IRC channel logs

<daviid>n|Phreak: fwiw, g-golf comes with Gtk-4 and Adw-1 examples - https://www.gnu.org/software/g-golf/learn.html - if you plan to devel an app, you should consider using libadwaita

<daviid>n|Phreak: if to wrap EFL, you should definitely use the nyacc ffi-helper for the low-level bindings, then provide (write) a higher level 'scheme' api, for which the best approach, imo, is to use goops - this is what guile-mqtt does, this is also what I do in guile-fluidsynth (which just got authorized to be on savannah, I should upload it anytime soo now)

<omentic>are there any qt-based gui libraries for guile?

<apteryx>is there a risk of double-free if I guard an object via a guardian (info "(guile) Guardians") yet manually reclaim the object before the guardian has returned it?

<apteryx>hm. memory address seen in strace: 0x7f682f1bf000; in guile: 0x7f6825ce0000

<apteryx>a different run: strace: 0x7f193515d000, guile: 0x7f193515c000

<apteryx>is using pointer->bytevector and bytevector->pointer to get back the pointer supposed to give me the same ptr/address?

<mwette>did you use zero for the len argument? You need to, I think

<mwette>oh, wrong,

<mwette>I was digging through all the layers and missed it.

<apteryx>mwette: I was trying to come up with a test that ensures munmap gets called exactly once, when the user/library manually callen munmap

<mwette>Got it. So munmap fails badly when called twice?

<apteryx>no! but it sounds like a bad thing that it would happen :-) (something else could have been used at the same address spot on the 2nd munmap, leading to corrupted state?)

<apteryx>so my idea is to use weak-key hash table to keep the manually munmapped bytevectors, and check this hash table in the pump-guardian-mmap routine before calling munmap there.

<apteryx>but first, trying to see a failing test :-)

<mwette>It sets errno. I'm not sure double-call is posslbe w/o hiding munmap from the user.

<apteryx>I've found it's best if the Guix library itself calls munmap every time a MAP_SHARED mmap is used, otherwise it keeps a lock on files, and you can't exec them for example.

<mwette>It's like using close on a port, though the GC can do that also.

<mwette>IIRC

<apteryx>right; my goal is to allow both usages, either manually called or lazily via the GC.

<mwette>I've run into problems where I have had to explicitly close file ports, because I was running out of (linux process) resources.

<mwette>At least that's what I remember. I need to go back and look.

<mwette>Hmm. Seems non-trivial. You could use object properties, but not sure that is efficient.

<apteryx>my test seems flawed; I was expecting the ptr address to be seen the same from strace or from guile, but they don't seem to match exactly, at least not all the time: https://paste.guixotic.coop/syscalls.scm_guix_tests_-25073-26126.html

<apteryx>above is my test

<apteryx>and the result looks like: https://paste.guixotic.coop/syscalls-36105-37701.log_tests_.html

<apteryx>maybe I should simply instrument the pump-guardian-mmap or munmap procedures with a parameter that I could then use to count how any times it was called

<apteryx>or is there something native in guile to inspect how many times a procedure got called in a test?

<apteryx>there's trace-calls-to-procedure, but this just prints

<apteryx>also from experiments in the past, I couldn't get it to work, perhaps the VM was not in debug mode.

<apteryx>this works, though not checking the mmap address feels like it may be fragile: https://paste.guixotic.coop/syscalls-36105-37166.log.html

<apteryx>this is showing the problem (2 munmap calls)

<apteryx>mwette: the idea of the weak hash table looks like: https://paste.guixotic.coop/magit_guix-398-1436.html

<apteryx>but it doesn't work yet, I need to debug it

<old>apteryx: for your weak ahsh table and mmap

<old>I think what you could do is

<old>use a regular hash map and store: address -> length

<old>not the pointer object itself

