[asdf-devel] Tests completed

Robert P. Goldman rpgoldman at sift.info
Tue Jan 14 00:32:06 UTC 2014

Faré wrote:
>> > But I can speak to the fact that code that quietly goes away and does
>> > something unexpected or, worse, quietly does not do something expected,
>> > is very difficult to debug.
>> >
> Indeed, the problem here is not that the breakage was invisible;
> the problem is that, upon seeing the breakage, the author (you in this case)
> had trouble tracing down the breakage to its root cause.

Let me clarify, the breakage WAS close to invisible.

The code that came through the allegedly successful compilation simply
didn't function.

There was no error message that I could track back, because some code
that should have been translated -- not COMPILED, but TRANSLATED, so
that when the code wasn't translated, ASDF simply went away and reloaded
the obsolete versions of the code.

There was NO ASDF breakage.

The only way to figure out what went wrong, well downstream, was to know
that one had to look at the output of TRAVERSE to see that an operation
we expected wasn't happening.

The breakage was WAY downstream, when odd things happened as a result of
loading old versions of code.

So that's as close as you get to "invisible" without walking into the
territory of "not a bug at all"!

> You're right that maybe we could have at the end of each file a check
> for new subclasses of OPERATION, and a warning if an unknown one was >
> It is probably more portable to use the MOP to walk all defined
> subclasses
> than to intercept their definition as it happens.

That might be nice, but when would we run this check?  After loading
each new system?  That seems a lot harder than running a check when a
new OPERATION subclass is instantiated (as Pascal's suggestion).

[I am quite concerned about this because I am 95% sure that we have
other systems like this out there that are just waiting to bite me.  We
have lots of systems that interact with outside software in ways that
require ASDF to initiate, e.g., some make operations, something to build
some Java code, starting up a server, etc.]


More information about the asdf-devel mailing list