[pro] How to interact with a running lisp instance?

[Daniel Weinreb]

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 at xs4all.nl wrote:
>>>
>>>       
>>>> On 17 dec 2010, at 22:15, Eli Naeher <enaeher at 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 at common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/pro
>   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/pro/attachments/20101220/0b86f1e0/attachment.html>