• Chuck.Esterbrook /at/ gmail /dot/ com <Chuck.Esterbrook_member pathlink.com> Aug 15 2005
• Derek Parnell <derek psych.ward> Aug 15 2005
• Chuck.Esterbrook /at/ gmail /dot/ com <Chuck.Esterbrook_member pathlink.com> Aug 16 2005
• "Ben Hinkle" <ben.hinkle gmail.com> Aug 16 2005
• pragma <pragma_member pathlink.com> Aug 16 2005
• "Charles" <noone nowhere.com> Aug 16 2005
• "Charles" <noone nowhere.com> Aug 16 2005
• "Charles" <noone nowhere.com> Aug 16 2005
• "Ben Hinkle" <bhinkle mathworks.com> Aug 16 2005
• "Charles" <noone nowhere.com> Aug 16 2005
• AJG <AJG_member pathlink.com> Aug 16 2005
• "Ben Hinkle" <ben.hinkle gmail.com> Aug 16 2005
• AJG <AJG_member pathlink.com> Aug 16 2005
• pragma <EricAnderton youknowthedrill.yahoo> Aug 17 2005
• "Charles" <noone nowhere.com> Aug 17 2005
• J Thomas <jtd514 ameritech.net> Aug 18 2005
• AJG <AJG_member pathlink.com> Aug 16 2005
• Chuck.Esterbrook /at/ gmail /dot/ com <Chuck.Esterbrook_member pathlink.com> Aug 16 2005
• pragma <EricAnderton youknowthedrill.yahoo> Aug 17 2005
• Chuck Esterbrook <Chuck.Esterbrook gmail.antispam.com> Aug 25 2005
• John Reimer <terminal.node gmail.com> Aug 17 2005
• Hasan Aljudy <hasan.aljudy gmail.com> Aug 16 2005
• zwang <nehzgnaw gmail.com> Aug 16 2005
• Chuck Esterbrook <Chuck.Esterbrook gmail.antispam.com> Aug 24 2005
• Hasan Aljudy <hasan.aljudy gmail.com> Aug 16 2005
• Hasan Aljudy <hasan.aljudy gmail.com> Aug 16 2005
• "ElfQT" <dethjunk yahoo.com> Aug 17 2005

Chuck.Esterbrook /at/ gmail /dot/ com <Chuck.Esterbrook_member pathlink.com> writes:

What debuggers, if any, are people actually using with their DMD programs on
Windows? You know: setting breakpoints, examining a live stack when an error
occurs, etc.

Does the one with DMC work with DMD executables?
http://www.digitalmars.com/ugr/chapter23.html


Thanks,
-Chuck

Derek Parnell <derek psych.ward> writes:

On Tue, 16 Aug 2005 06:34:58 +0000 (UTC), Chuck.Esterbrook /at/ gmail /dot/
com wrote:

 What debuggers, if any, are people actually using with their DMD programs on
 Windows? You know: setting breakpoints, examining a live stack when an error
 occurs, etc.


Real Programmers Don't Use Debuggers ;-)

I am a bit of a luddite in this regard. I still use the odd writef() to
'trace' my code. As a consequence, I only make tiny code changes before
each test run, in order to limit the debugging focus. Oh, that and unit
tests.

I suppose if there was a useful interactive GUI debugger that could really
understand D internals etc ... I might be tempted into the dark side. 

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
16/08/2005 4:47:22 PM

Chuck.Esterbrook /at/ gmail /dot/ com <Chuck.Esterbrook_member pathlink.com> writes:

In article <xze9vkdbz6oq$.1uac3snm89ho3$.dlg 40tude.net>, Derek Parnell says...
On Tue, 16 Aug 2005 06:34:58 +0000 (UTC), Chuck.Esterbrook /at/ gmail /dot/
com wrote:

 What debuggers, if any, are people actually using with their DMD programs on
 Windows? You know: setting breakpoints, examining a live stack when an error
 occurs, etc.


Real Programmers Don't Use Debuggers ;-)

I am a bit of a luddite in this regard. I still use the odd writef() to
'trace' my code. As a consequence, I only make tiny code changes before
each test run, in order to limit the debugging focus. Oh, that and unit
tests.

I suppose if there was a useful interactive GUI debugger that could really
understand D internals etc ... I might be tempted into the dark side. 


I think limiting myself to only some QA and troubleshooting techniques would be
a poor choice. I'm a proud user of pre-post-conditions, class invariants,
asserts, unit tests, print statements, exception handling, static source code
analysis and debuggers.

I know from experience that if I removed any one of those "from the equation" my
productivity would be reduced. They all have pros and cons and I enjoy applying
each of them when they are called for.

I've received substantial benefits from:
- Python's dumping of the entire stack trace for uncaught exceptions. This
really helps diagnosis.
- Python's ability to include additional run time information with assertions (a
topic recently brought up in this newsgroup).
- WingIDE for interacting with a live Python program.
- Visual Studio 2003 for interacting with a live C# program.

Before my D codebase becomes substantial, I hope to acquire similar capabilities
for D. Hopefully, someone already has to some degree and can share their actual
experiences.

-Chuck

