Re: lein-daemon 0.3

[Alfredo]

Good job :)
Can I use this in order to run, for examples, a lein ring session as a
deamon? :)
Bye,
Alfredo

On May 12, 6:18 am, Allen Rohner  wrote:
> I've released a new version of lein-daemon. daemon is like 'lein run',
> only it runs the process in the background rather than blocking.
>
> 0.3 and up is a complete re-write, that no longer depends on apache
> commons daemon. The new version has no dependencies on any external
> programs.
>
> For more, seehttps://github.com/arohner/lein-daemon

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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: Type hinting inconsistencies in 1.3.0

[Chas Emerick]

On May 12, 2011, at 2:09 AM, Ken Wesson wrote:

 The real problem is that first case was never actually specifying a
 return
 type - it is a type hint on the var that happened to store an fn. The fn
 itself can only return Object (<=1.2.0).
>>> 
>>> ??
>>> 
>>> Using 1.2:
>>> 
>>> sandbox=> (defn bar [] "foo")
>>> #'sandbox/bar
>>> sandbox=> (defn foo [] (.length (bar)))
>>> #'sandbox/foo
>>> Reflection warning, NO_SOURCE_PATH:1 - reference to field length can't
>>> be resolved.
>>> sandbox=> (defn ^String baz [] "foo")
>>> #'sandbox/baz
>>> sandbox=> (defn foo [] (.length (baz)))
>>> #'sandbox/foo
>>> 
>>> Looks like it recognizes it as hinting the return type to me.
>> 
>> https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/Compiler.java#L3236
> 
> What? Please actually respond in English, rather than by pointing
> mutely at something whose salience is not even apparent.

What David is getting at is that Object-based hints (as we've had all along) 
don't impact the signature of the generated function's invoke method -- their 
return types are always Object, and the hint is "just" used to determine which 
cast to use when the function's return is used in an interop context (and only 
in interop contexts, since "regular" Clojure functions never have 
statically-typed arguments).  In contrast, primitive type hints _do_ change the 
signature of the corresponding function's invoke* method via the selection of 
the appropriate IFn$N interface that has statically-typed arguments and 
return types.

What started this is I don't happen to think that's relevant re: syntax and the 
placement of the type hint — or, more to the point, that essentially no one 
does/will/should understand the difference in the implementation details and 
choices that are represented in the differentiated placement of the hint in:

(defn ^String foo [])
vs.
(defn foo ^long [])

- 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: Type hinting inconsistencies in 1.3.0

[Ken Wesson]

On Thu, May 12, 2011 at 6:01 AM, Chas Emerick  wrote:
> What David is getting at is that Object-based hints (as we've had all along) 
> don't impact the signature of the generated function's invoke method -- their 
> return types are always Object, and the hint is "just" used to determine 
> which cast to use when the function's return is used in an interop context 
> (and only in interop contexts, since "regular" Clojure functions never have 
> statically-typed arguments).

That's* different from his original claim that you "can't hint return
types", or words to that effect**; you can't enforce return types (as
in, returning the wrong type invariably throws CCE, or else it won't
compile), but you can hint them (and then wrong type used in interop
expression may cause CCE).

With 1.3, it looks like maybe you can enforce primitive return types
in some cases.

* If it even IS what he was getting at. All he posted was a URL, and I
don't think it's at all clear that that was what he meant by doing so.
And yes, that's after clicking through it and having a cursory look
around near the landing site in the code.

** To be exact, he said you can't "specify" return types, "it is a
type hint on the var that happened to store an fn". This reads to me
as implying that hinting (defn ^String foo [] ...) is hinting that foo
references a String rather than an IFn that returns a String, but the
compiler sure seems to interpret foo as referencing an IFn that
returns a String. :)

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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: Type hinting inconsistencies in 1.3.0

[Juha Arpiainen]

On May 12, 1:18 pm, Ken Wesson  wrote:
> This reads to me
> as implying that hinting (defn ^String foo [] ...) is hinting that foo
> references a String rather than an IFn that returns a String

It is if you use 'foo in argument position. That is, if Foo/bar is
overloaded for String and IFn, then (Foo/bar foo) resolves to the
wrong version.

--
Juha Arpiainen

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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: sessions in Ring, Sandbar, Compojure, etc...

[James Reeves]

On 12 May 2011 04:49, Shree Mulay  wrote:
> But for WHATEVER reason, the sessions are NOT getting stored?

Have you added the session middleware? e.g.

(def app
  (-> main-routes
  wrap-params
  wrap-session))

Or more succinctly:

(def app
  (handler/site main-routes))

- James

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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: Learning Idiomatic Clojure

[Mike Meyer]

On Wed, 11 May 2011 19:10:13 -0700 (PDT)
"J.R. Garcia"  wrote:

> I'm wondering what resources would be best to learn how Clojurians
> write their code.
> 
> I've been developing for about 4 years in several object-oriented
> languages (mostly C# and Ruby). I understand Clojure's syntax well and
> I'm familiar with a lot of the features of Clojure (although I'm sure
> several of you would prove me wrong). One problem I keep running into
> is how to attack a problem "the Clojure way". I often find myself
> writing Clojure like I would write C# code with LINQ, only in
> Clojure's syntax.

As others have said, this sounds like you need a book on
functional/LISP programming. There are some excellent books for other
LISP dialects. "Structure and Interpretation of Computer Programs"
(aka SICP) would be my recommendations, but "Practical Common Lisp"
and "On LISP" are both excellent. I don't know of a book at that
quality level using Clojure. There is an effort underway to translate
SICP to clojure at http://sicpinclojure.com/.

> I'm not interested in Java interop or Clojure on the web or Clojure's
> syntax. I've had no problem finding answers for those things on the
> Internet. I'm really more interested in stuff like
> http://www.bestinclass.dk/index.clj/2010/10/taking-uncle-bob-to-school.html,
> but covering a wider range of things rather than a small example. I'm
> interested in any resource whether it's a book, a video, a blog, a
> person, etc.

This, no the other hands, is a little bit contradictory. The example
about syntax and white space than writing code "the Clojure way",
though you explicitly say that's not what you're interested in. Seems
like you're asking for a community style guide. Again, I don't know
that such exists. If it does, Google didn't find it, thought it sounds
like a good idea if someone wanted to write one - maybe starting with
a LISP or Scheme style guide (there are lots of those to choose
from).

  http://www.mired.org/
Independent Software developer/SCM consultant, email for more information.

O< ascii ribbon campaign - stop html mail - www.asciiribbon.org

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Learning Idiomatic Clojure

[Stuart Halloway]

> This, no the other hands, is a little bit contradictory. The example
> about syntax and white space than writing code "the Clojure way",
> though you explicitly say that's not what you're interested in. Seems
> like you're asking for a community style guide. Again, I don't know
> that such exists. If it does, Google didn't find it, thought it sounds
> like a good idea if someone wanted to write one - maybe starting with
> a LISP or Scheme style guide (there are lots of those to choose
> from).

There is a (incomplete!) style guide that we (sometimes) follow for library 
work.

http://dev.clojure.org/display/design/Library+Coding+Standards

Contrib authors should feel free to enhance this document, after discussing 
their ideas on the dev list.

Stu



-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Speakers for NYC Clojure Users Group needed!

[Eric Thorsen]

We had a really interesting and thought provoking presentation on
Logic Programming in Clojure, predicate dispatch and some other topics
given by David Nolan last month who stepped up at the last minute
(thanks Dave!).  His project is now part of clojure contrib:

https://github.com/clojure/core.logic

Hopefully he can come back in the future and update us on his work there.

We do need a speaker for this month and if you would like to do a
presentation/tutorial on anything Clojure now or in a future meetup
please email me @

ericthor...@mac.com

Looking forward to seeing everyone next week!

Thanks,

Eric

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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: Learning Idiomatic Clojure

[Islon Scherer]

Read the joy of clojure, it's an amazing book that will teach you the
way of clojure.

Islon

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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: Learning Idiomatic Clojure

[Adam Burry]

On May 12, 11:54 am, Mike Meyer  wrote:
> As others have said, this sounds like you need a book on
> functional/LISP programming. There are some excellent books for other
> LISP dialects. "Structure and Interpretation of Computer Programs"
> (aka SICP) would be my recommendations, but "Practical Common Lisp"
> and "On LISP" are both excellent. I don't know of a book at that
> quality level using Clojure. There is an effort underway to translate
> SICP to clojure athttp://sicpinclojure.com/.

Obviously, these are excellent texts, but I wonder if a Haskel book
might be better place to look. The problem is I have not looked at any
Haskel books, but I expect it would be a better place to read about
the joys of laziness.

Adam

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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: Learning Idiomatic Clojure

[Sam Ritchie]

Here's a style guide for Scheme, another dialect of Lisp:

http://mumble.net/~campbell/scheme/style.txt

It's a fun read, and mostly applicable to Clojure.

On Thu, May 12, 2011 at 6:54 AM, Mike Meyer  wrote:

> On Wed, 11 May 2011 19:10:13 -0700 (PDT)
> "J.R. Garcia"  wrote:
>
> > I'm wondering what resources would be best to learn how Clojurians
> > write their code.
> >
> > I've been developing for about 4 years in several object-oriented
> > languages (mostly C# and Ruby). I understand Clojure's syntax well and
> > I'm familiar with a lot of the features of Clojure (although I'm sure
> > several of you would prove me wrong). One problem I keep running into
> > is how to attack a problem "the Clojure way". I often find myself
> > writing Clojure like I would write C# code with LINQ, only in
> > Clojure's syntax.
>
> As others have said, this sounds like you need a book on
> functional/LISP programming. There are some excellent books for other
> LISP dialects. "Structure and Interpretation of Computer Programs"
> (aka SICP) would be my recommendations, but "Practical Common Lisp"
> and "On LISP" are both excellent. I don't know of a book at that
> quality level using Clojure. There is an effort underway to translate
> SICP to clojure at http://sicpinclojure.com/.
>
> > I'm not interested in Java interop or Clojure on the web or Clojure's
> > syntax. I've had no problem finding answers for those things on the
> > Internet. I'm really more interested in stuff like
> >
> http://www.bestinclass.dk/index.clj/2010/10/taking-uncle-bob-to-school.html
> ,
> > but covering a wider range of things rather than a small example. I'm
> > interested in any resource whether it's a book, a video, a blog, a
> > person, etc.
>
> This, no the other hands, is a little bit contradictory. The example
> about syntax and white space than writing code "the Clojure way",
> though you explicitly say that's not what you're interested in. Seems
> like you're asking for a community style guide. Again, I don't know
> that such exists. If it does, Google didn't find it, thought it sounds
> like a good idea if someone wanted to write one - maybe starting with
> a LISP or Scheme style guide (there are lots of those to choose
> from).
>
>  --
> Mike Meyer   http://www.mired.org/
> Independent Software developer/SCM consultant, email for more information.
>
> O< ascii ribbon campaign - stop html mail - www.asciiribbon.org
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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: Small issue with swank-cdt on Windows

[George Jahad]

On May 11, 8:12 am, Aravindh Johendran  wrote:

> Can we just use the forward slashes in the method source-location-for-
> frame?

Seems reasonable.  Thanks for pointing it out.  I'll fix it in the
next snapshot.

g

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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: Learning Idiomatic Clojure

[Mike Meyer]

On Thu, 12 May 2011 07:45:50 -0700 (PDT)
Adam Burry  wrote:
> On May 12, 11:54 am, Mike Meyer  wrote:
> > As others have said, this sounds like you need a book on
> > functional/LISP programming. There are some excellent books for other
> > LISP dialects. "Structure and Interpretation of Computer Programs"
> > (aka SICP) would be my recommendations, but "Practical Common Lisp"
> > and "On LISP" are both excellent. I don't know of a book at that
> > quality level using Clojure. There is an effort underway to translate
> > SICP to clojure athttp://sicpinclojure.com/.
> 
> Obviously, these are excellent texts, but I wonder if a Haskel book
> might be better place to look. The problem is I have not looked at any
> Haskel books, but I expect it would be a better place to read about
> the joys of laziness.

SICP and On LISP both deal with lazy data structures, but as a special
case. While clojure has the same data structures, their libraries
don't seem to try and conserve it the way that Clojure libraries do,
so those are probably inadequate for people doing clojure. I think
Haskell might take you to far the other way, since everything is lazy,
which changes things radically.

The best I know of here would be "Concepts, Techniques, and Models of
Computer Programming", but that takes you well away from Clojure's
mostly-functional paradigm.

I suspect that dealing properly with Clojure's laziness is a topic for
a clojure-specific book.

   http://www.mired.org/
Independent Software developer/SCM consultant, email for more information.

O< ascii ribbon campaign - stop html mail - www.asciiribbon.org

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Learning Idiomatic Clojure

[J.R. Garcia]

Thanks for the recommendations, guys! I'll be checking those resources
out.

On May 12, 10:25 am, Mike Meyer  wrote:
> On Thu, 12 May 2011 07:45:50 -0700 (PDT)
>
> Adam Burry  wrote:
> > On May 12, 11:54 am, Mike Meyer  wrote:
> > > As others have said, this sounds like you need a book on
> > > functional/LISP programming. There are some excellent books for other
> > > LISP dialects. "Structure and Interpretation of Computer Programs"
> > > (aka SICP) would be my recommendations, but "Practical Common Lisp"
> > > and "On LISP" are both excellent. I don't know of a book at that
> > > quality level using Clojure. There is an effort underway to translate
> > > SICP to clojure athttp://sicpinclojure.com/.
>
> > Obviously, these are excellent texts, but I wonder if a Haskel book
> > might be better place to look. The problem is I have not looked at any
> > Haskel books, but I expect it would be a better place to read about
> > the joys of laziness.
>
> SICP and On LISP both deal with lazy data structures, but as a special
> case. While clojure has the same data structures, their libraries
> don't seem to try and conserve it the way that Clojure libraries do,
> so those are probably inadequate for people doing clojure. I think
> Haskell might take you to far the other way, since everything is lazy,
> which changes things radically.
>
> The best I know of here would be "Concepts, Techniques, and Models of
> Computer Programming", but that takes you well away from Clojure's
> mostly-functional paradigm.
>
> I suspect that dealing properly with Clojure's laziness is a topic for
> a clojure-specific book.
>
>        --
> Mike Meyer           http://www.mired.org/
> Independent Software developer/SCM consultant, email for more information.
>
> O< ascii ribbon campaign - stop html mail -www.asciiribbon.org

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: lein-daemon 0.3

