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

Re: [Pharo-project] [BUG] Issue 945 still can be reproduced

by George Herolyants

2010/1/18 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > ok we will integrate it in the next batch Thank you!

Jan. 18, 2010

Re: [Pharo-project] PluggableTextMorph >> getText proposedmodification

by StÃ©phane Ducasse

thanks gary. On Jan 18, 2010, at 12:07 PM, Gary Chambers wrote: > Looks ok. Similar things have been done for a few other morphs (buttons I > think)... > > Regards, Gary > > ----- Original Message ----- > From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> > To: <Pharo-project(a)lists.gforge.inria.fr> > Sent: Monday, January 18, 2010 8:12 AM > Subject: Re: [Pharo-project] PluggableTextMorph >> getText > proposedmodification > > >> Gary ?? >> Alain?? >> do one of you have a feedback for this change. >> I would like to integrate it because it makes sense to me but I'm far from >> a UI expert >> >> Stef >> >> >> On Jan 12, 2010, at 6:14 AM, Ralph Boland wrote: >> >>> In my (Squeak) project I modified PluggableTextMorph >> getText to be >>> as follows: >>> >>> getText >>> "Retrieve the current model text" >>> >>> | newText | >>> getTextSelector isNil ifTrue: [^Text new]. >>> newText := (getTextSelector numArgs = 1) >>> ifTrue: [model perform: getTextSelector with: self] >>> ifFalse: [model perform: getTextSelector]. >>> newText ifNil: [^Text new]. >>> ^newText shallowCopy >>> >>> >>> The change allows the getTextSelector to pass an additional argument: >>> self. >>> I made this change because I wanted to know which PluggableTextMorph >>> was asking for text. >>> This is useful when one has large numbers of similar PluggableTextMorphs. >>> Note that the method PluggableTextMorph >> acceptTextInModel >>> already does this so I didn't need to modify it. >>> Thus I think my change makes PluggableTextMorph more consistent. >>> >>> Any chance of this change being made a part of the Pharo image? >>> >>> Frankly, I would prefer that all the GUI objects that have get/set >>> messages >>> had this capability. For CheckBoxes I earlier added the capability to >>> return >>> either self or some arguments (by subclassing this time). >>> I am happy with the result. >>> >>> Another way I could do this would be to create a holder for the >>> PluggableTextMorph >>> (or other gui object) that would respond to the getText and >>> acceptTextInModel messages >>> and would know which PluggableTextMorph is speaking to it (since there >>> would be only one). >>> The holder would replace the model in the PluggableTextMorph and have >>> a reference to the original model to which it could forward messages. >>> Again this would allow me to have a large number of similar >>> PluggableTextMorphs. >>> One could create a PluggableTextMorphHolder class for this or create >>> a single holder >>> class that could work with different Morph classes (only one at a timeof >>> course) >>> (by responding to messages from all of them). It would be nice of >>> course if these >>> GUI holders already existed in Squeak/Pharo so I didn't have to invent >>> them. >>> >>> Which approach do you think is better? >>> >>> Regards, >>> >>> Ralph Boland >>> >>> >>> -- >>> I've been middle class and I've been poor. >>> Middle class is better. >>> >>> _______________________________________________ >>> 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

Jan. 18, 2010

Re: [Pharo-project] [BUG] Issue 945 still can be reproduced

by StÃ©phane Ducasse

ok we will integrate it in the next batch On Jan 18, 2010, at 10:31 AM, George Herolyants wrote: > 2010/1/18 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >> >> Did you publish a slice? or is it in your cs? >> isNil is a way to often turn around the problem. > > I've published it as an st file on the tracker > (http://pharo.googlecode.com/issues/attachment?aid=1897434323002707823&name=…) > The workaround affects only one method. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Jan. 18, 2010

Re: [Pharo-project] strange local variable problem

by Levente Uzonyi

