Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Do not compress jka-compr.el #78

Open
khaoos-abominable opened this issue Sep 22, 2024 · 1 comment
Open

Do not compress jka-compr.el #78

khaoos-abominable opened this issue Sep 22, 2024 · 1 comment

Comments

@khaoos-abominable
Copy link

khaoos-abominable commented Sep 22, 2024

The library jka-compr is used to load compressed libraries (.el.gz). When it's itself compressed one can encounter recursive load issue. For example:

 Warning (initialization): An error occurred while loading ~/.emacs.d/init.el’:

error: Recursive load, /app/share/emacs/29.4/lisp/jka-compr.el.gz, /app/share/emacs/29.4/lisp/jka-compr.el.gz, /app/share/emacs/29.4/lisp/jka-compr.el.gz, /app/share/emacs/29.4/lisp/jka-compr.el.gz, /app/share/emacs/29.4/lisp/jka-compr.el.gz, /app/share/emacs/29.4/lisp/info.el.gz, /home/khaoos/.emacs.d/init.el

It's happening on a fresh spacemacs installation (dev branch) due to the lines in `~/.emacs.d/layers/+spacemacs/spacemacs-defaults/config.el

;; Don't load outdated compiled files.
(setq load-prefer-newer t)

As soon as I comment them out, issue dissapears. It seems that emacs tries to recompile the library jka-compr before its load when load-prefer-newer is set. As the uncompiled version of the library is a bit fresher (see Modify below):

[📦 org.gnu.emacs lisp]$ pwd
/app/share/emacs/29.4/lisp
📦 org.gnu.emacs lisp]$ stat *jka-compr*
  File: jka-compr.elc
  Size: 12099     	Blocks: 24         IO Block: 4096   regular file
Device: 259,2	Inode: 674859      Links: 2
Access: (0644/-rw-r--r--)  Uid: (65534/nfsnobody)   Gid: (65534/nfsnobody)
Access: 2024-09-22 12:51:01.736093903 +0600
Modify: 2024-09-22 12:51:01.736093903 +0600
Change: 2024-09-22 12:51:22.793010855 +0600
 Birth: 2024-09-22 12:51:01.736093903 +0600
  File: jka-compr.el.gz
  Size: 7293      	Blocks: 16         IO Block: 4096   regular file
Device: 259,2	Inode: 676551      Links: 2
Access: (0644/-rw-r--r--)  Uid: (65534/nfsnobody)   Gid: (65534/nfsnobody)
Access: 2024-09-22 12:51:01.920093179 +0600
Modify: 2024-09-22 12:51:01.921093175 +0600
Change: 2024-09-22 12:51:22.798010836 +0600
 Birth: 2024-09-22 12:51:01.920093179 +0600

So I believe if you touch jka-compr.elc the problem will go away. Or a better option I think is just to not compress jka-compr.el at all. But you decide. I haven not tried any of them as the application is immutable and I am a newbie to flatpack to hack it around. As for now I've left setting load-prefer-newer above commented out.

@khaoos-abominable
Copy link
Author

Now I think that the most optimal solution will be to touch all *.elc files after their compilation.

Firstly, it will be more friendly to the load-prefer-newer setting. If all elc files are appear newer then their el.gz counterparts, they will be used for loading. And that is good as it's faster. In the opposite case el.gz will be constantly (once every session) being uncompressed and then loaded. And the last behavior I witnessed many times having older version of emacs flatpak: every new action in emacs` fresh session was accompanied by uncompressing and loading dozens of libraries. Which was kind of sluggish.

Secondly, there is a package named auto-compile that helps recompiling outdated libraries on their load and save. I haven't try yet, but I think it will fail when it sees a source el file which is fresher then it's compiled elc counterpart and tries to recompile the latter. Because the file system is read only.

So not compressing jka-compr.el as stated in the subject can be safely ignored in favor of having elc files newer then corresponding el.gz files.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant