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

Re: [Pharo-project] Software update

by Rob Rothwell

Well...the Universe Browser used to be in the Pharo image, but now I just open up the repository from Monticello and check for changes when I see things flying around on the lists that might fix something that has been bugging me...! Take care, Rob 2009/3/22 Mariano Martinez Peck <marianopeck(a)gmail.com> > Hi guys. I am quite confused with software updates. > > When you do right button -> system -> software update, what is updated? > just the core ? > > For example, tools like OB how must be updated ? > > Thanks, > > Mariano > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

March 22, 2009

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

by Michael van der Gulik

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/

March 22, 2009

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

by Igor Stasenko

2009/3/22 Michael van der Gulik <mikevdg(a)gmail.com>: > Argh. Stupid GMail sent it prematurely. > > On Mon, Mar 23, 2009 at 10:45 AM, Michael van der Gulik <mikevdg(a)gmail.com> > wrote: >> >> If, for example, you were trying to allocate an array of arrays >> concurrently, then I would write (using my namespaces :-) ): > > >> >> array := Concurrent.Collections.Array new: 1000000000. " We ignore the >> cost of making this array to begin with :-) " >> array withIndexdo: [ :each :i | >> Â Â Â " each will always be nil. " >> Â Â Â array at: i put: (Array new: 10). >> ]. >> >> Concurrent.Collections.Array>>withIndexDo: aBlock >> Â Â Â Â | nThreads sema | >> Â Â Â nThreads := 1000. " Pull this from a system setting or something. " >> Â Â Â sema := Semaphore withSignals: 0-nThreads. " Needs implementing: >> signal it -1000 times (or -999 or -1001? Unsure) " >> Â Â Â 1 to: nThreads do: [ :i | >> Â Â Â Â Â Â Â [ (nThreads*i) to: (nThreads*i - 1) do: [ :j >> Â Â Â Â Â Â Â Â Â Â Â aBlock value: (self at: j) value: j ] >> >> Â Â Â Â Â Â Â Â sema signal. >> Â Â Â Â Â Â Â Â ] fork ]. >> >> Â Â Â sema wait. >> Â Â Â ^ self. >> > > Again, it probably won't just run without some bug fixing. And it won't work > on non-closure Squeak anyway. > 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. > 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 > -- Best regards, Igor Stasenko AKA sig.

March 22, 2009

[Pharo-project] Software update

by Mariano Martinez Peck

Hi guys. I am quite confused with software updates. When you do right button -> system -> software update, what is updated? just the core ? For example, tools like OB how must be updated ? Thanks, Mariano

March 22, 2009

Re: [Pharo-project] Fwd: Issue 668: should clean the option-World click menu

by Rob Rothwell

Got it...I'll play with it and see what you think... Rob On Sun, Mar 22, 2009 at 5:29 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > > On Mar 22, 2009, at 10:17 PM, Rob Rothwell wrote: > > > Ok...I'll try to figure out what those are. You CAN still create > > new Project AND navigate to it, though... > > yes this is why we should remove the menus because Project will soon > explode :) > > > > > > On Sun, Mar 22, 2009 at 5:01 PM, StÃ©phane Ducasse < > stephane.ducasse(a)inria.fr > > > wrote: > > we should remove first the obsolete items (related to etoy and > > project). > > > > stef > > > > On Mar 22, 2009, at 9:24 PM, Rob Rothwell wrote: > > > > > Ok...it seems to be build in: > > > > > > Morph>>buildMetaMenu: > > > and > > > PasteUpMorph>>addCustomMenuItems:hand: > > > > > > So...any thoughts on what should be in this menu? > > > > > > Take care, > > > > > > Rob > > > > > > 2009/3/21 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > > > probably > > > I see > > > > > > > > > > > > > > > On Mar 21, 2009, at 8:23 PM, Rob Rothwell wrote: > > > > > > Is this what you are talking about? What would you like instead? > > > What was the intent of the option-World click menu? > > > > > > Rob > > > > > > 2009/3/20 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > > > > > > > > > Begin forwarded message: > > > > > > From: pharo-project-owner(a)lists.gforge.inria.fr > > > Date: March 19, 2009 3:13:47 PM CEST > > > To: ducasse(a)iam.unibe.ch > > > Subject: Issue 668: should clean the option-World click menu > > > > > > You are not allowed to post to this mailing list, and your message > > has > > > been automatically rejected. If you think that your messages are > > > being rejected in error, contact the mailing list owner at > > > pharo-project-owner(a)lists.gforge.inria.fr. > > > > > > > > > > > > From: stÃ©phane ducasse <ducasse(a)iam.unibe.ch> > > > Date: March 19, 2009 3:13:40 PM CEST > > > To: Pharo Development <Pharo-project(a)lists.gforge.inria.fr> > > > Subject: Issue 668: should clean the option-World click menu > > > > > > > > > <star_on.gif> Issue 668: > > > should clean the option-World click menu > > > http://code.google.com/p/pharo/issues/detail?id=668 > > > Apparently option-click on the world brings a new menu (which points > > > to crappy stuff) and to the new pharo menu. > > > > > > > > > > > > _______________________________________________ > > > Pharo-project mailing list > > > Pharo-project(a)lists.gforge.inria.fr > > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > <OldWorldMenu.jpg>_______________________________________________ > > > 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 > > > > > > _______________________________________________ > > 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 22, 2009

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

