- Pharo-dev - lists.pharo.org

[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

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

by Antony Blakey

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.

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: >> Green threads make some underlying implementation details easier, but >> at the language level the difference they make is determined by the >> interleaving guarantees they provide, and the extent to which the >> user >> can take advantage of those guarantees e.g. the yield-point model. >> >> IMO the solution to concurrency is not to simply add native threads - >> it also requires a more functional type of programming, and that can >> be largely provided by immutable data structures and more powerful >> abstractions, such as those provided in Clojure. > > can you illustrate that point? Immutable data makes concurrency easier because you avoid concurrent modification and eliminate synchronisation issues. Clojure adds data types with specific concurrency semantics. Here's some exposition: http://clojure.org/concurrent_programming > 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. > - 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

March 22, 2009

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

by Michael van der Gulik

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. Gulik. -- http://gulik.pbwiki.com/

March 22, 2009