<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">
<br><div><div>On 2010-04-21, at 10:56 , Juan Jose Garcia-Ripoll wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div class="gmail_quote">On Wed, Apr 21, 2010 at 10:31 AM, james anderson <span dir="ltr"><<a href="mailto:james.anderson@setf.de">james.anderson@setf.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> the patch which was enclosed in the earlier message[2] demonstrated<br> an implementation which modifies the three functions - component-<br> pathname, input-files, and output-files, extends the function which<br> constructs the component absolute pathname, and adds a function to<br> map between logical and physical pathname components. [...]<br> <div class="im"> </div>we can discuss the general utility of logical pathnames at length, at<br> your leisure. elsewhere. my enquiry concerns whether logical pathname<br> translations would serve as a more compact implementation mechanism<br> for asdf output translations than the present method.<br> <div class="im"><br> ><br> > And even then you'll have a hard time fixing things that users<br> > can now trivially do with the following translation:<br> ><br> > (:root ("C:/my/cl/cache" :implementation))<br> ><br> > This will work and make his file in<br> > \\remote-host\myshare\cl\cl-foo\foo-V2.000\bar_baz.lisp<br> > be compiled as obvious from the spec into<br> > C:\my\cl\cache\sbcl-1.0.38-windows-x86\remote-host\myshare\cl\cl-<br> > foo\foo-V2.000\bar_baz.fasl<br> <br> </div>this would appear to be the equivalent of a translation on the order of<br> <br> `("**;*.*.* ,(concatenate 'string "C:/my/cl/cache/"<br> (asdf::implementation-identifier)<br> "/**/*.*.*"))<br clear="all"></blockquote></div><br>Let's try to clarify the discussion.<br><br>* Fare insists on the validity of the current pathname translation mechanism, which allows the user to specify the destination of compiled files using physical pathnames and some configuration file or S-expr. If the user knows where the original file lived, he can find where the compiled file lives easily -- one to one mapping, no ambiguity, no names changes except mapping everything to a new tree.<br> <br>* James is claiming that this can be implemented using _internally_ logical pathnames with a logical pathname tree structure that is constructed from the component names and not from the physical location of the files they represent. This would be complemented with a function to obtain the actual location of compiled files given the component object. The configuration can be mapped to this structure and the overall implementation would then be smaller.<br></blockquote><div><br></div>in principle, yes. in detail, there is no need to construct a global structure as the computation can proceed locally. </div><div><br><blockquote type="cite"> <br>I see shortcomings on both sides<br><br>- Code size<br>- A bunch of people already using asdf-binary-locations out there (which is what was merged in)<br></blockquote><br>which one should be able to continue to support in any case.</div><div><br><blockquote type="cite">- James' implementation only seems to allow one file per component and it does not seem to take into account when OUTPUT-FILES returns more than one file.<br></blockquote><div><br></div>to quote from the original post.</div><div><br></div><div><blockquote type="cite"><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">further experiments demonstrated that - with changes to the scripts </div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">to account for functions which would be removed, all regression tests </div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">pass, and that with appropriate initialization, a multi-runtime build </div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">is supported for the normal abcl/acl/ccl/clisp/cmucl/ecl/lw/sbcl </div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">complement. </div></blockquote><br></div><div>that is, the multi-runtime build included ecl. for which the expression of the functional requirements was the conditionalization in the output-files method. if that is the extent of the requirement, then ecl is taken into account.</div><div><br></div><div> <br><blockquote type="cite"> - In James's model the interrogation: where does the compiled file associated to "file1.lsp" does not make sense without traversing the ASDF system and locating that file and its associated component.<br></blockquote><div><br></div>if the intended question was: "does the compiled file associated with 'file1.lsp' make sense without traversing the ASDF system?"</div><div><br></div><div>yes and no.</div><div>yes, in that the output - and _input_ - location translations are computed with respect to the respective component only.</div><div>no, in that system instantiation protocol includes a step which (effectively) walks the model to compute a location for each component. as i noted in the original message, this makes it a lot easier to understand a component pathname computation, but is independent of any translation mechanism. in addition, it is no longer even unique to the lp-based location translation implementation. as the step was already introduced in 1.676.</div><div><br></div><div><br></div></body></html>