Wasnt someone ( Frank ? ) planning on writing one ?  Hows that coming ?

C

"Matthew Wilson" <matthew@stlsoft.org> wrote in message news:bmfauf$9b0$1@digitaldaemon.com...
> As the originator of this thread, I'd just like to say that I believe in assertions, and I also use a debugger. If D had one, I'd use it, even
though
> I've managed well without one so far. I know that D will be more
acceptable
> to the wider dev community when it has a debugger.
>
> Arguing for only debugger or only assertions is a bit like arguing one programming language fits all.
>
>
>
> "Philippe Mori" <philippe_mori@hotmail.com> wrote in message news:bmfa4s$85h$1@digitaldaemon.com...
> > >
> > > The code does what you tell it to do. In practice it's very hard to
have
> a
> > > bug both in the contract and the code. In this case debugging won't
help
> > > because you won't know you have a problem. Of course you need to have
a
> > > contract with an implementation different from the body, otherwise
> you're
> > > just wasting time.
> > >
> >
> > Even if we try to put a lot of assertions (and design by contract) in
the
> > code,
> > we might simply not do some check either because they are difficult to
do
> > (or expensive to execute) or because we forget to do a check or think the code is so simple that no check are necessary.
> >
> > When debugging step by step the code, we can often see some errors very easily (a corrupted string, an unexpoected value for a float like 1e20 that also never happen in practice, wrong function called, breakpoint not hit,...)
> >
> > What I would also like from a debugger would be the ability to very easily add variables to the log... since often we otherwise write a
bunch
> > of information on paper while debugging...
> >
> > Philippe
> >
> >
>
>

Is there any decent free x86 debugger we could point people at maybe?  Maybe we could work to make it work better with D.

Sean

"Matthew Wilson" <matthew@stlsoft.org> wrote in message news:bmfauf$9b0$1@digitaldaemon.com...
> As the originator of this thread, I'd just like to say that I believe in assertions, and I also use a debugger. If D had one, I'd use it, even
though
> I've managed well without one so far. I know that D will be more
acceptable
> to the wider dev community when it has a debugger.
>
> Arguing for only debugger or only assertions is a bit like arguing one programming language fits all.

Local variables won't work yet :-( but at least you should be getting line numbers and function names.

"Jan-Eric Duden" <jeduden@whisset.com> wrote in message news:bma39a$2eno$1@digitaldaemon.com...
> Ok. Ill try that. I got some debugging to work yesterday night.
> But I couldn't see the local variables :(
> I guess I will need to look further into it.
> --
> Jan-Eric Duden
> "Walter" <walter@digitalmars.com> wrote in message
> news:bm9reg$2468$4@digitaldaemon.com...
> >
> > "Jan-Eric Duden" <jeduden@whisset.com> wrote in message news:bm76h3>
> >
>
c:\dmd\bin\dmd.exe -g -gt -debug -odC:\PROGRA~1\DIDE\Projects\T -version=Win
> >
> >
> > Don't use -gt for debugging, that is for doing profiling.
> >
> >
>
>

"Daniel Yokomiso" <daniel_yokomiso@yahoo.com.br> wrote in message news:bma1tm$2cub$1@digitaldaemon.com...
> > And another thing: you can easily get carried away by peppering your code with assertions everywhere. This may be nice from a theoretical point of view, but there IS the problem that when you're writing assertions you don't write code that actually adds functionality. Sure, the code you DO write may be less buggy, but there is a fine line between writing useful assertions and wasting time.
> A system with a thousand of buggy features do less than a system with one reliable feature. Assertions aren't a "theoretical" tool, they're
practical
> and much better than banging out code that "can't fail because it's too simple". There are lot's of statistics saying that programmers don't write more than x lines of code (where x is usually between 20 and 50) per day,
so
> adding a few assertions won't take much of your time. Even if you are a master coder you will have some periods when you're just thinking about
how
> to write some feature, and in this moment you should write down your assumptions (i.e. pre/postconditions and invariants) as part of the
feature
> design.

I've been using asserts for years with great success. They've proved invaluable, which is what spawned my interest in DbC in the first place.

"Walter" <walter@digitalmars.com> wrote in message news:bmob7v$50e$1@digitaldaemon.com...
>
> "Daniel Yokomiso" <daniel_yokomiso@yahoo.com.br> wrote in message news:bma1tm$2cub$1@digitaldaemon.com...
> > > And another thing: you can easily get carried away by peppering your code with assertions everywhere. This may be nice from a theoretical point of view, but there IS the problem that when you're writing assertions you don't write code that actually adds functionality.
Sure,
> > > the code you DO write may be less buggy, but there is a fine line between writing useful assertions and wasting time.
> > A system with a thousand of buggy features do less than a system with
one
> > reliable feature. Assertions aren't a "theoretical" tool, they're
> practical
> > and much better than banging out code that "can't fail because it's too simple". There are lot's of statistics saying that programmers don't
write
> > more than x lines of code (where x is usually between 20 and 50) per
day,
> so
> > adding a few assertions won't take much of your time. Even if you are a master coder you will have some periods when you're just thinking about
> how
> > to write some feature, and in this moment you should write down your assumptions (i.e. pre/postconditions and invariants) as part of the
> feature
> > design.
>
> I've been using asserts for years with great success. They've proved invaluable, which is what spawned my interest in DbC in the first place.

We're still going to need a debugger. Different people have different development practises, and if D does not cater to them all, it will lose the ones it doesn't.

Ahhh... Ok, then I got it :).
What is actually missing? The PDB file?
-- 
Jan-Eric Duden
"Walter" <walter@digitalmars.com> wrote in message
news:bmnm5m$2aks$2@digitaldaemon.com...
> Local variables won't work yet :-( but at least you should be getting line numbers and function names.
>
> "Jan-Eric Duden" <jeduden@whisset.com> wrote in message news:bma39a$2eno$1@digitaldaemon.com...
> > Ok. Ill try that. I got some debugging to work yesterday night.
> > But I couldn't see the local variables :(
> > I guess I will need to look further into it.
> > --
> > Jan-Eric Duden
> > "Walter" <walter@digitalmars.com> wrote in message
> > news:bm9reg$2468$4@digitaldaemon.com...
> > >
> > > "Jan-Eric Duden" <jeduden@whisset.com> wrote in message news:bm76h3>
> > >
> >
>
c:\dmd\bin\dmd.exe -g -gt -debug -odC:\PROGRA~1\DIDE\Projects\T -version=Win
> > >
> > >
> > > Don't use -gt for debugging, that is for doing profiling.
> > >
> > >
> >
> >
>
>

You can use windbg.exe from Microsoft. I think it comes free with MSDN. It also comes on the DMC++ CD.

"Sean L. Palmer" <palmer.sean@verizon.net> wrote in message news:bmgh8n$1sa7$1@digitaldaemon.com...
> Is there any decent free x86 debugger we could point people at maybe?
Maybe
> we could work to make it work better with D.