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

Re: [Pharo-project] About Adding/modifying in SUnit or not?

by Lukas Renggli

I am all in for improving SUnit, but there must be some compatibility mode that makes it easy not only to run, but also to write tests on the official SUnit. This is crucial for projects like Seaside, Magritte, Pier, PetitParser, ... that are supposed to work on various other Smalltalk platforms. Lukas On 25 October 2010 15:51, Niko Schwarz <niko.schwarz(a)googlemail.com> wrote: > Yea, well, it depends on whether we want to be compatible with camp > smalltalk's SUnit, as maintained by Niall Ross: > http://sunit.sourceforge.net/devel.htm. Pharo already is using > extensions, such as the possibility to mark tests as expected failures > at all (that is impossible in standard SUnit). > > My humble opinion is that we must control our testing environment, and > we already have an excellent cleanup of SUnit, namely akuhn/SUnit, > http://www.squeaksource.com/akuhn.html. And we have progress in the > form of Phexample, which builds ontop of SUnit. > http://smalltalkthoughts.blogspot.com/2009/11/phexample-because-examples-ex… > . I'd be more than happy if Pharo took a new SUnit as its standard > testing framework, and I'd even be thrilled if enough people found > Phexample useful enough, so that it could become standard over time. > > Niko > > 2010/10/25 Luc Fabresse <luc.fabresse(a)gmail.com>: >> Hi all, >> Â I am working on pushing environments in SystemNavigation. >> Â SystemNavigationTest previously used ClassFactoryForTestCase from SUnit for >> generating Â classes. >> Â Now I need an environment-awareÂ ClassFactoryForTestCase. >> Â Should I directly modifyÂ ClassFactoryForTestCase since a class generator >> should now be environment aware? >> Â Should I subclassÂ ClassFactoryForTestCase and put it in SUnit? >> Â Should I never changed SUnit and put it elsewhere? ;-) >> #Luc >> _______________________________________________ >> 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 > -- Lukas Renggli www.lukas-renggli.ch

Oct. 25, 2010

Re: [Pharo-project] About Adding/modifying in SUnit or not?

by Niko Schwarz

Yea, well, it depends on whether we want to be compatible with camp smalltalk's SUnit, as maintained by Niall Ross: http://sunit.sourceforge.net/devel.htm. Pharo already is using extensions, such as the possibility to mark tests as expected failures at all (that is impossible in standard SUnit). My humble opinion is that we must control our testing environment, and we already have an excellent cleanup of SUnit, namely akuhn/SUnit, http://www.squeaksource.com/akuhn.html. And we have progress in the form of Phexample, which builds ontop of SUnit. http://smalltalkthoughts.blogspot.com/2009/11/phexample-because-examples-ex… . I'd be more than happy if Pharo took a new SUnit as its standard testing framework, and I'd even be thrilled if enough people found Phexample useful enough, so that it could become standard over time. Niko 2010/10/25 Luc Fabresse <luc.fabresse(a)gmail.com>: > Hi all, > Â I am working on pushing environments in SystemNavigation. > Â SystemNavigationTest previously used ClassFactoryForTestCase from SUnit for > generating Â classes. > Â Now I need an environment-awareÂ ClassFactoryForTestCase. > Â Should I directly modifyÂ ClassFactoryForTestCase since a class generator > should now be environment aware? > Â Should I subclassÂ ClassFactoryForTestCase and put it in SUnit? > Â Should I never changed SUnit and put it elsewhere? ;-) > #Luc > _______________________________________________ > 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

Oct. 25, 2010

[Pharo-project] About Adding/modifying in SUnit or not?

by Luc Fabresse

Hi all, I am working on pushing environments in SystemNavigation. SystemNavigationTest previously used ClassFactoryForTestCase from SUnit for generating classes. Now I need an environment-aware ClassFactoryForTestCase. Should I directly modify ClassFactoryForTestCase since a class generator should now be environment aware? Should I subclass ClassFactoryForTestCase and put it in SUnit? Should I never changed SUnit and put it elsewhere? ;-) #Luc

Oct. 25, 2010

Re: [Pharo-project] what happened with Shout colors in Pharo 1.1?

by Alain Plantec

Le 25/10/2010 11:56, Mariano Martinez Peck a Ã©crit : > > Yes, we talked about that with Alain at Esug. It would be cool if > the 'choose packages' button, which filters entries in the > settings, would also apply to saving style. That way we could only > save partial settings. > > > Yes that would be awesome!!! I was thinking of giving the possibility to select settings individually (not grouped by package). Alain > > > > Thanks Simon. > > -- > Simon > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > <mailto:Pharo-project@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. 25, 2010

Re: [Pharo-project] what happened with Shout colors in Pharo 1.1?

by Mariano Martinez Peck

