www.digitalmars.com         C & C++   DMDScript  

D - Assert stacks

reply "Matthew Wilson" <matthew stlsoft.org> writes:
I know this has been said before, but having some stack trace in an
assertion would be *very* useful
Oct 09 2003
next sibling parent reply "Jan-Eric Duden" <jeduden whisset.com> writes:
Being able to debug would help too... :)

-- 
Jan-Eric Duden
"Matthew Wilson" <matthew stlsoft.org> wrote in message
news:bm544r$1pk0$1 digitaldaemon.com...

 I know this has been said before, but having some stack trace in an
 assertion would be *very* useful
Oct 10 2003
next sibling parent reply "Matthew Wilson" <matthew stlsoft.org> writes:
I suppose, D is sufficiently "high-level" that I've not yet really felt the
need. If it had assert and exception stacks, I may never feel that need. ;)

"Jan-Eric Duden" <jeduden whisset.com> wrote in message
news:bm5mh1$2jd9$1 digitaldaemon.com...

 Being able to debug would help too... :)

 -- 
 Jan-Eric Duden
 "Matthew Wilson" <matthew stlsoft.org> wrote in message
 news:bm544r$1pk0$1 digitaldaemon.com...

 I know this has been said before, but having some stack trace in an
 assertion would be *very* useful
Oct 10 2003
parent reply "Jan-Eric Duden" <jeduden whisset.com> writes:
Sure, D is high-level, but don't you make mistakes modelling an algorithm?

Debugging helps, it takes you by your hand, and goes with you through the
algorithm step by step.
that's easier and faster than putting assertions after every statement.

And after all, D is suposed to make our lives better :), but it doesn't
improve mine without a debugger :(.
-- 
Jan-Eric Duden
"Matthew Wilson" <matthew stlsoft.org> wrote in message
news:bm5nk1$2kpi$1 digitaldaemon.com...

 I suppose, D is sufficiently "high-level" that I've not yet really felt


the

 need. If it had assert and exception stacks, I may never feel that need.


;)

 "Jan-Eric Duden" <jeduden whisset.com> wrote in message
 news:bm5mh1$2jd9$1 digitaldaemon.com...

 Being able to debug would help too... :)

 -- 
 Jan-Eric Duden
 "Matthew Wilson" <matthew stlsoft.org> wrote in message
 news:bm544r$1pk0$1 digitaldaemon.com...

 I know this has been said before, but having some stack trace in an
 assertion would be *very* useful
Oct 10 2003
next sibling parent "Matthew Wilson" <matthew stlsoft.org> writes:
"Jan-Eric Duden" <jeduden whisset.com> wrote in message
news:bm5vhd$2uo8$1 digitaldaemon.com...

 Sure, D is high-level, but don't you make mistakes modelling an algorithm?


Never!

Well, sometimes, maybe. But don't tell anyone!


 Debugging helps, it takes you by your hand, and goes with you through the
 algorithm step by step.
 that's easier and faster than putting assertions after every statement.


Indeed. I am a big fan of the debugger. That's why I've been stuck to the
Visual Studio 97/98 IDE for the last 6 years. Nothing else is as powerful +
as efficient to use. In other words, *all* the other IDEs that I've used -
which is a lot - make you take your hands off the keyboard. Maybe that's why
some developers are proven to be up to 30 times as productive as others,
they're using IDEs that can be run entirely from the keyboard?


 And after all, D is suposed to make our lives better :), but it doesn't
 improve mine without a debugger :(.


I wasn't saying I won't need one, just that I haven't yet. I too would like
a debugger


 Jan-Eric Duden
 "Matthew Wilson" <matthew stlsoft.org> wrote in message
 news:bm5nk1$2kpi$1 digitaldaemon.com...

 I suppose, D is sufficiently "high-level" that I've not yet really felt


 the

 need. If it had assert and exception stacks, I may never feel that need.


 ;)

 "Jan-Eric Duden" <jeduden whisset.com> wrote in message
 news:bm5mh1$2jd9$1 digitaldaemon.com...

 Being able to debug would help too... :)

 -- 
 Jan-Eric Duden
 "Matthew Wilson" <matthew stlsoft.org> wrote in message
 news:bm544r$1pk0$1 digitaldaemon.com...

 I know this has been said before, but having some stack trace in an
 assertion would be *very* useful
