[asdf-devel] ASDF improvements from ECL

[Faré]

(Moving the discussion from the ecl list to the asdf list,
originally Re: ECL support for cl-launch and xcvb)

2009/11/9 Juan Jose Garcia-Ripoll <juanjose.garciaripoll at googlemail.com>:
>> For the record, the issue I finally found and fixed in building an
>> image was as follows: asdf:traverse is traversing system dependencies
>
> I have a problem with asdf:traverse. I mean, this function drives me
> mad. Its logic for listing what has to be done and most important
> _when_ is either broken or random. The last problem we had was that
> for certain systems traverse lists the LOAD-OP on the system far away
> from the LOAD-OPs on its individual components. ASDF:MAKE-BUILD was
> previously using the components to decide what to link, but for those
> systems arbitrary dependencies from other systems would be pushed in
> between breaking everything. Now ECL does the following: it invokes
> TRAVERSE with a hacked LOAD-OP method that reports NIL when queried
> whether that operation was than; then it takes the list and groups all
> subcomponents of the library that we want to turn into a big FASL,
> program, etc, and then it compiles and links everything. I did not
> change anything in TRAVERSE, but rather in how we use it.
>
>> I noticed that you're using what looks like an old version of
>> asdf.lisp. There have been numerous improvements in asdf recently, and
>> having been following them, I think that current revision 1.369 from
>> git is probably a good pick for an update, except that it doesn't work
>> in ECL as-is. It would be nice if you would merge your changes into
>> upstream.
>
> This is another thing I have been asking help from the ASDF
> maintainers. We cannot push our extensions upstream until they have
> been agreed upon, I mean we need a blessing for what we are doing with
> TRAVERSE and the like, and the assurance that the enging below is not
> going to arbitrary change breaking the operations we have. Again, I
> have written like five emails to the list without any answer. It is
> discouraging.
>
The problem is that you'll find no one to bless your changes, as ASDF
does not have a clearly defined dictator, the original author having left,
our main maintainer not having the resources to become one, and a vast
undefined community of users not being able to provide a clear permission
wrt making incompatible changes since it's not clear what in the
implementation or its documentation is binding for the future and what isn't.

I propose you offer a patch, and convince people with lots of systems to
try it. I'm volunteering to try your backwards-incompatible ASDF
improvements on all the systems used at ITA. Possibly, the DWIM.hu guys
will try it on all the systems they have, and so on. If no one complains
(and why should they?) then your patch will be a strong candidate for
inclusion. That automated test framework of yours is also a good thing
to show that your changes are not harmful.

>>> The other thing is that I have come to realize is that there is no
>>> systematic way of testing libraries. ASDF does not provide support for
>>> this. I have posted a call for help, or better for consensus the
>>> Common Lisp community, but so far the best I got was either being
>>> ignored or recriminated for being too emphatic about this.
>>>
>> Yeah, I saw your messages on the ASDF mailing-list.
>> I think it's not going to happen there.
>> I'd like to support something in XCVB, though, but I don't know what yet,
>> and have been fighting more urgent lacks of feature, first.
>
> You seem to be also confused w.r.t. what is really needed. ASDF does
> not have to support any single test library out there. What it needs
> is to ask developers to provide a valid TEST-OP, subclassing an
> operation it already provides. It is as simple as saying PERFORM on
> (YOUR-OWN-TEST-OP ANY-COMPONENT) should return two values: OK-VALUE
> and a SEQUENCE of failed tests inwhatever format you want.
>
Do you propose that people (or their libraries) should do things like that?
(eval `(defmethod asdf:perform
  ((op asdf:test-op) (c (eql ,(find-system :foo)))) ...))

> If ASDF specifies rigorously how test operations should behave then
> each test framework out there will be able to provide a uniform
> interface for testing in a couple of lines. I already showed how to do
> it for RT, for instance.
>
Sounds good.

> The only complain on the ASDF side was that currently PERFORM can not
> return values because it is not know the order in which operations are
> performed and because a single operation may trigger A LOT of other
> operations. That is why I developed a different implementation of
> ASDF:OPERATE which works incrementally creating a log of operations
> and output values. This log is extremely valuable because 1) by
> filtering test operations we can know which tests fails, 2) in general
> it allows a completely automated analysis of what ASDF did and what
> operations failed, instead of the current ugly interface based on the
> debugger. Both features are essential for automated building and
> testing.
>
Interestingly, antifuchs' POIU also has a logging facility,
to allow for replay of past builds (with non-deterministism
introduced by the termination order of the parallel compilation jobs).

> The patches have been submitted to the list but, as I said,
> no answer so far.
Yes, I saw the patch, but couldn't assume the authority to (in)validate it,
and probably no one else could.

Getting a patch widely tested could reassure us that "in practice, no
one relies on the behavior of the old TRAVERSE where it is
incompatibly redefined by the new one".

[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ]
One can be so anxious to put his "best foot forward" that he doesn't even
notice that it isn't his own foot. -- Harry Browne (HIFFIAUW)