On Sunday, September 01, 2013 17:14:01 H. S. Teoh wrote: > Well, I'm not an IDE person, so I have nothing to say on that front. > > But I will say that debugging can and must be improved. Currently, about > the only thing usable for dmd -g is to get a stacktrace of a program > crash. Nothing else seems to be properly supported (I use gdb). Stepping > through statements and setting breakpoints more-or-less works, but I > can't get at most variables (keeps complains about being unable to > reference 'this' or something similar), sometimes variable values are > outright wrong or completely unrelated to the actual value, sometimes > variables shown right on the source line being debugged don't exist in > the debugger ('no such symbol'). Unable to look into nested structs > without hitting odd behaviour. Doesn't understand D naming conventions > (or does so poorly). > > Basically, I've given up trying to use gdb on D programs except when I > need to find out where a crash is happening. Using writeln debugging is > far more productive, sadly to say. I can imagine this state of affairs > is quite disappointing to many potential D adopters.
This more or less mirrors my sentiments. I use (g)vim pretty much exclusively, so I don't really care about IDEs aside from how they help the community at large (your typical IDE's editing capabilites are so much of a joke compared to those of vim, that using an IDE really makes no sense for editing - for me at least). However, I would definitely like improved debugger support. I almost always end up using writeln debugging except when I need to track down a segfault. Of course, gdb support for _C++_ sucks in my experience. It can't understand basic stuff like operator overloading. So, I wouldn't expect much from D support either - though it would be really nice if gdb could at least understand D strings. I certainly wouldn't be opposed to someone writing a solid debugger which was D-centric, as it would really improve debugging, but I'm not holding my hopes up at this point. That's a major undertaking. - Jonathan M Davis