- Pharo-dev - lists.pharo.org

[Pharo-project] [update 1.1] #11269

by StÃ©phane Ducasse

11269 ----- - Issue 2145: initialExtent of Workspace is not good stef showing to laurent :) Laurent showing to stef how to screencast (stay tuned :)). Stef

March 14, 2010

[Pharo-project] squeaksource is down....

by StÃ©phane Ducasse

March 14, 2010

Re: [Pharo-project] Collection

by Miguel Enrique CobÃ¡ Martinez

El dom, 14-03-2010 a las 16:12 +0100, Lukas Renggli escribiÃ³: > >> startupLevel > >> ^ 100 > >> > >> method > >> > > err, but you still need to have a method, where this pragma will be located :) > > Yes, in the startup method itself. > > The #startUp, #shutDown, #cleanUp protocol is quite strange. They are > all defined as empty methods in Behavior, but for #startUp and > #shutDown a registration is required. This registration is missing in > some cases. #cleanUp does not require a registration. In all cases > cleanUp just delegates to one or more other methods that do the actual > cleanup. > > What I propose is to use pragmas for that. This allows to drop all the > existing implementors of #startUp, #shutDown, and #cleanUp and give > them intention revealing names. Also I envision getting rid of these > ugly boolean flags that are never quite clear what they do and what is > the default. I imagine the following 6 annotations: > > <systemStartup: aPriorityInteger> > <systemResumption: aPriorityInteger> > > <systemShutdown: aPriorityInteger> > <systemSuspension: aPriorityInteger> > > <systemCleanup: aPriorityInteger> > <systemCleanupAgressive: aPriorityInteger> > > This means for example that HandMorph > class>>#clearCompositionWindowManager could simply look likes this: > > HandMorph class>>clearCompositionWindowManager > <systemStartup: 100> > > CompositionWindowManager := nil > > The #startUp and the code that registers and unregisters from the > startup list is no longer necessary. > But isn't this the rationale for using annotations on Java for example, where after a while you don't know what a given annotation does because the logic of working is somewhere else. I prefer a single standardized message, just like "new" and "initialize" that have well stated intentions and not convert smalltalk in a soup of annotations like Java currently is. My 2 cents. > Lukas > -- Miguel CobÃ¡ http://miguel.leugim.com.mx

March 14, 2010

[Pharo-project] Fix 2145 - InitialExtent

by laurent laffont

In Inbox. http://code.google.com/p/pharo/issues/detail?id=2145 Laurent Laffont

March 14, 2010

Re: [Pharo-project] Collection

by Igor Stasenko

On 14 March 2010 17:12, Lukas Renggli <renggli(a)gmail.com> wrote: >>> startupLevel >>> Â Â Â Â ^ 100 >>> >>> method >>> >> err, but you still need to have a method, where this pragma will be located :) > > Yes, in the startup method itself. > > The #startUp, #shutDown, #cleanUp protocol is quite strange. They are > all defined as empty methods in Behavior, but for #startUp and > #shutDown a registration is required. This registration is missing in > some cases. #cleanUp does not require a registration. In all cases > cleanUp just delegates to one or more other methods that do the actual > cleanup. > > What I propose is to use pragmas for that. This allows to drop all the > existing implementors of #startUp, #shutDown, and #cleanUp and give > them intention revealing names. Also I envision getting rid of these > ugly boolean flags that are never quite clear what they do and what is > the default. I imagine the following 6 annotations: > > Â <systemStartup: aPriorityInteger> > Â <systemResumption: aPriorityInteger> > > Â <systemShutdown: aPriorityInteger> > Â <systemSuspension: aPriorityInteger> > > Â <systemCleanup: aPriorityInteger> > Â <systemCleanupAgressive: aPriorityInteger> > > This means for example that HandMorph > class>>#clearCompositionWindowManager could simply look likes this: > > HandMorph class>>clearCompositionWindowManager > Â Â Â Â <systemStartup: 100> > > Â Â Â Â CompositionWindowManager := nil > > The #startUp and the code that registers and unregisters from the > startup list is no longer necessary. > Good point. > 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 > -- Best regards, Igor Stasenko AKA sig.

