[squeak-dev] ObjectViewer example (Sensor cursorPoint) broken

christoph.thiede at student.hpi.uni-potsdam.de christoph.thiede at student.hpi.uni-potsdam.de
Thu Mar 24 17:36:45 UTC 2022


Hi all,

recently I noticed that the ObjectViewer example from the class comment is broken:

> ObjectViewers offers the same kind of interception of messages (via doesnotUnderstand:) as ObjectTracers, but instead of just being wrappers, they actually replace the object being viewed.  This makes them a lot more dangerous to use, but one can do amazing things.  For instance, the example below actually intercepts the EventSensor object, and prints the mouse coordinates asynchronously, every time they change:
> 	Sensor evaluate: [Sensor cursorPoint printString displayAt: 0 at 0]
> 		wheneverChangeIn: [Sensor cursorPoint].
> To exit from this example, execute:
> 	Sensor xxxUnTrace

"Broken" means that the VM will crash without further notice after a few seconds.

I identified two things that are going wrong here:

1.) Object>>#evaluate:wheneverChangeIn: uses the #become: primitive, and I was surprised that this will even exchange the receiver of all existing Context instances. Concretely, this affects the eventTickler process so that the next instvar access will fail because the ObjectViewer instance does not have enough instance variables.
Question: Should #become: et al. actually replace the receiver of context instances?

2.) I tried to fix the example by changing the code like this (to avoid the #become:):

		Sensor := ObjectViewer on: Sensor evaluate: [Sensor cursorPoint printString displayAt: 0 at 0]
			wheneverChangeIn: [Sensor cursorPoint].
	To exit from this example, execute:
		Sensor := Sensor xxxViewedObject.

Unfortunately, this still impairs the image because since ST80-mt.257/EventSensor>>#peekPosition @ mt 7/15/2020 11:05, #peekPosition & #cursorPoint are no longer side-effect free - i.e., sending #peekPosition frequently will swallow keyboard events.
Question: Are #peekPosition et al. actually expected to flush any events? If yes, how would you think about a new side-effect #peekLastPosition method?

Thanks in advance! :-)

Best,
Christoph

---
Sent from Squeak Inbox Talk
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20220324/3d18ca67/attachment.html>


More information about the Squeak-dev mailing list