On Tue, Oct 22, 2013 at 4:55 PM, Zach Beane wrote:
> Faré writes:
>
>> I'm not sure what you call "this behavior", but yes, upgrade to a new
>> ASDF (and getting it fixed if there's a bug) is probably the official
>> solution as long as ASDF is being maintained. In case ASDF falls back
>> into no
Faré writes:
> I'm not sure what you call "this behavior", but yes, upgrade to a new
> ASDF (and getting it fixed if there's a bug) is probably the official
> solution as long as ASDF is being maintained. In case ASDF falls back
> into not being actively maintained anymore, you can always overrid
On Tue, Oct 22, 2013 at 4:36 PM, Zach Beane wrote:
> Faré writes:
>> preloaded means: the code is already in the image, though the source
>> might not be available.
>
> Thanks for clarifying. Can this behavior only be changed by modifying
> the internals of ASDF?
>
I'm not sure what you call "thi
Faré writes:
> No, that's the opposite: if it's preloaded, it should *never* be found
> in preference to anything else, it's just available in the image as a
> fallback in case no source code was found. And I don't want people to
> have to retroactively modify quicklisp so it bumps
> sysdef-prelo
On Tue, Oct 22, 2013 at 3:55 PM, Zach Beane wrote:
> Faré writes:
>
>> I suppose the solution is for search-for-system-definition to treat
>> sysdef-preloaded-system-search specially and put it at the end of the
>> search, just like it magically puts find-system-if-being-defined
>> first.
>
> Doe
Faré writes:
> I suppose the solution is for search-for-system-definition to treat
> sysdef-preloaded-system-search specially and put it at the end of the
> search, just like it magically puts find-system-if-being-defined
> first.
Does that mean this behavior can only be controlled by modifying
