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

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

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

by Sven Van Caekenberghe

Thanks for the (positive) feedback. My problem is: if you think this through, lots of things could change. Consider that I added #magnitudes this would imply that sorting should move too, because you cannot assume the objects to be sortable (i.e. Magnitudes or conforming to that protocol). Also, this would create a kind of parallel hierarchy, with more type information. It feels like a simple single inheritance hierarchy cannot cover all combinations (for example, being sequenceable and being numbers, as opposed to being just a collection of numbers). Sorting an unordered collection is also different from sorting an ordered one (this last one could keep its type, or even be sorted in place). So maybe this is a can of worms. I am all for dynamic typing, not for trying to add some (weak) for of static typing. > On 07 Jan 2016, at 13:14, Max Leske <maxleske(a)gmail.com> wrote: > > Very, very cool Sven (and Henrik!)! > > And it even works with exotic objects: { 1@2. 2@3 } numbers sum ââ> (3@5)â > > Could Collections-Arithmetic be integrated into the collections operations? Not really sure thatâs a good idea, I just want to know. > > Cheers, > Max > >> On 04 Jan 2016, at 16:19, Tudor Girba <tudor(a)tudorgirba.com> wrote: >> >> Thank you, Sven! >> >> I like this very much. >> >> This would also mean that we could deprecate Collection>>#sum altogether :)) >> >> Cheers, >> Doru >> >> >>> On Dec 30, 2015, at 12:53 AM, 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> >>> >>> There are some examples in the class comments. >>> >>> 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 >>>> >>> >> >> -- >> www.tudorgirba.com >> www.feenk.com >> >> "Innovation comes in the least expected form. >> That is, if it is expected, it already happened." >> >> > >

Jan. 7, 2016

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

by Denis Kudriashov

2016-01-07 13:35 GMT+01:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > If think it makes more sense to #cull: the exception instance, it is more > object oriented We all know it. But then we found such methods in the system and cry :). who can wrote it

Jan. 7, 2016

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

by Sven Van Caekenberghe

> On 07 Jan 2016, at 13:11, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > Hi > > I look at implementation of BlockClosure>>ifError: . I did't know that it culls arguments to errorBlock. > But what is this arguments? It is not error instance but specific properties from it. > > BlockClosure>>ifError: errorHandlerBlock > > ^ self on: Error do: [:ex | > errorHandlerBlock cull: ex description cull: ex receiver] > > Why people doing that? > Many users of it just pass given error like > > [...] ifError: [:msg :rcv | ... > rcv error: msg]. > > Especially it is commonly used scenario by senders of #critical:ifError:. But it is different question. > > I propose change ifError: to cull error instance. > > What you think? Can be put it in Pharo 5? Such change can touch some packages If think it makes more sense to #cull: the exception instance, it is more object oriented. And it is what I would expect.

Jan. 7, 2016

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

by Max Leske

Very, very cool Sven (and Henrik!)! And it even works with exotic objects: { 1@2. 2@3 } numbers sum ââ> (3@5)â Could Collections-Arithmetic be integrated into the collections operations? Not really sure thatâs a good idea, I just want to know. Cheers, Max > On 04 Jan 2016, at 16:19, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > Thank you, Sven! > > I like this very much. > > This would also mean that we could deprecate Collection>>#sum altogether :)) > > Cheers, > Doru > > >> On Dec 30, 2015, at 12:53 AM, 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> >> >> There are some examples in the class comments. >> >> 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 >>> >> > > -- > www.tudorgirba.com > www.feenk.com > > "Innovation comes in the least expected form. > That is, if it is expected, it already happened." > >

Jan. 7, 2016

ifError: implementation is bad

by Denis Kudriashov

Hi I look at implementation of BlockClosure>>ifError: . I did't know that it culls arguments to errorBlock. But what is this arguments? It is not error instance but specific properties from it. BlockClosure>>ifError: errorHandlerBlock ^ self on: Error do: [:ex | errorHandlerBlock cull: ex description cull: ex receiver] Why people doing that? Many users of it just pass given error like [...] ifError: [:msg :rcv | ... rcv error: msg]. Especially it is commonly used scenario by senders of #critical:ifError:. But it is different question. I propose change ifError: to cull error instance. What you think? Can be put it in Pharo 5? Such change can touch some packages

Jan. 7, 2016