"Ben Hinkle" <ben.hinkle gmail.com> writes:

 I've received substantial benefits from:
 - Python's dumping of the entire stack trace for uncaught exceptions. This
 really helps diagnosis.


Someone started working on this but I don't know the current status:
http://www.digitalmars.com/d/archives/digitalmars/D/22562.html
http://www.digitalmars.com/d/archives/digitalmars/D/22967.html 

pragma <pragma_member pathlink.com> writes:

In article <ddsm6e$21n$1 digitaldaemon.com>, Ben Hinkle says...
 I've received substantial benefits from:
 - Python's dumping of the entire stack trace for uncaught exceptions. This
 really helps diagnosis.


Someone started working on this but I don't know the current status:
http://www.digitalmars.com/d/archives/digitalmars/D/22562.html
http://www.digitalmars.com/d/archives/digitalmars/D/22967.html 


Did he ever post anything (a zip, URL, anything) to the DNG for his work?  Maybe
someone should hunt down his email?

- EricAnderton at yahoo

"Charles" <noone nowhere.com> writes:

I have been working on a Debugger for months , but have been strapped for
time lately ( like all of us. ).  It uses dbghelp & imghelp to extract
symbols.  What its missing is the ability to get 'type' info from variables
so it can 'see' their contents , however Walter  said he'd totally add this
into the debug info , soon as their codes are figured out.

What I have now is really rough , its a mess in fact . I will clean it up
today and put it on the web, but I want to post while everyone is still
interested.

Maybe if we all combine what little time we have we can finish it and get a
debugger !


Charlie


"pragma" <pragma_member pathlink.com> wrote in message
news:ddsrcu$7f9$1 digitaldaemon.com...
 In article <ddsm6e$21n$1 digitaldaemon.com>, Ben Hinkle says...
 I've received substantial benefits from:
 - Python's dumping of the entire stack trace for uncaught exceptions.






 really helps diagnosis.


Someone started working on this but I don't know the current status:
http://www.digitalmars.com/d/archives/digitalmars/D/22562.html
http://www.digitalmars.com/d/archives/digitalmars/D/22967.html


 Did he ever post anything (a zip, URL, anything) to the DNG for his work?


 someone should hunt down his email?

 - EricAnderton at yahoo

"Charles" <noone nowhere.com> writes:

It still needs work , right now just run it on a faulty program to see a
call stack dump.

http://www.thecodebase.com/DMDebugApi.zip

DMDebugApi\DMDebugLib.dsw is the workspace.

Youll need latest windows SDK , and MSVC6 ( or 7 if you can get it
working ).

Eric I know you've been researching dynamic libs / OMF / COFF etc, would you
have time to work on this ?  If so maybe we can move discussion to DSP
forums.

Charlie

"Charles" <noone nowhere.com> wrote in message
news:ddsufj$atb$1 digitaldaemon.com...
 I have been working on a Debugger for months , but have been strapped for
 time lately ( like all of us. ).  It uses dbghelp & imghelp to extract
 symbols.  What its missing is the ability to get 'type' info from


 so it can 'see' their contents , however Walter  said he'd totally add


 into the debug info , soon as their codes are figured out.

 What I have now is really rough , its a mess in fact . I will clean it up
 today and put it on the web, but I want to post while everyone is still
 interested.

 Maybe if we all combine what little time we have we can finish it and get


 debugger !


 Charlie


 "pragma" <pragma_member pathlink.com> wrote in message
 news:ddsrcu$7f9$1 digitaldaemon.com...
 In article <ddsm6e$21n$1 digitaldaemon.com>, Ben Hinkle says...
 I've received substantial benefits from:
 - Python's dumping of the entire stack trace for uncaught exceptions.






 really helps diagnosis.


Someone started working on this but I don't know the current status:
http://www.digitalmars.com/d/archives/digitalmars/D/22562.html
http://www.digitalmars.com/d/archives/digitalmars/D/22967.html


 Did he ever post anything (a zip, URL, anything) to the DNG for his




 Maybe
 someone should hunt down his email?

 - EricAnderton at yahoo

"Charles" <noone nowhere.com> writes:

Sorry to flood , I would really like help on this if anyone is willing.  I
think having a fully functional debugger would do alot for the language.

Charlie


"Charles" <noone nowhere.com> wrote in message
news:ddt9us$nne$1 digitaldaemon.com...
 It still needs work , right now just run it on a faulty program to see a
 call stack dump.

 http://www.thecodebase.com/DMDebugApi.zip

 DMDebugApi\DMDebugLib.dsw is the workspace.

 Youll need latest windows SDK , and MSVC6 ( or 7 if you can get it
 working ).

 Eric I know you've been researching dynamic libs / OMF / COFF etc, would


 have time to work on this ?  If so maybe we can move discussion to DSP
 forums.

 Charlie

 "Charles" <noone nowhere.com> wrote in message
 news:ddsufj$atb$1 digitaldaemon.com...
 I have been working on a Debugger for months , but have been strapped




 time lately ( like all of us. ).  It uses dbghelp & imghelp to extract
 symbols.  What its missing is the ability to get 'type' info from


 so it can 'see' their contents , however Walter  said he'd totally add


 into the debug info , soon as their codes are figured out.

 What I have now is really rough , its a mess in fact . I will clean it




 today and put it on the web, but I want to post while everyone is still
 interested.

 Maybe if we all combine what little time we have we can finish it and




 a
 debugger !


 Charlie


 "pragma" <pragma_member pathlink.com> wrote in message
 news:ddsrcu$7f9$1 digitaldaemon.com...
 In article <ddsm6e$21n$1 digitaldaemon.com>, Ben Hinkle says...
 I've received substantial benefits from:
 - Python's dumping of the entire stack trace for uncaught










 This
 really helps diagnosis.


