- Pharo-dev - lists.pharo.org

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

by Ben Coman

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.) ? 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 Denis Kudriashov

2016-01-07 14:24 GMT+01:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > > Very, very cool Sven (and Henrik!)! > > > > And it even works with exotic objects: { 1@2. 2@3 } numbers sum ââ> (3@5 > )â > > > > I really not understand how it helps with original problem. There was > example with colors sum which was stop people to allow sum on empty > collection. How extra message solve it? > > (You should look at the code ;-) > > The example is confusing and not really relevant (because the points are > not numbers). > > Basically, sending #numbers to a collection returns an object, called a > 'collection operations' object (just a wrapper) that offers an interface to > do more operations on the collection, with the additional assumption that > it now contains (real) numbers. > > #(1 2 3) numbers sum => 6 > #() numbers sum => 0 > #(1 2 3) numbers product => 6 > #() numbers product => 1 > > #(1 2 3) asSet magnitudes max > #() asSet magnitudes maxIfEmpty: [ 100 ] > > But again, the code was just me thinking out loud, inspired by what Henrik > did, I am totally not sure it is a really good idea. Ok. I see it. And I like It.

Jan. 7, 2016

Re: [Pharo-dev] Atomic commits

by Damien Cassou

Hi, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> writes: > I wish the commits were much more atomic than they currently are... I agree. This is important (and one of my research topics https://hal.inria.fr/hal-01116225 :-)). Martin Dias worked on EpiceaUntangler to help developers do atomic commits http://smalltalkhub.com/#!/~MartinDias/EpiceaTaskClusterer. To put that in production, we need the Random Forest algorithm implemented in Pharo. > I can still open a fresh Pharo image and browse and review the whole code > snapshot there. > Or I can navigate more easily in history with git tools. > But if I wanted a lightweight review thru web, focusing on the diffs and > navigating a bit in history without replicating the repository, I can't. Skip is working on a code review tool. -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." --Winston Churchill

Jan. 7, 2016

Re: [Pharo-dev] OSProcess stdout not working in OSX [WAS] Re: Status of GitFileTree in Pharo 5.0 and Spur

by Dimitris Chloupis

you could use the older Cog JIT VM but that means also an older pharo 5 non spur image. I managed to get it working that way. I am now studying ObjC to help with getting pharo better integrated with MacOS. On Thu, Jan 7, 2016 at 3:40 PM Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > > > On Sun, Jan 3, 2016 at 12:54 PM, Thierry Goubier < > thierry.goubier(a)gmail.com> wrote: > >> Le 03/01/2016 16:49, Mariano Martinez Peck a Ã©crit : >> >>> mmmm ok, I am giving it a try but it seems it's not working or... mostly >>> likely, I am doing something wrong. >>> I just created a repo via github web interface, then I clone it to my >>> machine, and then I tried to add the gitfiletree repo in MC Browser, but >>> I get an error in: #currentBranch because #gitBranchs answered an empty >>> array. But the `git branch` command was really executed as I can see the >>> output of it in the stdout of the VM. So I guess OSProcess stdout >>> setting may be what is not working? >>> >> >> You're on Mac when you do that, right? >> >> OSProcess output redirection doesn't work in the latest Mac VM... my >> fault (introduced in the OSProcess plugin) :( but I have no idea why the fd >> dup / pipes work on Linux and not on Mac OS X. >> >> > Thierry, is there a way we can rollback or do something with this change > that broke the stdout redirection in the OSProcess plugin? > > And if true, can we make the CI build new VMs with such a fix ? > > I want to use GitFileTree in 5.0 :( > > > > >> Thierry >> >> >>> Thanks in advance, >>> >>> On Sun, Jan 3, 2016 at 12:01 PM, Mariano Martinez Peck >>> <marianopeck(a)gmail.com <mailto:marianopeck@gmail.com>> wrote: >>> >>> Hi Thierry, >>> >>> I had some problems with OSProcess in 5.0 with Spur so I wonder >>> what's the status with GitFileTree. Is it working with latest 5.0? >>> I tried to search some tests to confirm this but I found none. >>> >>> Thanks in advance, >>> >>> >>> -- >>> Mariano >>> http://marianopeck.wordpress.com >>> >>> >>> >>> >>> -- >>> Mariano >>> http://marianopeck.wordpress.com >>> >> >> >> > > > -- > Mariano > http://marianopeck.wordpress.com >

Jan. 7, 2016

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

by Sven Van Caekenberghe

> 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). >>> 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

OSProcess stdout not working in OSX [WAS] Re: Status of GitFileTree in Pharo 5.0 and Spur

by Mariano Martinez Peck

