March 2013 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Running tests on 2.0 and first impression

by Camillo Bruni

On 2013-03-20, at 14:01, Henrik Johansen <henrik.s.johansen(a)veloxit.no> wrote: > On Mar 20, 2013, at 1:20 PM, Camillo Bruni wrote: >>> Totally agree, but for this specific bug I think that the process can >>> be improved by increased code reviews. >>> The fact that a negative seconds inst var and a julianDayNumber inst >>> var different from julianDayNumber message was chosen indicates that >>> current implementation is a quick hack, a workaround for solving some >>> problems, but clearly not a long term solution. IMO it creates as many >>> problems as it solves. >> >> That is a totally different discussion and most probably the tests are >> wrong, as with most of the date and time stuff from squeak. The dimensions >> of this mess are hard to grasp, but using a reference point expressed in >> local time is a very bad thing. So we changed that and all internal >> representations of DateAndTime are in UTC. All external representations >> of DateAndTime are in local time. >> >> That implies that whatever you inspect and see is in UTC, negative >> offsets make perfectly sense if your time-zone lags behind UTC. I wish >> I had time to fully clear up the mess, and add all basic accessors for >> utc. >> >> > Nicolas wasn't talking of offset. > > When I (in Norwegian timezone) do > DateAndTime midnight > > I get an instance with instvars: > seconds -3600 > offset: 1 hour duration. > > If it were indeed supposed to return local time instvar, I would expect an instance with > julianDayNumber one less, and seconds 23 *3600. right, so it looks like DateAndTime>>#year:month:day:hour:minute:second:nanoSecond:offset: does not take the seconds nor the offset into account when calculating the julian day number. I opened a bug entry with an intermediate fix for this: https://pharo.fogbugz.com/default.asp?10069

March 20, 2013

Re: [Pharo-project] Running tests on 2.0 and first impression

by Sven Van Caekenberghe

On 20 Mar 2013, at 14:01, Henrik Johansen <henrik.s.johansen(a)veloxit.no> wrote: > On Mar 20, 2013, at 1:20 PM, Camillo Bruni wrote: > >>> Totally agree, but for this specific bug I think that the process can >>> be improved by increased code reviews. >>> The fact that a negative seconds inst var and a julianDayNumber inst >>> var different from julianDayNumber message was chosen indicates that >>> current implementation is a quick hack, a workaround for solving some >>> problems, but clearly not a long term solution. IMO it creates as many >>> problems as it solves. >> >> That is a totally different discussion and most probably the tests are >> wrong, as with most of the date and time stuff from squeak. The dimensions >> of this mess are hard to grasp, but using a reference point expressed in >> local time is a very bad thing. So we changed that and all internal >> representations of DateAndTime are in UTC. All external representations >> of DateAndTime are in local time. >> >> That implies that whatever you inspect and see is in UTC, negative >> offsets make perfectly sense if your time-zone lags behind UTC. I wish >> I had time to fully clear up the mess, and add all basic accessors for >> utc. >> > Nicolas wasn't talking of offset. > > When I (in Norwegian timezone) do > DateAndTime midnight > > I get an instance with instvars: > seconds -3600 > offset: 1 hour duration. > > If it were indeed supposed to return local time instvar, I would expect an instance with > julianDayNumber one less, and seconds 23 *3600. > > Cheers, > Henry Maybe renaming the instance variables to reflect their UTC nature would help, but there is a difference between internal representation and external behaviour - if it is documented that seems OK to me. The #midnight example probably needs an extra normalisation of the internal representation, which would indeed shift it to what you would expect. Constructive criticism is always welcome, but these changes to DateAndTime were made many months ago - with great effort. Yes, there is still work to be done, and although it is maybe logical, it is a bit dissappointing to hear it right after a release. Pharo is a continuous improvement process. Sven -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill

March 20, 2013

Re: [Pharo-project] Running tests on 2.0 and first impression

by Henrik Johansen

