Sven Van Caekenberghe sven@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.