This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-10-25
Channels
- # 100-days-of-code (6)
- # announcements (4)
- # aws (2)
- # beginners (151)
- # boot (1)
- # calva (1)
- # cider (19)
- # clara (47)
- # cljdoc (9)
- # cljs-dev (25)
- # clojars (18)
- # clojure (151)
- # clojure-canada (1)
- # clojure-conj (1)
- # clojure-dev (17)
- # clojure-italy (42)
- # clojure-nl (34)
- # clojure-spec (67)
- # clojure-uk (125)
- # clojurescript (163)
- # core-async (106)
- # cursive (19)
- # data-science (11)
- # datomic (9)
- # duct (2)
- # figwheel (1)
- # figwheel-main (6)
- # fulcro (97)
- # graphql (9)
- # instaparse (4)
- # jobs (6)
- # jobs-discuss (21)
- # leiningen (62)
- # mount (23)
- # off-topic (16)
- # re-frame (15)
- # reagent (16)
- # reitit (5)
- # remote-jobs (1)
- # ring-swagger (9)
- # shadow-cljs (176)
- # tools-deps (102)
- # unrepl (3)
(and further tracked it down to only happening in a depstar-produced JAR, rather than a full boot-produced JAR... so absolutely nothing to worry about it in this channel!)
(which points to similar issues with gradle-clojure and timestamps in JAR files!)
I think I recall that the file timestamps can matter if there are .class files older/newer than a similarly named .clj file for the same namespace. Are there other known cases where timestamps in JAR files matter?
It sets all time stamps to the same, so clj and class files become the same time, which causes the clj to be JIT compiled over again instead of using classfile
In Maven I had to just use exec plugin to script it to open the shaded jar, and bump all clj files timestamp to some time in past
But I don’t know specifically the problem here. Just saying I’ve had timestamp drama before with aot
My old post on the subject was https://groups.google.com/forum/m/#!topic/clojure/12BOjg1KsWA if it matters
I fixed (my fork of) depstar to preserve timestamps in JAR files and that fixed the issue. It doesn't (yet) preserve timestamps for locally included files but it probably should. Also for directories, to be really paranoid.
The whole thing does seem to make AOT very fragile when source files are still in scope (as if AOT isn't already known to be a giant can of worms!).
yikes. good find! I was bitten by this in bootstrapped katamari tonight. will be eyeballing your patch in the morning.
as best as I can tell, direct linking only optimizes function calls, is that correct? in particular, it doesn't optimize uses of a var that aren't in the call position, whether the var contains a value or it's a function used in HOF style
this makes more sense when I say it out loud; I guess for values I could imagine it being equivalent to ^:const
coolthx