Re: Idiomatic Clojure namespace names
On Jul 10, 12:16 am, Mike Meyer mwm-keyword-googlegroups. 620...@mired.org wrote: On Fri, 9 Jul 2010 12:49:05 -0700 (PDT) j-g-faustus johannes.fries...@gmail.com wrote: That said, I would leap at a chance to shorten Java names, even if it were just to chop off the leading com or org. As the owner of mired.org, but not of mired.com (and I don't know the registered owner) or .net, or of that domain in any other TLD, I'd have to call that the worst suggestion so far. But the chances of mired.com bringing out a library called 'proclog' are insignificant. As mentioned before in this discussion, TLDs change owners anyway so the TLD convention can't be used to definitively identify an owner. The aim of the convention is to reduce the chances of library names clashing. As another suggestion how about clj.handle.library e.g clj.mired.proclog clj.weavejester.compojure clj.acme-corp.dynamite This separates the clojure namespace from the java one, doesn't tie to a TLD and reduces the chances of collisions at the library level. Also, somebody mentioned dropping api/core from the core namespace in a library. Personally, I'd be happy with that. Saul -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Idiomatic Clojure namespace names
On 9 July 2010 17:46, Paul Moore p.f.mo...@gmail.com wrote: Is there any benefit to using a name like foo.core (or foo.api) rather than simply foo (beyond sytlistic considerations, that is)? Clojure compiles foo to a package-less class called foo. foo.ciore is compiled to a class called core in the package foo. Package-less classes are a bit problematic if you want to call them from another Java package, IIRC. But if your library isn't intended to be AOT-compiled and used from Java, I don't think it makes a difference. - 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: Idiomatic Clojure namespace names
Hello Laurent, Am 09.07.2010 um 18:30 schrieb Laurent PETIT: But still I prefer to have the library name at the end of the namespace, it's easier to spot than in the middle (e.g. I prefer net.cgrand.parsley to paredit.core) Now that is a strange argument. net.cgrand.parsley vs. parsley.api. Why should at the end be easier to spot than at the beginning? In particular because parsley.api just contains relevant information while net.cgrand.parsley contains quite a bit of noise. I consider the origin to be noise in the code. Of course it is a fact with some weight when evaluating a library whether it was written by Christophe. But in the code this is completely of no relevance. 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: Idiomatic Clojure namespace names
2010/7/10 Meikel Brandmeyer m...@kotka.de Hello Laurent, Am 09.07.2010 um 18:30 schrieb Laurent PETIT: But still I prefer to have the library name at the end of the namespace, it's easier to spot than in the middle (e.g. I prefer net.cgrand.parsley to paredit.core) Now that is a strange argument. net.cgrand.parsley vs. parsley.api. Why should at the end be easier to spot than at the beginning? In particular because parsley.api just contains relevant information while net.cgrand.parsley contains quite a bit of noise. I consider the origin to be noise in the code. Of course it is a fact with some weight when evaluating a library whether it was written by Christophe. But in the code this is completely of no relevance. I'm not talking about what the prefix should be. I didn't compare it to the most relevant part of the name being in the first segment, but in the middle ^^^ -- 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: ClojureDocs.org
Hi Zack, first of all, great effort there :) having a place for clojure docs is awesome. Two things come to mind: 1) http://github.com/defn/walton - have a look at it, it might be a good way to fetch examples for functions where none are provided yet. 2) Will it be possible to put other 3rd party libs on there - since I'd like to add some of mine, it's likely better to have them documented centrally then keeping a own documentation for each library. :) Regards, Heinz -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Idiomatic Clojure namespace names
Saul Hazledine shaz...@gmail.com wrote: On Jul 10, 12:16 am, Mike Meyer mwm-keyword-googlegroups. 620...@mired.org wrote: On Fri, 9 Jul 2010 12:49:05 -0700 (PDT) j-g-faustus johannes.fries...@gmail.com wrote: That said, I would leap at a chance to shorten Java names, even if it were just to chop off the leading com or org. As the owner of mired.org, but not of mired.com (and I don't know the registered owner) or .net, or of that domain in any other TLD, I'd have to call that the worst suggestion so far. But the chances of mired.com bringing out a library called 'proclog' are insignificant. As mentioned before in this discussion, TLDs change owners anyway so the TLD convention can't be used to definitively identify an owner. The aim of the convention is to reduce the chances of library names clashing. Considering that there's already another proclog project, I'm not so sure. But the objection is more that I'd rather use the extra level than share the namespace I'm paying for anyway. As another suggestion how about clj.handle.library e.g clj.mired.proclog clj.weavejester.compojure clj.acme-corp.dynamite Why should I prefer clj.mired, shared with gods knows who over org.mired, shared with nobody? This separates the clojure namespace from the java one, doesn't tie to a TLD and reduces the chances of collisions at the library level. I'd say we should avoid TLAs for the TLD, given the IETFs preference for them. Given a clojure registry of some sort, just use clojure and share everything else: clojure.proclog clojure.compojure clojure.dynamite Or to be really beep-beep about it, I could probably arrange to get com.acme.clj and we could use that as the prefix for things in the registry. Also, somebody mentioned dropping api/core from the core namespace in a library. Personally, I'd be happy with that. Sounds like one of the things that comes from Javas class/file requirement. I've got no problem with ignoring that. -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -- 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: ClojureDocs.org
This is great. One suggestion -- consider providing a downloadable bundle for offline use as well. Regards, Shantanu On Jul 10, 2:11 pm, Heinz N. Gies he...@licenser.net wrote: Hi Zack, first of all, great effort there :) having a place for clojure docs is awesome. Two things come to mind: 1)http://github.com/defn/walton- have a look at it, it might be a good way to fetch examples for functions where none are provided yet. 2) Will it be possible to put other 3rd party libs on there - since I'd like to add some of mine, it's likely better to have them documented centrally then keeping a own documentation for each library. :) Regards, Heinz -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Idiomatic Clojure namespace names
On Jul 9, 6:22 pm, Mike Meyer mwm-keyword-googlegroups. 620...@mired.org wrote: How have you managed to miss the second half of that's the way they do it in Java, which is and we need to interoperate with other JVM languages. Like it or not, one of the biggest draws of Clojure is that it interoperates with Java. Nothing about what I said precludes interoperability with Java. In fact I specifically chose to use the two part namespace because it allows for AOT compilation, and thus access from other JVM languages. I find the whole foo.core thing unfortunate too, because it would otherwise be nicer to just (:use foo). In my own projects I've adopted this style though, with the idea that I would like my code to be usable from other JVM languages in the future. For some people, like and future aren't acceptable options. It has to be usable from other JVM languages now. Not sure how realistic or plausible that really is... It's not really either. At the very least, you need to use a top-level namespace that sets clojure code apart from the other JVM languages (and then expect projects for which cross-language usage is important to do it the Java way anyway). I still suggest clojure for that. Using a two part namespace does enable access from other JVM languages, NOW, so yes it is plausible and realistic. I just don't see myself or many other people use Clojure libraries from outside Clojure yet, which is why I stated it the way that I did. You are spamming the list with arguments for these completely.useless.names.for.libraries.that.google.will.find.before.you.finish.typing.the.package.name, yet there are plenty of proofs by existence that this kind of scheme is not necessary to have a successful language or library community. The whole world is not going to write Clojure, and we don't need to prepare for it. This is the kind of enterprisey Java think that results in everything requiring copious amounts of configuration rather than just working the simple way by default. I also disagree with this concept of putting the language in the package name. One of the benefits of compiling down to a common runtime is that we don't need to care what language something was written in. I think this kind of meta-data, along with the domain of the project, authors, etc., should be associated with the Jar file if anything, but not splatted on the top of every piece of code that uses a library. The issue of changing domain names when using the domain as package name is much worse than only the maintainer having to do a multi-file search and replace. It means that every user of the library who wants to upgrade to the latest version also has to go through their code renaming packages. This all gets much more complicated and messy when you incorporate dependency injection, reflection and other forms of dynamic code where a simple search and replace might not do it. Renaming packages is really annoying, and another of many reasons not to include domains in package names. Another annoyance with these loquacious.package.names is that they require your source to be stuffed away in a column of useless directories. Even in an IDE they are annoying because in order to see the information containing components (right most) of package names you have to have a really wide package manager panel or deal with side scrolling. Every time I'm back in Java these things annoy me. Luckily for us, I think the tide is already rising on this conversation. Most prominent Clojure libraries are adopting the same packaging scheme as clojure.core, and we are uploading our libraries to the wild and crazy, totally uncensored and unmonitored clojars.org, which is working out great in tandem with lein. Clojars wasn't a failed experiment, it's the future. -Jeff -- 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: clj-sandbox
Now version 0.4.0 is out, it fixes a evil bug that had problems with forms like (. obj (meth arg)) and also introduces a pretty cool new feature: It allows a somewhat save use of def and defn, this is by far not perfect sadly but it is a step towards the direction of having a sandbox that allows to keep state without fear of memory overflows - sadly something java does not allow easily. Regards, Heinz -- 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: Recent builds have failed on http://build.clojure.org
I think it is because the last commit of the master branch is on June 24, 2010: http://github.com/richhickey/clojure/commits/master On Jul 10, 12:24 pm, Dmitry Kakurin dmitry.kaku...@gmail.com wrote: The last successful build was on June 23rd. - Dmitry -- 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: ClojureDocs.org
This is GREAT!!! I love the way you have opened it up for community participation. Robert On Jul 9, 4:32 am, zkim zachary@gmail.com wrote: Hi All, I'll try to keep this short. I've gotten a lot out of Clojure: I can honestly say that learning this language, and being part of this community has made me a better, happier developer, and I wanted to give something back. One of the pain points that I encountered when learning the language was a lack of examples specific to the individual functions I was trying to wrap my head around at any given time. So I took a whack at the problem, and came up withhttp://clojuredocs.org. It's a site that (I'm hoping) will fill this need by providing a centralized examples database, along with solid search capabilities across both core and third party libraries (core being the focus). Implementation: ClojureDocs.org is a rails site backed by MySQL, along with some clojure code to pull the namespaces / metadata / source and dump them into the database. Highlights: 1. Documentation and source for Clojure core, contrib, and a few third party libraries (random selection out of what I'm personally familiar with, and whatever was on the github trends page that day). 2. Search for a var across the whole ecosystem or in a specific library. 3. Per var wiki-style examples section. 4. Per var comments section. 5. Per var vars-in-this-var and this-var-used-in section (my personal favorite). Looking for a real-world example of a specific function? This is for you. For example,http://clojuredocs.org/v/1978, just below the source section. Lowlights: 1. Ugly URLs! There's a problem in the way that URLs with encoded question marks are being handled, so I had to move fromhttp://clojuredocs.org/clj-ssh/clj-ssh.core/file-pathtohttp://clojuredocs.org/v/1484. I've got an email out to the Phusion Passenger mailing list (http://groups.google.com/group/phusion- passenger/browse_thread/thread/ed2eadfdac5c166f) but if you've got any experience in this area drop me a line. 2. Strange var names (http://clojuredocs.org/v/781). Probably a bug in the import process. 3. General rough-around-the-edges-ness. I'm treating this as an alpha, and I'd really like feedback as to: a. How useful this would be to the community. b. Specific likes / dislikes about this alpha release. c. Feature requests. I've set up a feedback mechanism directly through the site (User Voice), which allows voting on specific posts. I'm also considering setting up a google group for general discussion. Feel free to contact me directly through email. Questions / thoughts? -Zack -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Idiomatic Clojure namespace names
On 10 July 2010 09:06, James Reeves jree...@weavejester.com wrote: On 9 July 2010 17:46, Paul Moore p.f.mo...@gmail.com wrote: Is there any benefit to using a name like foo.core (or foo.api) rather than simply foo (beyond sytlistic considerations, that is)? Clojure compiles foo to a package-less class called foo. foo.ciore is compiled to a class called core in the package foo. Package-less classes are a bit problematic if you want to call them from another Java package, IIRC. But if your library isn't intended to be AOT-compiled and used from Java, I don't think it makes a difference. Ah! I hadn't realised the package/class distinction - a result of my having no Java background. Thanks for the explanation, I can now understand the trade-offs better. Paul -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Recent builds have failed on http://build.clojure.org
You are looking at the wrong build box. The master branch is at http://github.com/clojure/clojure, now that GitHub offers organization support. The current build.clojure.org is about to be replaced. We have a new build box that we should be pointing the DNS to, hopefully this weekend. Stu I think it is because the last commit of the master branch is on June 24, 2010: http://github.com/richhickey/clojure/commits/master On Jul 10, 12:24 pm, Dmitry Kakurin dmitry.kaku...@gmail.com wrote: The last successful build was on June 23rd. - Dmitry -- 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: ClojureDocs.org
On 9 July 2010 21:06, Tom Faulhaber tomfaulha...@gmail.com wrote: Quick thought: You probably don't want to include private vars. Seconded. It's a little confusing seeing private vars and macros in the API docs! Other than that, this looks excellent. I'm signing up as I write this. - 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: ClojureDocs.org
Very cool. Let me start by saying thanks to everyone who has been involved in the various threads on improving documentation, especially those who, like Zack, have taken substantial action. Here are a bunch of ideas, in no particular order: (1) Ease of contribution is huge, and http://clojuredocs.org looks good on this front. Stick to it. (2) +1 on hiding private APIs. We use private APIs carefully and deliberately in Clojure, and I would hate to facilitate people writing code that will break later. (3) +1 on making it very easy to see which version of an API you are looking at. This should be both at the top level (some way to say show me 1.1) and on a per-var basis, reading the :added metadata. (4) Provenance matters. Clojure itself is very careful to have people sign a CA before contributing code. The bar may be somewhat different for a documentation site, but it still needs to be carefully considered. (5) Continuity matters. We have already had some pain with useful resources popping up on the web and then having the maintainer go AWOL with no succession plan. There are several steps any documentation site should take to address this: (a) open sourcing everything (b) including multiple committers and admins on the site itself and (c) providing an easy API to suck the data out. (6) Because docstrings are designed for consumption at a REPL, they may in some cases presume a fixed font. Worth considering for display on the site. (7) Quality matters. There are multiple possible ways to make sure that the cream rises: letting people up and downvote, making it easy for editors to track new submissions, etc. Thanks again! Stu Hi All, I'll try to keep this short. I've gotten a lot out of Clojure: I can honestly say that learning this language, and being part of this community has made me a better, happier developer, and I wanted to give something back. One of the pain points that I encountered when learning the language was a lack of examples specific to the individual functions I was trying to wrap my head around at any given time. So I took a whack at the problem, and came up with http://clojuredocs.org. It's a site that (I'm hoping) will fill this need by providing a centralized examples database, along with solid search capabilities across both core and third party libraries (core being the focus). Implementation: ClojureDocs.org is a rails site backed by MySQL, along with some clojure code to pull the namespaces / metadata / source and dump them into the database. Highlights: 1. Documentation and source for Clojure core, contrib, and a few third party libraries (random selection out of what I'm personally familiar with, and whatever was on the github trends page that day). 2. Search for a var across the whole ecosystem or in a specific library. 3. Per var wiki-style examples section. 4. Per var comments section. 5. Per var vars-in-this-var and this-var-used-in section (my personal favorite). Looking for a real-world example of a specific function? This is for you. For example, http://clojuredocs.org/v/1978, just below the source section. Lowlights: 1. Ugly URLs! There's a problem in the way that URLs with encoded question marks are being handled, so I had to move from http://clojuredocs.org/clj-ssh/clj-ssh.core/file-path to http://clojuredocs.org/v/1484. I've got an email out to the Phusion Passenger mailing list (http://groups.google.com/group/phusion- passenger/browse_thread/thread/ed2eadfdac5c166f) but if you've got any experience in this area drop me a line. 2. Strange var names (http://clojuredocs.org/v/781). Probably a bug in the import process. 3. General rough-around-the-edges-ness. I'm treating this as an alpha, and I'd really like feedback as to: a. How useful this would be to the community. b. Specific likes / dislikes about this alpha release. c. Feature requests. I've set up a feedback mechanism directly through the site (User Voice), which allows voting on specific posts. I'm also considering setting up a google group for general discussion. Feel free to contact me directly through email. Questions / thoughts? -Zack -- 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,
Re: Idiomatic Clojure namespace names
On Sat, Jul 10, 2010 at 12:06 PM, Saul Hazledine shaz...@gmail.com wrote: As another suggestion how about clj.handle.library e.g clj.mired.proclog clj.weavejester.compojure clj.acme-corp.dynamite +1 martin -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Idiomatic Clojure namespace names
On Sat, Jul 10, 2010 at 2:56 PM, Mike Meyer mwm-keyword-googlegroups.620...@mired.org wrote: As another suggestion how about clj.handle.library e.g clj.mired.proclog clj.weavejester.compojure clj.acme-corp.dynamite Why should I prefer clj.mired, shared with gods knows who over org.mired, shared with nobody? You wouldn't; someone without his own domain, or who didn't want to tie his project namespace to his domain, might. martin -- 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: Databases for a Concurrent World
On Fri, Jul 9, 2010 at 11:08 PM, tbatchelli tbatche...@gmail.com wrote: Hi David, Out of curiosity, how are these tests connecting to the database, especially in the cases of MongoDB and CouchDB? In the case of CouchDB you're clearly using HTTP in a way that it creates one connection per request, I believe. In the case of MongoDB, the driver provides a connection pool (default of 10) and these connections are kept alive and reused between requests. You might be comparing the difference between making one connection per request vs. pipelining many request over an already established connection... Toni. One big problem with the PostgreSQL and MySQL numbers is that they don't use pooling. I found a simple example of adding that to the PostgreSQL code and done so, though I'm still hunting for a MySQL example :P As far as CouchDB I'm using Richard Newman's nice clj-apache-http library which is a wrapper around Apache HTTP Client. It reuses connections by default. However Iooking into this some more, the connections might still be the bottleneck - I'm looking into using multithreaded client connection manager. Will be interesting to see what numbers come up after that. If the whole premise of the blog post turns out to be flawed at least we have a page documenting the basics of how to use Clojure with several dbs ;) 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: Databases for a Concurrent World
I think what you're doing is great. I understand you're using ab for these tests, right? What are the actual settings that you are using? Also, I'd like to mention that what these tests are showing is the behavior of the server under constant load (constant frequency in the arrival times of the requests, and constant load attached to each request). This is not what happens in reality though, and servers that do well under a constant distribution of requests might not do that well (at all) under a Pareto distribution of both arrival times and load (a real load that a server gets is very similar to a Pareto http://en.wikipedia.org/wiki/Pareto_distribution). Under a Pareto load a well crafted event-based server that has bounds on the number of threads used (and maybe other resources) might significantly outperform a 1-thread-per-request server. Unfortunately, I don't think ab can test these scenarios. I built a tool sometime ago while working at UCSB that would do exactly this. I will look into whether I can dig it out and opensource it. Toni. On Sat, Jul 10, 2010 at 8:59 AM, David Nolen dnolen.li...@gmail.com wrote: On Fri, Jul 9, 2010 at 11:08 PM, tbatchelli tbatche...@gmail.com wrote: Hi David, Out of curiosity, how are these tests connecting to the database, especially in the cases of MongoDB and CouchDB? In the case of CouchDB you're clearly using HTTP in a way that it creates one connection per request, I believe. In the case of MongoDB, the driver provides a connection pool (default of 10) and these connections are kept alive and reused between requests. You might be comparing the difference between making one connection per request vs. pipelining many request over an already established connection... Toni. One big problem with the PostgreSQL and MySQL numbers is that they don't use pooling. I found a simple example of adding that to the PostgreSQL code and done so, though I'm still hunting for a MySQL example :P As far as CouchDB I'm using Richard Newman's nice clj-apache-http library which is a wrapper around Apache HTTP Client. It reuses connections by default. However Iooking into this some more, the connections might still be the bottleneck - I'm looking into using multithreaded client connection manager. Will be interesting to see what numbers come up after that. If the whole premise of the blog post turns out to be flawed at least we have a page documenting the basics of how to use Clojure with several dbs ;) 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 -- Antoni Batchelli - twitter: @tbatchelli , @disclojure --- email: tbatche...@gmail.com - web: tbatchelli.org , disclojure.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: Databases for a Concurrent World
To test with pooled DB connections I thought I'd mention Apache Commons dbcp. Its a generic connection pool library that could be used for any jdbc connection. I'd post a example clojure usage but I'm afk atm. The lib's BasicDataSource is probably all you'd need. Depends on Commons pool. Just place both jars on the classpath. http://commons.apache.org/dbcp/ Allen On Jul 10, 2010 12:47 PM, Toni Batchelli tbatche...@gmail.com wrote: I think what you're doing is great. I understand you're using ab for these tests, right? What are the actual settings that you are using? Also, I'd like to mention that what these tests are showing is the behavior of the server under constant load (constant frequency in the arrival times of the requests, and constant load attached to each request). This is not what happens in reality though, and servers that do well under a constant distribution of requests might not do that well (at all) under a Pareto distribution of both arrival times and load (a real load that a server gets is very similar to a Pareto http://en.wikipedia.org/wiki/Pareto_distribution). Under a Pareto load a well crafted event-based server that has bounds on the number of threads used (and maybe other resources) might significantly outperform a 1-thread-per-request server. Unfortunately, I don't think ab can test these scenarios. I built a tool sometime ago while working at UCSB that would do exactly this. I will look into whether I can dig it out and opensource it. Toni. On Sat, Jul 10, 2010 at 8:59 AM, David Nolen dnolen.li...@gmail.com wrote: On Fri, Jul 9, 2010... -- Antoni Batchelli - twitter: @tbatchelli , @disclojure --- email: tbatche...@gmail.com - web: tbatchelli.org , disclojure.org -- You received this message because you are subscribed to the Google Groups Clojure group. To p... -- 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: ClojureDocs.org
On 10 July 2010 15:06, Stuart Halloway stuart.hallo...@gmail.com wrote: (6) Because docstrings are designed for consumption at a REPL, they may in some cases presume a fixed font. Worth considering for display on the site. What about giving function documentation the same wiki behaviour that the examples have? Start off with the docstrings as the initial values, but allow people to update them. The web allows longer and better formatted documentation than a standard Clojure docstring (which needs to fit in a terminal). - 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: Databases for a Concurrent World
Here are my examples for mysql and postgres using commons-dbcp. They are exactly the same except for the connection info. Might want to play around with the initial,min,max size properties. [MySQL] http://gist.github.com/470901 [PostgreSQL] http://gist.github.com/470904 Just download and include the following jars in the classpath: http://commons.apache.org/dbcp/downloads.html http://commons.apache.org/pool/downloads.html Allen On Sat, Jul 10, 2010 at 12:55 PM, Allen Johnson akjohnso...@gmail.com wrote: To test with pooled DB connections I thought I'd mention Apache Commons dbcp. Its a generic connection pool library that could be used for any jdbc connection. I'd post a example clojure usage but I'm afk atm. The lib's BasicDataSource is probably all you'd need. Depends on Commons pool. Just place both jars on the classpath. http://commons.apache.org/dbcp/ Allen On Jul 10, 2010 12:47 PM, Toni Batchelli tbatche...@gmail.com wrote: I think what you're doing is great. I understand you're using ab for these tests, right? What are the actual settings that you are using? Also, I'd like to mention that what these tests are showing is the behavior of the server under constant load (constant frequency in the arrival times of the requests, and constant load attached to each request). This is not what happens in reality though, and servers that do well under a constant distribution of requests might not do that well (at all) under a Pareto distribution of both arrival times and load (a real load that a server gets is very similar to a Pareto http://en.wikipedia.org/wiki/Pareto_distribution). Under a Pareto load a well crafted event-based server that has bounds on the number of threads used (and maybe other resources) might significantly outperform a 1-thread-per-request server. Unfortunately, I don't think ab can test these scenarios. I built a tool sometime ago while working at UCSB that would do exactly this. I will look into whether I can dig it out and opensource it. Toni. On Sat, Jul 10, 2010 at 8:59 AM, David Nolen dnolen.li...@gmail.com wrote: On Fri, Jul 9, 2010... -- Antoni Batchelli - twitter: @tbatchelli , @disclojure --- email: tbatche...@gmail.com - web: tbatchelli.org , disclojure.org -- You received this message because you are subscribed to the Google Groups Clojure group. To p... -- 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
Redcar and Clojure
Does anyone use Redcar editor with Clojure? I am thinking about writing a Clojure REPL plugin, but wanted to make sure no one else has already done this. Would anyone find this useful, or is there no need for it with the plethora of other options (emacs/slime/swank, counterclockwise, etc.)? -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Idiomatic Clojure namespace names
On 10 июл, 14:42, Jeff Rose ros...@gmail.com wrote: I also disagree with this concept of putting the language in the package name. One of the benefits of compiling down to a common runtime is that we don't need to care what language something was written in. I think this kind of meta-data, along with the domain of the project, authors, etc., should be associated with the Jar file if anything, but not splatted on the top of every piece of code that uses a library. Also it is possible to have a library implementing single API in parts in different languages or a library could be rewritten in a different language while retaining API compatibility. The issue of changing domain names when using the domain as package name is much worse than only the maintainer having to do a multi-file search and replace. I wonder if Oracle is going to rename all sun.* and com.sun.* packages in JVM. Also I don't see why one have to rename packages at all. Package name following the java conventions does not have to correspond to the registered domain owned by the project maintainer. From the Java Code Conventions (http://java.sun.com/docs/codeconv/html/CodeConventions.doc8.html): The prefix of a unique package name is always written in all-lowercase ASCII letters and should be one of the top-level domain names, currently com, edu, gov, mil, net, org, or one of the English two-letter codes identifying countries as specified in ISO Standard 3166, 1981. Subsequent components of the package name vary according to an organization's own internal naming conventions. Such conventions might specify that certain directory name components be division, department, project, machine, or login names. Another annoyance with these loquacious.package.names is that they require your source to be stuffed away in a column of useless directories. Even in an IDE they are annoying because in order to see the information containing components (right most) of package names you have to have a really wide package manager panel or deal with side scrolling. Every time I'm back in Java these things annoy me. This is more an IDE GUI usability issue. -- Mikhail -- 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: ClojureDocs.org
Zack if you need help with this Rail app let us now. We can give you a hand, the wish list keeps growing :))) Luc P. Sent from my iPod On 2010-07-09, at 15:07, zkim zachary@gmail.com wrote: Hi Justin, thanks again for the go-ahead to pull examples from http://clojure-examples.appspot.com. Zack, you had mentioned you planned to keep the source of your site proprietary -- is that set in stone? Definitely not set in stone. As far as the site goes there's not much Clojure going on there (rails / mysql), and I'd rather keep that part closed for now so I can concentrate on moving from alpha to beta, adding features, and fixing bugs. The analyzer, which pulls metadata / source from libraries, and inserts it into the database is a different story. Other than the fact that it's extremely hackish, nothing's really stopping me from EPLing it in the near future. You also mentioned an API / export process, which I think is a great idea. This would allow examples to be easily exported to prevent vendor lock-in. -Zack On Jul 9, 12:44 pm, Justin Kramer jkkra...@gmail.com wrote: I've told Zack that he is free to pull any examples from the wiki for use on his site. I don't know about collaboration beyond that. The wiki is open source and written in Clojure; anyone is free to contribute/fork. At least one person has expressed interest in making code contributions. Zack, you had mentioned you planned to keep the source of your site proprietary -- is that set in stone? Justin On Jul 9, 12:21 pm, David Nolen dnolen.li...@gmail.com wrote: On Fri, Jul 9, 2010 at 4:32 AM, zkim zachary@gmail.com wrote: Questions / thoughts? -Zack This is great. I think the main thing is not duplicating effort. This and clojure-examples.appspot.com should really join forces. 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
Congomongo question - how to update all records?
Let's say I have a table called :table, and a column called :col, and I want to go through all the records in the table and set the :col value to 0. I had been doing it like this: (defn update-db! [] (doseq [entry (fetch :table)] (update! :table entry (assoc entry :col 0 but the other day I noticed that this was mysteriously skipping over certain records, and not everything was getting updated. So I switched to this: (defn update-db! [] (doseq [entry (doall (fetch :table))] (update! :table entry (assoc entry :col 0 which worked just fine. I speculate that somehow the update process screws with whatever iteration process that fetch uses to deliver the records lazily. However, now my update process is limited by the number of records I can hold in memory. So, is there some sort of recipe for updating all records without first loading them all into memory? -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Idiomatic Clojure namespace names
On Sat, Jul 10, 2010 at 3:42 AM, Jeff Rose ros...@gmail.com wrote: Luckily for us, I think the tide is already rising on this conversation. Most prominent Clojure libraries are adopting the same packaging scheme as clojure.core, and we are uploading our libraries to the wild and crazy, totally uncensored and unmonitored clojars.org, which is working out great in tandem with lein. Clojars wasn't a failed experiment, it's the future. Right, I think we have a consensus of sorts here: if you are worried for some reason about naming collisions, then by all means use the verbose reverse domain name. The rest of us will all use the uncluttered way. -Phil -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Idiomatic Clojure namespace names
On Sat, 10 Jul 2010 03:42:16 -0700 (PDT) Jeff Rose ros...@gmail.com wrote: On Jul 9, 6:22 pm, Mike Meyer mwm-keyword-googlegroups. 620...@mired.org wrote: How have you managed to miss the second half of that's the way they do it in Java, which is and we need to interoperate with other JVM languages. Like it or not, one of the biggest draws of Clojure is that it interoperates with Java. Nothing about what I said precludes interoperability with Java. In fact I specifically chose to use the two part namespace because it allows for AOT compilation, and thus access from other JVM languages. No, it just ignores the increased possibility of collisions once you include the Java and other JVM language. I find the whole foo.core thing unfortunate too, because it would otherwise be nicer to just (:use foo). In my own projects I've adopted this style though, with the idea that I would like my code to be usable from other JVM languages in the future. For some people, like and future aren't acceptable options. It has to be usable from other JVM languages now. Not sure how realistic or plausible that really is... It's not really either. At the very least, you need to use a top-level namespace that sets clojure code apart from the other JVM languages (and then expect projects for which cross-language usage is important to do it the Java way anyway). I still suggest clojure for that. Using a two part namespace does enable access from other JVM languages, NOW, so yes it is plausible and realistic. I just don't see myself or many other people use Clojure libraries from outside Clojure yet, which is why I stated it the way that I did. The problem doesn't just occur for people calling clojure libraries from outside clojure. Hell, if it were, I wouldn't care - I don't plan on ever doing that. The problem occurs for people calling libraries from other languages in Clojure, which happens all the time. You are spamming the list with arguments for these completely.useless.names.for.libraries.that.google.will.find.before.you.finish.typing.the.package.name, yet there are plenty of proofs by existence that this kind of scheme is not necessary to have a successful language or library community. If people would quit repeating arguments that have already been shown to be wrong, there would be no reason to repeat the refutations. Yes, there are plenty of proofs by existence that a near free-for-all can be successful. So what? There are also plenty of proofs that a near free-for-all can cause name collisions and pain as well - even in successful languages. In fact, the more successful they are, the more likely that becomes. If all you want is a successful language, feel free to ignore any data that doesn't agree with what you're saying. If you want the environment to be the best it can be, then you examine both sets of cases, figure out what's different about them, and try and make sure clojure has the properties of the first set and not the second. Then you figure out how clojure is different from the successful cases, and try and figure out how to compensate. I've been doing that and proposing alternatives to both the free-for-all and the DNS names all along. The whole world is not going to write Clojure, and we don't need to prepare for it. This is the kind of enterprisey Java think that results in everything requiring copious amounts of configuration rather than just working the simple way by default. No, but it sure as hell seems like the whole world is writing Java already, and clojure shares that name space. That's what we have to deal with. I also disagree with this concept of putting the language in the package name. One of the benefits of compiling down to a common runtime is that we don't need to care what language something was written in. I think this kind of meta-data, along with the domain of the project, authors, etc., should be associated with the Jar file if anything, but not splatted on the top of every piece of code that uses a library. Another one of those oft-repeated wrong arguments. That ain't meta-data, it's just a name, with no meaning whatsoever. The point of using the language name as the first part of the namespace isn't to identify what language the program is written in, it's to pick out part of an existing namespace convention that isn't likely to be used by anyone else. It could just as well be pybwher. The issue of changing domain names when using the domain as package name is much worse than only the maintainer having to do a multi-file search and replace. It means that every user of the library who wants to upgrade to the latest version also has to go through their code renaming packages. This all gets much more complicated and messy when you incorporate dependency injection, reflection and other forms of dynamic code where a simple search and replace might not do it. Renaming packages is really annoying,
Proposal: Digest
Hi, I want to propose a wrapper around MessageDigest to provide a simple way to generate digests. The following proposal includes a multimethods digest, which operates either on strings or on arrays of bytes. I think digests are usuall used with strings. To expose the byte array api from java's message digest class I used multimethods. Other multimethods do not exists, as I think it doesn't make much sense to define digest on something like integers or sequences. The function digest-to-str returns a typical string representation. The available algorithms correspond to the algorithms that are available using MessageDigest. The code can be found here: http://github.com/dsp/clojure-contrib/commit/77c9f7dbe071d90bf6cb385db4859e76d5e8ff19 A typical example would be: (digest-to-str (digest hello world :algorithm SHA-1)) I'm open for suggestions, as I'm new to clojure and the API might not be perfectly suited for clojure. - 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
CCW zombie error markers
I'm using Eclipse/Counterclockwise and on a couple of occasions have had errors (e.g. once with a java.lang.IllegalArgumentException) that produce an error marker (a red circle with a white x in the left margin) that won't go away when the error is fixed, or even when closing/reopening the document or quitting/restarting Eclipse. Is there some simple way to clear these that I'm missing? I'm new to Eclipse but have tried to find this in the documentation or via web searches... but to no avail, and I have the feeling that I must be missing something obvious. Actually I did find one way to remove these things, but it's a weird pain: quit delete workspace/.metadata/.plugins/org.eclipse.core.resources/.projects/projectname/.markers relaunch clean run (see http://wiki.objectstyle.org/confluence/display/WOL/Sticky+WOD+error+markers+will+not+go+away) This seems like a workaround for a rare, pathological situation, but I've gotten into this situation twice in two days with CCW, so I'm guessing that I'm either missing the simpler, normal way to clear these things or maybe the CCW/Clojure is creating a pathological situation more than other Eclipse configurations (but more likely the former). Any pointers would be appreciated. -- Lee Spector, Professor of Computer Science School of Cognitive Science, Hampshire College 893 West Street, Amherst, MA 01002-3359 lspec...@hampshire.edu, http://hampshire.edu/lspector/ Phone: 413-559-5352, Fax: 413-559-5438 Check out Genetic Programming and Evolvable Machines: http://www.springer.com/10710 - http://gpemjournal.blogspot.com/ -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
bigint discrepency
I ran across this while editing http://clojure-examples.appspot.com:
user= (bigint 1)
1
user= (bigint 1.5)
1
user= (bigint 1)
1
user= (bigint 1.5)
java.lang.NumberFormatException: For input string:
1.5 (NO_SOURCE_FILE:0)
Since 1.5 coerces to 1, shouldn't 1.5 also coerce to 1?
user= *clojure-version*
{:interim true, :major 1, :minor 2, :incremental 0, :qualifier
master}
Bill Smith
Austin, Texas
--
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: bigint discrepency
Hello Bill, user= (bigint 1) 1 user= (bigint 1.5) java.lang.NumberFormatException: For input string: 1.5 (NO_SOURCE_FILE:0) Since 1.5 coerces to 1, shouldn't 1.5 also coerce to 1? This comes from Java's implementation of BigInteger user= (new BigInteger 1.5) java.lang.NumberFormatException: For input string: 1.5 (NO_SOURCE_FILE:0) user= (new BigInteger 1) 1 However I agree Clojure should fix that. All the best, -- Miki -- 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: Databases for a Concurrent World
Hello David, http://dosync.posterous.com/22516635 I'm interested to see what will be CouchDB numbers when there are indexes on the data. In my experience, this is a speed killer. All the best, -- Miki -- 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: Recent builds have failed on http://build.clojure.org
The current build.clojure.org is about to be replaced. We have a new build box that we should be pointing the DNS to, hopefully this weekend. Maybe clojurebot can announce build results in #clojure? Miki -- 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: Databases for a Concurrent World
To test with pooled DB connections I thought I'd mention Apache Commons dbcp. Its a generic connection pool library that could be used for any jdbc connection. There's also the lighter-weight MiniCollectionPoolManager. See http://www.source-code.biz/snippets/java/8.htm -Regards, Adrian. -- 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: bigint discrepency
Since 1.5 coerces to 1, shouldn't 1.5 also coerce to 1? The doc says Coerce to BigInteger, but that doesn't include double- quoted numbers. If (bigint) can't make up what you give it, it'll try BigInteger(byte[] val) or BigInteger(String val). Java calls can create inconsistencies but in this case I welcome the permissiveness. -- 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: ClojureDocs.org
http://gist.github.com/470031 I'm sure something like it could be made for ClojureDocs.org once the API is in place. Nice, looks pretty straightforward. I think an important aspect of a collaborative tool like this is quality control. To that end, a complete list of recent updates (with diffs) to go along with the short list on the homepage would be really nice. Agreed. I'd like to have an in depth discussion around this issue, and what potential solutions would look like, so I've set up google group (http://groups.google.com/group/clojuredocsorg). I'll be seeding this form with a couple of posts later tonight revolving around what I feel are some core issues that are very important to get right, and therefore require community facing discussion. Having a category-based outlines would also be nice. I have one here for clojure.core, adapted from the Cheatsheet: http://clojure-examples.appspot.com/clojure.core Thanks, this would be very nice to have. FYI, I'll probably be implementing a mass export feature for the wiki, so you could write a script or something to automate an import. I'll keep an eye out for this. -Zack On Jul 9, 5:05 pm, Justin Kramer jkkra...@gmail.com wrote: An examples function for the REPL that pulls from the wiki: http://gist.github.com/470031 I'm sure something like it could be made for ClojureDocs.org once the API is in place. General comments on ClojureDocs.org: I think an important aspect of a collaborative tool like this is quality control. There needs to be people watching recent updates, making sure examples meet certain standards (formatted correctly, idiomatic, etc.). To that end, a complete list of recent updates (with diffs) to go along with the short list on the homepage would be really nice. Having a category-based outlines would also be nice. I have one here for clojure.core, adapted from the Cheatsheet: http://clojure-examples.appspot.com/clojure.core Feel free to nab it. FYI, I'll probably be implementing a mass export feature for the wiki, so you could write a script or something to automate an import. Awesome work, Zack. Justin On Jul 9, 2:25 pm, Alex Miller alexdmil...@yahoo.com wrote: I've actually been thinking about this exact same kind of site for a while now and I'm thrilled that I was too lazy to do it so that you could do it instead. :) One idea that I have that I think would be killer would be to provide an API to look up one your examples at the repl so I could do something like: = (use 'clojuredocs) = (example map) clojure.core/map (since 1.0) (map inc [1 2 3 4 5]) (2 3 4 5 6) There are of course many variants of some functions and different forms of use, so dealing with the best way to provide useful help without an overwhelming number of examples is tricky in the repl, but I think worth doing. Along with doc and source, I think example would be a killer addition to allowing you to explore the libraries from the comfort of your repl. Alex On Jul 9, 3:32 am, zkim zachary@gmail.com wrote: Hi All, I'll try to keep this short. I've gotten a lot out of Clojure: I can honestly say that learning this language, and being part of this community has made me a better, happier developer, and I wanted to give something back. One of the pain points that I encountered when learning the language was a lack of examples specific to the individual functions I was trying to wrap my head around at any given time. So I took a whack at the problem, and came up withhttp://clojuredocs.org. It's a site that (I'm hoping) will fill this need by providing a centralized examples database, along with solid search capabilities across both core and third party libraries (core being the focus). Implementation: ClojureDocs.org is a rails site backed by MySQL, along with some clojure code to pull the namespaces / metadata / source and dump them into the database. Highlights: 1. Documentation and source for Clojure core, contrib, and a few third party libraries (random selection out of what I'm personally familiar with, and whatever was on the github trends page that day). 2. Search for a var across the whole ecosystem or in a specific library. 3. Per var wiki-style examples section. 4. Per var comments section. 5. Per var vars-in-this-var and this-var-used-in section (my personal favorite). Looking for a real-world example of a specific function? This is for you. For example,http://clojuredocs.org/v/1978, just below the source section. Lowlights: 1. Ugly URLs! There's a problem in the way that URLs with encoded question marks are being handled, so I had to move fromhttp://clojuredocs.org/clj-ssh/clj-ssh.core/file-pathtohttp://clojure I've got an email out to the Phusion Passenger mailing list (http://groups.google.com/group/phusion-
