Just Launched: You can now import projects and releases from Google Code onto SourceForge
We are excited to release new functionality to enable a 1-click import from Google Code onto the Allura platform on SourceForge. You can import tickets, wikis, source, releases, and more with a few simple steps. Read More
From: Peter Graves <peter@ar...> - 2005-08-30 19:20:19
ABCL 0.0.8 is now available:
The main user-visible change in this release is that by default, the
=2Ecls files generated by the compiler are now zipped up into their
parent .abcl file.
$ unzip -v tailp.abcl
Length Method Size Ratio Date Time CRC-32 Name
-------- ------ ------- ----- ---- ---- ------ ----
254 Defl:N 202 21% 08-30-05 11:15 f59bc191 tailp._
1174 Defl:N 559 52% 08-30-05 11:15 b59ff9af tailp-1.cls=
-------- ------- --- -------
1428 761 47% 2 files
You might want to think of tailp.abcl, in the new system, as tailp.jar;
the file tailp._, within the archive, would have been tailp.abcl in the
When you use build-abcl.lisp to build abcl.jar, the per-.abcl
compression is not done, in order to end up with only a single level of
compression in abcl.jar; if you look in src/org/armedbear/lisp, you'll
see the .cls files and unzipped .abcl files that were zipped up into
When you compile the Lisp source files of your application, on the
other hand, you'll end up with just one .abcl file for each Lisp source
file, and no .cls files at all.
This is fairly confusing, but as far as I know it doesn't confuse abcl,
which can deal with both compressed and uncompressed .abcl files, as
well as abcl.jar.
(There is currently no support for jar files that contain compressed
=2Eabcl files; abcl itself will not produce such a file.)
If you want the old behavior back (out of nostalgia, or because you
want to examine the .cls files without having to unzip them), you can
set SYS:*COMPILE-FILE-ZIP* to NIL.
Otherwise, work since 0.0.7 has been mainly directed towards
Overall, 0.0.8 is about twice as fast as 0.0.7 on the salza/gzip
benchmark, but only about 5% faster at building sbcl.
Inline functions are now supported. Juho Snellman has reported a bug
in that area which I haven't been able to figure out yet, but simple
inline functions in non-recursive contexts appear to work fine.
There were some particularly embarrassing floating point bugs in 0.0.7,
many of which have been fixed in 0.0.8. When run with Java 1.5, 0.0.8
has no failures on the IEEEFP-TESTS suite.
On a good day, 0.0.8 fails 93 out of 21320 tests in the GCL ANSI test
suite, compared to 90 out of 21206 tests for 0.0.7.
0.0.8 has been verified to work correctly with salza-0.7.2, cl-ppcre
1.2.11, and ironclad 0.7.2.
Thanks to Bryan O'Connor for providing a patch to add OpenMCL support
to build-abcl.lisp, and to Kevin Reid, David Steuber and Juho Snellman
for testing their applications with ABCL.
Please report problems to the j development mailing list:
Thanks for your support.