Planet LittleChina

After working on Canola for the past couple of months, finally we get to see it released. Hopefully people will like this new version, which is both faster and more stable (or less stable, I’m never quite sure which one we picked). We’re now back following the latest revision of the Enlightenment Foundation Libraries, which allowed us to make the UI experience alot smoother (check it out by going to the Photos section). Also there are a bunch of new features and lots of bugs fixed, so try it out yourself and tell us what you think. Hopefully now development of Canola will get back to more regular releases, and we’ll start seeing more external plugins being developed (such as the flickr plugin being done by Thomas Schimdt, available here).

For this release we went above and beyond the call of duty, doing tests that no one had ever done before (at least to our knowledge). That’s why we can say, with much confidence, that Canola works perfectly while drinking in Buenos Aires:

Canola in Buenos Aires

Testing in other capitals will ensue. Cheers !!!

So you’re programming on Rails 3 and you want to see how your 404 or 500 error page looks like to the end user. You think “that’s easy, all I have to do is run in production mode”, right? Yo do that, run to your browser, type in a bogus address and voilà… A stack trace! Wha..? I thought I was in production mode, shouldn’t I see the red default error page that comes with Rails (or your custom one)? Well, you are, and yes, you should. But that’s not how things work right now.

What happens is that, even in production mode, Rails shows you the stack trace if it sees that the request is coming from localhost. Previously, on Rails 2.x, this was decide by the method local_request? which lived in ActionController::Base, so all you had to do (according to the docs) to fix that was to override it on your application controller with something like:

def local_request?(*args)
  RAILS_ENV == 'production' ? false : true
end

But on Rails 3 (since this commit), exception handling isn’t done inside the controller anymore, it’s Rack-based, and so is the local_request? method. That means you can’t override it from inside your application controller anymore. And there isn’t properly-exposed API or documentation for how to work around this, so you’re screwed!

Oh wait, it’s Ruby, right? What’s another monkey-patch anyway?

So here it goes:

# Put this at the end of config/environments/production.rb

class ActionDispatch::ShowExceptions
  def local_request?(*args)
    false
  end
end

Hopefully this will be more properly configurable in the future.

A recent article from lwn.net shows ProFUSION in the most active employers for networking stuff in the 2.6.35 release cycle.  That was due to the work we did in the Bluetooth stack implementing the L2CAP Extended Features (see older post in this blog to learn about L2CAP Extended Features).  Nice!

As part of the Power Developer developer’s program, I received from Genesi one of their amazing Efika MX nettops. Other people have already posted about the unboxing process (for example darkside or brunocardoso), but I still want to throw a few screenshots to show it.

Efika booting

Recently there were big improvements made to the EFL on ARM platforms, but even without those optimizations and running on a 1680×1050 screen, E17 is running perfectly fine. Here are a couple of screenshots I made (the second one was taken with a camera phone, so it’s slightly worse to look at, I’ll try to put a video showing how well it’s performing on youtube later):

One of the initial versions of the Efenniht theme, with the obligatory Flame/Penguins/Snow modules enabled

Latest Efenniht version, with the Everything module on the center

I’m going to setup daily builds of the EFL running on it (plus weekly Ubuntu packages) so that it can help out stabilizing the arm port. The static analysis runs with clang of the EFL code that I’ve been doing are now on a new location, and I’ll also be running them directly from the Efika.

I’ll soon update the blog with more cool stuff I’ll be doing here (got an OE build for it about half done), but for now I just want to thank the folks at Genesi for this opportunity, and I’m eagerly waiting to try out the Aura firmware they are working on.

Hey everyone, it’s being a while since my last post. On 5th March 2009, I submitted a proposal to Power Developers to actually improve the ARM Cortex A8 support into the LLVM Compiler. The proposal was accepted in 24th August 2009, and the board arrived in late December.

Fresh new Fedex shipment with a EfikaMX board

After opening the Fedex box, this is what we found:

Unpacked efika board

The surprising news here, is that when I received the board all the improvements I had in mind and proposed to the Power Developers had already been implemented by other LLVM developers. Things not always go in the way we want to, but looking into the bright side I had a new shinning board to play with, and compiler backends always have room for small improvements.

So, first of all, lets look how this beautiful toy looks like. The “genesi” name actually reminds me of my good old sega genesis (good old times), but getting back to what matters, here is how it looks attached to an external monitor (using the HDMI port) and booting linux.

