Re: Clojure version in Eclipse/Counterclockwise projects
2010/7/9 Lee Spector > > On Jul 8, 2010, at 7:49 PM, Laurent PETIT wrote: > > > >> 2010/7/9 Lee Spector > >> > >> How is the Clojure version set in Eclipse/Counterclockwise projects? I'm > still wanting to work in 1.1.0, and while my older projects are using 1.1.0 > my newer ones -- I guess maybe this changed after upgrading to > Counterclockwise 0.0.59.RC2 -- are running with 1.2.0-master-SNAPSHOT. I > don't see where I can set this when creating a new project or how to change > it for an old project. I vaguely remember seeing a way but that may very > well have been in NetBeans, which I was experimenting with a little earlier. > I imagine I could manually copy files around to make this work, but there > ought to be a better way, at least when creating a new project. > > > > Hi, > > > > Again, the answer is: it works with out-of-the-box Eclipse options: a > clojure project is a java project. With additional goodies, but still a java > project. So clojure, clojure-contrib etc. are viewed as java dependencies > for the project. How do you change this ? In your project, go to Project > > Properties > Java Build Path > Libraries . In this form, you can manage the > dependencies of your project. That is you can remove the dependencies that > have been installed by default by CCW, and point to other clojure, > clojure-contrib of your choice (currently you must have not only clojure, > but also clojure-contrib in your dependencies/classpath. This will disappear > with the next release, as forcing every project to depend on clojure-contrib > is too high a barrier). > > Given that it works this way the default dependencies should be for the > current stable versions of the libraries, which would be Clojure 1.1. > Newcomers (like me) shouldn't be given 1.2 snapshots by default. > It is that way because of lack of coding time. The existing feature does not lead to a blocking state for the user. That's all. That said, I agree with your expectations ! > > Although I don't know what's involved in modifying the "new project" > wizard, I think it would be much better to add something there that allows > selection among Clojure versions than to force users to create a project > with the wrong version and then go and delete the libraries, independently > find the versions they want elsewhere on the web, download them separately, > put them in the right place, make the project point to them, etc. One of the > main reasons I'm working with Eclipse/Counterclockwise in the first place is > the relative ease of starting from nothing, downloading & installing, and > beginning to write and run Clojure programs. I didn't have to > find/download/install/configure anything else, and that was crucial. If I'll > have to jump through those kinds of hoops anyway, just to use the right > version of Clojure, then it's considerably less appealing for my purposes. > Even though I now appreciate that Counterclockwise has several other very > nice features the ease of getting started is one of my top priorities. > I understand, and this is one of the purposes of ccw, of course. I'll place this issue high in the todo-list (because adding powerful feature if no user is there to use them would make no sense :-) ) > > Following your instructions I was able to modify a new (1.2 snapshot) > project to use 1.1.0 but it required several steps: removing the > dependencies, then also deleting the jars from the project in the Package > Explorer, then copying the 1.1.0 jars from an older project into the newer > one (and I was only able to do this because I had an old project that I > created before 1.2 snapshot was the default -- if my students start from > scratch they'll have to find the 1.1.0 jars elsewhere and put them in the > right places via the OS, not in the Package Explorer), then go back into the > Project > Properties > Java Build Path > Libraries dialog to add the new > dependencies. This is quite a lot to add to the process every time I want to > create a new project, and for newbies there will be many steps at which > something can go wrong. (Update: I found a slightly shorter way but it also > relies on having an old project around and also seems to require a > "Clean"... still not nearly as good as being able to create the project with > the right Clojure version in the first place.) > Understood. BTW I would also personally very much like contrib also to always be > available without having to do any other downloading or configuration. > Yes, having contrib pre-installed as well as clojure will stay a possibility. What will differ is that currently it is *required* because the launched REPL uses clojure.contrib.repl_ln. I intend to make this requirement *vanish* for people that do not want contrib. Cheers, -- Laurent -- 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 -
Re: auto-indent in Counterclockwise
Hi On 9 July 2010 08:53, Laurent PETIT wrote: [...] >> > 2010/7/8 Lee Spector [...] >> >> Aha! It is now working for me on a mac and with control-space, getting ^ >> >> a >> >> popup menu exactly as you say and as I want! >> >> >> >> Perhaps I never actually tried this combination before, when I was just >> >> trying lots of combinations and stumbled across control-. by accident. >> >> For >> >> what it's worth control-. does not give a menu and the set of >> >> completions >> >> that it allows you to select from is different/wrong. It's some other >> >> feature. >> >> >> >> In any event, I think that the new text about keys to invoke completion >> >> should be changed to say command-space for the mac too :-) ^ [...] > Isn't it exactly what is currently done, or did I miss something ? Please > re-read carefully Lee's answer, he was talking about Ctrl+Space, not > Command+Space No, you re-read Lee's answer carefully! ;) In the first paragraph he said "control-space" and in the last paragraph he said "command-space". -- 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: auto-indent in Counterclockwise
2010/7/9 Michael Wood > Hi > > On 9 July 2010 08:53, Laurent PETIT wrote: > [...] > >> > 2010/7/8 Lee Spector > [...] > >> >> Aha! It is now working for me on a mac and with control-space, > getting > > ^ > >> >> a > >> >> popup menu exactly as you say and as I want! > >> >> > >> >> Perhaps I never actually tried this combination before, when I was > just > >> >> trying lots of combinations and stumbled across control-. by > accident. > >> >> For > >> >> what it's worth control-. does not give a menu and the set of > >> >> completions > >> >> that it allows you to select from is different/wrong. It's some other > >> >> feature. > >> >> > >> >> In any event, I think that the new text about keys to invoke > completion > >> >> should be changed to say command-space for the mac too :-) > ^ > > [...] > > Isn't it exactly what is currently done, or did I miss something ? Please > > re-read carefully Lee's answer, he was talking about Ctrl+Space, not > > Command+Space > > No, you re-read Lee's answer carefully! ;) > > In the first paragraph he said "control-space" and in the last > paragraph he said "command-space". > > Isn't it formidable that I automatically overlook the typos :-) -- 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: Request for comments: DefaultMap
Hi Stuart, I agree that the main problem here should be solved at the merge(-with) level. A couple of thoughts on this issue: On 8 July 2010 21:16, Stuart Halloway wrote: > Useful? Am I crazy? (Not mutually exclusive.) I'm inclined to think both. :-) I think that a "merge-reduce" function would be very useful indeed (I for one would definitely have more use for it than for the current merge-with), though ultimately I'd see it working along the lines of (defn merge-reduce ([maps] (merge (fn [_ x] x) maps)) ([f maps] (merge f nil maps)) ([f seed maps] ...)) This gives rise to at least two crazy possibilities: 1) call the above "merge" and allow it to supersede the current merge and merge-with; 2) just add it on top of the above two. 1) means breaking old code, which doesn't seem appealing at all, while 2) introduces a third core function which has the functionality of two other core functions built-in and follows a different calling convention while having a very similar name... Oh, the confusion. If the current signature with the "maps" argument being unrolled is preferred, than I wonder if we could simply have a third variant taking [f seed & maps]. Seems slightly wasteful, but then again, it's no big deal and keeps things consistent. Sincerely, Michał -- 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: Request for comments: DefaultMap
Hi Dave, thanks for pointing out the containsKey bug! I had it fixed locally and the (comment ...) at the top was written & tested with the fix in place, but for some reason I left the old version in the Gist... fixed now. If merge & merge-with were to coexist with a new "merge-with*" / "merge-reduce" function with a signature following a different convention, then I think "merge-reduce" would be a great name for the latter. Sincerely, Michał -- 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
I've asked myself this same question 50 times now. My best experience so far with a community that had packages was Ruby, and it was incredibly simple. Everyone can choose whatever name they like for their package as long as it isn't up on rubygems yet. I am strongly in favor of dropping these ridiculous Java naming schemes that not only waste time and obscure library names, but I think they also have a kind of selfishness to them. Just because I start a project doesn't really mean it is appropriate to use my domain for the lifetime of the project. Would you like to be programming with com.richhickey.clojure.core all of the time? Not I. This is the open source world, and I think social components like this are important for collaboration and community. Ruby (and Gems) had its own issues regarding packages and versioning, but conflicting names was never a problem for me. There are a lot of names out there, and since we have the ability to prefix however we like I don't see any good arguments for the Java naming scheme besides, "that's the way they do it in Java." Lets evolve. 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. Not sure how realistic or plausible that really is... So yeah, if the goal is to reach a consensus on package naming, I vote for the foo.core style. It works for all libs (AOT or not), and it keeps it clean and simple. It doesn't always have to be "core" either. foo.central foo.essence foo.api foo.live foo.base -Jeff On Jul 7, 6:13 pm, James Reeves wrote: > I've kinda asked this question before, but I framed in the context of > a suggestion, and the discussion got bogged down with no real answer. > > So this time, let me keep it simple: if I have a small Clojure > library, "foo", which only has one namespace, what is the idiomatic > name for that namespace? > > - foo > - foo.foo > - foo.core > - com.github.weavejester.foo > > I don't intend to call "foo" from Java, so there is no genclass in the > namespace definition, and I do not intend to AOT compile the > namespace. > > - 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: DSL with a grammar
Like some people mentioned, you can use a parsing library, but often
times I don't think that's necessary if you are just creating a DSL.
There are a couple of other strategies.
One is you can use a series of nested macros that expand into a data
structure. In this way your DSL will sort of auto-transform into a
nested data structure that you can then just operate on like regular
data. Here's what I mean, using a mini database DSL as an example:
(defmacro table [name & body]
`{:type :table
:name (str (quote ~name))
:cols [...@body]})
(defmacro col [name type]
`{:type :col
:name (str (quote ~name))
:data-type ~type})
; Allowing for specifications like this:
(table users
(col email :string)
(col password :string))
(Note: You can run this code to see the data structure it produces...)
Alternatively, if you want to get rid of parenthesis or introduce new
semantics, then you'll need to process the tokens yourself with some
logic. At a larger scale this is better done with a parser, but if
you just need to support a special keyword here or there, it's pretty
easy to include some simple logic in a macro to look at a symbol and
do something different depending on what it is. In general I try to
keep the semantics inside normal function definitions though, and just
use macros for restructuring.
-Jeff
On Jul 8, 8:52 pm, Nicolas Oury wrote:
> Dear all,
>
> I am trying to write a small Domain Specific Language using macro, and I
> want the syntax of the args of the macro to be somehow "parsed" and
> transformed.
>
> So, I have two questions:
>
> - Does anybody else does that? (except the infix calculus) Is there a
> generic method for doing it? Or even better a library?
> - I want to report syntax error from my macro expansion. Is there a way to
> get the line (or even better the line/file and character) of the usage of a
> macro being expanded?
> That way I could have helpful error message
>
> Best regards,
>
> Nicolas.
--
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: auto-indent in Counterclockwise
On 9 July 2010 11:17, Laurent PETIT wrote: [...] > Isn't it formidable that I automatically overlook the typos :-) It can be a blessing or a curse :) -- 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: DSL with a grammar
And does anyone has tried to use parser combinators on the result of the
reader, within a macro?
On Fri, Jul 9, 2010 at 11:23 AM, Jeff Rose wrote:
> Like some people mentioned, you can use a parsing library, but often
> times I don't think that's necessary if you are just creating a DSL.
> There are a couple of other strategies.
>
> One is you can use a series of nested macros that expand into a data
> structure. In this way your DSL will sort of auto-transform into a
> nested data structure that you can then just operate on like regular
> data. Here's what I mean, using a mini database DSL as an example:
>
> (defmacro table [name & body]
> `{:type :table
>:name (str (quote ~name))
>:cols [...@body]})
>
> (defmacro col [name type]
> `{:type :col
>:name (str (quote ~name))
>:data-type ~type})
>
> ; Allowing for specifications like this:
>
> (table users
> (col email :string)
> (col password :string))
>
> (Note: You can run this code to see the data structure it produces...)
>
> Alternatively, if you want to get rid of parenthesis or introduce new
> semantics, then you'll need to process the tokens yourself with some
> logic. At a larger scale this is better done with a parser, but if
> you just need to support a special keyword here or there, it's pretty
> easy to include some simple logic in a macro to look at a symbol and
> do something different depending on what it is. In general I try to
> keep the semantics inside normal function definitions though, and just
> use macros for restructuring.
>
> -Jeff
>
> On Jul 8, 8:52 pm, Nicolas Oury wrote:
> > Dear all,
> >
> > I am trying to write a small Domain Specific Language using macro, and I
> > want the syntax of the args of the macro to be somehow "parsed" and
> > transformed.
> >
> > So, I have two questions:
> >
> > - Does anybody else does that? (except the infix calculus) Is there a
> > generic method for doing it? Or even better a library?
> > - I want to report syntax error from my macro expansion. Is there a way
> to
> > get the line (or even better the line/file and character) of the usage of
> a
> > macro being expanded?
> > That way I could have helpful error message
> >
> > Best regards,
> >
> > Nicolas.
>
> --
> 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: ANN: Aleph, an asynchronous web server
On Wed, Jul 7, 2010 at 11:15 AM, Zach Tellman wrote: > At the Bay Area user group meeting in June, there was a very > interesting discussion about how to best use Clojure's concurrency > primitives to field large numbers of concurrent requests, especially > in a long-poll/push type application. We didn't arrive at any solid > conclusion, but it was clear to everyone that a thread-per-request > model is especially gratuitous for a language like Clojure. > > With this in mind, I decided to make the thinnest possible wrapper > around Netty such that a person could play around with alternate ways > to use Clojure effectively. The result can be found at > http://github.com/ztellman/aleph. Very interesting! I've been following the thread with great interest and did a quick performance test today comparing standard compojure with jetty against aleph and netty. I get around 4500 req/s with compojure and 3500 req/s with aleph. The test was as simple as possible, just return hello world. > I've just discovered another Netty wrapper was released this weekend > (http://github.com/datskos/ring-netty-adapter), but it's somewhat > different in its design and intent; it couples the request and > response to allow for seamless interop with Ring. > > Anyways, I hope some people find this interesting. Clojure doesn't > seem to have found its own voice w.r.t. web development; hopefully we > can work together to fix that. -- Anders Rune Jensen -- 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: ANN: Aleph, an asynchronous web server
On Fri, Jul 9, 2010 at 8:44 AM, Anders Rune Jensen < anders.rune.jen...@gmail.com> wrote: > Very interesting! > > I've been following the thread with great interest and did a quick > performance test today comparing standard compojure with jetty against > aleph and netty. I get around 4500 req/s with compojure and 3500 req/s > with aleph. The test was as simple as possible, just return hello > world. I'm curious how you ran that test. With ab running 10 clients for 1 second I see ~4000-5000 req/s using Compojure 0.4.0. With aleph I see ~8000-9000 req/s. I also had a quick chat with Zach Tellman and it sounds like he hasn't done much in the way of optimizing (few Java type hints), so we'll likely see the aleph numbers go up. 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: ANN: Aleph, an asynchronous web server
On Jul 8, 2:26 pm, Antoni Batchelli wrote: > Also, in some instances with NIO you can even work directly > with kernel buffers, and so the network data doesn't even need > to be copied from the kernel space into the user space. I assume that you are referring to NIO direct byte buffers. A threaded application can use direct byte buffers. I apologize for my sloppy terminology. When I wrote NIO, I was referring to the evented or async programming model. I didn't mean to imply that the threaded model cannot use NIO. > If the number of threads is not bound, a traffic spike will make > your memory requirements skyrocket, either exhausting the memory in > your JVM or prompting the OS to start paging on its VM. Yeah, a poorly constructed server can fall over with high load. The servers that I have worked with use bounded thread pools for this and other reasons. -- 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: ANN: Aleph, an asynchronous web server
Maybe what I said makes less sense in the case of NIO vs blocking with threads - I've mainly been working with Intel Threading Building Blocks lately, where the cost of cache cooling is very real. For that reason (and the others mentioned - context switches and lock preemption), Intel Threading Building Blocks will try and run a single thread per core and load balance work amongst these. I wouldn't say its just one thing (eg context switching), but a combination of thread memory overheads, thread creation and destruction, context switching, cache cooling, false sharing and lock preemption. I also don't know how valid this is to Java/Clojure or web servers, though I don't see why it wouldn't be just as valid as any other multicore code. Finally, I don't think you can really achieve true scalability by not using a multicore processors cores (by using a pure asynchronous server) - you would want to use the available cores. I'm just saying that having more threads than cores (or rather, more software threads than hardware threads) may hurt performance or scalability due to time slicing overheads. Obviously its more complicated than simply creating N worker threads for an N-core system though, since if any blocking IO is performed the cores are under-utilized. "just because you're not switching threads doesn't mean that different requests will not need to e.g. touch different cache lines" Yes, of course! I didn't mean to imply that an asynchronous server would save you from this. However, in an asynchronous server, (or, more importantly, in one where the number of threads do not exceed the number of hardware threads) it becomes much more likely that a request is processed to completion before it gets evicted from the cache (as long as care is taken to prevent false sharing with other, independent data which share the cache lines). As for locks, making sure to hold locks for as short a time as possible is a well known pattern, so I agree, the likelihood of switching away at the wrong time (and having another thread then try and aquire that same lock) is very low, but it can and does still happen on occasion - and when it does, it can really hit performance. (of course, the performance hit for a web application might not even be noticable - there wouldn't be so many web apps written in PHP, Ruby and Python!) Anyway, web servers aren't my area of expertise, so please ignore me if this isn't at all relevant to the discussion. Still, I am very interested to hear yours and everyone elses real world experiences. On an aside, callbacks aren't really all that cache frindly, unless great care is taken. OO isn't the greatest model for cache friendly multicore code either. Maybe thats one reason I like Clojures sequence abstraction as much as I do. On 8 July 2010 23:41, Peter Schuller wrote: > > Under heavy load, this can be quite costly, especially if each request > > requires non-trivial processing (ie, enough to make time-slicing kick > > in). > > This doesn't really jive with reality as far as I can tell; if > anything it is the exact opposite of reality. If you're doing > significant work in between doing I/O calls (which tend to be context > switching points) even to the point of usually yielding only to > pre-emptive switching resulting from exceeding your time slice, the > relative overhead of threading should be much less (usually) than if > you're just doing a huge amount of very very small requests. > > Whatever the extra cost is in a thread context switch compared to an > application context switch (and make no mistake, it's effectively > still a context switch; just because you're not switching threads > doesn't mean that different requests will not need to e.g. touch > differens cache lines, etc), that becomes more relevant as the amount > of work done after each switch decreases. > > The cost of time slicing while holding a lock is real, but if you have > a code path with a high rate of lock acquisition in some kind of > performance critical situation, presumably you're holding locks for > very short periods of time and the likelyhood of switching away at > exactly the wrong moment is not very high. > > Also: Remember that syscalls are most definitely not cheap, and an > asynchronous model doesn't save you from doing syscalls for the I/O. > > > So, between memory overheads, cost of creating and destroying threads > > and context switching, using a synchronous model can be extremely > > heavyweight compared to an asynchronous model. Its no surprise that > > people are seeing much better throughput with asynchronous servers. > > In my experience threading works quite well for many production tasks, > though not all (until we get better "vertical" (all the way from the > language to the bare metal) support for cheaper threads). The > maintenance and development costs associated with writing complex > software in callback form with all state explicitly managed, disabling > any use of sensible control
ClojureDocs.org
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
Clojure and Backtraces
Hi! I try to use clojure, and get problems with understanding what's- going-on with this awful backtraces. Is there any way to make this traces useful? -- 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: Any Clojure2js Libraries?
Scriptjure will do just perfectly. Thanks. Tim On Jul 8, 2:00 pm, Scott Jaderholm wrote: > Clojurescript is the only thing I know of like scheme2js. There are a > couple parenscript like programs, the best > beinghttp://github.com/arohner/scriptjure > > Scott > > > > On Thu, Jul 8, 2010 at 1:17 PM, Tim Robinson wrote: > > All I got from google was Clojurescript, but I'm wondering what > > options are out there. > > > I was looking for something like scheme2js[1] only in Clojure. > > > Thanks, > > Tim > > > [1]http://www-sop.inria.fr/mimosa/scheme2js/ > > > -- > > 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: Idiomatic Clojure namespace names
On Jul 9, 5:58 am, Mike Meyer wrote: > The other non- project requirement (a page linking the project to the domain > name) is pretty much contrary to the quote from the Java specification. By my reading, they are talking about something different - the "groupId" which identifies the project in a Maven build file. Sun was piggybacking on URLs to make a naming convention for Java packages, Maven is piggy-backing on the Java package naming convention with additional restrictions to make a scheme for unique project IDs with traceable ownership and licensing. Although groupId and Java package names tend to resemble each other, and the description on the Maven page is conflating the two, they are two different entities and made to solve different problems. >From their FAQ on the same page: - I have a patched version of the foo project developed at foo.com, what groupId should I use? * When you patch / modify a third party project, that patched version becomes your project and therefore should be distributed under a groupId you control as any project you would have developed, never under com.foo. See above considerations about groupId. I guess Maven wants to be the kind of authoritative software artifact repository Clojars apparently isn't, judging from the comments in this thread. jf -- 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
clojure + voltdb
I've created a basic project to show how to create a voltdb database, and then to create java and clojure clients for this database: http://github.com/ToddG/clojure-voltdb Any feedback would be most welcome. There's a tutorial and ant tasks for each step. -Todd -- 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: ANN: Aleph, an asynchronous web server
On Fri, Jul 9, 2010 at 3:09 PM, David Nolen wrote: > On Fri, Jul 9, 2010 at 8:44 AM, Anders Rune Jensen > wrote: >> >> Very interesting! >> >> I've been following the thread with great interest and did a quick >> performance test today comparing standard compojure with jetty against >> aleph and netty. I get around 4500 req/s with compojure and 3500 req/s >> with aleph. The test was as simple as possible, just return hello >> world. > > I'm curious how you ran that test. With ab running 10 clients for 1 second I > see ~4000-5000 req/s using Compojure 0.4.0. With aleph I see ~8000-9000 > req/s. I also had a quick chat with Zach Tellman and it sounds like he > hasn't done much in the way of optimizing (few Java type hints), so we'll > likely see the aleph numbers go up. Yeah I was possitive that the numbers were quite good for aleph considering it's such a young project. But I was expecting netty to beat jetty, so I was a little disappointed :) I just ran the test as simple as possible: java -server (no others paramters set), default kernel settings (Ubuntu) and then using ab -n 5000 -c 50 (as in your blog post). As always with java, one needs to run ab a few times before the number stabilize :) The test machine was an old intel c2 duo 2 GHz. > David -- Anders Rune Jensen -- 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: ANN: Aleph, an asynchronous web server
On 9 July 2010 14:09, David Nolen wrote: > I'm curious how you ran that test. With ab running 10 clients for 1 second I > see ~4000-5000 req/s using Compojure 0.4.0. With aleph I see ~8000-9000 > req/s. I also had a quick chat with Zach Tellman and it sounds like he > hasn't done much in the way of optimizing (few Java type hints), so we'll > likely see the aleph numbers go up. Benchmarking Aleph against Ring Jetty directly is likely to produce more accurate results. Compojure adds middleware and routing logic, so it's not really a fair test. That said, I expect Aleph to outperform the Jetty adapter :) - 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: auto-indent in Counterclockwise
Sorry for the typo -- I did indeed mean control-space throughout, and CCW is doing what everyone seems to think is right on this (control-space for symbol completion). -Lee On Jul 9, 2010, at 7:00 AM, Michael Wood wrote: > On 9 July 2010 11:17, Laurent PETIT wrote: > [...] >> Isn't it formidable that I automatically overlook the typos :-) > > It can be a blessing or a curse :) > > -- > 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 -- 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
Re: ANN: Aleph, an asynchronous web server
On Fri, Jul 9, 2010 at 9:44 AM, Anders Rune Jensen < anders.rune.jen...@gmail.com> wrote: > On Fri, Jul 9, 2010 at 3:09 PM, David Nolen > wrote: > > On Fri, Jul 9, 2010 at 8:44 AM, Anders Rune Jensen > > wrote: > >> > >> Very interesting! > >> > >> I've been following the thread with great interest and did a quick > >> performance test today comparing standard compojure with jetty against > >> aleph and netty. I get around 4500 req/s with compojure and 3500 req/s > >> with aleph. The test was as simple as possible, just return hello > >> world. > > > > I'm curious how you ran that test. With ab running 10 clients for 1 > second I > > see ~4000-5000 req/s using Compojure 0.4.0. With aleph I see ~8000-9000 > > req/s. I also had a quick chat with Zach Tellman and it sounds like he > > hasn't done much in the way of optimizing (few Java type hints), so we'll > > likely see the aleph numbers go up. > > Yeah I was possitive that the numbers were quite good for aleph > considering it's such a young project. But I was expecting netty to > beat jetty, so I was a little disappointed :) > > I just ran the test as simple as possible: java -server (no others > paramters set), default kernel settings (Ubuntu) and then using ab -n > 5000 -c 50 (as in your blog post). As always with java, one needs to > run ab a few times before the number stabilize :) > ab is a little weird. Trying running your tests again and you'll probably see the results I'm seeing. > > The test machine was an old intel c2 duo 2 GHz. > > > David > > -- > Anders Rune Jensen > > -- > 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: ANN: Aleph, an asynchronous web server
> Maybe what I said makes less sense in the case of NIO vs blocking with > threads - I've mainly been working with Intel Threading Building Blocks > lately, where the cost of cache cooling is very real. For that reason (and > the others mentioned - context switches and lock preemption), Intel > Threading Building Blocks will try and run a single thread per core and load > balance work amongst these. I haven't used Building Blocks, but I certainly agree that running exactly as many threads as cores is probably optimal under most conditions (assuming cache contention doesn't interact in such a way as to make it worse; e.g. you might see two threads going faster than four and such under extreme conditions). > would want to use the available cores. I'm just saying that having more > threads than cores (or rather, more software threads than hardware threads) > may hurt performance or scalability due to time slicing overheads. Obviously > its more complicated than simply creating N worker threads for an N-core > system though, since if any blocking IO is performed the cores are > under-utilized. Agreed. > However, in an asynchronous server, (or, more importantly, in one where the > number of threads do not exceed the number of hardware threads) it becomes > much more likely that a request is processed to completion before it gets > evicted from the cache (as long as care is taken to prevent false sharing > with other, independent data which share the cache lines). Agreed, but with the specific caveat that this is specifically under circumstances where you are in fact trading latency for throughput. In other words, this is true, but in any specific case where the asynch design allowed you to complete where you would otherwise have context switched, you are intrinsically violating your would-be timeslice, thus having effects on latency resulting from other requests waiting on your one long/expensive requests. > isn't at all relevant to the discussion. Still, I am very interested to hear > yours and everyone elses real world experiences. I come from the perspective of first having written quite a lot of multi-threaded C++ code (over a few years) that did fairly complex combinations of "CPU work" and I/O with other services. I am really confident that the code I/we wrote would never have been completed in even close to the same amount of time/resources if we had written everything event-based. I cannot overstate this point enough... During the last year I've been exposed so quite a lot of reactive code (C++, Python twisted, some others), with the expected IMO pretty extreme consequences for code maintainability and productivity (even for people who's been writing such code for a long time and are clearly used to it). So I have an strong desire to avoid going event based if possible as a default position. In terms of scalability, that definitely mattered when I worked on the mentioned multi-threaded code. It directly translated to hardware costs in terms of what you had to buy because we had effectively an infinite amount of work to be done in some areas (such as crawling the web; you don't really run out of things to do because you can always do things more often, better or faster). However, that experience is at best anecdotal since no formal studies were done on multi-core scalability; rather doubling cores meant it went "almost twice as fast" - purely anecdotal, based on empirical observations during development cycles. On this topic I found it interesting reading about Google's concerns with and improvements to the Linux kernel to support their use. I couldn't find the article right now (I'm pretty sure it was on lwn), but it strongly implied that Google definitely used production systems with very many threads. I found that interesting since given Google's scale, presumably runtime efficiency may be very highly valued compared to extra development cost to get there. My hypothesis, probably colored by confirmation bias, is that the difference in effort in writing large complex systems in an event-based fashion is simply too expensive to be worth it even at Google's scale - at least in the general case. Their release of Go was unsurprising to me for this reason :) Has anyone here got experience with writing really complex systems (big code bases, services talking to lots of other services, doing non-trivial control flow etc) in event-based form? Any comments on how it scales, in terms of development costs, as the size and complexity of the system grows? -- / Peter Schuller -- 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 and Backtraces
There are some utilities in clojure.stacktrace that are helpful with gnarly stacktraces (http://richhickey.github.com/clojure/clojure.stacktrace-api.html ). Various people have tinkered with more sophisticated "stacktrace interpreters" of late; clj-stacktrace is the most notable that I've heard of so far (http://github.com/mmcgrana/clj-stacktrace). In either case, I think it would be great if something along the lines of clj-stacktrace (or even clojure.stacktrace, as a first step) were baked into the REPL in the next version of Clojure. This is a universal pain point. - Chas On Jul 9, 2010, at 3:28 AM, Vasily Pupkin wrote: Hi! I try to use clojure, and get problems with understanding what's- going-on with this awful backtraces. Is there any way to make this traces useful? -- 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: clojure + voltdb
Hey Todd, It's great to see you working on this! Added your project to the list of projects I'm watching. :-) I'm very interested in benchmarking VoltDB against PostgreSQL, so this is good to see. I'm not yet at the database point in my project, so I'm not fully aware yet of all the Clojure related issues and might not have the best of feedback to offer yet, but one question I do have is whether it makes sense to make this interoperable with projects like ClojureQL, and some of the ORM solutions out there (clj-record, carte, oyako, etc.). Sincerely, Greg On Jul 9, 2010, at 2:03 AM, Todd wrote: > I've created a basic project to show how to create a voltdb database, and > then to create java and clojure clients for this database: > > http://github.com/ToddG/clojure-voltdb > > Any feedback would be most welcome. There's a tutorial and ant tasks for each > step. > > -Todd > > -- > 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
I took a first look and I have to say that the idea is genius and I love what you put up together this far. It is difficult to keep up with what's happening in the Clojure world, and this kind of central place to keep track of things was needed. The examples are also a strong point. I hope the site will grow with many people's contributions. Victor On Fri, Jul 9, 2010 at 4:32 AM, zkim 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 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, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Clojure and Backtraces
> In either case, I think it would be great if something along the lines of > clj-stacktrace (or even clojure.stacktrace, as a first step) were baked into > the REPL in the next version of Clojure. This is a universal pain point. Seconded. On Jul 9, 2010, at 11:50 AM, Chas Emerick wrote: > There are some utilities in clojure.stacktrace that are helpful with gnarly > stacktraces > (http://richhickey.github.com/clojure/clojure.stacktrace-api.html). Various > people have tinkered with more sophisticated "stacktrace interpreters" of > late; clj-stacktrace is the most notable that I've heard of so far > (http://github.com/mmcgrana/clj-stacktrace). > > In either case, I think it would be great if something along the lines of > clj-stacktrace (or even clojure.stacktrace, as a first step) were baked into > the REPL in the next version of Clojure. This is a universal pain point. > > - Chas > > On Jul 9, 2010, at 3:28 AM, Vasily Pupkin wrote: > >> Hi! >> >> I try to use clojure, and get problems with understanding what's- >> going-on with this awful backtraces. Is there any way to make this >> traces useful? >> >> -- >> You received this message because you are subscribed to the Google >> Groups "Clojure" group. >> To post to this group, send email to clojure@googlegroups.com >> Note that posts from new members are moderated - please be patient with your >> first post. >> To unsubscribe from this group, send email to >> clojure+unsubscr...@googlegroups.com >> For more options, visit this group at >> http://groups.google.com/group/clojure?hl=en > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To 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 Fri, Jul 9, 2010 at 2:32 AM, zkim wrote: > Hi All, > > Questions / thoughts? > > -Zack Hi Zack, First off, I think it looks great, and it definitely seems useful when trying to find an example of a particular API call. Few suggestions: 1. The headers for each section (Doc, Source, Example(s)) don't differentiate themselves from the regular doc text enough, maybe bold/underline/color them to make them show up more? 2. The links to the source code should link to http://github.com/clojure/clojure, I believe the richhickey clojure repo has been transitioned there. 3. I know non-confirmation logins are really nice, but should the site attract any spammers, you may want to look at adding an email account confirmation (since spammers could go nuts adding comments to pages). Looks awesome, hope it gets some love from the Clojure community. - Lee -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: ClojureDocs.org
On Fri, Jul 9, 2010 at 4:32 AM, zkim 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
Re: Idiomatic Clojure namespace names
On Fri, 9 Jul 2010 03:01:01 -0700 (PDT) Jeff Rose wrote: > I've asked myself this same question 50 times now. My best experience > so far with a community that had packages was Ruby, and it was > incredibly simple. Everyone can choose whatever name they like for > their package as long as it isn't up on rubygems yet. I am strongly > in favor of dropping these ridiculous Java naming schemes that not > only waste time and obscure library names, but I think they also have > a kind of selfishness to them. Just because I start a project doesn't > really mean it is appropriate to use my domain for the lifetime of the > project. Would you like to be programming with > com.richhickey.clojure.core all of the time? Not I. This is the open > source world, and I think social components like this are important > for collaboration and community. Ruby (and Gems) had its own issues > regarding packages and versioning, but conflicting names was never a > problem for me. There are a lot of names out there, and since we have > the ability to prefix however we like I don't see any good arguments > for the Java naming scheme besides, "that's the way they do it in > Java." Lets evolve. 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. > 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. http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Idiomatic Clojure namespace names
On Jul 8, 8:38 pm, Laurent PETIT wrote: > My opinion: no need to create problems when there already are accepted > solutions. > > In the java world, there are conventions for naming things. Stick with them. > I do see your point and if this is the way the consensus moves I'll follow it. However, the java solution does create the following new problems: 1. It leads to deep directory structures that are horrible to navigate on the command line (even using tab completion) and when browsing source code. I just went to github and browsed the new volt-db library. It uses a java style naming convention and I had to click through 4 levels of directory to get to some source code. 2. It makes the 'ns' declaration at the top of a source file harder to read. Instead of seeing easy to recognise libraries such as compojure, hiccup and ring the person reading has reversed tlds to parse. Somebody ended up on another thread because they had a typo in their title. However, I like their solution of libraryname.author.file e.g compojure.weavejester.api dynamite.acme-corp The hard work of finding unique handles/authors is done by vanity (individual or company). Also, to add my opinion on the original question that started this thread, I prefer 'foo.api' to 'foo.core' as it gives a clearer idea of which namespace should be pulled in by the user. 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
Hello, 2010/7/9 Saul Hazledine > On Jul 8, 8:38 pm, Laurent PETIT wrote: > > My opinion: no need to create problems when there already are accepted > > solutions. > > > > In the java world, there are conventions for naming things. Stick with > them. > > > > I do see your point and if this is the way the consensus moves I'll > follow it. However, the java solution does create the following new > problems: > > 1. It leads to deep directory structures that are horrible to navigate > on the command line (even using tab completion) and when browsing > source code. I just went to github and browsed the new volt-db > library. It uses a java style naming convention and I had to click > through 4 levels of directory to get to some source code. > > 2. It makes the 'ns' declaration at the top of a source file harder to > read. Instead of seeing easy to recognise libraries such as compojure, > hiccup and ring the person reading has reversed tlds to parse. > > Somebody ended up on another thread because they had a typo in their > title. However, I like their solution of libraryname.author.file e.g > compojure.weavejester.api > dynamite.acme-corp > > The hard work of finding unique handles/authors is done by vanity > (individual or company). > > Also, to add my opinion on the original question that started this > thread, I prefer 'foo.api' to 'foo.core' as it gives a clearer idea of > which namespace should be pulled in by the user. > > Indeed, foo.api sounds better than foo.core to me, now than I'm exposed to that (core sounds more like 'internals'). 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) -- 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
Having contributed a lot of examples to clojure-examples.appspot.com this week, I agree that it would be a shame to duplicate efforts. On Jul 9, 11:21 am, David Nolen wrote: > On Fri, Jul 9, 2010 at 4:32 AM, zkim 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
Should max and min have 0-arg implementations?
I noticed that http://clojure-examples.appspot.com/clojure.core/max has both (apply max [1 2 3 4]) -> 4 and (max []) -> [] (which I think is a poor example). However, when attempting to add another example for (apply max []) which I expected to return nil, that instead it throws an exception. I have to admit, I've never come across this in practice, but it seems like adding the overload would be nice for generality. -- Aaron -- 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: Should max and min have 0-arg implementations?
Once you walk down the path of "What should (max) return?" I think you won't want a default behavior. Stu P.S. Agreed that (max []) is a bad example. > I noticed that http://clojure-examples.appspot.com/clojure.core/max has both > (apply max [1 2 3 4]) -> 4 and (max []) -> [] (which I think is a poor > example). > > However, when attempting to add another example for (apply max []) which I > expected to return nil, that instead it throws an exception. > > I have to admit, I've never come across this in practice, but it seems like > adding the overload would be nice for generality. > > -- Aaron > > -- > 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: Clojure and Backtraces
On Fri, Jul 9, 2010 at 8:50 AM, Chas Emerick wrote: > In either case, I think it would be great if something along the lines of > clj-stacktrace (or even clojure.stacktrace, as a first step) were baked into > the REPL in the next version of Clojure. This is a universal pain point. Agreed. I was actually planning on suggesting this once 1.2 was released. In our project at work we already re-def clojure.stacktrace/print-cause-trace to clj-stacktrace.repl/pst since it's basically a drop-in replacement. It's been a great improvement over the stock stacktrace tools. I've talked to Mark, the author, and it sounded like he'd be willing to contribute it. Right now I think clojure.test is the main user of the clojure.stacktrace namespace, and clj-stacktrace works great with that, but obviously we'll need to check against other libraries to ensure there aren't any compatibility issues there. -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 Thu, Jul 8, 2010 at 11:09 PM, j-g-faustus wrote: > From their FAQ on the same page: > - I have a patched version of the foo project developed at foo.com, > what groupId should I use? > * When you patch / modify a third party project, that patched version > becomes your project and therefore should be distributed under a > groupId you control as any project you would have developed, never > under com.foo. See above considerations about groupId. > > I guess Maven wants to be the kind of authoritative software artifact > repository Clojars apparently isn't, judging from the comments in this > thread. Clojars has the exact same policy with regard to modified third-party libraries, (hence the abundance of org.clojars.$USERNAME groupids) it just doesn't enforce it with technical means; it relies on its users to make responsible decisions before uploading. Unfortunately this trust seems to have been misplaced in a few instances, or perhaps the documentation just needs to be more forceful. This would not be a big problem (it's easy to fix manually) except for the fact that the Clojars maintainer has disappeared. I've tried to contact him to see if he could allow someone else to have access (perhaps a Clojure/core member?) but have been unsuccessful. I will try again though--Clojars is too important to leave it in the hands of one person. -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 8 July 2010 16:56, Chas Emerick wrote: > Clojars is a disaster as an authoritative software artifact repository IMO, > and nothing about how it's being used should be taken as a template for > anything else. Ruby and Rubygems has been using single-segment namespaces for years, with no major problems. I don't think name clashes are a problem in practise, because projects tend to have original names. - 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: Clojure and Backtraces
Proposal and patch welcome! > On Fri, Jul 9, 2010 at 8:50 AM, Chas Emerick wrote: >> In either case, I think it would be great if something along the lines of >> clj-stacktrace (or even clojure.stacktrace, as a first step) were baked into >> the REPL in the next version of Clojure. This is a universal pain point. > > Agreed. > > I was actually planning on suggesting this once 1.2 was released. In > our project at work we already re-def > clojure.stacktrace/print-cause-trace to clj-stacktrace.repl/pst since > it's basically a drop-in replacement. It's been a great improvement > over the stock stacktrace tools. I've talked to Mark, the author, and > it sounded like he'd be willing to contribute it. > > Right now I think clojure.test is the main user of the > clojure.stacktrace namespace, and clj-stacktrace works great with > that, but obviously we'll need to check against other libraries to > ensure there aren't any compatibility issues there. > > -Phil > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups "Clojure" group. To 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
It's a great idea, and the site looks very good. Two suggestions: 1. Move examples section above source code section 2. Add OpenID sign in support. Personally I'm instantly repelled by sites asking me to create another account/password. And I'm sure I'm not alone. Stackoverflow.com is a great example of how effortless it could be to "register". - Dmitry On Jul 9, 1:32 am, zkim 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: ClojureDocs.org
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 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: ClojureDocs.org
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 wrote: > On Fri, Jul 9, 2010 at 4:32 AM, zkim 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
Bug in 1-arg max/min implementation? (Was: Should max and min have 0-arg implementations?)
On Fri, 9 Jul 2010 13:57:05 -0400 Stuart Halloway wrote: > Once you walk down the path of "What should (max) return?" I think you won't > want a default behavior. > > Stu > > P.S. Agreed that (max []) is a bad example. Given that max only works on numbers, then why doesn't (max []) throw the same exception as (max [] [])? Or, for that matter, (max \a) throw the same exception as (max \a \b \c)? If max worked on any comparable (which is what I expected), then (max A) always returning A makes sense, even if A isn't comparable. But that behavior when max is defined as only working on numbers sure seems like a bug. http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Idiomatic Clojure namespace names
On Fri, 9 Jul 2010 19:14:00 +0100 James Reeves wrote: > On 8 July 2010 16:56, Chas Emerick wrote: > > Clojars is a disaster as an authoritative software artifact repository IMO, > > and nothing about how it's being used should be taken as a template for > > anything else. > Ruby and Rubygems has been using single-segment namespaces for years, > with no major problems. I don't think name clashes are a problem in > practise, because projects tend to have original names. They do if you have a central registry for the project names, which RubyGems provides. If you don't, then they don't. Python doesn't have a single central registry (it has one official one, and a couple of unofficial ones that provide features missing from the original), and it has problems with namespace collisions. For that matter, I've had a number of my projects share names with other projects. Even if clojure had such a central registry, you're still forgetting that JAVA INTEROP IS A MAJOR DRAW FOR CLOJURE. That means you either need a central registry that covers all the JVM languages (which we've already got), or a first-level name that clojure projects share that distinguishes them from all the other JVM languages. http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Bug in 1-arg max/min implementation? (Was: Should max and min have 0-arg implementations?)
> Given that max only works on numbers, then why doesn't (max []) throw > the same exception as (max [] [])? Or, for that matter, (max \a) throw > the same exception as (max \a \b \c)? Clojure tends not to guarantee any particular behavior for invalid inputs. It might return an error, or it might give back a spurious answer. Most likely, the code for max just has a case that if it is only passed a single input, then that is the answer. No error checking is performed. -- 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
Quick thought: You probably don't want to include private vars. On Jul 9, 1:32 am, zkim 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: ClojureDocs.org
On Fri, Jul 9, 2010 at 2:32 AM, zkim wrote: > Hi All, > > Questions / thoughts? > > -Zack Hi Zack, First off, I think it looks great, and it definitely seems useful when trying to find an example of a particular API call. Few suggestions: 1. The headers for each section (Doc, Source, Example(s)) don't differentiate themselves from the regular doc text enough, maybe bold/underline/color them to make them show up more? 2. The links to the source code should link to http://github.com/clojure/clojure, I believe the richhickey clojure repo has been transitioned there. 3. I know non-confirmation logins are really nice, but should the site attract any spammers, you may want to look at adding an email account confirmation (since spammers could go nuts adding comments to pages). Looks awesome, hope it gets some love from the Clojure community. - Lee -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Solving Clojure's Documentation Problem Without Fragmentation
I'm very excited to see how quickly the Clojure community is taking up the charge of improving the documentation! Within a few *days* of my "Clojure n00b problem" post, several solutions have emerged to take up the cause of providing proper documentation and examples for Clojure's API, and third-party APIs as well. I don't know whether that post had anything to do with it, and frankly it doesn't matter. The projects that have emerged are: http://clojure-examples.appspot.com/ http://www.clojuredocs.org/ Further, I noticed several other reactions in this group of people stating they were planning on doing the same thing. You can add me to that list. :-p I'm worried, however, about the problem of fragmentation. This is a very serious problem that affects many projects, companies, etc. Providing good documentation and examples for Clojure's APIs, as well as third-party libraries, is *not* an easy task, and I doubt very much that a good result will emerge in the existence of a fragmented playing field. It would be a wish come true for me if Clojure's documentation were as good as PHP's or newLISP's. The only way that's going to happen is if efforts are not fragmented. Notice that both of those examples are examples of non-fragmented, focused community efforts. Clojure currently has at *least* 3 locations for API/examples. The two efforts above, and the existing Clojure.org/api. I have a feeling that more are on the way. I'd like to propose that we address this problem immediately, before it gets worse. We need to have one, single, awesome goto location for examples and documentation. Without that Clojure's documentation will remain third-rate. I think such a website must include, at the very minimum: 1) A way for anyone to easily add and edit examples and documentation. 2) For functions to be grouped by task/category 3) API access to the documentation and examples via JSON, so that IDEs can hook into it and provide documentation inline while you're editing. 4) Simple and easy methods for third-party developers to add their project(s) to the site. 5) Site-wide search on function/namespace names, documentation, and examples. And this is the "it would be nice" list, (again, all my opinion, of course): 1) Comments by users. 2) For the comments to be parsesable in markdown/textile so that commenters can post syntax-highlighted code. 3) Community voting and replying on individual comments ala HackerNews. 4) Live-updating searching in a frame/div in a section on the left to filter for functions/namespaces. 5) For the site to be powered by Clojure. Call me old-fashioned, but I think it should be. :-p 6) A better clojure-doc to integrate developers with the site. It would be great if developers could provide the initial documentation to such a site by running a tool like javadoc on their code. With regards to the minimum, #2 (task/category), is one of the most important (IMO). Have a look at how newLISP does this: http://www.newlisp.org/downloads/manual_frame.html The left-navigation bar makes it incredibly easy to find what you're looking for. PHP does something similar. I wouldn't consider a documentation site "good" without it. The practice of listing namespaces and then the functions within them in alphabetical order on one massive page isn't helpful. It's not helpful for learning an API, and it's not helpful for quick-reference. Possible solutions to fragmentation As I mentioned, I was (and still am) planning on addressing this issue if it's not solved well by another effort. But I don't want to add to the fragmentation either. Shortly after posting "Clojure n00b problems", I registered clojuredoc.org for that purpose. I'm now not so sure what to do with it, but I have some ideas. I have two proposals: Proposal #1: Combine clojure-examples & clojuredocs.org -- clojure-examples is already on Github. This is good, it means anyone can contribute and improve the site. It's also powered by Clojure. I think it'd be great if the two efforts combined forces and combined their documentation/comments/examples. I'd be happy to hand over clojuredoc.org to such an effort. Proposal #2: Central database of documentation and examples - If for some reason you don't want to combine efforts on the front-end of the site, clojuredoc.org could server simply as a backend for holding all the data. This way clojure-examples and clojuredocs.org (and IDEs) could pull & push examples/comments/documentation from a central location. This way, when someone submits examples on one site, they're available for all sites to use, and thus effort is not fragmented. Comments/Feedback welcome (especially Zachary Kim and Justin Kramer, and anyone else who is working or is i
Re: Idiomatic Clojure namespace names
On 9 July 2010 17:30, Laurent PETIT wrote: > Indeed, foo.api sounds better than foo.core to me, now than I'm exposed to > that (core sounds more like 'internals'). 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) Is there any benefit to using a name like foo.core (or foo.api) rather than simply foo (beyond sytlistic considerations, that is)? Leiningen creates a foo.core source file as part of its new project skeleton, but I prefer foo. Before I start fighting Leiningen, are there any pitfalls I'll hit (other than the obvious problems of fighting your tools...)? 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: ClojureDocs.org
Thanks all for your kind words. As to the specifics: > The headers for each section (Doc, Source, Example(s)) don't > differentiate themselves from the regular doc text enough, maybe > bold/underline/color them to make them show up more? I'd agree, I think the visual styling of the page will change a lot in the near future based on feedback, for now I'll add underlining. > The links to the source code should link to > http://github.com/clojure/clojure, I believe the richhickey clojure > repo has been transitioned there. Will update. > I know non-confirmation logins are really nice, but should the site > attract any spammers, you may want to look at adding an email account > confirmation (since spammers could go nuts adding comments to pages). This is strictly for alpha, I'm currently going back and forth between signups confirmed through email, or recaptcha (or both), but rounding out the sign-up / login process is high on my list. > This is great. I think the main thing is not duplicating effort. This and > clojure-examples.appspot.com should really join forces. > Having contributed a lot of examples to clojure-examples.appspot.com > this week, I agree that it would be a shame to duplicate efforts. I've been talking with Justin, and he's allowed me to pull examples from his site (as well as given some great feedback). I'm definitely all for a collaborative effort. Thanks, Zack. On Jul 9, 10:30 am, ".Bill Smith" wrote: > Having contributed a lot of examples to clojure-examples.appspot.com > this week, I agree that it would be a shame to duplicate efforts. > > On Jul 9, 11:21 am, David Nolen wrote: > > > > > On Fri, Jul 9, 2010 at 4:32 AM, zkim 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
List moderation
Is there anything we can do to improve the speed with which replies are sent to the list, and the order in which they're approved? I've observed several times my replies being approved after others, despite them obviously being sent before (based on content and timestamps). It's rather jarring for the conversation as a whole, I think, for replies to take hours for approval, and then for some to come out-of-order. Perhaps more moderators would help? I'd be willing to volunteer some time, and I'm sure others would as well. - Greg -- 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
I've put these suggestions up on the UserVoice page, I believe I got all of them, but if I missed yours please add it yourself or let me know. Dimitri: I share your frustrations with having to remember yet another login / password. Other than minor cosmetic fixes, improving the user signup / login experience is at the top of my list. Alex: Example lookup from the REPL would be awesome. As of now this is a bit lower on the list until things stabilize around the site. Side note: My responses don't seem to be showing up right away on the mailing list, so they may appear out of order. -- 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 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 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 wrote: > > > > > On Fri, Jul 9, 2010 at 4:32 AM, zkim 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
Re: ClojureDocs.org
On 9 July 2010 09:32, zkim wrote: > > Questions / thoughts? > > Looks really good to me. Could you display the version numbers for Clojure and the libraries that the site covers? Gavin -- 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, 8:14 pm, James Reeves wrote: > Ruby and Rubygems has been using single-segment namespaces for years, > with no major problems. I don't think name clashes are a problem in > practise, because projects tend to have original names. It works up to a point. It is claimed that university-level English speakers know about 10k words. The universe of possible names is probably larger, but not infinite. Ruby apparently has about 14k gems, and the advantage of a central repository where you can check if a name is in use. They still have things like AccessControl and access_control as two different projects. The JVM doesn't have a central repository, at least 10 to 100 times more libraries than Ruby, and half a dozen different languages running on it. What are the chances that people will think up half a million unique single-segment names? 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". I'm pretty sure the Java package naming convention is overkill in many (most?) cases. But as Laurent said, it may not be worth the trouble to reinvent something else. I guess I'll go with Chas' suggestion to "use discretion and sound judgement" for now :) jf -- 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
Clojure Job Opportunity in Boston!
Hi, I am a Technical Recruiter in Boston. I have a client in the Boston area who is looking for Software Engineers - Java & Clojure/Lisp skills. Please find the job description listed below. If anyone is interested in this role, please feel free to contact me directly at 617-951-1886 to further discuss & to send resumes to laura.brok...@avidtr.com. Referrals are always welcome as well! Thanks, Laura Brokans laura.brok...@avidtr.com 617-951-1886 Responsibilities: * Strong desire to problem solve with a keen focus on strategic scope * Quick study of key server-side technologies and systems * Drive development from conception and design through testing to deployment * Create new features and contribute to existing technology * Take responsibility for software quality, working closely with QA * Trouble shoot complex problems, working with support teams as needed Qualifications: Basic Qualifications * Overall Experience: 5+ years in software development. * 2+ years experience in Lisp and/or Java software development on Linux/Unix platforms. * 2+ years of experience with JVM and/or Java interoperability. * 2+ years experience working with Internet protocols such as TCP/IP, UDP/IP, and/or HTTP. * 2+ years experience with the complete software development process, from scoping to design, implementation, testing, and release. Desired Qualifications: * Education: Bachelor’s Degree preferred in Computer Science or similar field. * Familiarity with Clojure or Scheme. * Familiarity with Perl. * Knowledge of SQL, XHTML, CSS, and Javascript. * Familiarity with mobile web standards (XHTML Mobile or WAP) * Familiarity with multiple mobile web browsers (WebKit, Blackberry, Opera, OpenWave, NetFront) * Solid understanding of Web (W3C) markup languages and interfaces. * Embedded/mobile development experience. * Smartphone development, including iPhone, Android, RIM and Nokia * Strong communication and organizational skills. * Highly responsible, self-disciplined, self-managed, self-motivated, able to work with little or no supervision. -- 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
Beautiful. I think this should become the official community place for Clojure docs. Now who wants to integrate my :examples defn attribute code :) -John On Jul 9, 4:32 am, zkim 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: ClojureDocs.org
Tom- I kind of went back and forth on this. Originally I only parsed out public vars, but in a couple of instances I found that when tracing through some code I would hit on private vars. Perhaps a solution where private vars are hidden from normal flow (browsing and searching) unless explicitly included by the user? -Zack On Jul 9, 2:06 pm, Tom Faulhaber wrote: > Quick thought: You probably don't want to include private vars. > > On Jul 9, 1:32 am, zkim 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- > > 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: List moderation
Hi Greg, I thought that the approval process was supposed to auto-approve people after a certain number of approved messages, but that doesn't seem to have happened (at least in your case). Your messages are no longer moderated. Sorry for the delays. Stu > Is there anything we can do to improve the speed with which replies are sent > to the list, and the order in which they're approved? > > I've observed several times my replies being approved after others, despite > them obviously being sent before (based on content and timestamps). > > It's rather jarring for the conversation as a whole, I think, for replies to > take hours for approval, and then for some to come out-of-order. > > Perhaps more moderators would help? I'd be willing to volunteer some time, > and I'm sure others would as well. > > - Greg -- 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: ANN: Aleph, an asynchronous web server
On Wed, Jul 7, 2010 at 11:15 AM, Zach Tellman wrote: > At the Bay Area user group meeting in June, there was a very > interesting discussion about how to best use Clojure's concurrency > primitives to field large numbers of concurrent requests, especially > in a long-poll/push type application. We didn't arrive at any solid > conclusion, but it was clear to everyone that a thread-per-request > model is especially gratuitous for a language like Clojure. > > With this in mind, I decided to make the thinnest possible wrapper > around Netty such that a person could play around with alternate ways > to use Clojure effectively. The result can be found at > http://github.com/ztellman/aleph. > > I've just discovered another Netty wrapper was released this weekend > (http://github.com/datskos/ring-netty-adapter), but it's somewhat > different in its design and intent; it couples the request and > response to allow for seamless interop with Ring. > > Anyways, I hope some people find this interesting. Clojure doesn't > seem to have found its own voice w.r.t. web development; hopefully we > can work together to fix that. Is it possible to get an exception or something when a client disconnects? To avoid using needless resources. -- Anders Rune Jensen -- 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
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 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 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- > > 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 Fri, 9 Jul 2010 12:49:05 -0700 (PDT) j-g-faustus 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. Large companies may regularly register their trademarks in every TLD with multiple spellings (IUC, the IETF has been threatened with lawsuits if they create more domains because of this), but small companies don't. Not much point in keeping any vestige of the Java convention if you're going to cause organizational collisions right off the bat. http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Solving Clojure's Documentation Problem Without Fragmentation
Because of an moderation problem with my email (https://groups.google.com/group/clojure/browse_frm/thread/90c0a82153e08c9c) this thread is a bit outdated already. Perhaps it should be merged with the ClojureDocs.org thread now, as Tim and Justin apparently already seem to agree on collaboration (which is great!). - Greg On Jul 9, 2010, at 12:33 PM, Greg wrote: > I'm very excited to see how quickly the Clojure community is taking up the > charge of improving the documentation! > > Within a few *days* of my "Clojure n00b problem" post, several solutions have > emerged to take up the cause of providing proper documentation and examples > for Clojure's API, and third-party APIs as well. I don't know whether that > post had anything to do with it, and frankly it doesn't matter. > > The projects that have emerged are: > > http://clojure-examples.appspot.com/ > http://www.clojuredocs.org/ > > Further, I noticed several other reactions in this group of people stating > they were planning on doing the same thing. You can add me to that list. :-p > > I'm worried, however, about the problem of fragmentation. This is a very > serious problem that affects many projects, companies, etc. > > Providing good documentation and examples for Clojure's APIs, as well as > third-party libraries, is *not* an easy task, and I doubt very much that a > good result will emerge in the existence of a fragmented playing field. > > It would be a wish come true for me if Clojure's documentation were as good > as PHP's or newLISP's. The only way that's going to happen is if efforts are > not fragmented. Notice that both of those examples are examples of > non-fragmented, focused community efforts. > > Clojure currently has at *least* 3 locations for API/examples. The two > efforts above, and the existing Clojure.org/api. I have a feeling that more > are on the way. > > I'd like to propose that we address this problem immediately, before it gets > worse. We need to have one, single, awesome goto location for examples and > documentation. Without that Clojure's documentation will remain third-rate. > > I think such a website must include, at the very minimum: > > 1) A way for anyone to easily add and edit examples and documentation. > 2) For functions to be grouped by task/category > 3) API access to the documentation and examples via JSON, so that IDEs can > hook into it and provide documentation inline while you're editing. > 4) Simple and easy methods for third-party developers to add their project(s) > to the site. > 5) Site-wide search on function/namespace names, documentation, and examples. > > And this is the "it would be nice" list, (again, all my opinion, of course): > > 1) Comments by users. > 2) For the comments to be parsesable in markdown/textile so that commenters > can post syntax-highlighted code. > 3) Community voting and replying on individual comments ala HackerNews. > 4) Live-updating searching in a frame/div in a section on the left to filter > for functions/namespaces. > 5) For the site to be powered by Clojure. Call me old-fashioned, but I think > it should be. :-p > 6) A better clojure-doc to integrate developers with the site. It would be > great if developers could provide the initial documentation to such a site by > running a tool like javadoc on their code. > > With regards to the minimum, #2 (task/category), is one of the most important > (IMO). > > Have a look at how newLISP does this: > > http://www.newlisp.org/downloads/manual_frame.html > > The left-navigation bar makes it incredibly easy to find what you're looking > for. PHP does something similar. I wouldn't consider a documentation site > "good" without it. > > The practice of listing namespaces and then the functions within them in > alphabetical order on one massive page isn't helpful. It's not helpful for > learning an API, and it's not helpful for quick-reference. > > > Possible solutions to fragmentation > > > As I mentioned, I was (and still am) planning on addressing this issue if > it's not solved well by another effort. But I don't want to add to the > fragmentation either. > > Shortly after posting "Clojure n00b problems", I registered clojuredoc.org > for that purpose. I'm now not so sure what to do with it, but I have some > ideas. > > I have two proposals: > > Proposal #1: Combine clojure-examples & clojuredocs.org > -- > > clojure-examples is already on Github. This is good, it means anyone can > contribute and improve the site. It's also powered by Clojure. I think it'd > be great if the two efforts combined forces and combined their > documentation/comments/examples. I'd be happy to hand over clojuredoc.org to > such an effort. > > Proposal #2: Central database of documentation and examples > --
Re: ClojureDocs.org
*argh*. well at least my email is now finally on the whitelist. What do you guys think of some of the ideas presented in the "Solving Clojure's Documentation Problem Without Fragmentation" thread? (Which I sent shortly after this thread started, but ended up being posted several hours later). https://groups.google.com/group/clojure/t/77fda1c7c95f5344 - Greg P.S. clojuredoc.org might be irrelevant if you guys choose to collaborate on the same project, but what do you think about using Justin's codebase, or an Aleph-based server to host the thing instead of Ruby/Rails? (see the link above for more details) On Jul 9, 2010, at 7:05 PM, Justin Kramer 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 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 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- >>> 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 re
Re: List moderation
Thanks Stuart! Wow. It's like a breath of fresh air. My responses are actually arriving on time. Really, it felt weird previously, sort of like I was stuck in a timewarp. :-p - Greg On Jul 9, 2010, at 6:58 PM, Stuart Halloway wrote: > Hi Greg, > > I thought that the approval process was supposed to auto-approve people after > a certain number of approved messages, but that doesn't seem to have happened > (at least in your case). > > Your messages are no longer moderated. Sorry for the delays. > > Stu > >> Is there anything we can do to improve the speed with which replies are sent >> to the list, and the order in which they're approved? >> >> I've observed several times my replies being approved after others, despite >> them obviously being sent before (based on content and timestamps). >> >> It's rather jarring for the conversation as a whole, I think, for replies to >> take hours for approval, and then for some to come out-of-order. >> >> Perhaps more moderators would help? I'd be willing to volunteer some time, >> and I'm sure others would as well. >> >> - Greg > > > -- > 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
Databases for a Concurrent World
Some benchmarks thoughts on various databases + aleph. http://dosync.posterous.com/22516635 Cheers, 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
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. On Jul 9, 7:10 pm, David Nolen wrote: > Some benchmarks thoughts on various databases + aleph. > > http://dosync.posterous.com/22516635 > > Cheers, > 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
Recent builds have failed on http://build.clojure.org
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
Hi, Am 09.07.2010 um 23:47 schrieb zkim: > I kind of went back and forth on this. Originally I only parsed out > public vars, but in a couple of instances I found that when tracing > through some code I would hit on private vars. I'm suspicious of showing source code to the reader with everything more than a small quite nondescript link. The contract is the docstring. Looking at the code might be interesting but non-helpful. You start relying on implementation details, while these might change at any time (eg. introduction of transients, etc.). I would *not* show the source code and I would *not* document private vars. They are not part of the contract and should not show up in public API documentation. 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
On Jul 10, 12:16 am, Mike Meyer wrote: > On Fri, 9 Jul 2010 12:49:05 -0700 (PDT) > > j-g-faustus 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
