I've tried to run cl-test-grid on the new ABCL 1.4.0, but I get a lot of errors like:

..........; Compiling /home/testgrid/cl-test-grid/work-dir/agent/quicklisp/dists/quicklisp/software/cffi_0.17.1/src/cffi-abcl.lisp ... jnaASDF could not load because org.armedbear.lisp.Go.

Here is the diff comparing to 1.3.2: https://common-lisp.net/project/cl-test-grid//abcl/abcl-diff28.html

Is it a bug or some configuration option is needed?

Best regards, - Anton

08.10.2016, 19:59, "Mark Evenson" evenson@panix.com:

With a decided chill noticeable in the Northern Hemisphere, the Bear has finally sloughed off a long-needed release of ABCL.

With abcl-1.4.0, CFFI now works reliably allowing cross-platform linkage to native libraries to be initiated dynamically at runtime. Examples of using CL-CUDA to follow as their authors have time to publish.

Considerable work and testing led by Elias Pipping with contributions Olof-Joachim Frahm has led to a reasonable basis for UIOP/RUN-PROGRAM compatibility.

We have taken the time to learn enough of Maven to publish binary artifacts for both abcl.jar and abcl-contrib.jar that allow developers everywhere to more easily incorporate the Bear into their local Java build tool chains.

And we have tentatively surrendered to the current fashion by establishing GIT bridges to the ABCL source at and to more easily facilitate

Version 1.4.0

http://abcl.org/svn/tags/1.4.0/ http://abcl.org/trac/changeset/14892

08-OCT-2016

Enhancements

• Consolidated RUN-PROGRAM fixes (ferada, pipping)

• Upstream consolidated patchset (ferada)

** [r14857] Support `FILE-POSITION` on string streams. ** [r14859] Add multiple disassembler selector. ** [r14860] Add EXTERNAL-ONLY option to APROPOS. ** [r14861] Fix nested classes from JARs not visible with JSS.

• [r14840-2] (Scott L. Burson) Introduced "time of time" semantics for

{encode,decode}-universal time.

• EXTENSIONS:MAKE-TEMP-FILE now takes keyword arguments to specify

values of the prefix and suffix strings to the underlying JVM   implementation of java.io.File.createTempFile().

• [r14849] EXT:OS-{UNIX,WINDOWS}-P now provide a pre-ASDF runtime check

on hosting platform

Fixes

• [r14863] RandomCharacterFile et. al.

• [r14839] (JSS) Ensure the interpolation of Java symbol names as

strings (alan ruttenberg)

• [r14889] Fix ANSI-TEST SXHASH.8 (dmiles)

Updates

• asdf-3.1.7.26

• jna-4.2.2

Removed

• [r14885] ASDF-INSTALL was removed

-- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."

On 2016/10/10 21:36, Anton Vodonosov wrote:

In any case, org.armedbear.lisp.Go doesn't look right condition, as I understand it's this exception class is used internally by ABCL to implement non-local exits.

10.10.2016, 22:24, "Anton Vodonosov" avodonosov@yandex.ru:

...

I've tried to run cl-test-grid on the new ABCL 1.4.0, but I get a lot of errors like:

..........; Compiling /home/testgrid/cl-test-grid/work-dir/agent/quicklisp/dists/quicklisp/software/cffi_0.17.1/src/cffi-abcl.lisp ...
jnaASDF could not load because org.armedbear.lisp.Go.

Here is the diff comparing to 1.3.2: https://common-lisp.net/project/cl-test-grid//abcl/abcl-diff28.html

Is it a bug or some configuration option is needed?

It looks like ABCL is failing to initialize as a process for some reason, maybe (require :ABCL-CONTRIB) is not succeeding?

Otherwise, try nuking all the FASL files to force ABCL to compile everything it needs to execute to run under your test harness.

The VALUES for CL:LISP-IMPLEMENTATION-VERSION will give me the details I need about the JVM hosting for ABCL.

Thanks for testing, Mark

On 2016/10/13 20:23, Anton Vodonosov wrote:

CL-USER(3): (CL:LISP-IMPLEMENTATION-VERSION) "1.4.0" "OpenJDK_Client_VM-Sun_Microsystems_Inc.-1.6.0_38-b38" "i386-Linux-3.2.0-4-686-pae"

I see no errors in (require :abcl-contrib).

You can ssh to testgrid@cl-test-grid.cloud.efficito.com and reproduce yourself (your public keys exist in ~/.ssh/authorized_keys)

Not quite sure what key you have for me there, as I can't SSH with those credentials from two plausible candidates. I'll send you a copy of my mevenson@abcl.org public key under separate cover that you can update for me when you get a chance, ok?

13.10.2016, 13:17, "Mark Evenson" evenson@panix.com:

...

On 2016/10/10 21:36, Anton Vodonosov wrote:

...

In any case, org.armedbear.lisp.Go doesn't look right condition, as I understand it's this exception class is used internally by ABCL to implement non-local exits.

10.10.2016, 22:24, "Anton Vodonosov" avodonosov@yandex.ru:

...

I've tried to run cl-test-grid on the new ABCL 1.4.0, but I get a lot of errors like:

 ..........; Compiling /home/testgrid/cl-test-grid/work-dir/agent/quicklisp/dists/quicklisp/software/cffi_0.17.1/src/cffi-abcl.lisp ...
 jnaASDF could not load because org.armedbear.lisp.Go.

I have replicated this error with the following LISP-IMPLEMENTATION-VERSION setup.

"1.4.0-dev" "OpenJDK_64-Bit_Server_VM-Sun_Microsystems_Inc.-1.6.0_32-b40" "amd64-FreeBSD-11.0-RELEASE-p1"

