Re: Strings, Symbols, Keywords, Vars, NS, Type/Class…
Github page embeds your pdf as an image, browser sad. https://github.com/franks42/kitjensink/raw/master/extras/ClojureVarsNamespaceType6.pdf On Thursday, March 1, 2012 5:14:19 PM UTC-7, FrankS wrote: It is my experience that the way how these fundamental Clojure entities, like Strings, Symbols, Keywords, Vars, NS, and Type/Class, are related, is not so easy to figure out. This is not so much about programming Clojure, but more about getting a better feel how the language is held together one level below. I've created this graph that visually shows what core-functions will give you a var from a symb, a str from a ns, etc.: https://github.com/franks42/kitjensink/wiki/Symbs,-Vars,-NSs,-and-such; It's still work in progress, but compiling the info for this picture was already very therapeutic and enlightning. Any comments or suggestions how to improve are most welcome. --- One part that added to my confusion about how these different types are related, is the fact that the function signature and documentation is sometimes unclear and feels inconsistent. For example, different functions/macros let you pass a namespace as a string, a symbol-name, a quoted-symbol or a ns-instance, or some (arbitrary) combination. Sometimes a name refers to a symbol, sometimes a string, both in docs and in implementation… I often find myself getting exceptions thrown because I know a ns is expected, but I guessed wrongly about which type of ns-identifier that particular function demanded. Is that a common experience? Is that by design? (not being facetious - sometimes you want to throw exceptions if the wrong type is presented, or implementing all possible function signatures that would support an ns passed as string/symbol/instance simply adds too much additional testing). Regards, FrankS. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: ANN: ClojureScript revision 927 release
Weekend made. Thank you! -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Exception handling changes in Clojure 1.3.0
Would now be a bad time to observe there was a large change made to the way exceptions are handled, and the lack of guard-rails (no tests for exception handling behavior) may have contributed to this regression? https://github.com/clojure/clojure/commit/8fda34e4c77cac079b711da59d5fe49b74605553 On Tuesday, October 11, 2011 3:02:47 PM UTC-7, Stuart Sierra wrote: I was a little worried about this when the exception behavior for fns was changed. I think it's solvable, but don't know right now what the solution is. -S -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Exception handling changes in Clojure 1.3.0
Fair enough. :) Complete test coverage is intractable. But in clojure, there are only a handful of tests that contain a catch and none that test try/catch semantics. Maybe I'm looking in the wrong place... -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Exception handling changes in Clojure 1.3.0
I don't know what the right solution is either, but here is a JIRA ticket with an attached regression test. A start. http://dev.clojure.org/jira/browse/CLJ-855 On Tuesday, October 11, 2011 3:02:47 PM UTC-7, Stuart Sierra wrote: I was a little worried about this when the exception behavior for fns was changed. I think it's solvable, but don't know right now what the solution is. -S -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Reuse of generic Clojure/ClojureScript code?
Do you know if that solution will extend to sharing clojure core libraries where that makes sense (a lot of copy-n-pasted code in [core|set|string|walk|zip].cljs)? -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: autoboxing in 1.3 RC-0
I ran into this exact issue on an alioth benchmark. Adding the explicit (long ...) conversion gets rid of the reflection warning, but didn't have a significant effect on performance. The inner loop is still boxing the return value. On Thursday, September 15, 2011 8:36:53 AM UTC-7, Sean Corfield wrote: On Thu, Sep 15, 2011 at 7:50 AM, David Nolen dnolen...@gmail.com wrote: Loop itself will return boxed values I think. Looks that way. The following code has no reflection warning: (loop [x 1 changed 0] (if (= x 10) changed (recur (inc x) (long (loop [y 1 changed-y changed] changed-y) -- Sean A Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ World Singles, LLC. -- http://worldsingles.com/ Railo Technologies, Inc. -- http://www.getrailo.com/ Perfection is the enemy of the good. -- Gustave Flaubert, French realist novelist (1821-1880) -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: autoboxing in 1.3 RC-0
see https://github.com/clojure/test.benchmark/blob/master/src/main/clojure/alioth/mandelbrot.clj#L49 There's two ways to get rid of the reflection warning: 1) another function, appropriately type hinted 2) explicit conversion to long According to my measurements for this particular case, option 2 is fractionally faster by ~3% over option 1. Expectation would be the explicit conversion to long shouldn't be needed. On Thursday, September 15, 2011 8:16:10 PM UTC-7, pmbauer wrote: I ran into this exact issue on an alioth benchmark. Adding the explicit (long ...) conversion gets rid of the reflection warning, but didn't have a significant effect on performance. The inner loop is still boxing the return value. On Thursday, September 15, 2011 8:36:53 AM UTC-7, Sean Corfield wrote: On Thu, Sep 15, 2011 at 7:50 AM, David Nolen dnol...@gmail.com wrote: Loop itself will return boxed values I think. Looks that way. The following code has no reflection warning: (loop [x 1 changed 0] (if (= x 10) changed (recur (inc x) (long (loop [y 1 changed-y changed] changed-y) -- Sean A Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ World Singles, LLC. -- http://worldsingles.com/ Railo Technologies, Inc. -- http://www.getrailo.com/ Perfection is the enemy of the good. -- Gustave Flaubert, French realist novelist (1821-1880) -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Example of a real-world ClojureScript web application
Bit of copyright violation, that. If you want the Closure e-book, get a licensed copy. We should encourage legal means of obtaining information rather than post links to hosts that aren't authorized to distribute materials. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Stanford AI Class
+1 On Friday, August 12, 2011 3:16:15 PM UTC-7, Sergey Didenko wrote: BTW, Is there a case when AI self-modifying program is much more elegant than AI just-data-modifying program? I just can't figure out any example when there is a lot of sense to go the self-modifying route. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Creating a map algorithmically
For the sieve, if performance matters, clojure's native data structures may not be the best choice. A mutable array of boolean primitives could be more apropos. (defn prime-sieve [^long n] (let [^booleans sieve (make-array Boolean/TYPE (inc n))] ...) ... using aset/aget to write/read sieve. On Tuesday, August 9, 2011 1:18:46 PM UTC-7, Chouser wrote: On Tue, Aug 9, 2011 at 12:50 PM, Kevin Sookocheff kevin.so...@gmail.com wrote: Hi, I have a question regarding the map data structure. I'm trying to program a Sieve of Eratosthenes using the algorithm at Wikipedia: Input: an integer n 1 Let A be an array of bool values, indexed by integers 2 to n, initially all set to true. for i = 2, 3, 4, ..., while i^2 ≤ n: if A[i] is true: for j = i^2, i^2 + i, i^2 + 2i, ..., while j ≤ n: A[j] = false Now all i such that A[i] is true are prime. I'm having a problem creating the data structure A. What I want to do is create a map of integers from 2 to n all initialized to true that I can then prune using the algorithm. Any ideas? Since the keys are consecutive integers, you might consider a vector of booleans: (def A (vec (repeat (inc n) true))) You can then use assoc to set any particular index to false: (assoc A 5 false) Differences using a vector instead of a hash-map: will stay in numeric order, doesn't allow arbitrary dissoc, nth and assoc may be faster, use less memory, (vector-of :bool) will definitely use less memory, and probably others. Depending on your goals, a vector may or may not be preferable to a hash-map. --Chouser -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: ClojureScript Compile errors
Why all the attention to :use - I thought everyone agreed using it is a bad idea? Really? I thought it's use was only considered bad form in the absence of :only The only benefit I see is that you can avoid a (minimum 2 character) prefix. I would think the obvious benefit is its inclusion makes it easier port and share code between ClojureScript and Clojure. Every difference beyond the necessary (interop, no runtime compiler) makes re-use that much more difficult (see macro use, binding semantics, numerics, ns macro differences). Now if that's not a target and there is no expectation of sharing then all this is of course a non-issue. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: ClojureScript Compile errors
You don't need 'use' in production? ;) *ducks* On Friday, August 5, 2011 12:06:29 PM UTC-7, David Nolen wrote: On Fri, Aug 5, 2011 at 2:51 PM, Fogus mef...@gmail.com wrote: The following lines looks problematic: (ns mainpage (:use lib.dom-helpers)) That is, ClojureScript only supports the (ns foo (:require [a.b :as c])) form. Try changing your ns declaration accordingly. The error message could be slightly better I agree. ;-) :F Is there any particular reason / design rationale to not support use? 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: ClojureScript Compile errors
In Clojure, there is a clear distinction between using Clojure namespaces and importing interop packages. Is it a goal then to blur that line in ClojureScript? 'use' couldn't be used analogously just for ClojureScript names as it is in Clojure? On Friday, August 5, 2011 5:14:36 PM UTC-7, Rich Hickey wrote: On Aug 5, 2011, at 3:06 PM, David Nolen wrote: On Fri, Aug 5, 2011 at 2:51 PM, Fogus mef...@gmail.com wrote: The following lines looks problematic: (ns mainpage (:use lib.dom-helpers)) That is, ClojureScript only supports the (ns foo (:require [a.b :as c])) form. Try changing your ns declaration accordingly. The error message could be slightly better I agree. ;-) :F Is there any particular reason / design rationale to not support use? :use requires the ability to determine all the names in a namespace, something we don't generally have in ClojureScript, especially for JS pseudo-namespaces. Rich -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Libraries and build management hell
I might be able to disprove your scurrilous charge if ... I doubt that since your earlier assertion was factually incorrect. See mvn install:install-file http://maven.apache.org/guides/mini/guide-3rd-party-jars-local.html Not relevant. We were discussing use of lein deps. Wrong again. Lein shares a repository format and location with maven for dependencies. You would do well to educate yourself on a topic before picking an argument with those who are. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Libraries and build management hell
What if you have the JAR on a disk somewhere, for other reasons, but until now it wasn't a dependency of that particular project? Your assertion that dependency management systems are in any way disadvantaged to manual dependency management in terms of SPOF or requiring a network connection is merely incorrect. See mvn install:install-file http://maven.apache.org/guides/mini/guide-3rd-party-jars-local.html On Sunday, July 31, 2011 9:06:49 PM UTC-7, Ken Wesson wrote: On Sun, Jul 31, 2011 at 11:57 PM, Sean Corfield seanco...@gmail.com wrote: On Sun, Jul 31, 2011 at 7:49 PM, Ken Wesson kwes...@gmail.com wrote: If you add a new dependency, the network connection is needed. If you add a new dependency and you don't already have the JAR downloaded, you need a network connection one way or another to go get that JAR, yes? What if you have the JAR on a disk somewhere, for other reasons, but until now it wasn't a dependency of that particular project? -- 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: Possible Issue with Listing 11.5 from the Joy of Clojure
Please post all Errors and Corrections here http://www.manning-sandbox.com/thread.jspa?threadID=41321tstart=0 On Friday, July 29, 2011 9:10:00 PM UTC-7, Julien Chastang wrote: Thanks for your in-depth analysis. In conclusion, the 11.5 listing is broken specifically with the reification of the seq function. The problem is that the seq function allows the array reference to escape in an unsafe manner. The issue is concurrency as well as visibility. As you suggest, the only fix is to safely copy (via the locking function, i.e. synchronized block) the contents of the array into a data structure that would be passed back to the calling code. By the way, I still think you need a lock in the count function in the case where the caller tries to invoke the count function on a partially constructed object. You may be able to reason otherwise, but it is simply confusing to do so. Just access shared mutables in a safe manner and you will be OK. On Jul 29, 3:38 pm, Ken Wesson kwes...@gmail.com wrote: On Fri, Jul 29, 2011 at 3:19 PM, Julien julien.c...@gmail.com wrote: This listing is an attempt to make the function safe for concurrent modification. My claim is that count and seq should also be locking around a for exactly same reason as aget and aset. In particular, locking is not only ensuring mutual exclusion but also *visibility*. The danger is that count and seq may be accessing stale values of a. In the case of count that danger doesn't exist; Java arrays are of fixed size from creation, so the count value cannot change. The case of seq is trickier: the array can indeed change contents midway through iteration. But there's no simple fix. One could write something like (let [cnt (dec (count a)) step (fn step [i] (lazy-seq (if ( i cnt) (do (monitorexit a) nil) (cons x (step (inc i))] (monitorenter a) (step 0)) to hold a lock all the way through seq traversal, but if the seq is only partially traversed (either deliberately, or because of a thrown exception) the lock will never get released. More complicatedly, you could create a CloseableSeq defprotocol that extends ISeq and Closeable and create closeable seqs (line-seq could benefit from this as well); for the above the close operation would be (monitorexit a) (and for line-seq (.close rdr)). Closeable seqs could then be created in (with-open ...) and handled in an exception-safe manner -- so long as you made sure to consume or doall the seq before the end of the with-open scope. In the array seq case, the seq would still seem to work after the scope exited, but it would show an array in a possible state of flux again instead of a fixed state. Given all this complication, easiest might be (seq [this] (locking a (seq (into [] a which has the downside of copying the array into a vector but the upside of being thread- and exception-safe; the seq is backed by a fixed snapshot of the array. And can be traversed lazily and at leisure without holding onto a lock the whole time; the lock's held only during the copying. If you're worried about seeing inconsistent cell values during a traversal of a short array this is what you ought to use. But you should probably prefer to avoid arrays for the most part. :) Note: you will still potentially see *stale* values; the array can change after the snapshot is made. To avoid that you'd always have to lock during the operation where you want to be seeing the most up to date values. But you wouldn't see *inconsistent* values. If the array contains all 1s, and then someone else locks it, changes each cell to 2, and unlocks, and you are traversing the seq given above, you might get back (1 1 1 1 2 2 2 ...) which violates the intended invariant of all-the-same-number. With the snapshot you'll possibly see all-1s even after it's been updated to all-2s but you will never see a mixture. With locking the array the whole time you're working with the seq, you'll see all-2s if the array was ever updated to all-2s and otherwise the thing that will eventually update it to all-2s will block until you're done with the seq. See Java Concurrency in Practice, Section 3.1 for more of a discussion. My reasoning is based on the assumption that locking is simply an abstraction for the Java synchronized keyword. That assumption may or may not be correct. It is correct, though Clojure exposes the lower-level monitorenter and monitorexit; both Java synchronized and Clojure locking boil down to (the bytecode emitted by) (try (monitorenter foo) ... (finally (monitorexit foo))) so as to ensure the lock is released even if an exception is thrown out of the critical section. Java just
[ANN] (first phoenix-clojure-user-group-meetings)
Announcement Link, details: https://groups.google.com/d/topic/clj-phx/l_S4qcOSuaY/discussion August 30th, 6:30 PM Food provided. Please use the group mailing list for replies, RSVPs ( http://groups.google.com/group/clj-phx) Hosted by *Shutterfly http://www.shutterfly.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: format and printf can't be used with BigInt
That wasn't called for. Given Stu linked to the page (and is linked in the 1.3 release notes), it's reasonable to assume the permission error is merely a mistake and not some nefarious plot to withhold information from the Clojure community. On Thursday, July 28, 2011 4:48:34 PM UTC-7, Ken Wesson wrote: On Thu, Jul 28, 2011 at 7:30 PM, Sean Corfield seanco...@gmail.com wrote: I think one of the authors / core members needs to change the permissions. I have edit access on the parent page http://dev.clojure.org/display/doc/Enhanced+Primitive+Support and the sibling page http://dev.clojure.org/display/doc/Bit+Operations but, like you, don't have view access to the Numerics page. On Thu, Jul 28, 2011 at 7:27 AM, Perry James perry...@computer.org wrote: You cannot view this page I can't think of a single good reason why any of these pages should not be world-readable. We're an open source project. It's not as if we have trade secrets or something. I have no problem, of course, with restricting *edit* privileges to those with accounts that have proven to be responsible adults. -- 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
Clojure User Group, Phoenix
Anyone in the Phoenix area care to help start a Clojure user group? http://clj-phx.wikispaces.com/Startup+Discussion -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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 User Group, Phoenix
Great! I've created a mailing list: http://groups.google.com/ http://groups.google.com/group/clj-phx group/clj-phx http://groups.google.com/group/clj-phx On Thursday, July 28, 2011 8:17:14 PM UTC-7, Charlie Griefer wrote: On Thu, Jul 28, 2011 at 8:12 PM, pmbauer paul.mich...@gmail.com wrote: Anyone in the Phoenix area care to help start a Clojure user group? http://clj-phx.wikispaces.com/Startup+Discussion I'm in. I'm a total n00b, but I'm definitely in. -- Charlie Griefer http://charlie.griefer.com/ I have failed as much as I have succeeded. But I love my life. I love my wife. And I wish you my kind of success. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: The Number of Clojure (Was: Alright, fess up, who's unhappy with clojurescript?)
These unhappy threads need to die a horrible death. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: better community docs: getting started
I do not think we should attempt a recommended IDE (not even Clooj). We should offer a path for all existing IDEs / editors. ... Use an editor not listed here? Try Clooj (i.e., use this as a simple catch-all if we haven't covered what you already used today). That's one way of organizing it. The slightly serious explorer will of course pick setup documentation for their favorite IDE/editor, and that should be provided. But think of the casual dev wanting to know what Clojure and a typical Clojure toolchain can do for her ASAP. Most Java devs have never used a repl-aware edit buffer, something most of us take for granted. No common IDE/editor setup can expose her to a lisp-style toolchain in a single click. None. For usability, nothing beats the single-click. In seconds, Clooj gives her a one-stop-shop. So I see Clooj as something worth putting right along with try-clojure.org. It not only showcases Clojure, but is rapid exposure to the lisp-style toolchain. That's why I would give Clooj some prominence rather than burying it at the bottom of the decision tree. Anyone knowing what they're looking for will of course move on to the setup of their preference (emacs,vi,eclipse), so they don't lose anything. But the neophyte who doesn't know what they're looking for should have the lowest barrier to entry possible - usability. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Alright, fess up, who's unhappy with clojurescript?
Fair point, but Rhino doesn't always have the correct semantics. For example, one common JS idiom for default params: eval(undefined || 2 + 2) = returns true instead of 4 But mostly, Rhino is just a JS engine with no DOM, so is less than ideal for browser UI development. I do so hope however that someone manages to pull that out for a lets run this NOW on Java 7 as that would be a great improvement over rhino. Does it really matter? Nobody would really deploy ClojureScript based on Rhino, right? As long as Rhino has the correct semantics its fine as a repl. We allready have a programming language that runs fast on the JVM, its called clojure. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: better community docs: getting started
+1 on clooj. One click and you have a working build environment, REPL, and REPL-aware editor. https://github.com/downloads/arthuredelstein/clooj/clooj-0.1.5-standalone.jar -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Leiningen on OpenBSD
FWIW, lein and JDK 1.7 play fine together on both my linux systems (Ubuntu 10.10 and 11.04). -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: better community docs: contrib
Would be glad to help. I have a JIRA account (CA signed, etc) but no perms to add/edit pages. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: better community docs: contrib
P.S. JIRA account ID: pmbauer -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: BUG REPORT: ClojureScript : Portable Path Support
I know. But the sorts of (presently non-portable) scripts in scripts (see bootstrap, repl) ad-hoc test strategy, etc in ClojureScript are begging for dependency management and a build tool. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: BUG REPORT: ClojureScript : Portable Path Support
If ClojureScript isn't mavenified, how else do you easily make it a dependency in a web application? -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: :require farms in Clojure?
Something akin to the clj-nstools ns+ in clojure proper would sure make life easier. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: BUG REPORT: ClojureScript : Portable Path Support
Fair enough. But, it would be nice to eventually have a ClojureScript jar available in a public maven repo someplace. Not having one would needlessly complicate projects that already use a maven-based build tool (mvn, lein, cake) and want to depend on it as part of their build. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: BUG REPORT: ClojureScript : Portable Path Support
Fair enough. That addresses my concern. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
BUG REPORT: ClojureScript : Portable Path Support
Per instructions from redinger and jgehtland (patch addressing one issue
attached).
Three separate issues so far re: path support on windows
* compiler path regex is not portable, cljs/compiler.clj:1096 (see attached
patch, thanks amalloy for the assist)
* generated JS has path problems on windows
goog.addDependency(*
..\..\..\..\..\..\..\/C:/tmp/clojurescript/samples/twitterbuzz/out/cljs/core.js
*, ['cljs.core'], ['goog.string', 'goog.string.StringBuffer', 'goog.object',
'goog.array']);
* helper launch scripts on windows (under cygwin), more a feature than bug
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=enFrom 6b7b35504af661e16fc24487d309719cda974d31 Mon Sep 17 00:00:00 2001
From: unknown pba...@.corp.shutterfly.com
Date: Wed, 20 Jul 2011 18:56:19 -0700
Subject: [PATCH] Made path pattern portable.
---
src/clj/cljs/compiler.clj |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
mode change 100644 = 100755 src/clj/cljs/compiler.clj
diff --git a/src/clj/cljs/compiler.clj b/src/clj/cljs/compiler.clj
old mode 100644
new mode 100755
index b1f2213..b7090b0
--- a/src/clj/cljs/compiler.clj
+++ b/src/clj/cljs/compiler.clj
@@ -1093,7 +1093,7 @@ goog.require = function(rule){Packages.clojure.lang.RT[\var\](\cljs.compiler\
(defn path-seq
[file-str]
- (string/split file-str (re-pattern java.io.File/separator)))
+ (string/split file-str (re-pattern (java.util.regex.Pattern/quote (java.io.File/separator)
(defn to-path
[parts]
--
1.7.5.1
Re: Results from 2011 State of Clojure survey
On Tuesday, July 12, 2011 6:18:12 PM UTC-7, Chas Emerick wrote: I hesitate to go even more meta, but since I started the thread, I thought I would say: I talked for a bit in the results post about mailing list threads going into the weeds; at least IMO, this one qualifies. It wouldn't be the worst thing in the world if it died right here. :-) Cheers, - Chas Too late. Your thread has been YAKT (Yet Another Ken Thread). -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Which Clojure environments support arglist-on-space?
Slimv supports this for clojure via swank. http://www.vim.org/scripts/script.php?script_id=2531 -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Contagious BigDecimals?
If you add an inexact number and an exact number, the only thing that makes sense is to return something that is inexact. So why then are double's contagious when mixing double and float values in a calculation? Doubles and floats are both inexact, but floats are at least less exact than doubles. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Contagious BigDecimals?
(re: why then...) P.S. I mean in more general context of how double contagion is handled in most languages. Clojure 1.3 alphas auto-promote floats to doubles in almost every case eg. exception: (type (float 1.0)) On Monday, May 23, 2011 4:16:48 PM UTC-7, pmbauer wrote: If you add an inexact number and an exact number, the only thing that makes sense is to return something that is inexact. So why then are double's contagious when mixing double and float values in a calculation? Doubles and floats are both inexact, but floats are at least less exact than doubles. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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 1.3 Alpha 7
Use Case: Auto-generated record - relational mapping? Tables with more than 19 columns is not unheard of. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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 stack
The official way to get started has way too many sharp edges (Download JDK, install, set JAVA_HOME, add JAVA_HOME/bin to path, download clojure.zip, extract, sacrifice chicken, run java -cp clojure.jar clojure.main) ... at which point you get a kinda crappy REPL. Oops. Compare to (on linux): sudo apt-get install groovy; groovysh # even installs openjdk if needed -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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 stack
The recommended way definitely should be one of the painless installs. This works: * Download NetBeans, configuring on the NB homepage for J2SE, and run installer So does this: * Download Eclipse J2SE Sure, but that's still a lot of work just to get a simple repl. The easiest way (by far, and it doesn't work on Windows): $ wget https://github.com/technomancy/leiningen/raw/stable/bin/lein; lein repl clojure.org and the standard distro could use a little tlc. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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 stack
If ALL you want is a SIMPLE repl you can just go to the tryclojure site. :) Not quite. As far as official disto's go, the current state is a little raw for getting started And having the official getting started instructions be (as you suggested) So now you go download this 100MB IDE is a little heavy. No? There's room for something in-between. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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 stack
Mmm, not quite. Doesn't clojure run just fine with the 15MB JVM? -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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 stack
I'm beginning to think this has degenerated a bit into argument for arguments sake. Yes, JRE. You don't need the JDK to read/eval .clj files. And in the context of where this all started, namely, critiques to the current getting started experience for new users, a 75MB JDK + 100MB IDE is exactly the sort of heavyweight, intimidating experience that detracts from initial exposure. Clojure isn't just competing with Groovy, Scala, and other JVM languages for developer attention. Websites like try-clojre.org have their place, but aren't really in this context. Official support for a starter kit that automatically downloads or packages clojure, jline, etc would go a long way to lowering barrier-to-entry. Lein is one such option, but unlikely to get official recognition giving clojure/core's (arguably correct) decision to stick to maven. Groovy is really exemplary in this regard: installer on windows, .deb/apt packaging on linux (clojure has one, but it's 1.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
Re: Clojure stack
I've found the community to be very friendly and helpful. The problem is that the entire contents of the clojure.org site is written by an expert, for experts. ...and necessary. More verbose, newbie-friendly docs are important too, but take a lot more time and effort (clojuredocs.org, clojureatlas.com have great promise in this regard) So I don't think this newbie-unfriendliness is out of malice or arrogance as much as perhaps one of focus and lack of resources. Great newbie-friendly docs, starter kits, etc. take time and work - work that's honestly tedious compared to implementing a new concurrency construct or blazing fast primitive support. And in fairness, if you have the mind to do the latter, I'd rather not have that person wasted working on the former. Granted there are broken windows on clojure.org that detract from its image: e.g. * spotty details on the contribution process (info scattered between jira, clojure.org, mailing list, no process info links on github) * missing info/visiblity on state of clojure.next * public hudson server often showing builds broken for weeks/months EXAMPLE 2: Cryptic code single-character variables That it is a bit of an eye-brow-raiser for people of the Uncle Bob clean coder school that emphasizes verbose, literate naming conventions. It's something to get used to - every language has its idioms. The biggest inhibitor by far for adoption is tool support (unless you attend the Church of Emacs). Compared to Scala and (especially) Groovy, Clojure tool quality is green, but acceptable for a three-year-old language. These things take time. https://twitter.com/#%21/stuartsierra *It wouldn't be Lisp without existential angst @stuartsierrahttps://twitter.com/#%21/stuartsierra * -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Joy of Clojure errata: Chapter 5
Sorry; I don't really care for web forums much. I think mailing lists and Usenet are much to be preferred. Please do use Manning's forum for this. Actually, I can't. My copy is borrowed, for now, rather than my own, so I don't have an account there. Actually, you can. You just have to take a few minutes to create an account so errata can go to the appropriate place. http://www.manning-sandbox.com/accountCreate!default.jspa -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Joy of Clojure errata: Chapter 5
Manning's forum would be a better home for errata than the Clojure mailing list. http://www.manning-sandbox.com/forum.jspa?forumID=624 -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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 contrib build failure on win7
clojure-contrib was left broken 1.5 months past. clojure/core are no longer maintaining the monolithic clojure-contrib library as it is deprecated. A bunch of new projects are starting to fill the void (see listing at https://github.com/clojure) Some functionality isn't making the migration - some from lack of support - and much work is left. For details: http://dev.clojure.org/display/design/Clojure+Contrib -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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 Atlas now available (an experimental visualization of the Clojure language standard library)
ALT-[LEFT|RIGHT] ARROW - nav back/forward I was very pleased to have proper browsing history support - great way to do breadcrumbs. P.S. When I started learning clojure a year ago, one of the biggest pain points was not having a resource like this. Dynamic languages, in general, and clojure, in particular, lack the self-documenting relational ontology that static language jocks take for granted. It's difficult to quickly find relationships (e.g. find all the functions that operate on ISeq or Seqable); having half of Clojure implemented in Clojure and the other half in Java doesn't make it easy to automate this navigation with tools either. Major kudos on this. On May 3, 4:39 pm, Chas Emerick cemer...@snowtide.com wrote: On May 3, 2011, at 6:06 PM, Sean Corfield wrote: It's a very cool way to visualize the Clojure world and to explore what's available. One thing I found - which would definitely stop me paying for it as-is - I get lost when I drill down: there's no way to navigate 'back' to what I was looking at and no sense of history (like a crumb trail). Messing around with the demo I just realized I can use the browser back button / hot key but that feels clunky - being able to navigate more easily with keyboard shortcuts within the atlas itself would make it a lot nicer to use. Perhaps left arrow / right arrow to go back / forward thru the direct history and up arrow / down arrow to jump up and down the hierarchy? That's interesting; I very intentionally built in proper support for browser back/forward actions (as you discovered), thinking that that would be a good local maxima in terms of history navigation. FWIW, click-and-hold on the back or forward buttons in your browser will give you the breadcrumbs you're looking for. I'm not entirely convinced that left/right shortcuts would make sense — that would simply map to back/forward in the browser, which already have keyboard shortcuts. I'll think about it for a bit. I'd like to plumb at this up/down notion a bit. Perhaps it's not clear, but the ontology is not a hierarchy – there absolutely are cycles in its graph. For example: http://www.clojureatlas.com/org.clojure:clojure:1.2.0?guest=Y#clojure... Which way is up (or down) from isa? here? It doesn't appear to include any of the contrib libraries (I know that's a mammoth task for 1.2.0). Do you plan to include the new contrib libraries in 1.3.0 since they seem more integrated now? I hope that Clojure Atlas will include contrib libraries in the future, though I can't imagine I'll be building the ontologies for them. As you say, 1.2.0 contrib is large, but new contrib is likely to get much, much larger (presumably larger than the standard library) since contributing to it is far easier than classic contrb. I'm thinking about various ways to allow for community-constructed ontologies for various libraries, including contrib of all versions. - 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
Re: Future of clojure.contrib.core/-? macro
clojure/core use an alternative workflow to typical OSS on github, so the eqqon link is not apropos. The clojure github readme doesn't advertise the workflow, but you can find it here: http://clojure.org/contributing http://clojure.org/patches On Apr 20, 1:44 am, Ivan Koblik ivankob...@gmail.com wrote: Hello Konrad, Git workflow is a little bit different. You don't really need commit rights to contribute. I found a rather nice explanation of Git workflow here:http://www.eqqon.com/index.php/Collaborative_Github_Workflow Hope it helps. Cheers, Ivan. On 19 April 2011 16:40, Konrad Hinsen konrad.hin...@fastmail.net wrote: On 19 Apr, 2011, at 13:56 , Stuart Halloway wrote: Concerning my own modules in old contrib, there are three that I use myself and that I am planning to maintain, independently of where they will end up: - clojure.contrib.monads - clojure.contrib.macro-utils - clojure.contrib.generic There is an empty repos already waiting for your macro utils: https://github.com/clojure/tools.macro Great, thanks, I'll start with that one. Monads depend on it anyway. But I need commit permissions, which I probably don't have, but I don't even know how to find out without trying to do a commit. Can you please add me in the right place? My github account is khinsen. I have put some suggested names for the other new projects at http://dev.clojure.org/display/design/Contrib+Library+Names. Please review and comment, either there or here on the list. It seems that for now the top-level namespaces (well, next-to-top) are - clojure.core - clojure.data - clojure.java - clojure.tools I would like to suggest a new one, clojure.control, for control structures. This would be the natural home for monads, but also for parallelization frameworks and even for threading macros. None of this really fits into data or tools. If the goal is to keep the number of top-level namespaces as small as possible, I'd even propose to put clojure.contrib.generic under that label. Otherwise, I'd propose yet another namespace, clojure.interfaces, where the various submodules of generic would find their home next to other protocols and interfaces of general interest. Konrad. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Future of clojure.contrib.core/-? macro
Ivan, clojure/core use a different workflow than is typical for github projects. The github readme doesn't indicate, but you may find the process here: http://clojure.org/contributing http://clojure.org/patches Cheers, pm On Apr 20, 1:44 am, Ivan Koblik ivankob...@gmail.com wrote: Hello Konrad, Git workflow is a little bit different. You don't really need commit rights to contribute. I found a rather nice explanation of Git workflow here:http://www.eqqon.com/index.php/Collaborative_Github_Workflow Hope it helps. Cheers, Ivan. On 19 April 2011 16:40, Konrad Hinsen konrad.hin...@fastmail.net wrote: On 19 Apr, 2011, at 13:56 , Stuart Halloway wrote: Concerning my own modules in old contrib, there are three that I use myself and that I am planning to maintain, independently of where they will end up: - clojure.contrib.monads - clojure.contrib.macro-utils - clojure.contrib.generic There is an empty repos already waiting for your macro utils: https://github.com/clojure/tools.macro Great, thanks, I'll start with that one. Monads depend on it anyway. But I need commit permissions, which I probably don't have, but I don't even know how to find out without trying to do a commit. Can you please add me in the right place? My github account is khinsen. I have put some suggested names for the other new projects at http://dev.clojure.org/display/design/Contrib+Library+Names. Please review and comment, either there or here on the list. It seems that for now the top-level namespaces (well, next-to-top) are - clojure.core - clojure.data - clojure.java - clojure.tools I would like to suggest a new one, clojure.control, for control structures. This would be the natural home for monads, but also for parallelization frameworks and even for threading macros. None of this really fits into data or tools. If the goal is to keep the number of top-level namespaces as small as possible, I'd even propose to put clojure.contrib.generic under that label. Otherwise, I'd propose yet another namespace, clojure.interfaces, where the various submodules of generic would find their home next to other protocols and interfaces of general interest. Konrad. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
