In a VM mail Andreas said: "Some set of incomplete process/delay/semaphore changes in Pharo. One of the problems with processes and delays is that this part of the system reacts very badly to random "cleaning". I.e., changing "foo == nil" to "foo isNil" can have dramatic effects (since it introduces a suspension point) with just the kind of weird issue you're seeing."
I don't know if this is related to this issue. cheers mariano On Thu, Dec 2, 2010 at 10:50 PM, Peter van Rooijen <[email protected]>wrote: > On Thu, 02 Dec 2010 12:32:02 +0100, Levente Uzonyi <[email protected]> wrote: > > On Thu, 2 Dec 2010, Peter van Rooijen wrote: >> >> I agree, >>> >>> If you want to know if a object is the same object as >>> that designated by the expression nil, you use the message #== >>> (this message had guaranteed semantics since it can not be redefined). >>> >>> If you want to know if the message ifNil: aBlock sent to the object >>> evaluates the block argument, you use the message #ifNil: >>> (which could do anything it has been defined to do >>> - at least, I would hope so!). >>> >>> Those two uses are distinct and mean something different. >>> >> >> In theory yes, but the compiler also inlines #ifNil:, #ifNil:ifNotNil:, >> #ifNotNil: and #ifNotNil:ifNil: if the arguments are literal blocks. So in >> that case, they are equivalent with == nil ifTrue:/ifFalse:. >> > > Thanks for explaining, I wasn't aware of that. > > Seems like a really ugly hack to me. > Deciding semantics based on an argument type, > before the receiver type is known...extremely fishy. > > Now, if the compiler inlined [...] ifNil: <something> > that would be a different matter, since the receiver > class is known at compile time, and it's not such > a big deal to require those semantics to be fixed. > > Cheers, Peter > > > Levente >> > >
