Quando meu Kindle não está à mão, meu leitor substituto é um N900 com MeBook, um dos meus aplicativos preferidos – ele procura por livros (no formato ePub) no Feedbooks, baixa pro dispositivo e os mostra numa lista bem bacana, com capas e tudo. Examinando o código fonte do MeBook aprendi que ele usa a libepub para ler eBooks ePub, então pensei que seria interessante fazer bindings Python para libepub. E aqui estamos.

Ah, e mais uma coisa antes de começarmos, encontrei um projeto Python no github chamado libepub. Não verifiquei ainda, mas o menciono aqui pelo bem da informação.

Shiboken

Shiboken é a ferramenta de renome mundial usada para gerar o mundialmente famoso PySide (que ocore ter alcançado a versão 1.0 semana passada – viva!) Ela é uma das melhores ferramentas disponíveis para gerar bindings Python para bibliotecas C++. Mas isso sou eu falando – eu nela. Contudo, libepub é escrita em C, e mesmo que Shiboken possa gerar bindings para um punhado de funções globais e juntá-las num módulo Python, fica uma porcaria. De forma que terei de fazer algumas preparações para que a libepub apareça bela em Python.

Pré-requisitos: arquivos de desenvolvimento (i.e. os cabeçalhos) para ApiExtractor, GeneratorRunner, Shiboken, e libepub. (Para usuários de Debian/Ubuntu isto significa: libapiextractor-dev, libgenrunner-dev, libshiboken-dev, and libepub-dev.) E o compilador C++ mais o CMake, é claro.

Lembrete: ApiExtractor, GeneratorRunner e Shiboken são feitos com Qt (somente módulos principais, nenhuma delas tem ui), mas os bindings gerados não dependem da Qt de forma alguma. Exceto, obviamente, se a biblioteca para qual os bindings serão gerados já a use.

libepub

Primeiro, vamos dar uma olhada na libepub. Ela tem três estruturas usadas como ponteiros opacos:

Se você quiser ler o conteúdo de um arquivo ePub, chame a função que irá criar uma estrutura epub, itere por seu índice com um titerator, e depois pelos conteúdos mesmos usando um eiterator.

A maioria das funções seguem aquele formato “C orientado a objetos” visto em outras bibliotecas, com o primeiro argumento sendo um ponteiro para a estrutura que representa o “this” ou “self” em linguagens OO. Exemplos:

CMake

Usarei CMake como o sistema de compilação dos bindings pois me sinto confortável com ele – é o mesmo usado no PySide e no conjunto de ferramentas de geração do Shiboken. Não darei muita atenção à esta parte do processo, apenas veja os arquivos CMakeLists.txt; explicação mais detalhada sobre o processo de compilar um binding pode ser encontrada em PySide Binding Generation Tutorial. Para informação realmente básica, veja PySide CMake Primer.

C++ Wrapper feito à mão para uma biblioteca em C

Para gerar bindings Python para uma biblioteca C++, o sujeito precisa escrever uma descrição XML chamada type system, que declarará o quê precisa ser exposto para Python, e o quê sofrerá modificação: funções globais, classes, namespaces, enums. Por exemplo, se em C++ temos a classe Rectangle, eu a declararia no type system dessa forma:

Todos os métodos pertencentes à Rectangle serão expostos em Python automaticamente. O mesmo não vale para as funções em C que representam os métodos para a estrutura epub. Infelizmente não há modo de dizer para o gerador Shiboken que quero a estrutura epub e suas funções representadas como uma classe com métodos, sendo assim precisamos escrever um fino envoltório C++ ao redor das estruturas C. Isto seria um bocado de trabalho para uma grande biblioteca C, mas mesmo com uma minúscula sinto o desconforto de precisar recorrer a este tipo de gambiarra. O type system deveria ser expressivo o bastante para gerar bindings para estruturas e funções em C como se elas fossem objetos e métodos apropriados. Vou marcar isto para futuras melhorias comunitárias/fora-do-trabalho no Shiboken.

Vejamos um pedaço de código do arquivoepub_cpp_wrapper.h:

Note que todos os métodos são marcados como inline para fazer este envoltório o mais fino possível. (GCC, estou olhando pra você!)

Epub::open

A função epub_open se torna o método estático EPub::open que retornará um novo objeto EPub para o arquivo ePub dado pelo parâmetro filename, ou um null pointer se o arquivo for inválido ou não existir.
O construtor para esta classe foi feito privado de forma que o único modo de criar objetos EPub é via EPub::open, que nunca criará um objeto EPub inválido.

~Epub

Em C o responsável por liberar a estrutura epub é epub_close, mas não criarei um método EPub::close(), pois o equivalente C++ para ele é o destrutor da classe.

Um binding Python gerado para o que temos até agora seria mais ou menos assim:

Claro que não expliquei como isto seria gerado, que o módulo se chamaria epub, o que é epub.EPUB_TITLE, e como Python saberia o que fazer com unsigned char**, mas tenhamos paciência.

Movendo enums por aí

EPUB_TITLE é um valor vindo do enum epub_metadata, se ambos forem exportados para Python conforme estão, eles terão esta aparência:

Assim fica bem feio e fuleiro. Já que epub_metadata é um enum relacionado ao objeto epub (como nos informa o prefixo epub_), será natural que ele seja movido para dentro da class EPub. No meu mundo de fantasia, a tag do type system que descreve um enum C++ para Python teria a opção de movê-lo para dentro de outro objeto, e também de ser renomeado. Algo desse tipo:

