Spur + DateAndTime: bug?
Locked
 
|
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. Is this expected (because of changes in datetime primitives)? frank |
|
|
Why not just cleanly list the name of the failing test and nothing else? Tests are only understood and debugged in the running image, not from a cryptic message reported on the build website. It certainly can't be fixed and committed without running the test in the image anyway.
So why do we want to see that debugging noise in the build-server reports? On Mon, Jul 14, 2014 at 4:11 PM, Frank Shearar <[hidden email]> wrote: http://build.squeak.org/job/SqueakTrunkOnSpur/31/testReport/junit/KernelTests.Chronology/DateAndTimeTest/testReadFrom/ |
|
|
On 14 July 2014 22:36, Chris Muller <[hidden email]> wrote:
> Why not just cleanly list the name of the failing test and nothing else? > Tests are only understood and debugged in the running image, not from a > cryptic message reported on the build website. I realise that _you_ don't use CI to debug tests. I do. I find value in these error messages, especially since I don't have a Linux machine, and as it happens, a test (see Tests-fbs.301) fails in Spur+Linux but passes in Spur+Windows. > It certainly can't be fixed > and committed without running the test in the image anyway. Yes, and so what? > So why do we want to see that debugging noise in the build-server reports? How is a decent error message noise? I find ENORMOUS value in these error messages. How could I possibly report a problem on a Linux box to Eliot otherwise? frank > On Mon, Jul 14, 2014 at 4:11 PM, Frank Shearar <[hidden email]> > 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. >> >> Is this expected (because of changes in datetime primitives)? >> >> frank |
|
|
On Mon, Jul 14, 2014 at 4:52 PM, Frank Shearar <[hidden email]> wrote:
Don't worry, if you find them enormously valuable then I want you to have them. I'm just trying to understand the CI use cases with and without the debugging messages. Seems like, either way, the process is the same.. (go into image, run, fix, run, commit -- where did the messages help?).
The problem was still reported by CI from a Linux run. When do you consume these messages and how putting them to use before getting into an image with full debugger? It's not for trying to debug an OS-specific failure from a different OS, even I know better.. :)
|
|
|
In reply to this post by Frank Shearar-3
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. > > 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. Dave |
|
|
In reply to this post by Frank Shearar-3
Hi Frank,
On Mon, Jul 14, 2014 at 2:11 PM, Frank Shearar <[hidden email]> wrote:
http://build.squeak.org/job/SqueakTrunkOnSpur/31/testReport/junit/KernelTests.Chronology/DateAndTimeTest/testReadFrom/ Could be because the Preferences valueOfFlag: #useLocale is false, which it shouldn't be. Could be because Locale startUp: isn't evaluated. -- best, Eliot
|
|
|
In reply to this post by Frank Shearar-3
On Mon, Jul 14, 2014 at 2:52 PM, Frank Shearar <[hidden email]> wrote:
+1
best, Eliot
|
Re: Spur + DateAndTime: bug?
|
|
In reply to this post by Frank Shearar-3
On Mon, 14 Jul 2014, 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. > > Is this expected (because of changes in datetime primitives)? It's unrelated to the VM. DateAndTime >> #readFrom: (since 7/5/2012) will create an object in the local timezone if no timezone is specified. The test and some related methods' comments expect it to be in UTC. The test is rather new, and I think it has always been failing. Levente > > frank > > |
|
|
In reply to this post by Frank Shearar-3
[inline]
-- Tobias Pape sent from a mobile device > Am 14.07.2014 um 23:52 schrieb Frank Shearar <[hidden email]>: > >> On 14 July 2014 22:36, Chris Muller <[hidden email]> wrote: >> Why not just cleanly list the name of the failing test and nothing else? >> Tests are only understood and debugged in the running image, not from a >> cryptic message reported on the build website. > > I realise that _you_ don't use CI to debug tests. I do. I find value > in these error messages, especially since I don't have a Linux > machine, and as it happens, a test (see Tests-fbs.301) fails in > Spur+Linux but passes in Spur+Windows. +1 > >> It certainly can't be fixed >> and committed without running the test in the image anyway. > > Yes, and so what? > >> So why do we want to see that debugging noise in the build-server reports? > > How is a decent error message noise? I find ENORMOUS value in these > error messages. How could I possibly report a problem on a Linux box > to Eliot otherwise? > > frank > >> On Mon, Jul 14, 2014 at 4:11 PM, Frank Shearar <[hidden email]> >> 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. >>> >>> Is this expected (because of changes in datetime primitives)? >>> >>> frank > |
|
|
In reply to this post by David T. Lewis
On 14 July 2014 23:49, David T. Lewis <[hidden email]> 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 |
|
|
In reply to this post by Levente Uzonyi-2
On Tue, Jul 15, 2014 at 03:27:59AM +0200, Levente Uzonyi wrote:
> On Mon, 14 Jul 2014, 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. > > > >Is this expected (because of changes in datetime primitives)? > > It's unrelated to the VM. DateAndTime >> #readFrom: (since 7/5/2012) will > create an object in the local timezone if no timezone is specified. The > test and some related methods' comments expect it to be in UTC. > The test is rather new, and I think it has always been failing. Levente, You are right. It was a bad test, and I caused the problem. Fixed in KernelTests-dtl.273: Remove invalid assertions in DateAndTimeTest>>testReadFrom. These had been added to the test in KernelTests-dtl.265 in attempt to restore some missing test assertions from an earlier version of the method. The test assertions pass if and only if time zone has zero offset, so they appear to pass in an image with default UTC time zone. However, they contradict the documented behavior for parsing DateAndTime from a string with time zone offset unspecified. See DateAndTimeTest>>testFromString for coverage of the expected behavior. Dave |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |