Category Archives: Programming

The black magic of GDI+

One of the things I am most ashamed of on Quivi is its speed when opening large images (which are not uncommon nowadays, specially with digital photos). It’s embarrassing that the lame Windows Picture and Fax Viewer is lightning fast when opening those images!

I’ve always wondered how the Viewer did that. I’ve searched about it in the past but could never find anything about it. Then one of these days I was browsing the Wikipedia page about the Viewer and there I learned that it uses GDI+.

GDI+ is a C++ library, but it is built upon a flat C API which I could easily use in Python via ctypes. Long story short, I was able to modify Quivi to add support for viewing images with GDI+. And the result was amazing!

What about Linux? Well, something “equivalent” to GDI+ would be Cairo, so I did some tests with it too (luckily, support for it was included in wxPython recently).

Here are the results for the time to load a huge 5704px x 5659px PNG image and rescale it to 1/20 of its size:

Time to load and scale a PNG image
Library Time (s)
FreeImage 10.38
PIL 9.90
GDI+ 2.22
Cairo (from FreeImage) 3.60
Cairo (direct) 3.28

The reason for the two Cairo timings is that it supports reading directly from a PNG file but for e.g. JPG files you need to read the image with another library and to the format Cairo uses. I’ve used FreeImage to load the image and converted it to a Cairo surface.

Here are the results for the time to load and scaling the same image, but as a JPG:

Time to load and scale a JPG image
Library Time (s)
FreeImage 6.91
PIL 8.38
GDI+ 0.19
Cairo (from FreeImage) 1.43

Scary! How does GDI+ manages to do that? According to Wikipedia it uses hardware acceleration… Cairo doesn’t lag begind considering that the scaling only takes 0.015 (!) but I did notice that even its best quality scaling isn’t so good in comparison to the others, which is kinda odd.

Anyway, I’ll try to release a new version of Quivi with GDI+ and Cairo support soon. Stay tuned.

Yet another silly Python vs Java comparison

I’ve been hacking the mspsim (a simulator) source to add support for a couple of stuffs in its profiler. At a certain point I had a hash table mapping functions to how many times they were called, and I had to sort them by that number of times. How to do that?

1
2
3
4
5
6
7
List<Entry<MapEntry, Integer>> list = new LinkedList<Entry<MapEntry, Integer>>(callers.entrySet());
Collections.sort(list, new Comparator<Entry<MapEntry, Integer>>() {
    @Override
    public int compare(Entry<MapEntry, Integer> o1, Entry<MapEntry, Integer> o2) {
      return o2.getValue().compareTo(o1.getValue());
    }
});

And if it were Python:

1
lst = sorted(((n, fn) for fn, n in callers.iteritems()), reverse=True)

Yep, Java can be a pain.

Of course it’s not that simple, though. I’ve tested another simulator in Python and its code is very nice and readable and warm and fuzzy…

…but it’s 30 times slower than the Java one.

Sandbox Wordpress theme for 2.7 with threaded comments

The Sandbox Wordpress theme is a nice bare bones theme which can be easily used as a base to your own themes (preferably with a style.css file only, following the zen). The only problem is that its development is kinda frozen and it does not support new Wordpress 2.7 features like threaded and paged comments.

There are already some hacks to support them but I decided to take another approach. Since the comment loop was changed drastically, those hacks had to… well, hack away in order to keep backward compatibility with Sandbox-based themes. Instead, I decided to embrace the new comment loop in WP (which is simple and doesn’t allow much customization without resorting to the hackish callback, but it generates code very close to what Sandbox does).

If you like the idea, feel free to download my customization (just overwrite the comments.php and header.php in Sandbox). You’ll probably have to tweak your previous themes a little, though.

Tip: if you want do get rid of the “says:” in the comments (e.g. “Alice says:”), put this in your stylesheet:

.says { display: none; }

If you want to change the avatar size, change the following line in comments.php

<?php wp_list_comments(); ?>

to

<?php wp_list_comments('avatar_size=40'); ?>

(change 40 to whichever size you want)

