On Jan 16, 6:17 am, Rich Hickey <richhic...@gmail.com> wrote: > On Thu, Jan 14, 2010 at 12:22 PM, ataggart <alex.tagg...@gmail.com> wrote: > > Some people have had issues with c.c.logging in that it looks for a > > suitable logging implementation at macro-expansion-time (by simply > > trying to import the necessary classes), which thus also occurs during > > AOT compilation; the down-side is that if the desired logging lib is > > not on the classpath during compilation, the java.util.logging > > implementation gets selected into the compiled code. There are > > solutions to move this choice to runtime, though it adds some overhead > > to every invocation, even if the respective log level is disabled. > > > It occurs to me it would be very nice indeed if I could provide > > alternate implementations depending on whether the clojure code was > > being executed as a .clj or an AOTC'd .class file. Knowing this would > > further allow the specification of env vars to influence the resulting > > code, e.g., telling c.c.logging that even though it's being AOTC'd, it > > can choose the logging impl right away since it's on the classpath > > (thus negating the performance hit of a runtime selection). > > > Does anyone have a sense of whether or not this is possible already > > or, if not, worth doing? > > (doc *compile-files*) > > Rich
Rich, why do you insist on making things simple and obvious? ;) Thanks.
-- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
