Re: Code arrangement for understandability
On Thu, Dec 10, 2009 at 09:13:33AM -0800, samppi wrote: >notation before, and it is fine. For my tastes, however, I think that >it repeats the symbol (in this case, 'x) too much. Sometimes it may be >the best way, but usually I would instead use ->, ->>, and/or letfn. The problem I have using -> and ->> is that I often find inconsistency as to which argument the value should be placed at. 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: Renaming 1.1.0-alpha-SNAPSHOT is causing problems with projects on Clojars
liebke writes: > I like the new naming scheme, but would it be possible to add 1.1.0- > alpha-SNAPSHOT back to the repository (in addition to the new names), > so that builds dependent on projects in Clojars will be able to > download their dependencies correctly again, at least until everybody > gets a chance to upload new poms to Clojars? The jars with the old version number haven't disappeared, have they? Projects relying on -alpha should still work, they will just not get the latest and greatest version of Clojure. Please speak up if you've noticed otherwise, but that's my understanding. -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: Slides that accompany the Rich's QCon talk
On Dec 11, 12:21 am, Dragan Djuric wrote: > HI, > > I have just watched Rich's QCon talk and in some parts he is referring > to the slides that are not displayed in the video. Of, course, the > talk is perfectly fine without that, but I need to understand some > specific tricky details, and I believe that the referred slides would > help. Are they available? QCon and JAOO conferences make the slides available online http://qconlondon.com/london-2009/schedule/thursday.jsp /Karl -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: dumb noob ceremony question
> (clojure.set/union #{1} #{2})
>
> what'd I do wrong, please & thanks?
Nothing wrong!
Try this:
(use 'clojure.set)
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
dumb noob ceremony question
I'd like to say
(union #{1} #{2})
but I'm forced to say
(clojure.set/union #{1} #{2})
what'd I do wrong, please & 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: Main class not found when starting clojure: java -cp clojure.jar clojure.lang.Repl
On Dec 9, 2009, at 3:54 PM, HerbM wrote: > As I was preparing the post a message requesting help for > an error (see below) generated when I entered the quick start > suggest, I realized that suggestion is generic, and not technically > accurate. > >java -cp clojure.jar clojure.lang.Repl > > Many people may give up without realizing that the VERSION > specific name of the clojure jar must be substituted instead > >java -cp clojure_1.0.0.jar clojure.lang.Repl > > While this is entirely obvious once it has been noticed even > once, I figured posting it might help someone else and might > suggest editing the "QuickStart" page recommendation. Good catch! Thank you for pointing this out. The quick start suggestion given in the readme.txt is actually a common way to start Clojure. A clojure.jar file (with that exact name) is generated when you build Clojure from its sources. That file wasn't included in the 1.0.0 distribution, though. We'll need to make sure that the zip file for Clojure-1.1.0 is internally consistent and whatever instructions are included with it are up to date and work out of the box. clojure.lang.Repl is also no longer the canonical way to launch a Clojure repl. For Clojure 1.0.0, the suggestion should have been: java -cp clojure-1.0.0.jar clojure.main I hope your continued explorations of Clojure are much more fun than getting past this initial hurdle! Thanks, --Steve smime.p7s Description: S/MIME cryptographic signature
Re: how 'bout a debug-repl?
It's definitely on my todo list. But probably like yours, that list ain't short. On Dec 10, 12:56 pm, kyle smith wrote: > Yes, I just figured that out. Is there a way to use this with slime? -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Code arrangement for understandability
> The spy macro from c.c.logging does that. ;) I knew it was there somewhere; I just couldn't remember where, or what it was called! :) -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Code arrangement for understandability
On Dec 10, 11:02 am, Richard Newman wrote: > > They're especially useful for inserting println calls for seeing the > > value of something when I'm debugging; in fact, this is the primary > > way I do debugging. > > (defn tee (x) > (println "Debug: " (prn-str x)) > x) > > (let [x (tee (foo 1))] > ...) The spy macro from c.c.logging does that. ;) -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: update-in and get-in why no default?
Seconded; I like the intention of both changes, and do something
similar in a lot of my code (e.g., parsing functions that take an
extra arg if the parse is unsuccessful). Also, testing the type of
update-in2's second arg is a bad idea, imo.
As for the breaking change of adding another arg to update-in, I can't
think of a time when nil was actually the default value I wanted
there, though sometimes the function I was using behaved well with
nils (e.g., conj). In every other case, I had to explicitly handle
nils (e.g., inc).
I don't have a lot of production code that would need retrofitting, so
I'm inclined to prefer breaking things for the better (at least while
things are young). I imagine others might feel differently.
On Dec 10, 7:27 am, Sean Devlin wrote:
> Tim,
> I like both of these ideas. I agree, get-in2 seems to make sense as a
> drop in replacement.
>
> With update-in2 I prefer a new name, because I do occasionally write
> code that constructs lists of functions. I'd hate to get a weird bug
> while doing this.
>
> Sean
>
> On Dec 10, 7:20 am, Timothy Pratley wrote:
>
>
>
> > Hi,
>
> > update-in is an especially useful function but I find the update
> > function inevitably requires a check for nil. If I could supply a not-
> > found value then my code would get better golf scores.
>
> > When I reach for update-in, I usually want to pass it a numerical
> > operator like inc or +, but these don't play nicely with nil. Another
> > scenario is when I want to pass conj, which is fine if I want to
> > create lists, except if I usually want the data structure to be
> > something else. I've never come across a scenario where I didn't want
> > to supply a not-found value, are there any common ones?
>
> > If others have similar experience perhaps it is a candidate for
> > change. Ideally I'd like to see a not-found parameter added to update-
> > in and an extra arity overload for get-in as outlined below:
>
> > (defn update-in2
> > "'Updates' a value in a nested associative structure, where ks is a
> > sequence of keys and f is a function that will take the old value
> > and any supplied args and return the new value, and returns a new
> > nested structure. If any levels do not exist, hash-maps will be
> > created. If there is no value to update, default is supplied to f. "
> > ([m [k & ks] not-found f & args]
> > (if ks
> > (assoc m k (apply update-in2 (get m k) ks f args))
> > (assoc m k (apply f (get m k not-found) args)
>
> > user=> (reduce #(update-in2 %1 [%2] 0 inc) {} ["fun" "counting"
> > "words" "fun"])
> > {"words" 1, "counting" 1, "fun" 2}
> > user=> (reduce #(update-in2 %1 [(first %2)] [] conj (second %2)) {}
> > [[:a 1] [:a 2] [:b 3]])
> > {:b [3], :a [1 2]}
>
> > (defn get-in2
> > "returns the value in a nested associative structure, where ks is a
> > sequence of keys"
> > ([m ks]
> > (reduce get m ks))
> > ([m ks not-found]
> > (if-let [v (reduce get m ks)]
> > v
> > not-found)))
>
> > user=> (get-in2 {:a {:b 1}} [:a :b] 0)
> > 1
> > user=> (get-in2 {:a {:b 1}} [:a :b :c] 0)
> > 0
>
> > Changing update-in would be a breaking change unfortunately. To avoid
> > this you could consider checking the argument type for f to be
> > function or value (making an assumption here that you would rarely
> > want a function as the not-found value which is not 100% watertight).
> > Or you could have a similarly named update-in-or function (which is
> > less aesthetically pleasing), or maybe there is another even better
> > way?
>
> > Thanks for your consideration.
>
> > Regards,
> > Tim.
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from 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: Pull request for clojure.contrib.sql?
On Dec 10, 2009, at 7:18 PM, Graham Fawcett wrote: > Thank you! I'm already a registered Clojure contributor. Tomorrow I'll > prepare a ticket and attach the patch. Excellent! > If you'd rather discuss it first on or off-list, let me know & I'll > hold off on the ticket. Please do put in a ticket and attach a patch. If we need to discuss more, that will form the basis. Thanks! --Steve smime.p7s Description: S/MIME cryptographic signature
Re: Expanding the unit tests for clojure
Thanks for updating my clojure-dev membership On Dec 10, 1:33 pm, devender wrote: > Hi, I am interested in expanding the unit test coverage for clojure, I > have signed and mailed in the Agreement and my name now appears on the > clojure contributer page. Could someone PLEASE take my patches and > apply it to the code ? > > Yes I did read "Before you invest time working on a change, discuss > what you're trying to do with others on the Clojure Dev Google group. > They're likely to be able to offer comments and suggestions that will > result in a higher-quality change and a smoother submission process." > > But how do I post anything on the 'Clojure Dev' group if my membership > is always in "pending status". It is really frustrating. I have tried > sending message through github but no one seems to respond. > > -Devender -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Refs scalability
Dragan Djuric writes: > Is it a good idea, from the performance standpoint, to use many refs > in the program? By many, I mean thousands or even millions? The question isn't how many refs you should instantiate, it's how many refs you should read or write to at once in a transaction as well as how many transactions you expect to run at once. The place you'll run into perf issues is with transaction retries. The best (only?) way to know is to measure, I think. -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: Pull request for clojure.contrib.sql?
Hi Steve, On Thu, Dec 10, 2009 at 4:53 PM, Stephen C. Gilardi wrote: > Hi Graham, > >> To whom should I send a pull-request for an enhancement for >> clojure.contrib.sql? I see that scgilardi is listed as the author, but >> I'm not very clear on how the contrib community works. > > The contributing process is described at: > > http://clojure.org/contributing > > The patch submission process (once you're a registered contributor) is > described at: > > http://clojure.org/patches > > The underlying idea sounds good on a quick read. I'll take a look and see if > I have any ideas along those lines. Thank you! I'm already a registered Clojure contributor. Tomorrow I'll prepare a ticket and attach the patch. If you'd rather discuss it first on or off-list, let me know & I'll hold off on the ticket. Best, Graham > > --Steve > > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Renaming 1.1.0-alpha-SNAPSHOT is causing problems with projects on Clojars
It looks like renaming the version of Clojure in the build.clojure.org repository from 1.1.0-alpha-SNAPSHOT to 1.1.0-master-SNAPSHOT will require every project previously uploaded to Clojars, using the former name, to rewrite its pom and resubmit. I like the new naming scheme, but would it be possible to add 1.1.0- alpha-SNAPSHOT back to the repository (in addition to the new names), so that builds dependent on projects in Clojars will be able to download their dependencies correctly again, at least until everybody gets a chance to upload new poms to Clojars? 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
Refs scalability
Is it a good idea, from the performance standpoint, to use many refs in the program? By many, I mean thousands or even millions? -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Slides that accompany the Rich's QCon talk
HI, I have just watched Rich's QCon talk and in some parts he is referring to the slides that are not displayed in the video. Of, course, the talk is perfectly fine without that, but I need to understand some specific tricky details, and I believe that the referred slides would help. Are they available? -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Fine-grained locals clearing
> Also, it may be very useful to try all your code on 'new' *without* > taking > advantage of the new features, and reporting back on any > breakage. That's more what I was thinking. While I find the new features interesting, I'm less jazzed about spending the time to build on features that might go away. (Chicken and egg, of course.) It sounds like it's mostly the bleeding edge of `new` that's bleeding, so to speak, and the stable part is fairly reliable. If that's a correct impression, then it's probably worth developing against it. I'm not overly concerned about the occasional regression, because it's easy enough to switch to master to verify. It's systematic regression that I'd like to avoid. > You won't have to wait too long though, I suspect. Once 1.1 is > out the door I assume 'new' will be merged into 'master' fairly > quickly. All the more reason to bang on it now, I suppose! -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Pull request for clojure.contrib.sql?
Hi Graham, > To whom should I send a pull-request for an enhancement for > clojure.contrib.sql? I see that scgilardi is listed as the author, but > I'm not very clear on how the contrib community works. The contributing process is described at: http://clojure.org/contributing The patch submission process (once you're a registered contributor) is described at: http://clojure.org/patches The underlying idea sounds good on a quick read. I'll take a look and see if I have any ideas along those lines. --Steve smime.p7s Description: S/MIME cryptographic signature
[RFC/patch] teaching duck-streams to support byte streams
I've posted an attempt to teach duck-streams to be as convenient for byte streams as it now is for textual streams. I'm looking for review and feedback and hoping for inclusion in clojure-contrib. http://wiki.github.com/bpsm/clojure-contrib/about-branch-ducks-byte http://github.com/bpsm/clojure-contrib/tree/ducks-byte // Ben -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Expanding the unit tests for clojure
Hi, I am interested in expanding the unit test coverage for clojure, I have signed and mailed in the Agreement and my name now appears on the clojure contributer page. Could someone PLEASE take my patches and apply it to the code ? Yes I did read "Before you invest time working on a change, discuss what you're trying to do with others on the Clojure Dev Google group. They're likely to be able to offer comments and suggestions that will result in a higher-quality change and a smoother submission process." But how do I post anything on the 'Clojure Dev' group if my membership is always in "pending status". It is really frustrating. I have tried sending message through github but no one seems to respond. -Devender -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Idiomatic way to return the key of a map, which matches a vector containing a search value.
Hi,
Am 10.12.2009 um 20:40 schrieb mudphone:
> So, I have a search string, for example "rabble". And a map which
> contains keyword keys, and vectors of strings as values:
>
> (def players
> {
> :amit ["a" "b" "c"]
> :roger ["rabble" "x" "y"]
> })
>
> (defn key-from-match [search-str]
> (let [key-of-str? (fn [entry-pair]
> (if (some #(= (munge-str search-str) %)
> (val entry-pair))
>(key entry-pair)))]
>(some key-of-str? (players))
>))
How about this:
(def players {:amit ["a" "b" "c"]
:roger ["rabble" "x" "y"]})
(def reverse-players (reduce (fn [rplay [player values]]
(into rplay (map vector values (repeat player
{} players))
(defn key-from-match
[search-str]
(reverse-players (munge-str search-str)))
Sincerely
Meikel
smime.p7s
Description: S/MIME cryptographic signature
Pull request for clojure.contrib.sql?
Hi folks, To whom should I send a pull-request for an enhancement for clojure.contrib.sql? I see that scgilardi is listed as the author, but I'm not very clear on how the contrib community works. My patch provides an :external key to (get-connection), which lets you pass in an existing db connection instead of a db spec. This makes it trivial to get get c.c.sql to work with (for example) a Proxool db connection pool. http://github.com/gmfawcett/clojure-contrib/commit/c74833d5972eaf9357fdd9fd5da6f6bf7f1769bc Proxool: http://proxool.sourceforge.net/ Best, Graham -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Fine-grained locals clearing
I can't express how thrilled I am that you did this work.Thanks so much - since I've run into a few of these classes of bugs, I'll see if I can switch over to new and try to run against some big data sets and give some feedback, if I can find the time. On Dec 10, 6:10 am, Rich Hickey wrote: > I'm happy to announce I have implemented this fine-grained locals > clearing in the compiler, in the 'new' branch. It should automatically > cover all cases in which the code doesn't explicitly reuse the head - > including non-tail usage, destructuring etc. In short, such cases > should 'just work' from now on. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Fine-grained locals clearing
On Thu, Dec 10, 2009 at 2:26 PM, Richard Newman wrote: >> +1 As cool as the new branch is, this is the first compelling reason >> I've seen to go to my boss and say we need to switch to it now. >> >> Thanks Rich! > > Speaking of which... I know the new branch is where Rich publishes his > current work. Does anyone (Rich included!) have any opinion on whether > it's reasonable to do 'mainstream' development against new (rather > than working against master and occasionally testing against new)? > > I currently work against master, but I keep my checkout up-to-date. I would not recommend doing large amounts of development against 'new'. Things change there in ways that break compatibility with earlier changes there (not usually with 'master' through), so if you start using features from 'new' and keep your checkout up-to-date, your code may break at any time without notice. For context: I don't think I've ever recommended against using master. I would however recommend playing around with 'new', trying out some of the new features on key parts of your code. Also, it may be very useful to try all your code on 'new' *without* taking advantage of the new features, and reporting back on any breakage. You won't have to wait too long though, I suspect. Once 1.1 is out the door I assume 'new' will be merged into 'master' fairly quickly. --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: how 'bout a debug-repl?
Yes, I just figured that out. Is there a way to use this with slime? -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: how 'bout a debug-repl?
are you using slime? Currently, you need to use a non-slime repl, (I think because of how slime handles io redirection) On Dec 10, 12:14 pm, kyle smith wrote: > I'm having some trouble with Alex's macro. I can type in the debug- > repl, but when I hit enter, it just hangs and nothing happens. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Idiomatic way to return the key of a map, which matches a vector containing a search value.
Oops! Slight mistake
(ffirst (filter (comp (partial some #{"rabble"}) val) players))
On Dec 10, 3:27 pm, Sean Devlin wrote:
> Try this...
>
> (second (first (filter (comp (partial some #{"rabble"}) val)
> players)))
>
> On Dec 10, 2:40 pm, mudphone wrote:
>
> > Hi Folks,
>
> > So, I have a search string, for example "rabble". And a map which
> > contains keyword keys, and vectors of strings as values:
>
> > (def players
> > {
> > :amit ["a" "b" "c"]
> > :roger ["rabble" "x" "y"]
>
> > })
>
> > Is there an idiomatic way to search for "rabble" in the vector values,
> > then return the keyword that matches it? In this example, "rabble"
> > would match :roger. "b" would match :amit.
>
> > Currently, I'm doing a "some" which has a predicate function which
> > contains another "some" seems awkward to me, but works:
>
> > Assuming the search-str has to be transformed in some way (that I'm
> > leaving out here), using:
> > (defn munge-str [search-str]
> > ... returns a string...)
>
> > (defn key-from-match [search-str]
> > (let [key-of-str? (fn [entry-pair]
> > (if (some #(= (munge-str search-str) %)
> > (val entry-pair))
> > (key entry-pair)))]
> > (some key-of-str? (players))
> > ))
>
> > Thanks for any suggestions.
>
> > Kyle
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: Idiomatic way to return the key of a map, which matches a vector containing a search value.
Try this...
(second (first (filter (comp (partial some #{"rabble"}) val)
players)))
On Dec 10, 2:40 pm, mudphone wrote:
> Hi Folks,
>
> So, I have a search string, for example "rabble". And a map which
> contains keyword keys, and vectors of strings as values:
>
> (def players
> {
> :amit ["a" "b" "c"]
> :roger ["rabble" "x" "y"]
>
> })
>
> Is there an idiomatic way to search for "rabble" in the vector values,
> then return the keyword that matches it? In this example, "rabble"
> would match :roger. "b" would match :amit.
>
> Currently, I'm doing a "some" which has a predicate function which
> contains another "some" seems awkward to me, but works:
>
> Assuming the search-str has to be transformed in some way (that I'm
> leaving out here), using:
> (defn munge-str [search-str]
> ... returns a string...)
>
> (defn key-from-match [search-str]
> (let [key-of-str? (fn [entry-pair]
> (if (some #(= (munge-str search-str) %)
> (val entry-pair))
> (key entry-pair)))]
> (some key-of-str? (players))
> ))
>
> Thanks for any suggestions.
>
> Kyle
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Idiomatic way to return the key of a map, which matches a vector containing a search value.
Hi Folks,
So, I have a search string, for example "rabble". And a map which
contains keyword keys, and vectors of strings as values:
(def players
{
:amit ["a" "b" "c"]
:roger ["rabble" "x" "y"]
})
Is there an idiomatic way to search for "rabble" in the vector values,
then return the keyword that matches it? In this example, "rabble"
would match :roger. "b" would match :amit.
Currently, I'm doing a "some" which has a predicate function which
contains another "some" seems awkward to me, but works:
Assuming the search-str has to be transformed in some way (that I'm
leaving out here), using:
(defn munge-str [search-str]
... returns a string...)
(defn key-from-match [search-str]
(let [key-of-str? (fn [entry-pair]
(if (some #(= (munge-str search-str) %)
(val entry-pair))
(key entry-pair)))]
(some key-of-str? (players))
))
Thanks for any suggestions.
Kyle
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: how 'bout a debug-repl?
I'm having some trouble with Alex's macro. I can type in the debug- repl, but when I hit enter, it just hangs and nothing happens. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Fine-grained locals clearing
> +1 As cool as the new branch is, this is the first compelling reason > I've seen to go to my boss and say we need to switch to it now. > > Thanks Rich! Speaking of which... I know the new branch is where Rich publishes his current work. Does anyone (Rich included!) have any opinion on whether it's reasonable to do 'mainstream' development against new (rather than working against master and occasionally testing against new)? I currently work against master, but I keep my checkout up-to-date. Imaginary counter-points would be "bugs that get fixed on master don't get merged into new", "it's really only for experimentation", "it's often broken for days at a time", "things behave differently to master", "functions keep changing their names", "building a jar doesn't work", etc. I ask because I maintain a bunch of libraries and do quite a lot of new development, and so I see a possible win/win: I get to enjoy new improvements, but I also act as a real-world-code tester for the community. That only applies, though, if new has a modicum of stability and reliability. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Code arrangement for understandability
> They're especially useful for inserting println calls for seeing the > value of something when I'm debugging; in fact, this is the primary > way I do debugging. (defn tee (x) (println "Debug: " (prn-str x)) x) (let [x (tee (foo 1))] ...) -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Code arrangement for understandability
> How to rearrange the Clojure code for understandability? One approach I've used in Common Lisp to avoid multiple lets is to do (let* ((x (let ((v 1)) (f v) ; for side-effects v)) (y (+ x 2))) (g y)) This calls to mind Clojure's doto, which instantiates a Java object, does some stuff to it, then returns the object. It would be easy to define a macro to describe this. Of course, if `f` *returns* the value you want to bind to `x`, you don't have this problem (you can just put (f x) directly in the let binding form). You also don't have this problem if you don't need to call `f` before binding `y`. (+ x 2) is side-effect free, and (f x) cannot mutate `x`, so your Clojure code can easily be written (let [x 1 y (+ x 2)] (f x) (g y)) -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Apply performance and logging JIT compilation
Doh... -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Image scaling libraries. Request for recommendations
On 10 dec, 09:25, Frédéric Morain-Nicolier wrote: > ImageJ is considered as an excellent lib for image processing > :http://rsbweb.nih.gov/ij/ > > It is a java lib so integration in clojure is direct. You can even > find a fork with clojure inside (Fiji) > :http://pacific.mpi-cbg.de/wiki/index.php/Clojure_Scripting As far as I can tell, ImageJ isn't really suited for "headless" tasks, which is what I want to do; I want to run some image processing in the backend of a web app. I guess I'm going to try JAI first. Thanks to you both, Joost. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: autocomplete
Hi, On Dec 10, 4:06 pm, Laurent PETIT wrote: > If you want to rewrite from scratch, it's not very difficult, given that you > have clojure.core/ns-* (e.g. ns-public ...) functions at your disposal "for > free". > > The code in VimClojure is particularly clear, stable and complete, I guess > (at least for the clojure part of the story, don't know about code > completion for java) : > > http://bitbucket.org/kotarak/vimclojure/src/tip/src/de/kotka/vimcloju... For Java, it doesn't do much at the moment besides classnames which are imported and their static methods. I'll probably add method completion for imported classes. It seems I have to catch up with swank on this one. ;P 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: Code arrangement for understandability
If it's for side-effects, then using _ is fine, in my opinion—they're nicely identifiable. They're especially useful for inserting println calls for seeing the value of something when I'm debugging; in fact, this is the primary way I do debugging. I would say, though, that usually if you're going to truly do side-effects, it's better to isolate them as much as possible, rather than interspersing them within essential logic. I've seen the (let [x ... x (... x ...) x (... x ...) x (... x ...)] x) notation before, and it is fine. For my tastes, however, I think that it repeats the symbol (in this case, 'x) too much. Sometimes it may be the best way, but usually I would instead use ->, ->>, and/or letfn. On Dec 10, 9:05 am, David Brown wrote: > On Thu, Dec 10, 2009 at 09:26:07AM -0500, Graham Fawcett wrote: > >(let [x 1 > > _ (f x) > > y (+ x 2) > > _ (g y)] > > ...) > > What do people in general think of this style? I remember using this > trick a lot with O'Caml, and I've certainly used it a few times in > Clojure, but something feels icky about it. > > Where it's most useful, though is with stuff like this: > > (let [x ... > y ... > _ (prn "y is" y) > ...] > ...) > > I have found I sometimes find something like: > > (let [x ... > x (... x ...) > x (... x ...) > x (... x ...)] > x) > > easier to write, even if it is just how I write it the first time, and > then later change it to something looking more like function > application. Sometimes, I've found the let-chain is easier to modify > in the future. > > I guess, realizing it's still not imperative (necessarily), it > shouldn't bother me as much. > > 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: Fine-grained locals clearing
+1 As cool as the new branch is, this is the first compelling reason I've seen to go to my boss and say we need to switch to it now. Thanks Rich! On Dec 10, 6:40 am, "Stephen C. Gilardi" wrote: > On Dec 10, 2009, at 9:10 AM, Rich Hickey wrote: > > What a great change! We ran into the problem this solves just this week: > running out of memory on long lazy seqs with large elements that we intended > to be processing one item at a time. > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Code arrangement for understandability
On Thu, Dec 10, 2009 at 09:26:07AM -0500, Graham Fawcett wrote: >(let [x 1 > _ (f x) > y (+ x 2) > _ (g y)] > ...) What do people in general think of this style? I remember using this trick a lot with O'Caml, and I've certainly used it a few times in Clojure, but something feels icky about it. Where it's most useful, though is with stuff like this: (let [x ... y ... _ (prn "y is" y) ...] ...) I have found I sometimes find something like: (let [x ... x (... x ...) x (... x ...) x (... x ...)] x) easier to write, even if it is just how I write it the first time, and then later change it to something looking more like function application. Sometimes, I've found the let-chain is easier to modify in the future. I guess, realizing it's still not imperative (necessarily), it shouldn't bother me as much. 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: Code arrangement for understandability
A few things might help: * Judging by you examples, I looks like you're still getting used to the lisp style of coding. Everything is a chained function call. Write your code to support with that in mind. * Practice using comp & partial. Write a few small apps where you NEVER use a let form. * Practice using ->. Try to write a few other other apps only using this. * Master the editor you're using. Emacs has great tab support, and will help you arrange your code accordingly. I'm sure Vim does something similar. Enclojure has a netbeansy "Format my code" option from the popup menu. Sean PS - Do you come from a Python background? On Dec 10, 9:15 am, ngocdaothanh wrote: > Hi, > > I want to ask about code arrangement and understandability > (readability). > > Consider this "normal" code: > x = 1 > ... > f(x) > ... > y = x + 2 > ... > g(y) > > x, f, y, g have the same "abstractness" level, so they are indented to > the same level. > > My Clojure code: > (let [x 1] > ... > (f x) > ... > (let [y (+ x 2)] > ... > (g y))) > > It is very difficult to capture the "algorithm" behind the Clojure > code because things of the same "abstractness" level do not have the > same indent level. > > How to rearrange the Clojure code for understandability? > > I have been studying Clojure for several months now but I could never > "get" it. But I couldn't explain why I couldn't get it, I just didn't > know why. But today I think I have found the reason: I think the > problem of Clojure (and Lisp) is not parenthesis, its problem is > indent. > > I think if I can "let over" this problem, I will be enlightened. Would > you please help me? > > Thank you, > Ngoc -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: update-in and get-in why no default?
Tim,
I like both of these ideas. I agree, get-in2 seems to make sense as a
drop in replacement.
With update-in2 I prefer a new name, because I do occasionally write
code that constructs lists of functions. I'd hate to get a weird bug
while doing this.
Sean
On Dec 10, 7:20 am, Timothy Pratley wrote:
> Hi,
>
> update-in is an especially useful function but I find the update
> function inevitably requires a check for nil. If I could supply a not-
> found value then my code would get better golf scores.
>
> When I reach for update-in, I usually want to pass it a numerical
> operator like inc or +, but these don't play nicely with nil. Another
> scenario is when I want to pass conj, which is fine if I want to
> create lists, except if I usually want the data structure to be
> something else. I've never come across a scenario where I didn't want
> to supply a not-found value, are there any common ones?
>
> If others have similar experience perhaps it is a candidate for
> change. Ideally I'd like to see a not-found parameter added to update-
> in and an extra arity overload for get-in as outlined below:
>
> (defn update-in2
> "'Updates' a value in a nested associative structure, where ks is a
> sequence of keys and f is a function that will take the old value
> and any supplied args and return the new value, and returns a new
> nested structure. If any levels do not exist, hash-maps will be
> created. If there is no value to update, default is supplied to f. "
> ([m [k & ks] not-found f & args]
> (if ks
> (assoc m k (apply update-in2 (get m k) ks f args))
> (assoc m k (apply f (get m k not-found) args)
>
> user=> (reduce #(update-in2 %1 [%2] 0 inc) {} ["fun" "counting"
> "words" "fun"])
> {"words" 1, "counting" 1, "fun" 2}
> user=> (reduce #(update-in2 %1 [(first %2)] [] conj (second %2)) {}
> [[:a 1] [:a 2] [:b 3]])
> {:b [3], :a [1 2]}
>
> (defn get-in2
> "returns the value in a nested associative structure, where ks is a
> sequence of keys"
> ([m ks]
> (reduce get m ks))
> ([m ks not-found]
> (if-let [v (reduce get m ks)]
> v
> not-found)))
>
> user=> (get-in2 {:a {:b 1}} [:a :b] 0)
> 1
> user=> (get-in2 {:a {:b 1}} [:a :b :c] 0)
> 0
>
> Changing update-in would be a breaking change unfortunately. To avoid
> this you could consider checking the argument type for f to be
> function or value (making an assumption here that you would rarely
> want a function as the not-found value which is not 100% watertight).
> Or you could have a similarly named update-in-or function (which is
> less aesthetically pleasing), or maybe there is another even better
> way?
>
> Thanks for your consideration.
>
> Regards,
> Tim.
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from 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: Code arrangement for understandability
On Thu, Dec 10, 2009 at 9:15 AM, ngocdaothanh wrote: > > My Clojure code: > (let [x 1] > ... > (f x) > ... > (let [y (+ x 2)] > ... > (g y))) > > It is very difficult to capture the "algorithm" behind the Clojure > code because things of the same "abstractness" level do not have the > same indent level. Note, however, that in this example only the value of (g y) will be returned. Granted, if the ... includes conditionals (with more levels of indenting that aren't shown) there may be other possible results. But with the structure given, (f x) for example must be producing side-effects or it wouldn't be there at all. That pushes this code over into the "less than perfectly idiomatic" category and gets us a little off the topic of why idiomatic Clojure is written in one particular way or another. So let's imagine a more complex example, with multiple 'if's and therefore multiple tail positions, each computing the return value a different way: (let [x 1] (if ... (let [y (+ x 1)] (if ... y (f x))) (let [y (+ x 2)] (if ... (if ... x y) (g y) Let's set aside for the moment questions about weather all this really belongs in a single function or if y should be defined in multiple places. If we're trying to understand this code we're going to be repeatedly confronted with the question "where is the value of foo computed" where foo is x or y. In almost all languages our eyes would wander up the screen looking for hints. In imperative code, we would have to be alert for any variable assignments like "x = y + 1", regardless of where they show up -- being in some unrelated "then" clause is no guarantee you can ignore it if there's any chance it might have executed before reaching the code in question. We'd also need to be alert to any procedure calls that might name x as a parameter if there's any chance the procedure might modify x. In Clojure we still need to look farther up the screen, but only to find out-dented 'let's. When x is a local holding an immutable value like an Integer, there is simply no way any code can muck with it except a 'let' that is directly in the parentage of the code in question. This does mean you need to look as different levels of indentation to find the definition, but it is a good deal less code and fewer kinds of code than in an imperative language. --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: autocomplete
If you want to rewrite from scratch, it's not very difficult, given that you have clojure.core/ns-* (e.g. ns-public ...) functions at your disposal "for free". The code in VimClojure is particularly clear, stable and complete, I guess (at least for the clojure part of the story, don't know about code completion for java) : http://bitbucket.org/kotarak/vimclojure/src/tip/src/de/kotka/vimclojure/backend.clj Regards, -- Laurent 2009/12/10 Mike > In my earlier posts this week I was talking about integrating a repl > into our application; thanks to your help I was able to get this to > work. I appreciate it! > > So we actually have a number of "scripting" languages we have done > this with, such as Jython and SISC Scheme. We have a primitive > autocomplete function, where given the line of input so far we can > suggest ways to complete the current term (end of the input line, or > the last cursor position). For instance, if the line was: > > (def foobar (cons > > and the user pressed "Tab" for autocomplete, I need to return [ 'cons > 'constantly 'construct-proxy ] (from clojure core, etc.). It would be > nice to return normal bound symbols as well as special forms (macro > names) too. (And not just functions either, as maps and keywords can > be "functions", etc.). > > I tried to find how this works for the slime integration, but I'm > either not sure what to look for or just brain dead looking through > elisp code. > > Could anyone point me in the right direction? I'm hoping that there's > some part of the Clojure runtime that knows how to look through the > current environment and does most of the work of the > autocomplete...that way I can just tap into it directly. If most is > written in elisp, then maybe I need to rethink how I do this. > > Thanks a whole bunch in advance, > Mike > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from 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: Where is the Clojure 1.0 API documentation?
Tom, I like the idea of an "added in version", javadocs do it too. Perhaps it could go in the metadata? There is an issue to figure out, though. In the upgrade to 1.1, slurp got a new arity. In JavaLand this would be a non issue, because the new arity would have its own docs. However, in Clojure the docs & meta are shared. I don't see an obvious way of documention this distinction. Any ideas on how to solve this issue? Am I making something out of nothing? Sean On Dec 9, 10:10 am, Tom Faulhaber wrote: > Enhancing the doc tool so that we have versions for the multiple > branches (1.0, 1.1, master, new) is on my agenda. > > Maybe there's a way that Rich could add a link to the old 1.0 doc in > the meantime. > > I think that the "added in version" metadata tag is a good idea, at > least for clojure itself. Python does this and I've always liked it. > > Tom > > On Dec 9, 5:43 am, Mark Tomko wrote: > > > I second this - since many of the IDE plugins bundle the clojure-1.0 > > jar, new users trying out Clojure (and IDEs) can't use all the > > features listed in the docs, and it's hard to tell which is which. > > Maybe we could at least add a 'added in version' to the new method > > metadata? > > > On Dec 9, 4:48 am, Jarkko Oranen wrote: > > > > I just noticed that the API link on the clojure web site brings up > > > documentation for the master branch of Clojure instead of 1.0.0. I > > > can't find the 1.0.0 docs anywhere either. > > > > This is obviously a problem for 1.0.0 users, since the docs refer to > > > features that don't exist. > > > > I think it would be good to have the API page contain links to 1.0.0 > > > docs as well as master and perhaps other branches as well. Also, a > > > clear indication (preferably in a bold font or something) of which > > > revision the doc was generated for would be useful. > > > > -- > > > Jarkko -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Code arrangement for understandability
I'm not sure either what you mean by "abstraction level", but I would say that I tend more to think about abstraction level to be at function definition level. 2009/12/10 ngocdaothanh > Hi, > > I want to ask about code arrangement and understandability > (readability). > > Consider this "normal" code: > x = 1 > ... > f(x) > ... > y = x + 2 > ... > g(y) > > x, f, y, g have the same "abstractness" level, so they are indented to > the same level. > > My Clojure code: > (let [x 1] > ... > (f x) > ... > (let [y (+ x 2)] >... >(g y))) > > It is very difficult to capture the "algorithm" behind the Clojure > code because things of the same "abstractness" level do not have the > same indent level. > > How to rearrange the Clojure code for understandability? > > I have been studying Clojure for several months now but I could never > "get" it. But I couldn't explain why I couldn't get it, I just didn't > know why. But today I think I have found the reason: I think the > problem of Clojure (and Lisp) is not parenthesis, its problem is > indent. > > I think if I can "let over" this problem, I will be enlightened. Would > you please help me? > > Thank you, > Ngoc > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from 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: Fine-grained locals clearing
On Dec 10, 2009, at 9:10 AM, Rich Hickey wrote: > I'm happy to announce I have implemented this fine-grained locals > clearing in the compiler, in the 'new' branch. It should automatically > cover all cases in which the code doesn't explicitly reuse the head - > including non-tail usage, destructuring etc. What a great change! We ran into the problem this solves just this week: running out of memory on long lazy seqs with large elements that we intended to be processing one item at a time. > In short, such cases should 'just work' from now on. ... adding yet another entry on the long list of Clojure facilities that adhere to the principle of least surprise. Nicely done! --Steve smime.p7s Description: S/MIME cryptographic signature
Re: Code arrangement for understandability
On Thu, Dec 10, 2009 at 9:15 AM, ngocdaothanh wrote: > Hi, > > I want to ask about code arrangement and understandability > (readability). > > Consider this "normal" code: > x = 1 > ... > f(x) > ... > y = x + 2 > ... > g(y) > > x, f, y, g have the same "abstractness" level, so they are indented to > the same level. In what sense do they have the 'same abstractness level'? What do you mean by abstractness? g(y) depends upon y; y depends upon x; nothing depends upon f(x), so presumably it is being called for side effects. I don't see anything similar about them. You could also write (let [x 1 _ (f x) y (+ x 2) _ (g y)] ...) which puts them all at the same nesting level. Best, Graham > > My Clojure code: > (let [x 1] > ... > (f x) > ... > (let [y (+ x 2)] > ... > (g y))) > > It is very difficult to capture the "algorithm" behind the Clojure > code because things of the same "abstractness" level do not have the > same indent level. > > How to rearrange the Clojure code for understandability? > > I have been studying Clojure for several months now but I could never > "get" it. But I couldn't explain why I couldn't get it, I just didn't > know why. But today I think I have found the reason: I think the > problem of Clojure (and Lisp) is not parenthesis, its problem is > indent. > > I think if I can "let over" this problem, I will be enlightened. Would > you please help me? > > Thank you, > Ngoc > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from 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: Fine-grained locals clearing
Rockin'. On Thu, Dec 10, 2009 at 9:10 AM, Rich Hickey wrote: > One of the objectives of Clojure is to reduce incidental complexity. > And one of the biggest sources of incidental complexity in Clojure was > the retention of the head of a lazy sequence due to its being > referenced by some local (argument or local (let) binding). One might > expect that, if no subsequent code in the body of a function uses that > arg/local, it would be subject to GC. Unfortunately, on the JVM, that > is, in many cases, not true - the local is considered a live reference > and is thus not GCed. This yields the infamous 'holding onto the head' > problem, and subsequent Out Of Memory errors on large data sets. > > I had put in place a workaround, which was the 'clearing/nulling-out' > of locals on the tail call of the function. This helps in many, but > not all, cases. Not all logic flows are amenable to rearrangement to > leverage this cleanup. And there are many cases where the local is not > visible - e.g. when destructuring. > > The full solution is to track, during compilation, the lifetime of all > locals on all branches of the execution path and to emit code that > clears them at the point of last use in any particular branch. > > I'm happy to announce I have implemented this fine-grained locals > clearing in the compiler, in the 'new' branch. It should automatically > cover all cases in which the code doesn't explicitly reuse the head - > including non-tail usage, destructuring etc. In short, such cases > should 'just work' from now on. > > N.B. that this is strictly a lifetime management issue and does not > change the nature of lazy sequences - they are real, linked data > structures, the tail of which might not yet have been created. They > are most emphatically *not* ephemeral streams of values. However, with > fine-grained locals clearing, they are subject to GC 'as you go', > delivering the benefits of both. > > If you've got a pet case of incidental head-retention, please try out > the 'new' branch and let me know how it goes. > > Thanks, > > 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 > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Code arrangement for understandability
Hi, I want to ask about code arrangement and understandability (readability). Consider this "normal" code: x = 1 ... f(x) ... y = x + 2 ... g(y) x, f, y, g have the same "abstractness" level, so they are indented to the same level. My Clojure code: (let [x 1] ... (f x) ... (let [y (+ x 2)] ... (g y))) It is very difficult to capture the "algorithm" behind the Clojure code because things of the same "abstractness" level do not have the same indent level. How to rearrange the Clojure code for understandability? I have been studying Clojure for several months now but I could never "get" it. But I couldn't explain why I couldn't get it, I just didn't know why. But today I think I have found the reason: I think the problem of Clojure (and Lisp) is not parenthesis, its problem is indent. I think if I can "let over" this problem, I will be enlightened. Would you please help me? Thank you, Ngoc -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Fine-grained locals clearing
One of the objectives of Clojure is to reduce incidental complexity. And one of the biggest sources of incidental complexity in Clojure was the retention of the head of a lazy sequence due to its being referenced by some local (argument or local (let) binding). One might expect that, if no subsequent code in the body of a function uses that arg/local, it would be subject to GC. Unfortunately, on the JVM, that is, in many cases, not true - the local is considered a live reference and is thus not GCed. This yields the infamous 'holding onto the head' problem, and subsequent Out Of Memory errors on large data sets. I had put in place a workaround, which was the 'clearing/nulling-out' of locals on the tail call of the function. This helps in many, but not all, cases. Not all logic flows are amenable to rearrangement to leverage this cleanup. And there are many cases where the local is not visible - e.g. when destructuring. The full solution is to track, during compilation, the lifetime of all locals on all branches of the execution path and to emit code that clears them at the point of last use in any particular branch. I'm happy to announce I have implemented this fine-grained locals clearing in the compiler, in the 'new' branch. It should automatically cover all cases in which the code doesn't explicitly reuse the head - including non-tail usage, destructuring etc. In short, such cases should 'just work' from now on. N.B. that this is strictly a lifetime management issue and does not change the nature of lazy sequences - they are real, linked data structures, the tail of which might not yet have been created. They are most emphatically *not* ephemeral streams of values. However, with fine-grained locals clearing, they are subject to GC 'as you go', delivering the benefits of both. If you've got a pet case of incidental head-retention, please try out the 'new' branch and let me know how it goes. Thanks, 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: simple journal-based persistenсe for Clojure
Yes, it uses agents for writing operations. So on the account of disk failure it's possible that in-memory state will be a few transactions ahead of what is actually persisted. Thus it's not a strict transactional solution. I consider it as a good fit for project prototyping and may be production systems where this non strict behavior is acceptable. (considering people test it enough first) The in-crash behavior can be slightly improved by adding additional agent which will persist transactions by sending them to a remote computer, but of course it's not a fully reliable solution either. On Thu, Dec 10, 2009 at 11:30 AM, Laurent PETIT wrote: > Hello, > > without going too deep in the detail of your implementation, I just can't > keep thinking that, as far as I know, it's currently impossible with clojure > to extend the scope of the transaction outside the STM, without changes in > the STM itself (STM being aware of TransactionManagers being certainly the > way to go, I guess). > > At least, making it 100% reliable and race conditions-free. > All of this due to the fact that you can't do side effets from within the > transaction, and you have to use an agent to do so. And when the agent will > do the real persistence call, if this call fails for some reason (wire > disconnected, etc.), it's too late to fail the STM transaction, it's already > finished and commited to the ref world. > > Did I miss something ? > > 2009/12/2 Sergey Didenko > >> Hi, >> >> I have implemented the simple journal-based persistence library for >> Clojure programs and now making it public. >> >> It follows "Prevalent system" design pattern. >> >> I consider it a good fit for the prototyping stage of a project >> development. When you don't want to pay the price of impedance mismatch >> between the language data structures and your database because your database >> schema is not stable yet. >> >> However this pattern is used in production by some teams, see Prevayler >> mail list for details. Of course this implementation can contain bugs and >> must be tested well before doing that. Though it is very simple and I made >> some tests. >> >> The disadvantage of the pattern is that your data structures must fit in >> memory (unless you implement ad-hoc paging solution). However the journaling >> nature lets you easily switch to other databases. For that you just >> re-implement your transaction functions (subjects of apply-transaction* ) to >> write/read from another DB and replay transactions one time (init-db). >> >> Snapshotting is not yet implemented. It can solve another pattern problem >> - growing startup time. >> >> Usage examples: >> >> 1. first run >> >> (use 'persister) >> >> (def refx (ref 0)) >> (def refy (ref 0)) >> >> (defn tr-fn [x y] >>(do >>(alter refx + x) >>(alter refy + y) )) >> >> (defn tr-fn-swap [] >>(let [tmp @refx] >>(ref-set refx @refy) >>(ref-set refy tmp))) >> >> (defn tr-inc [] >>(ref-set refx (inc @refx)) >>(ref-set refy (inc @refy)) ) >> >> (init-db) >> (apply-transaction tr-fn 1 2) >> (apply-transaction tr-fn 10 20) >> (apply-transaction tr-fn-swap) >> (apply-transaction tr-inc) >> [refx refy] >> >> [# #] >> >> 2. the second run >> >> (use 'persister) >> >> (def refx (ref 0)) >> (def refy (ref 0)) >> >> (defn tr-fn [x y] >>(do >>(alter refx + x) >>(alter refy + y) )) >> >> (defn tr-fn-swap [] >>(let [tmp @refx] >>(ref-set refx @refy) >>(ref-set refy tmp))) >> >> (defn tr-inc [] >>(ref-set refx (inc @refx)) >>(ref-set refy (inc @refy)) ) >> >> (init-db) >> [refx refy] >> >> [# #] >> >> >> Note that journaled functions must be accessible in the current namespace >> when you replay transactions. >> >> See inline doc for details. >> >> Looking for your feedback! >> >> Regards, Sergey. >> >> -- >> You received this message because you are subscribed to the Google >> Groups "Clojure" group. >> To post to this group, send email to clojure@googlegroups.com >> Note that posts from new members are moderated - please be patient with >> your first post. >> To unsubscribe from 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 unsubscrib
autocomplete
In my earlier posts this week I was talking about integrating a repl into our application; thanks to your help I was able to get this to work. I appreciate it! So we actually have a number of "scripting" languages we have done this with, such as Jython and SISC Scheme. We have a primitive autocomplete function, where given the line of input so far we can suggest ways to complete the current term (end of the input line, or the last cursor position). For instance, if the line was: (def foobar (cons and the user pressed "Tab" for autocomplete, I need to return [ 'cons 'constantly 'construct-proxy ] (from clojure core, etc.). It would be nice to return normal bound symbols as well as special forms (macro names) too. (And not just functions either, as maps and keywords can be "functions", etc.). I tried to find how this works for the slime integration, but I'm either not sure what to look for or just brain dead looking through elisp code. Could anyone point me in the right direction? I'm hoping that there's some part of the Clojure runtime that knows how to look through the current environment and does most of the work of the autocomplete...that way I can just tap into it directly. If most is written in elisp, then maybe I need to rethink how I do this. Thanks a whole bunch in advance, Mike -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Apply performance and logging JIT compilation
On Tue, Dec 8, 2009 at 3:51 PM, Krukow wrote: > I am writing a function that has to wrap other code. One simple > approach is to do > > user> (defn wrap-fun [f] > (fn [& args] > (println "pre-processing") > (let [res (apply f args)] > (println "post-processing") > res))) > #'user/wrap-fun > user> (def w (wrap-fun (fn [x y] (println "calling") (+ x y > #'user/w > user> (w 2 2) > pre-processing > calling > post-processing > 4 > user> > > I was wondering what is the cost of using apply vs calling the wrapped > function directly. So my first question is: what is the performance > cost of using apply vs calling a function ;-) Can the compiler inline > a call to apply so there is no difference, or is there a real cost? > > An alternative is to use a macro to inline an expression corresponding > to the function f in wrap-fun above, e.g., > > user> (defmacro wrap-fn [params exp] > `(fn ~params > (println "pre-processing") > (let [res# ~exp] > (println "post-processing") > res#))) > #'user/wrap-fn > user> (def w (wrap-fn [x y] (do (println "calling") (+ x y > #'user/w > user> (w 2 2) > pre-processing > calling > post-processing > 4 > user> > > This avoid calling apply. To answer my own question, I wanted to test > the performance difference between the inlined and the apply-based > approach. But given that micro-performance test are known to be hard^1 > I wanted to make sure I was running the -server VM and that the code > was getting JIT'ed. > > I tried starting a clojure REPL with the option -XX:- > PrintCompilation, but I never see any prints. > > java -server -XX:-PrintCompilation -cp $CLOJURE_JRE_LIBS: > $USER_CLASSPATH clojure.main > > I've done a dotimes where I call a wrapped function many times. > > Now my question, is the code not JIT'ing or am I providing the wrong > JVM options? > > /Karl > I think you want: -XX:+PrintCompilation 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
update-in and get-in why no default?
Hi,
update-in is an especially useful function but I find the update
function inevitably requires a check for nil. If I could supply a not-
found value then my code would get better golf scores.
When I reach for update-in, I usually want to pass it a numerical
operator like inc or +, but these don't play nicely with nil. Another
scenario is when I want to pass conj, which is fine if I want to
create lists, except if I usually want the data structure to be
something else. I've never come across a scenario where I didn't want
to supply a not-found value, are there any common ones?
If others have similar experience perhaps it is a candidate for
change. Ideally I'd like to see a not-found parameter added to update-
in and an extra arity overload for get-in as outlined below:
(defn update-in2
"'Updates' a value in a nested associative structure, where ks is a
sequence of keys and f is a function that will take the old value
and any supplied args and return the new value, and returns a new
nested structure. If any levels do not exist, hash-maps will be
created. If there is no value to update, default is supplied to f. "
([m [k & ks] not-found f & args]
(if ks
(assoc m k (apply update-in2 (get m k) ks f args))
(assoc m k (apply f (get m k not-found) args)
user=> (reduce #(update-in2 %1 [%2] 0 inc) {} ["fun" "counting"
"words" "fun"])
{"words" 1, "counting" 1, "fun" 2}
user=> (reduce #(update-in2 %1 [(first %2)] [] conj (second %2)) {}
[[:a 1] [:a 2] [:b 3]])
{:b [3], :a [1 2]}
(defn get-in2
"returns the value in a nested associative structure, where ks is a
sequence of keys"
([m ks]
(reduce get m ks))
([m ks not-found]
(if-let [v (reduce get m ks)]
v
not-found)))
user=> (get-in2 {:a {:b 1}} [:a :b] 0)
1
user=> (get-in2 {:a {:b 1}} [:a :b :c] 0)
0
Changing update-in would be a breaking change unfortunately. To avoid
this you could consider checking the argument type for f to be
function or value (making an assumption here that you would rarely
want a function as the not-found value which is not 100% watertight).
Or you could have a similarly named update-in-or function (which is
less aesthetically pleasing), or maybe there is another even better
way?
Thanks for your consideration.
Regards,
Tim.
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
1.0 Compatible Terracotta Integration Module
Hey everyone,
I haven't been in #clojure that often lately, but when I have been
there were people asking about Terracotta integration on two separate
occasions. What are the chances of that?! :)
There is a new repo at http://github.com/pjstadig/tim-clojure-1.0.0/
that has a 1.0 compatible version of the TIM. It should be simpler to
setup and test (though it still depends on Maven...sorry). This time
around I also tested it on Windows, because I know a couple people
have asked about that.
Not everything in Clojure is functional, so there is a loss of
functionality from my last experiment, but this release also changes
the way that the sharing occurs. Vars are shared in Terracotta based
on metadata. So, for example, if you wanted to define a new shared
Var, then you would do it like so:
(defn #^{:tcshared true} foo [] 42)
To remove an object from Terracotta you would alter is metadata like
so:
(alter-meta! #'foo assoc :tcshared false)
By default everything that can be shared from clojure.core and
clojure.main are shared (obviously I'll need to share the other
clojure.* namespaces). This is still early, so some things will
change, but I wanted to get it out there as early as possible, while
still being functional. You can track the progress by watching either
the Git repo, or my blog http://paul.stadig.name/, and I would
certainly welcome any feedback or contributions.
Paul
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from 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: How to internally refer to other keys in a hashmap?
Hi, On Dec 9, 10:16 pm, Richard Newman wrote: > > However, if you would want to do something like an evolvable trade-off > > between epitopes and mutations in viruses, you would like to be able > > to store the functions inside each virus. > > And you can do that if you change how you retrieve values. This could be combined with c.c.fnmap[1] to make this completely transparent. Sincerely Meikel [1]: http://richhickey.github.com/clojure-contrib/fnmap-api.html -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: simple journal-based persistenсe for Clojure
Hello, without going too deep in the detail of your implementation, I just can't keep thinking that, as far as I know, it's currently impossible with clojure to extend the scope of the transaction outside the STM, without changes in the STM itself (STM being aware of TransactionManagers being certainly the way to go, I guess). At least, making it 100% reliable and race conditions-free. All of this due to the fact that you can't do side effets from within the transaction, and you have to use an agent to do so. And when the agent will do the real persistence call, if this call fails for some reason (wire disconnected, etc.), it's too late to fail the STM transaction, it's already finished and commited to the ref world. Did I miss something ? 2009/12/2 Sergey Didenko > Hi, > > I have implemented the simple journal-based persistence library for Clojure > programs and now making it public. > > It follows "Prevalent system" design pattern. > > I consider it a good fit for the prototyping stage of a project > development. When you don't want to pay the price of impedance mismatch > between the language data structures and your database because your database > schema is not stable yet. > > However this pattern is used in production by some teams, see Prevayler > mail list for details. Of course this implementation can contain bugs and > must be tested well before doing that. Though it is very simple and I made > some tests. > > The disadvantage of the pattern is that your data structures must fit in > memory (unless you implement ad-hoc paging solution). However the journaling > nature lets you easily switch to other databases. For that you just > re-implement your transaction functions (subjects of apply-transaction* ) to > write/read from another DB and replay transactions one time (init-db). > > Snapshotting is not yet implemented. It can solve another pattern problem - > growing startup time. > > Usage examples: > > 1. first run > > (use 'persister) > > (def refx (ref 0)) > (def refy (ref 0)) > > (defn tr-fn [x y] >(do >(alter refx + x) >(alter refy + y) )) > > (defn tr-fn-swap [] >(let [tmp @refx] >(ref-set refx @refy) >(ref-set refy tmp))) > > (defn tr-inc [] >(ref-set refx (inc @refx)) >(ref-set refy (inc @refy)) ) > > (init-db) > (apply-transaction tr-fn 1 2) > (apply-transaction tr-fn 10 20) > (apply-transaction tr-fn-swap) > (apply-transaction tr-inc) > [refx refy] > > [# #] > > 2. the second run > > (use 'persister) > > (def refx (ref 0)) > (def refy (ref 0)) > > (defn tr-fn [x y] >(do >(alter refx + x) >(alter refy + y) )) > > (defn tr-fn-swap [] >(let [tmp @refx] >(ref-set refx @refy) >(ref-set refy tmp))) > > (defn tr-inc [] >(ref-set refx (inc @refx)) >(ref-set refy (inc @refy)) ) > > (init-db) > [refx refy] > > [# #] > > > Note that journaled functions must be accessible in the current namespace > when you replay transactions. > > See inline doc for details. > > Looking for your feedback! > > Regards, Sergey. > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from 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: Image scaling libraries. Request for recommendations
ImageJ is considered as an excellent lib for image processing : http://rsbweb.nih.gov/ij/ It is a java lib so integration in clojure is direct. You can even find a fork with clojure inside (Fiji) : http://pacific.mpi-cbg.de/wiki/index.php/Clojure_Scripting -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
