━━━━━━━━━━━━━━━━━━━━━ ABCL 1.9.1 RELEASED
Mark Evenson ━━━━━━━━━━━━━━━━━━━━━
Table of Contents ─────────────────
1. abcl-1.9.1 .. 1. News ..... 1. CFFI compatibility ..... 2. (Alan Ruttenberg) Ability to discriminate generic function execution on sub-types of MOP:SPECIALIZER ..... 3. Overhauled relationship to later openjdk threading models ..... 4. (Uthar) Implement array types for JAVA:JNEW-RUNTIME-CLASS ..... 5. (Alejandrozf) Compiler uses of signals to fallback to interpreted form ..... 6. (Alejandrozf) Further fixes to COMPILE-FILE-PATHNAME ..... 7. (Tarn W. Burton) Avoid NIL in simple LOOP from CL:FORMAT directives ..... 8. Broad testing and tweaks across Java Long Term Support (LTS) binaries 2. Fuller details
1 abcl-1.9.1 ════════════
If one has been hesitating about using the latest ABCL because one "never uses a dot oh release", we have now sloughed off abcl-1.9.1 for your appraisal from the depths of a Bear's long winter nap. Now one can use the somewhat less buggy version of the Tenth Edition of Armed Bear Common Lisp, available, as usual, at https://abcl.org/releases/1.9.1/ or via Maven https://search.maven.org/artifact/org.abcl/abcl/1.9.1/jar.
1.1 News ────────
N.b. that when running on openjdk17 and later runtimes, there is quite a bit of necessary fiddling with command line arguments to "open" various modules to the Bear's introspective gaze. For example, see https://abcl.org/svn/tags/1.9.1/ci/create-abcl-properties.bash for the switches necessary to use CFFI to successfully run the CL+SSL test suite.
As a reward for your patience, we mention the following notable improvements:
1.1.1 CFFI compatibility ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
We improved the compiler to use wide indices for stack frame locals for the ALOAD, ASTORE, ILOAD, ISTORE, LLOAD, and LSTORE opcodes, which among other goodness, allows CFFI-TESTS to compile again. In addition, we have updated the jar artifact used by CFFI to jna-5.12.1 which includes support for native linkage on the Apple Silicon and other exotic architectures.
1.1.2 (Alan Ruttenberg) Ability to discriminate generic function execution on sub-types of MOP:SPECIALIZER ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
Following SBCL, CCL, and ECL, the Bear now accepts subtypes of MOP:SPECIALIZER as a generic function discriminator.
1.1.3 Overhauled relationship to later openjdk threading models ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
Going back to the future of the original green thread models, recent openjdk releases have started offering lightweight threading implementations. For the Bear, the ability to spawn virtual threads is indicated by the presence of :VIRTUAL-THREADS in CL:*FEATURES*. Setting the special THREADS:*THREADING-MODEL* to :VIRTUAL results in THREADS:MAKE-THREADS spawning virtual threads. On some openjdks one may have to pass a command-line switch the JVM to enable virtual threading.
1.1.4 (Uthar) Implement array types for JAVA:JNEW-RUNTIME-CLASS ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
Support for creating synthetic Java classes at runtime via JAVA:JNEW-RUNTIME-CLASS has been improved by introducing machinery for dealing with array types.
1.1.5 (Alejandrozf) Compiler uses of signals to fallback to interpreted form ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
We fall back to use an interpreted form for compilation results larger than 65535 bytes, which fixes the loading of the FirCAS computer algebra system.
1.1.6 (Alejandrozf) Further fixes to COMPILE-FILE-PATHNAME ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
We have restored the ability to compile Maxima by hopefully untangling the last kinks in the reworking of our COMPILE-FILE-PATHNAME logic.
1.1.7 (Tarn W. Burton) Avoid NIL in simple LOOP from CL:FORMAT directives ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
Simplify simple CL:LOOP requires only compound forms, in the place where returning NIL is neither permitted nor desired.
1.1.8 Broad testing and tweaks across Java Long Term Support (LTS) binaries ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
We have extensively tested against recent openjdk8, openjdk11, openjdk17, and openjdk19 binaries. Unfortunately, for openjdk17+ runtimes one needs to pass additional runtime command line switches to the hosting JVM which "open" Java modules to reflective actions.
2 Fuller details ════════════════
More details can be found in https://abcl.org/svn/tags/1.9.1/CHANGES.
Enjoy, and please CONS responsibly…
I just looked at the Maxima build problem, which I wasn't aware of until I saw the recent message that mentioned it. ABCL 1.9.0's COMPILE-FILE-PATHNAME did not cause the problem; it behaved correctly according to the CL spec.
Here is the value of
(compile-file-pathname "/mnt/maxima-5.46.0/src/numerical/f2cl-package.lisp" :output-file "binary-abcl/numerical/f2cl-package.abcl")
in four Lisps (CCL 1.12.1, SBCL 2.1.1.debian, ABCL 1.9.0, and ABCL 1.9.1):
#P"/mnt/maxima-5.46.0/src/numerical/binary-abcl/numerical/f2cl-package.abcl" #P"/mnt/maxima-5.46.0/src/numerical/binary-abcl/numerical/f2cl-package.abcl" #P"/mnt/maxima-5.46.0/src/numerical/binary-abcl/numerical/f2cl-package.abcl" #P"/mnt/maxima-5.46.0/src/binary-abcl/numerical/f2cl-package.abcl"
As you can see, the last one (ABCL 1.9.1) is the one that diverges.
I repeated that test for all of the COMPILE-FILE-PATHNAME invocations in the failed Maxima build. In every case, CCL and SBCL and ABCL 1.9.0 confirmed each others' results.
ABCL 1.9.0's COMPILE-FILE-PATHNAME produced bad output only because it received bad input.
I found the line of code in Maxima that's causing bad arguments to be passed to COMPILE-FILE-PATHNAME in ABCL but not in SBCL. A patch is attached.
armedbear-devel@common-lisp.net