On Mar 22, 2011, at 1:44 AM, Martin Blais wrote: >> 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.
Each of the development environments could easily load their own local versions of the tooling libraries, even in VMs that they didn't start. Even today, when I connect to a running Clojure VM with ccw, the first thing it does is load up its tooling-support libraries. As long it eventually takes care to load those libraries into a version-specific namespace, tooling shouldn't break in such an approach. We'll deal with the namespace unloading / class GC when we need to down the road. > Is there an effort somewhere for a common tooling library? Nothing concrete yet. All it requires is someone who is ready to take on the inevitable cat-herding. The vast majority of the actual code is already written, and is sitting in the repositories for ccw/swank-clojure/enclojure/vimclojure/etc. >> 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. I fundamentally agree, but if a middle path can be found that will make writing clients and adapters as simple as possible in all known contexts, I'm willing to put the work in for that – especially now, when nREPL is very young and hasn't been widely adopted yet. A common, easily-targetable transport is the first step in enabling positive network effects; the sooner we can do away with the balkanization that exists among Clojure tooling, the sooner all our lives will get a lot better. > 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. IMO, one thing at a time. :-) The VM has a number of purpose-built protocols/services (JDI, JMX, JVMPI, probably others), many of which we may want to orchestrate/interact with within a REPL, or using tools that use the REPL connection as a rich datasource. I wouldn't want to run into that stuff until we've learned to crawl. And, as you say, things like JDI require a "host" and target VM, but many environments already have a host (IDEs like Eclipse, etc., which would likely still want to use as much of CDT as possible). Someone will need to puzzle out the truly common bits and ensure that they're suitable for everyone, while allowing environments like vimclojure and emacs to opt into the parts that manage the "host" VM. - Chas -- 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
