This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-03-02
Channels
- # aleph (6)
- # beginners (57)
- # boot (1)
- # cider (27)
- # clara (23)
- # cljs-dev (166)
- # clojure (287)
- # clojure-dev (23)
- # clojure-greece (1)
- # clojure-italy (2)
- # clojure-russia (13)
- # clojure-spec (34)
- # clojure-uk (36)
- # clojurescript (68)
- # core-async (63)
- # core-logic (1)
- # cursive (1)
- # data-science (1)
- # datomic (26)
- # duct (1)
- # emacs (10)
- # figwheel (8)
- # fulcro (2)
- # garden (16)
- # graphql (8)
- # hoplon (20)
- # jobs (2)
- # leiningen (10)
- # off-topic (16)
- # onyx (2)
- # portkey (5)
- # quil (1)
- # re-frame (63)
- # reagent (95)
- # reitit (6)
- # remote-jobs (1)
- # ring (6)
- # rum (1)
- # shadow-cljs (76)
- # spacemacs (26)
- # specter (11)
- # sql (7)
- # unrepl (68)
- # vim (2)
- # yada (2)
@dnolen At the bottom of out\cljs\core.js
is
//# sourceMappingURL=core.js.map
if that’s what you are asking.
It appears that this may not be a regression introduced with cljs.main
: https://github.com/google/closure-compiler/issues/2611#issuecomment-345595935Good news is that all of the examples in the "`cljs.main` tour" news post work properly on Windows, apart from the issue encountered in CLJS-2588.
About the Windows thing, I wonder if this affects all attempts to use Closure on Windows. (I’m gonna see if I can come up with some slight variation so that this portion of the “tour” works on Windows.)
@dnolen FWIW, if you (.setResolveSourceMapAnnotations compiler-options false)
things compile
I don’t think so we only generate source maps for our own stuff & we handle that completely
Closure generates one of course when compiled, but we just merge that with our own thing
I wonder if this actually implies nobody uses ClojureScript on Windows for :advanced
Hrm.
Here is what I see after your patch:
C:\Users\mfikes>cd out\cljs
C:\Users\mfikes\out\cljs>dir
Volume in drive C has no label.
Volume Serial Number is 483F-8B01
Directory of C:\Users\mfikes\out\cljs
03/01/18 02:21 PM <DIR> .
03/01/18 02:21 PM <DIR> ..
03/01/18 09:36 PM 329,933 core.cljs
03/01/18 09:36 PM 1,276,371 core.js
02/28/18 10:07 AM 665,773 core.js.map
03/01/18 09:36 PM 1,088 nodejs.cljs
03/01/18 09:36 PM 1,001 nodejscli.cljs
03/01/18 01:30 PM 127,865 pprint.cljs
03/01/18 08:12 AM 154,429 pprint.cljs.cache.json
03/01/18 01:30 PM 493,716 pprint.js
02/28/18 10:07 AM 179,817 pprint.js.map
03/01/18 01:30 PM 2,154 repl.cljs
02/28/18 10:10 AM 1,265 repl.cljs.cache.json
03/01/18 01:30 PM 11,562 repl.js
02/28/18 10:07 AM 5,055 repl.js.map
02/28/18 10:07 AM <DIR> spec
13 File(s) 3,250,029 bytes
3 Dir(s) 20,814,352,384 bytes free
@mfikes actually I’m going to revert that for now /C:/Users/mfikes/out/cljs/core.js
shouldn’t those be backslashes in the name?
Not that this implies it is valid, but here is an interesting test done on that box:
user=> (io/file "/C:/Users/mfikes/out/cljs/core.js")
#object[java.io.File 0x53de625d "C:\\Users\\mfikes\\out\\cljs\\core.js"]
user=> (count (slurp *1))
1276371
@dnolen I can no longer reproduce CLJS-2588 as originally written, and made a comment showing the exact steps I took attempting to reproduce it https://dev.clojure.org/jira/browse/CLJS-2588?focusedCommentId=48452&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-48452 I’ll close it as “Not Reproducible” for now. Without the ability to reproduce the issue, it is not clear to me how to even work on a fix.
@dnolen I was pondering writing a separate suite of tests (maybe script/test-cli
) that essentially drives the CLI through its paces using clojure.java.shell/sh
, setting up each test in a temp dir (maybe via some appropriate use of (File/createTempFile)
), setting up src
in there, etc, and ultimately looking at :out
to see if -e
or other output prints correctly. These tests would be slow (and thus separate). I'm thinking the script can take as args what would go to -re
, and perhaps optional -ro
EDN. That way we could cause it to drive things with -re node
and -re nashorn
in CI, etc.
I was also thinking that, if we add an additional browser REPL env flag (along the lines of the :launch-browser
just proposed) to make it be "silent", to optionally turn off these lines
Compiling client js ...
Serving HTTP on localhost port 9000
Listening for browser REPL connect ...
and with that we could do something like script/test-cli browser '{:silent true}
` and at least run all of these tests manually letting it launch browsers on our desktop.
Of course you could also do script/test-cli ambly '{:choose-first-discovered true}
as an example to drive a downstream REPL.
Sorry for the wall of text, but just sharing in case there could be improvements to a way to test this. Probably won't start right away.@mfikes so I’m thinking we should change the Quick Start to show two paths, Windows is uberjar, but Linux / OS X is clj
@jannis re: https://dev.clojure.org/jira/browse/CLJS-2592, have you looked at https://github.com/cljs-oss/module-deps/blob/master/index.js
It’s also likely @anmonteiro can provide some insight here as to why .mjs
isn’t picked up by this
@jannis your Clojure patch will only fix the issue at the top level - but in order to get all deps for top level stuff you need to make sure the cljs-oss fork of module-deps is working correctly
Still working out how I can get e.g. graphql to work, which uses .mjs
all over the place (and also has CommonJS .js
files in parallel to .mjs
…).
The current patch will only add index.mjs
to the index but won’t include all other .mjs
files (it’ll pick the .js
ones instead), which is not going to work.
I haven’t even looked at @cljs-oss/module-deps
yet. So far I’m trying to get the .mjs
files to get indexed properly.
So far I’ve only looked at module_deps.js
in the CLJS source tree. There’s some .js
-extension-only logic in there, but changing that may indeed not be enough.
I was playing round with the clj -m cljs.main
for compiling stuff and it looks like om.next isn't being compiled correctly in these newer 1.10.* releases of clojurescript.
The failing case is:
clj -Sdeps "{:deps {org.clojure/clojurescript {:mvn/version \"1.10.63\"}
org.omcljs/om {:mvn/version \"1.0.0-beta1\"}}}" \
-m cljs.main \
-re node \
-e "(require '[om.next :as om])
(def c (om/reconciler {:state {}}))
(prn (type c))
;; Should return true but doesnt...
(prn (om/reconciler? c))
"
@tmulvaney need more information than “isn’t being compiled correctly”
Sure. So it compiles and runs with out any issues, but (om/reconciler? (om/reconciler {:state {}}))
doesn't return true
@tmulvaney seems like you could easily launch a browser REPL to see what’s going on in the debugger
Digging a little deeper (implements? om.next.protocols/IReconciler (om/reconciler {:state {}}))
is returning false as well. I started digging into this as the om app wouldn't mount and it was complaining about the reconciler not being a reconciler. The example I pasted is the minimal case i could produce.
@tmulvaney yeah I think it’s an om.next bug
@dnolen @jannis if I had to guess we need to add that extension here https://github.com/clojure/clojurescript/blob/master/src/main/cljs/cljs/module_deps.js#L67
@tmulvaney line 299 in om.next, hardcoded to 1.9
This is definitely a massive step in the right direction just from bug reporting standpoint
@anmonteiro That improves things a little. It changes all the indexing entries from
:file "/Users/jannis/Work/oss/clojure/clojurescript/node_modules/graphql/subscription/index.js",
to
:file "/Users/jannis/Work/oss/clojure/clojurescript/node_modules/graphql/subscription/index.mjs",
which is correct. What it doesn’t solve yet is that there is only a single addDependency
entry for the whole graphql
package in out/cljs_deps.js
:
goog.addDependency("../node_modules/graphql/index.mjs", ['module$Users$jannis$Work$oss$jannis$cljs_npm_deps_mjs_issue$node_modules$graphql$index_mjs'], ['module$Users$jannis$Work$oss$jannis$cljs_npm_deps_mjs_issue$node_modules$graphql$graphql', 'module$Users$jannis$Work$oss$jannis$cljs_npm_deps_mjs_issue$node_modules$graphql$execution', 'module$Users$jannis$Work$oss$jannis$cljs_npm_deps_mjs_issue$node_modules$graphql$subscription', 'module$Users$jannis$Work$oss$jannis$cljs_npm_deps_mjs_issue$node_modules$graphql$error']);
is that not correct?
should there be more entries?
@jannis did you add .mjs
in both extensions
and moduleExtensions
?
(I’m not sure what moduleExtensions
does though)
The last vector is dependencies, isn’t it? So at runtime, if there’s no entry for e.g. ...$graphql$graphql
, you’ll get this error in the browser: base.js:1357 Uncaught Error: Undefined nameToPath for module$Users$jannis$Work$oss$jannis$cljs_npm_deps_mjs_issue$node_modules$graphql$graphql
.
I think the indexing may be correct now but what happens between indexing and writing the dependencies to out/cljs_deps.js
is broken.
@jannis are you targeting the browser or nodejs?
@anmonteiro adding ‘.mjs’ to moduleExtensions
doesn’t fix it but it might not hurt to add it there anyway.
@tmulvaney great! no worries
AOT ClojureScript JAR is the default of this commit https://github.com/clojure/clojurescript/commit/8971829275b466280a0b8fc85886e3fa7d353a13
Integration tests for cljs.main
came out fairly readable. Could probably be improved more, but I don't want to over-engineer it for now.
Small example is
(deftest eval-test
(-> (cljs-main "-e" 3 "-e" nil "-e" 4)
(output-is 3 4)))
I have a few other initial tests in there, all the way up to compiling an optimized build for Node:
https://github.com/mfikes/clojurescript/blob/69f2751f38b5b898dcda379f19ad9950b658970a/src/test/cljs_cli/cljs_cli/test.clj
Patch forthcoming shortly.
(I think they also already caught a browser REPL bug, which I'll put together a minimal repro for and file a ticket.)@jannis you may have to mess with cljs.js-deps
@jannis would be interesting to know at which point the dependencies become missing
I would guess add-js-sources
(-> ... (doto clojure.pprint/pprint) ...)
is your friend here
I so want to be able to just require graphql (and Apollo) in ClojureScript via :npm-deps. That's my goal. :)
master global caches JAR deps now, definitely a huge performance boost - not configurable (only really interested in supporting disabling if anything)
also testing that cljs.main
works, and that you see caching behavior if you blow away out
should I just try building using the latest commit? what am I looking for?
cool will do
@bhauman @dnolen I took a stab at reducing the copy in the default browser REPL page. Here is a shorter version. I'm not sure how it sits with me, but leaving it here for impressions.
that’s nice and to the point for me, but I’m not feeling particular about it, so more feedback welcome
It might be too terse or curt compared to the previous one, which was a bit more warm and welcoming.
Maybe working the word "Welcome" in the beginning would do it... will ponder some more.
Wow, @dnolen the caching is awesomely faster! (Trying core.async
after blowing away out
is very fast.)
compiles fine my lambda project here, one suggestion...why not using $HOME/.clojure
as base dir? have you considered that?
@richiardiandrea conflicts
Ahh @dnolen I was wrong. (I have bugs in my testing process.) I was using node and failing to blow away .cljs_node_repl
. Regardless, I'm only seeing cljs
files under ~/.cljs/.aot_cache/
this global caching is nice and could by reused by self-host compilers as well I guess
@richiardiandrea My thought: Feel free to read from it, but I wouldn't write anything produced by the self-hosted compiler into it.
no write
but i see now another thing, only .cljs
files are cached here, no analysis cache, so i am off topic 😄
trying
I see them all now 👍
And .m2/repository/org/clojure/clojurescript/1.10.101/clojurescript-1.10.101.jar
is AOTd 🙂
quite an improvement
Here are my timings: https://gist.github.com/mfikes/9bd2365519f48f62f469b57b1bdee6ce
second time works because it’s in out, but not the first time when we copy from the cache into out
@dnolen It appears to not put stuff derived from JARs in the global cache if ClojureScript itself is not a built dep (if it is :local/root
or a git dep.) That seems like the right thing to do, but I don't yet see the code that prevents this.
I updated the Bocko gist, which depends on actual Bocko JARs to point to the latest ClojureScript. https://gist.github.com/mfikes/e00202b2de7cc2352fedcf92b1fe60dc
Ahh, I was mistaken: Global caching works if ClojureScript is not a built dep. The gist above result in:
.cljs/.aot_cache/0.0.90964463958/BF21A9E/bocko/core.cljc
.cljs/.aot_cache/0.0.90964463958/BF21A9E/bocko/core.cljc.cache.edn
.cljs/.aot_cache/0.0.90964463958/BF21A9E/bocko/core.js
.cljs/.aot_cache/0.0.90964463958/BF21A9E/bocko/core.js.map
This might be a bug. If I remove out
I see what looks like evidence that it is copying a compiled artifact from the cache, but then also compiling
Copying cached /Users/mfikes/.cljs/.aot_cache/0.0.90964463958/BF21A9E/bocko/core.js to out/bocko/core.js
Compiling out/bocko/core.cljc to out/bocko/core.js
Another tougher problem to solve (which Maven itself never solved for a long time...) is if you have two different projects compiling at the same time, potentially corrupting caches.
I guess one solution is to write all of the files for something (like those 4 bocko files above) into a temp dir, and then to swap the directory in place with one atomic operation via a filesystem move call
I confirm the REPL thing happens the first time, the socket repl in particular seems to hang completely