Aaaah now we're getting to the core of this discussion...
To summarize everyone's points:
- Several people consider the "transport" to be
orthogonal/separte to the "tooling" or "IDE backend."
a) By transport, it refers to a generic ability to transfer
key-value pairs, with a 'id' key for associating responses
to requests (asynchronous responses).
b) "Tooling," or "IDE backend," is a reference to the library
of functions implemented on top of this. I called this
"rich protocol" in my original email.
* These two layers are one in swank/emacs-rex; some people see
benefits in keeping those separate;
* nREPL aims only at the first goal;
* It's not clear whether people are interested in a common
"tooling" library at this point.
- The document that contains some of the juice I'd been looking
for is
http://dev.clojure.org/display/design/IDE+tooling+backend
(Thanks Meikel.)
* (Chas) A suggestion: adding a link to this document from the
nREPL README, or to the "original design notes" would be
useful. (I only found this later.)
- Swank is unsuitable, because...
* Its development and release cycle isn't well organized and
stable ("use the CVS HEAD")
* It is not managed and developed separately from its client
(Slime)
* It is undocumented (and it won't be)--you need to reverse
engineer it from the source code, which is more painful than
it needs to be
* It is more complicated to parse for non-lisp readers
* Evolving it--if even possible-- would cause too much
friction while breaking existing code for CL users
* Despite this, at least one project did use that approach:
CUSP // www.bitfauna.com/projects/cusp
- Clojure requires support beyond that offered for Common LISP
because...
* Looking up JavaDocs or integrating Java-specific
introspection would be useful
(nothing else so far...)
(Meikel Brandmeyer)
> Why does a synchronuous version break less than an async one? And
> besides: it's good enough for a lot of users, but it is not good
> enough for me.
Why does Slime with Clojure-1.3 not work right now?
(I don't know either: I'd have to dig in--and that's my point.
No time to dig in... though you could argue rightfully I should
try to fix the bug instead of spending this time writing an
email.)
IMO something really, really simple will almost never break,
even between versions; because if you keep it really simple it
never changes.
Being able to telnet to a VM on a remote server--no editor, just
telnet--is useful in real-world cases where you can't install
stuff on boxes; being able to shell in via telnet and eval a few
things is _really_ powerful. Again, that's not to say that that
could replace an asynchronous protocol, but it's a really nice
fallback.
Actually, I don't see why both could not be provided
simultaneously (separate ports).
> As for the connection: Vim requires async connections and doesn't come
> with a parser generator. So the SLIME/swank protocol is unsuitable in
> two ways: it requires a synchronuous connection and is to complicated
> to parse.
Swank is asynchronous, e.g.::
(:emacs-rex
(swank:create-repl nil)
"clojure.tools.nrepl-test" t 4)
(:return
(:ok
("user" "user"))
4)
AFAIK that final "4" in both the request and response is a
request id.
(Chas Emerick)
> In any case, I appreciate public thrashing of design and
> implementation choices (as long as the process is productive).
I apologize if it sounded like thrashing, I didn't mean it that way.
(Also, apologies if my email tone was a bit square BTW, I had
written a much longer and more nuanced one right before it and
it got lost in Gmail or my web browser textarea and I think in
my rewriting I was still a bit miffed at losing a lot of time on
the first one.)
> A few people have been discussing the desired capabilities,
> and have started documenting desired semantics, and where each
> capability has already been implemented.
Is there anything something beyond this page?
http://dev.clojure.org/display/design/IDE+tooling+backend
> The operations that would be provided by a tooling library would
> have zero impact on the nREPL protocol. There's no reason why a
> particular client would have to either (a) use the server's
> provided set of tooling functions or (b) use any particular
> standard set of tooling functions. It's just code that's being
> loaded somewhere, and then called later on -- no protocol changes.
Well, no low-level "protocol" changes that's true, but on top of
it, something higher-level will be built for invoking that
"tooling" library, if anything, just function calls on it, and
though the nREPL transport won't break, access to the tooling
library will likely break on version mismatch.
But I understand that's not the goal of nREPL anyway, so it's beside
the point.
Is there an effort somewhere for a common tooling library?
> apply. After going through the above, I think it's worth asking:
> what about swank is so great that it should wag the dog here?
It's a wheel that has been riding for a while. I've learned
not to ignore "working code", especially "old working code";
it's often too easy to dismiss something and restart from
scratch without looking at it in enough detail (I'm not
saying that this is the case here, but I'd have loved to see
an exhaustive list of swank functions--I think I'll produce
one; if anything that could be useful in helping define a
complete "tooling" library).
> However, there appears to be complete unanimity that this is a
> less-than-optimal approach that will make life harder for some
> potential client implementers in some contexts. So, I'm willing
> to change the wire protocol. I'll read more about netstrings,
> bencode, and other schemes. In the meantime, those who care
> should pipe up now as to their preferences and/or points of
> advice. The only significant preferences I have at the moment
> are that:
Your nREPL protocol is unusual indeed, I haven't seen one like
that before (but I don't think it's bad).
Netstrings are very common in binary protocols. I think for this
application we don't care about performance, so a text protocol
makes more sense to me.
Also, your keys probably don't need to be fully general
(e.g., be able to contain \n), you could simplify there.
I don't know; to me, the transport for this application is
uninteresting. You write a parser, and then it's what
happens on top I really care about.
(George Jahad)
> For those of us who weren't there, what exactly did Rich suggest at
> the NYC meetup?
I did a presentation on Slime and Emacs; (slides here:
http://furius.ca/tmp/emaclj/emacs-and-clojure.martin-blais.pdf)
we discussed why he and a few others were using inferior-lisp
instead of Slime (it didn't make sense to me since I like the
fancer Slime features, but I can see why now). I said I'd be
curious to implement support for the newer effort, Rich
recommended I have a look at nREPL, that that was the right
approach, and I had already discussed it with Chas in a previous
meetup, but I hadn't had time to look at the code yet. That's
all.
I'm interested in doing some Emacs work on making it work
with the new new thing, but I'm not sure I want to rewrite
Slime, thus the long long thread to try to convince myself
if it's worth it or not to start from scratch. (I find
writing Emacs-Lisp fun, but sometimes really thorny and
time-consuming--I cannot say I'm really good at it.)
One more idea:
IMHO a client library should consider integrating the work
of George on debugging with JDI. Because of the nature of
JDI, it is certain to dictate a client written in Java. For
Emacs users, this means some external/child process used to
indirectly connect to one or more target VMs will be
necessary.
I wonder if there would be any reasons to generalize this,
e.g. a client/IDE always connects to a long-running "JDI/IDE
server" instead of the target; say, that server never stops
on your machine, even if you restart your target VM(s). It
always connects to the target VMs.
Thanks for all the ideas,
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