[Allen Rohner]

> Can I use this in order to run, for examples, a lein ring session as a
> deamon? :)
>

Yes, that exactly its intention.

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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: lein-daemon 0.3

[Alfredo]

Very useful indeed :)

On May 12, 5:54 pm, Allen Rohner  wrote:
> > Can I use this in order to run, for examples, a lein ring session as a
> > deamon? :)
>
> Yes, that exactly its intention.

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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: sessions in Ring, Sandbar, Compojure, etc...

[Shree Mulay]

@ James, yes.

(def app
(-> #'main-routes
(wrap-reload '(SocialNetworkCore.core))  ;;remove wrap-reload
from production code
(wrap-params)   ;; wraps params (inputs from
forms) - makes 'em available
;(wrap-flash);;
(wrap-session)  ;; wraps session
(wrap-request-logging)  ;; gives me request logging
(wrap-bounce-favicon)   ;; skirts favicon request logging
(wrap-exception-logging);; logs exceptions
(wrap-stacktrace))) ;; detailed stacktrace of errors

Anything look wrong there???

On May 12, 7:02 am, James Reeves  wrote:
> On 12 May 2011 04:49, Shree Mulay  wrote:
>
> > But for WHATEVER reason, the sessions are NOT getting stored?
>
> Have you added the session middleware? e.g.
>
> (def app
>   (-> main-routes
>       wrap-params
>       wrap-session))
>
> Or more succinctly:
>
> (def app
>   (handler/site main-routes))
>
> - James

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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: sessions in Ring, Sandbar, Compojure, etc...

[Shree Mulay]

James, et al.,

WHOA! I got it to work!

After I commented out

  ;(wrap-reload '(SocialNetworkCore.core))  ;;remove wrap-reload

it started behaving. Is the "wrap-reload" functionality not compatible
with Ring Sessions??? Have I implemented it the wrong way?

Only thing is, when I goto

http://127.0.0.1:3000/set
I still get:
You set x =

Though at:

http://127.0.0.1:3000/get
I get:
x = Shree

All thoughts are appreciated. Thanks! Y'all's help has been
wonderful! :)

shree

On May 12, 2:57 pm, Shree Mulay  wrote:
> @ James, yes.
>
> (def app
>     (-> #'main-routes
>         (wrap-reload '(SocialNetworkCore.core))  ;;remove wrap-reload
> from production code
>         (wrap-params)               ;; wraps params (inputs from
> forms) - makes 'em available
>         ;(wrap-flash)                ;;
>         (wrap-session)              ;; wraps session
>         (wrap-request-logging)      ;; gives me request logging
>         (wrap-bounce-favicon)       ;; skirts favicon request logging
>         (wrap-exception-logging)    ;; logs exceptions
>         (wrap-stacktrace)))         ;; detailed stacktrace of errors
>
> Anything look wrong there???
>
> On May 12, 7:02 am, James Reeves  wrote:
>
>
>
>
>
>
>
> > On 12 May 2011 04:49, Shree Mulay  wrote:
>
> > > But for WHATEVER reason, the sessions are NOT getting stored?
>
> > Have you added the session middleware? e.g.
>
> > (def app
> >   (-> main-routes
> >       wrap-params
> >       wrap-session))
>
> > Or more succinctly:
>
> > (def app
> >   (handler/site main-routes))
>
> > - James

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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: Type hinting inconsistencies in 1.3.0

[Ken Wesson]

On Thu, May 12, 2011 at 6:44 AM, Juha Arpiainen  wrote:
> On May 12, 1:18 pm, Ken Wesson  wrote:
>> This reads to me
>> as implying that hinting (defn ^String foo [] ...) is hinting that foo
>> references a String rather than an IFn that returns a String
>
> It is if you use 'foo in argument position. That is, if Foo/bar is
> overloaded for String and IFn, then (Foo/bar foo) resolves to the
> wrong version.

MORE type hinting inconsistencies, then.

There does seem to be something of a mess in this area, in need of
cleaning up before 1.3 goes stable.

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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: sessions in Ring, Sandbar, Compojure, etc...

[James Reeves]

On 12 May 2011 20:37, Shree Mulay  wrote:
>  ;(wrap-reload '(SocialNetworkCore.core))  ;;remove wrap-reload
>
> it started behaving. Is the "wrap-reload" functionality not compatible
> with Ring Sessions??? Have I implemented it the wrong way?

I'm not sure. There exist better alternatives to the `wrap-reload`
middleware anyway, such as the lein-ring plugin.

> Only thing is, when I goto
>
> http://127.0.0.1:3000/set
> I still get:
> You set x =
>
> Though at:
>
> http://127.0.0.1:3000/get
> I get:
> x = Shree

Yes, because "x" is a parameter that is never set. In my original example:

   (GET "/set" [x :as {session :session}]
 {:session (assoc session :x x)
 :body (str "You set x = " x)})

So you'd set it by going to "http://localhost:3000/set?x=foo";.

You then hard-coded the :x session key to "Shree", but you didn't
change the value of the "x" variable:

   (GET "/set" [x :as {session :session}]
 {:session (assoc session :x "Shree")
 :body (str "You set x = " x)})

- James

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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: Learning Idiomatic Clojure

[Sean Corfield]

I'll +1 on The Joy of Clojure. I have the PDF on my iPhone and dip
into it early and often. Probably on my fourth full read of it now on
my iPad too.

On Thu, May 12, 2011 at 9:31 AM, Islon Scherer  wrote:
> Read the joy of clojure, it's an amazing book that will teach you the
> way of 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

Collaboration Proposal: Beyond CLOS Generic Methods, Predicate Dispatch, and Pattern Matching

[David Nolen]

Hello fellow Clojurians,

As some of you may know I've been doing a bit of research into efficient
predicate dispatch, generic methods, and state-of-the-art implementations of
pattern-matching in OCaml. After a bit of reading and prototyping, I'm quite
confident that it's possible to build something considerably more powerful
than generic methods or predicate dispatch that exhibits the performance of
the fastest pattern matching algorithms to be found in Standard ML, Haskell,
Ocaml, and Scala (without their numerous limitations).

The main innovation here is to use logic programming to drive the
compilation to decisions tree as some members of the ML family do. This
gives us the following:

- Open quality of CLOS generic methods
- User customizable specializers like CLOS
- Removes order requirements of ML style pattern matching
- Richer reasoning about errors beyond just non-exhaustiveness.

I plan on continuing to tackle this myself, but I'm putting this out there
to see if anyone else is interested in joining forces. This project isn't
nearly as daunting as it sounds. The OCaml aglorithms are well described and
we already have a logic engine - core.logic.

I think the project would find very wide use w/in the Clojure community and
I think it would be a great opportunity to accomplish the following:

- Learn how to write very, very high performance Clojure (6X-20X faster than
multimethods)
- Leverage relational/logic programming in a functional context
- Give Clojure a notable feature that any sufficiently advanced programming
language should be quite jealous of :D

Ping me on or off list if you'd like collaborate!

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: Learning Idiomatic Clojure

[Paul deGrandis]

I'll also jump on that, I'm on my second or third full read of Joy of
Clojure.  Just a great book about the why and when of the language
features ("why does feature X exist, when should I use it, when am I
abusing it").

Paul

On May 12, 2:55 pm, Sean Corfield  wrote:
> I'll +1 on The Joy of Clojure. I have the PDF on my iPhone and dip
> into it early and often. Probably on my fourth full read of it now on
> my iPad too.
>
>
>
>
>
>
>
> On Thu, May 12, 2011 at 9:31 AM, Islon Scherer  wrote:
> > Read the joy of clojure, it's an amazing book that will teach you the
> > way of 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: sessions in Ring, Sandbar, Compojure, etc...

[Shree Mulay]

James, et al.,

> I'm not sure. There exist better alternatives to the `wrap-reload`
> middleware anyway, such as the lein-ring plugin.
>

I didn't know there was? What I understood of wrap-reload is that I
didn't have to restart "lein ring server" at the command line
everytime I made a change to my core.clj file???

How do I set up lein-ring to give me the same functionality?

Cause, I'd REALLY appreciate that!

Appears I'd save a LOT of time! It's painful having to restart jvm
everytime I intend to make a change to the html, eh

>
> Yes, because "x" is a parameter that is never set. In my original example:
>
>    (GET "/set" [x :as {session :session}]
>      {:session (assoc session :x x)
>      :body (str "You set x = " x)})
>
> So you'd set it by going to "http://localhost:3000/set?x=foo";.
>
> You then hard-coded the :x session key to "Shree", but you didn't
> change the value of the "x" variable:
>
>    (GET "/set" [x :as {session :session}]
>      {:session (assoc session :x "Shree")
>      :body (str "You set x = " x)})

Gosh, I feel STUPID!

Thanks everyone for their patience and their time! I'm on my way!

Regards,

shree

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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: Collaboration Proposal: Beyond CLOS Generic Methods, Predicate Dispatch, and Pattern Matching

[Jonathan Fischer Friberg]

I'd like to help, if I can.

Jonathan

On Fri, May 13, 2011 at 12:03 AM, David Nolen wrote:

> Hello fellow Clojurians,
>
> As some of you may know I've been doing a bit of research into efficient
> predicate dispatch, generic methods, and state-of-the-art implementations of
> pattern-matching in OCaml. After a bit of reading and prototyping, I'm quite
> confident that it's possible to build something considerably more powerful
> than generic methods or predicate dispatch that exhibits the performance of
> the fastest pattern matching algorithms to be found in Standard ML, Haskell,
> Ocaml, and Scala (without their numerous limitations).
>
> The main innovation here is to use logic programming to drive the
> compilation to decisions tree as some members of the ML family do. This
> gives us the following:
>
> - Open quality of CLOS generic methods
> - User customizable specializers like CLOS
> - Removes order requirements of ML style pattern matching
> - Richer reasoning about errors beyond just non-exhaustiveness.
>
> I plan on continuing to tackle this myself, but I'm putting this out there
> to see if anyone else is interested in joining forces. This project isn't
> nearly as daunting as it sounds. The OCaml aglorithms are well described and
> we already have a logic engine - core.logic.
>
> I think the project would find very wide use w/in the Clojure community and
> I think it would be a great opportunity to accomplish the following:
>
> - Learn how to write very, very high performance Clojure (6X-20X faster
> than multimethods)
> - Leverage relational/logic programming in a functional context
> - Give Clojure a notable feature that any sufficiently advanced programming
> language should be quite jealous of :D
>
> Ping me on or off list if you'd like collaborate!
>
> David
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Collaboration Proposal: Beyond CLOS Generic Methods, Predicate Dispatch, and Pattern Matching

[David Nolen]

The following are what I would consider helpful reading and some advice
about their content:

- CiteSeerX — Efficient Predicate
Dispatching
  Good place to start, covers why the feature I'm proposing would be useful.
The algorithms described here however can be ignored.
- Compiling Pattern Matching to Good Decision
Trees
  The heart of the matter. This describes the algorithm I'd like to see
implemented. Do not be put off by the mathematical notation! It's really a
shorthand so they don't have to write OCaml. It does require a few
re-readings but the ideas here are very well expressed and mostly easy to
follow.
- Warnings for pattern
matching
  An earlier paper that explains the idea of "usefulness" used in the paper
above. The portions on Haskell and lazy-evaluation can be completely
ignored.

Another interesting book to look at would be The Art of the Metaobject
Protocol - The MIT Press , but I
don't consider it essential.

You really don't need to know OCaml or SML very well to understand the above
papers. However I have found it helpful to have an StandardML/NJ compiler
(REPL) handy to at least test out some of the things described in the
papers.

I've been pouring over these three papers again and again so I'm more than
happy to discuss my understanding of them. Again the most important paper is
the second one. My idea is to implement that algorithm and use a very small
amount of logic programming to reason about user defined patterns so they
can be properly ordered and compiled.

To move forward I would suggest:

1) Send in your CA if you haven't already
2) Skim the papers in your free time
3) Dig into the 2nd paper
4) Ping me on #clojure IRC or email me with whatever questions you may have
4) Start hacking :)

