From: Andras S. <as...@ma...> - 2004-07-29 14:20:32
|
http://www.math.bme.hu/~asimon/lisp/jfli-abcl.lisp is a port of jfli to ABCL. I don't know how well it mimics jfli/LW, but the swt demo and the jdbc code in http://sourceforge.net/mailarchive/forum.php?thread_id=5112610&forum_id=41309 appear to work. def-java-class does some package/symbol trickery that LispWorks tolerates but ABCL does not. The symptom is that if you compile and then load a file which has stuff like this: (defpackage :glr (:use :common-lisp :jfli) (:export :open-connection :select :close-connection)) (in-package :glr) (def-java-class "java.sql.DriverManager") (def-java-class "java.sql.Connection") (def-java-class "java.sql.Statement") (def-java-class "java.sql.ResultSet") (def-java-class "java.sql.ResultSetMetaData") (def-java-class "java.util.Properties") ;;(def-java-class "oracle.jdbc.driver.OracleDriver") (def-java-class "org.postgresql.Driver") (use-package "java.lang") (use-package "java.sql") (use-package "org.postgresql") (defvar *connection* nil) (defun open-connection() (declare (optimize (space 3))) (let* ((driver (driver.new)) (properties (properties.new)) (connection (progn (properties.setproperty properties "user" "simon") (properties.setproperty properties "password" "") (driver.connect driver "jdbc:postgresql:mydb" properties)))) (setf *connection* connection))) ABCL will complain that the function driver.new is undefined (it is defined and exported from the package named "org.postgresql" which is USEd by glr; nevertheless, I'm not at all sure that this is an ABCL bug). A workaround for now is to delete the glr package after compiling and before loading the .abcl file. Or (untested) compile and load a file containing only the def-java-class forms first. Andras |
From: glr <gl...@rc...> - 2004-08-02 11:57:50
|
Nope: (I'm not convinced we are running with the same version of stuff, however) J 0.20.2.18 (built Sun Aug 01 2004 09:54:55 PDT) Armed Bear Common Lisp 0.0.3.16 (built Sun Aug 01 2004 09:54:55 PDT) Java 1.4.2_03 Sun Microsystems Inc. Java HotSpot(TM) Client VM Type :HELP for a list of available commands. CL-USER(1): (load (compile-file "lisp/jfli.lisp")) ; Loading C:\J\src\org\armedbear\lisp\jvm.abcl ... ; Loading C:\J\src\org\armedbear\lisp\opcodes.abcl ... ; Loaded C:\J\src\org\armedbear\lisp\opcodes.abcl (0.601 seconds) ; Loaded C:\J\src\org\armedbear\lisp\jvm.abcl (7.351 seconds) [snip] Processing macro DOENUM ; Macro DOENUM => jfli-11.cls ; Processing macro GET-OR-INIT ; Macro GET-OR-INIT => jfli-12.cls Debugger invoked on condition of type ERROR: Package "java.lang" not found. Restarts: 0: TOP-LEVEL Return to top level. glr On Sun, 1 Aug 2004 23:31:52 +0200 (CEST), Andras Simon <as...@ma...> wrote: > > > On Sun, 1 Aug 2004, glr wrote: > >> Just a load. When I attempt to (load (compile-file "lisp/jfli")) it >> generates a package error (e.g. - can't find package java.lang. > > You mean (load (compile-file "sql-test.lisp"))? Because compiling and > loading jfli-abcl.lisp should not produce package errors. > > But if you ran the sql test uncompiled, I'm quite surprised that it > was so fast! > > Andras > >> >> glr >> >> On Sun, 1 Aug 2004 22:50:10 +0200 (CEST), Andras Simon >> <as...@ma...> wrote: >> >>> On Sun, 1 Aug 2004, glr wrote: >>> >>>> dump. On the other hand, the jfli/sql test worked against Oracle >>>> (without >>>> the problems you ran into with drver.new). >>> That's strange. I tried and ran into the very same problem again. Did >>> you compile the file containing the sql test? Or just loaded the >>> source? >>> Andras >>> >> >> >> >> -- Using M2, Opera's revolutionary e-mail client: >> http://www.opera.com/m2/ >> -- Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/ |
From: Andras S. <as...@ma...> - 2004-08-02 13:35:10
|
On Mon, 2 Aug 2004, glr wrote: > Nope: (I'm not convinced we are running with the same version of stuff, > however) Probably not. Are you using the CVS version of ABCL? Anything else is probably obsolete. > > J 0.20.2.18 (built Sun Aug 01 2004 09:54:55 PDT) > Armed Bear Common Lisp 0.0.3.16 (built Sun Aug 01 2004 09:54:55 PDT) It's Armed Bear Common Lisp 0.0.3.16+ (built Sun Aug 1 19:18:48 CEST 2004) here. (Though even if the version numbers were the same, that wouldn't mean too much.) > Processing macro DOENUM > ; Macro DOENUM => jfli-11.cls > ; Processing macro GET-OR-INIT > ; Macro GET-OR-INIT => jfli-12.cls > Debugger invoked on condition of type ERROR: > Package "java.lang" not found. > Restarts: > 0: TOP-LEVEL Return to top level. This shouldn't happen. There's a (eval-when (:compile-toplevel :load-toplevel) (defun ensure-package (name) "find the package or create it if it doesn't exist" (or (find-package name) (make-package name :use '()))) (intern "Object" (ensure-package "java.lang")) (intern "String" (ensure-package "java.lang"))) earlier in jfli-abcl.lisp Andras |
From: Larry C. <la...@th...> - 2004-08-02 15:05:43
|
glr said: > Nope: (I'm not convinced we are running with the same version of stuff, > however) Data point: I'm not convinced the file compiler is totally bug-free (cvs 8/2 ~9am Eastern). Doing a (compile-system), I get ; Compiling /big2/home/lmc/lisp/armedbear-cvs-2004-08-02/j/src/org/armedbear/lisp/macros.lisp ... ; Processing macro PROG1 ; Macro PROG1 => macros-1.cls ; Processing macro PROG2 ; Macro PROG2 => macros-2.cls ; Processing macro PUSH Debugger invoked on condition of type TYPE-ERROR: The value NIL is not of type HASH-TABLE. (see below for backtrace) But if I restart abcl and say (compile-file "macros.lisp"), it compiles ok. -- Larry Clapp [1] CL-USER(2): :bt 0: (BACKTRACE-AS-LIST) 1: (#:G9459 #S(JVM::INSTRUCTION :OPCODE 178 :ARGS ("org/armedbear/lisp/macros_3" "G17231_LIST" "Lorg/armedbear/lisp/LispObject;") :STACK NIL :DEPTH NIL)) 2: (JVM:COMPILE-DEFUN NIL (LAMBDA (#:G17208 #:G17209) (BLOCK PUSH (LET* NIL (UNLESS (<= 2 (LENGTH (CDR #:G17208)) 2) (SYSTEM::DO-ARG-COUNT-ERROR 'DEFMACRO 'PUSH (CDR #:G17208) '(SYSTEM::ITEM SYSTEM::PLACE) 2 2)) (LET* ((SYSTEM::ITEM (CAR (CDR #:G17208))) (SYSTEM::PLACE (CAR (CDR (CDR #:G17208))))) (IF (AND (SYMBOLP SYSTEM::PLACE) (EQ SYSTEM::PLACE (MACROEXPAND SYSTEM::PLACE))) (APPEND (LIST 'SETQ) (LIST SYSTEM::PLACE) (LIST (APPEND (LIST 'CONS) (LIST SYSTEM::ITEM) (LIST SYSTEM::PLACE) 'NIL)) 'NIL) (MULTIPLE-VALUE-BIND (SYSTEM::DUMMIES SYSTEM::VALS SYSTEM::NEWVAL SYSTEM::SETTER SYSTEM::GETTER) (GET-SETF-EXPANSION SYSTEM::PLACE) (LET ((SYSTEM::G (GENSYM))) (APPEND (LIST 'LET*) (LIST (APPEND (LIST (APPEND (LIST SYSTEM::G) (LIST SYSTEM::ITEM) 'NIL)) (MAPCAR #'LIST SYSTEM::DUMMIES SYSTEM::VALS) (LIST (APPEND (LIST (CAR SYSTEM::NEWVAL)) (LIST (APPEND (LIST 'CONS) (LIST SYSTEM::G) (LIST SYSTEM::GETTER) 'NIL)) 'NIL)) 'NIL)) (LIST SYSTEM::SETTER) 'NIL)))))))) NIL "/home/lmc/lisp/armedbear-cvs-2004-08-02/j/src/org/armedbear/lisp/macros-3.cls") 3: (SYSTEM::PROCESS-TOPLEVEL-FORM (DEFMACRO PUSH (SYSTEM::ITEM SYSTEM::PLACE) (IF (AND (SYMBOLP SYSTEM::PLACE) (EQ SYSTEM::PLACE (MACROEXPAND SYSTEM::PLACE))) (COMMON-LISP::BACKQUOTE (SETQ (COMMON-LISP::COMMA SYSTEM::PLACE) (CONS (COMMON-LISP::COMMA SYSTEM::ITEM) (COMMON-LISP::COMMA SYSTEM::PLACE)))) (MULTIPLE-VALUE-BIND (SYSTEM::DUMMIES SYSTEM::VALS SYSTEM::NEWVAL SYSTEM::SETTER SYSTEM::GETTER) (GET-SETF-EXPANSION SYSTEM::PLACE) (LET ((SYSTEM::G (GENSYM))) (COMMON-LISP::BACKQUOTE (LET* (((COMMON-LISP::COMMA SYSTEM::G) (COMMON-LISP::COMMA SYSTEM::ITEM)) (COMMON-LISP::COMMA-ATSIGN (MAPCAR #'LIST SYSTEM::DUMMIES SYSTEM::VALS)) ((COMMON-LISP::COMMA (CAR SYSTEM::NEWVAL)) (CONS (COMMON-LISP::COMMA SYSTEM::G) (COMMON-LISP::COMMA SYSTEM::GETTER)))) (COMMON-LISP::COMMA SYSTEM::SETTER))))))) #<FILE-STREAM @ #x19ea173> NIL) 4: (COMPILE-FILE "macros.lisp") 5: (APPLY #<FUNCTION COMPILE-FILE> ("macros.lisp")) 6: (SYSTEM::MAP1 #<FUNCTION COMPILE-FILE> (("collect.lisp" "macros.lisp" "loop.lisp")) NIL T) 7: (MAPC #<FUNCTION COMPILE-FILE> ("collect.lisp" "macros.lisp" "loop.lisp")) 8: (SYSTEM::%TIME #<FUNCTION @ #x179a49f>) 9: (COMPILE-SYSTEM) 10: (SYSTEM::%EVAL (COMPILE-SYSTEM)) 11: (EVAL (COMPILE-SYSTEM)) 12: (SYSTEM::INTERACTIVE-EVAL (COMPILE-SYSTEM)) 13: (TOP-LEVEL::REPL) 14: (TOP-LEVEL::TOP-LEVEL-LOOP) |
From: Peter G. <pe...@ar...> - 2004-08-02 15:31:57
|
On Mon, 2 Aug 2004 at 11:05:33 -0400, Larry Clapp wrote: > glr said: > > Nope: (I'm not convinced we are running with the same version of stuff, > > however) > > Data point: I'm not convinced the file compiler is totally bug-free (cvs > 8/2 ~9am Eastern). Doing a (compile-system), I get > > ; Compiling > /big2/home/lmc/lisp/armedbear-cvs-2004-08-02/j/src/org/armedbear/lisp/m > acros.lisp ... ; Processing macro PROG1 ; Macro PROG1 => > macros-1.cls ; Processing macro PROG2 ; Macro PROG2 => macros-2.cls > ; Processing macro PUSH Debugger invoked on condition of type > TYPE-ERROR: > The value NIL is not of type HASH-TABLE. > > (see below for backtrace) > > But if I restart abcl and say (compile-file "macros.lisp"), it compiles ok. I'm completely convinced the file compiler is NOT totally bug-free, but I haven't seen that particular error. Normally I do rm *.abcl *.cls in src/org/armedbear/lisp, rebuild all the abcl .java files (if they've changed at all) and restart abcl before doing COMPILE-SYSTEM, and I always try to make sure that works correctly before committing any changes to the compiler. Last night's version of the compiler completed COMPILE-SYSTEM (as described) without any unexpected problems and then went on to survive the ANSI test suite with no new failures, so I don't think it's seriously broken. (For now, there are always likely to be "expected problems", meaning code that can't be compiled and is therefore re left for the interpreter, but that sort of thing shouldn't interfere with correctness or cause any real trouble in practice.) -Peter |
From: glr <gl...@rc...> - 2004-08-02 16:39:27
|
OK ... Another try. 1) From CVS this morning 2) Did ant clean 3) Deleted anything with ".cls" or ".abcl" from org/armedbear/lisp 4) Ran ant all (using jdk142 and ant1.6.2 under win2k pro) 5) Everything OK at this point - j.jar created 6) Executed java -jar j.jar to get editor 7) Started embedded lisp 8) Executed (compile-system) at prompt and got dump. Am I missing a step here somewhere? Dump: [snip] ; Compiling C:\temp\j\j\src\org\armedbear\lisp\asdf.lisp ... ; Processing macro AIF ; Macro AIF => asdf-1.cls ; Processing function PATHNAME-SANS-NAME+TYPE ; PATHNAME-SANS-NAME+TYPE => asdf-2.cls ; Installing dummy function for PATHNAME-SANS-NAME+TYPE ; Processing macro APPENDF ; Macro APPENDF => asdf-3.cls ; Processing function SYSDEF-ERROR ; SYSDEF-ERROR => asdf-4.cls ; Installing dummy function for SYSDEF-ERROR ; Processing function COMPONENT-PARENT-PATHNAME ; COMPONENT-PARENT-PATHNAME => asdf-5.cls ; Installing dummy function for COMPONENT-PARENT-PATHNAME ; Processing function SPLIT ; SPLIT => asdf-6.cls ; Installing dummy function for SPLIT ; Processing function COERCE-NAME ; Compiling ALPHANUMERICP ... ; Compiled ALPHANUMERICP ; Compiling CHAR/= ... ; Compiled CHAR/= ; Compiling CHAR< ... ; Compiled CHAR< ; Compiling CHAR> ... ; Compiled CHAR> ; Compiling CHAR>= ... ; Compiled CHAR>= ; Compiling CHAR-NOT-EQUAL ... ; Compiled CHAR-NOT-EQUAL ; COERCE-NAME => asdf-8.cls ; Installing dummy function for COERCE-NAME ; Processing function SYSTEM-DEFINITION-PATHNAME ; SYSTEM-DEFINITION-PATHNAME => asdf-10.cls ; Installing dummy function for SYSTEM-DEFINITION-PATHNAME ; Processing function SYSDEF-CENTRAL-REGISTRY-SEARCH ; SYSDEF-CENTRAL-REGISTRY-SEARCH => asdf-12.cls ; Installing dummy function for SYSDEF-CENTRAL-REGISTRY-SEARCH ; Processing function FIND-SYSTEM ; FIND-SYSTEM => asdf-13.cls ; Installing dummy function for FIND-SYSTEM ; Processing function REGISTER-SYSTEM ; REGISTER-SYSTEM => asdf-15.cls ; Installing dummy function for REGISTER-SYSTEM ; Processing function SYSTEM-REGISTERED-P ; SYSTEM-REGISTERED-P => asdf-17.cls ; Installing dummy function for SYSTEM-REGISTERED-P ; Processing function NODE-FOR ; NODE-FOR => asdf-18.cls ; Installing dummy function for NODE-FOR ; Processing function MAKE-SUB-OPERATION ; MAKE-SUB-OPERATION => asdf-19.cls ; Installing dummy function for MAKE-SUB-OPERATION ; Processing function OPERATE ; Note: There is no class named FORMAT::FORMAT-ERROR. ; Unable to compile function OPERATE Debugger invoked on condition of type ERROR: There is no class named FORMAT::FORMAT-ERROR. Restarts: 0: TOP-LEVEL Return to top level. [1] ASDF(2): |
From: Peter G. <pe...@ar...> - 2004-08-02 17:25:14
|
On Mon, 02 Aug 2004 at 11:39:13 -0700, glr wrote: > OK ... Another try. > > 1) From CVS this morning > 2) Did ant clean > 3) Deleted anything with ".cls" or ".abcl" from org/armedbear/lisp > 4) Ran ant all (using jdk142 and ant1.6.2 under win2k pro) > 5) Everything OK at this point - j.jar created > 6) Executed java -jar j.jar to get editor > 7) Started embedded lisp ^^^^^^^^ This is probably the culprit. "Embedded" Lisp is the instance of abcl that's embedded in the currently-running instance of j. You really shouldn't use embedded Lisp unless you plan to use it to interact with the running instance of j in some way (to do editor-related customization, for example). Normally, if you just want to run abcl in a j Lisp shell, you should use the menu item "Run Lisp as Separate Process". Doing it this way has the important advantage that the abcl instance is completely separate from the j instance, so if you get frisky and some misfortune befalls abcl, nothing bad happens to j. (I'm typing this message in a j instance that's been running for over 9 days and has survived quite a few abcl adventures; I always run abcl as a separate process in a j Lisp shell when I'm doing abcl development.) Another advantage is that you can restart abcl without restarting j. (Closing an embedded abcl window and then running embedded Lisp again without restarting j just gets you a new window on the same embedded instance of abcl.) -Peter |
From: glr <gl...@rc...> - 2004-08-02 20:03:30
|
On Mon, 2 Aug 2004 10:25:07 -0700, Peter Graves <pe...@ar...> wrote: > On Mon, 02 Aug 2004 at 11:39:13 -0700, glr wrote: >> OK ... Another try. >> >> 1) From CVS this morning >> 2) Did ant clean >> 3) Deleted anything with ".cls" or ".abcl" from org/armedbear/lisp >> 4) Ran ant all (using jdk142 and ant1.6.2 under win2k pro) >> 5) Everything OK at this point - j.jar created >> 6) Executed java -jar j.jar to get editor >> 7) Started embedded lisp > ^^^^^^^^ > This is probably the culprit. > > "Embedded" Lisp is the instance of abcl that's embedded in the > currently-running instance of j. You really shouldn't use embedded Lisp > unless you plan to use it to interact with the running instance of j in > some way (to do editor-related customization, for example). > Doesn't appear to help. From the command line (no jar/editor involvement): 1) Executed java org.armedbear.lisp.Main 2) From prompt: (compile-system) (having guaranteed no cls and no abcl files exist) still yields the dump. 3) I also noticed that in format.lisp the (define-condition format-error ...) seems to be committed out. dump: [lots of snipping] ; Compiling C:\temp\j\j\src\org\armedbear\lisp\asdf.lisp ... ; Processing macro AIF ; Macro AIF => asdf-1.cls ; Processing function PATHNAME-SANS-NAME+TYPE ; PATHNAME-SANS-NAME+TYPE => asdf-2.cls ; Installing dummy function for PATHNAME-SANS-NAME+TYPE ; Processing macro APPENDF ; Macro APPENDF => asdf-3.cls ; Processing function SYSDEF-ERROR ; SYSDEF-ERROR => asdf-4.cls ; Installing dummy function for SYSDEF-ERROR ; Processing function COMPONENT-PARENT-PATHNAME ; COMPONENT-PARENT-PATHNAME => asdf-5.cls ; Installing dummy function for COMPONENT-PARENT-PATHNAME ; Processing function SPLIT ; SPLIT => asdf-6.cls ; Installing dummy function for SPLIT ; Processing function COERCE-NAME ; Compiling ALPHANUMERICP ... ; Compiled ALPHANUMERICP ; Compiling CHAR/= ... ; Compiled CHAR/= ; Compiling CHAR< ... ; Compiled CHAR< ; Compiling CHAR> ... ; Compiled CHAR> ; Compiling CHAR>= ... ; Compiled CHAR>= ; Compiling CHAR-NOT-EQUAL ... ; Compiled CHAR-NOT-EQUAL ; COERCE-NAME => asdf-8.cls ; Installing dummy function for COERCE-NAME ; Processing function SYSTEM-DEFINITION-PATHNAME ; SYSTEM-DEFINITION-PATHNAME => asdf-10.cls ; Installing dummy function for SYSTEM-DEFINITION-PATHNAME ; Processing function SYSDEF-CENTRAL-REGISTRY-SEARCH ; SYSDEF-CENTRAL-REGISTRY-SEARCH => asdf-12.cls ; Installing dummy function for SYSDEF-CENTRAL-REGISTRY-SEARCH ; Processing function FIND-SYSTEM ; FIND-SYSTEM => asdf-13.cls ; Installing dummy function for FIND-SYSTEM ; Processing function REGISTER-SYSTEM ; REGISTER-SYSTEM => asdf-15.cls ; Installing dummy function for REGISTER-SYSTEM ; Processing function SYSTEM-REGISTERED-P ; SYSTEM-REGISTERED-P => asdf-17.cls ; Installing dummy function for SYSTEM-REGISTERED-P ; Processing function NODE-FOR ; NODE-FOR => asdf-18.cls ; Installing dummy function for NODE-FOR ; Processing function MAKE-SUB-OPERATION ; MAKE-SUB-OPERATION => asdf-19.cls ; Installing dummy function for MAKE-SUB-OPERATION ; Processing function OPERATE ; Note: There is no class named FORMAT::FORMAT-ERROR. ; Unable to compile function OPERATE Debugger invoked on condition of type ERROR: There is no class named FORMAT::FORMAT-ERROR. Restarts: 0: TOP-LEVEL Return to top level. [1] ASDF(2): The top of the backtrace yields: 0: (EXTENSIONS:BACKTRACE-AS-LIST) 1: (FIND-CLASS FORMAT::FORMAT-ERROR) 2: (MAKE-CONDITION FORMAT::FORMAT-ERROR :COMPLAINT "Unknown directive.") 3: (APPLY #<FUNCTION MAKE-CONDITION> FORMAT::FORMAT-ERROR (:COMPLAINT "Unknown directive.")) 4: (SYSTEM::COERCE-TO-CONDITION FORMAT::FORMAT-ERROR (:COMPLAINT "Unknown directive.") SIMPLE-ERROR ERROR) 5: (ERROR FORMAT::FORMAT-ERROR :COMPLAINT "Unknown directive.") 6: (FORMAT::EXPAND-DIRECTIVE #S(FORMAT::FORMAT-DIRECTIVE :STRING "~@<Continue, treating ~S on ~S as ~ having been successful.~@:>" :START 34 :END 36 :CHARACTER #\Return :COLONP NIL :ATSIGNP NIL :PARAMS NIL) (" " #S(FORMAT::FORMAT-DIRECTIVE :STRING "~@<Continue, treating ~S on ~S as ~ having been successful.~@:>" :START 76 :END 76 :CHARACTER #\_ :COLONP T :ATSIGNP NIL :PARAMS NIL) "having " #S(FORMAT::FORMAT-DIRECTIVE :STRING "~@<Continue, treating ~S on ~S as ~ having been successful.~@:>" :START 83 :END 83 :CHARACTER #\_ :COLONP T :ATSIGNP NIL :PARAMS NIL) "been " #S(FORMAT::FORMAT-DIRECTIVE :STRING "~@<Continue, treating ~S on ~S as ~ having been successful.~@:>" :START 88 :END 88 :CHARACTER #\_ :COLONP T :ATSIGNP NIL :PARAMS NIL) "successful.")) |
From: Peter G. <pe...@ar...> - 2004-08-03 00:21:16
|
On Mon, 02 Aug 2004 at 15:03:20 -0700, glr wrote: > ; Processing function OPERATE > ; Note: There is no class named FORMAT::FORMAT-ERROR. > ; Unable to compile function OPERATE > Debugger invoked on condition of type ERROR: > There is no class named FORMAT::FORMAT-ERROR. > Restarts: > 0: TOP-LEVEL Return to top level. > [1] ASDF(2): I get this: ; Processing function OPERATE ; Note: nesting level > 0, not supported ; Unable to compile function OPERATE which is just a benign failure on the part of the compiler, and the build continues uneventfully. I don't know why it's working for me and not for you. You might try commenting out the "asdf.lisp" line in compile- system.lisp, just to see if you get any further. -Peter |
From: glr <gl...@rc...> - 2004-08-02 16:41:22
|
> > Normally I do rm *.abcl *.cls in src/org/armedbear/lisp, rebuild all > the abcl .java files (if they've changed at all) and restart abcl > before doing COMPILE-SYSTEM, and I always try to make sure that works > correctly before committing any changes to the compiler. > Dumb question: How does one (just) rebuild abcl files without doing a compile-system? |
From: Peter G. <pe...@ar...> - 2004-08-02 16:59:59
|
On Mon, 02 Aug 2004 at 11:41:13 -0700, glr wrote: > > > > Normally I do rm *.abcl *.cls in src/org/armedbear/lisp, rebuild all > > the abcl .java files (if they've changed at all) and restart abcl > > before doing COMPILE-SYSTEM, and I always try to make sure that works > > correctly before committing any changes to the compiler. > > > > Dumb question: How does one (just) rebuild abcl files without doing a > compile-system? (compile-file "foo.lisp") or (using a non-standard repl trick): :cf foo -Peter |
From: Andras S. <as...@ma...> - 2004-08-02 19:09:07
|
On Mon, 2 Aug 2004, Peter Graves wrote: > (For now, there are always likely to be "expected problems", meaning > code that can't be compiled and is therefore re left for the > interpreter, but that sort of thing shouldn't interfere with > correctness or cause any real trouble in practice.) Symbol macros seem to be an exception; they do cause problems when compiled. Andras |
From: Peter G. <pe...@ar...> - 2004-08-02 19:27:35
|
On Mon, 2 Aug 2004 at 21:09:05 +0200, Andras Simon wrote: > Symbol macros seem to be an exception; they do cause problems when > compiled. Do you have a small, self-contained test case? -Peter |
From: Andras S. <as...@ma...> - 2004-08-02 20:00:07
|
On Mon, 2 Aug 2004, Peter Graves wrote: > On Mon, 2 Aug 2004 at 21:09:05 +0200, Andras Simon wrote: >> Symbol macros seem to be an exception; they do cause problems when >> compiled. > > Do you have a small, self-contained test case? Compiling and loading a file that has this: (define-symbol-macro smm 1) (defun test () (print (type-of smm)) (print smm) (print (+ 3 smm))) produces T 1 Error: The value org.armedbear.lisp.SymbolMacro@6e10d8 is not of type number. when TEST is called. (Yesterday it was a bit different: (print smm) gave org.armedbear.lisp.SymbolMacro@6e10d8). Andras |
From: glr <gl...@rc...> - 2004-08-02 15:43:46
|
OK ... 1) I downloaded from the CVS this morning (Monday). 2) Ran basic build under jdk142 and got: c:\temp\j\j>ant all ant all Buildfile: build.xml ... BUILD SUCCESSFUL Total time: 43 seconds c:\temp\j\j>java -cp j.jar org.armedbear.lisp.Main java -cp j.jar org.armedbear.lisp.Main Armed Bear Common Lisp 0.0.3.16+ (built Mon Aug 02 2004 10:31:36 PDT) Java 1.4.2_03 Sun Microsystems Inc. Java HotSpot(TM) Client VM Low-level initialization completed in 0.972 seconds. Error: unhandled condition: #<ERROR @ #xe45076> Evaluation stack: 0: (SYSTEM::LOAD-COMPILED-FUNCTION "C:\\temp\\j\\j\\src\\org\\armedbear\\lisp\\macros-1.cls") 1: (SYSTEM::LOAD-SYSTEM-FILE "macros") org.armedbear.lisp.ConditionThrowable at org.armedbear.lisp.Primitives$73.execute(Primitives.java:1223) at org.armedbear.lisp.Primitive.execute(Primitive.java:66) at org.armedbear.lisp.Lisp.signal(Lisp.java:367) at org.armedbear.lisp.Lisp.eval(Lisp.java:420) at org.armedbear.lisp.dolist.execute(dolist.java:109) at org.armedbear.lisp.Lisp.eval(Lisp.java:427) at org.armedbear.lisp.SpecialOperators._let(SpecialOperators.java:168) at org.armedbear.lisp.SpecialOperators.access$000(SpecialOperators.java:26) at org.armedbear.lisp.SpecialOperators$3.execute(SpecialOperators.java:66) at org.armedbear.lisp.Lisp.eval(Lisp.java:427) at org.armedbear.lisp.Primitives$135.execute(Primitives.java:2962) at org.armedbear.lisp.Lisp.eval(Lisp.java:427) at org.armedbear.lisp.Closure.execute(Closure.java:478) at org.armedbear.lisp.Lisp.funcall(Lisp.java:131) at org.armedbear.lisp.Lisp.eval(Lisp.java:438) at org.armedbear.lisp.Primitives$82.execute(Primitives.java:1484) at org.armedbear.lisp.Lisp.eval(Lisp.java:427) at org.armedbear.lisp.SpecialOperators._let(SpecialOperators.java:168) at org.armedbear.lisp.SpecialOperators.access$000(SpecialOperators.java:26) at org.armedbear.lisp.SpecialOperators$3.execute(SpecialOperators.java:66) at org.armedbear.lisp.Lisp.eval(Lisp.java:427) at org.armedbear.lisp.Primitives$135.execute(Primitives.java:2962) at org.armedbear.lisp.Lisp.eval(Lisp.java:427) ... 3) Basic build ran OK. 4) Barfed when I attempted to execute result to do "compile-system". No, there was no cls (originally) files created. 5) None of this happens when I build/run from the src zip on armedbear.org (which I believe is 0.0.3.16). There are other problems, however. Anyone have a clue? glr |
From: Peter G. <pe...@ar...> - 2004-08-02 16:35:18
|
On Mon, 02 Aug 2004 at 10:43:35 -0700, glr wrote: > OK ... > > 1) I downloaded from the CVS this morning (Monday). > 2) Ran basic build under jdk142 and got: > > c:\temp\j\j>ant all > ant all > Buildfile: build.xml > ... > BUILD SUCCESSFUL > Total time: 43 seconds > c:\temp\j\j>java -cp j.jar org.armedbear.lisp.Main > java -cp j.jar org.armedbear.lisp.Main > Armed Bear Common Lisp 0.0.3.16+ (built Mon Aug 02 2004 10:31:36 PDT) > Java 1.4.2_03 Sun Microsystems Inc. > Java HotSpot(TM) Client VM > Low-level initialization completed in 0.972 seconds. > Error: unhandled condition: #<ERROR @ #xe45076> > Evaluation stack: > 0: (SYSTEM::LOAD-COMPILED-FUNCTION > "C:\\temp\\j\\j\\src\\org\\armedbear\\lisp\\macros-1.cls") ^^^^^^^^^^^^ The fact that it's trying to load a .cls file means that there was at least one .abcl file lying around when you started abcl after doing the ant build. The safest thing to do, when building abcl, is to delete all the .abcl and .cls files in the src/org/armedbear/lisp directory before trying to restart abcl after you have rebuilt the Java source (using ant or make). If you don't delete the .abcl files, things might work fine, or you might get the sort of problem you're reporting above, depending on how far out of sync things are. For example, changes to the .java files might have removed something that was required by the old .cls files. (It's also possible, and in fact a more common case, that a new version of the compiler won't work unless you have a new version of the .java files, but that's not what's happening here.) The confusion is compounded because abcl will probably encounter the error while trying to load its library files, so it might not be in a position to produce a useful error message. So, to summarize, for best results follow these steps: 1. Delete all the .class files in src/org/armedbear/lisp. "ant clean" or "make clean" should suffice. 2. Rebuild the .java files using ant or make. 3. Delete all the .abcl and .cls files in src/org/armedbear/lisp. 4. Fire up abcl. 5. Do COMPILE-SYSTEM. 6. Restart abcl again to pick up the freshly-compiled files. If you're working on abcl itself and you know what you're doing, you can often skip some of these steps. But if you encounter odd problems, following these steps is your best bet. -Peter |
From: Andras S. <as...@ma...> - 2004-08-02 19:35:15
|
On Mon, 2 Aug 2004, glr wrote: > OK ... > > 1) I downloaded from the CVS this morning (Monday). > 2) Ran basic build under jdk142 and got: > > c:\temp\j\j>ant all > ant all > Buildfile: build.xml > ... > BUILD SUCCESSFUL > Total time: 43 seconds Does this happen on a Cray? I don't use ant to build abcl, so I don't know for sure what 'ant all' does, but if it compiles all the Java files, I'm surprised it only takes 43 seconds. > c:\temp\j\j>java -cp j.jar org.armedbear.lisp.Main java -cp j.jar > org.armedbear.lisp.Main Armed Bear Common Lisp 0.0.3.16+ (built Mon > Aug 02 2004 10:31:36 PDT) Java 1.4.2_03 Sun Microsystems Inc. Java > HotSpot(TM) Client VM Low-level initialization completed in 0.972 > seconds. Error: unhandled condition: #<ERROR @ #xe45076> Evaluation > stack: 0: (SYSTEM::LOAD-COMPILED-FUNCTION > "C:\\temp\\j\\j\\src\\org\\armedbear\\lisp\\macros-1.cls") 1: Are you sure you don't have stale .abcl files around? Andras |
From: glr <gl...@rc...> - 2004-08-02 12:17:45
|
------- Forwarded message ------- From: "Andras Simon" <as...@ma...> To: glr <gl...@rc...> Subject: Re: [jfli-users] jfli for abcl: Followup Date: Sun, 1 Aug 2004 22:43:16 +0200 (CEST) On Sun, 1 Aug 2004, glr wrote: > Andras ... > > My apologies. It turns out that the source zip available from > armedbear.org will compile just fine. Good! In general, arm...@li... is the best place for asking abcl-related questions, because, unlike me, Peter Graves (author of abcl) can answer them. > > What's interesting to note is that after getting everything rebuilt, it > turns out (at least in the sense of the sql test) that abcl is only a > bit over 2x slower than the compiled lispworks version. It says > something about the overhead of the lisp -> jni -> java overhead. (It's interesting for another reason, too: just a few days ago, it was at least 10 times slower then the LW version, but now I get the same result as you do. abcl is evolving pretty fast!) But I'm not sure it gives much insight into where LW is spending the most time. Profiling would probably tell us more. Also, the version of the sql test which uses abcl's built-in Lisp->Java functions is almost twice as fast as the LW/jfli version. This suggests that the jfli layer (in jfli.lisp, as opposed to the direct jni calls in jni.lisp) adds a non-negligible overhead. Perhaps we should move this discussion to the jfli list, so people have a chance to voice their views. Andras -- Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/ |
From: Peter G. <pe...@ar...> - 2004-08-02 14:12:58
|
On Mon, 02 Aug 2004 at 07:17:26 -0700, glr wrote: > > What's interesting to note is that after getting everything > > rebuilt, it turns out (at least in the sense of the sql test) that > > abcl is only a bit over 2x slower than the compiled lispworks > > version. It says something about the overhead of the lisp -> jni -> > > java overhead. > > (It's interesting for another reason, too: just a few days ago, it > was at least 10 times slower then the LW version, but now I get the > same result as you do. abcl is evolving pretty fast!) I've been doing a lot of work on the JVM compiler over the past week or so. The number of compilation failures (where ABCL punts back to the interpreter) on the ANSI test suite is down from ~5000 a week ago to around 230 now. This doesn't affect correctness, but it does mean that a lot of functions that couldn't being compiled a week ago can be compiled today, so they (and things in general) will run much faster. Of course, if you're not compiling the code, I can't explain the improvement! -Peter |
From: Andras S. <as...@ma...> - 2004-08-02 19:05:32
|
On Mon, 2 Aug 2004, Peter Graves wrote: > I've been doing a lot of work on the JVM compiler over the past week or > so. The number of compilation failures (where ABCL punts back to the > interpreter) on the ANSI test suite is down from ~5000 a week ago to > around 230 now. This doesn't affect correctness, but it does mean that > a lot of functions that couldn't being compiled a week ago can be > compiled today, so they (and things in general) will run much faster. The rate of improvement is truly amazing! Andras |
From: Peter G. <pe...@ar...> - 2004-08-02 21:37:30
|
On Mon, 2 Aug 2004 at 21:35:12 +0200, Andras Simon wrote: > Does this happen on a Cray? I don't use ant to build abcl, so I don't > know for sure what 'ant all' does, but if it compiles all the Java > files, I'm surprised it only takes 43 seconds. 43 seconds is way slow: ; Loading /home/peter/depot/j/customizations.lisp ... ; Loaded /home/peter/depot/j/customizations.lisp (0.0020 seconds) JDK: /home/peter/blackdown/j2sdk1.4.2/ Java compiler: jikes Options: +D -g Build completed successfully in 2.129 seconds. This is a full build of all the Java files on an Athlon 2100+, using jikes with build-abcl.lisp, which I hope to check in later today. -Peter |
From: Andras S. <as...@ma...> - 2004-08-03 11:05:47
|
On Mon, 2 Aug 2004, Peter Graves wrote: > On Mon, 2 Aug 2004 at 21:35:12 +0200, Andras Simon wrote: >> Does this happen on a Cray? I don't use ant to build abcl, so I don't >> know for sure what 'ant all' does, but if it compiles all the Java >> files, I'm surprised it only takes 43 seconds. > > 43 seconds is way slow: > > ; Loading /home/peter/depot/j/customizations.lisp ... > ; Loaded /home/peter/depot/j/customizations.lisp (0.0020 seconds) > JDK: /home/peter/blackdown/j2sdk1.4.2/ > Java compiler: jikes > Options: +D -g > Build completed successfully in 2.129 seconds. > > This is a full build of all the Java files on an Athlon 2100+, using > jikes with build-abcl.lisp, which I hope to check in later today. Incredible! It's 5+ minutes here (with a 733Mhz PIII). Andras |
From: Peter G. <pe...@ar...> - 2004-08-03 17:00:41
|
On Mon, 2 Aug 2004 at 22:00:04 +0200, Andras Simon wrote: > Compiling and loading a file that has this: > > (define-symbol-macro smm 1) > > (defun test () > (print (type-of smm)) > (print smm) > (print (+ 3 smm))) > > produces > > T > 1 > Error: The value org.armedbear.lisp.SymbolMacro@6e10d8 is not of type number. > > when TEST is called. This is now fixed. The compiler should now handle the SETQ case correctly too: (defvar *x* 42) (define-symbol-macro smm2 *x*) (defun test2 () (setq smm2 7) *x*) (test2) => 7 DEFINE-SYMBOL-MACRO isn't used in abcl's library code, and there are no non-error tests of DEFINE-SYMBOL-MACRO in the ANSI test suite, so I didn't notice these problems before. I do remember that you mentioned it a while back, but at the time it was just one of many things that the compiler didn't handle. Now there aren't so many such things... ;) -Peter |
From: Andras S. <as...@ma...> - 2004-08-03 21:35:14
|
On Tue, 3 Aug 2004, Peter Graves wrote: > On Mon, 2 Aug 2004 at 22:00:04 +0200, Andras Simon wrote: >> Compiling and loading a file that has this: >> >> (define-symbol-macro smm 1) >> >> (defun test () >> (print (type-of smm)) >> (print smm) >> (print (+ 3 smm))) >> >> produces >> >> T >> 1 >> Error: The value org.armedbear.lisp.SymbolMacro@6e10d8 is not of type number. >> >> when TEST is called. > > This is now fixed. > > The compiler should now handle the SETQ case correctly too: > > (defvar *x* 42) > > (define-symbol-macro smm2 *x*) > > (defun test2 () > (setq smm2 7) > *x*) > > (test2) => 7 Great! Thanks! Andras |
From: glr <gl...@rc...> - 2005-04-20 10:19:12
|
Andras ... I don't use postgres myself. You might refer back to Sven's original posting on using JDBC. If memory serves me, he used the form "(driver (new driver.))". glr On Thu, 29 Jul 2004 16:20:20 +0200 (CEST), Andras Simon <as...@ma...> wrote: > http://www.math.bme.hu/~asimon/lisp/jfli-abcl.lisp is a port of jfli to > ABCL. I don't know how well it mimics jfli/LW, but the swt demo and the > jdbc code in > http://sourceforge.net/mailarchive/forum.php?thread_id=5112610&forum_id=41309 > appear to work. > > def-java-class does some package/symbol trickery that LispWorks > tolerates but ABCL does not. The symptom is that if you compile and > then load a file which has stuff like this: > > > (defpackage :glr > (:use :common-lisp :jfli) > (:export > :open-connection > :select > :close-connection)) > > (in-package :glr) > > (def-java-class "java.sql.DriverManager") > (def-java-class "java.sql.Connection") > (def-java-class "java.sql.Statement") > (def-java-class "java.sql.ResultSet") > (def-java-class "java.sql.ResultSetMetaData") > (def-java-class "java.util.Properties") > ;;(def-java-class "oracle.jdbc.driver.OracleDriver") > (def-java-class "org.postgresql.Driver") > > (use-package "java.lang") > (use-package "java.sql") > (use-package "org.postgresql") > > (defvar *connection* nil) > > (defun open-connection() > (declare (optimize (space 3))) > (let* ((driver (driver.new)) > (properties (properties.new)) > (connection (progn > (properties.setproperty properties "user" > "simon") > (properties.setproperty properties "password" "") > (driver.connect driver "jdbc:postgresql:mydb" > properties)))) > (setf *connection* connection))) > > ABCL will complain that the function driver.new is undefined (it is > defined and exported from the package named "org.postgresql" which is > USEd by glr; nevertheless, I'm not at all sure that this is an ABCL > bug). A workaround for now is to delete the glr package after > compiling and before loading the .abcl file. Or (untested) compile and > load a file containing only the def-java-class forms first. > > Andras > > > ------------------------------------------------------- > This SF.Net email is sponsored by BEA Weblogic Workshop > FREE Java Enterprise J2EE developer tools! > Get your free copy of BEA WebLogic Workshop 8.1 today. > http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click > _______________________________________________ > jfli-users mailing list > jfl...@li... > https://lists.sourceforge.net/lists/listinfo/jfli-users -- Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/ |