Collection
Locked
12
12
 
|
Igor wrote:
>What you talking about is an edge case in currently existing systems. >And its easy to prove: That's not convincing. I'd say you have cause and effect reversed. I'd not expect there to be large OrderedCollections as long as they don't behave well. Stephan _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Stephan Eggermont-3
On Sat, 13 Mar 2010, Stephan Eggermont wrote:
> Levente wrote: >> Trees are rarely useful in Smalltalk, so there's no >> default tree implementation. Note that trees consume >> a lot more memory (>=5x) than a single array. > Huh? You mean binary trees? Or Red-Black or so? The simplest unbalanced binary tree. > On current procesors they are not very useful, and > not usable at all for large data structures because > of the large overhead. But n-ary trees or two-level > stuctures are. If this is what you're looking for, just load the BTree package from squeaksource, or use SparseLargeTable. Levente > > Stephan > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Lukas Renggli
On 12.03.2010 14:05, Lukas Renggli wrote:
>> What would be cool for Seaside IMHO: >> - Multi Value Dictionaries, e.g. for request parameters >> - Some kind of thread safe map with atomic operations [2], e.g. for >> session store > > Why would that be cool? We already have a WAMultiValueDictionary for > request parameters. Also we have some ad-hock solutions for the thread > safe dictionaries. > > I would be more interested to see ... > > - if it would be beneficial for a collection to be able to swap out > its internal representation automatically depending on its load and > use ... > > - what we can do by externalizing the enumeration protocol (no, this > is not the same as streams or the iterable refactoring that was > recently proposed) ... > > - how to make collections more composable, e.g. make them thread safe, > make them read-only, make them ordered (sets and dictionaries), ... > [1] goes a little bit in that direction, even if only from the user point of view. [1] http://google-collections.googlecode.com/svn/trunk/javadoc/index.html?com/google/common/collect/MapMaker.html Cheers Philippe _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by stephane ducasse
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 [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
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 > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
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 <[hidden email]>: > 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 >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
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 <[hidden email]>: >> 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 >>> [hidden email] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
On 14 March 2010 15:24, Stéphane Ducasse <[hidden email]> 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 <[hidden email]>: >>> 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 >>>> [hidden email] >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> [hidden email] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
>> 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 _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
On 14 March 2010 17:12, Lukas Renggli <[hidden email]> 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 > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Lukas Renggli
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 _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
> 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. What about selecting the annotation and looking for its senders? The annotation doesn't change *anything* in that regard. Lukas -- Lukas Renggli http://www.lukas-renggli.ch _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
Hi,
I am student who work on the project. I was afforded a thesis which has roughly the same project. They had the idea to redo the hierarchy of collections. So why not do not do it? I am not an expert but, perhaps we can simplify it? This is the thesis in spanish: Reingenier-a_de_Jerarqu-as_Polim-rficas_Utilizando_Traits_-_Tesis_de_Licenciatura_-_Acciaresi_Cla.pdf. (you can find the presentation of the new hierarchy at page 3) If you agree with the reimplementation of the hierarchy of collections you can propose ideas! :) Tristan Bourgois |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |