In recent blog posts, Hans Hübner mentions how ABCL starts to be usable by the average Common Lisp programmer. Yet he also ran into the longer standing issue that the XPATH library doesn't want to be compiled by ABCL 1.1.1. (This is where his remark how the CXML-STP library doesn't work comes from.)
Last weekend I finally found out what the underlying problem was that XPATH triggered: shared structure in forms being compiled. Even though it's quite easy to generate code with shared structure, apparently few projects use it in a way which triggered ABCL into incorrect behaviour.
Case in point was a compiler macro expansion containing a literal list. After expansion, the literal became part of the code being compiled and the compiler modified the literal in place, resulting in problems on all subsequent expansions.
The cause of the issue dates all the way back to even before I started working on ABCL. Back then the compiler used to modify the CARs and CDRs of the forms it was compiling. Much of this behaviour was already replaced before last week as my intuition told me this is undesirable, with the replacement being nice side-effect-free functional code. Even though the reason for this behaviour isn't documented, I'll assume it was to reduce consing and thereby reduce pressure on the JVM's garbage collector. In today's world with new garbage collectors and much improved JIT compilers in the JVM, this issue isn't an issue anymore.
To cut a long story short: XPATH compilation fixed, compiler changed to functional style and libraries depending on XPATH (like CXML-STP) also fixed.
On to the next cl-test-grid failure...
Sunday, March 31, 2013
Friday, March 22, 2013
M$FT Excel format from Common Lisp.
In light of Hans Hübner's recent spike into the "no more Java the language" railhead. I'll certainly share recipes for using the monkeys' libraries to manipulate various historical Microsoft Excel formats. The dirty secret of computing on the modern enterprise trapped in the black iron prison of non-free document formats is that current versions of Office don't always handle previous versions very well. Since Apache POI has been around for the better part of a decade, it provides a fairly reasonably DWIM fallbacks for reading such formats. Somehow, once whatever you are working with is touchable with ANSI Common Lisp, all seems to be so much better…
Two examples that come to mind in swigging the Apache POI libraries over to a syntax that the Bear can paw through:
Two examples that come to mind in swigging the Apache POI libraries over to a syntax that the Bear can paw through:
- Alan Ruttenberg used JSS to work with Apache POI as read-ms-docs which was released as part of the lsw Semantic Web toolkit wrapping RDF(S) and OWL inference implementations in Java
- Mark Evenson extended Alan's work as part of reading to/from SQL to be able to roundtrip the data within Excel spreadsheets to Oracle databases. The database reflected the pure data of the Excel document, using the assorted Microsoft "macros" to sanitize input.
Thursday, February 14, 2013
ABCL 1.1.1
We are pleased to announce abcl-1.1.1, a maintenance release which addressed the following issues: * (A)MOP All reported errors with the MOP implementation have been addressed. * SETF autoloader An autoloader for SETF expansion functions has been implemented, eliminating the errors associated with not being able to use (SETF SYMBOL) without first invoking SYMBOL as a function. * ANSI Tests All outstanding regressions in the ANSI test suite with respect to abcl-1.0.1 have been fixed. * ABCL-ASDF The ability to resolve Maven components in ASDF system definitions has been restored.
downloads: http://common-lisp.net/project/armedbear/releases/1.1.1/ source: http://svn.common-lisp.net/armedbear/tags/1.1.1/abcl/ manual: http://abcl-dynamic-install.googlecode.com/files/abcl-20130214a.pdf
Friday, December 7, 2012
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/
-- 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/
Sunday, December 2, 2012
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
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
Wednesday, August 15, 2012
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.
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.
Sunday, July 8, 2012
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.
Subscribe to:
Posts (Atom)