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 <peter@vanrooijen.com> wrote:
On Thu, 02 Dec 2010 12:32:02 +0100, Levente Uzonyi <leves@elte.hu> 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