gsoc2011

A status update for those interested:

Bindings now return multiple values when appropriate (this was not working before).

Bindings now return undef (in Perl) or None (in Python) for a NULL object pointer; previously a target language object with an underlying NULL was returned, which obviously caused problems.

For errors, Perl returns undef and sets an error variable. Python raises an exception. However, when the status code is also the return value, Perl returns true if there is no error. Python simply returns the status code.

Perl builds under gcc2 and gcc4. Python builds under gcc2 and gives the following warnings/errors under gcc4:

gcc -fno-strict-aliasing -I/boot/develop/headers/3rdparty -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC -I/boot/common/include/python2.6 -c Haiku.cc -o build/temp.haiku-1-BePC-2.6/Haiku.o -Wno-multichar
cc1plus: warning: command line option "-Wstrict-prototypes" is valid for C/ObjC but not for C++

As far as I can tell, this has to do with the fact that the python executable was originally compiled with this flag. There seems to be no way to turn the flag off using distutils.

g++ -shared build/temp.haiku-1-BePC-2.6/Haiku.o -lpython2.6 -o build/lib.haiku-1-BePC-2.6/Haiku.so
/boot/develop/abi/x86/gcc4/tools/gcc-4.4.4-haiku-101111/lib/gcc/i586-pc-haiku/4.4.4/../../../../i586-pc-haiku/bin/ld: cannot find -lpython2.6
collect2: ld returned 1 exit status
error: command 'g++' failed with exit status 1

I'm guessing that this command will work with gcc4 if python is installed normally on a gcc4 Haiku. If not, I'm not sure how to fix it.

For those interested, I have created a git mirror of the SVN repository at https://github.com/jalopeura/Haiku-API-Language-Bindings. Note that the repos contain the perl code and definition files used to generate the bindings; they do not contain the bindings themselves. The bindings are available for download from the project page at http://dev.osdrawer.net/projects/perl-haiku-kits.

Please note that this is a mirror. Its function is to reflect the state of the real repository for those who do not wish to use SVN. I will still be working from the OsDrawer.net repository. If you make changes and you want me to be aware of them, you must notify me. You can use an email, a comment to this blog, a github pull request, whatever you want.

The next items on my list are structs and global variables. Structs will be an appropriate data type (Perl hash or Python dictionary) and globals are going to be accessed via a class method, rather than actual variables.

For example, be_app would be avilable as Haiku::Application->be_app() in Perl and Haiku.Application.be_app() in Python. Or if people prefer, I could put them into the Haiku namespace: Haiku->be_app() or Haiku.be_app(). (And if people really would prefer a variable to a class method, I can do it that way as well.)

So far:
SDL 1.3 officially compiles.
Whether it works is another story.

I've created 7 patches so far, four of which were created in logical pairs, one of which was completely useless. The 7th patch (SDL-1-3_patch06.diff) was sent out to the haiku-gsoc mailing list today, and should allow the code to compile. Note that not all functionality is implemented in the video code.

I've also started working on creating a Google code project to host my repository; this will make it easier to follow my progress if I succeed. So far I have had trouble pushing my repository to the project site; it's a lot of information, and takes about five hours. I've tried twice and it failed both times, although the failure may have been due to other things running; I'll have to try again tonight.

I finally managed to find a machine that works with both Haiku's graphics and internet drivers, and am moving my project onto this machine. This probably won't affect my workflow too much, but it will increase the number of updates I can make.

Future:
I will implement the more important video functionality missing in the current compiling version over the next couple of weeks, as well as review the code I have for any obvious bugs. By the next milestone report I will have, at the very least, a simple test that creates and destroys blank windows.

At any rate, I think I've made some good progress, and I hope I will continue to do so over the remaining weeks of the project.

The following objects have at least partial bindings:

At the moment, some of the classes are not very usable; they're necessary because other objects inherit from them. They will later be expanded to allow creation of custom objects based on them, so users could subclass a Looper or a View the same way they can now subclass Application and Window.

Python has a minimal test program that uses Application, Window, and Button, but the other objects have not been tested. It would be helpful if interested Python programmers could start coding (and thereby discovering bugs). In addition, I get a large number of warnings about multi-character constants when compiling. Despite following the instructions in the documentation, I cannot get the installer to pass options to the compiler to turn these off. There are also a few other warnings I'm working on eliminating, but the extensions successfully compile and the test program works.

For the time being, the Python objects are all named Haiku.Object instead of Haiku.Kit.Object. This allows me to split up the kits into different extensions; since an extension does not know what kit a foreign object is defined in, the kit name cannot be part of the object name. Since this naming scheme is apparently not good Python practice, I am still looking into alternatives; currently I am considering either placing everything into a single extension or adding some data to my definition files that lets an extension know what kit/extension a foreign object belongs to.

Perl has the minimal test program and it also has a slightly more complex test program (a small Person viewer app). There are also a few compiler warnings I'm still working on eliminating.

The bindings can be found at http://dev.osdrawer.net/projects/perl-haiku-kits. The downloadable files are under "Files"; there are also Forums and a Wiki, and (under "Issues") a bug tracker. Anyone can download the files and look at the content, but if you want to report bugs, post to the forums, or edit the wiki, you need to be added to the project. Interested users with an OsDrawer.net account can email me or post a comment here, and I will add you as a member of the project.

There may be some trial and error involved in adding members; OsDrawer.net has defined some roles for members of a project, but I can't find any documentation on what permissions each role has. There is a role called "Reporter" that I assume lets the user post new bugs, and there's one called "Wiki editor" that's self-explanatory. But there's no role for Forum poster, so I assume one or more of the other roles has that permission included. But I don't know which one(s).

Okay, let's take a look at my second-quarter goals:

- Bring the Python bindings to minimal functionality (Done)
- Write a minimal Python test program (Done)
- Continue to test threading issues (See below)
- Expand preliminary bindings and add new bindings (Done)
- Write test programs for the bindings (Partially done)
- Write documentation for the bindings (See below)
- If there is sufficient time, select a third target language (Insufficient time)

Threading: I have found several issues I thought might be threading issues, but upon closer examination, they were not. I did find one genuine threading issue - but it was because I forgot to lock a window before updating data.

Documentation: I have written some documentation and I am working on programmatically adding it to the bindings. Python has fields in the underlying C++ structures to add documentation, and Perl allows documentation to be mixed in with the code.

Now for my upcoming goals. In general, during the next quarter I will continue to keep an eye out for threading issues, add new bindings, and fix reported bugs. There are also a few more specific things I want to work on:

There are a number of methods that haven't been implemented yet because they have structs as input or output, and the bindings do not handle structs yet. It should not be too difficult to map these to appropriate data types in the target language (Perl hash, Python dictionary).

I'm not sure what to do about globals like be_app and be_clipboard; on the one hand, they could be treated like constants and restricted to a particular namespace, in order to not pollute the global namespace. This is the way I'm leaning right now. On the other hand, there are relatively few of them, and so it would probably not result in a great deal of pollution if I were to put them in the global namespace.

Several of the C++ objects have overloaded operators. I would like to expand the bindings to support these overloaded operators. I'm not sure how much time I want to spend on this issue right now, though. It depends on how much users want this feature.

- Continue to test threading issues
- Expand existing bindings and add new bindings
- Fix bugs reported by users
- Enable structs
- Expose globals
- Add documentation
- Write additional and more complex test programs
- If there is sufficient time, select a third target language
- If there is sufficient time and user interest, work on overloaded operators