February 27, 2007
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
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
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
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.
1 2
Next ›   Last »