Jascha Wetzel wrote:
> Daniel Keep wrote:
>> Messy, but it works.  I'd kill to have a better debugging environment, but I somehow doubt that's going to happen.  *sigh*
> 
> i'd suggest http://ddbg.mainia.de/
> i might go as far as to claim that it's
> better than windbg.

Clearly you have an unbiased opinion on the matter :P

The problem with ddbg is that it doesn't have the... well, I can't say "nice" since the windbg GUI is rubbish... GUI that windbg offers.  I always tend to get lost with the interactive text debuggers. [1]

The *second* problem is that I'm coding in DWEB.  What happens here is that my source .dw file is tangled into a .d file, which is then compiled.  So when I go to debug, instead of displaying the line in my original source file, it displays the line in the horrific, unreadable mess that is the .d file.

Basically, every single time I recompile, I have to go in, delete the .d files, and copy the .dw files to .d files in order to get the right lines to show up. [2]

So yeah; debugging at the moment is a major pain the posterior.  I doubt ddbg would help, but in all fairness, it wasn't designed for quite my circumstances :P

Thankfully though, windbg doesn't seem to care so long as the debugging information is present.

	-- Daniel

[1] That said, ddbg works beautifully with Code::Blocks.  A pity, then, that Code::Blocks is incapable of passing arguments to the D compiler at the moment, which makes it totally useless... -_-

Also a pity that probably can't even understand my particular source files (see second problem above).

[2] Yes, D encodes the *correct* line number, but the *wrong* filename!
 I posted a request to fix this, and never got a single reply :'(

-- 
int getRandomNumber()
{
    return 4; // chosen by fair dice roll.
              // guaranteed to be random.
}

http://xkcd.com/

v2sw5+8Yhw5ln4+5pr6OFPma8u6+7Lw4Tm6+7l6+7D i28a2Xs3MSr2e4/6+7t4TNSMb6HTOp5en5g6RAHCP  http://hackerkey.com/

Daniel Keep wrote:
> Clearly you have an unbiased opinion on the matter :P

obviously ;)

> The problem with ddbg is that it doesn't have the... well, I can't say "nice" since the windbg GUI is rubbish... GUI that windbg offers.  I always tend to get lost with the interactive text debuggers. [1]

i also use GUIs for debugging, since i feel the command line isn't
concise enough when debugging larger programs.
i didn't write a GUI for ddbg, though, because they are a matter of
taste and it's more flexible to have a debugger that integrates in
different GUIs. that said, as of now, there clearly aren't enough GUIs
you can use ddbg with (codeblocks and zeus only afaik). but codeblocks
appears to be quite solid atm.

> The *second* problem is that ... my source .dw file is tangled into a .d file ...

i could easily add an option to ddbg that will take care of that. i just
wonder: are the lines in the .dw files the same as in the .d files, just
with code added on the same line? else the line numbers couldn't be the
same.
with translation of the file extension, you should also be able to use
codeblocks to debug .dw files.

> [1] That said, ddbg works beautifully with Code::Blocks.  A pity, then, that Code::Blocks is incapable of passing arguments to the D compiler at the moment, which makes it totally useless... -_-

hm, i may misunderstand you, but there's a text field where you can add
any option that will be passed on to DMD in build options > compiler
settings > other options - this is per target.
there can also be custom build commands per file.


> Also a pity that probably can't even understand my particular source files (see second problem above).

if by "understand" you mean syntax sensitive editing stuff, the .dw extension can be added in settings > editor > syntax highlighting > filemasks. these filemasks are also used for goto function, code completion etc.

Jascha Wetzel wrote:
> Daniel Keep wrote:
>> Clearly you have an unbiased opinion on the matter :P
> 
> obviously ;)
> 
>> The problem with ddbg is that it doesn't have the... well, I can't say "nice" since the windbg GUI is rubbish... GUI that windbg offers.  I always tend to get lost with the interactive text debuggers. [1]
> 
> i also use GUIs for debugging, since i feel the command line isn't concise enough when debugging larger programs.

For me, it's more a case of "what the hell line am I on?"  "what are my local variables?"  "what's the value of that damn global now?" etcetera :)

> i didn't write a GUI for ddbg, though, because they are a matter of taste and it's more flexible to have a debugger that integrates in different GUIs. that said, as of now, there clearly aren't enough GUIs you can use ddbg with (codeblocks and zeus only afaik). but codeblocks appears to be quite solid atm.

Hopefully we'll see more support for ddbg; it's pretty much *the* best debugging tool for D in existence--certainly the only one targeted at D specifically.