I have a repo that primarily consists of sketches here,
https://github.com/swannodette/match. I think this is less relevant than
everyone having some basic grounding in the ideas covered in the mentioned
papers.

David

On Thu, May 12, 2011 at 6:03 PM, David Nolen  wrote:

> Hello fellow Clojurians,
>
> As some of you may know I've been doing a bit of research into efficient
> predicate dispatch, generic methods, and state-of-the-art implementations of
> pattern-matching in OCaml. After a bit of reading and prototyping, I'm quite
> confident that it's possible to build something considerably more powerful
> than generic methods or predicate dispatch that exhibits the performance of
> the fastest pattern matching algorithms to be found in Standard ML, Haskell,
> Ocaml, and Scala (without their numerous limitations).
>
> The main innovation here is to use logic programming to drive the
> compilation to decisions tree as some members of the ML family do. This
> gives us the following:
>
> - Open quality of CLOS generic methods
> - User customizable specializers like CLOS
> - Removes order requirements of ML style pattern matching
> - Richer reasoning about errors beyond just non-exhaustiveness.
>
> I plan on continuing to tackle this myself, but I'm putting this out there
> to see if anyone else is interested in joining forces. This project isn't
> nearly as daunting as it sounds. The OCaml aglorithms are well described and
> we already have a logic engine - core.logic.
>
> I think the project would find very wide use w/in the Clojure community and
> I think it would be a great opportunity to accomplish the following:
>
> - Learn how to write very, very high performance Clojure (6X-20X faster
> than multimethods)
> - Leverage relational/logic programming in a functional context
> - Give Clojure a notable feature that any sufficiently advanced programming
> language should be quite jealous of :D
>
> Ping me on or off list if you'd like collaborate!
>
> 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: Collaboration Proposal: Beyond CLOS Generic Methods, Predicate Dispatch, and Pattern Matching