E aqui temos outro item para a lista de “por fazer” do Shiboken. Enquanto esta funcionalidade não é implementada, terei de fazê-lo manualmente.

Os valores do enum epub_metadata foram convertidos para int para impedir o ApiExtractor de emitir toda sorte de warnings dizendo que ele não sabe quem são esses caras.

De qualquer modo, é terrível… ter esse gerador incrementado, e ter de escrever tudo isso… nãããão!

TIterator e EIterator

As estruturas C titerator e eiterator serão envolvidas pelas class C++ TIterator e EIterator, respectivamente, e como a classe EPub seus construtores serão privados.

Novas instâncias de TIterator e EIterator são criadas por métodos de EPub, por isso ela deve ser feita amiga (friend) das classes iteradoras.

python-epub

Agora é hora de dizer ao gerador o quê entra e o quê será modificado nos bindings.

O cabeçalho global

O cabeçalho global é um arquivo que inclui todos os outros cabeçalhos da biblioteca que será analizada. No cabeçalho global o desenvolvedor de bindings pode também adicionar algumas cláusulas, como um #define que irá causar alguma condição de mudança nos cabeçalhos da biblioteca alvo, que irá afetar o binding gerado.

O arquivo epub_global.h que uso aqui é muito simples:

Como o comentário nos diz, ApiExtractor não gosta quando encontra pré-declarações sem definições. Escolhi adicionar estas definições falsas para struct titerator e struct eiterator. (Por alguma razão o gerador nada diz sobre struct epub.) Outra opção seria não usar estas definições falsas, mas adicionar uma linha ao arquivo type system dizendo ao gerador para ignorar avisos relativos à estas estruturas.

A descrição do Type System

Aqui segue um pedaço de código do arquivo typesystem_epub.xml.

O enum epub_metadata não é exportado para Python (ao menos não diretamente) e para evitar que o gerador emita seus alertas, ele precisa ser explicitamente rejeitado; seu substituto C++ é adicionado depois dentro do object-type EPub. O mesmo acontece com os outros enums.

Na notação do type system object-type se refere aos objetos que são passados somente como ponteiros (como EPub, cujos construtor e operador de cópia são privados). Se, de outro modo, o objeto pode ser passado como valor, ele deve ser declarado como value-type, conforme nosso exemplo de Rectangle mencionado anteriormente.

O Protocolo de Iterador de Python

Em Python, se um objeto suporta o Protocolo de Iterador, poderei usar em comandos for, desta forma:

Seguir o Protocolo de Iterador de Python consiste tão somente de um objeto implementar os métodos __iter__() e __next__().

Nota: o nome correto para o método é next() e não __next__(). Este é apenas um bug menor no gerador, que acabei de encontrar.

O XML para adicionar as funcionalidades do protocolo de iterador à classe TIterator será extenso, de forma que o partirei em duas partes, a primeira lidando com templates de código do type system.

Os templates do Type System

Os métodos de iterador para TIterator e EIterator terão exatamente a mesma implementação, então é esperto usar os templates do type system, e ter o código, e seus eventuais bugs, num único lugar.

O iterator.__iter__ método precisa apenas returnar o próprio objeto com seu contador de referências incrementado em um. iterator.__next__ chama o next() do objeto C++ subjacente (e também retorna a si próprio, e incrementa o refcounter), e sobe uma exceção Python StopIteration quando chega ao fim.

As variáveis do type system %PYSELF, %PYARG_0 e %CPPSELF são substituídas por valores dependentes do contexto onde são usados (e.g. as classes TIterator ou EIteration). Verifique a documentation para saber seus significados.

Adicionando os métodos de iteração

Primeiro o next() original do C++ é removido, então aqueles para o protocolo de iterador do Python são adicionados, usando a tag <insert-template/> para inserir o código personalizado definido anteriormente. A exatas mesmas linhas serão adicionadas à classe EIterator.

Só mais um pouco de gambiarras

Apenas um obstáculo permanece no caminho de ter iteradores Python apropriados. Quando o comando for de Python for usado para iterar sobre um objeto iterável, na primeira rodada ele chama o método __iter__ do objeto, e imediatamente após ele chama next, e continua chamando next para cada nova iteração.

O problema aqui é que o iterador C subjacente retorna um objeto levando conteúdo apropriado quando __iter__ é chamado, então a forma como a iteração do for Python funciona fará o primeiro item válido ser pulado. Uma gambiarra para este caso é usar uma flag no wrapper C++ que verificará se o iterador acabou de ser criado, de forma que ele não pulará para o iterador seguinte quando next for chamada pela primeira vez.

Pude ter esta liberdade porque TIterator é uma classe completamente sob meu (eu, o desenvolvedor do binding) controle. Se struct titerator fosse uma classe C++ desde o começo, esta solução não seria a melhor. Talvez se a libshiboken (a biblioteca de apoio usada por todos os bindings gerados pelo Shiboken) fornecesse uma classe iteradora base para lidar com essa diferença particular entre iteradores Python e C++. Ou talvez as classes geradas, quando identificadas como iteráveis pela presença dos métodos do protocolo de iteração adicionados pelo desenvolvedor do binding, poderiam ter tal funcionalidade. A última opção me parece a melhor, e esse é mais um item pra minha lista de melhorias futuras.

Conversões Personalizadas

Retornando valores unicode

Os métodos EIterator::curr() e EIterator::curr_url() returnam valores do tipo char*, que não tem um conversor (const char* é que tem), por isso escrevi um código específico para converter isto para unicode do Python.

