PyBindGen documentation

I have been prodded by the NS-3 guys, namely Mathieu Lacage, to provide more documentation for PyBindgen. Additionally he provided some nice and short examples of C/C++ code to wrap. I then wrote the PyBindGen code that wraps the C/C++ examples, and added everything to the repository.

I looked into it and decided to use epydoc to generate API docs. Additionally I wrote a small introductory section, just to get started (else it's easy to get lost with all the classes). So here it is, the first draft of PyBindGen API documentation. Enjoy.

RedHat conspiracy theories

It seems my last post was not taken well by the community. The thing is, I had not realized my blog would reach so far. Luis Villa and Jeff Waugh in particular think I should I apologize. I respect their opinion, one hand, and I the blog post had unintended consequence, potentially damaging Red Hat's image, on the other hand, which is not what I intended. Red Hat absolutely rocks as a company.

So, I apologize to Red Hat for the last blog post.

Conspiracy theories are always fun, but it seems blogging about them can have unintended consequences.

RedHat's open source community trick

OK, I am going to be a bit cynical here, so be prepared ;-)

I think one of the new genial tricks of late being employed by RedHat to great effect is the following:

1. Select a good open source developer, respected in the community but not affiliated with any Linux distributor company;
2. Secretly talk to the guy and offer him a job at RedHat in some months, but he has to agree to start an open source project doing this and that...
3. The developer agrees, starts the open source project, and starts developing it;
4. In time the open source project gets good community support, not only because of its good quality but also because it is perceived as coming from the open source "community" rather than a company;
5. After some months, the developer joins RedHat, and continues to maintain the project (which now has good community adoption);
6. ....
7. Profit!

I am trying to guess here, and could be wrong, but I am guessing this might have happened with projects such as Cairo (Carl Worth), Pulse Audio (Lennart Poettering), and more recently PackageKit (Richard Hughes), probably others in the past (I suspect Nautilus as well).

Well, if true, I think this is only slightly evil, anyway. I love RedHat, and I think they have always done a great service to open source in the past, and continue to be the leading technology innovators.

OK, if one was not being so cynical one might consider a scenario where the developer in question starts something cool on his own free will and the company simply sees the potential and decides to hire him. But I think I am too cynical to believe this :)

Nvidia closed binary driver

I remember back in the days, when I bought my first nvidia card (GeForce 2) , the linux 'nv' open source driver was actually pretty great for 2D stuff. Everything painted very fast. The only problem was the lack of 3D acceleration. There was the closed source, binary 'nividia' driver out there. It was very good for 3D stuff, but was actually slightly worse than the open source driver for 2D; when switching workspaces I could notice that the new workspace took longer to appear than with the open source driver.

Now fast forward to 2008. The nvidia closed binary has gotten better at everything, even 2D is pretty fast. However, because the nvidia driver is split into a userspace part (xorg driver) and a kernel module, and the versions have to match between xorg driver and kernel module, I find myself not able to run it if I want to boot with an older kernel. I switch to the open source 'nv' driver, but I am finding it surprisingly slow, much slower than it was back in the day when I had a GeForce 2 (now I have a GeForce 6700). Everything seems sluggish now. It's a pain to have to use this driver now.

So what happened to the nv driver? Maybe this is what the linux kernel guys were afraid of, that when using binary closed drivers with linux becomes easy then the open source alternative might begin to bitrot. Well, but it's not like linux users ever had any real choice. In the mean time I sure hope the nouveau effort comes through!

No PyBindGen for NS-3 yet

Acording to the plan, I was supposed to have merged Python bindings for NS-3 about now. Unfortunately deep API changes in the NS-3 object system have broken the Python bindings and I decided to postpone Python bindings for the next release.

This means that PyBindGen 0.9 release is also postponed. But it sure is packed full of new features and many bug fixes, so potential developers may want to check out my bzr branch at https://code.launchpad.net/~gjc/pybindgen/trunk

WAF in GNOME

I have file GNOME bug #503907, which will hopefully allow me to be the one to introduce WAF into the first couple of GNOME modules. Let us hope this marks the start of a new revolution with the intent of ending the reign of autotools in the GNOME realm :-)

PyBindGen 0.8

Today I have unleashed PyBindGen version 0.8 to the world:

=== pybindgen 0.8 ===
- Support C++ instance attributes through getter/setter methods
- Support functions as methods of C++ classes
- Support the PyObject* type
- Support unsigned int, C strings (char*) (from Mark Lee)
- Add basic support for enum types
- New experimental automatic module generator based on C/C++
header file scanner and annotations in comments, using pygccxml
- Some bug fixes