As seen in Ingo's excellent presentation on Haiku's built-in debugging tools, our graphical debugger, while getting quite capable, is still missing a number of important features. As such, I made it my goal this week to try and resolve as many of those as I was able to.
The ARM is moving
After porting the basic VM code from X86 to our ARM port, it has been pretty much 2 years since I worked on it. Last weekend, BeGeistert 026, gave me a chance to work on it again, for a couple of days (nights?) in a row, and I tried to make the most of it.
Besides working on Haiku/ARM it was great to meet up with many of the people I already knew but had not seen for a long time, as well as finally meet the new people behind the names and posts I had followed over recent times.
Hi there !
This week was the BeGeistert coding sprint. I assume you already read the great report at IsComputerOn about the conferences for this week-end, so here’s just a summary of the work done durint the coding sprint.
ARM Port - Ithamar Adema, René Gollent, Adrien Destugues
Ithamar was holding the keyboard on this one. He's working on low-level Android stuff as his paid job, so he has a good understanding of the hardware and the Linux kernel that serves as a reference.
The ARM port was started as a Google Summer of Code project back in 2009. The project got the kernel compiling, and the bootloader working. Things more or less stayed there after that. However, with the recent release of the Raspberry Pi and some other cheap ARM-based hardware, there is interest for ARM again.
Some of you may know that for quite some time, on and off, I am working on a rewrite of WonderBrush, the graphics tool that comes bundled with Haiku releases. Since I have last demonstrated the prototype publically, I have occasionally found the time to work on it some more. I’ve ported over most brush tool related code from the original WonderBrush. And in the past weeks, I have specifically worked on a new text tool (written from scratch).
Hi,
as part of my PhD thesis at the Uni Auckland I would like to do a web survey about Stack & Tile.
Stack & Tile (S&T) is an extension of the window manager used in HAIKU. S&T allows the user to stack windows on top of one other or tile windows beside each other.
With the questionnaire we would like to gather some information about how and how often people are using S&T. Even if you never tried S&T before or you don’t know S&T at all, we have some general questions for you and we are interested in your feedback! If you don’t know S&T please take a look at the Haiku user guide *).
First of all, I apologize for the delay. I have now returned from my vacation,
had a few days to settle in and explain to my neighbours that I'm not dead (!).
Anyways, on to the interesting stuff.
On the surface, the status of things is mostly the same as in my last report,
with a few bugs less. I thought I had dedicated more than enough time for
bugfixing, but that turned out to not be the case. This is partly due to the
slower development cycle when testing natively (compile, copy driver to image,
boot virtual machine, test, repeat), and the bugs only showing up after doing
several resizes with other IO going on. All the bugs of this kind that I know
about have been eliminated.
To summarize the things I have accomplished during the summer:
- Resize support in BFS driver, save for vnode mapping and growing a full
file system.
- Getting the resizing "pipeline" from userspace to driver to a working
state (still needs some checking to verify that it's robust).
Recently I spend some time to develop ALE the Auckland Layout Editor and now it’s getting time to release a first testing version! ALE is a tool for developers to create GUIs. These GUIs can then be loaded from an application. This first version is still very basic and I hope I can get some feedback what can be improved and which features are most needed. It mainly focus on layout creation and less on editing view properties.

Friday, August 24th marked the end of
Google Summer of Code 2012.
This was the sixth year that the Haiku project participated
and was one of 180 fellow mentoring organizations.
This year, five of 1,212 students were mentored by Haiku.
To give a frame of reference to the competitiveness in Google Summer of Code,
over 400 mentoring organizations and over 4,000 students applied to participate.
For both mentoring organizations (and students), it is an honor and pleasure
to be selected in Google Summer of Code.
For those not in the know, Google Summer of Code is "a global program
that offers student developers stipends to write code for various
open source software projects". In other words, simply by being one
of the mentoring organizations, many youthful computer-savvy students
may learn about HAIKU for the first time. For a carefully selected few,
they have the opportunity to receive priority from our mentors in
teaching them how to develop software for Haiku. This is a unique opportunity,
as there is no other outreach effort of this magnitude available to the Haiku project.
Since the three-quarter term report, I have continued porting userland servers and apps. The app server is fully functional, as are Deskbar and Tracker and a few other apps. I also cross-compiled all of the basic development optional packages (GCC/Binutils, autotools, make, etc.) for x86_64. Another screenshot showing the current state of things is below:
the last quarter term is mostly spent on acpi cpuidle driver implementation. I also spent about 2 days to adjust the cpuidle framework so that the cpuidle generic module is loaded by lowlevel cpuidle driver, while the later will be loaded during boot up either by bus enumeration or calling get_module() manually. I also tested the power after acpi cpuidle driver is finished. The result is as good as intel native one. Since all the goals defined in my proposal are achieved, so the project is successfully finished.