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 an
Hi,
On 22 Mrz., 06:44, Martin Blais 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 mis
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 f
On Mar 21, 2011, at 5:57 PM, Kevin Downey wrote:
> On Mon, Mar 21, 2011 at 2:15 PM, James Reeves wrote:
>> On 21 March 2011 13:14, Chas Emerick wrote:
>>> I think we're in violent agreement. Here's a sample nREPL exchange from
>>> https://github.com/clojure/tools.nrepl:
>>
>> Ah, I did look
On Mon, Mar 21, 2011 at 2:15 PM, James Reeves wrote:
> On 21 March 2011 13:14, Chas Emerick wrote:
>> I think we're in violent agreement. Here's a sample nREPL exchange from
>> https://github.com/clojure/tools.nrepl:
>
> Ah, I did look through that REPL exchange, but I misunderstood the
> synta
On 21 March 2011 13:14, Chas Emerick wrote:
> I think we're in violent agreement. Here's a sample nREPL exchange from
> https://github.com/clojure/tools.nrepl:
Ah, I did look through that REPL exchange, but I misunderstood the
syntax the first time I read it. I now realise that the integer at t
On 21 March 2011 13:10, Meikel Brandmeyer wrote:
> Then we need a clear definition of the clojure syntax. Otherwise you
> cannot build clients without read-string.
True. I guess bencoded data structures, or JSON inside a netstring
would perhaps be more cross-platform solutions.
- James
--
You
I didn't mean to imply that I wanted to replace the number with tags,
what I meant to imply is that the number of lines is not any better
than START and BEGIN tags, while a fixed width count of bytes (even a
number string padded to a constant number of bytes with zeroes) is
better.
On Mon, Mar 21,
On Mar 21, 2011, at 8:52 AM, James Reeves wrote:
> On 21 March 2011 11:29, Chas Emerick wrote:
>> The notion of "passing around Clojure data structures" does get watered down
>> because of the non-sexpr-nature of e.g. *out* and *err*, and it's all
>> message-oriented so as to support asynchron
Hi,
On 21 Mrz., 13:52, James Reeves wrote:
> Then use the Clojure read-string and pr-str functions to encode data.
Then we need a clear definition of the clojure syntax. Otherwise you
cannot build clients without read-string. By hard-coding this I'm not
free to encode things as I want. Eg. with
On 21 March 2011 11:29, Chas Emerick wrote:
> The notion of "passing around Clojure data structures" does get watered down
> because of the non-sexpr-nature of e.g. *out* and *err*, and it's all
> message-oriented so as to support asynchronous evaluation from the same
> client, but that's prett
On Mar 19, 5:30 pm, Martin Blais wrote:
> Hi,
>
> After Rich's suggestion at the recent NYC meetup,
For those of us who weren't there, what exactly did Rich suggest at
the NYC meetup?
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this
On Mar 20, 2011, at 9:13 PM, James Reeves wrote:
> On 21 March 2011 00:18, Chas Emerick wrote:
>> In any case, my objective with nREPL was to get something working well that
>> had what I thought were the right semantics for the use cases I was
>> concerned with (i.e. point-to-point Clojure to
On Mar 20, 2011, at 10:48 PM, blais wrote:
> On Mar 20, 12:16 pm, Chas Emerick wrote:
>> Martin,
>>
>> Thank you for the pushback. :-)
>
> I'm not pushing back, I'm really just trying to understand...
In any case, I appreciate public thrashing of design and implementation choices
(as long a
2011/3/21 blais
> On Mar 20, 12:16 pm, Chas Emerick wrote:
> > Martin,
> >
> > Thank you for the pushback. :-)
>
> I'm not pushing back, I'm really just trying to understand...
>
>
> > On Mar 19, 2011, at 8:30 PM, Martin Blais wrote:
> > > I think this is wrong, because every single IDE client
take it from someone who has been digging through the swank clojure
source for the last few days, the protocol is not synchronuous.
swank-clojure is completely built around async message passing (to the
point where it can be difficult to trace an evaluation request and a
response), and it is a mirr
Hi,
just to drop some comments from someone who has rather heavy
requirements due to the environment he has to live with. But to re-
state what I said before: I'm a pretty extreme case and don't want to
be an obstacle for nREPL or any similar project. Nevertheless you can
learn a lot from VimCloju
On Mar 20, 10:48 pm, blais wrote:
> really valuable, because it is unlikely to break between versions, and
> it's already good enough for a lot of users via stdin/stdout pipes
> (i.e., inferior lisp).
Like being able to just telnet to a running VM and type "(+ 2 2)" and
see "4" printed on stdout.
On Mar 20, 12:16 pm, Chas Emerick wrote:
> Martin,
>
> Thank you for the pushback. :-)
I'm not pushing back, I'm really just trying to understand...
> On Mar 19, 2011, at 8:30 PM, Martin Blais wrote:
> > I think this is wrong, because every single IDE client
> > will have to adapt itself to
On 21 March 2011 00:18, Chas Emerick wrote:
> In any case, my objective with nREPL was to get something working well that
> had what I thought were the right semantics for the use cases I was concerned
> with (i.e. point-to-point Clojure tooling backends). Lifting those semantics
> onto other
The number indicates the number of entries in the following message; and yes,
you're right that a sentinel would have been sufficient to terminate each
message, though I wasn't attempting to follow in other protocols' footsteps.
I'm sure the protocol is lacking in a variety of ways; as I said,
On Mar 20, 2011, at 12:47 PM, Kevin Downey wrote:
> I am no python programmer, but if you look at
> http://docs.python.org/library/socket.html you see it passes in the
> number of bytes you wish to receive on a call to the receiv method on
> a socket. With that in mind parsing nrepl messages becom
My objection has nothing to do with string vs. byte.
Messages used in wire protocols exist on a continuum between fixed
width and variable width. The happy medium there, which almost all
protocols follow is a fixed width header that also provides the bye
count of the following variable width body.
Yes, as a heavy Emacs/SLIME user who does not work with Common Lisp any
more, I'd rather have a Clojure-specific Emacs environment, especially
something that can do more introspection of the JVM, e.g., look up JavaDocs
and examine classes through reflection.
In my not-terribly-well-informed opi
I am no python programmer, but if you look at
http://docs.python.org/library/socket.html you see it passes in the
number of bytes you wish to receive on a call to the receiv method on
a socket. With that in mind parsing nrepl messages becomes a huge
pain. At no time when parsing a nrepl message do
On Mar 20, 2011, at 3:13 AM, Kevin Downey wrote:
> nrepl's protocol is also very line reader centric, which is a drag,
> and the "integer" that prefixes messages is really just a variable
> length string and is not useful for allocating buffers to receive data
> in a client because it is a lines
Martin,
Thank you for the pushback. :-)
On Mar 19, 2011, at 8:30 PM, Martin Blais wrote:
> Hi,
>
> After Rich's suggestion at the recent NYC meetup, I had a
> detailed look at inferior-lisp vs. Slime, and nREPL, read
> Chas' document, wrote a bit of code, tried to figure out the
> issues for m
nrepl's protocol is also very line reader centric, which is a drag,
and the "integer" that prefixes messages is really just a variable
length string and is not useful for allocating buffers to receive data
in a client because it is a lines / 2 instead of a byte count. this
makes writing a client th
On Mar 19, 7:30 pm, Martin Blais wrote:
> (*) Please note: I am aware that only Emacs supports the
> Swank protocol right now but I don't see why other IDEs
> couldn't support it too--it's just made up of LISP forms
> after all; in other words, if someone wants to replace
> the
On Sat, Mar 19, 2011 at 7:36 PM, Sean Corfield wrote:
> I guess I would need to be persuaded that either a) Slime/Swank is so
> unassailably good that all IDEs should implement it or b) there are
> inherent problems with nREPL and no IDEs should use it?
As a follow on, the "Why another REPL imple
On Sat, Mar 19, 2011 at 5:30 PM, Martin Blais wrote:
> I'm curious to hear people's thoughts. I don't have a ton of
> experience with Clojure and I also might be misled regarding
> the aims of the nREPL project. What's bothering people with
> Swank's protocol anyway?
I have zero experience with E
Hi,
After Rich's suggestion at the recent NYC meetup, I had a
detailed look at inferior-lisp vs. Slime, and nREPL, read
Chas' document, wrote a bit of code, tried to figure out the
issues for myself; here are my conclusions on nREPL:
- In the Slime/Swank model, there is a single IDE that
conne
32 matches
Mail list logo
