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

Re: [Pharo-project] Fwd: [vwnc] Would you start a new Smalltalk project today?

by Antony Blakey

On 23/03/2009, at 6:51 PM, StÃ©phane Ducasse wrote: > but do they guarante identity preservation I guess not. Identity is obviously more important in OO than e.g. functional or function-based programming such as Lisp. This is the sort of thing I had in mind when I said that Smalltalk and immutability are less obviously a good fit than immutability and lisp-like languages such as Clojure. Antony Blakey ------------- CTO, Linkuistics Pty Ltd Ph: 0438 840 787 Nothing is really work unless you would rather be doing something else. -- J. M. Barre

March 23, 2009

Re: [Pharo-project] Concurrent programming (was: Would you start a new Smalltalk project today?)

by Antony Blakey

On 23/03/2009, at 7:05 PM, StÃ©phane Ducasse wrote: > do you know pointers that explain the interplay between transactional > memory and concurrency/immutable structure. There are many papers on STM that describe the benefits wrt concurrency. Wikipedia has a good explanation http://en.wikipedia.org/wiki/Software_transactional_memory with many subsequent links. The relative weight of the pros and cons vary depending both on the STM implementation (e.g. Clojure uses MVCC) and the language into which STM is embedded. Immutability makes a big difference by reducing contention granularity. Clojure has the additional benefit of explicitly identifying the points are which conflict can occur e.g. Refs. Antony Blakey ------------- CTO, Linkuistics Pty Ltd Ph: 0438 840 787 It is no measure of health to be well adjusted to a profoundly sick society. -- Jiddu Krishnamurti

March 23, 2009

Re: [Pharo-project] Software update

by Damien Cassou

On Mon, Mar 23, 2009 at 9:19 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > The update stream only includes update for the image pharo-core > for the pharo-dev you should use the universe browser. Universe is currently not used anymore to build pharo-dev. I'm building them using Monticello. The best solution is to save your code externally using Monticello and use the most recent pharo-dev when it comes out. That will ensure your code can be loaded in all images. That's a best practice used by different people. You can also use the update stream to update the core and MC to update the packages you want but I do not recommend this solution. -- Damien Cassou http://damiencassou.seasidehosting.st

March 23, 2009

Re: [Pharo-project] [ANN] Closures for beta testers

by Damien Cassou

On Sun, Mar 22, 2009 at 10:11 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > I can post the two images somewhere if this helps. Please provide a new image or update the stream. -- Damien Cassou http://damiencassou.seasidehosting.st

March 23, 2009

Re: [Pharo-project] HowToContribute wiki page

by Serge Stinckwich

On Mon, Mar 23, 2009 at 3:36 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > On Mar 23, 2009, at 9:26 AM, Serge Stinckwich wrote: > >> Hi, >> i'm currently reading this page : >> http://code.google.com/p/pharo/wiki/HowToContribute >> and it's not really clear when someone do not need to make a >> modification to several packages ... >> I guess you have to publish to modified package to PharoInbox also. > > Serge > you should publish the slice and it will automatically publish the > modified packages. But when only one package is modified, you need a slice also ? -- Serge Stinckwich UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam Smalltalkers do: [:it | All with: Class, (And love: it)] http://doesnotunderstand.org/

March 23, 2009

Re: [Pharo-project] HowToContribute wiki page

by Adrian Lienhard

On Mar 23, 2009, at 09:26 , Serge Stinckwich wrote: > Hi, > i'm currently reading this page : > http://code.google.com/p/pharo/wiki/HowToContribute > and it's not really clear when someone do not need to make a > modification to several packages ... > I guess you have to publish to modified package to PharoInbox also. Yes. In this case, no SLICE package is needed. We could also mention that instead of going through PharoInbox, creating a changeset and attaching it to the issue in the tracker is an alternative (which sometimes is much less time consuming). Adrian > > > Best regards, > -- > Serge Stinckwich > UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam > Smalltalkers do: [:it | All with: Class, (And love: it)] > http://doesnotunderstand.org/ > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

March 23, 2009

Re: [Pharo-project] HowToContribute wiki page

by StÃ©phane Ducasse

On Mar 23, 2009, at 9:26 AM, Serge Stinckwich wrote: > Hi, > i'm currently reading this page : > http://code.google.com/p/pharo/wiki/HowToContribute > and it's not really clear when someone do not need to make a > modification to several packages ... > I guess you have to publish to modified package to PharoInbox also. Serge you should publish the slice and it will automatically publish the modified packages. Stef > > > Best regards, > -- > Serge Stinckwich > UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam > Smalltalkers do: [:it | All with: Class, (And love: it)] > http://doesnotunderstand.org/ > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

March 23, 2009

Re: [Pharo-project] Concurrent programming (was: Would you start a new Smalltalk project today?)

by StÃ©phane Ducasse

do you know pointers that explain the interplay between transactional memory and concurrency/immutable structure. On Mar 23, 2009, at 7:54 AM, David Finlayson wrote: > Rich Hickey the creater of Clojure (functional Lisp) has done a bunch > of nice videos on the language here is one he did on concurrency that > is really very good: > > http://blip.tv/file/812787 > > At the end, he introduces an ant colony simulation that has similar > concurrency problems to your rock falling simulation. It is all done > with immutable persistent data structures and transaction memory. I > think it is the most exciting new programing language development of > the past few years. I wound up watching many of his videos. > > Smalltalk could do this stuff well. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

March 23, 2009

Re: [Pharo-project] Concurrent programming (was: Would you start a new Smalltalk project today?)

by StÃ©phane Ducasse

Strange since andreas was mentioning that squeak thread swicthing costs far less than in VW. Stef On Mar 23, 2009, at 4:49 AM, Michael van der Gulik wrote: > > > On Mon, Mar 23, 2009 at 2:21 PM, Michael van der Gulik <mikevdg(a)gmail.com > > wrote: > > > On Mon, Mar 23, 2009 at 12:34 PM, Igor Stasenko <siguctua(a)gmail.com> > wrote: > > Now consider the overhead of creating a fork vs the actual useful code > which is running within a block. > I presume, this code will run 10x times slower on a single core > processor, comparing to one w/o forks. > So, you will need to have 10 cores to match the computation time with > single core processor. > > I think its not wise to introduce parallelism on such low levels (in > Concurrent.Collections.Array>>withIndexDo:). Its like hammering nails > with microscope :) > > That's why i'm saying its too good to be true. > Introducing parallelism at such low levels will be a waste. I leaning > toward island model. This is a middle point between no sharing, like > in Hydra and sharing everything, like in what you proposing. > > 10 times slower? Sounds like a made-up number to me... > > " Using 101 threads: " > c := ConcurrentArray new: 1000001. > Time millisecondsToRun: [c withIndexDo: [ :each :i | c at: i put: i > asString. ]]. > 5711 > 5626 > 6074 > > " Using 11 threads: " > c := ConcurrentArray new: 1000001. > Time millisecondsToRun: [c withIndexDo: [ :each :i | c at: i put: i > asString. ]]. > 3086 > 3406 > 3256 > > " Using 1 thread: " > d := Array new: 1000001. > Time millisecondsToRun: [d withIndexDo: [ :each :i | d at: i put: i > asString]]. > 2426 > 2610 > 2599 > > My implementation is 1/2 to 1/3 the speed of the single-threaded > Array. If the blocks did more work, then the overhead would be lower > and some benefit would be gained from using multiple cores. > > I don't have a good idea of where the overhead is going - maybe it's > being lost in the block copying that is needed to work around > Squeak's deficiencies? Or maybe it's waiting for the scheduler to do > its stuff? > > Implementation attached, MIT license if you're picky. > > > I just tried it on VisualWorks as well. I removed the block copying > and renamed the method to "keysDo:" (I never thought of an array > like that before... keys and values). > > d := Array new: 1000001. > Time millisecondsToRun: [d keysDo: [ :i | d at: i put: i > printString]]. > 1180 > 982 > 1008 > > " Using 101 threads " > c := ConcurrentArray new: 1000001. > Time millisecondsToRun: [c keysDo: [ :i | c at: i put: i > printString. ]]. > 1072 > 1120 > 962 > > At this stage, I'm suspicous about the results :-). > > Gulik. > > -- > http://gulik.pbwiki.com/ > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

March 23, 2009

Re: [Pharo-project] Concurrent programming (was: Would you start a new Smalltalk project today?)

by StÃ©phane Ducasse

Michael there is no problem. discussion is also good. Dogma or trolling would be boring :) On Mar 23, 2009, at 12:42 AM, Michael van der Gulik wrote: > > > On Mon, Mar 23, 2009 at 11:39 AM, Antony Blakey <antony.blakey(a)gmail.com > > wrote: > > On 23/03/2009, at 7:37 AM, Michael van der Gulik wrote: > > > > > Smalltalk, the language rather than the implementation, already has > > fantastic support for concurrency. Smalltalkers just don't know how > > to use it. We don't need to rethink the model, we just need to learn > > to use what we have. > > Mutexes and semaphores are hardly 'fantastic'. The state of the art in > support for concurrency is way beyond what Smalltalk provides - > locking is both primitive and generally not scalable. > > > Semaphores _are_ fantastic!! Lock-free algorithms are even cooler. > > The language lends itself to building up higher abstractions. Take > for example Collection and all its subclasses; they're screaming out > to have parallelised versions made: > > c := ConcurrentOrderedCollection new. > c do: [ :each | ...this part gets executed in parallel...]. > > The caveat here is that you need to be careful about side-effects. > > This is just one example. I have some more rudimentary ideas at: > http://gulik.pbwiki.com/Parallel+processing. > > Oh, and sorry to the Pharo guys for keeping this going. Let us know > if you don't want threads like this on your list. > > Gulik. > > > -- > http://gulik.pbwiki.com/ > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

March 23, 2009