gsoc2009

Locale Kit: (somewhat) weekly report

Blog post by PulkoMandy on Fri, 2009-06-19 18:42
, ,

Mid-term evaluations for GSoC are already coming...

I'm still working on the catalogs for translating applications. I got the system working and integrated it into Haiku, so now any application can be translated. However, there is still a lot of work to do. I'm now working on a plaintext catalog add on.

Catalogs are the files that store translated strings. There is a catalog add-on called "default" that is used in applications. The problem is that the files for this add on are stored in binary form (as archived BMessages), so it's not easy to translate them.

So, the plaintext catalog add-on will allow developers to extract strings from their source programs and easily translate them in a plain text file. Then it will be possible to convert it to a binary file for use in the application. This is simpler to code than a full featured translation tool (that may come later), and also allow testing of the add-on system.

This is about everything for the catalog system, the other part of the work on this project is the formatting toolkit with functions for formatting dates, times, and numbers. This should be done using ICU, a library that provides all the needed classes, but will be wrapped in the already designed Locale Kit API, which feels more in accordance with the rest of the BeAPI. ICU will also be used to manage a big part of the preflet : language listing, and mapping languages to presets for all the settings.

The last part of the project will be mostly centered on the preflet. It will have to send a message to all the application when the user select a different language, so all the opened window are refreshed automagically.

I have a little problem with my debian setup this week, and for now I can't build haiku under debian anymore. But I will try to build directly under haiku if possible to keep working.
Also, I just finished school exams last week, so from now I will have a lot more free time and I hope the project will speed up a lot.

Locale Kit: everything about catalogs and catalog add ons

Blog post by PulkoMandy on Mon, 2009-06-01 19:52
, ,

Today I have started to write a catalog add-on to save catalogs in plain text for easy translation. I've spent some time looking at the involved C++ classes, and here is what I found.

A catalog is a collection of strings, stored as pairs. It is used in the locale kit to translate the text in an application to the system language at runtime. When an application starts, it asks the locale roster to find its catalog and return it back. Then, each time a strig needs to be displayed, it goes trough the catalog and is translated automatically.

Catalogs are stored on disk, and can use various formats. For example, there are files originating from zeta's locale kit, unixish po files, and our own format or haiku. The app doesn't need to know which of them it is using, so finding the right one is the job of the locale roster. All the different formats are handled by catalog add-ons. Every catalog knows which add on it needs to use to do all the work of loading and saving. An EditableCatalog can be modified, it's not meant to be used by a regular application, but only by the apps made for editing catalogs. For now, we will use collectcatkeys to extract all the strings from a sourcecode and dump them to a plain text catalog. Then, linkcatkeys will convert this catalog to one in the native format, which is faster to parse at runtime. Later it will be possible to create an app that allows direct editing of the compiled catalog with a nice graphical interface.

This will allow me to easily create test catalogs in different languages and use them in my HelloWorld test app. Then, i will add language swtching to the locale preflet, and test it so the testapp updates all its strings in realtime when a new language is selected in the preflet.

Locale Kit : status update n.2

Blog post by PulkoMandy on Wed, 2009-05-27 11:51
, ,

These two weeks I've been quite busy with other things, so the project didn't move as much as I wanted. However, I managed to get the catalog engine to internationalize an app for the first time. It's not a big application, just a very simple Hello World test program. And the lack of a tool for translating catalogs means I had to edit them by hand to get the translation done.
I will be working in a Catalog AddOn writing a catalog as full text for easier editing.

So, to test the program, you have to

1) run make
2) mkdir obj.x86/locale
3) mkdir obj.x86/locale/catalogs
4) mkdir obj.x86/locale/x-vnd.Be-HelloWorldSample
5) cpp HelloWindow.cpp > HelloWindow.precpp
6) collectcatkeys -s HELO HelloWindow.precpp -o obj.x86/locale/catalogs/x-vnd.Be-HelloWorldSample/english.catalog
7) run the application
8) you can edit the last occurence of "Hello World!" in the catalog file to change what the app displays.

It seems that attaching catalog as resource or attribute to the executable file doesn't work yet.
You can get the project here: http://dl.free.fr/vqHTlU63B

Feedback is welcome :)

