Clojurians Log v2

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

here it’s a bit different, similar to receiving a SIGHUP

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

Should this be the default behaviour? If no what else?

good point

what else could we do?

if the client disconnects, there's nowhere to write to

/dev/null ?

log files

true

maybe [:bye {:reason :disconnected :actions {:recapture-outs (....)}}]

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!“)))

and the thread keeps doing its stuff

hm

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

I think it just attepts to send the message back, gets an exception and keeps going

that *out* is not directly tied to the socket outputstream

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) 

and there’s a :reattach-outs action to recover outs in another 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.

not a fan of the overall format but very cool nonetheless

how do you make these .gif btw?

the gif doesn’t display right for me

works fine for me

gif recipe: https://gist.github.com/dergachev/4627207

cool thx for the notes

@thheller re: format, me neither but it’s a dozen CSS lines

I’m experimenting with the protocol, not the rendering

ah right, forgot its already html 😛

I’m longing to have a selhosted cljs impl of unrepl, to connect “hyrepl” to its own processes

hmm? whats wrong with the CLJ repl?

you mean the CLJ-CLJS repl or the CLJ one?

why does it have to be self-hosted cljs?

because slef-hosted is simpler to deal with

@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 <http://clojurescript.io|clojurescript.io> as self-hosted repl

Thanks!

it was an attempt to unify the code that powers planck (lumo was not out yet), the code for <http://clojurescript.io|clojurescript.io> 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