ABCL 1.1.0

Happy holidays!  Thanks to everyone…


-- ABCL Mgmt.

ABCL-1.1.1 will follow in thirty (30) days.

ABCL-1.1.0 images are being pushed to your local system providers.

Upstream providers updated:  MacPorts

[release]: http://svn.common-lisp.net/armedbear/public_html/releases/1.1.0/

The Winter of the Bear (2012 Holiday Edition)

ABCL 1.1.0 Release Candidate RC-2 available.

Hopefully people tune December 2012 Quicklisp to these images and their descendents.

All reported bugs with (A)MOP have been addressed.

As always, the source is open so you can get out and push if things break down…

The User Manual now contains appendices describing the SYSTEM and JSS packages.

c.f. http://article.gmane.org/gmane.lisp.armedbear.devel/2634

ABCL svn, now with more CLOS

Stas Boukarev recently reported and diagnosed quite an insidious bug with premature class finalization.  The symptoms could involve method-not-found errors, missing slots in class instances, and strange crashes in the Java parts of ABCL featuring page-long backtraces spewed to stderr (the latter because of debugging output in "can't happen" parts of the code, so someone was trying to diagnose this bug already.)

If you had been evaluating abcl against your existing system and given up because of inexplicable errors, it could be a good time to give the development version a spin again now that the bug is fixed in svn.

ABCL's MOP passes the test suite

Just some minutes ago, a commit went into ABCL's source repository which cleaned up a bit of confusion over the role of fast method functions in calculating the discriminating function of a generic function.  And as of now, Pascal Costanza's MOP test suite reports this:

CL-USER> (mop-feature-tests:describe-mop-features)

This MOP supports all known standard features.

This MOP lacks no known standard features.

This MOP supports the extra features (:ACCESSOR-METHOD-INITIALIZED-WITH-FAST-FUNCTION :ACCESSOR-METHOD-INITIALIZED-WITH-GENERIC-FUNCTION :ACCESSOR-METHOD-INITIALIZED-WITH-QUALIFIERS :ALLOCATION-CLASS-PASSED-TO-EFFECTIVE-SLOT-DEFINITION-CLASS :DIRECT-SLOT-DEFINITION-INITIALIZED-WITH-ALLOCATION-CLASS :EFFECTIVE-SLOT-DEFINITION-INITIALIZED-WITH-ALLOCATION-CLASS :METHOD-INITIALIZED-WITH-FAST-FUNCTION)

This MOP metaclass structure has no known leaks.
; No value
CL-USER>

The test suite page warns about interpreting such a result as "supports the meta-object protocol of Common Lisp, guaranteed bug-free!", and I heartily agree with that assessment.  I would classify ABCL's MOP support as early beta, with lots of exciting bugs to be uncovered as people start using it.  

That said, I will submit patches to closer-mop to support ABCL as soon as MOP support is in a released version of ABCL, and the large number of MOP-using systems available from quicklisp should then uncover any obvious bugs quite soon.

Loading the contents of a(n) URI

I'd place a bet as large as I would on the Grexit that we're in the "how lightweight is REST, really?" phase of experimentation with decentralized linking syntaxes.  Naturally, the Bear wants a piece of the action.

From sticking to the ABCL core principals ("the User is always right") comes from the work in using the ability for the JVM to dynamically install protocol handlers for URIs in the URL-PATHNAME implementation.  Which means to the Tl;DR; crowd that any valid PATHNAME for the Bear, including those resolvable via "http", "ftp", "https", etc., is the valid subject of the Common Lisp input routines, such as CL:READ, CL:READ-LINE, et. al.

Long ago, in an open sourced galaxy far away, we hacked these routines into the semantics of the CL:PATHNAME (paper forthcoming).  As such, in the "moving Common Lisp into the 21st century" department:  we have recently added the ability to get the underlying java.io.InputStream in the stable ABCL trunk.

Since a CL:PATHNAME may now be a valid URI, we use the ABCL-ASDF extension to locate the Jena binary artifacts to allow us to deserialize an N3 graph into a running ABCL instance.  An example of a trivial wrapping of of Jena in Common Lisp can be found in Jeannie. 

JFLI added to abcl-1.1.0

One basic tenet of current Armed Bear development is ANSI Common Lisp conformance first and foremost.  Sticking to a set of core principles often has unexpected benefits.  One such benefit by being as ANSI conformant as possible allows us to tool our implementation around the actual execution of the hoary descendents of programs such as Macsyma on the JVM as well as the contemporary multithreaded abstractions of Bordeaux-Threads.  

Despite the various lacunae, by and large the standard Common Lisp symbol dictionary defines a well thought out API.  Or at least it was a well argued API, being the attempted fusion of all existing Lisp dialects in the United States in commercial use by the government.  By using these well-defined semantics, Armed Bear development gains a solid platform for experimentation with better ways of "dealing with Java syntax".  The first experiment we incorporated was of course, Alan Ruttenberg's "Java Simple Syntax" (JSS).