Oct 10 2003
prev sibling parent reply "Daniel Yokomiso" <daniel_yokomiso yahoo.com.br> writes:
"Jan-Eric Duden" <jeduden whisset.com> escreveu na mensagem
news:bm5vhd$2uo8$1 digitaldaemon.com...

 Sure, D is high-level, but don't you make mistakes modelling an algorithm?


Sure that's where design by contract helps you. You write the preconditions
and posconditions of every function, and when you test it the compiler will
do the checks and tell you "The parameter foo should be a list sorted by bar
but wasn't". If you have the contracts for all of your functions you'll
quickly find your bugs.


 Debugging helps, it takes you by your hand, and goes with you through the
 algorithm step by step.
 that's easier and faster than putting assertions after every statement.


It isn't a matter of putting assertions after every statement, instead you
decompose your problem in smaller parts and write the contracts of those
parts. Since I started using unit tests and DbC in my code I don't mess with
the debugger anymore, perhaps once a year to debug third party code ;)


 And after all, D is suposed to make our lives better :), but it doesn't
 improve mine without a debugger :(.

 -- 
 Jan-Eric Duden


[snip]

Best regards,
Daniel Yokomiso.

"...didn't some bloke 2000 years ago write 'before you unwind the for loop
in your brothers code take the unbounded recursion out of your own.'"
 - Mike Wynn


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.524 / Virus Database: 321 - Release Date: 7/10/2003
Oct 10 2003
next sibling parent reply "Jan-Eric Duden" <jeduden whisset.com> writes:
 Debugging helps, it takes you by your hand, and goes with you through




the

 algorithm step by step.
 that's easier and faster than putting assertions after every statement.


 It isn't a matter of putting assertions after every statement, instead you
 decompose your problem in smaller parts and write the contracts of those
 parts. Since I started using unit tests and DbC in my code I don't mess


with

 the debugger anymore, perhaps once a year to debug third party code ;)


If you have a bug in your mind and therefore your model,
then you need to work statement by statement. Unittests only help to see
that there is a bug, but it doesn't help much to locate it.


 ...


Jan-Eric
Oct 10 2003
parent reply "Daniel Yokomiso" <daniel_yokomiso yahoo.com.br> writes:
"Jan-Eric Duden" <jeduden whisset.com> escreveu na mensagem
news:bm65db$507$1 digitaldaemon.com...

 Debugging helps, it takes you by your hand, and goes with you through




 the

 algorithm step by step.
 that's easier and faster than putting assertions after every






statement.

 It isn't a matter of putting assertions after every statement, instead




you

 decompose your problem in smaller parts and write the contracts of those
 parts. Since I started using unit tests and DbC in my code I don't mess


 with

 the debugger anymore, perhaps once a year to debug third party code ;)


 If you have a bug in your mind and therefore your model,
 then you need to work statement by statement. Unittests only help to see
 that there is a bug, but it doesn't help much to locate it.


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.


 ...


 Jan-Eric




---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.524 / Virus Database: 321 - Release Date: 7/10/2003
Oct 10 2003
next sibling parent "Jan-Eric Duden" <jeduden whisset.com> writes:
I was referring to the case where your code perfectly implements the model
and it still doesn't work.

Of course, It would be better to check and debug the model itself with the
standard model checking stuff,
but usually I have the model only in my mind and an implementation of the
model as code.
Since I can't really debug a model in my mind :), I debug the code and see
why the code fails.
Once, I know why the code fails I might also know why my model is wrong.
-- 
Jan-Eric Duden
"Daniel Yokomiso" <daniel_yokomiso yahoo.com.br> wrote in message
news:bm6j16$n3j$1 digitaldaemon.com...

 "Jan-Eric Duden" <jeduden whisset.com> escreveu na mensagem
 news:bm65db$507$1 digitaldaemon.com...

 Debugging helps, it takes you by your hand, and goes with you








through

 the

 algorithm step by step.
 that's easier and faster than putting assertions after every






 statement.

 It isn't a matter of putting assertions after every statement, instead




 you

 decompose your problem in smaller parts and write the contracts of






those

 parts. Since I started using unit tests and DbC in my code I don't






