[slime-devel] Package split
I just merged my package-split branch into the main trunk. We have now a new package SWANK-BACKEND. It is basically stand-alone and doesn't need the rest of SWANK. Of course, SWANK calls functions in the backend. I moved some functionality like handling of restarts and a lot symbol-to-string conversion to swank.lisp. The load order is now: swank-loader, swank-backend, swank-[cmucl,sbcl...], swank This means, we could define macros in the backend and use them in SWANK. I tested a bit with my usual implementations. I added the necessary changes for OpenMCL, but don't know if they actually work. Feedback welcome. Helmut.
Helmut Eller writes:
I just merged my package-split branch into the main trunk. We have now a new package SWANK-BACKEND. It is basically stand-alone and doesn't need the rest of SWANK. Of course, SWANK calls functions in the backend. I moved some functionality like handling of restarts and a lot symbol-to-string conversion to swank.lisp. The load order is now:
swank-loader, swank-backend, swank-[cmucl,sbcl...], swank
This means, we could define macros in the backend and use them in SWANK.
I tested a bit with my usual implementations. I added the necessary changes for OpenMCL, but don't know if they actually work. Feedback welcome.
Doesn't seem to work for sbcl 0.8.8.3 under FreeBSD - I'm getting load errors for swank-source-path-parser. I also saw references to "unknown package SWANK", so I'm guessing that the compile/load order is wrong for SBCL. -- Raymond Wiker Mail: Raymond.Wiker@fast.no Senior Software Engineer Web: http://www.fast.no/ Fast Search & Transfer ASA Phone: +47 23 01 11 60 P.O. Box 1677 Vika Fax: +47 35 54 87 99 NO-0120 Oslo, NORWAY Mob: +47 48 01 11 60 Try FAST Search: http://alltheweb.com/
Raymond Wiker writes:
Helmut Eller writes:
I just merged my package-split branch into the main trunk. We have now a new package SWANK-BACKEND. It is basically stand-alone and doesn't need the rest of SWANK. Of course, SWANK calls functions in the backend. I moved some functionality like handling of restarts and a lot symbol-to-string conversion to swank.lisp. The load order is now:
swank-loader, swank-backend, swank-[cmucl,sbcl...], swank
This means, we could define macros in the backend and use them in SWANK.
I tested a bit with my usual implementations. I added the necessary changes for OpenMCL, but don't know if they actually work. Feedback welcome.
Doesn't seem to work for sbcl 0.8.8.3 under FreeBSD - I'm getting load errors for swank-source-path-parser. I also saw references to "unknown package SWANK", so I'm guessing that the compile/load order is wrong for SBCL.
Hmmm... I replaced (in-package :swank) with (in-package :swank-backend) in swank-source-path-parser.lisp and swank-gray.lisp; that seemed to solve the problem. -- Raymond Wiker Mail: Raymond.Wiker@fast.no Senior Software Engineer Web: http://www.fast.no/ Fast Search & Transfer ASA Phone: +47 23 01 11 60 P.O. Box 1677 Vika Fax: +47 35 54 87 99 NO-0120 Oslo, NORWAY Mob: +47 48 01 11 60 Try FAST Search: http://alltheweb.com/
Raymond Wiker <Raymond.Wiker@fast.no> writes:
Hmmm... I replaced
(in-package :swank)
with
(in-package :swank-backend)
in swank-source-path-parser.lisp and swank-gray.lisp; that seemed to solve the problem.
Ah yes. I had forgotten to commit these two files. Thanks for the note. Helmut.
Helmut Eller <e9626484@stud3.tuwien.ac.at> writes:
I just merged my package-split branch into the main trunk. We have now a new package SWANK-BACKEND. It is basically stand-alone and doesn't need the rest of SWANK. Of course, SWANK calls functions in the backend. I moved some functionality like handling of restarts and a lot symbol-to-string conversion to swank.lisp. The load order is now:
swank-loader, swank-backend, swank-[cmucl,sbcl...], swank
This means, we could define macros in the backend and use them in SWANK.
So I take it the idea is that the decision of whether a given piece of portable code should go in swank-backend or swank is determined by whether it is needed by the swank-<impl>. I.e. portable code used from the swank-<impl> files obviously has to go in swank-backend. Should all other non-implementation dependent code go in swank? -Peter -- Peter Seibel peter@javamonkey.com Lisp is the red pill. -- John Fraser, comp.lang.lisp
Peter Seibel <peter@javamonkey.com> writes:
So I take it the idea is that the decision of whether a given piece of portable code should go in swank-backend or swank is determined by whether it is needed by the swank-<impl>. I.e. portable code used from the swank-<impl> files obviously has to go in swank-backend. Should all other non-implementation dependent code go in swank?
Yes, sounds like the natural approach to me. The primary purpose of the backend is to provide an interface to non-standardized functionality, so I don't think there is much code that can be shared between the swank-<impl> files. Perhaps some utility functions. The rest will be concerned with the definition of the "protocol", defgenerics, defconditions and defstructs. Helmut.
The "view source" command in the debugger now causes a reader error: The symbol "FRAME-SOURCE-LOCATION-FOR-EMACS" is not external in the SWANK package. The "continue" restart works, but perhaps the symbol should be exported? -- Jouni K Seppänen
Jouni K Seppanen <jks@iki.fi> writes:
The "view source" command in the debugger now causes a reader error:
The symbol "FRAME-SOURCE-LOCATION-FOR-EMACS" is not external in the SWANK package.
The "continue" restart works, but perhaps the symbol should be exported?
Yes, exporting fixes the problem. Done it CVS. Thanks. Helmut.
participants (4)
-
Helmut Eller -
Jouni K Seppanen -
Peter Seibel -
Raymond Wiker