
<html><body bgcolor="#FFFFFF"><div>The idea of shipping an unguaranteed extension is fine with me. Let me just clarify, please: my concern was what seemed like a requirement for getting the component-gathering right. I'd rather not expose that to "outsiders" until we can get it right, and I'm worried, based on my experience with TRAVERSE, that we'd end up locked into some bug-compatibility.</div><div><br></div><div>Sounds like there's a good function that can be exposed as an extension without needing to get the component-gathering right, which would be great.</div><div><br></div><div>Maybe I got misled -- are there two issues: what can be done now and what we could do a lot better if component gathering worked reliably?</div><div><br>On Mar 29, 2010, at 13:43, Juan Jose Garcia-Ripoll <<a href="mailto:juanjose.garciaripoll@googlemail.com">juanjose.garciaripoll@googlemail.com</a>> wrote:<br><br></div><div></div><blockquote type="cite"><div><div>Hi Robert,</div><div><br></div><div>I must say that I understand your concerns which are just, right now, *time*. And I also understand that in prolonging this thread I risk you lose your patience with a feeling that I am wasting your time, but please read this email and understand the following key points that indeed will save us all some time</div>

<div><br></div><div>1) We have a working set of ASDF extensions that ECL users apply routinely to most systems out there. It works.</div><div><br></div><div>2) You asked me to extend those extensions to SBCL in an email to the mailing list. I did it in a way that DOES NOT CHANGE the way ASDF behaves in any single way (*)</div>

<div><br></div><div>3) Those extensions can be shipped with ASDF without warranty of 100% work, and an explicit statement such as the following one:</div><div><br></div><blockquote class="webkit-indent-blockquote" style="margin: 0 0 0 40px; border: none; padding: 0px;">

The asdf-bundle operations are only designed to work with systems that contain basic ASDF operations and components. The protocol for systems that rely on external resources, such as shared libraries, compiled C files, bitmaps, etc, is not yet defined, so using it on such systems is not guaranteed to work.</blockquote>

<div><br></div><div>4) Given this, the current implementation just works. No work on implementors to do before ASDF 2.0</div><div><br></div><div>5) In order to remove the statement of 3) we have to code a better map-over-ASDF or gather-components function. This can be done at any time and it is not a requirement for shipping the current extensions. This was what I said should be "discussed", but if you are too busy, simply forget it.</div>

<div><br></div><div>You can stop reading here if you wish, and I will continue in a separate email with a discussion of how this should be completed if there is ever a desire to include these features in ASDF.</div><br clear="all">

Juanjo<div><br></div><div>(*) Only a small :around method for operation-done-p, but this method is only active when "performing" one of the bundle operators.<br><div><br>-- <br>Instituto de Física Fundamental, CSIC<br>

c/ Serrano, 113b, Madrid 28006 (Spain) <br><a href="http://tream.dreamhosters.com"><a href="http://tream.dreamhosters.com">http://tream.dreamhosters.com</a></a><br>

</div></div>

</div></blockquote></body></html>