Locale Kit : status update n.1

Blog post by PulkoMandy on Sun, 2009-05-03 16:34
, ,

The work on the Locale Kit as part of the Summer of Code has already started :)
This week we have been working on proper integration of my work in the Haiku tree. So you can now checkout Haiku from svn and get the Locale Kit as part of it.
Of course, some parts are still broken (or not yet written), but some of the tests seems to be already working.

I'm now looking at ICU sourcecode to study the best way to integrate it in Haiku.

So, nothing much to say this week, but a lot of work done.

GSoC 2009 Project: CIFS Client Implementation

Blog post by Obaro Ogbo on Wed, 2009-04-22 17:20
, , ,

Greetings one and all!
I am Obaro Ogbo, one of the students selected for GSoC 2009. I also use the name nastee on irc and on Haiku Bug Tracker. I am a 3rd year student of Computer Science and Technology at Bells University of Technology Ota, Nigeria, and it appears I'm the first ever Nigerian GSoC student :-).

I began programming with Java, then learnt C before studying C++. I've done little PHP and Perl coding, however I'm learning Lisp presently. I participated in the Nigerian ACM/ICPC in 2007 and 2008 where my team came 3rd and 2nd respectively.

My primary OS has been linux (Debian/Ubuntu) since 2006. In my attempt to understand Operating Systems, I've tried lots of different OSes including OpenSolaris, GNU/Hurd and FreeBSD. I *discovered* Haiku in December 2008 but didn't run it till early 2009 and its quick boot time, responsiveness and general clean light feel got me hooked. It also seemed tailor made for me(an OS well developed, but very far from finished, so I can follow and participate in its development). I'm interested in low-level programming, but I've never really done any. I hope to get into kernel level development, understand compilers intimately and networking technologies.

Following is my project proposal as submitted.

Project Details

* Project title - Implement a CIFS client

* List of project goals

1. Implement haiku native filesystem interface
2. Copy data structure and header files that handle protocol definitions
3. Implement Protocol Negotiation, User Authentication and other session requests
4. Implement Directory requests
5. Implement file requests
6. Include encryption routines
7. Write a GUI frontend to mount cifs volumes
8. Implement Unix Extensions.
9. Optimize and test

* Description of project goals

1. fs_interface.dox and fs_modules.dox describe how to do this.
2. Linux's cifs implementation contains definitions for CIFS/SMB data structures which I'll largely use as is.
3. Implement LANMAN2.1 and NTLM 0.12 dialect negotiation, SESSION_SETUP, LOGOFF, TREE_CONNECT, TREE_DISCONNECT and File System Information queries.
4. Directory Requests are well documented in the SNIA/CIFS Technical Reference, I'll implement requests and actions for responses.
5. There are a large number of file commands, and I expect to spend the most time in this step due to that. Similar to Goal 4.
6. Implement NT and LM authentication modes and make default
7. Graphical frontend to mount a share with user providing servername, sharename, username and password.
8. These are small enhancements to enable Unix/Unix-like clients and servers exchange information used by both e.g symbolic links.
9. Mainly try to optimize features like read-ahead and write-behind, and test extensively

* Why I want to work on this project

- I hope to understand an Operating System in its entirety, preferrably one not fully developed, so I can follow design decisions and help code someday. Haiku provides this opportunity, and implementing this project will serve as an entry point. I enjoy learning new things, and I've already learnt so much from researching this project I can hardly wait to start.

Update DriveSetup/Disk_Device

Blog post by bebop on Wed, 2009-04-22 04:21
, , ,

I live in Honolulu Hawaii, I enjoy Surfing, Swimming, Sun and Code. I am working on my BS in Computer Science at the University of Hawaii at Manoa and minoring in Geography. Next year will be my senior year. I have taken courses in concurrent programming as well as networking. Next year I will be taking an operating systems course. I also have some experience in machine architecture and optimization. My current side project is writing an application for the Geography Department, that is a complete suite of tools for stereogrammetry. My professional work has been work on an electronic medical health records system based on the United States Veterans Affairs VistA system. I have more recently worked for Nanopoint Imaging Inc. working on live cell imaging and microfluidics software.

Project: Finalize Design and Implementation of the Disk Device Framework and DriveSetup Application.
I would like to complete the implementation of the DriveSetup application for Haiku. The application is a key feature of Haiku and is currently in the Haiku bug tracker as an Alpha milestone.

To Complete this task will require:

Disk Device Framework:

  • Collaborate with mentors to finish work on the Disk Device Frame work.
    • Add partition/partition map creation to the Disk_Device API
    • Add partition/partition map deletion to the Disk_Device API
    • Finish Intel Partition Add on, in particular finish Extended Partition support.
  • Design and implement modules that the team deems necessary to complete the Disk Device framework.

    DriveSetup:

  • Update the DriveSetup UI to reflect the changes in the API
    • Add creation of Intel style partition maps.
    • Add creation of partitions of popular file system types.
    • Add deletion of partition maps and partitions.
  • Adapt DriveSetup to Haiku's layout system.
  • Apply MVP design pattern to all newly created code.

    Implementing the Intel style partition map (MBR) and extended partitions (EBR) can be done by following the data structures that have been well documented. The source code from Linux, and the BSD's as well as the various partition tools could be used as a starting point for integration into the operating system. The creation and deletion of these structures on disk will then be dependent on how well the implementation follows the data structures. Writing the DriveSetup application should then be a matter of creating a mock up then designing the correct views from the BeAPI.

    BeOS sparked my interesting in alternative operating systems way back in 8th grade. Since then I have watched Haiku/OpenBeOS and have always wanted to help but was unable to write code. Now that I have some experience as a paid programmer I feel that I can finally make a commitment to complete a project I set out to accomplish. I feel that I would be a good candidate for the project because I have experience in breaking a project into small tasks that can be completed by a fixed deadline. I have also become good at making time estimates on how long a particular task should take to be completed. I also believe that I have the technical skills to finish the project that I have outlined above, and would be excited to be given the chance to do so.

    • Implementing ZeroConf support for Haiku with mDNSResponder

    Blog post by majie on Wed, 2009-04-22 03:43
    , , ,

    Personal Profile

    • Ma Jie
    • Brief bio

      • My name is Ma Jie, And Jie is my given name. I'm a senior college student from China. Although not majored in Computer Science, I still love to do computer programming in my spare time. I have a National Computer Rank Examination certificate on computer network technology and got third prize of a national Java programming competition. The PoorMan server of Haiku is my first contribution to the open source world. I learned a lot from it, and I think it's time to contribute my knowledge back.

    Project idea information

    • Project title

      • Implementing ZeroConf support for Haiku with mDNSResponder

    • List of project goals
      1. porting mDNSResponder to Haiku
      2. a mDNSResponder configuration preflet, which can be integrated into the network preflet in the future
      3. a services browser and notifier, which may be integrated into the Deskbar
      4. making PoorMan server utilize the ZeroConf network
      5. writing test cases and running the tests
    • Project description

      • There are two major implementations of zero configuration networking, Avahi and Apple's Bonjour. mDNSResponder is the underlying component of Bonjour. There are several reasons for me to choose mDNSResponder as the Haiku's ZeroConf engine. First, as Avahi is mainly designed for linux and BSDs, it uses GNU Autotools, while mDNSResponder uses handmade makefiles. Since Haiku's build system consists of a lot of Jamfiles, mDNSResponder will be easier to integrate into the source tree. Second, Avahi lacks porting directions. Finally, Haiku prefers Apache license that is more compatible with Haiku's MIT license to LGPL.

      There may be some difficulties when porting mDNSResponder to Haiku, because the cross platform support is abandoned and some gcc incompatible codes was added to the sources. I need to fix the broken codes during the porting procedure. mDNSResponder will run like other Haiku components. A server runs in the background and clients that want to use the ZeroConf services can communicate with the server by a library.

      Goal 4 not only lets the PoorMan server broadcast its service to a local network, but it can be a demonstration to other Haiku services on how to use the ZeroConf network.

    • Why do you want to work on this project?

      • I think I can work on this project, because I ported thttpd as the backend of PoorMan server to Haiku and I learned some useful skills on porting codes to Haiku. If I can work on this project, with these experiences I can do better in my future contribution to the Haiku project.

    Syndicate content