[asdf-devel] Tests completed

Robert P. Goldman rpgoldman at sift.info
Mon Jan 13 03:50:20 UTC 2014


Faré wrote:
>>>> 1.  Add warnings as appropriate wrt changes in OPERATION hierarchy for
>>>> >>> code that extends OPERATION classes.
>>>> >>>
>>> >> Not sure what you mean by "add warnings": issue an official
>>> >> declaration warning people that code may break? Using the MOP to
>>> >> detect code that uses defclass with operation as a superclass and
>>> >> issue warnings? I mean, all known existing code has been fixed by now,
>>> >> or never tested.
>> >
>> > Find cases where people define new OPERATION subclasses and issue a
>> > warning about the changes.
>> >
> How do you detect whether the code is made to work for ASDF2 or for ASDF3?

The best we can do is issue a warning whenever code defines a subclass
of OPERATION, and allow the user to indicate that s/he understands and
wishes to proceed.

This is a very nasty case, since the user's agreement is of necessity
file-scoped.

The best thing I can think of is to have a wrapper around ASDF system
loading that will establish a binding for a variable that the user can
rebind local to a particular file.

That will allow the user to modify individual ASDF system definitions to
indicate that this is ok.

That's not a very good solution, actually, since the OPERATION subclass
might be defined outside an ASD file, in a normal .lisp file.  So
perhaps wrapping COMPILE-OP and LOAD-OP is also necessary.

I'd like to get this right before going forward, but I see only a choice
of unpleasant alternatives.

If anyone has a better one, I'm open to suggestions.

Unfortunately, to take your point about ASDF needing to let the person
who knows provide the knowledge, the only person who knows whether an
OPERATION redefinition is good is the system definer, and NOT the poor
programmer who loads a library.

So I'm inclined to do what's generally bad practice and explicitly
provide an out for all of the quicklisp systems that you have checked.
Only, oh dear, most people are not providing :VERSION attributes, which
means that we cannot distinguish patched from unpatched libraries....

Do you know: can we rely on :VERSION information to identify Quicklisp
libraries that you have patched?  If not, could we make that happen?

Best,
r




More information about the asdf-devel mailing list