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

Re: [Pharo-project] Object>>at:modify:???
by StÃ©phane Ducasse Oct. 25, 2010

Oct. 25, 2010

Ok we can deprecate it. On Oct 22, 2010, at 11:04 PM, Hernan Wilkinson wrote: > In a 1.1 image I have, the class HttpRequest is using that message... > > On Thu, Oct 21, 2010 at 4:08 PM, stephane ducasse <stephane.ducasse(a)free.fr> wrote: > I would like to deprecate the following method since nobody use it. > What do you think? > > Stef > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > -- > HernÃ¡n Wilkinson > Agile Software Development, Teaching & Coaching > Mobile: +54 - 911 - 4470 - 7207 > email: hernan.wilkinson(a)10Pines.com > site: http://www.10Pines.com > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

5 5

[Pharo-project] Fwd: [squeak-dev] bug in OBMetagraphBuilder>>#reference
by Mariano Martinez Peck Oct. 25, 2010

Oct. 25, 2010

lukas? ---------- Forwarded message ---------- From: Chris Muller <asqueaker(a)gmail.com> Date: Mon, Oct 25, 2010 at 6:16 PM Subject: [squeak-dev] bug in OBMetagraphBuilder>>#reference To: squeak dev <squeak-dev(a)lists.squeakfoundation.org> Hi, I just wanted to let the maintainers of OmniBrowser know, there is a bug with this method. The method reflects on its class and performs all that begin with #populate. However, it is not unusual to expect that someone's application might have a selector that also begins with the word 'populate'. And so those selectors would be performed as well. This is why, for cases like this, it is better for a tool, which is just a means, not an end, to be polite with the namespace; such as checking for 'obPopulate' perhaps rather than simply 'populate'. But that's just a mini-rant, not even the bug. The bug is, my 'populate' is not a unary message, so I get a failure on the perform, "incorrect number of arguments." I therefore always change the method to: OBMetagraphBuilder >> execute ((self class allSelectors select: [:ea | (ea beginsWith: 'populate') and: [ ea isUnary ]]) asSortedArray) do: [:selector | self perform: selector]. ^ self root Thank you, Chris

2 1

Re: [Pharo-project] what happened with Shout colors in Pharo 1.1?
by Simon Denier Oct. 25, 2010

Oct. 25, 2010

On 15 oct. 2010, at 17:31, Mariano Martinez Peck wrote: > They've changed a lot from 1.0. For example, self, super, etc, are not in "orange" or that color of 1.0. > Instances variables, are blue (instead of black), the same as parameters,etc... > > is there a way to recover the original colors? do we wanted this change or it is accidental ? I think the colors in 1.0 were inherited from the dev images build by Damien Cassou. In 1.1, the colors comes from the settings of Lukas, who maintains Shout? Am I wrong? I liked the colors in 1.0, but now I am accustomed to the current theme, which is very keen to the eye, except for two things that I change: - distinguish instance vars/class vars from other variables: I use a brownish color for that, as I want to see at once methods accessing the state of the object - distinguish class references: I use bold black as in the previous style, as I want to quickly catch hard dependencies in the code To customize colors, two solutions: 1) hack SHTextStylerST80>>defaultStyleTable 2) load latest Shout and use Settings (then you should be able to save/load your style), since there is now a Settings interface -- Simon

3 5

[Pharo-project] [update 1.2] #12215
by Marcus Denker Oct. 25, 2010

Oct. 25, 2010

[update 1.2] #12215 12215 ----- Issue 3158: Deprecate translation support protocol Issue 3157: Text entry dialog window badly compute minimumWidth Issue 3025: SystemVersionTest>>testDowngrade use a deprecated method Issue 3029: The Menus of the Source panes reverted to the old complex ones... Issue 3025: SystemVersionTest>>testDowngrade use a deprecated method -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

1 0

Re: [Pharo-project] what happened with Shout colors in Pharo 1.1?
by Simon Denier Oct. 25, 2010

Oct. 25, 2010

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

3 2

[Pharo-project] [update 1.2] #12214
by Marcus Denker Oct. 25, 2010

Oct. 25, 2010

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.

1 0

Re: [Pharo-project] Smells looking at collections
by StÃ©phane Ducasse Oct. 25, 2010

Oct. 25, 2010

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

4 4

Oct. 25, 2010

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

3 2

[Pharo-project] [ANN] ImageMap PharoKernel-12196
by Pavel Krivanek Oct. 25, 2010

Oct. 25, 2010

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

4 9

Oct. 25, 2010

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

1 0