Fork me on GitHub

@plexus it’s very helpful, thanks!


it's mostly untested since I wasn't sure what else I needed to be able to use it


Let’s summarize the self-hosted cljs situation: • stock repls (lumo or planck) can’t be upgraded BUT using one can have a server socket upgradable repl (maybe one day it could be the default socket repl for both — wishful thinking)


• we have a print.cljc


• what is missing is a repl.cljs (given the IO differences I’m not sure a repl.cljc is worth it)


• and the blob gen (which is not high priority since stock socket repls are not upgradeable yet)


That’s all


@cgrand thanks, that's very helpful to get a bit more of the big picture > Upgrading a stock cljs (self hosted) repl requires more work. I have one working with both lumo and a branch of Planck. Is this referring to cljs-js-repl? > I'd like it to go upstream but some issues with var bindings must be solved first. Is there an issue somewhere for this that people can keep an eye on?


Yes and no (well there's an old issue for var bindings).


However a first step is to prove the value of unrepl to entice @mfikes and @anmonteiro to ship Planck and Lumo with upgradable socket repls.


to me the selling point of unrepl is that it allows smart tooling (a la cider) without the need for nrepl. I would like to work on good Emacs and Atom integration of Lumo and/or Planck, and use that as a basis for some introductory level educational material


Yeah, I don’t see any problem with putting something into Planck, once all the stuff has been worked out.


it's either that, or porting nrepl-server to bootstrapped clojurescript. It seems no one is super keen to take that on, and I can understand why. I appreciate nrepl a lot, but I think it could be a bit overengineered.


I think @futuro has been pondering ^


completely agree with @mfikes


happy to incorporate any needed changes to Lumo to support upgradable REPLs


“Upgradable REPLs” is also a really cool term btw


“My REPL is upgradable, what about yours?” 😉


"I was upgrading my REPLs before it was cool"


Lumo and Planck are like twin siblings in that they essentially support all of the same command line options, etc. They could likely support Unrepl in a similar fashion.


it's times like these I really miss an old fashioned mailing list with longer form discussion. It's so much harder to piece together a coherent story from chat history... what's the situation? what needs to happen? etc...


Planck: I need to finish off fundamental socket support. This branch is sufficient to to make Unrepl upgradeable REPLs work


It's sufficient to make Planck supports upgradable repls. (Nitpicking)


Would you be more comfortable with a google group, a github issue or a wiki?


(Is the ggroup usenet bridge still active?)


maybe some github issues on the unrepl repo would be good to have. "Lumo support for unrepl", "Planck support for unrepl", etc


from there we can link at whatever branches people are working on and summarize what the current state of things is, blockers, etc


that way you also have somewhere to point people next time someone asks, "hey when is lumo support coming", for example


seems the issue was already there simple_smile


For regular (non bootstrapped) ClojureScript, how would unrepl work there? I don't suppose you'll ever be able to upgrade a CLJS repl (or?), but I imagine you would upgrade a Clojure (un)repl to a CLJS unrepl. Possibly by providing a custom cljs.repl/repl?


Never say never. (My work on upgradable self-hosted repl made me realize an upgradable CLJS repl would be possible – not with major changes to how repls work at the moment.) Still I don't think it's the fastest way to get unrepl in the browser. Your general plan is ok (upgrade from CLJ) but to me the target is a CLJC repl.


what do you mean exactly by a CLJC repl?


(this whole thing reminds me the Lambda Island repl guide is gonna need a serious update :))


@plexus maybe I'm insane but I'm thinking of a repl that when you type (+ 2 2) you get 4 twice (once from clj, once from cljs – which may be not be that confusing given unrepl tagged outputs) and of course you can use conditional readers.


I'm not sure I'm convinced of the usefulness of evaluating things twice, but a repl that could eval clj and cljs expressions would be very useful for tooling, and get rid of some of the unnecessary complexity you have now when using cider with cljs


Either you have two repls or a modal (switching) repl or a cljc repl (where the switch is controlled form by form using conditional readers). The last one is maybe not that bad. I'm still pondering this stuff


Wow... a CLJC REPL could be useful when developing portable library code.