This looks very useful, thanks!
--
--
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
Hi,
I have thought long which language to use for my current project. My main
choices were Scala and Clojure, and I decided on Clojure mainly because I
need to run substantial amounts of my code to run on both the JVM and in
the browser.
So now I am approaching the parts of my project that ne
Thanks a lot. Somehow I believed firmly (str nil) will be "nil" and didn't
even try it out ?!
On Thursday, January 3, 2013 11:47:15 PM UTC, Ben wrote:
>
> the type of nil is nil, and (str nil) is empty.
>
> On Thu, Jan 3, 2013 at 3:45 PM, Steven Obua >
> wro
Hi,
I am using Clojure 1.4.0, and am trying to debug some buggy(?) code I have.
In particular, I am trying to print information about some computed result,
like that:
(let [result (btree/btree-indexed-find pool address address-count name)]
(let [_ (println (str "result class: '" (type r
Thanks a lot for this comment. It is probably a good idea to flag "subvec"
in the docs as dangerous operation that does not really return a full
vector.
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@goo
I am using Clojure 1.4.0. It seems that reduce-kv does not work together
with subvec.
For example:
(reduce-kv (fn [v index u] (+ v (* index u))) [10 3 5])
results in 13, but
(reduce-kv (fn [v index u] (+ v (* index u))) 0 (subvec [11 10 3 5] 1 3))
yields the following exception:
No implemen
Jay's example has convinced me that redefinition is not a good idea anyway,
because #(f) is not always equivalent to f when (count [f]) is 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.co
I doubt that this change would break anything, as the case that has changed has
been pretty useless so far.
On 4 Jun 2012, at 13:32, Moritz Ulrich wrote:
> I don't think redefining the behavior of fundamental syntax is a good
> idea. Might break many things.
--
You received this message becaus
C+1, Steven Obua wrote:
>
> The expression
>
> (#({:a %}) :b)
>
> should evaluate to {:a :b}, but raises an exception instead:
>
> Wrong number of args (0) passed to: PersistentArrayMap
>
> This is a pretty irritating bug and makes the #% form essentially unusable
> for
Ah, I see. Thanks for the clarifications, at least now I understand why
#(...) does what it does.
On Monday, June 4, 2012 2:53:09 AM UTC+1, Steven Obua wrote:
>
> The expression
>
> (#({:a %}) :b)
>
> should evaluate to {:a :b}, but raises an exception instead:
>
>
The expression
(#({:a %}) :b)
should evaluate to {:a :b}, but raises an exception instead:
Wrong number of args (0) passed to: PersistentArrayMap
This is a pretty irritating bug and makes the #% form essentially unusable
for me, because I cannot rely on it but have to always second guess if it
>
> So, what does all this mean?
>
> 1. This is not a Clojure behavior but a Java one. Somehow millions of Java
> developers and projects
> managed to get by with this weird behavior.
>
I am not sure what you mean here:
Boolean b = new Boolean(false);
if (b) System.out.println("t
)
wrote:
>
> Hi,
>
> Am 07.04.2012 um 18:10 schrieb Steven Obua:
>
> > Thx, I am using (boolean ...) now to normalize my load-store function.
>
> ObjectInputStream and ObjectOutputStream have .readBoolean resp.
> .writeBoolean methods which do the right thing.
>
>
Thx, I am using (boolean ...) now to normalize my load-store function.
--
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 wit
l 7, 2012 4:50:00 PM UTC+1, Aaron Cohen wrote:
>
> On Sat, Apr 7, 2012 at 11:41 AM, Steven Obua wrote:
>
>> --(defrecord
>>
>> M-Node [leaf conte
Well, I am an emotional programmer. And it just hurts when something
potentially great like Clojure fucks up big time in the little details.
I found the problem. It was caused by serializing a record value and later
deserializing it:
-
Hi,
I am using Clojure for a month now. I like it a lot so far, but there
are a couple of little details that make me very afraid. Foremost:
(if (Boolean. false) "jesus" "christ")
will return "jesus", not "christ". Googling this on the net, I found
that this is a known phenomenon, and some ratio
17 matches
Mail list logo
