RE: [External] : Re: Native compilation

RE: [External] : Re: Native compilation

[Drew Adams]

[-- Attachment #1: Type: text/plain, Size: 543 bytes --]

> Uhm, native code, what's that? Compile for the architecture
> you're on? But isn't that the natural order of things?
> 
> Except for special cases when you cross-compile for, say
> a unit with less CPU power, to run but not compile?
> 
> And, is that the whole field?
> 
> No third way of doing it?

The result of Emacs byte-compilation is not
architecture-dependent.  It runs on any architecture
that Emacs supports.  Emacs Lisp has always had the
possibility of byte-compilation.  Native compilation
is new, for Emacs Lisp.

[-- Attachment #2: winmail.dat --]
[-- Type: application/ms-tnef, Size: 13084 bytes --]

Re: [External] : Re: Native compilation

[Emanuel Berg via Users list for the GNU Emacs text editor]

Drew Adams wrote:

>> Uhm, native code, what's that? Compile for the architecture
>> you're on? But isn't that the natural order of things?
>> 
>> Except for special cases when you cross-compile for, say
>> a unit with less CPU power, to run but not compile?
>> 
>> And, is that the whole field?
>> 
>> No third way of doing it?
>
> The result of Emacs byte-compilation is not
> architecture-dependent. It runs on any architecture that
> Emacs supports. Emacs Lisp has always had the possibility of
> byte-compilation. Native compilation is new, for Emacs Lisp.

We are talking Elisp and not C, OK, wonderful, let's check the
man page for emacs(1) right away ...

-- 
underground experts united
https://dataswamp.org/~incal

Re: [External] : Re: Native compilation

[Emanuel Berg via Users list for the GNU Emacs text editor]

Emanuel Berg via Users list for the GNU Emacs text editor wrote:

> We are talking Elisp and not C, OK, wonderful, let's check
> the man page for emacs(1) right away ...

It isn't mentioned there but do

  configure --with-native-compilation --with-x-toolkit=no



-- 
underground experts united
https://dataswamp.org/~incal

Re: [External] : Re: Native compilation

[Emanuel Berg via Users list for the GNU Emacs text editor]

Drew Adams wrote:

> The result of Emacs byte-compilation is not
> architecture-dependent. It runs on any architecture that
> Emacs supports. Emacs Lisp has always had the possibility of
> byte-compilation. Native compilation is new, for Emacs Lisp.

This stuff is so fast!

Speed me up!

https://www.youtube.com/watch?v=dCuCpVPkWDY

-- 
underground experts united
https://dataswamp.org/~incal

Re: [External] : Re: Native compilation

[Emanuel Berg via Users list for the GNU Emacs text editor]

Drew Adams wrote:

> The result of Emacs byte-compilation is not
> architecture-dependent. It runs on any architecture that
> Emacs supports. Emacs Lisp has always had the possibility of
> byte-compilation. Native compilation is new, for Emacs Lisp.

FYI when I configure like this

  configure --with-x-toolkit=no --with-native-compilation # [1]

it still just says when I do `report-emacs-bug' it still just
says

  Configured using:
    'configure --with-x-toolkit=no'

[1] https://dataswamp.org/~incal/conf/.zsh/install-emacs

-- 
underground experts united
https://dataswamp.org/~incal

Re: [External] : Re: Native compilation

[Emanuel Berg via Users list for the GNU Emacs text editor]

> FYI when I configure like this
>
>   configure --with-x-toolkit=no --with-native-compilation # [1]
>
> it still just says when I do `report-emacs-bug' it still just
> says
>
>   Configured using:
>     'configure --with-x-toolkit=no'

It is line 407 in

  /usr/local/share/emacs/29.0.50/lisp/mail/emacsbug.el.gz

and uses `system-configuration-options' which I indeed have as
only

  "--with-x-toolkit=no"

-- 
underground experts united
https://dataswamp.org/~incal

Re: [External] : Re: Native compilation

[Eli Zaretskii]

> Date: Fri, 31 Dec 2021 09:59:39 +0100
> From:  Emanuel Berg via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org>
> 
> FYI when I configure like this
> 
>   configure --with-x-toolkit=no --with-native-compilation # [1]
> 
> it still just says when I do `report-emacs-bug' it still just
> says
> 
>   Configured using:
>     'configure --with-x-toolkit=no'

Not here, it doesn't.

Are you sure your Emacs is actually compiled with native-compilation
turned on?  Did the configure-time test for libgccjit succeed or did
it fail?

Re: [External] : Re: Native compilation

[Emanuel Berg via Users list for the GNU Emacs text editor]

Eli Zaretskii wrote:

> Not here, it doesn't.
>
> Are you sure your Emacs is actually compiled with
> native-compilation turned on? Did the configure-time test
> for libgccjit succeed or did it fail?

Don't know, what test is that?

-- 
underground experts united
https://dataswamp.org/~incal

Re: [External] : Re: Native compilation

[Eli Zaretskii]

> Date: Fri, 31 Dec 2021 13:31:07 +0100
> From:  Emanuel Berg via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org>
> 
> Eli Zaretskii wrote:
> 
> > Not here, it doesn't.
> >
> > Are you sure your Emacs is actually compiled with
> > native-compilation turned on? Did the configure-time test
> > for libgccjit succeed or did it fail?
> 
> Don't know, what test is that?

This one:

  configure:16554: checking for gcc_jit_context_acquire in -lgccjit
  configure:16588: result: yes
  configure:16607: checking for libgccjit.h
  configure:16607: result: yes

Look in your config.log for what happened in your case.

Re: [External] : Re: Native compilation

[Emanuel Berg via Users list for the GNU Emacs text editor]

Eli Zaretskii wrote:

>> Don't know, what test is that?
>
> This one:
>
>   configure:16554: checking for gcc_jit_context_acquire in -lgccjit
>   configure:16588: result: yes
>   configure:16607: checking for libgccjit.h
>   configure:16607: result: yes
>
> Look in your config.log for what happened in your case.

No, it must be it since now when I installed it, after that
Emacs starts up two processes that are still compiling,
recompiling the native code I take it!

Since the byte compiler will be recompiled this way, maybe it
will compile for native code now automatically?

-- 
underground experts united
https://dataswamp.org/~incal

Re: [External] : Re: Native compilation

[Emanuel Berg via Users list for the GNU Emacs text editor]

Now `system-configuration-options' says "--with-x-toolkit=no
--with-native-compilation" as well. That settles it I guess.

Only what does this mean?

  Warning (comp): Cannot look-up eln file as no source file
  was found for /home/incal/.emacs.elc

And do I get native code with the same way using the
byte-compiler?

As in this?

# this file:
#   https://dataswamp.org/~incal/emacs-init/Makefile

emacs            = /usr/local/bin/emacs

init-file        = ${HOME}/.emacs
init-file-elc    = $(init-file).elc

emacs-dir        = ${HOME}/.emacs.d

ema-path         = $(emacs-dir)/emacs-init

ema-bibtex       = $(ema-path)/bibtex
ema-erc          = $(ema-path)/erc
ema-gnus         = $(ema-path)/gnus
ema-ide          = $(ema-path)/ide
ema-w3m          = $(ema-path)/w3m

ema              = \"$(ema-erc)\"    \
                   \"$(ema-bibtex)\" \
                   \"$(ema-gnus)\"   \
                   \"$(ema-ide)\"    \
                   \"$(ema-path)\"   \
                   \"$(ema-w3m)\"

elpa-path        = $(emacs-dir)/elpa

crontab-mode     = $(elpa-path)/crontab-mode-20210715.133
gnuplot-mode     = $(elpa-path)/gnuplot-mode-20171013.1616
google-translate = $(elpa-path)/google-translate-20210406.1138
lua-mode         = $(elpa-path)/lua-mode-20210809.1320
markdown-mode    = $(elpa-path)/markdown-mode-20211022.55
seq              = $(elpa-path)/seq-2.23
sml-mode         = $(elpa-path)/sml-mode-6.10
w3m              = $(elpa-path)/w3m-20211122.335

elpa             = \"$(crontab-mode)\"     \
                   \"$(gnuplot-mode)\"     \
                   \"$(google-translate)\" \
                   \"$(lua-mode)\"         \
                   \"$(markdown-mode)\"    \
                   \"$(seq)\"              \
                   \"$(sml-mode)\"         \
                   \"$(w3m)\"              \

packs            = $(elpa) $(ema)

el-files         = $(shell zsh -c "ls -1 **/*.el")
elc-files        = $(el-files:.el=.elc)

sed-filter       = 2>&1 | sed '/^\(Loading\|Wrote\)/d'

byte-compile     = $(emacs)                                  \
	--batch                                                   \
	--eval "(setq load-path (append load-path '($(packs)))))" \
	-f batch-byte-compile

all: $(elc-files) $(init-file-elc)

$(init-file-elc): $(init-file)
	$(byte-compile) $< $(sed-filter)

%.elc: %.el
	$(byte-compile) $< $(sed-filter)

clean:
	$(shell zsh -c "rm -rf **/*.elc(N)")
	rm -f $(init-file-elc)

again:
	${MAKE} clean
	${MAKE} all

test:
	echo $(byte-compile)

-- 
underground experts united
https://dataswamp.org/~incal

Re: [External] : Re: Native compilation

[Eli Zaretskii]

> Date: Fri, 31 Dec 2021 14:00:54 +0100
> From:  Emanuel Berg via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org>
> 
> No, it must be it since now when I installed it, after that
> Emacs starts up two processes that are still compiling,
> recompiling the native code I take it!

Yes, sounds like it.

> Since the byte compiler will be recompiled this way, maybe it
> will compile for native code now automatically?

No, automatic native compilation is triggered by _loading_ a .elc
file, not by compiling it.

Re: [External] : Re: Native compilation

[Emanuel Berg via Users list for the GNU Emacs text editor]

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

  Warning (comp): w3m.el:93:1: Warning: Variable ‘w3m-fb-mode’
  left uninitialized Disable showing

-- 
underground experts united
https://dataswamp.org/~incal

Re: [External] : Re: Native compilation

[Eli Zaretskii]

> Date: Fri, 31 Dec 2021 14:02:39 +0100
> From:  Emanuel Berg via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org>
> 
> 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
> 
>   Warning (comp): w3m.el:93:1: Warning: Variable ‘w3m-fb-mode’
>   left uninitialized Disable showing

The former means your .emacs was not natively compiled (which is
generally a Good Thing).  The latter means you need to look for a
missing 'require'.

Re: [External] : Re: Native compilation

[Emanuel Berg via Users list for the GNU Emacs text editor]

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?

But the strange thing is it _is_ compiled, there is an
.emacs.elc which according to file(1) is "Emacs/XEmacs v28
byte-compiled Lisp data", however the Emacs that compiled [1]
it is actually

  GNU Emacs 29.0.50 (build 1, x86_64-pc-linux-gnu, cairo
  version 1.16.0) of 2021-12-31

So I wonder if there is some special way to compile it
natively? I mean for all the extra Elisp one might have
in HOME?

Currently, .elc files are `load'ed from .emacs [1] if that's
what happens (it seems so since that software in one way or
the other is in effect).

>> Warning (comp): w3m.el:93:1: Warning: Variable
>> ‘w3m-fb-mode’ left uninitialized Disable showing
>
> The latter means you need to look for a missing 'require'.

It is in the MELPA's Emacs-w3m, I think, version 1.4.632.

[1] https://dataswamp.org/~incal/emacs-init/Makefile

[2] https://dataswamp.org/~incal/conf/.emacs

-- 
underground experts united
https://dataswamp.org/~incal

Re: [External] : Re: Native compilation

[Eli Zaretskii]

> Date: Sun, 09 Jan 2022 06:26:12 +0100
> Cc: emacs-w3m@namazu.org
> From:  Emanuel Berg via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org>
> 
> 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.

> But the strange thing is it _is_ compiled, there is an
> .emacs.elc which according to file(1) is "Emacs/XEmacs v28
> byte-compiled Lisp data", however the Emacs that compiled [1]
> it is actually

The native compilation didn't happen because Emacs didn't find the
source file for the .elc file.  I'm saying that you shouldn't worry
about that: native compilation of init files can only cause trouble,
and will never provide any tangible performance boost.  So just
disregard that warning.

> So I wonder if there is some special way to compile it
> natively?

Maybe.  But why bother?

> I mean for all the extra Elisp one might have in HOME?

I don't think it's relevant.

> >> Warning (comp): w3m.el:93:1: Warning: Variable
> >> ‘w3m-fb-mode’ left uninitialized Disable showing
> >
> > The latter means you need to look for a missing 'require'.
> 
> It is in the MELPA's Emacs-w3m, I think, version 1.4.632.

Report a bug to the developers.

Re: [External] : Re: Native compilation

[Emanuel Berg via Users list for the GNU Emacs text editor]

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?

Well, I meet you half the way since one of the big advantages
with byte-compilation is that it gives you an easy way to
improve the quality of the code, and with native byte-compile,
you don't get that advantage since you already got it with
ordinary/universal byte-compile ...

>> But the strange thing is it _is_ compiled, there is an
>> .emacs.elc which according to file(1) is "Emacs/XEmacs v28
>> byte-compiled Lisp data", however the Emacs that compiled
>> [1] it is actually
>
> The native compilation didn't happen because Emacs didn't
> find the source file for the .elc file. I'm saying that you
> shouldn't worry about that: native compilation of init files
> can only cause trouble, and will never provide any tangible
> performance boost. So just disregard that warning.
>
>> So I wonder if there is some special way to compile
>> it natively?
>
> Maybe.  But why bother?

Well, we we are into technology unless you didn't notice.

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?

But OK, just byte-compiling the old what, that doesn't make it
natively byte-compiled, right?

That happens automatically when Emacs is run, after being
configured --with-native-compilation [1], and it only affects
GNU Emacs Elisp, right?

Or what about [M]ELPA Elisp, that natively byte-compiled
as well?

If so, even more so, then why not all Elisp?

>> It is in the MELPA's Emacs-w3m, I think, version 1.4.632.
>
> Report a bug to the developers.

I CC the previous post to gmane.emacs.w3m ... there is no
common interface to submit bugs in random Elisp software
I guess? :)

[1] https://dataswamp.org/~incal/conf/.zsh/install-emacs

-- 
underground experts united
https://dataswamp.org/~incal

Re: [External] : Re: Native compilation

[Eli Zaretskii]

> Date: Mon, 10 Jan 2022 14:23:12 +0100
> From:  Emanuel Berg via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org>
> 
> 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?

> 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.

> But OK, just byte-compiling the old what, that doesn't make it
> natively byte-compiled, right?

No.

> 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?

> Or what about [M]ELPA Elisp, that natively byte-compiled
> as well?

What do you mean by "MELPA Elisp"?

> If so, even more so, then why not all Elisp?

Why not what?

Re: [External] : Re: Native compilation

[Emanuel Berg via Users list for the GNU Emacs text editor]

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

Re: [External] : Re: Native compilation

[Eli Zaretskii]

> Date: Tue, 11 Jan 2022 14:18:55 +0100
> From:  Emanuel Berg via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org>
> 
> Eli Zaretskii wrote:
> 
> >>>> 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)