Modificando a assinatura de um método

As assinaturas de alguns métodos C++ não podem ser automaticamente convertidas para código Python que faça sentido, então adicionei mais um pouco de código feito sob medida para tratar das situações caso a caso. Por exemplo, o método

O argumento int* size recebe um ponteiro para um int, que conterá o tamanho da lista de strings unicode retornada como unsigned char**. Em Python ele meramente retornará uma lista de objetos unicode, e a chamada à get_metadata não precisa do argumento size.

Creio que a descrição do type system será o bastante para ver como o sistema de modificação funciona.

Baixando, compilando, etc.

Chega de explicações, agora vamos experimentar o código. Lembre-se que precisará também dos arquivos de desenvolvimento que mencionei muito tempo atrás

Clone a versão mais recente do repositório git:

ou baixe o tarball: python-epub.tar.bz2

No diretório do código fonte crie um diretório build e…

O último comando merece uma conversa à respeito.

Testar, Testar, Testar

Quando trabalhando com desenvolvimento de bindings há uma miríade de coisas que podem dar errado, e muitas delas dão errado em completo silêncio. Tendo isto em mente, eu digo-lhe que ter testes de unidade torna a vida do desenvolvedor de bindings suportável.

Veja o diretório de testes para exemplos de como usar o bingind python-epub.

Para resultados detalhados dos testes, rode ctest com a opção -V (verboso).

Exemplo de UI (senão seria tedioso)

Mas a própria UI é bem tediosa, embora feita com o espetacular PySide, ela nem sequer mostra imagens. Por outro lado, com um pouco de código agora posso ver o conteúdo de um ebook ePub.

De dentro do diretório python-epub/build chame o visualizador de ePub dessa forma:

Ele sempre espera um parâmetro com o caminho para um arquivo ePub, neste caso “Beyond the Wall of Sleep” de Lovecraft.

Screenshots:

When my Kindle is not at hand, my replacement reader is a N900 with MeBook, one of my favorite apps – it looks for books (in ePub format) on Feedbooks, downloads to device and show them in a nice list with covers and all. Looking at MeBook source code I learned that it uses libepub to read the ePub eBooks, so I thought it would be interesting to make a Python binding to libepub. And here we are.

Ah, and one more thing before we start, I found a related Python project on github called libepub. Hadn’t checked it yet, but I mention it here for information’s sake.

Shiboken

Shiboken is the world famous tool used to generate the world famous PySide bindings (that happen to have reached 1.0 last week – yay!) It is one of the best tools around to generate Python bindings for C++ libraries. But that’s me talking – I work on it. But libepub is written in C, and even though Shiboken can generate bindings for a bunch of global functions and put them together in a Python module, that’s crappy. So I’ll have to make some preparations to make libepub appear beautiful in Python.

Pre-requisites: development files (i.e. the headers) for ApiExtractor, GeneratorRunner, Shiboken, and libepub. (For Debian/Ubuntu users this means: libapiextractor-dev, libgenrunner-dev, libshiboken-dev, and libepub-dev.) And the C++ compiler plus CMake, of course.

Remainder: ApiExtractor, GeneratorRunner and Shiboken are made with Qt (only the core libs, no ui for them), but the bindings generated do not depend on Qt at all. Except, obviously, if the library being wrapped already does.

libepub

First let’s have an overview of libepub. It has three structures used as opaque pointers:

If you want to read the contents of an ePub file, call the function that will create an epub structure, iterate through its table of contents with a titerator, and then the contents themselves with an eiterator.

Most functions follow that “object oriented C” format seen in other libraries, with the first argument being a pointer to the structure that represents the “this” or “self” in OO languages. Examples:

CMake

I’ll use CMake as the build system for the bindings because I feel comfortable with it – it is the same used in PySide and all the Shiboken generator tool chain. I’ll not give too much attention to this part of the process, just check the CMakeLists.txt files; more detailed explanation on the process of building a binding can be found in the PySide Binding Generation Tutorial. For really really basic information check PySide CMake Primer.

Handmade C++ Wrapper for a C library

To generate Python bindings for a C++ library one must write a XML description called type system, which will declare what must be exposed on Python land, and if any of this needs modification: global functions, classes, namespaces, enums. For example, if in C++ I have the class Rectangle, I would declare it in the type system this way:

All the methods belonging to Rectangle would be exposed to Python automatically. The same is not true for the C functions that representing the methods for the epub struct. Unfortunately there’s no way to tell the Shiboken generator that I want to have the epub structure and functions represented as a class with methods, so we have to make a thin C++ wrapper around the C structures. That would be a lot of work for a huge C library, but even with a tiny one I feel uncomfortable having to resort for this kind of hackery. The type system should be expressive enough to bind C structs and functions as if they were proper objects with methods. I’ll mark this for future community/out-of-work improvements on Shiboken.

Let’s see a snippet from epub_cpp_wrapper.h:

Notice that all methods were marked as inline to make this wrapper as thinner as possible. (GCC, I’m looking at you!)

Epub::open

The epub_open function becomes the static method EPub::open that will return a new EPub object for the ePub file given by filename parameter, or a null pointer if the file is invalid or doesn’t exist.
The constructor for this class was made private so the only way to create EPub objects is via EPub::open, that’ll never create an invalid EPub.

~Epub

In C the responsible for freeing the epub structure is epub_close, but I’ll not make it EPub::close() because the C++ equivalent for it is the class’ destructor.

