Re: Emacs-devel Digest, Vol 166, Issue 137

[Stefan Monnier]

>> No, I'm thinking rather of not keeping the bytecode file around at all,
>> or to store it in an "internal cache" (which could be kept in the
>> file-system but could be erased at any point and without any command to
>> "load a bytecode file").
> Sounds like a JIT.

Yes and no.  JIT usually applies to the case of generating machine code,
whereas the above scheme doesn't necessarily imply anything else than
the current scheme of compiling to a .elc file.

> Is there *any* testing done running emacs code on older bytecode, either in
> the normal course of testing or before a release?

Testing, as in a test-suite?  No.

Only testing in the form of people out there trying out Emacs from Git,
or from the pretests and reporting problems.

Note that this kind of testing leaves a lot of false negatives: often
they don't report the problems, because they try to workaround the
problems themselves (they don't behave as testers and don't feel
a responsibility to file bug reports when running prerelease versions;
instead they'll ask for help in various fora where other users give them
hints for how to workaround problems).

> If not, given the expectations that you ascribe to users, there
> probably should be.

Probably.  Don't count on me to do that work, tho.

> If you are saying that *all* Emacs-23 packages and bytecode runs on
> Emacs-27 then, sure, safer-load-file doesn't need to do anything.

They don't all run, but they "should" all run.  We know of some
exceptions, and there are probably some more exceptions we don't know
about, but by and large this has worked well enough (largely controlled
by the amount of bug reports we receive).

> A tool like safer-load-file could be told which sets of *packages* are
> incompatible and warn when it sees a problem.

We've had some such warnings in the past for some particular known
problems, but nothing "systematic".  I think the problem is a lack of
motivation because in most cases the problems will be apparent soon
enough that there's not much benefit to extra checks.

>> > There are free opcode space available. "apply" could be added is someone
>> > chooses to add it.
>> I'm just pointing out differences that illustrate the fact that
>> tradeoffs were quite different.
> Personally I think you are ascribing too much intentionality; this could
> just as easily be explained by oversight.

Could be.

> This still all sounds a little loose, and not fully formed.

It's not fully formed at all.  Otherwise I'd probably have a patch for it.


        Stefan