February 2012 - Pharo-dev - lists.pharo.org

[Pharo-project] [update 1.4] #14302

by Marcus Denker

14302 ----- Issue 5232: CheckButton is fully clickable http://code.google.com/p/pharo/issues/detail?id=5232 Issue 5231: Mini fix in CheckButtonMorph http://code.google.com/p/pharo/issues/detail?id=5231 Issue 5235: A very little fix to ensure Checkboxes take the keyboard focus when clicked http://code.google.com/p/pharo/issues/detail?id=5235 Issue 5230: removePseudoContext Part2 http://code.google.com/p/pharo/issues/detail?id=5230 -- Marcus Denker -- http://marcusdenker.de

Feb. 3, 2012

Re: [Pharo-project] About linkedlist

by Ben Coman

Lukas Renggli wrote: >>>>> what is the diff between arrayList and vectorList ? >>>>> >>>> ArrayList is double ended (very much like OrderedCollection), >>>> VectorList is single ended. I was just experimenting to see if it >>>> makes a difference. >>>> >> ok. I like to see such kind of experiment. >> Was the name based on something that people use? >> > > No, it is a randomly chosen and meaningless name. I guess in the end > there will only be one named ArrayList, but I am not sure which > implementation is better. > > I wasn't sure what double-ended versus single-ended meant, and found some answer at the obvious place [1] which mentions Ada.Containers.Vectors is a dynamic array implementation which seems consistent with C++ [2]. While looking around I happened to bump into [3] which was too much for me but may be of interest to anyone playing with data structres. Skimming this shows it discussing efficiency of data structures in functional languages together with lazy variants of imperative language data structures. Would such apply to Smalltalk or is the object-oriented style of Smalltalk considered imperative rather than functional? [1] http://en.wikipedia.org/wiki/Double-ended_queue [2] http://en.wikipedia.org/wiki/Sequence_container_%28C%2B%2B%29 [3] http://www.cs.cmu.edu/~rwh/theses/okasaki.pdf

Feb. 3, 2012

[Pharo-project] load testing a database

by Tudor Girba

Hi, Do you happen to know methods to approach the problem of testing the capacity of an application to work with an SQL database? In particular, I am interested in simulating concurrent requests towards this database that would resemble the interaction coming from the application. Cheers, Doru -- www.tudorgirba.com "Every thing has its own flow"

Feb. 3, 2012

Re: [Pharo-project] About linkedlist

by Lukas Renggli

>>>> what is the diff between arrayList and vectorList ? >>> >>> ArrayList is double ended (very much like OrderedCollection), >>> VectorList is single ended. I was just experimenting to see if it >>> makes a difference. > > ok. I like to see such kind of experiment. > Was the name based on something that people use? No, it is a randomly chosen and meaningless name. I guess in the end there will only be one named ArrayList, but I am not sure which implementation is better. Just a note to the VM developers: The primitive Array>>#replaceFrom:to:with:startingAt: is absolutely central to the implementation of efficient collections. While it works well if you copy from one array to the other, it is broken if source and destination array are the same and the areas overlap. Would it be possible to fix this. Even "memmove(void*, void*, size_t)" in C can handle this situation correctly. >>>> Do you have some kind of high level description of Container explaining the rationale, ideas and approach. >>> >>> The core idea is to split iteration from containment; I think a >>> horrible design mistake in the Smalltalk-80 collections. > > I thought about that when I read the Iterator. > I would not say that this is horrible. I think that for default case this is not that bad. > Now when you want to navigate a large graph and control the navigation then you should have an iterator. I think it is pretty horrible. I can think of at least 4 meaningful ways to iterate over an simple array (for other collections there are even more ways): 1. forward: #do:, #collect:, #select:, #detect:, #inject:into:, ... 2. forward with index: #keysAndValuesDo:, #collectWithIndex:, everything else is not possible 3. backward: #reverseDo:, everything else is not possible 4. backward with index: not possible If you split the iterator into a separate object, suddenly all of this becomes trivial. A #collect: remains a #collect: no matter if you are going forward or backward, or with or without index. Lukas -- Lukas Renggli www.lukas-renggli.ch

Feb. 3, 2012

Re: [Pharo-project] About linkedlist

by Igor Stasenko