A generated Python binding for what we have until now would look roughly like this:

Of course I didn’t explained how this would be generated, that the module would be called epub, what is epub.EPUB_TITLE, and how Python would know what to do with unsigned char**, but bear with me.

Moving enums around

EPUB_TITLE is a value from the epub_metadata enum, if exposed to Python as they are, they’ll look like this:

Which is pretty ugly and lame. Since epub_metadata is an enum related to the epub object (as the epub_ prefix tells us), it would be natural that it was moved inside the EPub class. In my fantasy world, the type system tag that describes a C++ enum to Python would have the option to move it inside another object, and also to be renamed. Something along these lines:

And here I have another thing for a Shiboken TODO list. While this feature is not implemented, I’ll have to do it manually.

The epub_metadata enum values were cast to int to prevent the ApiExtractor to emitting a bunch of warnings saying that it cannot tell who these guys are.

Anyways, it’s so awful… to have a fancy generator, and having to write all this… noooo!

TIterator and EIterator

The C structures titerator and eiterator will be wrapped by the C++ classes TIterator and EIterator, respectively, and like the EPub class their constructors are private.

New instances of TIterator and EIterator are created by EPub methods, because of that it must be a friend of the iterator classes.

python-epub

Now it’s time to say to the generator which goes in and which must change in the bindings.

The global header

The global header is a file that includes all other headers of the library that will be analyzed. In the global header the binding developer may also add some tweaks, like a #define that will trigger some condition in the target library headers, that will affect the generated binding.

The epub_global.h that I use here is very simple:

As the commentary tells us, ApiExtractor doesn’t like when it finds forward declarations without definitions. I choose to add these two bogus definitions for struct titerator and struct eiterator. (For some reason the generator said nothing about struct epub.) Other option would be not to add those bogus definitions, but add a line to the type system file telling the generator to ignore warnings relative to those structures.

The Type System description

Here follows a snippet from typesystem_epub.xml.

The epub_metadata enum is not exported to Python (at least not as it is) and to avoid the generator emitting his warnings, it must be explicitly rejected; its C++ substitute is added afterwards inside the EPub object type. The same happens to the other enums.

In the type system notation object-type refers to objects that are passed around solely as pointers (like EPub, whose copy constructor and operator are private). If, otherwise, the object can be passed as value, it should be declared as an value-type, as our Rectangle example mentioned before.

Python’s Iterator Protocol

In Python, if an object supports the Iterator Protocol I can use it on for statements, like this:

Following the Python Iterator Protocol consists solely of an object implementing the methods __iter__() and __next__().

Note: the correct name for the method is next() and not __next__(). That's a minor bug in the generator that I just found.

The XML to add iterator protocol features into TIterator class will be lengthy, so I'll split it into two parts, the first dealing with type system code templates.

Type System templates

The iterator methods for TIterator and EIterator have exactly the same implementation, so it’ll be smart to use type system templates and have the code, and its eventual bugs, in a single place.

iterator.__iter__ method just need to return the object itself with its reference counter incremented by one. iterator.__next__ calls the underlying C++ object’s next() (it also returns itself, and increments the refcounter), and raises a Python StopIteration exception when it reaches the end.

The type system variables %PYSELF, %PYARG_0 and %CPPSELF are replaced by values dependent on the context where they are used (e.g. TIterator or EIteration classes). Check the documentation for their meaning·

Adding the iterator methods

First the original C++ next() is removed, then the ones for the Python iterator protocol are added, using <insert-template/> tag to insert the previously defined custom code. Exactly the same lines will be added to EIterator class.

Just one more bit of hackery

Only one obstacle remains on the way of having proper Python iterators. When Python’s for statement is used to iterate through an iterable object, in the first round it calls the object’s __iter__ method, and immediately after it calls next, and keeps calling next for each new iteration.

The problem here is that our underlying C iterator returns an object loaded with proper content when __iter__ is called, then the way that Python’s for iteration works will cause the first item to be bypassed. A workaround for this case is to use a flag on the C++ wrapper that checks if the iterator has just been created, so that it will not move forward when next is called on it for the first time.

I had this freedom because TIterator is a class completely under my (me, the binding developer) control. If struct titerator were a C++ class from the beginning that approach would not be the best. Perhaps libshiboken (the supporting library used by all Shiboken generated bindings) should provide a base iterator class to handle this particular difference between Python and C++ iterators. Or perhaps the generated class, when identified as an iterable by the presence of iterator protocol methods added by the binding developer, should have such provisions. The latter options seems best, and that’s one more item for my list of future improvements.

Custom Conversions

Returning unicode values

The EIterator::curr() methods EIterator::curr_url() returns values of char* type, which doesn’t have a converter (const char* does have), so I’ve written a custom piece of code to convert it to Python’s unicode.

Modifying a method’s signature

Some C++ method signatures couldn’t automatically be converted to meaningful Python code, so I added more custom code to handle the situation on a case by case basis. For example, the method

The int* size argument receives a pointer to an int, which will contain the size of the list of unicode strings returned as unsigned char**. In Python it would merely return a list of unicode objects, and the call to get_metadata doesn’t need the size argument.

I believe the type system description is enough to see how the modification system works.

Downloading, building, etc.

Enough with the explanations, now let’s try the code. Remember that you’ll need also development files that I mentioned long time ago.

Clone the latest version from the git repository:

or download the tarball: python-epub.tar.bz2

Inside the source code directory create a build directory and …

The last command deserves some talking about.

Testing, Testing, Testing

