From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Michael Heerdegen Newsgroups: gmane.emacs.devel Subject: Re: Enabling native compilation by default when libgccjit is present Date: Thu, 09 Dec 2021 01:44:30 +0100 Message-ID: <87wnkeobdd.fsf@web.de> References: <87czmdqpv9.fsf@web.de> <83h7bo7rvz.fsf@gnu.org> <87bl1tjage.fsf@web.de> <83fsr4zfl2.fsf@gnu.org> <87y24vvnnk.fsf@web.de> <8335n3xnsa.fsf@gnu.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="13638"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) To: emacs-devel@gnu.org Cancel-Lock: sha1:BFdByi+IizvN9HaVPumEQHL+R4w= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Dec 09 01:46:58 2021 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 1mv7aM-0003KD-9g for ged-emacs-devel@m.gmane-mx.org; Thu, 09 Dec 2021 01:46:58 +0100 Original-Received: from localhost ([::1]:58972 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mv7aK-0003Ij-Hu for ged-emacs-devel@m.gmane-mx.org; Wed, 08 Dec 2021 19:46:56 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:41592) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mv7YE-0002EK-9P for emacs-devel@gnu.org; Wed, 08 Dec 2021 19:44:46 -0500 Original-Received: from ciao.gmane.io ([116.202.254.214]:32892) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mv7YA-0002oZ-2Z for emacs-devel@gnu.org; Wed, 08 Dec 2021 19:44:46 -0500 Original-Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1mv7Y8-0000Hl-41 for emacs-devel@gnu.org; Thu, 09 Dec 2021 01:44:40 +0100 X-Injected-Via-Gmane: http://gmane.org/ Received-SPF: pass client-ip=116.202.254.214; envelope-from=ged-emacs-devel@m.gmane-mx.org; helo=ciao.gmane.io X-Spam_score_int: -13 X-Spam_score: -1.4 X-Spam_bar: - X-Spam_report: (-1.4 / 5.0 requ) BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no 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:281414 Archived-At: Eli Zaretskii writes: > The JIT compilation doesn't just happen randomly because Emacs decides > it's an opportune moment for it. It happens because the session loads > some Lisp file. A live Emacs session used for real-life work will > always load Lisp files, as needed. Loading a Lisp file (via 'load' or > 'require' or any similar API) could potentially pop up warnings and > errors without any relation to native compilation, because something > went wrong while loading. I presume you won't argue for shutting up > such messages caused by some problems in the load process or in the > interaction of the loaded code with what you already have in the > session, would you? Then how are the warnings triggered by JIT > compilation different, in principle? They are the same phenomenon: > Emacs loaded some Lisp package because some command needed it, and > loading it caused warnings due to issues with the loaded code. Lars found already better words for this. The main problem is that it happens while loading. Some day when native compilation is normal like byte compilation, the problem might not be as bad. But currently most packages available have not been optimized for native compilation. A lot will never be fixed because they are abandoned. So a lot of warnings will always be there, but the packages still do work, and the user can do nothing about the warnings. And: package maintainers often don't care about warnings at all, we see that today with byte compilation. Summary: those warnings are good for developers but not helpful otherwise. And they annoy most people when they appear while loading a package. Idea: could we have a setting saying "show warnings from native compilation only when installing something or byte compiling, but not when recompiling (natively) because the Emacs binary has changed"? That would still show all warnings once, but would not get in the way when trying to work. That could be default. Developers could still say "show those warnings always". Michael.