gsoc2011

Language Bindings for the C++ API: Test Program Now Runs

Blog post by jalopeura on Thu, 2011-06-02 19:49
, , ,

In my last blog post, I mentioned the following goals:

- Define an interface definition language
- Define preliminary bindings for a minimal test programy
- Write a preliminary generator to create the bindings
- Write the minimal test program

These have now been achieved, and the minimal test program (in Perl) runs. It shows a window with a button, and the button label changes when the button is clicked.

It still has problems, of course. For example, after 32 messages pass through MessagesReceived, it dies. But it's nice to see something actually running.

Anyone who would like to test it may check out the code at http://svn.osdrawer.net/perl-haiku-kits. There are instructions for generating and compiling the bindings in the repo.

The priority goals remaining for the first quarter are:
- Test threading issues
- Make a final choice on target languages

These additional goals (mentioned in the last post) may need to be postponed to the second quarter.
- Expand preliminary bindings and add new bindings
- Write test programs for the bindings
- Write documentation for the bindings

ZFS Port: Community Bonding Report

Blog post by GeneralMaximus on Mon, 2011-05-30 19:39
, ,

I was busy with finals throughout the Community Bonding period, which left me with little time to work on GSoC-related tasks. I still have 3 exams left with the last one being on June 7. That's when the fun starts. For now I'm merely playing with ZFS on FreeBSD on a virtual machine. I still need to make my way through at least the ZFS On-Disk Specification. Even though the information contained in this document is not strictly required for porting ZFS to Haiku, it's a useful read nonetheless. It also makes me look like a rockstar when I open it in coffee shops.

According to my proposal, this is what comes next:

  • Finish porting dependencies (libavl, libnvpair, libuutil, libumem).
  • Begin writing an OpenSolaris compatibility layer. This involves studying how threads, mutexes, condition variables etc. work on Solaris and then writing wrappers that behave in a similar manner around the Haiku API.

This means approximately one week spent on porting and testing dependencies and a fair bit of time spent on learning about low-level Solaris interfaces. One week is an optimistic estimation for a port of any kind, but some of the dependencies are merely libraries that implement useful data structures. This means they might build on Haiku without major changes. I can't say anything further unless I've taken a better look at them myself. The end result of the quarter term should be an OptionalPackage that contains all the external ZFS dependencies.

June 7 is not far :)

Contacts Kit, Community Bonding Period

Blog post by Barrett on Mon, 2011-05-30 11:17
, , ,

During the community bonding period, i have researched around the project to prepare my work for the coding days that will follow.
I also promised to talk with the other devs in the ml, it was not necessary in these days...i'm working with the help of Alex to a document describing the entire API in order to discuss it in the ml.

The first problem was to choose a Default Media Format for contact translators, my choice has been addressed to a flattened BMessage. BMessage will be used internally by BContact to represent the contact fields and the state of the object. BContact will be also a BArchivable object.

All that could look strange for a naive, but there are some aspects that should not be underestimated :

  1. Easily sendable through applications and network (useful in future when sync support will come)
  2. Make simple to save the state of an object on a disk and then restore it at the next boot

So one of the most important aspects of BMessage is their flexibility in storing informations. The contact kit will define a set of fields used to represent a generic contact in memory, but it's too restrictive! Apps and addons should be able to define custom types of fields since the API cannot in any case define a set of fields generic enough to support every existent and future API. This is already an obscure side for me and i need some hours to make clarity and choose the best solution.

Portable Contacts

Portable Contacts is REST API using OAuth with the aim to provide a generic access to contacts from different services, at the moment it support many services like the OpenSocial platform. Who has read my proposal probably remember something about a "Google Contacts Services Add-On". I have decided to switch it into a "Portable Contacts Addon". For more informations : http://portablecontacts.net/.

Goals For the first quarter

  • A little patch for the translation kit to support the Contacts translators
  • Basic BContact Implementation
  • vCard and People translators

Goals for the First Quarter of the GSoC 2011

Blog post by gabriel.hartmann on Mon, 2011-05-30 06:03

In the community bonding period I made some brief contacts with my two mentors and did some reading of specification for UVC devices as well as the header for the current USB kit. My mentors confirmed that the EHCI interface for isochronous transfers with USB devices is not working properly and does not have a good set of tests. Neither my camera nor my mentor's camera are successfully engaged by Codycam at the moment. Fixing this fundamental connection issue is the first priority for the first quarter of the GSoC period, before moving on to working on the UVC driver.

The GSoC is organized around a northern hemisphere summer and I am still finishing off my semester at university at the moment, so coding for Haiku hasn't been a possibility. A 100 page dissertation, final reports, projects and exams unfortunately take precedent at the moment. On June 7 I will have finished most major projects and only exams will be left. Exams shouldn't be a big deal, so I should be able to start development at that point and can hopefully make up for lost time.

I'll have more to report once I've gotten my hands dirty.

Batisseur project update: Summary of work done and crystal ball into the future.

Blog post by jrabbit on Sun, 2011-05-29 14:41
,

Some of the clearly amazing things that got done during the community bonding period were:

