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

About LayoutFrame>>fractions:offsets:

by stepharo

Here is the new class comments I'm trying to write. I hope that it will help people to understand the circumstances under which they should use fractions:offset: creation API. I define a transformation frame relative to some rectangle. I'm basic data structure used for graphics. I represent two groups of distances: - The fractional distance (between 0 and 1) to place the morph in its owner's bounds - Fixed pixel offset to apply after fractional positioning (e.g., "10 pixel right of the center of the owner") !! API usage It is important to understand that it is better to use the fine grained API using elementary distances (bottomFraction:, bottomOffset:, leftFraction: ....) than the ones (historical) using points and rectangles (fractions:offsets:) The reason is that the old API (fractions:offsets:) is only interesting if you already have a rectangle and points at hand. If you need to create new ones, then they are created for nothing because they will be destructured to extract their information to be feed into the layoutFrame. So please do not blindly copy and paste code! Example: Favor (LayoutFrame identity leftFraction: 0; yourself); (LayoutFrame identity leftFraction: 0.5; rightFraction: 0.95; (LayoutFrame identity topOffset: topHeight; bottomFraction: 0; bottomOffset: self buttonsBarHeight; leftOffset: -1; rightOffset: 1) over (LayoutFrame fractions: (0 @ 0 corner: 1 @ 1)) because you are creating for nothing a new rectangle and some points. !! Implementation Instance variables: The fractional distance (between 0 and 1) to place the morph in its owner's bounds is represented by the following instance variables: leftFraction topFraction rightFraction bottomFraction <Float> Fixed pixel offset to apply after fractional positioning (e.g., "10 pixel right of the center of the owner") is represented by the following instance variables: leftOffset topOffset rightOffset bottomOffset <Integer>

Jan. 9, 2016

Crash editing class method...with Pharo5.0, Latest update: #50519

by stepharo

DNU RubShoutStylerDecorator>>characterBlockForIndex: I just started to edit fractions:offsets: characterBlockForIndex: index "Answer a CharacterBlock for the character in text at index." | line | line := self lines at: (self lineIndexOfCharacterIndex: index). ^ (RubCharacterBlockScanner new text: self text textStyle: self textStyle) characterBlockAtPoint: nil index: ((index max: line first) min: self text size+1) in: line self lines is empty... Now I could not recover or close my window. No idea how to reproduce it. Stef

Jan. 9, 2016

Re: [Pharo-dev] gtdebugger in pharo 5.0

by Esteban Lorenzano

(re-send because I exceeded limit.) Hi, letâs think positive. the GTDebugger is a step forwardâ¦ it allow a lot of better interactions and of course, it needs some iterations to make it appealing to everybody. For instance, I took me 2â to tweak the debugger presentation and to get this: (I changed all availableâ¦ is a trivial task) and like IMO feels a lot betterâ¦ and I think is a good compromise between the old and the new. Reasons to suggest this approach: - it keeps old approach who(I think) was good (I can see the stack, and the flow feels natural from top to down) - it preserves âthe importantâ (the code) as central. - it gives space for adding columns (like the bytecode). Nowâ¦ I can understand you want icons with text, and that can be hacked tooâ¦ Soâ¦ can we have an agreement? Esteban ps: btwâ¦ using GT with Fast Table we can also avoid those annoying paginated lists too > On 09 Jan 2016, at 08:53, stepharo <stepharo(a)free.fr> wrote: > > Thanks for your testimony. > > I'm not against GTDebugger per se. I believe that we should have better tools > but we should take time for building better tools (even if this is two years that moosers use or not this new debugger). > I would appreciate a process where users can give real feedback and we can simplify/shape our tools nicely. > > Now for the mooc I will not present GTDebugger. So students will not use Pharo 50 > > Stef > >> Le 08/01/2016 21:22, stepharo a Ã©crit : >>> 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 >>> >>> >> IMO the old debugger is way more intuitive. >> When I used the debugger of Eclipse for java I was lost. When I used >> Spec debugger I thought "Oh, this is not so hard in fact". And I lose >> the feeling with GTDebugger. And the debugger is one of the main source >> of interest for newbies. >> >> Maybe we could have a button on the spec Debugger "Switch to GTDebugger"? >> > >

Jan. 9, 2016

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

by stepharo

Le 9/1/16 03:04, Ben Coman a Ã©crit : > I found the blogs by real-time OS guys (RTOS) have more interesting > opinions on the finer points. They are the ones who are down in the > trenches. Yes I read them too even if I got lost probably :) > cheers -ben > > On Sat, Jan 9, 2016 at 4:17 AM, stepharo <stepharo(a)free.fr> wrote: >> 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. 9, 2016

Re: [Pharo-dev] gtdebugger in pharo 5.0

by stepharo

Thanks for your testimony. I'm not against GTDebugger per se. I believe that we should have better tools but we should take time for building better tools (even if this is two years that moosers use or not this new debugger). I would appreciate a process where users can give real feedback and we can simplify/shape our tools nicely. Now for the mooc I will not present GTDebugger. So students will not use Pharo 50 Stef > Le 08/01/2016 21:22, stepharo a Ã©crit : >> 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 >> >> > IMO the old debugger is way more intuitive. > When I used the debugger of Eclipse for java I was lost. When I used > Spec debugger I thought "Oh, this is not so hard in fact". And I lose > the feeling with GTDebugger. And the debugger is one of the main source > of interest for newbies. > > Maybe we could have a button on the spec Debugger "Switch to GTDebugger"? >

Jan. 9, 2016

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

by Ben Coman

