January 2016 - Pharo-dev - lists.pharo.org

Changing performance balance between CPU & non-volatile storage

by Ben Coman

An enlightening article (if a bit long). I wonder how non-volatile storage being faster than a CPU might affect Pharo systems. Perhaps the importance of migrating between live and backup Images gains in importance to backups via files. https://queue.acm.org/detail.cfm?id=2874238 cheers -ben

Jan. 7, 2016

Re: [Pharo-dev] [Vm-dev] Where to get Monitor implementation based on primitives?

by Eliot Miranda

Hi Ben, On Thu, Jan 7, 2016 at 10:39 AM, Ben Coman <btc(a)openinworld.com> wrote: > > On Fri, Jan 8, 2016 at 1:20 AM, Eliot Miranda <eliot.miranda(a)gmail.com> > wrote: > > > > and here's a version with a better class comment > > > > On Thu, Jan 7, 2016 at 9:12 AM, Eliot Miranda <eliot.miranda(a)gmail.com> > wrote: > >> > >> Hi Denis, Hi ClÃ©ment, Hi Frank, > >> > >> On Thu, Jan 7, 2016 at 5:34 AM, ClÃ©ment Bera <bera.clement(a)gmail.com> > wrote: > >>> > >>> Hello, > >>> > >>> Eliot, please, you told me you had the code and Denis is interested. > >>> > >>> It uses 3 primitives for performance. > >> > >> > >> Forgive the delay. I thought it proper to ask permission since the > code was written while I was at Qwaq. I'm attaching the code in a fairly > raw state, see the attached. The code is MIT, but copyright 3DICC. > >> > >> It is a plugin replacement for Squeak's Mutex, and with a little > ingenuity could be a replacement for Squeak's Monitor. It is quicker > because it uses three new primitives to manage entering a critical section > and setting the owner, exiting the critical section and releasing the > owner, and testing if a critical section, entering if the section is > unowned. The use of the primitives means fewer block activations and > ensure: blocks in entering and exiting the critical section, and that's the > actual cause of the speed-up. > >> > >> You can benchmark the code as is. Here are some results on 32-bit > Spur, on my 2.2GHz Core i7 > >> > >> {Mutex new. Monitor new. CriticalSection new} collect: > >> [:cs| | n | > >> n := 0. > >> [cs critical: [n := n + 1]. cs critical: [n := n + 1]. cs critical: [n > := n + 1]. cs critical: [n := n + 1]. cs critical: [n := n + 1]. > >> cs critical: [n := n - 1]. cs critical: [n := n - 1]. cs critical: [n > := n - 1]. cs critical: [n := n - 1]. cs critical: [n := n - 1]. > >> n ] bench] > >> > >> {Mutex new. Monitor new. CriticalSection new} collect: > >> [:cs| | n | > >> n := 0. > >> cs class name, ' -> ', > >> [cs critical: [n := n + 1]. cs critical: [n := n + 1]. cs critical: [n > := n + 1]. cs critical: [n := n + 1]. cs critical: [n := n + 1]. > >> cs critical: [n := n - 1]. cs critical: [n := n - 1]. cs critical: [n > := n - 1]. cs critical: [n := n - 1]. cs critical: [n := n - 1]. > >> n ] bench] > >> > >> #( 'Mutex -> 440,000 per second. 2.27 microseconds per run.' > >> 'Monitor -> 688,000 per second. 1.45 microseconds per run.' > >> 'CriticalSection -> 1,110,000 per second. 900 nanoseconds per run.') > >> > > This is great Eliot. Thank you and 3DICC. After loading the changeset > into Pharo-50515 (32 bit Spur) I get the following results on my > laptop i5-2520M @ 2.50GHz > > #('Mutex -> 254,047 per second' > 'Monitor -> 450,442 per second' > 'CriticalSection -> 683,393 per second') > > In a fresh Image "Mutex allInstances basicInspect" lists just two > mutexes... > 1. NetNameResolver-->ResolverMutex > 2. ThreadSafeTranscript-->accessSemaphore > I hate myself for getting distracted but I'm finding this is un. One can migrate to the new representation using normal Monticello loads by In the first version redefine Mutex and Monitor to subclass LinkedList and have their owner/ownerProcess inst var first (actually third after firstLink & lastLink), and add the primitives. In the next version check that all Mutex and Monitor instanes are unowned and then redefine to discard excess inst vars Let me test this before committing, and see that all tests are ok. > cheers -ben > > >> Replacement is probably trivial; rename Mutex to OldMutex, rename > CriticalSection to Mutex, recompile. But there are lots of mutexes in the > system and these are potentially owned. Transforming unowned ones is > trivial, but transforming owned ones is, I think, impossible. But at least > in my system there are no owned mutexes or monitors. > >> > >> Frank (or anyone else), would you be interested in creating a > replacement for Squeak's Monitor based on CriticalSection? > >> > >> > >> Here are the two business methods: > >> CriticalSection methods for mutual exclusion > >> critical: aBlock > >> "Evaluate aBlock protected by the receiver." > >> ^self primitiveEnterCriticalSection > >> ifTrue: [aBlock value] > >> ifFalse: [aBlock ensure: [self primitiveExitCriticalSection]] > >> > >> critical: aBlock ifLocked: lockedBlock > >> "Answer the evaluation of aBlock protected by the receiver. If it is > already in a critical > >> section on behalf of some other process answer the evaluation of > lockedBlock." > >> ^self primitiveTestAndSetOwnershipOfCriticalSection > >> ifNil: [lockedBlock value] > >> ifNotNil:[:alreadyOwner| > >> alreadyOwner > >> ifTrue: [aBlock value] > >> ifFalse: [aBlock ensure: [self primitiveExitCriticalSection]]] > >> > >> and the primitives: > >> CriticalSection methods for private-primitives > >> primitiveEnterCriticalSection > >> "Primitive. The receiver must be unowned or owned by the current > process to proceed. > >> Answer if the process is owned by the current process." > >> <primitive: 186> > >> self primitiveFailed > >> "In the spirit of the following" > >> "[owner ifNil: > >> [owner := Processor activeProcess. > >> ^false]. > >> owner = Processor activeProcess ifTrue: > >> [^true]. > >> self addLast: Processor activeProcess. > >> Processor activeProcess suspend] valueUnpreemptively" > >> > >> primitiveExitCriticalSection > >> "Primitive. Set te receiver to unowned and if any processes are waiting > on > >> the receiver then proceed the first one, indicating that the receiver > is unowned." > >> <primitive: 185> > >> self primitiveFailed > >> "In the spirit of the following" > >> "[owner := nil. > >> self isEmpty ifFalse: > >> [process := self removeFirst. > >> process resume]] valueUnpreemptively" > >> > >> primitiveTestAndSetOwnershipOfCriticalSection > >> "Primitive. Attempt to set the ownership of the receiver. > >> If the receiver is unowned set its owningProcess to the > >> activeProcess and answer false. If the receiver is owned > >> by the activeProcess answer true. If the receiver is owned > >> by some other process answer nil." > >> <primitive: 187> > >> self primitiveFail > >> "In the spirit of the following" > >> "[owner ifNil: > >> [owningProcess := Processor activeProcess. > >> ^false]. > >> owner = Processor activeProcess ifTrue: [^true]. > >> ^nil] valueUnpreemptively" > >> > >>> 2016-01-07 13:24 GMT+01:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > >>>> > >>>> > >>>> Hello. > >>>> > >>>> I hear about new Monitor implementation based on new primitives. > >>>> Where to get it? > >> > >> > >> _,,,^..^,,,_ > >> best, Eliot > > > > > > > > > > -- > > _,,,^..^,,,_ > > best, Eliot > > > -- _,,,^..^,,,_ best, Eliot