2010/10/25 Simon Denier <Simon.Denier(a)inria.fr> > > On 23 oct. 2010, at 19:13, Mariano Martinez Peck wrote: > > > To customize colors, two solutions: >> 1) hack SHTextStylerST80>>defaultStyleTable >> > > did you do this? can you share? > > > Well that's the standard mechanism which was already in place. Just take a > look at the comment to learn the format. It's a bit cumbersome to use > though. > > To change style for instance vars/class vars > (instVar ( blue muchDarker ) ) > (classVar ( blue muchDarker ) ) > > To change style for class (actually it's more like access to global > variables) > (poolConstant ( blue muchDarker ) ) > (globalVar ( blue muchDarker ) ) > > > > >> 2) load latest Shout and use Settings (then you should be able to >> save/load your style), since there is now a Settings interface >> >> > The problem is that I have my own style also....and when you save an style > I think you save it completly...I guess you cannot merge, so I will loose my > own changes. > Anyway, can you export and share the style so that I can take a look? > > > Yes, we talked about that with Alain at Esug. It would be cool if the > 'choose packages' button, which filters entries in the settings, would also > apply to saving style. That way we could only save partial settings. > Yes that would be awesome!!! > > Anyway, there's not much to change through the Settings browser. Easier to > show there: > > Before: > > After: > > > Thanks Simon. > -- > Simon > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 25, 2010

Re: [Pharo-project] what happened with Shout colors in Pharo 1.1?

by Simon Denier

On 23 oct. 2010, at 19:13, Mariano Martinez Peck wrote: > > To customize colors, two solutions: > 1) hack SHTextStylerST80>>defaultStyleTable > > did you do this? can you share? Well that's the standard mechanism which was already in place. Just take a look at the comment to learn the format. It's a bit cumbersome to use though. To change style for instance vars/class vars (instVar ( blue muchDarker ) ) (classVar ( blue muchDarker ) ) To change style for class (actually it's more like access to global variables) (poolConstant ( blue muchDarker ) ) (globalVar ( blue muchDarker ) ) > > 2) load latest Shout and use Settings (then you should be able to save/load your style), since there is now a Settings interface > > > The problem is that I have my own style also....and when you save an style I think you save it completly...I guess you cannot merge, so I will loose my own changes. > Anyway, can you export and share the style so that I can take a look? Yes, we talked about that with Alain at Esug. It would be cool if the 'choose packages' button, which filters entries in the settings, would also apply to saving style. That way we could only save partial settings. Anyway, there's not much to change through the Settings browser. Easier to show there: Before: After: -- Simon

Oct. 25, 2010

[Pharo-project] [update 1.2] #12214

by Marcus Denker

12214 ----- Issue 3156: StandardWindow should not redefine #initialExtent Issue 2899: Slice creation should add dirty packages are dependent Issue 2766: World Screen capture should be adapted to Pharo Issue 2256: #sortBy: should be deprecated (minus the deprication call in sortBy:.. will come later) -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

Oct. 25, 2010

Re: [Pharo-project] Smells looking at collections

by Levente Uzonyi

On Sun, 24 Oct 2010, Eliot Miranda wrote: > Hi Levente, > > in my experience playing with the Dan and Alan Borning's multiple > inheritance implementation getting things to work was one thing, reasonably > straighforward, but getting tool support right (file-out format so that > things filed back in correctly, etc) was another, an dth ebulk of the work. > Looking at your proposal below I see no problem getting it to work but see > lots of problems integrating it, e.g. with Monticello, etc. Traits is You're right, integration is hard. It would probably be harder than the integration of Traits was. > already integrated with Monticello, supported with tests, etc. As such it > is a much less risky or effortful proposition than a new scheme. So with > that in mind are there important functional benefits of your scheme's direct > state access as compared with traits that use accessors to access state that > each user of a trait must implement? i.e. what are the key benefits you see > in direct inst var access? I see four benefits: - a bit better performance on current VMs - no name conflict (accessors) - accessor methods can also be reused - the ability to reuse the code of existing classes (this may cause problems) Let's see the same example as a Trait: Trait named: #TBidirectionalLink uses: #() category: 'ClassCompositionExample' TBidirectionalLink >> unlink self previous next: self next. self next previous: self previous TBidirectionalLink >> linkAfter: aBidirectionalLink self previous: aBidirectionalLink. self next: aBidirectionalLink next. aBidirectionalLink next: self. self next previous: self And the user: ECSelectorEntry subclass: #ODatedEntry uses: TBidirectionalLink instanceVariableNames: 'date next previous' classVariableNames: '' poolDictionaries: '' category: 'Ocompletion' ODatedEntry (and all other users of TBidirectionalLink) has to implement four methods (the accessors): ODatedEntry >> next ^next ODatedEntry >> next: anODatedEntry next := anODatedEntry ODatedEntry >> previous ^previous ODatedEntry >> previous: anODatedEntry previous := anODatedEntry This is only possible if ODatedEntry (or a superclass of it) doesn't implement any of these methods, otherwise the Trait can't be used. Levente > > best > Eliot > > 2010/10/24 Levente Uzonyi <leves(a)elte.hu> > >> On Sun, 24 Oct 2010, StÃ©phane Ducasse wrote: >> >> >>>>> >>>>>> 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. >>> >> >> Okay, here is an example of my class composition idea. It works like >> Traits, but it supports state and there's no distinction between a trait and >> a class. Let's say I have a class named BidirectionalLink which can be used >> as a link in a linked list (with a head element). This will be used as a >> stateful trait. It's definition is like this: >> >> Object subclass: #BidirectionalLink >> instanceVariableNames: 'next previous' >> classVariableNames: '' >> poolDictionaries: '' >> category: 'ClassCompositionExample' >> >> It has a few methods: >> >> BidirectionalLink >> next >> ^next >> >> BidirectionalLink >> next: aBidirectionalLink >> next := aBidirectionalLink >> >> BidirectionalLink >> previous >> ^previous >> >> BidirectionalLink >> previous: aBidirectionalLink >> previous := aBidirectionalLink >> >> BidirectionalLink >> unlink >> previous next: next. >> next previous: previous >> >> BidirectionalLink >> linkAfter: aBidirectionalLink >> previous := aBidirectionalLink. >> next := aBidirectionalLink next. >> aBidirectionalLink next: self. >> next previous: self >> >> I have an existing class, let's call it ODatedEntry :). It has the >> following definition: >> >> ECSelectorEntry subclass: #ODatedEntry >> instanceVariableNames: 'date' >> classVariableNames: '' >> poolDictionaries: '' >> category: 'Ocompletion' >> >> As you can see, it inherits some state and behavior from ECSelectorEntry. >> My goal is to use the instances of this class in a linked list. So these >> objects should implement the same protocol with the same behavior as >> BidirectionalLink. I can't make it a subclass of BidirectionalLink, because >> I also need the behavior and state from ECSelectorEntry and we don't have >> multiple inheritance. So I'll compose the two classes. First I add the >> necessary instance variables to the class. Let's call them nextEntry and >> previousEntry: >> >> ECSelectorEntry subclass: #ODatedEntry >> instanceVariableNames: 'date nextEntry previousEntry' >> classVariableNames: '' >> poolDictionaries: '' >> category: 'Ocompletion' >> >> Then do the composition: >> >> ECSelectorEntry subclass: #ODatedEntry >> uses: BidirectionalLink >> instanceVariableNames: 'date nextEntry previousEntry' >> classVariableNames: '' >> poolDictionaries: '' >> category: 'Ocompletion' >> >> Now this doesn't work, because ODatedEntry doesn't have instance variables >> named next and previous, but the methods of BidirectionalLink would like to >> use them. Of course I could have used those names in the previous step and >> (with a working implementation) this would just work out of the box. But the >> example is about the instance variable mapping. Let's say ~ is the >> composition operator which defines variable mapping for a class or a method. >> Then I can write the following: >> >> ECSelectorEntry subclass: #ODatedEntry >> uses: BidirectionalLink ~ { #nextEntry -> #next. #previousEntry -> >> #previous } >> instanceVariableNames: 'date nextEntry previousEntry' >> classVariableNames: '' >> poolDictionaries: '' >> category: 'Ocompletion' >> >> This means: take all methods from BidirectionalLink, but replace the >> variable named next with nextEntry and previous with previousEntry. >> So now ODatedEntry understands #next, #next:, #previous, #unlink, etc. >> >> This is the basic concept. There are some open questions, like: >> - what happens when a composed method (or a method sent by a composed >> method, etc) has a super send? >> - will the class also get the methods of the superclasses of the "trait"? >> - how does it work on the class side? >> - what about class variables? >> - what if I don't want to use all methods, just a few? >> >> >>> >>> 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. >>> >> >> My idea is that traits don't add instance variables. The user of the trait >> maps the trait's variables to their own by name. So if a trait gets >> a new variable, then only the trait and subclasses have to be recompiled. >> The recompilation is postponed until a method of the trait which uses the >> new instance variable is added to a class. >> >> >>> 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 >>> >> >> See above. >> >> >> Levente >> >> >>> - 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 >>>> >>> >>> >>> _______________________________________________ >>> 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. 25, 2010

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

by Niko Schwarz

Couldn't Adrian be the maintainer? I could step in, too. I don't really know what you have in mind for a testing framework. We have our own independent and fully compatible fork of SUnit: akuhn/SUnit, which is quite a strong code basis. And on top of that we have Phexample, which has its own name, some extra features and gives a clear point where Pharo is different from the rest. Just a suggestion: Let Adrian maintain akuhn/SUnit, perhaps minus the "should" syntax that you don't like (as in: #(a b c) size should = 3), and make akuhn/SUnit part of Pharo core. The new features (having tests depend on one another, "should" syntax) go into Phexample, and I could maintain that. Cheers, Niko On Sun, Oct 24, 2010 at 8:37 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> 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 >>> >> > > > _______________________________________________ > 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

Oct. 25, 2010

Re: [Pharo-project] Learning on Sockets

by laurent laffont

Thank you Noury. Indeed for those interested in, I've just remembered that PBE is on github. So we can read it here http://github.com/SquareBracketAssociates/PharoByExample-english/blob/maste… Cheers, Laurent. On Mon, Oct 25, 2010 at 8:40 AM, Noury Bouraqadi <bouraqadi(a)gmail.com>wrote: > I can send you my PBE chapter on Socket (private email). > > Noury > On 24 oct. 2010, at 11:51, laurent laffont wrote: > > > Hi, > > > > I want to record a screencast on basic networking and also explore this > idea: http://forum.world.st/Community-in-the-IDE-tp2543540p2543540.html > > > > Do you have some links on documentation and/or good code to look at ? I'm > searching for best practices / modelizations to write a chat server and > client. > > > > Actually I've read and tried those: > > http://book.pharo-project.org/book/networking/Socket > > http://wiki.squeak.org/squeak/325 > > > > > > Cheers, > > > > Laurent Laffont > > > > Pharo Smalltalk Screencasts: http://www.pharocasts.com/ > > Blog: http://magaloma.blogspot.com/ > > _______________________________________________ > > 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. 25, 2010

Re: [Pharo-project] Learning on Sockets

by Noury Bouraqadi

I can send you my PBE chapter on Socket (private email). Noury On 24 oct. 2010, at 11:51, laurent laffont wrote: > Hi, > > I want to record a screencast on basic networking and also explore this idea: http://forum.world.st/Community-in-the-IDE-tp2543540p2543540.html > > Do you have some links on documentation and/or good code to look at ? I'm searching for best practices / modelizations to write a chat server and client. > > Actually I've read and tried those: > http://book.pharo-project.org/book/networking/Socket > http://wiki.squeak.org/squeak/325 > > > Cheers, > > Laurent Laffont > > Pharo Smalltalk Screencasts: http://www.pharocasts.com/ > Blog: http://magaloma.blogspot.com/ > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 25, 2010

Re: [Pharo-project] [ANN] ImageMap PharoKernel-12196

by Lukas Renggli

Ouch too bad, the image needs to get smaller to have a visual look at it :-) On 22 October 2010 09:34, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > Hi Lukas, > > I tried to generate the graph for the PharoKernel on a better machine, > it consumed 6.2 GB of RAM, now it is running for 20 hours and it is > still not complete :-) > > -- Pavel > > On Wed, Oct 20, 2010 at 10:53 PM, Pavel Krivanek > <pavel.krivanek(a)gmail.com> wrote: >> Hi Lukas, >> >> you can try it: >> http://www.grandjihlava.cz/tmp/ImageGraph/ImageMap.st >> >> the command that generates the graph is >> dot -Tsvg imageGraph.dot > imageGraph.svg >> >> Unfortunatelly my laptop has only 2GB so I have not enough RAM to >> generate the graph for whole PharoKernel image ;-) The input file for >> GraphViz has 67MB ;-) >> >> This is the resultant graph for the first 500 objects >> http://www.grandjihlava.cz/tmp/ImageGraph/imageGraph.svg >> >> Cheers, >> -- Pavel >> >> On Tue, Oct 19, 2010 at 9:15 PM, Lukas Renggli <renggli(a)gmail.com> wrote: >>> Wow, this is really cool. >>> >>> Did you also try to visualize the object-graph using GraphViz? >>> >>> Lukas >>> >>> On 19 October 2010 20:49, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: >>>> Hi, >>>> >>>> I generated the PharoKernel ImageMap (hypertext representation of the >>>> image content). You can see it here: >>>> >>>> http://goo.gl/nY2o >>>> >>>> The source code is here: http://goo.gl/J4T0 >>>> CSS style is here: http://goo.gl/Pxw2 >>>> >>>> Use it carefully, for 2,2MB image it generates 77,6MB of HTML files :-) >>>> >>>> Cheers, >>>> -- Pavel >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>> >>> >>> >>> -- >>> Lukas Renggli >>> www.lukas-renggli.ch >>> >>> _______________________________________________ >>> 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 > -- Lukas Renggli www.lukas-renggli.ch

