From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Andrea Corallo Newsgroups: gmane.emacs.devel Subject: Re: Suppressing native compilation (short and long term) Date: Wed, 05 Oct 2022 14:25:58 +0000 Message-ID: References: <87bkqxf1ij.fsf@tethera.net> <8335c9dkyf.fsf@gnu.org> <83tu4odez7.fsf@gnu.org> <871qrrpkgx.fsf@trouble.defaultvalue.org> <834jwnbi6c.fsf@gnu.org> <87mtafnun5.fsf@trouble.defaultvalue.org> <83sfk6ahty.fsf@gnu.org> <8735c6b0wo.fsf@gnus.org> <87y1ty9lha.fsf@gnus.org> <87lepym6ok.fsf@trouble.defaultvalue.org> <877d1i9h7k.fsf@gnus.org> <83edvqyr3q.fsf@gnu.org> <874jwl8e4p.fsf@gnus.org> <87pmf64beo.fsf@gnus.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="22158"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) Cc: Eli Zaretskii , rlb@defaultvalue.org, monnier@iro.umontreal.ca, david@tethera.net, emacs-devel@gnu.org To: Lars Ingebrigtsen Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Oct 05 16:56:20 2022 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1og5oq-0005WX-4V for ged-emacs-devel@m.gmane-mx.org; Wed, 05 Oct 2022 16:56:20 +0200 Original-Received: from localhost ([::1]:51944 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1og5oo-0006cH-VN for ged-emacs-devel@m.gmane-mx.org; Wed, 05 Oct 2022 10:56:18 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:48682) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1og5Lb-0007QM-QB for emacs-devel@gnu.org; Wed, 05 Oct 2022 10:26:08 -0400 Original-Received: from mx.sdf.org ([205.166.94.24]:62180) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1og5LW-0000lT-Vm; Wed, 05 Oct 2022 10:26:07 -0400 Original-Received: from ma.sdf.org (ma.sdf.org [205.166.94.33]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 295EPw2V007317 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Wed, 5 Oct 2022 14:25:59 GMT In-Reply-To: <87pmf64beo.fsf@gnus.org> (Lars Ingebrigtsen's message of "Wed, 05 Oct 2022 16:01:35 +0200") Received-SPF: pass client-ip=205.166.94.24; envelope-from=akrl@sdf.org; helo=mx.sdf.org X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:296974 Archived-At: Lars Ingebrigtsen writes: > Andrea Corallo 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 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 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