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

Re: [Pharo-project] About RBMethodModifierFinalRule

by Max Leske

We use it in Pharo 1.1.1 and 1.4. But we can put it back in as a custom rule if we need to. Max On 30.12.2012, at 21:03, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > 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. 31, 2012

Re: [Pharo-project] About RBLiteralArrayContainsCommaRule

by StÃ©phane Ducasse

Ok :) for now I kept it. And I'm creating an unused category to group the rules that we do not follow. I hope soon that we will develop some good rules to drive our development. Stef On Dec 30, 2012, at 9:05 PM, Peter Hugosson-Miller wrote: > 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] [update 2.0] #20463

by StÃ©phane Ducasse

20463 ----- - Issue 7190: MC core model depends on UI !! http://code.google.com/p/pharo/issues/detail?id=7190 - Issue 7195: SmallLint Rules better description and cleaning http://code.google.com/p/pharo/issues/detail?id=7195 - Issue 7198: MCVersionLoader http://code.google.com/p/pharo/issues/detail?id=7198 Diff information: http://ss3.gemstone.com/ss/Pharo20/System-Tools-StephaneDucasse.93.diff http://ss3.gemstone.com/ss/Pharo20/Refactoring-Critics-StephaneDucasse.28.d… http://ss3.gemstone.com/ss/Pharo20/Monticello-StephaneDucasse.740.diff http://ss3.gemstone.com/ss/Pharo20/Metacello-MC-StephaneDucasse.666.diff http://ss3.gemstone.com/ss/Pharo20/Manifest-Core-StephaneDucasse.99.diff http://ss3.gemstone.com/ss/Pharo20/Gofer-Core-StephaneDucasse.190.diff

Dec. 30, 2012

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