It is both.  I see little sense in compiling init files (except as a
method of finding bugs in them, which means you compile them and then
throw away the .elc files).  I see even less sense in natively
compiling them: you get all the "issues" caused by natively-compiled
ELisp, without any benefits.  So it's a net loss.  It follows that our
advice to users should be not to do something that results in net loss
for them.

> Or, if it indeed is a new attitude, what is the basis of
> that attitude? 

Natively-compiling Lisp files needs to make sure they are
self-contained, i.e. they don't depend on other Lisp files that are
not explicitly 'load'ed or 'require'd in them.  Otherwise you will
have warnings and errors during JIT native-compilation.

Natively-compiling Lisp files also means you'll need to have the
original Lisp files around, or else Emacs will refuse to load the .eln
file.  If you compress the source file, you need to have Emacs built
with decompression support (zlib), otherwise Emacs will refuse to load
the .eln file, claiming that the source isn't available.

Replacing the .eln file that is loaded into a running Emacs session is
"tricky" at best, because the *.eln files are actually shared
libraries in disguise, and your typical OS doesn't like it very much
when you delete a shared library that's in use.

Etc. etc. -- using the *.eln files comes at a price, so paying that
price when you get nothing in terms of performance is un-economical.
So my advice is not to do that.

> > 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?

Because most of the code in a typical init file doesn't perform any
significant processing that can be sped up by natively-compiling it.