Oct. 25, 2010

Re: [Pharo-project] Smells looking at collections

by StÃ©phane Ducasse

Eliot the main interest is in not having the responsibility to initialize the state of traits by the composite. Now since we know that doing for real is difficult this is why with did Nile: we build from scratch a real lib using traits and we wanted to see if we wanted state. The results were not really positive. Now also what people may not know is that the implementation of traits we have was a complete rewrite of the one of nathanael because proto are good but are proto. We try to keep xp for the research. Now I would like to take the time to rethink traits and its implementation. Stef On Oct 25, 2010, at 4:07 AM, Eliot Miranda wrote: > Hi Levente, > > in my experience playing with the Dan and Alan Borning's multiple inheritance implementation getting things to work was one thing, reasonably straighforward, but getting tool support right (file-out format so that things filed back in correctly, etc) was another, an dth ebulk of the work. Looking at your proposal below I see no problem getting it to work but see lots of problems integrating it, e.g. with Monticello, etc. Traits is already integrated with Monticello, supported with tests, etc. As such it is a much less risky or effortful proposition than a new scheme. So with that in mind are there important functional benefits of your scheme's direct state access as compared with traits that use accessors to access state that each user of a trait must implement? i.e. what are the key benefits you see in direct inst var access? > > best > Eliot > > 2010/10/24 Levente Uzonyi <leves(a)elte.hu> > On Sun, 24 Oct 2010, StÃ©phane Ducasse wrote: > > > > 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. > > Okay, here is an example of my class composition idea. It works like Traits, but it supports state and there's no distinction between a trait and a class. Let's say I have a class named BidirectionalLink which can be used as a link in a linked list (with a head element). This will be used as a stateful trait. It's definition is like this: > > Object subclass: #BidirectionalLink > instanceVariableNames: 'next previous' > classVariableNames: '' > poolDictionaries: '' > category: 'ClassCompositionExample' > > It has a few methods: > > BidirectionalLink >> next > ^next > > BidirectionalLink >> next: aBidirectionalLink > next := aBidirectionalLink > > BidirectionalLink >> previous > ^previous > > BidirectionalLink >> previous: aBidirectionalLink > previous := aBidirectionalLink > > BidirectionalLink >> unlink > previous next: next. > next previous: previous > > BidirectionalLink >> linkAfter: aBidirectionalLink > previous := aBidirectionalLink. > next := aBidirectionalLink next. > aBidirectionalLink next: self. > next previous: self > > I have an existing class, let's call it ODatedEntry :). It has the following definition: > > ECSelectorEntry subclass: #ODatedEntry > instanceVariableNames: 'date' > classVariableNames: '' > poolDictionaries: '' > category: 'Ocompletion' > > As you can see, it inherits some state and behavior from ECSelectorEntry. My goal is to use the instances of this class in a linked list. So these objects should implement the same protocol with the same behavior as BidirectionalLink. I can't make it a subclass of BidirectionalLink, because I also need the behavior and state from ECSelectorEntry and we don't have multiple inheritance. So I'll compose the two classes. First I add the necessary instance variables to the class. Let's call them nextEntry and previousEntry: > > ECSelectorEntry subclass: #ODatedEntry > instanceVariableNames: 'date nextEntry previousEntry' > classVariableNames: '' > poolDictionaries: '' > category: 'Ocompletion' > > Then do the composition: > > ECSelectorEntry subclass: #ODatedEntry > uses: BidirectionalLink > instanceVariableNames: 'date nextEntry previousEntry' > classVariableNames: '' > poolDictionaries: '' > category: 'Ocompletion' > > Now this doesn't work, because ODatedEntry doesn't have instance variables named next and previous, but the methods of BidirectionalLink would like to use them. Of course I could have used those names in the previous step and (with a working implementation) this would just work out of the box. But the example is about the instance variable mapping. Let's say ~ is the composition operator which defines variable mapping for a class or a method. Then I can write the following: > > ECSelectorEntry subclass: #ODatedEntry > uses: BidirectionalLink ~ { #nextEntry -> #next. #previousEntry -> #previous } > instanceVariableNames: 'date nextEntry previousEntry' > classVariableNames: '' > poolDictionaries: '' > category: 'Ocompletion' > > This means: take all methods from BidirectionalLink, but replace the variable named next with nextEntry and previous with previousEntry. > So now ODatedEntry understands #next, #next:, #previous, #unlink, etc. > > This is the basic concept. There are some open questions, like: > - what happens when a composed method (or a method sent by a composed method, etc) has a super send? > - will the class also get the methods of the superclasses of the "trait"? > - how does it work on the class side? > - what about class variables? > - what if I don't want to use all methods, just a few? > > > > 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. > > My idea is that traits don't add instance variables. The user of the trait maps the trait's variables to their own by name. So if a trait gets > a new variable, then only the trait and subclasses have to be recompiled. The recompilation is postponed until a method of the trait which uses the new instance variable is added to a class. > > > 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 > > See above. > > > Levente > > > - 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 > > > _______________________________________________ > 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

