- Pharo-dev - lists.pharo.org

Re: [Pharo-project] About RBLiteralArrayContainsCommaRule

by Peter Hugosson-Miller

Possibly it's useful as a warning to one who comes from a C-syntax language, and might accidentally define a literal array containing some. For example, #(1, 2, 3) - not an error, but not (as the perpetrator might believe) an array containing three integers ;) -- Cheers, Peter. On 30 dec 2012, at 20:48, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Hi > > I'm going over all the SmallLint rule and extending their rationale and fixing sometimes their default check. > Now I'm reading > > RBLiteralArrayContainsCommaRule > > rationale > ^ 'Checks for literal arrays that contain the #, symbol.' > > and I have no idea why this would be a problem. > > Anybody has an idea? > > Stef > >

Dec. 30, 2012

[Pharo-project] About RBMethodModifierFinalRule

by StÃ©phane Ducasse

Hi guys rationale ^ 'Checks that a methods marked with <modifier: #final> is never overridden.' my impression is that we can safely remove this rule. We never used this pragma for this convention. Isn't it :) Stef

Dec. 30, 2012

[Pharo-project] About RBLiteralArrayContainsCommaRule

by StÃ©phane Ducasse

Hi I'm going over all the SmallLint rule and extending their rationale and fixing sometimes their default check. Now I'm reading RBLiteralArrayContainsCommaRule rationale ^ 'Checks for literal arrays that contain the #, symbol.' and I have no idea why this would be a problem. Anybody has an idea? Stef

Dec. 30, 2012

Re: [Pharo-project] [squeak-dev] A blog article on Oak

by Mariano Martinez Peck

Thanks Goran. I read the whole article, and I really like it. Hope you continue pushing. I always wanted to build some kind of database on top of Fuel :) On Sun, Dec 30, 2012 at 9:24 AM, stephane ducasse < stephane.ducasse(a)gmail.com> wrote: > > On Dec 30, 2012, at 12:54 PM, GÃ¶ran Krampe wrote: > > > 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/ > Cool > this is the best way to create more documentation. > I would like to have a chapter on fuel, mongotalk,â¦.for the next book. > Deep into pharo 2 :) > Stef > > > > 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 > > ``` > > > > > -- Mariano http://marianopeck.wordpress.com

Dec. 30, 2012

[Pharo-project] corrupt images on gforge

by Camillo Bruni

see http://code.google.com/p/pharo/issues/detail?id=7196 I suggest someone other than me fixes it ;) to - add missing documentation - see how complicated everything is

Dec. 30, 2012

[Pharo-project] [update 2.0] #20462

by StÃ©phane Ducasse

20462 ----- - Issue 7192: JobEnd Bug. Now no more DNU :) http://code.google.com/p/pharo/issues/detail?id=7192 - Issue 7191: MC merge generate conflicts for categories http://code.google.com/p/pharo/issues/detail?id=7191 Diff information: http://ss3.gemstone.com/ss/Pharo20/Polymorph-Tools-Diff-StephaneDucasse.86.… http://ss3.gemstone.com/ss/Pharo20/Morphic-StephaneDucasse.1319.diff http://ss3.gemstone.com/ss/Pharo20/Monticello-StephaneDucasse.738.diff

Dec. 30, 2012

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

by StÃ©phane Ducasse

On Dec 30, 2012, at 3:02 PM, Max Leske wrote: > 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 :) oh yes!!!! Please > 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 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