Thank you. I am not loading jar files from an NFS share. I pull from
the 2 standard repositories plus one extra:
:repositories [["central-proxy" "https://repository.sonatype.org/
content/repositories/centralm1/"]]
>From there I pull:
[org.apache.commons/commons-email "1.3"]
I've encountered errors like this when running where .jar files for the
project were being loaded from an NFS share. Do you have that in your
environment? The solution is to load the .jars from a local directory
instead.
On Monday, January 28, 2013 12:59:12 PM UTC-5, larry google groups wrote:
Ah, stupid of me. No, I'm not using the 1.5 features. This project is all
1.4.
W dniu poniedziałek, 28 stycznia 2013 14:51:02 UTC-5 użytkownik Jim foo.bar
napisał:
>
> On 28/01/13 18:58, larry google groups wrote:
> > Interesting. My app leans heavily on (reduce). I think in some places
>
On 28/01/13 18:58, larry google groups wrote:
Interesting. My app leans heavily on (reduce). I think in some places
I might call reduce from inside of another reduce. This is the problem
then?
No no I don't mean plain old 'reduce' but the new 'reducers' library in
1.5...
Jim
--
--
You re
even if that works, it should really be considered as a
(temporary)workaround to the actual fix(which is unknown to me) and it's
not unlike using a 32bit jvm (both are workarounds and both have disabled
UseCompressedOops).
quick read here:
http://javarevisited.blogspot.com/2012/06/what-is-xxusecom
Than you for the suggestion. I am highly ignorant about the JVM. I have
been using these options:
:jvm-opts ["-Xmx1000m"]
I will switch to:
:jvm-opts ["-Xmx1000m -XX:-UseCompressedOops"]
W dniu poniedziałek, 28 stycznia 2013 13:02:48 UTC-5 użytkownik AtKaaZ
napisał:
>
> try using this
> This error is still thrown whenever i use ^:const and
> reducers to traverse tree of moves deeper than 6..
Interesting. My app leans heavily on (reduce). I think in some places I
might call reduce from inside of another reduce. This is the problem then?
W dniu poniedziałek, 28 stycznia 201
it could still be a clojure(or asm) issue but only when using 64bit jvm, my
guess is that the 32bit one will always work (without errors, or at least
without the compressed oops error) but I didn't try it
"In an ILP32-mode JVM, or if the UseCompressedOops flag is turned off in
LP64 mode, all oops
No, I haven't but to be honest switching vms is not really a
solution...even if it didn't happen my cpu is 64-bit and Ideally i'd
like to take advantage of it, wouldn't you? Are you sort of implying
that this is a Java/JDK issue and not a clojure one?
Larry are using reducers or ^:const ??? I'
Hi Jim, did you try a 32bit jvm? I wonder if it still happens with that
On Mon, Jan 28, 2013 at 7:28 PM, Jim - FooBar(); wrote:
> I feel obliged to come in and say that using this flag did not cure my
> problem completely...This error is still thrown whenever i use ^:const and
> reducers to tra
I feel obliged to come in and say that using this flag did not cure my
problem completely...This error is still thrown whenever i use ^:const
and reducers to traverse tree of moves deeper than 6...It doesn't happen
always but most of the times! If i don't use ^:const it seems to not
happen. Not
try using this vm arg:
-XX:-UseCompressedOops
more info here:
https://groups.google.com/d/msg/clojure/MIKccMX9gvk/gZYA_24d0BwJ
On Mon, Jan 28, 2013 at 6:59 PM, larry google groups <
lawrencecloj...@gmail.com> wrote:
>
> I have a small clojure app (maybe 700 lines of code). I start it at the
> t
I have a small clojure app (maybe 700 lines of code). I start it at the
terminal and it runs for 10 minutes or so. Then, sometimes, it produces
this error:
# A fatal error has been detected by the Java Runtime Environment:
#
# SIGBUS (0xa) at pc=0x00010e34815e, pid=45108, tid=22787
#
# JR
13 matches
Mail list logo
