Hi Squeakers,

To support using Squeak in embedded systems and memory-constrained ones
like Newtons, I'm exploring the idea of making a headless version of
Squeak with minimal footprint that can be remotely interacted with from
a headed Squeak via TCP/IP. Tools such as these might also be useful for
debugging "headless" Squeak images embedded in applications like web
browsers or web servers.

I am wondering if anyone else is working or has worked in this area. A
few questions:
1. Has anyone already ported Squeak to a real-time embedded OS like QNX
or VxWorks? How long do you think it would take for bare bones support?
2. Has anyone developed a cross-development system for Squeak (debugging
one image from another?) Are such readily available under an open source
license from any source?
3. Has anyone got tools for building up an image from scratch?  I know
there was talk a year or so back about someone rebuilding the Squeak
image from scratch. How was that done?
4. Has anyone else split the Squeak source into independently loadable
packages?
5. Does the headless code work well? Is there anything I would need to
improve on right away to make this practical? Has debugging such
applications been difficult in the past?
6. Can people think of other useful reasons to have such tools?
7. Anyone have any other generally useful advice in this endeavor?

Some more background:

You can do remote debugging now with VisualAge Smalltalk to remotely
debug a headless Smalltalk image running on a mainframe. 

Pocket Smalltalk for the Pilot by Andrew Brault.
http://www.tiac.net/users/ajb/pocketst/index.html 
is an example of a cross-compiler from Dolphin Smalltalk to an
essentially headless Pilot Smalltalk VM (in the emulated widgets sense)
that talks to host windows. 

What I want to do ideally is a combination of the VisualAge remote
development idea with the Pocket Smalltalk lightness focus. I think OTI
embedded Smalltalk may work much like this. I'm thinking about taking
these general ideas and making them work with Squeak bytecodes, Squeak
classes, and Squeak 32-bit architecture.

I'm willing to let real-time issues slide for now (like semaphores and
GC delays and hooking Interrupt Service Routines), although obviously
one would want to add support for these eventually. My key interest at
the moment is in getting a system that is small and which can direct
(not implement) real-time processes, and for which the compiler and
development environment on the target is optional. 

Here is what I have in mind as an ideal: 
You compile the core VM for your target (remote) system with various OS
hooks and get it there somehow. You then run that VM on the target,
without an image. The VM goes into a receptive/debugging mode. You then
open a TCP/IP connection (or maybe just plain serial) to that VM from a
Squeak image on another (local) machine (or even the same one). The VM
communications support is at the level of just accepting a few simple
commands for loading and storing to memory, and modifying the VM
registers. You manipulate the VM of the target system using the full
image on the development machine. You can compile methods to bytecodes
locally, and then download the bytecodes (with or without source) to the
target. If you want, you can compile the compiler and supporting classes
and put it on the target.

To reach this ideal, I need to:
* Modify the VM to support remote control (inserting of new objects,
single stepping, reading/writing of memory). This VM might be slower
then usual because of an extra "if (debugging)" check in the main
byte-code loop, and could be replaced by a non-debugging version when
development was done.
* Understand how the Squeak image is put together well enough to build
one from scratch. This would also include disentangling the Squeak
classes into independent packages which built on each other.
* Build tools in Squeak for controlling this remote VM. This might
entail only minor changes to the existing development tools, so the
tools know they are interacting with code and processes for a remote
system.
* Figure out a way to have this approach remain compatible with the
existing Squeak VM architecture and code, so it does not get left behind
with new releases.

I know I can do small scale development much more simply with the
approach of developing under a general Squeak system on another platform
and then stripping a big image down. However, ideally I'd like something
that feels cleaner and less monolithic, by building up from zero objects
in the image. Also, I'd like to be able to modify the target system
remotely in any case (if it is headless), although of course I could do
this at the Smalltalk (not VM) level, although with less fine control.

I have a couple days around now to work on this (mainly figuring out how
difficult the task would be), and probably some more time near the end
of December. Collaborators are welcome, as long as we all agree to put
the collective results back under the Squeak license.

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