Fork me on GitHub
#unrepl
<
2017-04-07
>
cgrand09:04:22

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

cgrand09:04:51

Currently I thought about :bye actions in the context of an upgrade (see https://github.com/cgrand/unrepl/blob/master/README.md#bye-actions)

cgrand09:04:14

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

pesterhazy09:04:47

yeah that's why I initially gave it another name, :fin

pesterhazy09:04:36

honestly not sure what the intended use for upgrading is

pesterhazy09:04:02

my focus was to tackle the practical issue of knowing when the EDN stream ends

pesterhazy09:04:29

what else would you want to happen if *in* is closed?

cgrand09:04:04

If you have sent a future which prints or logs and *in* is closed then the future dies on the next print/log

cgrand09:04:14

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

pesterhazy09:04:24

what else could we do?

pesterhazy09:04:40

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

cgrand09:04:09

/dev/null ?

cgrand09:04:36

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

pesterhazy09:04:26

how does it work with nREPL?

cgrand09:04:51

and everything goes to /dev/null until the :recapture-outs action form is issued somewhere

pesterhazy09:04:57

if you (future (do (Thread/sleep 1000) (println :foo))) and disconnect

cgrand09:04:46

so I sent

(future
  (println “5s to close the connection”)
  (Thread/sleep 5000)
  (while true (swap! a inc) (println “filling buffers if any!“)))

cgrand09:04:54

and the thread keeps doing its stuff

pesterhazy09:04:25

so nREPL must have some code in place to swap out a null output stream for *out* after disconnect

pesterhazy09:04:51

I think that's a good (non-surprising) default behavior

cgrand09:04:11

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

cgrand09:04:34

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

cgrand13:04:06

So now elided kvs are rendered as maps (when fetched, previously a seq of pairs was returned)

cgrand13:04:14

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) 

cgrand13:04:37

and there’s a :reattach-outs action to recover outs in another repl

cgrand13:04:33

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.

dominicm14:04:28

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.

thheller15:04:32

not a fan of the overall format but very cool nonetheless

thheller15:04:59

how do you make these .gif btw?

cgrand15:04:07

the gif doesn’t display right for me

thheller15:04:07

works fine for me

thheller15:04:33

cool thx for the notes

cgrand15:04:45

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

cgrand15:04:56

I’m experimenting with the protocol, not the rendering

thheller15:04:36

ah right, forgot its already html 😛

cgrand15:04:19

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

thheller15:04:35

hmm? whats wrong with the CLJ repl?

cgrand15:04:56

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

thheller15:04:19

why does it have to be self-hosted cljs?

cgrand15:04:31

because slef-hosted is simpler to deal with

richiardiandrea16:04:46

@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

richiardiandrea16:04:03

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