Examples of API

lex at cc.gatech.edu lex at cc.gatech.edu
Thu Nov 12 18:55:19 UTC 1998


"Richard L. Peskin" <rlpcon at vermontel.net> wrote:

> Anyway SCENE depended heavily on a couple of available technologies:
> 1. User added primitives. (These can be done in Squeak as far as I can see.)
> 2. Enhanced garbage collector for symbolic algebra. (You have helped me
> deal with this one.)
> 3. Interaction with external (non-Smalltalk) processes. (It is this need
> that I am having trouble seeing how to accomplish in Squeak.)
> 
> 3. was critical to SCENE. For example, under SCENE a user could
> interactively ask for a mathematical data filter operation and SCENE would
> generate the C code for the filter and then invoke the system C compiler to
> generate code, and then use this code to filter the data set finally
> returning the results back to SCENE for visualization. (While the
> equivalent could be done entirely inside Smalltalk, the data sets were too
> large for reasonable performance.) To implement this (Unix versions only)
> we actually wrote AppleEvents for Unix to handle the event interchange.)
> 
[...]
> >From what I can see, the Socket classes are limited to TCP/IP services,
> although the comments indicate that "someday" they might be used for IPC.
> Will the your  API work be useful for our objectives? Do you know of any
> other work that I might look at? What would really be nice is if Squeak
> offered the same sort of inter-process communication that exists in Tk and
> Python.
> 

....and emacs.

I agree, though my interest is different.  I think Squeak could make a great OS interface for Unix users, if only there were a way to access external entities in the system.  The main facilities needed are:
	
	1. external processes
	2. pipes to talk to them

In other words, popen() for Smalltalk.

Right now, neither external processes or Unix pipes are directly supported in Squeak.  It's also unlikely that such platform-specific features will ever end up in the core system.  However, it would still be nice to have, as an add-on.



Lex





More information about the Squeak-dev mailing list