Re: Lessons Learned from Adopting Clojure
Interesting - thanks all. My experience of Light Table is quite close to Norman's, although I discounted that *in my case* to not spending enough time with it. Knowing a little about who Sean is (from following your blog/comments/clojure.jdbc, not stalking! :)) I put a lot of weight behind his opinion. Brian's too, whose emacs's environment is similar to mine. I happen to run midge :autotest in a separate console rather than in emacs with xmonad as my desktop manager (I mention xmonad because if you haven't checked it out you should - you will love it or hate it). Guess I just need to carve out some time to play with it myself. On Wednesday, 5 February 2014 06:09:38 UTC, Sean Corfield wrote: On Tue, Feb 4, 2014 at 6:07 PM, Brian Marick mar...@exampler.comjavascript: wrote: I always grate at the need to then immortalize the core of what I did in the REPL in repeatable tests. That's actually one of the things that bothered me in the Emacs REPL world: working in the REPL was separate from working in my production source and my test source. It's one of the things that has me really hooked on LightTable. I have my source and test namespaces both open. I have them both connected to a REPL. I can evaluate any code, in place, in either file. If I grow some code in the source file, I can put (defn some-name [args]) in front of it and M-) slurps it into a function - done! If I grow some code in the test file, I can put (expect result-value) in front of it and M-) slurps it into a test - done! Since I moved to LightTable, I've found myself doing even more REPL-Driven-Development than before because it's so much easier to turn the experiments into code - or tests - in place. -- 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: [ANN] Jig
Hi Malcolm, I have a follow up question if you don't mind. Suppose I want to define a component that starts a thread and regularly checks a resource. If the resource changes, this has repercussions for other (dependent) components. How would you do that in jig? Maybe this question is too broad, so let me ask some more specific questions. All components should get/set their state from/in the system map, right? Now the system map is a var defined in the user namespace. Does this mean then that the resource-checking thread should alter the system var? And then I guess it should also call user/reset? Or am I still missing something here? BTW, not that I want to press you, but do you have any idea when you will be finishing up version 2? I ask because it seems that the github code currently is kind of in-between versions... Thanks again, Joachim. -- 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] garden-watch
Hey Dave, Thanks for that heads up. I originally wanted auto-compiling for *HAML* and *SCSS*. But then thought why, when I could just use edn with *Hiccup* and *Garden*. Now, a lein-hiccup, or some auto compile tool doesn't exist to my knowledge. So *i)* I had to do that work anyways. Then I spent 20 mins replicating the functionality for Garden. Also I think lein-garden tracks edn style definitions, inlined in your existing Clojure code, whereas *ii)*I wanted a separate directory watcher on edn files (no namespaces needed). But there's nothing that says that functionality in garden-watch couldn't be collapsed into lein-garden. It's pretty straightforward code. Tim Washington Interruptsoftware.com http://interruptsoftware.com On Wed, Feb 5, 2014 at 2:50 AM, Dave Sann daves...@gmail.com wrote: FYI, I think lein garden does this already. is there a particular difference? -- 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: Lessons Learned from Adopting Clojure
On Wednesday, February 5, 2014, Sean Corfield wrote: It's one of the things that has me really hooked on LightTable. I have my source and test namespaces both open. I have them both connected to a REPL. I can evaluate any code, in place, in either file. If I grow some code in the source file, I can put (defn some-name [args]) in front of it and M-) slurps it into a function - done! If I grow some code in the test file, I can put (expect result-value) in front of it and M-) slurps it into a test - done! Could you clarify the difference between LightTable's M-) and using C-M-x* in Emacs jacked into an nrepl session with Cider? * `eval-defun` or whatever cider replaces that with for clojure. -- 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.
Confused by Clojure floating-point differences (compared to other languages)
(sorry if you received an earlier mail from me that was half-formed, I hit
send by accident)
Hi there, I'm quite new to Clojure, and was trying to do some very simple
benchmarking with other languages. I was surprised by the floating-point
results I got, which differed (for the same calculation, using doubles)
compared to the other languages I tried (including C++, SuperCollider, Lua,
Python).
My benchmark iteratively runs a function 100M times: g(x) -- sin(2.3x) +
cos(3.7x), starting with x of 0.
In the other languages, I always got the result *0.0541718*..., but in
Clojure I get *0.24788989* I realize this is a contrived case, but --
doing an identical sequence of 64-bit floating-point operations on the same
machine should give the same answer. Note that if you only run the
function for about ~110 iterations, you get the same answer in Clojure (or
very close), but then it diverges.
I assume my confusion is due to my ignorance of Clojure and/or Java's math
library. I don't think I'm using 32-bit floats or the BigDecimal type (I
even explicitly converted to double, but got the same results, and if I
evaluate the *type* it tells me *java.lang.Double*, which seems right).
Maybe Clojure's answer is better, but I do find it strange that it's
different. Can someone explain this to me?
Here are some results:
*Clojure: ~23 seconds*
(defn g [x] (+ (Math/sin (* 2.3 x)) (Math/cos (* 3.7 x
(loop [i 1 x 0] (if (pos? i) (recur (dec i) (g x)) x))
;; final x: *0.24788989279493556 (???)*
*C++ (g++ -O2): ~4 seconds*
double g(double x) {
return std::sin(2.3*x) + std::cos(3.7*x);
}
int main() {
double x = 0;
for (int i = 0; i 1; ++i) {
x = g(x);
}
std::cout final x: x std::endl;
return 0;
}
// final x: *0.0541718*
*Lua: ~39 seconds*
g = function(x)
return math.sin(2.3*x) + math.cos(3.7*x)
end
x = 0; for i = 1, 1 do x = g(x) end
-- Final x: *0.054171801051906*
*Python: ~72 seconds*
def g(x):
return math.sin(2.3*x) + math.cos(3.7*x)
x = 0
for i in xrange(1):
x = g(x)
# Final x: *0.05417180105190572*
*SClang: ~26 seconds*
g = { |x| sin(2.3*x) + cos(3.7*x) };
f = { |x| 1.do{ x = g.(x) }; x};
bench{ f.(0).postln };
// final x: *0.054171801051906* (same as C++, Lua, Python; different from
Clojure)
Thanks,
Glen.
--
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: Confused by Clojure floating-point differences (compared to other languages)
IIRC, Java provides unusual trigonometric functions which, I’m guessing,
Clojure is using. I think the Java ones are actually more accurate (and slower)
so you may well find the answer obtained on the JVM is more precise than the
others.
Cheers,
Jon.
From: clojure@googlegroups.com [mailto:clojure@googlegroups.com] On Behalf Of
Glen Fraser
Sent: 05 February 2014 13:17
To: clojure@googlegroups.com
Subject: Confused by Clojure floating-point differences (compared to other
languages)
(sorry if you received an earlier mail from me that was half-formed, I hit send
by accident)
Hi there, I'm quite new to Clojure, and was trying to do some very simple
benchmarking with other languages. I was surprised by the floating-point
results I got, which differed (for the same calculation, using doubles)
compared to the other languages I tried (including C++, SuperCollider, Lua,
Python).
My benchmark iteratively runs a function 100M times: g(x) -- sin(2.3x) +
cos(3.7x), starting with x of 0.
In the other languages, I always got the result 0.0541718..., but in Clojure I
get 0.24788989 I realize this is a contrived case, but -- doing an
identical sequence of 64-bit floating-point operations on the same machine
should give the same answer. Note that if you only run the function for about
~110 iterations, you get the same answer in Clojure (or very close), but then
it diverges.
I assume my confusion is due to my ignorance of Clojure and/or Java's math
library. I don't think I'm using 32-bit floats or the BigDecimal type (I
even explicitly converted to double, but got the same results, and if I
evaluate the type it tells me java.lang.Double, which seems right). Maybe
Clojure's answer is better, but I do find it strange that it's different.
Can someone explain this to me?
Here are some results:
Clojure: ~23 seconds
(defn g [x] (+ (Math/sin (* 2.3 x)) (Math/cos (* 3.7 x
(loop [i 1 x 0] (if (pos? i) (recur (dec i) (g x)) x))
;; final x: 0.24788989279493556 (???)
C++ (g++ -O2): ~4 seconds
double g(double x) {
return std::sin(2.3*x) + std::cos(3.7*x);
}
int main() {
double x = 0;
for (int i = 0; i 1; ++i) {
x = g(x);
}
std::cout final x: x std::endl;
return 0;
}
// final x: 0.0541718
Lua: ~39 seconds
g = function(x)
return math.sin(2.3*x) + math.cos(3.7*x)
end
x = 0; for i = 1, 1 do x = g(x) end
-- Final x: 0.054171801051906
Python: ~72 seconds
def g(x):
return math.sin(2.3*x) + math.cos(3.7*x)
x = 0
for i in xrange(1):
x = g(x)
# Final x: 0.05417180105190572
SClang: ~26 seconds
g = { |x| sin(2.3*x) + cos(3.7*x) };
f = { |x| 1.do{ x = g.(x) }; x};
bench{ f.(0).postln };
// final x: 0.054171801051906 (same as C++, Lua, Python; different from Clojure)
Thanks,
Glen.
--
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: Confused by Clojure floating-point differences (compared to other languages)
Thanks for the tip. After reading your comment, I looked and discovered
the Java library called StrictMath, and tried it (replacing Math/cos and
Math/sin by the StrictMath versions). I did indeed get different results
than with the regular library, but unfortunately still not the same answer
as in other languages. I guess the Java implementation(s) are indeed
different. It's not a big deal for me, just something I found confusing,
wondering if I'd done something wrong.
Thanks,
Glen.
On Wednesday, February 5, 2014 4:06:31 PM UTC+1, Jon Harrop wrote:
IIRC, Java provides unusual trigonometric functions which, I’m guessing,
Clojure is using. I think the Java ones are actually more accurate (and
slower) so you may well find the answer obtained on the JVM is more precise
than the others.
Cheers,
Jon.
*From:* clo...@googlegroups.com javascript: [mailto:
clo...@googlegroups.com javascript:] *On Behalf Of *Glen Fraser
*Sent:* 05 February 2014 13:17
*To:* clo...@googlegroups.com javascript:
*Subject:* Confused by Clojure floating-point differences (compared to
other languages)
(sorry if you received an earlier mail from me that was half-formed, I hit
send by accident)
Hi there, I'm quite new to Clojure, and was trying to do some very simple
benchmarking with other languages. I was surprised by the floating-point
results I got, which differed (for the same calculation, using doubles)
compared to the other languages I tried (including C++, SuperCollider, Lua,
Python).
My benchmark iteratively runs a function 100M times: g(x) -- sin(2.3x) +
cos(3.7x), starting with x of 0.
In the other languages, I always got the result *0.0541718*..., but in
Clojure I get *0.24788989* I realize this is a contrived case, but
-- doing an identical sequence of 64-bit floating-point operations on the
same machine should give the same answer. Note that if you only run the
function for about ~110 iterations, you get the same answer in Clojure (or
very close), but then it diverges.
I assume my confusion is due to my ignorance of Clojure and/or Java's math
library. I don't think I'm using 32-bit floats or the BigDecimal type (I
even explicitly converted to double, but got the same results, and if I
evaluate the *type* it tells me *java.lang.Double*, which seems right).
Maybe Clojure's answer is better, but I do find it strange that it's
different. Can someone explain this to me?
Here are some results:
*Clojure: ~23 seconds*
(defn g [x] (+ (Math/sin (* 2.3 x)) (Math/cos (* 3.7 x
(loop [i 1 x 0] (if (pos? i) (recur (dec i) (g x)) x))
;; final x: *0.24788989279493556 **(???)*
*C++ (g++ -O2): ~4 seconds*
double g(double x) {
return std::sin(2.3*x) + std::cos(3.7*x);
}
int main() {
double x = 0;
for (int i = 0; i 1; ++i) {
x = g(x);
}
std::cout final x: x std::endl;
return 0;
}
// final x: *0.0541718*
*Lua: ~39 seconds*
g = function(x)
return math.sin(2.3*x) + math.cos(3.7*x)
end
x = 0; for i = 1, 1 do x = g(x) end
-- Final x: *0.054171801051906*
*Python: ~72 seconds*
def g(x):
return math.sin(2.3*x) + math.cos(3.7*x)
x = 0
for i in xrange(1):
x = g(x)
# Final x: *0.05417180105190572*
*SClang: ~26 seconds*
g = { |x| sin(2.3*x) + cos(3.7*x) };
f = { |x| 1.do{ x = g.(x) }; x};
bench{ f.(0).postln };
// final x: *0.054171801051906* (same as C++, Lua, Python; different from
Clojure)
Thanks,
Glen.
--
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 javascript:
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
Re: Confused by Clojure floating-point differences (compared to other languages)
--On 5 Feb 2014 05:17:13 -0800 Glen Fraser holag...@gmail.com wrote: My benchmark iteratively runs a function 100M times: g(x) -- sin(2.3x) + cos(3.7x), starting with x of 0. A quick look at the series you are computing suggests that it has chaotic behavior. Another quick looks shows that neither of the two values that you see after 100M iterations is a fix point. I'd need to do a careful numerical analysis to be sure, but I suspect that you are computing a close to random number: any numerical error at some stage is amplified in the further computation. If you get identical results from different languages, this suggests that they all end up using the same numerical code (probably the C math library). I suggest you try your Python code under Jython, perhaps that will reproduce the Clojure result by also relying on the JVM standard library. In the other languages, I always got the result 0.0541718..., but in Clojure I get 0.24788989 I realize this is a contrived case, but -- doing an identical sequence of 64-bit floating-point operations on the same machine should give the same answer. Unfortunately not. Your reasoning would be true if everyone adopted IEEE float operations, but in practice nobody does because the main objective is speed, not predictability. The Intel hardware is close to IEEE, but not fully compatible, and it offers some parameters that libraries can play with to get different results from the same operations. Konrad. -- 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: Confused by Clojure floating-point differences (compared to other languages)
Thanks, this is a satisfying answer. You're probably right that the other languages are all using the C standard math library (I naïvely assumed Java would too, but I see that's not the case). And yes, as I said, it is a rather contrived (and chaotic) example. Glen. On Feb 5, 2014, at 6:22 PM, Konrad Hinsen googlegro...@khinsen.fastmail.net wrote: --On 5 Feb 2014 05:17:13 -0800 Glen Fraser holag...@gmail.com wrote: My benchmark iteratively runs a function 100M times: g(x) -- sin(2.3x) + cos(3.7x), starting with x of 0. A quick look at the series you are computing suggests that it has chaotic behavior. Another quick looks shows that neither of the two values that you see after 100M iterations is a fix point. I'd need to do a careful numerical analysis to be sure, but I suspect that you are computing a close to random number: any numerical error at some stage is amplified in the further computation. If you get identical results from different languages, this suggests that they all end up using the same numerical code (probably the C math library). I suggest you try your Python code under Jython, perhaps that will reproduce the Clojure result by also relying on the JVM standard library. In the other languages, I always got the result 0.0541718..., but in Clojure I get 0.24788989 I realize this is a contrived case, but -- doing an identical sequence of 64-bit floating-point operations on the same machine should give the same answer. Unfortunately not. Your reasoning would be true if everyone adopted IEEE float operations, but in practice nobody does because the main objective is speed, not predictability. The Intel hardware is close to IEEE, but not fully compatible, and it offers some parameters that libraries can play with to get different results from the same operations. Konrad. -- 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.
JIRA and ticket votes
Hello, as we approach the end game for Clojure 1.6 and start looking forward to the next release, now is a good time to look at the existing ticket backlog and vote on things that are important to you. Andy's weighted ticket vote report is a good place to start - it includes all tickets currently in work or with any votes: http://jafingerhut.github.io/clj-ticket-status/CLJ-top-tickets-by-weighted-vote.html If you want to trawl the list of all open tickets, look here: http://dev.clojure.org/jira/secure/IssueNavigator.jspa?mode=hiderequestId=10371 Note that Andy's report splits each person's impact across the number of votes they make (so making more votes dilutes the value of each). In addition to the weighted report, I also look at reports sorted by the total number of (unweighted) votes. 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: Confused by Clojure floating-point differences (compared to other languages)
Ah, I see now that you are doing (g x) in your loop, not (g i), so scratch what I said about the loop running the wrong direction. On Wed, Feb 5, 2014 at 9:23 AM, Mark Engelberg mark.engelb...@gmail.comwrote: Looks to me like your Clojure loop runs in the opposite direction (counting downwards) versus the other languages. Since your code only returns the result of the last iteration of the loop, it's not too surprising that they return completely different results -- the last iteration of the Clojure code is a completely different input than in the other languages. -- 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.
GSoC 2014: We need ideas and mentors
Hello, all, It's time once again to prepare our application for Google Summer of Code, a program where Google pays students from around the world to work on open source projects. Clojure has successfully participated in the program for two years now, and I would love to make it a third. GSoC has helped projects like Typed Clojure, Clojure in Clojure, Clojure on Android, core.matrix, and ClojureScript. In order to have a strong application, we need you to help populate our project ideas page [1]. You can also review the ideas for 2012 [2] and 2013 [3] to help you come up with new ideas. Having a great ideas page is key to a successful application, and having many members from the community participate as potential mentors will be a big boost. At this point, you are not committing to anything—we just need your ideas. If you don't have edit rights to the wiki and don't want to sign up for an account, just post to the mailing list using '[GSoC Idea]' in the subject line, and I'll add it for you. Lastly, if you would like to review the answers to the organization application [4], I would appreciate the input. The application deadline the 14th of February. Thank you for time and ideas. Sincerely, Daniel [1]: http://dev.clojure.org/display/community/Project+Ideas [2]: http://dev.clojure.org/display/community/Google+Summer+of+Code+2012 [3]: http://dev.clojure.org/display/community/Project+Ideas+2013 [4]: http://dev.clojure.org/display/community/Mentoring+Organization+Application -- 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: Confused by Clojure floating-point differences (compared to other languages)
Looks to me like your Clojure loop runs in the opposite direction (counting
downwards) versus the other languages. Since your code only returns the
result of the last iteration of the loop, it's not too surprising that they
return completely different results -- the last iteration of the Clojure
code is a completely different input than in the other languages.
On Wed, Feb 5, 2014 at 5:17 AM, Glen Fraser holag...@gmail.com wrote:
(sorry if you received an earlier mail from me that was half-formed, I hit
send by accident)
Hi there, I'm quite new to Clojure, and was trying to do some very simple
benchmarking with other languages. I was surprised by the floating-point
results I got, which differed (for the same calculation, using doubles)
compared to the other languages I tried (including C++, SuperCollider, Lua,
Python).
My benchmark iteratively runs a function 100M times: g(x) -- sin(2.3x) +
cos(3.7x), starting with x of 0.
In the other languages, I always got the result *0.0541718*..., but in
Clojure I get *0.24788989* I realize this is a contrived case, but
-- doing an identical sequence of 64-bit floating-point operations on the
same machine should give the same answer. Note that if you only run the
function for about ~110 iterations, you get the same answer in Clojure (or
very close), but then it diverges.
I assume my confusion is due to my ignorance of Clojure and/or Java's math
library. I don't think I'm using 32-bit floats or the BigDecimal type (I
even explicitly converted to double, but got the same results, and if I
evaluate the *type* it tells me *java.lang.Double*, which seems right).
Maybe Clojure's answer is better, but I do find it strange that it's
different. Can someone explain this to me?
Here are some results:
*Clojure: ~23 seconds*
(defn g [x] (+ (Math/sin (* 2.3 x)) (Math/cos (* 3.7 x
(loop [i 1 x 0] (if (pos? i) (recur (dec i) (g x)) x))
;; final x: *0.24788989279493556 (???)*
*C++ (g++ -O2): ~4 seconds*
double g(double x) {
return std::sin(2.3*x) + std::cos(3.7*x);
}
int main() {
double x = 0;
for (int i = 0; i 1; ++i) {
x = g(x);
}
std::cout final x: x std::endl;
return 0;
}
// final x: *0.0541718*
*Lua: ~39 seconds*
g = function(x)
return math.sin(2.3*x) + math.cos(3.7*x)
end
x = 0; for i = 1, 1 do x = g(x) end
-- Final x: *0.054171801051906*
*Python: ~72 seconds*
def g(x):
return math.sin(2.3*x) + math.cos(3.7*x)
x = 0
for i in xrange(1):
x = g(x)
# Final x: *0.05417180105190572*
*SClang: ~26 seconds*
g = { |x| sin(2.3*x) + cos(3.7*x) };
f = { |x| 1.do{ x = g.(x) }; x};
bench{ f.(0).postln };
// final x: *0.054171801051906* (same as C++, Lua, Python; different from
Clojure)
Thanks,
Glen.
--
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: Confused by Clojure floating-point differences (compared to other languages)
I'd agree here. This is actually a very nice example of a system that might be called chaotic, though chaos is, even mathematically, a very vague term: 1) the iteration will never leave [-2, 2] 2) it won't converge because all 3 fixed points are unstable ( |f'(x_s)|1 ) So, your example is really not calculating any particular number. Now you could consider it as a calculation of the series itself. The question is that of repeatability. This is not something that can be answered by looking at hardware only. Even if you are running with the same primitive operations, the results could be different. Floating point representation violated distributivity and associativity laws of real numbers. Thus, the error of a certain computation, even if algebraically equivalent, depends on the ordering of operations (if you ever come close to the accuracy limits ~1e-7 for floats and ~1e-15 for doubles, or something like that). Since different compilers will order computation differently, you cannot really expect to match a diverging series ... Standard texts are: http://www.amazon.com/Nonlinear-Dynamics-And-Chaos-Applications/dp/0738204536 http://www.amazon.com/Accuracy-Stability-Numerical-Algorithms-Nicholas/dp/0898715210 ranko On Wednesday, February 5, 2014 12:22:54 PM UTC-5, Konrad Hinsen wrote: --On 5 Feb 2014 05:17:13 -0800 Glen Fraser hola...@gmail.comjavascript: wrote: My benchmark iteratively runs a function 100M times: g(x) -- sin(2.3x) + cos(3.7x), starting with x of 0. A quick look at the series you are computing suggests that it has chaotic behavior. Another quick looks shows that neither of the two values that you see after 100M iterations is a fix point. I'd need to do a careful numerical analysis to be sure, but I suspect that you are computing a close to random number: any numerical error at some stage is amplified in the further computation. If you get identical results from different languages, this suggests that they all end up using the same numerical code (probably the C math library). I suggest you try your Python code under Jython, perhaps that will reproduce the Clojure result by also relying on the JVM standard library. In the other languages, I always got the result 0.0541718..., but in Clojure I get 0.24788989 I realize this is a contrived case, but -- doing an identical sequence of 64-bit floating-point operations on the same machine should give the same answer. Unfortunately not. Your reasoning would be true if everyone adopted IEEE float operations, but in practice nobody does because the main objective is speed, not predictability. The Intel hardware is close to IEEE, but not fully compatible, and it offers some parameters that libraries can play with to get different results from the same operations. Konrad. -- 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: Confused by Clojure floating-point differences (compared to other languages)
Others have answered with many useful bits but I would mention that it
would possibly make a significant performance difference if you added this
to your code:
(set! *unchecked-math* true)
On Wednesday, February 5, 2014 7:17:13 AM UTC-6, Glen Fraser wrote:
(sorry if you received an earlier mail from me that was half-formed, I hit
send by accident)
Hi there, I'm quite new to Clojure, and was trying to do some very simple
benchmarking with other languages. I was surprised by the floating-point
results I got, which differed (for the same calculation, using doubles)
compared to the other languages I tried (including C++, SuperCollider, Lua,
Python).
My benchmark iteratively runs a function 100M times: g(x) -- sin(2.3x) +
cos(3.7x), starting with x of 0.
In the other languages, I always got the result *0.0541718*..., but in
Clojure I get *0.24788989* I realize this is a contrived case, but
-- doing an identical sequence of 64-bit floating-point operations on the
same machine should give the same answer. Note that if you only run the
function for about ~110 iterations, you get the same answer in Clojure (or
very close), but then it diverges.
I assume my confusion is due to my ignorance of Clojure and/or Java's math
library. I don't think I'm using 32-bit floats or the BigDecimal type (I
even explicitly converted to double, but got the same results, and if I
evaluate the *type* it tells me *java.lang.Double*, which seems right).
Maybe Clojure's answer is better, but I do find it strange that it's
different. Can someone explain this to me?
Here are some results:
*Clojure: ~23 seconds*
(defn g [x] (+ (Math/sin (* 2.3 x)) (Math/cos (* 3.7 x
(loop [i 1 x 0] (if (pos? i) (recur (dec i) (g x)) x))
;; final x: *0.24788989279493556 (???)*
*C++ (g++ -O2): ~4 seconds*
double g(double x) {
return std::sin(2.3*x) + std::cos(3.7*x);
}
int main() {
double x = 0;
for (int i = 0; i 1; ++i) {
x = g(x);
}
std::cout final x: x std::endl;
return 0;
}
// final x: *0.0541718*
*Lua: ~39 seconds*
g = function(x)
return math.sin(2.3*x) + math.cos(3.7*x)
end
x = 0; for i = 1, 1 do x = g(x) end
-- Final x: *0.054171801051906*
*Python: ~72 seconds*
def g(x):
return math.sin(2.3*x) + math.cos(3.7*x)
x = 0
for i in xrange(1):
x = g(x)
# Final x: *0.05417180105190572*
*SClang: ~26 seconds*
g = { |x| sin(2.3*x) + cos(3.7*x) };
f = { |x| 1.do{ x = g.(x) }; x};
bench{ f.(0).postln };
// final x: *0.054171801051906* (same as C++, Lua, Python; different from
Clojure)
Thanks,
Glen.
--
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: Confused by Clojure floating-point differences (compared to other languages)
Also:
(defn g ^double [^double x] (+ (Math/sin (* 2.3 x)) (Math/cos (* 3.7 x
On Wed, Feb 5, 2014 at 2:07 PM, Alex Miller a...@puredanger.com wrote:
Others have answered with many useful bits but I would mention that it
would possibly make a significant performance difference if you added this
to your code:
(set! *unchecked-math* true)
On Wednesday, February 5, 2014 7:17:13 AM UTC-6, Glen Fraser wrote:
(sorry if you received an earlier mail from me that was half-formed, I
hit send by accident)
Hi there, I'm quite new to Clojure, and was trying to do some very simple
benchmarking with other languages. I was surprised by the floating-point
results I got, which differed (for the same calculation, using doubles)
compared to the other languages I tried (including C++, SuperCollider, Lua,
Python).
My benchmark iteratively runs a function 100M times: g(x) -- sin(2.3x) +
cos(3.7x), starting with x of 0.
In the other languages, I always got the result *0.0541718*..., but in
Clojure I get *0.24788989* I realize this is a contrived case, but
-- doing an identical sequence of 64-bit floating-point operations on the
same machine should give the same answer. Note that if you only run the
function for about ~110 iterations, you get the same answer in Clojure (or
very close), but then it diverges.
I assume my confusion is due to my ignorance of Clojure and/or Java's
math library. I don't think I'm using 32-bit floats or the BigDecimal
type (I even explicitly converted to double, but got the same results, and
if I evaluate the *type* it tells me *java.lang.Double*, which seems
right). Maybe Clojure's answer is better, but I do find it strange that
it's different. Can someone explain this to me?
Here are some results:
*Clojure: ~23 seconds*
(defn g [x] (+ (Math/sin (* 2.3 x)) (Math/cos (* 3.7 x
(loop [i 1 x 0] (if (pos? i) (recur (dec i) (g x)) x))
;; final x: *0.24788989279493556 (???)*
*C++ (g++ -O2): ~4 seconds*
double g(double x) {
return std::sin(2.3*x) + std::cos(3.7*x);
}
int main() {
double x = 0;
for (int i = 0; i 1; ++i) {
x = g(x);
}
std::cout final x: x std::endl;
return 0;
}
// final x: *0.0541718*
*Lua: ~39 seconds*
g = function(x)
return math.sin(2.3*x) + math.cos(3.7*x)
end
x = 0; for i = 1, 1 do x = g(x) end
-- Final x: *0.054171801051906*
*Python: ~72 seconds*
def g(x):
return math.sin(2.3*x) + math.cos(3.7*x)
x = 0
for i in xrange(1):
x = g(x)
# Final x: *0.05417180105190572*
*SClang: ~26 seconds*
g = { |x| sin(2.3*x) + cos(3.7*x) };
f = { |x| 1.do{ x = g.(x) }; x};
bench{ f.(0).postln };
// final x: *0.054171801051906* (same as C++, Lua, Python; different
from Clojure)
Thanks,
Glen.
--
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: Lessons Learned from Adopting Clojure
On Feb 5, 2014, at 5:39 AM, John D. Hume duelin.mark...@gmail.com wrote: Could you clarify the difference between LightTable's M-) and using C-M-x* in Emacs jacked into an nrepl session with Cider? M-) is paredit-forward-slurp-sexp in both LightTable and Emacs. The key difference here is that LightTable can eval-in-place live inside a file without you needing to do anything but type code. You don't need to send expressions to a REPL and the results are displayed inline, right next to the expression, rather than in a separate REPL window or the minibuffer. Essentially you get the benefit of the REPL and fast feedback without needing a separate REPL buffer. Sean Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ Perfection is the enemy of the good. -- Gustave Flaubert, French realist novelist (1821-1880) signature.asc Description: Message signed with OpenPGP using GPGMail
diagram of clojure interfaces and objects
Hi, Does anyone know of a class diagram of all the java interfaces and classes that exist in clojure, including their inheritance relationships. Im trying to get a handle on all the many collection/sequence interfaces, but ideally I would like to visually grok the whole fundamental clojure object model on one sheet. I suppose I can derive this from the source if not of course... Andy -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: diagram of clojure interfaces and objects
On Wed Feb 5 13:16:01 2014, Andy Smith wrote: Hi, Does anyone know of a class diagram of all the java interfaces and classes that exist in clojure, including their inheritance relationships. Im trying to get a handle on all the many collection/sequence interfaces, but ideally I would like to visually grok the whole fundamental clojure object model on one sheet. I suppose I can derive this from the source if not of course... Andy -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. This tool by Stuart Sierra is helpful for these types of explorations and the README actually has an example showing some of what you are asking about: https://github.com/stuartsierra/class-diagram -- 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: Lessons Learned from Adopting Clojure
As a TDD practitioner and Expectationshttps://github.com/jaycfields/expectationsuser, I've been following this thread with great interest! @Jay: Will your change in thinking have any impact on Expectations? My experience with TDD in Clojure has been an overwhelmingly positive one, and it seems like this thread might be a good place to discuss the subject with others. RDD is an invaluable tool for evolving the shape of your functions, and it's a killer feature for REPL-based languages like Clojure. However, I mainly use RDD in the refactoring stage of TDD, and I still choose the overhead of writing tests before coding my solutions. Why do I do that? Well, I experience a number of benefits from TDD: - A very clear separation of thinking between requirements and solution - A constant focus on delivering the Minimum Viable Product - Documentation, in English, of the expected behaviour of a function - Documentation, in code, of example inputs and expected outputs of a function (especially useful in a dynamic language like Clojure) - A continual reminder (and perfect opportunity) to refactor - A refactoring confidence boost (i.e. if all my tests are still green, then I can be pretty confident in that refactor) - The little bit of serotonin released in your brain when you make the next test turn green :-) - Finishing a session with a red test gives you a great starting point for your next session and often helps you to get straight back into the zone - A clear handover point if you're pair-programming It's clear that developers who don't use TDD can (and do) develop extremely high quality solutions. However, for me personally, the list of benefits from doing TDD outweigh the cost of writing and maintaining the tests. I am a better programmer when I use TDD. I prefer jumping into other people's codebases when they have used TDD. I find it easier to get back into one of my own old projects when I've used TDD. I also understand that most other programmers don't agree with me on this, which might mean that I'm wrong. :-) Cheers, James On Tuesday, February 4, 2014 1:06:06 PM UTC+1, Jay Fields wrote: tl; dr: I'm presenting Lessons Learned from Adopting Clojure in Chicago on Feb 11th: http://www.eventbrite.com/e/goto-night-with-jay-fields-tickets-10366768283?aff=eorgf Five years ago DRW Trading was primarily a Java shop, and I was primarily developing in Ruby. Needless to say, it wasn't a match made in heaven. Fast forward five years, Clojure is the second most used language in the firm, and the primary language for several teams (including mine). Clojure wasn't the first language that I've introduced to an organization; however, it's unquestionably the most successful adoption I've ever been a part of. The use of Clojure has had many impacts on the firm: culturally, politically, and technically. My talk will discuss general ideas around language selection and maintenance trade-offs, and specific examples of what aspects of Clojure made it the correct choice for us. A few highlights - Where to first introduce a new language and your role as the language care-taker. - REPL driven development, putting TDD's 'rapid feedback' to shame. - Operations impact of adding a language - i.e. get ready for some DevOps. - Functional programming, the Lisp Advantage, and their impact on maintainability. Of course, no good experience report is all roses. The adoption has seen several hurdles along the way, and I'll happily to describe those as well. -- 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: Confused by Clojure floating-point differences (compared to other languages)
Thanks to both of you for these suggestions, they're good to know. In my
specific case, setting the *unchecked-math* flag true did indeed speed things
up slightly (by about 6%). The other change, though, with the double type
hints (I assume that's what those are), actually ran notably slower (over 20%
slower!).
Glen.
On Feb 5, 2014, at 8:13 PM, David Nolen dnolen.li...@gmail.com wrote:
Also:
(defn g ^double [^double x] (+ (Math/sin (* 2.3 x)) (Math/cos (* 3.7 x
On Wed, Feb 5, 2014 at 2:07 PM, Alex Miller a...@puredanger.com wrote:
Others have answered with many useful bits but I would mention that it would
possibly make a significant performance difference if you added this to your
code:
(set! *unchecked-math* true)
On Wednesday, February 5, 2014 7:17:13 AM UTC-6, Glen Fraser wrote:
(sorry if you received an earlier mail from me that was half-formed, I hit
send by accident)
Hi there, I'm quite new to Clojure, and was trying to do some very simple
benchmarking with other languages. I was surprised by the floating-point
results I got, which differed (for the same calculation, using doubles)
compared to the other languages I tried (including C++, SuperCollider, Lua,
Python).
My benchmark iteratively runs a function 100M times: g(x) -- sin(2.3x) +
cos(3.7x), starting with x of 0.
In the other languages, I always got the result 0.0541718..., but in Clojure
I get 0.24788989 I realize this is a contrived case, but -- doing an
identical sequence of 64-bit floating-point operations on the same machine
should give the same answer. Note that if you only run the function for
about ~110 iterations, you get the same answer in Clojure (or very close),
but then it diverges.
I assume my confusion is due to my ignorance of Clojure and/or Java's math
library. I don't think I'm using 32-bit floats or the BigDecimal type (I
even explicitly converted to double, but got the same results, and if I
evaluate the type it tells me java.lang.Double, which seems right). Maybe
Clojure's answer is better, but I do find it strange that it's different.
Can someone explain this to me?
Here are some results:
Clojure: ~23 seconds
(defn g [x] (+ (Math/sin (* 2.3 x)) (Math/cos (* 3.7 x
(loop [i 1 x 0] (if (pos? i) (recur (dec i) (g x)) x))
;; final x: 0.24788989279493556 (???)
C++ (g++ -O2): ~4 seconds
double g(double x) {
return std::sin(2.3*x) + std::cos(3.7*x);
}
int main() {
double x = 0;
for (int i = 0; i 1; ++i) {
x = g(x);
}
std::cout final x: x std::endl;
return 0;
}
// final x: 0.0541718
Lua: ~39 seconds
g = function(x)
return math.sin(2.3*x) + math.cos(3.7*x)
end
x = 0; for i = 1, 1 do x = g(x) end
-- Final x: 0.054171801051906
Python: ~72 seconds
def g(x):
return math.sin(2.3*x) + math.cos(3.7*x)
x = 0
for i in xrange(1):
x = g(x)
# Final x: 0.05417180105190572
SClang: ~26 seconds
g = { |x| sin(2.3*x) + cos(3.7*x) };
f = { |x| 1.do{ x = g.(x) }; x};
bench{ f.(0).postln };
// final x: 0.054171801051906 (same as C++, Lua, Python; different from
Clojure)
Thanks,
Glen.
--
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/kFNxGrRPf2k/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 -
Re: Lessons Learned from Adopting Clojure
+100 My English is bad, but you expressed my position about TDD in general (I'm not a clojurian, yet, but I really appreciate TDD workflow in other technologies). On Wed, Feb 5, 2014 at 6:35 PM, James Trunk james.tr...@gmail.com wrote: As a TDD practitioner and Expectationshttps://github.com/jaycfields/expectationsuser, I've been following this thread with great interest! @Jay: Will your change in thinking have any impact on Expectations? My experience with TDD in Clojure has been an overwhelmingly positive one, and it seems like this thread might be a good place to discuss the subject with others. RDD is an invaluable tool for evolving the shape of your functions, and it's a killer feature for REPL-based languages like Clojure. However, I mainly use RDD in the refactoring stage of TDD, and I still choose the overhead of writing tests before coding my solutions. Why do I do that? Well, I experience a number of benefits from TDD: - A very clear separation of thinking between requirements and solution - A constant focus on delivering the Minimum Viable Product - Documentation, in English, of the expected behaviour of a function - Documentation, in code, of example inputs and expected outputs of a function (especially useful in a dynamic language like Clojure) - A continual reminder (and perfect opportunity) to refactor - A refactoring confidence boost (i.e. if all my tests are still green, then I can be pretty confident in that refactor) - The little bit of serotonin released in your brain when you make the next test turn green :-) - Finishing a session with a red test gives you a great starting point for your next session and often helps you to get straight back into the zone - A clear handover point if you're pair-programming It's clear that developers who don't use TDD can (and do) develop extremely high quality solutions. However, for me personally, the list of benefits from doing TDD outweigh the cost of writing and maintaining the tests. I am a better programmer when I use TDD. I prefer jumping into other people's codebases when they have used TDD. I find it easier to get back into one of my own old projects when I've used TDD. I also understand that most other programmers don't agree with me on this, which might mean that I'm wrong. :-) Cheers, James On Tuesday, February 4, 2014 1:06:06 PM UTC+1, Jay Fields wrote: tl; dr: I'm presenting Lessons Learned from Adopting Clojure in Chicago on Feb 11th: http://www.eventbrite.com/e/goto-night-with-jay-fields- tickets-10366768283?aff=eorgf Five years ago DRW Trading was primarily a Java shop, and I was primarily developing in Ruby. Needless to say, it wasn't a match made in heaven. Fast forward five years, Clojure is the second most used language in the firm, and the primary language for several teams (including mine). Clojure wasn't the first language that I've introduced to an organization; however, it's unquestionably the most successful adoption I've ever been a part of. The use of Clojure has had many impacts on the firm: culturally, politically, and technically. My talk will discuss general ideas around language selection and maintenance trade-offs, and specific examples of what aspects of Clojure made it the correct choice for us. A few highlights - Where to first introduce a new language and your role as the language care-taker. - REPL driven development, putting TDD's 'rapid feedback' to shame. - Operations impact of adding a language - i.e. get ready for some DevOps. - Functional programming, the Lisp Advantage, and their impact on maintainability. Of course, no good experience report is all roses. The adoption has seen several hurdles along the way, and I'll happily to describe those as well. -- 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
Re: Confused by Clojure floating-point differences (compared to other languages)
(set! *unchecked-math* true)
(defn g ^double [^double x] (+ (Math/sin (* 2.3 x)) (Math/cos (* 3.7 x
(time (loop [i 1 x 0.0] (if (pos? i) (recur (dec i) (g x)) x)))
This is nearly 50% faster than the original version on my machine. Note
that x is bound to 0.0 in the loop, which allows the optimized g to be
invoked.
On Wed, Feb 5, 2014 at 4:41 PM, Glen Fraser holag...@gmail.com wrote:
Thanks to both of you for these suggestions, they're good to know. In my
specific case, setting the *unchecked-math* flag true did indeed speed
things up slightly (by about 6%). The other change, though, with the
double type hints (I assume that's what those are), actually ran notably
slower (over 20% slower!).
Glen.
On Feb 5, 2014, at 8:13 PM, David Nolen dnolen.li...@gmail.com wrote:
Also:
(defn g ^double [^double x] (+ (Math/sin (* 2.3 x)) (Math/cos (* 3.7 x
On Wed, Feb 5, 2014 at 2:07 PM, Alex Miller a...@puredanger.com wrote:
Others have answered with many useful bits but I would mention that it
would possibly make a significant performance difference if you added this
to your code:
(set! *unchecked-math* true)
On Wednesday, February 5, 2014 7:17:13 AM UTC-6, Glen Fraser wrote:
(sorry if you received an earlier mail from me that was half-formed, I
hit send by accident)
Hi there, I'm quite new to Clojure, and was trying to do some very
simple benchmarking with other languages. I was surprised by the
floating-point results I got, which differed (for the same calculation,
using doubles) compared to the other languages I tried (including C++,
SuperCollider, Lua, Python).
My benchmark iteratively runs a function 100M times: g(x) -- sin(2.3x)
+ cos(3.7x), starting with x of 0.
In the other languages, I always got the result *0.0541718*..., but in
Clojure I get *0.24788989* I realize this is a contrived case, but
-- doing an identical sequence of 64-bit floating-point operations on the
same machine should give the same answer. Note that if you only run the
function for about ~110 iterations, you get the same answer in Clojure (or
very close), but then it diverges.
I assume my confusion is due to my ignorance of Clojure and/or Java's
math library. I don't think I'm using 32-bit floats or the BigDecimal
type (I even explicitly converted to double, but got the same results, and
if I evaluate the *type* it tells me *java.lang.Double*, which seems
right). Maybe Clojure's answer is better, but I do find it strange that
it's different. Can someone explain this to me?
Here are some results:
*Clojure: ~23 seconds*
(defn g [x] (+ (Math/sin (* 2.3 x)) (Math/cos (* 3.7 x
(loop [i 1 x 0] (if (pos? i) (recur (dec i) (g x)) x))
;; final x: *0.24788989279493556 (???)*
*C++ (g++ -O2): ~4 seconds*
double g(double x) {
return std::sin(2.3*x) + std::cos(3.7*x);
}
int main() {
double x = 0;
for (int i = 0; i 1; ++i) {
x = g(x);
}
std::cout final x: x std::endl;
return 0;
}
// final x: *0.0541718*
*Lua: ~39 seconds*
g = function(x)
return math.sin(2.3*x) + math.cos(3.7*x)
end
x = 0; for i = 1, 1 do x = g(x) end
-- Final x: *0.054171801051906*
*Python: ~72 seconds*
def g(x):
return math.sin(2.3*x) + math.cos(3.7*x)
x = 0
for i in xrange(1):
x = g(x)
# Final x: *0.05417180105190572*
*SClang: ~26 seconds*
g = { |x| sin(2.3*x) + cos(3.7*x) };
f = { |x| 1.do{ x = g.(x) }; x};
bench{ f.(0).postln };
// final x: *0.054171801051906* (same as C++, Lua, Python; different
from Clojure)
Thanks,
Glen.
--
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/kFNxGrRPf2k/unsubscribe.
To unsubscribe from this group and all its topics,
Re: Lessons Learned from Adopting Clojure
On Wed, Feb 5, 2014 at 1:27 PM, Sean Corfield s...@corfield.org wrote: On Feb 5, 2014, at 5:39 AM, John D. Hume duelin.mark...@gmail.com wrote: Could you clarify the difference between LightTable's M-) and using C-M-x* in Emacs jacked into an nrepl session with Cider? M-) is paredit-forward-slurp-sexp in both LightTable and Emacs. Sorry, I thought you were saying that kb shortcut is what committed the change to the running JVM. I now see your point that LightTable keeps trying to eval each top-level form and show you the result as you edit, whereas in Emacs you would have to issue a command to see the value of a top-level form. It seems like a small distinction, but I can see how it would make work more fluid. The misconception I hope is disappearing is that REPL-driven development in Emacs necessarily involves lots of switching and copy-pasting back and forth between source file buffers and a REPL buffer. The video in Jay's blog post makes it pretty clear you never need to see the REPL prompt to use the REPL to change a running system. -- 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: Reagent 0.3.0 - now with async rendering
Hi Dan First of all thank you for Reagent - I'm enjoying playing with the library. Do you have a simple example of passing child components and then rendering them as I cannot get this to work - I fairly new to Clojure so it could be user error. cheers Dave -- 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: Confused by Clojure floating-point differences (compared to other languages)
Thanks, yes, the version starting with 0.0 in the loop (rather than 0) does run faster. In my case, about 13% faster (19.7 seconds -- for the code you pasted below, with *unchecked-math*, type hints and starting x of 0.0 -- vs 22.7 seconds for my original version). But if you start with x of 0 (integer), the type-hinted version runs notably slower. In all cases, though, at least you get the same final answer... (-; So I don't see that 50% speedup you're seeing, but I do see improvement. I'm on Clojure 1.5.1, and Java 1.7.0_51 on OS X 10.8.5, running in an nREPL (cider) in Emacs. Possibly other JDK versions have more optimizations? Thanks Glen. On Feb 5, 2014, at 10:56 PM, David Nolen dnolen.li...@gmail.com wrote: (set! *unchecked-math* true) (defn g ^double [^double x] (+ (Math/sin (* 2.3 x)) (Math/cos (* 3.7 x (time (loop [i 1 x 0.0] (if (pos? i) (recur (dec i) (g x)) x))) This is nearly 50% faster than the original version on my machine. Note that x is bound to 0.0 in the loop, which allows the optimized g to be invoked. On Wed, Feb 5, 2014 at 4:41 PM, Glen Fraser holag...@gmail.com wrote: Thanks to both of you for these suggestions, they're good to know. In my specific case, setting the *unchecked-math* flag true did indeed speed things up slightly (by about 6%). The other change, though, with the double type hints (I assume that's what those are), actually ran notably slower (over 20% slower!). Glen. On Feb 5, 2014, at 8:13 PM, David Nolen dnolen.li...@gmail.com wrote: Also: (defn g ^double [^double x] (+ (Math/sin (* 2.3 x)) (Math/cos (* 3.7 x On Wed, Feb 5, 2014 at 2:07 PM, Alex Miller a...@puredanger.com wrote: Others have answered with many useful bits but I would mention that it would possibly make a significant performance difference if you added this to your code: (set! *unchecked-math* true) -- 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: Confused by Clojure floating-point differences (compared to other languages)
You need to make sure that you are running with server settings. If you are using lein, it's likely that this is not the case unless you have overridden lein's defaults in your project.clj. On Wed, Feb 5, 2014 at 5:30 PM, Glen Fraser holag...@gmail.com wrote: Thanks, yes, the version starting with 0.0 in the loop (rather than 0) does run faster. In my case, about 13% faster (19.7 seconds -- for the code you pasted below, with *unchecked-math*, type hints and starting x of 0.0 -- vs 22.7 seconds for my original version). But if you start with x of 0 (integer), the type-hinted version runs notably slower. In all cases, though, at least you get the same final answer… (-; So I don't see that 50% speedup you're seeing, but I do see improvement. I'm on Clojure 1.5.1, and Java 1.7.0_51 on OS X 10.8.5, running in an nREPL (cider) in Emacs. Possibly other JDK versions have more optimizations? Thanks Glen. On Feb 5, 2014, at 10:56 PM, David Nolen dnolen.li...@gmail.com wrote: (set! *unchecked-math* true) (defn g ^double [^double x] (+ (Math/sin (* 2.3 x)) (Math/cos (* 3.7 x (time (loop [i 1 x 0.0] (if (pos? i) (recur (dec i) (g x)) x))) This is nearly 50% faster than the original version on my machine. Note that x is bound to 0.0 in the loop, which allows the optimized g to be invoked. On Wed, Feb 5, 2014 at 4:41 PM, Glen Fraser holag...@gmail.com wrote: Thanks to both of you for these suggestions, they're good to know. In my specific case, setting the *unchecked-math* flag true did indeed speed things up slightly (by about 6%). The other change, though, with the double type hints (I assume that's what those are), actually ran notably slower (over 20% slower!). Glen. On Feb 5, 2014, at 8:13 PM, David Nolen dnolen.li...@gmail.com wrote: Also: (defn g ^double [^double x] (+ (Math/sin (* 2.3 x)) (Math/cos (* 3.7 x On Wed, Feb 5, 2014 at 2:07 PM, Alex Miller a...@puredanger.com wrote: Others have answered with many useful bits but I would mention that it would possibly make a significant performance difference if you added this to your code: (set! *unchecked-math* true) -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: ANN: Reagent 0.3.0 - now with async rendering
On 5 feb 2014, at 23:28, David Simmons shortlypor...@gmail.com wrote:
Do you have a simple example of passing child components and then rendering
them as I cannot get this to work - I fairly new to Clojure so it could be
user error.
Yeah, that is apparently a bit tricky: see
https://github.com/holmsand/reagent/issues/13
And (as mentioned in the issue) the error message you get right now is frankly
quite horrible...
The children parameter passed to components is a vector, so you have to
combine it with another vector to make the whole thing work.
For example like this:
(defn has-children [props children]
(into [:div {:style {:color red}}]
children))
used like this:
[has-children foo [:i bar]]
/dan
--
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: Reagent 0.3.0 - now with async rendering
Thanks Dan I'll give this a go. cheers Dave -- 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: Lessons Learned from Adopting Clojure
On Wed, Feb 5, 2014 at 4:35 PM, James Trunk james.tr...@gmail.com wrote: As a TDD practitioner and Expectations user, I've been following this thread with great interest! @Jay: Will your change in thinking have any impact on Expectations? I don't anticipate making any changes to expectations, but it's likely that my preference for test-after did help shape some of expectations syntax. Writing tests after is pretty boring work, which is likely at least part of the reason that you're able to write such concise tests using expectations. -- 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: Confused by Clojure floating-point differences (compared to other languages)
To override the default tiered compilation, add this to your project.clj: :jvm-opts ^:replace [] I would also recommend using a newer JDK (preferably 7, but at least 6). On Wednesday, February 5, 2014 4:34:12 PM UTC-6, David Nolen wrote: You need to make sure that you are running with server settings. If you are using lein, it's likely that this is not the case unless you have overridden lein's defaults in your project.clj. On Wed, Feb 5, 2014 at 5:30 PM, Glen Fraser hola...@gmail.comjavascript: wrote: Thanks, yes, the version starting with 0.0 in the loop (rather than 0) does run faster. In my case, about 13% faster (19.7 seconds -- for the code you pasted below, with *unchecked-math*, type hints and starting x of 0.0 -- vs 22.7 seconds for my original version). But if you start with x of 0 (integer), the type-hinted version runs notably slower. In all cases, though, at least you get the same final answer… (-; So I don't see that 50% speedup you're seeing, but I do see improvement. I'm on Clojure 1.5.1, and Java 1.7.0_51 on OS X 10.8.5, running in an nREPL (cider) in Emacs. Possibly other JDK versions have more optimizations? Thanks Glen. On Feb 5, 2014, at 10:56 PM, David Nolen dnolen...@gmail.comjavascript: wrote: (set! *unchecked-math* true) (defn g ^double [^double x] (+ (Math/sin (* 2.3 x)) (Math/cos (* 3.7 x (time (loop [i 1 x 0.0] (if (pos? i) (recur (dec i) (g x)) x))) This is nearly 50% faster than the original version on my machine. Note that x is bound to 0.0 in the loop, which allows the optimized g to be invoked. On Wed, Feb 5, 2014 at 4:41 PM, Glen Fraser hola...@gmail.comjavascript: wrote: Thanks to both of you for these suggestions, they're good to know. In my specific case, setting the *unchecked-math* flag true did indeed speed things up slightly (by about 6%). The other change, though, with the double type hints (I assume that's what those are), actually ran notably slower (over 20% slower!). Glen. On Feb 5, 2014, at 8:13 PM, David Nolen dnolen...@gmail.comjavascript: wrote: Also: (defn g ^double [^double x] (+ (Math/sin (* 2.3 x)) (Math/cos (* 3.7 x On Wed, Feb 5, 2014 at 2:07 PM, Alex Miller al...@puredanger.comjavascript: wrote: Others have answered with many useful bits but I would mention that it would possibly make a significant performance difference if you added this to your code: (set! *unchecked-math* true) -- 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.
Re: Confused by Clojure floating-point differences (compared to other languages)
Did I see a thread a while ago where doing this caught some people out because it wiped out some other performance switches? I can't find the thread. Apologies if I am spreading FUD On Wednesday, 5 February 2014 23:05:18 UTC, Alex Miller wrote: To override the default tiered compilation, add this to your project.clj: :jvm-opts ^:replace [] I would also recommend using a newer JDK (preferably 7, but at least 6). On Wednesday, February 5, 2014 4:34:12 PM UTC-6, David Nolen wrote: You need to make sure that you are running with server settings. If you are using lein, it's likely that this is not the case unless you have overridden lein's defaults in your project.clj. On Wed, Feb 5, 2014 at 5:30 PM, Glen Fraser hola...@gmail.com wrote: Thanks, yes, the version starting with 0.0 in the loop (rather than 0) does run faster. In my case, about 13% faster (19.7 seconds -- for the code you pasted below, with *unchecked-math*, type hints and starting x of 0.0 -- vs 22.7 seconds for my original version). But if you start with x of 0 (integer), the type-hinted version runs notably slower. In all cases, though, at least you get the same final answer… (-; So I don't see that 50% speedup you're seeing, but I do see improvement. I'm on Clojure 1.5.1, and Java 1.7.0_51 on OS X 10.8.5, running in an nREPL (cider) in Emacs. Possibly other JDK versions have more optimizations? Thanks Glen. On Feb 5, 2014, at 10:56 PM, David Nolen dnolen...@gmail.com wrote: (set! *unchecked-math* true) (defn g ^double [^double x] (+ (Math/sin (* 2.3 x)) (Math/cos (* 3.7 x (time (loop [i 1 x 0.0] (if (pos? i) (recur (dec i) (g x)) x))) This is nearly 50% faster than the original version on my machine. Note that x is bound to 0.0 in the loop, which allows the optimized g to be invoked. On Wed, Feb 5, 2014 at 4:41 PM, Glen Fraser hola...@gmail.com wrote: Thanks to both of you for these suggestions, they're good to know. In my specific case, setting the *unchecked-math* flag true did indeed speed things up slightly (by about 6%). The other change, though, with the double type hints (I assume that's what those are), actually ran notably slower (over 20% slower!). Glen. On Feb 5, 2014, at 8:13 PM, David Nolen dnolen...@gmail.com wrote: Also: (defn g ^double [^double x] (+ (Math/sin (* 2.3 x)) (Math/cos (* 3.7 x On Wed, Feb 5, 2014 at 2:07 PM, Alex Miller al...@puredanger.comwrote: Others have answered with many useful bits but I would mention that it would possibly make a significant performance difference if you added this to your code: (set! *unchecked-math* true) -- 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=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_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: How to transform one data structure to another data structure?
This is very similar to Sean's solution, but all values will be vectors:
(reduce
(fn [acc [k v]]
(update-in acc [k]
#(conj (or %1 []) v))) {}
[[:a 123] [:b 124] [:a 125] [:c 126] [:b 127] [:a 100]])
--
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: Confused by Clojure floating-point differences (compared to other languages)
He is running 7. -- 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: Confused by Clojure floating-point differences (compared to other languages)
On Feb 5, 2014, at 6:05 PM, Alex Miller wrote: To override the default tiered compilation, add this to your project.clj: :jvm-opts ^:replace [] I was under the impression that one can get the same effect by running your program with: lein trampoline with-profile production run [etc] True? I *think* the text here implies this too: https://github.com/technomancy/leiningen/blob/master/doc/TUTORIAL.md FWIW my goal is to be able to run a project with one command, starting with a project that contains only source code (with none of my code pre-compiled), and have it do whatever it has to do to launch (I don't much care how long the launch takes) and then run as fast as possible (often for hours or days, CPU-bound). I launch my current runs with a command line like the one above, and I do also specify :jvm-opts in project.clj, specificially: :jvm-opts [-Xmx12g -Xms12g -XX:+UseParallelGC] Except that I have to tweak those 12s manually for different machines... Is there any way to specify just use whatever's available? Since I'm supplying other :jvm-opts I was under the impression that I couldn't do the ^:replace [] thing... So is with-profile production going to have the same effect? BTW I would also love input on the GC option. I'm also not at all sure that one is the best, but I generate lots of garbage across large numbers of cores so it seemed like a good idea. But then I read something here about the G1 GC... is that likely to be better? If so, does anyone know the string to include in :jvm-opts to use it? Thanks ( sorry to include so many questions!), -Lee -- 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: Confused by Clojure floating-point differences (compared to other languages)
Modern JVM's pick default heap sizes based on the physical memory in your machine. With more than 1GB of physical memory, initial heap is 1/64 and maximum heap is 1/4 of physical memory.[1] For OpenJDK and Oracle, this command: java -XX:+PrintFlagsFinal -version | grep HeapSize will show the initial and maximum heap sizes (along with a few other numbers). Also, you may not want to set the initial heap size as large as the maximum heap size. Oracle[2] says (in part): Setting -Xms and -Xmx to the same value increases predictability by removing the most important sizing decision from the virtual machine. However, the virtual machine is then unable to compensate if you make a poor choice. - Bruce [1] http://stackoverflow.com/questions/2915276/what-is-the-default-maximum-heap-size-for-suns-jvm-from-java-se-6 [2] http://www.oracle.com/technetwork/java/javase/gc-tuning-6-140523.html#generation_sizing.total_heap On Wed, Feb 5, 2014, at 08:28 PM, Lee Spector wrote: On Feb 5, 2014, at 6:05 PM, Alex Miller wrote: To override the default tiered compilation, add this to your project.clj: :jvm-opts ^:replace [] I was under the impression that one can get the same effect by running your program with: lein trampoline with-profile production run [etc] True? I *think* the text here implies this too: https://github.com/technomancy/leiningen/blob/master/doc/TUTORIAL.md FWIW my goal is to be able to run a project with one command, starting with a project that contains only source code (with none of my code pre-compiled), and have it do whatever it has to do to launch (I don't much care how long the launch takes) and then run as fast as possible (often for hours or days, CPU-bound). I launch my current runs with a command line like the one above, and I do also specify :jvm-opts in project.clj, specificially: :jvm-opts [-Xmx12g -Xms12g -XX:+UseParallelGC] Except that I have to tweak those 12s manually for different machines... Is there any way to specify just use whatever's available? Since I'm supplying other :jvm-opts I was under the impression that I couldn't do the ^:replace [] thing... So is with-profile production going to have the same effect? BTW I would also love input on the GC option. I'm also not at all sure that one is the best, but I generate lots of garbage across large numbers of cores so it seemed like a good idea. But then I read something here about the G1 GC... is that likely to be better? If so, does anyone know the string to include in :jvm-opts to use it? Thanks ( sorry to include so many questions!), -Lee -- 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: Confused by Clojure floating-point differences (compared to other languages)
On Feb 5, 2014, at 8:50 PM, Bruce Adams wrote: Modern JVM's pick default heap sizes based on the physical memory in your machine. With more than 1GB of physical memory, initial heap is 1/64 and maximum heap is 1/4 of physical memory.[1] For OpenJDK and Oracle, this command: java -XX:+PrintFlagsFinal -version | grep HeapSize will show the initial and maximum heap sizes (along with a few other numbers). Thanks Bruce. Do you happen to know if there's a way to specify different fractions? I'd like something more like 3/4 (or 7/8) than 1/4. Nothing else will be running on the machine (aside from the OS and maybe tiny other things), and I want it to take everything it might need. I realize I can hardcode specific sizes, but then I have to change it for every machine configuration it runs on, which is what I was hoping to avoid. I have 64GB on some of my machines, 12GB on others, etc., and I'd like to use most of what's available wherever I run, preferably without changing project.clj every time. Also, you may not want to set the initial heap size as large as the maximum heap size. Oracle[2] says (in part): Setting -Xms and -Xmx to the same value increases predictability by removing the most important sizing decision from the virtual machine. However, the virtual machine is then unable to compensate if you make a poor choice. The choice of using the same, maximal limit for both -Xms and -Xmx, could only be poor in the sense of using more than the necessary memory, right? Since I'm happy to use every available byte and am only concerned about speed it seems like this should be okay. Thanks, -Lee -- 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: [lein-describe 0.1.0] plugin for displaying detailed information about Clojure projects
The project URL is https://github.com/noprompt/lein-garden;. (Sorry, if this was mentioned before, I joined recently.) On Wed, Feb 5, 2014 at 12:28 PM, da...@dsargeant.com wrote: Looks cool. I'll be sure to check it 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. -- Kind Regards, Atamert Ölçgen -+- --+ +++ www.muhuk.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.
Re: How to transform one data structure to another data structure?
If you're not worried about order, you could also write:
(reduce (fn [m [k v]] (update-in m [k] conj v)) {} values)
- James
On 6 February 2014 00:40, Paul Mooser taron...@gmail.com wrote:
This is very similar to Sean's solution, but all values will be vectors:
(reduce
(fn [acc [k v]]
(update-in acc [k]
#(conj (or %1 []) v))) {}
[[:a 123] [:b 124] [:a 125] [:c 126] [:b 127] [:a 100]])
--
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: Lessons Learned from Adopting Clojure
FWIW, I find the language of Expectations to be much better suited to describing the desired behaviors of a system I want to build than the assertion-based language of clojure.test - so for me it's about test-before, not test-after. Sean On Wed, Feb 5, 2014 at 2:52 PM, Jay Fields j...@jayfields.com wrote: On Wed, Feb 5, 2014 at 4:35 PM, James Trunk james.tr...@gmail.com wrote: As a TDD practitioner and Expectations user, I've been following this thread with great interest! @Jay: Will your change in thinking have any impact on Expectations? I don't anticipate making any changes to expectations, but it's likely that my preference for test-after did help shape some of expectations syntax. Writing tests after is pretty boring work, which is likely at least part of the reason that you're able to write such concise tests using expectations. -- 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.
diagram of clojure interfaces and objects
I'd start here: http://www.clojureatlas.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.
Re: Lessons Learned from Adopting Clojure
On Wed, Feb 5, 2014 at 1:56 PM, John D. Hume duelin.mark...@gmail.com wrote: The misconception I hope is disappearing is that REPL-driven development in Emacs necessarily involves lots of switching and copy-pasting back and forth between source file buffers and a REPL buffer. The video in Jay's blog post makes it pretty clear you never need to see the REPL prompt to use the REPL to change a running system. Agreed but my point was that in Emacs the results of your evaluations are elsewhere and there is still a separate REPL buffer, even if you actually work by editing a source file and sending expressions from there to the REPL to operate on a live image. I believe it was Mark Engelberg who talked about working *in* the REPL and scrolling back through history and modifying and resubmitting previous forms while he was developing his code. I think others have also said they work that way. The objection was voiced (about LightTable) that it's not a natural REPL-based workflow to have code in a source file and send it to be evaluated. -- 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: [ANN] garden-watch
The idea to watch edn or garden files was a consideration of lein-garden but decided against it because, personally, I felt it was giving up a lot. However, some folks may prefer this approach and, hopefully, it suits them just as well. On Wednesday, February 5, 2014 4:45:43 AM UTC-8, frye wrote: Hey Dave, Thanks for that heads up. I originally wanted auto-compiling for *HAML*and *SCSS*. But then thought why, when I could just use edn with *Hiccup* and *Garden*. Now, a lein-hiccup, or some auto compile tool doesn't exist to my knowledge. So *i)* I had to do that work anyways. Then I spent 20 mins replicating the functionality for Garden. Also I think lein-garden tracks edn style definitions, inlined in your existing Clojure code, whereas *ii)* I wanted a separate directory watcher on edn files (no namespaces needed). But there's nothing that says that functionality in garden-watch couldn't be collapsed into lein-garden. It's pretty straightforward code. Tim Washington Interruptsoftware.com http://interruptsoftware.com On Wed, Feb 5, 2014 at 2:50 AM, Dave Sann dave...@gmail.com javascript: wrote: FYI, I think lein garden does this already. is there a particular difference? -- 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: [lein-describe 0.1.0] plugin for displaying detailed information about Clojure projects
Wat? I think you may have meant to post this comment somewhere else. That's certainly not the case. But I think I did forget to share the link which is: https://github.com/noprompt/lein-describe On Wednesday, February 5, 2014 6:23:25 PM UTC-8, Atamert Ölçgen wrote: The project URL is https://github.com/noprompt/lein-garden;. (Sorry, if this was mentioned before, I joined recently.) On Wed, Feb 5, 2014 at 12:28 PM, da...@dsargeant.com javascript:wrote: Looks cool. I'll be sure to check it out. -- 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. -- Kind Regards, Atamert Ölçgen -+- --+ +++ www.muhuk.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.
Re: ANN: [lein-describe 0.1.0] plugin for displaying detailed information about Clojure projects
I posted to the correct thread. Check the project.clj please. On Thu, Feb 6, 2014 at 12:05 PM, Joel Holdbrooks cjholdbro...@gmail.comwrote: Wat? I think you may have meant to post this comment somewhere else. That's certainly not the case. But I think I did forget to share the link which is: https://github.com/noprompt/lein-describe On Wednesday, February 5, 2014 6:23:25 PM UTC-8, Atamert Ölçgen wrote: The project URL is https://github.com/noprompt/lein-garden;. (Sorry, if this was mentioned before, I joined recently.) On Wed, Feb 5, 2014 at 12:28 PM, da...@dsargeant.com wrote: Looks cool. I'll be sure to check it out. -- 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=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_out. -- Kind Regards, Atamert Ölçgen -+- --+ +++ www.muhuk.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. -- Kind Regards, Atamert Ölçgen -+- --+ +++ www.muhuk.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.
Re: Confused by Clojure floating-point differences (compared to other languages)
This returns (.getTotalPhysicalMemorySize (java.lang.management.ManagementFactory/getOperatingSystemMXBean)) You could use this in your project.clj, perhaps by including ~(str -Xms (quot (.getTotalPhysicalMemorySize ...) appropriate-number)) in :jvm-opts. Also, you can absolutely use your own :jvm-opts with :replace. Cheers, Michał PS. getTotalPhysicalMemorySize is declared by com.sun.management.OperatingSystemMXBean. getOperatingSystemMXBean's return type is actually java.lang.management.OperatingSystemMXBean, but the actual returned value does implement the com.sun interface. I just tested this on a Linux system, hopefully it'll also work on other platforms. On 6 February 2014 03:15, Lee Spector lspec...@hampshire.edu wrote: On Feb 5, 2014, at 8:50 PM, Bruce Adams wrote: Modern JVM's pick default heap sizes based on the physical memory in your machine. With more than 1GB of physical memory, initial heap is 1/64 and maximum heap is 1/4 of physical memory.[1] For OpenJDK and Oracle, this command: java -XX:+PrintFlagsFinal -version | grep HeapSize will show the initial and maximum heap sizes (along with a few other numbers). Thanks Bruce. Do you happen to know if there's a way to specify different fractions? I'd like something more like 3/4 (or 7/8) than 1/4. Nothing else will be running on the machine (aside from the OS and maybe tiny other things), and I want it to take everything it might need. I realize I can hardcode specific sizes, but then I have to change it for every machine configuration it runs on, which is what I was hoping to avoid. I have 64GB on some of my machines, 12GB on others, etc., and I'd like to use most of what's available wherever I run, preferably without changing project.clj every time. Also, you may not want to set the initial heap size as large as the maximum heap size. Oracle[2] says (in part): Setting -Xms and -Xmx to the same value increases predictability by removing the most important sizing decision from the virtual machine. However, the virtual machine is then unable to compensate if you make a poor choice. The choice of using the same, maximal limit for both -Xms and -Xmx, could only be poor in the sense of using more than the necessary memory, right? Since I'm happy to use every available byte and am only concerned about speed it seems like this should be okay. Thanks, -Lee -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [ANN] garden-watch
Clojure. On Feb 5, 2014, at 8:42 PM, Timothy Washington twash...@gmail.com wrote: Ok, that's fine. Definitely good to have both ways to tackle the problem. But I'm curious. What do you feel is being given up by watching garden files? Thanks Tim Washington Interruptsoftware.com On Wed, Feb 5, 2014 at 11:04 PM, Joel Holdbrooks cjholdbro...@gmail.com wrote: The idea to watch edn or garden files was a consideration of lein-garden but decided against it because, personally, I felt it was giving up a lot. However, some folks may prefer this approach and, hopefully, it suits them just as well. On Wednesday, February 5, 2014 4:45:43 AM UTC-8, frye wrote: Hey Dave, Thanks for that heads up. I originally wanted auto-compiling for HAML and SCSS. But then thought why, when I could just use edn with Hiccup and Garden. Now, a lein-hiccup, or some auto compile tool doesn't exist to my knowledge. So i) I had to do that work anyways. Then I spent 20 mins replicating the functionality for Garden. Also I think lein-garden tracks edn style definitions, inlined in your existing Clojure code, whereas ii) I wanted a separate directory watcher on edn files (no namespaces needed). But there's nothing that says that functionality in garden-watch couldn't be collapsed into lein-garden. It's pretty straightforward code. Tim Washington Interruptsoftware.com On Wed, Feb 5, 2014 at 2:50 AM, Dave Sann dave...@gmail.com wrote: FYI, I think lein garden does this already. is there a particular difference? -- 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/GyKBpfEFkqg/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: [lein-describe 0.1.0] plugin for displaying detailed information about Clojure projects
Check which project.clj? You posted a link to lien-garden. Am I missing something here? On Wednesday, February 5, 2014 8:29:35 PM UTC-8, Atamert Ölçgen wrote: I posted to the correct thread. Check the project.clj please. On Thu, Feb 6, 2014 at 12:05 PM, Joel Holdbrooks cjhold...@gmail.comjavascript: wrote: Wat? I think you may have meant to post this comment somewhere else. That's certainly not the case. But I think I did forget to share the link which is: https://github.com/noprompt/lein-describe On Wednesday, February 5, 2014 6:23:25 PM UTC-8, Atamert Ölçgen wrote: The project URL is https://github.com/noprompt/lein-garden;. (Sorry, if this was mentioned before, I joined recently.) On Wed, Feb 5, 2014 at 12:28 PM, da...@dsargeant.com wrote: Looks cool. I'll be sure to check it out. -- 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=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_out. -- Kind Regards, Atamert Ölçgen -+- --+ +++ www.muhuk.com -- 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. -- Kind Regards, Atamert Ölçgen -+- --+ +++ www.muhuk.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.
Documentation, tips on chunked sequence functions?
It's easy to find information on the net about the general concept of a Clojure chunked sequence, and about the effects of using chunked sequences. I would like to understand the code that deals with chunked sequences in the Clojure source, in functions such as map and doseq. Any suggestions about what to read? -- 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: Documentation, tips on chunked sequence functions?
Just to be completely clear, I want to understand the source code for map and doseq. The parts that deal with chunked sequences are confusing to me. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: ANN: [lein-describe 0.1.0] plugin for displaying detailed information about Clojure projects
Oh, hey, thanks. I didn't catch that. Great copy/paste fail, eh. Maybe next time post an issue to the Github. :-) On Feb 5, 2014, at 8:29 PM, Atamert Ölçgen mu...@muhuk.com wrote: I posted to the correct thread. Check the project.clj please. On Thu, Feb 6, 2014 at 12:05 PM, Joel Holdbrooks cjholdbro...@gmail.com wrote: Wat? I think you may have meant to post this comment somewhere else. That's certainly not the case. But I think I did forget to share the link which is: https://github.com/noprompt/lein-describe On Wednesday, February 5, 2014 6:23:25 PM UTC-8, Atamert Ölçgen wrote: The project URL is https://github.com/noprompt/lein-garden;. (Sorry, if this was mentioned before, I joined recently.) On Wed, Feb 5, 2014 at 12:28 PM, da...@dsargeant.com wrote: Looks cool. I'll be sure to check it out. -- 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=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_out. -- Kind Regards, Atamert Ölçgen -+- --+ +++ www.muhuk.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. -- Kind Regards, Atamert Ölçgen -+- --+ +++ www.muhuk.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 a topic in the Google Groups Clojure group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/clojure/FWeIIO2ToGQ/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.
having trouble with lein-ring :auto-refresh?
Hi,
I've set up lein-ring with ring :auto-refresh? true but don't see updates
in the browser unless I refresh manually. It seems I have something
configured wrong but I can't see it. Does this look right?...
(defproject mystuff 0.1.0-SNAPSHOT
:description experiment
:url http://example.com/FIXME;
:license {:name Eclipse Public License
:url http://www.eclipse.org/legal/epl-v10.html}
:dependencies [[org.clojure/clojure 1.5.1]
[hiccup 1.0.5]]
:plugins [[lein-ring 0.8.10]]
:ring {:handler mystuff.core/ring-handler
:auto-reload? true
:auto-refresh? true}
:target-path target/%s)
My ring-handler function is basically a copy of the hello world one on
ring's site, but the body comes from a defined value.
(def x (html [:h1 (hello)]))
(defn ring-handler [request]
{:status 200
:headers {Content-Type text/html}
:body x})
The :auto-reload? true works as expected. But not :auto-refresh? true.
I'm after the live coding experience here. And I want it to be with
lein-ring if I can.
(I tried Daniel Szmulewicz's cool emacs way but I think lein-ring will fit
my needs better.)
confuzzled,
boz
--
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.
