Greetings,
I've about finished merging my latest OpenMCL code with Slime CVS.
However, the code that compiles the sys-dependent backend in an
EVAL-WHEN in swank.lisp does not work in OpenMCL. (As I understand
the problem, all the DEFMACROs and DEFVARs would need to have
EVAL-WHENs around them as well...)
Following Dan's suggestion in IRC I started on a loader that the Emacs
Lisp calls to compile and load the backend---I've put it up at
http://jamesjb.com/slime/swank-loader.lisp for comments.
One thing we lose if we do it this way is the ability to give the user
the nice "recompile swank?" prompt---we could instead have the elisp
compile each of the backend files but then we cannot automagically
figure the right backend based on *FEATURES*.
(I tried to test the loader under MacOS X SBCL but Swank doesn't seem
to run in my build of 0.8.4., thus only tested in OpenMCL).
Speaking of testing, a few trivial runs of the unit tests with the
OpenMCL backend resulted in 255 failures---after glancing at the code
it looks like it would need a fair bit of work to port.
In particular it doesn't seem to deal very well with unimplemented
slimefuns---perhaps we need a better way to say 'this function is
unimplemented' besides dumping the user into the debugger?
James
--
#:jamesjb
Hi,
SBCL pays careful attention to the distinction between a STYLE-WARNING
(a condition strong enough to warrant returning from COMPILE-FILE with
WARNINGSP set) and a compiler note (generally an optimization note,
but sometimes a code deletion note or something similar), which aren't
counted as warnings.
Attached is a patch to implement this. I know cmucl doesn't have this
distinction; I'm unsure as to whether OpenMCL does, so I've just
implemented it for SBCL; the behaviour of other lisps should be
unchanged.
Cheers,
Christophe
--
http://www-jcsu.jesus.cam.ac.uk/~csr21/ +44 1223 510 299/+44 7729 383 757
(set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b)))
(defvar b "~&Just another Lisp hacker~%") (pprint #36rJesusCollegeCambridge)
Helmut Eller <heller(a)common-lisp.net> writes:
> +(defun read-next-form ()
> + (handler-case
> + (let* ((length (logior (ash (read-byte *emacs-io*) 16)
> + (ash (read-byte *emacs-io*) 8)
> + (read-byte *emacs-io*)))
> + (string (make-string length)))
> + (sys:read-n-bytes *emacs-io* string 0 length)
> + (read-form string))
> + (condition (c)
> + (throw 'serve-request-catcher c))))
OK, so what is the problem with CMUCL that means it can't use
read-sequence here? I know it used to be broken (did partial reads)
but I thought that was fixed ages ago. Can we not report this as a
bug to the cmucl developers?
Thanks for cleaning up my other mess. Now I have to look through your
structure stuff and who-calls, see what I can steal for sbcl :-)
-dan
--
http://web.metacircles.com/cirCLe_CD - Free Software Lisp/Linux distro
