June 2009 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] [ANN] 10337

by StÃ©phane Ducasse

ok I prefer that than a merging bug. Stef On Jun 13, 2009, at 11:04 PM, Alain Plantec wrote: > StÃ©phane Ducasse a Ã©crit : >> can you check ? >> because book~LikeMorph and bookMorph in 320 were not in the same >> hierarchy anymore. > checked, my slice didn't completely remove BookMorph. =-O > my next will. > alain >> Stef >> >> On Jun 13, 2009, at 10:39 PM, Alain Plantec wrote: >> >>> StÃ©phane Ducasse a Ã©crit : >>>> issue 884: Bookmorph removal. Thanks alain! >>>> >>> I think that something was wrong because BookMorph is still present >>> after #10337. >>> >> >> > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

June 14, 2009

Re: [Pharo-project] Fixes for Numbers are ready (toward ANSI)

by Mariano Martinez Peck

On Thu, Jun 11, 2009 at 5:26 PM, Alain Plantec <alain.plantec(a)free.fr>wrote: > Nicolas Cellier a Ã©crit : > > 2009/6/11 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > > > >> thanks nicolas > >> BTW did you got feedback about this one? > >> > http://code.google.com/p/pharo/issues/detail?id=860&colspec=ID%20Type%20Sta… > >> > > > > None yet. I only see 3 explanations: > > - everyone is busy, dead, in hollidays, in the garden, etc... > > - everyone disabled the preference for generating the error log > > - I'm the only one doing bugs, no one else ever seen a slow Notifier > > > :) > Hi Nicolas, > sorry for the stupid question but what are you asking testers to do ? > I've loaded the 4 .cs, verified that the preference is on and evaluated > 0/0. > seen a notifier, click on proceed and get a SqueakDebug.log. > and then what ? Should he do something like what Nicolas do: Debugger class>>#openOn:context:label:contents:fullView: Preferences logDebuggerStackToFile ifTrue: [MessageTally spyOn: [Smalltalk logError: title inContext: context to: 'SqueakDebug.log']] and compare the times before and after the changesets ??? Cheers, Mariano > > thanks > Alain > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

June 13, 2009

Re: [Pharo-project] about FLoatArrays isZero

by Nicolas Cellier

Ah OK, I just ran the test, I know understand. You could eventually replace isZero with = 0 in that case... 2009/6/13 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: > The failing test you exposed sounds like the difference is used to > test equality between two FloatArray. > If that is the case, you could replace isZero by isAllZero. > I did not run an image nor look at the code, alors je suis peut Ãªtre Ã > cÃ´tÃ© de la plaque... > > > 2009/6/13 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >> I hate this coercion. >> >> Nicolas I do not understand your answer. >> For me a collection isZero means nothing. >> >> Stef >> >> On Jun 13, 2009, at 5:04 PM, Michael Roberts wrote: >> >>> I haven't yet looked at the cs on the mantis report, but why do we >>> expect to be able to coerce a collection into a number? (non an >>> obvious behaviour for collections) >>> >>> thanks, >>> Mike >>> >>> On Sat, Jun 13, 2009 at 3:48 PM, Nicolas >>> Cellier<nicolas.cellier.aka.nice(a)gmail.com> wrote: >>>> (a - b) allSatisfy: [:each | each isZero] ? >>>> >>>> 2009/6/13 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >>>>> isZero on collection does not make sense so it was deprecated now >>>>> >>>>> some tests like are breaking >>>>> >>>>> 3.0 / (FloatArray with: 2.0) = (FloatArray with: 1.5) >>>>> >>>>> so ? >>>>> Stef >>>>> >>>>> _______________________________________________ >>>>> Pharo-project mailing list >>>>> Pharo-project(a)lists.gforge.inria.fr >>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>> >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >

June 13, 2009

Re: [Pharo-project] Issue 67 and CrLfFileStream

by Norbert Hartl

On Sat, 2009-06-13 at 21:06 +0200, StÃ©phane Ducasse wrote: > On Jun 13, 2009, at 8:16 PM, Norbert Hartl wrote: > > > Maybe the email was not clear enough. The fix is ok. My > > question are targeted towards additional refactorings. > > > > Just in case that is the reason that wasn't been > > harvested :) > > ;) > I have the impression that we give a quite strong reactivity :) > Probably too much :) > There is no tooo much. It is very good indeed :) I was just wondering because I fixed this one before the one Marcus harvested. Norbert > Stef > > > > > Norbert > > > > On Sat, 2009-06-13 at 11:17 +0200, Norbert Hartl wrote: > >> I've fixed issue 67. SLICE is in PharoInbox. > >> > >> While looking at the classes I found some things. > >> CrLfFileStream is somehow obsolete. Its new class method > >> creates a MultiByteFileStream. The code in both classes > >> is doubled. I didn't check but I would expect it is close > >> to all of the code. > >> This is again a question if we are willing to break back- > >> ward compatibility. I would opt for removing the class > >> completely. If not I would change MultiByteFileStream in > >> a way that it inherits from CrLfFileStream. This way we could > >> at least remove the doubled code/methods. > >> > >> Or does anybody know reasons why the one or other isn't > >> feasible to do? > >> > >> Furthermore I would remove the handling of line endings > >> with symbols. These could just be the strings they contain. > >> String cr, String lf and String crlf all exist. Using this > >> instead of the symbols we could remove half of the class > >> variables and get rid of the LineEndStrings dictionary. > >> > >> What do you think? And could someone please review my > >> changes. I don't have a Mac. Well, the difference is only > >> noticable if you have a system < 10. > >> > >> Norbert > >> > >> > >> _______________________________________________ > >> Pharo-project mailing list > >> Pharo-project(a)lists.gforge.inria.fr > >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

