PySide

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

And “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:

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:

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:

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!

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:

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:

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:

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.

• 1/2: Apache
• 1: Cairo Graphics
• 2: OpenBSD
• 3: Baby Tux
• 5: FoxKeh
• 8: Tux
• 13: GNU
• 20: PostgreSQL
• 40: FreeDOS
• 100: Mozilla

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.

Bossa Conference 2008

Nesse fim de semana começa o Bossa Conference 2008, tou empolgado pra caramba com as palestras e workshops e tudo mais, mas fiquei curioso com esse tal de Summerville (o lugar o evento) e fiz uma busca pra ver qual que é. Confesso que achei o lugar meio morto.

Uma coisa é certa, Berry vai estar lá.

Falando sério, o Bossa Conference é o evento Open Source de mais alto nível técnico que você vai achar nessa parte do planeta, nem posso acreditar na sorte que tenho de morar perto. 😉 E se você não puder ir, é uma pena; se você marcou… melhor ir pro outro Summerville encontrar o Berry.

Como todos disseram hoje: Nokia Compra Trolltech

Nem ia falar sobre isso, mas comecei a comentar no blog do Danilo, então vou colocar algo aqui. Como estou preguiçoso, já falei um tanto sobre o que penso da Qt faz um tempo e, mais importante, como quem muito fala pouco coda, vou apenas citar um trecho de um comentário no Slashdot:

GPL for apps, LGPL for libraries. It’s scary to a commercial enterprise, but it really works – at least better than anything else (except, maybe, having a monopoly on desktop operating systems…).

É uma cilada, Bino?

Hoje, Lauro e eu fomos como representantes do CInLUG, a uma palestra sobre interoperabilidade lá na sede da Microsoft, aqui no Recife.

(silêncio)

É, isso mesmo, e nem rolou uma situação “lavagem cerebral estilo Laranja Mecânica”. 😀

Conversamos com Fábio (esqueci o sobrenome), que é um cara com uma bagagem técnica muito boa e sabia do que falava; ele fez uma das melhores exposições sobre a história e situação do software livre/open source que já vi. Depois nos mostrou as tecnologias OpenXML e Silverlight, também rodou uns códigos PHP num Suse rodando dentro de um Virtual PC, dentro de um Vista.

Depois disso, aos negócios. A intenção da Microsoft é fazer contato com o pessoal da comunidade de Software Livre. A idéia geral é que eles se tocaram, e isso já faz um bom tempo, de que é bom ter softwares open source rodando na plataforma Windows. São muitos, são bons e agregam valor. É preciso se aproximar de quem produz e usa esses software. A mensagem é do tipo daquele antigo comercial “vem pra Caixa você também. Vem!”. Rodem suas aplicações aqui, é bonito e confortável, e temos cookies! A iniciativa teria sido inicialmente provocada pelas exigências do mercado e encontrou muita resistência interna. E externamente, bem, as pessoas têm dificuldade de confiar na Microsoft, e com razão, pois as trairagens do passado são muitas (e sempre aparecem algumas no presente).

Como eu disse lá no evento, uma pessoa pode confiar em outra pessoa, mas ninguém pode confiar numa companhia. Confiança de companhia é contrato, e em se tratando de software, uma licença de código aberto precisa me garantir as quatro liberdades básicas. Não falo isso só do ponto de vista filosófico, mas o mais pragmático desenvolvedor Open Source não contribuiria uma linha de código se não tiver as garantias (na licença, o contrato) de que não irão tirar proveito de seu trabalho, ou não usaria uma plataforma se houvesse a possibilidade de ficar preso nela.

Foi dito que o OpenXML é um padrão aberto e que o OpenOffice da Novell é o único com suporte a esse formato (não conferi, mas serve como exemplo possível). Ora, Software Livre não é sobre “o único que…”, é sobre “alguém implementou X? então todos temos X!”. Mas se o filtro OpenXML da Novell está coberto pelo acordo de patentes Novell-Microsoft, então ele é “aberto mas…”, sua licença é “livre, mas…”, e caímos numa situação Orwelliana “todos os animais são iguais, mas alguns são mais iguais que os outros”. Bem, pessoal, vocês desejarem cooperação é uma coisa boa, a divisão de Open Source não poder influenciar em algumas políticas infelizes da mastodôntica Microsoft não é surpresa, mas se querem um relacionamento sincero com as comunidades de Software Livre então sejam sinceros: “é, o OpenXML (ou SilverLight, ou qualquer outra coisa) é coberto por patentes, se vocês quiserem usar vão ter de trabalhar nesses limites aqui”. Não que informações sobre suas restrições legais seja uma grande revelação para as massas ignorantes (“oh, patentes! Jamais imaginei!”, e uma donzela desmaia do lado), mas sinceridade é uma iniciativa boa e ajuda as pessoas a saber com quem estão lidando, e podem decidir onde é possível cooperar em lugar de simplesmente dizer um “não” automático.

