Mantis - OCaml-Java
Erweiterte Problemanzeige
114 schwerer Fehler immer 2013-01-30 13:05 2013-03-07 23:12
jrrk100  
xclerc  
normal  
erledigt 2.0-early-access  
erledigt  
keine    
keine 2.0-early-access3  
0000114: Error: Cannot compute stack frames
jk23@angcatlnxsrv10:~/ocamljava-2.0-early-access2$ ocamljava queens.ml
File "queens.ml", line 1:
Error: Cannot compute stack frames
(class "java.lang.Object" not found)
jk23@angcatlnxsrv10:~/ocamljava-2.0-early-access2$ ocamlc queens.ml
jk23@angcatlnxsrv10:~/ocamljava-2.0-early-access2$

The program came from here:

http://caml.inria.fr/pub/old_caml_site/Examples/oc/basics/queens.ml [^]

Platform was linux debian wheezy, JRE 1.7
Problem-Historie
2013-01-30 13:05 jrrk100 Neues Problem
2013-01-30 18:36 xclerc Problemnotiz hinzugefügt: 0000264
2013-01-30 18:36 xclerc Bearbeitung durch => xclerc
2013-01-30 18:36 xclerc Status neu => Rückmeldung
2013-01-31 16:55 jrrk100 Problemnotiz hinzugefügt: 0000269
2013-02-01 15:59 xclerc Problemnotiz hinzugefügt: 0000271
2013-02-01 15:59 xclerc Status Rückmeldung => anerkannt
2013-03-07 23:12 xclerc Status anerkannt => erledigt
2013-03-07 23:12 xclerc Behoben in Version => 2.0-early-access3
2013-03-07 23:12 xclerc Lösung offen => erledigt

Notiz
(0000264)
xclerc   
2013-01-30 18:36   
Usually, this happens when the JAVA_HOME environment variable
is not properly set. However, I only tested the distribution against
full JDKs, but not against mere JREs.

Could you check the value of the JAVA_HOME environment variable,
and also tell me whether you have a file with the path
$JAVA_HOME/lib/ct.sym ?
(0000269)
jrrk100   
2013-01-31 16:55   
You are correct, the compilation proceeds when JDK is used instead of JRE. lib/ct.sym is not present in the JRE. As far as runtime goes, the native executable solves the queens problem for an 8x8 board in 4ms. The java version, who knows - but a very long time.
(0000271)
xclerc   
2013-02-01 15:59   
I don't know yet if it will be possible to support bare JREs,
but will take a look at it.

Regarding "queens.ml", the bug in OCaml-Java is indeed
in the "read_int" primitive... the computation is never launched.
If modified to remove the interactive part, the program
exhibit decent performances.