This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # aleph (14)
- # boot (4)
- # cider (3)
- # clara (1)
- # cljs-dev (62)
- # cljsrn (20)
- # clojure (81)
- # clojure-berlin (2)
- # clojure-russia (76)
- # clojure-spec (35)
- # clojure-turkiye (1)
- # clojurescript (84)
- # cursive (2)
- # data-science (6)
- # datomic (4)
- # hoplon (92)
- # lumo (35)
- # om-next (1)
- # pedestal (2)
- # re-frame (2)
- # reagent (36)
- # ring-swagger (10)
- # unrepl (30)
- # untangled (124)
aset warning patch found 15 abuses in the std lib and a handful more in the test suite. (Supplied fixes for those in a revised patch in CLJS-2148)
Yes, and it would be nice to separate the warning itself from all of the (perhaps slightly dangerous) fixes for the warning.
As David suggested, there is now a
CLJS-2148-v2.patch attached to https://dev.clojure.org/jira/browse/CLJS-2148 that you can try on your codebases to see how many abuses of
aset it can find. The warnings are turned off by default, so you'd need to enable them.
If code uses
aset for object access, then it makes it difficult to do anything about https://dev.clojure.org/jira/browse/CLJS-2149
Perhaps the code emitted could depend on what type the analyzer infers. That would be a mess, but would shove some of the inefficiency out of runtime to compile time.
Would be nice to get some eyes on this https://gist.github.com/swannodette/6150d4213aeb9eba31e03ae522af4425
I’ve tested the
module-loader-preflight branch quite a bit - all tests (core, lein, self-host, self-parity), all REPLs (browser, nashorn, rhino, node), JS module guides, on Om (w/ Figwheel), on a trivial cljsjs.react project and I tested this new guide of course.
but more testing would be good as it required touching quite a bit of code so that we could compute the information required by ModuleManager in straightforward way.
while thinking through the
:none where we need to load stuff dynamically - I went ahead and re-considered what @thheller said about assigning compiler inputs to modules - and I copied what Google Closure JSModuleGraph does more or less.
but for the curious https://github.com/clojure/clojurescript/compare/module-loader-preflight
also can’t believe I just realized that
java -cp cljs.jar clojure.main -m cljs.repl.browser works for starting a local webserver 🙂
right, we should make this a hair nicer so you can get just the simple webserver and not the REPL
I’ve been instinctively using
python -m SimpleHTTPServer 8000 but this isn’t so nice for tutorials
hrm hard to say - code splits are driven by network latency - so your parse times would probably be have to be worse than that to be impactful?
Trying to track an intermittent issue with
I'm also going to disable
:parallel-build from now on since it could be the case that there's a bug in there
just verified it happens on Windows too (and macOS Sierra). opened https://dev.clojure.org/jira/browse/CLJS-2153
here’s the Windows build where the problem occurs: https://ci.appveyor.com/project/anmonteiro/lumo/build/815
java.lang.Thread.run Thread.java: 745 java.util.concurrent.ThreadPoolExecutor$Worker.run ThreadPoolExecutor.java: 617 java.util.concurrent.ThreadPoolExecutor.runWorker ThreadPoolExecutor.java: 1142 ... clojure.core/bound-fn*/fn core.clj: 2000 clojure.core/apply core.clj: 661 ... clojure.core/with-bindings* core.clj: 1970 (repeats 2 times) clojure.core/apply core.clj: 657 ... cljs.closure/parallel-compile-sources/fn closure.clj: 889 cljs.closure/compile-task closure.clj: 858 cljs.closure/compile-task/fn closure.clj: 862 cljs.closure/eval6343/fn/G closure.clj: 450 cljs.closure/eval6413/fn closure.clj: 576 cljs.closure/compile-from-jar closure.clj: 548 cljs.closure/eval6343/fn/G closure.clj: 450 cljs.closure/eval6407/fn closure.clj: 566 cljs.closure/compile-file closure.clj: 497 cljs.compiler/compile-file compiler.cljc: 1436 cljs.compiler/compile-file/fn compiler.cljc: 1459 cljs.compiler/compile-file* compiler.cljc: 1370 cljs.compiler/with-core-cljs compiler.cljc: 1206 cljs.compiler/compile-file*/fn compiler.cljc: 1381 cljs.compiler/emit-source compiler.cljc: 1307 cljs.analyzer/analyze analyzer.cljc: 3352 cljs.analyzer/analyze* analyzer.cljc: 3328 clojure.core/reduce core.clj: 6703 ... cljs.analyzer/analyze*/fn analyzer.cljc: 3328 cljs.analyzer/ns-side-effects analyzer.cljc: 3265 cljs.analyzer/check-use-macros-inferring-missing analyzer.cljc: 2055 ... clojure.core/update-in core.clj: 6054 clojure.core/update-in core.clj: 6068 clojure.core/update-in/up core.clj: 6067 clojure.core/apply core.clj: 659 ... cljs.analyzer/check-use-macros-inferring-missing/fn analyzer.cljc: 2057 cljs.analyzer/check-use-macros analyzer.cljc: 2043 cljs.analyzer/error analyzer.cljc: 655 cljs.analyzer/error analyzer.cljc: 657 clojure.core/ex-info core.clj: 4725 clojure.lang.ExceptionInfo: Invalid :refer, macro cljs.spec.gen.alpha/lazy-prims does not exist in file C:\Users\appveyor\.boot\cache\tmp\projects\lumo\18g\-gi273p\main.out\cljs\spec\gen\alpha.cljs
@dnolen I don’t see a
:module-loader config option in your example? I think the loader should be optional since it adds quite a few dependencies itself
I wonder if there could be some sort of concurrency bug in acquiring these locks: https://github.com/clojure/clojurescript/blob/master/src/main/clojure/cljs/analyzer.cljc#L3244-L3262
@anmonteiro if the concurrency thing is relatively reproducible, perhaps a git bisect, or a coarse-grained "first compiler version" would let us pinpoint. I was looking at this recent commit, wondering if the
::no-resolve could derail things somehow in concurrent code https://github.com/clojure/clojurescript/commit/01a1427e45c9726244940baeeb37b7511acbd8b1
the problem with this issue is that it’s non-deterministic (hence me thinking about parallel build)
That reminds me, I've turned off
:parallel-build for Planck owing to a fairly reproducible Transit-related bug I need to track down. Maybe I can spend some time with Lumo with
:parallel-build as well and try to shake out any concurrency bugs.