IRC channel logs

<mwette>rlb: Did you check the content in Guile's README, re: freebsd? I contributed that section several years ago.

<rlb>mwette: thanks -- problem was that I was invoking make, not gmake. We should just force an error or something because the failure with make is mysterious.

<rlb>I might try to come up with something later.

<humm>Would it be possible to let automake generate a GNUmakefile.in and not have a Makefile at all?

<rlb>looks like we also require makeinfo now, but don't test for it in configure.

<humm>but we do (but the test in configure and the MAKEINFO used by the Makefiles arw independent, which seems bad)

<humm> https://codeberg.org/guile/guile/src/branch/main/configure.ac#L196

<rlb>The tests fail when run in parallel, but are fine when serial -- fail in web-server.test after 16 retries with ECONN.

<rlb>(repeatable)

<humm>(so, for example, I believe `./configure MAKEINFO=gmakeinfo` will still test for `makeinfo` but use gmakeinfo)

<rlb>OK, haven't looked -- "pkg install texinfo" does "fix it".

<humm>I’ve had trouble with web-server.test as well, with an EINVAL I believe, repeatable … till I rebooted and rebuilt and it stopped failing somehow

<humm>rlb: judging from the comment at the top of GNUmakefile, it sounds like non-GNU makes should work as well for most things

<dsmith>rlb, That worked fine for me

<dsmith>Ah, yes. Need gm4 and gmake

<dsmith>rlb, Also, you must use the correct libgc

<rlb>...yeah, I was just calling "make" not "gmake", and I needed texinfo.

<rlb>But the web-server.test is still broken with -j

<dsmith>Hmm.

<dsmith>Was passing for me at the time.

<rlb>Here it's a freebsd vm I've had around for a while for testing bup; not sure what version it is offhand, so I suppose that could also be relevant.

<rlb>(also vm + networking...)

<dsmith>I was at v3.0.10-250

<rlb>Hmm, what's the freebsd equivalent to "cat /etc/debian_version"...

<rlb>ahh, uname -a says it's 14.1-RELEASE

<dsmith>cat /etc/motd ?

<rlb>Yeah, same thing.

<dsmith>I'm on 14.3-RELEASE

<rlb>Guess I could try a newer vm -- could create a new one; don't know how to upgrade a freebsd system across Y releases.

<rlb>would *really* would like to figure out a ctrl:nocaps equivalent for the bsd console

<rlb>Keep shouting at it :)

<dsmith>heh

<dsmith>I've got that tuned up in the windows host keybaord.

<dsmith>Made caps lock just plain olf shift

<dsmith>And moved caps-lock to right-control

<dsmith>And then in X I map caps-lock to Hyper

<dsmith>(Couldn't figure out how to map to Hyper directly)

<dsmith>Or is that Super?

<rlb>What I'd really like to try is the caps2esc arrangement, and there's an interception tools module for that, but I'm very hesitant about random root-level keylogging -- with that, transient capslock use is esc, chording is control.

<dsmith>It's Hyper

<rlb>keylogging -> mangling, capture, etc.

<rlb>Though it's probably fine...

<dsmith>The caps-lock move is in the keyboard directly for me

<rlb>right

<rlb>basically, I wish sway could just handle it directly :)

<mwette>cat /etc/os-release ?

<dsmith>Hm. I am seeing a broken pipe now that I didn't see before (same code though)

<rlb>thanks, though uname -a is probably fine

<dsmith>gmake -j$(nproc) check

<dsmith>And it's the 00-repl-server test

<rlb>boo

<rlb>?

<rlb>:)

<rlb>ACTION thought you fixed that

<rlb>might add texinfo to the README advice

<rlb>wrt pkg install

<dsmith>Indeed. But my clone there was not up-to-date. Rebuilding...

<rlb>that'd do it

<rlb>I haven't seen a problem there since, so pretty happy about that.

<dsmith>Bah. Had some leftover junk. Restarting from git clean -dxf