On Sun, Jan 3, 2016 at 12:54 PM, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > Le 03/01/2016 16:49, Mariano Martinez Peck a Ã©crit : > >> mmmm ok, I am giving it a try but it seems it's not working or... mostly >> likely, I am doing something wrong. >> I just created a repo via github web interface, then I clone it to my >> machine, and then I tried to add the gitfiletree repo in MC Browser, but >> I get an error in: #currentBranch because #gitBranchs answered an empty >> array. But the `git branch` command was really executed as I can see the >> output of it in the stdout of the VM. So I guess OSProcess stdout >> setting may be what is not working? >> > > You're on Mac when you do that, right? > > OSProcess output redirection doesn't work in the latest Mac VM... my fault > (introduced in the OSProcess plugin) :( but I have no idea why the fd dup / > pipes work on Linux and not on Mac OS X. > > Thierry, is there a way we can rollback or do something with this change that broke the stdout redirection in the OSProcess plugin? And if true, can we make the CI build new VMs with such a fix ? I want to use GitFileTree in 5.0 :( > Thierry > > >> Thanks in advance, >> >> On Sun, Jan 3, 2016 at 12:01 PM, Mariano Martinez Peck >> <marianopeck(a)gmail.com <mailto:marianopeck@gmail.com>> wrote: >> >> Hi Thierry, >> >> I had some problems with OSProcess in 5.0 with Spur so I wonder >> what's the status with GitFileTree. Is it working with latest 5.0? >> I tried to search some tests to confirm this but I found none. >> >> Thanks in advance, >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> >> >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> > > > -- Mariano http://marianopeck.wordpress.com

Jan. 7, 2016

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

by Sven Van Caekenberghe

> On 07 Jan 2016, at 14:08, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > > 2016-01-07 13:14 GMT+01:00 Max Leske <maxleske(a)gmail.com>: > Very, very cool Sven (and Henrik!)! > > And it even works with exotic objects: { 1@2. 2@3 } numbers sum ââ> (3@5)â > > I really not understand how it helps with original problem. There was example with colors sum which was stop people to allow sum on empty collection. How extra message solve it? (You should look at the code ;-) The example is confusing and not really relevant (because the points are not numbers). Basically, sending #numbers to a collection returns an object, called a 'collection operations' object (just a wrapper) that offers an interface to do more operations on the collection, with the additional assumption that it now contains (real) numbers. #(1 2 3) numbers sum => 6 #() numbers sum => 0 #(1 2 3) numbers product => 6 #() numbers product => 1 #(1 2 3) asSet magnitudes max #() asSet magnitudes maxIfEmpty: [ 100 ] But again, the code was just me thinking out loud, inspired by what Henrik did, I am totally not sure it is a really good idea. Sven

Jan. 7, 2016

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

by Ben Coman

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. > > >> 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. 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. Are there any other programming languages that do it this way? >> >> 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. 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? 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 Denis Kudriashov

2016-01-07 13:14 GMT+01:00 Max Leske <maxleske(a)gmail.com>: > Very, very cool Sven (and Henrik!)! > > And it even works with exotic objects: { 1@2. 2@3 } numbers sum ââ> (3@5)â > I really not understand how it helps with original problem. There was example with colors sum which was stop people to allow sum on empty collection. How extra message solve it?

Jan. 7, 2016

Semaphore and Mutex changes summary

by Denis Kudriashov

Hi. We got interesting discussion about semaphore and mutex. Here I put summary of proposed changes. First we will deprecate Semaphore>>forMutualExclusion and rename it to Semaphore>>newSignalled. Explanation from Ben Coman: Semaphore>>forMutualExclusion *encourages* people to believe > semaphores can be used *on*their*own* for mutual exclusion, when they > *shouldn't*. You *must* add ownership. If the mutual exclusion > object doesnât have ownership then, irrelevant of what it is called, > it is not a mutex!!! [1]. And more: > With an implementation like.. > Semaphore>>forMutualExclusion > ^self new signal > we don't gain a lot, and its a misleading convenience method since its > doesn't provide the proper facility for mutual exclusion (and I do > conflate mutual exclusion == mutex). Indeed, "Semaphore > forMutualExclusion + roll your ownership management + problems since > you weren't aware you needed to roll your own ownership management" is > not more convenient than "Mutex new" > If you want to keep a convenience method for a pre signalled > Semaphore, then we could provide something like "Semaphore > newSignalled" It is also explain why we should deprecate Semaphore>>critical: and use Mutex>>critical: instead. That's second change. So we want to move 4 Semaphore methods to Mutex: - critical: mutuallyExcludedBlock It will relies on new Semaphore method waitIfInterrupted: which block is executed when waiting process terminated at point where lock was not acquired. Slice for this already in inbox. - critical: mutuallyExcludedBlock ifCurtailed: terminationBlock - critical: mutuallyExcludedBlock ifError: errorBlock Semantic of this method is like BlockCosure>>ifError:. It culls error properties to handler block. It will be changed to cull only error instance. It will touch WeakArray and WeakRegistry. Now they doing this: ifError:[:msg :rcvr| rcvr error: msg]. No special logic inside handler. So we will just use #critical: message. - critical: mutuallyExcludedBlock ifLocked: alternativeBlock It purpose looks like "enter critical section without waiting otherwise alternativeBlock". But implementation not shows that waiting can not be happens: critical: mutuallyExcludedBlock ifLocked: alternativeBlock excessSignals == 0 ifTrue: [ ^alternativeBlock value ]. ^self critical: mutuallyExcludedBlock When critical message is sent but it method not started interrupt can happen and other process can lock this semaphore. And when process will be resumed it will be blocked. So implementation is not correct to me. It should be changed somehow. Welcome for suggestions

Jan. 7, 2016