Clojurians
#cljs-dev
<
2015-12-11
>

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

mfikes01:12:50

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.

mfikes01:12:41

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

mfikes01:12:38

@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.

richiardiandrea02:12:18

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...

mfikes04:12:30

@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.

mfikes04:12:48

@richiardiandrea: Check out ns-unmap

richiardiandrea04:12:16

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

mfikes04:12:00

Do you mean the :refer construct in ns?

mfikes04:12:55

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

mfikes04:12:06

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.

richiardiandrea04:12:03

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

richiardiandrea04:12:19

thanks for the tips Mike

mfikes04:12:34

@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.

mfikes04:12:37

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

mfikes04:12:59

I just restart my REPL :simple_smile:

richiardiandrea04:12:50

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

mfikes04:12:10

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

richiardiandrea04:12:38

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

mfikes04:12:45

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

richiardiandrea04:12:12

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

richiardiandrea04:12:55

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

mfikes04:12:12

Ahh… great catch.

mfikes04:12:31

Perhaps it is a side effect of the merge behavior.

richiardiandrea04:12:56

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

richiardiandrea04:12:08

I am trying live

richiardiandrea04:12:12

dunno if it is mine or upstream though :smile:

mfikes04:12:42

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

richiardiandrea04:12:46

Oh wow interesting

richiardiandrea04:12:09

I will investigade as well

dnolen04:12:08

@mfikes @richiardiandrea ^

dnolen04:12:09

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

richiardiandrea04:12:55

great i will add tests to replumb when switching to 189

richiardiandrea05:12:30

@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

richiardiandrea05:12:36

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

mfikes05:12:42

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

richiardiandrea05:12:09

Yes true, I am scanning through and noticing it

thheller09:12:17

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

thheller09:12:02

ns-side-effects now actually is a compiler pass

thheller09:12:26

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

thheller09:12:58

I opted to do two things

thheller09:12:06

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

thheller09:12:36

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

thheller09:12:21

so far it has served me well :simple_smile:

spinningtopsofdoom14:12:39

@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.

dnolen14:12:57

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

alexmiller15:12:39

@spinningtopsofdoom: are you doing the cached hash stuff?

mfikes15:12:26

@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.

spinningtopsofdoom15:12:44

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.

alexmiller15:12:22

yeah, I meant the former

alexmiller15:12:00

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.

spinningtopsofdoom15:12:33

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?

bensu16:12:43

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

bensu16:12:59

(all of this related to clj files)

bronsa16:12:01

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

bronsa16:12:41

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

dnolen16:12:09

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

dnolen16:12:21

once compilation is parallel it becomes blindingly obvious

dnolen16:12:42

so not something for us to fix at all

bronsa17:12:15

@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

bronsa17:12:57

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

dnolen17:12:27

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

dnolen17:12:41

so would need to isolate

dnolen17:12:54

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

dnolen17:12:57

but you would need to try master

bronsa17:12:53

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

dnolen17:12:33

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

bronsa17:12:40

fair enough

richiardiandrea19:12:32

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

dnolen19:12:04

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