Re: Parsing parameters in clojure.core
It would be nice if the compiler handled these things with greater cleverness. In the mean time, some macros might be in order. I'd also like to add that clojure.core is not generally an exemplar of style. :) -Per On Wed, Mar 24, 2010 at 11:58 PM, Sean Devlin francoisdev...@gmail.com wrote: It's a (drastic) performance improvement. The magic number of 3 appears to cover a lot of use cases. Once you get larger than three, it typically is a large number of inputs, i.e. the tail flattens off. On Mar 23, 5:00 pm, Thomas thomas.g.kristen...@gmail.com wrote: Hi all, I've been reading through clojure.core to see examples of fine clojure style. One thing I've noticed is (what I consider) a weird notation when parsing parameters for function. As an example, consider the function juxt: (defn juxt Alpha - name subject to change. Takes a set of functions and returns a fn that is the juxtaposition of those fns. The returned fn takes a variable number of args, and returns a vector containing the result of applying each fn to the args (left-to-right). ((juxt a b c) x) = [(a x) (b x) (c x)] ([f] (fn ([] [(f)]) ([x] [(f x)]) ([x y] [(f x y)]) ([x y z] [(f x y z)]) ([x y z args] [(apply f x y z args)]))) [ rest of juxt is omitted for brevity ] I don't understand why there needs to be a case for [x], [x y], [x y z] and [x y z args]. Why not just [args]? And why the magic number (three) of variables? Thomas -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
Re: ANN: labrepl, making Clojure more accessible
On 25 Mar, 01:16, Mark Engelberg mark.engelb...@gmail.com wrote: I tried following Rob Wolfe's zip file instructions. The bin\lein deps command seemed to work fine, but when I then invoked bin\repl, I got the following error: [...] brepl-0.0.1.jar;C:\labrepl-package\core\leiningen-1.1.0-standalone.jar;.;C :\Pro gram Files\Java\jre6\lib\ext\QTJava.zip;src;test;config;data Exception in thread main java.lang.NoClassDefFoundError: Files\Java\jre6\lib\e xt\QTJava/zip;src;test;config;data Caused by: java.lang.ClassNotFoundException: Files\Java\jre6\lib\ext\QTJava.zip; src;test;config;data Yeah, there is a bug in repl.bat. This error occurs when there is a path with spaces on class path. Change this line in repl.bat: set CLASSPATH=%CPLIB%;%CPCORE%;%CLASSPATH%;src;test;config;data like this: set CLASSPATH=%CPLIB%;%CPCORE%;%CLASSPATH%;src;test;config;data (note quotation marks around %CLASSPATH%) HTH, Rob -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
Re: Beginning Clojure. Recursion
jfr wrote: Hello, I've just started to play a little bit with clojure to get a feel for the language. It seems to be quite interesting (and it's a relief to leave my clumsy IDE behind and use Emacs). Concerning immutable data: Is the following code ok or should (must) I use transients as variables for the loop? Transients are merely a performance optimisation, and they're designed so that you can use them just like you would use persistent data structures. Therefore it's good to always start with purely functional algorithms. The code you wrote is idiomatic, though it could perhaps be improved by not looping explicitly and instead using eg. reduce. It's also fairly straightforward to transform to use transients, should performance turn out to be suboptimal. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
Re: Can't call public method of non-public class
Is this it? http://www.assembla.com/spaces/clojure/tickets/259 On Mar 23, 8:26 pm, Mark J. Reed markjr...@gmail.com wrote: As far as I can tell, you're doing nothing wrong and just hitting a bug in Clojure. Which is still in 1.2.0-master... On Tue, Mar 23, 2010 at 11:43 AM, Konstantin Barskiy zuftw...@gmail.com wrote: I'm trying to reproduce ProcessBuilder example from java documentation http://java.sun.com/javase/6/docs/api/java/lang/ProcessBuilder.html This is that example: ProcessBuilder pb = new ProcessBuilder(myCommand, myArg1, myArg2); MapString, String env = pb.environment(); env.put(VAR1, myValue); env.remove(OTHERVAR); env.put(VAR2, env.get(VAR1) + suffix); pb.directory(new File(myDir)); Process p = pb.start(); I'm typing folowing in clojure repl: D:\Users\Konstantinjava -jar clojure.jar Clojure 1.1.0 user= (def pb (new ProcessBuilder [myCommand myArg])) #'user/pb user= (def env (.environment pb)) #'user/env user= (.put env VAR1, myValue) java.lang.IllegalArgumentException: Can't call public method of non- public class: public java.lang.String java.lang.ProcessEnvironment.put(java.lang.String,java.lang.String) (NO_SOURCE_FILE:0) What does this error mean and what i am doing wrong? -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject. -- Mark J. Reed markjr...@gmail.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 To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
Re: Nubie Question
I thank all the people who have sent me solutions to my Conj problem. Unfortunately, none of them seem to work. The issue is adding a value to a defined vector - (def savedColors [black, white]) One solution was given as: (swap! savedColors conj newcolor) This produces still the following runtime error: Exception in thread AWT-EventQueue-0 java.lang.ClassCastException: clojure.lang.PersistentVector cannot be cast to clojure.lang.Atom Another solution was to make savedColors an atom - (def savedColors (atom [black, white])) This produces a new compile error: Exception in thread AWT-EventQueue-0 java.lang.IllegalArgumentException: Don't know how to create ISeq from: clojure.lang.Atom Changing savedColors to a list instead of a vector gets the same error. The atom example on the web is for a map. I'm sure this can be done. So far I just don't know how. Bill -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
Re: Nubie Question
On Thu, Mar 25, 2010 at 6:52 PM, WoodHacker ramsa...@comcast.net wrote: I thank all the people who have sent me solutions to my Conj problem. Unfortunately, none of them seem to work. The issue is adding a value to a defined vector - (def savedColors [black, white]) One solution was given as: (swap! savedColors conj newcolor) This produces still the following runtime error: Exception in thread AWT-EventQueue-0 java.lang.ClassCastException: clojure.lang.PersistentVector cannot be cast to clojure.lang.Atom Another solution was to make savedColors an atom - (def savedColors (atom [black, white])) This produces a new compile error: Exception in thread AWT-EventQueue-0 java.lang.IllegalArgumentException: Don't know how to create ISeq from: clojure.lang.Atom The def cannot produce that error. You probably mean that it originates with some reference to savedColors that is expecting a sequence. You must explicitly dereference savedColors by prefixing it with @ to get at the contained value: user (def saved-colors (atom [1, 2])) #'user/saved-colors user (doseq [x @saved-colors] (println Saved color: x)) Saved color: 1 Saved color: 2 nil -Per -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
Re: Named arguments in HEAD and prettier default arguments for :keys destructuring
Hi,
I've no idea whether this is reasonable but when I read your post
suddenly the following thought appeared...
What if defn would accept either a vector for the parameters or a map?
(defn foo {:dont know :what for}
;; ...
)
I did no deeper thinking on this at all, er, skip the deeper, I
guess. :-)
Cheers,
Stefan
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
To unsubscribe from this group, send email to
clojure+unsubscribegooglegroups.com or reply to this email with the words
REMOVE ME as the subject.
Benefit of declarative functional UI in Clojure?
Would a Clojure app benefit sigificantly from a declarative functional UI along the lines of Lunascript http://www.asana.com/luna or FlapJax http://www.flapjax-lang.org/ ? The results look quite impressive ... but I don't have much to compare to in Clojure. I am relatively new to both Clojure and the functional- reactive programming approach, so looking for some hints on whether it is worth exploring deeply. Thanks! -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
Re: Can't call public method of non-public class
That's the one. But the solution given by the bug reporter doesn't address the case that came up on this thread, since it's not the class of the invocant but the types of the parameters that prevent the match from being found. On Thu, Mar 25, 2010 at 7:06 AM, atucker agjf.tuc...@googlemail.com wrote: Is this it? http://www.assembla.com/spaces/clojure/tickets/259 On Mar 23, 8:26 pm, Mark J. Reed markjr...@gmail.com wrote: As far as I can tell, you're doing nothing wrong and just hitting a bug in Clojure. Which is still in 1.2.0-master... On Tue, Mar 23, 2010 at 11:43 AM, Konstantin Barskiy zuftw...@gmail.com wrote: I'm trying to reproduce ProcessBuilder example from java documentation http://java.sun.com/javase/6/docs/api/java/lang/ProcessBuilder.html This is that example: ProcessBuilder pb = new ProcessBuilder(myCommand, myArg1, myArg2); MapString, String env = pb.environment(); env.put(VAR1, myValue); env.remove(OTHERVAR); env.put(VAR2, env.get(VAR1) + suffix); pb.directory(new File(myDir)); Process p = pb.start(); I'm typing folowing in clojure repl: D:\Users\Konstantinjava -jar clojure.jar Clojure 1.1.0 user= (def pb (new ProcessBuilder [myCommand myArg])) #'user/pb user= (def env (.environment pb)) #'user/env user= (.put env VAR1, myValue) java.lang.IllegalArgumentException: Can't call public method of non- public class: public java.lang.String java.lang.ProcessEnvironment.put(java.lang.String,java.lang.String) (NO_SOURCE_FILE:0) What does this error mean and what i am doing wrong? -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject. -- Mark J. Reed markjr...@gmail.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 To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject. -- Mark J. Reed markjr...@gmail.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 To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
Re: Named arguments in HEAD and prettier default arguments for :keys destructuring
Hi,
Interesting. Seems more readable, more DRY, indeed. Especially if this
becomes idiomatic for optional named arguments ...
And the general case could be:
(defn funkymonkey [x y z {:keys [[a -1] [b -2] [c -3]], d :d, e [:e
-4], :or {b -3, g -6}} [x y z a b c])
?
Which leads to the question: which default value wins for b ? :)
2010/3/24 Per Vognsen per.vogn...@gmail.com:
Those of you following the clojure repo on GitHub may have noticed this
commit:
http://github.com/richhickey/clojure/commit/29389970bcd41998359681d9a4a20ee391a1e07c
Now you can do things like this:
user= (defn funkymonkey [x y z {:keys [a b c]}] [x y z a b c])
#'user/funkymonkey
user= (funkymonkey 1 2 3)
[1 2 3 nil nil nil]
user= (funkymonkey 1 2 3 :b 5)
[1 2 3 nil 5 nil]
user= (funkymonkey 1 2 3 :c 6 :a 4 :b 5)
[1 2 3 4 5 6]
Very nice! It feels smoothly integrated with the general destructuring
infrastructure. You can also supply default values with the :or
binder:
user= (defn funkymonkey [x y z {:keys [a b c] :or {a -1 b -2 c -3}]
[x y z a b c])
#'user/funkymonkey
user= (funkymonkey 1 2 3)
[1 2 3 -1 -2 -3]
user= (funkymonkey 1 2 3 :b 5)
[1 2 3 -1 5 -3]
The great thing about :keys is that it cuts down on redundancy: you
specify a symbol only once and it is dually interpreted as a map
keyword and a lexically bound symbol. Since :keys already expects a
flat sequence of symbols rather than arbitrary nested binding forms
(otherwise this trick of dual interpretation wouldn't work), you could
further cut down on the redundancy in the above :keys/:or idiom (which
I expect would become commonplace with named arguments) by letting
:keys elements optionally be two-element vectors with the second
element supplying the default value:
user= (defn funkymonkey [x y z {:keys [[a -1] [b -2] [c -3]]] [x y z a b
c])
What do you think? I hacked this into my local version of core.clj's
destructure and it feels very natural to me.
-Per
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
To unsubscribe from this group, send email to
clojure+unsubscribegooglegroups.com or reply to this email with the words
REMOVE ME as the subject.
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
To unsubscribe from this group, send email to
clojure+unsubscribegooglegroups.com or reply to this email with the words
REMOVE ME as the subject.
Re: web starting clojure apps without Java code
I fixed a couple of other issues, most of which show only on Windows. You should see Kanjis now on the right-hand side when drawing. Eugen On Mar 23, 5:30 pm, Zmitro Lapcjonak idob...@gmail.com wrote: On Mar 17, 4:56 pm, Eugen Dück eu...@dueck.org wrote: The complete jnlp can be found athttp://dueck.org/kanshiki-boom/. I plan to introduce and document this beta-grade app soon, but if there's any Japanese learner out there interested in or in need of Kanji handwriting recognition, check it out, but please hold back with any bug reports etc. until I have introduced it. i started and tryed a little the app. it downloaded (something from your site) then i was able to draw. i drawed some basic kanji (even those found in unistrok.data) pressed left button (the right works as undo). but observed no reply from the app. so, lets wait untill you anonce not-beta state of your app. good luck! -- zmitro lapcionak -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
Re: Nubie Question
Right. Let's make this clear: outside of the Java interoperability stuff, you cannot change the value of a variable in Clojure. Ever. All the data types are immutable; you can only build new values on top of existing ones, not modify the old ones. When you conj something onto a vector, it doesn't change that vector; it returns a new vector. The new vector reuses the old one's memory for efficiency, but if you look at the old one it doesn't have the new member. It's unchanged. What can change are references. So you can make a reference to the vector, and then build a new vector with the new items, and then change the reference to point to the new vector. That's what (swap!) does. But you have to have a reference to start with. Which (atom) gives you. But a reference is not the same as a vector; you can't use it directly when you need a vector, but must dereference it with @. Example: Clojure 1.1.0 user= (def start-colors [:black :white]) #'user/start-colors user= (def saved-colors (atom start-colors)) #'user/saved-colors user= start-colors [:black :white] user= @saved-colors [:black :white] user= (swap! saved-colors conj :red) [:black :white :red] user= start-colors [:black :white] user= saved-colors #a...@1d256fa: [:black :white :red] user= @saved-colors [:black :white :red] user= -- Mark J. Reed markjr...@gmail.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 To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
Re: Parsing parameters in clojure.core
I agreed with you until I had to go over every single line of the thing, in order. It actually reads pretty well from top to bottom. Then again, some functions are by necessity just plain nasty. On Mar 25, 2:02 am, Per Vognsen per.vogn...@gmail.com wrote: It would be nice if the compiler handled these things with greater cleverness. In the mean time, some macros might be in order. I'd also like to add that clojure.core is not generally an exemplar of style. :) -Per On Wed, Mar 24, 2010 at 11:58 PM, Sean Devlin francoisdev...@gmail.com wrote: It's a (drastic) performance improvement. The magic number of 3 appears to cover a lot of use cases. Once you get larger than three, it typically is a large number of inputs, i.e. the tail flattens off. On Mar 23, 5:00 pm, Thomas thomas.g.kristen...@gmail.com wrote: Hi all, I've been reading through clojure.core to see examples of fine clojure style. One thing I've noticed is (what I consider) a weird notation when parsing parameters for function. As an example, consider the function juxt: (defn juxt Alpha - name subject to change. Takes a set of functions and returns a fn that is the juxtaposition of those fns. The returned fn takes a variable number of args, and returns a vector containing the result of applying each fn to the args (left-to-right). ((juxt a b c) x) = [(a x) (b x) (c x)] ([f] (fn ([] [(f)]) ([x] [(f x)]) ([x y] [(f x y)]) ([x y z] [(f x y z)]) ([x y z args] [(apply f x y z args)]))) [ rest of juxt is omitted for brevity ] I don't understand why there needs to be a case for [x], [x y], [x y z] and [x y z args]. Why not just [args]? And why the magic number (three) of variables? Thomas -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
database management: curing lock issues
Question on best practices on handling SQL database concurrency issues I am pmapping a evaluation to a long list (which calls a computationally intense script) from within clojure. The script itself is designed to be completely free of concurrency side-effects. During the evaluation, several calculations are made that are then written to a SQLite database. My approach is to test for concurrency issues on a dual core system prior to moving to a cluster. What I find is that on occasion there is a database locking issue when sub-processes try to write to the database at the same time (java.sql.SQLException: database is locked). The side effect is that one of the evaluations is not written to the database (bad, cause it takes 3min to compute). I can fix it by catching the exception, and then calling (Thread/sleep) before trying to rewrite again. This is an ugly fix, and I am concerned that this may not scale properly. What is the best practices to handle such an issue in a concurrent and scalable way? Is it as simple as moving to a better database, such as mySQL? I could use Threads/Locks and move the db transaction outside the evaluation loop, or save all transactions and then commit after all evaluations are done. I can't help but feel both solns seem like cheating when working with a conncurrent language such as clojure. Any Advice? I am using contrib.sql and java.sql (org.sqlite.JDBC) -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
Re: database management: curing lock issues
Isn't programming not all about cheating the computer in doing what you want it to do? In the book programming clojure you can find an example with locks as well. 2010/3/25 Scott sbuck...@gmail.com Question on best practices on handling SQL database concurrency issues I am pmapping a evaluation to a long list (which calls a computationally intense script) from within clojure. The script itself is designed to be completely free of concurrency side-effects. During the evaluation, several calculations are made that are then written to a SQLite database. My approach is to test for concurrency issues on a dual core system prior to moving to a cluster. What I find is that on occasion there is a database locking issue when sub-processes try to write to the database at the same time (java.sql.SQLException: database is locked). The side effect is that one of the evaluations is not written to the database (bad, cause it takes 3min to compute). I can fix it by catching the exception, and then calling (Thread/sleep) before trying to rewrite again. This is an ugly fix, and I am concerned that this may not scale properly. What is the best practices to handle such an issue in a concurrent and scalable way? Is it as simple as moving to a better database, such as mySQL? I could use Threads/Locks and move the db transaction outside the evaluation loop, or save all transactions and then commit after all evaluations are done. I can't help but feel both solns seem like cheating when working with a conncurrent language such as clojure. Any Advice? I am using contrib.sql and java.sql (org.sqlite.JDBC) -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.comclojure%2bunsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en To unsubscribe from this group, send email to clojure+ unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject. -- Communication is essential. So we need decent tools when communication is lacking, when language capability is hard to acquire... - http://esperanto.net - http://esperanto-jongeren.nl Linux-user #496644 (http://counter.li.org) - first touch of linux in 2004 -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
Re: database management: curing lock issues
id prefer best practices if possible typically, cheating has consequences down the line On Mar 25, 10:43 am, Joop Kiefte iko...@gmail.com wrote: Isn't programming not all about cheating the computer in doing what you want it to do? In the book programming clojure you can find an example with locks as well. 2010/3/25 Scott sbuck...@gmail.com Question on best practices on handling SQL database concurrency issues I am pmapping a evaluation to a long list (which calls a computationally intense script) from within clojure. The script itself is designed to be completely free of concurrency side-effects. During the evaluation, several calculations are made that are then written to a SQLite database. My approach is to test for concurrency issues on a dual core system prior to moving to a cluster. What I find is that on occasion there is a database locking issue when sub-processes try to write to the database at the same time (java.sql.SQLException: database is locked). The side effect is that one of the evaluations is not written to the database (bad, cause it takes 3min to compute). I can fix it by catching the exception, and then calling (Thread/sleep) before trying to rewrite again. This is an ugly fix, and I am concerned that this may not scale properly. What is the best practices to handle such an issue in a concurrent and scalable way? Is it as simple as moving to a better database, such as mySQL? I could use Threads/Locks and move the db transaction outside the evaluation loop, or save all transactions and then commit after all evaluations are done. I can't help but feel both solns seem like cheating when working with a conncurrent language such as clojure. Any Advice? I am using contrib.sql and java.sql (org.sqlite.JDBC) -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.comclojure%2bunsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en To unsubscribe from this group, send email to clojure+ unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject. -- Communication is essential. So we need decent tools when communication is lacking, when language capability is hard to acquire... -http://esperanto.net -http://esperanto-jongeren.nl Linux-user #496644 (http://counter.li.org) - first touch of linux in 2004 -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
Re: database management: curing lock issues
Are the writes commutative? Since you are using pmap, I presume so. In that case, you could funnel the writes through an agent serving as a queue. -Per On Thu, Mar 25, 2010 at 9:59 PM, Scott sbuck...@gmail.com wrote: id prefer best practices if possible typically, cheating has consequences down the line On Mar 25, 10:43 am, Joop Kiefte iko...@gmail.com wrote: Isn't programming not all about cheating the computer in doing what you want it to do? In the book programming clojure you can find an example with locks as well. 2010/3/25 Scott sbuck...@gmail.com Question on best practices on handling SQL database concurrency issues I am pmapping a evaluation to a long list (which calls a computationally intense script) from within clojure. The script itself is designed to be completely free of concurrency side-effects. During the evaluation, several calculations are made that are then written to a SQLite database. My approach is to test for concurrency issues on a dual core system prior to moving to a cluster. What I find is that on occasion there is a database locking issue when sub-processes try to write to the database at the same time (java.sql.SQLException: database is locked). The side effect is that one of the evaluations is not written to the database (bad, cause it takes 3min to compute). I can fix it by catching the exception, and then calling (Thread/sleep) before trying to rewrite again. This is an ugly fix, and I am concerned that this may not scale properly. What is the best practices to handle such an issue in a concurrent and scalable way? Is it as simple as moving to a better database, such as mySQL? I could use Threads/Locks and move the db transaction outside the evaluation loop, or save all transactions and then commit after all evaluations are done. I can't help but feel both solns seem like cheating when working with a conncurrent language such as clojure. Any Advice? I am using contrib.sql and java.sql (org.sqlite.JDBC) -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.comclojure%2bunsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en To unsubscribe from this group, send email to clojure+ unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject. -- Communication is essential. So we need decent tools when communication is lacking, when language capability is hard to acquire... -http://esperanto.net -http://esperanto-jongeren.nl Linux-user #496644 (http://counter.li.org) - first touch of linux in 2004 -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
Re: database management: curing lock issues
Hi, maybe you can put finished work packages into a Queue and have a (different) thread reading them from the queue and writing them to the database linearly. So the workers don't have to know about the database and the DB writer doesn't have to care for the computation. Since you can't write to the database in parallel anyway, you don't loose anything, no? See java.util.concurrent for different Queue implementations, as well as CLojure PersistentQueue combined with an atom and watchers or so. (Although I think j.u.c.ArrayBlockingQueue looks interesting for this approach) Disclaimer: I'm not a specialist with this stuff. So take an appropriate amount of salt for evaluation. 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 To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
Re: Beginning Clojure. Recursion
Ok, I just looked at frequencies as Miki suggested.
(reduce #(assoc %1 %2 (inc (get %1 %2 0))) {} [One Two Two
Three Three Three])
would be more like it. Thanks for the infos...
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
To unsubscribe from this group, send email to
clojure+unsubscribegooglegroups.com or reply to this email with the words
REMOVE ME as the subject.
Re: Beginning Clojure. Recursion
Thanks I will take a look at it .Neverless, the idea was to write my own code ;-) You can also use frequencies from c.c.seq-utils (http:// richhickey.github.com/clojure-contrib/seq-api.html#clojure.contrib.seq/ frequencies) HTH, -- Miki -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
Re: database management: curing lock issues
I would suggest using a more concurrency-aware database. I've had luck with H2 (http://www.h2database.com/). It supports mixed local and remote connections in a thread-safe manner. Additionally it supports simple clustering, sounds like you could have use for such. Best Regards, Joonas -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
Re: database management: curing lock issues
Is it as simple as moving to a better database, such as mySQL? PostgreSQL is considerably better (even than MySQL, which still uses locks AFAIK) for anything concurrent. The PostgreSQL is using multiple version concurrency (MVC) approach - the same approach the clojure STM is using. The PostgreSQL might need a bit of tuning (the defaults are very conservative), but after that it usually performs very well. Make sure that you understand the PostgreSQL transactions and how they work, but usually - in default settings, the readers do not block writers, and readers always see consistent view of the data (but this view could be a bit behind in terms of time). The PostgreSQL mailing list is both, friendly and knowledgeable - speaking from experience. Kind regards, Vladimir -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
Re: database management: curing lock issues
thanks for your suggestions two clear options 1) agents and queued transactions 2) MVC enabled databases (postgresql, h2 (neat project)) Ill try the first option and see how it scales, and worst case move to the second Thanks again Scott On Mar 25, 12:47 pm, prhlava prhl...@googlemail.com wrote: Is it as simple as moving to a better database, such as mySQL? PostgreSQL is considerably better (even than MySQL, which still uses locks AFAIK) for anything concurrent. The PostgreSQL is using multiple version concurrency (MVC) approach - the same approach the clojure STM is using. The PostgreSQL might need a bit of tuning (the defaults are very conservative), but after that it usually performs very well. Make sure that you understand the PostgreSQL transactions and how they work, but usually - in default settings, the readers do not block writers, and readers always see consistent view of the data (but this view could be a bit behind in terms of time). The PostgreSQL mailing list is both, friendly and knowledgeable - speaking from experience. Kind regards, Vladimir -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
Re: Clojure/LLVM
I know it's not Clojure, but you can at least scratch the Lisp on the iP* itch. Scheme for the iPhone: http://jlongster.com/software/iphone/scheme-iphone-example/ http://jlongster.com/blog/2010/02/23/farmageddon/ -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
Choosing a Clojure build tool
I published a blog post earlier today, along with a short screencast that might be of interest: Like any group of super-smart programmers using a relatively new language, a lot of folks in the Clojure community have looked at existing build tools (the JVM space is the relevant one here, meaning primarily Maven and Ant, although someone will bark if I don't mention Gradle, too), and felt a rush of disdain. I'd speculate that this came mostly because of XML allergies, but perhaps also in part because when one has a hammer as glorious as Clojure, it's hard to not want to use it to beat away at every problem in sight. Read on: http://muckandbrass.com/web/x/AgBV Feedback welcome, either here or in the comments on the post. Cheers, - Chas -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
Re: Choosing a Clojure build tool
Chas Emerick cemer...@snowtide.com writes: I published a blog post earlier today, along with a short screencast that might be of interest: Like any group of super-smart programmers using a relatively new language, a lot of folks in the Clojure community have looked at existing build tools (the JVM space is the relevant one here, meaning primarily Maven and Ant, although someone will bark if I don't mention Gradle, too), and felt a rush of disdain. I'd speculate that this came mostly because of XML allergies, but perhaps also in part because when one has a hammer as glorious as Clojure, it's hard to not want to use it to beat away at every problem in sight. Read on: http://muckandbrass.com/web/x/AgBV Feedback welcome, either here or in the comments on the post. No, XML is not the worst thing (at least for me). The real problem is here: http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html Let's suppose that from time to time I'd like to package a few class files (e.g. Java subpackage) to jar without repeated compilation and without running tests of the whole project? How to do that with Maven? It should be easy, right? Are you sure that it is a no-brainer? Br, Rob -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
Re: Choosing a Clojure build tool
On Mar 25, 11:55 am, Chas Emerick cemer...@snowtide.com wrote: I published a blog post earlier today, along with a short screencast that might be of interest: Like any group of super-smart programmers using a relatively new language, a lot of folks in the Clojure community have looked at existing build tools (the JVM space is the relevant one here, meaning primarily Maven and Ant, although someone will bark if I don't mention Gradle, too), and felt a rush of disdain. I'd speculate that this came mostly because of XML allergies, but perhaps also in part because when one has a hammer as glorious as Clojure, it's hard to not want to use it to beat away at every problem in sight. Ruby: gem install X Perl: perl -MCPAN -e shell, then install X Why does building and installing dependencies have to be harder than this? Lein right now tries to fill this niche of being braindead easy to use, and comes pretty close. I realize Maven does a lot more than build and install dependencies, but for some of us, that's all we want out of life, and it's pretty nice when it's that easy to do so. My dream tool would be: 1) Platform-agnostic (for us sorry souls stuck on Windows at work) 2) IDE-agnostic (make a Netbeans project is great, but Emacs users need some love too) 3) Easy to understand and use for the kinds of tasks Lein covers (I don't want to have to study a Maven book(!) if I can avoid it) 4) Able to handle most or all Clojure and Java libraries I want to install (I don't want to have to circumvent the build tool and do things manually if I can help it) 5) Able to easily browse or search for packages in remote repositories, would be nice Rubygems and Perl's CPAN can handle those kinds of things, for example. If Maven can be those things, I'll have an XML sandwich for lunch with a smile if necessary. : ) Maybe it can and the community just needs to standardize around Maven and provide good documentation and community support for using it with Clojure. I just hope the community standardizes around something; any standard is better than everyone using a different tool. Thanks --Brian -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
Re: Choosing a Clojure build tool
On Mar 25, 2010, at 6:08 PM, Rob Wolfe wrote: No, XML is not the worst thing (at least for me). The real problem is here: http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html I'm not sure what you're referring to there. :-) Let's suppose that from time to time I'd like to package a few class files (e.g. Java subpackage) to jar without repeated compilation and without running tests of the whole project? How to do that with Maven? It should be easy, right? Are you sure that it is a no-brainer? You can disable all tests in a maven build with the - Dmaven.test.skip=true option. No compilation will occur if no changes have been made to your source files. - Chas -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
Re: Choosing a Clojure build tool
On Mar 25, 2010, at 19:55 , Chas Emerick wrote: I published a blog post earlier today, along with a short screencast that might be of interest: Like any group of super-smart programmers using a relatively new language, a lot of folks in the Clojure community have looked at existing build tools (the JVM space is the relevant one here, meaning primarily Maven and Ant, although someone will bark if I don't mention Gradle, too), and felt a rush of disdain. I'd speculate that this came mostly because of XML allergies, but perhaps also in part because when one has a hammer as glorious as Clojure, it's hard to not want to use it to beat away at every problem in sight. I slowly get the feeling that build tools are too much in the focus. Why don't we start up with a good shell integration, being able to run clj my script go nice and including dependencies in jars and stuff. Making it easy to work with plain .clj files to include, load, run them would get us a huge way ahead and I think kind of freeing us from what I feel as the burden of the java world. Regards, Heinz -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
converting long string to number
I am trying to convert a long string of numbers to a number, but get a java.lang.numberformatexception My long string of numbers has new line characters in it, so I am filtering out the newline characters before converting it back to a string. Then I try to use Integer. on it but get the above exception. Code is as follows: big-num-str is truncated for space's sake, is actually much much longer!! (def big-num-str 37107287533902102798797998220837590246510135740250 46376937677490009712648124896970078050417018260538 74324986199524741059474233309513058123726617309629 91942213363574161572522430563301811072406154908250 23067588207539346171171980310421047513778063246676 89261670696623633820136378418383684178734361726757 28112879812849979408065481931592621691275889832738 44274228917432520321923589422876796487670272189318 47451445736001306439091167216856844588711603153276 70386486105843025439939619828917593665686757934951) (Integer. (apply str (filter #(Character/isDigit %) big-num-str))) -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
Re: Choosing a Clojure build tool
Brian, FWIW, I'd claim that maven does deliver on all five points you list. Of note is that it absolutely is IDE-agnostic (I used NetBeans in the screencast because that's what I use -- you can load up maven-defined projects in Eclipse and IntelliJ just as easily). I'm not an emacs user, so I'm unsure what love would mean there, but I'd be surprised if there wasn't a maven mode somewhere, etc. The package browsing/searching story is probably the weakest. There's http://mvnrepository.com , which I just found 2 minutes ago. We have an internal Nexus installation (which caches all of the dependencies we've ever retrieved, so that our builds won't fail if the 'net is down, maven central is down, build.clojure.org is down, etc), which provides a very nice search interface. I'm not entirely sure what would be required from clojure-maven-plugin (for example) for maven to achieve greater acceptance in the community...as I mentioned, I'm relatively new to maven myself (~ 6 months in), and I paved the rough spots that I hit, but it's hard to speculate because people's workflows and specific requirements are so different. My guess is that once the Clojure-flavored Polyglot Maven project becomes fully-baked, it will become the de facto standard, as XML allergies really are the biggest deterrent right now IMO. Cheers, - Chas On Mar 25, 2010, at 6:17 PM, Brian Carper wrote: On Mar 25, 11:55 am, Chas Emerick cemer...@snowtide.com wrote: I published a blog post earlier today, along with a short screencast that might be of interest: Like any group of super-smart programmers using a relatively new language, a lot of folks in the Clojure community have looked at existing build tools (the JVM space is the relevant one here, meaning primarily Maven and Ant, although someone will bark if I don't mention Gradle, too), and felt a rush of disdain. I'd speculate that this came mostly because of XML allergies, but perhaps also in part because when one has a hammer as glorious as Clojure, it's hard to not want to use it to beat away at every problem in sight. Ruby: gem install X Perl: perl -MCPAN -e shell, then install X Why does building and installing dependencies have to be harder than this? Lein right now tries to fill this niche of being braindead easy to use, and comes pretty close. I realize Maven does a lot more than build and install dependencies, but for some of us, that's all we want out of life, and it's pretty nice when it's that easy to do so. My dream tool would be: 1) Platform-agnostic (for us sorry souls stuck on Windows at work) 2) IDE-agnostic (make a Netbeans project is great, but Emacs users need some love too) 3) Easy to understand and use for the kinds of tasks Lein covers (I don't want to have to study a Maven book(!) if I can avoid it) 4) Able to handle most or all Clojure and Java libraries I want to install (I don't want to have to circumvent the build tool and do things manually if I can help it) 5) Able to easily browse or search for packages in remote repositories, would be nice Rubygems and Perl's CPAN can handle those kinds of things, for example. If Maven can be those things, I'll have an XML sandwich for lunch with a smile if necessary. : ) Maybe it can and the community just needs to standardize around Maven and provide good documentation and community support for using it with Clojure. I just hope the community standardizes around something; any standard is better than everyone using a different tool. Thanks --Brian -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en To unsubscribe from this group, send email to clojure +unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
Re: converting long string to number
Glen, You want (java.math.BigInteger. 2342343...). java.lang.Integer is limited to 2^31-1. - Chas On Mar 25, 2010, at 6:40 PM, Glen Rubin wrote: I am trying to convert a long string of numbers to a number, but get a java.lang.numberformatexception My long string of numbers has new line characters in it, so I am filtering out the newline characters before converting it back to a string. Then I try to use Integer. on it but get the above exception. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
Re: Help optimizing array-to-integer operation?
On Mar 24, 10:57 am, Mark J. Reed markjr...@gmail.com wrote: On Tue, Mar 23, 2010 at 8:19 PM, Raph mart...@gmail.com wrote: (My opinion, anyway.I think a byte should be 8 bits and I should be able to use all of them.) Er, it is, and you can. A Java byte still gives you all 8 bits' worth of 256 different possible values; the interpretation of those values is all that differs here. Whereas C lets you pick between signed and unsigned (with the default unfortunately not always well-defined), Java gives you no choice but to use the signed interpretation. But you still get to use all 8 bits of the byte; it's just that the numbers mapped to [128, 255] in unsigned interpretations map to [-128,-1] instead. Right, should have been more specific. The 0xFF byte doesn't work the way I expect it to. I have to use ints to get the correct answer. (bit-or (bit-shift-left (byte 0x01) 16) (bit-shift-left (byte 0x7F) 8)) = 98048 (bit-or (bit-shift-left (int 0x01) 16) (bit-shift-left (int 0x7F) 8)) = 98048 But... (bit-or (bit-shift-left (byte 0x01) 16) (bit-shift-left (byte 0xFF) 8)) = -256 (bit-or (bit-shift-left (int 0x01) 16) (bit-shift-left (int 0xFF) 8)) = 130816 So I can't use the bits the way I'd expect. Raph -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
Re: Why I have chosen not to employ clojure
Clojure can be used in so many different ways. I can't think of any other language where I have so many varied integration options. The flexibility is confusing and frustrating, but I much prefer its presence than absence. :) I'm glad I stuck with it. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
Re: Why I have chosen not to employ clojure
I was thinking it might be interesting to see if we could integrate Bespin Embedded in labrepl, having a nice web based syntax highlighting editor thats consistent on platforms could be quite cool. -- Pull me down under... On Wed, Mar 24, 2010 at 4:26 AM, Stuart Halloway stuart.hallo...@gmail.comwrote: You also get this with the labrepl (http://github.com/relevance/labrepl) which is free. Plus I am attempting (with a little help from you all) to keep the labrepl working with various IDEs. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
Re: Choosing a Clojure build tool
On Thu, Mar 25, 2010 at 6:17 PM, Brian Carper briancar...@gmail.com wrote: Ruby: gem install X Perl: perl -MCPAN -e shell, then install X If you're just installing CPAN module X, then on most installations all you need to run is this: cpan X You can still go into the interactive shell if you want, usually by just running cpan with no args. You don't have to do that to install a module, but if you need to find a module whose exact name you don't know, or if a module fails to build and you want to poke around the build tree, etc, the cpan shell is handy. And other languages have their own flavors - PHP has PEAR/PECL, while Python is trying to get there with PyPI, but it's not quite there yet. The problem with CPAN is that many modules require compiling native code (C in this case), which means that just running cpan won't work if you don't have C dev tools installed. You can often get modules with prebuilt binaries, but the mechanism is platform-dependent. For instance, each module is its own apt package for Debian/Ubuntu, while ActivePerl on Windows uses its own Perl Package Manager (ppm.exe). -- Mark J. Reed markjr...@gmail.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 To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
referencing an atom inside a function used for swapping
I have a function that I use for adding a JPanel to a ui atom. When I call swap! that ui atom is sent to that function I call with the swap! on and is dereferenced inside the function so I don't need to call @ui on it. However, I want to add listeners to my JPanel that can affect that atom, but I don't have the actual atom anymore since it's deferenced when I pass it to swap. I believe I could just pass it as another parameter, but that seems like a hack. (defn swap-function [ui atomWithUiInIt] ; add code that on a click or press or something, alter the atomWithUiInIt atom ...) Is there better way to handle this? -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
Re: referencing an atom inside a function used for swapping
I would just pass the atom and move the @ inside the function... On Thursday, March 25, 2010, strattonbrazil strattonbra...@gmail.com wrote: I have a function that I use for adding a JPanel to a ui atom. When I call swap! that ui atom is sent to that function I call with the swap! on and is dereferenced inside the function so I don't need to call @ui on it. However, I want to add listeners to my JPanel that can affect that atom, but I don't have the actual atom anymore since it's deferenced when I pass it to swap. I believe I could just pass it as another parameter, but that seems like a hack. (defn swap-function [ui atomWithUiInIt] ; add code that on a click or press or something, alter the atomWithUiInIt atom ...) Is there better way to handle this? -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject. -- Mark J. Reed markjr...@gmail.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 To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
Re: Choosing a Clojure build tool
I am in complete agreement! Clojure continues to hinder itself by not providing an official executable. java -cp clojure.jar was good enough for Clojure 0.9, but that's not where it is anymore. Even simple things like submitting bug reports would be helped by having a default clj executable. It would avoid a lot of questions about system configuration when reporting a bug. So many people and projects have RE-implemented a clj script! Seth On Mar 25, 5:32 pm, Heinz N. Gies he...@licenser.net wrote: On Mar 25, 2010, at 19:55 , Chas Emerick wrote: I published a blog post earlier today, along with a short screencast that might be of interest: Like any group of super-smart programmers using a relatively new language, a lot of folks in the Clojure community have looked at existing build tools (the JVM space is the relevant one here, meaning primarily Maven and Ant, although someone will bark if I don't mention Gradle, too), and felt a rush of disdain. I'd speculate that this came mostly because of XML allergies, but perhaps also in part because when one has a hammer as glorious as Clojure, it's hard to not want to use it to beat away at every problem in sight. I slowly get the feeling that build tools are too much in the focus. Why don't we start up with a good shell integration, being able to run clj my script go nice and including dependencies in jars and stuff. Making it easy to work with plain .clj files to include, load, run them would get us a huge way ahead and I think kind of freeing us from what I feel as the burden of the java world. Regards, Heinz -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
Re: Choosing a Clojure build tool
For whats it worth here - IntelliJ IDEA will automatically add maven dependencies to you pom.xml file for unknown classes ( in java source, not the clojure plugin - yet), for example if you type com.cemerick.Foo in your source, and its an unknown class, the intention dialog gives you options of create class or search maven, it then gives you a list of artifacts containing that class for you to add to pom.xml. Woud be nice having that in the La Clojure plugin as well. -- Pull me down under... On Fri, Mar 26, 2010 at 11:42 AM, Chas Emerick cemer...@snowtide.comwrote: The package browsing/searching story is probably the weakest. There's http://mvnrepository.com, which I just found 2 minutes ago. We have an internal Nexus installation (which caches all of the dependencies we've ever retrieved, so that our builds won't fail if the 'net is down, maven central is down, build.clojure.org is down, etc), which provides a very nice search interface. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
Re: converting long string to number
Though it might not be the best option here, the Clojure reader is always ready to serve: user (type (read-string 123)) java.lang.Integer user (type (read-string 123123123123123)) java.lang.Long user (type (read-string 123123123123123123123123123123123123)) java.math.BigInteger Of course, it might also pose a bit of a security threat: user (read-string #=(println \I OWN YOU NOW!\)) I OWN YOU NOW! nil :) -Per On Fri, Mar 26, 2010 at 5:47 AM, Chas Emerick cemer...@snowtide.com wrote: Glen, You want (java.math.BigInteger. 2342343...). java.lang.Integer is limited to 2^31-1. - Chas On Mar 25, 2010, at 6:40 PM, Glen Rubin wrote: I am trying to convert a long string of numbers to a number, but get a java.lang.numberformatexception My long string of numbers has new line characters in it, so I am filtering out the newline characters before converting it back to a string. Then I try to use Integer. on it but get the above exception. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
Re: converting long string to number
Of course, it might also pose a bit of a security threat: user (read-string #=(println \I OWN YOU NOW!\)) I OWN YOU NOW! nil :) user= (binding [*read-eval* false] (read-string #=(println \I OWN YOU NOW!\))) java.lang.RuntimeException: java.lang.Exception: EvalReader not allowed when *read-eval* is false. (NO_SOURCE_FILE:0) -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
Re: converting long string to number
Another unadvertised function that is useful to be aware of is clojure.lang.Numbers/reduce which will simplify a number to its most simple type. I often find that I want to use some BigInteger function, but then it is important to turn it back into a typical Clojure number at the end. For example, (defn next-prime [n] (clojure.lang.Numbers/reduce (.nextProbablePrime (BigInteger. (str n) --Mark -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
Re: converting long string to number
In those hills yonder in the lands of Common Lisp, it's usually considered good practice to blast the entire read table save for what you need when you deal with untrusted data. Barring that, a better option might be a more modular reader: read-number, read-symbol, etc. -Per On Fri, Mar 26, 2010 at 9:01 AM, Richard Newman holyg...@gmail.com wrote: Of course, it might also pose a bit of a security threat: user (read-string #=(println \I OWN YOU NOW!\)) I OWN YOU NOW! nil :) user= (binding [*read-eval* false] (read-string #=(println \I OWN YOU NOW!\))) java.lang.RuntimeException: java.lang.Exception: EvalReader not allowed when *read-eval* is false. (NO_SOURCE_FILE:0) -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
Re: converting long string to number
In those hills yonder in the lands of Common Lisp, it's usually considered good practice to blast the entire read table save for what you need when you deal with untrusted data. Barring that, a better option might be a more modular reader: read-number, read-symbol, etc. Clojure doesn't have a user-programmable reader, so much of the readtable shenanigans we use in CL don't apply. But yes, specific readers would be neat. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
concurrency and rand-int
I'm trying to track down the reason that I sometimes see a lot of concurrency in my system (up to 1200% CPU utilization on a dual quadcore mac that also has some kind of hyperthreading, allegedly allowing a maximum of 1600% CPU) while other times it gets stuck at around 100-200%. My system (a genetic programming system) has a *lot* of randomness in it, so it's hard to repeat runs and get a firm handle on what's going on. But after a bunch of testing I'm beginning to suspect that it might be the random number generator itself (clojure-core/rand-int in this case, which calls (. Math (random))). This seems at least somewhat plausible to me because I guess that the underlying Java random method must be accessing and updating a random number generator state, and so this would be a concurrency bottleneck. So if I'm in a condition in which lots of concurrent threads are all calling rand-int a lot then all of the accesses to the state have to be serialized and my concurrency suffers (a lot). Does this sound plausible to you? If so, is there a straightforward way to avoid it? It is not important to me that the random numbers being generated in different threads be generated from the same generator or coordinated/seeded in any way. I just need lots of numbers that are random enough. I guess I could roll my own random number generator(s) and either have a lot of them with independent states or maybe even make them stateless (always generating numbers by scrambling the clock?). But I would hope there would be something simpler. Thanks, -Lee -- Lee Spector, Professor of Computer Science School of Cognitive Science, Hampshire College 893 West Street, Amherst, MA 01002-3359 lspec...@hampshire.edu, http://hampshire.edu/lspector/ Phone: 413-559-5352, Fax: 413-559-5438 Check out Genetic Programming and Evolvable Machines: http://www.springer.com/10710 - http://gpemjournal.blogspot.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 To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
Re: concurrency and rand-int
Clojure calls out to Java's java.lang.Math.Random: This method is properly synchronized to allow correct use by more than one thread. However, if many threads need to generate pseudorandom numbers at a great rate, it may reduce contention for each thread to have its own pseudorandom-number generator. Look at java.util.Random for local RNGs. In the long term, it might make sense for core's rand to refer to a *random-number-generator* var that defaults to a shared thread-safe RNG but can be rebound per thread in cases like yours to reduce contention. In the short term, you can just write your own wrapper functions. -Per On Fri, Mar 26, 2010 at 9:35 AM, Lee Spector lspec...@hampshire.edu wrote: I'm trying to track down the reason that I sometimes see a lot of concurrency in my system (up to 1200% CPU utilization on a dual quadcore mac that also has some kind of hyperthreading, allegedly allowing a maximum of 1600% CPU) while other times it gets stuck at around 100-200%. My system (a genetic programming system) has a *lot* of randomness in it, so it's hard to repeat runs and get a firm handle on what's going on. But after a bunch of testing I'm beginning to suspect that it might be the random number generator itself (clojure-core/rand-int in this case, which calls (. Math (random))). This seems at least somewhat plausible to me because I guess that the underlying Java random method must be accessing and updating a random number generator state, and so this would be a concurrency bottleneck. So if I'm in a condition in which lots of concurrent threads are all calling rand-int a lot then all of the accesses to the state have to be serialized and my concurrency suffers (a lot). Does this sound plausible to you? If so, is there a straightforward way to avoid it? It is not important to me that the random numbers being generated in different threads be generated from the same generator or coordinated/seeded in any way. I just need lots of numbers that are random enough. I guess I could roll my own random number generator(s) and either have a lot of them with independent states or maybe even make them stateless (always generating numbers by scrambling the clock?). But I would hope there would be something simpler. Thanks, -Lee -- Lee Spector, Professor of Computer Science School of Cognitive Science, Hampshire College 893 West Street, Amherst, MA 01002-3359 lspec...@hampshire.edu, http://hampshire.edu/lspector/ Phone: 413-559-5352, Fax: 413-559-5438 Check out Genetic Programming and Evolvable Machines: http://www.springer.com/10710 - http://gpemjournal.blogspot.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 To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
Re: concurrency and rand-int
Hi Lee, Indeed -- from the docs for Math.random(): This method is properly synchronized to allow correct use by more than one thread. However, if many threads need to generate pseudorandom numbers at a great rate, it may reduce contention for each thread to have its own pseudorandom-number generator. At its root, java.util.Random uses an AtomicLong to store the last dispensed pseduorandom number, so that is the fundamental point of contention (all of your threads are blocking on a CAS on a single atom in the Math class' Random instance). You can certainly have a Random instance per-thread -- when you set up each thread of execution (in a send to an agent, at the start of the fn that you're pmap'ing across a dataset, whatever), just bind a new java.util.Random to a var, and have all your code pull random numbers from there. - Chas On Mar 25, 2010, at 10:35 PM, Lee Spector wrote: I'm trying to track down the reason that I sometimes see a lot of concurrency in my system (up to 1200% CPU utilization on a dual quadcore mac that also has some kind of hyperthreading, allegedly allowing a maximum of 1600% CPU) while other times it gets stuck at around 100-200%. My system (a genetic programming system) has a *lot* of randomness in it, so it's hard to repeat runs and get a firm handle on what's going on. But after a bunch of testing I'm beginning to suspect that it might be the random number generator itself (clojure-core/rand-int in this case, which calls (. Math (random))). This seems at least somewhat plausible to me because I guess that the underlying Java random method must be accessing and updating a random number generator state, and so this would be a concurrency bottleneck. So if I'm in a condition in which lots of concurrent threads are all calling rand- int a lot then all of the accesses to the state have to be serialized and my concurrency suffers (a lot). Does this sound plausible to you? If so, is there a straightforward way to avoid it? It is not important to me that the random numbers being generated in different threads be generated from the same generator or coordinated/seeded in any way. I just need lots of numbers that are random enough. I guess I could roll my own random number generator(s) and either have a lot of them with independent states or maybe even make them stateless (always generating numbers by scrambling the clock?). But I would hope there would be something simpler. Thanks, -Lee -- Lee Spector, Professor of Computer Science School of Cognitive Science, Hampshire College 893 West Street, Amherst, MA 01002-3359 lspec...@hampshire.edu, http://hampshire.edu/lspector/ Phone: 413-559-5352, Fax: 413-559-5438 Check out Genetic Programming and Evolvable Machines: http://www.springer.com/10710 - http://gpemjournal.blogspot.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 To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
Re: referencing an atom inside a function used for swapping
I would just pass the atom and move the @ inside the function... But the non-atom is automatically dereferenced and sent to the respective function when I use swap! So unless there's another function to alter atoms, I'm going to have the dereferenced version there no matter what, right? On Thursday, March 25, 2010, strattonbrazil strattonbra...@gmail.com wrote: I have a function that I use for adding a JPanel to a ui atom. When I call swap! that ui atom is sent to that function I call with the swap! on and is dereferenced inside the function so I don't need to call @ui on it. However, I want to add listeners to my JPanel that can affect that atom, but I don't have the actual atom anymore since it's deferenced when I pass it to swap. I believe I could just pass it as another parameter, but that seems like a hack. (defn swap-function [ui atomWithUiInIt] ; add code that on a click or press or something, alter the atomWithUiInIt atom ...) Is there better way to handle this? -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject. -- Mark J. Reed markjr...@gmail.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 To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
Re: referencing an atom inside a function used for swapping
Ah, right, this is the function called from swap!. So move the listener stuff out of your swap function and into the function that calls swap! instead? On Thu, Mar 25, 2010 at 11:02 PM, Josh Stratton strattonbra...@gmail.com wrote: I would just pass the atom and move the @ inside the function... But the non-atom is automatically dereferenced and sent to the respective function when I use swap! So unless there's another function to alter atoms, I'm going to have the dereferenced version there no matter what, right? On Thursday, March 25, 2010, strattonbrazil strattonbra...@gmail.com wrote: I have a function that I use for adding a JPanel to a ui atom. When I call swap! that ui atom is sent to that function I call with the swap! on and is dereferenced inside the function so I don't need to call @ui on it. However, I want to add listeners to my JPanel that can affect that atom, but I don't have the actual atom anymore since it's deferenced when I pass it to swap. I believe I could just pass it as another parameter, but that seems like a hack. (defn swap-function [ui atomWithUiInIt] ; add code that on a click or press or something, alter the atomWithUiInIt atom ...) Is there better way to handle this? -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject. -- Mark J. Reed markjr...@gmail.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 To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject. -- Mark J. Reed markjr...@gmail.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 To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
^C behaviour on Leopard (OS X 10.5.8)?
I've been using clojure 1.1.0 (via MacPorts clojure+rlwrap) and every time I type Control-C, it kills closure and dumps me back at my shell. Is that what is supposed to happen? Is there some other keystroke I should be using that will interrupt clojure and put me back at the clojure top-level? There is no mention of this made on http://clojure.org/getting_started or in http://en.wikibooks.org/wiki/Clojure_Programming/FAQ should I be looking somewhere else? Thanks, -Doug -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
Re: ^C behaviour on Leopard (OS X 10.5.8)?
Look at clojure.contrib.repl-utils/add-break-thread!: http://richhickey.github.com/clojure-contrib/repl-utils-api.html -Per On Fri, Mar 26, 2010 at 10:20 AM, Douglas Philips d...@mac.com wrote: I've been using clojure 1.1.0 (via MacPorts clojure+rlwrap) and every time I type Control-C, it kills closure and dumps me back at my shell. Is that what is supposed to happen? Is there some other keystroke I should be using that will interrupt clojure and put me back at the clojure top-level? There is no mention of this made on http://clojure.org/getting_started or in http://en.wikibooks.org/wiki/Clojure_Programming/FAQ should I be looking somewhere else? Thanks, -Doug -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
Re: concurrency and rand-int
As others have pointed out using per-thread java.util.Random objects is probably the best way to go in this particular case. However, I'm curious if the following code could give any speed gain on your machine: (defn rand-seq [] (repeatedly #(. Math (random (def rand-seq-ref (ref (rand-seq))) (nth @rand-seq-ref 100) ;; pre-cache random values; evaluate it every some time ;;btw, how to do it automatically? (defn next-rand-val [] (dosync (commute rand-seq-ref next) (first @rand-seq-ref))) user= (next-random-val) 0.5558267606843464 user= (next-random-val) 0.32353157456467474 Cheers, Andrzej On Fri, Mar 26, 2010 at 11:35 AM, Lee Spector lspec...@hampshire.edu wrote: I'm trying to track down the reason that I sometimes see a lot of concurrency in my system (up to 1200% CPU utilization on a dual quadcore mac that also has some kind of hyperthreading, allegedly allowing a maximum of 1600% CPU) while other times it gets stuck at around 100-200%. My system (a genetic programming system) has a *lot* of randomness in it, so it's hard to repeat runs and get a firm handle on what's going on. But after a bunch of testing I'm beginning to suspect that it might be the random number generator itself (clojure-core/rand-int in this case, which calls (. Math (random))). This seems at least somewhat plausible to me because I guess that the underlying Java random method must be accessing and updating a random number generator state, and so this would be a concurrency bottleneck. So if I'm in a condition in which lots of concurrent threads are all calling rand-int a lot then all of the accesses to the state have to be serialized and my concurrency suffers (a lot). Does this sound plausible to you? If so, is there a straightforward way to avoid it? It is not important to me that the random numbers being generated in different threads be generated from the same generator or coordinated/seeded in any way. I just need lots of numbers that are random enough. I guess I could roll my own random number generator(s) and either have a lot of them with independent states or maybe even make them stateless (always generating numbers by scrambling the clock?). But I would hope there would be something simpler. Thanks, -Lee -- Lee Spector, Professor of Computer Science School of Cognitive Science, Hampshire College 893 West Street, Amherst, MA 01002-3359 lspec...@hampshire.edu, http://hampshire.edu/lspector/ Phone: 413-559-5352, Fax: 413-559-5438 Check out Genetic Programming and Evolvable Machines: http://www.springer.com/10710 - http://gpemjournal.blogspot.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 To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
Re: Choosing a Clojure build tool
One of the weirdest things coming to the Java world is to witness what strange things people take for granted should be in the build tool. All the example features you mention in your article are convenient, but I don't see why they belong in the build tool. They should be completely separate pieces of functionality that you happen to use the build tool to invoke. Why this obsession with integration and unified configuration? -Per On Fri, Mar 26, 2010 at 1:55 AM, Chas Emerick cemer...@snowtide.com wrote: I published a blog post earlier today, along with a short screencast that might be of interest: Like any group of super-smart programmers using a relatively new language, a lot of folks in the Clojure community have looked at existing build tools (the JVM space is the relevant one here, meaning primarily Maven and Ant, although someone will bark if I don't mention Gradle, too), and felt a rush of disdain. I'd speculate that this came mostly because of XML allergies, but perhaps also in part because when one has a hammer as glorious as Clojure, it's hard to not want to use it to beat away at every problem in sight. Read on: http://muckandbrass.com/web/x/AgBV Feedback welcome, either here or in the comments on the post. Cheers, - Chas -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
Re: ^C behaviour on Leopard (OS X 10.5.8)?
On 2010 Mar 25, at 11:29 PM, Per Vognsen wrote: Look at clojure.contrib.repl-utils/add-break-thread!: http://richhickey.github.com/clojure-contrib/repl-utils-api.html Nice. Now I have to figure out how to get a clojure rc file! :) -Doug -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
Re: concurrency and rand-int
I was going to suggest something similar using seque in an atom, but in neither case (using an atom or a ref) is the contention going to be minimized -- just shifted from the AtomicLong in java.util.Random to the now-app-level atom or ref. - Chas On Mar 26, 2010, at 12:30 AM, Andrzej wrote: As others have pointed out using per-thread java.util.Random objects is probably the best way to go in this particular case. However, I'm curious if the following code could give any speed gain on your machine: (defn rand-seq [] (repeatedly #(. Math (random (def rand-seq-ref (ref (rand-seq))) (nth @rand-seq-ref 100) ;; pre-cache random values; evaluate it every some time ;;btw, how to do it automatically? (defn next-rand-val [] (dosync (commute rand-seq-ref next) (first @rand-seq-ref))) user= (next-random-val) 0.5558267606843464 user= (next-random-val) 0.32353157456467474 Cheers, Andrzej On Fri, Mar 26, 2010 at 11:35 AM, Lee Spector lspec...@hampshire.edu wrote: I'm trying to track down the reason that I sometimes see a lot of concurrency in my system (up to 1200% CPU utilization on a dual quadcore mac that also has some kind of hyperthreading, allegedly allowing a maximum of 1600% CPU) while other times it gets stuck at around 100-200%. My system (a genetic programming system) has a *lot* of randomness in it, so it's hard to repeat runs and get a firm handle on what's going on. But after a bunch of testing I'm beginning to suspect that it might be the random number generator itself (clojure-core/rand-int in this case, which calls (. Math (random))). This seems at least somewhat plausible to me because I guess that the underlying Java random method must be accessing and updating a random number generator state, and so this would be a concurrency bottleneck. So if I'm in a condition in which lots of concurrent threads are all calling rand-int a lot then all of the accesses to the state have to be serialized and my concurrency suffers (a lot). Does this sound plausible to you? If so, is there a straightforward way to avoid it? It is not important to me that the random numbers being generated in different threads be generated from the same generator or coordinated/seeded in any way. I just need lots of numbers that are random enough. I guess I could roll my own random number generator(s) and either have a lot of them with independent states or maybe even make them stateless (always generating numbers by scrambling the clock?). But I would hope there would be something simpler. Thanks, -Lee -- Lee Spector, Professor of Computer Science School of Cognitive Science, Hampshire College 893 West Street, Amherst, MA 01002-3359 lspec...@hampshire.edu, http://hampshire.edu/lspector/ Phone: 413-559-5352, Fax: 413-559-5438 Check out Genetic Programming and Evolvable Machines: http://www.springer.com/10710 - http://gpemjournal.blogspot.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 To unsubscribe from this group, send email to clojure +unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
Re: ^C behaviour on Leopard (OS X 10.5.8)?
You can put a user.clj file in your class path. -Per On Fri, Mar 26, 2010 at 11:42 AM, Douglas Philips d...@mac.com wrote: On 2010 Mar 25, at 11:29 PM, Per Vognsen wrote: Look at clojure.contrib.repl-utils/add-break-thread!: http://richhickey.github.com/clojure-contrib/repl-utils-api.html Nice. Now I have to figure out how to get a clojure rc file! :) -Doug -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
Re: Choosing a Clojure build tool
Because they're common processes that are ideally built once, and then reused with minor variation. Library reuse is generally considered to be a good thing in software development, so it strikes me as odd that many think that such practices should stop at the build's edge, as it were. Truly, maven is often referred to using various terms that are more expansive than build tool, as it aims to bring a degree of standardization and regularity to a variety of non-programming-related tasks associated with building, configuring, deploying, and releasing software. IIRC, even the simple notion of systematized dependency management was an alien notion in the JVM world until maven came around (which, if I have my timeline right, later inspired ivy due to shortcomings in maven v1?). I guess I would counter with: why would you want to reinvent your build/configuration/deployment practices for every project? Cheers, - Chas On Mar 26, 2010, at 12:33 AM, Per Vognsen wrote: One of the weirdest things coming to the Java world is to witness what strange things people take for granted should be in the build tool. All the example features you mention in your article are convenient, but I don't see why they belong in the build tool. They should be completely separate pieces of functionality that you happen to use the build tool to invoke. Why this obsession with integration and unified configuration? -Per On Fri, Mar 26, 2010 at 1:55 AM, Chas Emerick cemer...@snowtide.com wrote: I published a blog post earlier today, along with a short screencast that might be of interest: Like any group of super-smart programmers using a relatively new language, a lot of folks in the Clojure community have looked at existing build tools (the JVM space is the relevant one here, meaning primarily Maven and Ant, although someone will bark if I don't mention Gradle, too), and felt a rush of disdain. I'd speculate that this came mostly because of XML allergies, but perhaps also in part because when one has a hammer as glorious as Clojure, it's hard to not want to use it to beat away at every problem in sight. Read on: http://muckandbrass.com/web/x/AgBV Feedback welcome, either here or in the comments on the post. Cheers, - Chas -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en To unsubscribe from this group, send email to clojure +unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
Re: Choosing a Clojure build tool
On Fri, Mar 26, 2010 at 11:50 AM, Chas Emerick cemer...@snowtide.com wrote: Because they're common processes that are ideally built once, and then reused with minor variation. Library reuse is generally considered to be a good thing in software development, so it strikes me as odd that many think that such practices should stop at the build's edge, as it were. Reuse is great. Integration tends to hamper reuse. To take one of your examples, if I want to bundle my classes and dependencies into a Windows installer, I will call a function in a library (or a command line program in the Unix world) that does that. That's it. It doesn't need to be part of the build system and shouldn't be. I can call functions in the build system to supply the relevant arguments. If the build tool and library is well designed, the added value of integration in this example should be infinitesimal. -Per -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
