This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-06-30
Channels
- # aws (1)
- # bangalore-clj (1)
- # beginners (73)
- # boot (13)
- # cider (3)
- # clara (19)
- # cljs-dev (33)
- # cljsrn (37)
- # clojure (177)
- # clojure-dev (13)
- # clojure-gamedev (1)
- # clojure-italy (10)
- # clojure-nlp (1)
- # clojure-russia (1)
- # clojure-spec (64)
- # clojure-uk (128)
- # clojurescript (177)
- # core-async (23)
- # cursive (5)
- # datascript (13)
- # datomic (20)
- # devops (49)
- # emacs (13)
- # graphql (5)
- # hoplon (13)
- # keechma (1)
- # leiningen (3)
- # liberator (4)
- # lumo (2)
- # off-topic (11)
- # om (19)
- # om-next (3)
- # onyx (6)
- # re-frame (13)
- # reagent (14)
- # ring-swagger (7)
- # rum (2)
- # spacemacs (7)
- # unrepl (1)
- # untangled (23)
- # vim (8)
- # yada (1)
Patch attached to CLJS-2139—it would re-enable analysis diagnostics for defn
(and named fn
) bodies.
Glad it was just inadvertent suppression of warning diagnostics and that we didn’t need to give up the optimization. 🙂
@dnolen No. Assumed that they might be good for coverage. But if you'd like CI to complete more quickly, could decline that one.
@mfikes I just can’t think of a case where :simple
will tell you something more than :advanced
- though I suppose :simple
will give you more meaningful looking failures
@dnolen Right. I assumed there might have been a historical "coverage" rationale for script/test-simple
but I was wondering the same (whether things ever fail that way but not in :advanced
)
@mfikes pretty sure :simple
tests only exist to make it easy to understand :advanced
failures
An interesting perf observation: If I enable :optimize-constants
in Planck (which is self-host :none
) it works properly, but there is no effect on compilation speed (tested by require
of cljs.core.async
), but it causes an extra 200 ms (on top of 1200 ms) startup latency.
Hypothesis is that for this environment, allocation is cheap, while loading the full constants table is not. (This might also be applicable for React Native apps, where it seems devs are dispensing with :advanced
, but where launch latency is important).
@mfikes that seems like a good hypothesis. Lazy parsing may be involved, too: constants table would frustrate lazy parsing efforts
those 200ms would be parsing and creating the constants that were not needed at startup
I wonder if there's some other way to express the constants table that works better with lazy parsing
I'm taking a stab at https://dev.clojure.org/jira/browse/CLJS-2142 and instead of attempting to force the issue (allowing set!
on ^:const
Vars), I'm thinking of taking the approach that those kinds of Vars don't fall into the "instrumentable" set referenced in the docstring.