As part of the continued effort to increase ABCL's practical usability (as opposed to its theoretical compliance to the CLHS), we've fixed compilation problems where ABCL would crash with a stack overflow when compiling CLOSURE-HTML.
The problem turned out to be that ABCL's fasl format didn't support serialization of circular structures. Apparently, very few libraries actually use the ability to serialize circular literals, but CLOSURE-HTML does.
The fix required changing the FASL version number. If you're working off trunk, you'll be required to do a full recompile of your work.
Tuesday, September 20, 2011
Sunday, September 11, 2011
DEFINE-METHOD-COMBINATION (long form) no longer experimental
Last year around the same time ABCL 0.23 was released. This release featured experimental support for the long form of DEFINE-METHOD-COMBINATION. Last February I started testing our implementation using tests that I found in SBCL's test suite. Unfortunately, I quickly found the implementation wasn't labeled experimental without reason and started fixing the tests one by one.
After other priorities interrupted my work in March, I picked up the remaining work two weeks ago. Today, I committed the last test cases ported from SBCL's test suite. They all work. Particularly hard to get right were the ones involving the (:ARGUMENTS . arguments-list) cases.
With the status that we have now DEFINE-METHOD-COMBINATION (long form) is no longer considered experimental! We're another step closer to full CLHS compliance!
After other priorities interrupted my work in March, I picked up the remaining work two weeks ago. Today, I committed the last test cases ported from SBCL's test suite. They all work. Particularly hard to get right were the ones involving the (:ARGUMENTS . arguments-list) cases.
With the status that we have now DEFINE-METHOD-COMBINATION (long form) is no longer considered experimental! We're another step closer to full CLHS compliance!
Saturday, September 3, 2011
ABCL 0.27.0 released
On behalf of the developers of ABCL (Armed Bear Common Lisp) I'm glad to
be able to announce the 0.27.0 release.
This release features - among other things - wider compatibility for Quicklisp encapsulated systems basedon reports for problems with ABCL: fixes for PARENSCRIPT, NAMED-READTABLES and CL-INTERPOL (CL-UNICODE fix).
Additionally, ABCL has regained the ability to build SBCL. The release notes can be found at:
http://common-lisp.net/project/armedbear/release-notes-0.27.shtml
and the list of changes at:
http://trac.common-lisp.net/armedbear/browser/trunk/abcl/CHANGES
If you have questions regarding use or licensing, or you find issues, please
report back to the development list:
armedbear-devel at common-lisp dot net
Source distribution archives can be downloaded in ZIP or gzipped tar form:
abcl-src-0.27.0.tar.gz
abcl-src-0.27.0.zip
Signatures are available under:
abcl-src-0.27.0.tar.gz.asc
abcl-src-0.27.0.zip.asc
In addition, binaries are also available:
abcl-bin-0.27.0.tar.gz
abcl-bin-0.27.0.zip
With associated signatures:
abcl-bin-0.27.0.tar.gz.asc
abcl-bin-0.27.0.zip.asc
JVM classpath integration (Maven et. al.)
Disclaimer: I loathe Maven. But I love users, so by unpopular (to me) demand as part of the upcoming abcl-0.27.0 release we've bowed to the inevitable by adding integration for Armedb Bear Common Lisp with Maven in svn r13550.
We've added the ASDF:MVN subclass ASDF:COMPONENT (by way of of ASDF:IRI) that refers to a purely virtual artifact, namely a given jar specified as a mvn dependency whose classes will be loaded in the hosting JVM (i.e. added to the running *classpath*).
The following 'log4j.asd' placed in a file on your local filesystem and then added the the ASDF:*CENTRAL-REGISTRY*:
then when the abcl-contrib.jar is loaded via
CL-USER> (require 'abcl-asdf)
an invocation of
CL-USER> (asdf:load-system 'log4j)
with ensure that log4j-1.4.9.jar and all its transitive dependencies as defined by the distributed Maven POM descriptions will be downloaded to the local filesystem if not already present. It will then dynamically add all of these Java classes to the currently hosting JVM.
Further details about additional ASDF extensions for both individual jar files and contents of directories are documented within the contrib/abcl-asdf/README.markdown file from SVN trunk.
Thanks to Alan Ruttenburg for great inspiration (and code) from invoke.lisp which was the first extension to ASDF that could actuall dynamically add jar files to the hosting JVM process.
We've added the ASDF:MVN subclass ASDF:COMPONENT (by way of of ASDF:IRI) that refers to a purely virtual artifact, namely a given jar specified as a mvn dependency whose classes will be loaded in the hosting JVM (i.e. added to the running *classpath*).
The following 'log4j.asd' placed in a file on your local filesystem and then added the the ASDF:*CENTRAL-REGISTRY*:
;;;; -*- Mode: LISP -*-
(in-package :asdf)
(defsystem :log4j
:components ((:mvn "log4j/log4j"
:version "1.4.9")))
then when the abcl-contrib.jar is loaded via
CL-USER> (require 'abcl-asdf)
an invocation of
CL-USER> (asdf:load-system 'log4j)
with ensure that log4j-1.4.9.jar and all its transitive dependencies as defined by the distributed Maven POM descriptions will be downloaded to the local filesystem if not already present. It will then dynamically add all of these Java classes to the currently hosting JVM.
Further details about additional ASDF extensions for both individual jar files and contents of directories are documented within the contrib/abcl-asdf/README.markdown file from SVN trunk.
Thanks to Alan Ruttenburg for great inspiration (and code) from invoke.lisp which was the first extension to ASDF that could actuall dynamically add jar files to the hosting JVM process.
Subscribe to:
Posts (Atom)