Send to Printer

smalltalk

Builds and Project Oddities

January 20, 2011 11:34:48.793

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.

At least so far as I know now, that looks like all the issues - my little build tool produces a runtime, and it doesn't look like anything we need is missing. I'd be curious to know what similar issues other people have run into though - the ones I detailed above weren't always easy to spot, and who knows - I may well be missing something else :)

posted by James Robertson

 Share Tweet This