Re: Choosing a Clojure build tool
On Mar 26, 2010, at 12:59 AM, Per Vognsen wrote: On Fri, Mar 26, 2010 at 11:50 AM, Chas Emerick cemer...@snowtide.com wrote: Because they're common processes that are ideally built once, and then reused with minor variation. Library reuse is generally considered to be a good thing in software development, so it strikes me as odd that many think that such practices should stop at the build's edge, as it were. Reuse is great. Integration tends to hamper reuse. This is likely wading into a silly semantic dispute re: integration, but I'd say exactly the opposite. When libraries are easily accessible within a common platform, it is easier to use them (assuming you are also participating in that platform). JVM libraries *could* be dis-integrated into separate executables or whatever, but that surely wouldn't encourage their reuse. Please note that Maven plugins are entirely, thoroughly optional -- you choose which ones to bring into your environment, exactly analogous to choosing libraries to be reused in an application. It's worth considering how things have played out in other contexts. Take ant, where there *are* plugins for doing a variety of interesting things, but because there is no baseline platform and mechanism for roping in those plugins in a consistent way from environment to environment, they've seen far, far less adoption and usage than the analogous maven plugins, where composition and reliable configuration is enabled by a consistent platform and defined points of integration. To take one of your examples, if I want to bundle my classes and dependencies into a Windows installer, I will call a function in a library (or a command line program in the Unix world) that does that. That's it. It doesn't need to be part of the build system and shouldn't be. I can call functions in the build system to supply the relevant arguments. If the build tool and library is well designed, the added value of integration in this example should be infinitesimal. Yeah, I think we're butting up against semantics (or we have very, very different world views! :-) I'd ask: what *does* belong in a build system? Should compilation be included (doesn't matter which language)? There are command line programs to compile source files, so why bother with make, ant, etc.? Aside from that extreme example (certain suggested only for illustration), how does your preferred approach fare when working with others, and vice versa? Should we all write our own one-off build scripts, each one different from the last, and require our collaborators to grok each one's unique subtleties as needed? Cheers, - Chas -- You 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 To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
Re: Choosing a Clojure build tool
I'll have to agree with Brain here. As of now, all I need is Leiningen. It does what I want. Lein is a new project, and I'm fairly certain that it will be much more useful in the future. I don't think I've ever seen a language in which part of the community shunned build tools written in the language itself. It's quite hilarious. On Mar 25, 5:17 pm, Brian Carper briancar...@gmail.com wrote: On Mar 25, 11:55 am, Chas Emerick cemer...@snowtide.com wrote: I published a blog post earlier today, along with a short screencast that might be of interest: Like any group of super-smart programmers using a relatively new language, a lot of folks in the Clojure community have looked at existing build tools (the JVM space is the relevant one here, meaning primarily Maven and Ant, although someone will bark if I don't mention Gradle, too), and felt a rush of disdain. I'd speculate that this came mostly because of XML allergies, but perhaps also in part because when one has a hammer as glorious as Clojure, it's hard to not want to use it to beat away at every problem in sight. Ruby: gem install X Perl: perl -MCPAN -e shell, then install X Why does building and installing dependencies have to be harder than this? Lein right now tries to fill this niche of being braindead easy to use, and comes pretty close. I realize Maven does a lot more than build and install dependencies, but for some of us, that's all we want out of life, and it's pretty nice when it's that easy to do so. My dream tool would be: 1) Platform-agnostic (for us sorry souls stuck on Windows at work) 2) IDE-agnostic (make a Netbeans project is great, but Emacs users need some love too) 3) Easy to understand and use for the kinds of tasks Lein covers (I don't want to have to study a Maven book(!) if I can avoid it) 4) Able to handle most or all Clojure and Java libraries I want to install (I don't want to have to circumvent the build tool and do things manually if I can help it) 5) Able to easily browse or search for packages in remote repositories, would be nice Rubygems and Perl's CPAN can handle those kinds of things, for example. If Maven can be those things, I'll have an XML sandwich for lunch with a smile if necessary. : ) Maybe it can and the community just needs to standardize around Maven and provide good documentation and community support for using it with Clojure. I just hope the community standardizes around something; any standard is better than everyone using a different tool. Thanks --Brian -- You 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 To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
Re: Choosing a Clojure build tool
On 26/03/2010, at 4:37 PM, Rayne wrote: I don't think I've ever seen a language in which part of the community shunned build tools written in the language itself. It's quite hilarious. I've seen many examples where an overwhelming Not-Invented-Here attitude lead to failure. Antony Blakey -- CTO, Linkuistics Pty Ltd Ph: 0438 840 787 Isn't it enough to see that a garden is beautiful without having to believe that there are fairies at the bottom of it too? -- Douglas Adams -- You 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 To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
Re: referencing an atom inside a function used for swapping
Hi, construct the JPanel outside the atom, add all the listeners and then add the panel to structure in the atom. (let [panel (JPanel. ..)] (add-listener-stuff panel the-atom) (swap! the-atom assoc :SpiffyPanel panel)) Side-effecting things shouldn't be done inside the swap! since it can be retried multiple times. So you would set up a panel, find that you have to retry, start over, retry, start over, retry, Sincerely Meikel -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
Re: Choosing a Clojure build tool
On 26/03/2010, at 4:37 PM, Rayne wrote: I don't think I've ever seen a language in which part of the community shunned build tools written in the language itself. It's quite hilarious. People aren't shunning anything because it's written in Clojure. I think that reinventing all that Maven can do, all of the IDE support, tools, documentation etc is misdirected effort. Especially given the appearance of polyglot Maven (Maven 3), which is Maven recast as a Java library that can be driven by languanges such as Clojure. Antony Blakey - CTO, Linkuistics Pty Ltd Ph: 0438 840 787 Every task involves constraint, Solve the thing without complaint; There are magic links and chains Forged to loose our rigid brains. Structures, structures, though they bind, Strangely liberate the mind. -- James Fallen -- You 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 To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
Re: Choosing a Clojure build tool
On Fri, Mar 26, 2010 at 12:59 PM, Chas Emerick cemer...@snowtide.com wrote: On Mar 26, 2010, at 12:59 AM, Per Vognsen wrote: On Fri, Mar 26, 2010 at 11:50 AM, Chas Emerick cemer...@snowtide.com wrote: Because they're common processes that are ideally built once, and then reused with minor variation. Library reuse is generally considered to be a good thing in software development, so it strikes me as odd that many think that such practices should stop at the build's edge, as it were. Reuse is great. Integration tends to hamper reuse. This is likely wading into a silly semantic dispute re: integration, but I'd say exactly the opposite. When libraries are easily accessible within a common platform, it is easier to use them (assuming you are also participating in that platform). JVM libraries *could* be dis-integrated into separate executables or whatever, but that surely wouldn't encourage their reuse. Please note that Maven plugins are entirely, thoroughly optional -- you choose which ones to bring into your environment, exactly analogous to choosing libraries to be reused in an application. It's not semantic nitpicking. There's a clear-cut difference a piece of reusable code with a function that can be called to generate a bundled Windows installer based on a set of arguments versus something that only works as part of a build system like Maven. I never said they should be separate executables (that's a terrible fit for the JVM world). I mentioned that as an example of how composable systems are built in the Unix world. It's a good conceptual model. In the Clojure world, functions (not necessarily pure, though pure functions play an important role in idempotent building) are the obvious counterparts. It's worth considering how things have played out in other contexts. Take ant, where there *are* plugins for doing a variety of interesting things, but because there is no baseline platform and mechanism for roping in those plugins in a consistent way from environment to environment, they've seen far, far less adoption and usage than the analogous maven plugins, where composition and reliable configuration is enabled by a consistent platform and defined points of integration. I can't comment on Ant as my experience in the Java world is limited to non-existent. To take one of your examples, if I want to bundle my classes and dependencies into a Windows installer, I will call a function in a library (or a command line program in the Unix world) that does that. That's it. It doesn't need to be part of the build system and shouldn't be. I can call functions in the build system to supply the relevant arguments. If the build tool and library is well designed, the added value of integration in this example should be infinitesimal. I'd ask: what *does* belong in a build system? Should compilation be included (doesn't matter which language)? There are command line programs to compile source files, so why bother with make, ant, etc.? No, compilation should not be included. You mention make; it is a macro language, dependency graph walker, shell executor and up-to-dateness checker. It doesn't do any compilation. It's very bare bones. It's not at all perfect but it's much closer to what I want from a build system than something like Maven. Aside from that extreme example (certain suggested only for illustration), how does your preferred approach fare when working with others, and vice versa? Should we all write our own one-off build scripts, each one different from the last, and require our collaborators to grok each one's unique subtleties as needed? The same way it works with any well-written software. When I want to build the bundled Windows installer, I import the library (which knows nothing about my build system) and call a single function, passing along whatever configuration information is appropriate. Done. -Per -- You 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 To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
Re: Why I have chosen not to employ clojure
Yes, or CodeMirror (maybe more lightweight ?) 2010/3/26 Mark Derricutt m...@talios.com: I was thinking it might be interesting to see if we could integrate Bespin Embedded in labrepl, having a nice web based syntax highlighting editor thats consistent on platforms could be quite cool. -- Pull me down under... On Wed, Mar 24, 2010 at 4:26 AM, Stuart Halloway stuart.hallo...@gmail.com wrote: You also get this with the labrepl (http://github.com/relevance/labrepl) which is free. Plus I am attempting (with a little help from you all) to keep the labrepl working with various IDEs. -- You 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 To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject. -- You 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 To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
Re: Choosing a Clojure build tool
Is there a tool which takes a simple config file as input in some human readable format (like below) and generate mavel pom xml? name: foobar version: x.y.z dependencies: clojure (= 1.1.0), clojure-contrib (= 1.1.0) ... ... Ramakrishnan -- You 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 To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
Re: concurrency and rand-int
There is a fast Java version of Mersenne Twister here, if you feel like compiling a java file: http://cs.gmu.edu/~sean/research/ On 26 mar, 05:43, Chas Emerick cemer...@snowtide.com wrote: I was going to suggest something similar using seque in an atom, but in neither case (using an atom or a ref) is the contention going to be minimized -- just shifted from the AtomicLong in java.util.Random to the now-app-level atom or ref. - Chas On Mar 26, 2010, at 12:30 AM, Andrzej wrote: As others have pointed out using per-thread java.util.Random objects is probably the best way to go in this particular case. However, I'm curious if the following code could give any speed gain on your machine: (defn rand-seq [] (repeatedly #(. Math (random (def rand-seq-ref (ref (rand-seq))) (nth @rand-seq-ref 100) ;; pre-cache random values; evaluate it every some time ;;btw, how to do it automatically? (defn next-rand-val [] (dosync (commute rand-seq-ref next) (first @rand-seq-ref))) user= (next-random-val) 0.5558267606843464 user= (next-random-val) 0.32353157456467474 Cheers, Andrzej On Fri, Mar 26, 2010 at 11:35 AM, Lee Spector lspec...@hampshire.edu wrote: I'm trying to track down the reason that I sometimes see a lot of concurrency in my system (up to 1200% CPU utilization on a dual quadcore mac that also has some kind of hyperthreading, allegedly allowing a maximum of 1600% CPU) while other times it gets stuck at around 100-200%. My system (a genetic programming system) has a *lot* of randomness in it, so it's hard to repeat runs and get a firm handle on what's going on. But after a bunch of testing I'm beginning to suspect that it might be the random number generator itself (clojure-core/rand-int in this case, which calls (. Math (random))). This seems at least somewhat plausible to me because I guess that the underlying Java random method must be accessing and updating a random number generator state, and so this would be a concurrency bottleneck. So if I'm in a condition in which lots of concurrent threads are all calling rand-int a lot then all of the accesses to the state have to be serialized and my concurrency suffers (a lot). Does this sound plausible to you? If so, is there a straightforward way to avoid it? It is not important to me that the random numbers being generated in different threads be generated from the same generator or coordinated/seeded in any way. I just need lots of numbers that are random enough. I guess I could roll my own random number generator(s) and either have a lot of them with independent states or maybe even make them stateless (always generating numbers by scrambling the clock?). But I would hope there would be something simpler. Thanks, -Lee -- Lee Spector, Professor of Computer Science School of 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 Check out Genetic Programming and Evolvable Machines: http://www.springer.com/10710-http://gpemjournal.blogspot.com/ -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com 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 To unsubscribe from this group, send email to clojure +unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject. -- You 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 To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
Re: Choosing a Clojure build tool
On 26 Mar 2010, at 05:50, Chas Emerick wrote: Because they're common processes that are ideally built once, and then reused with minor variation. Library reuse is generally considered to be a good thing in software development, so it strikes me as odd that many think that such practices should stop at the build's edge, as it were. Reuse is fine, libraries are fine. But Maven seems to be a monolithic beast that does a zillion things automatically and without telling me. Sure, I can always add some magic incantations on the command line to change whatever I want, but I need to know and understand all that. What I like is the Unix approach: each tool does one thing but does it well, and a flexible combination method (shells and pipes in the Unix case) permits everyone to customize the operations as necessary. That doesn't prevent anyone from providing easy-install scripts for end users, of course. My two biggest gripes with Maven (which may be due to my ignorance) are: 1) No clear separation between building and dependency resolution. I want to be able to build and test my code with known versions of everything that are on my machine. This seems to be possible with Maven, but it's not made easy, and I haven't yet figured out how to verify that a build uses my versions instead of the versions downloaded from some repository that I didn't even pick myself. 2) Bad system integration. Maven is the only tool on my Mac that has its own proxy configuration. Everything else uses either the system settings (ideal) or takes the proxy from an environment variable. All those tools adapt automatically when I change networks (twice a day). Only Maven requires me to edit $HOME/.m2/settings.xml twice a day. Konrad. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com 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 To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
Re: Choosing a Clojure build tool
On Fri, Mar 26, 2010 at 1:06 PM, Konrad Hinsen konrad.hin...@fastmail.net wrote: On 26 Mar 2010, at 05:50, Chas Emerick wrote: Because they're common processes that are ideally built once, and then reused with minor variation. Library reuse is generally considered to be a good thing in software development, so it strikes me as odd that many think that such practices should stop at the build's edge, as it were. Reuse is fine, libraries are fine. But Maven seems to be a monolithic beast that does a zillion things automatically and without telling me. Sure, I can always add some magic incantations on the command line to change whatever I want, but I need to know and understand all that. What I like is the Unix approach: each tool does one thing but does it well, and a flexible combination method (shells and pipes in the Unix case) permits everyone to customize the operations as necessary. That doesn't prevent anyone from providing easy-install scripts for end users, of course. Yes, I have exactly same feelings as well. IMHO, ant fits the task of the build tool very well. I never really understood why clojure-contrib moved to maven. What is needed is a tool to handle just the dependencies part. -- Ramakrishnan -- You 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 To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
Re: Choosing a Clojure build tool
Fully agree, reinventing the wheel is not a good time investment. Ant has been there for years, why not reuse it ? Why reinvent Ant (or Maven) in Clojure ? The fact that they may look ugly and cumbersome to use has to be separated from the benefits they provide. We switched to Leiningen here and created an internal Maven repository with Archiva for our own components. Leiningen implements in Clojure a simplified build interface, this is where the niceties are for users. It take cares of the house keeping for you and this is where we want a tool to save us time. Aside from resolving our dependencies in Maven repositories on the net and loading a few unknowns to our internal repository, we did not have anything else to do build wise. We have around 100 dependencies here and were looking for a way to simplify this management. Leiningen does it. If Ant or Maven changes, most of these impacts will most probably be hidden in Leiningen. We could not care less about the internal details... that's not where we see the added value of a build/deployment tool, it's in the day to day use by normal developers (non-Maven/Ant experts). Leiningen can handle simple projects as well as complex ones, why create yet another tool/tool-set ? For the sake of having it written 100% in Clojure ? Efforts should be focused on improving Leiningen when needed, not on creating another gizmo. As for the obsessive desire to get an integrated build/deployment tool, picture this, we need to manage all the above dependencies plus our own components AND multiple costumer site configurations. Having some simple automation here is an absolute requirement. We will add a deployment plugin to Leiningen this year to manage our deployments at customer sites. A Rails/Ruby one is also on the table. I do not call this hilarious (or obsessive), it's called common sense. Humans could still be reinventing fire every century but there's no added value to this process. Luc P. On Fri, 2010-03-26 at 16:49 +1030, Antony Blakey wrote: On 26/03/2010, at 4:37 PM, Rayne wrote: I don't think I've ever seen a language in which part of the community shunned build tools written in the language itself. It's quite hilarious. I've seen many examples where an overwhelming Not-Invented-Here attitude lead to failure. Antony Blakey -- CTO, Linkuistics Pty Ltd Ph: 0438 840 787 Isn't it enough to see that a garden is beautiful without having to believe that there are fairies at the bottom of it too? -- Douglas Adams -- You 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 To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
Re: Choosing a Clojure build tool
On Mar 26, 8:53 am, Per Vognsen per.vogn...@gmail.com wrote: It's not semantic nitpicking. There's a clear-cut difference a piece of reusable code with a function that can be called to generate a bundled Windows installer based on a set of arguments versus something that only works as part of a build system like Maven. I think this is mistaken. Your piece of reusable code still needs to know enough about the build system used to build the bundled windows application. Sure, the maven plugins can't be used unless you also use maven itself, but the advantage is that you don't need to configure the plugin to work with the build system... That's automatic. You could always write a maven plugin that invokes your function and configures it properly for the maven build in question. The point still remains that anyone using maven need not care about those details, as they're the plugin's responsibility. No, compilation should not be included. You mention make; it is a macro language, dependency graph walker, shell executor and up-to-dateness checker. It doesn't do any compilation. It's very bare bones. It's not at all perfect but it's much closer to what I want from a build system than something like Maven. Again, I think this is mistaken. Make alone, as you describe it, is *not* a build system. You have to do lots of manual work to make your application build if you use plain make, most of which a system like maven can do for you, since it's configured declaratively. With maven, you don't usually tell it what to do, you need to tell it what you want; and I think that is how a build system should be. -- You 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 To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
Re: Help optimizing array-to-integer operation?
The problem you're seeing is again due to bytes being a signed number, in particular because widening conversions preserve the sign, thus left-padding with ones if the MSB is one (i.e., a negative number). Since bit-shift-left converts the byte to an int, the 0xFF byte becomes a 0x int. When you start with ints instead of bytes, the int is just 0xFF, thus no leading ones. If you're playing with bytes, you always have to bit-mask the widening conversions to deal with sign issues. In fact you handled this in your original java code by using 0xFF against each byte prior to shifting. On Mar 25, 3:54 pm, Raph mart...@gmail.com wrote: On Mar 24, 10:57 am, Mark J. Reed markjr...@gmail.com wrote: On Tue, Mar 23, 2010 at 8:19 PM, Raph mart...@gmail.com wrote: (My opinion, anyway.I think a byte should be 8 bits and I should be able to use all of them.) Er, it is, and you can. A Java byte still gives you all 8 bits' worth of 256 different possible values; the interpretation of those values is all that differs here. Whereas C lets you pick between signed and unsigned (with the default unfortunately not always well-defined), Java gives you no choice but to use the signed interpretation. But you still get to use all 8 bits of the byte; it's just that the numbers mapped to [128, 255] in unsigned interpretations map to [-128,-1] instead. Right, should have been more specific. The 0xFF byte doesn't work the way I expect it to. I have to use ints to get the correct answer. (bit-or (bit-shift-left (byte 0x01) 16) (bit-shift-left (byte 0x7F) 8)) = 98048 (bit-or (bit-shift-left (int 0x01) 16) (bit-shift-left (int 0x7F) 8)) = 98048 But... (bit-or (bit-shift-left (byte 0x01) 16) (bit-shift-left (byte 0xFF) 8)) = -256 (bit-or (bit-shift-left (int 0x01) 16) (bit-shift-left (int 0xFF) 8)) = 130816 So I can't use the bits the way I'd expect. Raph -- You 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 To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
Re: Choosing a Clojure build tool
Hello Brian Carper at Thu, 25 Mar 2010 15:17:10 -0700 (PDT) wrote: BC On Mar 25, 11:55 am, Chas Emerick cemer...@snowtide.com wrote: I published a blog post earlier today, along with a short screencast that might be of interest: Like any group of super-smart programmers using a relatively new language, a lot of folks in the Clojure community have looked at existing build tools (the JVM space is the relevant one here, meaning primarily Maven and Ant, although someone will bark if I don't mention Gradle, too), and felt a rush of disdain. I'd speculate that this came mostly because of XML allergies, but perhaps also in part because when one has a hammer as glorious as Clojure, it's hard to not want to use it to beat away at every problem in sight. BC Ruby: gem install X BC Perl: perl -MCPAN -e shell, then install X BC Why does building and installing dependencies have to be harder than BC this? Lein right now tries to fill this niche of being braindead easy BC to use, and comes pretty close. I realize Maven does a lot more than BC build and install dependencies, but for some of us, that's all we want BC out of life, and it's pretty nice when it's that easy to do so. Maven is good because of many plugins written for it. I know some peoples who are using maven to build projects written in mix of erlang, flash, etc. I use maven to automatically generate installers using izpack plugin, for example. May be we'll need to provide better documentation for work with Clojure from maven. -- With best wishes, Alex Ott, MBA http://alexott.blogspot.com/ http://alexott.net http://alexott-ru.blogspot.com/ -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com 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 To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
Re: Choosing a Clojure build tool
I often want to add a custom task to a build, just as an example, I might want to call a Java method in my code after it has built which will generate a property file to be included in the distribution. If this was just a make file or some sort batch file, then that would just be an extra line in the build file. In ant, yeah, it would be padded out with lots of XML, but it would still be the addition of a fairly simple ant task. In leiningen, it seems that I can create a leiningen/*.clj file with a clojure function in it which will call my task. In Maven, it seems that I have to go through this procedure? http://maven.apache.org/guides/plugin/guide-java-plugin-development.html ... creating a Java class, annotating it with metadata, creating an XML manifest file for it, packaging it in a jar file, installing it in the local maven repository, referring to it from the project's pom. Is it really that complicated? -- Dave -- You 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 To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
Re: Choosing a Clojure build tool
2010/3/26 David Powell djpow...@djpowell.net: I often want to add a custom task to a build, just as an example, I might want to call a Java method in my code after it has built which will generate a property file to be included in the distribution. If this was just a make file or some sort batch file, then that would just be an extra line in the build file. In ant, yeah, it would be padded out with lots of XML, but it would still be the addition of a fairly simple ant task. In leiningen, it seems that I can create a leiningen/*.clj file with a clojure function in it which will call my task. In Maven, it seems that I have to go through this procedure? http://maven.apache.org/guides/plugin/guide-java-plugin-development.html ... creating a Java class, annotating it with metadata, creating an XML manifest file for it, packaging it in a jar file, installing it in the local maven repository, referring to it from the project's pom. Is it really that complicated? Maybe, so you could do this once and for all by writing the missing plugin which can take as an argument a command line, or best, which can take as an argument the name of a clojure script to play ? :-) And maybe contribute this to maven-clojure-plugin ? :-) -- You 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 To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
Re: Choosing a Clojure build tool
Hi, On Mar 25, 11:17 pm, Brian Carper briancar...@gmail.com wrote: Ruby: gem install X Perl: perl -MCPAN -e shell, then install X Why does building and installing dependencies have to be harder than this? I think you got this backwards. With maven, ant (ie. Ivy), gradle and leiningen this similar easy to do. Just add the dependency to your configuration file. What is complicated about maven, ant (ie. Ivy), gradle and leiningen (in various degrees) is the other part: the build process itself. And this isn't solved by gems, easy_install or CPAN neither. (configure scripts, native compilation problems (esp. on Windows), ) Sincerely Meikel -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
Re: Choosing a Clojure build tool
On Mar 26, 2010, at 5:35 AM, David Powell wrote:
I often want to add a custom task to a build, just as an example, I
might want to call a Java method in my code after it has built which
will generate a property file to be included in the distribution.
If this was just a make file or some sort batch file, then that would
just be an extra line in the build file.
In ant, yeah, it would be padded out with lots of XML, but it would
still be the addition of a fairly simple ant task.
In leiningen, it seems that I can create a leiningen/*.clj file with a
clojure function in it which will call my task.
In Maven, it seems that I have to go through this procedure?
http://maven.apache.org/guides/plugin/guide-java-plugin-development.html
Is it really that complicated?
No. :-)
If you're looking to simply run a function after the build, if you're
using maven, then you can either use the exec plugin (which can invoke
any command line you like, or start up java with any options you want
-- including all of your build and/or test dependencies, or not).
If you're looking to run a clojure script, clojure-maven-plugin has a
'run' goal that is a thin wrapper around the exec plugin's
functionality. Thus, here's a chunk our of one of our pom.xml files
that runs a script during the compile phase to generate a file we
include in our .war file (we have others that run in other phases,
such as to prep and tear down databases around functional tests, etc):
execution
idgenerate-design-doc-json/id
phasecompile/phase
goals
goalrun/goal
/goals
configuration
script${basedir}/src/main/clojure/com/snowtide/couchdb.clj/
script
argsassemble-ddoc-json/args
clojureOptions-Ddb.dir=databases -Ddb.assembly.target=$
{project.build.directory}/classes//clojureOptions
/configuration
/execution
Certainly, this is not something that requires creating a new plugin
-- just re-using the entry points that are there already.
... creating a Java class, annotating it with metadata, creating an
XML manifest file for it, packaging it in a jar file, installing it in
the local maven repository, referring to it from the project's pom.
Now, it *would* be nice, when it's really called for, to be able to
create a maven plugin using clojure. The API is just a pile of
interfaces, so it's fundamentally the same as implementing any other
Java API. As for having to package it -- if you're using maven,
that's trivial. ;-) (And a good thing to do regardless, so as to,
again, promote reuse.)
Cheers,
- Chas
--
You 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
To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or
reply to this email with the words REMOVE ME as the subject.
Re: Choosing a Clojure build tool
On Mar 26, 2010, at 4:33 AM, Jarkko Oranen wrote: No, compilation should not be included. You mention make; it is a macro language, dependency graph walker, shell executor and up-to-dateness checker. It doesn't do any compilation. It's very bare bones. It's not at all perfect but it's much closer to what I want from a build system than something like Maven. Again, I think this is mistaken. Make alone, as you describe it, is *not* a build system. You have to do lots of manual work to make your application build if you use plain make, most of which a system like maven can do for you, since it's configured declaratively. With maven, you don't usually tell it what to do, you need to tell it what you want; and I think that is how a build system should be. I would add to this that Maven, if one wants to be (IMO) pedantic about it, isn't a build system at all -- it's a shell that includes the bits needed for dependency resolution and command execution. Everything else comes down as plugins (which is where the hyperbole comes in about maven downloading the internet). Of course, everyone uses it as a build system, just like everyone uses make as a build system. Cheers, - Chas -- You 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 To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
Re: concurrency and rand-int
Thanks all for the quick and helpful responses on the issues with rand-int/rand and concurrency. I probably have some other issues that are also gumming up some of my concurrency, but following the advice on of creating per-thread java.util.Random objects *seems* to have helped, although it's a little hard to tell and I'm not sure I did it right. What I did was: (def thread-local-random-state (new java.util.Random)) ;; just an initial global binding (defn lrand-int Return a random integer using the thread-local random state. [n] (if ( n 1) 0 (. thread-local-random-state (nextInt n (defn lrand Return a random float between 0 and 1 usng the thread-local random state. [] (. thread-local-random-state (nextFloat))) And then I wrap the bodies of the the functions that I pass to send (which is the only way I launch threads) with: (binding [thread-local-random-state (new java.util.Random)] everything else goes here, with calls that make calls that eventually call lrand-int and lrand ) Is that the right way to do it? Thanks, -Lee On Mar 26, 2010, at 3:30 AM, mac wrote: There is a fast Java version of Mersenne Twister here, if you feel like compiling a java file: http://cs.gmu.edu/~sean/research/ On 26 mar, 05:43, Chas Emerick cemer...@snowtide.com wrote: I was going to suggest something similar using seque in an atom, but in neither case (using an atom or a ref) is the contention going to be minimized -- just shifted from the AtomicLong in java.util.Random to the now-app-level atom or ref. - Chas On Mar 26, 2010, at 12:30 AM, Andrzej wrote: As others have pointed out using per-thread java.util.Random objects is probably the best way to go in this particular case. However, I'm curious if the following code could give any speed gain on your machine: (defn rand-seq [] (repeatedly #(. Math (random (def rand-seq-ref (ref (rand-seq))) (nth @rand-seq-ref 100) ;; pre-cache random values; evaluate it every some time ;;btw, how to do it automatically? (defn next-rand-val [] (dosync (commute rand-seq-ref next) (first @rand-seq-ref))) user= (next-random-val) 0.5558267606843464 user= (next-random-val) 0.32353157456467474 Cheers, Andrzej On Fri, Mar 26, 2010 at 11:35 AM, Lee Spector lspec...@hampshire.edu wrote: I'm trying to track down the reason that I sometimes see a lot of concurrency in my system (up to 1200% CPU utilization on a dual quadcore mac that also has some kind of hyperthreading, allegedly allowing a maximum of 1600% CPU) while other times it gets stuck at around 100-200%. My system (a genetic programming system) has a *lot* of randomness in it, so it's hard to repeat runs and get a firm handle on what's going on. But after a bunch of testing I'm beginning to suspect that it might be the random number generator itself (clojure-core/rand-int in this case, which calls (. Math (random))). This seems at least somewhat plausible to me because I guess that the underlying Java random method must be accessing and updating a random number generator state, and so this would be a concurrency bottleneck. So if I'm in a condition in which lots of concurrent threads are all calling rand-int a lot then all of the accesses to the state have to be serialized and my concurrency suffers (a lot). Does this sound plausible to you? If so, is there a straightforward way to avoid it? It is not important to me that the random numbers being generated in different threads be generated from the same generator or coordinated/seeded in any way. I just need lots of numbers that are random enough. I guess I could roll my own random number generator(s) and either have a lot of them with independent states or maybe even make them stateless (always generating numbers by scrambling the clock?). But I would hope there would be something simpler. Thanks, -Lee -- Lee Spector, Professor of Computer Science School of 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 Check out Genetic Programming and Evolvable Machines: http://www.springer.com/10710-http://gpemjournal.blogspot.com/ -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com 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 To unsubscribe from this group, send email to clojure +unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject. -- You received this message because you are subscribed to the
Re: concurrency and rand-int
Just as long as your binding form is within the function body, you're good to go. e.g., you need to do this (or its equivalent): (send some-agent #(binding [random-state (Random.)] (other-fns %))) *not* this: (binding [random-state (Random.)] (send some-agent other-fns)) The latter will cause the sent fn to be invoked outside the scope of the binding. I wrote up a little guide on some of the wrinkles of binding some months ago: http://muckandbrass.com/web/display/~cemerick/2009/11/03/Be+mindful+of +Clojure%27s+binding On a very minor note, these forms are more syntactically idiomatic: (java.util.Random.) (.nextFloat random-state) (.nextInt random-state n) Cheers, - Chas On Mar 26, 2010, at 8:14 AM, Lee Spector wrote: Thanks all for the quick and helpful responses on the issues with rand-int/rand and concurrency. I probably have some other issues that are also gumming up some of my concurrency, but following the advice on of creating per-thread java.util.Random objects *seems* to have helped, although it's a little hard to tell and I'm not sure I did it right. What I did was: (def thread-local-random-state (new java.util.Random)) ;; just an initial global binding (defn lrand-int Return a random integer using the thread-local random state. [n] (if ( n 1) 0 (. thread-local-random-state (nextInt n (defn lrand Return a random float between 0 and 1 usng the thread-local random state. [] (. thread-local-random-state (nextFloat))) And then I wrap the bodies of the the functions that I pass to send (which is the only way I launch threads) with: (binding [thread-local-random-state (new java.util.Random)] everything else goes here, with calls that make calls that eventually call lrand-int and lrand ) Is that the right way to do it? Thanks, -Lee On Mar 26, 2010, at 3:30 AM, mac wrote: There is a fast Java version of Mersenne Twister here, if you feel like compiling a java file: http://cs.gmu.edu/~sean/research/ On 26 mar, 05:43, Chas Emerick cemer...@snowtide.com wrote: I was going to suggest something similar using seque in an atom, but in neither case (using an atom or a ref) is the contention going to be minimized -- just shifted from the AtomicLong in java.util.Random to the now-app-level atom or ref. - Chas On Mar 26, 2010, at 12:30 AM, Andrzej wrote: As others have pointed out using per-thread java.util.Random objects is probably the best way to go in this particular case. However, I'm curious if the following code could give any speed gain on your machine: (defn rand-seq [] (repeatedly #(. Math (random (def rand-seq-ref (ref (rand-seq))) (nth @rand-seq-ref 100) ;; pre-cache random values; evaluate it every some time ;;btw, how to do it automatically? (defn next-rand-val [] (dosync (commute rand-seq-ref next) (first @rand-seq-ref))) user= (next-random-val) 0.5558267606843464 user= (next-random-val) 0.32353157456467474 Cheers, Andrzej On Fri, Mar 26, 2010 at 11:35 AM, Lee Spector lspec...@hampshire.edu wrote: I'm trying to track down the reason that I sometimes see a lot of concurrency in my system (up to 1200% CPU utilization on a dual quadcore mac that also has some kind of hyperthreading, allegedly allowing a maximum of 1600% CPU) while other times it gets stuck at around 100-200%. My system (a genetic programming system) has a *lot* of randomness in it, so it's hard to repeat runs and get a firm handle on what's going on. But after a bunch of testing I'm beginning to suspect that it might be the random number generator itself (clojure-core/rand-int in this case, which calls (. Math (random))). This seems at least somewhat plausible to me because I guess that the underlying Java random method must be accessing and updating a random number generator state, and so this would be a concurrency bottleneck. So if I'm in a condition in which lots of concurrent threads are all calling rand-int a lot then all of the accesses to the state have to be serialized and my concurrency suffers (a lot). Does this sound plausible to you? If so, is there a straightforward way to avoid it? It is not important to me that the random numbers being generated in different threads be generated from the same generator or coordinated/seeded in any way. I just need lots of numbers that are random enough. I guess I could roll my own random number generator(s) and either have a lot of them with independent states or maybe even make them stateless (always generating numbers by scrambling the clock?). But I would hope there would be something simpler. Thanks, -Lee -- Lee Spector, Professor of Computer Science School of 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 Check out Genetic Programming and Evolvable Machines:
Re: Beginning Clojure. Recursion
(require 'clojure.contrib.seq-utils)
(defn word-count [s]
(frequencies (re-seq #[a-zA-ZöäüÖÄÜß]+ s)))
(word-count foo bar baz quux quux foo)
; {quux 2, baz 1, bar 1, foo 2}
Matt
On Mar 25, 4:09 pm, jfr janfrider...@googlemail.com wrote:
Thanks I will take a look at it .Neverless, the idea was to write my
own code ;-)
You can also use frequencies from c.c.seq-utils (http://
richhickey.github.com/clojure-contrib/seq-api.html#clojure.contrib.seq/
frequencies)
HTH,
--
Miki
--
You 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
To unsubscribe from this group, send email to
clojure+unsubscribegooglegroups.com or reply to this email with the words
REMOVE ME as the subject.
Re: concurrency and rand-int
On Fri, Mar 26, 2010 at 9:55 AM, Chas Emerick cemer...@snowtide.com wrote: Hi Lee, Indeed -- from the docs for Math.random(): This method is properly synchronized to allow correct use by more than one thread. However, if many threads need to generate pseudorandom numbers at a great rate, it may reduce contention for each thread to have its own pseudorandom-number generator. At its root, java.util.Random uses an AtomicLong to store the last dispensed pseduorandom number Nitpick: The state of a production-quality PRNG is never the last number it generated. That would mean you could initialize your own instance of the algorithm with the last number you saw it output and immediately duplicate all its future output. -Per -- You 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 To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
Re: Choosing a Clojure build tool
On Fri, Mar 26, 2010 at 7:33 AM, Chas Emerick cemer...@snowtide.com wrote: Now, it *would* be nice, when it's really called for, to be able to create a maven plugin using clojure. The API is just a pile of interfaces, so it's fundamentally the same as implementing any other Java API. As for having to package it -- if you're using maven, that's trivial. ;-) (And a good thing to do regardless, so as to, again, promote reuse.) Cheers, - Chas FWIW, this is trivial with Leiningen. Another reason I won't be moving to a Maven setup until things are further along there. If the legwork is done to make Maven fun to use when hacking on Clojure, people will use it. Keyword fun. 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 To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
Re: Why I have chosen not to employ clojure
Hello Ronan, By the way, if someone has an idea about a sample application (simple, but not trivial) which could lead the tutorial, and show different aspects of the language, let me know ! I was thinking about a more complete and idiomatic version of Vincent Foley's Fetching web comics tutorial, but something more enterprisey seems more adequate. I have a slightly more - a full application, it is a tool which I wrote to save someone around one hour per week of doing monkey work (nothing against monkeys, I just do not like when people waste their time on what computer can do for them, so I wasted some of mine on learning clojure better while doing something useful). The input is an excel spreadsheet, this spread-sheet is read (using libraries developed at apache project), checked whether it is valid (i.e. user opened the right kind), parsed (nothing too complicated), filtered (what the user needed was a subset according to few rules), and written to a new file in which the data split in 3 pages - all (for checking), not-interesting (what user does not want) and interesting (the stuff the user needs to make informed jugement). The result is, that instead of manually checking 100s spread-sheet records (the input spread-sheet was output from a database, btw), one only needs to check few. The app also reports reasonable errors and possibly exceptions (which can be cut-and-pasted - they do not pop up as dialog boxes), so this could be fed back to the programmer (me) to get a clue where the problem is. The program is not too long, reasonably structured (I wrote it twice, the first version with focus to make it work and learn, the second to like the code and the result), I could add more comments (to the code) as it was not too long ago that I wrote it. Also, I am pretty sure, someone with higher mastery of clojure-fu could improve it (my main motivation here is for other people not to pick up possibly bad beginners (mine) habits if there are some in there). Please e-mail me privately if interested. Kind regards, Vladimir -- You 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 To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
Re: Choosing a Clojure build tool
On Mar 26, 2010, at 10:18 AM, David Nolen wrote: Now, it *would* be nice, when it's really called for, to be able to create a maven plugin using clojure. The API is just a pile of interfaces, so it's fundamentally the same as implementing any other Java API. As for having to package it -- if you're using maven, that's trivial. ;-) (And a good thing to do regardless, so as to, again, promote reuse.) Cheers, - Chas FWIW, this is trivial with Leiningen. Another reason I won't be moving to a Maven setup until things are further along there. If the legwork is done to make Maven fun to use when hacking on Clojure, people will use it. Keyword fun. AFAICT, the situation is exactly the same, except maven has a Java API whereas lein is pure-clojure. I hope implementing a Java API isn't considered legwork. ;-) - Chas -- You 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 To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
Re: Choosing a Clojure build tool
On 25 March 2010 22:17, Brian Carper briancar...@gmail.com wrote: On Mar 25, 11:55 am, Chas Emerick cemer...@snowtide.com wrote: Why does building and installing dependencies have to be harder than this? Lein right now tries to fill this niche of being braindead easy to use, and comes pretty close. I realize Maven does a lot more than build and install dependencies, but for some of us, that's all we want out of life, and it's pretty nice when it's that easy to do so. Agreed. I know next to nothing about maven, other than it scared me back in my java days. It seems at first glance to be pretty impenetrable (at least in terms of how it is documented), and that's not say that I wasn't blown away by Chas's screencast. I'd certainly consider maven now or at least try it when my projects get bigger and require more than lein has to offer. Is there not an analogy to be drawn here between labrepl and lien? It seems both are targetted at being approachable to Clojure beginners (and in the case of lein small projects). labrepl isn't aiming to be the environment you run complex clojure projects with, and in the same way it seems that at some point you might want to migrate from lein to maven. I'd assumed that migrating a lein based project to a maven one (if required) would be as simple as running: $ lein pom Then when you're ready you can rm project.clj and just tweak your pom.xml for a pure maven build. If this is the case then lein seems to allow people to delay learning maven, which is a complex or at least daunting moving part in a complex environment. Not something you want to have to learn or adopt whilst straining to understand Clojure. Maven seems to be a polarising tool, some people love it and others hate it... This much we know. So anything we can do to prevent clojure being tarnished by the maven haters, the better. lein seems to be a good step in this direction, and is possibly even a gentle introduction to maven for those wishing (or requiring) to make the jump. Is it possible for us as a community to agree on this much? R. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
ANN: Kanshiki Boom! - Japanese handwriting recognition
I'd like to announce 漢識 Boom!, a handwriting recognition software for Japanese Kanjis. It is available at http://dueck.org/kanshiki-boom/ Currently, it will be useful mainly for learners of the Japanese language, as * it requires the user to use the official stroke order and direction (although I added some variants that are often used by Japanese) * it is able to recognize only the 2000 basic Kanjis (I am using Todd Rubick's unistrok file, with minor changes). It is still beta quality, I guess, but do give it a try and let me know of any issues, preferably via the @-button in the program itself. Why do I announce it here? * It's written in Clojure - which rocks, as we all (except this one guy recently who threatened to unsubscribe from the group if someone responds to his post ;) know very well * If there's enough interest in the algorithm and the implementation of it in Clojure, I might also post/blog about it and GPL the source code And finally, this program works for me, so I am using it as-is and I stopped improving it. But real users (if any) giving feedback would probably motivate me to iron out any remaining issues and to turn this into something that is useful for a broader audience - and I do have a lot of ideas for improvement, just not the motivation to do it right now. Examples: * support kana * detect radicals / let user compose kanjis out of radicals * fine-tune the recognition algorithm * switch to a different data set, so recognition can be better, we get more kanjis and this can actually be useful for advanced and even native Japanese speakers Cheers Eugen -- You 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 To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
Re: ANN: Kanshiki Boom! - Japanese handwriting recognition
This looks neat. I probably won't find much use for it though, as my input method already has this functionality, and even that doesn't get much use due to the fact that I am horrible at writing kanji with the mouse (I'm left-handed, but my mouse-hand is right.) If you have no plans to try to make money with this thing, I you suggest simply put the thing on github so that interested people can take a look. I don't think it's worth keeping things like this hidden. Note that if you do so you should choose a licence other than GPL, because it's known to be incompatible with EPL which Clojure uses. (EPL is a slightly weaker copyleft licence, more like LGPL). EPL is the most common choice, but of course a BSD-style licence is fine as well. -- You 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 To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
Re: Choosing a Clojure build tool
I'm not familiar with labrepl (except by name), but I think this is *exactly* right, as long as people do realize that maven is the next natural step from lein as soon as they have build requirements beyond running repls and maybe wrapping up a jar. Insofar as any higher- level tool provides UIs (text and script-based, like lein and other clojure build tools, or graphical, as with the NetBeans maven UI) that people are happy with, I think they're fabulous. I only take issue with the reimplementation of functionality that is otherwise ready-at- hand and any barriers that might be erected that prevent interoperability and collaboration. A semi-final thought: Clojure is a JVM language. This fact is inescapable, and implies a lot of things (for good, and very, very occasionally, for ill). One implication IMO is that we should collectively aim to cooperate, collaborate, and interoperate with the rest of the JVM world, for our own benefit as well as for our neighbors'. We gain a lot by being able to develop on and deploy to the JVM, and like any other software community, part of the culture has to do with how software is built, deployed, and managed. This is all completely orthogonal to the utility of Clojure as a programming language, and is a predominantly social concern. Most of us already know the relative joy that comes with being able to drop our Clojure- based application off in a client or customer's hands as a jar or war file, without the consternation or difficulties that might ensue if Clojure were a platform-less island. There's a great deal of currency that also comes with being able to hand a project that contains Clojure code off to another JVM developer and have confidence that they'll be able to build, configure, and deploy that project without special intervention using tools they're familiar with. That's a win for Clojure, and therefore very much in our interest. A P.S. on that thought is that I'd expect ClojureCLR projects to use whatever it is they use in .NET-land for building, configuring, and deploying projects and applications, for all the same reasons. Cheers, - Chas On Mar 26, 2010, at 11:13 AM, Rick Moynihan wrote: On 25 March 2010 22:17, Brian Carper briancar...@gmail.com wrote: On Mar 25, 11:55 am, Chas Emerick cemer...@snowtide.com wrote: Why does building and installing dependencies have to be harder than this? Lein right now tries to fill this niche of being braindead easy to use, and comes pretty close. I realize Maven does a lot more than build and install dependencies, but for some of us, that's all we want out of life, and it's pretty nice when it's that easy to do so. Agreed. I know next to nothing about maven, other than it scared me back in my java days. It seems at first glance to be pretty impenetrable (at least in terms of how it is documented), and that's not say that I wasn't blown away by Chas's screencast. I'd certainly consider maven now or at least try it when my projects get bigger and require more than lein has to offer. Is there not an analogy to be drawn here between labrepl and lien? It seems both are targetted at being approachable to Clojure beginners (and in the case of lein small projects). labrepl isn't aiming to be the environment you run complex clojure projects with, and in the same way it seems that at some point you might want to migrate from lein to maven. I'd assumed that migrating a lein based project to a maven one (if required) would be as simple as running: $ lein pom Then when you're ready you can rm project.clj and just tweak your pom.xml for a pure maven build. If this is the case then lein seems to allow people to delay learning maven, which is a complex or at least daunting moving part in a complex environment. Not something you want to have to learn or adopt whilst straining to understand Clojure. Maven seems to be a polarising tool, some people love it and others hate it... This much we know. So anything we can do to prevent clojure being tarnished by the maven haters, the better. lein seems to be a good step in this direction, and is possibly even a gentle introduction to maven for those wishing (or requiring) to make the jump. Is it possible for us as a community to agree on this much? R. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en To unsubscribe from this group, send email to clojure +unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject. -- You received this message because you are subscribed to the Google Groups Clojure
Re: referencing an atom inside a function used for swapping
construct the JPanel outside the atom, add all the listeners and then add the panel to structure in the atom. (let [panel (JPanel. ..)] (add-listener-stuff panel the-atom) (swap! the-atom assoc :SpiffyPanel panel)) Side-effecting things shouldn't be done inside the swap! since it can be retried multiple times. So you would set up a panel, find that you have to retry, start over, retry, start over, retry, Okay, I'll add the panel outside. But I don't think this is really a side effect. The events that call swap won't be called inside the function that is creating the panel since they're event listeners. Thanks. -- You 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 To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
Re: Choosing a Clojure build tool
On Mar 25, 7:55 pm, Chas Emerick cemer...@snowtide.com wrote: I published a blog post earlier today, along with a short screencast that might be of interest: Read on:http://muckandbrass.com/web/x/AgBV The article reads to me as, don't reinvent the wheel, everyone should use maven. Personally I disagree with this because maven configuration is much harder than it needs to be. About an hour ago I had to add the hierarchy, executions/execution/goals/goal to a pom.xml file and found it needlessly tedious and wholly dependent on copy and pasting from a webpage. I also don't think it is necessary to choose a single build tool. I've used different ones at various times. Leiningen works for me, is easy to understand and extend, and interoperates well with maven -- everyone using clojure could standardise on leiningen and my existing maven builds would still work. I also have a small bit of code using ant/ivy and that would build fine too in a leingingen only world. Saul -- You 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 To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
Re: Choosing a Clojure build tool
On Mar 25, 3:42 pm, Chas Emerick cemer...@snowtide.com wrote: I'm not entirely sure what would be required from clojure-maven-plugin (for example) for maven to achieve greater acceptance in the community... I think all it takes is getting the word out. Ease of use matters to me, but sexp vs. XML or simple interface vs. complex is only one part of ease of use. Another part is community support and availability of documentation. It's easy to learn any tool when lots of people are using it and writing about it. Your article was enough to convince me and apparently a few others to give Maven a chance. If a section appeared on clojure.org called Installing clojure and clojure-contrib via Maven with a sample POM and simple instructions for starting a REPL, that'd probably help. Is build.clojure.org linked to from anywhere on clojure.org? I only know about it from your blog post and from having read through IRC logs, and it's mentioned in the clojure-contrib README but there's no example of how to use it. Your article is the first I've seen Clojure installed directly via Maven. --Brian -- You 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 To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
Re: labrepl, making Clojure more accessible
Just tried this with NetBeans 6.7.1 on OSX 10.5.8. Got through all setup steps with no problem. When I try to start the project REPL, I get: There did not appear to be both valid clojure and clojure-contrib jars present in the classpath... (some paths to ...1.2.0-master- SNAPSHOT.jar) If I elect Use the default platform Clojure-1.0.0, a REPL starts, then (require 'labrepl) gives FileNotFoundException for clojure/ contrib/logging__init.class logging.clj HTH. -- You 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 To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
Re: Logic programming in Clojure
Really nice! Is it aware of all Clojure structures, including maps etc? -- You 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 To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
Re: Logic programming in Clojure
No. That's one of the improvements I would make if I get back to working on it again. Jim On Mar 26, 1:37 pm, Sophie itsme...@hotmail.com wrote: Is it aware of all Clojure structures, including maps etc? -- You 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 To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
Re: Choosing a Clojure build tool
On Fri, Mar 26, 2010 at 10:31 AM, Saul Hazledine shaz...@gmail.com wrote: The article reads to me as, don't reinvent the wheel, everyone should use maven. Personally I disagree with this because maven configuration is much harder than it needs to be. I think there's a misconception that's been spread that since Leiningen is written in Clojure, it's a break from the existing ecosystem. In truth Leiningen is mostly just a wrapper around Stuart Halloway's Lancet library (to use ant tasks) and the maven-ant-tasks library that provides dependency management. There are a few tasks that are implemented from scratch like clean because it's so trivial or compile, new, and test because they're Clojure-specific, but the rest of them rely on existing implementations. For the record, Leiningen is currently around 700 lines of code and was basically feature-complete after two weeks of evening and weekend work. It is true that projects that need to produce output that's more complicated than a jar or uberjar right now aren't served well by Leiningen out of the box, but that's simply because my own needs haven't included that and I haven't gotten to it yet, not because I believe that relying on ant or maven APIs is icky somehow. Some people have taken steps towards reimplementing this in pure-Clojure, and that may or may not be wise depending on the trade-off of how much time it takes to implement vs how much time it would take to leverage an existing solution. Ant tends to have the advantage over Maven in that case because Maven's dependency injection framework makes it rather hostile to call out to from Clojure, but the Ant ecosystem is rich enough that it should provide enough for most projects. -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 To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
newInstance with parameters?
Hello, I'm trying the newInstance examples from http://en.wikibooks.org/wiki/Learning_Clojure, however I get an error: Clojure 1.1.0 user= (new String ) user= (. (identity String) newInstance ) java.lang.IllegalArgumentException: No matching method found: newInstance for class java.lang.Class (NO_SOURCE_FILE:0) user= (.newInstance String ) java.lang.IllegalArgumentException: No matching method found: newInstance for class java.lang.Class (NO_SOURCE_FILE:0) user= (.newInstance (identity String) ) java.lang.IllegalArgumentException: No matching method found: newInstance for class java.lang.Class (NO_SOURCE_FILE:0) user= I can't use the new macro since I store several classes in a hash and pick the one I want in runtime (factory like). newInstance with no argument work though: user= (.newInstance String) user= Any ideas? Thanks, -- Miki -- You 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 To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
Re: converting long string to number
You want (java.math.BigInteger. 2342343...). java.lang.Integer is limited to 2^31-1. Clojure has a bigint function, so (bigint (apply str (re-seq #[0-9]+ big-num-str))) will work as well. -- You 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 To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
Re: newInstance with parameters?
You'll need to with with the Constructor object returned from Class.getConstructor(Class...). Or use this: (defn new-instance [#^Class c args] (if args (.newInstance (.getConstructor c (into-array Class (map class args))) (into-array Object args)) (.newInstance c))) On Mar 26, 12:51 pm, Miki miki.teb...@gmail.com wrote: Hello, I'm trying the newInstance examples fromhttp://en.wikibooks.org/wiki/Learning_Clojure, however I get an error: Clojure 1.1.0 user= (new String ) user= (. (identity String) newInstance ) java.lang.IllegalArgumentException: No matching method found: newInstance for class java.lang.Class (NO_SOURCE_FILE:0) user= (.newInstance String ) java.lang.IllegalArgumentException: No matching method found: newInstance for class java.lang.Class (NO_SOURCE_FILE:0) user= (.newInstance (identity String) ) java.lang.IllegalArgumentException: No matching method found: newInstance for class java.lang.Class (NO_SOURCE_FILE:0) user= I can't use the new macro since I store several classes in a hash and pick the one I want in runtime (factory like). newInstance with no argument work though: user= (.newInstance String) user= Any ideas? Thanks, -- Miki -- You 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 To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
Re: concurrency and rand-int
Interesting blog post, Chas, which led me to doall some of my lazy sequences (not 100% sure I caught them all) and in the process I also found another source of contention that I removed (over a Date object). But I'm still having contention somewhere that I can't find. Is there a tool that will help me to see what is being contended for, and/or who is contending for it? Anything would be helpful. Also, is it possible that there is contention over the reading, by many different threats (from 1 agents), of the same parts of many (1+) nested immutable lists with lots of shared structure? I know this immutable forrest is *safe* for reading by many threads, but I don't know if there's a performance implication. I've tried to make copies of list structures just to explore this, but it's not obvious how to do that in clojure and I'm not sure I've been doing it right. Thanks, -Lee On Mar 26, 2010, at 8:37 AM, Chas Emerick wrote: Just as long as your binding form is within the function body, you're good to go. e.g., you need to do this (or its equivalent): (send some-agent #(binding [random-state (Random.)] (other-fns %))) *not* this: (binding [random-state (Random.)] (send some-agent other-fns)) The latter will cause the sent fn to be invoked outside the scope of the binding. I wrote up a little guide on some of the wrinkles of binding some months ago: http://muckandbrass.com/web/display/~cemerick/2009/11/03/Be+mindful+of+Clojure%27s+binding On a very minor note, these forms are more syntactically idiomatic: (java.util.Random.) (.nextFloat random-state) (.nextInt random-state n) Cheers, - Chas On Mar 26, 2010, at 8:14 AM, Lee Spector wrote: Thanks all for the quick and helpful responses on the issues with rand-int/rand and concurrency. I probably have some other issues that are also gumming up some of my concurrency, but following the advice on of creating per-thread java.util.Random objects *seems* to have helped, although it's a little hard to tell and I'm not sure I did it right. What I did was: (def thread-local-random-state (new java.util.Random)) ;; just an initial global binding (defn lrand-int Return a random integer using the thread-local random state. [n] (if ( n 1) 0 (. thread-local-random-state (nextInt n (defn lrand Return a random float between 0 and 1 usng the thread-local random state. [] (. thread-local-random-state (nextFloat))) And then I wrap the bodies of the the functions that I pass to send (which is the only way I launch threads) with: (binding [thread-local-random-state (new java.util.Random)] everything else goes here, with calls that make calls that eventually call lrand-int and lrand ) Is that the right way to do it? Thanks, -Lee On Mar 26, 2010, at 3:30 AM, mac wrote: There is a fast Java version of Mersenne Twister here, if you feel like compiling a java file: http://cs.gmu.edu/~sean/research/ On 26 mar, 05:43, Chas Emerick cemer...@snowtide.com wrote: I was going to suggest something similar using seque in an atom, but in neither case (using an atom or a ref) is the contention going to be minimized -- just shifted from the AtomicLong in java.util.Random to the now-app-level atom or ref. - Chas On Mar 26, 2010, at 12:30 AM, Andrzej wrote: As others have pointed out using per-thread java.util.Random objects is probably the best way to go in this particular case. However, I'm curious if the following code could give any speed gain on your machine: (defn rand-seq [] (repeatedly #(. Math (random (def rand-seq-ref (ref (rand-seq))) (nth @rand-seq-ref 100) ;; pre-cache random values; evaluate it every some time ;;btw, how to do it automatically? (defn next-rand-val [] (dosync (commute rand-seq-ref next) (first @rand-seq-ref))) user= (next-random-val) 0.5558267606843464 user= (next-random-val) 0.32353157456467474 Cheers, Andrzej On Fri, Mar 26, 2010 at 11:35 AM, Lee Spector lspec...@hampshire.edu wrote: I'm trying to track down the reason that I sometimes see a lot of concurrency in my system (up to 1200% CPU utilization on a dual quadcore mac that also has some kind of hyperthreading, allegedly allowing a maximum of 1600% CPU) while other times it gets stuck at around 100-200%. My system (a genetic programming system) has a *lot* of randomness in it, so it's hard to repeat runs and get a firm handle on what's going on. But after a bunch of testing I'm beginning to suspect that it might be the random number generator itself (clojure-core/rand-int in this case, which calls (. Math (random))). This seems at least somewhat plausible to me because I guess that the underlying Java random method must be accessing and updating a random number generator state, and so this would be a concurrency bottleneck. So if I'm in a condition in which lots of concurrent threads are all
Re: concurrency and rand-int
mac: Thanks for that -- it's a pointer to one of my own former students, who I should be bugging about this stuff :-) -Lee On Mar 26, 2010, at 3:30 AM, mac wrote: There is a fast Java version of Mersenne Twister here, if you feel like compiling a java file: http://cs.gmu.edu/~sean/research/ On 26 mar, 05:43, Chas Emerick cemer...@snowtide.com wrote: I was going to suggest something similar using seque in an atom, but in neither case (using an atom or a ref) is the contention going to be minimized -- just shifted from the AtomicLong in java.util.Random to the now-app-level atom or ref. - Chas On Mar 26, 2010, at 12:30 AM, Andrzej wrote: As others have pointed out using per-thread java.util.Random objects is probably the best way to go in this particular case. However, I'm curious if the following code could give any speed gain on your machine: (defn rand-seq [] (repeatedly #(. Math (random (def rand-seq-ref (ref (rand-seq))) (nth @rand-seq-ref 100) ;; pre-cache random values; evaluate it every some time ;;btw, how to do it automatically? (defn next-rand-val [] (dosync (commute rand-seq-ref next) (first @rand-seq-ref))) user= (next-random-val) 0.5558267606843464 user= (next-random-val) 0.32353157456467474 Cheers, Andrzej On Fri, Mar 26, 2010 at 11:35 AM, Lee Spector lspec...@hampshire.edu wrote: I'm trying to track down the reason that I sometimes see a lot of concurrency in my system (up to 1200% CPU utilization on a dual quadcore mac that also has some kind of hyperthreading, allegedly allowing a maximum of 1600% CPU) while other times it gets stuck at around 100-200%. My system (a genetic programming system) has a *lot* of randomness in it, so it's hard to repeat runs and get a firm handle on what's going on. But after a bunch of testing I'm beginning to suspect that it might be the random number generator itself (clojure-core/rand-int in this case, which calls (. Math (random))). This seems at least somewhat plausible to me because I guess that the underlying Java random method must be accessing and updating a random number generator state, and so this would be a concurrency bottleneck. So if I'm in a condition in which lots of concurrent threads are all calling rand-int a lot then all of the accesses to the state have to be serialized and my concurrency suffers (a lot). Does this sound plausible to you? If so, is there a straightforward way to avoid it? It is not important to me that the random numbers being generated in different threads be generated from the same generator or coordinated/seeded in any way. I just need lots of numbers that are random enough. I guess I could roll my own random number generator(s) and either have a lot of them with independent states or maybe even make them stateless (always generating numbers by scrambling the clock?). But I would hope there would be something simpler. Thanks, -Lee -- Lee Spector, Professor of Computer Science School of 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 Check out Genetic Programming and Evolvable Machines: http://www.springer.com/10710-http://gpemjournal.blogspot.com/ -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com 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 To unsubscribe from this group, send email to clojure +unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject. -- You 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 To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject. -- Lee Spector, Professor of Computer Science School of 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 Check out Genetic Programming and Evolvable Machines: http://www.springer.com/10710 - http://gpemjournal.blogspot.com/ -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this
Re: Clojure Conference Poll
+1 Europe R. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
Re: ANN: Kanshiki Boom! - Japanese handwriting recognition
On Mar 27, 1:10 am, Jarkko Oranen chous...@gmail.com wrote: This looks neat. I probably won't find much use for it though, as my input method already has this functionality, and even that doesn't get much use due to the fact that I am horrible at writing kanji with the mouse (I'm left-handed, but my mouse-hand is right.) I tried to get the recognition to a point where it doesn't matter how bad you type, although there's still room for improvement. It more or less finds the closest match in all Kanjis it knows, however different the Kanji might look form the drawing, but if there is none that is closer, it will be the first choice. So it does not try to force you to draw exact strokes. Still, the general order of strokes and direction will probably always be important, with more common variants to be added. If you have no plans to try to make money with this thing, I you I'm not thinking of selling this as a product. suggest simply put the thing on github so that interested people can take a look. I don't think it's worth keeping things like this hidden. Note that if you do so you should choose a licence other than GPL, because it's known to be incompatible with EPL which Clojure uses. I just read through a couple of threads about the licensing issue in this group, and also the EPL and GPL licenses themselves and their FAQs. As I understand the EPL license, creating a modified version of an EPL product means creating derived work, and if derived work is distributed, the source code must be made available, which is exactly what I want. This should prevent others from benefiting from this open source software, without them letting me and others benefit from their changes by not open sourcing it. However, there might be another option, which I'm not 100% sure about: If Clojure was considered a system library as per GPL definition, I could release my software as GPL, just as other projects compiled with proprietary compilers are released as open source. I'm not sure whether I can bundle my software with clojure.jar and clojure- contrib.jar in that case though. (EPL is a slightly weaker copyleft licence, more like LGPL). EPL is the most common choice, but of course a BSD-style licence is fine as well. At this point, my software is not a library, at least I'm not currently seeing it as one. That might change, and at that point in time I will decide what choices I want to give to the users of that now-library. For now, I just don't want this to be secretly included somewhere in a commercial/closed-source product - not that it's in that state anyway :), but I don't mind sharing the sources. In case this software actually gets to a state where commercial companies are interested in incorporating that into their own products, I'd like them to either use it open-source (so if they modify, they have to share modifications), or give me enough money so I don't mind them making money from it exclusively, without sharing (at least with me :). Eugen -- You 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 To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
Re: Choosing a Clojure build tool
I'm now using polyglot maven for a project in both NetBeans/Enclojure and
Intellij/LaClojure. The pom.clj for one of my subprojects looks like this:
--
(defproject main com.linkuistics.lamdras:website:1.0-SNAPSHOT
:model-version 4.0.0
:name Lamdras Website
:description Acumen / LRMDS Integration
:packaging war
:properties {:project.build.sourceEncoding UTF-8}
:dependencies [[ring:ring-servlet:0.2.0-RC2]
[ring:ring-devel:0.2.0-RC2]
[clj-routing:clj-routing:0.1.0-SNAPSHOT]
[clout:clout:0.2.0-SNAPSHOT]
[compojure:compojure:0.4.0-SNAPSHOT]
[hiccup:hiccup:0.1.0-SNAPSHOT]
[org.clojure:clojure:1.2.0-master-SNAPSHOT]
[org.clojure:clojure-contrib:1.2.0-master-SNAPSHOT]
[congomongo:congomongo:0.1.2-SNAPSHOT]
[jline:jline:0.9.94]]
:provided-dependencies [[org.mortbay.jetty:servlet-api-2.5:6.1.14]]
:final-name website
:plugins [[org.apache.maven.plugins:maven-war-plugin:2.1-beta-1]
[org.apache.maven.plugins:maven-compiler-plugin:2.1
{:configuration {:source 1.6 :target 1.6}}]
[com.theoryinpractise:clojure-maven-plugin:1.3.1 {:executions
[{:id compile-clojure :phase compile :goals [compile]}]}]
[org.mortbay.jetty:maven-jetty-plugin:6.1.10 {:configuration
{:scanIntervalSeconds 10 :stopKey foo :stopPort }}]])
--
which isn't at all painful. It's early days yet, and neither IDE picks up the
pom.clj, so I have to run the translator to get a pom.xml, but that's trivial -
the command to produce pom.xml from pom.clj (and the translation is
bidirectional) is this:
translate pom.clj newpom.xml
assuming the polyglot maven translate command is on your path. Note that you
can use either maven 2 or 3 to run the resultant pom.xml.
You can use either declarative or imperative code in the pom.clj i.e. you can
call methods on the pom's object model to build up a project definition, which
you can then run using polyglot maven or translate to a pom.xml which can then
be run.
Antony Blakey
-
CTO, Linkuistics Pty Ltd
Ph: 0438 840 787
On the other side, you have the customer and/or user, and they tend to do what
we call automating the pain. They say, What is it we're doing now? How would
that look if we automated it? Whereas, what the design process should properly
be is one of saying, What are the goals we're trying to accomplish and how can
we get rid of all this task crap?
-- Alan Cooper
--
You 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
To unsubscribe from this group, send email to
clojure+unsubscribegooglegroups.com or reply to this email with the words
REMOVE ME as the subject.
