Re: [spr1624] Allegro-Emacs interface on NeXT

[cox@Franz.COM (Charles A. Cox)]

> Date: Wed, 20 Jun 90 16:14:50 GMT-0700
> From: silbar%whistler@LANL.GOV (Dick Silbar)
> 
> OK, first question: why does Allegro come up loading things like
> 	; Fast loading /usr/cl/lib/code/ipc.fasl.
> 	; Fast loading /usr/cl/lib/code/process.fasl.
> 	; Fast loading /usr/cl/lib/code/foreign.fasl.
> 	; Fast loading /usr/cl/lib/code/cstructs.fasl.
> 	; Fast loading /usr/cl/lib/code/emacs.fasl.
> 	; Fast loading /usr/cl/lib/code/mdproc.fasl.
> OK, ipc and emacs (and maybe process) I can believe should be there, 
> 
> but why foreign, cstructs, and mdproc?

The default Allegro CL image leaves out several extensions from the
base image which are automatically loaded ("autoload"ed) when needed.
These include features such foreign-functions, multiprocessing,
tracing, flavors, etc.

What you're seeing above is autoloading taking place for those
extensions needed to run the backdoor interface to GNU emacs.  You
won't see these messages if you start up Allegro in a shell outside of
emacs.

Specifically, ipc.fasl is needed for the IPC sockets that are set up
between GNU emacs and Allegro CL.  IPC, in turn, requires the foreign
function interface and the cstructs package (since C structures are
passed between Lisp and IPC library routines).  Also, since the
"backdoor" is really just a lisp listener running in the same main
Allegro process, Allegro needs to load in and start up its
multiprocessing scheduler (which brings in process.fasl and
mdproc.fasl).  

Finally, emacs.fasl contains extra functions that allows you to do
fancy things like lisp symbol name completion (by consulting the lisp
to see which symbols of your desired prefix are already interned).
For more information about emacs.fasl, you can look at the source on
NeXT machines in /usr/lib/emacs/lisp/fi/emacs.cl.

To make Allegro CL start up faster when running under emacs with the
backdoor interface, you can build these modules into your base Allegro
CL image.  This can be done by adding the following lines to your
/usr/cl/build/custom.cl file and then reinstalling Allegro CL:

 (require :ipc)
 (require :mdproc)
 (require :emacs)

> Then, the major question: I can then bring in a *.lisp file in a
> separate buffer and execute, say, the previous s-expression with
> <c-C><c-S>.  The interface does in fact DO this but in a funny
> way (or, funny to me).  It writes out the region being evaluated
> to a temporary file, which is then loaded into the Lisp world.  

Even though there is a fairly tight coupling between Allegro and GNU
emacs with the backdoor interface, the Allegro and GNU emacs processes
are still separate.  Thus, if you want to have an s-expression in one
of your emacs buffers evaluated by the main Allegro lisp listener
(usually the *common-lisp* emacs buffer), emacs has to transmit that
s-expression through the Allegro CL subprocess buffer (or
"frontdoor").

It is possible to actually "stuff" s-expressions into the
*common-lisp* buffer (eg, by doing something like mark-sexp (ESC C-@)
followed by copy-region-as-kill (ESC w) followed by going to the
*common-lisp* buffer and doing yank (C-y) followed by RET).  This
makes it look to the Allegro listener as if you had typed in the exact
s-expression as it appeared in the s-expression's original buffer.

Although, this will work and an emacs function which does this could
easily be written and bound to a key, there are at least two problems
(that I know of) that can occur with this approach.  First, the
s-expression may refer to symbols in packages not used by the
listener's current value of *package*.  The other problem is that
since GNU emacs uses a pseudo-tty (pty) to communicate with the
Allegro subprocess, it is possible to overflow the pty's input buffer
if you have a string of more than 256 characters without any
intervening newlines.  This latter problem occurs less often, but it
is something one has to watch for.

Therefore, to be perfectly safe, the Allegro-GNU interface writes the
s-expression to a temporary file and has Allegro call LOAD on that
file.  An appropriate (in-package ...) is put at the head of the
temporary file based on the package specified in the s-expression's
buffer being editted.  Also, loading files doesn't cause pty buffer
overload problems.

It is true that you lose seeing the interaction of how lisp reacts to
each s-expression this way.  However, you can set the emacs variable
fi:echo-evals-from-buffer-in-listener-p to t to see the s-expressions
echoed as they are loaded into lisp.

	Charley