On 3/30/15 4:26 PM, Dicebot wrote:
> Main problem with changing default formatting is that it is pretty hard
> to choose one that is 100% right.

It's very easy - format asserts occuring directly in unittests the same as compilation errors. I don't see why this would be ever debated. -- Andrei

On 31/03/2015 1:08 p.m., deadalnix wrote:
> That would be great if we could JIT the unitests at build time...

While we are at it, how about improving CTFE to be fully JIT'd and support calling external code? That way it is only a small leap to add unittests to be CTFE'd.

On Tuesday, 31 March 2015 at 00:49:41 UTC, Rikki Cattermole wrote:
> On 31/03/2015 1:08 p.m., deadalnix wrote:
>> That would be great if we could JIT the unitests at build time...
>
> While we are at it, how about improving CTFE to be fully JIT'd and support calling external code? That way it is only a small leap to add unittests to be CTFE'd.

I wouldn't go that far as to add external calls into CTFE, but yeah, that's pretty much the way I see things going.

On 31/03/2015 2:07 p.m., deadalnix wrote:
> On Tuesday, 31 March 2015 at 00:49:41 UTC, Rikki Cattermole wrote:
>> On 31/03/2015 1:08 p.m., deadalnix wrote:
>>> That would be great if we could JIT the unitests at build time...
>>
>> While we are at it, how about improving CTFE to be fully JIT'd and
>> support calling external code? That way it is only a small leap to add
>> unittests to be CTFE'd.
>
> I wouldn't go that far as to add external calls into CTFE, but yeah,
> that's pretty much the way I see things going.

Yeah, there is a lot of pros and cons to adding it. But the thing is, we are not pushing CTFE as far as it can go. We really aren't. And in some ways I like it. It makes it actually easier to work with in a lot of ways.

2015-03-31 2:46 GMT+02:00 Andrei Alexandrescu via Digitalmars-d < digitalmars-d@puremagic.com>:

> On 3/30/15 4:15 PM, Mathias Lang via Digitalmars-d wrote:
>
>> I'd rather see DMD automatically pass the expression that triggered the error (as it is done in C) to replace this useless "Unittest failure" that forces me to look through the code.
>>
>
> Often you need the context.
>

Often, not always. You doesn't loose any information by displaying the expression.



>  D has the advantage that it catches most errors at CT. You can write a
>> lot of code and just compile it to ensure it's more or less correct. I often write code that won't pass the unittests, but I need to check if my template / CT logic is correct. It may takes 20 compilations cycle before I run the unittests. Running the tests as part of the build would REALLY slow down the process -especially given that unittest is communicated to imported module, which means imported libraries. You don't want to catch unittests failures on every compilation cycle, but rather before your code make it to the repo - that's what CI systems are for -.
>>
>
> I disagree.
>
>
> Andrei
>
>
As you are entitled to. But I don't see any argument here.

On Mon, 30 Mar 2015 22:30:17 +0000, Dicebot wrote:

> tl: dr: please, no
> 
> We have put quite some effort into fighting default DMD behaviour of -unittest simply adding to main function and not replacing it. Initially many applications did run tests on startup because DMD suggested it is a good idea - some rather bad practical experience has shown this was a rather bad suggestion. Accidental tests that start doing I/O on productions servers, considerably increased restart times for services - that kind of issues.
> 
> And if you suggest to build both test and normal build as part of single compiler call (building test version silently in the background) this is also very confusing addition hardly worth its gain.
> 
> Just tweak your editors if that is truly important. It is not like being able to click some fancy lines in GUI makes critical usability addition to testing.

ah, i see.
* building new phobos version now: several seconds.
* building new phobos version with unittests now: several minutes.

with your suggesion:
* building new phobos version: several minutes.
* building new phobos version with unittests: several minutes.

yep, it's great. i was dreamt of such long compile sessions since i learned that compilers can be fast.

On Tue, 31 Mar 2015 03:29:38 +0000, ketmar wrote:

p.s. $#^&^#%! pan is buggy, the previous meant to be the answer to OP post.

On 3/30/15 7:14 PM, Mathias Lang via Digitalmars-d wrote:
> As you are entitled to. But I don't see any argument here.

The thing here is you're not forced to build both the unittest version and the deployed version. It's an opt-in thing. The problem currently is we format error messages badly so we make Good Things difficult. -- Andrei

A band-aid rather than a solution, but sticking this in .emacs/init.el will fix up emacs to do the right thing with asserts (only tested with DMD).

Cheers,

A.

(add-to-list 'compilation-error-regexp-alist
		'("^object\.Exception@\\(.*\\)(\\([0-9]+\\)).*"
		  1 2 ) )

On Tuesday, 31 March 2015 at 08:10:19 UTC, Andy Smith wrote:
>
> A band-aid rather than a solution, but sticking this in .emacs/init.el will fix up emacs to do the right thing with asserts (only tested with DMD).
>
> Cheers,
>
> A.
>
> (add-to-list 'compilation-error-regexp-alist
> 		'("^object\.Exception@\\(.*\\)(\\([0-9]+\\)).*"
> 		  1 2 ) )

Ah - didn't test for your specific example...

Need..

(add-to-list 'compilation-error-regexp-alist
		'("^core\.exception.AssertError@\\(.*\\)(\\([0-9]+\\)).*"
		  1 2 ) )

as well.... not sure how many variants of these there are but if regexps can't handle it am sure elisp can....

Cheers,

A.