[Slime-devel] SLY, a fork of SLY

[João Távora]

Helmut Eller <eller.helmut at gmail.com> writes:

> On Sun, Sep 07 2014, João Távora wrote:
>
> [...]
>>> Doesn't sound so hard and it would not need any conflicting package
>>> nicknames.
>>
>> Well, I would still need to rename the rex requests themselves as in
>>
>>    (sly-eval `(swank:list-all-package-names t)))
>>
>> So as to comply with your "part of symbols names" demand and,
>
> With "part of symbols names" I mean those symbols in ELisp that use
> "slime" or "sldb" as prefix when one would use packages in Common Lisp
> to make them unique.  Apparently you have already renamed most (all?) of
> those.

I'm still missing the "sldb-" symbols but I have already tried and this
presents no big problem. But again, not super-clean either, because
there are symbols in the CL namespace that contain "SLDB", and some are
user-customizable. I either leave those be or have to implement
abstractions.

>> importantly, to keep `sly-edit-definition' capabilities.
>>
>> This last bit is, incidently, one of the drawbacks of your previous
>> solution compared to nicknaming packages, since for anyone looking at
>> the wire (e.g. *events* buffer) strings would SIMPLE-READ to completely
>> disparate symbols. Now, imagine there is indeed a SWANK server running
>> int the Lisp image and the confusion this could cause. Would this be
>> easier to debug than an early abortive "Can't create package because
>> there is a conflict" error?
>
> People who are debugging some wire format issues probably wouldn't load
> Swank and slynk (or whatever name you choose) at the same time.  At
> least I wouldn't load any unnecessary components when debugging.

I don't know about that: when an unexpected error happens, the first
thing I do is not teardown my environment and start without unnecessary
compoenents, because I don't know who those are in the first place.

My view is that people who for some (slightly questionable) reason, do
want to have both Swank and the proposed Slynk in the Lisp, can very
well add an extra line to their configuration and see

   (:emacs-rex (slynk:connection-info) nil t 1)

in the events buffer.

>> After having done that, I would need the reverse indirection in
>> `sly-net-send`, and would have to walk the sexp there, since some
>> extensions "abuse" it and send nested sexps.
>
> That problem is the same for SWANKR or similar servers.  The right place
> to fix such issues is the extension.

Not really, and the problem is not only sexp nesting. sly.el calls
interfaces where a second "slimefun" is mentioned like in
slime-repl.el's own

    (slime-eval-async `(swank:listener-save-value ',slimefun , at args) ...)

Which is something that I added precisely for compatibility with SWANKR
(See the discussion with Christopher Rhodes in
https://github.com/slime/slime/issues/140).

Perhaps you consider it abuse -- I don't, hence the quotes earlier --
but it's also very convenient. It allow the proposed Slynk
to serve inspection requests for both SLIME and SLY clients. For
example, SLY implements multiple inspectors streams with a call like

    (sly-eval-async `(swank:eval-for-inspector
                      ,inspector-name
                      ',slimefun
                       ,args))

, which applies SLIMEFUN to ARGS in INSPECTOR-NAME's context. But the
SLIME client, who doesn't support multiple inspectors, will still see
its SLIMEFUN request honoured as always. And so Slynk remains backward
compatible to SLIME clients.

But anyway, changing `sly-net-send' to walk the sexp just before sending
doens't seem hard to do, and though I haven't measured, doesn't sound
computationally expensive in the RPC context.

João