mess

 with

 the debugger anymore, perhaps once a year to debug third party code ;)


 If you have a bug in your mind and therefore your model,
 then you need to work statement by statement. Unittests only help to see
 that there is a bug, but it doesn't help much to locate it.


 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.


 ...


 Jan-Eric




 ---
 Outgoing mail is certified Virus Free.
 Checked by AVG anti-virus system (http://www.grisoft.com).
 Version: 6.0.524 / Virus Database: 321 - Release Date: 7/10/2003
Oct 10 2003
prev sibling parent reply "Philippe Mori" <philippe_mori hotmail.com> writes:
 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
Oct 13 2003
parent reply "Matthew Wilson" <matthew stlsoft.org> writes:
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
Oct 13 2003
next sibling parent "Charles Sanders" <sanders-consulting comcast.net> writes:
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
Oct 13 2003
prev sibling parent reply "Sean L. Palmer" <palmer.sean verizon.net> writes:
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.
Oct 14 2003
parent "Walter" <walter digitalmars.com> writes:
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.
Jan 15 2004
prev sibling parent reply Hauke Duden <H.NS.Duden gmx.net> writes:
Daniel Yokomiso wrote:

 "Jan-Eric Duden" <jeduden whisset.com> escreveu na mensagem
 news:bm5vhd$2uo8$1 digitaldaemon.com...
 

Sure, D is high-level, but don't you make mistakes modelling an algorithm?


 
 
 Sure that's where design by contract helps you. You write the preconditions
 and posconditions of every function, and when you test it the compiler will
 do the checks and tell you "The parameter foo should be a list sorted by bar
 but wasn't". If you have the contracts for all of your functions you'll
 quickly find your bugs.


Hmmm. Contracts cannot be used to find all kinds of errors. To give one 
example: inter-thread behavior. Try to find a deadlock by adding 
contracts to your code.

Besides, contracts have one major drawback. Since the state of a 
sufficiently complex program is very big, you won't be able to check the 
consistency of everything after every operation. So basically you need 
to anticipate what might go wrong in order to be able to write 
meaningful asserts.

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. Sometimes you just 
have to have faith that everything will work as expected and use a 
debugger afterwards if it doesn't.

I'm not saying you shouldn't use assertions. But you need to find a 
balance between coding time and the ability to prove that the code is 
bug-free (or at least that the issues you have anticipated do not occur).

In other words: debugging IS necessary ;).

Hauke
Oct 10 2003
parent reply "Daniel Yokomiso" <daniel_yokomiso yahoo.com.br> writes:
"Hauke Duden" <H.NS.Duden gmx.net> escreveu na mensagem
news:bm6lrg$qtq$1 digitaldaemon.com...

 Daniel Yokomiso wrote:

 "Jan-Eric Duden" <jeduden whisset.com> escreveu na mensagem
 news:bm5vhd$2uo8$1 digitaldaemon.com...


Sure, D is high-level, but don't you make mistakes modelling an






algorithm?

 Sure that's where design by contract helps you. You write the




preconditions

 and posconditions of every function, and when you test it the compiler




will

 do the checks and tell you "The parameter foo should be a list sorted by




bar

 but wasn't". If you have the contracts for all of your functions you'll
 quickly find your bugs.


 Hmmm. Contracts cannot be used to find all kinds of errors. To give one
 example: inter-thread behavior. Try to find a deadlock by adding
 contracts to your code.



We can divide deadlocks in two kinds: deterministic and unpredictable. If
your deadlocks are deterministic they'll always happen so they're easy to
figure out and fix. If they are unpredictable the exact condition to trigger
them depends on race conditions and debugging mess with the timing so it
won't help much here. With some help of the lock classes you can create
asserts to ensure that "assert(Thread.current().holds(lock))" before
entering or exiting some method call. Also you can have better control and
dynamic checking (or static if the compiler let you have dependent int
types) if you design safe lock classes:


public class Lock {
    private final int level;
    public this(int level_)
    in {
        assert(level_ >= 0);
    } body {
        this.level = level_;
    }
    public int getLevel() {
        return this.level;
    }
    public void perform(void delegate() action) {
        synchronized(this) {
            action();
        }
    }
    public Lock and(Lock other)
    in {
        assert(getLevel() >= other.getLevel());
    } body {
        return new AndLock(this, other);
    }
}
class AndLock : Lock {
    private final Lock left, right;
    this(Lock left_, right_)
    in {
        assert(left.getLevel() >= right.getLevel());
    } body {
        this.left = left_;
        this.right = right_;
    }
    public int getLevel() {
        return this.right.getLevel();
    }
    public void perform(void delegate() action) {
        synchronized(this.left) {
            synchronized(this.right) {
                action();
            }
        }
    }
}

