Had another 48hr game jam this weekend...

[Iain Buclaw]

On Sep 2, 2013 1:26 AM, "Jonathan M Davis" <jmdavisProg at gmx.com> wrote:
>
> 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

I thought the problem with D strings was dmd, not gdb. As gdb has basic
debugging capability with D (from experience with gdc).  Such as the
ability to set breakpoints using pretty names, and it also recognises D
arrays and prints them out in a pretty manner too.  Ie:  {1, 2, 3} and not
{.length=3, .ptr=0x7ffff7ed0ff0}  (it does this by probing the type fields,
if it sees a two field struct with the member names length and ptr then it
works.  If it sees a ulong (see ABI page for dmd) then it will print you a
ulong value.

If anyone has any suggestions for improving gdb support, just let me know
as I intend to get round to improving some bits and pieces here and there
someday.

Regards
-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20130902/a3c57e4d/attachment.html>