www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - assert(condition[, message]) patch

reply braddr puremagic.com writes:
I have been toying with D to bring myself up to speed and I found myself writing
a lot of unit tests, always a good thing.  In those unit tests I found myself
writing a lot of blocks like:

if (cond)
{
writefln("some debugging output to make my life easier");
assert(false);
}

I know many don't like unit tests to have output, but I do.  To simplify this,
I've created a patch for gdc/dmd to allow this syntax instead:

assert(cond, "some optional debugging output to make my life easier");

http://www.puremagic.com/~braddr/d/assert-optional-message-0.1.diff
http://www.puremagic.com/~braddr/d/assert-test.d

I've run this through dstress with no regressions.

Anyone wanna give it a whirl?

Later,
Brad
Feb 01 2006
next sibling parent reply Hasan Aljudy <hasan.aljudy gmail.com> writes:
braddr puremagic.com wrote:

 I have been toying with D to bring myself up to speed and I found myself
writing
 a lot of unit tests, always a good thing.  In those unit tests I found myself
 writing a lot of blocks like:
 
 if (cond)
 {
 writefln("some debugging output to make my life easier");
 assert(false);
 }
 
 I know many don't like unit tests to have output, but I do.  To simplify this,
 I've created a patch for gdc/dmd to allow this syntax instead:
 
 assert(cond, "some optional debugging output to make my life easier");
 
 http://www.puremagic.com/~braddr/d/assert-optional-message-0.1.diff
 http://www.puremagic.com/~braddr/d/assert-test.d
 
 I've run this through dstress with no regressions.
 
 Anyone wanna give it a whirl?
 
 Later,
 Brad
 
 


How can we install/apply the patch?
Feb 01 2006
parent braddr puremagic.com writes:
In article <drs0sb$2vhj$1 digitaldaemon.com>, Hasan Aljudy says...

braddr puremagic.com wrote:

 I have been toying with D to bring myself up to speed and I found myself
writing
 a lot of unit tests, always a good thing.  In those unit tests I found myself
 writing a lot of blocks like:
 
 if (cond)
 {
 writefln("some debugging output to make my life easier");
 assert(false);
 }
 
 I know many don't like unit tests to have output, but I do.  To simplify this,
 I've created a patch for gdc/dmd to allow this syntax instead:
 
 assert(cond, "some optional debugging output to make my life easier");
 
 http://www.puremagic.com/~braddr/d/assert-optional-message-0.1.diff
 http://www.puremagic.com/~braddr/d/assert-test.d
 
 I've run this through dstress with no regressions.
 
 Anyone wanna give it a whirl?
 
 Later,
 Brad
 
 


How can we install/apply the patch?


Save the .diff to a file, use the standard unix tool 'patch' to apply it to a
gcc+gdc source tree from the gcc directory, and rebuild gdc.

Later,
Brad
Feb 01 2006
prev sibling next sibling parent reply "Unknown W. Brackets" <unknown simplemachines.org> writes:
Does this effect static asserts?  Currently, you can do this with them:

static assert ("Some message.", 0);

This is because it is passed an expression, and so "", 0 just evaluates 
to 0.  But it does display the whole thing.

-[Unknown]



 I have been toying with D to bring myself up to speed and I found myself
writing
 a lot of unit tests, always a good thing.  In those unit tests I found myself
 writing a lot of blocks like:
 
 if (cond)
 {
 writefln("some debugging output to make my life easier");
 assert(false);
 }
 
 I know many don't like unit tests to have output, but I do.  To simplify this,
 I've created a patch for gdc/dmd to allow this syntax instead:
 
 assert(cond, "some optional debugging output to make my life easier");
 
 http://www.puremagic.com/~braddr/d/assert-optional-message-0.1.diff
 http://www.puremagic.com/~braddr/d/assert-test.d
 
 I've run this through dstress with no regressions.
 
 Anyone wanna give it a whirl?
 
 Later,
 Brad
Feb 01 2006
parent braddr puremagic.com writes:
In article <drs52m$mu$1 digitaldaemon.com>, Unknown W. Brackets says...


 I have been toying with D to bring myself up to speed and I found myself
writing
 a lot of unit tests, always a good thing.  In those unit tests I found myself
 writing a lot of blocks like:
 
 if (cond)
 {
 writefln("some debugging output to make my life easier");
 assert(false);
 }
 
 I know many don't like unit tests to have output, but I do.  To simplify this,
 I've created a patch for gdc/dmd to allow this syntax instead:
 
 assert(cond, "some optional debugging output to make my life easier");
 
 http://www.puremagic.com/~braddr/d/assert-optional-message-0.1.diff
 http://www.puremagic.com/~braddr/d/assert-test.d
 
 I've run this through dstress with no regressions.
 
 Anyone wanna give it a whirl?
 
 Later,
 Brad


Does this effect static asserts?  Currently, you can do this with them:

static assert ("Some message.", 0);

This is because it is passed an expression, and so "", 0 just evaluates 
to 0.  But it does display the whole thing.

-[Unknown]


<peeking at the code...>

Looks like assert and static assert are handled by completely different blocks
of code, completely.  so, static assert(...) is unchanged.

Later,
Brad
Feb 01 2006
prev sibling next sibling parent Yves Jacoby <kloune gmail.com> writes:
On Thu, 02 Feb 2006 01:35:20 +0000, braddr wrote:


 I have been toying with D to bring myself up to speed and I found myself
writing
 a lot of unit tests, always a good thing.  In those unit tests I found myself
 writing a lot of blocks like:
 
 if (cond)
 {
 writefln("some debugging output to make my life easier");
 assert(false);
 }
 
 I know many don't like unit tests to have output, but I do.  To simplify this,
 I've created a patch for gdc/dmd to allow this syntax instead:
 
 assert(cond, "some optional debugging output to make my life easier");
 
 http://www.puremagic.com/~braddr/d/assert-optional-message-0.1.diff
 http://www.puremagic.com/~braddr/d/assert-test.d
 
 I've run this through dstress with no regressions.
 
 Anyone wanna give it a whirl?
 
 Later,
 Brad


Simply "Thank you". Great thing.
Feb 02 2006
prev sibling next sibling parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
braddr wrote:


 I know many don't like unit tests to have output, but I do.  To simplify this,
 I've created a patch for gdc/dmd to allow this syntax instead:
 
 assert(cond, "some optional debugging output to make my life easier");


Excellent, I would be happy to include this in "gdcmac" for instance.
(if there aren't any objections to including "non-offical" D patches
into the compiler, already have a few necessary-for-portability ones)

Too bad that it doesn't get past the:
assert(false, "Walter didn't like it");

--anders
Feb 02 2006
prev sibling next sibling parent Psi Oddech <Psi_member pathlink.com> writes:
It's been a while since I've programmed something but I used something along the
lines of assert(condition && "whatever") or assert(condition &&
printf("whatever")), whichever worked.

In article <drrnko$2onm$1 digitaldaemon.com>, braddr puremagic.com says...

I have been toying with D to bring myself up to speed and I found myself writing
a lot of unit tests, always a good thing.  In those unit tests I found myself
writing a lot of blocks like:

if (cond)
{
writefln("some debugging output to make my life easier");
assert(false);
}

I know many don't like unit tests to have output, but I do.  To simplify this,
I've created a patch for gdc/dmd to allow this syntax instead:

assert(cond, "some optional debugging output to make my life easier");

http://www.puremagic.com/~braddr/d/assert-optional-message-0.1.diff
http://www.puremagic.com/~braddr/d/assert-test.d

I've run this through dstress with no regressions.

Anyone wanna give it a whirl?

Later,
Brad
Feb 02 2006
prev sibling next sibling parent reply braddr puremagic.com writes:
In article <drrnko$2onm$1 digitaldaemon.com>, braddr puremagic.com says...

I have been toying with D to bring myself up to speed and I found myself writing
a lot of unit tests, always a good thing.  In those unit tests I found myself
writing a lot of blocks like:

if (cond)
{
writefln("some debugging output to make my life easier");
assert(false);
}

I know many don't like unit tests to have output, but I do.  To simplify this,
I've created a patch for gdc/dmd to allow this syntax instead:

assert(cond, "some optional debugging output to make my life easier");

http://www.puremagic.com/~braddr/d/assert-optional-message-0.1.diff
http://www.puremagic.com/~braddr/d/assert-test.d

I've run this through dstress with no regressions.

Anyone wanna give it a whirl?

Later,
Brad


I was just about to start bringing this patch up to work with current dmd and
gdc but decided I should ask first:

Is anyone using it with gdc 0.17?
Would anyone use it if I freshened it up?
Walter, would you be interested / willing to incorporate the parser part into
dmd and support the feature in dmd?

I've seen a couple alternatives suggested, but they've all been somewhat hacky,
imho.

Later,
Brad
May 30 2006
next sibling parent reply akcom <CppCoder gmail.com> writes:
braddr puremagic.com wrote:

 In article <drrnko$2onm$1 digitaldaemon.com>, braddr puremagic.com says...

 I have been toying with D to bring myself up to speed and I found myself
writing
 a lot of unit tests, always a good thing.  In those unit tests I found myself
 writing a lot of blocks like:

 if (cond)
 {
 writefln("some debugging output to make my life easier");
 assert(false);
 }

 I know many don't like unit tests to have output, but I do.  To simplify this,
 I've created a patch for gdc/dmd to allow this syntax instead:

 assert(cond, "some optional debugging output to make my life easier");

 http://www.puremagic.com/~braddr/d/assert-optional-message-0.1.diff
 http://www.puremagic.com/~braddr/d/assert-test.d

 I've run this through dstress with no regressions.

 Anyone wanna give it a whirl?

 Later,
 Brad


 
 I was just about to start bringing this patch up to work with current dmd and
 gdc but decided I should ask first:
 
 Is anyone using it with gdc 0.17?
 Would anyone use it if I freshened it up?
 Walter, would you be interested / willing to incorporate the parser part into
 dmd and support the feature in dmd?
 
 I've seen a couple alternatives suggested, but they've all been somewhat hacky,
 imho.
 
 Later,
 Brad
 
 


