joe513
Great to see a debugger for Linux being released! Just signed up, look forward to trying it this evening.

I really appreciate this. For projects like this every bit of support helps to maintain a healthy state. Generally speaking for further development I will try to be as transparent as possible.

I've created the mentioned video regarding saving configurations and the current ability for small customizations.
fun fact: all of the functionality (support for the "configs", "colors" and "layout" files) shown in the video is actually implemented in a custom layer by itself but that one is not ready yet.

(not all of the available color types and states are actually in use)

For a pre alpha release this is looking pretty good! After using the standard gdb console for the last few months this is pretty awesome. Having the values displayed directly in the source code and the option to "Run to cursor" are super handy and quick, not to mention the near instant start up time.
Just a couple quick questions
(1) Any way to change the font size?
(2) Considering it is pre alpha are you looking for issues to be reported yet? And if so where and how do you prefer?

joe513

(1) Any way to change the font size?

I have noticed that as well while creating the new help overlays and unfortunately font sizes are currently simply set dynamically in the UI code. I hope that I can provide a simple but not too temporary solution in the next couple days. Something the system is also missing is the ability for hierarchic values (as in color of a button or text in a certain panel) which has let to some hardcoded color values as well.

joe513

(2) Considering it is pre alpha are you looking for issues to be reported yet? And if so where and how do you prefer?

absolutely, yes. I have started to create a project submission which should give a bit more space for such reports or general discussion (instead of cluttering a single thread). After all this is a handmade project at heart and is in good company there. But I won't be able to finish the submission until later today.

Not everything can get priority but especially when asserts are hit or there is some misbehavior (wrong values for variables, ..) it is good to know at any stage. Of course you can always throw me an email but public posts can have the advantage of being helpful for others as well.

Also at some point I want to provide an actual structured bugtracker, ideally without the need to create "yet another account", so maybe using the patreon account for that.

First of all, great work! I'm really looking forward to this project.

Sadly, with the first thing I tried to debug I managed to hit a bug.
I don't know what you'd like for me to send you - maybe the executable?

Here is the terminal output:


I've tried to compile it with both g++ and clang++ and got the same result.
CPU - i5 2500K, GPU - NVIDIA GeForce GTX 960, OS - Arch Linux 4.12.12-1

I tested it with a hello world program and it worked just fine.

Dautor
First of all, great work! I'm really looking forward to this project.

Sadly, with the first thing I tried to debug I managed to hit a bug.
I don't know what you'd like for me to send you - maybe the executable?

Thank you for the feedback. This shouldn't be too hard. The position of the assert suggests that the debugger is "unhappy" with the memory mappings of the debugged application. I have a few assumptions in there that have been true to this point but maybe I have to extend this part a bit.
If possible you could start the codeclap binary using another debugger (gdb for example, such irony ^^) and run to the point of the assert (attaching the debugger is basically only to prevent the process from exiting at this point). Then look into the memory layout of the process that codeclap was supposed to debug (the process id from the terminal output, after "Child id is .." should be the correct one and should still be active at this point). You can get the layout from /proc/{processid}/maps simply by using cat. The interesting information in there is basically the memory ranges, the permissions and the library names.
If possible you could post it here somehow or just send it to me via mail ([email protected]).

I will also see if I can reproduce this problem under Arch Linux.

I'll do that tomorrow as it is pretty late here and I almost never use a debugger (gdb).
One more thing - when I'm debugging and I'm stepping through, the color of the current line is really hard for me to differentiate from other lines and I have not found a way to change its color. It might be normal for you, but do consider that I'm colorblind.

Dautor
I'll do that tomorrow as it is pretty late here and I almost never use a debugger (gdb).
One more thing - when I'm debugging and I'm stepping through, the color of the current line is really hard for me to differentiate from other lines and I have not found a way to change its color. It might be normal for you, but do consider that I'm colorblind.

good news is, that I've just posted an update on the patreon page regarding this issue (or more specifically the issue that only a handful of things have been customizable). This also includes the font sizes as discussed before.

In addition to this post here is an example on how this will look in the future:


In this state the line of the instruction pointer and the highlighted line (as seen in the screenshot) are still missing from this but will be changeable as well.

Looking forward to the upcoming changes. The new configuration parameters will make it easier to work with when using my smaller screen.

Question about viewing memory. When viewing the memory of an array of chars with lets say 10,000 elements the application pretty much stops. Not sure if the time to read all of the memory is causing the issue or if it is trying to render it all at once. I might be doing something wrong or is there a better way to look at large arrays?

joe513
Looking forward to the upcoming changes. The new configuration parameters will make it easier to work with when using my smaller screen.

Question about viewing memory. When viewing the memory of an array of chars with lets say 10,000 elements the application pretty much stops. Not sure if the time to read all of the memory is causing the issue or if it is trying to render it all at once. I might be doing something wrong or is there a better way to look at large arrays?

I will be finishing up these changes some time today.

yes, indeed it tries to render a memory view that is able to show the whole memory range. By itself this probably wouldn't be such a big problem but the interface system is not adjusted very well to showing such an amount of small elements. But I certainly will use things like this when looking into improving that part. For now I will limit the size of the view to something reasonable; giving the ability to resize the view at some point in the future (if I don't get it in there for this build).

After that 00.01.05 will probably more about fixing bugs I know of at this point before continuing with conditional breakpoints for 00.01.06.

First of all I am happy to note that the project submission has been approved as of today. Feel free to open threads for separate issues or suggestions over there at https://codeclap.handmade.network. From now on I will also post all updates and news there.

I've uploaded the current state as 00.01.04 over at the patreon page.

Because of the new scopes the help overlay with all the different types and states isn't that helpful anymore at the moment. I plan on doing some kind of a "picker cursor" that allows to select widgets directly from the UI to get information about the type and states and allow for direct customization. But for now the existing entries in the ui.config file hopefully should suffice in understanding what can be customized.
To test this I've gone a bit crazy and this is the result; you can also notice that the highlights for the IP and breakpoints should be much more visible now.