core.exception.AssertError at std/datetime.d(842): _assertPred!("opCmp", "<") failed: [-1999-Jan-01 23:59:59] ==
[-1999-Jan-01 23:59:59].

Nothing changed near the phobos portion of this code, and it's been failing since this set of changes on all but windows.  The only reason windows isn't failing, I suspect, is that a bunch of the datetime tests are versioned out.

http://d.puremagic.com/test-results/test_data.ghtml?dataid=62797

>From git://github.com/D-Programming-Language/dmd
   587fa66..3888ff0  master     -> origin/master
Updating 587fa66..3888ff0
Fast-forward
 src/constfold.c              |   12 +-
 src/interpret.c              |  978 ++++++++++++++++++++----------------------
 test/compilable/interpret3.d |  240 +++++++++++
 3 files changed, 712 insertions(+), 518 deletions(-)

Later,
Brad

That change fixed some awful CTFE wrong-code bugs, so it is possible
that some erroneous code used to pass.
We need a reduced test case. And once again, the enormous size of
std.datetime hurts us.


On 19 May 2011 09:18, Brad Roberts <braddr at puremagic.com> wrote:
> core.exception.AssertError at std/datetime.d(842): _assertPred!("opCmp", "<") failed: [-1999-Jan-01 23:59:59] ==
> [-1999-Jan-01 23:59:59].
>
> Nothing changed near the phobos portion of this code, and it's been failing since this set of changes on all but windows. ?The only reason windows isn't failing, I suspect, is that a bunch of the datetime tests are versioned out.
>
> http://d.puremagic.com/test-results/test_data.ghtml?dataid=62797
>
> From git://github.com/D-Programming-Language/dmd
> ? 587fa66..3888ff0 ?master ? ? -> origin/master
> Updating 587fa66..3888ff0
> Fast-forward
> ?src/constfold.c ? ? ? ? ? ? ?| ? 12 +-
> ?src/interpret.c ? ? ? ? ? ? ?| ?978 ++++++++++++++++++++----------------------
> ?test/compilable/interpret3.d | ?240 +++++++++++
> ?3 files changed, 712 insertions(+), 518 deletions(-)
>
> Later,
> Brad
> _______________________________________________
> dmd-internals mailing list
> dmd-internals at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-internals
>

On 2011-05-19 00:18, Brad Roberts wrote:
> core.exception.AssertError at std/datetime.d(842): _assertPred!("opCmp", "<")
> failed: [-1999-Jan-01 23:59:59] == [-1999-Jan-01 23:59:59].
> 
> Nothing changed near the phobos portion of this code, and it's been failing since this set of changes on all but windows.  The only reason windows isn't failing, I suspect, is that a bunch of the datetime tests are versioned out.
> 
> http://d.puremagic.com/test-results/test_data.ghtml?dataid=62797
> 
> From git://github.com/D-Programming-Language/dmd
>    587fa66..3888ff0  master     -> origin/master
> Updating 587fa66..3888ff0
> Fast-forward
>  src/constfold.c              |   12 +-
>  src/interpret.c              |  978
> ++++++++++++++++++++---------------------- test/compilable/interpret3.d |
> 240 +++++++++++
>  3 files changed, 712 insertions(+), 518 deletions(-)

At present, I believe that _all_ of std.datetime's unit tests have been versioned out on Windows due to http://d.puremagic.com/issues/show_bug.cgi?id=5454 . I'm hoping that once I've finished reworking std.datetime's unit tests, we'll luck out and 5454 won't cause it to run out of memory anymore, but we'll have to wait and see. They passed last time I ran the tests separately from the rest of Phobos though (which was before committing the last set of changes to std.datetime), so they should still be passing as long as dmd doesn't regress.

- Jonathan M Davis

How is this related to the size of std.datetime?? It's pretty clear the failure is on line 842.

Just isolate that line and its related setup, and you should find the minimal test case.? Or am I missing something?


-Steve


