Phew! I already thought I was crazy :)

In that case here are two more tidbits:
- I tried to log ‘DateAndTime now’ in a different test simultaneously. The 
timestamp produced there was different, suggesting that the clock does move 
from time to time.
- FileSystemTests>>testEntryAt exhibits that problem. But the tests run on the 
main Pharo machines are fine (that’s why I thought it might be the system 
clock).
- the same test only fails in the Pharo3 image, not in Pharo2, but both use the 
stable PharoVM for building.

Hope that helps.

On 04.03.2014, at 22:10, Sven Van Caekenberghe <[email protected]> wrote:

> Hey Max,
> 
> Great catch, I saw some weird stuff too, and we had this conversation :
> 
>> may be just = 
>> and time does not pass fast enough/
>> 
>>> On 03 Mar 2014, at 22:22, [email protected] wrote:
>>> 
>>>> https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2.1-Validation-A-L/label=linux-stable-worker/962/
>>>> 
>>>> 1 regressions found.
>>>> KernelTests.Chronology.DateAndTimeTest.testMonotonicity
>>> 
>>> How the hell can this fail ?
>>> The clock moving backwards ??
>>> 
>>> testMonotonicity
>>> 
>>>     | t1 t2 t3 t4 |
>>>     t1 := DateAndTime now.
>>>     t2 := DateAndTime now.
>>>     (Delay forMilliseconds: 1000) wait.
>>>     t3 := DateAndTime now.
>>>     t4 := DateAndTime now.
>>> 
>>>     self
>>>             assert: (t1 <= t2);
>>>             assert: (t2 < t3);
>>>             assert: (t3 <= t4).
> 
> 
> So you proofed Stef's assumption of time standing still ;-)
> 
> But there were earlier problems as well.
> 
> Thx !
> 
> On 04 Mar 2014, at 21:43, Max Leske <[email protected]> wrote:
> 
>> There seems to be a problem on pharo-contribution-linux64-4.ci.inria.fr 
>> AFAICT. I can reproduce the following to phenomena:
>> 
>> 1. '(Delay forSeconds: 10) wait’ does not wait.
>> 2. ‘DateAndTime now’ does not change for long intervals.
>> 
>> For instance, the following code:
>> 
>> (FileSystem disk workingDirectory / 'foo.log') writeStreamDo: [ :stream |
>>      stream nextPutAll: DateAndTime now asString;crlf.
>>      stream nextPutAll: ([(Delay forSeconds: 10) wait] timeToRun / 1000) 
>> asString; crlf.
>>      stream nextPutAll: DateAndTime now asString ].
>> 
>> produces this output:
>> 
>> 2014-03-04T21:32:21.396669+01:00
>> 0:00:00:00
>> 2014-03-04T21:32:21.396669+01:00
>> 
>> Too me (and my untrained eye) this looks like a system clock problem. Could 
>> somebode take a look at the server in question?
>> 
>> Cheers,
>> Max
> 
> 


Reply via email to