Jan. 7, 2016

Re: [Pharo-dev] [ANN] I created a web page so you can stalk me :)

by Dimitris Chloupis

first to comment, aha !!! :D On Thu, Jan 7, 2016 at 7:50 PM Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > Nice! > > However I wouldn't say you're not visible in the community. ;-) > > Esteban A. Maringolo > > > 2016-01-07 14:21 GMT-03:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > > > > On 07 Jan 2016, at 18:18, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > > > Hi, > > > > Stef told me I need to make a bit more visibility my work, and while > being > > in Togo I sketched an application I tested last few days and seems to be > > working fina. > > Of course, easiest way would be to use twitter as a work log, but I was > not > > satisfied with the idea. Why? wellâ¦ some reasons are explained in the > source > > page: > > > > - You can add formatting using pillar > > - You do not have 140 characters max (probably you will not need much > more, > > but anyway, the limitation is annoying :P) > > - You can disqus (http://disqus.com) posts. > > - Posts are interpreted and links are detected and listed (so is easy to > > find them) > > - Since is made for my own work, it understand links like *case:12345* > as a > > link to pharo fogbugz case 12345. > > - It has a command line! > > > > but another reason was because I wanted to try it (and I was bored in > Togo > > waiting for the planes) > > I donât know how this experiment will work, but letâs give it a try :) > > > > http://log.smallworks.eu > > http://log.smallworks.eu/rss (you can suscribe with your reader, so you > do > > not need to go to the page) > > https://github.com/estebanlm/worklog > > > > Enjoy stalking me :) > > > > Esteban > > > > > > btw is very possible that you took it downâ¦ I never tested with other > than > > my self. > > â¦ this is running in Pharo 5 with spur (I wanted to test stability too) > :P > > > > Esteban > > > >

Jan. 7, 2016

Re: [Pharo-dev] [ANN] I created a web page so you can stalk me :)

