J5’s Blog

Having not received a ballot for this years elections I went into my spam folder to see if it had been caught there.  Instead I found a renewal notification for my foundation membership.  The policy for members to renew their membership every two years is not a bad one but I was just informed that I can not be renewed until after the elections and as such can not cast any vote in this cycle.  That is a bad policy.  For someone who is in good standing with the Foundation, having worked on its behalf and even have been a board member myself, I feel I have a right to vote in this election.

The policy to not allow renewal at the ballot box has in effect disenfranchised me.  Most bodies of democracy I know allow registering at the ballot box for those who have a record of having been previously registered and can prove they are who they say they are.  We aren’t talking about someone voting who has not participated in a vote before and would require excessive vetting before gaining that right.

What really gets me steamed about the situation is that due to being caught in a spam filter the only other way I could know that I was removed from the Foundation’s member list was to realize that I never received a voting ballot in which case I am not even give a chance to re-register before voting cuts it off.

UPDATE: I have been notified by the membership committee that many people failed to re-register and are unable to vote this cycle.  If this isn’t a sign of a broken system then people are ignoring the issue.  I could see if this was an isolated incident but since there is a small number of people who are eligible to vote I wonder what the ratio is of people who were denied a vote due to this procedural issue.  I bet it is statistically significant.  How can a vote be legitimate when a significant portion of the community is denied their vote?  It is grounds for a challenge during the ratification stage.

I just filed a bug to request a review for merging my invoke-rewrite branch. This is a huge overhaul of internals of the introspection layer of PyGObject which I feel both speeds up calls as well as makes it easier to fix bugs and add features.

Right now the invoke-rewrite branch is stable and complete enough to be merged to master. It passes all the tests and even cleans up after itself when an error is raised while processing input parameters (something the current code doesn’t do).

A brief list of the advantages of this branch

• over 2 times faster running thought the test suite than the current implementation.
• more robust – handles a couple of corner cases which the current code does not such as multiple lists pointing to the same aux length value, having argument 0 be a length value and correctly blocking all NULL values which are not marked as allow-none
• correctly handles argument parameter counting and reduces the amount of complicated math used to determine argument counts and indexes
• splits code into logical layers such as caching, invoking, marshalling and cleanup layers
• splits code into manageable units so, for example, if there is an error in list processing it is easier to set break points and focus on the list code instead of wading through large switch statements
• ripe for even more optimizations and better layout for profiling

Things that are yet to be done

• Memory management still leaks and some types such as gclosures are not yet cleaned
• Some of the earlier code like struct marshalling can be split up further
• signals and closures still use the old marshalling paths
• remove the FFI/GArgument layer and marshal directly to FFI

Why merge now?

Code rots and getting more people to use the new codepath makes it easier to fix bugs. It is already feature complete with the old code and simply trades off some new bugs while fixing a slew of other bugs. Because of the caching layer the code is somewhat more complex but follows a much more consistent pattern. In my eyes it is easier to understand once learned but developers need ramp up time since the structure is different. This is the future, there is no need to keep bandaging the old invoke code. As we get to more and more corner cases it gets harder to patch the old code without breaking other pieces or causing memory leaks that are hard to track down and plug (see garray hack we added to handle C Array vs GArray failures).

A brief overrview of the design

New modules

• pygi-invoke-ng – the new invoke API handles setup/invoking/teardown at a high level. Replaces pygi-invoke and does not attempt to handle memory it did not itself create (see garray handling for example)
• pygi-invoke-state-structure – the state struct used to pass around changing state during the caching, marshalling, invoking and cleanup stages
• pygi-cache – sets up the cache which normalizes the information and support methods such as marshalling and cleanup of each interface when called. This allows us to process method calls in a more efficent manner as well as makes it easier to debug
• pygi-marshal – marshalling functions for each parameter type. Replaces pygi-arguments
• pygi-marshal-cleanup – cleanup functions for each parameter type.  Includes cleanup for parameters which were not processed due to an error.

Basic flow

invoke is called on an GICallableInfo object
  |
  |-> if GICallableInfo does not have a cache we loop over the interface
  |    creating the PyGICallableCache and ArgCaches for the interface
  |    and its arguments
  |
  |----> use the cache to marshal the parameters into the state struct
  |
  |---------> using the marshalled values invoke the interface using the
  |           GI FFI calls
  |
  |----> use the cache to cleanup any in values that need cleaning
  |
  |---------> use the cache to marshal the out values to python objects
  |
  |----> use the cache to cleanup any out values that need cleaning
  |
  |-> cleanup state
  |
return out values to python app

Standard paterns

All marshalling and cleanup methods for types are added to the argument cache as function pointers. A PyGIArgCache has these four function pointers no matter what the type we are caching for:

