Ahoy,
Did some improvements to the inferior-slime-mode based on helpful feedback: now it's careful about preserving history with multi-line input, and it also indents it as Lisp code. There's also a command on C-RET that closes all your open parenthesis and sends the input to Lisp.
More significantly, I started on The Great Backend Refactoring. This is ultra-disruptive, so I (gag) made a branch: backhackattack-1. The idea is to violently hack things into shape, initially only with the CMUCL backend, and then, only when it's right, update the other backends too. Meanwhile normal use/development can continue on the trunk. The hope is to only be branched for less than a week.
So far all I've done is split swank.lisp and swank-cmucl.lisp into separate packages, so that the interface is more explicit. It currently gets through the test suite.
The code looks pretty much like a pair of Siamese twins separated by a chainsaw -- lots of internal stuff shared all around the place with no logical division, but with the connections laid bare for the eye to see.
The next step is to jumble things around so that the backend implements a small and well-defined interface, and swank.lisp exports as little as possible to support it. AFAICS the best general strategy is moving code from the backend into swank.lisp. Anyone who wants to get muddy is welcome to join in :-)
For the callbacks, I'm currently defining the symbols and placeholder-functions in the SWANK package. Then swank-cmucl.lisp contains a bunch of "(defun swank:foobar ..)" forms to properly define the callbacks. May or may not be a good idea.
Cheers, Luke
Luke Gorrie lgorrie@nortelnetworks.com writes:
The next step is to jumble things around so that the backend implements a small and well-defined interface, and swank.lisp exports as little as possible to support it.
And to use James's code for this! Extremely nice stuff in your web directory which I didn't properly appreciate before diving back into backend hacking :-). I think you've split it up and documented it beautifully.
I recall we grumbled about the number of files initially, but after trying a less-split version me and Dan came around to your view. With just a frontend+backend pair of files I got yucky circular compilation dependencies.
What's the status of the code - is the stuff in http://jamesjb.com/slime/ the latest? Does it work? Let's use it!
-Luke the impressed
On 28 Oct 2003, luke@bluetail.com wrote:
And to use James's code for this! Extremely nice stuff in your web directory which I didn't properly appreciate before diving back into backend hacking :-). I think you've split it up and documented it beautifully.
Thanks. :)
I recall we grumbled about the number of files initially, but after trying a less-split version me and Dan came around to your view. With just a frontend+backend pair of files I got yucky circular compilation dependencies.
What's the status of the code - is the stuff in http://jamesjb.com/slime/ the latest? Does it work? Let's use it!
It's a few weeks old and missing a few loose ends but nothing major. If I commit, say, an empty implementation that throws not-implemented errors for everything and the OpenMCL version, will that be a good start?
James
James Bielman jamesjb@jamesjb.com writes:
It's a few weeks old and missing a few loose ends but nothing major. If I commit, say, an empty implementation that throws not-implemented errors for everything and the OpenMCL version, will that be a good start?
Yes, we can take it from there. I just moved the FAIRLY-STABLE tag for the benefit of people wanting a stable copy during the week.
-Luke
-
James Bielman -
Luke Gorrie