GValue from a DataModel must be read only, you can't delete them, that is a task for ServerProvider.
Hope this will help you: When you use g_value_set_boxed, the boxed is copied using the registered function to copy; for GdaNumeric is gda_numeric_copy. And when a GValue is unset, the gda_numeric_free is called. When you create a GdaNumeric struct and set its members, including the string, and then it is set to a GValue the struct and its fields is copied , then you can free your GdaNumeric. When you unset (or using gda_value_free) the GValue, automatically its GdaNumeric copy is freed. May you want to resend to Python developers. 2011/9/8 Murray Cumming <[email protected]> > On Thu, 2011-09-08 at 15:37 +0200, Tomeu Vizoso wrote: > > On Thu, Sep 8, 2011 at 15:22, Murray Cumming <[email protected]> > wrote: > > > On Thu, 2011-09-08 at 15:05 +0200, Tomeu Vizoso wrote: > > >> On Thu, Sep 8, 2011 at 14:33, Murray Cumming <[email protected]> > wrote: > > >> > When using the Python gi.repository.Gda API, I'm seeing some > nonsense > > >> > strings in the Gda's Numeric.number field. This valgrind warning > shows > > >> > that something is wrong at that point. I suspect that the whole > > >> > GdaNumeric has already been freed. I got the Numeric from a call to > > >> > datamodel.get_value_at(). > > >> > > > >> > Does anyone have any idea what might be wrong? > > >> > > >> datamodel.get_value_at() appears in the .gir as returning (transfer: > > >> full) when it should be (trasnfer: none) instead? > > > > > > The annotation says transfer:none, as it should: > > > http://git.gnome.org/browse/libgda/tree/libgda/gda-data-model.c#n637 > > > > > > However, it returns a GValue, with a GdaNumeric (boxed type) inside it, > > > and I don't know what defines how that is dealt with in Python. > > > > > > Actually, isn't this a general problem of boxed types inside GValues? > > > > I'm not surprised at all that you are having such problems, it looks > > certainly tricky. If you want to keep that API, I would add a minimal > > test case to g-i+pygobject that reproduces it as the first step > > towards solving it. > > OK. I'll try to. > > > In the process of writing the test case you may discover it's something > else :) > > > > > Boxed Types are not reference-counted, and you wouldn't want to copy > > > them just because a parent GValue's reference was increased. > > > > Actually, many boxed types are refcounted, with _copy increffing and > > _free unreffing. > > But there's no way to know that they are reference-counts, I think. To > the generic boxed-type registration API, they are just copy and free > functions. > > > > Maybe all child boxed types are copied already by pygobject when a > > > transfer:none GValue is returned? Or maybe they should be? > > > > Maybe they should be but aren't right now. Have you tried with the > > latest pygobject release? > > Yes. > > > J5 rewrote much of the marshalling code and > > he certainly knows more about marshalling GValues than me. > > > -- > [email protected] > www.murrayc.com > www.openismus.com > > _______________________________________________ > gnome-db-list mailing list > [email protected] > http://mail.gnome.org/mailman/listinfo/gnome-db-list >
_______________________________________________ gnome-db-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gnome-db-list
