defprotocol fails oddly in repl only
Whenever I do a defprotocol in the clojurescript repl, even a trivial one
like
(defprotocol IFoo
(foo [this]))
it fails with an error `Can't change/establish root binding of:
*unchecked-if* with set at line 1 '.
Everything else seems to work as expected.
When compiled outside the repl, such as in a running project, defprotocol
works fine.
This happens even in the bare bones cljs repl from following the Quickstart
recipe
on the cljs wiki exactly, using the latest cljs.jar. The complete
stacktrace is below
for reference.
This seems like a repl bug, but I'm open to other possibilities. Any
thoughts would
be appreciated.
cljs.user=> (defprotocol IFoo (foo [this]))
clojure.lang.ExceptionInfo: Can't change/establish root binding of:
*unchecked-if* with set at line 1 {:file "", :line
1, :column 1, :tag :cljs/analysis-error}
at clojure.core$ex_info.invokeStatic(core.clj:4617)
at cljs.analyzer$error.invokeStatic(analyzer.cljc:576)
at cljs.analyzer$analyze_seq_STAR__wrap.invokeStatic(analyzer.cljc:2420)
at cljs.analyzer$analyze_seq.invokeStatic(analyzer.cljc:2441)
at cljs.analyzer$analyze_form.invokeStatic(analyzer.cljc:2555)
at cljs.analyzer$analyze_STAR_.invokeStatic(analyzer.cljc:2600)
at cljs.analyzer$analyze.invokeStatic(analyzer.cljc:2617)
at cljs.analyzer$analyze.invoke(analyzer.cljc:2605)
at cljs.analyzer$analyze.invokeStatic(analyzer.cljc:2613)
at cljs.analyzer$analyze.invoke(analyzer.cljc:2605)
at cljs.analyzer$analyze.invokeStatic(analyzer.cljc:2612)
at cljs.analyzer$analyze.invoke(analyzer.cljc:2605)
at
cljs.analyzer$analyze_do_statements_STAR_$fn__1249.invoke(analyzer.cljc:1406)
at clojure.core$map$fn__4785.invoke(core.clj:2644)
at clojure.lang.LazySeq.sval(LazySeq.java:40)
at clojure.lang.LazySeq.seq(LazySeq.java:49)
at clojure.lang.RT.seq(RT.java:521)
at clojure.core$seq__4357.invokeStatic(core.clj:137)
at
cljs.analyzer$analyze_do_statements_STAR_.invokeStatic(analyzer.cljc:1405)
at cljs.analyzer$analyze_do_statements.invokeStatic(analyzer.cljc:1408)
at cljs.analyzer$fn__1254.invokeStatic(analyzer.cljc:1411)
at cljs.analyzer$fn__1254.invoke(analyzer.cljc:1411)
at clojure.lang.MultiFn.invoke(MultiFn.java:251)
at cljs.analyzer$analyze_seq_STAR_.invokeStatic(analyzer.cljc:2416)
at cljs.analyzer$analyze_seq_STAR__wrap.invokeStatic(analyzer.cljc:2419)
at cljs.analyzer$analyze_seq.invokeStatic(analyzer.cljc:2441)
at cljs.analyzer$analyze_form.invokeStatic(analyzer.cljc:2555)
at cljs.analyzer$analyze_STAR_.invokeStatic(analyzer.cljc:2600)
at cljs.analyzer$analyze.invokeStatic(analyzer.cljc:2617)
at cljs.analyzer$analyze.invoke(analyzer.cljc:2605)
at cljs.analyzer$analyze_seq.invokeStatic(analyzer.cljc:2443)
at cljs.analyzer$analyze_form.invokeStatic(analyzer.cljc:2555)
at cljs.analyzer$analyze_STAR_.invokeStatic(analyzer.cljc:2600)
at cljs.analyzer$analyze.invokeStatic(analyzer.cljc:2617)
at cljs.repl$evaluate_form.invokeStatic(repl.cljc:440)
at cljs.repl$eval_cljs.invokeStatic(repl.cljc:576)
at cljs.repl$eval_cljs.invoke(repl.cljc:563)
at cljs.repl$repl_STAR_$read_eval_print__4908.invoke(repl.cljc:875)
at cljs.repl$repl_STAR_$fn__4914$fn__4923.invoke(repl.cljc:914)
at cljs.repl$repl_STAR_$fn__4914.invoke(repl.cljc:913)
at cljs.compiler$with_core_cljs.invokeStatic(compiler.cljc:1154)
at cljs.repl$repl_STAR_.invokeStatic(repl.cljc:851)
at cljs.repl$repl.invokeStatic(repl.cljc:993)
at cljs.repl$repl.doInvoke(repl.cljc:925)
at clojure.lang.RestFn.invoke(RestFn.java:486)
at user$eval220.invokeStatic(repl.clj:10)
at user$eval220.invoke(repl.clj:10)
at clojure.lang.Compiler.eval(Compiler.java:6927)
at clojure.lang.Compiler.load(Compiler.java:7379)
at clojure.lang.Compiler.loadFile(Compiler.java:7317)
at clojure.main$load_script.invokeStatic(main.clj:275)
at clojure.main$script_opt.invokeStatic(main.clj:335)
at clojure.main$script_opt.invoke(main.clj:330)
at clojure.main$main.invokeStatic(main.clj:421)
at clojure.main$main.doInvoke(main.clj:384)
at clojure.lang.RestFn.invoke(RestFn.java:408)
at clojure.lang.Var.invoke(Var.java:379)
at clojure.lang.AFn.applyToHelper(AFn.java:154)
at clojure.lang.Var.applyTo(Var.java:700)
at clojure.main.main(main.java:37)
Caused by: java.lang.IllegalStateException: Can't change/establish root
binding of: *unchecked-if* with set
at clojure.lang.Var.set(Var.java:221)
at cljs.analyzer$fn__1299.invokeStatic(analyzer.cljc:1589)
at cljs.analyzer$fn__1299.invoke(analyzer.cljc:1578)
at clojure.lang.MultiFn.invoke(MultiFn.java:251)
at cljs.analyzer$analyze_seq_STAR_.invokeStatic(analyzer.cljc:2416)
at cljs.analyzer$analyze_seq_STAR__wrap.invokeStatic(analyzer.cljc:2419)
... 57 more
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send
defprotocol fails oddly in repl only
Whenever I do a defprotocol in the clojurescript repl, even a trivial one
like
(defprotocol IFoo
(foo [this]))
it fails with an error `Can't change/establish root binding of:
*unchecked-if* with set at line 1 '.
Everything else seems to work as expected.
When compiled outside the repl, such as in a running project, defprotocol
works fine.
This happens even in the bare bones cljs repl from following the Quickstart
recipe
on the cljs wiki exactly, using the latest cljs.jar. The complete
stacktrace is below
for reference.
This seems like a repl bug, but I'm open to other possibilities. Any
thoughts would
be appreciated.
cljs.user=> (defprotocol IFoo (foo [this]))
clojure.lang.ExceptionInfo: Can't change/establish root binding of:
*unchecked-if* with set at line 1 {:file "", :line
1, :column 1, :tag :cljs/analysis-error}
at clojure.core$ex_info.invokeStatic(core.clj:4617)
at cljs.analyzer$error.invokeStatic(analyzer.cljc:576)
at cljs.analyzer$analyze_seq_STAR__wrap.invokeStatic(analyzer.cljc:2420)
at cljs.analyzer$analyze_seq.invokeStatic(analyzer.cljc:2441)
at cljs.analyzer$analyze_form.invokeStatic(analyzer.cljc:2555)
at cljs.analyzer$analyze_STAR_.invokeStatic(analyzer.cljc:2600)
at cljs.analyzer$analyze.invokeStatic(analyzer.cljc:2617)
at cljs.analyzer$analyze.invoke(analyzer.cljc:2605)
at cljs.analyzer$analyze.invokeStatic(analyzer.cljc:2613)
at cljs.analyzer$analyze.invoke(analyzer.cljc:2605)
at cljs.analyzer$analyze.invokeStatic(analyzer.cljc:2612)
at cljs.analyzer$analyze.invoke(analyzer.cljc:2605)
at
cljs.analyzer$analyze_do_statements_STAR_$fn__1249.invoke(analyzer.cljc:1406)
at clojure.core$map$fn__4785.invoke(core.clj:2644)
at clojure.lang.LazySeq.sval(LazySeq.java:40)
at clojure.lang.LazySeq.seq(LazySeq.java:49)
at clojure.lang.RT.seq(RT.java:521)
at clojure.core$seq__4357.invokeStatic(core.clj:137)
at
cljs.analyzer$analyze_do_statements_STAR_.invokeStatic(analyzer.cljc:1405)
at cljs.analyzer$analyze_do_statements.invokeStatic(analyzer.cljc:1408)
at cljs.analyzer$fn__1254.invokeStatic(analyzer.cljc:1411)
at cljs.analyzer$fn__1254.invoke(analyzer.cljc:1411)
at clojure.lang.MultiFn.invoke(MultiFn.java:251)
at cljs.analyzer$analyze_seq_STAR_.invokeStatic(analyzer.cljc:2416)
at cljs.analyzer$analyze_seq_STAR__wrap.invokeStatic(analyzer.cljc:2419)
at cljs.analyzer$analyze_seq.invokeStatic(analyzer.cljc:2441)
at cljs.analyzer$analyze_form.invokeStatic(analyzer.cljc:2555)
at cljs.analyzer$analyze_STAR_.invokeStatic(analyzer.cljc:2600)
at cljs.analyzer$analyze.invokeStatic(analyzer.cljc:2617)
at cljs.analyzer$analyze.invoke(analyzer.cljc:2605)
at cljs.analyzer$analyze_seq.invokeStatic(analyzer.cljc:2443)
at cljs.analyzer$analyze_form.invokeStatic(analyzer.cljc:2555)
at cljs.analyzer$analyze_STAR_.invokeStatic(analyzer.cljc:2600)
at cljs.analyzer$analyze.invokeStatic(analyzer.cljc:2617)
at cljs.repl$evaluate_form.invokeStatic(repl.cljc:440)
at cljs.repl$eval_cljs.invokeStatic(repl.cljc:576)
at cljs.repl$eval_cljs.invoke(repl.cljc:563)
at cljs.repl$repl_STAR_$read_eval_print__4908.invoke(repl.cljc:875)
at cljs.repl$repl_STAR_$fn__4914$fn__4923.invoke(repl.cljc:914)
at cljs.repl$repl_STAR_$fn__4914.invoke(repl.cljc:913)
at cljs.compiler$with_core_cljs.invokeStatic(compiler.cljc:1154)
at cljs.repl$repl_STAR_.invokeStatic(repl.cljc:851)
at cljs.repl$repl.invokeStatic(repl.cljc:993)
at cljs.repl$repl.doInvoke(repl.cljc:925)
at clojure.lang.RestFn.invoke(RestFn.java:486)
at user$eval220.invokeStatic(repl.clj:10)
at user$eval220.invoke(repl.clj:10)
at clojure.lang.Compiler.eval(Compiler.java:6927)
at clojure.lang.Compiler.load(Compiler.java:7379)
at clojure.lang.Compiler.loadFile(Compiler.java:7317)
at clojure.main$load_script.invokeStatic(main.clj:275)
at clojure.main$script_opt.invokeStatic(main.clj:335)
at clojure.main$script_opt.invoke(main.clj:330)
at clojure.main$main.invokeStatic(main.clj:421)
at clojure.main$main.doInvoke(main.clj:384)
at clojure.lang.RestFn.invoke(RestFn.java:408)
at clojure.lang.Var.invoke(Var.java:379)
at clojure.lang.AFn.applyToHelper(AFn.java:154)
at clojure.lang.Var.applyTo(Var.java:700)
at clojure.main.main(main.java:37)
Caused by: java.lang.IllegalStateException: Can't change/establish root
binding of: *unchecked-if* with set
at clojure.lang.Var.set(Var.java:221)
at cljs.analyzer$fn__1299.invokeStatic(analyzer.cljc:1589)
at cljs.analyzer$fn__1299.invoke(analyzer.cljc:1578)
at clojure.lang.MultiFn.invoke(MultiFn.java:251)
at cljs.analyzer$analyze_seq_STAR_.invokeStatic(analyzer.cljc:2416)
at cljs.analyzer$analyze_seq_STAR__wrap.invokeStatic(analyzer.cljc:2419)
... 57 more
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send
BigDecimal and ==, with a proposed fix
My understanding of == is that it is intended to establish numerical
equivalence
across types. But I think that basic contract fails with BigDecimal. For
instance,
(== 1M 1.0M) ; = false
because the scale properties of these numbers are different. So then of
course:
[(== 1 1N 1.0) (== 1 1N 1.0 1M) (== 1 1N 1.0 1.0M) (== 1 1.0 1N 1.0M)]
; = [true true true false]
and
[(== 1.0M 1.0) (== 1.0 1) (== 1 1N) (== 1N 1.0M)]
; = [true true true false]
I find your lack of transitivity (and commutativity) ... disturbing.
The issue is that there are two notions of equality for BigDecimal,
equals and compareTo, where equals compares value *and* scale while
compareTo compares numerically.
The other numeric types use equals for equivalence, quite reasonably.
But in class BigDecimalOps in clojure/lang/Numbers.java, I propose
that
public boolean equiv(Number x, Number y){
return toBigDecimal(x).equals(toBigDecimal(y));
}
should be
public boolean equiv(Number x, Number y){
return toBigDecimal(x).compareTo(toBigDecimal(y)) == 0;
}
to give the proper sense of equivalence.
I haven't had a chance yet to recompile with this change to test it,
but we do have
(zero? (. 1.0M (compareTo 1M))) ; = true
(zero? (. 1.M (compareTo 1M))) ; = true
(zero? (. 1.000M (compareTo 1.0M))) ; = true
as desired.
Reactions?
Best,
Chris
--
--
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
---
You received this message because you are subscribed to the Google Groups
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: BigDecimal and ==, with a proposed fix
Terrific, Andy, thanks. I will definitely take a look.
On Friday, August 2, 2013 1:16:14 AM UTC-4, Andy Fingerhut wrote:
I agree, which is why I wrote a patch for the ticket
http://dev.clojure.org/jira/browse/CLJ-1118
(Depending on when you read this, dev.clojure.org may not be accessible
due to a recent DNS update made by the Clojure folks. Wait a while and try
again.)
It makes not only the change you suggest, but also another one to how hash
is calculated for BigDecimal values, so that hash is still consistent with
=. Take a look at it and see if you think it is correct.
Andy
On Thu, Aug 1, 2013 at 9:28 PM, CGAT genov...@gmail.com javascript:wrote:
My understanding of == is that it is intended to establish numerical
equivalence
across types. But I think that basic contract fails with BigDecimal.
For instance,
(== 1M 1.0M) ; = false
because the scale properties of these numbers are different. So then of
course:
[(== 1 1N 1.0) (== 1 1N 1.0 1M) (== 1 1N 1.0 1.0M) (== 1 1.0 1N 1.0M)]
; = [true true true false]
and
[(== 1.0M 1.0) (== 1.0 1) (== 1 1N) (== 1N 1.0M)]
; = [true true true false]
I find your lack of transitivity (and commutativity) ... disturbing.
The issue is that there are two notions of equality for BigDecimal,
equals and compareTo, where equals compares value *and* scale while
compareTo compares numerically.
The other numeric types use equals for equivalence, quite reasonably.
But in class BigDecimalOps in clojure/lang/Numbers.java, I propose
that
public boolean equiv(Number x, Number y){
return toBigDecimal(x).equals(toBigDecimal(y));
}
should be
public boolean equiv(Number x, Number y){
return toBigDecimal(x).compareTo(toBigDecimal(y)) == 0;
}
to give the proper sense of equivalence.
I haven't had a chance yet to recompile with this change to test it,
but we do have
(zero? (. 1.0M (compareTo 1M))) ; = true
(zero? (. 1.M (compareTo 1M))) ; = true
(zero? (. 1.000M (compareTo 1.0M))) ; = true
as desired.
Reactions?
Best,
Chris
--
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clo...@googlegroups.comjavascript:
Note that posts from new members are moderated - please be patient with
your first post.
To unsubscribe from this group, send email to
clojure+u...@googlegroups.com javascript:
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an
email to clojure+u...@googlegroups.com javascript:.
For more options, visit https://groups.google.com/groups/opt_out.
--
--
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
---
You received this message because you are subscribed to the Google Groups
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: Help: instance? always false for record type (in tomcat but not in jetty)
For others who might have this problem, I've reduced this to the following:
(defrecord A ...)
(instance? A (A. ...)) ;= true
(instance? A (map-A {...})) ;= can be false (e.g., in a tomcat servlet)
The map-A constructor uses the create method, and as Chris said earlier,
this seems
to have to do with some deep class loading magic. But this strikes me as a
bug in
the sense that the above should under all circumstances be a guarantee made
by map-A.
On Thursday, December 13, 2012 11:49:20 PM UTC-5, CGAT wrote:
I've now put :aot [ns1] in the projects.clj, did lein compile, then lein
ring uberwar.
There was no difference. The class loaders are distinct and instance?
still returns false.
1. Did I do the AOT compile incorrectly? Is it even necessary?
(The class files are in the war file but *all* of them are, not just
ns1.)
2. If not, is it not being ``transmitted'' correctly into the war file?
3. Or, am I misunderstanding the problem?
I'm really not clear how to fix this. A record constructed with
the map-A constructor does not show up as being an instance of A.
Why?
Help!?
On Thursday, December 13, 2012 11:13:29 PM UTC-5, CGAT wrote:
Without AOT, the classLoader's are not the same
(str (.getClassLoader A))
WebappClassLoader
delegate: false
repositories:
/WEB-INF/classes/
-- Parent Classloader:
org.apache.catalina.loader.StandardClassLoader@790bc49d
(str (.getClassLoader (class an-A-record)))
clojure.lang.DynamicClassLoader@3ac803e6
I'll try AOT compile next, as that DynamicClassLoader seems to suggest.
But I'm not sure what else can be done.
On Thursday, December 13, 2012 10:53:53 PM UTC-5, CGAT wrote:
I did not AOT compile it, though I can try that. I'll check the
ClassLoader as well, thanks. I do know that (class an-A-record) is A,
suitably ns-qualified.
Thanks for the ideas. What did you finally do when this happened to you?
On Thursday, December 13, 2012 8:19:48 PM UTC-5, cjeris wrote:
In the Tomcat uberwar setting, is ns1 AOT-compiled? Are
(.getClassLoader A) and (.getClassLoader (.getClass an-A-record))
different
class loaders? That's what the problem was when this one bit me. I never
did track down exactly why it happens or how to fix it.
peace, Chris Jeris
On Thu, Dec 13, 2012 at 6:13 PM, CGAT genov...@gmail.com wrote:
I have a frustrating situation and would appreciate any help.
The call
(instance? A an-A-record)
is returning false when an-A-record is in fact an instance of A.
This is in a noir/compojure/ring server. But the problem *only* *occurs
*when run under tomcat, *not* when run under Jetty. I'm guessing
that I've missed declaring something properly, but I don't see what it
is.
(I hope this is a suitable forum for this question.)
Here's the situation in more detail.
In ns1
(defrecord A ...)
(defrecord B ...)
(defn AorB? [x] (or (instance? A x) (instance? B x)))
(defn Afactory [] ...) ; makes an A
In ns2, which :require's ns 1 refering AorB? and Afactory and
:imports A and B properly from ns1.
(AorB? (Afactory)) ;= true in jetty, false in tomcat
I'm using Clojure 1.4.0, compojure 1.1.3, noir 1.3.0-beta10,
I use lein run to start the jetty server (with a suitable -main),
and lein ring uberwar to create a warfile which runs under
Apache Tomcat 6.0.24 (with JVM 1.6.0_26-b03).
All the rest of the code appears to be behaving identically under
either platform.
I've been banging my head against the wall over this and would
appreciate any help or pointers. Thanks!
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clo...@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+u...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--
Chris Jeris
cje...@brightcove.com (617) 686-3271
freenode/twitter/github: ystael
--
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
Help: instance? always false for record type (in tomcat but not in jetty)
I have a frustrating situation and would appreciate any help. The call (instance? A an-A-record) is returning false when an-A-record is in fact an instance of A. This is in a noir/compojure/ring server. But the problem *only* *occurs *when run under tomcat, *not* when run under Jetty. I'm guessing that I've missed declaring something properly, but I don't see what it is. (I hope this is a suitable forum for this question.) Here's the situation in more detail. In ns1 (defrecord A ...) (defrecord B ...) (defn AorB? [x] (or (instance? A x) (instance? B x))) (defn Afactory [] ...) ; makes an A In ns2, which :require's ns 1 refering AorB? and Afactory and :imports A and B properly from ns1. (AorB? (Afactory)) ;= true in jetty, false in tomcat I'm using Clojure 1.4.0, compojure 1.1.3, noir 1.3.0-beta10, I use lein run to start the jetty server (with a suitable -main), and lein ring uberwar to create a warfile which runs under Apache Tomcat 6.0.24 (with JVM 1.6.0_26-b03). All the rest of the code appears to be behaving identically under either platform. I've been banging my head against the wall over this and would appreciate any help or pointers. Thanks! -- 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: Help: instance? always false for record type (in tomcat but not in jetty)
I did not AOT compile it, though I can try that. I'll check the ClassLoader as well, thanks. I do know that (class an-A-record) is A, suitably ns-qualified. Thanks for the ideas. What did you finally do when this happened to you? On Thursday, December 13, 2012 8:19:48 PM UTC-5, cjeris wrote: In the Tomcat uberwar setting, is ns1 AOT-compiled? Are (.getClassLoader A) and (.getClassLoader (.getClass an-A-record)) different class loaders? That's what the problem was when this one bit me. I never did track down exactly why it happens or how to fix it. peace, Chris Jeris On Thu, Dec 13, 2012 at 6:13 PM, CGAT genov...@gmail.com javascript:wrote: I have a frustrating situation and would appreciate any help. The call (instance? A an-A-record) is returning false when an-A-record is in fact an instance of A. This is in a noir/compojure/ring server. But the problem *only* *occurs *when run under tomcat, *not* when run under Jetty. I'm guessing that I've missed declaring something properly, but I don't see what it is. (I hope this is a suitable forum for this question.) Here's the situation in more detail. In ns1 (defrecord A ...) (defrecord B ...) (defn AorB? [x] (or (instance? A x) (instance? B x))) (defn Afactory [] ...) ; makes an A In ns2, which :require's ns 1 refering AorB? and Afactory and :imports A and B properly from ns1. (AorB? (Afactory)) ;= true in jetty, false in tomcat I'm using Clojure 1.4.0, compojure 1.1.3, noir 1.3.0-beta10, I use lein run to start the jetty server (with a suitable -main), and lein ring uberwar to create a warfile which runs under Apache Tomcat 6.0.24 (with JVM 1.6.0_26-b03). All the rest of the code appears to be behaving identically under either platform. I've been banging my head against the wall over this and would appreciate any help or pointers. Thanks! -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clo...@googlegroups.comjavascript: Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+u...@googlegroups.com javascript: For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- Chris Jeris cje...@brightcove.com javascript: (617) 686-3271 freenode/twitter/github: ystael -- 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: Help: instance? always false for record type (in tomcat but not in jetty)
Without AOT, the classLoader's are not the same (str (.getClassLoader A)) WebappClassLoader delegate: false repositories: /WEB-INF/classes/ -- Parent Classloader: org.apache.catalina.loader.StandardClassLoader@790bc49d (str (.getClassLoader (class an-A-record))) clojure.lang.DynamicClassLoader@3ac803e6 I'll try AOT compile next, as that DynamicClassLoader seems to suggest. But I'm not sure what else can be done. On Thursday, December 13, 2012 10:53:53 PM UTC-5, CGAT wrote: I did not AOT compile it, though I can try that. I'll check the ClassLoader as well, thanks. I do know that (class an-A-record) is A, suitably ns-qualified. Thanks for the ideas. What did you finally do when this happened to you? On Thursday, December 13, 2012 8:19:48 PM UTC-5, cjeris wrote: In the Tomcat uberwar setting, is ns1 AOT-compiled? Are (.getClassLoader A) and (.getClassLoader (.getClass an-A-record)) different class loaders? That's what the problem was when this one bit me. I never did track down exactly why it happens or how to fix it. peace, Chris Jeris On Thu, Dec 13, 2012 at 6:13 PM, CGAT genov...@gmail.com wrote: I have a frustrating situation and would appreciate any help. The call (instance? A an-A-record) is returning false when an-A-record is in fact an instance of A. This is in a noir/compojure/ring server. But the problem *only* *occurs *when run under tomcat, *not* when run under Jetty. I'm guessing that I've missed declaring something properly, but I don't see what it is. (I hope this is a suitable forum for this question.) Here's the situation in more detail. In ns1 (defrecord A ...) (defrecord B ...) (defn AorB? [x] (or (instance? A x) (instance? B x))) (defn Afactory [] ...) ; makes an A In ns2, which :require's ns 1 refering AorB? and Afactory and :imports A and B properly from ns1. (AorB? (Afactory)) ;= true in jetty, false in tomcat I'm using Clojure 1.4.0, compojure 1.1.3, noir 1.3.0-beta10, I use lein run to start the jetty server (with a suitable -main), and lein ring uberwar to create a warfile which runs under Apache Tomcat 6.0.24 (with JVM 1.6.0_26-b03). All the rest of the code appears to be behaving identically under either platform. I've been banging my head against the wall over this and would appreciate any help or pointers. Thanks! -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clo...@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+u...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- Chris Jeris cje...@brightcove.com (617) 686-3271 freenode/twitter/github: ystael -- 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: Help: instance? always false for record type (in tomcat but not in jetty)
I've now put :aot [ns1] in the projects.clj, did lein compile, then lein ring uberwar. There was no difference. The class loaders are distinct and instance? still returns false. 1. Did I do the AOT compile incorrectly? Is it even necessary? (The class files are in the war file but *all* of them are, not just ns1.) 2. If not, is it not being ``transmitted'' correctly into the war file? 3. Or, am I misunderstanding the problem? I'm really not clear how to fix this. A record constructed with the map-A constructor does not show up as being an instance of A. Why? Help!? On Thursday, December 13, 2012 11:13:29 PM UTC-5, CGAT wrote: Without AOT, the classLoader's are not the same (str (.getClassLoader A)) WebappClassLoader delegate: false repositories: /WEB-INF/classes/ -- Parent Classloader: org.apache.catalina.loader.StandardClassLoader@790bc49d (str (.getClassLoader (class an-A-record))) clojure.lang.DynamicClassLoader@3ac803e6 I'll try AOT compile next, as that DynamicClassLoader seems to suggest. But I'm not sure what else can be done. On Thursday, December 13, 2012 10:53:53 PM UTC-5, CGAT wrote: I did not AOT compile it, though I can try that. I'll check the ClassLoader as well, thanks. I do know that (class an-A-record) is A, suitably ns-qualified. Thanks for the ideas. What did you finally do when this happened to you? On Thursday, December 13, 2012 8:19:48 PM UTC-5, cjeris wrote: In the Tomcat uberwar setting, is ns1 AOT-compiled? Are (.getClassLoader A) and (.getClassLoader (.getClass an-A-record)) different class loaders? That's what the problem was when this one bit me. I never did track down exactly why it happens or how to fix it. peace, Chris Jeris On Thu, Dec 13, 2012 at 6:13 PM, CGAT genov...@gmail.com wrote: I have a frustrating situation and would appreciate any help. The call (instance? A an-A-record) is returning false when an-A-record is in fact an instance of A. This is in a noir/compojure/ring server. But the problem *only* *occurs *when run under tomcat, *not* when run under Jetty. I'm guessing that I've missed declaring something properly, but I don't see what it is. (I hope this is a suitable forum for this question.) Here's the situation in more detail. In ns1 (defrecord A ...) (defrecord B ...) (defn AorB? [x] (or (instance? A x) (instance? B x))) (defn Afactory [] ...) ; makes an A In ns2, which :require's ns 1 refering AorB? and Afactory and :imports A and B properly from ns1. (AorB? (Afactory)) ;= true in jetty, false in tomcat I'm using Clojure 1.4.0, compojure 1.1.3, noir 1.3.0-beta10, I use lein run to start the jetty server (with a suitable -main), and lein ring uberwar to create a warfile which runs under Apache Tomcat 6.0.24 (with JVM 1.6.0_26-b03). All the rest of the code appears to be behaving identically under either platform. I've been banging my head against the wall over this and would appreciate any help or pointers. Thanks! -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clo...@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+u...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- Chris Jeris cje...@brightcove.com (617) 686-3271 freenode/twitter/github: ystael -- 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
Proposal/request: Give clojure.core/conj a unary implementation
It would be nice if clojure.core/conj had a unary implementation
([coll] coll)
The motivating use case is when one is conjoining sequences of
items to a collection all at once:
(apply conj coll seqable)
such as (apply conj #{1 2 3} [2 4 6 8 10]).
Currently (1.4.0), this will raise an arity exception
if the seqable object is empty:
(apply conj #{1 2 3} [])
necessitating an awkward empty? check when,
for instance, the sequence is computed or passed in.
It seems to me that making unary conj the identity is both
a natural interpretation and essentially cost free, while
making this use case much more convenient.
Moreover, it is consistent with clojure.core/disj for sets
which does act like this
(apply disj #{1 2 3} []) - #{1 2 3}
and has an identity unary implementation.
Comments?
--
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: Proposal/request: Give clojure.core/conj a unary implementation
That's a good point Alan, and I should have mentioned into.
But this came up for me in a situation relevant to Ben's' point.
I was adding or removing a computed sequence of elements of a set based on
some other
input and was using either conj or disj depending on that input, with apply.
It worked on the disj's but failed on the conj's, of course.
I could in this case have made the check at the time of change and used
into or disj
as appropriate, but in general, one might be passed just the functions as
Ben suggests.
Even if there is a better way to handle this problem in this case, I don't
see it as an argument
against the unary conj. The unary conj is conceptually natural, is
consistent with disj, does not
mask bugs, appears to really have no practical downside, and seems to have
at least one useful application.
Why not include it?
On Saturday, November 3, 2012 7:43:22 PM UTC-4, Ben wrote:
There might be a reason to write (apply f coll seqable) in a situation
in which f might be conj, though.
On Sat, Nov 3, 2012 at 4:25 PM, Alan Malloy al...@malloys.orgjavascript:
wrote:
There is never a reason to write (apply conj ...). Instead, use `into`,
which does the same thing but faster and with fewer characters.
On Saturday, November 3, 2012 3:27:24 PM UTC-7, CGAT wrote:
It would be nice if clojure.core/conj had a unary implementation
([coll] coll)
The motivating use case is when one is conjoining sequences of
items to a collection all at once:
(apply conj coll seqable)
such as (apply conj #{1 2 3} [2 4 6 8 10]).
Currently (1.4.0), this will raise an arity exception
if the seqable object is empty:
(apply conj #{1 2 3} [])
necessitating an awkward empty? check when,
for instance, the sequence is computed or passed in.
It seems to me that making unary conj the identity is both
a natural interpretation and essentially cost free, while
making this use case much more convenient.
Moreover, it is consistent with clojure.core/disj for sets
which does act like this
(apply disj #{1 2 3} []) - #{1 2 3}
and has an identity unary implementation.
Comments?
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clo...@googlegroups.comjavascript:
Note that posts from new members are moderated - please be patient with
your
first post.
To unsubscribe from this group, send email to
clojure+u...@googlegroups.com javascript:
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--
Ben Wolfson
Human kind has used its intelligence to vary the flavour of drinks,
which may be sweet, aromatic, fermented or spirit-based. ... Family
and social life also offer numerous other occasions to consume drinks
for pleasure. [Larousse, Drink entry]
--
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
