Re: [gnome-db] GdaNumeric problems

[Tomeu Vizoso <tomeu tomeuvizoso net>]

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.

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.

> 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? J5 rewrote much of the marshalling code and
he certainly knows more about marshalling GValues than me.

Regards,

Tomeu

>> Otherwise, it could be the field stuff not being stable enough, though
>
>
> --
> murrayc murrayc com
> www.murrayc.com
> www.openismus.com
>
>