api

Haiku on Java

Blog post by yourpalal on Thu, 2012-03-01 22:36

As part of my work at the University of Auckland (which is drawing to a close soon) I have been looking at Java on Haiku. There is already some support for Java on Haiku. By running installoptionalpackage DevelopmentJava you can get the JamVM java virtual machine, GNU Classpath (including gjar, gjavah and maybe some other utilities), and ecj (the Eclipse Java compiler, which is written in Java). This is enough to run and compile basic Java apps. For instance, the popular Java buildtool Ant can run on Haiku.

Anyway, the reason I was investigating this is because the University of Auckland has a big Java library (a database, actually) that has been developed here, and Christof and Gerald (my supervisors) want to bring it to Haiku. To do this, we require the ability to write code that integrates with both Java libraries, and the Haiku API. I looked at various solutions:

  • gcj compiles Java to C++, but seemed like too big of a port
  • Java Native Interface (JNI) allows for writing C++ code that hosts a JavaVM and calls Java code, but is tedious to write.
  • SWIG can generate Java bindings to C++ libraries, even allowing Java classes to inherit from, and override virtual methods in, C++ classes.

SWIG is a mature solution that handles writing lots of JNI code, and the input files are pretty much just C++ headers, so it doesn't require too much tedious work. Given these points, I decided to go with SWIG, and I have put the results (so far) on Github.

Currently, I have two tests, one that runs a custom handler on the BApplication thread (also works running it on an extra BLooper) and listens for messages. The other test makes a very simple GUI using the Haiku API. Check out the result of this test in the image on the right. That's a BWindow with a BButton and a BGroupLayout and a BStringView, all created with Java code!!!

There are still some issues, but I'm really excited about the progress that I've made already, and I'm very impressed with SWIG! As I said in the README on Github, having Java bindings also opens up the door for any JVM language to use the Haiku API, for instance Jython, JRuby, and Scala to name a few. If you're interested in contributing, head over to github and fork the project. If you just want to try it out, it's really easy to do that, there are instructions on github in the README.

Language Bindings for the C++ API: Fourth Quarter Report and Post-GSoC Goals

Blog post by jalopeura on Sat, 2011-08-20 15:56

The following classes have been implemented; some methods and functions have not been implemented due to dependencies on unimplemented classes, but the classes below are otherwise complete:

From the Application Kit: From the Interface Kit: From the Storage Kit: From the Support Kit:
Application
Clipboard
Cursor
Handler
Invoker
Looper
Message
Messenger
Alert
Box
Button
CheckBox
ColorControl
Control
Font
Menu
ListItem
ListView
MenuBar
MenuField
MenuItem
OutlineListView
Picture
PictureButton
Point
Polygon
PopUpMenu
RadioButton
Rect
Screen
ScrollBar
ScrollView
SeparatorItem
Shape
Slider
StatusBar
StringItem
StringView
TabView
TextControl
TextView
View
Window
Entry
EntryList
FindDirectory*
Mime
MimeType
Node
NodeInfo
NodeMonitor*
Path
Query
Statable
Volume
VolumeRoster
Archivable
Beep*
Errors*
TypeConstants*

*These don't actually contains any classes, Errors and TypeConstants expose constants; Beep exposes functions; FindDirectory and NodeMonitor expose constants and functions.

The following classes were partially implemented, but had bugs that could not be resolved before the end of GSoC:

Bitmap
FilePanel
ChannelControl
ChannelSlider
ColumnListView
Gradient (and derived classes)
OptionControl
OptionPopUp

The following classes from the original timeline were not implemented:

Dragger
Shelf
Region
PrintJob

My goals for the fourth quarter were:

- Fix bugs reported by users (None reported)
- Add documentation (Done)
- Write additional example programs and enhance existing ones (Done)

The generator and interface language have been documented; the documentation on the classes themselves is still limited.

Post-GSoC goals:
- Add support for keyword-style entry
- Add support for functions as parameters if possible
- Add support for templates as parameters if possible
- Continue to add new bindings
- Fix bugs as they are discovered

I don't know how long it will take me to meet these goals; now that GSoC is over, I won't be able to spend as much time on this project.

The Python extensions have not been tested very well; there are two simple programs that test the basic functionality, and those work. In addition, work on the Perl test programs exposed a number of bugs that were due to mistakes in the definition files, which means that those particular bugs were fixed for Python as well. But there are very likely a large number of Python-specific bugs that will only come to light with more testing.

As always, the files are available via the project page: http://dev.osdrawer.net/projects/perl-haiku-kits/; as requested by jrabbit, the Python extension is also available via PyPI. The Perl extension should be available on CPAN soon; I'm waiting for approval of the namespace from the maintainers.

Note: To report bugs, attach a comment here or request to be added as a project member via OsDrawer.net so you can report bugs via the project site.

Language Bindings for the C++ API: Third Quarter Report and Fourth Quarter Goals

Blog post by jalopeura on Sat, 2011-08-06 08:10

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:
Application
Clipboard
Cursor
Handler
Invoker
Looper
Message
Alert
Box
Button
CheckBox
Control
Font
Menu
ListItem
ListView
MenuBar
MenuField
MenuItem
OutlineListView
Point
PopUpMenu
RadioButton
Rect
Screen
ScrollBar
ScrollView
SeparatorItem
StringItem
StringView
TabView
TextControl
TextView
View
Window
Archivable
Errors*