When working with binding development there’s a myriad of things that can go wrong, and a number of them go wrong in complete silence. With this in mind, I tell you that having unit tests makes the binding developer life bearable.

To see detailed results from the tests, run ctest with -V (verbose) option.

Check the tests directory for examples on how to use the python-epub bindings.

UI Example (or else it would be boring)

But the UI itself is very boring, although it was made with the amazing PySide I did it as simple as possible, it doesn’t even show images. On the other hand, with very little code I can now see what’s inside an ePub ebook.

From python-epub/build directory call the ePub viewer like this:

It always expects a parameter with the path to an ePub file, in this case “Beyond the Wall of Sleep” by Lovecraft.

Screenshots:

Fomos lá no hospital Santa Maria, na minha cidade, pra render o turno da minha mãe, que está acompanhando meu tio na internação.
O hospital fica uns duzentos metros da casa dos meus pais. Mais duzentos metros e temos a casa do tio, e com mais duzetos é o cemitério. Tudo é perto na minha cidade, pouca necessidade de carro ou ônibus.

Só pra localizar melhor as coisas, esse tio não é um tio genérico, ele criou minha mãe como pai, logo é como se fosse meu avô. Todos chamamos ele de Nêgo (com ê mesmo). Ele tomava conta do pequeno eu de 5 anos (acho) enquanto minha mãe analisava amostras de sangue no laboratório. Mas meu tio também tinha seus compromissos de sacristão de uma paróquia, pra onde ele me levava. Lembro de ir pra uma extrema unção (ou era um velório?) onde fiquei cantando com o folhetinho virado de cabeça pra baixo.

Chegando na enfermaria do hospital mandamos minha mãe jantar. Eu tinha a intenção de entreter o doente, mas ele estava com a voz bem fraquinha pra conversar. Melhor uma estória. Então fiz a pergunta mágica ao meu pai sobre como vovô aprendeu a nadar tão bem vivendo num sítio no interior de Pernambuco.

Então, era uma vez meu bisavô, que não sei o nome, por causa de quem começa tudo. Tem essa estória vaga e difusa de que ele matou duas pessoas, em duas situações distintas, com tiros à queima roupa de seu perverso bacamarte. Me foi contado que ele socava vidro e pregos junto com a pólvora. Um dos tiros teria arrancado o coração de uma mulher e o outro a cabeça de um sujeito. Mas pode ter sido o oposto. A causa de tanta raiva pode ter sido fofoca e ciúme. Ele tinha uma amante e estavam contando pra minha bisavó. Meu bisavô, amante da paz que era tentou resolver do jeito dele. Contudo, nada é preciso nessa estória. Essas lendas de família são assim mesmo.

Fato é que nos idos de mil novecentos e dez e poucos os bandidos perigosos iam para… O que é que ele vai ganhar Lombardi? Uma viagem com tudo pago pra Fernando de Noronha, Silvio! E a estranheza só aumenta, meu pai contou que a família do condenado ia junto com ele, mas ficavam numa casa de verdade na ilha, e o meliante só precisava dormir na cela com provável vista pro mar. E essa era vida do meu bisavô, dormir no xilindró e fazer mais filhos durante o dia. Penso que ele só fazia pela diversão, mas cada filho nascido na ilha diminuia sua pena.

E foi assim que meu avô aprendeu a nadar, praticando dos 13 aos 18 em Fernando de Noronha, enquanto o pai cumpria pena por crimes hediondos.

Sabia desse conto só até essa parte, mas o mais legal de ouvir meu pai narrando tudo de novo é que sempre posso confiar na ampliação da estória com um detalhe que lembrou na hora. O detalhe dessa vez foi um tubarão.

Estavam pescando numa jangada lá no mar azul de Fernando de Noronha meu avô e seu irmão. Pescavam com anzol grande e corda resistente, esperando pegar algo graúdo. Pois foi um tubarão que veio, não sei a espécie, só sei que era do tipo com dentes afiados e do tamanho da jangada onde cabem duas pessoas.

Eles lutaram com o peixão por um bom tempo, até que o bicho virou o barquinho. Nessa parte da narrativa eu só acreditei que meu avô saiu vivo porque estavam o filho e o neto conversando sobre ele. Assisti muitos filmes de tubarão pra saber que o objetivo da espécie, em todas suas variantes, é o extermínio da raça humana. Veja o tubarão baleia por exemplo, aquele jeitão simpático dele, aquela boca de garagem de fusca, isso é só pra baixar nossa guarda.

Na vida real o tubarão com um gancho na boca só quer fugir. Vovô e seu irmão com suas inseparáveis facas (sim, os filhos do condenado andavam por aí com facas – eram aqueles tempos que todo mundo fala de amarrar cachorro com salsicha) só queriam um almoço de frutos do mar.

Bem, voltando, vovô conseguiu furar o tubarão e logo o bicho enfraquecia. Eles desviraram a jangada e jogaram o peixão no meio. Os pescadores adultos festejaram a habilidade e ousadia dos meus antepassados adolescentes e todos fizeram um feliz churrasco de tubarão.

Essas horas minha mãe já voltou e tenho um ônibus pra pegar.

