No, the one that every phobos test run shows.  eg http://yebblies.com/results/360_9rnsr_fix6529_phobostest.txt It's running on Ubuntu32.

On Sun, Sep 4, 2011 at 12:42 PM, David Simcha <dsimcha at gmail.com> wrote:
> On Sat, Sep 3, 2011 at 10:39 PM, Daniel Murphy <yebblies at gmail.com> wrote:
>>
>> On a side note, does anybody have any idea what's behind the phobos test failure?
>>
>
> If you mean the failure? that occurs intermittently on FreeBSD64, this is a segfault on exiting from the std.parallelism unittest.? I'm almost sure it's caused by Bug 6014 (http://d.puremagic.com/issues/show_bug.cgi?id=6014).? I have no idea why it seems to occur with std.parallelism and not other modules or FreeBSD64 and not other OS's.
>
> _______________________________________________
> dmd-internals mailing list
> dmd-internals at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-internals
>

It always fails on my ubuntu machine.

On Sun, Sep 4, 2011 at 2:58 PM, Don Clugston <dclugston at googlemail.com> wrote:
> On 4 September 2011 04:39, Daniel Murphy <yebblies at gmail.com> wrote:
>> I'm manually approving github users before testing their pull requests.
>>
>> Hopefully this will be enough.
>>
>> On a side note, does anybody have any idea what's behind the phobos test failure?
>
> Does std.datetime fail for you normally? Or is it only in your automated tester?
> _______________________________________________
> dmd-internals mailing list
> dmd-internals at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-internals
>

On Sunday, September 04, 2011 15:50:39 Daniel Murphy wrote:
> It always fails on my ubuntu machine.

What time zone is your machine using?

- Jonathan M Davis

Sydney (+10 ?)
~$ cat /etc/timezone
Australia/NSW


On Sun, Sep 4, 2011 at 4:29 PM, Jonathan M Davis <jmdavisProg at gmx.com> wrote:
> On Sunday, September 04, 2011 15:50:39 Daniel Murphy wrote:
>> It always fails on my ubuntu machine.
>
> What time zone is your machine using?
>
> - Jonathan M Davis
> _______________________________________________
> dmd-internals mailing list
> dmd-internals at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-internals
>

On Sunday, September 04, 2011 17:05:20 Daniel Murphy wrote:
> Sydney (+10 ?)
> ~$ cat /etc/timezone
> Australia/NSW

*Sigh* It looks like something is messed up with std.datetime dealing with that timezone. It looks like I get to go bug hunting...

- Jonathan M Davis

On Sunday, September 04, 2011 17:19:18 Jonathan M Davis wrote:
> On Sunday, September 04, 2011 17:05:20 Daniel Murphy wrote:
> > Sydney (+10 ?)
> > ~$ cat /etc/timezone
> > Australia/NSW
> 
> *Sigh* It looks like something is messed up with std.datetime dealing with that timezone. It looks like I get to go bug hunting...

LOL. Ouch. _That_ was dumb of me. I was trying to get the order of several time zones (including local time) in the tests, and somehow I managed to forget that diffing times ignores time zones (as it should). So, I subtracted the current time in UTC from the current time in local time (which inevitably is a matter of microseconds, because it's just the difference between two calls to Clock.currTime). The result is inevitably positive. West of UTC (as I and the autotester are) needs the result to be positive to order the time zones correctly, whereas east of UTC (as you are) needs the result to be negative - but it's positive. So, the time zones are in the wrong order for you, and the results are wrong. _This_ is why I like it when unit tests are dead stupid rather than trying to be clever and concise. It's so easy to screw them up when you try and be clever and concise. But no one likes the large number of dead stupid unit tests in std.datetime, so I've been trying to make them clever and concise. Bleh.

Oh well. At least I know what the problem is now. It shouldn't take very long to fix it.

- Jonathan M Davis

Heh.  Does that mean I'm the first person to run the std.datetime tests on linux in this hemisphere?

If the fix gets merged in soon I'll be able to re-run the tester and get some meaningful phobos results.  I've just added the druntime and phobos pulls to the tester.

On Sun, Sep 4, 2011 at 5:39 PM, Jonathan M Davis <jmdavisProg at gmx.com> wrote:
> On Sunday, September 04, 2011 17:19:18 Jonathan M Davis wrote:
>> On Sunday, September 04, 2011 17:05:20 Daniel Murphy wrote:
>> > Sydney (+10 ?)
>> > ~$ cat /etc/timezone
>> > Australia/NSW
>>
>> *Sigh* It looks like something is messed up with std.datetime dealing with that timezone. It looks like I get to go bug hunting...
>
> LOL. Ouch. _That_ was dumb of me. I was trying to get the order of several time zones (including local time) in the tests, and somehow I managed to forget that diffing times ignores time zones (as it should). So, I subtracted the current time in UTC from the current time in local time (which inevitably is a matter of microseconds, because it's just the difference between two calls to Clock.currTime). The result is inevitably positive. West of UTC (as I and the autotester are) needs the result to be positive to order the time zones correctly, whereas east of UTC (as you are) needs the result to be negative - but it's positive. So, the time zones are in the wrong order for you, and the results are wrong. _This_ is why I like it when unit tests are dead stupid rather than trying to be clever and concise. It's so easy to screw them up when you try and be clever and concise. But no one likes the large number of dead stupid unit tests in std.datetime, so I've been trying to make them clever and concise. Bleh.
>
> Oh well. At least I know what the problem is now. It shouldn't take very long to fix it.
>
> - Jonathan M Davis
> _______________________________________________
> dmd-internals mailing list
> dmd-internals at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-internals
>

On Sunday, September 04, 2011 17:48:43 Daniel Murphy wrote:
> Heh.  Does that mean I'm the first person to run the std.datetime tests on linux in this hemisphere?

You're the first one to report this problem, since the tests were updated to have this particular problem a few months back. Maybe all of the other active developers who would run into it are running Windows (where the tests are currently disabled).

- Jonathan M Davis

On Sunday, September 04, 2011 17:39:10 Jonathan M Davis wrote:
> On Sunday, September 04, 2011 17:19:18 Jonathan M Davis wrote:
> > On Sunday, September 04, 2011 17:05:20 Daniel Murphy wrote:
> > > Sydney (+10 ?)
> > > ~$ cat /etc/timezone
> > > Australia/NSW
> > 
> > *Sigh* It looks like something is messed up with std.datetime dealing with that timezone. It looks like I get to go bug hunting...
> 
> LOL. Ouch. _That_ was dumb of me. I was trying to get the order of several time zones (including local time) in the tests, and somehow I managed to forget that diffing times ignores time zones (as it should). So, I subtracted the current time in UTC from the current time in local time (which inevitably is a matter of microseconds, because it's just the difference between two calls to Clock.currTime). The result is inevitably positive. West of UTC (as I and the autotester are) needs the result to be positive to order the time zones correctly, whereas east of UTC (as you are) needs the result to be negative - but it's positive. So, the time zones are in the wrong order for you, and the results are wrong. _This_ is why I like it when unit tests are dead stupid rather than trying to be clever and concise. It's so easy to screw them up when you try and be clever and concise. But no one likes the large number of dead stupid unit tests in std.datetime, so I've been trying to make them clever and concise. Bleh.
> 
> Oh well. At least I know what the problem is now. It shouldn't take very long to fix it.

Blast it. It's worse than that. Your DST changes on April 1st, and apparently my tests can't cope with that at the moment. I'll have to rework them a bit, and it's going to take some time. I should have them fixed within a day or so, but I'm not going to get them sorted out tonight.

- Jonathan M Davis

No worries.

On Sun, Sep 4, 2011 at 7:05 PM, Jonathan M Davis <jmdavisProg at gmx.com> wrote:
> On Sunday, September 04, 2011 17:39:10 Jonathan M Davis wrote:
>> On Sunday, September 04, 2011 17:19:18 Jonathan M Davis wrote:
>> > On Sunday, September 04, 2011 17:05:20 Daniel Murphy wrote:
>> > > Sydney (+10 ?)
>> > > ~$ cat /etc/timezone
>> > > Australia/NSW
>> >
>> > *Sigh* It looks like something is messed up with std.datetime dealing with that timezone. It looks like I get to go bug hunting...
>>
>> LOL. Ouch. _That_ was dumb of me. I was trying to get the order of several time zones (including local time) in the tests, and somehow I managed to forget that diffing times ignores time zones (as it should). So, I subtracted the current time in UTC from the current time in local time (which inevitably is a matter of microseconds, because it's just the difference between two calls to Clock.currTime). The result is inevitably positive. West of UTC (as I and the autotester are) needs the result to be positive to order the time zones correctly, whereas east of UTC (as you are) needs the result to be negative - but it's positive. So, the time zones are in the wrong order for you, and the results are wrong. _This_ is why I like it when unit tests are dead stupid rather than trying to be clever and concise. It's so easy to screw them up when you try and be clever and concise. But no one likes the large number of dead stupid unit tests in std.datetime, so I've been trying to make them clever and concise. Bleh.
>>
>> Oh well. At least I know what the problem is now. It shouldn't take very long to fix it.
>
> Blast it. It's worse than that. Your DST changes on April 1st, and apparently my tests can't cope with that at the moment. I'll have to rework them a bit, and it's going to take some time. I should have them fixed within a day or so, but I'm not going to get them sorted out tonight.
>
> - Jonathan M Davis
> _______________________________________________
> dmd-internals mailing list
> dmd-internals at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-internals
>