The error stems from a failure to use Maven to download the JNA binary artifact "net.java.dev.jna/jna/4.2.2" which ABCL uses to shim the dynamic linking necessary CFFI to run. I am not sure if this is a generic problem with openjdk-6 using Maven, or the particular Maven installations that our machine happen to have. When I get a chance, I'll do some more investigation on my failing instance, and when I get access to `cl-test-grid.cloud.efficito.com`, I'll try to debug why Maven is failing for you. If necessary, we will release an abcl-1.4.1 to fix the situation.

Thanks again for the fantastic resource that is CL-TEST-GRID!

15.10.2016, 13:48, "Anton Vodonosov" avodonosov@yandex.ru:

From CFFI 0.18.0 release notes:

...

* bugfix: the ABCL backend has been fixed to handle recent JNA     changes. (Thanks to Daniel Kochmanksi.)

This might be related somehow

I've tried adding CFFI 0.18.0 to quicklisp's local-projects/ directory, but that doesn't help.

Below is a bigger quote of the console output with error and backtrace when the error happens:

; Wrote /home/testgrid/.cache/common-lisp/abcl-1.4.0-fasl42-linux-x86/home/testgrid/lisps/abcl-bin-1.4.0/abcl-contrib.jar/abcl-asdf/maven-embedder-tmp2IRAAKTB.abcl (0.288 seconds) jnaASDF could not load because org.armedbear.lisp.Go. cffiASDF could not load because org.armedbear.lisp.Go. Error loading jar:file:/home/testgrid/lisps/abcl-bin-1.4.0/abcl.jar!/org/armedbear/lisp/run-program.abcl at line 96 (offset 4172) #<THREAD "interpreter" {312564}>: Debugger invoked on condition of type ERROR org.armedbear.lisp.Go Restarts: 0: RETRY Retry compiling #<ASDF/INTERFACE:MVN "jna" "net.java.dev.jna/jna/4.2.2">. 1: ACCEPT Continue, treating compiling #<ASDF/INTERFACE:MVN "jna" "net.java.dev.jna/jna/4.2.2"> 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: TOP-LEVEL Return to top level. [1] SYS(2): :bt

0: (SYSTEM:BACKTRACE) 1: (INVOKE-DEBUGGER #<ERROR {548583}>) 2: org.armedbear.lisp.Lisp.error(Lisp.java:382) 3: org.armedbear.lisp.Java.jfield(Java.java:232) 4: org.armedbear.lisp.Java$pf_jfield.execute(Java.java:272) 5: org.armedbear.lisp.Primitive.execute(Primitive.java:123) 6: org.armedbear.lisp.Lisp.error(Lisp.java:382) 7: org.armedbear.lisp.Java.classForName(Java.java:1299) [1] SYS(3):

I make no use of Java 5 or 6, and I do not know anyone who does. I still have legacy Java 7 installs, and I do all new installs with Java 8. Having ABCL migrate to Java 7 or 8 without delay is my preference.

Blake McBride

On Fri, Nov 18, 2016 at 3:46 AM, Mark Evenson evenson@panix.com wrote:

I have finally found the time to trace down the source of errors for CL-TEST-GRID running abcl-1.4.0 tests. In short, the problem arises from the fact that SYS:RUN-PROGRAM does not run pre-Java7. This does not affect core ANSI CL behavior, but it does cause the ABCL-ASDF contrib to fail, which is used to locate and load the JNA artifact needed by CFFI.

From [the ticket I just filed][422]:

In chasing down the errors with CFFI on CL-TEST-GRID <​https://mailman.common-lisp.net/pipermail/armedbear-devel/ 2016-October/003719.html>, I have found that the [java.lang.ProcessBuilder?$Redirect][] interface used by Elias and Olof to extend SYS:RUN-PROGRAM for different types of I/O abstractions was introduced with Java 7, and will hence not work on earlier Java implementations.

ProcessBuilder.Redirect.html

Invoking ABCL-ASDF:ENSURE-MVN-VERSION, the following form causes the error

(JFIELD "java.lang.ProcessBuilder$Redirect" "INHERIT")

TODO: investigate the Java 6 APIs to see if there is a way to do I/O redirection with backwards compatibility. I currently suspect that there is no way to support Java 5/6 for this usage, which is why we never implemented I/O redirection previously.

There is undoubtedly a way re-write the SYS:RUN-PROGRAM interface so that we may invoke a process to read its output as a string in Java 5/Java 6, as it worked before. But we will have to figure out a way to advertise the different features of SYS:RUN-PROGRAM depending on the hosting VM.

Longer term, we may want to deprecate Java 5/6, but I would really have the compiler emit Java 7-compatible bytecode (mainly by passing the Java 6 verification process) before we begin that.

---

As a general survey question: would any current ABCL user be impacted if we dropped Java5/Java6 support? i.e. is there anyone "stuck" on pre-Java7 for some organizational reason?

Historically, when ORCL was absorbing SUNW from 2009-2011, there was quite a bit of uncertainty as to how available an FOSS JVM was going to be going forward, which is why we have hung onto Java5 compatibility as there was at least publicly available source to build it. Since then, ORCL has seem to commit to not only allowing openjdk-[678] to exist, but actually has synchronized their patching of their redistributed JVMs to the relevant OpenJDK version. In addition, ORCL has started to aggressively EOL previous JVMs (Java7 was EOL'd in 2015). Therefore, there is no apparent reason that end-users cannot freely use Java8 JVMs other than per-application "local ecosystem" restrictions.

It is a minor miracle that our compiler--which only outputs JVM 5 bytecode--continues to work.

Comments solicited.

-- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."