Fork me on GitHub

Is anyone working on integrating cljs-in-cljs in Lumo atm, and if, needs some help/ other pair of eyes? 😀


@richiardiandrea you mean the cljs repl?


In other news: I just had an eureka moment: the dynvars problem with async eval requires no change to clojurescript at all. (So yeah I went from big change to small change to no change.)


@richiardiandrea integration should not be difficult, however @anmonteiro and @mfikes would be happier with more proof that the code is robust.


So maybe porting the tools.reader tests to test the async reader could be a start.


One minor thing to consider when integrating with Lumo and Planck: The code would be shipped with those binaries, so it is difficult to fix things, as opposed to having the code in an independent library. (A fix would require a re-release of Lumo or Planck.) So, that argues at least for having things at a relatively good state before integrating into the binaries. (I still think it makes sense to integrate, because that lower friction of use.)


will the socket handling be exposed in next Planck release?


I'm thinking of exposing it via an alpha namespace (which is currently in that branch). And in that case, if there is any unrepl intregration code that could be bundled with Planck, it could safely make use of that alpha namespace (because the bundled code would evolve with Planck). I'd just like to clean up the Planck socket code a little before merging it into Planck master, but I see no problem with it being formally released with exposure via that alpha namespace.


sounds good


I pushed some changes to cljs-js-repl: async-proof eval, remove double prompt and *1, *2, *3handling.


Now I can consider integrating @plexus cljs work in unrepl


@plexus did you consider generating a cljc blob?


Not really, I was under the assumption it would have to be split into clj and cljs so that's mainly what I tried


May be fun: get a connection, send the blob et voilà: instant unrepl!