PySide

A few days ago the project that I worked on for sometime finally went public: PySide was launched!

PySide - Python for QtAnd “what is PySide?”, you ask me. It is a binding of the Qt4 framework for the Python language created by INdT and Nokia (Moi, tamperelaiset!) under a LGPL license. My team (not that I’m the owner, “mine” in the sense of “our not including the listener” — I think there is a plural for that in Finnish or Quenya) worked as mad and the launching was smooth: we have a positive reception from the community and the news are popping up everywhere.

And we give not only the fish but also the fishing rod: the binding generator was also made available. But what is the importance of this? Since the news was given, the explanation follows.

But before I continue, pay attention to the little Prince of Persia like bottle on the PySide logo. This nice image is a branding used in projects from the Qt Labs Americas.

The Bindings

The main motivation to start the PySide project was to provide Python bindings of the Qt4 library under a LGPL license, to follow the very own Qt4 LGPL license offer from Nokia. Many possibilities on how this should be done where analysed, and before this sentence start an endless technical discussion I must say that all the options have strengths and weaknesses, but aren’t that much different. In the end it was a mix of right-tool-for-the-job, team’s acquaintance with the technologies involved and personal taste. Just to mention a personal favorite, I really appreciate Smoke. In the end we choose to alter an existing binding generator (more on this later) and use Boost.Python as the middle-man to talk to CPython API. To express this with colored boxes this is PySide right now:

PySide architecture with Boost.Python

The Generator

Writing bindings for a library so massively huge as Qt is a task… no, it’s not a task, it is a punishment. Beign reasonable people as we are, a previous research has been made and we opt to adapt the code from QtScript Generator,which is a fork of the Qt Jambi’s Generator, and both are binding generators for QtScript and Java, respectively. They’re developed by Trolltech (when it was called Trolltech).

The binding generation scheme works like this:

Binding Generator Scheme

The global.h file includes all headers (or at least the desired ones) from the library beign wrapped, and is also used to define (and undefine) preprocessor macros. typesystem.xml files contains descriptions of how the library should be exported to the target language and other semantic information: rejeted classes, renames methods, types to be converted, which methods move object ownership from Python to C++ and the otherway around, and specifies where handwritten code for special cases should be inserted. If there is no need for changes, this XML will be a simple list of classes, enums and functions.

Notice that we not only forked the QtScript Generator, we also converted it from an monolithic application to a library + front-end generator scheme. And here is another picture to show the idea:

BoostPythonGenerator

Theoretically the projects from where we derived code could be changed to use the API Extractor and share this code base (and bugs, and fixes, and improvements). Nevertheless this will not be that straightforward, since we have made a number of changes to the typesystem format, from simple things like tag renaming (mostly changing “java” to “targetlang”) to more complex things that I’ll not exemplify here. Besides that, one could write front-ends that use API Extractor to generate things other than bindings: class diagrams with GraphViz, statistics, something-that-i-did-not-thought-about.

Now for the not so beauty part. In a perfect world the C++ to Python binding generator could generate bindings for any C++ library, although, in the way it is right now the generator is useful only for Qt based libraries. Shame on us! Anyhow, taking into account that our main target was to create Qt bindings and that a beta version of them was released, I suggest you forgive us. :) Of course that it is in our plans to solve this and make the generator a useful tool for as many people as possible.

To much information for now! For the time beign download, test, report bugs and enjoy. And, if you’re feeling social, go to #pyside channel on FreeNode and subscribe to the mailing list. Everybody is welcome.

Bugzilla

PySide

Agora sim, chega de trabalhar na moitinha igual contra-regra, o negócio agora é público: PySide foi lançado!

PySide - Python for Qt

Sim! E o que é PySide, você pergunta? São bindings da biblioteca Qt4 para linguagem Python criados pelo INdT e a Nokia (Moi, tamperelaiset!) sob licença LGPL. Minha equipe (não sou dono dela, minha no sentido de “nossa sem incluir o interlocutor”) trabalhou feito louca e o lançamento foi uma beleza: tivemos um retorno positivo da comunidade e as notícias estão aparecendo em toda parte.

E fornecemos não apenas o peixe mas também a vara (na boa): o gerador de bindings também está disponível. Mas qual a importância disso? Dada a notícia vou explicar com calma.

Antes de continuar repare na garrafinha de Prince of Persia no logo do PySide. É a marca usada em projetos do Qt Labs Americas.

Os Bindings

