IRC channel logs
2025-11-29.log
back to list of logs
<dsmith>rlb, FWIW: Intel 64 Deb Trixie: git clean -dxf; ./autogen.sh && ./configure && nice make -j$(nproc) && nice make -j$(nproc) check && nice make distcheck <dsmith>guile-3.0.10.288-1b58d archives ready for distribution: <old>I am setting a signal handler on SIGWINCH. In a REPL, I only receive the signal after reading something from the terminal. Any idea? <rlb>iirc C-c signals might be the same and I think I recall discussing it with someone (maybe Andy or Ludovic) who inclined toward "bug"... <rlb>(But I might also have misremembered somewhat.) <dsmith>old, Are you using readline? (readline messes with SIGWINCH IIRC) <old>dsmith: yes readline, hmm interresting <old>rlb: yes C-c is kind of broken in Guile, mostly with `system*` but not `system` IIRC <rlb>...yeah, just tested again, and if you're at the repl and hit C-c nothing happens until you hit return. Whether or not that's what we intend is of course another question. <sneek>tohoyn, you have 4 messages! <sneek>tohoyn, daviid says: please (a) update your coe so it uses the main I provided, so I canlauch the script with -d option; (b) provide a clear example as to where (in the console or ...) and how, exactly, to call dbus-send ... as said, I have zero dbus knowledge ... tx <sneek>tohoyn, daviid says: it would be better if you used dimfi (a peek 'clone', that uses less space, less newline, less semi-colomn ...) to debug, and 'normal' display inside your methods ... <sneek>tohoyn, daviid says: fwiw, dimfi always newline and returns its last arg ... <sneek>tohoyn, daviid says: see how dimfi is used in some g-golf core functionality ... as examples as to how to also properly indent debug info ... <tohoyn>daviid: my last paste EO6Q uses the same main as your paste IVPQ <tohoyn>daviid: run the server and dbus-send in separate terminal windows. First launch the server and the give the following command in the other window: dbus-send --dest=fi.tohoyn.DBusServer1 --print-reply /fi/tohoyn/DBusServer1 fi.tohoyn.DBusServer1.MyMethod1 string:Age <tohoyn>daviid: shall I change the comments to use dimfi instead of display? <tohoyn>daviid: I ported the test server to C (or actually ChatGPT did that). The ported code doesn't have the same bug as the Guile version. Here is the code: https://bpa.st/V34A. <tohoyn>daviid: here is the command line to build the C server: gcc server.c `pkg-config --cflags --libs gio-2.0 glib-2.0` -o server <tohoyn>daviid: if you comment out line 76 (g_object_ref) you get a segmentation fault as a response to the method call. <rlb>While "make distcheck" from a built tree is fine now, "make -j5 distcheck" from a clean tree crashes on a missing TOP/libguile/guile from prebuilt/ARCH. I suspect a missing inter-SUBDIR dependency, but I also checked and v3.0.10 has the same issue, so not a regression. <rlb>Oh, I thought lightening had been sorted out in main. <ekaitz>it works, it's just there was a file in the wrong folder <rlb>I don't see that file in main at all right now? <rlb>Question for today is whether we need to do anything here before we can release 3.0.11. If so, no worries, if not, might defer until after the release. <ekaitz>rlb: it might have been removed manually <rlb>It's not mentioned at all in a "git log -p" at least... <rlb>Maybe it was dropped in the merge commit? <rlb>oh, wait, wrong tree. <rlb>Oh, file name is actually .woodpecker.yml (I was using the name in the pr message). <rlb>And yes, we do have one. <rlb>So how would y'all like to proceed? Finish up that pr (might need a "rebase"?), or something else? <rlb>And is this likely to change things enough that we'll need to redo some of the release testing? <rlb>(I suppose I can just check the before/after diff of the whole tree once y'all are finished.) <ekaitz>rlb: it doesn't change anything really <ekaitz>the code in lightening is the same <ekaitz>it was a wrong subtree merge (i'm sorry) and I added the woodpecker file in the root folder instead of in the lightening folder <rlb>No worries, just want to figure out how we want to handle it -- and happy to wait a bit if y'all want to finish up. Few more days makes no difference at this point :) <rlb>And yeah, if it really doesn't change the tree much, then no concerns on the testing front either. <ekaitz>rlb: if you want to just merge it, it's fine <rlb>ekaitz: when I look at the graph of that pr's branch, it has no linkage to the lightening branch, but I thought maybe earlier merges I'd seen did -- is that expected? <rlb>e.g. 5d3f561d7dbcee370dc764cd5ba4210c62ce13de <rlb>i.e. if you see that commit in gitk or git log --graph, or... <rlb>3f02369484ba910f74d1ad25cf5911e490fed29f also had that linkage (pr 38) <rlb>I'm not really familiar with our intentions/expectations wrt the lightening branch, so... <rlb>(git semantics-wise) <ekaitz>the subtree merge is just a very problematic thing <ekaitz>and it's not obvious to do automatically <ekaitz>i think this commits do not have any relationship with lightening branch because I merged it previously and it looked fine <rlb>And so then the revert isn't considered a "complete" revert? <ekaitz>i don't think the pr is very different from doing `git mv` in the goodpecker fie <ekaitz>rlb: it never is, git doesn't know how to revert a merge really <rlb>Naively, I'd expected a full undo/redo, which would include the linkage again in the redo -- but I'm not all that familiar <ekaitz>you cannot revert a merge, there's no way to do it, git will always believe the merge was done in the point a commit has two parents <rlb>It does look like it does trivially "git rebase --rebase-merges origin/main" if we like (before pushing it, if we do). And perhaps doesn't even need the --rebase-merges... <rlb>I'll hold off for the moment -- wanted to double-check (also likely with Ludovic), and then we'll proceed. Thanks for the help. <rlb>ekaitz: is our lightening branch not up to date, and if so, know of I should fix that? <rlb>The merge has many newer commits? <ekaitz>I mean, the branch is not that important really <ekaitz>i think that lightening branch was used for development or something a while ago and never used again <rlb>Oh, sure -- I was just surprised when looking at the graph and it was "way back". <rlb>And so I wondered what our expectation was for that branch. <ekaitz>the way lightening is updated is fetching from the lightening codebase and merging in master with the subtree strategy <rlb>If we don't intend to keep it up to date, we might consider removing it. <rlb>potential attractive nuisance :) <ekaitz>if you see the lightening branch is NOT lightening's code, but guile's <rlb>ekaitz: ok, so I got curious, poked around, and wondered about this wrt current main: https://paste.debian.net/hidden/426e9d91/ Not *positive* it's "right", and it is messier, but maybe "preserves the graph"? Curious what you think (and also assume it's fine to just go with what you have). <ekaitz>rlb: if it fixes the issue, I approve <rlb>wrt the subtree merge, etc. <ekaitz>yeah... I'm in a similar situation <rlb>The final "git diff origin/main" says <rlb>diff --git a/.woodpecker.yml b/libguile/lightening/.woodpecker.yml <rlb>similarity index 100% <rlb>rename from .woodpecker.yml <rlb>rename to libguile/lightening/.woodpecker.yml <rlb>So that looks right at least <rlb>You can try it temporarily if you want to see what it looks like, and then undo of course via "git reset --hard origin/main" if you're on main (and didn't have any local changes of course). <rlb>Unless anyone else has strong feelings, I'll probably look at it more carefully later, and "pick one". <rlb>(one of the approaches) <ekaitz>I'm not very picky, as longs as the thing does what it should, I'm happy with any solution <rlb>I'm not sure it makes any practical difference unless the extra "linkage" helps git out with any future merges somehow. <ekaitz>i'm not sure if the thing really undoes the previous merge <rlb>We should make sure we have good notes somewhere wrt that proper subtree command/process -- not sure where that belongs. Worst case, I suppose we could put it in README or release.org. <ekaitz>i made wrote the example somewhere of how it should be done <ekaitz>but we should put it in the documentation or HACKING file or something <rlb>It creates a new branch from the merge of (subtree) lightening and main before the incorrect merge and then merges that into current main. <rlb>So right, no "undo". <ekaitz>i don't think there's going to be any problem in the future <rlb>Just want to make sure the next person doing this (including possibly future me) has a chance to get it right ;) <ekaitz>rlb: this is what is supposed to be done: git merge -s recursive -Xsubtree=libguile/lightening origin-lightening/main <rlb>I found that in your pr message. <ekaitz>I also try to be empathetic with my future self <rlb>Oh, git-merge(1) points to a whole git doc about the general issue: /usr/share/doc/git/html/howto/revert-a-faulty-merge.html <ekaitz>rlb: i read that one and what I did the PR with my conclusion: just keep it simple, git is always going to think the thing was merged at that point, so why bother? <rlb>yeah, I now see that's "a lot" ;) <rlb>OK, may just go with what you have and call it a day. Will decide later. Thanks again.