Oct. 25, 2010

Re: [Pharo-project] export information to PDF

by StÃ©phane Ducasse

if it works yes and if it does not pollutes everything. So Esteban if you can package this behavior into a package we are interested. Probably look in 3.9 but I'm not sure that it was working there. On Oct 25, 2010, at 12:42 AM, Esteban Lorenzano wrote: > Some time ago, there was a functionality to export a morph as a .ps file, I don't remember in which pharo version that function was lost...maybe it is in a package, and can be loaded, I really don't know, but it should be nice :) > > Cheers, > Esteban > > On 2010-10-24 09:58:09 -0300, name name <onor16(a)gmail.com> said: > >> Hello, >> Could you tell me how can I export (or where I can found ) information that >> I can get with a getter into a .pdf file? >> Thanks >> > ass=3D"text-cell">=A0=A0=A0=A0 Hello, Could you tell me how can I ex= >> port (or where I can found )=20 >> =A0information that I can get with a getter into a .pdf file? >> Thanks >> =09 >> =09 >> =09 >> >> _______________________________________________ >> 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. 25, 2010

Re: [Pharo-project] Smells looking at collections

by Igor Stasenko

On 24 October 2010 23:45, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>> >>>> >>>>> 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. Why? I think it having many benefits comparing to 'compiled once' idea. We're slowly moving towards multiple environemnts, right? So, what if i may want to use same trait in two different environments, and one of its methods using #Foo variable, which depending on environment could be one or another class, or be a classvar with different value. It could be quite powerful thing for testing purposes. Suppose you wanna test something against new implementation of old class. Then you don't need to waste a time and replace Foo -> Bar, you just need to put it in use in different environment, where Foo implemented differently. There are other things.. Suppose my class using different compiler (#compilerClass). It means that any methods in class should be compiled using that compiler. And trait methods should obey the same rule without exception. > 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. > Yes, same as if you adding an extra ivar to existing class, which having subclasses. Nothing really scary. >> 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 > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

Oct. 25, 2010

Re: [Pharo-project] Smells looking at collections

by Eliot Miranda

Hi Levente, in my experience playing with the Dan and Alan Borning's multiple inheritance implementation getting things to work was one thing, reasonably straighforward, but getting tool support right (file-out format so that things filed back in correctly, etc) was another, an dth ebulk of the work. Looking at your proposal below I see no problem getting it to work but see lots of problems integrating it, e.g. with Monticello, etc. Traits is already integrated with Monticello, supported with tests, etc. As such it is a much less risky or effortful proposition than a new scheme. So with that in mind are there important functional benefits of your scheme's direct state access as compared with traits that use accessors to access state that each user of a trait must implement? i.e. what are the key benefits you see in direct inst var access? best Eliot 2010/10/24 Levente Uzonyi <leves(a)elte.hu> > On Sun, 24 Oct 2010, StÃ©phane Ducasse wrote: > > >>>> >>>>> 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. >> > > Okay, here is an example of my class composition idea. It works like > Traits, but it supports state and there's no distinction between a trait and > a class. Let's say I have a class named BidirectionalLink which can be used > as a link in a linked list (with a head element). This will be used as a > stateful trait. It's definition is like this: > > Object subclass: #BidirectionalLink > instanceVariableNames: 'next previous' > classVariableNames: '' > poolDictionaries: '' > category: 'ClassCompositionExample' > > It has a few methods: > > BidirectionalLink >> next > ^next > > BidirectionalLink >> next: aBidirectionalLink > next := aBidirectionalLink > > BidirectionalLink >> previous > ^previous > > BidirectionalLink >> previous: aBidirectionalLink > previous := aBidirectionalLink > > BidirectionalLink >> unlink > previous next: next. > next previous: previous > > BidirectionalLink >> linkAfter: aBidirectionalLink > previous := aBidirectionalLink. > next := aBidirectionalLink next. > aBidirectionalLink next: self. > next previous: self > > I have an existing class, let's call it ODatedEntry :). It has the > following definition: > > ECSelectorEntry subclass: #ODatedEntry > instanceVariableNames: 'date' > classVariableNames: '' > poolDictionaries: '' > category: 'Ocompletion' > > As you can see, it inherits some state and behavior from ECSelectorEntry. > My goal is to use the instances of this class in a linked list. So these > objects should implement the same protocol with the same behavior as > BidirectionalLink. I can't make it a subclass of BidirectionalLink, because > I also need the behavior and state from ECSelectorEntry and we don't have > multiple inheritance. So I'll compose the two classes. First I add the > necessary instance variables to the class. Let's call them nextEntry and > previousEntry: > > ECSelectorEntry subclass: #ODatedEntry > instanceVariableNames: 'date nextEntry previousEntry' > classVariableNames: '' > poolDictionaries: '' > category: 'Ocompletion' > > Then do the composition: > > ECSelectorEntry subclass: #ODatedEntry > uses: BidirectionalLink > instanceVariableNames: 'date nextEntry previousEntry' > classVariableNames: '' > poolDictionaries: '' > category: 'Ocompletion' > > Now this doesn't work, because ODatedEntry doesn't have instance variables > named next and previous, but the methods of BidirectionalLink would like to > use them. Of course I could have used those names in the previous step and > (with a working implementation) this would just work out of the box. But the > example is about the instance variable mapping. Let's say ~ is the > composition operator which defines variable mapping for a class or a method. > Then I can write the following: > > ECSelectorEntry subclass: #ODatedEntry > uses: BidirectionalLink ~ { #nextEntry -> #next. #previousEntry -> > #previous } > instanceVariableNames: 'date nextEntry previousEntry' > classVariableNames: '' > poolDictionaries: '' > category: 'Ocompletion' > > This means: take all methods from BidirectionalLink, but replace the > variable named next with nextEntry and previous with previousEntry. > So now ODatedEntry understands #next, #next:, #previous, #unlink, etc. > > This is the basic concept. There are some open questions, like: > - what happens when a composed method (or a method sent by a composed > method, etc) has a super send? > - will the class also get the methods of the superclasses of the "trait"? > - how does it work on the class side? > - what about class variables? > - what if I don't want to use all methods, just a few? > > >> >> 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. >> > > My idea is that traits don't add instance variables. The user of the trait > maps the trait's variables to their own by name. So if a trait gets > a new variable, then only the trait and subclasses have to be recompiled. > The recompilation is postponed until a method of the trait which uses the > new instance variable is added to a class. > > >> 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 >> > > See above. > > > Levente > > >> - 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 >>> >> >> >> _______________________________________________ >> 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. 25, 2010

Re: [Pharo-project] call for scripting idea

by Tudor Girba

More precisely, the example that I had in mind would be: http://github.com/renggli/builder/blob/master/build.sh Doru On 19 Oct 2010, at 09:45, Lukas Renggli wrote: > On 19 October 2010 09:10, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> why not :) >> could you send them to the list so that we can see them? > > http://github.com/renggli/builder > > Lukas > > -- > Lukas Renggli > www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- www.tudorgirba.com "Being happy is a matter of choice."

Oct. 25, 2010

Re: [Pharo-project] Smells looking at collections

by Levente Uzonyi

On Sun, 24 Oct 2010, StÃ©phane Ducasse wrote: >>> >>>> >>>>> 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. Okay, here is an example of my class composition idea. It works like Traits, but it supports state and there's no distinction between a trait and a class. Let's say I have a class named BidirectionalLink which can be used as a link in a linked list (with a head element). This will be used as a stateful trait. It's definition is like this: Object subclass: #BidirectionalLink instanceVariableNames: 'next previous' classVariableNames: '' poolDictionaries: '' category: 'ClassCompositionExample' It has a few methods: BidirectionalLink >> next ^next BidirectionalLink >> next: aBidirectionalLink next := aBidirectionalLink BidirectionalLink >> previous ^previous BidirectionalLink >> previous: aBidirectionalLink previous := aBidirectionalLink BidirectionalLink >> unlink previous next: next. next previous: previous BidirectionalLink >> linkAfter: aBidirectionalLink previous := aBidirectionalLink. next := aBidirectionalLink next. aBidirectionalLink next: self. next previous: self I have an existing class, let's call it ODatedEntry :). It has the following definition: ECSelectorEntry subclass: #ODatedEntry instanceVariableNames: 'date' classVariableNames: '' poolDictionaries: '' category: 'Ocompletion' As you can see, it inherits some state and behavior from ECSelectorEntry. My goal is to use the instances of this class in a linked list. So these objects should implement the same protocol with the same behavior as BidirectionalLink. I can't make it a subclass of BidirectionalLink, because I also need the behavior and state from ECSelectorEntry and we don't have multiple inheritance. So I'll compose the two classes. First I add the necessary instance variables to the class. Let's call them nextEntry and previousEntry: ECSelectorEntry subclass: #ODatedEntry instanceVariableNames: 'date nextEntry previousEntry' classVariableNames: '' poolDictionaries: '' category: 'Ocompletion' Then do the composition: ECSelectorEntry subclass: #ODatedEntry uses: BidirectionalLink instanceVariableNames: 'date nextEntry previousEntry' classVariableNames: '' poolDictionaries: '' category: 'Ocompletion' Now this doesn't work, because ODatedEntry doesn't have instance variables named next and previous, but the methods of BidirectionalLink would like to use them. Of course I could have used those names in the previous step and (with a working implementation) this would just work out of the box. But the example is about the instance variable mapping. Let's say ~ is the composition operator which defines variable mapping for a class or a method. Then I can write the following: ECSelectorEntry subclass: #ODatedEntry uses: BidirectionalLink ~ { #nextEntry -> #next. #previousEntry -> #previous } instanceVariableNames: 'date nextEntry previousEntry' classVariableNames: '' poolDictionaries: '' category: 'Ocompletion' This means: take all methods from BidirectionalLink, but replace the variable named next with nextEntry and previous with previousEntry. So now ODatedEntry understands #next, #next:, #previous, #unlink, etc. This is the basic concept. There are some open questions, like: - what happens when a composed method (or a method sent by a composed method, etc) has a super send? - will the class also get the methods of the superclasses of the "trait"? - how does it work on the class side? - what about class variables? - what if I don't want to use all methods, just a few? > > >>> 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. My idea is that traits don't add instance variables. The user of the trait maps the trait's variables to their own by name. So if a trait gets a new variable, then only the trait and subclasses have to be recompiled. The recompilation is postponed until a method of the trait which uses the new instance variable is added to a class. > >> 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 See above. Levente > >>> - 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 > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 25, 2010