Someone started working on this but I don't know the current status:
http://www.digitalmars.com/d/archives/digitalmars/D/22562.html
http://www.digitalmars.com/d/archives/digitalmars/D/22967.html


 Did he ever post anything (a zip, URL, anything) to the DNG for his




 Maybe
 someone should hunt down his email?

 - EricAnderton at yahoo

"Ben Hinkle" <bhinkle mathworks.com> writes:

I haven't tried your app but I'm wondering what exactly the debugger has to 
do with dumping a stack trace on an uncaught exception. I had the impression 
the stack would be printed by the program as it exists even when there isn't 
a debugger controlling things. Similarly ordinary D code can request a stack 
dump or get the stack from an exception.

"Charles" <noone nowhere.com> wrote in message 
news:ddtj8s$11bo$1 digitaldaemon.com...
 Sorry to flood , I would really like help on this if anyone is willing.  I
 think having a fully functional debugger would do alot for the language.

 Charlie


 "Charles" <noone nowhere.com> wrote in message
 news:ddt9us$nne$1 digitaldaemon.com...
 It still needs work , right now just run it on a faulty program to see a
 call stack dump.

 http://www.thecodebase.com/DMDebugApi.zip

 DMDebugApi\DMDebugLib.dsw is the workspace.

 Youll need latest windows SDK , and MSVC6 ( or 7 if you can get it
 working ).

 Eric I know you've been researching dynamic libs / OMF / COFF etc, would


 have time to work on this ?  If so maybe we can move discussion to DSP
 forums.

 Charlie

 "Charles" <noone nowhere.com> wrote in message
 news:ddsufj$atb$1 digitaldaemon.com...
 I have been working on a Debugger for months , but have been strapped




 time lately ( like all of us. ).  It uses dbghelp & imghelp to extract
 symbols.  What its missing is the ability to get 'type' info from


 so it can 'see' their contents , however Walter  said he'd totally add


 into the debug info , soon as their codes are figured out.

 What I have now is really rough , its a mess in fact . I will clean it




 today and put it on the web, but I want to post while everyone is still
 interested.

 Maybe if we all combine what little time we have we can finish it and




 a
 debugger !


 Charlie


 "pragma" <pragma_member pathlink.com> wrote in message
 news:ddsrcu$7f9$1 digitaldaemon.com...
 In article <ddsm6e$21n$1 digitaldaemon.com>, Ben Hinkle says...
 I've received substantial benefits from:
 - Python's dumping of the entire stack trace for uncaught










 This
 really helps diagnosis.


Someone started working on this but I don't know the current status:
http://www.digitalmars.com/d/archives/digitalmars/D/22562.html
http://www.digitalmars.com/d/archives/digitalmars/D/22967.html


 Did he ever post anything (a zip, URL, anything) to the DNG for his




 Maybe
 someone should hunt down his email?

 - EricAnderton at yahoo






 

"Charles" <noone nowhere.com> writes:

 I haven't tried your app but I'm wondering what exactly the debugger has


 do with dumping a stack trace on an uncaught exception. I had the


 the stack would be printed by the program as it exists even when there


 a debugger controlling things.


Its certainly possible , my limited use of debuggers usually is just 'bt' in
GDB and using MSVC's 'Call Stack' window , this is the backtrace Im talking
about.  At the same point its also possible to enumerate through local
variables and display their variables etc.. , thats what Im trying to
implement -- it actually shoudln't take that much , just a good chunk of
time.

Charlie


