<gmaggior>Sorry, can a guile .scm file can be compiled into a standalone executable? <sneek>Welcome back daviid, you have 1 message! <daviid>gmaggior: what we do, is we write a guile script with --no-auto-compile -e main, that is minimal and import compiled modules - this way, for a user, it looks like it's an applcation, so to speak <daviid>str1ngs: the thing is that the scheme representation for NULL is #f, not '() - it is so much 'spread' in GI, that I think it is better to stick to that 'definition' <gmaggior>daviid, many thanks! I'm checking it out <daviid>str1ngs: to be 'consistent', otherwise what is NULL for string(s), #f or "" ... I thing by sending the message to g-golf users that NULL 'is' #f and #f 'is' NULL (converted to/from ...) is 'more reliable' (?) <daviid>gmaggior: welcome - what tells the autotool chain to install 'foliot' as a script is in Makefile.am, line 77 <daviid>str1ngs: I had a guix clone, and did pull today, it seems that all it takes to prepare a patch is to change the commit variable then the (sha256 (base32 ...)) expression I guess ? <daviid>str1ngs: i see they added ("gettext" ,gettext-minimal) depency - which is a bit of a surprise, I don't use it ... would that be because of texinfo? showing my ignorance here ... foliot does use gettext, but not g-golf, nor guile-cv ***catonano_ is now known as catonano
<str1ngs>daviid I think gettext is for bootstrapping configure.ac <str1ngs>daviid: in the case of GList* I'm use to '() not #f. I think this might be easier to use from a coding stand point. Since it's more useful to get length of the list then to have to handle two different types? Just my thoughts I can work around it around it. so your call. <daviid>hum, in this case, it should be 'covered' by the autoconf/automake dependency, just curious, no big deal here <str1ngs>I don't think autoconf or automake provide gettext. the gettext macro is something that only comes up with because of guile.m4. I can double check that dependency though see if it's really needed. <daviid>str1ngs: oh guile.m4 imposes gettext <daviid>I think gnome users should expect to recieve #f for gnome lib calls that return NULL, and hence always do (and val (what-ever-with val)) <daviid>str1ngs: that maks more sence (to me) then configure.ac imposing gettext ... now, why does guile.m4 requires gettext, I do't know <str1ngs>if gettext is not install then autoreconf -ivf fails with configure:12707: error: possibly undefined macro: AC_LIB_LINKFLAGS_FROM_LIBS. I tested on ubuntu-20.04 btw <str1ngs>daviid: does gtk_container_get_children actually return null? <daviid>str1ngs: very highly probably, otherwise you'd rceiv a list <RhodiumToad>I had a similar issue with guile-gnome on freebsd, it needed a dependency on gettext to get at lib-link.m4 <daviid> that failure above, to me tells that autoconf should depend on gettext <str1ngs>I don't think its and autoconf issue either. this tends to happens with guile projects. I suspect guile.m4 <RhodiumToad>AC_LIB_LINKFLAGS_FROM_LIBS is from lib-link.m4 which is part of gnulib, not autoconf <str1ngs>git grep AC_LIB_LINKFLAGS_FROM_LIBS shows guile.m4 <daviid>fine, but the package that defines AC_LIB_LINKFLAGS_FROM_LIBS, if it needs gettext, should impose th dpendncy, don't you think? <RhodiumToad>at least on freebsd, "the package that defines AC_LIB_LINKFLAGS_FROM_LIBS" _is_ gettext <str1ngs>right in this case g-golf is providing guile.m4 in m4. so it's only need because we use git and not a release tarball. <str1ngs>AC_LIB_LINKFLAGS_FROM_LIBS is provided by gettext but in this case it used by guile.m4 <RhodiumToad>yeah, I needed the gettext dependency for guile-gnome in freebsd because I needed to patch the configure.ac extensively <str1ngs>if you did not use guile.m4 then gettext would not be needed. so it's really a g-golf native bootstrap dependency <RhodiumToad>(because it had no way to tell it what components to include or not regardless of what was actually installed) <daviid>RhodiumToad: oh i see, why is that it is gettext that defines AC_LIB_LINKFLAGS_FROM_LIBS, that sounds really strange <daviid>again, no big deal, just being curious <str1ngs>maybe gettext use gnulib? IIRC its some thing related to gnulib as RhodiumToad mentioned. <str1ngs>I just added the dependency and avoided the rabbit hole haha <daviid>i'm gona ask on #autotools, why autoreconf -vif fails unless gettext is installed and if they considr this 'normal' <str1ngs>later it's a mote issue because the release tarball won't need autoreconf any ways. <str1ngs>it only fails if the project uses guile.m4 keep that in mind. <daviid>but yet, a strange rabbit hole :):) <str1ngs>daviid: let me know what you decide about gtk_container_get_children <daviid>str1ngs: what would you return a string and gnome returns NULL <str1ngs>I'm more in favor of '() then #f . but I can use #f if needed, it just requires an extra step type checking. <str1ngs>GList* is a list not a string. and the docs don't say it actually returns NULL so I can test what the C api returns if it helps? <daviid>str1ngs: the problem is not so much lists, but to be consistent, <daviid>str1ngs: I don't pretnd I hld the right answer, I did ask myself so many times ... but as things are, when an argument is a pointer to 'anything', if it is the %null-ponter, g-golf rturns #f, and when passing, if #f, thn it passes NULL ... <daviid>str1ngs: g-golf users are gnome users, they have to read the manual of the lb they are using ... if tha arg is a pointer, they must expct #f if ... which sounds very reasnable to me <daviid>str1ngs: but we can see and improving tin the future ... though it would be quite a lot more work then it seems <daviid>str1ngs: but for thee time being, I'll (have to) stick to the rule exprsses above - if an argument or returned value of function of a gnome lib is a pointer, g-golf users must expect pass or receive #f ... <daviid>str1ngs: I still have so many important things to do ... <str1ngs>again gtk_container_get_children does not return NULL it returns a GList* if there are not children it has length of zeron <str1ngs>daviid: I just verified this with the C api and that's how I've always used it myself. if you return #f on no children then it changes the return type. but it's your call at the end of the day. <daviid>str1ngs: NULL is not a type, it is a value <daviid>when you call gtk_container_get_children and there is no children, gnome returns NULL <str1ngs>gtk_container_get_children does not return NULL it returns a newly-allocated list of the container’s non-internal children. <daviid>this, in g-golf, up to now, pass through the same code, no matter what the 'final type' is ... but we can improve that i the future, it's not a priority to me though <str1ngs>no this was not always the case something changed before I could simply do (length (gtk-container-get-children container)) to see how many children a container had. now I need to type check gtk-container-get-children if its a boolean or not. <daviid>str1ngs: I did work on glist gslist a little while ago, and also added quite a few other similar procs, like gi-n-gtype->scm, scm->gi-n-gtype ... <daviid>I didn't thnk I 'changed' what we had, I'll check better <str1ngs>daviid: okay thanks, specifically (gtk-container-get-children (make <gtk-window>)) use to return '() now it returns #f <daviid>str1ngs: ok - note that the gi-argument for the returned value of gtk-container-get-children is definitely being set to NULL when there are non-internal children, that is a fact - which is not a 'justification' but that is why 'the change' made it so you see #f now (because I sort of uniformed any gi-argument-ref/set I suppose, I'll check and fix the problem <daviid>str1ngs: ther are many places I need to loo and fix, improve th tst-suite, but i the man time, you can edit (g-golf gi utils), and change line 238, replace #f with '() <daviid>str1ngs: that won't be enough - better wait for a good patch <daviid>str1ngs: ok, I pushed a fix for glist, gslist, I'll fix the other cases, strings, pointers, gtypes ... asap <str1ngs>daviid: great will test this out thanks. I'll probably mail a patch for the guix declaration in the morning as well. <daviid>str1ngs: wrt to the guix patch, let's wait I fix all occurrences of the problem you mntionned today, I'll let you know, a few days probably ... <str1ngs>daviid: sounds good. I'll stage something meantime then let me know. should not be much work then. ***logicmoo is now known as dmiles
***daviid is now known as Guest61703
<guix-vits>Guest61703: i was though g-golf is perfectly legal :P ***Guest61703 is now known as daviid
***leoprikler_ is now known as leoprikler
*guix-vits `(webkit-settings-new)`, yay. <civodul>ArneBab: the difference between -O2 and -O3 is "sealed bindings", so we'd need to look at mbrot to try and see why it matters there <civodul>it can make a difference if there are lots of small top-level procedures <wingo>probably a loop inlines or contifies a small helper that otherwise forced boxing <dsmith-work>With -O3 sealed bindings, are non-exported things visble to @@ ? <civodul>dsmith-work: sometimes, but not always, depending on inlining <civodul>you can no longer rely on @@ when using -O3 