Re: [Pharo-project] export information to PDF

by Esteban Lorenzano

Some time ago, there was a functionality to export a morph as a .ps file, I don't remember in which pharo version that function was lost...maybe it is in a package, and can be loaded, I really don't know, but it should be nice :) Cheers, Esteban On 2010-10-24 09:58:09 -0300, name name <onor16(a)gmail.com> said: > > > Hello, > > Could you tell me how can I export (or where I can found ) information that > I can get with a getter into a .pdf file? > > Thanks > > > ass=3D"text-cell">=A0=A0=A0=A0 Hello, Could you tell me how can I ex= > port (or where I can found )=20 > =A0information that I can get with a getter into a .pdf file? > Thanks > =09 > =09 > =09 > > > > > > _______________________________________________ > 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] Proposal: adding 261 named colors

by Schwab,Wilhelm K

There should be nothing to see - the code should raise and exception if the color is not recognized, and yes, I would probably halt not the system but the view trying to open. If you really want to default it, then there should be a colorNamed:ifNone: variant to allow the error condition to be trapped. ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Johan Fabry [jfabry(a)dcc.uchile.cl] Sent: Sunday, October 24, 2010 1:09 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Proposal: adding 261 named colors If you instantiate a color but dont see it, does it matter that the color is not what you wanted? It's like considering the classical 'tree falls in the forest' question. Or if you prefer a more implementation-based view: if a morph cannot be drawn, do you halt the system? Right now it is not the case, a rectangle with a cross is drawn. In any case, I am open to suggestions for improvement! On 23 Oct 2010, at 18:46, Schwab,Wilhelm K wrote: > I don't like the idea of instantiating red if the name is not recognized. Since you don't have selectors (900+ might be a bit much), the compiler/Shout won't catch mistakes, and it will be an ongoing source of silent failures. > > > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Johan Fabry [jfabry(a)dcc.uchile.cl] > Sent: Saturday, October 23, 2010 5:29 PM > To: Pharo Development > Subject: [Pharo-project] Proposal: adding 261 named colors > > Hi all, > > in the work of AspectMaps I was a bit let down by the named colors Pharo provides (Color red et cetera). Now I am happy to say that thanks to the XKCD color survey I was able to improve on this. I can now use 261 named colors thanks to a XKCDColor class, and I'd like to share the code, ideally to be included into Pharo. The code is available in bugreport http://code.google.com/p/pharo/issues/detail?id=3148 > > Here is the class comment fo XKCDColor: > > ---snip--- > A color named according to the XKCD color survey, as published in http://blog.xkcd.com/2010/05/03/color-survey-results/ ("Over five million colors were named across 222,500 user sessions.") > > Of the full table of 954 colors that is published only those were selected that did not have a space in their name, ignoring e.g. electric lime, nasty green, macaroni and cheese, pinkish tan, but also light light blue, strong blue. This results in a table of 261 named colors, but with duplicates such as ochre and ocre. These were left in since as they are common misspellings it is more convenient for the user. > > To instantiate: XCDColor named: aString where aString is one of the 261 named colors. If the name is not known, the color red is instantiated. Instances of XKCDColor know their XKCD color name, returned by the name accessor. > > Thanks to Randall Monroe of http://xkcd.com for providing the data. > ---snip--- > > And here is a picture of all the colors (Generated with Mondrian :-) ) > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Johan Fabry jfabry(a)dcc.uchile.cl - http://dcc.uchile.cl/~jfabry 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