"Ben Hinkle" <bhinkle mathworks.com> wrote in message
news:ddtkhh$12gl$1 digitaldaemon.com...
 I haven't tried your app but I'm wondering what exactly the debugger has


 do with dumping a stack trace on an uncaught exception. I had the


 the stack would be printed by the program as it exists even when there


 a debugger controlling things. Similarly ordinary D code can request a


 dump or get the stack from an exception.

 "Charles" <noone nowhere.com> wrote in message
 news:ddtj8s$11bo$1 digitaldaemon.com...
 Sorry to flood , I would really like help on this if anyone is willing.




 think having a fully functional debugger would do alot for the language.

 Charlie


 "Charles" <noone nowhere.com> wrote in message
 news:ddt9us$nne$1 digitaldaemon.com...
 It still needs work , right now just run it on a faulty program to see






 call stack dump.

 http://www.thecodebase.com/DMDebugApi.zip

 DMDebugApi\DMDebugLib.dsw is the workspace.

 Youll need latest windows SDK , and MSVC6 ( or 7 if you can get it
 working ).

 Eric I know you've been researching dynamic libs / OMF / COFF etc,






 you
 have time to work on this ?  If so maybe we can move discussion to DSP
 forums.

 Charlie

 "Charles" <noone nowhere.com> wrote in message
 news:ddsufj$atb$1 digitaldaemon.com...
 I have been working on a Debugger for months , but have been strapped




 time lately ( like all of us. ).  It uses dbghelp & imghelp to








 symbols.  What its missing is the ability to get 'type' info from


 so it can 'see' their contents , however Walter  said he'd totally








 this
 into the debug info , soon as their codes are figured out.

 What I have now is really rough , its a mess in fact . I will clean








 up
 today and put it on the web, but I want to post while everyone is








 interested.

 Maybe if we all combine what little time we have we can finish it and




 a
 debugger !


 Charlie


 "pragma" <pragma_member pathlink.com> wrote in message
 news:ddsrcu$7f9$1 digitaldaemon.com...
 In article <ddsm6e$21n$1 digitaldaemon.com>, Ben Hinkle says...
 I've received substantial benefits from:
 - Python's dumping of the entire stack trace for uncaught










 This
 really helps diagnosis.


Someone started working on this but I don't know the current












http://www.digitalmars.com/d/archives/digitalmars/D/22562.html
http://www.digitalmars.com/d/archives/digitalmars/D/22967.html


 Did he ever post anything (a zip, URL, anything) to the DNG for his




 Maybe
 someone should hunt down his email?

 - EricAnderton at yahoo

AJG <AJG_member pathlink.com> writes:

Hi,

I haven't tried your app but I'm wondering what exactly the debugger has to 
do with dumping a stack trace on an uncaught exception. I had the impression 
the stack would be printed by the program as it exists even when there isn't 
a debugger controlling things. Similarly ordinary D code can request a stack 
dump or get the stack from an exception.


Hm... interesting. I didn't know this could be done. Is there a page on how to
do this or maybe some example code?

Thanks!
--AJG.

"Ben Hinkle" <ben.hinkle gmail.com> writes:

"AJG" <AJG_member pathlink.com> wrote in message 
news:ddu16l$1dus$1 digitaldaemon.com...
 Hi,

I haven't tried your app but I'm wondering what exactly the debugger has 
to
do with dumping a stack trace on an uncaught exception. I had the 
impression
the stack would be printed by the program as it exists even when there 
isn't
a debugger controlling things. Similarly ordinary D code can request a 
stack
dump or get the stack from an exception.


 Hm... interesting. I didn't know this could be done. Is there a page on 
 how to
 do this or maybe some example code?

 Thanks!
 --AJG.


It's not in D yet (that's what the OP was requesting and it's what Maxime 
was working on). The links I posted in my first reply to this thread
http://www.digitalmars.com/d/archives/digitalmars/D/22562.html
http://www.digitalmars.com/d/archives/digitalmars/D/22967.html
are the only clues I know about for getting it implemented. I haven't 
checked some of the other replys on this thread for more details. That's all 
I know. 

AJG <AJG_member pathlink.com> writes:

Hi,

It's not in D yet (that's what the OP was requesting and it's what Maxime 
was working on). 


Hm... is that "yet" official?

The links I posted in my first reply to this thread
http://www.digitalmars.com/d/archives/digitalmars/D/22562.html
http://www.digitalmars.com/d/archives/digitalmars/D/22967.html
are the only clues I know about for getting it implemented. I haven't 
checked some of the other replys on this thread for more details. That's all 
I know.


Ok, thanks. So did Walter ever comment on this? I didn't see any replies in
either thread (or this one).

Cheers,
--AJG.

pragma <EricAnderton youknowthedrill.yahoo> writes:

Charles wrote:
 It still needs work , right now just run it on a faulty program to see a
 call stack dump.
 
 http://www.thecodebase.com/DMDebugApi.zip
 
 DMDebugApi\DMDebugLib.dsw is the workspace.
 
 Youll need latest windows SDK , and MSVC6 ( or 7 if you can get it
 working ).
 
 Eric I know you've been researching dynamic libs / OMF / COFF etc, would you
 have time to work on this ?  If so maybe we can move discussion to DSP
 forums.


Charles,
   I'll give your debugger a solid look sometime later on this week. 
However, I won't be able to do anything productive coding wise to it as 
I don't have MSVC6 installed (used to, but that was my last machine).

I'd love to help your efforts via my current research, if that's what 
you need.  Besides, its all quite synergistic as I could use a good 
debugging tool for what I'm working on.

So far I have an open OMF parser (no linker yet) that's yours to hack up 
all you like; its a frightful mess, but it can dump DMD's OMF files 
pretty well.  Its currently in the DSP SVN repos.

What I cannot fathom is how runtime object loading and linking interacts 
with debug information.  Right now, I feel like I run the risk of 
breaking debug info via runtime linking due to ignorance;  that's a 
drawback that is simply unacceptable.

Anyway, feel free to run amok in the DSP forum on dsource for any 
questions and issues you think I might be able to answer (I'd like to 
keep it in the forum, so it can stand as a research resource).

-- 
- EricAnderton at yahoo