I also discovered that Buildbot (Mostly its dependency: Twisted) don’t play nice on FreeBSD, the platform which currently builds Haiku nightlies on Matt Madia’s server. It’s not a huge priority to me at this point but it appears a bug still exists and will have to be filed (on my list).

On my list for the first quarter is finishing Command Not Found, and beginning work on the git tools and web services for package developers.[My actual project.] These tools can be developed while the package-fs work is in limbo or hpkgs mature. Command Not Found is a little script (if the install has python) or message that hooks into Bash’s command not found system and informs the user of ways to get this software. (i.e. you type in ruby but haven’t installed it or know that we have installoptionalpackage ruby, it will kindly tell you we have it.) Ubuntu has this feature in recent releases, and has an optional feature that may be interesting to use, spelling correction. It will be optional.

Command not found will be a way for users to be educated about Haiku even if they dive straight into the Terminal like a Unix user without reading any documentation (Like me!).

VBox guest additions: end of bonding period; first quarter goals

Blog post by scgtrp on Wed, 2011-05-25 10:25
, ,

During the community bonding period I played around with the existing guest additions patch, getting it to build and switching my repository over to git to preserve my sanity. I've learned a lot about the way Haiku drivers and modules work, especially in the last few days, and it seems that a few things are simpler than I originally thought they'd be and some things are more difficult.

As an example of the latter, it turns out that drivers can't provide APIs to other drivers; only modules can do this. This posed a problem for the shared folders module, which needs to either be in a separate module or contain extreme hackiness. As a driver, the original vboxguest couldn't allow vboxsf to use its API. To solve this, mmu_man and I decided that the best first task would be to break up the existing vboxguest driver into a module (vboxguest) containing the guest additions and a driver (vboxdev) which exposes the library to userspace as /dev/misc/vboxguest. This is now finished.

It turns out guest properties and clipboard sharing are already working, and mouse pointer integration is at least partially implemented, though I've not managed to get it to work yet. This should free up a bit of time for some of the other things.

As my first major subproject, I'm planning to implement a shared folders filesystem module - as I (and possibly a couple of other students?) are coding exclusively in VirtualBox, it makes sense to focus on the things that make development easier first, and being able to share files with the host is certainly useful at times.

Language Bindings for the C++ API: First Quarter Goals

Blog post by jalopeura on Wed, 2011-05-25 09:03
, , ,

During the bonding period I looked into Python's extension tools; they seem to be straightforward and at first glance look relatively easy, so Python is definitely an option. I asked on the mailing list what other languages people were using on Haiku, and Neil kindly made a poll based on the results. Depending on the popularity of the language (based on the poll results) and the ease of writing extensions, I will make a final decision on which langauges to target during GSoC.

I also looked into various ways of defining the extensions. I have decided to use an interface definition and generate bindings from that. I looked at pidgen's IDL, but it didn't have all the necessary information. I also considered parsing the header files directly, but that would also lack some necessary information. I am currently working on defining an SGML-esque interface language. Using an SGML-like language means that if a new target needs information not currently contained in the interface definition, this information can be added without disrupting the parsers for existing targets. SGML also compresses nicely. I am, however, still open to suggestions for other solutions, since I haven't (yet) put enough time into this one to be irreversibly committed to it.

My goal for the first week is to get minimal functionality; I have selected Perl as the target for this portion because I already know how to write extensions for Perl. I am implementing enough of the Application, Message, Window, and Button objects to write a small test program. This should let me work out any issues with the interface language.

Once this test program is working, it should also allow me to test for thread issues. While I could deliberately write a program that blocked, what I'm looking for is situations where C++ would not block with equivalent code. As soon as the test program is working, I'm going to look at changing some data via the from the target language (running in an interpreter in the main thread) when called from Window::MessageReceived (running in the window's thread). If anyone has any other suggestions for creating blocking situations, let me know.

After I have made the final selection on target languages and determined the best way to avoid thread issues, I will continue by expanding the interface definitions used for the test program and creating new interface definitions for additional classes. I will also need to document the interface definition language and each of the classes. Class documentation, at least initially, will consist of the differences between the C++ interface described in the Be/Haiku Book and the interface for the target language in question, along with a link to the relevant page in the Be/Haiku Book.

Unfortunately, I haven't been able to stay online much so far. We have company visiting us, and they're staying in the room with the wireless router/modem. Since Haiku can't do encrypted wireless, and I can't use the only space physically close enough to the router to use an ethernet cable, I have to leave Haiku and boot into Windows whenever I want to use the internet. I tried running Haiku from the physical drive with VMware in Windows, but it's too slow. Does anyone know whether VirtualBox can use the physical drive, and if so, is it faster than VMware?

In summary, my goals for the first quarter are:
- Define an interface definition language
- Define preliminary bindings for a minimal test program
- Write a preliminary generator to create the bindings
- Write the minimal test program
- Test threading issues
- Make a final choice on target languages
- Expand preliminary bindings and add new bindings
- Write test programs for the bindings
- Write documentation for the bindings

Syndicate content