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.

I've been building BottomFeeder without RTP for awhile now, but until I started looking at build automation for this new job, I hadn't fully automated it. That's something I've done now, and one thing that I really like about the process I use is the predictability.

With RTP, if you let it scan and strip, you're never really sure what it took out. Oh, sure, there's a report it generates, and you can go through that - but it's not easy to digest. Instead, I have a script that pulls out a set of named packages - this is one of the advantages to the newer releases of VW, btw - having defined blobs of code that have structure not only makes loading easier, it makes unloading easier. Here's what I have my script do:

"Unload the debugger and other tools"
(Store.Registry pundleNamed: 'Tools-Debugger')  ifNotNil: [:pundle |
	pundle leafItems do: [:each | each markNotModified].
	[pundle markNotModified; unloadFromImage] on: Warning do: [:ex | ex
	resume: true]].
(Store.Registry pundleNamed: 'Tools-Refactoring Browser')  ifNotNil: [:pundle |
	pundle leafItems do: [:each | each markNotModified].
	[pundle markNotModified; unloadFromImage] on: Warning do: [:ex | ex
	resume: true]].
(Store.Registry pundleNamed: 'Tools-Parcel Manager')  ifNotNil: [:pundle |
	pundle leafItems do: [:each | each markNotModified].
	[pundle markNotModified; unloadFromImage] on: Warning do: [:ex | ex
	resume: true]].
(Store.Registry pundleNamed: 'Tools-Changes')  ifNotNil: [:pundle |
	pundle leafItems do: [:each | each markNotModified].
	[pundle markNotModified; unloadFromImage] on: Warning do: [:ex | ex
	resume: true]].
(Store.Registry pundleNamed: 'Tools-File Browser')  ifNotNil: [:pundle |
	pundle leafItems do: [:each | each markNotModified].
	[pundle markNotModified; unloadFromImage] on: Warning do: [:ex | ex
	resume: true]].
(Store.Registry pundleNamed: 'UIPainter')  ifNotNil: [:pundle |
	pundle leafItems do: [:each | each markNotModified].
	[pundle markNotModified; unloadFromImage] on: Warning do: [:ex | ex
	resume: true]].
(Store.Registry pundleNamed: 'StoreForPostgreSQL')  ifNotNil: [:pundle |
	pundle leafItems do: [:each | each markNotModified].
	[pundle markNotModified; unloadFromImage] on: Warning do: [:ex | ex
	resume: true]].

The handler block allows the script to proceed if anything odd happens; I should probably be logging those events. The larger point is this: I know exactly what got pulled, and, more importantly - what didn't. Unless you're really careful (and you have to be careful every time code has changed), RTP will strip code from your application. That's usually safe, but if you use constructed message sends for any reason (good or bad), you can get smacked. I think this approach is vastly safer.

I've posted before on how I put the image into a runtime state, but it's worth going over again:

• Have a subclass of UserApplication. Specify your prereq subsystems, and implement #main. In that method, start your application. It'll get called when it's safe to do so at startup, based on the prereqs you specified
• Execute the following code after you do whatever other image prep is necessary:

"set up logging and exception handling"
DeploymentOptionsSystem current startInRuntime: true.
Notifier current: RuntimePackager.RuntimeEmergencyNotifier.
RuntimePackager.RuntimeManager errorLogPath: 'error.log'.
Notifier logToFile: true.
"set up runtime state"
UI.WindowManager noWindowBlock: [:windowManager | ].
stream := WriteStream on: String new.
stream nextPutAll: 'changeRequest'; cr; cr; tab.
stream nextPutAll: '^true'.
VisualLauncher compile: stream contents.
VisualLauncher allInstances do: [:each | each closeAndUnschedule.  each release].
ObjectMemory garbageCollect.
Workbook allInstances do: [:each | each closeRequest].
(Delay forSeconds: 20) wait.
Parcel searchPathModel value: (List with: (PortableFilename named: '.')).
SourceFileManager default discardSources.

"Now save the image such that this file doesn't get looked for at startup"
[ObjectMemory permSaveAs: runtime' thenQuit: false] fork.
[(Delay forSeconds: 25) wait.
RuntimeSystem isRuntime ifFalse: [ObjectMemory quit]] fork.

I actually use some of the RTP infrastructure (the runtime exception handler and logging) - I just don't use it to create the image. It's a pretty simple process, and once you have the script created, it's easy to have a "one button click" UI drive it - from another image