Clojurians Log v2

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

I'm guessing (not supporting) that its to allow for varied of the pub sub

maybe there is a use case that needs to dispatch on a raw value and not a keyword

I can't really conceive of it but ...

Worst case, give the possibility to subscribe to all topics?

that would be absolutely necessary, but its an unnecessary feature as its trivial to create dispatch

ok now I'm getting it, I dig it

The problem that I see is that if some code start to use tap> as log is that creating dispatch won’t be easy as you’ll have a lot of variance in the payloads

really? please enlighten me

sorry I mean I'm getting the tap design and how its useful, I've got no attachment to the dispatch decision

but the messages you send to yourself will be correct

and these messages only have handling that is guaranteed by the client

so its a crappy log fn

we reached an agreement!

I appreciate the back and forth on this it's super helpful

I really see tap> use as (tap> {:id 25 :type :tool/completion :complete (tool/complete "asso"))

or something like that

i think you were already there, it took me a minute

and you'd need a session id as well

sorry thinking out loud

don’t! It’s super useful to me too

and finally I get your point, session level dispatch would be nice at least

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

and ultimately I think this is why there is no dispatch, b/c depending on your use you are going to need another level of dispatch granularity

one repl dispatch on a message type

repls in parallel dispatch on a session

and I guess you could have shared sessions etc

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!

huh?

Yep that is definitely nicer

Don't worry I will switch off my rant mode 😄

rant-a-car?

Fixed 😉 tnx

no, really I’m not sure I get what you are saying; complaining about the “throw features over the wal” approach?

I mean, we have a project here with a relatively good support from the community...I am just afraid it will get shadowed. Instead it could have been additive, I hope it will be additive as you were saying and the two will thrive along together.

I hope

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

I'd really love your feedback