3 ms·
Sounds like 'better', being built around a set of libraries first, with the ability to write plugins/extension in a reasonable language like Python. Most softw
by pquerna 16y ago
Sounds like 'better', being built around a set of libraries first, with the ability to write plugins/extension in a reasonable language like Python.
Most software written originally 20 years ago is going to seem crusty, and have issues in a field as young as computer science -- there are just better ideas and practices these days compared to when GDB was first started, not even considering licensing issues.
Compare the architecture of Airplanes between WWI and WWII to the modern Jet age -- and real software development is still young compared to Airplanes, so yeah, its competition, but as long as it develops into a successful project, I'd expect it to be quite a bit better than GDB in the long run.
- lsb 16y agoYes -- antirez who wrote Redis wrote linenoise, a replacement of the 20k lines of the old GNU readline in about 400 lines of C for only the 99.99% of users who are on VT100 terminals. http://github.com/antirez/linenoise http://github.com/antirez/linenoise
- grogers 16y agoOf the tangible features that they list as motivation: - Build libraries for inclusion in IDEs, command line tools, and other analysis tools - gdb seems to have it http://sourceware.org/gdb/papers/libgdb2/libgdb_toc.html http://sourceware.org/gdb/papers/libgdb2/libgdb_toc.html - High performance and efficient memory use - I cant comment on how much of gdb's sluggishness in running programs is inherent in the problem, and how much is gdb being slow. - Extensible: Python scriptable and use a plug-in architecture - gdb has it http://sourceware.org/gdb/current/onlinedocs/gdb/Extending-GDB.html#Extending-GDB http://sourceware.org/gdb/current/onlinedocs/gdb/Extending-G... - Excellent multi-threaded debugging support - GDB could be better - I wish it could stop threads individually, instead of all-stop then all-resume even on a single step. But IIRC there is a project to be able to do something like this eventually. - Great support for C, Objective-C and C++ - Can't comment on objective-c, but the C++ support has gotten significantly better since GCC 4.5/GDB 7.0 with pretty printing of C++ data structures, and has been steadily improving over time handling C++ mangling. - Retargetable to support multiple platforms - gdb naturally is widely ported - A remote protocol server, debugserver, implements Mac OS X debugging on i386 and x86_64. - gdb has it I haven't seen anything that really improves on gdb yet. Maybe (hopefully) I'm wrong...
- wazoox 16y agoIt comes from Apple and is bsd-licensed. In this community, this passes for "enhancements" over gdb. Yes, this is a bitter comment about the HN community state of mind.
- pohl 16y agoYeah, pesky entrepreneurs and their eye for opportunity.
- wazoox 16y agoWell, my company only works on gpl stuff and doesn't suffer any inconvenience from that. So I call bluff.
- pohl 16y agoYou're saying that being able to statically link a library into a commercial app has no business value to anybody because you are fortunate enough to have found a niche where you didn't need to. Your personal experience is enviable, but I don't see how it speaks to the general case.
- wazoox 16y agoI actually think that proprietary software is morally wrong anyway. Blasphemy! :)
- neilc 16y agoI think that's far too cynical. gdb is fine, but there is tons of room for improvement, and more competition in this area can only be a good thing. It is early days yet for LLDB, but it is a promising start. I've yet to see any IDE/debugger setup on a Unixen that comes close to competiting with Visual Studio's debugging interface, as unfortunate as that is.
- 16y ago