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

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.

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:

# ubyte[] a = new ubyte[4096]; // src1
# ubyte[] b = new ubyte[4096]; // src2
# ubyte[] c = new ubyte[4096]; // dst
# ubyte[] d = new ubyte[4096]; // result calculated "long hand"
#
# // ...
#
# adds(a, b, c);
# assert(c == d);

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:

# assertArrayEqual(c, d);

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/

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:
> 
> # ubyte[] a = new ubyte[4096]; // src1
> # ubyte[] b = new ubyte[4096]; // src2
> # ubyte[] c = new ubyte[4096]; // dst
> # ubyte[] d = new ubyte[4096]; // result calculated "long hand"
> #
> # // ...
> #
> # adds(a, b, c);
> # assert(c == d);
> 
> 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:
> 
> # assertArrayEqual(c, d);
> 
> 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

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:
>>
>> # ubyte[] a = new ubyte[4096]; // src1
>> # ubyte[] b = new ubyte[4096]; // src2
>> # ubyte[] c = new ubyte[4096]; // dst
>> # ubyte[] d = new ubyte[4096]; // result calculated "long hand"
>> #
>> # // ...
>> #
>> # adds(a, b, c);
>> # assert(c == d);
>>
>> 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:
>>
>> # assertArrayEqual(c, d);
>>
>> 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
>>
> 
> 

# try
# {
#     // ...
# }
# catch( Exception e )
# {
#     // Hmm... nevermind
#     throw e;
# }

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/

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?

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.

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

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])
{
msg = "element #" ~ toString(i) ~ " unequal";
return false;
}
msg = "somthings wrong";
return false;
}

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

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");).

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