Quando era pirralho alguém da minha rua (e “minha rua” aqui significa todas as ruas ao redor até as bordas do cemitério, que às vezes era incluído no território) teve a genialíssima idéia de inventar o dinheiro! Da mesma forma que alguém decidiu que um metal amarelo brilhante aparentemente inútil (eles não tinham processadores naquela época) valia mais que muitas vidas humanas, nós crianças decidimos que carteiras vazias de cigarro valiam algo. Lembro mais ou menos da escala: Hollywood valia 5 (tinha um cigarro bem ruinzinho que valia 1), Carlton valia 10, Camel e Marlboro eram 50, e um outro lá que todos chamavam de “capa preta” valia 100 (uma nota preta!). Quanto mais bling mais valor.

A senhora minha mãe é fumante antiga, acho até que tragava líquido aminiótico pelo cordão umbilical (por falar nisso, ela jura que não fumou na gravidez, mas não consigo acreditar nela porque isso explicaria muita coisa), e eu como mau filho que era estimulava seu vício pra pegar as carteiras vazias. O problema é que ela só fumava Hollywood o que me garantia uma renda muito baixa. Os moleques Bicho Solto eram mais empreendedores, andavam pelos bares e pelas ruas mais agitadas e faziam verdadeiras fortunas. Eu tinha de me contentar em andar olhando as sarjetas e ir pra casa às 9. Eu era classe média. Sim, a parte sobre ser milionário foi uma mentira pra prender sua atenção.

Mesmo todo esse dinheiro de carteiras de cigarro não podia comprar o mais reles chiclete, além de nossas necessitades básicas serem plenamente atendidas pelos pais. Então, o que nos restava fazer com o dinheiro? Ver quem era o mais rico é uma das primeiras coisas pra fazer num grupo de pessoas com dinheiro em excesso. Não tínhamos um top 100 da Forbes, mas Moacir era sem sombra de dúvida nicotinicamente podre de rico, tinha até carteira de cigarro importado. Todos se admiravam. Ele era o cara mais de rua que podia existir, e também era muito doido, do tipo Forrest Gump (me lembro agora da história de como ele ficou comovido quando meu primo o levou no puteiro — mas isso aqui não é mil e uma noites, então vamos voltar à história). E claro que foi Moacir, bilionário entrepreneur, que nos levou pro próximo nível das pessoas com dinheiro e sem ter com que gastar: o jogo!

Moacir passou a andar com uma caixa, que desdobrada bem embaixo da luz de um dos poucos postes da grande ladeira no fim da rua, se tornava um cassino completo. Não exatamente completo, não tínhamos cartas, mas os dados e a roleta estavam lá pra quem quisesse apostar. “Derby?! Pode ir tirando esses couros-de-rato daqui que a aposta é alta: Carlton pra cima!”, “Porra, Moacir, aceita aí meus Hollywoods que ainda tá valendo.”, “Tá, tá, tá, então aposta logo essa miséria!” Cara, perdi tantos Hollywoods, mas foi melhor assim, em troca aprendi uma importante lição vendo Moacir enriquecer e todos os outros ficando pobres: no fim a casa leva.

Só tem um nível que nós ricaços das carteiras de cigarro não alcançamos: as putas. Nunca apareceu uma menina pra dançar no meio-fio do lado do cassino me permitindo colocar minhas carteiras vazias de Hollywood (provavelmente eu economizaria botando umas de Derby) na sua enorme calcinha de algodão.

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.

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.

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.

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

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. спасибо!

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

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.

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.

Imagino que o parêntese do último parágrafo cobre todo pr0n desse texto.

A repulsa pela a bíblia por parte das pessoas racionais e outros bichos parecidos provavelmente é gerada por causa do que ela e as pessoas que vendem esse peixe representam do que pelo conteúdo. Não vai faltar quem diga quantas mortes, guerras e manhãs de domingo entediantes aconteceram por causa de religião e tudo que lhe é relacionado. Também sobre a irracionalidade que causa nas pessoas e por aí vai. Por compartilhar vagamente dessas opiniões por muito tempo (e por ser importunado pra participar de grupos de estudo bíblicos de quanto em vez) algum mecanismo automático na minha cabeça colocava uma etiqueta de “anti- ou semi-racional” em qualquer pessoa segurando um livro preto de letras douradas e lateral das folhas vermelhas.

Moeda Romana com Otávio Augusto

Então eu esqueço esses problemas e vou ler qualquer outra coisa “de nível”, o que é esperado de uma pessoa racional. Vou de “A Desobediência Civil” de Henry Thoreau. “Sob um governo que prende qualquer homem injustamente, o único lugar digno para um homem justo é também a prisão.” É assim que se fala, Thoreau! (Embora eu mesmo não queira ir pra cadeia, e talvez você não tivesse ouvido falar de algo como Carandiru.) Texto vai, texto vem, chega na parte sobre governo, impostos e ele me vem com essa citação:

Cristo respondeu aos seguidores de Herodes de acordo com a situação deles. “Mostrem-me o dinheiro dos tributos”, disse ele; e um deles tirou do bolso uma moeda. Disse então Jesus Cristo: “Se vocês usam o dinheiro com a imagem de César, dinheiro que ele colocou em circulação e ao qual ele deu valor, ou seja, se vocês são homens do Estado e estão felizes de se aproveitar das vantagens do governo de César, então paguem-no por isso quando ele o exigir. Por­tanto, dai a César o que é de César, e a Deus o que é de Deus”; Cristo não lhes disse nada sobre como distinguir um do outro; eles não queriam saber isso.
A Desobediência Civil

Muito esperto Jesus, recebeu a bola e devolveu com efeito.

A Roda da Fortuna

