vary-meta slipped my mind! I've updated the gist to include it. The reason
I check for IObj and IMeta is that I want symbols and other custom deftypes
to recieve the metadata as well.
I thought about namespacing the let-names, but for my current purposes I
don't need that extra data (although
On Sat, Feb 9, 2013 at 4:20 PM, vemv v...@vemv.net wrote:
Then library consumers can specify either [com.example/awesomelib 1.4.0],
[com.example 1.4.0-DEBUG], or [com.example 1.4.0-NO-DEBUG] in their
:dependencies vector, in the corresponding project.clj.
If no version directive is specified,
I've written an implementation of this
here: https://gist.github.com/dgrnbrg/4751473
It does incur a 2 instance check penalty (the branches should be 100%
predictable, and never hurt in practice). I'm not sure if I could use
protocols to further reduce the cost of the check.
I've already put
Glad to hear that Phil! You're entirely right - I didn't realise that
distributing jar to Java consumers doesn't imply AOT-compiling the
libraries at all.
David, on your implementation - I may be missing something, but why not
just vary-meta each collection found in the bindings?
Also, it
+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
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
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.
My thoughts too. And there's no need for convention madness - e.g.
Leiningen could transparently create those versions to the user: the
Are you thinking that the client developer (the person using the library)
would maintain the proper magic ear-muffs in lein profiles?
On Saturday, February 9, 2013 3:17:51 PM UTC-8, vemv wrote:
Going the build route, probably use maven to produce debug and production
artifacts of differing
I had something like this in mind:
- There's a set of clojure.core vars that mean something (potentially)
expensive yet convenient, and default to true
- Neither library producers or consumers have ever to touch those
(unless they want fine-grained control for some specific
It is likely that, once this Pandora's box is opened, there will be more
profiles that just debug yes/no.
It is almost certain that whatever we do must be maven friendly. (Maven is
a de facto standard for 1000x more people than leiningen, and some of them
want to use libs written in Clojure.)
Thanks for the advice Stu! I might give it a shot at Confluence at some
point. Just for the record, I like to defend my hypotethical approach:
Non-Clojure consumers most likely win nothing from extended metadata
facilities etc. So on second thoughts, the best default for mylib-*1.0.0*.jar
is to
Given that: a) fns can have names for debugging purposes, and b) data
structures can have metadata, wouldn't it be a good idea to let let auto
attach (where possible) the names of the bindings to their corresponding
values?
For example, the improved let I'm thinking of would translate this
I would find this very useful in several projects I'm working on, where the
library would be able to give better information on where the error is in
the user's code if this metadata was available.
On Friday, February 8, 2013 12:18:54 PM UTC-5, vemv wrote:
Given that: a) fns can have names
2013/2/8 vemv v...@vemv.net
Do you see such a mechanism being incorporated to clojure.core/let -
should I open a ticket?
Only for debugging and not before it has a proven implementation. For
production, we actually want less metadata. At least in memory constrained
environments like android.
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.
On Friday, February 8, 2013
On Feb 8, 2013, at 7:56 PM, Daniel Glauser danglau...@gmail.com 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
16 matches
Mail list logo
