Re: distributing a clojure application as self contained .jar - guide
+ 1 on curiosity re: this question. In my limited Java experience, I find it more common to see a directory full of jars accompanying an application, but the benefits of a self-contained executable jar seem pretty self-evident, especially for an app who's only dependencies are clojure.jar & clojure-contrib.jar. Perry --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Misplaced doc strings in clojure.contrib.seq-utils
Here's the patch: http://clojure.googlegroups.com/web/seq-utils-doc-strings.patch Perry --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
clojure wrapper for Saxon XSLT 2.0 library
Hi All, For any of you who do XSLT 2.0 processing, I've written a simple Clojure wrapper around Saxon's (saxonica.com) high-level Java API. It's at http://github.com/pjt/saxon/tree/master Best, Perry --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: What is this function called?
I did something similar using (iterate rest coll), which I called iter- rest: (defn iter-rest "Takes the first (count coll) items from call to (iterate rest coll). If passed function as first argument, calls it on each invocation of rest, i.e. (iterate #(func (rest %)) coll)." ([coll] (take (count coll) (iterate rest coll))) ([func coll] (take (count coll) (iterate #(func (rest %)) coll user=> (iter-rest (range 3)) ((0 1 2) (1 2) (2)) I now realize a key difference is that, by using (count coll), iter- rest fully realizes anything lazy; for Andrew's lazy version above, I second the name "rests." Perry --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Newbie: Creating a macro that just calls a function but evaluates its arguments lazily
Hi sampii, The problem, as I see it (& as Konrad suggested above), is that you're not passing *functions* to (alt); you're passing values returned from function calls, even though in the case of the sub-functions you define those returned values are functions. Functions evaluate to themselves, so if you can write your code to pass functions to (alt), e.g. (alt #(sub-function1 c) #(sub-function2 c) #(sub-fuction3 c)) you should be golden. Just to show it can be done, if you make the args to alt be (defn mmf [c] (alt #(sub-one c) #(sub-two c) #(sub-three c))) (note the #() reader macro)), & if you modify the definition of alt to be (defn alt [& funcs] (fn [tokens] (some #((%) tokens) funcs))) (note the extra set of parens around % -- so that the #(sub-one c) funcs get called, then their return values likewise get called), you get user=> ((mmf "context") [:a :b :c]) 1 context 2 context true Of course it would be more straightforward to drop the intermediate step of the anonymous functions -- #(sub-one c) -- which return yet another function -- (fn [c] true) -- say, by passing the equivalent of (fn [c] true) directly to alt, but I don't know your actual use case. My recommendation -- to passing function -- is simple enough that I feel like I might be missing something important from your question, but in case I'm not I didn't want you to think your only recourse was the full machinery of delay/force. Transcript follows. Best, Perry user=> (defn alt [& funcs] (fn [tokens] (some #((%) tokens) funcs))) #'user/alt user=> (defn sub-one [c] (println 1 c) (fn [x] false)) #'user/sub-one user=> (defn sub-two [c] (println 2 c) (fn [x] true)) #'user/sub-two user=> (defn sub-three [c] (println 3 c) (fn [x] false)) #'user/sub-three user=> (defn mmf [c] (alt #(sub-one c) #(sub-two c) #(sub-three c))) #'user/mmf user=> ((mmf "context") [:a :b :c]) 1 context 2 context true --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
clojure.contrib.command-line patch: multiple option format
Hi Chouser & list, I like clojure.contrib.command-line -- thanks for it! -- but I wanted to be able to specify multiple forms for an option, e.g. --help, -h, -?, etc. Here (in the Files section) http://bit.ly/fIVH is a patch to enable it (the values are bound only to the first form given -- help, in the previous example). Would you consider it (my CA is in)? Best, Perry --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: clojure.contrib.command-line patch: multiple option format
Hi Chouser, Thanks for checking out the patch. > It's a good idea. Any sane way to allow the single-letter variety to > be specified with a single leading dash, instead of a double-dash? Single or double dashes should work for both kinds of options (long- or short-style), based on your code. The regex that looks for option syntax is (re-find #"^--?(.*)" argkey) (optional second dash). Are you seeing it not work this way? Maybe you're referring to the printed help, with the "--(option|o)" listing. I agree that it isn't that cool. Maybe dashes don't need to be printed next to the options at all, perhaps with a short message about single or doubles working (though that's a little clunky, too)? > 'justify' is interesting. I wonder if a CL-style 'format' will end up > in clojure-contrib after all. Yeah, I couldn't bear to do it w/o a bit of justification, even if it's a little out of place in this lib (& if 'justify' isn't really complete -- a centered option would be pretty easy to add). As for the full CL format, it looks like Tom Faulhaber is pretty far along at http://github.com/tomfaulhaber/cl-format/ but I'm not familiar with it myself. Best, Perry --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: clojure.contrib.command-line patch: multiple option format
A thought: if you end up using the patch, I gave the 'justify' function an inappropriate name. It should be 'align' or 'align-cols' or some such. (No one in their right mind would justify text on the console!) Perry On Jan 14, 3:16 pm, Perry Trolard wrote: > Hi Chouser, > > Thanks for checking out the patch. > > > It's a good idea. Any sane way to allow the single-letter variety to > > be specified with a single leading dash, instead of a double-dash? > > Single or double dashes should work for both kinds of options (long- > or short-style), based on your code. The regex that looks for option > syntax is > > (re-find #"^--?(.*)" argkey) > > (optional second dash). Are you seeing it not work this way? > > Maybe you're referring to the printed help, with the "--(option|o)" > listing. I agree that it isn't that cool. Maybe dashes don't need to > be printed next to the options at all, perhaps with a short message > about single or doubles working (though that's a little clunky, > too)? > > > 'justify' is interesting. I wonder if a CL-style 'format' will end up > > in clojure-contrib after all. > > Yeah, I couldn't bear to do it w/o a bit of justification, even if > it's a little out of place in this lib (& if 'justify' isn't really > complete -- a centered option would be pretty easy to add). As for the > full CL format, it looks like Tom Faulhaber is pretty far along at > > http://github.com/tomfaulhaber/cl-format/ > > but I'm not familiar with it myself. > > Best, > Perry --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
pmap memory hogging
Hi All, Yesterday I had a strange case of pmap (parallel map) eating up all of the heap space I'd make available -- from 256M up to a Gig. I track SVN, & I know for sure this wasn't happening last Wednesday (the 14th). Calling map in place of pmap caused the code to run fine inside of a 256M heap. I don't see anything in the SVN logs that looks like the culprit, but the behavior is easy enough to reproduce: user=> (def result (map inc (range 100))) #'user/result user=> (count result) 100 user=> (def result-p (pmap inc (range 100))) java.lang.OutOfMemoryError: Java heap space (NO_SOURCE_FILE:8) Stack trace below. Best to open an issue? Perry user=> (.printStackTrace *e) java.lang.OutOfMemoryError: Java heap space (NO_SOURCE_FILE:8) at clojure.lang.Compiler$InvokeExpr.eval(Compiler.java:2700) at clojure.lang.Compiler$DefExpr.eval(Compiler.java:297) at clojure.lang.Compiler.eval(Compiler.java:4180) at clojure.core$eval__3745.invoke(core.clj:1588) at clojure.main$repl__5474$fn__5492.invoke(main.clj:148) at clojure.main$repl__5474.doInvoke(main.clj:145) at clojure.lang.RestFn.invoke(RestFn.java:426) at clojure.main$repl_opt__5516.invoke(main.clj:208) at clojure.main$main__5551$fn__5553.invoke(main.clj:295) at clojure.main$main__5551.doInvoke(main.clj:289) at clojure.lang.RestFn.invoke(RestFn.java:402) at clojure.lang.Var.invoke(Var.java:332) at clojure.lang.AFn.applyToHelper(AFn.java:172) at clojure.lang.Var.applyTo(Var.java:453) at clojure.main.main(main.java:39) Caused by: java.lang.OutOfMemoryError: Java heap space at clojure.core$cycle__3644$thisfn__3646.invoke(core.clj:1457) at clojure.core$cycle__3644$thisfn__3646$fn__3648.invoke (core.clj:1458) at clojure.lang.LazyCons.rest(LazyCons.java:60) at clojure.lang.ASeq.count(ASeq.java:100) at clojure.lang.ASeq.size(ASeq.java:169) at clojure.lang.RT.nth(RT.java:766) at clojure.core$nth__3358.invoke(core.clj:871) at clojure.core$pmap__4904$step__4914.invoke(core.clj:3646) at clojure.core$pmap__4904.invoke(core.clj:3653) at clojure.lang.AFn.applyToHelper(AFn.java:176) at clojure.lang.RestFn.applyTo(RestFn.java:137) at clojure.lang.Compiler$InvokeExpr.eval(Compiler.java:2695) ... 14 more nil user=> --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: pmap memory hogging
> Doesn't pmap have to construct the whole sequence explicitly in order > to map its execution across more than one processor? or does it take > in a lazy fashion? Semi-lazy, according to the doc: Like map, except f is applied in parallel. Semi-lazy in that the parallel computation stays ahead of the consumption, but doesn't realize the entire result unless required. But I don't think lazyness is the problem: user=> (def r (doall (map inc (range 100 #'user/r user=> (count r) 100 user=> (pmap inc [0]) java.lang.OutOfMemoryError: Java heap space (NO_SOURCE_FILE:0) That is, map's fine with fully realizing a sequence of a million items; & pmap consumes all of the heap with a sequence of one item. Perry --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: pmap memory hogging
Thanks for testing, Mark. If I understand what you did correctly, the reason it worked for you is that Rich committed a fix to SVN in the meantime! > The last (count result-p) call takes a few seconds (probably > because there's a one-to-one mapping of tasks to sequence > elements) but it finishes. That's right, just for the record, using pmap to map inc across a collection of integers -- or to do any similarly low-cost computation -- is a *bad* idea. Map will always be faster -- in my casual tests with inc, pmap is slower by an order of magnitude. (But pmap should still compute the value, & inc was an easy way to make a reduction for bug reporting...) Perry --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Pretty printing a function's symbol
Hi Daniel, You can get the symbol that names the function from the Var's metadata, like: user=> (:name (meta (var =))) = user=> Best, Perry --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: clojure.contrib.command-line patch: multiple option format
Hi Chouser, Is there anything I can do to help get the proposed change above, or something like it, included in c.c.command-line? I'd be happy to modify the patch: removing the somewhat orthogonal alignment code, etc. Thanks, Perry --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: New functions and possible bugs
> I'd also like function? and macro? as an alternative to checking the > metadata for :macro set to true. Forgive my parital answer to the intial query of the thread, but regarding a function? predicate, it's already included: user=> (doc fn?) - clojure.core/fn? ([x]) Returns true if x implements Fn, i.e. is an object created via fn. nil user=> (doc ifn?) - clojure.core/ifn? ([x]) Returns true if x implements IFn. Note that many data structures (e.g. sets and maps) implement IFn nil Regarding macro?, it's use seems limited by the fact that macros are not self-evaluating like functions, so the macro? predicate would have to be a macro, which means it can't be passed to other functions, etc. But its implementation would of course be: (defmacro macro? [x] `(:macro (meta (var ~x Perry --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
proposal for shell-out: option to return articulated out, err, & exit code
Hi Users of Shell-out,
I'd sometimes like to have the exit status from system commands, so I
patched clojure.contrib.shell-out to accept a :verbose option which,
when turned on, returns a map with :exit, :out, & :err (where :exit's
value is the exit code int, & :out & :err name either byte arrays or
strings).
Anyone else have an interest in such a feature? In particular, would
the option be handy for lancet?
The modified sh function is below for reference, but I'll submit an
issue & patch to contrib if invited to.
Thanks,
Perry
(defn sh
; doc string elided
[& args]
(let [opts (parse-args args)
proc (.exec (Runtime/getRuntime)
(into-array (:cmd opts))
(as-env-string (:env opts))
(as-file (:dir opts)))
in-stream (.getInputStream proc)]
(when (:in opts)
(with-open [osw (OutputStreamWriter. (.getOutputStream proc))]
(.write osw (:in opts
(let [stdout (.getInputStream proc)
stderr (.getErrorStream proc)
[[out err] combine-fn]
(if (= (:out opts) :bytes)
[(for [strm [stdout stderr]]
(into-array Byte/TYPE (map byte (stream-seq strm
#(into-array Byte/TYPE (concat %1 %2))]
[(for [strm [stdout stderr]]
(apply str (map char (stream-seq
(InputStreamReader. strm (:out
opts))
str])
exit-code (.waitFor proc)]
(if (:verbose opts)
{:exit exit-code :out out :err err}
(combine-fn out err)
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---
Re: proposal for shell-out: option to return articulated out, err, & exit code
> Sounds good. Is ':verbose' the best name for this option? What about > ':return-map'? I'm okay with ':verbose' if we can't reach consensus > on something else. I agree that :verbose isn't right -- :return-map's not bad at all. Perry --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: proposal for shell-out: option to return articulated out, err, & exit code
Patch submitted to the issue tracker: http://code.google.com/p/clojure-contrib/issues/detail?id=23 Thanks, Perry --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: clojure.contrib.command-line patch: multiple option format
Patch attached to issue at http://code.google.com/p/clojure-contrib/issues/detail?id=24 On Jan 28, 7:55 pm, Chouser wrote: > Please make the 'justify' fn (whatever you want to call it) private > for now so that it doesn't become another API to be maintained. If it > proves to be more generally useful, it can be moved to a more > approriate lib later. Sure -- I should've done that the first time. > Printing the options as --(a|b) is rather unusual and likely to be > confusing. More common appears to be like this line from "ls --help": > > -r, --reverse reverse order while sorting > > Please use something like this instead. Showing double-dashes for > each option is probably fine for now. That's indeed more readable. Done. For single-character options, I show a single dash; for others, a double-dash. > If we want to allow combining > of multiple single-letter options without spaces between them later on > (which itself has questionable value) -- well, that's a question for > another time. Yeah, the trade-off seems to be that if you allow multiple single- characer options (like, say "tar -xvf") then you must be strict about multi-character options being preceded by double-dashes (so no "java - cp", say); or, you have to parse the option arguments while aware of the semantics of each option (which doesn't sound fun or worth the work). But I do like the convenience of -xvf; the easy way to tackle it would be to expand all "-xvf"'s into "-x -v -f" & proceed as usual from there. The only change it would require is strictness about double- dashes for long-format options. In any case, hope the patch as delivered is useful. Best, Perry --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Got a Clojure library?
Name: saxon Author: Perry Trolard URL: http://github.com/pjt/saxon/tree/master Category: XML, XPath, XQuery License: MIT Depends: Michael Kay's Saxon XSLT and XQuery Processor (http:// saxonica.com); included in distribution saxon is a simple functional wrapper around Saxon's high-level APIs, taking stylesheets, XPaths, & XQuery expressions & returning Clojure functions which apply them to compiled XML documents. For XQuery & XPath, functions return lazy sequences of query results with "atomic types" (i.e. non-node results) converted to native Clojure (Java) datatypes. Perry --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: proposal for shell-out: option to return articulated out, err, & exit code
I've updated this patch, eliminating the performance hit I introduced for concatenation of stdout & stderr when they're byte arrays (turns out it was significant). Let me know if there's anything else I can do. Perry http://code.google.com/p/clojure-contrib/issues/detail?id=23 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: A pipe macro for left-to-right coll streams
+1 for something like (let->). I don't imagine myself being confused by the reserved symbol being bound to different values in each successive form, or, in any case, would gladly trade that possibility for the advantage of being able to place the special symbol anywhere in the forms. Somewhat along the lines of what Miekel says, if the special symbol is not user-defined, the macro could be named after the special symbol, e.g. x->, or, (keeping with the the "threading the needle" metaphor in ->'s docs) ndl->, or with the pipe metaphor, P->. The latter has the advantage that capitals aren't idiomatic for variable names in Clojure. In any case, I vote for approaching Konrad Hinsen about putting this in clojure.contrib.macros when a naming convention is agreed on. Perry --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: A pipe macro for left-to-right coll streams
On Feb 12, 12:15 pm, Meikel Brandmeyer wrote: > > I dislike this strategy for two related reasons: (1) It cannont be > > nested. Here is a pseudo-example: > > > (?-> 2 ... some computations ... (f (?-> ... I don't have access to > > the outer "?" anymore... ))) > > > (2) Shadowing user bindings. If I bind ? to something in my code (e.g. > > (let [? (pred? foo)] ())) the ?-> form shadows my definition, > > preventing access. > Agreed, Mark. I thought these limitations were acceptable given that compactness is the goal of the macro -- i.e. it wouldn't make much sense to nest with it -- but you're likely right that it'd be shortsighted. > However I would not name it let-> since there is no binding vector > following. I would suggest pipe-as. This also explains, that the given > local is bound to different things during the different stages of the > pipe. +1 to Miekel's pipe-as: I agree that "let" forms should have a binding vector. > What I definitively want is the non-seq => (non-seq local) translation. > That's really nice. Agreed. > It does prompt me to consider > a more complicated macro that inspects its arguments and provides > several behaviors under one name. If the first arg is a symbol, it > works like let->. If the first argument is a list, it works like ->. > If the first argument is the keyword :last it behaves like pipe. This > would be backwards compatible with the current -> implementation, but > also allow for the additional functionality described in this thread. Mark, I don't think this is actually backwards compatible. If the first arg is a symbol, you don't know if it's a symbol to be bound or if it's the initial value, e.g. user=> (-> 0 inc dec) 0 user=> (def z 0) #'user/z user=> (-> z inc dec) 0 At the moment, my vote is for two macros: 1 pipe: like -> but accumulated value is place at end of each form 2 pipe-as: in which user specifies binding symbol for accumulated value, plus the non-seq to (non-seq local) translation Perry --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: A pipe macro for left-to-right coll streams
Let me amend: Instead of pipe-as, I think the symbol-binding version of the macro should be derived from the more common macro, which is -> & not pipe. So I'd vote for pipe & a let-> that takes a bindings vector as its first argument (sample implementation below). Perry (defmacro let-> "Like ->, but takes a binding form as first argument, the bound symbol(s) from which will carry the resulting value from form to subsequent form. E.g. (let-> [a 1] (str "Your number is:" a) (.replace a "Your" "My") .toUpperCase) => \"MY NUMBER IS: 1\"" ([[sym init] form] (if (seq? form) `(let [~sym ~init] ~form) (list 'let [sym init] (list form sym ([[sym init] form & more] `(let-> [~sym (let-> [~sym ~init] ~form)] ~...@more))) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: A pipe macro for left-to-right coll streams
Sorry to keep revising things; here's an improved version of let->, which better supports (as near as I can tell -- please try to break) arbitrary let-style destructuring. (The previous version favored single-symbol bindings, but I can imagine use cases where [a b :as all] kinds of destructuring are useful.) Perry (defmacro let-> "Like ->, but takes a binding form as first argument, the bound symbol(s) from which will carry the resulting value from each form." ([[bind init] form] (if (seq? form) `(let [~bind ~init] ~form) (list form init))) ([[bind init] form & more] `(let-> [~bind (let-> [~bind ~init] ~form)] ~...@more))) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: A pipe macro for left-to-right coll streams
Hi Timothy, On Feb 12, 8:08 pm, Timothy Pratley wrote: > What should happen when/if the seq arg doesn't contain the symbol? I > believe how you currently handle it is correct and in the spirit of > let-> (alternatively it could be reported as an error) however it may > raise yet another possibility for pipe: > (pipe 5 inc (+ 2) (+ ? 3) (+ 4 ? 2)) > ie: if the argument is a seq and doesn't contain ? then it is assumed > to be a post argument, but if it does contain ? then can be explicitly > a pre or mid argument. The problem that I see with scanning for the special symbol & inserting it when not found is that it really requires a single symbol as the binding. But I think it's good for let-> to behave just like let does -- no surprises -- which means arbitrary destructuring. So, for example, if my binding is like (let-> [[a :as all] coll] (if (pred? a) (map func1 all) (map func2 all)) some-final-func) what should happen if the last form was (map some-final-func) instead of some-final-func? Which symbol should be inserted into the form? One answer is that instead of a symbol being inserted, the value would be (this is what happens when the form isn't a list, .e.g. (let-> [a "string"] .toUpperCase) => (.toUpperCase "string")). But that brings the question of *where* to put it -- second, or last? We'd have to decide to follow -> or pipe, & I don't know that one makes more sense than the other. I think it's most straightforward to require that one manually places the symbol for all cases other than the non-list. > Is it worth considering how (doto) fits into the picture? My initial > observation is that (doto) is orthogonal in the sense that its primary > use is for java object manipulation, and there is never a use case to > have arguments in different places for that. So I suspect doto is > irrelevant. I agree -- doto assumes methods that mutate an object, & I think those are always going to be of the form (.method object [args]). Best, Perry --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: why (seq? [1 2 3]) yields false?
wubbie,
In case you're asking because you're trying to test for collection-
like objects, there are (at least) two ways to do so:
1. coll? tests if its arg implements IPersistentCollection, i.e. is
one of the native Clojure persistent collections:
user=> (map coll? [{} [] '() #{}])
(true true true true)
2. the (if (seq coll) ...) idiom (you'll see a lot of it in
clojure.core) tests if the coll arg is seq-able, i.e. can be viewed as
a seq as Steve says above. This test will match for more than just the
Clojure collections, e.g.
user=> (if (seq "hello") true false)
true
user=> (if (seq (into-array Character/TYPE [\a \b \c])) true false)
true
user=> (if (seq (doto (java.util.HashMap.) (.put "key" "val"))) true
false)
true
Since seq is lazy, simply calling seq realizes no elements from the
seq-able thing.
Note, however, that seq will throw an error if given a non-seq-able
item like an integer (this is because the (if (seq coll) ...) test
involves actually calling seq on the arg...). Which means that it's
only safe for contexts in which you know the arg will be seq-able or
empty.
Best,
Perry
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---
Re: Fully lazy sequences are coming - feedback wanted!
I agree with the majority of posters that the breaking changes in the
service of optimal names is the right way to go.
I found the explanation & recipe for porting at clojure.org/lazier
clear & easy to follow. I didn't do full ports of any projects, but I
did some selective porting & found it to be straightforward.
That said, the only problem I see is with the names. Like Mibu, I
think "next" isn't ideal -- it connotes an item in an iteration to me.
If you think "next *seq*" when you see "next" (how Rich explains it
at /lazier), it helps, but it's still not exactly right; or it
requires a different mental model from the non-lazy-branch "rest": the
cursor moving to the "next" item rather than the abstracted "rest of
the coll" (where you think about a cursor).
I think the issue is that "rest" is the right name for both rest &
next. The only difference between them, from the perspective of users,
is how empty rests are represented ('() or nil), & that's a hard
distinction to make manifest in a short name.
If it's the case that rest will almost exclusively appear in the
context of constructing lazy-seqs
(lazy-seq
(cons [something] (rest [something]))
& next will appear all over, it makes sense to me to sacrifice brevity
in the case of rest, & give next the right name: "rest" (that's
tortuous, I know).
rest* isn't quite right, but you get the idea: make the fully-lazy
rest the special-kind-of-rest, & the consumer-code rest the
transparent one. This way, people's concepts about recursing through
seqs of colls & testing for the end won't have to change; they'll only
have to change their understanding of how to make lazy sequences. I
know in my code I do a lot more of the former.
Anyone who's on board with this line of thought have ideas for the
right name of fully-lazy rest?
Best,
Perry
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---
Re: Fully lazy sequences are coming - feedback wanted!
> cursor moving to the "next" item rather than the abstracted "rest of > the coll" (where you think about a cursor). Correction: where you *don't* think about a cursor... Perry --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
clojure.core.read-line broken
On the most recent svn (r1293), read-line throws a ClassCastException when called: user=> (read-line) java.lang.ClassCastException: clojure.lang.LineNumberingPushbackReader cannot be cast to java.io.BufferedReader (NO_SOURCE_FILE:0) Removing the type hint solves the issue: user=> (source read-line) (defn read-line "Reads the next line from stream that is the current value of *in* ." [] (. #^java.io.BufferedReader *in* (readLine))) nil user=> (.readLine *in*) this is a line "this is a line" Perry --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: clojure.core.read-line broken
On Feb 18, 12:27 pm, "Stephen C. Gilardi" wrote: > This is from issue 47, svn 1229. It's unfortunate that a class can't > be both a BufferedReader and a PushbackReader simultaneously. Those > classes were implemented using class inheritance rather than via > interfaces. In this case, the default *in* is not a BufferedReader, > but does provide readLine. It looks to me like removing the hint is > the correct fix. Thanks, Steve -- I wasn't able to track down which revision introduced the breakage. Now I understand the motivation (avoiding reflection): user=> (set! *warn-on-reflection* true) true user=> (.readLine *in*) Reflection warning, line: 2 - reference to field readLine can't be resolved. hello "hello" user=> (.readLine #^clojure.lang.LineNumberingPushbackReader *in*) hello "hello" &, if I follow, the latter isn't robust because we need to allow for *in* to be dynamically rebound, & wouldn't want to require that it's always a LineNumberingPR. Some microbenchmarking (details below) shows that doing an instance? check combined with type hinting is almost twice as fast as relying on reflection, & hardly slower than the type-hinted code w/o an instance? check. How does the following implementation strike you? (defn r-l [] (if (instance? clojure.lang.LineNumberingPushbackReader *in*) (.readLine #^clojure.lang.LineNumberingPushbackReader *in*) (.readLine #^java.io.BufferedReader *in*))) Best, Perry --- 10 runs w/o type hinting: 0.119 msecs (avg) -- user=> (time (.readLine *in*)) "hello" "Elapsed time: 0.105 msecs" " \"hello\"" user=> (time (.readLine *in*)) "hello" "Elapsed time: 0.116 msecs" " \"hello\"" user=> (time (.readLine *in*)) "hello" "Elapsed time: 0.113 msecs" " \"hello\"" user=> (time (.readLine *in*)) "hello" "Elapsed time: 0.122 msecs" " \"hello\"" user=> (time (.readLine *in*)) "hello" "Elapsed time: 0.153 msecs" " \"hello\"" user=> (time (.readLine *in*)) "hello" "Elapsed time: 0.108 msecs" " \"hello\"" user=> (time (.readLine *in*)) "hello" "Elapsed time: 0.11 msecs" " \"hello\"" user=> (time (.readLine *in*)) "hello" "Elapsed time: 0.115 msecs" " \"hello\"" user=> (time (.readLine *in*)) "hello" "Elapsed time: 0.125 msecs" " \"hello\"" user=> (time (.readLine *in*)) "hello" "Elapsed time: 0.124 msecs" " \"hello\"" --- 10 runs with (r-l) func: 0.058 msecs (avg) --- user=> (time (r-l)) "hello" "Elapsed time: 0.055 msecs" " \"hello\"" user=> (time (r-l)) "hello" "Elapsed time: 0.055 msecs" " \"hello\"" user=> (time (r-l)) "hello" "Elapsed time: 0.064 msecs" " \"hello\"" user=> (time (r-l)) "hello" "Elapsed time: 0.061 msecs" " \"hello\"" user=> (time (r-l)) "hello" "Elapsed time: 0.057 msecs" " \"hello\"" user=> (time (r-l)) "hello" "Elapsed time: 0.056 msecs" " \"hello\"" user=> (time (r-l)) "hello" "Elapsed time: 0.058 msecs" " \"hello\"" user=> (time (r-l)) "hello" "Elapsed time: 0.062 msecs" " \"hello\"" user=> (time (r-l)) "hello" "Elapsed time: 0.054 msecs" " \"hello\"" user=> (time (r-l)) "hello" "Elapsed time: 0.061 msecs" " \"hello\"" --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: clojure.core.read-line broken
Hope I didn't imply by the above that I was suggesting a name change. I know my proposed version is ugly, but since BufferedReader & LineNumberingPR can't be unified, special-case-ing for the latter strikes me as an acceptable fix. But removing the type hint so that the function works out of the box is the next best option. (I know the above microbenchmarking is dubious & smacks of premature optimization, especially for a function whose use case, at least for me, is command-line interaction -- which is not performance-critical. But then I thought about reading strings from stdin, which could be; but perhaps a (line-seq) on a wrapped System/in would be better anyway...) Perry --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: :use feature requests
+1 from me, too. As to an :all shortcut that's synonymous with :exclude (), I think convenience at the REPL is a good argument for :all. (I'm assuming that the `require` macro would disappear, too.) For Cosmin's thought (:as mutually exclusive with :exclude, :only, & :rename), it does seem to me that when one is aliasing a namespace, one wouldn't have a need to exclude or rename any functions (because there's no chance of conflict or namespace pollution). Does anyone disagree? I do like James Reeves suggestion, but only if it's easy enough to implement; also, it seems mostly like a trade of outer parens for inner brackets -- in the end you'll have the same number of wrapping characters... Perry --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: dorun and map
The dynamic resource consumption discussion is interesting & I'm curious about scope, but just to be clear about side-effects in the case of: (dorun (map #(println %) my-vector)) The idiomatic way to do this is (doseq [i my-vector] (println i)) Perry --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: "Adding" strings
> Is there any reason that str is limited to 2 arguments? It would be > nice to do (str "foo" "bar" "baz") --> "foobarbaz". Try it! (Hint: "With more than one arg, returns the concatenation of the str values of the args.") > Is there a good reason that + can't do the right thing as with other > Java and scripting languages? I think this would be popular with > non-LISPers. I think any desire for that disappears once you discover str, but the implementation reason against it is that it'd require arg checks for +, which you want to be fast. Look at the source for + & str -- they're both optimized for what they do. Perry --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
contrib build errors after javadoc => repl-utils
Hi Christophe Grand or other contrib committers, clojure.contrib.javadoc should be removed from the list of libs to compile in the build.xml file; as it stands, building with ant throws the Exception that fires when c.c.javadoc is compiled. Best, Perry --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Problems with read-line
Hi, This was fixed at SVN revision 1321 on Mar 3: http://code.google.com/p/clojure/source/detail?r=1321 David, the lazy branch was merged into trunk (at r1287) -- track trunk & you'll have what you need (lazy-seq, not lazy-cons). Best, Perry --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: clojure.core.read-line broken - can we please fix it?
Just for the record, this problem with read-line was fixed at SVN r1321. (Thanks for packaging up the patch, Chouser.) Perry --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Proposed Change to str-utils
Whatever it's worth as a datum, my experience is that I usually find myself writing upcase, downcase, titlecase functions in most applications, because (1) they're prettier & more succinct when passed as first-class (downcase vs. #(.toLowerCase %)) (2) I can add type hints once, in the downcase, upcase, etc. functions, instead of doing so at each invocation (#(.toLowerCase #^String %)) I think (2)'s the most compelling reason. The type-hinting situation in Clojure is currently pretty impressive, I've found; a relatively small number of hints strategically placed usually eliminate most or all of the reflection that occurs in my first draft of functions. But many string-processing operations -- for whatever reason -- usually need a manual hint. I agree that it's not desirable to balloon the Clojure API with thin wrappers on the Java APIs, but, like pc, think this might be an exception. I'm less sure about the other proposed changes to str-utils -- the variable-arity versions of re-split, -partition, -sub, -gsub. Maybe a regex-parse lib in contrib would be a better place? Perry --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: proposed new contrib: java-utils
Hi Stuart,
I had occasion to wrap java.util.Properties. If there's interest, may
be a good candidate for c.c.java-utils.
It's pasted in below, & attached in the group at
http://clojure.googlegroups.com/web/props.clj
Feel free to change as you see fit.
Best,
Perry
(ns props
; Convenience lib for interacting with java.util.Properties
(:use [clojure.contrib.duck-streams :only (reader writer)]
[clojure.contrib.java-utils:only (the-str)])
(:import (java.util Properties)))
(defn props-to-map
"Convert Properties to map."
[p]
(into {} p))
(defn map-to-props
"Convert map to Properties."
{:tag Properties}
[m]
(let [p (Properties.)]
(doseq [[k v] m]
(.setProperty p (the-str k) (str v)))
p))
(defn read-props
"Read Properties from file into map. Uses duck-streams/reader to
read from file,
so duck-streams/*default-encoding* determines character decoding."
[file]
(props-to-map
(with-open [rdr (reader file)]
(doto (Properties.)
(.load rdr)
(defn write-props
"Write Properties from map into file. Uses duck-streams/writer to
write to file,
so duck-streams/*default-encoding* determines character encoding."
{:tag Properties}
([m file] (write-props m file nil))
([m file comments]
(with-open [wtr (writer file)]
(doto (map-to-props m)
(.store wtr comments)
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---
Re: reading properties file: does this helper already exist?
Hi Stuart, Not sure if you saw my post at http://bit.ly/sRnfG (links to list), or the props.clj file in the Google Group. In short, it's got a Properties reader & writer function. It tries to make Properties look like more native Clojure maps (i.e.keywords for keys), & it also uses duck-streams file readers & writers, which means that ISO-8859-1 encoding isn't assumed for files (which seems like a good thing to me, but I'd sympathize if others didn't). If you didn't see it, I offer it hoping you'll use what you think's useful; if you did, don't think a writer's useful as well? Best, Perry --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: reading properties file: does this helper already exist?
I think the consensus is that 1.5 is the target, so I've attached props.1.5.clj to the group, which is 1.5 compatiblle (i.e. uses streams, not readers or writers). Best, Perry On Apr 8, 6:49 pm, Stuart Halloway wrote: > Perry, > > Cool -- I will add this pending the result of the Java 6 thread I am > about to launch. > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: reading properties file: does this helper already exist?
As of 12:30 (Central Standard), a better props.1.5.clj is in Groups -- sorry for the revision if you've already looked. Perry On Apr 9, 10:55 am, Perry Trolard wrote: > I think the consensus is that 1.5 is the target, so I've attached > props.1.5.clj to the group, which is 1.5 compatiblle (i.e. uses > streams, not readers or writers). > > Best, > Perry > > On Apr 8, 6:49 pm, Stuart Halloway wrote: > > > > > Perry, > > > Cool -- I will add this pending the result of the Java 6 thread I am > > about to launch. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: reading properties file: does this helper already exist?
Hi Stu,
> Too late :-). I have already committed (r659) -- take a look and see
> if you are happy with the changes I made.
> Stu
Thanks -- looks great to me. One remark: how about returning a map
from read-properties (by wrapping the body with
(into {} )
)? I know you can just destructure the Properties object, but it seems
most transparent to get the Properties' pairs into a Clojure map as
soon as possible. Your call.
& hi Stuart,
> By the way, recent versions of duck-streams assume UTF-8 unless you
> rebind *default-encoding*.
> -Stuart S.
Indeed -- I'm grateful for it! The tricky bit about Properties is that
Java always reads & writes them as ISO-8859-1. In 1.6, you can read &
write Properties to file with Readers & Writers, in which case duck-
streams would've been ideal; as you say, enoding could've been
controlled through binding *default-encoding*. The extra control there
would be nice, but it's certainly not a reason to change Clojure's JVM
dependency...
Best,
Perry
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---
Compojure's decorate-with into contrib?
I'm trying to figure out the best way to use clojure.core/memoize while retaining the original function's docstrings, tags, etc. for the memoized function. The best way I've seen to do this is James Reeves' decorate-with function from Compojure, which applies a "decorator" -- Python's name for a higher-order function, like memoize, that takes a function f & returns f' that's a version of f modified in some useful way -- to already-defined functions, like (defn costly-fn [x] (costly-computation x)) (decorate-with memoize costly-fn) The most useful thing about decorate-with is its side-effecting code that redefines the root binding of the costly-fn var while keeping its original metadata. This is done by the redef function, which is (with a few minor differences from the Compojure version): (defmacro redef "Redefine an existing value, keeping the metadata intact." [name value] `(let [m# (meta (var ~name)) v# (def ~name ~value)] (alter-meta! v# merge m#) v#)) Question: is there a better way of using decorators than this? If not, is there any interest in including redef & decorate-with (see below) in contrib, either, perhaps, in c.c.def or c.c.macros? Thanks, Perry (defmacro decorate-with "Wrap functions in a decorator." [decorator & funcs] `(do ~@(for [f funcs] `(redef ~f (~decorator ~f) Compojure's compojure.control library: http://bit.ly/17U7m --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: UTF-8
For those on OS X -- who probably don't want the default MacRoman -- or anyone else who wants to override the system default, I wanted to point out that setting the "file.encoding" system property when invoking java (e.g. `java -Dfile.encoding=UTF-8 ... clojure.main`) will set the encoding for in, out, & err. If you want to override globally, this is easier than re-binding the vars. Perry --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: HTTP clients in clojure
> Let me know if you find it useful. I would love to get some comments.
> -Phil
Hi Phil,
I'm trying out clojure-http-client, & thus far I like the idea of it
quite a bit: a simple but clever wrapper on built-in JDK APIs, so
provides convenience w/o the burden of external jars.
Quickly, I ran into problems with the resourcefully/with-cookies
macro. Making two changes to resourcefully.clj & altering the
signature from the example made it work (but I didn't test too
rigorously).
Re: altering the signature, the example use of with-cookies in the
file is
(with-cookies (get ...) (post ...) ...)
but the macro expects the first argument to be a (possibly nil?)
cookies map, like this
(with-cookies {} (get ...) (post ...)) OR (with-cookies nil
(get ...) (post ...))
Re: changes to resourcefully, here's the diff:
diff --git a/src/clojure/http/resourcefully.clj b/src/clojure/http/
resourcefully.clj
index 0376df8..358c157 100644
--- a/src/clojure/http/resourcefully.clj
+++ b/src/clojure/http/resourcefully.clj
@@ -44,7 +44,7 @@
map. Cookies will be saved if inside with-cookies block.")
[u# & [headers# body#]]
(let [response# (save-cookies (client/request u# ~(str method)
- headers# *cookies*
body#))]
+ headers#
@*cookies* body#))]
(if (error? response#)
(throw (java.io.IOException. (error-message response#)))
response#
@@ -59,5 +59,5 @@ map. Cookies will be saved if inside with-cookies
block.")
"Perform body with *cookies* bound to cookie-map. Responses that
set
cookies will have them saved in the *cookies* ref."
[cookie-map & body]
- `(binding [*cookies* (ref (or cookie-map {}))]
+ `(binding [*cookies* (ref (or ~cookie-map {}))]
~...@body))
The gist is that (1), in with-cookies, the parameter "cookie-map" must
be unquoted & thus evaluated to the value passed in -- w/o the unquote
cookie-map gets namespace-qualified to the var resourcefully/cookie-
map, which doesn't exist. (2) in the define-method macro, the
*cookies* ref must be dereferenced when passed to client/request,
because client/request expects a map, not a ref.
Thanks for the lib. I for one would appreciate its inclusion in
contrib once it gets a little more testing.
Best,
Perry
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---
Re: ANN: VimClojure v2.1.2 released
On Jul 26, 4:09 am, Meikel Brandmeyer wrote: > I'd like to announce a bugfix release for VimClojure. Thanks, as ever, Miekel. > * Fixed annoying o/O delay bug A dream cometrue! Perry --~--~-~--~~~---~--~~ 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: do clojure and la(tex) have something in common ?
Hi Mike, On May 25, 9:04 am, Mike Meyer wrote: > I find the reference to "old fashioned xslt" amusing, considering that > how new it is. Or maybe how old I am. Of course, part of the point of > XML is that you have a wide variety of tools to pick from for working > with it; xslt is just one of them. I've had good experiences just > adding an xpath library to a good language. A clojure xpath library > that returned result sets as lazy sequences sounds like a really cool > way to do this, though that would again be just a single component in > such a system. Re: a clojure XPath/XQuery library that returns a lazy seq of the results, check out my wrapper of Michael Kay's Saxon library: http://github.com/pjt/saxon Saxon computes XPath results mostly lazily, & I retain this laziness in my wrapper. (I say "somewhat" because Saxon stays one result element ahead of realization.) Best, Perry -- 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: do clojure and la(tex) have something in common ?
On May 28, 10:35 pm, Dave Pawson wrote: > > Which Saxon have you wrapped please? > saxon655 or Saxon9he? Currently I'm wrapping the last Saxon 9B before the switch to the three-way split. I plan to stick with it until there's a reason not to; there are some features of B I'd rather not be without, like saxon:eval() in stylesheets. Best, Perry -- 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 / ruby yield comparison
> For example, the macro '->' changes this: > > (-> x (foo y) (bar z)) > > Into this: > > (foo (bar x z) y) Small correction. The result above should be: (bar (foo x y) z) user=> (macroexpand '(-> x (foo y) (bar z))) (bar (clojure.core/-> x (foo y)) z) Perry --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Leiningen uberjar: excluding dev-dependencies; new minus-clojure task
Greetings, Currently for the Leiningen uberjar task, all dev-dependencies are included in the resulting standalone jar. In a comment in uberjar.clj, there's a note that excluding these is on the todo list. I wonder if there are any ideas on how best to do it? I tried to tackle this in a naive way — finding jar files based on the project name — but this doesn't catch dependecies futher down the chain, e.g. for lein-clojars this'll find the lein-clojars.jar but won't find jsch.jar, its dependency. More maven-aware folks may have better ideas, but how does this solution sound: segregating dev- dependencies in the /lib/dev directory upon download? For lein tasks that construct the project classpath, lib/dev would then be included in it; for the uberjar task, only jars in the lib directory would be zipped up. I was working on uberjar because I want to write a similar task as a plugin, which is an uberjar without clojure & clojure-contrib included, so that I can drop a project & its dependencies in my local Clojure development environment, e.g. my Clojure saxon wrapper library as well as the Java Saxon jars it depends on. Anyone else have this use case? Perry -- 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 uberjar: excluding dev-dependencies; new minus-clojure task
On Jan 2, 12:35 am, Phil Hagelberg wrote: > I'm a little reluctant to make calculating the classpath any more > complicated than it currently is since that logic needs to be duplicated > in a few places, but I agree that the current situation is not great. > > Another idea would be to write a hidden blacklist file when fetching the > dev dependencies. The uberjar could then check that to know which jars > to skip. > > I'm not sure which approach I prefer... thoughts? I thought about the latter, too. I don't currently understand the maven stuff enough to know how dependencies get resolved into actual jarfile names enough to do this (there's the DependenciesTask &c. business in leiningen/deps.clj), but I'd be happy to investigate, esp. if someone were willing to point me in the right direction. > > I was working on uberjar because I want to write a similar task as a > > plugin, which is an uberjar without clojure & clojure-contrib > > included, so that I can drop a project & its dependencies in my local > > Clojure development environment, e.g. my Clojure saxon wrapper library > > as well as the Java Saxon jars it depends on. Anyone else have this > > use case? > > I'm not sure I understand. Why don't you just open your saxon wrapper > project in your IDE directly rather than adding an uberjar generated > from it? Plus if you put clojure and contrib on the classpath before > youruberjar, then the versions in your uberjar will be shadowed. I wasn't clear. By "development environment," I meant my `clj` script, not any particular project per se. In my clj script, I specify a place on the filesystem to drop jars that I want on the classpath when its invoked; I know others have setups like this. I always put clojure & clojure-contrib on the classpath, so I simply want the Clojure library & any of its dependencies zipped up in a sort of uberjar-minus-clojure (to avoid shadowing, as you mention). I suppose I could create a leiningen project for my clj script, specifying libraries I want as dependencies & then just putting its uberjar on the classpath, but this requires that the libraries are available in maven repos. Have other leiningen users solved this? Thanks, Perry -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Bug with Clojure 1.2 REPL (aka master branch) ?
On Jan 12, 8:58 pm, aria42 wrote: > I was seeing this error too and I reckoned it was because my > clojure.contribwas not compatible with clojure core. I think if > you're using1.2master of clojure you need 1.1 master ofcontrib. Is that right? The 1.1 new branch of Contrib is compatible, at least for the moment, with the 1.2 master of Clojure. Has there been talk about making an official 1.2-compatible Contrib? Or, I suppose, after the 1.1 RC2 is accepted, Contrib development will track Clojure's HEAD & make a 1.1-compatible branch? Perry -- 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's the best way to do this?
I think it's easier to think about combining predicates separately from your file-filtering code. I'd use a higher-order function like the following (defn combine-preds [& preds] (fn [& args] (every? #(apply % args) preds))) then filter files like (filter (combine-preds pred1 pred2) (file-seq in-dir)) Perry On Jan 21, 2:08 pm, nwalex wrote: > Brilliant. Thanks Dan, that did the trick. > > On Jan 21, 8:01 pm, Dan Schmidt wrote: > > > > > I don't know how efficient it is (or how idiomatic it really is), but > > this should work: > > > (defn find-files > > "Find files in directory that match predicates pred & others" > > [in-dir pred & others] > > (reduce (fn [xs f] (filter f xs)) (file-seq in-dir) (cons pred others))) > > > Dan > > > On Thu, Jan 21, 2010 at 2:47 PM, nwalex wrote: > > > I'm very new to Clojure, and to functional programming in general. Can > > > anyone tell me the idiomatic way to implement this function? > > > > (defn find-files > > > "Find files in directory that match predicates pred & others" > > > [in-dir pred & others] > > > (filter pred (file-seq in-dir))) > > > > What is the best way to filter a sequence using multiple predicates? I > > > want to return a sequence containing the files that match predicate > > > pred and all other predicates bound to 'others'. > > > > -- > > > 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: Dependency management
On Jan 21, 7:21 pm, Richard Newman wrote: > 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...?) Richard, this doesn't address your larger points, but I wanted to make sure you're aware of http://build.clojure.org which is a maven repo for clojure & contrib artifacts. At /snapshots, there are builds for Clojure 1.2 (1.2.0-master-SNAPSHOT). Leiningen is aware of this repo by default, so you can specify the 1.2.0-master snapshot as a dependency in your project.clj. Perry -- 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 uberjar: excluding dev-dependencies; new minus-clojure task
On Jan 28, 12:09 am, Phil Hagelberg wrote: > Perry Trolard writes: > Any time you have dependencies that aren't in repositories, it's going > to cause pain. It's much better to put them in a repository, even if > it's a private/local one, than to bend Leiningen to work with bare jars. > > -Phil Fair enough, though I think it was more a case of asking Leiningen to produce bare jars for use outside of its environment — e.g. standalone executables, the point of uberjar. In case others are interested (& it isn't too obvious to mention), I did end up using Leiningen to take care of my `clj` script setup. I found that it greatly simplified things compared to the filesystem- based configuration I used before. The project.clj looks like (defproject clj "1.0.0-SNAPSHOT" :description "Jar for `clj` CLI script." :main clojure.main :dependencies [[org.clojure/clojure "1.2.0-master-SNAPSHOT"] [org.clojure/clojure-contrib "1.1.0-new-SNAPSHOT"] [clojure-saxon "0.9.0-SNAPSHOT"] [clojure-http-client "1.0.0-SNAPSHOT"]]) & my `clj` script is now - #!/bin/bash jopts='-Xmx256m -server -Dfile.encoding=UTF-8' cp=~/software/clojure/clj/clj-standalone.jar # add to the classpath if [[ $1 == "-cp" ]]; then shift cp=$cp:$1 shift fi # print the classpath if [[ $1 == --print-c* ]]; then echo $cp exit 0 fi exec rlwrap java $jopts -cp $cp clojure.main "$@" Perry -- 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: User defined extensions with Xpath
Hi Andrei, I'm the author of the saxon wrapper library at https://github.com/pjt/saxon. User-defined XPath functions are indeed desirable but I haven't done anything special in the library to help in implementing them. What's available by default in Saxon is the ability to call Java methods. For static methods, you associate a namespace in the XSLT document with a class in Java, as in "nav" below: Then you can call static methods of that class as if it were an XPath function, e.g. Combine this with Clojure's class-generation facility (http:// clojure.org/compilation) & you can pretty easily see how to go about writing Clojure extension functions. This isn't as convenient as one could imagine, but it's a way to do it right now. Best, Perry On Mar 1, 10:40 am, Trastabuga wrote: > Hi > I am eager to try out Clojure for my new web site. But for that I need > XSLT support, like I used to have on Common Lisp (Xuriella XSLT) and > also XPath support (like Plexippus XPath). > I saw the saxon wrapper among the Clojure libraries but in its docs I > couldn't find how they define user extensions. I wonder if Clojure has > a library or some support for that now. > To illustrate what I need is when you create your xsl page you should > be able to define your extensions in lisp so that you can use it like > this: > > xmlns:xsl="http://www.w3.org/1999/XSL/Transform"; > xmlns:func="http://www.yourwebsite.com/func";> > ... > > .. > > > Where my-lisp-function is the user defined extension in the > "http://www.yourwebsite.com/func"; namespace. > Thank you, > Andrei -- 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: I cannot scroll up down REPL in konsole
Antonio, Apologies if this is obvious to you, but screen eats your scrollback lines. You can't use the terminal program's scroll bars; you've got to enter screen's copy mode to view history. It's a little jarring at first, but with the vim-style navigation keys & the ease of copying it allows, copy mode's actually pretty handy. Perry -- 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: Patch: universal main() with repl/script/compile
Very cool. The two main use cases work well (REPL, script), & the others -- loaded files, evaluation -- are real bonuses. (It's also really nice to have an extensible REPL implemented in Clojure). I think a flag for file loading (-l, --load) to make clear the distinction b/w the file that's a script & the files which are loaded beforehand woud be nice; but not nice enough to justify what seems to be the added complication to the argument-processing code (it'd require processing all args at once, not serially, it seems; or would require stipulating an order to arguments...). Regarding clojure.lang.Compile: this is incredibly handy! Thanks. What do think about adding a default value to the clojure.compile.path system property (./classes)? Perry --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Patch: universal main() with repl/script/compile
On Nov 24, 4:03 pm, Stuart Sierra <[EMAIL PROTECTED]> wrote:
> Hi Perry, Stephen,
> I like the "convention over configuration"-ness of defaulting to ./
> classes. One thought: Weird errors might result if ./classes is not
> on classpath. Is there an easy way to check that, and display a
> helpful error message?
>
Right, good idea. It would just take checking to see if the "path"
variable is in System.getProperty("java.class.path"), right?
--
Answer: no. I tried the approach below against Stephen's
clojure.lang.Compile, & the ant build process failed. All of the
classes currently on the classpath are evidently not reflected in the
system property -- at least when running in Ant. (I believe they would
be when invoking java w/ the -cp option.)
FAILED APPROACH -
Boolean found = false;
for ( String cp : System.getProperty("java.class.path").split(":") ) {
if (cp == path) {
found = true;
}
}
if (!found) {
err.println("System property " + PATH_PROP + " (the current value
of "+
"which is" + path +") must be in your
CLASSPATH.");
System.exit(1);
}
-
Another approach would be to just catch the
java.lang.ClassNotFoundException that would be triggered if the
clojure.compile.path isn't on the classpath. Better ideas, Stephen?
Perry
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---
Re: Patch: universal main() with repl/script/compile
I've written a preliminary cljc script -- a shell script for compiling
Clojure libs -- against Stephen's patched Clojure (specifically using
the clojure.lang.Compile class).
Configure the script with the locations of the clojure.jar & clojure-
contrib.jar & running cljc w/o options calls clojure.lang.Compile on
command-line args representing libs or namespaces. With options, it
can (1) wrap the contents of the build directory (hard-coded to be
"classes") into a jar file (with the first lib set to Main-Class) or
(2) wrap the contents of the build directory, the contents of
clojure.jar, & the contents of the clojure-contrib.jar into a jar file
(with the first lib set to Main-Class).
For example, if I have a Clojure lib in hello.clj
- hello.clj
(ns hello)
(defn reverse-string
[s]
(apply str (reverse s)))
(defn -main
[& args]
(println (apply str (mapcat reverse-string (interpose " " (reverse
args))
-
& I call cljc in the same directory like this:
cljc -a hello
I'll get a jar file I can call like
java -jar hello.jar dlroW olleH
with these results
Hello World
That is, it's standalone (albeit at 1.4 Megs!).
Anyone who's built Stephen's patch can try it out; others please feel
free to offer suggestions.
Thanks,
Perry
--
#!/usr/bin/env bash
# cljc: Clojure lib compiler
cjar=PATH/TO/clojure.jar
ccjar=PATH/TO/clojure-contrib.jar
build=classes
usage()
{
echo "Usage: $0 [options*] lib+"
echo "Options:"
echo " (-cp|--classpath) list: colon-separated list of
directories or jar files to add to classpath"
echo " (-j|--jar): turn on creation of jar file"
echo " (-n|--name) name: specify the name of created jar file"
echo " (-a|--all): turn on inclusion of all jars in jar file
(clojure.jar and clojure-contrib.jar) -- will turn on --jar option as
well"
# echo " (-e|--extra-jars) list: colon-separated list of jars to
include in created jar file"
echo " (-h|--help): display this usage information"
echo
echo "If creating a jar file, the first lib listed will be the Main-
Class in the jar's MANIFEST."
}
while [ $# -gt 0 ]; do
case $1 in
-cp | --classpath ) shift; cp=$cp:$1; shift;;
-a | --all ) shift; all=true; jar=true;;
-j | --jar ) shift; jar=true;;
# -e | --extra-jars) shift; extra=$1; shift;;
-h | --help ) usage; exit 1;;
-n | --name ) shift; name=$1; shift;;
* ) break;;
esac
done
if [ -z "$1" ]; then
usage
exit 1
fi
mkdir -p $build
java -cp $cp:$cjar:$ccjar:$build clojure.lang.Compile "$@"
if test $jar; then
name=`! test -z $name && echo $name || echo $1`
jar cfe $name.jar $1 -C $build .
if test $all; then
tmp=scratch-temp-dir
mkdir $tmp && cd $tmp
for jar in $cjar $ccjar; do
jar xf $jar
done
cd -
jar uf $name.jar -C $tmp clojure
rm -r $tmp
fi
fi
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---
Re: Patch: universal main() with repl/script/compile
On Nov 25, 8:42 am, Stuart Sierra <[EMAIL PROTECTED]>
wrote:
> I think it's because of different string representations of the path
> (e.g. the path variable may be "./classes" but the classpath (under
> Ant) is "/home/bob/project/classes". It probably need something like
> this:
> ...
Yeah, I thought of the same, but when I dump the results of
System.getProperty("java.class.path"), my classes directory doesn't
show up -- running under the Ant task, on my machine, at least. It
would if passed as an arg to java -cp, but the Ant is the first case
where Compile's got to work.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---
Re: Patch: universal main() with repl/script/compile
Sorry -- inadvertent send: the Ant task is the first case that's gotta work, so I think the best option is to catch the ClassNotFound exception, unless there's another alternative I'm not thinking of (& given my small amount of knowledge of Java proper, the chances of that are high!). Perry --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Patch: universal main() with repl/script/compile
> Is the classpath set up in the Ant task? It should look
> something like this:
>
> Near the top:
>
>
> In the compile_clojure task:
> classpath="${build}:${cljsrc}">
>
>
> ...and so on...
>
> There have been so many patches on this, I'm not sure which one you
> have.
> -S
Yes, that's the build.xml I have. If I add
err.println(System.getProperty("java.class.path"));
to clojure.lang.Compile, it gives me all of the Ant jars (included
below, but no need to scrutinize) but neither the $build or $cljsrc
directories set in build.xml.
Is there somewhere else to get a comprehensive list of the CLASSPATH?
Perry
java.class.path at time of clojure.lang.Compile's being called by Ant:
/usr/share/ant/lib/ant-launcher.jar:/usr/share/ant/lib/ant-jai.jar:/
usr/share/ant/lib/ant-jmf.jar:/usr/share/ant/lib/ant-junit.jar:/usr/
share/ant/lib/ant-launcher.jar:/usr/share/ant/lib/ant-nodeps.jar:/usr/
share/ant/lib/ant-swing.jar:/usr/share/ant/lib/ant-testutil.jar:/usr/
share/ant/lib/ant-trax.jar:/usr/share/ant/lib/ant.jar:/usr/share/ant/
lib/xercesImpl.jar:/usr/share/ant/lib/xml-apis.jar
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---
Re: Patch: universal main() with repl/script/compile
Thanks for untangling the Ant black magic, Stefan. Forking a separate VM seems the simplest way to go. With that in mind, here ( http://bit.ly/17N0M ) is a patch (against r1125) that includes all of Stephen & Stuart's additions for the clojure.main function, plus the modifications to clojure.lang.Compile for checking if the clojure.compile.path sytem property is on the classpath. My modifications are 1) Adding the check in clojure.lang.Compile to see if the path defined in the clojure.compile.path (or "classes," if none's defined) is on the classpath, & exiting with an error message if not. 2) Adding @fork="true" to the task in build.xml, so that the classpath is available to clojure.lang.Compile when run w/in Ant. Not sure how robust a solution this is & or how satisfactory it will be, but here it is in case it helps finish the work you started, Stephen & Stuart. Pending Rich's approval, I'm anxious to see it included! Best, Perry --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Patch: universal main() with repl/script/compile
That's great -- happy it's in. Quick impression: I like the improvements to clojure.main, especially that forms from stdin & -e are evaluated after init files are loaded & *command-line-args* is set. Now that clojure.lang.Compile is official, I'll post a cleaned up version of my cljc script (but probably not until after T-giving) in case it's a useful starting point for others. Perry p.s. My CA is in the mail, but if you want to include the trivial classpath-checking code, Steve, I'm sure you can change it enough to claim copyright! --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
clojure.main default print function
With the adoption of the clojure.main at SVN r1127, the print behavior
of the REPL changed from prn-style to println-style, e.g.
;r1126
user=> (list "hey" 'hey)
("hey" hey)
;r1127 & on
user=> (list "hey" 'hey)
(hey hey)
I missed it when looking over Stephen's clojure.main code when
proposed, but I think the prior behavior is pretty clearly preferable.
Others?
(To make the change, the docstring on line 73 & the default function
on line 85 would both be changed from println to prn.)
Perry
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---
Re: clojure.main default print function
Clarification: clojure.lang.Repl's behavior hasn't changed, it's just that the clojure.main default REPL behaves differently from it. Those who don't call clojure.main in their clj scripts won't notice a difference. Perry --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Misplaced doc strings in clojure.contrib.seq-utils
In clojure.contrib.seq-utils, partition-by & group-by have docstrings following their arglists, so (doc parition-by) prints - clojure.contrib.seq-utils/partition-by ([f coll]) nil nil I'd submit a patch, but I'm sure it's easier if Stuart Sierra or another of the contrib committers just swith 'em around. Best, Perry --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