…and I’ve not activated it in this blog for now, since it barely gets comments. Sorry, no live preview :)

Access violation errors with callbacks in ctypes

I’ve just spent a few hours trying to solve this bug, so I’m publishing this so maybe it will help someone with this issue…

Assume that you’re working with a DLL/.so library through ctypes in Python, and this library allows you to set a callback for some other function. In my case, I was working with unrar.dll. The code was something among these lines:

UNRARCALLBACK = ctypes.WINFUNCTYPE(ctypes.c_int, ctypes.c_uint, ctypes.c_long, ctypes.c_long, ctypes.c_long)
 
#in a class...
RARSetCallback(self.handle, UNRARCALLBACK(self.callback_fn), 0)
RARProcessFile(self.handle, RAR_TEST, None, None)

The first lines constructs the function prototype, the second sets the callback in a function of the DLL file, and the third calls a function in the DLL which will call the callback.

Can you spot the error?

The code worked fine in Python 2.5, but then I changed to 2.6 and it stopped working. I got a “WindowsError: exception: access violation reading…” (or writing) exception in the third call.

The reason, which is obvious in hindsight, is cleared explained in the docs:

Make sure you keep references to CFUNCTYPE objects as long as they are used from C code. ctypes doesn’t, and if you don’t, they may be garbage collected, crashing your program when a callback is made.

(Though it’s not explicit, it applies to WINFUNCTYPE objects too)

The WINFUNCTYPE object created in the second line no longer exists in the third line, so when the callback was called, it no longer pointed to a valid address. The solution is simple — just keep a reference to the object:

UNRARCALLBACK = ctypes.WINFUNCTYPE(ctypes.c_int, ctypes.c_uint, ctypes.c_long, ctypes.c_long, ctypes.c_long)
 
#inside a class...
self.callback_ref = UNRARCALLBACK(self.callback_fn)
RARSetCallback(self.rarFile.RAR._handle, self.callback_ref, 0)
RARProcessFile(self.rarFile.RAR._handle, RAR_TEST, None, None)

The only mystery left is why the old code worked on 2.5!

Porque eu reescrevi o Quivi do zero

Joel Spolsky, programador conhecido, disse em seu blog:

(…) Eles [da Netscape] fizeram isso tomando a pior decisão estratégica que uma compania de software pode fazer:

Eles decidiram reescrever o código do zero.

Em concordo, a princípio. Muitos projetos anunciam que foram “reescritos do zero” como se isso fosse algo maravilhoso, e na maioria das vezes, é só um sinal que a nova versão provavelmente tem mais bugs que a anterior.

Mas peraí, eu acabei de reescrever o Quivi (um visualizador de imagens e leitor de HQ’s / mangás) do zero! Por quê, então?

Bom, pensei que seria necessário me justificar. Essas são as razões:

  • É um projeto pequeno. Reescrevê-lo com certeza não é tão difícil quanto reescrever um navegador!
  • Eu não aguentava mais C++ (a linguagem de programação que eu utilizava). Claro, isso não é exatamente culpa do C++. Ele tem seus usos — a ferramente certa para o trabalho certo, e tudo o mais. Mas para escrever um programa de desktop? É canhão para matar formiga. Se você consegue (e gosta!) de fazer isso, eu admiro você. Mas eu não tinha mais motivação para trabalhar no Quivi.
  • Eu adoro Python (a linguagem de programação que eu uso agora), e claro,
    não sou o único. Programar é divertido em Python, tanto que eu tive a motivação de reescrever tudo, para começo de conversa! E claro, agora vai ser muito mais fácil para eu continuar trabalhando no Quivi.
  • Eu podia mudar de bibilioteca de interface. O SmartWin é uma boa bibilioteca, e use templates de formas interessantes; enquanto eu programava o Quivi eu acabei participando do desenvolvimento do SmartWin também. Mas ele tem os seus bugs, e justamente porque ele usa templates extensivamente, compilar um programa que o utilize é lento demais. Eu mudei para o wxPython, que é uma biblioteca de interface muito madura — e multi plataforma ainda por cima.

