IRC channel logs


back to list of logs

<gmaggior>Sorry, can a guile .scm file can be compiled into a standalone executable?
<daviid>gmaggior: no
<sneek>Welcome back daviid, you have 1 message!
<sneek>daviid, str1ngs says: Hello something has changed with (gtk-container-get-children (make <gtk-window>)) before it would return '() now it returns #f is that intended? only documents it returns GList* from my experience the C api does not return #f.
<gmaggior>daviid, thanks
<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
<gmaggior>daviid, oh ok fine!
<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'
<daviid>gmaggior: here is an example - note that the autotool chain, the configure step to be precis, will generate a 'foliot' file, which is installed 'as in' $prefix/bin/foliot
<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, 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
<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 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?
<str1ngs>err 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
<daviid>not g-golf
<RhodiumToad>no, it's not autoconf itself that's the issue
<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>that's not the issue
<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 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.
<RhodiumToad>I don't know
<RhodiumToad>all I know is what ports provide what files
<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: it changed?
<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
<tohoyn>sneek, botsnack
<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.
<str1ngs>daviid: btw instead of using examples. I've started to just make unit tests. so as long as you are covering the low level. I should start to accumulate more GTK case coverage. see
<daviid>str1ngs: nice
***logicmoo is now known as dmiles
<dsmith-work>{appropriate time} Greetings, Guilers
***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.
<ArneBab>wingo: what’s the reason for the 16x speedup of O3 over O2 in the mbrot benchmark?
<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 unboxing
<wingo>probably a loop inlines or contifies a small helper that otherwise forced boxing
<civodul>ah yes
<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
<ArneBab>wingo: ah, nice
<civodul>wingo: yay, excellent!
<civodul>thank you!
<rgherdt>really nice, thanks