- armedbear-devel - mailman3.common-lisp.net

Unable to quickload Drakma + CL+SSL on ABCL 1.3.2 - (Failed to read artifact descriptor for net.java.dev.jna:jna)
by Paul Nathan 27 Sep '15

27 Sep '15

Hello, I just downloaded ABCL 1.3.2 for OSX (curl -L -O http://abcl.org/releases/1.3.2/abcl-bin-1.3.2.tar.gz) and tried to load a few things in. Drakma & CL+SSL failed to load for me. I have copied the tracebacks to the end of the email. Please advise: is this my own error or something with ABCL? Is there more information you would like? Regards, Paul CL-USER(3): (ql:quickload :cl+ssl) To load "cl+ssl": Load 1 ASDF system: cl+ssl ; Loading "cl+ssl" .......... Using probed value of abcl-contrib: '/Users/pnathan/bin/abcl-bin-1.3.2/abcl-contrib.jar'. Added jar:file:/Users/pnathan/bin/abcl-bin-1.3.2/abcl-contrib.jar!/quicklisp/ to ASDF. Added jar:file:/Users/pnathan/bin/abcl-bin-1.3.2/abcl-contrib.jar!/mvn/ to ASDF. Added jar:file:/Users/pnathan/bin/abcl-bin-1.3.2/abcl-contrib.jar!/jss/ to ASDF. Added jar:file:/Users/pnathan/bin/abcl-bin-1.3.2/abcl-contrib.jar!/jfli/ to ASDF. Added jar:file:/Users/pnathan/bin/abcl-bin-1.3.2/abcl-contrib.jar!/asdf-jar/ to ASDF. Added jar:file:/Users/pnathan/bin/abcl-bin-1.3.2/abcl-contrib.jar!/asdf-install/ to ASDF. Added jar:file:/Users/pnathan/bin/abcl-bin-1.3.2/abcl-contrib.jar!/abcl-asdf/ to ASDF. ARTIFACT_RESOLVING net.java.dev.jna:jna:pom:4.1.0 ARTIFACT_DOWNLOADING net.java.dev.jna:jna:pom:4.1.0 @ central ( http://repo1.maven.org/maven2/, default, releases+snapshots) ARTIFACT_DOWNLOADED net.java.dev.jna:jna:pom:4.1.0 @ central ( http://repo1.maven.org/maven2/, default, releases+snapshots) ARTIFACT_RESOLVED net.java.dev.jna:jna:pom:4.1.0 jnaASDF could not load because Java exception 'org.eclipse.aether.collection.DependencyCollectionException: Failed to read artifact descriptor for net.java.dev.jna:jna:jar:4.1.0'.. #<THREAD "interpreter" {10EDE4B7}>: Debugger invoked on condition of type JAVA-EXCEPTION Java exception 'org.eclipse.aether.collection.DependencyCollectionException: Failed to read artifact descriptor for net.java.dev.jna:jna:jar:4.1.0'. Restarts: 0: RETRY Retry compiling #<ASDF/INTERFACE:MVN "jna" "net.java.dev.jna/jna/4.1.0">. 1: ACCEPT Continue, treating compiling #<ASDF/INTERFACE:MVN "jna" "net.java.dev.jna/jna/4.1.0"> as having been successful. 2: RETRY Retry compiling #<ASDF/LISP-ACTION:CL-SOURCE-FILE "cffi" "src" "cffi-abcl">. 3: ACCEPT Continue, treating compiling #<ASDF/LISP-ACTION:CL-SOURCE-FILE "cffi" "src" "cffi-abcl"> as having been successful. 4: RETRY Retry ASDF operation. 5: CLEAR-CONFIGURATION-AND-RETRY Retry ASDF operation after resetting the configuration. 6: ABORT Give up on "cl+ssl" 7: TOP-LEVEL Return to top level. CL-USER(4): (ql:quickload :drakma) To load "drakma": Load 1 ASDF system: drakma ; Loading "drakma" ARTIFACT_RESOLVING net.java.dev.jna:jna:pom:4.1.0 ARTIFACT_DOWNLOADING net.java.dev.jna:jna:pom:4.1.0 @ central ( http://repo1.maven.org/maven2/, default, releases+snapshots) ARTIFACT_DOWNLOADED net.java.dev.jna:jna:pom:4.1.0 @ central ( http://repo1.maven.org/maven2/, default, releases+snapshots) ARTIFACT_RESOLVED net.java.dev.jna:jna:pom:4.1.0 jnaASDF could not load because Java exception 'org.eclipse.aether.collection.DependencyCollectionException: Failed to read artifact descriptor for net.java.dev.jna:jna:jar:4.1.0'.. #<THREAD "interpreter" {A19A2B4}>: Debugger invoked on condition of type JAVA-EXCEPTION Java exception 'org.eclipse.aether.collection.DependencyCollectionException: Failed to read artifact descriptor for net.java.dev.jna:jna:jar:4.1.0'. Restarts: 0: RETRY Retry compiling #<ASDF/INTERFACE:MVN "jna" "net.java.dev.jna/jna/4.1.0">. 1: ACCEPT Continue, treating compiling #<ASDF/INTERFACE:MVN "jna" "net.java.dev.jna/jna/4.1.0"> as having been successful. 2: RETRY Retry compiling #<ASDF/LISP-ACTION:CL-SOURCE-FILE "cffi" "src" "cffi-abcl">. 3: ACCEPT Continue, treating compiling #<ASDF/LISP-ACTION:CL-SOURCE-FILE "cffi" "src" "cffi-abcl"> as having been successful. 4: RETRY Retry ASDF operation. 5: CLEAR-CONFIGURATION-AND-RETRY Retry ASDF operation after resetting the configuration. 6: ABORT Give up on "drakma" 7: TOP-LEVEL Return to top level. [1] CL-USER(5): 6

3 6

Pointing out ABCL "extensions" to ANSI-TEST
by Mark Evenson 15 Sep '15

15 Sep '15

Congratulations on getting the divergent ANSI-TEST suite codebases back together in one place, as well as establishing this mailing list. As a Common Lisp implementer who only really started studying the language a decade ago, I have profited immeasurably from figuring out why ABCL fails a given ANSI-TEST while other implementations don't. I would like to point out a few "extensions" to the ANSI-TEST suite that ABCL has added over the years so that other implementations might profit from them and/or that some of the ideas might be included in the ANSI-TEST suite itself. Upon reviewing the implementation of these ideas, parts of me cringe at how my younger self implemented things so I wouldn't necessarily recommend adoption of our code wholesale. 1) ASDF By the nature of how ANSI-TEST loads and runs itself, encapsulation as a "true" ASDF system (i.e. one where all the source is declared) seems a little farfetched. And maybe it is useful to be able to run the suite in places where ASDF is not available, such as when bootstrapping a new implementation. Nevertheless, we put some work into encapsulating the ANSI-SUITE into ASDF to the point that it can be loaded and the tests run that might be of interest. [ABCL defines three ASDF systems][1], namely ANSI-RT, ANSI-COMPILED, and ANSI-INTERPRETED. ANSI-RT encapsulates the regression test framework, while ANSI-COMPILED and ANSI-INTERPETED provide definitions to the point that ASDF:TEST-SYSTEM can run the compiled or interpreted tests respectively. This helps with automation of the tests in ABCL's build mechanism. The one caveat is that one cannot run tests in "parallel" on, say, different versions of your implementation that you are regression testing due to the way that ANSI-TEST uses the filesystem of the ANSI-TEST itself to keep fasls and record state for tests in the course of running the suite. [1]: http://abcl.org/trac/browser/trunk/abcl/abcl.asd#L76 2) ABCL.TEST.ANSI In order to support the necessary shenanigans to make the ANSI-COMPILED and ANSI-INTERPRETED definitions work, we [created a small set of utility routines][2]. CLEAN-TESTS performs the removal of intermediate files that the old Makefile used to do. DO-TESTS-MATCHING will run only those tests whose symbols match a regular expression, which is useful for repeatedly running a subset of tests. [2] http://abcl.org/trac/browser/trunk/abcl/test/lisp/ansi/abcl-ansi.lisp 3) ANSI-TEST error "database" We [created a simple s-expr "database"][4] for recording test failures and then [reporting on the results][3]. ABCL is a unique CL implementation because it is hosted on a JVM for which there are multiple implementations and whose behavior often varies by operating system so running the ANSI-TEST suite has proven to be fairly sensitive to hosting JVM implementation version and operating system. Thus, such a database of regressions has proven to be of special importance to ABCL. That being said, my implementation of this idea is pretty amateurish in hindsight, so I think what is important here is the idea rather than the implementation. [3]: http://abcl.org/trac/browser/trunk/abcl/test/lisp/ansi/parse-ansi-errors.li… [4]: http://abcl.org/trac/browser/trunk/abcl/test/lisp/ansi/ansi-test-failures -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."

