2007-12-16
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 :-)
2007-12-01
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
=== 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
2007-11-20
pybindgen + pygccxml
Last weekend I started a pygccxml based header file scanner for pybindgen. When it's finished, it will allow pybindgen to automatically scan a module's definition directly from header files, with little human intervention, similarly like Py++.
Progress has been good, but of course I have little time to work on it. I'll report back on this.
Progress has been good, but of course I have little time to work on it. I'll report back on this.
2007-09-01
pybindgen almost feature complete
During August I got sick, and the weather was lousy anyway, so I decided to continue development of PyBindGen. Since then I have finished most features that will be needed at least for NS-3, which is very C++ demanding. The list of features implemented is summarised in the project page, and I won't bother to repeat them here.
So what's left to do now?
So what's left to do now?
- Testing and bug fixing; I'm sure there are plently of bugs in there waiting to be found and fixed, since the generator has had very little real world testing so far;
- Adding support for some Python object special methods and protocols, such as __str__, __add__, __sub__, etc.; also mapping C++ iterators to Python iterators and vice versa, etc;
- Start thinking of a automatic code scanning layer on top of the pybindgen API, which scans C/C++ header files and tries to automatically 'guess' the definitions, a la Py++.
2007-08-17
PyBindGen Type Narrowing
Today I finished another important feature in my python bindings generator:
automatic type narrowing of C++ class pointers. It was implemented with a std::map<const char*, PyTypeObject*>, mapping type names to Python wrappers, and the typeid C++ operator, which uses RTTI to return type information in runtime, including type name.
This comes on the heels of supporting function/method/constructor overloading, finished a few days ago. I'm getting increasingly optimistic about pybindgen. It does few things, but does them well. It will hopefully make the (python) world a better place to live in :P
automatic type narrowing of C++ class pointers. It was implemented with a std::map<const char*, PyTypeObject*>, mapping type names to Python wrappers, and the typeid C++ operator, which uses RTTI to return type information in runtime, including type name.
This comes on the heels of supporting function/method/constructor overloading, finished a few days ago. I'm getting increasingly optimistic about pybindgen. It does few things, but does them well. It will hopefully make the (python) world a better place to live in :P
2007-08-09
Ubuntu Dell PCs in Europe
Nice to see Dell Ubuntu PCs being sold in Europe. However, one has to wonder why the laptops being sold in Europe are at most Intel Dual Core and Intel 950 graphics, noticeable inferior to those being sold in the U.S., namely Intel Core2 Duo and Intel 965 graphics. What's wrong? Do Europeans require less powerful hardware? Are we being discriminated? *sigh*
2007-08-05
GEdit with Emacs Colors
Following up on Paolo Borelli's post about a Dark Tango gedit color scheme, I decide to write a color scheme based on the default GNU Emacs colors circa RedHat 5.2. It basically has a dark slate grey background, and wheat foreground. All these years, since RedHat 5.2, my first Linux distribution, I got used to GNU Emacs as my editor of choice for serious tasks (programming, LaTeX).
I have customized a few things from the default Emacs color scheme, most notably getting rid of the awful red foreground for comments (ugh!) in favour of a less intrusive grey.
The other notable change that I made was the addition of syntax highlighting for symbols, including operators, parenthesis, brackets, curly braces, etc., because I believe it really helps read the code better. Emacs in fact does not natively support highlighting of symbols, but since it is highly extensible I was able to add support for it.
Anyway, my emacs color scheme for gedit can be found here. Playing a bit with gedit with this color scheme, once again I tried to get the feeling on whether I could ever switch from emacs to gedit, and the answer is sadly still no. Here's some of the reasons:
I have customized a few things from the default Emacs color scheme, most notably getting rid of the awful red foreground for comments (ugh!) in favour of a less intrusive grey.
The other notable change that I made was the addition of syntax highlighting for symbols, including operators, parenthesis, brackets, curly braces, etc., because I believe it really helps read the code better. Emacs in fact does not natively support highlighting of symbols, but since it is highly extensible I was able to add support for it.
Anyway, my emacs color scheme for gedit can be found here. Playing a bit with gedit with this color scheme, once again I tried to get the feeling on whether I could ever switch from emacs to gedit, and the answer is sadly still no. Here's some of the reasons:
- Gedit still does not have the notion of indentation offset, and only has tab width. In emacs, you can have tab width set to 8, but if you set indentation offset to 4 then pressing tab indents with 4 spaces, not one tab. In gedit you have to change the tab width to 4, which has disastrous side effects on source files that are using real tab characters for indentation. This is a really serious problem IMHO.
- Gedit is generally not very smart about indentation. Emacs usually knows how to indent a line based on syntax analysis of the surrounding context. I guess I can leave without it, but it would be really nice to have. But, yes, I realize this is very hard to implement for only a little gain.
- Gtk's default cursor is very thin and easy to lose track of it. In contrast, Emacs' cursor is big and blocky, but at least you never lose track of it. Fortunately I was able to kind of work around with a gtkrc style file, although it's not perfect.
- I already mentioned the symbols/operators problem. Gedit does not natively support operators in most language files; at least not C/C++/Python, which is the ones I care about. I'm not sure if I can fix this easily. I can define color schemes, but I wonder if I can customize language definitions, add new information to them in a inheritance style?
- The modelines plugin needs more work; it keeps ignoring many of the modelines on my files.
Subscribe to:
Comments (Atom)
