IRC channel logs
2025-11-17.log
back to list of logs
<kestrelwx>daviid: Sorry, this was my fault, I had to start a `MainLoop` in the default context. <sneek>kestrelwx, you have 2 messages! <sneek>kestrelwx, daviid says: I am not familiar with dbus, i just read in the doc you must call g_dbus_proxy_new_for_bus_finish() inside the GAsyncReadyCallback to obtain the result of the operation - do you? otherwise, is there a snipset I could use to learn, look at and possibly ask for help in gi room ... tx <sneek>kestrelwx, daviid says: unless a bug, there is no 'async callback blocker' in g-golf, not that I am aware of anyway <bootchk>daviid: I was incognito a few days. Any progress on G-Golf array of object? If not, I might devise a test case and patch myself. The strange thing is, the patch I already submitted *seems* to work in my tests, so I don't understand why it is not sufficient. <sneek>Welcome back bootchk, you have 3 messages! <sneek>bootchk, daviid says: I have fixed the gi-array->scm, could you either git pull (devel branch) or subtitue the entire (g-golf gi utils) file with this version - https://paste.debian.net/1405587/ - run the make/make install danse, then run your plugin ... let me know (I did test 'manually', here - https://paste.debian.net/1405588/ - you can see that the instances are properly being retreived ... I'll add this test to the test suite <sneek>bootchk, daviid says: if it still fails, we'd need to investigate if the gimp array of instances is somehow malformed, or if there is a problem in the typelib def for the returned value or a bug in gi-argument->scm procedure, for arrays (always possible, but I'd be very surpried, as it passes all g-golf implemented gimarshalling array tests, and this means that the pointer passed to gi-array->scm has properly been either <sneek>bootchk, daviid says: fwiw, I have just added and pushed (to the devel branch) a test to the test-suite, which properly calls gi-array->scm for both zero terminated and fixed sized arrays of gobject instances <bootchk>daviid: nevermind my last post, until I posted it I did not see your prior posts. Now I do, and will test your most recent changes. Thanks <bootchk>daviid: can you repost the expired pastebin for gi-array->scm? But I assume you checked it into the devel branch, I will look there in the meantime. <bootchk>daviid: I tested latest util.scm from devel branch (I assume that is the only file that changed). Unfortunately, still crashes Gimp. <bootchk>daviid: you may be correct that Gimp is doing something wrong, it would not be the first time, so I will explore that. <bootchk>daviid: I looked at your test case (as best I can with limited experience.) It is not clear to me that it creates a C array of length 4 (having 3 valid pointers and a null pointer.) Again, without me reading harder to understand what map and !g-inst etc actually do. <bootchk>daviid: the crash dump from gdb seems to say the array is terminated by a pointer to null instead of a null. Which may be Gimp's fault. <daviid>bootchk: it my test as using a malfromed array, it would ssegfault <daviid>bootchk: your last sentence seems to be the problem yes, this always segfault <daviid>bootchk: in your patch, you are (wrongly) doing extra dereference, precisly so it does not segfault, but that is to patch the gimp malformed array in the first place ... can you fix this last element and let me know ,, tx <bootchk>daviid: yes, I am looking hard at Gimp. Still, not sure it is the last element, but that fact that another level of deref seemed to fix it. Very perplexing that if it is a bug in Gimp, it hasn't been discovered yet. Because as I said earlier, there are plugins in Python using GI that work for this same case of object array. <bootchk>Yes, I have cloned and checkout devel <bootchk>daviid: reading Gimp code, they call it a boxed type. I don't think that is relevant, it would not add another level of pointers? <daviid>bootchk: an array of boxed tuype is not an array of object, <bootchk>daviid: in Gimp code, I haven't yet found the place where they write a null pointer to terminate. Maybe they were just lucky before and it the next word just happened to be zero. <daviid>bootchk: it would fail unless all pointers point to GObject (sub)class instances <bootchk>daviid: no I think they mean a boxed type of array. To me it just means: opaque, GObject won't understand it inside the box. <daviid>bootchk: the callable says it expect an array of objects, anything else will segfault <daviid>and in your case, it expect an array of <gimp-drawable>, iirc <bootchk>daviid: anyway, I think the problem is back to me to figure out. Yes, array of gimp-drawable. The scheme side doesn't worry about boxing, it is not relevant? <bootchk>Or would the gimp side need better annotation to say "boxed array of objects" ? <daviid>bootchk: i don't think the annotation is wrong, I think the code is not making an array of (pointers to) <gimp-drawable> instances <bootchk>daviid: Thanks so much. Let me work it. I will be leaving for lunch soon and check in tomorrow. <daviid>bootchk: to be precise, the C code must make an array of GimpDraable instances, g-golf either retreive (from its cache) or make a <gimp-draable> proxy instance <mwette>sneek: later tell bootchk, Maybe look in libgimpbase/gimpparamspecs.c. (I was curious. Based on daviid's comments, re GObject vs boxed, some of that looks fishy.) <bootchk>sneek: yes, have been reading there, and gimpprotocol.c. It is RPC with proxy objects, still have not found where array is actually created. <sneek>Welcome back bootchk, you have 1 message! <sneek>bootchk, mwette says: Maybe look in libgimpbase/gimpparamspecs.c. (I was curious. Based on daviid's comments, re GObject vs boxed, some of that looks fishy.) <mwette>To me looks like GimpCoreObjectArray is boxed null-terminated array of pointers to GObject. A box containing NULL is just a zero-length array.