This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-03-05
Channels
- # beginners (229)
- # cider (54)
- # cljs-dev (187)
- # cljsrn (1)
- # clojure (187)
- # clojure-dev (5)
- # clojure-italy (31)
- # clojure-losangeles (1)
- # clojure-russia (3)
- # clojure-spec (76)
- # clojure-uk (29)
- # clojurescript (94)
- # cursive (18)
- # datascript (8)
- # datomic (26)
- # docker (6)
- # emacs (19)
- # figwheel (6)
- # fulcro (41)
- # garden (1)
- # graphql (1)
- # hoplon (33)
- # jobs (1)
- # jobs-discuss (1)
- # lein-figwheel (14)
- # leiningen (7)
- # nrepl (10)
- # nyc (1)
- # off-topic (2)
- # onyx (2)
- # parinfer (25)
- # portkey (6)
- # powderkeg (1)
- # protorepl (1)
- # re-frame (14)
- # reagent (14)
- # shadow-cljs (31)
- # spacemacs (3)
- # test-check (33)
- # uncomplicate (1)
- # unrepl (40)
- # vim (5)
- # yada (16)
It turns out that https://dev.clojure.org/jira/browse/CLJS-2611 was a bit more serious of a problem than simply failing to map stacktraces: A mixture of "out"
and synthetic temp dir were being used.
The cljs.jar
that ships with 1.10.126 includes Clojure 1.10.0-alpha4. (Wondering if that is intentional)
One Quick Start feedback repeated another regarding separating Windows and Unix https://twitter.com/mamuninfo2/status/970588433713389568
IMHO, this would help, but perhaps Windows version of clj
isn't that far off in the big scheme of things.
Argh, I’m debugging the hell out of the :npm-deps
indexing and conversion to Closure modules but I still only have vague ideas of what might be going wrong.
With the shared AOT cache, if code in a JAR results in an analyzer warning, you generally only see it once, whereas previously you would see it after a "clean". (I have no profound thoughts on this; just sharing.)
@mfikes yeah I don’t think we should necessarily do anything about that other than document that :aot-cache false
is a good idea when sorting through an issue
@dnolen Here’s my current take:
* They are present as :foreign-libs
before https://github.com/clojure/clojurescript/blob/master/src/main/clojure/cljs/closure.clj#L2771
* They are moved to :libs
via the handle-js-modules
call
* They are dropped (as in: only the entry point .mjs file survives) in add-js-sources
: https://github.com/clojure/clojurescript/blob/master/src/main/clojure/cljs/closure.clj#L2777
And more specifically, add-js-sources
tries to traverse the JS depedencies via js-dependencies
but they are not present in the :js-dependency-index
right here: https://github.com/clojure/clojurescript/blob/master/src/main/clojure/cljs/closure.clj#L704
Assuming they should be in :js-dependency-index
, I haven’t figured out why they aren’t there.
One difference I noticed is that e.g. ...$graphql$index-mjs
depends on ...$graphql$execution
but the only thing we have is ...$graphql$execution$index-mjs
.
Even though the :provides
of the indexed .../graphql/execution/index.mjs
includes all of ("graphql/execution/index.mjs", "graphql/execution/index" "graphql/execution")
.
Regular .js
modules from other dependencies (e.g. React) are typically written with goog.provide('...$react$index')
(instead of e.g. goog.provide('...$react$index-js')
).
@dnolen captured need to document :aot-cache
compiler option https://github.com/clojure/clojurescript-site/issues/182
@dnolen Ok, but don’t we write the cljs_deps.js
file the processed node_modules
dir with the goog.provide
entries?
@jannis https://github.com/google/closure-compiler/blob/38bc30e96aac143e037ed546f75ff8034d03dfba/src/com/google/javascript/jscomp/deps/NodeModuleResolver.java#L38
so the easiest thing to do is pull that project, try fixing it, build and pulling that in as dep
What I’m still confused about / don’t understand is what our input to Closure should be once it supports .mjs.
I’d be surprised if npm
didn’t have support… .mjs
originates from the NPM project as far as I understand.
https://dev.clojure.org/jira/browse/CLJS-2617 Add events for significant compiler signals (compile finished, warnings, exceptions)
@dnolen Assuming I can add support for .mjs
to Closure, wouldn’t we still have to write all dependencies between .mjs
sources to cljs_deps.js
?
@jannis I don’t know what you’re talking about, cljs_deps.js
is automatically correct if all previous steps worked 🙂
Them being dropped as part of add-js-sources
(and them not being in :js-dependency-index
) is still wrong, I assume?
Ok, this lead me to check where Closure is used in the first place, and it’s in handle-js-modules
, which comes before add-js-sources
.
@jannis by all means understand the pipeline - just saying we can save you some debugging goose chases
@dnolen Captured draft content ideas for either an AOT cache guide or news post here: https://github.com/clojure/clojurescript-site/issues/183
@mfikes great, gonna need a socket REPL / pREPL one too but let’s worry about that later
I guess :aot-cache
doesn't need so much of a "guide" flavor, as it is a self-running feature.
I wonder if :cache-analysis
means "local cache, including source maps", and if so perhaps the global key name could be derived from that key name
@dnolen Nice, found out why those .mjs
files would result in ...$index-mjs
instead of ...$index
like .js
files. There’s code in Closure to strip the extension when generating the identifier. I should have looked at Closure earlier! 🙂
Has anyone seen this before when running lein with-profile +closure-snapshot test
against ClojureScript? java.lang.IllegalArgumentException: No matching ctor found for class com.google.javascript.jscomp.Es6RewriteModules
Looks like the new value is Nullable, so probably we can just pass in null
@bhauman https://dev.clojure.org/jira/browse/CLJS-2617, I think we should just copy the warning handler pattern, using compiler atom for events is not attractive to me
we could have *handlers*
dyn var, and bind this from compiler opts, and then in the compiler invoke for different event types
Yay, simple single .mjs file dependency still works, now with ...$iterall$index
instead of ...$iterall$index-mjs
.
because currently otherwise it's really hard to reliably bind warnings from inside the compiler thread
we should look for a more principled way to invert the relationship - but I’m not sure it’s possible
Interesting: goog.require("Require{symbol=module$Users$jannis$Work$oss$clojure$clojurescript$node_modules$graphql$graphql, rawText=./graphql, type=ES6_IMPORT}");
I guess the output of CompilerInput.getRequires
changed too.
@jannis symbol is the interesting part
and simply stamping the compile as finished in the compiler env shouldn't hurt the architecture or any racy builds
@jannis We probably can't apply these Closure fixes to Cljs master before next Closure release, but you can prepare issue with patch to be applied once we update Closure
@juhoteperi or we could finally start releasing Closure ourselves 🙂
I doubt there would be much benefit, they have lately released quite predictably once per month and they probably do some testing we would have to do ourselves
@bhauman while I think your simple figwheel thing is cool, I’m not really convinced that this is better in the end than just providing a repl-env
And based on previous release dates, there is good chance the march release coming soon
right but this is not a real problem 🙂 built-in browser / watcher is just for beginners, and experienced people who want to test something or do something simple
to me from a usability stand point what matters most here is semantics of the standard flags
I was envisioning the browser repl becoming more robust over time, the watcher as well, and core tools would really take over
that’s a possibility but I’m still convinced the innovation here shouldn’t be hampered by mainline dev
to me the lack of coordination around ClojureScript tooling has mostly been a good thing 🙂
it’s taken a long time to get ClojureScript core compiler stuff solid, and that probably isn’t going to change anytime soon
I'm bringing this up because it seems we're currently integrating some of those lessons back into the core. A figwheel like workflow has been a significant part of the growth of CLJS. So I'm kinda pushing to enable this without needing to compose over the compiler ... Of course I can easily continue to do that. But if the core of the Figwheel workflow is only a 200 line cljc file and it doesn't need to compose around the compiler, well that seems like an interesting trade off to me.
I agree it’s interesting, but probably on hold for now 🙂 that said a generic events handler thing still seems like a good idea, no reason to limit it to warning as it is now
@dnolen Do you know if anyone has tracked down this odd behavior with 1.10.x?
ios:cljs.user=> (def r (om/reconciler {:state {:a 1}}))
#'cljs.user/r
ios:cljs.user=> (om/reconciler? r)
false
I’m digging, but don’t want to waste time if already sorted.Confirmed fixed. And, the broadened scope on https://dev.clojure.org/jira/browse/CLJS-2616 is a good call as it allows a lein install
of non-snapshot JARs as well (thus enabling me to just lein install
master of om.next)
When I see them, I think I’m going to start adding comments to tickets like the one in https://dev.clojure.org/jira/browse/CLJS-2451 (unless there is some other precedent on how to handle these).
Funny I was wondering as well yesterday if a robust socket repl for node should be in core instead. Same train of thought of more robust tooling in core.
About prepl
, yesterday I did not have to time to get to it, I could write a post on new clj
+ socket repl so that folks start using it
@richiardiandrea yes that would be nice it should cover the new socket REPLs + pREPLs, feel free to take a run at that, I can help edit etc.
Cannot promise now at the beginning of the working week 😃 🤞
@richiardiandrea no rush, it would come after release post anyway
Ok cool, I can maybe sneak in some time on https://dev.clojure.org/jira/browse/CLJS-2613 today
I'm trying to concatenate all unoptimized JS files into one large JS file (same as closure-library/closure/bin/calcdeps.py), but having a hard time getting a hold of all the JS Sources in dependency order. Seems like this should be trivial, but can't seem to figure this out. Any pointers?
@alpeware is there a reason to not use the tools to do this? we don’t provide direct to accomplish this - you can root around the compiler and probably figure it out though
i'm trying to work around some memory constraints where i'm building. the closure compiler requires a lot of memory since it's pulling everything into a giant string apparently.
@alpeware hrm I don’t think I’ve seen that Closure uses a lot of memory except under advanced
So is this command wrong somehow?
clojure -Srepro -m cljs.main -co "$(cat cljsc_opts.edn)" -re node -c cli-repro.core -r
if not there is probably a regression, because it used to work
yep it is a regression, it was working at 04e55f88bf61006e0abd4e276eaf2297d91d40ce
I thought it was new, but it is not, it has been reported in https://dev.clojure.org/jira/browse/CLJS-2613
let me try one more time just to be sure
I am confused...seems fine now against master 😕
@dnolen I did the grunt work for https://dev.clojure.org/jira/browse/CLJS-2613, probably at this point only the fix is what's missing there. I am not sure how you want to handle it though so I am seeking advice