Invalid read syntax: "#<" with async-bytecomp

[ShuguangSun]

Please refer to this info:
https://lists.gnu.org/archive/html/bug-gnu-emacs/2022-02/msg00003.html
And from the replies, Emacs has a new mechanism for compilation warning positions.
https://lists.gnu.org/archive/html/bug-gnu-emacs/2022-02/msg00031.html

When I try to install packages from the Package Menu or the command of
package-install since about two weeks ago, it reports the error:

error in process sentinel: async-when-done: Invalid read syntax: "#<"
error in process sentinel: Invalid read syntax: "#<"

And it seems not preventing the installation process but stops the emacs
to compile the el files to elc.

[thierryvolpiatto]

ShuguangSun ***@***.***> writes:

Please refer to this info: https://lists.gnu.org/archive/html/bug-gnu-emacs/2022-02/msg00003.html And from the replies, Emacs has a new mechanism for compilation warning positions. https://lists.gnu.org/archive/html/bug-gnu-emacs/2022-02/msg00031.html When I try to install packages from the Package Menu or the command of package-install since about two weeks ago, it reports the error: error in process sentinel: async-when-done: Invalid read syntax: "#<" error in process sentinel: Invalid read syntax: "#<"

Just installed a fresh emacs-29 with native-comp and couldn't reproduce when installing a package, may be I am missing something, could you provide a recipe? Thanks.

…

-- Thierry

[ShuguangSun]

Could you check whether the async-bytecomp-package-mode is t or nil? My Emacs version is

In GNU Emacs 29.0.50 (build 1, x86_64-w64-mingw32) of 2022-01-31 
Repository revision: 04f9c3b8df6afaf1e9de9f2a4478f63fd959bf09

If sync-bytecomp-package-mode is t, then the error occurs when I call package-install or package-menu-mark-upgrades+package-menu-execute in the package-menu-mode (list-package).

It relates to some emacs' change around Jan 22.

[thierryvolpiatto]

ShuguangSun ***@***.***> writes:

Could you check whether the async-bytecomp-package-mode is t or nil?

Of course it is enabled.

In GNU Emacs 29.0.50 (build 1, x86_64-w64-mingw32) of 2022-01-31 Repository revision: 04f9c3b8df6afaf1e9de9f2a4478f63fd959bf09

Be sure to use the very last commit from master, if it still not work, it is a platform specific bug.

…

-- Thierry

[michael-heerdegen]

I still see the problem. I think the symbols with positions change is the culprit, I see symbols with positions in the return value of async-inject-variables.

I asked for help in my bug report Bug#54079 regarding another issue related to this change (which had been fixed, but this one is still there):

https://lists.gnu.org/archive/html/bug-gnu-emacs/2022-03/msg00571.html

[thierryvolpiatto]

Michael Heerdegen ***@***.***> writes:

1. ( ) text/plain (*) text/html I still see the problem. I think the symbols with positions change is the culprit, I see symbols with positions in the return value of async-inject-variables.

Hmm, looks like some byte-* vars handle such symbols with positions, but I don't know much about this new feature so I don't really know what to be fixed, also this is Emacs-29 which is a moving target, let see what Emacs upstream will do with this feature.

I asked for help in my bug report Bug#54079 regarding another issue related to this change (which had been fixed, but this one is still there): https://lists.gnu.org/archive/html/bug-gnu-emacs/2022-03/msg00571.html

Ok, thanks to report.

…

— Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android. You are receiving this because you commented.*Message ID: ***@***.***>

-- Thierry

[michael-heerdegen]

I see symbols with positions in the binding of `byte-optimize--dynamic-vars' after I have byte compiled something (i.e., compiled normally, not asynchronously), and that seems to be the root cause of the issue. I have opened a separate Emacs bug#54433: 29.0.50; Invalid read syntax: "#<" with async-bytecomp. Let's see what comes out of this.

[thierryvolpiatto]

Michael Heerdegen ***@***.***> writes:

I see symbols with positions in the binding of `byte-optimize--dynamic-vars' after I have byte compiled something (i.e., compiled normally, not asynchronously), and that seems to be the root cause of the issue.

We could try to not load byte-* vars which are IMO not needed to byte-recompile-directory (don't know why I did it initially). E.g. (async-inject-variables "\\`\\(?:load-path\\'\\)")

I have opened a separate Emacs bug#54433: 29.0.50; Invalid read syntax: "#<" with async-bytecomp. Let's see what comes out of this.

Great thanks.

…

— Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android. You are receiving this because you commented.*Message ID: ***@***.***>

-- Thierry

[thierryvolpiatto]

I made the regexp passed to async-inject-variables configurable and its default is now "\\`load-path\\'" only, let me know if it fixes your problem. Of course it would be better that upstream fixes readability of symbols... Thanks.

…

-- Thierry

[michael-heerdegen]

Yes, seems to help indeed, thanks. I hope not transferring those variables doesn't cause other issues.

After having a look at (info "(elisp) Symbols with Position"), you should be able to print the variable bindings using print-symbols-bare -> t to get rid of the symbol positions in printed expressions. You want to bind that in `async--insert-sexp' I think.

[thierryvolpiatto]

Michael Heerdegen ***@***.***> writes:

1. ( ) text/plain (*) text/html Yes, seems to help indeed, thanks. I hope not transferring those variables doesn't cause other issues. After having a look at (info "(elisp) Symbols with Position"), you should be able to print the variable bindings using print-symbols-bare -> t to get rid of the symbol positions in printed expressions. You want to bind that in `async--insert-sexp' I think.

Great I was wondering if there was some documentations about this and also such a var to disable the feature, I will install emacs-29 and look at this. Thanks.

…

-- Thierry

[thierryvolpiatto]

Michael Heerdegen ***@***.***> writes:

Yes, seems to help indeed, thanks. I hope not transferring those variables doesn't cause other issues. After having a look at (info "(elisp) Symbols with Position"), you should be able to print the variable bindings using print-symbols-bare -> t to get rid of the symbol positions in printed expressions. You want to bind that in `async--insert-sexp' I think.

Done, thanks.

…

-- Thierry

[michael-heerdegen]

Good - thanks. Then let's hope that this fixes all of the trouble...

[ShuguangSun]

It works now.