2 1

Typo in last commit on svn
by Stefan Husmann 10 Sep '15

10 Sep '15

Hello, I think there is a typo, or, say, copy-and-paste error in the last commit on svn. abcl does not build the way it is. This is my correction. +++ a/trunk/abcl/build.xml +++ b/trunk/abcl/build.xml @@ -877,5 +877,5 @@ ${basedir}/../ansi-tests. -[1]: <git+https://gitlab.common-lisp.net/ansi-test/ansi-test.git> +[1]: git+https://gitlab.common-lisp.net/ansi-test/ansi-test.git The CL-BENCH tests require that [cl-bench][2] be manually installed in Best Regards Stefan Husmann PS: I am new on this list, so I apologize if thi has been brought up before.

2 1

Can't muffle COMPILE
by James M. Lawrence 08 Sep '15

08 Sep '15

(handler-bind ((warning #'muffle-warning)) (compile nil '(lambda () x))) => ; Caught STYLE-WARNING: ; Undefined variable X assumed special ; Compilation unit finished ; Caught 1 STYLE-WARNING condition Also, you might want that to be more than a style-warning; it's a full warning in other implementations. Best, lmj

2 1

Compiler can generate code it cannot load....
by Patrick Stein 02 Sep '15

02 Sep '15

This is a short program for which the compiler creates a file it cannot load. Save this program to a file, then try: (load (compile-file “this-file.lisp”)) ;;; This program causes the ABCL compiler to generate code it cannot load. ;;; ;;; The code compiles and loads correctly if you do any of the following: ;;; * change BUFSIZE to be 'INTEGER instead of '(INTEGER 0 100) ;;; * delete the INLINE declaration for BUFFER-LENGTH ;;; * delete the FTYPE declaration for BUFFER-LENGTH ;;; * delete the TYPE declaration for NEW-CAPACITY (deftype bufsize () '(integer 0 100)) (declaim (inline buffer-length) (ftype (function () bufsize) buffer-length)) (defun buffer-length () (the bufsize 10)) (defun calculate-new-buffer-length (new-capacity) (declare (type bufsize new-capacity)) (min (buffer-length) new-capacity)) As noted in the comment, it is very finicky. There are at least four ways this code could be slightly less-specific and then not trigger the bug. I tried it both with ABCL-1.3.1 and ABCL-1.3.2. The logs of the output are below. I’d love to be able to say that I’m looking at the compiler now to try to figure out where it’s going wrong, but realistically, I’m not going to have time to delve into it myself, I’ve never really looked at the ABCL compiler before, and I suspect the problem is in the compiling but doesn’t show up until the loading… so it won’t be as easy as exploring the stack when the error shows up. Thanks, Patrick Script started on Tue Sep 1 16:33:56 2015 bash-3.2$ cat compile-problem.lisp ;;; This program causes the ABCL compiler to generate code it cannot load. ;;; ;;; The code compiles and loads correctly if you do any of the following: ;;; * change BUFSIZE to be 'INTEGER instead of '(INTEGER 0 100) ;;; * delete the INLINE declaration for BUFFER-LENGTH ;;; * delete the FTYPE declaration for BUFFER-LENGTH ;;; * delete the TYPE declaration for NEW-CAPACITY (deftype bufsize () '(integer 0 100)) (declaim (inline buffer-length) (ftype (function () bufsize) buffer-length)) (defun buffer-length () (the bufsize 10)) (defun calculate-new-buffer-length (new-capacity) (declare (type bufsize new-capacity)) (min (buffer-length) new-capacity)) bash-3.2$ ABCL_HOME=/usr/local/src/abcl-1.3.2 abcl Armed Bear Common Lisp 1.3.2 Java 1.8.0_45 Oracle Corporation Java HotSpot(TM) 64-Bit Server VM Low-level initialization completed in 0.524 seconds. Startup completed in 2.65 seconds. Type ":help" for a list of available commands. CL-USER(1): (load (compile-file "compile-problem.lisp")) ; Compiling /Users/pat/compile-problem.lisp ... ; (DEFTYPE BUFSIZE ...) ; (DECLAIM (INLINE BUFFER-LENGTH) ...) ; (DEFUN BUFFER-LENGTH ...) ; (DEFUN CALCULATE-NEW-BUFFER-LENGTH ...) ; Wrote /Users/pat/compile-problem.abcl (0.208 seconds) java.lang.VerifyError: (class: org/armedbear/lisp/compile_problem_2, method: execute signature: (Lorg/armedbear/lisp/LispObject;)Lorg/armedbear/lisp/LispObject;) Unable to pop operand off an empty stack at java.lang.Class.getDeclaredConstructors0(Native Method) at java.lang.Class.privateGetDeclaredConstructors(Class.java:2671) at java.lang.Class.getConstructor0(Class.java:3075) at java.lang.Class.newInstance(Class.java:412) at org.armedbear.lisp.FaslClassLoader.loadFunction(FaslClassLoader.java:130) at org.armedbear.lisp.FaslClassLoader$pf_get_fasl_function.execute(FaslClassLoader.java:165) at org.armedbear.lisp.LispThread.execute(LispThread.java:832) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:582) at org.armedbear.lisp.Lisp.eval(Lisp.java:540) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:577) at org.armedbear.lisp.Lisp.eval(Lisp.java:540) at org.armedbear.lisp.Load.faslLoadStream(Load.java:667) at org.armedbear.lisp.Load$init_fasl.execute(Load.java:457) at org.armedbear.lisp.LispThread.execute(LispThread.java:832) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:582) at org.armedbear.lisp.Lisp.eval(Lisp.java:540) at org.armedbear.lisp.Load.loadStream(Load.java:629) at org.armedbear.lisp.Load.loadFileFromStream(Load.java:597) at org.armedbear.lisp.Load.load(Load.java:224) at org.armedbear.lisp.Load.load(Load.java:745) at org.armedbear.lisp.Load$_load.execute(Load.java:693) at org.armedbear.lisp.Symbol.execute(Symbol.java:852) at org.armedbear.lisp.LispThread.execute(LispThread.java:894) at org.armedbear.lisp.load_1.execute(load.lisp:33) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:98) at org.armedbear.lisp.LispThread.execute(LispThread.java:814) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:575) at org.armedbear.lisp.Lisp.eval(Lisp.java:540) at org.armedbear.lisp.Lisp.eval(Lisp.java:538) at org.armedbear.lisp.Primitives$pf__eval.execute(Primitives.java:345) at org.armedbear.lisp.LispThread.execute(LispThread.java:814) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:575) at org.armedbear.lisp.Lisp.eval(Lisp.java:540) at org.armedbear.lisp.Lisp.progn(Lisp.java:709) at org.armedbear.lisp.Primitives$sf_block.execute(Primitives.java:3742) at org.armedbear.lisp.Lisp.eval(Lisp.java:530) at org.armedbear.lisp.Lisp.progn(Lisp.java:709) at org.armedbear.lisp.Closure.execute(Closure.java:220) at org.armedbear.lisp.Closure.execute(Closure.java:148) at org.armedbear.lisp.LispThread.execute(LispThread.java:814) at org.armedbear.lisp.Lisp$1.execute(Lisp.java:285) at org.armedbear.lisp.Symbol.execute(Symbol.java:803) at org.armedbear.lisp.LispThread.execute(LispThread.java:814) at org.armedbear.lisp.top_level_47.execute(top-level.lisp:407) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:89) at org.armedbear.lisp.Symbol.execute(Symbol.java:793) at org.armedbear.lisp.LispThread.execute(LispThread.java:798) at org.armedbear.lisp.top_level_48.execute(top-level.lisp:415) at org.armedbear.lisp.LispThread.execute(LispThread.java:798) at org.armedbear.lisp.Interpreter.run(Interpreter.java:361) at org.armedbear.lisp.Main$1.run(Main.java:48) at java.lang.Thread.run(Thread.java:745) Error loading /Users/pat/compile-problem.abcl at line 15 (offset 668) #<THREAD "interpreter" {33E81276}>: Debugger invoked on condition of type ERROR Compiled function can't be loaded: org.armedbear.lisp.compile_problem_2 from org.armedbear.lisp.Pathname@2acec9eb Restarts: 0: TOP-LEVEL Return to top level. [1] CL-USER(2): 0 CL-USER(3): (quit) bash-3.2$ ABCL_HOME=/usr/local/src/abcl-bin-1.3.1 abcl Armed Bear Common Lisp 1.3.1 Java 1.8.0_45 Oracle Corporation Java HotSpot(TM) 64-Bit Server VM Low-level initialization completed in 0.471 seconds. Startup completed in 2.651 seconds. Type ":help" for a list of available commands. CL-USER(1): (load (compile-file "compile-problem.lisp")) ; Compiling /Users/pat/compile-problem.lisp ... ; (DEFTYPE BUFSIZE ...) ; (DECLAIM (INLINE BUFFER-LENGTH) ...) ; (DEFUN BUFFER-LENGTH ...) ; (DEFUN CALCULATE-NEW-BUFFER-LENGTH ...) ; Wrote /Users/pat/compile-problem.abcl (0.199 seconds) java.lang.VerifyError: (class: org/armedbear/lisp/compile_problem_2, method: execute signature: (Lorg/armedbear/lisp/LispObject;)Lorg/armedbear/lisp/LispObject;) Unable to pop operand off an empty stack at java.lang.Class.getDeclaredConstructors0(Native Method) at java.lang.Class.privateGetDeclaredConstructors(Class.java:2671) at java.lang.Class.getConstructor0(Class.java:3075) at java.lang.Class.newInstance(Class.java:412) at org.armedbear.lisp.FaslClassLoader.loadFunction(FaslClassLoader.java:130) at org.armedbear.lisp.FaslClassLoader$pf_get_fasl_function.execute(FaslClassLoader.java:165) at org.armedbear.lisp.LispThread.execute(LispThread.java:832) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:582) at org.armedbear.lisp.Lisp.eval(Lisp.java:540) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:577) at org.armedbear.lisp.Lisp.eval(Lisp.java:540) at org.armedbear.lisp.Load.faslLoadStream(Load.java:667) at org.armedbear.lisp.Load$init_fasl.execute(Load.java:457) at org.armedbear.lisp.LispThread.execute(LispThread.java:832) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:582) at org.armedbear.lisp.Lisp.eval(Lisp.java:540) at org.armedbear.lisp.Load.loadStream(Load.java:629) at org.armedbear.lisp.Load.loadFileFromStream(Load.java:597) at org.armedbear.lisp.Load.load(Load.java:224) at org.armedbear.lisp.Load.load(Load.java:745) at org.armedbear.lisp.Load$_load.execute(Load.java:693) at org.armedbear.lisp.Symbol.execute(Symbol.java:852) at org.armedbear.lisp.LispThread.execute(LispThread.java:894) at org.armedbear.lisp.load_1.execute(load.lisp:33) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:98) at org.armedbear.lisp.LispThread.execute(LispThread.java:814) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:575) at org.armedbear.lisp.Lisp.eval(Lisp.java:540) at org.armedbear.lisp.Lisp.eval(Lisp.java:538) at org.armedbear.lisp.Primitives$pf__eval.execute(Primitives.java:345) at org.armedbear.lisp.LispThread.execute(LispThread.java:814) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:575) at org.armedbear.lisp.Lisp.eval(Lisp.java:540) at org.armedbear.lisp.Lisp.progn(Lisp.java:709) at org.armedbear.lisp.Primitives$sf_block.execute(Primitives.java:3742) at org.armedbear.lisp.Lisp.eval(Lisp.java:530) at org.armedbear.lisp.Lisp.progn(Lisp.java:709) at org.armedbear.lisp.Closure.execute(Closure.java:220) at org.armedbear.lisp.Closure.execute(Closure.java:148) at org.armedbear.lisp.LispThread.execute(LispThread.java:814) at org.armedbear.lisp.Lisp$1.execute(Lisp.java:285) at org.armedbear.lisp.Symbol.execute(Symbol.java:803) at org.armedbear.lisp.LispThread.execute(LispThread.java:814) at org.armedbear.lisp.top_level_47.execute(top-level.lisp:407) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:89) at org.armedbear.lisp.Symbol.execute(Symbol.java:793) at org.armedbear.lisp.LispThread.execute(LispThread.java:798) at org.armedbear.lisp.top_level_48.execute(top-level.lisp:415) at org.armedbear.lisp.LispThread.execute(LispThread.java:798) at org.armedbear.lisp.Interpreter.run(Interpreter.java:361) at org.armedbear.lisp.Main$1.run(Main.java:48) at java.lang.Thread.run(Thread.java:745) Error loading /Users/pat/compile-problem.abcl at line 15 (offset 668) #<THREAD "interpreter" {3F8D7E88}>: Debugger invoked on condition of type ERROR Compiled function can't be loaded: org.armedbear.lisp.compile_problem_2 from org.armedbear.lisp.Pathname@28015d1d Restarts: 0: TOP-LEVEL Return to top level. [1] CL-USER(2): 0 CL-USER(3): (quit) bash-3.2$ ccl --no-init Welcome to Clozure Common Lisp Version 1.11-dev-r16393-trunk (DarwinX8664)! CCL is developed and maintained by Clozure Associates. For more information about CCL visit http://ccl.clozure.com. To enquire about Clozure's Common Lisp consulting services e-mail info(a)clozure.com or visit http://www.clozure.com. ? (load (compile-file "compile-problem.lisp")) #P"/Users/pat/compile-problem.dx64fsl" ? (quit) bash-3.2$ sbcl --no-init This is SBCL 1.2.3.13-3446e1a-dirty, an implementation of ANSI Common Lisp. More information about SBCL is available at <http://www.sbcl.org/>. SBCL is free software, provided as is, with absolutely no warranty. It is mostly in the public domain; some portions are provided under BSD-style licenses. See the CREDITS and COPYING files in the distribution for more information. * (load (compile-file "compile-problem.lisp")) ; compiling file "/Users/pat/compile-problem.lisp" (written 01 SEP 2015 04:33:38 PM): ; compiling (DEFTYPE BUFSIZE ...) ; compiling (DECLAIM (INLINE BUFFER-LENGTH) ...) ; compiling (DEFUN BUFFER-LENGTH ...) ; compiling (DEFUN CALCULATE-NEW-BUFFER-LENGTH ...) ; /Users/pat/compile-problem.fasl written ; compilation finished in 0:00:00.007 T * (quit) bash-3.2$ exit Script done on Tue Sep 1 16:36:21 2015