by Esteban A. Maringolo

Nice! However I wouldn't say you're not visible in the community. ;-) Esteban A. Maringolo 2016-01-07 14:21 GMT-03:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > > On 07 Jan 2016, at 18:18, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > Hi, > > Stef told me I need to make a bit more visibility my work, and while being > in Togo I sketched an application I tested last few days and seems to be > working fina. > Of course, easiest way would be to use twitter as a work log, but I was not > satisfied with the idea. Why? wellâ¦ some reasons are explained in the source > page: > > - You can add formatting using pillar > - You do not have 140 characters max (probably you will not need much more, > but anyway, the limitation is annoying :P) > - You can disqus (http://disqus.com) posts. > - Posts are interpreted and links are detected and listed (so is easy to > find them) > - Since is made for my own work, it understand links like *case:12345* as a > link to pharo fogbugz case 12345. > - It has a command line! > > but another reason was because I wanted to try it (and I was bored in Togo > waiting for the planes) > I donât know how this experiment will work, but letâs give it a try :) > > http://log.smallworks.eu > http://log.smallworks.eu/rss (you can suscribe with your reader, so you do > not need to go to the page) > https://github.com/estebanlm/worklog > > Enjoy stalking me :) > > Esteban > > > btw is very possible that you took it downâ¦ I never tested with other than > my self. > â¦ this is running in Pharo 5 with spur (I wanted to test stability too) :P > > Esteban >

Jan. 7, 2016

Re: [Pharo-dev] [ANN] I created a web page so you can stalk me :)

by Esteban Lorenzano

