This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-01-20
Channels
- # announcements (1)
- # beginners (48)
- # cljdoc (6)
- # cljs-dev (1)
- # cljsjs (1)
- # clojure (13)
- # clojure-dev (6)
- # clojure-estonia (1)
- # clojure-europe (1)
- # clojure-finland (8)
- # clojure-gamedev (3)
- # clojure-spec (35)
- # clojure-uk (25)
- # clojurescript (9)
- # datascript (1)
- # datomic (18)
- # figwheel-main (2)
- # fulcro (5)
- # graphql (1)
- # jobs (16)
- # off-topic (76)
- # pathom (39)
- # re-frame (6)
- # reagent (7)
- # remote-jobs (6)
- # rum (3)
- # shadow-cljs (54)
- # spacemacs (8)
- # speculative (2)
- # yada (72)
I don’t know what he means by “Compiler.eval switches classloaders” - his fix basically forces the classloader used by the evaluation to be the classloader of the generated class. The way this works is that when the user evaluates an expression, I create an fn that looks like (fn [p1 p2 ...] <user's expression>)
where the parameters are either locals from the current stack frame, or closed over values from higher stack frames. I then call RT.readString()
on that, and Compiler.eval()
on the result. Then I find the invoke
method with the arity corresponding to the number of parameters and call that passing in the values from the local stack frames.
I guess the issue is that Compiler.eval()
creates a new DCL which the anonymous fn class is defined in, but that’s not the one used by the subsequent evaluation of invoke
.