On Wed, Apr 21, 2010 at 11:50 AM, james anderson <span dir="ltr"><<a href="mailto:james.anderson@setf.de">james.anderson@setf.de</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">

<div style="word-wrap: break-word;"><div class="im"><div><blockquote type="cite"><div style="margin: 0px;">further experiments demonstrated that - with changes to the scripts  </div><div style="margin: 0px;">to account for functions which would be removed, all regression tests  </div>

<div style="margin: 0px;">pass, and that with appropriate initialization, a multi-runtime build  </div><div style="margin: 0px;">is supported for the normal abcl/acl/ccl/clisp/cmucl/ecl/lw/sbcl  </div><div style="margin: 0px;">

complement. </div></blockquote></div></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></blockquote><div><br>I presume those tests only use the _default_ build system, not ECL's extensions. Your patches were produced against 1.5 and there the OUTPUT-FILES would only return one file, even for ECL.<br>

<br>However, once we integrated ECL's extensions, these produce  two object files, and I fail to see from your patch how the output files are handled -- from what I can see, since the OUTPUT-FILES method does not have an :AROUND, the output of ECL's extensions is not translated: they just take the source file produce a compile-file pathname and that's it. In other words: it is going to work, but it is going to have files laying around, both translated and not.<br>

<br>I suppose in your model developers are expected to integrate an explicit call to component-translate-pathname in every method they define for output-files.<br><br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">

<div style="word-wrap: break-word;">no, in that system instantiation protocol includes a step which (effectively) walks the model to compute a location for each component. <br></div>
</blockquote></div><br>Indeed, I find this an interesting approach, independently of what method is used for translation, but I see a problem if a user decides to temporarily deactivate translations or change the destination of a system. Right now it amounts to changing the translation table. With your model it involves re-reading and rebuilding the system and components.<br>

<br>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>