<daviid>str1ngs: g-golf depends on libgirepository-1.0, libglib-2.0, libgobject-2.0 and libg-golf, no g-ir-scanner and friends ... <sneek>daviid, you have 2 messages. <sneek>daviid, str1ngs says: will do. thanks again <sneek>daviid, str1ngs says: guix python GI and GJS binding are working fine same with C. for reference my trivial tests are here https://github.com/mrosset/test-gir. when I down grade gobject-introspection to 1.58.3 test.scm works but not with guix's 1.60.2. <daviid>str1ngs: it doesn't make sence, if all uses the same libs, that it would work in a lang bind and not in another, could add a call for g-irepository-get-typelib-path, g-irepository-get-shared-libraryyou, g-irepository-get-version and i would also try g-irepository-find-by-gtype on the registered type, in your tests <daviid>*g-irepository-get-shared-library <daviid>for all (each) namespace "Clutter", "GObject" and "GLib" <daviid>str1ngs: this made me find a typo in (g-golf gi utils) - which has nothing to do with this guix problem ... - please pull/make ... ***catonano_ is now known as catonano
<str1ngs>daviid: I did a pull. I agree it does not makes sense. Thanks for the snippet I'll add these to my tests over the next couple of days, maybe it will be more apparent what issue this shlibs patch introduces. Happy Holidays <zig>what would it take to speed up foreign function interface? <manumanumanu>Ho ho ho! What a christmas! I managed to send a patch with my transducers in, AND I managed to get my for loops to support foldr in a generic way. <manumanumanu>And now it's efficient! Next up, support a general lazy way of making it lazy! <manumanumanu>this means for/stream can be efficiently expressed as (for/foldr ...) and be properly lazy. <manumanumanu>What does goops call streams? I am trying to dispatch on <steram-promise> but that doesn't work. <daviid>manumanumanu: these are records, not classes <daviid>someone ask a similar question, but about future ... the esiest way is you wrap the record in a class <manumanumanu>I just thought it worked because class-of reported it as <stream-promise> <jcowan>I've made really good progress the other day on bitvectors <daviid>manumanumanu: visit the (oop goops), you'll see what classes are defined when goops is loaded <manumanumanu>daviid: that's a shame :D Then I know where to look, though. <manumanumanu>jcowan: I like that you are catering to both #t/#f and 1/0 people :D <jcowan>Right. At first I had just the first, but the second is cheap enough <jcowan>It expands the API surface, of course, but only in a trivial way, and it accords with my principle for R7RS-large: "Reach for the Right Thing in data structure, not the one with the biggest library." <str1ngs>daviid: I have resolved the (g-type-name type) issue. I needed to refine the propagated inputs for the g-golf package definition. <str1ngs>daviid: it's not complete fix yet. but I think I can resolve it going forward. <daviid>str1ngs: i don't understand what 'needed to refine the propagated inputs for the g-golf package definition' means, but glad you are on a route to solve the guix problem <daviid>i still is a very very very big surprise to me that you have to do anything 'special' for g-golf on guix <daviid>it stll does not make any sence to me <daviid>and why for that particular base info, and not others ... is a mistery to <daviid>but tx for tracking this, for the future guix g-golf users ... maybe good to also ask advanced guixers to check your diagnostic and solution as well, but as you wish of course