Re: [pygtk] PyGObject directory issue again, taking a stand

[Tomeu Vizoso <tomeu sugarlabs org>]

On Tue, Nov 23, 2010 at 20:15, Dieter Verfaillie
<dieterv optionexplicit be> wrote:
> Quoting "Tomeu Vizoso" <tomeu sugarlabs org>:
>>
>> On Tue, Nov 23, 2010 at 13:46, Dieter Verfaillie
>> <dieterv optionexplicit be> wrote:
>>>
>>> Quoting "Tomeu Vizoso" <tomeu sugarlabs org>:
>>> It's not up to me to decide anything, but is a kludge like that really
>>> planned to be supported? Maybe I missed the point of the whole gi effort,
>>> I thought the goal was that static bindings will be abandoned in favor of
>>> introspection... Looks like I have some more reading to do ;)
>>
>> Why would that be a kludge? For maintainability reasons, I tend myself
>> to introspection-only,
>
> Up until now I had the impression that we were going to be supposed to work
> like that: use on of both, but never both systems together. So the point of
> the "do not mix" warning/error I suggested now seems more like a display of
> my ignorance than anything else. It's never too late to learn, I guess :)

Trouble happens when static and introspected wrappers for the same
classes mix just because they most often have different APIs.

Both kind of wrappers use a metaclass that inherits from GObjectMeta
so they are in theory compatible, in practice they aren't because the
writer of the static wrapper usually chose to implement a slightly
different API than what would be introspected.

>> but some people (actually, gstreamer
>> developers) have shown concern about the extra overhead during
>> invocation
>
> gi compared to gst-python?

Yes, the static bindings already know at compile time how to marshall
the python args to C, with introspection we need to make that decision
at runtime and is not cheap. Johan has explored generating wrappers at
runtime with LLVM:

http://git.gnome.org/browse/pygobject/log/?h=llvm

>>  because there are server-side users of gstreamer that don't
>> care much about startup cpu and memory usage.
>
> I suspect a typo on your part, but if they don't care then why is the
> extra overhead important?

One consequence of the move to gi is that we can decide when to load
wrappers. With static bindings we load all classes and methods
regardless of whether will use them or not, which turned out to be too
expensive for desktop apps because of the slower start times and high
(private) memory usage.

Regards,

Tomeu

> Looks like all my original questions have been answered so thanks for
> taken the time to do that :)
>
> mvg,
> Dieter
>
> ----------------------------------------------------------------
> This message was sent using IMP, the Internet Messaging Program.
>