On 3 February 2012 13:33, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > On Feb 3, 2012, at 12:20 PM, Nicolas Cellier wrote: > >> 2012/2/3 Lukas Renggli <renggli(a)gmail.com>: >>> This is all very much at an experimental phase. >>> >>>> what is the diff between arrayList and vectorList ? >>> >>> ArrayList is double ended (very much like OrderedCollection), >>> VectorList is single ended. I was just experimenting to see if it >>> makes a difference. > > ok. I like to see such kind of experiment. > Was the name based on something that people use? > >>>> Do you have some kind of high level description of Container explaining the rationale, ideas and approach. >>> >>> The core idea is to split iteration from containment; I think a >>> horrible design mistake in the Smalltalk-80 collections. > > I thought about that when I read the Iterator. > I would not say that this is horrible. I think that for default case this is not that bad. > Now when you want to navigate a large graph and control the navigation then you should have an iterator. > > I'm curious to see what you will get. > >>> >>>> Do you have some kind of high level description of Container explaining the rationale, ideas and approach. >>>> It is one thing to browse the code, but the why/how is important as a guide. >>> >>> Another idea is to split the backing store from the container and >>> allow the composition of collection properties: >>> >>> Â - uniqueness: yes, no >>> Â - order: natural, custom, indexed >>> Â - access: indexed, keyed >>> Â - structure: hashed, treed, linked >>> Â - weakness: yes, no (not even touched yet) > > Yes I as to see that because I often want uniqueOrdered (not clear what you do when you add twice the same) > >>> >>>> It seems that although you introduce iterators, they are less annoying then expected, which is great. >>> >>> The goal here is to be as lazy as possible and avoid unnecessary loops >>> over the collections. >>> >>> Also iterators avoid the explosion of selector combinations like (#do: >>> and #withIndexDo: and #withIndexCollect:, etc) by utilizing objects. >>> >>>> Also, a certain level of backwards compatibility seems to be present, looking at message names. >>> >>> I like the existing names, but then this is not a goal. Also I am not >>> sure if methods like #add: and #at:put: should really return the >>> argument. > > :) > If I would know :) > it is somewhat convenient, because you can do things like: newItem := coll at: index ifAbsentPut: [ MyItem new ]. and other such forms... > Stef > -- Best regards, Igor Stasenko.

Feb. 3, 2012

Re: [Pharo-project] keeping up with lively-kernel (morphic)

by Fernando Olivero

Pharo is not only targeted at business..you can do research and other cool stuff on top of it. For example, Athens, Ring, the new Event-Model, and many other enhancements and additions to Pharo over the recent years, enable the development of new UI frameworks, in an easier and more elegant manner than before. Fernando On Fri, Feb 3, 2012 at 8:59 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > On Feb 2, 2012, at 11:21 PM, Helene Bilbo wrote: > >> >> Marcus Denker-4 wrote >>> >>> So there are multiple problems: >>> >>> 1) Morphic is not and API or a codebase but and idea (or principle) >>> And the question is even: a good one? In the current state for sure not. >>> For sure it's instantiation depends *a lot* on the language >>> model you have. >>> >> >> I think exactly the Morphic ideas (or principles) (not the squeak morphic >> code or the missing documentation or a morphic implementation in javascript) >> were so very charming, elegant and intriguing. Directly manipulating, >> combining Objects/Morphs and - as i read in this paper about LivelyKernel >> [1] - serializing them. >> >> But as i understood the Pharo Vision Document, Pharo is more aimed at >> business customers and therefor strives for being similar to other business >> oriented smalltalks rather than becoming Squeak with cleaner and smaller >> code and better documentation (which would have been also a very nice goal)? > > Pharo wants to be a platform where people can innovate so if you want to innovate at the UI level (for example Gaucho) > you need a good and flexible infrastructure. > > > >> >> [1] >> http://www.hpi.uni-potsdam.de/hirschfeld/publications/media/LinckeKrahnInga… >> >> -- >> View this message in context: http://forum.world.st/keeping-up-with-lively-kernel-morphic-tp4349125p43530… >> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >> > >

Feb. 3, 2012

Re: [Pharo-project] About linkedlist

by StÃ©phane Ducasse

On Feb 3, 2012, at 12:20 PM, Nicolas Cellier wrote: > 2012/2/3 Lukas Renggli <renggli(a)gmail.com>: >> This is all very much at an experimental phase. >> >>> what is the diff between arrayList and vectorList ? >> >> ArrayList is double ended (very much like OrderedCollection), >> VectorList is single ended. I was just experimenting to see if it >> makes a difference. ok. I like to see such kind of experiment. Was the name based on something that people use? >>> Do you have some kind of high level description of Container explaining the rationale, ideas and approach. >> >> The core idea is to split iteration from containment; I think a >> horrible design mistake in the Smalltalk-80 collections. I thought about that when I read the Iterator. I would not say that this is horrible. I think that for default case this is not that bad. Now when you want to navigate a large graph and control the navigation then you should have an iterator. I'm curious to see what you will get. >> >>> Do you have some kind of high level description of Container explaining the rationale, ideas and approach. >>> It is one thing to browse the code, but the why/how is important as a guide. >> >> Another idea is to split the backing store from the container and >> allow the composition of collection properties: >> >> - uniqueness: yes, no >> - order: natural, custom, indexed >> - access: indexed, keyed >> - structure: hashed, treed, linked >> - weakness: yes, no (not even touched yet) Yes I as to see that because I often want uniqueOrdered (not clear what you do when you add twice the same) >> >>> It seems that although you introduce iterators, they are less annoying then expected, which is great. >> >> The goal here is to be as lazy as possible and avoid unnecessary loops >> over the collections. >> >> Also iterators avoid the explosion of selector combinations like (#do: >> and #withIndexDo: and #withIndexCollect:, etc) by utilizing objects. >> >>> Also, a certain level of backwards compatibility seems to be present, looking at message names. >> >> I like the existing names, but then this is not a goal. Also I am not >> sure if methods like #add: and #at:put: should really return the >> argument. :) If I would know :) Stef >> > > These two are convenient for enabling this kind of DSL instructions > > A[i] := B[j] := c > > But of course, a dup bytecode would also do the trick... > > Nicolas > >> Essentially the goal is to provide an alternative to the Smalltalk-80 >> collections by adopting some ideas from modern collection libraries in >> Java, C++, Scala, Haskell, etc. >> >> Lukas >> >> On 3 February 2012 10:07, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>> what is the diff between arrayList and vectorList ? >>> I have plenty of other questions. :) >>> >>> Stef >>> >>> >>> On Feb 3, 2012, at 9:26 AM, Lukas Renggli wrote: >>> >>>> See below for an alternative collection implementation: >>>> >>>> http://jenkins.lukas-renggli.ch/job/Container/ >>>> >>>> Also contains a nice double-linked-list, as well as many other >>>> standard containers that are missing in standard Smalltalk. >>>> >>>> Lukas >>>> >>>> On 3 February 2012 07:52, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>>>> Hi >>>>> >>>>> I was thinking that linkedList is really not to be used by something else than the scheduler (remember the >>>>> problem we got with change == into something else). >>>>> >>>>> So I was wondering if it would not be simpler/safer to design a generalPurpose fast/robust LinkedList too? >>>>> >>>>> Stef >>>> >>>> >>>> >>>> -- >>>> Lukas Renggli >>>> www.lukas-renggli.ch >>>> >>> >>> >> >> >> >> -- >> Lukas Renggli >> www.lukas-renggli.ch >> >

Feb. 3, 2012

Re: [Pharo-project] [ANN] Shared Smalltalk Workspaces

by GermÃ¡n Arduino

Nice job! 2012/2/2 Sven Van Caekenberghe <sven(a)beta9.be>: > Hi, > > I hacked together a little web service called 'Shared Smalltalk Workspaces'. > > Â Â Â Â http://ws.stfx.eu > > It is basically a pastebin for Smalltalk, a way easily to share Smalltalk workspaces. > > Follow the link above for the details. > > There is a special 'Getting Started' workspace with instructions > > Â Â Â Â http://ws.stfx.eu/1WS4U > > Here are 2 more examples > > Â Â Â Â http://ws.stfxeu/8O58R5KF1FLQ > Â Â Â Â http://ws.stfxeu/8O58TU6FNFL6 > > Enjoy ! > > Sven > > PS: Of course, it is built and served using Pharo 1.4 > > -- > Sven Van Caekenberghe > http://stfx.eu > Smalltalk is the Red Pill > > > > > -- ============================================ GermÃ¡n S. ArduinoÂ <gsa @ arsol.net>Â Â Twitter: garduino Arduino Software Â http://www.arduinosoftware.com PasswordsProÂ http://www.passwordspro.com greensecure.blogspot.com germanarduino.blogpost.com ============================================

Feb. 3, 2012

Re: [Pharo-project] About linkedlist

by Nicolas Cellier

2012/2/3 Lukas Renggli <renggli(a)gmail.com>: > This is all very much at an experimental phase. > >> what is the diff between arrayList and vectorList ? > > ArrayList is double ended (very much like OrderedCollection), > VectorList is single ended. I was just experimenting to see if it > makes a difference. > >> Do you have some kind of high level description of Container explaining the rationale, ideas and approach. > > The core idea is to split iteration from containment; I think a > horrible design mistake in the Smalltalk-80 collections. > >> Do you have some kind of high level description of Container explaining the rationale, ideas and approach. >> It is one thing to browse the code, but the why/how is important as a guide. > > Another idea is to split the backing store from the container and > allow the composition of collection properties: > > Â - uniqueness: yes, no > Â - order: natural, custom, indexed > Â - access: indexed, keyed > Â - structure: hashed, treed, linked > Â - weakness: yes, no (not even touched yet) > >> It seems that although you introduce iterators, they are less annoying then expected, which is great. > > The goal here is to be as lazy as possible and avoid unnecessary loops > over the collections. > > Also iterators avoid the explosion of selector combinations like (#do: > and #withIndexDo: and #withIndexCollect:, etc) by utilizing objects. > >> Also, a certain level of backwards compatibility seems to be present, looking at message names. > > I like the existing names, but then this is not a goal. Also I am not > sure if methods like #add: and #at:put: should really return the > argument. > These two are convenient for enabling this kind of DSL instructions A[i] := B[j] := c But of course, a dup bytecode would also do the trick... Nicolas > Essentially the goal is to provide an alternative to the Smalltalk-80 > collections by adopting some ideas from modern collection libraries in > Java, C++, Scala, Haskell, etc. > > Lukas > > On 3 February 2012 10:07, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> what is the diff between arrayList and vectorList ? >> I have plenty of other questions. :) >> >> Stef >> >> >> On Feb 3, 2012, at 9:26 AM, Lukas Renggli wrote: >> >>> See below for an alternative collection implementation: >>> >>> Â http://jenkins.lukas-renggli.ch/job/Container/ >>> >>> Also contains a nice double-linked-list, as well as many other >>> standard containers that are missing in standard Smalltalk. >>> >>> Lukas >>> >>> On 3 February 2012 07:52, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>>> Hi >>>> >>>> I was thinking that linkedList is really not to be used by something else than the scheduler (remember the >>>> problem we got with change == into something else). >>>> >>>> So I was wondering if it would not be simpler/safer to design a generalPurpose fast/robust LinkedList too? >>>> >>>> Stef >>> >>> >>> >>> -- >>> Lukas Renggli >>> www.lukas-renggli.ch >>> >> >> > > > > -- > Lukas Renggli > www.lukas-renggli.ch >

Feb. 3, 2012

Re: [Pharo-project] About linkedlist

by Lukas Renggli

This is all very much at an experimental phase. > what is the diff between arrayList and vectorList ? ArrayList is double ended (very much like OrderedCollection), VectorList is single ended. I was just experimenting to see if it makes a difference. > Do you have some kind of high level description of Container explaining the rationale, ideas and approach. The core idea is to split iteration from containment; I think a horrible design mistake in the Smalltalk-80 collections. > Do you have some kind of high level description of Container explaining the rationale, ideas and approach. > It is one thing to browse the code, but the why/how is important as a guide. Another idea is to split the backing store from the container and allow the composition of collection properties: - uniqueness: yes, no - order: natural, custom, indexed - access: indexed, keyed - structure: hashed, treed, linked - weakness: yes, no (not even touched yet) > It seems that although you introduce iterators, they are less annoying then expected, which is great. The goal here is to be as lazy as possible and avoid unnecessary loops over the collections. Also iterators avoid the explosion of selector combinations like (#do: and #withIndexDo: and #withIndexCollect:, etc) by utilizing objects. > Also, a certain level of backwards compatibility seems to be present, looking at message names. I like the existing names, but then this is not a goal. Also I am not sure if methods like #add: and #at:put: should really return the argument. Essentially the goal is to provide an alternative to the Smalltalk-80 collections by adopting some ideas from modern collection libraries in Java, C++, Scala, Haskell, etc. Lukas On 3 February 2012 10:07, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > what is the diff between arrayList and vectorList ? > I have plenty of other questions. :) > > Stef > > > On Feb 3, 2012, at 9:26 AM, Lukas Renggli wrote: > >> See below for an alternative collection implementation: >> >> Â http://jenkins.lukas-renggli.ch/job/Container/ >> >> Also contains a nice double-linked-list, as well as many other >> standard containers that are missing in standard Smalltalk. >> >> Lukas >> >> On 3 February 2012 07:52, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>> Hi >>> >>> I was thinking that linkedList is really not to be used by something else than the scheduler (remember the >>> problem we got with change == into something else). >>> >>> So I was wondering if it would not be simpler/safer to design a generalPurpose fast/robust LinkedList too? >>> >>> Stef >> >> >> >> -- >> Lukas Renggli >> www.lukas-renggli.ch >> > > -- Lukas Renggli www.lukas-renggli.ch

Feb. 3, 2012