Hi,

On 22 Mrz., 06:44, Martin Blais <bl...@furius.ca> wrote:

> > 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 think, I understand now. I got a misunderstanding, because SLIME
puts transport and backend in one thing, IIUC. The IDE backend breaks.
Not the transport layer.

> IMO something really, really simple will almost never break,
> even between versions; because if you keep it really simple it
> never changes.

Why should the transport protocol change - and hence break - between
versions? What you do on top is the problem. And that is dictated by
necessity. I managed to get a working backend for 1.2 and 1.3 (so
far). But I had to deprecate usage with 1.1. At the moment this is not
very painful (who uses still 1.1?), but for the future I will probably
have to fork for different clojure versions.

> 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.

This has been solved before but seems to be abandoned. Simply put a
repl on a network socket.

> 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.

I'm suspicious that we talk about different "request id"s here. When I
close the connection, will SLIME keep repl state like the value of
*warn-on-reflection* and the like?

> Is there an effort somewhere for a common tooling library?

There is some at the given confluence link. It is supported by most of
the major toolsmiths: Laurent, Eric and myself. And of course all
future IDEs supporters should be. (eg. bluefish is a possible
example).

Unfortunately I haven't had the chance to dive in, yet. Real life
wants its share.

> It's a wheel that has been riding for a while. I've learned
> not to ignore "working code", especially "old working code";

My intention with the above is to use already existing code where
possible. But make independent from any transport or other system. We
can't know now, which environment an IDE developer does face. So it's
better not to couple things now needlessly.

> 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).

Feel free to gather your results in the posted tooling link. The page
currently contains only my experiences from VimClojure and some
distant observations from other systems + some corrections and
additions by Laurent.

Sincerely
Meikel

-- 
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

Reply via email to