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 t
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 th
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
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 ti
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
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 step
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
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 :en
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.
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 cons
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
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?
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/te
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
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 becau
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
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
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
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
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 j
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 recei
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
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 memor
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
> past
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 BE
> 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 evaluatio
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 proble
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 nam
> > 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.
>
>
> 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 rea
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 yo
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 a
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 y
> 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 evaluatio
> 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 t
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 imp
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
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 defini
#(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 hav
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.
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
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 th
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
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 wor
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)))
"
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.
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 t
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 a
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 .to
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 someb
> 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, t
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...
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!
An
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 a
54 matches
Mail list logo
