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 I
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 migh
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 t
On Sat, Feb 9, 2013 at 4:20 PM, vemv 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, "DEB
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
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.)
If
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 var/conte
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 differin
>
> 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
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
+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 charac
On Feb 8, 2013, at 7:56 PM, Daniel Glauser 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,
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 1
2013/2/8 vemv
> 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.
If you wan
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 f
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 inpu
16 matches
Mail list logo