"Charles" <noone nowhere.com> writes:

 I'd love to help your efforts via my current research, if that's what
 you need.  Besides, its all quite synergistic as I could use a good
 debugging tool for what I'm working on.


That'd be great ( good word syngery  ).

 So far I have an open OMF parser (no linker yet) that's yours to hack up
 all you like; its a frightful mess, but it can dump DMD's OMF files
 pretty well.  Its currently in the DSP SVN repos.


Very cool , checking it out .

 What I cannot fathom is how runtime object loading and linking interacts
 with debug information.


I have a vague idea -- something about storing a pointer to a debug table
... ( mutter ... trail off ).

 Anyway, feel free to run amok in the DSP forum on dsource for any
 questions and issues you think I might be able to answer (I'd like to
 keep it in the forum, so it can stand as a research resource).


Aye sounds good!

Charlie

"pragma" <EricAnderton youknowthedrill.yahoo> wrote in message
news:dducul$1mm6$1 digitaldaemon.com...
 Charles wrote:
 It still needs work , right now just run it on a faulty program to see a
 call stack dump.

 http://www.thecodebase.com/DMDebugApi.zip

 DMDebugApi\DMDebugLib.dsw is the workspace.

 Youll need latest windows SDK , and MSVC6 ( or 7 if you can get it
 working ).

 Eric I know you've been researching dynamic libs / OMF / COFF etc, would




 have time to work on this ?  If so maybe we can move discussion to DSP
 forums.


 Charles,
    I'll give your debugger a solid look sometime later on this week.
 However, I won't be able to do anything productive coding wise to it as
 I don't have MSVC6 installed (used to, but that was my last machine).

 I'd love to help your efforts via my current research, if that's what
 you need.  Besides, its all quite synergistic as I could use a good
 debugging tool for what I'm working on.

 So far I have an open OMF parser (no linker yet) that's yours to hack up
 all you like; its a frightful mess, but it can dump DMD's OMF files
 pretty well.  Its currently in the DSP SVN repos.

 What I cannot fathom is how runtime object loading and linking interacts
 with debug information.  Right now, I feel like I run the risk of
 breaking debug info via runtime linking due to ignorance;  that's a
 drawback that is simply unacceptable.

 Anyway, feel free to run amok in the DSP forum on dsource for any
 questions and issues you think I might be able to answer (I'd like to
 keep it in the forum, so it can stand as a research resource).

 --
 - EricAnderton at yahoo

J Thomas <jtd514 ameritech.net> writes:

killer! ive been working on a debugger written in d since my visual 
studio began crashing and i got tired of re-installing it (again)...

thanks very much for this code, you just saved me some work. im going to 
convert some of it to d since im never going to write c++ again unless i 
absolutely have to


Charles wrote:
 It still needs work , right now just run it on a faulty program to see a
 call stack dump.
 
 http://www.thecodebase.com/DMDebugApi.zip
 
 DMDebugApi\DMDebugLib.dsw is the workspace.
 
 Youll need latest windows SDK , and MSVC6 ( or 7 if you can get it
 working ).
 
 Eric I know you've been researching dynamic libs / OMF / COFF etc, would you
 have time to work on this ?  If so maybe we can move discussion to DSP
 forums.
 
 Charlie
 
 "Charles" <noone nowhere.com> wrote in message
 news:ddsufj$atb$1 digitaldaemon.com...
 
I have been working on a Debugger for months , but have been strapped for
time lately ( like all of us. ).  It uses dbghelp & imghelp to extract
symbols.  What its missing is the ability to get 'type' info from


 variables
 
so it can 'see' their contents , however Walter  said he'd totally add


 this
 
into the debug info , soon as their codes are figured out.

What I have now is really rough , its a mess in fact . I will clean it up
today and put it on the web, but I want to post while everyone is still
interested.

Maybe if we all combine what little time we have we can finish it and get


 a
 
debugger !


Charlie


"pragma" <pragma_member pathlink.com> wrote in message
news:ddsrcu$7f9$1 digitaldaemon.com...

In article <ddsm6e$21n$1 digitaldaemon.com>, Ben Hinkle says...

I've received substantial benefits from:
- Python's dumping of the entire stack trace for uncaught exceptions.






This

really helps diagnosis.


Someone started working on this but I don't know the current status:
http://www.digitalmars.com/d/archives/digitalmars/D/22562.html
http://www.digitalmars.com/d/archives/digitalmars/D/22967.html


Did he ever post anything (a zip, URL, anything) to the DNG for his




 work?
 
Maybe

someone should hunt down his email?

- EricAnderton at yahoo




 

AJG <AJG_member pathlink.com> writes:

Hi,

I think limiting myself to only some QA and troubleshooting techniques would be
a poor choice. I'm a proud user of pre-post-conditions, class invariants,
asserts, unit tests, print statements, exception handling, static source code
analysis and debuggers.

I know from experience that if I removed any one of those "from the equation" my
productivity would be reduced. They all have pros and cons and I enjoy applying
each of them when they are called for.

I've received substantial benefits from:
- Python's dumping of the entire stack trace for uncaught exceptions. This
really helps diagnosis.
- Python's ability to include additional run time information with assertions (a
topic recently brought up in this newsgroup).
- WingIDE for interacting with a live Python program.
- Visual Studio 2003 for interacting with a live C# program.


