- Pharo-dev - lists.pharo.org

[Pharo-project] String widgets for GUIs built using ToolBuilder

by Ralph Boland

I originally posted this on Squeak-Dev but I didn't get a response so I am hoping someone on this list can help. I will release the code I am working on to SqueakSource. I assume it will work in Pharo as well. If it doesn't let me know and I will clean up the problems. ================================= I am trying to subclass TestBuilder (SUnitGUI) for my own testing facility. TestBuilder builds a GUI using ToolBuilder and I am trying to build my GUI using ToolBuilder as well. I need to use an input field and want to add a StringMorph like widget to label the input field. The only way I can see to do this using ToolBuilder is to use another input field for my input field label string. There has to be a better, standard, way of doing this. Can someone tell me what the standard way, or some reasonable way, of labeling my input field is when using ToolBuilder? Regards, Ralph Boland -- Had a wife and kids in Florida, Jack (Nicklaus) Went out for a "ride" but I couldn't get back As a ten timer being hunted down OR When the wife found out who I was knowing (biblically speaking) I hit a hydrant and I just kept going (till I hit a tree). ...

March 13, 2010

Re: [Pharo-project] Collection

by Henrik Sperre Johansen

On 13.03.2010 01:23, Levente Uzonyi wrote: > 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 If you're talking about alternate addFirst: addLast: adds, is that really a usecase worth optimizing for? makeRoomAtFirst:/Last: can definately be sped up using replaceFrom:to:with:startingAt: though. > - SortedCollection: just deprecate it (or replace it's crappy > quicksort implementation if you really want to improve it. But I think > it's useless) +1 > > - StandardFileStream >> #upTo: (the recursive call + concatenation > requires O(n^2) runtime and O(n^2) memory for large chunks of data) > I did a different implementation some time ago, didn't notice enough of a speedup to consider posting it though. Hope you have better luck :) Cheers, Henry

March 13, 2010

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