This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-05-05
Channels
- # beginners (12)
- # calva (18)
- # cider (1)
- # cljs-dev (29)
- # clojure (97)
- # clojure-uk (18)
- # clojurescript (10)
- # clojureverse-ops (2)
- # cursive (7)
- # emacs (10)
- # fulcro (42)
- # graphql (36)
- # joker (1)
- # juxt (28)
- # mount (2)
- # other-languages (2)
- # pathom (1)
- # portkey (3)
- # re-frame (50)
- # shadow-cljs (42)
- # spacemacs (4)
- # sql (6)
- # yada (6)
After bumping cljs from 1.10.439
to 1.10.520
, we are seeing warnings in Maria related to certain calls to implements?
, including those that happen during destructuring. Example: https://dev.maria.cloud/gist/c901fbc959e0ca43a903d33a46f637a7?eval=true
Does anyone have an idea why this might be the case? I’ve verified that no other changes to Maria are involved (toggling the cljs version is enough to fix it) but haven’t tried creating a more isolated self-host example. Note that the URL above is our dev build, I reverted the prod build to 439.
@mhuebert try master if you can. might already be fixed https://github.com/clojure/clojurescript/commit/1fcce719377d0d1ecc1b197ed8023c48b3f5c720
there is also another code gen issue https://dev.clojure.org/jira/browse/CLJS-3076
@mfikes thx. looks like this is the relevant diff: https://github.com/clojure/clojurescript/compare/289014c4db9877246419ffbd64eac28392aef125...c15e1257458069b4e71c99841a1a75d39072320f
there is a jump of 2 commits there, the 2nd one i can verify the actual error i experience now, the 1st one broke in a different way
it looks like there are some basic bootstrap/selfhost tests, i can try modifying one of those
@mhuebert That would work. Or even in a REPL as described here https://clojurescript.org/community/reporting-bootstrap-issues
hmm odd, when i try those instructions I get Namespace cljs.repl.nashorn does not exist. {:cljs.main/error :invalid-arg}
@mhuebert My hunch: When the compiler sees an expression like
(if (implements? IAtom x) ,,,)
it is going to analyze the first thing in that list to see if it is cljs.core/implements?
, and Maria might not have the analysis metadata related to the core macros namespace loaded or somesuch. (Something close to the point of that particular analysis step, which is being done in cljs.analyzer/type-check-induced-tag
)Tracking down the above on the side with @mhuebert
At its core is that Maria repros the error if you evaluate implements?
(as opposed to indicating that you can't take the value of a macro, and this implies the analysis meta for the core macros namespace isn't available)
thanks to @mfikes for helping me track this down. I didn’t realize that to implement a warning handler, one should check for a warning’s :warning-type
in the dynamically-bound cljs.analyzer/*cljs-warnings*
map. In this case, the warning about implements?
was inside a no-warn
expression, so it was signalled to be suppressed, but we weren’t checking for that. We still have an issue re: wrong error messages about macros (should be “can’t take the value of a macro” not “undeclared var”) but we can already push this fix and continue using the latest cljs version.
turns out our incorrect macro messages were the result of our own error-message wrapping
found a weird thing: a particular JS library react-apollo
returns results without a constructor
property
the results looks like { "rates" [{ "currency": "USD", rate: "1.00"}, ...] }
but because it doesn’t have a constructor
property, (type results)
returns nil
which means that js->clj
does nothing since it uses (identical? (type x) js/Object)
to check if it should convert it to a map
This problem has always driven me nuts. All sorts of "Js objects" can't really get converted with js->clj
I wonder if there’s a way to handle something like this in js->clj
? or if this is even common?
yeah I ended up using mhuebert’s js-interop lib: https://github.com/Lokeh/apollo-cljs-example/blob/master/src/apollo_example/core.cljs#L23