Claro, existem algumas desvantagens com a mudança. O pacote inteiro é muito maior devido às dependências (o instalador foi de 900K para 5MB!). E o programa é um pouco mais lento, principalmente na inicialização, e usa mais memória (9MB para 30MB com nenhum imagem aberta). Mas eu acredito que foi um bom compromisso.

Reescrever do zero deve ser estudado com cuidado, e neste caso, acredito que foi uma boa idéia. O Quivi é um hobby, e acho que o ponto principal é me divertir escrevendo ele, e atender às necessidades dos usuários. Espero que eu consiga fazer os dois com esta nova versão (que será lançada em breve).

Why I rewrote Quivi from scratch

Joel Spolsky, popular software engineering, said in this blog:

(…) They [Netscape] did it by making the single worst strategic mistake that any software company can make:

They decided to rewrite the code from scratch.

I agree, mostly. Many projects market that they’ve been “rewritten from scratch” as if it was something marvelous, and most of time, it’s just a sign that the new version probably has more bugs than the previous. But, wait, I just rewrote Quivi (a image viewer and comic / manga reader) from scratch! Well, why?

Well, I thought I really had to justify this. So here are the reasons:

  • It is a small project. Rewriting it certainly isn’t as hard as rewriting a browser!
  • I couldn’t stand C++ anymore (the programming language I used before). Of course, this isn’t C++ fault per se. It has its uses — the right tool for the right job, and so on. But to write an desktop application? It’s overkill. If you manage to pull it of, hey, kudos to you. But I had no motivation to work on it anymore.
  • I love Python (the programming language I use now), and of course, I’m not the only one. Programming is fun in Python, so much that had the motivation to rewrite Quivi from scratch in the first place! And of course, it will be much more easier for me to keep working on Quivi.
  • I could change GUI libraries. SmartWin is a nice library, and uses templates in very interesting ways; when programming Quivi I ended up involved with its development too. But it has its bugs, and because it uses templates extensively, it’s awful slow to compile an application that uses it. I’ve changed to wxPython, which is a very mature GUI library – and cross platform to boot.

Of course, there are some downsides with the change. The whole software package is much bigger due to the dependencies (the installer jumped from 900K to 5MB!). And the program is a little bit slower, mainly when starting up, and uses more memory (9MB to 30MB with no images loaded). But I think it was a good enough trade-off.

Rewriting from scratch must be considered carefully, and in this case, I think it was a good idea. Quivi is a hobby project, and I guess the main point of it is to have fun writing it, and to make users happy. I hope I can do both with this new version (which will be released soon).

Ensinando programação C: Culto à carga

Este semestre estou participando de um estágio docente e sou responsável pelas aulas de laboratório de uma disciplina de introdução à algoritmos e programação, na linguagem C.

Está sendo interessante, mas ainda estou com medo que eles não estejam entendendo bulhufas.

A primeira coisa que eu já notei, e já vi em muitos lugares, é que aparentemente algumas pessoas já têm mentalidade de programador. Você explica, elas entendem. Já a maioria das pessoas não têm, e por mais que você explique, elas não conseguem chegar nas soluções sozinhas. Não que elas sejam burras, longe disso. Mas parece que para aprender programação todos têm que passar por uma “caída de ficha”. Eu não sei explicar bem como acontece, mas chega num momento, quando você começa a aprender a programar, em que “a ficha cai”. A partir daí você tem lá suas dificuldades, mas no fim você acaba conseguindo aprender o resto. O problema vai ser conseguir fazer essa ficha cair para todos!

Uma coisa que eu vejo bastante é algo parecido com o que chamam de “programação de culto à carga“, inspirada no fenômeno chamado cultos à carga de algumas tribos polinésias que idolatravam as cargas jogadas pelos deuses/aviões na segunda guerra. Em programação, chamam isso da atitude de copiar código de outros lugares na esperança que aquilo vá resolver seu problema, sem você entender de fato o que faz aquele código.

É o que acontece muito na aula (claro que justificável). Os alunos copiam os trechos que a professora passa como se fossem um conjunto de palavras mágicas que vai resolver o problema deles, mas eles não entendem de fato o que aquele código faz. E é claro que na hora de eles resolverem os problemas sozinhos, eles não conseguem.