Lock la = new Lock(2);
Lock lb = new Lock(1);
void a() {
    la.and(lb).perform(void delegate() {
        printf("a");
    });
}
void b() {
    lb.and(la).perform(void delegate() {
        printf("f");
    });
}


This will cause a assertion error in "b()", because the levels are
incorrect. You can make this better by making Lock a template with a int
parameter and ensuring the type of the right lock to be correct (less than)
at compile time. Also if the Thread class helps you can have the each Thread
instance have a level stack attribute and when then lock executes the
perform operation you can set the new current level of the Thread. With this
the contract of perform can include an in part with a
"assert(Thread.current().getLevel() >= getLevel())" to check for deadlocks
in other situations.



 Besides, contracts have one major drawback. Since the state of a
 sufficiently complex program is very big, you won't be able to check the
 consistency of everything after every operation. So basically you need
 to anticipate what might go wrong in order to be able to write
 meaningful asserts.



That's why you minimize state. State is hell: the more you have it the less
reliable your system will be. Local state is ok but everything else should
be strictly checked, so you can verify that the locked resources are
independent (i.e. no deadlock possible) or they can be used without locks
(e.g. atomic or stateless).



 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.



 Sometimes you just have to have faith that everything will work as
 expected and use a debugger afterwards if it doesn't.



I don't have faith in neither unstated assumptions nor perfect programmers
so I can just go on and use a debugger afterwards, because the worst bugs
are silent and just keep consuming resources, corrupting data and not
working properly.



 I'm not saying you shouldn't use assertions. But you need to find a
 balance between coding time and the ability to prove that the code is
 bug-free (or at least that the issues you have anticipated do not occur).



Assertions make code fail early and fast, because they don't propagate
invalid data and corrupt state. It's different from formal proofs or model
checking tools, because you write them not to ensure that the code is
correct but to ensure that if it's incorrect it'll stop.



 In other words: debugging IS necessary ;).



Testing is necessary, to ensure that your code paths are covered. Formal
proofs are a must have, but most of the times we can afford the time, the
cost or the technology to do them. With assertions you may need to debug
sometimes, but probably you can make it without debugging tools and just use
simple reasoning and assertion failure stack traces. I know I don't need to
debug to find my bugs, because the assertions tell me where is its
birthplace.



 Hauke



Best regards,
Daniel Yokomiso.

"I favour OMG IDL (which I still can't shake off as reading 'Oh my God,
IDL!')"
 - Burton Radons


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.524 / Virus Database: 321 - Release Date: 8/10/2003
Oct 11 2003
next sibling parent "Hauke Duden" <H.NS.Duden gmx.net> writes:
"Daniel Yokomiso" <daniel_yokomiso yahoo.com.br> wrote in message
news:bma1tm$2cub$1 digitaldaemon.com...

 We can divide deadlocks in two kinds: deterministic and unpredictable. If
 your deadlocks are deterministic they'll always happen so they're easy to
 figure out and fix. If they are unpredictable the exact condition to


trigger

 them depends on race conditions and debugging mess with the timing so it
 won't help much here.


That's not true. You're assuming that with the different timing of debugging
they won't occur. Usually, in a multi-process environment, things are
sufficiently unstable so that conditions that happen in release mode can
also happen in debug mode. It may take a few tries, but usually you get to
debug your deadlock.


 With some help of the lock classes you can create
 asserts to ensure that "assert(Thread.current().holds(lock))" before
 entering or exiting some method call. Also you can have better control and
 dynamic checking (or static if the compiler let you have dependent int
 types) if you design safe lock classes:


<snipped complicated code>

So you suggest that I design the structure of my code around the need to
debug deadlocks? The whole point of having the synchronize keyword is to
make thread synchronization easy. If you have to go out of your way and wrap
everything into Lock classes to get some logs, what use is that? With a
debugger I can actually write my code in a way that makes sense from a
logical point of view.

