October 2010 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Smells looking at collections

by StÃ©phane Ducasse

>> >>> >>>> 2) well, this is difficult to get the money for the butter and the butter - we are trying. >>> >>> If you can compose classes the way you can add a trait to a class now with class and optional method level instance+class variable mapping, then you're done. It would be a lot simpler to use it _and_ it would also be a lot easier to implement it. Especially the tools part. >> >> I'm interested to hear more about that. so can you explain what you meant because I did not understand it. >> Tell us more. The problem we faced was >> - offset access = you cannot reuse bytecode of a trait because the order of the offset can be different in each trait users > > If you mean that a CompiledMethod of a trait cannot be added to the class' method dictionary, than that's not an issue. The current Trait implementation was changed, because shared CompiledMethods caused other problems. no this is not what I meant > If you mean that the same bytecodes can't be used, than that's neither a problem, because you can and should be compile the method again. Sharing trailer bytes may cause problems. > So adding a method from a trait to a class is simply recompiling it in the class' context. this is what we wanted to avoid. Also because you may have to recompile all the other methods of the class hierarchy because if a trait add an instance variable then you should recompile the subclasses when a trait get added with a state in the superclass. > Instance variables should be used by name during compilation. If there's a name collision then use the instance variable map I mentioned above. what is that the instance variable map? take the time to write an example >> - initialization of instances variables at the trait level and the composition at the class levele > > You can always rename a trait's method in your class. So if the trait has an #initialize method, then simply rename it to #initializeFooBar and send it from the class' #initialize method. Yes this is what the javascript implementation does but this is not that nice but may be there is no better solution. So indeed we could think about adding state. > > > Levente > >> >>> >>>> 3) again if nobody does anything and we just all cry on ourselves then nothing will happen. >>> >>> Tools are a must. No tools - no users. >> >> Exact. >> >>>> So for now identifying traits and learning is the way. Then we can refactor, redesign >>> >>> Well, Traits are in Squeak since 2006, IIRC they were available a few years earlier. So in the last X (at least 4) years the only good candidate to become a Trait was Magnitude. >> >> Come on. >> I will not answer to such statement because I'm positive thinking. >> >> 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

Oct. 24, 2010

Re: [Pharo-project] Smells looking at collections

by StÃ©phane Ducasse

your 2 cts are really welcome. On Oct 24, 2010, at 7:49 PM, Johan Brichau wrote: > > On 24 Oct 2010, at 08:42, StÃ©phane Ducasse wrote: > >>> Well, Traits are in Squeak since 2006, IIRC they were available a few years earlier. So in the last X (at least 4) years the only good candidate to become a Trait was Magnitude. > > > PolyMorphic also uses traits. > There are non-core projects that also use them, for example WebTester. > > I can also name several occassions in the development of our application, where we considered using traits to avoid code duplication. The only reason we didn't was because of a need for portability to GS. But if I understood correctly, it's quite possible that GS will support them in the future. > > Traits are being added to many other languages as well (e.g. traitsjs.org) It would be a shame to remove them from Squeak/Pharo Smalltalk now. > > just my 2 cents, > Johan > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 24, 2010

Re: [Pharo-project] akuhn/SUnit: run faster tests first & step through tests

by Adrian Kuhn

Understandable. +1 for breaking backward compatibility. --AA On Oct 24, 2010, at 00:37 , StÃ©phane Ducasse wrote: > Lack of maintainers, too many unwanted features, lack of explanation, > large changes... > > And this is not that several persons did not look at the code. It > got more than the average. > > Now I'm thinking that with discussion and care we should really get > another testing framework with the same API that SUnit > because if we want that PharoSunit is the same as Sunit then we are > doomed to be backward compatible and no > real improvements. > > Stef > > On Oct 23, 2010, at 10:58 PM, Adrian Kuhn wrote: > >> Sad to hear that. >> >> Technical difficulties, or just lack of customers? ^^ >> >> --AA >> >> On Oct 23, 2010, at 08:05 , StÃ©phane Ducasse wrote: >> >>> It was too difficult to integrate. >>> >>> Stef >>> >>> On Oct 23, 2010, at 2:01 PM, Niko Schwarz wrote: >>> >>>> What's the status of akuhn/SUnit? I couldn't find his code in 1.2 >>>> core. >>>> >>>> Niko >>>> >>>> On Wed, Feb 3, 2010 at 1:13 PM, StÃ©phane Ducasse >>>> <stephane.ducasse(a)inria.fr> wrote: >>>>> this loads well in the latest 1,1 core :) >>>>> so now we should really have a look and these cool changes >>>>> >>>>> Stef >>>>> >>>>> On Jan 6, 2010, at 2:38 PM, Adrian Kuhn wrote: >>>>> >>>>>> SystemChangeNotifier uniqueInstance >>>>>> noMoreNotificationsFor: TestCase. >>>>>> Gofer it >>>>>> disablePackageCache; >>>>>> squeaksource: 'akuhn'; >>>>>> package: 'SUnit'; >>>>>> package: 'SUnitGUI'; >>>>>> load. >>>>> >>>>> >>>>> _______________________________________________ >>>>> Pharo-project mailing list >>>>> Pharo-project(a)lists.gforge.inria.fr >>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo- >>>>> project >>>>> >>>> >>>> >>>> >>>> -- >>>> http://scg.unibe.ch/staff/Schwarz >>>> twitter.com/nes1983 >>>> Tel: +41 076 235 8683 >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >

Oct. 24, 2010

[Pharo-project] [update 1.2] #12213

by Marcus Denker

