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

Re: [Pharo-project] Collection

by Levente Uzonyi

On Thu, 11 Mar 2010, 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? Here's the list I plan to improve is Squeak: - OrderedCollection: fix the growing behavior, adding n elements takes O(n^2) time in some cases - SortedCollection: just deprecate it (or replace it's crappy quicksort implementation if you really want to improve it. But I think it's useless) - TextStream: adding n characters with different attributes has O(n^2) runtime - StandardFileStream >> #upTo: (the recursive call + concatenation requires O(n^2) runtime and O(n^2) memory for large chunks of data) Levente > - are there some collections that would be cool to have and that we do not have yet? > If you have any idea related to optimizations let me know. > > Stef > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

March 13, 2010

Re: [Pharo-project] Collections

by Levente Uzonyi

On Sat, 13 Mar 2010, Stephan Eggermont wrote: > Stef wrote: >> - 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? > All collections with an Array as backing store do not perform > well in a large memory setting. That's not only a problem > in a 64-bit image. How bad do they perform? Do you have benchmarks? How can - an OrderedCollection - a Set - a Dictioanry - a Heap be implemented in a better way? Levente > > Stephan > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

March 12, 2010

Re: [Pharo-project] Collections

by Stephan Eggermont

Stef wrote: > - 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? All collections with an Array as backing store do not perform well in a large memory setting. That's not only a problem in a 64-bit image. Stephan

March 12, 2010

Re: [Pharo-project] Collection >> collectDistinct: ??

by Henrik Sperre Johansen

On 13.03.2010 00:14, csrabak(a)bol.com.br wrote: > Although the end result should be the same, I wonder if for a collection of items where there is a lot of duplicates the sequential nature of collecting and then converting to a Set wouldn't be less performant than Mariano's proposed method? > > -- > Cesar Rabak In my experience, yes, it would. The difference in practice is usually so small you wouldn't prefer one over the other unless it show up in a profile of a time-critical method though. Cheers, Henry Few distinct: [(1 to: 500000) collect: [:each | each odd] as: Set] timeToRun 1347 [|aSet | aSet := Set new. (1 to: 500000) do: [:each | aSet add: each odd] ] timeToRun 375 All distinct: [(1 to: 500000) collect: [:each | each +1] as: Set] timeToRun 1350 [|aSet | aSet := Set new: 500000. (1 to: 500000) do: [:each | aSet add: each +1] ] timeToRun 1740 > > > Em 10/03/2010 10:07, Nicolas Cellier< nicolas.cellier.aka.nice(a)gmail.com> escreveu: > self collect: aBlock as: Set > > 2010/3/10 Mariano Martinez Peck : >> Hi. I was needing something like the SQL select distinct, that doesn't take >> into account repeated objects. I didn't found anything useful in Collection, >> and thus, I have implemented this: >> >> Collection>> collectDistinct: aBlock >> >> >> collectDistinct: aBlock >> "Evaluate aBlock with each of the receiver's elements as the argument. >> Collect the resulting values into a Set, thus repeated objects will not >> be present. >> Answer the new collection." >> >> | newSet | >> newSet := self species new asSet. >> self do: [:each | newSet add: (aBlock value: each)]. >> ^ newSet >> >> >> Is there a better way ? Do you think it make sense to put this in Pharo ? >> >> Cheers >> >> 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

March 12, 2010

Re: [Pharo-project] Collection >> collectDistinct: ??

by csrabak＠bol.com.br

Although the end result should be the same, I wonder if for a collection of items where there is a lot of duplicates the sequential nature of collecting and then converting to a Set wouldn't be less performant than Mariano's proposed method? -- Cesar Rabak Em 10/03/2010 10:07, Nicolas Cellier < nicolas.cellier.aka.nice(a)gmail.com > escreveu: self collect: aBlock as: Set 2010/3/10 Mariano Martinez Peck : > Hi. I was needing something like the SQL select distinct, that doesn't take > into account repeated objects. I didn't found anything useful in Collection, > and thus, I have implemented this: > > Collection >> collectDistinct: aBlock > > > collectDistinct: aBlock > Â Â Â "Evaluate aBlock with each of the receiver's elements as the argument. > Â Â Â Collect the resulting values into a Set, thus repeated objects will not > be present. > Â Â Â Answer the new collection." > > Â Â Â | newSet | > Â Â Â newSet := self species new asSet. > Â Â Â self do: [:each | newSet add: (aBlock value: each)]. > Â Â Â ^ newSet > > > Is there a better way ?Â Â Do you think it make sense to put this in Pharo ? > > Cheers > > 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

March 12, 2010

Re: [Pharo-project] Collection >> collectDistinct: ??

by csrabak＠bol.com.br

Em 10/03/2010 09:50, Mariano Martinez Peck < marianopeck(a)gmail.com > escreveu: > Hi. I was needing something like the SQL select distinct, that > doesn't take into account repeated objects. I didn't found anything > useful in Collection, and thus, I have implemented this: > Collection >> collectDistinct: aBlock > > collectDistinct: aBlock > "Evaluate aBlock with each of the receiver's elements as the > argument. Collect the resulting values into a Set, thus repeated > objects will not be present. Answer the new collection." > | newSet | > newSet := self species new asSet. > self do: [:each | > newSet add: (aBlock value: each)]. > ^newSet > > Is there a better way ? Do you think it make sense to put this in > Pharo ? > Cheers Mariano, IIUC, your intent with this method is/was to get non repeated elements in a generic collection. However, the way is coded the result is Set which is returned instead of the collection from which the method had been called. I didn't miss something, the result of your proposed method is akin to calling Collection>>collect: and sending asSet to it. ITYM: | newSet | newSet := Set new . self do: [:each | newSet add: (aBlock value: each)]. ^newSet as: (self class) HTH -- Cesar Rabak