[David Nolen]

On Thu, May 12, 2011 at 7:30 PM, Jonathan Fischer Friberg <
odysso...@gmail.com> wrote:

> I'd like to help, if I can.
>
> Jonathan


I'm sure you can :) Give those papers a looksee and let me know what you
think.

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: sessions in Ring, Sandbar, Compojure, etc...

[James Reeves]

On 13 May 2011 00:23, Shree Mulay  wrote:
> I didn't know there was? What I understood of wrap-reload is that I
> didn't have to restart "lein ring server" at the command line
> everytime I made a change to my core.clj file???
>
> How do I set up lein-ring to give me the same functionality?

lein-ring will automatically reload any modified file in your src
directory without you having to do a thing.

Try starting "lein ring server" and then changing one of your source
files. When you refresh the page in your browser, the changes should
instantly be visible without the need for a restart.

- James

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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: Collaboration Proposal: Beyond CLOS Generic Methods, Predicate Dispatch, and Pattern Matching

[Brent Millare]

Hey,

Can you give a simple explanation how your methods would be faster
than multimethods. Does this mean your implementation uses protocols
underneath? How does multimethods work? How many branches?

-Brent
On May 12, 7:57 pm, David Nolen  wrote:
> On Thu, May 12, 2011 at 7:30 PM, Jonathan Fischer Friberg <
>
> odysso...@gmail.com> wrote:
> > I'd like to help, if I can.
>
> > Jonathan
>
> I'm sure you can :) Give those papers a looksee and let me know what you
> think.
>
> 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: Type hinting inconsistencies in 1.3.0