Oct. 24, 2010

Re: [Pharo-project] After loading a package...all changes with "revision changed"

by Mariano Martinez Peck

OK....found the problem. I think these are method recategorization. They say "revision changed" but since you don't see the category in the MC merge/changes browser, then you don't undrerstand why. In my case, the category changes were due to overrides. There is a package GlorpPostLoad which seems to have several overrides in Glorp package.... cheers mariano On Mon, Oct 4, 2010 at 12:57 PM, Gary Chambers <Gary.Chambers(a)pinesoft.co.uk > wrote: > Should be possibleâ¦ Iâll try to get some time to have a goâ¦ > > > > *From:* Mariano Martinez Peck [mailto:marianopeck@gmail.com] > *Sent:* 27 September 2010 9:51 PM > *To:* Pharo-project(a)lists.gforge.inria.fr > *Subject:* Re: [Pharo-project] After loading a package...all changes with > "revision changed" > > > > Gary, BWT, it would be nice to have a way to filter (hde) all those methods > as "revision changed" when seeing the changes. > After that, I am able to see only the really changed methods :) > > On Mon, Sep 27, 2010 at 10:42 PM, Mariano Martinez Peck < > marianopeck(a)gmail.com> wrote: > > > > 2010/9/26 Javier PimÃ¡s <elpochodelagente(a)gmail.com> > > > > We had a similar problem in squeaknos package, but just for some kind of > classes. It was caused by having an initialize class method in classes > derived from ExternalStructure, maybe it's because of the same reason? look > there, you may get some answers. > > > Thanks. It is good to know I am not the only one. This bug is REAAAAALY > annoying since you cannot see your changes. > > I've checked and I have no #initialize at class level :( > > The only thing I found is class side #new implementd something like: > > new > > ^super new initialize. > > can this be the problem? > > where could I put a halt to see the problem ? > > thanks in advance > > mariano > > > > regards, > javier. > > 2010/9/26 Norbert Hartl <norbert(a)hartl.name> > > > > FYI I encountered the same problem in gemstone. The only thing I know is > that all loaded packages were created in pharo that showed this behaviour. > It didn't show up in a reproducable manner and some packages were clean > again after a few package updates. And for some month now I didn't see it. > > > > Norbert > > > Am 25.09.2010 um 21:12 schrieb Mariano Martinez Peck < > marianopeck(a)gmail.com>: > > > > On Sat, Sep 25, 2010 at 9:02 PM, StÃ©phane Ducasse < > stephane.ducasse(a)inria.fr> wrote: > > > On Sep 25, 2010, at 8:25 PM, Mariano Martinez Peck wrote: > > > Hi. I am having a probem with Glorp and I really have no idea what can > be. The problem is that I load the package Glorp and just after loading, I > do a "changes" in the MC Browser and I see a lot of classes with a lot of > changes and all of them like "revison changed". This is annoying since it > doesn't let me easily see what I have really changed. > > > > To reproduce: > > > > - Load the package "Glorp" from http://www.squeaksource.com/SqueakDBX > > - Open a MC Browser, select Glorp package and press the "Changes" button > agains the ss repo. And you will see :) > > May be the image used to save the package got a problem and changed the > timestamp of the methods. > So when you merge you get changed methods. > > > I've just tried commiting and load them in a clean image...same problem. > > And if it were what you say...is there a solution? > > thanks > > mariano > > > > > > > Any help is really appreaciated. > > > > Thanks > > > > Mariano > > > _______________________________________________ > > 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 > > > > > -- > Javier PimÃ¡s > Ciudad de Buenos Aires > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > Click here <https://www.mailcontrol.com/sr/wQw0zmjPoHdJTZGyOCrrhg==> to > report this email as spam. > > > <http://www.pinesoft.co.uk/> > > > > Ã¼ *Consider your responsibility to the environment - think before you > print!* > > > ******************************************************************************************************************************************* > > This email is from Pinesoft Limited. Its contents are confidential to the > intended recipient(s) at the email address(es) to which it has been > addressed. It may not be disclosed to or used by anyone other than the > addressee(s), nor may it be copied in anyway. If received in error, please > contact the sender, then delete it from your system. Although this email and > attachments are believed to be free of virus, or any other defect which > might affect any computer or IT system into which they are received and > opened, it is the responsibility of the recipient to ensure that they are > virus free and no responsibility is accepted by Pinesoft for any loss or > damage arising in any way from receipt or use thereof. > > > ******************************************************************************************************************************************* > > > Pinesoft Limited are registered in England, Registered number: 2914825. > Registered office: 266-268 High Street, Waltham Cross, Herts, EN8 7EA > > >

