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

Re: [Pharo-project] Could not merge changes... DNU

by Gary Chambers

Will have a look. Not encountered an organisation conflict before. You can, of course, select the conflict manually from the tree and choose from there... Regards, Gary ----- Original Message ----- From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> To: "Pharo Development" <Pharo-project(a)lists.gforge.inria.fr> Sent: Thursday, March 19, 2009 9:13 PM Subject: [Pharo-project] Could not merge changes... DNU > PSMCmergePatchMorph>>selectNextConflict > "Select the next conflict after the current selection, if any." > > |next def| > next := self nextConflict ifNil: [^self]. > def := next remoteDefinition ifNil: [next localDefinition]. > self changed: {#changes. #openPath. next targetClassName asString. > def selector asString} > > > def = a MCOrganizationDefinition(#(#'System-Object Events')) > and does not understand selector > > _______________________________________________ > 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] Starting to clean theWorldMainDockingBar

by StÃ©phane Ducasse

The project invokes it but when I recompile a method the bar is recreated so probably using the change notification system updateIfNeeded: aDockingBar "Update the given docking bar if needed" | timeStamp | timeStamp := aDockingBar valueOfProperty: #mainDockingBarTimeStamp ifAbsent: [^ self]. timeStamp = self class timeStamp ifTrue: [^ self]. "" aDockingBar removeAllMorphs. self fillDockingBar: aDockingBar On Mar 22, 2009, at 3:10 PM, StÃ©phane Ducasse wrote: > am i correct that the dockingBar is redrawing itself continously? > I would be curious to understand the execution cost of this feature. > > stef > > On Mar 22, 2009, at 12:01 PM, StÃ©phane Ducasse wrote: > >> http://code.google.com/p/pharo/issues/detail?id=683 >> Started to remove reference to project....long effort though >> >> Stef >> >> _______________________________________________ >> 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] Starting to clean theWorldMainDockingBar

by StÃ©phane Ducasse

am i correct that the dockingBar is redrawing itself continously? I would be curious to understand the execution cost of this feature. stef On Mar 22, 2009, at 12:01 PM, StÃ©phane Ducasse wrote: > http://code.google.com/p/pharo/issues/detail?id=683 > Started to remove reference to project....long effort though > > Stef > > _______________________________________________ > 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 StÃ©phane Ducasse

On Mar 22, 2009, at 12:49 PM, Antony Blakey wrote: > > On 22/03/2009, at 9:48 PM, Igor Stasenko wrote: > >> Sorry, my fault. You need to sync in both cases (even with green >> threads). > > 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? 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) - I was wondering if the object that you put such immutable data structure should also be immutable > > I'm not suggesting adding native threads to Squeak. Squeak is quite a > minefield as it is. I think it's time for a new model of Smalltalk > that includes native threads from the get-go, and is a rethinking of > the Smalltalk tradition, in the same way that Clojure is a rethinking > of the Lisp tradition. The parallels between Lisp and Smalltalk, in > terms of their paradigmatic roles, market issues, and communities, is > quite striking. Why should these two powerhouses of beautiful > programming not *both* be reborn. Can you tell a word on clojure? Stef > > >> There is another problem, that squeak processes is cheap (few bytes >> in >> object memory), while allocating new native thread consumes >> considerable amount of memory & address space. So, if you map >> Processes to native threads, you will lose the ability in having >> millions of them, instead you will be limited to thousands. > > You don't need a 1:1 mapping. You can use a native thread pool to > execute lightweight threads. Erlang manages with huge numbers of > language level processes. > > Antony Blakey > -------------------------- > CTO, Linkuistics Pty Ltd > Ph: 0438 840 787 > > It is as useless to argue with those who have renounced the use of > reason as to administer medication to the dead. > -- Thomas Jefferson > > > > _______________________________________________ > 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] Starting to clean theWorldMainDockingBar

by Rob Rothwell

