Re: [gnome-db] GdaNumeric problems

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