If you have to write complicated code to make up for missing tool support,
things are just messed up.


 Besides, contracts have one major drawback. Since the state of a
 sufficiently complex program is very big, you won't be able to check the
 consistency of everything after every operation. So basically you need
 to anticipate what might go wrong in order to be able to write
 meaningful asserts.



 That's why you minimize state. State is hell: the more you have it the


less

 reliable your system will be. Local state is ok but everything else should
 be strictly checked, so you can verify that the locked resources are
 independent (i.e. no deadlock possible) or they can be used without locks
 (e.g. atomic or stateless).


Look at the memory usage of your application. Add to that the size of any
temporary files you use and you get some idea on how big the state of a
computer program is. Having a state is what software is all about!

I realize that you probably use a different definition of the word state,
though I'm not quite sure which one that is. "Limiting the state" is
sometimes possible if you remove redundancies. But the state of your
application would still be huge. As to "keeping it local": I assume you mean
that only an object itself should be influenced by its state. However, since
objects need to interact in order to form a working program that isn't
really feasible.

One example: You have some object that performs image filtering. It has a
bug that only occurs when the image it filters contains a certain
combination of pixel values. The bug doesn't produce a crash, it just
creates invalid output. The bug is triggered by the image data you pass to
that object, i.e. depends on the state of another object. You cannot
necessarily put assertions into the filtering code to make sure that the
output is correct, since the correct output can only be determined by the
algorithm that you're trying to find a bug in!

This is one of the cases where you just need to debug through the algorithm
step by step, look at how the values change and hope for an intuition on
what is going wrong.


 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 didn't advocate not using assertions. But if you want to get rid of
debugging you would have to encode every single interdependency between
variables into an assertion. If you assume that a programmer only creates 50
lines of code per day and 40 lines of that are assertions, you have a big
decrease in productivity.

Adding SOME assertions is good practice. Being overly paranoid and checking
for everything all the time is just not practical.


 Testing is necessary, to ensure that your code paths are covered. Formal
 proofs are a must have


That's where I don't agree. Formal proofs can be major timesinks. If people
were going around writing proofs that every single function works correctly,
no one would ever get anything done. Same with assertions. As I said before,
there is a fine line between using assertions as a useful tool and just
using them for the sake of having them.


 but most of the times we can afford the time, the
 cost or the technology to do them.


Right. That's basically what I just said ;). So you DO agree that proofs are
not must-haves after all?

Hauke
Oct 12 2003
prev sibling parent reply "Walter" <walter digitalmars.com> writes:
"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.
Oct 17 2003
parent "Matthew Wilson" <matthew stlsoft.org> writes:
"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.
Oct 17 2003
prev sibling next sibling parent reply "Nicolas Repiquet" <deadcow-remove-this free.fr> writes:
"Jan-Eric Duden" <jeduden whisset.com> a écrit dans le message news:
bm5mh1$2jd9$1 digitaldaemon.com...

 Being able to debug would help too... :)


D already have the most useful debugging primitive ever ! Namely, printf =)

-- Nicolas Repiquet
Oct 10 2003
parent "Sean L. Palmer" <palmer.sean verizon.net> writes:
Phooey!  It doesn't even go to the debugger output window.

Sean

"Nicolas Repiquet" <deadcow-remove-this free.fr> wrote in message
news:bm671e$73j$1 digitaldaemon.com...

 "Jan-Eric Duden" <jeduden whisset.com> a écrit dans le message news:
 bm5mh1$2jd9$1 digitaldaemon.com...

 Being able to debug would help too... :)


 D already have the most useful debugging primitive ever ! Namely, printf


=)

 -- Nicolas Repiquet
Oct 10 2003
prev sibling parent reply "Walter" <walter digitalmars.com> writes:
I use windbg.exe on it. It works. On linux, I use gdb.

"Jan-Eric Duden" <jeduden whisset.com> wrote in message
news:bm5mh1$2jd9$1 digitaldaemon.com...

 Being able to debug would help too... :)

 --
 Jan-Eric Duden
 "Matthew Wilson" <matthew stlsoft.org> wrote in message
 news:bm544r$1pk0$1 digitaldaemon.com...

 I know this has been said before, but having some stack trace in an
 assertion would be *very* useful
Oct 10 2003
next sibling parent "Jan-Eric Duden" <jeduden whisset.com> writes:
How ? I can't look up the _Dmain function and I just see assembler
statements.

