Re: Guile 3 and wip-elisp/Emacs
Christine Lemmer-Webber writes: > Ludovic Courtès writes: > >> Hello! >> >> Christine Lemmer-Webber skribis: >> >>> I've pushed this as origin/wip-elisp-rebased. I actually rebased it >>> again, making some naming adjustments for myself and a couple of >>> adjustments having talked to Robin. >>> >>> If nobody objects, I'd like to merge this into main. Maintainers, if >>> you have any objections, speak now or forever hold these commits! >> >> I haven’t looked at the branch, but I think it’s great to see it live >> and it’s great if it can be merged! > > I just compiled the rebased version and will be playing with it little > bits over the next few days to make sure it's reasonably good. > >> Some things to pay attention to before merging to ‘main’, since it >> corresponds to the current 3.0 stable branch: >> >> • Make sure no backward incompatibilities are introduced in >> preexisting modules; >> >> • Make sure the ABI of libguile-3.0.so and that of public modules >> is unchanged, or is changed compatibly; > > There are, I think, two commits that could use review, but I am NOT the > right person to do this. > > 4e96211eb666751b8666beb918bf3108aa1c725b intern arbitrary constants > 433fc448ddb018767906f8808203c9668c68cd83 multiple obarrays I'll take a look at these... > [...] (and maybe the "guile-private-ref" and "allow > arbitrary constants in cps" commits look relevant too). and these, but concur that Andy is the best person to review them, and I agree that Andy should approve the merge overall in any case. Still reviewing the wip-elisp-rebased branch in my spare time; so far I haven't found any noteworthy problems, not that I was expecting to :) A minor point: IMHO the "(Best-ability ChangeLog annotation ...)" lines aren't the ideal way to credit you, in terms of commit message formatting. I'd prefer using git 'trailers' for in-commit credit, so that it's obvious to both humans and git that it's commit metadata. I'm not sure there's a conventional git trailer for this...something like 'ChangeLog-by:' would be probably be clear enough. But if you prefer the current formatting and it works with Guile's ChangeLog generator, I don't mind leaving it as-is (except perhaps "s/Best-ability //" after I've reviewed everything :)) WDYT? Thanks, Robin -- "You have to act as if it were possible to radically transform the world. And you have to do it all the time." -- Angela Davis
Re: Guile 3 and wip-elisp/Emacs
"Gregg Sangster" writes: > Hello, > > I have wip-elisp rebased all the way up to main as of a few days ago > (e60469c8b6936575c079faaffa40a340e1d49f3c) plus two changes from > Ricardo. It's available here: > > https://git.sr.ht/~g20r/guile > > There is one test failure in "make check" on test-out-of-memory. I > haven't investigated it yet but I get the same failure on main. If > that's not an expected failure, it might be a problem with my > environment. > > There is also an emacs repo here: > > https://git.sr.ht/~g20r/emacs > > which uses the 3.0-based wip-elisp. It builds and runs but segfaults > easily. I've started rebasing it on a more current emacs. Those > changes aren't published yet. It's not a good sign that it segfaults easily; Someone(TM) should figure out the source of the crashes even if rebasing happens to fix them, which I wouldn't necessarily count on. I'll try to do some debugging in the next few days. > I haven't been able to get the guile-emacs package in guix working. The > build gets stuck at collecting/processing OKURI-NASI entries after a few > hours. For comparison, the 3.0-based guile-emacs builds in about 20 > minutes on my machine. If anyone has that running, it would be nice to > have a comparison of the build/run speed. I can confirm that, it seems to get stuck at: Reading file "/tmp/guix-build-[...]/[...]/leim/SKK-DIC/SKK-JISYO.L" ... [...] Collecting OKURI-NASI entries ... [...] collected 70% ... even after running for quite a while: guix build -c32 guile-emacs 5.29s user 0.47s system 0% cpu 28:02:53.21 total I'm not sure what's going on here, as I've definitely installed the guile-emacs package before (though not recently) and it doesn't use the standard emacs and guile packages, for obvious reasons. I can probably use guix time-machine to figure out what's happening. That build phase was always excruciatingly slow, but not *that* slow. -- „Die Philosophen haben die Welt nur verschieden *interpretiert*, es kömmt drauf an, sie zu *verändern*.“ -- Karl Marx
Re: Guile 3 and wip-elisp/Emacs
"Dr. Arne Babenhauserheide" writes: > The workload to finish this is considerable, though: IIRC You’ll need to > solve some deeper problems that prevent Guile Emacs from using > byte-compiled files (that’s why it currently has a very high startup > time). To clarify, Guile-Emacs intentionally ditches the existing Emacs bytecode compiler entirely (though it'd probably be possible to emulate the bytecode interpreter to allow loading old '.elc' files). I haven't followed Guile development closely enough to know whether these are practical solutions, but my main ideas for improving startup speed were to either add some form of AOT compilation to Guile, or to rely on cached JIT-compiled code. IIRC Emacs now uses a portable dumper (rather than the old system which dumped a running Emacs instance to an executable), which seems analogous to the latter approach. > That said, there is a guile-emacs package in guix, and Guile 3.0.7 is > much faster than Guile 2. > > (please someone correct me if I’m wrong!) > > Best wishes, > Arne Regards, Robin -- But speaking of programming, I was dreaming that I had some coding problem and suddenly robin walked by, so I asked what the common lisp way of solving it would be.
Re: Guile 3 and wip-elisp/Emacs
"Gregg Sangster" writes: > Hello Guile Hackers, > > I've rebased the wip-elisp branch on top of commit > 449f50dd84a081aea16ef678e32bf37abe429ff6 (git describe: > v3.0.4-64-g33232cb5c4). It's published here: > > https://git.sr.ht/~g20r/guile This is wonderful, thank you! (IIUC, Christine and Ricardo wrote ChangeLog entries and did some rebasing, but I don't think it's been fully rebased for some time, so this is a big step forward!) N.B. The commit messages need minor rewording, so this will require trivial changes before merging even if's otherwise perfect. > There are two additional failed tests which appear to be new tests > added since the last work on the wip-elisp branch. Also, ./configure > requires the --disable-jit option as the build fails otherwise. I > have not yet investigated any of these issues. Christine noted some "questionable" compiler changes, where my changes might conflict with Andy's, so this isn't surprising but it's useful to have potential confirmation. The elisp changes were fairly simple, so it shouldn't be too difficult to fix, if that is indeed the problem. > I don't have much experience with Guile itself or the Guile codebase. > The next commit has a conflict I was not able to resolve: that's why > it's not rebased all the way up to the tip of main. My next tasks are > to get the current Guile Emacs running on this version of Guile > followed by fixing the JIT build failure, rebasing this to the tip of > main and rebasing Guile Emacs on a more recent Emacs (I believe it is > currently v24.something). Rebasing onto a somewhat newer Emacs should be pretty straightforword, and certainly worthwhile on its on. However, rebasing onto emacs master is a major task that'll probably take several person-months of fairly tedious work... > My question is if this is worthwhile work? I don't have much time to > spend on it but am happy to keep hacking away if there's still > upstream interest. >From my perspective, it certainly is! There is plenty of interest from the Guile side AFAICT; the Emacs maintainers have been (understandably) skeptical about the project in general, but if we can make it correct *and* fast I think they'll be more interested, especially if Guile 3's JIT outperforms emacs native-comp in practice. Thanks, Robin -- "Digital Imperialism: The Highest Stage of Computing Capitalism" -- the Lenin of Emacs
Re: [guile-emacs] Circular require problem
Left Right olegsivo...@gmail.com writes: Hello, I've asked at #guile IRC channel and was told this is the right place to report these. So, I've built Guile-2.2 and Guile-Emacs. Vanilla Emacs didn't start at first due to: (provide 'calendar) (require 'cal-menu) lines in cal-menu.el. This is because calendar requires cal-menu and cal-menu requires calendar. It seems like the strategy in these situation with Emacs Lisp is to put a fake provide statement in the beginning of the file which provides the library, knowing that there's the second real provide statement in the end of the file. I've witnessed this same problem with couple more libraries, ERC being one of them. The first thing I tried was: (unless (featurep 'cal-menu) (require 'cal-menu)) Which, in some cases magically solved the problem, but not in other cases. But I don't think it is useful to mimic Emacs behavior wrt circular require. I think it would be better to make circular require possible by remembering what libraries had already been required. Thank you for the detailed report! This problem has been fixed in the current version of Guile-Emacs. I had modified `load' to compile and execute entire files at once, but the expression-by-expression evaluation normally performed by `load' is important for breaking `require' cycles like the one you encountered. Top-level `require' forms are evaluated at compile time but `provide' forms aren't, so when `load' compiles the whole file at once, early `provide' forms can never take effect at the right time. Additionally, some packages simply don't `require' all their dependencies and can't be byte-compiled cleanly. To support such packages, `load' now loads source files using an interpreter, just as standard Emacs does. Guile-Emacs will support automatic compilation again in the future, but it will take some time to implement in a completely compatible way. I have more problems to report. I've tried loading some popular Emacs packages, such as Org, SLIME, ESS and CEDET, and few others, but none of that worked. Only relatively large library that loaded was Pymacs, but it affected the rest of the code somehow so that nothing else would compile any more. Org, SLIME and ESS all work for me with the current version. (I haven't tested CEDET or Pymacs.) There was another problem with eval-buffer, where (add-to-list 'load-path ...) with the following (require ...) sexp wouldn't work, but if evaluated sexp after sexp they magically worked. This should be fixed now as well. I have saved backtrace and crash messages, and I could probably produce more / more specific error messages if I knew better how to debug. The regular backtrace buffer doesn't seem to be particularly useful (too much technical info, which is difficult to trace back to the source of the problem). This is now fixed. Thanks, Robin -- Inteligenta persono lernas la lingvon Esperanton rapide kaj facile. Esperanto estas moderna, kultura lingvo por la mondo. Simpla, fleksebla, belsona, Esperanto estas la praktika solvo de la problemo de universala interkompreno. Lernu la interlingvon Esperanton!
ELF and garbage collection
The following program works as expected in Guile 2.0: (do ((i 0 (1+ i))) ((= i 10)) (compile ''foo #:from 'scheme #:to 'value)) ...but when it's evaluated in Guile from the master branch, Guile crashes with a too many root sets error. This is because `GC_add_roots' is used in loader.c to instruct the garbage collector to scan the program constants section of an ELF object, and there's a fixed limit in libgc on the total number of roots. AFAICT, `GC_add_roots' used because loaded programs aren't garbage-collected. This makes normal compilation inconvenient when it's necessary to compile and execute lots of independent single-expression programs, like with the Elisp and Common Lisp `load' functions. The easiest solution is to change nothing and require the use of interpreters for some applications. Guile-Elisp currently relies on a Tree-IL interpreter to load files; whole-file compilation is not possible for some programs. Maybe it's possible to modify the internal representation of ELF programs and/or extend libgc so that the garbage collector can manage them. It would be tricky to do this without scanning arbitrary program text. Another option could be to define a new program representation for small programs that's amenable to garbage collection, at the cost of complicating the VM somewhat. What do you think? Thanks, Robin -- Inteligenta persono lernas la lingvon Esperanton rapide kaj facile. Esperanto estas moderna, kultura lingvo por la mondo. Simpla, fleksebla, belsona, Esperanto estas la praktika solvo de la problemo de universala interkompreno. Lernu la interlingvon Esperanton!
