[asdf-devel] ASDF traverse changed behavior?

Wed Mar 17 22:54:17 UTC 2010

On Wed, Mar 17, 2010 at 11:28 PM, Robert Goldman <rpgoldman at 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.
>

I must say I am basically in the same position. That is why I ask so often
and may sound sometimes like nagging. Seems we are all a bit insecure on how
ASDF should behave, maybe two things would help -- one would be writing down
a description of what the main function, TRAVERSE, does, another one is
perhaps enlarging the set of tests so that we all feel safer about
experimentation.

Juanjo

-- 
Instituto de Física Fundamental, CSIC
c/ Serrano, 113b, Madrid 28006 (Spain)
http://tream.dreamhosters.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/asdf-devel/attachments/20100317/fd81487c/attachment.html>