[ANN] Documentation generator - Receipt Receipt Plugin
Receipt Receipt PluginStandalone and plugin Clojure documentation generator.Standalone [receipt "1.0.1"]Lein Plugin [receipt-plugin "1.0.1"]Usage DocumentationThe documentation for receipt was generated with receipt and can be viewed here$ lein receipt-plugin Writing doc/receipt.core.html Writing doc/receipt.test.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: [ANN] Documentation generator - Receipt Receipt Plugin
Here's the source on Github https://github.com/runexec/receipt-clj 03.11.2013, 17:08, "Kelker Ryan" theinter...@yandex.com:Receipt Receipt PluginStandalone and plugin Clojure documentation generator.Standalone [receipt "1.0.1"]Lein Plugin [receipt-plugin "1.0.1"]Usage DocumentationThe documentation for receipt was generated with receipt and can be viewed here$ lein receipt-plugin Writing doc/receipt.core.html Writing doc/receipt.test.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. -- -- 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.
[ANN] Imagez 0.2.0
Hi All, I made some updates to my lightweight Clojure bitmap image processing library. - https://github.com/mikera/imagezhttps://github.com/mikera/imagez/tree/develop Builds available from clojars here: - https://clojars.org/net.mikera/imagez Main interesting addition is the addition of a few image filtering functions, wrapping some of the excellent (and fast!) JH Labs image filters (see http://www.jhlabs.com/ip/filters/index.html). If there is more demand for these, happy to wrap more of them up with the Clojure API for general consumption. Mike. -- -- 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: Functions using locks are slowed even when locks are never taken
same results on my machine as well. I tried decompiling the jar (with cider-decompile), and the parts that actually run (the then clause) seems almost identical. If you'r interested, i can post them later tonight. On Sunday, November 3, 2013 2:32:42 AM UTC+2, Michael Blume wrote: Hmm, it seems like if it were JIT related you'd see the same issue with java code, but I get 5ns across the board. https://github.com/MichaelBlume/perf-test/blob/master/src-java/PerfTest.java On Saturday, November 2, 2013 12:01:01 AM UTC-7, Trenton Strong wrote: Verified that I receive the same result patterns as you on my machine. One other possibility outside of what you have already mentioned would be something JIT-related. Perhaps there is an optimization that can be performed if the locking sections of the code are in another function but otherwise no, but I'm not sure how that dovetails with Clojure' fn compilation. On Friday, November 1, 2013 11:53:12 AM UTC-7, Michael Blume wrote: Since 1.6 alpha is out, I reran the tests with that -- basically the same results. On Friday, November 1, 2013 11:34:15 AM UTC-7, Michael Blume wrote: https://github.com/MichaelBlume/perf-test (ns perf-test (:use (criterium core)) (:gen-class)) (def o (Object.)) (defn foo [x] (if ( x 0) (inc x) (do (monitor-enter o) (let [res (dec x)] (monitor-exit 0) res (defn bar [x] (if ( x 0) (inc x) (dec x))) (defn locking-part [x l] (monitor-enter l) (let [res (dec x)] (monitor-exit l) res)) (defn baz [x] (if ( x 0) (inc x) (locking-part x o))) (defn -main [] (println benching foo) (bench (foo 5) :verbose) (println benching bar) (bench (bar 5) :verbose) (println benching baz) (bench (baz 5) :verbose) (println done benching)) I'm only ever calling these functions with positive values, so the monitor-enter branch should never be entered. Nevertheless, the performance of foo is much worse than bar or baz. The best guess I've got is that the fact that lock-taking is involved somehow changes how the function is compiled, somehow making the function slower. If the practical upshot is that I shouldn't write functions that only sometimes lock -- that the locking part of a function should always be its own function -- then I can do that, but I'm curious why. $ lein uberjar Compiling perf-test Created /Users/mike/perf-test/target/perf-test-0.1.0-SNAPSHOT.jar Created /Users/mike/perf-test/target/perf-test-0.1.0-SNAPSHOT-standalone.jar $ java -jar -server target/perf-test-0.1.0-SNAPSHOT-standalone.jar benching foo WARNING: Final GC required 1.5974571326266802 % of runtime x86_64 Mac OS X 10.8.3 4 cpu(s) Java HotSpot(TM) 64-Bit Server VM 24.0-b28 Runtime arguments: Evaluation count : 391582560 in 60 samples of 6526376 calls. Execution time sample mean : 167.426696 ns Execution time mean : 167.459429 ns Execution time sample std-deviation : 4.079466 ns Execution time std-deviation : 4.097819 ns Execution time lower quantile : 160.742869 ns ( 2.5%) Execution time upper quantile : 175.453376 ns (97.5%) Overhead used : 1.634996 ns Found 2 outliers in 60 samples (3. %) low-severe 2 (3. %) Variance from outliers : 12.5602 % Variance is moderately inflated by outliers benching bar x86_64 Mac OS X 10.8.3 4 cpu(s) Java HotSpot(TM) 64-Bit Server VM 24.0-b28 Runtime arguments: Evaluation count : 2174037300 in 60 samples of 36233955 calls. Execution time sample mean : 26.068923 ns Execution time mean : 26.066422 ns Execution time sample std-deviation : 0.887937 ns Execution time std-deviation : 0.916861 ns Execution time lower quantile : 23.996763 ns ( 2.5%) Execution time upper quantile : 27.911936 ns (97.5%) Overhead used : 1.634996 ns Found 3 outliers in 60 samples (5. %) low-severe 1 (1.6667 %) low-mild 1 (1.6667 %) high-mild1 (1.6667 %) Variance from outliers : 22.1874 % Variance is moderately inflated by outliers benching baz x86_64 Mac OS X 10.8.3 4 cpu(s) Java HotSpot(TM) 64-Bit Server VM 24.0-b28 Runtime arguments: Evaluation count : 2270676660 in 60 samples of 37844611 calls. Execution time sample mean : 25.834142 ns Execution time mean : 25.837429 ns Execution time sample std-deviation : 0.718382 ns Execution time std-deviation : 0.729431 ns Execution time lower quantile : 24.837925 ns ( 2.5%) Execution time upper quantile : 27.595781 ns (97.5%) Overhead used : 1.634996 ns Found 4 outliers in 60 samples (6.6667 %) low-severe 2 (3. %) low-mild 2 (3. %) Variance from outliers : 15.7591 % Variance is moderately inflated by outliers done benching -- -- You received this message because you are
Re: assoc / dissoc consistency, maps and vectors
You also assume keys are comparable or that 'conj order' is retained, which
is often not true. Consider following map:
(your-dissoc {2 1, :a 1, foo 1, 'bar 1} 2)
=
Vectors are indexed and maps are associative. These two concepts share some
functionalities (assoc, get), but are otherwise very different.
JW
On Sat, Nov 2, 2013 at 11:12 PM, vrak...@gmail.com wrote:
On Saturday, November 2, 2013 4:56:13 PM UTC-5, Jozef Wagner wrote:
Problem is, when your proposed dissoc removes value from a vector, it
shifts all larger keys. So dissoc would not only remove value at index
position, but also change keys for pther values. And this is not what
dissoc should do
You're right. I'm not sure why this is suddenly clear without essentially
any new information. :) I think I had the wrong conceptual impression of
what assoc and dissoc should be, putting the emphasis on the generality of
the collection types instead its specificity to the indicies.
For my notion of assoc/dissoc to hold parity, it would have to work like
this which seems undesirable:
(def some-vector ['a 'b 'c 'd 'e])
(def some-map {0 'a 1 'b 2 'c 3 'd 4 'e})
(assoc some-vector 2 'x)
;= [a b x d e]
(dissoc some-vector 2) ;; theoretical
;= [a b d e] ;; theoretical
(assoc some-map 2 'x)
;= {0 a, 1 b, 2 x, 3 d, 4 e}
(dissoc some-map 2)
;= {0 a, 1 b, 2 d, 3 e} ;; not good
--
--
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: Scala interop (or, aliasing imported Java classes)
Mark mjt0...@gmail.com writes: I think my preferred solution would be to allow imported Java classes to be aliased, so I could do this: (import '(org.fooinstitute.team.library.foo package :as foop)) = org.fooinstitute.team.library.foo.package (foop/isFoo foop) = false But to the best of my knowledge (and searching), that doesn't exist in Clojure. Clojure doesn’t provide it as a part of the `ns` or `import` forms, but the underlying `Namespace` objects support it just fine, and then almost everything works as you’d expect w/ the arbitrary alias: user (.importClass *ns* 'Q java.util.concurrent.LinkedBlockingQueue) java.util.concurrent.LinkedBlockingQueue user Q java.util.concurrent.LinkedBlockingQueue user (Q.) #LinkedBlockingQueue [] user (fn [q x] (.offer q x)) Reflection warning, /tmp/form-init7252328014986537096.clj:1:11 - call to offer can't be resolved. #user$eval1302$fn__1303 user$eval1302$fn__1303@ece88d2 user (fn [q x] (.offer ^Q q x)) #user$eval1308$fn__1309 user$eval1308$fn__1309@251c4123 HTH, -Marshall -- -- 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: What's the -dup in print-dup?
John Mastro john.b.mas...@gmail.com writes: This isn't a very deep question, but I wonder every time I come across it: to what does -dup in `print-dup` and `*print-dup*` refer? I don’t have any special knowledge in this regard, but I’ve always thought of it as “duplicate,” which makes some sense when you think of how it’s used. AFAIK, `print-dup` exists to provide objects which doen’t normally print to `read`able form an alternative form which is `read`able. The compiler can then use the `print-dup` form to embed instance objects in code, by generating code which produces duplicates via round-tripping through the reader. user (print-method (fn []) *out*) #user$eval1328$fn__1329 user$eval1328$fn__1329@6dc8f3cd nil user (print-dup (fn []) *out*) #=(user$eval1332$fn__1333. ) nil -Marshall -- -- 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: Functions using locks are slowed even when locks are never taken
You have a typo in foo -- monitor-exit's argument is 0 (zero) rather than o (the sentinel object). Besides that, in foo both monitor-enter and monitor-exit get their arguments from a Var. Rewriting to use locking, which first puts the object whose monitor will be used in a local (that is, (let [lockee o] ...), where ... performs the locking using the newly introduced local), gives timings identical to those of bar and baz: (defn foo' [x] (if ( x 0) (inc x) (let [res (locking o (dec x))] res))) So this is one reason not to use monitor-enter and monitor-exit directly. Another reason is that locking guarantees that the monitor will be released (by using try / finally, and of course by preventing situations where the matching monitor-enter monitor-exit operate on different objects). In fact, both monitor-enter and monitor-exit carry docstrings which explicitly say that they should not be used in user code and point to locking as the user-facing equivalent to Java's synchronized. Cheers, Michał On 1 November 2013 19:34, Michael Blume blume.m...@gmail.com wrote: https://github.com/MichaelBlume/perf-test (ns perf-test (:use (criterium core)) (:gen-class)) (def o (Object.)) (defn foo [x] (if ( x 0) (inc x) (do (monitor-enter o) (let [res (dec x)] (monitor-exit 0) res (defn bar [x] (if ( x 0) (inc x) (dec x))) (defn locking-part [x l] (monitor-enter l) (let [res (dec x)] (monitor-exit l) res)) (defn baz [x] (if ( x 0) (inc x) (locking-part x o))) (defn -main [] (println benching foo) (bench (foo 5) :verbose) (println benching bar) (bench (bar 5) :verbose) (println benching baz) (bench (baz 5) :verbose) (println done benching)) I'm only ever calling these functions with positive values, so the monitor-enter branch should never be entered. Nevertheless, the performance of foo is much worse than bar or baz. The best guess I've got is that the fact that lock-taking is involved somehow changes how the function is compiled, somehow making the function slower. If the practical upshot is that I shouldn't write functions that only sometimes lock -- that the locking part of a function should always be its own function -- then I can do that, but I'm curious why. $ lein uberjar Compiling perf-test Created /Users/mike/perf-test/target/perf-test-0.1.0-SNAPSHOT.jar Created /Users/mike/perf-test/target/perf-test-0.1.0-SNAPSHOT-standalone.jar $ java -jar -server target/perf-test-0.1.0-SNAPSHOT-standalone.jar benching foo WARNING: Final GC required 1.5974571326266802 % of runtime x86_64 Mac OS X 10.8.3 4 cpu(s) Java HotSpot(TM) 64-Bit Server VM 24.0-b28 Runtime arguments: Evaluation count : 391582560 in 60 samples of 6526376 calls. Execution time sample mean : 167.426696 ns Execution time mean : 167.459429 ns Execution time sample std-deviation : 4.079466 ns Execution time std-deviation : 4.097819 ns Execution time lower quantile : 160.742869 ns ( 2.5%) Execution time upper quantile : 175.453376 ns (97.5%) Overhead used : 1.634996 ns Found 2 outliers in 60 samples (3. %) low-severe 2 (3. %) Variance from outliers : 12.5602 % Variance is moderately inflated by outliers benching bar x86_64 Mac OS X 10.8.3 4 cpu(s) Java HotSpot(TM) 64-Bit Server VM 24.0-b28 Runtime arguments: Evaluation count : 2174037300 in 60 samples of 36233955 calls. Execution time sample mean : 26.068923 ns Execution time mean : 26.066422 ns Execution time sample std-deviation : 0.887937 ns Execution time std-deviation : 0.916861 ns Execution time lower quantile : 23.996763 ns ( 2.5%) Execution time upper quantile : 27.911936 ns (97.5%) Overhead used : 1.634996 ns Found 3 outliers in 60 samples (5. %) low-severe 1 (1.6667 %) low-mild 1 (1.6667 %) high-mild 1 (1.6667 %) Variance from outliers : 22.1874 % Variance is moderately inflated by outliers benching baz x86_64 Mac OS X 10.8.3 4 cpu(s) Java HotSpot(TM) 64-Bit Server VM 24.0-b28 Runtime arguments: Evaluation count : 2270676660 in 60 samples of 37844611 calls. Execution time sample mean : 25.834142 ns Execution time mean : 25.837429 ns Execution time sample std-deviation : 0.718382 ns Execution time std-deviation : 0.729431 ns Execution time lower quantile : 24.837925 ns ( 2.5%) Execution time upper quantile : 27.595781 ns (97.5%) Overhead used : 1.634996 ns Found 4 outliers in 60 samples (6.6667 %) low-severe 2 (3. %) low-mild 2 (3. %) Variance from outliers : 15.7591 % Variance is moderately inflated by outliers done benching -- -- 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
Re: Functions using locks are slowed even when locks are never taken
I should perhaps make clear that with direct use of monitor-enter and monitor-exit with a Var it's possible for monitor-enter and monitor-exit to operate on different objects even in the absence of typos, namely if somebody rebinds the Var. To illustrate this with print at the REPL (a regular Clojure REPL, as opposed to nREPL or similar, in case there are any issues with reproducing this in different environments): (def x 1) (future (print x) (Thread/sleep 5000) (print x)) ; prints 1 immediately, but then goes to sleep; ; in the meantime, I say (def x 2) @*2 ; and after a moment 2 is printed NB. this could also happen with alter-var-root or set! to a Var with a thread-local binding. Cheers, Michał On 3 November 2013 18:30, Michał Marczyk michal.marc...@gmail.com wrote: You have a typo in foo -- monitor-exit's argument is 0 (zero) rather than o (the sentinel object). Besides that, in foo both monitor-enter and monitor-exit get their arguments from a Var. Rewriting to use locking, which first puts the object whose monitor will be used in a local (that is, (let [lockee o] ...), where ... performs the locking using the newly introduced local), gives timings identical to those of bar and baz: (defn foo' [x] (if ( x 0) (inc x) (let [res (locking o (dec x))] res))) So this is one reason not to use monitor-enter and monitor-exit directly. Another reason is that locking guarantees that the monitor will be released (by using try / finally, and of course by preventing situations where the matching monitor-enter monitor-exit operate on different objects). In fact, both monitor-enter and monitor-exit carry docstrings which explicitly say that they should not be used in user code and point to locking as the user-facing equivalent to Java's synchronized. Cheers, Michał On 1 November 2013 19:34, Michael Blume blume.m...@gmail.com wrote: https://github.com/MichaelBlume/perf-test (ns perf-test (:use (criterium core)) (:gen-class)) (def o (Object.)) (defn foo [x] (if ( x 0) (inc x) (do (monitor-enter o) (let [res (dec x)] (monitor-exit 0) res (defn bar [x] (if ( x 0) (inc x) (dec x))) (defn locking-part [x l] (monitor-enter l) (let [res (dec x)] (monitor-exit l) res)) (defn baz [x] (if ( x 0) (inc x) (locking-part x o))) (defn -main [] (println benching foo) (bench (foo 5) :verbose) (println benching bar) (bench (bar 5) :verbose) (println benching baz) (bench (baz 5) :verbose) (println done benching)) I'm only ever calling these functions with positive values, so the monitor-enter branch should never be entered. Nevertheless, the performance of foo is much worse than bar or baz. The best guess I've got is that the fact that lock-taking is involved somehow changes how the function is compiled, somehow making the function slower. If the practical upshot is that I shouldn't write functions that only sometimes lock -- that the locking part of a function should always be its own function -- then I can do that, but I'm curious why. $ lein uberjar Compiling perf-test Created /Users/mike/perf-test/target/perf-test-0.1.0-SNAPSHOT.jar Created /Users/mike/perf-test/target/perf-test-0.1.0-SNAPSHOT-standalone.jar $ java -jar -server target/perf-test-0.1.0-SNAPSHOT-standalone.jar benching foo WARNING: Final GC required 1.5974571326266802 % of runtime x86_64 Mac OS X 10.8.3 4 cpu(s) Java HotSpot(TM) 64-Bit Server VM 24.0-b28 Runtime arguments: Evaluation count : 391582560 in 60 samples of 6526376 calls. Execution time sample mean : 167.426696 ns Execution time mean : 167.459429 ns Execution time sample std-deviation : 4.079466 ns Execution time std-deviation : 4.097819 ns Execution time lower quantile : 160.742869 ns ( 2.5%) Execution time upper quantile : 175.453376 ns (97.5%) Overhead used : 1.634996 ns Found 2 outliers in 60 samples (3. %) low-severe 2 (3. %) Variance from outliers : 12.5602 % Variance is moderately inflated by outliers benching bar x86_64 Mac OS X 10.8.3 4 cpu(s) Java HotSpot(TM) 64-Bit Server VM 24.0-b28 Runtime arguments: Evaluation count : 2174037300 in 60 samples of 36233955 calls. Execution time sample mean : 26.068923 ns Execution time mean : 26.066422 ns Execution time sample std-deviation : 0.887937 ns Execution time std-deviation : 0.916861 ns Execution time lower quantile : 23.996763 ns ( 2.5%) Execution time upper quantile : 27.911936 ns (97.5%) Overhead used : 1.634996 ns Found 3 outliers in 60 samples (5. %) low-severe 1 (1.6667 %) low-mild 1 (1.6667 %) high-mild 1 (1.6667 %) Variance from outliers : 22.1874 % Variance is moderately inflated by outliers benching baz x86_64 Mac OS X 10.8.3 4 cpu(s) Java HotSpot(TM) 64-Bit Server VM 24.0-b28 Runtime arguments:
Re: Functions using locks are slowed even when locks are never taken
Good detective work, Michal. So the extra time for the slower version was because a Var was always being accessed in the generated byte code, even if the source code was only explicitly accessing the Var in a branch that was never executed? Thanks, Andy On Sun, Nov 3, 2013 at 9:30 AM, Michał Marczyk michal.marc...@gmail.comwrote: You have a typo in foo -- monitor-exit's argument is 0 (zero) rather than o (the sentinel object). Besides that, in foo both monitor-enter and monitor-exit get their arguments from a Var. Rewriting to use locking, which first puts the object whose monitor will be used in a local (that is, (let [lockee o] ...), where ... performs the locking using the newly introduced local), gives timings identical to those of bar and baz: (defn foo' [x] (if ( x 0) (inc x) (let [res (locking o (dec x))] res))) So this is one reason not to use monitor-enter and monitor-exit directly. Another reason is that locking guarantees that the monitor will be released (by using try / finally, and of course by preventing situations where the matching monitor-enter monitor-exit operate on different objects). In fact, both monitor-enter and monitor-exit carry docstrings which explicitly say that they should not be used in user code and point to locking as the user-facing equivalent to Java's synchronized. Cheers, Michał On 1 November 2013 19:34, Michael Blume blume.m...@gmail.com wrote: https://github.com/MichaelBlume/perf-test (ns perf-test (:use (criterium core)) (:gen-class)) (def o (Object.)) (defn foo [x] (if ( x 0) (inc x) (do (monitor-enter o) (let [res (dec x)] (monitor-exit 0) res (defn bar [x] (if ( x 0) (inc x) (dec x))) (defn locking-part [x l] (monitor-enter l) (let [res (dec x)] (monitor-exit l) res)) (defn baz [x] (if ( x 0) (inc x) (locking-part x o))) (defn -main [] (println benching foo) (bench (foo 5) :verbose) (println benching bar) (bench (bar 5) :verbose) (println benching baz) (bench (baz 5) :verbose) (println done benching)) I'm only ever calling these functions with positive values, so the monitor-enter branch should never be entered. Nevertheless, the performance of foo is much worse than bar or baz. The best guess I've got is that the fact that lock-taking is involved somehow changes how the function is compiled, somehow making the function slower. If the practical upshot is that I shouldn't write functions that only sometimes lock -- that the locking part of a function should always be its own function -- then I can do that, but I'm curious why. $ lein uberjar Compiling perf-test Created /Users/mike/perf-test/target/perf-test-0.1.0-SNAPSHOT.jar Created /Users/mike/perf-test/target/perf-test-0.1.0-SNAPSHOT-standalone.jar $ java -jar -server target/perf-test-0.1.0-SNAPSHOT-standalone.jar benching foo WARNING: Final GC required 1.5974571326266802 % of runtime x86_64 Mac OS X 10.8.3 4 cpu(s) Java HotSpot(TM) 64-Bit Server VM 24.0-b28 Runtime arguments: Evaluation count : 391582560 in 60 samples of 6526376 calls. Execution time sample mean : 167.426696 ns Execution time mean : 167.459429 ns Execution time sample std-deviation : 4.079466 ns Execution time std-deviation : 4.097819 ns Execution time lower quantile : 160.742869 ns ( 2.5%) Execution time upper quantile : 175.453376 ns (97.5%) Overhead used : 1.634996 ns Found 2 outliers in 60 samples (3. %) low-severe 2 (3. %) Variance from outliers : 12.5602 % Variance is moderately inflated by outliers benching bar x86_64 Mac OS X 10.8.3 4 cpu(s) Java HotSpot(TM) 64-Bit Server VM 24.0-b28 Runtime arguments: Evaluation count : 2174037300 in 60 samples of 36233955 calls. Execution time sample mean : 26.068923 ns Execution time mean : 26.066422 ns Execution time sample std-deviation : 0.887937 ns Execution time std-deviation : 0.916861 ns Execution time lower quantile : 23.996763 ns ( 2.5%) Execution time upper quantile : 27.911936 ns (97.5%) Overhead used : 1.634996 ns Found 3 outliers in 60 samples (5. %) low-severe 1 (1.6667 %) low-mild 1 (1.6667 %) high-mild 1 (1.6667 %) Variance from outliers : 22.1874 % Variance is moderately inflated by outliers benching baz x86_64 Mac OS X 10.8.3 4 cpu(s) Java HotSpot(TM) 64-Bit Server VM 24.0-b28 Runtime arguments: Evaluation count : 2270676660 in 60 samples of 37844611 calls. Execution time sample mean : 25.834142 ns Execution time mean : 25.837429 ns Execution time sample std-deviation : 0.718382 ns Execution time std-deviation : 0.729431 ns Execution time lower quantile : 24.837925 ns ( 2.5%) Execution time upper
Re: Functions using locks are slowed even when locks are never taken
Huh, interesting. I have: (defn foo' [x] (if ( x 0) (inc x) (let [res (locking o (dec x))] res))) (defn foo'' [x] (if ( x 0) (inc x) (locking o (dec x foo' is fast, but foo'' is slow. So something about wrapping the locking clause in a let makes it fast. Still no idea why. On Sunday, November 3, 2013 9:30:45 AM UTC-8, Michał Marczyk wrote: You have a typo in foo -- monitor-exit's argument is 0 (zero) rather than o (the sentinel object). Besides that, in foo both monitor-enter and monitor-exit get their arguments from a Var. Rewriting to use locking, which first puts the object whose monitor will be used in a local (that is, (let [lockee o] ...), where ... performs the locking using the newly introduced local), gives timings identical to those of bar and baz: (defn foo' [x] (if ( x 0) (inc x) (let [res (locking o (dec x))] res))) So this is one reason not to use monitor-enter and monitor-exit directly. Another reason is that locking guarantees that the monitor will be released (by using try / finally, and of course by preventing situations where the matching monitor-enter monitor-exit operate on different objects). In fact, both monitor-enter and monitor-exit carry docstrings which explicitly say that they should not be used in user code and point to locking as the user-facing equivalent to Java's synchronized. Cheers, Michał On 1 November 2013 19:34, Michael Blume blume...@gmail.com javascript: wrote: https://github.com/MichaelBlume/perf-test (ns perf-test (:use (criterium core)) (:gen-class)) (def o (Object.)) (defn foo [x] (if ( x 0) (inc x) (do (monitor-enter o) (let [res (dec x)] (monitor-exit 0) res (defn bar [x] (if ( x 0) (inc x) (dec x))) (defn locking-part [x l] (monitor-enter l) (let [res (dec x)] (monitor-exit l) res)) (defn baz [x] (if ( x 0) (inc x) (locking-part x o))) (defn -main [] (println benching foo) (bench (foo 5) :verbose) (println benching bar) (bench (bar 5) :verbose) (println benching baz) (bench (baz 5) :verbose) (println done benching)) I'm only ever calling these functions with positive values, so the monitor-enter branch should never be entered. Nevertheless, the performance of foo is much worse than bar or baz. The best guess I've got is that the fact that lock-taking is involved somehow changes how the function is compiled, somehow making the function slower. If the practical upshot is that I shouldn't write functions that only sometimes lock -- that the locking part of a function should always be its own function -- then I can do that, but I'm curious why. $ lein uberjar Compiling perf-test Created /Users/mike/perf-test/target/perf-test-0.1.0-SNAPSHOT.jar Created /Users/mike/perf-test/target/perf-test-0.1.0-SNAPSHOT-standalone.jar $ java -jar -server target/perf-test-0.1.0-SNAPSHOT-standalone.jar benching foo WARNING: Final GC required 1.5974571326266802 % of runtime x86_64 Mac OS X 10.8.3 4 cpu(s) Java HotSpot(TM) 64-Bit Server VM 24.0-b28 Runtime arguments: Evaluation count : 391582560 in 60 samples of 6526376 calls. Execution time sample mean : 167.426696 ns Execution time mean : 167.459429 ns Execution time sample std-deviation : 4.079466 ns Execution time std-deviation : 4.097819 ns Execution time lower quantile : 160.742869 ns ( 2.5%) Execution time upper quantile : 175.453376 ns (97.5%) Overhead used : 1.634996 ns Found 2 outliers in 60 samples (3. %) low-severe 2 (3. %) Variance from outliers : 12.5602 % Variance is moderately inflated by outliers benching bar x86_64 Mac OS X 10.8.3 4 cpu(s) Java HotSpot(TM) 64-Bit Server VM 24.0-b28 Runtime arguments: Evaluation count : 2174037300 in 60 samples of 36233955 calls. Execution time sample mean : 26.068923 ns Execution time mean : 26.066422 ns Execution time sample std-deviation : 0.887937 ns Execution time std-deviation : 0.916861 ns Execution time lower quantile : 23.996763 ns ( 2.5%) Execution time upper quantile : 27.911936 ns (97.5%) Overhead used : 1.634996 ns Found 3 outliers in 60 samples (5. %) low-severe 1 (1.6667 %) low-mild 1 (1.6667 %) high-mild 1 (1.6667 %) Variance from outliers : 22.1874 % Variance is moderately inflated by outliers benching baz x86_64 Mac OS X 10.8.3 4 cpu(s) Java HotSpot(TM) 64-Bit Server VM 24.0-b28 Runtime arguments: Evaluation count : 2270676660 in 60 samples of 37844611 calls. Execution time sample mean : 25.834142 ns Execution time mean : 25.837429 ns
Re: Scala interop (or, aliasing imported Java classes)
Perhaps a small extension to (import ..) is warranted then, since the
underlying machinery seems to support aliases?
(import [the.java.package {Clazz1 Alias1 Clazz2 Alias2} Clazz3])
or, maybe more in keeping with require:
(import [the.java.package Clazz1 Clazz2 Clazz3 :rename {Clazz1
Alias1 Clazz2 Alias2}])
Sean
On Sun, Nov 3, 2013 at 4:38 AM, Marshall Bockrath-Vandegrift
llas...@gmail.com wrote:
Mark mjt0...@gmail.com writes:
I think my preferred solution would be to allow imported Java classes
to be aliased, so I could do this:
(import '(org.fooinstitute.team.library.foo package :as foop))
= org.fooinstitute.team.library.foo.package
(foop/isFoo foop)
= false
But to the best of my knowledge (and searching), that doesn't exist in
Clojure.
Clojure doesn’t provide it as a part of the `ns` or `import` forms, but
the underlying `Namespace` objects support it just fine, and then almost
everything works as you’d expect w/ the arbitrary alias:
user (.importClass *ns* 'Q java.util.concurrent.LinkedBlockingQueue)
java.util.concurrent.LinkedBlockingQueue
user Q
java.util.concurrent.LinkedBlockingQueue
user (Q.)
#LinkedBlockingQueue []
user (fn [q x] (.offer q x))
Reflection warning, /tmp/form-init7252328014986537096.clj:1:11 - call to
offer can't be resolved.
#user$eval1302$fn__1303 user$eval1302$fn__1303@ece88d2
user (fn [q x] (.offer ^Q q x))
#user$eval1308$fn__1309 user$eval1308$fn__1309@251c4123
HTH,
-Marshall
--
--
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.
--
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
World Singles, LLC. -- http://worldsingles.com/
Perfection is the enemy of the good.
-- Gustave Flaubert, French realist novelist (1821-1880)
--
--
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: Scala interop (or, aliasing imported Java classes)
That would need quoting wouldn't it?
(import '(the.java.package {Clazz1 Alias1 Clazz2 Alias2} Clazz3))
or:
(import '(the.java.package Clazz1 Clazz2 Clazz3 :rename {Clazz1
Alias1 Clazz2 Alias2}))
On Sun, Nov 3, 2013 at 11:22 AM, Sean Corfield seancorfi...@gmail.com wrote:
Perhaps a small extension to (import ..) is warranted then, since the
underlying machinery seems to support aliases?
(import [the.java.package {Clazz1 Alias1 Clazz2 Alias2} Clazz3])
or, maybe more in keeping with require:
(import [the.java.package Clazz1 Clazz2 Clazz3 :rename {Clazz1
Alias1 Clazz2 Alias2}])
Sean
On Sun, Nov 3, 2013 at 4:38 AM, Marshall Bockrath-Vandegrift
llas...@gmail.com wrote:
Mark mjt0...@gmail.com writes:
I think my preferred solution would be to allow imported Java classes
to be aliased, so I could do this:
(import '(org.fooinstitute.team.library.foo package :as foop))
= org.fooinstitute.team.library.foo.package
(foop/isFoo foop)
= false
But to the best of my knowledge (and searching), that doesn't exist in
Clojure.
Clojure doesn’t provide it as a part of the `ns` or `import` forms, but
the underlying `Namespace` objects support it just fine, and then almost
everything works as you’d expect w/ the arbitrary alias:
user (.importClass *ns* 'Q java.util.concurrent.LinkedBlockingQueue)
java.util.concurrent.LinkedBlockingQueue
user Q
java.util.concurrent.LinkedBlockingQueue
user (Q.)
#LinkedBlockingQueue []
user (fn [q x] (.offer q x))
Reflection warning, /tmp/form-init7252328014986537096.clj:1:11 - call to
offer can't be resolved.
#user$eval1302$fn__1303 user$eval1302$fn__1303@ece88d2
user (fn [q x] (.offer ^Q q x))
#user$eval1308$fn__1309 user$eval1308$fn__1309@251c4123
HTH,
-Marshall
--
--
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.
--
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
World Singles, LLC. -- http://worldsingles.com/
Perfection is the enemy of the good.
-- Gustave Flaubert, French realist novelist (1821-1880)
--
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
World Singles, LLC. -- http://worldsingles.com/
Perfection is the enemy of the good.
-- Gustave Flaubert, French realist novelist (1821-1880)
--
--
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: Functions using locks are slowed even when locks are never taken
I mean, I'm probably being naive, but this suggests that one could write (defmacro locking' [ forms] `(let [res# (locking ~@forms)] res#)) and use locking' in place of locking for improved performance. Is this wrong? If it's right, does that suggest the macro in clojure.core should be changed? On Sun, Nov 3, 2013 at 11:09 AM, Michael Blume blume.m...@gmail.com wrote: Huh, interesting. I have: (defn foo' [x] (if ( x 0) (inc x) (let [res (locking o (dec x))] res))) (defn foo'' [x] (if ( x 0) (inc x) (locking o (dec x foo' is fast, but foo'' is slow. So something about wrapping the locking clause in a let makes it fast. Still no idea why. On Sunday, November 3, 2013 9:30:45 AM UTC-8, Michał Marczyk wrote: You have a typo in foo -- monitor-exit's argument is 0 (zero) rather than o (the sentinel object). Besides that, in foo both monitor-enter and monitor-exit get their arguments from a Var. Rewriting to use locking, which first puts the object whose monitor will be used in a local (that is, (let [lockee o] ...), where ... performs the locking using the newly introduced local), gives timings identical to those of bar and baz: (defn foo' [x] (if ( x 0) (inc x) (let [res (locking o (dec x))] res))) So this is one reason not to use monitor-enter and monitor-exit directly. Another reason is that locking guarantees that the monitor will be released (by using try / finally, and of course by preventing situations where the matching monitor-enter monitor-exit operate on different objects). In fact, both monitor-enter and monitor-exit carry docstrings which explicitly say that they should not be used in user code and point to locking as the user-facing equivalent to Java's synchronized. Cheers, Michał On 1 November 2013 19:34, Michael Blume blume...@gmail.com wrote: https://github.com/MichaelBlume/perf-test (ns perf-test (:use (criterium core)) (:gen-class)) (def o (Object.)) (defn foo [x] (if ( x 0) (inc x) (do (monitor-enter o) (let [res (dec x)] (monitor-exit 0) res (defn bar [x] (if ( x 0) (inc x) (dec x))) (defn locking-part [x l] (monitor-enter l) (let [res (dec x)] (monitor-exit l) res)) (defn baz [x] (if ( x 0) (inc x) (locking-part x o))) (defn -main [] (println benching foo) (bench (foo 5) :verbose) (println benching bar) (bench (bar 5) :verbose) (println benching baz) (bench (baz 5) :verbose) (println done benching)) I'm only ever calling these functions with positive values, so the monitor-enter branch should never be entered. Nevertheless, the performance of foo is much worse than bar or baz. The best guess I've got is that the fact that lock-taking is involved somehow changes how the function is compiled, somehow making the function slower. If the practical upshot is that I shouldn't write functions that only sometimes lock -- that the locking part of a function should always be its own function -- then I can do that, but I'm curious why. $ lein uberjar Compiling perf-test Created /Users/mike/perf-test/target/perf-test-0.1.0-SNAPSHOT.jar Created /Users/mike/perf-test/target/perf-test-0.1.0-SNAPSHOT-standalone.jar $ java -jar -server target/perf-test-0.1.0-SNAPSHOT-standalone.jar benching foo WARNING: Final GC required 1.5974571326266802 % of runtime x86_64 Mac OS X 10.8.3 4 cpu(s) Java HotSpot(TM) 64-Bit Server VM 24.0-b28 Runtime arguments: Evaluation count : 391582560 in 60 samples of 6526376 calls. Execution time sample mean : 167.426696 ns Execution time mean : 167.459429 ns Execution time sample std-deviation : 4.079466 ns Execution time std-deviation : 4.097819 ns Execution time lower quantile : 160.742869 ns ( 2.5%) Execution time upper quantile : 175.453376 ns (97.5%) Overhead used : 1.634996 ns Found 2 outliers in 60 samples (3. %) low-severe 2 (3. %) Variance from outliers : 12.5602 % Variance is moderately inflated by outliers benching bar x86_64 Mac OS X 10.8.3 4 cpu(s) Java HotSpot(TM) 64-Bit Server VM 24.0-b28 Runtime arguments: Evaluation count : 2174037300 in 60 samples of 36233955 calls. Execution time sample mean : 26.068923 ns Execution time mean : 26.066422 ns Execution time sample std-deviation : 0.887937 ns Execution time std-deviation : 0.916861 ns Execution time lower quantile : 23.996763 ns ( 2.5%) Execution time upper quantile : 27.911936 ns (97.5%) Overhead used : 1.634996 ns Found 3 outliers in 60 samples (5. %) low-severe 1 (1.6667 %) low-mild 1 (1.6667 %) high-mild 1 (1.6667 %) Variance from outliers : 22.1874 % Variance is moderately inflated by outliers benching baz x86_64 Mac OS
Re: Functions using locks are slowed even when locks are never taken
Well, that is interesting. The difference between the compiled versions of (defn foo [x] (if ( x 0) (inc x) (locking o (dec x and (defn bar [x] (if ( x 0) (inc x) (let [res (locking o (dec x))] res))) is quite significant. foo gets compiled to a single class, with invocations handled by a single invoke method; bar gets compiled to a class for bar + an extra class for an inner function which handles the (locking o (dec x)) part -- probably very similar to the output for the version with the hand-coded locking-part (although I haven't really looked at that yet). The inner function is a closure, so calling it involves an allocation of a closure object; its ctor receives the closed-over locals as arguments and stores them in two fields (lockee and x). Then they get loaded from the fields in the body of the closure's invoke method etc. I guess I'll have to play around with Java equivalents too... Cheers, Michał On 3 November 2013 20:46, Michael Blume blume.m...@gmail.com wrote: I mean, I'm probably being naive, but this suggests that one could write (defmacro locking' [ forms] `(let [res# (locking ~@forms)] res#)) and use locking' in place of locking for improved performance. Is this wrong? If it's right, does that suggest the macro in clojure.core should be changed? On Sun, Nov 3, 2013 at 11:09 AM, Michael Blume blume.m...@gmail.com wrote: Huh, interesting. I have: (defn foo' [x] (if ( x 0) (inc x) (let [res (locking o (dec x))] res))) (defn foo'' [x] (if ( x 0) (inc x) (locking o (dec x foo' is fast, but foo'' is slow. So something about wrapping the locking clause in a let makes it fast. Still no idea why. On Sunday, November 3, 2013 9:30:45 AM UTC-8, Michał Marczyk wrote: You have a typo in foo -- monitor-exit's argument is 0 (zero) rather than o (the sentinel object). Besides that, in foo both monitor-enter and monitor-exit get their arguments from a Var. Rewriting to use locking, which first puts the object whose monitor will be used in a local (that is, (let [lockee o] ...), where ... performs the locking using the newly introduced local), gives timings identical to those of bar and baz: (defn foo' [x] (if ( x 0) (inc x) (let [res (locking o (dec x))] res))) So this is one reason not to use monitor-enter and monitor-exit directly. Another reason is that locking guarantees that the monitor will be released (by using try / finally, and of course by preventing situations where the matching monitor-enter monitor-exit operate on different objects). In fact, both monitor-enter and monitor-exit carry docstrings which explicitly say that they should not be used in user code and point to locking as the user-facing equivalent to Java's synchronized. Cheers, Michał On 1 November 2013 19:34, Michael Blume blume...@gmail.com wrote: https://github.com/MichaelBlume/perf-test (ns perf-test (:use (criterium core)) (:gen-class)) (def o (Object.)) (defn foo [x] (if ( x 0) (inc x) (do (monitor-enter o) (let [res (dec x)] (monitor-exit 0) res (defn bar [x] (if ( x 0) (inc x) (dec x))) (defn locking-part [x l] (monitor-enter l) (let [res (dec x)] (monitor-exit l) res)) (defn baz [x] (if ( x 0) (inc x) (locking-part x o))) (defn -main [] (println benching foo) (bench (foo 5) :verbose) (println benching bar) (bench (bar 5) :verbose) (println benching baz) (bench (baz 5) :verbose) (println done benching)) I'm only ever calling these functions with positive values, so the monitor-enter branch should never be entered. Nevertheless, the performance of foo is much worse than bar or baz. The best guess I've got is that the fact that lock-taking is involved somehow changes how the function is compiled, somehow making the function slower. If the practical upshot is that I shouldn't write functions that only sometimes lock -- that the locking part of a function should always be its own function -- then I can do that, but I'm curious why. $ lein uberjar Compiling perf-test Created /Users/mike/perf-test/target/perf-test-0.1.0-SNAPSHOT.jar Created /Users/mike/perf-test/target/perf-test-0.1.0-SNAPSHOT-standalone.jar $ java -jar -server target/perf-test-0.1.0-SNAPSHOT-standalone.jar benching foo WARNING: Final GC required 1.5974571326266802 % of runtime x86_64 Mac OS X 10.8.3 4 cpu(s) Java HotSpot(TM) 64-Bit Server VM 24.0-b28 Runtime arguments: Evaluation count : 391582560 in 60 samples of 6526376 calls. Execution time sample mean : 167.426696 ns Execution time mean : 167.459429 ns Execution time sample std-deviation : 4.079466 ns Execution time std-deviation : 4.097819 ns Execution time lower quantile : 160.742869
Re: Potential improvement to select-keys ?
On Nov 2, 2013, at 9:27 AM, Mark Engelberg mark.engelb...@gmail.com wrote:
I seem to be a relatively lone voice thinking it makes sense to preserve the
type of the map, and honestly, I'm not going to lose any sleep if this patch
is never actually implemented, but here's my two cents on the optimal
design for records.
Earlier in the thread, I mentioned two mental models about how select-keys
works. Even though the actual implementation involves starting from an empty
map and building back up, I think the behavior of select-keys should mimic
the mental model of discarding irrelevant keys.
The two mental models predict somewhat differently what would happen when
working with records. Records can hold additional keys. So imagine someone
dumps a whole lot of additional keys, and then wants to recover the
original, true record, by calling select-keys with the original keys in the
record. I think this is a use case worth supporting. This corresponds to
the mental model of discarding unwanted keys.
To implement this for records:
If any of the original record keys do not appear in the selected keys, then,
as with dissoc, we must revert back to a map as there is no valid way to
represent this as a record.
Otherwise, maintain the record type -- the core record contents are
preserved, and essentially you only need to call select-keys only on the
extended map of extra keys stored in the record.
I agree 100% with Mark’s comments above.
This is exactly the model I would expect select-keys to have.
Conceptually, this is how I imagine select-keys should work:
(defn select-keys++
Returns a new map of the same (hashed/sorted) type,
that contains only those entries whose key is in keyseq
[map keyseq]
(apply dissoc
map
(clojure.set/difference (set (keys map))
(set keyseq
I am not saying that this would be the best , or even a good, implementation.
Like Mark, I am not going to lose any sleep about this either, but I was using
Mark’s data.priority-maps the other day,
did a select-keys to winnow down my priority-map, and was surprised by the
result.
Perhaps I should not have been surprised….
In preparing this email, I carefully re-read the doc strings for both dissoc
and select keys:
(defn dissoc
dissoc[iate]. Returns a new map of the same (hashed/sorted) type,
that does not contain a mapping for key(s).”
(defn select-keys
Returns a map containing only those entries in map whose key is in keys
Clearly dissoc makes the promise to return a map of the same type that
select-keys doesn’t.
A potential non-code change to select-keys might be to emphasize that the
return map will be
a hash-map, regardless of the kind/type of input map.
Don
On Sat, Nov 2, 2013 at 8:49 AM, Andy Fingerhut andy.finger...@gmail.com
wrote:
I attached another patch to the ticket. It builds up the answer from the
empty map {} if the argument is a record (as the current select-keys does),
but from (empty map) if it is not a record, so it will preserve sortedness of
the argument. Not sure if there are any other cases that are a problem, or
if it does what everyone would expect, but it should be closer.
http://dev.clojure.org/jira/browse/CLJ-1287
Andy
On Sat, Nov 2, 2013 at 6:07 AM, Alex Miller a...@puredanger.com wrote:
One other point:
Sometimes people use sorted maps and array maps specifically for scenarios
in which the keys are not hashable and therefore hash maps would not apply.
Dumping the contents into a regular map in such cases doesn't make much
sense.
Everything is hashable, not sure what a non-hashable key means. Array maps
use the hash of the key to determine the array bucket. If you get the hash
code of a sorted map, it will get the hash of all keys and values.
--
--
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
Why is this count example not working: (count % '(1 2 3))
(count % '(1 2 3)) I am getting error: clojure.lang.ArityException: Wrong number of args (2) passed to: core$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/groups/opt_out.
Re: Why is this count example not working: (count % '(1 2 3))
% is used as the implicit arg in the #() (syntactic sugar) anonymous function form. Maybe you want (count '(1 2 3)). --- Joseph Smith j...@uwcreations.com @solussd On Nov 3, 2013, at 3:39 PM, Angus anguscom...@gmail.com wrote: (count % '(1 2 3)) I am getting error: clojure.lang.ArityException: Wrong number of args (2) passed to: core$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/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: Why is this count example not working: (count % '(1 2 3))
On 3 Nov 2013, at 21:39, Angus anguscom...@gmail.com wrote: (count % '(1 2 3)) I am getting error: clojure.lang.ArityException: Wrong number of args (2) passed to: core$count http://clojuredocs.org/clojure_core/clojure.core/count Count only takes one argument, a collection, and returns the number of items in the collection. You’re giving it two arguments % and ‘(1 2 3). Alan -- -- 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.
tomcat 6/7 stream closed error in ring json - works in lein ring server
Hi all, I have developed a ring/compojure app which receives and servers JSON. All is well in 'lein ring server' but as soon as I do 'lein ring uberwar' and deploy it to tomcat 6 or 7 it fails. To be explicit, the app deploys and I can view the static resources, but as soon as I issue a JSON POST I get the following error: [code] java.io.IOException: Stream closed org.apache.catalina.connector.InputBuffer.read(InputBuffer.java:325) org.apache.catalina.connector.CoyoteInputStream.read(CoyoteInputStream.java:193) sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:283) sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:325) sun.nio.cs.StreamDecoder.read(StreamDecoder.java:177) java.io.InputStreamReader.read(InputStreamReader.java:184) java.io.BufferedReader.fill(BufferedReader.java:154) java.io.BufferedReader.read(BufferedReader.java:175) clojure.core$slurp.doInvoke(core.clj:6279) clojure.lang.RestFn.invoke(RestFn.java:410) ring.middleware.json$read_json.doInvoke(json.clj:12) clojure.lang.RestFn.invoke(RestFn.java:423) ring.middleware.json$wrap_json_body$fn__1031.invoke(json.clj:19) ring.middleware.json$wrap_json_params$fn__1035.invoke(json.clj:31) compojure.core$routing$fn__362.invoke(core.clj:107) clojure.core$some.invoke(core.clj:2443) compojure.core$routing.doInvoke(core.clj:107) clojure.lang.RestFn.applyTo(RestFn.java:139) clojure.core$apply.invoke(core.clj:619) compojure.core$routes$fn__366.invoke(core.clj:112) health.servlet$_service$fn__1016.invoke(servlet.clj:1) ring.util.servlet$make_service_method$fn__50.invoke(servlet.clj:126) health.servlet$_service.invoke(servlet.clj:1) health.servlet.service(Unknown Source) [/code] Any help? -- -- 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: tomcat 6/7 stream closed error in ring json - works in lein ring server
Apologies - I just realised a Compojure group existed. I have posted in there (https://groups.google.com/forum/#!topic/compojure/_jut36dXmCM) as well. On Monday, 4 November 2013 00:20:29 UTC, Colin Yates wrote: Hi all, I have developed a ring/compojure app which receives and servers JSON. All is well in 'lein ring server' but as soon as I do 'lein ring uberwar' and deploy it to tomcat 6 or 7 it fails. To be explicit, the app deploys and I can view the static resources, but as soon as I issue a JSON POST I get the following error: [code] java.io.IOException: Stream closed org.apache.catalina.connector.InputBuffer.read(InputBuffer.java:325) org.apache.catalina.connector.CoyoteInputStream.read(CoyoteInputStream.java:193) sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:283) sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:325) sun.nio.cs.StreamDecoder.read(StreamDecoder.java:177) java.io.InputStreamReader.read(InputStreamReader.java:184) java.io.BufferedReader.fill(BufferedReader.java:154) java.io.BufferedReader.read(BufferedReader.java:175) clojure.core$slurp.doInvoke(core.clj:6279) clojure.lang.RestFn.invoke(RestFn.java:410) ring.middleware.json$read_json.doInvoke(json.clj:12) clojure.lang.RestFn.invoke(RestFn.java:423) ring.middleware.json$wrap_json_body$fn__1031.invoke(json.clj:19) ring.middleware.json$wrap_json_params$fn__1035.invoke(json.clj:31) compojure.core$routing$fn__362.invoke(core.clj:107) clojure.core$some.invoke(core.clj:2443) compojure.core$routing.doInvoke(core.clj:107) clojure.lang.RestFn.applyTo(RestFn.java:139) clojure.core$apply.invoke(core.clj:619) compojure.core$routes$fn__366.invoke(core.clj:112) health.servlet$_service$fn__1016.invoke(servlet.clj:1) ring.util.servlet$make_service_method$fn__50.invoke(servlet.clj:126) health.servlet$_service.invoke(servlet.clj:1) health.servlet.service(Unknown Source) [/code] Any help? -- -- 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: tomcat 6/7 stream closed error in ring json - works in lein ring server
Hi Colin, One of the compromises Ring makes for efficiency is that the body of a request is an InputStream, rather than a static string or byte array pre-loaded into memory. Because it's a stream, it can potentially be consumed by previous middleware. For some reason you have both wrap-json-body and wrap-json-params in your stacktrace: ring.middleware.json$wrap_json_body$fn__1031.invoke(json.clj:19) ring.middleware.json$wrap_json_params$fn__1035.invoke(json.clj:31) Both middleware read from the body InputStream, so one of them is going to fail when you try and read the body twice. - James On 4 November 2013 00:20, Colin Yates colin.ya...@gmail.com wrote: Hi all, I have developed a ring/compojure app which receives and servers JSON. All is well in 'lein ring server' but as soon as I do 'lein ring uberwar' and deploy it to tomcat 6 or 7 it fails. To be explicit, the app deploys and I can view the static resources, but as soon as I issue a JSON POST I get the following error: [code] java.io.IOException: Stream closed org.apache.catalina.connector.InputBuffer.read(InputBuffer.java:325) org.apache.catalina.connector.CoyoteInputStream.read(CoyoteInputStream.java:193) sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:283) sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:325) sun.nio.cs.StreamDecoder.read(StreamDecoder.java:177) java.io.InputStreamReader.read(InputStreamReader.java:184) java.io.BufferedReader.fill(BufferedReader.java:154) java.io.BufferedReader.read(BufferedReader.java:175) clojure.core$slurp.doInvoke(core.clj:6279) clojure.lang.RestFn.invoke(RestFn.java:410) ring.middleware.json$read_json.doInvoke(json.clj:12) clojure.lang.RestFn.invoke(RestFn.java:423) ring.middleware.json$wrap_json_body$fn__1031.invoke(json.clj:19) ring.middleware.json$wrap_json_params$fn__1035.invoke(json.clj:31) compojure.core$routing$fn__362.invoke(core.clj:107) clojure.core$some.invoke(core.clj:2443) compojure.core$routing.doInvoke(core.clj:107) clojure.lang.RestFn.applyTo(RestFn.java:139) clojure.core$apply.invoke(core.clj:619) compojure.core$routes$fn__366.invoke(core.clj:112) health.servlet$_service$fn__1016.invoke(servlet.clj:1) ring.util.servlet$make_service_method$fn__50.invoke(servlet.clj:126) health.servlet$_service.invoke(servlet.clj:1) health.servlet.service(Unknown Source) [/code] Any help? -- -- 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: tomcat 6/7 stream closed error in ring json - works in lein ring server
Hi James, Not sure why I did that double wrapping.. However, wouldn't that also fail in Jetty? On 4 November 2013 01:02, James Reeves ja...@booleanknot.com wrote: Hi Colin, One of the compromises Ring makes for efficiency is that the body of a request is an InputStream, rather than a static string or byte array pre-loaded into memory. Because it's a stream, it can potentially be consumed by previous middleware. For some reason you have both wrap-json-body and wrap-json-params in your stacktrace: ring.middleware.json$wrap_json_body$fn__1031.invoke(json.clj:19) ring.middleware.json$wrap_json_params$fn__1035.invoke(json.clj:31) Both middleware read from the body InputStream, so one of them is going to fail when you try and read the body twice. - James On 4 November 2013 00:20, Colin Yates colin.ya...@gmail.com wrote: Hi all, I have developed a ring/compojure app which receives and servers JSON. All is well in 'lein ring server' but as soon as I do 'lein ring uberwar' and deploy it to tomcat 6 or 7 it fails. To be explicit, the app deploys and I can view the static resources, but as soon as I issue a JSON POST I get the following error: [code] java.io.IOException: Stream closed org.apache.catalina.connector.InputBuffer.read(InputBuffer.java:325) org.apache.catalina.connector.CoyoteInputStream.read(CoyoteInputStream.java:193) sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:283) sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:325) sun.nio.cs.StreamDecoder.read(StreamDecoder.java:177) java.io.InputStreamReader.read(InputStreamReader.java:184) java.io.BufferedReader.fill(BufferedReader.java:154) java.io.BufferedReader.read(BufferedReader.java:175) clojure.core$slurp.doInvoke(core.clj:6279) clojure.lang.RestFn.invoke(RestFn.java:410) ring.middleware.json$read_json.doInvoke(json.clj:12) clojure.lang.RestFn.invoke(RestFn.java:423) ring.middleware.json$wrap_json_body$fn__1031.invoke(json.clj:19) ring.middleware.json$wrap_json_params$fn__1035.invoke(json.clj:31) compojure.core$routing$fn__362.invoke(core.clj:107) clojure.core$some.invoke(core.clj:2443) compojure.core$routing.doInvoke(core.clj:107) clojure.lang.RestFn.applyTo(RestFn.java:139) clojure.core$apply.invoke(core.clj:619) compojure.core$routes$fn__366.invoke(core.clj:112) health.servlet$_service$fn__1016.invoke(servlet.clj:1) ring.util.servlet$make_service_method$fn__50.invoke(servlet.clj:126) health.servlet$_service.invoke(servlet.clj:1) health.servlet.service(Unknown Source) [/code] Any help? -- -- 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 a topic in the Google Groups Clojure group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/clojure/RxctbwMoOPU/unsubscribe. To unsubscribe from this group and all its topics, 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] Jig
Ok, some more feedback for Jig. *A)* Testing - Let's say I have a multi-project jig, with dependencies across projects. There doesn't seem to be a way to run tests (midje :autotest) for a specific project. I tried creating a Midje component (see https://www.refheap.com/20442). But when I *i)* put this into config.edn, and *ii)* thread through my local project component, *iii)* this only prints out the classpath directories under the *jig* project. I'll want to be in the Classpath context of the project that's being passed in. That way, I can :autotest for that project. Or perhaps there's another way to run and autorun tests for a particular project. I noticed that Juxt-Accounting https://github.com/juxt/juxt-accounting has a test suite. *B)* Ok, so there's just that and removing the *config/console.edn* and *config/default.edn* files when writing your jig. *C)* And a raw *git clone g...@github.com:juxt/jig.git*, then *lein repl*, then * (go)*, doesn't give working URLs ( http://:8091/readme , http://:8001/server, etc ) Let me know if you want me to log these as bugs, feature requests, etc. Very excited about the kind of leverage that this project can yield. Loving this tool. Thanks. Tim Washington Interruptsoftware.ca http://interruptsoftware.ca/ / Bkeeping.comhttp://bkeeping.com/ On Sat, Nov 2, 2013 at 8:18 PM, Timothy Washington twash...@gmail.comwrote: Ok, I actually got the compojure example working. I just had to remove the *config/console.edn* and *config/default.edn* files in my jig. They must be disrupting the config that I put in. So that's my only feedback so far. Ok, this is looking really good. Great work :) Tim Washington Interruptsoftware.ca http://interruptsoftware.ca/ / Bkeeping.comhttp://bkeeping.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/groups/opt_out.
New Functional Programming Job Opportunities
Here are some functional programming job opportunities that were posted recently: Senior Clojure Software Engineer at DRW Trading Group http://functionaljobs.com/jobs/8653-senior-clojure-software-engineer-at-drw-trading-group Cheers, Sean Murphy FunctionalJobs.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/groups/opt_out.
