This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-07-15
Channels
- # admin-announcements (2)
- # beginners (93)
- # boot (34)
- # capetown (1)
- # cider (15)
- # cljs-dev (30)
- # cljsjs (9)
- # clojars (8)
- # clojure (199)
- # clojure-austin (3)
- # clojure-france (3)
- # clojure-greece (2)
- # clojure-italy (46)
- # clojure-quebec (7)
- # clojure-russia (2)
- # clojure-spec (76)
- # clojure-uk (16)
- # clojurescript (43)
- # core-async (7)
- # cursive (14)
- # data-science (1)
- # datascript (4)
- # datomic (3)
- # devcards (60)
- # editors (5)
- # funcool (5)
- # garden (3)
- # hoplon (32)
- # immutant (22)
- # jobs (1)
- # lein-figwheel (21)
- # leiningen (1)
- # mental-health (11)
- # mount (2)
- # off-topic (6)
- # om (16)
- # onyx (15)
- # re-frame (43)
- # reagent (20)
- # rum (18)
- # specter (37)
- # sql (2)
- # testing (8)
- # untangled (7)
- # yada (19)
@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
@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.
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
@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.
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)
@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
@dnolen how do we call those #:ns{:key :value}
maps? we need support for those in cljs.reader