Fork me on GitHub
Vitor Barbosa09:01:07

Hi there! I'm having a very weird Uncaught TypeError: XR.V is not a function error that happens only in chrome versions 79.*. Both chrome 78, 75 and Firefox loads the page just fine. Is anyone else having issues with Chrome 79?


What do use to build CLJS?

Vitor Barbosa09:01:25

We use lein-figwheel

Roman Liutikov09:01:04

XR is a global var in Chrome, probably some Browser API

Roman Liutikov09:01:24

so looks like your genereted JS clashes with Browser’s env

Roman Liutikov09:01:53

your generated JS should be wrapped into self invoking function then


IIRC, an updated version of Google Closure Compiler handles the XR issue. So likely an upgrade of whatever CLJS build tools is used would fix it.


It has been discussed before, and if my memory serves me well, an update of shadow-cljs has fixed the issue. No idea about other tools.

Roman Liutikov09:01:45

as for updating GCC, it ships with ClojureScript, so you’d need to overwrite GCC version then

Vitor Barbosa09:01:04

Cool! Thanks guys, you just saved my life 🙂

👍 4

how are people dealing with large clojure/clojurescript projects? we have a project which is becoming quite large and very slow to work with


define slow to work with?


so the figwheel-main reload takes up to 10 seconds maybe, depending on what file you change


I also get a few thread starvation issues with jetty sometimes, so somehow it's consuming lots of resources


I tried to look with VisualVM to get some insight of what is the problem but I could not find that much, possibly we just have too many dependencies and we load everything at startup


it's a massive SPA with re-frame in short, with the API deployed together with it


in figwheel :recompile-dependents defaults to true. making that false can make things faster, but might make hot-reload a bit unreliable


yeah one colleague is using that, but I would like a more proper solution.


maybe try shadow-cljs, I'm told its faster by people that have switched 😛


I was wondering if maybe we could use Lein for the API and shadow for the Frontend exactly


otherwise people use the REPL approach. so no hot-reload at all and rather trigger updates from the REPL


that is generally a lot faster but requires pressing a few keys instead of just saving


yeah sure, well the best thing about figwheel-main & is the live reload, would like not to lose that. does anyone use lein+shadow in the same project? I guess the deployment maybe becomes a bit more tricky, but well we can then deploy API and frontend separately


which in a way could be a good thing, we might just lose some CLJC goodness though in the process, which might not be such a big issue though


you don't lose anything. you can either use shadow-cljs with lein or without


you pretty much use it like you use figwheel-main now


well I mean splitting the project into two really, backend and frontend, so there would not be an opportunity to share code anymore


well you can use the same source paths in both "projects"


the other thing I find quite hard is to measure where the time/ram usage goes, specially when the project loads the first time or does a live reload


maybe try setting :verbose true


shadow-cljs will tell you exactly where time goes with verbose. dunno about figwheel though


ah ok nice, ok then I'll do some experiments


hi, anyone feeling like helping me catch remaining issues with new Dirac release? thanks! please follow quick start here: I wonder if you can complete it on your system (mac/linux)

Eamonn Sullivan15:01:00

So, I thought I'd give this a shot, but fell over at the first hurdle: installing Dirac. Is there a particular version of shasum that you need?


ah, thanks I looked at shasum man page under macOS, it looks like -p is not supported elsewhere


let me update it quick

Eamonn Sullivan15:01:58

I am on MacOS, but maybe not the same version. I'll give it another shot.

Eamonn Sullivan15:01:30

This is what happened when I tried to run it. I have the full report, if you need it.


hmm, it looks like I didn’t include clojurescript dependency into final jar


probably I have it in /.lein or /.clojure and that is why it worked on my machine


could you try running env DIRAC_CLI_VERSION=master dirac, that should clone master and use deps.edn there, so it should work around that issue


clojars agrees that clojurescript dep is not there: alternative workaround would be to include clojurescript on your classpath by default, but I don’t want to go that route