Skip to main content

Change events are special

I just spent a few hours chasing a very mysterious bug, where an event handler was properly called the first time, but never again. This was a rather unspecial on:in: handler:
onFooInBar
<on: foo in: bar>
...
After initialization it was properly registered in the event map, but at some point the event map entry just vanished.

There also was another on: handler which did some stuff whenever bar changed. To "call" that stuff, we just signaled a barChanged event somewhere else:
self signal: #barChanged.
It turned out this innocuously looking line was responsible for the trashed on:in: handler! What happened?

Well, an on:in: handler must always be registered to the object that currently is occupying the bar field. But what if bar changes? Then we must unregister the foo handler in the old bar, and re-register it with the new bar. That's why the system installs a barChanged handler behind the scenes, which normally receives the new and old values of bar as arguments.

Now, can you see what happened? If we just signal #barChanged, then the arguments are nil! The current handler will be unregistered, but no new handler gets registered instead!

Lesson learned:
Do not signal a change event by hand!
Of course, we could have constructed a proper change signal like this:
self signalChanged: #barChanged from: bar to: bar
but why bother? It's much cleaner to not misuse the system-defined change event. I ended up defining another event, #barModified with a proper handler, which is signaled from both the #barChanged handler and other places.
Labels:

Comments

Post a Comment

Popular posts from this blog

Deconstructing Floats: frexp() and ldexp() in JavaScript

While working on my  SqueakJS VM, it became necessary to deconstruct floating point numbers into their mantissa and exponent parts, and assembling them again. Peeking into the C sources of the regular VM, I saw they use the  frexp ()   and ldexp () functions found in the standard C math library. Unfortunately, JavaScript does not provide these two functions. But surely there must have been someone who needed these before me, right? Sure enough, a Google search came up with a few implementations. However, an hour later I was convinced none of them actually are fully equivalent to the C functions. They were imprecise, that is, deconstructing a float using frexp() and reconstructing it with ldexp() did not result in the original value. But that is the basic use case: for all float values, if [ mantissa , exponent ] = frexp (value) then value = ldexp ( mantissa , exponent ) even if the value is subnormal . None of the implementations (even the complex ones) re...
6 comments
Read more

Emulating the latest stable OLPC XO software

Even with XO laptops readily available now there are quite a lot of reasons why one would want to emulate it on another machine. One being to hook up a projector. Unfortunately there are quite a number of hoops (*) one has to jump through to make it work. Anyway, I made a virtual machine that allows me to emulate the XO in VMWare on my Mac, running Sugar in the XO's native 1200x900 resolution, scaled down to a nice physical size in a window on my regular screen (fullscreen works, too). Sound works (even Tam Tam), Browse works (so networking is good), and after setting a working Jabber server I do see other XOs in the neighborhood view (Chat worked fine). Camera and mic are half working (Measure crashes, Record shows blank picture, but reportedly does record video), and a "Sugar restart" does not actually restart Sugar, but apart from that it seems fully functional, and much nicer than the emulations I had used to date. Click to see actual screenshots (calibrated to mat...
15 comments
Read more

SqueakJS: A Lively Squeak VM

I'm proud to announce SqueakJS, a new Squeak VM that runs on Javascript: SqueakJS project page It was inspired by Dan's JSqueak/Potato VM for Java, and similarly only runs the old Squeak 2.2 mini.image for now. But I developed it inside the Lively Kernel, which allowed me to make a nice UI to look inside the VM (in addition to all the Lively tools): It represents regular Squeak objects as Javascript objects with direct object references. SmallIntegers are represented as Javascript numbers, there is no need for tagging. Instance variables and indexable fields are held in a single array named "pointers". Word and byte binary objects store their data in arrays named "bytes" or "words". CompiledMethod instances have both "pointers" and "bytes". Float instances are not stored as two words as in Squeak, but have a single "float" property that stores the actual number (and the words are generated on-the-fly w...
7 comments
Read more