IRC channel logs

2021-06-10.log

back to list of logs

<flatwhatson>lampilelo: i'm fairly sure std::function must not be bigger than a pointer, so function pointers are unboxed but capturing lambdas always allocate
***jackhill_ is now known as jackhill
***terpri is now known as robin
<daviid>tohoyn, and g-golf 'followers', I made subtantial changes to the way g-properties are defined, added the GStrv GValue boxed type (used in css-classes properties), then g-golf now also defines(imports) GObject Binding, BindingFlags and last but not least, GObject methods - so it is now possible to bind properties
<daviid>I also added an examples/gtk-4 dir, with a hello-world.scm, a search-bar.scm and their respective screenshot examples - all this pushed to the devel branch
<daviid>tohoyn: whenever you have sometime, please pull the devel branch and try ... let me know ...
<flatwhatson>daviid: is gtk4 required then? i got it built with guix, but fails at runtime because i only have gtk3
<flatwhatson>Typelib file for namespace 'Gtk', version '4.0' not found
<daviid>flatwhatson: no, it is not required at all, you can even use gtk-2 if you wish
<daviid>but the examples i added are gtk-4 based
<daviid>make check (still) refers to clutter and gtk-3, i hope i cna clean that in the future - but building g-golf does not requireanything but gi, glib andgobject
<flatwhatson>i had to do some nast LD_LIBRARY_PATH to get it to compile, otherwise dlopen complained about missing libraries, but I think that's a guix problem not yours
<daviid>flatwhatson: there is a g-golf guix package already
<flatwhatson>yes but it doesn't build your latest devel version
<daviid>ah, could be aproblem here as well then
<daviid>i didn't run make distcheck will do
<daviid>flatwhatson: make distcheck passes here
<daviid>fwiw
<daviid>flatwhatson: one change that might be 'culprit' is the develbranch changes libg-golf
<flatwhatson>daviid: here's my efforts: https://paste.gnome.org/pmc8ehmdy
<daviid>flatwhatson: note that (you probably knowbutjust to make sure) examples are distrib, not compiled, otherwise yu'd have to have gtk-4 - which is nnot meant to be...
<flatwhatson>yeah, i hoped to try the examples but packaging gtk4 for guix is too much for today... ':D
<daviid>flatwhatson: sure, but this libg-golf.so problem, could it be that my am/guile.mk is incorrect?
<flatwhatson>i don't know sorry, autotools are still dark magic to me
<flatwhatson>oh i see, maybe pre-inst-env should be setting LD_LIBRARY_PATH appropriately
<daviid>hum, but it does set it
<daviid>not sure if 'appropirately' though
<flatwhatson>daviid: patch for the g-golf.so: https://paste.gnome.org/ptrkc39kb
<lampilelo>flatwhatson: capturing lambda by itself doesn't allocate, std::function boxes it if it doesn't fit it's internal storage
<flatwhatson>looks like that builds into g-golf/.libs now, though i'm not sure who's responsible for that path
<lampilelo>lambda's size is known at the compile time
<flatwhatson>i removed the src path, i don't think that will ever be needed for LD_LIBRARY_PATH
<daviid>this sounds a bit strange to me, but i'll look into this, not exactly now though, but tx
<flatwhatson>lampilelo: yes, but at least for gcc i think std::function<> must be the size of a pointer? so in practice only non-capture lambdas or function pointers (basically the same thing) can be stored without allocation?
<lampilelo>std::function (on gcc) is 32 bits, if it can fit all the data it stores it locally
<lampilelo>iiuc
<flatwhatson>my bits/std_function.h has sizeof(_Nocopy_types), a union of various pointer types, maybe 32bits in practice
<flatwhatson>i assumed it would always need to store a function pointer there, but maybe lambdas are smarter than that
<flatwhatson>it would be nice if [this]{ my_method(); } would fit without allocation!
<lampilelo>we should probably look at the standard, not the code, but i'm pretty sure your example would be put into std::function without allocation, look at the _Base_manager::_M_init_functor - it uses placement new for data that fit into _Any_data union (which has the size of _Nocopy_types)
<lampilelo>also _Base_manager::__stored_locally
<lampilelo>and i think the lambda from your example is 16 bytes
<lampilelo>hmm, it's 8 bytes
<flatwhatson>oh right, std::function is 32 *bytes*
<lampilelo>ah, sorry, i misspelled it
<lampilelo>i thought about bytes and didn't notice we both wrote "bits"
<flatwhatson>thanks though, til :)
<lampilelo>these nooks and crannies of c++ can get confusing, i'm trying to make sense of them
<lloda>lampilelo: np, i couldn't use that code directly since i already have a crummy wrapper that does scm2c etc. I'll have to adapt it. But the idea behind the code is useful to me
<sneek>Welcome back lloda, you have 1 message!
<sneek>lloda, lampilelo says: sorry for the faulty code i gave you earlier, this should be much better: https://paste.debian.net/1200610/
<lampilelo>we should make a library for c++, preferably in guile's source tree
<lampilelo>because right now everyone needs to reinvent the wheel
<lloda>i agree
<lloda>at the very least have some pointers in the manual
<lampilelo>that's for sure
<dsmith-work>Thursday Greetings, Guilers
<lloda>i simplified a bit and put it in a working example lampilelo https://paste.debian.net/1200733/
<lloda>still not sure how it fits my use case, but having something like this in Guile would be nice
<leoprikler>fwiw there are already some Guile compat libraries out there (IIRC schmutz is one of them)
<lampilelo>lloda: nice, i thought about moving dest_t definition to the top of the function to simplify it but now i don't have to do it myself! what is also useful is adding "typename = std::enable_if_t<std::is_trivially_destructible_v<Fun>>" to destructor_wrapper's template parameters list, just to be sure that destructor_wrapper can be safely free()'d
<lloda>i use requires now :-D
<lampilelo>yeah, maybe i should switch to c++20 in my project too
<lampilelo>lol i copied schmutz to search for it and then proceeded to type it by hand in the search bar
<lloda>i'm still using smobs so
<lampilelo>lloda: hmm... after i uploaded the last paste i made my make_destructor destroy passed objects in the reverse order for consistency, your simplified version can't do that, is this something that could be an issue to you?
<lloda>since you have to pass the args to scm_dynwind_cpp_destroy, i could just pass them in reverse order
<lloda>but it's true that the comma fold doesn't give you that choice
<lloda>also what happens if you declare the unwind handler several times, can one do that?
<lloda>like A a; scm_dynwind_cpp_destroy(a); B b; scm_dynwind_cpp_destroy(b); ...
<manumanumanu>Whoa! That tailify branch seems awfully web-friendly
<manumanumanu>it even says so in the source comment... I should really read stuff before opening my mouth
<avp>Hello Guilers. I just released Guile-INI 0.2.0: https://lists.gnu.org/archive/html/guile-user/2021-06/msg00036.html
<lampilelo>lloda: yes, it will work and they will run in the reverse order they were registered in, just like scm_dynwind_free, they just get added to a dynstack and since the data associated is allocated through the gc it should be completely safe (iiuc ofc; i tested it by interspersing scm_gc() between the calls to scm_dynwind_cpp_destroy and it was fine, maybe it needs some real life testing to be sure though)
<lampilelo>avp: will you publish your libraries on guix? they are not on the list: https://www.gnu.org/software/guile/libraries/
<daviid>lampilelo: guile s/w list is here - http://sph.mn/foreign/guile-software.html
<amirouche>re tailyfication: It looks much better than mine.
***apteryx_ is now known as apteryx
<daviid>flatwhatson: this .libs 'problem' seems to only occur while using guile 3.0(.7) - and looking at guile's meta/uninstalled-env.in LTDL_LIBRARY_PATH is (alsonot) adding .libs, 'just' doing the usual "${top_builddir}/${dir}" - only DYLD_LIBRARY_PATH is, in that file, but that is for macos iiuc
<daviid>guilers, any one has experienced a foo project, that has a libfoo lib that it needs to build foo ... using 3.0.7, that 'also' fails?
<daviid>in a g-golf git clone, git clean -dxf, ./autogen.sh, ./configure --prefix=/opt2 --with-guile-site=yes, make uninstall (to make sure it won't find libg-golf.so from a previous install), make pass
<leoprikler>I'm not quite if I parsed that correctly, but I think you're encountering some trouble with the change in dynamic library loading.
<leoprikler>In particular, Guile 3.0.7 no longer uses libtool, so the inner workings are a little different
<daviid>but using guile 3.0.7, git clean -dxf, ./autogen.sh, ./configure --prefix=/opt3 --with-guile-site=yes, make uninstall (to make sure it won't find libg-golf.so from a previous install), make boum - https://paste.debian.net/1200795/
<daviid>leoprikler: I think it should still find libs 'as before', though I amhappy to temporarilylocallypatch g-golf