I completely agree with everything you've said here. When coding in C# I have
the enourmous benefit of the VS2K5 environment with its phenomenal debugger. I
mean that thing is almost a sentient creature by now.

It is really painful to go back and forth between this and printf() when coding
in D. OTOH, a rich environment like that _coupled_ with D would probably kick
butt.

Before my D codebase becomes substantial, I hope to acquire similar capabilities
for D. Hopefully, someone already has to some degree and can share their actual
experiences.


Personally, all my debugging efforts have failed miserably. I can't even get GDB
(various versions) to run my D programs _at all_ under linux. Sigh... this is an
area that could really use improvement.

Here's to something better coming along.
--AJG.

Chuck.Esterbrook /at/ gmail /dot/ com <Chuck.Esterbrook_member pathlink.com> writes:

In article <ddspqq$5p3$1 digitaldaemon.com>, AJG says...
Personally, all my debugging efforts have failed miserably. I can't even get GDB
(various versions) to run my D programs _at all_ under linux. Sigh... this is an
area that could really use improvement.


I'm starting to wonder if what we need at a higher level is an open source
D-to-C program (written in D, of course). We could compile with dmc, gcc, etc.

The resulting C code could be beefed up with stack tracing/management code and
other goodies as we need them. Or maybe debugged directly. We could fix syntax
problems like "if(int x = foo()) { <use x>" and so on. With more imagination, we
could probably double the list of benefits.

Another idea is to write a D-to-D translator. That would be even easier since
the target language is identical (or in the case of language changes,
near-identical). The generated D would look different from the original source
to the extent that debugging aids were turned on and language features had been
tweaked.

Something like:
 d2d -debug -stack -trace-mem MyProgram.d


which would do the translation and invoke dmd.exe to finish off compilation.
Hypothetically:
* "-stack" turns on whatever is needed to ask for stacks programmatically and to
dump them on uncaught errors.
* "-trace-mem" turns on whatever is needed to write stats on object creation and
destruction during execution.

Although I feel a little silly proprosing something I don't have time to work
on. :-)  However, I've read references to a D front end. Is that in D? If so,
d2d could be written in D which is certainly more productive than writing
anything in C or C++.

d2d could be our escape hatch for when we need to enhance D sooner rather than
later.

Reactions?

-Chuck

pragma <EricAnderton youknowthedrill.yahoo> writes:

Chuck.Esterbrook /at/ gmail /dot/ com wrote:
 Another idea is to write a D-to-D translator. That would be even easier since
 the target language is identical (or in the case of language changes,
 near-identical). The generated D would look different from the original source
 to the extent that debugging aids were turned on and language features had been
 tweaked.


I've thought about something like that myself.  Sort of like an 
aspect-oriented template for a whole source tree, eh?  Composed in an 
abstract fashion, it could be a very versatile tool in its own right.

 Although I feel a little silly proprosing something I don't have time to work
 on. :-)  


Hey, if you've got an hour, just throw a crude specification up on the 
Wiki with "please edit me if you want to contribute" plastered all over 
it.  Odds are you're probably a few more thoughts ahead of the rest of 
us on that idea.

Besides, this newsgroup is positively dreadful for archiving good 
concepts (as our debugger debacle has demonstrated).

 However, I've read references to a D front end. Is that in D?


I've done some hacking there myself.  Its a funny thing: its written in 
C, but most of that code are thinly veiled D-isms.  Picking through the 
source, one gets an impression of why Walter started D in the first 
place.  Eventually, some brave soul will convert this over to D and will 
likely see that its a fairly straightforward task.

-- 
- EricAnderton at yahoo

Chuck Esterbrook <Chuck.Esterbrook gmail.antispam.com> writes:

On Wed, 17 Aug 2005 00:14:13 -0700, pragma
<EricAnderton youknowthedrill.yahoo> wrote:

Chuck.Esterbrook /at/ gmail /dot/ com wrote:
 Another idea is to write a D-to-D translator. That would be even easier since
 the target language is identical (or in the case of language changes,
 near-identical). The generated D would look different from the original source
 to the extent that debugging aids were turned on and language features had been
 tweaked.


I've thought about something like that myself.  Sort of like an 
aspect-oriented template for a whole source tree, eh?  Composed in an 
abstract fashion, it could be a very versatile tool in its own right.

 Although I feel a little silly proprosing something I don't have time to work
 on. :-)  


Hey, if you've got an hour, just throw a crude specification up on the 
Wiki with "please edit me if you want to contribute" plastered all over 
it.  Odds are you're probably a few more thoughts ahead of the rest of 
us on that idea.

Besides, this newsgroup is positively dreadful for archiving good 
concepts (as our debugger debacle has demonstrated).

 However, I've read references to a D front end. Is that in D?


I've done some hacking there myself.  Its a funny thing: its written in 
C, but most of that code are thinly veiled D-isms.  Picking through the 
source, one gets an impression of why Walter started D in the first 
place.  Eventually, some brave soul will convert this over to D and will 
likely see that its a fairly straightforward task.


