Re: Guile 3 and wip-elisp/Emacs
Hi Christine, On Friday, October 22, 2021 12:17 EDT, Christine Lemmer-Webber wrote: > Christine Lemmer-Webber writes: > > I missed earlier in the thread that Gregg said that we should use > > --disable-jit. Once I did that it was fine. So ignore this bit! > > > > - Christine > > It wasn't this either! It turns out it's that ,L elisp and geiser don't > seem to get along (yet). The same thing happens with me in Guile's > stable release. > > Also notably, --disable-jit doesn't seem to have been the culprit for me > then; I got it to compile fine without it, I think? --disable-jit isn't needed. My initial rebasing was done in the guile-for-guile-emacs guix environment and around the guile 2 to 3 transition it became necessary. After switching to the guile-next environment, the jit version compiles fine. -- Gregg
Re: Guile 3 and wip-elisp/Emacs
Christine Lemmer-Webber writes: > Well, *something* isn't ready to go: > > scheme@(guile-user)> (+ 1 2) > $3 = 3 > scheme@(guile-user)> ,L elisp > Happy hacking with Emacs Lisp! To switch back, type `,L scheme'. > elisp@(guile-user)> (+ 1 2) > $4 = 3 > elisp@(guile-user)> (cons 'foo '()) > $25 = (foo) > elisp@(guile-user) [10]> > > Hoo, 10 levels deep! I missed earlier in the thread that Gregg said that we should use --disable-jit. Once I did that it was fine. So ignore this bit! - Christine PS: An aside: wrong name in previous email; I never use gnus anymore, apparently loading it accidentally the other day loaded a stale ~/.gnus.el and lead to me deadnaming myself with an old (setq user-full-name ...) !!! Watch out for stale elisp!
Re: Guile 3 and wip-elisp/Emacs
Christine Lemmer-Webber writes: > Christine Lemmer-Webber writes: > >> Well, *something* isn't ready to go: >> >> scheme@(guile-user)> (+ 1 2) >> $3 = 3 >> scheme@(guile-user)> ,L elisp >> Happy hacking with Emacs Lisp! To switch back, type `,L scheme'. >> elisp@(guile-user)> (+ 1 2) >> $4 = 3 >> elisp@(guile-user)> (cons 'foo '()) >> $25 = (foo) >> elisp@(guile-user) [10]> >> >> Hoo, 10 levels deep! > > I missed earlier in the thread that Gregg said that we should use > --disable-jit. Once I did that it was fine. So ignore this bit! > > - Christine It wasn't this either! It turns out it's that ,L elisp and geiser don't seem to get along (yet). The same thing happens with me in Guile's stable release. Also notably, --disable-jit doesn't seem to have been the culprit for me then; I got it to compile fine without it, I think?
Re: Guile 3 and wip-elisp/Emacs
Robin Templeton writes: > 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? I'm fine changing it. The original reason for the "best ability" notes was that I was more or less making up text to make it compatible with the changelog style based off of reading your code. Honestly the attribution part isn't the most important to me but the "ChangeLog-by is an interesting idea". Most importantly, I want to get it in! :) > Thanks, > Robin
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
Hi Gregg, On Thursday, October 14, 2021 13:34 EDT, Ricardo Wurmus wrote: I also had he same experience. Guile Emacs would segfault very quickly. That’s why I started a rebase on top of the nearest Emacs release, which is 25.2. I had to abandon the rebase, because after about 45 commits it became too difficult for me to understand what exactly I had to do to resolve all these conflicts. There are about 112 commits left to apply. If you think you could benefit from the work I already did I could upload the full git repo as it is, mid-rebase and all. If you'd like to upload it, I think it would be a great reference. You can download it here: https://bimsbstatic.mdc-berlin.de/akalin/guile-emacs-repo.tar.xz -- Ricardo
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. Well, *something* isn't ready to go: scheme@(guile-user)> (+ 1 2) $3 = 3 scheme@(guile-user)> ,L elisp Happy hacking with Emacs Lisp! To switch back, type `,L scheme'. elisp@(guile-user)> (+ 1 2) $4 = 3 elisp@(guile-user)> (cons 'foo '()) $25 = (foo) elisp@(guile-user) [10]> Hoo, 10 levels deep! >> 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
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 3 and wip-elisp/Emacs
Hi Ricardo, On Thursday, October 14, 2021 13:34 EDT, Ricardo Wurmus wrote: > I also had he same experience. Guile Emacs would segfault very > quickly. That’s why I started a rebase on top of the nearest > Emacs release, which is 25.2. I had to abandon the rebase, > because after about 45 commits it became too difficult for me to > understand what exactly I had to do to resolve all these > conflicts. There are about 112 commits left to apply. > > If you think you could benefit from the work I already did I could > upload the full git repo as it is, mid-rebase and all. If you'd like to upload it, I think it would be a great reference. I've taken the strategy of rebasing forwards along the master branch a few commits at a time. So far I'm about a thousand commits ahead. It's time consuming but the conflicts to resolve are smaller. There are just more of them. :) -- Gregg
Re: Guile 3 and wip-elisp/Emacs
Hi Christine, Thanks for looking at this! I just noticed that my email address as the committer on 1ba3d7854cac0524f80d3c6113da770505c9eda9 is incorrect. Before merging, can you please change it to gr...@thesangsters.ca? On Tuesday, October 19, 2021 17:59 EDT, Christine Lemmer-Webber wrote: > 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! > > Christine Lemmer-Webber writes: > > > This is awesome. > > > > So, what's stopping us from merging this into guile main now before it > > bitrots again? :) > > > > "Gregg Sangster" writes: > > > >> Hi Ricardo, > >> > >> Thanks, your changes fixed a couple of the test errors I saw. > >> > >> On Monday, September 13, 2021 06:56 EDT, Ricardo Wurmus > >> wrote: > >> > >>> > >>> Hi Gregg, > >>> > >>> > 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 > >>> > >>> FWIW I had also rebased wip-elisp in 2020: > >>> > >>> > >>> https://git.elephly.net/?p=software/guile.git;a=shortlog;h=refs/heads/wip-elisp > >>> > >>> -- > >>> Ricardo > >>> >
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 > >> • Make sure there are reasonable tests and doc so it can be maintained >> (and used!) going forward; > > Three tests across elisp-compiler.test,elisp-reader.test, elisp.test. > They seem to cover enough. Also I just verified, only one commit is failing, which is the out of memory test, but that's failing on the main branch too. So looks good on that front.
Re: Guile 3 and wip-elisp/Emacs
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 > • Make sure there are reasonable tests and doc so it can be maintained > (and used!) going forward; Three tests across elisp-compiler.test,elisp-reader.test, elisp.test. They seem to cover enough. > • Robin has a copyright assignment on file, so we should be fine > (whether we’ll keep doing copyright assignment for Guile is still > unclear, but we can discuss that separately). Cool. > I think we should also wait for a green light from Andy. Yes, I think so too. Note that I will be without consistent internet over the next few days so will be replying intermittently until the weekend, but I want to see this happen. Andy, I think you're the best person to review the relevant commits above (and maybe the "guile-private-ref" and "allow arbitrary constants in cps" commits look relevant too). > Thanks Gregg, Christine, Robin, and everyone involved! Yes, also Ricardo for doing the previous rebase! This is awesome stuff! Let's get it in! > Ludo’.
Re: Guile 3 and wip-elisp/Emacs
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! 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; • Make sure there are reasonable tests and doc so it can be maintained (and used!) going forward; • Robin has a copyright assignment on file, so we should be fine (whether we’ll keep doing copyright assignment for Guile is still unclear, but we can discuss that separately). I think we should also wait for a green light from Andy. Thanks Gregg, Christine, Robin, and everyone involved! Ludo’.
Re: Guile 3 and wip-elisp/Emacs
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! Christine Lemmer-Webber writes: > This is awesome. > > So, what's stopping us from merging this into guile main now before it > bitrots again? :) > > "Gregg Sangster" writes: > >> Hi Ricardo, >> >> Thanks, your changes fixed a couple of the test errors I saw. >> >> On Monday, September 13, 2021 06:56 EDT, Ricardo Wurmus >> wrote: >> >>> >>> Hi Gregg, >>> >>> > 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 >>> >>> FWIW I had also rebased wip-elisp in 2020: >>> >>> >>> https://git.elephly.net/?p=software/guile.git;a=shortlog;h=refs/heads/wip-elisp >>> >>> -- >>> Ricardo >>>
Re: Guile 3 and wip-elisp/Emacs
This is awesome. So, what's stopping us from merging this into guile main now before it bitrots again? :) "Gregg Sangster" writes: > Hi Ricardo, > > Thanks, your changes fixed a couple of the test errors I saw. > > On Monday, September 13, 2021 06:56 EDT, Ricardo Wurmus > wrote: > >> >> Hi Gregg, >> >> > 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 >> >> FWIW I had also rebased wip-elisp in 2020: >> >> >> https://git.elephly.net/?p=software/guile.git;a=shortlog;h=refs/heads/wip-elisp >> >> -- >> Ricardo >>
Re: Guile 3 and wip-elisp/Emacs
Hi Gregg, "Gregg Sangster" writes: 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 Excellent! 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. I also had he same experience. Guile Emacs would segfault very quickly. That’s why I started a rebase on top of the nearest Emacs release, which is 25.2. I had to abandon the rebase, because after about 45 commits it became too difficult for me to understand what exactly I had to do to resolve all these conflicts. There are about 112 commits left to apply. If you think you could benefit from the work I already did I could upload the full git repo as it is, mid-rebase and all. 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 only got the 2.x-based Guile Emacs to build. Haven’t tried with 3.x because I had not dared rebase beyond 2.2. -- Ricardo
Re: Guile 3 and wip-elisp/Emacs
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. 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. On Sunday, September 12, 2021 22:13 EDT, Christine Lemmer-Webber wrote: > "Dr. Arne Babenhauserheide" writes: > > > [[PGP Signed Part:Undecided]] > > Hello Gregg, > > "Gregg Sangster" writes: > > > >> 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 > > > > I’m not a Guile core developer, but I think that this is awesome! > > > >> 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. > > > > I think that there is upstream interest in Guile to improve the elisp > > implementation, but I’m not sure about Emacs. They added improvements to > > elisp that also provide better performance and they keep improving their > > elisp implementation. > > I would personally think it would be good if we could get the wip-elisp > branch merged. It would be good not to bitrot. It seems more likely to > survive if it gets included in emacs proper. > > > That said: Tools like fibers would be great to have in Emacs. > > > > 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). > > > > That said, there is a guile-emacs package in guix, and Guile 3.0.7 is > > much faster than Guile 2. > > Yes, to complete *guile-emacs*... that will be a lot of work. But it > will be less work if guile's elisp branch is no longer this separate > thing that isn't kept up to date with the rest of guile. More likely > that someone could finish and pick it up. > > > (please someone correct me if I’m wrong!) > > > > Best wishes, > > Arne >
Re: Guile 3 and wip-elisp/Emacs
Hi Ricardo, Thanks, your changes fixed a couple of the test errors I saw. On Monday, September 13, 2021 06:56 EDT, Ricardo Wurmus wrote: > > Hi Gregg, > > > 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 > > FWIW I had also rebased wip-elisp in 2020: > > > https://git.elephly.net/?p=software/guile.git;a=shortlog;h=refs/heads/wip-elisp > > -- > Ricardo >
Re: Guile 3 and wip-elisp/Emacs
Hello, Just my 2 cents as a drive-by watcher: I agree that having wip-elisp branch in guile tree would be nice to have, this way it's easier to find out where progress is being made for this endeavour, with potentially a checked out TODO or TASKS file to see if I can ever help (if only with testing, I know nothing of compilation so I don't think I'll be able to contribute to an .elc parser/evaluator/loader) Regards, -- Gerry
Re: Guile 3 and wip-elisp/Emacs
Hi Gregg, 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 FWIW I had also rebased wip-elisp in 2020: https://git.elephly.net/?p=software/guile.git;a=shortlog;h=refs/heads/wip-elisp -- Ricardo
Re: Guile 3 and wip-elisp/Emacs
"Dr. Arne Babenhauserheide" writes: > [[PGP Signed Part:Undecided]] > Hello Gregg, > "Gregg Sangster" writes: > >> 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 > > I’m not a Guile core developer, but I think that this is awesome! > >> 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. > > I think that there is upstream interest in Guile to improve the elisp > implementation, but I’m not sure about Emacs. They added improvements to > elisp that also provide better performance and they keep improving their > elisp implementation. I would personally think it would be good if we could get the wip-elisp branch merged. It would be good not to bitrot. It seems more likely to survive if it gets included in emacs proper. > That said: Tools like fibers would be great to have in Emacs. > > 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). > > That said, there is a guile-emacs package in guix, and Guile 3.0.7 is > much faster than Guile 2. Yes, to complete *guile-emacs*... that will be a lot of work. But it will be less work if guile's elisp branch is no longer this separate thing that isn't kept up to date with the rest of guile. More likely that someone could finish and pick it up. > (please someone correct me if I’m wrong!) > > Best wishes, > Arne
Re: Guile 3 and wip-elisp/Emacs
Hello Gregg, "Gregg Sangster" writes: > 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 I’m not a Guile core developer, but I think that this is awesome! > 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. I think that there is upstream interest in Guile to improve the elisp implementation, but I’m not sure about Emacs. They added improvements to elisp that also provide better performance and they keep improving their elisp implementation. That said: Tools like fibers would be great to have in Emacs. 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). 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 -- Unpolitisch sein heißt politisch sein ohne es zu merken signature.asc Description: PGP signature
Guile 3 and wip-elisp/Emacs
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 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. 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). 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. -- Gregg
Guile 3 and wip-elisp/Emacs
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 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. 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). 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. -- Gregg
Guile 3 and wip-elisp/Emacs
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 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. 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). 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. -- Gregg
