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 you are excited about doing this design work, please start a page in
Confluence, and capture your goals, options, tradeoffs, and recommendations.
Stu
On Sat, Feb 9, 2013 at 7:20 PM, vemv <v...@vemv.net> wrote:
> 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/context)
> - When performing a release to clojars or central, Lein creates two
> versions ("DEBUG", "NO-DEBUG"), in which the vars are set to true and
> false, respectively
> - 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, "DEBUG" would be chosen unless
> specified otherwise in profiles.clj: {:user {:debug-dependencies false}}
>
> Does it sound good enough?
>
>
> On Friday, February 8, 2013 6:18:54 PM UTC+1, vemv wrote:
>>
>> 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 input:
>>
>> (ns my.namespace)
>>
>> (defn do-it
>> (let [foo (fn [] (throw (Exception.)))
>> bar {:hello (/ 0 0)}]))
>>
>> to:
>>
>> (ns my.namespace)
>>
>> (defn do-it
>> (let [foo (fn foo [] (throw (Exception.)))
>> bar ^{:origin :my.namespace/do-it$let$bar} {:hello (/ 0 0)}]))
>>
>> This could be used to increase the precision of the stack traces, or in
>> IDEs/editors for locating the exact source of an exception.
>>
>> Do you see such a mechanism being incorporated to clojure.core/let -
>> should I open a ticket?
>>
> --
> --
> 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.
>
>
>
--
--
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.
