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.
// Ben
--
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