by Antony Blakey

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

March 22, 2009

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

by Antony Blakey

On 23/03/2009, at 9:36 AM, Schwab,Wilhelm K wrote: > Semaphores and Mutexes are the lower level tools. **Critical > sections** implemented in terms of blocks are the fantastic part. I don't regard critical sections as particularly fantastic. > The little that I know about functional languages and their > immutable data structures suggests that a LOT of copying occurs. > That has to be expensive in terms of scheduling and memory footprint. A lot less than you might think, but this reminds me of the arguments people make against Smalltalk and Lisp. Old radicals become the new conservatives. Antony Blakey -------------------------- CTO, Linkuistics Pty Ltd Ph: 0438 840 787 The greatest challenge to any thinker is stating the problem in a way that will allow a solution -- Bertrand Russell

March 22, 2009

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

by Schwab,Wilhelm K

Semaphores and Mutexes are the lower level tools. **Critical sections** implemented in terms of blocks are the fantastic part. The little that I know about functional languages and their immutable data structures suggests that a LOT of copying occurs. That has to be expensive in terms of scheduling and memory footprint. Bill --- Wilhelm K. Schwab, Ph.D. bschwab AT anest DOT ufl DOT edu -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Antony Blakey Sent: Sunday, March 22, 2009 5:40 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Fwd: [vwnc] Would you start a new Smalltalk project today? On 23/03/2009, at 7:37 AM, Michael van der Gulik wrote: > Anybody who relies on the behaviour of the scheduler deserves to be > forced to program in BASIC. Semaphores work; use them. And they work with native threads, which was my point. A more pedantic answer to your response is that you take advantage of the scheduler all the time when considering priorities and atomicity, but I agree with the intent of your statement. > 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. Antony Blakey ------------- CTO, Linkuistics Pty Ltd Ph: 0438 840 787 There is nothing more difficult to plan, more doubtful of success, nor more dangerous to manage than the creation of a new order of things... Whenever his enemies have the ability to attack the innovator, they do so with the passion of partisans, while the others defend him sluggishly, So that the innovator and his party alike are vulnerable. -- Niccolo Machiavelli, 1513, The Prince. _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

March 22, 2009

Re: [Pharo-project] Pharo a VMs

by Mariano Martinez Peck

On Sat, Mar 21, 2009 at 5:46 AM, Alexandre Bergel <alexandre(a)bergel.eu>wrote: > All VM on which Squeak run may be safely used with Pharo. > This may change in the future with the introduction of closures. > Ok, and which VM can run safely squeak of those I said ? > > Cheers, > Alexandre > > On 20 Mar 2009, at 21:59, Mariano Martinez Peck wrote: > > > Hi men! > > > > I know very little about VMs but I have a very simple question, > > which vms are 100% compatibles with Pharo ? > > > > I know standard vm, cog, exupery and hydra. > > > > And which of them that are compatible with pharo is the most > > "performant" ? > > > > thanks, > > > > Mariano > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

March 22, 2009

Re: [Pharo-project] Clock icon when vm is buzy

by Mariano Martinez Peck

2009/3/22 Gary Chambers <gazzaguru2(a)btinternet.com> > This has to be done manually at the moment for things that may be > expected to take a while... > > Cursor wait showWhile: someBlock > Excellent! Thanks Gary > > Regards, Gary > > ----- Original Message ----- > *From:* Mariano Martinez Peck <marianopeck(a)gmail.com> > *To:* Pharo Development <pharo-project(a)lists.gforge.inria.fr> > *Sent:* Friday, March 20, 2009 3:10 PM > *Subject:* [Pharo-project] Clock icon when vm is buzy > > It would be nice to have a clock icon when the image is blocked doing > something and then disappear when it finished. What I have to do, to get > noticed when it terminates the block, is to click on another windows. So, > when the vm returns control, then I goes to the windows I pick, and there I > know. > > Is this possible to do? > > 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 22, 2009