On Mar 20, 2013, at 2:01 PM, Henrik Johansen wrote: > > > If it were indeed supposed to return local time instvar, I would expect an instance with Bah, forgot to proofread, meant "If it were indeed supposed to return midnight local time, I would expect a DateAndTime with UTC instance variables where" > julianDayNumber one less, and seconds 23 *3600. > > Cheers, > Henry

March 20, 2013

Re: [Pharo-project] Running tests on 2.0 and first impression

by Henrik Johansen

On Mar 20, 2013, at 1:20 PM, Camillo Bruni wrote: >>> >> Totally agree, but for this specific bug I think that the process can >> be improved by increased code reviews. >> The fact that a negative seconds inst var and a julianDayNumber inst >> var different from julianDayNumber message was chosen indicates that >> current implementation is a quick hack, a workaround for solving some >> problems, but clearly not a long term solution. IMO it creates as many >> problems as it solves. > > That is a totally different discussion and most probably the tests are > wrong, as with most of the date and time stuff from squeak. The dimensions > of this mess are hard to grasp, but using a reference point expressed in > local time is a very bad thing. So we changed that and all internal > representations of DateAndTime are in UTC. All external representations > of DateAndTime are in local time. > > That implies that whatever you inspect and see is in UTC, negative > offsets make perfectly sense if your time-zone lags behind UTC. I wish > I had time to fully clear up the mess, and add all basic accessors for > utc. > > Nicolas wasn't talking of offset. When I (in Norwegian timezone) do DateAndTime midnight I get an instance with instvars: seconds -3600 offset: 1 hour duration. If it were indeed supposed to return local time instvar, I would expect an instance with julianDayNumber one less, and seconds 23 *3600. Cheers, Henry

March 20, 2013

Re: [Pharo-project] Running tests on 2.0 and first impression

by Camillo Bruni

>> > Totally agree, but for this specific bug I think that the process can > be improved by increased code reviews. > The fact that a negative seconds inst var and a julianDayNumber inst > var different from julianDayNumber message was chosen indicates that > current implementation is a quick hack, a workaround for solving some > problems, but clearly not a long term solution. IMO it creates as many > problems as it solves. That is a totally different discussion and most probably the tests are wrong, as with most of the date and time stuff from squeak. The dimensions of this mess are hard to grasp, but using a reference point expressed in local time is a very bad thing. So we changed that and all internal representations of DateAndTime are in UTC. All external representations of DateAndTime are in local time. That implies that whatever you inspect and see is in UTC, negative offsets make perfectly sense if your time-zone lags behind UTC. I wish I had time to fully clear up the mess, and add all basic accessors for utc.

March 20, 2013

Re: [Pharo-project] Running tests on 2.0 and first impression

by Frank Shearar

On 20 March 2013 11:56, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > Marcus Denker-4 wrote >> How to not require a name when a tests does something that needs it? >> When running tests on the build server it sets a name before and removes >> it later, but I don't think that the test runner should do that by >> default. > > MCWorkingCopyTest already temporarily sets the author name, why not do the > same with the test Nicolas is pointing out? Or perhaps the test runner can do this: one risks forgetting that some action triggers the dialog, and not notice in one's dev image. (And of course the test runner can _unset_ the author if it had to fake an author.) frank > OT... this smells to me like another example of the value of a "skipped > test" concept in SUnit... if the information is supplied, no problem, if the > dialog is cancelled, or the image is headless, skip the test. > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/Running-tests-on-2-0-and-first-impression-tp4677439p4… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

March 20, 2013

Re: [Pharo-project] Running tests on 2.0 and first impression

by Sean P. DeNigris

Marcus Denker-4 wrote > How to not require a name when a tests does something that needs it? > When running tests on the build server it sets a name before and removes > it later, but I don't think that the test runner should do that by > default. MCWorkingCopyTest already temporarily sets the author name, why not do the same with the test Nicolas is pointing out? OT... this smells to me like another example of the value of a "skipped test" concept in SUnit... if the information is supplied, no problem, if the dialog is cancelled, or the image is headless, skip the test. ----- Cheers, Sean -- View this message in context: http://forum.world.st/Running-tests-on-2-0-and-first-impression-tp4677439p4… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

