I am looking for an example project that uses Boot, anyone have one?
AFAIK, boot-cljs-devtools had support at some point: https://github.com/boot-clj/boot-cljs-devtools/blob/master/src/powerlaces/boot_cljs_devtools.clj#L74
Yeah, i've seen that but the source is really opaque to debug, looking to just natively do it
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
haha yes but in the future selfhost may be pro tool 🙂 Have you seen http://hyperfiddle.net ? 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
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
i am wondering what it would take to offer the dirac debugging experience in prod
for userland clojurescript stored in a database
but compiled in browser, not compiled in nrepl
thinking…
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] https://github.com/binaryage/dirac/blob/master/resources/unpacked/devtools/front_end/console/ConsoleView.js#L1006
[2] https://github.com/binaryage/dirac/blob/master/docs/about-repls.md#dirac
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
I see
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
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?
(^ 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
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
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
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
yeah
if this was not possible, user would have to read that file in the REPL again
right
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”
Like how Klipse downloads cljc files by url
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
lol.
did you get to this? https://github.com/binaryage/dirac/blob/master/docs/about-repls.md#dirac--figwheel
“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
Yeah ok i understand
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
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