whoa

Similarities with unrepl are reassuring design-wise

I'm surprised this is a thing, given that unrepl exists 🙂

don't know where Rich is going with this but if nothing else "prepl" is fun to say 😉

I think he really wants something like this to be part of Clojure itself. Originally we wanted nREPL as part of Clojure and that’s why Chas agreed to move the project under clojure-contrib, but we all know how things played out and how bad this was for nREPL in the end of the day. I guess he finally realized that the design of the socket REPL is not exactly very convenient for tooling, but he might be pursuing some other goal as well.

>>> Tasseography is a divination or fortune-telling method that interprets patterns in tea leaves, coffee grounds, commit logs, or wine sediments.

remote-prepl puzzles me: why not reuse the existing server code? it’s just a different accept.

Why not allow tap> to have a tag argument? Forcing the user to structure the tap data in a way amenable to triage/routing/filtering? It hinders upgradability too.

:read only on :ret means that the: • the client doesn’t know when the server has started working • you don’t get :read info for exceptions

Hmmm, why is there no differentiation between a thrown exception value and a returned exception value?

in prepl

what do you mean? looking at the code if the return value is an exception you get a :ret msg not a :err msg, no?

no

you get a :ret

err is only for the :err print stream

https://github.com/clojure/clojure/blob/86a158d0e0718f5c93f9f2bb71e26bc794e7d58e/src/clj/clojure/core/server.clj#L242

oh you are right, I misinterpreted :err

so I agree with you: one can’t tell an exception being thrown from an exception being returned

also: why bother converting :ns to string and exceptions to tagged-literals here? shouldn’t it be done in out-fn?

he's serializing things as that's the intended use

and it gives a canonical return value in all situations

I'm still grocking the why of tap> it's so that tooling can send messages back to the client??

Yeah but there’s also valf that’s going to transform the value

so out-fn does more than dumb serializing

yeah but the base value is always ready to transmit

everybody gets all the messages!, I'm going to run my chat server and my repl through tap!

an interesting thing is that clojurescript needs two different types of tap> for tooling

one that runs in clojurescript land and one that runs in clojure land

hmmm so we make a macro called meta-tap>

or not, I have to put some thought into how you would bootstrap the cljs-repl using these new tools

I have to say I am a bit disappointed, and there no way to see it differently. Unrepl is there, for everybody to contribute to, I wish we did not have so many different clones of the same thing...we'll see how it pans out.

@richiardiandrea well it validates the core design of unrepl

and plain repls are still upgradable

and life may get easier because of changes made for prepl (but won’t ship until 1.10)

Lol I keep rewriting this sentence over and over...I am just thinking that I would have taken some additional step to make this part (tooling) a bit more open to contributions...

But yeah, we know how Clojure works 😃

Currently I’m seeing unrepl as a toolkit for creating custom (private) protocols for tools. It provides a foundation, some design decisions have been made etc. But unrepl is not “consumer tech”: got a tool? got a plain repl? it works!

https://github.com/bhauman/rebel-readline

I'd really love your feedback