Stas Boukarev <stassats@...> writes:
> Stas Boukarev <stassats@...> writes:
>> Nikodemus Siivola <nikodemus@...> writes:
>>> On 2 Jun 2013 23:01, "stassats" <stassats@...> wrote:
>>>> commit 11f6bc8c710bfa83e8cddbc9a389be02ae6ee7ef
>>>> Author: Stas Boukarev <stassats@...>
>>>> Date: Sun Jun 2 22:58:27 2013 +0400
>>>> Don't go through fdefn when referencing #'known-functions.
>>>> Known functions are know to be always present, save on indirection by
>>>> using them directly.
>>> Very nice!
>>> ...but can we put this behind a #-sb-fluid? Unless I misread things
>>> this makes redefining things harder, which is a loss for interactive
>>> (IIRC :sb-fluid build is broken, but this would be a nice motivator to
>>> fix it...)
>> Yes, I thought about sb-fluid, but it being broken stopped me from
>> including it. Things which are referred as #'xxx are quite rare in SBCL
>> sources, and those that are rarely redefined. But I'm now contemplating
>> of doing a similar thing for full calls, that would certainly require
>> usage of sb-fluid or similar.
> Now that I think about full-calls, it doesn't make much sense to get rid
> of fdefns here, since they include raw-addr slot.
> And I didn't account in the previous mail for third party code
> referencing known functions and not being able to use new
> redefinition. Maybe sb-fluid would make sense there, but with the number
> of transforms, vops and other things, I already don't expect the changes
> to SBCL to take effect without a recompile.
Another idea is when a function is redefined, a stub is written in its
stead, which calls the new function. And then upon GC they can be
With best regards, Stas.