Re: FAQ
Some thoughts on really stupid things that have tripped me up: - How do I exit Clojure - srsly C-c - Whatsa JVM - does this mean Clojure is really just Java with parens? - Whatsa Classpath? this answer presents the *ALL* important opportunity to mention that *nix uses `:' to separate paths whereas windz uses `;' - How do I access Clojure documentation - e.g. where is `man Clojure' - Is a Clojure docstring the same as Javadoc? - Is Clojure stable? - Where's the Clojure manual? - What happened to setf? - Why are Clojure's docstring placements different than other lisps - Where do I make donations? - Why are Clojure's defun params passed in a [] vector? - Does Clojure do TCO? - Whatsa TCO? - How do I compile Clojure? OR Where's the Clojure Compiler? - How does Clojure's nil differ from other Lisps? - Clojure has a `cons' function and a `conj' function - whats the difference? - At what point do calls out to external Java interfaces limit/alter Clojures' internal handling of sequences How do I avoid interopearating with Java - e.g. when is Clojure all I need for task X When should I make use of external Java libraries - Whatsa Clojure Sequence - how does it corellate to language X - Whatsa Collection - how does it corellate to language X - Whatsa Map - how does it corellate to language X On Dec 19, 12:41 am, "Adrian Cuthbertson" wrote: > > Suggestions for entries welcome here. > > > > Rich > > Here's another that was a "gotcha" for me for an hour or two... > > Why after using map/reduce/for to change a java object does the object > remain unchanged? > > (defn initv1 [myseq] (let [v (java.util.Vector.)] (for [x myseq] > (.addElement v x)) v)) > (initv1 [1 2 3]) > ; => (java.util.Vector. []) > > ; or... > > (defn initv2 [myseq] (let [v (java.util.Vector.)] (map (fn [x] (.addElement > v x)) myseq) v)) > (initv2 [1 2 3]) > ; => (java.util.Vector. []) > > As map/reduce/for are lazy, the "let" construct does not actually "take" any > elements from the map/reduce/for. In this case, use doseq... > > (defn initv3 [myseq] (let [v (java.util.Vector.)] (doseq [x myseq] > (.addElement v x)) v)) > (initv3 [1 2 3]) > ; => (java.util.Vector. [1 2 3]) > > (Actually this happened in a more complex function, but the essence was that > a new java object was instantiated in a let and I'd used a map to call a > method on that object with all the items from a sequence. I could not > understand why the object remained unchanged afterwards until I simplified > it down to the above example). > > Regards, Adrian --~--~-~--~~~---~--~~ You 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: Preparing for Release 1.0 (was: Re: 20081217 Release)
> I would propose, that the files are hosted where ever > they are hosted now with suitable labels with which > Clojure version they work. This works out of the box > with the least amount of trouble. > > Meikel In contrast to the monolithic GG Code repo or C*AN or git/hg/bzr.*hubs I find that the Emacswiki (while by no means perfect) is the best model I have encountered for this sort thing because: a) it acommodates small libs that can easily be extended into ones working environment. b) it allows for user interaction in a temporally adhoc manner dissimilar from that of a maillist, IRC, static site, etc. c) it promotes community interaction d) it consolidates questions/answers regarding *particular* libs, tasks, data-models, environs, etc. e) it is independent of the core Emacs devels f) anyone can play at any level g) itsa wiki h) it doesn't require code be hosted on a particular server *NOTE* I am *not* suggesting that any approach toward this model need be in any way tied to Emacs. It's just that Emacs happens to be what prompted the Emacs Wiki - if there are other communities with a similar flavor I am simply unaware of them. --~--~-~--~~~---~--~~ You 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 -~--~~~~--~~--~--~---
A more useful assert macro
At the moment assert macro accepts only a single argument - a test. If the test fails (is false), an exception is thrown. But the only information available (until we have better introspection tools) is the test _expression_. This causes problems when working on many items that should satisfy an assertion, but the assertion expression is the same for all of them (like, when iterating through a sequence) - it is impossible to see for which items exactly the assertion fails. For this reason I think assert macro should accept another parameter - something to construct a meaningful assertion failure reason. A simplistic approach would be to just pass a string that has been constructed using str function. But this would involve too much unnecessary computation/consing since assertions are usually expected not to fail (in which case the failure message is not needed and should not be constructed). So my proposed (below) accepts a second parameter, which should be a form that results in a string. It could also accept variable number of parameters and implicitly call str on them, but that I think is a bad style. Comments welcome. And I hope some variation of it makes it to the clojure.core. (defmacro assert "Evaluates expr and throws an exception if it does not evaluate to logical true. message, if present, should be a an expression that evaluates to string describing the assertion failure." ([x] `(when-not ~x (throw (new Exception (str "Assert failed: " (pr-str '~x)) ([x message] `(let [message# (fn [] ~message)] (when-not ~x (throw (new Exception (str "Assert failed: " (message# -- Jānis Džeriņš --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Problems with "gen-and-load-class" (defn user-exception-test [] (try (throw (new user.UserException "msg: user exception was here!!")) (catch user.UserException e (prn "caught exception" e)) (fi
It would be nice if someone updated the wiki with a new example. I don't understand how the gen-class stuff is supposed to work. Why doesn't the following work? (gen-class :name MyException :extends [Exception]) (defn user-exception-test [] (try (throw (new MyException "msg: user exception was here!!")) (catch MyException e (prn "caught exception" e)) (finally (prn "finally clause invoked!!!" --~--~-~--~~~---~--~~ You 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: introduce (defn name attr-map? [params*] doc-string body) form.
On Fri, Dec 19, 2008 at 2:41 AM, Christian Vest Hansen wrote: > > All. > > I think it would be nice if the doc-string was allowed (in addition to > current behavior) to immediately follow the params vector in the > various defsomethings. > > To the best of my knowledge, such a change would be non-breaking because, > a) It should be implemented such that (defn foo [] "bar") is a > function that always returns the string "bar" - like it does today, > and > b) The "eggs" string following the params vector in (defn spam [] > "eggs" "pokemon") is completely harmless in current code. > > Even though this change would introduce yet-another-way-to-def-fn, I > think it is a good change because it allows be to keep my [params] on > the same line as my defn's and still have a thorough doc-string. And > in my humble opinion, I think it improves the readability of function > definitions when the defn, name and [params] are on the same line > regardless of how long the doc-string is. Where would it go when you have multiple parameter lists and bodies? (defn blah ([a] (do-something-with a)) ([a b] (do-something-with a b))) -- Michael Wood --~--~-~--~~~---~--~~ You 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 possible bug in are
On Thu, Dec 18, 2008 at 9:08 PM, Stuart Sierra wrote: > > On Dec 18, 6:05 pm, "Mark Volkmann" wrote: >> If I understand correctly, >> >> (are (< 1 2, 5 7)) >> >> is equivalent to >> >> (is (< 1 2)) >> (is (< 5 7)) > > Not exactly. The first argument to "are" is a template expression, > which is sort of like #(). The arguments to the template are symbols > named "_1", "_2", "_3", "_4", and so on. The remaining arguments of > "are" fill in the arguments to the template. So: > > (are (< _1 _2) 5 7 8 10) > ;=> expands to (do (is (< 5 7)) (is (< 8 10)) > > Make sense? This is roughly equivalent to > (map (fn [x y] (is (< x y))) [[5 7] [8 10]]) > but it happens at compile time. Thanks! I understand it now. There's still the issue though that if I use it incorrectly like this: (are < 1 2, 5 7) it hangs forever instead of giving me an error. -- 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: Suggestion: introduce (defn name attr-map? [params*] doc-string body) form.
On Fri, Dec 19, 2008 at 12:46 PM, Michael Wood wrote: > > Where would it go when you have multiple parameter lists and bodies? > > (defn blah ([a] (do-something-with a)) ([a b] (do-something-with a b))) That case should be unchanged, and work as it does today. > > -- > Michael Wood > > > > -- 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: A try on condp
On Thu, Dec 18, 2008 at 5:26 PM, Meikel Brandmeyer wrote: > Hi, > > I reworked my initial proposal according to the comments > of Rich. The syntax now looks as follows: > > (condp predicate expr > test-expr result-expr > test-expr :> result-expr What is ":>"? Is that just a keyword whose name is ">"? I think adding more characters with special meaning makes code harder to read, so I hope we don't add more of these. > ... > default-expr) > > A result-expr is chosen according to (predicate test-expr expr). > In the first form, result-expr is simply evaluated and the result > is returned. In the second form, result-expr is expected to > evaluate to a function. This function gets passed the return > value of the predicate call. Whatever the function returns > is returned by condp. > > If no test-expr leads to a success the default-expr is evaluated > and the result returned. If no default-expr is supplied an > exception is thrown. > > The patch is attached at the issue tracker. > http://code.google.com/p/clojure/issues/detail?id=6#c2 > > Comments appreciated. > > Sincerely > Meikel > > -- 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: A try on condp
Hi Mark, On 19 Dez., 13:12, "Mark Volkmann" wrote: > What is ":>"? Is that just a keyword whose name is ">"? It's exactly that: a keyword with the name ">". > I think adding more characters with special meaning > makes code harder to read, so I hope we don't add > more of these. It comes from (some) Scheme. There you can "pipe" the result of a test expression into the result expression using "=>". (cond (test-expr => result-expr)) result-expr should actually be a function, which is called with the result of the test-expr. If you don't need this, you don't have to use it. (condp instance? x String "some string")) is (more or less) equivalent to (cond (instance? String x) "some string")) Sincerely Meikel --~--~-~--~~~---~--~~ You 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 -~--~~~~--~~--~--~---
syntax philosophy
> If you don't need this, you don't have to use it. I feel very strongly that Clojure, and any programming language, should avoid using this rationale when adding support for new syntax. Just because a developer chooses not to use a particular feature doesn't mean they don't have to understand it. They will have to read the code that other developers write and those developers may use the feature. I have a strong dislike for the concept of TIMTOWTDI (There is more than one way to do it ... pronounced "tim toadie") that Perl and Ruby espouse. I think it's fine to have more than one way to do something IF each way has some unique characteristic such as performance in different scenarios, but not if each way is just a different syntax for the same functionality. Part of the success of Clojure (measured in adoption) will depend on how much effort is required to learn it. Anything extra that makes Clojure code more challenging to read and determine what the code does works against the goal of getting more developers to consider using Clojure. -- 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 -~--~~~~--~~--~--~---
groups-of
I'm learning Clojure by trying to implement some functions from Ruby core/stdlib/ActiveSupport's core_ext. The first one I wrote is groups-of (similar to ActiveSupport's in_groups_of): (defn groups-of "Returns coll in groups of x size, optionally padding any remaining slots with specified value" ([x coll] (loop [list coll result nil] (if (empty? list) result (recur (drop x list) (concat result [(take x list)]) ([x coll padding] (groups-of x (concat coll (replicate (rem (- x (rem (count coll) x)) x) padding) user=> (groups-of 2 [1 2 3 4]) ((1 2) (3 4)) user=> (groups-of 3 [1 2 3 4] "*") ((1 2 3) (4 "*" "*")) I've got a few questions: 1. Can the code above be improved ? I'm not sure if using concat is the best way to append to a collection. 2. If I wanted to extend the function to support executing a piece of code for each group would it be recommended to write a macro to support it (by passing an optional body for example) or rather use apply on the returned sequence ? How would an example macro look like ? 3. How to contribute to clojure-contrib ? 4. Is there a package retrieval/dependency tracking system for Clojure (sth. similar to Rubygems / asdf / apt-get etc.) or is someone working on such a system ? Thanks -- Karol Hosiawa --~--~-~--~~~---~--~~ You 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: FAQ
Not sure if the FAQ is the right place to put it, but I haven't seen any mention of this "gotcha" which could really trip some people up: http://w01fe.com/?p=32 Short version: hashing "immutable" Clojure collections that contain mutable Java objects can lead to confusing results. (Hi all, I'm new to Clojure and this is my first email here ... sorry if this has already been discussed elsewhere) -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: syntax philosophy
Hello Mark, On 19 Dez., 13:36, "Mark Volkmann" wrote: > > If you don't need this, you don't have to use it. Ok. That was a stupid statement. But at least it is not the rationale for including condp (in whatever form). > I feel very strongly that Clojure, and any programming language, > should avoid using this rationale when adding support for new syntax. > Just because a developer chooses not to use a particular feature > doesn't mean they don't have to understand it. They will have to read > the code that other developers write and those developers may use the > feature. Then we are in trouble anyway. The reason: macros. Any developer can basically do whatever he wants with macros. Just because something looks like normal clojure code, doesn't mean that it is. It could be a macro, controlling the evaluation of the arguments. So "adding support for new syntax" is basically happening every day. The question is whether this should go to clojure.core or not. That's a different story. In contrib there is fcase and cond-let. I used both in my code several times, now. So (at least for me) there is some practical interest to have an often used form available in core. My stupid statement above is not the rationale for including it. Sorry in case I offended you. Sincerely Meikel --~--~-~--~~~---~--~~ You 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: syntax philosophy
On Fri, Dec 19, 2008 at 6:52 AM, Meikel Brandmeyer wrote: > > Hello Mark, > > On 19 Dez., 13:36, "Mark Volkmann" wrote: >> > If you don't need this, you don't have to use it. > > Ok. That was a stupid statement. But at least it is > not the rationale for including condp (in whatever > form). I like the idea behind condp. I'm just not crazy about the ":>" part of it. >> I feel very strongly that Clojure, and any programming language, >> should avoid using this rationale when adding support for new syntax. >> Just because a developer chooses not to use a particular feature >> doesn't mean they don't have to understand it. They will have to read >> the code that other developers write and those developers may use the >> feature. > > Then we are in trouble anyway. The reason: macros. Any > developer can basically do whatever he wants with macros. > Just because something looks like normal clojure code, doesn't > mean that it is. It could be a macro, controlling the evaluation > of the arguments. So "adding support for new syntax" is > basically happening every day. I agree that we can't control that. We can control the set of macros that are a standard part of Clojure though. > The question is whether this should go to clojure.core or not. > That's a different story. In contrib there is fcase and cond-let. > I used both in my code several times, now. So (at least for > me) there is some practical interest to have an often used > form available in core. I agree that condp belongs in core. > My stupid statement above is not the rationale for including it. > > Sorry in case I offended you. No offense taken! I just wanted to express my thoughts on keeping the language as simple as possible. I suspect my views on this are in the minority. Most developers seem to love having TIMTOWDI. -- 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 -~--~~~~--~~--~--~---
IntelliJ Plugin now on Google Code
For those who are following or helping my efforts (thank you), the IntelliJ Clojure plugin code is now on GoogleCode. Enjoy! http://code.google.com/p/clojure-intellij-plugin/source/browse/#svn/trunk/src/org/clojure/intellij Please note that this code is nowhere near ready for use. Syntax coloring is barely working, but only if you scroll to the top of a file, and CLJ files have an icon. That it so far. After coloring is debugged, I will add folding, references, indenting, refactoring support and all the other goodies one expects from an IDE. However, I need help, especially with the REPL. Please email me if you want to join this project. Peter --~--~-~--~~~---~--~~ You 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: IntelliJ Plugin now on Google Code
Peter, Great news! On Friday 19 December 2008 05:36, Peter Wolf wrote: > For those who are following or helping my efforts (thank you), the > IntelliJ Clojure plugin code is now on GoogleCode. Enjoy! > > http://code.google.com/p/clojure-intellij-plugin/source/browse/#svn/t >runk/src/org/clojure/intellij At what point will it be available for installation via the IDEA plug-in manager? > ... > > Peter Randall Schulz --~--~-~--~~~---~--~~ You 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: groups-of
On Fri, Dec 19, 2008 at 1:02 PM, hosia...@gmail.com wrote: > > I'm learning Clojure by trying to implement some functions from Ruby > core/stdlib/ActiveSupport's core_ext. > > The first one I wrote is groups-of (similar to ActiveSupport's > in_groups_of): > > (defn groups-of > "Returns coll in groups of x size, optionally padding any remaining > slots with specified value" > ([x coll] > (loop [list coll result nil] > (if (empty? list) > result > (recur (drop x list) (concat result [(take x list)]) > ([x coll padding] > (groups-of x (concat coll (replicate (rem (- x (rem (count coll) > x)) x) padding) There is a function called partition in Clojure's core.clj that does this, except it does not pad, but rather discards any incomplete groups. It's recursive, though, so it runs out of heap on large sequences like (iterate inc 1). > user=> (groups-of 2 [1 2 3 4]) > ((1 2) (3 4)) (partition 2 [1 2 3 4]) => ((1 2) (3 4)) > user=> (groups-of 3 [1 2 3 4] "*") > ((1 2 3) (4 "*" "*")) (partition 3 [1 2 3 4]) => ((1 2 3)) > I've got a few questions: > > 1. Can the code above be improved ? I'm not sure if using concat is > the best way to append to a collection. > 2. If I wanted to extend the function to support executing a piece of > code for each group would it be recommended to write a macro to > support it (by passing an optional body for example) or rather use > apply on the returned sequence ? How would an example macro look > like ? > 3. How to contribute to clojure-contrib ? First you will need to send in a Contributor Agreement. http://clojure.org/contributing > 4. Is there a package retrieval/dependency tracking system for Clojure > (sth. similar to Rubygems / asdf / apt-get etc.) or is someone working > on such a system ? There is no such thing at the moment although it's been mentioned in the past. -- Michael Wood --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: A more useful assert macro
While we are talking about assert: I recently wanted for assert to return the value of the expression, so I could embed asserts inside a Fact test and get detailed reporting about what failed. I checked a few other functional languages and none of their asserts return a value either. This surprised me. Should assert return its value? If not, what should I name the function that works just like assert but returns its value? Stuart > At the moment assert macro accepts only a single argument - a test. If > the test fails (is false), an exception is thrown. But the only > information available (until we have better introspection tools) is > the test _expression_. This causes problems when working on many items > that should satisfy an assertion, but the assertion expression is the > same for all of them (like, when iterating through a sequence) - it is > impossible to see for which items exactly the assertion fails. > > For this reason I think assert macro should accept another parameter - > something to construct a meaningful assertion failure reason. A > simplistic approach would be to just pass a string that has been > constructed using str function. But this would involve too much > unnecessary computation/consing since assertions are usually expected > not to fail (in which case the failure message is not needed and > should not be constructed). So my proposed (below) accepts a second > parameter, which should be a form that results in a string. It could > also accept variable number of parameters and implicitly call str on > them, but that I think is a bad style. > > Comments welcome. And I hope some variation of it makes it to the > clojure.core. > > (defmacro assert > "Evaluates expr and throws an exception if it does not evaluate to > logical true. message, if present, should be a an expression that > evaluates to > string describing the assertion failure." > ([x] > `(when-not ~x >(throw (new Exception (str "Assert failed: " (pr-str '~x)) > ([x message] > `(let [message# (fn [] ~message)] >(when-not ~x > (throw (new Exception (str "Assert failed: > " (message# > > -- > Jānis Džeriņš > > --~--~-~--~~~---~--~~ You 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: IntelliJ Plugin now on Google Code
Hi Randall, I'd like to get it to the point where some set of features completely work before I release a plugin. I'd like to see at least coloring, parens matching and a REPL. For the moment you need to install the IntelliJ plugin development kit if you just want to try it. Of course, having done that, you could help me fix the bugs ;-) P Randall R Schulz wrote: > Peter, > > Great news! > > On Friday 19 December 2008 05:36, Peter Wolf wrote: > >> For those who are following or helping my efforts (thank you), the >> IntelliJ Clojure plugin code is now on GoogleCode. Enjoy! >> >> http://code.google.com/p/clojure-intellij-plugin/source/browse/#svn/t >> runk/src/org/clojure/intellij >> > > At what point will it be available for installation via the IDEA plug-in > manager? > > > >> ... >> >> Peter >> > > > Randall Schulz > > > > > --~--~-~--~~~---~--~~ You 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: groups-of
On Dec 19, 8:59 am, "Michael Wood" wrote: > On Fri, Dec 19, 2008 at 1:02 PM, hosia...@gmail.com > wrote: > > > I'm learning Clojure by trying to implement some functions from Ruby > > core/stdlib/ActiveSupport's core_ext. > > > The first one I wrote is groups-of (similar to ActiveSupport's > > in_groups_of): > > > (defn groups-of > > "Returns coll in groups of x size, optionally padding any remaining > > slots with specified value" > > ([x coll] > > (loop [list coll result nil] > > (if (empty? list) > > result > > (recur (drop x list) (concat result [(take x list)]) > > ([x coll padding] > > (groups-of x (concat coll (replicate (rem (- x (rem (count coll) > > x)) x) padding) > > There is a function called partition in Clojure's core.clj that does > this, except it does not pad, but rather discards any incomplete > groups. It's recursive, though, so it runs out of heap on large > sequences like (iterate inc 1). > That's not true - partition is lazy: ;with -Xmx128M (last (partition 2 (take 1 (iterate inc 1 -> ( 1) 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: groups-of
On Fri, Dec 19, 2008 at 4:32 PM, Rich Hickey wrote: > > On Dec 19, 8:59 am, "Michael Wood" wrote: >> On Fri, Dec 19, 2008 at 1:02 PM, hosia...@gmail.com >> wrote: >> >> > I'm learning Clojure by trying to implement some functions from Ruby >> > core/stdlib/ActiveSupport's core_ext. >> >> > The first one I wrote is groups-of (similar to ActiveSupport's >> > in_groups_of): >> >> > (defn groups-of >> > "Returns coll in groups of x size, optionally padding any remaining >> > slots with specified value" >> > ([x coll] >> > (loop [list coll result nil] >> > (if (empty? list) >> > result >> > (recur (drop x list) (concat result [(take x list)]) >> > ([x coll padding] >> > (groups-of x (concat coll (replicate (rem (- x (rem (count coll) >> > x)) x) padding) >> >> There is a function called partition in Clojure's core.clj that does >> this, except it does not pad, but rather discards any incomplete >> groups. It's recursive, though, so it runs out of heap on large >> sequences like (iterate inc 1). >> > > That's not true - partition is lazy: > > ;with -Xmx128M > > (last (partition 2 (take 1 (iterate inc 1 > -> ( 1) hmmm... if I do this: user=> (partition 2 1 (iterate inc 1)) (.printStackTrace *e) it ends like this: [...] 57) (587257 587258) (587258 587259) (587259 587260) (587260 587261) (587261 587262) (587262 587263) (587263 587264) (587264 587265) (587265 587266) (587266 587267) (587267 587268) (587268 587269) (587269 587270) (587270 587271) (587271 587272) (587272 587273) (587273 587274) user=> java.lang.OutOfMemoryError: Java heap space at clojure.lang.PersistentHashMap$BitmapIndexedNode.assoc(PersistentHashMap.java:419) at clojure.lang.PersistentHashMap.assoc(PersistentHashMap.java:139) at clojure.lang.PersistentHashMap.assoc(PersistentHashMap.java:52) at clojure.lang.Var.pushThreadBindings(Var.java:264) at clojure.core$print_sequential__4821.invoke(core_print.clj:37) at clojure.core$fn__4889.invoke(core_print.clj:133) at clojure.lang.MultiFn.invoke(MultiFn.java:152) at clojure.core$pr_on__3671.invoke(core.clj:1742) at clojure.core$print_sequential__4821.invoke(core_print.clj:54) at clojure.core$fn__4889.invoke(core_print.clj:133) at clojure.lang.MultiFn.invoke(MultiFn.java:152) at clojure.core$pr_on__3671.invoke(core.clj:1742) at clojure.lang.Var.invoke(Var.java:331) at clojure.lang.RT.print(RT.java:1200) at clojure.lang.Repl.main(Repl.java:94) nil This is Ubuntu 7.10 using: $ java -version java version "1.5.0_13" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_13-b05) Java HotSpot(TM) Client VM (build 1.5.0_13-b05, mixed mode, sharing) -- Michael Wood --~--~-~--~~~---~--~~ You 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: groups-of
On Fri, Dec 19, 2008 at 4:35 PM, Michael Wood wrote: > On Fri, Dec 19, 2008 at 4:32 PM, Rich Hickey wrote: >> >> On Dec 19, 8:59 am, "Michael Wood" wrote: [...] >>> There is a function called partition in Clojure's core.clj that does >>> this, except it does not pad, but rather discards any incomplete >>> groups. It's recursive, though, so it runs out of heap on large >>> sequences like (iterate inc 1). >>> >> >> That's not true - partition is lazy: >> >> ;with -Xmx128M >> >> (last (partition 2 (take 1 (iterate inc 1 >> -> ( 1) > > hmmm... if I do this: > > user=> (partition 2 1 (iterate inc 1)) (.printStackTrace *e) > > it ends like this: > > [...] > 57) (587257 587258) (587258 587259) (587259 587260) (587260 587261) > (587261 587262) (587262 587263) (587263 587264) (587264 587265) > (587265 587266) (587266 587267) (587267 587268) (587268 587269) > (587269 587270) (587270 587271) (587271 587272) (587272 587273) > (587273 587274) user=> java.lang.OutOfMemoryError: Java heap space [...] Actually, I suppose that's because it's printing the whole thing out? -- Michael Wood --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: A more useful assert macro
On Dec 19, 4:27 pm, Stuart Halloway wrote: > While we are talking about assert: I recently wanted for assert to > return the value of the expression, so I could embed asserts inside a > Fact test and get detailed reporting about what failed. > > I checked a few other functional languages and none of their asserts > return a value either. This surprised me. My feeling about assert is that if it fails it means that a program is broken. > Should assert return its value? If not, what should I name the > function that works just like assert but returns its value? I think I'd call it "expect". --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
contrib updated to use latest test-is
Hi all, I have made a small commit [1] to clojure-contrib that gets most of clojure.contrib.test-clojure working again. Hopefully this will enable people to contribute more tests. (J., evaluation.clj was more complicated to fix so I have temporarily disabled it.) I hope to be in the IRC most of the rest of the day (East Coast US) if anybody wants to discuss testing Clojure and Contrib. Cheers, Stuart [1] http://code.google.com/p/clojure-contrib/source/detail?spec=svn317&r=317 --~--~-~--~~~---~--~~ You 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: groups-of
On Fri, Dec 19, 2008 at 9:37 AM, Michael Wood wrote: > > On Fri, Dec 19, 2008 at 4:35 PM, Michael Wood wrote: >> >> hmmm... if I do this: >> >> user=> (partition 2 1 (iterate inc 1)) (.printStackTrace *e) >> >> it ends like this: >> >> [...] >> 57) (587257 587258) (587258 587259) (587259 587260) (587260 587261) >> (587261 587262) (587262 587263) (587263 587264) (587264 587265) >> (587265 587266) (587266 587267) (587267 587268) (587268 587269) >> (587269 587270) (587270 587271) (587271 587272) (587272 587273) >> (587273 587274) user=> java.lang.OutOfMemoryError: Java heap space > [...] > > Actually, I suppose that's because it's printing the whole thing out? It's easy enough to test: user=> (nth (partition 2 1 (iterate inc 1)) 1000) (1001 1002) --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: Preparing for Release 1.0 (was: Re: 20081217 Release)
Hi Meikel, On Thu, Dec 18, 2008 at 11:18 PM, Meikel Brandmeyer wrote: > On 19 Dez., 02:10, bc wrote: >> For clojure-contrib, it would make sense to create a matching tarball >> whenever a Clojure release occurs. For the other 3, it would be >> necessary for someone to test and save off a copy of the libraries >> somewhere (that by itself would make getting started with Clojure a >> much easier task). >> >> I'm not sure what the best way to manage this (the "where" and "who") >> would be. > > The "who" is probably the maintainer/developer of the > third-party library. Although this might seem logical, if fact it is probably not the best solution because: 1. There are multiple inter-related projects (slime, clojure-mode, swank-clojure) that would all need to be "snapshot-ed" simultaneously. 2. It assumes the developer(s) of the projects are interested in doing this (SLIME developers support many lisp implementations). 3. The snapshot of all 3 inter-related projects (slime, clojure-mode, swank-clojure) should occur after it has been confirmed that they all currently work together with the latest clojure release. > The "where" is probably the place > for the "who" hosts his project. Both swank-clojure and clojure-mode are hosted on git-hub. Although it is possible to download a tar/zip file of the current set of files in a git-hub repository, I didn't see any functionality to store other "historical" snapshots. SLIME (as mentioned above) is not clojure-specific. Historically, the SLIME developers have not been keen to create snapshots. >> One option would be to store files in the Clojure Google >> Groups file area (although this could be a bit problematic since the >> Google Groups file area isn't very "flexible" and everything is >> jumbled in there together). Another option is to maintain the 3rd >> party tarballs as separate "Featured" downloads in the clojure-contrib >> Google Code Downloads area. I think the latter might make more sense >> as it would keep "release-related" tarballs all in the clojure-contrib >> project without actually "polluting" the clojure-contrib source >> repository with foreign libraries. It would also provide "ownership" >> of the process (assuming the clojure-contrib members are willing to >> take this on). > > I don't think, that the Google Group is a suitable > place for such files. Concerning the contrib download > area: who decides, which projects are allowed to go > there? Who plays the postman who puts up the files? > (The upstream author is probably not allowed to...) I agree, I just suggested it because it is an option. I think Google Code is much better suited for this. > A centralised approach would be feasible if there was > some CCAN, where every author can upload his files > himself. > > I would propose, that the files are hosted where ever > they are hosted now with suitable labels with which > Clojure version they work. This works out of the box > with the least amount of trouble. For the reasons I listed above, I don't think it's practical to do this for slime, clojure-mode, and swank-clojure. - Bill --~--~-~--~~~---~--~~ You 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: Circular Require Change?
Thanks Rich! I'll keep an eye on the defect(shame there isn't a watch feature on google code). Other than this little minor annoyance, the new AOT changes are working great. Thanks for all the work, I'm really enjoying Clojure. On Dec 17, 6:45 am, Rich Hickey wrote: > On Dec 17, 12:43 am, Kevin Martin wrote: > > > I unfortunately ran intocircularrequires today. In previous > > versions of Clojure acircularrequirewas answered with an > > exception. The text of this was something along the lines of "Cannot > > load 'a' because already loading 'a'. It looks as though this was > > changed with svn revision 1131 Sun Nov 30 12:58:30 2008 > > +.http://clojure.svn.sourceforge.net/viewvc/clojure?view=rev&revision=1131 > > The commit message is "made nested load of already loading resource a > > no-op instead of a throw". This implies this was an intentional > > change. I found this > > posthttp://groups.google.com/group/clojure/browse_thread/thread/d3dd0486f... > > where Rich seems to conclude thatcircularreferences are an error > > waiting to be debugged. I agree with this sentiment and I'm confused > > as to why this was changed. > > It was changed for AOT compilation, where it is now possible to gen- > class a class that gets responsibility for loading that same ns on > init, said init happening when the ns containing the gen-class is > compiled. > > > If there is another thread I didn't find explaining this, please point > > me to it. Otherwise, I am interesting why this was changed to what I > > vote is a worse design choice. > > I hope to re-enable the detection of the 'mistake' case, just requires > some time to work out how to distinguish from the AOT case. > > http://code.google.com/p/clojure/issues/detail?id=3 > > 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: Circular Require Change?
On Fri, Dec 19, 2008 at 10:30 AM, Kevin Martin wrote: > > Thanks Rich! I'll keep an eye on the defect(shame there isn't a watch > feature on google code). Other than this little minor annoyance, the > new AOT changes are working great. Thanks for all the work, I'm > really enjoying Clojure. > > I think starring an issue in Google Code is the equivalent of 'watch'. You'll get emailed when there are changes or comments on that issue. - Cosmin --~--~-~--~~~---~--~~ You 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: Circular Require Change?
On Friday 19 December 2008 09:10, Cosmin Stejerean wrote: > On Fri, Dec 19, 2008 at 10:30 AM, Kevin Martin wrote: > > Thanks Rich! I'll keep an eye on the defect(shame there isn't a > > watch feature on google code). Other than this little minor > > annoyance, the new AOT changes are working great. Thanks for all > > the work, I'm really enjoying Clojure. > > I think starring an issue in Google Code is the equivalent of > 'watch'. You'll get emailed when there are changes or comments on > that issue. Have you been able to make it work? It doesn't for me, and I am logged in. Is there a trick? Stuart H. managed to make it work somehow. He said something about using Firebug to figure it out. > - Cosmin Randall Schulz --~--~-~--~~~---~--~~ You 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: Circular Require Change?
Hi, Am 19.12.2008 um 18:19 schrieb Randall R Schulz: Have you been able to make it work? It doesn't for me, and I am logged in. Is there a trick? Stuart H. managed to make it work somehow. He said something about using Firebug to figure it out. Starring works for me (Safari on Mac & Windows). Sincerely Meikel smime.p7s Description: S/MIME cryptographic signature
Re: Persistent storage
On Dec 18, 7:18 pm, "Mark McGranaghan" wrote: > I've likewise though a fair bit about this, but haven't been able to > come up with a particularly satisfying solution. > > One approach I've considered is a watcher-type system where > persistence is defined in terms of immutable snapshots and append-only > journals: you snapshot the data to disk occasionally and otherwise > maintain persistence by appending changes to a journal before > committing; these changes can be replayed in the case of failure. This > will probably require additional hooks into Clojure's MVCC > implementation. This might actually be workable for smallish data > sets, where it is reasonable to hold everything in memory. > > Anyone interested in the topic of "persistent data structures on disk" > might want to look into the implementation of CouchDB. They currently > use (IIUC) a persistent B tree on disk that uses crash-safe > append-only modifications and is "garbage collected" by occasionally > copying over all reachable portions of the tree into a new file. This > may be interesting in and of itself, but I also expect that we'll see > more interesting things in this space from the CouchDB project. > > - Mark > > On Thu, Dec 18, 2008 at 7:53 PM, Kyle Schaffrick wrote: > > > On Thu, 18 Dec 2008 18:06:40 -0500 > > Chouser wrote: > > >> On Thu, Dec 18, 2008 at 4:47 PM, r wrote: > > >> > Is is possible to use some kind of backend storage for Clojure's > >> > data structures? I mean something like Perl's "tie" function that > >> > makes data structures persistent (in sense of storage, not > >> > immutability). > > >> > Such storage should be inherently immutable the way Clojure's data > >> > are (so a simple wrapper on sql is probably not good enough) and > >> > provide means of querying database and indexing (ideally > >> > multidimensional). > > >> I would looove this. > > > This occurred to me the other day as well; the name "Mnejia" which > > popped into my head says a lot about the sort of thing I had in mind :) > > >> > I wonder if this could be at library level or would rather have to > >> > be hard-coded into Clojure itself. Did anyone try to do it? > > >> I've pondered a couple approaches, though only enough to find > >> problems. > > >> One approach would work act like a Clojure collection, with structural > >> sharing on-disk. This would be great because it would have > >> multi-versioning and transaction features built right in. It would > >> also have the potential to cache some data in memory while managing > >> reads and writes to disk. > > > This is an interesting observation. > > > Something in the vein of OTP's Mnesia for Clojure would be *very* cool > > indeed, and I have been thinking a lot about ways to implement > > distribution mechanisms for Clojure on top of which such a thing could > > be built. I imagine however that even sans distribution it would be > > quite powerful and useful, and a fun project. > > > [ Mostly off-topic musings follow :) ] > > > The big problem with mimicking Mnesia for distribution is that a lot of > > Erlang distribution idioms (used heavily in Mnesia AFAIK) rely on BEAM's > > ability to marshall funs across the network (and indeed I think Mnesia > > can even use that to serialize them on disk tables). If serialization of > > a fun is possible in Clojure, doing it is way over my head :) Obviously > > if you can serialize the sexp before the compiler gets ahold of it, this > > is easy, but usually you don't get that lucky. > > > If one were able to marshall a Clojure fun, I had envisioned > > constructing a sort of "distributed send", probably built atop one of > > the many good message-queueing protocols already extant, that can be > > used to cause that fun to be run on a remote Agent, giving you a more > > Clojure-flavored distribution mechanism. Not RPC, but not exactly Actor > > model either. > > > H... :) > > > -Kyle The largest project for which I'm using Clojure currently uses a CouchDB instance for server storage and uses neo4j for single-user persistent storage. Both are working well for me so far. They aren't transparent, but, then again, I'm not sure that any persistent storage mechanism is. Based on past experience, I prefer to have all operations that alter persistent storage go through a fairly small number of API calls, so that the search space is small when it's time to fix bugs. Writing that API, and then ensuring that everything in the system uses it, is about as much work as writing the data- marshaling subsystem that you need for storage that requires marshaling, so in that sense it's no loss. There may even be a disadvantage to a storage subsystem that purports to be "transparent": if the only way to get objects into and out of the store is by marshaling them through your API, then there won't be rogue code somewhere using some other API to scribble something wrong in your database. If you use a "transparent" storage layer, then there are ways other
Clojure vs. CL macros question
According to Paul Graham's On Lisp, macroexpanders should be purely functional, and you should not count on how often a macro gets expanded. This seems like a reasonable restriction for Clojure too. However, Chouser posted an example that shows the expansion of proxy does have a side effect [2]. Should macros written by ordinary mortals follow PG's rule? If not, should this be listed as a difference from other Lisps at [3]? Stuart [1] http://www.paulgraham.com/onlisp.html. Free download, see discussion in 10.3. [2] http://paste.lisp.org/display/72406 [3] http://clojure.org/lisps --~--~-~--~~~---~--~~ You 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: Microsoft SQL Server and the sql contrib
On Tue, Dec 16, 2008 at 1:15 PM, Scott Jaderholm wrote:
> I'm trying to use the sql contrib with Microsoft SQL Server Express 2005.
I've used the jTDS driver for SQL Server 2005 (not Express) without
any problems, so if you still have problems with the Microsoft driver
you may want to try that one.
> 3. I'm defining my database connection as follows:
>
> (def db {:classname "com.microsoft.sqlserver.jdbc.SQLServerDriver"
> :subprotocol "sqlserver"
> :subname "//sqlserver\\sqlexpress" ; this is hostname and instance
> name. I've tried just //sqlserver and sqlserver also
> :user "username"
> :password "password"
> })
I think the problem is that you cannot specify the instance in the
:subname part of the connection parameters. Instead use the
':instance' keyword. For example,
(def db {:classname "com.microsoft.sqlserver.jdbc.SQLServerDriver"
:subprotocol "sqlserver"
:subname "//sqlserver"
:instance "sqlexpress"
:user "username"
:password "password"
})
Failing that, send along a connection string that you would use from
Java and we can figure out how to break it apart into its pieces for
the SQL library.
-tree
--
Tom Emerson
tremer...@gmail.com
http://www.dreamersrealm.net/~tree
--~--~-~--~~~---~--~~
You 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 vs. CL macros question
I think it's a generally good idea for macros to be purely functional, but it's not always a requirement. As long as Clojure remains exclusively a compiler and not an interpreter (unlike some CL implementations) I think it is safe to assume that macros will only run at compile time. -S On Dec 19, 2:05 pm, Stuart Halloway wrote: > According to Paul Graham's On Lisp, macroexpanders should be purely > functional, and you should not count on how often a macro gets > expanded. This seems like a reasonable restriction for Clojure too. > However, Chouser posted an example that shows the expansion of proxy > does have a side effect [2]. > > Should macros written by ordinary mortals follow PG's rule? If not, > should this be listed as a difference from other Lisps at [3]? > > Stuart > > [1]http://www.paulgraham.com/onlisp.html. Free download, see > discussion in 10.3. > [2]http://paste.lisp.org/display/72406 > [3]http://clojure.org/lisps --~--~-~--~~~---~--~~ You 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: FAQ
+1 to Mon Key's suggestions. Those are very FAQ-like questions. -Matt On Dec 19, 12:45 am, Mon Key wrote: > Some thoughts on really stupid things that have tripped me up: > > - How do I exit Clojure - srsly > C-c > > - Whatsa JVM - does this mean Clojure is really just Java with parens? > > - Whatsa Classpath? > this answer presents the *ALL* important opportunity to mention that > *nix uses `:' to separate paths whereas windz uses `;' > > - How do I access Clojure documentation - e.g. where is `man Clojure' > > - Is a Clojure docstring the same as Javadoc? > > - Is Clojure stable? > > - Where's the Clojure manual? > > - What happened to setf? > > - Why are Clojure's docstring placements different than other lisps > > - Where do I make donations? > > - Why are Clojure's defun params passed in a [] vector? > > - Does Clojure do TCO? > > - Whatsa TCO? > > - How do I compile Clojure? OR Where's the Clojure Compiler? > > - How does Clojure's nil differ from other Lisps? > > - Clojure has a `cons' function and a `conj' function - whats the > difference? > > - At what point do calls out to external Java interfaces limit/alter > Clojures' internal handling of sequences > How do I avoid interopearating with Java - e.g. when is Clojure > all I need for task X > When should I make use of external Java libraries > > - Whatsa Clojure Sequence - how does it corellate to language X > - Whatsa Collection - how does it corellate to language X > - Whatsa Map - how does it corellate to language X > > On Dec 19, 12:41 am, "Adrian Cuthbertson" > > wrote: > > > Suggestions for entries welcome here. > > > > > Rich > > > Here's another that was a "gotcha" for me for an hour or two... > > > Why after using map/reduce/for to change a java object does the object > > remain unchanged? > > > (defn initv1 [myseq] (let [v (java.util.Vector.)] (for [x myseq] > > (.addElement v x)) v)) > > (initv1 [1 2 3]) > > ; => (java.util.Vector. []) > > > ; or... > > > (defn initv2 [myseq] (let [v (java.util.Vector.)] (map (fn [x] (.addElement > > v x)) myseq) v)) > > (initv2 [1 2 3]) > > ; => (java.util.Vector. []) > > > As map/reduce/for are lazy, the "let" construct does not actually "take" any > > elements from the map/reduce/for. In this case, use doseq... > > > (defn initv3 [myseq] (let [v (java.util.Vector.)] (doseq [x myseq] > > (.addElement v x)) v)) > > (initv3 [1 2 3]) > > ; => (java.util.Vector. [1 2 3]) > > > (Actually this happened in a more complex function, but the essence was that > > a new java object was instantiated in a let and I'd used a map to call a > > method on that object with all the items from a sequence. I could not > > understand why the object remained unchanged afterwards until I simplified > > it down to the above example). > > > Regards, Adrian --~--~-~--~~~---~--~~ You 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 -~--~~~~--~~--~--~---
Stumped - Java hangs when using Swing in Slime
I noticed this first with a project I'm working on, and verified that it is happening as well with the temperature converter demo on the clojure site. After I run the file from within Slime, after a few seconds my Swing gui stops responding, and the Repl as well. Apparently, the whole Java process is hung. Running the same file from a basic Clojure Repl started from the command line works fine, with exactly the same VM settings. I am running on Windows XP with Java 1.6.0_10. Anyone have any ideas? I'm pretty confused as to what might be going on. Some sort of deadlock in the thread pool that isn't allowing the AWT event thread any cycles? I'm looking at the thread pool in JSwat and I see a lot of Swank threads, but I can't tell exactly what's going on. Many thanks, -Luke --~--~-~--~~~---~--~~ You 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 -~--~~~~--~~--~--~---
def in caller namespace from a macro
I'm learning macros, and I've figured something out that works for what I want to do but looks awfully weird. Is this a hacky mess because I don't know the clean way to do it or an idiom I just need to get used to? I want a macro expansion to define some functions in the namespace of the "caller." I think I need syntax-quoting because I need to drop some arguments in place, but since syntax-quoting namespace-qualifies symbols with the namespace of the macro, I'm using a let to also drop in the symbols that I don't want namespace-qualified. Here's a simple example that shows what I'm talking about: (ns foo) (defmacro defthing [s] (let [thing-name 'thing] `(def ~thing-name (format "the %s thing" ~s (ns bar) (foo/defthing "Bar") (ns user) (foo/defthing "User") thing => "the User thing" bar/thing => "the Bar thing" So this works, and that's great, but that let is pretty gross. Am I missing a cleaner way? Thanks. -hume. -- http://elhumidor.blogspot.com/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
*compile-path* hardwired in compiled Clojure core
Hi Rich & all, While compiling Clojure, It seems that *compile-path* is being set to the absolute path to "classes" within the Clojure source distribution. That is: unzip clojure_20081217.zip cd clojure java -jar clojure.jar Clojure user=> *compile-path* "/Users/rich/dev/clojure/classes" And it doesn't obey the system property used by clojure.lang.Compile: java -Dclojure.compile.path="/tmp/classes" -cp /tmp/ classes:clojure.jar clojure.main Clojure user=> *compile-path* "/Users/rich/dev/clojure/classes" -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: def in caller namespace from a macro
Hi, Am 19.12.2008 um 21:25 schrieb John D. Hume: (ns foo) (defmacro defthing [s] (let [thing-name 'thing] `(def ~thing-name (format "the %s thing" ~s Simply put 'thing directly into the syntax-quote: (defmacro defthing [s] `(def ~'thing (format "the %s thing" ~s))) But be sure to clearly document, that you capture symbols of a certain form with your macro. Otherwise this may lead to clashes with user code! In your example this is probably the point of the macro to define a certain name. But in general capturing names in macros is a bad thing. Sincerely Meikel smime.p7s Description: S/MIME cryptographic signature
Re: Stumped - Java hangs when using Swing in Slime
Possibly related: http://groups.google.com/group/clojure/browse_thread/thread/161d608ccb1e8b3d/76eadda70df674a4?lnk=gst&q=swing+hang#76eadda70df674a4 Bill On Dec 19, 2:18 pm, levand wrote: > I noticed this first with a project I'm working on, and verified that > it is happening as well with the temperature converter demo on the > clojure site. > > After I run the file from within Slime, after a few seconds my Swing > gui stops responding, and the Repl as well. Apparently, the whole Java > process is hung. > > Running the same file from a basic Clojure Repl started from the > command line works fine, with exactly the same VM settings. > > I am running on Windows XP with Java 1.6.0_10. > > Anyone have any ideas? I'm pretty confused as to what might be going > on. Some sort of deadlock in the thread pool that isn't allowing the > AWT event thread any cycles? I'm looking at the thread pool in JSwat > and I see a lot of Swank threads, but I can't tell exactly what's > going on. > > Many thanks, > -Luke --~--~-~--~~~---~--~~ You 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: CLI launcher (was: Superficial barriers to entry)
On Thu, Dec 18, 2008 at 12:56 PM, Phil Hagelberg wrote: > This was one of the most disorienting things I encountered when starting > with clojure. I'm used to codebases providing a bin/ directory or at > least a shell script to start from. It wouldn't be so bad if the java > CLI launcher were any good, but it's pretty lousy. This could be rectified with an appropriate shell-script / batch file that is part of the standard distribution. Unfortunately the nature of Java means you need to deal with classpaths and what not. The addition of the manifest to the clojure jar file so that it can be launched with $ java -jar clojure.jar is a Win, but it could be better. > I've been looking at hashdot, (http://hashdot.sourceforge.net/) and it > seems to address the weaknesses of the java command in a pretty > intuitive way that makes it seem like a first-class citizen in Unix. It > lets you write shebang-savvy scripts, and it sets the process names so > you get something reasonable showing up in ps and top instead of the > jumble of alphanumerics that the jvm shows by default. The downside of hashdot is that the developers do not distribute binary packages, so it is up to the user to go out and download it, get and build/install APR, and Windows users are stuck. I agree that hashdot is a good solution, but it isn't optimal IMHO. -tree -- Tom Emerson tremer...@gmail.com http://www.dreamersrealm.net/~tree --~--~-~--~~~---~--~~ You 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: Stumped - Java hangs when using Swing in Slime
> Anyone have any ideas? I'm pretty confused as to what might be going > on. Some sort of deadlock in the thread pool that isn't allowing the > AWT event thread any cycles? I'm looking at the thread pool in JSwat > and I see a lot of Swank threads, but I can't tell exactly what's > going on. I literally just had this problem today. I was having slime hang on me with _any_ swing code. So I tried the basic repl and even the most basic (. javax.swing.JOptionPane (showMessageDialog nil "Hello World")) and even this was failing. Spent an hour svn updating, etc. Finally, I clicked on the system icon tray at the bottom right of XP and noticed that that the stupid Java download manager wanted me to update. I let it download whatever patch it wanted and then suddenly everything worked. It could be coincidental. But I am telling you just in case. --~--~-~--~~~---~--~~ You 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: Blogging About Clojure?
On Tue, Dec 16, 2008 at 2:05 PM, Randall R Schulz wrote: > Does anyone have any recommendations? I use WordPress on my site and like it a lot: does everything I need, and then some I suspect. wordpress.com will host your blog for free, I think. Also blogger.com (owned by Google) looks to be quite good and quite popular, and also is free. Anyway, they're the big two. -tree -- Tom Emerson tremer...@gmail.com http://www.dreamersrealm.net/~tree --~--~-~--~~~---~--~~ You 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 -~--~~~~--~~--~--~---
subset?
Since sets are callable like functions, subset? can be written pretty concisely: user> (defn subset? [a b] (every? b a)) It handles the empty set cases correctly and everything. Is this already in clojure-contrib? Want it and its brethren superset? proper- subset? proper-superset? in there? Andrew --~--~-~--~~~---~--~~ You 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: subset?
I should note that this also works because of sets being seq-able. Since they're callable, we can use b as the predicate in every?; since they're seq-able we can use a as the coll in every?. Very cool! On Dec 19, 1:46 pm, Andrew Baine wrote: > Since sets are callable like functions, subset? can be written pretty > concisely: > > user> (defn subset? [a b] (every? b a)) > > It handles the empty set cases correctly and everything. Is this > already in clojure-contrib? Want it and its brethren superset? proper- > subset? proper-superset? in there? > > Andrew --~--~-~--~~~---~--~~ You 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: Blogging About Clojure?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/19/2008 04:23 PM, Tom Emerson wrote: > On Tue, Dec 16, 2008 at 2:05 PM, Randall R Schulz wrote: >> Does anyone have any recommendations? > > I use WordPress on my site and like it a lot: does everything I need, > and then some I suspect. > > wordpress.com will host your blog for free, I think. > > Also blogger.com (owned by Google) looks to be quite good and quite > popular, and also is free. > > Anyway, they're the big two. > > -tree > I'm curious, does anyone here have any experience using Roller? (http://rollerweblogger.org/project/) Personally, I use Wordpress, but I think it may be interesting to switch to a java-based blogging platform in the event I decide to do any extending with Clojure. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAklMIoYACgkQWorbjR01Cx74uQCgjg8kLPc8buXx7p3nhggsvZEl 1wYAoJEaJIz/Uud7ErZ9T6X9bfhji0Gc =h4ne -END PGP SIGNATURE- --~--~-~--~~~---~--~~ You 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: The return of the monads: lessons learned about macros
Konrad, Glad to know we were on the same page about monad transformers. That transformer was indeed a translation from the Haskell implementation. Using 'with-monad' does clean it up. I'll have to take a look at your implementation of m-bind. I did prefer the conciseness and the fact that it would handle a vector of more than one value. But the behavior is identical, so it seems it's more a matter of taste. > > I also rewrote the maybe monad as: > ... > > Why did you do this? Did you just want a more concise implementation, > or is there a difference in behaviour? As far as I can see, your > version of m-bind does exactly the same as mine for all input values > that can occur in the given context. Yours would also do something > useful given a vector of more than one value, but that should never > happen in the maybe monad. I've got some more thinking to do about transformers, when I get a chance. Jim --~--~-~--~~~---~--~~ You 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 -~--~~~~--~~--~--~---
dissoc-in?
I've been using assoc-in, get-in, etc, to work with nested maps, but I recently needed a dissoc-in to free up unneeded indexes and such. I didn't see one, so does this look about right? (defn dissoc-in [m keys] (if (<= (count keys) 1) (dissoc m (first keys)) (let [k (last keys) restkeys (butlast keys) submap (dissoc (get-in m restkeys) k)] (if (empty? submap) (recur m restkeys) (assoc-in m restkeys submap) --~--~-~--~~~---~--~~ You 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 -~--~~~~--~~--~--~---
doc strings for multimethods?
Am I mistaken, or is there currently no nice syntax for giving doc
strings to methods? Sure, I can do
(defmulti #^{:doc "documentation"} my-method my-dispatch-fn)
but for consistency with defn and defmacro it would be nice to have a
direct way to document multimethods. Even better would be a way to
provide doc strings for each method implementation as well, but that
seems trickier to fit in the current framework.
-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: Blogging About Clojure?
Hi Randall, I'm in the same boat: I just set up my first blog yesterday so I could post some gotchas i've found and experiments i've done with clojure. I went the route David suggests: dreamhost.com has a special now, $10 for a domain and 6 months free hosting, and they have a one-click wordpress install. I'm not sure how best to post code, but for now simple seems to work OK. -Jason On Dec 16, 11:05 am, Randall R Schulz wrote: > Hi, > > Wordy though I am, I've never done any blogging before, but now that I'm > finally beginning to get up-to-speed on Clojure, I think I might have > some things to say. > > So I was wondering if anyone could recommend a good blog site for this > purpose? Naturally, I'll want to include source code, so it should be > able to present that easily and cleanly. Apart from that, I don't think > I need much in the way of fanciness. I'd prefer a site whose > presentation is clean and uncluttered. > > Does anyone have any recommendations? > > Randall Schulz --~--~-~--~~~---~--~~ You 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: Blogging About Clojure?
Jason writes: > I'm in the same boat: I just set up my first blog yesterday so I could > post some gotchas i've found and experiments i've done with clojure. > I went the route David suggests: dreamhost.com has a special now, $10 > for a domain and 6 months free hosting, and they have a one-click > wordpress install. I'm not sure how best to post code, but for now > simple seems to work OK. I host my blog on Dreamhost, and it works great for static files, though if you're looking to host actual clojure apps DH won't cut it. I have a one-click wordpress install for my family blog, and a statically-generated HTML blog for my code stuff. Posting code is notoriously easy to screw up with many blogging platforms, so I've found the most reliable way is to just export HTML straight from your editor, and just rely on its syntax highlighting. htmlize.el works like a dream: http://www.emacswiki.org/emacs/Htmlize If you're going to blog about code, you definitely want it highlighted; monochrome code is really hard to read. My brain basically just shuts off when it sees it; I've gotten too used to the help that an editor provides. -Phil --~--~-~--~~~---~--~~ You 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: CLI launcher
"Tom Emerson" writes: > On Thu, Dec 18, 2008 at 12:56 PM, Phil Hagelberg > wrote: >> This was one of the most disorienting things I encountered when starting >> with clojure. I'm used to codebases providing a bin/ directory or at >> least a shell script to start from. It wouldn't be so bad if the java >> CLI launcher were any good, but it's pretty lousy. > > This could be rectified with an appropriate shell-script / batch file > that is part of the standard distribution. Unfortunately the nature of > Java means you need to deal with classpaths and what not. The addition > of the manifest to the clojure jar file so that it can be launched > with > > $ java -jar clojure.jar > > is a Win, but it could be better. A bundled shell script would help, but it will still look pretty silly in ps or top when you've got a more interesting classpath. Hashdot also provides easy daemonization, which you would have to handle yourself. It seems to me (being spoiled by package managers and not having any Java experience) that you would want Clojure to be able to use system-installed libraries (jars provided by apt-get) automatically, which is pretty easy to do in hashdot. Someone on #clojure seemed to say this was a bad idea. I couldn't make head or tail of his reasoning, but maybe there's a problem with it? > The downside of hashdot is that the developers do not distribute > binary packages, so it is up to the user to go out and download it, > get and build/install APR, and Windows users are stuck. I agree that > hashdot is a good solution, but it isn't optimal IMHO. Well, the project is only a month or so old, but the developer is very responsive. It couldn't take long for someone familiar with C to give it a decent ./configure file and get a few .debs and .rpms up for download. It's a little effort up front to save a fair amount of time for users getting started. -Phil --~--~-~--~~~---~--~~ You 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: Blogging About Clojure?
> I host my blog on Dreamhost, and it works great for static files, though > if you're looking to host actual clojure apps DH won't cut it. Yeah, Java hosting seems like rather tricky business, since you basically need dedicated RAM. I've heard slicehost is very good and reasonably priced in that department. Anyway, I'm not there yet. > htmlize.el works like a dream:http://www.emacswiki.org/emacs/Htmlize Thanks for the tip; I'll definitely check that out. I'd imagine you could paste the generated HTML directly into a wordpress post; have you experienced problems with this? -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: Listen on changes to refs
Apart from being blasphemous - would it be a good idea to override clojure.lang.Ref in Java land? I want to create (children of?) refs in clojure that send an agent when they change, so that I can create facilities to observe changes to them. Creating a 'MyRef extends Ref' seems to be the obvious Java way. Don't know whether the #^clojure.lang.Ref tags in the clojure ref functions would cause problems, though (is it like instanceof or is it a (arg.getClass() == ... comparison?). This might be the easiest way for a Java developer, but shouldn't it be possible to develop this in Clojure land in an easy manner? On 16 Dez., 20:58, Rowdy Rednose wrote: > Can I listen on changes done to refs? > > Let's say in a scenario like that > onhttp://en.wikibooks.org/wiki/Clojure_Programming#Mutation_Facilities > could I add a facility that allows the registration of listeners that > get called on certain changes to the refs? > > For example I'd like to be notified on all changes to employees where > name is "Jim". --~--~-~--~~~---~--~~ You 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: Blogging About Clojure?
>> I host my blog on Dreamhost, and it works great for static files, though >> if you're looking to host actual clojure apps DH won't cut it. > > Yeah, Java hosting seems like rather tricky business, since you > basically need dedicated RAM. I've heard slicehost is very good and > reasonably priced in that department. Anyway, I'm not there yet. > I started my first Clojure web application on Slicehost a few days ago using the Compojure library. The setup was surprisingly easy. http://ericlavigne.wordpress.com/2008/12/18/compojure-on-a-slicehost-vps/ As the application develops, I'll write additional articles to share what I've learned - and to help me remember :-) -- Education is what survives when what has been learned has been forgotten. - B. F. Skinner --~--~-~--~~~---~--~~ You 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: Listen on changes to refs
On Fri, Dec 19, 2008 at 8:35 PM, Rowdy Rednose wrote: > > Apart from being blasphemous - would it be a good idea to override > clojure.lang.Ref in Java land? > > I want to create (children of?) refs in clojure that send an agent > when they change, so that I can create facilities to observe changes > to them. I don't think it would be quite that easy. The implementation of Refs is shared with LockingTransaction. You saw that agents have watchers that do exactly this? Depending on how complex your use case, you might be able to get away with using agents and 'await' for now. Another option, as long as you don't tell Rich, is that you could abuse the validator function to send to your agent. Anyway, apparently watchers for Refs are planned, so you could just wait for that. --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: Listen on changes to refs
To give some structure to my previous questions - How would I make refs, that I'm interested in, send an agent on every change, without having to do that manually? A: Extend the Ref class (either in Clojure land or in Java land) B: overload/overwrite (however that would be achieved in Clojure) the relevant functions like ref-set etc. Or is there anything else I missed? On 20 Dez., 10:35, Rowdy Rednose wrote: > Apart from being blasphemous - would it be a good idea to override > clojure.lang.Ref in Java land? > > I want to create (children of?) refs in clojure that send an agent > when they change, so that I can create facilities to observe changes > to them. Creating a 'MyRef extends Ref' seems to be the obvious Java > way. Don't know whether the #^clojure.lang.Ref tags in the clojure ref > functions would cause problems, though (is it like instanceof or is it > a (arg.getClass() == ... comparison?). > > This might be the easiest way for a Java developer, but shouldn't it > be possible to develop this in Clojure land in an easy manner? > > On 16 Dez., 20:58, Rowdy Rednose wrote: > > > Can I listen on changes done to refs? > > > Let's say in a scenario like that > > onhttp://en.wikibooks.org/wiki/Clojure_Programming#Mutation_Facilities > > could I add a facility that allows the registration of listeners that > > get called on certain changes to the refs? > > > For example I'd like to be notified on all changes to employees where > > name is "Jim". --~--~-~--~~~---~--~~ You 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: Listen on changes to refs
Validators seem like an easy way to do it, I'll try that. Thanks Chouser! Afaik Rich only thinks about adding watchers to refs currently, and I can't find it in the list: http://code.google.com/p/clojure/issues/list?can=2&q=&colspec=ID+Type+Status+Priority+Reporter+Owner+Summary&cells=tiles So it will probably not be in 1.0 On 20 Dez., 11:30, Chouser wrote: > On Fri, Dec 19, 2008 at 8:35 PM, Rowdy Rednose wrote: > > > Apart from being blasphemous - would it be a good idea to override > > clojure.lang.Ref in Java land? > > > I want to create (children of?) refs in clojure that send an agent > > when they change, so that I can create facilities to observe changes > > to them. > > I don't think it would be quite that easy. The implementation of Refs > is shared with LockingTransaction. > > You saw that agents have watchers that do exactly this? Depending on > how complex your use case, you might be able to get away with using > agents and 'await' for now. > > Another option, as long as you don't tell Rich, is that you could > abuse the validator function to send to your agent. > > Anyway, apparently watchers for Refs are planned, so you could just > wait for that. > > --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: syntax philosophy
> I have a strong dislike for the concept of TIMTOWTDI (There is more > than one way to do it . This should be a guiding design goal for any core lisp devel. Get the core right and TIMTOWTDI is a `side effect' of good design rather than the inverse. s_P On Dec 19, 7:36 am, "Mark Volkmann" wrote: > > If you don't need this, you don't have to use it. > > I feel very strongly that Clojure, and any programming language, > should avoid using this rationale when adding support for new syntax. > Just because a developer chooses not to use a particular feature > doesn't mean they don't have to understand it. They will have to read > the code that other developers write and those developers may use the > feature. > > I have a strong dislike for the concept of TIMTOWTDI (There is more > than one way to do it ... pronounced "tim toadie") that Perl and Ruby > espouse. I think it's fine to have more than one way to do something > IF each way has some unique characteristic such as performance in > different scenarios, but not if each way is just a different syntax > for the same functionality. > > Part of the success of Clojure (measured in adoption) will depend on > how much effort is required to learn it. Anything extra that makes > Clojure code more challenging to read and determine what the code does > works against the goal of getting more developers to consider using > Clojure. > > -- > 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: Clojure vs. CL macros question
> This seems like a reasonable restriction for Clojure too. Third rule. Macros break the rules. Don't place arbitrary restrictions on rule breaking :P s_P On Dec 19, 2:05 pm, Stuart Halloway wrote: > According to Paul Graham's On Lisp, macroexpanders should be purely > functional, and you should not count on how often a macro gets > expanded. This seems like a reasonable restriction for Clojure too. > However, Chouser posted an example that shows the expansion of proxy > does have a side effect [2]. > > Should macros written by ordinary mortals follow PG's rule? If not, > should this be listed as a difference from other Lisps at [3]? > > Stuart > > [1]http://www.paulgraham.com/onlisp.html. Free download, see > discussion in 10.3. > [2]http://paste.lisp.org/display/72406 > [3]http://clojure.org/lisps --~--~-~--~~~---~--~~ You 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: Persistent storage
Hans Hubner's BKNR framework for CL explores this in a very interesting way - while relying on CLOS meta-object protocol the ideas could prob. be extended to Clojure. With some ABCL interaction this would make CL -> Clojure || Clojure -> CL interop possible at the JVM level with persistence... Someone call me when i can pull my head out of the pipe :) s_P On Dec 18, 8:10 pm, r wrote: > On Thu, Dec 18, 2008 at 11:06 PM, Chouser wrote: > > > I've pondered a couple approaches, though only enough to find > > problems. > > > One approach would work act like a Clojure collection, with structural > > sharing on-disk. This would be great because it would have > > multi-versioning and transaction features built right in. It would > > also have the potential to cache some data in memory while managing > > reads and writes to disk. > > > But Clojure's persistent collections rely on garbage collection -- > > when old versions of the collection are no longer referenced, the JVM > > cleans them up automatically. How would this work on disk? How would > > you define "no longer referenced"? > > [1. just to confirm I understand you correctly: is this a > "transparent" case where each newly constructed data structure is > immediately written to disk?] > > I can see another problem here: assuming we have multiple "active" > versions of such structure at the time of closing the application, > which of them should we restore when the application restarts? Do we > need explicit "save"&"restore" commands to mark the data we want > anyway? Or is it better to automatically keep track of "heads" per > (named) thread? Or use a (transparent) Ref? > > Another issue is the efficiency of the GC itself. Whatever scheme we > use, Clojure is going to use GC a lot. This may cause strong > fragmentation of data on disk (not to say about performance penalty). > > > Another approach would be at the Ref or Agent level, where watchers > > could be hooked in. (Watchers are currently only for agents, but are > > planned for refs as well.) Watchers are functions that are called > > when their underlying mutable object has a change committed, so they'd > > be able to sync the disk up with new in-memory value. But this means > > the whole collection would have to be in-memory. Also the watcher > > gets no hint as to *what* in the collection changed. > > > So for now it seems we'll have to make do with "normal" mechansims > > like SQL libraries. > > [2. is this an "opaque" case where data sit in memory and only when we > switch the Ref the on-disk representation is updated?] > > Hiding the whole data structure behind the Ref and syncing data only > when it changes would solve both problems mentioned above. The cost is > that the data would not longer be updated incrementally so the whole > structure would have to be flushed to the disk. This wouldn't be very > efficient but would work with existing database back-ends. > > Perhaps it would be better to use a combination of 1. and 2., i.e. not > only to hide data structures behind a Ref and commit changes to disk > only when the Ref changes (as in 2.) but also to use a journal for > tracking "modifications" to data so that only incremental changes have > be done. Such journal could be translated (and optimized) into a bunch > of INSERT&DELETE commands. > > Another question: what kind of data structures? List, vector and hash > or maybe a new specialized type (a table)? Performance characteristics > are going to be very different from in-memory data so maybe it makes > sense for the whole mechanism to be opaque. > > -r. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
multiple sets on one item - is this a good idea?
Hello, I am gearing up to write some swing code, specifically some stuff where I want to use the grid bag layout system, and I remember something I hated about java: --c.fill = GridBagConstraints.HORIZONTAL; c.weightx = 0.5; c.gridx = 2; c.gridy = 0; -- You repeated c all over the place so you didn't dare name it something reasonable. I noticed in some closure code this looks about the same (actually worse): (set! (.fill c) GridBagConstraints/HORIZONTAL) (set! (.anchor c) GridBagConstraints/PAGE_END) (set! (.weightx c) 1.0) (set! (.weighty c) 1.0) So I decided to do something about it: user> c # user> (defmacro sets! [vars & rest] `(do ~@(map (fn [flds] `(set! (. ~vars ~(first flds)) ~(second flds))) rest))) nil user> (macroexpand '(sets! c (fill GridBagConstraints/HORIZONTAL) (weightx 1.0))) (do (set! (. c fill) GridBagConstraints/HORIZONTAL) (set! (. c weightx) 1.0)) user> (sets! c (fill GridBagConstraints/VERTICAL) (weightx 1.0)) 1.0 user> (. c fill) 2 user> (sets! c (fill GridBagConstraints/VERTICAL) (weightx 1.0)) 1.0 user> (. c fill) 3 user> Is this a good idea or did I do something ridiculous? I am a clojure newb, so please feel free to be quite explicit. Chris --~--~-~--~~~---~--~~ You 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: doc strings for multimethods?
Docstrings for individual defmethods are not possible.
You can find more info about it there:
http://groups.google.com/group/clojure/msg/f7751913e875953f
Lauri
On Sat, Dec 20, 2008 at 3:05 AM, Jason wrote:
>
> Am I mistaken, or is there currently no nice syntax for giving doc
> strings to methods? Sure, I can do
>
> (defmulti #^{:doc "documentation"} my-method my-dispatch-fn)
>
> but for consistency with defn and defmacro it would be nice to have a
> direct way to document multimethods. Even better would be a way to
> provide doc strings for each method implementation as well, but that
> seems trickier to fit in the current framework.
>
> -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
-~--~~~~--~~--~--~---
Help Needed Getting Clojure-Mode working with XEmacs
Hi everyone, I'm trying to get clojure-mode working under XEmacs and am having troubles. I managed to get it working under GNU Emacs with the following .emacs file: (setq inferior-lisp-program "java -cp C:/clojure/trunk/clojure.jar clojure.lang.Repl") (add-to-list 'load-path "C:/program files/xemacs/clojure-mode") (require 'clojure-auto) But it doesn't work under XEmacs, and I'm not sure what else I have to do. I'm very new to emacs and would really appreciate some easy to follow instructions for getting this set up. Thanks very much -Patrick --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: multiple sets on one item - is this a good idea?
chris a écrit : > Hello, I am gearing up to write some swing code, specifically some > stuff where I want to use the grid bag layout system, and I remember > something I hated about java: > > --c.fill = GridBagConstraints.HORIZONTAL; > c.weightx = 0.5; > c.gridx = 2; > c.gridy = 0; > -- > > You repeated c all over the place so you didn't dare name it something > reasonable. > > I noticed in some closure code this looks about the same (actually > worse): > (set! (.fill c) GridBagConstraints/HORIZONTAL) > (set! (.anchor c) GridBagConstraints/PAGE_END) > (set! (.weightx c) 1.0) > (set! (.weighty c) 1.0) > Your sets! macro seems a good idea to me. When an object provides proper accessors, you can write: (doto c (.setFill GridBagConstraints/HORIZONTAL) (.setAnchor GridBagConstraints/PAGE_END) (.setWeightx 1.0) (.setWeighty 1.0)) But in your case, the only way to use doto I can think of is: (doto c (-> .fill (set! GridBagConstraints/HORIZONTAL)) (-> .anchor (set! GridBagConstraints/PAGE_END)) (-> .weightx (set! 1.0)) (-> .weighty (set! 1.0))) which does not repeat c but is even slightly longer than the naive sequence of set!. I think that you could remove some parens from your macro form to just write: (sets! c fill GridBagConstraints/HORIZONTAL weightx 1.0) (I think it's a more idiomatic form, see cond or bindings: pairs aren't paired together.) (defmacro sets! [vars & rest] `(do ~@(map (fn [flds] `(set! (. ~vars ~(first flds)) ~(second flds))) (apply array-map rest Christophe --~--~-~--~~~---~--~~ You 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 -~--~~~~--~~--~--~---
