View mode: basic / threaded / horizontal-split · Log in · Help
February 27, 2007
Re: Debuggers for D
it wouldn't make any sense to assign any line other than the one of the
mixin statement. hence this isn't much of a problem.

DMD for windows assigns the line following the mixin statement to the
code. well, kind of... it looks a bit like the current behaviour is not
intended.

Ary Manzana wrote:
> John Demme wrote:
>> I'm pretty sure that a fair of the
>> linenumber and file information is wrong
> 
> Imagine when mixins will come into play. What line and number
> information can be recorded for symbols generated at compile time? :-O
February 27, 2007
Re: Debuggers for D
Cristian Vlasceanu wrote:

> John Demme wrote:
>> Bill Baxter wrote:
>> 
>>> Walter Bright wrote:
>>>> This newsgroup is for discussions about debuggers for D with at least
>>>> some D specific support:
>>>>
>>>> 1) Cristi Vlasceanu's ZeroBUGS for Linux:
>>>>
>>>> http://www.zerobugs.org/
>>> D support is still vapor as far as I know?  Couldn't find anything
>>> mentioned on the web page.
>>>
>> 
>> He doesn't mention it on the website, but there is some limited support
>> for
>> D.  I've been working with it a bit today.
>> 
>> Unfortunately, when it comes to debugging D code on Linux it's hard to
>> label
>> a debugger as vaporware when in fact "dmd -g" is vaporware.  I can't tell
>> what's the debugger's fault and what DMD either isn't doing or is doing
>> wrong.  Hell, #146 is still open!  I'm pretty sure that a fair of the
>> linenumber and file information is wrong, and most symbols don't appear
>> in
>> the DWARF information.  I don't mind sounding like a broken record when I
>> say that I'd be very, very happy if the next DMD had real Linux debugging
>> support.  According to Critian, it's not too hard to do with libdwarf.
>> 
> I am currently having an email exchange with Walter on the topic of line
> numbers. Which BTW, work with GDC.
> 
> Indeed, the only place I alluded to D is on the zero-bugs.com FAQ page.
> Thomas Kuehne has graciously contributed a D demangler, the Dmain
> function and the dthrow are detected, but that's about it so far.
> 
> I hope to get the D support in a better shape as soon as we fix this
> line numbers show stopper problem.

Great!

While you're at it, and Walter's knee deep in DWARF output, can you nudge
him in the direction of fixing bug #146?  If you're doing any template
programming--and I do a--it's a debugging show stopper, also.

Thanks for your work with D!

-- 
~John Demme
me@teqdruid.com
http://www.teqdruid.com/
January 27, 2008
Re: Debuggers for D
In an ideal world there would also be a full "stack trace" of 
information where the mixin was used... The more complex metaprogramming 
becomes, the more important it is to be able to (easily!) debug the 
compilation process itself.

I don't pay too close attention to the D community, and clearly runtime 
debugging support is a higher priority, but is 
mixin/template/metaprogramming debugging on anyone's radar at all? It's 
nice to have powerful metaprogramming support in D, but if the only way 
to debug a wacky template is via compiler error messages, it's just as 
bad as having to debug a normal program only using crash stack traces.

Jascha Wetzel wrote:
> it wouldn't make any sense to assign any line other than the one of the
> mixin statement. hence this isn't much of a problem.
> 
> DMD for windows assigns the line following the mixin statement to the
> code. well, kind of... it looks a bit like the current behaviour is not
> intended.
> 
> Ary Manzana wrote:
>> John Demme wrote:
>>> I'm pretty sure that a fair of the
>>> linenumber and file information is wrong
>> Imagine when mixins will come into play. What line and number
>> information can be recorded for symbols generated at compile time? :-O
January 28, 2008
Re: Debuggers for D
Michael Coupland wrote:
> In an ideal world there would also be a full "stack trace" of 
> information where the mixin was used... The more complex metaprogramming 
> becomes, the more important it is to be able to (easily!) debug the 
> compilation process itself.
> 
> I don't pay too close attention to the D community, and clearly runtime 
> debugging support is a higher priority, but is 
> mixin/template/metaprogramming debugging on anyone's radar at all?

Descent could do this in a future. I think it isn't hard, but it'll take 
its time.
Next ›   Last »
1 2
Top | Discussion index | About this forum | D home