Thin Air
Everything about smalltalk
Announcements
The basic design strategy for OmniBrowser is simple: rather than modelling a browser with one large and complex object (like Browser does), break it up into a network of smaller, simpler objects. From there, the design is pretty straightforward, and it's much easier to build lots of kinds of browsers from the same code base.
This design does have a downside, though. It makes event handling more difficult, because the objects that need to communicate to respond to events are often in distant parts of the network, and can't rely on the the structure of the network to find each other. Early versions of OmniBrowser responded to events, such as a click, with a cascade of messages, with each object letting it's neighbors know about the the event. This had the advantage that each object only needed to know about it's immediate neighbors, but it was also fragile and prone to infinite loops as neighbors repeatedly notified each other of the same event.
My second attempt to address this problem involved the use of a Dispatcher. This was an central object that all notification messages would flow through. As the various parts of the browser were created, they would register with the dispatcher to receive messages. This was an improvement, because objects could send messages to "everybody" rather than to an explicit receiver. But it was still awkward, and the event handling code was still convoluted and difficult to understand.
I've just finished up the implementation of my third attempt, this time based on Vassili Bykov's notion of Announcements. I talked to the folks at Cincom about porting the code to Squeak, but that didn't work out. I ended up just doing a mini-implementation that meets my needs for OmniBrowser. (Actually this was probably what I should have done in the first place. It was probably less work for me to re-implement Announcements from scratch than it would have been for someone at Cincom to get corporate approval to release the code under an open source license.)
Despite all the positive things Vassili had to say about Announcements, I have to admit I was surprised what an improvement it made in OmniBrowser's event handling code. My first pass at the conversion was simple. I replaced messages sent to the dispatcher with announcements sent to the announcer. Then I installed an announcement spy and browsed around the image a bit. It turned out that every event resulted in 3 or 4 redundant announcements, and probably even more unnecessary updates to the UI.
So I made a second pass, explicitly aimed at removing all the redundant announcements. In many cases, this meant finding the ultimate source of a particular announcement. For example, OBSelectionChanged should only be announced from two places in the code. All the other places where it was being announced were redundant, and had to be removed. By spying on announcements, I was able to get a clearer idea of the code flow in response to different events, and find other ways to simplify.
I suspect there's even more simplification that can be made, but even without it, moving to Announcements was a big improvement.
Posted in omnibrowser announcements visualworks smalltalk squeak
Questions on the versioning model
Bruce Badger posted a comment in response to my post on the versioning model used in Monticello 2. He has some questions about methods:
- What is the identity (or primary key) of a method?
- Within what scope is the identity unique?
- If I wanted to use a particular version of a particular method in two classes, could I (setting asside the question of whether this is a good idea or not)?
The short answer is that Monticello two uses the same semantics that the Smallltalk runtime uses. The identity of a MethodElement is class name and selector; it's only guaranteed to be unique within a given image. You couldn't put the same method in two classes, it would have to be copied.
Now, Avi and I have kicked around ideas for a deeper model of Smalltalk code. Rather than identifying elements by name, they'd each have UUIDs. Method sources would be versioned as an AST. The nodes for variable references would have the UUIDs of the elements the variables are bound to in the compiled method.
This would have two advantages:
First, it would help with platform independence. Rather than depending on names to bind variables during compilation, we'd be relying on UUIDs. This would make it easier to transform the names when moving code back and forth between dialects. This would make it easier to handle Namespaces in VW, for example, or differences in platform libraries.
Second, it would allow us to provide a more accurate reproduction of code between images. We'd be restoring methods to their compiled states rather than just their source code. This is one of the things that's so compelling about Spoon, and it would allow Bruce's scenario of the same method version being used in two different classes.
On the other hand, it's that much more code and complexity. It would require a custom parser, an AST able to handle all the syntactic quirks of the various dialects of Smalltalk where Monticello will run, and a compiler back end for each platform. Monticello 2 is already an ambitious project, and a significant improvement over Monticello 1. Our goal for now is to get the current version up to production quality so we can start using it. Maybe some of these ideas will be part of Monticello 3.
Posted in monticello versioning smalltalk
Monticello 2 alpha release
One of the things that surprised me at Smalltalk Solutions this year was the continuing interest in Monticello 2 from outside the Squeak world. Now that I'm not working in VisualWorks day-to-day anymore, I've been more focused on solving the problems that we have with using Monticello 1 in Squeak.
However, there is a real need for tools to make cross-dialect development easier, and versioning is an important component of that. After doing a few demos, I had volunteers to maintain VisualAge and Dolphin ports. The VisualWorks folks all seem pretty busy, but I'm sure somebody will step up when MC2 gets to production quality.
With all that momentum coming out of the conference, I cleaned up the code a bit, wrote an installer and posted the first alpha to SqueakMap. The reaction has been mostly positive, particularly given that Monticello 2 is still very raw and there's no documentation at all.
To remedy that I'll post some discussion of the architecture and features of Monticello 2 over the coming weeks.
Posted in smalltalk monticello dolphin visualworks visualage squeak