Igalia – Page 7

Rss support on jhbuild-buildbot

Recently I have joined with Iago to make efforts on the work of the build brigade development, the continuous integration system for gnome.

The first task was install an work enviroment on my local machine, using the work of Iago and Dape on use the buildbot integration system on jhbuild, the tool to compile gnome modules.

At first I use the buildbot from cvs, but then I switch with the 0.7.5 version, as is the one the build brigade production page is using. But this work let me enter on the buildbot code, to make the neccesary changes to work with it, and start to see how is the python code, as I have no previous experience with it.

But python is an dynamic object-oriented programming language very intuitive, so I understand almost all.

Then, I started with a real useful task. The idea is add RSS support to this buildbot. To do that I start first using the Dape changes on buildbot to add feeds to the failed builds, but then I start to use the Lieven Govaerts work (based on Dape’s works). The advantage of Lieven work is that this adds new classes, creating a new file with this new classes, without modifying the buildbot code. This is more “clean” as we don’t need to add patches to the buildbot, or wait to apply these, and makes it easier to keep in sync with buildbot releases.

One of the buildbot advantages is that is really easy extend it. So view this more easily this is an summary class diagram:

On the diagram the white classes are the original buildbot classes, gray classes came from Twisted module, red classes are the ones which adds Lieven Govaerts and the green one is that we define in our custom buidbot.tac.

Well, one you reach this, review the code etc., you can think, “well nothing more to do!”. But we have a weird problem. This feeds takes the failed log builds and create a rss/atom element. In this case the build log are the jhbuild logs. And we have a problem with this. At first the rss failed, getting a crash on this line:

*** error during stage configure of cairo: ########## Error running ./configure –prefix /home/gnomeslave/devel/gnome/work/prefix –disable-static –disable-gtk-doc –enable-coverage *** [1/1]

So we go to the log, and we see some strange symbols on this line (and realize that the line appear two times):

*** Configuring cairo *** [1/1]
jhbuild: Configuring cairo [1/1]

Looking after this I have found the problem. jhbuild show his log in a pretty print way, showing some phases in bold and add the title to the current terminal. To do that it adds some special symbols. In the case of the bold, it uses “tput bold” to get the special symbol (as it can be different on each terminal). To the title it checks if it is and xtem or rxvt, and uses the special symbols 33] 07. But in our case we don’t need this, we only want the log as a plain text, as this will be used to be showed on the web browser. The log with strange symbols on the web page is only a annoying problem, but the crash on the rss feed is a real problem.

So I started to work on the jhbuild code, as the first idea was avoid to print this ones from the jhbuild. jhbuild has a configuration parameter called “pretty_print”, used to allow to print the output on the terminal in a enhanced visual way (colors, etc.) So my initial idea was include the bold and the title in the “pretty print concept”.

But this has a problem. It is easy to do, but I need to create a patch, add a bug on jhbuild bugzilla page, and wait this to be applied. Meanwhile, to use it we’ll be using and “custom jhbuild” and everyone who wants to install the jhbuild-buildbot scripts, need to take it into account, applying this patch. And, in my personal opinion, I don’t think that a patch that is only a enhancement required for an concrete project could be a high priority task for jhbuild guys. If I were an jhbuild maintainer I will ignore this patch for a long time 😉

At first I realize that the title is only set when an xterm is detected. So I tried to change the environment variable TERM to another terminal (vt100) and this works. Using this idea, I start to search a terminal with no bold support. Reading a little the terminfo manpage, and another related, I used the adm3, and this works!! 😛

So, to solve this problem, instead of modify the jhbuild code, you only need to modify it on your slave .bashrc file:
export TERM=adm3

Simple, no?

Well, this work is done, I hope that this will be released soon on the buildbrigade production page, enjoy it! 🙂

PS: on the lines which appears the strange symbols, I have removed this ones. This is because the planet.igalia.com feed started when I added this 😉

