Re: Trying to get a list of random numbers using repeat
2009/3/23 Krešimir Šojat kso...@gmail.com: (rand-int 49) will produce one integer, and repeat will repeat it 10 times, that is why you see same number repeated. How embarrassing! As soon as I switched my machine off last night I realised rand-int was only being called once - of course it was! I did consider 'repeatedly' but I couldn't get it to work for some reason - thank you for showing me how to use it. Also, I was put off from using it when I read its doc-string which says: Takes a function of no args, presumably with side effects, and returns an infinite lazy sequence of calls to it Why presumably with side effects? Cheers, Paul. -- Iode Software Ltd, registered in England No. 6299803. Registered Office Address: 12 Sancroft Drive, Houghton-le-Spring, Tyne Wear, DH5 8NE. This message is intended only for the use of the person(s) (the intended recipient(s)) to whom it is addressed. It may contain information which is privileged and confidential within the meaning of applicable law. If you are not the intended recipient, please contact the sender as soon as possible. The views expressed in this communication may not necessarily be the views held by The Company. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Trying to get a list of random numbers using repeat
Why presumably with side effects?Otherwise you would use repeat. A pure function returns the same value every time, so there is no reason to call it repeatedly. Joshua On Tue, Mar 24, 2009 at 10:04 AM, Paul Drummond paul.drumm...@iode.co.ukwrote: 2009/3/23 Krešimir Šojat kso...@gmail.com: (rand-int 49) will produce one integer, and repeat will repeat it 10 times, that is why you see same number repeated. How embarrassing! As soon as I switched my machine off last night I realised rand-int was only being called once - of course it was! I did consider 'repeatedly' but I couldn't get it to work for some reason - thank you for showing me how to use it. Also, I was put off from using it when I read its doc-string which says: Takes a function of no args, presumably with side effects, and returns an infinite lazy sequence of calls to it Why presumably with side effects? Cheers, Paul. -- Iode Software Ltd, registered in England No. 6299803. Registered Office Address: 12 Sancroft Drive, Houghton-le-Spring, Tyne Wear, DH5 8NE. This message is intended only for the use of the person(s) (the intended recipient(s)) to whom it is addressed. It may contain information which is privileged and confidential within the meaning of applicable law. If you are not the intended recipient, please contact the sender as soon as possible. The views expressed in this communication may not necessarily be the views held by The Company. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Trying to get a list of random numbers using repeat
2009/3/24 Joshua Fox joshuat...@gmail.com: Why presumably with side effects? Otherwise you would use repeat. A pure function returns the same value every time, so there is no reason to call it repeatedly. Yup, that makes sense. Random numbers are side-effecting (is that the right term?) and I was trying to think about the (simple) problem in a pure functional way which was getting my simple brain all confused! Thanks to both of you for helping me see sense! Cheers, Paul. -- Iode Software Ltd, registered in England No. 6299803. Registered Office Address: 12 Sancroft Drive, Houghton-le-Spring, Tyne Wear, DH5 8NE. This message is intended only for the use of the person(s) (the intended recipient(s)) to whom it is addressed. It may contain information which is privileged and confidential within the meaning of applicable law. If you are not the intended recipient, please contact the sender as soon as possible. The views expressed in this communication may not necessarily be the views held by The Company. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Problem with CLASSPATH
Has anyone gotten 20090320 to work on a new MacBook Pro running Leopard? With further investigation, it looks like any call to (use...) either explicitly or as part of an (ns...) function call causes clojure to crash since the upgrade. I've fiddled around with the class path, and nothing seems to work. Interestingly enough, my Structure.clj file sets the namespace, but doesn't use any other files. So, I can launch it from the command line like this: java clojure.lang.Script Structure.clj And I don't get any errors. When I open up the REPL, however and try (use 'Structure), It crashes. I would go back to the older version, but I cannot get duck-streams from clojure.contrib to work on that version. Clojure.contrib seems to build without errors, but it just doesn't work. Previously, I'd built both clojure and clojure.contrib from source, and everything worked fine. However, I have no clue which revision that was, so I don't know how to go back to that version. So, I'm stuck between two non-working versions. Which is frustrating, because I'm in the middle of a project, and I need to get things moving again quickly. Any help or advice would be greatly appreciated. -Rich- On Mar 23, 11:12 am, Rich rwml...@gmail.com wrote: Let me clarify my last post. In both cases, the directory was on the class path (either implicitly as ., or explicitly given the absolute path). However, in both cases I got the same FileNotFound exception. -Rich- On Mar 23, 6:39 am, Rich rwml...@gmail.com wrote: . should be set by default. I verified that it was set using (. System getProperties). I also tried explicitly setting the absolute path using -cp. No luck on either count. -Rich- On Mar 23, 5:14 am, revoltingdevelopment christopher.jay.jo...@gmail.com wrote: I also had the NO_SOURCE_FILE error when using contrib packages, upon upgrade to 20090320. My CLASSPATH included .. I had to revert to starting clojure with an explicit -cp. I'm new to both Java and Clojure, but this led me to think my CLASSPATH was being ignored. I chalked it up to my misunderstanding or not really keeping track of how I had things set up before, but it seemed different. On Mar 23, 9:24 am, Mark Volkmann r.mark.volkm...@gmail.com wrote: On Mon, Mar 23, 2009 at 7:34 AM, Rich rwml...@gmail.com wrote: Structure.clj does call ns as shown below: (ns Structure) So, as far as I can tell, Clojure should look for Structure.clj in the class path. At least, that's what it used to do. I guess I could move all the code into a sub-directory, and rename all the namespaces--but I'd rather keep it organized the way it is, if possible. Do you have . or the current directory in CLASSPATH? On Mar 23, 1:33 am, Mark Volkmann r.mark.volkm...@gmail.com wrote: On Mon, Mar 23, 2009 at 4:59 AM, Rich rwml...@gmail.com wrote: Hi, I'd been using the 20081217 release. The following code worked, as long as Structure was in the working directory: Clojure user= (use 'Structure) nil However, after I updated to 20090320, I get the following errors: Clojure user= (use 'Structure) java.io.FileNotFoundException: Could not locate Structure__init.class or Structure.clj on classpath: (NO_SOURCE_FILE:0) In both cases, I'm launching Clojure from the directory that contains Structure.clj as follows: java clojure.lang.Repl What am I doing wrong? Does Structure.clj contain a call to the ns macro? If so, I think you need to move Structure.clj to a subdirectory that matches its namespace. For example, if the namespace is a.b.c then you need a directory in the classpath that contains an a directory that contains a b directory that conains c.clj, not Structure.clj. -- R. Mark Volkmann Object Computing, Inc. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Trying to get a list of random numbers using repeat
On Mar 23, 2009, at 10:36 PM, Paul Drummond wrote:
2009/3/24 Joshua Fox joshuat...@gmail.com:
Why presumably with side effects?
Otherwise you would use repeat. A pure function returns the same
value
every time, so there is no reason to call it repeatedly.
Yup, that makes sense.
Random numbers are side-effecting (is that the right term?) and I was
trying to think about the (simple) problem in a pure functional way
which was getting my simple brain all confused!
It's not obvious what side effect is occurring by calling rand-int,
but in fact the state of the pseudorandom generator is affected by
each call. This is from java.util.Random. Everybody calls next()
sooner or later, and it calls the compareAndSet() method:
* This is a linear congruential pseudorandom number generator, as
* defined by D. H. Lehmer and described by Donald E. Knuth in
iThe
* Art of Computer Programming,/i Volume 2: iSeminumerical
* Algorithms/i, section 3.2.1.
protected int next(int bits) {
long oldseed, nextseed;
AtomicLong seed = this.seed;
do {
oldseed = seed.get();
nextseed = (oldseed * multiplier + addend) mask;
} while (!seed.compareAndSet(oldseed, nextseed));
return (int)(nextseed (48 - bits));
}
As Joshua pointed out, whenever a function returns different values
given the same args that's a good sign that a side effect has
occurred--some state has obviously changed.
Aloha,
David Sletten
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Clojure group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---
Re: PATCH: universal parent type for Clojure hierarchies
On Mar 23, 2009, at 23:11, Meikel Brandmeyer wrote: This is not correct. defmulti may take any of Clojure's reference types containing the hierarchy. So it doesn't need to be a Var. A Ref, an Atom or an Agent are also possible. Thanks for pointing this out. Here comes a corrected patch! Konrad. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~--- root-type.patch Description: Binary data
Generic functions again
News for the handful of people interested in gfs. Below is a sample trace of the gf implementation. Dispatch is wholly deterministic; you never need prefer-method. There is no need to specify a dispatch function, though dispatch customization is available if you want it. The default dispatch function matches methods by using a sequence of matcher functions, finding methods whose formal parameter constraints match the supplied argument values. The standard matchers, in order from least to most specific, are: wildcard (any value matches), type (class or isa?), equal (the argument equals a declared values), and test (the argument satisfies a uder-supplied predicate). A second premade matcher sequence provides dispatching on isa? with user-supplied hierarchies, as well. In the scope in which a generic function is applied, next-method is always bound to the next applicable method in a total ordering of applicable methods for the arguments supplied (see the first java.lang.Integer method below for an example of how to use next- method). applicable-methods is always bound to a function that returns a list of applicable methods, ordered from most- to least-specific; next-method is equal to (first (applicable-methods)). As in CLOS, if you call define-method on an unbound name, then define- generic-function is called for you with the most common arguments. You only need to call define-generic-function if you want to do something more esoteric, like customizing dispatch. This iteration is more complete than the previous one; for example, next-method is implemented. :before and :after methods are still not implemented. You can supply your own sequence of matchers, but you can't yet replace the default dispatching function that uses them to find and order applicable methods. No caching of method orderings is performed at present, and I'm sure a critical eye could find other things to improve in the performance. gf calling currently takes something like ten times as long as a MultiFn call in the relatively simple cases I've tested, with most of the extra time going into sorting the applicable methods. Implementing the sort of method cache that every Common Lisp uses would likely be a big improvement. If you want the code, send email to mevins at mac dot com and let me know; I'll tell you how to get it. It's sort of embedded in the larger project that it's a part of right now (it uses a few lower-level utilities that are part of the project), but if there's sufficient interest I could make it self-contained without too much effort. user (define-method add [x y] (str don't know how to add these things: x y)) #generic-function add user (add 1 2) don't know how to add these things: 1 2 user (define-method add [[x java.lang.Number] [y java.lang.Number]] (+ x y)) #generic-function add user (add 1 2) 3 user (define-method add [[x java.lang.Integer] [y java.lang.Integer]] (let [result (xg.gf/next-method x y)] (println this is the integer version) result)) #generic-function add user (add 1 2) this is the integer version 3 user (add 1.0 2.0) 3.0 user (add 1.0 2) 3.0 user (define-method add [[x java.lang.String] [y java.lang.String]] (str x y)) #generic-function add user (add foo bar) foobar user (define-method add [[x java.lang.String] [y java.lang.Integer]] (str x y)) #generic-function add user (add foo 3) foo3 user (add 'foo 'bar) don't know how to add these things: foo bar --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Generic functions again
On Mar 24, 2009, at 11:19, mikel wrote: Dispatch is wholly deterministic; you never need prefer-method. There Then what is the rule for choosing one method when there are several that match the arguments? In the scope in which a generic function is applied, next-method is always bound to the next applicable method in a total ordering of applicable methods for the arguments supplied (see the first java.lang.Integer method below for an example of how to use next- method). applicable-methods is always bound to a function that returns a list of applicable methods, ordered from most- to least-specific; next-method is equal to (first (applicable-methods)). So I guess that the chosen method is the first one in the applicable- methods list, meaning the most specific one. The question is then how specificity is defined, in particular for multiple argument dispatch. Suppose in your example that I provide (define-method add [x y] ...) (define-method add [[x java.lang.Integer] y] ...) (define-method add [x [y java.lang.Integer]] ...) and call (add 3 3). Which of the methods is chosen? Konrad. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: parallel iteration
On 24/03/2009 1:06, pmf wrote: On Mar 24, 12:01 am, Rowdy Rednoserowdy.redn...@gmx.net wrote: Hi group, say I have 2 sequences (def seq-a '(a1 a2 a3)) (def seq-b '(b1 b2 b3)) and want to iterate over them in parallel, like this (par-doseq [a seq-a b seq-b] (prn a b)) which should print a1 b1 a2 b2 a3 b3 A combination of the interleave and partition functions would probably do what you want: (partition 2 (interleave [:a :b :c] [:d :e :f])) (Wrap it in a doall to force your side effects.) Another one : (doseq [[a b] (map vector '(1 2 3) '(a b c))] (println a b)) (defmacro par-doseq [bindings body] (let [bindings (partition 2 bindings)] `(doseq [~(vec (map first ,bindings)) (map vector ~@(map second ,bindings))] ~...@body))) cara.nio.echo= (par-doseq [a '(1 2 3) b '(a b c)] (println a b)) 1 a 2 b 3 c nil Sacha --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: STM and useful concurrency
As was described in a Software Engineering Radio podcast on transactional memory, there are many parallels between garbage collection and transactional memory. Some parallels that aren't in place yet though include: 1) There are tools to measure the impact of GC on runs of an application, but we don't yet have similar tools for TM. 2) The operation of GC can be tuned through command-line options, but no such options are available yet for TM. I don't know if these are really needed for TM, but I suspect they would be useful and would at least make people feel more comfortable about building large applications using TM. I believe everything you say about programming with STM being much easier than programming with locks. My concern is only about performance measurement and tuning, either through options or code refactoring. On Mon, Mar 23, 2009 at 6:27 PM, Luc Prefontaine lprefonta...@softaddicts.ca wrote: On Mon, 2009-03-23 at 14:49 -0500, Cosmin Stejerean wrote: The fact that B is tried once concurrently with A, and is then aborted and retried is in my opinion the same as transaction B being stuck waiting on a lock while A is being processed, but I can see how trying B concurrently with A the first time might waste more resources, and that perhaps for certain applications it locks might have better performance. Coming from years of intensive use of libthread, if I use it as a comparison basis, a mutex waiting for a resource access to be granted essentially spins waiting. Your thread is not doing anything useful. Of course the spinning itself consumes CPU cycles... Assuming you need to lock several resources, you may wait a significant amount of time getting each mutex on each resource AND the more resources you have to lock (the more complex is your transaction), the greater your dead lock chances are as concurrency increases. If you hit a deadlock situation in a concurrent application written in the usual libthread model, what are your options ? Abort or ... retry on behalf of the user/event/whatever started the transaction. Now would you rather do this yourself or have a model that takes care of that for you ? Guess what, I prefer someone else to deal with this transparently Clojure has a big advantages over the classical libthread model: a) It makes everything immutable by default. You do not have to care about the whole universe, just about the stuff your transaction alters. Less bugs to discover, simpler STM implementation. Other languages look like single-legged runners... b) It's it's clear in the code which resources are part of a transaction and it allows you finer control on them. Changing stuff is a lot simpler. Compared that with changing the granularity level of your locks when using libthread or even in Java... c) You are isolated from the code that deals with contention, dead locks, restarts, ... The implementation can change to accommodate different environmental conditions while keeping your code sane. You have two choices, the empirical approach which I went through and with some experience you eventually learn the pitfalls OR you use a canned approach which removes from you all these concerns. Which one will be more efficient with the hardware ? These days we have much more powerful hardware than in the 1980/1990s. In these times we had to be very careful about resource usage and code was hand crafted very carefully. We had 2/4/6 processors SMP machines and we were already facing concurrency problems already with the libthread model. The absence of a simple concurrency model had a severe impact for years on our ability to spit out concurrent applications. Too complex for the average programmer, hard to test, ... The disproportion of the number of concurrent applications versus the single threaded ones did not allow us to learn much about scaling to environments with hundreds of CPUs. It's been done for some mathematical models and other bleeding edge applications but these are in very narrow application domains. What if STM was waisting cycles given the hardware power we have today ? What if each transaction had to be retried twice ? What if for some application concurrency situations there was a glass ceiling that was preventing us from scaling above 100 CPUs ? Would that be a hindrance if concurrent applications become common because of a simpler model ? I do not think so, the implementations could help with these problems. You should have the ability to tune the concurrency outside of your application. Better implementations will be created over time. It's a bit like garbage collectors, they have existed for a long time and have been improved over several iterations. Having a simpler model is essential before anything else can be done. I can imagine how in certain situations a profile mode where Clojure keeps track of transaction retries, and maybe even the reason why
Re: Suggestion for Java Clojure code, use of checkstyle or code formatter
+1 for running all the code under src/jvm through some code formatter that uses something at least similar to the Sun Java conventions. On Mon, Mar 23, 2009 at 11:59 PM, BerlinBrown berlin.br...@gmail.com wrote: I was curious about how some of the clojure code worked and observed that the coding style is a little bit non idiomatic from typical Java coding conventions. E.g. there aren't any javadoc comments on methods or classes, non standard indents. Something like checkstyle might prove useful. http://checkstyle.sourceforge.net/ While, every programmer balks at conventions, I am sure there is a mountain of evidence for increased overall maintenance and other benefits. I know, I will get suggestions for clojure/lisp coding style. -- R. Mark Volkmann Object Computing, Inc. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Problem with CLASSPATH
The latest version of Clojure incorporated lazy sequences which broke many libraries early on. Most of these problems have been worked out. In my experience you should use the cutting edge version of everything including SLIME. I clone everything from GitHub (clojure, clojure-contrib, swank-clojure, clojure-mode, slime). This has worked for me for the past 6 months with very few problems (except the original transition to lazy sequences). On Tue, Mar 24, 2009 at 5:03 AM, Rich rwml...@gmail.com wrote: Has anyone gotten 20090320 to work on a new MacBook Pro running Leopard? With further investigation, it looks like any call to (use...) either explicitly or as part of an (ns...) function call causes clojure to crash since the upgrade. I've fiddled around with the class path, and nothing seems to work. Interestingly enough, my Structure.clj file sets the namespace, but doesn't use any other files. So, I can launch it from the command line like this: java clojure.lang.Script Structure.clj And I don't get any errors. When I open up the REPL, however and try (use 'Structure), It crashes. I would go back to the older version, but I cannot get duck-streams from clojure.contrib to work on that version. Clojure.contrib seems to build without errors, but it just doesn't work. Previously, I'd built both clojure and clojure.contrib from source, and everything worked fine. However, I have no clue which revision that was, so I don't know how to go back to that version. So, I'm stuck between two non-working versions. Which is frustrating, because I'm in the middle of a project, and I need to get things moving again quickly. Any help or advice would be greatly appreciated. -Rich- On Mar 23, 11:12 am, Rich rwml...@gmail.com wrote: Let me clarify my last post. In both cases, the directory was on the class path (either implicitly as ., or explicitly given the absolute path). However, in both cases I got the same FileNotFound exception. -Rich- On Mar 23, 6:39 am, Rich rwml...@gmail.com wrote: . should be set by default. I verified that it was set using (. System getProperties). I also tried explicitly setting the absolute path using -cp. No luck on either count. -Rich- On Mar 23, 5:14 am, revoltingdevelopment christopher.jay.jo...@gmail.com wrote: I also had the NO_SOURCE_FILE error when using contrib packages, upon upgrade to 20090320. My CLASSPATH included .. I had to revert to starting clojure with an explicit -cp. I'm new to both Java and Clojure, but this led me to think my CLASSPATH was being ignored. I chalked it up to my misunderstanding or not really keeping track of how I had things set up before, but it seemed different. On Mar 23, 9:24 am, Mark Volkmann r.mark.volkm...@gmail.com wrote: On Mon, Mar 23, 2009 at 7:34 AM, Rich rwml...@gmail.com wrote: Structure.clj does call ns as shown below: (ns Structure) So, as far as I can tell, Clojure should look for Structure.clj in the class path. At least, that's what it used to do. I guess I could move all the code into a sub-directory, and rename all the namespaces--but I'd rather keep it organized the way it is, if possible. Do you have . or the current directory in CLASSPATH? On Mar 23, 1:33 am, Mark Volkmann r.mark.volkm...@gmail.com wrote: On Mon, Mar 23, 2009 at 4:59 AM, Rich rwml...@gmail.com wrote: Hi, I'd been using the 20081217 release. The following code worked, as long as Structure was in the working directory: Clojure user= (use 'Structure) nil However, after I updated to 20090320, I get the following errors: Clojure user= (use 'Structure) java.io.FileNotFoundException: Could not locate Structure__init.class or Structure.clj on classpath: (NO_SOURCE_FILE:0) In both cases, I'm launching Clojure from the directory that contains Structure.clj as follows: java clojure.lang.Repl What am I doing wrong? Does Structure.clj contain a call to the ns macro? If so, I think you need to move Structure.clj to a subdirectory that matches its namespace. For example, if the namespace is a.b.c then you need a directory in the classpath that contains an a directory that contains a b directory that conains c.clj, not Structure.clj. -- R. Mark Volkmann Object Computing, Inc. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Suggestion for Java Clojure code, use of checkstyle or code formatter
Javadoc would be nice, but I do note that Rich's Java code is pretty darn clear ;) I also note the indentation style is similar to Whitesmith's according to Wikipedia http://en.wikipedia.org/wiki/Indent_style. I've always preferred the BSD curly brace level matching convention over the KR derivatives. That said aren't we all hacking on Clojure because we're done with this convention thing? ;) David On Tue, Mar 24, 2009 at 8:05 AM, Laurent PETIT laurent.pe...@gmail.comwrote: Why you guys want to suppress all the fun from clojure ? ;-) :-p 2009/3/24 Mark Volkmann r.mark.volkm...@gmail.com +1 for running all the code under src/jvm through some code formatter that uses something at least similar to the Sun Java conventions. On Mon, Mar 23, 2009 at 11:59 PM, BerlinBrown berlin.br...@gmail.com wrote: I was curious about how some of the clojure code worked and observed that the coding style is a little bit non idiomatic from typical Java coding conventions. E.g. there aren't any javadoc comments on methods or classes, non standard indents. Something like checkstyle might prove useful. http://checkstyle.sourceforge.net/ While, every programmer balks at conventions, I am sure there is a mountain of evidence for increased overall maintenance and other benefits. I know, I will get suggestions for clojure/lisp coding style. -- R. Mark Volkmann Object Computing, Inc. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: STM and useful concurrency
Some generic STM bits of wisdom: - STMs in standard languages (e.g. C, C++) suffer from having to track all memory references. THis overhead means the STM code typically starts 3x to 10x slower than non-STM code, which is a pretty stiff penalty to recover from. If you're only getting a 3x speedup on your 4-core machine, but you're starting 3x down then you're not ahead. - Abort/retry rates can commonly exceed 90% (e.g. 1-in-10 attempts succeeds) - There are very few languages w/real TM support, so good TM writing styles are still being figured out - THere are very few TM implementations, so good STM implementations are still being figured out - even the good feature set isn't really well known. - Clojure dodges several of these bullets (no need to track everything; already paying a high abstraction penalty (commonly), so the STM slowdown isn't really interestingly large (e.g. it's 3x over some base speed, not 3x on top of Clojure) - I DO have a Clojure program where the retry/fail rate approaches 99.99% - There are NOT good tools to figure out why TM's fail - if you have a high fail rate it's often hard to figure out even that! Cliff --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Generic functions again
2009/3/24 Konrad Hinsen konrad.hin...@laposte.net On Mar 24, 2009, at 11:19, mikel wrote: Dispatch is wholly deterministic; you never need prefer-method. There Then what is the rule for choosing one method when there are several that match the arguments? In the scope in which a generic function is applied, next-method is always bound to the next applicable method in a total ordering of applicable methods for the arguments supplied (see the first java.lang.Integer method below for an example of how to use next- method). applicable-methods is always bound to a function that returns a list of applicable methods, ordered from most- to least-specific; next-method is equal to (first (applicable-methods)). So I guess that the chosen method is the first one in the applicable- methods list, meaning the most specific one. The question is then how specificity is defined, in particular for multiple argument dispatch. Suppose in your example that I provide (define-method add [x y] ...) (define-method add [[x java.lang.Integer] y] ...) (define-method add [x [y java.lang.Integer]] ...) and call (add 3 3). Which of the methods is chosen? Isn't it the second, which is the most specific on the first argument ? (I think I remember this from CLOS ...) Konrad. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Suggestion for Java Clojure code, use of checkstyle or code formatter
Even though I don't really care for the indentation style used, it is (unlike most projects) consistent and clear. Joshua On Mar 24, 8:40 am, David Nolen dnolen.li...@gmail.com wrote: Javadoc would be nice, but I do note that Rich's Java code is pretty darn clear ;) I also note the indentation style is similar to Whitesmith's according to Wikipediahttp://en.wikipedia.org/wiki/Indent_style. I've always preferred the BSD curly brace level matching convention over the KR derivatives. That said aren't we all hacking on Clojure because we're done with this convention thing? ;) David On Tue, Mar 24, 2009 at 8:05 AM, Laurent PETIT laurent.pe...@gmail.comwrote: Why you guys want to suppress all the fun from clojure ? ;-) :-p 2009/3/24 Mark Volkmann r.mark.volkm...@gmail.com +1 for running all the code under src/jvm through some code formatter that uses something at least similar to the Sun Java conventions. On Mon, Mar 23, 2009 at 11:59 PM, BerlinBrown berlin.br...@gmail.com wrote: I was curious about how some of the clojure code worked and observed that the coding style is a little bit non idiomatic from typical Java coding conventions. E.g. there aren't any javadoc comments on methods or classes, non standard indents. Something like checkstyle might prove useful. http://checkstyle.sourceforge.net/ While, every programmer balks at conventions, I am sure there is a mountain of evidence for increased overall maintenance and other benefits. I know, I will get suggestions for clojure/lisp coding style. -- R. Mark Volkmann Object Computing, Inc. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Why not sorted-set-by?
Hi, all. I'm experimenting clojure. Some code, I needed something like sorted-set-by, but no such thing. So i used sorted-map-by ignoring value part. Is it deliberate for some reason? Or just not there? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Suggestion for Java Clojure code, use of checkstyle or code formatter
You mean by Sun Norvig conventions right ? ;) http://code.google.com/p/clojure/issues/detail?id=16q=prettycolspec=ID%20Type%20Status%20Priority%20Reporter%20Owner%20Summary On Mar 24, 1:46 am, Mark Volkmann r.mark.volkm...@gmail.com wrote: +1 for running all the code under src/jvm through some code formatter that uses something at least similar to the Sun Java conventions. On Mon, Mar 23, 2009 at 11:59 PM, BerlinBrown berlin.br...@gmail.com wrote: I was curious about how some of the clojure code worked and observed that the coding style is a little bit non idiomatic from typical Java coding conventions. E.g. there aren't any javadoc comments on methods or classes, non standard indents. Something like checkstyle might prove useful. http://checkstyle.sourceforge.net/ While, every programmer balks at conventions, I am sure there is a mountain of evidence for increased overall maintenance and other benefits. I know, I will get suggestions for clojure/lisp coding style. -- R. Mark Volkmann Object Computing, Inc. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Why not sorted-set-by?
Hi all. I'm experimenting cljoure. some code, i needed something like sorted-set-by. but, no such thing, so I emulated that using sorted-map-by. Is it deliberate for some reason? or just not there? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Why not sorted-set-by?
Hi, all. I'm experimenting clojure. Some code, I needed something like sorted-set-by, but no such thing. So i used sorted-map-by ignoring value part. Is it deliberate for some reason? Or just not there? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
I'm experimenting clojure - sorted-set-by?
Hi, all. I don't know why my previous posts ignored. spam filtering? so i changed title. I'm experimenting clojure. Some code, I needed something like sorted-set-by, but no such thing. So i used sorted-map-by ignoring value part. Is it deliberate for some reason? Or just not there? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Annotations and gen-class
Support for using JVM annotations with Clojure code has come up several times before, I'd like a feature request issue to be created and to start discussing the implementation. It seems that an annotations metadata tag could contain all annotations for an object, and any annotations that persist to runtime would need bytecode emitted. This appears straightforward, but I wonder if there will be a problem using Method or Parameter annotations. The motivation for this is to support Java libraries which depend on annotations at runtime for discovery and metadata persistence. Being able to integrate a class generated by gen-class with, for example, a Java project using Guice would be handy. Thoughts? -Matt --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: parallel iteration
Thanks guys, these solutions look much better already. But do I always have to have these 2 steps * merge collection * split collection It feels a bit inefficient, I don't know if it actually is, though. On Mar 24, 8:05 pm, Phlex ph...@telenet.be wrote: On 24/03/2009 1:06, pmf wrote: On Mar 24, 12:01 am, Rowdy Rednoserowdy.redn...@gmx.net wrote: Hi group, say I have 2 sequences (def seq-a '(a1 a2 a3)) (def seq-b '(b1 b2 b3)) and want to iterate over them in parallel, like this (par-doseq [a seq-a b seq-b] (prn a b)) which should print a1 b1 a2 b2 a3 b3 A combination of the interleave and partition functions would probably do what you want: (partition 2 (interleave [:a :b :c] [:d :e :f])) (Wrap it in a doall to force your side effects.) Another one : (doseq [[a b] (map vector '(1 2 3) '(a b c))] (println a b)) (defmacro par-doseq [bindings body] (let [bindings (partition 2 bindings)] `(doseq [~(vec (map first ,bindings)) (map vector ~@(map second ,bindings))] ~...@body))) cara.nio.echo= (par-doseq [a '(1 2 3) b '(a b c)] (println a b)) 1 a 2 b 3 c nil Sacha --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Annotations and gen-class
Some working code would make it a lot easier to understand *exactly* what you're looking for. Do you think you could post a few quick methods on github? If memory serves, the reflections package should be a good place to start. However, you'd need to ask *why* you need this. If the answer is I need to work with and modify a pre-existing, pre- tested, needs-to-stay-in-production application, then this is a great idea. Clojrue should help you glue your components together. If your answer is I'm making a brand new application, or This is for a side project, this might be a bad approach. Annotations generally are used to make up for a weakness in the Java language. Some Clojure language features could probably do the job better * Dynamic Typing * First class functions * Sequence functions. such as map/reduce/filter etc. * Macros Specifically, I think Guice (and other DI tools) should be avoided. They are the antithesis of functional programming, and first class functions will make your life much easier. Try re-thinking about a problem in a functional style. I'm willing to bet that you'll have a solution that is easier to write, easier to test, and will scale better. On Mar 24, 9:57 am, Matt Revelle mreve...@gmail.com wrote: Support for using JVM annotations with Clojure code has come up several times before, I'd like a feature request issue to be created and to start discussing the implementation. It seems that an annotations metadata tag could contain all annotations for an object, and any annotations that persist to runtime would need bytecode emitted. This appears straightforward, but I wonder if there will be a problem using Method or Parameter annotations. The motivation for this is to support Java libraries which depend on annotations at runtime for discovery and metadata persistence. Being able to integrate a class generated by gen-class with, for example, a Java project using Guice would be handy. Thoughts? -Matt --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: parallel iteration
You could define a helper function, zip (as in Haskell) : (def zip (partial map list)) and then use as showed above: (doseq [[x y] (zip [:a :b] [1 2])] (println x: x , y: y)) 2009/3/24 Rowdy Rednose rowdy.redn...@gmx.net Thanks guys, these solutions look much better already. But do I always have to have these 2 steps * merge collection * split collection It feels a bit inefficient, I don't know if it actually is, though. On Mar 24, 8:05 pm, Phlex ph...@telenet.be wrote: On 24/03/2009 1:06, pmf wrote: On Mar 24, 12:01 am, Rowdy Rednoserowdy.redn...@gmx.net wrote: Hi group, say I have 2 sequences (def seq-a '(a1 a2 a3)) (def seq-b '(b1 b2 b3)) and want to iterate over them in parallel, like this (par-doseq [a seq-a b seq-b] (prn a b)) which should print a1 b1 a2 b2 a3 b3 A combination of the interleave and partition functions would probably do what you want: (partition 2 (interleave [:a :b :c] [:d :e :f])) (Wrap it in a doall to force your side effects.) Another one : (doseq [[a b] (map vector '(1 2 3) '(a b c))] (println a b)) (defmacro par-doseq [bindings body] (let [bindings (partition 2 bindings)] `(doseq [~(vec (map first ,bindings)) (map vector ~@(map second ,bindings))] ~...@body))) cara.nio.echo= (par-doseq [a '(1 2 3) b '(a b c)] (println a b)) 1 a 2 b 3 c nil Sacha --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: parallel iteration
@Rowdy Take the time to do the interleave example by hand. You'll it does exactly what you want in one pass. On Mar 24, 10:10 am, Rowdy Rednose rowdy.redn...@gmx.net wrote: Thanks guys, these solutions look much better already. But do I always have to have these 2 steps * merge collection * split collection It feels a bit inefficient, I don't know if it actually is, though. On Mar 24, 8:05 pm, Phlex ph...@telenet.be wrote: On 24/03/2009 1:06, pmf wrote: On Mar 24, 12:01 am, Rowdy Rednoserowdy.redn...@gmx.net wrote: Hi group, say I have 2 sequences (def seq-a '(a1 a2 a3)) (def seq-b '(b1 b2 b3)) and want to iterate over them in parallel, like this (par-doseq [a seq-a b seq-b] (prn a b)) which should print a1 b1 a2 b2 a3 b3 A combination of the interleave and partition functions would probably do what you want: (partition 2 (interleave [:a :b :c] [:d :e :f])) (Wrap it in a doall to force your side effects.) Another one : (doseq [[a b] (map vector '(1 2 3) '(a b c))] (println a b)) (defmacro par-doseq [bindings body] (let [bindings (partition 2 bindings)] `(doseq [~(vec (map first ,bindings)) (map vector ~@(map second ,bindings))] ~...@body))) cara.nio.echo= (par-doseq [a '(1 2 3) b '(a b c)] (println a b)) 1 a 2 b 3 c nil Sacha --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
simple debugging utility
I want to write a function or macro that allows me to output the value of an expression without repeating it. For example, I want something like (dump (+ 1 2)) to output (+ 1 2) = 3. This works. (defn dump1 [string] (println string = (load-string string))) (dump1 (+ 1 2)) Note how I had to put the expression passed to dump1 in quotes to make a string. I'm wondering if there is a way to avoid that using a macro. The hard part is printing the expression. The following doesn't work. It outputs 3 = 3. (defmacro dump2 [expr] `(let [value# ~expr] (pr ~expr) (println = value#))) (dump2 (+ 1 2)) -- R. Mark Volkmann Object Computing, Inc. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
simple debugging utility
I want to write a function or macro that allows me to output the value of an expression without repeating it. For example, I want something like (dump (+ 1 2)) to output (+ 1 2) = 3. This works. (defn dump1 [string] (println string = (load-string string))) (dump1 (+ 1 2)) Note how I had to put the expression passed to dump1 in quotes to make a string. I'm wondering if there is a way to avoid that using a macro. The hard part is printing the expression. The following doesn't work. It outputs 3 = 3. (defmacro dump2 [expr] `(let [value# ~expr] (pr ~expr) (println = value#))) (dump2 (+ 1 2)) -- R. Mark Volkmann Object Computing, Inc. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Problem with CLASSPATH
On Mar 24, 2009, at 5:03 AM, Rich wrote: Has anyone gotten 20090320 to work on a new MacBook Pro running Leopard? I tried it just now and it worked for me. Here's the test I did: - Download 20090320 zip file - Expand it into dir - create a file in dir called Structure.clj with contents: (ns Structure) - cd to dir - launch clojure with java -cp clojure.jar:. clojure.main - at the prompt issue (use 'Structure) - receive the response nil I'm using java 1.6 on a 64-bit capable (Core2 Duo based) MacBook Pro. Does that same test fail on your machine? One thing to note is that namespace names should always have at least one period in them. I believe this is due to a rule regarding Java packages. At some point the clojure namespace became clojure.core for this reason. I haven't had a problem with such top level namespace names on my machine locally, but they're not officially supported. --Steve smime.p7s Description: S/MIME cryptographic signature
Re: Problem with CLASSPATH
On Tue, Mar 24, 2009 at 9:44 AM, Stephen C. Gilardi squee...@mac.com wrote: One thing to note is that namespace names should always have at least one period in them. I believe this is due to a rule regarding Java packages. At some point the clojure namespace became clojure.core for this reason. I haven't had a problem with such top level namespace names on my machine locally, but they're not officially supported. I hadn't run across that rule before. I guess the user namespace is an exception. That should be mentioned at http://clojure.org/namespaces. Where did you find that? -- R. Mark Volkmann Object Computing, Inc. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Problem with CLASSPATH
On Tue, Mar 24, 2009 at 9:44 AM, Stephen C. Gilardi squee...@mac.com wrote: One thing to note is that namespace names should always have at least one period in them. I believe this is due to a rule regarding Java packages. At some point the clojure namespace became clojure.core for this reason. I haven't had a problem with such top level namespace names on my machine locally, but they're not officially supported. I hadn't run across that rule before. I guess the user namespace is an exception. That should be mentioned at http://clojure.org/namespaces. Where did you find that? -- R. Mark Volkmann Object Computing, Inc. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: simple debugging utility
On Mar 24, 2009, at 15:44, Mark Volkmann wrote: I'm wondering if there is a way to avoid that using a macro. The hard part is printing the expression. The following doesn't work. It outputs 3 = 3. (defmacro dump2 [expr] `(let [value# ~expr] (pr ~expr) (println = value#))) (dump2 (+ 1 2)) All it takes to make it work is a slight modification: (defmacro dump [expr] `(let [value# ~expr] (pr (quote ~expr)) (println = value#))) (dump (+ 1 2)) prints: (+ 1 2) = 3 Konrad. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: simple debugging utility
On Tue, Mar 24, 2009 at 9:55 AM, Konrad Hinsen konrad.hin...@laposte.net wrote: On Mar 24, 2009, at 15:44, Mark Volkmann wrote: I'm wondering if there is a way to avoid that using a macro. The hard part is printing the expression. The following doesn't work. It outputs 3 = 3. (defmacro dump2 [expr] `(let [value# ~expr] (pr ~expr) (println = value#))) (dump2 (+ 1 2)) All it takes to make it work is a slight modification: (defmacro dump [expr] `(let [value# ~expr] (pr (quote ~expr)) (println = value#))) (dump (+ 1 2)) prints: (+ 1 2) = 3 Thanks! It looks like I don't need the let now. Does a macro have to evaluate to one form? For example, this works, but it seems I can't drop the do. (defmacro dump [expr] `(do (print (quote ~expr)) (println = ~expr))) -- R. Mark Volkmann Object Computing, Inc. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: simple debugging utility
2009/3/24 Mark Volkmann r.mark.volkm...@gmail.com: Thanks! It looks like I don't need the let now. Does a macro have to evaluate to one form? For example, this works, but it seems I can't drop the do. (defmacro dump [expr] `(do (print (quote ~expr)) (println = ~expr))) How about: (defmacro dump [expr] `(println '~expr = ~expr)) R. Mark Volkmann -- ! Lauri --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: simple debugging utility
On Mar 24, 2009, at 16:00, Mark Volkmann wrote: Thanks! It looks like I don't need the let now. Indeed. Does a macro have to evaluate to one form? For example, this works, but it seems I can't drop the do. Yes, a macro has to evaluate to one form. This is actually not so much a condition on macros as a consequence of the fact that a macro, like any function, has a single return value. What else could that reasonably be but a form? Konrad. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Problem with CLASSPATH
On Mar 24, 2009, at 10:49 AM, Mark Volkmann wrote: On Tue, Mar 24, 2009 at 9:44 AM, Stephen C. Gilardi squee...@mac.com wrote: One thing to note is that namespace names should always have at least one period in them. I believe this is due to a rule regarding Java packages. At some point the clojure namespace became clojure.core for this reason. I haven't had a problem with such top level namespace names on my machine locally, but they're not officially supported. I hadn't run across that rule before. I guess the user namespace is an exception. That should be mentioned at http://clojure.org/namespaces. Where did you find that? It turns out not to be a Java package name rule, but a consequence of how Clojure maps namespaces into Java. A Clojure namespace maps to a Java class. If the namespace has only one component in its name, the class that implements it will be not be in any package. It's classes at the top level (outside of any package) that may cause a problem. Rich's description here: http://groups.google.com/group/clojure/msg/58e3f8e5dfb876c9 includes: The main structural change related to AOT is that the mapping between a Clojure namespace and a Java package has changed. Where it was ns maps to package: my.fancy.lib == my/fancy/lib/lib.clj it is now ns maps to class: my.fancy.lib == my/fancy/lib.clj, when compiled, my/fancy/lib.class Just lift your files up a directory to accommodate this change. Note that this implies that all namespaces should have at least 2 segments, and following the Java package name guidelines, e.g. com.mydomain.mylib, is recommended. Accordingly, the clojure ns has been renamed clojure.core. Any explicitly qualified references will need to be changed. boot.clj has been renamed core.clj. He uses the word should there and that's consistent with it working OK in some cases, but it's a guideline that we should encourage and follow. I agree this should be mentioned on the namespaces page at clojure.org. --Steve smime.p7s Description: S/MIME cryptographic signature
Re: simple debugging utility
Eric Rochester has a debug macro, together with a walkthrough of how he built it, here http://writingcoding.blogspot.com/2008/09/stemming-part-19-debugging.html Joshua On Tue, Mar 24, 2009 at 4:43 PM, Mark Volkmann r.mark.volkm...@gmail.comwrote: I want to write a function or macro that allows me to output the value of an expression without repeating it. For example, I want something like (dump (+ 1 2)) to output (+ 1 2) = 3. This works. (defn dump1 [string] (println string = (load-string string))) (dump1 (+ 1 2)) Note how I had to put the expression passed to dump1 in quotes to make a string. I'm wondering if there is a way to avoid that using a macro. The hard part is printing the expression. The following doesn't work. It outputs 3 = 3. (defmacro dump2 [expr] `(let [value# ~expr] (pr ~expr) (println = value#))) (dump2 (+ 1 2)) -- R. Mark Volkmann Object Computing, Inc. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: parallel iteration
On 24/03/2009 15:10, Rowdy Rednose wrote: Thanks guys, these solutions look much better already. But do I always have to have these 2 steps * merge collection * split collection It feels a bit inefficient, I don't know if it actually is, though. Allright let's see what we can do : make a macro out of this : (loop [a '(1 2 3) b '(a b c d)] (when (and (seq a) (seq b)) (println (first a) (first b)) (recur (rest a) (rest b Might be easier to make a function first (defn par-doseq-fn [fn seqs] (loop [rests seqs] (when (every? identity (map seq rests)) (apply fn (map first rests)) (recur (map rest rests) cara= (par-doseq-fn #(println %1 %2) '(1 2 3) '(a b c)) 1 a 2 b 3 c (defmacro par-doseq [bindings body] (let [bindings (partition 2 bindings)] `(par-doseq-fn (fn ~(vec (map first bindings)) ~...@body) ~@(map second bindings cara= (par-doseq [a '(0 1 2) b '(a b c)] (println a b)) 0 a 1 b 2 c nil Now you get to run the micro-benchmarks ! Sacha --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: parallel iteration
(defn par-doseq-fn [fn seqs] (loop [rests seqs] (when (every? identity (map seq rests)) (apply fn (map first rests)) (recur (map rest rests) It should of course be like this : (defn par-doseq-fn [fn seqs] (loop [rests seqs] (when (every? seq rests) (apply fn (map first rests)) (recur (map rest rests) Sacha --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Annotations and gen-class
On Mar 24, 10:19 am, Sean francoisdev...@gmail.com wrote:
Some working code would make it a lot easier to understand *exactly*
what you're looking for. Do you think you could post a few quick
methods on github?
No need for gist, this will do as an example:
(ns some.namespace
(:gen-class
:methods [^#{:annotations [SomeAnnotation]} [aMethod [T] S]]
...)
This adds an annotation, SomeAnnotation, to the gen-class'd method,
aMethod.
If memory serves, the reflections package should
be a good place to start.
However, you'd need to ask *why* you need this.
If the answer is I need to work with and modify a pre-existing, pre-
tested, needs-to-stay-in-production application, then this is a great
idea. Clojrue should help you glue your components together.
If your answer is I'm making a brand new application, or This is
for a side project, this might be a bad approach. Annotations
generally are used to make up for a weakness in the Java language.
Some Clojure language features could probably do the job better
* Dynamic Typing
* First class functions
* Sequence functions. such as map/reduce/filter etc.
* Macros
Specifically, I think Guice (and other DI tools) should be avoided.
They are the antithesis of functional programming, and first class
functions will make your life much easier. Try re-thinking about a
problem in a functional style. I'm willing to bet that you'll have a
solution that is easier to write, easier to test, and will scale
better.
You're preaching to the choir. The reasoning behind supporting
annotations in gen-class is the
same as providing gen-class in the first place. Generating classes
usable in Java code is
sometimes necessary and as gen-class' feature set becomes more
complete the better it serves users.
On Mar 24, 9:57 am, Matt Revelle mreve...@gmail.com wrote:
Support for using JVM annotations with Clojure code has come up
several times before,
I'd like a feature request issue to be created and to start discussing
the implementation.
It seems that an annotations metadata tag could contain all
annotations for an object,
and any annotations that persist to runtime would need bytecode
emitted. This appears straightforward,
but I wonder if there will be a problem using Method or Parameter
annotations.
The motivation for this is to support Java libraries which depend on
annotations at runtime for discovery and metadata persistence.
Being able to integrate a class generated by gen-class with, for
example, a Java project using Guice would be handy.
Thoughts?
-Matt
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Clojure group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---
file io
is there something as simple as this in clojure? whole python program: of = open(filename,w) of.write(hello) of.close() I checked the api and looked around the wiki and google quickly and saw how to use java's stuff to do it ... but, welll... I noticed slurp in the api for reading ... but only the whole file at once (read() but no readline()). Is there something symmetrical for writing (outputting)? Is there a web page called File IO somewhere? 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 To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: parallel iteration
(defn par-doseq-fn [fn seqs] (loop [rests seqs] (when (every? identity (map seq rests)) (apply fn (map first rests)) (recur (map rest rests) It should of course be like this : (defn par-doseq-fn [fn seqs] (loop [rests seqs] (when (every? seq rests) (apply fn (map first rests)) (recur (map rest rests which amounts to (def par-doseq-fn (comp dorun map)) Though there is some consing going on as a result of the map... Ok that's it, enough of me flooding the mailing list =P Sacha --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: file io
Hello, try (with-open [of (java.io.FileWriter. /path/to/your/file)] (.write of coucou)) As far as java libraries are concerned, and answer commonly seen in this ml is : use apache commons io. And indeed it does the job well, but, yes, it's then another dependency to your project, for what one might consider a very basic feature. http://commons.apache.org/io/ HTH, -- Laurent 2009/3/24 e evier...@gmail.com is there something as simple as this in clojure? whole python program: of = open(filename,w) of.write(hello) of.close() I checked the api and looked around the wiki and google quickly and saw how to use java's stuff to do it ... but, welll... I noticed slurp in the api for reading ... but only the whole file at once (read() but no readline()). Is there something symmetrical for writing (outputting)? Is there a web page called File IO somewhere? 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 To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: file io
e wrote: is there something as simple as this in clojure? whole python program: of = open(filename,w) of.write(hello) of.close() I checked the api and looked around the wiki and google quickly and saw how to use java's stuff to do it ... but, welll... There are possibly other (better) ways to do it. One way is: user= (use 'clojure.contrib.duck-streams) nil user= (with-open [f (writer (file test.txt))] (binding [*out* f] (println hello world !!!))) nil user= % cat test.txt hello world !!! % clojure.contrib.duck-stream has an interesting set of functions. Parth I noticed slurp in the api for reading ... but only the whole file at once (read() but no readline()). Is there something symmetrical for writing (outputting)? Is there a web page called File IO somewhere? 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 To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: simple debugging utility
For reference, here's a version I wrote while I was working on cl- format and the pretty printer: (defn prerr [ args] Println to *err* (binding [*out* *err*] (apply println args))) (defmacro prlabel [prefix arg more-args] Print args to *err* in name = value format (cons 'prerr (cons (list 'quote prefix) (mapcat #(list (list 'quote %) = %) (cons arg more- args) It prints a label (which is a string, but the macro quotes it for you and a set of forms you want to print. Using the above example, this would be (prlabel foo (+ 1 2)) and it would print: foo (+ 1 2) = 3 A real example from the PrettyWriter is: (prlabel tf? (.getColumn this) (buffer-length tokens)) I make sure the output goes to *err* partially because that just seems right for trace output and partially because cl-format tends to have *out* bound at its whim. Tom On Mar 24, 8:32 am, Joshua Fox joshuat...@gmail.com wrote: Eric Rochester has a debug macro, together with a walkthrough of how he built it, herehttp://writingcoding.blogspot.com/2008/09/stemming-part-19-debugging Joshua On Tue, Mar 24, 2009 at 4:43 PM, Mark Volkmann r.mark.volkm...@gmail.comwrote: I want to write a function or macro that allows me to output the value of an expression without repeating it. For example, I want something like (dump (+ 1 2)) to output (+ 1 2) = 3. This works. (defn dump1 [string] (println string = (load-string string))) (dump1 (+ 1 2)) Note how I had to put the expression passed to dump1 in quotes to make a string. I'm wondering if there is a way to avoid that using a macro. The hard part is printing the expression. The following doesn't work. It outputs 3 = 3. (defmacro dump2 [expr] `(let [value# ~expr] (pr ~expr) (println = value#))) (dump2 (+ 1 2)) -- R. Mark Volkmann Object Computing, Inc. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: I'm experimenting clojure - sorted-set-by?
Hello! Yes, you are right, sorted-set-by is missing. Good news is - it is on the way :-) See issue 76: http://code.google.com/p/clojure/issues/detail?id=76 Frantisek On Mar 24, 5:35 am, hjlee hj.d@gmail.com wrote: Hi, all. I don't know why my previous posts ignored. spam filtering? so i changed title. I'm experimenting clojure. Some code, I needed something like sorted-set-by, but no such thing. So i used sorted-map-by ignoring value part. Is it deliberate for some reason? Or just not there? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Namespace confusion using clojure.contrib.zip-filter
Hi all, I'm getting an error I don't quite understand. Starting Clojure (r1329) and entering user (ns foo (:use [clojure.contrib.zip-filter :as zf])) I get an exception, java.lang.IllegalStateException: descendants already refers to: #'clojure.core/descendants in namespace: foo (NO_SOURCE_FILE:0) [Thrown class clojure.lang.Compiler$CompilerException] I notice that in zip_filter.clj the namespace declaration contains (:refer-clojure :exclude (descendants ancestors)) Do I need to do this as well if I'm going to use zip-filter? It looks like I do, though this isn't (explicitly) documented. Thanks for any clarification. -tree -- Tom Emerson tremer...@gmail.com http://treerex.blogspot.com/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Namespace confusion using clojure.contrib.zip-filter
The doc doesn't claim that :as works with use. But it works well with require : user (ns foo (:require [clojure.contrib.zip-filter :as zf])) HTH, -- Laurent 2009/3/24 Tom Emerson tremer...@gmail.com Hi all, I'm getting an error I don't quite understand. Starting Clojure (r1329) and entering user (ns foo (:use [clojure.contrib.zip-filter :as zf])) I get an exception, java.lang.IllegalStateException: descendants already refers to: #'clojure.core/descendants in namespace: foo (NO_SOURCE_FILE:0) [Thrown class clojure.lang.Compiler$CompilerException] I notice that in zip_filter.clj the namespace declaration contains (:refer-clojure :exclude (descendants ancestors)) Do I need to do this as well if I'm going to use zip-filter? It looks like I do, though this isn't (explicitly) documented. Thanks for any clarification. -tree -- Tom Emerson tremer...@gmail.com http://treerex.blogspot.com/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Namespace confusion using clojure.contrib.zip-filter
On Mar 24, 2009, at 1:01 PM, Tom Emerson wrote: Hi all, I'm getting an error I don't quite understand. Starting Clojure (r1329) and entering user (ns foo (:use [clojure.contrib.zip-filter :as zf])) Because you've used :use, you are referring all of clojure.contrib.zip-filter into foo. ns has already referred all of clojure.core into foo. They both define ancestors and descendants so you get an exception. Since you're providing an alias via :as, you have a few options: - change :use to :require and always prefix your zip-filter calls with zf/ - add :exclude (descendants ancestors) to your :use clause. Most of zip-filter will be available without qualification. For ancestors and descendants you'll need to use the zf/ prefix. - add an :only () clause to your :use clause, effectively changing it from a :use to a :require --Steve smime.p7s Description: S/MIME cryptographic signature
Re: Generic functions again
On Mar 24, 7:59 am, Laurent PETIT laurent.pe...@gmail.com wrote: 2009/3/24 Konrad Hinsen konrad.hin...@laposte.net On Mar 24, 2009, at 11:19, mikel wrote: Dispatch is wholly deterministic; you never need prefer-method. There Then what is the rule for choosing one method when there are several that match the arguments? In the scope in which a generic function is applied, next-method is always bound to the next applicable method in a total ordering of applicable methods for the arguments supplied (see the first java.lang.Integer method below for an example of how to use next- method). applicable-methods is always bound to a function that returns a list of applicable methods, ordered from most- to least-specific; next-method is equal to (first (applicable-methods)). So I guess that the chosen method is the first one in the applicable- methods list, meaning the most specific one. The question is then how specificity is defined, in particular for multiple argument dispatch. Suppose in your example that I provide (define-method add [x y] ...) (define-method add [[x java.lang.Integer] y] ...) (define-method add [x [y java.lang.Integer]] ...) and call (add 3 3). Which of the methods is chosen? Isn't it the second, which is the most specific on the first argument ? (I think I remember this from CLOS ...) That's correct. The default dispatch algorithm follows CLOS rules, which are just as you say. In CLOS, the default dispatch algorithm is the only one, unless you use MOP features to make a different kind of generic function. I've been intending to permit you to pass a dispatch function to define-generic-function if you wish, but it's not implmented yet. We'll see if I get around to it; I haven't needed such a feature yet in around twenty years of using CLOS and its immediate predecessors, but if someone were really hot on having it, that might make up my mind to implement it. It's noticeably slower than Clojure's MultiFn dispatch, which is in turn noticeably slower than Clozure Common Lisp's generic functions. There's certainly room for optimization, if it turns out to be useful enough to warrant it. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
re: oo
question: what do people think about the general topic of inheritance? my take on it so far is that inheritance apparently sounds like a good idea at first to some folks, but quickly turns into something of a nightmare if one is actually concerned with keeping a coherent semantics (so that (a) people can learn it (b) simulate it in their heads and (c) so you can have tools to check things maybe and (d) ultimately so the code using it sucks less -- things like LSP and Java Generics show how fubar it can easily be). so people have come up with mixins, and then traits. and interfaces. and stuff. mainly, i just hope that whatever OO Clojurians finally coalesce towards doesn't make the same mistakes that have already been made by plenty of other languages, from old C++ through to new Scala. (not that i have the Programming Language Theory chops to help much there, myself.) sincerely. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: file io
On Mar 24, 12:42 pm, Parth Malwankar parth.malwan...@gmail.com wrote: user= (with-open [f (writer (file test.txt))] (binding [*out* f] (println hello world !!!))) Or even more simply: (use 'clojure.contrib.duck-streams) (spit test.txt Hello, world!\n) -Stuart Sierra --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: version of - short-circuiting on nil
On Mon, Mar 23, 2009 at 6:49 PM, Laurent PETIT laurent.pe...@gmail.com wrote: Hello, there has been plenty of time to speak about that in the previous thread on the subject, and it's a shame these interesting proposals had to wait for the release of the functionality to pop up :-). But I think it's my fault: when nobody did additional comments on the thread, I considered one of the last proposals as silently accepted by most, and since it was one of Rich's proposals to use .?. and -?, I took them. So I did not close the brainstorming with a if everybody agrees, I'll use these names ... and write the patch. No worries, Laurent. Sorry for not joining the discussion earlier. :-) Actually I think the -? squiggle is quite a good name for this function. Best, Graham Concerning the fact that .. could be removed from clojure.core, why not. I suggest that the .?. version be removed when (if) .. is removed. Concerning the names, shouldn't maybe- be reserved for the real monadic version (I haven't seen how monads are implemented in clojure, and I'm not sure the signature of a maybe- monad would be the same as -?) ? Regards, -- Laurent 2009/3/23 Graham Fawcett graham.fawc...@gmail.com On Sun, Mar 22, 2009 at 9:05 PM, Stephen C. Gilardi squee...@mac.com wrote: On Mar 22, 2009, at 4:43 PM, Meikel Brandmeyer wrote: Is .?. necessary? - does the same job as .. by virtue of the .method notation, but is more general. So, why not get rid of .. and .?. completely? That sounds right to me, Meikel. I'm in favor of keeping only -? . Might I suggest maybe- ? This function has a strong similarity to the Maybe monad in Haskell and similar languages. and- would be another less Haskelly candidate, and is reminiscent of Scheme's and-let* which is also sort-of similar. Best, Graham --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Suggestion for Java Clojure code, use of checkstyle or code formatter
On Mar 24, 7:46 am, Mark Volkmann r.mark.volkm...@gmail.com wrote: +1 for running all the code under src/jvm through some code formatter that uses something at least similar to the Sun Java conventions. On Mon, Mar 23, 2009 at 11:59 PM, BerlinBrown berlin.br...@gmail.com wrote: I was curious about how some of the clojure code worked and observed that the coding style is a little bit non idiomatic from typical Java coding conventions. E.g. there aren't any javadoc comments on methods or classes, non standard indents. Something like checkstyle might prove useful. http://checkstyle.sourceforge.net/ While, every programmer balks at conventions, I am sure there is a mountain of evidence for increased overall maintenance and other benefits. I know, I will get suggestions for clojure/lisp coding style. My predictive powers are improving. When I saw the OP I subvocalized, Seems like something Volkmann would endorse. ;-) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: STM and useful concurrency
On Mar 24, 5:56 am, cliffc cli...@acm.org wrote: Some generic STM bits of wisdom: - STMs in standard languages (e.g. C, C++) suffer from having to track all memory references. THis overhead means the STM code typically starts 3x to 10x slower than non-STM code, which is a pretty stiff penalty to recover from. If you're only getting a 3x speedup on your 4-core machine, but you're starting 3x down then you're not ahead. - Abort/retry rates can commonly exceed 90% (e.g. 1-in-10 attempts succeeds) - There are very few languages w/real TM support, so good TM writing styles are still being figured out - THere are very few TM implementations, so good STM implementations are still being figured out - even the good feature set isn't really well known. - Clojure dodges several of these bullets (no need to track everything; already paying a high abstraction penalty (commonly), so the STM slowdown isn't really interestingly large (e.g. it's 3x over some base speed, not 3x on top of Clojure) I don't think I quite understand the abstraction penalty here. Are you saying that Clojure is on the order of 3x slower than Java the STM contributes little to that? Of the overhead, which parts do you think are the most significant (ie, dynamic typing, forced immutability, etc)? - I DO have a Clojure program where the retry/fail rate approaches 99.99% Would you mind describing the scenario a little for this? I guess it must be a highly contended transaction, but is the transaction large? Is it possible to optimize it, or are you at the stage where 99% retry is the best you can get? I also wanted to comment on the inefficiencies of retrying a transaction: If you have more hardware threads than logical threads, retrying is probably free (memory contention might make the whole system slow down though, so maybe not). If you have more logical threads than hardware threads, then the work you lose from having to retry may not be free - if you were to block instead of retry another logical thread would be allowed to run. I can imagine if I were tuning transactions I'd like the ability to mark a transaction as exclusive - ie if I had a heavily contended large transaction lots of logical threads that were wanting to run, it might be better to explicitly lock that guy, or perhaps only allow a couple of active threads in the transaction. Cheers, Brad --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: oo
On Mar 24, 12:58 pm, Raoul Duke rao...@gmail.com wrote: question: what do people think about the general topic of inheritance? my take on it so far is that inheritance apparently sounds like a good idea at first to some folks, but quickly turns into something of a nightmare if one is actually concerned with keeping a coherent semantics (so that (a) people can learn it (b) simulate it in their heads and (c) so you can have tools to check things maybe and (d) ultimately so the code using it sucks less -- things like LSP and Java Generics show how fubar it can easily be). so people have come up with mixins, and then traits. and interfaces. and stuff. mainly, i just hope that whatever OO Clojurians finally coalesce towards doesn't make the same mistakes that have already been made by plenty of other languages, from old C++ through to new Scala. (not that i have the Programming Language Theory chops to help much there, myself.) I'm not a big fan of inheritance; neither am I ardently opposed to it. It's basically an automated facility for copying common code. On the plus side, it's one approach to providing support for the principle of Don't Repeat Yourself. On the minus side, most systems with inheritance combine the inheritance of behavior with the inheritance of data structure, which are two totally different things. As always, conflating orthogonal concerns leads to gratuitous duplication: you inherit from a class because you want its data layout, but end up writing gratuitous extra code because the inherited behavior is no good to you (or vice versa). Also on the minus side, systems with inheritance encourage you to scatter your API definition over lots of places, which can be an obstacle to maintenance and judicious use. I personally like Haskell's philosophy in this area: there is a facility for defining data layouts, and there is a facility for defining protocols, and they are completely separate. You can define a new data layout without any reference to any behavior. Similarly, you can define a new protocol and the behaviors it supports, without any reference to any particular data layout. You can implement any protocol you like at any time for any data layout you want, without needeing to change the definitions of any data layouts. And, conversely, you can add and extend data layouts any time you want, without affecting existing implementations of behavior. A Clojure system with a similar philosophy might consist of two facilities: a facility for defining record types with named fields, with record-extension that enables you to say this record is that other record over there plus these fields; and a facility for defining multifunctions that dispatch on some computable characteristic of their arguments. Clojure's built-in defstruct provides a way to specify record types, but not to extend them. Konrad Hinsen is experimenting with a typesystem that provides another way to define data layouts. Clojure's built-in MultiFns provide one way to define functions that dispatch on computable characteristics of their arguments. I'm experimenting with implementing CLOS-style generic functions, which is another approach (I have found Clojure MultiFns awkward to use thus far, especially when trying to design extensible APIs around them; client code has to know too much about the implementation details of MultiFns--e.g. you have to know when and how to hand-tweak dispatching for the particular MultiFns you are given). --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: What's a convenient way of calling super.method()?
*bump* Just letting people know that this is still an important and unresolved issue for me. Calling super multi-methods? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: file io
does anyone else think that should be more fundamental like the python example? imagine saying that out loud to your friend who asks . . . and the amount of noise, visually: use clojure dot contrib dot duck dash streams. perhaps it is already the hope that it will spit will eventually sit next to slurp? I had thought of java.io.FileWriter. /path/to/your/file . . .. but it's sometimes the case that using the jvm is acceptable enough, but learning the java libraries isn't ... because then folks are learning two languages and it also really ties a basic thing to the java language. Thanks for the answer. On Tue, Mar 24, 2009 at 2:10 PM, Stuart Sierra the.stuart.sie...@gmail.comwrote: On Mar 24, 12:42 pm, Parth Malwankar parth.malwan...@gmail.com wrote: user= (with-open [f (writer (file test.txt))] (binding [*out* f] (println hello world !!!))) Or even more simply: (use 'clojure.contrib.duck-streams) (spit test.txt Hello, world!\n) -Stuart Sierra --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Suggestion for Java Clojure code, use of checkstyle or code formatter
+1 Using regular and proper formatting assists in submitting patches. A little Javadoc would be nice as well. On Tue, Mar 24, 2009 at 4:46 AM, Mark Volkmann r.mark.volkm...@gmail.com wrote: +1 for running all the code under src/jvm through some code formatter that uses something at least similar to the Sun Java conventions. On Mon, Mar 23, 2009 at 11:59 PM, BerlinBrown berlin.br...@gmail.com wrote: I was curious about how some of the clojure code worked and observed that the coding style is a little bit non idiomatic from typical Java coding conventions. E.g. there aren't any javadoc comments on methods or classes, non standard indents. Something like checkstyle might prove useful. http://checkstyle.sourceforge.net/ While, every programmer balks at conventions, I am sure there is a mountain of evidence for increased overall maintenance and other benefits. I know, I will get suggestions for clojure/lisp coding style. -- R. Mark Volkmann Object Computing, Inc. -- Howard M. Lewis Ship Creator Apache Tapestry and Apache HiveMind --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: simple debugging utility
Hi, Am 24.03.2009 um 16:00 schrieb Mark Volkmann: Thanks! It looks like I don't need the let now. But there are reasons to keep it! Eg. returning the expression result! (defmacro dump [expr] `(let [value# ~expr] (println (pr-str (quote ~expr)) = (pr-str value#)) value#)) Then you can mix in your dump macro where you want. Your version always returns nil. Or you can have a look at clojure.contrib.trace. Sincerely Meikel smime.p7s Description: S/MIME cryptographic signature
Re: Generic functions again
Hi, Am 24.03.2009 um 18:51 schrieb mikel: (define-method add [x y] ...) (define-method add [[x java.lang.Integer] y] ...) (define-method add [x [y java.lang.Integer]] ...) and call (add 3 3). Which of the methods is chosen? Isn't it the second, which is the most specific on the first argument ? (I think I remember this from CLOS ...) That's correct. I'm still not sure I understand how this is resolved. Suppose the following situation: (define-method foo [x some.inter.Face] ...) (define-method foo [x some.other.Interface] ...) Now suppose you call this function foo with something like (proxy [some.inter.Face some.other.Interface] [] ...). Which magic decides which method to use? Sincerely Meikel smime.p7s Description: S/MIME cryptographic signature
Re: Suggestion for Java Clojure code, use of checkstyle or code formatter
Hi, Am 24.03.2009 um 20:08 schrieb Howard Lewis Ship: Using regular and proper formatting assists in submitting patches. hahaha! If someone submitting a patch ever adhered to a coding convention of any sort. A little Javadoc would be nice as well. Yes. That would definitively be a good a thing, and it is a open issue in the issue list. Sincerely Meikel smime.p7s Description: S/MIME cryptographic signature
Re: Generic functions again
On Mar 24, 3:39 pm, Meikel Brandmeyer m...@kotka.de wrote: Hi, Am 24.03.2009 um 18:51 schrieb mikel: (define-method add [x y] ...) (define-method add [[x java.lang.Integer] y] ...) (define-method add [x [y java.lang.Integer]] ...) and call (add 3 3). Which of the methods is chosen? Isn't it the second, which is the most specific on the first argument ? (I think I remember this from CLOS ...) That's correct. I'm still not sure I understand how this is resolved. Suppose the following situation: (define-method foo [x some.inter.Face] ...) (define-method foo [x some.other.Interface] ...) Now suppose you call this function foo with something like (proxy [some.inter.Face some.other.Interface] [] ...). Which magic decides which method to use? Presently, that depends on what type you tell your proxy object to have, or, alternatively, what matching sequence you tell your generic function to have. The default matching sequence presently relies on the Clojure function named type, which is not defined for all possible Clojure values. You can, for example, use proxy to create an object for which type is not defined. If you then apply a generic function to that value, and the gf was created with the default dispatch sequence, the gf will raise an exception, because type raises an exception. The solutions open to you in the present implementation are: 1) give your proxy object a type (in the sense of the Clojure type function); or (2) create your generic function with a matching sequence suited to values for which type is not defined. A more comprehensive and automatic solution that is in the spirit of CLOS would be to arrange for your example to dispatch to the some.inter.Face method, because that's the one that appears farthest to the left in your proxy expression. That wouldn't be particularly hard to arrange; it would mean a special case for values for which type is not defined, and a small adjustment to the code that measures specificity of matches in the case of matching on class. A possible monkey wrench is that this approach can only be made to work if we can reliably infer from a proxy object the order of the class and interfaces as they appeared in the proxy expression that created it; I don't know off the top of my head whether we can safely make that assumption. CLOS says that if two matches are otherwise equally specific, the one on the left wins. Similarly, it says that if two classes define slots with the same name, the one farthest from the root of the class heterarchy (as defined by a standard traversal algorithm) wins. You can make a theoretical argument that these choices are arbitrary, and that the programmer should control those decisions. In practice, the CLOS approach is not a problem because: (1) the standard choices are, in practice, the ones that least often surprise programmers using them In other words, the assumption that parameters on the left trump those on the right seems to suit most people's intuitions; similarly, they seem to be comfortable with the assumption that slots defined later trump those defined earlier. (2) if you *really* want the decisions to fall out a different way, mechanisms are provided with which you can make that happen. I'm a fan of CLOS in this respect: I think the default mechanism for dispatch works well, and its arbitrariness is fine, because it's easy to understand, it very rarely produces surprises, and in those rare cases where it really isn't what you want, you have the power to change it. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Bit-syntax (Was: Re: I need help tracking down a performance problem.)
On Mon, 23 Mar 2009 19:41:07 -0700 Mark Engelberg mark.engelb...@gmail.com wrote: On Mon, Mar 23, 2009 at 7:31 PM, Vincent Foley vfo...@gmail.com wrote: More generally, is it possible that I'm just doing this whole thing wrong? That using vectors to represent binary fields and records in a declarative is just a bad idea and that I should try and explore lower- level alternatives? This reminds me... I would LOVE to see in Clojure something like Erlang's bit-packing/destructuring syntax for working with bit manipulation in a high-level way. http://www.erlang.se/euc/00/bit_syntax.html I'm actually casually hacking on something like this right now, as I want to attempt to port a radar processing code I wrote into Clojure. (It's currently implemented in modern C++ with a functional-ish style) The WSR-88D file format is *extremely* bizarre and convoluted and requires a lot of bit-fiddling. Half or more of the current code is dedicated to converting this format into something sane. I actually hate that part of my C++ implementation the most because it's all hand-written unpacking and endianness-fixing of byte arrays which seems impossible to clean up any further. -So- .. What I actually have so far is a macro that lets you basically write Erlang bit-syntax in S-exps and it will expand into a vector that you can use as the binding list of a let form. The IP header unpacking example in Erlang's documentation looks something like this: (let (bits dgram [ip-ver 4] [hdr-len 4] svc-type [tot-len 16] [id 16] [flags 3] [frag-off 13] ttl proto [hdr-cksum 16] [src-ip 32] [dst-ip 32] [rest-dgram :binary]) 'stuff) Not shown: floats, signedness, and endianness (defaults are all the same as Erlang). It's okay, but it looks unnatural and I don't really like doing it that way very much. The source and destination names are backwards (dgram is being destructured into ip-ver, hdr-len and so on), and the syntax hijacks the whole let form, because I don't think you can write a macro that automatically splices into its parent form. So I had been thinking of composing an email about what the likelihood of seeing extensibility API for destructuring would be. The idea being that the UI for the bit-syntax library would allow for this custom destructuring to be pervasive, look a little more conventional, and let you mix it with regular binding forms (instead of having to use an explicit let that is completely hijacked by the bit-syntax). You could of course write something that would unpack bits into a vector, and then destructure the vector on the left-hand side, but that separates the names which will be bound (on the left) from their field specifiers (passed to the macro on the right). I found this difficult to read when the specifier list gets large, so I implemented it this way so the bound names are next to their specifications (just like Erlang's). Details: the macro expands into a bunch of sequential let bindings that progressively tease apart the blob using some helper functions. I haven't actually implemented the functions that do this teasing yet because that requires me to go digging in Java API docs to see what they provide for dealing with bit-bashing, and I haven't had the inclination to do that just yet :) So, is there any chance of extensible destructuring? What would such an API look like? I have thought about it a lot, but the minutiae of doing this generally enough to be useful, but simple enough to be implementable are probably beyond my grasp. -Kyle --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: file io
i guess another way to say this is that I can see both sides of the argument ... on one side, it shouldn't be a priority to resolve problems that java already provides when there are probably other more pressing issues. And it's part of the design decision to allow users to leverage java libraries. On the other, I've heard people complain about the verbosity of trying to find libraries in java vs. python, and this could be an opportunity to fix that. On Tue, Mar 24, 2009 at 2:53 PM, e evier...@gmail.com wrote: does anyone else think that should be more fundamental like the python example? imagine saying that out loud to your friend who asks . . . and the amount of noise, visually: use clojure dot contrib dot duck dash streams. perhaps it is already the hope that it will spit will eventually sit next to slurp? I had thought of java.io.FileWriter. /path/to/your/file . . .. but it's sometimes the case that using the jvm is acceptable enough, but learning the java libraries isn't ... because then folks are learning two languages and it also really ties a basic thing to the java language. Thanks for the answer. On Tue, Mar 24, 2009 at 2:10 PM, Stuart Sierra the.stuart.sie...@gmail.com wrote: On Mar 24, 12:42 pm, Parth Malwankar parth.malwan...@gmail.com wrote: user= (with-open [f (writer (file test.txt))] (binding [*out* f] (println hello world !!!))) Or even more simply: (use 'clojure.contrib.duck-streams) (spit test.txt Hello, world!\n) -Stuart Sierra --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: STM and useful concurrency
I think Cliff may mean that each STM-participating memory access is 3x slower, but in Clojure, because of immutability, a very small proportion of accesses are Ref accesses, whereas in C/C++ *all* memory accesses would be. I agree that there's lots of room for adding instrumentation to Clojure's STM, and having done some STM in Haskell I'd like to see 'retry' and 'orElse' available too. 'retry' says The prerequisites for running this tx haven't been met, so retry -- but wait until at least one of the Refs I've read so far has changed 'orElse t1 t2' attempts t1, and if it retries doesn't retry it, but runs t2 instead -- if t2 retries t1 is tried again and so on. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Problem with CLASSPATH
I think I figured it out. If I install clojure.jar into /Library/Java/Extensions/ (the ext directory on Macs) then it won't work. Even if I use java -cp ... to point to a different clojure.jar. Simply having the jar in that folder breaks things. Once I deleted it from /Library/Java/Extensions, I could manually set the class path using java -cp and things worked fine again. So, at least I have a good work around. But does anyone know why placing the jars in the ext directory no longer works? It was my understanding that this was the recommended way to install Jars. Does placing them in the java.ext.dirs on other systems also cause problems? Or is this just a Mac thing? Thanks everyone for your help. -Rich- On Mar 24, 5:19 am, Stephen C. Gilardi squee...@mac.com wrote: On Mar 24, 2009, at 10:49 AM, Mark Volkmann wrote: On Tue, Mar 24, 2009 at 9:44 AM, Stephen C. Gilardi squee...@mac.com wrote: One thing to note is that namespace names should always have at least one period in them. I believe this is due to a rule regarding Java packages. At some point the clojure namespace became clojure.core for this reason. I haven't had a problem with such top level namespace names on my machine locally, but they're not officially supported. I hadn't run across that rule before. I guess the user namespace is an exception. That should be mentioned at http://clojure.org/namespaces. Where did you find that? It turns out not to be a Java package name rule, but a consequence of how Clojure maps namespaces into Java. A Clojure namespace maps to a Java class. If the namespace has only one component in its name, the class that implements it will be not be in any package. It's classes at the top level (outside of any package) that may cause a problem. Rich's description here: http://groups.google.com/group/clojure/msg/58e3f8e5dfb876c9 includes: The main structural change related to AOT is that the mapping between a Clojure namespace and a Java package has changed. Where it was ns maps to package: my.fancy.lib == my/fancy/lib/lib.clj it is now ns maps to class: my.fancy.lib == my/fancy/lib.clj, when compiled, my/fancy/lib.class Just lift your files up a directory to accommodate this change. Note that this implies that all namespaces should have at least 2 segments, and following the Java package name guidelines, e.g. com.mydomain.mylib, is recommended. Accordingly, the clojure ns has been renamed clojure.core. Any explicitly qualified references will need to be changed. boot.clj has been renamed core.clj. He uses the word should there and that's consistent with it working OK in some cases, but it's a guideline that we should encourage and follow. I agree this should be mentioned on the namespaces page at clojure.org. --Steve smime.p7s 3KViewDownload --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Generic functions again
Hi, Am 24.03.2009 um 22:36 schrieb mikel: CLOS says that if two matches are otherwise equally specific, the one on the left wins. Similarly, it says that if two classes define slots with the same name, the one farthest from the root of the class heterarchy (as defined by a standard traversal algorithm) wins. You can make a theoretical argument that these choices are arbitrary, and that the programmer should control those decisions. In practice, the CLOS approach is not a problem because: Thank you for the long explanation. Please allow me to be sceptical (fatigued and after all long day of work). CLOS is certainly a powerful system, but reading these rules makes me headaches. To use a gf I need to understand, which dispatch sequence, graph traversing algorithms or class definition orders are used. I will almost certainly mess this up. I personally prefer the explicit style, where I declare which method to prefer over another. So I don't have to rely on my leaky memory. But this is only some fuzzy feeling. I will certainly try gf when I'm in a more awaken state. Sincerely Meikel smime.p7s Description: S/MIME cryptographic signature
Re: STM and useful concurrency
A relevant question is: what is the relative cost of locking and blocking (in the pure Java approach) vs. the cost of retrying (in the Clojure/STM approach). I don't want to go out on a limb, having not looked at the Clojure STM implementation. However, I would bet that the costs are roughly equal. Even if Clojure was 50% slower, or 100% slower, the knowlege that you can spin up a large number of threads and not worry about deadlocks is ultimately more valuable. On Mon, Mar 23, 2009 at 12:36 PM, Mark Volkmann r.mark.volkm...@gmail.com wrote: On Mon, Mar 23, 2009 at 11:19 AM, Cosmin Stejerean cstejer...@gmail.com wrote: On Sun, Mar 22, 2009 at 9:12 PM, Mark Volkmann r.mark.volkm...@gmail.com wrote: I'm trying to understand the degree to which Clojure's STM provides more concurrency than Java's blocking approach. I know it's difficult to make generalizations and that specific applications need to be measured, but I'll give it a go anyway. Clearly using STM (dosync with Refs) makes code easier to write than using Java synchronization because you don't have to determine up front which objects need to be locked. In the Clojure approach, nothing is locked. Changes in the transaction happen to in-transaction values and there is only a small amount of blocking that occurs at the end of the transaction when changes are being committed. Score one for Clojure! What concerns me though is how often the work done in two transactions running in separate threads turns out to be useful work. It seems that it will typically be the case that when two concurrent transactions access the same Refs, one of them will commit and the other will retry. The retry will discard the in-transaction changes that were made to the Refs, essentially rendering the work it did of no value. So there was increased concurrency, but not useful concurrency. In the case where two transactions need to modify the same Ref they definitely to be serialized, either by explicitly using locks in Java, or by letting Clojure automatically retry one of them. In either case it about the same thing happens. Transaction A starts and finishes, then Transaction B starts and finishes. I don't think the same thing happens. In the case of Clojure, both transaction A and B start. Suppose A finishes first and commits. Then transaction B retries, finishes and commits. That's what I was referring to as non-useful work. I'm not saying it's the wrong approach, but it is different. Of course there is a chance that the transaction contains some conditional logic that makes it so the Refs to be accessed aren't always the same, but my speculation is that that's are rare occurrence. It's probably more typical that a transaction always accesses the same set of Refs every time it executes. Which Refs your transactions modify will depend heavily based on the specific application you are working on. For example I can imagine that an application dealing with bank accounts and transferring money between them the probability of two transactions concurrently hitting the same account is pretty low. In other applications where a lot of transactions modify the same global state the chances of conflicts are much higher. Agreed. This makes it seem that Java's locking approach isn't so bad. Well, it's bad that I have to identify the objects to lock, but it's good that it doesn't waste cycles doing work that will just be thrown away. There's a reason concurrent programming is notoriously hard in most languages, because it takes a lot of effort and skill to get right. Between having to correctly identify which objects need to be locked and trying to avoid deadlocks dealing with explicit locks can be pretty messy and dangerous. That doesn't mean Java's approach is bad, after all the internals of Clojure are implemented using Java locks. But explicit management of locks is often too low level and unnecessarily complex, and Clojure provides a higher level way of dealing with concurrency that makes it easier and safer to work with most of the time. I agree that Clojure makes the programming much easier, but is there a downside? Maybe the downside is performance. If I found out that a particular transaction was commonly being retried many times, is that a sign that I need to write the code differently? How would I find out that was happening? I know I could insert my own code to track that, but it seems like this may be a commonly needed tool for Clojure to detect excessive conflicts/retries in transactions. Maybe we could set a special variable like *track-retries* that would cause Clojure to produce a text file that describes all the transaction retries that occurred in a particular run of an application. If such a tool isn't needed or wouldn't be useful, I'd like to understand why. -- R. Mark Volkmann Object Computing, Inc. -- Howard M. Lewis Ship Creator Apache Tapestry and Apache HiveMind
Re: parallel iteration
Thanks all, microbenchmarking shows that a simple (time (doseq [[a b] (map vector list-a list-b)])) is ~50% faster on my system than (def par-doseq-fn (comp dorun map)) (defmacro par-doseq [bindings body] (let [bindings (partition 2 bindings)] `(par-doseq-fn (fn ~(vec (map first bindings)) ~...@body) ~@(map second bindings (time (par-doseq [a list-a b list-b] (+ a b))) I used these lists: (def list-a (repeat 40 1234)) (def list-b (repeat 40 2345)) On Mar 25, 1:22 am, Phlex ph...@telenet.be wrote: (defn par-doseq-fn [fn seqs] (loop [rests seqs] (when (every? identity (map seq rests)) (apply fn (map first rests)) (recur (map rest rests) It should of course be like this : (defn par-doseq-fn [fn seqs] (loop [rests seqs] (when (every? seq rests) (apply fn (map first rests)) (recur (map rest rests which amounts to (def par-doseq-fn (comp dorun map)) Though there is some consing going on as a result of the map... Ok that's it, enough of me flooding the mailing list =P Sacha --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: STM and useful concurrency
I don't want to go out on a limb, having not looked at the Clojure STM implementation. However, I would bet that the costs are roughly equal. Even if Clojure was 50% slower, or 100% slower, the knowlege that you can spin up a large number of threads and not worry about deadlocks is ultimately more valuable. It really depends on the problem. For instance in a Python program I wrote, a genetic algorithm was doing some evolution as fast as it could. The algorithm was heavily optimized, things that profiled slow were converted to C though Cython. I had a GUI that would display the current best individual every 5 seconds (not every generation because there is a rendering cost). To keep the GUI responsive, the evolution and the GUI would each run in their own thread. Only 2 locks were required to implement this. A stop (lock protected) variable would be set to True if the user through the GUI requested the evolution to stop. The evolution thread would look at this variable before computing the next generation (it would be unsafe to stop the evolution in an half-finished state). A best (also lock protected) variable would be set to the best individual after each new generation was computed. A profiling run reveals that a whooping 25% of the execution time is spent acquiring locks! Had I coded this in Clojure, there would not even be a transaction! best would be asynchronously set and read and stop would be useless as I could easily discard an half-finished computation of immutable data. I didn't convert the code yet to Clojure yet but it seems obvious that Clojure's concurrency model would have been much faster. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: STM and useful concurrency
On Tue, Mar 24, 2009 at 11:40 PM, Howard Lewis Ship hls...@gmail.com wrote: A relevant question is: what is the relative cost of locking and blocking (in the pure Java approach) vs. the cost of retrying (in the Clojure/STM approach). I can't think, off the top of my head, of a fair way to compare the two. You can have a single global lock, a lock per object, lock striping. Likewise, a transaction can touch many or few refs and the changes can be cheap or expensive to calculate versus the cost of committing a transaction. If runtime performance is that important, then I think a carefully crafted lock scheme is the winner. However, this is weighted against the dificulty of implementing it correctly; without dead-locks, and without undersynchronized windows. Also, another problem with locking is that, depending on the problem, it may just be too difficult to do correctly with the skill that is available to a given project. I don't want to go out on a limb, having not looked at the Clojure STM implementation. However, I would bet that the costs are roughly equal. Even if Clojure was 50% slower, or 100% slower, the knowlege that you can spin up a large number of threads and not worry about deadlocks is ultimately more valuable. On Mon, Mar 23, 2009 at 12:36 PM, Mark Volkmann r.mark.volkm...@gmail.com wrote: On Mon, Mar 23, 2009 at 11:19 AM, Cosmin Stejerean cstejer...@gmail.com wrote: On Sun, Mar 22, 2009 at 9:12 PM, Mark Volkmann r.mark.volkm...@gmail.com wrote: I'm trying to understand the degree to which Clojure's STM provides more concurrency than Java's blocking approach. I know it's difficult to make generalizations and that specific applications need to be measured, but I'll give it a go anyway. Clearly using STM (dosync with Refs) makes code easier to write than using Java synchronization because you don't have to determine up front which objects need to be locked. In the Clojure approach, nothing is locked. Changes in the transaction happen to in-transaction values and there is only a small amount of blocking that occurs at the end of the transaction when changes are being committed. Score one for Clojure! What concerns me though is how often the work done in two transactions running in separate threads turns out to be useful work. It seems that it will typically be the case that when two concurrent transactions access the same Refs, one of them will commit and the other will retry. The retry will discard the in-transaction changes that were made to the Refs, essentially rendering the work it did of no value. So there was increased concurrency, but not useful concurrency. In the case where two transactions need to modify the same Ref they definitely to be serialized, either by explicitly using locks in Java, or by letting Clojure automatically retry one of them. In either case it about the same thing happens. Transaction A starts and finishes, then Transaction B starts and finishes. I don't think the same thing happens. In the case of Clojure, both transaction A and B start. Suppose A finishes first and commits. Then transaction B retries, finishes and commits. That's what I was referring to as non-useful work. I'm not saying it's the wrong approach, but it is different. Of course there is a chance that the transaction contains some conditional logic that makes it so the Refs to be accessed aren't always the same, but my speculation is that that's are rare occurrence. It's probably more typical that a transaction always accesses the same set of Refs every time it executes. Which Refs your transactions modify will depend heavily based on the specific application you are working on. For example I can imagine that an application dealing with bank accounts and transferring money between them the probability of two transactions concurrently hitting the same account is pretty low. In other applications where a lot of transactions modify the same global state the chances of conflicts are much higher. Agreed. This makes it seem that Java's locking approach isn't so bad. Well, it's bad that I have to identify the objects to lock, but it's good that it doesn't waste cycles doing work that will just be thrown away. There's a reason concurrent programming is notoriously hard in most languages, because it takes a lot of effort and skill to get right. Between having to correctly identify which objects need to be locked and trying to avoid deadlocks dealing with explicit locks can be pretty messy and dangerous. That doesn't mean Java's approach is bad, after all the internals of Clojure are implemented using Java locks. But explicit management of locks is often too low level and unnecessarily complex, and Clojure provides a higher level way of dealing with concurrency that makes it easier and safer to work with most of the time. I agree that Clojure makes the programming much easier, but is there a downside? Maybe the downside
dynamic member-symbol in (.) form
Hi, Is there any way to get a dynamic member-symbol for use in the (.) special form? For example, I get the following exception: user= (def obj (Object.)) #'user/obj user= (. obj (symbol f)) java.lang.IllegalArgumentException: No matching method found: symbol for class java.lang.Object I expected this to behave like: (. obj f), so I can change the accessed member by changing the argument in (symbol ...), but was surprised by the result... 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 To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: file io
On Mar 24, 11:53 pm, e evier...@gmail.com wrote: does anyone else think that should be more fundamental like the python example? imagine saying that out loud to your friend who asks . . . and the amount of noise, visually: use clojure dot contrib dot duck dash streams. perhaps it is already the hope that it will spit will eventually sit next to slurp? This has come up before on the list. I am not sure about where things stand with that though. http://groups.google.com/group/clojure/browse_thread/thread/31f01808c225ecc1/d0e286fa0c8ef7d2 http://groups.google.com/group/clojure/browse_thread/thread/d8064dbb94c5cd2c/ba355cfe2c708068 I think it would be nice to have spit in the core, especially for people like me who aren't too good with java. But having clojure-contrib.duck-streams definately makes life easier :) Parth --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Proposed Change to str-utils
Okay, I've made some changes to my proposed str-utils. I've also got a few answers to some of the issues Stuart raised. New Changes 1. re-strip is now lazy I re-wrote this method to used the re-partition method in str-utils. This enables the laziness, and helped be consolidate my Java interactions into fewer functions. 2. re-strip options changed I removed the ability to pass a :limit option. I replaced it with :offset and :length options. Seemed to make the function more flexible :) 3. created nearby function The nearby function returns a lazy sequence of strings nearby the input string. It's inspired by the Norvig spellchecker example. I'd like to propose adding this method to the library, because I'm interested in what uses creative people will have for it. 4. Added README.html This file contains usage on every method in my proposed str-utils Response to Stuart's Issues You've raised some good points with my proposal. However, I think there is some hidden value in including the functions in the library. 1. Repeated The main reason I have for including the repeated methods (trim,strip,downcase,upcase) in the str-utils library is program flow. Take the following two examples (map downcase a-list) (map #(. % toLowerCase) a-list) It's my purely subjective opinion that the first method reads much nicer. I'm also a web developer, so I do a lot of string processing. I have a subjective preference for functions that make code more concise, and my code will read a little shorter with the downcase function in it. I guess my main argument is that a more concise way of stating the same thing does add value. For example, the jQuery selector can be called using the function jQuery(). However, it is always written $() to save time. In my view, the $() shortcut does add value. This is why I think you should consider adding my repeated methods to str- utils. 2. Methods in Apache Commons The second issue you raise is with methods like capitalize, that are available in Apache Commons. First of all, the exact reasoning I went through above could easily be applied to the following s-exp (map capitalize a-list) However, I believe there is an additional reason for including these methods in the library. By requiring Apache Commons, you've increased the number of jars I need to maintain. Granted, a lot of people are used to using the commons. It is still one more thing that requires maintenance, though. By making capitalize (and others) part of contrib, it reduces the amount of work I have to do to get this functionality. In conclusion, I'd recommend making the str-utils one of the slickest libraries in Clojure. As developers, we know how strong string manipulation makes writing code easier. If Clojure has incredible string support, developers will be more impressed. Let's go out of our way to make string manipulation in Clojure easier than in any other language. Besides, once we get a kick-ass string library working, we can then abstract the routines to work on any pattern of symbols, and give our macro writers a boost. Sean On Mar 24, 2:22 pm, Stuart Sierra the.stuart.sie...@gmail.com wrote: On Mar 23, 9:46 pm, Sean francoisdev...@gmail.com wrote: http://github.com/francoisdevlin/clojure-str-utils-proposal/tree/master I'm not sure what the directory structure should be for everything still. Perhaps somebody can point out how it should be done. I'll put the original post in the README Long story short: multi-methods could be awesome Hi Sean, This is interesting. One quick comment, though: the trim, strip, upcase, and downcase functions don't add anything to the original Java methods. Rich and others have warned against adding wrapper functions just to hide Java. Some of these functions, like capitalize, are available in Apache Commons Lang, the StringUtils class. -Stuart Sierra --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Proposed Change to str-utils
Hi, I would generally agree with Stuart that wrapping Java functions is not a good idea. However, string functions come up so often that I think that this is one area where the rule should be broken, if only for readablility. Making str-utils kick-ass is a great idea. pc On Mar 24, 7:05 pm, Sean francoisdev...@gmail.com wrote: Okay, I've made some changes to my proposed str-utils. I've also got a few answers to some of the issues Stuart raised. New Changes 1. re-strip is now lazy I re-wrote this method to used the re-partition method in str-utils. This enables the laziness, and helped be consolidate my Java interactions into fewer functions. 2. re-strip options changed I removed the ability to pass a :limit option. I replaced it with :offset and :length options. Seemed to make the function more flexible :) 3. created nearby function The nearby function returns a lazy sequence of strings nearby the input string. It's inspired by the Norvig spellchecker example. I'd like to propose adding this method to the library, because I'm interested in what uses creative people will have for it. 4. Added README.html This file contains usage on every method in my proposed str-utils Response to Stuart's Issues You've raised some good points with my proposal. However, I think there is some hidden value in including the functions in the library. 1. Repeated The main reason I have for including the repeated methods (trim,strip,downcase,upcase) in the str-utils library is program flow. Take the following two examples (map downcase a-list) (map #(. % toLowerCase) a-list) It's my purely subjective opinion that the first method reads much nicer. I'm also a web developer, so I do a lot of string processing. I have a subjective preference for functions that make code more concise, and my code will read a little shorter with the downcase function in it. I guess my main argument is that a more concise way of stating the same thing does add value. For example, the jQuery selector can be called using the function jQuery(). However, it is always written $() to save time. In my view, the $() shortcut does add value. This is why I think you should consider adding my repeated methods to str- utils. 2. Methods in Apache Commons The second issue you raise is with methods like capitalize, that are available in Apache Commons. First of all, the exact reasoning I went through above could easily be applied to the following s-exp (map capitalize a-list) However, I believe there is an additional reason for including these methods in the library. By requiring Apache Commons, you've increased the number of jars I need to maintain. Granted, a lot of people are used to using the commons. It is still one more thing that requires maintenance, though. By making capitalize (and others) part of contrib, it reduces the amount of work I have to do to get this functionality. In conclusion, I'd recommend making the str-utils one of the slickest libraries in Clojure. As developers, we know how strong string manipulation makes writing code easier. If Clojure has incredible string support, developers will be more impressed. Let's go out of our way to make string manipulation in Clojure easier than in any other language. Besides, once we get a kick-ass string library working, we can then abstract the routines to work on any pattern of symbols, and give our macro writers a boost. Sean On Mar 24, 2:22 pm, Stuart Sierra the.stuart.sie...@gmail.com wrote: On Mar 23, 9:46 pm, Sean francoisdev...@gmail.com wrote: http://github.com/francoisdevlin/clojure-str-utils-proposal/tree/master I'm not sure what the directory structure should be for everything still. Perhaps somebody can point out how it should be done. I'll put the original post in the README Long story short: multi-methods could be awesome Hi Sean, This is interesting. One quick comment, though: the trim, strip, upcase, and downcase functions don't add anything to the original Java methods. Rich and others have warned against adding wrapper functions just to hide Java. Some of these functions, like capitalize, are available in Apache Commons Lang, the StringUtils class. -Stuart Sierra --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Mapping a function over a map's values
Awesome. Thanks Konrad. On Mar 23, 4:11 am, Konrad Hinsen konrad.hin...@laposte.net wrote: On 22.03.2009, at 21:10, Jon Nadal wrote: I often need to map a function over the values of a map while preserving keys--something like: ... Is there a more concise way to do this in Clojure? If not, is this something that might be worth putting in the contrib? Look at clojure.contrib.generic.functor/fmap. It does what you need for maps, for all the other Clojure collections (where it works like map except that its return value is a collection of the same type as the input value), and you can implement it for any type you define yourself, e.g. a tree structure. Konrad. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: file io
It'd be nice to have a macro that worked more like the first example - spit is great for one-liners, but the fact that it opens and closes the file each time you call it seems a bit painful for anything more complex. Something that ends up working like: (with-out-as test.txt (println hello) (println world)) Hmm - I've never written a macro, maybe I should give this a try... - Korny On Wed, Mar 25, 2009 at 5:10 AM, Stuart Sierra the.stuart.sie...@gmail.comwrote: On Mar 24, 12:42 pm, Parth Malwankar parth.malwan...@gmail.com wrote: user= (with-open [f (writer (file test.txt))] (binding [*out* f] (println hello world !!!))) Or even more simply: (use 'clojure.contrib.duck-streams) (spit test.txt Hello, world!\n) -Stuart Sierra -- Kornelis Sietsma korny at my surname dot com Every jumbled pile of person has a thinking part that wonders what the part that isn't thinking isn't thinking of --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: file io
I'm interested to know what the process/priority is on bubbling things up from contrib into the core. Is a discussion under way about going through it all? I also think it's good to have cross-language conventions sometimes unless there are compelling reasons. For example, slurp is, perhaps, marginally better than read because it may help express that it reads the whole file. Whereas, in Python, one only knows that read reads the whole file when they compare it to the fact that there is readline(). BUT, basing it on python, yet IMPROVING, I'd advocate for read-all and read-line. Totally consistent AND unambiguous. Unless there is a compelling reason (saving a few chars or being cute don't count) to deviate from read and write, it just makes it needlessly harder for people coming from other languages (IMnsHO) On Tue, Mar 24, 2009 at 11:05 PM, Korny Sietsma ko...@sietsma.com wrote: It'd be nice to have a macro that worked more like the first example - spit is great for one-liners, but the fact that it opens and closes the file each time you call it seems a bit painful for anything more complex. Something that ends up working like: (with-out-as test.txt (println hello) (println world)) Hmm - I've never written a macro, maybe I should give this a try... - Korny On Wed, Mar 25, 2009 at 5:10 AM, Stuart Sierra the.stuart.sie...@gmail.com wrote: On Mar 24, 12:42 pm, Parth Malwankar parth.malwan...@gmail.com wrote: user= (with-open [f (writer (file test.txt))] (binding [*out* f] (println hello world !!!))) Or even more simply: (use 'clojure.contrib.duck-streams) (spit test.txt Hello, world!\n) -Stuart Sierra -- Kornelis Sietsma korny at my surname dot com Every jumbled pile of person has a thinking part that wonders what the part that isn't thinking isn't thinking of --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Generic functions again
On Mar 24, 5:37 pm, Meikel Brandmeyer m...@kotka.de wrote: Hi, Am 24.03.2009 um 22:36 schrieb mikel: CLOS says that if two matches are otherwise equally specific, the one on the left wins. Similarly, it says that if two classes define slots with the same name, the one farthest from the root of the class heterarchy (as defined by a standard traversal algorithm) wins. You can make a theoretical argument that these choices are arbitrary, and that the programmer should control those decisions. In practice, the CLOS approach is not a problem because: Thank you for the long explanation. Please allow me to be sceptical (fatigued and after all long day of work). CLOS is certainly a powerful system, but reading these rules makes me headaches. To use a gf I need to understand, which dispatch sequence, graph traversing algorithms or class definition orders are used. I will almost certainly mess this up. I personally prefer the explicit style, where I declare which method to prefer over another. So I don't have to rely on my leaky memory. But this is only some fuzzy feeling. I will certainly try gf when I'm in a more awaken state. I know what you mean. My own experience of learning CLOS lo, these many years ago was that the explanations seemed sort of impenetrable, but that when I started actually using it, it was quite straightforward and easy to understand. In practice, the only time I've needed to understand anything about the mechanics of dispatch and applicable method ordering is when I'm implementing them. Applied to 11, a method on Integer is more specific than a method on Number, which is more specific than a method on Object. If your method on Integer calls next-method, then in that case, next- method is the method on Number. Applied to [1 2], a method on [Integer Number] is more specific than a method on [Number Integer], because the more specific class comes first. That's pretty much to all you need to know to use generic functions productively. There are more esoteric things to learn about them if you want to do esoteric things, but the circumstances where one needs to do those things tend to be...esoteric. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: file io
On Tue, Mar 24, 2009 at 10:19 PM, e evier...@gmail.com wrote: I'm interested to know what the process/priority is on bubbling things up from contrib into the core. Is a discussion under way about going through it all? I also think it's good to have cross-language conventions sometimes unless there are compelling reasons. For example, slurp is, perhaps, marginally better than read because it may help express that it reads the whole file. Whereas, in Python, one only knows that read reads the whole file when they compare it to the fact that there is readline(). BUT, basing it on python, yet IMPROVING, I'd advocate for read-all and read-line. Totally consistent AND unambiguous. There's a reason Python's read is called read and not read-all, because it takes an argument for how many bytes to read. This argument just happens to be optional, in which case it will read everything. This is particularly useful when reading data from a binary file where you have to read the data in chunks (and you obviously can't rely on readline). Given that I don't see the need for also having a read-all function. -- Cosmin Stejerean http://offbytwo.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
