This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-01-10
Channels
- # adventofcode (3)
- # aws (2)
- # beginners (85)
- # boot (8)
- # boot-dev (4)
- # cider (36)
- # clara (3)
- # cljs-dev (87)
- # cljsrn (3)
- # clojure (87)
- # clojure-austin (12)
- # clojure-brasil (1)
- # clojure-dev (8)
- # clojure-dusseldorf (5)
- # clojure-estonia (5)
- # clojure-greece (4)
- # clojure-italy (3)
- # clojure-spec (17)
- # clojure-uk (55)
- # clojurescript (70)
- # core-logic (2)
- # cursive (6)
- # data-science (18)
- # datomic (13)
- # emacs (34)
- # fulcro (347)
- # graphql (12)
- # hoplon (6)
- # jobs (3)
- # jobs-discuss (43)
- # juxt (2)
- # keechma (31)
- # leiningen (29)
- # lumo (2)
- # midje (2)
- # off-topic (118)
- # om-next (4)
- # onyx (39)
- # pedestal (6)
- # re-frame (85)
- # reagent (21)
- # remote-jobs (3)
- # ring (5)
- # rum (2)
- # shadow-cljs (126)
- # spacemacs (1)
- # sql (6)
@juhoteperi looking over your closure update it looks like you ALWAYS access module$*
via ["default"]
? Is that not incorrect if the source is actually ES6 and not CJS?
@thheller at least if ES6 doesn't export default
say the ES6 does export { foo }
. (:require ["that-es6" :refer (foo)])
. would that not be incorrectly rewritten as module$that_es6["default"].foo
?
This changes aim would be to get Closure working like before, so I guess it should only emit ["default"] for CJS and not for ES6 at all?
Then ES6 default can be implemented later
my guess is that it now fixes CJS but breaks ES6 but I might be wrong. only looked over your patch, did not test it yet
Problem with checking the module-type is same as with checking :js-module-index
; the var name at emit* is the full module$
name and it is inconvenient to find information using that
Maybe... form
has the used namespace/name from code, and maybe compiler env has the require information from alias/refer to "pretty" module-name mapping
I still think that https://dev.clojure.org/jira/browse/CLJS-2376 is the solution we should go for. fixes every issue.
Yes, but it is separate
and should be easyish to implement once this is done properly
But currently the harder part is to get the information from Closure to Cljs compiler emit*
Hmm, but maybe we could use that :refer default :rename {default ...}
even for CJS
though that doesn't work for :as
no that exists, but some-ns
is not available in emit*
should be either (name n)
or (namespace n)
? eg. js/module$foo$bar
or module$foo$bar/thing
?
hmm, currently we don't have any mapping from module$...
to any information
:js-module-index
has e.g. lodash/array
-> module$path$lodash$array
mapping
I guess we could add new mapping to compiler env with module$
name to module-type (and maybe other information)
ah ok, I have that info in shadow-cljs available already. it is pretty useful at times
@juhoteperi we definitely want that, we worked around missing that several times already
I'll work on that today
Hm, we are probably missing any ES6 module tests now, I should probably add one
Do we have any tests where the compiled JS is ran on some JS engine to validate it works? Or is it best to just assert the output looks correct
@juhoteperi we don’t have a way to test that code works, though I want to fix that in this release by providing a Nashorn runner
and one more JS import
hack, they just keep coming. 😛 https://twitter.com/_developit/status/951122721429213184
It looks like a directly reducible tree-seq
is within reach, so long as perf benchmarks pan out. 🙂
Initial patch added for comment to: https://dev.clojure.org/jira/browse/CLJS-2464
this seems bad for the same reasons as your line-seq idea
because you’re relying on seqs with potential side effects
right, so the same issues as iterate
except iterate
gets around it by requiring f
to be side-effect free?
Right, @alexmiller. So tree-seq
is fundamentally a different beast than iterate
?
the set of things that we made reducible in Clojure was intentionally very narrow - range, cycle, repeat all deal with values. iterate leans on the side-effect free constraint for f
collections are concrete and immutable
FWIW, it looks like it would be great for Clojure https://gist.github.com/mfikes/cc1d1fac47e7dc112b0b9f4e3de11eae
yes, but it would also allow you to do things that break expectations
if you reduce over the tree-seq and then use it as a seq you are re-computing any non-concrete seq inside the tree
So, in short, if tree-seq
’s docstring included the caveat that branch?
and children
“must be free of side-effects”, then this would be worth exploring. But, alas, no.
yeah, it’s not something that can be applied generally to other seq functions
unless you constrain other dimensions
that would also limit its utility so tradeoffs either way
seqs cache and are immutable - that is both a pro and a con
Should ./script/test
pass on master?
Failing for me on master and r1.9.946. It should be enough to run build and bootstraap before test script?
I have now module-type read from Closure and added to new property on compiler-env (naming this property is maybe the hardest part...) and emit* is now checking that information and adding ["default"]
only to CommonJS modules
Unfortunately looks like Closure will return proper module-type only for npm modules
Does anyone know ES6 npm packages I could use for testing? It seems to be quite hard to find one
found lodash-es
Aha, even ES6 files from npm packages get module-type NONE
@juhoteperi With respect to script/test
passing, I’ve been running the tests continually, and it passes in CI https://github.com/mfikes/clojurescript/commits/master
although your switched to es5 as the default right? then I think you are supposed to emit .default
instead
Closure uses ["default"]
in the processed modules
and you don’t run into situations where sometimes .default
is used (by the GCC) and sometimes ["default"]
by CLJS
thought I saw it generate a .default
before but just might be remembering that wrong
@thheller Maybe it was Cljs compiler? Or maybe they changed something.
In the :default issue you mention that :refer :rename would already work, but wouldn't default
have been rewritten to default$
?
Or did you use language-out es5? Then it wouldn't be renamed?
I work arround the default$
is in other ways. also don’t use the closure compiler to process node_modules
so don’t really have any of the issues you are working through currently
(:require ["lodash-es/takeRight" :default take-right])
(take-right #js [1 2])
module$home$juho$Source$clojurescript$node_modules$lodash_es$takeRight["default"]([(1),(2)]);
implemention change is +4/-1 lines plus error message changes
https://github.com/Deraen/clojurescript/commit/db622472bc6f8e2a6da7f72dca03af207f505bbd I guess this at least needs better name for compiler env prop that :js-module-index-2
:default commit here: https://github.com/Deraen/clojurescript/commit/9b53bf5d957673281c5edc4c851c6566fecb1713 (in fact also requires require spec validation change)
ana/js-module-exists?
can be rewritten to use the new compiler env prop, but I'll leave that to separate change