>> The *second* problem is that ... my source .dw file is tangled into a .d file ...
> 
> i could easily add an option to ddbg that will take care of that. i just
> wonder: are the lines in the .dw files the same as in the .d files, just
> with code added on the same line? else the line numbers couldn't be the
> same.
> with translation of the file extension, you should also be able to use
> codeblocks to debug .dw files.

Not even close.  CWEB (and DWEB, which is based on CWEB) are for literate programming.  Here's a sample:

> @ Now we'll deal with the peep's schedule.  For the sake of simplicity, this model assumes that every person in the universe has a uniform nine-to-five work day.  All we need to do is watch out for when the simulation ticks past 9:00 AM and 5:00 PM, and act accordingly.
>
> @<Process peep's schedule@>=
>     if( sim.data.advancedToTime(9,0) )
>     {
>         peepId.moveTo(params.work);
>     }
>     else if( sim.data.advancedToTime(17,0) )
>     {
>         peepId.moveTo(params.home);
>     }

The first part is a (sometimes very verbose) explanation of the code, what it's for, etc. and is written using TeX.  Then we have a named section, and its contents.

The advantage of all this is that I can use "dweave foo && pdftex foo" to produce a perfectly typeset PDF book of the source code, and "dtangle foo" to produce a compilable source file.  This is very handy given that the implementation of my project basically becomes the bulk of my honours thesis: I just have to weave the source files, stick them together with the rest of the thesis and have it printed off.

But the best part (re: the discussion at hand)?  This isn't even necessarily linear; I can use the @<Process peep's schedule@> section anywhere else in my code, potentially multiple times.  Works a bit like a #define.

Here's what the above becomes in the .d file:

> /*13:*/
> #line 148 "simple.dw"
>
> if(sim.data.advancedToTime(9,0))
> {
> peepId.moveTo(params.work);
> }
> else if(sim.data.advancedToTime(17,0))
> {
> peepId.moveTo(params.home);
> }

Section 13, sourced from line 148 of simple.dw.  That starts on line 137 of simple.d.  Also, for some reason that escapes me, Knuth saw fit to remove all whitespace when it outputs the code. [1]

Which is what's weird: DMD outputs the correct line number, but the *wrong filename*, which is really what's causing problems.

>> [1] That said, ddbg works beautifully with Code::Blocks.  A pity, then, that Code::Blocks is incapable of passing arguments to the D compiler at the moment, which makes it totally useless... -_-
> 
> hm, i may misunderstand you, but there's a text field where you can add
> any option that will be passed on to DMD in build options > compiler
> settings > other options - this is per target.
> there can also be custom build commands per file.

Yes, the option is there, but in the builds I've used, it doesn't work.
 Basically, Code::Blocks chews up any additional options you add, and
dumps them into the "Defines" section... which isn't used by DMD, so the
options are ignored.  I've already filed a ticket on it, so it will
hopefully be fixed sometime soon.

>> Also a pity that probably can't even understand my particular source files (see second problem above).
> 
> if by "understand" you mean syntax sensitive editing stuff, the .dw extension can be added in settings > editor > syntax highlighting > filemasks. these filemasks are also used for goto function, code completion etc.

As you can see above, getting it to highlight the D code is the easy part.  Getting it to highlight the *TeX* code at the same time, let alone make *sense* of the file; that's the hard part ;)

FYI, I'm currently using a hacked version of VIM's CWEB syntax files, modified to load the D syntax file instead of the C one, so the highlighting mostly works.  I've never really missed the code completion stuff: I have all my code modules as indexed and cross-referenced PDFs :P

	-- Daniel

[1] Even more fun: [0..5] gets turned into [0. .5] which is interpreted as [0.0 0.5], and you can't enter imaginary numbers *at all* without escaping them!  I really should get around to fixing DWEB; at the moment it's basically just modified to read in .dw files instead of .w, and output .d instead of .c.

-- 
int getRandomNumber()
{
    return 4; // chosen by fair dice roll.
              // guaranteed to be random.
}

http://xkcd.com/

v2sw5+8Yhw5ln4+5pr6OFPma8u6+7Lw4Tm6+7l6+7D i28a2Xs3MSr2e4/6+7t4TNSMb6HTOp5en5g6RAHCP  http://hackerkey.com/

Jascha Wetzel wrote:
>> [1] That said, ddbg works beautifully with Code::Blocks.  A pity, then,
>> that Code::Blocks is incapable of passing arguments to the D compiler at
>> the moment, which makes it totally useless... -_-