Yes...I have fixed up the FileList reference one or two times before. I am still looking for where the Option-Click World menu is built... Rob On Sun, Mar 22, 2009 at 7:01 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > http://code.google.com/p/pharo/issues/detail?id=683 > Started to remove reference to project....long effort though > > Stef > > _______________________________________________ > 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 22/03/2009, at 9:48 PM, Igor Stasenko wrote: > Sorry, my fault. You need to sync in both cases (even with green > threads). 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. I'm not suggesting adding native threads to Squeak. Squeak is quite a minefield as it is. I think it's time for a new model of Smalltalk that includes native threads from the get-go, and is a rethinking of the Smalltalk tradition, in the same way that Clojure is a rethinking of the Lisp tradition. The parallels between Lisp and Smalltalk, in terms of their paradigmatic roles, market issues, and communities, is quite striking. Why should these two powerhouses of beautiful programming not *both* be reborn. > There is another problem, that squeak processes is cheap (few bytes in > object memory), while allocating new native thread consumes > considerable amount of memory & address space. So, if you map > Processes to native threads, you will lose the ability in having > millions of them, instead you will be limited to thousands. You don't need a 1:1 mapping. You can use a native thread pool to execute lightweight threads. Erlang manages with huge numbers of language level processes. Antony Blakey -------------------------- CTO, Linkuistics Pty Ltd Ph: 0438 840 787 It is as useless to argue with those who have renounced the use of reason as to administer medication to the dead. -- Thomas Jefferson

March 22, 2009

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

by Igor Stasenko

2009/3/22 Igor Stasenko <siguctua(a)gmail.com>: > 2009/3/22 Michael van der Gulik <mikevdg(a)gmail.com>: >> >> >> On Sat, Mar 21, 2009 at 8:38 AM, Janko MivÅ¡ek <janko.mivsek(a)eranova.si> >> wrote: >>> >>> Philippe Marschall pravi: >>> >> Michael van der Gulik wrote: >>> >>> >> So now it seems that Gemstone is the only multi-core capable Smalltalk >>> >> VM :-(. >>> >>> > AFAIK Gemstone isn't multi-core capable as well. You can just run >>> > multiple gems and they share the same persistent memory. Which is >>> > similar but different. >>> >>> Well, Gemstone can for sure be considered as multi-core capable. Every >>> gem runs on its own process and therefore can run on its own CPU core. >>> All gems then share a Shared Memory Cache. So, a typical multi-core >>> scenario. >>> >> By multi-core, I mean that the following code would spread CPU usage over at >> least two cores of a CPU or computer for a while: >> >> | sum1 sum2 | >> >> sum1 := 0. sum2 := 0. >> >> [ 1 to: 10000000 do: [ :i | sum1 := sum1 + 1 ] ] fork. >> >> [ 1 to: 10000000 do: [ :i | sum2 := sum2 + 1 ] ] fork. >> >> (I didn't try the above so there might be obvious bugs) >> >> If a VM can't distribute the load for the above over two or more CPU cores, >> I consider its multi-core capabilities a hack. No offense intended to the >> Hydra VM. >> > > Michael, that's would be too ideal to be true, especially for smalltalk. > > Consider the following: > > | array sum1 sum2 | > > sum1 := 0. sum2 := 0. > array := Array new: 10. > > [ 1 to: 10000000 do: [ :i | array at: (10 random) put: (Array new: 10) ] ] fork. > [ 1 to: 10000000 do: [ :i | array at: (10 random) put: (Array new: 10) ] ] fork. > 1 to: 10000000 do: [ :i | array at: (10 random) put: (Array new: 10) ]. > > This code reveals the following problems: > - concurrent access to same object > - a heavy memory allocation during running 3 processes, which at some > point should cause GC. > While first is more or less on the hands of developer (write a proper > code to avoid such things), but second is a problem that you need to > solve to be able to collect garbage in real time , when there are > multiple threads producing it. > > Another problem, which will force you to rewrite many things in > smalltalk code base, is problems with concurrent access to complex > collections such as ordered collections, streams & dictionaries: > | dict | > dict := Dictionary new. > [ 10000 timesRepeat: [ dict at: (1000000 random) put: 1 ]] fork. > [ 10000 timesRepeat: [ dict at: (1000000 random) put: 1 ]] fork. > > at some point dictionary would require rehashing, but there are > another thread which constantly putting new values in it. Obviously, > access to dictionary should be synchronized to avoid conflicts. > And synchronized access to collection(s) ( semaphore critical: [] ) > makes them really slow, which scales very poorly on multiple cores. > The code above will take more time to complete comparing to same code > when running in single native thread (green threading model), because > you don't have to deal with synchronization. > Sorry, my fault. You need to sync in both cases (even with green threads). But what strikes me, that there are a lot of code, which never cares about it, for instance see Symbol class>> intern: and in some magical fashion it works w/o problems in green threading.. i'm not sure it will continue running when you enable multiple native threads. There is another problem, that squeak processes is cheap (few bytes in object memory), while allocating new native thread consumes considerable amount of memory & address space. So, if you map Processes to native threads, you will lose the ability in having millions of them, instead you will be limited to thousands. > >> I'm feeling a bit disheartened by the fact that there aren't any Smalltalk >> VMs, commercial or not, that can do fine-grained parallelism. >> >> 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. > -- Best regards, Igor Stasenko AKA sig.

