On Thu, Dec 16, 2010 at 1:15 PM, Baishampayan Ghose wrote:
>>> yet you are accusing people of criticizing you just because they feel you
>>> should do a bit more
>>> research about this.
>>
>> I'm asking them to explain themselves better, and their responses are
>> not any kind of explanation.
>
> 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.
On Thu, Dec 16, 2010 at 1:06 PM, Ken Wesson wrote:
> I don't know how common dynamic binding is in application code. It
> tends to be in library code more often, which is a smaller number of
> changes to make. Plus, the dynamic binding changes have a rationale
> behind them that actually seems to
>> 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
expla
On Thu, Dec 16, 2010 at 12:24 PM, David Nolen wrote:
> On Thu, Dec 16, 2010 at 12:06 PM, Ken Wesson wrote:
>>
>> The overflow check is the same whether you react to an overflow by
>> boxing the result or react to an overflow by throwing an exception!
>
> It's not the same at all.
> If you box the
On Thu, Dec 16, 2010 at 12:22 PM, Baishampayan Ghose wrote:
>>> It takes almost zero time to offer opinions without bothering to check.
>>
>> That looks like yet another unproductive, non-constructive personal
>> criticism.
>
> Why do you think so?
Because of the implication that my opinions are
On Dec 16, 2010, at 11:19 AM, Ken Wesson wrote:
> On Thu, Dec 16, 2010 at 8:17 AM, Stuart Halloway
> wrote:
>> I wrote:
>>> Breaking source compatibility with just about every single preexisting
>>> line of Clojure code out there is supposed to make our lives *easier*?
>>> I'd dearly love to kno
On Thu, Dec 16, 2010 at 12:14 PM, nicolas.o...@gmail.com
wrote:
>>
>> The overflow check is the same whether you react to an overflow by
>> boxing the result or react to an overflow by throwing an exception!
>
> But then all the rest of the code has to check whether things are boxed or
> not.
> M
On Thu, Dec 16, 2010 at 12:13 PM, Stuart Halloway
wrote:
Worse, from the sounds of it the new + isn't exactly the old
unchecked-+; it still checks for overflow rather than allowing
wrapping. That's going to add a compare-and-branch to every add
instruction and halve the speed o
On Thu, Dec 16, 2010 at 12:06 PM, Ken Wesson wrote:
> The overflow check is the same whether you react to an overflow by
> boxing the result or react to an overflow by throwing an exception!
>
It's not the same at all.
If you box the result all further arithmetic computations slows down. You
ca
>> 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
de
*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
>
> 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 th
>>> 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-e
On Thu, Dec 16, 2010 at 12:04 PM, Stuart Halloway
wrote:
> I wrote:
>> On Thu, Dec 16, 2010 at 8:17 AM, Stuart Halloway
>> wrote:
>>> I wrote:
Breaking source compatibility with just about every single preexisting
line of Clojure code out there is supposed to make our lives *easier*?
>>
On Thu, Dec 16, 2010 at 11:36 AM, David Nolen wrote:
> On Thu, Dec 16, 2010 at 11:18 AM, Ken Wesson wrote:
>>
>> On Thu, Dec 16, 2010 at 8:13 AM, Stuart Halloway
>> wrote:
>> >> Worse, from the sounds of it the new + isn't exactly the old
>> >> unchecked-+; it still checks for overflow rather th
> On Thu, Dec 16, 2010 at 8:17 AM, Stuart Halloway
> wrote:
>> I wrote:
>>> Breaking source compatibility with just about every single preexisting
>>> line of Clojure code out there is supposed to make our lives *easier*?
>>> I'd dearly love to know how -- my cousin is a stage magician and he's
>>
On Thu, Dec 16, 2010 at 11:18 AM, Ken Wesson wrote:
> On Thu, Dec 16, 2010 at 8:13 AM, Stuart Halloway
> wrote:
> >> Worse, from the sounds of it the new + isn't exactly the old
> >> unchecked-+; it still checks for overflow rather than allowing
> >> wrapping. That's going to add a compare-and-b
> 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).
On Thu, Dec 16, 2010 at 8:17 AM, Stuart Halloway
wrote:
> I wrote:
>> Breaking source compatibility with just about every single preexisting
>> line of Clojure code out there is supposed to make our lives *easier*?
>> I'd dearly love to know how -- my cousin is a stage magician and he's
>> always
On Thu, Dec 16, 2010 at 8:13 AM, Stuart Halloway
wrote:
>> Worse, from the sounds of it the new + isn't exactly the old
>> unchecked-+; it still checks for overflow rather than allowing
>> wrapping. That's going to add a compare-and-branch to every add
>> instruction and halve the speed of those o
> 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 get
> On Tue, Dec 14, 2010 at 9:56 PM, David Nolen wrote:
>> On Tue, Dec 14, 2010 at 9:04 PM, Ken Wesson wrote:
>>>
>>> On Tue, Dec 14, 2010 at 8:23 PM, Benny Tsai wrote:
As Brian said, primitive math is now the default in 1.3. If auto-
promotion on overflow is desired, you can use the +
> 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 i
On Dec 15, 10:05 am, Ken Wesson wrote:
> On Wed, Dec 15, 2010 at 12:52 PM, Mike Meyer
>
> 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
On Wed, 15 Dec 2010 13:02:13 -0500
Ken Wesson wrote:
> On Wed, Dec 15, 2010 at 12:51 PM, Eric Schulte wrote:
> > Ken Wesson writes:
> >
> >> Are you honestly suggesting I search the archives
> >
> > It is common courtesy on open-source lists such as this one to check if
> > a question you are a
On Wed, Dec 15, 2010 at 1:12 PM, Eric Schulte wrote:
> Ken Wesson writes:
>
>> On Wed, Dec 15, 2010 at 12:51 PM, Eric Schulte
>> wrote:
>>> Ken Wesson writes:
>>>
Are you honestly suggesting I search the archives
>>>
>>> It is common courtesy on open-source lists such as this one to check
Ken Wesson writes:
> On Wed, Dec 15, 2010 at 12:51 PM, Eric Schulte wrote:
>> Ken Wesson writes:
>>
>>> Are you honestly suggesting I search the archives
>>
>> It is common courtesy on open-source lists such as this one to check if
>> a question you are about to ask has already been answered.
>
On Wed, Dec 15, 2010 at 12:52 PM, Mike Meyer
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
On Tue, 14 Dec 2010 21:04:11 -0500
Ken Wesson wrote:
> On Tue, Dec 14, 2010 at 8:23 PM, Benny Tsai wrote:
> > As Brian said, primitive math is now the default in 1.3. If auto-
> > promotion on overflow is desired, you can use the +', -', *', inc',
> > dec' functions (note the single quote suffi
On Wed, Dec 15, 2010 at 12:51 PM, Eric Schulte wrote:
> Ken Wesson writes:
>
>> Are you honestly suggesting I search the archives
>
> It is common courtesy on open-source lists such as this one to check if
> a question you are about to ask has already been answered.
As I believe I already mentio
Ken Wesson writes:
> Are you honestly suggesting I search the archives
It is common courtesy on open-source lists such as this one to check if
a question you are about to ask has already been answered. Not only
does it save a lot of noise on the list, but it often means that you
find your answe
On Wed, Dec 15, 2010 at 11:07 AM, 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
2010/12/15 Ken Wesson
> On Wed, Dec 15, 2010 at 1:11 AM, Michael Gardner
> wrote:
> > On Dec 14, 2010, at 11:22 PM, Ken Wesson wrote:
> >
> >> On Tue, Dec 14, 2010 at 10:37 PM, Michael Gardner
> wrote:
> >>> That's what archives are for
> >>
> >> Are you honestly suggesting I search the archive
On Wed, Dec 15, 2010 at 11:14 AM, Ken Wesson 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
On Wed, Dec 15, 2010 at 10:56 AM, Laurent PETIT 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:
>
> Davi
> 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
On Wed, Dec 15, 2010 at 1:11 AM, Michael Gardner wrote:
> On Dec 14, 2010, at 11:22 PM, Ken Wesson wrote:
>
>> On Tue, Dec 14, 2010 at 10:37 PM, Michael Gardner
>> wrote:
>>> That's what archives are for
>>
>> Are you honestly suggesting I search the archives for every word of
>> every thought t
On Wed, Dec 15, 2010 at 1:07 AM, David Nolen wrote:
> On Wed, Dec 15, 2010 at 12:50 AM, Ken Wesson wrote:
>>
>> On Wed, Dec 15, 2010 at 12:38 AM, David Nolen
>> wrote:
>> > On Wed, Dec 15, 2010 at 12:22 AM, Ken Wesson wrote:
>> >>
>> >> Are you honestly suggesting I search the archives for ever
On Dec 14, 2010, at 11:22 PM, Ken Wesson wrote:
> On Tue, Dec 14, 2010 at 10:37 PM, Michael Gardner 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 o
On Wed, Dec 15, 2010 at 12:50 AM, Ken Wesson wrote:
> On Wed, Dec 15, 2010 at 12:38 AM, David Nolen
> wrote:
> > On Wed, Dec 15, 2010 at 12:22 AM, Ken Wesson wrote:
> >>
> >> Are you honestly suggesting I search the archives for every word of
> >> every thought that it ever occurs to me to post
On Wed, Dec 15, 2010 at 12:38 AM, David Nolen wrote:
> On Wed, Dec 15, 2010 at 12:22 AM, Ken Wesson 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 s
On Wed, Dec 15, 2010 at 12:22 AM, Ken Wesson 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. Wh
On Tue, Dec 14, 2010 at 10:57 PM, Brian Goslinga
wrote:
> On Dec 14, 9:24 pm, Ken Wesson 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
On Tue, Dec 14, 2010 at 10:37 PM, Michael Gardner wrote:
> On Dec 14, 2010, at 9:26 PM, Ken Wesson wrote:
>
>> On Tue, Dec 14, 2010 at 10:02 PM, Brian Goslinga
>> wrote:
>>> This topic has been discussed to death before on this group.
>>
>> If so, it was before I joined.
>
> That's what archives
On Tue, Dec 14, 2010 at 7:02 PM, Brian Goslinga wrote:
> (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 y
On Tue, Dec 14, 2010 at 6:04 PM, Ken Wesson wrote:
> On Tue, Dec 14, 2010 at 8:23 PM, Benny Tsai wrote:
> > As Brian said, primitive math is now the default in 1.3. If auto-
> > promotion on overflow is desired, you can use the +', -', *', inc',
> > dec' functions (note the single quote suffix)
On Dec 14, 9:24 pm, Ken Wesson 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
On Dec 14, 2010, at 9:26 PM, Ken Wesson wrote:
> On Tue, Dec 14, 2010 at 10:02 PM, Brian Goslinga
> 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=clojur
On Tue, Dec 14, 2010 at 10:02 PM, Brian Goslinga
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 r
On Tue, Dec 14, 2010 at 9:56 PM, David Nolen wrote:
> On Tue, Dec 14, 2010 at 9:04 PM, Ken Wesson wrote:
>>
>> On Tue, Dec 14, 2010 at 8:23 PM, Benny Tsai wrote:
>> > As Brian said, primitive math is now the default in 1.3. If auto-
>> > promotion on overflow is desired, you can use the +', -',
On Dec 14, 8:04 pm, Ken Wesson wrote:
> On Tue, Dec 14, 2010 at 8:23 PM, Benny Tsai wrote:
> > As Brian said, primitive math is now the default in 1.3. If auto-
> > promotion on overflow is desired, you can use the +', -', *', inc',
> > dec' functions (note the single quote suffix).
>
> Why was
On Tue, Dec 14, 2010 at 9:04 PM, Ken Wesson wrote:
> On Tue, Dec 14, 2010 at 8:23 PM, Benny Tsai wrote:
> > As Brian said, primitive math is now the default in 1.3. If auto-
> > promotion on overflow is desired, you can use the +', -', *', inc',
> > dec' functions (note the single quote suffix)
On Tue, Dec 14, 2010 at 8:23 PM, Benny Tsai wrote:
> As Brian said, primitive math is now the default in 1.3. If auto-
> promotion on overflow is desired, you can use the +', -', *', inc',
> dec' functions (note the single quote suffix).
Why was this done? I preferred having +, -, etc. DTRT in g
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 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',
> de
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 wrote:
> On Dec 1
On Dec 14, 6:30 pm, Miki 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 a
(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
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.
On Tue, Dec 14, 2010 at 8:02 AM, Stuart Sierra
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
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
On Dec 14, 2:27 am, Vagif Verdi 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-ra
"Vagif Verdi" 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
On Sun, Dec 12, 2010 at 7:09 PM, Stuart Halloway
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
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 wrote:
> Clojure 1.3 Alpha 2 is now available at
>
> http://clojure.org/downloads
>
> 0 Changes from 1.3 Alpha
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 t
66 matches
Mail list logo
