[Openmcl-devel] Problems with asdf-install

Gary Byers gb at clozure.com
Mon Jan 2 21:55:18 PST 2006

On Mon, 2 Jan 2006, Ralph Richard Cook wrote:

> Backtrace follows. When starting OpenMCL standalone I don't have a problem, 
> it's just when going through Emacs/Slime

The trouble seems to start with a call to WARN-UNIMPLEMENTED-INTERFACES;
after the warning is printed (buffered) to *ERROR-OUTPUT*, the function
things go downhill from there.

One of the first things that happens when a saved image starts up
(the slightly simplified version) is that *TERMINAL-IO* gets SETQed
to a two-way stream made from an input stream to file descriptor 0
and an output stream to file descriptor 1; the other standard streams
are ordinarily made to be synonym streams to *TERMINAL-IO*.  (This
happens in the initial thread, and there isn't too much that happens
before this happens.)

Before this happens, the value of *TERMINAL-IO* is the value that
it had in the old (pre-SAVE-APPLICATION) image.  That value usually
becomes garbage as soon as the "new" *TERMINAL-IO* is created, but
(even though it's also a two-way stream to file descriptors 0 an 1)
it probably won't work to do I/O to it: pointers to buffers will
have been turned into "dead macptrs", since the #_malloc'ed memory
they use doesn't really exist in the new image.  (The buffering
is actually implemented by #_malloc'ing some memory an making it
look enough like a character or byte vector that things like SCHAR
and AREF work on it.  The lisp string or vector will still be in
the "defunct" stream, but its address will be "where the #_malloc'ed
memory used to be, and maybe something else is now.")

Slime/swank seem to hold onto "current" and "real" values of the
implementation's standard streams (in special variables like
values of these variables aren't reset or cleared when an image
is saved or when it starts up.  These variables are defined via

The short version of the story is that if you save an image with
Slime/Swank loaded into it in OpenMCL, Swank's notion of the values
of the "real" standard stream values is yesterday's news (established
before the SAVE-APPLICATION and never reset.)  Around the time that
SLIME finishes compiling/loading itself, it apparently sets *TERMINAL-IO*
to its (stale) notion of what the "real" *TERMINAL-IO* should be, 
and that can't work.  (It's not necessary to use ASDF-INSTALL or to
try to load PASERVE or to do much of anything else in order to trigger

I can think of a few ways around this; which way or ways would work
best depend on whether invoking SLIME always tries to load the swank
stuff even if it's already present in the image.  (If so, a very
simple fix would be to change the DEFVARs in swank.lisp's

More information about the Openmcl-devel mailing list