Invalid read syntax: "#<" with async-bytecomp #153
Comments
|
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
|
|
Could you check whether the If It relates to some emacs' change around Jan 22. |
|
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
|
|
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 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 |
|
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
|
|
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. |
|
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
|
Some byte-* variables are no more readable since introduction of symbols with positions in emacs-29, avoid loading by default such vars. The regexp passed to async-inject-variables is now stored in a var to allow modifying it.
|
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
|
|
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. |
|
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
|
|
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
|
|
Good - thanks. Then let's hope that this fixes all of the trouble... |
|
It works now. |
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:
And it seems not preventing the installation process but stops the emacs
to compile the el files to elc.
The text was updated successfully, but these errors were encountered: