Re: Another ClojureScript app in the wild
Very cool! Now the logic of pacman is in a form I can easily read :-) Out of interest, do you know why it only works in Chrome? Doesn't the closure library do any work to shield you from from the browser differences, or is it simply a performance issue with the Chrome js engine the only one operating fast enough to smoothly render the game? Sam --- http://sam.aaron.name On 17 Aug 2011, at 23:00, Matthew Gilliard wrote: > I've been playing around writing a fun little ClojureScript project - > it's a bit different, so I thought you might like to see it: > > http://mjg123.github.com/pacman/pacman.html > > As I was feeling my way quite blindly through ClojureScript and > gClosure I have let the code get into a bit of a mess and I don't > think I'll really work on it much more. I have learned an awful lot > though (which was the main objective) - my main lessons are: > > - ClojureScript is awesome. The performance and stability of it are > really astounding. Really great work guys. > - Debugging a ClojureScript app is hard. I never figured out how to > get js/console to work. My best solution was to compile & run very > often, so that errors were caught quickly. Better yet would have been > thorough testing ;) > > - it *is* possible to write a game with no mutable state (well, I use > an atom to hold the most-recently-pressed key, but apart from that... > The state-of-the-world datastructure is immutable) > > - Some functions missing from ClojureScript which surprised me: range, int > - Some functions behave differently between Clojure and ClojureScript > (due to underlying platform differences): mod > > - Testing is very important. The gClosure jsunit stuff looks nice > but I'd love a midje-like API for it. > > Browser-compatibility: Chrome - OK, Firefox 6 - sometimes crashes > with "too much recursion", IE/Safari - Forget it. > > Happy to answer any questions, otherwise I'll be over here hacking > some Clojure :) > > Matthew > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Clojure Speed performance test
Hello, I recently stumbled upon this page: http://java.dzone.com/articles/contrasting-performance They are comparing several languages (Java, Scala, Python, Erlang, Clojure, Ruby, Groovy, Javascript), and Clojure rated very badly: Object Oriented List Reduction Element Recursion Java 1.6 0.6371.435 2.816 Clojure 1.2.1 - 25.966 28.753 Maybe the clojure's scripts were not very idiomatic? If some guru wants to check them, here's the source code: - https://github.com/dnene/josephus/blob/master/element-recursion/josephus.clj - https://github.com/dnene/josephus/blob/master/list-reduction/josephus.clj All the best, Roberto -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Another ClojureScript app in the wild
> Very cool! Now the logic of pacman is in a form I can easily read :-) I assume you are referring to the gameinternals post not my code ! I do not know why it only works in Chrome. The error "too much recursion" is confusing. It happens before the game is rendered so I suspect it's in the code which parses the board. The only explicit recursion I do is my implementation of (range) here: https://github.com/mjg123/pacman/blob/gh-pages/src/pacman/board.cljs - but that uses (recur). There's also the nested for loop in that same file, I have no idea how (for) works internally. The gameloop uses a javascript timer-with-callback to call itself so that won't consume stack space. Another thing is that it seems to be machine dependent - it works fine in ff6 on my work pc but not on my (much) older home PC. There are also rendering bugs in Firefox which seem to be caused by SVG arc-segments with negative radius - I assume this is just an implementation difference in a grey area of the spec. If there's interest I can try to pare down the code to a minimal case which throws the "too much recursion" error? mg On Thu, Aug 18, 2011 at 8:04 AM, Sam Aaron wrote: > Very cool! Now the logic of pacman is in a form I can easily read :-) > > Out of interest, do you know why it only works in Chrome? Doesn't the closure > library do any work to shield you from from the browser differences, or is it > simply a performance issue with the Chrome js engine the only one operating > fast enough to smoothly render the game? > > Sam > > --- > http://sam.aaron.name > > On 17 Aug 2011, at 23:00, Matthew Gilliard wrote: > >> I've been playing around writing a fun little ClojureScript project - >> it's a bit different, so I thought you might like to see it: >> >> http://mjg123.github.com/pacman/pacman.html >> >> As I was feeling my way quite blindly through ClojureScript and >> gClosure I have let the code get into a bit of a mess and I don't >> think I'll really work on it much more. I have learned an awful lot >> though (which was the main objective) - my main lessons are: >> >> - ClojureScript is awesome. The performance and stability of it are >> really astounding. Really great work guys. >> - Debugging a ClojureScript app is hard. I never figured out how to >> get js/console to work. My best solution was to compile & run very >> often, so that errors were caught quickly. Better yet would have been >> thorough testing ;) >> >> - it *is* possible to write a game with no mutable state (well, I use >> an atom to hold the most-recently-pressed key, but apart from that... >> The state-of-the-world datastructure is immutable) >> >> - Some functions missing from ClojureScript which surprised me: range, int >> - Some functions behave differently between Clojure and ClojureScript >> (due to underlying platform differences): mod >> >> - Testing is very important. The gClosure jsunit stuff looks nice >> but I'd love a midje-like API for it. >> >> Browser-compatibility: Chrome - OK, Firefox 6 - sometimes crashes >> with "too much recursion", IE/Safari - Forget it. >> >> Happy to answer any questions, otherwise I'll be over here hacking >> some Clojure :) >> >> Matthew >> >> -- >> You received this message because you are subscribed to the Google >> Groups "Clojure" group. >> To post to this group, send email to clojure@googlegroups.com >> Note that posts from new members are moderated - please be patient with your >> first post. >> To unsubscribe from this group, send email to >> clojure+unsubscr...@googlegroups.com >> For more options, visit this group at >> http://groups.google.com/group/clojure?hl=en > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Clojure-CLR, CLASSPATH, clojure.load.path and Cygwin
On Thu, Aug 18, 2011 at 01:39:21AM -0400, Ken Wesson spake thus: > On Thu, Aug 18, 2011 at 12:32 AM, Alan D. Salewski wrote: > > On Wed, Aug 17, 2011 at 01:47:53PM -0400, Ken Wesson spake thus: > >> On Wed, Aug 17, 2011 at 9:48 AM, Alan D. Salewski wrote: > >> > I approached the question from the perspective of one wanting to invoke > >> > Clojure-CLR with the ability to manipulate the value of > >> > 'clojure.class.path' "on-the-fly" in a way that is common and natural > >> > for *nix folks. > >> > >> And with 'env' it clearly is possible to manipulate the value on the > >> fly, as Stephen pointed out three hours before your post and as you > >> yourself have demonstrated. > > > > Aside from the matter that using 'env' is clunky for common command line > > usage, it is /not/ possible manipulate the value on the fly, generally. > > There is no in-principle difference between using 'set' and using > 'env'. It's just a different three letters here and there in your > script. Sure there is. I use 'set' to show behavior related to querying the environment of the current process. I use 'env' to show behavior related to querying the environment of a child process (and separately as a tool for setting up such environments, obviously): $ echo $BASH_VERSION 4.1.5(1)-release $ env -- dot.name=blah /bin/bash # create subshell $ set | grep dot # query current env of "this" subshell, using builtin 'set' command; no output, but it's there... $ env | grep dot # query env of child of "this" subshell; ah, there it is. dot.name=blah > > There are at least three common scenarios to consider: > > > > 1. Inovking the Clojure-CLR from bash w/o setting or modifying > > 'clojure.load.path'. > > Just run it. Yep, that's what I said. > > 2. Invoking the Clojure-CLR from bash, supplying an explicit value > > for 'clojure.run.path' not based on the existing value, if any. > > > > 3. Invoking the Clojure-CLR from bash, augmenting the existing value > > of 'clojure.run.path' with an explicit value. > > Use a script that wraps the invocation in a save and set, then a > restore, of clojure.run.path; or spawn a subsidiary shell with its own > copy of the environment with a short script that sets the environment > variable and then runs Clojure-CLR, "popping" the environment changes > on exit. > > > Scenario 3 cannot be addressed by 'env' because it requires manipulation > > of the existing value of the variable. > > You aren't honestly claiming that there is no way to extract the value > into a bash shell variable, are you? No, I claimed that you cannot access the envrionment variable by name in the current process to extract it's value (for the purpose of augmenting that value while setting up the environment of a subprocess, in the example I used). > Not after you yourself posted > this snippet earlier: > > $ /usr/bin/env -- ALJUNK_CRAP1=junk1 ALJUNK.CRAP2=junk2 /bin/bash -c > env | grep ALJU > ALJUNK.CRAP2=junk2 > ALJUNK_CRAP1=junk1 > > So, env | grep clojure.class.path | sed after the = goes here> | whatever > > and you can grab the existing value and compute something from it. > > Couldn't be simpler. That's ridiculous; there's nothing simple about it. It requires launching a subprocess simply to query it's environment to extract a value to use while setting up the environment of the subprocess that is to receive the value: $ /usr/bin/env -- "clojure.load.path=/my/new/value$(env|sed -n '/^clojure\.load\.path=\(.*\)$/ s//:\1/p')" /bin/bash It's exceedingly useful that such things can be scripted, but that's a clunky way to accomplish something that is more directly and efficiently accomplished in other well established ways. It violates the *nix user's expectation about how such things can be accomplished, and prevents folks from invoking Clojure-CLR in the way they invoke every other tool they've launched from a *nix shell since the epoch. And it won't work with all shells[0] because propagation down through subprocesses cannot be relied upon. From the perspective of a *nix shell user, it's neither simple nor elegant. The OP didn't ask if it was possible to hack around use of an environment variable whose name is not a valid POSIX shell identifier. He asked, "How do we plan to support an alternative name..." I think it's reasonable to think such a thing would be generally desirable, and that it is also reasonable to expect that the solution would take a form similar to existing tools. With that said, I also think a valid answer is, "There are currently no plans to support that use case, but if you'd like to see it happen, patches are welcome. In the meantime, maybe you can use the hacks in this thread to get by." -Al [0] ksh, for example: $ /usr/bin/env -- "clojure.load.path=/the/os/default" /bin/ksh $ /usr/bin/env | grep clojure.load.path # no output; var did not propagate --
Re: lein gets error java 1.6.0_26 ???
You are missing the robert hook library. https://github.com/technomancy/robert-hooke This is used by leiningen and should be installed as part of the leiningen install. Did you do a clean reinstall of leinigen with the windows dist to ensure you have all the pieces ? Luc P. On Wed, 17 Aug 2011 19:40:05 -0700 (PDT) jayvandal wrote: > > I some how got this error. I have deleted clojure, lein, java, changed > paths and I get this error > What is the problem??? > > Microsoft Windows [Version 6.0.6002] > Copyright (c) 2006 Microsoft Corporation. All rights reserved. > > C:\Users\jim>lein > Exception in thread "main" java.io.FileNotFoundException: Could not > locate rober > t/hooke__init.class or robert/hooke.clj on classpath: (core.clj:1) > at clojure.lang.Compiler.eval(Compiler.java:5440) > at clojure.lang.Compiler.eval(Compiler.java:5415) > at clojure.lang.Compiler.load(Compiler.java:5857) > at clojure.lang.RT.loadResourceScript(RT.java:340) > at clojure.lang.RT.loadResourceScript(RT.java:331) > > This is thee version of java that won't go away > Microsoft Windows [Version 6.0.6002] > = > Copyright (c) 2006 Microsoft Corporation. All rights reserved. > > C:\Users\jim>java -vwersion > Unrecognized option: -vwersion > Could not create the Java virtual machine. > > C:\Users\jim>java -version > java version "1.6.0_26" > Java(TM) SE Runtime Environment (build 1.6.0_26-b03) > Java HotSpot(TM) Client VM (build 20.1-b02, mixed mode, sharing) > > C:\Users\jim> > at clojure.lang.RT.load(RT.java:409) > at clojure.lang.RT.load(RT.java:381) > at clojure.core$load$fn__4519.invoke(core.clj:4915) > at clojure.core$load.doInvoke(core.clj:4914) > at clojure.lang.RestFn.invoke(RestFn.java:408) > at clojure.core$load_one.invoke(core.clj:4729) > at clojure.core$load_lib.doInvoke(core.clj:4766) > at clojure.lang.RestFn.applyTo(RestFn.java:142) > at clojure.core$apply.invoke(core.clj:542) > at clojure.core$load_libs.doInvoke(core.clj:4800) > at clojure.lang.RestFn.applyTo(RestFn.java:137) > at clojure.core$apply.invoke(core.clj:544) > at clojure.core$use.doInvoke(core.clj:4892) > at clojure.lang.RestFn.invoke(RestFn.java:408) > at user$eval1.invoke(NO_SOURCE_FILE:1) > at clojure.lang.Compiler.eval(Compiler.java:5424) > at clojure.lang.Compiler.eval(Compiler.java:5391) > at clojure.core$eval.invoke(core.clj:2382) > at clojure.main$eval_opt.invoke(main.clj:235) > at clojure.main$initialize.invoke(main.clj:254) > at clojure.main$script_opt.invoke(main.clj:270) > at clojure.main$main.doInvoke(main.clj:354) > at clojure.lang.RestFn.invoke(RestFn.java:436) > at clojure.lang.Var.invoke(Var.java:373) > at clojure.lang.AFn.applyToHelper(AFn.java:167) > at clojure.lang.Var.applyTo(Var.java:482) > at clojure.main.main(main.java:37) > Caused by: java.io.FileNotFoundException: Could not locate robert/ > hooke__init.cl > ass or robert/hooke.clj on classpath: > at clojure.lang.RT.load(RT.java:412) > at clojure.lang.RT.load(RT.java:381) > at clojure.core$load$fn__4519.invoke(core.clj:4915) > at clojure.core$load.doInvoke(core.clj:4914) > at clojure.lang.RestFn.invoke(RestFn.java:408) > at clojure.core$load_one.invoke(core.clj:4729) > at clojure.core$load_lib.doInvoke(core.clj:4766) > at clojure.lang.RestFn.applyTo(RestFn.java:142) > at clojure.core$apply.invoke(core.clj:542) > at clojure.core$load_libs.doInvoke(core.clj:4800) > at clojure.lang.RestFn.applyTo(RestFn.java:137) > at clojure.core$apply.invoke(core.clj:544) > at clojure.core$use.doInvoke(core.clj:4892) > at clojure.lang.RestFn.invoke(RestFn.java:457) > at leiningen.core > $eval5$loading__4414__auto6.invoke(core.clj:1) > at leiningen.core$eval5.invoke(core.clj:1) > at clojure.lang.Compiler.eval(Compiler.java:5424) > ... 31 more > > C:\Users\jim> > -- Luc P. The rabid Muppet -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Clojure Speed performance test
Maybe Clojure code needs some type annotations. On Aug 18, 9:40 am, Roberto Mannai wrote: > Hello, > I recently stumbled upon this > page:http://java.dzone.com/articles/contrasting-performance > They are comparing several languages (Java, Scala, Python, Erlang, > Clojure, Ruby, Groovy, Javascript), and Clojure rated very badly: > > Object Oriented List Reduction > Element Recursion > Java 1.6 0.637 1.435 > 2.816 > Clojure 1.2.1 - 25.966 > 28.753 > > Maybe the clojure's scripts were not very idiomatic? If some guru > wants to check them, here's the source code: > -https://github.com/dnene/josephus/blob/master/element-recursion/josep... > - https://github.com/dnene/josephus/blob/master/list-reduction/josephus... > > All the best, > Roberto -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be 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
REPL and Leiningen checkouts
Hello, I want to play around with a library I'm using so I started using the Leiningen checkouts feature and if I do lein repl it works. But when I'm running the REPL inside my editor I'm not running it through lein. Any ideas how to get my REPL to pick up checkouts like when I run it with lein? 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
Re: Clojure-CLR, CLASSPATH, clojure.load.path and Cygwin
Ken Wesson writes: >> I approached the question from the perspective of one wanting to invoke >> Clojure-CLR with the ability to manipulate the value of >> 'clojure.class.path' "on-the-fly" in a way that is common and natural >> for *nix folks. > > And with 'env' it clearly is possible to manipulate the value on the > fly, as Stephen pointed out three hours before your post and as you > yourself have demonstrated. > > The OP's problem has been solved; let's move on. In my opinion using a variable name that is not supported in Bash would create some problems: - most Linux (and probably Mac) users use the Bash shell. The 'env' command can pass a variable that is not Bash compliant to a process, but you can not set and query such a variable in a Bash script. This is very likely to cause some frustration and time wasting for people using Clojure and Bash together. - A name like clojure.load.path breaks a widely accepted convention: environment variable names usually consist of capital letters and underscores. So we have MAVEN_HOME, JAVA_HOME, ANT_HOME, etc. When I see a name like clojure.load.path my first thought would be that this is a Java system property, not an environment variable. I think that it would be wise to stick to the convention and use variable names that are Bash compliant. I would use CLOJURE_LOAD_PATH for an environment variable name and clojure.load.path for a Java system property name. -- Dimitre Liotev -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be 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
clojurescript support of ns-* functions
Hi, I'm enjoying playing with ClojureScript so far, great job guys! I'm wondering if functions like ns-aliases and Vars like *ns* will be implemented in future versions of ClojureScript. If not, are there recommended workarounds or should I just hardcode the values? Thanks, Jim -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: clojure-jack-in vs. slime-connect
On Wed, Aug 17, 2011 at 8:53 AM, Jose A. Ortega Ruiz wrote: > I use (technomancy's) slime with clojure-mode (both elpa-installed) > without any issues (via lein swank and slime-connect). While the newish > clojure-jack-in works too, i prefer slime-connect (because i save the > time of re-evaluating the slime code everytime i restart the REPL). > > So i was wondering: is the stand-alone slime package deprecated or > lagging respect to the one that gets loaded by clojure-jack-in? Or are > both kept in sync, so that i'm not missing any new functionality or > fixes by using the slime-connect way? You will be fine; clojure-jack-in is built upon slime-connect and lein swank, so that stuff is not going away. It's more convenient to use jack-in, but if you already have everything installed and don't mind picking port numbers that don't conflict then you're ok. Future versions of swank-clojure will allow the elisp to be byte-compiled so slime will load much more quickly. -Phil -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: REPL and Leiningen checkouts
2011/8/16 J. Pablo Fernández : > I want to play around with a library I'm using so I started using the > Leiningen checkouts feature and if I do lein repl it works. But when I'm > running the REPL inside my editor I'm not running it through lein. Any ideas > how to get my REPL to pick up checkouts like when I run it with lein? It's impossible to say without knowing what your editor is, but you will probably want to use the output of "lein classpath" when configuring it if it can't hook directly up to leiningen via repl, swank, nrepl, nailgun, etc. -Phil -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: REPL and Leiningen checkouts
I'm currently using La Clojure. Not sure if I can directly hook it to lein. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Clojure Speed performance test
The Clojure code posted there is pretty awful and shows a gross, gross misunderstanding of Clojure data types. I submitted one improved version already, but didn't spend the time to make it really, really fast. For this particular kind of pointless benchmark it's not hard to get identical Java perf. If you want to see how I suggest you look at the Alioth benchmarks where the Clojure code shows a much better understanding of the language and the fast paths and where the microbenchmarks are quite so micro. David On Thu, Aug 18, 2011 at 3:40 AM, Roberto Mannai wrote: > Hello, > I recently stumbled upon this page: > http://java.dzone.com/articles/contrasting-performance > They are comparing several languages (Java, Scala, Python, Erlang, > Clojure, Ruby, Groovy, Javascript), and Clojure rated very badly: > > Object Oriented List Reduction > Element Recursion > Java 1.6 0.6371.435 > 2.816 > Clojure 1.2.1 - 25.966 > 28.753 > > Maybe the clojure's scripts were not very idiomatic? If some guru > wants to check them, here's the source code: > - > https://github.com/dnene/josephus/blob/master/element-recursion/josephus.clj > - > https://github.com/dnene/josephus/blob/master/list-reduction/josephus.clj > > All the best, > Roberto > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Clojure Speed performance test
On Thu, Aug 18, 2011 at 7:40 AM, Paulo Pinto wrote: > Maybe Clojure code needs some type annotations. Type annotations will not help this code at all. David -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Clojure Speed performance test
For list reduction it is said to remove every third solder but just with 1 step they remove 1 soldier. There is something wrong Scully. On Aug 18, 3:50 pm, David Nolen wrote: > The Clojure code posted there is pretty awful and shows a gross, gross > misunderstanding of Clojure data types. I submitted one improved version > already, but didn't spend the time to make it really, really fast. > > For this particular kind of pointless benchmark it's not hard to get > identical Java perf. If you want to see how I suggest you look at the Alioth > benchmarks where the Clojure code shows a much better understanding of the > language and the fast paths and where the microbenchmarks are quite so > micro. > > David > > > > > > > > On Thu, Aug 18, 2011 at 3:40 AM, Roberto Mannai wrote: > > Hello, > > I recently stumbled upon this page: > >http://java.dzone.com/articles/contrasting-performance > > They are comparing several languages (Java, Scala, Python, Erlang, > > Clojure, Ruby, Groovy, Javascript), and Clojure rated very badly: > > > Object Oriented List Reduction > > Element Recursion > > Java 1.6 0.637 1.435 > > 2.816 > > Clojure 1.2.1 - 25.966 > > 28.753 > > > Maybe the clojure's scripts were not very idiomatic? If some guru > > wants to check them, here's the source code: > > - > >https://github.com/dnene/josephus/blob/master/element-recursion/josep... > > - > >https://github.com/dnene/josephus/blob/master/list-reduction/josephus... > > > All the best, > > Roberto > > > -- > > You received this message because you are subscribed to the Google > > Groups "Clojure" group. > > To post to this group, send email to clojure@googlegroups.com > > Note that posts from new members are moderated - please be patient with > > your first post. > > To unsubscribe from this group, send email to > > clojure+unsubscr...@googlegroups.com > > For more options, visit this group at > >http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Clojure-CLR, CLASSPATH, clojure.load.path and Cygwin
On Wed, Aug 17, 2011 at 4:25 PM, Dimitre Liotev wrote: > you can not set and query such a variable in a Bash script. Code has already been posted to this thread that does exactly that. -- Protege: What is this seething mass of parentheses?! Master: Your father's Lisp REPL. This is the language of a true hacker. Not as clumsy or random as C++; a language for a more civilized age. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be 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
Video & Slides on Pattern Matching and Predicate Dispatch in Clojure
In case you didn't see this elsewhere: http://vimeo.com/27860102 David -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Video & Slides on Pattern Matching and Predicate Dispatch in Clojure
Hello, I don't have a Facebook account (and don't want to create one), neither have or want to create a scribd account. Could it be possible to have the slides available for download without having to authenticate (e.g. slideshare) ? 2011/8/18 David Nolen > In case you didn't see this elsewhere: > > http://vimeo.com/27860102 > > David > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Video & Slides on Pattern Matching and Predicate Dispatch in Clojure
> I don't have a Facebook account (and don't want to create one), neither have > or want to create a scribd account. Could it be possible to have the slides > available for download without having to authenticate (e.g. slideshare) ? Slides are on Scribd as well - http://www.scribd.com/doc/62571669/Patterns Awesome stuff, David. I am quite enamoured by the things that are still to come :-) Hats off... Regards, BG -- Baishampayan Ghose b.ghose at 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
Re: Video & Slides on Pattern Matching and Predicate Dispatch in Clojure
SlideShare link, http://www.slideshare.net/DavidNolen/patterns-8907600 David On Thu, Aug 18, 2011 at 2:57 PM, Laurent PETIT wrote: > Hello, > > I don't have a Facebook account (and don't want to create one), neither > have or want to create a scribd account. Could it be possible to have the > slides available for download without having to authenticate (e.g. > slideshare) ? > > 2011/8/18 David Nolen > >> In case you didn't see this elsewhere: >> >> http://vimeo.com/27860102 >> >> David >> >> -- >> You received this message because you are subscribed to the Google >> Groups "Clojure" group. >> To post to this group, send email to clojure@googlegroups.com >> Note that posts from new members are moderated - please be patient with >> your first post. >> To unsubscribe from this group, send email to >> clojure+unsubscr...@googlegroups.com >> For more options, visit this group at >> http://groups.google.com/group/clojure?hl=en > > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Video & Slides on Pattern Matching and Predicate Dispatch in Clojure
Thanks David, I can't wait reading them ! Cheers, -- Laurent 2011/8/18 David Nolen > SlideShare link, http://www.slideshare.net/DavidNolen/patterns-8907600 > > David > > > On Thu, Aug 18, 2011 at 2:57 PM, Laurent PETIT wrote: > >> Hello, >> >> I don't have a Facebook account (and don't want to create one), neither >> have or want to create a scribd account. Could it be possible to have the >> slides available for download without having to authenticate (e.g. >> slideshare) ? >> >> 2011/8/18 David Nolen >> >>> In case you didn't see this elsewhere: >>> >>> http://vimeo.com/27860102 >>> >>> David >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Clojure" group. >>> To post to this group, send email to clojure@googlegroups.com >>> Note that posts from new members are moderated - please be patient with >>> your first post. >>> To unsubscribe from this group, send email to >>> clojure+unsubscr...@googlegroups.com >>> For more options, visit this group at >>> http://groups.google.com/group/clojure?hl=en >> >> >> -- >> You received this message because you are subscribed to the Google >> Groups "Clojure" group. >> To post to this group, send email to clojure@googlegroups.com >> Note that posts from new members are moderated - please be patient with >> your first post. >> To unsubscribe from this group, send email to >> clojure+unsubscr...@googlegroups.com >> For more options, visit this group at >> http://groups.google.com/group/clojure?hl=en > > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Video & Slides on Pattern Matching and Predicate Dispatch in Clojure
2011/8/18 Baishampayan Ghose > > I don't have a Facebook account (and don't want to create one), neither > have > > or want to create a scribd account. Could it be possible to have the > slides > > available for download without having to authenticate (e.g. slideshare) ? > > Slides are on Scribd as well - http://www.scribd.com/doc/62571669/Patterns Yes, but scribd required authentication for being able to download the slides > > > Awesome stuff, David. I am quite enamoured by the things that are > still to come :-) Hats off... > > Regards, > BG > > -- > Baishampayan Ghose > b.ghose at 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 > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Video & Slides on Pattern Matching and Predicate Dispatch in Clojure
2011/8/18 David Nolen > SlideShare link, http://www.slideshare.net/DavidNolen/patterns-8907600 Arrrgh, and now slideshare wants me to authenticate via FB or a slideshare account if I want to download the slides, again. Ok, I've already got a slideshare account, so I'll try to remember the password or go through the email roundtrip, but still, I can remember a time where things were easier for non DRM material with scribd/slideshare ... ? > > David > > > On Thu, Aug 18, 2011 at 2:57 PM, Laurent PETIT wrote: > >> Hello, >> >> I don't have a Facebook account (and don't want to create one), neither >> have or want to create a scribd account. Could it be possible to have the >> slides available for download without having to authenticate (e.g. >> slideshare) ? >> >> 2011/8/18 David Nolen >> >>> In case you didn't see this elsewhere: >>> >>> http://vimeo.com/27860102 >>> >>> David >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Clojure" group. >>> To post to this group, send email to clojure@googlegroups.com >>> Note that posts from new members are moderated - please be patient with >>> your first post. >>> To unsubscribe from this group, send email to >>> clojure+unsubscr...@googlegroups.com >>> For more options, visit this group at >>> http://groups.google.com/group/clojure?hl=en >> >> >> -- >> You received this message because you are subscribed to the Google >> Groups "Clojure" group. >> To post to this group, send email to clojure@googlegroups.com >> Note that posts from new members are moderated - please be patient with >> your first post. >> To unsubscribe from this group, send email to >> clojure+unsubscr...@googlegroups.com >> For more options, visit this group at >> http://groups.google.com/group/clojure?hl=en > > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Clojure-CLR, CLASSPATH, clojure.load.path and Cygwin
On Thu, Aug 18, 2011 at 7:34 PM, Ken Wesson wrote: > > On Wed, Aug 17, 2011 at 4:25 PM, Dimitre Liotev wrote: > > you can not set and query such a variable in a Bash script. > > Code has already been posted to this thread that does exactly that. Let me rephrase this for you: you can not set and query such a variable in the standard, conventional, predictable Bash way. This is what matters. No point in devising ways to torture users by forcing them to use ugly hacks for something as basic and simple as setting a variable. -- Dimitre Liotev -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Clojure-CLR, CLASSPATH, clojure.load.path and Cygwin
On Thu, Aug 18, 2011 at 4:56 PM, D L wrote: > On Thu, Aug 18, 2011 at 7:34 PM, Ken Wesson wrote: >> >> On Wed, Aug 17, 2011 at 4:25 PM, Dimitre Liotev wrote: >> > you can not set and query such a variable in a Bash script. >> >> Code has already been posted to this thread that does exactly that. > > Let me rephrase this for you: you can not set and query such a > variable in the standard, > conventional, predictable Bash way. This is what matters. No point in > devising ways to > torture users by forcing them to use ugly hacks for something as basic > and simple as > setting a variable. But the standard way of "setting a variable" in bash would presumably not, in a Windows port of bash, affect the environment as seen by native programs anyway, since clearly bash has a different idea of what an environment variable is, how it can be named, and so on than Windows does, and so seems to necessarily have a different environment than Windows's. Then, no matter what it's named, if a Windows application uses a Windows environment variable it will be more awkward to manipulate from a Windows port of bash than an emulated native unix environment variable, and likewise more awkward than a true native unix environment variable manipulated on a unix machine and used by a native unix application. But this is all entirely beside the point: 1. The OP just wanted to *set* the variable and call Clojure-CLR. That problem is solved. A claim was mooted that it was unsolvable without renaming the variable, and that claim was decisively proved wrong. 2. Subsequently, a claim was mooted that though it was admittedly possible to *set* the variable it would not be *possible* to read it, and thus to set it to a function of its prior value -- and THAT claim was decisively proved wrong. 3. So now you admit that it IS possible, but instead of leaving it at that, you just change your objection -- AGAIN -- this time to say that it's *too inconvenient*. 4. On top of all of this goalpost-moving by what seems to be either a Sybil attack or a tag-team of opponents ganging up on me, there's the minor little matter of the fundamentally questionable assumption they (you) are making, which is that developers of native Windows applications should be adhering to Unix naming conventions for the convenience of that tiny fraction of Windows users that use a port of bash to Windows as their command shell instead of using native tools such as cmd and Explorer! Taken to its logical extreme, such a position is probably untenable, as it's likely that if you intersected the subsets of names and other practices that would be allowed and convenient for all operating systems you'd wind up with the empty set and become paralyzed into inaction. :) "You can't please all of the people all of the time", and apparently the same goes for operating systems. It's generally regarded as acceptable for Windows-native applications to adhere to Windows conventions, unix-native ones to unix conventions, and so forth; and here we have a Windows-native application with an environment variable name that lies within the realm Windows allows to manipulate conveniently, but happens to be awkward to deal with in unix. I'd say that that's too bad for the unix user affected by it, but not a foul by the Windows community, and it's not even the biggest unix/Windows impedance mismatch out there -- how about cr/lf vs. lf? Space-ridden case-insensitive file names that need to be quoted to move to unix, and cause collisions sometimes moving the other way? Name collisions are certainly a larger inconvenience than having to -- my God! -- use sed a little bit. :) -- Protege: What is this seething mass of parentheses?! Master: Your father's Lisp REPL. This is the language of a true hacker. Not as clumsy or random as C++; a language for a more civilized age. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: REPL and Leiningen checkouts
FWIW, IntelliJ (like Eclipse) has excellent Maven support, which includes (IIRC, haven't touched IDEA in a long time) the equivalent of Eclipse's workspace dependency resolution. So, if you have project A that depends on vX of project B and vY of project C, then the IDE will add the compilation results and resources (including e.g. Clojure source files) from your workspace's working copies of projects B and C to the classpath of project A. Reading that now, that sounds way more complicated than it actually is. :-) In short, the IDE uses the projects you have open as dependencies, instead of "binary" artifacts that you might have in e.g. /lib or your local mvn repo. If you're using lein for your authoritative builds, then it should work to `lein pom` each of them to get a pom.xml to use for the basis of your IntelliJ projects, and then rely on the IDE's workspace dependency resolution to tie them all together. - Chas On Aug 18, 2011, at 9:22 AM, J. Pablo Fernández wrote: > I'm currently using La Clojure. Not sure if I can directly hook it to lein. > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Video & Slides on Pattern Matching and Predicate Dispatch in Clojure
Hi, Am 18.08.2011 um 22:27 schrieb Laurent PETIT: > 2011/8/18 David Nolen > SlideShare link, http://www.slideshare.net/DavidNolen/patterns-8907600 > > Arrrgh, and now slideshare wants me to authenticate via FB or a slideshare > account if I want to download the slides, again. > > Ok, I've already got a slideshare account, so I'll try to remember the > password or go through the email roundtrip, but still, I can remember a time > where things were easier for non DRM material with scribd/slideshare ... ? Eh, what exactly does slideshare provide over a PDF put on some server somewhere? 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
Can't resolve .write
I'm trying to track down some reflection warnings in my code. There is one that I can't track down, however. Example: (def ID 4) (defn output [itm ^java.io.DataOutputStream stream] (.write stream ID) (.writeInt itm)) Reflection warning, NO_SOURCE_PATH:4061 - call to write can't be resolved. --- This however, works just fine: (defn output [itm ^java.io.DataOutputStream stream] (.writeInt stream ID) (.writeInt itm)) Why can the compile resolve .writeInt, but not write? Timothy -- “One of the main causes of the fall of the Roman Empire was that–lacking zero–they had no way to indicate successful termination of their C programs.” (Robert Firth) -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Clojure-CLR, CLASSPATH, clojure.load.path and Cygwin
Several comments: (a) 'clojure.load.path' is not new in 1.3. It's been in the code since at least May, 2009. (b) Regarding Dimitre's comment below, I probably did have Java system properties on my mind at the time. I guarantee that I was not thinking of picking Bash-compliant names. I doubt that I gave it much thought at all. (c) It could be changed to something like CLOJURE_LOAD_PATH instead. Would that cause a problem for anyone? -David On Aug 17, 3:25 pm, Dimitre Liotev wrote: > - A name like clojure.load.path breaks a widely accepted convention: > environment variable names usually consist of capital letters and > underscores. So we have MAVEN_HOME, JAVA_HOME, ANT_HOME, etc. When > I see a name like clojure.load.path my first thought would be that > this is a Java system property, not an environment variable. > > I think that it would be wise to stick to the convention and use > variable names that are Bash compliant. I would use CLOJURE_LOAD_PATH > for an environment variable name and clojure.load.path for a Java system > property name. > > -- > Dimitre Liotev -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Can't resolve .write
Hi, Am 19.08.2011 um 05:00 schrieb Timothy Baldridge: > I'm trying to track down some reflection warnings in my code. > > There is one that I can't track down, however. > > Example: > > (def ID 4) > > (defn output [itm ^java.io.DataOutputStream stream] > (.write stream ID) > (.writeInt itm)) > > Reflection warning, NO_SOURCE_PATH:4061 - call to write can't be resolved. > > --- > > This however, works just fine: > > (defn output [itm ^java.io.DataOutputStream stream] > (.writeInt stream ID) > (.writeInt itm)) > > Why can the compile resolve .writeInt, but not write? My suspicion is because there is only one writeInt. So there is no ambiguous choice. However there are two writes: write(int) and write(byte[]). So Clojure can't decide. If you hint ID to be an int, the warning will probably go away, no? 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
Re: REPL and Leiningen checkouts
Thanks for the reply Chas. Does that mean that I have to create a Java project inside IntelliJ, instead of just opening the directory containing a Clojure/Lein project? -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: REPL and Leiningen checkouts
A Maven project, yes. Just "mounting" a directory as a project and editing resources tells IntelliJ nothing about the projects in question. See: http://wiki.jetbrains.net/intellij/Creating_and_importing_Maven_projects#Importing_an_existing_Maven_project_into_an_IntelliJ_IDEA_project What I saw in a couple of bits of Intellij docs and a few message board threads is that it does indeed work similarly to Maven w.r.t. identifying and configuring cross-project source dependencies based on the Maven metadata. The caveat to that is that I don't actually use Intellij (or have it installed, even), so you're following the blind here. FWIW, the worst-case scenario is that you set module dependencies manually. Clearly not ideal, and I don't think it'll come to that. - Chas On Aug 19, 2011, at 2:17 AM, J. Pablo Fernández wrote: > Thanks for the reply Chas. Does that mean that I have to create a Java > project inside IntelliJ, instead of just opening the directory containing a > Clojure/Lein project? > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
