Re: Performance of seq on empty collections
On Sun, Nov 14, 2010 at 9:36 PM, Eric Kobrin erl...@gmail.com wrote: This brought to mind the general case of detecting emptiness. The current practice of using `seq` to check for non-emptiness wastes resources. It depends: in many cases you need to call seq anyway in the non-empty branch so seq+if-let is both expressive and efficient. However from time to time you really need to check for emptiness quickly. (zero? (count x)) is one way, (.isEmpty ^java.util.Collection x) is another. This limits the use of nice abstractions like `reduce` in performance critical environments where a sentinel could be used. Not everyone will be able to use a sentinel value to solve their particular problem. What can be done to make `empty` faster? However if your [] is really a sentinel, what about creating a real sentinel with (Object.) or (gensym) and checking it with identical? hth, Christophe -- Professional: http://cgrand.net/ (fr) On Clojure: http://clj-me.cgrand.net/ (en) -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: LabREPL status ... github returning 404's
On 14 November 2010 20:47, Victor Olteanu bluestar...@gmail.com wrote: Github is down at the moment unfortunately... Ahhh great, it's back up... Looks like github was partially down as other pages were returning for me. Thanks R. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: max-key taking a list rather than different number of args
You should be able to use (apply max-key f someseq); apply takes a variable number of args, and only the last is expanded. Thanks, thought there would be something like this! -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: LabREPL status ... github returning 404's
On 15 November 2010 09:46, Rick Moynihan rick.moyni...@gmail.com wrote: On 14 November 2010 20:47, Victor Olteanu bluestar...@gmail.com wrote: Github is down at the moment unfortunately... Ahhh great, it's back up... Looks like github was partially down as other pages were returning for me. I'm guessing this was the cause... https://github.com/blog/744-today-s-outage R. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Clojure typing test
The StackOverflowError jumps over the lazy seq. Have all good days, David Sletten -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Land of Lisp's Conrad Barski M.D. speaking about Clojure (Nov. 18, DC/VA/MD area)
Conrad Barski, author of Land of Lisp (http://www.amazon.com/gp/ product/1593272812) will be giving a talk entitled *Land of Lisp: The Clojure-ish Parts* at the National Capital Area Clojure Users Group (CAPCLUG) on November 18, 2010 at 6:15 pm. The meeting will be held at 12021 Sunset Hills Road Suite 400, Reston, VA. Pizza and drinks are provided as part of the admission cost of $0.00 USD. The talk will be followed by mingle time whereby you can talk to programmers interested (and at times well versed in) Clojure, Common Lisp, Scheme, Ruby, Java, T, Gosu, and the Kent Recursive Calculator. Please consider signing up at the CAPCLUG meeting site (http:// www.meetup.com/Cap-Clug/calendar/14802573) so that we know how much food and beverage to provide. If we're lucky we will get a live performance of the hit single, *Land of Lisp*! (music video at http://landoflisp.com) -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: LabREPL status ... github returning 404's
That's right - but I'm happy they are back up. I was in the middle of working for something requiring the clj-time library, and all of a sudden GitHub starts reporting it's missing. I was thinking, wow, did the author suddenly decided to take to the hills, like someone once did (in the Rails community) and erased all of his repos :) Then I saw all my account's history and repos were gone, and that was scary. Luckily, twitter quickly revealed to me that they were experiencing problems. Victor On Mon, Nov 15, 2010 at 8:37 AM, Rick Moynihan rick.moyni...@gmail.comwrote: On 15 November 2010 09:46, Rick Moynihan rick.moyni...@gmail.com wrote: On 14 November 2010 20:47, Victor Olteanu bluestar...@gmail.com wrote: Github is down at the moment unfortunately... Ahhh great, it's back up... Looks like github was partially down as other pages were returning for me. I'm guessing this was the cause... https://github.com/blog/744-today-s-outage R. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.comclojure%2bunsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Incorrect behaviour for large s-expressions :(
On Nov 14, 6:48 am, Robert McIntyre r...@mit.edu wrote: So my friend and I were screwing around, battling versions of LISP as nerds are wont to do, when I came across this: (eval `(clojure.core/+ ~@(take 1e4 (iterate inc 1 Invalid method Code length 89884 in class file user$eval13607 This is just trying to evaluate + directly on a bunch of arguments. Common Lisp on my friend's 30 year old Lisp machine does the equivalent of this with ease, even for much larger numbers. As I'm writing this, my friend is rubbing in this in my face by also doing the above with C-LISP on his laptop. (although his stack overflows for 1e5) I'm losing my battle!!! :( Pls. help! It's not a CL vs Clojure issue, rather a typical-CL-implementation vs JVM, as you're hitting the JVM method size limit (64K iirc). For example ABCL is a Common Lisp targeting the JVM and it has the same problem, not with eval but with files containing many functions (since it generates one big loader method for the whole file, and if there are a lot of functions in the file, that method becomes too big). Of course, since Clojure is strongly tied to the JVM, while CL is an open standard with multiple implementations, your friend is not completely wrong ;) -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Clojure typing test
On 15 November 2010 16:08, David Sletten da...@bosatsu.net wrote: The StackOverflowError jumps over the lazy seq. The quick, brown StackOverflowError jumps over the lazy seq? -- Michael Wood esiot...@gmail.com -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Function Design: sequence or argument?
If you have a function that needs to treat multiple arguments as a group, what forces drive you to represent this as a single sequence argument vs. an argument? To give a concrete example, why does + work like (+ 1 2 3 4) instead of (+ [1 2 3 4]) Is it performance? Aesthetics? Composability concerns? Not having to call apply all the time? Thanks, 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 Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: REQUEST for feedback on http://clojure.org
Hi Alex, I have one more Clojure Group for you: The Manchester (UK) Clojure Dojo http://manchester.clojuredojo.com/ I'm currently in the process of organising our next meeting, but a link on the clojure.org website would be appreciated. R. On 31 October 2010 02:38, Alex Miller alexdmil...@yahoo.com wrote: Hi all, I'm doing a bit of doc cleanup on http://clojure.org and I'd welcome your feedback on things that are broken or could be improved. I'm not looking (or likely authorized :) to make any drastic changes but if there are things that you have run into, please drop a line here or in email to alexdmiller at yahoo.com. Ideally, I'd like people to be logging tickets in jira, but I'm not sure it's quite ready for that yet. Some recent changes I've already made: - switched all of the old richhickey github references to clojure - cleaned up some factually wrong or out of date stuff on getting started and download pages - added Protocol and Datatypes pages to left nav (the pages have existed for 6 months) - added a page on starting a user group (still in review, not yet linked) - currently working on updating the cheat sheet to the 1.2 version (and adding links!) I'm particularly interested in: - new user groups or suggestions for the community page - stuff that is just wrong or out of date This DOES NOT include stuff in the API or Contrib autodoc pages. Please raise those issues or file tickets on those but that's not what I'm focusing on at the moment. Alex -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- Rick Moynihan http://twitter.com/RickMoynihan http://delicious.com/InkyHarmonics http://sourcesmouth.co.uk/ -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: shorter alternatives for `comp' and `partial'
I think comp is nice and short, personally. Partial is okay, and the long name helps discourage me from using it when I should be using #() instead - partial is a bit slower. And if you find yourself wanting to nest #() forms, it's not that bad to switch to partial, and it may serve as a warning sign that what you're doing should be multiple expressions anyway. The one that bugs me is complement - such a long name for a commonly- useful function. I often wind up defining ! as an alias for complement, but maybe others will think that is poor style. I like it because ! is already well-associated with inversion from the C family of languages so there's little risk of forgetting the name, and it saves a lot more space than aliasing comp. On Nov 13, 10:33 pm, Eric Schulte schulte.e...@gmail.com wrote: Hi, I find myself frequently using the `comp' and `partial' functions and while I really enjoy being able to program in a point free style, the length (in characters) of these command names often has the effect of causing what should be a brief statement to span multiple lines. I'm about to begin starting all of my clojure namespaces with (def o comp) ; o for cOmp, Haskell's (.) or Mathematical composition \circ (def p partial) ; p for partial However, I'm worried that this could limit the readability of my code, and given that this issue has (sort of) come up previously [1] [2], I figured I'd ask... Is there any support for including these function aliases for `comp' and `partial' (or some other shortened names) in the core? Best -- Eric Footnotes: [1] http://groups.google.com/group/clojure/msg/f41f9866dc736077 [2] http://groups.google.com/group/clojure/msg/29ce4786c9cef754 -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Incorrect behaviour for large s-expressions :(
On Nov 13, 11:48 pm, Robert McIntyre r...@mit.edu wrote: So my friend and I were screwing around, battling versions of LISP as nerds are wont to do, when I came across this: (eval `(clojure.core/+ ~@(take 1e4 (iterate inc 1 Invalid method Code length 89884 in class file user$eval13607 This is just trying to evaluate + directly on a bunch of arguments. Common Lisp on my friend's 30 year old Lisp machine does the equivalent of this with ease, even for much larger numbers. As I'm writing this, my friend is rubbing in this in my face by also doing the above with C-LISP on his laptop. (although his stack overflows for 1e5) I'm losing my battle!!! :( Pls. help! --Robert McIntyre Well, assuming the memory is available, at least Clojure is guaranteed to support vectors with more than 1024 elements... -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: LabREPL status ... github returning 404's
On Mon, Nov 15, 2010 at 10:21 AM, Victor Olteanu bluestar...@gmail.com wrote: That's right - but I'm happy they are back up. I was in the middle of working for something requiring the clj-time library, and all of a sudden GitHub starts reporting it's missing. I was thinking, wow, did the author suddenly decided to take to the hills, like someone once did (in the Rails community) and erased all of his repos :) Then I saw all my account's history and repos were gone, and that was scary. Luckily, twitter quickly revealed to me that they were experiencing problems. Security problems, sounds like. A normal server outage results in timeouts, not 404s. On the other hand, someone deleting all the files results in 404s. Good thing they had offline backups. Let's just hope they're using JDBC prepared statements that automatically quote their own arguments the *next* time someone tries to sign up there as joe_douche';DELETE * FROM cms_web_content. :) -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Function Design: sequence or argument?
On Mon, Nov 15, 2010 at 11:52 AM, Chris christopher.ma...@gmail.com wrote: If you have a function that needs to treat multiple arguments as a group, what forces drive you to represent this as a single sequence argument vs. an argument? To give a concrete example, why does + work like (+ 1 2 3 4) instead of (+ [1 2 3 4]) Is it performance? Aesthetics? Composability concerns? Not having to call apply all the time? Not having to use extra brackets all the time gets my vote. Yeah, yeah, I know, a strange statement coming from a lisp-head. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Clojure typing test
On Mon, Nov 15, 2010 at 10:52 AM, Michael Wood esiot...@gmail.com wrote: On 15 November 2010 16:08, David Sletten da...@bosatsu.net wrote: The StackOverflowError jumps over the lazy seq. The quick, brown StackOverflowError jumps over the lazy seq? The reversible, associative vector jumps over the lazy seq ... for certain algorithms, anyway. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: shorter alternatives for `comp' and `partial'
On Mon, Nov 15, 2010 at 1:26 PM, Alan a...@malloys.org wrote: I think comp is nice and short, personally. Partial is okay, and the long name helps discourage me from using it when I should be using #() instead - partial is a bit slower. And if you find yourself wanting to nest #() forms, it's not that bad to switch to partial, and it may serve as a warning sign that what you're doing should be multiple expressions anyway. Or at least using (fn [...] ...). Sometimes I use that over #() even under other circumstances, particularly if I feel it enhances readability a lot to name the thing's parameters. Even if they're [k v] rather than [farads ohms] that still communicates more than [%1 %2]. Another obvious use case for (fn [...] ...) is when you want to destructure one or more of the arguments. The one that bugs me is complement - such a long name for a commonly- useful function. I often wind up defining ! as an alias for complement, but maybe others will think that is poor style. It fits the C family of languages, but doesn't fit the names ending with ! mutate something and are called for their side effects Clojure idiom. How about ~? Oh yeah, taken already for the syntax-unquote reader macro. I'd probably settle for some shorter English name, say (def flip complement). Another good choice might be neg. Those lucky bastards in the far east can of course get away with 補充. :) -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Function Design: sequence or argument?
Hi, Am 15.11.2010 um 17:52 schrieb Chris: If you have a function that needs to treat multiple arguments as a group, what forces drive you to represent this as a single sequence argument vs. an argument? To give a concrete example, why does + work like (+ 1 2 3 4) instead of (+ [1 2 3 4]) Is it performance? Aesthetics? Composability concerns? Not having to call apply all the time? Semantics? + is a binary operator. Allowing more arguments is a convenience I guess. The mathematically honest definition would have arity 2. Eg. filter on the other hand acts on a sequence. That's why it is not defined as (filter even? 1 2 3 4). (See also map for example where apply wouldn't help.) Does this make sense? 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 Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Function Design: sequence or argument?
Performance is part of it too. Allowing dispatch on arity leads to faster code. Many of the functions that operate on sequences are lazy so dispatch on arity doesn't apply. On Nov 15, 11:52 am, Chris christopher.ma...@gmail.com wrote: If you have a function that needs to treat multiple arguments as a group, what forces drive you to represent this as a single sequence argument vs. an argument? To give a concrete example, why does + work like (+ 1 2 3 4) instead of (+ [1 2 3 4]) Is it performance? Aesthetics? Composability concerns? Not having to call apply all the time? Thanks, 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 Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Incorrect behaviour for large s-expressions :(
I'm building an ETL app, so aggregate functions of arbitrarily large arity is a necessity. I've had to wrap a lot of core clojure functions with concrete arg lists to make them work with lazy sequences. In my limited experience, machine generated code of this nature should use lazy sequences that get realized at eval-time rather with arg lists that are realized compile-time. Keep in mind that currently, functions are subclasses of AFunction where constants are stored in the class file as static final class members. This may eventually get optimized, but I wouldn't hold my breath; it would take a LOT of static analysis to recognize closures, and this level of support for macros will probably never happen. Each function eats up your permgen. Garbage collection of classes vs. objects is also REALLY tricky. So you're probably better off using sequences that consume plain old heap and functions that don't close over things so you use less permgen space. So yes, I don't think this is worth getting worked up about. On Nov 14, 9:13 pm, David Nolen dnolen.li...@gmail.com wrote: On Sun, Nov 14, 2010 at 4:21 PM, Robert McIntyre r...@mit.edu wrote: That is not in fact an adequate workaround --- (eval `(apply + ~@(take 9001 (iterate inc 1 ;; OVER 9000!!! or, alternately (eval (cons 'apply (cons '+ (take 9001 (iterate inc 1) will fail just as in the addition examples. It's not true that you can just use an apply in your auto generated code, you would instead have to do something like a tree of function calls, so It may be worth increasing the limit for for the sake of enabling machine generated code. What are you peoples' thoughts on this? --Robert McIntyre Not worth getting worked up. David- Hide quoted text - - Show quoted text - -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Incorrect behaviour for large s-expressions :(
On 15 Nov, 19:34, Brian Goslinga quickbasicg...@gmail.com wrote: Well, assuming the memory is available, at least Clojure is guaranteed to support vectors with more than 1024 elements... Unfair comparison. Clojure is not a standard, it's an implementation. SBCL is guaranteed to support vectors with 1024 elements too, for example. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: shorter alternatives for `comp' and `partial'
On Mon, Nov 15, 2010 at 10:26 AM, Alan a...@malloys.org wrote: The one that bugs me is complement - such a long name for a commonly- useful function. I often wind up defining ! as an alias for complement, but maybe others will think that is poor style. Possibly because bang functions indicate Here be dragons in terms of mutating state? e.g., set! Are you really using complement a lot? I guess I would define an alias for the complement-ed function or use not in expressions... -- Sean A Corfield -- (904) 302-SEAN Railo Technologies, Inc. -- http://getrailo.com/ An Architect's View -- http://corfield.org/ If you're not annoying somebody, you're not really alive. -- Margaret Atwood -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Closures eat permgen?
If you look at the bytecode for the closures, you'll see that the Var that *ns*/a points to is resolved at clinit time, and the Java reference is stored as a static final class member. That's a small use of additional permgen. In your example, my-generator isn't the concern. It's the call to my- generator that creates functions, each of which creates bytecode, is loaded as a class, then is instantiated, and finally invoked. That temporarily uses permgen. There should be no problem collecting permgen in this trivial example. However, more complex scenarios will cause classes to live far beyond you would expect. If there is a leak or long-lived object, you'd rather it be in the regular heap instead. My point in the other thread was more of a question of using closures at all vs. not using closures. All functions lead to a loaded class, which by definition uses permgen. Unless there's a real win in terms of design or maintainability, you should use regular functions and just pass in your state/identity. The use case in the other thread was a bad one as far as using closures go; I was recommending against that. On Nov 15, 2:52 pm, Ken Wesson kwess...@gmail.com wrote: In another thread, someone just indicated that a closed-over variable chews up permgen. Is this true? I had been under the impression that keywords didn't get garbage-collected, so runtime generation with (keyword foo) ought to be used sparingly, but that was it. Perhaps the scenario was something along the lines of (defn make-generator [] (let [a (atom 0)] (fn [] (swap! a inc) @a))) (def my-generator (make-generator)) user= (my-generator) 1 user= (my-generator) 2 user= In this case, a closed-over atom is referenced by a function that's bound to a global var, my-generator. This won't be garbage-collected so long as my-generator isn't un/redef'd. Even so it shouldn't be permgen, technically speaking; just indirectly referenced by a loaded class and so ineligible for GC by more ordinary criteria. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Dependency between files problem
File example\some.clj (ns example.some (:use example.someother)) (defn helloworld [] (print helloworld)) File example\someother.clj: (ns example.someother (:use example.some)) (defn sample [] (helloworld)) A compile error Unable to resolve helloworld in this context is produced (on either latest clojure-maven-plugin or Leiningen). If the two defn's are switched places, the build completes successfully. This is very basic functionality but after thinking a lot, I still see no reason why it isn't working. What am I getting wrong? Clojure 1.2. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: REQUEST for feedback on http://clojure.org
Done. On Nov 15, 12:21 pm, Rick Moynihan rick.moyni...@gmail.com wrote: Hi Alex, I have one more Clojure Group for you: The Manchester (UK) Clojure Dojo http://manchester.clojuredojo.com/ I'm currently in the process of organising our next meeting, but a link on the clojure.org website would be appreciated. R. On 31 October 2010 02:38, Alex Miller alexdmil...@yahoo.com wrote: Hi all, I'm doing a bit of doc cleanup onhttp://clojure.organd I'd welcome your feedback on things that are broken or could be improved. I'm not looking (or likely authorized :) to make any drastic changes but if there are things that you have run into, please drop a line here or in email to alexdmiller at yahoo.com. Ideally, I'd like people to be logging tickets in jira, but I'm not sure it's quite ready for that yet. Some recent changes I've already made: - switched all of the old richhickey github references to clojure - cleaned up some factually wrong or out of date stuff on getting started and download pages - added Protocol and Datatypes pages to left nav (the pages have existed for 6 months) - added a page on starting a user group (still in review, not yet linked) - currently working on updating the cheat sheet to the 1.2 version (and adding links!) I'm particularly interested in: - new user groups or suggestions for the community page - stuff that is just wrong or out of date This DOES NOT include stuff in the API or Contrib autodoc pages. Please raise those issues or file tickets on those but that's not what I'm focusing on at the moment. Alex -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- Rick Moynihanhttp://twitter.com/RickMoynihanhttp://delicious.com/InkyHarmonicshttp://sourcesmouth.co.uk/ -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Closures eat permgen?
On Nov 15, 12:12 pm, Alyssa Kwan alyssa.c.k...@gmail.com wrote: In your example, my-generator isn't the concern. It's the call to my- generator that creates functions, each of which creates bytecode, is loaded as a class, then is instantiated, and finally invoked. Not true. Compiling my-generator creates two classes, which at run time are simply instantiated as needed. Here's an example: (ns permgen.core (:gen-class)) (defn -my-generator [] (let [x (atom 0)] (fn [] (swap! x inc (dotimes [_ 1000] (-my-generator)) $ cake compile ls classes/permgen/* classes/permgen/core.class classes/permgen/core__init.class classes/permgen/core$loading__4410__auto__.class classes/permgen/core$_my_generator.class classes/permgen/core$_my_generator$fn__2474.class -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Performance of seq on empty collections
Yes, the API *does* suggest using seq to check for emptiness. (empty? x) is implemented as (not (seq x)). You certainly won't ever get improved performance by using empty? - at best you break even, most of the time you lose. For example: (if (empty? x) ; empty branch ; not-empty branch Can be replaced with (if (seq x) ; not-empty branch ; empty branch This is usually more readable, since the empty case tends to be less interesting. Further, you usually have to seq the object anyway if it's not empty, so the seq call becomes free except in the case where the collection is in fact empty: (if-let [x (seq x)] ; do stuff with x ; give up compared to: (if (not (seq x)) ; this is what empty? does ; give up (let [useful-var (seq x)] ; do stuff with useful, seq'd version of x Of course performance isn't usually the main driver, so if you feel empty? really is more expressive in your case, go for it. But the OP seems to care about performance, and suggesting empty? is off the mark. On Nov 14, 11:42 am, David Sletten da...@bosatsu.net wrote: On Nov 14, 2010, at 2:16 PM, Eric Kobrin wrote: In the API it is suggested to use `seq` to check if coll is empty. Your timing results raise some interesting questions, however, the API doesn't suggest using 'seq' to check if a collection is empty. That's what 'empty?' is for. The documentation note suggests (for style purposes apparently) that you use 'seq' to test that the collection is not empty. So to be precise you are testing two different things below. For instance, (identical? coll []) is true when coll is an empty vector. (seq coll) is true when coll is not empty. The correct equivalent would be to test (empty? coll). Of course, this doesn't change the results. I get similar timings with empty?: user= (let [iterations 1] (time (dotimes [_ iterations] (identical? [] []))) (time (dotimes [_ iterations] (empty? [] Elapsed time: 2.294 msecs Elapsed time: 2191.256 msecs nil user= (let [iterations 1] (time (dotimes [_ iterations] (identical? ))) (time (dotimes [_ iterations] (empty? Elapsed time: 2.657 msecs Elapsed time: 4654.622 msecs nil user= (let [iterations 1] (time (dotimes [_ iterations] (identical? () ( (time (dotimes [_ iterations] (empty? () Elapsed time: 2.608 msecs Elapsed time: 2144.142 msecs nil This isn't so surprising though, considering that 'identical?' is the simplest possible test you could try--do two references point to the same object in memory? It can't get any more efficient than that. Have all good days, David Sletten I was working on some code recently found that my biggest performance bottleneck was calling `seq` to check for emptiness. The calls to `seq` were causing lots of object allocation and taking noticeable CPU time. I switched to using `identical?` to explicitly compare against the empty vector and was rewarded with a drastic reduction in execution time. Here are some hasty tests showing just how big the difference can be: user= (let [iterations 1] (time (dotimes [_ iterations] (identical? [] []))) (time (dotimes [_ iterations] (seq [] Elapsed time: 3.512 msecs Elapsed time: 2512.366 msecs nil user= (let [iterations 1] (time (dotimes [_ iterations] (identical? ))) (time (dotimes [_ iterations] (seq Elapsed time: 3.898 msecs Elapsed time: 5607.865 msecs nil user= (let [iterations 1] (time (dotimes [_ iterations] (identical? () ( (time (dotimes [_ iterations] (seq () Elapsed time: 3.768 msecs Elapsed time: 2258.095 msecs nil Has any thought been given to providing a faster `empty?` that is not based on seq? Thanks, Eric Kobrin -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post.
Re: Performance of seq on empty collections
On Nov 15, 2010, at 4:41 PM, Alan wrote: Yes, the API *does* suggest using seq to check for emptiness. (empty? x) is implemented as (not (seq x)). You certainly won't ever get improved performance by using empty? - at best you break even, most of the time you lose. For example: The only way the API could suggest using 'seq' to check for emptiness is by not having a function called 'empty?'. It's irrelevant that 'empty?' is merely implemented as (not (seq)). The function is there for a reason. Are you suggesting that it's deprecated? If you would like to focus on a premature optimization of this sort, go right ahead. I will stick with the more meaningful function name. If I'm testing whether or not a sequence is empty I will use 'empty?'. Of course performance isn't usually the main driver, so if you feel empty? really is more expressive in your case, go for it. But the OP seems to care about performance, and suggesting empty? is off the mark. Apparently you didn't read what I wrote. I didn't suggest that using 'empty?' would solve the OP's performance issue. I simply pointed out that he was testing two opposite things. On Nov 14, 11:42 am, David Sletten da...@bosatsu.net wrote: On Nov 14, 2010, at 2:16 PM, Eric Kobrin wrote: In the API it is suggested to use `seq` to check if coll is empty. Your timing results raise some interesting questions, however, the API doesn't suggest using 'seq' to check if a collection is empty. That's what 'empty?' is for. The documentation note suggests (for style purposes apparently) that you use 'seq' to test that the collection is not empty. So to be precise you are testing two different things below. For instance, (identical? coll []) is true when coll is an empty vector. (seq coll) is true when coll is not empty. The correct equivalent would be to test (empty? coll). Of course, this doesn't change the results. I get similar timings with empty?: user= (let [iterations 1] (time (dotimes [_ iterations] (identical? [] []))) (time (dotimes [_ iterations] (empty? [] Elapsed time: 2.294 msecs Elapsed time: 2191.256 msecs nil user= (let [iterations 1] (time (dotimes [_ iterations] (identical? ))) (time (dotimes [_ iterations] (empty? Elapsed time: 2.657 msecs Elapsed time: 4654.622 msecs nil user= (let [iterations 1] (time (dotimes [_ iterations] (identical? () ( (time (dotimes [_ iterations] (empty? () Elapsed time: 2.608 msecs Elapsed time: 2144.142 msecs nil This isn't so surprising though, considering that 'identical?' is the simplest possible test you could try--do two references point to the same object in memory? It can't get any more efficient than that. Have all good days, David Sletten I was working on some code recently found that my biggest performance bottleneck was calling `seq` to check for emptiness. The calls to `seq` were causing lots of object allocation and taking noticeable CPU time. I switched to using `identical?` to explicitly compare against the empty vector and was rewarded with a drastic reduction in execution time. Here are some hasty tests showing just how big the difference can be: user= (let [iterations 1] (time (dotimes [_ iterations] (identical? [] []))) (time (dotimes [_ iterations] (seq [] Elapsed time: 3.512 msecs Elapsed time: 2512.366 msecs nil user= (let [iterations 1] (time (dotimes [_ iterations] (identical? ))) (time (dotimes [_ iterations] (seq Elapsed time: 3.898 msecs Elapsed time: 5607.865 msecs nil user= (let [iterations 1] (time (dotimes [_ iterations] (identical? () ( (time (dotimes [_ iterations] (seq () Elapsed time: 3.768 msecs Elapsed time: 2258.095 msecs nil Has any thought been given to providing a faster `empty?` that is not based on seq? Thanks, Eric Kobrin -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups Clojure group. To post
Re: Dependency between files problem
On Mon, Nov 15, 2010 at 11:35 AM, trying clj trying...@gmail.com wrote: A compile error Unable to resolve helloworld in this context is produced (on either latest clojure-maven-plugin or Leiningen). If the two defn's are switched places, the build completes successfully. This is very basic functionality but after thinking a lot, I still see no reason why it isn't working. What am I getting wrong? Circular dependencies are not allowed. The problem is that the compiler gives you an unhelpful message. This issue is actually as old as the hills (pre-1.0), though there has been a patch submitted recently that fixes it: http://dev.clojure.org/jira/browse/CLJ-8 Just waiting for that to get applied. -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 Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Dependency between files problem
On Mon, Nov 15, 2010 at 2:35 PM, trying clj trying...@gmail.com wrote:
File example\some.clj
(ns example.some (:use example.someother))
(defn helloworld [] (print helloworld))
File example\someother.clj:
(ns example.someother (:use example.some))
(defn sample [] (helloworld))
A compile error Unable to resolve helloworld in this context is produced
(on either latest clojure-maven-plugin or Leiningen). If the two defn's are
switched places, the build completes successfully.
This is very basic functionality but after thinking a lot, I still see no
reason why it isn't working. What am I getting wrong?
Probably in one case it was compiling the file with sample before the
file with helloworld. Be glad this example doesn't have a true
circular dependency.
I have sometimes resorted to atom to get rid of circular dependencies:
file1.clj:
(defvar- foo (atom nil))
(defn some-fn [...]
...
(do-something-with @foo)
...)
(defn set-foo! [x]
(reset! foo x))
file2.clj:
(defn some-other-fn [...]
...
(some-fn some-args)
...)
(defn init-file2 []
(set-foo! [some-data-structure-built-using-some-other-fn]))
filen.clj:
(defn main- [...]
(init-file2)
...)
Obviously in this example some-fn ought to have some way to be
somewhat useful if the atom's still its initial value, here nil. A
case that comes up sometimes is a lookup table, in which case starting
it with an empty map {} makes sense. The most recent case where I did
something like this, foo was a large data structure that had to hold
functions that called functions that called functions that,
eventually, referenced the data structure. None of these functions
would actually get *called* until bootstrap was complete, so they'd
never see the atom holding nil, but fn1 calls fn2 calls fn3 calls fn4
references foo contains fn1 is still a circular dependency.
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
help to improve a multimethod with a vaguely interesting dispatch function
Hi, I'm trying to work out a way to define a multimethod dispatch function that will allow me to make a decision based on two values. In the example below I'm using symbols for the values of the major and minor values, mostly for convenience. What I'm trying to do is dispatch a multifunction on both values if the method exists, on the major value alone if it exists, and to the default if there's still no method. Can anyone see a better way of doing this? Thanks, Bob (declare can-we-not-do-better-dispatcher) (defmulti can-we-not-do-better (fn [major minor] (can-we-not-do-better-dispatcher major minor))) (remove-all-methods can-we-not-do-better) (defmethod can-we-not-do-better :default [major minor](str default-default - major minor)) (defmethod can-we-not-do-better :one [major minor](str one-default - major minor)) (defmethod can-we-not-do-better [:one :two] [major minor] (str one-two - major minor)) (defn can-we-not-do-better-dispatcher [major minor] (let [method-map (methods can-we-not-do-better)] (or (and (get method-map [major minor]) [major minor]) (and (get method-map major) major) :default))) (defn play [] (println (can-we-not-do-better :zero :zero)) (println (can-we-not-do-better :one :two)) (println (can-we-not-do-better :one :three))) (play) default-default - :zero:zero one-two - :one:two one-default - :one:three Bob Hutchison Recursive Design Inc. http://www.recursive.ca/ weblog: http://xampl.com/so -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Closures eat permgen?
On Mon, Nov 15, 2010 at 4:24 PM, Alan a...@malloys.org wrote: On Nov 15, 12:12 pm, Alyssa Kwan alyssa.c.k...@gmail.com wrote: In your example, my-generator isn't the concern. It's the call to my- generator that creates functions, each of which creates bytecode, is loaded as a class, then is instantiated, and finally invoked. Not true. Compiling my-generator creates two classes, which at run time are simply instantiated as needed. I thought so. Now if your code has stuff like: (defn foo [x] (eval `(fn [quux] blah blah blah quux blah blah ~x blah))) then every call to foo generates new classes and loads them at runtime. Part of why eval should be used sparingly. :) -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Performance of seq on empty collections
On Mon, Nov 15, 2010 at 4:41 PM, Alan a...@malloys.org wrote: Yes, the API *does* suggest using seq to check for emptiness. (empty? x) is implemented as (not (seq x)). You certainly won't ever get improved performance by using empty? - at best you break even, most of the time you lose. For example: (if (empty? x) ; empty branch ; not-empty branch Can be replaced with (if (seq x) ; not-empty branch ; empty branch This is usually more readable, since the empty case tends to be less interesting. I disagree. I tend to prefer to front-load the empty case, because it's usually the base case of a (recur)sion. Getting it out of the way quickly and early establishes both how the result is generated and the semantics of many of the loop variables. More generally, I like to test for, handle, and discard the corner/special cases and quickie cases and then have the meat of the function last. It gets the distractions out of the way to focus on the main, common case (in loops, the iteration rather than the termination). Further, you usually have to seq the object anyway if it's not empty, so the seq call becomes free except in the case where the collection is in fact empty: (if-let [x (seq x)] ; do stuff with x ; give up compared to: (if (not (seq x)) ; this is what empty? does ; give up (let [useful-var (seq x)] ; do stuff with useful, seq'd version of x Funny. My own use cases tend not to use seq explicitly at all. I'm likely to have e.g. (loop [s some-coll o nil] (if (empty? s) o (let [f (first s)] (blah blah blah s blah blah blah f blah blah blah) (recur (rest s) (conj o foobar) or some similar control flow structure, where s gets first and rest used on it, but not (directly) seq. If some-coll is not already a seq, using these implicitly generates a seq view of it with seq; on every iteration but the first, s is bound to a seq implementation already. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Performance of seq on empty collections
Hi, Am 15.11.2010 um 23:07 schrieb Ken Wesson: (loop [s some-coll o nil] (if (empty? s) o (let [f (first s)] (blah blah blah s blah blah blah f blah blah blah) (recur (rest s) (conj o foobar) or some similar control flow structure, where s gets first and rest used on it, but not (directly) seq. If some-coll is not already a seq, using these implicitly generates a seq view of it with seq; on every iteration but the first, s is bound to a seq implementation already. Changing the above code to the following (which is similarly readable) should give an immediate speed bump. Rich once stated something around 20%, although I have not verified the numbers and this was quite a while ago... (loop [s (seq some-coll) o nil] (if s (let [f (first s)] (bla bla bla f bla bla bla) (recur (next s) (conj o foobar))) o)) 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 Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: shorter alternatives for `comp' and `partial'
Coming from Haskell, where composition and partial functions are cheap and free in terms of character count, it is actually pretty discouraging to have to spell it out in Clojure for the same effect. Some of the cases where you should be using multiple expressions in Clojure would be perfectly clear in Haskell as one expression... On Mon, Nov 15, 2010 at 11:37 AM, Sean Corfield seancorfi...@gmail.comwrote: On Mon, Nov 15, 2010 at 10:26 AM, Alan a...@malloys.org wrote: The one that bugs me is complement - such a long name for a commonly- useful function. I often wind up defining ! as an alias for complement, but maybe others will think that is poor style. Possibly because bang functions indicate Here be dragons in terms of mutating state? e.g., set! Are you really using complement a lot? I guess I would define an alias for the complement-ed function or use not in expressions... -- Sean A Corfield -- (904) 302-SEAN Railo Technologies, Inc. -- http://getrailo.com/ An Architect's View -- http://corfield.org/ If you're not annoying somebody, you're not really alive. -- Margaret Atwood -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.comclojure%2bunsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: shorter alternatives for `comp' and `partial'
I think the minimal character count for composition and partial functions in haskell are some of the reasons that haskell code is so impenetrable to non-haskell hackers. Feel free to rig up crazy unicode characters to any identifier you want in your own code, just don't ask me to read or debug any of it. On Nov 15, 2010, at 2:12 PM, Paul Hobbs wrote: Coming from Haskell, where composition and partial functions are cheap and free in terms of character count, it is actually pretty discouraging to have to spell it out in Clojure for the same effect. Some of the cases where you should be using multiple expressions in Clojure would be perfectly clear in Haskell as one expression... On Mon, Nov 15, 2010 at 11:37 AM, Sean Corfield seancorfi...@gmail.com wrote: On Mon, Nov 15, 2010 at 10:26 AM, Alan a...@malloys.org wrote: The one that bugs me is complement - such a long name for a commonly- useful function. I often wind up defining ! as an alias for complement, but maybe others will think that is poor style. Possibly because bang functions indicate Here be dragons in terms of mutating state? e.g., set! Are you really using complement a lot? I guess I would define an alias for the complement-ed function or use not in expressions... -- Sean A Corfield -- (904) 302-SEAN Railo Technologies, Inc. -- http://getrailo.com/ An Architect's View -- http://corfield.org/ If you're not annoying somebody, you're not really alive. -- Margaret Atwood -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Performance of seq on empty collections
On Mon, Nov 15, 2010 at 6:49 PM, Meikel Brandmeyer m...@kotka.de wrote: Changing the above code to the following (which is similarly readable) should give an immediate speed bump. Rich once stated something around 20%, although I have not verified the numbers and this was quite a while ago... (loop [s (seq some-coll) o nil] (if s (let [f (first s)] (bla bla bla f bla bla bla) (recur (next s) (conj o foobar))) o)) Eh. I'd heard first and rest had replaced next. No? -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: REQUEST for feedback on http://clojure.org
The main page link to API is a little confusing/annoying. I expect it to go here: http://clojure.org/api ( I expect this because doing a google search on clojure api brings it up) However the main page link to API goes directly to here: http://clojure.github.com/clojure/ It's kind of annoying/confusing to new users, maybe instead have 2 links on the main page? - Clojure API - Clojure Contrib API Tim On Oct 30, 7:38 pm, Alex Miller alexdmil...@yahoo.com wrote: Hi all, I'm doing a bit of doc cleanup onhttp://clojure.organd I'd welcome your feedback on things that are broken or could be improved. I'm not looking (or likely authorized :) to make any drastic changes but if there are things that you have run into, please drop a line here or in email to alexdmiller at yahoo.com. Ideally, I'd like people to be logging tickets in jira, but I'm not sure it's quite ready for that yet. Some recent changes I've already made: - switched all of the old richhickey github references to clojure - cleaned up some factually wrong or out of date stuff on getting started and download pages - added Protocol and Datatypes pages to left nav (the pages have existed for 6 months) - added a page on starting a user group (still in review, not yet linked) - currently working on updating the cheat sheet to the 1.2 version (and adding links!) I'm particularly interested in: - new user groups or suggestions for the community page - stuff that is just wrong or out of date This DOES NOT include stuff in the API or Contrib autodoc pages. Please raise those issues or file tickets on those but that's not what I'm focusing on at the moment. Alex -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Performance of seq on empty collections
On Mon, Nov 15, 2010 at 5:31 PM, Ken Wesson kwess...@gmail.com wrote: Eh. I'd heard first and rest had replaced next. No? rest and next do different things: rest - Returns a possibly empty seq of the items after the first. Calls seq on its argument. next - Returns a seq of the items after the first. Calls seq on its argument. If there are no more items, returns nil. -- Sean A Corfield -- (904) 302-SEAN Railo Technologies, Inc. -- http://getrailo.com/ An Architect's View -- http://corfield.org/ If you're not annoying somebody, you're not really alive. -- Margaret Atwood -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: (:multiplexing clojure.contrib.sql = nil?)
I may be using the term wrong; while concurrency isn't necessary, I'm really just looking to minimize the # of times I'm opening/closing connections, but also looking to minimize unnecessary open connections. I suspect what I'm really looking for is a macro to detect every instance of (sql/with-connection in a form, delete them all, and then wrap them in one with-connection form. Which probably means I should get to writing it myself. But if anyone knows of one already in existence, I'm all ears. Cheers, Daniel On Nov 13, 11:30 pm, Shantanu Kumar kumar.shant...@gmail.com wrote: Not sure what you meant by multiplexing? Did you mean concurrent execution of SQL statements on the same connection? Regards, Shantanu On Nov 14, 4:00 am, Daniel Bell dchristianb...@gmail.com wrote: I'm just getting my feet wet w/clojure's sql library, and I got to wondering---is multiplexing implemented in a library somewhere? Or is it already part of contrib.sql but executed behind the scenes? Thanks, ---Dan -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Closures eat permgen?
I totally misunderstood the role of the EVAL context flag in the compile method of ObjExpr. Is there a general writeup anywhere of how the compiler works, especially the interaction of parse and emit? On Nov 15, 4:59 pm, Ken Wesson kwess...@gmail.com wrote: On Mon, Nov 15, 2010 at 4:24 PM, Alan a...@malloys.org wrote: On Nov 15, 12:12 pm, Alyssa Kwan alyssa.c.k...@gmail.com wrote: In your example, my-generator isn't the concern. It's the call to my- generator that creates functions, each of which creates bytecode, is loaded as a class, then is instantiated, and finally invoked. Not true. Compiling my-generator creates two classes, which at run time are simply instantiated as needed. I thought so. Now if your code has stuff like: (defn foo [x] (eval `(fn [quux] blah blah blah quux blah blah ~x blah))) then every call to foo generates new classes and loads them at runtime. Part of why eval should be used sparingly. :) -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Performance of seq on empty collections
Hi, On 16 Nov., 02:31, Ken Wesson kwess...@gmail.com wrote: Eh. I'd heard first and rest had replaced next. No? No. This was a misinformation. To elaborate a bit more on the differences pointed out by Sean: next returns nil if there are no more items in the sequence, which is nice to use in if and when statements to test for emptiness. However in order to be able to return nil the sequence has to be realised. Otherwise you can't know whether to return nil or not. So next is non- lazy of order 1 so to say. To allow full laziness lazy-seq was introduced. It returns an object which doesn't know directly whether it's empty, but it knows how to find out, when you ask for it. When you know call empty? on the lazy-seq you realise the sequence and the seq call hidden in empty will return most likely a Cons, where first and rest are just field references, or nil of there are no elements in the sequence. But you throw this away. Then you call first on the lazy- seq. first itself calls seq and gets again the now cached Cons. Then you call rest, which calls seq, which returns the cached Cons. A lot of indirection going on. If you handle non-seqs like vectors or maps, you have to replace that with multiple creations of very short-lived objects. This is even more expensive. So you can see, that by capturing the return value of the seq call you can save quite a bit of indirection. Plus seq becomes the identity, which should be fast. I did some quick'n'dirty benchmarking and the improvement seems to be 12% for me. Not tht much, but quite a bit for such trivial changes. user= (bench (loop [s (take 1 (range)) i 0] (if (empty? s) i (recur (rest s) (+ i (first s)) Evaluation count : 8100 Execution time mean : 7,393586 ms 95,0% CI: (7,391431 ms, 7,394906 ms) Execution time std-deviation : 3,062580 ms 95,0% CI: (3,043205 ms, 3,086849 ms) Found 2 outliers in 60 samples (3, %) low-severe 2 (3, %) Variance from outliers : 22,2178 % Variance is moderately inflated by outliers nil user= (bench (loop [s (seq (take 1 (range))) i 0] (if s (recur (next s) (+ i (first s))) i))) Evaluation count : 9840 Execution time mean : 6,502692 ms 95,0% CI: (6,499507 ms, 6,505352 ms) Execution time std-deviation : 3,708928 ms 95,0% CI: (3,687700 ms, 3,731890 ms) nil Hope that helps. 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 Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
bimaps in clojure
Hello everybody, Is there something like a bimap in clojure? I know I can have two regular hash-maps .. but I was wondering if there is a better implementation..? a similar implementation in c++ is http://beta.boost.org/doc/libs/1_41_0/libs/bimap/doc/html/index.html Thanks, Sunil. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: (:multiplexing clojure.contrib.sql = nil?)
The idiomatic JDBC solution to this problem is a DataSource: http://download.oracle.com/javase/6/docs/api/javax/sql/DataSource.html http://bitbucket.org/kumarshantanu/clj-dbcp/src A connection-pooling data source does exactly that - it recycles the connection for many statements. The close() method of the Connection doesn't really close it, but rather puts it back in the pool. Regards Shantanu On Nov 16, 9:44 am, Daniel Bell dchristianb...@gmail.com wrote: I may be using the term wrong; while concurrency isn't necessary, I'm really just looking to minimize the # of times I'm opening/closing connections, but also looking to minimize unnecessary open connections. I suspect what I'm really looking for is a macro to detect every instance of (sql/with-connection in a form, delete them all, and then wrap them in one with-connection form. Which probably means I should get to writing it myself. But if anyone knows of one already in existence, I'm all ears. Cheers, Daniel On Nov 13, 11:30 pm, Shantanu Kumar kumar.shant...@gmail.com wrote: Not sure what you meant by multiplexing? Did you mean concurrent execution of SQL statements on the same connection? Regards, Shantanu On Nov 14, 4:00 am, Daniel Bell dchristianb...@gmail.com wrote: I'm just getting my feet wet w/clojure's sql library, and I got to wondering---is multiplexing implemented in a library somewhere? Or is it already part of contrib.sql but executed behind the scenes? Thanks, ---Dan -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: shorter alternatives for `comp' and `partial'
Well, for those who use emacs, you could always make it *look* like it was pretty... For example: (eval-after-load 'clojure-mode '(font-lock-add-keywords 'clojure-mode `((\\fn\\ (0 (progn (compose-region (match-beginning 0) (match-end 0) ,(make-char 'greek-iso8859-7 107)) ;; a lambda nil))) (\\comp\\ (0 (progn (compose-region (match-beginning 0) (match-end 0) ∘ ) nil))) (\\partial\\ (0 (progn (compose-region (match-beginning 0) (match-end 0) 풫 ))) On Mon, Nov 15, 2010 at 5:19 PM, Cyrus Harmon cyrushar...@gmail.com wrote: I think the minimal character count for composition and partial functions in haskell are some of the reasons that haskell code is so impenetrable to non-haskell hackers. Feel free to rig up crazy unicode characters to any identifier you want in your own code, just don't ask me to read or debug any of it. On Nov 15, 2010, at 2:12 PM, Paul Hobbs wrote: Coming from Haskell, where composition and partial functions are cheap and free in terms of character count, it is actually pretty discouraging to have to spell it out in Clojure for the same effect. Some of the cases where you should be using multiple expressions in Clojure would be perfectly clear in Haskell as one expression... On Mon, Nov 15, 2010 at 11:37 AM, Sean Corfield seancorfi...@gmail.comwrote: On Mon, Nov 15, 2010 at 10:26 AM, Alan a...@malloys.org wrote: The one that bugs me is complement - such a long name for a commonly- useful function. I often wind up defining ! as an alias for complement, but maybe others will think that is poor style. Possibly because bang functions indicate Here be dragons in terms of mutating state? e.g., set! Are you really using complement a lot? I guess I would define an alias for the complement-ed function or use not in expressions... -- Sean A Corfield -- (904) 302-SEAN Railo Technologies, Inc. -- http://getrailo.com/ An Architect's View -- http://corfield.org/ If you're not annoying somebody, you're not really alive. -- Margaret Atwood -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.comclojure%2bunsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.comclojure%2bunsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
