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?

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."

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)

$ rm -rf ~/.cache/common-lisp/ $ java -XX:MaxPermSize=256m -jar /home/testgrid/lisps/abcl-bin-1.4.0/abcl.jar --noinit --nosystem --eval '(require :abcl-contrib)' --eval '(load #P"/home/testgrid/cl-test-grid/work-dir/agent/quicklisp/setup.lisp")'

(require :cffi)

Best regards, - Anton

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.

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

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

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 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]:

[422]: http://abcl.org/trac/ticket/422

In chasing down the errors with CFFI on CL-TEST-GRID <​https://mailman.common-lisp.net/pipermail/armedbear-devel/2016-October/00371..., 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.

[java.lang.ProcessBuilder?$Redirect]: ​https://docs.oracle.com/javase/8/docs/api/java/lang/ProcessBuilder.Redirect....

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.

IMHO, anything we can do, as quickly as possible, to eliminate "It is a minor miracle that our compiler--which only outputs JVM 5 bytecode--continues to work" is deeply appreciated.

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."