Em suma, as pessoas não querem coisas desse tipo:

The patent-protection pledge in Microsoft’s Open Specification Promise only protects what is explicitly specified in the standard. The Promise states that the company will not sue anyone for implementing the explicit parts of the OOXML specification; however, there are numerous implied, referenced, and undocumented facets and behaviors of the OOXML formats which, if implemented by another entity, would risk “intellectual property” (patent) violations against Microsoft software.

[Extraído de Achieving Openness: A Closer Look at ODF and OOXML]

Me parece que a “essência da coisa” do desenvolvimento aberto ainda está escapando da Microsoft. Você não pode restringir as condições nas quais alguém vai usar tal e tal tecnologia, não pode ser apenas no Windows, ou apenas naquele Linux ratificado pela Microsoft. Todas as empresas Open Source estão baseadas num tipo de colaboração que não pode sofrer esses tipos de restrições, sob o risco de quebrar o sistema. Imagine que você trabalha na Red Hat, na Canonical, ou é um desenvolvedor Debian, você colaboraria com o Moonlight da Novell sabendo que apenas ela pode usá-lo legalmente? Onde está o retorno? Acho que esse seria o primeiro exemplo real de “trabalhar de graça” do qual os programadores Software Livre eram acusados trocentos anos atrás. Estou exagerando?

Binary codecs for Windows Media video and audio, only licensed for use with Moonlight when running in a web browser. Other decoders will also work include Gstreamer and ffmpeg (used during the development stage) but Novell will not provide prepackaged version that include these libraries because of licensing and patent restrictions in the United States.

Wikipedia: Moonlight (runtime)

Outro ponto notável no discurso é que mesmo o Open Source estando tão em alta aos olhos da Microsoft, o Linux não está, assim como o Apache, o que não é uma surpresa, pois o negócio da Microsoft sempre foi plataformas de software, e a desejável posição de poder que vem junto. Até Bill G. já expressou como esse controle da plataforma já salvou sua empresa no passado:

“In short, without this exclusive franchise called the Windows API, we would have been dead a long time ago.”

Wikipedia: Vendor Lock-In – Microsoft

O Apache é um alvo particularmente interessante nesses tempos de aplicações Web, que tornam Linux e Windows relevantes apenas como porta de entrada pra internet, e muito foi falado sobre o Windows Server.

No geral a visita foi muito interessante, sinceramente, não estou falando por educação. 🙂 O pessoal lá parecia bem aberto e a discussão fluiu muito bem. Eles certamente encontrarão resistência, mas a iniciativa é válida e espero que a comunidade mostre boas maneiras. Como disse o Fábio, é preciso coexistir, até porque ninguém vai desaparecer.

(cena do filme Inimigo Meu)

Maemo SDK Appliance, release 0.4 “Not So Fat”

Finally the new version of the appliance, and it is “Not So Fat” as we expected, since it is loaded of good stuff. See the Release Notes:

This release is loaded with a lot of goodies: Maemo 4.0 (Chinook) final and Maemo 3.2 (Bora) with Nokia Binaries Installer, PyMaemo packages, Vala compiler and its Hildon bindings for Chinook, Maemomm libraries, EVAS (Bora and Chinook, but i386 only), qemu-arm-eabi used as default cpu transparency method, Eclipse with ESbox plugin, and Firefox has now a lot of bookmarks for reference material. There are code samples for all the libraries and development packages cited above.

Checkout the ChangeLog entry:

* Scratchbox installed from official Debian Repository.
* Maemo 4.0 (Chinook) release.
* Maemo 3.2 (Bora) (the last release was using 3.1)
* Use the qemu-arm-eabi as default cputransp method
* Nokia Binaries Installer for Chinook and Bora
* Added a lot of bookmarks in Firefox for reference material.
* Maemomm (C++ bindings) added, with code samples.
* EVAS libraries added to Bora and Chinook i386 targets, along with code samples.
* Eclipse 3.3.1.1 with CDT 4.0.1 and ESbox 1.2.0 plugins.

Watch a screencast on Google Video (YouTube doesn’t like Ogg/Theora, and I’m feeling very lazy to bother converting) with a sample session of using Eclipse with the ESbox plugin to create a Maemo project. For a higher resolution version, download the ogg.)

Download torrent from PirateBay (prefer this way; yarrr!):

• maemo-sdk-vmware_0.4

Or direct download in two parts:

• maemo-sdk-vmware_0.4.7z.001
• maemo-sdk-vmware_0.4.7z.002

You will need 7zip to unpack the files.

Update: direct download link fixed. Thanks tabrez. 🙂