NVPerfKit 2.1 supports linux

When you are debugging a graphical aplication, using OpenGL, debugging is very complex. You can’t use the common debuggers, as gdb, because the graphical part are executed at the “server side”, at the card, therefore, managed by the OpenGL drivers, asynchronously with respect your program.

But, as in other programs, debugging and profiling a very important part of the development process, more important with the pass of the time, as the graphical cards are more and more complex, and make more and more work, not only graphical. For example, Havok creates and physical effects engine implemented over the graphics card, called Havok FX.

Recently, NVIDIA released NVPerfKit 2.1, a package of performance tools to help debug and profile Direct3D and OpenGL aplications, that for the first time supports Linux!! Its a good new. It isn’t free, and includes gDEbugger as a 30-day-trial version, but, well this is better than nothing 😐

When I was developing my Master Thesis (Proyecto de Fin de Carrera), I missed a lot some kind of tool to debug and test perform of my program, but, or this tools wasn’t released or my card doesn’t support it … so I need to use the “universal flag-method” 😉 to debug the aplication, and use and ad-hoc system to profile it. But well, at this moment there are some NVPerfkit tools that don’t support my card (well really, my card don’t support this tools, for example, don’t support GPU counters 🙁 ), so I would need to do that anyway.

Someday I will write a post about this project. I hope to someday I will get that this compile at linux, and migrate my “Hair Editor” to GTK, but “when I have some time” ….

Freeze Fisterra

I’m currently working on Igalia in order to get Fisterra better.

My firsts tasks was about obtain a good debian package for Fisterra, and then add documentation to the page. A good amount of developer manuals, installation manuals, and examples are important to understand a huge project, and Fisterra is a really huge one. This is important too to get a good comunity of people working on it (we are searching help, join us! 🙂 )

But recently, in a conversation with Alex, another Igalo, introduce me one technology: Internet Communications Engine, or sortly, Ice. Ice pretends to be a middleware similar to CORBA or COM. This was developed by ZeroC, a company founded by experienced CORBA developers. The idea is get a better middleware than CORBA. As ZeroC says, “we neither wish to start a “CORBA vs. Ice” flame war nor do we want to discredit CORBA. On the contrary, we believe that CORBA was a great achievement for its time, and obviously Ice borrows many good ideas from CORBA”. They only want to go to the next step.

I see the page and the features only a bit, but this looks great! And this was implemented by them himself, are complete, and are free (libre), using a GPL license.

Fisterra initially uses CORBA as the middleware for his communication layer, using the ORBit implementation. Then, adds support to SOAP, due some needs in a concrete project. And, what about uses Ice in Fisterra? This is a very interesting technology, and Fisterra was designed in a way that the comunication layer could be replace (this is a hard work, but not an IMPOSIBLE work), although the first task should be “it worth the effort?”. The next could be “we can use the three simultaneously?”.

This task could be called “Freeze Fisterra” … a good name 😉

A 3D view for baobab widget

Meanwhile some igalians (*) was making a very useful view of the baobab, I was spending my time creating a 3D of this widget. To do that I used the great library gtkglext , which allows to add OpenGL drawing to any widget gtk.

While the base 2D view are very intuitive, and allow you a visual track to your directorioes, with tooltips, etc, my 3D view is a very beatiful 🙂 view of a widget, but it is almost useless, as is hard to manage and select the directories. But, as I’d said, this look greats, and its funny create this, although I became a leech of the igalians laptops. For example, the Mario’s one, forcing him to work in this widget, when I kidnapped his laptop … 😉

At the end of the post you can see a screenshoot of an alpha release of this widget. The next step is create the blocks more consistently, as at this moment has some visual “leaks”, and integrate with the original base.

This is a headache problem, as to avoid to add a new dependence with the baobab, I was working in a “parallel experimental” branch. “One day” its possible a total integration, but for this moment, we have two work groups.

[*] :: Alex, Miguel, Mario, Henrique