> Right, it doesn't look like it, either. So how do you natively
> byte-compile the file x.el?

By using one or more of special commands designed for that.

> >> 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.

It happens automatically when Emacs loads a .elc file whose .el file
can be found in the usual places, yes.

> >> 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.

Same thing.  The source of the Lisp code doesn't matter (of course).

> >> 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?

Most of the Lisp code you load does perform some processing that can
be sped up.  Of course, there are exceptions, but on the average
compiling them produces tangible gains.  Not so with init files.

Re: [External] : Re: Native compilation

[Emanuel Berg via Users list for the GNU Emacs text editor]

Eli Zaretskii wrote:

> It is both. I see little sense in compiling init files
> (except as a method of finding bugs in them, which means you
> compile them and then throw away the .elc files). I see even
> less sense in natively compiling them: you get all the
> "issues" caused by natively-compiled ELisp, without any
> benefits. So it's a net loss. It follows that our advice to
> users should be not to do something that results in net loss
> for them.

Well ... okay, a general approach of course, but nonetheless.

>> Or, if it indeed is a new attitude, what is the basis of
>> that attitude? 
>
> Natively-compiling Lisp files needs to make sure they are
> self-contained, i.e. they don't depend on other Lisp files
> that are not explicitly 'load'ed or 'require'd in them.
> Otherwise you will have warnings and errors during JIT
> native-compilation.

