On Wed, Mar 17, 2010 at 11:28 PM, Robert Goldman
<rpgoldman@sift.info> wrote:
For example, if I'm writing the ASDF
definition for my FLOYD-WARSHALL transitive closure library, I can't be
putting into it
(defmethod PERFORM ((op load-op) (c cl-source-file))
....)
because that means that anyone who loads my library will be loading it
into a radically different environment.
Understood. Then the general restriction would be that at least one of the classes in the method should be proprietary to allow the user to write such methods. Does this seem reasonable?
1. really fuse the ECL extensions into ASDF proper, to the extent of
putting the source in there. We will still rely on some periodic
testing to make sure that any incompatibilities are caught, but James
Anderson's work seems like it will fix this problem.
Right now I think it is more sensible to group all nonstandard operations in asdf-ecl.lisp, not because they are considered extraneous, but because of readability. asdf.lisp is already large enough.
2. keep ECL separate and provide some statement, ideally one that can
be programmatically checked, about the kind of API you expect. For
example, you could add a test to the test suite that would check for the
absence of a method for PERFORM on the signature (T COMPONENT). That
would verify that you have the method free for your own use.
Sounds sensible, minimalistic testing is what I am doing right now for all other libraries I develop. I will have to learn how tests are written right now. Maybe also adding some comments to the main methods.
> Integration with TRAVERSE is crucial and depending on how _you_ _all_
> decide that TRAVERSE should behave then we will have to adapt the code
> one way or another. This integration is fragile. If at some point the
> algorithm is randomly changed and you decide that systems should be
> listed before components, then we are f*ck*d.
Can you say what exactly has goofed this up for you? Note that TRAVERSE
is not deterministic --- it's possible to specify multiple different
orderings that satisfy the dependency specification in the ASDF file.
Oh, there is nothing with TRAVERSE's output _right now_. It has bitten us hard in the past, though and I was just mentioning for the record, to give a complete overview of how this kind of operations bind to the ASDF core: these are operations rely on traversing a system and performing things on them, a task that can be very useful for many other purposes, such as grovelling information from libraries (kind of TAGs files), metaprogramming, etc. All these things should be doable with ASDF if the API is fixed with a long term scope.
> asdf-ecl.lisp only defined methods on COMPONENT-DEPENDS-ON, INPUT-FILES,
> OUTPUT-FILES, PERFORM and OPERATION-DONE-P. All the signatures we used
> contain at least either OUR components our OUR operations, so in that
> sense they should be allowed to exist and ASDF should be careful on
> deciding what to do with these methods -- for instance, rewriting paths
> as we discussed on another thread.
I thought you were specifically referring to core methods. I see that I
was not fully understanding.
Ok, so then we may consider that these are non-volatile definitions, which is great because as I said this is basically all one really needs to build things on top of ASDF!
> At some point the extensions were accepted in the source tree, point at
> which I asked whether the integration that was done the right way or
> not. The lack of answer was understood as an ok.
This exhibits two problems ASDF development. The underlying problem is
that people are doing this work on very thin time slices.
1. Lack of answer can never effectively be treated as "ok" --- lack of
an answer is more likely to simply mean "I haven't had time to look at
this." My changes to TRAVERSE went in a very long time ago, and only
after a very long discussion in the mailing list. It's clear that you
didn't have time to review them then, and so an issue that we thought
was closed will have to be reopened.
I miss a lot of emails when the subjects are not directly related. On reading the archive of emails I see what you were discussing -- to me it just looked like a minor detail in dependency binding and nothing that would change the logic of TRAVERSE.
2. The documentation is badly bit-rotted. The section on extending the
ASDF object model is in particularly bad shape. It was never complete,
as far as I can tell, and it has not been updated. We badly need a
protocol specification stating exactly what has to be defined to make
new components and operations. I can't say that I fully understand how
to do this --- my experiments have often seemed to go just fine, then
led to me stumbling much later on a problem that came up because some
critical method was missing.