My midterm goal was porting libzpool -- which contains most of the ZFS code -- to Haiku. Another midterm goal was to get ztest -- the ZFS testing tool --- to run on Haiku. Being able to run ztest in a loop for an entire day means that about 80% of the ported code is working fine (though the remaining 20% is the most difficult part of the entire porting process).
I’m in the middle of my planned vacation in New Mexico. I recently wrote a new feature for haikuporter emulating the style of homebrew’s create command. (It makes as much of the bep file for you as can be automated.) I’ve written a haikuporter (or later pkgman) wrapper to handle the achievements. It works like git-achievements you alias over the command and check the switches/commands. I’ve moved over some code to redis, and have gotten their development branch to build on alpha3 (Stable used to work back a few revs.
Alas the time of my contract with Haiku, Inc. is up. So besides giving some details about the query support and libsolv port which I've been working on since my last post, I'll also summarize where Haiku's package management stands now and what still needs to be done.
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.
Shares fully working! Slightly slow, but usable. Clipboardy stuff too.
I’ve now fixed most of the bugs in the guest additions, to the point that what’s done so far is mostly usable - the only major bugs remaining are some random crashes in VBoxService that I’ve not been able to reproduce, and an inability to drag icons when mouse pointer integration is enabled. (Thanks to kallisti5 for finding both of these.
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.
Since my last blog entry a lot of progress has been made. Currently I’m right on the cusp of actually producing images on the screen that have been captured by my camera. Successful communication is occurring between the driver and the camera in at least two different forms.
The first form of communication to be successfully implemented involves the setting of values within the camera which affect image capture. These are the familiar brightness, contrast, sharpness etc. settings which most cameras support. Nearly all of the options available to my camera are now presented for manipulation by end-users and successfully communicated to the camera. These values are maintained within the camera between power cycles and this fact is successfully communicated to the user via the available controls. The controls can be viewed and modified in the media preferences application or the cortex demo application. ParameterWeb control documentation indicates a range of different style controls within the continuous or discrete parameter varieties. However it appears to me that the only discrete value input method currently supported with an appropriate gui interface is the binary on/off option. This is suitable for features like the auto value for white balance which can only be either on or off. However the powerline frequency setting which has three possible values was unable to be represented with the appropriate discrete control of the B_RECSTATE type which has three possible states. To simulate this capability a continuous control was modified to only allow three values which are indicated by placing the sliding control within a +/-10 range of the desired value. The slider snaps to the available values to indicate this behaviour. One future feature which would perhaps be desirable is controls with auto settings which indicate in real time by their movement what values the camera is using in its auto mode. Right now sliders are simply frozen in their last position when the auto mode is in effect. I had some brief discussion with my mentors about this feature, but it was deemed to be unnecessary at this stage as a lot of work is left to be done in actual image capture.
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.
Here is a topic that for the longest time as a BeOS/Haiku developer, I had no idea how to do and didn’t really feel enthused on the concept of learning. Of course, now all the major platforms have desktop gadgets. Ironically, writing a replicant is really easy if you already know how to write basic Haiku GUI applications already. Find out how in this lesson.
Programming with Haiku, Lesson 21
Time does fly. It has already been two weeks since my previous blog post, so I guess an update is in order. The support for shine-through directories and the package links has been implemented as planned and works nicely as far as I have tested them. Other than that I've worked on a few odds and ends.
