Leandro A. F. Pereira

Na última quarta feira ocorreu a segunda noite de introdução ao Arduino no LHC. Além de pizza grátis, quem participou teve a oportunidade de aprender sobre o funcionamento básico do Arduino: as funções setup() e loop(), I/O analógico e digital, delays, e até mesmo implementação de um protocolo serial via software.

As brincadeiras com I/O giraram ao redor de oito LEDs conectados em uma protoboard e aos pinos de I/O 0-7 de um Seeeduino. Um trimpot atuando como divisor de tensão foi usado na entrada analógica 0 para controlar a velocidade de marcha dos LEDs ou escolher qual LED acender, de acordo com o valor lido pelo conversor analógico-digital.

A implementação do protocolo serial via software, usando técnica de bitbanging, foi feita para interfacear um módulo de display da OSRAM, o SCDQ5541.

No próximo encontro, devemos brincar com registradores de deslocamento ou charlieplexing, para acender uma quantidade maior de LEDs, afim de construir um cubo.

No dia 20 de Outubro, ocorreu a primeira noite do radioamadorismo no Laboratório Hacker de Campinas (LHC). A idéia dessas noites é reunir pessoas interessadas em aprender sobre o assunto e fazer experimentos com rádio.

O Juba trouxe (e deixou no LHC) um transceptor de rádio amador, com antena dipolo e caixa acústica. Conseguimos captar, mesmo com uma instalação precária da antena nas grades da janela, sinais de outros países (ou pelo menos em outros idiomas, como Chinês, Russo e Espanhol), e algumas transmissões nacionais também.

Além disso, brincamos com uma USRP, que é basicamente uma interface para receber o sinal analógico do rádio e transmití-lo pela USB para processamento em software pelo GNU Radio. Rodamos alguns dos exemplos do GNU Radio e conseguimos sintonizar rádios FM comerciais e ver o sinal de walkie talkies GMRS (deu pra ver a portadora do sinal e as distorções que acontecem depois da demodulação, mas não conseguimos de fato ouvir a voz).

No próximo encontro, devemos fazer uma instalação melhor da antena e começar a preparar o material para conseguir a licença de estação para a Anatel. O Juba já tem licença de radioamador e eu pretendo conseguir uma também.

After a marathon to build WebKit EFL on a Pandaboard (setting up a reliable cross-compilation environment would take more time than I had at hand), I was able to test how WebKit EFL behaved on ARM. At least the ARMv7, little-endian, kind of RISC.

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.

WebKitEFL has gone a long way since it was upstreamed a year ago.

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.