Re: ANN: Om, a ClojureScript binding to Facebook's React

2013-12-21 Thread Conrad Barski
Two quick questions as I am working through the OM stuff... glad if anyone here 
has some pointers to point me in the right directions...

1. I seem to be unable to get "lein trampoline cljsbuild repl-listen" to serve 
up a css file on my own Om project... I have my css located at "[project 
root]/css/main.css" and then reference it in the html as  but this just throws a 404 error for main.css when I run 
my program. I've tried many other variations but nothing seems to work. 
Javascript, html, and sourcemaps work fine. Anyone have an idea of what I'm 
doing wrong? How does repl-listen decide where the css lives?

2. In the Om TodoMVC app in the function "handle-new-todo-keydown" there is one 
ugly line of code that reads:
(set! (.-value new-field) "")

   Anyone figure out yet why such a DOM manipulation was necessary in that case?
   

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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 unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.


Re: Does Pedestal have a future in the long run

2013-12-21 Thread Murtaza Husain
I dont know much about the third project so will comment on Pedestal and 
Om. I see both of these projects as complimentary - 

1. Pedestal concerns itself with propagating the change in your state, and 
wiring the dependencies within it. Its sort of dataflow/FRP in cljs. 

2. Om/react.js in concerned with taking a state and rendering it 
efficiently. 

So pedestal events/msgs can be easily flow to Om bindings, which re-renders 
the DOM. 

Looking forward to the next pedestal release which will simplify things. 
And also looking forward to the rapidly evolving Om framework. 

Thanks,
Murtaza


On Saturday, December 21, 2013 1:44:15 AM UTC+5:30, Thomas Deutsch wrote:
>
> As far as i can read the community, there are 3 Projects that use the UI 
> as a value.
>
> - Pedestal  
> - Om
> - Aurora  ( comming early 2014 )
>
> As a Clojure community we know "the value of 
> values", 
> and for a UI as a value we will have "Immediate 
> Mode" 
> on the view side of things,
> because we want to reflect our value (a clojure/script data type) to the 
> DOM.
> It seems that all 3 Projects could use react.js because:
> *"react.js is the immediate mode abstraction over the retained mode 
> dom"*(Chris Granger)
>
> Does Pedestal have a future in the long run?
> I hope that pedestal will be simple, and open to a solution to use 
> react.js or any immediate mode abstraction lib that will come along.
>
>
>

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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 unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.


Re: clojure.java.jdbc 0.3.0 column name handling

2013-12-21 Thread Sean Corfield
There are two hooks for naming strategies in java.jdbc:

* :identifiers - for converting ResultSet column names to keywords
* :entities - for converting Clojure keywords/string to SQL entity names

:identifiers defaults to clojure.string/lower-case - so SQL column
names become lowercase keywords.

:entities defaults to identity - so Clojure keywords and strings
simply become SQL table and column names as-is.

A call to the quoted function is a suitable argument for :entities -
available on delete!, insert!, update!, create-table-ddl and
drop-table-ddl. For the execute! and query functions (and others), you
pass raw SQL so you are expected to have taken care of quoting
entities yourself.

