Bug report: Loading a FASL into a package which doesn't import SETQ
Mark Evenson
evenson at panix.com
Wed Nov 11 09:40:23 UTC 2020
> On Nov 11, 2020, at 03:44, Robert Munyer <2433647181 at munyer.com> wrote:
[…]
> It's conceivably possible that _all_ of the manipulation of *PACKAGE*
> that happens during COMPILE-FILE could be removed, because the user is
> already required to have *PACKAGE* set correctly when invoking LOAD.
I don’t think this is true: COMPILE-FILE should actually capture the current package when COMPILE-FILE is invoked, arranging to have this package present when LOAD occurs. [An example of this][1] works on SBCL/CCL but fails on ABCL even with all of your suggestions. Please correct me if you believe this isn’t the case.
[1]: <https://github.com/armedbear/abcl/pull/353/files#diff-886c987127185fcb79c86d6531feefaf00c1365126fc63afa248096f1da49e6eR12>
By [explicitly putting an IN-PACKAGE form in our fasl prologue which includes the value of the package that COMPILE-FILE is invoked within, I am able to make all my current tests pass.
[2]: https://github.com/armedbear/abcl/pull/353/files#diff-ccaa655ebf1432951ff70b34dcd6e82428cba2c5035e8077c7b183a6551bba3dR810
The new behavior is present in [pull][353]. I am going for a walk while I let the CI do its thing, pondering if I am really testing all the cases, but anticipate merging a consolidated version later today.
[353]: https://github.com/armedbear/abcl/pull/353/
yours,
Mark
--
"A screaming comes across the sky. It has happened before but there is nothing
to compare to it now."
More information about the armedbear-devel
mailing list