<dsmith>build done

<dsmith>Ok!

<dsmith>Did 10 "nice gmake -j$(nproc) check" with no problems

<dsmith>rlb, ^^

<dsmith>After a fresh git pull

<rlb>Thanks -- if I get time, I'll have to see what's going on, or I could try 13.4 and see if that makes a difference.

<dsmith>And that's with ./configure --with-bdw-gc=bdw-gc-threaded

<rlb>my vague guess would be that the test is colliding here wrt ports or something similar, but dunno.

<rlb>I did the same configure.

<dsmith>Probably a 14.1 -> 14.3 difference?

<rlb>EIDEA :)

<dsmith>??

<rlb>"no idea"

<dsmith>Ahh

<dsmith>This is clang 19.1.7

<dsmith>Complains about () func arguments

<rlb>For gcc 15+ we now need -std=gcc17

<rlb>fwiw

<dsmith>I *think* some of the new stuff in 14.1 is the posix-spawn stuff.

<dsmith>ACTION looks

<dsmith>Nothing jumps out at me from the release notes

<dsmith> https://www.freebsd.org/releases/14.2R/relnotes/ and https://www.freebsd.org/releases/14.3R/relnotes/

<rlb>I figured it might also be related to kvm networking "somehow", unless you're doing the same thing.

<dsmith>I'm running under vmware

<dsmith>With the virt ethernet bridged, not nat

<dsmith>(shou;dn't make a difference..)

<rlb>(I'm sure mine's nat.)

<dsmith>Looks like those posix_spawn_*_np things were added in 13.1

<ArneBab>rlb: I’d like to merge the "build on windows 64" PR -- it’s reviewed by multiple people and the tests pass on Linux (Guix). A last test I’m doing is to run the benchmarks whether there’s a significant change.

<ArneBab>rlb: is that still OK at the current step of the release process?

<ArneBab>rlb: I found no performance regression with https://codeberg.org/guile/guile/pulls/22 ⇒ OK to merge?

<tohoyn>sneek: botsnack

<sneek>:)

<sneek>tohoyn: Greetings :D

<tohoyn>daviid: I have a problem with passing a struct argument to an introspected function, see https://paste.debian.net/1409430/ for the code and https://paste.debian.net/1409432/ for the error output. The error is caused by the third argument to procedure gd-bus-connection-register-object-with-closures2, line 52. If you want I can debug this myself. Or is there some special way semi-opaque or opaque structs shall be passed to introspected

<tohoyn>functions?

<optimal>does anyone know where i can find the version of guile-wiredtiger as documented in https://a-guile-mind.github.io/wiredtiger/ ?

<optimal>the package in guix seems to provide only the (wiredtiger wiredtiger) module and nothing else

<tohoyn>daviid: the problem may be that the GDBusInterfaceInfo is declared semi-opaque but Gio does not provide any functions to create an instance of it.

<chrislck>ACTION hopes guile-on-win64 can complete soon

<daviid>tohoyn: didn't closely looked at the code yet, but the error shows that it expect a pointer to ... the semi-opaque and opaque tags are there so the struct isn't deserialized, as there are missing info to do so - i so far never encounter to have to pass a semi-opaque (pointer to) struct, but if you have to, you have to write and bind a C snipset of call make-c-struct (if you know what to place where the structdef info is missing)

<tohoyn>daviid: ok

<daviid>tohoyn: it is suspicious that you would have to create one yourself

<tohoyn>daviid: is this a design bug in the Gio DBus library?

<tohoyn>daviid: see https://gi.readthedocs.io/en/latest/writingbindableapis.html

<daviid>i very mucg doubt so -

<daviid>yes, not sure what you are doing, not familiar with dbus either, but what ever you are trying to do should be feasible using their api, w/o making a semi opaque struct ...

<ieure>I wrote an Emacs library to make D-Bus less horrible to use, you might find some inspiration there. https://codeberg.org/emacs-weirdware/debase