>________________________________
>From: Don Clugston <dclugston at googlemail.com>
>To: Discuss the internals of DMD <dmd-internals at puremagic.com>
>Sent: Thursday, May 19, 2011 3:43 AM
>Subject: Re: [dmd-internals] test failures
>
>That change fixed some awful CTFE wrong-code bugs, so it is possible
>that some erroneous code used to pass.
>We need a reduced test case. And once again, the enormous size of
>std.datetime hurts us.
>
>
>On 19 May 2011 09:18, Brad Roberts <braddr at puremagic.com> wrote:
>> core.exception.AssertError at std/datetime.d(842): _assertPred!("opCmp", "<") failed: [-1999-Jan-01 23:59:59] ==
>> [-1999-Jan-01 23:59:59].
>>
>> Nothing changed near the phobos portion of this code, and it's been failing since this set of changes on all but windows. ?The only reason windows isn't failing, I suspect, is that a bunch of the datetime tests are versioned out.
>>
>> http://d.puremagic.com/test-results/test_data.ghtml?dataid=62797
>>
>> From git://github.com/D-Programming-Language/dmd
>> ? 587fa66..3888ff0 ?master ? ? -> origin/master
>> Updating 587fa66..3888ff0
>> Fast-forward
>> ?src/constfold.c ? ? ? ? ? ? ?| ? 12 +-
>> ?src/interpret.c ? ? ? ? ? ? ?| ?978 ++++++++++++++++++++----------------------
>> ?test/compilable/interpret3.d | ?240 +++++++++++
>> ?3 files changed, 712 insertions(+), 518 deletions(-)
>>
>> Later,
>> Brad
>> _______________________________________________
>> dmd-internals mailing list
>> dmd-internals at puremagic.com
>> http://lists.puremagic.com/mailman/listinfo/dmd-internals
>>
>_______________________________________________
>dmd-internals mailing list
>dmd-internals at puremagic.com
>http://lists.puremagic.com/mailman/listinfo/dmd-internals
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/dmd-internals/attachments/20110519/d6ae364b/attachment-0001.html>

On 19 May 2011 12:45, Steve Schveighoffer <schveiguy at yahoo.com> wrote:

> How is this related to the size of std.datetime?  It's pretty clear the failure is on line 842.
>

> Just isolate that line and its related setup, and you should find the minimal test case.  Or am I missing something?
>

I believe the issue isn't std.datetime directly, but it takes time to narrow down a testcase from a 30kLoC file, even if you know the exact line that's failing!


> -Steve
>

-- 
Robert
http://octarineparrot.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/dmd-internals/attachments/20110519/4613e1a4/attachment.html>

On 19 May 2011 17:54, Robert <robert at octarineparrot.com> wrote:
> On 19 May 2011 12:45, Steve Schveighoffer <schveiguy at yahoo.com> wrote:
>>
>> How is this related to the size of std.datetime?? It's pretty clear the failure is on line 842.
>>
>> Just isolate that line and its related setup, and you should find the minimal test case.? Or am I missing something?

The "related setup" is the problem. It's scattered all through the file.

> I believe the issue isn't std.datetime directly, but it takes time to narrow down a testcase from a 30kLoC file, even if you know the exact line that's failing!

Apart from the size, a particular problem with std.datetime is that it
has unittests _inside_ struct declarations.
This makes the code practically unreadable, especially since those
unittests are enormous, and it makes bisection a very painful, manual
process. 30K lines with only a few blocks of unittests wouldn't be a
problem.

Previously, that single module has cost me at least twenty hours of time in bisecting bugs. I've spent a couple of hours on reducing down this bug already, and I'm still many hours away from a reduced test case. I find this extremely frustrating, since intrinsically it's a very simple module. Basically, it's unmaintainable code.

On 2011-05-20 00:16, Don Clugston wrote:
> On 19 May 2011 17:54, Robert <robert at octarineparrot.com> wrote:
> > On 19 May 2011 12:45, Steve Schveighoffer <schveiguy at yahoo.com> wrote:
> >> How is this related to the size of std.datetime?  It's pretty clear the failure is on line 842.
> >> 
> >> Just isolate that line and its related setup, and you should find the minimal test case.  Or am I missing something?
> 
> The "related setup" is the problem. It's scattered all through the file.
> 
> > I believe the issue isn't std.datetime directly, but it takes time to narrow down a testcase from a 30kLoC file, even if you know the exact line that's failing!
> 
> Apart from the size, a particular problem with std.datetime is that it
> has unittests _inside_ struct declarations.
> This makes the code practically unreadable, especially since those
> unittests are enormous, and it makes bisection a very painful, manual
> process. 30K lines with only a few blocks of unittests wouldn't be a
> problem.
> 
> Previously, that single module has cost me at least twenty hours of time in bisecting bugs. I've spent a couple of hours on reducing down this bug already, and I'm still many hours away from a reduced test case. I find this extremely frustrating, since intrinsically it's a very simple module. Basically, it's unmaintainable code.

