Define a Simple Echo-Op

[zacque]

Hi phoebe,

> [[PGP Signed Part:Undecided]]
>  I'll still get the warnings (even with one new warning: "No dependency
>  propagating scheme specified..."):
>
> Perhaps it was imprecise of me to say that defining a method on COMPONENT-DEPENDS-ON will prevent the deprecation warning.
> Causing the default method to be invoked on an OPERATION that is not a direction-OPERATION is deprecated; defining a more
> specific method which does CALL-NEXT-METHOD still invokes the deprecated behavior.
>
>  What I meant was subclassing ASDF:OPERATION only
>
> You can subclass OPERATION without a direction-OPERATION, but you have to completely override COMPONENT-DEPENDS-ON
> with your own behavior, never invoking the built-in method. I strongly recommend against doing this.
>
>  So, all operations are by default downward and sideway unless they are
>  subclass of (OR DOWNWARD-OPERATION UPWARD-OPERATION SIDEWAY-OPERATION
>  SELFWARD-OPERATION NON-PROPAGATING-OPERATION)
>
> Er... I'm not comfortable with saying that. In ASDF 2, all operations behaved in a way that is now called being downward and
> sideway. ASDF 3 treats operations which don't specify their dependency relationship in a way compatible with ASDF 2 to give
> maintainers a chance to update old extensions. The beautiful dream is that, one day, the compatibility behavior will be replaced
> with a hard error. Please do not treat the compatibility behavior as a part of ASDF 3's interface.
>

>From our exchange, I think its safe to summarise into this table:

"Table of ASDF operation classes to subclass and the corresponding
methods to define on your custom class."

|                      | OPERATION  | <direction>-OPERATION    | *-op |
|----------------------+------------+--------------------------+------|
| perform              | X          | X                        | X    |
| component-depends-on | X (note 1) |                          |      |
| input-files          | X          | (Depending on your need) |      |
| output-files         | X          | (Depending on your need) |      |

Note 1: You have to completely override COMPONENT-DEPENDS-ON for your
custom class without invoking (CALL-NEXT-METHOD). 

As a new ASDF extension writer, I think having a table like this helps a
lot to easily getting started.

>   Is it a linear chain or a "network chain" of
>  operations?
>
> The latter. When you define a subclass of SELFWARD-OPERATION, you specify what other operation(s) it is selfward to by
> overriding the :INITFORM of the slot SELFWARD-OPERATION. The value you provide may be either a single operation designator,
> or a list of operation designators. For example, (LOAD-OP COMPONENT) depends on both (COMPILE-OP COMPONENT) and
> (PREPARE-OP COMPONENT), so its SELFWARD-OPERATION slot is defined:
>
> (selfward-operation :initform '(prepare-op compile-op) :allocation :class)
>
>  can be done in parallel,
>
>  But how can I
>  express the operation dependencies such that ASDF knows PRINT-OP depends
>  on ECHO-OP?
>
> (defclass print-op (asdf:selfward-operation)
>   ((asdf:selfward-operation :initform 'echo-op :allocation :class)))
>

Thanks! I have tried it out and it works. Still need some time to
understand its behaviour though.

> ASDF as it exists now is not capable of running anything in parallel. Faré has an experimental project to do this, called POIU, but I
> can't speak for its status. Until very recently, SBCL was incapable of compiling files in parallel, and still today, lots of code does
> not-thread-safe stuff at load-time, so I'm not convinced it's practically possible to make ASDF parallel via shared-memory threaded
> concurrency. I believe POIU compiles each component in a separate process, then loads them sequentially.

I see, that's good to know. At least it's an implementation limitation
and not a design limitation I guess.

-- 
Regards,
zacque