December 2012 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] DateAndTime class>>midnight

by Max Leske

Ok, thanks for the explanation. I'll go back to the drawing board. And once I've figured it out I might even come up with a helpful class comment :) On 30.12.2012, at 14:00, Camillo Bruni <camillobruni(a)gmail.com> wrote: > > On 2012-12-30, at 05:42, Max Leske <maxleske(a)gmail.com> wrote: > >> Hm. Ok. It still looks really weird. The comment in #midnight states that it answers midnight in the local time zone. That comment is now wrong, isn't it? #midnight now answers midnight UTC (??). >> >> In any case, I see two problems: >> 1. as already said, comparison operations on Date are broken (and on DateAndTime) >> 2. "midnight" is no longer the same as "midnight". Consider the following example: >> >> now := DateAndTime now. >> midnight := now - now hours hours - now minutes minutes - now seconds seconds - now nanoSecond nanoSecond. >> midnight = DateAndTime midnight "---> true" >> >> Interestingly, this evaluates to true in both 1.4 and 2.0. BUT: in 2.0 the objects have different julian day numbers and different seconds. I would hardly call those objects equalâ¦ > > thats a fully correct observation but a wrong conclusion :) > > old: internal, external representation and 0-point were local time > new: internal representation and 0-point are in UTC, external representation are in local time > > for comparisons we now simply compare the internal representation in UTC, > which makes everything way simpler. > >> I'm also pretty unhappy with the API changes to DateAndTime. For instance, "DateAndTime now seconds" is not the same as "DateAndTime now instVarNamed: 'seconds'". That's really frustrating when debugging those objects. >> >> Sorry Cami, I know that's your work :) > > > haha well consider it as one of these nasty things in pharo you got used to. > DateAndTime was sincerely broken in pre 2.0 images. > Moving an image between a timezone yielded wrong DateAndTimes (which btw happens > twice per year when switching from/to daylight saving time). The only way > to solve the mess is to have a fixed reference point, in this case UTC. > > - internally everything is in UTC > - externally everything is in local time > > believe me that was harder than you think ;) we did a nasty hackathon of 8hours > to get "everything" straight. > > That said, it might be confusing compared to pre 2.0 images but it makes definitely > more sense. Hence I can only conclude that the code you use from pre 2.0 era is wrong :D

Dec. 30, 2012

Re: [Pharo-project] DateAndTime class>>midnight

by Camillo Bruni

On 2012-12-30, at 10:26, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > camillo > > is your explanation in the class comment? > Because if you say that this is nastyâ¦. > It is worth documenting it :) It says that DateAndTime uses UTC time so technically all the information is there. But the comment could indeed require some more love ;)

Dec. 30, 2012

Re: [Pharo-project] War plan for Pharo20 beta

by Camillo Bruni

On 2012-12-30, at 10:12, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > On Dec 30, 2012, at 2:02 PM, Camillo Bruni wrote: > >> >> On 2012-12-30, at 08:39, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> >>> Hi guys >>> >>> I really think that we should focus on fixing the tests first. >>> >>> - I will remove the spellchecking tests so that tests run faster >>> - Integrate a couple of more fixes to make us faster when merging. >>> - then I will try to spot the progress bar bugs. >> >> wait with the last thing until I am back in Lille next week. >> Cause you will most probably cause conflicts up my existing fixes ;) > > Yes now I "fixed" the bars last so that we do not have 50 DNU ;) good!

Dec. 30, 2012

Re: [Pharo-project] DateAndTime class>>midnight

by StÃ©phane Ducasse

camillo is your explanation in the class comment? Because if you say that this is nastyâ¦. It is worth documenting it :) Stef On Dec 30, 2012, at 2:00 PM, Camillo Bruni wrote: > > On 2012-12-30, at 05:42, Max Leske <maxleske(a)gmail.com> wrote: > >> Hm. Ok. It still looks really weird. The comment in #midnight states that it answers midnight in the local time zone. That comment is now wrong, isn't it? #midnight now answers midnight UTC (??). >> >> In any case, I see two problems: >> 1. as already said, comparison operations on Date are broken (and on DateAndTime) >> 2. "midnight" is no longer the same as "midnight". Consider the following example: >> >> now := DateAndTime now. >> midnight := now - now hours hours - now minutes minutes - now seconds seconds - now nanoSecond nanoSecond. >> midnight = DateAndTime midnight "---> true" >> >> Interestingly, this evaluates to true in both 1.4 and 2.0. BUT: in 2.0 the objects have different julian day numbers and different seconds. I would hardly call those objects equalâ¦ > > thats a fully correct observation but a wrong conclusion :) > > old: internal, external representation and 0-point were local time > new: internal representation and 0-point are in UTC, external representation are in local time > > for comparisons we now simply compare the internal representation in UTC, > which makes everything way simpler. > >> I'm also pretty unhappy with the API changes to DateAndTime. For instance, "DateAndTime now seconds" is not the same as "DateAndTime now instVarNamed: 'seconds'". That's really frustrating when debugging those objects. >> >> Sorry Cami, I know that's your work :) > > > haha well consider it as one of these nasty things in pharo you got used to. > DateAndTime was sincerely broken in pre 2.0 images. > Moving an image between a timezone yielded wrong DateAndTimes (which btw happens > twice per year when switching from/to daylight saving time). The only way > to solve the mess is to have a fixed reference point, in this case UTC. > > - internally everything is in UTC > - externally everything is in local time > > believe me that was harder than you think ;) we did a nasty hackathon of 8hours > to get "everything" straight. > > That said, it might be confusing compared to pre 2.0 images but it makes definitely > more sense. Hence I can only conclude that the code you use from pre 2.0 era is wrong :D

