--- Begin Message ---
|
Subject: |
29.0.50; Invalid read syntax: "#<" with async-bytecomp |
|
Date: |
Thu, 17 Mar 2022 03:55:27 +0100 |
|
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) |
Hello,
when updating packages with M-x package-list-packages, and using
async-bytecomp.el to compile, some users get an error like this one:
error in process sentinel: async-when-done: Invalid read syntax: "#<"
error in process sentinel: Invalid read syntax: "#<"
This seems to be related to the recent addition of symbols with
positions.
async uses `async-inject-variables' to collect variable bindings of
interest and deliver them to the other Emacs instance. The return value
contains symbols with positions in some scenarios.
The root of the trouble seems to be the value of
`byte-optimize--dynamic-vars'. As soon as I byte compile any file, I
see lots of symbols with positions in `byte-optimize--dynamic-vars'.
Is that expected? What has to be done?
TIA,
Michael.
In GNU Emacs 29.0.50 (build 55, x86_64-pc-linux-gnu, GTK+ Version 3.24.24,
cairo version 1.16.0)
of 2022-03-17 built on drachen
Repository revision: 97e687006498490cca1e6dabc1ea7e692271c5ed
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12011000
System Description: Debian GNU/Linux 11 (bullseye)
Configured using:
'configure --with-native-compilation --with-xwidgets'
--- End Message ---
--- Begin Message ---
|
Subject: |
Re: bug#54433: 29.0.50; Invalid read syntax: "#<" with async-bytecomp |
|
Date: |
Thu, 24 Mar 2022 02:38:14 +0100 |
|
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) |
Thierry Volpiatto <thievol@posteo.net> writes:
> > I think that all the byte-* variables are connected with byte
> > compilation. But I also think that they are (?nearly?) all internal
> > variables, so it shouldn't be needed to copy them to an aynchronous
> > thread (?or process?).
>
> Thanks to confirm this.
I can confirm that the problem has been fixed well in the "async"
package, and we have found that everything in Emacs is working as
expected. So I'm closing this report. Thanks to everybody involved!
Michael.
--- End Message ---