<div class="gmail_quote">On Wed, Mar 17, 2010 at 11:28 PM, Robert Goldman <span dir="ltr"><<a href="mailto:rpgoldman@sift.info">rpgoldman@sift.info</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">For example, if I'm writing the ASDF</div>
definition for my FLOYD-WARSHALL transitive closure library, I can't be<br>
putting into it<br>
<br>
(defmethod PERFORM ((op load-op) (c cl-source-file))<br>
....)<br>
<br>
because that means that anyone who loads my library will be loading it<br>
into a radically different environment.<br></blockquote><div><br></div><div>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?</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">1. really fuse the ECL extensions into ASDF proper, to the extent of<br>
putting the source in there. We will still rely on some periodic<br>
testing to make sure that any incompatibilities are caught, but James<br>
Anderson's work seems like it will fix this problem.<br></blockquote><div><br></div><div>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
2. keep ECL separate and provide some statement, ideally one that can<br>
be programmatically checked, about the kind of API you expect. For<br>
example, you could add a test to the test suite that would check for the<br>
absence of a method for PERFORM on the signature (T COMPONENT). That<br>
would verify that you have the method free for your own use.</blockquote><div><br></div><div>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.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">> Integration with TRAVERSE is crucial and depending on how _you_ _all_</div><div class="im">
> decide that TRAVERSE should behave then we will have to adapt the code<br>
> one way or another. This integration is fragile. If at some point the<br>
> algorithm is randomly changed and you decide that systems should be<br>
> listed before components, then we are f*ck*d.<br>
<br>
</div>Can you say what exactly has goofed this up for you? Note that TRAVERSE<br>
is not deterministic --- it's possible to specify multiple different<br>
orderings that satisfy the dependency specification in the ASDF file.<br></blockquote><div><br></div><div>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">> asdf-ecl.lisp only defined methods on COMPONENT-DEPENDS-ON, INPUT-FILES,<br>
> OUTPUT-FILES, PERFORM and OPERATION-DONE-P. All the signatures we used<br>
> contain at least either OUR components our OUR operations, so in that<br>
> sense they should be allowed to exist and ASDF should be careful on<br>
> deciding what to do with these methods -- for instance, rewriting paths<br>
> as we discussed on another thread.<br>
<br>
</div>I thought you were specifically referring to core methods. I see that I<br>
was not fully understanding.</blockquote><div><br></div><div>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!</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">
> At some point the extensions were accepted in the source tree, point at<br>
> which I asked whether the integration that was done the right way or<br>
> not. The lack of answer was understood as an ok.<br>
<br>
</div>This exhibits two problems ASDF development. The underlying problem is<br>
that people are doing this work on very thin time slices.<br>
<br>
1. Lack of answer can never effectively be treated as "ok" --- lack of<br>
an answer is more likely to simply mean "I haven't had time to look at<br>
this." My changes to TRAVERSE went in a very long time ago, and only<br>
after a very long discussion in the mailing list. It's clear that you<br>
didn't have time to review them then, and so an issue that we thought<br>
was closed will have to be reopened.<br></blockquote><div><br></div><div>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
2. The documentation is badly bit-rotted. The section on extending the<br>
ASDF object model is in particularly bad shape. It was never complete,<br>
as far as I can tell, and it has not been updated. We badly need a<br>
protocol specification stating exactly what has to be defined to make<br>
new components and operations. I can't say that I fully understand how<br>
to do this --- my experiments have often seemed to go just fine, then<br>
led to me stumbling much later on a problem that came up because some<br>
critical method was missing.<br></blockquote></div><div><br></div>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.<div>
<br></div><div>Juanjo<br clear="all"><br>-- <br>Instituto de Física Fundamental, CSIC<br>c/ Serrano, 113b, Madrid 28006 (Spain) <br><a href="http://tream.dreamhosters.com">http://tream.dreamhosters.com</a><br>
</div>