The aget / 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)

@mfikes might be nice to have those in separate patch

OK. Will split them into two.

this new warning is guaranteed to create chaos 🙂

probably one of the few warnings we want to put behind a false flag

and people can enable it for code style

Yes, and it would be nice to separate the warning itself from all of the (perhaps slightly dangerous) fixes for the warning.

Ahh, yeah, we can have them default to false.

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 aget and aset it can find. The warnings are turned off by default, so you'd need to enable them.

If code uses aget / aset for object access, then it makes it difficult to do anything about https://dev.clojure.org/jira/browse/CLJS-2149

Not impossible; just difficult to do efficiently while preserving abuse

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.

pretty huge change so I’m less concerned about code review and more just testing 🙂

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 🙂

AFK, but wondering if java -jar cljs.jar -m cljs.repl.browser also works :)

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

The above looks like really cool stuff. I'm wondering if might even be useful for gigantic React Native apps (where all the code is local, but you want to bring up the initial screen with minimal latency. I doubt it would matter for that use case in the end, given how quickly JavaScript can be loaded. Also wondering about self-host low-latency loading (understood if none of this works in self-hosted).

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 cljs.gen.alpha: https://jenkins.brew.sh/job/Homebrew%20Core%20Pull%20Requests/4021/version=yosemite/testReport/junit/brew-test-bot/yosemite/install_lumo/

Anyone seen this before?

@anmonteiro no but the error is quite strange

it looks like it tried to find a macro in a .cljs file no?

Looks like it. I wonder if we still have a bug in cljs.js-deps

@anmonteiro is this with master?

I'm also going to disable :parallel-build from now on since it could be the case that there's a bug in there

This is with 1.9.671

hrm, I don’t see how that could cause macro lookup in the wrong file type (but maybe)

Trying to get the new Lumo release through Homebrew

It only ever seems to happen on OSX Yosemite though

heh

I don't know what kind of conditions are in place for this to be happening

well hopefully someone else can repro

I mean seems common enough situation that someone else might run into it

I think we saw something similar in one of our builds the other day

Agreed

don't have access to the build logs ATM but will check tomorrow

Thanks

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

so ^ here’s the stacktrace

seems related to the analyzer and not js-deps

@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

sounds unlikely, but I don’t have any other ideas ATM

Further working on apply speedup. It's now beating CLJ in a few cases 🙂

@thheller it is optional your ns has to require it. No need for flag.

ah, good point

@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

(Maybe I can try to repro when I again have access to my 12-core box.)

that doesn’t look very offensive to me

the problem with this issue is that it’s non-deterministic (hence me thinking about parallel build)

I can’t repro it locally for example

so far it has only shown up in CI

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.

by all means 🙂