Just my thoughts, I think it's definitely got some merits, although one 
must consider that the assert( statementToTest ) would give you the line 
that threw the assert, which makes a message a bit less important. 
Although, on the other hand, if someone (ie not someone who wrote the 
code) were to see the assert and check the given line, it probably 
wouldn't mean too much to them, whereas being able to see a message 
associated with it would be a bit more useful.  I'd definitely give the 
mod a whirl.
May 30 2006
parent reply BCS <BCS_member pathlink.com> writes:
In article <e5im92$hlo$2 digitaldaemon.com>, akcom says...


[...]

Just my thoughts, I think it's definitely got some merits, although one 
must consider that the assert( statementToTest ) would give you the line 
that threw the assert, which makes a message a bit less important. 


if the message is non static then a lot of info can be printed.

assert(str.length < 5, `the string "` ~ str ~ `" is more than 5 char long");

I'll vote for this.



 May 30 2006



  parent reply Daniel Keep <daniel.keep.lists gmail.com>  writes:


BCS wrote:

 In article <e5im92$hlo$2 digitaldaemon.com>, akcom says...
 [...]

 Just my thoughts, I think it's definitely got some merits, although one 
 must consider that the assert( statementToTest ) would give you the line 
 that threw the assert, which makes a message a bit less important. 


 
 if the message is non static then a lot of info can be printed.
 
 assert(str.length < 5, `the string "` ~ str ~ `" is more than 5 char long");
 
 I'll vote for this.
 


I like the idea, but here's a better one that I could have used when
testing my MMX routines:











Working out *why* it's asserted is no fun whatsoever.  YES it's told you
there's a bug, but in this case, it hasn't even told you what that bug
is.  Just that it exists.

In this case, using a message would help; I could tell myself where the
assert had failed.  Even better would be a few more asserts:



Which might print:

AssertError foo.d line 2001: mismatch at element 42: expected "6", got "9".

I would have KILLED for that a few weeks ago :)  I'd implement that
myself, except that `assert` seems to be the ONLY statement in D that
automatically passes the source file and line number to the exception.

Walter: is there any technical reason why we can't get Exceptions to
automatically have source file and line number assigned when instantiated?

Hmm.  Seem to have gone off topic somewhat.  Gomen.

	-- Daniel

-- 
Unlike Knuth, I have neither proven or tried the above; it may not even
make sense.

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



 May 30 2006



  parent reply Bruno Medeiros <brunodomedeirosATgmail SPAM.com>  writes:


Daniel Keep wrote:

 
 BCS wrote:

 In article <e5im92$hlo$2 digitaldaemon.com>, akcom says...
 [...]

 Just my thoughts, I think it's definitely got some merits, although one 
 must consider that the assert( statementToTest ) would give you the line 
 that threw the assert, which makes a message a bit less important. 


 if the message is non static then a lot of info can be printed.

 assert(str.length < 5, `the string "` ~ str ~ `" is more than 5 char long");

 I'll vote for this.


 
 I like the idea, but here's a better one that I could have used when
 testing my MMX routines:
 









 
 Working out *why* it's asserted is no fun whatsoever.  YES it's told you
 there's a bug, but in this case, it hasn't even told you what that bug
 is.  Just that it exists.
 
 In this case, using a message would help; I could tell myself where the
 assert had failed.  Even better would be a few more asserts:
 

 
 Which might print:
 
 AssertError foo.d line 2001: mismatch at element 42: expected "6", got "9".
 
 I would have KILLED for that a few weeks ago :)  I'd implement that
 myself, except that `assert` seems to be the ONLY statement in D that
 automatically passes the source file and line number to the exception.
 
 Walter: is there any technical reason why we can't get Exceptions to
 automatically have source file and line number assigned when instantiated?
 


You mean when thrown, no?


 Hmm.  Seem to have gone off topic somewhat.  Gomen.
 
 	-- Daniel
 



-- 
Bruno Medeiros - CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D



 May 31 2006



  parent reply Daniel Keep <daniel.keep.lists gmail.com>  writes:


Bruno Medeiros wrote:

 Daniel Keep wrote:

 BCS wrote:

 In article <e5im92$hlo$2 digitaldaemon.com>, akcom says...
 [...]

 Just my thoughts, I think it's definitely got some merits, although
 one must consider that the assert( statementToTest ) would give you
 the line that threw the assert, which makes a message a bit less
 important. 


 if the message is non static then a lot of info can be printed.

 assert(str.length < 5, `the string "` ~ str ~ `" is more than 5 char
 long");

 I'll vote for this.


 I like the idea, but here's a better one that I could have used when
 testing my MMX routines:











 Working out *why* it's asserted is no fun whatsoever.  YES it's told you
 there's a bug, but in this case, it hasn't even told you what that bug
 is.  Just that it exists.

 In this case, using a message would help; I could tell myself where the
 assert had failed.  Even better would be a few more asserts:



 Which might print:

 AssertError foo.d line 2001: mismatch at element 42: expected "6", got
 "9".

 I would have KILLED for that a few weeks ago :)  I'd implement that
 myself, except that `assert` seems to be the ONLY statement in D that
 automatically passes the source file and line number to the exception.

 Walter: is there any technical reason why we can't get Exceptions to
 automatically have source file and line number assigned when
 instantiated?


 
 You mean when thrown, no?
 

 Hmm.  Seem to have gone off topic somewhat.  Gomen.

     -- Daniel


 
 












See the problem? :P

-- 
Unlike Knuth, I have neither proven or tried the above; it may not even
make sense.

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



 May 31 2006



  parent  Bruno Medeiros <brunodomedeirosATgmail SPAM.com>  writes:


Daniel Keep wrote:

 
 Bruno Medeiros wrote:

 Daniel Keep wrote:

 BCS wrote:

 In article <e5im92$hlo$2 digitaldaemon.com>, akcom says...
 [...]

 Just my thoughts, I think it's definitely got some merits, although
 one must consider that the assert( statementToTest ) would give you
 the line that threw the assert, which makes a message a bit less
 important. 


 if the message is non static then a lot of info can be printed.

 assert(str.length < 5, `the string "` ~ str ~ `" is more than 5 char
 long");

 I'll vote for this.


 I like the idea, but here's a better one that I could have used when
 testing my MMX routines:











 Working out *why* it's asserted is no fun whatsoever.  YES it's told you
 there's a bug, but in this case, it hasn't even told you what that bug
 is.  Just that it exists.

 In this case, using a message would help; I could tell myself where the
 assert had failed.  Even better would be a few more asserts:



 Which might print:

 AssertError foo.d line 2001: mismatch at element 42: expected "6", got
 "9".

 I would have KILLED for that a few weeks ago :)  I'd implement that
 myself, except that `assert` seems to be the ONLY statement in D that
 automatically passes the source file and line number to the exception.

 Walter: is there any technical reason why we can't get Exceptions to
 automatically have source file and line number assigned when
 instantiated?


 You mean when thrown, no?


 Hmm.  Seem to have gone off topic somewhat.  Gomen.

     -- Daniel




 









 
 See the problem? :P
 


Easily solvable I think. 'throw' will only fill file-line info once for 
a given exception (that is, it fills only if the exception hasn't that 
info already).
But now that you mention that idiom, I wonder how other languages deal 
with that. I'll have to check it out

-- 
Bruno Medeiros - CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D



 Jun 02 2006



prev sibling  parent  Sean Kelly <sean f4.ca>  writes:


braddr puremagic.com wrote:

 
 I was just about to start bringing this patch up to work with current dmd and
 gdc but decided I should ask first:
 
 Is anyone using it with gdc 0.17?
 Would anyone use it if I freshened it up?
 Walter, would you be interested / willing to incorporate the parser part into
 dmd and support the feature in dmd?


Assuming the feature were added to DMD I'd definitely use it, but I've 
avoided it to date as I dislike language extensions.


Sean



 May 30 2006



prev sibling  parent reply Walter Bright <newshound digitalmars.com>  writes:


braddr puremagic.com wrote:

 I have been toying with D to bring myself up to speed and I found myself
writing
 a lot of unit tests, always a good thing.  In those unit tests I found myself
 writing a lot of blocks like:
 
 if (cond)
 {
 writefln("some debugging output to make my life easier");
 assert(false);
 }
 
 I know many don't like unit tests to have output, but I do.


Why not:

	assert(!cond); // some debugging output to make my life easier

? You'll need to go look at the source anyway when the assert trips, so 
what advantage is there to print the comment?



 May 31 2006



 next sibling parent  BCS <BCS_member pathlink.com>  writes:


In article <e5ki8s$jfc$1 digitaldaemon.com>, Walter Bright says...

braddr puremagic.com wrote:

 I have been toying with D to bring myself up to speed and I found myself
writing
 a lot of unit tests, always a good thing.  In those unit tests I found myself
 writing a lot of blocks like:
 
 if (cond)
 {
 writefln("some debugging output to make my life easier");
 assert(false);
 }
 
 I know many don't like unit tests to have output, but I do.


Why not:

	assert(!cond); // some debugging output to make my life easier

? You'll need to go look at the source anyway when the assert trips, so 
what advantage is there to print the comment?


a little run time info could be realy helpfull.



or in the case someone was talking about (MMX stuff)


..

char[] assertMsg
assert(compArray(c,d,assertMsg), assertMsg);

..

bool compArray(int[] a, int[] b, inout char[] msg)
{
if(a==b) return true;

if(a.length != b.length)
{
msg = "Unequal length";
return false;
}

foreach(int i, int j; a)
if(a[i] != b[i])
{

return false;
}
msg = "somthings wrong";
return false;
}



 May 31 2006



prev sibling next sibling parent reply Brad Roberts <braddr puremagic.com>  writes:


On Wed, 31 May 2006, Walter Bright wrote:


 braddr puremagic.com wrote:

 I have been toying with D to bring myself up to speed and I found myself
 writing
 a lot of unit tests, always a good thing.  In those unit tests I found
 myself
 writing a lot of blocks like:
 
 if (cond)
 {
 writefln("some debugging output to make my life easier");
 assert(false);
 }
 
 I know many don't like unit tests to have output, but I do.


 
 Why not:
 
 	assert(!cond); // some debugging output to make my life easier
 
 ? You'll need to go look at the source anyway when the assert trips, so what
 advantage is there to print the comment?


Often it saves one cycle through the debugger by the expediency of having 
actual information about what caused the assert, more than just 'something 
broke here' that a plain assertion violation causes today.

Take a look at some code I wrote where the unit tests use this feature:

  http://www.puremagic.com/~braddr/d/interned_string.d

A comment can't convey state, just intent.

I've reapplied the referenced patch to dmd/gdc and it works when used 
properly.  However, exactly like it was before, it's got a number of bugs 
when used improperly.  I need to learn more about dmd and gdc both to fix 
the thing to be robust enough to actually merge in.

Later,
Brad



 May 31 2006



  parent  Brad Roberts <braddr puremagic.com>  writes:


On Wed, 31 May 2006, Brad Roberts wrote:


 On Wed, 31 May 2006, Walter Bright wrote:
 

 braddr puremagic.com wrote:

 I have been toying with D to bring myself up to speed and I found myself
 writing
 a lot of unit tests, always a good thing.  In those unit tests I found
 myself
 writing a lot of blocks like:
 
 if (cond)
 {
 writefln("some debugging output to make my life easier");
 assert(false);
 }
 
 I know many don't like unit tests to have output, but I do.


 
 Why not:
 
 	assert(!cond); // some debugging output to make my life easier
 
 ? You'll need to go look at the source anyway when the assert trips, so what
 advantage is there to print the comment?


 
 I've reapplied the referenced patch to dmd/gdc and it works when used 
 properly.  However, exactly like it was before, it's got a number of bugs 
 when used improperly.  I need to learn more about dmd and gdc both to fix 
 the thing to be robust enough to actually merge in.


The current patch:

    http://www.puremagic.com/~braddr/d/assert-optional-message-0.2-gdc-0.18.diff
    http://www.puremagic.com/~braddr/d/assert-test.d


There's a couple issues with the code as it stands:

1) most of the code is in the gdc layer, meaning that to incorporate with 
dmd walter will have to do some work.  This can't be helped, probably.

2) rather than introduce a new _d_assert_with_message() api to the 
runtime, I've chosen to default to "" if no assert message is specified.

3) the runtime code in phobos/std/assertinternal.d recognizes "" as 'no 
message'

4) assert(condition, non-string-constant) produces an ICE in the gdc glue 
layer

5) assert(condition, non-string-expression) produces an odd error message:  
Integer constant expression expected instead of (test7func)()


I'm continuing to work on 4 and 5.  For now, I'm leaving 1-3 as is unless 
there's some outcry that guilts me into working on them more.


Later,
Brad



 May 31 2006



prev sibling next sibling parent reply "Chris Miller" <chris dprogramming.com>  writes:


On Wed, 31 May 2006 13:01:24 -0400, Walter Bright  
<newshound digitalmars.com> wrote:


 braddr puremagic.com wrote:

 I have been toying with D to bring myself up to speed and I found  
 myself writing
 a lot of unit tests, always a good thing.  In those unit tests I found  
 myself
 writing a lot of blocks like:
  if (cond)
 {
 writefln("some debugging output to make my life easier");
 assert(false);
 }
  I know many don't like unit tests to have output, but I do.


 Why not:

 	assert(!cond); // some debugging output to make my life easier

 ? You'll need to go look at the source anyway when the assert trips, so  
 what advantage is there to print the comment?


How about when you have many versions of the program and source. Sure if  
you backup regularly and save them all you can eventually figure out which  
assert, but a message usually lets you find it in seconds.

I'd also be satisfied if it only used the assert expression as this  
message (and a trick could be used if one really wants: assert(foo && "my  
message");).



 May 31 2006



  parent reply Walter Bright <newshound digitalmars.com>  writes:


Chris Miller wrote:

 On Wed, 31 May 2006 13:01:24 -0400, Walter Bright 

 ? You'll need to go look at the source anyway when the assert trips, 
 so what advantage is there to print the comment?


 
 How about when you have many versions of the program and source. Sure if 
 you backup regularly and save them all you can eventually figure out 
 which assert, but a message usually lets you find it in seconds.


I'm not sure what there is to figure out, it gives the source file and 
line number. If you're using a decent IDE, it'll even automatically 
bring up the source file and position the cursor on the offending line.



 I'd also be satisfied if it only used the assert expression as this 
 message (and a trick could be used if one really wants: assert(foo && 
 "my message");).





 May 31 2006



  parent  "Chris Miller" <chris dprogramming.com>  writes:


On Wed, 31 May 2006 17:55:51 -0400, Walter Bright  
<newshound digitalmars.com> wrote:


 Chris Miller wrote:

 On Wed, 31 May 2006 13:01:24 -0400, Walter Bright

 ? You'll need to go look at the source anyway when the assert trips,  
 so what advantage is there to print the comment?


  How about when you have many versions of the program and source. Sure  
 if you backup regularly and save them all you can eventually figure out  
 which assert, but a message usually lets you find it in seconds.


 I'm not sure what there is to figure out, it gives the source file and  
 line number. If you're using a decent IDE, it'll even automatically  
 bring up the source file and position the cursor on the offending line.


"How about when you have many versions of the program and source" ==  
source files have been modified; lines don't "line up" unless you  
coordinate the version and dig it up.



 May 31 2006



prev sibling next sibling parent reply Lars Ivar Igesund <larsivar igesund.net>  writes:


Walter Bright wrote:


 braddr puremagic.com wrote:

 I have been toying with D to bring myself up to speed and I found myself
 writing
 a lot of unit tests, always a good thing.  In those unit tests I found
 myself writing a lot of blocks like:
 
 if (cond)
 {
 writefln("some debugging output to make my life easier");
 assert(false);
 }
 
 I know many don't like unit tests to have output, but I do.


 
 Why not:
 
 assert(!cond); // some debugging output to make my life easier
 
 ? You'll need to go look at the source anyway when the assert trips, so
 what advantage is there to print the comment?


Because not all the users will have access to the source, or be inclined to
see it. Unless the user get's a readable/understandable assert message
he/she might not get enough information to actually reproduce a test case
for the developer to peruse.

Walter, this is a no-brainer, please put it in.

-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource & #D: larsivi



 May 31 2006



  parent reply Tom S <h3r3tic remove.mat.uni.torun.pl>  writes:


Lars Ivar Igesund wrote:

 Because not all the users will have access to the source, or be inclined to
 see it. Unless the user get's a readable/understandable assert message
 he/she might not get enough information to actually reproduce a test case
 for the developer to peruse.
 
 Walter, this is a no-brainer, please put it in.


++votes;

/+
when you release your app to some testing team, you might want to leave 
asserts in. While an error message containing the line number and 
filename could be helpful, an additional message could be priceless. 
E.g. assert(fileNameContainsNoSpaces(foo)); won't tell you that the 
'foo' really was something like '^&^34 5+23 3(43D678[SAFer6_[]' which 
might mean some mem corruption or forgetting a .dup somewhere in your 
code. You'd instead go searching for some logic problems that wouldn't 
solve the problem.
+/


-- 
Tomasz Stachowiak  /+ a.k.a. h3r3tic +/



 May 31 2006



  parent reply Joseph Lisee <jlisee umd.edu>  writes:


In article <e5l5v8$1g7j$1 digitaldaemon.com>,
 Tom S <h3r3tic remove.mat.uni.torun.pl> wrote:


 Lars Ivar Igesund wrote:

 Because not all the users will have access to the source, or be inclined to
 see it. Unless the user get's a readable/understandable assert message
 he/she might not get enough information to actually reproduce a test case
 for the developer to peruse.
 
 Walter, this is a no-brainer, please put it in.


 
 ++votes;
 
 /+
 when you release your app to some testing team, you might want to leave 
 asserts in. While an error message containing the line number and 
 filename could be helpful, an additional message could be priceless. 
 E.g. assert(fileNameContainsNoSpaces(foo)); won't tell you that the 
 'foo' really was something like '^&^34 5+23 3(43D678[SAFer6_[]' which 
 might mean some mem corruption or forgetting a .dup somewhere in your 
 code. You'd instead go searching for some logic problems that wouldn't 
 solve the problem.
 +/


I vote for the assert(condition, "msg"), construct as well.

CXX Test and JUnit have spoiled me.  You can't even do assert(1 == 0 && 
"The laws of math have been changed"), which is trick I use in the C++ 
all the time.  Is having a message with the assert going to hurt 
anything?

-Joseph Lisee



 Jul 31 2006



 next sibling parent  Brad Roberts <braddr puremagic.com>  writes:


On Mon, 31 Jul 2006, Joseph Lisee wrote:


 In article <e5l5v8$1g7j$1 digitaldaemon.com>,
  Tom S <h3r3tic remove.mat.uni.torun.pl> wrote:
 

 Lars Ivar Igesund wrote:

 Because not all the users will have access to the source, or be inclined to
 see it. Unless the user get's a readable/understandable assert message
 he/she might not get enough information to actually reproduce a test case
 for the developer to peruse.
 
 Walter, this is a no-brainer, please put it in.


 
 ++votes;
 
 /+
 when you release your app to some testing team, you might want to leave 
 asserts in. While an error message containing the line number and 
 filename could be helpful, an additional message could be priceless. 
 E.g. assert(fileNameContainsNoSpaces(foo)); won't tell you that the 
 'foo' really was something like '^&^34 5+23 3(43D678[SAFer6_[]' which 
 might mean some mem corruption or forgetting a .dup somewhere in your 
 code. You'd instead go searching for some logic problems that wouldn't 
 solve the problem.
 +/


 
 I vote for the assert(condition, "msg"), construct as well.
 
 CXX Test and JUnit have spoiled me.  You can't even do assert(1 == 0 && 
 "The laws of math have been changed"), which is trick I use in the C++ 
 all the time.  Is having a message with the assert going to hurt 
 anything?
 
 -Joseph Lisee


Um..  you're voting for a feature that was added several releases ago.

Later,
Brad



 Jul 31 2006



prev sibling  parent reply Sean Kelly <sean f4.ca>  writes:


Joseph Lisee wrote:

 In article <e5l5v8$1g7j$1 digitaldaemon.com>,
  Tom S <h3r3tic remove.mat.uni.torun.pl> wrote:
 

 Lars Ivar Igesund wrote:

 Because not all the users will have access to the source, or be inclined to
 see it. Unless the user get's a readable/understandable assert message
 he/she might not get enough information to actually reproduce a test case
 for the developer to peruse.

 Walter, this is a no-brainer, please put it in.


 ++votes;

 /+
 when you release your app to some testing team, you might want to leave 
 asserts in. While an error message containing the line number and 
 filename could be helpful, an additional message could be priceless. 
 E.g. assert(fileNameContainsNoSpaces(foo)); won't tell you that the 
 'foo' really was something like '^&^34 5+23 3(43D678[SAFer6_[]' which 
 might mean some mem corruption or forgetting a .dup somewhere in your 
 code. You'd instead go searching for some logic problems that wouldn't 
 solve the problem.
 +/


 
 I vote for the assert(condition, "msg"), construct as well.


This feature was added a number of builds ago.


Sean



 Jul 31 2006



  parent reply Joseph Lisee <jlisee umd.edu>  writes:


In article <ealh03$htp$1 digitaldaemon.com>, Sean Kelly <sean f4.ca> 
wrote:


 Joseph Lisee wrote:

 In article <e5l5v8$1g7j$1 digitaldaemon.com>,
  Tom S <h3r3tic remove.mat.uni.torun.pl> wrote:
 

 Lars Ivar Igesund wrote:

 Because not all the users will have access to the source, or be inclined 
 to
 see it. Unless the user get's a readable/understandable assert message
 he/she might not get enough information to actually reproduce a test case
 for the developer to peruse.

 Walter, this is a no-brainer, please put it in.


 ++votes;

 /+
 when you release your app to some testing team, you might want to leave 
 asserts in. While an error message containing the line number and 
 filename could be helpful, an additional message could be priceless. 
 E.g. assert(fileNameContainsNoSpaces(foo)); won't tell you that the 
 'foo' really was something like '^&^34 5+23 3(43D678[SAFer6_[]' which 
 might mean some mem corruption or forgetting a .dup somewhere in your 
 code. You'd instead go searching for some logic problems that wouldn't 
 solve the problem.
 +/


 
 I vote for the assert(condition, "msg"), construct as well.


 
 This feature was added a number of builds ago.
 
 
 Sean


That is what happens when I don't read the documentation close enough 
and not pay attention to message dates.

It should also be noted that the in the Contract Programming page of the 
documentation it only mentions "assert(expression)".  While It does link 
to the full documentation on the assert expression should that page also 
mention the option for a message?

Sorry to clutter the mailing list.  I will just go back to my attempt at 
wrapping C++ with doxygen + python. Yes I am aware of the D module for 
Swig, but I am going for something more elegant and this effort is a 
good C++, Python, and D programming exercise.

-Joseph



 Aug 01 2006



  parent reply Kirk McDonald <kirklin.mcdonald gmail.com>  writes:


Joseph Lisee wrote:

 In article <ealh03$htp$1 digitaldaemon.com>, Sean Kelly <sean f4.ca> 
 wrote:
 
 

Joseph Lisee wrote:


In article <e5l5v8$1g7j$1 digitaldaemon.com>,
 Tom S <h3r3tic remove.mat.uni.torun.pl> wrote:



Lars Ivar Igesund wrote:


Because not all the users will have access to the source, or be inclined 
to
see it. Unless the user get's a readable/understandable assert message
he/she might not get enough information to actually reproduce a test case
for the developer to peruse.

Walter, this is a no-brainer, please put it in.


++votes;

/+
when you release your app to some testing team, you might want to leave 
asserts in. While an error message containing the line number and 
filename could be helpful, an additional message could be priceless. 
E.g. assert(fileNameContainsNoSpaces(foo)); won't tell you that the 
'foo' really was something like '^&^34 5+23 3(43D678[SAFer6_[]' which 
might mean some mem corruption or forgetting a .dup somewhere in your 
code. You'd instead go searching for some logic problems that wouldn't 
solve the problem.
+/


I vote for the assert(condition, "msg"), construct as well.


This feature was added a number of builds ago.


Sean


 
 
 That is what happens when I don't read the documentation close enough 
 and not pay attention to message dates.
 
 It should also be noted that the in the Contract Programming page of the 
 documentation it only mentions "assert(expression)".  While It does link 
 to the full documentation on the assert expression should that page also 
 mention the option for a message?
 
 Sorry to clutter the mailing list.  I will just go back to my attempt at 
 wrapping C++ with doxygen + python. Yes I am aware of the D module for 
 Swig, but I am going for something more elegant and this effort is a 
 good C++, Python, and D programming exercise.


Are you aware of my Pyd library? It's a wrapper around the Python API, 
analogous to Boost::Python, but for D. It's probably not quite ready for 
serious use (for one thing, I haven't really documented it yet; for 
another, I haven't added Linux support yet, though it's going in Real 
Soon Now (tm)), but it might be worth taking a look at.

So yeah, this is yet another unfinished, undocumented open-source 
project, but it is still capable of the following and more:

[testdll.d]
import pyd.pyd;
import std.stdio;

class Foo {
     int m_i;
     this() { m_i = 0; }
     this(int i) { m_i = i; }

     void foo() { writefln("i = ", m_i); }
     int i() { return m_i; }
     void i(int j) { m_i = j; }
}

void bar(int i) {
     writefln("You entered: ", i);
}

extern(C)
export void inittestdll() {
     // Function wrapping
     def!(bar, "bar");

     module_init("testdll");

     // Class wrapping
     wrapped_class!(Foo, "Foo") f;
     // Constructor wrapping
     f.init!(tuple!(int));
     // Member function wrapping
     f.def!(Foo.foo, "foo");
     // Property wrapping
     f.prop!(Foo.i, "i");
     finalize_class(f);
}
// EOF

And in Python:


 import testdll
 testdll.bar(20)






You entered: 20

 f = testdll.Foo(30)
 f.i






30

 f.i = 50
 f.foo()






i = 50

It also comes with an extension to Python's distutils (David Rushby's 
CeleriD), to make building these extensions so much easier.

Even if you don't use Pyd, the project has what I believe is the most 
complete version of the Python API header, which would probably be 
useful to you:
http://dsource.org/projects/pyd/browser/trunk/infrastructure/python/headers/python.d

-- 
Kirk McDonald
Pyd: Wrapping Python with D
http://dsource.org/projects/pyd/wiki



 Aug 01 2006



  parent reply Joseph Lisee <jlisee umd.edu>  writes:


In article <eao805$2svv$1 digitaldaemon.com>,
 Kirk McDonald <kirklin.mcdonald gmail.com> wrote:



 Are you aware of my Pyd library? It's a wrapper around the Python API, 
 analogous to Boost::Python, but for D. It's probably not quite ready for 
 serious use (for one thing, I haven't really documented it yet; for 
 another, I haven't added Linux support yet, though it's going in Real 
 Soon Now (tm)), but it might be worth taking a look at.
 
 So yeah, this is yet another unfinished, undocumented open-source 
 project, but it is still capable of the following and more:
 
 [testdll.d]
 import pyd.pyd;
 import std.stdio;
 
 class Foo {
      int m_i;
      this() { m_i = 0; }
      this(int i) { m_i = i; }
 
      void foo() { writefln("i = ", m_i); }
      int i() { return m_i; }
      void i(int j) { m_i = j; }
 }
 
 void bar(int i) {
      writefln("You entered: ", i);
 }
 
 extern(C)
 export void inittestdll() {
      // Function wrapping
      def!(bar, "bar");
 
      module_init("testdll");
 
      // Class wrapping
      wrapped_class!(Foo, "Foo") f;
      // Constructor wrapping
      f.init!(tuple!(int));
      // Member function wrapping
      f.def!(Foo.foo, "foo");
      // Property wrapping
      f.prop!(Foo.i, "i");
      finalize_class(f);
 }
 // EOF
 
 And in Python:
 
  >>> import testdll
  >>> testdll.bar(20)
 You entered: 20
  >>> f = testdll.Foo(30)
  >>> f.i
 30
  >>> f.i = 50
  >>> f.foo()
 i = 50
 
 It also comes with an extension to Python's distutils (David Rushby's 
 CeleriD), to make building these extensions so much easier.
 
 Even if you don't use Pyd, the project has what I believe is the most 
 complete version of the Python API header, which would probably be 
 useful to you:
 http://dsource.org/projects/pyd/browser/trunk/infrastructure/python/headers/py
 thon.d


I have seen your library and I think it will be a great addition to D, 
what parts of linux support are missing?

I don't think PyD will apply to my project.  Let me get incredibly off 
topic and explain a little more. I am trying to make a program that 
generates wrappers for C++ programs so you can use them in D.  My 
current plan is to process the XML output from Doxygen with Python and 
the ElementTree library.  I will then generate a C++ file with a C 
interface to the class and D wrapper file for each class.  Something 
similar to below:

// C++ Code
class MyClass {
   int m_num;
public:
    MyClass(int num) {
        m_num = num;
    }

    int getNum() {
        return m_num;
    }
};

// C Wrapper Code
extern "C"
{
    void* MyClass_new(int num) {
        return (void*)(new myClass(num));
    }

    int MyClass_getNum(void* obj) {
        return ((myClass*)obj)->getNum();
    }

    void MyClass_delete(void* obj) {
        delete (myClass*)obj;
    }
}

// D wrapper class
extern (C)
{
    void* MyClass_new(int num);
    int MyClass_getNum(void* obj);
    void MyClass_delete(void* obj);
}

class MyClass {
    private void* cppObj;

    this(int num) {
        cppObj = MyClass_new(num);
    }

    ~this() {
        MyClass_delete(cppObj);
    }

    int getNum() {
        return MyClass_getNum(cppObj);
    }
}

That is a very basic example and doesn't handle exception being thrown 
from the C++ code.  I haven't start work on the generator yet.  I am 
currently testing my ideas on the following issues:

  -properly handling the passing of D wrapped C++ classes to and from 
the C++ code.
  -using directors at the bottom of the inheritance tree to properly 
pass virtual function calls of to inherited D class
  -Throwing C++ and D exceptions through the interface that has C 
linkage.
  -Mapping of types from C++ to C to D.

If this ever gets off the ground I am thinking of calling it WrapeD, the 
lack of two p's is intentional.  I hope to have simpler interface file 
system than swig.  Something looks more like SCons build files.

-Joseph



 Aug 01 2006



 next sibling parent  Kirk McDonald <kirklin.mcdonald gmail.com>  writes:


Joseph Lisee wrote:

 I have seen your library and I think it will be a great addition to D, 
 what parts of linux support are missing?
 


Mostly I need to re-write CeleriD's DCompiler classes to add support for 
gdc. Building shared libraries with DMD on Linux doesn't work, but using 
gdc does. This is farily tedious (it basically means re-writing the 
entire dcompiler.py module), but I'm bashing away at it.

-- 
Kirk McDonald
Pyd: Wrapping Python with D
http://dsource.org/projects/pyd/wiki



 Aug 01 2006



prev sibling  parent reply =?ISO-8859-1?Q?=22R=E9my_J=2E_A=2E_Mou=EBza=22?=  writes:


I've done something close to what you discribe using Python ( C++ 
wrapping using the output of gccxml ). You can have a look at it on 
http://remy.moueza.free.fr. Gregor Richards has done better with BCD, 
available on dsource, only using D and gccxml. Swig also output xml, 
thus it is also possible to use it as an alternative to gccxml. I didn't 
know doxygen could output an xml view of its analysis.
Good luck.


 I don't think PyD will apply to my project.  Let me get incredibly off 
 topic and explain a little more. I am trying to make a program that 
 generates wrappers for C++ programs so you can use them in D.  My 
 current plan is to process the XML output from Doxygen with Python and 
 the ElementTree library.  I will then generate a C++ file with a C 
 interface to the class and D wrapper file for each class.  Something 
 similar to below:
 
 // C++ Code
 class MyClass {
    int m_num;
 public:
     MyClass(int num) {
         m_num = num;
     }
 
     int getNum() {
         return m_num;
     }
 };
 
 // C Wrapper Code
 extern "C"
 {
     void* MyClass_new(int num) {
         return (void*)(new myClass(num));
     }
 
     int MyClass_getNum(void* obj) {
         return ((myClass*)obj)->getNum();
     }
 
     void MyClass_delete(void* obj) {
         delete (myClass*)obj;
     }
 }
 
 // D wrapper class
 extern (C)
 {
     void* MyClass_new(int num);
     int MyClass_getNum(void* obj);
     void MyClass_delete(void* obj);
 }
 
 class MyClass {
     private void* cppObj;
 
     this(int num) {
         cppObj = MyClass_new(num);
     }
 
     ~this() {
         MyClass_delete(cppObj);
     }
 
     int getNum() {
         return MyClass_getNum(cppObj);
     }
 }
 
 That is a very basic example and doesn't handle exception being thrown 
 from the C++ code.  I haven't start work on the generator yet.  I am 
 currently testing my ideas on the following issues:
 
   -properly handling the passing of D wrapped C++ classes to and from 
 the C++ code.
   -using directors at the bottom of the inheritance tree to properly 
 pass virtual function calls of to inherited D class
   -Throwing C++ and D exceptions through the interface that has C 
 linkage.
   -Mapping of types from C++ to C to D.
 
 If this ever gets off the ground I am thinking of calling it WrapeD, the 
 lack of two p's is intentional.  I hope to have simpler interface file 
 system than swig.  Something looks more like SCons build files.
 
 -Joseph





 Aug 02 2006



  parent reply Joseph Lisee <jlisee umd.edu>  writes:


In article <eapnnc$14sh$1 digitaldaemon.com>,
 "Rémy J. A. Mouëza" <ray.jay.ay.moueza do.not.spam.gmail.com> wrote:


 I've done something close to what you discribe using Python ( C++ 
 wrapping using the output of gccxml ). You can have a look at it on 
 http://remy.moueza.free.fr. Gregor Richards has done better with BCD, 
 available on dsource, only using D and gccxml. Swig also output xml, 
 thus it is also possible to use it as an alternative to gccxml. I didn't 
 know doxygen could output an xml view of its analysis.
 Good luck.


I looked at your project about a week ago but did not have gccxml 
installed at the time and all of the comments as to what works, and what 
didn't work are in French.  I will give it a go and see what kind of 
code it produces.  

Could you translate the comments to French, or maybe just put the 
information on the website you provided above?

-Joseph



 Aug 02 2006



  parent reply =?ISO-8859-1?Q?=22R=E9my_J=2E_A=2E_Mou=EBza=22?=  writes:


Joseph Lisee a écrit :

 I looked at your project about a week ago but did not have gccxml 
 installed at the time and all of the comments as to what works, and what 
 didn't work are in French.  I will give it a go and see what kind of 
 code it produces.  
 
 Could you translate the comments to French, or maybe just put the 
 information on the website you provided above?
 
 -Joseph


Yes, I can.
By the time I've written those comments they were kind of log of the 
progress I was doing. They just lists problems that happened and that I 
resolved and a few things to improve. They were not intended to be used 
  as documentation.
I haven't updated the site for a long time, I will first resolve my ftp 
access and ftp client problems first and update the site with a 
translated version of these log messages.



 Aug 03 2006



  parent  =?ISO-8859-1?Q?=22R=E9my_J=2E_A=2E_Mou=EBza=22?=  writes:


Rémy J. A. Mouëza a écrit :

 Joseph Lisee a écrit :

 I looked at your project about a week ago but did not have gccxml 
 installed at the time and all of the comments as to what works, and 
 what didn't work are in French.  I will give it a go and see what kind 
 of code it produces. 
 Could you translate the comments to French, or maybe just put the 
 information on the website you provided above?

 -Joseph


 
 Yes, I can.
 By the time I've written those comments they were kind of log of the 
 progress I was doing. They just lists problems that happened and that I 
 resolved and a few things to improve. They were not intended to be used 
  as documentation.
 I haven't updated the site for a long time, I will first resolve my ftp 
 access and ftp client problems first and update the site with a 
 translated version of these log messages.


As I had problems with the firewall of my university and ftp 
connection,I used my wiki (I had forgotten I set up one, and just 
started to use it).
Translation of the french comments is available:
http://remy.moueza.free.fr/wikini/wakka.php?wiki=DeeWrapperGenerator

And I have written a few line on my feelings about that wrapper generator.



 Aug 07 2006



prev sibling next sibling parent reply Sean Kelly <sean f4.ca>  writes:


Walter Bright wrote:

 braddr puremagic.com wrote:

 I have been toying with D to bring myself up to speed and I found 
 myself writing
 a lot of unit tests, always a good thing.  In those unit tests I found 
 myself
 writing a lot of blocks like:

 if (cond)
 {
 writefln("some debugging output to make my life easier");
 assert(false);
 }

 I know many don't like unit tests to have output, but I do.


 
 Why not:
 
     assert(!cond); // some debugging output to make my life easier
 
 ? You'll need to go look at the source anyway when the assert trips, so 
 what advantage is there to print the comment?


Some applications ship with asserts left on, and the more information 
the user has about why the application just halted the better.  As 
others have noted, an optional message also allows state information to 
be conveyed, which can be useful in the absence of a core dump.


Sean



 May 31 2006



  parent reply "Derek Parnell" <derek psych.ward>  writes:


On Thu, 01 Jun 2006 04:38:50 +1000, Sean Kelly <sean f4.ca> wrote:


 Walter Bright wrote:

 braddr puremagic.com wrote:

 I have been toying with D to bring myself up to speed and I found  
 myself writing
 a lot of unit tests, always a good thing.  In those unit tests I found  
 myself
 writing a lot of blocks like:

 if (cond)
 {
 writefln("some debugging output to make my life easier");
 assert(false);
 }

 I know many don't like unit tests to have output, but I do.


  Why not:
      assert(!cond); // some debugging output to make my life easier
  ? You'll need to go look at the source anyway when the assert trips,  
 so what advantage is there to print the comment?


 Some applications ship with asserts left on, and the more information  
 the user has about why the application just halted the better.  As  
 others have noted, an optional message also allows state information to  
 be conveyed, which can be useful in the absence of a core dump.


And this is a deployment/development strategy that is flawed. It would be  
better to ship a product without asserts turned on, but if you have to  
show internal issues to a customer then don't use asserts - use exceptions  
or similar to do this at run time. Just use asserts for quality assurance  
prior to shipping.

For me, the golden rule with D is don't use asserts to report errors in  
production releases.



-- 
Derek Parnell
Melbourne, Australia



 May 31 2006



 next sibling parent  BCS <BCS pathlink.com>  writes:


Derek Parnell wrote:

 On Thu, 01 Jun 2006 04:38:50 +1000, Sean Kelly <sean f4.ca> wrote:
 

 Some applications ship with asserts left on, and the more information  
 the user has about why the application just halted the better.  As  
 others have noted, an optional message also allows state information 
 to  be conveyed, which can be useful in the absence of a core dump.


 
 And this is a deployment/development strategy that is flawed. It would 
 be  better to ship a product without asserts turned on, but if you have 
 to  show internal issues to a customer then don't use asserts - use 
 exceptions  or similar to do this at run time. Just use asserts for 
 quality assurance  prior to shipping.
 
 For me, the golden rule with D is don't use asserts to report errors in  
 production releases.
 



An assert is just syntactic sugar for something like:

if(!(cond)) throw new AssertError(__FILE__":"~itoa!(__LINE__)~" Assert 
ERROR")

so they are exceptions.

As to not reporting asserts to the user, how about making asserts go to 
a special Stream object that can be redirected to a file or something 
(if it goes to stderr we're most of the way there). That with a 
backtrace log could make for a vary powerful bug hunting tool.



 May 31 2006



prev sibling  parent reply Sean Kelly <sean f4.ca>  writes:


Derek Parnell wrote:

 On Thu, 01 Jun 2006 04:38:50 +1000, Sean Kelly <sean f4.ca> wrote:
 

 Walter Bright wrote:

 braddr puremagic.com wrote:

 I have been toying with D to bring myself up to speed and I found 
 myself writing
 a lot of unit tests, always a good thing.  In those unit tests I 
 found myself
 writing a lot of blocks like:

 if (cond)
 {
 writefln("some debugging output to make my life easier");
 assert(false);
 }

 I know many don't like unit tests to have output, but I do.


  Why not:
      assert(!cond); // some debugging output to make my life easier
  ? You'll need to go look at the source anyway when the assert trips, 
 so what advantage is there to print the comment?


 Some applications ship with asserts left on, and the more information 
 the user has about why the application just halted the better.  As 
 others have noted, an optional message also allows state information 
 to be conveyed, which can be useful in the absence of a core dump.


 
 And this is a deployment/development strategy that is flawed. It would 
 be better to ship a product without asserts turned on, but if you have 
 to show internal issues to a customer then don't use asserts - use 
 exceptions or similar to do this at run time. Just use asserts for 
 quality assurance prior to shipping.


There's a popular argument connected to contract programming which says 
that it makes no sense to test with contracts enabled and disable them 
in the release code.  I'd prefer not to take sides here, but I do think 
that in instances where the application should halt because a condition 
has not been met, an assert should be used.  If the programmer would 
prefer that the user not see file and line information, he can easily 
catch the error in main, report it however he wants to, and then return.

That said, my real goal here is merely to make assert a bit more 
flexible so users aren't inclined to roll their own error handling 
routines simply because they want to provide context information.  The 
above example just happened to be the first I though of.


Sean



 May 31 2006



  parent reply kris <foo bar.com>  writes:


Sean Kelly wrote:
[snip]

 There's a popular argument connected to contract programming which says 
 that it makes no sense to test with contracts enabled and disable them 
 in the release code.  I'd prefer not to take sides here, but I do think 
 that in instances where the application should halt because a condition 
 has not been met, an assert should be used.  If the programmer would 
 prefer that the user not see file and line information, he can easily 
 catch the error in main, report it however he wants to, and then return.
 
 That said, my real goal here is merely to make assert a bit more 
 flexible so users aren't inclined to roll their own error handling 
 routines simply because they want to provide context information. 


Amen.

I find it surprising that the dmd support code still makes it awkward to 
add file & line number info to all exceptions. Asserts are no less vague 
in this respect. One has to wonder if this is deliberate or not?

On the other hand, Ares has provided for optional Exception file & line 
ctor arguments for at least a year.

Seems quite clear that people *want* more flexible assert and exception 
reporting. It also seems clear that everyone will roll their own if it's 
not provided as basic functionality. I certainly would like to add it to 
library code, since I suspect most folk would appreciate having it there :)

Is there a contrary argument or position? I mean, is there some negative 
aspect of enabling (optional) better error reporting?



 May 31 2006



  parent  Derek Parnell <derek psych.ward>  writes:


On Wed, 31 May 2006 17:05:16 -0700, kris wrote:


 Sean Kelly wrote:
 [snip]

 There's a popular argument connected to contract programming which says 
 that it makes no sense to test with contracts enabled and disable them 
 in the release code.  I'd prefer not to take sides here, but I do think 
 that in instances where the application should halt because a condition 
 has not been met, an assert should be used.  If the programmer would 
 prefer that the user not see file and line information, he can easily 
 catch the error in main, report it however he wants to, and then return.
 
 That said, my real goal here is merely to make assert a bit more 
 flexible so users aren't inclined to roll their own error handling 
 routines simply because they want to provide context information. 


 
 Amen.
 
 I find it surprising that the dmd support code still makes it awkward to 
 add file & line number info to all exceptions. Asserts are no less vague 
 in this respect. One has to wonder if this is deliberate or not?
 
 On the other hand, Ares has provided for optional Exception file & line 
 ctor arguments for at least a year.
 
 Seems quite clear that people *want* more flexible assert and exception 
 reporting. It also seems clear that everyone will roll their own if it's 
 not provided as basic functionality. I certainly would like to add it to 
 library code, since I suspect most folk would appreciate having it there :)
 
 Is there a contrary argument or position? I mean, is there some negative 
 aspect of enabling (optional) better error reporting?


I suspect that this is the real issue. Namely that it is possible to
provide additional information at runtime when an 'assert' fires, but to do
so is awkward in comparison to a simple "assert( <Expression> )" statement.

One could always do something like ...

// ---- file: massert.d ----
private import std.string;
void myassert(bool res, char[] f, long l, char[] msg)
{
    if (!res)
    {
        throw new Exception(std.string.format("ASSERT in File: %s(%s), %s",
             f, l, msg));
    }
}


// --- file: myapp.d -----
import massert;
import std.string;
void main(char[][] pArgs)
{
   myassert( pArgs.length >= 2, __FILE__, __LINE__,
             "Not enough args supplied" );
   myassert( pArgs[1].length >= 2, __FILE__, __LINE__,
        std.string.format("Arg1 '%s' too short", pArgs[1])
        );
}


but I concede that this is not pretty.

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Down with mediocracy!"
1/06/2006 10:55:52 AM



 May 31 2006



prev sibling  parent reply "Unknown W. Brackets" <unknown simplemachines.org>  writes:


Walter,

My most common use for having this is simple.

Consider an open source software.  Various versions of the same software 
are in use, each with different patches applied.

Let's say this happened to dmd, or gdc.  Let's say a compiler error 
occurred... this:

expression.c(379)

Because a patch has been applied to expression.c - a rather long one 
adding support for "x ?: y" or something else like that (maybe a bad 
example) the error actually shows:

expression.c(518)

The user, who has this patch, does not really know much about 
programming, and reports it to the original software developer. 
Eventually, after initial confusion, it becomes clear that patches are 
involved, and these are listed.  Eventually, the bug can be tracked down.

With a compiler, this is really not a common thing.  But with many other 
softwares, this is VERY common.  I have had a huge amount of experience 
with exactly this problem, although not in D.

It was not fun, and caused finding bugs, searching for solutions to 
common problems, and everything much much more difficult and time consuming.

Error messages in this software were eventually revamped to be logged 
with more extensive information.  It became rapidly easier to debug the 
software, and make it robust and bug free.  Searching for errors was no 
longer done by line number, resulting in a much higher rate of return - 
which meant our support team was much less bogged down by those requests.

I realize it doesn't benefit DMD much, but having some way to give more 
information than a line number (which, to some projects, is about as 
useful as dumping the value of a pointer at runtime) is extremely useful 
for many sorts of open source softwares.

It's also useless when you have people using/testing nightlies or 
frequent beta releases, a practice that generally helps to improve 
overall release quality.  You can't even tag the assert with a release 
tag or revision.  Even if not for the patches...

As it is, I guess the solution is simple.  Don't use assert, it's almost 
useless for any robust application development.  Roll your own instead, 
e.g. using if as Brad suggested.

-[Unknown]



 braddr puremagic.com wrote:

 I have been toying with D to bring myself up to speed and I found 
 myself writing
 a lot of unit tests, always a good thing.  In those unit tests I found 
 myself
 writing a lot of blocks like:

 if (cond)
 {
 writefln("some debugging output to make my life easier");
 assert(false);
 }

 I know many don't like unit tests to have output, but I do.


 
 Why not:
 
     assert(!cond); // some debugging output to make my life easier
 
 ? You'll need to go look at the source anyway when the assert trips, so 
 what advantage is there to print the comment?





 May 31 2006



  parent reply Derek Parnell <derek psych.ward>  writes:


On Wed, 31 May 2006 21:38:04 -0700, Unknown W. Brackets wrote:


 Walter,
 
 My most common use for having this is simple...


Excellent reply and I'm now convinced too.

As a heretical aside, with the almost released new version of Build, you
can do something like the C-styled assert macro.

You can define a macro replacement pattern such as ...

  regexp <:assert\s(.*)::(.*):>   =
         if (!($1)) {writefln(`%%s:%%s`, `$1`, `$2`); assert(0);}

and then write in your code  ...

  <:assert result != 0::Bad result:>

which will transform into ...

  if (!(result != 0)) {writefln(`%s:%s`, 
        `result != 0`, `Bad result`); assert(0);}

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Down with mediocracy!"
1/06/2006 3:48:31 PM



 May 31 2006



  parent reply kris <foo bar.com>  writes:


Derek Parnell wrote:

 On Wed, 31 May 2006 21:38:04 -0700, Unknown W. Brackets wrote:
 
 

Walter,

My most common use for having this is simple...


 
 
 Excellent reply and I'm now convinced too.
 
 As a heretical aside, with the almost released new version of Build, you
 can do something like the C-styled assert macro.
 
 You can define a macro replacement pattern such as ...
 
   regexp <:assert\s(.*)::(.*):>   =
          if (!($1)) {writefln(`%%s:%%s`, `$1`, `$2`); assert(0);}
 
 and then write in your code  ...
 
   <:assert result != 0::Bad result:>
 
 which will transform into ...
 
   if (!(result != 0)) {writefln(`%s:%s`, 
         `result != 0`, `Bad result`); assert(0);}
 


I wish I could understand why this is needed in Build, Derek ... Build 
is truly great, at what it does well. Now it apparently allows one to 
intimately tie their code to Build, for all eternity, by extending the D 
language? Does this new stuff slow it down even a tiny bit?

Sorry if this comes off a bit negative, but Build is just so good as it 
is. Still, it is your baby :)



 May 31 2006



  parent reply Derek Parnell <derek psych.ward>  writes:


On Wed, 31 May 2006 23:12:42 -0700, kris wrote:


 I wish I could understand why this is needed in Build, Derek ... Build 
 is truly great, at what it does well. Now it apparently allows one to 
 intimately tie their code to Build, for all eternity, by extending the D 
 language? Does this new stuff slow it down even a tiny bit?
 
 Sorry if this comes off a bit negative, but Build is just so good as it 
 is. Still, it is your baby :)


Not at all! I love to hear real users' feedback. 

Rest assured though that from a performance point of view, you won't notice
anything if you aren't using this facility, because it doesn't do text
preprocessing on ".d" files. Instead you have to explicitly use ".mac"
files which are transformed into ".d" files. However in the end, you are
not forced into using the text processing stuff, just like you are not
forced into using 'goto'.

One reason for extending Build is so I can use it to build things other
than D applications. But I've kept in mind the 'normal' case of using it
with D so that is where the performance bias is.

But there will now be a few milliseconds extra delay at start up time
because I've replaced a lot of hard-coded strings with user-definable ones,
which are cached when the program starts.


------
I just had a bit more of a go at an 'assert' macro and it can actually do
this ...

  regexp assert\((.*),(.*)\);   = 
       if (!($1)) {writefln(`%%s:%%s`, `$1`, $2); assert(0);}

used as ...

    assert(result != 0, "Bad result");

and comes out as ...

   if (!(result != 0)) {writefln(`%s:%s`, `result != 0`,  "Bad result");
assert(0);}


So Walter, if you want to stop this nasty abomination of source code abuse,
please allow coder defined messages in the built-in assert statement ;-)

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Down with mediocracy!"
1/06/2006 4:20:39 PM



 May 31 2006



 next sibling parent  kris <foo bar.com>  writes:


Derek Parnell wrote:

 Rest assured though that from a performance point of view, you won't notice
 anything if you aren't using this facility, because it doesn't do text
 preprocessing on ".d" files. Instead you have to explicitly use ".mac"
 files which are transformed into ".d" files.


Whew! Thanks :-D

[snip]

 So Walter, if you want to stop this nasty abomination of source code abuse,
 please allow coder defined messages in the built-in assert statement ;-)


Right on!



 May 31 2006



prev sibling next sibling parent  Daniel Keep <daniel.keep.lists gmail.com>  writes:


Derek Parnell wrote:

 On Wed, 31 May 2006 23:12:42 -0700, kris wrote:
 
 [snip]
 
 So Walter, if you want to stop this nasty abomination of source code abuse,
 please allow coder defined messages in the built-in assert statement ;-)
 


"Alright, this is a hold up!  No body move!

"Now, listen up; in this bag here I 'ave a three megaton regex macro
pre-processor, and I ain't afraids to use it!  If youse don't comply wit
my demands, you'll leave me no choice but to butcher your pristine
littl' language just like wot happened to C!

"First, make it so that we can prints us some bloody context from asserts!

"Second, we wants to bloody know where in a file the bloody exceptions
are commin' from, and no not everyone can figure out how to use bloody
WinDbg!

"Thirds, I wants me a bloody sandwich!"

"This is the police!  We have the newsgroups surrounded; come out with
your hands up, and the new version of build clearly visible or we'll
shoot you!"

"Oh 'ell."

--------------------

On a more serious note, this looks *evil*.  In a, y'know, really handy
kind of a way.

But what I've always wanted is something similar to what Nemerle has.
For example, this is how the 'for' structure is defined in Nemerle:













Everything inside the <[ ... ]> "quotes" is treated as the substitute
syntax tree.  The nice thing about this over plain old text substitution
is that it's all typesafe: it only allows you to substitute complete,
valid syntax trees.

Aside from that, you can also directly create and modify the AST (since
the "macro" is really just a function run by the compiler; the funky <[
... ]> quotes are just syntactic sugar).  Whatever you return from the
function is what replaces the macro use in the source file.

Anyway, just my AU$0.02.

	-- Daniel

-- 
Unlike Knuth, I have neither proven or tried the above; it may not even
make sense.

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



 Jun 01 2006



prev sibling  parent reply pragma <pragma_member pathlink.com>  writes:


In article <2dpe83lsz5rb.v7hpd58hsxeu.dlg 40tude.net>, Derek Parnell says...

One reason for extending Build is so I can use it to build things other
than D applications. But I've kept in mind the 'normal' case of using it
with D so that is where the performance bias is.


Its interesting that you mention this.  I recently drafted a parser-frontend
generator that generates .d code as output; it works a treat, but I'm presently
having to go through multiple build steps.  So, would "things other than D
applications" happen to cover preprocessors other than just .mac file handling?
;)


So Walter, if you want to stop this nasty abomination of source code abuse,
please allow coder defined messages in the built-in assert statement ;-)


Nice.

In a more serious, and on-topic note, I too believe that assert() could stand
some expansion to allow for more succinct error reporting.  It all comes down to
the matter of reporting "how and why" something breaks rather than just "where".

As a preface, I for one do not use an IDE when developing my software.  D seems
to do pretty well for me without it, although I'm still longing for
out-of-the-box stack tracing.

Anyway, so I run some code that trips on an assert, and it coughs up
"foobar.d(42)" as where I need to look.  The assert has done its job, as I go to

basically flying blind (no watch window and no stack trace), my next step is
almost always: add a writefln() before the assert to get some more information
as to how this happened.  Meshing those two steps seems like an obvious choice
to me.

Another way to look at it is in the use of static assert().  With the
compile-time regexp processor(s) out there, they halt on static assert() and
then cough up some rudimentary explaination as to *why* using pragma(msg).  I
wouldn't even consider either implementation usable without the msg/assert
idiom, so I don't really use them apart from each other.  In fact, I'll argue
that its impossible to meaningfully extend the compiler/D-grammar through
templates without using the two together; the library user just wouldn't have a
clue otherwise.

To sum up: I honestly feel that the two capabilities, assert() and writefln(),
should be merged into an extended assert() statment, for the sake of encouraging
better coding and library use.

- EricAnderton at yahoo



 Jun 01 2006



 next sibling parent reply Oskar Linde <oskar.lindeREM OVEgmail.com>  writes:


pragma wrote:

 In a more serious, and on-topic note, I too believe that assert() could stand
 some expansion to allow for more succinct error reporting.  It all comes down
to
 the matter of reporting "how and why" something breaks rather than just
"where".
 
 As a preface, I for one do not use an IDE when developing my software.  D seems
 to do pretty well for me without it, although I'm still longing for
 out-of-the-box stack tracing.
 
 Anyway, so I run some code that trips on an assert, and it coughs up
 "foobar.d(42)" as where I need to look.  The assert has done its job, as I go
to

 basically flying blind (no watch window and no stack trace), my next step is
 almost always: add a writefln() before the assert to get some more information
 as to how this happened.  Meshing those two steps seems like an obvious choice
 to me.


What I do is redefine the implementation of assert to do:

  *(cast(int *)0) = 0;

That way, I get a segmentation fault and a core dump that the debugger 
(gdb) is able to use to present me with a back trace and (all) local 
variables available for inspection. This is immensely more useful than 
letting assert throw an exception, which means losing all state and 
stack trace information.

/Oskar



 Jun 01 2006



  parent reply kris <foo bar.com>  writes:


Oskar Linde wrote:

 pragma wrote:

 Anyway, so I run some code that trips on an assert, and it coughs up
 "foobar.d(42)" as where I need to look.  The assert has done its job, 
 as I go to

 basically flying blind (no watch window and no stack trace), my next 
 step is
 almost always: add a writefln() before the assert to get some more 
 information
 as to how this happened.  Meshing those two steps seems like an 
 obvious choice
 to me.


 
 
 What I do is redefine the implementation of assert to do:
 
  *(cast(int *)0) = 0;
 
 That way, I get a segmentation fault and a core dump that the debugger 
 (gdb) is able to use to present me with a back trace and (all) local 
 variables available for inspection. This is immensely more useful than 
 letting assert throw an exception, which means losing all state and 
 stack trace information.
 
 /Oskar



And therein lies the key: what everyone is asking for is a means to 
capture additional state with the assert()

Ideally, all code-testing would be performed within the comforting arms 
of a debugger. But it doesn't happen that way and, due to Murphy's law, 
the one and only time your code trips up is when it's not in the 
debugger. That's when you need additional state to help track things 
down; especially with those "non repeatable" bugs.

Having said that, a very large part of the valuable state is the 
stack-trace ~ "how did we get here" can be just as important as some key 
variable. Often more so. Thus, I tend to look at assert as the bare 
minimum of tools; scraping the barrel, if you will. That goes to show 
how poor the runtime diagnostic support really is in D at this time ~ 
we're actually better off with printf() than most anythng else :)

Thus when all is said and done, having support for a stack-trace seems 
far more valuable than the 'convenience' of an assert message. Although 
in the absence of the former, it's easy to see why assert() gets so much 
attention.

Finally, I suspect adding printf formatting to assert() would be binding 
complexity at a delicate level; partly because the formatting might try 
to allocate memory?

Let's get stack-tracing supported, instead of depending upon the 
marginally useful assert() statement :D

- Kris



 Jun 01 2006



  parent reply James Dunne <james.jdunne gmail.com>  writes:


kris wrote:

 Oskar Linde wrote:
 

 pragma wrote:


 Anyway, so I run some code that trips on an assert, and it coughs up
 "foobar.d(42)" as where I need to look.  The assert has done its job, 
 as I go to

 basically flying blind (no watch window and no stack trace), my next 
 step is
 almost always: add a writefln() before the assert to get some more 
 information
 as to how this happened.  Meshing those two steps seems like an 
 obvious choice
 to me.




 What I do is redefine the implementation of assert to do:

  *(cast(int *)0) = 0;

 That way, I get a segmentation fault and a core dump that the debugger 
 (gdb) is able to use to present me with a back trace and (all) local 
 variables available for inspection. This is immensely more useful than 
 letting assert throw an exception, which means losing all state and 
 stack trace information.

 /Oskar


 
 
 
 And therein lies the key: what everyone is asking for is a means to 
 capture additional state with the assert()
 
 Ideally, all code-testing would be performed within the comforting arms 
 of a debugger. But it doesn't happen that way and, due to Murphy's law, 
 the one and only time your code trips up is when it's not in the 
 debugger. That's when you need additional state to help track things 
 down; especially with those "non repeatable" bugs.
 
 Having said that, a very large part of the valuable state is the 
 stack-trace ~ "how did we get here" can be just as important as some key 
 variable. Often more so. Thus, I tend to look at assert as the bare 
 minimum of tools; scraping the barrel, if you will. That goes to show 
 how poor the runtime diagnostic support really is in D at this time ~ 
 we're actually better off with printf() than most anythng else :)
 
 Thus when all is said and done, having support for a stack-trace seems 
 far more valuable than the 'convenience' of an assert message. Although 
 in the absence of the former, it's easy to see why assert() gets so much 
 attention.
 
 Finally, I suspect adding printf formatting to assert() would be binding 
 complexity at a delicate level; partly because the formatting might try 
 to allocate memory?
 
 Let's get stack-tracing supported, instead of depending upon the 
 marginally useful assert() statement :D
 
 - Kris


I'm sorry but I really have to insert my skepticism here about stack traces.

Upon first glance it sounds like a wonderful idea, until you get to 
where Java is at.  Literally hundreds of lines of stack traces dumped 
into log files to wade thru, most of them completely useless because: 
THEY DON'T CONTAIN STATE!!!

Sure they have the call-stack state so you can see where the function 
calls came from but there are no local variables, no function parameter 
values, no class/struct dumps; basically nothing useful for anything 
more complex than the simplest case of a deterministic function call, 
and even then it's not too terribly useful.

While I agree that it is better than nothing, we can still do better. 
An entire run-time debugging framework is what we really want to shoot 
for.  Exception logging, tracing, dumping of object contents, reading 
local variables, reading function parameters, etc.  This probably 
requires the help of a compile-time reflection system (where certain 
properties of objects are translated by the compiler into literal 
expressions).  Run-time reflection isn't really necessary.

-- 
Regards,
James Dunne



 Jun 01 2006



 next sibling parent  Brad Roberts <braddr puremagic.com>  writes:


On Thu, 1 Jun 2006, James Dunne wrote:


 I'm sorry but I really have to insert my skepticism here about stack traces.
 
 Upon first glance it sounds like a wonderful idea, until you get to where Java
 is at.  Literally hundreds of lines of stack traces dumped into log files to
 wade thru, most of them completely useless because: THEY DON'T CONTAIN
 STATE!!!
 
 Sure they have the call-stack state so you can see where the function calls
 came from but there are no local variables, no function parameter values, no
 class/struct dumps; basically nothing useful for anything more complex than
 the simplest case of a deterministic function call, and even then it's not too
 terribly useful.
 
 While I agree that it is better than nothing, we can still do better. An
 entire run-time debugging framework is what we really want to shoot for.
 Exception logging, tracing, dumping of object contents, reading local
 variables, reading function parameters, etc.  This probably requires the help
 of a compile-time reflection system (where certain properties of objects are
 translated by the compiler into literal expressions).  Run-time reflection
 isn't really necessary.
 
 -- 
 Regards,
 James Dunne


At that point, you really just want the core file.  Given the program 
image and the core, you can do all of the above.



 Jun 01 2006



prev sibling next sibling parent  kris <foo bar.com>  writes:


James Dunne wrote:

 I'm sorry but I really have to insert my skepticism here about stack 
 traces.
 
 Upon first glance it sounds like a wonderful idea, until you get to 
 where Java is at.  Literally hundreds of lines of stack traces dumped 
 into log files to wade thru, most of them completely useless because: 
 THEY DON'T CONTAIN STATE!!!
 
 Sure they have the call-stack state so you can see where the function 
 calls came from but there are no local variables, no function parameter 
 values, no class/struct dumps; basically nothing useful for anything 
 more complex than the simplest case of a deterministic function call, 
 and even then it's not too terribly useful.
 
 While I agree that it is better than nothing, we can still do better. An 
 entire run-time debugging framework is what we really want to shoot 
 for.  Exception logging, tracing, dumping of object contents, reading 
 local variables, reading function parameters, etc.  This probably 
 requires the help of a compile-time reflection system (where certain 
 properties of objects are translated by the compiler into literal 
 expressions).  Run-time reflection isn't really necessary.



Fair enough;

I find it vaguely interesting that there's been a log4j clone publicly 
available for 25 months now, yet I'm perhaps the only one who uses it -- 
lol -- what does that tell you? If anything?

:-D



 Jun 01 2006



prev sibling next sibling parent  Don Clugston <dac nospam.com.au>  writes:


James Dunne wrote:

 kris wrote:

 Oskar Linde wrote:


 pragma wrote:


 Anyway, so I run some code that trips on an assert, and it coughs up
 "foobar.d(42)" as where I need to look.  The assert has done its 
 job, as I go to

 I'm
 basically flying blind (no watch window and no stack trace), my next 
 step is
 almost always: add a writefln() before the assert to get some more 
 information
 as to how this happened.  Meshing those two steps seems like an 
 obvious choice
 to me.




 What I do is redefine the implementation of assert to do:

  *(cast(int *)0) = 0;

 That way, I get a segmentation fault and a core dump that the 
 debugger (gdb) is able to use to present me with a back trace and 
 (all) local variables available for inspection. This is immensely 
 more useful than letting assert throw an exception, which means 
 losing all state and stack trace information.

 /Oskar




 And therein lies the key: what everyone is asking for is a means to 
 capture additional state with the assert()

 Ideally, all code-testing would be performed within the comforting 
 arms of a debugger. But it doesn't happen that way and, due to 
 Murphy's law, the one and only time your code trips up is when it's 
 not in the debugger. That's when you need additional state to help 
 track things down; especially with those "non repeatable" bugs.

 Having said that, a very large part of the valuable state is the 
 stack-trace ~ "how did we get here" can be just as important as some 
 key variable. Often more so. Thus, I tend to look at assert as the 
 bare minimum of tools; scraping the barrel, if you will. That goes to 
 show how poor the runtime diagnostic support really is in D at this 
 time ~ we're actually better off with printf() than most anythng else :)

 Thus when all is said and done, having support for a stack-trace seems 
 far more valuable than the 'convenience' of an assert message. 
 Although in the absence of the former, it's easy to see why assert() 
 gets so much attention.

 Finally, I suspect adding printf formatting to assert() would be 
 binding complexity at a delicate level; partly because the formatting 
 might try to allocate memory?

 Let's get stack-tracing supported, instead of depending upon the 
 marginally useful assert() statement :D

 - Kris


 
 I'm sorry but I really have to insert my skepticism here about stack 
 traces.
 
 Upon first glance it sounds like a wonderful idea, until you get to 
 where Java is at.  Literally hundreds of lines of stack traces dumped 
 into log files to wade thru, most of them completely useless because: 
 THEY DON'T CONTAIN STATE!!!



 Sure they have the call-stack state so you can see where the function 
 calls came from but there are no local variables, no function parameter 
 values, no class/struct dumps; basically nothing useful for anything 
 more complex than the simplest case of a deterministic function call, 
 and even then it's not too terribly useful.




 While I agree that it is better than nothing, we can still do better. An 
 entire run-time debugging framework is what we really want to shoot 
 for.  Exception logging, tracing, dumping of object contents, reading 
 local variables, reading function parameters, etc.  This probably 
 requires the help of a compile-time reflection system (where certain 
 properties of objects are translated by the compiler into literal 
 expressions).  Run-time reflection isn't really necessary.



I have to disagree with this. A stack trace does give you the most 
important piece of state information: the value of function pointers and 
delegates that are called. Personally, I don't think I've ever learnt 
much from a debugger other than seeing the call stack; it gives a list 
of all the places to look at for bugs (and the places to put more 
asserts into!). It covers >90% of the use cases.



 Jun 02 2006



prev sibling  parent  BCS <BCS_member pathlink.com>  writes:


In article <e5odr1$2mis$1 digitaldaemon.com>, James Dunne says...


[...]

I'm sorry but I really have to insert my skepticism here about stack traces.

Upon first glance it sounds like a wonderful idea, until you get to 
where Java is at.  Literally hundreds of lines of stack traces dumped 
into log files to wade thru, most of them completely useless because: 
THEY DON'T CONTAIN STATE!!!


A lot of state can be gained with scope(failure) statements. I have a program
where (as an experiment) every function is prefaced with:



If I needed some state a few more scope(failure) line would do this quite
nicely.

I will grant, just an automated stack trace might not be to useful, but throwing

idea where things stand.

OTOH if I was trying to run an automated bug tracking system that gets reports
from crashed sessions, a stack trace would be exactly where I would start.



Sure they have the call-stack state so you can see where the function 
calls came from but there are no local variables, no function parameter 
values, no class/struct dumps; basically nothing useful for anything 
more complex than the simplest case of a deterministic function call, 
and even then it's not too terribly useful.

While I agree that it is better than nothing, we can still do better. 
An entire run-time debugging framework is what we really want to shoot 
for.  Exception logging, tracing, dumping of object contents, reading 
local variables, reading function parameters, etc.  This probably 
requires the help of a compile-time reflection system (where certain 
properties of objects are translated by the compiler into literal 
expressions).  Run-time reflection isn't really necessary.

-- 
Regards,
James Dunne





 Jun 02 2006



prev sibling next sibling parent reply Sean Kelly <sean f4.ca>  writes:


pragma wrote:

 
 Another way to look at it is in the use of static assert().  With the
 compile-time regexp processor(s) out there, they halt on static assert() and
 then cough up some rudimentary explaination as to *why* using pragma(msg).  I
 wouldn't even consider either implementation usable without the msg/assert
 idiom, so I don't really use them apart from each other.  In fact, I'll argue
 that its impossible to meaningfully extend the compiler/D-grammar through
 templates without using the two together; the library user just wouldn't have a
 clue otherwise.


Good point.  If this change were made, would it apply to static assert 
as well?  It would certainly be nice.


Sean



 Jun 01 2006



  parent reply Don Clugston <dac nospam.com.au>  writes:


Sean Kelly wrote:

 pragma wrote:

 Another way to look at it is in the use of static assert().  With the
 compile-time regexp processor(s) out there, they halt on static 
 assert() and
 then cough up some rudimentary explaination as to *why* using 
 pragma(msg).  I
 wouldn't even consider either implementation usable without the 
 msg/assert
 idiom, so I don't really use them apart from each other.  In fact, 
 I'll argue
 that its impossible to meaningfully extend the compiler/D-grammar through
 templates without using the two together; the library user just 
 wouldn't have a
 clue otherwise.




[ie, just like C++!]
That's my experience too. It's possible to have excellent usability now 
that we have sudden-death static asserts.



 Good point.  If this change were made, would it apply to static assert 
 as well?  It would certainly be nice.


The case for a message in static assert is very much stronger than for 
assert.
(a) You don't have a debugger -- there's no way of finding what's going 
on apart from seeing the assert.
(b) The message is always for the programmer, not the end user.
(c) Established practice is to use pragma(msg) with static assert(0).

My code is littered with:

static if (!cond) {
   pragma(msg, "xxx");
   static assert(0);
}

It would be so much cleaner to replace this with
static assert(cond, "xxx");
(and it would accentuate the superiority of D templates over C++).



 Jun 02 2006



  parent  "Unknown W. Brackets" <unknown simplemachines.org>  writes:


I use:

static assert ("Message", 0);

Which gives a message similar to:

static assert  ("Message" , 0) is false

-[Unknown]



 My code is littered with:
 
 static if (!cond) {
   pragma(msg, "xxx");
   static assert(0);
 }





 Jun 02 2006



prev sibling  parent  Thomas Kuehne <thomas-dloop kuehne.cn>  writes:


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

pragma schrieb am 2006-06-01:

 To sum up: I honestly feel that the two capabilities, assert() and writefln(),
 should be merged into an extended assert() statment, for the sake of
encouraging
 better coding and library use.


That's easy:
















Thomas


-----BEGIN PGP SIGNATURE-----

iD8DBQFEf1ix3w+/yD4P9tIRAjo6AJ9jH5cEKVNBjPCDAfi/MO14xqSumACfQMem
fhE84xqWoqTYtOg895pDA58=
=0sAG
-----END PGP SIGNATURE-----



 Jun 01 2006