Re: complex number library
2010/12/16 Sunil S Nandihalli > double-dispatch in clojure .. thats neat... Thanks Stuart. Really, that's "double-dispatch with protocols", 'cause double-triple-whatever-dispatch on anything you know 'bout the function arguments is solved since the introduction of multimethods. Cheers, -- Laurent > Sunil. > > > On Wed, Dec 15, 2010 at 12:17 AM, Stuart Sierra < > the.stuart.sie...@gmail.com> wrote: > >> On Dec 14, 2:31 am, Konrad Hinsen wrote: >> > That's actually what clojure.contrib.complex-numbers already uses! And >> > it's based on multimethods, not protocols, because of all those binary >> > operations. >> >> It is possible, though not trivial, to do 2-argument dispatch with >> protocols. See http://paste.lisp.org/+2023 for an example. I have no >> idea how well this performs compared to multimethods. >> >> -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 >> 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: Looking for a better way
Indeed ! I was stuck in the macro thinking, thanks for getting us out of it ! And then this solution not only works for literal strings: user=> (foo (str "yo" "man")) #'user/yoman user=> yoman "yoman" user=> 2010/12/16 Robert McIntyre > no need to use macros at all: > > (defn foo > "creates a symbol named s with the value s in the current namespace " > [s] > (intern *ns* (symbol s) s)) > > that is, assuming I got the use case right. > > --Robert McIntyre > > > On Wed, Dec 15, 2010 at 8:00 AM, Laurent PETIT > wrote: > > 2010/12/15 Emeka > >> > >> Helllo All, > >> Is there a better way of doing this? > >> (defmacro foo [string] (let[b# string f# (symbol b#)] `(def ~f# ~b#))) > > > > Hello, > > > > What is it supposed to be used ? > > > > What do you expect the macroexpansion to look like ? > > > > As is stands, your example can go without the ending #'s since they > aren't > > declared inside the returned quoted expr. They're useless. > > > > So having > > > > (defmacro foo [string] (let [b string f (symbol string)] `(def ~f ~b))) > > > > But now, string is not (as you may think) evaluated within the let in the > > macro. string is just an immutable datastructure containing "as is" what > has > > been passed to foo. So if what you pass to foo is something which > > "evaluates" to a string, for example a string concatenation expression as > > (str "the-" "value"), then the code will not do what it suggests it's > doing > > : > > > > user=> (defmacro foo [string] (let[b# string f# (symbol b#)] `(def ~f# > > ~b#))) > > #'user/foo > > user=> (foo (str "the-" "value")) > > java.lang.ClassCastException: clojure.lang.PersistentList cannot be cast > to > > java.lang.String (NO_SOURCE_FILE:0) > > user=> (macroexpand '(foo (str "the-" "value"))) > > java.lang.ClassCastException: clojure.lang.PersistentList cannot be cast > to > > java.lang.String (NO_SOURCE_FILE:0) > > user=> > > > > > > Now, if you just want the macro to take literal strings as input, then > the > > code can be further simplified to : > > > > (defmacro foo [string] `(def ~(symbol string) ~string)) > > > > user=> (defmacro foo [string] `(def ~(symbol string) ~string)) > > #'user/foo > > user=> (foo "the-string") > > #'user/the-string > > user=> the-string > > "the-string" > > user=> (macroexpand '(foo "the-string")) > > (def the-string "the-string") > > user=> > > > > HTH, > > > > -- > > Laurent > > > > -- > > You 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: complex number library
my bad .. thats what I meant..:) On Thu, Dec 16, 2010 at 2:10 PM, Laurent PETIT wrote: > 2010/12/16 Sunil S Nandihalli > > double-dispatch in clojure .. thats neat... Thanks Stuart. > > > Really, that's "double-dispatch with protocols", 'cause > double-triple-whatever-dispatch on anything you know 'bout the function > arguments is solved since the introduction of multimethods. > > Cheers, > > -- > Laurent > > >> Sunil. >> >> >> On Wed, Dec 15, 2010 at 12:17 AM, Stuart Sierra < >> the.stuart.sie...@gmail.com> wrote: >> >>> On Dec 14, 2:31 am, Konrad Hinsen wrote: >>> > That's actually what clojure.contrib.complex-numbers already uses! And >>> >>> > it's based on multimethods, not protocols, because of all those binary >>> >>> > operations. >>> >>> It is possible, though not trivial, to do 2-argument dispatch with >>> protocols. See http://paste.lisp.org/+2023 for an example. I have no >>> idea how well this performs compared to multimethods. >>> >>> -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 >>> 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 > -- You 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: Catching ClassNotFoundException.
Hi, Am 16.12.2010 um 04:16 schrieb Nicolas Buduroi: > So we could always use RT/classForName to detect what classes are > available. Do you think the extend-type thrown exception can possibly > be fixed or is it a fundamental limitation? I think the problem here is „when“ not „where.“ The „extend-type“ exception is thrown when the expression is compiled because the compiler tries to resolve the class. But the try catch is not in effect at that time: it just gets compiled! Using RT/classForName moves the class resolution to the runtime and everything works fine. You could do something like (try (load "file/with/extend-type") (catch ClassNotFoundException uhOh ...)). Sincerely Meikel -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Looking for a better way
Laurent and Robert, Thank you all. On Thu, Dec 16, 2010 at 9:44 AM, Laurent PETIT wrote: > Indeed ! > > I was stuck in the macro thinking, thanks for getting us out of it ! > > And then this solution not only works for literal strings: > > user=> (foo (str "yo" "man")) > #'user/yoman > user=> yoman > "yoman" > user=> > > 2010/12/16 Robert McIntyre > > no need to use macros at all: >> >> (defn foo >> "creates a symbol named s with the value s in the current namespace " >> [s] >> (intern *ns* (symbol s) s)) >> >> that is, assuming I got the use case right. >> >> --Robert McIntyre >> >> >> On Wed, Dec 15, 2010 at 8:00 AM, Laurent PETIT >> wrote: >> > 2010/12/15 Emeka >> >> >> >> Helllo All, >> >> Is there a better way of doing this? >> >> (defmacro foo [string] (let[b# string f# (symbol b#)] `(def ~f# ~b#))) >> > >> > Hello, >> > >> > What is it supposed to be used ? >> > >> > What do you expect the macroexpansion to look like ? >> > >> > As is stands, your example can go without the ending #'s since they >> aren't >> > declared inside the returned quoted expr. They're useless. >> > >> > So having >> > >> > (defmacro foo [string] (let [b string f (symbol string)] `(def ~f ~b))) >> > >> > But now, string is not (as you may think) evaluated within the let in >> the >> > macro. string is just an immutable datastructure containing "as is" what >> has >> > been passed to foo. So if what you pass to foo is something which >> > "evaluates" to a string, for example a string concatenation expression >> as >> > (str "the-" "value"), then the code will not do what it suggests it's >> doing >> > : >> > >> > user=> (defmacro foo [string] (let[b# string f# (symbol b#)] `(def ~f# >> > ~b#))) >> > #'user/foo >> > user=> (foo (str "the-" "value")) >> > java.lang.ClassCastException: clojure.lang.PersistentList cannot be cast >> to >> > java.lang.String (NO_SOURCE_FILE:0) >> > user=> (macroexpand '(foo (str "the-" "value"))) >> > java.lang.ClassCastException: clojure.lang.PersistentList cannot be cast >> to >> > java.lang.String (NO_SOURCE_FILE:0) >> > user=> >> > >> > >> > Now, if you just want the macro to take literal strings as input, then >> the >> > code can be further simplified to : >> > >> > (defmacro foo [string] `(def ~(symbol string) ~string)) >> > >> > user=> (defmacro foo [string] `(def ~(symbol string) ~string)) >> > #'user/foo >> > user=> (foo "the-string") >> > #'user/the-string >> > user=> the-string >> > "the-string" >> > user=> (macroexpand '(foo "the-string")) >> > (def the-string "the-string") >> > user=> >> > >> > HTH, >> > >> > -- >> > Laurent >> > >> > -- >> > You 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 > -- *Satajanus Nig. Ltd * -- You 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.3 Alpha 4
> Worse, from the sounds of it the new + isn't exactly the old > unchecked-+; it still checks for overflow rather than allowing > wrapping. That's going to add a compare-and-branch to every add > instruction and halve the speed of those operators on typical > hardware. Compare-and-throw-exception is hardly superior to > compare-and-box-in-BigInteger, since it's still slow AND now some > arithmetic code that used to work but be slow will now explode in your > face. This argument is based on the (provably wrong) presumption that "still slow" means "equally slow". The difference is percentage points vs. order of magnitude. Test it for yourself. The Clojure/core team has an action item to pull the docs on the numeric stuff into one place so that it is easier to point people to a single location and prevent rehashing old issues. Until that is done, if you want to continue this thread, please make arguments that back up notions like "slow" or "fast" or "broken" with evidence from real code. 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.3 Alpha 4
> On Tue, Dec 14, 2010 at 9:56 PM, David Nolen wrote: >> On Tue, Dec 14, 2010 at 9:04 PM, Ken Wesson wrote: >>> >>> On Tue, Dec 14, 2010 at 8:23 PM, Benny Tsai wrote: As Brian said, primitive math is now the default in 1.3. If auto- promotion on overflow is desired, you can use the +', -', *', inc', dec' functions (note the single quote suffix). >>> >>> Why was this done? I preferred having +, -, etc. DTRT in general and >>> unchecked-+, etc. for when you really needed efficient primitive math. >>> My code is littered with + but has few unchecked-+s. Which means I'll >>> have to go through it all adding little tick-marks everywhere and >>> making the math look funny to keep its behavior the same whenever 1.3 >>> is released. >> >> For quite a few good reasons, the most important being that it makes Rich >> Hickey's life a lot easier, and ours as well as a result of that. > > Breaking source compatibility with just about every single preexisting > line of Clojure code out there is supposed to make our lives *easier*? > I'd dearly love to know how -- my cousin is a stage magician and he's > always on the lookout for new tricks, so this would make a nearly > perfect Christmas present for him. :) We are aware that this is a breaking change. :-) In addition to talking on IRC and the mailing list, we checked dozens of Clojure libraries (code review and test suite) and found *minimal* breakage. If anyone has different empirical evidence to offer, please do so. 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.3 Alpha 4
> In practice, I haven't seen a significant speed improvement in the new branch > of Clojure (except on specific benchmarks that intentionally test Clojure's > new default primitive math). In my day-to-day code, all my numbers, despite > being perfectly small enough to fit in a long, end up getting stored and > retrieved from Clojure's various data structures - vectors, maps, sets, etc. > and thus lose their primitiveness. So I presumably haven't seen any speed > improvement because all the numbers are boxed by the time I do math on them. > Fortunately, I also don't seem to run into arithmetic overflows because my > production code isn't particularly math intensive, but I still end up feeling > stressed out trying to convince myself that it can't ever overflow for any > input. Mark nails it. The interesting thing about the numeric change in 1.3 is that a great deal of application code is unaffected in *either* direction! That is, (1) It isn't a lot faster. (2) Very little breaks. -- You 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
MethodHandles and the future
Hi all, Are there any plans to move in the direction John Rose is talking about here? I guess the timeframe would depend on when this tech makes it into production branches, but is it on the radar at least? http://blogs.sun.com/jrose/entry/scheme_in_one_class Regards, Robbie -- You 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: unquote
In general you should prefer doseq because it doesn't hold on to the head, correct? Sent from my iPhone On Dec 15, 2010, at 5:14 PM, Meikel Brandmeyer wrote: > Hi, > > Am 15.12.2010 um 19:54 schrieb Brian Marick: > >> (See also #'dorun.) > > Argh. See also doseq. > > Sincerely > Meikel > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en -- You 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: unquote
Hi, Am 16.12.2010 um 14:50 schrieb Jay Fields: > In general you should prefer doseq because it doesn't hold on to the head, > correct? dorun does the same. But it constructs a lazy sequence of return values which is thrown away immediately. This is very ugly and wasteful. Doing some microbenchmarking one might even see, that doseq is a little faster than (dorun (map ...)). But that isn't maybe not the main issue. Maybe this is just philosophical. Sincerely Meikel -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: MethodHandles and the future
Certainly on the radar. But not usable until it's available in the majority of production JDKs out there. Java moves slowly; even Clojure's dependence on 1.5 has been a blocker for some folks. -Stuart Sierra clojure.com -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Midje: a different slant on clojure testing
Thank you for sharing Midje with us. I too would like to hear how it relates to clojure.test. -- You 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: Midje: a different slant on clojure testing
On Dec 16, 2010, at 12:21 AM, Shantanu Kumar wrote:
> 1. Is there any example app that demonstrates how to use Midje?
The introduction to the basic feature set is here:
https://github.com/marick/Midje/blob/master/examples/sweet-examples/basic/test/basic/core_test.clj
As a simple example, I converted the tests from Mark McGranaghan's sample
compojure app from clojure.test to midje. The converted app is here:
https://github.com/marick/Midje/tree/master/examples/sweet-examples/adder-webapp
To compare the sets of tests, look in these two places:
https://github.com/mmcgrana/adder/blob/master/test/adder/core_test.clj
https://github.com/marick/Midje/blob/master/examples/sweet-examples/adder-webapp/test/adder/core_test.clj
(Looking at my example, I see the treatment of helper functions is out of date.
I'll go and update it.)
> 2. Why would I use Midje instead of clojure.test? (Perhaps you can
> also blog about it with an example using clojure.test and Midje.)
Midje supports top-down development, whereas clojure.test doesn't. I have a
three-part example of top-down development here:
http://www.exampler.com/blog/2010/06/10/tdd-in-clojure-a-sketch-part-1/
(Note the example predates Midje. The "shape" of the code samples is the same
(arrows, placeholders with names like ...cell...), but names have changed.
"know" is now called "fact", etc.)
I think Midje syntax is more readable because it matches the way we're used to
seeing examples of code: the code, then some delimiter, then the results. Look
at the examples in /Programming Clojure/. From p. 50:
(into [] (take 5 (iterate dec 5)))
=> [5 4 3 2 1]
(As I've been converting my tests from clojure.test to Midje, I've also noticed
that they become terser.)
I find the test failures easier to interpret, especially when I use "chatty
checkers" (which was inspired by Phlip's assert{2.0} for Ruby
http://www.oreillynet.com/ruby/blog/2008/02/assert2.html)
-
Brian Marick, Artisanal Labrador
Contract programming in Ruby and Clojure
Author of /Ring/ (forthcoming; sample: http://bit.ly/hfdf9T)
www.exampler.com, www.exampler.com/blog, www.twitter.com/marick
--
You 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: Catching ClassNotFoundException.
Cool, that explain everything. Thanks On Dec 16, 4:40 am, Meikel Brandmeyer wrote: > Hi, > > Am 16.12.2010 um 04:16 schrieb Nicolas Buduroi: > > > So we could always use RT/classForName to detect what classes are > > available. Do you think the extend-type thrown exception can possibly > > be fixed or is it a fundamental limitation? > > I think the problem here is „when“ not „where.“ The „extend-type“ exception > is thrown when the expression is compiled because the compiler tries to > resolve the class. But the try catch is not in effect at that time: it just > gets compiled! Using RT/classForName moves the class resolution to the > runtime and everything works fine. > > You could do something like (try (load "file/with/extend-type") (catch > ClassNotFoundException uhOh ...)). > > Sincerely > Meikel -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Clojure 1.3 Alpha 4
On Thu, Dec 16, 2010 at 8:13 AM, Stuart Halloway wrote: >> Worse, from the sounds of it the new + isn't exactly the old >> unchecked-+; it still checks for overflow rather than allowing >> wrapping. That's going to add a compare-and-branch to every add >> instruction and halve the speed of those operators on typical >> hardware. Compare-and-throw-exception is hardly superior to >> compare-and-box-in-BigInteger, since it's still slow AND now some >> arithmetic code that used to work but be slow will now explode in your >> face. > > This argument is based on the (provably wrong) presumption that "still slow" > means "equally slow". The difference is percentage points vs. order of > magnitude. Test it for yourself. That does not make sense, since the implementations in both cases have to test for overflow and branch. In the "overflowed" branch further expensive actions are taken -- in both cases the creation of a Java object, for instance (an exception or a boxed numeric). These branches might differ in other ways in speed, but they're the rare case. The common case is test and accept the result, returning it, in both cases; so the common case should have comparable execution speed given both implementations. If not, something is wrong someplace else with at least one of the implementations (or, much less likely, with the JVM/JIT). > Until that is done, if you want to continue this thread, please make > arguments that back up notions like "slow" or "fast" or "broken" with > evidence from real code. As for "broken", you can't honestly think changing the semantics of the + operator, after years of code written in Clojure has accumulated, won't break *something*. Surely. Most likely many somethings, scattered all over the place. -- You 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.3 Alpha 4
On Thu, Dec 16, 2010 at 8:17 AM, Stuart Halloway wrote: > I wrote: >> Breaking source compatibility with just about every single preexisting >> line of Clojure code out there is supposed to make our lives *easier*? >> I'd dearly love to know how -- my cousin is a stage magician and he's >> always on the lookout for new tricks, so this would make a nearly >> perfect Christmas present for him. :) > > We are aware that this is a breaking change. :-) > > In addition to talking on IRC and the mailing list, we checked dozens of > Clojure libraries (code review and test suite) and found *minimal* breakage. > If anyone has different empirical evidence to offer, please do so. Define "minimal". -- You 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.3 Alpha 4
> The > common case is test and accept the result, returning it, in both > cases; so the common case should have comparable execution speed given > both implementations. If not, something is wrong someplace else with > at least one of the implementations (or, much less likely, with the > JVM/JIT). > I am not a specialist but, if I understood well, the new implementation does not box the result, which is a *significant* speed up. -- You 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.3 Alpha 4
On Thu, Dec 16, 2010 at 11:18 AM, Ken Wesson wrote: > On Thu, Dec 16, 2010 at 8:13 AM, Stuart Halloway > wrote: > >> Worse, from the sounds of it the new + isn't exactly the old > >> unchecked-+; it still checks for overflow rather than allowing > >> wrapping. That's going to add a compare-and-branch to every add > >> instruction and halve the speed of those operators on typical > >> hardware. Compare-and-throw-exception is hardly superior to > >> compare-and-box-in-BigInteger, since it's still slow AND now some > >> arithmetic code that used to work but be slow will now explode in your > >> face. > Hacker's Delight shows how the overflow check can be done w/ around 6-8% hit on performance. Clojure implements that strategy. Arguments without any knowledge of the details seems fruitless. Why not try the primitive branch yourself and report back w/ actual experience? I've been using 1.3 exclusively for some time and experienced no trouble. 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: Midje: a different slant on clojure testing
On Dec 16, 2010, at 12:21 AM, Shantanu Kumar wrote: > 2. Why would I use Midje instead of clojure.test? Oh, one other thing: you can mix and match Midje and Clojure.test tests. Midje uses the clojure.test reporting mechanism. You can start adding Midje tests to your existing test files and change old tests to the new format at your leisure. (The downside is that if you want the test summaries to be right, you have to wrap the Midje tests in #'deftest. Otherwise fact successes and failures aren't counted when you do 'lein test'.) - Brian Marick, Artisanal Labrador Contract programming in Ruby and Clojure Author of /Ring/ (forthcoming; sample: http://bit.ly/hfdf9T) www.exampler.com, www.exampler.com/blog, www.twitter.com/marick -- You 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.3 Alpha 4
> On Thu, Dec 16, 2010 at 8:17 AM, Stuart Halloway > wrote: >> I wrote: >>> Breaking source compatibility with just about every single preexisting >>> line of Clojure code out there is supposed to make our lives *easier*? >>> I'd dearly love to know how -- my cousin is a stage magician and he's >>> always on the lookout for new tricks, so this would make a nearly >>> perfect Christmas present for him. :) >> >> We are aware that this is a breaking change. :-) >> >> In addition to talking on IRC and the mailing list, we checked dozens of >> Clojure libraries (code review and test suite) and found *minimal* breakage. >> If anyone has different empirical evidence to offer, please do so. > > Define "minimal". What folllows is more of a characterization than a definition: Number of projects checked: 20+ open source projects and a similar number of commercial projects. Number of unit tests broken by changes in 1.3, across all projects: 1. (Solution: Replace "1" with "1N" in test input.) Number of higher-level tests broken: 0. Number of production breakages observed: 0. It takes a lot of effort to do this checking. I have done it. It takes almost zero time to offer opinions without bothering to check. 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.3 Alpha 4
On Thu, Dec 16, 2010 at 11:36 AM, David Nolen wrote: > On Thu, Dec 16, 2010 at 11:18 AM, Ken Wesson wrote: >> >> On Thu, Dec 16, 2010 at 8:13 AM, Stuart Halloway >> wrote: >> >> Worse, from the sounds of it the new + isn't exactly the old >> >> unchecked-+; it still checks for overflow rather than allowing >> >> wrapping. That's going to add a compare-and-branch to every add >> >> instruction and halve the speed of those operators on typical >> >> hardware. Compare-and-throw-exception is hardly superior to >> >> compare-and-box-in-BigInteger, since it's still slow AND now some >> >> arithmetic code that used to work but be slow will now explode in your >> >> face. > > Hacker's Delight shows how the overflow check can be done w/ around 6-8% hit > on performance. Clojure implements that strategy. The overflow check is the same whether you react to an overflow by boxing the result or react to an overflow by throwing an exception! > Arguments without any knowledge of the details seems fruitless. This reads like a personal criticism to me. And meanwhile you managed to entirely miss my point. -- You 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.3 Alpha 4
On Thu, Dec 16, 2010 at 12:04 PM, Stuart Halloway wrote: > I wrote: >> On Thu, Dec 16, 2010 at 8:17 AM, Stuart Halloway >> wrote: >>> I wrote: Breaking source compatibility with just about every single preexisting line of Clojure code out there is supposed to make our lives *easier*? I'd dearly love to know how -- my cousin is a stage magician and he's always on the lookout for new tricks, so this would make a nearly perfect Christmas present for him. :) >>> >>> We are aware that this is a breaking change. :-) >>> >>> In addition to talking on IRC and the mailing list, we checked dozens of >>> Clojure libraries (code review and test suite) and found *minimal* >>> breakage. If anyone has different empirical evidence to offer, please do so. >> >> Define "minimal". > > What folllows is more of a characterization than a definition: > > Number of projects checked: 20+ open source projects and a similar number of > commercial projects. > > Number of unit tests broken by changes in 1.3, across all projects: 1. > (Solution: Replace "1" with "1N" in test input.) So we're looking at breakage in 2% of cases, IF the testing was thorough and included (simulated or actual) industrial-scale use of the systems (overflow problems may well not show up with small test cases and then blow up in your face in a production environment with much bigger inputs) and IF that's a statistically significant sample size. 2% may not sound like much but imagine the uproar if Oracle made a non-compatible change that broke 2% of all Java codebases! > It takes almost zero time to offer opinions without bothering to check. That looks like yet another unproductive, non-constructive personal criticism. -- You 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.3 Alpha 4
>>> Worse, from the sounds of it the new + isn't exactly the old >>> unchecked-+; it still checks for overflow rather than allowing >>> wrapping. That's going to add a compare-and-branch to every add >>> instruction and halve the speed of those operators on typical >>> hardware. Compare-and-throw-exception is hardly superior to >>> compare-and-box-in-BigInteger, since it's still slow AND now some >>> arithmetic code that used to work but be slow will now explode in your >>> face. >> >> This argument is based on the (provably wrong) presumption that "still slow" >> means "equally slow". The difference is percentage points vs. order of >> magnitude. Test it for yourself. > > That does not make sense, since the implementations in both cases have > to test for overflow and branch. In the "overflowed" branch further > expensive actions are taken -- in both cases the creation of a Java > object, for instance (an exception or a boxed numeric). These branches > might differ in other ways in speed, but they're the rare case. The > common case is test and accept the result, returning it, in both > cases; so the common case should have comparable execution speed given > both implementations. If not, something is wrong someplace else with > at least one of the implementations (or, much less likely, with the > JVM/JIT). It will make sense once you understand the implications of primitives and objects not being unified, which come into play before the test for overflow, and hurt you even in applications where overflow never happens. If this thread is not sufficiently clear on that point, and you don't have time to run tests for yourself, can I ask that you please hold off on beating this dead horse until we can >> Until that is done, if you want to continue this thread, please make >> arguments that back up notions like "slow" or "fast" or "broken" with >> evidence from real code. > > As for "broken", you can't honestly think changing the semantics of > the + operator, after years of code written in Clojure has > accumulated, won't break *something*. Surely. Most likely many > somethings, scattered all over the place. That's why it is called a breaking change. :-) We have (and will continue to have) a large number of prereleases for people to shake out issues. 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.3 Alpha 4
> > The overflow check is the same whether you react to an overflow by > boxing the result or react to an overflow by throwing an exception! But then all the rest of the code has to check whether things are boxed or not. Moreover, the JVM makes it very hard (impossible) to manipulate something that is either a boxed or a primitive value. -- You 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.3 Alpha 4
*begin rant* I have yet to see anyone who posts the classic "rtfm" (even politely) response search previous posts and realize that "rtfm" responses have already been sent and refrain from sending the same explanation of how to use a mailing list over and over and over. Simple customer service experience teaches that if customers are asking the same questions multiple times, then the documentation is either, hard to find, incomplete, or not clear enough. Improving the docs is a healthier and more productive use of time than starting yet another thread on how to use a mailing list. *end rant* Sorry. Couldn't contain myself ;-) Eric Schulte wrote: Ken Wesson writes: On Wed, Dec 15, 2010 at 12:51 PM, Eric Schulte wrote: Ken Wesson writes: Are you honestly suggesting I search the archives It is common courtesy on open-source lists such as this one to check if a question you are about to ask has already been answered. As I believe I already mentioned, if everyone spends a while searching some archives every time they are going to post, this list's traffic will drop to nearly nil. Do we really want that? 1. I disagree with your assertion that traffic would drop to zero, and 2. I would not mind if posts which repeat previous posts were not sent but maybe I'm wrong, and creating a vibrant open-source community is as simple as a thesaurus-equipped script which re-sends old mailing list posts with some synonym replacement. :) -- You 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.3 Alpha 4
>> It takes almost zero time to offer opinions without bothering to check. > > That looks like yet another unproductive, non-constructive personal criticism. Why do you think so? These people are just requesting you to check things for yourself instead engaging in this meaningless argument. The design decision of implementing "enhanced primitives" support in Clojure was taken months ago after a *lot* of intense debate, thinking & research. You are unwilling to dig the archives, read the implementation or even test an existing codebase for issues, yet you are accusing people of criticizing you just because they feel you should do a bit more research about this. Don't you think it's unfair of you? Talk is cheap, show us the code. Regards, BG -- Baishampayan Ghose b.ghose at gmail.com -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Java out of memory problem
Hello, I'm trying to insert in a database large number of records, however it's not scaling correctly. For 100 records it takes 10 seconds, for 100 records it takes 2 min to save. But for 250 records it throws Java Heap out of memory exception. I've tried separting the records processing and the actual batch save. Just processing the 250 records in memory it take 30 seconds. With batch insert it throws the above exception. I don't understand why saving to a database it creates more Java Heap space. Any ideas would be appreciated. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Clojure 1.3 Alpha 4
On Thu, Dec 16, 2010 at 12:06 PM, Ken Wesson wrote: > The overflow check is the same whether you react to an overflow by > boxing the result or react to an overflow by throwing an exception! > It's not the same at all. If you box the result all further arithmetic computations slows down. You cannot preserve the primitive path. Throwing an exception means "Hey it looks like you want big math, clearly you don't want or need primitive perf, fix your code". So use auto-promoting variants, or add a big integer literal in the right place. BigInts are contagious. In this world very little work needs to be done to satisfy the real desires of people who want the fast path and those people who want big math. You're right that this is a breaking change. Some code will get broken. However there are other breaking changes in 1.3 that have far greater implications for real Clojure apps than this change - like dynamic binding. This affects a much large range of Clojure apps, libraries and tools. But Clojure is not Oracle. Rich Hickey has stated that he will continue to forge ahead. Things are not going to "slow down". That is something that the Clojure community embraces. Otherwise why would any of us be writing in a crazy functional Lisp on the JVM :) P.S. That was not a personal criticism as much as fact that can be applied to any discussion between respectful parties. 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.3 Alpha 4
On Thu, Dec 16, 2010 at 12:13 PM, Stuart Halloway wrote: Worse, from the sounds of it the new + isn't exactly the old unchecked-+; it still checks for overflow rather than allowing wrapping. That's going to add a compare-and-branch to every add instruction and halve the speed of those operators on typical hardware. Compare-and-throw-exception is hardly superior to compare-and-box-in-BigInteger, since it's still slow AND now some arithmetic code that used to work but be slow will now explode in your face. >>> >>> This argument is based on the (provably wrong) presumption that "still >>> slow" means "equally slow". The difference is percentage points vs. order >>> of magnitude. Test it for yourself. >> >> That does not make sense, since the implementations in both cases have >> to test for overflow and branch. In the "overflowed" branch further >> expensive actions are taken -- in both cases the creation of a Java >> object, for instance (an exception or a boxed numeric). These branches >> might differ in other ways in speed, but they're the rare case. The >> common case is test and accept the result, returning it, in both >> cases; so the common case should have comparable execution speed given >> both implementations. If not, something is wrong someplace else with >> at least one of the implementations (or, much less likely, with the >> JVM/JIT). > > It will make sense once you understand I don't care for your condescending tone. If you have a personal problem with me, please take it up in personal email rather than posting it to the list. Thank you. Now, as I understand it, + and the like, being normal Clojure functions (rather than, say, special forms or interop calls), take and return boxed values. So boxing overhead is unaffected by all this. We have a function that, say, takes two Integers, sees if the result overflows, and if not adds them and returns the boxed result, and if it does overflow, either throws an exception or returns a BigInteger rather than an Integer. The check should be about the same speed in either case. Now, BigInteger contagion could slow things down, but it would only do so in the case where the proposed changes result in exceptions being thrown (= breakage, in the case of old code that assumes BigInteger promotion will happen instead). So, some code won't slow down or speed up appreciably; other code would speed up if the behavior was to wrap the value but will instead simply not work now. I still confess I don't see a big advantage here. -- You 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.3 Alpha 4
On Thu, Dec 16, 2010 at 12:14 PM, nicolas.o...@gmail.com wrote: >> >> The overflow check is the same whether you react to an overflow by >> boxing the result or react to an overflow by throwing an exception! > > But then all the rest of the code has to check whether things are boxed or > not. > Moreover, the JVM makes it very hard (impossible) to manipulate > something that is > either a boxed or a primitive value. I thought it had method overload resolution for that. And that everything is boxed, except in let and loop forms sometimes, and then whether it's boxed or not is generally known at compile time. -- You 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.3 Alpha 4
On Dec 16, 2010, at 11:19 AM, Ken Wesson wrote: > On Thu, Dec 16, 2010 at 8:17 AM, Stuart Halloway > wrote: >> I wrote: >>> Breaking source compatibility with just about every single preexisting >>> line of Clojure code out there is supposed to make our lives *easier*? >>> I'd dearly love to know how -- my cousin is a stage magician and he's >>> always on the lookout for new tricks, so this would make a nearly >>> perfect Christmas present for him. :) >> >> We are aware that this is a breaking change. :-) >> >> In addition to talking on IRC and the mailing list, we checked dozens of >> Clojure libraries (code review and test suite) and found *minimal* breakage. >> If anyone has different empirical evidence to offer, please do so. > > Define "minimal". > It's a breaking change. It will be clearly documented as such. Whether you think it is the right thing, minimal or whatever else is not going to change it. There have been very few breaking changes made in Clojure, given its age, and this is going to be one of them. You'll either have to get over it, or move on. Your dissatisfaction is noted. The discussion period for this has passed. Thanks, Rich -- You 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.3 Alpha 4
On Thu, Dec 16, 2010 at 12:22 PM, Baishampayan Ghose wrote: >>> It takes almost zero time to offer opinions without bothering to check. >> >> That looks like yet another unproductive, non-constructive personal >> criticism. > > Why do you think so? Because of the implication that my opinions are uninformed ones not worth their time. (It's interesting, though, that they apparently consider those opinions worth their time to criticize, but not worth their time to actually consider carefully!) > These people are just requesting you to check things for yourself I CAN'T check things for myself -- I only have 1.2 here and I'm not about to break all of my OWN code by "up"grading it to an alpha version that has at least one KNOWN massive compatibility-breaking change as well as being likely to contain significant unfixed bugs. Really, I was wondering if anyone would manage to top the ridiculous suggestion that every post be preceded by two hours of thorough archive-diving and reading of older posts. Now you have, by making the truly *ludicrous* suggestion that one not post unless one is using the bleedingest-edge alpha version, complete with whatever headaches that will certainly induce (not least among them, updating everything every few days instead of every few months/years). > instead engaging in this meaningless argument. The > design decision of implementing "enhanced primitives" support in > Clojure We had fine primitives support in let and loop with the unchecked-foo operations; and it didn't affect the rest of one's code, which was generally not arithmetic-performance-critical. I still do not see what advantage this change brings. Can the fastest primitive operations in let and loop contexts be made any faster? Not that I've heard. Can primitives now be passed and returned in function calls? Not that I've heard, just "we're working on it". > You are unwilling to dig the archives I am unwilling to accede to a request if it's stated rudely enough. I DID read the summary link someone posted, but it did not relieve my concerns on this topic. This does not mean I did not read it thoroughly and understand it. It means that I did and I STILL DISAGREE WITH YOU. Perhaps this notion is literally inconceivable to you, but those're the facts, Jack. > read the implementation Don't have it. (1.3 alpha 4, that is.) > or even test an existing codebase for issues Don't have it. (1.3 alpha 4, that is.) > yet you are accusing people of criticizing you just because they feel you > should do a bit more > research about this. I'm asking them to explain themselves better, and their responses are not any kind of explanation. -- You 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.3 Alpha 4
On Thu, Dec 16, 2010 at 12:24 PM, David Nolen wrote: > On Thu, Dec 16, 2010 at 12:06 PM, Ken Wesson wrote: >> >> The overflow check is the same whether you react to an overflow by >> boxing the result or react to an overflow by throwing an exception! > > It's not the same at all. > If you box the result all further arithmetic computations slows down. You > cannot preserve the primitive path. All further arithmetic computations slow down on the one hand; halt with an exception if the opposite choice is made. Slow-but-works is usually preferred to broken. > However there are other breaking changes in 1.3 that have far greater > implications for real Clojure apps than this change - like dynamic binding. > This affects a much large range of Clojure apps, libraries and tools. I don't know how common dynamic binding is in application code. It tends to be in library code more often, which is a smaller number of changes to make. Plus, the dynamic binding changes have a rationale behind them that actually seems to me to make the tradeoff potentially worth it. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Clojure 1.3 Alpha 4
>> yet you are accusing people of criticizing you just because they feel you >> should do a bit more >> research about this. > > I'm asking them to explain themselves better, and their responses are > not any kind of explanation. Please try putting yourself in their shoes. They have already explained themselves the best they could, and it's all documented (in the archives, the wiki, etc). Why do you think they should do it again? Anyway, as Rich said in his response, the die has been cast and it can't be changed at the moment. You will have to either accept it or stick to Clojure 1.2.x. I am requesting you to end the discussion here. Regards, BG -- Baishampayan Ghose b.ghose at gmail.com -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Clojure 1.3 Alpha 4
On Thu, Dec 16, 2010 at 1:06 PM, Ken Wesson wrote: > I don't know how common dynamic binding is in application code. It > tends to be in library code more often, which is a smaller number of > changes to make. Plus, the dynamic binding changes have a rationale > behind them that actually seems to me to make the tradeoff potentially > worth it. I find this situation quite humorous: 1.3 Dynamic binding breaking change Much faster. People don't seem to have strong opinions. But a lot of things break. People fix it and move on. 1.3 Primitive math Much faster. Everyone seems to have a strong opinion. Hardly anything breaks. People move on. 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.3 Alpha 4
> wrote: > Worse, from the sounds of it the new + isn't exactly the old > unchecked-+; it still checks for overflow rather than allowing > wrapping. That's going to add a compare-and-branch to every add > instruction and halve the speed of those operators on typical > hardware. Compare-and-throw-exception is hardly superior to > compare-and-box-in-BigInteger, since it's still slow AND now some > arithmetic code that used to work but be slow will now explode in your > face. This argument is based on the (provably wrong) presumption that "still slow" means "equally slow". The difference is percentage points vs. order of magnitude. Test it for yourself. >>> >>> That does not make sense, since the implementations in both cases have >>> to test for overflow and branch. In the "overflowed" branch further >>> expensive actions are taken -- in both cases the creation of a Java >>> object, for instance (an exception or a boxed numeric). These branches >>> might differ in other ways in speed, but they're the rare case. The >>> common case is test and accept the result, returning it, in both >>> cases; so the common case should have comparable execution speed given >>> both implementations. If not, something is wrong someplace else with >>> at least one of the implementations (or, much less likely, with the >>> JVM/JIT). >> >> It will make sense once you understand > > I don't care for your condescending tone. I apologize. This forum is renowned for civil discourse, and I hope it will continue to be. > Now, as I understand it, + and the like, being normal Clojure > functions (rather than, say, special forms or interop calls), take and > return boxed values. I think I can help here: 1. Clojure's numeric operators are more than normal Clojure functions. You can see hints of this in the source code (even in 1.2!) in the :inline and :inline-arities metadata. 2. As such, Clojure's numeric operators are capable of working directly with primitives. 3. In 1.3 functions can take and return primitives. It is the combination of these factors that provides the speed boost in 1.3, so if you were unaware of some of them, perhaps we have been talking past each other. 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.3 Alpha 4
On Thu, Dec 16, 2010 at 1:15 PM, Baishampayan Ghose wrote: >>> yet you are accusing people of criticizing you just because they feel you >>> should do a bit more >>> research about this. >> >> I'm asking them to explain themselves better, and their responses are >> not any kind of explanation. > > Please try putting yourself in their shoes. They have already > explained themselves the best they could, and it's all documented Then why didn't the link I followed to the summary assuage my doubts? > Why do you think they should do it again? Anyway, as Rich said in his > response, the die has been cast and it can't be changed at the moment. That same summary implied there were two proposals, not just one; in one of them, + and the like retain their current behavior and it is +' and the like that you use if you want potentially faster math. > I am requesting you to end the discussion here. I reserve the right to respond in my own defense if personally attacked, and to respond if asked a question. -- You 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: Java out of memory problem
You might be coming to near OOM with using in-memory processing but don't know it, and the batched (lazy) version is probably holding onto data creating the mem leak. Would you be able to post the relevant source? -- You 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
Possible to use << from clojure.contrib.strint with a string variable
I'm trying to use << from clojure.contrib.strint perform string
interpolation in a string variable. The following,
(ns strint-test (:use clojure.contrib.strint))
(def v 1)
(println (<< "v: ~{v}"))
(def s "v: ~{v}")
(println (<< (str s)))
(println (<< s))
results in
v: 1
v: ~{v}
java.lang.RuntimeException: java.lang.RuntimeException:
java.lang.IllegalArgumentException: No matching method found: indexOf
for class clojure.lang.Symbol (strint-test.clj:8)
Does anybody have any advice on getting (<< s) to work? I have
included the << macro and associated function from
clojure.contrib.strint for reference. Thanks.
(defmacro <<
[string]
`(str ~@(interpolate string)))
(defn- interpolate
"Yields a seq of Strings and read forms."
([s atom?]
(lazy-seq
(if-let [[form rest] (silent-read (subs s (if atom? 2 1)))]
(cons form (interpolate (if atom? (subs rest 1) rest)))
(cons (subs s 0 2) (interpolate (subs s 2))
([^String s]
(if-let [start (->> ["~{" "~("]
(map #(.indexOf s %))
(remove #(== -1 %))
sort
first)]
(lazy-seq (cons
(subs s 0 start)
(interpolate (subs s start) (= \{ (.charAt s (inc
start))
[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
Improving the documentation
On Thu, 16 Dec 2010 10:18:47 -0700 Terrance Davis wrote: > *begin rant* > > I have yet to see anyone who posts the classic "rtfm" (even politely) > response search previous posts and realize that "rtfm" responses have > already been sent and refrain from sending the same explanation of how > to use a mailing list over and over and over. Simple customer service > experience teaches that if customers are asking the same questions > multiple times, then the documentation is either, hard to find, > incomplete, or not clear enough. Improving the docs is a healthier and > more productive use of time than starting yet another thread on how to > use a mailing list. > > *end rant* > > Sorry. Couldn't contain myself ;-) No need to be sorry - it's a very good point. In the past, I've contributed to open source projects by watching for the same question to be raised multiple times, combining the data in the best answers into one "best of breed", and submitting it as a patch for the project handbook. The clojure community doesn't have anything as spiffy as the FreeBSD handbook - instead we have a wiki FAQ page (from clojure.org, click "wiki" then "2 FAQ" to get to http://en.wikibooks.org/wiki/Clojure_Programming). While much more painful than editing docbook, it's a good place to post things. Unfortunately, we can't post excerpts from clojure source there because the wiki license is incompatible with the source license - or anything else using that same license. In particular, not being able to use doc strings, etc. Given that the FAQ itself suggests that such be posted to the clojure group, this makes doing what I did rather problematical. Minimally, I need to figure out whether or not a post contains such an excerpt in order to be able to use it. Worst case, the license for content posted to the group is *also* incompatible with the source license, so you can't legally add any Frequent Answers from there to the FAQ. Ok, I found a problem. Anyone got solutions? http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.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: Erlang-esque bit syntax in Clojure?
> > I was wondering if anyone has been working > on implementing a bit syntax for Clojure in the rough conceptual style > of Erlang's bit syntax. > I'm not an erlang-pro, just dabbled enough to know I like the pattern matching, which is what you're talking about here, I believe. > I'm looking for a Clojure adaptation of the core > concept and tool as it exists in Erlang So, as I understand it, in erlang you have a function and each implementation of that function is guarded by a pattern, in the case of the bit syntax you're able to look at arbitrary binary data. I think compojure provides an interesting template for this; instead of defining `routes` you define patterns (expressed however you want, you just need to create the macros for it), when those patterns match you execute the accompanying forms. The major issue I see here is performance, you would probably have to copy everything off the buffer to actually run it through the pattern matching function. I suppose the copying could be limited to just when you have a full packet, so you'd need another set of logic for defining what a full packet is, IRC erlang does this too when you define your socket options. To that point... I've also seen Zach Tellman's Gloss[2], but I'm not sure > it's what I want. It is highly likely I've missed something I was at Zach's gloss talk two weeks ago and I think it is definitely what you want, at least to start: https://github.com/ztellman/gloss/wiki -- You 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: Possible to use << from clojure.contrib.strint with a string variable
On Thu, Dec 16, 2010 at 2:56 PM, Michael wrote:
>
> I'm trying to use << from clojure.contrib.strint perform string
> interpolation in a string variable. The following,
>
> (ns strint-test (:use clojure.contrib.strint))
>
> (def v 1)
> (println (<< "v: ~{v}"))
>
> (def s "v: ~{v}")
> (println (<< (str s)))
> (println (<< s))
> results in
>
> v: 1
> v: ~{v}
> java.lang.RuntimeException: java.lang.RuntimeException:
> java.lang.IllegalArgumentException: No matching method found: indexOf
> for class clojure.lang.Symbol (strint-test.clj:8)
>
> Does anybody have any advice on getting (<< s) to work? I have
> included the << macro and associated function from
> clojure.contrib.strint for reference. Thanks.
The macro interprets its string argument at macroexpansion time. If it
is a string literal, everything works fine. But if it's a symbol or
s-expression, things go wrong, as you saw. In the case of (<< (str s))
the macro gets a list of 'str and 's rather than "v: ~{v}". In the
case of (<< s) it gets a symbol 's. The latter in particular causes
the .indexOf not found in clojure.lang.Symbol exception you saw.
Frankly, I'm not sure what the use of this is. Compare:
(println (<< "v: ~{v}"))
(println (str "v: " v))
The latter is actually shorter. And the << macro as you've seen won't
work with a runtime-variable format; whereas (apply str some-seq) lets
you vary the content and order at runtime, and the printf-like format
function allows a C-like format syntax where the format string can
again vary at runtime.
--
You 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: Improving the documentation
> On Thu, 16 Dec 2010 10:18:47 -0700 > Terrance Davis wrote: > >> *begin rant* >> >> I have yet to see anyone who posts the classic "rtfm" (even politely) >> response search previous posts and realize that "rtfm" responses have >> already been sent and refrain from sending the same explanation of how >> to use a mailing list over and over and over. Simple customer service >> experience teaches that if customers are asking the same questions >> multiple times, then the documentation is either, hard to find, >> incomplete, or not clear enough. Improving the docs is a healthier and >> more productive use of time than starting yet another thread on how to >> use a mailing list. >> >> *end rant* >> >> Sorry. Couldn't contain myself ;-) > > No need to be sorry - it's a very good point. > > In the past, I've contributed to open source projects by watching for > the same question to be raised multiple times, combining the data in > the best answers into one "best of breed", and submitting it as a > patch for the project handbook. The clojure community doesn't have > anything as spiffy as the FreeBSD handbook - instead we have a wiki > FAQ page (from clojure.org, click "wiki" then "2 FAQ" to get to > http://en.wikibooks.org/wiki/Clojure_Programming). While much more > painful than editing docbook, it's a good place to post things. > > Unfortunately, we can't post excerpts from clojure source there > because the wiki license is incompatible with the source license - or > anything else using that same license. In particular, not being able > to use doc strings, etc. > > Given that the FAQ itself suggests that such be posted to the clojure > group, this makes doing what I did rather problematical. Minimally, I > need to figure out whether or not a post contains such an excerpt in > order to be able to use it. Worst case, the license for content posted > to the group is *also* incompatible with the source license, so you > can't legally add any Frequent Answers from there to the FAQ. > > Ok, I found a problem. Anyone got solutions? > > http://dev.clojure.org/display/doc/FAQ) has edit capabilities tied to signing the CA. If you have signed a CA you can post to the FAQ, quoting from other CA-governed sources (e.g. Clojure) as makes sense. Does that help? 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: Erlang-esque bit syntax in Clojure?
The only things I know that Gloss lacks relative to Erlang's functionality is arbitrary bit-lengths for integers and mixed-endian support, both of which I plan to add in the near future. Lacking Erlang's built in pattern matching, the Clojure implementation will probably be less elegant in some cases, but it will certainly get the job done. If you decide to use Gloss and run into any issues, please let me know. Zach On Dec 16, 1:55 pm, Michael Ossareh wrote: > > I was wondering if anyone has been working > > on implementing a bit syntax for Clojure in the rough conceptual style > > of Erlang's bit syntax. > > I'm not an erlang-pro, just dabbled enough to know I like the pattern > matching, which is what you're talking about here, I believe. > > > I'm looking for a Clojure adaptation of the core > > concept and tool as it exists in Erlang > > So, as I understand it, in erlang you have a function and each > implementation of that function is guarded by a pattern, in the case of the > bit syntax you're able to look at arbitrary binary data. > > I think compojure provides an interesting template for this; instead of > defining `routes` you define patterns (expressed however you want, you just > need to create the macros for it), when those patterns match you execute the > accompanying forms. > > The major issue I see here is performance, you would probably have to copy > everything off the buffer to actually run it through the pattern matching > function. I suppose the copying could be limited to just when you have a > full packet, so you'd need another set of logic for defining what a full > packet is, IRC erlang does this too when you define your socket options. > > To that point... > > I've also seen Zach Tellman's Gloss[2], but I'm not sure > > > it's what I want. It is highly likely I've missed something > > I was at Zach's gloss talk two weeks ago and I think it is definitely what > you want, at least to start:https://github.com/ztellman/gloss/wiki -- You 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: Erlang-esque bit syntax in Clojure?
On Thu, Dec 16, 2010 at 6:01 PM, Zach Tellman wrote: > The only things I know that Gloss lacks relative to Erlang's > functionality is arbitrary bit-lengths for integers and mixed-endian > support, both of which I plan to add in the near future. Lacking > Erlang's built in pattern matching, the Clojure implementation will > probably be less elegant in some cases, but it will certainly get the > job done. Erlang's built-in pattern matching is insignificant compared to the power of the (macros and DSLs) Force. :) -- You 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: Improving the documentation
On Thu, 16 Dec 2010 17:50:58 -0500 Stuart Halloway wrote: > > On Thu, 16 Dec 2010 10:18:47 -0700 > > Terrance Davis wrote: > > > >> *begin rant* > >> > >> I have yet to see anyone who posts the classic "rtfm" (even politely) > >> response search previous posts and realize that "rtfm" responses have > >> already been sent and refrain from sending the same explanation of how > >> to use a mailing list over and over and over. Simple customer service > >> experience teaches that if customers are asking the same questions > >> multiple times, then the documentation is either, hard to find, > >> incomplete, or not clear enough. Improving the docs is a healthier and > >> more productive use of time than starting yet another thread on how to > >> use a mailing list. > >> > >> *end rant* > >> > >> Sorry. Couldn't contain myself ;-) > > > > No need to be sorry - it's a very good point. > > > > In the past, I've contributed to open source projects by watching for > > the same question to be raised multiple times, combining the data in > > the best answers into one "best of breed", and submitting it as a > > patch for the project handbook. The clojure community doesn't have > > anything as spiffy as the FreeBSD handbook - instead we have a wiki > > FAQ page (from clojure.org, click "wiki" then "2 FAQ" to get to > > http://en.wikibooks.org/wiki/Clojure_Programming). While much more > > painful than editing docbook, it's a good place to post things. > > > > Unfortunately, we can't post excerpts from clojure source there > > because the wiki license is incompatible with the source license - or > > anything else using that same license. In particular, not being able > > to use doc strings, etc. > > > > Given that the FAQ itself suggests that such be posted to the clojure > > group, this makes doing what I did rather problematical. Minimally, I > > need to figure out whether or not a post contains such an excerpt in > > order to be able to use it. Worst case, the license for content posted > > to the group is *also* incompatible with the source license, so you > > can't legally add any Frequent Answers from there to the FAQ. > > > > Ok, I found a problem. Anyone got solutions? > > > > > The new FAQ (under construction at http://dev.clojure.org/display/doc/FAQ) > has edit capabilities tied to signing the CA. > > If you have signed a CA you can post to the FAQ, quoting from other > CA-governed sources (e.g. Clojure) as makes sense. > > Does that help? First, that looks more like it's part of a wiki aimed at clojure developers than at clojure users. While that's an important thing to have, it's not what I'm looking for, and I'm pretty sure that combining the two is bad idea. Second, a wiki that requires you be a contributor to edit it seems to defeat the point of having a wiki in the first place. If you're going to require someone to be a contribute to edit the docs, why not use a real document processing system instead, so that you can handle documentation using the same tools (source control system, etc.) as you're using for code, and get the added benefit of being able to generate media-specific output (assuming you chose a good dps). Finally, Jira needs a category for "wiki bugs" so that people who haven't signed a CA can contribute fixes (patches? to a wiki? Another reason to use a real document processing system). http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.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: Erlang-esque bit syntax in Clojure?
Hi Daniel, I'm fairly certain this is not exactly what you're looking for, but it's somewhat related and it might give you a fuller image -- my tiny clj-bitfields library: https://github.com/nathell/clj-bitfields Best, Daniel Janus -- You 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: Java out of memory problem
On Thu, Dec 16, 2010 at 09:19, clj123 wrote: > Hello, > > I'm trying to insert in a database large number of records, however > it's not scaling correctly. For 100 records it takes 10 seconds, for > 100 records it takes 2 min to save. But for 250 records it > throws Java Heap out of memory exception. > > I've tried separting the records processing and the actual batch save. > Just processing the 250 records in memory it take 30 seconds. With > batch insert it throws the above exception. I don't understand why > saving to a database it creates more Java Heap space. > > Any ideas would be appreciated. What indexes are on the table that you're inserting into? To me the increase in time suggests your index is being rebuilt after each insert. As for the memory, I concur with zeph, you're either holding onto the head of a seq or you're accessing some portion of a string which is holding the data structures around and you're OOMing as a result. Code please :) -- You 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: Possible to use << from clojure.contrib.strint with a string variable
Michael writes:
> I'm trying to use << from clojure.contrib.strint perform string
> interpolation in a string variable. The following,
> (def s "v: ~{v}")
> (println (<< (str s)))
> (println (<< s))
This is not going to be possible (at least not efficiently: you could
technically do itwith &env and eval, but it would be slow and ugly).
The << macro compiles the interpolation string into code, so it needs
access to the string at compile-time.
It also needs to capture "v" and you can't get lexical bindings at
run-time unless you explicitly hold onto them all with &env. Capturing
the entire lexical environment is generally a bad idea (although useful
in a few specific cases like debug-repl) as it breaks local-clearing and
could cause difficult to diagnose "holding onto head" problems.
You didn't explain why you wanted to do it. Maybe you could pass around
first class functions instead of strings?
(def greetings
{:english
(fn [m] (<< "Hello ~(:name m). You have ~(:balance m) dollars."))
:german
(fn [m] (<< "Hallo ~(:name m). Sie haben ~(:balance m) dollar."))})
(def *lang* :english)
(println ((greetings *lang*) {:name "John", :balance 200}))
Personally I'm not a fan of the << style string interpolation (at least
in Clojure where there's better options). I think #'format is generally
a better choice for this sort of thing and since it can't contain
arbitrary Clojure code it doesn't need to be compiled:
(def *lang* :german)
(def greetings
{:english "Hello %s. You have %d dollars."
:german "Hallo %s. Sie haben %d dollar."})
(format (greetings *lang*) "John" 200)
--
You 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
