-
Notifications
You must be signed in to change notification settings - Fork 68
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
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: