- Pharo-dev - lists.pharo.org

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

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

by StÃ©phane Ducasse

I had the impression that this was the direction newspeak was going. On Mar 23, 2009, at 12:15 AM, Antony Blakey wrote: > > On 23/03/2009, at 12:32 AM, StÃ©phane Ducasse wrote: > >> can you illustrate that point? > > It might be that Smalltalk and wide-spread immutability and > fundamentally incompatible. The problem is that Smalltalk's model has > Objects whose state changes in response to messages. Such state change > breaks immutability. But if objects are immutable, then the problem is > that after any mutation operation within a method, subsequent sends > need to be not to self, but to the newly mutated object. This problem > cascades, with the effective self needing to change potentially after > every send. Maybe the solution is to enable that to happen seamlessly > e.g. 'self' changes as the object mutates (because the object isn't > actually mutating). Objects do make immutability-based concurrency > more 'interesting'. > > It's important to note that Clojure is a rethinking of Lisp, and the > end result is not Common Lisp + concurrency + Java interop. I suspect > that a rethinking of Smalltalk would be similarly different than what > we now know. This doesn't surprise me - out assumptions about > concurrency, or the lack of it, and general inexperience with taming > true concurrency, is a significant context the design of most existing > languages, with notable exceptions such as CSP/Occam. > > Maybe the appropriate concurrency model for Smalltalk IS an ultra- > lightweight fine-grained copy-on-write multiple image model, with that > being the *only* threading abstraction. If you could control the > separation e.g. share some objects with well defined concurrency > semantics like Clojure such STM/Refs/Agents etc, then that might be > the best fit. OTOH a shared-nothing model would give you CSP/Erlang. > The implementation challenges are very different, and I must admit I > don't know enough about Hydra to know if that project has solved this > issue. > > Antony Blakey > ------------- > CTO, Linkuistics Pty Ltd > Ph: 0438 840 787 > > He who would make his own liberty secure, must guard even his enemy > from repression. > -- Thomas Paine > > > > _______________________________________________ > 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

[Pharo-project] HowToContribute wiki page

by Serge Stinckwich

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. Best regards, -- 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] Fwd: [vwnc] Would you start a new Smalltalk project today?

by StÃ©phane Ducasse

> Here's some exposition: http://clojure.org/concurrent_programming I will reread it then > > >> Another question I would love to have immutability bit for pharo. >> Now if you have immutable collection then I imagine that >> - you should copy them when you want to modify them (functional) > > That happens automatically. Modification operations are functional > > e.g. f(data) -> data' > > data' is a different object than data, which remains unchanged. > Efficiently implementing this is the key, but it's been done. but do they guarante identity preservation I guess not. > > >> - I was wondering if the object that you put such immutable data >> structure should >> also be immutable > > Not necessarily - in the case of Clojure you might put a Ref/Var/Atom/ > Agent into an immutable structure, and those objects have their own > concurrency semantics as described in the link above. > > Antony Blakey > ------------- > CTO, Linkuistics Pty Ltd > Ph: 0438 840 787 > > Borrow money from pessimists - they don't expect it back. > -- Steven Wright > > > > _______________________________________________ > 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