This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-04-07
Channels
- # beginners (41)
- # boot (38)
- # cider (17)
- # cljs-dev (52)
- # cljsjs (3)
- # clojure (200)
- # clojure-italy (8)
- # clojure-russia (50)
- # clojure-spec (28)
- # clojure-uk (45)
- # clojurescript (28)
- # core-async (9)
- # core-matrix (2)
- # cursive (16)
- # datascript (15)
- # datomic (50)
- # dirac (5)
- # emacs (20)
- # figwheel (8)
- # flambo (2)
- # hoplon (10)
- # incanter (1)
- # jobs (1)
- # leiningen (2)
- # lumo (26)
- # mount (171)
- # off-topic (22)
- # om (54)
- # onyx (2)
- # pedestal (27)
- # re-frame (10)
- # reagent (12)
- # ring (27)
- # ring-swagger (3)
- # rum (2)
- # slack-help (1)
- # spacemacs (134)
- # specter (6)
- # sql (15)
- # testing (20)
- # uncomplicate (5)
- # unrepl (49)
- # untangled (9)
- # yada (29)
@pesterhazy I haven’t merged your PR yet because I’d like to discuss what happens when stdin is closed and how to control that.
Currently I thought about :bye actions in the context of an upgrade (see https://github.com/cgrand/unrepl/blob/master/README.md#bye-actions)
yeah that's why I initially gave it another name, :fin
honestly not sure what the intended use for upgrading is
my focus was to tackle the practical issue of knowing when the EDN stream ends
what else would you want to happen if *in*
is closed?
If you have sent a future which prints or logs and *in*
is closed then the future dies on the next print/log
good point
what else could we do?
if the client disconnects, there's nowhere to write to
how does it work with nREPL?
and everything goes to /dev/null
until the :recapture-outs action form is issued somewhere
if you (future (do (Thread/sleep 1000) (println :foo)))
and disconnect
so I sent
(future
(println “5s to close the connection”)
(Thread/sleep 5000)
(while true (swap! a inc) (println “filling buffers if any!“)))
so nREPL must have some code in place to swap out a null output stream for *out*
after disconnect
I think that's a good (non-surprising) default behavior
A cursory review of nrepl shows me that this should not happen https://github.com/clojure/tools.nrepl/blob/master/src/main/clojure/clojure/tools/nrepl/transport.clj#L101
So now elided kvs are rendered as maps (when fetched, previously a seq of pairs was returned)
and :bye
got some attention:
(spec/def :unrepl/bye-payload
(spec/keys :opt-un [:unrepl.bye/reason :unrepl.bye/outs :unrepl/actions]))
(spec/def :unrepl.bye/reason #{:disconnection :upgrade})
;; describes what happen to background outputs after the `:bye` message:
(spec/def :unrepl.bye/outs
#{:muted ; they are muted (think `/dev/null`)
:blocked ; writing threads are blocked
:closed ; they are closed (unless handled, the IO exception kills the writer)
:cobbled}) ; everything is cobbled together (like with a plain repl)
but it’s kind of stupid of advertising :reattach-outs
on :bye
because depending on how you lost the connection you may not get it.
I have a cli tool for nrepl that I wrote, that sometimes gets killed before the messages have been received. nREPL throws exceptions when it can't send the message back. It's really annoying. The exception gets written to the stdout of the "host" process.
I’m longing to have a selhosted cljs impl of unrepl, to connect “hyrepl” to its own processes
@cgrand you can have a look at replumb
for that, I haven't update it in a while (sorry!) but I am was using it for
as self-hosted repl
it was an attempt to unify the code that powers planck (lumo was not out yet), the code for
is under Lambda-X/cljs-repl-web
on github and the file that uses replumb
is here -> https://github.com/Lambda-X/cljs-repl-web/blob/devel/src/cljs/cljs_repl_web/replumb_proxy.cljs