<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Sep 23, 2015 at 1:10 PM, Faré <span dir="ltr"><<a href="mailto:fahree@gmail.com" target="_blank">fahree@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">>>: Faré<br>
<span class=""><br>
>> when asdf-ecl was initially written, its load-fasl-op was intended<br>
>> as the default way to load a system. Because of implementation bugs<br>
>> revealed as ASDF improved its testing, this feature was disabled at<br>
>> some point while developing ASDF 3.1. Now that these implementation<br>
>> bugs seem to have been solved, for both ECL and MKCL, the question is:<br>
>> do you guys want me to make load-bundle-op (as it is now named)<br>
>> the default *load-system-operation* on ECL and/or MKCL?<br>
<br>
</span>>:JCB<br>
<span class="">> I have been away from ASDF related concerns long enough for me<br>
> to be unable to form a precise understanding of what such move would<br>
> precisely mean right now, sorry.  But I will try to push out the door<br>
> MKCL 1.1.10, the latest maintenance release of the MKCL 1.1.X line,<br>
> before the end of this month. And as part of that operation I want<br>
> to upgrade the bundled ASDF to 3.1.5.  So I'll have then a great<br>
> opportunity to get reacquainted with all those load-XXX-op questions,<br>
> and I should be able to have an informed opinion by then.<br>
><br>
</span>The question is whether you prefer to load a previously compiled system<br>
via a single .fasb or via plenty of .fas (which wasn't previously working).<br>
<span class=""><br></span></blockquote><div><br></div><div>Put like this I would say that my natural inclination is to say that<br></div><div>.fasb should (always?) have precedence over a bunch of .fas if<br></div><div>the bunch of .fas provides the same functionality as the .fasb.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="">
> Are we talking about something like #'cl:lisp-implementation-version and<br>
> related facilities? If so then you could be interested in:<br>
><br>
> #'si:mkcl-major-version<br>
> #'si:mkcl-minor-version<br>
> #'si:mkcl-patch-level<br>
><br>
</span>Is (lisp-implementation-version) guaranteed to be the concatenation<br>
of these, with no trailing data?<br>
<span class=""><br></span></blockquote><div><br></div><div>Well, the idea is indeed to let #'cl:lisp-implementation-version be free<br></div><div>to have some trailing data like perhaps a test level marker ("alpha",<br></div><div>"beta", "rc1"...). Otherwise our three little stooges up here would<br></div><div>be pretty redundant, wouldn't they?<br><br></div><div>But currently this returns T:<br><br>(string= (lisp-implementation-version)<br>             (concatenate 'base-string<br>                                  (si::mkcl-major-version)<br>                                  "."<br>                                  (si::mkcl-minor-version)<br>                                  "."<br>                                  (si::mkcl-patch-level)))<br><br><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="">
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• <a href="http://fare.tunes.org" rel="noreferrer" target="_blank">http://fare.tunes.org</a><br>
</span>...so this guy walks into a bar.<br>
"The usual, Mr. Descartes?" the barman asked.<br>
"I think not," Rene replied, and promptly disappeared.<br>
</blockquote></div><br></div></div>