On Wed, Jun 25, 2025 at 6:01 PM Lynn Winebarger wrote: > > In the recursive sense, not the "safe for concurrency" sense. > > I want to use readevalloop to process command-line arguments, and my > initial attempts failed to handle '"(load "loadup.el") (princ > "Done")'. So I took a stab at making all the entry points synchronize > with an explicit stack of continuation frames shared between read0 and > readevalloop. > > The attached diff is against master from a couple of days ago. For > me, a configure/build (from scratch) completes *almost* everything > (including the standard AOT native-compiled bits) - it chokes on > lisp/leim/ja-dic.el due to a failure in a compiled function in > bytecomp.elc. There are clearly still some issues where the new code > is not dealing with unibyte/multibyte correctly. For example, running > emacs -Q shows the initial scratch buffer contents as: > > ;; This buffer is for text that is not saved, and for Lisp evaluation. > ;; To create a file, visit it with ‘C-x C-f’ and enter text in its buffer. > > This is definitely not ready for committing, but I'm hoping someone > else finds this of interest and maybe can spot where I'm going wrong > with the unibyte/multibyte handling. Or what is going on with > ja-dic.el. The error I'm seeing there is in the execution of some > byte-code, where some bit-wise operator gets a non-numeric argument. > My only idea at present is to diff the byte-compiled libraries and see > what's going on there - theoretically, there shouldn't be any change > in the results of the byte-compiler. It was pointed out to me that the patch did not actually apply cleanly to master. I'm attaching a patch generated by 'git format-path' after installing the modified lread.c to a freshly cloned master. That failed to build, so this patch is not quite the same. The one issue I mentioned about the initial scratch buffer seems to have resolved, at least. When I start it without '-Q', though, the button that precedes the missing lexical-binding cookie message is labeled with 'â\226_' instead of whatever the text should be. The 'ja-dic.el' file still produces the same error, but putting a pre-built copy of ja-dic.elc in the source tree allowed the build to complete. My configuration options are "--enable-checking=yes,glyphs --enable-check-lisp-object-type 'CFLAGS=-O0 -g3 -gdwarf-5 -fvar-tracking -gstatement-frontiers' --infodir=/usr/local/share/emacs/31/share/info --mandir=/usr/local/share/emacs/31/share/man --docdir=/usr/local/share/emacs/31/share/doc/emacs --localedir=/usr/local/share/emacs/31/share/locale --with-x --with-xim --with-sound --with-xpm --with-jpeg --with-tiff --with-gif --with-png --with-rsvg --with-imagemagick --with-dbus --with-gpm --with-x-toolkit=gtk3 --with-toolkit-scroll-bars --with-libotf --with-m17n-flt --with-cairo --with-xwidgets --disable-build-details --without-pop --with-mailutils --without-hesiod --with-gameuser=:games --with-kerberos --with-kerberos5 --with-file-notification=inotify --with-modules --with-tree-sitter NATIVE_COMPILATION_AOT=yes" Although it is not currently building all the libraries natively AOT. Which is probably good, because the native compiler seems to be even slower than usual while bootstrapping.