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

Re: [Pharo-project] [TODO] 1.2 full build broken since 5 days

by Mariano Martinez Peck

Thank you so much Dale for all your effort in Pharo, Seaside, Metacello, etc. It is cool that people like you from Gestome can help that much. On Tue, Jun 7, 2011 at 8:34 PM, Dale Henrichs <dhenrich(a)vmware.com> wrote: > Fixed a subtle problem in 1.2.4-baseline version of > ConfigurationOfOmniBrowser (see > http://code.google.com/p/metacello/issues/detail?id=144) > > After correcting the configuration, the load completed without error in my > test env ... we'll see what the next hudson build brings:) > > Dale > > ----- Original Message ----- > | From: "Dale Henrichs" <dhenrich(a)vmware.com> > | To: Pharo-project(a)lists.gforge.inria.fr > | Sent: Tuesday, June 7, 2011 10:15:27 AM > | Subject: Re: [Pharo-project] [TODO] 1.2 full build broken since 5 days > | > | I'm going to look into this issue ... where can I find the build > | script that is used for Pharo-1.2? I want to duplicate the > | operations done by Hudson and I can't seem to find a link to the > | script anywhere on the site ... > | > | Dale > | > | ----- Original Message ----- > | | From: "Norbert Hartl" <norbert(a)hartl.name> > | | To: Pharo-project(a)lists.gforge.inria.fr > | | Sent: Tuesday, June 7, 2011 1:47:56 AM > | | Subject: Re: [Pharo-project] [TODO] 1.2 full build broken since 5 > | | days > | | > | | > | | Am 07.06.2011 um 10:37 schrieb Norbert Hartl: > | | > | | > I cannot reach the server so I cannot check. But I checked at the > | | > weekend and wrote a mail to the pharo list. The build failed > | | > because it couldn't load a file from Lukas' server. I could load > | | > it via my browser. So triggering a new build will hopefully fix > | | > it. > | | > > | | Ok, now I see. It has been restarted but there is another error. > | | > | | Norbert > | | > Norbert > | | > > | | > Am 07.06.2011 um 09:47 schrieb Marcus Denker: > | | > > | | >> Hello, > | | >> > | | >> The 1.2 full build is broken since 5 days > | | >> > | | >> > | | >> https://pharo-ic.lille.inria.fr/hudson/job/Pharo%201.2/ > | | >> > | | >> Someone needs to fix it. > | | >> > | | >> -- > | | >> Marcus Denker -- http://www.marcusdenker.de > | | >> INRIA Lille -- Nord Europe. Team RMoD. > | | >> > | | >> > | | > > | | > > | | > | | > | | > | > | > > -- Mariano http://marianopeck.wordpress.com

June 7, 2011

[Pharo-project] TWM: Multiple World integration

by laurent laffont

With the help of my local developper group, I've integrated Sean DeNigris work and now Tiling Window Manager supports Multiple Worlds. Here's a screencast that shows the progress. (My English seems a little less catastrophic than the previous screencast :) http://magaloma.blogspot.com/2011/06/multiple-worlds-for-twm.html Cheers, Laurent Laffont - @lolgzs <http://twitter.com/#!/lolgzs> Pharo Smalltalk Screencasts: http://www.pharocasts.com/ Blog: http://magaloma.blogspot.com/ Developer group: http://cara74.seasidehosting.st

June 7, 2011

Re: [Pharo-project] support for flattening-out traits for export?

by StÃ©phane Ducasse

> > These phrases are related to innovation in our language. > >> Adding more language features to be comparable to other languages? > > It's not about making Smalltalk to be comparable to other languages, > it's about trying new ideas. I think Smalltalk is a good platform for > that and traits are such an idea. Now, maybe traits implementation is > not perfect. Maybe developer support is not good. I think developer > support will follow the arrival of Nautilus and Glamour which makes it > much simpler to try new ideas. > > Do we want to keep traits in the system? Maybe not. Do we want to > delete them and forget them forever? I certainly don't want that > because I see real potential in traits. So, either we keep them in the > system or we make it possible to load them. I'm not sure solution #2 > is doable and nobody showed interest yet. Damien I always wanted to evaluate what andreas did in Squeak and see if we could simplify trait implementation and plug them. Davdi R. did a really good job with his browser for traits support. Coding with it was really good for traits. Now Nautilus is not trait-friendly and you are right that Glamour may change it. Now this is not really important. I prefer to get: - opal - new event - cleaning the UI - bring Ring in the system (new declarative code model) and we will see for trait later. Stef

June 7, 2011

Re: [Pharo-project] support for flattening-out traits for export?

by StÃ©phane Ducasse

Hi eliot we are nearly in sync :). > and e.g. if it looses traits then at least provides tools for importing packages with traits, eliminating the trait usage on the way in, and in general provides tools for cleaning-up packages (i.e. refactoring with clean-ups) so that old packages continue to function, and so that users can continue to use Pharo in their daily work. We always pay attention to that. We are working on tools to support change and evolution. Now we do not have enough man power. Torch is the example of the best tools for understanding changes I have seen but this is > But you also need Pharo the Phuture, which is a system moving towards your vision. By maintaining the two side-by-side you get to work on migration tools and you keep the existing user base happy while helping people to dip their toes in the Phuture water. I know its expensive, yes we know that and this is what we are doing > but if you just provide Phuture you'll alienate the existing user base and you won't provide a well-tooled migration path to bring that user base into the future. This is an agile, incremental approach to getting the entire community into the future, oh yes that we know and this is for the reason that classboxes were not adequate for real usage that we never push them. > instead of an isolated incremental approach, where only the developers at the core of Pharo can keep up with the incremental progress towards the vision. Anyway, that's how I would go about it. Yes this is our vision and process too. eliot what I want to say is that we did pharo to open space and reinvent Smalltalk. I have no problem to perform a real analysis and decide that we made a mistake and learn from it with traits (see the beginning of the other mails). I have a problem with cries and backward compatibility for the sake of it. If one of the smalltalk adds a good feature then we should copy it and we should add what we think is important. Smalltalk is not carved in stone. This is what we did for pragma (they are cool). We have the initialize invoked automatically (like CLOS since 90). Now if we do not give intellectual space for inventing on the pretext of backward compatibility then frankly better do something else. I think that pharo is doing a good job and we will continue and we will add/change the language for the better. We want slots for example because this is really good. And some people will do not like it and be against and use the "non compatible" flag. The feedback we got from some venture oriented people is that: it is old. Sure they are probably idiot but with money and power in our case. So if I would sell the java, javascript it would be much simpler (even if the java hype i over and people are open to dynamic language): clojure, scala... xxxx. So my point is at least we should be imaginative and show that we are smart and that we can learn from others and be open to change. This is my main point. I do not care about traits: I care about innovation and the place we give it. For example we got a really nice presentation from tom van cutsem about the new scheme for proxy in Javascript and this is good and they will have a nice way to secure some part of Javascript. So mariano is working on Ghost and we want a really good proxy implementation and we will have it. This is the same for Fuel: we liked the idea of the pickle format and we will have a nice object-serializers. These two examples are not about the languages but for me this is the same. Ghost is based on a VM hook that does not exist in other Smalltalk. so too bad ;) Stef