2 2

Better integration between ABCL & Java
by Blake McBride 30 Aug '15

30 Aug '15

Greetings, I worked hard on a project to link ABCL with a very large Java application. Although the addition of ABCL to that project failed, the work I did could be of use, and with some effort could be made to solve the problem I had. I believe the original problem I had would be a very common problem in similar circumstances. My pre-existing Java application has almost 10,000 classes! I wasn't about to create lisp cover functions for each java method. I also wasn't going to use a convoluted syntax to get to java each time. What I did was create some Java and Lisp code that, through reflection, caused the system to auto-generate a complete set of CLOS classes to mirror my primary java application classes - including the class hierarchy. The methods in these CLOS classes would call the Java methods. With this, when in Lisp, I could just use all of my Java classes and methods as regular CLOS classes and methods. It's use of Java classes and methods internally was transparent to lisp. All of this worked fine. The problem I ran into was the fact that Java can have several methods with the same name but different arguments. So, the Java method being called depended on the types and number of arguments too (not just the class of the instance and the method name). I never solved this, although I think it could be. I just ran out of time and steam, as well as other non-technical reasons. The reason I bring this all up now is because I am unclear about what problems Ralph is trying to solve. I thought what I have done may be of use. Thanks. Blake McBride

5 5

All conformance ansi-test's passed
by Ralph Ritoch 27 Aug '15