March 12, 2010

Re: [Pharo-project] [squeak-dev] We applied!!!

by GermÃ¡n Arduino

Excellent Mariano! It's good, very good to see all Smalltalk's thinking and working together! Cheers. GermÃ¡n. 2010/3/12 Mariano Martinez Peck <marianopeck(a)gmail.com>: > See the final application at: http://gsoc2010.esug.org/application.html. > See final project ideas at: http://gsoc2010.esug.org/ideas.html > > > It seems that we managed to activate our whole community to propose a > record number of projects in a record short time this year. We namely > have 35 project ideas (comparing to 15 in 2009, 18 in 2008, 24 in 2007) > Proposed projects seem also of a high quality and this won't get > unnoticed by Google, we can be sure. > > So, let we keep fingers crossed for a few days until Thursday, 16.March > for Google to decide... > > Thanks to all for the project submissions, ideas, feedback and corrections! > > Janko and Mariano > > > >

March 12, 2010

[Pharo-project] We applied!!!

by Mariano Martinez Peck

See the final application at: http://gsoc2010.esug.org/application.html. See final project ideas at: http://gsoc2010.esug.org/ideas.html It seems that we managed to activate our whole community to propose a record number of projects in a record short time this year. We namely have 35 project ideas (comparing to 15 in 2009, 18 in 2008, 24 in 2007) Proposed projects seem also of a high quality and this won't get unnoticed by Google, we can be sure. So, let we keep fingers crossed for a few days until Thursday, 16.March for Google to decide... Thanks to all for the project submissions, ideas, feedback and corrections! Janko and Mariano

March 12, 2010

[Pharo-project] [update 1.1] #11259

by StÃ©phane Ducasse

11259 ----- - Issue 1614: EmptyBlock is returning last argument instead of nil (thanks lukas and jorge) Stef

March 12, 2010

Re: [Pharo-project] [squeak-dev] Re: [vwnc] GSoC idea: Brainstorming portal for better community decision process

by Janko MivÅ¡ek

Hi Gregory, On 12. 03. 2010 01:47, Gregory Bourassa wrote: > Paul has made some criticisms of your idea elsewhere on the thread...and > some of his points are certainly worth considering. > > However, a system with some of the attributes you describe might be > implemented as a "fun" tool to experiment with social communities and > the outcomes of their interactions. If you take one step of > abstraction away from "serious" consensus-seeking and make the tool > configurable enough to support "playing at consensus seeking", it > might become a runaway hit. :-) It seems so :) Sometimes one needs to dress his idea as a toy to easier convince the people, I agree, ok, let we make a toy :) Thanks for that proposal, I'll actually start thinking in this direction! Janko > > Gregory Bourassa > > > Janko MivÅ¡ek wrote: >> Dear Smalltalkers, >> >> Becasue we have quite some problems in a community with seeking a >> consensus on important questions, from organization ones and on, I came >> to idea to build a tool for help. And a GSoC project can be an ideal >> opportunity to build such a tool. What do you think? >> >> Here is a description: >> >> Brainstorming portal for better community decision process >> ========================================================== >> >> Create a web portal for brainstorming sessions/meetings to get ideas and >> answers to important questions in Smalltalk community. Portal should >> allow on-line to: >> >> 1. brainstorm the ideas >> 2. vote to get-out the best ideas >> 3. seek consensus >> 4. analyze - report >> >> On-line session/meeting should look like a Skype session together with a >> brainstorming portal, from collecting ideas to a final decision >> proposal. Example of such session can be a Squeak Oversight Board >> meeting or planning session for a new Smalltalk project. Or some broader >> session in the community, like on a question how to organize better. >> >> Some important concepts: >> >> * anonymity of idea proposers >> * associations: proposers see the ideas of anonymous others to >> facilitate an association for proposing an even better idea >> * seeking consensus to avoid 51/49% decisions but to come closer to >> 100% agreement on important ideas. >> >> Technical details >> >> * a web application for gathering brainstormed ideas in real-time >> (using Ajax and Comet technology). >> * voting system with appropriate algorithms >> * analytics with on-line graphs and reports on paper/PDF >> * installation on a publicly available hosting server >> >> Benefits to the Student >> >> * getting insight into group dynamics of Smalltalk community and in >> general >> * gaining knowledge of modern web technologies in Smalltalk and in >> general >> >> Benefits to the Community >> >> Better community decision process by getting the best ideas from the >> members while on the other side avoiding stalemates so frequent in >> Smalltalk community those days >> >> >> Best regards >> Janko >> >> >> > > ----------------------------------------- > Key Technology, Inc. Disclaimer Notice - The information and > attachment(s) contained in this communication are intended for the > addressee only, and may be confidential and/or legally privileged. If > you have received this communication in error, please contact the sender > immediately, and delete this communication from any computer or network > system. Any interception, review, printing, copying, re-transmission, > dissemination, or other use of, or taking of any action upon this > information by persons or entities other than the intended recipient is > strictly prohibited by law and may subject them to criminal or civil > liability. Key Technology, Inc. is not liable for the improper and/or > incomplete transmission of the information contained in this > communication or for any delay in its receipt. > > > > -- Janko MivÅ¡ek AIDA/Web Smalltalk Web Application Server http://www.aidaweb.si

March 12, 2010