[Chas Emerick]

On May 12, 2011, at 3:53 PM, Ken Wesson wrote:

> On Thu, May 12, 2011 at 6:44 AM, Juha Arpiainen  wrote:
>> On May 12, 1:18 pm, Ken Wesson  wrote:
>>> This reads to me
>>> as implying that hinting (defn ^String foo [] ...) is hinting that foo
>>> references a String rather than an IFn that returns a String
>> 
>> It is if you use 'foo in argument position. That is, if Foo/bar is
>> overloaded for String and IFn, then (Foo/bar foo) resolves to the
>> wrong version.
> 
> MORE type hinting inconsistencies, then.
> 
> There does seem to be something of a mess in this area, in need of
> cleaning up before 1.3 goes stable.

Object-based hints are not new, and haven't changed in 1.3.0 as far as I can 
tell.  Such hints are _hints_, not type declarations (in the case of a var's 
value) or return type declarations (in the case of a fn held by a var).  This 
is distinct from primitive "hints", which — in the context we've been 
discussing them — _are_ return type declarations (i.e. they change the type of 
the return from the function's generated class).

- 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: Type hinting inconsistencies in 1.3.0

[Ken Wesson]

On Thu, May 12, 2011 at 11:32 PM, Chas Emerick  wrote:
> Object-based hints are not new, and haven't changed in 1.3.0 as far as I can 
> tell.  Such hints are _hints_, not type declarations (in the case of a var's 
> value) or return type declarations (in the case of a fn held by a var).

I never said they were not hints.

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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: Learning Idiomatic Clojure

[Gregg Williams]

This is good advice, but I can't parse 1a after the phrase "or maybe",
and I'm not sure about 1b. Can you reword them, making it clearer when
you're using a Clojure keyword? I want to be sure I understand what
you're saying--it sounds insightful! Thanks.

On May 11, 9:09 pm, Ken Wesson  wrote:
> On Wed, May 11, 2011 at 10:10 PM, J.R. Garcia  wrote:
> > I'm wondering what resources would be best to learn how Clojurians
> > write their code.
>
> > I've been developing for about 4 years in several object-oriented
> > languages (mostly C# and Ruby). I understand Clojure's syntax well and
> > I'm familiar with a lot of the features of Clojure (although I'm sure
> > several of you would prove me wrong). One problem I keep running into
> > is how to attack a problem "the Clojure way". I often find myself
> > writing Clojure like I would write C# code with LINQ, only in
> > Clojure's syntax.
>
> > I'm not interested in Java interop or Clojure on the web or Clojure's
> > syntax. I've had no problem finding answers for those things on the
> > Internet. I'm really more interested in stuff like
> >http://www.bestinclass.dk/index.clj/2010/10/taking-uncle-bob-to-schoo...,
> > but covering a wider range of things rather than a small example. I'm
> > interested in any resource whether it's a book, a video, a blog, a
> > person, etc.
>
> > Any suggestions?
>
> I don't know about any books or other resources, but a few general pointers:
>
> 1. Think functional. Try to express as much as possible as "data
> plumbing": here is an input, here is the desired result, how to get
> there from here? Think in terms of calculating a new value in terms of
> an existing one, rather than changing things in place. Familiarize
> yourself with map, filter, remove, reduce, iterate, and friends, and
> the data structures (maps, sets, vectors, seqs) and use those to
> represent as much as possible and to do as much as possible. In
> particular, when a processing step has to be repeated:
>
> 1a. If it's for each element of a sequence, consider map, reduce, and
> for. If it has to walk several sequences in tandem, use map, or maybe
> reduce or for with (map vector s1 s2 ...). If it's for each
> combination in some sequences, so for all in the first sequence, and
> for each of those for all in the second, etc., use for.
>
> 1b. If it's accumulating a result, consider reduce, even if the input
> isn't (obviously) a sequence, or iterate, before resorting to
> loop/recur.
>
> 2. When the time comes to abstract things, abstract as much as you can
> using function arguments and, perhaps, returns and using maps before
> resorting to defmulti/defrecord/etc.
>
> 3. Look at other Clojure code, including what shows up here from time
> to time, and ask here about making specific code more idiomatic. Many
> people here will likely answer fairly quickly, and even when they
> disagree, the disagreement and their stated reasons for disagreeing
> may themselves be illuminating -- and then anything *everyone* agrees
> is ugly or poor practice almost certainly is. :)

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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: Learning Idiomatic Clojure