June 13, 2009

Re: [Pharo-project] about FLoatArrays isZero

by Nicolas Cellier

The failing test you exposed sounds like the difference is used to test equality between two FloatArray. If that is the case, you could replace isZero by isAllZero. I did not run an image nor look at the code, alors je suis peut Ãªtre Ã cÃ´tÃ© de la plaque... 2009/6/13 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > I hate this coercion. > > Nicolas I do not understand your answer. > For me a collection isZero means nothing. > > Stef > > On Jun 13, 2009, at 5:04 PM, Michael Roberts wrote: > >> I haven't yet looked at the cs on the mantis report, but why do we >> expect to be able to coerce a collection into a number? (non an >> obvious behaviour for collections) >> >> thanks, >> Mike >> >> On Sat, Jun 13, 2009 at 3:48 PM, Nicolas >> Cellier<nicolas.cellier.aka.nice(a)gmail.com> wrote: >>> (a - b) allSatisfy: [:each | each isZero] ? >>> >>> 2009/6/13 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >>>> isZero on collection does not make sense so it was deprecated now >>>> >>>> some tests like are breaking >>>> >>>> 3.0 / (FloatArray with: 2.0) = (FloatArray with: 1.5) >>>> >>>> so ? >>>> Stef >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

June 13, 2009

Re: [Pharo-project] [ANN] 10337

by Alain Plantec

StÃ©phane Ducasse a Ã©crit : > can you check ? > because book~LikeMorph and bookMorph in 320 were not in the same > hierarchy anymore. checked, my slice didn't completely remove BookMorph. =-O my next will. alain > Stef > > On Jun 13, 2009, at 10:39 PM, Alain Plantec wrote: > >> StÃ©phane Ducasse a Ã©crit : >>> issue 884: Bookmorph removal. Thanks alain! >>> >> I think that something was wrong because BookMorph is still present >> after #10337. >> > >

June 13, 2009

Re: [Pharo-project] [ANN] 10337

by StÃ©phane Ducasse

can you check ? because book~LikeMorph and bookMorph in 320 were not in the same hierarchy anymore. Stef On Jun 13, 2009, at 10:39 PM, Alain Plantec wrote: > StÃ©phane Ducasse a Ã©crit : >> issue 884: Bookmorph removal. Thanks alain! >> > I think that something was wrong because BookMorph is still present > after #10337. > > regarding SqueakPage removal. It seems to me that ObjectOut and > MorphObjectOut would not be fonctional at all after > SqueakPage and SqueakPageCache removal. > I would remove all of this. > (and in the case someone want to make it revive, it isn't lost) > > alain >> Stef >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

June 13, 2009

Re: [Pharo-project] [ANN] 10337

by StÃ©phane Ducasse

I applied your slice and when I checked it removed BookLikeMorph Stef On Jun 13, 2009, at 10:39 PM, Alain Plantec wrote: > StÃ©phane Ducasse a Ã©crit : >> issue 884: Bookmorph removal. Thanks alain! >> > I think that something was wrong because BookMorph is still present > after #10337. > > regarding SqueakPage removal. It seems to me that ObjectOut and > MorphObjectOut would not be fonctional at all after > SqueakPage and SqueakPageCache removal. > I would remove all of this. > (and in the case someone want to make it revive, it isn't lost) yes I know. sniff all fun stuff broken. > > alain >> Stef >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

June 13, 2009

[Pharo-project] package extension question

by StÃ©phane Ducasse

Hi Apparently some class extensions category are stored in lowercase, and this makes difficult to find a package given a method category. methodCategoryPrefix ^ methodCategoryPrefix ifNil: [methodCategoryPrefix := '*', self packageName asLowercase] I would be nice to make sure that we can go from a package to its class extensions and from the class extensions to its package. Now using asLowercase breaks this dual relationship. What do you think? Ideally I would like to fix all the package extensions to reflect exactly their package name and also change the code above to ensure that we get a real bijection. Stef

June 13, 2009

Re: [Pharo-project] [ANN] 10337

by Alain Plantec

StÃ©phane Ducasse a Ã©crit : > issue 884: Bookmorph removal. Thanks alain! > I think that something was wrong because BookMorph is still present after #10337. regarding SqueakPage removal. It seems to me that ObjectOut and MorphObjectOut would not be fonctional at all after SqueakPage and SqueakPageCache removal. I would remove all of this. (and in the case someone want to make it revive, it isn't lost) alain > Stef > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > >

June 13, 2009