March 20, 2013

Re: [Pharo-project] one-click is dead, now we have platform specific builds

by Sean P. DeNigris

EstebanLM wrote > I just adapted the script for create one-click Have we captured the procedure for the one-click? Even though it didn't work out for newbies, I think it has value in other contexts e.g. a personal image that I can easily start up on any OS, perhaps to show off at conferences ;) ----- Cheers, Sean -- View this message in context: http://forum.world.st/one-click-is-dead-now-we-have-platform-specific-build… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

March 20, 2013

Re: [Pharo-project] Penelope is in town! (or how to have access to the new issue tracker)

by Sean P. DeNigris

Nicolas Cellier wrote > I don't know if it's worth duplicating many bug tracker features. > ... > I'd say first concentrate on providing a working registering page and > I'll be happy :) I agree that registration is most important. And, I also think it's important to have a flexible search feature on the mirror site; not for us, but for users. The harder it is to search, the more duplicate issues there will be, and the more work for us to straighten it out. ----- Cheers, Sean -- View this message in context: http://forum.world.st/Penelope-is-in-town-or-how-to-have-access-to-the-new-… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

March 20, 2013

Re: [Pharo-project] Running tests on 2.0 and first impression

by Nicolas Cellier

2013/3/20 Marcus Denker <marcus.denker(a)inria.fr>: > > On Mar 20, 2013, at 12:54 AM, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > >> First thing, congrats to Pharo community, I observe a good trend. >> It may seem dumb, but it's great to have pharo executable and pharo icons. >> Once the image launched, my general feel is good too, though I'm not >> fan of multiple keys shortcuts. >> It stressed me to the point that I didn't realize the single key >> shortcuts were still active in text editor (desperately seeking cmd b+ >> something... when cmd + shift + N would just browse ivar references). >> I guess I'll get used to it. >> Browsing the class Object seems a bit long, I guess there's time >> wasted scanning the class hierarchy... >> >> Of course, there's a few things to polish. >> First I ran the tests, and here is what I have to say about it >> - there were two interactions requests, IMO, there shouldn't be any (a >> pop up for my name, and a menu) > > How to not require a name when a tests does something that needs it? > When running tests on the build server it sets a name before and removes > it later, but I don't think that the test runner should do that by default. > >> - there are some failures (10) and errors (3), is this expected? (see >> attachment) > > -> There are some tests that fail when running like this that do not fail > on the build server. We should put issues for them on the tracker and fix them. > > -> There seems to be a strange Time related bug happening only around midnight. > Yes, someone should have a look a that, too. > (First step is to submit an issue). > >> - more annoyingly, during the test, the progressbar feedback >> disappeared (sporadically flashing) and the TestRunner feedback too >> (number of succeded test updates went scarce) >> > ProgressBar still needs to be improved. I think there is even an issue for that. > >> When I opened a FileBrowser to browse the filedOut TestRunner report, >> I typed *.txt as a filter and got a RegexSyntaxError nullable closure, >> that's surprising. >> > FileBrowser is not used a lot and there are of course no UI level tests. > So there will be bugs. > >> There I stopped exploring the features and inquired a bit about the failures. >> Most failures are related to DateAndTime. I guess they occured because >> I was playing with image around midnight with a +01:00 offset. > > Yes, two people already saw this bug happening, we should add an issue to the tracker. > > In general it just shows: Any issue that is not fixed by someone is not fixed. ;-) > > > Marcus > > Totally agree, but for this specific bug I think that the process can be improved by increased code reviews. The fact that a negative seconds inst var and a julianDayNumber inst var different from julianDayNumber message was chosen indicates that current implementation is a quick hack, a workaround for solving some problems, but clearly not a long term solution. IMO it creates as many problems as it solves. Diff has been added lately, and it is a real progress for reviewing code, but the effort to participate is still a bit high. More eyes, more reviews... The fact that bug only show up around midnight is true only for Europeans which have small offsets from UTC, I guess the probability of bug shall increase in California or Japan. Nicolas > > >

March 20, 2013