IRC channel logs

2020-06-08.log

back to list of logs

***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?
<daviid>apteryx: passwd:uid
<apteryx>thanks! (passwd:uid (getpwnam "username"))
<daviid>wc!
***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
<tohoyn>daviid: your example works fine
<tohoyn>daviid: I may have asked this from you before but could you look at https://savannah.nongnu.org/task/?15647 and tell me what is wrong with the project licenses?
<wingo>o/
***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)
<tohoyn>and (describe ...)
<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
<dsmith-work>{appropriate time} Greetings, Guilers
<guix-vits>sneek: tell dsmith-work Hi :D
<sneek>dsmith-work, guix-vits says: Hi :D
<mwette>the link for the logs now gives me "502: bad gateway"; anyone else get that?
<mwette>^ that is http://logs.guix.gnu.org/guile/
<guix-vits>mwette: logs.guix.gnu.org (w/o guile) gives 502 to me and butterypancake (#guix)
<dsmith-work>Yes, 502 for me
<mwette>thx
<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> http://logs.guix.gnu.org/guile/ fails for me, today
<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'
<sneek>Got it.
<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 ...
<sneek>Okay.
<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
<sneek>Will do.
<daviid>sneek: later tell tohoyn of course that list will evolve in time ...
<sneek>Will do.
<civodul> http://logs.guix.gnu.org/guile/ is back up! (but slow)
<ArneBab>daviid: ok
<mwette>civodul: thanks for the log fix
<civodul>yw!