Avoiding fragmentation with a rolling release

[Robert Bruce Park]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 13-03-04 07:34 AM, Evan Dandrea wrote:
>> "From exceptions to segfaults" is quite a harsh exaggeration.
> 
>>> from gi.repository import GdkX11 GdkX11.get_default_xdisplay()
> [1]    10593 segmentation fault (core dumped)  ipython
> 
>>> import gtk gtk.gdk.display_get_default()
> None

As a developer who has spent the better part of the last two years
developing a desktop application using PyGObject, I am no stranger to
python code that segfaults instead of raising exceptions. Sometimes it
was my fault for tickling the APIs incorrectly, sometimes I discovered
genuine bugs in the C libs that were promptly fixed when I reported bugs.

But the important thing to remember about GI is that it has
*enormously* reduced the language bindings maintenance burden. pygtk2
was a *huge* codebase, and updating it to the new gtk3 APIs would have
been untenable. There simply was not enough manpower available to
undertake such a task. GI was the blessing that allowed Python
developers to use GTK3 *at all*.

I would like to hold up GExiv2 as a smaller case study in the
successes of GI. The pyexiv2 module that it replaced was on the order
of 10,000 lines of glue code, which existed purely to allow python to
call into libexiv2 code written in C. It suffered from many layers of
glue code and introduced a bunch of baroque APIs not present in the
original libexiv2 library. It was a maintenance nightmare and proved
nigh-impossible to port to Python3.

On the other hand, I added GI annotations to Yorba's existing GExiv2
Vala library over a single weekend. I only had to write about 100
lines of code, and the API was suddenly importable and usable in
Python 2, Python 3, and even Javascript, among many others. The
maintenance burden is almost non-existent; it's just so simple that it
blows the alternatives right out of the water.

I feel quite strongly that the odd segfault is a small price to pay
for an otherwise *enormous* improvement in efficiency, API coverage,
maintenance burden, etc. I would go so far as to say that GI is one of
the *best* technologies to come out of the GNOME project, and it's
something that I am going to sorely miss as we transition to Qml.

> I think it also speaks to the problem faced whenever you
> mechanically generate bindings. These are not Pythonic. For someone
> versed in that language, writing Object.new() is entirely alien.

There exist overrides to provide the syntactic sugar that most python
programmers have come to expect.

>> But what do we get from switching from GI to QML? We won't have
>> bindings to a great many libraries at all any more, and now have
>> to go back to writing C++ stubs for those. I. e. exactly the
>> problem that GI already fixed.
> 
> That of course assumes we pick Python as the language for
> graphical applications and services. Last I checked, it wasn't the
> fastest thing going on an ARM processor. And the system
> requirements should bar it from ever being used for a long-running
> (ubuntuone-syncdaemon) or frequent process (Lenses).

Yes, yes, we are discouraging python on the phone. GI is equally
capable of allowing C libs to be imported into Javascript code, and
Qml lets you hack in Javascript, too... so what happens now if we want
to import the *wealth* of gobject based libraries into Qml? Well, you
have to write a bunch of C++ wrapper glue code to get at it... it's a
waste of effort and introduces extra maintenance burden.

I would *really* like to see Qml adopt some form of support for GI to
make it easier to call GObject libs from within Qml's JS implementation.



> Or we could keep creating choose your own adventures of pain: 
> http://blogs.adobe.com/penguinswf/files/penguinswf/linuxaudio.png

http://xkcd.com/927/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iQIcBAEBAgAGBQJRNRhCAAoJEMnVpoCaWglEPVcQAJyHOCVRG1/yc9eh76gouqTE
/4eJTsjjxJ6SfehVwV1PkMlhknp8tDnJYKpoD8otXuzXB7HxksN8IP9Qsw/dzReN
pUhHNvlAl8t/ai+kql/RpI98QkPEF2rdY0jptM1f0dk21FGlP3i3af+gEiZF9M46
8gY4nHMLzJfieVFnZgvaQap34wckBSv5i2RGPWh57MxKs+TouVUyevlPaDojstfb
Cb21zR/AJF9EMrDi9L3kir+9YYka3ri/96tDx9i4M2InBAZL3t9VNUFya+U100yf
7GZRm7n+34GJBCRpLOSy/Ikt08zbnNdky12DzJfDtZDEeaB1BewJSp4PuqbiKOW6
xDpoSHFyGlDp8j/raaCdOZEye7F/gsir6xOpWTjslbkHrCCkTADlnGxKuB4EquLl
SI7W1AXT3WXuda6AZWWWFxSNAGR3DBvtdZVFlUEiqT2dqT73JFUmky4gcU+vdpJU
1hvQVAHzE7D/2p5KTL2bxhkULmG+FE3Z80g+GOv64hUJZjyB8qxMnofw1r+wCuUv
E6mugZJv9/1Zl4SDC4zT0WVerkoGTq4+3hD/kb3xbzIXbWCepyuq/QbCPfVOrMrn
zvQHJi/nVjtDrmySIqY5a/XEswdlExk76XApJLJ2eF79SQdV/vdmnEZqXGgz5kT4
5wGfBEqO1VijVUr0XTQT
=8kIb
-----END PGP SIGNATURE-----