March 22, 2009

[Pharo-project] Starting to clean theWorldMainDockingBar

by StÃ©phane Ducasse

http://code.google.com/p/pharo/issues/detail?id=683 Started to remove reference to project....long effort though Stef

March 22, 2009

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

by Igor Stasenko

2009/3/22 Michael van der Gulik <mikevdg(a)gmail.com>: > > > On Sat, Mar 21, 2009 at 8:38 AM, Janko MivÅ¡ek <janko.mivsek(a)eranova.si> > wrote: >> >> Philippe Marschall pravi: >> >> Michael van der Gulik wrote: >> >> >> So now it seems that Gemstone is the only multi-core capable Smalltalk >> >> VM :-(. >> >> > AFAIK Gemstone isn't multi-core capable as well. You can just run >> > multiple gems and they share the same persistent memory. Which is >> > similar but different. >> >> Well, Gemstone can for sure be considered as multi-core capable. Every >> gem runs on its own process and therefore can run on its own CPU core. >> All gems then share a Shared Memory Cache. So, a typical multi-core >> scenario. >> > By multi-core, I mean that the following code would spread CPU usage over at > least two cores of a CPU or computer for a while: > > | sum1 sum2 | > > sum1 := 0. sum2 := 0. > > [ 1 to: 10000000 do: [ :i | sum1 := sum1 + 1 ] ] fork. > > [ 1 to: 10000000 do: [ :i | sum2 := sum2 + 1 ] ] fork. > > (I didn't try the above so there might be obvious bugs) > > If a VM can't distribute the load for the above over two or more CPU cores, > I consider its multi-core capabilities a hack. No offense intended to the > Hydra VM. > Michael, that's would be too ideal to be true, especially for smalltalk. Consider the following: | array sum1 sum2 | sum1 := 0. sum2 := 0. array := Array new: 10. [ 1 to: 10000000 do: [ :i | array at: (10 random) put: (Array new: 10) ] ] fork. [ 1 to: 10000000 do: [ :i | array at: (10 random) put: (Array new: 10) ] ] fork. 1 to: 10000000 do: [ :i | array at: (10 random) put: (Array new: 10) ]. This code reveals the following problems: - concurrent access to same object - a heavy memory allocation during running 3 processes, which at some point should cause GC. While first is more or less on the hands of developer (write a proper code to avoid such things), but second is a problem that you need to solve to be able to collect garbage in real time , when there are multiple threads producing it. Another problem, which will force you to rewrite many things in smalltalk code base, is problems with concurrent access to complex collections such as ordered collections, streams & dictionaries: | dict | dict := Dictionary new. [ 10000 timesRepeat: [ dict at: (1000000 random) put: 1 ]] fork. [ 10000 timesRepeat: [ dict at: (1000000 random) put: 1 ]] fork. at some point dictionary would require rehashing, but there are another thread which constantly putting new values in it. Obviously, access to dictionary should be synchronized to avoid conflicts. And synchronized access to collection(s) ( semaphore critical: [] ) makes them really slow, which scales very poorly on multiple cores. The code above will take more time to complete comparing to same code when running in single native thread (green threading model), because you don't have to deal with synchronization. > I'm feeling a bit disheartened by the fact that there aren't any Smalltalk > VMs, commercial or not, that can do fine-grained parallelism. > > 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] [ANN] 10259 : ProjectHistoryRemoval

by StÃ©phane Ducasse

ProjectHistory is now out. Some of its friends will be in the radar too. Stef

March 22, 2009