Smalltalk with James Robertson

You find a lot of quirks when you try to automate your Smalltalk builds. Some of them are related to your project, and others are in the system itself. With the way VisualWorks is built now, it's easy (in theory) to unload packages you don't need at runtime. For instance, here's the code I use to pull the entire Debugger bundle:

[(Store.Registry pundleNamed: 'Tools-Debugger') ifNotNil: [:pundle |
      pundle leafItems do: [:each | each markNotModified].
      [pundle markNotModified; unloadFromImage] on: Warning do: [:ex | ex resume: true]].

Seems easy enough, right? Do the same for the rest of the tools, including the UIPainter, and you get a smaller runtime where you know exactly what got pulled out and why (as opposed to the somewhat arcane process that the RTP uses). This is where I ran into some problems though - in package Debugger-UI, there's a postUnloadBlock:

[
        Notifier beDevelopment]

I think that's an artifact from when VW had its own debugger, and the PDP was an add on - unload it, and it restored the base behavior. Now, when you try to unload the debugger, that fires and immediately blows up. It seems like something that could be easily fixed; I tossed this code into my build script:

(Store.Registry pundleNamed: 'DebuggerUI') properties at: #postUnloadBlock put: [:pkg | ].

That worked, but the Debugger-UI Parcel still had that block. So I tried this:

(Parcel parcelNamed: 'Debugger-UI') properties at: #postUnloadBlock put: [:pcl | ].

And... no effect. I scratched my head over that one for a bit, then finally decided it was easier to just dynamically recompile the offending method (Notifier>>beDevelopment) than it was to keep pounding sand. That's a problem with the base system (VW 7.6). Then there are issues at the project level.

As part of the system here, there are two overrides to classes in UIPainter. Ideally, they would be in a development package instead of the master bundle, but right now, that's not my call. I'd still like to be able to unload UIPainter, so how do I get there? Simple - yank the overrides in the script, then remove the painter. I had to debug my way through the browser doing an override removal to find this code:

overrides := (Store.Registry pundleNamed: 'UIPainter') overrides select: [:each | each class = OverridenClass].
overrides do: [:each | each reinstall.
			Override removeOverride: each].

That restores the base behavior, removing the overrides from the master bundle (which are only needed during development) - and thus allowing UIPainter to be cleanly removed. That was almost all the interesting issues, but I ran across one more.

Yesterday, I did a test build with a colleague. The runtime looked good, but it threw an MNU - something that surprised me - the whole point of avoiding the RTP was to get more predictability, right? Well, it turns out that the RTP scan can cause you grief, but it's also smart enough to spot things you might miss. In this case, I missed this: we use HotDraw, which happens to live in the Refactory namespace. Where is that namespace defined? In the RB bundle. What's one of the things I'm removing? The RB. The fix is pretty simple here. Instead of yanking the entire RB bundle, I just yank all of the packages in the bundle except for the one that defines the needed namespace.

Looks like the Cincom Smalltalk website is down this morning. If you're on the VWNC mailing list, people have been posting about it there.

Update: - it came back while I was at lunch

There's a code retreat (not entirely certain what that is - something like a BarCamp, sounds like, but my French is spotty) in Grenoble, January 21.