Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

GDB Frontend with C Pointer Visualization

github.com

Post reply on HN
Print view View original

21–30 of 58 posts

Re: GDB Frontend with C Pointer Visualization

#21

Post by scoutt »

acqq wrote: post #14
dragonwriter wrote: post #10

Earlier quoted context omitted.

> 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…

> 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 I claim it’s not true. If one would measure The light flux of my screen I’m sure it wouldn’t be higher than that of the paper when reading in good light conditions. I claim that it’s dependent of how one configures his display.

Emitting light != reflecting light.

I used to battle too against "dark modes". But I was forced to use VSCode for one project (since a couple of months), and I have to say that I became so used to it that now I want to use "dark mode" everywhere I can. Unfortunately IDEs for embedded like KEIL uVision will never get such feature, and now it's a pain to go back to white background.

Re: GDB Frontend with C Pointer Visualization

#22

Post by seanmcdirmid »

dragonwriter wrote: post #10
acqq wrote: post #4

Earlier quoted context omitted.

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…

Light themes are better than dark themes from an eye strain perspective if a room is well lit. On the other hand, dark themes are better in low light conditions, so if you like coding in dark rooms dark themes are essential. Dark themes are also good for photo editing where you don’t want chrome saturating content.

Re: GDB Frontend with C Pointer Visualization

#23

Post by seanmcdirmid »

Razengan wrote: post #12
acqq wrote: post #4

Earlier quoted context omitted.

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 don’t like this so nobody else should" is always obnoxious to read. I like dark mode. If it has options to let you have dark-text-on-bright-backgrounds, why does the option for a dark mode bother you? Tech should cater to different needs. Nobody should have to defend their preferences against anyone, but for those wondering if there are any objective reasons: I don’t want intense light constantly blasting my eyes,…

Unless you are using an OLED, a dark theme is not more energy efficient than a light one.

Re: GDB Frontend with C Pointer Visualization

#24

Post by pjmlp »

ducktective wrote: post #17

I see it is using PyQt5. Any favorite books/tutorials/guides on learning Qt5 or PyQt5? (I'm at 1/4 of Koenig's accelerated C++ and know some python to get my day to day script needs done)

"Mastering Qt 5" would be one of them.

https://www.packtpub.com/eu/web-development/mastering-qt-5-s...

Re: GDB Frontend with C Pointer Visualization

#25

Post by mistrial9 »

lokedhs wrote: post #11
nathell wrote: post #2

This 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/

That reminds me about that one day in at Sun back in the late 90's when I compiled Solaris in debug mode and set up KGDB. I was running a full Solaris kernel while anothe rmachine was running GDB and DDD. I was able to visualise all the kernel structures in realtime. It was significantly more usable that I would have imagined it to be. Can you do something similar these days with Linux?

curious - the Sun developers I saw in the late 90s had a multi-window debugger but the local variables Did Not Update, and had to be 'refreshed' manually; at the same time, I had MetrwoWerks IDE Debugger on a Macintosh, and easily had all locals, source code, stack, RAM inspection by structure and more, all updating with every change. The Sun devs were being PAID a LOT more, yet their tools looked primitive and the contextual knowledge to use them was much greater..

Re: GDB Frontend with C Pointer Visualization

#28

Post by ducktective »

pjmlp wrote: post #24
ducktective wrote: post #17

I see it is using PyQt5. Any favorite books/tutorials/guides on learning Qt5 or PyQt5? (I'm at 1/4 of Koenig's accelerated C++ and know some python to get my day to day script needs done)

"Mastering Qt 5" would be one of them. https://www.packtpub.com/eu/web-development/mastering-qt-5-s...

There seems to be critical reviews against Packt publications but this one is good right? Have you read it yourself?

Re: GDB Frontend with C Pointer Visualization

#29

Post by ktm5j »

lokedhs wrote: post #11
nathell wrote: post #2

This 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/

That reminds me about that one day in at Sun back in the late 90's when I compiled Solaris in debug mode and set up KGDB. I was running a full Solaris kernel while anothe rmachine was running GDB and DDD. I was able to visualise all the kernel structures in realtime. It was significantly more usable that I would have imagined it to be. Can you do something similar these days with Linux?

You could, but eBPF might be a more sensible way to get the same information: http://www.brendangregg.com/ebpf.html

Re: GDB Frontend with C Pointer Visualization

#30

Post by ubercow13 »

dragonwriter wrote: post #10
acqq wrote: post #4

Earlier quoted context omitted.

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…

You are really just talking about your preferences as if they are scientific absolutes. It depends on your eyes including the amount of floaters you have and how imperfect the lens of your eye is away from its centre, the lighting conditions of your room, your monitor, your taste.

I am not sure exactly when the recent trend towards dark editor themes started but I wonder if it was around the same time that WLED LCD backlighting took over? I love white themes on my CFL monitor but not so much on my WLED laptop.

I also think maybe many people started preferring dark colour schemes because colours pop and look more saturated against black, and so it looks better in screenshots etc.

Post reply on HN