27 Aug '15

Hello, I have been able to get ABCL to pass all of the ansi conformance tests. While this is not an official ABCL release, all of the modifications I made are released under the MIT license and may be freely integrated into ABCL at the discretion of the maintainers. To embed this conforming version into your java applications add the following dependencies which have been released at maven central. <dependency> <groupId>com.vnetpublishing.lisp</groupId> <artifactId>jrelisp-abcl-impl</artifactId> <version>0.0.2</version> </dependency> <dependency> <groupId>com.vnetpublishing.lisp</groupId> <artifactId>jrelisp-abcl-contrib</artifactId> <version>0.0.2</version> </dependency> The source code for this release can be found at https://github.com/rritoch/jrelisp-abcl/tree/55e808d3c0084d16d1ed04c36a6f5a… . While I have moved some files around it is still an ABCL implementation that is mostly backwards-compatible with the official ABCL releases. Moving forward it is likely that any future development on these branches will further deviate from ABCL. I am not claiming that this solves EVERY compliance issue but I have found solutions for each of the ansi conformance test failures. Any remaining compliance issues can be considered a bug. My primary intention of passing every test is to lock the build process so that builds will fail if any of the ansi tests fail. It is unlikely that future modifications to these forks will have any relevance to ABCL. I will likely continue developing features that are needed for modern application development and therefore are of little interest to some, if not all, of the ABCL maintainers. That being said, v0.0.2 is the best release to source conformance solutions from for ABCL as it passes every conformance test. Any future releases will no longer be based on improving ABCL but be for the purpose of better supporting modern application development. Best Regards, Ralph Ritoch

