Re: [gnome-db] GdaNumeric problems

[Daniel Espinosa <esodan gmail com>]

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 <murrayc murrayc com>

On Thu, 2011-09-08 at 15:37 +0200, Tomeu Vizoso wrote:

> On Thu, Sep 8, 2011 at 15:22, Murray Cumming <murrayc murrayc com> wrote:
> > On Thu, 2011-09-08 at 15:05 +0200, Tomeu Vizoso wrote:
> >> On Thu, Sep 8, 2011 at 14:33, Murray Cumming <murrayc murrayc com> 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.

--
murrayc murrayc com
www.murrayc.com
www.openismus.com

_______________________________________________
gnome-db-list mailing list
gnome-db-list gnome org
http://mail.gnome.org/mailman/listinfo/gnome-db-list