Re: Clojure Conference Poll
I second Seattle. On Fri, Jan 22, 2010 at 1:19 PM, ajay gopalakrishnan ajgop...@gmail.comwrote: I vote for Seattle. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: (list* ())
I'm still confused by why you'd need a list version of vec. Just return the sequence. Whatever would consume the list should equivalently consume the seq. -- 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 Conference Poll
On Sat, Jan 23, 2010 at 8:54 AM, Konrad Hinsen konrad.hin...@fastmail.net wrote: On 22 Jan 2010, at 22:15, Wilson MacGyver wrote: I vote let's turn this into a clojure vacation, and hold it in an exotic location. Otherwise, hey, Columbus Ohio is as good as any other city. :) My vote is for Paris, France :-) +1 :-) -- 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 Conference Poll
East coast for we Europeans ? On Jan 23, 8:53 am, Christophe Grand christo...@cgrand.net wrote: On Sat, Jan 23, 2010 at 8:54 AM, Konrad Hinsen konrad.hin...@fastmail.net wrote: On 22 Jan 2010, at 22:15, Wilson MacGyver wrote: I vote let's turn this into a clojure vacation, and hold it in an exotic location. Otherwise, hey, Columbus Ohio is as good as any other city. :) My vote is for Paris, France :-) +1 :-) -- 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: Dependency management
I believe some people use HttpUnit for this purpose. It's a very full-featured HTTP client. YMMV. On 23 Jan 2010, at 01:25, Richard Newman wrote: And as for Apache HttpComponents, it sounds like they don't grok the notion that breaking backwards compatibility should only occur with a major-version change. Yeah, it's a pain to use their stuff -- I've never seen *so many packages* in one library -- but it seems to be the only feature-rich HTTP client in the Java world (y'know, that can actually set parameters on requests, that sort of thing). The JRE stuff sucks badly. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: How can I parse this with clojure.contrib.zip-filter.xml ?
On 23 Jan 2010, at 02:53, James Reeves wrote: On Jan 23, 2:29 am, David Cabana drcab...@gmail.com wrote: What I'd like to get from 'tickets' is something like ( [Alice [foo]] [Bob [bar baz]]), that is, output that ties incidents to customers. So far it has eluded me. xml- just returns a sequence of matches. If you want nested matches, you'll need to put another loop in. Perhaps something like: (defn tickets [xml] (for [ticket (zf/xml- xml :ticket)] [(zf/xml1- ticket :customer zf/text) (zf/xml- ticket :item zf/text)])) The following is equally untested, but you can also just have xml- call a function for each matching sub-element: (defn ticket [xml] [(zf/xml1- xml :customer zf/text) (zf/xml- xml :item zf/text)]) (defn tickets [xml] (zf/xml- xml :ticket ticket))) -Steve -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Announcement: Vijual Graph Layout Library for Clojure Version 0.1
Awesome! I tried it out quickly last night using leiningen. The text rendering worked great, but graphical seems to have a problem: user= (use 'vijual.graphical) java.lang.Exception: Unable to resolve symbol: half in this context (graphical.clj:60) -Jeff On Jan 22, 11:06 pm, Conrad drc...@gmail.com wrote: http://lisperati.com/vijual/ Hope some of you find this library useful. Let me know if you have feature requests or want to help me improve this library. Conrad Barski lisper...@gmail.com -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Dependency management
I use leiningen to download and publish libraries, but in terms of setting up for development I use a bash script that adds whatever I need for the project to the CLASSPATH and starts the nailgun server. (swank for vimclojure) This seems to work pretty well, although it would be nice if Leiningen had mechanisms like Ant where you could customize the classpath on a project and/or task basis. Below is the script I'm using to create the classpath for a project that has multiple git submodules located in src/lib, jars downloaded with lein deps sitting in lib, and the code in src and test. I'm normally on Ubuntu but works under Cygwin also. -Jeff --- #!/bin/bash DEPS=lib SUBMODULES=src/lib CLASSPATH=./src:./test # Add jar files for f in $DEPS/*.jar; do CLASSPATH=$CLASSPATH:$f done # Add sub-modules for f in $SUBMODULES/**/src; do CLASSPATH=$CLASSPATH:$f done if [[ $OSTYPE == 'cygwin' ]]; then CLASSPATH=`cygpath -wp $CLASSPATH` fi echo $CLASSPATH On Jan 22, 2:21 am, Richard Newman holyg...@gmail.com wrote: Hi folks, Apparently everyone is jumping on the Leiningen bandwagon and deleting their build.xml files. I guess that means I'm moving, too. Now, I like to keep track of Clojure master. Right now, Clojure reports Clojure 1.2.0-master-SNAPSHOT. (I don't see that in Maven Central or in Clojars, so I guess I have to put it in my local repository...?) Unfortunately, not everybody keeps up-to-date like I do; most of the projects I use demand 1.1.0-alpha-SNAPSHOT. I'm sure there are still projects that demand 1.0. Adjusting the lein script to use my local Clojure install gave me a great error: Caused by: java.lang.NoSuchMethodError: clojure.lang.RestFn.init(I)V at clojure.contrib.with_ns$with_ns__7929.init(with_ns.clj:20) at clojure.contrib.with_ns__init.load(Unknown Source) at clojure.contrib.with_ns__init.clinit(Unknown Source) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:247) at clojure.lang.RT.loadClassForName(RT.java:1523) at clojure.lang.RT.load(RT.java:396) at clojure.lang.RT.load(RT.java:378) at clojure.core$load__4869$fn__4876.invoke(core.clj:4294) at clojure.core$load__4869.doInvoke(core.clj:4293) at clojure.lang.RestFn.invoke(RestFn.java:409) at clojure.core$load_one__4810.invoke(core.clj:4130) at clojure.core$load_lib__4825.doInvoke(core.clj:4167) at clojure.lang.RestFn.applyTo(RestFn.java:143) at clojure.core$apply__3434.invoke(core.clj:478) at clojure.core$load_libs__4841.doInvoke(core.clj:4193) at clojure.lang.RestFn.applyTo(RestFn.java:138) at clojure.core$apply__3434.invoke(core.clj:480) at clojure.core$use__4865.doInvoke(core.clj:4271) at clojure.lang.RestFn.invoke(RestFn.java:409) at leiningen.core$eval__5$loading__4758__auto6.invoke(core.clj:1) at leiningen.core$eval__5.invoke(core.clj:1) at clojure.lang.Compiler.eval(Compiler.java:5349) and I saw a similar problem with builds that referred to libraries built with different versions of Clojure. How do people deal with this? How can one simultaneously use two libraries which have hardwired dependencies on two different Clojure versions, each of which might be mutually incompatible? What's the community protocol around locally installing Clojure 1.2, and adding that as a dependency for a published library? What's the right way to get lein itself to use a recent Clojure build, rather than the version with which it ships? Thoughts -- and answers! -- welcome. Thanks, -R -- 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: Announcement: Vijual Graph Layout Library for Clojure Version 0.1
Jeff, I'm trying to dupe the error right now On Jan 23, 7:14 am, Jeff Rose ros...@gmail.com wrote: Awesome! I tried it out quickly last night using leiningen. The text rendering worked great, but graphical seems to have a problem: user= (use 'vijual.graphical) java.lang.Exception: Unable to resolve symbol: half in this context (graphical.clj:60) -Jeff On Jan 22, 11:06 pm, Conrad drc...@gmail.com wrote: http://lisperati.com/vijual/ Hope some of you find this library useful. Let me know if you have feature requests or want to help me improve this library. Conrad Barski lisper...@gmail.com -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Debugging in Clojure
On Jan 22, 1:40 pm, Krukow karl.kru...@gmail.com wrote: Please don't top post. Seriously, people still complain about this? It's the default behavior in Google Groups, so I think you just have to live with it. Find a news reader that doesn't suck. -- 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 Conference Poll
On 23.1.2010, at 10:33, Edmund wrote: East coast for we Europeans ? On Jan 23, 8:53 am, Christophe Grand christo...@cgrand.net wrote: On Sat, Jan 23, 2010 at 8:54 AM, Konrad Hinsen konrad.hin...@fastmail.net wrote: On 22 Jan 2010, at 22:15, Wilson MacGyver wrote: I vote let's turn this into a clojure vacation, and hold it in an exotic location. Otherwise, hey, Columbus Ohio is as good as any other city. :) My vote is for Paris, France :-) +1 :-) I'd say +1 for Paris, but I guess Clojure Conference Europe would be nice :D B. -- 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: Announcement: Vijual Graph Layout Library for Clojure Version 0.1
Yes, I'm getting the same error- The console functions (use 'vijual) work fine from the clojar but the graphical functions (use 'vijual.graphical) are throwing that error. There must be something more about clojure namespaces I'm not understanding... I'll let you know as soon as I have it fixed. On Jan 23, 7:14 am, Jeff Rose ros...@gmail.com wrote: Awesome! I tried it out quickly last night using leiningen. The text rendering worked great, but graphical seems to have a problem: user= (use 'vijual.graphical) java.lang.Exception: Unable to resolve symbol: half in this context (graphical.clj:60) -Jeff On Jan 22, 11:06 pm, Conrad drc...@gmail.com wrote: http://lisperati.com/vijual/ Hope some of you find this library useful. Let me know if you have feature requests or want to help me improve this library. Conrad Barski lisper...@gmail.com -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Clojure Conference Poll
On Jan 23, 2010, at 12:04 , Boštjan Jerko wrote: On 23.1.2010, at 10:33, Edmund wrote: East coast for we Europeans ? On Jan 23, 8:53 am, Christophe Grand christo...@cgrand.net wrote: On Sat, Jan 23, 2010 at 8:54 AM, Konrad Hinsen konrad.hin...@fastmail.net wrote: On 22 Jan 2010, at 22:15, Wilson MacGyver wrote: I vote let's turn this into a clojure vacation, and hold it in an exotic location. Otherwise, hey, Columbus Ohio is as good as any other city. :) My vote is for Paris, France :-) +1 :-) I'd say +1 for Paris, but I guess Clojure Conference Europe would be nice :D B. I had a horrible french teacher! Please not paris :P then again it's closer then the US Wherever it is there :P. How about Berlin? It's wonderful here ;). But for being serious if we pull something here in europe I would belive the UK would likely be the best place since at least all of us on the list speak english and won't have too much trouble to get along there ;) In the US I would say something on the east cost would be best, DS, NY, stuff which is easy to reach for us europeans, after all if any of us manage to attend we'll have 11+h of flight even if it's on the eastcost, having it back on the other side makes this what 15+? I'm not sure never took that route yet. Best regards, Heinz. PS: We've great bear and sausages in germany! -- 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: slicing multidimensional vectors (vectors of vectors of vectors ...)
I have a working function to slice multidimensional nested vectors a la MATLAB (actually more like NumPy). I'm using Konrad Hinsen's multi-array library (keep up the great work Konrad!). Here's the code (I'm sure it can be greatly improved and optimized): (defn nv-subvec [x ind] (loop [v x dim 0 i ind] (let [[start end step] (first i) other (rest i)] (if (empty? other) (nv-sample v dim start end step) (recur (nv-sample v dim start end step) (inc dim) other) It works like this: (nv-subvec VECTOR SLICE+) where each SLICE is [STAR END STEP]. Here's a 3 x 3 matrix: (def a [[[1 2 3] [4 5 6] [7 8 9]] [[10 11 12] [13 14 15] [16 17 18]] [[19 20 21] [22 23 24] [25 26 27]]]) user= (nv-subvec a [0 3 2] [0 2 1] [1 3 1]) [[[2 3] [5 6]] [[20 21] [23 24]]] user= (nv-subvec a [0 3 2] [0 2 1]) [[[1 2 3] [4 5 6]] [[19 20 21] [22 23 24]]] The result is correct in both cases. Seems to work fine. Of course a lot of space for improvement. Let me know what you think. On Jan 11, 8:26 am, Konrad Hinsen konrad.hin...@fastmail.net wrote: On 10 Jan 2010, at 21:39, extrackc wrote: Have you looked into Incanter project? I just found out about it recently. Incanter is a Clojure-based, R-like platform for statistical computing and graphics. http://incanter.org/ Incanter uses ParallelColt as its underlying matrix library. While this is a fine library for working with matrices, it is not a multidimensional array library. Colt arrays exist only in 1, 2, and 3 dimensions and there are no generic (dimension-independent) operations on array structure. As the huge success of Matlab has shown, a lot can be done with just matrices and vectors, but anyone who has used an array language (such as APL) or an equivalent library (such as Python's NumPy) will feel constrained by such an approach. Konrad. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: slicing multidimensional vectors (vectors of vectors of vectors ...)
Pardon, in the example above we have a 3 x 3 x 3 nested vector, not a 3 x 3 matrix! On Jan 23, 2:45 pm, Rock rocco.ro...@gmail.com wrote: I have a working function to slice multidimensional nested vectors a la MATLAB (actually more like NumPy). I'm using Konrad Hinsen's multi-array library (keep up the great work Konrad!). Here's the code (I'm sure it can be greatly improved and optimized): (defn nv-subvec [x ind] (loop [v x dim 0 i ind] (let [[start end step] (first i) other (rest i)] (if (empty? other) (nv-sample v dim start end step) (recur (nv-sample v dim start end step) (inc dim) other) It works like this: (nv-subvec VECTOR SLICE+) where each SLICE is [STAR END STEP]. Here's a 3 x 3 matrix: (def a [[[1 2 3] [4 5 6] [7 8 9]] [[10 11 12] [13 14 15] [16 17 18]] [[19 20 21] [22 23 24] [25 26 27]]]) user= (nv-subvec a [0 3 2] [0 2 1] [1 3 1]) [[[2 3] [5 6]] [[20 21] [23 24]]] user= (nv-subvec a [0 3 2] [0 2 1]) [[[1 2 3] [4 5 6]] [[19 20 21] [22 23 24]]] The result is correct in both cases. Seems to work fine. Of course a lot of space for improvement. Let me know what you think. On Jan 11, 8:26 am, Konrad Hinsen konrad.hin...@fastmail.net wrote: On 10 Jan 2010, at 21:39, extrackc wrote: Have you looked into Incanter project? I just found out about it recently. Incanter is a Clojure-based, R-like platform for statistical computing and graphics. http://incanter.org/ Incanter uses ParallelColt as its underlying matrix library. While this is a fine library for working with matrices, it is not a multidimensional array library. Colt arrays exist only in 1, 2, and 3 dimensions and there are no generic (dimension-independent) operations on array structure. As the huge success of Matlab has shown, a lot can be done with just matrices and vectors, but anyone who has used an array language (such as APL) or an equivalent library (such as Python's NumPy) will feel constrained by such an approach. Konrad. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Announcement: Vijual Graph Layout Library for Clojure Version 0.1
I'm stumped on this error- Maybe someone in this group can help point out my error in my clojar? Here's the issue: - The majority of the code in this library is in vijual.clj: http://github.com/drcode/vijual/blob/master/src/vijual.clj - I have a namespace under that with a file graphical.clj that has the graphical functions. It uses the vijual namespace: http://github.com/drcode/vijual/blob/master/src/vijual/graphical.clj - As far as I can tell, both vijual and vijual.graphical work just fine when I use it as local library, without a jar/leiningen/clojars. - When compiled to a clojar, you can use the vijual.clj functions as expected with the following minimal example (ns vijual-test (:use [vijual])) (draw-tree [[:foo [:bar]]]) - When compiled to a clojar, you get an error using the graphical.clj functions as can be seen with the following minimal example (ns vijual-test (:use [vijual.graphical])) (draw-tree-image [[:foo [:bar]]]) Namespaces and libraries are definitely still a weakness for me in clojure- If anyone here can give me some advice on any improvements I can make to my library to conform to clojure best practices (and also resolve this error) it would be much appreciated! -Conrad On Jan 23, 8:39 am, Conrad drc...@gmail.com wrote: Yes, I'm getting the same error- The console functions (use 'vijual) work fine from the clojar but the graphical functions (use 'vijual.graphical) are throwing that error. There must be something more about clojure namespaces I'm not understanding... I'll let you know as soon as I have it fixed. On Jan 23, 7:14 am, Jeff Rose ros...@gmail.com wrote: Awesome! I tried it out quickly last night using leiningen. The text rendering worked great, but graphical seems to have a problem: user= (use 'vijual.graphical) java.lang.Exception: Unable to resolve symbol: half in this context (graphical.clj:60) -Jeff On Jan 22, 11:06 pm, Conrad drc...@gmail.com wrote: http://lisperati.com/vijual/ Hope some of you find this library useful. Let me know if you have feature requests or want to help me improve this library. Conrad Barski lisper...@gmail.com -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Announcement: Vijual Graph Layout Library for Clojure Version 0.1
I should point out that the error involves the fact that the graphical.clj code uses items in the 'vijual namespace in an unqualified fashion (such as the half function) which I would expect would be allowed, but the compiler complains about this. On Jan 23, 8:58 am, Conrad drc...@gmail.com wrote: I'm stumped on this error- Maybe someone in this group can help point out my error in my clojar? Here's the issue: - The majority of the code in this library is in vijual.clj:http://github.com/drcode/vijual/blob/master/src/vijual.clj - I have a namespace under that with a file graphical.clj that has the graphical functions. It uses the vijual namespace:http://github.com/drcode/vijual/blob/master/src/vijual/graphical.clj - As far as I can tell, both vijual and vijual.graphical work just fine when I use it as local library, without a jar/leiningen/clojars. - When compiled to a clojar, you can use the vijual.clj functions as expected with the following minimal example (ns vijual-test (:use [vijual])) (draw-tree [[:foo [:bar]]]) - When compiled to a clojar, you get an error using the graphical.clj functions as can be seen with the following minimal example (ns vijual-test (:use [vijual.graphical])) (draw-tree-image [[:foo [:bar]]]) Namespaces and libraries are definitely still a weakness for me in clojure- If anyone here can give me some advice on any improvements I can make to my library to conform to clojure best practices (and also resolve this error) it would be much appreciated! -Conrad On Jan 23, 8:39 am, Conrad drc...@gmail.com wrote: Yes, I'm getting the same error- The console functions (use 'vijual) work fine from the clojar but the graphical functions (use 'vijual.graphical) are throwing that error. There must be something more about clojure namespaces I'm not understanding... I'll let you know as soon as I have it fixed. On Jan 23, 7:14 am, Jeff Rose ros...@gmail.com wrote: Awesome! I tried it out quickly last night using leiningen. The text rendering worked great, but graphical seems to have a problem: user= (use 'vijual.graphical) java.lang.Exception: Unable to resolve symbol: half in this context (graphical.clj:60) -Jeff On Jan 22, 11:06 pm, Conrad drc...@gmail.com wrote: http://lisperati.com/vijual/ Hope some of you find this library useful. Let me know if you have feature requests or want to help me improve this library. Conrad Barski lisper...@gmail.com -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Clojure for largish web application?
It's still very young days for any of the Clojure web frameworks (including -shameless plug- Cascade). My favorite web framework (for obvious reasons) is Tapestry; there's years and years of experience behind it to make it a very effective, very productive, and extremely high-performance environment. It's also very flexible; I see no reason why it would not be possible to use a stateful Tapestry presentation layer that communicated to a stateless (or state managed) Clojure back end for any non-trivial processing or calculation. On Fri, Jan 22, 2010 at 5:52 AM, Shantanu Kumar kumar.shant...@gmail.com wrote: On Jan 22, 11:09 am, cperkins cperk...@medialab.com wrote: I've read that people have been able to use Clojure with some of the Java web servers. I am not familiar with any Java web servers or web frameworks and wonder if anyone who knows more about them can advise me. FWIW I'm also not familiar with load balancing or multi-server setups for web applications. We are looking to develop a largish web application that may move a lot of data and potentially have a lot of users. Maybe a couple hundred thousand page hits a day, maybe a million - it's too early to tell. I've developed some smaller web applications using Common Lisp, but I'm not confident that any of the CL web servers (CL-HTTP, Hunchentoot, AllegroServe, Araneida, mod_lisp, et al) are up to handling high traffic high data sites. (Maybe they are, I just don't know). So, now that we are considering developing a considerably larger one I'm looking for something suitable strong to build it upon. I've heard good things about some of the Java web frameworks (WebWork, Tapestry, etc) but, again, know nothing about them - and I'd rather program in a Lisp. Does anyone know how good any of the CL web servers are at handling high traffic? What are my options if I were to go with Clojure? How solid and scalable are they going to be? 1. The JVM may be a good bet in your case, and Clojure seems to be the right language for this. 2. Irrespective of which web framework you use, consider using a web container or an app server. Deploy the application as a WAR if you want to use the app server's manageability features. 3. If you want to scale out the web layer, consider using memcached as your session handler rather than the built-in (sticky sessions are a pain). The latency may be slightly higher, but scale it would. http://code.google.com/p/memcached-session-manager/ 4. If you are keen on Open Source, consider Tomcat, JBoss, Terracota etc. If you don't need clustering, stick with Tomcat rather than JBoss. Tomcat and JBoss are pretty solid and proven technologies. Use JDK 1.6 in server mode for better performance. 5. Use Apache HTTPD (or nginx or any web server) for serving static content. Use CDN is you can. 6. If you have many (and probably non-trivial) web content, consider using a web template framework. StringTemplate is a functional style web template framework: http://www.stringtemplate.org/ 7. Web frameworks for Clojure: Compojure, Taimen. You can look at Blogjure for example usage. http://github.com/weavejester/compojure http://code.google.com/p/bitumenframework/ (Taimen and Blogjure, shameless plug) What questions am I not asking and should be? Feel free to ask any question you have. Keep us posted on what you chose and why -- it would be good to know. HTH Regards, Shantanu -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- Howard M. Lewis Ship Creator of Apache Tapestry The source for Tapestry training, mentoring and support. Contact me to learn how I can get you up and productive in Tapestry fast! (971) 678-5210 http://howardlewisship.com -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Promise/Deliver use cases
Jeff Rose ros...@gmail.com writes: The future is used because they have a timeout feature when using the .get method. Should there be a corresponding timeout-based `deref' function¹ (deref-within?) for promises? Having to close a function over your @p form and spawn a job on a separate thread seems like way too much work just to get a timeout-based wait on the promise's delivery arriving. Footnotes: ¹ http://richhickey.github.com/clojure/clojure.core-api.html#clojure.core/deref -- Steven E. Harris -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Clojure for largish web application?
I successfully used Clojure, Restlet, StringTemplate, and the Simple servlet framework to handle all traffic on www.altlaw.org. My scaling requirements were a tad unusual -- only ~10,000 visitors per day, but over a million pages. This was all on a single EC2 small instance, also running Solr. -SS On Jan 22, 1:09 am, cperkins cperk...@medialab.com wrote: I've read that people have been able to use Clojure with some of the Java web servers. -- 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: Dependency management
On Jan 22, 11:58 pm, Richard Newman holyg...@gmail.com wrote: I foresee a future with a lot more time spent modifying other people's project files. This is the past, the present, and the forever-after of open-source software development. If you need lots of libraries, you need your own Maven repository with your own builds, tweaked to work together. -SS -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: (list* ())
The Clojure parser I'm writing needs to differentiate between nil and the empty list. It should parse [1 2 3] and read that as [1 2 3], and the same for lists, maps, and sets. If it parses () and reads that nil, then it's not working correctly. In addition, code in some other libraries I'm writing depends on the vector? and list? functions. (list? (list* coll)) is (confusingly) always false unless coll is a list to begin with. That explains another bug that I was encountering earlier... What I don't get is the terminology and the doc of list*. list* definitely does not return lists; it returns sequences, a superset of the list. This does affect any code that depends on collection types (e.g. list?). On Jan 23, 1:02 am, ataggart alex.tagg...@gmail.com wrote: I'm still confused by why you'd need a list version of vec. Just return the sequence. Whatever would consume the list should equivalently consume the seq. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: (list* ())
Fair enough. Clearly list* isn't intended to do what you want. I'd suggest using (into '() ...). On Jan 23, 8:38 am, samppi rbysam...@gmail.com wrote: The Clojure parser I'm writing needs to differentiate between nil and the empty list. It should parse [1 2 3] and read that as [1 2 3], and the same for lists, maps, and sets. If it parses () and reads that nil, then it's not working correctly. In addition, code in some other libraries I'm writing depends on the vector? and list? functions. (list? (list* coll)) is (confusingly) always false unless coll is a list to begin with. That explains another bug that I was encountering earlier... What I don't get is the terminology and the doc of list*. list* definitely does not return lists; it returns sequences, a superset of the list. This does affect any code that depends on collection types (e.g. list?). On Jan 23, 1:02 am, ataggart alex.tagg...@gmail.com wrote: I'm still confused by why you'd need a list version of vec. Just return the sequence. Whatever would consume the list should equivalently consume the seq. -- 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: Promise/Deliver use cases
delay/force definitely do not do what I'm describing. What we want to is something like a continuation as mentioned by Chouser. We want to block the thread of execution until some point in the future when the values become available. I'm not sure that what you described describes what you want :) Yes, if you want to block the current thread to wait for a value computed by a background thread, you need promises and futures. However, you were explicitly talking about a use outside the context of concurrency. If you don't want concurrency, only delayed execution, then use delay instead. In your example you have to *know* that all the tests have run in order to accumulate results. No you don't — force is synchronous. By the time that `doall` has finished, all the tests have run and their results have been accumulated inside the delays. As I said, if you want to run tests in parallel, then you're not talking outside the context of concurrency. Futures are awesome, but you can't argue that they're not a parallel construct. By using promise/deliver you can remove yourself from caring about that at all. With a recursive data structure this becomes annoying very quickly, you have to bookkeep where you are if you use delay/force. No you don't — simply always call `force`, just as you always call `deref`, and the delayed computation will be done if necessary. (In fact, you can use @, just as you can with refs and promises.) Here's an example of a trivial recursive arithmetic evaluator that prints the whole tree, returning a delay which captures the execution. When forced, it prints the arithmetic results back up the tree. Execution occurs once. (defn form-delay [v] (if (number? v) (do (println Saw number v) (delay v)) (let [[op args] v] (println Seen form with operator op , args args) (let [delays (map form-delay args)] (delay (let [res (eval `(~op ~@(map force delays)))] (println Result is res) res)) user= (let [de (form-delay `(+ 5 (- 3 2)))] (println First run: @de) (println No bookkeeping: @de) (println Delay: de) @de) Seen form with operator clojure.core/+ , args (5 (clojure.core/- 3 2)) Saw number 5 Seen form with operator clojure.core/- , args (3 2) Saw number 3 Saw number 2 Result is 1 Result is 6 First run: 6 No bookkeeping: 6 Delay: #de...@58e22f2b: 6 6 You'll see that: * It runs on one thread * There is no bookkeeping of what's been forced and what has not; you can force multiple times without re-execution * It can do arbitrary work during the tree walk (printing Seen form...), and during evaluation (printing Result is), and the two phases are separate. By creating the future computations to be performed during the traversal you later only need to deliver each individual test result. As tests come in they automatically trigger the next level of computation (the aggregate result). You don't need track relationships between tests at all because that was determined by the first traversal. There are only two places where futures might apply in what you're talking about: * To run tests in parallel, which you explicitly disregarded * To have the tests depend on each other's values (which doesn't seem very smart to me). Use futures and promises for parallelism or dataflow-style work. Use delay for non-parallel, synchronous delayed execution. -- 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: Leiningen plugin: run
Is Leiningen a Linux-only tool? -- 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: Leiningen plugin: run
Is Leiningen a Linux-only tool? No, but Linux is much better supported than Windows right now. See this page: http://github.com/technomancy/leiningen The last question in the FAQ on that page is: Q: What about Windows? A: Try the bin/lein.bat script. Note that Windows support is still experimental; not all features (notably self-install) are implemented. -- 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: Leiningen plugin: run
Is Leiningen a Linux-only tool? No, but Linux is much better supported than Windows right now. See this page: http://github.com/technomancy/leiningen The last question in the FAQ on that page is: Q: What about Windows? A: Try the bin/lein.bat script. Note that Windows support is still experimental; not all features (notably self-install) are implemented. More information on this issue: http://groups.google.com/group/leiningen/browse_thread/thread/2474d2e9019ee29c -- 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: Leiningen plugin: run
It works well for me on MacOS X. If Clojure were an option for me at work, I would try Leiningen under something like Cygwin or msysgit on Windows. On Jan 23, 8:13 pm, Mark Engelberg mark.engelb...@gmail.com wrote: Is Leiningen a Linux-only tool? -- 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: Promise/Deliver use cases
On Sat, Jan 23, 2010 at 7:43 PM, Richard Newman holyg...@gmail.com wrote: Use futures and promises for parallelism or dataflow-style work. Use delay for non-parallel, synchronous delayed execution. You're right. Here's a recursive example of what I was trying to do with promise/deliver: http://gist.github.com/284957 And with delay/force: http://gist.github.com/284972 I suppose the one thing I like about promise/deliver is that promises can be watched making it perhaps more extensible? Anyone can get just attempt to deref the value inside a future to watch it. With delay/force it's harder to add new functionality without mucking directly with the code. Or is there a better way to handle this that I haven't thought of? Thanks for the insights Richard. -- 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 Conference Poll
Weekend, and East coast, either near the DC area or New York Area, maybe Boston area is OK too. On Jan 22, 12:36 pm, dysinger t...@dysinger.net wrote: We will be organizing a conference in the next month for 2010 (probably in the fall). One question I would like to ask is, given the conference is probably going to be a 2-day conference, would you rather have it during the week or weekend ? I would think a weekend (meet greet friday night, saturday sunday) would work good. -Tim -- 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: Promise/Deliver use cases
You're right. Here's a recursive example of what I was trying to do with promise/deliver: http://gist.github.com/284957 And with delay/force: http://gist.github.com/284972 Nice comparison, thanks for sharing. I suppose the one thing I like about promise/deliver is that promises can be watched making it perhaps more extensible? Anyone can get just attempt to deref the value inside a future to watch it. With delay/force it's harder to add new functionality without mucking directly with the code. Or is there a better way to handle this that I haven't thought of? Nope, you're right about the advantages — futures (being essentially control abstractions for tasks running on threads) are richer objects. Delays have downsides: for example, just printing a delay will cause its value to be computed. And of course using promises and futures introduces parallelism into your code, which is sometimes desirable. I see a kind of analogy — futures : delays :: refs : vars or atoms. Both futures and refs hide a lot of functionality under the hood (threads and synchronization for futures, the STM for refs), whilst delays and the other state approaches are more applicable for local or non-concurrent situations. Delaying computation with delay feels like local accumulation using an atom, whilst computation with promises and futures feels like distributing state operations with refs. Thanks for the insights Richard. Thanks for the discussion! -- 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 are Vars supposed to be used for?
Thanks for the reply. That seems to match well with how I thought they were supposed to work. I'm just a little confused by the set!, with-local-vars, functions. What are they supposed to be used for? -Patrick -- 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