12213 ----- Issue 3153: MCVersionReader uses FileList registration Issue 3152: wrong Monticello package dependencies Issue 1954: Browser less hardcoded UI class Issue 3038: ToolBuilderTests>>testGetButtonSideEffects seems to be wrong Issue 3033: PharoCorePackageDependenciesTests make tests with packages not presents in pharo 1.2 Issue 2298: RunArray which would cause Texts with empty runs to lose their emphasis. -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

Oct. 24, 2010

Re: [Pharo-project] Smells looking at collections

by Johan Brichau

On 24 Oct 2010, at 20:06, Levente Uzonyi wrote: >> PolyMorphic also uses traits. > > Where can I find it? Sorry, I meant Polymorph. The PolyMorph-Widgets category in any Pharo image has them: TEasilyThemed, TEnableInHalo (or something like that). >> There are non-core projects that also use them, for example WebTester. > > I don't see any trait in the latest version, though I used SqueakSource's web interface. There's just one (WtTClickable) right now.

Oct. 24, 2010

Re: [Pharo-project] Smells looking at collections

by Levente Uzonyi

On Sun, 24 Oct 2010, Johan Brichau wrote: > > On 24 Oct 2010, at 08:42, StÃ©phane Ducasse wrote: > >>> Well, Traits are in Squeak since 2006, IIRC they were available a few years earlier. So in the last X (at least 4) years the only good candidate to become a Trait was Magnitude. > > > PolyMorphic also uses traits. Where can I find it? > There are non-core projects that also use them, for example WebTester. I don't see any trait in the latest version, though I used SqueakSource's web interface. > > I can also name several occassions in the development of our application, where we considered using traits to avoid code duplication. The only reason we didn't was because of a need for portability to GS. But if I understood correctly, it's quite possible that GS will support them in the future. > > Traits are being added to many other languages as well (e.g. traitsjs.org) It would be a shame to remove them from Squeak/Pharo Smalltalk now. I'm not saying that trait-like composition is bad, I only say that there's a better approach. Levente > > just my 2 cents, > Johan > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 24, 2010

Re: [Pharo-project] Smells looking at collections

by Johan Fabry

On 24 Oct 2010, at 14:48, Johan Brichau wrote: > > On 24 Oct 2010, at 08:42, StÃ©phane Ducasse wrote: > >>> Well, Traits are in Squeak since 2006, IIRC they were available a few years earlier. So in the last X (at least 4) years the only good candidate to become a Trait was Magnitude. > > > PolyMorphic also uses traits. > There are non-core projects that also use them, for example WebTester. AspectMaps us them as well. They made it possible to really clean up my implementation, so I am happy with them (even though there are packaging issues). > Traits are being added to many other languages as well (e.g. traitsjs.org) It would be a shame to remove them from Squeak/Pharo Smalltalk now. +1 -- Johan Fabry jfabry(a)dcc.uchile.cl - http://dcc.uchile.cl/~jfabry PLEIAD Lab - Computer Science Department (DCC) - University of Chile

Oct. 24, 2010

[Pharo-project] Issue 3153: MCVersionReader uses FileList registration

by Pavel Krivanek

http://code.google.com/p/pharo/issues/detail?id=3153 This is the next important patch that enables to load Monticello to PharoKernel. Cheers -- Pavel

Oct. 24, 2010

Re: [Pharo-project] Smells looking at collections

by Johan Brichau

On 24 Oct 2010, at 08:42, StÃ©phane Ducasse wrote: >> Well, Traits are in Squeak since 2006, IIRC they were available a few years earlier. So in the last X (at least 4) years the only good candidate to become a Trait was Magnitude. PolyMorphic also uses traits. There are non-core projects that also use them, for example WebTester. I can also name several occassions in the development of our application, where we considered using traits to avoid code duplication. The only reason we didn't was because of a need for portability to GS. But if I understood correctly, it's quite possible that GS will support them in the future. Traits are being added to many other languages as well (e.g. traitsjs.org) It would be a shame to remove them from Squeak/Pharo Smalltalk now. just my 2 cents, Johan

Oct. 24, 2010

Re: [Pharo-project] Smells looking at collections

by Levente Uzonyi

On Sun, 24 Oct 2010, StÃ©phane Ducasse wrote: >>>> >> Not trivial? Maybe not, but only a little bit harder than trivial. > > We are open to suggestions believe me :) >> >>> 2) well, this is difficult to get the money for the butter and the butter - we are trying. >> >> If you can compose classes the way you can add a trait to a class now with class and optional method level instance+class variable mapping, then you're done. It would be a lot simpler to use it _and_ it would also be a lot easier to implement it. Especially the tools part. > > I'm interested to hear more about that. > Tell us more. The problem we faced was > - offset access = you cannot reuse bytecode of a trait because the order of the offset can be different in each trait users If you mean that a CompiledMethod of a trait cannot be added to the class' method dictionary, than that's not an issue. The current Trait implementation was changed, because shared CompiledMethods caused other problems. If you mean that the same bytecodes can't be used, than that's neither a problem, because you can and should be compile the method again. Sharing trailer bytes may cause problems. So adding a method from a trait to a class is simply recompiling it in the class' context. Instance variables should be used by name during compilation. If there's a name collision then use the instance variable map I mentioned above. > - initialization of instances variables at the trait level and the composition at the class levele You can always rename a trait's method in your class. So if the trait has an #initialize method, then simply rename it to #initializeFooBar and send it from the class' #initialize method. Levente > >> >>> 3) again if nobody does anything and we just all cry on ourselves then nothing will happen. >> >> Tools are a must. No tools - no users. > > Exact. > >>> So for now identifying traits and learning is the way. Then we can refactor, redesign >> >> Well, Traits are in Squeak since 2006, IIRC they were available a few years earlier. So in the last X (at least 4) years the only good candidate to become a Trait was Magnitude. > > Come on. > I will not answer to such statement because I'm positive thinking. > > Stef > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 24, 2010