I was doing some poking around the news archives and found that
someone already has a d2d translator!

digitalmars.D/26468
http://languagemachine.sourceforge.net/

I haven't tried it out yet, but thought I would add mention of it to
this thread.

-Chuck

John Reimer <terminal.node gmail.com> writes:

Derek Parnell wrote:
 On Tue, 16 Aug 2005 06:34:58 +0000 (UTC), Chuck.Esterbrook /at/ gmail /dot/
 com wrote:
 
 
What debuggers, if any, are people actually using with their DMD programs on
Windows? You know: setting breakpoints, examining a live stack when an error
occurs, etc.


 
 Real Programmers Don't Use Debuggers ;-)
 
 I am a bit of a luddite in this regard. I still use the odd writef() to
 'trace' my code. As a consequence, I only make tiny code changes before
 each test run, in order to limit the debugging focus. Oh, that and unit
 tests.
 
 I suppose if there was a useful interactive GUI debugger that could really
 understand D internals etc ... I might be tempted into the dark side. 
 


Actually, I believe a debugger might be exceptionally useful for D 
program troubleshooting at this point of the game.

D is still beta... A debugger may provide a useful perspective in 
determining d programming aberrations due to language issues.

It can be hard to hunt such problems down otherwise.  Of course, I guess 
we have managed up to this point without one (excepting the marginal 
uses of windbg and the gnu debugger).

-JJR

Hasan Aljudy <hasan.aljudy gmail.com> writes:

Chuck.Esterbrook /at/ gmail /dot/ com wrote:
 What debuggers, if any, are people actually using with their DMD programs on
 Windows? You know: setting breakpoints, examining a live stack when an error
 occurs, etc.
 
 Does the one with DMC work with DMD executables?
 http://www.digitalmars.com/ugr/chapter23.html
 
 
 Thanks,
 -Chuck
 
 


Someone mentioned (probably along time ago) debugging with MSVC 6

http://www.prowiki.org/wiki4d/wiki.cgi?EditorSupport#MicrosoftVisualC60

I don't know if that still applies.

zwang <nehzgnaw gmail.com> writes:

Chuck.Esterbrook /at/ gmail /dot/ com wrote:
 What debuggers, if any, are people actually using with their DMD programs on
 Windows? You know: setting breakpoints, examining a live stack when an error
 occurs, etc.
 
 Does the one with DMC work with DMD executables?
 http://www.digitalmars.com/ugr/chapter23.html
 
 
 Thanks,
 -Chuck
 
 


I used MSVC6 and OpenWatcom Windows debugger before I wrote up a logging 
module plus a testing framework which enabled me to locate bugs quickly 
without the need of a full-fledged debugger.

Chuck Esterbrook <Chuck.Esterbrook gmail.antispam.com> writes:

On Tue, 16 Aug 2005 23:04:47 +0800, zwang <nehzgnaw gmail.com> wrote:

Chuck.Esterbrook /at/ gmail /dot/ com wrote:
 What debuggers, if any, are people actually using with their DMD programs on
 Windows? You know: setting breakpoints, examining a live stack when an error
 occurs, etc.
 
 Does the one with DMC work with DMD executables?
 http://www.digitalmars.com/ugr/chapter23.html
 
 
 Thanks,
 -Chuck
 
 


I used MSVC6 and OpenWatcom Windows debugger before I wrote up a logging 
module plus a testing framework which enabled me to locate bugs quickly 
without the need of a full-fledged debugger.


Would you care to share your logging module and testing framework?

And regardless, can you say what your testing framework provides that
the unittest { } feature does not?

Thanks,
Chuck

Hasan Aljudy <hasan.aljudy gmail.com> writes:

Chuck.Esterbrook /at/ gmail /dot/ com wrote:
 What debuggers, if any, are people actually using with their DMD programs on
 Windows? You know: setting breakpoints, examining a live stack when an error
 occurs, etc.
 
 Does the one with DMC work with DMD executables?
 http://www.digitalmars.com/ugr/chapter23.html
 
 
 Thanks,
 -Chuck
 
 


I started lurking around trying to figure out how to do basic debugging 
on windows ..

You can actually use WinDbg to step through the source code and set 
break points.

First you're gonna have to download some debugging tools for windows:
http://www.microsoft.com/whdc/devtools/debugging/installx86.mspx

you can use cdb from the command line or you windbg (gui wrapper around 
cdb).

Before you use cdb you need to add its path to the system path variable.

Now to show an example of stepping through the code:
setup a directory and create a .d file in it (I called it test.d) and 
just write some code, like:
<code>
import std.stdio;

void main()
{
	writefln("hello world!");
	writefln("line 2");
	writefln("this is the third line!");
	writefln("4th line");
}
</code>
compile it with -g and -debug
#dmd test.d -g -debug
that should create a test.exe for you
now load it with cdb
#cdb test
you'll see some crap which you can ignore for now.

what we want is to start at the program's main() function and step 
through lines one by one.

by default, cdb will be in "assembly mode", i.e. it will show you 
assembly commands and memore offsets, instead of source lines.

we can issue few commands to cdb to switch to "source mode".
#l+l
#l+s
#l+t
#l+o
#.lines