Depois fui pra George Orwell. Tem um ensaio chamado “Politics and the English Language”, onde ele discute como o pensamento de uma sociedade decadente corrompe a língua e como a língua corrompida aumenta ainda mais a decadência. Essa corrupção aparece na forma de textos vagos, usando uma colagem de frases prontas que esconde o que o autor quer dizer (às vezes dele mesmo) e ainda dão umas duas mãos de tinta de respeitabilidade em cima de baboseiras que se ditas claramente seriam rejeitadas no mesmo instante. Num dado momento Orwell mostra um texto claro, com imagens fortes e que passa a idéia básica do autor muito bem:

I returned, and saw under the sun, that the race is not to the swift, nor the battle to the strong, neither yet bread to the wise, nor yet riches to men of understanding, nor yet favor to men of skill; but time and chance to them all.

Voltei-me, e vi debaixo do sol que não é dos ligeiros a carreira, nem dos fortes a batalha, nem tampouco dos sábios o pão, nem tampouco dos prudentes as riquezas, nem tampouco dos entendidos o favor, mas que o tempo e a oportunidade ocorrem a todos. (Tradução de alguém na internet.)

E para demostrar seu ponto de vista reescreve o trecho no que ele chama de “inglês moderno”:

Objective consideration of contemporary phenomena compels the conclusion that success or failure in competitive activities exhibits no tendency to be commensurate with innate capacity, but that a considerable element of the unpredictable must invariably be taken into account.

Consideração objetiva de fenômenos contemporâneos compele a conclusão de que sucesso ou fracasso em atividades competitivas não exibe qualquer tendência a ser passível de redução à capacidades inatas, mas que a considerável influência do elemento da imprevisíbilidade deve ser levada em consideração. (Minha tradução.)

Essa comparação ilustra bem a idéia do ensaio, e o primeiro texto achei excelente (em português e inglês), quem o escreveu deve ter vivido o que dizia, e qualquer um lendo já deve ter passado algo assim. Quero dizer, é o tipo de preocupação com a qual todos podem se identificar. Recomendo duplamente o ensaio. E também o restante do texto-exemplo.

Holy Pr0n!

Outra coisa que acho legal é literatura inglesa, embora não tenha tempo e memória pra ficar esnobando nos círculos sociais por aí :P. Teve uma época que trabalhei numa biblioteca de faculdade e um livro encontrado por acaso (todos eram) e devorado (e os detalhes esquecidos. sabe, memória e tals, dammit!) chamava-se “A Literatura Inglesa” de Anthony Burgess (o cara de Laranja Mecânica (o autor, não o personagem)). O livro foi escrito como um mastigadão (no bom sentido) de literatura inglesa pra ajudar alunos do Burgess em algum lugar pela Malásia. A prova final de inglês incluía o conhecimento de obras literárias um tanto alienígenas pros caras de lá e o livro adicionava um pouco de contexto histórico. Pra um livro escolar achei esse um dos mais agradáveis de ler (não contando os trechos legais em livros de “Comunicação e Expressão”, mas esses acabavam logo e não tinha livraria na minha cidade pra comprar a versão integral) e demoliu uns muros velhos da minha antiga aversão à literatura.

Burgess começa falando das origens da língua, saxões, normandos e tudo mais, até que chega num capítulo sem número entre o 5 e o 6 com o seguinte título: “Interlúdio – A Bíblia inglesa”. E o primeiro parágrafo é o seguinte:

Vamos examinar muito sumariamente um livro cuja influência sobre a escrita, a fala e o pensamento inglês foi, e ainda é, imansa. A Bíblia não é basicamente literatura – é o livro sagrado do cristianismo -, mas recentemente vem se afirmando uma tendência crescente para apreciar a Bíblia por suas qualidades artísticas, para vê-la não só como a “Palavra de Deus”, mas como uma obra de grandes escritores. Sejam quais forem nossas crenças religiosas, se desejarmos ter uma apreciação integral do desenvolvimento da literatura inglesa, não podemos nos arriscar a negligenciar a Bíblia: seu impacto puramente literário nos escritores ingleses é talvez grande demais para ser medido.

A tradução da Bíblia (agora que tenho sua atenção posso usar o ‘B’ maiúsculo sem parecer um carola) para o inglês foi encomendada pelo Rei James I. A tarefa foi realizada (com muito cuidado) por 47 eruditos de 1604 até 1611 (foi muito cuidado mesmo). No final entregaram um texto tão bom que segura audiências até os dias de hoje. Segundo Burguess: “Não há escritopr que não tenha sido influenciado por ela – até mesmo escritores como Bernard Shaw e H. G. Wells, apesar de não serem cristãos, acabaram sucumbindo à sua força.”

Outro dia comprei uma King Jame’s Bible, logo de cara gostei dessa parte (Genesis 1:2):

The earth was formless and void, and darkness was over the surface of the deep, and the Spirit of God was moving over the surface of the waters.

(E a terra era sem forma e vazia; e havia trevas sobre a face do abismo; e o Espírito de Deus se movia sobre a face das águas.)

Não sei se é tietagem minha com a língua inglesa ou se a versão em português me lembra ser acordado à força no domingo pra continuar dormindo numa posição desconfortável na igreja, mas gosto mais da versão Jamesiana do que a tradução nos parênteses. As palavras em “formless and void” e “darkness was over the surface of the deep” soam tão bem. E “the Spirit of God was moving over the surface of the waters” gera uma imagem mental do “Espírito de Deus” sendo uma Jamanta (não o caminhão, ou aquele louco de uma novela esquecida – o que nos leva a outra tietagem: “Jamanta” simplesmente não soa tão bem quanto “Manta Ray”).

