Re: clojure-1.4.0.jar missing in ~/.m2
Guys, I need to thank you both. Now it works: :dependencies [ [org.clojure/clojure "1.4.0"] [colorize "0.1.1" :exclusions [org.clojure/clojure]] [noir-cljs "0.3.0"] [jayq "0.1.0-alpha1"] [fetch "0.1.0-alpha2"] [crate "0.1.0-alpha3"] [noir "1.3.0-beta2"] ] $ lein deps Copying 46 files to /home/bost/dev/webcli/lib $ lein repl REPL started; server listening on localhost port 19200 user=> (clojure-version) "1.4.0" Bost -- 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.4.0.jar missing in ~/.m2
On May 5, 2012, at 7:38 PM, Rostislav Svoboda wrote: > My guess is that any of the dependencies I defined in my project.clj contains >:dependencies [[org.clojure/clojure "1.3.0"] ... ] > so it overrides my [org.clojure/clojure "1.4.0"] If you have Leiningen 2, you can find the culprit like this: 659 $ lein2 deps :tree [colorize 0.1.1] [ordered 1.2.0] [org.clojure/clojure 1.2.1]<<<=== [org.clojure/algo.monads 0.1.0] [org.clojure/core.incubator 0.1.0] [org.clojure/core.unify 0.5.2] [org.clojure/math.combinatorics 0.0.1] [org.clojure/tools.macro 0.1.1] [swiss-arrows 0.1.0] [utilize 0.2.3] [joda-time 2.0] Then you can "exclude" it in the project.clj file: [[ordered "1.2.0" :exclusions [org.clojure/clojure]] However, the Leiningen printout only shows the first blocking dependency. Then you have to run it another time to find which next thing to exclude. None of this makes any sense to me, and I hope I never really need to understand it. I accept this pain as an offering to the Java gods. - Brian Marick, Artisanal Labrador Now working at http://path11.com Contract programming in Ruby and Clojure Occasional consulting on Agile -- 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.4.0.jar missing in ~/.m2
Rostislav Svoboda: > My guess is that any of the dependencies I defined in my project.clj contains >:dependencies [[org.clojure/clojure "1.3.0"] ... ] > so it overrides my [org.clojure/clojure "1.4.0"] You can exclude org.clojure/clojure for your dependencies: https://github.com/michaelklishin/monger/blob/master/project.clj#L23 I try to do it for most of http://clojurewerkz.org projects to not worry about something dragging Clojure 1.2 in, for example (all those projects are 1.3+). MK -- 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.4.0.jar missing in ~/.m2
On 6 May 2012 01:37, Kurt Harriger wrote: > When i first upgraded to clojure 1.4 i had a similar issue with lein not > downloading updated dependencies. It tirned out to be an invalid version > range dependency spec in midje that caused it to fail silently. Perhaps try > removing all other dependencies first and try again. Kurt, you are right: :dependencies [[org.clojure/clojure "1.4.0"] ; [noir-cljs "0.3.0"] ; [jayq "0.1.0-alpha1"] ; [fetch "0.1.0-alpha2"] ; [crate "0.1.0-alpha3"] ; [noir "1.3.0-beta2"] ] $ lein deps Downloading: org/clojure/clojure/1.4.0/clojure-1.4.0.jar from repository central at http://repo1.maven.org/maven2 Copying 1 file to /home/bost/dev/webcli/lib $ find ~/.m2/repository/org/clojure/clojure/ -name clojure-1.4.0.jar /home/bost/.m2/repository/org/clojure/clojure/1.4.0/clojure-1.4.0.jar but when I activate the dependencies again: :dependencies [[org.clojure/clojure "1.4.0"] [noir-cljs "0.3.0"] [jayq "0.1.0-alpha1"] [fetch "0.1.0-alpha2"] [crate "0.1.0-alpha3"] [noir "1.3.0-beta2"] ] I get: $ lein repl REPL started; server listening on localhost port 55066 user=> (clojure-version) "1.3.0" My guess is that any of the dependencies I defined in my project.clj contains :dependencies [[org.clojure/clojure "1.3.0"] ... ] so it overrides my [org.clojure/clojure "1.4.0"] Bost -- 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.4.0.jar missing in ~/.m2
On May 5, 2012, at 6:37 PM, Kurt Harriger wrote: > When i first upgraded to clojure 1.4 i had a similar issue with lein not > downloading updated dependencies. It tirned out to be an invalid version > range dependency spec in midje that caused it to fail silently. Perhaps try > removing all other dependencies first and try again. Note that Midje 1.4 (beta-2 just pushed today) has fixed this problem. - Brian Marick, Artisanal Labrador Now working at http://path11.com Contract programming in Ruby and Clojure Occasional consulting on Agile -- 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: new with clojure, need help!
On 06/05/12 00:51, Rostislav Svoboda wrote: i need a more basic guidence on how to install the nessecery plugins to eclipse, and what to do with them... eclipse IDE may look like a good idea but in the beginning it just increases the amount of work you need to do and troubles you need to overcome. Just start with the REPL and any reasonably simple text editor. Then, after you gain some skills, you may try to use eclipse with ccw, but the chances are high you gonna end up using "only" vim or emacs Bost Also if you're on ubuntu or something a pretty basic but nice setup would be simply gedit with an embedded terminal where your repl will be...personally that is what i do - keep things nice and simple...you may want to keep a second repl open for testing...it's up to you really...of course learning emacs or vim will benefit you in the long run... as an aside - have you had a look at clooj? It might be exactly what you need... Jim -- 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: [ANN] The "It starts to look like a real App", 1.2.0 release of the Clojure Namespace Browser (clj-ns-browser)
I put :dev-dependencies [[clj-ns-browser "1.2.0"]] to my project.clj and did: $ lein deps Copying 46 files to /home/bost/dev/webcli/lib [WARNING] Overriding profile: 'null' (source: pom) with new instance from source: pom [WARNING] Overriding profile: 'null' (source: pom) with new instance from source: pom [WARNING] Overriding profile: 'null' (source: pom) with new instance from source: pom Copying 29 files to /home/bost/dev/webcli/lib/dev $ lein repl REPL started; server listening on localhost port 27581 IllegalStateException escape-html already refers to: #'hiccup.core/escape-html in namespace: hiccup.page clojure.lang.Namespace.warnOrFailOnReplace (Namespace.java:88) clojure.core=> when I comment out the ; :dev-dependencies [[clj-ns-browser "1.2.0"]] then everything works as before Bost -- 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: new with clojure, need help!
> i need a more basic guidence on how to install the nessecery plugins > to eclipse, and what to do with them... eclipse IDE may look like a good idea but in the beginning it just increases the amount of work you need to do and troubles you need to overcome. Just start with the REPL and any reasonably simple text editor. Then, after you gain some skills, you may try to use eclipse with ccw, but the chances are high you gonna end up using "only" vim or emacs Bost -- 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.4.0.jar missing in ~/.m2
When i first upgraded to clojure 1.4 i had a similar issue with lein not downloading updated dependencies. It tirned out to be an invalid version range dependency spec in midje that caused it to fail silently. Perhaps try removing all other dependencies first and try again. -- 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.4.0.jar missing in ~/.m2
Hi, my project.clj contains :dependencies [[org.clojure/clojure "1.4.0"] [noir-cljs "0.3.0"] [jayq "0.1.0-alpha1"] [fetch "0.1.0-alpha2"] [crate "0.1.0-alpha3"] [noir "1.3.0-beta2"]] but 'lein deps' does not download any clojure-1.4.0.jar only clojure-1.3.0.jar and clojure-1.2.1.jar $ cd ~/.m2/repository/org/clojure/clojure/ $ find . -name clojure* ./1.3.0-alpha5/clojure-1.3.0-alpha5.pom ./1.3.0-alpha5/clojure-1.3.0-alpha5.pom.sha1 ./1.2.0/clojure-1.2.0.pom ./1.2.0/clojure-1.2.0.pom.sha1 ./1.3.0/clojure-1.3.0.jar.sha1 ./1.3.0/clojure-1.3.0.jar ./1.3.0/clojure-1.3.0.pom ./1.3.0/clojure-1.3.0.pom.sha1 ./1.4.0/clojure-1.4.0.pom ./1.4.0/clojure-1.4.0.pom.sha1 ./1.2.1/clojure-1.2.1.pom.sha1 ./1.2.1/clojure-1.2.1.pom ./1.2.1/clojure-1.2.1.jar does anyone know what am I missing? I tried both: Leiningen 2.0.0-preview3 Leiningen 1.7.1 thx Bost -- 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+ and JRebel
I'm attempting to start a swank-clojure session within a grails application. This part is easy and works fine. However, whenever I change a groovy class clojure does not see this change until I restart the jvm. I mucked around a bit with classlojure and pomegranate trying to figure out if I could shadow the default class loader to force clojure to relaod the groovy class files on demand, but at the moment it seems beyond me. I've heard of JRebel for reloading class files in an existing jvm and ran across a few posts where people have had success using JRebel to reload classes in clojure. I was able to get this to work with clojure 1.2.1 however I can't get it to work with clojure 1.3 or 1.4. The simplest reproducible test case I could think of was just to start the repl as follows: java -javaagent:/Applications/ZeroTurnaround/JRebel/jrebel.jar -cp lib/clojure-1.4.0.jar clojure.main -r JRebel: Starting logging to file: /Users/kurtharriger/var/jrebel.log [2012-05-05 16:19:40] [2012-05-05 16:19:40] # [2012-05-05 16:19:40] [2012-05-05 16:19:40] JRebel 4.6.2 (201205021440) [2012-05-05 16:19:40] (c) Copyright ZeroTurnaround OU, Estonia, Tartu. [2012-05-05 16:19:40] [2012-05-05 16:19:40] Over the last 1 days JRebel prevented [2012-05-05 16:19:40] at least 1 redeploys/restarts saving you about 0 hours. [2012-05-05 16:19:40] [2012-05-05 16:19:40] This product is licensed to Kurt Harriger (FullContact) [2012-05-05 16:19:40] until June 4, 2012 [2012-05-05 16:19:40] [2012-05-05 16:19:40] * [2012-05-05 16:19:40] Your license is about to EXPIRE! [2012-05-05 16:19:40] * [2012-05-05 16:19:40] [2012-05-05 16:19:40] This license will expire in 29 days and JRebel will [2012-05-05 16:19:40] stop working after that. Renew your license at: [2012-05-05 16:19:40] http://sales.zeroturnaround.com/?1338842936 [2012-05-05 16:19:40] [2012-05-05 16:19:40] The following plugins are disabled at the moment: [2012-05-05 16:19:40] * Apache MyFaces plugin (set -Drebel.myfaces_plugin=true to enable) [2012-05-05 16:19:40] Reloads JSF configuration and reconfigures managed beans. [2012-05-05 16:19:40] * Click plugin (set -Drebel.click_plugin=true to enable) [2012-05-05 16:19:40] Reloads menu.xml menu definitions of Apache Click projects. [2012-05-05 16:19:40] * JRuby Plugin (set -Drebel.jruby_plugin=true to enable) [2012-05-05 16:19:40] * Jersey plugin (set -Drebel.jersey_plugin=true to enable) [2012-05-05 16:19:40] Reloads Jersey configuration from Java annotations. [2012-05-05 16:19:40] * Oracle ADF Core plugin (set -Drebel.adf_core_plugin=true to enable) [2012-05-05 16:19:40] JRebel ADF Core Plugin [2012-05-05 16:19:40] * Oracle ADF Faces plugin (set -Drebel.adf_faces_plugin=true to enable) [2012-05-05 16:19:40] JRebel ADF Faces Plugin [2012-05-05 16:19:40] * Seam-Wicket plugin (set -Drebel.seam_wicket_plugin=true to enable) [2012-05-05 16:19:40] Integration with load time weaving seam annotations to wicket classes [2012-05-05 16:19:40] (-javaagent:) [2012-05-05 16:19:40] * WebObjects plugin (set -Drebel.webobjects_plugin=true to enable) [2012-05-05 16:19:40] WebObjects JRebel Plugin [2012-05-05 16:19:40] [2012-05-05 16:19:40] # [2012-05-05 16:19:40] Exception in thread "main" java.lang.ExceptionInInitializerError at clojure.main.(main.java:20) Caused by: java.lang.IllegalStateException: Attempting to call unbound fn: #'clojure.core/first, compiling:(clojure/core.clj:55) at clojure.lang.Compiler.analyzeSeq(Compiler.java:6462) at clojure.lang.Compiler.analyze(Compiler.java:6262) at clojure.lang.Compiler.access$100(Compiler.java:37) at clojure.lang.Compiler$DefExpr$Parser.parse(Compiler.java:518) at clojure.lang.Compiler.analyzeSeq(Compiler.java:6455) at clojure.lang.Compiler.analyze(Compiler.java:6262) at clojure.lang.Compiler.analyze(Compiler.java:6223) at clojure.lang.Compiler.eval(Compiler.java:6515) at clojure.lang.Compiler.load(Compiler.java:6952) at clojure.lang.RT.loadResourceScript(RT.java:359) at clojure.lang.RT.loadResourceScript(RT.java:350) at clojure.lang.RT.load(RT.java:429) at clojure.lang.RT.load(RT.java:400) at clojure.lang.RT.doInit(RT.java:436) at clojure.lang.RT.(RT.java:318) ... 1 more Caused by: java.lang.IllegalStateException: Attempting to call unbound fn: #'clojure.core/first at clojure.lang.Var$Unbound.throwArity(Var.java:43) at clojure.lang.AFn.invoke(AFn.java:39) at clojure.core$fn.doInvoke(core.clj:3999) at clojure.lang.RestFn.invoke(RestFn.java:490) at clojure.lang.Var.invoke(Var.java:431) at clojure.lang.AFn.applyToHelper(AFn.java:178) at clojure.lang.Var.applyTo(Var.java:532) at clojure.lang.Compiler.macroexpand1(Compiler.java:6366) at clojure.lang.Compiler.analyzeSeq(Compiler.java:6441) ... 15
Re: Difficulty understanding (new?) behavior of identical?
Fantastic Daniel. Your thorough analysis has cleared up my confusion. I see now
that Java is partly to blame for this idiosyncratic behavior.
Furthermore, I agree that this is a relatively unlikely use of 'identical?'.
Considering all of the usual concerns when comparing floating-point numbers,
this is probably not worth getting worked up about.
Thanks,
David Sletten
On May 5, 2012, at 5:14 PM, Daniel Solano Gómez wrote:
> On Sat May 5 16:43 2012, David Sletten wrote:
>> Thanks for your response Daniel. You explain WHAT is apparently
>> happening here. However, I am still struggling to understand WHY this
>> is the new behavior.
>
> Yes, this is indeed a valid question. I think the answer is that this
> particular behaviour is an unintended side effect of the performance
> optimizations introduced in Clojure 1.3. By refusing to box numeric
> primitives until it's absolutely necessary, the results are generally
> much better performance for arithmetic code.
>
>> The documentation for 'identical?' states: Tests if 2 arguments are
>> the same object. To me, (identical? x x) asks whether 2 references to
>> the same object (the referent of x) are identical. Clojure 1.4's
>> response suggests that in some cases, within a given scope, a local
>> can refer to 2 different things. To be charitable, this is a
>> counterintuitive result. It's obvious that (identical? (Double. x)
>> (Double. x)) should return false, but that's not what I'm asking. To
>> suggest that x is not identical to x (within the same scope where they
>> refer to the same thing) violates one of the most fundamental laws of
>> logic.
>
> Well, arguably, this is part of the unfortunate fallout of the JVM's
> disjoint type system between objects and primitives. The key thing to
> realise is that before Clojure 1.3, (let [x 2] …) resulted in x
> referring to an object that contains the value of 2. In Clojure 1.3 and
> newer, the x in (let [x 2] …) now refers to a primitive long with the
> value 2.
>
>> You give interpretations of what is happening under the covers in both
>> pre- and post-1.3 Clojure above. Your explanation appears to
>> correspond to the observed behavior, but how did you come to this
>> realization? Can you point me to where this issue is documented? I
>> don't find any clues in the Clojure literature.
>
> I don't think it's documented, not as such. I just happen to be
> familiar with a lot of implementation details.
>
>> I see the following example in _The Joy Of Clojure_ (pg. 71):
>> (let [x 'goat y x] (identical? x y)) => true
>>
>> As you point out, this is also the behavior with cached integers (-128
>> <= n < 127). However, the following does not make the issue any
>> clearer:
>> (let [x 123] (identical? x x)) => true
>
> As we have established, the JVM's cache kicks in for this.
>
>> (let [x 1234] (identical? x x)) => false
>
> This is outside the range of the cache, the boxed values of x are
> different.
>
>> (let [x 1234N] (identical? x x)) => true
>
> Here, you are explicitly creating a clojure.lang.BigInt, an object.
>>
>> (let [x 8.9M] (identical? x x)) => true
>> (let [x (Double. 8.9)] (identical? x x)) => true
>> (class 8.9) => java.lang.Double
>
> Again for these, you are explicitly creating objects.
>
>> Furthermore, in _Clojure Programming_ (pg. 433) the authors write:
>> [identical?] corresponds directly to == in Java. This is clearly not
>> true in the example I presented. This code will print 'true' in all 4
>> cases:
>>Double d1 = 8.9;
>>Double d2 = d1;
>>
>>double d3 = 8.9;
>>double d4 = d3;
>>
>>System.out.println(d1 == d1);
>>System.out.println(d1 == d2);
>>System.out.println(d3 == d3);
>>System.out.println(d3 == d4);
>>
>> Of course, looking at the source for 'identical?' vindicates what these
>> authors have written:
>> (defn identical? [x y]
>> (clojure.lang.Util/identical x y))
>>
>> In clojure.lang.Util:
>> static public boolean identical(Object k1, Object k2){
>>return k1 == k2;
>> }
>>
>> So apparently as far as Java is concerned, my example should return
>> 'true'. Therefore something must be occurring in the reader that
>> results in the explanation which you gave.
>
> Not quite, you get the same behaviour in Java if you have to autobox the
> values like Clojure does:
>
> public class Equals {
> static boolean eq(Object lhs, Object rhs) {
>return lhs == rhs;
> }
>
> public static void main(String[] args) {
>// prints true
>System.out.println(eq(1, 1));
>
>// prints true
>System.out.println(eq(127, 127));
>
>// prints false
>System.out.println(eq(128, 128));
> }
> }
>
>
>> To be fair, the Common Lisp standard seems goofy to me on this issue
>> too. The analogous operator is EQ, documented here:
>> http://www.lispworks.com/documentation/HyperSpec/Body/f_eq.htm
>>
>> Of note is the example below:
>> (let ((x 5)) (eq x x))
>> => true
>> OR=> false
>> This sta
Re: Difficulty understanding (new?) behavior of identical?
On Sat May 5 16:43 2012, David Sletten wrote:
> Thanks for your response Daniel. You explain WHAT is apparently
> happening here. However, I am still struggling to understand WHY this
> is the new behavior.
Yes, this is indeed a valid question. I think the answer is that this
particular behaviour is an unintended side effect of the performance
optimizations introduced in Clojure 1.3. By refusing to box numeric
primitives until it's absolutely necessary, the results are generally
much better performance for arithmetic code.
> The documentation for 'identical?' states: Tests if 2 arguments are
> the same object. To me, (identical? x x) asks whether 2 references to
> the same object (the referent of x) are identical. Clojure 1.4's
> response suggests that in some cases, within a given scope, a local
> can refer to 2 different things. To be charitable, this is a
> counterintuitive result. It's obvious that (identical? (Double. x)
> (Double. x)) should return false, but that's not what I'm asking. To
> suggest that x is not identical to x (within the same scope where they
> refer to the same thing) violates one of the most fundamental laws of
> logic.
Well, arguably, this is part of the unfortunate fallout of the JVM's
disjoint type system between objects and primitives. The key thing to
realise is that before Clojure 1.3, (let [x 2] …) resulted in x
referring to an object that contains the value of 2. In Clojure 1.3 and
newer, the x in (let [x 2] …) now refers to a primitive long with the
value 2.
> You give interpretations of what is happening under the covers in both
> pre- and post-1.3 Clojure above. Your explanation appears to
> correspond to the observed behavior, but how did you come to this
> realization? Can you point me to where this issue is documented? I
> don't find any clues in the Clojure literature.
I don't think it's documented, not as such. I just happen to be
familiar with a lot of implementation details.
> I see the following example in _The Joy Of Clojure_ (pg. 71):
> (let [x 'goat y x] (identical? x y)) => true
>
> As you point out, this is also the behavior with cached integers (-128
> <= n < 127). However, the following does not make the issue any
> clearer:
> (let [x 123] (identical? x x)) => true
As we have established, the JVM's cache kicks in for this.
> (let [x 1234] (identical? x x)) => false
This is outside the range of the cache, the boxed values of x are
different.
> (let [x 1234N] (identical? x x)) => true
Here, you are explicitly creating a clojure.lang.BigInt, an object.
>
> (let [x 8.9M] (identical? x x)) => true
> (let [x (Double. 8.9)] (identical? x x)) => true
> (class 8.9) => java.lang.Double
Again for these, you are explicitly creating objects.
> Furthermore, in _Clojure Programming_ (pg. 433) the authors write:
> [identical?] corresponds directly to == in Java. This is clearly not
> true in the example I presented. This code will print 'true' in all 4
> cases:
> Double d1 = 8.9;
> Double d2 = d1;
>
> double d3 = 8.9;
> double d4 = d3;
>
> System.out.println(d1 == d1);
> System.out.println(d1 == d2);
> System.out.println(d3 == d3);
> System.out.println(d3 == d4);
>
> Of course, looking at the source for 'identical?' vindicates what these
> authors have written:
> (defn identical? [x y]
> (clojure.lang.Util/identical x y))
>
> In clojure.lang.Util:
> static public boolean identical(Object k1, Object k2){
> return k1 == k2;
> }
>
> So apparently as far as Java is concerned, my example should return
> 'true'. Therefore something must be occurring in the reader that
> results in the explanation which you gave.
Not quite, you get the same behaviour in Java if you have to autobox the values
like Clojure does:
public class Equals {
static boolean eq(Object lhs, Object rhs) {
return lhs == rhs;
}
public static void main(String[] args) {
// prints true
System.out.println(eq(1, 1));
// prints true
System.out.println(eq(127, 127));
// prints false
System.out.println(eq(128, 128));
}
}
> To be fair, the Common Lisp standard seems goofy to me on this issue
> too. The analogous operator is EQ, documented here:
> http://www.lispworks.com/documentation/HyperSpec/Body/f_eq.htm
>
> Of note is the example below:
> (let ((x 5)) (eq x x))
> => true
> OR=> false
> This states that a conforming system may return either a true or a
> false value in this case. This doesn't make any more sense to me than
> what Clojure is doing, but all of the Common Lisp implementations I've
> tested (Allegro, Clozure, SBCL, CLISP) do return T as I expected.
So, in the end, the question is: is this a bug? I can't speak for the
rest of Clojure/dev on this, but I am guessing that it might not be
considered a bug. To be fair, it would be nice if your sample code
returned the intuitive answer. However, I think the main argument
against it being considered a bug would
Re: Difficulty understanding (new?) behavior of identical?
On May 5, 2012, at 3:06 PM, Daniel Solano Gómez wrote:
> On Sat May 5 14:53 2012, David Sletten wrote:
>> Can anyone explain this change?
>> (clojure-version) => "1.2.0"
>> (let [x 8.9] (identical? x x)) => true
>>
>> Compared to:
>> (clojure-version) => "1.4.0"
>> (let [x 8.9] (identical? x x)) => false
>
> Well, this is certainly an interesting phenomenon. What is happening
> here is part of Clojure's primitive optimisations introduced in Clojure
> 1.3.
>
> Before Clojure 1.3, the code:
>
> (let [x 8.9] (identical? x x))
>
> Roughly can be thought of expanding to something like:
>
> (let [x (Float. 8.9)] (identical? x x))
>
> Since x is an object, it is indeed identical to itself.
>
> In Clojure 1.3, the code could be thought of evaluating to something
> like:
>
> (let [x (float 8.9)] (identical? (Double. x) (Double. x)))
>
> The x remains unboxed, so that when it is passed to the function call,
> which presumably has no primitive-hinted forms, it much be boxed each
> time it is an argument, and the resulting objects are not identical.
>
> To see more of the same in action (in Clojure 1.3 and above):
>
> (let [x 127] (identical? x x)) ;=> true
> (let [x 128] (identical? x x)) ;=> false
>
> The JVM has an optimisation such that boxed versions of small integers
> get boxed to cached instances. However for integers with large enough
> magnitudes, the JVM produces new objects.
Thanks for your response Daniel. You explain WHAT is apparently happening here.
However, I am still struggling to understand WHY this is the new behavior.
The documentation for 'identical?' states: Tests if 2 arguments are the same
object. To me, (identical? x x) asks whether 2 references to the same object
(the referent of x) are identical. Clojure 1.4's response suggests that in some
cases, within a given scope, a local can refer to 2 different things. To be
charitable, this is a counterintuitive result. It's obvious that (identical?
(Double. x) (Double. x)) should return false, but that's not what I'm asking.
To suggest that x is not identical to x (within the same scope where they refer
to the same thing) violates one of the most fundamental laws of logic.
You give interpretations of what is happening under the covers in both pre- and
post-1.3 Clojure above. Your explanation appears to correspond to the observed
behavior, but how did you come to this realization? Can you point me to where
this issue is documented? I don't find any clues in the Clojure literature.
I see the following example in _The Joy Of Clojure_ (pg. 71):
(let [x 'goat y x] (identical? x y)) => true
As you point out, this is also the behavior with cached integers (-128 <= n <
127). However, the following does not make the issue any clearer:
(let [x 123] (identical? x x)) => true
(let [x 1234] (identical? x x)) => false
(let [x 1234N] (identical? x x)) => true
(let [x 8.9M] (identical? x x)) => true
(let [x (Double. 8.9)] (identical? x x)) => true
(class 8.9) => java.lang.Double
Furthermore, in _Clojure Programming_ (pg. 433) the authors write: [identical?]
corresponds directly to == in Java. This is clearly not true in the example I
presented. This code will print 'true' in all 4 cases:
Double d1 = 8.9;
Double d2 = d1;
double d3 = 8.9;
double d4 = d3;
System.out.println(d1 == d1);
System.out.println(d1 == d2);
System.out.println(d3 == d3);
System.out.println(d3 == d4);
Of course, looking at the source for 'identical?' vindicates what these authors
have written:
(defn identical? [x y]
(clojure.lang.Util/identical x y))
In clojure.lang.Util:
static public boolean identical(Object k1, Object k2){
return k1 == k2;
}
So apparently as far as Java is concerned, my example should return 'true'.
Therefore something must be occurring in the reader that results in the
explanation which you gave.
To be fair, the Common Lisp standard seems goofy to me on this issue too. The
analogous operator is EQ, documented here:
http://www.lispworks.com/documentation/HyperSpec/Body/f_eq.htm
Of note is the example below:
(let ((x 5)) (eq x x))
=> true
OR=> false
This states that a conforming system may return either a true or a false value
in this case. This doesn't make any more sense to me than what Clojure is
doing, but all of the Common Lisp implementations I've tested (Allegro,
Clozure, SBCL, CLISP) do return T as I expected.
David Sletten
--
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: Difficulty understanding (new?) behavior of identical?
On Sat May 5 14:53 2012, David Sletten wrote: > Can anyone explain this change? > (clojure-version) => "1.2.0" > (let [x 8.9] (identical? x x)) => true > > Compared to: > (clojure-version) => "1.4.0" > (let [x 8.9] (identical? x x)) => false Well, this is certainly an interesting phenomenon. What is happening here is part of Clojure's primitive optimisations introduced in Clojure 1.3. Before Clojure 1.3, the code: (let [x 8.9] (identical? x x)) Roughly can be thought of expanding to something like: (let [x (Float. 8.9)] (identical? x x)) Since x is an object, it is indeed identical to itself. In Clojure 1.3, the code could be thought of evaluating to something like: (let [x (float 8.9)] (identical? (Double. x) (Double. x))) The x remains unboxed, so that when it is passed to the function call, which presumably has no primitive-hinted forms, it much be boxed each time it is an argument, and the resulting objects are not identical. To see more of the same in action (in Clojure 1.3 and above): (let [x 127] (identical? x x)) ;=> true (let [x 128] (identical? x x)) ;=> false The JVM has an optimisation such that boxed versions of small integers get boxed to cached instances. However for integers with large enough magnitudes, the JVM produces new objects. I hope this clears things up. Sincerely, Daniel signature.asc Description: Digital signature
Difficulty understanding (new?) behavior of identical?
Can anyone explain this change? (clojure-version) => "1.2.0" (let [x 8.9] (identical? x x)) => true Compared to: (clojure-version) => "1.4.0" (let [x 8.9] (identical? x x)) => false Thanks. David Sletten -- 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: Data vs API
Thanks all, folks. Rich's video helped tremendously. The a-ha moment was the realization that the biggest reason to abstract data access in Java is the non-uniform built-in access to data: accessing fields in objects is different from hashmaps which is different from instance access which is different from static data. Clojure's uniformity neatly solves that problem. As I'm getting more familiar with destructuring and Clojure's polymorphism, I realize that I was anticipating more of a problem with fluid data structures than they turn out to be. -- 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