(insert! db-spec :fruit {:name "Apple" :appearance "Round" :cost
99} :entities (quoted \`))

In the generated SQL, this will produce `fruit`, `name`, `appearance`,
and `cost`.

The docstrings on the new API could certainly make that clearer. I'm
planning to overhaul the docstrings now the API is stable and public -
since I can see that the arglists alone are far from satisfactory -
and I'm also in the middle of a major overhaul of the java.jdbc
section of clojure-doc.org to provide more examples, with full
tutorials on each of the major functions.

Does that help?

Sean


On Sat, Dec 21, 2013 at 11:56 AM, rod naph  wrote:
> with the new release of java.jdbc 0.3.0 i can't quite work out how the
> quoting support for column names is supposed to work.  i can see the
> strategy for the deprecated namespace, but the new core namespace only
> contains a function "quoted" - which isn't used directly at all.
>
> so what's the deal now - do we need to handle this in client code, or am i
> missing a trick?
>
> thanks,
> rod.
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your
> first post.
> To unsubscribe from 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 unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.



-- 
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
World Singles, LLC. -- http://worldsingles.com/

"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)

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


Re: bug in clojure.zip when calling next on empty list node?

2013-12-21 Thread Lee Spector

On Dec 21, 2013, at 11:49 AM, Lee Spector wrote:

> 
> When I step through a zipper made from a nested list via seq-zip, I get 
> extraneous nils after processing a nested (). 
> 
> Is this somehow expected behavior, or a bug, or am I misunderstanding 
> something fundamental?
> 
> The problem seems to arise only when an nested empty list is present, not 
> other nested lists and not other nested empty sequences (see example at 
> bottom for this bit).

I take it back about it working correctly with other nested empty sequences. I 
realize now that my example of that had a nested empty vector, not a sequence. 
Trying to reproduce that example with a nested empty sequence just confused me, 
because it turns out that (seq ()) = (seq []) = nil, and I'm not sure what that 
means... But this is all really a distraction from the case I care about, which 
is lists that contain (among other things) nested empty lists. For example, 
'(() 0). Here it seems to me that zip/next's behavior is clearly wrong and I'm 
not sure why or what to do about it.

Thanks,

 -Lee

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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 unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.


[ANN] Frodo 0.2.9 - Ring-compatible web server with Stuart Sierra's 'Reloaded' workflow

2013-12-21 Thread James Henderson
Hi all,

I've just released Frodo 0.2.9 - a web server plugin that allows you to 
develop using Stuart Sierra's 'Reloaded' workflow. It sets up a web server 
that you can nREPL into, easily open a CLJS browser REPL (using Chas 
Emerick's 'Austin' library) and, when you've made changes, to start a fresh 
web-server and refresh the server-side state without restarting the JVM.

*https://github.com/james-henderson/frodo*

If you haven't seen it already, Stuart's written a great blog on how to 
develop using the 'Reloaded' workflow and its benefits - it's at 
http://thinkrelevance.com/blog/2013/06/04/clojure-workflow-reloaded.

There are plenty of Frodo examples and a sample project on the GitHub repo, 
but the basic premise is that you configure Frodo with a function that 
initialises your system state and returns a handler. When your server-side 
code changes and you run (user/reload-frodo!)in the REPL, it will reload 
any changed namespaces (and anything that depends on a changed namespace), 
restart the web server and ask your function to initialise its state and 
return another handler. This usually looks something like:

(ns your-app.handler
  (:require [compojure.core :refer [routes GET]]
[compojure.handler :refer [api]]
[ring.util.response :refer [response]]))
 
(defn app-routes []
  (let [system (init-system)]
(routes
  (GET "/route/:id" [id]
(response (handle-get system id)))
 
  ...)))
 
(defn app []
  (-> (app-routes)
  wrap-with-ring-middleware
  api))


You'd then configure Frodo to use '*your-app.handler/app*' as its entry 
point.

Probably the easiest way to get up and running is to use '*splat*', a Lein 
template:

lein new splat 
cd 
lein dev

If you've got any questions or feedback, it'd be great to hear it! Let me 
know, either through here, GitHub or Twitter (I'm 
@jarohen
)

Hope you all have a great Christmas, and a happy New Year!

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
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.


Re: Who is "doing something worthwhile" in Clojure?

2013-12-21 Thread Bastien
Samuel Aaron  writes:

> To me at least, this is a worthwhile endeavour.

It certainly is!

Here is a quick intro to Overtone with Emacs and Org:
  http://bzg.fr/emacs-org-babel-overtone-intro.html

... as a "thank you" for this great expression medium.

-- 
 Bastien

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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 unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.


clojure.java.jdbc 0.3.0 column name handling

2013-12-21 Thread rod naph
with the new release of java.jdbc 0.3.0 i can't quite work out how the 
quoting support for column names is supposed to work.  i can see the 
strategy for the deprecated namespace, but the new core namespace only 
contains a function "quoted" - which isn't used directly at all.

so what's the deal now - do we need to handle this in client code, or am i 
missing a trick?

thanks,
rod.

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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 unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.


Re: How to go about 'proving' why dynamically typed languages are better.

2013-12-21 Thread Chris Zheng
@dennis - how would this model work on a type system?



I also believe that type systems are very awkward for modelling change - 
whereas a schema system like datomic is do much better because it is a lot 
looser in the constraints. For example, if we are modelling the stages if 
growth of a person, as well as the functions that they perform - baby, teen, 
further study/ work, career change, two jobs, parenting, etc... The type 
'person' would have to be very generic, and pretty much the same as type 
'nested map'. 

I like that typed clojure supports map checking and so it is not really 'typed 
clojure' in the traditional sense, but 'schema clojure' in the way datomic 
advocates use of data types.

On 20/12/2013, at 22:20, Dennis Haupt  wrote:

> in my mental world, there is a "pure human", and a 4 armed human would 
> probably be a 95% human or something, just like a hobbit would be. the other 
> way round, a human would be a "95% hobbit". an elephant would be 4% hobbit on 
> that scale.
> this model is flexible, covers everything, and is not really helpful when you 
> ask "what is it?" you have to ask "is this at least 90% cat?"
> 
> 
> 2013/12/20 Phillip Lord 
>> zcaudate  writes:
>> > @philip lord.
>> >
>> > Where would mutant elephants and the elephant god Ganesha fit in that 
>> > classification?
>> 
>> 
>> It might surprise you to know that there is actually quite a lot work on
>> both of these.
>> 
>> The problem with mutant elephants generalises into the problem with
>> abnormalities; for example, if I build a model of a human which says,
>> "humans have two hands, and two legs" then there are plenty of counter
>> examples, having more or less than two hands (mostly less). If, on the
>> other hand, you have a model which can cope with these exceptions, then
>> it gets too complex to handle, and you can rarely conclude anything
>> useful.
>> 
>> Ganesha causes a different problem: that is does he exist at all, and if
>> he does, is he an elephant. Now there are those who say no he isn't, so
>> he shouldn't be in the model. And, there are those (like me) who say,
>> well it depends on your application and what you are trying to achieve.
>> 
>> Farcical as all of this sounds, it does actually have implications for
>> the way that we build data models, particularly for biology and
>> medicine. If you are interested, you can read my paper on the subject
>> here:
>> 
>> http://www.russet.org.uk/blog/1713
>> 
>> And a companion article by my co-author. It's about unicorns, but most
>> of it probably covers Ganesha also.
>> 
>> http://robertdavidstevens.wordpress.com/2011/05/26/unicorns-in-my-ontology/
>> 
>> 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
>> ---
>> You received this message because you are subscribed to the Google Groups 
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to clojure+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/groups/opt_out.
> 
> -- 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from 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 a topic in the Google 
> Groups "Clojure" group.
> To unsubscribe from this topic, visit 
> https://groups.google.com/d/topic/clojure/0I7u5yn01qU/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to 
> clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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 unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.


bug in clojure.zip when calling next on empty list node?

2013-12-21 Thread Lee Spector

When I step through a zipper made from a nested list via seq-zip, I get 
extraneous nils after processing a nested (). 

Is this somehow expected behavior, or a bug, or am I misunderstanding something 
fundamental?

The problem seems to arise only when an nested empty list is present, not other 
nested lists and not other nested empty sequences (see example at bottom for 
this bit).

Here's an illustration, stepping through '(() 0) with next and printing the 
node at each step:

(loop [z (zip/seq-zip '(() 0))]
  (if (zip/end? z)
:done
(do (println (zip/node z))
  (recur (zip/next z)

That produces:

(() 0)
()
nil
0
:done

I don't expect the nil to be there.

If I do this with a 1 in place of the () then it works as I expect:

(loop [z (zip/seq-zip '(1 0))]
  (if (zip/end? z)
:done
(do (println (zip/node z))
  (recur (zip/next z)

produces:

(1 0)
1
0
:done

It also works as I expect if I put (1) in place of (), suggesting that it's not 
a problem with stepping over nested lists in general, but just with stepping 
over ():

(loop [z (zip/seq-zip '((1) 0))]
  (if (zip/end? z)
:done
(do (println (zip/node z))
  (recur (zip/next z)

produces:

((1) 0)
(1)
1
0
:done

However, if I use non-list sequences then things seem to work as I would expect:

(loop [z (zip/seq-zip (seq [[] 0]))]
  (if (zip/end? z)
:done
(do (println (zip/node z))
  (recur (zip/next z)

produces:

([] 0)
[]
0
:done

This is with Clojure 1.5.1. 

It's leading to null pointer exceptions in my application, so any explanations 
or fixes or pointers would be very much appreciated.

Thanks,

 -Lee

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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 unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.


[ANN] Liberator Templates

2013-12-21 Thread Daniel Higginbotham
Liberator Templates allows you to abstract patterns in your liberator 
resources so that you can define resources more consistently and concisely:

https://github.com/flyingmachine/liberator-templates

Hope y'all find it useful!

Daniel

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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 unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.


Re: [ANN] Austin — the ClojureScript browser-REPL, rebuilt stronger, faster, easier

2013-12-21 Thread Peter Wang
Hi,

On Tuesday, September 10, 2013 2:24:50 AM UTC+2, Nelson Morris wrote:
>
> I've been using austin on a project with emacs/nrepl.  It works for a C-c 
> C-k, switch to nrepl, interact with app. However, some other features like 
> auto-complete and jump-to-symbol-definition I'm used to in a clojure 
> workflow don't work or cause a core to spin.  I'd suspect the eldoc call to 
> show the function arguments could act similar.
>

I have the same problem about auto-complete/jump-to-symbol-definition in 
cljs repl/cljs buffer. Any updates about this? Or any other emacs mode 
(like cider) solved this?
 

> -
> Nelson
>
>
> On Mon, Sep 9, 2013 at 10:25 AM, Norman Richards 
> 
> > wrote:
>
>> On Mon, Aug 5, 2013 at 8:21 AM, Chas Emerick 
>> > wrote:
>>  
>>> As you might know, I've been tinkering with an easier-to-use variant of 
>>> ClojureScript's browser-REPL for some time.  I've finally wrapped that up 
>>> into its own project, Austin: [...]
>>>
>>
>>
>> Is anyone successfully using this with nrepl in emacs?  I am able to make 
>> it work, but something is causing both emacs and the JVM it is connected to 
>> to use 100% CPU.  I seem to be getting a long stream of "Unable to resolve 
>> symbol: if-let in this context, compiling:(NO_SOURCE_PATH:1:1)" 
>>
>> See: https://gist.github.com/orb/6496320
>>
>> *nrepl-connection* fills up with:
>>
>> d2:ex45:class 
>> clojure.lang.Compiler$CompilerException2:id6:1504207:root-ex45:class 
>> clojure.lang.Compiler$CompilerException7:session36:43e688aa-01c2-4824-b1f3-1bd05a1f02446:statusl10:eval-erroreed3:err128:CompilerException
>>  
>> java.lang.RuntimeException: Unable to resolve symbol: if-let in this 
>> context, compiling:(NO_SOURCE_PATH:1:1) 
>>
>>
>> I'm not sure if this is a problem with austin or if it's nrepl.el or 
>> something on the emacs side.  
>>
>> As a side note, I occasionally get a similar error message using straight 
>> nrepl when first starting up, but it usually only happens once.  With 
>> austin/nrepl it appears to be stuck in some kind of loop erroring over and 
>> over...  Does anyone have a known good setup I could try to reproduce?
>>
>>  -- 
>> -- 
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clo...@googlegroups.com
>> Note that posts from new members are moderated - please be patient with 
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+u...@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 unsubscribe from this group and stop receiving emails from it, send an 
>> email to clojure+u...@googlegroups.com .
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>
>

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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 unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.


Re: ANN: Om, a ClojureScript binding to Facebook's React

2013-12-21 Thread Mikera
This is brilliant, thanks for sharing David!

It might (finally!) be the tool I've been looking for to resurrect my 
interest in client-side development :-)

On Thursday, 19 December 2013 19:12:12 UTC, David Nolen wrote:
>
> Enjoy, 
> http://swannodette.github.io/2013/12/17/the-future-of-javascript-mvcs/
>
> 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 unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.