Attached to an external monitor

After booting up and gathering information about the system, I installed gnome and did play with some applications to see how efficient it was. It surprised me, it was faster than I expected, even without the proprietary drivers needed to use the video decoding processor. This is an album with all pictures I took from EfikaMX, they were all taken in the day I received the board back in 9 December 2009.

Before talking about what my current plans are I do have some greetings to do: Thanks very much to Genesi U.S.A., Inc and to Raquel and Bill @ Genesi, to being so kind providing a board and making llvm developers happier. Also I would like to apologize to them by the time I took to give them a feedback, sorry for taking so long

I’m currently in the USA doing a summer internship and my board is at Brazil right now, so until October I don’t have any way to give it attention, but at the EfikaMX/llvm/ARM side of things, these are future plans:

• Set-up EfikaMX as a linux ARM backend test machine, so we can run llvm test suite on it and be sure it gets working for linux (we don’t have that for linux in the moment)
• Consider the possibility to implement random small optimizations aimed to ARM/linux, as for example this gcc bug.

After more than 4 months working daily at ERTM, here at ProFUSION, we have now a functional and much more stable implementation. Several potential crashes have been fixed, and missing features were added. Also the code was checked against the Profile Tuning Suite(PTS) test software. That software is the official test software from Bluetooth SIG to qualify Bluetooth stacks and the result is that right now we are also passing all PTS tests.

On the bug fixes front, beside the kernel crash fixes, a lot of ERTM behavior bugs have been found and fixed. Some of them made ERTM flow crazy, but we have been able to discover and fix them all. Obviously there might be other bugs in the code, but I haven’t found them yet. ;)

New code added: All missing events and actions from the ERTM spec were implemented, they should be working properly now. Among them we have the Local Busy handling, Invalid Frame detection, etc.

The PTS software helped a lot with the ERTM development, I’m sure that we are much more compatible with others stacks now after fixing L2CAP to pass all tests for Enhanced Retransmission Mode, Streaming Mode and FCS.

Now I’m aiming at make the code base even more stable looking on the mainlining of this new part of the L2CAP code inside the Linux stack.  All the code should be available and enabled by default on the 2.6.36 release. If you wanna help testing use the for-next branch of my git tree:

http://git.kernel.org/?p=linux/kernel/git/padovan/bluetooth-testing.git

Maemo 5 PR 1.2 is out with Qt 4.6.2  installed, so developers now can create applications with Qt 4.6 using either the official scratchbox based SDK or MADDE (remember, “MADDE is currently a technology preview.”)

BUT… there are people who prefer “Livin’ on the Edge“. If you are one of those and already want/need to develop with Qt 4.7 (not released yet!) for Maemo 5, using MADDE to build your applications / packages, here is an update to the procedure first published by the troll Harald Fernengel (AKA harryF). Although the title says “on MacOS X”, the steps also work on Linux.

Step-by-step:

• Install MADDE. Download it here.
• If you are not using a Debian based distro, you need to install the “Tools for Debian Packages” package of your distribution (e.g. “deb” on openSUSE, sys-apps/debianutils on Gentoo).
• Download the script fetch-qt4.7.0~git20100520-0maemo1.sh fetch-qt4.7.0~git20100614-0maemo1.sh . This script downloads the libqt4-experimental packages from repository.maemo.org and installs then in your MADDE – Before you run the script, remember to adjust the MADDE_PATH variable according to the path you installed MADDE.
• Download qt4-maemo5-qt4.7.0~git20100520-0maemo1.tar.gz qt4-maemo5-qt4.7.0~git20100614-0maemo1.tar.gz. It contains the Qt tools compiled for the correspondent version, configured for cross compiling. Extract to /opt/qt4-maemo5.
• Check if mad is in your PATH.

To build an application using your fresh environment, run /opt/qt4-maemo5/bin/qmake && make .

If you succeeded in the setup process, this should result in a armel binary ready to run on N900. To generate a deb package, you can use the tools offered by MADDE to build a skeleton of debian package and so on.

To run your application on N900, install libqt4-experimental-* packages. If QtQuick (QML) is part of your plans, qmlviewer  is in the package qt4-experimental-declarative-qmlviewer .

UPDATE (2010-06-15): For newer (or older) versions, check http://anselmolsm.org/public/qt/madde-qt47/