This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-08-08
Channels
- # aleph (4)
- # beginners (5)
- # cljs-dev (21)
- # clojure (155)
- # clojure-dev (3)
- # clojure-italy (10)
- # clojure-losangeles (3)
- # clojure-nl (2)
- # clojure-russia (5)
- # clojure-spec (42)
- # clojure-uk (11)
- # clojurescript (170)
- # code-art (1)
- # component (3)
- # core-async (28)
- # cursive (70)
- # data-science (3)
- # datascript (1)
- # datomic (28)
- # emacs (6)
- # gorilla (1)
- # graphql (2)
- # jobs (1)
- # lein-figwheel (4)
- # lumo (7)
- # off-topic (13)
- # om (63)
- # parinfer (66)
- # planck (1)
- # re-frame (22)
- # reagent (2)
- # ring-swagger (53)
- # rum (3)
- # sql (13)
- # test-check (2)
- # unrepl (48)
- # vim (8)
- # yada (33)
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?
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…
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.
At some point I had an electron-based repl that allowed browsing but the rendering was crude. There's a gif floating around
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 assumes multiple connnections. But these connections may be provided over a multiplexed pair of streams.
oh having the choice is the best of both worlds then
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?
Not in my experience. The main drawback is that it does not work when creating when new connections are expensive or impossible.
The first drawback is vastly mitigated by the fact that a repl can be upgraded into a multiplexed server.
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.
@ghadi: cool.
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 🙂
Unrepl assumes multiple connnections. But these connections may be provided over a multiplexed pair of streams.
@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?
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
Switching application to be able to expand seems cumbersome for something so common. Ymmv
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
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.
@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
@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