Fork me on GitHub

@pat: Thinking a little more on your comment yesterday, are you already using Andare, and finding that env/*compiler* is not set at times?


@mfikes yes I should have said so. I think this is more to do with the dynamic binding within js.cljs. Even without a go-block, calling the load-fn's cb downstream of a take! will not work


Things will hum along for awhile and then you'll get a runtime 'no deref for type null' long after things have loaded


I have andare compiling andare just fine with my suggested changes


@pat Is this with a released version of ClojureScript, or with master? There are a couple of changes I made (CLJS-1694 and CLJS-1695) and I’m wondering if they in any way provoke or exacerbate what you are seeing.


I am on master


I will look


Thanks. Yeah, it would be nice to decide if either of those caused a regression with respect to binding.


@pat another thing to look out for is inadvertently ever letting the JavaScript associated with the cljs.env namespace be loaded more than once… that would cause env/*compiler* to be re-set to nil and would trigger a no deref for type null error


Yes I saw you post something about that somewhere, not the issue


I checked out just before CLJS-1694, same err.


@pat OK, so no regression, but you’d summarize the problem as: If you call the load-fn callback asynchronously, then the bindings set up in cljs.js (which have been deactivated) are used in subsequent load processing.


Yes, happens @ ana/check-uses


'Could not parse ns form...No protocol method IDeref defined for type null'


That kind of error makes some sense to me. (I never see it because in Planck call the load fn synchronously), but I think I’ve seen hints of that kind of stuff with the use of Node in the ClojureScript unit tests (which involves Node’s async file load fn)


Thats where im doing this fwiw


Im just wrapping the async functions into channels


@dnolen: A summary of the above. I believe @pat has indeed found a valid defect in the case where the cljs.js/*load-fn* callback is called asynchronously, and where analyzer functions are called which themselves rely on dynamic-bindings instead of explicitly passed values. (@pat sees it and I don’t because Planck calls back essentially synchronously, while @pat is using Node’s async file loading fn). The simplest case appears to be check-uses. @pat: It should be possible to write a minimal JIRA that exhibits the issue, IMHO, probably using cljs.js in a REPL, evaluating an ns form, and using js/setTimeout before calling back with some code that itself uses another ns form, or something along those lines to trip it up.


@mfikes: ok good to know, happy to see a patch then would be nice to get a review of that as well @pat


@pat have you submitted your Clojure CA?


Will try to get something up by this afternoon


@dnolen how do we call those #:ns{:key :value} maps? we need support for those in cljs.reader


@thheller: yes we do need support for that in the provided reader


wanted to open an issue just now but can't remember what they are called 😛


namespaced map reader literal things


"namespaced map literal" is fine


Incidentally, namespaced map literals are good to go for bootstrap, because of the different reader used there.


yeah just ran into it by accident when I switched to clojure 1.9 and it started printing some of those maps