Re: Generic functions again
On Tue, Mar 24, 2009 at 5:37 PM, Meikel Brandmeyer 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. > Interestingly enough the rules described above seem to be exactly how multiple inheritance works in Python, and they seem to me pretty easy to understand. Imagine that you specify interfaces left to right in order of importance, and therefore when a generic function is defined for two of them the leftmost one wins. Should you happen not to remember though you can quickly try out an example at the REPL. I do that all the time in Python when I want to verify that what I remember is in fact correct. -- 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 -~--~~~~--~~--~--~---
Re: file io
On Tue, Mar 24, 2009 at 10:19 PM, e 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 -~--~~~~--~~--~--~---
Re: Generic functions again
On Mar 24, 5:37 pm, Meikel Brandmeyer 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
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 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 >> 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
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 wrote: > > On Mar 24, 12:42 pm, Parth Malwankar > 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: Mapping a function over a map's values
Awesome. Thanks Konrad. On Mar 23, 4:11 am, Konrad Hinsen 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: 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 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 wrote: > > > On Mar 23, 9:46 pm, Sean 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
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 wrote: > On Mar 23, 9:46 pm, Sean 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: file io
On Mar 24, 11:53 pm, e 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 -~--~~~~--~~--~--~---
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: STM and useful concurrency
On Tue, Mar 24, 2009 at 11:40 PM, Howard Lewis Ship 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 > wrote: >> >> On Mon, Mar 23, 2009 at 11:19 AM, Cosmin Stejerean >> wrote: >>> >>> On Sun, Mar 22, 2009 at 9:12 PM, Mark Volkmann >>> 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
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: 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 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
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 wrote: > > On Mon, Mar 23, 2009 at 11:19 AM, Cosmin Stejerean > wrote: >> >> On Sun, Mar 22, 2009 at 9:12 PM, Mark Volkmann >> 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 Comp
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: 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" wrote: > On Mar 24, 2009, at 10:49 AM, Mark Volkmann wrote: > > > > > On Tue, Mar 24, 2009 at 9:44 AM, Stephen C. Gilardi > > 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: 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: 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 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 >> 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 -~--~~~~--~~--~--~---
Bit-syntax (Was: Re: I need help tracking down a performance problem.)
On Mon, 23 Mar 2009 19:41:07 -0700 Mark Engelberg wrote: > > On Mon, Mar 23, 2009 at 7:31 PM, Vincent Foley > 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: Generic functions again
On Mar 24, 3:39 pm, Meikel Brandmeyer 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 -~--~~~~--~~--~--~---
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
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: 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: Promise for absense of side effects
Another link that gives an easy understandable intro into gradual typing: http://ece-www.colorado.edu/~siek/gradualtyping.html By adding local and global switches this behaviour could be made completely optional, allowing everyone to have as much typing as one wants to have in the code. Btw, is anyone currently working on any code analysis tools for Clojure? Something like the Erlang Dialyzer, or gradual typing? --~--~-~--~~~---~--~~ You 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 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 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: 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 wrote: > > On Mar 24, 12:42 pm, Parth Malwankar > 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: 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: oo
On Mar 24, 12:58 pm, Raoul Duke 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: STM and useful concurrency
On Mar 24, 5:56 am, cliffc 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: Suggestion for Java Clojure code, use of checkstyle or code formatter
On Mar 24, 7:46 am, Mark Volkmann 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 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: Proposed Change to str-utils
On Mar 23, 9:46 pm, Sean 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: version of -> short-circuiting on nil
On Mon, Mar 23, 2009 at 6:49 PM, Laurent PETIT 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 >> >> On Sun, Mar 22, 2009 at 9:05 PM, Stephen C. Gilardi >> 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: file io
On Mar 24, 12:42 pm, Parth Malwankar 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: 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: Generic functions again
On Mar 24, 7:59 am, Laurent PETIT wrote: > 2009/3/24 Konrad Hinsen > > > > > > > > > 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: 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: 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 > > 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 -~--~~~~--~~--~--~---
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: 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 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 -~--~~~~--~~--~--~---
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 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 > wrote: > > > > > 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: 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: 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 > 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 -~--~~~~--~~--~--~---
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: Annotations and gen-class
On Mar 24, 10:19 am, Sean 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 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
> (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: 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: 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 wrote: > > 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 10:49 AM, Mark Volkmann wrote: On Tue, Mar 24, 2009 at 9:44 AM, Stephen C. Gilardi 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
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: simple debugging utility
2009/3/24 Mark Volkmann : > > 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 Tue, Mar 24, 2009 at 9:55 AM, Konrad Hinsen 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
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: Problem with CLASSPATH
On Tue, Mar 24, 2009 at 9:44 AM, Stephen C. Gilardi 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 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 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
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: 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 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 wrote: > > > On 24/03/2009 1:06, pmf wrote: > > > > On Mar 24, 12:01 am, Rowdy Rednose 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
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 > > 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 wrote: > > On 24/03/2009 1:06, pmf wrote: > > > > > On Mar 24, 12:01 am, Rowdy Rednose 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 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
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 wrote: > On 24/03/2009 1:06, pmf wrote: > > > On Mar 24, 12:01 am, Rowdy Rednose 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 -~--~~~~--~~--~--~---
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 -~--~~~~--~~--~--~---
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 -~--~~~~--~~--~--~---
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 -~--~~~~--~~--~--~---
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=16&q=pretty&colspec=ID%20Type%20Status%20Priority%20Reporter%20Owner%20Summary On Mar 24, 1:46 am, Mark Volkmann 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 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
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 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 K&R 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 wrote: > > > > > Why you guys want to suppress all the fun from clojure ? ;-) :-p > > > 2009/3/24 Mark Volkmann > > >> +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 > >> 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: Generic functions again
2009/3/24 Konrad Hinsen > > 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: 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: 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 K&R 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 wrote: > Why you guys want to suppress all the fun from clojure ? ;-) :-p > > > 2009/3/24 Mark Volkmann > > >> +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 >> 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 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 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 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 > > > > > 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 wrote: > > > > > > > On Mon, Mar 23, 2009 at 7:34 AM, Rich 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 > wrote: > > > > > >> On Mon, Mar 23, 2009 at 4:59 AM, Rich > 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 unsu
Re: Suggestion for Java Clojure code, use of checkstyle or code formatter
Why you guys want to suppress all the fun from clojure ? ;-) :-p 2009/3/24 Mark Volkmann > > +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 > 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: 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 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
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 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 kee
Re: parallel iteration
On 24/03/2009 1:06, pmf wrote: > On Mar 24, 12:01 am, Rowdy Rednose 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: 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 -~--~~~~--~~--~--~---
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)) # 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)) # 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)) # 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)) # user> (add "foo" "bar") "foobar" user> (define-method add [[x java.lang.String] [y java.lang.Integer]] (str x y)) # 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: 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
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 : >>> 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 The * Art of Computer Programming, Volume 2: Seminumerical * Algorithms, 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: 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 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 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 > > > 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 wrote: > > > > > On Mon, Mar 23, 2009 at 7:34 AM, Rich 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 wrote: > > > > >> On Mon, Mar 23, 2009 at 4:59 AM, Rich 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
2009/3/24 Joshua Fox : >> 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: 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 wrote: > > 2009/3/23 Krešimir Šojat : > > (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/23 Krešimir Šojat : > (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 -~--~~~~--~~--~--~---