"Then God said, 'Let there be light'; and there was light."

Saindo da literatura e me interessando por eventos recentes. Todos (que pensam) já se perguntaram quanto do terrorismo fundamentalista islâmico é coisa de fundamentalistas, se o islamismo é mesmo violento em seu núcleo, ou se é inerente de qualquer religião, já que elas causam mortes guerras e constrangimento, como quando você é flagrado por seus amigos racionais lendo a Bíblia.

Esse assunto em particular é bem espinhento. Se você se der ao trabalho de procurar vai ter seu saco ou ovários enchidos até o limite com opiniões que vão de um extremo politicamente correto onde tudo é bom, todos são bons, ninguém pode ser ofendido e que mulheres de burka trancadas em casa são felizes do jeito delas, até o outro extremo (lá pelo lado direito) com pessoas que tudo que precisam é uma desculpa pra expulsar/matar/desintegrar os “alienígenas indesejáveis” do seu país.

Oriana Fallaci (foto "emprestada" de El País)

Persistindo dá pra encontrar umas pessoas interessantes, como Ayaan Hirsi Ali, aquela moça da Somália que escapou da família pra Europa e chegou a parlamentar nos Países Baixos. Ou a menos famosa (pelo menos pra mim) Oriana Fallaci, que aos 10 anos participou da Resistência Italiana, aos 16 era repórter, foi ao Vietnam como correspondente 12 vezes, e por aí vai. Meu episódio preferido é o da entrevista com o aiatolá Khomeini em 1979:

“Como é possível nadar com um chador [traje feminino que cobre todo o corpo, deixando apenas os olhos de fora]?”. A resposta do líder, Oriana escreveu depois no New York Times, foi que ela não era obrigada a usar um, já que se tratava de uma peça de roupa para mulheres islâmicas respeitáveis. A jornalista, então, rasgou seu chador na frente de Khomeini.
Morre a polêmica jornalista e escritora italiana

Mas o que interessa nesse texto é como ela se define como Ateísta Cristã no livro A Força da Razão. Dizem que o livro em si é tão polêmico que devia vir com um martelo e uma caixa de vidro escrita “Quebre em Caso de Emergência”, mas voltemos à afirmação:

Sou uma Cristã porque gosto do discurso que está nas raízes do Cristianismo. Porque ele me convence. Ele me seduz… Quero dizer, o discurso concebido por Jesus de Nazaré… que… se concentra no Homem. Que adimitindo o livre-arbítrio, clama pela consciência do Homem, nos faz responsáveis por nossas ações. Mestres de nosso destino. Eu vejo um hino à Razão, uma renovação do pensamento claro… escolha… a redescoberta da liberdade. A redenção da liberdade… uma idéia que ninguém jamais teve… A idéia de um Deus que se tornou Homem… Que falando de um Criador… se apresenta como seu Filho e explica que todos os homens são irmãos de seu Filho… capaz de exercer sua própria essência divina… pregando a Bondade que é o fruto da Razão, da Liberdade, espalhando o Amor… Jesus… como um homem… aborda o tema do secularismo… ele impede os covardes que estão para apedrejar a adúltera… ele ataca a escravidão… ele luta… ele morre. Sem morrer pois a Vida não morre. A Vida sempre ressucita, Vida é eterna. E, junto com o discurso sobre a Razão, sobre a Liberdade, este é o ponto que mais me convence… a negação da Morte, a apoteose da Vida… sua alternativa é a Não-Existência. E vamos encarar: tal é o princípio que guia e alimenta nossa civilização.

Essa tradução é do único trecho que pude encontrar na internet (sem recorrer a torrents de PDFs) onde Oriana Fallaci elabora essa idéia de Ateísmo Cristão dela. Veio de um artigo de uma revista conservadora norte-americana. Os conservadores provavelmente vão pegar a finada como Joana D’Arc involuntária deles ou sei lá, mas esse é ainda outro problema, que de fato não é meu.

O meu problema é que já escrevi bastante. Preciso pensar como finalizar isso tudo e botar umas figuras legais pra disfarçar a compridez do texto. Opa! Falei isso em voz alta?!

A conclusão não sagaz é o bom e velho “não julgue o livro pela capa” que o He-Man diria num final de episódio. Pensando mais um pouco dá pra perceber (eu pelo menos) que tomamos muita coisa como garantida, como esperar um comportamento decente por parte dos assim chamados Outros (citação obrigatória do Luck (não Luke): “Não se preocupe com os outros, tem muitos mais de onde esses vieram.”), ou que a civilização (no sentido de educação e respeito, não no sentido de eletrônicos chineses feitos por trabalhadores sem assistência social) brotou de grátis do nada como o mundo que o Grande Deus Jamanta tirou do vácuo. Bom, tem uma meia dúzia de idéias que fazem sua vida não tão ruim quanto a da galera num filme de Mad Max que, dentre outros lugares, veio da Bíblia. Por exemplo: “E como vós quereis que os homens vos façam, da mesma maneira lhes fazei vós, também.”, Lucas 6:31; ou “And as ye would that men should do to you, do ye also to them likewise.”, Luke 6:31. Então se me encontrarem lendo uma Bíblia por aí lembre de tratar os outros como gostaria de ser tratado e não me encha o saco. Aliás, sinta-se livre pra tratar os outros direito (estou levando em consideração que você não é masoquista), quer saber, pra ficar mais fácil ainda: deixe-os em paz. Do que estamos agora pra isso já seria uma grande melhora.