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

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

by stepharo

Ok but my gut feeling is telling me that exposing activities in open community can only explain better. Le 7/1/16 21:06, Esteban A. Maringolo a Ã©crit : > 2016-01-07 16:54 GMT-03:00 stepharo <stepharo(a)free.fr>: >> This is not to be visible. >> This is to educate you guys :) >> The point is how much time does it take esteban to fix FFI >> How much worth is that? >> All these questions and like that you know what esteban is doing for >> real when you put money >> in the consortium. > > Oh, I see. Well... Esteban is very proficient, any money spent on him > will pay more than on any other developer. His commits speak by > themselves. > > Regards! > > Esteban A. Maringolo > >

Jan. 8, 2016

Re: [Pharo-dev] gtdebugger in pharo 5.0

by stepharo

I'm sorry but this debugger should not be the default one. MONDAY we are filming our mooc and we have to explain the debugger and personally I do not see the gain: - It looks a lot more complex to me and I do not want to have to redo all the screenshots of our lecture. - Just that I have to learn the meaning of small icons. - Why do we need a special pane for the evaluator - Why there is a type column. - Sorry but I'm not convinced about the moldable aspect behind the story (no need to argue I know it) I would like to avoid to be forced to use not the latest version of Pharo for the mooc. Such changes are arriving far too late in the release. We do not change the debugger itself the day of code freeze. We decided that the GTDebugger can be included but to me it never meant that it should be the default one. I think that experts can choose the debugger they want. The newbies don't. Stef

Jan. 8, 2016

Re: [Pharo-dev] Semaphore and Mutex changes summary

by stepharo

thanks for the summary. I think that this is important to update the class comments with the comment of ben. I read several blogs of mutex vs semaphore and this is nice to get this cleared out. Stef Le 7/1/16 14:05, Denis Kudriashov a Ã©crit : > 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. 8, 2016

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

by Juraj Kubelka

Hi, 8. 1. 2016 v 17:11, Tudor Girba <tudor(a)tudorgirba.com>: > Hi, > > Denis says that right now, to use ifError: you do: > > [...] ifError: [:msg :rcv | â¦ ] > > and he would like to write this: > > [...] ifError: [:error | â¦ ] But for this we have on:do: message, right? Do we need ifError:? Cheers, Juraj > > I agree with him. The problem is that this might generate a bit of ripple effects in external code. This is when Stephan came in and said that if we would have a way to investigate all external repositories that are open we could do such refactorings more boldly. > > Does it make more sense now? Or did I get it wrong? > > Cheers, > Doru > > > >> On Jan 8, 2016, at 10:05 PM, stepharo <stepharo(a)free.fr> wrote: >> >> Hi denis >> I do not understand the problem and I'm convinced that you are right >> so can anybody explain to me the point made by denis? >> >> Stef >> >> Le 7/1/16 13:11, Denis Kudriashov a Ã©crit : >>> 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 > > -- > www.tudorgirba.com > www.feenk.com > > "Be rather willing to give than demanding to get." > > > > >

Jan. 8, 2016

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

by stepharo

Sven may be should do the following: - introduce the best solution (not using your and henrik decomposition) - continue to think about it. I would like to see if Xtreams does not go in the same direction too. But I do not have the code at hand to think about it. Stef

Jan. 8, 2016

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

by Tudor Girba

Hi, Denis says that right now, to use ifError: you do: [...] ifError: [:msg :rcv | â¦ ] and he would like to write this: [...] ifError: [:error | â¦ ] I agree with him. The problem is that this might generate a bit of ripple effects in external code. This is when Stephan came in and said that if we would have a way to investigate all external repositories that are open we could do such refactorings more boldly. Does it make more sense now? Or did I get it wrong? Cheers, Doru > On Jan 8, 2016, at 10:05 PM, stepharo <stepharo(a)free.fr> wrote: > > Hi denis > I do not understand the problem and I'm convinced that you are right > so can anybody explain to me the point made by denis? > > Stef > > Le 7/1/16 13:11, Denis Kudriashov a Ã©crit : >> 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 > -- www.tudorgirba.com www.feenk.com "Be rather willing to give than demanding to get."

