Re: Clojure Conference Poll
I second Seattle. On Fri, Jan 22, 2010 at 1:19 PM, ajay gopalakrishnan wrote: > 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 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 wrote: > On Sat, Jan 23, 2010 at 8:54 AM, Konrad Hinsen > > 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 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: Promise/Deliver use cases
In a library for communicating with networked programs and devices using Open Sound Control (OSC) messages, I use promises in combination with futures to provide synchronous callbacks with an optional timeout. For example, you might send a status request message to a device and you expect an immediate response as long as the device is live. If the device is off or it has crashed then you don't want to hang forever waiting for a response. The promise/deliver pair acts as the communication mechanism between a handler that gets called asynchronously by another thread listening on a socket and the original thread that is waiting for the response. In the function below osc-handle registers a handler function for a specific OSC path, which acts as a basic message dispatch. All the handler does is deliver the promise and remove itself. The future is used because they have a timeout feature when using the .get method. (defn osc-recv "Receive a single message on an osc path (node) with an optional timeout." [peer path & [timeout]] (let [p (promise)] (osc-handle peer path (fn [msg] (deliver p msg) (osc-remove-handler))) (let [res (try (if timeout (.get (future @p) timeout TimeUnit/MILLISECONDS) @p) (catch TimeoutException t nil))] res))) The library is available on github, in case anyone wants to talk OSC: http://github.com/rosejn/osc-clj -Jeff On Jan 21, 12:19 pm, Baishampayan Ghose wrote: > Hello, > > I am trying to understand the use-cases of the new promise/deliver > feature in Clojure. I have tried using them, and they seem to be > pretty straight-forward to use, but unfortunately I haven't been able > to understand its use-cases. > > It would be great if someone pointed out some example usage of > promise/deliver. > > Regards, > BG > > -- > Baishampayan Ghose -- 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 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 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.(I)V > at clojure.contrib.with_ns$with_ns__7929.(with_ns.clj:20) > at clojure.contrib.with_ns__init.load(Unknown Source) > at clojure.contrib.with_ns__init.(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 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 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 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 wrote: >> On Sat, Jan 23, 2010 at 8:54 AM, Konrad Hinsen >> >> 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: Clojure Conference Poll
>> >> I vote let's turn this into a clojure vacation, and hold it in an >> >> exotic location. Well, how about Johannesburg or Cape Town. Sort of equidistant from the US, Europe, Asia and Aus. Also if you wait a month or two you can get to watch a soccer (footie) match or three as well :). -- 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 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 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 wrote: >>> On Sat, Jan 23, 2010 at 8:54 AM, Konrad Hinsen >>> >>> 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 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 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 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 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 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 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 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 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 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 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 wrote: > > > On Jan 22, 11:09 am, cperkins 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 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 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 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 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 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 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: # 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 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 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 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
