Tales of Dying Objects

Paul Fernhout pdfernhout at kurtz-fernhout.com
Sun Jun 18 15:09:14 UTC 2000


Stefan Matthias Aust wrote:
> This is a tragic story of my failed effort to create a tidy tiny image.

Stefan-

Yours was a fantastic post. Thanks for sharing it.

It helps bolster my own conviction that shrinking images for deployment
is not the ideal way to go. The approach of building up Smalltalk images
seems much more reliable; like Pocket Smalltalk doe:
  http://www.pocketsmalltalk.com/

What your post makes clear to me is that shrinking images requires:
  * a deep understanding of the Smalltalk,
  * a reasonable understanding of many applications which you are not
interested in and willlingness to explore arcane interrelationships,
  * a lot of time and a willingness to do the same thing over and over
again,
  * keeping up-to-date on version changes,
  * an acceptance of uncertainty in a deployed image and the need for
extensive testing.

I understand that historically, Smalltalk vendors wanted developers to
remove the compiler and development tools to preserve the vendors
commercial leverage, and it was easier to just include a minimal tool to
do that removal (and maybe then a little more). So I can understand how
the concept of "shrinking" or "stripping" images came about.  But this
seems somehow inappropriate in an open Smalltalk. Even when I stripped
images in VisualWorks it was often an effort that took multiple attempts
to make something that worked right.

I also understand why for attracting people to Squeak one might want to
ship a large image with lots of bells and whistles. However, the need
for this is changing as Squeak becomes better able to load modules on
demand over the internet and as more and more people have internet
connections. Also, in the absence of tools like those in LearningWorks
for hiding complexity in the debuggers and browsers, all these classes
and methods can easily overwhelm the novice developer, and thus be
counterproductive in encouraging people to develop in Squeak. (Actually,
I'm more impressed by Squeak's ability to incrementally load an
application like the math morphs.)

Squeak Central seems to be deeply enamored of shipping big images and
asking people to shrink them, offering at best a tool for tracing object
references in an images to copy parts of an image. Is this a case of not
making modularity a priority, or is there some other reason I do not
understand for wanting to shrink images for deployment? It just seems
like an ancient holdover to me -- perhaps more a sign of relative
priorities of distribution vs. exploratory work.

The sort of experience you had is why I think a version of Squeak
designed for making shippable utilities and applications must support
building up an image from scratch. I really don't understand what people
think is so hard about this. You just have a file of Smalltalk code (or
a class) which defines the base objects in an "image" object built as a
byte array, and then you ask the image object to write itself out. I
would guess the core would be probably ten pages of Smalltalk, with then
a selection of classes and specific methods to be added afterwards to
the image (filed in by the host Smalltalk system, since the virtual
image might not include file-in code or a compiler). Some portable
Forths do something like this in a process called "meta-compiling" -- in
short, the host Forth compiler is minimally modified to emit compiled
code into the target image. In Smalltalk's case, one would probably also
want to write out a source file to go with the compiled-in methods. The
question for Smalltalk is, how much initial spaghetti is there at the
core to get to the point where one can then incrementally load new
objects and classes?

Perhaps one reason this image creation process is more difficult for
Smalltalk than it has to be is that to an extent a typical Smalltalk's
class library in my opinion is "over factored". For example there are
endless types of Stream classes, when in practice for 95% of streaming
one or two might do. This makes the task of deciding what to include in
a small image more daunting. Pocket Smalltalk gets by with many fewer
classes.

Python is an example of a system which is much more modular.
Unfortunately, Python lacks many of Squeak's other elegances:
non-reference counting garbage collection, keyword syntax,
cross-platform GUI concept, blocks, integrated development tools, etc.
Python also has its own deployment issues, mostly revolving around its
desire to load modules from files in various locations and the need for
choice of a GUI platform (TK/TCL, wxWindows, etc.) which has its own
installation issues.

Having been tanking up on money the last few months on a consulting
project (with some more to go), my mind has been turning again towards a
version of Squeak (Squeak/Pro?) useful for application deployment (in
our case, to make our applications cross-platform and more extensible.)
There did see to be substantial interest in a version of Squeak designed
for deployment of GUI applications and web applications. I personally
decided the dynamics of funding such an effort through external means
were too complex and fraught with the potential for unfairness and
disharmony (although thanks again to those who were interested in it).

What stops me from pursuing building up an image (besides time) is in
large part the issue of forking. It really seems that a application
deployment version of Squeak would have to be separately maintained
until such time as Squeak Central and others started to base their work
on it. Is there any way to resolve this?

-Paul Fernhout
Kurtz-Fernhout Software 
=========================================================
Developers of custom software and educational simulations
Creators of the Garden with Insight(TM) garden simulator
http://www.kurtz-fernhout.com





More information about the Squeak-dev mailing list