[slime-devel] SLIME and Lispworks?

[Luke Gorrie]

Alain.Picard at memetrics.com writes:

> It's a nice theory.  However, on my emacs, 
> 
> I get:
> 
> M-x slime-run-tests
> 
> Failed on 24 of 19 tests.
> byte-code: Symbol's function definition is void: hide-body

Embarrassing error message :-) I'll fix it when I get a minute.

> [I discovered that that's because I seem to use NOUTLINE,
> instead of regular OUTLINE.  I'll try to use `emacs -q'
> to do my slime hacking from now on.]
> I'm using cmucl 18e to bootstrap my way into all this.

Currently CMUCL 18e is not supported (like it says in the README
:-)). It's best to bootstrap from the latest CMUCL snapshot in
ftp://cmucl.cons.org/pub/lisp/cmucl/snapshots (it works fine)

The incompatibility with 18e is very slight - we're using some xref
functions that didn't exist - so it should be easy to "port".

>     * complete-symbol
>     ** input: (cl:compile (cl:compile cl:compile-file cl:compile-file-pathname cl:compiled-function cl:compiled-function-p cl:compiler-macro cl:compiler-macro-function))
>     FAILED: Completion set is as expected.

This looks like a case where we assume we're talking to a CMUCL
snapshot, i.e. we expect over-specific results. The test cases still
need to be hacked to come to terms with the reality of multiple
backends by only looking up symbols we've defined ourselves.

>     ** input: (defun (defun &whole source name lambda-list &parse-body (body decls doc)))
>     FAILED: Argument list "(defun &whole source name lambda-list &body (body decls doc))" is as expected.
>     ** input: (cl::defun (cl::defun &whole source name lambda-list &parse-body (body decls doc)))
>     FAILED: Argument list "(cl::defun &whole source name lambda-list &body (body decls doc))" is as expected.

As above.

>     ** input: ((defun :foo () (list `(1 ,(random 10) 2 ,@(random 10) 3 ,(:bar)))) (:bar))
>     FAILED: error-location-correct

This is currently known to fail. Resolving source locations with
backquote is hard and we haven't got it right yet.

>     * interactive-eval
>     ** input: nil
>     Automaton is back in idle state.
>     FAILED: Minibuffer contains: "=> t"

I get this too. This feature and test case went in yesterday and
probably needs debugging.

So, as of CVS right now, there "should" be two failed cases when
running with a CMUCL snapshot.

-Luke