Re: Suppressing native compilation (short and long term)

[Andrea Corallo <akrl@sdf.org>]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Andrea Corallo <akrl@sdf.org> writes:
>
>> Also repeatable testing are most likely executed in batch mode and...
>>
>> ...surprise surprise deferred compilation is *already* *disabled* in
>> this mode!!
>
> Not all testing happens in batch mode.
>
> Andrea Corallo <akrl@sdf.org> writes:
>
>>> I'm not sure we need to save the trampolines at all (in this
>>> don't-do-native-compilation configuration) -- Andrea probably knows.
>>> Andrea, would it be possible to just create and use the trampolines
>>> without writing them to a file?
>>
>> No
>
> Yes, it is.  (That is, the trampolines get written to /tmp, but can be
> deleted after loading.)

You asked: "would it be possible to just create and use the trampolines
without writing them to a file?"

I aswered "no".  Of course writing a file into /tmp is still writing to
a file.

> Andrea Corallo <akrl@sdf.org> writes:
>
>> That's your opinion and I respect it.  Still
>> `inhibit-automatic-native-compilation' does *not* disable automatic
>> native compilation but only a mechanism contributing to it, so it's IMO
>> a bad naming decision.
>
> Like I said earlier, if anybody has a better name for the variable,
> renaming it is fine, but it has to be an improvement.

I think `inhibit-jit-native-compilation' is better as I believe users
perceive the JIT word related to user code and not internal mechanisms
as trampolines.

I've the perception that this change was done without the full picture
in mind of how the native compiler and his mechanisms works.  As a
result the current naming is IMO just wrong, and as such is a step
backward the original state.

As maintainer of the native compiler is my duty to point this out and
ask for reversion.

>> I have not said that once code is in master discussion is forbidden.  I
>> said that to discuss a change there's *no* requirement to install it in
>> master, especially before sufficient discussion is done on the list for
>> these tricky interfaces.  My 2cts are that these mechanisms and changes
>> should be very well thought and participated before being modified.
>>
>> As maintainer of comp.c and related I ask to have this changeset
>> reverted and then we restart thinking again what's the best change (if
>> any) needed here.
>
> I don't see any advantages to doing that -- the changes that are in now
> seem to work fine for the stated use cases (which are both "don't write
> to $HOME while testing" and "I want to use a AOT-compiled Emacs, but
> don't do any further JIT compilation while running Emacs").

I explained in two other mails that these changesets are orthogonal to
what the user asked and don't help them.  Also is still not clear why
the user asked for this knob.

It is *extremely* important that we analyze the usecase *before*
introducing new interfaces.  The user might ask for a new interface
without knowing we can provide or suggest a better solution. It might
even already exists!!

Developers can't just add mechanisms without a full understanding of
the current ones just because there was a user request, even worst
without an in deep discussion, sorry this is IMO just recipe for
disaster.

  Andrea