Oct. 24, 2010

Re: [Pharo-project] How to change keyboard bindings

by Mariano Martinez Peck

Maybe this helps http://forum.world.st/Keyboard-Shortcuts-Keymapping-now-loads-in-Pharo-core… On Mon, Oct 18, 2010 at 9:02 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > this is an area where we should improve. Now you can hack the table in > paragraphEditor and get an impact on all the texteditor. > > Stef > > On Oct 18, 2010, at 8:40 PM, Bart Veenstra wrote: > > > HI list, > > > > Using VW and VAST a lot, I got used to the key bindings. > > For instance, I would like to use control-q for bringing up the > > inspector instead of alt-i. Could someone point me in the right > > direction where I can change the bindings? Also, It is often unclear > > when I should use Control or Alt. For instance: > > > > In the System Browser, I can use Alt-X to remove a method, and > > Control-B to browse the class, but both are shown between the > > parenthesis. > > > > Regards, > > > > Bart > > > > _______________________________________________ > > 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] What happened to demo mode?

by Mariano Martinez Peck

On Sun, Oct 24, 2010 at 6:54 PM, Alain Plantec <alain.plantec(a)free.fr>wrote: > Le 24/10/2010 18:30, Serge Stinckwich a Ã©crit : > >> >> >> Le 24 oct. 2010 Ã 16:23, laurent laffont <laurent.laffont(a)gmail.com<mailto: >> laurent.laffont(a)gmail.com>> a Ã©crit : >> >> >> Added: http://book.pharo-project.org/book/CustomizingPharo/ >>> >> >> Thank you Laurent, but i guess there is still a problem with demo mode >> under Mac os x (the font used in browser code pane is not correct). >> > yes ! unfortunately > see Issue 2986. <http://code.google.com/p/pharo/issues/detail?id=2986> > Yes, we should take a decision about this. Maybe Alain is right, remove accuny from core, and add also demo fonts for core? Or only the normal ones for core and then add in dev the rest? As said, I am ok to be in Core if they are removed in #cleanUpForProduction. > Alain > > >> -- Serge Stinckwich >> >> >> >> _______________________________________________ >> 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] Proposal: adding 261 named colors

by StÃ©phane Ducasse

I think that this is good to clean it a bit anyway. Did you have a look at the other package too? On Oct 24, 2010, at 7:34 PM, Johan Fabry wrote: > > Yes there are some fun names in there: ice, yelowish, midnight, barney. Also some very 'human-excreta-related' ones: puke, vomit, poo, booger, ... But I chose not to pass a watch-out-for-the-children filter. (What would I do with Barney for example ? :-P ) > > On 24 Oct 2010, at 03:46, StÃ©phane Ducasse wrote: > >> ok I read the code :) >> >> I like 'swamp' >> >> Stef >> >> On Oct 23, 2010, at 11:30 PM, Johan Fabry wrote: >> >>> Hi all, >>> >>> in the work of AspectMaps I was a bit let down by the named colors Pharo provides (Color red et cetera). Now I am happy to say that thanks to the XKCD color survey I was able to improve on this. I can now use 261 named colors thanks to a XKCDColor class, and I'd like to share the code, ideally to be included into Pharo. The code is available in bugreport http://code.google.com/p/pharo/issues/detail?id=3148 >>> >>> Here is the class comment fo XKCDColor: >>> >>> ---snip--- >>> A color named according to the XKCD color survey, as published in http://blog.xkcd.com/2010/05/03/color-survey-results/ ("Over five million colors were named across 222,500 user sessions.") >>> >>> Of the full table of 954 colors that is published only those were selected that did not have a space in their name, ignoring e.g. electric lime, nasty green, macaroni and cheese, pinkish tan, but also light light blue, strong blue. This results in a table of 261 named colors, but with duplicates such as ochre and ocre. These were left in since as they are common misspellings it is more convenient for the user. >>> >>> To instantiate: XCDColor named: aString where aString is one of the 261 named colors. If the name is not known, the color red is instantiated. Instances of XKCDColor know their XKCD color name, returned by the name accessor. >>> >>> Thanks to Randall Monroe of http://xkcd.com for providing the data. >>> ---snip--- >>> >>> And here is a picture of all the colors (Generated with Mondrian :-) ) >>> >>> <Colors.png> >>> >>> -- >>> Johan Fabry >>> jfabry(a)dcc.uchile.cl - http://dcc.uchile.cl/~jfabry >>> 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 > > -- > Johan Fabry > jfabry(a)dcc.uchile.cl - http://dcc.uchile.cl/~jfabry > 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

Oct. 24, 2010

Re: [Pharo-project] Proposal: adding 261 named colors

by StÃ©phane Ducasse

On Oct 24, 2010, at 7:25 PM, Johan Fabry wrote: > > Yes if it doesn't make it in Pharo, it would be great that it gets in Moose. > > Stef, you closed the bug, does this mean it will be integrated ? I did not closed it I marked it as fixed = readyForIntegration Now this is not clear that we should add it or just keep it as a pharo package. stef > > On 24 Oct 2010, at 04:12, Tudor Girba wrote: > >> Hi Johan, >> >> I would definitely be interested in getting this as an external library around Mondrian and Moose. >> >> Cheers, >> Doru >> >> >> On 24 Oct 2010, at 07:09, Johan Fabry wrote: >> >>> If you instantiate a color but dont see it, does it matter that the color is not what you wanted? It's like considering the classical 'tree falls in the forest' question. >>> >>> Or if you prefer a more implementation-based view: if a morph cannot be drawn, do you halt the system? Right now it is not the case, a rectangle with a cross is drawn. >>> >>> In any case, I am open to suggestions for improvement! >> > > -- > Johan Fabry > jfabry(a)dcc.uchile.cl - http://dcc.uchile.cl/~jfabry > 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

Oct. 24, 2010