Clojurians
#cljs-dev
<
2016-07-15
>

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

mfikes12:07:40

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

pat12:07:58

@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

pat12:07:16

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

pat12:07:28

I have andare compiling andare just fine with my suggested changes

mfikes12:07:23

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

pat12:07:34

I am on master

pat12:07:49

I will look

mfikes12:07:27

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

mfikes12:07:33

@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

pat12:07:13

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

pat12:07:48

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

mfikes12:07:52

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

pat12:07:50

Yes, happens @ ana/check-uses

pat12:07:54

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

mfikes12:07:45

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)

pat12:07:07

Thats where im doing this fwiw

pat12:07:27

Im just wrapping the async functions into channels

mfikes13:07:48

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

dnolen13:07:59

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

dnolen13:07:06

@pat have you submitted your Clojure CA?

pat13:07:09

@dnolen Yep @mfikes thanks

pat13:07:41

Will try to get something up by this afternoon

thheller13:07:21

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

dnolen13:07:11

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

thheller13:07:34

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

thheller13:07:00

namespaced map reader literal things

dnolen13:07:15

"namespaced map literal" is fine

mfikes13:07:57

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

thheller13:07:40

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