Re: Find file from namespace symbol
But note that a namespace's definition may be spread among several source files, though. So you're just able to localize the main file of the namespace, which contains the (ns) directive, but you can't localize the loaded files participating to the namespace, those you contain (in-ns) directives. 2010/9/29 David Jagoe davidja...@gmail.com Hi all, Anyone know of a utility that returns a absolute filename given a namespace symbol? Actually what I'm trying to do is adjust ring.middleware.reload to only reload source files if they've changed (otherwise I run into problems with session management), so if anyone knows of utilities that already do that, or utilities to help me to determine when a file changes that would be pretty useful too. Cheers, David -- 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.comclojure%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 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
Re: Evaling forms that require
2010/9/30 Phil Hagelberg p...@hagelb.org The following form fails in Clojure 1.0, but was fixed in 1.1: (eval '(do (require 'clojure.inspector) clojure.inspector/inspect)) It used to fail because it tried to compile the whole quoted form, but it couldn't compile the inspect reference because the require hadn't been run yet. I think it's great that it works in 1.1, but I'm boggled as to how it works. Does the compiler split apart certain forms like do and compile/run each form separately? It seems like it wouldn't be possible to make this work without multiple passes, but I'm curious how it's done. Yes, do is given special treatment, I've meet this part of code a while back. It basically just is converted into as many eval() as there are exprs in the do. -Phil -- 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.comclojure%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 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
Re: Some code dramatically slower in Clojure 1.3 Alpha 1?
I believe the performance problems boil down to the abysmal performance of bit-shift-right and bit-and in Clojure 1.3 alpha 1. I'll post this in a separate thread to make sure it gets read. -- 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
Clojure 1.3 alpha 1 report - bitwise operations extremely slow
bitwise-and and bitwise-shift-right and bitwise-shift-left run more than 50 times slower in clojure 1.3 alpha 1 versus clojure 1.2. Could the 1.3 gurus please investigate this? Try something like this to see the difference: (time (doseq [x (range 10)] (bit-shift-left x 1))) This points to another issue with Clojure 1.3. I can't figure out how to determine what is a primitive and what isn't. Are the values produced by range primitives? Are the values produced by bitwise operations primitive? How can I determine this? -- 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
Re: Clojure 1.3 alpha 1 report - bitwise operations extremely slow
With all these reports of performance degradation, it sounds like it would be really useful to have a performance regression suite. -Per On Thu, Sep 30, 2010 at 1:19 PM, Mark Engelberg mark.engelb...@gmail.com wrote: bitwise-and and bitwise-shift-right and bitwise-shift-left run more than 50 times slower in clojure 1.3 alpha 1 versus clojure 1.2. Could the 1.3 gurus please investigate this? Try something like this to see the difference: (time (doseq [x (range 10)] (bit-shift-left x 1))) This points to another issue with Clojure 1.3. I can't figure out how to determine what is a primitive and what isn't. Are the values produced by range primitives? Are the values produced by bitwise operations primitive? How can I determine this? -- 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 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
Changing keys in a map
I have a need to convert maps in the following ways:
Given a map with keyword keys, I need a map with uppercase string keys
- and vice versa.
{ :stuff 42 :like 13 :this 7 } = { STUFF 42 LIKE 13 THIS 7 }
I've come up with various functions to do this but so far they all
feel a bit clunky.
Any suggestions for the simplest, most idiomatic solution?
Here's one pair of functions I came up with...
(defn- to-struct [r] (apply hash-map (flatten (map (fn [[k v]]
[(s/upper-case (name k)) v]) r
(defn- to-rec [m] (apply hash-map (flatten (map (fn [[k v]] [(keyword
(s/lower-case k)) v]) m
s is clojure.string:
(:use [clojure.string :as s :only (lower-case upper-case)])
I came up with some using assoc and/or dissoc as well... didn't like
those much either :)
--
Sean A Corfield -- (904) 302-SEAN
Railo Technologies, Inc. -- http://getrailo.com/
An Architect's View -- http://corfield.org/
If you're not annoying somebody, you're not really alive.
-- Margaret Atwood
--
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
Re: Changing keys in a map
I have a need to convert maps in the following ways:
Given a map with keyword keys, I need a map with uppercase string keys
- and vice versa.
{ :stuff 42 :like 13 :this 7 } = { STUFF 42 LIKE 13 THIS 7 }
What about this -
(into {} (for [[k v] { :stuff 42 :like 13 :this 7 }]
[(.toUpperCase (name k)) v]))
Regards,
BG
--
Baishampayan Ghose
b.ghose at gmail.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
Re: Changing keys in a map
On Sep 30, 2010, at 2:53 AM, Baishampayan Ghose wrote:
I have a need to convert maps in the following ways:
Given a map with keyword keys, I need a map with uppercase string keys
- and vice versa.
{ :stuff 42 :like 13 :this 7 } = { STUFF 42 LIKE 13 THIS 7 }
What about this -
(into {} (for [[k v] { :stuff 42 :like 13 :this 7 }]
[(.toUpperCase (name k)) v]))
One small suggestion based on something Christophe Grand once pointed out:
(defn string-keys [m]
(into (empty m) (for [[k v] m] [(.toUpperCase (name k)) v])))
(defn keyword-keys [m]
(into (empty m) (for [[k v] m] [(keyword (.toLowerCase k)) v])))
This will preserve the type of the map.
(string-keys { :stuff 42 :like 13 :this 7 } ) = {THIS 7, LIKE 13, STUFF
42}
(keyword-keys (string-keys { :stuff 42 :like 13 :this 7 } )) = {:stuff 42,
:like 13, :this 7}
Have all good days,
David Sletten
--
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
Re: Changing keys in a map
On Wed, Sep 29, 2010 at 11:53 PM, Baishampayan Ghose b.gh...@gmail.com wrote:
(into {} (for [[k v] { :stuff 42 :like 13 :this 7 }]
[(.toUpperCase (name k)) v]))
(defn- to-struct [r] (into {} (for [[k v] r] [(.toUpperCase (name k)) v]))
That is certainly nicer than most of my attempts, thank you!
Any reason for .toUpperCase instead of clojure.string/upper-case?
Thanx also to David for the (empty m) tip (but I'm only working with
hash maps at the moments).
--
Sean A Corfield -- (904) 302-SEAN
Railo Technologies, Inc. -- http://getrailo.com/
An Architect's View -- http://corfield.org/
If you're not annoying somebody, you're not really alive.
-- Margaret Atwood
--
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
Re: Changing keys in a map
On Wed, Sep 29, 2010 at 11:53 PM, Baishampayan Ghose b.gh...@gmail.com
wrote:
(into {} (for [[k v] { :stuff 42 :like 13 :this 7 }]
[(.toUpperCase (name k)) v]))
(defn- to-struct [r] (into {} (for [[k v] r] [(.toUpperCase (name k)) v]))
That is certainly nicer than most of my attempts, thank you!
Any reason for .toUpperCase instead of clojure.string/upper-case?
clojure.contrib.string/upper-case is a trivial wrapper over
.toUpperCase. In my humble opinion it's perfectly OK to use such
static Java methods directly instead of writing trivial wrappers
around them.
This also helps in avoiding the contrib dependency.
Regards,
BG
--
Baishampayan Ghose
b.ghose at gmail.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
Re: Changing keys in a map
On Thu, Sep 30, 2010 at 12:24 AM, Baishampayan Ghose b.gh...@gmail.com wrote: This also helps in avoiding the contrib dependency. Good point. Thanx BG. -- Sean A Corfield -- (904) 302-SEAN Railo Technologies, Inc. -- http://getrailo.com/ An Architect's View -- http://corfield.org/ If you're not annoying somebody, you're not really alive. -- Margaret Atwood -- 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
Re: Changing keys in a map
On Thu, Sep 30, 2010 at 12:24 AM, Baishampayan Ghose b.gh...@gmail.com wrote: clojure.contrib.string/upper-case is a trivial wrapper over .toUpperCase. In my humble opinion it's perfectly OK to use such static Java methods directly instead of writing trivial wrappers around them. Except that if you use .toUpperCase, you have to remember to type hint the input. Any time you call a Java method without type hinting, you take a significant performance hit. The wrapper function takes care of that for you. -- 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
Re: Changing keys in a map
On Thu, Sep 30, 2010 at 12:18 AM, Meikel Brandmeyer m...@kotka.de wrote: (defn to-string-keys [m] (zipmap (map (comp clojure.string/upper-case name) (keys m)) (vals m))) That's very similar to one of my attempts and... I don't know... I just don't like it as much. Splitting the map into two streams and zipping them back together just doesn't feel as 'nice' and making one pass over the key/value pairs of the map... Interesting choice of comp - I think I went with #(s/upper-case (name %)) - I guess comp is more idiomatic, functionally? -- Sean A Corfield -- (904) 302-SEAN Railo Technologies, Inc. -- http://getrailo.com/ An Architect's View -- http://corfield.org/ If you're not annoying somebody, you're not really alive. -- Margaret Atwood -- 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
Re: Changing keys in a map
On Thu, Sep 30, 2010 at 12:30 AM, Mark Engelberg mark.engelb...@gmail.com wrote: Except that if you use .toUpperCase, you have to remember to type hint the input. Any time you call a Java method without type hinting, you take a significant performance hit. The wrapper function takes care of that for you. Good to know, thanx Mark. Keep 'em coming folks, this is exactly what I was hoping for when I posted the question. -- Sean A Corfield -- (904) 302-SEAN Railo Technologies, Inc. -- http://getrailo.com/ An Architect's View -- http://corfield.org/ If you're not annoying somebody, you're not really alive. -- Margaret Atwood -- 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
Re: Changing keys in a map
On Sep 30, 2010, at 3:40 AM, Sean Corfield wrote: On Thu, Sep 30, 2010 at 12:30 AM, Mark Engelberg mark.engelb...@gmail.com wrote: Except that if you use .toUpperCase, you have to remember to type hint the input. Any time you call a Java method without type hinting, you take a significant performance hit. The wrapper function takes care of that for you. Good to know, thanx Mark. Keep 'em coming folks, this is exactly what I was hoping for when I posted the question. Huh?! How many solutions do you want? You're starting to annoy me Sean. Hmm, I guess you must really be alive. :) If you're not annoying somebody, you're not really alive. -- Margaret Atwood -- 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
Re: Clojure 1.3 alpha 1 report - bitwise operations extremely slow
Some more data points on 1.3 alpha 1 performance: bit operations appear to be much faster on hinted args. For example, (defn unhinted-shift [n] (bit-shift-left n 1)) (defn ^:static hinted-shift [^long n] (bit-shift-left n 1)) user= (time (doseq [x (range 10)] (unhinted-shift x))) Elapsed time: 2533.935459 msecs user= (time (doseq [x (range 10)] (hinted-shift x))) Elapsed time: 33.889503 msecs On the other hand, / seems to be much faster on unhinted args. (defn unhinted-divide [n] (/ n 2)) (defn ^:static hinted-divide [^long n] (/ n 2)) user= (time (doseq [x (range 10)] (unhinted-divide x))) Elapsed time: 37.612043 msecs user= (time (doseq [x (range 10)] (hinted-divide x))) Elapsed time: 2687.836862 msecs I checked the enhanced operations (+, -, *, inc, dec) and their prime counterparts (+', -', *', inc', dec'). All 10 perform equally fast with unhinted and hinted args. On Sep 30, 12:19 am, Mark Engelberg mark.engelb...@gmail.com wrote: bitwise-and and bitwise-shift-right and bitwise-shift-left run more than 50 times slower in clojure 1.3 alpha 1 versus clojure 1.2. Could the 1.3 gurus please investigate this? Try something like this to see the difference: (time (doseq [x (range 10)] (bit-shift-left x 1))) This points to another issue with Clojure 1.3. I can't figure out how to determine what is a primitive and what isn't. Are the values produced by range primitives? Are the values produced by bitwise operations primitive? How can I determine this? -- 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
Re: Clojure 1.3 alpha 1 report - bitwise operations extremely slow
Did some more testing, and I'm now convinced that the slow performance of the bitwise operators in clojure 1.3 alpha 1 is due to the inline declaration in the definition of the bitwise ops. If you remove the inline declaration, performance is as it should be. So something about the way inline works is screwing with performance in 1.3 alpha 1. -- 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
Re: Changing keys in a map
Hi, On 30 Sep., 09:37, Sean Corfield seancorfi...@gmail.com wrote: That's very similar to one of my attempts and... I don't know... I just don't like it as much. Splitting the map into two streams and zipping them back together just doesn't feel as 'nice' and making one pass over the key/value pairs of the map... The two passes are an argument. I - personally - like the split, because it makes clear that the values are not touched, while they are carried as dead weight in the one solutions. Interesting choice of comp - I think I went with #(s/upper-case (name %)) - I guess comp is more idiomatic, functionally? Dunno. I don't use it very often. I normally also use #() but in this case it was nice and clean. Sincerely Meikel -- 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
Re: Some code dramatically slower in Clojure 1.3 Alpha 1?
As a side note, I notice that in clojure 1.3, bit-shift-left now provides wraparound logic with no warning if the first input is a long (as opposed to a bigint). Wouldn't it be more consistent if bit-shift-left provided an overflow error for long inputs that shift so much they overflow? Should there also be an unchecked-bit-shift-left and a bit-shift-left' ? -- 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
anonymous fn or partial?
Hi, Newbie here with a simple question: what is the preferred way of mapping a function to a seq? Use an anonymous function or use a partial? Consider this: user= (map (fn [n] (+ 2 n)) [1 2 3 4 5]) (3 4 5 6 7) user= (map (partial + 2) [1 2 3 4 5]) (3 4 5 6 7) user= I know that the answer is likely to be it depends. I am just interested in whether one is more idiomatic/functional than the other, performance issues that one approach may have that the other one doesn't, etc. Thanks in advance, PS: I'm even tempted to say that if one could do (map (+ 2) [1 2 3 4 5]) it would look even better :) U -- 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
Re: anonymous fn or partial?
I ask myself that from time to time. I tend to use (partial + 2) because I think its easier to read. The (+ 2) bit is intressting. That would be automatic currying, you get that in other languages. It is not possible in Clojure becaus there is no limit to how many args a clojure function can take. Think about it for a moment. What should ((+ 2) 1) return? A function with the next elment add on to it? So it would return a function that adds 3 to its args or the result? How can you know what the caller wants? Thats the reason for partial. I would have liked a shorter word for partial but its not really importend. On Sep 30, 9:48 am, Ulises ulises.cerv...@gmail.com wrote: Hi, Newbie here with a simple question: what is the preferred way of mapping a function to a seq? Use an anonymous function or use a partial? Consider this: user= (map (fn [n] (+ 2 n)) [1 2 3 4 5]) (3 4 5 6 7) user= (map (partial + 2) [1 2 3 4 5]) (3 4 5 6 7) user= I know that the answer is likely to be it depends. I am just interested in whether one is more idiomatic/functional than the other, performance issues that one approach may have that the other one doesn't, etc. Thanks in advance, PS: I'm even tempted to say that if one could do (map (+ 2) [1 2 3 4 5]) it would look even better :) U -- 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
Re: Changing keys in a map
#(s/upper-case (name %)) Good and clear in this case. #(- % name s/upper-case) I think that would be nice if there were three functions. (comp s/upper-case name) I think its hard to read for beginners, because you have to read it backwards and no parens to indicate but you could say that the have to get used to it. On Sep 30, 10:09 am, Meikel Brandmeyer m...@kotka.de wrote: Hi, On 30 Sep., 09:37, Sean Corfield seancorfi...@gmail.com wrote: That's very similar to one of my attempts and... I don't know... I just don't like it as much. Splitting the map into two streams and zipping them back together just doesn't feel as 'nice' and making one pass over the key/value pairs of the map... The two passes are an argument. I - personally - like the split, because it makes clear that the values are not touched, while they are carried as dead weight in the one solutions. Interesting choice of comp - I think I went with #(s/upper-case (name %)) - I guess comp is more idiomatic, functionally? Dunno. I don't use it very often. I normally also use #() but in this case it was nice and clean. Sincerely Meikel -- 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
Re: Clojure 1.3 alpha 1 report - bitwise operations extremely slow
So if we fix that all the other peoples problems fix themselfs :) Nice work Mark. On Sep 30, 10:06 am, Mark Engelberg mark.engelb...@gmail.com wrote: Did some more testing, and I'm now convinced that the slow performance of the bitwise operators in clojure 1.3 alpha 1 is due to the inline declaration in the definition of the bitwise ops. If you remove the inline declaration, performance is as it should be. So something about the way inline works is screwing with performance in 1.3 alpha 1. -- 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
Re: anonymous fn or partial?
Hi, On 30 Sep., 09:48, Ulises ulises.cerv...@gmail.com wrote: user= (map (fn [n] (+ 2 n)) [1 2 3 4 5]) (3 4 5 6 7) user= (map (partial + 2) [1 2 3 4 5]) (3 4 5 6 7) user= You can also consider the following: (map #(+ % 2) [1 2 3 4]), which is also very clear. I personally almost never use partial. (partial + 2) is not entirely equivalent to #(+ 2 %) - actually it's #(apply + 2 %) - but for 95% of my use cases the #() form is sufficient, shorter, easier to read for me. partial is just a special case of #(). So in the end it's probably personal preference. Sincerely Meikel -- 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
Re: An Emacs command to close the various balanced expressions in Clojure
That's really is a cool idea of feature. I intend to add such a feature as well in ccw, will certainly be a very useful command in the default mode ! (and also in the REPL ? hmmm ) 2010/9/30 blais bl...@furius.ca It's too small to be an Emacs package, but I've forked it into its own file and a few improvements have been made to it. Here: http://furius.ca/pubcode/pub/conf/common/elisp/blais/close-matching.el ( It is linked from this page: http://furius.ca/pubcode/ ) On Sep 28, 6:03 pm, .Bill Smith william.m.sm...@gmail.com wrote: Blais, Thank you for contributing the emacs code. I have been looking for the same thing, for the reasons you and Laurent PETIT described. Bill Smith Austin, Texas -- 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.comclojure%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 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
Re: anonymous fn or partial?
You can also consider the following: (map #(+ % 2) [1 2 3 4]), which I did consider #(...) but didn't include it in the example as I tend to prefer (fn [..] ...). For some reason my brain parses (fn...) much better than #() (it looks more explicit). If partial is a special case of #(..) could there be then a performance penalty of using apply instead of a direct call? My question stemmed from the fact that sometimes I find myself mapping functions which are just partial applications of the same function and perhaps having a bunch of partials lying around would make my code read better. Cheers for all the replies, U -- 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
Re: anonymous fn or partial?
Think about it for a moment. What should ((+ 2) 1) return? A function with the next elment add on to it? So it would return a function that adds 3 to its args or the result? How can you know what the caller wants? That's a very good point which I hadn't considered. Perhaps the evaluation result could depend on the context? E.g. (def add-2 (partial + 2)) (def add-3 (add-2 1)) Then, hopefully: (add-3 3) ; 6 (add-3); 3 U -- 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
Re: anonymous fn or partial?
Hi, On 30 Sep., 12:10, Ulises ulises.cerv...@gmail.com wrote: My question stemmed from the fact that sometimes I find myself mapping functions which are just partial applications of the same function and perhaps having a bunch of partials lying around would make my code read better. Well. In case it scratches your itch, I don't see a reason why not to use partial. (Performance implications of the apply should be a concern when the prove to be a problem) Sincerely Meikel -- 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
instance? accepting only one argument
Hello,
Can somebody explains me why the instance? function accepts one
argument whereas the documentation states Usage: (instance? c x)
For instance:
user= *clojure-version*
{:interim true, :major 1, :minor 2, :incremental 0, :qualifier
master}
user= (instance? Integer)
false
Thanks in advance.
--
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
Re: anonymous fn or partial?
The two styles are ok. Matter of taste. (partial ...) have probably a slight cost I wouldn't worry about except if profiler tells me to worry. The (partial...) style is called point-less, because you directly manipulate the arrows and not the points. It is the same kind of question as : should you use composition or call (f (g x))? Should I use the do-monad notation or a clever combination of m-bind, map, and composition? No good answer. Do what you like best in each situation. If you want to have something looking like (+ 2) with multiple args possible, I would advocate the best way might be to add a reader macro to clojure expanding to partial. #p(+ 2) for example. It is a better idea than using having evaluation depending of the context, IMHO. -- 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
Re: anonymous fn or partial?
The two styles are ok. Matter of taste. (partial ...) have probably a slight cost I wouldn't worry about except if profiler tells me to worry. Excellent. If you want to have something looking like (+ 2) with multiple args possible, I would advocate the best way might be to add a reader macro to clojure expanding to partial. #p(+ 2) for example. It is a better idea than using having evaluation depending of the context, IMHO. I guess that this has just led me into learning yet another bit which I wasn't even aware of! Thanks! U -- 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
Re: instance? accepting only one argument
On 30 Sep 2010, at 11.36 am, K. wrote:
Can somebody explains me why the instance? function accepts one
argument whereas the documentation states Usage: (instance? c x)
What an interesting question. If you try and emulate the behaviour yourself by
creating a separate fn with a different name, it works as you might expect:
(def
^{:arglists '([^Class c x])
:doc Evaluates x and tests if it is an instance of the class
c. Returns true or false
:added 1.0}
eggs? (fn eggs? [^Class c x] (. c (isInstance x
#'user/eggs?
user= (eggs?)
IllegalArgumentException Wrong number of args (0) passed to: user$eggs-QMARK-
clojure.lang.AFn.throwArity (AFn.java:439)
user= (eggs? Integer)
IllegalArgumentException Wrong number of args (1) passed to: user$eggs-QMARK-
clojure.lang.AFn.throwArity (AFn.java:439)
user= (eggs? java.lang.Long 1)
true
This fn must be created deep down in the guts of the Clojure implementation
where things are murky and magical...
I assume that x defaults to nil in the case where the number of args passed to
instance? is less than the required arity (2). However, that's just a guess...
Can anyone shed some more light?
Sam
---
http://sam.aaron.name
--
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
Re: Planet Clojure Feed Broken
Hello Stefan Hübner at Wed, 29 Sep 2010 10:38:45 +0200 wrote: SH (sorry to use this channel) SH I just wanted to notice the maintainers of Planet Clojure, that it's RSS SH feed is outdated. The web site shows more recent articles than the feed SH does. Yes, we know - there is a problem with PlanetPlanet. Baishampayan Ghose is trying to fix this, but with no much success yet :-( SH Besides of that: Thank you for this really handy service! You're welcome ;-) If you'll find new blog, not listed in planet, just send address to me or B.Ghose - we'll add it to planet -- With best wishes, Alex Ott, MBA http://alexott.blogspot.com/ http://alexott.net http://alexott-ru.blogspot.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
Handling keystrokes
I have a keyboard paste problem, but I think it has more general interest. When the user types Control V in a JTextPane, data from the clipboard will be pasted into the text. I want to act on that pasted text. I can easily capture the keystroke. The problem is that my capture takes place BEFORE the actual paste. What do I do to make my handler occur AFTER the paste? Bill -- 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
Re: Handling keystrokes
You have probably mistaken this clojure group for another ... 2010/9/30 WoodHacker ramsa...@comcast.net I have a keyboard paste problem, but I think it has more general interest. When the user types Control V in a JTextPane, data from the clipboard will be pasted into the text. I want to act on that pasted text. I can easily capture the keystroke. The problem is that my capture takes place BEFORE the actual paste. What do I do to make my handler occur AFTER the paste? Bill -- 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.comclojure%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 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
Re: Find file from namespace symbol
Thanks chaps, that's what I was looking for. Luckily I came across an easier solution to the underlying problem (i.e. using session and reload middleware in ring): http://groups.google.com/group/ring-clojure/browse_thread/thread/a0dffa86be0896ff# basically, using defonce allows me to create memory storage that persists across namespace reloads. Thanks again. Cheers, David -- 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
Re: Changing keys in a map
I wrote a blog recently on a helper function I use for stuff like this
called mapmap:
http://tech.puredanger.com/2010/09/24/meet-my-little-friend-mapmap/
mapmap takes a function to generate keys and a function to generate
values, applies them to a sequence, and zipmaps their results. Using
a map as the sequence, you'd do something like:
(mapmap #(upper-case (key %)) identity m)
If you wanted to upper-case the values, mapmap uses identity as a
default key function, so you'd do:
(mapmap #(upper-case (val %)) m)
Someone suggested on twitter that a helper function over it
specifically for working from an existing map and splitting the key
and val might be nicer. mapmap on map would of course be:
(defn mapmapmap [kf vf m]
(mapmap (comp kf key) (comp vf val) m))
Then you could use the cleaner form for your needs:
(mapmapmap upper-case identity { abc def ghi jkl })
{GHI jkl, ABC def}
From a readability perspective, I think that's nice. Feel free to
throw plenty of rocks at the function names and impl though. :)
On Sep 30, 1:44 am, Sean Corfield seancorfi...@gmail.com wrote:
I have a need to convert maps in the following ways:
Given a map with keyword keys, I need a map with uppercase string keys
- and vice versa.
{ :stuff 42 :like 13 :this 7 } = { STUFF 42 LIKE 13 THIS 7 }
I've come up with various functions to do this but so far they all
feel a bit clunky.
Any suggestions for the simplest, most idiomatic solution?
Here's one pair of functions I came up with...
(defn- to-struct [r] (apply hash-map (flatten (map (fn [[k v]]
[(s/upper-case (name k)) v]) r
(defn- to-rec [m] (apply hash-map (flatten (map (fn [[k v]] [(keyword
(s/lower-case k)) v]) m
s is clojure.string:
(:use [clojure.string :as s :only (lower-case upper-case)])
I came up with some using assoc and/or dissoc as well... didn't like
those much either :)
--
Sean A Corfield -- (904) 302-SEAN
Railo Technologies, Inc. --http://getrailo.com/
An Architect's View --http://corfield.org/
If you're not annoying somebody, you're not really alive.
-- Margaret Atwood
--
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
clojure-mode bug in Emacs
Has anyone else noticed this? In Emacs clojure-mode, indentation and syntax coloring can get out of whack after a string that contains an open parenthesis. In the example below, (+ 1 2) is indented incorrectly. (defn f [x] Blah blah blah. (parenthetical expression (+ 1 2)) -- 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
Bug with map keys containing quotes in clojure.contrib.json
Hi,
c.c.json/json-str seems to handle maps with keys containing quotes
incorrectly:
(println (json-str {\ 1}))
{:1}
...while I (and my parsers) would expect {\:1}.
I'd much rather report this on Assembla than here, but I seem to be
needing a CA to post a ticket there, and I'm in way too big hurry to
sign the CA now... I have the feeling that Clojure makes it too
difficult to just report a bug in it or Contrib (as opposed to
submitting a fix).
Thanks,
- Daniel
--
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
Re: Bug with map keys containing quotes in clojure.contrib.json
I forgot to add that this happens both with contrib 1.2.0 and 1.3- alpha1. Daniel -- 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
Re: Evaling forms that require
There it is : http://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/Compiler.java#L5984 The magic only happen for dos which are top level forms 2010/9/30 Phil Hagelberg p...@hagelb.org On Wed, Sep 29, 2010 at 11:02 PM, Laurent PETIT laurent.pe...@gmail.com wrote: The following form fails in Clojure 1.0, but was fixed in 1.1: (eval '(do (require 'clojure.inspector) clojure.inspector/inspect)) Yes, do is given special treatment, I've meet this part of code a while back. It basically just is converted into as many eval() as there are exprs in the do. Fascinating; thanks. It's a shame that forms with implicit do don't get treated similarly, but I suppose that's a sidetrack for which it would be very difficult to get all the edge cases for very little gain. (eval '(when true (require 'clojure.inspector) clojure.inspector/inspect)) Exception in thread main java.lang.ClassNotFoundException: clojure.inspector (core.clj:6) -Phil -- 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.comclojure%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 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
Re: Bug with map keys containing quotes in clojure.contrib.json
On 30 Wrz, 20:46, Steve Purcell st...@sanityinc.com wrote: You can file the bug as a support ticket without a CA here: http://www.assembla.com/spaces/clojure/support/tickets Thanks, I've reported it as a contrib support ticket. I wasn't aware of this functionality. Daniel -- 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
Re: Problems Running tests with fixtures
Just in case anyone comes across this, I did get around it. In fig. 2 I was
trying to run (use-fixtures) twice. One with a :once, and one with :each. I
just commented out the :once call and executed manually.
*(use-fixtures :once login-test/test-fixture-shell )*
*(use-fixtures :each login-test/test-fixture-db )*
*(test-fixture-shell nil)*
*;;(use-fixtures :once login-test/test-fixture-shell )*
*(use-fixtures :each login-test/test-fixture-db )*
Tim
On Tue, Sep 28, 2010 at 6:08 PM, Timothy Washington twash...@gmail.comwrote:
Oh that's my mistake in the example code. My actual code does have an (is )
function. The example code should look like:
(deftest test-code []
*(is (= 5 5)) *
)
Tim
On Tue, Sep 28, 2010 at 12:29 PM, Kevin Downey redc...@gmail.com wrote:
your test has no (is ...)
On Mon, Sep 27, 2010 at 5:16 PM, Timothy Washington twash...@gmail.com
wrote:
I suppose I've been looking at this code for too long, so I need a 2nd
pair
of eyes on it. I'm not getting some 'test.is' code to run. I'm trying
to run
the tests as in fig. 1. Suppose the tests are defined in a file called
utests.clj (fig. 2).
(use 'clojure.test)
(require 'utests)
(run-tests 'utests)
fig. 1 - run attempts
(ns utests)
(defn test-fixture-1 [test-func]
(setup-code)
(test-func)
(teardown-code)
)
(use-fixtures :each test-fixture-1)
(deftest test-code []
(= 5 5))
)
fig. 2 - utests.clj
Ran 0 tests containing 0 assertions.
0 failures, 0 errors.
{:type :summary, :test 0, :pass 0, :fail 0, :error 0}
fig. 3 - output
Q. The thing that I'm missing is...
Thanks in advance
Tim
--
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.comclojure%2bunsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--
And what is good, Phaedrus,
And what is not good—
Need we ask anyone to tell us these things?
--
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.comclojure%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 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
Any clean way to avoid explicit recursion when creating nested loops?
I was discussing this on the clojure channel, and it seems as though avoiding explicit recursion is the idiomatic thing to do. Is there a better way to define a function that loops over an arbitrary number of sequences in a nested fashion, similar to the 'for' macro, without relying on recursion? This is the current approach, using recursion: (defn nested [ seqs] returns lazy 'for'-like nesting of a seq of seqs. (letfn [(nestrec [prefix [list deeper-lists]] (if deeper-lists (mapcat #(nestrec (conj prefix %) deeper-lists) list) (map #(conj prefix %) list)))] (nestrec [] seqs))) so (nested (range) [:a :b]) returns [[0 :a][0 :b] [1 :a] [1 :b] [2 :a] ... ] -- 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
Re: Idiomatic Way to Build String or Simply Use StringBuilder
Mark Engelberg mark.engelb...@gmail.com writes: str uses a string builder behind the scenes, so it's efficient this way. If the `str' implementation didn't take the input sequence to be lazy, it could figure out how long the resulting string needed to be, and construct the StringBuilder using the single-integer constructor, ensuring that no reallocation and copying occurs. Some temporary allocation would still be necessary to hold the Object-to-String projection, as `str' calls Object#toString() on each argument, rather than assuming the arguments are already of type String. -- Steven E. Harris -- 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
Re: Any clean way to avoid explicit recursion when creating nested loops?
That's perfect, thanks! On Sep 30, 4:55 pm, Mark Engelberg mark.engelb...@gmail.com wrote: clojure.contrib.cartesian-product does what your nested function does, but more efficiently, using iteration rather than recursion. -- 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
Calling macros by var
So I noticed some curious behaviour:
(defmacro foo [body] {:env env :form form :body body})
= #'user/foo
(#'user/foo :body)
= java.lang.IllegalArgumentException: Wrong number of args (1)
passed to: user$foo (NO_SOURCE_FILE:0)
(#'user/foo :form :env :body)
= {:env :env, :form :form, :body :body}
(#'user/foo :form :env body)
= Unable to resolve symbol: body in this context
So it appears when you call a macro by its var, it acts just like a
function, even though its metadata says it should be a macro.
(:macro (meta #'foo))
= true
I suspect the answer may just be yeah... that's not something you
should do with macros, but I'm curious. I suppose the compiler only
checks the :macro metadata when it's literally in the call position
rather than when there's indirection through calling var?
-Phil
--
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
Re: Problems Running tests with fixtures
On Thu, Sep 30, 2010 at 2:44 PM, Timothy Washington twash...@gmail.com wrote:
Just in case anyone comes across this, I did get around it. In fig. 2 I was
trying to run (use-fixtures) twice. One with a :once, and one with :each.
I just tried that and it worked fine for me:
(ns utest)
(use 'clojure.test)
(defn f [x] (println f before) (x) (println f after))
(use-fixtures :each f)
(defn g [x] (println g1)(x)(println g2))
(use-fixtures :once g)
(deftest test-me (is ( = 1 1)))
(deftest test-me-2 (is ( = 2 2 )))
(run-tests)
Produced:
Testing utest
g1
f before
f after
f before
f after
g2
Ran 2 tests containing 2 assertions.
0 failures, 0 errors.
{:type :summary, :pass 2, :test 2, :error 0, :fail 0}
I'm using Clojure 1.3.0 master.
--
Sean A Corfield -- (904) 302-SEAN
Railo Technologies, Inc. -- http://getrailo.com/
An Architect's View -- http://corfield.org/
If you're not annoying somebody, you're not really alive.
-- Margaret Atwood
--
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
Re: Clojure 1.3 alpha 1 report - bitwise operations extremely slow
As with most microbenchmarks you're measuring the test more than the subject. In the above case the seq generation dominates. Compare the following on my machine: user= (time (doseq [x (range 10)] (bit-shift-left x 1))) Elapsed time: 3531.198 msecs nil user= (time (dotimes [x 10] (bit-shift-left x 1))) Elapsed time: 3.744 msecs nil Beyond the seq issue there is a further (very small) penalty due to seqs working with objects, thus x from the range seq is a Long object, not a primitive long. You can see the implementation differences of shiftLeft here: http://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/Numbers.java#L425 On Sep 29, 11:19 pm, Mark Engelberg mark.engelb...@gmail.com wrote: bitwise-and and bitwise-shift-right and bitwise-shift-left run more than 50 times slower in clojure 1.3 alpha 1 versus clojure 1.2. Could the 1.3 gurus please investigate this? Try something like this to see the difference: (time (doseq [x (range 10)] (bit-shift-left x 1))) This points to another issue with Clojure 1.3. I can't figure out how to determine what is a primitive and what isn't. Are the values produced by range primitives? Are the values produced by bitwise operations primitive? How can I determine this? -- 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
Re: Clojure 1.3 alpha 1 report - bitwise operations extremely slow
On Thu, Sep 30, 2010 at 9:13 PM, ataggart alex.tagg...@gmail.com wrote: As with most microbenchmarks you're measuring the test more than the subject. In the above case the seq generation dominates. Compare the following on my machine: user= (time (doseq [x (range 10)] (bit-shift-left x 1))) Elapsed time: 3531.198 msecs nil user= (time (dotimes [x 10] (bit-shift-left x 1))) Elapsed time: 3.744 msecs nil But if you replace the bit-shift-left operation with some other arithmetic operation in the doseq expression, it is quite fast, thus disproving your assertion that the slowdown is caused by the overhead of doseq. Furthermore, as we've already discussed, type hinting the x or removing the inline delcaration from bit-shift-left makes the problem go away -- inside the doseq expression. So, if it is true that range produces objects and dotimes produces primitive longs, then I believe that it is the odd interaction between bit-shift-left's inlining and long objects (as opposed to primitives) that is causing the disparity in your measurements, not something inherent in the mechanism of doseq vs dotimes. -- 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
Re: Changing keys in a map
On Thu, Sep 30, 2010 at 12:52 AM, David Sletten da...@bosatsu.net wrote: Huh?! How many solutions do you want? You're starting to annoy me Sean. Sorry dude. I think it's really insightful to see lots of different solutions to small point problems like this when you're learning a language - particularly when the issue of idiom is being discussed. I've certainly found this thread educational and I hope I'm not annoying too many people :) Things I'm finding particularly helpful: * into / for * comp vs #() vs - * split a map and zip it vs a single pass with a more complex function The into / for thing was great because it's something that seems very Clojurish that I wouldn't have thought of without input. I'm very excited about Clojure. I think it's going to be core to my team's work over the next couple of years. I haven't been able to do serious functional programming for about three decades but Clojure really provides that option. We're already using Scala for certain performance-critical pieces of our system but it's not a language that I can present to most of my web developers - they're used to dynamic scripting languages, no type system, no compile/deploy/run cycle. -- Sean A Corfield -- (904) 302-SEAN Railo Technologies, Inc. -- http://getrailo.com/ An Architect's View -- http://corfield.org/ If you're not annoying somebody, you're not really alive. -- Margaret Atwood -- 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
