just found a problem in shadow-build that I'm pretty sure cljs will have as well, don't have time to verify

ns caching will lose the ns metadata

since it is only available via the [::ana/namespaces ns :name] meta and that is not written to disk

maybe someone else is interested in verifying

so (ns my.ns {:fancy true}) will not have the metadata when loading from cache

not a widely used feature but docstrings are lost as well

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

feel free to file an issue

@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

where at js-loaded-ns?

yeah

@dnolen though there's something weird

yeah I’d like to understand what’s going on here

if there’s something to clean up we should do it

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

I didn’t encounter what you are saying

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

yeah ok

we probably should add the {React React} case, like we do for namespaces aliases

and keep checking the values in js-module-exists?

right whatever patch we come up with - we should provide a detailed explanation

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)

I’m assuming you’re saying that we always provide an ns as an alias to itself?

so we need to in this case as well?

yeah

when we require any namespace, say cljs.test we add a {cljs.test cljs.test} entry to requires map

right

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 ?

@dspiteself: yes

great either I or @favila will make a ticket and patch soon