Language Bindings for the C++ API: Third Quarter Report and Fourth Quarter Goals
The following classes are now mostly implemented; there are some methods that cannot be implemented yet because they require objects that are not yet implemented, but otherwise these classes are complete.
|From the Application Kit:
|From the Interface Kit:
|From the Support Kit:
Errors doesn’t actually have any classes, it merely exposes a lot of constants to the target language.
My goals and results for the last quarter:
- Continue to test threading issues (Done)
- Expand existing bindings and add new bindings (Done)
- Fix bugs reported by users (None reported)
- Enable structs (Done)
- Expose globals (Done)
- Add documentation (Partially done)
- Write additional and more complex test programs (Done)
- If there is sufficient time, select a third target language (Insufficient time)
- If there is sufficient time and user interest, work on overloaded operators (Done)
No users have reported bugs yet, but I found several of my own, including a threading problem. Perl passes arguments and fetches results via a stack. The stack is maintained by the interpreter, which lives in the main thread. When multiple threads write to the stack at the same time, the arguments and return values can end up mixed. I solved it by calling
be_app->LockLooper() before doing any stack manipulation and
be_app->UnlockLooper() once I was done.
I didn’t uncover this bug until I was writing a complex example program, with lots of events coming back from the system. I learned enough Python to write minimal test programs, but I don’t have any complex examples in Python, so there may be hidden bugs in the Python bindings. (This particular bug won’t be an issue though, because Python doesn’t use a stack to pass values to and from functions.)
It would be a big help if interested users were to download the bindings and try them out, especially the Python bindings. The bindings can be downloaded from the files pages on the project site (http://dev.osdrawer.net/projects/perl-haiku-kits/files). (Edit: Removed erroneous ‘>’ from the end of the URL.)
While researching the best way to handle structs, I found a reference (http://www.parashift.com/c++-faq-lite/classes-and-objects.html#faq-7.8) which indicated that classes and structs are the same thing as far as the compiler is concerned. And some Haiku structs do in fact take constructors and methods. So since I already had a way to expose classes, I used the same method to expose structs.
I have some more partial documentation for the classes, and I have started on documentation for the generator itself.
There was no time to add additional target languages. I’d still like to, but I won’t be able to fit it into GSoC.
During the rest of GSoC, I will be fixing bugs, writing documentation, and creating more code examples. I still have several groups of classes that I want to include, but I won’t have time to implement them before GSoC ends. (Mostly these classes are layout-related, drawing-related, and query-related.)
Goals for the fourth quarter:
- Fix bugs reported by users
- Add documentation
- Write additional example programs and enhance existing ones
- Language Bindings for the C++ API: Fourth Quarter Report and Post-GSoC Goals
- Language Bindings for the C++ API: Third Quarter Report and Fourth Quarter Goals
- Language Bindings for the C++ API: Git Mirror, Gcc4, and Other Changes
- Language Bindings for the C++ API: Mid-term Report and Third Quarter Goals
- Language Bindings for the C++ API: Python partially working
- Language Bindings for the C++ API: First Quarter Report and Second Quarter Goals
- Language Bindings for the C++ API: Test Program Now Runs
- Language Bindings for the C++ API: First Quarter Goals
- GSoC work schedule
- Language Bindings for the C++ API