dbus-python 0.80rc1 release candidate

[Simon McVittie]

Sorry, forgot the Cc to dbus at lists...

On Thu, 07 Dec 2006 at 20:53:18 -0500, John (J5) Palmieri wrote:
> On Thu, 2006-12-07 at 20:33 -0500, John (J5) Palmieri wrote:
> > On Thu, 2006-12-07 at 18:51 -0500, John (J5) Palmieri wrote:
> > > On Thu, 2006-12-07 at 18:06 -0500, John (J5) Palmieri wrote:
> > > > On Thu, 2006-12-07 at 17:04 -0500, John (J5) Palmieri wrote:
> > > > > On Wed, 2006-12-06 at 14:50 +0000, Simon McVittie wrote:
> > > > > > Release candidate 1 for dbus-python 0.80 is now available. Please
> > > > > > download, test, try to break it.
> > > > > > 
> > > > > 
> > > > > Still tracking it down but sugar no longer starts.  We are getting a
> > > > > connection != NULL assertion when calling
> > > > > dbus_connection_send_with_reply.  Unfortunately it happens in the
> > > > > library so I don't have a python traceback.  0.80pre1 ran sugar a bit
> > > > > better so perhaps you might have insight into the issue based on the
> > > > > changes you made. I'll look more in depth and post anything I find.

Do you have a C (gdb) traceback, and can you reproduce the problem with
the built-in tests (python setup.py check) or with the binding interop
tests (get the Makefile from my dbus-python git tree and the interop
tests from dbus-test)?

As of yesterday we now have an OLPC in the office, but judging by yesterday
I doubt I'll be able to keep Daf away from it for long enough to debug
much ;-)

You can also get more debug info by editing _dbus_bindings/debug-impl.h
and changing the sense of the #if. This produces vast amounts of debug
on stderr.

> > File "/usr/lib/python2.4/site-packages/dbus/__init__.py", line 177 in ?
> >   from _dbus_bindings import get_default_main_loop,
> > set_default_main_loop,\
> > ImportError: cannot import name get_default_mail_loop

There is no mention of get_default_mail_loop in my whole git tree, says grep.
Is that a transcription error, or a direct cut&paste?

The pre1 version didn't have get_default_main_loop at all, so it's
possible that you're using the rc1 Python modules with the pre1 C extension.

Also, if your versions of _dbus_bindings and _dbus_glib_bindings mix
pre1 and rc1, it will crash very hard (I changed the layout of the C API
stub that _dbus_glib_bindings uses). I plan to stay compatible(ish)
with rc1 in future (it'll at least break gracefully, since the C API
stub now includes a number-of-symbols count).

> One thing is for sure here, the setup.py stuff
> isn't very robust right now and needs to be looked into.

distutils (setup.py) is the standard way to install Python extensions,
although I'm starting to see why people use autofoo instead...

One thing to watch out for is that it doesn't track header dependencies,
so you need to "rm -r build" if you're doing multiple builds while
editing the source.

Also check that it's installing files where you think it is, and that
the Python and C bits are coming from the same sys.path entry.

As you mentioned on IRC, distutils also doesn't do very tolerant
checking for missing headers. I think it's reasonable to assume that
Python.h will be present when compiling Python extensions, though (it's
certainly standard practice) - in a source install of Python you already have
it, and in a distribution you have to install python2.4-dev or python-devel
or whatever the distro calls it, but once you've installed one extension
from source you know that.

> Another thing I noticed is all your code is in header files.  Is there a
> reason for this?  It seems pretty wrong.

Python wants extensions to export exactly one symbol, init<name of extn>,
and hence have everything else static, so I wrote _dbus_bindings as a
single translation unit (the -impl.h files are only ever meant to be
#included by module.c, include/dbus_bindings.h is the only one that
might conceivably be made public). I might just ignore that rule and use
multiple C files anyway, like pygtk does.

(I'm starting to detect a pattern of Python upstream's rules not always
being followed in practice, because they haven't entirely been thought
out... don't get me started on setuptools, eggs and "ez_setup"!)

The reasoning behind exporting exactly one symbol is that symbol
visibility in plugins is very platform-dependent - for instance Linux has
a flat namespace, so you have to prefix all your exported symbols to avoid
clashes, but e.g. Windows has a tree of namespaces, so one extension
can't see symbols in another and you have to do the sort of strangeness
you can see in include/dbus_bindings.h.

	Simon