*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: Git Mirror, Gcc4, and Other Changes

Blog post by jalopeura on Sat, 2011-07-16 23:48

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.)

Language Bindings for the C++ API: Mid-term Report and Third Quarter Goals

Blog post by jalopeura on Sat, 2011-07-09 23:45

The following objects have at least partial bindings:

From the Application Kit: From the Interface Kit: From the Support Kit:
Application
Clipboard
Cursor
Handler
Invoker
Looper
Message
Alert
Box
Button
Control
Font
Menu
MenuBar
MenuField
MenuItem
Point
PopUpMenu
Rect
Screen
StringView
TextControl
TextView
View
Window
Archivable

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

Language Bindings for the C++ API: Python partially working

Blog post by jalopeura on Fri, 2011-06-24 01:21

I've just uploaded some files onto http://dev.osdrawer.net/projects/perl-haiku-kits/files They are minimal implementations (window with a button) for Perl and Python. The Perl one works fine, but I'm still having issues with the Python.

Here are some of the issues with Python:

Apparently by convention packages start with a lower-case letter. The bindings are currently in the 'Haiku' package. This would be a trivial change; it depends on how important it is to Haiku's Python user community.

PyModules and PyTypes (= classes) cannot share the same name, as far as I can tell. Thus, in order to have constants and plain functions available from (for example) Haiku.Application, the Application PyType must be in a separate namespace, currently Haiku.Application.Application. Depending on what the community wants, I could move all the constants and plain functions into the ApplicationKit PyModule, and have the PyType be Haiku.Application.

The really big problem, however, is passing objects. BWindow::MessageReceived gets a BMessage object. In order to pass this to Python, I need to have a PyType. But the PyType in question is defined in the ApplicationKit, which is a separate package. So I don't have access to it.

In Perl, this was not a problem; I simply used a string containing the Perl class name, and as long as the user had loaded the relevant package, Perl took care of it. But Python wants the PyType, not just a string. I'm still looking into a way to get around this problem. I'm trying to do it by eval'ing some Python code, but so far I have been unsuccessful. If I can't do it any other way, I could export the PyType from the other package, but then Python would be loading the .so and I would be loading it a second time, in addition to the extra overhead of exporting and importing. It just seems like a waste of resources.

In any case, the Python test script displays the window, and calls event hooks on the Application object (ArgvReceived, ReadyToRun, QuitRequested), but when you click the button and it tries to call the Window's MessageReceived event, it dies.

Language Bindings for the C++ API: First Quarter Report and Second Quarter Goals

Blog post by jalopeura on Mon, 2011-06-13 16:46

During the first quarter, I defined an interface language to use for creating the bindings. I had to create my own for several reasons. Probably the biggest factor was the need to know whether the target language has the right to destroy an object. Most of the target languages has some kind of automatic garbage collection; the programmer never needs to worry about whether to delete an object to free up memory. I didn't want to force programmers to worry about it when they don't normally need to. Therefore, I had to be able to mark whether an object was delete-able, so the generated bindings could delete it automatically if necessary.

I also defined preliminary bindings for a minimal test program, wrote a preliminary generator to create the bindings, and wrote the program itself (a simple application with a window which has a single button). The preliminary generator and the test program targeted Perl.

I also tried changing some data from the test program (with the interpreter running in the main thread) while in the MessageReceived method for the window (which should theoretically lock the window's thread). I was unable to make the program block, so I will need to continue testing for thread issues as I go along. Suggestions are welcome.

I in an earlier post that I would make a decision on target languages based on two criteria, popularity with the Haiku user base and ease of writing extensions. The popularity, based on a poll on the Haiku home page, is as follows:

42 51% Python
14 17% Ruby
12 14% Lua
06 07% Haskell
04 05% Perl
03 04% Scheme
02 02% Squirrel

As you can see, Python won in the popularity category, with over half the total votes and three times as many votes as the next highest language. Extension writing looks like it will be relatively easy as well. With good scores in both categories, Python will be one of the target languages. (In fact, I've already started work on them.)

I already know how to write extensions for Perl, which means it wins in the ease category. Since I did my initial tests with Perl, it will continue to be one of the target languages as I expand the number of bindings.

However, Perl scored quite low in popularity, so I would like to add another of the more popular languages as well. Ruby and Lua both scored more than 10%. If I am able to get the Python bindings working in time, I will research extensions for those two languages. Their scores were close enough that ease of writing extensions will be the deciding factor here.

Report on first-quarter goals:

- Define an interface definition language (Done)
- Define preliminary bindings for a minimal test program (Done)
- Write a preliminary generator to create the bindings (Done)
- Write the minimal test program (Done)
- Test threading issues (Will continue into the second quarter)
- Make a final choice on target languages (Done)
- Expand preliminary bindings and add new bindings (Not done)
- Write test programs for the bindings (Not done)
- Write documentation for the bindings (Not done)

My goals for the second quarter (including the ones brought forward from last quarter) are:

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

Syndicate content