On Apr 17, 2010, at 3:50 PM, B Smith-Mannschott wrote:
On Sat, Apr 17, 2010 at 21:32, Stuart Halloway
<stuart.hallo...@gmail.com> wrote:
It's almost certainly the commit that added the InternalReduce
protocol:
5b281880571573c5917781de932ce4789f18daec.
I am slowly pounding my skull against this and would welcome any
help. It
appears that the internal-reduce function flakes out and stops
working, but
only intermittently.
If there is some way that protocols.clj gets *re*loaded while
Clojure is
running, that would definitely be a problem, as reduce depends on it.
Yes, I just saw a8e92018ce0ce32fc59fae2072369a8671fdea62 "disable new
reduce" go in on clojure/master and have been running repeated builds
of clojure-contrib builds using that. It's a marked improvement, I'm
now only seeing 1 build of every 18 fail. It's no longer failing in
complex-numbers but rather in json:
ERROR in (can-print-json-null) (run-test1309997463507545582.clj:44)
expected: (= "null" (json-str nil))
actual: java.lang.NullPointerException: null
at clojure.contrib.json$eval__7586$fn__7587$G__7578__7590.invoke
(json.clj:204)
clojure.contrib.json/json_str (json.clj:306)
clojure.contrib.test_json/fn (test_json.clj:148)
clojure.test$test_var__6804$fn__6805.invoke (test.clj:644)
clojure.test/test_var (test.clj:644)
clojure.test$test_all_vars__6809$fn__6810$fn__6817.invoke
(test.clj:659)
clojure.test/default_fixture (test.clj:617)
clojure.test$test_all_vars__6809$fn__6810.invoke (test.clj:659)
clojure.test/default_fixture (test.clj:617)
clojure.test/test_all_vars (test.clj:655)
clojure.test/test_ns (test.clj:677)
clojure.core$map__4089$fn__4090.invoke (core.clj:1870)
clojure.lang.LazySeq.sval (LazySeq.java:42)
clojure.lang.LazySeq.seq (LazySeq.java:56)
clojure.lang.Cons.next (Cons.java:37)
clojure.lang.RT.next (RT.java:540)
clojure.core/next (core.clj:54)
clojure.core/reduce (core.clj:707)
clojure.core/reduce (core.clj:698)
clojure.core$merge_with__4179.doInvoke (core.clj:2046)
clojure.lang.RestFn.applyTo (RestFn.java:140)
clojure.core/apply (core.clj:480)
clojure.test$run_tests__6826.doInvoke (test.clj:691)
clojure.lang.RestFn.invoke (RestFn.java:1261)
user$eval__12082$fn__12085.invoke (run-
test1309997463507545582.clj:46)
user/eval (run-test1309997463507545582.clj:44)
clojure.lang.Compiler.eval (Compiler.java:5373)
clojure.lang.Compiler.load (Compiler.java:5784)
clojure.lang.Compiler.loadFile (Compiler.java:5747)
clojure.main/load_script (main.clj:213)
clojure.main/script_opt (main.clj:265)
clojure.main$main__6279.doInvoke (main.clj:346)
clojure.lang.RestFn.invoke (RestFn.java:409)
clojure.lang.Var.invoke (Var.java:365)
clojure.lang.AFn.applyToHelper (AFn.java:165)
clojure.lang.Var.applyTo (Var.java:482)
clojure.main.main (main.java:37)
Line 204 of json.cl is:
202 ;;; JSON PRINTER
203
*204 (defprotocol Write-JSON
205 (write-json [object out]
206 "Print object to PrintWriter out as JSON"))
So, though a8e92018 is a great improvement, I'm still seeing some
defprotocol related misbehavior.
This should all be fixed now, as of
#19dd3c593e7a29cbca514c6ab7424ff22e353cc6.
Thanks for the report,
Rich
--
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
