This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-03-24
Channels
- # beginners (108)
- # boot (16)
- # bristol-clojurians (1)
- # cider (20)
- # cljs-dev (167)
- # clojure (64)
- # clojure-greece (4)
- # clojure-hamburg (1)
- # clojure-russia (1)
- # clojure-uk (27)
- # clojurescript (235)
- # datomic (1)
- # devops (2)
- # fulcro (80)
- # graphql (6)
- # heroku (2)
- # jobs-discuss (1)
- # jobs-rus (2)
- # lein-figwheel (1)
- # lumo (2)
- # nyc (1)
- # off-topic (22)
- # portkey (4)
- # re-frame (44)
- # reagent (39)
- # ring-swagger (9)
- # shadow-cljs (90)
- # tools-deps (5)
- # vim (8)
- # yada (2)
@mfikes @dnolen This patch will make Cljs work with current Closure snapshot and current release, and no need to for reflection or other ugly tricks: https://dev.clojure.org/jira/browse/CLJS-2699
At some point, we can look into supporting ES7/8/TypeScript module processing
This closure-library svn checkout on bootstrap script seems deprecated: https://github.com/clojure/clojurescript/blob/master/script/bootstrap#L62-L77
If bootstrap is rewritten (or something) to use tools.deps it would be easy to use Closure snapshot?
@juhoteperi Windows is a blocker here
Oh right
@juhoteperi huh 2699 does that solve the scoped npm deps issue?
hmm, what's issue with scoped npm deps?
I doubt it. Is just about getting Cljs to work with both current Closure-compiler release and the snapshot.
Hmm will calling those compiler passes through those Compiler methods set the correct moduleLoader?
btw. https://github.com/clojure/clojurescript/blob/master/src/main/clojure/cljs/closure.clj#L1799-L1801 these three bindings are unused now, forgot to clean in the patch
@juhoteperi https://dev.clojure.org/jira/browse/CLJS-2697 fixes the Closure Library issue
@mfikes I reverted one of your changes, I don’t know why you need to read .cljsc_opts.edn
in compile
I know this was to handle analyze paths or something for REPL but it’s just not the right way to handle it
so probably was made early while we were still exploring how this was all going to work
@dnolen I'm going to set up new Canary subproject that builds and tests ClojureScript against the latest Closure compiler and also the latest Closure library. If you think https://dev.clojure.org/jira/browse/CLJS-2697 https://dev.clojure.org/jira/browse/CLJS-2698 are safe to have on master, I'll use the switches they provide. (If you are not comfortable with that yet, I can simply make Travis in that subproject imitate the behavior in those patches.)
Cool! I see with Juho's patch things pass. I'll set things up so we know if anything regresses going forward.
I'm going to look into https://dev.clojure.org/jira/browse/CLJS-2700. My hope is that it is just a bad test and that, after assessing I can add a filter for those two REPL environments.
@juhoteperi can confirm that your Closure patch plus my patch at least lets scoped requires work
This caught my eye, a new loader namespace of some sorts in Closure Library: https://github.com/google/closure-library/tree/master/closure/goog/loader
(I'm digging into why bootstrapping is failing in self host tests with the latest Closure Library, and some stuff may have changed. goog.dependencies_
is undefined and might be related to this new loader stuff, but not sure yet.)
Arg. Non-accretion. https://github.com/google/closure-library/commit/aa92ba3c3cf3861baec980ae2c05d9ae265d9841#diff-c359099ba4bc09bc2864536c49356d52L875
^ Captured as a future enhancement / thing https://dev.clojure.org/jira/browse/CLJS-2702
Canary is now set up to run ClojureScript through its suite using the latest Closure stuff.
A couple things are disabled, namely
lein with-profile +closure-snapshot test
(with the latest Closure Compiler) and
script/test-self-partity
(with the latest Closure Library).
I'm making sure we have JIRAs so we ultimately address the needed code changes to accommodate Closure changes.@dnolen It seems that https://github.com/clojure/clojurescript/commit/84004ff7d90d48a730b2e1e8ebc2c421830462f7 broke piggieback support for node cljs repls, due to different nREPL threads. (https://github.com/clojure/tools.nrepl/blob/fcac1e13d6f80eb0db28773247a769c1dc9659b1/src/main/clojure/clojure/tools/nrepl/middleware/interruptible_eval.clj#L131)
It works just fine until (cljs.repl.node/thread-name)
returns "nREPL-worker-1"
instead of "nREPL-worker-0"
.
I'm not familiar with nREPL's threads, but I assume there's no known reason this should break node repls.
It seems like it might be an issue with stdout getting rebound, because {"type":"result","repl":"nREPL-worker-1","status":"success","value":"true"}
ends up getting printed to the console. (It wasn't before this commit.)
Let me know if there's any more information I can provide.
@cemerick Would it be possible to constrain piggieback to a single nREPL thread?
@juhoteperi You might be interested in this one. It might be trivial or innocuous. I'm not yet familiar with that part of the codebase: https://dev.clojure.org/jira/browse/CLJS-2703
Did another pass through the doc list https://gist.github.com/mfikes/bdbe214f03abac88ae384adb1ac26490 and I think everything is pretty much up to date now.
@mfikes I've got your zippy.clj
test running against the websocket socket repl implementation and it's going strong at 1.6 million inc
s
I don't recall any headless tests, probably because you need a browser.
The only thing I'm aware of is if you run script/test-cli browser
it will fire up your browser during the tests.
Yeah, even if we have some "manual" tests in the codebase, that's better than nothing.
@john One easy stress test you can try in your browser REPL code is (range 1000000)
. I just tried that with Ambly and it completed in a few minutes (sending the range back across TCP).
@ghopper this looks like just interruptible eval - I don’t see why you can’t just discard that middleware - it doesn’t really work for ClojureScript anyway
Cool. Looks like https://dev.clojure.org/jira/browse/CLJS-2632 is no longer reproducible 🙂
@ghopper you should probably report this issue and have piggieback remove that middleware
Are there currently any "blocker" tickets? (It seems like stuff is mostly under control.)
no I lowered the priority on two things - they just don’t seem critical and we’ve delayed long enough
the nREPL thing is actually likely to cause a lot of trouble - but I don’t really see a good answer to that - other than piggieback needs to be updated
during rewrite I would vote for making it an optional feature, not implemented for everything, just for case in future there would be possibility, we could optionally implement it
Is the browser REPL used by large numbers of developers? Just curious. Something like think won't affect Figwheel users right?
for example dirac could possibly implement it: https://github.com/binaryage/dirac/issues/41
I think for any chance, you need support by all the JS engines. I think Lumo is the only one to have pulled it off in the case of V8.
well I’m not going to fix this now - but I will spend some cycles on how to work around this tomorrow
there may be I/O redirect issues - so it might fix the immediate problem but maybe printing won’t work correctly you should check for that
I'm trying it too. I saw the interruptible eval thing. (apply + (range))
lets you Ctrl-C, but then you get a cljs.user=>
prompt that won't eval anything after that. Hrm.
OK. I'll check your hack to see if it fixes things. First I want to see how easy it is to repro without it.
OK, it seems trivial to repro. Start it up, eval a form, wait 30 seconds. Deterministic failure.
Her is what I got
Exception in thread "nREPL-worker-1" java.lang.NullPointerException
at cljs.repl.node$node_eval.invokeStatic(node.clj:67)
at cljs.repl.node$node_eval.invoke(node.clj:61)
at cljs.repl.node.NodeEnv._evaluate(node.clj:235)
at user.Delegatingcljs_repl_node_NodeEnv._evaluate(form-init2154258829537880589.clj:122)
at cljs.repl$evaluate_form.invokeStatic(repl.cljc:553)
at cljs.repl$evaluate_form.invoke(repl.cljc:484)
at cljs.repl$repl_STAR_.invokeStatic(repl.cljc:930)
at cljs.repl$repl_STAR_.invoke(repl.cljc:839)
at cemerick.piggieback$run_cljs_repl.invokeStatic(piggieback.clj:169)
at cemerick.piggieback$run_cljs_repl.invoke(piggieback.clj:155)
at clojure.lang.AFn.applyToHelper(AFn.java:171)
at clojure.lang.AFn.applyTo(AFn.java:144)
at clojure.core$apply.invokeStatic(core.clj:650)
at clojure.core$apply.invoke(core.clj:641)
at cemerick.piggieback$evaluate.invokeStatic(piggieback.clj:259)
at cemerick.piggieback$evaluate.invoke(piggieback.clj:255)