Hmm. It looks like implicit macro loading (autoloading of macros when you :require a namespace that itself loads its own macros) doesn’t work for :use.

It’s a consequence of :require being picked out here https://github.com/clojure/clojurescript/blob/master/src/main/clojure/cljs/analyzer.cljc#L1818

No big deal probably… just some of the ns docs are slightly wrong.

@thheller: Thanks for your comments on CLJS-1507. It led me to realize there might be a formidable challenge. I was going to peek in the analysis metadata to drive the inference, but I see evidence that it may not have yet been populated owing to parsing the ns form prior to the :required ns being analyzed, which is dealt with today via https://github.com/clojure/clojurescript/blob/r1.7.189/src/main/clojure/cljs/analyzer.cljc#L1799-L1801 for at least the need to know whether a namespace loads its own macros. Crap, that’s insufficient if you want to know if a symbol refers to a macro or non-macro var. Dangit.

A newbie question, where are "store" referred vars after the evaluation? I am following :def-emits-var...I am actually trying to find a way to purge referred vars after a test...

@richiardiandrea: When you def in a REPL, there are two side effects: (1) the analysis metadata is updated, and (2) the JavaScript environment is mutated by running some code. You can see (1) in Planck, for example if you look at (get-in @planck.repl/st [:cljs.analyzer/namespaces 'cljs.user]) and then do a (def a 3) and then look again.

@richiardiandrea: Check out ns-unmap

Is this happening also for referred var (my inner answer is yes)

Do you mean the :refer construct in ns?

Yep

I don’t know how to “un-`:refer`"

I suppose you can ns-unmap the var in the origin namespace and then mess with your analysis cache to eliminate the :refer, but that sounds janky.

yep but I found maybe a bug and I will need to do it 😄

thanks for the tips Mike

as usual 👍

@richiardiandrea: Academically interesting: REPLs are designed so that :merge meta is added to ns forms employed by require, so that new requires just “add more stuff”. But if you try something like (ns cljs.user (:require foo.core)) it removes the previous refers you may have had.

Nah… good conversation. I haven’t pondered how to clean up stuff. That could also be useful outside of testing: component lifecycles, etc.

I just restart my REPL

so a refer is not a var added to your namespace technically? I cannot orientate myself in the source..mybe I need to look for it better

(A lot of Planck’s integration tests run exactly that way. They run planck, do some testing, and then let it die.)

the bug was if I try (require '[clojure.set :refer [diff]]) <- wrong refer

I’d describe it as “refer aliases a name into your namespace”.

then (require '[clojure.set :refer [difference]]), it gives me the previous error

Could not parse ns form cljs.user - Referred var clojure.set/diff does not exist

Ahh… great catch.

Perhaps it is a side effect of the merge behavior.

and then even (require 'clojure.set) returns the same

I am trying live

for reference: https://github.com/ScalaConsultants/replumb/issues/66

dunno if it is mine or upstream though 😄

It happens in Planck. It does not happen in Nashorn.

Oh wow interesting

I will investigade as well

https://github.com/clojure/clojurescript/commit/d8a47d9

@mfikes @richiardiandrea ^

basically the trick is to catch the error and simply restore the old analysis environment

great i will add tests to replumb when switching to 189

@mfikes: maybe this is the line that gets the defined vars in a namespace? -> https://github.com/clojure/clojurescript/blob/master/src/main/clojure/cljs/analyzer.cljc#L634

Probably I need to pprint @env/*compiler* to understand, which is great (that I found the way :D)

Right… I suspect there is lots of code that understands the shape of the AST. You just happened to highlight one such spot.

Yes true, I am scanning through and noticing it

@mfikes the macro stuff unfortunately is a bit tricky which is why I was using compiler passes for it initially

ns-side-effects now actually is a compiler pass

so maybe it can be done there, but check-uses must be adjusted as well

I opted to do two things

1) in namespaces that self-require via :require-macros, find all macros in that ns save as a :macros #{the-macro} set inside the ns info

2) when :refer-ing a var from another namespace, check the usual stuff and :macros

so far it has served me well

@dnolen: When you have a moment could you pull the latest Lean HAMT and run the benchmarks looking at the equality benchmarks? The results I'm getting seem way way too good to be true for equality checks between two Lean HAMT's.

@spinningtopsofdoom: will give it a try later today and report back

thanks!

@spinningtopsofdoom: are you doing the cached hash stuff?

@alexmiller: Yep

@bensu: Does the dependency graph stuff you’re messing with ultimately lead to an ability to compile via a topological sort? (If ns a depends on ns b does it lead to ns b being compiled first?) Just wondering what the goals are and whether it helps with an issue encountered related to single-pass compilation.

Oh do you mean caching the hash at the HAMT level? If so no, I'm using the bitmap indexes on the nodes as hash substitutes per the paper.

yeah, I meant the former

I did some investigation on incremental and cached hash codes when we switched hashing strategies in clojure 1.6 - it's not obvious to me how well some of those ideas would play out in the clojure impls. I think the memory layout aspects are pretty obviously good though.

The memory layout aspects are very good, I have a strong suspicion that the results I'm seeing for the worst case of equality checking are due to that. How would caching the hash work with the current hashing requirements?

@mfikes: topo sort might be needed, but I haven't cracked the single edge case yet.

(all of this related to clj files)

@dnolen: FYI we were trying parallel compilation in prod but had to disable it because it was causing :undeclared-var warnings to fire

haven't had time to look into what was going on though

@bronsa: many ClojureScript libraries do not declare their dependencies correctly

once compilation is parallel it becomes blindingly obvious

I see

so not something for us to fix at all

@dnolen: the reason why I thought this might be a cljs issue is that I'm reasonably sure I saw an undeclared-var warning in the same namespace where that var was being declared, something that doesn't happen w/o parallel compilation

but I don't see how parallel compilation would affect that, so maybe it was just caused by some stale analysis cache or something. Will let you know if I have time to try and repro

@bronsa there might be a bug but I have not seen this with any of the core libraries, transit, Om Next etc.

so would need to isolate

yeah

we also have a lock around require usage for macro loading in ClojureScript now

but you would need to try master

yes I saw that commit, I was going to wait for the next cljs release before trying parallel compilation again tbh

ok, it might be a while - there’s a few things queued up so probably not until early 2016

fair enough

but basically goog/deps.js is generated only with :optimizations :none right?

@richiardiandrea: that’s the only optimization settings where it’s actually needed