Fork me on GitHub
#cljs-dev
<
2016-12-02
>
mhuebert08:12:38

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.)

thheller09:12:23

@mhuebert I'm not sure if @dnolen would agree but I think the best way forward is by writing clojure.specs for everything that goes in there

thheller09:12:58

there aren't many people using this data and so far there has not been any official API

thheller09:12:11

so I'd say it is ok to break things in order to clean them up

thheller09:12:22

well "break" isn't the best word to use

thheller09:12:56

there should probably be only one unique way to identify paths and such

mhuebert09:12:03

@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?

mhuebert09:12:42

I guess I just need to read a lot more of the source 🙂

thheller09:12:11

I honestly can't tell you

thheller09:12:31

but I have a different way of handling paths&co in shadow-build

thheller09:12:39

{: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."}

thheller09:12:52

is what I get for cljs.spec/conform for example

thheller09:12:17

that is already different than what cljs itself produces

thheller09:12:34

so it is fairly safe to assume that it isn't used anywhere 😉

thheller09:12:42

I'd say the it is probably best to keep :meta in :meta and not repeat it at the top

thheller09:12:56

:variadic is definitly used by the compiler

thheller09:12:01

as is :fn-var

thheller09:12:49

:max-fixed-arity, :protocol-impl, :fn-var, :variadic, :name

thheller09:12:02

those are definitely used by the compiler

thheller09:12:33

for source-maps or other meta stuff I can't say whether :meta is used or not

thheller09:12:52

the path stuff of cljs.closure is part of the reason I wrote shadow-build to begin with 😛

mhuebert09:12:30

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

mhuebert09:12:53

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.

mhuebert09:12:55

@thheller do you know offhand why the :column values always differ?

thheller09:12:55

@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

thheller09:12:40

agreed on the paths, in shadow-build I normalize everything when they enter the build process

thheller10:12:03

instead of trying to reconcile everything later based off URLs or files and so on

mhuebert10:12:29

@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)

mhuebert10:12:00

I think it would make sense to normalize to the beginning of the form rather than where the name appears

thheller10:12:30

yeah my guess would be that :meta actually comes from the reader meta of the symbol

thheller11:12:10

@mhuebert it is probably best if you open a CLJS Jira issue to track all the differences in the metadata

thheller11:12:27

I know of some more for the ns itself

dnolen14:12:38

yes a ticket to canonicalize the var meta is welcome

dnolen23:12:16

@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

dnolen23:12:29

other folks, if you have a chance to test master that would be great ^