June 7, 2011

Re: [Pharo-project] support for flattening-out traits for export?

by Damien Cassou

On Tue, Jun 7, 2011 at 5:20 PM, Torsten Bergmann <astares(a)gmx.de> wrote: >>"he last time something serious was new in Smalltalk it was back in 1984" >>"got killed by Java" >>"Pharo is not about maintaining the past." > > Sorry Stef, but to me these are phrases and not releated to > the question about the usefullness of Traits. These phrases are related to innovation in our language. > Adding more language features to be comparable to other languages? It's not about making Smalltalk to be comparable to other languages, it's about trying new ideas. I think Smalltalk is a good platform for that and traits are such an idea. Now, maybe traits implementation is not perfect. Maybe developer support is not good. I think developer support will follow the arrival of Nautilus and Glamour which makes it much simpler to try new ideas. Do we want to keep traits in the system? Maybe not. Do we want to delete them and forget them forever? I certainly don't want that because I see real potential in traits. So, either we keep them in the system or we make it possible to load them. I'm not sure solution #2 is doable and nobody showed interest yet. -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry

June 7, 2011

Re: [Pharo-project] support for flattening-out traits for export?

by StÃ©phane Ducasse

Torsten I wrote the following before reading your mail.... Hi guys just to make sure that everybody understand our point of view about traits. I was thinking that we could remove them. Now we have more important point to do and traits can be useful from time to time (but even there we are not bound to them). Now what would be better is: - can we have a simpler/better trait model? - can we plug traits in a kernel? - can we control the induced complexity? Stef still my point is valid. >> Just a meta question..... > > What about real questions: > > - are Traits used these days > - in which packages and why > - how is the adoption rate > > I havent much used them by myself (mostly due to the lack of > time to dig into it) but I would like to learn about the current > state of Traits (is it used, maintained, usable). it is used, it is maintained and it is stable. > > And yes - we can add lots of (language) features. But we > should also discuss/measure/find out if they are usefull. > Some of them help us moving forward others may stand in our > way. And "Keep it simple" is always a good rule ... torsten, did you see all the work we did about traits? Adrian rewrote the implementation from scratch it took him around 6 months. Then Damien did a real reimplementation of stream. > One great thing in languages like Smalltalk is that > you can care about the problem ... and not so much about > satisfying the compiler or knowing about the 10 most recent > language features nailed to the language to circumvent problems > from early language design. > > I think we should be more serious ... I'm really serious. I'm not doing pharo to have an old Smalltalk-80 languages. > Marianos may have > some valid points we should discuss. So let him tell us > why he avoided Traits and what are the issues with tools. > Let's listen and learn. > >> "he last time something serious was new in Smalltalk it was back in 1984" >> "got killed by Java" >> "Pharo is not about maintaining the past." > > Sorry Stef, but to me these are phrases and not releated to > the question about the usefullness of Traits. Indeed, but what I see is that a lot of people spent time on traits. > Language features were not the reasons why Java took up. certainly not so what? > Back at the time it was small, free, multiplatform and available in > the web (applets) when the web took up and no radical change for > most programmers. > > In fact languages features are discussed these days for Java > and we should discuss them too... so? > Especially since Smalltalk is not a programming language ... more > a dynamic object system on top of a VM with a language built in. > > Which path would we like to take with Pharo? Adding more language > features to be comparable to other languages? Or even become a > multilanguage platform/embed new languages similar to JVM and > .NET VM (maybe with Helvetia)? What are our goals here? We are not discussing about features. We want to have first class instance variables because early smalltalkers totally missed their power. We will probably work on a good module system and points for security. for the vision watch the barcelona video, listen the podcast of james robertson or wait for the next esug. Sorry I do not have the time for that now. Stef

