www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Debugger for D?

reply 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
Aug 15 2005
next sibling parent reply 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
Aug 15 2005
next sibling parent reply 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
Aug 16 2005
next sibling parent reply "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
Aug 16 2005
parent reply 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
Aug 16 2005
parent reply "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

Aug 16 2005
parent reply "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


Aug 16 2005
next sibling parent reply "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



Aug 16 2005
parent reply "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




Aug 16 2005
next sibling parent "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





Aug 16 2005
prev sibling parent reply 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.
Aug 16 2005
parent reply "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.
Aug 16 2005
parent 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.
Aug 16 2005
prev sibling next sibling parent reply 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
Aug 17 2005
parent "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

Aug 17 2005
prev sibling parent 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



Aug 18 2005
prev sibling parent reply 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.
Aug 16 2005
parent reply 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
Aug 16 2005
parent reply 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
Aug 17 2005
parent 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
Aug 25 2005
prev sibling parent 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
Aug 17 2005
prev sibling next sibling parent 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.
Aug 16 2005
prev sibling next sibling parent reply 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.
Aug 16 2005
parent 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
Aug 24 2005
prev sibling next sibling parent reply 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.
Aug 16 2005
parent 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.
Aug 16 2005
prev sibling parent "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

Aug 17 2005