IRC channel logs
2025-11-20.log
back to list of logs
<humm>(looking at random files: Guile does require C99 or newer already) <rlb>Could be Andy told me c11, and I misremembered. <rlb>(now that I type that -- sounds even more likely) <mwette>I believe C99 or better required since 2.2.0. <mwette>But maybe revisit min required, and max supported, C. <mwette>ACTION released nyacc-3.00.2 on github and savannah <daviid>sneek: later tell tohoyn on the paste of the d-bus example your are trying, line 71 you call on-name-acquired, but it is not defined, could you paste a def so I can further try ... tx <daviid>sneek: later tell tohoyn dito line 73, you call on-name-lost but it is not defined ... <daviid>sneek: are you sleeping or what? <daviid>it took a couple of seconds to respond ... could be my internet though ... <dsmith>daviid, the log in this irc client shows the but reponding within the same second <rlb>OK, I fixed the -std=gnu17 issue in main (configure automatically adds it if it's available, restoring, for now, the arrangement before GCC 15). <dsmith>rlb, Hmm. I wonder if that works with clang also <humm>clang knows -std=gnu17 as well <rlb>It should -- if clang supports the option, we'll add it, but I assume it doesn't. I did test what happens when the option is not supported. <rlb>(assuming clang implements it similarly enough) <rlb>I can test with clang if we're concerned -- not sure I've ever tried that. <rlb>Hah, I'd assume you can just ./configure CC=clang <rlb>oh, I'd forgotten that (if I'd noticed). <mwette>I think clang has been making itself more gnu compatible over the years. lldb actually accepts lots of gdb commands these days. <dsmith>Well, ./configure added CFLAGS -std=gnu17 <rlb>Imagine you know, but you can see the full command line via "make V=1 ..." <rlb>or I guess gmake there :) <dsmith>Didn't complain. Still gets the same prototype warnings <rlb>Sure -- main thing is that it doesn't crash hard on the foo() prototoypes, etc. <dsmith>"Warning: passing args to a func without prototype is deprecated in all versions of C and not supported in C23" <rlb>...right -- that's one of the main things we're going to have to fix, or just wait for Andy's fix. <dsmith>But yeah, it did pass the gnu-17 arg <rlb>thanks for the testing <dsmith>Personally, I try to run -Werror if possible. One place I worked had *hundreds* of warnings. How do you see the one that is important? <rlb>I tend to favor it too, but perhaps locally, not as the default (e.g. in a release) -- unless you insist on a very narrow range of compilers (c-world-wise). <dsmith>True. Stuff that can build in a variety on environments is different that is for a specific embedded system. <rlb>When developing, though, I'm typically happy to have it on, and to fix whatever it's yelling about. <ArneBab>sneek: later tell civodul: thank you! <lloda>imo we should fix the gcc 15 problem asap and not wait for the new gc branch to be merged. That isn't going to happen soon, it'll be 4.0 and it'll probaby cause some breakage. 3.x should work with gcc 15 <lloda>the patch that was sent to the list looked good to me at the time <Arsen>this should be set if we're in C23+, no? <ArneBab>can it be a problem that we omit the L ⇒ int vs. long comparison? It’s still correct, right? <ArneBab>If it is, then the fix for GCC is in main already ⇒ need to release 3.0.11, then it’s in. <Arsen>that falls outside the smallest int range permissible by the standard so it may be wise to include L <identity>is there any system that has Guile support *and* 16-bit ints? <ArneBab>the lib/verify.h was already in 3.0.9, so if it makes problems, those should already appear with 3.0.9 on C23. But since that didn’t build on C23 due to jit.c, I don’t know whether that says much. <sneek>tohoyn, you have 2 messages! <sneek>tohoyn, daviid says: on the paste of the d-bus example your are trying, line 71 you call on-name-acquired, but it is not defined, could you paste a def so I can further try ... tx <sneek>tohoyn, daviid says: dito line 73, you call on-name-lost but it is not defined ... <tohoyn>daviid: I'm planning to implement method handling in the server but I haven't done it yet because the object registration does not work. <tohoyn>daviid: semi-opaqueness is a G-Golf concept and it is not define by GObject introspection. so the lack of constructors for GDBusInterfaceInfo is probably not a design bug in Gio library. <tohoyn>daviid: is there some reason why arguments of type GDBusInterfaceInfo (and other semi-opaque struct types) can't be serialized like nonopaque structs? <dsmith>Guile hasn't supported 16bit since it was forked from SCM deep in the mists of time <lee-thomp>Hi all, what would be the best approach for porting https://nas.sr/%D9%82%D9%84%D8%A8/ to Guile as a new language? My goals are to handle Arabic numerals as expected and to parse symbols regardless of vowel diacritics, which are largely optional in written Arabic. I've made an attempt by using the standard `read' and then stripping diacritics from symbols and parsing numerals (https://codeberg.org/lee-thomp/guile-qalb), any advice <humm>lee-thomp: Cool! Doesn’t that language have an entirely different syntax, though? If so, you probably need to actually write a parser instead of using (read). And then translate it to some other of Guile’s languages. <humm>since the original seems implemented in JS, to have more fun playing around with Guile’s languages, you could try to modify the original parser and Guile’s ECMAScript compiler until they work with eachother <identity>also see (info "(guile) Writing New High-Level Languages") <daviid>tohoyn: as said, the annotation doesn't provide info to serialize/de-serialize semi-opaque struct - you can try to use make-c-struct parse-c-struct - I won't be able to help much this moment, sorry <daviid>tohoyn: wrt callback arg list, it is given by the callback annotation, and generally the C last arg, user-data, isn't passed/used by lang bindings <daviid>if/when you get something working let me know <Codeko>I'm building an Emacs-like environment in Guile and need variable docstrings like elisp has. Guile's define doesn't support docstrings for variables. What's the recommended approach ? <ekaitz>but it looks like procedures have properties but variables don't <ekaitz>there's some source-properties thing though <rlb>(Oh, and I'd forgotten about the comments in there, e.g. the issues I hit with object-documentation.) <rlb>yeah, not sure what got in to me... <rlb>I'd quite possibly be working on support for the latter right now if there was a consensus that it was "the way". <rlb>(Though unless it's easy/isolated enough, if I'm sane, I'd probably want to wait until the utf-8 question is settled -- haven't looked in to it enough yet to have a good idea.) <Codeko>rlb: That works like a charm thank you! I'm still a Guile noob, don't know many things yet <rlb>(though I did also rebase it onto current main before testing) <rlb>Just added some guidance wrt the 32-bit big-endian build issue to the README, i.e. how to handle it for now. <rlb>civodul: created next-y-release and next-z-release milestones (and added the 32-bit/be build issue to the former -- aspirationally...) <rlb>Checked libguile/.libs/libguile-3.0.so via abidiff wrt a built v3.0.10 tree and main, and assuming I did it right[1], it reports no differences. Cross checked via /usr/lib libguile 2.2 and 3.0, where, as expected, it did report differences. <rlb>[1] think it may be the first time I've used abidiff <rlb>...I just checked my main env, which (unsurprisingly) is amd64 <rlb>I wonder if we could/should add that to CI so it's always visible in the logs and we can just survey. <rlb>I guess that'd need to be a separate test since it'd need to know what it's diffing against. <rlb>presumably main would be diffing against v3.0.10 atm <mwette>yes. I think makes sense for the win64 update, but not sure applicable otherwise. <rlb>Well, we need to know right now for "all archs" for the release check? <mwette>but applicable for 32-bit update also <rlb>i.e. I thought your point was that I really ought to be checking it "everywhere". <mwette>I was thinking the 64 bit windows update should ideally not alter the non-windows ones, and the 32bit fix should not alter the 64bit ones. <rlb>Oh, I'm talking about the 3.0.11 vs 3.0.10 release check in general. <rlb>i.e. irrespective of when we decide to merge the win* changes. <mwette>I would expect those to deviate, in general. Or are you looking to validate on which objects the changes are? With lto all things could happen, I guess. <rlb>I thought abidiff prev.so new.so was supposed to report (at least) "public" api changes, and at least here, for 3.0.11, there shouldn't be any (or shouldn't be anything but maybe new symbols). <rlb>And that's what I saw. <rlb>Of course I saw a lot of output for 2.2 vs 3.0 <rlb>I thought your point was just that we really needed to test more than just my one platform because the abi can vary per-platform. <rlb>(which offhand, sounds right to me) <mwette>right. I am not super-familiar with abidiff. <mwette>maybe a good test for .Z updates? <rlb>I suppose it a more expensive test, since it requires an additional, otherwise unneeded bootstrap build -- unless we have "previous release" artifacts we can use. So we might want it to run "less often", e.g. perhaps just daily rather than on every commit or something. <rlb>On the other hand, it'd be a great thing to know before merging prs if we could "afford" it. <rlb>Most of the time, I might really just want/need it on-demand -- (at least) once before merging a pr, definitely before a release, etc. <rlb>If nothing else, I might see about adding it to the debian tests, which will cover a lot of architectures "eventually", but wouldn't be useful for upstream guile releases unless I started trying to test them in advance via debian experimental... <rlb>OK, debian 32-bit/be (powerpc) abidiff against current deb 3.0 package's libguile is also clean (that was easy, since I already had the schroot built from the earlier testing). I'll check s390x (64-bit/be) too and maybe call that enough for now. <rlb>mwette: thanks for the nudge. <mwette>rlb: yw. Thanks for all the hard work on this. <rlb>civodul: in case it's useful -- I happened to run abidiff on s390x on the win* (#22) pr, rebased on current main (forgot that was the worktree), and it filtered out the scm_t_hash changes as "harmless". <mwette>rlb: What does "compatible type" mean? <mwette>I assume that means they resolve to the same base type. (In C, typedefs are aliases.) <rlb>dunno, apparently it's "--harmless" ;) <humm>rlb: /compatible types/ is a concept of the C standard which lets distinct types be used in certain contexts; for example, a `struct s {int i;}` in one translation unit is a distinct type from an equal `struct s {int i;}` in another translation unit, and yet you can pass one to a function expecting the other <humm>and int[42] and int[] are distinct but compatible types, so you can define `int a[42];` in one translation unit and declare it as `extern int a[];` in another with defined behavior <humm>in C17, `void()` and `void(int)` were distinct but compatible function types, so you could call a function defined as `void f(int i){}` as `void f(); f(42);` <humm>this abidiff message is false: scm_t_hash is the same type as uintptr_t, which may or may not be the same type as unsigned long; if it is the same type, the return type has not changed on the platform; if it is not, the return type is in all likeliness incompatible, even if it has the same size (but that probably doesn’t matter, as the ABI probably doesn’t distinguish between incompatible types of the same size) <humm>(that is, unsigned long and unsigned long long are incompatible, even if both happen to be 64 bit wide) <mwette>humm: Thanks for the explanation. <dsmith>rlb, So this 32bit big-endian problem. Could that be caused non-aligned mem access? <rlb>no idea, it ends up (iirc) with a segfalt <dsmith>Does it requier real hardware? or does it also happen in an emulator? <rlb>Hmm, don't know and can't recall if I've ever tested that in a vm, but I'd guess it doesn't require real hardware. <rlb>I do have some vague recollection of maybe setting up a qemu powerpc vm, but don't know what for. <daviid>sneek: later tell tohoyn I found why it is not working. could you edit the (g-golf support struct) module and comment the line 107, using #;, so it becomes this - #;(string-prefix? "GDBus" g-name) - save, compile/install g-golf <daviid>sneek: later tell tohoyn then use this version of your test - https://paste.debian.net/1409664/ - given I saved it as d-bus-server-test.scm, chmod a+x d-bus-server-test.scm, you can run passing (if you wish) -d, as in ./d-bus-server-test.scm -d this will print g-golf core precious info as you are debugging ... <daviid>sneek: later tell tohoyn please note that I had to change your GDBusInterfaceInfo name, "FiTohoynDBusServer1" is not a valid name, not knowing what I am doing here, I picked the one in the doc, but for info, your name must pass the test, i.e (g-dbus-is-interface-name "org.freedesktop.DBus.Properties") => #t, but (g-dbus-is-interface-name "FiTohoynDBusServer1") => #f and that raises a Gio CRITICAL ... <daviid>sneek: later tell tohoyn I am sure why I tag GValue and Graphene struct as semi-opaque, but I can't remember why I also tagged DBus - even when I comment as suggested above, both the g-golf test-suite and all gi-marshalling tests still pass ... so I may patch 'for real' and release ...