Re: clojure.data.csv/write-csv isn't thread safe (should it be?)

[Michael Gardner]

Note that clojure.core/println is also not "thread-safe" in that sense: two 
threads doing `(println "foo" "bar")` may produce interleaved output.

> On May 2, 2019, at 05:59, matt.t.gr...@gmail.com wrote:
> 
> The write-csv function in clojure.data.csv isn't thread safe because even 
> though it uses the synchronized .write method on BufferedReader, it does so 
> at the cell level, not the row/line level. Is this expected or a bug? Is 
> there a reason it shouldn't be made thread safe?
> 
> Attached is a simple test showing the result of calling write-csv with a 
> single thread vs. 100 threads. With a single thread, the output is correct, 
> and with 100 threads the result is a jumbled mess. Conversely, if I use 
> clojure-csv and manually write at the row level using the same harness, it 
> works as expected with multiple threads.
> 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
> 

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Keyword namespacing best practices

[Michael Gardner]

> On Sep 30, 2018, at 23:41, Alan Thompson  wrote:
> 
> It is easy to overdo it when trying to predict future needs.  I always (now) 
> do the minimal solution, with the expectation that it *may* evolve in the 
> future.

Normally I'd agree: YAGNI is great for functionality that can be added without 
breaking clients (or when you control all the clients). But public APIs seem 
like the place to be forward-thinking, at least for potential breaking changes 
such as switching to namespaced keywords.

> Since the parts that do need change (say 5% ?) are usually not the ones I 
> would have predicted, I am usually very glad I didn't over-engineer the API 
> in advance.

W.r.t. "over-engineer", tongue-in-cheek: 
https://www.youtube.com/watch?v=XewVicFzRxw=2m44s

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Keyword namespacing best practices

[Michael Gardner]

> On Sep 30, 2018, at 18:54, Eric Lavigne  wrote:
> 
> I would not use keyword namespaces in this situation. Users of the "fetch" 
> function will likely type :timeout, :status, and :body when using this 
> function. Keyword namespaces would just force users to type longer names for 
> these.

Thanks for the response, Eric. Leaving :timeout aside for the moment, the issue 
I'm wrestling with is that you never know what your clients will do with the 
response. That makes it hard to anticipate the likelihood of keyword 
collisions, especially for a more complex compound response. There are also 
some fringe benefits, like greater synergy with clojure.spec and a kind of 
self-description effect (again, more relevant for larger APIs).

I've also heard some library developers say they've adopted namespaced keywords 
almost everywhere, so I guess I'm just wondering about where to draw that line.

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Keyword namespacing best practices

[Michael Gardner]

I'm looking for some feedback on keyword namespacing. Say you're writing an API 
to be used by external clients that works something like this:

(fetch url :timeout 10)
=> {:status 200, :body "..."}

Would you namespace the :status and :body keywords in the response? What about 
the :timeout kwarg in the function call? Why or why not?

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: case bug

[Michael Gardner]

As its docstring states, the `case` macro doesn't evaluate its test-constants. 
It only works on compile-time constants (e.g. literal strings/numbers), to 
allow O(1) matching. You want `condp` instead.

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [ANN and RFC] Bifurcan: impure functional data strucures

[Michael Gardner]

> On Mar 27, 2017, at 09:51, Zach Tellman  wrote:
> 
> They also provide high-performance mutable variants of the data structure 
> which share an API with their immutable cousins.

How does their performance compare to Clojure's transients? Transients are 
slower than Java's native mutable collections, so if the mutable collections in 
this library deliver the same performance as the latter, they could act as a 
drop-in replacement for the former (given a compatible Clojure wrapper).

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Clojure.spec, maps, restrict valid keywords, easier way?

[Michael Gardner]