June 7, 2011

Re: [Pharo-project] support for flattening-out traits for export?

by Mariano Martinez Peck

On Tue, Jun 7, 2011 at 7:48 PM, Eliot Miranda <eliot.miranda(a)gmail.com>wrote: > > > On Mon, Jun 6, 2011 at 11:11 PM, Mariano Martinez Peck < > marianopeck(a)gmail.com> wrote: > >> >> >> On Tue, Jun 7, 2011 at 12:47 AM, Eliot Miranda <eliot.miranda(a)gmail.com>wrote: >> >>> Hi All, >>> >>> if I want to export a package (Fuel!!) to a dialect without traits is >>> there anything to help me remove the trait info and just file-out the >>> composed code? >>> >>> >> Hi Eliot. Traits are only used in Fuel for testing. And really used for >> testing methods for classes and traits (not the basic methods). So, of >> course, you can directly fileout the Fuel package only without traits. >> > > Hmm, at least in Fuel stable 1.4 there exists FLTWithClass trait which is > used by FLObjectCluster and FLRawArrayedCollectionCluster. > yes, sorry Eliot for my false assumption. Martin remembered that to me today afternoon :( > This seems reasonable to me; Pharo and Squeak currently support traits. > But I'm trying to use Fuel in Newsqueak (the Squeak Newspeak > implementation) and we eliminated traits from that system. So... > > > Turns out there is a facility to remove traits, and had I browsed before > asking (lazy man, me) I would have found it (I'm in an updated 1.2): > > Behavior>>flattenDownAllTraits > > Interesting. I wasn't aware of that :) > and so one can theoretically eliminate traits from Fuel by e.g. > > #('Fuel' 'FuelTests') do: > [:pn| > (SystemNavigation new allClassesInPackageNamed: pn) do: > [:c| > c isTrait > ifTrue: [c category: #Unpackaged] > ifFalse: > [{c. c class} do: [:b| b flattenDownAllTraits]]]] > > but there's a couple of bugs, one weird. The first bug is that > basicLocalSelectors can answer nil and so Behavior>>flattenDown: (find > attached) needs to read: > > flattenDown: aTrait > | selectors | > [self hasTraitComposition and: [self traitComposition allTraits includes: > aTrait]] assert. > selectors := (self traitComposition transformationOfTrait: aTrait) > selectors. > self basicLocalSelectors: (self basicLocalSelectors > ifNil: [selectors] > ifNotNil: [:bls| bls , selectors]) asSet. > self removeFromComposition: aTrait > > But the weird bug, which I suppose could be a Cog VM bug, and that I don't > have time to track down right now, is that if I try the doit > above FLRawArrayedCollectionCluster class ends up losing its #for: method > from FLTWithClass classTrait but FLObjectCluster does not. But if I > evaluate > > FLRawArrayedCollectionCluster class flattenDownAllTraits. > > manually before the doit then FLRawArrayedCollectionCluster class does > /not/ lose its #for: method and everything is ok. > > weird....Maybe Adrian can help us? > > BTW, I find adding a literal selector mode to the finder is really useful. > Being able to look for just #for: instead of all the selectors containing > for: makes finding for: much easier (try it and see) ;) > +1 > So find attached a modification to the finder that matches exactly that > selector if one surrounds it with double quotes. i.e. searching for "for:" > finds only the implementors of #for:. > > Great, thanks! I will ask benjamin to integrate it :) > > >> One of the things I always wanted is what you are really asking, a way to >> fileout forgetting traits, just letting those methods directly in the >> classes. But I have no idea if that's possible. >> > > Well, if we can track down and fix the bug then a package-level > flattenDownAllTraits could be constructed and provided from a menu. That > would be useful and as you can see, at least theoretically its easily done > :) > Yes, it sounds good. > > >> Finally, I was never really convinced about the Traits usage in Fuel. >> Mostly because some tools seem not to be happy with them...We should check >> how much difficult and what we loose removing them now.... >> > > At least in Fuel core you'd loose almost nothing. > This this can be done in a couple of minutes. But what do you win? if you cannot really testes (because most traits are there) you won't be sure if it works. > The FLTWithClass trait adds 6 methods but is used only by two subclasses of > FLCluster, (FLObjectCluster and FLRawArrayedCollectionCluster). So you > could add a subclass of FLCluster, e.g. FLClusterWithClass, and then > move FLObjectCluster and FLRawArrayedCollectionCluster under it. At least > that's what I'd do. > +1. Sounds a good solution. I will do this with Martin. Would that help? > > best, > Eliot > > P.S. Fuel looks well-factored. I like the idea of abstracting the code > for marshalling specific kinds of classes into the FLCluster hierarchy. > Thanks :) Several times we discussed what to do. One possibility is what is done now. The other one, like Colin's S&M does, is that each class, say Float, SmallInteger, ByteArray, etc, instead of answering kind of specific claster, they all use the same but different methods. Examples: Float >> serialize FLSerializer serializeFloat: self. ByteArray >> serialize FLSerializer serializeByteArray: self. etc... this makes easy porting it to other dialect because you jus change one class. But such class is big with a lot of methods. We prefer our design which splits the behavior in different classes, but makes porting more complicated since you should change most of the FLCluster hierarchy. > I look forward to providing more feedback once we're using Fuel. > > And we are looking forward to receive feedback as well. > >> Cheers >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> >> > -- Mariano http://marianopeck.wordpress.com

