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

[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

Re: [Pharo-project] Issue Fixing Process

by StÃ©phane Ducasse

oh yesssss! Stef On Jun 13, 2009, at 2:29 PM, dmason(a)mason-rose.ca wrote: >> As a start point I will run the test cases and see if I can fix the >> failing... (Issue 409). > > I would encourage anyone fixing an issue to first add a test case that > exhibits the issue to the appropriate test class, and *then* see if > you > can fix the issue itself. > > Even if you can't fix the issue, *publish the test case*(s). This > will > allow someone else to move forward faster on fixing it. > > ../Dave > > _______________________________________________ > 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 Michael Roberts

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 >

June 13, 2009

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

by Michael Roberts

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? 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 >

June 13, 2009

Re: [Pharo-project] about FLoatArrays isZero

by Nicolas Cellier

(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 >

June 13, 2009