On 14 July 2014 23:49, David T. Lewis <lewis at mail.msen.com> wrote:
> On Mon, Jul 14, 2014 at 10:11:50PM +0100, Frank Shearar wrote:
>> http://build.squeak.org/job/SqueakTrunkOnSpur/31/testReport/junit/KernelTests.Chronology/DateAndTimeTest/testReadFrom/
>> shows a not-very-helpful test failure report: Expected
>> '2002-05-1...etc... but was '2002-05-1...etc....
>>
>> If build.squeak.org is anything like my machine, that failure might
>> more profitably be reported as:
>>
>> Expected '2002-05-16T17:20:00+00:00' but was '2002-05-16T17:20:00+01:00'
>>
>> from this assertion:
>>
>> self assert: '2002-05-16T17:20:00+00:00' equals: ' 2002-05-16T17:20'
>> asDateAndTime printString.
>
> If you are suggesting that a more informative error message would be
> helpful in this case, then yes for sure. My only caution would be to make
> sure that the improved message looks reasonable when viewed in a test
> runner in the image, since that is the most important usage. If you can
> make it display something meaningful in both the CI output and the
> test runner, that's great.

The issue with the reported string is just the "...." parts: while
they're there so you can't accidentally get a multi-gigabyte error
description, a DateAndTime is just long enough to get truncat.

>> Is this expected (because of changes in datetime primitives)?
>>
>
> No. The Spur image format and associated changes to the VM should be
> completely independent of primitives like this. You should expect the
> same results when running Spur, Cog, Stackinterpreter, or the traditional
> interpreter VM.
>
> The more important factor would be the platform support code that actually
> implements the low level "get the system time" functions. This will vary
> across Windows, Unix, Mac, Risc OS, etc, and it may also have variations
> between the oscog platforms branch and the trunk platforms branch.
>
> For example, I think that the newer microsecond clock prims are unimplemented
> in the Windows interpreter VM, and I'm not sure if they have been implemented
> in the oscog branch. So if you were seeing differences in test results on
> Windows versus other platforms, that would be the likely cause.

The test fails in my (updated trunk) Spur image on my Windows machine,
so things are at least consistent.

But as always, there's the state in the test and the state of the
entire image. I think Eliot's on the right track, and the Spur trunk
image just has a different Locale preference set or something to the
"normal" trunk image. The state of the image affects the running of
the test. Ideally DateAndTimeTest would set the necessary state just
for the test run, so we could have a deterministic test.

frank

> Dave