June 7, 2011

Re: [Pharo-project] [TODO] 1.2 full build broken since 5 days

by Dale Henrichs

Fixed a subtle problem in 1.2.4-baseline version of ConfigurationOfOmniBrowser (see http://code.google.com/p/metacello/issues/detail?id=144) After correcting the configuration, the load completed without error in my test env ... we'll see what the next hudson build brings:) Dale ----- Original Message ----- | From: "Dale Henrichs" <dhenrich(a)vmware.com> | To: Pharo-project(a)lists.gforge.inria.fr | Sent: Tuesday, June 7, 2011 10:15:27 AM | Subject: Re: [Pharo-project] [TODO] 1.2 full build broken since 5 days | | I'm going to look into this issue ... where can I find the build | script that is used for Pharo-1.2? I want to duplicate the | operations done by Hudson and I can't seem to find a link to the | script anywhere on the site ... | | Dale | | ----- Original Message ----- | | From: "Norbert Hartl" <norbert(a)hartl.name> | | To: Pharo-project(a)lists.gforge.inria.fr | | Sent: Tuesday, June 7, 2011 1:47:56 AM | | Subject: Re: [Pharo-project] [TODO] 1.2 full build broken since 5 | | days | | | | | | Am 07.06.2011 um 10:37 schrieb Norbert Hartl: | | | | > I cannot reach the server so I cannot check. But I checked at the | | > weekend and wrote a mail to the pharo list. The build failed | | > because it couldn't load a file from Lukas' server. I could load | | > it via my browser. So triggering a new build will hopefully fix | | > it. | | > | | Ok, now I see. It has been restarted but there is another error. | | | | Norbert | | > Norbert | | > | | > Am 07.06.2011 um 09:47 schrieb Marcus Denker: | | > | | >> Hello, | | >> | | >> The 1.2 full build is broken since 5 days | | >> | | >> | | >> https://pharo-ic.lille.inria.fr/hudson/job/Pharo%201.2/ | | >> | | >> Someone needs to fix it. | | >> | | >> -- | | >> Marcus Denker -- http://www.marcusdenker.de | | >> INRIA Lille -- Nord Europe. Team RMoD. | | >> | | >> | | > | | > | | | | | | | |

June 7, 2011

Re: [Pharo-project] support for flattening-out traits for export?

by Eliot Miranda

On Tue, Jun 7, 2011 at 7:18 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>wrote: > Just a meta question..... > So what will people do when we will add slots? Leave/cry and complain as > usual? When Common lisp got slots since 1990 and the world imagination got > killed by Java, it makes me think. > May be we are not a community to invent something after all. Especially if > we are not ready because the last time something serious was new in > Smalltalk it was back in 1984. > I think to invent something new you have to fork. IMO, the community needs Pharo the platform, which stays backwards-compatible, and e.g. if it looses traits then at least provides tools for importing packages with traits, eliminating the trait usage on the way in, and in general provides tools for cleaning-up packages (i.e. refactoring with clean-ups) so that old packages continue to function, and so that users can continue to use Pharo in their daily work. But you also need Pharo the Phuture, which is a system moving towards your vision. By maintaining the two side-by-side you get to work on migration tools and you keep the existing user base happy while helping people to dip their toes in the Phuture water. I know its expensive, but if you just provide Phuture you'll alienate the existing user base and you won't provide a well-tooled migration path to bring that user base into the future. This is an agile, incremental approach to getting the entire community into the future, instead of an isolated incremental approach, where only the developers at the core of Pharo can keep up with the incremental progress towards the vision. Anyway, that's how I would go about it. > > Mariano this is not against you but in general. Pharo is not about > maintaining the past. > This notion of compatibility is doomed, because first VW does not ask pharo > to add a feature in the language (like these wonderful namespaces or XML > code format) > Second, this means that nobody can evolve. While we have the tools to > manage difference. > So of course traits could be better but this is not by being negative on > attempt to move our wonderful old community that we will make progress. > Or may be the best way is just to tell us that we should better invest in > Javascript and we will all look far cooler in fact. > Are you really afflicted with FUD? Talk to e.g. Gilad about using Javascript for Newspeak and you'll find there are a host of deep serious problems using it. Its community is large which implies great inertia. There are basic problems with the language (it lacks structure, it is difficult to implement efficiently). There are problems with its tools. But unlike Pharo and Squeak you don't have control unless you maintain your own fork. As they say, better the devil you know than the devil you don't. Stay strong and cast those doubts aside. You're on the right track; you just need to think a bit about how to walk down it. best wishes, and hugs, Eliot > > Stef > > > > On Jun 7, 2011, at 3:10 PM, Mariano Martinez Peck wrote: > > > Thanks Adrian. > > > > BTW, there is no way to fileout a whole Monticello package? it seems I > have to manually do a fileout of each category, not package :( > > > > Eliot: we were discussing today with Martin and maybe we will get rid of > Traits. The truth is that in our case we use them mostly for tests and we > think that with a good refactor we can avoid using them without duplicating > too much code. In fact, we suffer several problems with traits and the > integration with tools like Monticello. And even more it makes porting more > complicated. We cannot code that much now because we are preparing a paper > for ESUG but we will give it a try. > > > > Taking into account all your knowledge and experience in general and with > Parcels, we will LOVE to listen your feedback for Fuel. > > > > Cheers > > > > Mariano > > > > > > On Tue, Jun 7, 2011 at 12:29 PM, Adrian Lienhard <adi(a)netstyle.ch> > wrote: > > IIRC this can be achieved with two small changes: > > > > - Comment out the line "method isLocalSelector" from > PackageInfo>>methods. This will flatten the traits into the classes, i.e., > make all methods of a class being stored even if they come from a trait. > > > > - In addition you probably need to change PackageInfo>>classes to filter > out all traits (like ... reject: #isTrait). > > > > HTH, > > Adrian > > > > On Jun 7, 2011, at 08:11 , Mariano Martinez Peck wrote: > > > > > On Tue, Jun 7, 2011 at 12:47 AM, Eliot Miranda < > eliot.miranda(a)gmail.com>wrote: > > > > > >> Hi All, > > >> > > >> if I want to export a package (Fuel!!) to a dialect without traits > is > > >> there anything to help me remove the trait info and just file-out the > > >> composed code? > > >> > > >> > > > Hi Eliot. Traits are only used in Fuel for testing. And really used for > > > testing methods for classes and traits (not the basic methods). So, of > > > course, you can directly fileout the Fuel package only without traits. > > > > > > One of the things I always wanted is what you are really asking, a way > to > > > fileout forgetting traits, just letting those methods directly in the > > > classes. But I have no idea if that's possible. > > > > > > Finally, I was never really convinced about the Traits usage in Fuel. > Mostly > > > because some tools seem not to be happy with them...We should check how > much > > > difficult and what we loose removing them now.... > > > > > > Cheers > > > > > > -- > > > Mariano > > > http://marianopeck.wordpress.com > > > > > > > > > > > > -- > > Mariano > > http://marianopeck.wordpress.com > > > > >

June 7, 2011

Re: [Pharo-project] support for flattening-out traits for export?

by Eliot Miranda

On Mon, Jun 6, 2011 at 11:11 PM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > > > On Tue, Jun 7, 2011 at 12:47 AM, Eliot Miranda <eliot.miranda(a)gmail.com>wrote: > >> Hi All, >> >> if I want to export a package (Fuel!!) to a dialect without traits is >> there anything to help me remove the trait info and just file-out the >> composed code? >> >> > Hi Eliot. Traits are only used in Fuel for testing. And really used for > testing methods for classes and traits (not the basic methods). So, of > course, you can directly fileout the Fuel package only without traits. > Hmm, at least in Fuel stable 1.4 there exists FLTWithClass trait which is used by FLObjectCluster and FLRawArrayedCollectionCluster. This seems reasonable to me; Pharo and Squeak currently support traits. But I'm trying to use Fuel in Newsqueak (the Squeak Newspeak implementation) and we eliminated traits from that system. So... Turns out there is a facility to remove traits, and had I browsed before asking (lazy man, me) I would have found it (I'm in an updated 1.2): Behavior>>flattenDownAllTraits and so one can theoretically eliminate traits from Fuel by e.g. #('Fuel' 'FuelTests') do: [:pn| (SystemNavigation new allClassesInPackageNamed: pn) do: [:c| c isTrait ifTrue: [c category: #Unpackaged] ifFalse: [{c. c class} do: [:b| b flattenDownAllTraits]]]] but there's a couple of bugs, one weird. The first bug is that basicLocalSelectors can answer nil and so Behavior>>flattenDown: (find attached) needs to read: flattenDown: aTrait | selectors | [self hasTraitComposition and: [self traitComposition allTraits includes: aTrait]] assert. selectors := (self traitComposition transformationOfTrait: aTrait) selectors. self basicLocalSelectors: (self basicLocalSelectors ifNil: [selectors] ifNotNil: [:bls| bls , selectors]) asSet. self removeFromComposition: aTrait But the weird bug, which I suppose could be a Cog VM bug, and that I don't have time to track down right now, is that if I try the doit above FLRawArrayedCollectionCluster class ends up losing its #for: method from FLTWithClass classTrait but FLObjectCluster does not. But if I evaluate FLRawArrayedCollectionCluster class flattenDownAllTraits. manually before the doit then FLRawArrayedCollectionCluster class does /not/ lose its #for: method and everything is ok. BTW, I find adding a literal selector mode to the finder is really useful. Being able to look for just #for: instead of all the selectors containing for: makes finding for: much easier (try it and see) ;) So find attached a modification to the finder that matches exactly that selector if one surrounds it with double quotes. i.e. searching for "for:" finds only the implementors of #for:. > One of the things I always wanted is what you are really asking, a way to > fileout forgetting traits, just letting those methods directly in the > classes. But I have no idea if that's possible. > Well, if we can track down and fix the bug then a package-level flattenDownAllTraits could be constructed and provided from a menu. That would be useful and as you can see, at least theoretically its easily done :) > Finally, I was never really convinced about the Traits usage in Fuel. > Mostly because some tools seem not to be happy with them...We should check > how much difficult and what we loose removing them now.... > At least in Fuel core you'd loose almost nothing. The FLTWithClass trait adds 6 methods but is used only by two subclasses of FLCluster, (FLObjectCluster and FLRawArrayedCollectionCluster). So you could add a subclass of FLCluster, e.g. FLClusterWithClass, and then move FLObjectCluster and FLRawArrayedCollectionCluster under it. At least that's what I'd do. best, Eliot P.S. Fuel looks well-factored. I like the idea of abstracting the code for marshalling specific kinds of classes into the FLCluster hierarchy. I look forward to providing more feedback once we're using Fuel. > Cheers > > -- > Mariano > http://marianopeck.wordpress.com > >

June 7, 2011