[Ecls-list] ECL support for cl-launch and xcvb

[Juan Jose Garcia-Ripoll]

On Mon, Nov 9, 2009 at 4:04 PM, Faré <fahree at gmail.com> wrote:
>> Is there a systematic way for me to reproduce the problem? Some test
>> in cl-launch perhaps?
>>
> Yes, in a fresh directory (where plenty of files will be created), try
>   cl-launch -l ecl -B tests
> It should successfully test 234 combinations of invocation flags for
> cl-launch with ecl (numbered from 0 to 233).

Thanks, I take note of this and of your instructions below. I hope I
can install it next week, when I come back from a work trip.

> 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 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.

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.

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.

The patches have been submitted to the list but, as I said, no answer so far.

Juanjo

-- 
Instituto de Física Fundamental, CSIC
c/ Serrano, 113b, Madrid 28006 (Spain)
http://juanjose.garciaripoll.googlepages.com