Then what would improve it for you? I'm in the midst of reworking the unit tests, which will reduced the number of lines of code that they take up, but the tests due ensure that the code stays valid when changes are made. They're also far more maintainable when they're right next to what they're testing than when they're completely separate from what they're testing, though that does tend to separate the functions from each other. Searching and hopping to matching braces deals with that pretty well overall though - at least for me. If you want the unit tests to all be disabled, then just remove the line

    version = testStdDateTime;

(which is currently line# 143), and then you can enable unit tests that you care about individually by removing the version declaration in front of them. So, it's easy to stop the unit tests from being compiled in and only compile in those that you care about (if any).

Other than reducing the number of lines of codes of the unit tests (which I'm in the middle of, though it was partially done for this last release), what would help you when have to deal with std.datetime for fixing compiler bugs?

- Jonathan M Davis

On 5/20/11 2:16 AM, Don Clugston wrote:
> Apart from the size, a particular problem with std.datetime is that it
> has unittests _inside_ struct declarations.
> This makes the code practically unreadable, especially since those
> unittests are enormous, and it makes bisection a very painful, manual
> process. 30K lines with only a few blocks of unittests wouldn't be a
> problem.

Just a thought - how about a tool (that would go in the same dir as dmd and rdmd) called strip_unittest? It would read a D program and output to stdout the same program without unittests.

All we need is a D tokenizer (which we need anyway) and a small driver.


Andrei

On 20.05.2011 16:32, Andrei Alexandrescu wrote:
> On 5/20/11 2:16 AM, Don Clugston wrote:
>> Apart from the size, a particular problem with std.datetime is that it
>> has unittests _inside_ struct declarations.
>> This makes the code practically unreadable, especially since those
>> unittests are enormous, and it makes bisection a very painful, manual
>> process. 30K lines with only a few blocks of unittests wouldn't be a
>> problem.
>
> Just a thought - how about a tool (that would go in the same dir as dmd and rdmd) called strip_unittest? It would read a D program and output to stdout the same program without unittests.
>
> All we need is a D tokenizer (which we need anyway) and a small driver.
>

Visual D has a "token replacer" that allows to do this: http://www.dsource.org/projects/visuald/wiki/Tour/TokenReplace

replacing "unittest { $anything }" with "unittest { }" (to not get into troubles with version conditionals before the unittest statement) reduces the size of datetime.d to about a third of its original size.

Rainer

On 20 May 2011 16:48, Rainer Schuetze <r.sagitario at gmx.de> wrote:
> On 20.05.2011 16:32, Andrei Alexandrescu wrote:
>>
>> On 5/20/11 2:16 AM, Don Clugston wrote:
>>>
>>> Apart from the size, a particular problem with std.datetime is that it
>>> has unittests _inside_ struct declarations.
>>> This makes the code practically unreadable, especially since those
>>> unittests are enormous, and it makes bisection a very painful, manual
>>> process. 30K lines with only a few blocks of unittests wouldn't be a
>>> problem.
>>
>> Just a thought - how about a tool (that would go in the same dir as dmd and rdmd) called strip_unittest? It would read a D program and output to stdout the same program without unittests.
>>
>> All we need is a D tokenizer (which we need anyway) and a small driver.
>>
>
> Visual D has a "token replacer" that allows to do this: http://www.dsource.org/projects/visuald/wiki/Tour/TokenReplace
>
> replacing "unittest { $anything }" with "unittest { }" (to not get into troubles with version conditionals before the unittest statement) reduces the size of datetime.d to about a third of its original size.
>
> Rainer

This looks like exactly what I want. Unfortunately when I select that menu item, I just get a gray box. Presumably something's gone wrong in the installation (I just upgraded from a few versions back; VS shell 2008). Any ideas?