Yes, but that's completely natural ... good, even?

> Natively-compiling Lisp files also means you'll need to have
> the original Lisp files around, or else Emacs will refuse to
> load the .eln file. If you compress the source file, you
> need to have Emacs built with decompression support (zlib),
> otherwise Emacs will refuse to load the .eln file, claiming
> that the source isn't available.

Okay, why?

Anyway I always have the .elc next to the .el anyway ...

> Replacing the .eln file that is loaded into a running Emacs
> session is "tricky" at best, because the *.eln files are
> actually shared libraries in disguise, and your typical OS
> doesn't like it very much when you delete a shared library
> that's in use.

Well, we don't intend to do that a lot ... if we do that will
be interesting to know and we'll cross that bridge when/if we
reach it ...

>> 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?
>
> Because most of the code in a typical init file doesn't
> perform any significant processing that can be sped up by
> natively-compiling it.

Yeah ... I have 144 Elisp files [1] so maybe it isn't
a typical setup. Anyway it isn't (for me) really about making
anything faster anyway, it is about natively byte-compiling
the Elisp ...

>> Right, it doesn't look like it, either. So how do you
>> natively byte-compile the file x.el?
>
> By using one or more of special commands designed for that.

Which are?

Or where is this documented perhaps better ...

>>>> 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.
>
> It happens automatically when Emacs loads a .elc file whose
> .el file can be found in the usual places, yes.