March 14, 2010

Re: [Pharo-project] Collection

by Lukas Renggli

>> startupLevel >> Â Â Â Â ^ 100 >> >> method >> > err, but you still need to have a method, where this pragma will be located :) Yes, in the startup method itself. The #startUp, #shutDown, #cleanUp protocol is quite strange. They are all defined as empty methods in Behavior, but for #startUp and #shutDown a registration is required. This registration is missing in some cases. #cleanUp does not require a registration. In all cases cleanUp just delegates to one or more other methods that do the actual cleanup. What I propose is to use pragmas for that. This allows to drop all the existing implementors of #startUp, #shutDown, and #cleanUp and give them intention revealing names. Also I envision getting rid of these ugly boolean flags that are never quite clear what they do and what is the default. I imagine the following 6 annotations: <systemStartup: aPriorityInteger> <systemResumption: aPriorityInteger> <systemShutdown: aPriorityInteger> <systemSuspension: aPriorityInteger> <systemCleanup: aPriorityInteger> <systemCleanupAgressive: aPriorityInteger> This means for example that HandMorph class>>#clearCompositionWindowManager could simply look likes this: HandMorph class>>clearCompositionWindowManager <systemStartup: 100> CompositionWindowManager := nil The #startUp and the code that registers and unregisters from the startup list is no longer necessary. Lukas -- Lukas Renggli http://www.lukas-renggli.ch

March 14, 2010

Re: [Pharo-project] Collection

by Igor Stasenko

