Fork me on GitHub
#clojurescript
<
2020-01-10
>
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?

p-himik09:01:40

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

p-himik09:01:54

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.

p-himik09:01:38

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
andrea.crotti10:01:34

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

thheller10:01:51

define slow to work with?

andrea.crotti10:01:14

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

andrea.crotti10:01:30

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

andrea.crotti10:01:02

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

andrea.crotti10:01:07

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

thheller10:01:26

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

andrea.crotti10:01:45

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

thheller10:01:53

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

andrea.crotti10:01:03

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

thheller10:01:32

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

thheller10:01:01

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

andrea.crotti10:01:56

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

andrea.crotti10:01:15

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

thheller10:01:33

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

thheller10:01:51

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

andrea.crotti10:01:28

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

thheller10:01:26

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

andrea.crotti10:01:33

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

thheller10:01:48

maybe try setting :verbose true

thheller10:01:05

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

andrea.crotti10:01:29

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

darwin15:01:20

hi, anyone feeling like helping me catch remaining issues with new Dirac release? thanks! please follow quick start here: https://github.com/binaryage/dirac#quick-start 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?

darwin15:01:00

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

darwin15:01:07

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.

darwin15:01:14

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

darwin15:01:37

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

darwin15:01:29

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

darwin15:01:28

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