<daviid>sneek: later tell tohoyn fixed all but the last reported bugs and pushed on master, so after pull/make/install [the master branch] ... gtk-css-provider-load-from-data will work, as well as gtk-tree-selection-get-selected, which is now overridden, to return two values [not three], the model and either #f or the selected iter when one is selected <Kolev>Any GTK GUI apps written in Guile that I can see? <daviid>Kolev: both guile-gi and g-golf have a few examples intheir respective repo <Kolev>daviid: How do I run those on guix? <daviid>Kolev: not sure because guix still doens'thave (or had) gtk4, you'd have to ask on guix <sneek>tohoyn, you have 2 messages! <sneek>tohoyn, daviid says: yes, i am working on it - paused to fixed the bugs you reported - noeta, but working on it with ahigh priority ... <sneek>tohoyn, daviid says: fixed all but the last reported bugs and pushed on master, so after pull/make/install [the master branch] ... gtk-css-provider-load-from-data will work, as well as gtk-tree-selection-get-selected, which is now overridden, to return two values [not three], the model and either #f or the selected iter when one is selected <tohoyn>daviid: about the snippet I sent you recently: I looked at the Gio source code and it seems that g_simple_action_new accepts NULL as its second argument. So I guess that the corresponding guile procedure should accept #f as its second argument. <tohoyn>daviid: I ran the snippet with up-to-date master branch of g-golf <tohoyn>Is it possible to use schemas (GSettings) in a Guile G-Golf program? In C programs the compiled schema file is linked to the binary application. <jpoiret>daviid, Kolev: we've had gtk4 for ~ a month ***lampilelo_ is now known as lampilelo
<tohoyn>I think I found a solution for this. <tohoyn>note that the previous snippet needs some extra files to run. I can paste them if anybody wants. <tohoyn>daviid: it seems that G-Golf doesn't realize that <g-settings-action> is a kind of <g-action>. I get the following error: oop/goops.scm:1585:2: No applicable method for #<<generic> g-action-map-add-action (1)> in call (g-action-map-add-action #<<gtk-application> 7f7433ee0680> #<<g-settings-action> 7f7433ef98d0>) <lloda>what's the point of HAVE_COPYSIGN in numbers.c when it's used only once and elsewhere copysign is used freely <wingo>civodul: did you manage to get guile from git working for guix ? <lloda>wingo: mind if i push my patches directly on wip-inline-digits? <civodul>wingo: not yet, sorry; i'd need to fix the free-variable/autoload issue <civodul>(i also need to dedicate a few hours to this, too!) <wingo>i think before working on this patch series i had never used ldexp / frexp / copysign <wingo>gosh i am feeling great about no custom gmp allocator and no finalizers <wingo>rlb: how does guile in git break lokke ? <sneek>I've been running for 8 days <sneek>This system has been up 24 weeks, 5 days, 16 minutes <rlb>wingo: I'll have to try again (been wanting to but haven't had a chance yet),, but iirc it was a build failure caused by always inlining. <rlb>I'll see if I can get some time today. <drakonis>hmm, how do you daemonize code in guile? <wingo>civodul: not sure, i think you would rather want to check if the IFACE arg to imported-resolver is an autoload iface <wingo>because otherwise the resolve-interface at procedure entry of imported-resolver will trigger the unwanted behavior, right? <wingo>the issue is that guile's first-class module interface can't indicate the set of bindings that an autoloaded module will provide :( <wingo>civodul: also, don't autoloads have to be available at compile-time anyway? <wingo>or does syntax expansion somehow magically recognize that autoloaded bindings aren't macros <civodul>wingo: i think the assumption is that autoloaded bindings aren't macros <civodul>at least that's always how i've used it <wingo>psyntax will want to resolve all free bindings tho, right? <wingo>there's nothing that says "hey this module is autoload" <civodul>hmm something somewhere prevents the module from being actually loaded tho <wingo>and since expansion is before compilation i would have thought these modules would have been loaded <civodul>so currently you only get a warning at compile time but no attempt is made to actually load the module <civodul>or rather, if loading fails, it's just a warning <wingo>i think i am missing something <civodul>i think i'm missing something too :-) i need to focus, lemme see <civodul>ah yes, that's from make-autoload-interface <wingo>i think the change needed is a little different, will poke tomorro <wingo>i.e. basically the resolver should first look up the variable and only then attempt to determine its public name <wingo>loading modules in the second part <civodul>in the meantime i'll work around it to test the bignum branch