<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 <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>flatwhatson: one change that might be 'culprit' is the develbranch changes libg-golf <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>not sure if 'appropirately' though <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 <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 <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>and i think the lambda from your example is 16 bytes <lampilelo>i thought about bytes and didn't notice we both wrote "bits" <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! <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>at the very least have some pointers in the manual <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 <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 <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>it even says so in the source comment... I should really read stuff before opening my mouth <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) <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