[asdf-devel] Quick note on tests
fahree at gmail.com
Thu Sep 13 15:59:00 UTC 2012
>> failing test(s): test-configuration.script test-multiple.script
>> test-static-and-serial.script test-utilities.script
> OK, seems like exiling functions to ASDF-UTILS and no longer exporting
> from ASDF is causing this failure.
Oops. I've fixed the tests to work
despite utilities not being exported anymore.
> Question: what's the removal of these exports doing, aside from
> assuaging a feeling of tidiness? I get it that one might not like
> people using ASDF as a source of utilities, but is that not-liking
> strong enough to break existing code (or in this case, re-breaking
I don't have a strong opinion on that.
Apparently, Xach has one, and I care about his opinion a lot
to improve the adoption of ASDF and other Lisp utility packages.
> [Faré, your ILC 2012 stuff looks like a lot more exciting place
> to spend hours than tidying ASDF!]
I think so, too, and I've made significant progress in the last few days:
working transformation from interface-passing style to traditional OO style,
and now the beginning of actual description of the software in the article,
rather than just a plan.
Hopefully, the final paper will be ready by the deadline of the 25th.
> I also get it that Xach doesn't like use of ASDF as a utility source for
> Quicklisp, because it introduces a dependency on bleeding edge versions
> of ASDF. But that doesn't seem to me to be a problem with use of ASDF
> for utilities per se --- the problem instead is that ASDF doesn't have a
> stable API[*]. Maybe instead of refusing to export these utilities, we
> should do a feature freeze, and defer future API changes (any changes to
> exported symbols) to ASDF 3, which may or may not arrive before the
> coming of the programmer's choice of Messiah.
> Freezing the API would also have the effect of encouraging the
> development of alternative sources of utility functions. As people want
> more functionality, they will be driven to develop it in a freestanding
> library, and that will naturally motivate them to move away from using
> ASDF as a utility source in favor of a new library that does not have
> ASDF's special status. [As I read it, one of Xach's objections to the
> use of ASDF as a utility source is that it has a special status. This
> seems an eminently reasonable ground for objection.]
> * There is a separate problem that people might like to see ASDF wither
> away, but I'd be happier to postpone preparations for said withering
> until it is sooner to come. The better is the enemy of the good, and
> all that.
Frankly, I agree that Xach indeed is both a bit early in wanting to
move away from ASDF without a clear universal replacement in sight
(and I regret to admit that XCVB isn't ready yet
as such a *universal* replacement).
I also believe that Xach is being overly conservative in
his reluctance to upgrade to the "bleeding edge" of asdf *releases*
while having software depend on the often unreleased bleeding edge
of about everything else (including asdf-utils).
But I'll do whatever makes Xach happy, because he's the one who's
having the best CL software distribution so far
(the only one with actual end-users, it seems).
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
Every task involves constraint,
Solve the thing without complaint;
There are magic links and chains
Forged to loose our rigid brains.
Structures, strictures, though they bind,
Strangely liberate the mind.
More information about the asdf-devel