Fork me on GitHub
#clojure-dev
<
2016-06-09
>
bronsa10:06:38

@hiredman: I just reproduced in prod that Var$Unbound issue you reported the other day -- trying to extract a minimum repro example

bronsa11:06:42

11:28:38 WARNING: Inst already refers to: #'clojure.core/Inst in namespace: schema.core, being replaced by: #'schema.core/Inst
11:28:41 Exception in thread "main" java.lang.IllegalArgumentException: No implementation of method: :spec of protocol: #'schema.core/Schema found for class: clojure.lang.Var$Unbound, compiling:(social/common/url.cljc:43:1)

bronsa11:06:15

weird thing is that it seems to be non deterministic -- one build failed like this, next build built fine

bronsa13:06:12

seems to be caused by a stale target/

bronsa13:06:25

yep. so the steps to repro are: - AOT compile with alpha4 a project that shadows one of the new c.c vars of alpha5 - bump dependency to alpha5 - try to run project

alexmiller13:06:19

Doesn't that affect a whole lot of bytecode?

alexmiller13:06:15

I can't imagine that's going to fly

bronsa14:06:55

yeah, that's 7 extra bytecodes for every def, which is definitely not ideal, but AFAICT is the only way to maintain ABI compatibility when new version of libs add vars that consumers are shadowing

ghadi15:06:46

mumble mumble invokedynamic

ghadi15:06:52

one of the lesser known things about indy is that it's is an excellent tool to win at the binary compatibility game. you wire up a callsite using an indy instruction, which calls the bootstrap method once. bootstrap method can return different MethodHandles in different versions of clojure -- but the bytecode never changes at the callsite

ghadi15:06:58

it's the ultimate in late binding