O motivo primário da criação do PySide foi prover bindings Python da Qt4 sob a licença LGPL, para se alinhar com a oferta da Nokia da própria Qt4. Várias possibilidades de como fazer foram analisadas, e antes dessa frase começar uma discussão técnica infinita, todas as opções tinham pontos bons e ruins, mas não tão diferentes assim. A idéia do Smoke foi uma das que mais gostamos e vale uma menção. No fim optamos por alterar um gerador de bindings existente (mais sobre isso abaixo) e usar o Boost.Python para fazer meio-campo com a API CPython. Trocando em diagramas coloridos esse é o PySide:

PySide architecture with Boost.Python

O Gerador

Escrever bindings pra uma biblioteca tão massivamente grande quanto Qt é uma tarefa… não, não é uma tarefa, é uma punição. Pessoas de bom senso que somos demos uma pesquisada por aí e optamos por adaptar o código do QtScript Generator, que por sua vez é um fork do Qt Jambi Generator, e ambos são geradores de bindings QtScript e Java, respectivamente, desenvolvidos pela Trolltech (quando ela se chamava Trolltech).

O esquema de geração de bindings funciona assim:

Binding Generator Scheme

O arquivo global.h inclui todos os headers (pelo menos os desejados) da biblioteca sendo processada, e também define e desdefine flags do preprocessador. Arquivos typesystem.xml são descrições de como a biblioteca deve ser exportada para a linguagem alvo: classes rejeitadas, métodos renomeados, tipos convertidos e, muito importante, códigos escritos à mão para casos especiais e onde eles devem ser inseridos. Se não houver necessidade de alterações esse xml será apenas uma simples lista de classes, enums e funções.

Notem que não apenas forkamos o QtScript Generator, mas a convertemos de uma aplicação monolítica num esquema lib (que chamamos de API Extractor) + front-end gerador. E mais uma figura pra explicar a idéia:

BoostPythonGenerator Teoricamente os projetos dos quais derivamos código poderiam ser alterados para usar o API Extractor e compartilhar essa base de código (e bugs, e fixes, e melhorias). Além disso, o sujeito pode escrever front-ends que gerem outras coisas que não código: grafos de relacionamento entre as classes, estatísticas, algo-que-eu-não-pensei.

Agora a parte não tão bela. Num mundo perfeito o gerador de bindings C++ para Python geraria bindings de qualquer biblioteca C++ para Python, contudo da forma que se encontra agora o gerador serve apenas para bibliotecas baseadas em Qt. Grande vergonha! Considerando que o foco era criar o bindings Qt e os lançamos em versão beta, sugiro nos perdoar. :) Claro que está nos planos resolver isso e tornar o gerador uma ferramente genérica e útil para mais pessoas.

Informação demais! Por hora, baixem, testem, relatem bugs e aproveitem. E se estiverem se sentindo sociais entrem no canal #pyside no FreeNode e assinem a lista de discussão.

Bugzilla

Scrum Cards Open-Source Style

Conheci o Scrum aqui no INdT, e tendo sido adotado recentemente a maioria do pessoal ainda está aprendendo. Uma das técnicas do Scrum que chama atenção é a do planning poker, usada para estimar o esforço de uma estória (ou feature, mas estória dá uma idéia melhor). Nos explicaram que o esforço necessário para realizar a tarefa é para ser visualizado como tamanho, não como tempo. Mas era comum nos planejamentos sair frases como “quanto tempo vai levar?”, “acho que fazemos isso numa tarde”, e “não, não, nada de pensar em tempo”. Pra ajudar a me reeducar passei a imaginar que as tarefas eram grandes como elefantes ou pequenas como ratos. Daí pra ficar legal mesmo fiz um baralho de planejamento com imagens de bichos de tamanhos diferentes. Ao contrário dos chatos softwares proprietários quase todo projeto opensource ou de software livre tem um mascote simpático. Daí usei esse zoológico pra construir meu baralho.

verso das cartas

A pena é do projeto Apache, que certamente requer um esforço maior e vale mais que 1/2. É isso aí Coxa, estou falando com você. Ele disse “você tá louco?! O Apache 1/2!?”. A idéia é visualizar tamanho, e a pena é o mais leve da lista.
Verdade que nem todas as figuras são de projetos de código aberto. O clipe você deve conhecer e odiar de um softwarezinho proprietário aí. E esse clipe não vale nada, por isso é o zero. O outro personagem é a coruja retardada da interrogação. Essa coruja ficou famosa por causa deste poster motivacional:

Ela é incrível e somos todos grandes fãs aqui no INdT. Não há ninguém melhor pra ilustrar a carta “não faço a menor idéia do esforço disso”.

