Re: Compilation-aware code?
On Jan 16, 6:17 am, Rich Hickey wrote: > On Thu, Jan 14, 2010 at 12:22 PM, ataggart 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
Re: Compilation-aware code?
On Thu, Jan 14, 2010 at 12:22 PM, ataggart 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 -- 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
Re: Compilation-aware code?
I was referring to common lisp's eval-when special operator: http://www.lispworks.com/documentation/HyperSpec/Body/s_eval_w.htm cyrus On Jan 14, 2010, at 12:22 PM, ataggart wrote: > I'm detecting sarcasm, but it's not clear to me what point you're > trying to make. Care to be more helpful or enlightening? > > > On Jan 14, 12:09 pm, Cyrus Harmon wrote: >> hmm... perhaps one could have a form called something like ... oh, I dunno, >> maybe ... eval-when! And then one could have situations like >> :compile-toplevel and :load-toplevel and, maybe, :execute. Nah... that's a >> crazy idea; never mind... >> >> :) >> >> Cyrus -- 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
Re: Compilation-aware code?
I'm detecting sarcasm, but it's not clear to me what point you're trying to make. Care to be more helpful or enlightening? On Jan 14, 12:09 pm, Cyrus Harmon wrote: > hmm... perhaps one could have a form called something like ... oh, I dunno, > maybe ... eval-when! And then one could have situations like > :compile-toplevel and :load-toplevel and, maybe, :execute. Nah... that's a > crazy idea; never mind... > > :) > > Cyrus > > On Jan 14, 2010, at 9:22 AM, ataggart 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? > > -- > > 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 -- 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
Re: Compilation-aware code?
hmm... perhaps one could have a form called something like ... oh, I dunno, maybe ... eval-when! And then one could have situations like :compile-toplevel and :load-toplevel and, maybe, :execute. Nah... that's a crazy idea; never mind... :) Cyrus On Jan 14, 2010, at 9:22 AM, ataggart 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? > -- > 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 -- 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
Compilation-aware code?
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? -- 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