[Ken Wesson]

On Fri, May 13, 2011 at 12:29 AM, Gregg Williams  wrote:
> This is good advice, but I can't parse 1a after the phrase "or maybe",
> and I'm not sure about 1b. Can you reword them, making it clearer when
> you're using a Clojure keyword? I want to be sure I understand what
> you're saying--it sounds insightful! Thanks.

OK --

1. Think functional. Try to express as much as possible as "data
plumbing": here is an input, here is the desired result, how to get
there from here? Think in terms of calculating a new value in terms of
an existing one, rather than changing things in place. Familiarize
yourself with "map", "filter", "remove", "reduce", "iterate", and
"friends", and the data structures (maps, sets, vectors, and seqs) and
use those to represent as much as possible and to do as much as
possible. In particular, when a processing step has to be repeated:

1a. If it's for each element of a sequence, consider "map", "reduce",
and "for". If it has to walk several sequences in tandem, use "map",
or maybe "reduce" or "for" with (map vector s1 s2 ...) as the input.
If it's for each combination in some sequences, so for all in the
first sequence, and for each of those for all in the second, etc., use
"for".

1b. If it's accumulating a result, consider "reduce", even if the
input isn't (obviously) a sequence, or "iterate", before resorting to
"loop"/"recur".

2. When the time comes to abstract things, abstract as much as you can
using functions as arguments and, perhaps, as return values and using
maps before resorting to "defmulti"/"defrecord"/etc.

3. Look at other Clojure code, including what shows up here from time
to time, and ask here about making specific code more idiomatic. Many
people here will likely answer fairly quickly, and even when they
disagree, the disagreement and their stated reasons for disagreeing
may themselves be illuminating -- and then anything *everyone* agrees
is ugly or poor practice almost certainly is. :)

That better? I made a few other tweaks as well as quoting all the
names of core functions and macros I was referring to.

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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: Collaboration Proposal: Beyond CLOS Generic Methods, Predicate Dispatch, and Pattern Matching

[David Nolen]

On Thu, May 12, 2011 at 10:26 PM, Brent Millare wrote:

> Hey,
>
> Can you give a simple explanation how your methods would be faster
> than multimethods. Does this mean your implementation uses protocols
> underneath? How does multimethods work? How many branches?
>
> -Brent
>

There's quite a bit of overhead in the current implementation of
multimethods:

- dispatch fn
- in order to deal w/ complex matches dispatch fn must construct a
collection
- this collection is looked up in map
- if not found check to see that if it's been memoized
- if not memoized check to figure out if it matches an entry in the map
- when found memoize

In the implementation I'm proposing we only do the following:

- literal matches are dealt with case
- instance? or custom predicate matches done w/ if

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: Collaboration Proposal: Beyond CLOS Generic Methods, Predicate Dispatch, and Pattern Matching

[Heinz N. Gies]

Hearing Pattern Matching,
do you mean Erlang like Pattern matching?

Regards,
Heinz

smime.p7s
Description: S/MIME cryptographic signature

Re: Import other .clj files

[MohanR]

I am able to set the swank-clojure-classpath and also verify it using
C-h v. It has the current directory "." and also other directories
where .clj files are located

If a .clj file has a namespace I ensure the classpath points to the
root of the namespace folder structure like I do with Java.


What else is missing ?

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en