[slime-devel] OpenMCL

[Helmut Eller]

Sven Van Caekenberghe <sven at beta9.be> writes:

> Yesterday, we have been using SLIME on OpenMCL the whole day - and
> yes, we are happy ! Thank you all.

Glad to hear.

> However, there is a problem in the debugger connection in cvs head (as
> compared to the version we checked out 2 days ago): an undefined
> function like (foo) gives an (presumably emacs) error: error in
> process filter: Assertion failed: (<= (length frames) maximum-length)
> - and as far as we understand SLIME, everything is broken/lost
> then. It is a bit hard to use SLIME without entering the lisp debugger
> ;-)

I couldn't reproduce this.  Are you using XEmacs or Emacs? 
Until we know what the problem is, you can disable the SLIME debugger
by placing something like this into your .swank.lisp:

  (defun swank-debugger-hook (e c) )

Errors will put you in the normal tty-debugger in the slime-repl
buffer.

> One of the reasons that we like SLIME so much is the fact that it
> doesn't choke on asynchroneous output (as ILISP does): when working
> with a multithreaded server that makes all the difference in the
> world. The output that non-evaluator threads write to stdout goes to
> the inferior lisp buffer, we can live with that, but maybe it would be
> nicer if (optionally) that output was inserted in the normal SLIME
> REPL buffer (maybe in some other color) - is that possible, maybe the
> behavior is different on other platforms ?

That's not yet implemented :-) SLIME is currently only able to talk to
a single thread.  We hope that we can support this in the future, but
progress is a bit slow in this direction.

> Also, on one machine, some of the output is 'undecorated', on an other
> it looks like this:
> 
> ..^@^@\213(:read-output "127.0.0.1 - - [Fri, 12 Dec 2003 08:51:02
> GMT] \"GET /ha-dynsite/webaction?action=show-current-calendar
> HTTP/1.1\" 200 -1
> ")
> 
> Where does the difference come from ? Are only some streams redirected
> properly ?

This can happen when you write to a redirected stream from a different
thread, or generally when *emacs-io* is not correctly bound.
Redirection only works as long as you are in the dynamic extend of
SLIME's request-loop.

Helmut.