Fork me on GitHub
Slack Archive

This page is not created by, affiliated with, or supported by Slack Technologies, Inc.

2019-05-15

Channels

#shadow-cljs
<
2019-05-15
>
caleb.macdonaldblack05:05:10

Anyone know what could be causing Exception in thread "main" java.lang.RuntimeException: Unable to resolve symbol: qualified-keyword? in this context, compiling:(shadow/jvm_log.clj:74:10) when running shadow-cljs watch app? Specifically in regards to this issue: https://github.com/reagent-project/reagent-template/issues/166

caleb.macdonaldblack05:05:10

I actually cannot replicate this issue myself. Perhaps java or node needs to be updated?

caleb.macdonaldblack05:05:05

Maybe somehow a version of Clojure < 1.9 is being run?

caleb.macdonaldblack05:05:24

Shadow is using :lein true and the project.clj has clojure 1.10 specified so unless that's changed I'm not sure why shadow-cljs would start with a different version of clojure

thheller07:05:36

@caleb.macdonaldblack what is the actual project.clj?

caleb.macdonaldblack07:05:25

That will be it then

caleb.macdonaldblack07:05:42

I must have been looking at the project.clj for the template instead of what was generated

caleb.macdonaldblack07:05:53

Okay thanks for that. I should be able to fix this now

Jon11:05:40

I added Google Analytics on http://shadow-cljs.org and here's the results of past days.

chrisblom12:05:45

What may cause the "Stale client! You are not using the latest compilation output"? I keep getting this error, also after recompiling and refreshing

chrisblom13:05:44

found the cause: i used another keyword than :main in [:builds :browser :modules] in the shadow-cljs.edn

thheller13:05:04

@chrisblom totally fine to use a different keyword. just need to adjust the html loading the main.js accordingly

chrisblom14:05:11

thanks, i did not notice these had to be aligned

thheller15:05:41

yeah the keyword controls the name of the output file

chadharrington17:05:13

@thheller Any thoughts on https://github.com/Dept24c/viz-min ? I'd appreciate any insights you have. Thank you for your hard work on this project.

chadharrington18:05:43

I just noticed that one of the reproduction instructions in README.md was incorrect... I have fixed that in the GitHub version.

thheller18:05:47

I really can't offer any insights here. Its a bug in the Closure Compiler.

thheller18:05:57

it has issues processing the full.render.js file ... which is huge ... 1,9mb ...

thheller18:05:22

it is also archived .. so seems like a dead project?

chadharrington20:05:37

Okay. Thanks for looking into it. I appreciate it.

Jacob Haag18:05:26

I am having an issue with a npm module that I was formerly using as a cljsjs package. formerly when using cljsjs we had 

(:require [cljsjs.fuse])

(.search
       (js/Fuse.
        js-coll
        fuse-options)
       query)
which in the past worked but when we changed it too 
(:require ["fuse" :as fuse])

(.search
       (js/Fuse.
        js-coll
        fuse-options)
       query)
I've been getting the following error 
ReferenceError: Fuse is not defined
    at eval (eval at <anonymous> (), <anonymous>:3:1)
Any ideas of the issue?

polymeris18:05:42

I think you can just do fuse instead of js/Fuse

thheller18:05:15

yes js/Fuse is accessing a global which doesn't exist. so just use the name you created via :as fuse instead.

wilkerlucio18:05:52

and you may need to change :as to :default to use it, depends on how the module is been exported

wilkerlucio18:05:26

but for this case specific, if you want, I have a Fuzzy wrapper version that works both on Shadow and Figwheel: https://github.com/wilkerlucio/fuzzy-cljs

Jacob Haag18:05:36

Nice, @U066U8JQJ I'll take a look at that

wilkerlucio18:05:44

I remember I had to copy and to some small changes to make that work, I think that's reason I did that

Jacob Haag18:05:51

I've been getting the error 

TypeError: Cannot call a class as a function
    at e$jscomp$1 ()
When trying to create an object

wilkerlucio18:05:55

are you using new?

wilkerlucio19:05:11

(can be (new Fuse) or (Fuse.))

wilkerlucio19:05:42

the errors makes it look you are calling the constructor as a fn

thheller19:05:58

@U994BRXMF (fuse. ...) not (fuse ...)

Jacob Haag19:05:00

