Ah. Issue #36.

It keeps coming back to read tracking. 😿

Don’t. Make. Cats. Cry.

and I really want to remove unrepl/do

Yes. I see the problem now.

Tell

It’s good to hear people restating stuff, you get to see things under a different angle

I always forget about reading from stdin....

Like (read). Was happy to have it. Forgot about immediately. :face_palm:

Can we have a byte offset?

Scratch that.

char offset not byte

Typing faster than thinking.

with covering :readmessages it should be more frequent for the client to determine if nothing is “in flight”

Can I retrieve the exception from a repl? Without mocking with *1?

heh?

At the moment I have to reimplement c.stacktrace. Because it expects a throwable. Also the stacktrace gets elided.

Stop. Rewind. I need more context, I’m not following along at all

Do you want the exception thrown by code evaluated in unrepl or something else?

I get an exception via unrepl. I want to pretty print it for human consumption. But I only get an #error with elided parts which doesn't read back in in the tooling connection.

So I need to translate things and have a modified pretty printer to understand the translated thing.

It should read back. Can you reproduce it with just netcat?

I tried to read a (prn (Exception. ...)) in a plain repl. And it doesn't. Also the elision fails reading.

Otherwise I do think that swapping some parts of unrepl to do most of the pretty printing server-side when the client-side is feeble is a good idea

currently make-blob allows only actions to be customized

but more hardcord customizations are possible

So you mean just to pretty print the EDN code?

What’s the point of having machine-readable printings that your machine can’t print?

?

If you can’t do stuff on the client side, modify the blob to have the server do most of it.

Hi, is there some overview comparison between unrepl and nREPL? I haven't been able to figure it out from reading the readme and glancing over unrepl spec.

I like that unrepl wraps socket repl which makes it easy to plug in into CLJS environments. But if someone created a nREPL wrapper over socket repl would unrepl still have some other benefits?

The goal of unrepl is to be transparent to the user: no configuration, no middleware. All you need is a repl (not even a socket one, I routinely test over stdin).

unrepl is meant to be an implementation detail for tools.

> But if someone created a nREPL wrapper over socket repl would unrepl still have some other benefits?

@kloud Why would do something like this? You’ll still need middleware, so you’d gain very little. What would be more impactful would be to just update the implementation to target Clojure 1.7 and support ClojureScript natively (something that was obviously not possible when nREPL was created).

regular expression of the message stream :unrepl/hello (:prompt :read (:started-eval (:eval | :exception))?)*

previsouly was :unrepl/hello (:prompt (:read :started-eval (:eval | :exception))*)*

I get this: unrepl.repl$pkrTyzbcFcA3scs1I83X8tI0iM0.proxy$clojure.lang.LineNumberingPushbackReader$ILookup$ILocatedReader$ff3fd87c cannot be cast to clojure.lang.IFn

With the latest commit.

grmf

when doing what?

in set_file_line_col

is that a bitcoin hash?

set source

found

@ghadi no it’s dependency sha1ding

It's used from vv-vZOFetlbOcKtaQ-vCp699gbSDFw.vimpire.nails

Notice the fangs.

I like the metaphors.

@cgrand Is it possible, that I don't get eval and friends for :set-source?

that’s unrepl/do dark arts

Baron Samedi comes to haunt the voodoo priests who opened a tomb without his permission.

Let's hope your machine doesn't crash and take it into oblivion before you can push. 🙂

also: since there are more prompts now, prompts will announce the next eval-id

What will trigger now a prompt?

you get a prompt after ignored characters (possibly 0 soon, when interrupted from aux) or after evaluation

vimpire does now read tracking. That means commands are framed based on their submission. This is mostly interesting for the tooling repl.

For the repl buffer that means the prompt is only shown once at the end after all submitted commands are executed.

It also means that something like: user=> (read) (+ 1 2) will break the connection.

Is that a progress?

@kotarak can you outline your algorithm?

The connection starts out in state prompt. Then input is sent. This happens in a queued context. Agent-like. A context may contain several forms. In particular the context also contains the length of input and callbacks for the events. This is important because vim channels are asynchronous. The conn is put into state evaling. The read event is used to reduce the remaining length. Eval checks whether there is input remaining. If so, the conn is kept in evaling state. The prompt handler sees the evaling state and does nothing. The next form is read. In particular are the proper callbacks still in place. Then we come back to eval eventually. Now assume, the input for the context is exhausted. Then the context is popped from the queue. And the connection is put into awaiting-prompt state. On the next prompt the handler recognises this. It switches the connection back to prompt state and triggers the execution of the next context in the queue (if any). And then things start over.

One special case: if the prompt handler sees the combination of evaling and exhausted input it assumes unrepl/do or whitespace only input and pops the context from the queue itself. The only way the prompt handler can see exhausted input is by skipping the eval handler.

The repl buffer is built on this. With some special handlers for output and exceptions. However, eg. a (read) does not generate read events. So "user=> (read) :foo" will break the connection state because the :foo will be consumed without the conn knowing about it. So it will wait forever for the "remaining" five chars to be read.