What places are these?

I have the .elc files and they are in the same directory as
the .el files - okay, so maybe they are indeed
natively byte-compiled already?

.eln files do exist in ~/.emacs.d/eln-cache/29.0.50-9e08bfb0
including my files, e.g. time-incal-760bfd05-7cbfad50.eln -
okay, so maybe that's why I got the warning/error for just one
file, .emacs - because .emacs is named .emacs and not
emacs.el?

Everything else taken cared of already?

[1] https://dataswamp.org/~incal/emacs-init/

-- 
underground experts united
https://dataswamp.org/~incal

Re: [External] : Re: Native compilation

[Emanuel Berg via Users list for the GNU Emacs text editor]

> I have the .elc files and they are in the same directory as
> the .el files - okay, so maybe they are indeed
> natively byte-compiled already?
>
> .eln files do exist in ~/.emacs.d/eln-cache/29.0.50-9e08bfb0
> including my files, e.g. time-incal-760bfd05-7cbfad50.eln -
> okay, so maybe that's why I got the warning/error for just one
> file, .emacs - because .emacs is named .emacs and not
> emacs.el?

$ ln -s .emacs .emacs.el

> Everything else taken cared of already?

Now everything else is as well :)

-- 
underground experts united
https://dataswamp.org/~incal

Re: [External] : Re: Native compilation

[Eli Zaretskii]

> Date: Wed, 12 Jan 2022 23:49:30 +0100
> From:  Emanuel Berg via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org>
> 
> $ ln -s .emacs .emacs.el
> 
> > Everything else taken cared of already?
> 
> Now everything else is as well :)

Fine, just don't come back crying, complaining that this causes all
kinds of annoying warnings and errors.

WE RECOMMEND NOT TO NATIVE-COMPILE YOUR INIT FILES!!!

Re: [External] : Re: Native compilation

[Emanuel Berg via Users list for the GNU Emacs text editor]

Eli Zaretskii wrote:

> Fine, just don't come back crying, complaining that this
> causes all kinds of annoying warnings and errors.

They are not the same as the ones you see and prune by
byte-compiling?

> WE RECOMMEND NOT TO NATIVE-COMPILE YOUR INIT FILES!!!

You do recommend it to other Elisp? If you do, what you says
is illogical.

If you don't recommend it to any Elisp, why is it included
at all?

Ah, right, maybe not everyone thinks like you? Forgot about
that but indeed that'd be a horrible world.

-- 
underground experts united
https://dataswamp.org/~incal

Re: [External] : Re: Native compilation

[Emanuel Berg via Users list for the GNU Emacs text editor]

