obrien@aero.UUCP (09/17/87)
As powerful personal engines become increasingly available, Smalltalk-80
is finally starting to come into its own. However, by entering the
real world, it becomes subject to the laws of the real world: it must
finally be made able to call foreign functions, talk to foreign
processes, etc.
The question of how to carry this out is as yet unresolved. There
are (at least) two approaches to take:
1) Smalltalk should be as small and simple as possible. Abstractions
should be simple. Programming should be fun.
This is the attitude taken by ParcPlace Systems in providing socket
capabilities in their VI2.2/VM1.1 release. It is a persuasive
argument. One merely provides a host name and a socket number, and
a ReadWriteStream to goodness-knows-what comes into existence.
2) Networking and IPC are hard no matter what you do. Low-level
primitives should be provided and people should roll their own
applications.
This is the attitude ParcPlace Systems started to take in the VI2.1/VM1.0
release, where there were (mostly unimplemented) primitives for all
of the UNIX system calls, and about a million caveats in the code.
It is evident that if we could get away with it, approach (1) is
by far the most attractive. Certainly it is the most seductive.
There are problems, however.
Consider that in the first place, there is no way in the current
implementation to start a remote server under program control.
Servers must be started "by hand" in a terminal window. fork()/exec()
and wait() do not exist.
Secondly, only client connections can be made by this scheme. No
provisions are made for doing a listen(), nor, indeed, for handling
wildcard sockets (randomly chosen port numbers).
Given a more atomic primitive set, I claim that it would be possible to
implement a complete RPC/XDR facility, allowing both UDP and TCP sockets
(the current high-level interface supports only TCP connections).
Further, real remote procedure calls could be implemented, allowing
Smalltalk to call procedures written in any other language supporting
RPC and XDR (this includes both Prolog and C, at the least).
One could argue that such generality could be supported by a smaller
number of more general objects, such as is currently done in, say, class
Pen. Envision, for example:
socket _ Socket new.
socket family: Socket AF_INET.
socket type: Socket UDP.
socket bindToHost: 'hostname'. "Subsumes gethostbyname()"
and so forth. I would have no argument with this, but the class of
primitives would have to be well-thought-out.
Ideally we would want to be able both to call foreign-language functions
and to communicate with (and control!) foreign processes. Currently this
is possible only in Tektronix' implementation, so far as I know.
Comments?
--
--------
Mike O'Brien
obrien@aerospace.aero.org
{sdcrdcf,trwrb}aero!obrienbnfb@uw-june.UUCP (09/18/87)
>[..about communication with external machines and processes..]
Here at the University of Washington, the Heterogeneous Computer
Systems (HCS) Project has implemented Heterogeneous RPC (HRPC).
The goal of HRPC (and HCS) is not to dictate a standard RPC or
interface, but to adapt to what it there. As a result, HRPC is
alive and working from Smalltalk.
It is implemented in Tek Smalltalk, and uses a sub-process to handle
the TCP/IP connections in lieu of appropriate primitives.
However, if such primitives were available...
The key point I'm trying to bring up is that Smalltalk-HRPC provides
classes that handle all the dirty work, and it is quite easy to have
a Smalltalk client talk to C programs, PASCAL programs, Modula2
programs, LISP programs, Mesa Programs, etc.
For more information, contact:
Ed Lazowska lazowska@june.cs.washinton.edu
Sung Kwon Chung sung@june.cs.washington.edu
Bjorn N. Freeman-Bensonjans@tekchips.TEK.COM (Jan Steinman) (09/20/87)
<<<Ideally we would want to be able... to communicate with (and control!)
foreign processes. Currently this is possible only in Tektronix'
implementation, so far as I know.>>>
This is one of the first things I put in an image:
Smalltalk at: #Ksh put:
(OSFilter openOn: '/bin/ksh' withArguments: #('-i')).
Then any application can simply "nextPutAll:" and "nextAvailable" to
communicate with Unix processes, using wildcards and I/O redirection and any
other shell fancies needed. We provide examples for using an OSFilter with sed
and cpp in order to parse an arbitrary ".h" file into a Dictionary of
symbol-value Associations.
Another way we've tried to make Smalltalk and Unix get along is to allow
standard input to file in. This allows Smalltalk to be used inside a Makefile!
This aids considerably when dealing with multi-person projects, allowing
automatic generation of images, as shown in this Makefile fragment:
.st.im:
@echo "!SystemDictionary methodsFor:
'time-versions'!\nversionNumber\n" '"Return the version number of this release
of Tektronix Smalltalk-80."\n\n\ "^'$(@:.im=)'! !\n(Smalltalk
snapshotPrimitive: '$@') isNil\n\tifTrue: [Smalltalk quit].\nSmalltalk
postSnapshot.\nSmalltalk startUp!" | cat $< - | smalltalk
(Warning! Line breaks have been automagically inserted!) When you type "make
X2.3.6.im", make looks for a file named "X2.3.6.st" and files it into Smalltalk
using "cat". When that file-in is finished, the method that defines the
version number is updated, the updated image "X2.3.6.im" is written out, and
smalltalk is exited.
In addition, each Unix system call is accessible from within Tektronix
Smalltalk. We took care to use naming conventions designed to make the use of
such calls easy. In short, if you can do it in C, you can do it in Tek
Smalltalk!
:::::: Software Productivity Technologies --- Smalltalk Project ::::::
:::::: Jan Steinman N7JDB Box 500, MS 50-470 (w)503/627-5881 ::::::
:::::: jans@tekcrl.TEK.COM Beaverton, OR 97077 (h)503/657-7703 ::::::