On 30 May 2010 17:17, Christophe Rhodes <csr21@...> wrote:
> Faré <fahree@...> writes:
>> Would ASDF2 count as a contrib enhancement? Is it OK to commit it
>> before 1.0.39? Right after 1.0.39?
> (Not before 1.0.39, but that's obvious now :-) In what ways is asdf2
> backwards-incompatible with asdf as currently shipped? Are there still
> hooks or similar for sbcl to be able to build and ship loadable contribs
> without the user being able to shoot themselves in the foot too easily?
> (For example, one usual problem is/was an asdf-binary-locations
> configuration which wanted to change the output locations of sbcl
> contrib fasls).
Yes, it is too late for 1.0.39 indeed. I intend to rename 1.728 to
2.000 tomorrow and hope it can make it to 1.0.39.small_integer.
ASDF 2 *should* be fully backwards compatible with ASDF 1 in all the
features actually used by .asd files in the wild, and so far there
haven't been any known incompatibility that we haven't addressed. But
I admit I haven't tried *all* said files, just a lot of them. Others
have tried a whole lot of them, automatically, and haven't submitted a
bug report in a month - but I admit I didn't dig much into that. ABCL,
CCL, CMUCL and ECL have included recentish versions of ASDF in the
master branches of their source trees, without unaddressed complaint
The SBCL REQUIRE hook is present, and now also works on ECL, CCL, ABCL.
Where ASDF 2 is incompatible is that:
* it defines behavior in cases that used to be non-portable (notably
allowing strings as portable hierarchical pathnames, and handling
pathname merging in a portable way, too).
* it ships with asdsf output translations included and enabled by
defaults (the successor to asdf binary locations) -- however, it
arranges to leave things under SBCL_HOME invariant no matter what.
Some hack may or may not be necessary while compiling the contribs
themselves: (exporting SBCL_HOME=... or
* by default, the *central-registry* (still supported) is empty,
predefined search paths being supplied as part of the default and
wrapping values for the source-registry. This shouldn't affect anyone.
There is, however, one current slight performance regression on SBCL
in certain cases: the default value of the source-registry in ASDF 2
includes recursing through /usr/share/common-lisp/source which if you
have a lot of files there and are using SBCL can take a few
noticeable seconds when ASDF first scans these directories. I think
it's a SBCL performance bug wrt DIRECTORY doing too much
pathname/truename normalization and namestringation, especially since
other Lisp implementations seem to be much less slow by an order of
magnitude at least. But I still think it's OK, since:
* things are fast if the directories are empty.
* you can override the default source-registry and remove those
directories if you want to skip this scanning.
* a few seconds at startup is not THAT annoying, especially when
compilation takes minutes.
* I'd rather the performance bug be fixed in SBCL than in ASDF.
Note: SBCL is my main testing platform for ASDF. I also run
regressions on CCL, CLISP, ECL, Allegro, before every release.
[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ]
The worst thing about totalitarian regimes is not that they make people poor,
miserable and unfree — it's that they corrupt people's souls, and turning
everyone into a double-thinking, double-speaking liar for the sake of survival.