ObjectViewer Bug in Squeak 2.x ?
paulmc at ftconnect.com
Mon Aug 9 21:40:11 UTC 1999
There are a couple of problems. You can get an idea of what is going on by
putting a halt in front of your expression and using the debugger's send
command -- very carefully!
First note that the inst var recursionFlag has no references in the
ObjectTracer, the class in which it is defined. Curious, eh? Next, note
that when on: is sent to ObjectViewer, the on: message is found in class
ObjectTracer -- thus guaranteeing that the recursionFlag instVar is nil.
When doesNotUnderstand: is sent to the object of interest, the
doesNotUnderstand: message in ObjecTracer runs and the first thing it does
is send ifTrue: to recursionFlag. The VM detects that recursionFlag is
neither true nor false and forces a message send to the receiver. Hence the
infinite regress. Perhaps the author or authors of ObjectTracer and
ObjectViewer can explain their curious code!
At 04:06 PM 8/9/99 -0400, you wrote:
>Evaluating the following expression with "do it..." on any Squeak V2.x system
>I've tried causes the system to lock up to the point that the Squeak VM
>be killed from the host OS. Evaluating the same expression in Squeak V1.3
>fine and operates as expected. (BTW, this is the example from the Class
>for ObjectViewer). Some kind of "dieing gasp" message comes up that indicates
>something about a message not in the inheritance chain, but since the system
>locks up, debugging this is a bit difficult.
> Sensor evaluate: [Sensor cursorPoint printString displayAt: 0 at 0]
> wheneverChangeIn: [Sensor cursorPoint].
>I stumbled on this in my quest to create a "landscape" display mode for
>Squeak on the Casio E100/105. I planned to use the ObjectViewer functionality
>to intercept message sends to #Display, and swap the x,y coordinates in BitBlt
>So, on a related note: Is there a better and/or safer way to intercept
>sends to #Display, or is 'become:' about the only way to do it?
> -Dean Swan
> dean_swan at mitel.com
More information about the Squeak-dev