rant
I don't know about other Smalltalk folks, but this has been a pet peeve of mine for years. It is easy enough to use RTP to strip an image, IF you know what you're doing. If you don't, you're dead. I have often wondered how many beginners have marveled at how easily they can do things in Smalltalk, and then they want to put their "things" into a dedicated clickable app, and they open RTP, gasp in horror, and go fire up the nearest Java IDE. This has to be easier. This has to be faster. This has to have a smaller learning curve.

There has to be, for all platforms, a small executable that will bring up a VM, read a list of parcels from a config file, load each one in turn, and execute a "Namespace.Classname new start" command. That's what we do. That's how you run a production app. I personally strip one image when I upgrade VW, and then never touch it. It reads a config file, loads parcels, and runs. But EVERYONE shouldn't have to build this image themselves. It should be part of the distribution. Forcing people to deal with RTP is just insane, if your goal is to grow your userbase.
/rant

My comment on Tom Sattler's remarks: Ditto.

Comment by Alan Knight

Hmm, so if I'm to understand correctly, what you'd like to be able to do is something like create a configuration file foo.cnf with, e.g. (I hope the formatting comes out intelligibly on this)

$(VISUALWORKS)\net\Http.pcl

in the file, and then run, say

visual.exe visual.im -cnf foo.cnf -doit "(Net.HttpClient new get: 'http://www.yahoo.com') inspect"

Is that the kind of thing you're thinking of?

Alan,

Close, but not exactly. I'm thinking simpler than that. I'm thinking of an executable (different for each platform, obviously) which combines the VM and an image in one file, which is started like so:

visualWorksExecutable myConfig.stc

The "stc" (or Smalltalk config) file will look sort of like this:
load infrastructureParcel.pcl
load domainParcel1.pcl
load domainParcel2.pcl
load domainParcel3.pcl
load wtkParcel1.pcl
load wtkParcel2.pcl
run BigKahuhaNamespace.SystemInstigator new open

Each "load" line designates a parcel that gets loaded, and the "run" line designates the method invocation that starts the system.
This will allow newcomers to take their code, which they've run in a workspace while going thru the development process, and turn it into a clickable app with about five minutes worth of work. The RTP learning curve goes away. RTP will stay as an optional component if one wants to fine-tune their process, but it should not be required. The executable to which I am referring would of course be fairly large, because it will have to include everything that RTP would ordinarily strip out, but in these days of 512mb entry-level workstations with 250gb hard drives, saving space is a luxury, no longer a necessity.

Comment by Alan Knight

Why would you want to do that as an executable, rather than as, say, a shell script? I think it would be about 3 lines, since there's a simple macro transformation between your syntax and the -pcl and -doit command-line options, that probably even I could manage to make sed do :-). Then if someone wanted to modify the process to do something like use a different startup image, it would be quite simple. But I also think five minutes of work is about four and a half minutes too long.

I'm thinking in terms of what I do to run my production apps. I use RTP to build a stripped image, which knows to read a config file, load the parcels in the order in which they're listed, and execute the last statement in the config file. Most other people I've spoken to about this do some variation on it. It just seems like a waste of time for everyone to go through this same process (since we as Smalltalk programmers march under the banner of "reuse") and the runtime image which does all this could be very easily on the distribution CD, so beginners don't have to figure out how to do all this themselves.

Comment by Alan Knight

Well, I'm not sure about putting the run command in the config file. It seems to me there are already two reasonable mechanisms for for indicating what to do on startup - either putting something to run on startup or on load in your code, or indicating on the command line what to do in startup. The first is more appropriate if it doesn't change very much, and the second if it changes often. I'm not sure that adding that into the config file adds a lot of value in exchange for making the config file format more complex.

Mind you, in an RTP-prepared runtime image, you can do that anyway, because the config file supports arbitrary command-line options, although in a somewhat cryptic form and undocumented form, in that you put the option and its arguments on separate lines. That's the way RTP has always done it, although I certainly didn't know about it until I started poking about in the code.

The plain base image config file only supports loading parcels in the config file, and I wasn't quite prepared to change it to support the fully general option. But presumably to do a standard runtime image, you'd want to have it set up as a runtime anyway, rather than just using the base.im that's sort of in development mode, but doesn't have any tools.

The only packaged but not thoroughly stripped runtime in the current distribution is the Web Toolkit one, so you'd have to do something like

   visual.exe ..\web\runtime.im -cnf foo.cnf

where foo.cnf contains, e.g.

  $(VISUALWORKS)\Net\Http.pcl
-doit
 42 inspect.

But in 7.3.1 this is very intolerant of blank lines, so you'd need to make sure the file ends directly after the doit line.

Comment by Alan Knight

I suppose in that last example it would also help to send -headfull, since the web runtime is by default headless :-)