This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-11-15
Channels
- # announcements (11)
- # beginners (66)
- # boot (6)
- # clara (25)
- # cljdoc (4)
- # cljs-dev (22)
- # clojure (261)
- # clojure-dev (1)
- # clojure-europe (2)
- # clojure-italy (15)
- # clojure-losangeles (1)
- # clojure-nl (19)
- # clojure-spec (62)
- # clojure-uk (50)
- # clojurescript (12)
- # community-development (6)
- # cursive (60)
- # datomic (21)
- # emacs (2)
- # figwheel (2)
- # figwheel-main (3)
- # fulcro (2)
- # graphql (11)
- # hyperfiddle (11)
- # javascript (1)
- # jobs (6)
- # juxt (1)
- # kaocha (5)
- # keechma (2)
- # off-topic (4)
- # onyx (10)
- # pathom (7)
- # re-frame (15)
- # reagent (8)
- # remote-jobs (2)
- # ring-swagger (14)
- # shadow-cljs (35)
- # sql (22)
- # testing (9)
- # tools-deps (62)
- # vim (12)
Hmm, I'll try and work up a minimal repro case
Does ClojureScript run the test suite on Windows?
@danielcompton Yes, but a subset. https://github.com/mfikes/clojurescript/blob/master/appveyor.yml
I enabled :parallel-build
and :aot-cache
in a Windows CI run and it passed. This doesn't prove anything, really. Was hoping for an easy repro. https://ci.appveyor.com/project/mfikes/clojurescript/builds/20313492
Yeah I think it's a tricky set of dependencies in a large project that will trigger it. Will try and work up a minimal case
hey folks, empty
function returns nil for strings on clojure but raise an exception on cljs. is it intentional ?
I think that’s a possible enhancement for unification with JVM clojure. The docstring says it will return nil otherwise. e.g. (empty 1)
also returns nil
, while cljs throws.
Seems reasonable to me. Rationale in https://dev.clojure.org/jira/browse/CLJS-2974
📣 hey core team, finally trying to categorize everything in cljs.core api docs—lemme know if I’m surfacing anything that shouldn’t be used or whatever: 📖 http://cljs.github.io/api/#cljs.core
Good call! We can add this more complex logic while speeding things up for SpiderMonkey.
For (empty [1 2 3])
speedups with that approach:
V8: 0.83
SpiderMonkey: 1.81
JavaScriptCore: 1.03
Nashorn: 1.16
ChakraCore: 0.98
GraalVM: 1.33
xposting from #clojurescript:
has anyone looked into the performance of add-watch
? I'm trying to vet it against using a general JS event emitter/observable. wondering if someone's already done the due-diligence
@lilactown no specific work has been done on add-watch
but also no one has complain about it
makes sense. I know that, for instance, reagent implemented their own way of managing subscriptions to their own special atoms. I had this notion it was partially for perf reasons and was just wondering if a comparison already existed
I’m not an expert on it, but I think Reagent atoms add some additional semantics where they do something funky simply when dereferenced, something that regular atoms don’t do (even when you have a watch on it)
@lilactown Looking at the source for add-watch
, it's just making use of the IWatchable
protocol, so performance is going to depend on the thing you're watching rather than add-watch itself
@mfikes yeah, derefing them also adds a subscription to their changes that does some magic to reactively kick off another render cycle for components that have deref'd it https://github.com/reagent-project/reagent/blob/master/src/reagent/ratom.cljs#L142-L145