5 7

loading lisp files from inside the java jar
by Hamda Binte Ajmal 18 Aug '15

18 Aug '15

Hi, I am sending this message again, as the last thread went a little too far. I have developed a Java Application that runs lisp code at the back end, and I use ABCL for that. Before using the lisp commands, I load a few .lisp files so that I can call the functions defined in those files. Everything works fine as long as I run the application from Netbeans. When I run the application from the jar file, it throws 'File not found error'. as the lisp files are not a part of file system inside the project jar. I tried to follow the suggestions given by Mark (load “jar:file:/absolute/path/to/file.jar!/path/within/jar/setup.lisp”) It shows the same File not found error. Am i missing something here? As suggested by Ralph to use (load-system-file "path/to/resource.lisp"), I tried to use that, but I was unable to access sys package, please let me know how to do this. I find the help documentation and tutorials very confusing, and difficult to understand. Any hints will be appreciated. Thanking in anticipation. Regards, Hamda NUIG, Ireland.

5 13

Re: Lisp filepath issues when running application directly from jar file
by Ralph Ritoch 17 Aug '15

17 Aug '15

This "idiot" refactored a very small portion of your code making it MUCH faster, and also passed more than 90% of the tests ABCL is currently failing, leaving only 3 ansi-tests that are still failing. If I'm an idiot it doesn't say much about you since you've been working on this for years and I've only been working on it for weeks. Best Regards, Ralph Ritoch On Mon, Aug 17, 2015 at 8:00 PM, <armedbear-devel-request(a)common-lisp.net> wrote: > Send armedbear-devel mailing list submissions to > armedbear-devel(a)common-lisp.net > > To subscribe or unsubscribe via the World Wide Web, visit > https://mailman.common-lisp.net/listinfo/armedbear-devel > or, via email, send a message with subject or body 'help' to > armedbear-devel-request(a)common-lisp.net > > You can reach the person managing the list at > armedbear-devel-owner(a)common-lisp.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of armedbear-devel digest..." > > > Today's Topics: > > 1. Re: Lisp filepath issues when running application directly > from jar file (Mark Evenson) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 16 Aug 2015 14:38:44 +0200 > From: Mark Evenson <evenson(a)panix.com> > To: Armed Bear <armedbear-devel(a)common-lisp.net> > Subject: Re: Lisp filepath issues when running application directly > from jar file > Message-ID: <5616917D-F789-4F95-93E2-FC3B7633B051(a)panix.com> > Content-Type: text/plain; charset="utf-8" > > > > On Aug 16, 2015, at 02:34, Ralph Ritoch <rritoch(a)gmail.com> wrote: > > > > I have used this function in my code without ANY problems. [?] > > The SYSTEM package is not intended to be used by users unless there is no > alternative. The manual states clearly that functionality provided by > SYSTEM > is subject to be changed between major releases without warning. > Therefore, > the argument in this case isn?t that one would have problems using > SYSTEM:LOAD-SYSTEM-FILE, but rather that one should use the ANSI interface > as > implemented CL:LOAD which should be able to load Lisp and/or fasls in all > cases > needed by the user. My work on EXT:JAR-PATHNAME and EXT:URL-PATHNAME was > motivated by precisely the need for CL:LOAD to work in all conceivable > cases in > the JVM ecology. And the best contemporary mechanism for expression for > resolution of and dependency order for CL:LOAD lies in ASDF, hence my > emphasis on using its abstraction where extending CL:LOAD is not desirable. > > As a side note, over time, we wish to move functions in SYSTEM which > useful to > the user into the EXTENSION package, but this work is incomplete at best. > Currently, there are indeed cases in which using a function from SYSTEM is > unavoidable. The use of SYSTEM:LOAD-SYSTEM-FILE is not one of them. > > > Your attitude regarding "progress" is archaic. If you don't want to > support maven or other java technologies why do you even bother controlling > abcl? > > > Your attitude towards discussion is not only archaic (i.e. immature) but > counterproductive towards reaching the sort of consensus needed for > progress. > > However misguided such an endeavor may be, a couple points follow towards a > defense from your sleazy ad hominem ?argumentation?. > > As for supporting Maven, I have developed the machinery to use Maven > artifacts > in ABCL-ASDF, and continued to maintain them (with help from users) even > as the > lurching horror that comprises Maven release engineering continues to > change > API semantics between patch level releases. I have offered to collaborate > with you on incorporating your initial work on building from Maven, > pointing > out the problems that I see with your approach to which I have received no > reply. > > As for supporting ?other technologies?, I suppose you are referring to your > attempt to merge abcl-contrib.jar and abcl.jar. In this effort, I pointed > out > you could do this cleanly with the current code by adding site-specific > code to > the ?system.lisp? file whose contents are controlled by the Ant build > process. > Since your Maven build doesn?t use the Ant target to package (one of my > explicit criticisms), you presumedly weren?t interested in using this > mechanism. I responded twice to your proposal to probe jar files on the > classpath for code to pontential load with suggestions which you found too > burdensome to discuss so you developed what you needed. Your email > announcing > this implementation implied you had implemented to a ?specification?, but > no > such entity existed external to the source code. If you wish to provide > such a > specification for your current implementation, please do so that others may > consider its usefulness. > > As to whether I control ABCL, I was going to reply that I am but one > maintainer > out of five; that you are welcome to convince a majority of the maintainers > through useful and accepted contributions that that you should be in > ?control? > too; and that since the code is GPL?d so you are welcome to get the fork > out of > here. But at this point, I would reply that if I do somehow ?control? > ABCL, I > am glad to protect it from idiots like you. > > -- > "A screaming comes across the sky. It has happened before but there is > nothing > to compare to it now." > > > > > >

5 7

Lisp filepath issues when running application directly from jar file
by Hamda Binte Ajmal 17 Aug '15

17 Aug '15

Hi, I was working on an application, that loads a few lisp files using lisp command (load "fullfilepath.lisp") from java using ABCL. This file in turn loads the other lisp files located in same folder hierarchy, and then i call lisp functions (defined in these files) from java and everything works perfect as long as I run the application from Netbeans. Close to deployment, I tested the application by running it from jar file, I found that there are issues with filepaths, as the files are not a part of file-system, and hence not accessible using a file-path. Does anyone has any idea how to fix this issue ? I tried many things, like URL url = LispConnector.class.getResource("/Aima/aima/quicklisp/setup.lisp");String path = url.getFile();File f = new File(path); path = f.getAbsolutePath(); path = path.replace("\\", "/"); which returns [image: enter image description here] But which is wrong as this is not a valid file path and does not exists so lisp : (load "filepath") fails here. When I use the code String path = url.toURI();File = new File(path); path = path.getAbsolutePath(); Again it works fine while running from netbeans, but shows error "URI is not hierarchical" error while running the jar file. Has anyone encountered this issue, please help. -- Hamda Binte Ajmal NUIG, Ireland

2 2