- Pharo-dev - lists.pharo.org

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

[Pharo-project] CompiledMethod and MethodReference

by StÃ©phane Ducasse

I was playing with compiledMethod and MethodReference and it would be great if they could be more polymorphic: MethodReference>>methodClass ^ self actualClass I was also thinking that it would be nice to have the package associated with the MethodReference eg: (Character>>#escapeEntities) package -> PackageInfo-Base What do you think about that? Stef

June 13, 2009

Re: [Pharo-project] Issue 67 and CrLfFileStream

by StÃ©phane Ducasse

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 :) 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 >

June 13, 2009

Re: [Pharo-project] Issue 67 and CrLfFileStream

by Norbert Hartl

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 :) 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

June 13, 2009

Re: [Pharo-project] about FLoatArrays isZero

by StÃ©phane Ducasse

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 >

June 13, 2009

Re: [Pharo-project] [update] #10334

by StÃ©phane Ducasse

On Jun 13, 2009, at 4:52 PM, Michael Roberts wrote: > hi folks, just wanted to ask what the correct way we should expect > deprecations to be used. Updates are great of course! I am running > all the tests to generate baseline results and then try and chip away > at a few of the new/old errors. > > However, now when I run the whole test suite it pauses because there > is a deprecation. If we are going to deprecate a method would it be > good to also fix up the senders? yes this should be like that, now for example of the isZero it was not clear apparently they were senders in the system. I imgaine that the integrator did not rnu the tests. > or have a mechanism that suppresses > the deprecation in the context of the test run? > > thanks, > Mike > > On Thu, Jun 11, 2009 at 4:50 PM, Marcus Denker<denker(a)acm.org> wrote: >> #10334 >> ====== >> Issue 877: Collection>>isZero use deprecatedDescrition: >> instead of >> deprecated >> Issue 686: Remove dice methods in Random >> Issue 631: API Consistency on MIMEDocument >> >> -- >> Marcus Denker - http://marcusdenker.de >> PLEIAD Lab - Computer Science Department (DCC) - University of Chile >> >> >> _______________________________________________ >> 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] [ANN] 10337

by StÃ©phane Ducasse

issue 884: Bookmorph removal. Thanks alain! Stef

June 13, 2009