Re: Performance issue with hashing records
I don't think this particular example relates.
Memoize produces a function, so the time spent is really about hashing
functions which presumably hashes on the address of the function (or
something similar) and never touches the underlying record.
In the later example, you are mostly timing the cost of repeatedly
memoizing, which creates a lot of anonymous functions, and would be
expected to be more time-consuming.
The other examples you posted are interesting, though.
On Sat, Feb 2, 2013 at 11:31 PM, AtKaaZ atk...@gmail.com wrote:
ok i like this variant:
= (def r (memoize (A. a 3)))
#'runtime.q_test/r
= (time (dotimes [n 1000] (hash r)))
Elapsed time: 342.363961 msecs
nil
= (time (dotimes [n 1000] (hash r)))
Elapsed time: 361.66747 msecs
nil
= (time (dotimes [n 1000] (hash (memoize (A. a 3)
Elapsed time: 1812.016478 msecs
nil
= (time (dotimes [n 1000] (hash (memoize (A. a 3)
Elapsed time: 1847.244062 msecs
nil
On Sun, Feb 3, 2013 at 8:29 AM, AtKaaZ atk...@gmail.com wrote:
= (def m {:x a :y 3})
#'runtime.q_test/m
= (time (dotimes [n 1000] (hash m)))
Elapsed time: 154.650091 msecs
nil
= (time (dotimes [n 1000] (hash m)))
Elapsed time: 164.724641 msecs
nil
= (time (dotimes [n 1000] (hash m)))
Elapsed time: 150.194984 msecs
nil
= (time (dotimes [n 1000] (hash {:x a :y 3})))
Elapsed time: 57.981602 msecs
nil
= (time (dotimes [n 1000] (hash {:x a :y 3})))
Elapsed time: 70.803223 msecs
nil
= (time (dotimes [n 1000] (hash {:x a :y 3})))
Elapsed time: 67.395947 msecs
nil
= (def r (A. a 3))
#'runtime.q_test/r
= (time (dotimes [n 1000] (hash r)))
Elapsed time: 4906.641334 msecs
nil
= (time (dotimes [n 1000] (hash r)))
Elapsed time: 4959.124395 msecs
nil
= (time (dotimes [n 1000] (hash (A. a 3
Elapsed time: 4842.496589 msecs
nil
= (time (dotimes [n 1000] (hash (A. a 3
Elapsed time: 4856.855515 msecs
nil
On Sun, Feb 3, 2013 at 8:26 AM, AtKaaZ atk...@gmail.com wrote:
he's in RC4
= *clojure-version*
{:major 1, :minor 5, :incremental 0, :qualifier RC4}
= (time (dotimes [n 1000] (hash {:x a :y 3})))
Elapsed time: 70.037502 msecs
= (time (dotimes [n 1000] (hash (A. a 3
Elapsed time: 5307.93947 msecs
On Sun, Feb 3, 2013 at 8:22 AM, Leonardo Borges
leonardoborges...@gmail.com wrote:
Are you running these in Clojure 1.5 RC-1 by any chance? That's when I
got results similar to yours.
In Clojure 1.4, I get this:
user (time (dotimes [n 1000] (hash {:x a :y 3})))
Elapsed time: 5993.331 msecs
nil
user (time (dotimes [n 1000] (hash (A. a 3
Elapsed time: 3144.368 msecs
No clue as to the reason though - but it seems something might have
changed from 1.4 to 1.5?
Leonardo Borges
www.leonardoborges.com
On Sun, Feb 3, 2013 at 5:07 PM, Mark Engelberg
mark.engelb...@gmail.com wrote:
I just went through the process of converting my map-based program
over to
records, hoping it would improve speed. Much to my dismay, it
actually
slowed my program down substantially. With some profiling, I
discovered
that one possible explanation is that (at least in RC4) hashing of
records
is about 60x slower than their map-based counterpart.
(defrecord A [x y])
= (time (dotimes [n 1000] (hash {:x a :y 3})))
Elapsed time: 90.631072 msecs
= (time (dotimes [n 1000] (hash (A. a 3
Elapsed time: 5549.788311 msecs
Any thoughts about why this is the case?
--
--
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.
--
Please correct me if I'm wrong
Re: Performance issue with hashing records
ah I see, you're right , which made me think why would memoize allow
non-func but then I realized this:
= *((memoize {:key 1}) :key)*
1
=* ((memoize {:key 1}) :ke)*
nil
this is what I thought I was doing:
= *(def g (A. a 3))*
#'runtime.q_test/g
= *(defn f [] g)*
#'runtime.q_test/f
= *(def r (memoize f))*
#'runtime.q_test/r
=* (time (dotimes [n 1000] (hash (r*
Elapsed time: 5595.312905 msecs
nil
=* (time (dotimes [n 1000] (hash (r*
Elapsed time: 5644.041368 msecs
nil
= *(r)*
#runtime.q_test.A{:x a, :y 3}
= *r*
#core$memoize$fn__5074 clojure.core$memoize$fn__5074@4482a7fa
= *r*
#core$memoize$fn__5074 clojure.core$memoize$fn__5074@4482a7fa
= *(def r (memoize #(A. a 3)))*
#'runtime.q_test/r
= *(time (dotimes [n 1000] (hash (r*
Elapsed time: 5645.559622 msecs
nil
= *(time (dotimes [n 1000] (hash (r*
Elapsed time: 5595.968715 msecs
nil
(wonder how do some people paste colored clojure code, I'm guessing they
paste html but what do they use for to generate it? doesn't look like they
use refheap for example)
On Sun, Feb 3, 2013 at 9:13 AM, Mark Engelberg mark.engelb...@gmail.comwrote:
I don't think this particular example relates.
Memoize produces a function, so the time spent is really about hashing
functions which presumably hashes on the address of the function (or
something similar) and never touches the underlying record.
In the later example, you are mostly timing the cost of repeatedly
memoizing, which creates a lot of anonymous functions, and would be
expected to be more time-consuming.
The other examples you posted are interesting, though.
On Sat, Feb 2, 2013 at 11:31 PM, AtKaaZ atk...@gmail.com wrote:
ok i like this variant:
= (def r (memoize (A. a 3)))
#'runtime.q_test/r
= (time (dotimes [n 1000] (hash r)))
Elapsed time: 342.363961 msecs
nil
= (time (dotimes [n 1000] (hash r)))
Elapsed time: 361.66747 msecs
nil
= (time (dotimes [n 1000] (hash (memoize (A. a 3)
Elapsed time: 1812.016478 msecs
nil
= (time (dotimes [n 1000] (hash (memoize (A. a 3)
Elapsed time: 1847.244062 msecs
nil
On Sun, Feb 3, 2013 at 8:29 AM, AtKaaZ atk...@gmail.com wrote:
= (def m {:x a :y 3})
#'runtime.q_test/m
= (time (dotimes [n 1000] (hash m)))
Elapsed time: 154.650091 msecs
nil
= (time (dotimes [n 1000] (hash m)))
Elapsed time: 164.724641 msecs
nil
= (time (dotimes [n 1000] (hash m)))
Elapsed time: 150.194984 msecs
nil
= (time (dotimes [n 1000] (hash {:x a :y 3})))
Elapsed time: 57.981602 msecs
nil
= (time (dotimes [n 1000] (hash {:x a :y 3})))
Elapsed time: 70.803223 msecs
nil
= (time (dotimes [n 1000] (hash {:x a :y 3})))
Elapsed time: 67.395947 msecs
nil
= (def r (A. a 3))
#'runtime.q_test/r
= (time (dotimes [n 1000] (hash r)))
Elapsed time: 4906.641334 msecs
nil
= (time (dotimes [n 1000] (hash r)))
Elapsed time: 4959.124395 msecs
nil
= (time (dotimes [n 1000] (hash (A. a 3
Elapsed time: 4842.496589 msecs
nil
= (time (dotimes [n 1000] (hash (A. a 3
Elapsed time: 4856.855515 msecs
nil
On Sun, Feb 3, 2013 at 8:26 AM, AtKaaZ atk...@gmail.com wrote:
he's in RC4
= *clojure-version*
{:major 1, :minor 5, :incremental 0, :qualifier RC4}
= (time (dotimes [n 1000] (hash {:x a :y 3})))
Elapsed time: 70.037502 msecs
= (time (dotimes [n 1000] (hash (A. a 3
Elapsed time: 5307.93947 msecs
On Sun, Feb 3, 2013 at 8:22 AM, Leonardo Borges
leonardoborges...@gmail.com wrote:
Are you running these in Clojure 1.5 RC-1 by any chance? That's when I
got results similar to yours.
In Clojure 1.4, I get this:
user (time (dotimes [n 1000] (hash {:x a :y 3})))
Elapsed time: 5993.331 msecs
nil
user (time (dotimes [n 1000] (hash (A. a 3
Elapsed time: 3144.368 msecs
No clue as to the reason though - but it seems something might have
changed from 1.4 to 1.5?
Leonardo Borges
www.leonardoborges.com
On Sun, Feb 3, 2013 at 5:07 PM, Mark Engelberg
mark.engelb...@gmail.com wrote:
I just went through the process of converting my map-based program
over to
records, hoping it would improve speed. Much to my dismay, it
actually
slowed my program down substantially. With some profiling, I
discovered
that one possible explanation is that (at least in RC4) hashing of
records
is about 60x slower than their map-based counterpart.
(defrecord A [x y])
= (time (dotimes [n 1000] (hash {:x a :y 3})))
Elapsed time: 90.631072 msecs
= (time (dotimes [n 1000] (hash (A. a 3
Elapsed time: 5549.788311 msecs
Any thoughts about why this is the case?
--
--
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
Why is there not much conversation on Spreadsheet like APIs in this group?
Hi, the library https://github.com/straszheimjeffrey/dataflow and http://richhickey.github.com/clojure-contrib/dataflow-api.html (1) or https://github.com/gcv/dgraph seems to me very cool for systems that need to react on changes on dependent values. I very much like the API in (1) Actually my personal opinion is that this is a very substantial thing in business applications. Am I wrong but nobody seems to bother about them? (I am not well clojure connected so this assumption is totally based on git-update-dates / clojure-user-group discussions / planet.clojure.in posts) Many Greetings John -- -- 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 code so slow?
On Feb 3, 12:54 pm, Curtis Gagliardi gagliardi.cur...@gmail.com wrote: I took your version Feng and used rem instead of mod and added a type hint and got down from: 23217.321626 = 11398.389942 No idea where to go from here though. I'm surprised there's such a difference even not using any sort of collection. (defn smallest-multiple-of-1-to-n-hinted-rem [^long n] (loop [i n] (if (loop [d 2] (cond ( d n) true (not= 0 (rem i d)) false :else (recur (inc d i (recur (inc i I was able to shave off some more by writing (not= 0 (rem i d)) as ( 0 (rem i d)). Shantanu -- -- 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 code so slow?
On Sun, Feb 3, 2013 at 2:42 AM, Shantanu Kumar kumar.shant...@gmail.comwrote: I was able to shave off some more by writing (not= 0 (rem i d)) as ( 0 (rem i d)). Haven't tested, but based on past experience I would expect (not (zero? (rem i d))) to be the fastest way, or possibly (pos? (rem i d)) In general, zero?, pos?, and neg? are faster than comparing to 0 with = and . --Mark -- -- 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 code so slow?
I was able to shave off some more by writing (not= 0 (rem i d)) as ( 0 (rem i d)). the running time is about 4787ms on my computer, compare to *2759ms *of the java version, a bit slower, but not much. 沈锋 美味书签 : http://meiweisq.com 博客： http://shenfeng.me On Sun, Feb 3, 2013 at 6:42 PM, Shantanu Kumar kumar.shant...@gmail.comwrote: On Feb 3, 12:54 pm, Curtis Gagliardi gagliardi.cur...@gmail.com wrote: I took your version Feng and used rem instead of mod and added a type hint and got down from: 23217.321626 = 11398.389942 No idea where to go from here though. I'm surprised there's such a difference even not using any sort of collection. (defn smallest-multiple-of-1-to-n-hinted-rem [^long n] (loop [i n] (if (loop [d 2] (cond ( d n) true (not= 0 (rem i d)) false :else (recur (inc d i (recur (inc i I was able to shave off some more by writing (not= 0 (rem i d)) as ( 0 (rem i d)). Shantanu -- -- 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 code so slow?
On Feb 3, 3:54 pm, Shen, Feng shen...@gmail.com wrote: I was able to shave off some more by writing (not= 0 (rem i d)) as ( 0 (rem i d)). the running time is about 4787ms on my computer, compare to *2759ms *of the java version, a bit slower, but not much. 沈锋 美味书签 :http://meiweisq.com 博客：http://shenfeng.me On Sun, Feb 3, 2013 at 6:42 PM, Shantanu Kumar kumar.shant...@gmail.comwrote: On Feb 3, 12:54 pm, Curtis Gagliardi gagliardi.cur...@gmail.com wrote: I took your version Feng and used rem instead of mod and added a type hint and got down from: 23217.321626 = 11398.389942 No idea where to go from here though. I'm surprised there's such a difference even not using any sort of collection. (defn smallest-multiple-of-1-to-n-hinted-rem [^long n] (loop [i n] (if (loop [d 2] (cond ( d n) true (not= 0 (rem i d)) false :else (recur (inc d i (recur (inc i I was able to shave off some more by writing (not= 0 (rem i d)) as ( 0 (rem i d)). For some reason, by splitting out the inner loop into a function shaved 6 more seconds (from 34s to 28s) on my low-config 32-bit laptop: (defn every-d? [^long x ^long n] (loop [d 2] (cond ( d n) true ( 0 (rem x d)) false :otherwise (recur (inc d) (defn smallest-multiple-of-1-to-n [n] (let [n (long n)] (loop [x n] (if (every-d? x n) x (recur (inc x)) Changing ( 0 ...) to (pos? ..) had no noticeable delay. This is of course only a micro-benchmark and numbers would probably change when the JIT compiler kicks in. With *unchecked-math* set to true, the Clojure version above takes 28s. Interestingly, when I modified the Java version to use Long, the time went up from 18s to 40s and for unboxed long, the time went up from 18s to 37s. Shantanu -- -- 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 code so slow?
Given that I don't know much about how scala does optimizations, I find the question of why the scala version is faster than the Java version even more interesting. It seems to me that in Scala, the list (don't know the actual data type which is created) of 1 to 20 is created each time isDivisibleByAll is called which (probably?) creates some overhead. The Java version doesn't create the list for each check, but it uses an ArrayList where it could use an array and Integer where it could use int - shenedu makes that optimization in the buttom, but it only improves about half a second according to him. So what's going on the Scala version? On Sunday, February 3, 2013 3:28:09 AM UTC+1, Alexandros Bantis wrote: Hello all. I'm working through the Project Euler problems in Java, Scala, Clojure (trying to learn all three?!?). I notice that for one particular problem, I use--more or less--a similar algorithm for all three, but the clojure code runs about 20-30 times slower than the java/scala versions. Does anyone have any idea why this might be? It strikes me that it might have something to do with every? but I don't know because I'm a newbie with Clojure. http://stackoverflow.com/questions/14668272/what-can-i-do-to-speed-up-this-code thanks, alex -- -- 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 code so slow?
Changing ( 0 ...) to (pos? ..) had no noticeable delay. I meant 'difference', not 'delay'. Shantanu -- -- 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 there not much conversation on Spreadsheet like APIs in this group?
Thank you for this(I'm now looking into dgraph), I am very interested in such things, though you should look at me like a I'm a newbie in both this and clojure. Whatever I end up doing will unavoidable use such concepts: graph, dependencies... I imagine that a properly implemented system like so, would require no restart, because only the affected nodes will get updated... sort of like 'make' does in a project when you changed some file, but on the elemental(lowest?) level . Ok, later, cause I don't seem to be in the zone to talk about this. On Sun, Feb 3, 2013 at 10:39 AM, john john.vie...@gmail.com wrote: Hi, the library https://github.com/straszheimjeffrey/dataflow and http://richhickey.github.com/clojure-contrib/dataflow-api.html (1) or https://github.com/gcv/dgraph seems to me very cool for systems that need to react on changes on dependent values. I very much like the API in (1) Actually my personal opinion is that this is a very substantial thing in business applications. Am I wrong but nobody seems to bother about them? (I am not well clojure connected so this assumption is totally based on git-update-dates / clojure-user-group discussions / planet.clojure.in posts) Many Greetings John -- -- 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. -- Please correct me if I'm wrong or incomplete, even if you think I'll subconsciously hate it. -- -- 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 code so slow?
The Scala version is probably faster because it uses a range (1 to top) which is represented as a pair of integers (the start and endpoint). Perhaps the JVM can even eliminate that completely with escape analysis. The Java version is repeatedly filling an ArrayList with the numbers in that range. On Sunday, February 3, 2013 12:19:51 PM UTC+1, Casper Clausen wrote: Given that I don't know much about how scala does optimizations, I find the question of why the scala version is faster than the Java version even more interesting. It seems to me that in Scala, the list (don't know the actual data type which is created) of 1 to 20 is created each time isDivisibleByAll is called which (probably?) creates some overhead. The Java version doesn't create the list for each check, but it uses an ArrayList where it could use an array and Integer where it could use int - shenedu makes that optimization in the buttom, but it only improves about half a second according to him. So what's going on the Scala version? On Sunday, February 3, 2013 3:28:09 AM UTC+1, Alexandros Bantis wrote: Hello all. I'm working through the Project Euler problems in Java, Scala, Clojure (trying to learn all three?!?). I notice that for one particular problem, I use--more or less--a similar algorithm for all three, but the clojure code runs about 20-30 times slower than the java/scala versions. Does anyone have any idea why this might be? It strikes me that it might have something to do with every? but I don't know because I'm a newbie with Clojure. http://stackoverflow.com/questions/14668272/what-can-i-do-to-speed-up-this-code thanks, alex -- -- 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: http-kit 2.0.0.RC2, high performance HTTP Server Client for Clojure
Quick anecdote: I've got an HTTP Kit server running in a test environment and the initial results are *very* promising. It's handling a mix of sync, async, and WebSocket requests and so far has been a pleasure to use. HTTP Kit's sweet spot seems to be quite large too: folks running high-traffic (esp. high-concurrency) web servers that are resource or performance sensitive. I would recommend running behind a reverse proxy (nginx, say) given the server's relative immaturity - but I'd normally recommend doing that anyway, and I haven't encountered any specific problems yet myself. And I haven't had a chance to use it much, but the HTTP client looks pretty great too. Exciting stuff! -- -- 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 code so slow?
without looking at the code: ranges in scala have been optimized in i think 2.10 to be able to be inlineable completely when you iterate over them. at runtime, it *should* be equal to a simple while loop and a counter variable Am 03.02.2013 14:28, schrieb Jules: The Scala version is probably faster because it uses a range (1 to top) which is represented as a pair of integers (the start and endpoint). Perhaps the JVM can even eliminate that completely with escape analysis. The Java version is repeatedly filling an ArrayList with the numbers in that range. On Sunday, February 3, 2013 12:19:51 PM UTC+1, Casper Clausen wrote: Given that I don't know much about how scala does optimizations, I find the question of why the scala version is faster than the Java version even more interesting. It seems to me that in Scala, the list (don't know the actual data type which is created) of 1 to 20 is created each time isDivisibleByAll is called which (probably?) creates some overhead. The Java version doesn't create the list for each check, but it uses an ArrayList where it could use an array and Integer where it could use int - shenedu makes that optimization in the buttom, but it only improves about half a second according to him. So what's going on the Scala version? On Sunday, February 3, 2013 3:28:09 AM UTC+1, Alexandros Bantis wrote: Hello all. I'm working through the Project Euler problems in Java, Scala, Clojure (trying to learn all three?!?). I notice that for one particular problem, I use--more or less--a similar algorithm for all three, but the clojure code runs about 20-30 times slower than the java/scala versions. Does anyone have any idea why this might be? It strikes me that it might have something to do with every? but I don't know because I'm a newbie with Clojure. http://stackoverflow.com/questions/14668272/what-can-i-do-to-speed-up-this-code http://stackoverflow.com/questions/14668272/what-can-i-do-to-speed-up-this-code thanks, alex -- -- 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 code so slow?
If your goal is just to make it fast, then you should use a different algorithm, e.g. (defn bump-up Bump up n by a multiple of x until greater than or equal to k. [n x k] (if (= n k) n (recur (+ n x) x k))) (defn bump-up-fast Bump up n by a multiple of x until greater than or equal to k in O(1). [n x k] exercise for the reader) (defn lcm Compute the least common multiple of a and b. [a b] (loop [n a k b] (cond ( n k) (recur (bump-up n a k) k) ( n k) (recur n (bump-up k b n)) (= n k) n))) (defn smallest-multiple-of-1-to-n [n] (reduce lcm (range 1 (+ n 1 On Sunday, February 3, 2013 3:28:09 AM UTC+1, Alexandros Bantis wrote: Hello all. I'm working through the Project Euler problems in Java, Scala, Clojure (trying to learn all three?!?). I notice that for one particular problem, I use--more or less--a similar algorithm for all three, but the clojure code runs about 20-30 times slower than the java/scala versions. Does anyone have any idea why this might be? It strikes me that it might have something to do with every? but I don't know because I'm a newbie with Clojure. http://stackoverflow.com/questions/14668272/what-can-i-do-to-speed-up-this-code thanks, alex -- -- 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 there not much conversation on Spreadsheet like APIs in this group?
On Feb 3, 2013 4:40 AM, john john.vie...@gmail.com wrote: seems to me very cool for systems that need to react on changes on dependent values. I very much like the API in (1) Actually my personal opinion is that this is a very substantial thing in business applications. In such an application, I found more use for Jeff Straszheim's graph contrib library, now packaged with datalog, than the cells-ish stuff. This is probably because my Clojure style seeks immutable solutions, and cells-ishs don't fit in that category. -- Stephen Compall If anyone in the MSA is online, you should watch this flythrough. On Feb 3, 2013 4:40 AM, john john.vie...@gmail.com wrote: Hi, the library https://github.com/straszheimjeffrey/dataflow and http://richhickey.github.com/clojure-contrib/dataflow-api.html (1) or https://github.com/gcv/dgraph seems to me very cool for systems that need to react on changes on dependent values. I very much like the API in (1) Actually my personal opinion is that this is a very substantial thing in business applications. Am I wrong but nobody seems to bother about them? (I am not well clojure connected so this assumption is totally based on git-update-dates / clojure-user-group discussions / planet.clojure.in posts) Many Greetings John -- -- 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 code so slow?
For some reason, by splitting out the inner loop into a function shaved 6 more seconds (from 34s to 28s) on my low-config 32-bit laptop: Pulling every-d? out into it's own function slowed things down a few seconds for me. Strange stuff. -- -- 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 code so slow?
Was on clojure 1.4, just tried on 1.5.0-RC4 and its a few hundred miliseconds faster in its own function. 4921.78197 msecs vs 5251.267893 msecs On Sunday, February 3, 2013 11:52:11 AM UTC-6, Curtis Gagliardi wrote: For some reason, by splitting out the inner loop into a function shaved 6 more seconds (from 34s to 28s) on my low-config 32-bit laptop: Pulling every-d? out into it's own function slowed things down a few seconds for me. Strange stuff. -- -- 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 code so slow?
yes, I believe I can just make a list of the greatest common factors and then multiply them out to get the number rather than iterating through 2 through n. Still, I'm curious about the performance difference, since all three are running on the same JVM and ultimately are all compiled down to java byte code, you would expect that a similar algorithm would produce similar results across the three. On 02/03/2013 07:29 AM, Jules wrote: If your goal is just to make it fast, then you should use a different algorithm, e.g. (defn bump-up Bump up n by a multiple of x until greater than or equal to k. [n x k] (if (= n k) n (recur (+ n x) x k))) (defn bump-up-fast Bump up n by a multiple of x until greater than or equal to k in O(1). [n x k] exercise for the reader) (defn lcm Compute the least common multiple of a and b. [a b] (loop [n a k b] (cond ( n k) (recur (bump-up n a k) k) ( n k) (recur n (bump-up k b n)) (= n k) n))) (defn smallest-multiple-of-1-to-n [n] (reduce lcm (range 1 (+ n 1 On Sunday, February 3, 2013 3:28:09 AM UTC+1, Alexandros Bantis wrote: Hello all. I'm working through the Project Euler problems in Java, Scala, Clojure (trying to learn all three?!?). I notice that for one particular problem, I use--more or less--a similar algorithm for all three, but the clojure code runs about 20-30 times slower than the java/scala versions. Does anyone have any idea why this might be? It strikes me that it might have something to do with every? but I don't know because I'm a newbie with Clojure. http://stackoverflow.com/questions/14668272/what-can-i-do-to-speed-up-this-code http://stackoverflow.com/questions/14668272/what-can-i-do-to-speed-up-this-code thanks, alex -- -- 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 there not much conversation on Spreadsheet like APIs in this group?
@stephan thank you for your info. so if I understand you correctly you use https://github.com/fogus/bacwn/blob/master/src/clojure/fogus/datalog/bacwn/impl/graph.clj to build a dependency tree of your data and then query this tree to find the dependent values(cells) that need updates. Am Sonntag, 3. Februar 2013 18:47:12 UTC+1 schrieb Stephen Compall: On Feb 3, 2013 4:40 AM, john john@gmail.com javascript: wrote: seems to me very cool for systems that need to react on changes on dependent values. I very much like the API in (1) Actually my personal opinion is that this is a very substantial thing in business applications. In such an application, I found more use for Jeff Straszheim's graph contrib library, now packaged with datalog, than the cells-ish stuff. This is probably because my Clojure style seeks immutable solutions, and cells-ishs don't fit in that category. -- Stephen Compall If anyone in the MSA is online, you should watch this flythrough. On Feb 3, 2013 4:40 AM, john john@gmail.com javascript: wrote: Hi, the library https://github.com/straszheimjeffrey/dataflow and http://richhickey.github.com/clojure-contrib/dataflow-api.html (1) or https://github.com/gcv/dgraph seems to me very cool for systems that need to react on changes on dependent values. I very much like the API in (1) Actually my personal opinion is that this is a very substantial thing in business applications. Am I wrong but nobody seems to bother about them? (I am not well clojure connected so this assumption is totally based on git-update-dates / clojure-user-group discussions / planet.clojure.in posts) Many Greetings John -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clo...@googlegroups.comjavascript: Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+u...@googlegroups.com javascript: 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+u...@googlegroups.com javascript:. 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.
Inflection on clojure.java.io/reader and writer
Hey guys, I'm trying to read a lot of data, sometimes from *in* and sometimes from a file. I extensively use the native .write and .read java methods. According to the clojure doc for reader, it says that Default implementations always return a BufferedReader. However, when I write, (*defn* solve [src dest] (*let* [in (clojure.java.io/reader src) out (clojure.java.io/writer dest) I get a bunch of reflection warnings on .read and .write, and most of the running time is spent on reflection. AFAIK you can't type hint a (let) construct, so what should I do here? 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.
Re: Inflection on clojure.java.io/reader and writer
Why not add type hints like this ? (let [^java.io.BufferedReader in ^java.io.BufferedWriter out ...] .. Luc P. Hey guys, I'm trying to read a lot of data, sometimes from *in* and sometimes from a file. I extensively use the native .write and .read java methods. According to the clojure doc for reader, it says that Default implementations always return a BufferedReader. However, when I write, (*defn* solve [src dest] (*let* [in (clojure.java.io/reader src) out (clojure.java.io/writer dest) I get a bunch of reflection warnings on .read and .write, and most of the running time is spent on reflection. AFAIK you can't type hint a (let) construct, so what should I do here? 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. -- Softaddictslprefonta...@softaddicts.ca sent by ibisMail from my ipad! -- -- 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: Inflection on clojure.java.io/reader and writer
Unfortunately it doesn't work. Reflection warning, NO_SOURCE_PATH:20 - call to write can't be resolved. Reflection warning, NO_SOURCE_PATH:21 - reference to field newLine can't be resolved. On Sunday, February 3, 2013 2:35:23 PM UTC-5, Luc wrote: Why not add type hints like this ? (let [^java.io.BufferedReader in ^java.io.BufferedWriter out ...] .. Luc P. Hey guys, I'm trying to read a lot of data, sometimes from *in* and sometimes from a file. I extensively use the native .write and .read java methods. According to the clojure doc for reader, it says that Default implementations always return a BufferedReader. However, when I write, (*defn* solve [src dest] (*let* [in (clojure.java.io/reader src) out (clojure.java.io/writer dest) I get a bunch of reflection warnings on .read and .write, and most of the running time is spent on reflection. AFAIK you can't type hint a (let) construct, so what should I do here? Thanks! -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clo...@googlegroups.comjavascript: Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+u...@googlegroups.com javascript: 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+u...@googlegroups.com javascript:. For more options, visit https://groups.google.com/groups/opt_out. -- Softaddictslprefo...@softaddicts.ca javascript: sent by ibisMail from my ipad! -- -- 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 there not much conversation on Spreadsheet like APIs in this group?
On Feb 3, 2013 1:42 PM, john john.vie...@gmail.com wrote: so if I understand you correctly you use https://github.com/fogus/bacwn/blob/master/src/clojure/fogus/datalog/bacwn/impl/graph.clj to build a dependency tree of your data and then query this tree to find the dependent values(cells) that need updates. Yes. Aside from the mutability issue, I also had other problems to which graphs were well-suited, but cells-ishs were not. For example, given the metadata to build a graph, optimum conversion function generalizes to shortest path. -- Stephen Compall If anyone in the MSA is online, you should watch this flythrough. -- -- 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: Inflection on clojure.java.io/reader and writer
Can you post a larger chunk of code for us to examine, perhaps on github or as a gist if it is over 30 lines of code or so? Many of us have had good success with eliminating reflection using type hints, so it should be possible to make it work. Andy On Feb 3, 2013, at 12:50 PM, Kanwei Li wrote: Unfortunately it doesn't work. Reflection warning, NO_SOURCE_PATH:20 - call to write can't be resolved. Reflection warning, NO_SOURCE_PATH:21 - reference to field newLine can't be resolved. On Sunday, February 3, 2013 2:35:23 PM UTC-5, Luc wrote: Why not add type hints like this ? (let [^java.io.BufferedReader in ^java.io.BufferedWriter out ...] .. Luc P. Hey guys, I'm trying to read a lot of data, sometimes from *in* and sometimes from a file. I extensively use the native .write and .read java methods. According to the clojure doc for reader, it says that Default implementations always return a BufferedReader. However, when I write, (*defn* solve [src dest] (*let* [in (clojure.java.io/reader src) out (clojure.java.io/writer dest) I get a bunch of reflection warnings on .read and .write, and most of the running time is spent on reflection. AFAIK you can't type hint a (let) construct, so what should I do here? 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.
Execute a subprocess that takes input e.g. emacs
Hi, Is there a straightforward way to invoke an editor within clojure e.g. (clojure.java.shell/sh emacs some-file)? I've taken a look at popular shell libraries like conch and stevedore but found nothing helpful. If you're curious why I want to do it, it's to open a lein dependency in emacs from the commandline, https://github.com/cldwalker/lein-open . Thanks, Gabriel -- -- 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 code so slow?
On Feb 3, 11:40 pm, Alexandros Bantis amban...@gmail.com wrote: yes, I believe I can just make a list of the greatest common factors and then multiply them out to get the number rather than iterating through 2 through n. Still, I'm curious about the performance difference, since all three are running on the same JVM and ultimately are all compiled down to java byte code, you would expect that a similar algorithm would produce similar results across the three. I ran both provided Java code and my Clojure code (defaulting to (int n) just like the Java version) with JVM `-server` option and. It made no difference to the Java version at 18s, but the Clojure version came down to 22s. This is probably because JIT inlining is more effective in the -server mode and Clojure's primitive support depends on inlining for performance: http://clojure.org/news Shantanu -- -- 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: Execute a subprocess that takes input e.g. emacs
I was able to open an X windows emacs session using:
(require '[clojure.java.shell :as sh])
(sh/sh emacs)
on my system. The REPL did not give another prompt until I quit that emacs
invocation. I was able to get another REPL prompt immediately using this:
(future (sh/sh emacs))
When I tried running the terminal version of emacs without using the X window
system, it gave a valid complaint like this:
user= (sh/sh emacs -nw)
{:exit 1, :out , :err emacs: standard input is not a tty\n}
You can also specify the file name and line number where the cursor should
initially be placed like so:
(sh/sh emacs +57 foo.txt)
In case it matters what versions of things I am using, I was able to get
similar results above on both of the following systems:
Mac OS X 10.6.8 + Oracle/Apple JDK 1.6.0_37 + Leiningen 2.0.0 + Clojure
1.5.0-RC2
Ubuntu 11.10 32-bit desktop + Oracle JDK 1.6.0_38 + Leiningen 2.0.0 + Clojure
1.5.0-RC4
I also tried it with Clojure 1.4.0 with the same good results.
Andy
On Feb 3, 2013, at 2:30 PM, Gabriel Horner wrote:
Hi,
Is there a straightforward way to invoke an editor within clojure e.g.
(clojure.java.shell/sh emacs some-file)?
I've taken a look at popular shell libraries like conch and stevedore but
found nothing helpful.
If you're curious why I want to do it, it's to open a lein dependency in
emacs from the commandline, https://github.com/cldwalker/lein-open .
Thanks,
Gabriel
--
--
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: Performance issue with hashing records
On Sunday, February 3, 2013 1:07:41 AM UTC-5, puzzler wrote:
I just went through the process of converting my map-based program over to
records, hoping it would improve speed. Much to my dismay, it actually
slowed my program down substantially. With some profiling, I discovered
that one possible explanation is that (at least in RC4) hashing of records
is about 60x slower than their map-based counterpart.
(defrecord A [x y])
= (time (dotimes [n 1000] (hash {:x a :y 3})))
Elapsed time: 90.631072 msecs
= (time (dotimes [n 1000] (hash (A. a 3
Elapsed time: 5549.788311 msecs
Any thoughts about why this is the case?
There was a change for 1.5 to cache hasheq for maps
https://github.com/clojure/clojure/commit/d77489d3ce912c177fe288a6f399a5c1da6683db
but the same is not done for defrecords. That is why maps are so much
faster than records.
Paul
--
--
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: Performance issue with hashing records
In these examples, the map/record is freshly created each time through the
loop, so caching should not be a factor.
In fact, later in the thread, AtKaaZ posted an example which demonstrated
his timing results when computing the hash repeatedly on the same object.
Oddly, the performance of hashing on maps got* worse *when repeatedly
hashing the same object (records were unaffected), implying that it was
taking more time to retrieve the cached hash than to just compute it from
scratch -- very strange.
--Mark
On Sun, Feb 3, 2013 at 4:47 PM, Paul Stadig p...@stadig.name wrote:
On Sunday, February 3, 2013 1:07:41 AM UTC-5, puzzler wrote:
I just went through the process of converting my map-based program over
to records, hoping it would improve speed. Much to my dismay, it actually
slowed my program down substantially. With some profiling, I discovered
that one possible explanation is that (at least in RC4) hashing of records
is about 60x slower than their map-based counterpart.
(defrecord A [x y])
= (time (dotimes [n 1000] (hash {:x a :y 3})))
Elapsed time: 90.631072 msecs
= (time (dotimes [n 1000] (hash (A. a 3
Elapsed time: 5549.788311 msecs
Any thoughts about why this is the case?
There was a change for 1.5 to cache hasheq for maps
https://github.com/clojure/clojure/commit/d77489d3ce912c177fe288a6f399a5c1da6683dbbut
the same is not done for defrecords. That is why maps are so much
faster than records.
Paul
--
--
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: Equality comparison in 1.3
Yes, the Clojure 1.3 doc is wrong. As a new Clojure user, I was pretty confused for a while. But after reading this thread I still don't understand why the map behavior (where 3 and 3.0 are considered different map keys) wasn't considered incorrect, rather than the = behavior. http://clojure.org/data_structures has this general statement: - Contagion BigInts and floating point types are contagious across operations. That is, any integer operation involving a BigInt will result in a BigInt, and any operation involving a double or float will result in a double. Since this does seem to apply to and , why wouldn't = fall into the same category, and therefore why wouldn't it be the map behavior that was considered incorrect? Said differently, what is the rationale for the map behavior? --mark -- -- 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 there not much conversation on Spreadsheet like APIs in this group?
John, Thanks for your email and the links, I'm interested in this topic and wasn't aware of the previous work you referenced. I would't be surprised if the sentiments expressed by Stephen Compall in this thread, specially my Clojure style seeks immutable solutions, and cells-ishs don't fit in that category might be shared by many in the Clojure community. Just something to keep in mind, and it is certainly possible that I'm wrong about this. Important parts of the app I am currently working on definitely have a need to react to changes on dependent values Right now, unfortunately, I am attempting to manage the dependency graph and the resulting updates/propagations manually, which is tedious and prone to error. I'm actively looking for a solution that would automate some or all of this. I'm wondering if this kind of thing might work well in conjunction with the graph library recently released by Prismatic, and there are are similar work-alike libraries. One idea I am currently mulling over is compiling a computation specified in the graph manner into a dynamically updatable realization/implementation, somewhat similar to the way that Prismatic compiles their graphs into maps , lazy maps, or a map with each subcomputation spawned in parallel via futures. I'm definitely interested in talking/working with others with similar interests/requirements…. Don On Feb 3, 2013, at 1:39 AM, john john.vie...@gmail.com wrote: Hi, the library https://github.com/straszheimjeffrey/dataflow and http://richhickey.github.com/clojure-contrib/dataflow-api.html (1) or https://github.com/gcv/dgraph seems to me very cool for systems that need to react on changes on dependent values. I very much like the API in (1) Actually my personal opinion is that this is a very substantial thing in business applications. Am I wrong but nobody seems to bother about them? (I am not well clojure connected so this assumption is totally based on git-update-dates / clojure-user-group discussions / planet.clojure.in posts) -- -- 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: Inflection on clojure.java.io/reader and writer
works for me:
= (*let [^java.io.BufferedReader a
(clojure.java.io/readerc:\\windows\\setupact.log)] (println (. a
readLine)))
*
AudMig: No audio endpoint migration settings found 0x2
nil
= *(let [a (clojure.java.io/reader c:\\windows\\setupact.log)] (println
(. a readLine)))*
Reflection warning, NO_SOURCE_PATH:1:72 - reference to field readLine can't
be resolved.
AudMig: No audio endpoint migration settings found 0x2
nil
= **clojure-version**
{:major 1, :minor 5, :incremental 0, :qualifier RC4}
On Sun, Feb 3, 2013 at 9:50 PM, Kanwei Li kan...@gmail.com wrote:
Unfortunately it doesn't work.
Reflection warning, NO_SOURCE_PATH:20 - call to write can't be resolved.
Reflection warning, NO_SOURCE_PATH:21 - reference to field newLine can't
be resolved.
On Sunday, February 3, 2013 2:35:23 PM UTC-5, Luc wrote:
Why not add type hints like this ?
(let [^java.io.BufferedReader in
^java.io.BufferedWriter out ...]
..
Luc P.
Hey guys,
I'm trying to read a lot of data, sometimes from *in* and sometimes
from a
file. I extensively use the native .write and .read java methods.
According to the clojure doc for reader, it says that Default
implementations always return a BufferedReader. However, when I write,
(*defn* solve [src dest]
(*let* [in (clojure.java.io/reader src)
out (clojure.java.io/writer dest)
I get a bunch of reflection warnings on .read and .write, and most of
the
running time is spent on reflection. AFAIK you can't type hint a (let)
construct, so what should I do here?
Thanks!
--
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clo...@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+u...@**googlegroups.com
For more options, visit this group at
http://groups.google.com/**group/clojure?hl=enhttp://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+u...@**googlegroups.com.
For more options, visit
https://groups.google.com/**groups/opt_outhttps://groups.google.com/groups/opt_out.
--
Softaddictslprefo...@**softaddicts.ca sent by ibisMail from my ipad!
--
--
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.
--
Please correct me if I'm wrong or incomplete,
even if you think I'll subconsciously hate it.
--
--
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 there not much conversation on Spreadsheet like APIs in this group?
There has been some discussion of lazily computed expressions in the Numerical Clojure group: https://groups.google.com/forum/?fromgroups=#!forum/numerical-clojure There, the interest is really in deferring execution of large matrix operations until and efficient execution strategy can be determined. The capability to do this kind of thing is being build into the core.matrix APIs at the moment, collaboration on this would be welcome. As a related point, if you are thinking of spreadsheet in the sense of a multi-dimensional grid, then you should definitely be looking at core.matrix anyway - it is shaping up to be the defacto standard for managing multi-dimensional array data structures in Clojure On Monday, 4 February 2013 14:06:27 UTC+8, dcj wrote: John, Thanks for your email and the links, I'm interested in this topic and wasn't aware of the previous work you referenced. I would't be surprised if the sentiments expressed by Stephen Compall in this thread, specially my Clojure style seeks immutable solutions, and cells-ishs don't fit in that category might be shared by many in the Clojure community. Just something to keep in mind, and it is certainly possible that I'm wrong about this. Important parts of the app I am currently working on definitely have a need to react to changes on dependent values Right now, unfortunately, I am attempting to manage the dependency graph and the resulting updates/propagations manually, which is tedious and prone to error. I'm actively looking for a solution that would automate some or all of this. I'm wondering if this kind of thing might work well in conjunction with the graph library recently released by Prismatic, and there are are similar work-alike libraries. One idea I am currently mulling over is compiling a computation specified in the graph manner into a dynamically updatable realization/implementation, somewhat similar to the way that Prismatic compiles their graphs into maps , lazy maps, or a map with each subcomputation spawned in parallel via futures. I'm definitely interested in talking/working with others with similar interests/requirements…. Don On Feb 3, 2013, at 1:39 AM, john john@gmail.com javascript: wrote: Hi, the library https://github.com/straszheimjeffrey/dataflow and http://richhickey.github.com/clojure-contrib/dataflow-api.html (1) or https://github.com/gcv/dgraph seems to me very cool for systems that need to react on changes on dependent values. I very much like the API in (1) Actually my personal opinion is that this is a very substantial thing in business applications. Am I wrong but nobody seems to bother about them? (I am not well clojure connected so this assumption is totally based on git-update-dates / clojure-user-group discussions / planet.clojure.in posts) -- -- 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.
IllegalAccessError problem when referring non-public classes
Hi, I'm trying to create Excel files with jexcelapi: https://sourceforge.net/projects/jexcelapi/files/jexcelapi API provides a method of creating Excel fonts which uses instances of a non-public inner class: public WritableFont(FontName fn, int ps, BoldStyle bs, boolean it, UnderlineStyle us, Colour c) where BoldStyle is a non-public static inner class of WritableFont. When I'm in Java, I'm supposed to use the WritableFont.BOLD and WritableFont.NO_BOLD constants provided by the WritableFont class to pass as the 'BoldStyle bs' parameter: new WritableFont(WritableFont.TIMES, 16, WritableFont.BOLD, true); This compiles and works Ok in Java, but when I try to execute the Clojure equivalent: (WritableFont. WritableFont/TIMES 16 WritableFont/BOLD true) it causes the following exception java.lang.IllegalAccessError: tried to access class jxl.write.WritableFont$BoldStyle from class test.excel$eval775 at test.excel$eval775.invoke (:1) clojure.lang.Compiler.eval (Compiler.java:6511) clojure.lang.Compiler.eval (Compiler.java:6477) clojure.core$eval.invoke (core.clj:2797) clojure.main$repl$read_eval_print__6405.invoke (main.clj:245) clojure.main$repl$fn__6410.invoke (main.clj:266) clojure.main$repl.doInvoke (main.clj:266) clojure.lang.RestFn.invoke (RestFn.java:1096) clojure.tools.nrepl.middleware.interruptible_eval$evaluate$fn__511.invoke (interruptible_eval.clj:58) clojure.lang.AFn.applyToHelper (AFn.java:159) clojure.lang.AFn.applyTo (AFn.java:151) clojure.core$apply.invoke (core.clj:601) clojure.core$with_bindings_STAR_.doInvoke (core.clj:1771) clojure.lang.RestFn.invoke (RestFn.java:425) clojure.tools.nrepl.middleware.interruptible_eval$evaluate.invoke (interruptible_eval.clj:43) clojure.tools.nrepl.middleware.interruptible_eval$interruptible_eval$fn__552$fn__554.invoke (interruptible_eval.clj:173) clojure.core$comp$fn__4034.invoke (core.clj:2278) ... Regards, Vladimir -- -- 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.