I am trying to get dmd/ddbg/cblocks working at the moment. It seems to compile and link ok, and if I run my program from the command line it works:

hello world
args.length = 1
args[0] = 'C:\d\hworld\bin\Debug\hworld.exe'

....but when I try to step in (having set up ddbg_gdb.exe as the debugger), it just terminates, with this in the output window:

Building to ensure sources are up-to-date
Build succeeded
Selecting target: Debug
Adding source dir: c:\d\hworld\
Adding source dir: c:\d\hworld\
Adding file: bin\Debug\hworld.exe
Starting debugger: done
Registered new type: wxString
Registered new type: STL String
Registered new type: STL Vector
Setting breakpoints
Program exited
Debugger finished with status 0

...can someone please shed light on why the debugger is not playing ball?

Thanks

-P

PS Code::Blocks looks like a worthy replacement for Visual Studio, if only I could get the debugger working.....

Patrick Byrne wrote:
> Jascha Wetzel wrote:
>>> [1] That said, ddbg works beautifully with Code::Blocks.  A pity, then, that Code::Blocks is incapable of passing arguments to the D compiler at the moment, which makes it totally useless... -_-
> 
> I am trying to get dmd/ddbg/cblocks working at the moment. It seems to compile and link ok, and if I run my program from the command line it works:
> 
> hello world
> args.length = 1
> args[0] = 'C:\d\hworld\bin\Debug\hworld.exe'
> 
> .....but when I try to step in (having set up ddbg_gdb.exe as the debugger), it just terminates, with this in the output window:
> 
> Building to ensure sources are up-to-date
> Build succeeded
> Selecting target: Debug
> Adding source dir: c:\d\hworld\
> Adding source dir: c:\d\hworld\
> Adding file: bin\Debug\hworld.exe
> Starting debugger: done
> Registered new type: wxString
> Registered new type: STL String
> Registered new type: STL Vector
> Setting breakpoints
> Program exited
> Debugger finished with status 0
> 
> ....can someone please shed light on why the debugger is not playing ball?
> 
> Thanks
> 
> -P
> 
> PS Code::Blocks looks like a worthy replacement for Visual Studio, if only I could get the debugger working.....

IIRC, there are a number of things you need to do to get DDBG to work in Code::Blocks.  The two that I can remember off the top of my head are:

1.  Make sure you have "gdb" in ddbg's filename somewhere.  I just copied ddbg.exe to ddbg_gdb.exe, and told CB to use that.

2.  Code::Block's D template is a little iffy atm.  You need to go in to linker options and add the '-g' switch; can't remember where, exactly. The reason is that dmd is both compiler and linker, and it seems that if you link debug code without '-g', OPTLINK will actually drop the debugging info.

Hope that helps :)

	-- Daniel

-- 
int getRandomNumber()
{
    return 4; // chosen by fair dice roll.
              // guaranteed to be random.
}

http://xkcd.com/

v2sw5+8Yhw5ln4+5pr6OFPma8u6+7Lw4Tm6+7l6+7D i28a2Xs3MSr2e4/6+7t4TNSMb6HTOp5en5g6RAHCP  http://hackerkey.com/

Daniel Keep wrote:
> 1.  Make sure you have "gdb" in ddbg's filename somewhere.  I just
> copied ddbg.exe to ddbg_gdb.exe, and told CB to use that.
> 
> 2.  Code::Block's D template is a little iffy atm.  You need to go in to
> linker options and add the '-g' switch; can't remember where, exactly.
> The reason is that dmd is both compiler and linker, and it seems that if
> you link debug code without '-g', OPTLINK will actually drop the
> debugging info.

Thanks very much! Unfortunately, I had already scraped this info from the forums/webpages, and even with this set it isn't working.    :-(

I shall re-post this problem shortly to the ...debugger forum, in case people would rather it lived there.

-P

check settings > compiler and debugger > debugger settings > display
debugger's log
you'll have a message tab "Debugger (debug)" which displays almost all
of the communication between codeblocks and ddbg.
ddbg will probably give a more verbose error message that you'll find there.
alternatively you can also try debugging your program on the command
line to find the problem.

you may have to consider that codeblocks compiles and links in separate steps. therefore compiler and linker need to have the -g option. you have to add the -g switch manually in the build options for the linker.

also note, that you need codeblocks nightly build from 2007-03-19 or newer for stepping to work correctly.

