This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-01-12
Channels
- # arachne (1)
- # aws (2)
- # beginners (123)
- # boot (22)
- # boot-dev (8)
- # chestnut (3)
- # cider (38)
- # clara (36)
- # cljs-dev (148)
- # clojars (2)
- # clojure (76)
- # clojure-austin (2)
- # clojure-greece (1)
- # clojure-italy (6)
- # clojure-russia (5)
- # clojure-spec (8)
- # clojure-uk (65)
- # clojurescript (45)
- # core-async (38)
- # cursive (9)
- # data-science (5)
- # datomic (28)
- # docs (1)
- # emacs (2)
- # fulcro (34)
- # hoplon (18)
- # jobs-discuss (7)
- # keechma (8)
- # lumo (5)
- # om (3)
- # onyx (31)
- # parinfer (1)
- # pedestal (1)
- # re-frame (20)
- # reagent (5)
- # ring-swagger (16)
- # shadow-cljs (56)
- # spacemacs (11)
- # specter (8)
- # sql (5)
- # unrepl (29)
- # yada (6)
I got the test script working, I had to remove lib/
which had some old jars, which bootstrap script didn't replace or remove
Btw. deps between bootstrap script, project.clj and pom.template.xml don't match. Bootstrap uses Clj 1.9.0-alpha17, project.clj 1.9.0, pom 1.8.0. Pom is also missing core-specs-alpha dependency.
fyi, clojure 1.9 depends on core.specs.alpha, so you will get that transitively if depending on 1.9
perhaps tools.deps
is a good way to unify all these ^
in a single place
Not sure if it will help with pom.xml? But yes, will probably help with bootstrap and lein
@juhoteperi If you have a deps.edn
you can generate a pom.xml
using clojure -Spom
Lein could generate pom.xml also, I think there is some reason why clojurescript uses separate file
(Here is the ClojureScript deps.edn
I was messing with. https://gist.github.com/mfikes/9485eaded14ae100e1174586446aeb3d)
I think the pom.template.xml is the master for Cljs currently
(The only testing I did with that was to see if I could depend on ClojureScript from another project that also uses deps.edn
.)
So it will require plugins etc. for builds
@dnolen If you apply patches today, I think the Closure update patch is OK now: https://dev.clojure.org/jira/secure/attachment/17621/CLJS-2389-5.patch
@dnolen I can provide patches for any of my last few tickets, just let me know if you're interested and I'll produce them. The chunking for small vectors + faster reduce for them will likely make a lot of code faster.
@juhoteperi ok thanks
@rauh patches welcome, though I probably won’t get a chance to look at those particular ones today
@dnolen Sounds good, just to summarize: 1. Add -reduce
for ChunkedCons
2. Make seq-reduce
check for chunked
3. Add IChunkedSeq
for IndexedSeq
. All three ok?
@rauh do these changes parallel what’s be done in Clojure? that should be in the ticket - whether this is novel work
Benchmarks are already included, about 4x-5x faster for the chunking and 5-10x faster for seq-reduce. The seq-reduce is already done in Clojure, not sure if there has ever been a ticket for it. The chunking was also never done in Clojure since (seq [1 2 3])
has always returned a ChunkedCons in Clojure.
Though, the approach would a different one to Clojure: I think making IndexedSeq a chunk makes sense since we (in CLJS) use IndexedSeq a lot more than Clojure
Eg: (apply (fn [& a] (type a)) [1 2 3 4 8])
returns ChunkedCons in Clojure but IndexedSeq in CLJS.
2. Is also done in Clojure. But that's the only trickier part where I'd like a review. Need to be careful to not end up blowing the stack
@juhoteperi did you run ./script/test
?
I only had JSC installed but that passed tests
Oh didn't notice that
maybe related to this ERROR: JSC_JSON_UNEXPECTED_TOKEN. Unexpected JSON token at /home/juho/Source/clojurescript/node_modules/lodash/package.json line (unknown line) : (unknown column) ERROR: JSC_PARSE_ERROR. Parse error. Semi-colon expected at /home/juho/Source/clojurescript/node_modules/lodash/package.json line 2 : 9
Closure should have rewritten those references
Yeah I see
Closure processing doesn't work with cljsc
oops, I have two Closure compiler jars on lib/
Yes, second time I missed this
Huh still doesn't pass. I remember seeing the successful output.. hm
lein test :only cljs.build-api-tests/test-npm-deps
cat /tmp/npm-deps-test-out/node_modules/lodash/toLength.js
using lein test the processing works
what can cause the difference with cljsc?
Yes
@juhoteperi seems to me there’s probably just a bug with the patch
Yes, but I don't understand what difference causes with lein and test script
But how can I look for the bug when it works already using lein
Do you see the error about Error: Can't resolve './calculator_amd'
?
@juhoteperi when calling ./script/test
, convert-js-modules
is never called, this doesn’t seem right
It is called for me
How are you testing? Println? Output is redirected to the file
Closure parse error about lodash package.json stops the Closure processing for me
We should throw exception in report-failure if there was errors, output will be broken in that case
@juhoteperi ah so the issue is that we’re blindly processing package.json
as JS
we need it as an input of course for Node resolution, but we shouldn’t be trying to process it
Hmph, no, Closure should be able to process it
Because requiring package.json to read the package information works in CJS
@juhoteperi yeah I’m not sure I believe Closure will process these inputs or should
exports.version = require('./package.json').version;
And Closure also needs to read the package.json again for dependencies
Our package information is only used to select which files to pass into Closure
They do the same again
(They read the main property information from package.json files at least)
And there is a pass to rewrite them into JS modules, which is called during parse
@juhoteperi so then what step are we missing?
I have Lodash processing working in another env so I'm still thinking there is some difference with bootstrap or test script
Bootstrap uses different Closure jar so I wonder how that is different
maybe this is a good excuse to try deps.edn
, the bootstrap script is just a pile of workarounds for grabbing the Maven deps we need and managing the classpath
lurker +1
Perhaps the effort put into making deps.edn
work would pay for itself in terms of making it easier for community members to try MASTER without even (manually) cloning it.
I suppose to really reach that nirvana, end users would need to be using deps.edn
themselves…
I mean… the description on this page becomes almost nothing: https://clojurescript.org/community/building
@alexmiller the basic deps.edn docs don’t cover what to do if your source paths aren’t under src
?
I thought so https://gist.github.com/mfikes/9485eaded14ae100e1174586446aeb3d#file-deps-edn-L2
^^ does that answer your question?
@alexmiller yes thanks!
@alexmiller clj -R:test bin/cljsc.clj "..."
this is really a clojure.main question - I think you have to use -m if you want to invoke -main with args
using a script will just load and eval the script
does cljsc.clj have a -main?
then I don’t think that will work
@alexmiller the error is a bit cryptic
Exception in thread "main" java.io.FileNotFoundException: {:optimizations :advanced ...
@dnolen I have a similar script that uses *command-line-args*
successfully https://github.com/mfikes/coal-mine/blob/master/script/build#L4
I can’t repro what you are seeing @dnolen
$ cat foo.clj
(prn *command-line-args*)
$ clj foo.clj 1 2 3
("1" "2" "3")
yeah, looking at the code it seems like command-line-args should be set when using the script
if I add (prn *command-line-args*)
to the top of bin/cljsc.clj I see the args passed with clj bin/cljsc.clj 1 2
if your “…” is multiple options with spaces between then maybe that bash quoting is failing you
(or maybe clj itself is deficient in that regard, but I’m pretty sure it is ok)
now hitting other issues, but @juhoteperi no change, so it doesn’t look like it has anything to do with the Closure Compiler dep
@alexmiller clj
wouldn’t affect picking up data_readers.cljc
files right?
only insofar as it affects your classpath
clj -Spath will dump your classpath if that helps
@alexmiller any reason clj -R:test -Spath
isn’t showing my :test
alias extra paths?
because you need -C:test
-R affects resolve-deps, -C affects building the classpath. there is a ticket to merge these and we may do that.
@juhoteperi yeah I got tests running via clj
and there is no change, so the fact that this is somehow working under lein isn’t telling us much
@alexmiller right makes sense, I just didn’t understand the distinction
I'll continue looking into this and will report when I find the fix