Re: where is contrib?
On 21.02.2009, at 18:25, Frantisek Sodomka wrote: For example, lazy-cons is still present in: combinatorics.clj lazy_xml/with_pull.clj monads/examples.clj In monads/examples, it is used inside a macro that chooses lazy-seq or lazy-cons according to which version of Clojure is running, so it doesn't do any harm. In the other two files, it seems that porting still needs to be done, but it looks straightforward to do. Konrad. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com 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 Questions
On 21.02.2009, at 19:57, Christian Vest Hansen wrote: I *think* that Clojure does not require anything from Java 6, and thus can work on any compliant Java 5 or greater. I run it with Java 5, which is the latest Java available for MacOSX 10.4 on a PowerPC. It works fine. Konrad. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com 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: Directed Graphs for Contrib
On 22.02.2009, at 02:59, Jeffrey Straszheim wrote: As part of my Datalog work I'm putting together some directed graph algorithms, mostly things like finding strongly connected components, and building dependency stratifications (think topological sort but with the results groups in tiers of non- interdependent nodes). Anyhow, I'm thinking this stuff will be usefull outside of Datalog, and am wondering if I should just add it to contrib as a stand-alone library? Yes, that looks quite useful! Konrad. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com 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: Changed clojure.contrib.test-clojure to load without running, add run method
I wonder about testing clojure.contrib in general. Some libraries like math, miglayout, monads, sql and test-is define their own tests tests.clj in their subdirectory. Others - shell_out and str_utils - have their tests in test_contrib. Should we merge these two approaches into one? Frantisek On Feb 23, 12:12 am, Stephen C. Gilardi squee...@mac.com wrote: On Feb 22, 2009, at 5:41 PM, Frantisek Sodomka wrote: There was a functionality in build.xml to run tests from the command line. When you correctly set clojure.jar path, you could just do: ant test_clojure Fixed. Thanks for the report. Regarding test_contrib, I would like to update it along the lines of the recent changes to test_clojure because I think they make things cleaner, more composable, and more modular. Discussion welcome. Thanks, --Steve smime.p7s 3KViewDownload --~--~-~--~~~---~--~~ 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: Directed Graphs for Contrib
I agree -- an important goal is to define a suitable common way to represent graphs in terms of idiomatic Clojure data structures. Francesco On Feb 22, 4:11 pm, Jeffrey Straszheim straszheimjeff...@gmail.com wrote: Just as a point of fact, I don't plan to make a complete *every algorithm you can think of* package, just the ones I need. However, it would be easy to add others submitted by the community. I could be a gathering place of graph algorithms. --~--~-~--~~~---~--~~ 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: with-meta and concat
Chouser a écrit :
On Sun, Feb 22, 2009 at 4:07 PM, jim jim.d...@gmail.com wrote:
In some old code, I did something like:
(with-meta (concat [1 3] [8 4])
{:tail true}))
which now fails. I believe it's because the result of concat is now
some kind of reference.
Does anyone have any advice on a workaround?
LazySeq extends AFn, so you can't change the metadata once the object
exists. However, Seq's still accept meta-data, so:
(with-meta (seq (concat [1 3] [8 4]))
{:tail true})
I'm not sure it's desirable to have metadata on seqs (it bit me while
transitionning to lazy) but I have thought of two ways to add withMeta
to a LazySeq:
* to have meta()/withMeta() to force evaluation of the inner seq (and it
begs the question to know whether (= (meta a) (meta (lazy-seq a)))
should be true),
* to have withMeta() to return some kind proxy on the LazySeq object
(cannot this approach also works for regular closures?).
BTW, speaking of regular closures, would it be possible to be able to
set static metadata?
eg:
(#^{:meta {:actual :metadata}} fn* [args] body)
(The fn macro could make this prettier.)
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: Clojure running atop Java ME (Micro Edition) for mobile phones
+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: with-meta and concat
On Feb 23, 4:21 am, Christophe Grand christo...@cgrand.net wrote:
Chouser a écrit :
On Sun, Feb 22, 2009 at 4:07 PM, jim jim.d...@gmail.com wrote:
In some old code, I did something like:
(with-meta (concat [1 3] [8 4])
{:tail true}))
which now fails. I believe it's because the result of concat is now
some kind of reference.
Does anyone have any advice on a workaround?
LazySeq extends AFn, so you can't change the metadata once the object
exists. However, Seq's still accept meta-data, so:
(with-meta (seq (concat [1 3] [8 4]))
{:tail true})
I'm not sure it's desirable to have metadata on seqs (it bit me while
transitionning to lazy) but I have thought of two ways to add withMeta
to a LazySeq:
* to have meta()/withMeta() to force evaluation of the inner seq (and it
begs the question to know whether (= (meta a) (meta (lazy-seq a)))
should be true),
* to have withMeta() to return some kind proxy on the LazySeq object
(cannot this approach also works for regular closures?).
BTW, speaking of regular closures, would it be possible to be able to
set static metadata?
eg:
(#^{:meta {:actual :metadata}} fn* [args] body)
(The fn macro could make this prettier.)
The fact that LazySeqs are AFns is an implementation detail that might
change. I still have some perf tweaking to do. After that, we can look
at how best to support metadata.
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: suggestion for resultset-seq and duplicate column names
On Feb 22, 7:59 pm, Rob rob.nikan...@gmail.com wrote: Hi, How about having this function call .getColumnLabel instead of .getColumnName. That way, you can do a join with duplicate column names and rename them in the SQL query... select name name1, name name2, ... from ... and resultset-seq won't throw an exception. ? Sounds good to me - any drawbacks to this? Does it require that the columns be named explicitly? 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 -~--~~~~--~~--~--~---
Generating classes with annotations
Hi, Is it possible to add annotations to classes generated with clojure? There seems to be an AnnotationWriter class in the source, but I've not had any luck tracing it back to anything useable. Thanks, Rob. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
alternate syntax
I have an idea I'd like to float to see if there are reasons why it's a bad idea. What if Clojure had an alternate surface syntax that was translated into standard Clojure syntax by a kind of preprocessor? Many people that don't like Lisp dialects don't like them because of the parentheses. I'm trying to address that. Here's a simple example of valid Clojure code. (defn pig-latin [word] (let [first-letter (first word)] (if (.contains aeiou (str first-letter)) (str word ay) (str (subs word 1) first-letter ay (println (pig-latin red)) (println (pig-latin orange)) Here's what that same code would look like in my alternate syntax. defn pig-latin [word] let [first-letter (first word)] if .contains aeiou (str first-letter) str word ay str (subs word 1) first-letter ay println (pig-latin red) println (pig-latin orange) The rules for turning this into standard Clojure syntax are pretty simple. 1) If a line is indented farther than the previous one, it is part of the previous line. 2) If a line doesn't start with a (, then add one. 3) If the next line is indented less than this one, add the appropriate number of )'s at the end. 4) If the first token on a line is if and the first non-whitespace character after it is not ( then assume the rest of the line is the condition and wrap it in ( ). A translation from standard Clojure syntax to this alternate form should also be possible. Is this a bad idea? -- R. Mark Volkmann Object Computing, Inc. --~--~-~--~~~---~--~~ 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: Directed Graphs for Contrib
As a compiler writer I do a lot of graph-work, but nearly all of it has cycles. There was a thread earlier about defining cyclic graphs in Clojure. Can someone point me to it? Thanks, Cliff On Feb 22, 7:55 am, Rich Hickey richhic...@gmail.com wrote: On Feb 22, 2009, at 10:11 AM, Jeffrey Straszheim wrote: Just as a point of fact, I don't plan to make a complete *every algorithm you can think of* package, just the ones I need. However, it would be easy to add others submitted by the community. I could be a gathering place of graph algorithms. Sounds good to me - thanks! Rich On Sun, Feb 22, 2009 at 7:31 AM, Francesco Bellomi francesco.bell...@gmail.com wrote: +1 Francesco On Feb 22, 2:59 am, Jeffrey Straszheim straszheimjeff...@gmail.com wrote: As part of my Datalog work I'm putting together some directed graph algorithms, mostly things like finding strongly connected components, and building dependency stratifications (think topological sort but with the results groups in tiers of non-interdependent nodes). Anyhow, I'm thinking this stuff will be usefull outside of Datalog, and am wondering if I should just add it to contrib as a stand-alone library? --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
better syntax highlighting for Clojure
I have improved the clojure.js bits [1]. Various small changes, but the big issue was to discontinue using \b for end of word, which does not work well with names-like-this. Feedback or additional improvements welcome. Stuart [1] http://github.com/stuarthalloway/programming-clojure/blob/95d9943dfb54112912714a2d741a34749bca3be2/public/javascripts/clojure.js --~--~-~--~~~---~--~~ 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: Directed Graphs for Contrib
I don't remember that post, but my work also deals with cycles, and a strongly connected component algorithm will be one of my first submissions. On Mon, Feb 23, 2009 at 10:52 AM, cliffc cli...@acm.org wrote: As a compiler writer I do a lot of graph-work, but nearly all of it has cycles. There was a thread earlier about defining cyclic graphs in Clojure. Can someone point me to it? Thanks, Cliff On Feb 22, 7:55 am, Rich Hickey richhic...@gmail.com wrote: On Feb 22, 2009, at 10:11 AM, Jeffrey Straszheim wrote: Just as a point of fact, I don't plan to make a complete *every algorithm you can think of* package, just the ones I need. However, it would be easy to add others submitted by the community. I could be a gathering place of graph algorithms. Sounds good to me - thanks! Rich On Sun, Feb 22, 2009 at 7:31 AM, Francesco Bellomi francesco.bell...@gmail.com wrote: +1 Francesco On Feb 22, 2:59 am, Jeffrey Straszheim straszheimjeff...@gmail.com wrote: As part of my Datalog work I'm putting together some directed graph algorithms, mostly things like finding strongly connected components, and building dependency stratifications (think topological sort but with the results groups in tiers of non-interdependent nodes). Anyhow, I'm thinking this stuff will be usefull outside of Datalog, and am wondering if I should just add it to contrib as a stand-alone library? --~--~-~--~~~---~--~~ 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: alternate syntax
Interesting thread on LtU on this subject: http://lambda-the-ultimate.org/node/1646 On Mon, Feb 23, 2009 at 10:42 AM, Mark Volkmann r.mark.volkm...@gmail.comwrote: I have an idea I'd like to float to see if there are reasons why it's a bad idea. What if Clojure had an alternate surface syntax that was translated into standard Clojure syntax by a kind of preprocessor? Many people that don't like Lisp dialects don't like them because of the parentheses. I'm trying to address that. Here's a simple example of valid Clojure code. (defn pig-latin [word] (let [first-letter (first word)] (if (.contains aeiou (str first-letter)) (str word ay) (str (subs word 1) first-letter ay (println (pig-latin red)) (println (pig-latin orange)) Here's what that same code would look like in my alternate syntax. defn pig-latin [word] let [first-letter (first word)] if .contains aeiou (str first-letter) str word ay str (subs word 1) first-letter ay println (pig-latin red) println (pig-latin orange) The rules for turning this into standard Clojure syntax are pretty simple. 1) If a line is indented farther than the previous one, it is part of the previous line. 2) If a line doesn't start with a (, then add one. 3) If the next line is indented less than this one, add the appropriate number of )'s at the end. 4) If the first token on a line is if and the first non-whitespace character after it is not ( then assume the rest of the line is the condition and wrap it in ( ). A translation from standard Clojure syntax to this alternate form should also be possible. Is this a bad idea? -- R. Mark Volkmann Object Computing, Inc. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
challenge: best fibo implementation under the new laziness?
I have updated the sample source from the book (http://tinyurl.com/clojure-samples ) to the new laziness. Along the way, I replaced the lazy-cons based implementation of the fibonacci numbers with this: (defn fibo ([] (concat [0 1] (fibo 0 1))) ([a b] (let [n (+ a b)] (lazy-seq (cons n (fibo b n)) Is there a better/more idiomatic approach, without resorting to code in clojure-contrib? Test your code against the following expression to flush out stack and heap overflows. (rem (nth (fibo) 100) 1000) - 875 Also, the current 'fibs' implementation in clojure.contrib.seq fails the test above, because it holds the entire sequence as it goes. We should replace it with whatever the community comes up with on this thread. Cheers, 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: alternate syntax
On Mon, Feb 23, 2009 at 4:42 PM, Mark Volkmann r.mark.volkm...@gmail.com wrote: I have an idea I'd like to float to see if there are reasons why it's a bad idea. What if Clojure had an alternate surface syntax that was translated into standard Clojure syntax by a kind of preprocessor? Do you by any chance mean custom reader when you say preprocessor? :) Many people that don't like Lisp dialects don't like them because of the parentheses. I'm trying to address that. How many of those have spend enough time with a lisp to form a valid opinion of the syntax? There are many programming languages who's syntax looks ugly to the eye that do not understand its meaning. Here's a simple example of valid Clojure code. (defn pig-latin [word] (let [first-letter (first word)] (if (.contains aeiou (str first-letter)) (str word ay) (str (subs word 1) first-letter ay (println (pig-latin red)) (println (pig-latin orange)) Here's what that same code would look like in my alternate syntax. defn pig-latin [word] let [first-letter (first word)] if .contains aeiou (str first-letter) str word ay str (subs word 1) first-letter ay println (pig-latin red) println (pig-latin orange) The rules for turning this into standard Clojure syntax are pretty simple. 1) If a line is indented farther than the previous one, it is part of the previous line. 2) If a line doesn't start with a (, then add one. 3) If the next line is indented less than this one, add the appropriate number of )'s at the end. 4) If the first token on a line is if and the first non-whitespace character after it is not ( then assume the rest of the line is the condition and wrap it in ( ). Rule 4 is a special case that introduces inconsistency. I am against it. The syntax is basically introducing implicit parenthesis based on indentation. I have been pondering this idea as well, but decided that Clojure already goes so easy on the parenthesis, that it wasn't worth my time to persue it any further. A translation from standard Clojure syntax to this alternate form should also be possible. Is this a bad idea? It is not inherently bad, but I doubt that a lot of people would prefer it as their primary reader over the standard Clojure reader. It could, on the other hand, find a nice niche in DSLs, for programs that need some level of scriptability by people who cannot be expected to be lisp savvy. -- R. Mark Volkmann Object Computing, Inc. -- Venlig hilsen / Kind regards, Christian Vest Hansen. --~--~-~--~~~---~--~~ 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: alternate syntax
You might be interested in my pet macro: pl http://github.com/hiredman/odds-and-ends/blob/8a84e6ddbad9d71f714ba16c3e1239633228a7eb/functional.clj#L94 it does transformations on code using zippers. for example: (pl inc $ inc $ 0) expands to (inc (inc 2)) pl is just a toy but it might be worth looking at. On Mon, Feb 23, 2009 at 7:42 AM, Mark Volkmann r.mark.volkm...@gmail.com wrote: I have an idea I'd like to float to see if there are reasons why it's a bad idea. What if Clojure had an alternate surface syntax that was translated into standard Clojure syntax by a kind of preprocessor? Many people that don't like Lisp dialects don't like them because of the parentheses. I'm trying to address that. Here's a simple example of valid Clojure code. (defn pig-latin [word] (let [first-letter (first word)] (if (.contains aeiou (str first-letter)) (str word ay) (str (subs word 1) first-letter ay (println (pig-latin red)) (println (pig-latin orange)) Here's what that same code would look like in my alternate syntax. defn pig-latin [word] let [first-letter (first word)] if .contains aeiou (str first-letter) str word ay str (subs word 1) first-letter ay println (pig-latin red) println (pig-latin orange) The rules for turning this into standard Clojure syntax are pretty simple. 1) If a line is indented farther than the previous one, it is part of the previous line. 2) If a line doesn't start with a (, then add one. 3) If the next line is indented less than this one, add the appropriate number of )'s at the end. 4) If the first token on a line is if and the first non-whitespace character after it is not ( then assume the rest of the line is the condition and wrap it in ( ). A translation from standard Clojure syntax to this alternate form should also be possible. Is this a bad idea? -- R. Mark Volkmann Object Computing, Inc. -- And what is good, Phaedrus, And what is not good— Need we ask anyone to tell us these things? --~--~-~--~~~---~--~~ 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: alternate syntax
On Mon, Feb 23, 2009 at 10:55 AM, Christian Vest Hansen karmazi...@gmail.com wrote: On Mon, Feb 23, 2009 at 4:42 PM, Mark Volkmann r.mark.volkm...@gmail.com wrote: I have an idea I'd like to float to see if there are reasons why it's a bad idea. What if Clojure had an alternate surface syntax that was translated into standard Clojure syntax by a kind of preprocessor? Do you by any chance mean custom reader when you say preprocessor? :) No. This would be a translation step before the code is fed to the current Clojure reader. Many people that don't like Lisp dialects don't like them because of the parentheses. I'm trying to address that. How many of those have spend enough time with a lisp to form a valid opinion of the syntax? The parens don't bother me. My concern though is that many people won't take the time to learn Clojure primarily because of the parens. The preprocessor would appease those people and not change anything for those that like Clojure just fine as it is. Rule 4 is a special case that introduces inconsistency. I am against it. The syntax is basically introducing implicit parenthesis based on indentation. That's correct. The preprocessor would be just like Python in that regard. People that don't like Python won't like this either. -- R. Mark Volkmann Object Computing, Inc. --~--~-~--~~~---~--~~ 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: alternate syntax
My opinion is that since Lisp is the programmable programming language, people shouldn't hesitate to try to write code to modify it to their liking. I actually think parenthesis are neat and the new syntax wouldn't be an improvement (and I've been programming in Python for the last 8 years) but don't wait for approval, experiment! --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
*features*-var
Some (most, if not all) CL variants have a *features*-var available that contains information about what the implementation supports and what not. Seeing that the issue of determining the Clojure-version in use come up from time to time, maybe it would be useful to introduce something like this for Clojure. For example, identifying whether one is using the lazy (lazier) version would then be possible by checking for the presence of a flag :lazy (in this particular case, checking for the presence of lazy-seq would be enough, but other feature-sets might be harder to detect). --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
How to get rid of reflection warning from countdown latch?
Hi all, I'm getting Reflection warning, line: 150 - reference to field countDown can't be resolved. from (if cell-updated? (if (not (:updating @cell)) (.countDown latch Is there any way to get rid of it? Thanks, Anand --~--~-~--~~~---~--~~ 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: alternate syntax
On Mon, Feb 23, 2009 at 11:10 AM, Mark Volkmann r.mark.volkm...@gmail.comwrote: On Mon, Feb 23, 2009 at 10:55 AM, Christian Vest Hansen karmazi...@gmail.com wrote: On Mon, Feb 23, 2009 at 4:42 PM, Mark Volkmann r.mark.volkm...@gmail.com wrote: I have an idea I'd like to float to see if there are reasons why it's a bad idea. What if Clojure had an alternate surface syntax that was translated into standard Clojure syntax by a kind of preprocessor? Do you by any chance mean custom reader when you say preprocessor? :) No. This would be a translation step before the code is fed to the current Clojure reader. This sounds to me like a better fit for an editor plugin (that would add parentheses as you type based on indentation, and optionally hide them as well when editing the source). -- Cosmin Stejerean http://offbytwo.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: How to get rid of reflection warning from countdown latch?
This blind stab worked... is it correct? (if cell-updated? (if (not (:updating @cell)) (.countDown #^java.util.concurrent.CountDownLatch latch Thanks, Anand On Feb 23, 5:20 pm, Anand Patil anand.prabhakar.pa...@gmail.com wrote: Hi all, I'm getting Reflection warning, line: 150 - reference to field countDown can't be resolved. from (if cell-updated? (if (not (:updating @cell)) (.countDown latch Is there any way to get rid of it? Thanks, Anand --~--~-~--~~~---~--~~ 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: alternate syntax
Mark Volkmann r.mark.volkm...@gmail.com writes: The parens don't bother me. My concern though is that many people won't take the time to learn Clojure primarily because of the parens. Rule one of programming: never code anything you're not going to use yourself. Unless you're getting paid to do it. Or something. The preprocessor would appease those people and not change anything for those that like Clojure just fine as it is. Not really. People who use this preprocessor would still have to learn to read Clojure code. And presumably these people would be releasing libraries, so this would affect the Real Clojure programmers as well. Nothing happens in a vacuum. This idea gets proposed to various segments of the Lisp community with astonishing regularity[1]. AFAIK the only time it ever went anywhere (for some value of went anywhere at least) was with Dylan[2]. Needless to say, this did nothing to increase the appeal of Dylan to the language community at large and really only alienated people who actually understood Lisp. I hate to sound like a Smug Lisp Weenie™, but if people want to learn Clojure, they're going to have to get comfortable with its syntax. Parentheses aren't some embarrassing historical accident; they're part of the reason lisps are so powerful. -Phil [1] http://www.dwheeler.com/readable/sweet-expressions.html http://www.lispin.org/ http://www.archub.org/noparen.arc http://pschombe.wordpress.com/2006/04/16/lisp-without-parentheses/ ... and many more. [2] http://en.wikipedia.org/wiki/Dylan_programming_language --~--~-~--~~~---~--~~ 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: alternate syntax
2009/2/23 Cosmin Stejerean cstejer...@gmail.com On Mon, Feb 23, 2009 at 11:10 AM, Mark Volkmann r.mark.volkm...@gmail.com wrote: On Mon, Feb 23, 2009 at 10:55 AM, Christian Vest Hansen karmazi...@gmail.com wrote: On Mon, Feb 23, 2009 at 4:42 PM, Mark Volkmann r.mark.volkm...@gmail.com wrote: I have an idea I'd like to float to see if there are reasons why it's a bad idea. What if Clojure had an alternate surface syntax that was translated into standard Clojure syntax by a kind of preprocessor? Do you by any chance mean custom reader when you say preprocessor? :) No. This would be a translation step before the code is fed to the current Clojure reader. This sounds to me like a better fit for an editor plugin (that would add parentheses as you type based on indentation, and optionally hide them as well when editing the source). Indeed, it's something I've also kept in mind when clojure-dev has waaay more functionalities than now (so this day is not coming very soon ;-). That is, experimenting with an optional thin layer between the user and the real source file. In order for that to work, though, I think the rules must allow for real bi-directional translation from the 2 forms. And concerning the rule for if, there may be another more general pattern to find. Certainly something along the lines of how Haskell does things. -- Laurent -- Cosmin Stejerean http://offbytwo.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: alternate syntax
What if Clojure had an alternate surface syntax that was translated into standard Clojure syntax by a kind of preprocessor? Many people that don't like Lisp dialects don't like them because of the parentheses. Agreed the parentheses take getting used to, and I respect that you want to expand the Clojure community by helping parentheses-adverse people out. It seems to me that introducing a second syntax may help beginners but will make things worse the longer they use it. For example, if a second-syntax user has a problem, where should they go for help? Should there be two Clojure forums, one for the Lisp syntax and one for the second syntax? Should there be two versions of the documentation, one written in the second syntax? Which syntax should libraries be written in? Of course as long as there aren't any bugs in the preprocessor, code written in the two syntaxes should be compatible, but if I use the second syntax because I don't want to adjust to parentheses, what happens if I need to read library code that's been written using Lisp syntax? Bill Smith --~--~-~--~~~---~--~~ 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: alternate syntax
On Feb 23, 11:29 am, Phil Hagelberg p...@hagelb.org wrote: I hate to sound like a Smug Lisp Weenie™, but if people want to learn Clojure, they're going to have to get comfortable with its syntax. Parentheses aren't some embarrassing historical accident; they're part of the reason lisps are so powerful. Actually, they're both[0] ;-) :dudley [0] http://en.wikipedia.org/wiki/M-expression --~--~-~--~~~---~--~~ 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: *features*-var
On Mon, Feb 23, 2009 at 11:16 AM, pmf phil.fr...@gmx.de wrote: Some (most, if not all) CL variants have a *features*-var available that contains information about what the implementation supports and what not. Seeing that the issue of determining the Clojure-version in use come up from time to time, maybe it would be useful to introduce something like this for Clojure. For example, identifying whether one is using the lazy (lazier) version would then be possible by checking for the presence of a flag :lazy (in this particular case, checking for the presence of lazy-seq would be enough, but other feature-sets might be harder to detect). I don't think something like *features* makes sense in Clojure. Unlike CL there isn't an incomplete standard with many slightly different implementations. Requiring a specific version (or range of versions) of Clojure should be sufficient to ensure that the code is run against a compatible version of Clojure. For now I assume that means SVN revision numbers until we get to 1.0 -- Cosmin Stejerean http://offbytwo.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: alternate syntax
While in another answer to this post, I said I had in mind to experiment with such a thing when time permits on clojure-dev, I've then followed some links, seen some attempts to remove parentheses ... ... and was very surprised to feel a little losts without the parenthesis on the examples ! :-) Anyway, since clojure-dev colorizes parenthesis depending on how deep they are in the hierarchy, I think it's not even painfull at all to live with parenthesis. See this snapshot for an example : http://code.google.com/p/clojure-dev/wiki/ScreenShots#Source_code_Editor I know also of gorilla (vim plugin), and certainly emacs (not sure about enclojure, though) that offer parens colorizing (also named rainbow parens). Concerning the debate : should this be just an IDE trick to remove parens, or a preprocessor, I'm very very against the idea of a preprocessor, for all the reasons other people have said about it : because it will inevitably lock beginners into something that is not really clojure, they won't be able to easily share libraries, they will feel bad when reading real clojure libraries code. In the other end, I think a bidirectional translator could be interesting in an IDE to visually help people, from time to time. My 0,02 €, -- Laurent 2009/2/23 Mark Volkmann r.mark.volkm...@gmail.com I have an idea I'd like to float to see if there are reasons why it's a bad idea. What if Clojure had an alternate surface syntax that was translated into standard Clojure syntax by a kind of preprocessor? Many people that don't like Lisp dialects don't like them because of the parentheses. I'm trying to address that. Here's a simple example of valid Clojure code. (defn pig-latin [word] (let [first-letter (first word)] (if (.contains aeiou (str first-letter)) (str word ay) (str (subs word 1) first-letter ay (println (pig-latin red)) (println (pig-latin orange)) Here's what that same code would look like in my alternate syntax. defn pig-latin [word] let [first-letter (first word)] if .contains aeiou (str first-letter) str word ay str (subs word 1) first-letter ay println (pig-latin red) println (pig-latin orange) The rules for turning this into standard Clojure syntax are pretty simple. 1) If a line is indented farther than the previous one, it is part of the previous line. 2) If a line doesn't start with a (, then add one. 3) If the next line is indented less than this one, add the appropriate number of )'s at the end. 4) If the first token on a line is if and the first non-whitespace character after it is not ( then assume the rest of the line is the condition and wrap it in ( ). A translation from standard Clojure syntax to this alternate form should also be possible. Is this a bad idea? -- R. Mark Volkmann Object Computing, Inc. --~--~-~--~~~---~--~~ 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: better syntax highlighting for Clojure
Hello Stuart, Can you explain what this is ? Is it just something related to your book, or something that also colors syntax on websites (maybe the clojure website, or github ..) ? Indeed, if these are the commonly accepted colors for clojure code, I'll consider adapt clojure-dev to stick with this coloring scheme. Thanks in advance, -- Laurent 2009/2/23 Stuart Halloway stuart.hallo...@gmail.com I have improved the clojure.js bits [1]. Various small changes, but the big issue was to discontinue using \b for end of word, which does not work well with names-like-this. Feedback or additional improvements welcome. Stuart [1] http://github.com/stuarthalloway/programming-clojure/blob/95d9943dfb54112912714a2d741a34749bca3be2/public/javascripts/clojure.js --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Another look at streams
I have been playing a bit more with the concept of a data stream for building computational pipelines. The result has replaced my previous experimental stream-utils library in clojure.contrib: http://code.google.com/p/clojure-contrib/source/browse/trunk/src/ clojure/contrib/stream_utils.clj Examples are provided as well: http://code.google.com/p/clojure-contrib/source/browse/trunk/src/ clojure/contrib/stream_utils/examples.clj This new stream-utils library is for the now standard Clojure branch, not for the experimental streams branch. This module introduces a new way to represent streams in the form of stream generator closures. It also contains an interface to streams through a multimethod that is implemented for stream generator closures and for lazy sequences. Next, there is a stream transformer monad plus associated utility functions/macros. The basic idea behind the stream generator closures is that a stream is not represented by its elements (as in Rich's experimental stream implementation in the streams branch of Clojure), but by its current state plus a function that converts the current state into the next value plus the new state, the state and the function being wrapped up together in a closure. The closure is called with an arbitrary end-of- stream value, and returns a vector containing the next value in the sequence (or end-of-stream) plus a stream generator closure encapsulating the new state. The implementation of such a stream generator looks quite similar to the implementation of a lazy seq. Compare for example the following two functions implementing a simple random-number generator: (defn rng-gen [seed] (fn [eos] (let [m 259200 value (/ (float seed) (float m)) next (rem (+ 54773 (* 7141 seed)) m)] [value (rng-gen next)]))) (defn rng-seq [seed] (lazy-seq (let [m 259200 value (/ (float seed) (float m)) next (rem (+ 54773 (* 7141 seed)) m)] (cons value (rng-seq next) While generator closures are less convenient than lazy seqs because they are less well integrated into Clojure's ecosystem, they do have a couple of advantages: 1) No values are ever cached. 2) It is easy to keep a reference to a stream state and recreate the stream from it at any time. 3) I expect them to be faster because they don't need to go through a caching mechanism, but I didn't actually do any timings until now. It would be nice if stream generators could be made seq-able, removing the need for stream-as-seq, but this doesn't look simple, requiring at least proxy if not gen-class. Any suggestions about how to do this are welcome, as is any other feedback on the stream-utils library. Konrad. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com 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: better syntax highlighting for Clojure
Laurent, I originally grabbed the js and css from the Google groups files. I haven't changed the colors--I merely adapted the js to do a better job of identifying clojure names. The js and css should work on any website, which is why I thought this might be of general interest. Stuart Hello Stuart, Can you explain what this is ? Is it just something related to your book, or something that also colors syntax on websites (maybe the clojure website, or github ..) ? Indeed, if these are the commonly accepted colors for clojure code, I'll consider adapt clojure-dev to stick with this coloring scheme. Thanks in advance, -- Laurent 2009/2/23 Stuart Halloway stuart.hallo...@gmail.com I have improved the clojure.js bits [1]. Various small changes, but the big issue was to discontinue using \b for end of word, which does not work well with names-like-this. Feedback or additional improvements welcome. Stuart [1] http://github.com/stuarthalloway/programming-clojure/blob/95d9943dfb54112912714a2d741a34749bca3be2/public/javascripts/clojure.js --~--~-~--~~~---~--~~ 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: challenge: best fibo implementation under the new laziness?
Using a good old sequence of vectors: (defn fibo [] (map first (iterate (fn [[a b]] [b (+ a b)]) [0 1]))) Christophe Stuart Halloway a écrit : I have updated the sample source from the book (http://tinyurl.com/clojure-samples ) to the new laziness. Along the way, I replaced the lazy-cons based implementation of the fibonacci numbers with this: (defn fibo ([] (concat [0 1] (fibo 0 1))) ([a b] (let [n (+ a b)] (lazy-seq (cons n (fibo b n)) Is there a better/more idiomatic approach, without resorting to code in clojure-contrib? Test your code against the following expression to flush out stack and heap overflows. (rem (nth (fibo) 100) 1000) - 875 Also, the current 'fibs' implementation in clojure.contrib.seq fails the test above, because it holds the entire sequence as it goes. We should replace it with whatever the community comes up with on this thread. Cheers, Stu -- 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: alternate syntax
Yes, clojure needs an alternative surface syntax for obvious reasons. And anybody that brings up Dylan as a counter-example doesn't know what they're talking about. Dylan died because Apple killed it. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: alternate syntax
But.. but... macros? code is no longer data? On Feb 23, 2009, at 10:42 AM, Mark Volkmann wrote: I have an idea I'd like to float to see if there are reasons why it's a bad idea. What if Clojure had an alternate surface syntax that was translated into standard Clojure syntax by a kind of preprocessor? Many people that don't like Lisp dialects don't like them because of the parentheses. I'm trying to address that. Here's a simple example of valid Clojure code. (defn pig-latin [word] (let [first-letter (first word)] (if (.contains aeiou (str first-letter)) (str word ay) (str (subs word 1) first-letter ay (println (pig-latin red)) (println (pig-latin orange)) Here's what that same code would look like in my alternate syntax. defn pig-latin [word] let [first-letter (first word)] if .contains aeiou (str first-letter) str word ay str (subs word 1) first-letter ay println (pig-latin red) println (pig-latin orange) The rules for turning this into standard Clojure syntax are pretty simple. 1) If a line is indented farther than the previous one, it is part of the previous line. 2) If a line doesn't start with a (, then add one. 3) If the next line is indented less than this one, add the appropriate number of )'s at the end. 4) If the first token on a line is if and the first non-whitespace character after it is not ( then assume the rest of the line is the condition and wrap it in ( ). A translation from standard Clojure syntax to this alternate form should also be possible. Is this a bad idea? -- R. Mark Volkmann Object Computing, Inc. --~--~-~--~~~---~--~~ 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: alternate syntax
On Feb 23, 2009, at 1:21 PM, MarkH wrote: Yes, clojure needs an alternative surface syntax for obvious reasons. And anybody that brings up Dylan as a counter-example doesn't know what they're talking about. Dylan died because Apple killed it. It may be more productive to help newcomers understand why parentheses are handy and not baggage. Something like coffeemug's post on the subject: http://www.defmacro.org/ramblings/lisp.html --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com 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: alternate syntax
Hi, Am 23.02.2009 um 19:42 schrieb Dan Larkin: But.. but... macros? code is no longer data? It still is. Macros don't work on the String (foo bar) but on the data structure (list 'foo 'bar). Whether this is represented as foo bar, (foo bar) or implicit via indentation doesn't change this. Macros happen after the reader Sincerely Meikel smime.p7s Description: S/MIME cryptographic signature
:use feature requests
I have a feature request for the 'use' function. First an example. I have some real-world code like this: (ns n01se.net.graph.issues (:import (java.text SimpleDateFormat ParsePosition) (java.util GregorianCalendar Calendar) (org.jfree.chart ChartFrame)) (:use [clojure.zip:only (xml-zip node)] [clojure.contrib.lazy-xml :only (parse-trim)] [clojure.contrib.zip-filter.xml :only (xml- attr text)] [clojure.contrib.seq-utils :only (reductions)]) (:require [clojure.contrib.zip-filter :as zf] [com.markmfredrickson.dejcartes :as chart])) It struck me as awkward that libs are separated into :use and :require blocks when I need almost the same thing from each. In fact, any one lib has a tendency to be shuffled between the two as I tidy up usages in the code and change my mind about whether I want the whole namespace aliased or specific functions brought in. After kicking around some alternatives, I realized 'use' is sufficient for all cases: (ns n01se.net.graph.issues (:import (java.text SimpleDateFormat ParsePosition) (java.util GregorianCalendar Calendar) (org.jfree.chart ChartFrame)) (:use [clojure.zip:only (xml-zip node)] [clojure.contrib.zip-filter :as zf :only ()] [clojure.contrib.zip-filter.xml :only (xml- attr text)] [clojure.contrib.lazy-xml :only (parse-trim)] [clojure.contrib.seq-utils :only (reductions)] [com.markmfredrickson.dejcartes :as chart :only ()])) This is much prettier to my eye, but has a couple things that could be better. So, feature request #1 is that if a libspec has an :as option, that the :only [] option be implied. That is, if I'm aliasing an namespace, don't by default refer in all that namespaces vars. While this would technically be a breaking change, it seems unlikely to me that it will cause much if any real-world disruption. Any usage that actually intended to both alias the namespace and refer all the symbols could say [my.lib :as mylib :exclude ()] --Chouser --~--~-~--~~~---~--~~ 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
On Feb 23, 2009, at 1:54 PM, Chouser wrote: After kicking around some alternatives, I realized 'use' is sufficient for all cases: (ns n01se.net.graph.issues (:import (java.text SimpleDateFormat ParsePosition) (java.util GregorianCalendar Calendar) (org.jfree.chart ChartFrame)) (:use [clojure.zip:only (xml-zip node)] [clojure.contrib.zip-filter :as zf :only ()] [clojure.contrib.zip-filter.xml :only (xml- attr text)] [clojure.contrib.lazy-xml :only (parse-trim)] [clojure.contrib.seq-utils :only (reductions)] [com.markmfredrickson.dejcartes :as chart :only ()])) This is much prettier to my eye, but has a couple things that could be better. So, feature request #1 is that if a libspec has an :as option, that the :only [] option be implied. That is, if I'm aliasing an namespace, don't by default refer in all that namespaces vars. While this would technically be a breaking change, it seems unlikely to me that it will cause much if any real-world disruption. Any usage that actually intended to both alias the namespace and refer all the symbols could say [my.lib :as mylib :exclude ()] I like this a lot. At that point, it seems only a small step to remove require entirely which I think would be a long-term plus--coalescing two very similar things (require and use) into one (use) with (possibly) an additional option. In order to keep it clear what non-core symbols refer to, several of us have been recommending always using either :as or :only and only very rarely if ever a naked use. How about this as an alternative in the same spirit as your proposal: - change the name of :require to :use -- :use with no options changes from an implicit refer all to an implicit refer none - :as, :only, :exclude, and :rename work as they do now - add an :all option to cover the case of really wanting to refer in all of the subject namespace. It would have the same effect as :exclude (). (Alternatively, perhaps we intend for this to be a rare enough use case that :exclude () by itself would suffice.) Of course this would be a bigger, definitely breaking change, but not breakage that will be at all difficult to find or fix in old or new code. --Steve smime.p7s Description: S/MIME cryptographic signature
Re: :use feature requests
On Mon, Feb 23, 2009 at 2:33 PM, Stephen C. Gilardi squee...@mac.com wrote: At that point, it seems only a small step to remove require entirely which I think would be a long-term plus--coalescing two very similar things (require and use) into one (use) with (possibly) an additional option. In order to keep it clear what non-core symbols refer to, several of us have been recommending always using either :as or :only and only very rarely if ever a naked use. How about this as an alternative in the same spirit as your proposal: - change the name of :require to :use -- :use with no options changes from an implicit refer all to an implicit refer none - :as, :only, :exclude, and :rename work as they do now - add an :all option to cover the case of really wanting to refer in all of the subject namespace. It would have the same effect as :exclude (). (Alternatively, perhaps we intend for this to be a rare enough use case that :exclude () by itself would suffice.) Of course this would be a bigger, definitely breaking change, but not breakage that will be at all difficult to find or fix in old or new code. I'm completely in favor of all of this -- let's do it! --Chouser --~--~-~--~~~---~--~~ 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: suggestion for resultset-seq and duplicate column names
On Feb 23, 8:33 am, Rich Hickey richhic...@gmail.com wrote: Sounds good to me - any drawbacks to this? Does it require that the columns be named explicitly? I can't think of any drawbacks. When the column is not named explicitly, getColumnLabel returns the same thing as getColumnName. Rob --~--~-~--~~~---~--~~ 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: challenge: best fibo implementation under the new laziness?
On Feb 23, 2009, at 11:43 AM, Stuart Halloway wrote: Also, the current 'fibs' implementation in clojure.contrib.seq fails the test above, because it holds the entire sequence as it goes. We should replace it with whatever the community comes up with on this thread. The fibs implementation in clojure.contrib.lazy-seqs is not a function that returns fib(n) given n. Instead, it is an infinite sequence of all the fibonacci numbers. It holds onto its head because it's intended to. It's surely not the right way to deal with fibonacci numbers in every context, but I don't think it needs replacing because it requires a large java heap to pass this test: (rem (nth clojure.contrib.lazy-seqs/fibs 100) 1000) - 875 I think defining a fib(n) function somewhere in contrib or core that operates as efficiently as we can manage would be a good idea. --Steve smime.p7s Description: S/MIME cryptographic signature
Re: :use feature requests
Stuart is gonna love you guys ;) On Feb 23, 2:59 pm, Chouser chou...@gmail.com wrote: On Mon, Feb 23, 2009 at 2:33 PM, Stephen C. Gilardi squee...@mac.com wrote: At that point, it seems only a small step to remove require entirely which I think would be a long-term plus--coalescing two very similar things (require and use) into one (use) with (possibly) an additional option. In order to keep it clear what non-core symbols refer to, several of us have been recommending always using either :as or :only and only very rarely if ever a naked use. How about this as an alternative in the same spirit as your proposal: - change the name of :require to :use -- :use with no options changes from an implicit refer all to an implicit refer none - :as, :only, :exclude, and :rename work as they do now - add an :all option to cover the case of really wanting to refer in all of the subject namespace. It would have the same effect as :exclude (). (Alternatively, perhaps we intend for this to be a rare enough use case that :exclude () by itself would suffice.) Of course this would be a bigger, definitely breaking change, but not breakage that will be at all difficult to find or fix in old or new code. I'm completely in favor of all of this -- let's do it! --Chouser --~--~-~--~~~---~--~~ 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
On Feb 23, 6:54 pm, Chouser chou...@gmail.com wrote: (ns n01se.net.graph.issues (:import (java.text SimpleDateFormat ParsePosition) (java.util GregorianCalendar Calendar) (org.jfree.chart ChartFrame)) (:use [clojure.zip :only (xml-zip node)] [clojure.contrib.zip-filter :as zf :only ()] [clojure.contrib.zip-filter.xml :only (xml- attr text)] [clojure.contrib.lazy-xml :only (parse-trim)] [clojure.contrib.seq-utils :only (reductions)] [com.markmfredrickson.dejcartes :as chart :only ()])) Whilst we're throwing out ideas, I almost wonder if it wouldn't be worth allowing for this case in addition: (ns foo.bar (:use clojure.zip :only (xml-zip node)) (:use clojure.contrib.zip-filter :as zf)) It seems a little more aesthetically pleasing to me, and whilst it would require a lookahead of 1 to watch for keywords, some of the current binding syntax does the same. - James --~--~-~--~~~---~--~~ 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: transactions and retries
If I understand correctly, when there is an attempt to modify a Ref that has been modified in another thread since the current transaction began then the current transaction will retry immediately. Isn't it true that it has no chance of completing until the transaction that changed that Ref either commits or rolls back? If that is true, wouldn't it make sense to make the retry wait until that other transaction is finished? Maybe the point of retrying immediately is that it can at least get through some of its work (the part before it tries to change the Ref in question) before it has to check on that other transaction again. Until there is a commit, no one but the transaction knows that those refs are meant to hold new values. When your transaction notices something is wrong and retries, the other transaction will *always* be finished. Which of course doesn't mean another transaction might not prevent it to finish again. --~--~-~--~~~---~--~~ 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: alternate syntax
I'm opposed to this idea. I don't think we should pander to the masses by creating a schism between new and experienced users. New users should be introduced to the real thing immediately and it is up to the tutorials and community to help them overcome the fear/ puzzlement of parentheses. Like many other people have mentioned, parentheses are not there just to be different, they're an integral part of Clojure's power and hiding that fact from users will just prevent them from using Clojure the way it's meant to. What's the problem with parentheses anyway? It's the same as in Java except you move the opening parentheses to the left of the function name (and with Clojure, you don't even need to remove the commas!): foo(bar, baz) = (foo bar, baz) Vincent. On Feb 23, 10:42 am, Mark Volkmann r.mark.volkm...@gmail.com wrote: I have an idea I'd like to float to see if there are reasons why it's a bad idea. What if Clojure had an alternate surface syntax that was translated into standard Clojure syntax by a kind of preprocessor? Many people that don't like Lisp dialects don't like them because of the parentheses. I'm trying to address that. Here's a simple example of valid Clojure code. (defn pig-latin [word] (let [first-letter (first word)] (if (.contains aeiou (str first-letter)) (str word ay) (str (subs word 1) first-letter ay (println (pig-latin red)) (println (pig-latin orange)) Here's what that same code would look like in my alternate syntax. defn pig-latin [word] let [first-letter (first word)] if .contains aeiou (str first-letter) str word ay str (subs word 1) first-letter ay println (pig-latin red) println (pig-latin orange) The rules for turning this into standard Clojure syntax are pretty simple. 1) If a line is indented farther than the previous one, it is part of the previous line. 2) If a line doesn't start with a (, then add one. 3) If the next line is indented less than this one, add the appropriate number of )'s at the end. 4) If the first token on a line is if and the first non-whitespace character after it is not ( then assume the rest of the line is the condition and wrap it in ( ). A translation from standard Clojure syntax to this alternate form should also be possible. Is this a bad idea? -- R. Mark Volkmann Object Computing, Inc. --~--~-~--~~~---~--~~ 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: alternate syntax
http://xkcd.com/297/ 'nuff said ;-) Tom 2009/2/23 Vincent Foley vfo...@gmail.com I'm opposed to this idea. I don't think we should pander to the masses by creating a schism between new and experienced users. New users should be introduced to the real thing immediately and it is up to the tutorials and community to help them overcome the fear/ puzzlement of parentheses. Like many other people have mentioned, parentheses are not there just to be different, they're an integral part of Clojure's power and hiding that fact from users will just prevent them from using Clojure the way it's meant to. What's the problem with parentheses anyway? It's the same as in Java except you move the opening parentheses to the left of the function name (and with Clojure, you don't even need to remove the commas!): foo(bar, baz) = (foo bar, baz) Vincent. On Feb 23, 10:42 am, Mark Volkmann r.mark.volkm...@gmail.com wrote: I have an idea I'd like to float to see if there are reasons why it's a bad idea. What if Clojure had an alternate surface syntax that was translated into standard Clojure syntax by a kind of preprocessor? Many people that don't like Lisp dialects don't like them because of the parentheses. I'm trying to address that. Here's a simple example of valid Clojure code. (defn pig-latin [word] (let [first-letter (first word)] (if (.contains aeiou (str first-letter)) (str word ay) (str (subs word 1) first-letter ay (println (pig-latin red)) (println (pig-latin orange)) Here's what that same code would look like in my alternate syntax. defn pig-latin [word] let [first-letter (first word)] if .contains aeiou (str first-letter) str word ay str (subs word 1) first-letter ay println (pig-latin red) println (pig-latin orange) The rules for turning this into standard Clojure syntax are pretty simple. 1) If a line is indented farther than the previous one, it is part of the previous line. 2) If a line doesn't start with a (, then add one. 3) If the next line is indented less than this one, add the appropriate number of )'s at the end. 4) If the first token on a line is if and the first non-whitespace character after it is not ( then assume the rest of the line is the condition and wrap it in ( ). A translation from standard Clojure syntax to this alternate form should also be possible. Is this a bad idea? -- R. Mark Volkmann Object Computing, Inc. --~--~-~--~~~---~--~~ 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: *features*-var
I've always thought *features* was a nuisance in CL, since very few values were ever standardized. It ends up being used like browser- sniffing code in JavaScript. -Stuart Sierra On Feb 23, 12:16 pm, pmf phil.fr...@gmx.de wrote: Some (most, if not all) CL variants have a *features*-var available that contains information about what the implementation supports and what not. Seeing that the issue of determining the Clojure-version in use come up from time to time, maybe it would be useful to introduce something like this for Clojure. For example, identifying whether one is using the lazy (lazier) version would then be possible by checking for the presence of a flag :lazy (in this particular case, checking for the presence of lazy-seq would be enough, but other feature-sets might be harder to detect). --~--~-~--~~~---~--~~ 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: transactions and retries
On Mon, Feb 23, 2009 at 2:31 PM, Dan redalas...@gmail.com wrote: If I understand correctly, when there is an attempt to modify a Ref that has been modified in another thread since the current transaction began then the current transaction will retry immediately. Isn't it true that it has no chance of completing until the transaction that changed that Ref either commits or rolls back? If that is true, wouldn't it make sense to make the retry wait until that other transaction is finished? Maybe the point of retrying immediately is that it can at least get through some of its work (the part before it tries to change the Ref in question) before it has to check on that other transaction again. Until there is a commit, no one but the transaction knows that those refs are meant to hold new values. Ah ... I didn't know that. I did know that the new value wasn't visible outside the uncommitted transaction, but I thought other transactions were aware that some other transaction was changing it. Thanks for explaining that! When your transaction notices something is wrong and retries, the other transaction will *always* be finished. Which of course doesn't mean another transaction might not prevent it to finish again. -- R. Mark Volkmann Object Computing, Inc. --~--~-~--~~~---~--~~ 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
On Mon, Feb 23, 2009 at 2:29 PM, James Reeves weavejes...@googlemail.comwrote: On Feb 23, 6:54 pm, Chouser chou...@gmail.com wrote: (ns n01se.net.graph.issues (:import (java.text SimpleDateFormat ParsePosition) (java.util GregorianCalendar Calendar) (org.jfree.chart ChartFrame)) (:use [clojure.zip:only (xml-zip node)] [clojure.contrib.zip-filter :as zf :only ()] [clojure.contrib.zip-filter.xml :only (xml- attr text)] [clojure.contrib.lazy-xml :only (parse-trim)] [clojure.contrib.seq-utils :only (reductions)] [com.markmfredrickson.dejcartes :as chart :only ()])) Whilst we're throwing out ideas, I almost wonder if it wouldn't be worth allowing for this case in addition: (ns foo.bar (:use clojure.zip :only (xml-zip node)) (:use clojure.contrib.zip-filter :as zf)) +1 I think :as should be mutually exclusive with :only (and friends). -- Cosmin Stejerean http://offbytwo.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: alternate syntax
On Feb 23, 10:42 am, Mark Volkmann r.mark.volkm...@gmail.com wrote: What if Clojure had an alternate surface syntax that was translated into standard Clojure syntax by a kind of preprocessor? Many people that don't like Lisp dialects don't like them because of the parentheses. I'm trying to address that. Heh heh. This is one of the oldest debates in programming languages. The original Lisp had something called M-expressions, a surface syntax without parentheses. But no one ever bothered to implement it. About once a month someone brings up Lisp without parentheses on comp.lang.lisp. It's never caught on. For one thing, it's harder than you think when you get into all the edge-cases. For another, it usually doesn't offer any compelling advantages over the standard syntax. -Stuart Sierra --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com 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: alternate syntax
It's a good idea. Not for anyone to actually use, but as an demonstration of code is data, and of the separation of surface syntax from the code data-structure. Can you do this without reader macros? Can you keep it homoiconic? (Apparently so, given the transformation rules, but I wonder if there are any corner cases.) Joshua On Mon, Feb 23, 2009 at 5:42 PM, Mark Volkmann r.mark.volkm...@gmail.comwrote: I have an idea I'd like to float to see if there are reasons why it's a bad idea. What if Clojure had an alternate surface syntax that was translated into standard Clojure syntax by a kind of preprocessor? Many people that don't like Lisp dialects don't like them because of the parentheses. I'm trying to address that. Here's a simple example of valid Clojure code. (defn pig-latin [word] (let [first-letter (first word)] (if (.contains aeiou (str first-letter)) (str word ay) (str (subs word 1) first-letter ay (println (pig-latin red)) (println (pig-latin orange)) Here's what that same code would look like in my alternate syntax. defn pig-latin [word] let [first-letter (first word)] if .contains aeiou (str first-letter) str word ay str (subs word 1) first-letter ay println (pig-latin red) println (pig-latin orange) The rules for turning this into standard Clojure syntax are pretty simple. 1) If a line is indented farther than the previous one, it is part of the previous line. 2) If a line doesn't start with a (, then add one. 3) If the next line is indented less than this one, add the appropriate number of )'s at the end. 4) If the first token on a line is if and the first non-whitespace character after it is not ( then assume the rest of the line is the condition and wrap it in ( ). A translation from standard Clojure syntax to this alternate form should also be possible. Is this a bad idea? -- R. Mark Volkmann Object Computing, Inc. --~--~-~--~~~---~--~~ 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: alternate syntax
On Mon, Feb 23, 2009 at 2:38 PM, Dan redalas...@gmail.com wrote: [...] The problem is (+ 1 2) which is unlike how you normally do maths Removing parens doesn't solve the problem with (+ 1 2). For writing out math formulas a macro that allows infix notation would be useful (and I'm pretty sure I've seen at least one). -- Cosmin Stejerean http://offbytwo.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: challenge: best fibo implementation under the new laziness?
As the sequence is very cheap to calculate it is difficult to see the benefit of keeping it in memory under any circumstances. I would replace the one in contrib with Christophe's short, easy to understand implementation. Caching values isn't getting you anywhere; just wasting resources. Chris On Feb 23, 12:51 pm, Stephen C. Gilardi squee...@mac.com wrote: On Feb 23, 2009, at 11:43 AM, Stuart Halloway wrote: Also, the current 'fibs' implementation in clojure.contrib.seq fails the test above, because it holds the entire sequence as it goes. We should replace it with whatever the community comes up with on this thread. The fibs implementation in clojure.contrib.lazy-seqs is not a function that returns fib(n) given n. Instead, it is an infinite sequence of all the fibonacci numbers. It holds onto its head because it's intended to. It's surely not the right way to deal with fibonacci numbers in every context, but I don't think it needs replacing because it requires a large java heap to pass this test: (rem (nth clojure.contrib.lazy-seqs/fibs 100) 1000) - 875 I think defining a fib(n) function somewhere in contrib or core that operates as efficiently as we can manage would be a good idea. --Steve smime.p7s 3KViewDownload --~--~-~--~~~---~--~~ 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: Macro madness
Check out the part of this page on syntax quote http://clojure.org/reader As I understand it, syntax-quote namespace-resolves symbols to prevent accidental variable capture. 90% of the time, any variables you let within a macro should be suffixed by a #. So, if you replace all occurrences of fd, controller, control, etc. with fd#, controller#, control#, you should be taking a step in the right direction. (This improves the CL behavior of having to manually create gensyms outside of the macro-generated body if you want to write hygenic macros). HTH, Jason On Feb 23, 12:25 pm, max3000 maxime.lar...@gmail.com wrote: Hi, I'm new to lisp and clojure, so what follows may be a very easy (i.e. stupid) question... I want a macro to generate multi-methods. Here is the macro I crafted: (defmacro mcf [type class set-expr forms] '(defmethod make ~type [fd controller] (let [control (new ~class)] (doto control ~@(map (fn [f] f) forms) (~set-expr (. controller link control (:uid fd))) For instance, I want this: (mcf :String JTextField .setText (.setColumns 15) (.setEditable false)) To generate this: (defmethod make :String [fd controller] (let [control (new JTextField)] (doto control (.setColumns 15) (.setEditable false) (.setText (. controller link control (:uid fd)) For some reason, controller, link, control and fd don't seem to be handled properly. No matter what escaping I try (quotes, semi-quotes), I always get some error similar to No such var: clojure.core/link. Clojure seems to think link is a variable in the namespace while it is in fact a (java) method on the controller. I just want to output the last part verbatim (. controller link control...), I want no ahead- of-time dereferencing... What am I missing? Is it even possible? Thanks, Max --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com 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: Macro madness
Try this syntax: ~'link Cheers, Telman On Feb 23, 3:25 pm, max3000 maxime.lar...@gmail.com wrote: Hi, I'm new to lisp and clojure, so what follows may be a very easy (i.e. stupid) question... I want a macro to generate multi-methods. Here is the macro I crafted: (defmacro mcf [type class set-expr forms] '(defmethod make ~type [fd controller] (let [control (new ~class)] (doto control ~@(map (fn [f] f) forms) (~set-expr (. controller link control (:uid fd))) For instance, I want this: (mcf :String JTextField .setText (.setColumns 15) (.setEditable false)) To generate this: (defmethod make :String [fd controller] (let [control (new JTextField)] (doto control (.setColumns 15) (.setEditable false) (.setText (. controller link control (:uid fd)) For some reason, controller, link, control and fd don't seem to be handled properly. No matter what escaping I try (quotes, semi-quotes), I always get some error similar to No such var: clojure.core/link. Clojure seems to think link is a variable in the namespace while it is in fact a (java) method on the controller. I just want to output the last part verbatim (. controller link control...), I want no ahead- of-time dereferencing... What am I missing? Is it even possible? Thanks, Max --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com 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: transactions and retries
On Feb 23, 2009, at 3:44 PM, Mark Volkmann wrote: On Mon, Feb 23, 2009 at 2:31 PM, Dan redalas...@gmail.com wrote: If I understand correctly, when there is an attempt to modify a Ref that has been modified in another thread since the current transaction began then the current transaction will retry immediately. Isn't it true that it has no chance of completing until the transaction that changed that Ref either commits or rolls back? If that is true, wouldn't it make sense to make the retry wait until that other transaction is finished? Maybe the point of retrying immediately is that it can at least get through some of its work (the part before it tries to change the Ref in question) before it has to check on that other transaction again. Until there is a commit, no one but the transaction knows that those refs are meant to hold new values. Ah ... I didn't know that. I did know that the new value wasn't visible outside the uncommitted transaction, but I thought other transactions were aware that some other transaction was changing it. Thanks for explaining that! When your transaction notices something is wrong and retries, the other transaction will *always* be finished. Which of course doesn't mean another transaction might not prevent it to finish again. This stuff is not right. You really shouldn't be concerned about the details of what happens when *inside* a transaction. The guarantees of http://clojure.org/refs are met, but the exact flow can get complex - there is blocking, deadlock avoidance and conflict resolution, aging and barging etc. I frequently see these this happens then that happens imaginings about what happens inside transactions. Nothing other than what is documented is guaranteed, and those guarantees are about what a transaction sees, and what its effects are on commit, not the order of operations inside a transaction. If you're not doing side effects in transactions, you shouldn't care, and you shouldn't be doing side effects in transactions. 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 -~--~~~~--~~--~--~---
newbie troubles with new lazy-seq hotness (OutOfMemory)
;; - ;; using clojure.jar from source r1301 ;; ;; I'm new to clojure and working from B7.0 of Programming Clojure. ;; This version still uses lazy-cons. Nevertheless I'm trying to grok lazy-seq ;; as described here: http://clojure.org/lazy ;; ;; It seems I've not understood it because I'm getting OutOfMemoryError ;; below and this surprises me ;; bog-standard iterative fib. ;; This works as expected (defn fibi [n] (loop [a 0, b 1, i n] (if (= i 0) a (recur b (+ a b) (dec i) ;; (count (str (fibi 10))) ;; -- 20899 ;; my attempt to define a lazy fib sequence. ;; working? not so much. (def fibl ((fn h [a b] (lazy-seq (cons a (h b (+ a b) 0 1)) ;; (count (str (last (take 10 fibl ;; -- java.lang.OutOfMemoryError: Java heap space --~--~-~--~~~---~--~~ 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: alternate syntax
Removing parens doesn't solve the problem with (+ 1 2). For writing out math formulas a macro that allows infix notation would be useful (and I'm pretty sure I've seen at least one). A long time ago I worked for a company that for reasons I will not go into now, wanted to distribute a modified version of CLIPS to its customers that did not resemble LISP syntax. Taking care of things like (printout t foo) was a simple matter of forcing the parser to recognize it as printout(t foo). Piece of cake. The harder problem of course was that (+ 1 2 3) became +(1 2 3) which was even more unacceptable to the customer. Therefore, we added a special null function to the parser that took a bunch of symbols representing an infix mathematical expression and converted it to function calls: (1 + 2 + 3) = +(1 +(2 3)) or (1 + (6 / 3) + 3) = +(1 /(6 3) 3) and so on... It required every math expression to be enclosed in parens, but they didn't care; it was a hit. Weird. I am not encouraging an alternate syntax for Clojure (or Lisp), only stating that turning an s-expr based language into something that vaguely resembles a c-syntax language is not that difficult, even for math expressions. -m --~--~-~--~~~---~--~~ 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: transactions and retries
On Mon, Feb 23, 2009 at 3:19 PM, Rich Hickey richhic...@gmail.com wrote On Feb 23, 2009, at 3:44 PM, Mark Volkmann wrote: On Mon, Feb 23, 2009 at 2:31 PM, Dan redalas...@gmail.com wrote: If I understand correctly, when there is an attempt to modify a Ref that has been modified in another thread since the current transaction began then the current transaction will retry immediately. Isn't it true that it has no chance of completing until the transaction that changed that Ref either commits or rolls back? If that is true, wouldn't it make sense to make the retry wait until that other transaction is finished? Maybe the point of retrying immediately is that it can at least get through some of its work (the part before it tries to change the Ref in question) before it has to check on that other transaction again. Until there is a commit, no one but the transaction knows that those refs are meant to hold new values. Ah ... I didn't know that. I did know that the new value wasn't visible outside the uncommitted transaction, but I thought other transactions were aware that some other transaction was changing it. Thanks for explaining that! When your transaction notices something is wrong and retries, the other transaction will *always* be finished. Which of course doesn't mean another transaction might not prevent it to finish again. This stuff is not right. You really shouldn't be concerned about the details of what happens when *inside* a transaction. The guarantees of http://clojure.org/refs are met, but the exact flow can get complex - there is blocking, deadlock avoidance and conflict resolution, aging and barging etc. I frequently see these this happens then that happens imaginings about what happens inside transactions. Nothing other than what is documented is guaranteed, and those guarantees are about what a transaction sees, and what its effects are on commit, not the order of operations inside a transaction. If you're not doing side effects in transactions, you shouldn't care, and you shouldn't be doing side effects in transactions. Without getting into the implementation details, is there anything wrong with this statement? While in a transaction, if an attempt is made to modify a Ref that has been modified in another transaction that has committed since the current transaction started, the current transaction discards all its in-transaction Ref changes and retries by returning to the beginning of the dosync body. -- R. Mark Volkmann Object Computing, Inc. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
pretty printing code
I recall several people discussing creation of pretty printers for Clojure code on this mailing list. Are any of them in a usable state? I'm looking for one that can be invoked on a file from a terminal window, not one that is part of an editor/IDE plugin. -- R. Mark Volkmann Object Computing, Inc. --~--~-~--~~~---~--~~ 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 troubles with new lazy-seq hotness (OutOfMemory)
The identifier fibl is holding on to the head of the sequence. On Mon, Feb 23, 2009 at 4:04 PM, bsmith.occs bsmith.o...@gmail.com wrote: ;; - ;; using clojure.jar from source r1301 ;; ;; I'm new to clojure and working from B7.0 of Programming Clojure. ;; This version still uses lazy-cons. Nevertheless I'm trying to grok lazy-seq ;; as described here: http://clojure.org/lazy ;; ;; It seems I've not understood it because I'm getting OutOfMemoryError ;; below and this surprises me ;; bog-standard iterative fib. ;; This works as expected (defn fibi [n] (loop [a 0, b 1, i n] (if (= i 0) a (recur b (+ a b) (dec i) ;; (count (str (fibi 10))) ;; -- 20899 ;; my attempt to define a lazy fib sequence. ;; working? not so much. (def fibl ((fn h [a b] (lazy-seq (cons a (h b (+ a b) 0 1)) ;; (count (str (last (take 10 fibl ;; -- java.lang.OutOfMemoryError: Java heap space --~--~-~--~~~---~--~~ 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 Slime, how to jump to a def/defn?
Is this supported yet? M-. is supposed to handle this, but I get an error when I try. David --~--~-~--~~~---~--~~ 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: alternate syntax
On Feb 23, 12:01 pm, Laurent PETIT laurent.pe...@gmail.com wrote: I know also of gorilla (vim plugin), and certainly emacs (not sure about enclojure, though) that offer parens colorizing (also named rainbow parens). Enclojure doesn't, yet at least. --~--~-~--~~~---~--~~ 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 get rid of reflection warning from countdown latch?
On Mon, Feb 23, 2009 at 12:20 PM, Anand Patil anand.prabhakar.pa...@gmail.com wrote: Hi all, I'm getting Reflection warning, line: 150 - reference to field countDown can't be resolved. from (if cell-updated? (if (not (:updating @cell)) (.countDown latch Is there any way to get rid of it? What's the object on which .countDown is called? You need to find where it's first declared and give it a type annotation. Regards, -- miʃel salim • http://hircus.jaiku.com/ IUCS • msa...@cs.indiana.edu Fedora • sali...@fedoraproject.org MacPorts • hir...@macports.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com 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: challenge: best fibo implementation under the new laziness?
Beautiful-thanks. Using a good old sequence of vectors: (defn fibo [] (map first (iterate (fn [[a b]] [b (+ a b)]) [0 1]))) Christophe Stuart Halloway a écrit : I have updated the sample source from the book (http://tinyurl.com/clojure-samples ) to the new laziness. Along the way, I replaced the lazy-cons based implementation of the fibonacci numbers with this: (defn fibo ([] (concat [0 1] (fibo 0 1))) ([a b] (let [n (+ a b)] (lazy-seq (cons n (fibo b n)) Is there a better/more idiomatic approach, without resorting to code in clojure-contrib? Test your code against the following expression to flush out stack and heap overflows. (rem (nth (fibo) 100) 1000) - 875 Also, the current 'fibs' implementation in clojure.contrib.seq fails the test above, because it holds the entire sequence as it goes. We should replace it with whatever the community comes up with on this thread. Cheers, Stu -- 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: alternate syntax
On Mon, Feb 23, 2009 at 10:42 AM, Mark Volkmann r.mark.volkm...@gmail.com wrote: I have an idea I'd like to float to see if there are reasons why it's a bad idea. What if Clojure had an alternate surface syntax that was translated into standard Clojure syntax by a kind of preprocessor? Many people that don't like Lisp dialects don't like them because of the parentheses. I'm trying to address that. Here's a simple example of valid Clojure code. (defn pig-latin [word] (let [first-letter (first word)] (if (.contains aeiou (str first-letter)) (str word ay) (str (subs word 1) first-letter ay (println (pig-latin red)) (println (pig-latin orange)) Here's what that same code would look like in my alternate syntax. defn pig-latin [word] let [first-letter (first word)] if .contains aeiou (str first-letter) str word ay str (subs word 1) first-letter ay println (pig-latin red) println (pig-latin orange) The rules for turning this into standard Clojure syntax are pretty simple. 1) If a line is indented farther than the previous one, it is part of the previous line. 2) If a line doesn't start with a (, then add one. 3) If the next line is indented less than this one, add the appropriate number of )'s at the end. 4) If the first token on a line is if and the first non-whitespace character after it is not ( then assume the rest of the line is the condition and wrap it in ( ). If the procedure application uses a nested expression to select the procedure to apply, it looks like using your heuristics, the parentheses cannot be omitted: Clojure: ((if ( x 0) - +) x) Haskell: (s-expression with optional parentheses and infix operators): (if (x 0) then (\x - -x) else id) x Using your proposed rules, this does not work (if ( x 0) - +) x as the line starts with parentheses, and so the parser will assume parentheses do not need to be added A Haskell-like parser would be kind of cool, though -- is it worth the hassle? -- miʃel salim • http://hircus.jaiku.com/ IUCS • msa...@cs.indiana.edu Fedora • sali...@fedoraproject.org MacPorts • hir...@macports.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com 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: challenge: best fibo implementation under the new laziness?
On Feb 23, 2:51 pm, Stephen C. Gilardi squee...@mac.com wrote: The fibs implementation in clojure.contrib.lazy-seqs is not a function that returns fib(n) given n. I think defining a fib(n) function somewhere in contrib or core that operates as efficiently as we can manage would be a good idea. There was a thread on comp.lang.lisp a while ago where a number of people went back and forth trying to come up withe the fastest fib(n) algorithm (again, *not* returning a sequence, but just the nth fib given n). Here is the winner of that informal competition translated to clojure: (defn fib ([n] (fib n 1)) ([n b] (if (zero? b) ;calculate lucas numbers (cond (zero? n) 2 (= n 1) 1 :otherwise (if (even? n) (let [ k (/ n 2) l (fib k 0)] (+ (* l l) (if (even? k) -2 2))) (let [ k (- n 1) l (fib k 0) f (fib k 1)] (/ (+ (* 5 f) l) 2 (cond;calculate fibonacci numbers (zero? n) 0 (= n 1) 1 :otherwise (if (even? n) (let [ k (/ n 2) l (fib k 0) f (fib k 1)] (* f l)) (let [ k (- n 1) l (fib k 0) f (fib k 1)] (/ (+ f l) 2))) btw, the relatively naive algorithm: (defn fib-naive [n] (first (nth (iterate (fn [[a b]] [b (+ a b)]) [0 1]) n))) takes over 85 seconds, or more than 40 times as long as the lucas number based algorithm at top to compute the one millionth fibonacci number. The simple loop version: (defn fib-naive2 [n] (loop [a 0 b 1 counter 0] (if (= counter n) a (recur b (+ a b) (inc counter) fares exactly the same as one might expect. for comparison, here are some timings under different lisps on the same machine. All timings are after several runs to warm up caches and, in the case of clojure, hotspot optimizations. Time to calculate the one millionth fibonacci number using the lucas number based algorithm at top: clojure: 2 seconds ccl: 0.5 seconds lispworks: 1.7 seconds mzscheme: 0.15 seconds sbcl: 0.8 seconds larceny: 13 seconds ecl: 0.04 seconds as you can see, clojure is competitive with other lisps/schemes, faster than some, slower than others. this is really just a benchmark of the bignum package used by the lisp implementation. I think ecl uses GMP which is quite fast. btw, I tried adding type annotations to the clojure version but it didn't seem to make much difference. --~--~-~--~~~---~--~~ 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 troubles with new lazy-seq hotness (OutOfMemory)
Have you figured this out yet? On Mon, Feb 23, 2009 at 4:58 PM, Jeffrey Straszheim straszheimjeff...@gmail.com wrote: The identifier fibl is holding on to the head of the sequence. On Mon, Feb 23, 2009 at 4:04 PM, bsmith.occs bsmith.o...@gmail.comwrote: ;; - ;; using clojure.jar from source r1301 ;; ;; I'm new to clojure and working from B7.0 of Programming Clojure. ;; This version still uses lazy-cons. Nevertheless I'm trying to grok lazy-seq ;; as described here: http://clojure.org/lazy ;; ;; It seems I've not understood it because I'm getting OutOfMemoryError ;; below and this surprises me ;; bog-standard iterative fib. ;; This works as expected (defn fibi [n] (loop [a 0, b 1, i n] (if (= i 0) a (recur b (+ a b) (dec i) ;; (count (str (fibi 10))) ;; -- 20899 ;; my attempt to define a lazy fib sequence. ;; working? not so much. (def fibl ((fn h [a b] (lazy-seq (cons a (h b (+ a b) 0 1)) ;; (count (str (last (take 10 fibl ;; -- java.lang.OutOfMemoryError: Java heap space --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Would people be interested in extending test-is with random tests?
I recently wrote a test framework for Scheme, initially similar to what test-is provides; recently, it has been extended to add random checks akin to Haskell's QuickCheck. The syntax is very similar (I have not bothered defining a 'deftest' form, but that is trivial): (define a-test (test a-test (+ 2 2) 4)) == (deftest a-test (is (+ 2 2) 4)) The property syntax, inspired by the Fact library announced here, is as follows: (define a-property (property add-commutes ([x randint] [y randint]) (= (+ x y) (+ y x which expands to a normal test, the body of which is a doseq such that x and y both iterate over a sequence of random integers The announcement on comp-lang-scheme is here: http://groups.google.com/group/comp.lang.scheme/browse_thread/thread/b917ffc0d2f34167/7f937544321e93c2#7f937544321e93c2 I just filled out the contributor's agreement (I just need to mail it), so if people are interested I can port the property part to Clojure and file a request at clojure-contrib. Regards, -- miʃel salim • http://hircus.jaiku.com/ IUCS • msa...@cs.indiana.edu Fedora • sali...@fedoraproject.org MacPorts • hir...@macports.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com 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
On Mon, Feb 23, 2009 at 3:52 PM, Perry Trolard trol...@gmail.com wrote: +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? The only reason I could see for using both :as and something :only is to bring certain vars from that namespace into the current one AND refer to that namespace by a shortname so you can access other parts of it. That can in fact happen sometimes but in those cases my recommendation would be to use to :use statements :use foo.bar :only [eggs, spam] :use foo.bar :as fb -- Cosmin Stejerean http://offbytwo.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 -~--~~~~--~~--~--~---
environment when calling clojure from Java
I'm new to clojure, and I'm trying to figure out how to integrate it into a somewhat large Java codebase. At a particular point the the program's execution, I'd like to spin up a thread with a swank server on it, but the following code doesn't seem to work. Can I get a pointer from the experienced hands as to what I'm doing wrong, or where to look for more clues? RT.loadResourceScript(swank/loader.clj); Var swank = RT.var(swank.loader, init); Object result = swank.invoke(); RT.loadResourceScript(swank/swank.clj); // main.legacy_repl (null); // A swank = RT.var(swank.swank, start-server); result = swank.invoke(/dev/ null); // B Line B throws java.lang.IllegalStateException: Var clojure.core/*3 is unbound. If I uncomment line A, I get a repl at which I can immediately do (swank.swank/start-server /dev/null) and get a running swank. I'm stumped as to why that var can be resolved in one situation but not the other. Do I need to do additional things to set up the full clojure environment before that invocation? Thanks, Thom --~--~-~--~~~---~--~~ 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: transactions and retries
On Feb 23, 2009, at 4:47 PM, Mark Volkmann wrote: On Mon, Feb 23, 2009 at 3:19 PM, Rich Hickey richhic...@gmail.com wrote On Feb 23, 2009, at 3:44 PM, Mark Volkmann wrote: On Mon, Feb 23, 2009 at 2:31 PM, Dan redalas...@gmail.com wrote: If I understand correctly, when there is an attempt to modify a Ref that has been modified in another thread since the current transaction began then the current transaction will retry immediately. Isn't it true that it has no chance of completing until the transaction that changed that Ref either commits or rolls back? If that is true, wouldn't it make sense to make the retry wait until that other transaction is finished? Maybe the point of retrying immediately is that it can at least get through some of its work (the part before it tries to change the Ref in question) before it has to check on that other transaction again. Until there is a commit, no one but the transaction knows that those refs are meant to hold new values. Ah ... I didn't know that. I did know that the new value wasn't visible outside the uncommitted transaction, but I thought other transactions were aware that some other transaction was changing it. Thanks for explaining that! When your transaction notices something is wrong and retries, the other transaction will *always* be finished. Which of course doesn't mean another transaction might not prevent it to finish again. This stuff is not right. You really shouldn't be concerned about the details of what happens when *inside* a transaction. The guarantees of http://clojure.org/ refs are met, but the exact flow can get complex - there is blocking, deadlock avoidance and conflict resolution, aging and barging etc. I frequently see these this happens then that happens imaginings about what happens inside transactions. Nothing other than what is documented is guaranteed, and those guarantees are about what a transaction sees, and what its effects are on commit, not the order of operations inside a transaction. If you're not doing side effects in transactions, you shouldn't care, and you shouldn't be doing side effects in transactions. Without getting into the implementation details, is there anything wrong with this statement? While in a transaction, if an attempt is made to modify a Ref that has been modified in another transaction that has committed since the current transaction started, the current transaction discards all its in-transaction Ref changes and retries by returning to the beginning of the dosync body. -- The answer is here: http://clojure.org/refs should a transaction have a conflict while running, it is automatically retried and 3. No changes will have been made by any other transactions to any Refs that have been ref-set/altered/ensured by this transaction. 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: Would people be interested in extending test-is with random tests?
I'm definitely interested. There is Fact that does this already as well as ClojureCheck (http://bitbucket.org/kotarak/clojurecheck/ overview/). I think you should try to contact James and Meikel and see if it would be a good idea to join forces. I don't mind multiple libraries that do the same task, but if it's possible to collaborate, that's ever better! Good luck! On Feb 23, 5:47 pm, Michel Salim michel.syl...@gmail.com wrote: I recently wrote a test framework for Scheme, initially similar to what test-is provides; recently, it has been extended to add random checks akin to Haskell's QuickCheck. The syntax is very similar (I have not bothered defining a 'deftest' form, but that is trivial): (define a-test (test a-test (+ 2 2) 4)) == (deftest a-test (is (+ 2 2) 4)) The property syntax, inspired by the Fact library announced here, is as follows: (define a-property (property add-commutes ([x randint] [y randint]) (= (+ x y) (+ y x which expands to a normal test, the body of which is a doseq such that x and y both iterate over a sequence of random integers The announcement on comp-lang-scheme is here:http://groups.google.com/group/comp.lang.scheme/browse_thread/thread/... I just filled out the contributor's agreement (I just need to mail it), so if people are interested I can port the property part to Clojure and file a request at clojure-contrib. Regards, -- miʃel salim • http://hircus.jaiku.com/ IUCS • msa...@cs.indiana.edu Fedora • sali...@fedoraproject.org MacPorts • hir...@macports.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com 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: Directed Graphs for Contrib
Jeffrey Straszheim wrote: As part of my Datalog work I'm putting together some directed graph algorithms, mostly things like finding strongly connected components, and building dependency stratifications (think topological sort but with the results groups in tiers of non-interdependent nodes). Anyhow, I'm thinking this stuff will be usefull outside of Datalog, and am wondering if I should just add it to contrib as a stand-alone library? That would be great. Especially if the algorithms can operate over some kind of generalized interface, so the algorithms can run over different graph implementations. I'm writing a semi-structured storage library on top of the neo4j graph database, and it would be great if I could analyze properties like connectedness, degree distribution, etc. I'm writing a graph query engine too, so it would also be cool if it could run over the in-memory graphs from your library. -Jeff --~--~-~--~~~---~--~~ 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: Maven/Continous Integration
I've added a patch for clojure-contrib so that the clojure-contrib module can build post-checkin, and nightly. I'd really like to see it taken, so I can set up continuous integration on tapestry.formos.com. Basically, we'll be able to have clojure-contrib build after any change to clojure-contrib, or to clojure-lang. That's great for spotting problems with tests and such as soon as they occur. -- Howard M. Lewis Ship Creator Apache Tapestry and Apache HiveMind --~--~-~--~~~---~--~~ 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: Directed Graphs for Contrib
Well, right now I'm just handling directed graphs, and basically treating nodes as integer indexes, with a simple formula from index to adjacency list of nodes. I'm not opposed to a more elaborate implementation. Patch welcome :) On Mon, Feb 23, 2009 at 7:33 PM, Jeff Rose ros...@gmail.com wrote: Jeffrey Straszheim wrote: As part of my Datalog work I'm putting together some directed graph algorithms, mostly things like finding strongly connected components, and building dependency stratifications (think topological sort but with the results groups in tiers of non-interdependent nodes). Anyhow, I'm thinking this stuff will be usefull outside of Datalog, and am wondering if I should just add it to contrib as a stand-alone library? That would be great. Especially if the algorithms can operate over some kind of generalized interface, so the algorithms can run over different graph implementations. I'm writing a semi-structured storage library on top of the neo4j graph database, and it would be great if I could analyze properties like connectedness, degree distribution, etc. I'm writing a graph query engine too, so it would also be cool if it could run over the in-memory graphs from your library. -Jeff --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Operating on multidimensional primitive arrays without reflection?
I'm trying to call some third-party code that expects a two- dimensional double array, and I can't figure out how to create and fill this in Clojure without a huge perf hit (which profiling shows to be coming from reflection): user (time (let [arr (make-array Double/TYPE 1)] (dotimes [_ 10] (aset-double arr 0 0.0 Elapsed time: 28.408 msecs nil user (time (let [arr (make-array Double/TYPE 1 1)] (dotimes [_ 10] (aset-double arr 0 0 0.0 Elapsed time: 3634.136 msecs nil I've tried adding type hints like #^[[D to no avail. What am I missing here? BTW, I'm still on the pre-lazy SVN, waiting for the dust to settle. 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 -~--~~~~--~~--~--~---
Re: Would people be interested in extending test-is with random tests?
Hi Michel, I find that when I want to use randomness in tests, I just create a random value and use it. I've never felt a compelling need for special test-related syntax for random values. The property syntax is shorter, but I tend to think it's only useful in testing very mathematical code where you can assert non-trivial properties that always hold. That's not to say there isn't a place for this in contrib. I'd be happy to have this available as an extension to test-is, but I'd prefer to have it in its own namespace so that test-is doesn't grow too much. -Stuart Sierra On Feb 23, 5:47 pm, Michel Salim michel.syl...@gmail.com wrote: I recently wrote a test framework for Scheme, initially similar to what test-is provides; recently, it has been extended to add random checks akin to Haskell's QuickCheck. The syntax is very similar (I have not bothered defining a 'deftest' form, but that is trivial): (define a-test (test a-test (+ 2 2) 4)) == (deftest a-test (is (+ 2 2) 4)) The property syntax, inspired by the Fact library announced here, is as follows: (define a-property (property add-commutes ([x randint] [y randint]) (= (+ x y) (+ y x which expands to a normal test, the body of which is a doseq such that x and y both iterate over a sequence of random integers The announcement on comp-lang-scheme is here:http://groups.google.com/group/comp.lang.scheme/browse_thread/thread/... I just filled out the contributor's agreement (I just need to mail it), so if people are interested I can port the property part to Clojure and file a request at clojure-contrib. Regards, -- miʃel salim • http://hircus.jaiku.com/ IUCS • msa...@cs.indiana.edu Fedora • sali...@fedoraproject.org MacPorts • hir...@macports.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com 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: Operating on multidimensional primitive arrays without reflection?
(time (let [arr (make-array Float/TYPE 1 1)] (dotimes [_ 10] (let [#^floats sub-arr (aget arr 0)] (aset-float sub-arr 0 0.0) Seems to work? Looks an eligible candidate for a macro. On Mon, Feb 23, 2009 at 9:04 PM, Jason Wolfe jawo...@berkeley.edu wrote: I'm trying to call some third-party code that expects a two- dimensional double array, and I can't figure out how to create and fill this in Clojure without a huge perf hit (which profiling shows to be coming from reflection): user (time (let [arr (make-array Double/TYPE 1)] (dotimes [_ 10] (aset-double arr 0 0.0 Elapsed time: 28.408 msecs nil user (time (let [arr (make-array Double/TYPE 1 1)] (dotimes [_ 10] (aset-double arr 0 0 0.0 Elapsed time: 3634.136 msecs nil I've tried adding type hints like #^[[D to no avail. What am I missing here? BTW, I'm still on the pre-lazy SVN, waiting for the dust to settle. 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 -~--~~~~--~~--~--~---
Re: Clojure Slime, how to jump to a def/defn?
David Nolen on 2009-02-23 16:58:40 -0500: Is this supported yet? M-. is supposed to handle this, but I get an error when I try. It works for me with Clojure sources (for example, M-. on rest), even if they're in jars, but not with applications I've compiled through load-file, slime-compile-defun, or slime-compile-region. I think I remember this working a while ago. The backtrace I get is very reproducable: (:emacs-rex (swank:find-definitions-for-emacs bar) foo :repl-thread 19) (:return (:abort) 19) (:debug 2 1 (java.lang.StringIndexOutOfBoundsException: String index out of range: -1 (NO_SOURCE_FILE:0) [Thrown class clojure.lang.Compiler$CompilerException] nil) ((ABORT Return to SLIME's top level.) (CAUSE Throw cause of this exception)) ((0 clojure.lang.Compiler.eval(Compiler.java:4235) (:restartable nil)) (1 clojure.core$eval__3894.invoke(core.clj:1711) (:restartable nil)) (2 swank.core$eval_in_emacs_package__275.invoke(core.clj:55) (:restartable nil)) (3 swank.core$eval_for_emacs__350.invoke(core.clj:123) (:restartable nil)) (4 clojure.lang.Var.invoke(Var.java:348) (:restartable nil)) (5 clojure.lang.AFn.applyToHelper(AFn.java:179) (:restartable nil)) (6 clojure.lang.Var.applyTo(Var.java:457) (:restartable nil)) (7 clojure.core$apply__3162.doInvoke(core.clj:408) (:restartable nil)) (8 clojure.lang.RestFn.invoke(RestFn.java:428) (:restartable nil)) (9 swank.core$eval_from_control__278.invoke(core.clj:62) (:restartable nil)) (10 swank.core$eval_loop__281.invoke(core.clj:67) (:restartable nil)) (11 swank.core$spawn_repl_thread__409$fn__438$fn__440.invoke(core.clj:168) (:restartable nil)) (12 clojure.lang.AFn.applyToHelper(AFn.java:171) (:restartable nil)) (13 clojure.lang.AFn.applyTo(AFn.java:164) (:restartable nil)) (14 clojure.core$apply__3162.doInvoke(core.clj:408) (:restartable nil)) (15 clojure.lang.RestFn.invoke(RestFn.java:428) (:restartable nil)) (16 swank.core$spawn_repl_thread__409$fn__438.doInvoke(core.clj:165) (:restartable nil)) (17 clojure.lang.RestFn.invoke(RestFn.java:402) (:restartable nil)) (18 clojure.lang.AFn.run(AFn.java:37) (:restartable nil)) (19 java.lang.Thread.run(Thread.java:636) (:restartable nil))) (19)) (:emacs-rex (swank:throw-to-toplevel) nil 2 20) (:debug-activate 2 1 true) (:return (:abort) 20) (:debug-return 2 1 nil) --~--~-~--~~~---~--~~ 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: Operating on multidimensional primitive arrays without reflection?
Sweet, thanks! I forgot that you could extract sub-arrays like that in Java. Maybe aset-* could be changed to incorporate this trick? -Jason On Feb 23, 2009, at 6:22 PM, David Nolen wrote: (time (let [arr (make-array Float/TYPE 1 1)] (dotimes [_ 10] (let [#^floats sub-arr (aget arr 0)] (aset-float sub-arr 0 0.0) Seems to work? Looks an eligible candidate for a macro. On Mon, Feb 23, 2009 at 9:04 PM, Jason Wolfe jawo...@berkeley.edu wrote: I'm trying to call some third-party code that expects a two- dimensional double array, and I can't figure out how to create and fill this in Clojure without a huge perf hit (which profiling shows to be coming from reflection): user (time (let [arr (make-array Double/TYPE 1)] (dotimes [_ 10] (aset-double arr 0 0.0 Elapsed time: 28.408 msecs nil user (time (let [arr (make-array Double/TYPE 1 1)] (dotimes [_ 10] (aset-double arr 0 0 0.0 Elapsed time: 3634.136 msecs nil I've tried adding type hints like #^[[D to no avail. What am I missing here? BTW, I'm still on the pre-lazy SVN, waiting for the dust to settle. 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 -~--~~~~--~~--~--~---
Re: challenge: best fibo implementation under the new laziness?
The speed of the JVM's big ints, and therefore Clojure's, doesn't seem to be competitive. On Mon, Feb 23, 2009 at 5:46 PM, Raffael Cavallaro raffaelcavall...@gmail.com wrote: On Feb 23, 2:51 pm, Stephen C. Gilardi squee...@mac.com wrote: The fibs implementation in clojure.contrib.lazy-seqs is not a function that returns fib(n) given n. I think defining a fib(n) function somewhere in contrib or core that operates as efficiently as we can manage would be a good idea. There was a thread on comp.lang.lisp a while ago where a number of people went back and forth trying to come up withe the fastest fib(n) algorithm (again, *not* returning a sequence, but just the nth fib given n). Here is the winner of that informal competition translated to clojure: (defn fib ([n] (fib n 1)) ([n b] (if (zero? b) ;calculate lucas numbers (cond (zero? n) 2 (= n 1) 1 :otherwise (if (even? n) (let [ k (/ n 2) l (fib k 0)] (+ (* l l) (if (even? k) -2 2))) (let [ k (- n 1) l (fib k 0) f (fib k 1)] (/ (+ (* 5 f) l) 2 (cond;calculate fibonacci numbers (zero? n) 0 (= n 1) 1 :otherwise (if (even? n) (let [ k (/ n 2) l (fib k 0) f (fib k 1)] (* f l)) (let [ k (- n 1) l (fib k 0) f (fib k 1)] (/ (+ f l) 2))) btw, the relatively naive algorithm: (defn fib-naive [n] (first (nth (iterate (fn [[a b]] [b (+ a b)]) [0 1]) n))) takes over 85 seconds, or more than 40 times as long as the lucas number based algorithm at top to compute the one millionth fibonacci number. The simple loop version: (defn fib-naive2 [n] (loop [a 0 b 1 counter 0] (if (= counter n) a (recur b (+ a b) (inc counter) fares exactly the same as one might expect. for comparison, here are some timings under different lisps on the same machine. All timings are after several runs to warm up caches and, in the case of clojure, hotspot optimizations. Time to calculate the one millionth fibonacci number using the lucas number based algorithm at top: clojure: 2 seconds ccl: 0.5 seconds lispworks: 1.7 seconds mzscheme: 0.15 seconds sbcl: 0.8 seconds larceny: 13 seconds ecl: 0.04 seconds as you can see, clojure is competitive with other lisps/schemes, faster than some, slower than others. this is really just a benchmark of the bignum package used by the lisp implementation. I think ecl uses GMP which is quite fast. btw, I tried adding type annotations to the clojure version but it didn't seem to make much difference. --~--~-~--~~~---~--~~ 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 Slime, how to jump to a def/defn?
You're right, works perfectly on clojure sources, but not the instances you've described. It would be great if this would work again. I don't understand swank/slime well enough to try it myself. On Mon, Feb 23, 2009 at 9:23 PM, Alec Berryman a...@thened.net wrote: David Nolen on 2009-02-23 16:58:40 -0500: Is this supported yet? M-. is supposed to handle this, but I get an error when I try. It works for me with Clojure sources (for example, M-. on rest), even if they're in jars, but not with applications I've compiled through load-file, slime-compile-defun, or slime-compile-region. I think I remember this working a while ago. The backtrace I get is very reproducable: (:emacs-rex (swank:find-definitions-for-emacs bar) foo :repl-thread 19) (:return (:abort) 19) (:debug 2 1 (java.lang.StringIndexOutOfBoundsException: String index out of range: -1 (NO_SOURCE_FILE:0) [Thrown class clojure.lang.Compiler$CompilerException] nil) ((ABORT Return to SLIME's top level.) (CAUSE Throw cause of this exception)) ((0 clojure.lang.Compiler.eval(Compiler.java:4235) (:restartable nil)) (1 clojure.core$eval__3894.invoke(core.clj:1711) (:restartable nil)) (2 swank.core$eval_in_emacs_package__275.invoke(core.clj:55) (:restartable nil)) (3 swank.core$eval_for_emacs__350.invoke(core.clj:123) (:restartable nil)) (4 clojure.lang.Var.invoke(Var.java:348) (:restartable nil)) (5 clojure.lang.AFn.applyToHelper(AFn.java:179) (:restartable nil)) (6 clojure.lang.Var.applyTo(Var.java:457) (:restartable nil)) (7 clojure.core$apply__3162.doInvoke(core.clj:408) (:restartable nil)) (8 clojure.lang.RestFn.invoke(RestFn.java:428) (:restartable nil)) (9 swank.core$eval_from_control__278.invoke(core.clj:62) (:restartable nil)) (10 swank.core$eval_loop__281.invoke(core.clj:67) (:restartable nil)) (11 swank.core$spawn_repl_thread__409$fn__438$fn__440.invoke(core.clj:168) (:restartable nil)) (12 clojure.lang.AFn.applyToHelper(AFn.java:171) (:restartable nil)) (13 clojure.lang.AFn.applyTo(AFn.java:164) (:restartable nil)) (14 clojure.core$apply__3162.doInvoke(core.clj:408) (:restartable nil)) (15 clojure.lang.RestFn.invoke(RestFn.java:428) (:restartable nil)) (16 swank.core$spawn_repl_thread__409$fn__438.doInvoke(core.clj:165) (:restartable nil)) (17 clojure.lang.RestFn.invoke(RestFn.java:402) (:restartable nil)) (18 clojure.lang.AFn.run(AFn.java:37) (:restartable nil)) (19 java.lang.Thread.run(Thread.java:636) (:restartable nil))) (19)) (:emacs-rex (swank:throw-to-toplevel) nil 2 20) (:debug-activate 2 1 true) (:return (:abort) 20) (:debug-return 2 1 nil) --~--~-~--~~~---~--~~ 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: Directed Graphs for Contrib
On Feb 23, 6:38 pm, Jeffrey Straszheim straszheimjeff...@gmail.com
wrote:
Well, right now I'm just handling directed graphs, and basically treating
nodes as integer indexes, with a simple formula from index to adjacency list
of nodes.
I would actually like to see an implementation that more closely
resembles the mathematical representation of graphs:
A graph is V, E, where V is a set of vertices and E is a set of
edges v1, v2.
It's really easy to do with maps and sets:
{:V #{1 2 3 4 5} :E #{{:a 1 :b 2} . . . .
It is less efficient than yours, but let's not optimize too soon.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Clojure group.
To post to this group, send email to clojure@googlegroups.com
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: Directed Graphs for Contrib
It would be easy to convert from your form to adjacency lists, so if you
want it write a converter :) I think we should keep the algorithms
*basically* efficient. I don't see that as premature optimization at all.
On Mon, Feb 23, 2009 at 9:37 PM, Eric ericwnorm...@gmail.com wrote:
On Feb 23, 6:38 pm, Jeffrey Straszheim straszheimjeff...@gmail.com
wrote:
Well, right now I'm just handling directed graphs, and basically treating
nodes as integer indexes, with a simple formula from index to adjacency
list
of nodes.
I would actually like to see an implementation that more closely
resembles the mathematical representation of graphs:
A graph is V, E, where V is a set of vertices and E is a set of
edges v1, v2.
It's really easy to do with maps and sets:
{:V #{1 2 3 4 5} :E #{{:a 1 :b 2} . . . .
It is less efficient than yours, but let's not optimize too soon.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Clojure group.
To post to this group, send email to clojure@googlegroups.com
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: Would people be interested in extending test-is with random tests?
Hi James, Stuart: I started Quiche after taking a look at Fact, actually; the difference between what I'm proposing and Fact is that the latter is a standalone test framework, whereas the random-testing part of Quiche (property) and Fact (fact) could, IMHO, be built on top of test-is. I've not seen ClojureCheck before -- thanks for the pointer! Will definitely contact both authors and see if we can get a common QuickCheck port into contrib. And yes, a separate namespace is most likely a good idea. Regards, -- Michel Salim On Feb 23, 7:26 pm, Vincent Foley vfo...@gmail.com wrote: I'm definitely interested. There is Fact that does this already as well as ClojureCheck (http://bitbucket.org/kotarak/clojurecheck/ overview/). I think you should try to contact James and Meikel and see if it would be a good idea to join forces. I don't mind multiple libraries that do the same task, but if it's possible to collaborate, that's ever better! Good luck! On Feb 23, 5:47 pm, Michel Salim michel.syl...@gmail.com wrote: I recently wrote a test framework for Scheme, initially similar to what test-is provides; recently, it has been extended to add random checks akin to Haskell's QuickCheck. The syntax is very similar (I have not bothered defining a 'deftest' form, but that is trivial): (define a-test (test a-test (+ 2 2) 4)) == (deftest a-test (is (+ 2 2) 4)) The property syntax, inspired by the Fact library announced here, is as follows: (define a-property (property add-commutes ([x randint] [y randint]) (= (+ x y) (+ y x which expands to a normal test, the body of which is a doseq such that x and y both iterate over a sequence of random integers The announcement on comp-lang-scheme is here:http://groups.google.com/group/comp.lang.scheme/browse_thread/thread/... I just filled out the contributor's agreement (I just need to mail it), so if people are interested I can port the property part to Clojure and file a request at clojure-contrib. Regards, -- miʃel salim • http://hircus.jaiku.com/ IUCS • msa...@cs.indiana.edu Fedora • sali...@fedoraproject.org MacPorts • hir...@macports.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com 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: challenge: best fibo implementation under the new laziness?
On Feb 23, 9:31 pm, Jeffrey Straszheim straszheimjeff...@gmail.com wrote: The speed of the JVM's big ints, and therefore Clojure's, doesn't seem to be competitive. Clearly the JVM's big ints doesn't compare favorably with GMP. On the other hand, Clojure falls near the middle of the range of the various lisps and schemes. It's about as fast as LispWorks 32-bit for example. --~--~-~--~~~---~--~~ 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: challenge: best fibo implementation under the new laziness?
On Mon, Feb 23, 2009 at 10:26 PM, Raffael Cavallaro raffaelcavall...@gmail.com wrote: On Feb 23, 9:31 pm, Jeffrey Straszheim straszheimjeff...@gmail.com wrote: The speed of the JVM's big ints, and therefore Clojure's, doesn't seem to be competitive. Clearly the JVM's big ints doesn't compare favorably with GMP. On the other hand, Clojure falls near the middle of the range of the various lisps and schemes. It's about as fast as LispWorks 32-bit for example. Too bad GMP is LGPLv3+, while Java is GPLv2 only, so we'll not see Java using GMP in the foreseeable foture. Kaffe's JVM uses GMP, though. If Clojure runs on it, it'd be interesting to see what sort of numbers it produces. I've not seen a decent GMP wrapper for Java -- does anyone know of any such implementation? Regards, -- miʃel salim • http://hircus.jaiku.com/ IUCS • msa...@cs.indiana.edu Fedora • sali...@fedoraproject.org MacPorts • hir...@macports.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com 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: Where to put fixed-point?
On Mon, Feb 23, 2009 at 11:06 PM, Jeffrey Straszheim straszheimjeff...@gmail.com wrote: For my graph code in contrib, I've created a function fixed-point. It is, I believe, generally useful. However, it is not properly a graph function per se, and might belong elsewhere in the library. Does anyone have a better suggestion of a file in contrib to put a fixed-point function? Perhaps clojure.contrib.math, or some subspace thereof? Regards, -- miʃel salim • http://hircus.jaiku.com/ IUCS • msa...@cs.indiana.edu Fedora • sali...@fedoraproject.org MacPorts • hir...@macports.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com 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: test-is integration via SLIME
On Wed, Feb 18, 2009 at 7:07 PM, Phil Hagelberg p...@hagelb.org wrote: I've been cooking up a little tool to help with running tests using test-is. It's a little cumbersome to need to switch back and forth between the test buffer and the repl to see the test results, so I've created an Emacs mode that actually overlays the results on top of the test buffer itself. I've attached a screenshot of it in action. Basically it colors failing is forms in red and erroring forms in brown. When you put the point in a failing is form and press C-c ', it will show the failure message in the minibuffer. That would be really neat! I'm having a bit of trouble setting it up, though: - I added the clojure-test initialization code to ~/.emacs right after setting up clojure-mode - When loading a .clj file in Emacs, it automatically triggers Slime - However, the file is not actually loaded; I had to C-c C-l - C-c C-' is not bound; if I (run-tests 'clojure-mode.test-is), the tests run but nothing appears in the editor window Any idea what could be wrong? Here's the clojure-mode / clojure-test-mode part of ~/.emacs (autoload 'clojure-mode clojure-mode A major mode for Clojure t) (add-to-list 'auto-mode-alist '(\\.clj$ . clojure-mode)) (autoload 'clojure-test-mode clojure-test-mode Clojure test mode t) (add-hook 'clojure-mode-hook (lambda () (save-excursion (goto-char (point-min)) (if (or (search-forward (deftest nil t) (search-forward (with-test nil t)) (clojure-test-mode t) Thanks, -- miʃel salim • http://hircus.jaiku.com/ IUCS • msa...@cs.indiana.edu Fedora • sali...@fedoraproject.org MacPorts • hir...@macports.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com 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: challenge: best fibo implementation under the new laziness?
Hello, What about giving back 'lazy-cons (or lcons as a shortcut), with the optional possibility to give the cons an internal name ? This could allow for self-recursive definition, such as this one for a fibonacci generator function as : user=(defn fib-fn [] (lcons [fib] 1 (lcons 1 (map + fib (rest fib) #'user/fib-fn user= (take 10 (fib-fn)) (1 1 2 3 5 8 13 21 34 55) If you think it's interesting, see the detailed explanation below, and find the patch to play with it in google groups files section : http://groups.google.com/group/clojure/web/lazy-cons.patch I wanted to try a definition closer to the one I had in my Haskell book. This definition needs the ability for the lazy-seq to reference itself. For example, it can in straight clojure be written as : (def fib (lazy-seq (cons 1 (lazy-seq (cons 1 (map + fib (rest fib))) But of course, the above version, while interesting, leaks memory since the lazy seq is bound to a global var. So I've played with clojure core to allow the creation of lazy-sequences that can refer to themselves inside their body, and get rid of the memory leak problem. I've called this 'named-lazy-seq : (named-lazy-seq [a-name] ... ) And since the pattern (lazy-seq (cons ...)) may well be a common one, I've also recreated 'lazy-cons (or lcons for brevity) that is just a macro calling either 'lazy-seq or 'named-lazy-seq depending on its arity : (lazy-cons a-first-elem a-tail) = (lazy-seq (cons a-first-elem a-tail)) or (lazy-cons [a-name] a-first-elem a-tail) = (named-lazy-seq [a-name] (cons a-first-elem a-tail)) With these additions, one can write the fibonacci lazy sequence as : (lcons [fib] 1 (lcons 1 (map + fib (rest fib and, of course, a fibonacci lazy sequence generator : (defn fib-fn [] (lcons [fib] 1 (lcons 1 (map + fib (rest fib) HTH, -- Laurent 2009/2/23 Stuart Halloway stuart.hallo...@gmail.com Beautiful-thanks. - Afficher le texte des messages précédents - Using a good old sequence of vectors: (defn fibo [] (map first (iterate (fn [[a b]] [b (+ a b)]) [0 1]))) Christophe Stuart Halloway a écrit : I have updated the sample source from the book ( http://tinyurl.com/clojure-samples ) to the new laziness. Along the way, I replaced the lazy-cons based implementation of the fibonacci numbers with this: (defn fibo ([] (concat [0 1] (fibo 0 1))) ([a b] (let [n (+ a b)] (lazy-seq (cons n (fibo b n)) Is there a better/more idiomatic approach, without resorting to code in clojure-contrib? Test your code against the following expression to flush out stack and heap overflows. (rem (nth (fibo) 100) 1000) - 875 Also, the current 'fibs' implementation in clojure.contrib.seq fails the test above, because it holds the entire sequence as it goes. We should replace it with whatever the community comes up with on this thread. Cheers, Stu -- 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: newbie troubles with new lazy-seq hotness (OutOfMemory)
On Feb 23, 11:46 pm, Jeffrey Straszheim straszheimjeff...@gmail.com wrote: Have you figured this out yet? On Mon, Feb 23, 2009 at 4:58 PM, Jeffrey Straszheim straszheimjeff...@gmail.com wrote: The identifier fibl is holding on to the head of the sequence. Yes, this works: (defn fibl [] ((fn h [a b] (lazy-seq (cons a (h b (+ a b) 0 1)) ;; (count (str (last (take 10 (fibl) ;; -- 20899 by making fibl a function, the head of the sequence is no longer hanging off some global variable, never to be garbage collected. I think I now understand why it's holding on to the head. lazy-seq evaluates its body only once and then caches the result, which would be a cons with a number in the car and a lazy-seq in the cdr, which in turn... tada! full heap! macroexpand-1 gave me the clue I needed: = (macroexpand-1 '(lazy-seq (cons a (h b (+ a b) (new clojure.lang.LazySeq (fn* [] (cons a (h b (+ a b) Thanks for the pointer in the right direction! // ben --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