Eli Zaretskii wrote:

> Fine, just don't come back crying, complaining that this
> causes all kinds of annoying warnings and errors.

Not fine!

It should look for .emacs automatically because it is the
default name of the Emacs main init file, no one should need
to make a symlink to have Emacs find .emacs just because there
isn't a .emacs.el (???), when there is a .emacs.elc and Emacs
has been configured with --with-native-compilation.

That is so lame, it is like you are saying people shouldn't
native-compile Elisp or something ...

-- 
underground experts united
https://dataswamp.org/~incal

Re: [External] : Re: Native compilation

[Eli Zaretskii]

> Date: Wed, 12 Jan 2022 23:38:36 +0100
> From:  Emanuel Berg via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org>
> 
> > Natively-compiling Lisp files needs to make sure they are
> > self-contained, i.e. they don't depend on other Lisp files
> > that are not explicitly 'load'ed or 'require'd in them.
> > Otherwise you will have warnings and errors during JIT
> > native-compilation.
> 
> Yes, but that's completely natural ... good, even?

Quite a few people are annoyed by the many warnings they get in this
case.

> > Natively-compiling Lisp files also means you'll need to have
> > the original Lisp files around, or else Emacs will refuse to
> > load the .eln file. If you compress the source file, you
> > need to have Emacs built with decompression support (zlib),
> > otherwise Emacs will refuse to load the .eln file, claiming
> > that the source isn't available.
> 
> Okay, why?

Because Emacs needs to be sure the .eln file corresponds to the
.el/.elc, otherwise the session might crash.

> >> Right, it doesn't look like it, either. So how do you
> >> natively byte-compile the file x.el?
> >
> > By using one or more of special commands designed for that.
> 
> Which are?
> 
> Or where is this documented perhaps better ...

In the manual, of course.  And also this should help:

   M-x apropos RET native.*compile RET

> >> Native byte-compilation of GNU Emacs (vanilla Emacs) Elisp.
> >
> > It happens automatically when Emacs loads a .elc file whose
> > .el file can be found in the usual places, yes.
> 
> What places are these?

Near the .el file and on load-path, of course.

> I have the .elc files and they are in the same directory as
> the .el files - okay, so maybe they are indeed
> natively byte-compiled already?

Probably.  Look in the eln-cache directory.

> .eln files do exist in ~/.emacs.d/eln-cache/29.0.50-9e08bfb0
> including my files, e.g. time-incal-760bfd05-7cbfad50.eln -
> okay, so maybe that's why I got the warning/error for just one
> file, .emacs - because .emacs is named .emacs and not
> emacs.el?

If you have .emacs.elc somewhere, and it said it couldn't find the
source of it, then that's the reason.  If you don't have .emacs.elc,
it will not try to natively-compile .emacs.  The eln-cache has nothing
to do with that, because the sources aren't supposed to be there and
aren't being looked up there.

Re: [External] : Re: Native compilation

[Emanuel Berg via Users list for the GNU Emacs text editor]

Eli Zaretskii wrote:

>> Yes, but that's completely natural ... good, even?
>
> Quite a few people are annoyed by the many warnings they get
> in this case.

I didn't get a single one except the one from the MELPA
Emacs-w3m and the .emacs case described already. I guess my
144 files are pretty good ...

>>> Natively-compiling Lisp files also means you'll need to
>>> have the original Lisp files around, or else Emacs will
>>> refuse to load the .eln file. If you compress the source
>>> file, you need to have Emacs built with decompression
>>> support (zlib), otherwise Emacs will refuse to load the
>>> .eln file, claiming that the source isn't available.
>> 
>> Okay, why?
>
> Because Emacs needs to be sure the .eln file corresponds to
> the .el/.elc, otherwise the session might crash.

OK, well not a problem anyway since it is just source ...
bunch of chars LOL

>> .eln files do exist in
>> ~/.emacs.d/eln-cache/29.0.50-9e08bfb0 including my files,
>> e.g. time-incal-760bfd05-7cbfad50.eln - okay, so maybe
>> that's why I got the warning/error for just one file,
>> .emacs - because .emacs is named .emacs and not emacs.el?
>
> If you have .emacs.elc somewhere, and it said it couldn't find the
> source of it, then that's the reason.

It is ... with .emacs.el symlinked I don't get a warning.

> If you don't have .emacs.elc

Grep the backlog for the answer to this question ...

-- 
underground experts united
https://dataswamp.org/~incal