> From: "Roger Vossler" <rvossler at uswest.net>
>
> Howdy,
>     Does Squeak 2.8 or 2.9 run OK under the Classic environment
> of MacOS X (PB at this point). Or, has it been Carbonized? Any
> plans for a natice Cocoa implementation? Thanks for any info?

In addition to the Classic + Carbon versions, there is a Cocoa  
implementation maintained by myself, available from

	http://www.metaobject.com/downloads/Squeak/

I spent some time over the holidays giving this VM a major overhaul,  
and will be posting an update as soon as we have completed the  
switch-over of our web-server to a new machine.

This overhaul fixes some bugs with modifiers keys not working  
properly and the cursor-image changes not showing up, as well as  
improving display speed somewhat.  However, display speed is still  
less than stellar, due in large part to Quartz simply not being  
optimized yet.  I expect this to improve for GM, and am also  
exploring alternatives such as the direct-access APIs as well as  
OpenGL.

The Squeak VM is now encapsulated in an Objective-C object, class  
SqueakInterpreter.  This object provides an API for access to Squeak,  
as well as I/O services for the Squeak VM.  This encapsulation as  
well as the fact that both the generated code and the Objective-C  
cover reside in the Squeak framework mean that it is now fairly easy  
to include a Squeak interpreter in your custom application.  The  
Squeak.app itself, for example, is just a fairly thin wrapper that  
manipulates the SqueakInterpreter object from the framework  
(exception:  the display code, but that will probably be moved to a  
SqueakUI framework soon).

To run a Squeak interpreter with an image:

	id interpreter = [SqueakInterpreter interpreter];
	[interpreter readImageFile: @"great.image" withHeapSize: 64  
* 1024 * 1024];
	[interpreter startInterpreter];
or
	[interpreter startInterpreterInSeparateThread];

That would be a headless interpreter, and due to all the global  
variables in the generated code, you can only run a single (shared)  
instance at a time.  One solution to that problem is to generate the  
interpreter as an Objective-C class/object instead, turning the  
current global variables into instance variables of the object.  The  
Objective-C generator code I've started working on again now  
generates a compilable Interpreter class (subclass of ObjectMemory),  
and I am fairly sure that I am not too far away from a runnable  
version.  At that point, I will be able to eliminate that pesky C  
glue code, and have the interpreter send messages to its VM.

Another one of the next steps will be a really simple and somewhat  
restricted call-in facility to Squeak based on the event mechanism.   
That together with the (separate) call-out facility of the  
Objective-C bridge should be enough to at the very least experiment  
with integrating Squeak and Cocoa.

Marcel