Shiboken

Last week PySide was launched, the team was glad to see the project finally go public and receive the community feedback, be it positive, negative or both. Many questions arose, like “Why duplicate efforts?” Well, I can’t say much more than what is already answered on PySide FAQ. For us (the team) the fact is that we had a task to accomplish and must perform it the best we can. That said, allow me to remind you that this is my personal blog and many of the views here written are my very own cherished opinion.

The other question that we’re waiting for, and my personal favorite, was “Why Boost.Python?”. Though one. First of all, Boost.Python eases very much the creation of C++ libraries bindings for Python. How to infer which method signature to call based on the Python arguments passed to the method wrapper? Boost.Python will take care of it. Inheritance? Type conversion (in opposition to type wrapping)? You bet: Boost.Python will take care of all this for you. The feature full Boost.Python gave us a great kick start and at first we progressed very fast. Occasionally some strange bug appeared and took some time to figure out the problem through the jungle of template error messages. Part of the job anyhow, and after that: fast pace again.

At some point somebody checked the size of the produced binary modules. “Hey guys, is that correct?”, “Ah, just strip the file.”, “Still huge.”, “Holy cow…”. Next task: size reduction. Some redesigns reduced a good deal of megabytes, g++ flags were also helpful, but these things weren’t enough. Then a new idea: “Let’s try it with the Intel C++ compiler and see what gives.” It gave binary modules with feasible sizes. Good, but the test just proved that it was possible to achieve the reductions. Besides, there were still other new ideas to try, and the fact that as soon as the project was launched the community would step in and say “I had this size problem with Boost.Python before. Here is how I solved it…”. (Which reminds me how limited, communication wise, a project is in its non-open phase. And don’t point your finger, mister — for every open source project has it’s non-open phase, even in your head!)

Part of the team was growing skeptical about the size reduction problem. Why not to try CPython code generation right now? Well, some say you can’t change the plane’s motor while flying, and this is true. Feature wise we were almost there and the reduction was possible. Also some of us had mixed feelings about CPython. In a past project a comparison was made about writing bindings with different technologies, including CPython, to check for speed, size and the burden imposed on the developer. At the end the guy with CPython had good numbers (not stunningly better than the others, at least for the case that mattered back then), but his personal impression was that he was suffering the Stockholm syndrome: he knew CPython abused him, but he developed a bond with his kidnapper.

Still, almost every one started personal (and voluntary, aka “made at home”) experimentation with different CPython generators (even a ctypes one!), and in the end all the ideas (including the ones from the Boost.Python generator) were merged into a single CPython generator, called Shiboken.

Shiboken

Before going on with this, allow me to explain that Shiboken means absolutely nothing. Not buddhist void, I just mean that the word Shiboken has no meaning attached to it. Except, of course, “generator of CPython based binding code for C/C++ libraries”.

Disclaimer: I don’t know a thing about Japanese language and the above kanjis are just something that I found at wikitionary to match the sounds of Shiboken. Forgive me, Lauro. :)

The conspirators’ plan was to develop the alternative generator to a point that could generate PySide bindings that pass all our unit tests, run the apps, etc, thus beign able to replace the Boost.Python front-end. For PySide users, i.e. Python programmers, the replacement would bring no impact, since the API should remain the same. The Shiboken generator is based on the same principles of the Boost.Python one: built using the API Extractor library, how the C++ library should be exported to Python is described on a Type System file, and so on.

Shiboken Generator

The power of Lego-fu!

When Shiboken reached a point that we’d think was good enough to start working with it at work, we presented it to our bosses and the green light was given. The Boost.Python generator will continue as the tool to generate the official PySide bindings, but with the parallel efforts we hope that Shiboken takes its place, the size reduction is achieved, and the Occam’s razor cut off the unnecessary entities.

noboost

Occam's razor demands that Boost.Python go

C/C++ Bindings

