dirac

Dirac v1.7.2 is out: https://github.com/binaryage/dirac/releases/tag/v1.7.2
2019-10-25T00:35:54.021400Z

2019-10-25T00:39:35.024500Z

So I’m trying to use dirac, shadow-cljs and deps.edn together — I’ll completely understand if it’s too far from the supported path. I’m getting pretty far, but I’m getting tripped up during bootstrap on the following issue: Assert failed: (set? ns-roots)

2019-10-25T00:40:43.026400Z

I’ll try debugging myself some more, but I’ve included full logs from everywhere I could find in the snippet above. (except the Chrome DevTools, where I can confirm that Dirac is making its presence known — I’ll paste that too)

2019-10-25T00:40:51.026800Z

Any help would be appreciated :)

2019-10-25T01:04:03.027300Z

2019-10-25T01:04:11.027400Z

2019-10-25T01:04:44.027800Z

I guess folks didn’t have any luck so far @julien.rouse @darwin?

2019-10-25T01:05:58.028800Z

I’m curious if my (huge) snippet above is of any use in debugging, or if there’s steps that I can take to trace this back — I’m happy to dig into the error in more depth, only any pointers as to what might be causing it would help. 🙂

superstructor 2019-10-25T09:24:35.030700Z

@tekacs my impression is dirac/shadow-cljs integration needs significant expert (e.g. @darwin / @thheller) development work. See their discussion on #shadow-cljs earlier. Looks very promising steps forward but its early days and certainly not usable just by configuration at this point.

2019-10-25T12:42:01.038300Z

@tekacs in nutshell, dirac needs a clojurescript compiler to turn your REPL commands into js code to be evaluated in javascript context (in the browser), under normal circumstances it uses cljs compiler with blank state or if it detects figwheel, it uses cljs compiler with figwheel’s cljs compiler state (see [1] for mote details). Dirac uses cljs compiler through cljs.repl API[2]. And this is the problem. Shadow cljs wraps cljs compiler with its own modifications and does not support cljs.repl, it has its own custom REPL apis. This is why your setup throws. Dirac middleware tries to compile cljs code via cljs.repl API and fails, because shadow cljs monkey patching is not expecting entering via cljs.repl codepath (my assumption). It is unlikely for shadow-cljs to add support for cljs.repl. The only way forward is for Dirac to start using shadow-cljs repl apis. And this will be quite some work and maintenance for me going forward. [1] https://github.com/binaryage/dirac/blob/master/docs/about-repls.md#dirac--figwheel [2] https://github.com/binaryage/dirac/blob/master/src/nrepl/dirac/nrepl/eval.clj

2019-10-25T16:43:20.039100Z

Understood, thanks very much for explaining, both of you!

2019-10-25T16:46:01.041500Z

The Dirac (and associated libraries’) code is pretty manageable, so I could look into a patch now that I have a sense of where to start, but let me double check how/whether shadow-cljs stays in this workflow. :)

2019-10-25T16:51:23.045300Z

Thanks for your help offer I wanted to look into this over the weekend. I think I will be able to implement initial support. I guess two things will be needed: 1) implementing shadow-cljs detection and interface which will use shadow-cljs dynamically (not as a hard dependency), see how figwheel detection is done[1] 2) implementing support for shadow-cljs code-path in dirac.nrepl.eval - I think I could be still able to implement it as a cljs.repl shim, so that code won’t change much, I will just call corresponding shadow cljs repl api to compile cljs code to javascript [1] https://github.com/binaryage/dirac/blob/master/src/nrepl/dirac/nrepl/figwheel.clj

2019-10-25T16:58:23.046200Z

I think the meat is here: https://github.com/binaryage/dirac/blob/master/src/nrepl/dirac/nrepl/eval.clj#L176-L177 this needs to be done via shadow repl api

2019-10-25T17:08:56.048100Z

Mm, I’ve just been reading shadow-cljs’ repl module to look for its usage - it looks like it’ll provide all that’s necessary at a glance... https://github.com/thheller/shadow-cljs/blob/c2795128a30f45b870cb6b64763fbf2277ab53e9/src/main/shadow/cljs/repl.clj#L492 This is used to analyze: https://github.com/thheller/shadow-cljs/blob/c2795128a30f45b870cb6b64763fbf2277ab53e9/src/main/shadow/build/compiler.clj#L189 though the resulting ast isn’t exposed: https://github.com/thheller/shadow-cljs/blob/c2795128a30f45b870cb6b64763fbf2277ab53e9/src/main/shadow/cljs/repl.clj#L464

2019-10-25T17:33:11.051400Z

yes, from recent discussion with @thheller in #shadow-cljs it looks like we can almost use it as-is, and he is willing to add support for missing stuff, we will definitely need some way how to pass :locals into cljs compiler which is not currently exposed AFAICT