Dear SLIME developers (hi Luke!)
Well, ILISP has been annoying me _SO_ much recently I figured it may finally be time to do something about it; then I stumbled on this project.
I realize (from reading your sources so far) that you're focussing on CMUCL and SBCL; however, if the intent is to try to make the protocol sufficiently general/portable to other Lisps, I hereby volunteer my services as Lispworks user/tester/debugger (and even, initially) porter of whatever LW specific code needs to be written to get SLIME going on LW.
I can't promise I have a lot of time to devote to this, so I'll be happy to pass the ball on to whoever wants to take this up next, but one is greater than zero, so I'm willing to give this a go, if the concensus of this list is that this is a) feasible b) a good idea
So let me know your thoughts. (I won't be offended if you think such an effort is undesirable or premature, so feel free to speak your collective minds).
yours, --Alain Picard
G'day Alain!
I realize (from reading your sources so far) that you're focussing on CMUCL and SBCL; however, if the intent is to try to make the protocol sufficiently general/portable to other Lisps, I hereby volunteer my services as Lispworks user/tester/debugger (and even, initially) porter of whatever LW specific code needs to be written to get SLIME going on LW.
Great! The OpenMCL backend is currently the shortest/simplest, so I would guess the easiest approach it to port that to LispWorks.
If you write that, we can run the test suite against LispWorks along with the other backends. That way we can avoid breaking it during restructurings. I just installed LispWorks Personal Edition for Linux, which was painless, so I think this will work.
As you've probably noticed, we're just taking the first steps in creating a sane way to interface the backend-specific code with the common stuff, so everything will change a fair bit in the coming weeks. That said, personally I would be happy to have a LispWorks backend in any time -- I don't think it will be much extra work to maintain, and it would be good to support it.
And we may even trick you into writing some code that benefits the other backends too. :-)
Cheers, Luke
Luke Gorrie writes:
Great! The OpenMCL backend is currently the shortest/simplest, so I would guess the easiest approach it to port that to LispWorks.
Okay. I'll start with that.
If you write that, we can run the test suite against LispWorks along
There's a test suite?! Wow. ;-)
And we may even trick you into writing some code that benefits the other backends too. :-)
Who knows. It's been known to happen before. :-)
I'll report back when I have something basic going.
Cheers!
Alain.Picard@memetrics.com writes:
Luke Gorrie writes:
Great! The OpenMCL backend is currently the shortest/simplest, so I would guess the easiest approach it to port that to LispWorks.
Okay. I'll start with that.
If you write that, we can run the test suite against LispWorks along
There's a test suite?! Wow. ;-)
You can run it with `M-x slime-run-tests'. It even has a pretty outline-mode interface :-). There're some shell scripts for running it in batch-mode with different Lisp/Emacs combinations too. If you want to do that you can find some details in the thread starting from http://article.gmane.org/gmane.lisp.slime.devel/36
Some of the cases are currently CMUCL-specific (e.g. expecting edit-definition to find CMUCL sources). Will fix :-)
-Luke
Luke Gorrie writes:
Alain.Picard@memetrics.com writes:
Luke Gorrie writes:
Great! The OpenMCL backend is currently the shortest/simplest, so I would guess the easiest approach it to port that to LispWorks.
Okay. I'll start with that.
If you write that, we can run the test suite against LispWorks along
There's a test suite?! Wow. ;-)
You can run it with `M-x slime-run-tests'. It even has a pretty
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
[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.
Current results are: Failed on 5 of 19 tests.
* find-definition ** input: (list list.lisp) Definition of `list' is in "list.lisp". Definition now at point. Returning from definition restores original buffer/position. ** input: (loop loop.lisp) Definition of `loop' is in "loop.lisp". Definition now at point. Returning from definition restores original buffer/position. ** input: (aref array.lisp) Definition of `aref' is in "array.lisp". Definition now at point. Returning from definition restores original buffer/position. * 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. ** input: (cl:foobar nil) Completion set is as expected. ** input: (cl::compile-file (cl::compile-file cl::compile-file-pathname)) Completion set is as expected. * arglist ** input: (list (list &rest args)) Argument list "(list &rest args)" is as expected. ** 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. * compile-defun ** input: ((defun :foo () (:bar)) (:bar)) error-location-correct ** input: ((defun :foo () #\space ;;Sdf (:bar)) (:bar)) error-location-correct ** input: ((defun :foo () #+(or)skipped #| #||# #||# |# (:bar)) (:bar)) error-location-correct ** input: ((defun :foo () (list `(1 ,(random 10) 2 ,@(random 10) 3 ,(:bar)))) (:bar)) FAILED: error-location-correct * async-eval-debugging ** input: (1) Automaton initially in idle state. Automaton stack reflects debug level 1. Maximum depth reached (1) is 1. Automaton is back in idle state. ** input: (2) Automaton initially in idle state. Automaton stack reflects debug level 1. Automaton stack reflects debug level 2. Maximum depth reached (2) is 2. Automaton is back in idle state. ** input: (3) Automaton initially in idle state. Automaton stack reflects debug level 1. Automaton stack reflects debug level 2. Automaton stack reflects debug level 3. Maximum depth reached (3) is 3. Automaton is back in idle state. * loop-interrupt-quit ** input: nil Automaton initially in idle state. In eval state. First interrupt. Automaton is back in idle state. * loop-interrupt-continue-interrupt-quit ** input: nil Automaton initially in idle state. In eval state. First interrupt. No sldb buffer. In eval state. Second interrupt. Automaton is back in idle state. * interactive-eval ** input: nil Automaton is back in idle state. FAILED: Minibuffer contains: "=> t"
Note that to start all this, I have to first load slime, do M-x slime; I get an error in cmucl: ; Compilation unit aborted. ; 2 notes
; Compilation aborted after 0:00:01. ;; Loading #p"/home/ap/Lisp/slime/swank-cmucl.lisp".
Reader error at 11874 on #<Stream for file "/home/ap/Lisp/slime/swank-cmucl.lisp">: Symbol "WHO-MACROEXPANDS" not found in the XREF package.
Restarts: 0: [CONTINUE] Use symbol anyway. 1: Return NIL from load of #p"/home/ap/Lisp/slime/swank-cmucl.lisp". 2: Return NIL from load of "/home/ap/Lisp/slime/swank-loader". 3: [ABORT ] Return to Top-Level.
Debug (type H for help)
(COMMON-LISP::READ-TOKEN #<Stream for file "/home/ap/Lisp/slime/swank-cmucl.lisp"> #\x) Source: ; File: target:code/reader.lisp (WITH-SIMPLE-RESTART (CONTINUE "Use symbol anyway.") (ERROR 'READER-PACKAGE-ERROR :STREAM STREAM :FORMAT-ARGUMENTS ...))
Continuing:
0] :c 0 T
And manually starting the server
* (swank:start-server)
;; Swank ready.
lets me run the tests.
Enough for tonight...
Cheers.
Alain.Picard@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
Luke Gorrie luke@bluetail.com writes:
The incompatibility with 18e is very slight - we're using some xref functions that didn't exist - so it should be easy to "port".
This would have been easier done than said, so, I did it. SLIME now works with CMUCL 18e, but without the `who-macroexpands' command.
Even remembered to update the README. :-)
Haven't fixed the spurious test failures yet.
-Luke
Luke Gorrie luke@bluetail.com writes:
* 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.
I have (setq *print-case* :downcase) in my .cmucl-init.lisp and the test failed if *print-case* is :upcase. Should be fixed in CVS.
--helmut.
Helmut Eller e9626484@stud3.tuwien.ac.at writes:
Luke Gorrie luke@bluetail.com writes:
* 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.
I have (setq *print-case* :downcase) in my .cmucl-init.lisp and the test failed if *print-case* is :upcase. Should be fixed in CVS.
Nice one. I updated the edit-definition/arglist tests to lookup symbols in swank.lisp so they should be portable. Tested with previously-not-working CMUCL 18e and SBCL.
Alain, when you wake up, CMU18e should work fine and only fail the place-note-within-backquote test case.
-Luke
Alain.Picard@memetrics.com writes:
[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 would like to fix this, but I can't find this `noutline' package anywhere - what is it? I notice that the outline.el that ships with GNU Emacs includes a "(provide 'noutline)" so I'm assuming it's an alternative implementation of outline-mode?
If you send me noutline.el or, a patch to slime.el with the appropriate fboundp check or what-have-you, I'll be glad to commit a fix. Of course you shouldn't have to use "emacs -q" to run SLIME.
-Luke
Luke Gorrie writes:
Alain.Picard@memetrics.com writes:
[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 would like to fix this, but I can't find this `noutline' package anywhere - what is it? I notice that the outline.el that ships with GNU Emacs includes a "(provide 'noutline)" so I'm assuming it's an alternative implementation of outline-mode?
If you send me noutline.el or, a patch to slime.el with the appropriate fboundp check or what-have-you, I'll be glad to commit a fix. Of course you shouldn't have to use "emacs -q" to run SLIME.
Sorry, my bad (an old mode I used years ago). The outline package I'm using now is allout.el.
And both M-x slime and slime-run-tests are running properly now. Weird. Did somebody fix this behind our backs?
Alain.Picard@memetrics.com writes:
I realize (from reading your sources so far) that you're focussing on CMUCL and SBCL; however, if the intent is to try to make the protocol sufficiently general/portable to other Lisps, I hereby volunteer my services as Lispworks user/tester/debugger (and even, initially) porter of whatever LW specific code needs to be written to get SLIME going on LW.
I've committed a first version of a Lispworks backend. It would be great if you could give it a try. This backend supports about the same features as the OpenMCL backend.
With the Personal Edition you can load it like:
(load "/home/helmut/lisp/slime/swank-loader.lisp") (swank::create-swank-server 4005)
and use M-x slime-connect to start a session.
Helmut.
Helmut Eller e9626484@stud3.tuwien.ac.at writes:
I've committed a first version of a Lispworks backend.
Works for me!
-
Alain.Picard＠memetrics.com -
Helmut Eller -
Luke Gorrie