The results were unsurprisingly similar to x86: 92% of the tests are passing. Given that libraries differ in version from the ones I have on my development machine, and that the baselines were not readjusted to match the different environment, it is a pretty decent score. Environment discrepancies aside, there were some real failures as far as I can tell — some of them are already fixed and should hit upstream soon.

Also of note: by using a similar approach to obtain the text baselines, more than 5200 pixel test baselines were created. After a couple of bug fixes, results remained with 95% acceptance.

Recently, we’ve been hard at work to implement the much needed testing infrastructure to not only help fix and identify bugs, but also to ensure that fixed things won’t break in the future. This infrastructure is implemented by all major ports, like the Mac port, all the Chromium ports, the GTK and Qt ports, etc, and is comprised of a port-specific part, and a port-independent part.

The independent parts are scripts that gathers the (currently) 20000+ tests and feeds them to the port-specific parts, to compare with outputs generated previously with the same tools.

Since some things depends heavily on how a certain platform behaves — font hinting, for example, is largely dependent on the platform — baselines are provided for each platform, in addition to “generic” baselines for some tests. This is one of the reasons the WebKit repository is so large: the LayoutTests directory weighs about 1.4GB of tests and baselines for all the ports.

The platform-dependent part has been implemented and is in the process of being upstreamed. It is comprised of two tools, basically:

• DumpRenderTree, which, as the name says, dumps a textual representation of all the objects that will be used to render the web page — it performs a little more than that, of course, so that the output is in a known state before dumping the output;
• ImageDiff, which compares two images and, if a significant difference is found, outputs the percentage of pixels that changed and a third image that highlights the regions of change.

With these tools alone, and without any EFL-specific baselines, the port manages to get about 72% of acceptance. Given that most web pages renders perfectly under WebKitEFL, this score can be improved. However, as stated, there are a lot of tests, and manually checking each one would be very impractical and time consuming.

By writing a script that would compare the textual output of our DumpRenderTree with the baselines for other ports — and consider the output of the EFL port correct if within certain thresholds, the acceptance went up to 95%, which is pretty satisfactory.

There are still 5% of tests that are not passing,  either because of an unimplemented feature being tested (in which case, the test is temporarily skipped), or because some more deep debugging is required to improve the score. There are the occasional crashers as well, usually after merges with upstream.

The next step is to set up a bot that will periodically execute these tests and warn for potential breaks or changes of behavior.

Using ideas found scattered over the web, such as Github’s build indicator light, I’ve cooked my own buildbot monitor using a mail indicator bought from a Chinese store (which is really just a RGB LED with an USB interface). A simple Python script polls the buildbot status page every 15 minutes and changes the LED color to be either green or red, depending on the build status. Click on the photo for a full-sized version.

Why use something like this instead of a notification area icon, you ask? Well, this looks way nicer and displays the status even when my screen is locked and I’m away from my computer.

For those unfamiliar with this kind of stuff: the EWS bot will download every single patch submitted to WebKit’s Bugzilla, apply it with a clean tree, and then build the port. If the patch couldn’t be applied, or the build fails, a red bubble shows up in Bugzilla right beside the patch to warn the submitter that there might be a problem with it — clicking this bubble gives the build-webkit script output to give a clue of what happened.

The Buildbot does roughly the same thing as the EWS, with the exception of only running patches that actually went to the repository. Because of this, it performs incremental builds: there is no need to clean the build directory, so each build cycle is pretty fast: if no files relevant to the EFL port has been touched, a cycle will take about 30s, way faster than the 15minutes of each EWS cycle.

Both bots are being run on CPU time donated by Samsung Electronics. Currently there is only one machine running both bots, but more will be added soon.

Last, but not least: with the help of Buildbot, we know which revision is building or not, so expect weekly snapshots of WebKit EFL.

Without further ado, the source code (and other information) is available on its official web site. Enjoy!

This browser is a complete rewrite of the old Eve web browser, and is meant to be used on mobile devices. It is currently pretty complete, including tabs, bookmarks, and history. It also looks good to boot (thanks Marina!), as it is based on the Efenniht theme (click to open a larger version):

Screenshots won’t make it any justice though, as Eve is capable of some nice and smooth animations. I’m too lazy to make a screencast, so you’ll have to download and run it locally to see the interface at work

So Enlightenment users can benefit from this project, I’ve committed it to the Enlightenment SVN repository (on /trunk/eve). Also, there are some things that I didn’t have time to implement, so open sourcing this seems to be a nice idea: so, if you’d like to dive into the code, there are a few things that I’d like to have implemented on the browser… bug me on IRC (acidx @ freenode).

This will eventually speed up the maintenance of the EFL port, as build fixes do not require to be reviewed by someone else, and thus don’t require the use of the usually crowded commit queue.

There are various ways to get a monster like WebKit to compile faster, such as using ccache or icecream.

CCache is nice because I’m working with the build system, so I have to rebuild the whole thing often, even if I didn’t change a single line of code: ccache saves the object files somewhere in your home and only copies them instead of compiling it again, if there were no changes to the source code.

Icecream is also nice. Forked from distcc, icecream allows to distribute the compilation to other computers: add more nodes and the compilation goes faster. Compiling the kernel was never this fun before I’ve used this thing. There are some Gentoo users at ProFUSION that probably enjoys this thing as well.

And even though Icecream offers a nice program called Icemon with some nice visualization options, it is written for Qt3 — it works with Qt4 using the compatibility libraries — and crashes often. Since I was too lazy to debug this program, I’ve decided to write my own.

Called Picolé, it is an web-based monitor program. It felt natural to do a web-based program because I was working with WebKit; also, it can be installed on a server and there is no need for specialized client applications anymore. And since I’ve been longing to create something using AJAX for some time, this was the perfect opportunity.

The user interface is pretty simple. It offers two views: Hosts and Jobs.

Picolé’s main interface (click to enlarge)

The hosts view can display all the Icecream nodes in the network either in a table, or by using a star view, similar to the Icemon one.

The jobs view displays all the jobs being processed right now, and tells the language, file name, node that asked the compilation and node where the compilation is being performed.

The server is written in Python (using webpy) and it communicates through pipes with a program, written in C++, which communicates with the Icecream’s scheduler. The reason I’m not using a single programming language is that I didn’t want to rewrite the C++ part in Python, because I am using the same classes used by the Icemon program.

I got permission to distribute Picolé’s source code, but I need to clean it up and fix some stability problems. I’ll let you know whenever this happens.