This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # adventofcode (76)
- # announcements (6)
- # beginners (103)
- # boot (28)
- # calva (128)
- # cider (48)
- # cljs-dev (40)
- # clojure (268)
- # clojure-austin (2)
- # clojure-dev (2)
- # clojure-europe (47)
- # clojure-italy (10)
- # clojure-nl (17)
- # clojure-spec (2)
- # clojure-uk (15)
- # clojurescript (45)
- # code-reviews (14)
- # cursive (5)
- # data-science (2)
- # datascript (1)
- # datomic (52)
- # duct (4)
- # emacs (2)
- # figwheel (1)
- # figwheel-main (4)
- # fulcro (13)
- # hyperfiddle (51)
- # leiningen (19)
- # nrepl (40)
- # off-topic (45)
- # pathom (3)
- # pedestal (28)
- # portkey (7)
- # re-frame (25)
- # reagent (76)
- # reitit (7)
- # shadow-cljs (92)
- # slack-help (3)
- # specter (5)
- # timbre (2)
- # tools-deps (39)
- # unrepl (1)
- # vim (13)
As I was reading Drawbridge, I stumbled on:
Wouldn’t it be more sensible to prefer
(if (find-ns 'clojure.tools.nrepl) (require '[clojure.tools.nrepl :as nrepl] '[clojure.tools.nrepl.server :as server] '[clojure.tools.nrepl.transport :as transport]) (require '[nrepl.core :as nrepl] '[nrepl.server :as server] '[nrepl.transport :as transport]))
@cfleming putting my thoughts together would take time and a small article. streaming pros: super simple model: 1 connection :: 1 repl :: 1 thread; can be taken over (powerful) streaming cons: tracking progress (see prepl and unrepl takes), mixed output streams (because of laziness, modern envs with more than 1 thread, err vs out etc.) (again unrepl and prepl both frame outputs, so their output is a stream of forms instead of a stream of characters); can be taken over (interfer with framing) RPC pros: 1 connection for everything; easy progress report (because framed input) RPC cons: thread management/serialization of evals; explicit lifecycle management; can not be taken over
@cgrand Probably. I didn’t think much about this, as it was supposed to be a temporary measure and now that leiningen ships nREPL 0.5 we can remove all the compatibility code.
Probably I’ll cut one more release of cider-nrepl that supports tools.nrepl and afterwards I’ll go over all the middleware/transport projects and drop this for simplicity’s sake.
I’m happy to report that datafy/nav is now supported by rich (unrepl) printing: https://github.com/nrepl/nrepl/commit/26e51fbca0dfba5a9ee247605445df7e58e83269
Obviously (as for elisions) it requires client-side ui.
A datafiable value is represented as
#unrepl/browsable [plain-value browsable-value] and to make this lazy the
browsable-value is elided.
For nav, it’s the same thing: if the datafied value is a map or a vector and is navigable then the map values becomes elided
#unrepl/browsable whose elision triggers
@cgrand I've been playing with the idea of not needing client side UI by binding variables to ..1 ..2 ..3 and so forth. Except I can't quite make the idea work.
Ahh, I wasn't to worried about that. I was worried about needing to keep the numbers forever.
with datafy/nav, many values may be littered with small affordances hinting that an alternate view is available
Anyway, I'm super excited to have this somehow baked in to my REPL. It solves quite a few problems for me, including 10,000 line exceptions in my primary app. So, thanks for working on it!
Hey, that brings up a question about the nREPL client API. Why have a split between connection and client? It doesn't seem like multiple clients are possible per connection.
@cgrand Thanks! I agree that the main benefit of streaming REPLs is that they’re composable, but that definitely comes at a cost.
@cfleming no they are not; see https://github.com/nrepl/nrepl/issues/45#issuecomment-444476311
@dominicm I meant, to be clear, that it doesn't seem to add anything, AFAICT. There's not concept of client on the wire protocol, only session. And that's another layer of abstraction in the API.
I don't have a point, I want to understand abstracting clients from connections and sessions.