[asdf-devel] :in-order-to

[james anderson]

On 2010-04-15, at 23:30 , Juan Jose Garcia-Ripoll wrote:

> On Thu, Apr 15, 2010 at 10:40 PM, james anderson  
> <james.anderson at setf.de> wrote:
>
> On 2010-04-15, at 22:26 , Juan Jose Garcia-Ripoll wrote:
>
> > Who uses it?
>
> depends on what one means by "uses it"? the value in the respective
> slot is more-or-less central to the dependency computation and is
> initialized in the instantiation process[1]. once it plays that role,
> is there any reason to not place the initarg in the interface?
>
> The current implementation can be done without :in-order-to, and I  
> think Fare also has that in mind.

yes, the initarg is not essential. however, as evident in the issues  
which you raise below, its presence does not contribute significantly  
to asdf deficiencies.

>
> Personally I also find another reason to make the under-the-hoods  
> algorithm not rely on in-order-to, and it is the following one.
>

you will need to elaborate on why this matters. the primary  
dependencies are all in a list which is bound to the in-order-to slot.
the :in-order-to initarg is just circumstantially involved in this.  
most of the initialization value is collected from the other  
dependency initargs.

> The most valuable information ASDF has is the list of dependencies  
> which would allow one to do a topologically sorted list of  
> components to be loaded. By loaded I do not mean compiled and  
> loaded but just loaded, assuming everything had been already compiled.
>
> Currently we can not get this graph because every LOAD-OP produces  
> a COMPILE-OP which may itself trigger a LOAD-OP of other component.  
> LOAD-SRC-OP currently does not work to get an equivalent graph  
> because it is not available for all components and because not all  
> libraries take it into account in :in-order-to. ASDF also does not  
> take it itself into account in the automated dependencies.

none of which has to do with the initarg. it has to do with how the  
graph is annotated and the way traverse operates on it. there are  
lots of things one should be able to do with the dependency graph. it  
would be nice. your remarks suggest that you fail to appreciate how  
broken i believe traverse to be.[1]

>
> So, I would say, in order to produce that beautiful and useful  
> list: 1) provide another mean to have a test-op (perhaps a :test- 
> system option?), 2) remove :in-order-to, 3) implement a kind of  
> "force-all" option to TRAVERSE which makes it behave as if nothing  
> was loaded before and either a) fix LOAD-SRC-OP and rely on it or  
> b) provide a means to temporarily deactivate the triggering LOAD-OP  
> -> COMPILE-OP. With this we can use TRAVERSE to get the sorted graph.

traverse needs to be rewritten. faré alluded to a "refactoring". with  
all of a .021 version bump. i'm curious, whether he manages to stop  
at that.

>
> Finally, note that removing :in-order-to does not mean having  
> serial order, for we still have the other ways to express  
> dependencies.


---

[1] : http://github.com/lisp/de.setf.asdf.x
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/asdf-devel/attachments/20100416/0632b94a/attachment.html>