October 2010 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Fwd: [squeak-dev] SharedQueue does scale (was: Re: SharedQueue doesn't scale)

by Schwab,Wilhelm K

I don't know if it's better (or even as good), but when the dust settles, it would be nice to have something _called_ SharedQueue that does what's expected of it and delegates to the improved classes. Another option would be to go through a deprecation period with SharedQueue. ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of StÃ©phane Ducasse [stephane.ducasse(a)inria.fr] Sent: Monday, October 18, 2010 9:26 AM To: Pharo Development Subject: [Pharo-project] Fwd: [squeak-dev] SharedQueue does scale (was: Re: SharedQueue doesn't scale) >>> >>> >> >> Thanks, Levente for giving a feedback. >> Please, feel free to shape my classes in more complete from (such as >> proper naming), >> to make them ready for inclusion in both Squeak's and Pharo cores. >> I propose the following names: >> AtomicQueue (base class) -> AtomicCollection >> FIFOQueue -> AtomicQueue >> LIFOQueue -> AtomicStack >> If you, or anyone else having better suggestions, speak now :) > > > Sounds like good names. > > >> In any case, i'm am open to discuss further details and possible >> caveats of using new classes >> to anyone interested in using them. >> >> P.S. As a side note, i now can explain (to myself at first place), why >> i intuitively choosed to used atomic swap >> instead of CAS. >> Because it fits better fits with smalltalk language semantics: >> >> A swap operation in smalltalk implemented as two assignments: >> x := y. y := z. >> An assignments is basic operation, which have nothing to do with >> late-bound nature of language. >> Unless we going to introduce a meta-object protocol(s), which could >> turn a simple assignment >> into some message sends under the hood, it will remain a basic, >> early-bound operation. >> And even if we do, it is highly unlikely, that even then we will throw >> away the old, >> simple assignment, which identifies an assignment source & target at >> compile time. >> >> In contrast, a CAS operation , if written in smalltalk looks like: >> >> (a == b ) ifTrue: [ a := c ] >> >> so, it having two message sends (#== , #ifTrue:), and from strict, >> pure language perspective, >> this using a late-bound semantics (a message sends), >> and as any message send, the message result and behavior cannot be >> predicted at compile time >> and therefore its wrong to assume that such statement could be an >> atomic operation. >> >> Unless, of course, we introduce a new language syntax which will >> denote a CAS operation explicitly. >> >>> >>> Levente >>> >>> >>> snip >>> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> > > > > _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 18, 2010

Re: [Pharo-project] [SPAM] Re: Speeding up Pharo 1.1

by Schwab,Wilhelm K

I doubt you will have trouble loading with SIXX, but ask if you do :) ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Bart Veenstra [bart.veenstra(a)gmail.com] Sent: Monday, October 18, 2010 7:54 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] [SPAM] Re: Speeding up Pharo 1.1 I haven't put my mind yet to loading the data, but I guess I will get this running pretty soon. For loading packages I will create a metacello configuratoin with all packages so I only need to load this once. (including seaside and other 3rd party tools) Regards, Bart 2010/10/18 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>: > I am not clear on upgrades, but I strongly urge establishing a process for saving and loading packages and data, otherwise you can end up trapped in a very old image. SIXX has done well for me so far with data. What don't you understand about loading? > > For saving and loading packages, I use a homegrown tool called Migrate; see the in box (and expect to ask some questions here) if you are interested. > > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Bart Veenstra [bart.veenstra(a)gmail.com] > Sent: Monday, October 18, 2010 3:48 AM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] [SPAM] Re: Speeding up Pharo 1.1 > > I would love to use a new image and reload all my apps, but I have > some important data in the image persisted, and I guess I would loose > these with a new image. I installed SIXX already for exporting. this > works. Now the importing part. > > Is there a way I can upgrade to 1.1.1 from 1.1? The software update > option doesn't do much. > > Regards, > > > Bart > > 2010/10/18 Sven Van Caekenberghe <sven(a)beta9.be>: >> >> On 18 Oct 2010, at 09:21, Bart Veenstra wrote: >> >>> After MCMethodDefinition shutDown it looks like it is reacting a bit >>> faster to keyboard input. I often experience sluggishness in >>> autocompletion method. When I type in a name of a class in a >>> workspace, the autocomplete suggests 3 options. I want to choose the >>> middle, so I press down and after 3 seconds (or sometimes nothging >>> happens) it selects the class. The longer I have my image open, the >>> longer this will take :S >> >> That is what I had before, see my earlier answer... >> >> Sven >> >> >> _______________________________________________ >> 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

Oct. 18, 2010

