Lex writes:

> Well, you *can* write pluggable primitives straight in C--I've in fact
> been doing so a little.  But maybe this is a deprecated way to do
> things?

Sure you can do that.  But why?  The virtue of doing in in Squeak to 
generate the C-Code is that you can play with a dynamic, solid 
user-friendly environment to debug your code when the primitive 
fails.  If the primitive fails, the interpreter takes over, and you 
have everything you need to figure out the problem, with full access 
to inspectors, browsers, et al.

By doing it this way, you can interactively tinker with your c-code, 
testing it and changing it as you need to do so, bypassing to a great 
extent the burdens of the traditional c-code, edit, compile and run 
cycle.  You can use the code generator to get code reading virtually 
anyway you'd like in the c-module, and you can link in c-language 
code to do anything you think you can't do in Squeak.

-----

The only difficulty I am having with pluggables, whether implemented 
in Squeak or directly in C, is memory management.  While it is 
trivial to get blocks of memory to work with for each individual call 
-- Just generate a byte-array of the appropriate size, either by 
parameter, method variable or using interpreterProxy, and then get 
the location of the buffer from the object -- the "hard" addresses 
cannot be trusted after returing to the interpreter due to relocation 
in the garbage collector.

There are ways, of course, to finesse that problem in some cases. 
The memory block can be allocated and stored as an object in an 
instance variable of the caller or elsewhere.  Then, the variable is 
polled each call for the present address, and offsets into that block 
can be used in lieu of internal addresses.

Has anyone figured out a way to "Steal" a block of memory, either 
from squeak or the operating system, in order to set up a heap in 
which the primitive can deal with memory in the traditional 
malloc/free manner, or, in the alternative, a way to interact safely 
with the garbage collector that would be transparent to a malloc/free 
central C-language library?  For example, in Macland, would calls to 
NewPtr or NewHandle for a "private heap" or to substitute for 
malloc/free calls screw up the mainline?

Clearly, such uses of external resources imply some need for care and 
use of the finalization routines.  However, it would be useful to be 
able to write squeak wrappers for the massive amount of useful 
existing Open Source libraries already out there.