On 14 March 2010 15:24, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Yes we talked about that. > What we would like to do is to use pragma to avoid to have a > > startupLevel > Â Â Â Â ^ 100 > > method > err, but you still need to have a method, where this pragma will be located :) > Stef > > On Mar 14, 2010, at 2:01 PM, Nicolas Cellier wrote: > >> Hi guys, >> You should have a look at Keith's work on image startup management. >> Some good ideas and MIT code could be good to >> experiment/polish/integrate in Pharo. >> Don't remember all the links (It's not always simple with Keith), but >> here are some starters: >> >> https://code.launchpad.net/~keithy/ >> https://code.launchpad.net/Cuis >> http://vimeo.com/9392990 >> >> Cheers >> >> Nicolas >> >> 2010/3/14 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >>> lol >>> >>> ;) >>> >>> we beat them :) >>> >>> >>> On Mar 14, 2010, at 12:55 PM, Philippe Marschall wrote: >>> >>>> On 11.03.2010 14:24, stephane ducasse wrote: >>>>> Hi guys >>>>> >>>>> tristan is a new student here and he would like to work on collection optimization and implementation. >>>>> I would like the get some ideas from you. >>>>> Â Â Â - are there some collections that would be cool to improve? >>>>> Â Â Â - are there some collections that would be cool to have and that we do not have yet? >>>> >>>> An ordered set, use case: start up and shut down list ;-) >>>> >>>> Cheers >>>> Philippe >>>> >>>> >>>> _______________________________________________ >>>> 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 > -- Best regards, Igor Stasenko AKA sig.

March 14, 2010

Re: [Pharo-project] [squeak-dev] Use of #asMorph

by Igor Stasenko

On 14 March 2010 15:38, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > I'm not convinced by your argumentation. > Because > Â Â Â Â #('a' 'b') collect: [:each | each asMorph] > would mean to me that you get StringMorph or some morph representation of the object. Yes, exactly like that. And i want to find a convenient approach how to achieve that. Means , that from one side we having a container (list, inspector, panel, window etc) and from other side, we having a model which is a collection of items. And i want to find a way, how an object, which you want to represent in a container, could pick a most appropriate form of its representation, BUT depending on a nature of container. > If this is what you want why not but I thought you talk about container containee relationship/ > I am not convinced myself that such way is feasible either. You tell :) Usually, in most cases, a container dictating how its items should be displayed and behave. And usually, a model knows more than a little about items it contains (for instance a class methods pane contains only methods, not arbitrary objects). > > > Stef > > > On Mar 14, 2010, at 2:05 PM, Igor Stasenko wrote: > >> On 14 March 2010 14:40, stephane ducasse <stephane.ducasse(a)gmail.com> wrote: >>> Igor >>> >>> I do not know (I'm dizzy after a couple of hours of bus) but >>> asMorph for me conveys the idea that we get a transformation of the receiver, while if this is just to >>> change the model of a morph why not model: >>> >> Changing a model gives nothing: >> >> morph := MyListMorph new. >> morph model: someModel. >> >> now, since my morph is a list, it assumes that someModel object >> implements a protocol, which allows to extract the >> items ( #size, #at: etc). >> The question is, what you would do, if you want to represent each item >> in a list as a morph, so instead of: >> >> strings := model items collect: [:each | each asString ]. >> >> you doing: >> >> subMorphs := model items collect: [:each | each asMorph ]. >> ... >> this gives you a freedom to pick any form how represent each item in a >> list, instead of bare strings. >> >> >>> >>> Stef >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> > > > _______________________________________________ > 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.

March 14, 2010

Re: [Pharo-project] [squeak-dev] Use of #asMorph

by StÃ©phane Ducasse

I'm not convinced by your argumentation. Because #('a' 'b') collect: [:each | each asMorph] would mean to me that you get StringMorph or some morph representation of the object. If this is what you want why not but I thought you talk about container containee relationship/ Stef On Mar 14, 2010, at 2:05 PM, Igor Stasenko wrote: > On 14 March 2010 14:40, stephane ducasse <stephane.ducasse(a)gmail.com> wrote: >> Igor >> >> I do not know (I'm dizzy after a couple of hours of bus) but >> asMorph for me conveys the idea that we get a transformation of the receiver, while if this is just to >> change the model of a morph why not model: >> > Changing a model gives nothing: > > morph := MyListMorph new. > morph model: someModel. > > now, since my morph is a list, it assumes that someModel object > implements a protocol, which allows to extract the > items ( #size, #at: etc). > The question is, what you would do, if you want to represent each item > in a list as a morph, so instead of: > > strings := model items collect: [:each | each asString ]. > > you doing: > > subMorphs := model items collect: [:each | each asMorph ]. > ... > this gives you a freedom to pick any form how represent each item in a > list, instead of bare strings. > > >> >> Stef >> > > > > -- > Best regards, > Igor Stasenko AKA sig. >

March 14, 2010

Re: [Pharo-project] Collection

by StÃ©phane Ducasse

Yes we talked about that. What we would like to do is to use pragma to avoid to have a startupLevel ^ 100 method Stef On Mar 14, 2010, at 2:01 PM, Nicolas Cellier wrote: > Hi guys, > You should have a look at Keith's work on image startup management. > Some good ideas and MIT code could be good to > experiment/polish/integrate in Pharo. > Don't remember all the links (It's not always simple with Keith), but > here are some starters: > > https://code.launchpad.net/~keithy/ > https://code.launchpad.net/Cuis > http://vimeo.com/9392990 > > Cheers > > Nicolas > > 2010/3/14 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >> lol >> >> ;) >> >> we beat them :) >> >> >> On Mar 14, 2010, at 12:55 PM, Philippe Marschall wrote: >> >>> On 11.03.2010 14:24, stephane ducasse wrote: >>>> Hi guys >>>> >>>> tristan is a new student here and he would like to work on collection optimization and implementation. >>>> I would like the get some ideas from you. >>>> - are there some collections that would be cool to improve? >>>> - are there some collections that would be cool to have and that we do not have yet? >>> >>> An ordered set, use case: start up and shut down list ;-) >>> >>> Cheers >>> Philippe >>> >>> >>> _______________________________________________ >>> 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

March 14, 2010