On Sat, Jan 9, 2016 at 7:12 AM, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > > On Jan 8, 2016 4:13 PM, "Ben Coman" <btc(a)openinworld.com> wrote: >> >> 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... >> > > Thanks! > >> *** 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. > > I thought the same. But I also read in glibc that that the init and destroy > would free and alloc exactly so that you don't have to do it. > > In fact, the structure is known to be opaque. I cannot rely in what I see in > internet since each os may have a different. > > And I cant get the size of it from ffi so I cannot allocate accurately. I > think I am screw. I don't want to go to plugin side grrr .. > > And osx does work. > > I think I will try against glibc rather than libc. > > Another idea? > >> { >> int __allocated; >> int __used; >> struct __spawn_action *__actions; >> int __pad[16]; >> } posix_spawn_file_actions_t; >> // http://linux.die.net/include/spawn.h >> > > But that's opaque right? I cannot rely on that Your ExternalAddress use only allocates 4 bytes for the pointer. You need to also allocate the space for the structure. I guess these may need separate ExternalXXX objects, but just as hack experiment I find below that n:=68 crashes and n:=69 its fine. | posixSpawnFileActionsT n | n := 68. "n := 69" posixSpawnFileActionsT := ExternalAddress allocate: n. OSSUnixSubprocess new primitivePosixSpawnFileActionsInit: posixSpawnFileActionsT. posixSpawnFileActionsT free. In trying to understand this I found an interesting article... http://www.catb.org/esr/structure-packing/ What I don't know is for a 32-bit OS on a 64-bit machine, is my pointer 4 or 8 bytes? Assuming 4 I derive the structure size for my 32-bit system is... 4 int __allocated; 4 int __used; 4 struct __spawn_action *__actions; 64 int __pad[16]; 76 posix_spawn_file_actions_t; 76 - 68 = 8 is an interesting round number, but I can't quite reason it out. With FFI how to you allocate some external memory and then get a pointer to it to pass to primitivePosixSpawnFileActionsInit ? 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. 9, 2016

Re: [Pharo-dev] gtdebugger in pharo 5.0

by Ferlicot D. Cyril

Le 08/01/2016 21:22, stepharo a Ã©crit : > 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 > > IMO the old debugger is way more intuitive. When I used the debugger of Eclipse for java I was lost. When I used Spec debugger I thought "Oh, this is not so hard in fact". And I lose the feeling with GTDebugger. And the debugger is one of the main source of interest for newbies. Maybe we could have a button on the spec Debugger "Switch to GTDebugger"? -- Cyril Ferlicot http://www.synectique.eu 165 Avenue Bretagne Lille 59000 France

Jan. 9, 2016

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

by Mariano Martinez Peck

Ok... so I think that mapping the structures from FFI as defined in glibc would make it work in most if not all Linux right? On Fri, Jan 8, 2016 at 10:17 PM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > > > On Fri, Jan 8, 2016 at 8:41 PM, Nicolai Hess <nicolaihess(a)gmail.com> > wrote: > >> >> >> 2016-01-09 0:12 GMT+01:00 Mariano Martinez Peck <marianopeck(a)gmail.com>: >> >>> >>> On Jan 8, 2016 4:13 PM, "Ben Coman" <btc(a)openinworld.com> wrote: >>> > >>> > 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... >>> > >>> >>> Thanks! >>> >>> > *** 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. >>> >>> I thought the same. But I also read in glibc that that the init and >>> destroy would free and alloc exactly so that you don't have to do it. >>> >>> In fact, the structure is known to be opaque. I cannot rely in what I >>> see in internet since each os may have a different. >>> >>> And I cant get the size of it from ffi so I cannot allocate accurately. >>> I think I am screw. I don't want to go to plugin side grrr .. >>> >>> And osx does work. >>> >>> I think I will try against glibc rather than libc. >>> >>> Another idea? >>> >>> > { >>> > int __allocated; >>> > int __used; >>> > struct __spawn_action *__actions; >>> > int __pad[16]; >>> > } posix_spawn_file_actions_t; >>> > // http://linux.die.net/include/spawn.h >>> > >>> >>> But that's opaque right? I cannot rely on that >>> >> >> >> no, posix_spawn_file_actions_init is not supposed allocate the >> structure. >> >> http://linux.die.net/man/3/posix_spawn_file_actions_init: >> "The *posix_spawn_file_actions_init*() function shall *initialize the >> object referenced* >> >> >> > Yeah, damn. And the following text may explain why it DOES work on OSX: > > As an implementation detail, the externally visibily type > * posix_spawn_file_actions_t is defined to be a void *, and > * initialization involves allocation of a memory object. > * Subsequent changes to the spawn file actions may result in > * reallocation under the covers. > > > Extracted from > http://www.opensource.apple.com/source/Libc/Libc-583/sys/posix_spawn.c > > > > > 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_… >>> > >>> >> >> > > > -- > Mariano > http://marianopeck.wordpress.com > -- Mariano http://marianopeck.wordpress.com

Jan. 9, 2016

Re: [Pharo-dev] gtdebugger in pharo 5.0

by Ben Coman

On Sat, Jan 9, 2016 at 4:22 AM, stepharo <stepharo(a)free.fr> wrote: > 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) This also applies to UPBE. It would be good to get that out the door matching Pharo 5 without too much rework. cheers -ben > 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. 9, 2016

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

by Ben Coman

I found the blogs by real-time OS guys (RTOS) have more interesting opinions on the finer points. They are the ones who are down in the trenches. cheers -ben On Sat, Jan 9, 2016 at 4:17 AM, stepharo <stepharo(a)free.fr> wrote: > 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. 9, 2016