<old>in your guardian, you lookup the length of the pointer by using `pointer-address' as the key

<old>that way, you never keep a reference to the pointer object itself, you only keep the address number and length in a hash map

<old>and this will work with munmap also

<old>you lookup the pointer address and remove it from the hash table whenever a succesfull call to munmap happen

<old>you might want to protect this with a mutex tho to avoid double free

<apteryx>old: thanks for the idea; I was just finding out that taking bv out of the guardian segfaults if it was already munmap'd :-)

<old>how do you pass the off_t parameter btw?

<old>off_t offset

<old>the last paramter to mmap. It's not defined in foreign-library (the type)

<apteryx>there's an #:offset keyword to mmap

<old>you mean the wrapper is already present in Guix?

<old>I meant that when you use foreign-library-function to make a procedure that call the syscall

<old>you have to pass the types of the argument

<apteryx>I used long, like what was done in Artanis I think

<apteryx>(define %mmap (syscall->procedure '* "mmap" (list '* size_t int int int long)))

<old>ah yes I just saw that hm

<old>would be nice of Guile could provide `off_t`

<apteryx>old: with you hash table keeping addr -> length, the guardian would still keep the bytevector object?

<apteryx>If so, I'll have the same problem, as it seems if the bytevector's underlying pointer has been unmapped, it can't be used at all without causing a segfault (so I wouldn't be able to get the (bytevector-address (bytevector->pointer bv))

<apteryx>err, pointer-address

<apteryx> https://paste.guixotic.coop/syscalls-41800-42051.scm_build_.html

<apteryx>interestingly the sigsev seems to be silenced when it happens when running in the GC hook

<apteryx>I can see it at the REPL if I eval the guardian directly after munmap'd a bytevector, and then set! bv to #f to have it collectable.

<apteryx>ACTION -> zzz, I'll read the scrollback tomorrow

<old>question for you

<old>you want to allow someone to do: mmunmap manually

<old>but then you could have a bytevector somewhere still alive that do a reference and will segfault no?

<old>apteryx: this is a dummy example I made

<old> https://paste.sr.ht/~old/c8ad3015f47f705ab1885531de9d4dd15971ee98

<old>you have manual memory management with MADV_DONTEED to hint the kernel that the memory can be reclaimed (physical only) while still being safe to use the bytevector

<old>otherwise if you call munmap directly, somebody could still have a reference to the bytevector and touch the memory, segfaulting in Scheme

<old>an alternatvie would be to not return a bytevector, but another type of object that hide the pointer from the user

<old>you keep an internal flag to this structure and when you call munmap on it, you set it to #f. This will disable operations on the memory

<mwette>Could you create a (shared) weak hash table; add pointer when mmap is called; remove entry when munmap is called; if munmap gets pointer not in table, do nothing.

<mwette>the table can keep the lengths.

<old>mwette: the problem with weak table is that in the guardian, the reference won't be in it

<old>and so you lose the length

<mwette>OK.

<old>what would have been great is for pointer finalizer to accept a scheme thunk

<old>that way, we would just done: (set-pointer-finalizer! pointer (lambda () (munmap pointer length)))

<old>but again I don't think that the reference would be in the weak table in finalizer

<rlb>Hmm, I wonder if this is intentional, or if we might be missing some build deps -- I just updated my branch to include the recent lightening changes, and when I ran make, it didn't rebuild anything. Maybe I misunderstood, but I'm moderately certain that's right.

<rlb>So, ekaitz, should the diff between 62e9ccc06a42fcb4d33416c982a0dc0a62da4c4b and main be nearly empty?

<rlb>i.e. I only have CI and minor doc chnages.

<rlb>Perhaps ArneBab too ^ (or maybe I'm looking at it wrong).

<dsmith>rlb, When you do a git checkout/switch/whatever to an earlier commit, does it also back date the file? Or does it have a fresh "now" timestamp?

<rlb>It changes the timestamps to now I believe.

<rlb>But according to the diff "there are no changes".

<dsmith>ACTION never thought about it before

<dsmith>Ah

<rlb>i.e. only changes (if I'm doing it right) are to woodpecker.yml and the lightening README.md.

<rlb>There are various flavors of diff you cold do, but one is if you're on current main just "git diff 62e9ccc06a42fcb4d33416c982a0dc0a62da4c4b".

<rlb>I could also just be getting the diff wrong.

<ekaitz_>rlb: idk what that is

<rlb>ekaitz ArneBab: perhaps it's fine -- I checked the actual content of x86.c by hand, and it appears to include the changes, so perhaps nvm. (Though I remain confused -- that hash above is just before the merge which includes the x86.c changes as far as I can see in say gitk).

<ekaitz_>the diff i saw is pretty unrelated with x86.c

<rlb>Oh, wait -- the revert.

<rlb>I bet that's what's confusing me.

<ekaitz_>please give me some context because I just got here and I don't know what you are talking about

<rlb>(And must be that git's smart enough to notice that the file doesn't change in the end, and so doesn't update it.)

<rlb>i.e. doesn't replay the revert.

<ekaitz_>you are talking about #38?

<ekaitz_>there is a revert so it doesn't really look like it's doing anything

<ekaitz_>and that's exactly how it should look

<ekaitz_>because we are moving a change we have to lightening

<rlb>ekaitz: short story -- I was on 62e9ccc06a42fcb4d33416c982a0dc0a62da4c4b (previous main), and I did an (effective) "git pull --rebase" to move to current main, including the lightening changes. Then I did a "make", and nothing built, so I got suspicious.

<ekaitz_>and merging lightening

<ekaitz_>oh so yeah

<ekaitz_>the file doesn't really change

<rlb>And saw "no diff" between the two commits, but that's because the revert came just after that hash, and then the merge restored the change, but git was smart enough to not change the timestamp twice, and so "no build".

<rlb>So nvm -- clever, but slightly confusing.

<ekaitz_>rlb: when I did the pr I was supersuspicious about it

<ekaitz_>i was like "wtf dude! it doesn't change anything"

<ekaitz_>but of course it doesn't

<ekaitz_>the change is still there, but in lightening

<ekaitz_>so in the end, the code is the same

<rlb>It's also confusing in gitk (in the commits) that the paths for lightening are lightening/x86.x not libguile/lightening/lightening/x86.c.

<rlb>i.e. the paths in the commit aren't "real".

<ekaitz_>they are, but in lightening

<ekaitz_>it is merged using a subtree strategy

<ekaitz_>but I see what you mean

<rlb>Sure, but I'd have assumed that whatever happened, gitk would make them the real real paths in the commits...

<rlb>i.e. from looking at the commit, how in the world do I know which file actually changed?

<rlb>But I'm also not all that familiar with more complex merge bits.

<rlb>I assume y'all did "something special".

<ekaitz_>that's a really good question, and that's why submodules were invented i think

<ekaitz_>rlb: do you want me to explain how that works?

<rlb>I'm just very surprised that there's no way to look at the commits and know what actually happened -- i.e. where's the info in the commits that tells me where those files actually are?

<rlb>It's not even in the merge commit.

<ekaitz_> https://git-scm.com/book/en/v2/Git-Tools-Advanced-Merging.html#_subtree_merge <-- that's how lightening is handled

<ekaitz_>basically lightening's history is included in a separate branch, and then a merge is done against the lightening directory

<ekaitz_>you can read the history to know where the files were coming from

<rlb>Andy's last lightening merge *does* at least mention the real paths, i.e. git show 5d3f561d7dbcee370dc764cd5ba4210c62ce13de

<rlb>I wonder if he did something different, or if your merge was just different somehow.

<rlb>Though oh, perhaps again, that's the revert.

<ekaitz_>oh that can be

<rlb>i.e. because of that there were no actual changes in the subdir to mention.

<rlb>I suspect that's it.

<rlb>OK, well thanks for humoring me...

<ekaitz_>yeah that might be it

<ekaitz_>rlb: compare with d418f8080

<ekaitz_>that also doesn't show anything in the files

<ekaitz_>because it doesn't know which side you want to check

<ekaitz_>you can `git show -m`

<ekaitz_>i didn't merge properly now I think about it hehe

<ekaitz_>the .woodpecker file is wrongly merged in the project root

<rlb>Sure, but if I check out 624d78625b81d29fac389c1947b127f3ca4a3e65 (main a bit before that merge), and then try "git diff 5d3f561d7dbcee370dc764cd5ba4210c62ce13dea" (diffing against that merge), I see what I'd expect. I think I was just confused by the revert, which prevented the expected source time updates (and hence the rebuild).

<rlb>(i.e. I see the changes to libguile/lightening/...)

<ekaitz_>everything looks right but the woodpecker file is kinda wrong there

<ekaitz_>that we need to fix, too

<ekaitz_>wtf

<rlb>OK

<rlb>By all means :)

<ekaitz_>this is hard, dude

<ekaitz_>so now it's getting harder, revert the merge and remerge with this strategy would work?

<rlb>I don't have any of the context, but If it's just one file, perhaps alternately just "git mv" that file -- unless that's going to cause trouble with future merges somehow (doubt it?).

<ArneBab>rlb: I think you saw only the diff to the one parent, not to the other. I also stumbled over that several times ☺ -- but please avoid submodules: they almost always cause more trouble than they avoid.

<ekaitz_>yeah...

<ekaitz_>okay prepared a revert and then I need to re-merge... let's see if git helps me

<ekaitz_>ACTION will have dinner first just in case

<rlb>If it's just one file moving, do we want that much complexity (we might, just wondering).

<rlb>?

<rlb>i.e. mess in the history.

<ekaitz_>i prefer to make a clean merge instead, because maybe we could have issues with later merges

<ekaitz_>because we would be externally adding things to the lightening folder

<rlb>OK, well, I'll leave y'all to it :)

<dsmith>ekaitz_, I often make a local copy (just cp -a) of the clone to try things that might be "dangerous"

<rlb>ACTION is quite fond of "git worktree"

<rlb>(along those lines)

<rlb>particularly handy for something like guile that takes a long time to bootstrap -- e.g. I keep separate main and utf8 worktrees, etc.

<dsmith>rlb, That shares git files though, doesn't it? Is it possible to damage the main worktree by doign something stupid?

<rlb>nope

<rlb>they're completely separate worktrees

<rlb>have their own HEAD, "everything" (fsvo everything).

<rlb>And you can "rm -rf" them when you're done (though git will only notice that, bookkeeping-wise after the next "git worktree prune").

<dsmith>So something like rebasing main that has already been pushed?

<rlb>They do share the same "branch namespace".

<rlb>just separate "worktree wise".

<rlb>i.e. there's only one local main branch, utf8 branch, etc.

<rlb>and you can only have any given branch checked out in one worktree at a time.

<dsmith>Ok, I gotta look into this.. Always something to learn.

<rlb>They share the same ~/.git/ dir (the one from the original clone), and that happens indirectly by having .git be a file in each worktree that "points" to the original clone.

<rlb>oops

<rlb>I meant ".git/" dir (ignore the ~) :)

<ArneBab>yes, you *can* damage the worktree and some commands don’t work correctly. At a repo so small as the one of Guile, I’d always just use a regular local git clone.

<rlb>Commands I use all the time there are "git worktree (create|list|add)", and less often "move|prune|remove".

<rlb>Hmm, what kind of damage?

<ArneBab>small off topic: it’s fun that git worktree is exactly the concept that bazaar advertised

<ArneBab>:-)

<ArneBab>rlb: like editing a file in .git by hand or a script running amok.

<rlb>Oh, hmm, I guess I don't really do that, or don't do it wrt the worktree-relevant bits.

<ArneBab>yes, it’s a really bad idea ☺

<ArneBab>(to run scripts on your .git if using worktrees)

<rlb>dsmith: it also mostly doesn't care where the worktrees are (roughly), so atm I tend to have say ~/src/guile/{main,utf8,...} where main is the real clone and the others are worktrees.

<rlb>I don't think I really ever run scripts on my .git/ content.

<ArneBab>I see worktrees as a workaround to avoid stumbling over not being able to push back into a repo that has the same branch checked out.

<rlb>For that i'd be more likely to use "git config".

<rlb>which should dtrt in many cases.

<rlb>I do hand edit sometimes.

<rlb>git worktrees almost entirely replaced the need for multiple clones for me (not entirely), but of course ymmv :)

<dsmith>Ah. .git is now a file, not a dir.

<rlb>right

<rlb>One important thing to remember is to not move those dirs manually :)

<rlb>i.e. use "git worktree move"

<rlb>afaik deleting them manually is fine, though you can use "remove"

<ekaitz_>rlb, ArneBab : #42

<ekaitz_>it was a pain in the butt to make

<ekaitz_>rlb: as you said, really both commits together are just a git mv

<jralls>Hi. I'm trying to build guile for mingw64. The Msys2 project has a build for Msys but I need to use it in a packaged program so I need it in mingw. After patching some compile errors (mostly casting things to scm_t_subr) I got it to build completely on Ming32.

<jralls>Mingw64 compiles all of the C code (with a few ptr-to-int of different size warnings) then fails in the stage0 compile of eval.scm with "ERROR: In procedure apply-smob/1: In procedure bytevector-u32-native-set!: Wrong type argument in position 3: 654452552"

<jralls>The stack trace is 15 instancess of (apply-smob/1 #<boot-closure XXXX ()> plus (primitive-eval ((@ (ice-9 control) %) (begin (# #) .))) at frame 14 and (bytevector-u32-native-set! #u32(1 0 5243149 45 62 85 .) .) at frame 3.

<jralls>The apply-smob/1 boot-closure arg at frame 2 is (_ . _)> # "b." . instead of just () .

<jralls>Source is git main at 7f0f63d08.

<jralls>Any suggestions about how to get some more information about what's going wrong where?

<dsmith>jralls, Take a look at https://codeberg.org/guile/guile/pulls/22

<dsmith>jralls, Not saying that will fix your issues, but that's a proposed fix for 64 bit windows.

<jralls>dsmith, roger, thanks. I'll give it a try.

<dsmith>jralls, Almost all guilers do not run windows...

<jralls>dsmith, That's true of a lot of F/LOSS projects. But real world apps like GnuCash (for which I'm a core dev) find most of their audience on Windows. We've been building Guile on Windows for a very long time.

<dsmith>jralls, Yep. wingo, who wrote the compiler, JIT, web stuff and lots more, got sucked into guile via GnuCash

<daviid>most lilypond users use ouindoze and mac ... those are a lot more users then guilers :-)

<jralls>PR#22 didn't build, there are some C compile errors. I'm out of time for today but I'll whack on it some more tomorrow.

<dsmith>Heh "ouindoze" first time I've seen that

<rlb>Hah, I had no idea -- I think I'm likely the culprit originally responsible for Guile being in GnuCash.

<dsmith> https://wingolog.org/archives/2010/04/02/recent-developments-in-guile#3262b9d06b9c03c87d1c82902123712fbf66ae46

<rlb>:)

<sam113101>guys

<sam113101>my REPL is extremely limited

<Arsen>as in, the line editing experience?

<sam113101>the arrow keys don't work for example

<Arsen>(i.e. no history etc)

<Arsen>yeah

<Arsen> https://www.gnu.org/software/guile/manual/html_node/Loading-Readline-Support.html

<Arsen>(or, locally, run: info '(guile)Loading Readline Support')

<sam113101>thank you my man

<sam113101>do you know if it's possible to add color?

<Arsen>should be

<sam113101>looks like I don't have colorized and it's not in the fedora repos ;_;

<Arsen>hm, I thought (set-readline-prompt! "\x01\x1b[34m\x02scheme@(guile-user)\x01\x1b(B\x1b[m\x02") would do it but apparently not

<Arsen>I apologize, I'm missing something

<Arsen>,o prompt "\x01\x1b[34m\x02scheme@(guile-user)\x01\x1b(B\x1b[m\x02" did tho

<Arsen>(and I realized I forgot to attach "> " to the end)

<sam113101>I want my code to be colorized, not just the prompt, will that work? https://gitlab.com/NalaGinrut/guile-colorized

<Arsen>ACTION never heard of it

<Arsen>probably

<dsmith>sam113101, You are slowly getting closer and closer to using emacs with guile

<Arsen>;)

<mwette>Anyone w/ aarch64 boxes running ubuntu or debian? Looks like lots of missing packages, including guile. (And on aarch64 ubuntu 24.04, emacs is a snap.)

<ekaitz_>sam113101: I use it, it works

<sam113101>ekaitz_: my prompt is the only thing that got colorized though, is that normal?

<ekaitz_>sam113101: yes

<ekaitz_>that's what it does

<ekaitz_>it also colorizes other kind of things like errors and such

IRC channel logs

2025-10-27.log