aha, no error message! @thheller

jerome19:05:34

@thheller have you (or anyone else) noticed Chrome 74+ crashing in development mode? We're struggling with something right now, and it's probably not shadow-cljs, but wanted to rule it out since it only happens in development.

thheller20:05:17

chrome crashing?

jerome18:05:50

Since Chrome 74 we're seeing an "Aw snap" error message in all tabs pointed at our development server. Chome stack trace dumps seem to indicate something trying to access an address in memory it doesn't have access to. I doubt it's actually shadow-cljs, but since it's only in our dev environment and doesn not occur for QA or production builds I wanted to see if you've ever seen crashing like this. If not, don't worry about it, as it's most likely not our problem. 👍

thheller18:05:18

not a clue what could be causing this. did you maybe start using a new npm dependency or so recently that does weird stuff?

thheller18:05:37

I haven't seen any crashes myself during regular development

thheller18:05:13

I think I had an infinite loop once that ended up crashing the tab but that was clearly my fault

koz15:05:45

@jeromedane is this Chrome 74+ crash still happening to you? it’s happening to multiple people here and we’re not quite sure what’s causing it.

jerome16:05:56

Yes @U3GKNM1CK it's still happening to us, and we have no idea what's causing it to the point it's driving us nuts. For what it's worth, we have seen it happen once in a relatively clean project started with lein new shadow-cljs your-project +reagent while prototyping with material-ui. It seems to happen whenever there's a very specific unknown error rendering components.

jerome16:05:31

material-ui is not yet in place in our production app where we see the most crashes

koz16:05:36

The only thing I can think of is that we have a pretty large application with a good amount of namespaces. Right before chrome crashes, I usually get a message ultimately stating that one of my NPM modules is now nil. I’m wondering if there is any crazy garbage collection happening in Chrome 74+ that is cleaning up things loaded in dev via goog.require if a lot of memory is being used by the tab and crashing the browser if it tries to reference the required module. Some evidence to support this is that in the Chrome logs, it says (93)] mach_vm_read(0x7ffee0423000, 0x2000): (os/kern) invalid address (1) when the crash happens, and it seems like the crash happens after a GC happens, since when I monitor the JS memory usage, it goes up, then goes down, then crashes

4
jerome16:05:05

We've seen a "memory address access not authorized" error [or something like that] during these crashes when hooked into the chrome process debugger if that helps any.

koz16:05:06

interesting - i’ll keep looking into it and update with anything i find. it’s interesting that you got it to happen with material-ui, i’ll see if i can create a simple repro as well that might crash more consistently

koz16:05:05

@jeromedane I’m wondering if the Chrome 74 crashes are a byproduct of the new bytecode flushing feature in the V8 engine (https://v8.dev/blog/v8-release-74#bytecode-flushing) - can you please try shutting down Chrome and re-launching it from the terminal using /Applications/Google\ Chrome --js-flags="--no-flush_bytecode" and let me know if you still run into this issue?

jerome17:05:54

^^ I'll give it a shot and socialize the flag here so others do too. Will report results early next week. 👍

koz17:05:10

awesome, hope it helps!

thheller17:05:54

nothing we do should be able to crash chrome so this is very suspicious

thheller17:05:23

everyone involved using macOS?

koz17:05:54

@thheller I am using macOS - I don’t think it’s shadow crashing chrome, if I were to bet it’s trying to reference code brought in through the Closure module loader after they are being flushed out by GC. The V8 docs on the subject say: > In order to reduce V8’s memory overhead, we have implemented support for flushing compiled bytecode from functions during garbage collection if they haven’t been executed recently. In order to enable this, we keep track of the age of a function’s bytecode, incrementing the age during garbage collections, and resetting it to zero when the function is executed. Any bytecode which crosses an aging threshold is eligible to be collected by the next garbage collection, and the function resets to lazily recompile its bytecode if it is ever executed again in the future.

thheller17:05:39

but if I understand correctly this also happens in production builds where shadow-cljs is no longer involved?

koz19:05:59

@thheller i think this only happens in development

koz19:05:47

we seem to already be using :loader-mode :eval in our shadow-cljs config

koz19:05:21

we haven’t been able to repro in a release build so far

thheller20:05:47

does it happen if you have the chrome devtools open or closed?

koz20:05:15

I’ve been able to repro with it both open and closed

thheller20:05:02

hmm thought maybe the devtools would cause this but guess not

koz20:05:51

yeah originally i thought it was the (very large) source maps but happened with source maps turned off in devtools and also with devtools closed (i’ll re-confirm now)

thheller20:05:05

can you try in incognito with extensions disabled?

koz20:05:37

i removed all of my extensions to reduce variables that could be causing this

koz20:05:53

let me run in incognito just in case

thheller20:05:12

did you try this with shadow-cljs compile vs watch? don't think that the websocket would be causing issues but who knows

thheller20:05:46

also try :optimizations :simple with a release build maybe?

koz20:05:09

yeah got it crashing with incognito with dev tools closed. the only thing that’s reliably fixing it for me is starting Chrome with the --js-flags="--no-flush_bytecode" flag. I’ll try a compiled version with simple optimizations now.

koz20:05:27

definitely something with that new V8 feature though

koz20:05:07

also since it happens in Chrome 74, 75, and 76. Firefox and Safari are fine

thheller20:05:42

hmm I'm on chrome beta so I've used 74 for a while and on 75 now

thheller20:05:00

I never had any crashes .. I'm on windows though so that might be a factor

koz20:05:28

it only happens if 1) i’m doing something super memory exhaustive or 2) leave the page open for a while and then take an action. yeah not sure if it happens on windows

