Re: Changing keys in a map
On Oct 1, 2010, at 1:57 AM, Sean Corfield wrote: > On Thu, Sep 30, 2010 at 12:52 AM, David Sletten 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 :) > Sean, Sean...I was just making fun of your signature. :) Keep up the questions! > > "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: Calling macros by var
On 01.10.2010, at 03:07, Phil Hagelberg wrote: > 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? Right. I use this for macro testing from the REPL for convenience, so I hope this won't change. Konrad. -- 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 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
Re: Clojure 1.3 alpha 1 report - bitwise operations extremely slow
On Thu, Sep 30, 2010 at 9:13 PM, ataggart 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: 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 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: Idiomatic Way to Build String or Simply Use StringBuilder
Everybody, thanks for all your responses. conj to vector feels good
so that's what I'm playing with now. Michael, in answer to your
question, and this may be more detail than you bargained for, I'm
playing around with a little state machine parser. It actually
doesn't do much now, but baby steps as I learn clojure. Eventually, I
want it to make distinctions between numbers that pass through and
numbers that are transformed. Am not crazy about having to add a
space at the end of the original string and welcome edifying comments.
(ns test-test.parse
(:use [clojure.contrib.string :only (split)]))
(defn parse-char [m c]
(condp = (:state m)
:degree (cond
(Character/isDigit c) (assoc m :degree (+ (* (:degree
m) 10) (Character/digit c 10)))
(Character/isWhitespace c) (assoc
m :state :whitespace :buf (conj (:buf m) (:degree m) " ") :degree 0))
:whitespace (cond
(Character/isDigit c) (assoc
m :state :degree :degree (+ (* (:degree m) 10) (Character/digit c
10)))
(Character/isWhitespace c) m)))
(defn parse [s]
(let [m (reduce parse-char {:state :degree :degree 0 :buf []} (str s
" "))]
(apply str (:buf m
(println (parse "1 2 33"))
On Sep 30, 12:15 am, Michael Gardner wrote:
> On Sep 29, 2010, at 11:01 PM, HiHeelHottie wrote:
>
> > What if you are appending over different lines of code?
>
> Could you give an example of what you're trying to do? Mutable strings are
> almost never necessary, in my experience.
--
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 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
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: Any clean way to avoid explicit recursion when creating nested loops?
That's perfect, thanks! On Sep 30, 4:55 pm, Mark Engelberg 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
Re: Idiomatic Way to Build String or Simply Use StringBuilder
Mark Engelberg 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?
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
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: 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 wrote:
> 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 wrote:
>
>> your test has no (is ...)
>>
>> On Mon, Sep 27, 2010 at 5:16 PM, Timothy Washington
>> 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.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.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: clojure-mode bug in Emacs
On Sep 30, 8:26 am, ".Bill Smith" wrote: > 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. Not happening with the version i am using. Do you use paredit? -- 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 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: Bug with map keys containing quotes in clojure.contrib.json
You can file the bug as a support ticket without a CA here:
http://www.assembla.com/spaces/clojure/support/tickets
-Steve
Daniel Janus writes:
> 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: 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 > On Wed, Sep 29, 2010 at 11:02 PM, Laurent PETIT > 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.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
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
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: Evaling forms that require
On Wed, Sep 29, 2010 at 11:02 PM, Laurent PETIT 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.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
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 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
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: Handling keystrokes
You have probably mistaken this clojure group for another ... 2010/9/30 WoodHacker > 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 -- 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: anonymous fn or partial?
> Note that you can't make readermacros yet. It's a supported in CL not > in Clojure but maybe in future versions how knows. I meant, if you want to modify Clojure to allow a shorter notation for partial application, it is better to add a reader macro (directly in Clojure) than to change evaluation semantic I am not sure it is a good idea anyway... -- 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
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: anonymous fn or partial?
> > 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! Note that you can't make readermacros yet. It's a supported in CL not in Clojure but maybe in future versions how knows. I think the have random nummer of args vs currying its a good traidoff. -- 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: 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
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?
Hi, On 30 Sep., 12:10, Ulises 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
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?
> 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: 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 > 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" 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.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?
Hi, On 30 Sep., 09:48, Ulises 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: 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 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: 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 wrote: > Hi, > > On 30 Sep., 09:37, Sean Corfield 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: 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 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
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: 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
Re: Changing keys in a map
Hi, On 30 Sep., 09:37, Sean Corfield 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
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: 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 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: 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 > 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: Changing keys in a map
On Thu, Sep 30, 2010 at 12:30 AM, Mark Engelberg 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 Thu, Sep 30, 2010 at 12:18 AM, Meikel Brandmeyer 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:24 AM, Baishampayan Ghose 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:24 AM, Baishampayan Ghose 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 Wed, Sep 29, 2010 at 11:53 PM, Baishampayan Ghose
> 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
Hi, On 30 Sep., 09:08, Sean Corfield wrote: > 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). In that case... Just for the record: (defn to-string-keys [m] (zipmap (map (comp clojure.string/upper-case name) (keys m)) (vals m))) 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: Changing keys in a map
On Wed, Sep 29, 2010 at 11:53 PM, Baishampayan Ghose 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 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
