GDB Frontend with C Pointer Visualization
1–10 of 58 posts
Re: GDB Frontend with C Pointer Visualization
#2This looks like a modern-day ddd [1]. Sorely needed. (Not much by me, since I don't do a lot of C these days, but I'd definitely use this if I did.)
Re: GDB Frontend with C Pointer Visualization
#3This looks like a modern-day ddd [1]. Sorely needed. (Not much by me, since I don't do a lot of C these days, but I'd definitely use this if I did.) [1]: https://www.gnu.org/software/ddd/
Or to go more into the past, a modern day Zortech C++ debugger.
I still make use of DDD, one of the debuggers that made my UNIX development experience more enjoyable (vs PC/Mac tooling).
Re: GDB Frontend with C Pointer Visualization
#4This looks like a modern-day ddd [1]. Sorely needed. (Not much by me, since I don't do a lot of C these days, but I'd definitely use this if I did.) [1]: https://www.gnu.org/software/ddd/
What I don't understand with this "modernity" is these "black background shimmery text" themes.
Because that's what we had in bad old days before the monitors were able to show pixels -- the text consoles could actually show only text and the technology used was too poor to have nice pale background and black letters.
But why would somebody want this on the modern displays, except because he does that instead of properly adjusting the background light or because "the real cool guys look at black screens" is beyond me. Seriously, the displays aren't cheap eighties displays anymore. And even then the expensive ones already looked much better by default than these "modern" themes now.
/end of the old guy's lawn rant
Otherwise, I definitely like every debugging tool that tries to have a good GUI.
Re: GDB Frontend with C Pointer Visualization
#5Would be amazing if this could also integrate with a language server to provide code browsing functionality. These days I'm using Vim's gdb integration, which doesn't have any data visualisation features, but lets me use all of my code browsing plugins.
Re: GDB Frontend with C Pointer Visualization
#6This looks like a modern-day ddd [1]. Sorely needed. (Not much by me, since I don't do a lot of C these days, but I'd definitely use this if I did.) [1]: https://www.gnu.org/software/ddd/
I love the ability of ddd to plot 1d and 2d arrays in gnuplot, while you debug, updating the plot after each next instruction. Really handy for numerical codes. I have not found yet another tool with the same functionality. The python calls from gdb allows to do something similar but does not update automatically and you have to use much more code
Re: GDB Frontend with C Pointer Visualization
#7This looks like a modern-day ddd [1]. Sorely needed. (Not much by me, since I don't do a lot of C these days, but I'd definitely use this if I did.) [1]: https://www.gnu.org/software/ddd/
What I don't understand with this "modernity" is these "black background shimmery text" themes. Because that's what we had in bad old days before the monitors were able to show pixels -- the text consoles could actually show only text and the technology used was too poor to have nice pale background and black letters. But why would somebody want this on the modern displays, except because he does that instead of prop…
Basically that is how I feel when I see HD colour screens being used to organize XTerms, similar to the IBM XWindows terminals I got to use in 1994.
Re: GDB Frontend with C Pointer Visualization
#8Is this any different than the debugger visualisations that other editors/IDEs have?
Genuinely curious, because if I'm understanding this correctly, it's just another front-end like what VSCode/Atom(probably)/CLion/Visual Studio have been doing for years if not decades.
I guess what I'm asking is: does this do a better job than the others?
Re: GDB Frontend with C Pointer Visualization
#9This looks like a modern-day ddd [1]. Sorely needed. (Not much by me, since I don't do a lot of C these days, but I'd definitely use this if I did.) [1]: https://www.gnu.org/software/ddd/
What I don't understand with this "modernity" is these "black background shimmery text" themes. Because that's what we had in bad old days before the monitors were able to show pixels -- the text consoles could actually show only text and the technology used was too poor to have nice pale background and black letters. But why would somebody want this on the modern displays, except because he does that instead of prop…
I have tried to use a lighter background because apparently "that's the correct thing". After experiencing significant eye fatigue I switched back to dark blue.
Re: GDB Frontend with C Pointer Visualization
#10This looks like a modern-day ddd [1]. Sorely needed. (Not much by me, since I don't do a lot of C these days, but I'd definitely use this if I did.) [1]: https://www.gnu.org/software/ddd/
What I don't understand with this "modernity" is these "black background shimmery text" themes. Because that's what we had in bad old days before the monitors were able to show pixels -- the text consoles could actually show only text and the technology used was too poor to have nice pale background and black letters. But why would somebody want this on the modern displays, except because he does that instead of prop…
> What I don't understand with this "modernity" is these "black background shimmery text" themes.
Because we're mostly using emissive displays, and it turns out that trying to imitate what works on paper on an emissive display sucks for long term use (though it looks pretty at a glance, and if you are composing things for print WYSIWYG may be more important than what is most comfortable on the screen.) We tried light themes as the almost invariable rule for the first several decades of GUIs, but recently got over it.
(Light backgrounds are awesome on reflective media, and if eInk was cheap and fast enough to use for primary monitors for coding we’d do that.)