[asdf-devel] Tests completed

[Faré]

On Sun, Jan 12, 2014 at 1:57 PM, Robert P. Goldman <rpgoldman at sift.info> wrote:
> 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 ASDF2 model was inconsistent, with contradictory assumptions about
OPERATION (1), and ASDF3 fixes as many or more systems than it breaks.
I don't think it's possible to detect that something wrong is going on,
without being a nuisance for the vast majority of system that work
(some of them after being fixed).

[(1) (a) OPERATION is the root of the operation class hierarchy
(b) in ASDF2, all operations are propagated downwards and sideway (big mistake)
Some systems define operations that really do not want not to be propagated
either downward or sideway, and work around that as they can (if they can);
ASDF3 fixes them.
Some systems define operations rely on operations being propagated
either downward or sideway, and ASDF3 breaks them unless the definition has
#+asdf3 downward-operation and/or #+asdf3 sideway-operation.]

I considered having a completely separate incompatible hierarchy, but
that would instead have broken *everything*, instead of breaking a fraction
and fixing a larger fraction of code. That wouldn't have been
much of an ASDF3, and I might as well have stuck to XCVB.

> The problem is that the current change in implementation breaks unknown
> code in ways that quietly cause it to fail to do what the programmer
> expects without any visible notification of the change.
>
Any change in implementation will do that: if people start relying on bugs,
instead of reporting them and getting them fixed, then of course their code
will break when the bugs are fixed

With ASDF, no one really understood the bug (or the structure of ASDF
in general),
and back in the days of ASDF1, there was no incentive in figuring
things out anyway,
since there was no good process for getting things fixed.
Many people were using kludges


> Programmers who do not follow ASDF-DEVEL carefully will be completely
> blindsided by this change.
>
> Indeed, *I* was blindsided by this change, and I do read ASDF-DEVEL.
>
That's my fault. I should have shouted about it in ALL CAPS,
MANY TIMES OVER. Instead, I wrongly assumed that
chasing the offenders in Quicklisp and getting them fixed would be enough.

> I need to look into a means to identify these problematic cases.  Ugh.
> MOP not standardized.  Ugh ugh ugh ugh.  I'll see if I can pilfer code
> from Closer-MOP to render ENSURE-CLASS accessible.
>
> Is this the moral of this story: code that wishes to be backwards
> compatible and portable can NEVER change the class hierarchy above an
> API-visible class, because there is no *portable* way to detect when
> someone's code will be affected.
>
What if the previous hierarchy was plain buggy?

Every bug fix *is* an incompatibility, and yes, sometimes it is necessary
to fix changes in the class hierarchy, and getting clients fixed can be a pain.
Hopefully, this part of the hierarchy is stable now.
There are other potential incompatible changes that I annotated ASDF4
in the source code, that I didn't undertake, because they would have been
a lot of work to fix all clients, without sufficient functional gain.
A more motivated maintainer than I would have provided a transition plan,
so gotten all clients could be fixed in a backward compatible way,
before the old code is changed incompatibly.

That's another reason for fixing bugs early rather than late, and
fixing as many as possible at once when you introduce incompatibility,
because the price is proportional to the number of times that things break,
not to how much breaks each time. Maybe I should have been more, not less,
aggressive in introducing incompatibilities.


>>> 2.  Add warnings for people using ABCL or ECL + bundle-op on Mac OS.
>>>
>> The ABCL and ECL bugs... well, I'm not sure these configurations ever
>> worked, so it's no regression. But yes, it should be easy to detect
>> such a situation and issue a warning of a cerror might help the user
>> diagnose why his code is failing, e.g. in the failing perform method,
>> before the failure.
>
> I believe so, and while waiting for a fix, we can allow programmers to
> live dangerously by pushing something like :asdf-try-broken-bundle-op
> onto *FEATURES*.
>
I recommend against a feature, which requires recompilation,
and is thus useless when using an implementation-provided ASDF,
as well as introduces hard-to-control environmental dependencies.
Instead, I much recommend using CERROR, which can be controled
programmatically at runtime with RESTART-CASE.

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
There are just two rules of governance in a free society:
Mind your own business. Keep your hands to yourself. — P. J. O'Rourke