We ended up sticking with AOT (for now, anyway), because it seems easier to
manage in the codebase. The alternative is to use data structures that can
be eval'd, like you would use in the body of a macro. I like how that
clearly separates the code that runs on the local machine from that which
Thanks for your replies.
I've looked at clj-headlights a bunch, and datasplash, too. I was mistaken
to think that AOT was necessary. Earlier in the project, AOT simplified a
few things, like affording the use of anonymous functions (in ParDo
implementations), and I don't think I realized
Interesting! I had not seen clj-headlights but my org is using Beam +
Clojure and we've made some similar decisions as clj-headlights.
Specifically we are avoiding AOT and its headaches,.
On Thursday, September 12, 2019 at 12:37:24 AM UTC-5, Kimmo Koskinen wrote:
>
> Hi!
>
> Not a direct
Hi!
Not a direct answer, but have you looked at clj-headlights
https://github.com/logrhythm-oss/clj-headlights, a Apache Beam wrapper for
Clojure. It might have pointers related to Beam/AOT specifically.
- Kimmo
--
You received this message because you are subscribed to the Google
Groups
I have to use AOT for a project, because it uses Apache Beam/Google
Dataflow.
There are two libraries: A and B. A depends on B. Both require AOT.
B uses :aot :all in the project.clj :dev profile, so that it will AOT for
tests, but not for the jar.
A uses :aot :all at the top level of its