[Pharo-project] Fwd: [squeak-dev] SharedQueue does scale (was: Re: SharedQueue doesn't scale)

by StÃ©phane Ducasse

>>> >>> >> >> Thanks, Levente for giving a feedback. >> Please, feel free to shape my classes in more complete from (such as >> proper naming), >> to make them ready for inclusion in both Squeak's and Pharo cores. >> I propose the following names: >> AtomicQueue (base class) -> AtomicCollection >> FIFOQueue -> AtomicQueue >> LIFOQueue -> AtomicStack >> If you, or anyone else having better suggestions, speak now :) > > > Sounds like good names. > > >> In any case, i'm am open to discuss further details and possible >> caveats of using new classes >> to anyone interested in using them. >> >> P.S. As a side note, i now can explain (to myself at first place), why >> i intuitively choosed to used atomic swap >> instead of CAS. >> Because it fits better fits with smalltalk language semantics: >> >> A swap operation in smalltalk implemented as two assignments: >> x := y. y := z. >> An assignments is basic operation, which have nothing to do with >> late-bound nature of language. >> Unless we going to introduce a meta-object protocol(s), which could >> turn a simple assignment >> into some message sends under the hood, it will remain a basic, >> early-bound operation. >> And even if we do, it is highly unlikely, that even then we will throw >> away the old, >> simple assignment, which identifies an assignment source & target at >> compile time. >> >> In contrast, a CAS operation , if written in smalltalk looks like: >> >> (a == b ) ifTrue: [ a := c ] >> >> so, it having two message sends (#== , #ifTrue:), and from strict, >> pure language perspective, >> this using a late-bound semantics (a message sends), >> and as any message send, the message result and behavior cannot be >> predicted at compile time >> and therefore its wrong to assume that such statement could be an >> atomic operation. >> >> Unless, of course, we introduce a new language syntax which will >> denote a CAS operation explicitly. >> >>> >>> Levente >>> >>> >>> snip >>> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> > > > >

Oct. 18, 2010

[Pharo-project] [update 1.2] #12196

by StÃ©phane Ducasse

12196 ----- - Issue 3121: LongTest API improvement. - Issue 3120: MultiByteFileStream class>>lineEndDefault. - Issue 3119: rounded and truncated for DateAndTime. - Issue 3126: Cleans do: symbol usage

Oct. 18, 2010

Re: [Pharo-project] Implementing a Timer: "newProcessWith: anArray" fails

by Igor Stasenko

On 18 October 2010 14:55, nullPointer <epicfan(a)gmail.com> wrote: > > Now works :| > yes, but probably you found a Cog issue. > > pvtStartProcess > > Â Â Â Â internalProcess := [ self pvtCallProcess: self] fork. > > > > pvtGetNewProcessBlock > > Â Â Â Â ^[:timer || intervalDelay | > > Â Â Â Â Â Â Â Â [timer enabled] whileTrue:[ > > Â Â Â Â Â Â Â Â Â Â Â Â (Delay forMilliseconds: timer interval) wait. > > Â Â Â Â Â Â Â Â Â Â Â Â timer enabled ifTrue:[ > > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â timer raiseOnElapsedTimeForProcessThread: (timer getProcess). > > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â WorldState addDeferredUIMessage:[ > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â timer raiseOnElapsedTimeForUIThread: (timer getProcess) > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â ]. > Â Â Â Â Â Â Â Â Â Â Â Â ] > Â Â Â Â Â Â Â Â ]. > Â Â Â Â ]. > > > > pvtCallProcess: oneParam > > Â Â Â Â | processBlock | > > Â Â Â Â processBlock := self pvtGetNewProcessBlock. > Â Â Â Â processBlock value: oneParam. > > > Anyway I understand than the other way must be go. Something I did bad. > > Many thanks for the help > > > -- > View this message in context: http://forum.world.st/Implementing-a-Timer-newProcessWith-anArray-fails-tp2… > Sent from the Pharo Smalltalk mailing list archive at Nabble.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.

Oct. 18, 2010

Re: [Pharo-project] Implementing a Timer: "newProcessWith: anArray" fails

by nullPointer

Now works :| pvtStartProcess internalProcess := [ self pvtCallProcess: self] fork. pvtGetNewProcessBlock ^[:timer || intervalDelay | [timer enabled] whileTrue:[ (Delay forMilliseconds: timer interval) wait. timer enabled ifTrue:[ timer raiseOnElapsedTimeForProcessThread: (timer getProcess). WorldState addDeferredUIMessage:[ timer raiseOnElapsedTimeForUIThread: (timer getProcess) ]. ] ]. ]. pvtCallProcess: oneParam | processBlock | processBlock := self pvtGetNewProcessBlock. processBlock value: oneParam. Anyway I understand than the other way must be go. Something I did bad. Many thanks for the help -- View this message in context: http://forum.world.st/Implementing-a-Timer-newProcessWith-anArray-fails-tp2… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Oct. 18, 2010

Re: [Pharo-project] [SPAM] Re: Speeding up Pharo 1.1

by Bart Veenstra

I haven't put my mind yet to loading the data, but I guess I will get this running pretty soon. For loading packages I will create a metacello configuratoin with all packages so I only need to load this once. (including seaside and other 3rd party tools) Regards, Bart 2010/10/18 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>: > I am not clear on upgrades, but I strongly urge establishing a process for saving and loading packages and data, otherwise you can end up trapped in a very old image. Â SIXX has done well for me so far with data. Â What don't you understand about loading? > > For saving and loading packages, I use a homegrown tool called Migrate; see the in box (and expect to ask some questions here) if you are interested. > > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Bart Veenstra [bart.veenstra(a)gmail.com] > Sent: Monday, October 18, 2010 3:48 AM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] [SPAM] Re: Speeding up Pharo 1.1 > > I would love to use a new image and reload all my apps, but I have > some important data in the image persisted, and I guess I would loose > these with a new image. I installed SIXX already for exporting. this > works. Now the importing part. > > Is there a way I can upgrade to 1.1.1 from 1.1? The software update > option doesn't do much. > > Regards, > > > Bart > > 2010/10/18 Sven Van Caekenberghe <sven(a)beta9.be>: >> >> On 18 Oct 2010, at 09:21, Bart Veenstra wrote: >> >>> After MCMethodDefinition shutDown it looks like it is reacting a bit >>> faster to keyboard input. I often experience sluggishness in >>> autocompletion method. When I type in a name of a class in a >>> workspace, the autocomplete suggests 3 options. I want to choose the >>> middle, so I press down and after 3 seconds (or sometimes nothging >>> happens) it selects the class. The longer I have my image open, the >>> longer this will take :S >> >> That is what I had before, see my earlier answer... >> >> Sven >> >> >> _______________________________________________ >> 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 >

Oct. 18, 2010

Re: [Pharo-project] Implementing a Timer: "newProcessWith: anArray" fails

by nullPointer

The assert works good. processBlock numArgs. "returns 1 too" IÂ´m thinking perhaps the problem is Cog VM... itÂ´s possible? If I debug: block := [ :int1 | | int2 | int2 := 2. int1 + int2 ]. block newProcessWith: { 2 }. I get an SimulationGuardException exception... -- View this message in context: http://forum.world.st/Implementing-a-Timer-newProcessWith-anArray-fails-tp2… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Oct. 18, 2010

Re: [Pharo-project] [SPAM] Re: Speeding up Pharo 1.1

by Schwab,Wilhelm K

I am not clear on upgrades, but I strongly urge establishing a process for saving and loading packages and data, otherwise you can end up trapped in a very old image. SIXX has done well for me so far with data. What don't you understand about loading? For saving and loading packages, I use a homegrown tool called Migrate; see the in box (and expect to ask some questions here) if you are interested. ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Bart Veenstra [bart.veenstra(a)gmail.com] Sent: Monday, October 18, 2010 3:48 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] [SPAM] Re: Speeding up Pharo 1.1 I would love to use a new image and reload all my apps, but I have some important data in the image persisted, and I guess I would loose these with a new image. I installed SIXX already for exporting. this works. Now the importing part. Is there a way I can upgrade to 1.1.1 from 1.1? The software update option doesn't do much. Regards, Bart 2010/10/18 Sven Van Caekenberghe <sven(a)beta9.be>: > > On 18 Oct 2010, at 09:21, Bart Veenstra wrote: > >> After MCMethodDefinition shutDown it looks like it is reacting a bit >> faster to keyboard input. I often experience sluggishness in >> autocompletion method. When I type in a name of a class in a >> workspace, the autocomplete suggests 3 options. I want to choose the >> middle, so I press down and after 3 seconds (or sometimes nothging >> happens) it selects the class. The longer I have my image open, the >> longer this will take :S > > That is what I had before, see my earlier answer... > > Sven > > > _______________________________________________ > 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

Oct. 18, 2010

Re: [Pharo-project] Implementing a Timer: "newProcessWith: anArray" fails

by Igor Stasenko

It works for me: ([:foo | foo + 1 ] newProcessWith: #(10)) resume and ([:foo | foo + 1 ] newProcessWith: {10}) resume works as well. Try put self assert: processBlock argumentCount == 1 in pvtStartProcess. -- Best regards, Igor Stasenko AKA sig.

Oct. 18, 2010