Re: Build tool for mixed Clojure/Java projects
On Jul 5, 12:43 pm, Ken Wesson wrote: > > What method was used to create the projects ab initio? Some sort of > direct interaction with Maven, followed by some kind of import into > each IDE instance? Or can one of those IDEs create a Maven project (as > opposed to a built-in project management project) ex nihilo by ticking > some box somewhere? > Netbeans can create Maven projects. Eclipse can also create Maven projects (once you have installed the Maven plugin). Enclojure lets you create Maven projects with the Clojure specific configuration already written for you. They can also both open/import Maven projects created outside the IDE. - 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
Re: Build tool for mixed Clojure/Java projects
On Mon, Jul 4, 2011 at 7:43 PM, Ken Wesson wrote: > I was using it in the sense typically meant in phrases like "source > code repository", as seems reasonable given the context, but oh well. If you're using git, "source code repository" could easily be local and not require an Internet connection... so I think it depends on your experience :) In the OP comment, I certainly took repository to just mean "somewhere you store stuff" and hence it could easily be local... -- Sean A Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ World Singles, LLC. -- http://worldsingles.com/ Railo Technologies, Inc. -- http://www.getrailo.com/ "Perfection is the enemy of the good." -- Gustave Flaubert, French realist novelist (1821-1880) -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Build tool for mixed Clojure/Java projects
On Mon, Jul 4, 2011 at 7:11 PM, Steve wrote: > On Jul 5, 7:13 am, Ken Wesson wrote: > >> > No, there's no server, no port, nothing to firewall. It's just a >> > directory (~/.m2/repository). >> >> So, not actually a repository, then. :) > > Well not as you're defining it :) But yes it is a repository if > repository means "place to store stuff". I was using it in the sense typically meant in phrases like "source code repository", as seems reasonable given the context, but oh well. >> One problem with that is that you generally can't *not* use your IDE's >> built in project management unless you don't use an IDE at all (vi, >> emacs, Notepad, whatever rather than Eclipse, IDEA, Netbeans, >> whatever). > > No that's not right, Netbeans (and I'm sure Eclipse, no idea about > IDEA) happily creates and works with Maven projects. Perhaps, but not by default. File->New->Project creates built-in project management projects, at least in Eclipse, to judge by the fact that the result appears to be a project to the built-in project management functionality. :) > We have guys working here using a range of different tools (mostly Java > projects using Netbeans and Eclipse, running on Linux and Windows) > and because we've standardised on Maven we have very few issues > sharing projects. What method was used to create the projects ab initio? Some sort of direct interaction with Maven, followed by some kind of import into each IDE instance? Or can one of those IDEs create a Maven project (as opposed to a built-in project management project) ex nihilo by ticking some box somewhere? (The third option, that one or each makes Maven projects natively by default or even has no distinct "built-in project management project" type, seems to be excluded by your earlier statement of "I'd be more confident of being able to build your project if you're using maven/lein/cake/etc. than if you're using the IDEs built in project management facilities".) -- Protege: What is this seething mass of parentheses?! Master: Your father's Lisp REPL. This is the language of a true hacker. Not as clumsy or random as C++; a language for a more civilized age. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: nrepl example/tutorial
You can try jark: http://icylisper.in/jark/ Jark provides an nrepl-server and client. The client has a REPL too. - isaac -- 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
nrepl example/tutorial
Hi I just can't find an example/tutorial on how to use nrepl. Anyone knows? The github page only shows how to get it from maven central and build it. Maybe it is too obvious, but I'm quite new to clojure and it would be good to have some guidance. I could find that counterclockwise is able to connect to a nrepl server, and I'd like to have a repl running on a remote server that I could interact with. Thanks Rui -- 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: Build tool for mixed Clojure/Java projects
On Jul 5, 7:13 am, Ken Wesson wrote: > > > No, there's no server, no port, nothing to firewall. It's just a > > directory (~/.m2/repository). > > So, not actually a repository, then. :) > Well not as you're defining it :) But yes it is a repository if repository means "place to store stuff". In particular, "place to store jars for one project that can be effortlessly depended upon by another project". > > One problem with that is that you generally can't *not* use your IDE's > built in project management unless you don't use an IDE at all (vi, > emacs, Notepad, whatever rather than Eclipse, IDEA, Netbeans, > whatever). > No that's not right, Netbeans (and I'm sure Eclipse, no idea about IDEA) happily creates and works with Maven projects. We have guys working here using a range of different tools (mostly Java projects using Netbeans and Eclipse, running on Linux and Windows) and because we've standardised on Maven we have very few issues sharing projects. - 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
Re: Please stand firm against Steve Yegge's "yes language" push
On Mon, Jul 4, 2011 at 1:44 PM, Mark Rathwell wrote: > > A function is a function, whether it is bound to a Var or not. I think that > was Ken's point, that you need to wrap a Java method in a function > (anonymous or named) in order to pass to an HOF, as Java methods are not > first class. So, that is one instance where a function whose sole purpose > is to wrap a Java method may make sense. Exactly. A related case may be when you're not making just a straight wrapper, but adding something -- your own pre/post checks, or argument transformations, or etc. As for binding to a Var, that makes sense if the result is not as trivial as #(.meth %) and is going to be used many times. Otherwise #(.meth %) is not much longer than a reasonably clear Var name for it and is crystal clear as to what it does, so I'd just use that. -- Protege: What is this seething mass of parentheses?! Master: Your father's Lisp REPL. This is the language of a true hacker. Not as clumsy or random as C++; a language for a more civilized age. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Build tool for mixed Clojure/Java projects
On Mon, Jul 4, 2011 at 10:16 AM, Steve wrote: > On Jul 4, 9:08 pm, Ken Wesson wrote: >> >> That's actually a bit worrying. I'm not sure I want a potential >> security hole into my computer, such as a repository, being "handled >> for me" without having *some* input into the matter. For example if I >> intend to use it purely locally I'd want to firewall the port it's >> using to make sure it's unreachable from any address other than >> 127.0.0.1. >> > > No, there's no server, no port, nothing to firewall. It's just a > directory (~/.m2/repository). So, not actually a repository, then. :) > Well exactly - by using an independent build tool you decrease the > likelihood of your build being tied to a particular IDE. If I'm using > Netbeans on linux, and you're using Eclipse on windows I'd be more > confident of being able to build your project if you're using maven/ > lein/cake/etc. than if you're using the IDEs built in project > management facilities or a bunch of shell scripts (or ant for that > matter). One problem with that is that you generally can't *not* use your IDE's built in project management unless you don't use an IDE at all (vi, emacs, Notepad, whatever rather than Eclipse, IDEA, Netbeans, whatever). > I think that Greenspun's tenth rule has an analogue in hand rolled > build systems - most of them end up being a crappy implementation of > 10% of maven's functionality (and maven is not that nice to begin > with :) That's not *too* bad, compared to Greenspun's 50%. On the other hand I'd think the more natural comparison would be to make, which after all long predates maven and may even be half as old as Common Lisp. :) -- Protege: What is this seething mass of parentheses?! Master: Your father's Lisp REPL. This is the language of a true hacker. Not as clumsy or random as C++; a language for a more civilized age. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: iterate?
Or, to defeat the purpose of iterate entirely: (= (repeat 100 :foo) (take 100 (iterate (constantly :foo) :foo))) On Jul 4, 3:51 am, Christophe Grand wrote: > => (= (repeat 100 :foo) > (take 100 (iterate identity :foo))) > true > > hth, > > Christophe > > > > > > > > > > On Mon, Jul 4, 2011 at 12:39 PM, Antonio Recio wrote: > > Do you know how to solve this? > > > (= (repeat 100 :foo) > > (take 100 (iterate ___ :foo))) > > > -- > > 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 > > -- > Professional:http://cgrand.net/(fr) > On Clojure:http://clj-me.cgrand.net/(en) -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Clojure for large programs
Yes, exactly. I'm going to check that out.
Thanks Shantanu
Tim
On Sun, Jul 3, 2011 at 11:42 AM, Shantanu Kumar wrote:
>
>
> On Jul 3, 7:39 pm, Timothy Washington wrote:
> > I'm using pre / post assertions quite a bit in a project I'm building.
> And I
> > too would love to see better or custom error messages for each assertion.
>
> That should be possible with a macro. For example, I use this:
>
> https://bitbucket.org/kumarshantanu/clj-miscutil/src/acfb97c662d9/src/main/clj/org/bituf/clj_miscutil.clj#cl-1009
>
> Maybe you need something like this(?):
>
> (defmacro verify-my-arg
> "Like assert, except for the following differences:
> 1. does not check for *assert* flag
> 2. throws IllegalArgumentException"
> [err-msg arg]
> `(if ~arg true
> (throw (IllegalArgumentException. ~err-msg
>
> Then use it thus:
>
> (defn foo [m]
> {:pre [(verify-my-arg "m must be a map" (map? m))]}
> (println m))
>
> Regards,
> Shantanu
>
> --
> 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: Sample Vaadin application in Clojure
On Jul 2, 2011, at 12:53 PM, Dmitry Gutov wrote: >> Is there any hope of getting rid of the servlet altogether, and >> somehow get a Ring handler to perform whatever Vaadin stuff that needs >> to be done on the server? > > Well, you could rewrite the servlet in Clojure... right? > Aside from that, I don't think so. Ring works on a much lower level of > abstraction. FWIW, https://github.com/laurentpetit/ring-java-servlet provides a canned compiled servlet that will delegate all requests to a ring handler you specify in your web.xml descriptor. That's generally useful, not just for Vaadin apps, and (often) allows you to eliminate AOT compilation from your ring projects. - 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: Please stand firm against Steve Yegge's "yes language" push
A function is a function, whether it is bound to a Var or not. I think that was Ken's point, that you need to wrap a Java method in a function (anonymous or named) in order to pass to an HOF, as Java methods are not first class. So, that is one instance where a function whose sole purpose is to wrap a Java method may make sense. On Mon, Jul 4, 2011 at 1:20 PM, James Keats wrote: > > > On Jul 3, 6:15 am, Ken Wesson wrote: > > > > There's one obvious use case for such a wrapper function, though: if > > you'll want to pass the Java method to HOFs from time to time. You > > can't directly pass a Java method to a HOF, but you can pass such a > > wrapper function. > > > > Pardon me if I'm wrong, but could you not use an anonymous function in > those places where you'd need to pass it to a HOF and continue to use > it directly elsewhere? That would probably be how I'd prefer it, as > it'd mean less functions to keep track of, and less indirection > (decoupling api concerns aside). > > > -- > > Protege: What is this seething mass of parentheses?! > > Master: Your father's Lisp REPL. This is the language of a true > > hacker. Not as clumsy or random as C++; a language for a more > > civilized age. > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > -- 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: Please stand firm against Steve Yegge's "yes language" push
On Jul 3, 6:15 am, Ken Wesson wrote: > > There's one obvious use case for such a wrapper function, though: if > you'll want to pass the Java method to HOFs from time to time. You > can't directly pass a Java method to a HOF, but you can pass such a > wrapper function. > Pardon me if I'm wrong, but could you not use an anonymous function in those places where you'd need to pass it to a HOF and continue to use it directly elsewhere? That would probably be how I'd prefer it, as it'd mean less functions to keep track of, and less indirection (decoupling api concerns aside). > -- > Protege: What is this seething mass of parentheses?! > Master: Your father's Lisp REPL. This is the language of a true > hacker. Not as clumsy or random as C++; a language for a more > civilized age. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Clojure for large programs
No worries. I have the book on my shelf. The first version. But thanks for making me aware of the second version. -- 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: Build tool for mixed Clojure/Java projects
On Jul 4, 9:08 pm, Ken Wesson wrote: > > That's actually a bit worrying. I'm not sure I want a potential > security hole into my computer, such as a repository, being "handled > for me" without having *some* input into the matter. For example if I > intend to use it purely locally I'd want to firewall the port it's > using to make sure it's unreachable from any address other than > 127.0.0.1. > No, there's no server, no port, nothing to firewall. It's just a directory (~/.m2/repository). > > There's also the fact that everything remains simple (maybe too > simple; see above) only so long as you remain inside the cushioned box > of the particular IDE. As soon as you try to do anything else -- tweak > something from vi or Notepad, significantly refactor and rename and > restructure stuff in a manner that changes some file paths, move to or > sync with another machine, share with a collaborator, even just find > the source files to back them up somewhere safe -- you're in the deep > woods, possibly without a good map. :) > Well exactly - by using an independent build tool you decrease the likelihood of your build being tied to a particular IDE. If I'm using Netbeans on linux, and you're using Eclipse on windows I'd be more confident of being able to build your project if you're using maven/ lein/cake/etc. than if you're using the IDEs built in project management facilities or a bunch of shell scripts (or ant for that matter). I think that Greenspun's tenth rule has an analogue in hand rolled build systems - most of them end up being a crappy implementation of 10% of maven's functionality (and maven is not that nice to begin with :) - 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
Re: Clojure for large programs
I think the issue with large programs is not the language but software engineering. A large program should be well designed and architected, and this is a problem (I think) many people in clojure and functional programming in general have. "Clojure is a very high level and concise language so I'll grow my program as I type". I'm not proposing UML or any specific tool or technique, but analysis and design are a important part of a large software. It's easier to understand your problem if you look at your high level documentation/diagrams than look at code. Of course some problems and refactor will happen no matter how well you designed, but you'll understand better what you did and what you should do. Islon On Jul 4, 9:40 am, James Keats wrote: > On Jul 4, 1:26 pm, James Keats wrote: > > > On Jul 4, 5:45 am, Christian Schuhegger > > A good > > book to get you started would SEMANTIC WEB for the WORKING ONTOLOGIST, > > of which a second edition has recently come out. :-) > > Sorry about the unintentional "to get you started" figure of speech; I > note you said you already had rdf/owl in your kit. It's not out of > underestimating your knowledge (though it might be out of my sense of > being mildly overwhelmed by the still remaining reading list I already > have of semantic web books, Springer just keeps dropping them like > rain. :-) -- 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: Build tool for mixed Clojure/Java projects
On Mon, 04 Jul 2011 03:14:01 -0400, Konrad Hinsen wrote: AOT compilation: My case is probably a bit complex in this respect. I need AOT compilation only because I want to produce an executable jar, so there is at least one namespace that must be AOT compiled. For building that executable jar, it doesn't matter if everything else is AOT compiled as well. But I want to be able to build a standard library jar with just the Clojure code to make sure it works with future Clojure releases. One solution would be to have two completely different builds, one for the executable jar and one for the library version, but using the same set of source code files. You might be able to use the :impl-ns option in gen-class to limit the extent of AOT compilation. -- Hugo Duncan -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Clojure for large programs
On Jul 4, 1:26 pm, James Keats wrote: > On Jul 4, 5:45 am, Christian Schuhegger > A good > book to get you started would SEMANTIC WEB for the WORKING ONTOLOGIST, > of which a second edition has recently come out. :-) Sorry about the unintentional "to get you started" figure of speech; I note you said you already had rdf/owl in your kit. It's not out of underestimating your knowledge (though it might be out of my sense of being mildly overwhelmed by the still remaining reading list I already have of semantic web books, Springer just keeps dropping them like rain. :-) -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Clojure for large programs
On Jul 4, 5:45 am, Christian Schuhegger wrote: > Thanks for your feed-back. I already have RDF/OWL in my tool-kit. I am > only not sure if an ERP like system should be modeled along those > lines. But I did not put enough thought in that direction yet. Would > you base an ERP like system on top of RDF/OWL? My immediate instinct would suggest you already use an existing one, but I note that you said it was a "toy project". ERP is a problem that's historically been well-suited for prolog and logic programming. Yes, I believe RDF/OWL(/Sparql and semantic web reasoners) is a major advancement in that field and would recommend you look at it. A good book to get you started would SEMANTIC WEB for the WORKING ONTOLOGIST, of which a second edition has recently come 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
Re: Build tool for mixed Clojure/Java projects
> 2) Network independence. I often work without Internet access, and I > don't want to be blocked at some point because some build tool wants > to access some repository to see if my version is still current. For the record, this is easily doable with both Leiningen and Cake (which both use Maven under the hood). One just has to create a ~/.m2/settings.xml with the following content: http://maven.apache.org/SETTINGS/1.0.0"; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0 http://maven.apache.org/xsd/settings-1.0.0.xsd";> true Best, - 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
Re: Build tool for mixed Clojure/Java projects
Hi On 4 July 2011 13:08, Ken Wesson wrote: > On Mon, Jul 4, 2011 at 6:29 AM, Steve wrote: >> On Jul 3, 10:01 pm, Ken Wesson wrote: >>> >>> OK...ridiculous leap reduced to merely huge leap then, if you only >>> have to learn 2 of these three things at once: big, interdependent >>> groups of projects, maven/etc. repository-accessing tools, and server >>> administration. :) >>> >> >> It's really not that hard. If you use Enclojure/Netbeans there are >> wizards for creating maven clojure projects (I assume so for other >> IDEs as well). You create one project, write some code, mvn install. >> Create another one, right click on the dependency folder, add the >> details for the first project and it's ready for you to use. No >> repositories to create or manage, maven handles all that stuff for >> you. > > That's actually a bit worrying. I'm not sure I want a potential > security hole into my computer, such as a repository, being "handled > for me" without having *some* input into the matter. For example if I > intend to use it purely locally I'd want to firewall the port it's > using to make sure it's unreachable from any address other than > 127.0.0.1. "Repository" need not imply anything to do with networking. I'm sure someone will correct me if I'm wrong, but I am pretty sure that the repository Steve is talking about above is just a hierarchy of files in your home directory. -- Michael Wood -- 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: Build tool for mixed Clojure/Java projects
> (ns leiningen.sub > (:use [leiningen.core :only [apply-task task-not-found]])) > > (defn sub [task-name & args] > (doseq [project (projects-in-dir)] > (apply-task task-name project args task-not-found))) > > Implementation of projects-in-dir left as an exercise for the > reader. Shouldn't be more than four lines. Push the lein-subs plugin to > clojars: problem solved in a repeatable, maintainable way. IMHO such a thing can be added to Lein proper as a feature. It's very useful. Maybe with a :sub key in project.clj: :sub ["module/dep-B" "module/dep-D"] Regards, Shantanu -- 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: Build tool for mixed Clojure/Java projects
On Mon, Jul 4, 2011 at 6:29 AM, Steve wrote: > On Jul 3, 10:01 pm, Ken Wesson wrote: >> >> OK...ridiculous leap reduced to merely huge leap then, if you only >> have to learn 2 of these three things at once: big, interdependent >> groups of projects, maven/etc. repository-accessing tools, and server >> administration. :) >> > > It's really not that hard. If you use Enclojure/Netbeans there are > wizards for creating maven clojure projects (I assume so for other > IDEs as well). You create one project, write some code, mvn install. > Create another one, right click on the dependency folder, add the > details for the first project and it's ready for you to use. No > repositories to create or manage, maven handles all that stuff for > you. That's actually a bit worrying. I'm not sure I want a potential security hole into my computer, such as a repository, being "handled for me" without having *some* input into the matter. For example if I intend to use it purely locally I'd want to firewall the port it's using to make sure it's unreachable from any address other than 127.0.0.1. On the one hand, manually managing stuff like that is hard, and it's complex to learn the first time. On the other, making it *too* simple, at least when it has implications for the machine's security, is not generally a good thing. > I wouldn't normally defend maven, but there are some things it does > well and for this sort of simple "local Project A depends on local > Project B" stuff it's a no-brainer (esp. when the IDEs do most of the > config creation work). There's also the fact that everything remains simple (maybe too simple; see above) only so long as you remain inside the cushioned box of the particular IDE. As soon as you try to do anything else -- tweak something from vi or Notepad, significantly refactor and rename and restructure stuff in a manner that changes some file paths, move to or sync with another machine, share with a collaborator, even just find the source files to back them up somewhere safe -- you're in the deep woods, possibly without a good map. :) -- Protege: What is this seething mass of parentheses?! Master: Your father's Lisp REPL. This is the language of a true hacker. Not as clumsy or random as C++; a language for a more civilized age. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: iterate?
=> (= (repeat 100 :foo) (take 100 (iterate identity :foo))) true hth, Christophe On Mon, Jul 4, 2011 at 12:39 PM, Antonio Recio wrote: > Do you know how to solve this? > > (= (repeat 100 :foo) > (take 100 (iterate ___ :foo))) > > -- > 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 -- Professional: http://cgrand.net/ (fr) On Clojure: http://clj-me.cgrand.net/ (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
iterate?
Do you know how to solve this? (= (repeat 100 :foo) (take 100 (iterate ___ :foo))) -- 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: Build tool for mixed Clojure/Java projects
On Jul 3, 10:01 pm, Ken Wesson wrote: > > OK...ridiculous leap reduced to merely huge leap then, if you only > have to learn 2 of these three things at once: big, interdependent > groups of projects, maven/etc. repository-accessing tools, and server > administration. :) > It's really not that hard. If you use Enclojure/Netbeans there are wizards for creating maven clojure projects (I assume so for other IDEs as well). You create one project, write some code, mvn install. Create another one, right click on the dependency folder, add the details for the first project and it's ready for you to use. No repositories to create or manage, maven handles all that stuff for you. I wouldn't normally defend maven, but there are some things it does well and for this sort of simple "local Project A depends on local Project B" stuff it's a no-brainer (esp. when the IDEs do most of the config creation work). - 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
Re: Clojure for large programs
On Sat, Jul 2, 2011 at 8:19 PM, Luc Prefontaine wrote: > Were did you find the link between functional languages and close proximity of > errors ? That's a language design decision. You may want to use assertions > on your fns to validate inputs. That sould improve your ability to track > errors > before they carry things too far from the spotwhere it failed. > I would not trade this for systematic exception reporting. Sorry if I wasn't clear about this. One time I was rereading a book about the art of debugging (I think it was this book: http://www.amazon.com/Why-Programs-Fail-Second-Systematic/dp/0123745152), and realized that the main theme of the book is that the #1 reason that debugging is hard is that most bugs result from some sort of mutation of state in one part of your code that inadvertently violates some assumption or invariant you had in your mind. But your program doesn't crash right away, it keeps quietly chugging along with that corrupted state until some completely separate portion of your program tries to do something with that data that no longer makes sense and KA-BOOM. But the line your debugger shows you just shows you where the crash happened; it can't show you the series of steps that led to the corruption of state that actually caused the crash. Thus, you need to do a lot of detective work and step through the program. This is precisely why, for example, most programmers will gladly pay the performance penalty for bounds-checking on array reads and writes -- it's incredibly valuable to have your program crash where the problem actually occurs, rather than continuing for a while with spurious values or corrupted memory and getting a delayed crash with no clear connection to the cause. I had a personal a-ha moment when I read that, which made me realize that one of the reasons I enjoy functional programming so much more is that this class of bug just doesn't happen. Generally speaking, crashes have good locality with respect to the flaw in the code that causes them because there's no "state" to get corrupted and eventually cause a delayed crash. Of course, often the hardest bugs of all to find are the ones that are the result of deep logical flaws. The program may be an exact implementation of what you had in mind, but what you had in mind doesn't quite accomplish what you expected it to. And that's the problem I have with some of Clojure's core functions -- they can turn a blatant mismatch (between a function's input requirements and the inputs that actually get passed) into a deep logical flaw. The get example I raised is a perfect example of this. When I passed a transient set to a function that used get, I reasonably assumed that transient sets implement whatever interface get requires. But rather than raise an error because the object didn't support the desired interface, get just returned nil -- which is the exact same value that is returned in ordinary usage when you test whether something is in the set and it isn't! So now, I have sets that are quietly being passed around, and returning sensible values but behaving as if they don't have any elements. What should be an easy bug has turned into a deep logical flaw in my program. Everything appears to be working, but my program generates completely bogus outputs because at some stage of its processing it tested for membership in a set and got back nil for something that was actually in the set. This is the kind of thing that is a real nuisance to track down, requiring detailed detective work and a careful analysis of the entire chain of logic to find the spot where things actually go wrong. Given that get creates the illusion of working even when it doesn't, I fail to see how a pre or post condition in my own code could have picked up on this or validated the input, short of having a deep understanding of all the interfaces required by every core function and testing every input explicitly for support of those interfaces (in which case, I might as well be using a statically typed language). -- 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: Build tool for mixed Clojure/Java projects
On Mon, Jul 4, 2011 at 3:14 AM, Konrad Hinsen wrote: > AOT compilation: My case is probably a bit complex in this respect. I need > AOT compilation only because I want to produce an executable jar, so there > is at least one namespace that must be AOT compiled. For building that > executable jar, it doesn't matter if everything else is AOT compiled as > well. But I want to be able to build a standard library jar with just the > Clojure code to make sure it works with future Clojure releases. One > solution would be to have two completely different builds, one for the > executable jar and one for the library version, but using the same set of > source code files. You seem to want to make two things: a library and an application. For that, I think it's only proper if you have two build scripts, since you have two build artifacts. Indeed, the application may be better off depending on the library than directly incorporating its source code as some of its own. >> For the record, leiningen can do this by adding a repository with a >> file:/// URL; it's just not documented because I think it's a bad idea. > > With absolute filenames in a URL, it's indeed a bad idea because the project > becomes specific to a machine/installation. What I'd like to see instead is > a project-local repository, e.g. a "deps" folder with jar files and source > code directories. > > There are several reasons why I want dependencies outside of repositories: > > 1) Simplicity. I want to distribute a single tar file to collaborators (who > are new to Clojure and the JVM world) containing all dependencies and build > scripts. I want to tell them "install , take this file, > play with the source code, and just type to build an > executable". They will struggle with a new language and a new environment > already, there's no need to add the complexities of repositories. This is what I meant about avoiding unnecessary ceremony. > To make it worse, we all live behind proxies that require messy configuration > for tools like Maven. > > 2) Network independence. I often work without Internet access, and I don't > want to be blocked at some point because some build tool wants to access > some repository to see if my version is still current. The above provide some reasons why the build process should not *require* an internet connection if all dependencies are already available locally. I don't have a problem if some build tool checks for updates, so long as it treats a failed check the same as finding there's no update, give or take a non-fatal warning or two. On the other hand, the result on actually finding an update should probably be a user prompt in interactive mode and a build without the update in batch mode. Otherwise the update, if it breaks backward compatibility, could break the build. A build that worked yesterday and breaks today without one having changed any local files, neither the build script nor the sources nor anything else, is going to be a head-scratcher to deal with, and in many contexts time is money. > 3) Confidentiality. Sometimes I work with unpublished code that I promised > not to give to anyone else. I can't keep that promise if the code leaves my > machine in any way. For that case, the file:/// repository would of course > be fine. Presumably also for network-independence and avoiding annoying proxies. But if it needs an absolute path, that may* break the "just tar up the source tree and mail it to someone" capability and forces even small collaborative projects to set up and use some kind of code repository instead. As I've argued elsewhere, repository use scales poorly at the small-project end, unsurprisingly since repositories were specifically invented as a tool to make large-scale projects with huge numbers of collaborators and vast reams of code manageable. Using a high-falutin' version control system for 12kloc and three developers is like using a bazooka to swat a fly, a top-of-the-line Oracle database product on expensive iron to track your personal expenses and balance your checkbook, or hashmaps instead of arraymaps to store little three-key objects that number in the tens of thousands. :) * Unix filesystems seem to be standardized enough in layout that using absolute paths of \usr\src\whatever and suchlike may be viable. Except that it won't work for a collaborator whose machine runs Windows, and, worse, it requires working as root or else letting unprivileged users create executables in world-readable places -- ick. > I'd prefer one build system to two separate layers, one of which I'd write > myself. Moreover, most of my dependencies are not projects, but simply jar > files picked up from various sources. Indeed, Maven-based stuff seems oriented around the assumption that any third-party dependencies you will have, in particular, will generally be publicly hosted on Maven repositories themselves rather than just a ten-cent web site or Blogspot article or Facebook page with a .jar download
Re: Build tool for mixed Clojure/Java projects
Hi,
Am Montag, 4. Juli 2011 09:14:01 UTC+2 schrieb konrad...@laposte.net:
> Thanks for everyone's suggestions and comments!
>
> Some remarks:
>
> Gradle/clojuresque: I never tried them, but it looks like I should!
>
> AOT compilation: My case is probably a bit complex in this respect. I
> need AOT compilation only because I want to produce an executable jar,
> so there is at least one namespace that must be AOT compiled. For
> building that executable jar, it doesn't matter if everything else is
> AOT compiled as well. But I want to be able to build a standard
> library jar with just the Clojure code to make sure it works with
> future Clojure releases. One solution would be to have two completely
> different builds, one for the executable jar and one for the library
> version, but using the same set of source code files.
I would do it like this:
Split the source in two parts: the library part and the application
part. This would help to maintain a clean library API, because you
could use your application as “real” customer. You could build both
parts independently if desired and so on.
On the other hand this is not a requirement. You could just as well
have everything in one tree and create two jars from it. But my
gradle-fu is too limited to suggest a quick solution for that way.
First the former way the source layout would be something like this:
root directory of the project
│
├─ build.gradle (see below)
│
├─ lib
│ │
│ ├─ build (clojuresque, other stuff needed for buildscript)
│ │
│ └─ runtime (your dependencies go here)
│
├─ library (library subproject)
│
└─ app (application subproject)
You need only the following central build.gradle. It will build a
normal library jar for the library subproject and a AOT-compiled
jar for the application.
buildscript {
repositories { flatDir dirs: project.file('lib/build') }
dependencies { classpath "clojuresque:clojuresque:1.4.1" }
}
subprojects {
apply plugin: "java"
apply plugin: "clojure"
group = "yourGroupGoesHere"
version = "some.version.number"
repositories {
flatDir dirs: project(':').file('lib/runtime').absoluteFile
}
dependencies {
compile "org.clojure:clojure:1.2.1"
}
}
project(':library') {
dependencies {
compile "some.other:library:1.2.3"
compile "and.another:one:3.2.1"
}
}
project(':app') {
aotCompile = true
// If you want a fat jar with all dependencies included...
uberjar.enabled = true
configurations.compile.transitive = true
dependencies {
compile project(':library')
}
// more stuff here for main class definition etc.
}
Although not completely working out of the box this should give
you a feeling of how things would look like with gradle. So you
can hopefully quickly evaluate whether it is worth a look at all.
I'm open for any support request to get you going with clojuresque.
Mail me or put the discussions on the newly created google
group: http://groups.google.com/group/clojuresque.
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: Build tool for mixed Clojure/Java projects
FYI, here is how to add jar deps in gradle for local files, either as a file or a dir of files http://stackoverflow.com/questions/2572811/gradle-make-a-3rd-party-jar-available-to-local-gradle-repository and getting started is at https://bitbucket.org/kotarak/clojuresque/wiki/Home while the tutorial is written for gradle 1.0.x milestone releases. I use gradle 0.9.2, and it works fine for me. On Mon, Jul 4, 2011 at 3:14 AM, Konrad Hinsen wrote: > 1) Simplicity. I want to distribute a single tar file to collaborators (who > are new to Clojure and the JVM world) containing all dependencies and build > scripts. I want to tell them "install , take this file, > play with the source code, and just type to build an > executable". They will struggle with a new language and a new environment > already, there's no need to add the complexities of repositories. To make it > worse, we all live behind proxies that require messy configuration for tools > like Maven. -- Omnem crede diem tibi diluxisse supremum. -- 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: Build tool for mixed Clojure/Java projects
On 3 Jul 2011, at 21:57, Konrad Hinsen wrote: I am looking for a build tool that fulfills the following requirements: 1) Must handle Clojure namespaces that are AOT-compiled. 2) Must handle Clojure namespaces that are not AOT-compiled. 3) Must handle Java source code files. 4) Must handle dependencies in the form of on-disk jar files (not in any repository) 5) No XML configuration files. Thanks for everyone's suggestions and comments! Some remarks: Gradle/clojuresque: I never tried them, but it looks like I should! AOT compilation: My case is probably a bit complex in this respect. I need AOT compilation only because I want to produce an executable jar, so there is at least one namespace that must be AOT compiled. For building that executable jar, it doesn't matter if everything else is AOT compiled as well. But I want to be able to build a standard library jar with just the Clojure code to make sure it works with future Clojure releases. One solution would be to have two completely different builds, one for the executable jar and one for the library version, but using the same set of source code files. On 4 Jul 2011, at 00:06, Phil Hagelberg wrote: 4) Must handle dependencies in the form of on-disk jar files (not in any repository) For the record, leiningen can do this by adding a repository with a file:/// URL; it's just not documented because I think it's a bad idea. With absolute filenames in a URL, it's indeed a bad idea because the project becomes specific to a machine/installation. What I'd like to see instead is a project-local repository, e.g. a "deps" folder with jar files and source code directories. There are several reasons why I want dependencies outside of repositories: 1) Simplicity. I want to distribute a single tar file to collaborators (who are new to Clojure and the JVM world) containing all dependencies and build scripts. I want to tell them "install , take this file, play with the source code, and just type command> to build an executable". They will struggle with a new language and a new environment already, there's no need to add the complexities of repositories. To make it worse, we all live behind proxies that require messy configuration for tools like Maven. 2) Network independence. I often work without Internet access, and I don't want to be blocked at some point because some build tool wants to access some repository to see if my version is still current. 3) Confidentiality. Sometimes I work with unpublished code that I promised not to give to anyone else. I can't keep that promise if the code leaves my machine in any way. For that case, the file:/// repository would of course be fine. On 4 Jul 2011, at 01:30, Anthony Grimes wrote: Cake can indeed handle Java source files. Throw them in src/jvm, I believe. Leiningen and cake can both handle on-disk jar files, but (at least in cakes case) they need to be installed in the local repository. Having used cake in the past for simpler projects, I know that it can handle project-local dependencies. Just add a classpath setting to .cake/config (I'd have to look up the exact name of that variable). If cake can indeed handle Java code, then it might be just fine for my needs. On 4 Jul 2011, at 03:29, Mark Derricutt wrote: The other option is Polyglot Maven, which hasn't really seen much movement lately, but gives you maven power without the XML ( clojure source, yaml, etc. ) http://polyglot.sonatype.org/clojure.html Being Maven, this would still require repositories, right? Even a local Maven repository is more than I'd like to impose on my collaborators. On 4 Jul 2011, at 07:16, Shantanu Kumar wrote: Maven works, but if you don't want XML why not just use Leiningen? Split your code base into various modules (each module having its own project.clj) and have a shell script (or PowerShell script if you're on Windows) to take care of the dependencies while building across modules. I'd prefer one build system to two separate layers, one of which I'd write myself. Moreover, most of my dependencies are not projects, but simply jar files picked up from various sources. Thanks again to everyone! I'll look at Java with cake, and also at Gradle. Konrad. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Unknown constant tag 32 in class file error
Hi all, Since I started using Clojure (I think from just before 1.0) I have, on the odd occasion, received an error message of this form (Unknown constant tag X in class file error) while trying to evaluate a namespace in Slime/Emacs. Whenever it cropped up, it was completely random: it never seemed to have any specific relation to something I'd done in the code. Sometimes it'd get triggered by an arbitrary change like renaming a variable or deleting a comment or unused function. In all cases, recompiling the project from scratch would get past the issue. I'd always figured it was some random quirk of the compiler. Since it didn't happen often and could be fixed by a recompile, I just let it be. Today though, I've started running into this error more persistently. It'll start appearing consistently -right- after a recompile. I.e.: I'll compile the project, then try re-evaluate a namespace that was just compiled (no changes to the code) and it'll throw the error. There hasn't been any change to the code in this file and the other recent changes are all superficial and syntactically correct (proved also by the fact that the source is compiling successfully). I'm using Clojure 1.2.0. The best info I could find on this error is here, from 2009: http://www.mail-archive.com/clojure@googlegroups.com/msg19130.html. I don't have any familiarity with Clojure's compiler (or Java or the JVM) so am a little clueless as to where I'd begin trying to get past the problem. Any rough idea what might be going on? Am I possibly bumping into a Clojure/Java/JVM limitation somewhere? Could this be a Slime/Swank issue? The project's about 21,000 LOC right now, including lots of comments. This is split into about 40 namespaces/files. Kind of in the middle of a product launch right now, so the timing's a little bit unfortunate: would really appreciate any advice! Thank you! The full stack trace is below: Unknown constant tag 32 in class file wusoup/web/responses/profiles $eval7347 [Thrown class java.lang.ClassFormatError] Restarts: 0: [QUIT] Quit to the SLIME top level Backtrace: 0: java.lang.ClassLoader.defineClass1(Native Method) 1: java.lang.ClassLoader.defineClass(ClassLoader.java:634) 2: java.lang.ClassLoader.defineClass(ClassLoader.java:480) 3: clojure.lang.DynamicClassLoader.defineClass(DynamicClassLoader.java: 45) 4: clojure.lang.Compiler$ObjExpr.getCompiledClass(Compiler.java: 3964) 5: clojure.lang.Compiler$FnExpr.parse(Compiler.java:3219) 6: clojure.lang.Compiler.analyzeSeq(Compiler.java:5367) 7: clojure.lang.Compiler.analyze(Compiler.java:5190) 8: clojure.lang.Compiler.eval(Compiler.java:5421) 9: clojure.lang.Compiler.eval(Compiler.java:5391) 10: clojure.core$eval.invoke(core.clj:2382) 11: swank.core$eval_in_emacs_package.invoke(core.clj:94) 12: swank.core$eval_for_emacs.invoke(core.clj:241) 13: clojure.lang.Var.invoke(Var.java:373) 14: clojure.lang.AFn.applyToHelper(AFn.java:169) 15: clojure.lang.Var.applyTo(Var.java:482) 16: clojure.core$apply.invoke(core.clj:540) 17: swank.core$eval_from_control.invoke(core.clj:101) 18: swank.core$spawn_worker_thread$fn__465$fn__466.invoke(core.clj: 300) 19: clojure.lang.AFn.applyToHelper(AFn.java:159) 20: clojure.lang.AFn.applyTo(AFn.java:151) 21: clojure.core$apply.invoke(core.clj:540) 22: swank.core$spawn_worker_thread$fn__465.doInvoke(core.clj:296) 23: clojure.lang.RestFn.invoke(RestFn.java:398) 24: clojure.lang.AFn.run(AFn.java:24) 25: java.lang.Thread.run(Thread.java:636) -- 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