What would be the Right Way to deal with typos like (fetch-important-data 
{:encypt true}), where the :encrypt key is optional? Timothy mentions 
auto-complete, which is better than nothing but doesn't feel like a real 
solution (especially to those who don't use auto-complete).

> On Feb 2, 2017, at 16:37, Alex Miller  wrote:
> 
> Ugh, don't do that. Introducing layers that add no value is a bad idea. Just 
> use the keyword directly. 
> 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Help me understand what part of this code is slow, and how to make it faster?

[Michael Gardner]

Below is the fastest version I tested, using ideas from the various responses 
in this thread. It runs in ~4s on my machine, compared with ~27s for the 
original version.

The biggest win by far was from James Reeves' suggestion of switching to Java's 
mutable HashSet. I'm not sure why; I'd thought that using transients and 
transducers with Clojure's native sets would provide comparable performance, 
but this was not true in my testing.

I also couldn't figure out how to avoid the reflection warning when invoking 
HashSet's constructor that takes a generic Collection, which is why that ugly 
doto is there in nth-neighbors. How would I avoid that?

(ns hash-set-bench
  (import
[java.util HashSet]
[java.awt Point]))
  
(set! *warn-on-reflection* true)
(set! *unchecked-math* :warn-on-boxed)

(defn neighbors [^Point p]
  (let [x (.-x p), y (.-y p)]
[(Point. x (inc y))
 (Point. x (dec y)) 
 (Point. (inc x) y)
 (Point. (dec x) y)]))

(defn nth-neighbors [^long n ^Point p]
  (loop [n n, s1 (doto (HashSet.) (.add p)), s2 (HashSet.)]
(if (zero? n) s1
  (let [s0 (HashSet.)]
(doseq [_ s1, p (neighbors _)]
  (when-not (or (.contains s1 p) (.contains s2 p))
(.add s0 p)))
(recur (dec n) s0 s1)

> On Nov 15, 2016, at 19:39, Didier  wrote:
> 
> Hey all,
> 
> I came upon a benchmark of F#, Rust and OCaml, where F# performs much faster 
> then the other two. I decided for fun to try and port it to Clojure to see 
> how Clojure does. Benchmark link: https://github.com/c-cube/hashset_benchs
> 
> This is my code for it: 
> https://gist.github.com/didibus/1fd4c00b69d927745fbce3dcd7ca461a
> 
> (ns hash-set-bench
>   "A Benchmark I modified to Clojure from:
>https://github.com/c-cube/hashset_benchs;)
> 
> (defn iterNeighbors [f [i j]]
>   (f [(dec i) j])
>   (f [(inc i) j])
>   (f [i (dec j)])
>   (f [i (inc j)]))
> 
> (defn nth* [n p]
>   (loop [n n s1 #{p} s2 #{}]
> (if (= n 0)
>   s1
>   (let [s0 (atom #{})]
> (letfn [(add [p]
>  (when (not (or (contains? s1 p) (contains? s2 p)))
>(reset! s0 (conj @s0 p]
>(doseq [p s1] (iterNeighbors add p))
>(recur (dec n) @s0 s1))
> 
> #_(printf "result is %d" (count (time (nth* 2000 [0 0]
> 
> And here's the F# code: 
> https://github.com/c-cube/hashset_benchs/blob/master/neighbors2.fsx
> 
> Currently, this takes about 30s in Clojure, while it only takes around 3s for 
> OCaml, Rust and F#.
> 
> From what I see, the differences between my code and theirs are:
>   • Lack of a Point struct, I'm just using a vector.
>   • They use a mutable set, I don't.
>   • They overrode Hashing for their point struct, as well as equality. I 
> rely on Clojure's default hashing, and vector equality.
> I'm not sure if any of these things should really impact performance that 
> much though. And what I could do in Clojure if I wanted to improve it.
> 
> 
> 
> Any Help?
> 
> 
> 
> 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 from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Thoughts on clojure.spec

[Michael Gardner]

It might be possible to leverage something like American Fuzzy Lop[1] for 
better random input generation. I've never used AFL myself, but I know SQLite 
(one of the best-tested libraries I know of) has had good success with it[2], 
and it does work on Java.

[1] http://lcamtuf.coredump.cx/afl/
[2] https://www.sqlite.org/testing.html#aflfuzz

> On Jul 10, 2016, at 03:04, Mark Engelberg  wrote:
> 
> I've played around now with implementing specs for a couple of my projects.
> 
> What I'm finding is that writing specs to check the inputs of a function is 
> easy-ish, but building useful random generators is very hard -- in my 
> projects, this seems too hard to do with any reasonable amount of effort.
> 
> This isn't due to anything inherent in clojure.spec, it's just that for 
> non-trivial functions, coming up with relevant random input is a very hard 
> problem.  For example, let's say I have a function that takes two integers.  
> Odds are that not any two randomly chosen integers will work.  Some 
> combinations of integers are non-sensical and could trigger an error, other 
> combinations may cause the function to run way too long.  As a concrete 
> example, I just tried to spec out a SAT solver (which tries to solve 
> NP-complete problems).  The input should be a vector of vectors of ints, but 
> many combinations of inputs will just run forever.  How to generate "good" 
> SAT problems?  I have no idea.
> 
> So for the most part, I've ignored the generation aspect of specs because it 
> just feels like too much work.  But without the generators, clojure.spec's 
> utility is significantly diminished.
> 
> 1. No way to test function output specs.  For documentation purposes, I want 
> to have an output spec on my function.  However, as far as I know, after 
> instrumentation-triggered checking of output specs was removed a couple of 
> alphas ago, the only way remaining to check against output specs is to use 
> randomly generated tests.  So if I can't make good generators, I have no way 
> to confirm that my output spec works the way I think it does.  My 
> documentation could be totally out of touch with reality, and that displeases 
> me.
> 
> 2. Limited ability for testing that functions take and receive what you 
> expect.  Whereas a static type system can prove certain properties about 
> whether functions are called with valid inputs, with spec, you only get those 
> guarantees if you pump a function with enough valid random data to trigger 
> the function calling all its callees with interesting combinations of data.  
> But if I use the naive generators, the function will never even complete with 
> most of the randomly generated input, let alone call other functions in a 
> useful way.  And in many cases I don't see how to generate something of 
> better quality.
> 
> So looking back at my experiments, my preliminary impression is that by 
> adding specs to my public APIs, I've gained some useful documentation, and 
> I've given users the ability to instrument functions in order to get 
> high-quality assertion-checking of the inputs.  In some cases, the error 
> messages for bad input when instrumented are also more useful than I would 
> have otherwise gotten, but in some cases they aren't.  Overall, I've 
> struggled to write generators, and without them, the value proposition isn't 
> as great.
> 
> One other issue I've had, unrelated to generators, is that I'm struggling to 
> express higher-order type constraints, for example, this function takes a 
> vector v1 of anything and a vector v2 of anything, but the type of the things 
> in vector v1 better match the type of the things in vector v2.
> 
> What are other people finding?  Do you find it easy/hard to write generators? 
>  (If you think it's easy, I'd love to know your tricks).  Do you find it 
> easy/hard to read specs as a form of documentation about the contract of a 
> function?  Do you find it frustrating that there's no way to turn on 
> instrumentation of function outputs for manual testing?  Do you feel your 
> generators are providing sufficient code coverage when exercising callee 
> functions?
> 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" 

Rationale for `keys` not supporting vectors?

[Michael Gardner]

I've looked around, but couldn't find any discussion on the topic. Is it purely 
an implementation thing, or a design choice?

(Yes, I realize you can just do (range (count v)).)

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: apply madness

[Michael Gardner]

There's no need to avoid `apply` altogether, IMO. You could do something like 
this:

(let [raw (list :a 1 :b 2 :c 3)]
(into {:raw raw}
(filter (comp even? second)
(apply hash-map raw

BTW, `list` is pretty uncommon. Usually you'd just use a vector literal.

And this is the right place to ask!

> On May 12, 2016, at 00:46, hiskennyness  wrote:
> 
> This does what I want but feels nooby-ish, as in "in a month I will do this 
> without APPLY":
> 
> (let [raw (list  :a 1 :b 2 :c 3)]
>   (apply assoc {}
>  :raw raw
>   (apply concat
>(filter #(even? (second %))
>(apply hash-map raw)
> ;; => {:raw (:a 1 :b 2 :c 3), :b 2}
> 
> Am I being too hard on myself?
> 
> Meta question: is there a better place to ask such questions?
> 
> -kt
> 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Are strings vectors? Should 'get' docstring be changed?

[Michael Gardner]

On Apr 21, 2016, at 10:04, James Reeves  wrote:
> 
> Clojure seems to avoid having functions that have variable performance 
> depending on the data structure they're applied to.

But not always! (e.g. count)

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Reducing the pain of a clojars outage

[Michael Gardner]

> On Jan 2, 2016, at 10:27, Toby Crawley <t...@tcrawley.org> wrote:
> 
> On Sat, Jan 2, 2016 at 12:47 AM, Michael Gardner <gardne...@gmail.com> wrote:
>> 
>> I would caution against this approach. An attacker could easily target 
>> specific organizations, serving compromised artifacts only to particular IP 
>> ranges. A periodic verification process wouldn't detect this[1], and might 
>> lend a false sense of security that lulls people into putting off real 
>> security measures.
>> 
>> [1] Unless run by every organization that uses lein, and even then it still 
>> might not catch anything if the attackers are clever.
>> 
> 
> That's a good point. Would you trust this approach more if the mirrors
> were all managed by the clojars staff instead of by community members?
> You currently trust the clojars staff to not act maliciously, and to
> detect an intrusion by a third party against clojars.org.

I would trust it somewhat more. An increase in the number of servers still 
means an increase in the system's attack surface, but at least there shouldn't 
be any additional risk from those running the mirrors.

Still, my personal opinion (for whatever it's worth) is that ensuring the 
entire process is always cryptographically secure end-to-end should be a higher 
priority than establishing mirrors.

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Reducing the pain of a clojars outage

[Michael Gardner]

> On Jan 1, 2016, at 21:31, Toby Crawley  wrote:
> 
> But if we had a regular
>process that crawled all of the mirrors and the canonical repo to
>verify that the checksums every artifact are identical, this could
>actually improve security, since we could detect if any checksum
>had been changed

I would caution against this approach. An attacker could easily target specific 
organizations, serving compromised artifacts only to particular IP ranges. A 
periodic verification process wouldn't detect this[1], and might lend a false 
sense of security that lulls people into putting off real security measures.

[1] Unless run by every organization that uses lein, and even then it still 
might not catch anything if the attackers are clever.

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Style, Efficiency, and updating nested structure

[Michael Gardner]

- Worrying about the performance of a small, pure function like this is almost 
certainly premature optimization.

- Avoid concurrency constructs like atoms if you don't need them.

- Have you considered using group-by?

> On Nov 11, 2015, at 13:25, Dave Tenny  wrote:
> 
> A colleague and I are debating various things clojure as we were exploring 
> alternative ways to solve a problem.
> 
> Here's the description of the problem that a particular function is trying to 
> solve, and the first implementation of it.
> 
> (defn update-roles 
>   "Given a vector of maps of the form {:project_id N :project_name S 
> :project_roles [...roles...]}
>   if there is already a map for the indicated project id/name, add new-role 
> to it and returned
>   a copy the updated input vector, otherwise return a vector with a new map 
> entry for the newly found
>   project and initial role.  This function is basically aggregating tuples 
> from the database."
>   [projects project-id project-name new-role]
>   (let [updated? (atom nil)
> 
> projects* (mapv (fn [m] 
>   (if (= (:project_id m) project-id)
> (do (reset! updated? true)
> (assoc m :project_roles (conj (:project_roles 
> m) new-role)))
> m))
> projects)]
> (if @updated?
>   projects*
>   (conj projects {:project_id project-id :project_name project-name 
> :project_roles [new-role]}
> 
> 
> ;; (update-roles [{:project_id 1 :project_name "One" :project_roles [:own]}] 
> 2 "Two" :edit)
> ;; => [{:project_id 1, :project_name "One", :project_roles [:own]} 
> {:project_id 2, :project_name "Two", :project_roles [:edit]}]
> ;; (update-roles [{:project_id 1 :project_name "One" :project_roles [:own]}] 
> 1 "Two" :edit)
> ;; => [{:project_id 1, :project_name "One", :project_roles [:own :edit]}]
> 
> 
> 
> Now here's another implementation:
> 
> (defn update-or-insert-project-role
>   [prj-roles prj-role]
>   (let [to-insert-prj-id (:project_id prj-role)
> by-pid   (group-by :project_id prj-roles)]
> (case (get by-pid to-insert-prj-id)
>   nil (conj prj-roles prj-role)
>   (->> (update-in by-pid [to-insert-prj-id 0 :project_roles] #(apply conj 
> % (:project_roles prj-role)))
>(mapcat second)
>(into [])
> 
> ;; (def prj-roles [{:project_id 1, :project_name "One", :project_roles 
> [:own]} {:project_id 3 :project_name "Three" :project_roles [:edit]}])
> ;; (update-or-insert-project-role prj-roles {:project_id 2 :project_name 
> "Two" :project_roles [:edit]})
> ;; => [{:project_id 1, :project_name "One", :project_roles [:own]} 
> {:project_id 3, :project_name "Three", :project_roles [:edit]} {:project_id 
> 2, :project_name "Two", :project_roles [:edit]}]
> ;; (update-or-insert-project-role prj-roles {:project_id 1 :project_name 
> "One" :project_roles [:edit]})
> ;; => [{:project_id 1, :project_name "One", :project_roles [:own :edit]} 
> {:project_id 3, :project_name "Three", :project_roles [:edit]}]
> 
> 
> 
> The function is called in a loop to aggregate rows from a database, though it 
> isn't an overriding concern, we're not going millions of records in this case.
> 
> The first thing my colleague and I disagreed on was the calling sequence, 
> arguing over which is more readable.
> The second thing was whether efficiency in this context is really important, 
> or whether it's all moot in clojure.  
> 
> Finally, I'm sure there's a better way, probably with Zippers or something, 
> but neither of us have used them. Suggestions for the stylistic and 
> operational epitome of clojure expression on this routine are welcome!
> 
> Superficially, and probably incorrect in multiple ways, here is a poor 
> attempt at breaking down efficiency in terms of search/traversal and memory 
> allocations.  This was done by someone with no knowledge of clojure internals 
> (including the library implementations of the called functions).
> 
> ;; Comparing the two routines per function call, for existing project case 
> (i.e. where roles are updated)
> ;;
> ;; Assuming each routine allocates new vector for new-role placement in 
> existing project
> ;; and MapEntry for assoc of new vector on project_roles, so they aren't 
> included in allocations 
> ;; below since both routines have to do it.
> ;;
> ;; Note that x-element map allocates storage for map and map-entries or 
> clojure equivalent.
> ;; (and more expensive than an x-element vector, of course).
> ;;
> ;; n == length of input project list.
> ;; m == average length of input project list role vectors.
> ;; 
> ;; Object Allocations
> ;;   Function call:
> ;; update-roles: 
> ;;   1 atom
> ;;   1 O(n) vector for mapv 
> ;; update-or-insert-project-role: 
> ;;   1 3-entry map + 1 single-element vector for prj-role argument input.
> ;;   1 n-element map for group-by
> ;;   n 

Re: Clojure/Pedestal vs Go

[Michael Gardner]

On Sep 15, 2015, at 20:45, Mikera  wrote:
> 
> 7. The open source library ecosystem on the JVM is awesome. There's nothing 
> like it for any other language.

I like your other points, but in my experience this one is (arguably) no longer 
true. I've often found the JVM library ecosystem to be lacking in comparison to 
Python's, especially for newer problem domains. I'd attribute this to Java no 
longer being a "hip" language, which counts for a lot in OSS development!

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Single-atom update ordering guarantees

[Michael Gardner]

This might be blindingly obvious to some, but I can't find any discussion about 
it. Let's say I have code like the following:

(def a (atom 1))
...
(swap! a inc)
(swap! a dec)

Is there any possibility of another thread seeing a=0? If not, what provides 
this guarantee?

-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Single-atom update ordering guarantees

[Michael Gardner]

I'm talking about a scenario where a single thread does inc, followed shortly 
by dec. Obviously from that thread's perspective, the value will never be zero, 
but what about as seen by other threads?

My understanding of Java's memory model is that instructions within a single 
thread *can* get reordered, and Java only guarantees that they will *appear* to 
have executed in order from the perspective of the executing thread. Other 
threads might see those instructions as executing out-of-order. What I'm 
wondering is whether atoms are subject to this as well.

 On Jun 9, 2015, at 10:16 AM, Andy Fingerhut andy.finger...@gmail.com wrote:
 
 I am not sure why Atamert says No.
 
 If the (swap! a inc) and (swap! a dec) are executed in different threads, and 
 they can occur in either order because there is no synchronization between 
 those threads that prevents one of the two possible orders from occurring, 
 then another thread *could* see a value of 0, if and when the (swap! a dec) 
 occurs first.
 
 If the (swap! a inc) and (swap! a dec) are executed sequentially in a single 
 thread, and no other thread is modifying a, then by normal sequential 
 execution the atom should change from 1 to 2, then from 2 back to 1.
 
 Andy
 
 On Tue, Jun 9, 2015 at 9:38 AM, Atamert Ölçgen mu...@muhuk.com wrote:
 
 
 On Tue, Jun 9, 2015 at 7:30 PM, Michael Gardner gardne...@gmail.com wrote:
 This might be blindingly obvious to some, but I can't find any discussion 
 about it. Let's say I have code like the following:
 
 (def a (atom 1))
 ...
 (swap! a inc)
 (swap! a dec)
 
 Is there any possibility of another thread seeing a=0? If not, what provides 
 this guarantee?
 
 No. Not if those two swap! calls are made from different threads.
  
 
 --
 You received this message because you are subscribed to the Google
 Groups Clojure group.
 To post to this group, send email to clojure@googlegroups.com
 Note that posts from new members are moderated - please be patient with your 
 first post.
 To unsubscribe from this group, send email to
 clojure+unsubscr...@googlegroups.com
 For more options, visit this group at
 http://groups.google.com/group/clojure?hl=en
 ---
 You received this message because you are subscribed to the Google Groups 
 Clojure group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to clojure+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.
 
 
 
 -- 
 Kind Regards,
 Atamert Ölçgen
 
 ◻◼◻
 ◻◻◼
 ◼◼◼
 
 www.muhuk.com
 www.olcgen.com
 
 -- 
 You received this message because you are subscribed to the Google
 Groups Clojure group.
 To post to this group, send email to clojure@googlegroups.com
 Note that posts from new members are moderated - please be patient with your 
 first post.
 To unsubscribe from this group, send email to
 clojure+unsubscr...@googlegroups.com
 For more options, visit this group at
 http://groups.google.com/group/clojure?hl=en
 --- 
 You received this message because you are subscribed to the Google Groups 
 Clojure group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to clojure+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.
 
 
 -- 
 You received this message because you are subscribed to the Google
 Groups Clojure group.
 To post to this group, send email to clojure@googlegroups.com
 Note that posts from new members are moderated - please be patient with your 
 first post.
 To unsubscribe from this group, send email to
 clojure+unsubscr...@googlegroups.com
 For more options, visit this group at
 http://groups.google.com/group/clojure?hl=en
 --- 
 You received this message because you are subscribed to the Google Groups 
 Clojure group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to clojure+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Single-atom update ordering guarantees

[Michael Gardner]

Thanks. That does appear to provide the guarantee I was looking for.

 On Jun 9, 2015, at 12:14 PM, Andy Fingerhut andy.finger...@gmail.com wrote:
 
 swap! is implemented using Java's AtomicReference class and its compareAndSet 
 method.  I haven't dug into the Java source code implementing that class, but 
 you can read the Java documentation for all Atomic* Java classes here:
 
 https://docs.oracle.com/javase/7/docs/api/java/util/concurrent/atomic/package-summary.html
 
 The summary there is that all accesses to Atomic* classes should have similar 
 memory model guarantees as Java fields declared volatile.  I don't have a 
 good authoritative link handy for Java documentation on volatile, but the 
 basic idea is that they should not be cached locally by individual threads, 
 but be visible to all.
 
 Andy
 
 
 On Tue, Jun 9, 2015 at 11:33 AM, Michael Gardner gardne...@gmail.com wrote:
 I'm talking about a scenario where a single thread does inc, followed shortly 
 by dec. Obviously from that thread's perspective, the value will never be 
 zero, but what about as seen by other threads?
 
 My understanding of Java's memory model is that instructions within a single 
 thread *can* get reordered, and Java only guarantees that they will *appear* 
 to have executed in order from the perspective of the executing thread. Other 
 threads might see those instructions as executing out-of-order. What I'm 
 wondering is whether atoms are subject to this as well.
 
  On Jun 9, 2015, at 10:16 AM, Andy Fingerhut andy.finger...@gmail.com 
  wrote:
 
  I am not sure why Atamert says No.
 
  If the (swap! a inc) and (swap! a dec) are executed in different threads, 
  and they can occur in either order because there is no synchronization 
  between those threads that prevents one of the two possible orders from 
  occurring, then another thread *could* see a value of 0, if and when the 
  (swap! a dec) occurs first.
 
  If the (swap! a inc) and (swap! a dec) are executed sequentially in a 
  single thread, and no other thread is modifying a, then by normal 
  sequential execution the atom should change from 1 to 2, then from 2 back 
  to 1.
 
  Andy
 
  On Tue, Jun 9, 2015 at 9:38 AM, Atamert Ölçgen mu...@muhuk.com wrote:
 
 
  On Tue, Jun 9, 2015 at 7:30 PM, Michael Gardner gardne...@gmail.com wrote:
  This might be blindingly obvious to some, but I can't find any discussion 
  about it. Let's say I have code like the following:
 
  (def a (atom 1))
  ...
  (swap! a inc)
  (swap! a dec)
 
  Is there any possibility of another thread seeing a=0? If not, what 
  provides this guarantee?
 
  No. Not if those two swap! calls are made from different threads.
 
 
  --
  You received this message because you are subscribed to the Google
  Groups Clojure group.
  To post to this group, send email to clojure@googlegroups.com
  Note that posts from new members are moderated - please be patient with 
  your first post.
  To unsubscribe from this group, send email to
  clojure+unsubscr...@googlegroups.com
  For more options, visit this group at
  http://groups.google.com/group/clojure?hl=en
  ---
  You received this message because you are subscribed to the Google Groups 
  Clojure group.
  To unsubscribe from this group and stop receiving emails from it, send an 
  email to clojure+unsubscr...@googlegroups.com.
  For more options, visit https://groups.google.com/d/optout.
 
 
 
  --
  Kind Regards,
  Atamert Ölçgen
 
  ◻◼◻
  ◻◻◼
  ◼◼◼
 
  www.muhuk.com
  www.olcgen.com
 
  --
  You received this message because you are subscribed to the Google
  Groups Clojure group.
  To post to this group, send email to clojure@googlegroups.com
  Note that posts from new members are moderated - please be patient with 
  your first post.
  To unsubscribe from this group, send email to
  clojure+unsubscr...@googlegroups.com
  For more options, visit this group at
  http://groups.google.com/group/clojure?hl=en
  ---
  You received this message because you are subscribed to the Google Groups 
  Clojure group.
  To unsubscribe from this group and stop receiving emails from it, send an 
  email to clojure+unsubscr...@googlegroups.com.
  For more options, visit https://groups.google.com/d/optout.
 
 
  --
  You received this message because you are subscribed to the Google
  Groups Clojure group.
  To post to this group, send email to clojure@googlegroups.com
  Note that posts from new members are moderated - please be patient with 
  your first post.
  To unsubscribe from this group, send email to
  clojure+unsubscr...@googlegroups.com
  For more options, visit this group at
  http://groups.google.com/group/clojure?hl=en
  ---
  You received this message because you are subscribed to the Google Groups 
  Clojure group.
  To unsubscribe from this group and stop receiving emails from it, send an 
  email to clojure+unsubscr...@googlegroups.com.
  For more options, visit https://groups.google.com/d/optout.
 
 --
 You received this message because you

Identifying dependency that's pulling in SLF4J

[Michael Gardner]

I've started to see unwanted SLF4J console messages from one of my projects. 
I'm not (directly) using SLF4J, and would like to find out which of my 
dependencies is. But the dependency tree is a bit large to search by hand. Is 
there a better way?

-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Identifying dependency that's pulling in SLF4J

[Michael Gardner]

 On Jun 8, 2015, at 10:30 AM, Stephen Gilardi scgila...@gmail.com wrote:
 
 Does “lein deps :tree” help?

Yes, that's very helpful. 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 from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: contains? on String

[Michael Gardner]

On May 12, 2015, at 1:54 PM, Shantanu Kumar kumar.shant...@gmail.com wrote:
 I agree about the counter-intuitiveness. I'm only wondering whether the error 
 message is a bit misleading contains? not supported on type: 
 java.lang.String because of course (contains? hello 2) works fine.

It seems odd that (contains? abc 2) works, at least to me. It's clearly 
intentional, from this line in RT.java:

else if(key instanceof Number  (coll instanceof String || 
coll.getClass().isArray())) {

Can anyone comment on why Strings are explicitly supported here?

-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: contains? on String

[Michael Gardner]

On May 12, 2015, at 3:28 PM, Fluid Dynamics a2093...@trbvm.com wrote:
 Strings and arrays support constant-time access by index.

Yes, but why should that mean that contains? should work on Strings? Because 
it can doesn't seem compelling to me. In discussions about contains?, one 
often hears that it works on associative containers, which is supported by the 
use of the word key in its docstring. Vectors are indeed associative, but 
Strings aren't (at least according to associative?), which is why this seems 
like a strange feature to me.

-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: How to coerce to bigint ?

[Michael Gardner]

On Sat, Apr 4, 2015 at 11:36 AM, Paul Roush pro...@gmail.com wrote:

 (range  5N) = (0 1 2 3 4)  ;  i.e. the bigint-ness is lost

 So in this particular case I needed to inject bigint into the process
 later in some way.


You could try (range (* 0 n) n). A little silly, but does avoid the
conditional.

You could consider also creating a JIRA issue asking for range to match the
type of its argument in the 1-arity case. No idea whether it would be
accepted, though.

-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Set equality bug?

[Michael Gardner]

On Jan 23, 2015, at 8:23 AM, Andy Fingerhut andy.finger...@gmail.com wrote:
 You can try creating a JIRA ticket suggesting that Clojure's = should return 
 false when comparing floats and doubles to each other.

CLJ-1649, for anyone interested.

-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Set equality bug?

[Michael Gardner]

On Jan 23, 2015, at 11:51 AM, Andy Fingerhut andy.finger...@gmail.com wrote:
 Hash consistency is certainly nice, but if Clojure were changed such that (= 
 float-val double-val) were always false, and no other changes were made, it 
 would lead to this situation:
 
 user= (= (float 1.5) (double 1.5))
 true
 user= (= (float 1.5) (double 1.5))
 true
 user= (= (float 1.5) (double 1.5))
 false

I'd argue you should be using == if you care about that particular property. 
And note that this can already happen with BigDecimals:

user= (= 10M 10)
true
user= (= 10M 10)
true
user= (= 10M 10)
false

-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Set equality bug?

[Michael Gardner]

I'm sure we are all aware of the various issues with floating point math 
(particularly equality comparisons); however none of that is relevant to this 
discussion. The only issue here is an inconsistency between hashing and 
equality testing in Clojure.

My claim is that the property any two objects can be equal only if their 
hashes are equal is a fundamental one that should not be violated under any 
circumstances. Whether that means modifying Clojure's hashing algorithm or its 
implementation of = doesn't much matter to me, so long as that property is 
maintained.

 On Jan 23, 2015, at 5:06 AM, Luc Préfontaine lprefonta...@softaddicts.ca 
 wrote:
 
 Well if it breaks elsewhere than in your code because you mix representations 
 and leak
 them to some library in Java that you do not control I see my comments as 
 absolutely relevant.
 
 It's not technical, it's failsafe. But that might not be of any interest to 
 your problem scope.
 However it does interest me. Hiding odd behaviors when consistency can be 
 guaranteed,
 I have no problem with that. Here to me its very clear that there is no 
 failsafe approach.
 
 Clojure is hosted on a platform that does not provide the kind if consistency 
 you want.
 Anything you can build to hide this in Clojure is like building a tower on 
 moving sand.
 
 Mark has a valid point about type safety which helps a bit in Java but you 
 can dig
 with google and you will find people that got bitten in Java by float/double 
 mixing
 even with type 'safety'. So long for type systems, it cannot help you with 
 values that
 'look' the same superficially but are internally different.
 
 For some values, floats and doubles are equal because their internal 
 representations are the 
 same. For many other values it's not working.
 
 I suggest some readings;
 
 http://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html
 http://floating-point-gui.de/errors/comparison/
 
 Then maybe we can bring this thread to an end.
 
 
 If there's a technical reason why Clojure can't return false for all = 
 comparisons between floats and doubles, I'd like to hear it. Otherwise, I 
 don't see how your response is relevant.
 
 On Jan 23, 2015, at 3:10 AM, Luc Prefontaine lprefonta...@softaddicts.ca 
 wrote:
 
 Agree, it's broken... in java...
 Has it has been broken in the past in several architectures...
 
 I understand your frustration but this is not something new. It's been a 
 problem for at least 30 years.
 
 It is kind of a basic programming issue:
 
 - Never compare floats with different representations.
 
 - Never mix different representations in computations
 
 - Convert representations as early as possible to a common format
 
 These are the rules to follow to avoid running into trouble.
 
 Now if you think you can overcome this persistent (ah ! ah !) problem with 
 some David Copperfield trick, fine.
 
 But that's a trick nothing else. The problem will resurface in some form in 
 another. Better cope with reality...
 
 Luc P.
 
 
 On Jan 23, 2015, at 1:33 AM, Immo Heikkinen immo.heikki...@gmail.com 
 wrote:
 
 I actually ran into this while comparing nested data structures from two 
 different sources and spent a good part of my day figuring out what's 
 happening. While it is a good advice to avoid mixing floats and doubles, 
 it is inevitable that Clojure users will get bitten by this once in a 
 while and hours will be wasted.
 
 It is also very disturbing to realise that (= a b) doesn't always imply 
 (= (hash a) (hash b)) or (= #{a} #{b}) as you would think.
 
 (inc)
 
 This is fundamentally broken behavior. Telling people to just learn to 
 avoid it is not good, IMO. If the hashes must be unequal, then = should 
 return false.
 
 As for backwards compatibility, note that if such a change were made to =, 
 it wouldn't affect anyone who was already following Andy's advice to avoid 
 mixing doubles and floats. IOW, it should only affect those who are doing 
 something you're not supposed to do 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
 --- 
 You received this message because you are subscribed to the Google Groups 
 Clojure group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to clojure+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.
 
 --
 Luc Prefontainelprefonta...@softaddicts.ca sent by ibisMail!
 
 -- 
 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 

Re: Set equality bug?

[Michael Gardner]

On Jan 23, 2015, at 1:33 AM, Immo Heikkinen immo.heikki...@gmail.com wrote:
 
 I actually ran into this while comparing nested data structures from two 
 different sources and spent a good part of my day figuring out what's 
 happening. While it is a good advice to avoid mixing floats and doubles, it 
 is inevitable that Clojure users will get bitten by this once in a while and 
 hours will be wasted.
 
 It is also very disturbing to realise that (= a b) doesn't always imply (= 
 (hash a) (hash b)) or (= #{a} #{b}) as you would think.

(inc)

This is fundamentally broken behavior. Telling people to just learn to avoid it 
is not good, IMO. If the hashes must be unequal, then = should return false.

As for backwards compatibility, note that if such a change were made to =, it 
wouldn't affect anyone who was already following Andy's advice to avoid mixing 
doubles and floats. IOW, it should only affect those who are doing something 
you're not supposed to do 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
--- 
You received this message because you are subscribed to the Google Groups 
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Set equality bug?

[Michael Gardner]

If there's a technical reason why Clojure can't return false for all = 
comparisons between floats and doubles, I'd like to hear it. Otherwise, I don't 
see how your response is relevant.

 On Jan 23, 2015, at 3:10 AM, Luc Prefontaine lprefonta...@softaddicts.ca 
 wrote:
 
 Agree, it's broken... in java...
 Has it has been broken in the past in several architectures...
 
 I understand your frustration but this is not something new. It's been a 
 problem for at least 30 years.
 
 It is kind of a basic programming issue:
 
 - Never compare floats with different representations.
 
 - Never mix different representations in computations
 
 - Convert representations as early as possible to a common format
 
 These are the rules to follow to avoid running into trouble.
 
 Now if you think you can overcome this persistent (ah ! ah !) problem with 
 some David Copperfield trick, fine.
 
 But that's a trick nothing else. The problem will resurface in some form in 
 another. Better cope with reality...
 
 Luc P.
 
 
 On Jan 23, 2015, at 1:33 AM, Immo Heikkinen immo.heikki...@gmail.com wrote:
 
 I actually ran into this while comparing nested data structures from two 
 different sources and spent a good part of my day figuring out what's 
 happening. While it is a good advice to avoid mixing floats and doubles, it 
 is inevitable that Clojure users will get bitten by this once in a while 
 and hours will be wasted.
 
 It is also very disturbing to realise that (= a b) doesn't always imply 
 (= (hash a) (hash b)) or (= #{a} #{b}) as you would think.
 
 (inc)
 
 This is fundamentally broken behavior. Telling people to just learn to avoid 
 it is not good, IMO. If the hashes must be unequal, then = should return 
 false.
 
 As for backwards compatibility, note that if such a change were made to =, 
 it wouldn't affect anyone who was already following Andy's advice to avoid 
 mixing doubles and floats. IOW, it should only affect those who are doing 
 something you're not supposed to do 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
 --- 
 You received this message because you are subscribed to the Google Groups 
 Clojure group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to clojure+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.
 
 --
 Luc Prefontainelprefonta...@softaddicts.ca sent by ibisMail!
 
 -- 
 You received this message because you are subscribed to the Google
 Groups Clojure group.
 To post to this group, send email to clojure@googlegroups.com
 Note that posts from new members are moderated - please be patient with your 
 first post.
 To unsubscribe from this group, send email to
 clojure+unsubscr...@googlegroups.com
 For more options, visit this group at
 http://groups.google.com/group/clojure?hl=en
 --- 
 You received this message because you are subscribed to the Google Groups 
 Clojure group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to clojure+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [ANN] Clojure 1.7.0-alpha2

[Michael Gardner]

Great stuff, and thanks for all the hard work.

But if I may, I'd like to suggest that completing isn't a great name for that 
transducer helper function-- at least not in the core namespace. It's too 
generic: there's no way to guess what it does from the name, and IMO a function 
with such a niche role doesn't merit such a basic name.

Granted I can't think of a slam-dunk alternative, but what about something like 
trans-complete?

-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: what's the elegant way to write this code in clojure?

[Michael Gardner]

On Apr 18, 2014, at 09:05 , sd song sd.s...@gmail.com wrote:

 another question is: i think code like: (if (nil? page) lmt page) is ugly. is 
 there some functions in clojure like (get_default_value_3_if_a_is_null a 3) ?

If you're OK with false being treated the same as nil, you can do (or page lmt).

-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: boolean problem

[Michael Gardner]

On Apr 17, 2014, at 02:34 , Tassilo Horn t...@gnu.org wrote:

 And now you have an if without then which will give you another
 exception.

Not true. It's more common to use 'when', but single-branch ifs are perfectly 
fine.

-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: boolean problem

[Michael Gardner]

On Apr 17, 2014, at 07:38 , Tassilo Horn t...@gnu.org wrote:

 Michael Gardner gardne...@gmail.com writes:
 
 And now you have an if without then which will give you another
 exception.
 
 Not true. It's more common to use 'when', but single-branch ifs are
 perfectly fine.
 
 Yes, but that was a zero-branch if, and that's not ok.

Oh duh, my bad. I read that as if without else for some reason. Sorry for the 
noise.

-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: creating a map

[Michael Gardner]

For reasons unclear to me, (into {} ...) expects a sequence of 2-element 
*vectors*, not just 2-element collections. partition returns a seq of lists, 
not vectors, which is why you're getting that exception. You could try (into {} 
(map vec (partition 2 2 12))) instead.

On Mar 26, 2014, at 15:36 , Andy Smith the4thamig...@googlemail.com wrote:

 Hi all,
 
 I was wondering why this doesn't create a map 1 - 2 :
 
 (into {} (partition 2 2 12))
 
 Must be yet another misunderstanding of mine.
 
 Thanks
 
 Andy
 
 -- 
 You received this message because you are subscribed to the Google
 Groups Clojure group.
 To post to this group, send email to clojure@googlegroups.com
 Note that posts from new members are moderated - please be patient with your 
 first post.
 To unsubscribe from this group, send email to
 clojure+unsubscr...@googlegroups.com
 For more options, visit this group at
 http://groups.google.com/group/clojure?hl=en
 --- 
 You received this message because you are subscribed to the Google Groups 
 Clojure group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to clojure+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: XOR two arrays into a third on Clojure

[Michael Gardner]

Might be slow because of the polymorphic nature of nth. If you replace nth with 
aget (and turn on *warn-on-reflection*, which is a good idea when 
performance-tuning), you'll get reflection warnings because Clojure doesn't 
know what Java method to use since it doesn't know what type of objects a and b 
are. Once you silence those with type hints like in Walter's example, you get 
roughly a 2x speedup (in my tests).

BTW, I'd write it like this:

(defn inplace-xor [^bytes a ^bytes b ^bytes out]
(dotimes [i (alength a)]
(aset-byte out i
(bit-xor (aget a i) (aget b i)

On Mar 13, 2014, at 00:26 , Ignacio Corderi icord...@soe.ucsc.edu wrote:

 Hey guys, here is a huge performance problem I'm trying to figure out:
 
 ;; Say you have 2 data arrays sitting out there of 1 MB
 
 (def one-mb (byte-array (* 1024 1024))) 
 (def another-mb (byte-array (* 1024 1024))) 
 
 ;; and another one that should have the byte-by-byte XOR of the previous two 
 
 (def out-mb (byte-array (* 1024 1024)))
 
 ;; question is... how do you code this guy, so that it doesn't take forever
 
 (defn inplace-xor [a b out]
   (def ln (count a))
   (loop [x 0]
 (if ( x ln)
   (do 
 (aset-byte out x (bit-xor (nth a x) (nth b x)))
 (recur (+ x 1))
 
 
 ;; checking the time 
 
 (time (inplace-xor one-mb another-mb out-mb))
 
 ;; takes about ~400ms which is well... A LOT
 
 ;; I'm happy to receive a solution that involves calling some java library...
 
 Thanks in advance!
 -Ignacio
 
  
 
 -- 
 You received this message because you are subscribed to the Google
 Groups Clojure group.
 To post to this group, send email to clojure@googlegroups.com
 Note that posts from new members are moderated - please be patient with your 
 first post.
 To unsubscribe from this group, send email to
 clojure+unsubscr...@googlegroups.com
 For more options, visit this group at
 http://groups.google.com/group/clojure?hl=en
 --- 
 You received this message because you are subscribed to the Google Groups 
 Clojure group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to clojure+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: XOR two arrays into a third on Clojure

[Michael Gardner]

On Mar 13, 2014, at 07:34 , Alex Miller a...@puredanger.com wrote:

 Agreed with all the comments on this so far. I would also say that dotimes is 
 slower than loop for stuff like this so I would also make that change.

The dotimes version is slightly faster on my hardware. Why would it be slower?

-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Comparing Regular Expression pattens for equality?

[Michael Gardner]

You can compare the output of the .pattern or .toString methods if all you care 
about is finding regexes made from the exact same patterns. There's no simple 
way to detect equivalent regexes made from different patterns, though.

As for why = doesn't do this, you'd have to talk to the Java folks about that 
(since Clojure's = just calls .equals on Java objects). I suspect it has to do 
with the problem of equivalent patterns.

On Feb 26, 2014, at 05:55 , Thomas th.vanderv...@gmail.com wrote:

 Hi Everyone,
 
 I am creating some regular expressions programmatically with re-pattern. In 
 order to avoid creating the same regex pattern again I want to check if it 
 already exists. But comparing regex pattern doesn't seem to be work:
 
 user= (= #test #test)
 false
 user= (identical? #test #test)
 false
 
 Not surprised that identical? doesn't work to be honest, but = should have 
 worked IMHO
 
 Is there a way to do this?
 
 TIA
 
 Thomas
 
 -- 
 You received this message because you are subscribed to the Google
 Groups Clojure group.
 To post to this group, send email to clojure@googlegroups.com
 Note that posts from new members are moderated - please be patient with your 
 first post.
 To unsubscribe from this group, send email to
 clojure+unsubscr...@googlegroups.com
 For more options, visit this group at
 http://groups.google.com/group/clojure?hl=en
 --- 
 You received this message because you are subscribed to the Google Groups 
 Clojure group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to clojure+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/groups/opt_out.

-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Function that weaves two collections together - looking for feedback

[Michael Gardner]

You may be interested in the core function 'interleave'. As for (into []), it's 
perfectly idiomatic as long as you actually need to return a vector and not 
just some kind of sequence (the more common case). But note also the 
mapv/filterv/reduce-kv family of functions, though they're not directly 
applicable here.

On Feb 18, 2014, at 22:58 , Laurent Droin laurentdr...@gmail.com wrote:

 Hi,
 
 Continuing my little pet project (small program really) to learn Clojure, I 
 am now working on a function whose description would be something like:
   Returns a collection 'weaving' 2 collections (boundaries into categories).
   Boundaries must have one element less than categories.
   For example, if categories is [:z1 :z2 :z3 :z4 :z5]  
   and boundaries is [120 150 165 180] 
   returns [:z1 120 :z2 150 :z3 165 :z4 180 :z5]
 
 Assume the precondition is enforced.
 If categories has n elements, boundaries has n-1.
 
 I have tried to come up with a good implementation. I actually came up with 
 two, one that is non recursive, and one that is recursive. But I'm not fully 
 satisfied. I have the feeling that it's possible to make the function 
 simpler, and more elegant but I only know a subset of Clojure and am surely 
 missing some good idioms that I could/should be using.
 So once again, relying on feedback from experienced Clojurists to show me the 
 way :-)
 
 Here is what I have so far:
 
 1- the non recursive function - based on mapcat
 (defn build-quantize-defs
 
   
 [categories boundaries]
 
 
 (conj (into [] (mapcat #(vector %1 %2) categories boundaries)) (last 
 categories)))
 
 2 - the recursive function
 (defn build-quantize-defs-recur [categories boundaries]
 
   
 (let [c (first categories) b (first boundaries)]
 
 
 (if (nil? b)
  
   
 [c]
  
   
 (into [] (concat [c] [b] (build-quantize-defs-recur (rest categories) (rest 
 boundaries)))
 
 Both functions work (on my example at least).
 
 One of the things I don't like, is my abusing (or the feeling that I am 
 abusing anyway) of this into []  idiom. I find myself constantly turning 
 things into vectors. That doesn't seem right and maybe I am using it in 
 places it's not needed. That's probably because I don't quite have a very 
 good idea of how collections work just yet. 
 
 Thanks for any feedback.

-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [ANN] Clojure 1.6.0-beta1

[Michael Gardner]

On Feb 14, 2014, at 17:25 , Alex Miller a...@puredanger.com wrote:

 The names of these functions were chosen by Rich. There was already some name 
 overloading of some even before these new functions with some (truthy) and 
 some-/some- (not nil). The new functions keep with the latter meaning. 
 Many other names were considered, including everything I've seen someone 
 mention (-not-nil, exists, nnil, etc). As far as I know these names are 
 final, however, I will relay all of the feedback I've seen here, on #clojure, 
 and on Twitter to Rich for consideration.

Probably way too late for this, but if there are truthy and non-nil versions of 
multiple functions/macros then it would be good to use a consistent suffix to 
indicate those semantics, e.g. if/if*, when-let/when-let*, etc (asterisk just 
used as an example).

-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: range-sum

[Michael Gardner]

On Feb 13, 2014, at 08:56 , Stuart Sierra the.stuart.sie...@gmail.com wrote:

 No. Clojure's `apply` is lazy. Varargs are passed to the
 function as a lazy sequence, and it's up to the function to
 realize them or not.

It's worth noting (for people who might try to rely on that laziness) that 
apply will always realize its first four arguments. See 
http://clojurian.blogspot.com/2012/11/beware-of-mapcat.html

-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: range-sum

[Michael Gardner]

On Feb 13, 2014, at 14:31 , Michael Gardner gardne...@gmail.com wrote:

 On Feb 13, 2014, at 08:56 , Stuart Sierra the.stuart.sie...@gmail.com wrote:
 
 No. Clojure's `apply` is lazy. Varargs are passed to the
 function as a lazy sequence, and it's up to the function to
 realize them or not.
 
 It's worth noting (for people who might try to rely on that laziness) that 
 apply will always realize its first four arguments. See 
 http://clojurian.blogspot.com/2012/11/beware-of-mapcat.html

On further examination, I don't think this is correct.

user= (defn f [x] (println x) x)
#'user/f
user= (defn s [n] (lazy-seq (cons (f n) (s (inc n)
#'user/s
user= (defn myfn [ args] nil)
#'user/myfn
user= (apply myfn (s 0))
0
1
nil

I can't explain why exactly two of the elements in (s 0) are being realized 
here, but in any case my claim seems to be wrong.

-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: range-sum

[Michael Gardner]

On Feb 13, 2014, at 15:17 , Mauricio Aldazosa 
mauricio.aldaz...@ciencias.unam.mx wrote:

 My guess is that when using a rest-param a call to next is involved thus 
 realizing two elements of the sequence.

A destructured vararg is nil when there are no more items, which indeed 
requires realizing at least the first item. But that only explains why the 
first item gets realized, not the second (unless I'm missing something).

-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: map semantics

[Michael Gardner]

On Feb 8, 2014, at 15:14 , Andy C andy.coolw...@gmail.com wrote:

 It all boils down this:
   is it possible to have two clojure.lang.PersistentHashSet with identical 
 values (in mathematical sense) but producing different seqs?

Are you serious? The entire point of the email you responded to was to answer 
that question.

(But why male models?)

-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: map semantics

[Michael Gardner]

On Feb 7, 2014, at 22:17 , Andy C andy.coolw...@gmail.com wrote:

 Having map to produce a lazy seq implies that the input must be serializable 
 (or linear).

That's just what map is in Clojure: an operation on sequences. It works on 
various concrete types because those can be viewed as sequences; map knows 
nothing of their structure. What you're looking for is another abstraction 
entirely (see clojure.walk, for example).

-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: ANN: Another binary parser combinator - this time for java's streams

[Michael Gardner]

On Jan 30, 2014, at 01:36 , Steffen steffen.die...@gmail.com wrote:

 If you would like to use a specific codec other than :byte or :ubyte but also 
 restrict the number of bytes read this would only work if you expected to 
 have some kind of optional padding after your objects, like: 
 
 (padding inner-codec 4096).

Yes, that's exactly what I need. I didn't try 'padding because the docs seemed 
to say that it works only when encoding.

My only problem is that when decoding, I don't know how many objects to expect 
before the padding (this is for parsing ID3v2 tags). Ideally I'd like to say 
something like (padding (repeated frame-codec) byte-count), with the padding 
taking over once the inner codec fails to parse the next available bytes (but 
see the next point).

 (defn enum [type m] 
 (compile-codec type m 
 (clojure.set/map-invert m))) 
 So m would be a map of for example keywords to a native datatype like int 
 that would allow you to represent a fixed number of things with distinct 
 binary representations? Looks good to me. What do you think should be the 
 behaviour in case of an unspecified value (not in m)?

I'd expect an exception to be thrown in case of an unspecified value. But when 
decoding, it would be nice if the exception were (optionally?) swallowed when 
occurring inside a 'padding construct, to allow something like the above 
example. Though I don't know how many other binary formats would require 
something like that; I imagine most aren't as dumb as ID3v2.

 Currently the index in the vector is the index of the bit. Yes, that means 
 LSB-first.

Then the docs seem to be wrong (or at least confusing), since the example code 
for 'bits says the first item corresponds to the highest bit.

-- 
-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: ANN: Another binary parser combinator - this time for java's streams

[Michael Gardner]

On Jan 30, 2014, at 08:10 , Steffen Dienst steffen.die...@gmail.com wrote:

 That's exactly what padding is designed to do: Let's say you know there is a 
 run of bytes with a known length (from a header field maybe) and you want to 
 parse an unbounded number of objects within this area. You could use
 
 (padding (repeated inner-codec) 1024)

Excellent.

 Currently codecs don't know about their context, that means, I can't behave 
 differently depending on whether a codec is used within a padding or not, 
 sorry.

It could work the other way around, with 'padding catching certain types of 
exceptions thrown by its inner codecs.

For example, when parsing something like (padding (repeated (constant 0x99)) 
len pad-byte), padding could catch the exception thrown by the constant codec 
and then use pad-byte to parse the remaining bytes.

But I can live without this, if it's too niche or too hard to implement.

 Then the docs seem to be wrong (or at least confusing), since the example 
 code for 'bits says the first item corresponds to the highest bit.
 Thanks, I fixed the documentation. 

A couple other things about the README:

The docs for 'header say that body-header should produce a codec that will be 
used to encode the header, but in testing I've had to make it return the header 
directly (which does make more sense).

Also, the expression #{:a :b:last} in the 'bits section is missing a space.

Thanks for all the help, by the way!

-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: ANN: Another binary parser combinator - this time for java's streams

[Michael Gardner]

Looks good! A few questions:

1) Is it possible to specify a byte length for a 'repeated codec, rather than a 
number of objects?

2) Would you consider an enum type, for convenience? Something like:

(defn enum [type m]
(compile-codec type m
(clojure.set/map-invert m)))

3) In the mp3.clj demo, the flags seem to be listed in the wrong order. Or does 
the 'bits function actually take its arguments LSB-first?

On Jan 29, 2014, at 06:32 , Steffen steffen.die...@gmail.com wrote:

 Hello Clojure community,
 
 there are already two excellent libraries for reading/writing/manipulating 
 binary data: Zach's Lamina and Clojurewerkz' Buffy for java's ByteBuffers. I 
 would like to offer another library for java's Input/OutputStreams. It is 
 inspired by Lamina but not compatible in syntax, I'm sorry.
 The focus is on 
   * read/write performance, 
   * no external dependencies
   * works with java.util.*Stream
 If you use Leiningen please add the following to your dependencies:
 
 [org.clojars.smee/binary 0.2.4]
 
 The link to the source code and README is https://github.com/smee/binary.
 Democode to parse Bitcoin blocks (including scripts): 
 https://github.com/smee/binary/blob/master/src/org/clojars/smee/binary/demo/bitcoin.clj
 Democode for MP3 ID3v2 tags (work in progress): 
 https://github.com/smee/binary/blob/master/src/org/clojars/smee/binary/demo/mp3.clj
 
 Apart from the README, doc strings there is no further documentation, yet. 
 Please refer to the demos and the unit tests for now.
 
 Thanks,
 
 Steffen Dienst
 
 -- 
 -- 
 You received this message because you are subscribed to the Google
 Groups Clojure group.
 To post to this group, send email to clojure@googlegroups.com
 Note that posts from new members are moderated - please be patient with your 
 first post.
 To unsubscribe from this group, send email to
 clojure+unsubscr...@googlegroups.com
 For more options, visit this group at
 http://groups.google.com/group/clojure?hl=en
 --- 
 You received this message because you are subscribed to the Google Groups 
 Clojure group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to clojure+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/groups/opt_out.

-- 
-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [ANN] Buffy, The Byte Buffer Slayer 1.0.0-beta1

[Michael Gardner]

I'm looking to deal with a stream of data that includes a structured, 
variable-length header followed by a (potentially large) binary blob. I'd like 
to parse only the header while leaving the stream (can be a java stream or NIO 
channel, whichever works best) positioned at the start of the binary blob. Can 
Buffy currently do this?

About naming: is the -type prefix to the built-in data types (string-type, etc) 
really necessary, given they're already grouped in the buffy.types namespace? 
I'd prefer to be able to write t/string, t/int32 and so on, personally.

On Dec 17, 2013, at 06:44 , Alex P oleksandr.pet...@gmail.com wrote:

 Buffy [1][2] is a Clojure library to work with Binary Data, write complete 
 binary protocol implementations
 in clojure, store your complex data structures in an off-heap chache, read 
 binary files and do
 everything you would usually do `ByteBuffer`. 
 
 After the initial project announcement, we've got several feature-requests, 
 which been addressed by current 
 release:
 
* Bit fields (masks of on/off bits) 
 https://github.com/clojurewerkz/buffy#bit-type
* Wrapped buffers (work with existing byte arrays or byte buffers): 
 https://github.com/clojurewerkz/buffy#buffer-types
* Dynamic frames (complex protocol generation and parsing, when you can't 
 know the length of payload 
 in advance, and need to introspect buffer for parsing, or add hint-fields 
 into payload): https://github.com/clojurewerkz/buffy#dynamic-frames
 
 Buffy has been serving us well for recent time, and no major issues were 
 revealed. However, until 
 it reaches GA, we can't guarantee 100% backward compatibility, although we're 
 thought it through
 very well and used our best knowledge to make it right.
 
 Buffy is a ClojureWerkz project, same as Monger, Elastisch, Cassaforte, 
 Neocons, Meltdown and
 many others. 
 
 Let us know what you think!
 
 [1] https://github.com/clojurewerkz/buffy
 [2] http://blog.clojurewerkz.org/blog/2013/11/29/introducing-buffy/
 [2] http://clojurewerkz.org
 
 -- 
 -- 
 You received this message because you are subscribed to the Google
 Groups Clojure group.
 To post to this group, send email to clojure@googlegroups.com
 Note that posts from new members are moderated - please be patient with your 
 first post.
 To unsubscribe from this group, send email to
 clojure+unsubscr...@googlegroups.com
 For more options, visit this group at
 http://groups.google.com/group/clojure?hl=en
 --- 
 You received this message because you are subscribed to the Google Groups 
 Clojure group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to clojure+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/groups/opt_out.

-- 
-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Large File Processing] What am I doing wrong?

[Michael Gardner]

On Jan 21, 2014, at 07:11 , Chris Perkins chrisperkin...@gmail.com wrote:

 This part: (some #{hashed} already-seen) is doing a linear lookup in 
 `already-seen`. Try (contains? already-seen hashed) instead.

Or just (already-seen hashed), given that OP's not trying to store nil hashes.

To OP: note that if you’re storing the hashes as strings (as it appears), 
you’re using 16 more bytes per hash than necessary. If you’re really going to 
be dealing with so many URLs that you’d use too much memory by storing the 
unique URLs directly, then you should probably be storing the hashes as byte 
arrays.

Alternatively, if you’re going to be dealing with REALLY large files and are 
running on Linux/BSD, consider dumping just the URLs to a file and using “sort 
-u” on it. UNIX Sort can efficiently handle files that are too large to fit in 
memory, via external merge sort.

-- 
-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: clojure.java.shell/sh and expand wildcard

[Michael Gardner]

Try (sh “bash” “-c” “ls *.txt”).

On Jan 21, 2014, at 21:51 , John Gabriele jmg3...@gmail.com wrote:

 I'd like to do something like:
 
 user= (require '[clojure.java.shell :as sh])
 user= (sh/sh ls *.txt)
 
 but get:
 
 {:exit 2, :out , :err ls: cannot access *.txt: No such file or 
 directory\n}
 
 even though there *are* a few .txt files present.
 
 That error message is the same one I'd get if I tried:
 
 $ ls '*.txt'  # or
 $ ls \*.txt
 
 How can I get that sh/sh call to work with the wildcard? (Note: I realize I 
 can use Raynes' fs module for this particular example, but I want to be able 
 to pass wildcards to sh/sh in general.)
 
 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 from this group, send email to
 clojure+unsubscr...@googlegroups.com
 For more options, visit this group at
 http://groups.google.com/group/clojure?hl=en
 --- 
 You received this message because you are subscribed to the Google Groups 
 Clojure group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to clojure+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/groups/opt_out.

-- 
-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Clojure development laptop battery usage

[Michael Gardner]

On Jan 20, 2014, at 11:14 , Mars0i marsh...@logical.net wrote:

 Just to be clear, Leiningen only eats CPU when started in an arbitrary 
 directory.  When started from a Leiningen project directory, it doesn't use 
 CPU unless I tell it to.  I have not investigated what it is in the project 
 directory that Leiningen needs in order to feel at peace. :-) 

I don’t see this behavior on my MBP with latest Leiningen. Have you reported it 
to the lein devs?

-- 
-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [ANN] play-clj, a game library

[Michael Gardner]

On Jan 20, 2014, at 09:31 , Zach Oakes zsoa...@gmail.com wrote:

 Today I'm releasing play-clj, a Clojure wrapper for LibGDX that allows you to 
 write games for desktop OSes, Android, and iOS from the same Clojure codebase.

Neat!

How is Clojure’s performance on the latest Android devices? Good enough for 
simple real-time games while still remaining more-or-less idiomatic?

Also, does running Java on iOS still require jailbreaking?

-- 
-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Contributors needed for Rouge (Clojure on Ruby)

[Michael Gardner]

On Jan 4, 2014, at 11:52 , gvim gvi...@gmail.com wrote:

 This looks like the best of the scripting language implementations of Clojure 
 in that it attempts to match the JVM implementation on PyPy. Sadly, however, 
 there doesn't seem to have been any activity since last April so it may be a 
 dead project.

It’s dead, Jim [1]. Hopefully the landscape for alternative Clojure hosts will 
improve with the completion of CinC [2].

[1] https://groups.google.com/d/msg/clojure-py-dev/HbeNEkIG23U/61rN0wR2qDwJ
[2] https://github.com/Bronsa/CinC

-- 
-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Finding available methods or docs for a value type

[Michael Gardner]

On Dec 24, 2013, at 07:58 , John Kida jdk...@gmail.com wrote:

 Or is there some technique I can use in the repl to tell me what methods are 
 available to work with this particular datastructure.. that sounds not 
 possible due to the dynamic lisp nature of clojure, but I wanted to ask the 
 community to see if there were some good strategies to learning and finding 
 available methods to work with a particular value.

I don’t know of a programmatic way to enumerate the fns that operate on a given 
type of data structure (would be nontrivial since Clojure is dynamically 
typed). But there are good references like clojuredocs.org (sadly not yet 
updated beyond Clojure 1.3, but still useful) and http://clojure.org/cheatsheet.

-- 
-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Breaking out of a map type function

[Michael Gardner]

On Nov 24, 2013, at 10:19 , David Simmons shortlypor...@gmail.com wrote:

 I wish to process each item in a vector. I know I can use map to do this e.g. 
 (map my-func my-vector). My problem is that I need to be able to break out of 
 the map if my-func returns an error when processing any of the items. I know 
 map isn't what I'm looking for but is there a function or some idiomatic 
 piece of clojure to achieve my aim.

If you only want to break when there's an error, you could use exceptions.

Alternatively, if my-func ordinarily doesn't return nil, you could take 
advantage of map's laziness by having my-func return nil on failure-- then you 
just stop consuming the output of map when you hit a nil value.

-- 
-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Potential improvement to select-keys ?

[Michael Gardner]

On Nov 1, 2013, at 14:18 , Mark Engelberg mark.engelb...@gmail.com wrote:

 I'm sure it's possible to imagine both needs, but if you have have a 
 sorted-map, and you do a select-keys, don't you think the principle of least 
 surprise is for it to stay a sorted-map?

I'm not sure about that, given how map and similar functions behave. And with 
the point Cedric raised about records, I think it's better to have consistent 
behavior (always return a regular map).

-- 
-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Request for help optimising a Clojure program

[Michael Gardner]

On Oct 23, 2013, at 12:30 , Andy Fingerhut andy.finger...@gmail.com wrote:

 If you can think of a different hash function for vectors that doesn't lead 
 to these types of collisions, I'm all ears.  The issue is that the hash 
 function for sets adds up the hash values of its elements.  Those sums of 
 vector hash values are what are colliding, not the individual vector hash 
 values themselves.

What about the formula used by Boost's hash_combine?

http://stackoverflow.com/questions/4948780/magic-number-in-boosthash-combine

-- 
-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Request for help optimising a Clojure program

[Michael Gardner]

On Oct 23, 2013, at 14:34 , Mark Engelberg mark.engelb...@gmail.com wrote:

 Another example of why this has more to do with the hashing of sets, than 
 underlying elements:
 = (hash #{#{1 2} 3})
 6
 = (hash #{#{1 3} 2})
 6

The hash-combining function for sets must be commutative. But in order for the 
hashes of #{#{1 2} 3} and #{#{1 3} 2} to be unequal, it must also be 
non-associative. That's possible, but I'm not sure what would be a good 
candidate function. Something involving averaging, perhaps?

-- 
-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Request for help optimising a Clojure program

[Michael Gardner]

On Oct 23, 2013, at 17:03 , Mark Engelberg mark.engelb...@gmail.com wrote:

 It is true that it must be commutative, but not true that it must be 
 non-associative.  Here is a sample implementation of a hash function for sets 
 that is commutative and associative but doesn't collide for these sorts of 
 common rearrangements.  The idea of this proof of concept is that the hash 
 value of a set is the sum of (expt 3 (abs (hash item))) for each item in the 
 set.

Associativity is only meaningful for binary operators-- I was assuming a binary 
hash-combining function that would be applied via reduce or such. The function 
you've described can't be implemented as a binary operator without changing its 
behavior, so it can't be described as associative. But you're right that Set's 
hash function doesn't need to be associative, since it doesn't actually need to 
be a binary operator.

BTW, while looking into this I discovered that Clojure already defines a 
function clojure.lang.Util/hashCombine that uses Boost's hash-combining 
algorithm, but it doesn't seem to be used for anything except Symbols at the 
moment.

-- 
-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: tools for minimizing forward declaration

[Michael Gardner]

On Aug 19, 2013, at 06:38 , Tim Visher tim.vis...@gmail.com wrote:

 The most annoying thing to me about forward declaration is that it
 prevents what Uncle Bob calls 'Newspaper Style Code' where I can
 structure my code in such a way that the high-level functions are
 right at the top and the primitives that they might need are found
 below so that I or someone else who needs to read me code can stop
 reading at any point and only miss some details about how things work.

On the other hand, it doesn't take much to get used to reading source files 
from the bottom up. And I'd consider it a (minor) benefit that Clojure 
encourages this organization, as opposed to languages that don't care where in 
the file you put your functions.

Not that I'd be against doing things another way; I just haven't been bothered 
much by Clojure's backwards orientation and the occasional 
forward-declaration.

-- 
-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Wrong documentation of contains?

[Michael Gardner]

Wouldn't changing collection to associative collection be enough? Though 
maybe a note about its behavior on vectors would also be good.

On Aug 7, 2013, at 11:15 , Mark Engelberg mark.engelb...@gmail.com wrote:

 Yes, the discussion about contains? has come up before, but there's a new 
 aspect to this particular instance of the discussion that most of the posts 
 seem to be ignoring.
 
 The original poster specifically pointed out that his sequence was 
 constructed by calling the `keys` function on a map:
 (keys {:a f :b 23})
 
 He then went on to point out that it doesn't return just a regular, ordinary 
 lazy sequence, but some sort of special type called a KeySeq.
 
 The documentation says that `contains?` looks for whether a given key is 
 present.  Probably when the documentation was written, there was some 
 assumption that by saying it looks for a key, that makes it obvious it only 
 works on associative collections.
 
 But look here, we've got a sequence of keys.  We know it is comprised of 
 keys, and obviously Clojure knows it is a sequence just of keys (because of 
 the custom type).  Therefore, it was reasonable for the poster to think that 
 `contains?` would work on to determine whether a given key was in the 
 collection -- it is a collection with keys!
 
 So I think the new idea here, worthy of discussion, is this:
 
 How can we reword the doc for `contains?` so that it clearly does not apply 
 to a sequence of keys?
 
 -- 
 -- 
 You received this message because you are subscribed to the Google
 Groups Clojure group.
 To post to this group, send email to clojure@googlegroups.com
 Note that posts from new members are moderated - please be patient with your 
 first post.
 To unsubscribe from this group, send email to
 clojure+unsubscr...@googlegroups.com
 For more options, visit this group at
 http://groups.google.com/group/clojure?hl=en
 --- 
 You received this message because you are subscribed to the Google Groups 
 Clojure group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to clojure+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/groups/opt_out.
  
  

-- 
-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: putting 2-element colls into a map: works with vectors, but not with lists?

[Michael Gardner]

On Jun 25, 2013, at 15:03 , Michael-Keith Bernard (SegFaultAX) 
mkbernard@gmail.com wrote:

 https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/APersistentMap.java#L24
 
 The implementation assumes you're attempting to conj one of the following 3 
 things into the hash map:
   • A MapEntry object
   • A vector of the format [key value]
   • A seq of MapEntry objects (commonly created via 
 http://docs.oracle.com/javase/6/docs/api/java/util/HashMap.html#entrySet() 
 and the like)

If I read you correctly, you're saying the reason 'into et al. can't accept 
arbitrary two-element collections for adding to a map is that APersistentMap's 
.cons method does something special with seqable things that aren't vectors. 
Right?

Any insight into why Rich would have written .cons that way, instead of putting 
that seq-of-MapEntry functionality into a separate method?

-- 
-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: putting 2-element colls into a map: works with vectors, but not with lists?

[Michael Gardner]

On Jun 24, 2013, at 11:14 , Sean Corfield seancorfi...@gmail.com wrote:

 On Mon, Jun 24, 2013 at 8:49 AM, John Gabriele jmg3...@gmail.com wrote:
 Why does `into` fail when the 2-element collections are lists and not
 vectors? :
 
 Because the implementation special cases vectors :)
 
 It's the one place where a two element vector is treated like a
 Map$Entry so that you are not forced to somehow create Map$Entry
 instances for the key/value pairs.

Huh. I had assumed this would work with any 2-element collection, like 
destructuring. Why not? Performance reasons?

-- 
-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: lazy sequence termination

[Michael Gardner]

On May 28, 2013, at 15:05 , Mond Ray mondraym...@gmail.com wrote:

 Quite a few views but no bites ... what have I done wrong in asking this 
 question? If you can't help with the problem would you please take a moment 
 to help me understand what has put you off? 

It would help to post less code, to make it easier for people to zero in on the 
critical parts. For example, it's not necessary to include 'fetch-atom-chunk 
and 'fetch-atom-feed since you can just post some sample parsed data (which you 
did).

When I try running your predicate against your sample data, the predicate 
returns false because 2013-05-27 isn't after the feed's :UPDATED date. Might 
you have the arguments to 'after? reversed?

-- 
-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: noob question about try/catch

[Michael Gardner]

On Apr 26, 2013, at 10:01 , larry google groups lawrencecloj...@gmail.com 
wrote:

 java.lang.RuntimeException: java.sql.SQLException: Cannot convert value 
 '-00-00 00:00:00' from column 6 to TIMESTAMP.

I believe Clojure is wrapping the java.sql.SQLException in a 
java.lang.RuntimeException because of reasons[1][2], so you'd need to catch 
java.lang.RuntimeException and examine the exception's cause property to get 
the real exception.

[1] http://dev.clojure.org/jira/browse/CLJ-855
[2] https://groups.google.com/d/msg/clojure/I5l1YHVMgkI/nt8t9aHNVEYJ

-- 
-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: noob question about try/catch

[Michael Gardner]

On Apr 26, 2013, at 11:55 , Michael Gardner gardne...@gmail.com wrote:

 I believe Clojure is wrapping the java.sql.SQLException in a 
 java.lang.RuntimeException because of reasons[1][2], so you'd need to catch 
 java.lang.RuntimeException and examine the exception's cause property to get 
 the real exception.
 
 [1] http://dev.clojure.org/jira/browse/CLJ-855
 [2] https://groups.google.com/d/msg/clojure/I5l1YHVMgkI/nt8t9aHNVEYJ

…though I just noticed that JIRA issue was closed in 1.3, so unless you're 
still on 1.3 it doesn't actually explain why you're getting wrapped exceptions.

-- 
-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: merge nested maps

[Michael Gardner]

On Apr 25, 2013, at 15:41 , Joachim De Beule joachim.de.be...@gmail.com wrote:

 I was searching for an easy way to combined nested maps, e.g. as in 
 
 (combine {:foo {:bar baz}} {:foo {:x y}})
 = {:foo {:bar baz, :x y}}

user= (merge-with merge {:foo {:bar baz}} {:foo {:x y}})
{:foo {:x y, :bar baz}}

If you need to support more than one level of nesting, you could try something 
like:

(defn combine [ maps]
(apply merge-with combine maps))

-- 
-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Parallelizing tasks

[Michael Gardner]

On Apr 10, 2013, at 21:46 , Ulises ulises.cerv...@gmail.com wrote:

 Have you tried replacing all your calls to map for pmap yet?

That will not work. He'll need to rearrange his algorithm to something like 
this before pmap will help:

(defn iterated-difference [f a b]
Yields a lazy seq of the differences between (iterate f a) and (iterate f 
b).
(cons (doto (double (- b a)) println)
(lazy-seq (apply iterated-difference f (pmap f [a b])

Might need to wrap this in a (doall …) or such to see progressive output from 
the println.

-- 
-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: how can I count lines of code?

[Michael Gardner]

On Mar 27, 2013, at 14:36 , larry google groups lawrencecloj...@gmail.com 
wrote:

 I am curious, is there a simple command line script I could use to count 
 lines of code? Or is there some trick in emacs that I can do? I'd like to 
 know how many lines there are, minus the comments and white space. 

On Linux or Mac, try `wc' (the first number printed is the one you want). To 
omit whitespace and comments, you could pipe the file through grep -v first:

$ grep -vxE '[[:space:]]*(;.*)?' file.clj | wc
117 4493567

That regular expression matches any line that consists of zero or more 
whitespace characters, followed by an optional suffix that starts with a 
semicolon. Not perfect, but should be good enough for most purposes.

(Cue the old now you have two problems joke about regexes…)

-- 
-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Get difference between two lists with java objects of same class

[Michael Gardner]

On Mar 11, 2013, at 17:09 , Ryan arekand...@gmail.com wrote:

 What if, i had two clojure lists, with hash-maps which have the same keys and 
 based on a specific key, i wanted to find the items from list-a which do not 
 exist in list-b. Would i go with the two functions you suggested or is there 
 something else I could use?

Assuming :id is the key you care about:

(filter (comp (complement (set (map :id list-b))) :id)
list-a)

user= (defn rand-seq [n] (repeatedly #(rand-int n)))
#'user/rand-seq
user= (def list-a (map (partial hash-map :id) (take 5 (rand-seq 10
#'user/list-a
user= list-a
({:id 8} {:id 4} {:id 5} {:id 1} {:id 6})
user= (def list-b (map (partial hash-map :id) (take 5 (rand-seq 10
#'user/list-b
user= list-b
({:id 9} {:id 6} {:id 3} {:id 6} {:id 3})
user= (filter (comp (complement (set (map :id list-b))) :id) list-a)
({:id 8} {:id 4} {:id 5} {:id 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
--- 
You received this message because you are subscribed to the Google Groups 
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Get difference between two lists with java objects of same class

[Michael Gardner]

On Mar 12, 2013, at 04:11 , Marko Topolnik marko.topol...@gmail.com wrote:

 This is almost exactly the same as the one from an earlier post here:
 
 (remove (comp (into #{} (map key-fn list-b)) key-fn) list-a) 
 
 I'd prefer remove to filter + complement, though.

Ah, I should have read the rest of the thread more carefully. I keep forgetting 
that 'remove exists.

I do prefer 'set and friends to 'into, though.

-- 
-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: contains? for vectors

[Michael Gardner]

On Feb 28, 2013, at 17:17 , AtKaaZ atk...@gmail.com wrote:

 According to this, can a vector have keys that are not numbers? like :a , if 
 not, then wouldn't it make more sense that
 (contains? [:a :b :c] :a)  would throw ? It's probably just me.

This is a reasonable point, and one I haven't seen made before. The only 
problem I can see with throwing an exception is that one might sometimes wish 
to deal with associative containers in a generic fashion, and thus end up 
asking a vector if it contains a keyword or a string without doing so 
explicitly. In that case you'd not want it to throw an exception any more than 
the other associative collection types would.

-- 
-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: contains? for vectors

[Michael Gardner]

On Mar 1, 2013, at 13:36 , AtKaaZ atk...@gmail.com wrote:

 I don't think I understand what you mean (could you rephrase/example?), I 
 cannot think of a case when I wouldn't want it to throw when I'm passing a 
 non-number (contains? [:a :b :c] :a), I mean, rather than just silently 
 ignoring.

I'm talking about a case where you have one or more associative containers of 
unknown types, and you want to be able to generically ask them whether they 
contain a particular key. E.g.:

(defn has-foo? [c] ;; c is only known to be Associative
  (contains? c :foo))

Insofar as a vector can be viewed as a kind of associative container, one might 
expect/desire this code to just return false if c happens to be a vector. One 
could see this as a question about the contract promised by the Associative 
interface: is is always OK to ask an Associative container whether it contains 
a given key, or are implementations free to accept only certain kinds of keys? 
I could go either way on that personally, but I can't find any docs that 
support one interpretation or the other.

 It;s not unlike this:
 = (contains? '(:a :b :c) :a)
 IllegalArgumentException contains? not supported on type: 
 clojure.lang.PersistentList  clojure.lang.RT.contains (RT.java:724)
 
 it throws because, it's similarly better than just ignoring it and 
 propagating the bug somewhere else.

Different case, because lists aren't Associative.

 In a way, it's already so for String:
 = (contains? aaa 1)
 true
 = (contains? aaa 3)
 false
 = (contains? aaa a)
 IllegalArgumentException contains? not supported on type: java.lang.String  
 clojure.lang.RT.contains (RT.java:724)
 = (contains? aaa 'a)
 IllegalArgumentException contains? not supported on type: java.lang.String  
 clojure.lang.RT.contains (RT.java:724)

This one's actually quite surprising to me. I don't know why 'contains? throws 
when given a String and a non-numeric argument, since that's inconsistent with 
its behavior on vectors (and the exception's description seems inaccurate, 
since 'contains? *is* supported on Strings). Even more strangely:

user= (contains? abc 1.5)
true

I have no explanation for 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 unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: contains? for vectors

[Michael Gardner]

This is a sore spot that has been discussed many times on this list[1]. The 
short version is that many people agree that the name contains? is misleading 
to newcomers, but according to Rich it's not changing any time soon[2]. What 
you want for linear searches is 'some (as mentioned in the doc for 'contains?).

Also, why are you quoting your vectors (e.g. '[:a :b :c] instead of just [:a :b 
:c])?

[1] Most recently, 
https://groups.google.com/d/msg/clojure/wNFdG11zMMo/OC9ezSn9nRAJ
[2] https://groups.google.com/d/msg/clojure/bSrSb61u-_8/3-wjAkJ4VJgJ

-- 
-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Clojure Performance For Expensive Algorithms

[Michael Gardner]

On Feb 24, 2013, at 10:46 , Marko Topolnik marko.topol...@gmail.com wrote:

 from what I hear, idiomatic Haskell is a performance devil as well

Does this mean very good, or very bad?

On a related note, is there currently any way to get the Clojure compiler to 
tell you where boxing is occurring, like *warn-on-reflection* does for 
reflection?

-- 
-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: clojure API documentation

[Michael Gardner]

On Jan 29, 2013, at 11:42 , cej38 junkerme...@gmail.com wrote:

   Should these symbols be added to the documentation?

The dot is documented at http://clojure.org/java_interop#dot -- which you'll be 
pointed to if you try (doc .) at a repl. It's also linked from 
http://clojure.org/special_forms.

It's not in the API docs because it's a special form (same as `if', for 
example). I think this is because the API docs are automatically generated and 
so don't know about special forms, only functions, macros, and vars.

-- 
-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [ANN] vectorz-clj - high performance vector maths for Clojure

[Michael Gardner]

On Dec 2, 2012, at 06:24 , Mikera mike.r.anderson...@gmail.com wrote:

 Contributions / comments / suggestions very welcome. API is not yet set in 
 stone, so I'm very open to ideas on how to make it better.

Since the vast majority of physical applications will use 2D or 3D vectors, did 
you consider building around javax.vecmath? I have to imagine that would be 
faster than any generic vector implementation. I believe Zach Tellman's cantor 
(no longer maintained) used a similar approach.

-- 
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: Can anyone explain this behavior of clojure.java.shell/sh ?

[Michael Gardner]

I can't duplicate your results on my Debian wheezy box (Clojure 1.4, openjdk 
1.6.0_24, xdg-open 1.1.0 rc1); the call to (sh xdg-open …) returns 
immediately. The only possibilities I can think of are that your version of 
xdg-open blocks when run from a non-interactive shell, or that your version of 
Java somehow handles subprocesses differently.

The first possibility should be easy to test. And you should be able to test 
the second by writing your own shell script that forks and then exits (at 
least, I assume that's what xdg-open is doing).

On Nov 9, 2012, at 19:26 , Andy Fingerhut andy.finger...@gmail.com wrote:

 This issue may be specific to Linux, or even to a particular version of Linux 
 that I am using (Ubuntu 11.10 32-bit desktop), although I doubt it is.  If 
 others try this out, I'd be curious to know what your results are, especially 
 if you know why it is happening, and how it can be fixed.
 
 First, some behavior from a bash window on Ubuntu 11.10:
 
 % echo hi
 hi
 % xdg-open http://www.google.com
 %
 
 After pressing return for the xdg-open command above, my browser opens a tab 
 to Google's home page.  Back in the shell window, the next prompt appears 
 immediately, even though the browser is still running and open to that page.  
 That is what I expect to happen.
 
 However, if I do the following commands inside of a Clojure REPL (tested 
 Clojure 1.4 and 1.5-beta1 so far):
 
 % rlwrap java -cp ~/lein/clojure-1.4.0/lib/clojure-1.4.0.jar clojure.main
 Clojure 1.4.0
 user= (require '[clojure.java.shell :as sh])
 nil
 user= (sh/sh echo hi)
 {:exit 0, :out hi\n, :err }
 user= (sh/sh xdg-open http://www.google.com;)
 
 The invocation of echo returns immediately, printing the result and the next 
 REPL prompt.  But when I invoke xdg-open, while the browser window appears 
 and goes to the Google home page, back in the bash window I see no return 
 value and no new REPL prompt.
 
 If I quit the browser, then back in the bash window I finally see the return 
 value and a REPL prompt, as shown below:
 
 {:exit 0, :out , :err }
 user= 
 
 
 What I'm wishing would happen is for the return value and REPL prompt to 
 appear very soon after pressing return when invoking xdg-open with 
 clojure.java.shell/sh.
 
 I added some debug print messages to a local copy of clojure.java.shell/sh, 
 and it is stopping when waiting for the evaluation of either @out or @err in 
 the final line of the function.
 
 If I do the same commands above on Mac OS X, with open instead of 
 xdg-open, it all works as I expect.
 
 Any clues?
 
 Thanks,
 Andy
 
 -- 
 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: Cdr car

[Michael Gardner]

On Nov 6, 2012, at 11:48 , Sean Corfield seancorfi...@gmail.com wrote:

 On Tue, Nov 6, 2012 at 9:34 AM, JvJ kfjwhee...@gmail.com wrote:
 There's quite a number of functions like caar, cadr, cadadr, etc.  It's
 lengthy to do that in clojure with just first and rest.
 
 Clojure does have ffirst, fnext, nfirst, nnext tho' - and I'd question
 why you'd need to string several of them together... almost sounds
 like you'd want different data structures or a more descriptive way to
 access data in them? Perhaps vectors and maps and get-in?

Don't forget destructuring! I love that Clojure's pervasive destructuring 
support single-handedly eliminates many of these problems.

-- 
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: Evaluating an anonymous function with closure

[Michael Gardner]

On Oct 16, 2012, at 5:16 AM, Jim foo.bar wrote:

 so you're saying that if I write a for-loop in Java that populates an array 
 with constants from 1-1 and then a 2nd loop to add them up, it would 
 happen at compile-time and i would get the same timing-result?

Maybe, maybe not. Compilers are very smart these days, but I don't know if they 
can fold complex expressions like for-loops.

-- 
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: Evaluating an anonymous function with closure

[Michael Gardner]

On Oct 15, 2012, at 7:45 PM, Andy Fingerhut wrote:

 For the case of arithmetic on compile-time constants, I believe that many C, 
 Java, etc. compilers already perform the arithmetic at compile time.

Known as constant folding, yes.

-- 
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: genuine help needed to speed up minimax algorithm!

[Michael Gardner]

If you haven't already, start by eliminating reflection warnings[1].

As for pmap, it's unfortunately useless. You could roll your own using e.g. 
Java's thread pools, or you could wait for the new reducers library[2]. 
Reducers should offer not only useful parallelism, but also better performance 
across-the-board compared to clojure's sequence functions (since they don't pay 
the performance price of laziness).

[1] http://clojuredocs.org/clojure_core/clojure.core/*warn-on-reflection*
[2] 
http://clojure.com/blog/2012/05/08/reducers-a-library-and-model-for-collection-processing.html

-- 
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: genuine help needed to speed up minimax algorithm!

[Michael Gardner]

On Aug 18, 2012, at 7:27 AM, Jim - FooBar(); wrote:

 As far as pmap goes, I originally thought of starting a new future for each 
 starting branch but that is what pmap does essentially, so it looked very 
 handy at first...

Yes, pmap is essentially a trap in that it looks like the perfect tool for some 
light parallelism, but it works so poorly in the vast majority of cases that 
it's basically useless. There have been a few discussions on this list about it 
in the past.

 I don't see how reducers can help here because I'm not reducing anything 
 really.

You should read the link I posted about reducers. It's good stuff.

 I just wish pmap  worked!

So do I. Until the reducers library is ready, you could try something like this 
(no guarantees that this is an optimal implementation!):

(defn with-thread-pool* [num-threads f]
  (let [pool (java.util.concurrent.Executors/newFixedThreadPool num-threads)]
(try (f pool)
  (finally
(when pool (.shutdown pool))

(defmacro with-thread-pool [[name num-threads]  body]
  `(with-thread-pool* ~num-threads (fn [~name] ~@body)))

(defn pmap-pool [f coll]
  (with-thread-pool [pool (.. Runtime getRuntime availableProcessors)]
(doall
  (map #(.get %)
(.invokeAll pool
  (map (partial partial f)
coll))

-- 
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: Just wanted to say how much I like ClojurePY

[Michael Gardner]

On Aug 16, 2012, at 8:52 AM, Timothy Baldridge wrote:

 With pip/easy_install and virtual_env, there's really not much of a point. 
 Would lein-py be nice? Yeah, but it's hardly a show-stopper.

What's the story like for code that depends on another clojure-py library? 
Would the Python Package Index accept clojure-py libraries?

-- 
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: Question about sets

[Michael Gardner]

On Aug 5, 2012, at 4:18 PM, Mark Engelberg wrote:

 Also, although it was a breaking change to add throw-on-duplicate behavior to 
 many types of maps and sets, reverting back to 1.2 behavior could not 
 possibly be a breaking change in the literal sense.  Anyone whose code 
 works right now on 1.4, by definition, has no duplicate keys.  Therefore, 
 relaxing the restriction on duplicate keys can't possibly affect their 
 existing code and cause it to break.

Not quite true; imagine some code that tried to construct a set literal from 
some variables, catching IllegalArgumentException to deal with duplicate values.

But I doubt there's any code in the wild that relies on this behavior yet, and 
I agree that set literals should be reverted to the 1.2 behavior.

-- 
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: Alternative to (or (:k1 m) (:k2 m))

[Michael Gardner]

On Jul 31, 2012, at 12:00 AM, Ben Smith-Mannschott wrote:

 ((some-fn :k1 :k2) m)

Ah, excellent. Yet another hidden gem in clojure I'd somehow overlooked until 
now!

-- 
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

Alternative to (or (:k1 m) (:k2 m))

[Michael Gardner]

Is there an elegant way to say '(or (:k1 m) (:k2 m)), without repeating m? 
Using a let can be awkward if the expression isn't already wrapped in one; 
'(apply #(or %1 %2) (map m [:k1 :k2])) is similarly bad. Hopefully there's 
something clever I'm missing; any ideas?

-- 
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: Alternative to (or (:k1 m) (:k2 m))

[Michael Gardner]

On Jul 30, 2012, at 6:08 PM, Aaron Cohen wrote:

 For even more fun, try (some m [:k1 :k2]) :)

Wow, that's perfect. It even works with string keys! Thanks, guys.

-- 
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: General subsequence function

[Michael Gardner]

On Jun 27, 2012, at 9:39 AM, Warren Lynn wrote:

 I am surprised that there seems to be no general sub-sequence function that 
 will return a segment of a sequence without changing the underlying concrete 
 type. I found subvec, but it works only on vectors. subseq is not what I 
 thought it is. Did I miss anything? Or is there a simple idiomatic way to do 
 it so there is no need for such a function? Thank you.

You can combine 'drop and 'drop-last to get a seq version of subvec (but lazy 
and O(n)). As for the issue of concrete types: in general, clojure's sequence 
functions return seqs, not instances of whatever concrete type you gave them.  
If you need a specific type, you normally just pour the result through 'into or 
one of the specific collection creation functions.

-- 
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: General subsequence function

[Michael Gardner]

On Jun 27, 2012, at 1:02 PM, Warren Lynn wrote:

 Do you mean something like this:
 
 (defn subseqx [s start end] (into (empty s) (drop-last (- (count s) end) 
 (drop start s
 
 Two things I don't like it:
 
 1. It does not work
 (subseqx [1 2 3] 1 3) = [2 3]
 (subseqx '(1 2 3) 1 3) = (3 2)
 because into will reverse the order on sequence.

I'd forgotten that 'into adds things in the default place for whatever type 
you're using, hence the reversal on lists. I'm not sure if there's a simple way 
to get the same type out again while preserving order.

 2. kind of ugly for such a simple thing, and may not be efficient either.
 
 Any SIMPLE way to do it? I need concrete type unchanged. I don't think that 
 is a rare need/use case.

Ordering problem aside, I'd argue this is not an unreasonable amount of code 
for what seems to me a pretty rare set of requirements. Most people who want a 
same-type segment from the middle of an ordered collection (which is already 
uncommon in my experience) are probably either using vectors already or at 
least know what type they're operating on.

 PS: when I say sequences, how should I distinguish between general sequence 
 and concrete sequences? Any conventions for the wording?

Ordered collection is the preferred term for the general concept, I think.

-- 
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: (#({:a %}) :b)

[Michael Gardner]

On Jun 3, 2012, at 8:53 PM, 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 me, because I cannot rely on it but have to always second guess if its 
 use is safe in the current context or not.

#(f ...) expands to (fn [...] (f ...)), so #({:a %}) would be (fn [x] ({:a x})).

In order for #({:a %}) to work as you want, the more common usage #(f %) would 
have to become #((f %)). That seems like a poor trade-off to me.

-- 
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: Different behavior at REPL vs compiled code

[Michael Gardner]

On May 19, 2012, at 3:19 AM, Andy Fingerhut wrote:

 Whereas Perl would automatically convert from a string to a number in a case 
 like this, Clojure does not.  One could argue that such auto-conversion of 
 types, while convenient in many cases in Perl, is also a source of errors in 
 programs.

Indeed. To put it another way, weak typing allows certain logic errors to go 
undetected longer (vs. strong typing). One could argue the same for dynamic vs. 
static typing, but I don't think the same answer has to hold in both cases, 
since the trade-offs differ.

-- 
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: docstrings of if-let and when-let incorrect

[Michael Gardner]

On May 16, 2012, at 8:16 AM, Aaron Cohen wrote:

 Saying something is obvious and then using the word monad a paragraph later 
 is contradictory. ;)

If the word monad is scary, just pretend he said it should short-circuit 
instead. ;)

 What should happen on the else branch of the if-let; which bindings are in 
 scope and what would be their values?

That's an interesting question. For consistency with the current behavior of 
single-binding if-let, the binding whose value was false should be left unbound 
(as well as successive bindings, given short-circuiting); but I could see going 
either way for the bindings that succeeded. I don't think it matters as much 
that this behavior would be non-obvious, though, because I'd predict the common 
case in the else-branch of a multi-binding if-let would be to not care about 
any of the bindings. That's just my guess, though.

-- 
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: Faster application startup for rapid development

[Michael Gardner]

There's also nailgun: it keeps a JVM running in the background that Java 
programs can connect to, eliminating JVM startup time completely. It's totally 
insecure on multi-user machines and hasn't been updated in a while, but it may 
be sufficient to ease the pain on developer machines.

-- 
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: docstrings of if-let and when-let incorrect

[Michael Gardner]

On May 15, 2012, at 3:15 PM, Andy Fingerhut wrote:

 If if-let/when-let had multiple bindings, how would you propose to define the 
 condition of whether to do the then branch?
 
 As the logical AND of all of the multiple forms?  The OR?  Only use the first 
 expression?  Only the last?
 
 I don't see that any of those is any more clear or least surprising than 
 any of the others.  Permitting only one makes that part of the behavior 
 clear, at least.

AND is the obvious choice, IMO. People will probably still have to look up what 
happens with multiple bindings from time to time, but that doesn't seem worse 
than having to look up whether if-let and when-let even support multiple 
bindings.

-- 
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: code as data vs. code injection vulnerability

[Michael Gardner]

On May 9, 2012, at 11:01 AM, Rostislav Svoboda wrote:

 This is the point! On one hand I need to evaluate data from a client
 on the other hand I'd like to filter out things like rm -rf /, drop
 table users etc. To me it looks like a contradiction impossible to
 circumvent. So I ask if there's anything like best practices or even
 better something like a concept of access rights or prepared
 statements in clojure?. AFAIK there isn't any. So this problem must be
 solved on the host platforms (database, operating system etc). To me
 this looks much like a wheel-reinventing...

Or you can just use something like XML or a custom language for data transfer, 
which also avoids trying your clients to Clojure. I've never understood why 
anyone would use prn/read for data transfer, other than extreme laziness.

-- 
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: Returning Success

[Michael Gardner]

If the success/failure of the function makes sense to represent in game-world 
terms, you could encode the information in the world object, perhaps as a flag 
that can be attached to the relevant object. In your example, the unit might be 
given a state with the value :blocked, indicating that something is currently 
blocking its movement.

Another option would be metadata, though that feels ugly to me.

Or the simplest option: just have your functions return nil to indicate that 
the world state should remain unchanged from its previous value.

[Minor nitpick about your email: lisps aren't necessarily functional (e.g. 
Common Lisp).]

-- 
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: Returning Success

[Michael Gardner]

On Mar 19, 2012, at 5:31 PM, Michael Gardner wrote:

 Or the simplest option: just have your functions return nil to indicate that 
 the world state should remain unchanged from its previous value.

If your world state is a hash-map, you could also return partial states and 
merge them into the existing world; that would make nil automatically mean no 
change. Let's say your world has the key :player (among other things):

(defn move-player [{:keys [player ...]} ...]
(when (can-move player)
{:player (assoc player ...)}))

The above returns nil when (can-move player) returns false; otherwise it 
returns a hash-map with only the key :player defined. Then (merge world 
(move-player world ...)) does the right thing, with no special-casing of nil 
needed.

-- 
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: Bret Victor - Inventing on Principle

[Michael Gardner]

On Feb 24, 2012, at 1:51 PM, Daniel E. Renfer wrote:

 Ken Wesson was noted for having strong opinions as was a noted hater of
 videos where text will do.

He was also the only guy who would post replies with just you're welcome as 
the body. Until Cedric, that is...

-- 
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: Why does (= [] (range)) not terminate?

[Michael Gardner]

On Feb 17, 2012, at 12:32 PM, Bill Smith wrote:

 It might help to know that (= (range) (range)) does not terminate either.

Of course, since a pairwise sequential comparison (what I assume is going on 
under the hood) will never find a non-matching pair.

 It appears that the = operator wants to fully evaluate the second argument 
 before comparing to the first.  Since (range) is infinite, it hangs.

Yes, that is what appears to be happening. The question is: why? Why does it 
only do this to the second argument? Why does (= v s) for any vector `v' and 
any infinite lazy sequence `s' not terminate, while (= s v) does?

-- 
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