This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-12-02
Channels
- # adventofcode (5)
- # arachne (2)
- # bangalore-clj (1)
- # beginners (8)
- # boot (195)
- # cider (28)
- # cljs-dev (35)
- # cljsrn (4)
- # clojure (295)
- # clojure-brasil (5)
- # clojure-gamedev (2)
- # clojure-greece (2)
- # clojure-korea (13)
- # clojure-russia (60)
- # clojure-spec (58)
- # clojure-uk (92)
- # clojurescript (31)
- # clojurex (4)
- # css (1)
- # cursive (13)
- # datomic (40)
- # devcards (2)
- # emacs (17)
- # events (1)
- # flambo (3)
- # garden (9)
- # hoplon (31)
- # jobs (3)
- # klipse (1)
- # lein-figwheel (1)
- # london-clojurians (1)
- # luminus (2)
- # mount (36)
- # off-topic (13)
- # onyx (8)
- # pamela (1)
- # pedestal (1)
- # planck (3)
- # proto-repl (16)
- # protorepl (11)
- # re-frame (78)
- # reagent (4)
- # rethinkdb (6)
- # ring-swagger (1)
- # specter (8)
- # untangled (10)
- # vim (1)
are there clear expectations for the :file
key in an analysis cache def, and how this should relate to :var-special output? I’m seeing variations of absolute vs. relative paths, and extension vs. no extension, for different kinds of names in caches: https://gist.github.com/mhuebert/4e826ab01e6684ef1413b15ef9edc547
I’d like to dedupe to reduce cache size, but not sure what is necessary & canonical vs. what can be derived, & unsure of implications of eliminating some of this (eg. absolute file paths are not desired at all for analysis caches that are to be shared/distributed.)
@mhuebert I'm not sure if @dnolen would agree but I think the best way forward is by writing clojure.spec
s for everything that goes in there
there aren't many people using this data and so far there has not been any official API
@thheller ok. do you know where I would look to see which keys in a def
are actually used by cljs (internally) vs. which are there for programmers who might be using/inspecting the data later?
{:protocol-inline nil,
:meta {:file "cljs/spec.cljs",
:line 115,
:column 7,
:end-line 115,
:end-column 14,
:arglists (quote ([spec x])),
:doc "Given a spec and a value, returns :clojure.spec/invalid if value does not match spec,
else the (possibly destructured) value."},
:name cljs.spec/conform,
:variadic false,
:file "cljs/spec.cljs",
:end-column 14,
:method-params ([spec x]),
:protocol-impl nil,
:arglists-meta (nil nil),
:column 1,
:line 115,
:end-line 115,
:max-fixed-arity 2,
:fn-var true,
:arglists (quote ([spec x])),
:doc "Given a spec and a value, returns :clojure.spec/invalid if value does not match spec,
else the (possibly destructured) value."}
the path stuff of cljs.closure
is part of the reason I wrote shadow-build
to begin with 😛
hey, cool, I had not looked at shadow-build
. probably a bunch of overlap with what i’ve been trying to do with cljs-live
, bundling deps for self-hosted use
to me the :file
path like shadow-build outputs makes the most sense — :file "cljs/spec.cljs”
because that’s what you would search for in a classpath on whatever system you are on.
@mhuebert no idea why they differ. maybe one is the |(def thing)
while the other is (def |thing)
, ie. measuring start of form vs name of form
agreed on the paths, in shadow-build I normalize everything when they enter the build process
@thheller ah that must be correct, it accounts for the commonly seen 7 (for (defn
) and, eg. why core$macros/-> is 19 (you can count it out: https://github.com/clojure/clojurescript/blob/master/src/main/clojure/cljs/core.cljc#L104)
I think it would make sense to normalize to the beginning of the form rather than where the name appears
@mhuebert it is probably best if you open a CLJS Jira issue to track all the differences in the metadata
@bhauman fixed http://dev.clojure.org/jira/browse/CLJS-1718, foreign libs now placed on relative path instead of just at the top level of :output-dir