- Pharo-dev - lists.pharo.org

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

Interrupting processes question. Can method return be interrupted?

by Denis Kudriashov

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.

Jan. 7, 2016

Re: [Pharo-dev] [Vm-dev] How to compile Spur VM in Windows?

by Esteban Lorenzano

Hi Hernan, > On 06 Jan 2016, at 23:46, HernÃ¡n Morales Durand <hernan.morales(a)gmail.com> wrote: > > Hola Esteban :) > > As suggested, I am using sources from https://ci.inria.fr/pharo/view/VM/job/PharoVM/Architecture=32,Slave=vm-buil… <https://ci.inria.fr/pharo/view/VM/job/PharoVM/Architecture=32,Slave=vm-buil…> > > I have some questions: > > 1) The sources.tgz file in CI already includes the generated C code (in src/ directories) and CMake files (in build/ directories) ? So for checking the build it would not be necessary to evaluate "PharoVMBuilder buildWin32â. I never built the VM using those sources, so I donât know how it will go. In general, I think what you say is ok. > > 2) Just out of curiosity, VMMakerTool is usable these days? Nope, we use CMakeMaker (could work, never tried). > > 3) I evaluated : PharoVMBuilder buildWin32. and received a lot of warnings (conflicting return types, undeclareds, etc) in Transcript - attached - Is this expected or should I try to update PharoVMMaker? And if so, from where? I think you are âsafe to goâ with those warnings. I should review them, though. Esteban > > HernÃ¡n > > 2016-01-06 16:08 GMT-03:00 Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>>: > btw you might be able to build SpurVM using an old non-spur Pharo 5.0 imageâ¦ not sure, but I do not see a reason why you couldnât :) > > Esteban > > >> On 06 Jan 2016, at 20:05, Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>> wrote: >> >> https://github.com/estebanlm/pharo-vm/tree/spur64 <https://github.com/estebanlm/pharo-vm/tree/spur64> >> >> because I still do not merge with master >> instructions should work, but right now you WILL NOT be able to build a VM, because there is a bug in OpalCompiler who prevents building the VM in spur imagesâ¦ and probably there are other issues, I couldnât test further. >> >> So I would say you need to wait until I can restore the builds here: https://ci.inria.fr/pharo/view/5.0-VM-Spur/job/PharoVM-spur32/ <https://ci.inria.fr/pharo/view/5.0-VM-Spur/job/PharoVM-spur32/> >> >> (itâs been almost one month since I cannot build :( ) >> >> Esteban >> >> >>> On 06 Jan 2016, at 19:33, HernÃ¡n Morales Durand <hernan.morales(a)gmail.com <mailto:hernan.morales@gmail.com>> wrote: >>> >>> Hello >>> >>> I am trying to compile Spur VM in Windows 8.1. >>> >>> As far as I understand Spur VM needs the Pharo 5.0 image format, is that right? >>> >>> Apparently instructions here https://github.com/pharo-project/pharo-vm/blob/master/README-Win32-fasttrac… <https://github.com/pharo-project/pharo-vm/blob/master/README-Win32-fasttrac…> are only applicable to "Old VM" in Pharo 3.0 >>> >>> Does anyone have any idea how to clone/compile the Spur VM (i.e. Pharo 5.0) ? >>> >>> Cheers, >>> >>> HernÃ¡n >>> >> > > > <buildWarnings.txt>

Jan. 7, 2016

Re: [Pharo-dev] ifError: implementation is bad

by Stephan Eggermont

On 07-01-16 13:11, Denis Kudriashov wrote: > What you think? Can be put it in Pharo 5? Such change can touch some > packages This is exactly why I want a compact archive representation of all source code in the repos. Then we know what's touched. Stephan

Jan. 7, 2016

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

by Sven Van Caekenberghe

> 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

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

by Nicolai Hess

2016-01-07 16:31 GMT+01:00 Ben Coman <btc(a)openinworld.com>: > 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.) ? > Decorator? https://en.wikipedia.org/wiki/Decorator_pattern > > 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