Jan. 8, 2016

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

by stepharo

In general I do not like cull: and I'm really suspicious about its use. It often reveals a lack of coherence and/or design. Why this is not simply BlockClosure>>ifError: errorHandlerBlock ^ self on: Error do: errorHandlerBlock ?? > 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. 8, 2016

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

by stepharo

Hi denis I do not understand the problem and I'm convinced that you are right so can anybody explain to me the point made by denis? Stef Le 7/1/16 13:11, Denis Kudriashov a Ã©crit : > 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. 8, 2016

problem with become:?

by Tudor Girba

Hi, If I execute the following code in the latest Pharo image: Object subclass: #A instanceVariableNames: '' classVariableNames: '' package: 'AA'. Object subclass: #B instanceVariableNames: '' classVariableNames: '' package: 'AA'. a := A new. b := B new. a become: b. a class ==> âA". In a pre-Spur image, I used to get âBâ. Is this a bug, or is there a change I am not aware of? Cheers, Doru -- www.tudorgirba.com www.feenk.com "Things happen when they happen, not when you talk about them happening."

Jan. 8, 2016

Re: [Pharo-dev] Help with FFI crash in latest Spur (only in Linux)

by Ben Coman

On Sat, Jan 9, 2016 at 2:04 AM, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > Hi guys, > > I wonder if someone could give me a hand to find out why a FFI calling I am > doing is crashing. In OSX it works correct but I am testing in CentOS and it > fails. I wonder if it also crashes in other Linuxes too. I only had enough time to run it a few time so you know it also crashes in Debian Jessie 32-bit. There were no debug logs. I got these sorts of messages... *** Error in `/home/ben/tst/pharo-vm/pharo': free(): invalid next size (fast): 0x08841a70 *** pharo: malloc.c:3695: _int_malloc: Assertion `(unsigned long) (size) >= (unsigned long) (nb)' failed. *** Error in `/home/ben/tst/pharo-vm/pharo': malloc(): memory corruption: 0x0984c1e0 *** Searching github for "posix_spawn_file_actions_init " (https://git.io/vuSPL) I see a lot a function definitions of the form... int posix_spawn_file_actions_init(posix_spawn_file_actions_t *fa) { fa->__actions = 0; return 0; } ...so it seems you need to first allocate the space for the struct and then pass the address of that. { int __allocated; int __used; struct __spawn_action *__actions; int __pad[16]; } posix_spawn_file_actions_t; // http://linux.die.net/include/spawn.h cheers -ben > > I am using latest Pharo 5.0 with Spur. To reproduce: > > 1) Get latest Pharo 5.0 and Spur via: > wget -O- get.pharo.org/alpha+vm | bash > > 2) Inside Pharo, load my prototype tool: > > Gofer it > package: 'OSSubprocess'; > url: 'http://smalltalkhub.com/mc/marianopeck/OSSubprocess/main'; > load. > > 3) This is the code I am executing and it's crashing: > > | posixSpawnFileActionsT | posixSpawnFileActionsT := ExternalAddress > allocate: 4. OSSUnixSubprocess new primitivePosixSpawnFileActionsInit: > posixSpawnFileActionsT. posixSpawnFileActionsT free. > 4) The primitive is as simple as: > > primitivePosixSpawnFileActionsInit: aPosixSpawnFileActionsT > ^ self ffiCall: #( int posix_spawn_file_actions_init(void* > aPosixSpawnFileActionsT) ) module: LibC > > I have no idea what I am doing wrong. And again, this works on OSX. The > function I am calling is: int > posix_spawn_file_actions_init(posix_spawn_file_actions_t *file_actions); as > you can read in [1] > > Below is the stacktrace I get the Linux terminal. > > Any hint is greatly appreciated. > > Thanks, > > > [1] > http://pubs.opengroup.org/onlinepubs/9699919799/functions/posix_spawn_file_…

Jan. 8, 2016