This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-06-03
Channels
- # admin-announcements (2)
- # alda (4)
- # beginners (15)
- # boot (89)
- # cljs-dev (88)
- # cljsrn (75)
- # clojure (149)
- # clojure-belgium (16)
- # clojure-france (2)
- # clojure-greece (6)
- # clojure-russia (108)
- # clojure-spec (39)
- # clojure-taiwan (3)
- # clojure-uk (7)
- # clojurescript (70)
- # css (3)
- # cursive (17)
- # data-science (2)
- # datascript (7)
- # datomic (41)
- # dirac (3)
- # hoplon (12)
- # instaparse (1)
- # juxt (3)
- # lambdaisland (9)
- # mount (4)
- # off-topic (6)
- # om (71)
- # om-next (4)
- # onyx (22)
- # other-languages (56)
- # perun (15)
- # proton (6)
- # re-frame (32)
- # reagent (42)
- # specter (34)
- # spirituality-ethics (7)
- # tmp-json-parsing (5)
- # untangled (13)
- # vim (4)
- # yada (6)
@dnolen: multi-arity returning vars looks cut-n-dry to fix. Attaching a patch to CLJS-1611.
I'm experimenting a little bit with commonjs -> google closure modules transformations (documented in https://github.com/clojure/clojurescript/wiki/Compiler-Options#foreign-libs) and it works correctly from cljs.build.api/build but when I put the same in the deps.cljs
it raises a internal compiler error. Is that expected?
Absolutly the same :foreign-libs
in the build compiler api works as expected and if I put it into deps.cljs raises a internal compiler exception...
@niwinz: I would expect that transformations would work with upstream foreign deps (I’ve never heard of such a limitation).
I'm also surprised, but I can't use the deps.cljs
approach for expose a commonjs module using :module-type :commonjs
@niwinz: Important bit is to not make a project based on lein
or boot
but instead with the shipping JAR.
Sweet! Transit for compiler metadata cache is great. (And it’s definitely reliable for this use—Replete’s been using it for 11 months, Planck 6 months, zero issues, extremely fast.)
@mfikes: yeah looking forward to wrapping this up, it should be very big boost to REPL start up time
@dnolen: Based on your suggestion yesterday about using a js array in cljs.reader
for creating the collections instead of using apply
, I’ve created a Jira ticket for it. It includes a patch and some benchmarks - http://dev.clojure.org/jira/browse/CLJS-1665
@dnolen: Thanks. one change i’d like to make is to create an .fromArray
function for a List
like all other collection types. I haven’t done that as I wanted to keep this patch just to cljs.reader
.
@dnolen: looking at the core library, I noticed that there a lot of functions exposed to the user which are not in the official API and are not documented per se. Should they be marked as something like “internal use only”?
@dnolen: did you mention a while back that we might add a :signature like key in here
https://github.com/clojure/clojurescript/blob/master/src/main/clojure/cljs/compiler.cljc#L1160
David I get a weird warning while upgrading to 1.9.0-alpha4
+ 1.9.14
:
WARNING: Use of undeclared Var cljs.analyzer/_ at line 2366 /.../git/cljs-repl-web/irc/-5y5vor/main.out/cljs/analyzer.cljc
I don't have a minimal repro repo at the moment, if you need it I can produce it@richiardiandrea: that’s fixed in master
https://github.com/clojure/clojurescript/commit/f38cda652699bf44d673f577137e181d8e20ec5d
thanks @anmonteiro sorry for the noise then
@dnolen: 👍 I tried master on our Figwheel-based setup and it works, with .cache.json
files appearing. No noticeable speedup (it was already compiling in about 3 seconds, so perhaps not enough volume of code to matter.)
Yes, the first compile is on the order of 20–30 seconds. Subsequent launches involve a compile of about 3 seconds.
(I’m thinking that perhaps this just isn’t a large enough project to benefit from the Transit conversion.)
in my case is the same, the compile time is so high that I cannot see the difference in launching the repl (but good that it is there!)
(I’m not actively using Figwheel all of the time, so I’m probably not the best to offer feedback other than a simple “smoke test” that it didn’t horribly break. 🙂 )
confirm that the warning went away with 1.9.36
, going back to the performance topic, http://clojurescript.io compiles in:
real 1m57.961s
user 2m49.489s
sys 0m2.619s
with :parallel-build
on@richiardiandrea: thanks for the confirm
Has this been reported yet?
ERROR: Not supported: class clojure.lang.Var at file src/path/to/file.cljc
data: {:file “src/path/to/file.cljc", :from :boot-cljs}
adzerk.boot_cljs.util.proxy$java.lang.Throwable$ff19274a: java.lang.Exception: Not supported: class clojure.lang.Var
adzerk.boot_cljs.util.proxy$java.lang.Throwable$ff19274a: Not supported: class clojure.lang.Var
This is using transit-clj and latest cljs. I can reproduce with the following code in a cljc file
(def foo "foo")
#?(:clj (defmacro bar [] (:name (meta (var foo)))))
(def bazz (bar))
@jr: Can you reproduce this without boot-cljs?
Yeah, doesn't look like something boot-cljs would cause, but as it mangles the exceptions it is a bit harder to debug the problem
Did you change the file path? 😄
so in replumb the only failing test is with the form: (find-doc "[^(]newline[^s*]")
, I need to investigate
it does not return the doc we were expecting
maybe the new 1.9 version got rid of some of the -newline
functions
I’ll come up with a minimal project to reproduce. In the mean time here is the full stack trace, which indicates (to me) that something about emitting a serialized var is broken https://gist.github.com/JacobNinja/30a42ee9d4517190acfe95e2d21ab4a9
false alarm on my side, silly difference in the output
@jr or that just looks like bad code that never should have worked and you just got lucky
@jr still I agree that there is a problem here - you need to be able to disable transit encoding if necessary
fwiw, the breaking code is similar to this, which imports vars from another namespace https://github.com/ztellman/potemkin/blob/master/src/potemkin/namespaces.clj#L11
Is transit supposed to emit EDN for analysis? Seems like it is emitting JSON based on the stacktrace
just forgot to say that all the tests now pass in replumb with cljs 1.9.36, thanks David!