Fork me on GitHub

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


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


or is that a breaking change

Alex Miller (Clojure team)22:09:24

that’s just completing the Java collection api

Alex Miller (Clojure team)22:09:39

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

Alex Miller (Clojure team)22:09:30

actually I guess it is in IPV, nvm

Alex Miller (Clojure team)22:09:12

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

Alex Miller (Clojure team)23:09:52

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

Alex Miller (Clojure team)23:09:40

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

Alex Miller (Clojure team)23:09:47

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

Alex Miller (Clojure team)23:09:21

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


agreed we probably don’t need this one