<ieure>It uses Emacs' D-Bus bindings, so not a 1:1, but they seem like fairly thin wrappers over the native stuff.

<tohoyn>daviid: I'm writing a simple DBus server using the Gio DBus API. The example server (C program) uses function g_dbus_connection_register_object to register objects, too.

<tohoyn>ieure: I made a simple client with Emacs DBus library, tool

<tohoyn>s/tool/too/g

<tohoyn>daviid: My goal is to make DBus support to Theme-D, too.

<daviid>tohoyn: i am not gona be very helpful here, but there is no bug in g-golf and you should not have to make opaque, nor semi-opqaue struct yourself, tha's all i can dssay

<daviid>*say

<tohoyn>daviid: ok, I agree with you that this is not a G-Golf bug.

<daviid>tohoyn: why do you import (rnrs)? you may hide display to avoid the warning

<daviid>and newline

<tohoyn>daviid: I use rnrs for exception handling, among other things

<daviid>tohoyn: g-golf already imports GLib "Variant" and "VariantType"

<daviid>i'll look at your code closer later today, have to go afk ...

<daviid>i have to learn a bit about dbus, it seems everyone wants to use it :-)

<ieure>It sucks.

<tohoyn>daviid: another possible bug: Gio callback BusNameAcquiredCallback is declared to get three arguments, see https://paste.debian.net/1409456/. But the callback procedure works only if it takes two arguments. To see this, add a third argument to procedure on-bus-acquired (line 36) in the example server. You should get error "Wrong number of arguments".

<daviid>tohoyn: don't use dbus :-)

<daviid>ieure: yes :-) I wonder why people want to use it

<identity>for all their desktop bus needs i would imagine

<ieure>daviid, I wonder why people want to use a good number of modern Linux infrastructure, it all seems godawful to me. systemd, pulseaudio, d-bus, polkit.

<identity>d-bus is not exactly the nicest implementation of the idea, but it is far from godawful

<rrobin>i guess the awfull part is troubleshooting it

<ieure>The awful parts are that it's all XML, security is bolted on, documentation for the interfaces is autogenerated and lacks much needed to use it in practice, it's difficult to juggle multiple interfaces on a single object, and services have wildly inconsistent behavior.

<ieure>Which is most of the core implementation.

<ieure>Example, PulseAudio "supports" D-Bus. But it runs its own bus instead of attaching to the system or user bus. Instead, it exposes a stub D-Bus interface that does nothing except return the path for the actual bus. This is very different from the majority of D-Bus things.

<dsmith>Yeah, when I first encountered it years ago, I thought the actual protocol and idea was pretty cool, but you needed all the XML goo on top to know messages and stuff. Typical "now you have two problems"

<ieure>Yes, the idea is fairly solid, the implementation leaves *much* to be desired.

<humm>last I looked I believe the dbus spec itself still had todos left in it

<dsmith>heh

<ieure>It is nice not to have to fork and exec unix utils and parse their output to build UIs on top of this stuff. And it handles permissions for things like mounting/unmounting disks, so your user doesn't directly need those. Those are nice things.

<humm>the idea of a single bus instead of, say, a socket per service is questionable as well

<ieure>I can understand that, it seems like a hassle to mange N sockets per service per user.

<humm>if it’s a hassle you could write a library for it

<rlb>ArneBab: I think that's a change where I'll want to defer to civodul or wingo. If we do merge it, I'll probably want to double-check it on s390x and/or powerpc. Might also be good to double-check a *bsd too.

<ayys>Hey guys, quick API design question: Is it better to keep module exports short and assume users will use #:prefix if needed, or should I namespace them myself e.g., (cat/make) instead of make + (use-modules ((cat) #:prefix cat/))?

<ayys>hrm I wonder, is there are a naming standard documented somewhere?

<identity>ayys: definitely keep them short, if the users want the short names they would need to do a renaming dance, even if they do not collide with anything