Ainda não sei bem como vou fazer eles perceberem isso. Ainda estamos no começo do semestre, mas já estou ficando um pouco preocupado. Eu ainda não consegui nem convencê-los a indentar código; já expliquei o porquê de indentar; já pedi para eles indentarem; e nada. O jeito vai ser ameçar tirar nota se eles não indentarem, mas realmente acho isso muito tosco…

(E definitivamente, depois de 17 anos sendo aluno, é bizarro ser chamado de “professor”)

Python, Phyton… Pytohn?

Essa é nova:

As primeiras versões para Java e Pytohn já estão disponíveis para download a partir do serviço Google Code.

Não dá para entender a inabilidade geral das pessoas de escreverem “Python” direito.

Pegadinha com closures (ilustrado em Python)

(Embora ilustrado em Python, creio que conhecer Python não seja totalmente necessário para entender o post :) )

Você conhece o conceito de closures (“fecho”, mas acho que ninguém usa o termo em português…)? Basicamente, é quando você pode definir uma função em tempo de execução e esta função faz referência a variáveis de um escopo externo a ela. Por exemplo:

def make_number_printer(n):
    def number_printer():
        print n
    return number_printer
 
printer = make_number_printer(5)
printer()

A função make_number_printer recebe um número e retorna uma função que, quando chamada, imprime esse mesmo número. Não é a função mais útil do universo, mas ilustra bem o conceito de closure. No caso, a função number_printer é uma closure, pois referencia a variável n que está num escopo externo (o da função make_number_printer).

Porém minha intenção aqui não é tanto explicar o que são closures, mas sim ilustrar uma característica que pode acabar confundindo (já perdi um bom tempo caçando um bug causado por isso). O que esse código imprime?

printer_lst = []
for i in xrange(10):
    def number_printer():
        print i
    printer_lst.append(number_printer)
 
for printer in printer_lst:
    printer()

Ele executa um loop de 0 a 9, em cada iteração criando uma função number_printer e colocando-a numa lista, e em seguida percorre essa lista chamando todas as funções. Era de se esperar que ele imprimisse os números de 0 a 9, certo?

Errado! Ele imprime o número 9 dez vezes.

O problema é que na maioria das vezes, intuitivamente pensa-se que as closures funcionam “fixando” o valor das variáveis externas que elas referenciam para usá-las num momento posterior. Mas na verdades elas guardam uma referência àquela variável, e se ela mudar de valor, a closure usará o valor alterado. Como a nossa variável i vale 9 no final da criação das closures, esse é o valor que todas vão imprimir. Isso vale mesmo se a variável i deixar de existir após a criação das closures (por exemplo, se o primeiro for estivesse dentro de uma função).

Como resolver isso? Você pode mover a criação da closure para uma outra função, desta forma:

def make_number_printer(n):
    def number_printer():
        print n
    return number_printer
 
printer_lst = []
for i in xrange(10):
    printer_lst.append(make_number_printer(i))
 
for printer in printer_lst:
    printer()

Assim a closure irá referenciar a variável n, que possui instâncias diferentes para cada closure diferente criada. Outra alternativa é utilizar um “recurso” polêmico do Python, que é o fato de que os valores de parâmetros com valores padrão são avaliados quando a função é definida, e não quando ela é chamada:

printer_lst = []
for i in xrange(10):
    def number_printer(x=i):
        print x
    printer_lst.append(number_printer)
 
for printer in printer_lst:
    printer()

Ao executar def number_printer(x=i):, o valor de i é avaliado e salvo permanentemente na definição da função; assim, cada vez que a função é definida (a closure é criada) o valor atual de i é “congelado”.

Se alguém se estiver perguntando, “mas eu nunca vou acabar me deparando com isso”, este é um exemplo um pouco mais próximo da realidade (na verdade me bati com ele quando programava um jogo em Flash, que usa ActionScript). Fundamentalmente é o mesmo código acima e apresenta o mesmo problema:

class Button:
    #Esta é uma classe para simular um botão, suponha
    #que é parte de uma biblioteca de GUI e por alguma
    #razão você não pode herdar dela
 
    def __init__(self):
        self.listener = None
 
    def set_click_listener(self, fn):
        self.listener = fn
 
    def on_click(self):
        self.listener()
 
#Cria 10 botões...
buttons = [Button() for i in xrange(10)]
#E suponha que eles são adicionados na interface
 
#Seta os listeners para o evento de clique.
#O número de botões pode mudar no futuro
#e todos têm o mesmo código, a única diferença
#sendo o índice do botão. Então é melhor fazer isso
#dentro de um loop.
for i in xrange(10):
    def on_click():
        #Imagine que o código aqui seja mais útil
        print i
    buttons[i].set_click_listener(on_click)
 
#Simula um clique em cada botão
for j in xrange(10):
    buttons[j].on_click()

Closure gotcha (with Python)

Do you know what a closure is? Basically, it’s a function created at runtime that references variables defined in a outer scope. For example:

def make_number_printer(n):
    def number_printer():
        print n
    return number_printer
 
printer = make_number_printer(5)
printer()

The function make_number_printer receives a number and returns a function which, when called, prints that same number. It’s not the most useful function in the world, but it does show how closures work. In this case, the number_printer function is a closure, because it references the variable n which is in an outer scope (of the make_number_printer function).

My intention here, though, it’s not to explain what closures are but to show a property of them which may cause some confusion (and made me spent quite some time hunting for a bug caused by it). What does this code prints when run?

printer_lst = []
for i in xrange(10):
    def number_printer():
        print i
    printer_lst.append(number_printer)
 
for printer in printer_lst:
    printer()

It loops between 0 and 10 creating a number_printer function and appending it to a list. Then it loops through the functions of the list, calling them. You would expect it to print the numbers 0 to 9, right?

Wrong! It prints the number 9 ten times.

The problem is that most people (including me, before learning this) think that closures work by evaluating the variables in the outer scope and storing their values to use when necessary. But actually they keep an reference to those variables, and if their contents change, the closure will use the new value. Since our variable i stores the value 9 after the closures are created, that is the value they will print. This happens even if the variable i goes out of scope after the closures are created (e.g., if the first for were inside a function).

So how to solve this? You can move the creation of the closure to another function, like this:

def make_number_printer(n):
    def number_printer():
        print n
    return number_printer
 
printer_lst = []
for i in xrange(10):
    printer_lst.append(make_number_printer(i))
 
for printer in printer_lst:
    printer()

Here the closure will reference the variable n, which has different instances for each different closure created. Another alternative is to use a somewhat contrived Python “feature” which is the fact that default parameter values are evaluated when the function is defined and not when they are called:

printer_lst = []
for i in xrange(10):
    def number_printer(x=i):
        print x
    printer_lst.append(number_printer)
 
for printer in printer_lst:
    printer()

When def number_printer(x=i): is run, the variable i is evaluated and its value is saved in the function definition; so, each time the function is defined (i.e., the closure is created), the current value of i is “frozen”.

If somebody is thinking, “but I’ll never run into this situation”, here is a little more real example (which actually happened to me when I was coding a Flash game, which uses ActionScript). Basically it’s the same code above and has the same issue:

class Button:
    #This is a dummy Button class; suppose
    #it's part of a GUI library and for some reason
    #you can't subclass it
 
    def __init__(self):
        self.listener = None
 
    def set_click_listener(self, fn):
        self.listener = fn
 
    def on_click(self):
        self.listener()
 
#Create 10 buttons...
buttons = [Button() for i in xrange(10)]
#And suppose the buttons are added to the GUI after
 
#Set the listeners to the click event.
#The number of buttons may change in the future
#and all of them have the same code, the
#only difference is the button index. So it's better
#to do this within a loop. 
for i in xrange(10):
    def on_click():
        #Suppose there is something more useful here
        print i
    buttons[i].set_click_listener(on_click)
 
#Simulate a click in each button
for j in xrange(10):
    buttons[j].on_click()