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
