Re: [ANN] `comidi`: a committee approach to defining HTTP routes
Chris, this is definitely interesting. Quickly pluggable metrics swagger trapperkeeper componentization sure are useful integrations. Doing a quick review, it surprised me a bit how many dependencies you brought into comidi https://github.com/puppetlabs/comidi/blob/master/project.clj [dependencies]. This looks more like a pragmatic, compromise integration library than a pure new offer (just like you said you need at Puppet Labs). Nevertheless, since you deviate from Compojure's API, I was very surprised to still see you depend on it. And then I remind myself that you're in there for meaningful, but quick, wins. There was a discussion between most of the authors of the popular routing libraries when Silk was introduced, including bidi's Malcolm, which came to be very interesting too. When you titled `comidi` as being a committee approach to defining HTTP routes, I wondered if you were following up to that discussion. Here's a link I kept to the middle of it https://groups.google.com/forum/#!searchin/clojure/silk$20bidi/clojure/D95anPmhNhU/X7P53cGbfZMJ [discussion]. In any case, thanks for contributing to this field. [dependencies]: https://github.com/puppetlabs/comidi/blob/master/project.clj [discussion]: https://groups.google.com/forum/#!searchin/clojure/silk$20bidi/clojure/D95anPmhNhU/X7P53cGbfZMJ On Wednesday, July 1, 2015 at 5:45:40 AM UTC-4, Chris Price wrote: Hiya. We really like the syntax of compojure for defining HTTP routes, but have had some trouble with use cases where we'd really like to be able to introspect the route tree, and aren't able to do so because the nested functions are pretty opaque. After spending some time trying to workaround that, and giving up, we decided to look into bidi, which has been awesome. The data-driven route tree is really, really useful. However, a wholesale port of all of our existing apps directly from compojure to bidi seemed daunting. Enter `comidi`: https://github.com/puppetlabs/comidi This is a small library that uses bidi to build up route trees, but provides a compojure-like syntax for defining the routes, and uses compojure's render capabilities to support flexible syntax for specifying your individual handlers for each route. We've also got a related project that integrates comidi with our Trapperkeeper framework and the dropwizard metrics library, to give you middleware that will automatically track request metrics for each route in your bidi/comidi route tree. This is all a work in progress: notably, we had built up some prismatic schemas around the route structures, but since the latest release of bidi ships with its own schemas, we'll probably try to upgrade to that and reconcile the differences soon. We also have some plans for improving the ability to wrap middleware around the route tree at various levels, and to look into some ring-swagger integration soon. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: How to share the large files that can not fit in Github?
Since you mentioned GitHub, have you looked at Git Large File Storage? https://github.com/blog/1986-announcing-git-large-file-storage-lfs On Monday, June 22, 2015 at 4:09:31 PM UTC-4, Mohit Thatte wrote: AWS S3 is a great place to put large files https://aws.amazon.com/blogs/aws/amazon-s3-object-size-limit/. You can use S3 sync http://docs.aws.amazon.com/cli/latest/reference/s3/sync.html to keep things current. ~Mohit On Mon, Jun 22, 2015 at 9:34 PM, Lawrence Krubner lawr...@rollioforce.com javascript: wrote: This is more of Java eco-system/development question, but I am curious what folks in the Clojure community might regard as best practice. Up till now most of the projects that I've worked on we've been able to share resources informally via scp and email, or via Github, but on the current project we are dealing with a lot of massive files, over 100 megs, many over a gig. These are things such as Natural Language Processing classifiers/dictionaries, many of which are huge. We need to have them available on our machines so we can do development work. We're trying to figure a way such that when we add new paths or new files we can tell each other, or find a way that they can do something similar to git fetch origin and see what changes have happened. How do others handle this? -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clo...@googlegroups.com javascript: Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+u...@googlegroups.com javascript: For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@googlegroups.com javascript:. For more options, visit https://groups.google.com/d/optout. -- -Mohit Thatte -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [ClojureScript] Re: [ANN] Silk, an isomorphic routing library for Clojure and ClojureScript
This thread over Silk, Bidi and Secretary has been very interesting. I looked at the three projects to see how they evolved after this thread started. Any cross-pollination or progress worth sharing now that I've missed? From what I could gather: * Secretary is evolving towards a conservative 2.0 and won't, after all, be re-implemented on top of Silk. This may be a good thing: not bringing more transitive dependencies in all projects using Secretary. Thus, Secretary would remain the first stop for Compojure-like easy routing in ClojureScript apps. * Bidi was already quite mature and comparable to Silk and remains as attractive as it was, especially with regard to its established production usage and corporate backing. * Silk's development slowed for some time and this may make for a good occasion to reflect on its state and the value of its ambitions (which seemed quite interesting to me). * I would add, from distant memory, that Pedestal's isomorphic routing is planned to be extracted into a self-contained library. Judging from the advent of Clojure 1.7's reader conditionals and Om's model 2 for which I'm expecting an announcement in a few weeks, I suppose Cognitect may start providing again their leadership on the front-end. Either they start recommending something like Bidi or Silk, or they (more probably) reader-cond-port their routing lib to ClojureScript. I'm watching this space and thanks for any comments. On Sunday, October 12, 2014 at 11:28:13 PM UTC-4, Dom Kiva-Meyer wrote: Thanks for the experience reports, Dylan! Colin, Silk is Ring-compatible and meant to be used as a single replacement for both Compojure and Secretary (or any other server/browser routing combination with incompatible syntax and semantics). But, as Dylan said, it's totally fine to use it in conjunction with Compojure instead of replacement. Silk should also work fine with all Ring middleware. In the next version, Silk will have a more familiar and mostly Compojure-compatible syntax for defining routes. My hope is that this will make it easier to translate Compojure examples/code to Silk. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Clojure for web project? Talk me into it!
Not to make it more complicated for you, but have you looked at Hoplon too? http://hoplon.io/ I was *very* impressed by the author's presentations, the later of which is https://www.youtube.com/watch?v=wVXjExRiFy0 And podcast about it: http://thinkrelevance.com/blog/2014/03/18/alan-dipert-cognicast-episode-052 It's optimized around single-page web apps. I'm not saying that's what I'd necessarily use for your product; you may want to use all of it, or parts of it (it's modular) along something else. If this kind of approach isn't what you'd use on your front-end, make sure you look at Om, Reagent and Quiescent for that. And obviously, I'm forgetting a few other batteries-included frameworks I've seen (because there are a few, apart from Caribou). On Tuesday, April 29, 2014 4:22:58 AM UTC-4, Bernhard Mäder wrote: Hey guys, I need your help in choosing a web stack for a medium sized website project, which is going to take the better half of my time for the next year. I really want to use clojure, because of various reasons, but have never done web development with it before. Frankly, it’s quite hard to feel confident about such a decision, as there are so many libraries to choose from, many of which seem to be abandoned or with very little (public) momentum. These are the notable features I need on the server side: - Internationalization of content, with multilingual URLs - Authentication through username / password and through xing (oauth) and linkedin (oath2). - Image and PDF upload - A small (and pretty basic) CMS - Beautiful reports renderings - A basic admin backend First, I was thinking along the compojure/hiccup/friend stack. I like it for the simplicity, the flexibility and the abundance of documentation on the web. Unfortunately, I see myself reinventing the wheel a few times with this approach… Then there is caribou. I like that it’s very well documented and that it’s already being used in production. It appears to be the most feature complete solution for the time being. It handles images, has backend scaffolding and i18n. OTOH, authentication isn’t really built-in (other than basic auth, if I got that right) and, it’s very new, so adoption seems to be still low. Also, it is developed in-house, so there’s the risk of abandonment, too. Finally, I took a look at pedestal (services). I like its overall design and I especially welcome the URL generator, which is going to be a boon in larger projects. But all in all, it seems to be little more than a (powerful) routing engine (again, maybe I’m missing something) and lacks internationalization as well as authentication (although I read that the snapshot version of friend will work with it). Also, it is developed in-house and not declared production-ready yet. I don’t feel very comfortable with either choice and would appreciate the thoughts of seasoned clojure web devs on that topic. Please talk me into it! I don’t want to end up with scala and play… :-) Thanks for your thought! Bernhard -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [ANN] CloCoP - constraint programming for Clojure
So then you'd also need a 0.3.0 branch to allow people to pull-request new features and/or breaking changes, since those things are not semantically ok to do in a patch release (the 1 in 0.2.1). Of course there are many other ways to look at this workflow thing around pull requests, versioning and etc. I hope my tone felt helpful. :) On Thursday, September 12, 2013 4:21:11 PM UTC-4, Alex Engelberg wrote: It's under the Eclipse Public License (as stated in project.clj), with pull requests welcome. I just added the license info to the Readme as well. Sorry about the confusion. I've also created a 0.2.1 branch (without any changes yet) for people to pull-request new features into. (Though if you're just submitting examples/tests, the master branch is fine.) Thanks, --Alex On Wednesday, September 11, 2013 1:47:44 PM UTC-7, sesm wrote: Great stuff! Unfortunately, README doesn't say anything about license and contributing, so I've sent a pull request to check it :) If you accept contributing tests/examples, I would send a lot more. вторник, 10 сентября 2013 г., 5:39:46 UTC+4 пользователь Alex Engelberg написал: http://github.com/aengelberg/clocop CloCoP is a Clojure wrapper of the Java library JaCoP. The acronyms stand for Clojure/Java Constraint Programming. This invites comparison to the core.logic library, and you may wonder why we need both. There are a few ways in which, in my opinion, the JaCoP system is better than core.logic: - JaCoP is more plug-in-able, with an extensive set of customizations to the way that the search operates. There are interfaces for different components of the search, and each has several implementations. - I found that with core.logic, I was somewhat limited by the set of available constraints. JaCoP has many different constraints that seem to more suit my needs for solving challenging problems. - As the core.logic people say,https://github.com/clojure/core.logic/wiki/External-solversJaCoP is anywhere from 10X-100X faster than core.logic at solving Finite Domain problems. JaCoP has a lot of global constraints which are very powerful and essential for describing certain problems. As Radoslaw Szymanek (an author of JaCoP) says, CP without global constraints is just [a] plain academic toy. Using problems with arithmetic constraints is doing CP bad publicity. If you'd like to see implementations of sample problems in CloCoP, check out the test caseshttps://github.com/aengelberg/clocop/tree/master/test/clocop (https://github.com/aengelberg/clocop/tree/master/test/clocop). -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
What is wrong with ClojureQL?
Since Korma appeared, it seems ClojureQL isn't mentioned anywhere anymore. Are there solid reasons why Korma took all the attention to itself? Are there situations in which ClojureQL would be more recommended than Korma? In case nobody remembers CQL : http://clojureql.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: A New Core.logic Primer
On Wednesday, March 14, 2012, Dan wrote: David Nolen wrote: Thanks to Edmund Jackson we have a new primer for core.logic: https://github.com/clojure/core.logic/wiki/A-Core.logic-Primer [...] I think you should say a word about prolog and mention that unlike it core.logic isn't turing complete and can't have infinite loops (unless I'm mistaken about core.logic). Dan, you probably read that recently about Datalog, while you were reviewing Datomic. Ain't that right? :) -- 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: Can Clojure be as readable as Python or Ruby ?
On Thursday, March 8, 2012 9:33:04 PM UTC-5, puzzler wrote: I love these ideas. I think your final comment is especially insightful. I have no problem writing Clojure code, I just find it unnecessarily taxing to read it. The idea of separating the two, and possibly having a read-mode is an absolutely fascinating idea. In some sense, Marginalia is already a good positive step in this direction. The first time I ran Marginalia on my code I was astonished at how much more readable it was to have the comments in a separate column alongside the code, rather than interrupting the code itself. It makes me wonder how many other things could have such a positive, dramatic effect. I think you struck it there, especially wrt marginalia. I've been wanting for a long time for some kind of code editor where ancillary things like comments/tests/contracts/examples may be displayed in a more appropriate manner, so that our code may be the star of our screen, while still being appropriately accompanied on demand by those comments/tests/contracts/examples. You're right that putting comments in a different column (which is scrolled synchronously) helps. Wouldn't be nice if that column could be replaced anytime with tests/contracts/examples/etc.? And with a larger monitor, multiple synced columns could be displayed. That said, to me, it's important that all of this is still editable at all times. I don't often read my own code in marginalia for this reason. Of course, you may just as well tell me that's what emacs allows with its buffers and swank-clojure slime. But anyway, emacs' way of doing it is much more an *on demand* thing, and much less pervasive for now. I feel we could do quite a bit more with those tools. -- 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: Must a page refresh fire an init event?
Folcon wrote: I'm trying out Clojurescript one, but whenever I refresh the page the init event appears to fire so I lose the current state I'm in. How can I set it so that the init event only resets my state if I don't have any? (I'm intending to have an explicit reset event.) That's the nature of the web. A page refresh in a browser clears all client-side, transient state. You can restore state out of persistent state stores (cookies on the client side, or session on the server side), or you can also pass state elements through the HTTP request-response workflow. All that said, if your intention was to try your code changes while you were developing, I strongly encourage you to watch this very nice screencast [1] and read that wiki page [2]. [1] http://vimeo.com/35153207 [2] https://github.com/brentonashworth/one/wiki/Development Also, the rest of the wiki is very interesting [3]. [3] https://github.com/brentonashworth/one/wiki -- 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: Must a page refresh fire an init event?
The wiki page I really meant is https://github.com/brentonashworth/one/wiki/Workflow Also, obviously, restoring state out of persistent state stores can only be made if you've explicitly saved stuff there before the user refreshed the page. The same is true of the HTTP request-response workflow. No state can survive through a browser refresh in any case unless the developer provisioned one of those ways for the state to flow through. Daniel Jomphe wrote: Folcon wrote: I'm trying out Clojurescript one, but whenever I refresh the page the init event appears to fire so I lose the current state I'm in. How can I set it so that the init event only resets my state if I don't have any? (I'm intending to have an explicit reset event.) That's the nature of the web. A page refresh in a browser clears all client-side, transient state. You can restore state out of persistent state stores (cookies on the client side, or session on the server side), or you can also pass state elements through the HTTP request-response workflow. All that said, if your intention was to try your code changes while you were developing, I strongly encourage you to watch this very nice screencast [1] and read that wiki page [2]. [1] http://vimeo.com/35153207 [2] https://github.com/brentonashworth/one/wiki/Development Also, the rest of the wiki is very interesting [3]. [3] https://github.com/brentonashworth/one/wiki -- 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: Must a page refresh fire an init event?
ClojureScript One is built on top of Ring, which provides nice middleware for handling cookies [1]. You may want to search for wrap- on the web page of One's marginalia documentation to see where you could add this middleware [2]. [1] https://github.com/mmcgrana/ring/wiki/Cookies [2] http://clojurescriptone.com/documentation.html But all of this is server-side, and if you need to persist state of which the server can't know about, then you need to set the cookies on the client side. There, accessing cookies can be done by calling standard cookie-handling javascript functions [3] (using ClojureScript's interop to javascript). Or you may prefer to use the Cookies class that comes with the Google Closure Library that's part of ClojureScript [4], which I would advise to do if you need to manage cookies client-side. [3] http://www.w3schools.com/js/js_cookies.asp [4] http://closure-library.googlecode.com/svn/docs/class_goog_net_Cookies.html As for how to call either of those things from ClojureScript, I suggest looking at One's source code for lots of examples. (One doesn't use cookies at all but you'll see lots of calls of js stuff, and lots of usages of Closure Library stuff.) On Saturday, January 21, 2012 9:37:26 PM UTC-5, Folcon wrote: Actually thinking about this what you are saying seems to be correct, I just realised that the atom is stored on the client, not the server. Is there any cookie functionality I can access from clojurescript? Regards, Folcon -- 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: Breaking news - Counterclockwise sponsored by Relevance !
Congrats Laurent, and thanks Relevance! -- 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
Curator for ZooKeeper in Avout
I know ZooKeeper may not be wholly part of Avout's future, but I just remembered that one using zk may really much want to use it through Curator to ease that a lot. I'm not sure, but one of the highlights looks like Curator could be used to allow embedding zk inside Avout, either directly (as a maven dependency) or as a plugin. That would feel much better than depending on a separate, manual installation of zk, isn't this right? I suggest you take a look at the FAQ to see what else Curator provides, and its rationale. https://github.com/Netflix/curator/wiki/FAQ -- 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] ClojureScript One - Getting Started with ClojureScript
Will we be able to read the account of the experience of translating the app from CoffeeScript to ClojureScript? And/or reading both code bases. Not sure if this account is covered by https://github.com/brentonashworth/one/issues/22 -- 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: Literate Programming example
On Sunday, November 20, 2011 5:50:31 AM UTC-5, thorwil wrote: I'm following one or the other Free Software project where an incredible amount of discussions happen regarding work-flow and features. So much thought, so many decisions on details, but for the most part, the implementation is all that remains. But the research, concepts and conscious decisions regarding trade-offs could actually outlive any implementation, they are portable and could be argued to be more valuable. You raised my curiosity. Would you mind sharing a link? ;) -- 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: Literate Programming example
On Sunday, November 20, 2011 6:17:13 AM UTC-5, robermann79 wrote: FYI: some time ago the Opensuse project used such a collaborative tool (http://www.co-ment.com) in order to get a shared mindset of its goals. This was the result, see how clicking on higlight words points to their comments: https://lite.co-ment.com/text/lNPCgzeGHdV/view/ Interesting. And funny, considering I bought the cochapter.com domain to do something similar. I'm yet to deliver the application that's planned to power that domain. -- 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: Literate Programming example
On Saturday, November 19, 2011 2:37:48 PM UTC-5, TimDaly wrote: However, as Knuth points out and as I've already experienced, writing a program in literate form vastly reduces the errors. There are two causes I can find. First, if I have to write an explanation then I have to justify my poor code hacks. Sometimes I find that I rewrite the code because the very act of explaining the bad code made me realize that the code is bad. I find I have to talk about memory allocations so I catch leaks. I have to talk about argument handling so I end up proving that the arguments are correct, or I end up checking for possible failures. Second, because other people can see the reasoning at the code review, they can chastise me for failing to explain, or explaining things that the code does not do, or just plain failing to implement a correct solution. With the tools available to us today, there's no reason why we at least shouldn't have everything needed to make literate programming more seamless, more natural. For example, while reading your toy example, I found myself wanting to ask a question or comment on your thoughts a few times. If your book had been displayed on a dynamic website geared towards literate programming, I might have been able to click on a paragraph and write my question/comment right there. And then, after a short conversation there, you would have integrated the fruits of our conversation directly into the end result. Thus each new reader would have been an occasion to improve the book. ...It's nothing surprising since this kind of review system already exists in some publishers' toolkits. Another thing that appeals to me regarding Tangle, is the fact that it may be used to keep things DRY. For example, when we have many arity-overloaded implementations of a function, some of their arguments are repeated, and we need to duplicate their api docs. Tangle could be leveraged to get rid of this duplication. -- 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: Literate Programming example
On Friday, November 18, 2011 7:17:08 AM UTC-5, TimDaly wrote: Many of you asked me to show an example of a literate program and demonstrate the use of the tangle function. I usually use Latex for literate work but I've done this example using HTML and pre id=foo tags. I've written a self-referential literate program that explains the details of the tangle function in literate form. You can find the web page at http://daly.literatesoftware.com/lithtml/litprog.html I have read your literate program, and must recognize that I know how tangle works even though I didn't want to really read the source code. I read your prose all the way through. I still haven't read the source code; I didn't feel the need to read it. Were I to maintain your program, I'd have more than enough confidence to start hacking the code right now. I think this speaks very positively about literate programming. What remains to be seen is how much (or not) I'm going to practice it in the future. What do you think of marginalia? It's a bit the reverse of tangle; it assembles all those 70's files together into this book you might want to read. Is it sound or not? Have your thoughts changed from what you wrote in [1]? [1] http://goo.gl/cXWzF -- 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: Literate programming
I would gladly pay for such a thing to materialize on my screen; if it only took money to get that, I'm sure we'd all be willing to finance such an effort however we can. On Thursday, October 27, 2011 1:58:52 PM UTC-4, TimDaly wrote: So imagine a world where the eloquence of Rich Hickey was expressed in book form. Imagine the whole immutability lecture written down and decorated with the actual running code as illustration. Imagine that the original authors clearly explained software transactional memory and illustrated it with the actual code. Imagine a discussion of argument destructuring with running code illustrations. How many more people would be able to dive into the details of Clojure to maintain and modify the code? How many people would find it much easier to understand prototypes, defrecords, macros, and all of the other struggles that populate the current email forums? How are infinite sequences supported and what code supports it? What does NIL mean and why was it defined that way? We do not capture the ideas. We do not rewrite the explanations to clarify the fine points of confusion. We do not illustrate how the ideas of Red-Black tries are moved from ideas to implementation. We do not communicate the ideas to each other. We code for the machine. ... Now imagine that the book is multimedia where you can include animation (watch the tree balance), video, and a running REPL. Think Khan Academy for Clojure. This community is willing to overthrow the traditional ideas of lisp in order to make progress on a new path. Yet we continue to structure the development as though we worked on a PDP 11/40 with 4k file size limits. We continue to let the most valuable information which is the meat of Clojure disappear while we keep only the code, the bones of Clojure. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: [ANN] dj 0.1.0 released
I'll add this context: https://github.com/bmillare/dj dj takes the cacaphony of java, git, clojure, and build tools and mixes it into something harmonious. In a nutshell, dj is an attempt to make a clojure distribution. Like leiningen and maven, dj resolves dependencies, however, dj tries to be more like debian's APT or gentoo's portage and provide tools to manage your projects as if it were a part of a larger ecosystem of repositories, configuration files, jar files, project sources, and native dependencies. -- 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
Adding ClojureScript support to a noir-based project
For what it may be worth to you: In trying out the Noir framework (which neatly assembles ring+compojure+hiccup+other stuff) for its new bindings to ClojureScript (using noir-cljs and pivot), I thought some people might like to see what kind of diff is needed to add basic ClojureScript support to a noir project. Here goes the diff on GitHub: http://goo.gl/oJjkI Note that for now, I haven't yet written a single line of ClojureScript; but if you launch the server in simple/advanced mode, you'll already be able to observe that the generated .js file is already different. In advanced compilation, it's empty. In simple compilation, it contains a few KBs of Javascript code. Since my project on GitHub is very much at its infancy for now, you might like to browse its few lines of code to see how Noir expects you to code a (very) basic website. For more information on Noir, visit its website; it's been updated by the author with nice examples. Mentioned: - Noir: http://www.webnoir.org/ - Noir-cljs: https://github.com/ibdknox/noir-cljs - Pinot (not demonstrated in my diff): https://github.com/ibdknox/pinot -- 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
Feedback on the name of a new project
I'm starting development on a new product with eventual commercial possibilities. This project should be very polyglot-language based, but put clojure to the forefront. I'm trying to find a name that doesn't appear too much in Google and doesn't necessarily mean anything, and whose d*main is available. Since I'm not natively English/American, I wanted to ask your feedback on the following names, just to be sure they don't fall in the category of bad names. Oranyko Oranko Ceasel Ceasle Thank you, And sorry for the a bit out-of-topic question. BTW if I ever make money out of this project, I'll definitely pass some %s with Rich :) --~--~-~--~~~---~--~~ 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: Feedback on the name of a new project
Nevermind, I found something better that I know will be nice. On Jul 20, 5:09 pm, Daniel Jomphe danieljom...@gmail.com wrote: I'm starting development on a new product with eventual commercial possibilities. This project should be very polyglot-language based, but put clojure to the forefront. I'm trying to find a name that doesn't appear too much in Google and doesn't necessarily mean anything, and whose d*main is available. Since I'm not natively English/American, I wanted to ask your feedback on the following names, just to be sure they don't fall in the category of bad names. Oranyko Oranko Ceasel Ceasle Thank you, And sorry for the a bit out-of-topic question. BTW if I ever make money out of this project, I'll definitely pass some %s with Rich :) --~--~-~--~~~---~--~~ 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 at LispNYC tonight 7pm
I second this suggestion to add the video to clojure.blip.tv. It felt very awkward in 2009 to have to download this thing instead of stream it. :) I just watched it and wanted to say it's a very nice show of Clojure's Java interop in practice. Congrats to Stuart. It was also very nice to learn the history behind some of Stuart's contribs. Now, I think it would be very great for Stuart to present this again, but this time to a java audience, and put that too on blip. On Jun 16, 11:10 am, Paul Stadig p...@stadig.name wrote: On Wed, Jun 10, 2009 at 11:37 AM, Stuart Sierra the.stuart.sie...@gmail.com wrote: On Jun 9, 10:32 am, Stuart Sierra the.stuart.sie...@gmail.com wrote: Join us Tuesday, June 9 from 7:00-9:00 for Stuart Sierra's presentation: Implementing AltLaw.org in Clojure Slides and video here:http://lispnyc.org/wiki.clp?page=past-meetings We'll try to get something lighter than a 3GB mpeg soon. -Stuart I watched this video. Thanks for posting it! There is some great information in there, especially the from the trenches tips about working with Java libraries. Since you're one of the more active contributors to Clojure, would it be appropriate to post the video to clojure.blip.tv? 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 -~--~~~~--~~--~--~---
Article on Dispatch
I think the following article I wrote may help properly understanding dispatch. I submit here for your pleasure/review. First paragraph: I believe multiple dispatch is known to be hard to understand. When I first read about it, for some reason, it took me quite a lot of thinking before I really understood it all. Now that I understand it very well, I find it odd that it felt so challenging at the time. For this reason, I wanted to try putting an end to this nonsense. There’s probably other articles out there that explain it very well today. In any case, here’s my take. As usual with me, it’s pretty wordy: I like to surround that kind of knowledge with lots of useful observations. http://danieljomphe.github.com/2009/06/18/understanding-function-dispatch.html --~--~-~--~~~---~--~~ 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: What books have helped you wrap your brain around FP and Clojure?
I second most of the book suggestions already mentioned (those that I've read). If you like reading papers, I strongly suggest you take a look at Can Programming Be Liberated from the von Neumann Style?: http://www.stanford.edu/class/cs242/readings/backus.pdf This paper will help you with two things: 1. Motivation to investigate deeper FP; 2. Understanding many core concepts of FP. If you read this paper, I strongly suggest you schedule some time to read at least the first 12 pages of his lecture. The first 7 pages will shed out more light on what’s wrong with imperative languages; then, the next pages will explain how a language can be implemented on top of a very small number of sound and simple concepts that can be used and powerfully combined in all sorts of natural ways to describe computations. (Although it could be argued that some of this paper's ideas go even further than our current FP languages do, they won't hinder your understanding at all.) If you'd like to read about Backus' contribution to our field, I think these are the best links: http://en.wikipedia.org/wiki/John_Backus http://theory.stanford.edu/~aiken/other/backus.pdf http://www-03.ibm.com/ibm/history/exhibits/builders/builders_backus.html Another paper which helped me understand FP in relation with maths is Recursion Equations As A Programming Language. Last time I checked (Jan.), this paper was still not freely available on the web; but you can read most of its message through Google Books. It's a much easier read than Backus, but less complete; nonetheless, it's really, really highly recommended because it's complementary. Next, I've seen the following mentioned in quite a few places, and I think the general opinion is that it's also high-quality stuff. I'm yet to read it. Why Functional Programming Matters: http://www.cs.chalmers.se/~rjmh/Papers/whyfp.html Now, one might argue these papers' goal is more to introduce/motivate FP over traditional imperative programming. I would oppose to this that in order to back FP, these papers need to explain FP in very powerful terms for people; thus, they are great reads for the problem at hand. On Jun 8, 11:10 am, Daniel Lyons fus...@storytotell.org wrote: On Jun 8, 2009, at 7:24 AM, Nathan Hawkins wrote: The syntax and message passing emphasis aren't relevant to Clojure I don't have any experience with agents in Clojure, but I wonder if they be used to similar effect? Agents seem more like data in another thread to me than self-recursive functions in another thread, which is what Erlang's processes are like, but your remark piques my curiosity. Can one be implemented trivially via the other? — Daniel Lyonshttp://www.storytotell.org-- Tell It! --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Optimizing cross-product mappings
I need to generate a list of all possible American zipcodes, MD5- digested. Later on, I will need to do much more involving stuff, processor-wize, with this. But already, generating a naive list of all possible zipcodes is taking quite a deal of time: user (time (dorun (take 100 (all-zips Elapsed time: 3294.478 msecs nil user (time (dorun (take 100 (all-zips-MD5 Elapsed time: 28150.076 msecs nil If I allow the whole all-zips to be realized, it takes nearly 1 hour. I have tried a few optimizations, but before proceeding any further with it, I wondered if you'd have any advice re: idiomatic clojure and optimization. Here's my code: (defn all-zips-MD5 [] Returns a lazy list of all possible American zipcodes, as MD5 digests. (let [digester (java.security.MessageDigest/getInstance MD5)] (map (fn [to-digest] (.update digester (.getBytes to-digest)) (String. (.digest digester))) (all-zips (defn all-zips [] Returns a lazy list of all possible American zipcodes. (let [zips5(zip-formatted-range 5) zips4(zip-formatted-range 4) cross-prod-zips4 (fn [zip5] (map #(str zip5 - %) zips4)) zips5-4 (mapcat cross-prod-zips4 zips5)] (concat zips5 zips5-4))) (defn zip-formatted-range [n-digits] Returns a lazy list of stringified numbers, which are pre-padded with zeroes, starting from 0 and going up to the max number that can be represented with a number of digits of n-digits. Thus, if n-digits is 3, it will produce [001, 002, ... 999]. (let [zip-formatter #(format (str %0 n-digits d) %) n-to-format (Math/pow 10 (dec n-digits)) n-max (Math/pow 10 n-digits)] (concat (map zip-formatter (take n-to-format (range n-max))) (map str (drop n-to-format (range n-max)) --~--~-~--~~~---~--~~ 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: Silly question from Programming Clojure
I support the CTMCP recommendation. I learned a lot from its first few hundred pages. (Kept the rest for later.) On Jun 5, 2:45 am, Laurent PETIT laurent.pe...@gmail.com wrote: I just got my own copy of the CTM book (Concepts, Techniques and Models of computer programming) (http://www.info.ucl.ac.be/~pvr/book.html) and from now on I find it very interesting in introducing all these notions (variable, value, binding, etc.) one step after the other, showing how the different programming models / programming paradigms relate to each other, complement themselves, etc. I encourage you to get your own copy. --~--~-~--~~~---~--~~ 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: Optimizing cross-product mappings
Thanks for your replies. Sean: Type-hinting the String didn't help. And for some reason, defn'd function is 1.5x slower than my anonymous one. Daniel: Thanks for the info. Once my algorithms are fine (if they can get finer), I'll definitely narrow down the zips5 seed, and use your suggested MD5 digester. Stuart: user (time (dorun (take 100 (for [x (range 9), y (range )] (format %05d-%04d x y) Elapsed time: 95470.891 msecs :( That's probably because my version makes sure 'format' is called only when there's a need for padding with leading zeros. All: I forgot to mention that the only function I need to optimize at this point is 'all-zips' (sorry), because 'zip-formatted-range' is instantaneous, and 'all-zips-MD5's performance depends solely on the MD5 digester used and 'all-zips'. My bottleneck is thus definitely 'all-zips'. Do you think this code should run as slow in a purely imperative, traditional Java solution? Is there something functional I should sacrifice for bloated iterative code? --~--~-~--~~~---~--~~ 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: Optimizing cross-product mappings
Stuart, I took a second look at your suggestion. I integrated it directly in my code, which became much more elegant as a direct consequence. :) And it's a tiny, tiny little bit faster too. :) (defn all-zips [] Returns a lazy list of all possible American zipcodes. (let [zips5 (zip-formatted-range 5) zips4 (zip-formatted-range 4) zips5-4 (for [x zips5, y zips4] (str x - y))] (concat zips5 zips5-4))) It definitely looks simpler. So my question becomes: is there a faster way than using 'for'? I suppose not. Well, we've achieved ~71% optimization, which is already quite good, thank you all. On Jun 5, 11:17 am, Stuart Sierra the.stuart.sie...@gmail.com wrote: On Jun 5, 10:56 am, Daniel Jomphe danieljom...@gmail.com wrote: I need to generate a list of all possible American zipcodes, MD5- digested. Later on, I will need to do much more involving stuff, I'm not sure if this is exactly what you want, but maybe this will help: (defn all-zipcodes [] (for [x (range 1 9), y (range 1 )] (format %05d-%04d x y))) -Stuart Sierra --~--~-~--~~~---~--~~ 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: Optimizing cross-product mappings
You guessed mostly right, Daniel :) This guy hashed some fields of his client's database, replacing the original content with its hashed version. I don't know everything, but he at least obfuscated the addresses. He (and the client who asked to encrypt with MD5) thought he was actually encrypting the data. : And both didn't keep any backup. And there's lots of important data implied. That's indeed a very, very funny story. At least on my side of the story, since my ass is not on stake here :) On Jun 5, 12:43 pm, Daniel Lyons fus...@storytotell.org wrote: Daniel, I guess I have to ask... why do you need to do this in the first place? :) Zip codes are already unique. Are you searching through data where someone else MD5'd some zip codes to obfuscate them? Just curious. — Daniel Lyonshttp://www.storytotell.org-- Tell It! --~--~-~--~~~---~--~~ 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: Concerns About Pushing Clojure 1.0.0 to Maven Central Repo?
Laurent PETIT wrote: On 8 Mai, 01:39, Laurent PETIT laurent.pe...@gmail.com wrote: note that clojure must be compatible with JDK 1.5, so if you compile with 1.6, maybe you should verify the compatibility mode (not sure if what I write here makes sense, I'm not a specialist in javac retrocompatibility concerns). Compiling with javac -target=1.5 should also work, though. I read somewhere an authoritative article that mentioned the only way to produce 100% compatible bytecode is to compile using the proper jvm version. They explicitly mentioned 1.6 compiling with a target of 1.4 or 1.5 wouldn't produce 100% compatible byte code for these platforms. Sadly, I don't remember the explanation, though. :\ In any case, that's good to keep in our minds for future work. --~--~-~--~~~---~--~~ 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 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: The Path to 1.0
Daniel Jomphe wrote: Rich Hickey wrote: I don't mind the build producing clojure-1.0.0.jar etc, but it doesn't now. The master build is Ant. Where is the best place to put the version info so it can be leveraged by Ant, Maven and the clojure core runtime in order to produce *clojure-version* ? What changes are needed to the build scripts to produce version- numbered jars? Since Java is so much geared towards properties files, I suppose a version.properties file would ease integration with each build tool. *Ant* could easily fetch what it needs from the props file. Not sure how one does it though. *Maven*: if I remember well from my experience, the version of the maven artifact couldn't be populated dynamically. If it could, the props file would be one of the closest things to help make it work. *Clojure runtime* could easily populate its *clojure-version* on startup from the props file. That said, if the dynamic fetching from a props file approach isn't workable, an easier approach would be filling a few holes on pre-build time, using a script that calls to a template engine like StringTemplate, to inject the version as needed, where needed. Of course, this sounds ugly, especially considering it would be alien to automated tools like IDEs and etc. Let's hope someone knows better than I do. BTW, the most common approach I've seen to this problem is capitulate; let's just manually hard-code the version in the three places; anyways, we won't have to change it often. --~--~-~--~~~---~--~~ 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 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: The Path to 1.0
Laurent PETIT wrote: I have not followed maven2 concerning this qualifier thing. Right. The first (small) part of my post, which referred to yours, was strictly about versioning, and specifically about the end of the version string, related to snapshots. Then I addressed the classifier as another subject, which is more related to build management. Would it be corrrect to say that, to further extend you examples, one the qualifiers could be slim, since clojure ant already has such a target. Or would a slim jar of clojure have to had another artifactId ? (I don't think so, but I ask to be certain of that) I believe the correct approach would indeed have slim as a classifier, because slim is an hybrid of the default classifier (.java files as bytecode only) and of the source classifier (.clj files). That fits in the original definition of classifier: The classifier allows to distinguish artifacts that were built from the same POM but differ in their content. Thus, due to clojure's way of bundling AOT-compiled bytecode and/or clojure data structures as code, I believe it makes sense to introduce a new conventional classifier which is alien to purely java-based projects but makes sense to clojure projects. Following this, a conventional maven packaging of clojure would yield the following: clojure-1.0.0-snapshot.jar clojure-1.0.0-snapshot-slim.jar clojure-1.0.0-snapshot-javadoc.jar clojure-1.0.0-snapshot-sources.jar Now, let's suppose we really don't care about the javadoc-only packaging. Upon official release: clojure-1.0.0.jar clojure-1.0.0-slim.jar clojure-1.0.0-sources.jar clojure-1.0.1-snapshot.jar clojure-1.0.1-snapshot-slim.jar clojure-1.0.1-snapshot-sources.jar clojure-1.1.0-snapshot.jar clojure-1.1.0-snapshot-slim.jar clojure-1.1.0-snapshot-sources.jar Howard has already done this for the snapshot of 1.0.0, but he versioned it 1.0: http://tapestry.formos.com/maven-snapshot-repository/org/clojure/clojure-lang/1.0-SNAPSHOT/ --~--~-~--~~~---~--~~ 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 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: The Path to 1.0
Paul Stadig wrote: Others have commented on the whole groupId, artifactId, etc., etc. But in terms of the parts of the version number, they are named major.minor.incremental-qualifier as documented here: http://www.sonatype.com/books/maven-book/reference/pom-relationships-... Thanks for the info. So I was wrong in two ways: 1. There's in fact a convention for version strings: M.m.i-qualifier 2. The string SNAPSHOT may appear anywhere inside the version string. Keeping SNAPSHOT at the end and adding a rc1 qualifier, to illustrate: version: 1.0.0-rc1-SNAPSHOT yields: clojure-1.0.0-rc1-snapshot.jar (and ...-slim.jar, ...-sources.jar) --~--~-~--~~~---~--~~ 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 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: The Path to 1.0
Laurent PETIT wrote:
version: 1.0.0-rc1-SNAPSHOT
yields: clojure-1.0.0-rc1-snapshot.jar
(and ...-slim.jar, ...-sources.jar)
There it is. But why having snapshot in the name of the jar,
shouldn't it just be SNAPSHOT (as far as I remember) ?
That is:
{ :major 1 :minor 0 :incremental 0-rc1-SNAPSHOT }
gives version: 1.0.0-rc1-SNAPSHOT
yields: clojure-1.0.0-rc1-SNAPSHOT.jar
(and ...-slim.jar, ...-sources.jar)
The snapshot was a shortened version of the reality, for example:
20090222.174152-1
So in reality, snapshot packages look like:
clojure-1.0.0-rc1-20090222.174152-1.jar
Even though, when we add clojure as a dependency of some project, we
will ask for the version 1.0.0-rc1-SNAPSHOT.
See
http://tapestry.formos.com/maven-snapshot-repository/org/clojure/clojure-lang/1.0-SNAPSHOT/
--~--~-~--~~~---~--~~
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
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: The Path to 1.0
Laurent PETIT wrote: I'd suggest calling :release something else, like :revision or :patch. I like the term service used in Eclipse terminology: the service segment indicates bug fixes (The numbering scheme for Eclipse uses major, minor, service and qualifier : the qualifier segment indicates a particular build). And let's not forget _feu_ Sun's terminology: update, as in Java 6 update 14, which really means 1.6.14. :) Now, personally, what sounds the best in my ears is revision. There's of course yet more possibilities: http://en.wikipedia.org/wiki/Software_versioning --~--~-~--~~~---~--~~ 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 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: The Path to 1.0
Rich Hickey wrote: I'm unfamiliar with the POM version coordinate system - any hints? Maven takes the version as whatever-formatted string, but recognizes a conventional (.endsWith 1.0.0-SNAPSHOT -SNAPSHOT), like described by Laurent PETIT. So whatever-SNAPSHOT means we're going someday to release version whatever, and this is our most recent snapshot of its edge development. But that's not all that has been mentioned in this thread re: maven conventions. A release is uniquely identified by a few attributes: groupId:artifactId:packaging:classifier:version The classifier part has alson been mentioned. From maven's doc: --- The classifier allows to distinguish artifacts that were built from the same POM but differ in their content. It is some optional and arbitrary string that - if present - is appended to the artifact name just after the version number. As a motivation for this element, consider for example a project that offers an artifact targeting JRE 1.5 but at the same time also an artifact that still supports JRE 1.4. The first artifact could be equipped with the classifier jdk15 and the second one with jdk14 such that clients can choose which one to use. Another common use case for classifiers is the need to attach secondary artifacts to the project's main artifact. If you browse the Maven central repository, you will notice that the classifiers sources and javadoc are used to deploy the project source code and API docs along with the packaged class files. --- Lots of java libraries are distributed thusly: (1) org.clojure:clojure:jar:1.0.0 (no classifier) (2) org.clojure:clojure:jar:javadoc:1.0.0 (3) org.clojure:clojure:jar:sources:1.0.0 So 1 is bytecode release; 2 is only javadoc; 3 is full sources w/o bytecode. Of course, javadoc is also included in the sources release (3). Hope this answered your question, and more, if needed. --~--~-~--~~~---~--~~ 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 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: The Path to 1.0
Overall, I'm getting feature requests (more change!) and not a strong drive for 1.0 stability. If you feel otherwise, please speak up. Otherwise, my conclusion is that 1.0 may be more important for not-yet- users wary of working from source. My thought was that I very much like that you don't have to bother too much with: * release-quality documentation * release-quality tests (because you obviously didn't need them much until now) * release planning * release press coverage, interviews such ...so that you can continue improving our baby as fast as you're used to. Therefore, if you can find a way to fit in the former without hindering you too much for the latter, I'm 100% supporting for a 1.0 cut. Why? Because I've heard quite a few business deciders mention that we're waiting for a 2.0 release. Consequently, I think it would be great to see a 1.0 release today so that we can see a 2.0 release sooner than later. :) But not at the cost of your ability to thrive at clojure's development. That said, I'm definitely dedicating more and more of my time to clojure. I'm willing to help with the former (doc tests, as soon as I'm ready) to help you focus on the latter. For this reason, although I would prefer that clojure's tests be part of the core not the contrib, I understand that it suits you better like it is for now, and I support that. The same could be said of all the other issues that have been mentioned, as long as they help you focus. Whatever you decide, I'll definitely support your call. Finally, the only thing that I ask of you, in support to Luc Préfontaine, is for you to write up some priorities for us to help you better. --~--~-~--~~~---~--~~ 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 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: getting code coverage into clojure-contrib builds?
Stuart Halloway wrote: I will go and bug the emma folks, but first wanted to ask here if there is any specific reason that Clojure-generated bytecode might surprise emma? I might be totally wrong, but from what I've heard, Emma's development has stopped a few years ago and it doesn't support some Java 5 features, including annotations. A quick search seems to confirm the development has stopped scenario, at the very least. That said, I know cobertura is used successfully nowadays in java projects; it also works at the bytecode level. --~--~-~--~~~---~--~~ 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 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: DISCUSS: tests that read and write files
Stuart Halloway wrote: concerns: (1) Would like to see the file after a failed test. (2) [...] I would be much more comfortable not having to rely on code to write the file first. Doesn't feel like a unit test. But I am much more interested in having a shared approach that all contrib users adhere to than in getting my way. :-) Why not: (binding [*tmp-properties-file* (File/createTempFile temp .properties)] (.deleteOnExit *tmp-properties-file*) (spit *tmp-properties-file* contents of the test file) ...) ...wrapped in whatever macro if need be. Re: your (1): this way, you'll see it; it will be deleted when the jvm shuts down. Re: your (2): I personally wouldn't mind if we rely on contrib/spit as long as it's tested itself. :) --~--~-~--~~~---~--~~ 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 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: New release of the enclojure plugin is up.
CuppoJava wrote: I'm just wondering if anyone who's tried this and the IntelliJ plugin can comment on how they compare. I'm wondering if Enclojure has some basic s-exp functions, like Surround-With-(). For different reasons, I've been constantly switching between NetBeans, IntelliJ and Eclipse for clojure development in the last few days. Thus, I'm somewhat proficient with them, though I master none. Eclipse and NetBeans have both very recently seen new releases of their clojure plugins that brought many improvements to the table. Unless I missed some documentation, IntelliJ's plugin is the one that features the less support of clojure's lispy features, including sexps and repl. And it appears to be the least documented. Eclipse has, by far, the best syntax highlighting and the best keyboard bindings behavior, although there's only a few such bindings available for now. NetBeans is almost on par with Eclipse for its keyboard bindings. Namely, it features a bit more bindings, which behave a bit less well. Most of all, Enclojure features, and by far, the best repl interactions. Overall, I think Enclojure is the best offering as of today. And I wouldn't be surprised if it kept its pole position for quite a long time. That said, these plugins are still far from the usability of SLIME with paredit; but I wouldn't be surprised to see some of them outweigh them in a not too distant future. In reading my opinions, please remind yourself I'm no expert user of anyone of these plugins - I have only a few days worth of shared usage under my belt. --~--~-~--~~~---~--~~ 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 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: How do you handle different string encodings?
I finally worked it all out. For future reference, here's a record of my research on this: http://stackoverflow.com/questions/715958/how-do-you-handle-different-string-encodings Daniel Jomphe wrote: I made some progress. [By the way, NetBean's console displays *everything* 100% fine. I decided to use one of the worst repl consoles: that of IntelliJ. I want to make sure I really understand what's the point behind all this.] (import '(java.io PrintWriter PrintStream FileInputStream) '(java.nio CharBuffer ByteBuffer) '(java.nio.charset Charset CharsetDecoder CharsetEncoder) '(org.xml.sax InputSource)) (def utf8 UTF-8) (def d-utf8 (.newDecoder (Charset/forName utf8))) (def e-utf8 (.newEncoder (Charset/forName utf8))) (def latin1 ISO-8859-1) (def d-latin1 (.newDecoder (Charset/forName latin1))) (def e-latin1 (.newEncoder (Charset/forName latin1))) (defmacro with-out-encod [encoding body] `(binding [*out* (PrintWriter. (PrintStream. System/out true ~encoding) true)] ~...@body (flush))) (def s québécois français) (print s) ;quÔøΩbÔøΩcois franÔøΩaisnil (with-out-encod latin1 (print s)) ;qu?b?cois fran?aisnil (with-out-encod utf8 (print s)) ;qu?b?cois fran?aisnil (def encoded (.encode e-utf8 (CharBuffer/wrap québécois français))) (def s-d (.toString (.decode d-utf8 encoded))) (print s-d) ;quÔøΩbÔøΩcois franÔøΩaisnil (with-out-encod latin1 (print s-d)) ;qu?b?cois fran?aisnil (with-out-encod utf8 (print s-d)) ;qu?b?cois fran?aisnil (def f-d (:content (let [x (InputSource. (FileInputStream. french.xml))] (.setEncoding x latin1) (clojure.xml/parse x (print f-d) ;quÔøΩbÔøΩcois franÔøΩaisnil (with-out-encod latin1 (print f-d)) ;québécois français (with-out-encod utf8 (print f-d)) ;québécois français So my theory, which is still almost certainly wrong, is: 1. When the input is a file whose encoding is, say, latin-1, it's easy to decode it and then encode it however one wants. 2. When the input is a literal string in the source file, it looks like it's impossible to encode it correctly, unless one first decodes it from the source file's encoding. But then, I don't yet know how to do this without actually reading the source file. :\ Daniel Jomphe wrote: I tried under eclipse. Default console encoding configuration (MacRoman): #'user/s quÔøΩbÔøΩcois franÔøΩaisnil qu?b?cois fran?aisnil #'user/snc qu?b?cois fran?aisnil qu?b?cois fran?aisnil Console configured to print using ISO-8859-1: #'user/s qu�b�cois fran�aisnil qu?b?cois fran?aisnil #'user/snc qu?b?cois fran?aisnil qu?b?cois fran?aisnil Console configured to print using UTF-8: #'user/s québécois françaisnil québécois françaisnil #'user/snc québécois françaisnil québécois françaisnil So as I come to understand it, it looks like UTF-8 should be the rolls- royce for my needs. May I correctly conclude the following? Don't bother about encodings unless you're displaying something and it's unreadable; then, don't bother about it in the code; find a proper console or viewer. Doesn't that sound like offloading a problem to users? Isn't there something reliable that can be done in the code? Daniel Jomphe wrote: Sorry for all these posts. I pasted my last post's code into a fresh repl (not in my IDE), and here's what I got (cleaned up): #'user/s québécois françaisnil qu?b?cois fran?aisnil #'user/snc québécois françaisnil qu?b?cois fran?aisnil I'm not sure what to make out of it. My terminal (Apple Terminal) supports the encoding, and prints correctly s and snc out of the box. When I use with-out-encoded, I actually screw up both s and snc's printing. Daniel Jomphe wrote: Now that I know for sure how to bind *out* to something else over System/out, it's time to bring back my encoding issues into scope: (import '(java.io PrintWriter PrintStream)) (defmacro with-out-encoded [encoding body] `(binding [*out* (java.io.PrintWriter. (java.io.PrintStream. System/out true ~encoding) true)] ~...@body (flush))) (def nc ISO-8859-1) ;;; with a normal string (def s québécois français) (print s) ; quÔøΩbÔøΩcois franÔøΩaisnil (with-out-encoded nc (print s)) ; qu?b?cois fran?aisnil ;;; with a correctly-encoded string (def snc (String. (.getBytes s nc) nc)) (print snc) ; qu?b?cois fran?aisnil (with-out-encoded nc (print snc)) ; qu?b?cois fran?aisnil I'm certainly missing something fundamental somewhere
Re: How do you print to standard output without using *out*?
Since I can't find the way to solve this issue, let's tackle it at a more fundamental level. First, I need to make sure I can print to standard output without using *out*, so I can later, temporarily bind *out* to something else. Also, I don't want to print directly to System/out. Later, I'll need it to be wrapped into something that gives it a proper encoding. user= (import '(java.io PrintWriter PrintStream)) nil user= (.print (PrintWriter. (PrintStream. System/out) true) bonjour) nil Do you know how to make this work? Daniel Jomphe wrote: Let's say I have this file to parse: ?xml version=1.0 encoding=ISO-8859-1? rootQuébécois français/root I spent many hours trying different ways of doing it, but still haven't found one. Here are probably my best attempts: (def n ISO-8859-1) (defmacro with-out-encoded [encoding body] `(binding [*out* (java.io.OutputStreamWriter. System/out ~encoding)] ~...@body)) (:content (clojure.xml/parse french.xml)) ; [Qu√©b√©cois fran√ßais] (with-out-encoded n (:content (clojure.xml/parse french.xml))) ; [Qu√©b√©cois fran√ßais] (with-out-encoded n (let [x (org.xml.sax.InputSource. (java.io.FileInputStream. french.xml))] (do (.setEncoding x n) (:content (clojure.xml/parse x) ; [Qu√©b√©cois fran√ßais] Some xml files appear different when I run them through these lines; this one does not. In all cases, though, I don't get what's really expected. How would go about it? --~--~-~--~~~---~--~~ 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 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: How do you print to standard output without using *out*?
Oh, somehow, auto-flushing doesn't work, and that's why I wasn't seeing anything else than nil: user= (def w (PrintWriter. (PrintStream. System/out) true)) #'user/w user= (.print w bonjour) nil user= (.flush w) bonjournil So although I asked for auto-flushing, I need to do so manually. Daniel Jomphe wrote: Since I can't find the way to solve this issue, let's tackle it at a more fundamental level. First, I need to make sure I can print to standard output without using *out*, so I can later, temporarily bind *out* to something else. Also, I don't want to print directly to System/out. Later, I'll need it to be wrapped into something that gives it a proper encoding. user= (import '(java.io PrintWriter PrintStream)) nil user= (.print (PrintWriter. (PrintStream. System/out) true) bonjour) nil Do you know how to make this work? --~--~-~--~~~---~--~~ 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 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: How do you print to standard output without using *out*?
Kyle Schaffrick wrote: Could you just make a new Var (like *always-stdout* or something) and assign *out* to it at program start? This way the dynamic bindings on *out* don't affect your new Var and you can continue using it to access the real stdout. As long as I'm willing to lose the convenience of (print string), I could. It might be advisable to do so instead of binding *out* in a with- macro like I did; I'm not sure if it's a bad idea or not. In any case, I think doing so wouldn't solve my encoding issues. --~--~-~--~~~---~--~~ 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 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: How do you handle different string encodings?
Now that I know for sure how to bind *out* to something else over System/out, it's time to bring back my encoding issues into scope: (import '(java.io PrintWriter PrintStream)) (defmacro with-out-encoded [encoding body] `(binding [*out* (java.io.PrintWriter. (java.io.PrintStream. System/out true ~encoding) true)] ~...@body (flush))) (def nc ISO-8859-1) ;;; with a normal string (def s québécois français) (print s) ; quÔøΩbÔøΩcois franÔøΩaisnil (with-out-encoded nc (print s)) ; qu?b?cois fran?aisnil ;;; with a correctly-encoded string (def snc (String. (.getBytes s nc) nc)) (print snc) ; qu?b?cois fran?aisnil (with-out-encoded nc (print snc)) ; qu?b?cois fran?aisnil I'm certainly missing something fundamental somewhere. --~--~-~--~~~---~--~~ 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 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: How do you handle different string encodings?
Sorry for all these posts. I pasted my last post's code into a fresh repl (not in my IDE), and here's what I got (cleaned up): #'user/s québécois françaisnil qu?b?cois fran?aisnil #'user/snc québécois françaisnil qu?b?cois fran?aisnil I'm not sure what to make out of it. My terminal (Apple Terminal) supports the encoding, and prints correctly s and snc out of the box. When I use with-out-encoded, I actually screw up both s and snc's printing. Daniel Jomphe wrote: Now that I know for sure how to bind *out* to something else over System/out, it's time to bring back my encoding issues into scope: (import '(java.io PrintWriter PrintStream)) (defmacro with-out-encoded [encoding body] `(binding [*out* (java.io.PrintWriter. (java.io.PrintStream. System/out true ~encoding) true)] ~...@body (flush))) (def nc ISO-8859-1) ;;; with a normal string (def s québécois français) (print s) ; quÔøΩbÔøΩcois franÔøΩaisnil (with-out-encoded nc (print s)) ; qu?b?cois fran?aisnil ;;; with a correctly-encoded string (def snc (String. (.getBytes s nc) nc)) (print snc) ; qu?b?cois fran?aisnil (with-out-encoded nc (print snc)) ; qu?b?cois fran?aisnil I'm certainly missing something fundamental somewhere. --~--~-~--~~~---~--~~ 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 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: How do you handle different string encodings?
I'm running on Mac. In IDE (IntelliJ): Java: Apple's 1.6 Clojure: LaClojure's version (I don't know) In Terminal: Java: Apple's 1.5.0_16 Clojure: 1338, 2009-04-01 Paul Stadig wrote: Works For Me (TM). user= (def s québécois français) #'user/s user= (print s) québécois françaisnil Are you running on Windows, Mac, or Linux? Using the Sun JVM? Which revision of Clojure? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com 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: How do you handle different string encodings?
I tried under eclipse. Default console encoding configuration (MacRoman): #'user/s quÔøΩbÔøΩcois franÔøΩaisnil qu?b?cois fran?aisnil #'user/snc qu?b?cois fran?aisnil qu?b?cois fran?aisnil Console configured to print using ISO-8859-1: #'user/s qu�b�cois fran�aisnil qu?b?cois fran?aisnil #'user/snc qu?b?cois fran?aisnil qu?b?cois fran?aisnil Console configured to print using UTF-8: #'user/s québécois françaisnil québécois françaisnil #'user/snc québécois françaisnil québécois françaisnil So as I come to understand it, it looks like UTF-8 should be the rolls- royce for my needs. May I correctly conclude the following? Don't bother about encodings unless you're displaying something and it's unreadable; then, don't bother about it in the code; find a proper console or viewer. Doesn't that sound like offloading a problem to users? Isn't there something reliable that can be done in the code? Daniel Jomphe wrote: Sorry for all these posts. I pasted my last post's code into a fresh repl (not in my IDE), and here's what I got (cleaned up): #'user/s québécois françaisnil qu?b?cois fran?aisnil #'user/snc québécois françaisnil qu?b?cois fran?aisnil I'm not sure what to make out of it. My terminal (Apple Terminal) supports the encoding, and prints correctly s and snc out of the box. When I use with-out-encoded, I actually screw up both s and snc's printing. Daniel Jomphe wrote: Now that I know for sure how to bind *out* to something else over System/out, it's time to bring back my encoding issues into scope: (import '(java.io PrintWriter PrintStream)) (defmacro with-out-encoded [encoding body] `(binding [*out* (java.io.PrintWriter. (java.io.PrintStream. System/out true ~encoding) true)] ~...@body (flush))) (def nc ISO-8859-1) ;;; with a normal string (def s québécois français) (print s) ; quÔøΩbÔøΩcois franÔøΩaisnil (with-out-encoded nc (print s)) ; qu?b?cois fran?aisnil ;;; with a correctly-encoded string (def snc (String. (.getBytes s nc) nc)) (print snc) ; qu?b?cois fran?aisnil (with-out-encoded nc (print snc)) ; qu?b?cois fran?aisnil I'm certainly missing something fundamental somewhere. --~--~-~--~~~---~--~~ 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 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: How do you handle different string encodings?
I made some progress. [By the way, NetBean's console displays *everything* 100% fine. I decided to use one of the worst repl consoles: that of IntelliJ. I want to make sure I really understand what's the point behind all this.] (import '(java.io PrintWriter PrintStream FileInputStream) '(java.nio CharBuffer ByteBuffer) '(java.nio.charset Charset CharsetDecoder CharsetEncoder) '(org.xml.sax InputSource)) (def utf8 UTF-8) (def d-utf8 (.newDecoder (Charset/forName utf8))) (def e-utf8 (.newEncoder (Charset/forName utf8))) (def latin1 ISO-8859-1) (def d-latin1 (.newDecoder (Charset/forName latin1))) (def e-latin1 (.newEncoder (Charset/forName latin1))) (defmacro with-out-encod [encoding body] `(binding [*out* (PrintWriter. (PrintStream. System/out true ~encoding) true)] ~...@body (flush))) (def s québécois français) (print s) ;quÔøΩbÔøΩcois franÔøΩaisnil (with-out-encod latin1 (print s)) ;qu?b?cois fran?aisnil (with-out-encod utf8 (print s)) ;qu?b?cois fran?aisnil (def encoded (.encode e-utf8 (CharBuffer/wrap québécois français))) (def s-d (.toString (.decode d-utf8 encoded))) (print s-d) ;quÔøΩbÔøΩcois franÔøΩaisnil (with-out-encod latin1 (print s-d)) ;qu?b?cois fran?aisnil (with-out-encod utf8 (print s-d)) ;qu?b?cois fran?aisnil (def f-d (:content (let [x (InputSource. (FileInputStream. french.xml))] (.setEncoding x latin1) (clojure.xml/parse x (print f-d) ;quÔøΩbÔøΩcois franÔøΩaisnil (with-out-encod latin1 (print f-d)) ;québécois français (with-out-encod utf8 (print f-d)) ;québécois français So my theory, which is still almost certainly wrong, is: 1. When the input is a file whose encoding is, say, latin-1, it's easy to decode it and then encode it however one wants. 2. When the input is a literal string in the source file, it looks like it's impossible to encode it correctly, unless one first decodes it from the source file's encoding. But then, I don't yet know how to do this without actually reading the source file. :\ Daniel Jomphe wrote: I tried under eclipse. Default console encoding configuration (MacRoman): #'user/s quÔøΩbÔøΩcois franÔøΩaisnil qu?b?cois fran?aisnil #'user/snc qu?b?cois fran?aisnil qu?b?cois fran?aisnil Console configured to print using ISO-8859-1: #'user/s qu�b�cois fran�aisnil qu?b?cois fran?aisnil #'user/snc qu?b?cois fran?aisnil qu?b?cois fran?aisnil Console configured to print using UTF-8: #'user/s québécois françaisnil québécois françaisnil #'user/snc québécois françaisnil québécois françaisnil So as I come to understand it, it looks like UTF-8 should be the rolls- royce for my needs. May I correctly conclude the following? Don't bother about encodings unless you're displaying something and it's unreadable; then, don't bother about it in the code; find a proper console or viewer. Doesn't that sound like offloading a problem to users? Isn't there something reliable that can be done in the code? Daniel Jomphe wrote: Sorry for all these posts. I pasted my last post's code into a fresh repl (not in my IDE), and here's what I got (cleaned up): #'user/s québécois françaisnil qu?b?cois fran?aisnil #'user/snc québécois françaisnil qu?b?cois fran?aisnil I'm not sure what to make out of it. My terminal (Apple Terminal) supports the encoding, and prints correctly s and snc out of the box. When I use with-out-encoded, I actually screw up both s and snc's printing. Daniel Jomphe wrote: Now that I know for sure how to bind *out* to something else over System/out, it's time to bring back my encoding issues into scope: (import '(java.io PrintWriter PrintStream)) (defmacro with-out-encoded [encoding body] `(binding [*out* (java.io.PrintWriter. (java.io.PrintStream. System/out true ~encoding) true)] ~...@body (flush))) (def nc ISO-8859-1) ;;; with a normal string (def s québécois français) (print s) ; quÔøΩbÔøΩcois franÔøΩaisnil (with-out-encoded nc (print s)) ; qu?b?cois fran?aisnil ;;; with a correctly-encoded string (def snc (String. (.getBytes s nc) nc)) (print snc) ; qu?b?cois fran?aisnil (with-out-encoded nc (print snc)) ; qu?b?cois fran?aisnil I'm certainly missing something fundamental somewhere. --~--~-~--~~~---~--~~ 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 To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group
How do you parse xml files with different encodings?
Let's say I have this file to parse: ?xml version=1.0 encoding=ISO-8859-1? rootQuébécois français/root I spent many hours trying different ways of doing it, but still haven't found one. Here are probably my best attempts: (def n ISO-8859-1) (defmacro with-out-encoded [encoding body] `(binding [*out* (java.io.OutputStreamWriter. System/out ~encoding)] ~...@body)) (:content (clojure.xml/parse french.xml)) ; [Qu√©b√©cois fran√ßais] (with-out-encoded n (:content (clojure.xml/parse french.xml))) ; [Qu√©b√©cois fran√ßais] (with-out-encoded n (let [x (org.xml.sax.InputSource. (java.io.FileInputStream. french.xml))] (do (.setEncoding x n) (:content (clojure.xml/parse x) ; [Qu√©b√©cois fran√ßais] Some xml files appear different when I run them through these lines; this one does not. In all cases, though, I don't get what's really expected. How would go about it? --~--~-~--~~~---~--~~ 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 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: doseq vs. map
From map's docstring: Returns a lazy sequence [...] So I guess you applied map at the top level and wondered why side- effects didn't happen. Try: (dorun (map #(form-with-side-effects %) a-list)) Or, for fun: (take 1 (map #(form-with-side-effects %)) Basically, since your map wasn't needed, it wasn't realized/ executed. Laziness. Sean wrote: What I don't understand is why the doseq macro is required instead of the mapping operation. Could somebody explain why Clojure has this different form for functions that have side effects? --~--~-~--~~~---~--~~ 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 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: doseq vs. map
Daniel Jomphe wrote: Basically, since your map wasn't needed, it wasn't realized/ executed. Laziness. Better said: Basically, since your map's results weren't used, it wasn't realized/ evaluated. That's why you didn't see your expected side effects. Laziness. --~--~-~--~~~---~--~~ 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 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: rules for writing macros
Mark Volkmann wrote: I see from the feedback so far that my statements are wrong. However, I think it's true that there are *some* things you can do in a function that you cannot do in a macro, and perhaps vice-versa. Are those clearly documented anywhere? If not, what are some? You might be interested in the development of this thread: http://groups.google.com/group/clojure/browse_thread/thread/fa976abf80c91361/0019b33732f34e62 --~--~-~--~~~---~--~~ 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 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: Pretty printing a function's symbol
Michael Wood wrote: (defn with-test-report [test fn] You are shadowing clojure.core/fn here. Not a problem really, but perhaps it would be better to use a different name? Oh, and clojure.core/test. Oh, right! Didn't think of it this way; it might be misleading to any future reader, so I take note. (defn with-test-report [test fn] (let [assert# (first test) expect# (second test) params# (last test) result# (assert# expect# (apply fn params#))] I've seen various code snippets where people use something# in functions. Is there any point to this or gensym except in a macro? In another function, if I didn't gensym my let-bounds, they would interact with an outer lexical context, if I remember well. (Note that my observations at that time could have been totally wrong.) So I figured out that since `let` is a special form, it might have a different behavior than what I'm used to see in Common Lisp. Gensym- ing fixed my issues and since then I always do so for my let-bounds. I also have seen it in other people's code, but I only remember seeing it in `let` expressions (apart from macros, of course). It would great to hear the advice on that matter of someone more knowledgeable than I. Exception: Unable to resolve var: expect# in this context How about using a macro. e.g.: (defmacro with-test-report [tst f] `(let [pred#(first ~tst) pname# '~(first tst) expect# (second ~tst) params# (last ~tst) result# (pred# expect# (apply ~f params#))] (if result# (print .) (do (newline) (println (format FAIL: [%s %s] pname# params# result#)) nil user= (with-test-report [= 3 [1 3]] +) FAIL: [= [1 3]] false Cool! Even when experimenting with macros, it didn't work for me! Thank you Michael. I still wish I knew how to achieve this without resolving to macros. Macros are what seduced me towards lisp instead of, say, haskell, so my goal in learning any real lisp (Clojure here) is to try as hard as I can to not use macros so that I don't develop a bad habit of writing macros when obvious functions would have done the same job. This way, I'll really appreciate macros for their usefulness without fooling myself. When I'll have developed a good intuition about this, I'll of course loosen that rule. If anyone could chime in and tell me if macros are the only out of this problem, that would be really great. To simplify the problem to its essence, let's say I'd like, without using macros, the following to print better: (print (first [= 1 2])) #core$_EQ___2886 clojure.core$_eq___2...@830122 Hey, I just found out the following works: (print (first '(=))) = But in my previous (different) attempts, I couldn't make it work. Well, I may have found a good way to refactor out my issue. --~--~-~--~~~---~--~~ 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 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 -~--~~~~--~~--~--~---
Pretty printing a function's symbol
Hi, I'm learning Clojure by playing with a simple test toolkit: (fn-with-tests + [[= 2 [1 1]] [= 2 [1 1]] [= 2 [1 0]] [= 2 [2 0]]]) .. FAIL: [#core$_EQ___2886 clojure.core$_eq___2...@13d422d 2 [1 0]] . === Tests Done === Some tests FAILED! false As you can see, I want to report the vector that defined the failing test, but am annoyed with ='s internal representation. Here's what I tried to print a test failure: (println (format FAIL: %s (print-str (print-str (first test)) (rest test Do you know of something that would allow me to print the following instead? FAIL: [= 2 [1 0]] I tried (name ...) without avail. --~--~-~--~~~---~--~~ 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 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: Pretty printing a function's symbol
Daniel Jomphe wrote: What is (var ...)? I didn't find it in the api docs, nor in the Vars and Environment page. Sorry, I didn't search well enough; found it. Now, all I need is to understand why my use of (:name (meta (var expect#))) doesn't work. --~--~-~--~~~---~--~~ 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 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 -~--~~~~--~~--~--~---
Is 'every?' broken?
(defn print-arg [x] (let [result# x] (println (format [%s] result#)) result#)) (every? true? (map #(print-arg %) [true false true])) ; [true] ; [false] ;false (every? true? (to-array (map #(print-arg %) [true false true]))) ; [true] ; [false] ; [true] ;false I would have expected 'every?' to work the same way with lists as it works with arrays. --~--~-~--~~~---~--~~ 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 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: Is 'every?' broken?
wwmorgan wrote: map is lazy, but to-array is not. The output you are seeing is the result of to-array needing to realize every element of its collection. every? only applies its predicate to as many elements of its collection as are necessary. See the following: Thank you. This became my first conscious experience on laziness. I didn't need it until now (and still don't directly need it, although I can definitely how useful it can be). As of now, I have around 3 or 4 days worth of programming experience in languages that support laziness, although I have much more in unapplied theory. So the work to bridge the gap has started. I now see how the concept of laziness works well with pure functions. As soon as we use impure functions, the need arises to be conscious of laziness if our expected side effects are to be guaranteed. I'm definitely going to *love* purity and laziness. Very cool! This also confirms the detour I'm taking to learn Haskell isn't bad at all, since Haskell strongly emphasizes purity and laziness. I'll come back with great tools in my mind. Cheers to Rich for using laziness in Clojure's standard! --~--~-~--~~~---~--~~ 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 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: Yet another html templating library
Christophe Grand wrote: Therefore, this feels a bit misleading to me: this separates design from code even further. I just want to point out StringTemplate helps separating design from code, but its main goal is separating the View from Controller and Model in a formally strict way. In the case of enlive, this main goal is not achieved, so it couldn't be done even further. I think you both aren't talking about the same separation: - (To put it in MVC terms) Enlive separates the View into design (plain html, no extra tags, no $..$) and code (clj) - StringTemplate enforces a strict separation of the View from Model and Controller. Not really. What you perceived as such is because of my bad attempt at saying the following. The html-clj separation is completely distinct from StringTemplate's v- mc separation. Therefore, it feels a bit misleading to compare them using such relation as even further; it diverges one's thinking from either real goal of Enlive or S.T.: Enlive's real goal is, in the View, to separate design and code. In fact, Enlive looks really great here. And ST fares better on this aspect than most other templating libraries, but it's only one of the consequences of enforcing ST's real goal. If one thinks in terms of Enlive goes even further than ST at separating design from code, one might completely overlook the real goal of ST. ST's real goal is to separate the View from Model and Controller (VMC/ MVC). In my understanding, Enlive doesn't try to enforce this at all. Consequently, most projects using Enlive will feature intertwined VMC aspects in the code of their V, because it's really hard not to cross the line. Therefore, if one thinks in terms of Enlive goes even further than ST at separating design from code and thinks of design as V and code as MC, one will end up with a false conclusion. Now, I must confess that I kind of jumped on the issue because I had just read the paper and felt the phrase misleading. I might as well have let it like it is and nobody would have suffered much about it. :) This being said, I didn't doubt that Stuart's intention was to mean literally html-(code-in-the-view) separation. Sorry that it looked like that. --~--~-~--~~~---~--~~ 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 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: Yet another html templating library
Stuart Sierra wrote: Very interesting, Christophe. I've been playing with StringTemplate http://www.stringtemplate.org/ lately, but this separates design from code even further. Can it do conditionals, as in if this variable is true, includes this HTML element? ...and the following posts establishing that it can. Therefore, this feels a bit misleading to me: this separates design from code even further. I just want to point out StringTemplate helps separating design from code, but its main goal is separating the View from Controller and Model in a formally strict way. In the case of enlive, this main goal is not achieved, so it couldn't be done even further. So my point is we must understand your phrase in a biased way because it appears to be more separated from design, but is less in fact. Disclosure: I have no interest in StringTemplate, other than the fact I read its formal paper today. :) --~--~-~--~~~---~--~~ 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 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: post on test-is and testing styles
Stuart Sierra wrote: http://stuartsierra.com/2009/01/18/tests-are-code Comments welcome here or on the blog. That's funny Stuart; The question I asked about 'reduce' and 'and' was exactly for this purpose. The first programming exercise I gave myself to start learning Clojure was to build a testing toolkit from scratch. When you helped me, it was in fact for my implementation of... a with-test macro, with *exactly* the same behavior as yours. (Either with-test is big common sense, either we've both seen it somewhere else, although we may not necessarily remember seeing it.) I didn't write about my learning path on my blog or anywhere public because it's stuff I was doing at work and I'm waiting for some kind of permission before going public about this. Btw, my opinion is that it's much better to have unit tests written exactly beside their function in most cases. Thanks for your good work! --~--~-~--~~~---~--~~ 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 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: Macros in interaction with Functions
Stuart Sierra wrote: - The reader performs a few substitutions, then gives the resulting code to the compiler. - The compiler starts by expanding macros into their substitution. --- Thus, for functions, there's no such thing as macros. --- Thus, all that functions see of macros is what came out of macros' complete expansion. --- Therefore, like Timothy Pratley wrote so well, a function can have for parameter a macro call, but not a macro itself. All correct up to this point. - After macro expansion, the compiler starts compiling all functions in need of being compiled, including the functions modified during macro expansion. Sort of. What's really getting compiled are just the function calls. The functions themselves were compiled back when they were defined. Ok, so do we have: read = macro-expand = compile-definitions = compile-calls? So that when new code is read, if it contains function definitions, they'll get compiled before their call(s) is compiled? Stuart and Konrad respectively said: [...] and doesn't know how many arguments it's going to get. If you look at the definition of and, you'll see that it takes a variable number of arguments and it is recursive. So if you tried to expand it before knowing the length of the argument list, you would get an infinite loop. The universal workaround is to define a function that contains nothing but the macro, such as (fn [x y] (and x y)) which can also be written in Clojure using the shorthand notation #(and %1 %2) Ok!! So *that* would explain why wrapping 'and' *this* way enables it to be an argument to a function call in (reduce #(and % %2): it becomes clear how many args are going to be given to 'and's call. Wow, thanks for such clarity! --~--~-~--~~~---~--~~ 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 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: Macros in interaction with Functions
Stuart Sierra said: It's not covered much. You get used to it. Think of it this way -- macros only exist during compilation. Functions like apply get evaluated at run-time. A macro like and has no value at run-time, so you can't use it as an argument to a function. I'll tell you my current understanding of how Clojure works, so you can correct me where I may be wrong: - The compiler has for target a living environment; thus, it's dynamic. - There's no interpreter; thus, the following points will be easier to reason about. - When code is sent for evaluation, it's first read. - The reader performs a few substitutions, then gives the resulting code to the compiler. - The compiler starts by expanding macros into their substitution. --- Thus, for functions, there's no such thing as macros. --- Thus, all that functions see of macros is what came out of macros' complete expansion. --- Therefore, like Timothy Pratley wrote so well, a function can have for parameter a macro call, but not a macro itself. - After macro expansion, the compiler starts compiling all functions in need of being compiled, including the functions modified during macro expansion. - Then, code is ready for evaluation. Now, I see that (function macro arg-given-to-macro-by-function) can't work, because 'function', in its body, during its evaluation, would have to give 'arg-given...' to 'macro'; but since 'function' is a function, before eval was inside 'function's body, it needed to evaluate each one of 'function's parameters; thus, at this precise moment, 'macro' would have said hey, now that you're evaluating me, will you please give me my parameter?, and eval would have answered I can't, its 'function's responsibility, but we're not yet inside its body, and thus, eval would have blocked. Ok, so although it's a live system, when a new bunch of code is sent for evaluation, all macros inside it must be expanded before runtime evaluation can occur. Thus, functions can't act on macros. I thought that somehow my code could still work because what would have happened is 'reduce' would have acted on 'and's expansion, but I see and's expansion couldn't be done because it would have to wait for reduce's evaluation. If we were speaking of concurrency, wouldn't this be a deadlock issue? ...I also thought it could be possible that 'and' expands to a partial application that waits for 'reduce' to provide it its arguments. Wouldn't this make sense? Konrad Hinsen said: The universal workaround is to define a function that contains nothing but the macro, such as (fn [x y] (and x y)) which can also be written in Clojure using the shorthand notation #(and %1 %2) Here the macro gets expanded inside the function *body*, but what you pass around is the function *object*. Wouldn't this defeat the purpose of having 'and's arguments short- circuited when false is found? Now, why is this workaround possible? For sure, the wrapper function is ok as a parameter of a function call. And in the called function's body, when it's going to call the wrapper function, the arguments for the macro wrapped in the wrapper function will be ready. And the wrapper function contains the macro's substitution anyways. So if we're willing to sacrifice macros' lazy parameters evaluation, we can wrap them inside functions to achieve this effect. We could also say that as long as macros are either called or wrapped in any function, they can go anywhere. In other words, the only limitation seems to be that runtime code can't use the symbol to which a macro is binded. Phew, does this all make perfect sense? Chouser said: Is there anyway to write a macro/function that acts as a function when necessary (so it can be passed as an argument), but expands into a macro (for speed) when deemed possible? I don't think this is possible without some sort of support for a macro/function duality in core Clojure. Which is one way to describe what's provided by definline. It's marked experimental, has an unusual format and proviso's, but it's there get a blend of macro performance and function first-classness. Cool. Let's see how this develops. It's definitely interesting. ...All those years doing imperative programming, I knew I somehow wasn't doing what I really always wanted to do. ...Anyways, before I devote 100% of my programming time to macro-ed functional languages, I want to get rid of the imperative way of programming as much as possible, so I thought it might be good for me to do a small detour by learning Haskell before coming back full strength to Clojure and Qi +CL. If someone has any opinion about this, I'm all ears open. --~--~-~--~~~---~--~~ 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 To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options,
How to reduce a list of booleans?
I'm in the following situation: (and '(true true)) ;doesn't work I tried apply, reduce, and a few other things. Reading the apidocs, reduce is said to be the proper choice to compute a boolean from a seq. But: (reduce and '(true true)) ;Exception: Can't take value of a macro: #'clojure.core/and Also, the following isn't the solution: (reduce 'and '(true false true)) ;true In any case, I think using reduce with and wouldn't be nice because it won't return false as soon as it can like and does. Therefore, I came up with the following working solution: (defmacro and-booleans [logical-booleans-list] `(and ~...@logical-booleans-list)) (and-booleans (true false true)) ;false But I wonder if I have overlooked something fundamental, either about reduce or anything else. Of course, I could have built my final boolean value imperatively, in effect reimplementing and for lists as a function that wraps the ant built-in macro. But I'm hoping to leave imperative programming as much behing me as possible. What would you consider the normal way of solving this small problem of mine? --~--~-~--~~~---~--~~ 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 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: How to reduce a list of booleans?
(every? identity [true false true]) So obvious, yet so overlooked each time I read the function names in the api! Thanks to both you! Looks like I'll be having a bunch of fun through this learning curve in the future. :) --~--~-~--~~~---~--~~ 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 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: Erlang vs Clojure
On Dec 5 2008, Luc Prefontaine wrote: I feel we will start before Xmas to put together a prototype. I really want this to come to life because we could use cooperative Clojure instances on our bus. This would also provide us another form of persistance. Presently we rely on ActiveMq queues but to maximize parallelism we need another model and building that from queues would be harder. I'll keep everyone posted. As soon as I can get my hands on it without being interrupted by the current release of our bus we launch this. For the record, if anyone is watching only this thread post, Luc has posted an update here: http://groups.google.com/group/clojure/browse_thread/thread/85649a134cf22655# --~--~-~--~~~---~--~~ 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 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 -~--~~~~--~~--~--~---