koz20:05:41

and it usually happens after i make a change to the app which triggers code that requires a NPM module which it can no longer find. which aligns with the V8 change that removes functions during garbage collection after a set period of time.

thheller20:05:20

but it should only be removing the jit compiled code

thheller20:05:41

it should just be using the "slow" version again until the jit kicks in again

koz20:05:50

doesn’t appear to be happening using the release build

thheller20:05:12

hmm thats odd

thheller20:05:57

:simple is pretty much the same as :advacned as far as the npm packages are concerned

koz20:05:45

can it have something to do with goog.require’s cache of the node modules getting garbage collected somehow?

thheller20:05:36

node modules don't use goog.require

thheller20:05:46

but goog.require is basically a noop, it doesn't do anything

thheller20:05:23

goog.require is basically just metadata to ensure everything is loaded properly

thheller20:05:38

but it doesn't trigger any loading itself if everything is loaded

thheller20:05:50

and shadow-cljs ensures everything is loaded

thheller20:05:59

but regardless of that nothing here should be crashing chrome 😛

thheller20:05:20

google pays money for chrome crash bugs so maybe try reporting it 😉

koz20:05:41

haha ok, i’ll have to try to make a simple, consistent repro case

thheller20:05:12

yeah I'd be interested to see that

emil0r20:05:40

Anyone got an idea on how to get https://material-ui.com/layout/grid/ to work with reagent? Looked at the reagent react interopability page, but I can’t seem to get it to work. I was working on the first variant of Basic grid

jerome20:05:59

We're about to start playing with this. See if https://github.com/reagent-project/reagent/blob/master/examples/material-ui/src/example/core.cljs helps, and I'll try to remember to circle back to this once I have a working example

emil0r20:05:31

Got it work

emil0r20:05:07

It’s a bit cumbersome. Will have to think about how to create some helper classes

emil0r20:05:42

How much js <-> clj conversion cost?

koz16:05:36

The only thing I can think of is that we have a pretty large application with a good amount of namespaces. Right before chrome crashes, I usually get a message ultimately stating that one of my NPM modules is now nil. I’m wondering if there is any crazy garbage collection happening in Chrome 74+ that is cleaning up things loaded in dev via goog.require if a lot of memory is being used by the tab and crashing the browser if it tries to reference the required module. Some evidence to support this is that in the Chrome logs, it says (93)] mach_vm_read(0x7ffee0423000, 0x2000): (os/kern) invalid address (1) when the crash happens, and it seems like the crash happens after a GC happens, since when I monitor the JS memory usage, it goes up, then goes down, then crashes

4
koz16:05:05

@jeromedane I’m wondering if the Chrome 74 crashes are a byproduct of the new bytecode flushing feature in the V8 engine (https://v8.dev/blog/v8-release-74#bytecode-flushing) - can you please try shutting down Chrome and re-launching it from the terminal using /Applications/Google\ Chrome --js-flags="--no-flush_bytecode" and let me know if you still run into this issue?