I'm not know for my format-fu, and for a good reason.
I'm however wondering about the following:
(format t "~@<~A.~:@>" "a aa aaa aaaa aaaaa aaaaaa aaaaaa aaaa aaaa aaaa aaaa aa aaa aaaa aaaa aaaaaa aaaa aaaaaa")
I'd expect that to do my wrapping for me, but it doesn't. Are my
expectations misguided?
Cheers,
-- Nikodemus "Not as clumsy or random as a C++ or Java.
An elegant weapon for a more civilized time."

Christophe Rhodes wrote:
> So do I. I've merged a fix for this into sbcl-0.8.12.11.
Wow, thanks for the rapid fix.
... Gates told journalists that Microsoft's patching process
compares well with competitor, "You know, the time - the average
time - to fix on an operating system other than Windows is
typically ninety to a hundred days," said Gates. "Today we have
that down to less than forty-eight hours."[1]
This rapid SBCL fix shows yet another reason that Gates continues to
avoids direct comparison of his compiler to SBCL in his public
statements.
Kevin
[1] http://www.theregister.co.uk/2004/06/28/gates_get_patching/

Package locks have now been merged to the CVS HEAD.
Summary of open issues:
* Should package locks be enabled by default? Currently they
aren't, but #lisp consenus seems to be that they should.
Pros:
Will get more testing and feedback on the interface.
Attractive NEWS message:
12:37 <Xophe> "minor incompatible change: code not obeying clhs
11.1.2.1.2 is now broken in a more definitive way"
Joe User is less likely to twiddle with *features* (I guess),
but would definitely benefit from the safety net provided by
package locks.
Cons:
Interface changes will hurt users more -- though only if they are
either actively using package locks for their own code or are doing
something nasty to COMMON-LISP or SB-* packages (like McCLIM). ...and
there are both "not quite happy with this" and "will change somewhat"
issues with the interface (summarized later).
* Known interface issues
The :implement option to DEFPACKAGE, as discussed earlier is not
optimal as far as names go. Furthermore, I'd like it to be also
usable with symbol-granularity, eg. (:implement-symbols foo:bar
bar:quux). And if the :implement option is renamed, so should
all the implementation-package operators (and the whole concept,
probably).
There should probably be a (unlock-package foo bar) declaration
in addition to the DISABLE/ENABLE-PACKAGE-LOCKS, or the latter
should maybe accept strings as well and for them disable package
locks for the named packages. There should possibly also be
a declaration to disable all package locks for the lexical scope.
Compile-time package lock violations should probably result
in code that signals a program-error instead of interrupting
the compilation with an option to continue. The only question
about this is whether or not users should be able to do something
like:
(handler-bind ((sb-ext:package-lock-violation #'maybe-continue))
(compile-file "foo.lisp"))
* Outstanding FIXMEs:
SBCL doesn't currently compile cleanly under SBCL-style package
locks. There are a few DEFVARs of symbols in the COMMON-LISP package
that are done under the host lisp, and some COMMON-LISP symbols
rebound as local macros as well. To remedy this SBCL when building
under an SBCL with package locks currently unlocks all packages,
which is unsightly to say the least.
The inital package-lock sanitation of at least SB-GROVEL and
SB-SIMPLE-STREAMS is not all that elegant, and should be fixed.
Cheers,
-- Nikodemus "Not as clumsy or random as a C++ or Java.
An elegant weapon for a more civilized time."

I recently dusted off the venerable "Great Computer
Language Shootout." Since CMUCL was already part of
the set of tests, I did a bit of minor edits to get
things running under SBCL.
Unfortunately, being a relative SBCL novice I'm sure
that I have overlooked many compiler flags (since I
had to remove several of the CMUCL-specific items) and
may be giving SBCL lower marks than it deserves.
I was hoping some SBCL guru could take a look at the
existing sources and suggest improvements (see
http://shootout.alioth.debian.org/lang/sbcl/). The
red X's show where my ineptitude has overcome SBCL's
generally good compatibility with CMUCL.
Specific questions I have include:
* Whether the SBCL "compile-file" form has an analog
to CMUCL's ":block-compile" flag (and even if it's of
any use)
* If there is an easy CMUCL Sockets -> SBCL sockets
migration guide.
* Why the 'unsigned-byte type seems to be such a
problem when used with the array class (see
http://shootout.alioth.debian.org/lang/sbcl/wordfreq.sbcl.html
-- this doesn't even compile under CMUCL's current
release, so I'm not sure how this came into being).
I'd appreciate any comments you might have.
Thanks,
-Brent