Genetic Algorithm Example
Hi everyone! I started learning Clojure earlier this year (as a part of MSc studies from this discussion: http://groups.google.com/group/clojure/browse_thread/thread/a8aa5ac26d9761da?hl=entvc=2#) I was initially shocked with lispy syntax, given the fact I previously mostly used languages with C-like syntax, however after some time spent on trying out stuff and playing with REPL it wasn't so alien anymore and I admit I was quite surprised with how much work can be done with Clojure for very little time. Anyway, being a Clojure newbie myself, I had a huge benefit from freely available code examples, so I decided to share my own project with other folks who are learning Clojure. It's hosted on: http://code.google.com/p/genetic-my-number/ So, enjoy... and, of course, I always welcome ideas, suggestions, (constructive) criticism or any other comments. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Macro closing over atom gives Can't embed object in code error.
A macro is a function which returns a data structure representing code to be compiled. All literals (String, Integer, symbol, etc.) and basic data structures (lists, maps, etc.) can be compiled, as can functions. Most other non-literal objects *cannot* be compiled. What you probably want is not a macro but a closure: (defn hidden-atom [] (let [a (atom :hello)] (fn [] (deref a (def x (hidden-atom)) (x) ;;= :hello -S On Sep 19, 12:32 am, Nathan Sorenson n...@sfu.ca wrote: I am playing around with a macro to define accessor functions for a closed-over atom. Here is a simplified example: (defmacro hidden-atom [] (let [a (atom :hello)] `(defn get-value [] (deref ~a When I evaluate this macro, I get the error: Can't embed object in code, maybe print-dup not defined: clojure.lang.a...@1a7693a I imagined this should work, as the above macro doesn't seem too different from the following macro, which does work: (defmacro hidden-function[] (let [a (fn [] :hello)] `(defn get-value [] (~a When using macroexpand-1, both macros return nearly identical forms: gdsl.proc (macroexpand '(hidden-atom)) (def gdsl.proc/get-value (.withMeta (clojure.core/fn gdsl.proc/get- value ([] (clojure.core/deref #a...@10a5e22: :hello))) (.meta (var gdsl.proc/get-value gdsl.proc (macroexpand '(hidden-function)) (def gdsl.proc/get-value (.withMeta (clojure.core/fn gdsl.proc/get- value ([] (#proc$hidden_function$a__15149 gdsl.proc$hidden_function $a__15...@bde2da))) (.meta (var gdsl.proc/get-value I'm afraid I don't know enough about macro expansion to understand what is wrong here. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Displaying source of function typed into the REPL?
On Sep 18, 5:39 pm, Sean Corfield seancorfi...@gmail.com wrote: Is there something easy within the REPL to show the source of something you defined earlier? No. The REPL does not preserve what you type in. -S -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Displaying source of function typed into the REPL?
I think this would be a very nice extension for the repl - Saving the forms for later-retrieval. On Sun, Sep 19, 2010 at 3:54 PM, Stuart Sierra the.stuart.sie...@gmail.com wrote: On Sep 18, 5:39 pm, Sean Corfield seancorfi...@gmail.com wrote: Is there something easy within the REPL to show the source of something you defined earlier? No. The REPL does not preserve what you type in. -S -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this 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 -- Moritz Ulrich Programmer, Student, Almost normal Guy http://www.google.com/profiles/ulrich.moritz BB5F086F-C798-41D5-B742-494C1E9677E8 -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this 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
why the big difference in speed?
Hi, I'm trying learn Clojure to see if I can use it in my simulations, and one thing I need to do is generate arrays of normally distributed numbers. I've been able to come up with the following two ways of doing this. gaussian-matrix2 is a lot faster than gaussian-matrix1, but I'm not sure why. And it's still slower than it should be I think. Is there anything I can do to speed this up still further? Thanks, -Ranjit (import java.util.Random) (def r (Random. )) (defn next-gaussian [] (.nextGaussian r)) (defn gaussian-matrix1 [arr L] (doseq [x (range L) y (range L)] (aset arr x y (next-gaussian (defn gaussian-matrix2 [L] (into-array (map double-array (partition L (repeatedly (* L L) next-gaussian) -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: why the big difference in speed?
A first good start is to put (set! *warn-on-relection* true) at the start of the file and removes all reflective access. Before the 1.3 release, function cannot receive/returns primitive so you might consider (defmacro next-gaussian [] `(.nextGaussian ^Random r)) (^Random is here to make sure r is seen with the right type) in both function, add ^doubles before arr at the binding point. (defn ... [^doubles arr]) then set will not be rflective and be as fast as a set in java. Ask other questions of you need more help. The best reference on all that: clojure.org/java_interop On Sun, Sep 19, 2010 at 3:29 PM, Ranjit rjcha...@gmail.com wrote: Hi, I'm trying learn Clojure to see if I can use it in my simulations, and one thing I need to do is generate arrays of normally distributed numbers. I've been able to come up with the following two ways of doing this. gaussian-matrix2 is a lot faster than gaussian-matrix1, but I'm not sure why. And it's still slower than it should be I think. Is there anything I can do to speed this up still further? Thanks, -Ranjit (import java.util.Random) (def r (Random. )) (defn next-gaussian [] (.nextGaussian r)) (defn gaussian-matrix1 [arr L] (doseq [x (range L) y (range L)] (aset arr x y (next-gaussian (defn gaussian-matrix2 [L] (into-array (map double-array (partition L (repeatedly (* L L) next-gaussian) -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this 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 -- Sent from an IBM Model M, 15 August 1989. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Using macro to generate part of fn
On 19 Sep 2010, at 07:21, Stuart Campbell wrote: In this method, the first two parameters may be null. So, my fn looks like this: (defn exported-keys ([table] (exported-keys nil table)) ([schema table] (exported-keys nil schema table)) ([catalog schema table] (fetch-metadata-rs .getExportedKeys catalog schema table))) I was trying to automatically generate the final function body since it duplicates the parameter list, and I expect to have a lot of these kinds of methods. Although, it's not too bad as it is (I've already pulled some common bits into fetch-metadata-rs). You could have a macro (defmacro make-wrapper [name method args] ...) and call it (make-wrapper exported-keys getExportedKeys catalog schema table) or something like that. You might have to add some indication about the order in which the arguments become optional if that's not always the same. The essential point is to generate the whole function from one macro, rather than try to generate pieces of the function body by some macro. 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
Re: practical clojure
I definitely have. I'm in the middle of trying to port some stats test from R over to Incanter, notably the Wicoxon Rank Sum test. I just meant I hope this catches on with statisticians, now that R's creator has admitted its flaws. On Sep 18, 9:09 pm, Jeff Heon jfh...@gmail.com wrote: On Sep 17, 8:23 pm, David J acts.as.da...@gmail.com wrote: I second faenvie's request for applications of Clojure books, especially on AI. AI is the reason I started looking at a Lisp in the first place. I'd also like to see Clojure become *the* language for statistics, though I understand that R statisticians aren't so fond of Lisps. Have a look at Incanter 8) http://incanter.org/ -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: why the big difference in speed?
Hi Nicholas, Thanks for the advice. I already tried (set! *warn-on-reflection* true), but it doesn't generate any warnings for any of these functions. I tried adding ^doubles in gaussian-matrix1 as you suggested but that didn't really change the speed at all. And changing next-gaussian to a macro didn't make much difference to gaussian-matrix1, and it doesn't work with gaussian-matrix2 at all and I'm not quite sure yet how to fix it so it does. I would have thought gaussian-matrix1 would be faster than gaussian- matrix2, but it turns out it's the opposite. Then I thought that the reason using aset was slower must have something to do with reflection, but that doesn't seem to be the case. So I'm a bit confused now. More generally though, the main reason I wanted to use Java arrays was because I have to use FFT's in my simulation and I figured it would be better to do everything in Java arrays rather than copy a Clojure vector into a 2d array and back every time I needed to do an FFT. But am I wrong in thinking that? Thanks, Ranjit On Sep 19, 11:20 am, Nicolas Oury nicolas.o...@gmail.com wrote: A first good start is to put (set! *warn-on-relection* true) at the start of the file and removes all reflective access. Before the 1.3 release, function cannot receive/returns primitive so you might consider (defmacro next-gaussian [] `(.nextGaussian ^Random r)) (^Random is here to make sure r is seen with the right type) in both function, add ^doubles before arr at the binding point. (defn ... [^doubles arr]) then set will not be rflective and be as fast as a set in java. Ask other questions of you need more help. The best reference on all that: clojure.org/java_interop On Sun, Sep 19, 2010 at 3:29 PM, Ranjit rjcha...@gmail.com wrote: Hi, I'm trying learn Clojure to see if I can use it in my simulations, and one thing I need to do is generate arrays of normally distributed numbers. I've been able to come up with the following two ways of doing this. gaussian-matrix2 is a lot faster than gaussian-matrix1, but I'm not sure why. And it's still slower than it should be I think. Is there anything I can do to speed this up still further? Thanks, -Ranjit (import java.util.Random) (def r (Random. )) (defn next-gaussian [] (.nextGaussian r)) (defn gaussian-matrix1 [arr L] (doseq [x (range L) y (range L)] (aset arr x y (next-gaussian (defn gaussian-matrix2 [L] (into-array (map double-array (partition L (repeatedly (* L L) next-gaussian) -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this 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 -- Sent from an IBM Model M, 15 August 1989. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: why the big difference in speed?
In common lisp I use the (disassemble) function which generally gives back an assembler listing of the code that would be executed. Is there a Java function which will return the byte codes that get executed? Could this be used to create a (disassemble) function for Clojure? Having such a function means that you don't have to guess what the program is actually doing. On 9/19/2010 1:19 PM, Ranjit wrote: Hi Nicholas, Thanks for the advice. I already tried (set! *warn-on-reflection* true), but it doesn't generate any warnings for any of these functions. I tried adding ^doubles in gaussian-matrix1 as you suggested but that didn't really change the speed at all. And changing next-gaussian to a macro didn't make much difference to gaussian-matrix1, and it doesn't work with gaussian-matrix2 at all and I'm not quite sure yet how to fix it so it does. I would have thought gaussian-matrix1 would be faster than gaussian- matrix2, but it turns out it's the opposite. Then I thought that the reason using aset was slower must have something to do with reflection, but that doesn't seem to be the case. So I'm a bit confused now. More generally though, the main reason I wanted to use Java arrays was because I have to use FFT's in my simulation and I figured it would be better to do everything in Java arrays rather than copy a Clojure vector into a 2d array and back every time I needed to do an FFT. But am I wrong in thinking that? Thanks, Ranjit On Sep 19, 11:20 am, Nicolas Ourynicolas.o...@gmail.com wrote: A first good start is to put (set! *warn-on-relection* true) at the start of the file and removes all reflective access. Before the 1.3 release, function cannot receive/returns primitive so you might consider (defmacro next-gaussian [] `(.nextGaussian ^Random r)) (^Random is here to make sure r is seen with the right type) in both function, add ^doubles before arr at the binding point. (defn ... [^doubles arr]) then set will not be rflective and be as fast as a set in java. Ask other questions of you need more help. The best reference on all that: clojure.org/java_interop On Sun, Sep 19, 2010 at 3:29 PM, Ranjitrjcha...@gmail.com wrote: Hi, I'm trying learn Clojure to see if I can use it in my simulations, and one thing I need to do is generate arrays of normally distributed numbers. I've been able to come up with the following two ways of doing this. gaussian-matrix2 is a lot faster than gaussian-matrix1, but I'm not sure why. And it's still slower than it should be I think. Is there anything I can do to speed this up still further? Thanks, -Ranjit (import java.util.Random) (def r (Random. )) (defn next-gaussian [] (.nextGaussian r)) (defn gaussian-matrix1 [arr L] (doseq [x (range L) y (range L)] (aset arr x y (next-gaussian (defn gaussian-matrix2 [L] (into-array (map double-array (partition L (repeatedly (* L L) next-gaussian) -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this 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 -- Sent from an IBM Model M, 15 August 1989. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: why the big difference in speed?
You can use javap -c out of the JDK to get the bytecodes that are handed to the VM. However, HotSpot does amazing things with the bytecodes after the code begins to run, so a disassembly can be quite misleading. I measure far more often than I view bytecode. Stu In common lisp I use the (disassemble) function which generally gives back an assembler listing of the code that would be executed. Is there a Java function which will return the byte codes that get executed? Could this be used to create a (disassemble) function for Clojure? Having such a function means that you don't have to guess what the program is actually doing. On 9/19/2010 1:19 PM, Ranjit wrote: Hi Nicholas, Thanks for the advice. I already tried (set! *warn-on-reflection* true), but it doesn't generate any warnings for any of these functions. I tried adding ^doubles in gaussian-matrix1 as you suggested but that didn't really change the speed at all. And changing next-gaussian to a macro didn't make much difference to gaussian-matrix1, and it doesn't work with gaussian-matrix2 at all and I'm not quite sure yet how to fix it so it does. I would have thought gaussian-matrix1 would be faster than gaussian- matrix2, but it turns out it's the opposite. Then I thought that the reason using aset was slower must have something to do with reflection, but that doesn't seem to be the case. So I'm a bit confused now. More generally though, the main reason I wanted to use Java arrays was because I have to use FFT's in my simulation and I figured it would be better to do everything in Java arrays rather than copy a Clojure vector into a 2d array and back every time I needed to do an FFT. But am I wrong in thinking that? Thanks, Ranjit On Sep 19, 11:20 am, Nicolas Ourynicolas.o...@gmail.com wrote: A first good start is to put (set! *warn-on-relection* true) at the start of the file and removes all reflective access. Before the 1.3 release, function cannot receive/returns primitive so you might consider (defmacro next-gaussian [] `(.nextGaussian ^Random r)) (^Random is here to make sure r is seen with the right type) in both function, add ^doubles before arr at the binding point. (defn ... [^doubles arr]) then set will not be rflective and be as fast as a set in java. Ask other questions of you need more help. The best reference on all that: clojure.org/java_interop On Sun, Sep 19, 2010 at 3:29 PM, Ranjitrjcha...@gmail.com wrote: Hi, I'm trying learn Clojure to see if I can use it in my simulations, and one thing I need to do is generate arrays of normally distributed numbers. I've been able to come up with the following two ways of doing this. gaussian-matrix2 is a lot faster than gaussian-matrix1, but I'm not sure why. And it's still slower than it should be I think. Is there anything I can do to speed this up still further? Thanks, -Ranjit (import java.util.Random) (def r (Random. )) (defn next-gaussian [] (.nextGaussian r)) (defn gaussian-matrix1 [arr L] (doseq [x (range L) y (range L)] (aset arr x y (next-gaussian (defn gaussian-matrix2 [L] (into-array (map double-array (partition L (repeatedly (* L L) next-gaussian) -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this 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 -- Sent from an IBM Model M, 15 August 1989. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Macro closing over atom gives Can't embed object in code error.
I think I understand; the unquote operator is not providing a reference to the underlying object itself, but is rather a procedure that translates the object into a code representation. Thank-you for the explanation. On Sep 19, 6:53 am, Stuart Sierra the.stuart.sie...@gmail.com wrote: A macro is a function which returns a data structure representing code to be compiled. All literals (String, Integer, symbol, etc.) and basic data structures (lists, maps, etc.) can be compiled, as can functions. Most other non-literal objects *cannot* be compiled. What you probably want is not a macro but a closure: (defn hidden-atom [] (let [a (atom :hello)] (fn [] (deref a (def x (hidden-atom)) (x) ;;= :hello -S On Sep 19, 12:32 am, Nathan Sorenson n...@sfu.ca wrote: I am playing around with a macro to define accessor functions for a closed-over atom. Here is a simplified example: (defmacro hidden-atom [] (let [a (atom :hello)] `(defn get-value [] (deref ~a When I evaluate this macro, I get the error: Can't embed object in code, maybe print-dup not defined: clojure.lang.a...@1a7693a I imagined this should work, as the above macro doesn't seem too different from the following macro, which does work: (defmacro hidden-function[] (let [a (fn [] :hello)] `(defn get-value [] (~a When using macroexpand-1, both macros return nearly identical forms: gdsl.proc (macroexpand '(hidden-atom)) (def gdsl.proc/get-value (.withMeta (clojure.core/fn gdsl.proc/get- value ([] (clojure.core/deref #a...@10a5e22: :hello))) (.meta (var gdsl.proc/get-value gdsl.proc (macroexpand '(hidden-function)) (def gdsl.proc/get-value (.withMeta (clojure.core/fn gdsl.proc/get- value ([] (#proc$hidden_function$a__15149 gdsl.proc$hidden_function $a__15...@bde2da))) (.meta (var gdsl.proc/get-value I'm afraid I don't know enough about macro expansion to understand what is wrong here. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Keyword namespaces
Unlike symbols, keywords just evaluate to themselves. The keyword :foo will not collide with a var foo, likewise keyword :my-ns/foo will not collide with var my-ns/foo. So, if I understand you correctly, :xsl/ value-of would work just fine. On Sep 19, 11:56 am, Kyle Schaffrick k...@raidi.us wrote: Would it be correct to say that the namespace portions of keywords are semantically opaque? In other words, if I have a keyword :my-ns/foo and a symbol 'my-ns/foo, obviously the namespace in the symbol has semantic meaning to the language when it's evaluated (or syntax-quoted), but the namespace of the keyword does not appear carry that meaning, almost as if they are in two separate meta-namespaces. Is that pretty much guaranteed as far as the language is concerned? I'm asking because I've become the latest in the line of Clojurians to go tilting at the SXML-in-Clojure windmill, and if I decide use the namespace portion of a keyword (for example :xsl/value-of) I want to be certain it's always distinct in meaning from any Clojure namespaces or aliases of the same name. The code I teased apart into this library currently uses keywords like :xsl:value-of to distinguish XML namespaces from Clojure namespaces, just as a matter of that was the first thing I thought of, but it would certainly be saner to stop wasting effort splitting them apart by hand with string munging and simply bestow my own meaning on the keywords' namespaces if the language itself doesn't give them any meaning. Thanks, -Kyle -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Displaying source of function typed into the REPL?
On Sun, Sep 19, 2010 at 10:24 AM, Stephen C. Gilardi squee...@mac.com wrote: The clojure repl is very customizable. It's possible to add this feature in a custom repl to experiment with the idea: Awesome. I'll see if I can generalize that to keep a longer history and a nice easy way to view / retrieve past entries so I can see how useful I'd actually find it in real life... -- Sean A Corfield -- (904) 302-SEAN Railo Technologies, Inc. -- http://getrailo.com/ An Architect's View -- http://corfield.org/ If you're not annoying somebody, you're not really alive. -- Margaret Atwood -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this 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
Can resultset-seq blow the stack?
Hi, While looking at the implementation of clojure.core/resultset-seq function, I found there is a recursive call to 'thisfn' which isn't loop-recur'ed. I simulated a similar recursive call and found it throws StackOverflowError at 5508 levels deep on a 32-bit Sun JVM (not server mode) on Windows 7. This makes me wonder if the recursive call in resultset-seq is intentional -- this might restrict the function to support only a limited number of rows in the result set. Regards, Shantanu -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Keyword namespaces
On Sun, 19 Sep 2010 12:22:54 -0700 (PDT) ataggart alex.tagg...@gmail.com wrote: Unlike symbols, keywords just evaluate to themselves. The keyword :foo will not collide with a var foo, likewise keyword :my-ns/foo will not collide with var my-ns/foo. So, if I understand you correctly, :xsl/ value-of would work just fine. Right, I understand that the keyword and the symbol themselves are distinct. I guess what I'm asking about is the meaning of their namespaces to the evaluator, and probably is best illustrated like this: user= (require '[some.library :as xsl]) nil ;; now the namespace xsl has semantic meaning on symbols when ;; they're evaluated in this context: user= #'xsl/value-of #'some.library/value-of Is there any situation where, in that examaple, the namespace xsl on a keyword such as :xsl/value-of might be conflated with the namespace alias xsl that I created with require? Or, does Clojure consider keyword namespaces to be completely meaningless and opaque, the same as it does with their names? I can't find any situation where the two blur together except for the ::keyword syntax, but I suspect this is nothing more than a superficial syntactic trick. Still, I want to make sure I'm not missing something. -Kyle On Sep 19, 11:56 am, Kyle Schaffrick k...@raidi.us wrote: Would it be correct to say that the namespace portions of keywords are semantically opaque? In other words, if I have a keyword :my-ns/foo and a symbol 'my-ns/foo, obviously the namespace in the symbol has semantic meaning to the language when it's evaluated (or syntax-quoted), but the namespace of the keyword does not appear carry that meaning, almost as if they are in two separate meta-namespaces. Is that pretty much guaranteed as far as the language is concerned? I'm asking because I've become the latest in the line of Clojurians to go tilting at the SXML-in-Clojure windmill, and if I decide use the namespace portion of a keyword (for example :xsl/value-of) I want to be certain it's always distinct in meaning from any Clojure namespaces or aliases of the same name. The code I teased apart into this library currently uses keywords like :xsl:value-of to distinguish XML namespaces from Clojure namespaces, just as a matter of that was the first thing I thought of, but it would certainly be saner to stop wasting effort splitting them apart by hand with string munging and simply bestow my own meaning on the keywords' namespaces if the language itself doesn't give them any meaning. Thanks, -Kyle -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: why the big difference in speed?
I'm seeing a big difference in speed for each function run only once, so I guess any Hotspot optimization isn't happening right? But is the way Clojure works so opaque we need to see byte codes? I was hoping someone on the list would have some intuition about how the expressions get implemented. In fact I hope it's pretty close to what I would naively guess from just reading the code as is. So I think gaussian-matrix1 is basically an imperative style program. There's a couple of loops and a random number is generated and then assigned to a element of the 2d array. And I think that gaussian-matrix2 is first generating a nested set lists with all of the random numbers, then each list is copied into a 1d Java array of doubles by the map operation, and then into-array makes a 1d array of double[]'s. Is that about right, or is that too naive somehow? On Sep 19, 2:24 pm, Alessio Stalla alessiosta...@gmail.com wrote: On 19 Set, 19:34, Tim Daly d...@axiom-developer.org wrote: In common lisp I use the (disassemble) function which generally gives back an assembler listing of the code that would be executed. Is there a Java function which will return the byte codes that get executed? In general there isn't. In the particular situation in which a) the Lisp implementation controls class loading and b) each Lisp function is compiled to a distinct Java class, the implementation can arrange to store the bytecode for each function and run a Java bytecode decompiler on it to disassemble/decompile it. Could this be used to create a (disassemble) function for Clojure? Having such a function means that you don't have to guess what the program is actually doing. I think Clojure respects point a) and b) above when not using gen- class to compile multiple functions to a single Java class, so it would be possible, but it requires support from the implementation, it cannot be a library function. Cheers, Alessio -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Keyword namespaces
Considering that the only effect of adding a namespace to keyword is to ensure it doesn't inadvertently equal some other keyword (e.g., :a- ns/foo doesn't equal :foo nor :b/foo), I'm not clear on what kind of conflation you're concerned about. Also note that the namespace portion of a keyword does not get resolved against the current aliases. E.g., user= (require '[clojure.java.io :as io]) nil user= (= :io/foo :clojure.java.io/foo) false On Sep 19, 1:06 pm, Kyle Schaffrick k...@raidi.us wrote: On Sun, 19 Sep 2010 12:22:54 -0700 (PDT) ataggart alex.tagg...@gmail.com wrote: Unlike symbols, keywords just evaluate to themselves. The keyword :foo will not collide with a var foo, likewise keyword :my-ns/foo will not collide with var my-ns/foo. So, if I understand you correctly, :xsl/ value-of would work just fine. Right, I understand that the keyword and the symbol themselves are distinct. I guess what I'm asking about is the meaning of their namespaces to the evaluator, and probably is best illustrated like this: user= (require '[some.library :as xsl]) nil ;; now the namespace xsl has semantic meaning on symbols when ;; they're evaluated in this context: user= #'xsl/value-of #'some.library/value-of Is there any situation where, in that examaple, the namespace xsl on a keyword such as :xsl/value-of might be conflated with the namespace alias xsl that I created with require? Or, does Clojure consider keyword namespaces to be completely meaningless and opaque, the same as it does with their names? I can't find any situation where the two blur together except for the ::keyword syntax, but I suspect this is nothing more than a superficial syntactic trick. Still, I want to make sure I'm not missing something. -Kyle On Sep 19, 11:56 am, Kyle Schaffrick k...@raidi.us wrote: Would it be correct to say that the namespace portions of keywords are semantically opaque? In other words, if I have a keyword :my-ns/foo and a symbol 'my-ns/foo, obviously the namespace in the symbol has semantic meaning to the language when it's evaluated (or syntax-quoted), but the namespace of the keyword does not appear carry that meaning, almost as if they are in two separate meta-namespaces. Is that pretty much guaranteed as far as the language is concerned? I'm asking because I've become the latest in the line of Clojurians to go tilting at the SXML-in-Clojure windmill, and if I decide use the namespace portion of a keyword (for example :xsl/value-of) I want to be certain it's always distinct in meaning from any Clojure namespaces or aliases of the same name. The code I teased apart into this library currently uses keywords like :xsl:value-of to distinguish XML namespaces from Clojure namespaces, just as a matter of that was the first thing I thought of, but it would certainly be saner to stop wasting effort splitting them apart by hand with string munging and simply bestow my own meaning on the keywords' namespaces if the language itself doesn't give them any meaning. Thanks, -Kyle -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Keyword namespaces
Hi, Am 19.09.2010 um 22:59 schrieb ataggart: Also note that the namespace portion of a keyword does not get resolved against the current aliases. E.g., user= (require '[clojure.java.io :as io]) nil user= (= :io/foo :clojure.java.io/foo) false It does with ::. user= (= ::io/foo :clojure.java.io/foo) true Sincerely Meikel -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this 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
Isn't STM good at building an ant colony?
Hi. I posted following question. The more threads that changes the Clojure's ref are, the more does the rate of retries per threads rise? http://stackoverflow.com/questions/3746893/the-more-threads-that-changes-the-clojures-ref-are-the-more-does-the-rate-of-re I think increasing retries in O(thread^2) means that refs should not be used to store the data that is aletered by too many threads like big ant colony map or newral network nodes. If modifying the data by too many threads is planned, instead of refs, are agents best way to store it? Any other solution? Thanks. Takahiro Hozumi -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: why the big difference in speed?
What is the definition of microbench? -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: why the big difference in speed?
Microbench is a little utility I wrote that executes a piece of code for awhile to warm up, then records timings for as many runs as will fit in a preset time limit and reports statistics. So the numbers you see are min/median/max milleseconds per run, and number of runs that fit in 3 seconds of real time. Now that clojure.contrib.profile exists, you could use that to similar effect. But if you want my microbench, it's here http://gist.github.com/587199 (not the cleanest implementation, but it works). -Jason On Sep 19, 3:48 pm, Mike K mbk.li...@gmail.com wrote: What is the definition of microbench? -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this 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
trace facility?
In common lisp I can say (trace foo) and it will print out the arguments and the return value of calls to foo. Would it be possible to create such a facility in clojure, perhaps by defining a new class loader? Java knows the types of the arguments and the return values so it should be possible to wrap a function call with a tracer. If the class loader inspected the byte codes it should be possible to write a trace wrapper. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: trace facility?
On Sun, 19 Sep 2010 16:33:54 -0700 (PDT) TimDaly d...@axiom-developer.org wrote: In common lisp I can say (trace foo) and it will print out the arguments and the return value of calls to foo. Would it be possible to create such a facility in clojure, perhaps by defining a new class loader? Java knows the types of the arguments and the return values so it should be possible to wrap a function call with a tracer. If the class loader inspected the byte codes it should be possible to write a trace wrapper. It already exists - it's clojure.contrib.trace (or was - it may have moved in 1.2). Usage is (dotrace [foo ...] (expression)) and it traces the foo and ... functions while evaluating (expression). mike -- Mike Meyer m...@mired.org http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. O ascii ribbon campaign - stop html mail - www.asciiribbon.org -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Displaying source of function typed into the REPL?
If you use emacs, incremental back search is handy. Typing C-r defn, you may jump to the defnition of a function. Next time, you need to type only C-r C-r. -- Takahiro Hozumi On 9月19日, 午前6:39, Sean Corfield seancorfi...@gmail.com wrote: OK, this feels like a really dumb question... I'm playing around in the REPL, I type in a function, I use it and continue to work on other stuff... I can't remember what the function looked like and I want to display the source of it again... I know I can go back through the REPL history but maybe I typed it in ages ago or maybe I typed it on multiple lines so it's hard to piece together from the history. That seems like hard work. I know I can go directly to the .jline-clojure.main.history file in my home directory. That seems like cheating (and it means I have to jump out of the REPL and hunt thru the file). I know I can use (source sym) to get the source of something whose .clj is on the classpath - that doesn't work for stuff typed directly into the REPL. Is there something easy within the REPL to show the source of something you defined earlier? -- Sean A Corfield -- (904) 302-SEAN Railo Technologies, Inc. --http://getrailo.com/ An Architect's View --http://corfield.org/ If you're not annoying somebody, you're not really alive. -- Margaret Atwood -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: why the big difference in speed?
But is the way Clojure works so opaque we need to see byte codes? I was hoping someone on the list would have some intuition about how the expressions get implemented. In fact I hope it's pretty close to what I would naively guess from just reading the code as is. One of the advantages of lisp is that there is a very clear connection between the code and the mental model of how the code is implemented. With a little experience it is easy to infer what machine language code will be generated. Once that becomes second nature it is easy to see what optimizations can be made (e.g. when to use declare). This becomes useful in numeric examples where you can get vastly improved code by adding declarations. If you look at the generated machine code you can compare it directly to, say, a fortran implementation of the same code. This is also true of Java code if you look at the generated byte code. I'm sure that Rich has a very strong sense of what the machine is doing underneath his code, otherwise why would there be a 32-trie optimization? How could he know if the transactions were correct? How would he find where the real optimizations matter? I know that Java will perform certain run-time optimizations but I consider these part of the hardware of the JVM. The real CPU does similar optimizations, out-of-order execution, integer pipelining, cache-fetching, branch optimization, micro-op reordering, register renaming, etc. You can't depend on them from machine to machine. However, given the same javac compiler you can depend on the generated code being the same. For some optimizations see www.hpjava.org/pcrc/doc/rochester/rochester.pdf The way to develop intuition about Clojure is to see what the JVM will do. If you program for a living there should be no magic. I would guess, not having seen your code, that the most likely problem is that your numbers are boxed and you're spending time unboxing/reboxing. See http://www.bestinclass.dk/index.clj/2010/03/functional-fluid-dynamics-in-clojure.html He shows a couple macros for aget! and aset! which might help. There was also a long thread about boxing based on Rich's fast numerics branch. I expect others will disagree about the magic, of course, and I'm not trying to start a flame-war. Some programmers I have worked with did not know what byte codes were and they were still able to generate code (curiously they tended to be design pattern programmers so there may be a connection). See http://dj-java-decompiler.software.informer.com/3.9 for a piece of software that can show the byte codes. There are many others. Tim Daly -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this 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
Making Clojure really work with Google App Engine
I recently spent some time trying to abstract away some of the incidental complexity of using Google App Engine with Clojure. Right now, setting up interactive development and understanding what to do requires reading several blog posts, and pasting in a lot of boilerplate code. I ended up making a small library, called appengine- magic, which cuts the boilerplate down to (1) a single additional .jar dependency, (2) a couple of macros, and (3) a couple of files generated by a Leiningen plugin. It takes a Ring handler, and turns it into an application suitable for App Engine. http://github.com/gcv/appengine-magic It doesn't do everything yet, but I feel that it already makes a much easier starting point than any alternative. The README file explains the details. Unfortunately, I hit a major stumbling block. Live deployment to App Engine does not work because of a dependency importing a blacklisted class. appengine-magic expects to deploy a Ring handler. This makes it possible to write apps using any Ring-compliant Clojure web framework. In order to deploy to App Engine, it needs to turn the handler into a servlet. The ring-servlet library does this with its handy ring.util.servlet/defservice function. The implementation of defservice uses duck-streams/copy. duck-streams imports java.net.Socket, a class blacklisted by App Engine, causing deployment to fail. So any innocuous dependency, which transitively depends on anything which loads a file which imports a blacklisted class, can cause deployment to fail. Even Clojure itself is not entirely safe: for example, duck-streams is now clojure.java.io, which imports java.net.Socket. I can reimplement defservice, and so avoid depending on ring-servlet. Still, the situation seems fragile and precarious. Suggestions and comments welcome. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this 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
Is reflection free clojure code possible?
Since there appears to be a version of clojure being made for .Net I was interested in the possibility of programming Xbox games in clojure. I imagine the Xbox doesn't have many of the same limitations that mobile devices have but as I understand it the version of .Net on the Xbox is a compact version that has either anemic or no support for reflection. I know you can use type hints to keep clojure from making function calls with reflection but does that necessarily eliminate all reflection? -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Is reflection free clojure code possible?
With XNA running on the Xbox 360, reflection is the least of your worries. The runtime uses a very poor non-generational mark-and-sweep collector. At the rate of memory allocation in a typical Clojure program, you would be faced with constant GC hitches. Even people writing XNA games in C# (where idiomatic code is much less allocation intense) have to be very careful with allocations and will tend to use preallocated object pools for virtually everything. -Per On Mon, Sep 20, 2010 at 8:55 AM, Jarl Haggerty fictivela...@gmail.com wrote: Since there appears to be a version of clojure being made for .Net I was interested in the possibility of programming Xbox games in clojure. I imagine the Xbox doesn't have many of the same limitations that mobile devices have but as I understand it the version of .Net on the Xbox is a compact version that has either anemic or no support for reflection. I know you can use type hints to keep clojure from making function calls with reflection but does that necessarily eliminate all reflection? -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Displaying source of function typed into the REPL?
That also sounds pretty useful for development. I may try that as an exercise... This weekend has been a journey through The Joy of Clojure. I read about 100 pages on Friday evening (easy going), 150 pages on Saturday (harder going - more complex topics). Today I read another 50 pages, skipped chapters 11 12 (brain too full to process - about 80 pages) and read chapter 13 (about 20 pages). All the time I had a REPL open and kept copy'n'pasting examples in and playing with them to get a feel for it. It's been a really fun weekend! Now, unfortunately, I must get chores (and work!) done before the week starts. See some of you at the JavaOne Clojure meetup tomorrow (Monday)? On Sun, Sep 19, 2010 at 6:11 PM, jlk lachlan.kana...@gmail.com wrote: Not sure how practical it is, but a while back I was playing around with a macro redefining defn so that it stored the function source in the meta-data of the function. I can't find it now but remember it being fairly trivial to implement. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Can resultset-seq blow the stack?
On Sep 19, 2010, at 3:45 PM, Shantanu Kumar wrote: I simulated a similar recursive call and found it throws StackOverflowError at 5508 levels deep on a 32-bit Sun JVM (not server mode) on Windows 7. Did your similar recursion include the lazy-seq form that wraps the (apparently) recursive call? Each invocation of lazy-seq results in one call to the code it wraps that's delayed until its value is requested. The invocations do not end up nested on the stack. Instead they are executed one by one as calling code steps through the lazy sequence. --Steve -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this 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
