[Pharo-project] Collection
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? If you have any idea related to optimizations let me know. Stef
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? If you have any idea related to optimizations let me know.
I will get bashed but: [1] 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 [1] http://code.google.com/p/google-collections/ [2] http://java.sun.com/javase/6/docs/api/java/util/concurrent/ConcurrentMap.htm... Cheers Philippe
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), ... Lukas -- Lukas Renggli http://www.lukas-renggli.ch
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.
We could (theoretically, if other dialects follow) delete our code. Everybody who needs something similar doesn't need to write his own.
Also we have some ad-hock solutions for the thread safe dictionaries.
Yeah, the same comment as above applies. Cheers Philippe
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/go... Cheers Philippe
Thanks for the suggestions :)
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? If you have any idea related to optimizations let me know.
I will get bashed but: [1]
no not us :) You remember I forced you to give a talk on what we could learn from Java :)
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
[1] http://code.google.com/p/google-collections/ [2] http://java.sun.com/javase/6/docs/api/java/util/concurrent/ConcurrentMap.htm...
Cheers Philippe
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On 11 March 2010 15:24, stephane ducasse <stephane.ducasse@free.fr> 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? If you have any idea related to optimizations let me know.
I'd say that it is strange choice, because collections , apart of having big protocols don't really interesting piece of code from an optimization side, because most of things there already implemented quite good. Reimplementing them using traits - that's would be cool.
Stef _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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
On Sat, 13 Mar 2010, Henrik Sperre Johansen wrote:
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.
My ideas would result in a general minor speedup, while mixed use of #addFirst: and #addLast: wouldn't suffer the performance penalty at all. So we can win something without losing anything. #replaceFrom:to:with:startingAt: can only be used to move elements to a position with lower index, otherwise overlapping areas will be overwritten.
- 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 :)
I don't have an implementation yet, but I expect ~3-5% speedup if reading all the sources. This may seem insignificant, but if other bottlenecks are out of the way, this may be 15-25%. And my opinion is still that "library functions" should be optimized for most usecases, so this should be fixed. Levente
Cheers, Henry
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Sat, Mar 13, 2010 at 12:23 AM, Levente Uzonyi <leves@elte.hu> wrote:
- SortedCollection: just deprecate it (or replace it's crappy quicksort implementation if you really want to improve it. But I think it's useless)
You shouldn't deprecate it... it's ANSI. :) But it's implementation could certainly be improved... Julian
On Sat, 13 Mar 2010, Julian Fitzell wrote:
On Sat, Mar 13, 2010 at 12:23 AM, Levente Uzonyi <leves@elte.hu> wrote:
- SortedCollection: just deprecate it (or replace it's crappy quicksort implementation if you really want to improve it. But I think it's useless)
You shouldn't deprecate it... it's ANSI. :)
That's why I suggested deprecating instead of removing. :)
But it's implementation could certainly be improved...
IMHO it shouldn't be used at all. Levente
Julian
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
10 or 15 years back I look a look at the SortedCollection logic with an eye to improve it. Oddly I found the folks who wrote it had a good understanding of how the code becomes bytecodes and how that impacts performance. My attempts made things worst, so good luck. Personally I'd choose the font rendering path, since there is lots of *stuff* required to run to splash a character glyph to Display. On 2010-03-12, at 4:46 PM, Julian Fitzell wrote:
On Sat, Mar 13, 2010 at 12:23 AM, Levente Uzonyi <leves@elte.hu> wrote:
- SortedCollection: just deprecate it (or replace it's crappy quicksort implementation if you really want to improve it. But I think it's useless)
You shouldn't deprecate it... it's ANSI. :)
But it's implementation could certainly be improved...
Julian
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- =========================================================================== John M. McIntosh <johnmci@smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================
On Fri, 12 Mar 2010, John M McIntosh wrote:
10 or 15 years back I look a look at the SortedCollection logic with an eye to improve it. Oddly I found the folks who wrote it had a good understanding of how the code becomes bytecodes and how that impacts performance. My attempts made things worst, so good luck.
Quicksort has worse performance than merge sort in dynamic languages (and in general when comparison costs more than minimal), because it makes more comparisons. The simple quicksort performs really bad (O(n^2)) if there are only a few different elements. A 3-way partitioning algorithm could perform much better in general, but I think it'd be still slower than merge sort. Here is a bug report which is pretty naive, but shows the effect of the few different elements case: http://code.google.com/p/pharo/issues/detail?id=1718&q=sort&colspec=ID%20Typ... Squeak/Pharo's merge sort implementation is highly optimized. The merge algorithm compiles to pure bytecodes and primitive sends. Levente
Personally I'd choose the font rendering path, since there is lots of *stuff* required to run to splash a character glyph to Display.
On 2010-03-12, at 4:46 PM, Julian Fitzell wrote:
On Sat, Mar 13, 2010 at 12:23 AM, Levente Uzonyi <leves@elte.hu> wrote:
- SortedCollection: just deprecate it (or replace it's crappy quicksort implementation if you really want to improve it. But I think it's useless)
You shouldn't deprecate it... it's ANSI. :)
But it's implementation could certainly be improved...
Julian
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- =========================================================================== John M. McIntosh <johnmci@smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
I think that this is great. We need to optimize as much as it makes sense without breaking our nice apis. Stef On Mar 13, 2010, at 1:23 AM, 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 - 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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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
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@lists.gforge.inria.fr 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 <stephane.ducasse@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr 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 <stephane.ducasse@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On 14 March 2010 15:24, Stéphane Ducasse <stephane.ducasse@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@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
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
On 14 March 2010 17:12, Lukas Renggli <renggli@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
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
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
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: http://n4.nabble.com/file/n1750153/Reingenier-a_de_Jerarqu-as_Polim-rficas_U... 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 -- View this message in context: http://n4.nabble.com/Collection-tp1590427p1750153.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
participants (13)
-
Henrik Sperre Johansen -
Igor Stasenko -
John M McIntosh -
Julian Fitzell -
Levente Uzonyi -
Lukas Renggli -
Miguel Enrique Cobá Martinez -
Nicolas Cellier -
Philippe Marschall -
Philippe Marschall -
stephane ducasse -
Stéphane Ducasse -
Tristan Bourgois