get rid of reflection in proxy-super?
Hi all, is there any way to get rid of reflection in simmilar looking? Nothing seems to work... (proxy [JPanel ActionListener KeyListener] [] (paintComponent [^java.awt.Graphics g] (let [^JPanel this this] (proxy-super paintComponent g)) thanks in advance... :) Jim -- -- 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.
Re: bug in clojure.zip when calling next on empty list node?
Also, what about this: (loop [z (zip/seq-zip '((nil) 0))] (if (zip/end? z) :done (do (println (zip/node z)) (recur (zip/next z) Which produces: ((nil) 0) (nil) nil 0 :done On Saturday, December 21, 2013 5:59:16 PM UTC-5, Lee wrote: On Dec 21, 2013, at 11:49 AM, Lee Spector wrote: When I step through a zipper made from a nested list via seq-zip, I get extraneous nils after processing a nested (). Is this somehow expected behavior, or a bug, or am I misunderstanding something fundamental? The problem seems to arise only when an nested empty list is present, not other nested lists and not other nested empty sequences (see example at bottom for this bit). I take it back about it working correctly with other nested empty sequences. I realize now that my example of that had a nested empty vector, not a sequence. Trying to reproduce that example with a nested empty sequence just confused me, because it turns out that (seq ()) = (seq []) = nil, and I'm not sure what that means... But this is all really a distraction from the case I care about, which is lists that contain (among other things) nested empty lists. For example, '(() 0). Here it seems to me that zip/next's behavior is clearly wrong and I'm not sure why or what to do about it. Thanks, -Lee -- -- 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.
Re: bug in clojure.zip when calling next on empty list node?
On Dec 22, 2013, at 12:02 PM, Micha Niskin wrote: Also, what about this: (loop [z (zip/seq-zip '((nil) 0))] (if (zip/end? z) :done (do (println (zip/node z)) (recur (zip/next z) Which produces: ((nil) 0) (nil) nil 0 :done I think that's actually fine. The nil is visited and printed as any other element would be. Maybe you expect nil to be handled specially? I'm not sure why, but in any event this is not the issue that I raised. The issue I was rasing is that, when traversing '(() 0) with zip/next, one should first visit the root, then (), and then 0. But what actually happens is that between then () and the 0 one lands on a non-existent nil node. So one ends up visiting 4 nodes when there are only 3, and the extra one is a nil. As I mentioned previously this leads to null pointer exceptions in my application, and the only ways around it that I see are recoding everything without zippers or some nasty special case hackery. It's also possible that I just don't understand something fundamental about zippers and that this is supposed to happen. But if that's not true -- if it's really a bug -- then it'd be great if this could be fixed. Thanks, -Lee -- -- 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.
When does clojure.lang.PersistentArrayMap become clojure.lang.PersistentHashMap
I am surprised that a map literal is clojure.lang.PersistentArrayMap but as
soon as I assign it to a var, it becomes clojure.lang.PersistentHashMap.
Are there any rules for being able to predict when these conversions occur?
user (type {})
clojure.lang.PersistentArrayMap
user (type {:what why?})
clojure.lang.PersistentArrayMap
user (def curious {:what why?})
#'user/curious
user (type curious)
clojure.lang.PersistentHashMap
user (def sug (assoc curious :whodoneit mikey))
#'user/sug
user (type sug)
clojure.lang.PersistentHashMap
I am curious because I wrote a (reduce) function which mostly just builds a
map:
(assoc map-of-data (:item-name next-item) next-item))
Since I was using assoc I was certain I would
get clojure.lang.PersistentHashMap back, but instead I
got clojure.lang.PersistentArrayMap.
--
--
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.
Re: bug in clojure.zip when calling next on empty list node?
What I was getting at there was that it seems like nil could mean a leaf node with the value nil or the absence of leaf nodes, and the two situations can't be distinguished. On Dec 22, 2013 12:26 PM, Lee Spector lspec...@hampshire.edu wrote: On Dec 22, 2013, at 12:02 PM, Micha Niskin wrote: Also, what about this: (loop [z (zip/seq-zip '((nil) 0))] (if (zip/end? z) :done (do (println (zip/node z)) (recur (zip/next z) Which produces: ((nil) 0) (nil) nil 0 :done I think that's actually fine. The nil is visited and printed as any other element would be. Maybe you expect nil to be handled specially? I'm not sure why, but in any event this is not the issue that I raised. The issue I was rasing is that, when traversing '(() 0) with zip/next, one should first visit the root, then (), and then 0. But what actually happens is that between then () and the 0 one lands on a non-existent nil node. So one ends up visiting 4 nodes when there are only 3, and the extra one is a nil. As I mentioned previously this leads to null pointer exceptions in my application, and the only ways around it that I see are recoding everything without zippers or some nasty special case hackery. It's also possible that I just don't understand something fundamental about zippers and that this is supposed to happen. But if that's not true -- if it's really a bug -- then it'd be great if this could be fixed. Thanks, -Lee -- -- 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 a topic in the Google Groups Clojure group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/clojure/8TL7IGmE7N0/unsubscribe. To unsubscribe from this group and all its topics, 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.
Re: When does clojure.lang.PersistentArrayMap become clojure.lang.PersistentHashMap
Hmm, the different return types seem tied to the 2 different functions
being called, but both functions have the same return type, which is a
lazyseq. I am using Monger to get data from MongoDb. These functions are
private:
(defn- get-distinct [request]
{:pre [(= (type request) clojure.lang.PersistentHashMap)]
:post [(= (type %) clojure.lang.LazySeq)]}
(monger/get-distinct (:item-type request)))
(defn- paginate-results [request]
{:pre [ (= (type request) clojure.lang.PersistentHashMap)]
:post [(= (type %) clojure.lang.LazySeq)]}
(monger/paginate-results (:item-type request) (if (:which-page request)
(:which-page request)
0)))
Both of these functions return lazyseqs, as expected. The results from both
get run through a (reduce) function that does some minor filtering. Yet in
one case the return type (from the reduce function)
is clojure.lang.PersistentArrayMap and in the other it
is clojure.lang.PersistentHashMap. I'd like to be able to write a :post
condition that enforces strictness, but that seems impossible because I can
not figure out what the rule is that handles the conversion. I don't care
if the return type is clojure.lang.PersistentArrayMap
or clojure.lang.PersistentHashMap, all I want is it for it be consistently
one or the other.
On Sunday, December 22, 2013 2:31:45 PM UTC-5, larry google groups wrote:
I am surprised that a map literal is clojure.lang.PersistentArrayMap but
as soon as I assign it to a var, it becomes clojure.lang.PersistentHashMap.
Are there any rules for being able to predict when these conversions occur?
user (type {})
clojure.lang.PersistentArrayMap
user (type {:what why?})
clojure.lang.PersistentArrayMap
user (def curious {:what why?})
#'user/curious
user (type curious)
clojure.lang.PersistentHashMap
user (def sug (assoc curious :whodoneit mikey))
#'user/sug
user (type sug)
clojure.lang.PersistentHashMap
I am curious because I wrote a (reduce) function which mostly just builds
a map:
(assoc map-of-data (:item-name next-item) next-item))
Since I was using assoc I was certain I would
get clojure.lang.PersistentHashMap back, but instead I
got clojure.lang.PersistentArrayMap.
--
--
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.
Re: When does clojure.lang.PersistentArrayMap become clojure.lang.PersistentHashMap
Hmm, I see. get-distinct was returning an empty lazyseq, which apparently
made the difference.
On Sunday, December 22, 2013 2:56:01 PM UTC-5, larry google groups wrote:
Hmm, the different return types seem tied to the 2 different functions
being called, but both functions have the same return type, which is a
lazyseq. I am using Monger to get data from MongoDb. These functions are
private:
(defn- get-distinct [request]
{:pre [(= (type request) clojure.lang.PersistentHashMap)]
:post [(= (type %) clojure.lang.LazySeq)]}
(monger/get-distinct (:item-type request)))
(defn- paginate-results [request]
{:pre [ (= (type request) clojure.lang.PersistentHashMap)]
:post [(= (type %) clojure.lang.LazySeq)]}
(monger/paginate-results (:item-type request) (if (:which-page request)
(:which-page request)
0)))
Both of these functions return lazyseqs, as expected. The results from
both get run through a (reduce) function that does some minor filtering.
Yet in one case the return type (from the reduce function)
is clojure.lang.PersistentArrayMap and in the other it
is clojure.lang.PersistentHashMap. I'd like to be able to write a :post
condition that enforces strictness, but that seems impossible because I can
not figure out what the rule is that handles the conversion. I don't care
if the return type is clojure.lang.PersistentArrayMap
or clojure.lang.PersistentHashMap, all I want is it for it be consistently
one or the other.
On Sunday, December 22, 2013 2:31:45 PM UTC-5, larry google groups wrote:
I am surprised that a map literal is clojure.lang.PersistentArrayMap but
as soon as I assign it to a var, it becomes clojure.lang.PersistentHashMap.
Are there any rules for being able to predict when these conversions occur?
user (type {})
clojure.lang.PersistentArrayMap
user (type {:what why?})
clojure.lang.PersistentArrayMap
user (def curious {:what why?})
#'user/curious
user (type curious)
clojure.lang.PersistentHashMap
user (def sug (assoc curious :whodoneit mikey))
#'user/sug
user (type sug)
clojure.lang.PersistentHashMap
I am curious because I wrote a (reduce) function which mostly just builds
a map:
(assoc map-of-data (:item-name next-item) next-item))
Since I was using assoc I was certain I would
get clojure.lang.PersistentHashMap back, but instead I
got clojure.lang.PersistentArrayMap.
--
--
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.
Re: get rid of reflection in proxy-super?
I actually just wrote a long reply detailing how to type hint 'this', and then noticed that you've already done that! This exact case (paintComponent) is the one reflection warning I can't get rid of in the whole Cursive codebase, I can't figure it out either. On 23 December 2013 01:03, Jim - FooBar(); jimpil1...@gmail.com wrote: Hi all, is there any way to get rid of reflection in simmilar looking? Nothing seems to work... (proxy [JPanel ActionListener KeyListener] [] (paintComponent [^java.awt.Graphics g] (let [^JPanel this this] (proxy-super paintComponent g)) thanks in advance... :) Jim -- -- 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.
Where are the videos for Clojure Conj 2013
Were any videos of the presentations made? Have they been uploaded anywhere online? Sorry if this has been asked before I have tried searching. regards, Richard. -- -- 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.
How do I fix *warn-on-reflextion* warnings in 3rd party libraries?
I know this has been discussed before but I could not find anything like a canonical answer via Google. I just set to :warn-on-reflection true in my project.clj and now I get the following warnings. How do I fix the warnings that are in 3rd party libraries? How do I add type hints to code I :use or :require? lein uberjar Compiling admin.core Reflection warning, admin/monitoring.clj:15:5 - call to enumerate can't be resolved. Reflection warning, admin/monitoring.clj:22:27 - reference to field getName can't be resolved. Reflection warning, admin/monitoring.clj:27:25 - reference to field getId can't be resolved. Reflection warning, admin/monitoring.clj:34:50 - reference to field getId can't be resolved. Reflection warning, admin/monitoring.clj:37:26 - reference to field getName can't be resolved. Reflection warning, admin/monitoring.clj:37:39 - reference to field getId can't be resolved. Reflection warning, clj_time/core.clj:577:10 - reference to field getDayOfMonth can't be resolved. Reflection warning, monger/joda_time.clj:32:19 - reference to field toDate can't be resolved. Reflection warning, monger/joda_time.clj:64:14 - reference to field toDate can't be resolved. Reflection warning, clojure/core/incubator.clj:90:7 - reference to field getClass can't be resolved. Reflection warning, clojure/core/incubator.clj:90:7 - reference to field isArray can't be resolved. Reflection warning, lamina/trace/timer.clj:173:7 - call to enqueue can't be resolved. Reflection warning, lamina/trace/timer.clj:302:5 - call to enqueue can't be resolved. Reflection warning, formative/util.clj:37:9 - call to valueOf can't be resolved. Reflection warning, jkkramer/verily.clj:304:15 - call to digit can't be resolved. Reflection warning, formative/parse.clj:45:9 - call to valueOf can't be resolved. Reflection warning, formative/parse.clj:49:15 - call to valueOf can't be resolved. Reflection warning, formative/parse.clj:55:13 - call to valueOf can't be resolved. Reflection warning, formative/parse.clj:74:13 - call to java.math.BigDecimal ctor can't be resolved. Reflection warning, formative/parse.clj:87:21 - call to java.math.BigInteger ctor can't be resolved. Reflection warning, admin/controller.clj:159:29 - reference to field toString can't be resolved. Reflection warning, admin/controller.clj:159:29 - reference to field toString can't be resolved. Reflection warning, net/cgrand/xml.clj:85:4 - call to parse can't be resolved. Reflection warning, net/cgrand/tagsoup.clj:15:3 - call to parse can't be resolved. Reflection warning, net/cgrand/tagsoup.clj:32:18 - call to org.xml.sax.InputSource ctor can't be resolved. Reflection warning, net/cgrand/enlive_html.clj:54:16 - call to org.xml.sax.InputSource ctor can't be resolved. Reflection warning, admin/supervisor.clj:54:5 - call to java.lang.Thread ctor can't be resolved. Reflection warning, admin/supervisor.clj:54:5 - call to java.lang.Thread ctor can't be resolved. Reflection warning, clojure/tools/reader/default_data_readers.clj:175:20 - reference to field get can't be resolved. Reflection warning, clojure/tools/reader/default_data_readers.clj:177:15 - call to format can't be resolved. Reflection warning, clojure/tools/reader/default_data_readers.clj:177:5 - call to write can't be resolved. Reflection warning, clojure/tools/reader/default_data_readers.clj:220:20 - reference to field get can't be resolved. Reflection warning, clojure/tools/reader/default_data_readers.clj:222:15 - call to format can't be resolved. Reflection warning, clojure/tools/reader/default_data_readers.clj:222:5 - call to write can't be resolved. Reflection warning, clojure/tools/reader.clj:71:20 - call to digit can't be resolved. Reflection warning, clojure/tools/reader.clj:77:20 - call to digit can't be resolved. Reflection warning, clojure/tools/reader.clj:89:24 - call to digit can't be resolved. Reflection warning, clojure/tools/reader.clj:214:23 - call to digit can't be resolved. Reflection warning, clojure/tools/reader.clj:218:23 - call to digit can't be resolved. Reflection warning, clojure/tools/reader/edn.clj:78:20 - call to digit can't be resolved. Reflection warning, clojure/tools/reader/edn.clj:84:20 - call to digit can't be resolved. Reflection warning, clojure/tools/reader/edn.clj:96:24 - call to digit can't be resolved. Reflection warning, clojure/tools/reader/edn.clj:205:23 - call to digit can't be resolved. Reflection warning, clojure/tools/reader/edn.clj:209:23 - call to digit can't be resolved. Reflection warning, ns_tracker/core.clj:20:28 - reference to field lastModified can't be resolved. Reflection warning, ns_tracker/core.clj:25:6 - reference to field lastModified can't be resolved. Reflection warning, ring/middleware/session/cookie.clj:82:27 - reference to field getBytes can't be resolved. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to
Re: How do I fix *warn-on-reflextion* warnings in 3rd party libraries?
Most often, you don't add type hints to code you :use or :require. You disable the warnings, or accept that you will see a slew of them, or if you only want to see them in your own code but not in libraries you use, remove :warn-on-reflection true from your project.clj, and edit your source files to put a line like (set! *warn-on-reflection true) near the beginning of the file, after the ns statement. If the source code is available, e.g. on Github, you can get a copy of it, edit it to eliminate the reflection warnings (when possible), and then install a copy of that project locally in your ~/.m2 Maven repo using 'lein install' (if the project uses Leiningen). You could even submit a JIRA ticket with patch (if the library is part of Clojure core) or whatever the project owner prefers for change ideas (e.g. often Github pull requests), and they might choose to accept your changes into their copy of the library. Andy On Sun, Dec 22, 2013 at 2:33 PM, larry google groups lawrencecloj...@gmail.com wrote: I know this has been discussed before but I could not find anything like a canonical answer via Google. I just set to :warn-on-reflection true in my project.clj and now I get the following warnings. How do I fix the warnings that are in 3rd party libraries? How do I add type hints to code I :use or :require? lein uberjar Compiling admin.core Reflection warning, admin/monitoring.clj:15:5 - call to enumerate can't be resolved. Reflection warning, admin/monitoring.clj:22:27 - reference to field getName can't be resolved. Reflection warning, admin/monitoring.clj:27:25 - reference to field getId can't be resolved. Reflection warning, admin/monitoring.clj:34:50 - reference to field getId can't be resolved. Reflection warning, admin/monitoring.clj:37:26 - reference to field getName can't be resolved. Reflection warning, admin/monitoring.clj:37:39 - reference to field getId can't be resolved. Reflection warning, clj_time/core.clj:577:10 - reference to field getDayOfMonth can't be resolved. Reflection warning, monger/joda_time.clj:32:19 - reference to field toDate can't be resolved. Reflection warning, monger/joda_time.clj:64:14 - reference to field toDate can't be resolved. Reflection warning, clojure/core/incubator.clj:90:7 - reference to field getClass can't be resolved. Reflection warning, clojure/core/incubator.clj:90:7 - reference to field isArray can't be resolved. Reflection warning, lamina/trace/timer.clj:173:7 - call to enqueue can't be resolved. Reflection warning, lamina/trace/timer.clj:302:5 - call to enqueue can't be resolved. Reflection warning, formative/util.clj:37:9 - call to valueOf can't be resolved. Reflection warning, jkkramer/verily.clj:304:15 - call to digit can't be resolved. Reflection warning, formative/parse.clj:45:9 - call to valueOf can't be resolved. Reflection warning, formative/parse.clj:49:15 - call to valueOf can't be resolved. Reflection warning, formative/parse.clj:55:13 - call to valueOf can't be resolved. Reflection warning, formative/parse.clj:74:13 - call to java.math.BigDecimal ctor can't be resolved. Reflection warning, formative/parse.clj:87:21 - call to java.math.BigInteger ctor can't be resolved. Reflection warning, admin/controller.clj:159:29 - reference to field toString can't be resolved. Reflection warning, admin/controller.clj:159:29 - reference to field toString can't be resolved. Reflection warning, net/cgrand/xml.clj:85:4 - call to parse can't be resolved. Reflection warning, net/cgrand/tagsoup.clj:15:3 - call to parse can't be resolved. Reflection warning, net/cgrand/tagsoup.clj:32:18 - call to org.xml.sax.InputSource ctor can't be resolved. Reflection warning, net/cgrand/enlive_html.clj:54:16 - call to org.xml.sax.InputSource ctor can't be resolved. Reflection warning, admin/supervisor.clj:54:5 - call to java.lang.Thread ctor can't be resolved. Reflection warning, admin/supervisor.clj:54:5 - call to java.lang.Thread ctor can't be resolved. Reflection warning, clojure/tools/reader/default_data_readers.clj:175:20 - reference to field get can't be resolved. Reflection warning, clojure/tools/reader/default_data_readers.clj:177:15 - call to format can't be resolved. Reflection warning, clojure/tools/reader/default_data_readers.clj:177:5 - call to write can't be resolved. Reflection warning, clojure/tools/reader/default_data_readers.clj:220:20 - reference to field get can't be resolved. Reflection warning, clojure/tools/reader/default_data_readers.clj:222:15 - call to format can't be resolved. Reflection warning, clojure/tools/reader/default_data_readers.clj:222:5 - call to write can't be resolved. Reflection warning, clojure/tools/reader.clj:71:20 - call to digit can't be resolved. Reflection warning, clojure/tools/reader.clj:77:20 - call to digit can't be resolved. Reflection warning, clojure/tools/reader.clj:89:24 - call to digit can't be resolved. Reflection warning,
Re: How do I fix *warn-on-reflextion* warnings in 3rd party libraries?
For clj-time I'm happy to just see an issue opened on Github (when it's back from its current 503 woes!) and happier to see a Pull Request. For clojure.tools.reader, you'll need to open issues in JIRA as Andy indicated. Most of the rest sound like Github-based projects so opening issues, preferably with PRs should get some of those cleaned up. Sean On Sun, Dec 22, 2013 at 2:33 PM, larry google groups lawrencecloj...@gmail.com wrote: I know this has been discussed before but I could not find anything like a canonical answer via Google. I just set to :warn-on-reflection true in my project.clj and now I get the following warnings. How do I fix the warnings that are in 3rd party libraries? How do I add type hints to code I :use or :require? lein uberjar Compiling admin.core Reflection warning, admin/monitoring.clj:15:5 - call to enumerate can't be resolved. Reflection warning, admin/monitoring.clj:22:27 - reference to field getName can't be resolved. Reflection warning, admin/monitoring.clj:27:25 - reference to field getId can't be resolved. Reflection warning, admin/monitoring.clj:34:50 - reference to field getId can't be resolved. Reflection warning, admin/monitoring.clj:37:26 - reference to field getName can't be resolved. Reflection warning, admin/monitoring.clj:37:39 - reference to field getId can't be resolved. Reflection warning, clj_time/core.clj:577:10 - reference to field getDayOfMonth can't be resolved. Reflection warning, monger/joda_time.clj:32:19 - reference to field toDate can't be resolved. Reflection warning, monger/joda_time.clj:64:14 - reference to field toDate can't be resolved. Reflection warning, clojure/core/incubator.clj:90:7 - reference to field getClass can't be resolved. Reflection warning, clojure/core/incubator.clj:90:7 - reference to field isArray can't be resolved. Reflection warning, lamina/trace/timer.clj:173:7 - call to enqueue can't be resolved. Reflection warning, lamina/trace/timer.clj:302:5 - call to enqueue can't be resolved. Reflection warning, formative/util.clj:37:9 - call to valueOf can't be resolved. Reflection warning, jkkramer/verily.clj:304:15 - call to digit can't be resolved. Reflection warning, formative/parse.clj:45:9 - call to valueOf can't be resolved. Reflection warning, formative/parse.clj:49:15 - call to valueOf can't be resolved. Reflection warning, formative/parse.clj:55:13 - call to valueOf can't be resolved. Reflection warning, formative/parse.clj:74:13 - call to java.math.BigDecimal ctor can't be resolved. Reflection warning, formative/parse.clj:87:21 - call to java.math.BigInteger ctor can't be resolved. Reflection warning, admin/controller.clj:159:29 - reference to field toString can't be resolved. Reflection warning, admin/controller.clj:159:29 - reference to field toString can't be resolved. Reflection warning, net/cgrand/xml.clj:85:4 - call to parse can't be resolved. Reflection warning, net/cgrand/tagsoup.clj:15:3 - call to parse can't be resolved. Reflection warning, net/cgrand/tagsoup.clj:32:18 - call to org.xml.sax.InputSource ctor can't be resolved. Reflection warning, net/cgrand/enlive_html.clj:54:16 - call to org.xml.sax.InputSource ctor can't be resolved. Reflection warning, admin/supervisor.clj:54:5 - call to java.lang.Thread ctor can't be resolved. Reflection warning, admin/supervisor.clj:54:5 - call to java.lang.Thread ctor can't be resolved. Reflection warning, clojure/tools/reader/default_data_readers.clj:175:20 - reference to field get can't be resolved. Reflection warning, clojure/tools/reader/default_data_readers.clj:177:15 - call to format can't be resolved. Reflection warning, clojure/tools/reader/default_data_readers.clj:177:5 - call to write can't be resolved. Reflection warning, clojure/tools/reader/default_data_readers.clj:220:20 - reference to field get can't be resolved. Reflection warning, clojure/tools/reader/default_data_readers.clj:222:15 - call to format can't be resolved. Reflection warning, clojure/tools/reader/default_data_readers.clj:222:5 - call to write can't be resolved. Reflection warning, clojure/tools/reader.clj:71:20 - call to digit can't be resolved. Reflection warning, clojure/tools/reader.clj:77:20 - call to digit can't be resolved. Reflection warning, clojure/tools/reader.clj:89:24 - call to digit can't be resolved. Reflection warning, clojure/tools/reader.clj:214:23 - call to digit can't be resolved. Reflection warning, clojure/tools/reader.clj:218:23 - call to digit can't be resolved. Reflection warning, clojure/tools/reader/edn.clj:78:20 - call to digit can't be resolved. Reflection warning, clojure/tools/reader/edn.clj:84:20 - call to digit can't be resolved. Reflection warning, clojure/tools/reader/edn.clj:96:24 - call to digit can't be resolved. Reflection warning, clojure/tools/reader/edn.clj:205:23 - call to digit can't be resolved. Reflection warning, clojure/tools/reader/edn.clj:209:23 -
Re: How do I fix *warn-on-reflextion* warnings in 3rd party libraries?
On Sun, Dec 22, 2013 at 2:55 PM, Sean Corfield seancorfi...@gmail.com wrote: For clj-time I'm happy to just see an issue opened on Github (when it's back from its current 503 woes!) and happier to see a Pull Request. https://github.com/clj-time/clj-time/issues/100 -- Sean A Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ World Singles, LLC. -- http://worldsingles.com/ Perfection is the enemy of the good. -- Gustave Flaubert, French realist novelist (1821-1880) -- -- 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.
Re: Where are the videos for Clojure Conj 2013
According to a note I found on Reddit via Google, Conj videos have historically appeared on the ClojureTV YouTube channel 4-6 weeks after the event so I would expect them to start appearing soon through the New Year... Sean On Sun, Dec 22, 2013 at 1:25 PM, Richard Cole richard.j.c...@gmail.com wrote: Were any videos of the presentations made? Have they been uploaded anywhere online? Sorry if this has been asked before I have tried searching. regards, Richard. -- -- 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. -- Sean A Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ World Singles, LLC. -- http://worldsingles.com/ Perfection is the enemy of the good. -- Gustave Flaubert, French realist novelist (1821-1880) -- -- 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.
Looking to migrate thousands of Clojure applications from 1.2 to 1.5.
At my company, we use Clojure for reporting. Specifically, reports are written in Clojure which integrate data from a variety of sources and display the final output to the user in a WPF-based webapp. For all intents and purposes, each 'report' is a standalone Clojure app, and most of them use the contrib library. Not all of them are active, but there are thousands. And I need to migrate them over to 1.5. Now I know the contrib libraries are not compatible with 1.3+. From what I've read, the big change is related to dynamic var declaration, and there are subtle incompatibilities involving certain scalars. I also looked at this page for information on each library's migration: http://dev.clojure.org/display/community/Where+Did+Clojure.Contrib+Go I'm considering one of two approaches: 1) Run both Clojure 1.2 and 1.5, with all new reports required to use the modular contrib libraries. This would require a change to the backend appservers. 2) Grep the reports and create a list of all the distinct contrib libraries we use. Identify which of the libraries have a modular analog, and replace accordingly. To do this, I would need to check that the function signatures match and the output is remains as expected. I would also still need to run 1.2 running in production and 1.5 in a sandbox to migrate reports over gradually. Asking individual authors to update their reports won't work. Please share your opinions on these approaches or what your experience was in migrating from 1.2 to 1.3+. Also, is there an easier way which I'm not seeing? Thank you. Sol -- -- 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.
Re: Looking to migrate thousands of Clojure applications from 1.2 to 1.5.
If you truly have thousands of Clojure 1.2 apps, I'd go with option 1), and look at migrating legacy reports over if you need to do any maintenance on them. Since Clojure is just a Java library, it's fairly easy to keep the Clojure version locked in each individual project so there's no reason to migrate old, working reports if you don't have to do any maintenance / updates on them. The differences in numerics as well as the difference between monolithic contrib and modern, modular contrib could eat up a lot of your time in migration and, unless you are constantly updating all those reports, I'm not sure what the benefits would be. Sean On Sun, Dec 22, 2013 at 3:51 PM, solo.l...@gmail.com wrote: At my company, we use Clojure for reporting. Specifically, reports are written in Clojure which integrate data from a variety of sources and display the final output to the user in a WPF-based webapp. For all intents and purposes, each 'report' is a standalone Clojure app, and most of them use the contrib library. Not all of them are active, but there are thousands. And I need to migrate them over to 1.5. Now I know the contrib libraries are not compatible with 1.3+. From what I've read, the big change is related to dynamic var declaration, and there are subtle incompatibilities involving certain scalars. I also looked at this page for information on each library's migration: http://dev.clojure.org/display/community/Where+Did+Clojure.Contrib+Go I'm considering one of two approaches: 1) Run both Clojure 1.2 and 1.5, with all new reports required to use the modular contrib libraries. This would require a change to the backend appservers. 2) Grep the reports and create a list of all the distinct contrib libraries we use. Identify which of the libraries have a modular analog, and replace accordingly. To do this, I would need to check that the function signatures match and the output is remains as expected. I would also still need to run 1.2 running in production and 1.5 in a sandbox to migrate reports over gradually. Asking individual authors to update their reports won't work. Please share your opinions on these approaches or what your experience was in migrating from 1.2 to 1.3+. Also, is there an easier way which I'm not seeing? Thank you. Sol -- -- 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. -- Sean A Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ World Singles, LLC. -- http://worldsingles.com/ Perfection is the enemy of the good. -- Gustave Flaubert, French realist novelist (1821-1880) -- -- 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.
Re: Looking to migrate thousands of Clojure applications from 1.2 to 1.5.
A third option I'm considering is to simply keep running 1.2 and replace the contrib libraries with their modular counterparts, moving to 1.5 only after that's done. The two difficulties I see here are: 1) Ensuring all new reports written during this process use the modular libraries 2) What to do about contrib libraries which have no counterpart (but this difficulty applies to all options) On Sunday, December 22, 2013 6:51:06 PM UTC-5, solo...@gmail.com wrote: At my company, we use Clojure for reporting. Specifically, reports are written in Clojure which integrate data from a variety of sources and display the final output to the user in a WPF-based webapp. For all intents and purposes, each 'report' is a standalone Clojure app, and most of them use the contrib library. Not all of them are active, but there are thousands. And I need to migrate them over to 1.5. Now I know the contrib libraries are not compatible with 1.3+. From what I've read, the big change is related to dynamic var declaration, and there are subtle incompatibilities involving certain scalars. I also looked at this page for information on each library's migration: http://dev.clojure.org/display/community/Where+Did+Clojure.Contrib+Go I'm considering one of two approaches: 1) Run both Clojure 1.2 and 1.5, with all new reports required to use the modular contrib libraries. This would require a change to the backend appservers. 2) Grep the reports and create a list of all the distinct contrib libraries we use. Identify which of the libraries have a modular analog, and replace accordingly. To do this, I would need to check that the function signatures match and the output is remains as expected. I would also still need to run 1.2 running in production and 1.5 in a sandbox to migrate reports over gradually. Asking individual authors to update their reports won't work. Please share your opinions on these approaches or what your experience was in migrating from 1.2 to 1.3+. Also, is there an easier way which I'm not seeing? Thank you. Sol -- -- 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.
Re: Looking to migrate thousands of Clojure applications from 1.2 to 1.5.
Thanks, Sean. Yes, the reports are static and not maintained. The lifecycle of the typical report is as follows: 1) Business requests data 2) Someone writes a report using Clojure 3) Business views the report and may request changes now and then 4) Business eventually loses interest Part of my plan may involve just cutting anything which hasn't been run in 90 days. On Sunday, December 22, 2013 7:05:13 PM UTC-5, Sean Corfield wrote: If you truly have thousands of Clojure 1.2 apps, I'd go with option 1), and look at migrating legacy reports over if you need to do any maintenance on them. Since Clojure is just a Java library, it's fairly easy to keep the Clojure version locked in each individual project so there's no reason to migrate old, working reports if you don't have to do any maintenance / updates on them. The differences in numerics as well as the difference between monolithic contrib and modern, modular contrib could eat up a lot of your time in migration and, unless you are constantly updating all those reports, I'm not sure what the benefits would be. Sean On Sun, Dec 22, 2013 at 3:51 PM, solo...@gmail.com javascript: wrote: At my company, we use Clojure for reporting. Specifically, reports are written in Clojure which integrate data from a variety of sources and display the final output to the user in a WPF-based webapp. For all intents and purposes, each 'report' is a standalone Clojure app, and most of them use the contrib library. Not all of them are active, but there are thousands. And I need to migrate them over to 1.5. Now I know the contrib libraries are not compatible with 1.3+. From what I've read, the big change is related to dynamic var declaration, and there are subtle incompatibilities involving certain scalars. I also looked at this page for information on each library's migration: http://dev.clojure.org/display/community/Where+Did+Clojure.Contrib+Go I'm considering one of two approaches: 1) Run both Clojure 1.2 and 1.5, with all new reports required to use the modular contrib libraries. This would require a change to the backend appservers. 2) Grep the reports and create a list of all the distinct contrib libraries we use. Identify which of the libraries have a modular analog, and replace accordingly. To do this, I would need to check that the function signatures match and the output is remains as expected. I would also still need to run 1.2 running in production and 1.5 in a sandbox to migrate reports over gradually. Asking individual authors to update their reports won't work. Please share your opinions on these approaches or what your experience was in migrating from 1.2 to 1.3+. Also, is there an easier way which I'm not seeing? Thank you. Sol -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clo...@googlegroups.comjavascript: 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. -- Sean A Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ World Singles, LLC. -- http://worldsingles.com/ Perfection is the enemy of the good. -- Gustave Flaubert, French realist novelist (1821-1880) -- -- 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.
Re: Looking to migrate thousands of Clojure applications from 1.2 to 1.5.
Could you point to more information regarding the numeric changes? I can't seem to pinpoint anything in particular here: https://github.com/clojure/clojure/blob/1.3.x/changes.txt On Sunday, December 22, 2013 7:05:13 PM UTC-5, Sean Corfield wrote: If you truly have thousands of Clojure 1.2 apps, I'd go with option 1), and look at migrating legacy reports over if you need to do any maintenance on them. Since Clojure is just a Java library, it's fairly easy to keep the Clojure version locked in each individual project so there's no reason to migrate old, working reports if you don't have to do any maintenance / updates on them. The differences in numerics as well as the difference between monolithic contrib and modern, modular contrib could eat up a lot of your time in migration and, unless you are constantly updating all those reports, I'm not sure what the benefits would be. Sean On Sun, Dec 22, 2013 at 3:51 PM, solo...@gmail.com javascript: wrote: At my company, we use Clojure for reporting. Specifically, reports are written in Clojure which integrate data from a variety of sources and display the final output to the user in a WPF-based webapp. For all intents and purposes, each 'report' is a standalone Clojure app, and most of them use the contrib library. Not all of them are active, but there are thousands. And I need to migrate them over to 1.5. Now I know the contrib libraries are not compatible with 1.3+. From what I've read, the big change is related to dynamic var declaration, and there are subtle incompatibilities involving certain scalars. I also looked at this page for information on each library's migration: http://dev.clojure.org/display/community/Where+Did+Clojure.Contrib+Go I'm considering one of two approaches: 1) Run both Clojure 1.2 and 1.5, with all new reports required to use the modular contrib libraries. This would require a change to the backend appservers. 2) Grep the reports and create a list of all the distinct contrib libraries we use. Identify which of the libraries have a modular analog, and replace accordingly. To do this, I would need to check that the function signatures match and the output is remains as expected. I would also still need to run 1.2 running in production and 1.5 in a sandbox to migrate reports over gradually. Asking individual authors to update their reports won't work. Please share your opinions on these approaches or what your experience was in migrating from 1.2 to 1.3+. Also, is there an easier way which I'm not seeing? Thank you. Sol -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clo...@googlegroups.comjavascript: 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. -- Sean A Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ World Singles, LLC. -- http://worldsingles.com/ Perfection is the enemy of the good. -- Gustave Flaubert, French realist novelist (1821-1880) -- -- 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.
Re: Looking to migrate thousands of Clojure applications from 1.2 to 1.5.
On Sun, Dec 22, 2013 at 4:13 PM, solo.l...@gmail.com wrote: Could you point to more information regarding the numeric changes? I can't seem to pinpoint anything in particular here: https://github.com/clojure/clojure/blob/1.3.x/changes.txt That document links to these: * http://dev.clojure.org/display/design/Enhanced+Primitive+Support * http://dev.clojure.org/display/design/Documentation+for+1.3+Numerics Hope those help? -- Sean A Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ World Singles, LLC. -- http://worldsingles.com/ Perfection is the enemy of the good. -- Gustave Flaubert, French realist novelist (1821-1880) -- -- 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.
Re: Looking to migrate thousands of Clojure applications from 1.2 to 1.5.
On Sun, Dec 22, 2013 at 4:07 PM, solo.l...@gmail.com wrote: A third option I'm considering is to simply keep running 1.2 and replace the contrib libraries with their modular counterparts, moving to 1.5 only after that's done. The two difficulties I see here are: 1) Ensuring all new reports written during this process use the modular libraries 2) What to do about contrib libraries which have no counterpart (but this difficulty applies to all options) Whatever decision you make, this page will be useful: * http://dev.clojure.org/display/community/Where+Did+Clojure.Contrib+Go -- Sean A Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ World Singles, LLC. -- http://worldsingles.com/ Perfection is the enemy of the good. -- Gustave Flaubert, French realist novelist (1821-1880) -- -- 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.
Re: Looking to migrate thousands of Clojure applications from 1.2 to 1.5.
Yep, those links were useful. Cheers, Sean. -- -- 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.
Re: get rid of reflection in proxy-super?
Seesaw has the same problem with paintComponent. IIRC, it's because it's
protected. I never found a workaround.
Dave
On Sunday, December 22, 2013, Colin Fleming wrote:
I actually just wrote a long reply detailing how to type hint 'this', and
then noticed that you've already done that! This exact case
(paintComponent) is the one reflection warning I can't get rid of in the
whole Cursive codebase, I can't figure it out either.
On 23 December 2013 01:03, Jim - FooBar();
jimpil1...@gmail.comjavascript:_e({}, 'cvml', 'jimpil1...@gmail.com');
wrote:
Hi all,
is there any way to get rid of reflection in simmilar looking? Nothing
seems to work...
(proxy [JPanel ActionListener KeyListener] []
(paintComponent [^java.awt.Graphics g]
(let [^JPanel this this]
(proxy-super paintComponent g))
thanks in advance... :)
Jim
--
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to
clojure@googlegroups.comjavascript:_e({}, 'cvml',
'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 javascript:_e({}, 'cvml',
'clojure%2bunsubscr...@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 javascript:_e({}, 'cvml',
'clojure%2bunsubscr...@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.comjavascript:_e({}, 'cvml',
'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 javascript:_e({}, 'cvml',
'clojure%2bunsubscr...@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 javascript:_e({}, 'cvml',
'clojure%2bunsubscr...@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.
Re: How to go about 'proving' why dynamically typed languages are better.
The things is that dynamically typed languages are easier to implement than statically typed languages. Static typing comes down to making statements about the program and deriving other statements from them. It leads to all sorts of interesting work including I think into systems like Z. However theorem provers are limited in what they can do, and it can be both limiting and a big distraction to you as programmer to get into a dialogue with the theorem prover about your program. It can distract you from your original intention which was to write a program to do something in particular. So simply put, dynamic languages are better than static ones because they don't distract you with type discussions that can end up being unprofitable or limiting. Static languages are better because sometimes the type discussions lead to early and convenient detection of bugs and can also in some cases make it easier for other people to understand you program or how to use your library. Static types I think also help refactoring tools. Having optional typing in clojure is very nice. It allows for a lot of experimentation and research on type systems and for them to be used to the extent that people find them useful in their work. It is why I guess Alan Kay said that lisp is not a language, it's a building material. If you want to know what are the current problems in static typing you going to have to start learning what people are doing in that field, e.g. is their foreign function interface from Haskel to Java? Why not? Can a well typed program still exhibit bugs? If the type checking is so powerful why do bugs persist? You might also look at what Gilhad Brakka was attempting to do with newspeak and his notions of types being anti-modular. You are not going to find a proof that that line of enquirely is fruitless, you'll instead find what people can do today in that field and where they're pushing the bounds. regards, Richard. -- -- 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.
Re: Where are the videos for Clojure Conj 2013
All talks were recorded. All editing is complete. The bottleneck right now is in just getting them uploaded which should clear up soon after the holidays. Alex On Sunday, December 22, 2013 3:25:07 PM UTC-6, Richard Cole wrote: Were any videos of the presentations made? Have they been uploaded anywhere online? Sorry if this has been asked before I have tried searching. regards, Richard. -- -- 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.
Re: get rid of reflection in proxy-super?
But surely proxy-super should be designed to call protected methods? I'd have to check but I suspect I call other protected methods using it. On 23 December 2013 14:13, Dave Ray dave...@gmail.com wrote: Seesaw has the same problem with paintComponent. IIRC, it's because it's protected. I never found a workaround. Dave On Sunday, December 22, 2013, Colin Fleming wrote: I actually just wrote a long reply detailing how to type hint 'this', and then noticed that you've already done that! This exact case (paintComponent) is the one reflection warning I can't get rid of in the whole Cursive codebase, I can't figure it out either. On 23 December 2013 01:03, Jim - FooBar(); jimpil1...@gmail.com wrote: Hi all, is there any way to get rid of reflection in simmilar looking? Nothing seems to work... (proxy [JPanel ActionListener KeyListener] [] (paintComponent [^java.awt.Graphics g] (let [^JPanel this this] (proxy-super paintComponent g)) thanks in advance... :) Jim -- -- 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. -- -- 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.
Re: Looking to migrate thousands of Clojure applications from 1.2 to 1.5.
One difficulty with this approach (which I largely following on a similar operation a while back) is that the modular counterparts have continued forward and in many cases are not API-compatible with the 1.2 version anymore (tools.cli is one example that I remember from this transition as its API changed significantly). In fact, some contrib libraries no longer build or support 1.2 at all. In those cases, you're going to need to jump both contrib and clojure version at the same time. Before doing anything, I would do a census as to which of the clojure.contrib namespaces are actually in use. Perhaps you examine them in order from most recently run backwards. I'm guessing that there is a decent amount of duplication and copy/paste if you really have thousands of these, so I suspect you'll see some patterns. On Sunday, December 22, 2013 6:07:26 PM UTC-6, solo...@gmail.com wrote: A third option I'm considering is to simply keep running 1.2 and replace the contrib libraries with their modular counterparts, moving to 1.5 only after that's done. The two difficulties I see here are: 1) Ensuring all new reports written during this process use the modular libraries 2) What to do about contrib libraries which have no counterpart (but this difficulty applies to all options) On Sunday, December 22, 2013 6:51:06 PM UTC-5, solo...@gmail.com wrote: At my company, we use Clojure for reporting. Specifically, reports are written in Clojure which integrate data from a variety of sources and display the final output to the user in a WPF-based webapp. For all intents and purposes, each 'report' is a standalone Clojure app, and most of them use the contrib library. Not all of them are active, but there are thousands. And I need to migrate them over to 1.5. Now I know the contrib libraries are not compatible with 1.3+. From what I've read, the big change is related to dynamic var declaration, and there are subtle incompatibilities involving certain scalars. I also looked at this page for information on each library's migration: http://dev.clojure.org/display/community/Where+Did+Clojure.Contrib+Go I'm considering one of two approaches: 1) Run both Clojure 1.2 and 1.5, with all new reports required to use the modular contrib libraries. This would require a change to the backend appservers. 2) Grep the reports and create a list of all the distinct contrib libraries we use. Identify which of the libraries have a modular analog, and replace accordingly. To do this, I would need to check that the function signatures match and the output is remains as expected. I would also still need to run 1.2 running in production and 1.5 in a sandbox to migrate reports over gradually. Asking individual authors to update their reports won't work. Please share your opinions on these approaches or what your experience was in migrating from 1.2 to 1.3+. Also, is there an easier way which I'm not seeing? Thank you. Sol -- -- 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.
Re: Looking to migrate thousands of Clojure applications from 1.2 to 1.5.
It sounds like the vast majority of these apps will simply sit on the shelf, with no need to ever run them again. So, as long as you have a way to run them at need, in an accurate and acceptably prompt manner, you don't have to worry about porting the code. So, if you can keep a Clojure 1.2 environment around _forever_, this may be a plausible strategy. One way of doing this might be to create a VM (eg, using VirtualBox) with all of the necessary apps, libraries, programs, etc. Burn this onto several CDs and save them in various locations. However, if you have to take an existing app and upgrade it in some manner, you will probably want to upgrade the version of Clojure at the same time. In support of this, you might want to find a way to create a mechanized way to recognize issues we have seen before, so that you can get a jump start on upgrading each revived app. -r -- http://www.cfcl.com/rdm Rich Morin r...@cfcl.com http://www.cfcl.com/rdm/resumeSan Bruno, CA, USA +1 650-873-7841 Software system design, development, and documentation -- -- 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.
Re: get rid of reflection in proxy-super?
So, I poked around in the code a little, Dave is indeed right - it appears
to be impossible to remove reflection warnings for proxy-super calling
protected methods.
(defn proxy-call-with-super [call this meth]
(let [m (proxy-mappings this)]
(update-proxy this (assoc m meth nil))
(let [ret (call)]
(update-proxy this m)
ret)))
(defmacro proxy-super
Use to call a superclass method in the body of a proxy method.
Note, expansion captures 'this
{:added 1.0}
[meth args]
`(proxy-call-with-super (fn [] (. ~'this ~meth ~@args)) ~'this ~(name
meth)))
The method call for proxy-super just expands into the dot form, and looking
at the Compiler code that does indeed only search public methods.
There appears to be another problem with proxy-call-with-super: unless I'm
missing something, the second update-proxy should be in a finally block.
Currently if the superclass method throws an exception, the proxy will be
left with the superclass call in its proxy mappings.
On 23 December 2013 16:41, Colin Fleming colin.mailingl...@gmail.comwrote:
But surely proxy-super should be designed to call protected methods? I'd
have to check but I suspect I call other protected methods using it.
On 23 December 2013 14:13, Dave Ray dave...@gmail.com wrote:
Seesaw has the same problem with paintComponent. IIRC, it's because it's
protected. I never found a workaround.
Dave
On Sunday, December 22, 2013, Colin Fleming wrote:
I actually just wrote a long reply detailing how to type hint 'this',
and then noticed that you've already done that! This exact case
(paintComponent) is the one reflection warning I can't get rid of in the
whole Cursive codebase, I can't figure it out either.
On 23 December 2013 01:03, Jim - FooBar(); jimpil1...@gmail.com wrote:
Hi all,
is there any way to get rid of reflection in simmilar looking? Nothing
seems to work...
(proxy [JPanel ActionListener KeyListener] []
(paintComponent [^java.awt.Graphics g]
(let [^JPanel this this]
(proxy-super paintComponent g))
thanks in advance... :)
Jim
--
--
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.
--
--
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.
Re: get rid of reflection in proxy-super?
I've spent a night scratching my head about the behavior of proxy-super in
the presence of exceptions as well. I figured it was something like what
you found, but by that point I just didn't trust proxy that much anymore
and wrote that little bit in Java [1]. If I were a better person I would
have hunted it down and filed a JIRA.
Dave
[1]
https://github.com/daveray/seesaw/blob/develop/jvm/seesaw/ExceptionHandler.java
On Sun, Dec 22, 2013 at 10:26 PM, Colin Fleming colin.mailingl...@gmail.com
wrote:
So, I poked around in the code a little, Dave is indeed right - it appears
to be impossible to remove reflection warnings for proxy-super calling
protected methods.
(defn proxy-call-with-super [call this meth]
(let [m (proxy-mappings this)]
(update-proxy this (assoc m meth nil))
(let [ret (call)]
(update-proxy this m)
ret)))
(defmacro proxy-super
Use to call a superclass method in the body of a proxy method.
Note, expansion captures 'this
{:added 1.0}
[meth args]
`(proxy-call-with-super (fn [] (. ~'this ~meth ~@args)) ~'this ~(name
meth)))
The method call for proxy-super just expands into the dot form, and
looking at the Compiler code that does indeed only search public methods.
There appears to be another problem with proxy-call-with-super: unless I'm
missing something, the second update-proxy should be in a finally block.
Currently if the superclass method throws an exception, the proxy will be
left with the superclass call in its proxy mappings.
On 23 December 2013 16:41, Colin Fleming colin.mailingl...@gmail.comwrote:
But surely proxy-super should be designed to call protected methods? I'd
have to check but I suspect I call other protected methods using it.
On 23 December 2013 14:13, Dave Ray dave...@gmail.com wrote:
Seesaw has the same problem with paintComponent. IIRC, it's because it's
protected. I never found a workaround.
Dave
On Sunday, December 22, 2013, Colin Fleming wrote:
I actually just wrote a long reply detailing how to type hint 'this',
and then noticed that you've already done that! This exact case
(paintComponent) is the one reflection warning I can't get rid of in the
whole Cursive codebase, I can't figure it out either.
On 23 December 2013 01:03, Jim - FooBar(); jimpil1...@gmail.comwrote:
Hi all,
is there any way to get rid of reflection in simmilar looking? Nothing
seems to work...
(proxy [JPanel ActionListener KeyListener] []
(paintComponent [^java.awt.Graphics g]
(let [^JPanel this this]
(proxy-super paintComponent g))
thanks in advance... :)
Jim
--
--
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.
--
--
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
ANN Langohr 2.0.1 is released
Langohr [1] is a feature complete Clojure client for RabbitMQ. 2.0.1 is a bug fix release. Release notes: http://blog.clojurewerkz.org/blog/2013/12/22/langohr-2-dot-0-1-is-released/ 1. http://clojurerabbitmq.info -- MK http://github.com/michaelklishin http://twitter.com/michaelklishin -- -- 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.
New Functional Programming Job Opportunities
Here are some functional programming job opportunities that were posted recently: Chief Data Scientist at Lazada http://functionaljobs.com/jobs/8671-chief-data-scientist-at-lazada Cheers, Sean Murphy FunctionalJobs.com -- -- 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.