• in_marshaller – the function which marshals in values for this argument
• out_marshaller – the function which marshals out values for this argument
• in_cleanup – the function that cleans up in values for this argument
• out_cleanup – the function that cleans up out and in/out values for this argument

All type marshallers and cleanup methods follow this naming pattern:

• in marshallers – _pygi_marshal_in_<type> (e.g. _pygi_marshal_in_utf8 or _pygi_marshal_in_interface_enum)
• out marshallers – _pygi_marshal_out_<type> (e.g. _pygi_marshal_out_utf8 or _pygi_marshal_out_interface_enum)
• in_cleanup – _pygi_marshal_cleanup_in_<type> (e.g. _pygi_marshal_cleanup_in_utf8)
• out_cleanup – _pygi_marshal_cleanup_out_<type> (e.g. _pygi_marshal_cleanup_out_utf8)

These are all setup during the caching phase in functions named similarly (e.g. _arg_cache_in_utf8_setup)

This is just a reminder to those who are coming to the launch party. The dinner reservations has be moved to 8:00 at The Blue Room in Kendall Square. We also have the two back pool tables reserved at Flat Top Johnny’s at 9:30. See you there.

Hey all. We are winding down the release and ramping up to getting our party on! The Boston/Cambridge GNOME 3.0 Launch Party will be happening this Sunday down in Kendall Square, Cambridge, MA. We will be meeting for dinner around 7 at The Blue Room and then going to our tradition hang out spot, Flat Top Johnny’s, for drinks and a couple of rounds of pool. If you are planning on coming please add your name to the wiki ASAP so I can make reservations. I plan on making them by tomorrow night. Hope to see you there!

Hey all you Northeast GNOME developers and users. We are having a GNOME release party this Sunday, April 10th sponsored by Red Hat. We are still scouting for a good location but the idea is to go to a bar with either a bowling lane or pool tables where drinks, games and food will be sponsored. Please head over to the wiki and let us know you will be coming so we can figure out the best venue to hold it.

Come on down and have some fun while we celebrate the hard work that went into this historic release for the GNOME Project.

I am pleased to announce version 2.28.3 of the Python bindings for GObject. There was an issue with the patch that went out with 2.28.2 and all users should upgrade from 2.28.2 to this release. This is a minor bugfix release of the stable 2.28 branch.

The new release is available from ftp.gnome.org:

http://download.gnome.org/sources/pygobject/2.28/

What’s new since PyGObject 2.28.1?

• fixed an ABI break in the static bindings when setting string gvalues
  • e.g. passing an int to a Gtk.ListStore column which expects a string automatically converts the int to a string instead of throwing an error
• This release fixes a bug that the 2.28.2 release introduced

What’s new since PyGObject 2.28.0?

• pygi-convert.sh now supports webkit conversions and favors using GObject over gobject
• Raw closures can now be passed from a signal/vfunc callback to a method
• Revert linking to the python libs because the python runtime statically links it in
• TreeModel column marshalling is now more robust (supports GObject Python Object storing)
• Gtk.MessageDialog now respects the MessageType
• You can now send None in for the signature of GDBus messages that have no parameters
• TreeViewColumn.set_cell_data_func can take None for the func_data
• Fix syntax error so we can run in Python 2.5
• Add pickers and menu demos

Blurb:

GObject is a object system library used by GTK+ and GStreamer.

PyGObject provides a convenient wrapper for the GObject library for use in Python programs, and takes care of many of the boring details such as managing memory and type casting. When combined with PyGTK, PyORBit and gnome-python, it can be used to write full featured Gnome 2 applications.

Like the GObject library itself PyGObject is licensed under the GNU LGPL, so is suitable for use in both free software and proprietary applications. It is already in use in many applications ranging from small single purpose scripts up to large full featured applications.

PyGObject requires glib >= 2.22.4 and Python >= 2.5.1 to build.
GIO bindings require glib >= 2.22.4.

The Introspection module is the next generation Python GObject library bindings. Instead of statically wrapping every GObject based library we can now dynamically accesses any of those libraries using GObject Introspection. It replaces the need for separate modules such as PyGTK, GIO and python-gnome to build a full GNOME 3.0 application. Once new functionality is added to gobject library it is instantly available as a Python API without the need for an intermediate Python module.

Introspection/Python 2 bindings requires gobject-introspection >= 0.9.5 and pycairo >=1.0.2 or py2cairo >=1.8.10
Introspection/Python 3 bindings requires gobject-introspection >= 0.9.5, pycairo >=1.8.10 and Python >= 3.1

–
John (J5) Palmieri
GNOME Foundation member
johnp@redhat.com

