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 15:12:46 +0000 Message-ID: References: <87bkqxf1ij.fsf@tethera.net> <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> <87h70i4a46.fsf@gnus.org> <87czb648r9.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="9656"; 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 17:40:53 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 1og6Vx-0002Kx-NL for ged-emacs-devel@m.gmane-mx.org; Wed, 05 Oct 2022 17:40:53 +0200 Original-Received: from localhost ([::1]:39036 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1og6Vw-0004iF-N2 for ged-emacs-devel@m.gmane-mx.org; Wed, 05 Oct 2022 11:40:52 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:35124) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1og64r-000863-3T for emacs-devel@gnu.org; Wed, 05 Oct 2022 11:12:54 -0400 Original-Received: from mx.sdf.org ([205.166.94.24]:56412) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1og64o-0004DR-Ri; Wed, 05 Oct 2022 11:12:52 -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 295FCkm1022029 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Wed, 5 Oct 2022 15:12:47 GMT In-Reply-To: <87czb648r9.fsf@gnus.org> (Lars Ingebrigtsen's message of "Wed, 05 Oct 2022 16:58:50 +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:296983 Archived-At: Lars Ingebrigtsen writes: > Andrea Corallo writes: > >> Well to give few examples you were not aware of: the `load-no-native' >> mechanism, the fact that deferred compilation is not the only mechanism >> concurring to automatic native compilation (and that's why it was named >> as such and not just automatic native compilation), the fact that native >> compilation does not happen in non interactive sessions. > > I didn't know about the first (because it's badly named and > undocumented, as well as totally irrelevant to the discussion in this > thread), but I was aware of all the other things here, and I'm not sure > why you'd think otherwise. Well because I cannot understand why one would do any of these changes if these mechanisms are known. > My perception here is that you're mostly angry that somebody else is > working on your code -- but that's pretty common. Many people feel > proprietary towards code they've written. This is not the case at all, please trust me, your changeset does two things: 1- change the name a knob, but it goes from a maybe un-intuitive one to just (as explained) a plain wrong one. 2- add a mechanism that (as explained) cannot help with the user request in this discussion at all. These are both not improvements, this is the reason I'm asking for it to be reverted now. Please don't accuse me to feel the ownership on this code, I've never objected to other changes on this done on master as I thought were correct. Andrea