Scott McKay wrote:
On Dec 19, 2010, at 10:46 AM, Daniel Herring wrote:
On Sun, 19 Dec 2010, Scott McKay wrote:
On Dec 17, 2010, at 4:57 PM, aerique@xs4all.nl wrote:
On 17 dec 2010, at 22:15, Eli Naeher enaeher@gmail.com wrote:
Right now I usually have (under screen) one instance of Emacs for personal projects (for which I try to use the latest Slime and Swank) and one for work (where they do not get updated so frequently), and sometimes I need to start a third instance if I am doing work on an older maintenance branch of the software. It seems like there should be a way to switch between Slime versions within the same running Emacs, but I have yet to figure it out.
Not a direct question to Eli, but why is Slime so version specific anyway?
Ya have to wonder if Slime/Swank should be used Protocol Buffers or Thrift to do their RPC. These both support versioned protocols, and it would be great to have a CL binding to Protocol Buffers.
As I understand it, the wire protocol is generally the stable part of Slime. The RPC aspects (what the server commands do) is what has deep implications and changes frequently.
But what I am saying is, use something that supports versioned wire protocols, and instead of willy-nilly changing the existing API frequently, change it in constrained ways, increment a version number, and use a new version of the wire protocol.
Yes, it's work.
Slime and Swank already check the versions when they start. It's part of the defined wire protocol. Well, actually, it's defined as part of the convention that's always used between Slime and Swank. So if you want to use Swank from a non-Slime client, you ought to put this in yourself.
Swank has a global variable named *swank-wire-protocol-version*. When Slime sends the connection-info command, Swank sends back a bunch of info including this value. Slime checks whether this equals slime-protocol-version, and if not, asks you "Protocol version mismatch. Continue anyway? " with a yes or no answer.
Both Slime and Swank get the protocol version by opening the file ChangeLog file and getting the first token in it, which is something like "2007-12-20".
The important issue is *when* they do it.
In Swank, it is done at the time that the swank-loader.lisp file is loaded. Under normal circumstances, i.e. when you start up a Common Lisp instance that Swank isn't already loaded into, it happens when you start up Slime, beacause that starts up Swank.
In Slime, there is a top-level form:
(setq slime-protocol-version (eval-when-compile (slime-changelog-date)))
I think this means at the time that swank.el is compiled into swank.elc.
The ChangeLog file is supposed to be updated with a new entry at the front every time a change is made to either Slime or Swank. So the code is very conservative about versions. You don't have to ask whether the change you just made would alter the protocol. As Daniel Herring pointed out, even if all the functions and arguments remain the same, their effect might differ from one version to the next in a way that matters to the client.
The downside to being so conservative is that you are forced to keep your Slime and Swank aligned any time you make a change. If you have Swank pre-loaded in your image, the client must use exactly the same version of Slime, or else subvert the checking mechanism (by altering the ChangeLog file) or something.
At least it looks that way to me.
-- Dan
[aside] Protocol buffers are an unnecessarily complicated reinvention of the wheel. If the big G wasn't using them, everyone would be using one of the preexisting formats (e.g. XDR). See MapReduce for a related theme. IMO, a binding to Apache Camel or OpenSplice DDS would be much more interesting.
(Although this is an interesting topic, I suggest that we not get into this on the pro-lisp list.)
- Daniel
pro mailing list pro@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/pro