Clojurians Log v2

I’ve been following the unrepl stuff for a short while, and I find it kinda annoying that many repl’s are tied to their development environments; e.g. proto-repl-charts, gorilla-repl etc… The stuff Stuart Halloway said in his recent talk about sidecars really resonates. Anyway it got me thinking that what would be super useful is having a broadcast repl, that could broadcast interactions/responses over some mechanism (perhaps pub/sub) so that sidecar repl clients could render results for you. The idea would be that I could for example keep my editors REPL, but have a a sidecar client connected to the same unrepl server, listen for evaluation results and render them… e.g. it could render a stream of proto-repl charts, if they conformed to the right type, or it could render a tree view for exploring datastructures; without having to work directly with my editor and its REPL (Emacs). Has anyone else thought about this at all? Would unrepl support it?

To me the “integration hub” is the client not the server. One reason is that it doesn’t assume that all repls servers are not local and easily connectable.

ok, so you’d have a broadcast client that would broadcast its interactions to clients that are connected in turn to it?

Last week I’ve been thinking about zeroconf and how it could be used

That seems very useful for this problem.

hmmm maybe… its been a while since I looked into bonjour; when I last looked a lot of it was pretty immature; apart from the mDNS side

something to think about some more…

i had an old spike of a bonjour like REPL data sharing thing

anyway user side it’d be nice to have something like an electron client app that would only render datastructures… it’d let you drill down into deeply nested hashmaps etc… but not really receive any code to process.

but Emacs and its REPL wouldn’t need to care

@rickmoynihan there has been some conversation on that here and interestingly enough two sides of the coin arised. @thheller's shadow-cljs preaches multiple connections for tooling (if I need to auto complete, I do it on a separate connection). The other side will be multiplexing on the same connection (keep a mapping session <-> connection IIRC but Christophe can correct me here).

Unrepl does not have multiplexing atm and about shadow-cljs, I was playing with an emacs client that opens connections ad-hoc

yeah I’ve read those discussions… multiplexing gets pretty messy in my experience; so I’m more sympathetic to having multiple connections - though not sure what cons that approach might have

in my mind multiplexing protocols on a single socket is always prone to the latency issue where there’s data ahead of you in the network buffer.

probably makes state management more messy...I guess?

IIRC many, many moons ago, Rich was arguing that nREPL should be designed using STOMP, which would’ve in theory enabled a lot of stuff like this… At the time I was implementing a message broker using STOMP, and recall that actually the protocol was horrendously underspecified… It was only superficially simple because it was vague… I remember researching the MQTT protocol at the time, which by comparison was awesome, and well specified.

@cgrand https://github.com/ghadishayban/undersea

@ghadi: cool.

i wanted to share data with co-worker's REPLs.

gosh the code is gross

https://github.com/jonpither/cider-spy possibly related (aimed at emacs ofc)

yeah I’d seen cider-spy before; pretty cool… but sharing REPL’s with coworkers isn’t something I want to do 🙂

At some point I had an electron-based repl that allowed browsing but the rendering was crude. There's a gif floating around

Not in my experience. The main drawback is that it does not work when creating when new connections are expensive or impossible.

Other minor drawback: the server can't initiate a new connection.

The first drawback is vastly mitigated by the fact that a repl can be upgraded into a multiplexed server.

cool

@cgrand is this new?

also you sure type fast

Not new unearthing it for @rickmoynihan

I was thinking of trying out Unrepl-over-http - exposing Unrepl's EDN as an HTTP POST endpoint

That could be read from, say, a Reagent clojurescript app, which takes care of the presentation and requests sequence expansions as necessary

@pesterhazy SSE is perhaps the most appropriate, no? Unrepl is more of a stream?

(This would actually make auth really easy)

nice! 🙂 I think the only difference between that and what I’m saying is that I’d leave the evaluation/entry of code out of that REPL, and have it only display values and expand them

@dominicm, right, Unrepl is a stream, but to implement a interactive, expanding tree I think you want request/response semantics

although I could be wrong

well websockets can still be used as request/response, and it has probably easier implementation...maybe

also re-frame can integrate pretty well with this by being event/message based

oh having the choice is the best of both worlds then

@pesterhazy I thought you were thinking of exposing all of unrepl

@dominicm, I was more thinking of a sidecar window (in a browser) that can be used to visualize data structures

@pesterhazy makes more sense. :) unless it's large :thinking_face: might be better to be able to run the code

Switching application to be able to expand seems cumbersome for something so common. Ymmv