On Sunday, October 23, 2011 5:21:52 PM UTC-4, Rich Hickey wrote:
>
> Hi all,
>
> This reply is to the thread, not Luc specifically.
>
> Thanks everyone for your feedback and input.
>
> I have pushed 3 commits:
>
> 1) Fixes the inconsistency between the hash function used by Clojure maps
> (was .
You can't jump around at a per-commit level (unless there's one build for
each commit) but you can jump around among individual builds.
You can see a list of all completed builds on our Hudson server:
http://build.clojure.org/view/Clojure/job/clojure/
The "module builds" pages show the Git commi
;; lein for all 3 commits
[org.clojure/clojure "1.4.0-master-20111023.210239-5"]
and I imagine you can do something similar with maven, the main thing
is you need to add the sonatype snapshot repo.
but you can't access individual commits because the build machine
polls and gathers the latest comm
How can people toggle between the various commits I mentioned using Maven?
Rich
On Oct 23, 2011, at 9:52 PM, Stuart Sierra wrote:
> As a reminder, you don't need Git to use the latest development version of
> Clojure. Just set your Clojure dependency version to "1.4.0-master-SNAPSHOT"
> and ad
As a reminder, you don't need Git to use the latest development version of
Clojure. Just set your Clojure dependency version to "1.4.0-master-SNAPSHOT"
and add Sonatype to your Maven repositories.
Detailed instructions here:
http://dev.clojure.org/display/doc/Maven+Settings+and+Repositories
-S
Hi all,
This reply is to the thread, not Luc specifically.
Thanks everyone for your feedback and input.
I have pushed 3 commits:
1) Fixes the inconsistency between the hash function used by Clojure maps (was
.hashCode) and =. Thanks Paul for the report.
2) Changes core/hash to return the resu
On Sun, Oct 23, 2011 at 4:01 PM, Luc Prefontaine <
lprefonta...@softaddicts.ca> wrote:
> It's simpler to use one representation to port the core. You can choose the
> fastest/efficient one. You do not have to carry all these intermediate
> types
> with you.
>
There are already at least two numeri
On Sun, 23 Oct 2011 20:31:51 +0200
Ivan Koblik wrote:
> Hello Luc,
>
> In all fairness I don't see how converting ints to Integers returned
> by class methods would break the abstraction. If you start talking
> about portability of Clojure code, then Long is as portable as
> Integer is. (In ge
Hello Luc,
In all fairness I don't see how converting ints to Integers returned by
class methods would break the abstraction. If you start talking about
portability of Clojure code, then Long is as portable as Integer is. (In
general they are not.)
Could you explain your position on the fact that
CON1 - I'm buying your argumentation about consistency in Clojure maps and
fixing them. Integer OBJECTS (as opposed to int primitive) should be
handle as objects consistenly, not as primitive values promoted to long.
CON2, CON3 and CON4 - No way, the current design choice is the good one.
So man
On Sat, Oct 22, 2011 at 5:51 PM, Stuart Halloway
wrote:
> I am dropping off this thread now. At this point I think it would be more
> useful for me (or someone) to expand the notes about numerics into better
> documentation, rather than continuing this rambling point-by-point treatment
> without
On Sat, Oct 22, 2011 at 7:53 PM, Luc Prefontaine <
lprefonta...@softaddicts.ca> wrote:
>
> Ha ! Ok, I missed the digression here and I now understand the issue.
> Considering that a PersistentArrayMap may eventually become a
> PersistentHashMap
> this opens the door to *funny* bugs.
>
> Is this th
Ha ! Ok, I missed the digression here and I now understand the issue.
Considering that a PersistentArrayMap may eventually become a PersistentHashMap
this opens the door to *funny* bugs.
Is this the only known case ?
Luc
On Sat, 22 Oct 2011 18:55:52 -0400
Paul Stadig wrote:
> On Sat, Oct 22,
On Sat, Oct 22, 2011 at 5:42 PM, Luc Prefontaine <
lprefonta...@softaddicts.ca> wrote:
> What's missing from your shortened example ?
>
I think what you want is the example I posted originally:
user=> (get {(Long. -1) :here} (Integer. -1))
:here
That works fine because you are actually creating
> Note that I'm not claiming to have any deep insights into what's broken and
> what's not, either in Clojure or in Java. All I'm saying is that claiming
> anything along the lines of "Clojure is not Java, so we can do whatever we
> want - contracts do not apply" does not lead to sane map behavi
Your example is so short that I cannot replicate it:
user=> (def a (hash-map -1 :a))
#'user/a
user=> (def b (array-map -1 :a))
#'user/b
user=> (= a b)
true
user=> (= (key (first a)) (key (first b)) -1)
true
I said to myself, "Ok he's been throwing some ints in there":
user=> (def a (hash-map (in
On Saturday, October 22, 2011 4:31:29 PM UTC-4, Luc wrote:
>
> Where's the contract breach here ?
>
Glad you asked. Consider the following clojure session (1.3), shortened for
your reading pleasure:
map-1 => {-1 :yo}
map-2 => {-1 :yo}
key-1 => -1
key-2 => -1
Just some simple maps and val
The contract in Clojure is clear, they are only long integer values except if
you cast
them accordingly for Java interop purposes. Anything else is a long so there
are no
contract breaches.
It's not a platform issue, it's a Java issue. Equality is implemented by Java
for objects.
It has nothin
Luc,
On Sat, Oct 22, 2011 at 3:40 PM, Luc Prefontaine <
lprefonta...@softaddicts.ca> wrote:
> All the contracts you mention are language centric, each of them defined
> their contract according
> to their own needs. Clojure should have the right to do so.
>
The contract is required for implement
a) Clojure does not to implement Integer, Byte, ... or any of the number
related Java classes.
It uses native JVM data types. The Integer class has nothing to do with the
JVM primitive types.
These are Java concepts. It has nothing to do with Clojure itself. It's
alien stuff.
Dunno why
On Sat, Oct 22, 2011 at 1:49 PM, Luc Prefontaine <
lprefonta...@softaddicts.ca> wrote:
>
> Java != JVM.
>
> That's a too common mistake. Integer vs Long, Byte, ... are Java creations.
> They have nothing to do with the JVM primitive data types.
>
> Clojure implements a semantic different than Java
Java != JVM.
That's a too common mistake. Integer vs Long, Byte, ... are Java creations.
They have nothing to do with the JVM primitive data types.
Clojure implements a semantic different than Java on top of the JVM, why not ?
That's the whole idea of having the JVM around. Abstracting the metal
On Sat, Oct 22, 2011 at 9:48 AM, Chas Emerick wrote:
> If Clojure's primary objective were Java interop, I might agree with you.
> However, it's not, and it's bizarre to see someone argue that this is not
> broken:
>
> user=> (.equals (Integer. -1) (Long. -1))
> false
>
> Sure, not broken accord
If Clojure's primary objective were Java interop, I might agree with you.
However, it's not, and it's bizarre to see someone argue that this is not
broken:
user=> (.equals (Integer. -1) (Long. -1))
false
Sure, not broken according to the Java object model and its equality semantics,
but damn
On Wednesday, October 19, 2011 10:38:56 AM UTC-4, stuart@gmail.com
wrote:
>Integers and longs are going to be painful no matter what because they are
broken in Java, e.g.
It is incorrect to say that "Integers and longs...are broken in Java."
user=> (.hashCode (Integer. -1))
-1
user=> (.hash
Yea let's chat on IRC. I'll ping you when I see you online.
-Nathan
On Oct 21, 4:24 am, Stuart Halloway wrote:
> > Luc, what you're saying sounds to me like "this is the way it is so
> > deal with it". Can you give me some concrete code snippets showing why
> > it's better to box ints as Longs?
Perhaps I can clarify why the 1.3 behavior is confusing. For those who have
focused on issues like "primitives need to be boxed, therefore you get a
long" - I think you are missing Nathan's point. Here is what changed about
boxing in 1.3:
Clojure 1.2:
(class (Long/parseLong "1")) => java.la
Like Stu says, this conversation is going in circle.
"Concrete code examples" cannot be a replacement for consistent rules when
designing software and especially a prog. language.
Since the beginning of this thread, you have been exposed to two of these:
a) make collections consistent
b) make co
> Luc, what you're saying sounds to me like "this is the way it is so
> deal with it". Can you give me some concrete code snippets showing why
> it's better to box ints as Longs? Do you really think the following is
> at all intuitive?
>
> user=> (class (Integer/parseInt "1"))
> java.lang.Long
> u
On Fri, Oct 21, 2011 at 12:52 AM, nathanmarz wrote:
> user=> (class (Integer/parseInt "1"))
> java.lang.Long
(Integer/parseInt "1") returns an int - which Clojure promotes to long
(since it only has 64-bit primitives) and class takes an Object so
long is boxed to Long.
> user=> (class (Integer/v
Luc, what you're saying sounds to me like "this is the way it is so
deal with it". Can you give me some concrete code snippets showing why
it's better to box ints as Longs? Do you really think the following is
at all intuitive?
user=> (class (Integer/parseInt "1"))
java.lang.Long
user=> (class (In
The "weirdness" here is that you seem to confuse the Java context and the
Clojure
context. They are not the same. Clojure has to satisfy to performance and
consistency
criterias. It's a language of it's own, not a Java offspring.
user=> (class (Integer/parseInt "1"))
java.lang.Long
user=>
Int
Thanks Alan, that makes sense. This code example illustrates that
Clojure values can already be primitive ints:
user=> (let [i 1] (primitive-type i))
:long
user=> (let [i (Integer/parseInt "1")] (primitive-type i))
:int
So it appears that Clojure's behavior is case #2 from my last comment.
All I'
It is a Long object. Vars hold objects, so it has to be boxed.
However, if instead of def'ing it you immediately called some java
method that will accept either a primitive int or a primitive long, my
understanding is that Clojure would arrange for the int version to be
called, because no boxing wo
Now I'm confused. So when I do this:
(def i (Integer/parseInt "1"))
Is "i" a primitive int, a primitive long, or a Long object?
I was under the impression that it was a primitive int based on
Justin's test code, but when I run "(primitive-type i)" in the REPL it
tells me :object.
If "i" is a pr
On Thu, Oct 20, 2011 at 4:11 PM, nathanmarz wrote:
> I'm not sure we're arguing about the same thing. I think that Clojure
> only supporting 64 bit primitive arithmetic is fine, and I'm not
> proposing that it support 32 bit primitive arithmetic. The sole point
> of contention is what Clojure doe
So you propose this:
user=> (time (dotimes [i 1000] (let [ a (Integer. 1) b (Integer. 2)] (+ a
b
"Elapsed time: 31.14886 msecs"
nil
Instead of this:
user=> (time (dotimes [i 1000] (let [ a 1 b 2] (+ a b
"Elapsed time: 15.680386 msecs"
nil
Using a wrapper instead of a primitive
On Thu, Oct 20, 2011 at 1:11 PM, nathanmarz wrote:
> of contention is what Clojure does when it has to box a primitive int.
My understanding is that Clojure 1.3 has 64-bit primitives, i.e.,
longs and double. You only have a primitive int if you coerce the
value to int (for an interop call that ex
I'm not sure we're arguing about the same thing. I think that Clojure
only supporting 64 bit primitive arithmetic is fine, and I'm not
proposing that it support 32 bit primitive arithmetic. The sole point
of contention is what Clojure does when it has to box a primitive int.
I think this is orthogo
On Thu, Oct 20, 2011 at 12:45 PM, nathanmarz wrote:
> But Clojure is already inconsistent. ints and Integers in interop are
> treated differently. The only way to make Clojure consistent is to
> either:
as David said "Clojure now only has 64bit primitives".
an Integer is not a primitive, an int
On Thu, Oct 20, 2011 at 3:45 PM, nathanmarz wrote:
> But Clojure is already inconsistent. ints and Integers in interop are
> treated differently. The only way to make Clojure consistent is to
> either:
>
Clojure is consistent. Whether or not that makes *interop* easier or harder
is orthogonal.
But Clojure is already inconsistent. ints and Integers in interop are
treated differently. The only way to make Clojure consistent is to
either:
1. Box ints as Integers
2. Always convert Integers to Longs.
I'm not sure on the feasibility of #2.
I'm not trying to be obtuse, but I really don't see
Such a change would be make Clojure's numeric design inconsistent. You keep
saying that Clojure is changing the types - that's probably not the right
way to look at it.
It's a semantic change, Clojure now only has 64bit primitives - the same way
that JavaScript only has doubles.
Prior to the 1.3
Oops, I meant "Clojure should box primitive ints as Integers." :-)
On Oct 20, 12:15 pm, nathanmarz wrote:
> Thanks, that clarifies the behavior. Regardless though, at some point
> the "int" is becoming a "Long" which is a change of type. I'm arguing
> that Clojure should box primitive ints as L
Thanks, that clarifies the behavior. Regardless though, at some point
the "int" is becoming a "Long" which is a change of type. I'm arguing
that Clojure should box primitive ints as Longs.
Stu, I wouldn't say Clojure's behavior makes it "just work". For
example, if I obtained by number using Integ
Oops, I elided a little too much. Need a method with an Object signature to
distinguish Integer from int:
(definterface IPrimitiveTester
(getType [^int x])
(getType [^long x])
;; etc
(getType [^Object x]))
(deftype PrimitiveTester []
IPrimitiveTester
(getType [this ^int x] :int)
(g
Here's a quick proof using an interface-based primitive detector:
(definterface IPrimitiveTester
(getType [^int x])
(getType [^long x])
;; other types elided
)
(deftype PrimitiveTester []
IPrimitiveTester
(getType [this ^int x] :int)
(getType [this ^long x] :long)
;; other types e
On Thu, Oct 20, 2011 at 1:54 AM, nathanmarz wrote:
> Yes, I understand the behavior perfectly well. The primitive int gets
> converted to a Long immediately, as this code demonstrates:
>
> user=> (class (Integer/parseInt "5"))
> java.lang.Long
class is a clojure function that takes Objects, so th
We still have a sizable Java chunk here closely interacting with Clojure
and fully agree with #1 and #2.
Interop is environment specific and should not be driving the Clojure language
design.
Otherwise Clojure generics would have to "bend" to Java, CLR, JS and future
implementations in
other env
> Yes, I understand the behavior perfectly well. The primitive int gets
> converted to a Long immediately, as this code demonstrates:
>
> user=> (class (Integer/parseInt "5"))
> java.lang.Long
>
> The int isn't being "boxed" into a Long -- the type is being changed.
>
> I'm aware that I can "fix
Yes, I understand the behavior perfectly well. The primitive int gets
converted to a Long immediately, as this code demonstrates:
user=> (class (Integer/parseInt "5"))
java.lang.Long
The int isn't being "boxed" into a Long -- the type is being changed.
I'm aware that I can "fix" things by conver
On Wed, Oct 19, 2011 at 5:14 PM, nathanmarz wrote:
> Here's a code example illustrating the problem I'm having:
> https://gist.github.com/1300034 I've simplified it to the bare minimum
> necessary to illustrate the problem.
>
> Agree 100% that ints and longs are broken in Java. The hashcode/
> equ
Here's a code example illustrating the problem I'm having:
https://gist.github.com/1300034 I've simplified it to the bare minimum
necessary to illustrate the problem.
Agree 100% that ints and longs are broken in Java. The hashcode/
equality stuff is messed up. Clojure can try really hard to hide t
> Thanks. I read through that and it didn't quite answer my question. To
> me it seems more logical that:
>
> 1. Clojure defaults to longs when you create a new number (with a
> literal 0, 1, etc)
> 2. You can create ints by doing (int 0)
> 3. Clojure never changes the types of things you're using
On Tue, Oct 18, 2011 at 7:45 PM, nathanmarz wrote:
> Thanks. I read through that and it didn't quite answer my question. To
> me it seems more logical that:
>
> 1. Clojure defaults to longs when you create a new number (with a
> literal 0, 1, etc)
> 2. You can create ints by doing (int 0)
> 3. Clo
Thanks. I read through that and it didn't quite answer my question. To
me it seems more logical that:
1. Clojure defaults to longs when you create a new number (with a
literal 0, 1, etc)
2. You can create ints by doing (int 0)
3. Clojure never changes the types of things you're using
I find Cloju
233 messages long thread from June 2010,
http://groups.google.com/group/clojure/browse_thread/thread/c8c850595c91cc11/171cacba292a0583
David
On Tue, Oct 18, 2011 at 5:00 PM, nathanmarz wrote:
> Hey all,
>
> I recently started upgrading Storm to Clojure 1.3, and I ran into
> various issues due t
Hey all,
I recently started upgrading Storm to Clojure 1.3, and I ran into
various issues due to Clojure's treatment of integers and longs. In
particular, I have a situation like the following:
1. A Java object returns me an int. Let's call this value "v".
2. I put "v" into a map, and pass that m
58 matches
Mail list logo
