On 2010-04-15, at 22:59 , Faré wrote:

Interestingly, I wanted to get rid of it and/or refactor how this thing is done, particularly so to make ASDF and POIU play nicer with each other. Sigh.

Note that I'm currently refactoring TRAVERSE. Because it was taking 2 minutes to process the qres-sbcl-xne.asd generated by XCVB, what with O(n^3) algorithms and worse. Will release 1.700 when it's done.

absent the system definitions for qres-*-xne it is hard suggest why. still, if the dependency structure is literally the "flat" which you indicated in your earlier message, that might imply serial dependency, which - given the way parse-component-form implements serial dependency, would not be a pretty graph for a large system.

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

On 2010-04-16, at 10:33 , Juan Jose Garcia-Ripoll wrote:

On Fri, Apr 16, 2010 at 12:01 AM, james anderson <james.anderson@setf.de> wrote: 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.

Yes, but everything is transformed into an in-order to internally when parsing the system definition. The result is a duplicated list of dependencies :in-order-to load-op and :in-order-to compile-op.

the presence of a single list is independent of the particular annotations. yes, it was a bad idea to hardwire the implication between load and compile operations.

The additional problem is that right now we have a dichotomy between load and load-src-op and apart from the cases in which :in- order-to is used for testing, the other cases just write dependencies for one of the operations and not for the other.

The third problem is that the in-order to mechanism does not provide any kind of inheritance and if I tried to write a fix for load-src-op that creates the hierarchy

operation +- compile-op +- load-op +- compile-and-load-op +- load-source-op

this does not work.

your remarks suggest that you fail to appreciate how broken i believe traverse to be.[1]

Your remarks fail to appreciate how good and useful I believe a properly written traverse could be.

if you write that, i infer, you did not look at the reference.[1] i call it again to you attention, for your reference. you may disagree, that it embodies the best approach. you man conclude that it is also an inadequate implementation. but, you should at least engage the argument which that re-implementation represents rather than suggest that there is none.[2] it was a couple of months ago, but i believe it demonstrates an alternative asdf model and an alternative traverse implementation which address all of the items in your list. both better suited to the current and future development environments than the current one. among other things, it demonstrates that the two phase process which is central to traverse - plan collection followed by plan execution, is not necessary, and is not necessarily the correct process for a contemporary build system. --- [1] : http://github.com/lisp/de.setf.asdf.x [2] : http://github.com/lisp/de.setf.asdf.x/blob/master/README.md