[asdf-devel] ASDF test-op question

[Juan Jose Garcia-Ripoll]

Hi Robert,

I hope you do not mind I CC this email to the list, because I think
you made pretty good points and I think I also have some valid answers
to them.

2009/10/19 Robert Goldman <rpgoldman at sift.info>:
> Yes, that's right.  You /do/ need to run through all of ASDF's code.  I
> have been going through that code.  I am trying to tell the list what I
> found there.

And I thank you for that. I probably never got as far as understanding
TRAVERSE and the way it works and this is one of the reasons why I
feel my design of the ASDF-ECL extensions might be very fragile.

> ASDF invokes TRAVERSE to make a /plan/ for performing an operation.  A
> plan is an ordered list of operation . component pairs.  After traverse
> returns this plan, OPERATE loops over the ordered list, calling PERFORM
> on each pair.

Understood. However note one thing: these are ASDF internals. They are
not "exposed" to the users and not fixed by the manual. ASDF might
work equally well if one changes the way OPERATE uses the output of
TRAVERSE, or if we fix an order for TRAVERSE, or if we dispense the
plan-and-then-execute setup.

> This means that the return values of PERFORM are /discarded/.

Not necesseraly.

> It also means that it's not obvious to find which are the component
> operations that are done for some operation X.  That is, if you do (OP1
> . A) (OP2 . B) and (OP3 . C) in order to do (OP . X) all you know is
> that the first three will appear /somewhere/ before (OP . X) in the plan
> --- you have no stronger guarantee about where they are.  In particular,
> there is no top-level function call to do OP X that will be on the stack
> when the three subsidiary operations are done.

Understood as well. However, this also does not prevent ASDF from
exposing a history of what it has done so far and let later operations
use that.

I attach a simple extension to ASDF's OPERATE that creates a log. The
log is a list of objects, each one containing the operation that was
performed, whether it failed, and the output of PERFORM. With that log
it is easy to build a TEST function that parses only the log entries
related to tests.

* (multiple-value-setq (op log) (asdf:operate 'asdf:load-op 'cl-unicode))

[...]
;;; Computing Hangul syllable names
#<ASDF:LOAD-OP NIL {12229E41}>
* (mapc #'asdf::print-log-entry log)
;;; Log entry:
;;; #<LOAD-OP NIL {12229E41}> on #<SYSTEM "cl-unicode" {11A88DF9}>
;;; No return values
[...]
* (describe (first log))
#<ASDF:LOG-ENTRY {12E80A69}>
is an instance of class #<STANDARD-CLASS ASDF:LOG-ENTRY>.
The following slots have :INSTANCE allocation:
 COMPONENT        #<ASDF:SYSTEM "cl-unicode" {11A88DF9}>
 OPERATION        #<ASDF:LOAD-OP NIL {12229E41}>
 FAILED-P         NIL
 RETURN-VALUES    NIL

Could we agree that this is a valid starting point? It is really
compatible with previous uses of ASDF and it only asks one thing:
PERFORM, applied on TEST-OP should return two values, success-p and a
list of objects containing the tests, so that we can analyze the log.

Juanjo

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