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