<identity>s/they do not collide/names do not collide/

<identity>users generally do not collide

<ayys>interesting. so I assume using prefixes is an accepted practice in the community?

<identity>ayys: if the prefixes are not baked in, sure

<identity>they are generally not used unless there are collisions

<identity>the naming style is generally not much more than «they should be english words separated by hyphens». a ‹?› goes at the end of predicates; ‹!› at the end of mutating procedures, fsvo mutating. i have also seen (and used) a ‹?› at the start of a symbol to indicate replace a ‹maybe-› prefix, as in the variable may be #false.

<identity>err, ‹?› as a prefix, instead of ‹maybe-›, to indicate that the variable may be #false

<ayys>Awesome! So I'll go with specifying concise names and let the user handle collisions.

<ayys>Although, I am still kind of uncomfortable putting names like `make` into the global scope for unaware users.

<identity>sometimes you have to check whether something supports mutation, so you end up with names like ‘port-has-set-port-position!?’

<identity>in such situations, i read the ‹!?› as «wow, what»

<identity>ayys: usually if a collision happens the scheme implementation will print a warning/raise an error to let the user know

<ArneBab>rlb: ok -- do you know who can do the check on the non x86_64 hardware and on *bsd?

<ayys>identity: thanks for the help!

<rlb>Oh, I figured I probably would if we end up wanting to merge it, or after it was merged, but suppose I could try to do that sooner.

<ArneBab>rlb: I think if there is no breakage, we really want to merge that, because it simplifies things a lot for lilypond (they currently build with a patched Guile). We should get towards a state where Liliypond can build directly from our unpatched source again.

<rlb>But that can happen independently / in parallel with checking whether it's OK for main right now.

<ArneBab>so what’s still missing for merging the windows 64bit fixes¹ is an OK from wingo or civodul? ¹ https://codeberg.org/guile/guile/pulls/22

<rlb>Sure, but as mentioned, I'd also want an opinion from Andy or Ludovic for that, were I involved.

<rlb>I'd say let's get their opinion, and I'll plan to test those other cases. Then "up to y'all" as far as I'm concerned :)

<rlb>If you don't hear back from me wrt the testing in the next couple of days, please feel free to ping me.

<ArneBab>Thank you!

<rlb>certainly

<civodul>rlb, ArneBab: just left a comment; overall LGTM, i think it just needs careful checks to ensure there’s no ABI breakage

<civodul>quite a few people already commented actually so that’s great, no need for the old farts ;-)

<rlb>Right - it was mainly the abi breakage question that I haven't and am not planning to try to figure out. If others are "sufficiently happy" there, then no worries.

<rlb>I'll go ahead and test s390x and powerpc too -- should manage that in a day or two.

<rlb>(Though I suspect they won't be affected.)

<civodul>if there are doubts about the ABI, perhaps it’s best to skip

<rlb>I have no well-founded opinion there either way -- i.e. I wasn't intending to take responsibility there, investigate it well, etc.

<civodul>ok :-)

<rlb>(It might be just fine.)

<civodul>someone™ should take responsibility, or this can be left for later

<rlb>sneek: later tell civodul - I should have just tried it. Having configure autodetect and add -std=gnu17 when available is trivial, so I'll just plan to add that to main.

<sneek>Okay.

<rlb>The README notes we were going to need were about the same length...

<humm>why gnu17? what is it using right now?

<rlb>gcc 15+ has switched to gnu23 as the default (from gnu17), which we can't handle, so for now, this just restores the status quo.

<rlb>Andy has a full fix in wip-whippet, but it depends on c99, which I think 4.0 is going to require.

<humm>What does “depends on c99” mean?

<humm>“breaks with C11 or newer”?

<rlb>requires c99 features

<rlb>Generic, etc.

<rlb>iirc

<humm>// comments, declarations mixed with statements?

<rlb>_Generic