This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-11-12
Channels
- # bangalore-clj (1)
- # beginners (10)
- # boot (5)
- # cljs-dev (47)
- # cljsrn (19)
- # clojure (57)
- # clojure-russia (63)
- # clojure-spec (26)
- # clojure-uk (7)
- # clojurescript (104)
- # cursive (26)
- # data-science (2)
- # datomic (1)
- # dirac (1)
- # hoplon (11)
- # juxt (23)
- # off-topic (16)
- # om (6)
- # onyx (3)
- # parinfer (2)
- # protorepl (2)
- # re-frame (1)
- # ring-swagger (1)
- # untangled (2)
just found a problem in shadow-build
that I'm pretty sure cljs
will have as well, don't have time to verify
since it is only available via the [::ana/namespaces ns :name]
meta and that is not written to disk
Submitted a number of patches today that address some bugs I found out while giving current master a spin
@thheller seems like a simple thing to fix, we should add :ns-meta
to the analysis data
@dnolen easier to answer you question in CLJS-1848 here. If you look at how the :js-module-index
map is structured, you'll get the bug: https://github.com/clojure/clojurescript/commit/1f2c0a922130769a3da398aa501b3621fd1f8cd5#diff-d32ae4da93f4291162e396e053e5ff0dR57
particularly, I was getting a huge number of undeclared var/NS warnings when doing the Om stuff I mentioned in the #om channel
@anmonteiro but why didn’t we see this with the circle-demo?
hrm let me investigate
@dnolen because it doesn't reach that test
the and
clause bails out earlier
@dnolen though there's something weird
in the circle color project, the prefix
is module$resources$public$js$libs$react
, in the Om case I tried it was React
so my understanding is the following:
when a (processed) JS module calls React, the prefix is module$resources$public$js$libs$react
, when we call from a ClojureScript namespace, the prefix is React
@anmonteiro https://github.com/swannodette/circle-color/blob/test/src/circle_color/core.cljs
oh that's right, I didn't read my full output
my conclusion above is wrong
@dnolen OH I know
the problem was in defui
, so the problem occurs when analyzing a macro expansion
which leads me to believe the solution should be different from the one in my patch
we probably should add the {React React}
case, like we do for namespaces aliases
and keep checking the values in js-module-exists?
does the above sound good?
I can try that and check both projects again
(and provide an explanation as to why we need to do it, of course)
when we require any namespace, say cljs.test
we add a {cljs.test cljs.test}
entry to requires map
which I think we should do in the :js-modules-index
too for macroexpansion to work
yeah, I just confirmed the bug happens as a result of macroexpansion
@dnolen updated the issue with the actual fix for the problem http://dev.clojure.org/jira/browse/CLJS-1848
We have a use case that makes equiv on a defrecord a hotspot. Would you entertain a patch that makes the IEquiv implimentation that emit-defrecord emits call equiv on all field inline and only do equivmap on extmap ?
great either I or @favila will make a ticket and patch soon