31–40 of 58 posts
Earlier quoted context omitted.
"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?
There aren't that many books on Qt, besides Packt ones, AFAIK.
There is also https://github.com/cs01/gdbgui
From the project page: > Note: This project is no longer under active development.
Earlier quoted context omitted.
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
With kmdb you get to write shell-like pipelines using powerful data structure traversal builtins, and it is safe (you can't crash the system by dereferencing NULL pointers). Really, it's quite fantastic.
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…
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.
IIRC, the issue is legibility more than eyestrain (though they are related) and light themes are still better with normal vision, but a majority of the adult population has one or more of the vision issues that reverse this (astigmatism being the main one, and alone accounting for nearly 50%.)
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…
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 b…
No, I'm talking about what's true of the population as a whole (but not every individual member) as if it was the driver of the trend the poster I was responding to questioned...because it is.
Earlier quoted context omitted.
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 c…
Earlier quoted context omitted.
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 c…
I guess one reason it wasn't used much is because it was a hassle to set up, and I think it got a bit slow when you had a lot of information displayed. I do recall not using this setup much in practice, as just breaking into the debugger on the machine itself was faster and easier.
You had to lot of options when it came to working on the Solaris kernel, and the code was so easy to understand. In fact, I believe the Solaris code base is the best C code I've ever worked with. It's a pity what happened after Oracle took over.
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/
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).
The interface is surprisingly good, and it's what I recommend to new gdb users if they aren't using an IDE. I still prefer the Emacs integration[1], but I don't recommend that to people who aren't already experienced Emacs users.
[1] https://sourceware.org/gdb/current/onlinedocs/gdb/Emacs.html...