Thomas Gagne has some qualms about modifying production Smalltalk images:

Practically speaking, we could probably open a running image, save code, then parcel-out the fixed classes. That would require our production images to be configured to read-in parcels when it starts up. While technically feasibly, it is impractical. We have a distributed application with multiple Smalltalk images running concurrently and each one would have to be re-initialized.

It's simpler than that, IMHO. I modify the running blog server here all the time. I've outlined the steps before, but what the heck - let's go through it again:

• I have a base image that loads all parcels at startup. VW can do that via a command line argument, either with the parcels on the command line or in a config file.
• I have an interface open on the server that allows me to kick it and have it execute specific patches (Smalltalk file-ins)
• I do development on my local Linux box, and export changes in two forms: a file-out of changes, and a new parcel
• I upload the file-out to the patch directory on the server, and the new parcel to the startup directory. I don't worry about saving the image - I just ensure that the latest code is ready to load at startup
• I kick the image so that it loads the patches

That's it. Every major change I've done (including ones that have made shape changes to live objects in the server) has happened on the fly that way. I try not to restart the server, simply to avoid outages.

Technorati Tags: hot loading, live patching