Another fix that we aim to achieve with Shiboken is to allow non-Qt C++ and C libraries to be wrapped with the generator scheme. The problem with the current Boost.Python generator is that even a non-Qt library wrapped with it will depend on Qt. Of course this is not the best we can do, but the fixing task had low priority since the PySide bindings are the main target of the work. For Shiboken we make it library agnostic from the start, specially because we do not get our chances trying to wrap the whole Qt from start: a test library with all the problems that could arise was made and is the source of all Shiboken unit tests.

Shiboken Features Worth Noting

Abandoning Boost.Python means abandoning some features already provided by it. One that is worth mentioning is the decision of which signature of a method should be called depending on the Python arguments passed on the call. For this to work we have to write a decisor that progressively checks the argument types until the correct signature is found. Just this? Of course not, the binding developer can use the Type System description to remove method signatures, remove/change the type of its arguments, even remove/change/set its default values! The method call decisor must take everything into account.

Overloaded Method

Debugging a multiple signature method call decisor is easier with the "dumpGraph" method.

No Boost.Python also means that would be harder to convert types and containers back and forth between C++ and Python. The template specialization technique was used to solve this one.

template <> struct Converter<bool> {
  static PyObject* toPython(ValueHolder<bool> holder) {
    return PyBool_FromLong(holder.value);
  }
  static bool toCpp(PyObject* pyobj) {
    return pyobj == Py_True;
  }
};

Why not generating “pyobj == Py_True” directly, you say? The above code scales better, since it will be the same for types that are composed of some primitive types inside containers inside containers, etc. Besides, the compiler could be counted on to inline short methods.

“They have a plan”

Right now Hugo (from PySide fame) started working on generating bare QtCore bindings without QObject and signals, then go to QObject. After that we should solve the signals problem, re-write the pieces of custom code and so on. I think after QtCore is completely done we can make a comparison with the one produced by the Boost.Python generator and see if the whole Shiboken idea can stand to its promise. The best should win for the honor and glory of open source.

We encourage everyone interested in the creation of Python bindings for C++ libraries to test Shiboken, report problems (we now have a component on OpenBossa bugzilla!), and tell us if something is missing for your library to work. Patches are always welcome as usual. :)

Shiboken on gitorious: http://qt.gitorious.org/pyside/shiboken

Cryptonomicon

Logo que terminei de ler Cryptonomicon, do Neal Stephenson, fiquei protelando escrever algo sobre o livro, mas seria injusto não falar uma coisa ou outra sobre ele. Vamos ver o que ainda tenho na cabeça.

stephenson_cryptonomicon_html_49ffa56a

O livro é um tijolo de papel que vale cada árvore. Novecentas e tantas páginas onde o escritor não tem a menor vergonha de meter um gráfico de sino (aquele da probabilidade) ou um pequeno script perl. Mais ainda, Stephenson coloca tudo de uma forma que em vez de achar difícil você se sente mais inteligente (+2 na Int enquanto o livro estiver aberto).

A história se desenvolve em duas épocas: a Segunda Guerra Mundial e o Tempo Presente (anos 90, na verdade). Alguns personagens dos tempos mordernos são descendentes ou versões mais velhas de personagens da época da guerra. Outros personagens são reais (ou representações romanceadas de pessoas reais), como Alan Turing e o General MacArthur, que era muito figura. O livro alterna a narrativa entre as duas épocas, o que me deixou o tempo todo pescando pistas de todas as formas que o passado poderia influenciar o presente.

Não é segredo que o principal tema do livro é criptografia. Na parte da estória ambientada no passado são apresentados vários temas modernos da matemática. Não de forma didática, mas pelos olhos de quem estava descobrindo as novidades com a empolgação de um explorador do ártico. Lawrence Pritchard Waterhouse, amigo pessoal de Alan Turing, é uma dessas pessoas com o cérebro tão embriagado pela matemática que é normal ter epifanias geniais qualquer que seja a situação. Quando a guerra começa a esquentar Waterhouse está num navio em Pearl Harbor como músico da bandinha. Tendo sobrevivido aos eventos conhecidos, ele é inesperadamente descoberto como matemático über-cracker extraordinaire, promovido à oficial e mandado pra quebrar códigos nazistas em Bletchley Park e outros lugares.