Patrick Byrne wrote:
> Jascha Wetzel wrote:
>>> [1] That said, ddbg works beautifully with Code::Blocks.  A pity, then, that Code::Blocks is incapable of passing arguments to the D compiler at the moment, which makes it totally useless... -_-
> 
> I am trying to get dmd/ddbg/cblocks working at the moment. It seems to compile and link ok, and if I run my program from the command line it works:
> 
> hello world
> args.length = 1
> args[0] = 'C:\d\hworld\bin\Debug\hworld.exe'
> 
> ....but when I try to step in (having set up ddbg_gdb.exe as the debugger), it just terminates, with this in the output window:
> 
> Building to ensure sources are up-to-date
> Build succeeded
> Selecting target: Debug
> Adding source dir: c:\d\hworld\
> Adding source dir: c:\d\hworld\
> Adding file: bin\Debug\hworld.exe
> Starting debugger: done
> Registered new type: wxString
> Registered new type: STL String
> Registered new type: STL Vector
> Setting breakpoints
> Program exited
> Debugger finished with status 0
> 
> ...can someone please shed light on why the debugger is not playing ball?
> 
> Thanks
> 
> -P
> 
> PS Code::Blocks looks like a worthy replacement for Visual Studio, if only I could get the debugger working.....

Daniel Keep wrote:

> [1] That said, ddbg works beautifully with Code::Blocks.  A pity, then,
> that Code::Blocks is incapable of passing arguments to the D compiler at
> the moment, which makes it totally useless... -_-

If you're talking about Bug #10658, it'll get fixed shortly...

See http://forums.codeblocks.org/index.php/topic,5553.0.html

--anders

Frits van Bommel wrote:
> Daniel Keep wrote:
>> The *second* problem is that I'm coding in DWEB.  What happens here is that my source .dw file is tangled into a .d file, which is then compiled.  So when I go to debug, instead of displaying the line in my original source file, it displays the line in the horrific, unreadable mess that is the .d file.
>>
>> Basically, every single time I recompile, I have to go in, delete the .d files, and copy the .dw files to .d files in order to get the right lines to show up. [2]
> [snip]
>> [2] Yes, D encodes the *correct* line number, but the *wrong* filename!
>>  I posted a request to fix this, and never got a single reply :'(
> 
> Do the .d files contain the correct "#line" token sequences?
> I.e. something like '#line 6 "myfile.dw"' (_including_ the file name)?
> If so then DMD _should_ generate the correct debug info (according to
> http://www.digitalmars.com/d/lex.html#specialtokens).
> I haven't tested this, among other things because it probably wouldn't
> mean much since I'm not using Windows and debug info is different on Linux.

You know, I just tried this on a small test program, and it worked! Which is strange since it's never worked before...  the only thing that didn't work properly was that it couldn't find source files for modules in subdirectories, which always worked before (albeit choosing the .d file instead of the .dw file).

How bizarre.  Once I've finished with the current refactoring, I'll give debugging another shot and see if something's magically changed since the last time I used it.

Typical.  It doesn't work until I tell someone, and then it works.  If I didn't know better, I'd say either windbg or dmd is doing this to spite me :P

	-- Daniel

-- 
int getRandomNumber()
{
    return 4; // chosen by fair dice roll.
              // guaranteed to be random.
}

http://xkcd.com/

v2sw5+8Yhw5ln4+5pr6OFPma8u6+7Lw4Tm6+7l6+7D i28a2Xs3MSr2e4/6+7t4TNSMb6HTOp5en5g6RAHCP  http://hackerkey.com/

Anders F Björklund wrote:
> Daniel Keep wrote:
> 
>> [1] That said, ddbg works beautifully with Code::Blocks.  A pity, then, that Code::Blocks is incapable of passing arguments to the D compiler at the moment, which makes it totally useless... -_-
> 
> If you're talking about Bug #10658, it'll get fixed shortly...
> 
> See http://forums.codeblocks.org/index.php/topic,5553.0.html
> 
> --anders

Yup, that's mine :)

Glad to hear they've got a fix for it[1].  There's a project I've been thinking about that would *seriously* benefit from having a proper IDE with debugging support...

	-- Daniel

[1] Actually, make that *impressed*.

-- 
int getRandomNumber()
{
    return 4; // chosen by fair dice roll.
              // guaranteed to be random.
}

http://xkcd.com/

v2sw5+8Yhw5ln4+5pr6OFPma8u6+7Lw4Tm6+7l6+7D i28a2Xs3MSr2e4/6+7t4TNSMb6HTOp5en5g6RAHCP  http://hackerkey.com/