> On 07 Jan 2016, at 18:18, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > Hi, > > Stef told me I need to make a bit more visibility my work, and while being in Togo I sketched an application I tested last few days and seems to be working fina. > Of course, easiest way would be to use twitter as a work log, but I was not satisfied with the idea. Why? wellâ¦ some reasons are explained in the source page: > > - You can add formatting using pillar > - You do not have 140 characters max (probably you will not need much more, but anyway, the limitation is annoying :P) > - You can disqus (http://disqus.com <http://disqus.com/>) posts. > - Posts are interpreted and links are detected and listed (so is easy to find them) > - Since is made for my own work, it understand links like *case:12345* as a link to pharo fogbugz case 12345. > - It has a command line! > > but another reason was because I wanted to try it (and I was bored in Togo waiting for the planes) > I donât know how this experiment will work, but letâs give it a try :) > > http://log.smallworks.eu <http://log.smallworks.eu/> > http://log.smallworks.eu/rss <http://log.smallworks.eu/rss> (you can suscribe with your reader, so you do not need to go to the page) > https://github.com/estebanlm/worklog <https://github.com/estebanlm/worklog> > > Enjoy stalking me :) > > Esteban > btw is very possible that you took it downâ¦ I never tested with other than my self. â¦ this is running in Pharo 5 with spur (I wanted to test stability too) :P Esteban

Jan. 7, 2016

Re: [Pharo-dev] [Vm-dev] Where to get Monitor implementation based on primitives?

by Eliot Miranda

and here's a version with a better class comment On Thu, Jan 7, 2016 at 9:12 AM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > Hi Denis, Hi ClÃ©ment, Hi Frank, > > On Thu, Jan 7, 2016 at 5:34 AM, ClÃ©ment Bera <bera.clement(a)gmail.com> > wrote: > >> Hello, >> >> Eliot, please, you told me you had the code and Denis is interested. >> >> It uses 3 primitives for performance. >> > > Forgive the delay. I thought it proper to ask permission since the code > was written while I was at Qwaq. I'm attaching the code in a fairly raw > state, see the attached. The code is MIT, but copyright 3DICC. > > It is a plugin replacement for Squeak's Mutex, and with a little ingenuity > could be a replacement for Squeak's Monitor. It is quicker because it uses > three new primitives to manage entering a critical section and setting the > owner, exiting the critical section and releasing the owner, and testing if > a critical section, entering if the section is unowned. The use of the > primitives means fewer block activations and ensure: blocks in entering and > exiting the critical section, and that's the actual cause of the speed-up. > > You can benchmark the code as is. Here are some results on 32-bit Spur, > on my 2.2GHz Core i7 > > {Mutex new. Monitor new. CriticalSection new} collect: > [:cs| | n | > n := 0. > [cs critical: [n := n + 1]. cs critical: [n := n + 1]. cs critical: [n := > n + 1]. cs critical: [n := n + 1]. cs critical: [n := n + 1]. > cs critical: [n := n - 1]. cs critical: [n := n - 1]. cs critical: [n := n > - 1]. cs critical: [n := n - 1]. cs critical: [n := n - 1]. > n ] bench] > > {Mutex new. Monitor new. CriticalSection new} collect: > [:cs| | n | > n := 0. > cs class name, ' -> ', > [cs critical: [n := n + 1]. cs critical: [n := n + 1]. cs critical: [n := > n + 1]. cs critical: [n := n + 1]. cs critical: [n := n + 1]. > cs critical: [n := n - 1]. cs critical: [n := n - 1]. cs critical: [n := n > - 1]. cs critical: [n := n - 1]. cs critical: [n := n - 1]. > n ] bench] > > #( 'Mutex -> 440,000 per second. 2.27 microseconds per run.' > 'Monitor -> 688,000 per second. 1.45 microseconds per run.' > 'CriticalSection -> 1,110,000 per second. 900 nanoseconds per run.') > > Replacement is probably trivial; rename Mutex to OldMutex, rename > CriticalSection to Mutex, recompile. But there are lots of mutexes in the > system and these are potentially owned. Transforming unowned ones is > trivial, but transforming owned ones is, I think, impossible. But at least > in my system there are no owned mutexes or monitors. > > Frank (or anyone else), would you be interested in creating a replacement > for Squeak's Monitor based on CriticalSection? > > > Here are the two business methods: > *CriticalSection methods for mutual exclusion* > *critical:* aBlock > "Evaluate aBlock protected by the receiver." > ^self primitiveEnterCriticalSection > ifTrue: [aBlock value] > ifFalse: [aBlock ensure: [self primitiveExitCriticalSection]] > > *critical:* aBlock *ifLocked:* lockedBlock > "*Answer the evaluation of aBlock protected by the receiver. If it is > already in a critical* > * section on behalf of some other process answer the evaluation of > lockedBlock.*" > ^self primitiveTestAndSetOwnershipOfCriticalSection > ifNil: [lockedBlock value] > ifNotNil:[:alreadyOwner| > alreadyOwner > ifTrue: [aBlock value] > ifFalse: [aBlock ensure: [self primitiveExitCriticalSection]]] > > and the primitives: > *CriticalSection methods for private-primitives* > *primitiveEnterCriticalSection* > "Primitive. The receiver must be unowned or owned by the current process > to proceed. > Answer if the process is owned by the current process." > <primitive: 186> > self primitiveFailed > "In the spirit of the following" > "[owner ifNil: > [owner := Processor activeProcess. > ^false]. > owner = Processor activeProcess ifTrue: > [^true]. > self addLast: Processor activeProcess. > Processor activeProcess suspend] valueUnpreemptively" > > *primitiveExitCriticalSection* > "Primitive. Set te receiver to unowned and if any processes are waiting on > the receiver then proceed the first one, indicating that the receiver is > unowned." > <primitive: 185> > self primitiveFailed > "In the spirit of the following" > "[owner := nil. > self isEmpty ifFalse: > [process := self removeFirst. > process resume]] valueUnpreemptively" > > *primitiveTestAndSetOwnershipOfCriticalSection* > "Primitive. Attempt to set the ownership of the receiver. > If the receiver is unowned set its owningProcess to the > activeProcess and answer false. If the receiver is owned > by the activeProcess answer true. If the receiver is owned > by some other process answer nil." > <primitive: 187> > self primitiveFail > "In the spirit of the following" > "[owner ifNil: > [owningProcess := Processor activeProcess. > ^false]. > owner = Processor activeProcess ifTrue: [^true]. > ^nil] valueUnpreemptively" > > 2016-01-07 13:24 GMT+01:00 Denis Kudriashov <dionisiydk(a)gmail.com>: >> >>> >>> Hello. >>> >>> I hear about new Monitor implementation based on new primitives. >>> Where to get it? >>> >> > _,,,^..^,,,_ > best, Eliot > -- _,,,^..^,,,_ best, Eliot

Jan. 7, 2016

[ANN] I created a web page so you can stalk me :)