On Sun, 17 Jan 2010, csrabak(a)bol.com.br wrote: > Levente and Lukas, > > You both agree that this is not a bug, them we have to ascertain that 'average Smalltalker' will understand that using closures in Pharo changes the Smalltalk language definition. The semantics change in various ways. The trivial example that everyone knows is this: factorial := [ :n | n > 1 ifTrue: [ n * (factorial value: n - 1) ] ifFalse: [ 1 ] ]. factorial value: 10. Without closures you get an error, with closures you get the expected result. Another significant change is the existence of local variables in blocks. Without closures blocks don't have local variables, with closures they do: b := [ :p | | t | t ifNil: [ t := p ] ]. { b value: 1. b value: 2 } In a non-closure image you get #(1 1) as result, because t is not a block local variable even if it looks like one. In a closure image you get #(1 2) because t is a block local variable. Levente > > > > Em 17/01/2010 06:57, Lukas Renggli < renggli(a)gmail.com > escreveu: > > >> I believe this is a bug. > > That's the correct behavior. This is exactly how closures should > behave. The variable declaration is outside the block you store thus > one variable slot is shared among multiple block definitions inside. > See ClosureTests for more examples of that behavior. > > Lukas > > -- > Lukas Renggli > http://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 >

Jan. 18, 2010

Re: [Pharo-project] send a message code kata

by Alexandre Bergel

I tried PrStef, the idea is really cool! Alexandre On 17 Jan 2010, at 07:39, laurent laffont wrote: > Hi, > > for PrStef (that may be renamed ProfStef - thanks Lukas) there are > several ways to go to the next lesson: > > PrStef next. > > [PrStef next] value. > > 3=3 ifTrue: [PrStef next]. > > 1 to: 1 do: [:i | PrStef next]. > > I'm thinking about adding more of it: > > (Smalltalk at: #PrStef) next. > > PrStef perform: #next. > > > I'm sure you know other funny ways to send #next on PrStef :) > > > Laurent > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Jan. 18, 2010

Re: [Pharo-project] PluggableTextMorph >> getText proposedmodification

by Gary Chambers

Looks ok. Similar things have been done for a few other morphs (buttons I think)... Regards, Gary ----- Original Message ----- From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> To: <Pharo-project(a)lists.gforge.inria.fr> Sent: Monday, January 18, 2010 8:12 AM Subject: Re: [Pharo-project] PluggableTextMorph >> getText proposedmodification > Gary ?? > Alain?? > do one of you have a feedback for this change. > I would like to integrate it because it makes sense to me but I'm far from > a UI expert > > Stef > > > On Jan 12, 2010, at 6:14 AM, Ralph Boland wrote: > >> In my (Squeak) project I modified PluggableTextMorph >> getText to be >> as follows: >> >> getText >> "Retrieve the current model text" >> >> | newText | >> getTextSelector isNil ifTrue: [^Text new]. >> newText := (getTextSelector numArgs = 1) >> ifTrue: [model perform: getTextSelector with: self] >> ifFalse: [model perform: getTextSelector]. >> newText ifNil: [^Text new]. >> ^newText shallowCopy >> >> >> The change allows the getTextSelector to pass an additional argument: >> self. >> I made this change because I wanted to know which PluggableTextMorph >> was asking for text. >> This is useful when one has large numbers of similar PluggableTextMorphs. >> Note that the method PluggableTextMorph >> acceptTextInModel >> already does this so I didn't need to modify it. >> Thus I think my change makes PluggableTextMorph more consistent. >> >> Any chance of this change being made a part of the Pharo image? >> >> Frankly, I would prefer that all the GUI objects that have get/set >> messages >> had this capability. For CheckBoxes I earlier added the capability to >> return >> either self or some arguments (by subclassing this time). >> I am happy with the result. >> >> Another way I could do this would be to create a holder for the >> PluggableTextMorph >> (or other gui object) that would respond to the getText and >> acceptTextInModel messages >> and would know which PluggableTextMorph is speaking to it (since there >> would be only one). >> The holder would replace the model in the PluggableTextMorph and have >> a reference to the original model to which it could forward messages. >> Again this would allow me to have a large number of similar >> PluggableTextMorphs. >> One could create a PluggableTextMorphHolder class for this or create >> a single holder >> class that could work with different Morph classes (only one at a timeof >> course) >> (by responding to messages from all of them). It would be nice of >> course if these >> GUI holders already existed in Squeak/Pharo so I didn't have to invent >> them. >> >> Which approach do you think is better? >> >> Regards, >> >> Ralph Boland >> >> >> -- >> I've been middle class and I've been poor. >> Middle class is better. >> >> _______________________________________________ >> 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

