https://github.com/google/closure-compiler/issues/2644

just saw this with :parallel-build:

cljs.closure/parallel-compile-sources/fn              closure.clj:  923
                         cljs.closure/compile-task              closure.clj:  894
                      cljs.closure/compile-task/fn              closure.clj:  896
                        cljs.closure/eval6987/fn/G              closure.clj:  485
                          cljs.closure/eval7057/fn              closure.clj:  611
                     cljs.closure/compile-from-jar              closure.clj:  583
                        cljs.closure/eval6987/fn/G              closure.clj:  485
                          cljs.closure/eval7051/fn              closure.clj:  601
                         cljs.closure/compile-file              closure.clj:  532
                        cljs.compiler/compile-file            compiler.cljc: 1494
                     cljs.compiler/compile-file/fn            compiler.cljc: 1519
                       cljs.compiler/compile-file*            compiler.cljc: 1422
                      cljs.compiler/with-core-cljs            compiler.cljc: 1252
                    cljs.compiler/compile-file*/fn            compiler.cljc: 1437
                         cljs.compiler/emit-source            compiler.cljc: 1409
                cljs.analyzer/write-analysis-cache            analyzer.cljc: 3912
                          cljs.analyzer/dump-specs            analyzer.cljc: 3887
                                clojure.core/deref                 core.clj: 2317
                         clojure.core/deref-future                 core.clj: 2295
java.lang.ClassCastException: clojure.lang.Var$Unbound cannot be cast to java.util.concurrent.Future
  clojure.lang.ExceptionInfo: failed compiling file:/Users/anmonteiro/.boot/cache/tmp/Users/anmonteiro/Documents/github/lumo/1ubm/-cvhnmc/main.out/cljs/source_map.cljs

not exactly sure what’s going on here

but it’s not deterministic (when was it ever, with parallel build)

@anmonteiro seems like a require issue, but reports seems relatively rare now

@dnolen looking to backport this that landed in clojure today https://github.com/clojure/clojure/commit/46eb144b12d1b5dbf543384984a57a4dfa3d8531

our IVector protocol has assoc-n, would it be OK to add the length method there?

or is that a breaking change

that’s just completing the Java collection api

so I don’t know that it’s actually needed in cljs

actually I guess it is in IPV, nvm

that’s implementing the IPV method on primitive vectors. does cljs even have primitive vectors?

hrm, I interpreted it as if it were implementing .length in PersistentVector

CLJS doesn’t have prim vectors afaik

@alexmiller not a big deal but still a difference with Clojure if we don’t support .length on vectors

I'm not sure that's important or useful level of interop

My suspicion is that it's not there in cljs b/c it's not part of the abstraction, just impl detail

the abstractions in cljs are cleaner by virtue of being a 2nd system. don’t mess them up just to make them the same. :)

people should be invoking stuff via the core api, not via the guts. the api should be the same.

makes sense

agreed we probably don’t need this one