[slime-devel] SLIME and Lispworks?
luke at bluetail.com
Mon Oct 20 13:39:45 UTC 2003
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.
> ** 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.
More information about the slime-devel