On Oct 4, 2010, at 3:58 AM, George Jahad wrote:
> Using the CDT I was able to confirm that one of the agents actually is
> generating a run time exception, trying to cast an int from a long.
> Could the perturb function be calling rand-int with a value that is
> too large? I'm including the stack trace below in case that helps.
Thank you George!
I think this will solve my current problem although I wonder if this points to
some issues with agent error handling that deserve more attention.
FWIW I had noticed that the exception you found could occur, and in my most
recent code I have an alternative to rand-int that includes this:
(if (= (type n) java.lang.Integer)
(. thread-local-random-generator (nextInt n))
(. thread-local-random-generator (nextInt 2147483647))))) ;; biggest
java.lang.Integer
BUT I foolishly forgot to change the call to rand-int in perturb to use this
alternative, so I was still calling rand-int with something that wasn't a
java.lang.Integer and that seems like it is indeed the source of the trouble.
I still don't understand why everything continues to chug merrily along in 1.1
when I hit this error (although other errors in agents would produce a message
saying that the agent had errors -- not specific but at least something), why
1.2 hangs without comment (shouldn't the exception produce some sort of
feedback?), or why I couldn't find a trace of the exception in the Eclipse
debugger.
Setting aside the 1.1 mystery for now -- since it's just history anyway -- is
there a rationale for silencing exceptions in agents and just having calls to
await hang without comment? I'm not sure what I think should happen in terms of
continued processing, but it sure would be nice to know that an exception
occurred and to be shown the details.
I also look forward to the integration of CDT into Eclipse/ccw :-). Or maybe I
need to migrate back to emacs, from whence I came (but was lured away by a
couple nice features of eclipse/ccw...).
Thanks George especially for running the code to diagnose this. It was tricky
because the bignums only arise in certain situations, although here there is
actually selection pressure for bignums since bigger arguments to perturb
increase replication accuracy.
-Lee
--
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
