IRC channel logs
2026-03-25.log
back to list of logs
<probie>What does Guile do for GC these days? I have vague memories that last time I checked (about 15 years ago), it was just using the Boehm collector <ekaitz>probie: it is still doing that but there's whippet coming, a generational gc <ekaitz>old: still segfault, but in a sc.d <ekaitz>time to read the ISA again, but I think that piece of code was copied from somewhere <ekaitz>dsmith: do you have some ISA knowledge? i need to discuss <ekaitz>the only ISA i know kind of ok-ish is RISC-V and i'd like to know what others do for the lightening cas_atomic <ekaitz>there's a cas implementation in the RISC-V ISA manual, which is very similar to what I made <ekaitz>idk how to represent a failure in the cas <ekaitz>i don't understand very well what it expects, and the issue is probably there <ekaitz>i'll try to review the arm case and see if I can copy it <jcowan>I'm very familiar with the PDP-8 ISA, but I don't suppose that's helpful. <ekaitz>jcowan: did it have store-conditional and load-reserved? <jcowan>No. But it did have actual magnetic cores (little donuts) for main memory -- awesome. <jcowan>If you turned the power off, ,your program was still in memory, only the (few) registers were lost. <ekaitz>now I think i got something, the arguments to the sc.d are in the wrong order lol <ekaitz>ACTION really just stared to the computer like before, but some slight feeling of joy crawled in his chest <ekaitz>old dsmith rlb : fixed and pushed to lightening <ekaitz>and also configured my checkout to use gpg, which I didn't have <ekaitz>i'll rebuild guile with guix and run then fibers, to see if all tests pass properly now <old>ekaitz: what happened? <old>load/store were fixed but missing fix on CAS? <ekaitz>old: yes, CAS had the arguments in the wrong order <ekaitz>basically because riscv has a weird argument ordering <ekaitz>i'd say both things are fixed now, we'll see soon <ekaitz>once I have this tested i'd like to integrate in guile, if someone can help with that... <old>ekaitz: open a PR on Codeberg, I'll get it merged <old>given I don't have a RISC-V machine to test one, I trust your testing here <rlb>Hah, I was about to suggest the same. <rlb>I even still have the command: git merge -s recursive -Xsubtree=libguile/lightening LIGHTENING_REF <ekaitz>rlb: i was about to ask you for the command LOL <rlb>Can't believe previous me was that well behaved... <rlb>I can test on a porterbox, either before or after we merge --- I'd guess either's fine. <old>rlb: I will then let you do the merge <rlb>I suppose if that is "the command" we should stick it in doc/* somewhere... <rlb>ekaitz: do you want me to just do it, or do we want a PR? I'll look at what we did last time... <rlb>ACTION is fine either way <rlb>If this works out, I'll probably cherry-pick it to debian so we can go ahead. <rlb>ACTION should think about that a touch more, but still may <rlb>Oh, and congratulations :) <old>make a PR so we have a trace of the work done here <ekaitz>i will write all that down in the PR <ekaitz>the multithreading support was best effort when I wrote it because I had no idea about it <rlb>And in the commit message --- i.e. forge data tends not to last. <rlb>(over the longer hauls) <ekaitz>the commit messages you have in the lightening repo <ekaitz>how do you feel about them? enough? <rlb>Sure. I'd tend to think that the merge commit would be the place for relevant guile-specific additional explanation, rationale, motivation, if any. <ekaitz>i'm more used to rebase and push way of doing things <rlb>e.g. here, I'd guess on the guile side it might at least say something to the effect of "fix riscv jit" in the merge commit, but even better to explain a little bit more... <rlb>I also sometimes use --no-ff when adding any given sequence of commits if they all "go together", fwiw. <rlb>(i.e. even when not merging from "somewhere else") <rlb>Easy to see in the graph, and test with/without, etc. <rlb>Note, all just opinions, ymmv ;) <ekaitz>ACTION is actually kind of satisfied with the work today. All the changes and tests happened in a machine 40km away from here, so not bad. <rlb>go tmux? I'm sad when I notice I forgot to use it when bootstrapping guile on a porterbox... <ekaitz>yeah tmux, i hate it but I had to <ekaitz>i have to learn gnu screen instead hehe <ieure>Never got the hang of tmux, but the screen muscle memory runs deep. <rlb>Could just use an emacs -daemon ;) <ieure>I'm not sure you can use EXWM with the Emacs daemon. <rlb>Oh, I meant for remote terminals. <rlb>Ruh emacs -daemon on the remote, resume via emacsclient -t on the remote. <ekaitz>ACTION will write his own text editor and run naked through the mountains forever <jcowan>Just learn ex, and all will be well again <old>ekaitz: how can you hate tmux <old>best thing since sliced bread <ekaitz>i could rant a lot so i'll keep silent <rlb>sounds like good news <old>great! remote debugging works! <ekaitz>ACTION scrolls to see the git sorcery from before <old>I guess that the remote year at the University during COVID pay-off somehow <old>Remote coding with screen sharing <old>I also teached laboraty remotely <old>a FPGA class, what a mess I can tell you <old>try to help a student to upload their VHDL code into their FPGA card using Vivado <old>youg is an euphemism <old>one month ago exactly <ekaitz>i finished university like 13 years ago <ekaitz>i miss it a little bit, not gonna lie <old>student life is great <old>though, I don't like been that poor <old>but it was not so bad <ekaitz>for me, having the chance to learn things with people you could ask questions to is what I miss the most <ekaitz>learning is the only thing that matters <old>sure .. until you need the money <ekaitz>well, it's very easy to forget about money when you have enough of it <old>I could have stayed longer at the university, making a PhD <old>I would have get 1/3 of what I make now for that and I would not be able to: Buy a house, Buy a car, Pay kindergarten, pay for therapry for my old dog <old>so, money is necessary evil unfortunatelly <rlb>ekaitz: great --- not sure yet, but I might test that on a porterbox next. If so, it'll take about a day (iirc ~8 hours just to run it). <old>rlb: we ought to register to GCC build farm. I think they have some riscv64 boards <rlb>haven't looked at the build farm yet, but sounds plausible. <old>lechner: currently physio-therapy weekly and acupuncture monthly <old>for muscle build-up and pain-management <ekaitz>rlb: great, let me know if everything is ok <ekaitz>maybe we can ask some guix people to run this? <ekaitz>idk if civodul can do anything here <rlb>old: I'm not knowledgeable wrt riscv instructions, so if you or if anyone else here is, by all means, check the PR too if you have time. <rlb>(Though the changes do look plausible.) <old>well I kind of contribute to it wrt to store/load so that part if fine by me <old>I haven't lookup CAS tho <old>I'll put that on my todo for this evenning <ekaitz>the cas thingie does exactly the same ARM one does <ekaitz>maybe it could use one register less in certain case... <ekaitz>in fact, i think there's a bug in ARM <ekaitz>a register is allocated only if a condition happens to be true, and then it's released without checking for that <rlb>ekaitz: ok, build's running (on ricci.debian.org) <ekaitz>having fast response makes this kind of work way more satisfying <ArneBab>dthompson: regarding game jam: and I just got images working in enter-three-witches :-) <gabber>how can i trigger a scheme function from the DOM with hoot? e.g. i want to react to an onClick event from a button with some hoot/scheme code <ArneBab>gabber: did you already try providing addEventListener into hoot and calling it from within hoot? <ArneBab>(that’s what I would try, but I didn’t try that yet) <gabber>what is the (define-foreign ..) type of a function? (ref symbol) throws an exception <gabber>unfortunately this raises quite the exception (which i don't understand <lechner>Hi, what are the different stages by which Guile builds itself, please? <gabber>lechner: are you referring to bootstrapping?