UPDATE: Please use the 2.28.3 release

I am pleased to announce version 2.28.2 of the Python bindings for GObject.  This is a minor bugfix release of the stable 2.28 series.

The new release is available from ftp.gnome.org:

http://download.gnome.org/sources/pygobject/2.28/

What’s new since PyGObject 2.28.1?

• fixed an ABI break in the static bindings when setting string gvalues
  • e.g. passing an int to a Gtk.ListStore column which expects a string automatically converts the int to a string instead of throwing an error

What’s new since PyGObject 2.28.0?

• pygi-convert.sh now supports webkit conversions and favors using GObject over gobject
• Raw closures can now be passed from a signal/vfunc callback to a method
• Revert linking to the python libs because the python runtime statically links it in
• TreeModel column marshalling is now more robust (supports GObject Python Object storing)
• Gtk.MessageDialog now respects the MessageType
• You can now send None in for the signature of GDBus messages that have no parameters
• TreeViewColumn.set_cell_data_func can take None for the func_data
• Fix syntax error so we can run in Python 2.5
• Add pickers and menu demos

Blurb:

GObject is a object system library used by GTK+ and GStreamer.

PyGObject provides a convenient wrapper for the GObject library for use in Python programs, and takes care of many of the boring details such as managing memory and type casting.  When combined with PyGTK, PyORBit and gnome-python, it can be used to write full featured Gnome 2 applications.

Like the GObject library itself PyGObject is licensed under the GNU LGPL, so is suitable for use in both free software and proprietary applications. It is already in use in many applications ranging from small single purpose scripts up to large full featured applications.

PyGObject requires glib >= 2.22.4 and Python >= 2.5.1 to build.
GIO bindings require glib >= 2.22.4.

The Introspection module is the next generation Python GObject library bindings. Instead of statically wrapping every GObject based library we can now dynamically accesses any of those libraries using GObject Introspection. It replaces the need for separate modules such as PyGTK, GIO and python-gnome to build a full GNOME 3.0 application. Once new functionality is added to gobject library it is instantly available as a Python API without the need for an intermediate Python module.

Introspection/Python 2 bindings requires gobject-introspection >= 0.9.5 and pycairo >=1.0.2 or py2cairo >=1.8.10
Introspection/Python 3 bindings requires gobject-introspection >= 0.9.5, pycairo >=1.8.10 and Python >= 3.1

–
John (J5) Palmieri
GNOME Foundation member
johnp@redhat.com

I am pleased to announce version 2.28.1 of the Python bindings for GObject.  This is a minor bugfix release of the stable 2.28 series.

The new release is available from ftp.gnome.org:

http://download.gnome.org/sources/pygobject/2.28/

What’s new since PyGObject 2.28.0?

• pygi-convert.sh now supports webkit conversions and favors using GObject over gobject
• Raw closures can now be passed from a signal/vfunc callback to a method
• Revert linking to the python libs because the python runtime statically links it in
• TreeModel column marshalling is now more robust (supports GObject Python Object storing)
• Gtk.MessageDialog now respects the MessageType
• You can now send None in for the signature of GDBus messages that have no parameters
• TreeViewColumn.set_cell_data_func can take None for the func_data
• Fix syntax error so we can run in Python 2.5
• Add pickers and menu demos

Blurb:

GObject is a object system library used by GTK+ and GStreamer.

PyGObject provides a convenient wrapper for the GObject library for use in Python programs, and takes care of many of the boring details such as managing memory and type casting.  When combined with PyGTK, PyORBit and gnome-python, it can be used to write full featured Gnome 2 applications.

Like the GObject library itself PyGObject is licensed under the GNU LGPL, so is suitable for use in both free software and proprietary applications. It is already in use in many applications ranging from small single purpose scripts up to large full featured applications.

PyGObject requires glib >= 2.22.4 and Python >= 2.5.1 to build.
GIO bindings require glib >= 2.22.4.

The Introspection module is the next generation Python GObject library bindings. Instead of statically wrapping every GObject based library we can now dynamically accesses any of those libraries using GObject Introspection. It replaces the need for separate modules such as PyGTK, GIO and python-gnome to build a full GNOME 3.0 application. Once new functionality is added to gobject library it is instantly available as a Python API without the need for an intermediate Python module.

Introspection/Python 2 bindings requires gobject-introspection >= 0.9.5 and pycairo >=1.0.2 or py2cairo >=1.8.10
Introspection/Python 3 bindings requires gobject-introspection >= 0.9.5, pycairo >=1.8.10 and Python >= 3.1

–
John (J5) Palmieri
GNOME Foundation member
johnp@redhat.com

