One of the things that sticks to Smalltalk (unfairly now) is the idea that building and deploying a runtime is hard. In this post, I'll take a small application and demonstrate how to go from "code in the environment" to a runtime application. If you want to use this sample application, simply go to the public store repository and install ITunesAlarmClock. It doesn't have any outside pre-reqs. First, here's a snapshot of the simple iTunes alarm clock application:

---

The application is simple - specify a time, set an alarm, and when the time rolls around, iTunes will play at the specified volume. Here's the way we get the runtime to start the application up when the image starts:

---

We create a subclass of UserApplication and add a #main method. In #main, we put our startup code. That's most of what we needed. Next, there's a short script to build the image:

| promise stream |

Parcel loadParcelFrom: 'ITunesAlarmClock.pcl'.

DeploymentOptionsSystem current startInRuntime: true.

Notifier current: AlarmClock.EmergencyHandler.

Notifier uheFilename: 'error.log'.

Notifier logToFile: true.

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 closeRequest].

(Delay forSeconds: 10) wait.

promise := [ObjectMemory permSaveAs: 'alarmClock' thenQuit: false] promise.

promise value.

RuntimeSystem isRuntime ifFalse: [ObjectMemory quit].

Adapting that script to your own needs should be straightforward. Here's what's going on there (the file is called configureAlarmImage.st):

• We tell the runtime system that we'll be in deployment
• We specify that the emergency handler to use is AlarmClock.EmergencyHandler
• We tell the WindowManager not to bring up the launcher when there are no other windows open
• The streaming code is a bit of trickery to tell the launcher to not prompt us when we close it in the next couple of lines.
• Then we save the image, with a delay - that's to ensure that the resulting image doesn't start up with the launcher visibly closing.
• Finally, we quit the image we're in, having created a new one

Now, to use that we start the image on the command line. The Mac shell script I use is below; on Linux/Unix you would do something similar. On Windows, a simple batch file would suffice. Heck, you can even just type the command in at the command line:

#!/bin/sh

./startvw ~/Applications/vw7.6/preview/packaging/base.im  -fileIn configureAlarmImage.st

That starts up the base image (which does not have development tools in it), loads our code and configures the image (as explained above), and then saves it.

That gives us an image that will start up with our application running. Finally, you need to put this into a platform specific runtime. On Windows, follow the directions here to create an executable. On Mac, follow the directions here. If you want to create a nice DMG file, just use the Disk Utility application to build that. On Unix/Linux, all you need to do is change the image to have executable permissions, and put it and the VM in the same directory. The image can then be run as if it were a schell script.

And that's it! Not a ton of steps, and it's all automatable.

Technorati Tags: deployment, runtime