Hello,
what features would be required of a Common Lisp system to actually support a (minimally) usable SLIME ?
Regards,
Julian Stecklina der_julian@web.de writes:
what features would be required of a Common Lisp system to actually support a (minimally) usable SLIME ?
First, the Lisp system should be complete enough to actually compile the code in swank.lisp. That may sound trivial, but, e.g., ECL cannot. Also GCL has apparently incomplete readtables, so that some tests must be disabled before the fasl file can be loaded.
Second, support for server sockets and the ability to turn client sockets into streams. This is a must.
At this point it's usually possible to connect to the Lisp and to do simple evaluations. Symbol completion is also works very early.
For a little debugging comfort you have a implement a way to produce a backtrace. The backtrace could be empty, but debugging without backtrace is no fun.
I'd say this is about the minimal support needed. The rest can be added incrementally.
If you want to use the REPL, you have to implement streams to redirect the output to Emacs. If the implementation supports Gray streams you can use the code in swank-gray.lisp. You have to disable output redirection until the streams are implemented and the output will show up the *inferior-lisp* buffer.
A good M-. (find-definitions) implementation is IMO the most important feature for real work.
Helmut.
Helmut Eller e9626484@stud3.tuwien.ac.at writes:
Julian Stecklina der_julian@web.de writes:
what features would be required of a Common Lisp system to actually support a (minimally) usable SLIME ?
First, the Lisp system should be complete enough to actually compile the code in swank.lisp. That may sound trivial, but, e.g., ECL cannot. Also GCL has apparently incomplete readtables, so that some tests must be disabled before the fasl file can be loaded.
Are there any particular features ECL is missing? (I am going to try that tomorrow, so there is no need for you to investigate, if you do not already know.)
Second, support for server sockets and the ability to turn client sockets into streams. This is a must.
This will probably work with ECL.
At this point it's usually possible to connect to the Lisp and to do simple evaluations. Symbol completion is also works very early.
Hopefully. ;)
If you want to use the REPL, you have to implement streams to redirect the output to Emacs. If the implementation supports Gray streams you can use the code in swank-gray.lisp. You have to disable output redirection until the streams are implemented and the output will show up the *inferior-lisp* buffer.
You can write your own stream classes via some CLOS magic in ECL. Hopefully I can hack this into a proper Gray streams interface. :)
Thanks for the information. If anything usable turns up, I'll report back to the list.
Regards,
Julian Stecklina der_julian@web.de writes:
Are there any particular features ECL is missing? (I am going to try that tomorrow, so there is no need for you to investigate, if you do not already know.)
Well, the compiler breaks. First, ECL barfs on methods without arguments. This can be worked around with some #+ecl kludges, but later an internal compiler error is triggered.
You can write your own stream classes via some CLOS magic in ECL. Hopefully I can hack this into a proper Gray streams interface. :)
Thanks for the information. If anything usable turns up, I'll report back to the list.
Below is a half working GCL backend. To make it work you have to disable some of the tests in swank.lisp and add this to your .swank.lisp:
#+gcl (progn (setq swank::*use-dedicated-output-stream* nil) (setq swank::*redirect-io* nil))
Helmut Eller e9626484@stud3.tuwien.ac.at writes:
Julian Stecklina der_julian@web.de writes:
Are there any particular features ECL is missing? (I am going to try that tomorrow, so there is no need for you to investigate, if you do not already know.)
Well, the compiler breaks. First, ECL barfs on methods without arguments. This can be worked around with some #+ecl kludges, but later an internal compiler error is triggered.
I fixed the method bug, and I am at the moment unable to reproduce the compiler bug. Good news. :)
Below is a half working GCL backend.
Thanks very much!
Regards,
-
Helmut Eller -
Julian Stecklina