Clojurians Log v2

@cgrand yes I remember when you brought it up. I spent a few minutes reading through the unrepl-reader code... are you proposing to replace ensure-raw-repl for a function that would notify there's an upgrade in progress (similar to what :bye does) and instead of reverting to raw-out, wrapping the 'upgraded output' into unrepl messages?

@volrath yes, at least that.

that sounds good to me, did you have something else in mind?

I think that'd definitely ease some of the client side implementation

@pesterhazy I'm not sure if you've explored this, but I just did an experiment where I got a clojure program to run in around ~1.5s. It only did a little local network connection & disconnect in that time. But the startup time seems sufficient for unravel. Might be worth considering (I also selfishly wouldn't mind a convenient JVM wrapper for unrepl… ;))

@volrath re: something else. Maybe a way for user code to emit unrepl triples.

@dominicm are you suggesting an jvm-based unravel?

@cgrand yep.

@cgrand So I was thinking about something similar yesterday, but related to what we were discussing before regarding providing "specialized repl tools". nREPL uses middleware for this type of things (extensibility in general,) but I also understand and agree with the idea of not tempering with user input at all, so middlewares are not viable. That said, maybe adding a way to process unrepl output triples could be beneficial for client authors.. at least I think it would cover the 2 specialized repl tools examples you mentioned (pretty printing, nicer exceptions)

main thing I'm not sure about this: maybe allowing client authors to "extend" or change unrepl's core triples (:print :eval :log and so on) could be detrimental, It'd be better if they're only able to create their own triples with their own names, which I think is closer to what you're saying