Re: Got a Clojure library?
Name: clj-web-crawler URL: http://github.com/heyZeus/clj-web-crawler/tree/master Author: Brian Doyle Categories: Web, Automation License: MIT Dependencies: clojure, clojure-contrib, Apache commons-client 3.1 Description: clj-web-crawler is a wrapper around the Apache commons-client Java library that allows you to easily crawl the web in a functional way. On Wed, Apr 8, 2009 at 9:16 AM, Rich Hickey wrote: > > Added - thanks! > > Rich > > On Apr 8, 2009, at 3:43 AM, Remco van 't Veer wrote: > > > > > Name: clj-android > > URL: http://github.com/remvee/clj-android/ > > Author: Remco van 't Veer > > Categories: android framework > > License: MIT > > Dependencies: clojure > > Description: > > Basic application framework for building Android applications using > > Clojure. > > > > > > > > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Question about metadata on map keys
I just tracked down a bug in my code, which boiled down to this:
user> ^(key (first (assoc {[] :old-val} (with-meta []
{:some :metadata}) :val)))
nil
Namely, if a map already contains a given key, when you attempt to
assoc in a version of the key with new metadata this is not recorded.
It seems that the map always retains the original key:
user> (let [x [1]] (identical? x (key (first (assoc {[1] :val}
x :val2)
false
user> (let [x [1]] (identical? x (key (first (assoc {x :val}
[1] :val2)
true
Is this desired behavior? If so, is there a better way to change the
metadata on a key than first dissoc-ing it out and then assoc-ing it
back in again with new metadata?
Thanks!
Jason
--~--~-~--~~~---~--~~
You 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
-~--~~~~--~~--~--~---
Amb operator
So, I was wondering if anyone had implemented the amb operator in Clojure, so I decided to give it a try. This is my first Clojure program bigger then 5 lines, the code still needs ALOT of work, it is ugly as hell atm, but I think it kind of works. (Yes, I know, it's very easy to bug it, its just a sketch). Notice that unlike most continuation based amb operators, the amount of backtracking this implementation has to do depends on the order of the requires, not the amb assignments. If anyone wants to clear or improve the code, go ahead. I also would like to know how to be able to write @baker instead of the current (myderef baker), I tried using a proxy and implementing IDeref, but then I couldn't acess the amb-struct private data. Since Clojure doesn't have continuations I had to use a try catch block to do the stack unwinding, and some redundant calculations might be done because of it. Here is the code: (defstruct amb-struct :instance :orig :possible) (def amb-stack nil) (defn amb [choices] (struct-map amb-struct :instance false :orig choices :possible choices)) (defn myderef [a] (if (:instance @a) (:value @a) (do (set! amb-stack (cons a amb-stack)) (let [oldpos (:possible @a)] (var-set a (assoc @a :value (first oldpos) :instance true :possible (rest oldpos (:value @a (defn amb-require [condition] (if condition nil (do (throw (.Exception "nothing") (defn bindnext [] (if (empty? amb-stack) 'nomatchfound (let [lastbind (first amb-stack) oldpos (:possible @lastbind)] (if (empty? oldpos) (do (var-set lastbind (assoc @lastbind :instance false :possible (:orig @lastbind))) (set! amb-stack (rest amb-stack)) (recur)) (do (var-set lastbind (assoc @lastbind :value (first oldpos) :possible (rest oldpos))) 'recur) (defmacro amb-let [declarations & body] `(with-local-vars ~declarations (binding [amb-stack nil] (loop [] (let [retvalue# (try (do ~...@body) (catch Exception ~'except (bindnext)))] (cond (= retvalue# 'recur) (recur) true retvalue#)) (defn distinct-seq? [s] (cond (empty? (rest s)) true (= (first s) (second s)) false true (and (distinct-seq? (cons (first s) (rest (rest s (distinct-seq? (rest s) (amb-let [baker (amb [1 2 3 4 5]) cooper (amb [1 2 3 4 5]) fletcher (amb [1 2 3 4 5]) miller (amb [1 2 3 4 5]) smith (amb [1 2 3 4 5])] (amb-require (distinct-seq? (map myderef (list baker cooper fletcher miller smith (amb-require (not (= (myderef baker) 5))) (amb-require (not (= (myderef cooper) 1))) (amb-require (not (= (myderef fletcher) 1))) (amb-require (not (= (myderef fletcher) 5))) (amb-require (> (myderef miller) (myderef cooper))) (amb-require (not (= 1 (. java.lang.Math abs (- (myderef smith) (myderef fletcher)) (amb-require (not (= 1 (. java.lang.Math abs (- (myderef fletcher) (myderef cooper)) [['baker (myderef baker)] ['cooper (myderef cooper)] ['fletcher (myderef fletcher)] ['miller (myderef miller)] ['smith (myderef smith)]]) Running it returns [[baker 3] [cooper 2] [fletcher 4] [miller 5] [smith 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 To unsubscribe from 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: set-system-properties
Yes to almost all of this (r662). I am not totally comfortable with the false/"false" conversion. Stu > Hi Stuart H! Comment on: > > (defn set-system-properties > [settings] > "Set some system properties. Nil clears a property." > (doseq [[name val] settings] >(if val > (System/setProperty (as-str name) val) > (System/clearProperty (as-str name) > > > What if that were: > >(if (nil? val) > (System/clearProperty (as-str name)) > (System/setProperty (as-str name) (as-str val)) > > The change allows: > 1. Using boolean false as a value (converted to the string "false") > 2. Using keywords/symbols as values. > > > Also, get-system-property could support multiple arities: > > (defn get-system-property > ([stringable] (System/getProperty (as-str stringable))) > ([stringable default] (System/getProperty (as-str stringable) (as- > str default > > > -Stuart S > > > --~--~-~--~~~---~--~~ You 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: Java 6 dependency in clojure-contrib ok?
I would strongly recommend Java 5 and plan on staying with that version for a while if you have a goal seeing corporate uptake for Clojure. The Java version debate comes up every few months on the Groovy lists. The most common argument I've heard was that any company progressive enough to use a language like Groovy or Clojure would be using current versions of Java so there is no harm in using the current version of Java. My experience consulting for medium and large companies is that this is a false assumption. Most companies are years behind the current Java version but are still open to using new technologies that will run on their current platforms. The web app servers that get deployed usually lag way behind Java releases and converting legacy Java apps to newer versions of Java + app servers is a major project for many companies. They put it off for as long as possible. It may not make sense to those of us trying new languages on the JVM but it is a reality that is out there. Scott Hickey Senior Consultant Object Partners, Inc. From: Rich Hickey To: Clojure Sent: Wednesday, April 8, 2009 7:31:19 PM Subject: Re: Java 6 dependency in clojure-contrib ok? On Apr 8, 7:52 pm, Stuart Halloway wrote: > Perry's proposed props functions > (http://groups.google.com/group/clojure/browse_thread/thread/c8ec751b8... > ) uses some Java 6 methods. > > Is it ok for me to add such things to contrib, or are we maintaining > Java 5 compatibility? I'd prefer we maintain Java 5 for now. Rich --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from 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: "Transparent" delays
Hi Chas,
Have you considered wrapping the computation in a lazy sequence?
(lazy-seq [(expensive-calculation)])
The, instead of (force ...), you just use (first ...). I think
equality and hashing will automatically work like you want them to.
Cheers,
Jason
On Apr 9, 11:55 am, Chas Emerick wrote:
> I recently came across a situation where I very much wanted to delay
> the calculation of some values, but where I also wanted those delays
> to use their calculated values for equality determinations. This is
> particularly important when comparing vectors or maps that contain
> delayed values, where doing something like (= (force some-delay) some-
> value) isn't possible.
>
> So, I whipped up a tdelay (transparent delay) macro, an almost
> complete ripoff of clojure.core/delay, except that it creates
> instances of a subclass of clojure.lang.Delay that defers equality and
> hashcode calculations to the delay's value. The results:
>
> user=> (= {:a 5 :b (delay 12)} {:a 5 :b 12})
> false
> user=> (= {:a 5 :b (tdelay 12)} {:a 5 :b 12})
> true
>
> I get nervous when I screw around with equality in relatively sneaky
> ways like this, so I thought I'd toss this out on the list and see if
> anyone has any comments one way or the other.
>
> - Chas
>
> --
>
> (import '(clojure.lang Delay Util))
>
> (defn make-tdelay
> [fn]
> (proxy [Delay] [fn]
> (equals [other]
> (Util/equals (.deref this) (Delay/force other)))
> (hashCode []
> (Util/hash (.deref this)
>
> (defmacro tdelay
> [& body]
> (list 'make-tdelay (list* `#^{:once true} fn* [] body)))
--~--~-~--~~~---~--~~
You 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
-~--~~~~--~~--~--~---
Re: Java 6 dependency in clojure-contrib ok?
> > For what it's worth, I haven't upgraded from Tiger so I'm stuck with > Java 1.5, so I'd like to keep 1.5 compatibility. As an aside, I have Tiger and do stuff with Java 6 all the time. It's called soylatte: http://landonf.bikemonkey.org/static/soylatte/ The only thing is that I didn't know my install disk came with X11 for a LONGG time. This finally forced me to figure that out so I could install it (my soylatte version, at least, is dependent on having X11 running for some stuff). --~--~-~--~~~---~--~~ You 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: Java 6 dependency in clojure-contrib ok?
Our God has spoken. On Apr 8, 7:31 pm, Rich Hickey wrote: > On Apr 8, 7:52 pm, Stuart Halloway wrote: > > > Perry's proposed props functions > > (http://groups.google.com/group/clojure/browse_thread/thread/c8ec751b8... > > ) uses some Java 6 methods. > > > Is it ok for me to add such things to contrib, or are we maintaining > > Java 5 compatibility? > > I'd prefer we maintain Java 5 for now. > > Rich --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Is there a simple Clojure data schema/validation library?
On Thu, Apr 9, 2009 at 11:58 AM, samppi wrote: > I've been whipping up a simple schema library for validating Clojure > data based on their tags, but I'm worried that what I'm doing might be > redundant with an already existing library. Is there something, such > as in clojure-contrib, that can do things similar to the code below There's some similarity with the validation stuff in clj-record[1], but that's about DB persistence. (It also doesn't use metadata.) I was thinking about trying to tease clj-record apart so it could be backed by AppEngine's API for BigTable. Maybe I should also consider non-persistence-related uses of the parts where it makes sense. -hume. [1] http://github.com/duelinmarkers/clj-record/tree/master -- http://elhumidor.blogspot.com/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: DISCUSS: tests that read and write files
Stuart Halloway wrote: > concerns: > (1) Would like to see the file after a failed test. > (2) [...] I would be much more > comfortable not having to rely on code to write the file first. > Doesn't feel like a unit test. > > But I am much more interested in having a shared approach that all > contrib users adhere to than in getting my way. :-) Why not: (binding [*tmp-properties-file* (File/createTempFile "temp" ".properties")] (.deleteOnExit *tmp-properties-file*) (spit *tmp-properties-file* "contents of the test file") ...) ...wrapped in whatever macro if need be. Re: your (1): this way, you'll see it; it will be deleted when the jvm shuts down. Re: your (2): I personally wouldn't mind if we rely on contrib/spit as long as it's tested itself. :) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: "Transparent" delays
On Apr 9, 2:55 pm, Chas Emerick wrote:
> I recently came across a situation where I very much wanted to delay
> the calculation of some values, but where I also wanted those delays
> to use their calculated values for equality determinations. This is
> particularly important when comparing vectors or maps that contain
> delayed values, where doing something like (= (force some-delay) some-
> value) isn't possible.
>
> So, I whipped up a tdelay (transparent delay) macro, an almost
> complete ripoff of clojure.core/delay, except that it creates
> instances of a subclass of clojure.lang.Delay that defers equality and
> hashcode calculations to the delay's value. The results:
>
> user=> (= {:a 5 :b (delay 12)} {:a 5 :b 12})
> false
> user=> (= {:a 5 :b (tdelay 12)} {:a 5 :b 12})
> true
>
> I get nervous when I screw around with equality in relatively sneaky
> ways like this, so I thought I'd toss this out on the list and see if
> anyone has any comments one way or the other.
>
You shouldn't ignore your nervousness in this case:
user=> (= {:a 5 :b 12} {:a 5 :b (tdelay 12)})
false
The lack of symmetry makes this too fragile IMO.
Rich
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---
Re: DISCUSS: tests that read and write files
On Thu, Apr 9, 2009 at 3:57 PM, Stuart Halloway wrote: > > Three concerns: > > (1) Would like to see the file after a failed test. Unit tests should write their files to the temp directory (using the system property java.io.tmpdir). This way, unit tests do not pollute your project directory, and it is OK to leave the files around. Cheers, Victor Rodriguez. > (2) Also have tests that read a file, and I would be much more > comfortable not having to rely on code to write the file first. > Doesn't feel like a unit test. > > (3) The macro is more complex than the code being tested. :-) (The net > effect of my build.xml changes might also be...) > > But I am much more interested in having a shared approach that all > contrib users adhere to than in getting my way. :-) > > Stu > >> My recommendation would be to use a temporary file that is created and >> deleted in a macro or fixture. >> >> (defmacro with-tmp-properties-file [& body] >> `(binding [*tmp-properties-file* (File/createTempFile "temp" >> ".properties")] >> (spit *tmp-properties-file* "contents of the test file") >> ~...@body >> (.delete *tmp-properties-file*))) >> >> -Stuart Sierra >> >> >> On Apr 9, 1:54 pm, Stuart Halloway wrote: >>> In r659 I added a unit test to clojure-contrib that needed to read >>> and >>> write from the filesystem. I picked a dumb and simple convention, and >>> welcome review from other committers to move to something that is >>> just- >>> smart-enough. >>> >>> Stu >> > > > > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: DISCUSS: tests that read and write files
Three concerns: (1) Would like to see the file after a failed test. (2) Also have tests that read a file, and I would be much more comfortable not having to rely on code to write the file first. Doesn't feel like a unit test. (3) The macro is more complex than the code being tested. :-) (The net effect of my build.xml changes might also be...) But I am much more interested in having a shared approach that all contrib users adhere to than in getting my way. :-) Stu > My recommendation would be to use a temporary file that is created and > deleted in a macro or fixture. > > (defmacro with-tmp-properties-file [& body] > `(binding [*tmp-properties-file* (File/createTempFile "temp" > ".properties")] > (spit *tmp-properties-file* "contents of the test file") > ~...@body > (.delete *tmp-properties-file*))) > > -Stuart Sierra > > > On Apr 9, 1:54 pm, Stuart Halloway wrote: >> In r659 I added a unit test to clojure-contrib that needed to read >> and >> write from the filesystem. I picked a dumb and simple convention, and >> welcome review from other committers to move to something that is >> just- >> smart-enough. >> >> Stu > > --~--~-~--~~~---~--~~ You 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 -~--~~~~--~~--~--~---
Got a Clojure user group?
Got a Clojure user group, meetup etc? Reply to this message and let me know, I'll add them to the Clojure site. Please supply a primary URL for getting info for your group. Thanks! Rich --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
"Transparent" delays
I recently came across a situation where I very much wanted to delay
the calculation of some values, but where I also wanted those delays
to use their calculated values for equality determinations. This is
particularly important when comparing vectors or maps that contain
delayed values, where doing something like (= (force some-delay) some-
value) isn't possible.
So, I whipped up a tdelay (transparent delay) macro, an almost
complete ripoff of clojure.core/delay, except that it creates
instances of a subclass of clojure.lang.Delay that defers equality and
hashcode calculations to the delay's value. The results:
user=> (= {:a 5 :b (delay 12)} {:a 5 :b 12})
false
user=> (= {:a 5 :b (tdelay 12)} {:a 5 :b 12})
true
I get nervous when I screw around with equality in relatively sneaky
ways like this, so I thought I'd toss this out on the list and see if
anyone has any comments one way or the other.
- Chas
--
(import '(clojure.lang Delay Util))
(defn make-tdelay
[fn]
(proxy [Delay] [fn]
(equals [other]
(Util/equals (.deref this) (Delay/force other)))
(hashCode []
(Util/hash (.deref this)
(defmacro tdelay
[& body]
(list 'make-tdelay (list* `#^{:once true} fn* [] body)))
--~--~-~--~~~---~--~~
You 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: Programming Clojure Beta 9 Is Out
Hi Stuart, Thanks very much for writing this book. Do you think the release of the completed book is pretty close? I'm very excited about it. -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 To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
OK, cobertura runs, but...
I have Cobertura running and producing reports against contrib, sort-of. Problems: (1) AFAICT, cobertura *insists* in trying to parse the source code as Java to do cyclomatic complexity analysis. This blows up, of course. (2) The red/green coloring of the lines does not match what I know is happening in the test run. This may be caused by #1 but I doubt it. I have attached a modified contrib build.xml if anyone wants to play with this. Note that you will need to drop cobertura and its various jars into a cobertura directory. --~--~-~--~~~---~--~~ You 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 -~--~~~~--~~--~--~--- Pack all clojure-contrib sources into a JAR. Compile those that can be compiled standalone if the clojure.jar property points us to clojure.jar. WARNING: You have not defined a path to clojure.jar so I can't compile files. This will cause some parts of clojure.contrib not to work (e.g., pretty print). To enable compiling, run "ant -Dclojure.jar=<...path to clojure.jar..>"
Re: clojure dependency management and build
On Thu, Apr 9, 2009 at 11:34 AM, Stuart Sierra wrote: > > I keep a "Clojure stuff" dir with the latest revisions of all the > projects I track -- Clojure, contrib, swank, slime, etc. -- and update > them all with a shell script that runs the various "svn update" and > "git pull" commands. So I always have access to the latest version of > everything. But I don't automatically use the latest releases in my > projects! > > Each project that I work on has a "lib" dir for JARs, including > Clojure. I manage the JARs manually, but they're part of my source > control repository. I update the the JARs only when some new > functionality or bug fix that I depend on comes out. That way I know > that a project won't suddenly break just because I've updated to the > latest Clojure SVN. > > I use Ant for build management, with separate build dirs for compiled > Java code and AOT-compiled Clojure code. Here's my build.xml: > http://tinyurl.com/c5vkfm Cool, thanks, I will look over this stuff today. Sounds like more or less what I have been doing. What are you doing about building up the classpath for your projects in slime/swan? Where does the rake come into play? > > > Multi-version dependency tracking is HARD. I've never seen a system > that does it perfectly -- Rubygems, CPAN, Maven, you name it. Yea, I don't imagine will solve things beautifully at first, but we should be able to at least streamline things a bit. > > > -Stuart S > > > On Apr 8, 3:31 pm, Bradford Cross wrote: > > When you are building something real with Clojure and Emacs/Slime/Swank > - > > things can get a bit hairy with dependency management. > > > > I have scoured the inter-tubes in the past couple days to see what I > could > > find. > > > > I found Lancet, for builds: > http://github.com/stuarthalloway/lancet/tree/master > > > > I haven't tried it yet. > > > > I found some people doing things with Maven: > > > > Creating a clojurue app with maven: > http://pupeno.com/blog/how-to-create-a-clojure-application?set_langua...http://pupeno.com/blog/iterative-coding-with-a-clojure-application > > > > clojure-pom:http://github.com/dysinger/clojure-pom/tree/master > > > > I heard some chatter yesterday on #clojure about using Ivy with Clojure. > > > > So there is a flurry of activity. Please let me know if there are other > > things that I am missing. > > > > What I am doing now from my emacs / slime-repl is hacking things in > manually > > to my swank-clojure-extra-classpaths. This doesn't scale for working > with > > multiple clojure projects in emacs. > > > > I will probably create a script to make things a bit nicer. But I'd like > > something fundamentally better. > > > > Here are the issues: > > > > -I download lots of little projects things from github and i want to > munge > > them all together for my app. This means I need to build jars (some with > > ant, otehrs with maven, etc.) and in other cases I want to depend > directly > > on the .clj files using clojures namespace-to-dir-structure conventions. > So > > there are a couple different ways to build of the classpath - one for > .clj > > and one for .jar. > > -Many projects also have their own lib foler - with both jars and cljs, > so I > > need to pick those deps up transatively. > > -The work in the Clojure community is proceeding very fast, so I'd like > > updating all the projects from git to be automated as well. > > > > So what is a good solution to these problems? Perhaps it would be cool > to > > build some git/maven/lancet aware infrastructure to do this refreshing of > > deps, building the deps, and building up the classpath. It may also be > good > > to configure .emacs to be able to load projects and rebuild the classpath > > dynamically based on lancet build files - much in the way that intelliJ > or > > eclipse load projects from ant .builds or maven poms. > > > > Is all this too much, am I missing something that already exists? > > > > --~--~-~--~~~---~--~~ You 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 dependency management and build
I keep a "Clojure stuff" dir with the latest revisions of all the projects I track -- Clojure, contrib, swank, slime, etc. -- and update them all with a shell script that runs the various "svn update" and "git pull" commands. So I always have access to the latest version of everything. But I don't automatically use the latest releases in my projects! Each project that I work on has a "lib" dir for JARs, including Clojure. I manage the JARs manually, but they're part of my source control repository. I update the the JARs only when some new functionality or bug fix that I depend on comes out. That way I know that a project won't suddenly break just because I've updated to the latest Clojure SVN. I use Ant for build management, with separate build dirs for compiled Java code and AOT-compiled Clojure code. Here's my build.xml: http://tinyurl.com/c5vkfm Multi-version dependency tracking is HARD. I've never seen a system that does it perfectly -- Rubygems, CPAN, Maven, you name it. -Stuart S On Apr 8, 3:31 pm, Bradford Cross wrote: > When you are building something real with Clojure and Emacs/Slime/Swank - > things can get a bit hairy with dependency management. > > I have scoured the inter-tubes in the past couple days to see what I could > find. > > I found Lancet, for builds:http://github.com/stuarthalloway/lancet/tree/master > > I haven't tried it yet. > > I found some people doing things with Maven: > > Creating a clojurue app with > maven:http://pupeno.com/blog/how-to-create-a-clojure-application?set_langua...http://pupeno.com/blog/iterative-coding-with-a-clojure-application > > clojure-pom:http://github.com/dysinger/clojure-pom/tree/master > > I heard some chatter yesterday on #clojure about using Ivy with Clojure. > > So there is a flurry of activity. Please let me know if there are other > things that I am missing. > > What I am doing now from my emacs / slime-repl is hacking things in manually > to my swank-clojure-extra-classpaths. This doesn't scale for working with > multiple clojure projects in emacs. > > I will probably create a script to make things a bit nicer. But I'd like > something fundamentally better. > > Here are the issues: > > -I download lots of little projects things from github and i want to munge > them all together for my app. This means I need to build jars (some with > ant, otehrs with maven, etc.) and in other cases I want to depend directly > on the .clj files using clojures namespace-to-dir-structure conventions. So > there are a couple different ways to build of the classpath - one for .clj > and one for .jar. > -Many projects also have their own lib foler - with both jars and cljs, so I > need to pick those deps up transatively. > -The work in the Clojure community is proceeding very fast, so I'd like > updating all the projects from git to be automated as well. > > So what is a good solution to these problems? Perhaps it would be cool to > build some git/maven/lancet aware infrastructure to do this refreshing of > deps, building the deps, and building up the classpath. It may also be good > to configure .emacs to be able to load projects and rebuild the classpath > dynamically based on lancet build files - much in the way that intelliJ or > eclipse load projects from ant .builds or maven poms. > > Is all this too much, am I missing something that already exists? --~--~-~--~~~---~--~~ You 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?
By the way, recent versions of duck-streams assume UTF-8 unless you rebind *default-encoding*. -Stuart S. On Apr 8, 6:15 pm, Perry Trolard wrote: > Hi Stuart, > > Not sure if you saw my post athttp://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: DISCUSS: tests that read and write files
My recommendation would be to use a temporary file that is created and deleted in a macro or fixture. (defmacro with-tmp-properties-file [& body] `(binding [*tmp-properties-file* (File/createTempFile "temp" ".properties")] (spit *tmp-properties-file* "contents of the test file") ~...@body (.delete *tmp-properties-file*))) -Stuart Sierra On Apr 9, 1:54 pm, Stuart Halloway wrote: > In r659 I added a unit test to clojure-contrib that needed to read and > write from the filesystem. I picked a dumb and simple convention, and > welcome review from other committers to move to something that is just- > smart-enough. > > Stu --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: getting code coverage into clojure-contrib builds?
OK, I'll try Cobertura next. There is a reason my Java knowledge sounds about 5 years old ... :-) Stu > > Stuart Halloway wrote: >> I will go and bug the emma folks, but first wanted to ask here if >> there is any specific reason that Clojure-generated bytecode might >> surprise emma? > > I might be totally wrong, but from what I've heard, Emma's development > has stopped a few years ago and it doesn't support some Java 5 > features, including annotations. A quick search seems to confirm the > "development has stopped" scenario, at the very least. That said, I > know cobertura is used successfully nowadays in java projects; it also > works at the bytecode level. > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: getting code coverage into clojure-contrib builds?
Stuart Halloway wrote: > I will go and bug the emma folks, but first wanted to ask here if > there is any specific reason that Clojure-generated bytecode might > surprise emma? I might be totally wrong, but from what I've heard, Emma's development has stopped a few years ago and it doesn't support some Java 5 features, including annotations. A quick search seems to confirm the "development has stopped" scenario, at the very least. That said, I know cobertura is used successfully nowadays in java projects; it also works at the bytecode level. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
DISCUSS: tests that read and write files
In r659 I added a unit test to clojure-contrib that needed to read and write from the filesystem. I picked a dumb and simple convention, and welcome review from other committers to move to something that is just- smart-enough. Stu --~--~-~--~~~---~--~~ You 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?
Too late :-). I have already committed (r659) -- take a look and see if you are happy with the changes I made. Stu > 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?
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: New release of the enclojure plugin is up.
Enclojure is shaping up to be a really nice development environment for Clojure. Great work Eric. --~--~-~--~~~---~--~~ You 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 -~--~~~~--~~--~--~---
new contrib: singleton
- clojure.contrib.singleton/singleton ([f]) Returns a memoized version of a function with no arguments. The memoized version caches the function's return value. This is useful for lazily creating global objects that are expensive to initialize. Warning: Make sure you really want a single global instance, and not one instance per thread. --~--~-~--~~~---~--~~ You 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 -~--~~~~--~~--~--~---
getting code coverage into clojure-contrib builds?
I spent a few minutes this morning trying to get an emma coverage report over contrib. Short answer is that it doesn't work -- emma throws an exception while instrumenting the code (see attached console.txt). I will go and bug the emma folks, but first wanted to ask here if there is any specific reason that Clojure-generated bytecode might surprise emma? I have attached a modified build.xml if anybody wants to try this out. Stu --~--~-~--~~~---~--~~ You 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 -~--~~~~--~~--~--~--- Pack all clojure-contrib sources into a JAR. Compile those that can be compiled standalone if the clojure.jar property points us to clojure.jar. WARNING: You have not defined a path to clojure.jar so I can't compile files. This will cause some parts of clojure.contrib not to work (e.g., pretty print). To enable compiling, run "ant -Dclojure.jar=<...path to clojure.jar..>" : ant -Dclojure.jar=../clojure/clojure.jar test_contrib Buildfile: build.xml test_contrib: [emmajava] EMMA: package [clojure/contrib] contains classes [test_is__init] without full debug info [emmajava] java.lang.ExceptionInInitializerError (test_contrib.clj:0) [emmajava] at clojure.lang.Compiler.eval(Compiler.java:4533) [emmajava] at clojure.lang.Compiler.load(Compiler.java:4846) [emmajava] at clojure.lang.RT.loadResourceScript(RT.java:325) [emmajava] at clojure.lang.RT.loadResourceScript(RT.java:316) [emmajava] at clojure.lang.RT.load(RT.java:394) [emmajava] at clojure.lang.RT.load(RT.java:366) [emmajava] at clojure.core$load__5042$fn__5045.invoke(core.clj:3746) [emmajava] at clojure.core$load__5042.doInvoke(core.clj:3745) [emmajava] at clojure.lang.RestFn.invoke(RestFn.java:413) [emmajava] at clojure.core$load_one__4994.invoke(core.clj:3590) [emmajava] at clojure.core$load_lib__5015.doInvoke(core.clj:3627) [emmajava] at clojure.lang.RestFn.applyTo(RestFn.java:147) [emmajava] at clojure.core$apply__3231.doInvoke(core.clj:408) [emmajava] at clojure.lang.RestFn.invoke(RestFn.java:443) [emmajava] at clojure.core$load_libs__5027.doInvoke(core.clj:3657) [emmajava] at clojure.lang.RestFn.applyTo(RestFn.java:142) [emmajava] at clojure.core$apply__3231.doInvoke(core.clj:408) [emmajava] at clojure.lang.RestFn.invoke(RestFn.java:443) [emmajava] at clojure.core$require__5033.doInvoke(core.clj:3713) [emmajava] at clojure.lang.RestFn.invoke(RestFn.java:413) [emmajava] at user$eval__1.invoke(Unknown Source) [emmajava] at clojure.lang.Compiler.eval(Compiler.java:4522) [emmajava] at clojure.core$eval__3975.invoke(core.clj:1743) [emmajava] at clojure.main$eval_opt__5805.invoke(main.clj:220) [emmajava] at clojure.main$initialize__5812.invoke(main.clj:239) [emmajava] at clojure.main$null_opt__5834.invoke(main.clj:264) [emmajava] at clojure.main$main__5854$fn__5856.invoke(main.clj:333) [emmajava] at clojure.main$main__5854.doInvoke(main.clj:328) [emmajava] at clojure.lang.RestFn.invoke(RestFn.java:426) [emmajava] at clojure.lang.Var.invoke(Var.java:350) [emmajava] at clojure.lang.AFn.applyToHelper(AFn.java:175) [emmajava] at clojure.lang.Var.applyTo(Var.java:463) [emmajava] at clojure.main.main(main.java:39) [emmajava] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [emmajava] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [emmajava] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.ja
Re: DISCUSS: clojure.contrib.java-utils/as-str
Hi, Am 09.04.2009 um 15:49 schrieb Stephen C. Gilardi: I like it for its simplicity. It can actually be a little simpler yet as the general case gives the same result when passed no arguments as the special case does: (defn as-str [& args] (apply str (map #(if (instance? clojure.lang.Named %) (name %) %) args))) Please note that all implementation proposed so far ignore the namespace of a Named. (as-str :foo/bar) (as-str :frob/bar) will give the same string. This might be intended, but it also might be the source of subtle bugs. Sincerely Meikel smime.p7s Description: S/MIME cryptographic signature
Is there a simple Clojure data schema/validation library?
I've been whipping up a simple schema library for validating Clojure
data based on their tags, but I'm worried that what I'm doing might be
redundant with an already existing library. Is there something, such
as in clojure-contrib, that can do things similar to the code below
(note the make-schemata and validate functions)?
(derive ::employee ::person)
(derive ::special-employee ::employee)
(def schemata-plans
{::person {:required {:name string?}
:optional {:id (partial < 0)}}
::employee {:required {:dept keyword?}}
::special-employee {:required {:name integer?}}})
(defn with-tag
"Changes its argument's tag to the given tag."
[tag x]
(with-meta x (merge ^x {:tag x})))
(defstruct person-s :name :id)
(def valid-employee
(with-tag ::employee (struct-map person-s :name "Bill", :id 10
:dept :management)))
(def invalid-employee
(with-tag ::employee (struct-map person-s :name "Bob", :id -11
:dept :management)))
(binding [*schemata* (make-schemata schemata-plans)]
(println (validate valid-employee)) ; nil
(println (validate invalid-employee)) ; A map of validation problems
--~--~-~--~~~---~--~~
You 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: Java 6 dependency in clojure-contrib ok?
Yes to 5! I'm on a Mac and don't feel like dealing w/ upgrading to 6. On Thu, Apr 9, 2009 at 9:03 AM, Francesco Bellomi < francesco.bell...@gmail.com> wrote: > > Looks like an interesting idea for me; it would also allow for > automated dependency analysis for a given target jvm. > > btw, I'd also prefer to have 1.5 compatibility > > Francesco > > On Apr 9, 2:24 am, Howard Lewis Ship wrote: > > Looks like we need a macro: > > > > (for-jvm 1.5 () > > 1.6 ()) > > > > > > --~--~-~--~~~---~--~~ You 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: clj-android
On Thu, Apr 9, 2009 at 3:17 PM, Rich Hickey wrote: > On Apr 9, 8:03 am, "Remco van 't Veer" wrote: >> On Thu, Apr 9, 2009 at 1:23 PM, Onorio Catenacci wrote: >> > [..] >> >> > I know you were mentioning some real performance issues when starting >> > a Clojure app from Android (I see them too). I wonder if using >> > TraceView to profile the Dalvik code generated by the conversion from >> > the Clojure bytecode might point us to something to fix the startup >> > time? I'll try this myself--I just thought I might ask you if you'd >> > already done this and if it were a waste of time or not. :-) >> >> I've used the mentioned profiler and I did some performance tweaks >> already, thus the clojure fork on github. > > Is that still needed after: > > http://code.google.com/p/clojure/issues/detail?id=78 Yes, the fork has two extra tweaks in place and a workaround for dalvik. A blocker for dalvik is issue 77; http://github.com/remvee/clojure/commit/7c110dc00895dea8e583e122acc6423b7e812b12 Reflection is very slow on dalvik. To speedup type-hint-less code I've build some caching around Reflection.getMethods: http://groups.google.com/group/clojure/browse_thread/thread/d3802c761ffbef69/9d06c1e420969b2d And a later commit to use ConcurrentHashMap: http://github.com/remvee/clojure/commit/07459a61bbc35c093ee5d1b6e643b84e79feab5c Another tweak I did is not loading set, zip and xml implicitly: http://github.com/remvee/clojure/commit/431fb254327ed72a2db17999f6fc9c11eef40d88 That saves of another couple of seconds. If you'd want to use it you need to require/load it first. Remco --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Macros, let and variable capture
2009/4/9 Christophe Grand :
> The problem is with the last two lines of your macro (the let expansion
> is fine):
>
> (.add l)
> (.add b
> Do you really want to hardcode l and b here or emit as many .add as
> required?
No - this is where the macro is incomplete - these lines are just
temporary. But I was sure the problem was in the let form.
I have commented these lines out and everything works fine now!!
Thanks for putting me straight - I'm struggling a bit with macros and
so I was convinced the problem was more serious. Good to know it's
just a silly mistake on my part.
Paul.
--
Iode Software Ltd, registered in England No. 6299803.
Registered Office Address: 12 Sancroft Drive, Houghton-le-Spring, Tyne
& Wear, DH5 8NE.
This message is intended only for the use of the person(s) ("the
intended recipient(s)") to whom it is addressed. It may contain
information which is privileged and confidential within the meaning of
applicable law. If you are not the intended recipient, please contact
the sender as soon as possible. The views expressed in this
communication may not necessarily be the views held by The Company.
--~--~-~--~~~---~--~~
You 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.main always exits with code 0
I have experienced this as well. My problem is that I would like my test suite to exit the proper way so that CI knows that the build actually failed. Currently test-is seems to just report to stdout, but not set anything that would cause the suite to fail with the proper exit code. Any ideas? Aaron On Apr 8, 2009, at 2:28 PM, Tom Faulhaber wrote: I'd like to second this request. It's pretty necessary to have an exit code for any type of scripting. Of course, you can always use (System/exit result-code), but a return value is "prettier" to me. - This message was sent using Endymion MailMan. http://www.endymion.com/products/mailman/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Macros, let and variable capture
Hi Paul Paul Drummond a écrit : > (defmacro defwidget [& body] > `(let [panel# (javax.swing.JPanel.) >~@(flat1 (map (fn [[type inst]] [inst (list type)]) (rest (first > body] > ~(second body) > (doto panel# > (.setLayout (javax.swing.BoxLayout. panel# > javax.swing.BoxLayout/Y_AXIS)) > (.add l) > (.add b > > The problem is with the last two lines of your macro (the let expansion is fine): (.add l) (.add b Do you really want to hardcode l and b here or emit as many .add as required? (defmacro defwidget [& body] `(let [panel# (javax.swing.JPanel.) ~@(flat1 (map (fn [[type inst]] [inst (list type)]) (rest (first body] ~(second body) (doto panel# (.setLayout (javax.swing.BoxLayout. panel# javax.swing.BoxLayout/Y_AXIS)) ~@(for [[_ inst] (reverse (rest (first body)))] `(.add ~inst) Christophe -- Professional: http://cgrand.net/ (fr) On Clojure: http://clj-me.blogspot.com/ (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 To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: DISCUSS: clojure.contrib.java-utils/as-str
On Apr 9, 2009, at 2:57 AM, Eric Tschetter wrote: Might I suggest (defn as-str ([] "") ([& args] (apply str (map #(if (instance? clojure.lang.Named %) (name %) %) args))) I like it for its simplicity. It can actually be a little simpler yet as the general case gives the same result when passed no arguments as the special case does: (defn as-str [& args] (apply str (map #(if (instance? clojure.lang.Named %) (name %) %) args))) This code works well, but performs much less well than the code I posted. Just by code inspection, we can see that it's doing a lot more work, invoking a lot more machinery, especially in the one-argument case. We can run some micro-benchmarks to get some idea how that affects its performance: For a one argument case: ; as-str using apply user=> (time (dotimes [i 100] (as-str :a))) "Elapsed time: 496.361 msecs" ; as-str not using apply user=> (time (dotimes [i 100] (as-str :a))) "Elapsed time: 22.178 msecs" The non-apply version is 22 times as fast. For a two argument case: ; as-str using apply user=> (time (dotimes [i 100] (as-str :a 1))) "Elapsed time: 1057.922 msecs" ; as-str not using apply user=> (time (dotimes [i 100] (as-str :a 1))) "Elapsed time: 317.483 msecs" The non-apply version is 3.3 times as fast. From looking at this difference, my conclusion is that the version I posted is "simple enough" to be preferred over the apply version given that its performance, especially in the one argument case, is so much better. Criticisms of that conclusion: - These are micro-benchmarks, they tell us little about how either version will really perform when the processor is doing more than just repeating the same operation over and over. - This is premature optimization, there's no evidence that this difference will matter in practice. - The apply version is simple, functional, and pretty. In the long run that matters more than performance. Thoughts on the criticisms: micro-benchmark: that's right, although, combined with thinking about how the code works, it does give some indication of the performance difference which is not 10%, or 60%, but 2100%. This is library code that should run well in a large variety of circumstances. A factor of 22 in performance is hard to ignore in that scenario. premature: that's right. It's only the "this is a low-level operation that may be used heavily in circumstances we don't yet imagine" argument that pushes me to consider this optimization in the absence of a real performance test that shows it matters. simple: The apply version is certainly pretty. The version I posted, though, is also written in a straightforward way that I think is quite readable and understandable. It trades that last measure of simplicity for a healthy measure of improved performance. Since arguing with myself is only so productive, I'd appreciate hearing other thoughts about these ideas. --Steve smime.p7s Description: S/MIME cryptographic signature
Macros, let and variable capture
Hi, I am trying to define a macro something like this:
(defwidget
(vlayout
(create-button b)
(create-label l))
(on-event b "pressed" (fn [] (.setText l "Hello World"
After a lot of messing around (I am learning all the time here!) I
have a version of defwidget that generates the code I want but I get
"Can't let qualified name" errors.
This is where my understanding of macros is giving me problems. I
want the forms inside "vlayout" to expand to local vars in a let
form. The above example would expand to:
(let [b (create-button)
l (create-label)]
(on-event b "pressed" (fn [] (.setText l "Hello World"))
where on-event is just a function. So I want to build the let form
then have the body use the local vars defined by the let form. So if
I understand correctly I explicity want to allow variable capture,
don't I? I am not sure how to achieve what I need. Clojure
automatically qualifies the vars and I just want to just turn off that
behaviour I think...
For completeness, here's the source for my macro but beware - it's
incomplete, very messy and probably unreadable!
(defmacro defwidget [& body]
`(let [panel# (javax.swing.JPanel.)
~@(flat1 (map (fn [[type inst]] [inst (list type)]) (rest (first
body]
~(second body)
(doto panel#
(.setLayout (javax.swing.BoxLayout. panel# javax.swing.BoxLayout/Y_AXIS))
(.add l)
(.add b
(defn flat1 [coll]
(mapcat #(if (coll? %) % [%]) coll))
The code that generates the let form is on line 3. I need some way of
getting "inst" to expand to its value without Clojure qualifying it.
I think that's what I need anyway - this is all very confusing to me
still!!
I'm sure there are lots of ways to clean this macro up - comments welcome.
Cheers,
Paul.
--
Iode Software Ltd, registered in England No. 6299803.
Registered Office Address: 12 Sancroft Drive, Houghton-le-Spring, Tyne
& Wear, DH5 8NE.
This message is intended only for the use of the person(s) ("the
intended recipient(s)") to whom it is addressed. It may contain
information which is privileged and confidential within the meaning of
applicable law. If you are not the intended recipient, please contact
the sender as soon as possible. The views expressed in this
communication may not necessarily be the views held by The Company.
--~--~-~--~~~---~--~~
You 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: clj-android
On Apr 9, 8:03 am, "Remco van 't Veer" wrote: > On Thu, Apr 9, 2009 at 1:23 PM, Onorio Catenacci wrote: > > [..] > > > I know you were mentioning some real performance issues when starting > > a Clojure app from Android (I see them too). I wonder if using > > TraceView to profile the Dalvik code generated by the conversion from > > the Clojure bytecode might point us to something to fix the startup > > time? I'll try this myself--I just thought I might ask you if you'd > > already done this and if it were a waste of time or not. :-) > > I've used the mentioned profiler and I did some performance tweaks > already, thus the clojure fork on github. Is that still needed after: http://code.google.com/p/clojure/issues/detail?id=78 ? Rich --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from 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: Java 6 dependency in clojure-contrib ok?
Looks like an interesting idea for me; it would also allow for automated dependency analysis for a given target jvm. btw, I'd also prefer to have 1.5 compatibility Francesco On Apr 9, 2:24 am, Howard Lewis Ship wrote: > Looks like we need a macro: > > (for-jvm 1.5 () > 1.6 ()) > --~--~-~--~~~---~--~~ You 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: clj-android
On Thu, Apr 9, 2009 at 1:23 PM, Onorio Catenacci wrote: > [..] > > I know you were mentioning some real performance issues when starting > a Clojure app from Android (I see them too). I wonder if using > TraceView to profile the Dalvik code generated by the conversion from > the Clojure bytecode might point us to something to fix the startup > time? I'll try this myself--I just thought I might ask you if you'd > already done this and if it were a waste of time or not. :-) I've used the mentioned profiler and I did some performance tweaks already, thus the clojure fork on github. The "original" startup time of an application was around 15 seconds and using the current fork it's about 5 seconds. Still too much IMO. Most of the startup time is spend bootstrapping the clojure core. Unfortunately the profiler doesn't give any clear suspects any more, so I need to figure out another way to speed this up. Maybe doing something like a core dump after bootstrap and making that executable in some way is a solution but that goes beyond my knowledge of the internals of clojure and java byte code generations at this moment. Can anybody give me pointers? Remco --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: New release of the enclojure plugin is up.
Hi, FYI, it seems that the old web site of enclojure is still up and running, and not referencing the new wikispaces web site. HTH, -- Laurent 2009/4/7 Eric Thorsen > > There is a new release of the Enclojure plugin that addresses many of > the items I have seen discuss here recently with regards to managing > classpaths in REPLs as well as many other Clojure development > scenarios. The plugin supports several use cases for the clojure.main > REPL use: > a. Project based REPLs where the REPL is started using the > dependancies on the project in the IDE. > b. Remote REPLs where some shim code can be included in your > application(s) and you can attach a REPL (or REPLs) to running VMs. > c. Ad-hoc REPLs - manually set your classpaths and start a REPL up. > All of these scenarios have strong integration with the editor > supporting integrated Clojure/Java completion, debugging with viewable > clojure data, syntax highlighting, code loading, expression > evaluation, s-expression nav and many more features. There have been > well over 100 patches since the last release in February. > For more information, please see: > http://enclojure.wikispaces.com > Plugin can be downloaded at: > http://code.google.com/p/enclojure-nb-clojure-plugin/downloads/list > > Feedback welcome! > Eric > > > Eric Thorsen > ThorTech Solutions > www.thortech-solutions.com > (914) 302-7638 [work] > (914) 302-7641 [fax] > (914) 804-4954 [cell] > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: How to flatten a coll only 1 level deep?
2009/4/9 Chouser :
> (defn flat1 [coll]
> (mapcat #(if (coll? %) % [%]) coll))
Ah, I see. So for each item, if its already a collection we leave it
alone and if not we make a vector of one item, then at the end we use
mapcat to concatinate all the top-level items into one list.
Excellent - thank you!
Paul.
--
Iode Software Ltd, registered in England No. 6299803.
Registered Office Address: 12 Sancroft Drive, Houghton-le-Spring, Tyne
& Wear, DH5 8NE.
This message is intended only for the use of the person(s) ("the
intended recipient(s)") to whom it is addressed. It may contain
information which is privileged and confidential within the meaning of
applicable law. If you are not the intended recipient, please contact
the sender as soon as possible. The views expressed in this
communication may not necessarily be the views held by The Company.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---
Re: DISCUSS: clojure.contrib.java-utils/as-str
I think it makes sense for (str) to return "", but I'm not sure about
(as-str) being "". It doesn't seem as obvious and expected to me.
Paul
On Thu, Apr 9, 2009 at 2:57 AM, Eric Tschetter wrote:
>
> Might I suggest
>
> (defn as-str
> ([] "")
> ([& args]
>(apply str (map #(if (instance? clojure.lang.Named %) (name %) %)
> args)))
>
> --Eric Tschetter
>
> On Wed, Apr 8, 2009 at 8:19 PM, Stephen C. Gilardi
> wrote:
> >
> > On Apr 8, 2009, at 8:13 PM, Stuart Halloway wrote:
> >
> >> Changed to as-str (r654).
> >
> > Very nice!
> >
> > Should we extend as-str to any number of arguments like its close cousin
> > str?
> >
> > Here's a proposed implementation:
> >
> > (defn as-str
> > "With no args, returns the empty string. With one arg, returns its name
> > or string representation. (as-str nil) returns the empty string. With
> > more than one arg, returns the concatenation of the as-str values of the
> > args."
> > {:tag String}
> > ([] "")
> > ([x]
> > (if (instance? clojure.lang.Named x)
> > (name x)
> > (str x)))
> > ([x & ys]
> > (let [sb (StringBuilder. #^String (as-str x))]
> > (doseq [y ys]
> > (.append sb (as-str y)))
> > (.toString sb
> >
> > Comments welcome.
> >
> > --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
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---
