IRC channel logs

2025-06-26.log

back to list of logs

<wingo>ArneBab: not currently :)
<wingo>zomg
<wingo>so, the hash table implementation. hashq-ref will internally dispatch to scm_hash_fn_ref and pass hashq and eq as functions
<wingo>which, ok, probably the hash table should store its own hash functions, but, ok
<wingo>but it does so by casting scm_ihashq to scm_t_hash_fn
<wingo>the hash function is then invoked as hash (x, len, closure), where closure is user-provided data, to allow for user-supplied hash procedures
<wingo>but scm_ihashq only takes two arguments
<wingo>yolo
<civodul>wingo: ouch :-)
<civodul>in practice the 3rd argument goes in a register that just happens to be ignored
<civodul>so it’s prolly okay
<civodul>but not pretty
<dthompson>speaking of hash functions... just want to re-raise that hash code composition is currently commutative which is no bueno
<wingo>civodul: actually, just having upgraded my guix, i see that something changed in the default dialect making a number of these sloppy-prototype things to be an error
<wingo>anyway, fixing in source, it's better that way :P
<wingo>also... i just used _Generic for the first time
<wingo>lets me cast to scm_t_subr from a limited subset of types, otherwise errors
<wingo>ok! wip-whippet pins objects whose object or hashq is taken.
<wingo>am ready to write a trace function.... tomorrow
<wingo>then we get to try the moving collector
<dsmith>ACTION spins up the theme music for "The Jefferesons"
<rlb>wingo: there are the gcc 15-related issues: https://bugs.debian.org/1096788 (iirc there's also a guile bug).
<civodul>rlb: oh, would be nice fixing in ‘main’
<rlb>Depending on what you mean, I think it'd be nice to fix that in 3.x, whatever else we do, if it's not too hard.
<rlb>I haven't really tried yet, since it wasn't critical for debian (trixie).
<dthompson> wingo: exciting!!
<old>rlb: IRC, GCC 15 will soo break things. I think they changed some defualt 0 initializer in C for union or something like this
<old>> {0} initializer in C or C++ for unions no longer guarantees clearing of the whole union (except for static storage duration initialization), it just initializes the first union member to zero
<old>what an insane move to make
<rlb>I suppose if we need it, and there's a -fno-... option, we can detect/add it.
<dsmith>Or rearrange the union to have the largest member first
<dsmith>I can't think of any useful reason to only init the first member. Strange.
<identity>rlb: "use {} (valid in C23 or C++) or use -fzero-init-padding-bits=unions option to restore old GCC behavior."
<lechner>Hi, how may I discard bindings but keep the %load-path, please? I lose the latter with (set-current-module (make-fresh-user-module))
<sneek>Welcome back lechner, you have 2 messages!
<sneek>lechner, old says: the only language that puts `_` in their files is Python. Because their module system reflection works with Python identifier
<sneek>lechner, mwette says: dev-2.02 branch has your fixes, also fix to include libs from pkg-config: i'll need to do testing and plan to then release as 2.02.1 (i messed up 2.02.0).
<lechner>sneek / tell old / thanks!
<sneek>old, lechner says: / thanks!
<lechner>sneek / tell mwette / thanks!
<sneek>mwette, lechner says: / thanks!
<rlb>identity: thanks
<mwette>i did release 2.02.1
<lechner>mwette / yes, thanks! i saw it, built it, and am currently testing it
<lechner>sorry, too much Latin as a child
<dsmith>heh
<inline>veni compili testi
<inline>lol
<lechner>thanks for getting it!
<lechner>it actually would be vidi, compili, testi
<lechner>although veni works too
<lechner>sneek / later tell mwette / Hi, I'm getting compile-ffi: error: typedef not found for: "__u16" on this https://codeberg.org/lechner/guile-syscall/src/branch/history/scm/ffi/linux/fcntl.ffi but haven't investigated
<sneek>Got it.
<mwette>Hmm: maybe try adding "__u16=uint16_t" in cpp-defs
<sneek>mwette, you have 1 message!
<sneek>mwette, lechner says: / Hi, I'm getting compile-ffi: error: typedef not found for: "__u16" on this https://codeberg.org/lechner/guile-syscall/src/branch/history/scm/ffi/linux/fcntl.ffi but haven't investigated
<lechner>mwette / here is the version generated by 2.01.5 with my patches https://bpa.st/IC2Q
<lechner>unsigned-short all over the place
<lechner>mwette / my ffi file includes types.h which should pull in, locally, asm-generic/int-ll64.h
<lechner>or do i have to list it separately?
<lechner>the rule is that definitions from inclusions are available for processing but won't be exported unless added, right?
<lechner>mwette / okay, all good now! I added "asm-generic/int-ll64.h" in a bunch of places, and the errors went away. thanks for the new version!
<lloda>rlb, old: there's patch for gcc 15 https://debbugs.gnu.org/cgi/bugreport.cgi?bug=78464
<lloda>i haven't reviewed it
<mwette> The compiler has a lot of default defines. The ffi compiler uses a gcc command to extract those. There may be flags that are not passed. In this case you could try using CC env var (e.g., export CC="gcc -mfoo").
<lechner>mwette / thanks! all good now
<lechner>lloda / rlb / old / the C23 patch is straightforward but should probably be split up. for example, it also changes the way getpgrp is called (without an argument, which I think is right). i'm not sure "declarators" is a word, and "equivalent" is spelled this way i think
<humm>“declarators” is a word
<humm>scm_t_subr should probably be defined as void (*)(void), though