there is still another thing .. cdb doesn't know what is our source 
file, so we have to tell it to load it
#lsf test.d

next, set a break point at the program's start, which btw is _Dmain, not 
main
#bp _Dmain
and you can ignore error messeges.

now let the program run till it reaches that break point:
#g

now you can step through with
#p

and step inside functions with
#t

if you press Enter on the keyboard, the last command will be repeated.

That's all I could figure out by now.

You can do the same things with windbg.

open WinDbg, and go
File->Open Source file
and load test.d
then
File->Open Executable
and load test.exe

ignore the workspace dialoge (choose anything .. yes or no .. I don't 
know what that does).
Then
View->Command

Then make sure that
Debug -> Source Mode
is checked. (that takes care of all the l+ options)

now, in the command window set the break point to _Dmain like last time 
and run the program
#bp _Dmain
#g

now you can use the GUI buttons to step through the code.

One thing I noticed, if you declare a variable but never use it, the 
line numbers will be off by one.

Hasan Aljudy <hasan.aljudy gmail.com> writes:

Hasan Aljudy wrote:
 Chuck.Esterbrook /at/ gmail /dot/ com wrote:
 
 What debuggers, if any, are people actually using with their DMD 
 programs on
 Windows? You know: setting breakpoints, examining a live stack when an 
 error
 occurs, etc.

 Does the one with DMC work with DMD executables?
 http://www.digitalmars.com/ugr/chapter23.html


 Thanks,
 -Chuck


 I started lurking around trying to figure out how to do basic debugging 
 on windows ..
 
 You can actually use WinDbg to step through the source code and set 
 break points.
 
 First you're gonna have to download some debugging tools for windows:
 http://www.microsoft.com/whdc/devtools/debugging/installx86.mspx
 
 you can use cdb from the command line or you windbg (gui wrapper around 
 cdb).
 
 Before you use cdb you need to add its path to the system path variable.
 
 Now to show an example of stepping through the code:
 setup a directory and create a .d file in it (I called it test.d) and 
 just write some code, like:
 <code>
 import std.stdio;
 
 void main()
 {
     writefln("hello world!");
     writefln("line 2");
     writefln("this is the third line!");
     writefln("4th line");
 }
 </code>
 compile it with -g and -debug
 #dmd test.d -g -debug
 that should create a test.exe for you
 now load it with cdb
 #cdb test
 you'll see some crap which you can ignore for now.
 
 what we want is to start at the program's main() function and step 
 through lines one by one.
 
 by default, cdb will be in "assembly mode", i.e. it will show you 
 assembly commands and memore offsets, instead of source lines.
 
 we can issue few commands to cdb to switch to "source mode".
 #l+l
 #l+s
 #l+t
 #l+o
 #.lines
 
 there is still another thing .. cdb doesn't know what is our source 
 file, so we have to tell it to load it
 #lsf test.d
 
 next, set a break point at the program's start, which btw is _Dmain, not 
 main
 #bp _Dmain
 and you can ignore error messeges.
 
 now let the program run till it reaches that break point:
 #g
 
 now you can step through with
 #p
 
 and step inside functions with
 #t
 
 if you press Enter on the keyboard, the last command will be repeated.
 
 That's all I could figure out by now.
 
 You can do the same things with windbg.
 
 open WinDbg, and go
 File->Open Source file
 and load test.d
 then
 File->Open Executable
 and load test.exe
 
 ignore the workspace dialoge (choose anything .. yes or no .. I don't 
 know what that does).
 Then
 View->Command
 
 Then make sure that
 Debug -> Source Mode
 is checked. (that takes care of all the l+ options)
 
 now, in the command window set the break point to _Dmain like last time 
 and run the program
 #bp _Dmain
 #g
 
 now you can use the GUI buttons to step through the code.
 
 One thing I noticed, if you declare a variable but never use it, the 
 line numbers will be off by one.


aw, a little correction: you don't need the lsf command .. cdb will know 
which source files it needs.

"ElfQT" <dethjunk yahoo.com> writes:

I'm using Visual Studio 2003, and Open Watcom Debugger 1.3.
VS is unable show any compound variables, Watcom is able, but for some
unknown reason to me, Watcom shows different (improper) float values.

Here's a link to a VS solution and project - you can build and debug D in VS
with that.
(If you want to add new file, add it manually by modifying .vcproj <Files>
section.
And of course, you have to modify the path to dmd.exe, if needed.)

http://elfqt.simeis.hu/szallit/D/D_VS_sampleSln.zip

(By the way, I also managed to port the first five DirectX D3D tutorials to
D. If anyone interested, let me know and I will upload.)

ElfQT

"Chuck.Esterbrook /at/ gmail /dot/ com"
<Chuck.Esterbrook_member pathlink.com> wrote in message
news:dds1ei$2ff9$1 digitaldaemon.com...
 What debuggers, if any, are people actually using with their DMD programs


 Windows? You know: setting breakpoints, examining a live stack when an


 occurs, etc.

 Does the one with DMC work with DMD executables?
 http://www.digitalmars.com/ugr/chapter23.html


 Thanks,
 -Chuck