GNOME Bugzilla – Bug 662265
gperl_value_from_sv() doesn't understand G_TYPE_VALUE_ARRAY values
Last modified: 2021-07-05 12:22:32 UTC
Created attachment 199499 [details] GPerlBoxedWrapperClass for G_TYPE_VALUE_ARRAY I'm wrapping a GObject-based library with a couple of objects that have array properties (GParamSpecValueArray). When I try to set the property on construction, I get the following error: internal problem: GType GValueArray (2535808) has not been registered with GPerl This seems to be due to the fact that GValueArray is a boxed type, but it has not been registered with gperl_register_boxed, and there isn't any special code to handle ValueArray values in gperl_value_from_sv(). I needed a work around to get some minimal functionality for the library bindings, so I implemented the attached code, which I include in the library bindings module itself. This code probably isn't correct (I've only tested it for integers in the SV-to-GValue direction), and a proper fix should probably be to implement handling of value arrays at some point higher in the call stack (say when decoding the property GParamSpecs).
Created attachment 199593 [details] GPerlBoxedWrapperClass for G_TYPE_VALUE_ARRAY Fixed some of the work-around code. Has been tested SV->GValue and GValue->SV for int, string, and GObject.
The GValue→SV part looks fine basically, but it should use g_value_array_get_nth and g_value_array_free. But as you note the trouble is with the the SV→GValue part. One simply cannot reliably know what type an SV has -- think of overloading, for example; <http://markmail.org/thread/xqab2x34q3kjm4l4> has more details. Also, Perl programmers don't expect to have to use things like 0+$value just because some function expects a number. The only safe way to do this, as far as I can see, is if you already know somehow what type is expected. This is the case for gtk_list_store_set_value, for example: you can find out the expected type by finding the column's type. So, what API are you trying to wrap? Is there a way to know the expected type?
I'm wrapping the OSCATS library (http://code.google.com/p/oscats), which includes an element param spec for the array-valued properties (#GParamSpecValueArray.element_spec), so the expected type for the elements of is known, at least at the point at which the property information has been accessed---such as in: GObject.xs:g_object_new() GObject.xs:init_property_value() GParamSpec.xs:g_param_value_validate() GParamSpec.xs:g_param_values_cmp() It would probably be better to handle the G_TYPE_VALUE_ARRAY case there, instead of in a boxed wrapper, as I did in the work-around, at least for the SV->GValue direction.
(In reply to comment #3) > I'm wrapping the OSCATS library (http://code.google.com/p/oscats), which > includes an element param spec for the array-valued properties > (#GParamSpecValueArray.element_spec), so the expected type for the elements of > is known, at least at the point at which the property information has been > accessed---such as in: I see. (But note that element_spec is documented as allowing NULL.) > GObject.xs:g_object_new() > GObject.xs:init_property_value() > GParamSpec.xs:g_param_value_validate() > GParamSpec.xs:g_param_values_cmp() Yeah, gperl_value_from_sv is not among them. I guess we need to alter Glib::Object::set_property to somehow cooperate with init_property_value such that gperl_value_from_sv knows the expected element type when it encounters a boxed of type G_TYPE_VALUE_ARRAY. That won't cover G_TYPE_VALUE_ARRAY arguments to signals or similar, but I don't see how to handle that automatically.
It's true that element_spec can be NULL, in which case one is sort of out of luck (seems like poor object specification, in my view), but if the property specification supplies the element type, it seems reasonable to make use of it. Although it probably isn't possible to handle the arguments to signals and other closures automatically now, it probably would be through GObject Introspection (for well-documented objects, at least), once it becomes a little more mature.
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME?utf8=%E2%9C%93&filter=perl- Thank you for your understanding and your help.