Mostly Pythonic

It has been a nightmare from the beginning….

Starting from the new release of Gobject bindings a lot has changed, we now have a new namespace glib where a lot of classes have been moved, of course retaining backward compatibility.

The new library (libpyglib) needs to be shared and not static, so I changed a couple of lines in Makefile.am to build it as a shared lib, basically adding -no-undefined in libpyglib_2_0_la_LDFLAGS, so far so good, the linker is much more happy.

The second problem came when python libs where not linked against this new library, after some resarch I came across a modification to the macro AM_CHECK_PYTHON_HEADERS into gnome-python-extras that Armin Burgmeier made, taking it from a modified version from Murray Cumming… it looks like we do a lot of copy/paste on this things.

So now I have got my $(PYTHON_LDFLAGS) to add to libpyglib_2_0_la_LIBADD and also to the other modules glib gio and gobject, so far so good.

Now i can get it to compile, the dll’s are created and I can change them to .pyd extension which python expects to have, so far so good.

Now when I try to import one of those modules from python I get:

>>> import glib
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/opt/python25/Lib/site-packages/gtk-2.0/glib\__init__.py", line 30, in <module>
    from glib._glib import *
ImportError: DLL load failed: The specified module could not be found.
>>>

Now I see two different problems here, obviously the first one is that libpyglib-2.0.dll  not found but it’s in the right place C:\opt\Python25\DLLs, the second problem is that there is a path hardcoded (/opt/python25/Lib/site-packages/gtk-2.0/glib\__init__.py) and I don’t understand why is that.

My .profile looks like this:

export PATH=/opt/gnome2/bin:/opt/svn/bin:/opt/python25:$PATH
export LD_LIBRARY_PATH=/opt/gnome2/lib
export PKG_CONFIG_PATH=/opt/gnome2/lib/pkgconfig:/c/opt/python25/lib/pkgconfig
export ACLOCAL_FLAGS="-I /opt/gnome2/share/aclocal"
export CC='gcc -mms-bitfields -mthreads'
export CPPFLAGS='-I/opt/gnome2/include -I/opt/gnuwin32/include -I/opt/python25/include'
export CFLAGS=-g
export LDFLAGS='-L/opt/gnome2/lib -L/opt/gnuwin32/lib'
export am_cv_python_pythondir=/opt/python25/Lib/site-packages
export am_cv_python_pyexecdir=/opt/python25/Lib/site-packages

I run autogen like this:

$ ./autogen.sh --prefix=/opt/Python25 --disable-docs

If someone has got ideas please help 🙂

Pygtksourceview2 is now updated with the latest goodies of gtksourceview.

I’ve also written the docs that were missing in previous releases, for now you can find them here

Have fun!

After a couple of months of hard work PyGTK 2.12.0 is finally in the wild! You can read the announcement

A lot of work is still to be done, especially on docs, cannot wait to help…?? drop us an email!

After a couple of weeks of fighting with GRegex I finally finished the bindings.

Despite the fact that in the python standard library we already have a regular expression module, glib.Regex() is a more powerful way to manage regexp, a simple example is something like:

import glib

def print_uppercase_words(str):
regex = glib.Regex(“[A-Z]+”, 0, 0)
match_info = regex.match_full(str, -1, 0, 0)

while match_info.matches():
word = match_info.fetch(0)
print word
match_info.next()

reg = match_info.get_regex()
print reg.get_pattern()

print_uppercase_words(“SOLO upPerCase LettErs”)

which will produce this output:

gianmt@urano:~$ python regex.py
SOLO
P
C
L
E
[A-Z]+

Luckyly is what I expected to see…. 🙂

Of course I need to test it and especially….write the docs!

So here is my first post in this brand new blog.

The title is not quite self-explaining but I’ve never been good at titles.

I’m trying to wrap as much as possible of Glib to python, that means, at the moment, avoid duplicating what is already in pygobject and what is in the python standard library, anyway if someone of you guys needs a bit of Glib that has not yet been wrapped let me know.

But what is the reason for the title…well while wrapping GNode and writing test for it I’ve been bitten by a segfault that was impossible to track down with both gdb and valgrind, for a couple of days I was trying to segregate the problem writing minimal test cases, but with this small bits of code valgrind and gdb are “almost” useless.

The problem has been tracked down using G_SLICE=debug-blocks as mentioned in Tim’s blog, that’s finally why I owe a beer to Tim.