Re: ANN: core.match 0.2.0-alpha5
I'm just following what seemed to be a convention - https://github.com/clojure/core.unify/blob/master/src/main/clojure/clojure/core/unify.clj On Sun, Oct 9, 2011 at 7:17 PM, Alan Malloy a...@malloys.org wrote: On Oct 9, 12:31 pm, David Nolen dnolen.li...@gmail.com wrote: I've removed some fairly big bugs in the algorithm. This will probably the be the last alpha release before I cut a beta. Would love to hear any and all feedback. - clojure.core.match instead of clojure.core.match.core Those both seem weird to me, unless the plan is to make it part of clojure.core eventually. clojure.match is the namespace I would expect to find it under, with clojure.match.core a reasonable second choice. I assume you have a reason, though; would you mind explaining it? -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com 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: ANN: core.match 0.2.0-alpha5
I've come up with some better reasons to return nil. - smaller generated code size - cleaner implementation of which the latter is the most significant. While we're on the topic of conventions, I think the most important convention match is breaking is using the destructuring syntax to mean something less generic by default (only vectors). (match [(list 1 2 3)] [[x xs]] 1) ;; - falls through because [x xs] only matches vectors by default I can see this tripping people up time and time again. Make it correct, then make it fast A wonderful asset of Clojure, is that once it's correct, the fast version is never far away syntactically. I think we should adopt this ideology and default to :seq matching. To make it fast, just add :vector (or matchv). Thanks, Ambrose -- You 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: inconsistent results from String.valueOf
It's precisely the behaviour you would get by calling String.valueOf(null) in java. Nulls match to the most specific parameter type in a given hierarchy, and in this case, that would be char[] instead of Object. If the param types were not in the same hierarchy, say char[] and String, then you'd get an ambiguity exception. -- You 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
ANN: clj-vorbis
Hello all. I have made a small clojure wrapper around the jorbis library from jcraft (for decoding ogg vorbis compressed audio). I'm planning to maybe use it as a component in a small game library but I made it as a stand alone library because it could really be useful in any app dealing with audio. If anyone is interested in something like this, or just interested in optimizing clojure code I would appreciate any comments or suggestions. The interface is pretty low level, it uses bytebuffers and the internals are full of mutable state that is not thread safe. The reasons for this is that audio output APIs can work with bytebuffers and the jorbis library which is used internally contains a lot of mutable state. If anyone has suggestions that can make the code more idiomatic, easier to use or thread safe without making it slower or making it require more memory that would be very welcome. The code is on github: github.com/bagucode/clj-vorbis /Markus -- You 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.contrib.base64
On Sunday, 9 October 2011 19:49:17 UTC-7, Stuart Sierra wrote: Clojure unless somebody clever can make one that's actually *faster* than the best Java lib. Here ya go: https://github.com/ataggart/clojure.data.codec -- You 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: where can I find the official statement about changes from 1.2 to 1.3?
https://github.com/clojure/clojure/blob/1.3.x/changes.txt I think. -- You 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: Macro tutorials?
A good book to learn lisp macros, is On Lisp from Paul Graham. This book really cover advanced topics and concepts, and has many chapters related to macros. The book is freely available in online format from Paul Graham Website: http://www.paulgraham.com/onlisp.html On Oct 6, 1:02 pm, Michael Jaaka michael.ja...@googlemail.com wrote: Thanks to all! You have helped a lot! Also I will consider reading Practical Common Lisp. On Oct 6, 9:42 am, Stefan Kamphausen ska2...@googlemail.com wrote: Hi. You might consider reading Peter Seibel's excellent Practical Common Lisp which has some nice macro-work in it. If after that you're still hungry for more, consider Let Over Lambda by Doug Hoyte. Admitted, both cover Common Lisp, but the differences will not keep you from getting a deeper understanding of how macros work and where and how they can be used. (This is more an answer to the subject of this thread, less to the question in your body :) Regards, Stefan -- You 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.contrib.base64
On Sunday, 9 October 2011 19:49:17 UTC-7, Stuart Sierra wrote: Clojure unless somebody clever can make one that's actually *faster* than the best Java lib. Here ya go: https://github.com/ataggart/clojure.data.codec I owe you a beer for the offset and length args. Thanks! Stu Stuart Halloway Clojure/core http://clojure.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: clojure.contrib.base64
Cool! That would make a sweet example of Clojure is fast at primitives. -S -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com 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: Is there a clojure counterpart for java.lang.String indexOf method?
Thanks for your clarification. On Oct 9, 11:47 pm, Stephen Compall stephen.comp...@gmail.com wrote: On Sun, 2011-10-09 at 07:36 -0700, jingguo wrote: Does clojure has a API for this? I have checked clojure.core and clojure.string. It seems that clojure does not have a counterpart for indexOf. No, it doesn't. There's usually a way to do string operations that you traditionally do with indexOf using other tools like regular expressions; these also have the benefit of helping you avoid fencepost errors. For example, if you wanted all the text before and after 12 in a string, you could match #(?s)(.*?)12(.*). That aside, while the lack of a Clojure-level facility should give you a nudge to consider such alternatives, it's perfectly fine to call Java when needed. -- Stephen Compall ^aCollection allSatisfy: [:each|aCondition]: less is better -- You 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: ANN: core.match 0.2.0-alpha5
On Sun, Oct 9, 2011 at 11:19 PM, Ambrose Bonnaire-Sergeant abonnaireserge...@gmail.com wrote: On Mon, Oct 10, 2011 at 3:31 AM, David Nolen dnolen.li...@gmail.comwrote: - return nil instead of throwing if no match found to mirror the behavior of cond I don't like this. I'm definitely open to talking about it. Strong opinions appreciated :) Why are we emulating cond? clojure.core/case, for example, seems closer to what `match` provides, and that throws an IllegalArgumentException if there is no match. Seems arbitrary to me. Is there more to it? Thanks, Ambrose A good point. I'm mostly thinking about user friendliness here. I'm also OK w/ the idea of providing two versions of match - one w/ verbose error reporting that throws and perhaps the default one that doesn't David -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com 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: ANN: core.match 0.2.0-alpha5
On Mon, Oct 10, 2011 at 3:46 AM, Ambrose Bonnaire-Sergeant abonnaireserge...@gmail.com wrote: While we're on the topic of conventions, I think the most important convention match is breaking is using the destructuring syntax to mean something less generic by default (only vectors). (match [(list 1 2 3)] [[x xs]] 1) ;; - falls through because [x xs] only matches vectors by default We can support this but I'm afraid that it will be very slow. In the presence of rest syntax vector patterns split the data structure into left and right sides. But again, perhaps this is a case of user friendliness and people don't care that much? David -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com 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: ANN: core.match 0.2.0-alpha5
Would supporting other data structures make it slower when using vectors, or only when using non-vector seq's? If it makes it substantially slower across the board, personally I'd still like core.match to support all of clojure's built in data structures; but I could understand why people would have a contrary opinion. If it only makes the non-vector seq case slower, I'd certainly make that an available option - people are going to have to manually convert other sequences into vectors anyway which creates a coding overhead and also makes the code less likely to be JITed. On the other hand.. YMMV. Thanks for all your hard work David, I love core.match. R. On 10 Oct 2011, at 15:14, David Nolen wrote: On Mon, Oct 10, 2011 at 3:46 AM, Ambrose Bonnaire-Sergeant abonnaireserge...@gmail.com wrote: While we're on the topic of conventions, I think the most important convention match is breaking is using the destructuring syntax to mean something less generic by default (only vectors). (match [(list 1 2 3)] [[x xs]] 1) ;; - falls through because [x xs] only matches vectors by default We can support this but I'm afraid that it will be very slow. In the presence of rest syntax vector patterns split the data structure into left and right sides. But again, perhaps this is a case of user friendliness and people don't care that much? David -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com 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
Is clojure.data.json compatible with 1.3?
If not, is there a lib I can leverage for this on 1.3? -- You 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: How to Collapse Nested Map into a Sequence of Flat Maps
Your input isn't a legal Clojure form, and the correlation between
input and output is difficult to spot, so it is hard to guess what you
mean.
Sorry about the malformed map, a correctly formed map follows:
{a {2011 [[a 2011 ari] [a 2011 dan]], 2010 [[a 2010
jon]]}}
Now as for the correlation: the original map is a two-tier map with
the key a on the first tier and keys 2011 and 2010 on the second.
The goal is to collapse the map keys into composite keys and create
new flat maps, i.e.
( { [a 2011] [ [a 2011 ari] [a 2011 dan] ] } , { [a 2010]
[ [a 2010 jon] ] } )
Let's examine the first map in the above sequence of maps.
[a 2011] is a composite key derived from the tiered keys:
{a { 2011 }}
[ [a 2011 ari] [a 2011 dan ] ] is the value corresponding to
the above tiered keys.
Now let's examine the second map in the above sequence of maps.
[a 2011] is a composite key derived from the tiered keys: {a { ... ,
2010 }}
[ [a 2010 jon] ] is the value corresponding to the above tiered
keys.
Try a simpler example, preferably with less repetition of
similar-looking values.
Unfortunately, the repetition of identical or similar values is a part
of the problem set; essentially, the keys themselves are values which
are contained in the corresponding nested value, i.e.
{a { ... , 2010 [ [a 2010 jon] ] } }
Notice how the nested vector contains both aand 2010.
Thanks for the help. Hope my clarifications make the problem clearer;
let me know if any more information/clarification is needed.
Regards,
Ari
--
You 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: ANN: core.match 0.2.0-alpha5
On Mon, Oct 10, 2011 at 10:28 PM, Rob Lally rob.la...@gmail.com wrote: Would supporting other data structures make it slower when using vectors, or only when using non-vector seq's? If we use :seq pattern matching, it will use first/rest. This can be very expensive. Vectors will take a performance hit. :vector matching uses subvec, which explains its advantages (speed) and disadvantages (only supports vectors). What I'm proposing is defaulting to :seq matching. It's very easy to switch on :vector matching. Something like (match [v] [[x xs]] 1) - :seq (match [v] [([x xs] :vector)] 1) - vector Ambrose -- You 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: ANN: core.match 0.2.0-alpha5
How about: `match` - defaults to :seq, returns nil `match-debug` - defaults to :seq, w/ error checking, w/ comprehensiveness check `matchv` - defaults to :vector Ambrose -- You 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: Faster JSON library
On Fri, Oct 7, 2011 at 4:20 PM, Stuart Halloway stuart.hallo...@gmail.com wrote: Trying to be a little bit constructive here, in case I come across as complaining, I took the source for c.d.json and put it into a leiningen project, enabled warn on reflection, and found that several cases of (... (let [c (char i] ... (= c \x) ...) results in Clojure deciding it needs to perform reflection in order to call equals in the comparison with a fixed character. I'm not really sure what the proper solution for this is, but I changed the let to (let [c (Character/valueOf (char i)] ...) and the time for my 217KB JSON file dropped from 107 seconds to 2 seconds, or only a little more than twice as slow as clj-json (which clocked in a little under one second for my file). Lars Nilsson This reflection warning can be fixed with an enhancement on the Clojure side, which I have just pushed to master [1]. I would like to create 1.4 alpha 1 with the code changes that have gone in today. It would be super-great if anybody has time to build your own project against master and let us know if you see any issues. Thanks, Stu [1] https://github.com/clojure/clojure/commit/405d24dd49d649c01b7881f1394fc90924c54ef0 Cloning and building 1.4.0-master-SNAPSHOT resulted in much better performance in loading data into couchdb. When using c.d.json it takes about 98 seconds for loading and storing 100 JSON documents (ranging in size from some tens of KB, to 5MB), while clj-json takes about 86 seconds. Comparing just the load time c.d.json takes 27 seconds and clj-json takes 12 seconds. Overall, the 100 JSON files are about 114MB. So to keep things in perspectice, a single 217KB file took over 100 seconds before this change, now 114MB takes 27 seconds. Lars Nilsson -- You 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: Faster JSON library
On Mon, Oct 10, 2011 at 11:19 AM, Lars Nilsson chamael...@gmail.com wrote: On Fri, Oct 7, 2011 at 4:20 PM, Stuart Halloway stuart.hallo...@gmail.com wrote: Trying to be a little bit constructive here, in case I come across as complaining, I took the source for c.d.json and put it into a leiningen project, enabled warn on reflection, and found that several cases of (... (let [c (char i] ... (= c \x) ...) results in Clojure deciding it needs to perform reflection in order to call equals in the comparison with a fixed character. I'm not really sure what the proper solution for this is, but I changed the let to (let [c (Character/valueOf (char i)] ...) and the time for my 217KB JSON file dropped from 107 seconds to 2 seconds, or only a little more than twice as slow as clj-json (which clocked in a little under one second for my file). Lars Nilsson This reflection warning can be fixed with an enhancement on the Clojure side, which I have just pushed to master [1]. I would like to create 1.4 alpha 1 with the code changes that have gone in today. It would be super-great if anybody has time to build your own project against master and let us know if you see any issues. Thanks, Stu [1] https://github.com/clojure/clojure/commit/405d24dd49d649c01b7881f1394fc90924c54ef0 Cloning and building 1.4.0-master-SNAPSHOT resulted in much better performance in loading data into couchdb. When using c.d.json it takes about 98 seconds for loading and storing 100 JSON documents (ranging in size from some tens of KB, to 5MB), while clj-json takes about 86 seconds. Comparing just the load time c.d.json takes 27 seconds and clj-json takes 12 seconds. Overall, the 100 JSON files are about 114MB. So to keep things in perspectice, a single 217KB file took over 100 seconds before this change, now 114MB takes 27 seconds. Ugh, I need to keep things straight. It was obviuosly some iterations earlier for the single file, compared with once for each file afterward. Still, the difference is huge. Lars Nilsson -- You 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: ANN: core.match 0.2.0-alpha5
On Mon, Oct 10, 2011 at 10:28 AM, Rob Lally rob.la...@gmail.com wrote: If it only makes the non-vector seq case slower, I'd certainly make that an available option - people are going to have to manually convert other sequences into vectors anyway which creates a coding overhead and also makes the code less likely to be JITed. On the other hand.. YMMV. Choosing to support seqs doesn't really make anything else slower. It's about managing expectations - people will use whatever's most convenient. If it performs badly then maybe that will be a unpleasant surprise. But then again, maybe it's fast enough that most people don't really care. That people use and enjoy destructuring on seqs is probably a good argument that most people don't care. David -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com 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: ANN: core.match 0.2.0-alpha5
On Mon, Oct 10, 2011 at 10:56 AM, Ambrose Bonnaire-Sergeant abonnaireserge...@gmail.com wrote: How about: `match` - defaults to :seq, returns nil `match-debug` - defaults to :seq, w/ error checking, w/ comprehensiveness check `matchv` - defaults to :vector Ambrose I think we can just have vector patterns support seqs via nth. I'm OK w/ match-debug. David -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com 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: ANN: core.match 0.2.0-alpha5
On Mon, Oct 10, 2011 at 06:57, David Nolen dnolen.li...@gmail.com wrote: On Sun, Oct 9, 2011 at 11:19 PM, Ambrose Bonnaire-Sergeant abonnaireserge...@gmail.com wrote: On Mon, Oct 10, 2011 at 3:31 AM, David Nolen dnolen.li...@gmail.com wrote: - return nil instead of throwing if no match found to mirror the behavior of cond I don't like this. I'm definitely open to talking about it. Strong opinions appreciated :) Why are we emulating cond? clojure.core/case, for example, seems closer to what `match` provides, and that throws an IllegalArgumentException if there is no match. Seems arbitrary to me. Is there more to it? A good point. I'm mostly thinking about user friendliness here. I'm also OK w/ the idea of providing two versions of match - one w/ verbose error reporting that throws and perhaps the default one that doesn't So, I have one other argument in favour of just return nil, which I prefer: If you just return `nil`, I can use :else to throw fairly cheaply, and quite visibly. If you throw then I have to wrap any non-exhaustive pattern in a try/catch block to avoid the exception propagating up the stack. Daniel -- ♲ Made with 100 percent post-consumer electrons -- You 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: ANN: core.match 0.2.0-alpha5
On Mon, Oct 10, 2011 at 12:08 PM, Daniel Pittman dan...@rimspace.netwrote: On Mon, Oct 10, 2011 at 06:57, David Nolen dnolen.li...@gmail.com wrote: On Sun, Oct 9, 2011 at 11:19 PM, Ambrose Bonnaire-Sergeant abonnaireserge...@gmail.com wrote: On Mon, Oct 10, 2011 at 3:31 AM, David Nolen dnolen.li...@gmail.com wrote: - return nil instead of throwing if no match found to mirror the behavior of cond I don't like this. I'm definitely open to talking about it. Strong opinions appreciated :) Why are we emulating cond? clojure.core/case, for example, seems closer to what `match` provides, and that throws an IllegalArgumentException if there is no match. Seems arbitrary to me. Is there more to it? A good point. I'm mostly thinking about user friendliness here. I'm also OK w/ the idea of providing two versions of match - one w/ verbose error reporting that throws and perhaps the default one that doesn't So, I have one other argument in favour of just return nil, which I prefer: If you just return `nil`, I can use :else to throw fairly cheaply, and quite visibly. If you throw then I have to wrap any non-exhaustive pattern in a try/catch block to avoid the exception propagating up the stack. Daniel We'll only throw w/ match-debug. David -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com 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: Faster JSON library
I think I got the permissions fixed... -S -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com 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: Faster JSON library
Patch welcome... ;) -S -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com 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.contrib.base64
Cool! I did some quick-and-dirty benchmarking of it this afternoon (GMT+2) and got between 50 and 70 MiB/s on my machine. The Apache implementation used for comparison by the unit tests came in at between 30 and 40 MiB/s. Impressive. I've since seen perf_base64.clj go in, though I'm not clear on how it's intended to be used as it's not actually used by test code, though it is in the test tree. I thought I'd get c.c.base64 wired up with swank-clojure since that's my usual way of working and start exploring. (That was an hour ago.) I've now got it working (tl;dr: parent 0.0.25 brings clojure 1.3.0; swank 1.3.3 needs plugin 1.3.8). See also https://github.com/bpsm/clojure.data.codec/commit/5c285928e5362ab73bfb5a01e2df0d7542bb64d0 So, now I'm ready to explore. Yea! :) (* Other topic: To Stewart's recent question about encouraging more use of Clojure's bleeding edge for more timely feedback: I suspect it's this kind of death-by-a-thousand-paper-cuts dependency foul-ups that make one gunshy about staying on the bleeding edge. With swank-clojure, clojure-maven-plugin, clojure, clojure-mode.el in my tool chain, I've grown reluctant to stay on the bleeding edge even for projects without library dependencies. The 1.1-1.2 transition was already rocky for me because of tooling issues. What do the Clojure devs themselves do to keep their dev environment productive? Use ed and a raw repl running in two xterms? ;-) *) On Mon, Oct 10, 2011 at 12:08, Alexander Taggart m...@ataggart.ca wrote: On Sunday, 9 October 2011 19:49:17 UTC-7, Stuart Sierra wrote: Clojure unless somebody clever can make one that's actually *faster* than the best Java lib. Here ya go: https://github.com/ataggart/clojure.data.codec -- You 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: clojure.contrib.base64
I see about a 50% increased throughput over apache commons-codec as well. I use the perf-base64 ns generate input data and output timing files to keep track of changes to the performance over time, lest a regression creep in. I'll add some documentation if you want to play with it. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com 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: ANN: core.match 0.2.0-alpha5
I've just been playing around a bit with match so please forgive me if I've
missed some prior discussions regarding issues that are considered settled.
One of my first attempts was to match a vector of two of the same thing using a
pattern like [a a]. I naively thought that would imply an equality constraint
between the two items, but in fact each variable matched anything
independently. I now understand that the pattern variables are considered in
different scopes, but I think it's confusing. It's reasonable that you want
something faster than unification for simple literal patterns, but this to my
mind is a special case that's likely to trip people up.
My work-around is to use something like this:
(match [x y]
[a (b :when #(= % x))] :match
:else :no-match)
But that doesn't look very nice, and it gets worse with multiple pattern
variables. Still, it doesn't look too hard to make that sort of conversion
automatically so maybe I'll try to write a macro. (Famous last words. :-)
In any case, if using multiple pattern variables of the same name does not
imply an equality constraint, I suggest that it be considered an error to reuse
a pattern variable. It's better to throw than to yield an unexpected match.
Regarding OR patterns, I didn't really like the infix notation, (1 | 2). As a
lisper, I'd prefer to use something like (or 1 2), or maybe even a Clojure set
notation: #{1 2}. I'm guessing you already thought about this and made your
decision on syntax, but I thought I'd throw it out there.
For guards, I wonder if the extra parens are really necessary. Couldn't the
:when bind tightly to the previous pattern variable? Like Clojure FOR
comprehensions. I think it would be easier to read that way. Same comment
applies to :as. To cover the rare case of matching a literal :when or :as, you
could quote it or use it as the first item in an OR pattern.
As others have suggested, I agree that returning nil when nothing matches makes
sense. That was my original expectation.
It was common when testing to wrap a let around the match so I made a little
macro to save a few characters. Free for anyone who wants it. :-)
(defmacro match-let [bindings body]
(let [bindvars# (take-nth 2 bindings)]
`(let ~bindings
(match [~@bindvars#]
~@body
Steve Miner
stevemi...@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
Re: clojure.contrib.base64
I've already figured out how it works and have found the same 2:1 ratio. (This time on my 1.4GHz MacBook Air; The previous tests were on a 2.4 GHz Core2Duo running Linux.) When I did the quick-and-dirty benchmarking this afternoon I used larger random inputs (1 to 8 MiB) allowing me to calculate a MiB/s value. I found performance dropped off a noticeably when input size increased from 2 to 4 MiB. (Processor cache effect?) Just now, I wrote a round-trip unit test and have begun poking at an implementation of a decode function. (As an exercise to better understand the techniques you used in your encode function; If it turns out not to suck and can compete with whatever you must already be writing, I'll offer it for inclusion -- my C.A. is on file.) // Ben On Mon, Oct 10, 2011 at 20:37, Alexander Taggart m...@ataggart.ca wrote: I see about a 50% increased throughput over apache commons-codec as well. I use the perf-base64 ns generate input data and output timing files to keep track of changes to the performance over time, lest a regression creep in. I'll add some documentation if you want to play with it. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com 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: ANN: core.match 0.2.0-alpha5
On Mon, Oct 10, 2011 at 2:43 PM, Steve Miner stevemi...@gmail.com wrote:
I've just been playing around a bit with match so please forgive me if I've
missed some prior discussions regarding issues that are considered settled.
One of my first attempts was to match a vector of two of the same thing
using a pattern like [a a]. I naively thought that would imply an equality
constraint between the two items, but in fact each variable matched anything
independently. I now understand that the pattern variables are considered in
different scopes, but I think it's confusing. It's reasonable that you want
something faster than unification for simple literal patterns, but this to
my mind is a special case that's likely to trip people up.
I would accept a patch that would make equality constraints work. We would
have to track named wildcards and if they are reused, impose the
constraint.
In any case, if using multiple pattern variables of the same name does not
imply an equality constraint, I suggest that it be considered an error to
reuse a pattern variable. It's better to throw than to yield an unexpected
match.
In the meantime throwing an error if names are reused in a pattern row is a
good idea. http://dev.clojure.org/jira/browse/MATCH-30
Regarding OR patterns, I didn't really like the infix notation, (1 | 2).
As a lisper, I'd prefer to use something like (or 1 2), or maybe even a
Clojure set notation: #{1 2}. I'm guessing you already thought about this
and made your decision on syntax, but I thought I'd throw it out there.
Set notation doesn't communicate that order is important. (or 1 2) overloads
the meaning of the or construct. I'm not sold on the infix notation either.
Looking for more feedback / ideas on this.
For guards, I wonder if the extra parens are really necessary. Couldn't
the :when bind tightly to the previous pattern variable? Like Clojure FOR
comprehensions. I think it would be easier to read that way. Same comment
applies to :as. To cover the rare case of matching a literal :when or :as,
you could quote it or use it as the first item in an OR pattern.
It would be nice to lose the extra parens - patch welcome :)
As others have suggested, I agree that returning nil when nothing matches
makes sense. That was my original expectation.
It was common when testing to wrap a let around the match so I made a
little macro to save a few characters. Free for anyone who wants it. :-)
(defmacro match-let [bindings body]
(let [bindvars# (take-nth 2 bindings)]
`(let ~bindings
(match [~@bindvars#]
~@body
Steve Miner
stevemi...@gmail.com
match-let looks good. I see that you are Clojure contributor - I'm more than
happy to include this.
Steve, this is great feedback - much appreciated.
David
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
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: ANN: core.match 0.2.0-alpha5
match-let looks good. I see that you are Clojure contributor - I'm more than happy to include this. Yes, I'm a registered contributor. It's all yours. I'll take a look at the code and see if I can fix things for myself regarding the implied equality constraints and guard clauses. By the way, there is a recurring typo in the README and the code: occurance should be occurrence. Steve Miner stevemi...@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
Re: ANN: core.match 0.2.0-alpha5
On Mon, Oct 10, 2011 at 3:42 PM, Steve Miner stevemi...@gmail.com wrote: match-let looks good. I see that you are Clojure contributor - I'm more than happy to include this. Yes, I'm a registered contributor. It's all yours. I'll take a look at the code and see if I can fix things for myself regarding the implied equality constraints and guard clauses. The internals of core.match could use quite a bit of spring cleaning. Feel free to open tickets on obvious improvements. By the way, there is a recurring typo in the README and the code: occurance should be occurrence. Steve Miner stevemi...@gmail.com Heh, will fix, thanks. David -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com 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: Spread work onto multiple threads (in pure Clojure)
I think that the following partially answers my own question and that it provides a way to get decent multicore performance for collections of non-uniform but compute-intensive tasks through a simple, pmap-like interface. But I'm not sure if it's the best approach and I'd like some feedback. If it *is* a good approach then maybe we should refine it and make it more widely available. If it's not the best approach then I'd love some advice on how to do it better. The use case here -- which I think must be shared by at least some others -- is that I have a finite, non-lazy collection of inputs on which I'd like to run an expensive (but not uniformly expensive) function, gathering the results in a non-lazy sequence. This is a *very* common need in my own projects. I don't care about the order in which the function calls are made, and I'm not concerned about the memory overhead of retaining all of the results since I want to keep them all anyway. I just want all of the computations done as quickly as possible, using all of my available cores. The pmap function seems at first to provide an elegant way to do what's needed, e.g. with (doall (pmap f inputs)), but as discussed earlier in this thread it will often wait for the completion of earlier calls before starting later calls, and this will be particularly problematic when the runtimes of the calls are uneven. The medusa package provides something that would seem to fit the bill better, but it comes with other baggage that I don't need or want. I just want a version of pmap that will use all available CPU resources to aggressively complete all of the computations in a non-lazy context. Here's my stab at doing this using agents: (defn pmapall Like pmap but: 1) coll should be finite, 2) the returned sequence will not be lazy, 3) calls to f may occur in any order, to maximize multicore processor utilization, and 4) takes only one coll so far. [f coll] (let [agents (map agent coll)] (dorun (map #(send % f) agents)) (apply await agents) (doall (map deref agents I should make a version that takes multiple colls, but I for now've written it to take just one for clarity. This does appear to speed things up pretty significantly in certain circumstances, but maybe not as much as possible. Is it the best approach? To show that it beats pmap I define a time-wasting function (I want to see real cpu utilization so I'm not using delays) like this: (defn burn [] (dotimes [i 1] (reduce * (map float (take 1000 (iterate inc i)) And then I define a function that takes a lot or a little bit of time depending on its argument: (defn fast-or-slow [n] (if (zero? n) :done (do (burn) :done))) And then I create an vector of inputs in which the slow ones are scattered sparsely: (def inputs (take 1000 (cycle (conj (repeat 20 0) 1 And then on a 48 core node I get timings like this: user= (time (last (pmapall fast-or-slow inputs))) Elapsed time: 37244.151 msecs :done user= (time (last (doall (pmap fast-or-slow inputs Elapsed time: 110862.187 msecs :done And by the way, plain old serial map does this: user= (time (last (doall (map fast-or-slow inputs Elapsed time: 260941.836 msecs So we've improved things; pmap is a little better than twice as fast as map, and pmapall is roughly 3 times faster than pmap. So I think I'm ready to switch all of my pmaps to pmapalls. But that's still nothing close to a 48x speedup, even though all of the tasks should be completely independent and I wouldn't expect a huge loss for coordination. And another confusing thing is that even with pmapall, when I look at the CPU utilization I see numbers close to 4800% in some cases (like the one above) but numbers topping out at something more like 1900% in some others (e.g. with different input vectors). So I feel like I'm moving in the right direction but that I'm still probably missing something. Is there a better way to do this? Surely it will come in handy for others as well if there's a simple way to more effectively dispatch tasks to multiple cores. Thoughts? Code? Thanks, -Lee On Oct 9, 2011, at 7:24 PM, Lee Spector wrote: I've been playing with medusa and it sometimes does what I expect, but sometimes it's doing something strange and I'm wondering if someone can help me to do one specific medusa-like thing but more simply (and without the strangeness, which I haven't fully traced but I hope to avoid having to). What I want is a version of pmap that will always use any available cores to compute remaining values (except of course the last couple of values, when there are less remaining values than cores). In other words, I want the behavior that Andy Fingerhut describes medusa as having here: On Sep 22, 2011, at 11:34 PM, Andy Fingerhut wrote: pmap will limit the maximum number of simultaneous threads. So will the medusa library's medusa-pmap.
Composing HTML rendering functions
Hi!
Initially I created a mess of interlinked functions for rendering HTML
via hiccup.
I have few pages with parts that may vary or may be present or not based
on whether the user is logged in as admin.
With the desire to test for the role in a single place and for composing
the views in a uniform way, I created a little framework and now wonder
if I'm thinking too complicated, or if this seems sound. Can you suggest
improvements or alternatives?
The outcome is that I can define my views via defviews:
https://github.com/thorwil/tlog-clj-gae/blob/4440f729001ef14ea63115c69f0c868bc59e4686/src/tlog/views/views.clj
The roles are cumulative.
Every view defined in this way expects a role and a map (from the
datastore). The maps is handed through all elements in the vector
(except if it happens to be a def). The html is assembled as value to
:buildup. Every element may read and update/add arbitrary key-vals.
All the slightly complicated business happens here:
https://github.com/thorwil/tlog-clj-gae/blob/4440f729001ef14ea63115c69f0c868bc59e4686/src/tlog/views/compose.clj
To allow the rather straightforward parts:
https://github.com/thorwil/tlog-clj-gae/blob/4440f729001ef14ea63115c69f0c868bc59e4686/src/tlog/views/parts.clj
The {:keys} specified are like slots. If one is nil, Hiccup makes it
fall out.
--
Thorsten Wilms
thorwil's design for free software:
http://thorwil.wordpress.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: Spread work onto multiple threads (in pure Clojure)
A weakness of my pmapall: #Exception java.lang.Exception: Can't await in agent action Which means, I think, that I can't call pmapall within a function that I pass to pmapall. Unfortunate. Is there a better way? -Lee PS to see these exceptions one must change the call to agent in my definition with something like #(agent % :error-handler (fn [agnt except] (println except))). On Oct 10, 2011, at 4:07 PM, Lee Spector wrote: I think that the following partially answers my own question and that it provides a way to get decent multicore performance for collections of non-uniform but compute-intensive tasks through a simple, pmap-like interface. But I'm not sure if it's the best approach and I'd like some feedback. If it *is* a good approach then maybe we should refine it and make it more widely available. If it's not the best approach then I'd love some advice on how to do it better. The use case here -- which I think must be shared by at least some others -- is that I have a finite, non-lazy collection of inputs on which I'd like to run an expensive (but not uniformly expensive) function, gathering the results in a non-lazy sequence. This is a *very* common need in my own projects. I don't care about the order in which the function calls are made, and I'm not concerned about the memory overhead of retaining all of the results since I want to keep them all anyway. I just want all of the computations done as quickly as possible, using all of my available cores. The pmap function seems at first to provide an elegant way to do what's needed, e.g. with (doall (pmap f inputs)), but as discussed earlier in this thread it will often wait for the completion of earlier calls before starting later calls, and this will be particularly problematic when the runtimes of the calls are uneven. The medusa package provides something that would seem to fit the bill better, but it comes with other baggage that I don't need or want. I just want a version of pmap that will use all available CPU resources to aggressively complete all of the computations in a non-lazy context. Here's my stab at doing this using agents: (defn pmapall Like pmap but: 1) coll should be finite, 2) the returned sequence will not be lazy, 3) calls to f may occur in any order, to maximize multicore processor utilization, and 4) takes only one coll so far. [f coll] (let [agents (map agent coll)] (dorun (map #(send % f) agents)) (apply await agents) (doall (map deref agents I should make a version that takes multiple colls, but I for now've written it to take just one for clarity. This does appear to speed things up pretty significantly in certain circumstances, but maybe not as much as possible. Is it the best approach? To show that it beats pmap I define a time-wasting function (I want to see real cpu utilization so I'm not using delays) like this: (defn burn [] (dotimes [i 1] (reduce * (map float (take 1000 (iterate inc i)) And then I define a function that takes a lot or a little bit of time depending on its argument: (defn fast-or-slow [n] (if (zero? n) :done (do (burn) :done))) And then I create an vector of inputs in which the slow ones are scattered sparsely: (def inputs (take 1000 (cycle (conj (repeat 20 0) 1 And then on a 48 core node I get timings like this: user= (time (last (pmapall fast-or-slow inputs))) Elapsed time: 37244.151 msecs :done user= (time (last (doall (pmap fast-or-slow inputs Elapsed time: 110862.187 msecs :done And by the way, plain old serial map does this: user= (time (last (doall (map fast-or-slow inputs Elapsed time: 260941.836 msecs So we've improved things; pmap is a little better than twice as fast as map, and pmapall is roughly 3 times faster than pmap. So I think I'm ready to switch all of my pmaps to pmapalls. But that's still nothing close to a 48x speedup, even though all of the tasks should be completely independent and I wouldn't expect a huge loss for coordination. And another confusing thing is that even with pmapall, when I look at the CPU utilization I see numbers close to 4800% in some cases (like the one above) but numbers topping out at something more like 1900% in some others (e.g. with different input vectors). So I feel like I'm moving in the right direction but that I'm still probably missing something. Is there a better way to do this? Surely it will come in handy for others as well if there's a simple way to more effectively dispatch tasks to multiple cores. Thoughts? Code? Thanks, -Lee On Oct 9, 2011, at 7:24 PM, Lee Spector wrote: I've been playing with medusa and it sometimes does what I expect, but sometimes it's doing something strange and I'm wondering if someone can help me to do one specific medusa-like thing but more simply (and without the
Type hints and records
I am using a record to wrap a number of java classes, which I then access various properties on. I am trying to avoid reflection so I type have type hinted, however when accessing the values in the record the type hints are lost. It might look something like this (defrecord Rec [^Integer i]) (defn to-string [^Rec record] (.toString (:i record))) However the to-string function gives a reflection warning, even with the input the to function type hinted. Now I know that type hints don't survive across function boundaries, but is there no way to get a type hinted value from the record? -- You 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
Reactions to google dart?
And what does it mean to clojurescript? -- You 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: statistics library?
Hi Lee, On Wed, Sep 28, 2011 at 12:43 AM, Lee Spector lspec...@hampshire.edu wrote: On Sep 27, 2011, at 5:44 PM, David Powell wrote: I see that there was a recent fix made to Incanter: Fixed typo in :lower-tail? keyword. This was causing the complement of the p-value to be returned. https://github.com/liebke/incanter/pull/39 Have you tried the latest version in git? Does this fix the problem? Hmm. I had asked about the version on the Incanter list too. I now see that I was using a *newer* version than the newest one at https://github.com/liebke/incanter. I grabbed what appeared to be the newest on clojars, which is [incanter 1.2.3], while the newest download on that github project page appears to be 1.2.2 from April 20, 2010. It does sound like the comment that you quoted might indeed be about the bug that I ran into, so maybe it's fixed in some version of Incanter somewhere... There should be 1.2.4 (and a snapshot of 1.3.0) up on clojars now. Could I ask you to give one of them a go, and mail your findings to the list? We have our regular Incanter Hack Day coming up next weekend, so if things are still b0rken for you, I can try to find a developer to look at the problem for you at the Hack day. Thanks, Ben -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com 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: Macro tutorials?
Hi, Nicolas, and thanks. I'm new to clojure (I've been working through Programming Clojure), and most of my long work life has gravitated around c, shell scripts, and perl. That being said, I've tinkered with Lisp dialects for the past twenty-five years (mostly elisp, scheme, and common lisp), and have always struggled with both the overall meaning of Lisp (when should I use it, when should I not?), and with macros. I downloaded and read the intro to On Lisp, and it looks like exactly what I need. I'm going to work through the book, and make comments here about how it relates to my learning of clojure (assuming that it isn't deemed off-topic noise). Regards, Larry On Mon, Oct 10, 2011 at 7:33 AM, Nicolas bousque...@gmail.com wrote: A good book to learn lisp macros, is On Lisp from Paul Graham. This book really cover advanced topics and concepts, and has many chapters related to macros. The book is freely available in online format from Paul Graham Website: http://www.paulgraham.com/onlisp.html On Oct 6, 1:02 pm, Michael Jaaka michael.ja...@googlemail.com wrote: Thanks to all! You have helped a lot! Also I will consider reading Practical Common Lisp. On Oct 6, 9:42 am, Stefan Kamphausen ska2...@googlemail.com wrote: Hi. You might consider reading Peter Seibel's excellent Practical Common Lisp which has some nice macro-work in it. If after that you're still hungry for more, consider Let Over Lambda by Doug Hoyte. Admitted, both cover Common Lisp, but the differences will not keep you from getting a deeper understanding of how macros work and where and how they can be used. (This is more an answer to the subject of this thread, less to the question in your body :) Regards, Stefan -- You 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 -- *Off the Beaten Path in Technology http://otbeatenpath.wordpress.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
Incanter Hack Day, Sunday 16th October, London
Hi, There is an Incanter Hack Day taking place on Sunday at the Royal Festival Hall in London. We'll be on the 5th floor, Blue side. The group will begin turning up at 1000, but feel free to come a bit later if that's too early. We'll go for some lunch somewhere close by on Southbank when everyone gets hungry, then come back for a few more hours hacking in the afternoon. It's very laid-back and informal, and we try to be accessible to interested developers of all levels. Feel free to bring Incanter tasks to hack on (but we always have a stock of open tasks if people need something to work on). These are regular, monthly events - every 3rd Sunday of the month. Upcoming dates are: 16th October 20th November 18th December Hope to see you on Sunday! Thanks, Ben -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com 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: Reactions to google dart?
As a language - not much exciting stuff. ClojureScript by targeting lowest common denominator JavaScript is portable in a way that Dart is not. I'm skeptical that Dart will see much uptake from various vendors - but only time will tell. David On Mon, Oct 10, 2011 at 7:47 AM, ivo ivo.reduto.fre...@gmail.com wrote: And what does it mean to clojurescript? -- You 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: Reactions to google dart?
What I have in mind is not related to Dart, but to the support of Closure Tools from Google. Will Dart javascript compatibility layer/javascript compilation for non-Chrom(e)(ium) browsers include the Closure Tools Suite ? 2011/10/10 David Nolen dnolen.li...@gmail.com: As a language - not much exciting stuff. ClojureScript by targeting lowest common denominator JavaScript is portable in a way that Dart is not. I'm skeptical that Dart will see much uptake from various vendors - but only time will tell. David On Mon, Oct 10, 2011 at 7:47 AM, ivo ivo.reduto.fre...@gmail.com wrote: And what does it mean to clojurescript? -- You 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: ANN: core.match 0.2.0-alpha5
On Mon, Oct 10, 2011 at 09:08:42AM -0700, Daniel Pittman wrote: So, I have one other argument in favour of just return nil, which I prefer: If you just return il, I can use :else to throw fairly cheaply, and quite visibly. If you throw then I have to wrap any non-exhaustive pattern in a try/catch block to avoid the exception propagating up the stack. Daniel An :else clause *makes* for an exhaustive pattern; :else nil will never throw an exception, and shows the intention to expliclty handle unknown values by returning nil. I think a match-debug is barking up the wrong tree. If throwing an exception is the right thing to do to track down an unaccounted case, why make a different macro just for a slightly different default behavior that is easily specifiable by :else. In fact, the match macro can simply implement default behavior by adding an :else clause if there is none (thus removing concerns about 'code size'). I would definitely consider it a plus for the stock vector form to work on any seqable, especially when using match to write macros. Right now I've been doing (match-1 (into [] ...) ...) just to make the clauses look nicer. If the type of the seqable is important to differentiate or for performance, then there's more complex :seq and :vector. Also, what's the point of having a specific match and match-1? I presume it's to avoid creating an intermediate vector. Why not make match-1 the default, and if the expression is a literal vector, fall back to current match? Steve -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com 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.contrib.base64
What do the Clojure devs themselves do to keep their dev environment productive? Use ed and a raw repl running in two xterms? ;-) *) Emacs inferior-lisp mode and Bash scripts. Not my first choice, but always works. -Stuart Sierra clojure.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: Type hints and records
I am using a record to wrap a number of java classes, which I then access various properties on. I am trying to avoid reflection so I type have type hinted, however when accessing the values in the record the type hints are lost. It might look something like this (defrecord Rec [^Integer i]) (defn to-string [^Rec record] (.toString (:i record))) However the to-string function gives a reflection warning, even with the input the to function type hinted. Now I know that type hints don't survive across function boundaries, but is there no way to get a type hinted value from the record? Treat the record as a typed thing instead of as a map (note the dot instead of the colon). (defn to-string [^Rec record] (.toString (.i record))) That said, and not knowing exactly what you are doing, the following looks better to me: (defrecord Rec [^int i]) (defn to-string [^Rec record] (str (:i record))) Stu Stuart Halloway Clojure/core http://clojure.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: Spread work onto multiple threads (in pure Clojure)
On Mon, Oct 10, 2011 at 1:07 PM, Lee Spector lspec...@hampshire.edu wrote: Here's my stab at doing this using agents: (defn pmapall Like pmap but: 1) coll should be finite, 2) the returned sequence will not be lazy, 3) calls to f may occur in any order, to maximize multicore processor utilization, and 4) takes only one coll so far. [f coll] (let [agents (map agent coll)] (dorun (map #(send % f) agents)) (apply await agents) (doall (map deref agents What you're really looking for is pdoseq, right? Seems like futures might be a better building-block for this, although again Clojure's lack of flexibility over the thread pool could easily bite you here. -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: Spread work onto multiple threads (in pure Clojure)
On Oct 10, 2011, at 7:16 PM, Phil Hagelberg wrote: What you're really looking for is pdoseq, right? Seems like futures might be a better building-block for this, although again Clojure's lack of flexibility over the thread pool could easily bite you here. No -- I want all of the returned values, as map/pmap provides but doseq does not. I want what pmap does except that I want greedier use of available cores until all of the values are computed, at the expense of computing them in order. -Lee -- You 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: statistics library?
On Oct 10, 2011, at 4:36 PM, Ben Evans wrote: There should be 1.2.4 (and a snapshot of 1.3.0) up on clojars now. Could I ask you to give one of them a go, and mail your findings to the list? We have our regular Incanter Hack Day coming up next weekend, so if things are still b0rken for you, I can try to find a developer to look at the problem for you at the Hack day. Searching for incanter at clojars I find only one 1.2.4 item: incanter/incanter-latex 1.2.4 -- I don't think this is what I want... Is it? I just want the statistics functions, not anything having to do with latex. I see the 1.3 snapshot, but when I try it by including [incanter 1.3.0-SNAPSHOT] in my project.clj dependencies lein deps fails with: --- Unable to resolve artifact: Missing: -- 1) incanter:incanter-latex:jar:1.3.0-SNAPSHOT --- So I haven't yet been able to actually try the statistical tests. -Lee -- You 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
Libraries supporting 1.31.2 and bignums
I may be missing something obvious. Midje has a checker that lets users say things like (fact (my-computation) = (roughly 15 2)) Where the first number in `roughly` is the target number and the second is an acceptable range around that target. Part of what the checker does in 1.2 is this: (= expected (+ actual delta)) Now, Midje is a service. If the 1.3 user has taken care to use promoting-to-bignum arithmetic, it would be rude to blow up if `actual` happens to be a regular integer but adding `delta` to it causes an overflow. I should use promoting-to-bignum addition. In Clojure 1.3, thats +'. In 1.2, it's +. I can't use the token +' because it doesn't exist in 1.2: java.lang.ClassCastException: clojure.lang.Symbol cannot be cast to java.lang.Number (NO_SOURCE_FILE:0) I can't use the token + because that blows up in the boundary case under 1.3 (but not under 1.2). One thought is variations of code like this: (if (clojure-1-3?) (def +M +') (def +M +) This causes amusing results because of the quote. I haven't found a variation that works. So what should a library writer who wants to honor the choices of his users do? - Brian Marick, Artisanal Labrador Now working at http://path11.com Contract programming in Ruby and Clojure Occasional consulting on Agile -- You 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: Libraries supporting 1.31.2 and bignums
(defmacro plus [] (if … (resolve (symbol clojure.core/+)) (resolve (symbol clojure.core/+' ((plus) actual delta) On Mon, Oct 10, 2011 at 4:28 PM, Brian Marick mar...@exampler.com wrote: I may be missing something obvious. Midje has a checker that lets users say things like (fact (my-computation) = (roughly 15 2)) Where the first number in `roughly` is the target number and the second is an acceptable range around that target. Part of what the checker does in 1.2 is this: (= expected (+ actual delta)) Now, Midje is a service. If the 1.3 user has taken care to use promoting-to-bignum arithmetic, it would be rude to blow up if `actual` happens to be a regular integer but adding `delta` to it causes an overflow. I should use promoting-to-bignum addition. In Clojure 1.3, thats +'. In 1.2, it's +. I can't use the token +' because it doesn't exist in 1.2: java.lang.ClassCastException: clojure.lang.Symbol cannot be cast to java.lang.Number (NO_SOURCE_FILE:0) I can't use the token + because that blows up in the boundary case under 1.3 (but not under 1.2). One thought is variations of code like this: (if (clojure-1-3?) (def +M +') (def +M +) This causes amusing results because of the quote. I haven't found a variation that works. So what should a library writer who wants to honor the choices of his users do? - Brian Marick, Artisanal Labrador Now working at http://path11.com Contract programming in Ruby and Clojure Occasional consulting on Agile -- You 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 -- And what is good, Phaedrus, And what is not good— Need we ask anyone to tell us these things? -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com 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: How to Collapse Nested Map into a Sequence of Flat Maps
I'd appreciate suggestions and insights on how I can collapse a nested
map with n number of keys (levels) to create a flat map which is
comprised of composite keys and a value. For example, let's say we
have:
{ a { 2011 [ [ a 2011 ari] [ a 2011 dan] ] } { 2010 [ [ a
2010 jon] ] } }
I'd like to collapse the nest into a sequence of flat maps like:
( { [a 2011] [ [a 2011 ari] [a 2011 dan] ] }, { [a 2010]
[ [a 2010 jon] ] } )
I've put together a solution (see below) that collapses nested maps
into a sequence of flat maps with composite keys. Unfortunately, the
solution wraps the result within another list, anyone know why?
Thanks.
(defn collapse [data keys-coll]
(if (map? data)
(for [[k v] data]
(collapse v (if (nil? keys-coll)
(conj [] k)
(conj (into [] keys-coll) k
(hash-map (flatten keys-coll) data)))
--
You 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: ANN: core.match 0.2.0-alpha5
On Mon, Oct 10, 2011 at 6:07 PM, Stephen Wrobleski st...@localtoast.orgwrote: I think a match-debug is barking up the wrong tree. If throwing an exception is the right thing to do to track down an unaccounted case, why make a different macro just for a slightly different default behavior that is easily specifiable by :else. In fact, the match macro can simply implement default behavior by adding an :else clause if there is none (thus removing concerns about 'code size'). I'm not following. Getting accurate information about what failed to match needs to be integrated. Given that match makes no restrictions on types there's not much we can do except communicate where we were when the match failed via an exception. Also, what's the point of having a specific match and match-1? I presume it's to avoid creating an intermediate vector. Why not make match-1 the default, and if the expression is a literal vector, fall back to current match? Steve Ambrose had some arguments for keeping match and match-1 separate. At the moment I don't see any real issues except that overloading match to handle two different cases seems like we're making things slightly more complex. David -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com 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
How do I add goog.ui.MenuItem or goog.ui.Option items to goog.ui.Select in clojurescript?
Here's my clojurescript function: (defn make-select [elem-id] (let [select (goog.ui.Select. Heading) select-elem (d/element (keyword (str div# elem-id)))] (.addItemAt select (goog.ui.MenuItem. Item 1) 0) (.addItem select (goog.ui.Option. Item 2)) (.render select select-elem) select-elem)) When you add the results of a calling the above function as: (make-select :channel) to the DOM, it produces the following HTML in the browser: div id=channel div class=goog-inline-block goog-menu-button title= role=button style=-webkit-user-select: none; tabindex=0 aria- haspopup=true aria-pressed=false aria-expanded=false aria- activedescendant= div class=goog-inline-block goog-menu-button-outer-box div class=goog-inline-block goog-menu-button-inner-box div class=goog-inline-block goog-menu-button-caption Heading /div div class=goog-inline-block goog-menu-button-dropdown nbsp; /div /div /div /div /div So, where are the MenuItems or Options? I can't figure out what to do to get the items to be added! The generated Javascript looks a lot like the code in the demo at: http://closure-library.googlecode.com/svn/trunk/closure/goog/demos/select.html Any help greatly appreciated. -- You 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.contrib.base64
Base64 decoding support has been added. http://github.com/ataggart/clojure.data.codec -- You 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: Spread work onto multiple threads (in pure Clojure)
I made an alternative implementation using a thread pool and a queue, based on the example at http://clojure.org/concurrent_programming In short, your pmapall and the pool-based implementation (below) both give approximately perfect scaling on my 4/8-core system (Intel i7 920 and HT). Both give close to full load on all cores and a factor 4.4 speedup compared to single threaded. This seems about right, the CPU has four physical cores and get a few percent extra performance from the virtual cores, so the speedup is approximately linear with the number of cores. pmap-pool may be a tiny bit faster than the pmapall, but they are so close that I can't really tell. It is possible that there is some sort of synchronization overhead on your 48-core machine. 95% of the tasks are practically noops, after all - just the cost of a single function call. There are only 48 tasks in your test that actually require computation, so each core will do a bunch of noops and perhaps one real task. In real time, a single i7 920 runs the test just as fast as your 48 cores. I don't expect that's representative for what your 48 cores can do. I suggest * Increase the test size and/or the density of heavy tasks. * Let the light tasks do a bit more computation, at least enough to pay for the overhead of calling them. * Start with a smaller number of threads, and see where it stops scaling linearly. Threadpool/queue-based implementation: (import '(java.util.concurrent Executors)) (defn pmap-pool [f coll] (let [queue (ref coll) ;; shared queue of work units nthreads (.availableProcessors (Runtime/getRuntime)) pool (Executors/newFixedThreadPool nthreads) tasks (map (fn [_] (fn [] ; one task per thread (let [local-res (atom [])] ;; collect results per thread to minimize synchronization (while (seq @queue) ;; queue may be emptied between 'while' ;; and 'dosync'. (when-let [wu (dosync ;; grab work unit, update queue (when-let [w (first @queue)] (alter queue next) w))] (swap! local-res conj (f wu local-res))) (range nthreads)) results (doall (map #(deref (.get %)) ;; blocks until completion (.invokeAll pool tasks))) ;; start all tasks results (reduce concat results)] (.shutdown pool) ;; sanity check (when-not (and (empty? @queue) (= (count results) (count coll)) (every? #(= % :done) results)) (println ERROR: queue (count @queue) #results (count results))) results)) Results on an i7 920, 4 cores/8 threads (hyperthreading), Ubuntu 10.10: user= (time (last (map fast-or-slow inputs Elapsed time: 161891.732036 msecs, 100% CPU (out of 800% possible) user= (time (last (pmap fast-or-slow inputs Elapsed time: 163139.249677 msecs, 100% CPU pmap has zero effect on my system, it won't use more than one core. user= (time (last (pmapall fast-or-slow inputs Elapsed time: 37710.349712 msecs, ~793% CPU user= (time (last (pmap-pool fast-or-slow inputs Elapsed time: 36393.132824 msecs, ~795% CPU -- You 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: Spread work onto multiple threads (in pure Clojure)
Interesting. I'll try some of your suggested tests to see if my pmapall all is behaving better than I thought. Does your pmap-pool permit nesting? (That is, does it permit passing pmap-pool a function which itself calls pmap-pool?). If so then that would be a reason to prefer it over my pmapall. Thanks, -Lee On Oct 10, 2011, at 9:43 PM, j-g-faustus wrote: I made an alternative implementation using a thread pool and a queue, based on the example at http://clojure.org/concurrent_programming In short, your pmapall and the pool-based implementation (below) both give approximately perfect scaling on my 4/8-core system (Intel i7 920 and HT). Both give close to full load on all cores and a factor 4.4 speedup compared to single threaded. This seems about right, the CPU has four physical cores and get a few percent extra performance from the virtual cores, so the speedup is approximately linear with the number of cores. pmap-pool may be a tiny bit faster than the pmapall, but they are so close that I can't really tell. It is possible that there is some sort of synchronization overhead on your 48-core machine. 95% of the tasks are practically noops, after all - just the cost of a single function call. There are only 48 tasks in your test that actually require computation, so each core will do a bunch of noops and perhaps one real task. In real time, a single i7 920 runs the test just as fast as your 48 cores. I don't expect that's representative for what your 48 cores can do. I suggest * Increase the test size and/or the density of heavy tasks. * Let the light tasks do a bit more computation, at least enough to pay for the overhead of calling them. * Start with a smaller number of threads, and see where it stops scaling linearly. Threadpool/queue-based implementation: (import '(java.util.concurrent Executors)) (defn pmap-pool [f coll] (let [queue (ref coll) ;; shared queue of work units nthreads (.availableProcessors (Runtime/getRuntime)) pool (Executors/newFixedThreadPool nthreads) tasks (map (fn [_] (fn [] ; one task per thread (let [local-res (atom [])] ;; collect results per thread to minimize synchronization (while (seq @queue) ;; queue may be emptied between 'while' ;; and 'dosync'. (when-let [wu (dosync ;; grab work unit, update queue (when-let [w (first @queue)] (alter queue next) w))] (swap! local-res conj (f wu local-res))) (range nthreads)) results (doall (map #(deref (.get %)) ;; blocks until completion (.invokeAll pool tasks))) ;; start all tasks results (reduce concat results)] (.shutdown pool) ;; sanity check (when-not (and (empty? @queue) (= (count results) (count coll)) (every? #(= % :done) results)) (println ERROR: queue (count @queue) #results (count results))) results)) Results on an i7 920, 4 cores/8 threads (hyperthreading), Ubuntu 10.10: user= (time (last (map fast-or-slow inputs Elapsed time: 161891.732036 msecs, 100% CPU (out of 800% possible) user= (time (last (pmap fast-or-slow inputs Elapsed time: 163139.249677 msecs, 100% CPU pmap has zero effect on my system, it won't use more than one core. user= (time (last (pmapall fast-or-slow inputs Elapsed time: 37710.349712 msecs, ~793% CPU user= (time (last (pmap-pool fast-or-slow inputs Elapsed time: 36393.132824 msecs, ~795% CPU -- You 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 -- Lee Spector, Professor of Computer Science Cognitive Science, Hampshire College 893 West Street, Amherst, MA 01002-3359 lspec...@hampshire.edu, http://hampshire.edu/lspector/ Phone: 413-559-5352, Fax: 413-559-5438 -- You 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
Re: How do I add goog.ui.MenuItem or goog.ui.Option items to goog.ui.Select in clojurescript?
Well, I figured it out. It was working just fine. The problem was that the Options/MenuItems are added elsewhere to the dom. I didn't have the css loading so I just didn't notice that they were at the very bottom of the screen. On Oct 10, 9:25 pm, Eric Harris-Braun zippy.314@gmail.com wrote: Here's my clojurescript function: (defn make-select [elem-id] (let [select (goog.ui.Select. Heading) select-elem (d/element (keyword (str div# elem-id)))] (.addItemAt select (goog.ui.MenuItem. Item 1) 0) (.addItem select (goog.ui.Option. Item 2)) (.render select select-elem) select-elem)) When you add the results of a calling the above function as: (make-select :channel) to the DOM, it produces the following HTML in the browser: div id=channel div class=goog-inline-block goog-menu-button title= role=button style=-webkit-user-select: none; tabindex=0 aria- haspopup=true aria-pressed=false aria-expanded=false aria- activedescendant= div class=goog-inline-block goog-menu-button-outer-box div class=goog-inline-block goog-menu-button-inner-box div class=goog-inline-block goog-menu-button-caption Heading /div div class=goog-inline-block goog-menu-button-dropdown nbsp; /div /div /div /div /div So, where are the MenuItems or Options? I can't figure out what to do to get the items to be added! The generated Javascript looks a lot like the code in the demo at:http://closure-library.googlecode.com/svn/trunk/closure/goog/demos/se... Any help greatly appreciated. -- You 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: Libraries supporting 1.31.2 and bignums
(def +M (first [+' 1])) seems like it should work in both versions? On Oct 10, 4:28 pm, Brian Marick mar...@exampler.com wrote: I may be missing something obvious. Midje has a checker that lets users say things like (fact (my-computation) = (roughly 15 2)) Where the first number in `roughly` is the target number and the second is an acceptable range around that target. Part of what the checker does in 1.2 is this: (= expected (+ actual delta)) Now, Midje is a service. If the 1.3 user has taken care to use promoting-to-bignum arithmetic, it would be rude to blow up if `actual` happens to be a regular integer but adding `delta` to it causes an overflow. I should use promoting-to-bignum addition. In Clojure 1.3, thats +'. In 1.2, it's +. I can't use the token +' because it doesn't exist in 1.2: java.lang.ClassCastException: clojure.lang.Symbol cannot be cast to java.lang.Number (NO_SOURCE_FILE:0) I can't use the token + because that blows up in the boundary case under 1.3 (but not under 1.2). One thought is variations of code like this: (if (clojure-1-3?) (def +M +') (def +M +) This causes amusing results because of the quote. I haven't found a variation that works. So what should a library writer who wants to honor the choices of his users do? - Brian Marick, Artisanal Labrador Now working athttp://path11.com Contract programming in Ruby and Clojure Occasional consulting on Agile -- You 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: Suggestion needed for namespace management in modular clojure app
On Sun, Oct 9, 2011 at 8:48 AM, Stephen Compall stephen.comp...@gmail.com wrote: On Fri, 2011-10-07 at 19:07 +0530, Vivek Khurana wrote: I would prefer to have a modules directory where each module will create a sub directory and all files in the module sub directory expose a single namespace. So it sounds like you intend for module writers to be writing Clojure, but want to replace the standard way namespaces are done in Clojure (i.e. ns form at top of file). Not just clojure. Solution for clojure only code is simple. The application is a framework, which will expose some API and modules consuming the API, can be written in any JVM language. It is known that all modules will run from same instance of JVM. The issue is that I should be able to distinguish between the modules written by core team and modules written by others and cannot figure out the correct way to manage namespaces in this situation. When ever I try to use AOT I get errors. You should avoid AOT for this; indeed, perhaps modules shouldn't even go in the src/ directory, assuming you are using Leiningen or something with similar structure. Yes I am using Leiningen. Do you suggest I should host the modules out side the src ? Wont that create a classpath havoc ? Secondly, in case the modules are outside src, how will they compile ? Do I need to make any changes to Leingen configuration ? Also, is there a better way to manage namespaces in modular applications. I do not want the developers of modules to struggle with managing files and namespaces. If you wish to replace the standard Clojure conventions for managing files and namespaces, as codified by `require' and its ilk, these items will help you on your adventure: clojure.core/*ns* A clojure.lang.Namespace object representing the current namespace. clojure.core/load ([ paths]) Loads Clojure code from resources in classpath. snip clojure.core/load-file ([name]) Sequentially read and evaluate the set of forms contained in the file. You could bind `*ns*' to a namespace you construct yourself while loading the files that make up a module, in a guaranteed order of course. It might be difficult to guarantee the order when number of modules increase... regards Vivek -- The hidden harmony is better than the obvious!! -- You 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: Spread work onto multiple threads (in pure Clojure)
I'll post more on this later, but I wanted to point out one case where I found that pmap was not achieving the desired level of speedup (# of CPUs/cores) that you would initially expect, and it is not due to any reasons that I've posted about before. Imagine a 4-core CPU. There are 4 physical CPU cores on the same chip, so if you can find some computation task that is completely compute-bound, _and that computation task does not require reading from or writing to main memory or any other storage media like hard drives after it is warmed up_, then pmap or pmapall should ideally be able to achieve an elapsed time of 1/4 of doing the tasks sequentially. However, suppose instead that the computation task reads from a large data structure and creates a new large data structure as a result, and that the amount of memory reading is large compared to the amount of computation required. Then it is possible that the speedup will not be limited by the number of CPU cores available, but by the bandwidth that main memory can be read or written. For example, the 4 CPU cores in the hypothetical example might have a shared bus for writing to main memory that has a maximum capacity of 20 Gbytes/sec. If doing the tasks sequentially on one CPU core can completely use that CPU core, and require writing 10 Gbytes/sec to main memory, then it doesn't matter whether you have 2 cores or 50 cores on that chip, the 20 Gbytes/sec of write bandwidth to main memory will limit your parallel speedup to a factor of 2 (i.e. parallel run elapsed times will be at least 1/2 of the sequential elapsed times). I believe I have found similar cases where I did not have a large output data structure, but I simply generated data structures that very soon become garbage. Because I allocated them, and the garbage collector did not detect them as garbage until *after* they had been written from the CPU's cache to main memory, caused the parallel speedup to be limited by the CPU's write bandwidth to main memory, which was lower than the number of cores. In such cases, it would be ideal if the garbage collector could somehow be made smart enough to detect the allocated structures as garbage, and reallocate their memory, before they were ever written to main memory. This would allow that memory to stay in cache, and the computation could proceed with an order of magnitude less data written to main memory. Andy On Mon, Oct 10, 2011 at 6:55 PM, Lee Spector lspec...@hampshire.edu wrote: Interesting. I'll try some of your suggested tests to see if my pmapall all is behaving better than I thought. Does your pmap-pool permit nesting? (That is, does it permit passing pmap-pool a function which itself calls pmap-pool?). If so then that would be a reason to prefer it over my pmapall. Thanks, -Lee On Oct 10, 2011, at 9:43 PM, j-g-faustus wrote: I made an alternative implementation using a thread pool and a queue, based on the example at http://clojure.org/concurrent_programming In short, your pmapall and the pool-based implementation (below) both give approximately perfect scaling on my 4/8-core system (Intel i7 920 and HT). Both give close to full load on all cores and a factor 4.4 speedup compared to single threaded. This seems about right, the CPU has four physical cores and get a few percent extra performance from the virtual cores, so the speedup is approximately linear with the number of cores. pmap-pool may be a tiny bit faster than the pmapall, but they are so close that I can't really tell. It is possible that there is some sort of synchronization overhead on your 48-core machine. 95% of the tasks are practically noops, after all - just the cost of a single function call. There are only 48 tasks in your test that actually require computation, so each core will do a bunch of noops and perhaps one real task. In real time, a single i7 920 runs the test just as fast as your 48 cores. I don't expect that's representative for what your 48 cores can do. I suggest * Increase the test size and/or the density of heavy tasks. * Let the light tasks do a bit more computation, at least enough to pay for the overhead of calling them. * Start with a smaller number of threads, and see where it stops scaling linearly. Threadpool/queue-based implementation: (import '(java.util.concurrent Executors)) (defn pmap-pool [f coll] (let [queue (ref coll) ;; shared queue of work units nthreads (.availableProcessors (Runtime/getRuntime)) pool (Executors/newFixedThreadPool nthreads) tasks (map (fn [_] (fn [] ; one task per thread (let [local-res (atom [])] ;; collect results per thread to minimize synchronization (while (seq @queue) ;; queue may be emptied between 'while' ;; and 'dosync'.
