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 dnolen.li...@gmail.com wrote: On Tue, Dec 14, 2010 at 9:04 PM, Ken Wesson kwess...@gmail.com wrote: On Tue, Dec 14, 2010 at 8:23 PM, Benny Tsai benny.t...@gmail.com 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
Re: Clojure 1.3 Alpha 4
On Thu, Dec 16, 2010 at 8:13 AM, Stuart Halloway stuart.hallo...@gmail.com 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 stuart.hallo...@gmail.com 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 kwess...@gmail.com wrote: On Thu, Dec 16, 2010 at 8:13 AM, Stuart Halloway stuart.hallo...@gmail.com 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: Clojure 1.3 Alpha 4
On Thu, Dec 16, 2010 at 8:17 AM, Stuart Halloway stuart.hallo...@gmail.com 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 dnolen.li...@gmail.com wrote: On Thu, Dec 16, 2010 at 11:18 AM, Ken Wesson kwess...@gmail.com wrote: On Thu, Dec 16, 2010 at 8:13 AM, Stuart Halloway stuart.hallo...@gmail.com 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 stuart.hallo...@gmail.com wrote: I wrote: On Thu, Dec 16, 2010 at 8:17 AM, Stuart Halloway stuart.hallo...@gmail.com 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 kwess...@gmail.com writes: On Wed, Dec 15, 2010 at 12:51 PM, Eric Schulte schulte.e...@gmail.com wrote: Ken Wesson kwess...@gmail.com 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
Re: Clojure 1.3 Alpha 4
On Thu, Dec 16, 2010 at 12:13 PM, Stuart Halloway stuart.hallo...@gmail.com 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 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 stuart.hallo...@gmail.com 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 b.gh...@gmail.com 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 upgrading 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 dnolen.li...@gmail.com wrote: On Thu, Dec 16, 2010 at 12:06 PM, Ken Wesson kwess...@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! 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 kwess...@gmail.com 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
stuart.hallo...@gmail.com 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 b.gh...@gmail.com 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: Clojure 1.3 Alpha 4
On Wed, Dec 15, 2010 at 1:07 AM, David Nolen dnolen.li...@gmail.com wrote: On Wed, Dec 15, 2010 at 12:50 AM, Ken Wesson kwess...@gmail.com wrote: On Wed, Dec 15, 2010 at 12:38 AM, David Nolen dnolen.li...@gmail.com wrote: On Wed, Dec 15, 2010 at 12:22 AM, Ken Wesson kwess...@gmail.com wrote: Are you honestly suggesting I search the archives for every word of every thought that it ever occurs to me to post here? With all due respect, the topic has already been bike shedded into the ground by many members in the community. Fascinating. Your point being? That statement of yours does not, after all, magically make searching the archive for every word in every post you ever think of posting suddenly become practical. I wasn't suggesting you do that. People earlier in the post gave links to the thread. The first link to the thread was posted AFTER I was castigated with the phrase this topic has been discussed to death before on this group. So, no, people earlier in the post did NOT give links to the thread. People earlier in the post DID expect me to have read it before any of them mentioned it. And that it what I took issue with. -- You 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
Again, there'd have to be a staggering further benefit from the change than just the clojure.core code looks cleaner in github or even the code is a bit easier to maintain in the future. I'm not sure that even massive increases in code maintainability alone suffice for something like this. A major, massively end-user-useful new feature that's nigh-impossible to implement otherwise that can then be implemented *might* suffice. I think the point was not to criticize you at all (nobody have to read every post in the archive) but just to point the fact that this debate was somehow already behind us. It has been already debated a lot with pretty good points on each side. (The concerns you are expressing are good points, as are the answers in this thread and the preceeding on the subject.) For the specific problem you are facing, I would advise to go through your code looking for number literal and replacing each number by N. (ex 15 --- 15N). As boxedness is contagious, you probably won't have to change much more to solve compatibility issues with 1.3. If you find other specific problems, it would be great to post them: we will need a good compilation of tips to convert numerical code from 1.2 to 1.3. 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.3 Alpha 4
On Wed, Dec 15, 2010 at 10:56 AM, Laurent PETIT laurent.pe...@gmail.com wrote: People criticized me Hello Ken, please, don't take it bad, but just halt for a minute, and take a deep breath. Nobody criticized you. To convince myself with this, I've reread the first posts following your first ones: David Nolen: 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. Best to read over the very, very long thread on the subject. No objection to this one. Brian: This topic has been discussed to death before on this group. This reads as a (mild) criticism. Short version: Doing the right thing is actually harder than you might first think: methods in Java must choose between returning a primitive and Suggests a criticism, but furthermore seems to miss the point. If we were debating whether to make arithmetic work the 1.2 way or the 1.3 alpha 4 way while still busily creating Clojure from scratch, which way would be easier to implement would be a key factor in the decision and whether the choice we made might break existing code wouldn't be. However, Clojure 1.2 exists and is already implemented, with arithmetic working the 1.2 way, and there is a ton of existing code that may be relying on arithmetic working the 1.2 way. So breaking existing code IS material to the debate now, and whether it's hard to implement the 1.2 way is not. There's no need to implement the 1.2 way because it's already been done. Michael: On Dec 14, 2010, at 9:26 PM, Ken Wesson wrote: quickbasicg...@gmail.com wrote: This topic has been discussed to death before on this group. If so, it was before I joined. That's what archives are for: This is the one I objected the most to. First of all, I argued back (mildly) against the (mild) criticism from quickbasicguru (and what, I might ask, is one of those doing on a lisp mailing list? :)) and Michael argued instead of acceding. So it's sort of as if an elbow came close to my face, possibly unintentionally, I took a mild action (raising my own arm in a blocking posture) to prevent it knocking my glasses off, and someone grabbed my arm and tried to yank it down again to ensure the elbow hit me in the nose. That's a deliberate attack and it makes it more likely the elbow was also. Furthermore, Michael's statement carries with it the implication that I should search the archives for every word I'm about to use before every post to this list, which would take hours of my time every day if implemented. That simply cannot be reasonable and I feel it necessary to make it very firmly clear that no such expectation can be considered reasonable. In particular, I pointed out that if Michael's search-the-archives-first-before-posting-anything policy was adhered to perfectly by everyone, contributions to this list would slow to a crawl, if not stop entirely. There are 2 ways to reduce that: apply the policy only to some users, or only to some topics. The first of these is obviously grossly unfair. That leaves the second. The problem with the second is: which topics require an archive search and which do not is not itself obvious. Such a policy turns this list into a minefield; unless you search the archives on every post (check for a mine at every footfall) you might oneday fail to search on a post on one of the forbidden topics (fail to check for a mine at a spot where there's actually a mine). The only way to avoid the minefield effect, other than not requiring (via punishing with public castigation) people to check the archives at all, is to post the touchy subject list somewhere. Of course, then there's the problem of making sure that everyone knows about the touchy subject list! And about every update to it. It would have to be reposted every few days like the usenet faqs of yore, with a clear indication in the subject header of whether anything had been added. -- You 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 Wed, Dec 15, 2010 at 11:14 AM, Ken Wesson kwess...@gmail.com wrote: Pros (heard from others so far and taken on faith): * Clojure's code base can be made internally simpler. * It's easier to implement what was already implemented. (?) * Code that isn't performance-critical may get slightly faster. Not many people have mentioned concrete benefits from this change because they have already been enumerated in the original thread about the 1.3 primitive math change. So I don't think anyone is going to defend or critique your arguments. From *my* experience unless you're working on Project Euler, you won't have to change your code. I've have yet to hear anyone else state otherwise, which, admittedly, is not conclusive, but perhaps a good sign. 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
2010/12/15 Ken Wesson kwess...@gmail.com On Wed, Dec 15, 2010 at 1:11 AM, Michael Gardner gardne...@gmail.com wrote: On Dec 14, 2010, at 11:22 PM, Ken Wesson wrote: On Tue, Dec 14, 2010 at 10:37 PM, Michael Gardner gardne...@gmail.com wrote: That's what archives are for Are you honestly suggesting I search the archives for every word of every thought that it ever occurs to me to post here? I don't have that kind of time and I doubt anyone else does. If anyone started to actually enforce such a rule, participation here would drop to practically zero overnight. That's a mighty fine straw man you have there. And how deftly you knock it down! How rude. It is not a straw man. People criticized me Hello Ken, please, don't take it bad, but just halt for a minute, and take a deep breath. Nobody criticized you. To convince myself with this, I've reread the first posts following your first ones: David Nolen: 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. Best to read over the very, very long thread on the subject. Brian: This topic has been discussed to death before on this group. Short version: Doing the right thing is actually harder than you might first think: methods in Java must choose between returning a primitive and Michael: On Dec 14, 2010, at 9:26 PM, Ken Wesson wrote: quickbasicg...@gmail.com wrote: This topic has been discussed to death before on this group. If so, it was before I joined. That's what archives are for: http://groups.google.com/group/clojure/search?group=clojureq=primitive+math; Peace, -- 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
Re: Clojure 1.3 Alpha 4
On Wed, Dec 15, 2010 at 11:07 AM, nicolas.o...@gmail.com nicolas.o...@gmail.com wrote: Again, there'd have to be a staggering further benefit from the change than just the clojure.core code looks cleaner in github or even the code is a bit easier to maintain in the future. I'm not sure that even massive increases in code maintainability alone suffice for something like this. A major, massively end-user-useful new feature that's nigh-impossible to implement otherwise that can then be implemented *might* suffice. I think the point was not to criticize you at all (nobody have to read every post in the archive) but just to point the fact that this debate was somehow already behind us. Perhaps so, but if so, this pointing-out was done in a manner that was open to interpretation. It has been already debated a lot with pretty good points on each side. (The concerns you are expressing are good points, as are the answers in this thread and the preceeding on the subject.) What answers in this thread? The points I'm aware of so far are: Pros (heard from others so far and taken on faith): * Clojure's code base can be made internally simpler. * It's easier to implement what was already implemented. (?) * Code that isn't performance-critical may get slightly faster. Cons: (easily inferred from what's been stated) * Code that is performance-critical won't get any faster but will need to be rewritten. * It may even get slower if there's no way to get the old unchecked-foo behavior where overflows wrap rather than throw OR get promoted. * Everything else may break randomly from time to time if not rewritten. * Ugly tick-marks will appear after every arithmetic operator in ordinary code. * Or else ugly Ns after every numeric literal in ordinary code. * Or else it breaks randomly from time to time. * Non-backward-compatible semantic changes affecting nearly every existing sourcefile! I can only assume, in the spirit of interpreting these events charitably, that there may be a pro or two not on my list. :) But that means that those pros were not raised in this thread. You said the answers in this thread are good points, but the second pro on my list is damned dubious, the third is clearly not worth wrecking backward compatibility, and I'm highly dubious of the notion that the first is, or even all three of those combined. For the specific problem you are facing, I would advise to go through your code looking for number literal and replacing each number by N. (ex 15 --- 15N). As boxedness is contagious, you probably won't have to change much more to solve compatibility issues with 1.3. If you find other specific problems, it would be great to post them: we will need a good compilation of tips to convert numerical code from 1.2 to 1.3. Thanks. I'll keep this in mind if I'm ever forced to upgrade to 1.3. -- You 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
Ken Wesson kwess...@gmail.com 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. Not only does it save a lot of noise on the list, but it often means that you find your answer immediately rather than having to wait for a reply. for every word of every thought that it ever occurs to me to post here? hyperbole helps no-one, generally a single short query suffices -- You 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 Wed, Dec 15, 2010 at 12:51 PM, Eric Schulte schulte.e...@gmail.com wrote: Ken Wesson kwess...@gmail.com 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? -- You 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, 14 Dec 2010 21:04:11 -0500 Ken Wesson kwess...@gmail.com wrote: On Tue, Dec 14, 2010 at 8:23 PM, Benny Tsai benny.t...@gmail.com 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. One of the things those of us on your side *begged* for (and apparently also didn't get) was that the versions with correct behavior not have second-class names. That we didn't get them means we'll have to provide them ourselves, but it's easy. Since we're having to fix code anyway, just use a file containing something like: (def add +') (def sub -') (def mul *') (def add1 inc') (def sub1 dec') when you need it. mike -- Mike Meyer m...@mired.org 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: Clojure 1.3 Alpha 4
On Wed, Dec 15, 2010 at 12:52 PM, Mike Meyer mwm-keyword-googlegroups.620...@mired.org wrote: One of the things those of us on your side *begged* for (and apparently also didn't get) was that the versions with correct behavior not have second-class names. That we didn't get them means we'll have to provide them ourselves, but it's easy. Since we're having to fix code anyway, just use a file containing something like: (def add +') (def sub -') (def mul *') (def add1 inc') (def sub1 dec') I'd much rather exclude +, -, etc. when importing core and then (def + +'), etc. and (def unchecked-+ clojure.core/+) etc. Of course that adds enough boilerplate to the code to make me want to write a my-ns macro that passes most of its arguments through to ns but does all of the above as well. And still leaves me no way to get the old unchecked-+ speed and behavior (wrap on overflow rather than compare-and-branch then throw). I can only hope the branch prediction in modern CPUs will mostly prevent the speed loss from this change. -- You 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
Ken Wesson kwess...@gmail.com writes: On Wed, Dec 15, 2010 at 12:51 PM, Eric Schulte schulte.e...@gmail.com wrote: Ken Wesson kwess...@gmail.com 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
On Wed, Dec 15, 2010 at 1:12 PM, Eric Schulte schulte.e...@gmail.com wrote: Ken Wesson kwess...@gmail.com writes: On Wed, Dec 15, 2010 at 12:51 PM, Eric Schulte schulte.e...@gmail.com wrote: Ken Wesson kwess...@gmail.com 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 I said nearly nil, not exactly zero. It would just slow down tremendously as everyone spent ages poking around in Google instead of coding or writing insightful mailing list posts just to be sure of not maybe possibly duplicating something someone else said six years ago in this list. :) -- You 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 Wed, 15 Dec 2010 13:02:13 -0500 Ken Wesson kwess...@gmail.com wrote: On Wed, Dec 15, 2010 at 12:51 PM, Eric Schulte schulte.e...@gmail.com wrote: Ken Wesson kwess...@gmail.com 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? Actually, what would drop to nearly nil would be questions that have already been answered and points that have already been debated to death. And yes, we *do* want that. In fact, it's part of the FAQ on asking smart questions: http://www.catb.org/~esr/faqs/smart-questions.html. Further, not only is it easy (the list is hosted by google groups, so just googling for keywords will search it) but may well turn up the answer faster than posting to the list. Admittedly, that (or searching the archives proper) might not have found what you're looking for in this case, because neither enhanced nor primitive leap to mind as search terms when you get an unexpected overflow error. But it works often enough that checking google before asking a question is a productive habit to get into. mike -- Mike Meyer m...@mired.org 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: Clojure 1.3 Alpha 4
On Dec 15, 10:05 am, Ken Wesson kwess...@gmail.com wrote:
On Wed, Dec 15, 2010 at 12:52 PM, Mike Meyer
mwm-keyword-googlegroups.620...@mired.org wrote:
One of the things those of us on your side *begged* for (and
apparently also didn't get) was that the versions with correct
behavior not have second-class names. That we didn't get them means
we'll have to provide them ourselves, but it's easy. Since we're
having to fix code anyway, just use a file containing something like:
(def add +')
(def sub -')
(def mul *')
(def add1 inc')
(def sub1 dec')
I'd much rather exclude +, -, etc. when importing core and then (def +
+'), etc. and (def unchecked-+ clojure.core/+) etc.
Of course that adds enough boilerplate to the code to make me want to
write a my-ns macro that passes most of its arguments through to ns
but does all of the above as well.
And still leaves me no way to get the old unchecked-+ speed and
behavior (wrap on overflow rather than compare-and-branch then throw).
I can only hope the branch prediction in modern CPUs will mostly
prevent the speed loss from this change.
This was one of the stated features of the new release:
user= *clojure-version*
{:major 1, :minor 3, :incremental 0, :qualifier alpha4}
user= (doc *unchecked-math*)
-
clojure.core/*unchecked-math*
While bound to true, compilations of +, -, *, inc, dec and the
coercions will be done without overflow checks. Default: false.
-Jason
--
You 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
There has been much thought lately around build and release processes. See http://dev.clojure.org/display/design/Common+Contrib+Build The goal is to to have more libraries under the umbrella of contrib without requiring them to keep to the same release schedule. Each library can have its own release schedule and version numbers. The current clojure-contrib, the monolithic repository with 60+ modules, will be phased out. All 1.3.0-alpha* releases of the clojure-contrib module JARs are source-code-only (except for the 4 modules that require AOT) so they are compatible with any Clojure release. For example, you can use Clojure 1.3.0-alpha4 and org.clojure.contrib/logging 1.3.0-alpha3 in the same project. -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: Clojure 1.3 Alpha 4
On Tue, Dec 14, 2010 at 8:02 AM, Stuart Sierra the.stuart.sie...@gmail.com wrote: There has been much thought lately around build and release processes. See http://dev.clojure.org/display/design/Common+Contrib+Build Thanx. The goal is to to have more libraries under the umbrella of contrib without requiring them to keep to the same release schedule. Each library can have its own release schedule and version numbers. Makes sense (although it sounds like a recipe for confusion until the transition is completed - at 1.3.0 final, yes?). I suspect it will get easier - or at least look a little less confusing - when the current contrib libs actually do start having separate version numbers :) For example, you can use Clojure 1.3.0-alpha4 and org.clojure.contrib/logging 1.3.0-alpha3 in the same project. Is there an easy way to lookup whether a given lib has an alpha4 version (or, more generally, what the latest reasonably stable build is)? (should I take this to the -dev list?) -- Sean A Corfield -- (904) 302-SEAN Railo Technologies, Inc. -- http://getrailo.com/ An Architect's View -- http://corfield.org/ If you're not annoying somebody, you're not really alive. -- Margaret Atwood -- You 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
For now, you can just look at the repository at http://build.clojure.org/releases/org/clojure/ Once we get automated releases from Hudson/Maven (real soon now) the JARs will be deployed to the Maven Central repository, where they will be automatically indexed by search engines like jarvana.com. -S On Tuesday, December 14, 2010 4:27:21 PM UTC-5, seancorfield wrote: Is there an easy way to lookup whether a given lib has an alpha4 version (or, more generally, what the latest reasonably stable build is)? -- You 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
(defn fact [n] (reduce * (range 1 (inc n (fact 100) This produces the right result on 1.2 but ArithmeticException integer overflow on 1.3-alpha4. Is this intentional? -- You 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 14, 6:30 pm, Miki miki.teb...@gmail.com wrote: (defn fact [n] (reduce * (range 1 (inc n (fact 100) This produces the right result on 1.2 but ArithmeticException integer overflow on 1.3-alpha4. Is this intentional? Primitive math is the default in 1.3 -- You 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
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). http://dev.clojure.org/display/doc/Enhanced+Primitive+Support On Dec 14, 5:36 pm, Brian Goslinga quickbasicg...@gmail.com wrote: On Dec 14, 6:30 pm, Miki miki.teb...@gmail.com wrote: (defn fact [n] (reduce * (range 1 (inc n (fact 100) This produces the right result on 1.2 but ArithmeticException integer overflow on 1.3-alpha4. Is this intentional? Primitive math is the default in 1.3 -- You 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
Of course, TANSTAAFL: the auto-promoting version of the functions will be slower than their primitive counterparts. On Dec 14, 6:23 pm, Benny Tsai benny.t...@gmail.com 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). http://dev.clojure.org/display/doc/Enhanced+Primitive+Support On Dec 14, 5:36 pm, Brian Goslinga quickbasicg...@gmail.com wrote: On Dec 14, 6:30 pm, Miki miki.teb...@gmail.com wrote: (defn fact [n] (reduce * (range 1 (inc n (fact 100) This produces the right result on 1.2 but ArithmeticException integer overflow on 1.3-alpha4. Is this intentional? Primitive math is the default in 1.3 -- You 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 8:23 PM, Benny Tsai benny.t...@gmail.com 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. -- You 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:04 PM, Ken Wesson kwess...@gmail.com wrote: On Tue, Dec 14, 2010 at 8:23 PM, Benny Tsai benny.t...@gmail.com 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. Best to read over the very, very long thread on the subject. 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 Dec 14, 8:04 pm, Ken Wesson kwess...@gmail.com wrote: On Tue, Dec 14, 2010 at 8:23 PM, Benny Tsai benny.t...@gmail.com 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. This topic has been discussed to death before on this group. Short version: Doing the right thing is actually harder than you might first think: methods in Java must choose between returning a primitive and returning in reference type. This means that you have to choose between fast primitive math or slow reference type math. To advance the goal of writing Clojure in Clojure, it is necessary for it be easy to write high-performance Clojure code (although you might not care about how hard photosynthesis is, the plants do). Since it is generally the case that longs are sufficient for most purposes and it generally known ahead of time when they are not (Project Euler problems for example), primitive math is being made default in 1.3 Another change in 1.3 is that BigInteger math will not auto-reduce and will be contagious. This means that the prime versions of operations (+', -', etc.) are almost never necessary as one can use a BigInteger literal to ensure the operation will not overflow. Your example will work correctly if you change 1 to 1N. (Since java.lang.BigInteger is slow on small numbers, clojure.lang.BigInt is also being introduced (which is the type of 1N) that should be as fast as math was in 1.2 when the numbers fit into a long) For better or worse (hopefully for better), Clojure is increasingly adopting C++'s philosophy of pay for what you need. -- You 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 dnolen.li...@gmail.com wrote: On Tue, Dec 14, 2010 at 9:04 PM, Ken Wesson kwess...@gmail.com wrote: On Tue, Dec 14, 2010 at 8:23 PM, Benny Tsai benny.t...@gmail.com 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. :) -- You 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 10:02 PM, Brian Goslinga quickbasicg...@gmail.com wrote: This topic has been discussed to death before on this group. If so, it was before I joined. Doing the right thing is actually harder than you might first think But it's also already being done by Clojure 1.2 so I don't see how that's relevant. If someone proposed a novel behavior, it being harder than you might first think would be a point against that proposal. However it cannot logically ever be a point against keeping current behavior. -- You 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 14, 2010, at 9:26 PM, Ken Wesson wrote: On Tue, Dec 14, 2010 at 10:02 PM, Brian Goslinga quickbasicg...@gmail.com wrote: This topic has been discussed to death before on this group. If so, it was before I joined. That's what archives are for: http://groups.google.com/group/clojure/search?group=clojureq=primitive+math See in particular the threads Enhanced primitive support and Enhanced primitive support - redux. Doing the right thing is actually harder than you might first think But it's also already being done by Clojure 1.2 so I don't see how that's relevant. If someone proposed a novel behavior, it being harder than you might first think would be a point against that proposal. However it cannot logically ever be a point against keeping current behavior. Are you saying that simplifying existing code provides no benefit? -- You 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 14, 9:24 pm, Ken Wesson kwess...@gmail.com wrote: Breaking source compatibility with just about every single preexisting line of Clojure code out there is supposed to make our lives *easier*? Actually, it appears that the majority of the lines of code out there use integers that fit inside a long, so the change doesn't affect them. On Dec 14, 9:26 pm, Ken Wesson kwess...@gmail.com wrote: But it's also already being done by Clojure 1.2 so I don't see how that's relevant. If someone proposed a novel behavior, it being harder than you might first think would be a point against that proposal. However it cannot logically ever be a point against keeping current behavior. There exists a difference in the behavior of primitive and reference type math in 1.2; Clojure 1.3 will unify the behavior of the two. The auto promoting operators need to return an Object currently even if they take in primitives because the operation might overflow. This means that the auto promoting operators are incompatible with fast math (blame the JVM). It would be nice if there wasn't a trade-off to make, but there is one. -- You 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 6:04 PM, Ken Wesson kwess...@gmail.com wrote: On Tue, Dec 14, 2010 at 8:23 PM, Benny Tsai benny.t...@gmail.com 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. Search the archives for enhanced primitive support. There was a big battle back in June. People like you and me, who don't want to have to think about whether their code might crash with certain inputs from arithmetic overflow, lost the battle to those who want to get more speed out of Clojure without having to specifically annotate tight loops with special primitive math ops. The theory is that most programs work perfectly fine with longs. If yours doesn't, you'll hopefully find out when it throws an error, and go annotate your code accordingly. In exchange, Clojure will supposedly get faster for the common case. 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. It will be interesting to see how this all shakes out -- whether there are more ways to exploit the default of primitive math for better speed, and whether people still like the new direction after trying it more. -- You 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 7:02 PM, Brian Goslinga quickbasicg...@gmail.comwrote: (Since java.lang.BigInteger is slow on small numbers, clojure.lang.BigInt is also being introduced (which is the type of 1N) that should be as fast as math was in 1.2 when the numbers fit into a long) AFAIK, this hasn't been done yet, and clojure.lang.BigInt is just a stub that is as slow as java.lang.BigInteger. Is this correct? -- You 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 10:37 PM, Michael Gardner gardne...@gmail.com wrote: On Dec 14, 2010, at 9:26 PM, Ken Wesson wrote: On Tue, Dec 14, 2010 at 10:02 PM, Brian Goslinga quickbasicg...@gmail.com wrote: This topic has been discussed to death before on this group. If so, it was before I joined. That's what archives are for Are you honestly suggesting I search the archives for every word of every thought that it ever occurs to me to post here? I don't have that kind of time and I doubt anyone else does. If anyone started to actually enforce such a rule, participation here would drop to practically zero overnight. Doing the right thing is actually harder than you might first think But it's also already being done by Clojure 1.2 so I don't see how that's relevant. If someone proposed a novel behavior, it being harder than you might first think would be a point against that proposal. However it cannot logically ever be a point against keeping current behavior. Are you saying that simplifying existing code provides no benefit? If it breaks existing client code then yes. Simplifying internals without altering API semantics is generally a good thing; when the API semantics start changing, though, an unequivocal improvement becomes a tradeoff that might tip either way. Changing the behavior of arithmetic operators that are found in virtually every extant source file is going to have a very big downside in broken backward compatibility. If there's an upside, it would have to be staggeringly enormous to make such a change worthwhile. -- You 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 10:57 PM, Brian Goslinga quickbasicg...@gmail.com wrote: On Dec 14, 9:24 pm, Ken Wesson kwess...@gmail.com wrote: Breaking source compatibility with just about every single preexisting line of Clojure code out there is supposed to make our lives *easier*? Actually, it appears that the majority of the lines of code out there use integers that fit inside a long, so the change doesn't affect them. You could as well argue that dosync be changed to simply lock all the things that are altered or assured instead of doing the whole STM thing. Most things wouldn't break ... but a few things would, with the odd deadlock here and there. And that too would simplify the implementation. A lot. There exists a difference in the behavior of primitive and reference type math in 1.2; Clojure 1.3 will unify the behavior of the two. The auto promoting operators need to return an Object currently even if they take in primitives because the operation might overflow. This means that the auto promoting operators are incompatible with fast math (blame the JVM). But we have the unchecked-foo operators for when we need fast math. We have the longer, more awkward name in the rare case and plain old +, -, etc. in the common case. Now you're proposing to reverse that. 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. -- You 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 Wed, Dec 15, 2010 at 12:22 AM, Ken Wesson kwess...@gmail.com wrote: Are you honestly suggesting I search the archives for every word of every thought that it ever occurs to me to post here? With all due respect, the topic has already been bike shedded into the ground by many members in the community. Which isn't to say you don't have a valid point, but that ground has already been covered at great, great length. If you want to know why the decision was made read the thread. If you don't want to read the thread, well there's not much too talk about that hasn't been talked about before. Such decisions aren't not made lightly and it would be fair to at least go read what Rich Hickey had to say on the matter. 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 Wed, Dec 15, 2010 at 12:38 AM, David Nolen dnolen.li...@gmail.com wrote: On Wed, Dec 15, 2010 at 12:22 AM, Ken Wesson kwess...@gmail.com wrote: Are you honestly suggesting I search the archives for every word of every thought that it ever occurs to me to post here? With all due respect, the topic has already been bike shedded into the ground by many members in the community. Fascinating. Your point being? That statement of yours does not, after all, magically make searching the archive for every word in every post you ever think of posting suddenly become practical. -- You 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 Wed, Dec 15, 2010 at 12:50 AM, Ken Wesson kwess...@gmail.com wrote: On Wed, Dec 15, 2010 at 12:38 AM, David Nolen dnolen.li...@gmail.com wrote: On Wed, Dec 15, 2010 at 12:22 AM, Ken Wesson kwess...@gmail.com wrote: Are you honestly suggesting I search the archives for every word of every thought that it ever occurs to me to post here? With all due respect, the topic has already been bike shedded into the ground by many members in the community. Fascinating. Your point being? That statement of yours does not, after all, magically make searching the archive for every word in every post you ever think of posting suddenly become practical. I wasn't suggesting you do that. People earlier in the post gave links to the thread. 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 Dec 14, 2010, at 11:22 PM, Ken Wesson wrote: On Tue, Dec 14, 2010 at 10:37 PM, Michael Gardner gardne...@gmail.com wrote: That's what archives are for Are you honestly suggesting I search the archives for every word of every thought that it ever occurs to me to post here? I don't have that kind of time and I doubt anyone else does. If anyone started to actually enforce such a rule, participation here would drop to practically zero overnight. That's a mighty fine straw man you have there. And how deftly you knock it down! Are you saying that simplifying existing code provides no benefit? If it breaks existing client code then yes. Simplifying internals without altering API semantics is generally a good thing; when the API semantics start changing, though, an unequivocal improvement becomes a tradeoff that might tip either way. Changing the behavior of arithmetic operators that are found in virtually every extant source file is going to have a very big downside in broken backward compatibility. If there's an upside, it would have to be staggeringly enormous to make such a change worthwhile. The claim I responded to was: it cannot logically ever be a point against keeping current behavior. You are now arguing a much weaker claim, that the upside of simplifying existing code is unlikely to outweigh the drawbacks of breaking existing code. -- You 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
Maybe clojure should adopt linux versioning scheme, where even numbers are stable production clojure and odd numbers are development branch ? On Dec 12, 7:09 pm, Stuart Halloway stuart.hallo...@gmail.com wrote: Clojure 1.3 Alpha 2 is now available at http://clojure.org/downloads 0 Changes from 1.3 Alpha 3 to 1.3 Alpha 4 1 Changes from 1.3 Alpha 2 to 1.3 Alpha 3 2 Changes from 1.3 Alpha 1 to 1.3 Alpha 2 3 Changes from 1.2 to 1.3 Alpha 1 4 About Alpha Releases = 0 Changes from 1.3 Alpha 3 to 1.3 Alpha 4 * normalized unchecked-* fn names * added *unchecked-math* support * fixes to binding conveyance (and *agent*) = 1 Changes from 1.3 Alpha 2 to 1.3 Alpha 3 * fixed filter performance issue introduced in 1.3A2 * with-redefs macro (useful for stubbing) * print-table = 2 Changes from 1.3 Alpha 1 to 1.3 Alpha 2 * code path for using vars is now *much* faster for the common case, and you must explicitly ask for :dynamic bindability * new: clojure.reflect/reflect http://dev.clojure.org/display/design/Reflection+API * new: clojure.data/diff = 3 Changes from 1.2 to 1.3 Alpha 1 * enhanced primitive support (http://dev.clojure.org/display/doc/Enhanced+Primitive+Support) * better exception reporting * ancillary namespaces no longer auto-load on startup: clojure.set, clojure.xml, clojure.zip = 4 About Alpha Releases 1.3 is the first release of Clojure that will include a series of alpha builds. We are adding these builds to support maven and leiningen users, who want a specific artifact that they can target (as opposed to building from master or moving-target snapshots). If you are the kind of person who used to track master by building from source, but no longer do so because you are using maven or leiningen, alpha releases are for you. -- You 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 Sun, Dec 12, 2010 at 7:09 PM, Stuart Halloway stuart.hallo...@gmail.com wrote: Clojure 1.3 Alpha 2 is now available at http://clojure.org/downloads ...and via Leiningen as: [org.clojure/clojure 1.3.0-alpha4] which leads me to ask: Has there been any thought to making simultaneous clojure/contrib releases to make it easier for folks using lein / mvn to just update their deps for all org.clojure entries at the same time? -- Sean A Corfield -- (904) 302-SEAN Railo Technologies, Inc. -- http://getrailo.com/ An Architect's View -- http://corfield.org/ If you're not annoying somebody, you're not really alive. -- Margaret Atwood -- You 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
Vagif Verdi vagif.ve...@gmail.com wrote: Maybe clojure should adopt linux versioning scheme, where even numbers are stable production clojure and odd numbers are development branch ? Gods please no. -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -- You 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 14, 2:27 am, Vagif Verdi vagif.ve...@gmail.com wrote: Maybe clojure should adopt linux versioning scheme, where even numbers are stable production clojure and odd numbers are development branch ? AFAICT this will seriously affect Maven/Lein/Cake transitive dependency management when dealing with version-ranges. Regards, Shantanu On Dec 12, 7:09 pm, Stuart Halloway stuart.hallo...@gmail.com wrote: Clojure 1.3 Alpha 2 is now available at http://clojure.org/downloads 0 Changes from 1.3 Alpha 3 to 1.3 Alpha 4 1 Changes from 1.3 Alpha 2 to 1.3 Alpha 3 2 Changes from 1.3 Alpha 1 to 1.3 Alpha 2 3 Changes from 1.2 to 1.3 Alpha 1 4 About Alpha Releases = 0 Changes from 1.3 Alpha 3 to 1.3 Alpha 4 * normalized unchecked-* fn names * added *unchecked-math* support * fixes to binding conveyance (and *agent*) = 1 Changes from 1.3 Alpha 2 to 1.3 Alpha 3 * fixed filter performance issue introduced in 1.3A2 * with-redefs macro (useful for stubbing) * print-table = 2 Changes from 1.3 Alpha 1 to 1.3 Alpha 2 * code path for using vars is now *much* faster for the common case, and you must explicitly ask for :dynamic bindability * new: clojure.reflect/reflect http://dev.clojure.org/display/design/Reflection+API * new: clojure.data/diff = 3 Changes from 1.2 to 1.3 Alpha 1 * enhanced primitive support (http://dev.clojure.org/display/doc/Enhanced+Primitive+Support) * better exception reporting * ancillary namespaces no longer auto-load on startup: clojure.set, clojure.xml, clojure.zip = 4 About Alpha Releases 1.3 is the first release of Clojure that will include a series of alpha builds. We are adding these builds to support maven and leiningen users, who want a specific artifact that they can target (as opposed to building from master or moving-target snapshots). If you are the kind of person who used to track master by building from source, but no longer do so because you are using maven or leiningen, alpha releases are for you. -- You 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
Clojure 1.3 Alpha 4
Clojure 1.3 Alpha 2 is now available at http://clojure.org/downloads 0 Changes from 1.3 Alpha 3 to 1.3 Alpha 4 1 Changes from 1.3 Alpha 2 to 1.3 Alpha 3 2 Changes from 1.3 Alpha 1 to 1.3 Alpha 2 3 Changes from 1.2 to 1.3 Alpha 1 4 About Alpha Releases = 0 Changes from 1.3 Alpha 3 to 1.3 Alpha 4 * normalized unchecked-* fn names * added *unchecked-math* support * fixes to binding conveyance (and *agent*) = 1 Changes from 1.3 Alpha 2 to 1.3 Alpha 3 * fixed filter performance issue introduced in 1.3A2 * with-redefs macro (useful for stubbing) * print-table = 2 Changes from 1.3 Alpha 1 to 1.3 Alpha 2 * code path for using vars is now *much* faster for the common case, and you must explicitly ask for :dynamic bindability * new: clojure.reflect/reflect http://dev.clojure.org/display/design/Reflection+API * new: clojure.data/diff = 3 Changes from 1.2 to 1.3 Alpha 1 * enhanced primitive support (http://dev.clojure.org/display/doc/Enhanced+Primitive+Support) * better exception reporting * ancillary namespaces no longer auto-load on startup: clojure.set, clojure.xml, clojure.zip = 4 About Alpha Releases 1.3 is the first release of Clojure that will include a series of alpha builds. We are adding these builds to support maven and leiningen users, who want a specific artifact that they can target (as opposed to building from master or moving-target snapshots). If you are the kind of person who used to track master by building from source, but no longer do so because you are using maven or leiningen, alpha releases are for you. -- You 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
