***gwroalyf is now known as guix-vits
<daviid>should g-golf accept '() and #f or stricktly '(), wdyt? here is an example is gtk-init, (gtk-init 0 #f) and/or (gtk-init 0 '()) - fwiw guile-gnome would even accept (gtk-init #f #f) <daviid>this is a bit of a 'symetric question' to the one we previusly spoke about hre, wrt gi->scm that return a list, and now return '() not #f, when the gnome lib returned NULL ... <daviid>ok, I'll ake those to only accept '() - till now, this was the case for all but one, scm->gi-gslist to name it, so I'm goig to make it stricktly accept lists not #f anymore <daviid>actually argv is 'tagged as an array of utf8, not a glist, so even after this change (which only affects functions that accept GList/GSlist, users will still be able to (gtk-init 0 #f) or (gtk-init 0 '()) - but from now on, for functions that expect GList/GSList, g-golf will raise an exception if passed #f, users must pass '() instead <str1ngs> daviid for lists I prefer '() +1 here for that. <daviid>str1ngs: ok, all situations have been solved wrt returned values, but I realize I still do not 'enforce' '() for function calls - what I did so far affects direct calls to scm->gi (commit de41195), but funcall args are preprocessed in prepare-gi-args-in, which still accept #f for those args tagged as 'array, 'glist, 'gslist', 'ghash, 'error, 'utf8, 'filename and 'void <daviid>str1ngs: this is just to say that to achieve 'in/'inout arguments 'strict' enforcement to lists only, '() - not #f - for those tagged arguments, to pass %null-pointer (which is ok only if the argument has its 'maybe-null? slot value being #t), I need to review the 'preprocessing' code that occurs in prepare-gi-args-in <daviid>so at this point the question 'still is opened', should g-golf enforce, for those tags, that expect a list 'on the scheme side' of things, strict lists or accept #f as well ... ***wxie1 is now known as wxie
<apteryx>how can I query the integer user id given a user id string? <apteryx>thanks! (passwd:uid (getpwnam "username")) ***wxie1 is now known as wxie
<daviid>tohoyn: I just push a series of patches, and now child properties g-value are 'hidden' to g-golf users, please pull, make and test ... here is a concrete en example, based on yours ... https://paste.gnome.org/pw7blrnnw ***apteryx is now known as Guest22959
***apteryx_ is now known as apteryx
<tohoyn>daviid: gtk-container-child-get-property is not handled correctly. It takes four arguments last of which is a gvalue. <tohoyn>(gi-cache-ref 'function 'gtk-container-child-get-property) <guix-vits>tohoyn: maybe this parson on savannah need an ``Use a license compatible with the GNU GPL, and use the __"or any later version"__ formulation in your license notices.''? <daviid>you should not pass tha last arg, see the example ... <tohoyn>daviid: yes, but Theme-D-Golf uses the introspection data and it has to be correct. <tohoyn>daviid: because Theme-D is statically typed <tohoyn>guix-vits, I already have "or (at your option) any later version" in my license notices. <leoprikler>for the record, guile-gi accepts #f for NULL and also allows omission ***guix-vits is now known as gwroalyf
***gwroalyf is now known as guix-vits
<sneek>dsmith-work, guix-vits says: Hi :D <mwette>the link for the logs now gives me "502: bad gateway"; anyone else get that? <guix-vits>mwette: logs.guix.gnu.org (w/o guile) gives 502 to me and butterypancake (#guix) <ArneBab>daviid: did g-golf already warn when it got #f? If not then throwing an error on #f sounds like it could break existing programs. <ArneBab>daviid: is there a way to give compile-time errors for all places where someone used teh old version? <ArneBab>wow, after fixing pull: The news headlines are awesome! <dsmith-work>daviid: (I haven't been paying attention to this discussion so far) For this GList/GSlist stuff, are these exposed to Scheme as scheme lists or as some other type? ***hugh_marera_ is now known as hugh_marera
<daviid>ArneBab: fwiw, before 1.0, I allow myslf to change anything at anytime - althought things are prtty 'stable' now, from a user point of view I mean, iernally, thunderstorm every day here :):) <daviid>dsmith-work: the #f for NULL debate, not only for GList/GSList, for 'in and 'inout rgument still is 'open' - not sure yet ... <daviid>sneek: later tell tohoyn g-golf introspection data is perfectly correct :), as a matter of fact, procedures that override any typelib function _do_ use the imported version and the cache holds on scheme representation of GI 'objects' <daviid>sneek: later tell tohoyn as said earlier, you are not supposed to use/depend on g-golf internals anyway, thay may change anytime, you do this 'at your own risks', which is ok, but g-golf does not bear any obligation wrt. now, if you do, you'll have to adapt ... this said, what we are talkg about now is _not_ a change in g-golf internal representation but the adition of an override mechanism ... <daviid>sneek: later tell tohoyn so, it appears to me that you need to think and implement your own theme-d override mechanism ... fwiw, overriden functions are listed in %gi-override, (g-golf override override) module <daviid>sneek: later tell tohoyn of course that list will evolve in time ...