JSS was always envisioned as the first of many such experimentations, and since adding extensions in the abcl-contrib section is now as easy as copying a ASDF tree,  and repackaging 'abcl-contrib.jar', we have experimentally snagged the most recent copy of Rich Hickey's pre-Clojure framework called JFLI.  The version of JFLI in abcl-1.1.0-dev is a pure Common Lisp version that does away with the need with either JNI or ASM runtime linkage.  We could, of course, directly use the JFLI code that links via JNI: perhaps should as a backup strategy.  The code in 'abcl/contrib/jfli' is a bit choppy right now, as tests indicate that we still need to patch a few things most recently in dealing with references to a single byte.

If you use JFLI with ABCL-CONTRIB drop us a line:  we aim to try to support all existing usages. 

But this should not be the last such experiment: the dot notation developed for jscheme is quite interesting, and of course we could return the favor to Rich by implementing a Clojure contrib so he could return to doing Lisp the right way…

Closing in on the MOP ...

I just sent the following patch to Pascal Costanza, the author of the excellent mop-feature-tests test suite:

--- old-mop-features/mop-feature-tests.lisp
+++ new-mop-features/mop-feature-tests.lisp
@@ -1,6 +1,7 @@
 (in-package :mop-feature-tests)
 
 (defparameter *mop-package-name*
+  #+abcl "MOP"
   #+allegro "MOP" ;; "CLOS" "ACLMOP"
   #+clisp "CLOS"
   #+cmu "CLOS-MOP" ;; "MOP"
@@ -730,6 +731,7 @@
         (format out "(defparameter *mop-known-extra-features*~%")
         (format out "  '~S)~%~%" *mop-known-extra-features*))
       (format out
+              #+abcl "#+abcl~%"
               #+allegro "#+allegro~%"
               #+clisp "#+clisp~%"
               #+cmu "#+cmu~%"

The version of ABCL in subversion now runs this test suite to completion, sporting 53 missing standard features but on the other hand also 13 extra features, as reported by (mop-feature-tests:describe-mop-features).  Next up: finding out what these numbers mean, implementing the missing features, and getting ABCL support into Pascal's closer-mop compatibility library, which is used by virtually all MOP-using Lisp code these days.

Right now, I would rate ABCL's MOP support as alpha-quality, as in "it compiled, check it in!".  But after some rounds of bug-fixing, we should have solid support for another big group of Common Lisp libraries and systems.  Onward!

JSS 3

Armed Bear Common Lisp 1.0 shipped with a mechanism that packages pure Common Lisp extensions in an JVM artifact ("abcl-contrib-1.0.1.jar") which can be loaded by the CL:REQUIRE mechanism operating on the symbol named ABCL-CONTRIB.


Among the abcl-contrib packages shipped is an updated version of Alan Ruttenberg's Java Simple Syntax ("JSS") which can be loaded after the"abcl-contrib.jar" artifact has been CL:REQURIRE'd via the JSS symbol.


JSS 1 pioneered a SHARPSIGN-DOUBLE-QUOTE macro which dynamically introspected JVM method lookup via a very Lisp-y mechanism.  

    CL-USER> (#"getProperties" 'lang.System)
    #<java.util.Properties {java.runtime.name=Java(TM) SE R.... {1297ABD9}>

JSS 1 extended ASDF 1's ability to specify pathnames relative to a definition file to name JVM artifacts for dynamic loading in the JVM which ABCL finds itself hosted upon.  


For all its merits, JSS 1 needed two additional jars on the ABCL classpath, one for the jscheme implementation of Per Bothner et. al. ("jscheme.jar") to handle argument arity and one for the BeanShell interpreter to modify the JVM classpath dynamically ("bsh-2.04b.jar").  Figuring out how to modify the classpath of the JVM process was never an entirely simple task.


JSS 3 no longer has the dependencies on these artifacts, having rewritten the necessary primitives in Common Lisp.  As part of this re-engineering, we have packaged all the JSS functionality in its own package.  If you wish to ensure compatibility with existing JSS 1 code then invoke JSS:ENSURE-COMPATIBILITY to import the expected JSS symbols into CL-USER.

Closing in on CLOSER-MOP in abcl-1.1.0-dev

In response to inquiries recently on #abcl (from @loke among others), we'd like to point out that recent work on the Armed Bear trunk--what will be abcl-1.1--by Rudi has started to converge on a plausible AMOP strategy.  Stay tuned.

ABCL 1.0.1 Released

All users of abcl-1.0.0 are recommended to migrate to abcl-1.0.1 as it fixes the abcl-contrib mechanism, an unfortunate oversight in our giddiness at being able to release at ECLM 2011.

Now the following incantation

(require 'abcl-contrib)

(require 'jss)

should result in a working JSS.

In addition to restoring the loading of ASDF definitions from jar archives, we've randomized some of our String hashes to prevent a purported JVM exploit spotted recently and shipped with ASDF-2.019.

You can find more in the release notes at:

http://common-lisp.net/project/armedbear/release-notes-1.0.1.shtml

and the list of changes at:

http://trac.common-lisp.net/armedbear/browser/tags/1.0.1/abcl/CHANGES

Source and binary distribution archives with associated cryptographic
signatures can be downloaded in ZIP or gzipped tar from:

http://common-lisp.net/project/armedbear/releases/1.0.1

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