From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Suppressing native compilation (short and long term) Date: Mon, 03 Oct 2022 21:49:34 +0300 Message-ID: <835yh0yc75.fsf@gnu.org> References: <87bkqxf1ij.fsf@tethera.net> <8335c9dkyf.fsf@gnu.org> <83edvqafr7.fsf@gnu.org> <87fsg6m5zx.fsf@trouble.defaultvalue.org> <83mtaeys7k.fsf@gnu.org> <87o7uukngi.fsf@trouble.defaultvalue.org> <83a66czz5q.fsf@gnu.org> <83mtacyfvl.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="25989"; mail-complaints-to="usenet@ciao.gmane.io" Cc: rlb@defaultvalue.org, tomas@tuxteam.de, emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Oct 03 20:57:02 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 1ofQcf-0006b6-Ty for ged-emacs-devel@m.gmane-mx.org; Mon, 03 Oct 2022 20:57:02 +0200 Original-Received: from localhost ([::1]:57752 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ofQce-00054s-PQ for ged-emacs-devel@m.gmane-mx.org; Mon, 03 Oct 2022 14:57:00 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:57266) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ofQVY-0004VK-16 for emacs-devel@gnu.org; Mon, 03 Oct 2022 14:49:40 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:59374) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ofQVX-0005l4-JD; Mon, 03 Oct 2022 14:49:39 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=M3yZuGlYGjdjKZTKFNbFCy0kSYC8ALLNw42xn+/5lyk=; b=Auw8nFSmCp3j DH1IaYft6J9bRl0aVClpJz27NKOlZBRYt8hmMy7winpIQ0DUlHke99GGOmPBN7oBDtyfoC6fDwF5J /OkCDkXHmcjMkFER/lcV6HPZgUGzi/rjZP0ctIP3Anj4YZvr3BJbOsfVwLwMe7D6ruLiyiO5wAi09 Fu0QztLzZJyrXuOsoeZ6Y6oEu/9w8sy5V62yGajjm9l2JQcSqcm4OeYucloIcrXIeCa5MyUoxf0Ow V3VJKnVjegL5FsAuBxXNWwjIjgIgN17AjWWYGhYIzaNtGLIgr5JmY5P+LwYQD9ktYgRnRNGC8hI3/ MvkREYpxmSuMM/Ck+pu7KA==; Original-Received: from [87.69.77.57] (port=2000 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ofQVX-0003hC-1x; Mon, 03 Oct 2022 14:49:39 -0400 In-Reply-To: (message from Stefan Monnier on Mon, 03 Oct 2022 14:33:09 -0400) 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:296788 Archived-At: > From: Stefan Monnier > Cc: rlb@defaultvalue.org, tomas@tuxteam.de, emacs-devel@gnu.org > Date: Mon, 03 Oct 2022 14:33:09 -0400 > > >> And the issue is not subprocesses per se, but it's extra processing that > >> happens outside of the control of the user. > > How do you mean "outside of the control of the user"? The user causes > > it by loading a feature. > > When a user loads a feature, this request doesn't say explicitly "and > native compile the file". And there is no direct way to "just load this > package without compiling it". So the compilation is not really under > the control of the user. > > I don't think users know, when they load a feature, if it's the first > time they loaded this feature in this version of Emacs, so by and large > they can't predict when the compilation does happen. It just takes getting used to, that's all. > > How is that different from any other command that uses a subprocess > > under the hood? > > It's different in that for those other commands, the users cannot get > the result they want without running that subprocess, so even if they're > not fully aware of it, they do have some vague idea it's inevitably > going to happen. > > In contrast, the compilation is not indispensable, (so much so that the > past it never happened). So native-compilation is "guilty" because it can be disabled? ;-) > > On my system, I don't see any warnings. > > That's presumably because you stick to the bundled packages (where we've > managed to keep a "no compilation warnings" state for the last few > years) or the few third party packages which are careful enough to > eliminate all warnings. > > The rise of ELPA has removed most of the cases where native compilation > will miscompile files (because ELPA forces the .el files to be compiled > in a "standard" way rather than using ad-hoc Makefile rules which the > native compiler cannot and does not try to reproduce), but compilation > warnings are still very common (the situation is improving, tho, and > arguably the warnings popping up out of the blue during lazy native > compilation may prove to be a good way to convince more package authors > to clean up their act). So this, too, is extremely temporary, and will disappear soon enough, at least in popular packages.