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
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-
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
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
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
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
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.
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
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
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
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
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
*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
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
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
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
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
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
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
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
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
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.
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.
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:
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
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
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
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
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
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
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
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'
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
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
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
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
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
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 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
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
(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
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
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
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 +',
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 +,
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'
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
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-
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
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:
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
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'
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,
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
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
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
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,
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
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
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
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
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
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
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
64 matches
Mail list logo
