Fork me on GitHub
#dirac
<
2018-12-13
>
dustingetz15:12:15

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

dustingetz17:12:18

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

dustingetz18: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)

darwin18:12:46

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

darwin18:12:21

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

darwin18:12:39

^ my personal opinion

dustingetz18:12:10

haha yes but in the future selfhost may be pro tool 🙂 Have you seen http://hyperfiddle.net ? Very much not a toy

darwin18:12:57

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

darwin18:12:13

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

dustingetz18: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

darwin18:12:54

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

dustingetz18:12:25

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

dustingetz18:12:35

for userland clojurescript stored in a database

dustingetz18:12:06

but compiled in browser, not compiled in nrepl

darwin18:12:00

thinking…

darwin18:12:50

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

dustingetz18: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?

darwin18:12:45

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

darwin18:12:35

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

darwin18:12:57

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

darwin18:12:47

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

dustingetz18: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

darwin18:12:52

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

dustingetz18: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?

dustingetz18:12:23

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

darwin18:12:35

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

dustingetz18:12:03

oh, of course, i see now

darwin18:12:21

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

darwin18:12:08

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

darwin18:12:32

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

dustingetz18: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?

darwin18:12:38

what do you now compile with self-hosted compiler?

darwin18:12:43

in hyperfiddle

darwin18:12:57

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

darwin18:12:16

but hyperfiddle “engine” itself is compiled as usual

dustingetz18: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)

darwin18:12:50

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

darwin18:12:42

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

darwin18:12:28

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

darwin18:12:00

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

darwin18:12:17

so better would be to have it available “automatically”

dustingetz18:12:20

Like how Klipse downloads cljc files by url

dustingetz18:12:49

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

darwin18:12:35

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

darwin18:12:55

“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.”

darwin18:12:16

that’s the problem I’m talking about,

darwin19:12:01

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

darwin19:12:25

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

dustingetz19:12:00

Yeah ok i understand

dustingetz19:12:16

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

darwin19:12:52

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

darwin19:12:01

I mean proof of concept

dustingetz19: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