How to debug in Visual studio?

[Daniel Keep]

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/