-- 
Jan-Eric Duden

"Walter" <walter digitalmars.com> wrote in message
news:bm6rn4$12ud$3 digitaldaemon.com...

 I use windbg.exe on it. It works. On linux, I use gdb.

 "Jan-Eric Duden" <jeduden whisset.com> wrote in message
 news:bm5mh1$2jd9$1 digitaldaemon.com...

 Being able to debug would help too... :)

 --
 Jan-Eric Duden
 "Matthew Wilson" <matthew stlsoft.org> wrote in message
 news:bm544r$1pk0$1 digitaldaemon.com...

 I know this has been said before, but having some stack trace in an
 assertion would be *very* useful
Oct 10 2003
prev sibling parent reply Andy Friesen <andy ikagames.com> writes:
Walter wrote:


 I use windbg.exe on it. It works. On linux, I use gdb.
 


Visual Studio (I've tried 7 and 7.1) works just fine too.  Just be sure 
to compile with symbolic debug info on, and point the debugger at the 
exe like anything else. (-g)

You can't inspect the members of structs and classes (including 'this'), 
which is a shame, but you can put watches on local variables, set 
breakpoints, and step through the program and so forth.

  -- andy
Oct 10 2003
next sibling parent "Matthew Wilson" <matthew stlsoft.org> writes:
Cool! I may have to start using that. :)