Jan. 18, 2010

Re: [Pharo-project] allSubclassesDoGently: ?

by Mariano Martinez Peck

On Mon, Jan 18, 2010 at 11:01 AM, Marcus Denker <marcus.denker(a)inria.fr>wrote: > > On Jan 18, 2010, at 10:50 AM, Mariano Martinez Peck wrote: > > > Does someone know what "gently" means for ? > > > > it asks " S'il vous plait " to each class ? > > > > Seriously, I don't understand. What about rename it to something like: > > > > allSubclassesInMemoryDo ? > > > > what do you think ? > > > > Is this mechanism used? If not, we could even remove it... if we need it in > the future, > we can redo it if needed. (and than nicer...) > > I have been looked to that for a while. The method isInMemory seems to be used and wide spread it. I even like the idea behind that: some classes are not in memory. And it is cool that certain options don't want to search in ALL classes because if you do that you will bring all the classes again to memory. Now for example, I explain myself why the OB doesn't bring all classes to memory (classes that I had in a segment) when browsing a class. And I think it is because it uses somehow this message (maybe I am wrong...just a few minutes analying it). Now I would like to to fix the implementors and senders because when I do then, all classes are bring (even from segments). Thus, I can replace that code to use this method. What I really don't like at all is the name. What does gently has to do with inMemory ? I would really like to refector that if nobody explains why cheers Mariano > Marcus > > > -- > Marcus Denker -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Jan. 18, 2010

Re: [Pharo-project] allSubclassesDoGently: ?

by Marcus Denker

On Jan 18, 2010, at 10:50 AM, Mariano Martinez Peck wrote: > Does someone know what "gently" means for ? > > it asks " S'il vous plait " to each class ? > > Seriously, I don't understand. What about rename it to something like: > > allSubclassesInMemoryDo ? > > what do you think ? > Is this mechanism used? If not, we could even remove it... if we need it in the future, we can redo it if needed. (and than nicer...) Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

Jan. 18, 2010

Re: [Pharo-project] allSubclassesDoGently: ?

by Mariano Martinez Peck

Does someone know what "gently" means for ? it asks " S'il vous plait " to each class ? Seriously, I don't understand. What about rename it to something like: allSubclassesInMemoryDo ? what do you think ? On Sun, Jan 17, 2010 at 10:34 PM, StÃ©phane Ducasse < stephane.ducasse(a)inria.fr> wrote: > Yes of course. > Now since only a subpart of the system was using it it means that > imageSegment are most of the time reloaded. > So this is clearly a neat idea but not fully working. > > Stef > > On Jan 17, 2010, at 10:27 PM, John M McIntosh wrote: > > > I think you'll find it's documented in the class > > ImageSegmentRootStub > > > > It's all tied up in image segments, projects, etoys and the like, so in > the past an attempt to ensure > > that objects (classes) that were bundled up and stuffed into an image > segment aren't faulted back in > > unless you really mean it... > > > > users of this are interesting, see for example > > Dictionary>>at:ifPresentAndInMemory: > > > > On 2010-01-17, at 1:10 PM, StÃ©phane Ducasse wrote: > > > >> isInMemory > > > > -- > > > =========================================================================== > > John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: > squeaker68882 > > Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.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 >

Jan. 18, 2010

Re: [Pharo-project] [BUG] Issue 945 still can be reproduced

by George Herolyants

2010/1/18 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > > Did you publish a slice? or is it in your cs? > isNil is a way to often turn around the problem. I've published it as an st file on the tracker (http://pharo.googlecode.com/issues/attachment?aid=1897434323002707823&name=…) The workaround affects only one method.

Jan. 18, 2010