Dec. 30, 2012

Re: [Pharo-project] War plan for Pharo20 beta

by StÃ©phane Ducasse

On Dec 30, 2012, at 2:02 PM, Camillo Bruni wrote: > > On 2012-12-30, at 08:39, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > >> Hi guys >> >> I really think that we should focus on fixing the tests first. >> >> - I will remove the spellchecking tests so that tests run faster >> - Integrate a couple of more fixes to make us faster when merging. >> - then I will try to spot the progress bar bugs. > > wait with the last thing until I am back in Lille next week. > Cause you will most probably cause conflicts up my existing fixes ;) Yes now I "fixed" the bars last so that we do not have 50 DNU > >

Dec. 30, 2012

Re: [Pharo-project] War plan for Pharo20 beta

by Camillo Bruni

On 2012-12-30, at 08:39, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Hi guys > > I really think that we should focus on fixing the tests first. > > - I will remove the spellchecking tests so that tests run faster > - Integrate a couple of more fixes to make us faster when merging. > - then I will try to spot the progress bar bugs. wait with the last thing until I am back in Lille next week. Cause you will most probably cause conflicts up my existing fixes ;)

Dec. 30, 2012

Re: [Pharo-project] DateAndTime class>>midnight

by Camillo Bruni

On 2012-12-30, at 05:42, Max Leske <maxleske(a)gmail.com> wrote: > Hm. Ok. It still looks really weird. The comment in #midnight states that it answers midnight in the local time zone. That comment is now wrong, isn't it? #midnight now answers midnight UTC (??). > > In any case, I see two problems: > 1. as already said, comparison operations on Date are broken (and on DateAndTime) > 2. "midnight" is no longer the same as "midnight". Consider the following example: > > now := DateAndTime now. > midnight := now - now hours hours - now minutes minutes - now seconds seconds - now nanoSecond nanoSecond. > midnight = DateAndTime midnight "---> true" > > Interestingly, this evaluates to true in both 1.4 and 2.0. BUT: in 2.0 the objects have different julian day numbers and different seconds. I would hardly call those objects equalâ¦ thats a fully correct observation but a wrong conclusion :) old: internal, external representation and 0-point were local time new: internal representation and 0-point are in UTC, external representation are in local time for comparisons we now simply compare the internal representation in UTC, which makes everything way simpler. > I'm also pretty unhappy with the API changes to DateAndTime. For instance, "DateAndTime now seconds" is not the same as "DateAndTime now instVarNamed: 'seconds'". That's really frustrating when debugging those objects. > > Sorry Cami, I know that's your work :) haha well consider it as one of these nasty things in pharo you got used to. DateAndTime was sincerely broken in pre 2.0 images. Moving an image between a timezone yielded wrong DateAndTimes (which btw happens twice per year when switching from/to daylight saving time). The only way to solve the mess is to have a fixed reference point, in this case UTC. - internally everything is in UTC - externally everything is in local time believe me that was harder than you think ;) we did a nasty hackathon of 8hours to get "everything" straight. That said, it might be confusing compared to pre 2.0 images but it makes definitely more sense. Hence I can only conclude that the code you use from pre 2.0 era is wrong :D

Dec. 30, 2012

Re: [Pharo-project] [update 2.0] #20461

by StÃ©phane Ducasse

I took again the same image and did nothing but run the tests and it did not crash. Strange. On Dec 30, 2012, at 12:51 PM, StÃ©phane Ducasse wrote: > > On Dec 30, 2012, at 12:32 PM, StÃ©phane Ducasse wrote: > >> Looking at the log I do not see how this is related to the changes we did. >> I'm puzzled >> Now I'm rerunning the tests flushing the cache >> MCMethodDefinition flushMethodCache first >> But I expect exactly the same result. > The vm does not crash. I will redo the experiment but I wonder if this is not related to > > > - http://code.google.com/p/pharo/issues/detail?id=5276 > > Stef

Dec. 30, 2012

[Pharo-project] A blog article on Oak

by GÃ¶ran Krampe

Hi! I just moved my blog to Octopress (away from Wordpress) and must say this is much more up my alley. And doing so I also published a rather long article on Oak - Nicolas little OODB-thing that I am using: http://goran.krampe.se/2012/12/29/oak/ If you have questions about Oak, feel free to either reply here or comment on the article. If you have questions on Octopress and migrating from Wordpress - feel free to ask about that too! ...and a happy new year! regards, GÃ¶ran PS. Colorized Smalltalk code in Octopress markdown is trivial, I just do this: ``` smalltalk 3 + 4 ```

Dec. 30, 2012

Re: [Pharo-project] [update 2.0] #20461

by StÃ©phane Ducasse

On Dec 30, 2012, at 12:32 PM, StÃ©phane Ducasse wrote: > Looking at the log I do not see how this is related to the changes we did. > I'm puzzled > Now I'm rerunning the tests flushing the cache > MCMethodDefinition flushMethodCache first > But I expect exactly the same result. The vm does not crash. I will redo the experiment but I wonder if this is not related to - http://code.google.com/p/pharo/issues/detail?id=5276 Stef

Dec. 30, 2012