"Andy Friesen" <andy ikagames.com> wrote in message
news:bm74a3$1e4u$1 digitaldaemon.com...

 Walter wrote:


 I use windbg.exe on it. It works. On linux, I use gdb.


 Visual Studio (I've tried 7 and 7.1) works just fine too.  Just be sure
 to compile with symbolic debug info on, and point the debugger at the
 exe like anything else. (-g)

 You can't inspect the members of structs and classes (including 'this'),
 which is a shame, but you can put watches on local variables, set
 breakpoints, and step through the program and so forth.

   -- andy
Oct 10 2003
prev sibling next sibling parent reply "Jan-Eric Duden" <jeduden whisset.com> writes:
so you debug assembler code? or actually d code?

I used the -g option:

c:\dmd\bin\dmd.exe -g -gt -debug -odC:\PROGRA~1\DIDE\Projects\T -version=Win
dowsXP  T.exe "C:\Program Files\DIDE\Projects\T\T.d" -I\dmd\src

started windbg. execute with windbg the .exe and then I just see assembler
code.
so what am I doing wrong?

-- 
Jan-Eric Duden
"Andy Friesen" <andy ikagames.com> wrote in message
news:bm74a3$1e4u$1 digitaldaemon.com...

 Walter wrote:


 I use windbg.exe on it. It works. On linux, I use gdb.


 Visual Studio (I've tried 7 and 7.1) works just fine too.  Just be sure
 to compile with symbolic debug info on, and point the debugger at the
 exe like anything else. (-g)

 You can't inspect the members of structs and classes (including 'this'),
 which is a shame, but you can put watches on local variables, set
 breakpoints, and step through the program and so forth.

   -- andy
Oct 10 2003
next sibling parent Andy Friesen <andy ikagames.com> writes:
Jan-Eric Duden wrote:


 so you debug assembler code? or actually d code?
 
 I used the -g option:
 
 c:\dmd\bin\dmd.exe -g -gt -debug -odC:\PROGRA~1\DIDE\Projects\T -version=Win
 dowsXP  T.exe "C:\Program Files\DIDE\Projects\T\T.d" -I\dmd\src
 
 started windbg. execute with windbg the .exe and then I just see assembler
 code.
 so what am I doing wrong?
 


D source.

I've always run it through the IDE, so I'm not sure what it's doing on 
you.  Basically, I set up a makefile project, and pointed the debugger 
at the executable within the project settings.

  -- andy
Oct 10 2003
prev sibling parent reply "Walter" <walter digitalmars.com> writes:
"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.
Oct 11 2003
parent reply "Jan-Eric Duden" <jeduden whisset.com> writes:
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.
Oct 11 2003
parent reply "Walter" <walter digitalmars.com> writes:
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.
Oct 16 2003
parent "Jan-Eric Duden" <jeduden whisset.com> writes:
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.
Oct 20 2003
prev sibling parent reply "Matthew Wilson" <matthew stlsoft.org> writes:
Have you any tips on how to get syntax highlighting working?

I've copied the C/C++ settings to a D key under
HKCU\Software\Microsoft\Visual Studio\7.0\Text Editor but that's had no
effect. :(

"Andy Friesen" <andy ikagames.com> wrote in message
news:bm74a3$1e4u$1 digitaldaemon.com...

 Walter wrote:


 I use windbg.exe on it. It works. On linux, I use gdb.


 Visual Studio (I've tried 7 and 7.1) works just fine too.  Just be sure
 to compile with symbolic debug info on, and point the debugger at the
 exe like anything else. (-g)

 You can't inspect the members of structs and classes (including 'this'),
 which is a shame, but you can put watches on local variables, set
 breakpoints, and step through the program and so forth.

   -- andy
Oct 10 2003
parent reply Andy Friesen <andy ikagames.com> writes:
Matthew Wilson wrote:

 Have you any tips on how to get syntax highlighting working?
 
 I've copied the C/C++ settings to a D key under
 HKCU\Software\Microsoft\Visual Studio\7.0\Text Editor but that's had no
 effect. :(
 


Add a key '.d' to 
HKLM/Software/Microsoft/VisualStudio/7.x/Languages/File Extensions and 
copy the value from .c into it.  That'll make VS treat D as if it were C++.

To add user keywords, create a file called UserType.dat and put it in 
the same directory as msdev.exe.  You can set the colour for the 
keywords in this file in the 'User Defined Keywords' subsection of the 
syntax highlighting settings.

  -- andy
Oct 10 2003
parent "Matthew Wilson" <matthew stlsoft.org> writes:
 Add a key '.d' to
 HKLM/Software/Microsoft/VisualStudio/7.x/Languages/File Extensions and
 copy the value from .c into it.  That'll make VS treat D as if it were


C++.

Nice one. :)


 To add user keywords, create a file called UserType.dat and put it in
 the same directory as msdev.exe.  You can set the colour for the
 keywords in this file in the 'User Defined Keywords' subsection of the
 syntax highlighting settings.


Been doing this one for years, but good to know it'll apply with VS.NET.

Thanks for all the info
Oct 10 2003
prev sibling parent reply "Walter" <walter digitalmars.com> writes:
"Matthew Wilson" <matthew stlsoft.org> wrote in message
news:bm544r$1pk0$1 digitaldaemon.com...

 I know this has been said before, but having some stack trace in an
 assertion would be *very* useful


It's Daniel Y's Most Requested Feature <g>.
Oct 10 2003
parent reply "Daniel Yokomiso" <daniel_yokomiso yahoo.com.br> writes:
"Walter" <walter digitalmars.com> escreveu na mensagem
news:bm5mnj$2jor$1 digitaldaemon.com...

 "Matthew Wilson" <matthew stlsoft.org> wrote in message
 news:bm544r$1pk0$1 digitaldaemon.com...

 I know this has been said before, but having some stack trace in an
 assertion would be *very* useful


 It's Daniel Y's Most Requested Feature <g>.


That's true. When will we have it? ;)


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.524 / Virus Database: 321 - Release Date: 7/10/2003
Oct 10 2003
parent "Daniel Yokomiso" <daniel_yokomiso yahoo.com.br> writes:
"Daniel Yokomiso" <daniel_yokomiso yahoo.com.br> escreveu na mensagem
news:bm61dr$316t$1 digitaldaemon.com...

 "Walter" <walter digitalmars.com> escreveu na mensagem
 news:bm5mnj$2jor$1 digitaldaemon.com...

 "Matthew Wilson" <matthew stlsoft.org> wrote in message
 news:bm544r$1pk0$1 digitaldaemon.com...

 I know this has been said before, but having some stack trace in an
 assertion would be *very* useful


 It's Daniel Y's Most Requested Feature <g>.


 That's true. When will we have it? ;)


Also would be very nice to be able to add messages to "assert", so we could
write:


public void assertEquals(Object left, Object right) {
    assert(left == right,
           "Expected <" ~ left.toString() ~ ">\r\n"
         ~ "Received <" ~ right.toString() ~ ">");
}


and get a nice message instead of a bland "Assertion Error".


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.524 / Virus Database: 321 - Release Date: 7/10/2003
Oct 10 2003