From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Emanuel Berg via Users list for the GNU Emacs text editor Newsgroups: gmane.emacs.help Subject: Re: [External] : Re: Native compilation Date: Tue, 11 Jan 2022 14:18:55 +0100 Message-ID: <87czkys94w.fsf@zoho.eu> References: <875yr5up38.fsf@zoho.eu> <83k0flge7s.fsf@gnu.org> <87tuept0qc.fsf@zoho.eu> <83ee5tgcwv.fsf@gnu.org> <87ilv5sz9s.fsf@zoho.eu> <834k6ohp2o.fsf@gnu.org> <87ilutv5sb.fsf@zoho.eu> <83czl12xgd.fsf@gnu.org> <87tuebsp1b.fsf@zoho.eu> <831r1fa37q.fsf@gnu.org> Reply-To: Emanuel Berg Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="22972"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) To: help-gnu-emacs@gnu.org Cancel-Lock: sha1:NR/BiTOGmx8JO12upTWPkPevlwg= Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Tue Jan 11 15:38:45 2022 Return-path: Envelope-to: geh-help-gnu-emacs@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 1n7IIP-0005mC-68 for geh-help-gnu-emacs@m.gmane-mx.org; Tue, 11 Jan 2022 15:38:45 +0100 Original-Received: from localhost ([::1]:58924 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1n7IIN-0008AY-Uz for geh-help-gnu-emacs@m.gmane-mx.org; Tue, 11 Jan 2022 09:38:43 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:56052) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n7H3L-0001Ul-Nf for help-gnu-emacs@gnu.org; Tue, 11 Jan 2022 08:19:08 -0500 Original-Received: from ciao.gmane.io ([116.202.254.214]:41900) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n7H3J-0000U8-3L for help-gnu-emacs@gnu.org; Tue, 11 Jan 2022 08:19:07 -0500 Original-Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1n7H3H-0003qy-IU for help-gnu-emacs@gnu.org; Tue, 11 Jan 2022 14:19:03 +0100 X-Injected-Via-Gmane: http://gmane.org/ Mail-Followup-To: help-gnu-emacs@gnu.org Mail-Copies-To: never Received-SPF: pass client-ip=116.202.254.214; envelope-from=geh-help-gnu-emacs@m.gmane-mx.org; helo=ciao.gmane.io X-Spam_score_int: -16 X-Spam_score: -1.7 X-Spam_bar: - X-Spam_report: (-1.7 / 5.0 requ) BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "help-gnu-emacs" Xref: news.gmane.io gmane.emacs.help:135200 Archived-At: Eli Zaretskii wrote: >>>>>> Here is what it said during the native compile: >>>>>> >>>>>> Warning (comp): Cannot look-up eln file as no source file >>>>>> was found for /home/incal/.emacs.elc >>>>> >>>>> The former means your .emacs was not natively compiled >>>>> (which is generally a Good Thing). >>>> >>>> Thanks, you mean not to compile it natively or not compile >>>> it at all? >>> >>> Natively. >> >> Okay, it is interesting that you say so because didn't you >> use (?) to say that byte-compiling of the .emacs and >> supplemental files was disencouraged? > > I did, but how is that relevant to the issue at hand? Because I would like to know if this new (?) attitude to a new thing - is that actually a new attitude, or is it an old attitude ("don't byte-compile your own Elisp") applied to a new thing? (native byte-compilation) Or, if it indeed is a new attitude, what is the basis of that attitude? >> Why is it that while it makes sense to natively >> byte-compile the Elisp of GNU Emacs it doesn't make sense >> to natively byte-compile all other Elisp? > > Because the gains will be null and void. OK, so that's the basis, but then I again ask, why are there gains doing this to the GNU Emacs (vanilla Emacs) Elisp, but not to the local (HOME) Elisp? >> But OK, just byte-compiling the old what, that doesn't make >> it natively byte-compiled, right? > > No. Right, it doesn't look like it, either. So how do you natively byte-compile the file x.el? >> That happens automatically when Emacs is run, after being >> configured --with-native-compilation [1], and it only >> affects GNU Emacs Elisp, right? > > What is "that" in this case? Native byte-compilation of GNU Emacs (vanilla Emacs) Elisp. >> Or what about [M]ELPA Elisp, that natively byte-compiled >> as well? > > What do you mean by "MELPA Elisp"? The Elisp you get from ELPA and MELPA and possibly other places with the package manager. >> If so, even more so, then why not all Elisp? > > Why not what? _If_ there is an advantage, and I agree it is, both in theory and in practice, to natively byte-compile the GNU Emacs (vanilla Emacs) Elisp, then how can it be that "the gains will be null and void" to do the same with the local (HOME) Elisp? And, as asked, the [M]ELPA Elisp? Why/how can it makes sense to do this on some Elisp but not all? -- underground experts united https://dataswamp.org/~incal