Fork me on GitHub
Dustin Getz15:12:15

I am looking for an example project that uses Boot, anyone have one?

Dustin Getz17:12:18

Yeah, i've seen that but the source is really opaque to debug, looking to just natively do it

Dustin Getz18:12:46

Darwin, has there been any discussion about level of effort to bring this to browsers running self-hosted clojurescript? (A very weird idea, just curious if it has been thought about before)


some people on reddit mentioned it in the past, where I replied, but I’m not aware of any discussion


it can be done, but I’m not sure how useful it would be, Dirac is meant as a “pro” tool, not a toy for someone to play with cljs in browser console


^ my personal opinion

Dustin Getz18:12:10

haha yes but in the future selfhost may be pro tool 🙂 Have you seen ? Very much not a toy


I’m aware of hyperfiddle, but quite frankly I didn’t understand much of it, it was over top of my head… 😕


but I understand that a massive ton of work went into it

Dustin Getz18:12:22

i am cofounder of hyperfiddle - when you say "it can be done" what is the level of effort required? E.g. a month, six months, longer


wait maybe I misunderstood your question now when I’m reading it again, I was under impression, that you wanted hosted-clojurescript REPL in Dirac, not Dirac being part of a normal browser installation

Dustin Getz18:12:25

i am wondering what it would take to offer the dirac debugging experience in prod

Dustin Getz18:12:35

for userland clojurescript stored in a database

Dustin Getz18:12:06

but compiled in browser, not compiled in nrepl




well, I think getting basic REPL evaluations working would be a weekend project, when user enters something in DevTools Console in Dirac Prompt, sendEvalRequest[1] is called, current implementation needs to behave like a nREPL client, send it to nREPL server, which compiles the cljs code to js, sends it back to weasel-like client, which requests its evaluation in app’s js context and then result is sent back*, see[2] in case of self-hosted cljs it would be much simpler: the request would be sent to app’s javascript context helper function, which would compile it using self-hosted compiler, eval it and send result back (*technically it is not needed, because output is printed into console as a side-effect, I call it “short-circuiting-presentation”) but this would be a barebone thing, people maybe expect some repl-special commands to work, like in-ns, doc etc. is there a working REPL implementation for self-hosted clojurescript? [1] [2]

Dustin Getz18:12:27

If there is not a self-hosted REPL it is possible to build though right? I guess the question is how much involvement from clojure/core team?


I don’t think we would need any special support from core team. Assuming we would not hit some bugs in self-hosted implementation.


I just need working self-hosted compiler in app’s js context. That would be primarily a job of hyperfiddle to setup it properly.


I need something like compile-cljs and eval I have in js by default


but it would be more involved, we want to execute those functions from devtools so they work even when app’s js context is stopped on a breakpoint, but that is a minor detail

Dustin Getz18:12:58

Antonin thanks for writing this down, i will save it off. What you've done with Dirac is very impressive, and i know you incur quite the burden maintaining and supporting installation etc


just note that hosted-clojurescript compiler must be in app’s js context, to match version of app’s cljs code - I cannot “embed” it into Dirac itself, because that could be version mismatch, also other Dirac features (like code completion) rely on non-minified code and sourcemaps, so hyperfiddle (even in prod) must contain them for these to work properly

Dustin Getz18:12:56

Yeah, i understand. I think we might even already be saving off analyzer state from the build and sending it down to initialize the browser compiler. Have i understood what you're saying?

Dustin Getz18:12:23

(^ That could be wrong, my co-founder handles this stuff)


I think this is another thing, I’m talking about situation when Dirac would have self-hosted compiler embedded and used it instead of in-page compiler, that could lead to unexpected compatibility issues, because “REPL” evaluations would be produced by a different compiler version

Dustin Getz18:12:03

oh, of course, i see now


you are talking about cljs compiler state (which is needed for each new compilation job), that is related to self-hosted REPL implementation, something like that must be implemented


e.g. I want to say (in-ns ...) and that means, I’m mutating compiler state for next compilation job


if I don’t have in-ns available, I would need to specify all symbols with fully qualified names

Dustin Getz18:12:16

SO basically Hyperfiddle itself has to be self-hosted and compiled in browser, and then dirac would plug into the same compiler process used to bootstrap hyperfiddle – now have I understood?


what do you now compile with self-hosted compiler?


in hyperfiddle


I assume, you use it for user’s code stored in database


but hyperfiddle “engine” itself is compiled as usual

Dustin Getz18:12:02

That's correct today, but it is problematic for reasons unrelated to dirac, i think we are going to bootstrap the whole thing. (We have a "prod mode" that is not interactive so we can bake stuff as usual, eventually do advanced mode etc)


ok, depends what you want your REPL users to be able to do, if you want them being able to go into existing namespace and see “what’s there”, then you need your compiler state to be aware of that namespace, in other words, all forms of that namespace must be already compiled at least once using that compiler state


if this was not possible, user would have to read that file in the REPL again


and the question is how this would be implemented in pure-browser env,


e.g. we could have some REPL helpers to do that by specifying URL or something like that


so better would be to have it available “automatically”

Dustin Getz18:12:20

Like how Klipse downloads cljc files by url

Dustin Getz18:12:49

Sorry if my questions are dumb, im still learning about this


no, I also don’t have deep understanding, I forgot most of it when I finished initial dirac impl


“As you probably know traditionally you had to make effort to keep your REPL environment in-sync with your runtime environment being evolved by hot-reloading.”


that’s the problem I’m talking about,


it all boils down to use one single compiler state(cache) for initial compilation and all subsequent evaluations on top of that (this is what figwheel does), otherwise you need to understand how internals work to understand why you are not seeing what you are expected to see


and how to fix that by using load-file or something like that

Dustin Getz19:12:00

Yeah ok i understand

Dustin Getz19:12:16

Thanks for all of this and for taking the time. We are not that close to implementing this, but eventually


ok, think about it, I’m willing to implement a proof of work for this, if you decided to move ahead


I mean proof of concept

Dustin Getz19:12:03

Okay, definitely, i have a lot of homework to do first and we have some competing priorities but in the medium term this seems really valuable and interesting

👍 4