Fork me on GitHub
#unrepl
<
2017-08-08
>
rickmoynihan15:08:00

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?

cgrand16:08:41

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.

rickmoynihan16:08:07

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

cgrand16:08:35

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

dominicm16:08:14

That seems very useful for this problem.

rickmoynihan16:08:53

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

rickmoynihan16:08:13

something to think about some more…

ghadi16:08:34

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

rickmoynihan16:08:34

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.

cgrand16:08:44

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

rickmoynihan16:08:29

but Emacs and its REPL wouldn’t need to care

richiardiandrea16:08:49

@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).

cgrand16:08:46

Unrepl assumes multiple connnections. But these connections may be provided over a multiplexed pair of streams.

richiardiandrea17:08:40

oh having the choice is the best of both worlds then

richiardiandrea16:08:22

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

rickmoynihan16:08:16

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

rickmoynihan16:08:32

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.

richiardiandrea16:08:28

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

cgrand16:08:34

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

cgrand16:08:57

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

cgrand16:08:39

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

rickmoynihan16:08:35

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.

ghadi16:08:41

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

ghadi16:08:45

gosh the code is gross

dominicm16:08:08

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

rickmoynihan16:08:23

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

pesterhazy17:08:44

also you sure type fast

cgrand17:08:34

Not new unearthing it for @rickmoynihan

pesterhazy17:08:21

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

pesterhazy17:08:05

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

dominicm17:08:54

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

dominicm17:08:03

(This would actually make auth really easy)

rickmoynihan17:08:29

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

cgrand19:08:21

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

rickmoynihan09:08:05

Maybe, I just think there are a lot of environments (Emacs, vim, console repl etc) that aren’t going to grow a rich graphical interface anytime soon. So decoupling such a thing from the editor seems to make sense. It depends on the other tools/workflow you’re using as to whether it would be cumbersome; but I think alt-tabing to a different window isn’t too much of a burden in the worst case. In the better cases you could integrate via a tiling window manager etc… I think that the emacs REPL would still basically work as it is, and that the results of evaluations would be broadcast to the different rendering frontends, so the Emacs REPL would also render the datastructure, exploring that value just wouldn’t be as nice… Just thinking interfaces driven off of unrepl ellipsis might be richer and more widely useful if they didn’t have to be tied to be a specific editor

sooheon05:08:03

This sounds awesome, because this is essentially what I have going on in a more roundabout way with emacs and gorilla-repl. The only difference is that I require the ns I’m working on in emacs from gorilla-repl, and have to eval the datastructures/visualizations again in gorilla-repl.

pesterhazy17:08:01

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

pesterhazy17:08:50

although I could be wrong

richiardiandrea17:08:33

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

richiardiandrea17:08:07

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

dominicm17:08:04

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

pesterhazy19:08:45

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

dominicm19:08:06

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