Clojure 1.3: Integrating clj-stacktrace?
One of the most common complaints about the current implementation of Clojure is that the stack traces are often unreadable. At work we have been using Mark McGranaghan's clj-stacktrace library[1] to print stack traces, and it does a great job of cleaning them up and making it much clearer as to what the actual cause of the problem is. I've found it invaluable for this--it provides indentation, better details, and even coloring to help make the relevant frames stand out in the noise. I've spoken to him about it, and he is agreeable to the idea of merging it into Clojure. He is the sole author of it, and it sounds like he'd be fine with relicensing and copyright assignment. It appears at first glance to be compatible with the existing clojure.stacktrace library. Obviously before it could be merged we would need to investigate this more thoroughly, but I think it could be a valuable improvement to Clojure 1.3. Thoughts? -Phil [1] - http://github.com/mmcgrana/clj-stacktrace -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Clojure 1.2 and the Computer Language Benchmarks Game
On Aug 24, 7:48 pm, ataggart wrote: > Thanks for focusing solely on one example, and still not providing any > useful, specific information. You asked - "Do I really need to perform the itemCheck math ops in the binary-tree test" - and if you can't see the answer from simply looking at the other programs and the program output, then you need more hand-holding than I'm going to provide. Will it really make a big difference when I add the indefinite article to what it already says in the description? "Each program should ... - walk the tree nodes, checksum node items (and maybe deallocate the node)" > There may be a number of possible implementations for a given design > criterion. The binary-tree "memory allocation/deallocation" test (for > example) includes not only that, but also math ops, in a particular > fashion, a particular style of looping, with particular string > concatenation, and particular places for printing to stdout, etc. Yes. > From what I can infer, the criterion being tested is how well can > clojure code perform when it's written just like the imperative > version in, say, C++. Nonsense. You could as easily say - the criterion being tested is how well can clojure code perform when it's written just like the functional version in, say Clean or Haskell? > I had been assuming this was a serious comparison various languages > performance in achieving a particular design goal. After so many people have contributed programs for binary-trees in so many languages, I had been assuming it was kind-of easy. > Time to move on to something productive. > > On Aug 24, 11:17 am, Isaac Gouy wrote:> On Aug 24, > 9:50 am, ataggart wrote: > > > > It would have been more useful to answer the question (particularly > > > with regards to a canonical implementation) than getting all passive- > > > aggressive. > > > Did you find any programs that didn't perform itemCheck? > > > In Clojure does one integer addition and one integer subtraction per > > node take a significant amount of time? > > > > On Aug 24, 5:55 am, Isaac Gouy wrote: > > > > > On Aug 23, 7:07 pm, ataggart wrote: > > > > > > It's never been clear to me exactly what the code is supposed to be > > > > > do. For example, the "spec" for the binary-tree test is so wholly > > > > > lacking in any details that I'm left to infer that one is supposed to > > > > > copy an implementation used previously, though without any indication > > > > > as to which is the canonical version. Do I really need to perform the > > > > > itemCheck math ops in the binary-tree test which is ostensibly about > > > > > allocating/deallocating memory? Who knows? > > > > > Some people complain - underspecified - and some people complain - > > > > overspecified - and some people just contribute programs. > > > > > Some people complain - forced to write code that isn't idiomatic - as > > > > if there was a canonical version. (Did you find any programs that > > > > didn't perform itemCheck?) > > > > > In Clojure does one integer addition and one integer subtraction per > > > > node take a significant amount of time? Who knows? (I guess you could > > > > measure with/without.) -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Removed Clojure binaries from contrib 'complete' jar
Pardon the silly question, but if it doesn't contain any AOT compiled .class files, then is it a de facto source jar? On Aug 24, 2:56 pm, Stuart Sierra wrote: > I've updated the clojure-contrib build to create the "uberjar" at > modules/complete/target/complete-1.3.0-SNAPSHOT-bin.jar > WITHOUT the Clojure .class build files included. > > This is a binary-only JAR right now. I will look into building a JAR > that includes the clojure-contrib source files. > > -S -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Clojure 1.2 and the Computer Language Benchmarks Game
Thanks for focusing solely on one example, and still not providing any useful, specific information. There may be a number of possible implementations for a given design criterion. The binary-tree "memory allocation/deallocation" test (for example) includes not only that, but also math ops, in a particular fashion, a particular style of looping, with particular string concatenation, and particular places for printing to stdout, etc. >From what I can infer, the criterion being tested is how well can clojure code perform when it's written just like the imperative version in, say, C++. I had been assuming this was a serious comparison various languages performance in achieving a particular design goal. Time to move on to something productive. On Aug 24, 11:17 am, Isaac Gouy wrote: > On Aug 24, 9:50 am, ataggart wrote: > > > It would have been more useful to answer the question (particularly > > with regards to a canonical implementation) than getting all passive- > > aggressive. > > Did you find any programs that didn't perform itemCheck? > > In Clojure does one integer addition and one integer subtraction per > node take a significant amount of time? > > > > > > > On Aug 24, 5:55 am, Isaac Gouy wrote: > > > > On Aug 23, 7:07 pm, ataggart wrote: > > > > > It's never been clear to me exactly what the code is supposed to be > > > > do. For example, the "spec" for the binary-tree test is so wholly > > > > lacking in any details that I'm left to infer that one is supposed to > > > > copy an implementation used previously, though without any indication > > > > as to which is the canonical version. Do I really need to perform the > > > > itemCheck math ops in the binary-tree test which is ostensibly about > > > > allocating/deallocating memory? Who knows? > > > > Some people complain - underspecified - and some people complain - > > > overspecified - and some people just contribute programs. > > > > Some people complain - forced to write code that isn't idiomatic - as > > > if there was a canonical version. (Did you find any programs that > > > didn't perform itemCheck?) > > > > In Clojure does one integer addition and one integer subtraction per > > > node take a significant amount of time? Who knows? (I guess you could > > > measure with/without.) -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: date serialization in clojure-contrib json
I understand the desire to keep the parser clean, but at the same time the ability to register custom data deserializers would be very convenient. Would something like the following help with the performance issue, since if no deserializers were registered there would only be a one time penalty for selecting the object reader? (defn- read-json-reader ([#^PushbackReader stream keywordize? eof-error? eof-value] (loop [i (.read stream) object-reader (if (empty? @*deserializers*) read-json- object read-json-object-and-deserialize)] On Aug 24, 6:51 pm, Stuart Sierra wrote: > On Aug 23, 9:03 pm, Dmitri wrote: > > > Would there be an issue with adding something like that to the > > contrib? > > I don't want to add anything that impacts performance in the plain > parsing case. > > -S -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Los Angeles Clojure users group
Lance Bradley (lancepantz) and I are interested in getting an LA area Clojure group started, so we started a Google group (http:// groups.google.com/group/clj-la). If you're in the Los Angeles area, please join the group so we can talk about setting up a first meeting. Or go to the irc channel: #clj- la on irc.freenode.net Cheers, Justin -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: date serialization in clojure-contrib json
On Aug 23, 9:03 pm, Dmitri wrote: > Would there be an issue with adding something like that to the > contrib? I don't want to add anything that impacts performance in the plain parsing case. -S -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Removed Clojure binaries from contrib 'complete' jar
I've updated the clojure-contrib build to create the "uberjar" at modules/complete/target/complete-1.3.0-SNAPSHOT-bin.jar WITHOUT the Clojure .class build files included. This is a binary-only JAR right now. I will look into building a JAR that includes the clojure-contrib source files. -S -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Clojure 1.2 and the Computer Language Benchmarks Game
On Aug 24, 9:50 am, ataggart wrote: > It would have been more useful to answer the question (particularly > with regards to a canonical implementation) than getting all passive- > aggressive. Did you find any programs that didn't perform itemCheck? In Clojure does one integer addition and one integer subtraction per node take a significant amount of time? > > On Aug 24, 5:55 am, Isaac Gouy wrote: > > > On Aug 23, 7:07 pm, ataggart wrote: > > > > It's never been clear to me exactly what the code is supposed to be > > > do. For example, the "spec" for the binary-tree test is so wholly > > > lacking in any details that I'm left to infer that one is supposed to > > > copy an implementation used previously, though without any indication > > > as to which is the canonical version. Do I really need to perform the > > > itemCheck math ops in the binary-tree test which is ostensibly about > > > allocating/deallocating memory? Who knows? > > > Some people complain - underspecified - and some people complain - > > overspecified - and some people just contribute programs. > > > Some people complain - forced to write code that isn't idiomatic - as > > if there was a canonical version. (Did you find any programs that > > didn't perform itemCheck?) > > > In Clojure does one integer addition and one integer subtraction per > > node take a significant amount of time? Who knows? (I guess you could > > measure with/without.) -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Clojure 1.2 and the Computer Language Benchmarks Game
On Aug 24, 9:58 am, Nicolas Oury wrote: > On Tue, Aug 24, 2010 at 5:33 PM, Isaac Gouy wrote: > > > Well when Clojure 1.3 is released... > > > The phrase "idiomatic code" often seems to be used to mean - code > > written in a natural way for that language and as if performance > > doesn't matter - whereas I seem to have the strange notion that both > > code written as if performance matters and code written as if > > performance doesn't matter can be "idiomatic code". > > For most of the code, being slower (in a reasonable limit) is not > important if you are correct and easily maintable, and reusable. When it doesn't matter it doesn't matter but when it matters it matters. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Clojure 1.2 and the Computer Language Benchmarks Game
On Tue, Aug 24, 2010 at 5:33 PM, Isaac Gouy wrote: > > Well when Clojure 1.3 is released... > > The phrase "idiomatic code" often seems to be used to mean - code > written in a natural way for that language and as if performance > doesn't matter - whereas I seem to have the strange notion that both > code written as if performance matters and code written as if > performance doesn't matter can be "idiomatic code". For most of the code, being slower (in a reasonable limit) is not important if you are correct and easily maintable, and reusable. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Clojure 1.2 and the Computer Language Benchmarks Game
>>> Clojure 1.3's performance improvements will significantly impact perf on >>> some of the benchmarks. If you are trying these out, please try them on >>> both 1.2 and 1.3. >> >> >> Has Clojure 1.3 been released? >> > > No, but since the num/prim/equiv work specifically targets performance, we > want to collect people's experiences comparing 1.2 and 1.3. This is totally > separate from the benchmark submission process and for our own information. > I have a project that is development and will still be for some time. I don't mind if it does not work perfectly before 1.3 and I will be very happy to have it very fast when 1.3 is ready. I am quite happy to make a branch to check improvement vs 1.2, but I wouldn't know how to change my code to benefit from the features of 1.3. Is there some links about that? Are the prim/equiv work in master yet? And the :static defn with primitives arg? And the protocols with primitive? Are there other improvements? I have a lot of primitives that are spread in a big part of the code, so I think I would benefit from that? Best, Nicolas. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Clojure 1.2 and the Computer Language Benchmarks Game
It would have been more useful to answer the question (particularly with regards to a canonical implementation) than getting all passive- aggressive. On Aug 24, 5:55 am, Isaac Gouy wrote: > On Aug 23, 7:07 pm, ataggart wrote: > > > It's never been clear to me exactly what the code is supposed to be > > do. For example, the "spec" for the binary-tree test is so wholly > > lacking in any details that I'm left to infer that one is supposed to > > copy an implementation used previously, though without any indication > > as to which is the canonical version. Do I really need to perform the > > itemCheck math ops in the binary-tree test which is ostensibly about > > allocating/deallocating memory? Who knows? > > Some people complain - underspecified - and some people complain - > overspecified - and some people just contribute programs. > > Some people complain - forced to write code that isn't idiomatic - as > if there was a canonical version. (Did you find any programs that > didn't perform itemCheck?) > > In Clojure does one integer addition and one integer subtraction per > node take a significant amount of time? Who knows? (I guess you could > measure with/without.) -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Clojure 1.2 and the Computer Language Benchmarks Game
On Tue, Aug 24, 2010 at 12:33 PM, Isaac Gouy wrote: > The phrase "idiomatic code" often seems to be used to mean - code > written in a natural way for that language and as if performance > doesn't matter - whereas I seem to have the strange notion that both > code written as if performance matters and code written as if > performance doesn't matter can be "idiomatic code". > Idiomatic Clojure is plenty fast, faster than most of the other dynamic langs. But Clojure can get identical to pure Java perf and that may or may not look idiomatic depending on what you are doing. David -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Clojure 1.2 and the Computer Language Benchmarks Game
On Aug 24, 8:48 am, Stuart Halloway wrote: > > On Aug 24, 6:44 am, Stuart Halloway wrote: > >> Clojure 1.3's performance improvements will significantly impact perf on > >> some of the benchmarks. If you are trying these out, please try them on > >> both 1.2 and 1.3. > > > Has Clojure 1.3 been released? > > No, but since the num/prim/equiv work specifically targets performance, we > want to collect people's experiences comparing 1.2 and 1.3. This is totally > separate from the benchmark submission process and for our own information. > > >> Also: the benchmarks are totally a numbers game: throw idioms and > >> readability out the window. Clojure 1.3 should be able to match Java > >> performance if you basically write Java-in-Clojure. On Clojure 1.2 you > >> will have to do stranger things to get there. > > > If you choose to throw idioms and readability out the window then > > don't be surprised at the comments that will be made about Clojure. > > Let me reduce the stridency of my previous statement: "throwing things out > the window" is too strong. Benchmarks are a numbers contest, not a beauty > contest. But, there's no saying the resulting programs will be ugly (or even > non-idiomatic). Try things. Measure. It is simply the case that some > idiomatic code (i.e. numeric code with no hints in the body) is faster in > master/1.3 than in 1.2, and that some benchmark-useful things (fns > taking/returning primitives) are available only post 1.2. Well when Clojure 1.3 is released... The phrase "idiomatic code" often seems to be used to mean - code written in a natural way for that language and as if performance doesn't matter - whereas I seem to have the strange notion that both code written as if performance matters and code written as if performance doesn't matter can be "idiomatic code". http://shootout.alioth.debian.org/u32q/program.php?test=spectralnorm&lang=ghc&id=2 http://shootout.alioth.debian.org/u32q/program.php?test=spectralnorm&lang=ghc&id=4 > > If you have to "do stranger things to get there" with Clojure 1.2 then > > doesn't that simply suggest Clojure 1.2 performance doesn't match Java > > performance? > > If I had wanted to suggest that, I would have said "you can't get there". > With Clojure 1.2, you can get fast programs easily, or screaming-fast > programs with effort. Some of the work in Clojure 1.3 reduces that effort. > > Stu -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Clojure 1.2 and the Computer Language Benchmarks Game
> On Aug 24, 6:44 am, Stuart Halloway wrote: >> Clojure 1.3's performance improvements will significantly impact perf on >> some of the benchmarks. If you are trying these out, please try them on both >> 1.2 and 1.3. > > > Has Clojure 1.3 been released? > No, but since the num/prim/equiv work specifically targets performance, we want to collect people's experiences comparing 1.2 and 1.3. This is totally separate from the benchmark submission process and for our own information. >> Also: the benchmarks are totally a numbers game: throw idioms and >> readability out the window. Clojure 1.3 should be able to match Java >> performance if you basically write Java-in-Clojure. On Clojure 1.2 you will >> have to do stranger things to get there. > > If you choose to throw idioms and readability out the window then > don't be surprised at the comments that will be made about Clojure. Let me reduce the stridency of my previous statement: "throwing things out the window" is too strong. Benchmarks are a numbers contest, not a beauty contest. But, there's no saying the resulting programs will be ugly (or even non-idiomatic). Try things. Measure. It is simply the case that some idiomatic code (i.e. numeric code with no hints in the body) is faster in master/1.3 than in 1.2, and that some benchmark-useful things (fns taking/returning primitives) are available only post 1.2. > If you have to "do stranger things to get there" with Clojure 1.2 then > doesn't that simply suggest Clojure 1.2 performance doesn't match Java > performance? If I had wanted to suggest that, I would have said "you can't get there". With Clojure 1.2, you can get fast programs easily, or screaming-fast programs with effort. Some of the work in Clojure 1.3 reduces that effort. Stu -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: cool compiler-project?
@Daniel Glauser records and protocols are an effort to provide very fast solution to problems that where to slow in Clojure to write Clojure-in-Clojuer and the the same speed as Clojure-in-Java. This is an effort to make clojure faster and by this allowing Clojure- in-Clojure. I don't think Rich only wanted Clojure-in-Clojure and had to make Clojure faster for that he just wants Clojure to be fast. @Sreeraj a I don't know if it is difficult enough but a real help for the community would be to implement better error messages in the compiler. On Aug 24, 2:28 am, Daniel Glauser wrote: > I thought that much of the driver behind protocols and records were to > support the Clojure-in-Clojure effort. > Can anyone confirm? > > Thanks, > Daniel > > On Aug 23, 3:59 am, nickikt wrote: > > > > > I think he talkes about automatic detection where memoization would be > > good for performence. I don't think it is done ATM but I would surly > > be a intressting topic. > > > The Clojure compiler is still in Java. I think befor someone does a > > big project with the compiler it should be translated to clojure. I > > think Rich said once that the compiler is about 5000 lines so its not > > an imposibly hard task. > > > On Aug 23, 9:01 am, Moritz Ulrich > > wrote: > > > > Memoization is implemented at language-leve. The function is called > > > memoize. > > > (It's a three-liner or so) > > > > On Sun, Aug 22, 2010 at 11:45 PM, Sreeraj a wrote: > > > > What about automatic memoization? > > > > Does clojure already implement memoization? > > > > is adding auto memoization to the compiler a good idea? > > > > > -- > > > > You received this message because you are subscribed to the Google > > > > Groups "Clojure" group. > > > > To post to this group, send email to clojure@googlegroups.com > > > > Note that posts from new members are moderated - please be patient with > > > > your > > > > first post. > > > > To unsubscribe from this group, send email to > > > > clojure+unsubscr...@googlegroups.com > > > > For more options, visit this group at > > > >http://groups.google.com/group/clojure?hl=en > > > > -- > > > Moritz Ulrich > > > Programmer, Student, Almost normal Guy > > > >http://www.google.com/profiles/ulrich.moritz > > > BB5F086F-C798-41D5-B742-494C1E9677E8 -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Clojure 1.2 and the Computer Language Benchmarks Game
On Tue, Aug 24, 2010 at 10:30 AM, Isaac Gouy wrote: > Has Clojure 1.3 been released? > Nope. > If you choose to throw idioms and readability out the window then > don't be surprised at the comments that will be made about Clojure. > Clojure doesn't encourage mutable state. Most of the benchmarks do. Mutable Clojure will probably always look fairly unidiomatic. > If you have to "do stranger things to get there" with Clojure 1.2 then > doesn't that simply suggest Clojure 1.2 performance doesn't match Java > performance? No. David -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Blocked read on a thread of execution
Thar she blows. This works: * **(let [agt (agent nil)] * * * * **(send-off agt * * **(fn [] (println "FINAL > " * * **(with-out-str (**some-function-that-blocks-on-read*** * **nil* * **) * * **)* * * * **(println "foobar")* Danke Schon Tim On Tue, Aug 24, 2010 at 10:17 AM, Mark Rathwell wrote: > > It's not send and send-off that are blocking, it is your (println > "Final"... send expects a function, so it is waiting for "(println..." to > return some function to apply to the agent. > > > On Tue, Aug 24, 2010 at 9:16 AM, Timothy Washington wrote: > >> Ok, I have a dumb question here. Using Clojure's concurrency semantics, >> I'm trying to see how to spawn a thread that runs and blocks on input from >> the standard-in. Vars, atoms, agents and refs all seem to deal with >> coordinated / uncoordinated access to blocks of data. >> >> I need i) to call a function (in a thread) that runs and blocks on >> standard input. Then ii) run a thread that spits data to the standard in. I >> tried create an agent with nil data, then sending an update function to the >> agent; but no dice. >> >> *(let [agt (agent nil)] * >> * (send agt ** **;; both send and send-off still block execution - >> (println "foobar") never gets called * >> *(println "FINAL > " * >> * (with-out-str (some-function-that-blocks-on-read )))* >> *nil * >> * ) * >> *)* >> * * >> *(println "foobar") * >> >> >> I want to avoid using Java threads if at all possible. >> >> Hmmm >> Tim >> >> -- >> You received this message because you are subscribed to the Google >> Groups "Clojure" group. >> To post to this group, send email to clojure@googlegroups.com >> Note that posts from new members are moderated - please be patient with >> your first post. >> To unsubscribe from this group, send email to >> clojure+unsubscr...@googlegroups.com >> For more options, visit this group at >> http://groups.google.com/group/clojure?hl=en >> > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: What is the best way to parasitically invade a java project with clojure goodness?
On Mon, Aug 23, 2010 at 8:41 PM, Seth wrote: > Going from Java to Clojure isn't quite as easy as going the other way, > as @brweber2 demonstrated at the local Clojure meetup. Here's the code > he used in the presentation, might send him a direct message on > Twitter for more info: > > http://github.com/brweber2/javacallclj > > On a related note, there is a nice library for calling clojure from Groovy. The library relies on dynamic dispatch so you can't call it directly from Java. Right now the library is part of the Grails Clojure plugin. I will soon pull that apart so the library may be used from any project, not just a Grails app. A screencast showing the original 0.1 release of the plugin is at http://s3.amazonaws.com/jeffscreencasts/grails_clojure_demo.mov and more details about the plugin are at http://grails.org/plugin/clojure. jb -- Jeff Brown SpringSource http://www.springsource.com/ Autism Strikes 1 in 166 Find The Cause ~ Find The Cure http://www.autismspeaks.org/ -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Clojure 1.2 and the Computer Language Benchmarks Game
On Aug 24, 6:44 am, Stuart Halloway wrote: > Clojure 1.3's performance improvements will significantly impact perf on some > of the benchmarks. If you are trying these out, please try them on both 1.2 > and 1.3. Has Clojure 1.3 been released? > Also: the benchmarks are totally a numbers game: throw idioms and readability > out the window. Clojure 1.3 should be able to match Java performance if you > basically write Java-in-Clojure. On Clojure 1.2 you will have to do stranger > things to get there. If you choose to throw idioms and readability out the window then don't be surprised at the comments that will be made about Clojure. If you have to "do stranger things to get there" with Clojure 1.2 then doesn't that simply suggest Clojure 1.2 performance doesn't match Java performance? -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Blocked read on a thread of execution
It's not send and send-off that are blocking, it is your (println "Final"... send expects a function, so it is waiting for "(println..." to return some function to apply to the agent. On Tue, Aug 24, 2010 at 9:16 AM, Timothy Washington wrote: > Ok, I have a dumb question here. Using Clojure's concurrency semantics, I'm > trying to see how to spawn a thread that runs and blocks on input from the > standard-in. Vars, atoms, agents and refs all seem to deal with coordinated > / uncoordinated access to blocks of data. > > I need i) to call a function (in a thread) that runs and blocks on standard > input. Then ii) run a thread that spits data to the standard in. I tried > create an agent with nil data, then sending an update function to the agent; > but no dice. > > *(let [agt (agent nil)] * > * (send agt ** **;; both send and send-off still block execution - > (println "foobar") never gets called * > *(println "FINAL > " * > * (with-out-str (some-function-that-blocks-on-read )))* > *nil * > * ) * > *)* > * * > *(println "foobar") * > > > I want to avoid using Java threads if at all possible. > > Hmmm > Tim > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: cool compiler-project?
On Aug 18, 7:35 am, Sreeraj a wrote: > Hi, > I am a post-grad student looking for a cool compiler - project to do. > I am getting comfortable with clojure and would really like to help > > Ideas anyone? > or, Is there a to-do list where can i start? > > Cheers > Sreeraj An idea: Use knowledge of the program and environment to emit warnings/notes about potential problems in the code, like calling foo with three arguments when it is currently defined to take one (see SBCL for inspiration). -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Clojure 1.2 and the Computer Language Benchmarks Game
Clojure 1.3's performance improvements will significantly impact perf on some of the benchmarks. If you are trying these out, please try them on both 1.2 and 1.3. Also: the benchmarks are totally a numbers game: throw idioms and readability out the window. Clojure 1.3 should be able to match Java performance if you basically write Java-in-Clojure. On Clojure 1.2 you will have to do stranger things to get there. Stu > Now Clojure 1.2 has been released, Clojure programs will be included > in the Computer Language Benchmarks Game. > > If you'd like to contribute Clojure programs, please follow the step- > by-step > > http://shootout.alioth.debian.org/help.php#contribute > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Clojure 1.2 and the Computer Language Benchmarks Game
On Aug 23, 7:35 pm, Robert McIntyre wrote: > I hear you --- I got excited about this too, and implemented the fannuchredux > algorithm, only to be thwarted by an undocumented "checksum" each > program is also > supposed to calculate. This checksum depends heavily on the exact > order in which > a set of permutations are traversed. And of course, they aren't > traversed in lexical order, > but whatever order the original implementation used. By design - "This checksum depends heavily on the exact order in which a set of permutations are traversed." - people kept finding ways to not generate some of the permutations or used faster algorithms to generate the permutations - so fannkuch-redux now allows little flexibility. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Blocked read on a thread of execution
Ok, I have a dumb question here. Using Clojure's concurrency semantics, I'm trying to see how to spawn a thread that runs and blocks on input from the standard-in. Vars, atoms, agents and refs all seem to deal with coordinated / uncoordinated access to blocks of data. I need i) to call a function (in a thread) that runs and blocks on standard input. Then ii) run a thread that spits data to the standard in. I tried create an agent with nil data, then sending an update function to the agent; but no dice. *(let [agt (agent nil)] * * (send agt ** **;; both send and send-off still block execution - (println "foobar") never gets called * *(println "FINAL > " * * (with-out-str (some-function-that-blocks-on-read )))* *nil * * ) * *)* * * *(println "foobar") * I want to avoid using Java threads if at all possible. Hmmm Tim -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Clojure 1.2 and the Computer Language Benchmarks Game
On Aug 23, 7:07 pm, ataggart wrote: > It's never been clear to me exactly what the code is supposed to be > do. For example, the "spec" for the binary-tree test is so wholly > lacking in any details that I'm left to infer that one is supposed to > copy an implementation used previously, though without any indication > as to which is the canonical version. Do I really need to perform the > itemCheck math ops in the binary-tree test which is ostensibly about > allocating/deallocating memory? Who knows? Some people complain - underspecified - and some people complain - overspecified - and some people just contribute programs. Some people complain - forced to write code that isn't idiomatic - as if there was a canonical version. (Did you find any programs that didn't perform itemCheck?) In Clojure does one integer addition and one integer subtraction per node take a significant amount of time? Who knows? (I guess you could measure with/without.) -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
