This post originated from an RSS feed registered with Agile Buzz by James Robertson. Original Post: How easy is it to update a Smalltalk App? Feed Title: Cincom Smalltalk Blog - Smalltalk with Rants Feed URL: http://www.cincomsmalltalk.com/rssBlog/rssBlogView.xml Feed Description: James Robertson comments on Cincom Smalltalk, the Smalltalk development community, and IT trends and issues in general. Latest Agile Buzz Posts Latest Agile Buzz Posts by James Robertson Latest Posts From Cincom Smalltalk Blog - Smalltalk with Rants

At least in VisualWorks (part of Cincom Smalltalk), it's pretty straightforward. There are two simple paths for updating:

• File in new code. A file-out is simply code exported from a Smalltalk image - in a format that will allow it to be imported into another image. This is how I patch this server in place - I follow the following steps:
• Test my changes in a local (my office Linux box) image
• Once they work, I file out the changes. How do I know what's changed? In VW, any package has a change set - which holds all the changes since the last time that package was published. I just export that
• FTP the file-out to the server
• Using an interface I left open for myself (web based), I login and tell the server to load in one or more patches.

What does the server do? It executes code like this:

'someCodeFile.st' asFilename fileIn.

That's it. The nifty thing is what happens - not only is the new code compiled and loaded, but any shape changes required of existing objects (i.e., changes in the instance variables) just happen. I don't need to jump through a bunch of hoops; it all just works.

I take a slightly different tack with BottomFeeder. With that application, updates are delivered via HTTP download, as parcels. These parcels are either loaded at startup or at the time of download - and they replace the older version of the parcel that is in memory. Again, I don't need to worry about the details of shape changes - it all just works. Here's the code snippet that will load a parcel, and handle the warning exception that may notify me (if I'm loading over existing code:

[Parcel quietlyLoadParcelFrom: file]
	on: DuplicateBindingsError
	do: [:ex | ex resume].

And again, that's it. The parcel loads up, fixes itself into the system, and everything is updated. No need for custom class loaders. No need to write complex rules for exporting object state and then restoring it. It just works