by Esteban Lorenzano

Hi, Stef told me I need to make a bit more visibility my work, and while being in Togo I sketched an application I tested last few days and seems to be working fina. Of course, easiest way would be to use twitter as a work log, but I was not satisfied with the idea. Why? wellâ¦ some reasons are explained in the source page: - You can add formatting using pillar - You do not have 140 characters max (probably you will not need much more, but anyway, the limitation is annoying :P) - You can disqus (http://disqus.com) posts. - Posts are interpreted and links are detected and listed (so is easy to find them) - Since is made for my own work, it understand links like *case:12345* as a link to pharo fogbugz case 12345. - It has a command line! but another reason was because I wanted to try it (and I was bored in Togo waiting for the planes) I donât know how this experiment will work, but letâs give it a try :) http://log.smallworks.eu <http://log.smallworks.eu/> http://log.smallworks.eu/rss <http://log.smallworks.eu/rss> (you can suscribe with your reader, so you do not need to go to the page) https://github.com/estebanlm/worklog <https://github.com/estebanlm/worklog> Enjoy stalking me :) Esteban

Jan. 7, 2016

Re: [Pharo-dev] [Vm-dev] Where to get Monitor implementation based on primitives?

by Eliot Miranda

Hi Denis, Hi ClÃ©ment, Hi Frank, On Thu, Jan 7, 2016 at 5:34 AM, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > Hello, > > Eliot, please, you told me you had the code and Denis is interested. > > It uses 3 primitives for performance. > Forgive the delay. I thought it proper to ask permission since the code was written while I was at Qwaq. I'm attaching the code in a fairly raw state, see the attached. The code is MIT, but copyright 3DICC. It is a plugin replacement for Squeak's Mutex, and with a little ingenuity could be a replacement for Squeak's Monitor. It is quicker because it uses three new primitives to manage entering a critical section and setting the owner, exiting the critical section and releasing the owner, and testing if a critical section, entering if the section is unowned. The use of the primitives means fewer block activations and ensure: blocks in entering and exiting the critical section, and that's the actual cause of the speed-up. You can benchmark the code as is. Here are some results on 32-bit Spur, on my 2.2GHz Core i7 {Mutex new. Monitor new. CriticalSection new} collect: [:cs| | n | n := 0. [cs critical: [n := n + 1]. cs critical: [n := n + 1]. cs critical: [n := n + 1]. cs critical: [n := n + 1]. cs critical: [n := n + 1]. cs critical: [n := n - 1]. cs critical: [n := n - 1]. cs critical: [n := n - 1]. cs critical: [n := n - 1]. cs critical: [n := n - 1]. n ] bench] {Mutex new. Monitor new. CriticalSection new} collect: [:cs| | n | n := 0. cs class name, ' -> ', [cs critical: [n := n + 1]. cs critical: [n := n + 1]. cs critical: [n := n + 1]. cs critical: [n := n + 1]. cs critical: [n := n + 1]. cs critical: [n := n - 1]. cs critical: [n := n - 1]. cs critical: [n := n - 1]. cs critical: [n := n - 1]. cs critical: [n := n - 1]. n ] bench] #( 'Mutex -> 440,000 per second. 2.27 microseconds per run.' 'Monitor -> 688,000 per second. 1.45 microseconds per run.' 'CriticalSection -> 1,110,000 per second. 900 nanoseconds per run.') Replacement is probably trivial; rename Mutex to OldMutex, rename CriticalSection to Mutex, recompile. But there are lots of mutexes in the system and these are potentially owned. Transforming unowned ones is trivial, but transforming owned ones is, I think, impossible. But at least in my system there are no owned mutexes or monitors. Frank (or anyone else), would you be interested in creating a replacement for Squeak's Monitor based on CriticalSection? Here are the two business methods: *CriticalSection methods for mutual exclusion* *critical:* aBlock "Evaluate aBlock protected by the receiver." ^self primitiveEnterCriticalSection ifTrue: [aBlock value] ifFalse: [aBlock ensure: [self primitiveExitCriticalSection]] *critical:* aBlock *ifLocked:* lockedBlock "*Answer the evaluation of aBlock protected by the receiver. If it is already in a critical* * section on behalf of some other process answer the evaluation of lockedBlock.*" ^self primitiveTestAndSetOwnershipOfCriticalSection ifNil: [lockedBlock value] ifNotNil:[:alreadyOwner| alreadyOwner ifTrue: [aBlock value] ifFalse: [aBlock ensure: [self primitiveExitCriticalSection]]] and the primitives: *CriticalSection methods for private-primitives* *primitiveEnterCriticalSection* "Primitive. The receiver must be unowned or owned by the current process to proceed. Answer if the process is owned by the current process." <primitive: 186> self primitiveFailed "In the spirit of the following" "[owner ifNil: [owner := Processor activeProcess. ^false]. owner = Processor activeProcess ifTrue: [^true]. self addLast: Processor activeProcess. Processor activeProcess suspend] valueUnpreemptively" *primitiveExitCriticalSection* "Primitive. Set te receiver to unowned and if any processes are waiting on the receiver then proceed the first one, indicating that the receiver is unowned." <primitive: 185> self primitiveFailed "In the spirit of the following" "[owner := nil. self isEmpty ifFalse: [process := self removeFirst. process resume]] valueUnpreemptively" *primitiveTestAndSetOwnershipOfCriticalSection* "Primitive. Attempt to set the ownership of the receiver. If the receiver is unowned set its owningProcess to the activeProcess and answer false. If the receiver is owned by the activeProcess answer true. If the receiver is owned by some other process answer nil." <primitive: 187> self primitiveFail "In the spirit of the following" "[owner ifNil: [owningProcess := Processor activeProcess. ^false]. owner = Processor activeProcess ifTrue: [^true]. ^nil] valueUnpreemptively" 2016-01-07 13:24 GMT+01:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > >> >> Hello. >> >> I hear about new Monitor implementation based on new primitives. >> Where to get it? >> > _,,,^..^,,,_ best, Eliot

Jan. 7, 2016

Re: [Pharo-dev] Interrupting processes question. Can method return be interrupted?

by Eliot Miranda

Hi Denis, On Thu, Jan 7, 2016 at 7:54 AM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > Look at example: > > > methodA > | result | > result := false. > [result := self methodB] ensure: [result ifTrue: [...]] > > methodB > result := 1 < 2. > > ^result > > > Imagine now that methodB starts execution in context of call inside > methodA. > Is it possible to terminate process at point of methodB return (^result)? > In that case ensure block in methodA will perform wrong logic. > Returns are not suspension points, so no. In the Cog and Stack VMs the only suspension points are backward jumps (at the end of while loops) and method activations. Note that invocations of methods with primitives (including quick methods, e.g. ^true or ^instVar) are not suspension points, unless their primitives fail, or unless the primitives are suspend, wait et al. In the interpreter VM (incorrectly IMO) primitive invocation in the context of a perform:, tryPrimitive:, executeMethod: primitive is also a suspension point. i.e. /any/ primitive including a quick primitive invoked via primitives 83, 84, 100, 188, 188 & 189, could potentially be a suspension point, in which case the process would be suspended immediately following the send that invoked the primitive. _,,,^..^,,,_ best, Eliot

Jan. 7, 2016

Re: [Pharo-dev] #sum:, #detectSum:, #sumNumbers:

by Guillermo Polito

I'd say that it is not quite a proxy nor a decorator as their main characteristic is to maintain the api of its wrapee, and so be polymorphic and transparent. At least not the number example. The main reason of this wrappers are to augment the api. But i do not know if that has a name. However, a wrapper implementing mutual exclusion could enter in the decorator category... Le 7 janv. 2016 16:38, "Sven Van Caekenberghe" <sven(a)stfx.eu> a Ã©crit : > > > On 07 Jan 2016, at 16:31, Ben Coman <btc(a)openinworld.com> wrote: > > > > On Thu, Jan 7, 2016 at 9:40 PM, Sven Van Caekenberghe <sven(a)stfx.eu> > wrote: > >> > >>> On 07 Jan 2016, at 14:23, Ben Coman <btc(a)openinworld.com> wrote: > >>> > >>> On Mon, Jan 4, 2016 at 10:55 PM, Guillermo Polito > >>> <guillermopolito(a)gmail.com> wrote: > >>>> I like these last. > >>>> > >>>> Particularly because > >>>> > >>>> - it cleans the collectionâs API > >>>> - we can continue extending this idea to add parallelism, mutual > exclusion... > >>> > >>> I don't understand the second point. > >> > >> Wrapping an object in another to add behaviour is a standard technique > (as opposed to adding the behaviour to the object itself). There can be > several reasons for doing this. It is not necessarily or always a good idea > either (for example, extension protocols are nice too). > > > >> "standard technique" > > > > Does it have a pattern name?, that I could look up to learn more (btw > > I have Design Patterns Smalltalk Companion - but its hard to remember > > them without using them in practice.) ? > > Something in the general direction of Proxy, Decorator and/or Adaptor ? > > > cheers -ben > > > >> > >>>>> On 29 dic 2015, at 11:53 p.m., Sven Van Caekenberghe <sven(a)stfx.eu> > wrote: > >>>>> > >>>>> Hi Henrik, > >>>>> > >>>>>> On 25 Dec 2015, at 14:08, Henrik Nergaard <henrin10(a)student.uia.no> > wrote: > >>>>>> > >>>>>> Like this? > >>>>>> http://smalltalkhub.com/#!/~Latsabben/NumIt > >>>>> > >>>>> That is a cool take on a possible approach. Thanks for doing it, it > makes it much easier to think about and discuss alternatives. > >>>>> > >>>>> This inspired me to do something similar, but not quite. I am just > thinking out loud by implementation. Here is my result: > >>>>> > >>>>> <Collections-Operations-SvenVanCaekenberghe.1.mcz> > >>> > >>> Interesting to great enthusiasm from several people. Looks like I'm > >>> in the minority but I'm wary of this. It seems like > >>> over-intellectualized design. > >> > >> Yes, maybe ;-) > >> > >>> I'll need to remember whether to send > >>> #magnitude or #numbers before an operation and which matches up with > >>> which operations. This seems harder for newcomers. > >> > >> #(1 2 foo true false) sum => ? > >> #() sum => ? > >> { window1. window2. window3 } max => ? > >> > >>> Are there any other programming languages that do it this way? > >> > >> There are not so many fully dynamic languages with non-homogeneous > collections. Most languages have static typing and generic types (both are > not what we want). But I would love to see how comparable languages solve > this 'problem'. > >> > >> Most language won't allow (or don't define) operations on collections > that could fail because of the fact that they contain the wrong objects. > >> > >> Having said that, I am not saying that I want to move away from our > flexibility/simplicity ! > >> > >>>>> > >>>>> There are some examples in the class comments. > >>> > >>> Class comment says CollectionOperations is "a class that offers > >>> extended API to operate on collections assumed to contain objects of a > >>> certain type." > >>> > >>>>> 1. CollectionOperations > >>>>> 2. OperationsOnMagnitudes > >>>>> 3. OperationsOnNumbers > >>>>> 4. OperationsOnSequenceableNumbers > >>> > >>> So 2 & 3 refer to the elements of the collection, so 4 makes me wonder > >>> what elements are sequence-able numbers? So 4 breaks the pattern to > >>> refer to the type of collection not just the type of element. > >> > >> Yes, that is a problem, it feels wrong. There are several dimensions > that cannot be captured in one simple hierarchy. > >> > >>> Why is #average defined for OperationsOnNumbers rather than > >>> OperationsOnMagnitudes? If I have a collection of magnitudes like Time > >>> "17:28 . 17:29 . 17:31 . 17:32" or Duration "4 minutes . 6 minutes" > >>> I would expect to be able to get 17:30 and 5 minutes as the respective > >>> averages. > >>> But then it doesn't make sense to average other magnitudes like > >>> Character, so where does that leave us? > >> > >> You are wrong, a Magnitude is only comparable, it does not mean it can > do arithmetic. You need arithmetic to compute average. > >> > >> In this case, you could use #numbers to indicate that you see your > objects as compatible with that (and the time objects mostly are). > >> > >> But summing an empty collection of Durations, you would probably want > Duration zero to be the result, and then we are back to our original > problem ;-) > >> > >>> Also I'd like to sum Durations but its not defined for > OperationsOnMagnitudes. > >>> > >>> I guess I fear there is hidden complexity for little gain. Maybe > >>> those that like the idea can collaborate on a package they use on > >>> their own projects to work out the kinks. > >>> > >>> cheers -ben > >>> > >>>>> > >>>>> Sven > >>>>> > >>>>>> Best regards, > >>>>>> Henrik > >>>>>> > >>>>>> -----Original Message----- > >>>>>> From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On > Behalf Of stepharo > >>>>>> Sent: Thursday, December 24, 2015 9:58 AM > >>>>>> To: Pharo Development List <pharo-dev(a)lists.pharo.org> > >>>>>> Subject: Re: [Pharo-dev] #sum:, #detectSum:, #sumNumbers: > >>>>>> > >>>>>> Just a remark. > >>>>>> I think that we discarded the proposition of having > >>>>>> > >>>>>> aCol arithmetic sum > >>>>>> > >>>>>> but I found it nice because there if was clear that you want to get > back > >>>>>> 0 for #(). > >>>>>> > >>>>>> Stef > > >

Jan. 7, 2016