Has anyone played with the new assert semantics? I find them a significant step down from before.

Consider:

int x;
...
assert(x == 2, text(x));

I'm not seeing an actual message informing that an assertion has failed! In case it does fail the text is just printed and as such it is indistinguishable from regular debug chatter.

Walter, please revert the semantics of assert. This can't be worked with.

If you do want to improve things, please have assert abort the current unittest and continue to the next one. The current semantics is unbearable.


Andrei

Andrei Alexandrescu wrote:
>
> If you do want to improve things, please have assert abort the current unittest and continue to the next one.

Vote++;

On Jun 27, 2010, at 11:32 PM, Andrei Alexandrescu <andrei at erdani.com> wrote:

> Has anyone played with the new assert semantics? I find them a significant step down from before.

No, and I'm not looking forward to it either! My asserts are sprinkled in unittests, helper functions, contracts, and in the main codebase. The current scheme is unnatural for me.


> 
> Consider:
> 
> int x;
> ...
> assert(x == 2, text(x));
> 
> I'm not seeing an actual message informing that an assertion has failed! In case it does fail the text is just printed and as such it is indistinguishable from regular debug chatter.
> 
> Walter, please revert the semantics of assert. This can't be worked with.
> 
> If you do want to improve things, please have assert abort the current unittest and continue to the next one. The current semantics is unbearable.

This is the basic scheme I had assumed before reading through the changeset. I can't appreciate Walter's performance concerns since I don't really know their impacts. I na?vely assume a global could be set which changes behavior from an abort to an error (exception)

Jason House wrote:
> On Jun 27, 2010, at 11:32 PM, Andrei Alexandrescu <andrei at erdani.com> wrote:
>
> 
>> Has anyone played with the new assert semantics? I find them a significant step down from before.
>> 
>
> No, and I'm not looking forward to it either! My asserts are sprinkled in unittests, helper functions, contracts, and in the main codebase. The current scheme is unnatural for me.
>
>
> 
>> Consider:
>>
>> int x;
>> ...
>> assert(x == 2, text(x));
>>
>> I'm not seeing an actual message informing that an assertion has failed! In case it does fail the text is just printed and as such it is indistinguishable from regular debug chatter.
>>
>> Walter, please revert the semantics of assert. This can't be worked with.
>>
>> If you do want to improve things, please have assert abort the current unittest and continue to the next one. The current semantics is unbearable.
>> 
>
> This is the basic scheme I had assumed before reading through the changeset. I can't appreciate Walter's performance concerns since I don't really know their impacts. I na?vely assume a global could be set which changes behavior from an abort to an error (exception)
> 

For that matter why should asserts use the same code gen inside unittest as out? Yes I know it's just easier to do it that way but but while making them different is non-trivial (I assume) I can't think it would be hard enough to rule it out. There is already more than one way they get implemented (with and without -release) and other things (like break/continue/goto/return, inside and out a foreach via opApply) radically change implementation depending on context.

On Jun 27, 2010, at 8:32 PM, Andrei Alexandrescu wrote:

> Has anyone played with the new assert semantics? I find them a significant step down from before.
> 
> Consider:
> 
> int x;
> ...
> assert(x == 2, text(x));
> 
> I'm not seeing an actual message informing that an assertion has failed! In case it does fail the text is just printed and as such it is indistinguishable from regular debug chatter.
> 
> Walter, please revert the semantics of assert. This can't be worked with.
> 
> If you do want to improve things, please have assert abort the current unittest and continue to the next one. The current semantics is unbearable.

Yup, hate it.  I'd like each each unittest block to have its own entry in the ModuleInfo struct.  Then it would be a library issue to determine what granularity (or if) tests should be resumed.  If we really want a "report but don't throw" routine I'd prefer it be a library function named something like validate().  There's no reason to mess with the behavior of assert in this way.

I thought this was the way it worked!  It needs to work this way, because often times, further parts of the same unit test depend on the prior parts passing.

I assumed that assert was still throwing, and being caught outside the unit test.  Something like this would be fine:

unittest
{
   x = new X;
   assert(x);
   x.foo();
}

translates to:

unittest
{
   try
   {
       x = new X;
       assert(x);
       x.foo();
   }
   catch(AssertionError e)
   {
       printAssertion(e);
   }
}

-Steve



----- Original Message ----
> From: Andrei Alexandrescu <andrei at erdani.com>
> If you do want to improve
> things, please have assert abort the current unittest and continue to the next
> one. The current semantics is
> unbearable.

Because a unittest assert may not originate inside a unittest block.  If you call a regular function inside a unit test and it asserts, should that function use the normal assert codegen or the unittest codegen?

-Steve



----- Original Message ----
> From: Benjamin Shropshire <benjamin at precisionsoftware.us>
For that
> matter why should asserts use the same code gen inside unittest
as out?

Steve Schveighoffer wrote:
> Because a unittest assert may not originate inside a unittest block.  If you call a regular function inside a unit test and it asserts, should that function use the normal assert codegen or the unittest codegen?
>
> -Steve
>
> 

Oh, duh. Now I even remember that thread.

>
> ----- Original Message ----
> 
>> From: Benjamin Shropshire <benjamin at precisionsoftware.us>
>> 
> For that
> 
>> matter why should asserts use the same code gen inside unittest
>> 
> as out?
>
>
>
> 
> _______________________________________________
> dmd-internals mailing list
> dmd-internals at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-internals
>
> 

Walter, any progress on this? I understand that there is little time to tend to various issues, but in this case you have actually spent time on something that is a net pessimization.

Prior to this change all I had to do was make unittest and watch it failing. Now I need to actually scan visually the standard output after each run, otherwise failures count as successes (zero exit code).

Please revert the semantics of assert.


Thanks,

Andrei

On 06/27/2010 10:32 PM, Andrei Alexandrescu wrote:
> Has anyone played with the new assert semantics? I find them a significant step down from before.
>
> Consider:
>
> int x;
> ...
> assert(x == 2, text(x));
>
> I'm not seeing an actual message informing that an assertion has failed! In case it does fail the text is just printed and as such it is indistinguishable from regular debug chatter.
>
> Walter, please revert the semantics of assert. This can't be worked with.
>
> If you do want to improve things, please have assert abort the current unittest and continue to the next one. The current semantics is unbearable.
>
>
> Andrei