Enquanto isso, nos tempos modernos, Randy Waterhouse, neto de Lawrence, é um hacker e empreendedor tentando, juntamente com seus amigos e sócios, criar um Data Haven numa ilha do Pacífico. E caçar tesouros.

Nesse ponto eu dou uma parada no post tipo “resenha” e mudo pra post tipo “vou fazer como quiser”.

O livro tem vários personagens legais, mas vou me fixar nos Waterhouse e nas minhas situações preferidas. E em Enoch Root, claro.

Enoch Root é um padre que aparece nas duas épocas, praticamente inalterado. Randy define ele como um Mago. Randy também se define como um Anão e outras pessoas como Hobbits. Essas comparações de pessoas com personagens das histórias de Tolkien e RPGs sempre me arrancavam um sorriso de satisfação — isso é algo que faço com muita freqüência (designers são Elfos, desenvolvedores são Anões).

Avançando um pouco, Randy é trancafiado numa cadeia em algum lugar pelas Filipinas. Enoch Root arruma um jeito de ser preso na cela do lado. Lá rola um diálogo que é o meu preferido no livro: Enoch Root explicando que os alemães perderam a WW2 por serem seguidores de Ares e os Aliados venceram por serem seguidores de Atena. Ele começa questionando pra quê os gregos precisavam de dois deuses da guerra. Eles não são exatamente iguais. Ares é a pancadaria, a carnificina e a destruição — o cara é um psico. Atena é diferente, começando que ela nasceu da cabeça de Zeus. E ela não é deusa só da guerra, ela é deusa da estratégia e, mais importante, da tecnologia. A marcha de destruição alemã não era apenas física, eles atacaram desde as artes até a por eles chamada “ciência judaica”. Eles tocaram Einstein (ele faz uma pontinha no livro) pra fora de lá, só pra citar um. Os aliados, pelo contrário, recebem a leva de cientistas fugidos e ainda proveem o habitat natural deles: um lugar para pensarem livremente (mais uma boa verba de pesquisa). Enoch Root elabora esse ponto melhor que eu (leia o livro), mas poderia resumir assim: “Smart guys have better guns”.

Waterhouse avô é meu personagem preferido, as situações são ótimas. Ele alterna períodos de intenso trabalho intelectual com luxúria desesperada que geralmente o leva pros serviços das moças da rua da luz vermelha. Waterhouse chega a fazer um gráfico da variação de concentração ao longo do tempo: o “horniness index”. Os períodos de tranqüilidade após um “manual override” eram sempre mais curtos que os que seguiam a ida às putas (ele é um marinheiro afinal de contas). Achei esse gráfico muito mais legal que o computador que ele inventou baseado num órgão de igreja.

Talvez não tão legal quanto quando Waterhouse percebe na beira da praia que toda a existência envia sinais criptografados para todos os lados, e se pergunta que informações estão codificadas na freqüência das ondas.

O livro é grande, com seqüências de ação, sagacidades, drogas, putarias, discussões filosóficas, heroísmo, códigos, quebra de códigos, submarinos, jatos, nazistas, nerdices, dinheiro, tesouros, mais códigos, e as missões para corrigir a curva do sino realizadas pelo destacamento 2702 (originalmente chamado destacamento 2701, mas esse número dava muito na vista, sendo ele o produto dos números primos palíndromos 37 e 73 — suspeitíssimo!). Se você quiser ler e completar as enormes lacunas dessa sombra de lembrança de resenha, então corra. Se está difícil conseguir o volume tem esse link de um dos maiores Data Havens do mundo: a mãe Rússia. спасибо!

stephenson_cryptonomicon_html_46ae2806

P.S.: e um valeu pro Marcio pelo livro.

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