Agora alguns dados técnicos e a chatice legal. Fiz o baralho com o Inkscape e a fonte usada foi a Purisa (parte do pacote ttf-thai-tlwg no Debian/Ubuntu). A licença pro baralho é a Creative Commons Atribuição-Uso Não-Comercial.

As licenças de cada uma das imagens podem ser encontradas em seus respectivos sites. Duvido muito que você queira checar, mas vou colocar os links pros projetos (ou entradas na Wikipedia) assim mesmo.

Como a maioria dos posters motivacionais a coruja retardada é domínio público. Assim espero.

Não deu pra descobrir qual a licença do clipe idiota, mas se alguém reclamar deixo só os olhos dele e mando os membros pra sua família em Redmond.

qemu-arm-eabi updated, fakeroot bug fixed, post posted

As some of you already know Lauro Venâncio maintains a version of qemu with a set of patches that provides arm-eabi compatibility (which is needed if you want to build/use PyMaemo in Scratchbox). He does so because many of these patches where not yet accepted upstream and the world can not wait.

The version of qemu-arm-eabi in the sourceforge repository included the full source of qemu from its cvs with the patches already applied. Since the qemu source was a bit old (the current version uses svn) I spent some time updating Lauro’s qemu-arm-eabi. Now the sourceforge repository includes only the patches and a script to checkout qemu source from its own svn and apply the patches with quilt. There are also scripts to build and install the qemu-arm-eabi in scratchbox.

But nobody expects that a new bug would crawl in. When running a program through fakeroot and that program tries to call popen libfakeroot will not be found. I find out that the problem was in the fakeroot-tcp script that was using ‘,’ as separator in the environment variable SBOX_PRELOAD. This works with the qemu versions provided by scratchbox, but not with our patched version. I take a look at the scratchbox patches and other places for the source of the problem and found nothing. Since my time to deal with this was limited I just changed ‘,‘ to ‘:‘ in fakeroot-tcp. This worked fine when you do “fakeroot ./progthatusespopen” but Jesus couldn’t do a “dpkg-buildpackage -rfakeroot“. Caio (from Canola fame) solved this by removing the separator and the second item of the SBOX_PRELOAD variable.

The fix described is not the best but works for now. If you have any idea on how to solve this in a proper way your help is appreciated.

Instructions on how to install in the qemu-arm-eabi wiki.

Palestra sobre Software Livre e Open Source no CIn

Jesus me chamou, em nome do PET, pra aprensentar novamente aquela palestra sobre Software Livre e Open Source pro pessoal do CIn, em sua maior parte pessoal do primeiro período.

Já havíamos apresentado essa no passado, também pra uma maioria de alunos do primeiro período. Um costume que chamamos carinhosamente de “lavagem cerebral”, mas num sentido bem positivo – pense em cérebros limpinhos e aquele ursinho do comercial do Comfort.

Os slides foram aqueles bons e velhos (a anedota dos russos continua funcionando!), que você encontra aqui:

Cheguei meio atrasado e não deu tempo de usar o laptop, então usei os do slideshare com a opção fullscreen. Ponto pra eles, embora meu slide com a mensagem subliminar não tenha aparecido direito.

A experiência foi bem legal, vi um monte de gente que não encontrava faz tempo, e pensei que tinha esquecido do conteúdo da apresentação, mas não esqueci. :) Expliquei SL e OS, como é feita uma distribuição, o que são padrões abertos, fiz um jabá do Maemo e do INdT (depois ainda dei uma cutucada no professor Fernando Fonseca pra deixar o pessoal usar Postgres no lugar do Oracle na disciplina de Banco de Dados :D). Tentei dar uma ênfase sobre os pontos que fazem valer à pena desenvolver software open source, que eu me atrevo a resumir num ponto: vocês se tornarão melhores programadores. Claro que elaborei mais, e penso que fui convincente o suficiente pros calouros não acharem que isso é coisa de comunistas e hippies sujos.

Maemo SDK Appliance, release 0.6 “Be kind.”

New vm appliance everybody, the last one was redone from scratch because of some problems with Open VM Tools, and I managed to miss other things too, like the hildonmm development packages. ><

This one, even still made by a humble human, should be (almost (i hope)) bug free. As usual updates to the packages included, check the changelog:

  • The latest PyMaemo.
  • Eclipse 3.3.1.1 with CDT 4.0.2, PyDev 1.3.14 and ESbox 1.3.6 plugins.
  • Using Open VM Tools ver. 2008.02.13-77928.
  • Using kernel for virtualization.
  • Scripts to automate image creation.
  • EFL (ecore, evas, etc. and python-evas) installed from extras repository (instead from CVS source).
  • Nokia Binaries installers fixed.
  • Vala not included in this version.

Download in the website.