I am pleased to announce version 2.28.0 of the Python bindings for GObject.

Including the stable improvements in the base pygobject modules this is the first stable release of the Introspection binding.  PyGObject Introspection is compatible with both the Python 2 and Python 3 runtimes.

This marks the second major development project I have had the pleasure to help bring to fruition.  Like for D-Bus, I am merely the public face of a rather vibrant development community.  While I hope I don’t leave anyone out I would like to thank the following people who dedicated their valuable time to the future of the Python platform for GNOME.

• Johan Dahlin – creator of PyBank, the predecessor to PyGObject Introspection, for giving us direction, advice and helping to review patches
• Tomeu Vizoso – co-maintainer, my good friend, the reason why we decided to push for Introspection support and probably the hardest worker on our team
• Steve Frécinaux – for all of his leak hunting and bug fixing while testing against libpeas and gedit plugins
• Ignacio Casal Quinterio – for fixing bugs while porting the gedit plugins to the new bindings
• Laszlo Pandy – for fixing some of the tougher bugs and winning the “why are you awake at this hour, hacking on PyGObject while on irc?” award
• Martin Pitti – who worked on GVarients and making GDBus easy to use from PyGObject
• Simon van der Linden – who started this journey with us and has been helping us along when he finds the time
• Simon Schampijer – our newcomer from OLPC/Sugar development who jumped right in to help at the hackfest
• Sebastian Pölsterl – another hackfest alum who ported GNOME DVB Daemon’s GUI
• John Ehresman – creator of the initial Python 3 support code
• Dave Malcolm – some of the initial Python 3 bits and my sounding board for any Python issues I ran into
• The entire GObject Introspection team – especially the tireless Colin Walters who fixed our many GI bugs quickly while also putting up with my complaining both at work and whenever we happened to grab a beer in one of the local watering holes
• The Python team – for making an excellent language for us to bind to
• And many more, too numerous to list, who have contributed to the continuing maintenance of PyGObject throughout the years

The new release is available from ftp.gnome.org:

http://download.gnome.org/sources/pygobject/2.28/

What’s new since PyGObject 2.27.92?

• fix sinking of floating objects
• fix leaks when setting properties
• add basic icon view demo
• add search entry demo
• override Gdk.RGBA so you can construct it like Gdk.RGBA(1.0, 1.0, 1.0, 1.0)
• handle unichar gvalues in TreeModels
• check for _thread module when configuring threading
• package config file now contains overridesdir variable for 3rd party overrides
• on windows set bdist_wininst user-access-control property when installing
• Gtk.stock_lookup return None on failure instead of a success value
• Python 2.5 fixes
• Python 3 fixes

Blurb:

GObject is a object system library used by GTK+ and GStreamer.

PyGObject provides a convenient wrapper for the GObject library for use in Python programs, and takes care of many of the boring details such as managing memory and type casting.  When combined with PyGTK, PyORBit and gnome-python, it can be used to write full featured Gnome 2 applications in Python 2.

Like the GObject library itself PyGObject is licensed under the GNU LGPL, so is suitable for use in both free software and proprietary applications. It is already in use in many applications ranging from small single purpose scripts up to large full featured applications.

PyGObject requires glib >= 2.22.4 and Python >= 2.5.1 to build.
GIO bindings require glib >= 2.22.4.

The Introspection module is the next generation Python GObject library bindings. Instead of statically wrapping every GObject based library we can now dynamically accesses any of those libraries using GObject Introspection. It replaces the need for separate modules such as PyGTK, GIO and python-gnome to build a full GNOME 3.0 application in Python 2 or 3. Once new functionality is added to gobject library it is instantly available as a Python API without the need for an intermediate Python module.

Introspection/Python 2 bindings requires gobject-introspection >= 0.9.5 and pycairo >=1.0.2 or py2cairo >=1.8.10
Introspection/Python 3 bindings requires gobject-introspection >= 0.9.5, pycairo >=1.8.10 and Python >= 3.1

–
John (J5) Palmieri
GNOME Foundation member

I submitted a patch for the last known blocker bug which is waiting on review.  If no other bugs are added to the blocker list, I will be releasing a stable 2.28.0 PyGObject on Monday.  Please add your bug to the blocker list if you want to see it get into the stable release.  They will be the only bugs I will be looking at so if it isn’t there as far as I am concerned, it doesn’t exist until the next development cycle.  If I deem it to not be a blocker I will take it off the list and punt it for the next release.  If it breaks dynamic ABI, except in a few cases, it will be punted to the next major release.  If it touches any of the static binding code in order to fix a GI issue, it will be punted to the next major release.  Most bugs, unless they absolutely positively have to be fixed will be punted to the next release.