Going the build route, probably use maven to produce debug and production artifacts of differing versions: blah-1.0.0-DEBUG.jar and blah-1.0.0.jar.
Rather than go that route and the ensuing naming convention madness, I wonder how much we could rely on the JIT to push the decision of debug vs production to runtime? On Saturday, February 9, 2013 6:31:10 AM UTC-8, stuart....@gmail.com wrote: > > +1 on this line of thought. We are definitely interested in decomplecting > dev mode utility from production lean-and-meanness. > > One question along this path is "What options exist in Java/maven land for > doing multiple releases of the same artifact with e.g. different > performance and debugging characteristics, and how could these be > incorporated into the Clojure build in a transparent, easy-to-assess way?" > > Answering the preceding question (or reframing it into a better question) > is not blocked waiting on anybody. Have at it! > > Stu > > > On Fri, Feb 8, 2013 at 9:36 PM, Brian Marick <mar...@exampler.com<javascript:> > > wrote: > >> >> On Feb 8, 2013, at 7:56 PM, Daniel Glauser <dangl...@gmail.com<javascript:>> >> wrote: >> >> > >> > This sounds like a great idea. I was working with some tests today and >> it would have been really useful to have some way to query the current >> function/execution context. Seems like passing that through all lets would >> go a long way, provided I'm reading this right. >> >> It would be very interesting to have a "maximally informative mode" and a >> "generate really tense code" mode. There is tradition behind such an idea. >> >> It would be especially interesting if the maximally informative mode had >> hooks tools could exploit. For example, Midje provides a hack where you can >> declare records in a way that the contained functions can be mocked: >> `defrecord-openly`. I expect almost no one uses it, even though it is no >> different than `defrecord` when in "production mode": it's too weird >> looking. But people would use it if ordinary defrecord methods weren't >> inlined during development. >> >> There's no *semantic* reason why parts of Clojure should *always* be >> closed to introspection-type actions. It's purely a matter of time >> constraints on the core team, which I am certainly not in a position to >> judge. How much core time should be spent on saving anonymous programmers >> time vs. saving cycles for anonymous apps running on the Amazon cloud? It's >> a tough tradeoff. >> >> -------- >> Looking for 1/2-time employment as a Clojure programmer >> Latest book: /Functional Programming for the Object-Oriented Programmer/ >> https://leanpub.com/fp-oo >> >> -- >> -- >> You received this message because you are subscribed to the Google >> Groups "Clojure" group. >> To post to this group, send email to clo...@googlegroups.com<javascript:> >> Note that posts from new members are moderated - please be patient with >> your first post. >> To unsubscribe from this group, send email to >> clojure+u...@googlegroups.com <javascript:> >> 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 unsubscribe from this group and stop receiving emails from it, send an >> email to clojure+u...@googlegroups.com <javascript:>. >> For more options, visit https://groups.google.com/groups/opt_out. >> >> >> > -- -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
