[slime-devel] :new-features command
Hi all, I'm trying to write a Common Lisp frontend that speaks to a Swank backend. I've just run into a bit of a problem. Let's assume that Swank sends the message (:new-features (:cffi :x86 cffi-features:darwin)). In my code I decode the length of a message then do (with-standard-io-syntax (read-from-string message)) SBCL's reader barfs on the symbol CFFI-FEATURES:DARWIN, because the host side doesn't have have the package CFFI-FEATURES. Which is fair enough. I'm guessing that the Emacs interpreter doesn't bother resolving the symbols, so there is no problem. Later on Slime prefixes ":" in front of the non-keyword symbols, presumably to make them into keyword symbols. Am I understanding this correctly? Is it possible to move the keyword interning to the Swank side? If so, I'll try to write a patch for that. Cheers Brad
* Brad Beveridge [2006-11-06 08:29+0100] writes:
SBCL's reader barfs on the symbol CFFI-FEATURES:DARWIN, because the host side doesn't have have the package CFFI-FEATURES. Which is fair enough. I'm guessing that the Emacs interpreter doesn't bother resolving the symbols, so there is no problem. Later on Slime prefixes ":" in front of the non-keyword symbols, presumably to make them into keyword symbols.
I think, Slime only adds the ":" when it parses features expressions in source buffers, not for the message from the wire.
Am I understanding this correctly?
Yes. By convention, messages on the wire should only contain keywords, nil, and t. But this convention isn't enforced, and the :new-features message obviously violates the convention.
Is it possible to move the keyword interning to the Swank side? If so, I'll try to write a patch for that.
I'm not sure what you mean with "interning" here. Instead of including the symbols in the message we could send a string [e.g. created with (let ((*package* <keyword-package>)) (prin1-to-string <new-features>))]. Are thinking about something else? Helmut.
On Mon, 2006-11-06 at 10:37 +0100, Helmut Eller wrote:
* Brad Beveridge [2006-11-06 08:29+0100] writes:
SBCL's reader barfs on the symbol CFFI-FEATURES:DARWIN, because the host side doesn't have have the package CFFI-FEATURES. Which is fair enough. I'm guessing that the Emacs interpreter doesn't bother resolving the symbols, so there is no problem. Later on Slime prefixes ":" in front of the non-keyword symbols, presumably to make them into keyword symbols.
I think, Slime only adds the ":" when it parses features expressions in source buffers, not for the message from the wire.
Am I understanding this correctly?
Yes. By convention, messages on the wire should only contain keywords, nil, and t. But this convention isn't enforced, and the :new-features message obviously violates the convention.
Is it possible to move the keyword interning to the Swank side? If so, I'll try to write a patch for that.
I'm not sure what you mean with "interning" here.
"Intern" is a classic old-world Lisp verb, from the Maclisp function "INTERN". It's a (setf (gethash ...) ...) for strings/symbols and a package. So INTERNing FOO::BAR means to look up BAR in the FOO package, and if it is not found, create a BAR, and in either case return BAR.
Instead of including the symbols in the message we could send a string [e.g. created with (let ((*package* <keyword-package>)) (prin1-to-string <new-features>))].
Are thinking about something else?
Helmut.
_______________________________________________ slime-devel site list slime-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/slime-devel
On 06/11/06, Helmut Eller <heller@common-lisp.net> wrote:
* Brad Beveridge [2006-11-06 08:29+0100] writes:
SBCL's reader barfs on the symbol CFFI-FEATURES:DARWIN, because the host side doesn't have have the package CFFI-FEATURES. Which is fair enough. I'm guessing that the Emacs interpreter doesn't bother resolving the symbols, so there is no problem. Later on Slime prefixes ":" in front of the non-keyword symbols, presumably to make them into keyword symbols.
I think, Slime only adds the ":" when it parses features expressions in source buffers, not for the message from the wire.
Am I understanding this correctly?
Yes. By convention, messages on the wire should only contain keywords, nil, and t. But this convention isn't enforced, and the :new-features message obviously violates the convention. That makes sense.
Is it possible to move the keyword interning to the Swank side? If so, I'll try to write a patch for that.
I'm not sure what you mean with "interning" here. Instead of including the symbols in the message we could send a string [e.g. created with (let ((*package* <keyword-package>)) (prin1-to-string <new-features>))].
I don't think I knew what I meant when I said "interning" :) I think that for now I will hack on my Swank backend to return :new-features as a string, later on I'll look at how that impacts Slime and submit a patch. Cheers Brad
"Brad Beveridge" <brad.beveridge@gmail.com> writes:
Yes. By convention, messages on the wire should only contain keywords, nil, and t. But this convention isn't enforced, and the :new-features message obviously violates the convention.
Since packages aren't guarenteed to exist on both sides of the wire, perhaps something like this is in order: (defun wire-symbol (symbol) (if (keywordp symbol) symbol (make-wire-symbol :package (package-name (symbol-package symbol)) :name (symbol-name symbol)))) ...where the WIRE-SYMBOL travels over the wire as something like (:SYMBOL "PACKAGE" "NAME") or #S(SWANK:WIRE-SYMBOL ...). The receiving end can then check if the package exists or not, and act approriately, where "appropriate" is probably context-dependent. Cheers, -- Nikodemus Schemer: "Buddha is small, clean, and serious." Lispnik: "Buddha is big, has hairy armpits, and laughs."
Helu * "Brad Beveridge" <de95dc6f0611052329r51b935b3p6ec637e118e9f3be@mail...> | I'm trying to write a Common Lisp frontend that speaks to a Swank | backend. I did this a while ago, for CMUCL with simple-streams for network IO. I'm attaching the file (slapping an LLGPL, with the hope it may be useful). Since Slime seems to be gaining in size perhaps a compliant CL client can be included with the sources? -- Regards Madhu
On 06/11/06, Madhu <enometh@meer.net> wrote:
Helu
* "Brad Beveridge" <de95dc6f0611052329r51b935b3p6ec637e118e9f3be@mail...> | I'm trying to write a Common Lisp frontend that speaks to a Swank | backend.
I did this a while ago, for CMUCL with simple-streams for network IO. I'm attaching the file (slapping an LLGPL, with the hope it may be useful). Since Slime seems to be gaining in size perhaps a compliant CL client can be included with the sources?
-- Regards Madhu
Thanks a lot Madhu. To be honest I think that I am further along with my stuff, though it is nice to have some more code to look at :) I think it would be nice to have a properly maintained CL Swank frontend as part of Slime, but it needs to be pretty polished IMHO. If anybody is interested in my code I can post it here for review/critique. It will be released under whatever license Swank runs under. Cheers Brad
participants (5)
-
Brad Beveridge -
Dan Weinreb -
Helmut Eller -
Madhu -
Nikodemus Siivola