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 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'mgetting 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 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 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 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.
-
Helmut Eller -
Jouni K Seppanen -
Peter Seibel -
Raymond Wiker