Blogs

WiFi stack - coarse design overview As you can see there are two distinguished areas, one is colored green the other blue. Green shows already existing infrastructure, blue shows the infrastructure I'm going to provide. The arrows should be read as “depends on, uses features of”.

So the blue ellipse encapsulates the blueprint of the WiFi-stack. The inner structure of the yellow box, saying “WiFi-Stack” will be my next task. The main reasons for designing a Haiku-specific WiFi-stack (in contrast to modify/port the FreeBSD one) are to utilize Haiku's strengths (multithreading, object orientation, ...) and to get smaller driver code (due to lack of all the FreeBSD compatibility code).

After accomplishing the yellow one, I'll pay my attention to the yellow-red gradiented box saying “FreeBSD-Adapter”. This adapter will allow to use FreeBSD's WiFi driver and use them in Haiku with just recompiling them. As you can see this is the same idea as realized for LAN driver's by Hugo Santos.

This week i've been working on a big red post-it that was on last week's picture. It was about wo things : make the catalog handling tools work as build tools, and test them in some special cases.

The first part took me almost the whole week. I started doing a full port of the locale kit, but noticed it would probably be too complex to do that. Instead, I started over with a simpler solution. I only compiled the tools I needed, statically including the catalog add-ons inside them. It is now possible to extract the keys (original string) from a BeOS program, translate them to a new language, and integrate them in the Haiku Image. I did not have much problems with C++, but Jam caused me some difficulties, as I had never worked with it before except copypasting things around to integrate my code to the haiku image. This time I had to build up a new part of th toolchain, creating two rules and two actions. Ingo helped me a lot on that and now I have a better understanding of the whole Jam system. The rules I wrote are still not perfect, there are already some plans to make them simpler to use.

The second part of the post-it was about checking if collectcatkeys could extract strings correctly from sourcecode if they contained escape characters (\", \n, \t). Of course, that did not work at all. The problem is that we have to remove these escaped characters at some point and replace \t by tab, \n by newline. gcc will do that when compiling something, so if the program asks us to translate a string, we have to have it in unescaped form. This is currently done in collectcatkeys. But the change I made to collectcatkeys make it save the extracted string in a simple text file, and worse, I use tabs as delimiters. So this unescaping work will have to be done in linkcatkeys instead. This way, it is possible to translate the string easily, and then it is converted so the program will still find it back after compilation.

So, work for next week will start with a cleanup of my jam rules if I manage to do it (I'm still not very skilled at Jam), and fix of this quite important bug. But, next week I will be at the RMLL with some other Haiku developpers, so I'm not sure I will have much free time for coding. Well, there will be at least the hours I will spent in the train to go there.

Also, Oliver has made good progress on the wchar_t fixes. So I'm getting ready for messing with ICU and integrating it in the API. First step will be to build it with the new wchar-fixed gcc, then to make sure the tests are working ok before I do any integration work.

Finally, I also plan on making the Locale Preflet the first fully localized application in Haiku. This will allow me to test the catalog part and some other features such as the broadcast BMessage sent to all applications when the user change the default system language. The locale preflet will serve as a reference implementation of what to do when localizing an application.

After more than a week of thinking, "Today is the day I'll write that blog post", here I am with a status update on my HCD2009 project. I have only a few more points to add to what Matt has already posted here.

First of all, the previously unnamed full text indexing and search tool now has a name: Beacon. The indexing daemon currently in the works is called beacond. This is what beacond can do right now:

• Monitor files for changes and add new/modified files to the index. Only plain text files are supported for now.
• Handle mounting/unmounting of BFS volumes. Start watching volumes when they are mounted, and stop watching them when they are unmounted.
• Selectively exclude certain folders from being indexed.

Right now, I'm mostly concerned with polishing beacond. A few short term goals are:

• Reduce memory usage. Currently, beacond eats up about 60MB of memory, which is way too much for what it does.
• Perform the actual indexing operation in a separate thread. This is required so that the daemon does not become unresponsive during long indexing operations.
• Write a small tool which can search the index created by beacond (for demonstration and testing purposes only).
• Several minor tweaks (properly saving/loading settings, better build system etc.).
• Write a few DataTranslators so that beacond can be tested with different kinds of files. PDF is top priority.

In the long run, my major goals will be (1) seamlessly integrating Beacon with the existing Find tool in Haiku and (2) supporting more file types. But for now, the focus is on getting the daemon right.

If anybody wishes to check Beacon out, here is the project homepage (hosted on Google Code).