Sunday, October 23, 2011

ABCL 1.0.0 released


On behalf of the developers of ABCL (Armed Bear Common Lisp) we are happy to be able to announce the 1.0.0 release on the premises of the European Common Lisp Meeting 2011.

ABCL is a Common Lisp implementation implemented in Java and running on the Java Virtual Machine (JVM) featuring both an interpreter and a compiler. The compiler targets the JVM directly meaning that its output is runnable JVM bytecode. The fact that ABCL is implemented in Java allows for relatively easy embedding in larger applications. For integration with existing applications ABCL completely implements the "JSR 223: Java scripting API" specification.

This release delivers the last requirement for ABCL's 1.0 release milestone, namely a conforming implementation of the long form of DEFINE-METHOD-COMBINATION. Additionally, the abcl-contrib mechanism now supports a robust collection of contributions to ABCL beyond ANSI concerned with dynamically linking JVM artifacts at runtime, packaging ASDF system construction within jar archives, and an optional higher-level domain specific syntax called JSS (Java Syntax Sucks) for manipulating JVM libraries. Extensive testing and debugging the implementation with popular Quicklisp systems has resulted in a much more rugged and battle-tested Lisp. A draft version of the user manual is now available.

The list of changes can be viewed at


If you have questions regarding use or licensing, or you find issues, please use the development email list for questions:

armedbear-devel at common-lisp dot net


Source distribution archives can be downloaded in ZIP or gzipped tar form:


Cryptographic signatures are available under:


In addition, binaries are also available:


With the associated cryptographic signatures:

Thursday, October 20, 2011

ABCL User Manual

In preparation for the upcoming ABCL 1.1.0 development release, we are releasing drafts of the ABCL User Manual for feedback.

The manual needs more love:  please submit patches to the [LaTex source][1].

[1]: http://osdir.com/ml/armedbear-devel/2011-09/msg00014.html

** Drafts




*** "Draft of upcoming abcl-1.1.0 User Manual":  abcl-manual-20120205a.pdf


*** "Rudi patches the documentation process from the version released withabcl-1.0.1 fresh from the sources via 'pdflatex' on January 28, 2012": abcl-20120124a.pdf.

Tuesday, September 20, 2011

Compilation fixes for CLOSURE-HTML landed on trunk

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.

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!

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*:
     ;;;; -*- 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.

Thursday, August 25, 2011

Building SBCL with ABCL

In revisiting our compiler for various improvements, it is helpful to have challenging compilations to perform so that we have some confidence we don't break things along the way. One of the more complicated tasks we've found is using ABCL as a build host to compile SBCL which has seemingly has lots of twisty little macros, all different. A while ago, maybe perhaps a year ago, we broke this behavior, closing off this avenue of testing.

But due to recent work, as of ABCL trunk r13538 we've restored this capability, once again making ABCL capable of bootstrapping an SBCL build. This may prove handy for individuals who wish to port SBCL to new platforms where there is a JVM available.

When we mentioned this on #lisp, we were asked how long it takes ABCL to build SBCL vs. SBCL building itself.

ABCL building SBCL
//build started:  Thu Aug 25 15:12:30 CEST 2011

//build finished: Thu Aug 25 16:49:30 CEST 2011
real 96m59.819s
user 37m35.702s
sys 32m44.641s

SBCL building SBCL
//build started:  Thu Aug 25 16:51:34 CEST 2011

//build finished: Thu Aug 25 17:07:47 CEST 2011
real 16m12.855s
user 4m40.804s
sys 3m28.145s


So, ABCL is roughly a factor of six slower building SBCL than SBCL itself.