… o gráfico foi gerado agregando todos os emails que enviei nos últimos seis anos^[1] por hora e dividindo pelo total. Achei interessante que um bloco bem grande de horas tenha valores parecidos.

E o script para gerá-lo começa por pegar o campo Date de todos os emails, depois o divide em colunas separadas por “:” para se livrar do “Date:” inicial, remove as entradas inválidas, como emails em HTML^[2], emails com data não padrão (usando “/” para separação), emails com especificação de hora estranha (a remoção do “at”^[3]. Depois disso, as datas são passadas para o comando date do unix, convertidas para UTC, pois queria todas as horas em UTC-3, e as horas são repassadas ao script de plotagem:

SENT_MAIL=/caminho/para/emails/enviados

grep -r ^Date: ${SENT_MAIL} | \
cut --complement -d : -f 1-3 | \
grep -v \<br\> | grep -v \/ | grep -v 'at' | \
date -f /dev/stdin -u +%H | \
./plot.py

O script de plotagem recebe as horas, as soma e, por fim, as exibe:

import numpy as np
from pylab import *
from math import sqrt

bins = {}

for line in sys.stdin:
    hour = int(line.strip()) - 3
    if hour < 0:
        hour += 24
    bins[hour] = bins.get(hour, 0) + 1

SAMPLES = len(bins)
width = 0.35 * 0.5
total = float(sum(bins.values()))
stuff = [i/total for i in bins.values()]

ind = np.arange(SAMPLES + 1)
ind = 0.5 * (ind[1:]+ind[:-1])

fdata = figure()

p = bar(ind, stuff)
xticks(ind + width/2 + 0.3, [i + 1 for i in range(SAMPLES + 1)])

title('Chance de eu enviar um email por hora')
xlabel('Hora do dia')
ylabel('"Probabilidade"')

defsize = fdata.get_size_inches()
golden = (sqrt(5) - 1)/2
fdata.set_size_inches(defsize[0], defsize[1] * golden)

grid()

fdata.savefig('mails.png')

Sentia falta de escrever esses scripts inúteis. Esses webmails da vida bem que poderiam exibir uns dados assim. Garanto que eles têm esse tipo de informação.

Bônus

Fiz um script em Python capaz de coletar as datas dos emails enviados do Gmail via IMAP. Obviamente, o acesso IMAP deve ser habilitado para que o script funcione. O script deve funcionar em qualquer Python da série 2.x na versão 2.4 ou superior.

#!/usr/bin/python

import getpass, imaplib

ssl  = True
host = 'imap.gmail.com'
mbox = '[Gmail]/Sent Mail'
port = 993 if ssl else None
imapmethod = imaplib.IMAP4_SSL if ssl else imaplib.IMAP4

def main():
    user = raw_input('Username: ')
    conn = imapmethod(host, port)
    conn.login(user, getpass.getpass())
    conn.select(mailbox = mbox)
    typ, data = conn.search(None, 'ALL')
    for mnum in data[0].split():
        _, tmp = conn.fetch(mnum, '(BODY[HEADER.FIELDS (DATE)])')
        date = tmp[0][1].strip()
        print date
    conn.close()
    conn.logout()

if __name__ == '__main__':
    main()

Textos Relacionados (gerado automaticamente):

1. Migrando do nmzmail para o mu

“Impostor syndrome” is the name given to the feelings that Abigail and many other young scientists describe: Their accomplishments are just luck or deceit, and they’re in over their heads. The key to getting past it, experts say, is making accurate, realistic assessments of your performance. Perhaps equally important: knowing you’re not alone. Abigail thinks that sharing her feelings with other people is how she will eventually come to grips with her sense of feeling like an impostor. “It’s fantastic to hear other people say, ‘I’ve felt that way, too.’ “

And it continues to say that

( … ) the root of the problem appears to be “very unrealistic notions of what it means to be competent” and says that people “set this internal bar exceedingly high.” When they occasionally fail, these people may adopt negative behaviours such as procrastination and perfectionism. ( … )

The article also presents some interesting solutions. Acknoledging the problem may help, but when you’re under a cognitive bias’ effect^[1], you don’t operate on logic.

The Dunnig-Kruger effect, introduced by IgNobel-winning article “Unskilled and Unaware of It: How Difficulties in Recognizing One’s Own Incompetence Lead to Inflated Self-Assessments” is equally interesting, by stating that

The Dunning–Kruger effect is a cognitive bias in which an unskilled person makes poor decisions and reaches erroneous conclusions, but their incompetence denies them the metacognitive ability to realize their mistakes.[1] The unskilled therefore suffer from illusory superiority, rating their own ability as above average, much higher than it actually is, while the highly skilled underrate their abilities, suffering from illusory inferiority.

Their (Impostor & Dunning-Kruger) corresponding Wikipedia entries are worth reading.

Não há textos relacionados.

My project’s objective is to port Mercurial to py3k ^[1] (Python 3.x), as described in my proposal. Working with the mercurial developers is being a wonderful experience. The most interesting part of the development process is the code review. Every time you want to contribute a change, you submit a patch to the mailing list and a handful of people will start contributing ideas to improve your code so it can, eventually (after some iterations – if it’s not a braindead idea ), be pushed to the main repository. It feels a bit frustrating when those picky people start to complain about your code, but the result tends to be much better than the first versions.

A peculiar aspect of this first half of coding is that I spent more time coding in C than in Python. As some core mercurial modules are implemented in C, I decided that porting them before all others would pay off in the future. Thus, I spent some time adapting the code to build both in Python 2.x and Python 3.x. That part is building fine and working well as far as I am concerned^[2]. Now I’m focusing on implementing some custom fixers for 2to3 to get the python code running in py3k. More about that later…

Being a community-oriented project, we are holding public IRC meetings every Tuesday at 2pm (BRT) at #mercurial in freenode, in case you wanna join us. I am also participating in the mercurial devel and user (not so much in this one) lists.

Textos Relacionados (gerado automaticamente):

1. Summer of code
2. Atualizações vitais

Esse é o mutt

Então, depois de configurar meu ambiente de email, com

• offlineimap para sincronização do backup local de mensagens com os servidores IMAP de meu email;
• vim para edição dos emails;
• msmtp para envio dos emails por SMTP;
• msmtpqueue para manutenção da fila de emails não enviados;
• Truecrypt para cifragem do banco de dados de emails;
• GnuPG para a paranóia básica;
• gnome-keyring como chaveiro com as minhas senhas^[2];
• nmzmail para indexação e busca rápida das minhas mensagens.

Essa configuração funciona muito bem, mas dia desses acabei esbarrando numa página que comparava três indexadores (mairix, nmzmail e maildir-utils) e que dizia que o maildir-utils era a opção do sujeito.

Nunca considerei o mairix pois li em alguns reviews ^{[citation needed]} que o nmzmail possuía mais impressões positivas, mas como não conhecia o maildir-utils (mu), era hora de comparar os dois e ver no que dava. Meu objetivo não era comparar por comparar, mas o nmzmail costumava gastar bastante tempo processando meu banco de dados de email, que consiste de aproximadamente 45000 documentos e quase dois milhões de palavras.

Após instalação do mu, hora de gerar o índice. Como a geração inicial do índice costuma ser custosa, ela não foi usada para comparação. No entanto, após a criação do índice, resolvi fazer algumas novas indexações para comparação de desempenho (há um cronjob que levanta de três em três horas para atualizar o índice, quanto menos tempo, melhor). Enquanto o tempo total de indexação do mu ficou na ordem de cinco segundos em todas as execuções, o nmzmail levou cerca de 50 segundos.

Depois desse resultado, resolvi usar o mu por mais algum tempo para ver se me adapto ao programa. Infelizmente ele não possui uma interface para entrada de consultas (pelo menos eu não vi nenhuma) e a solução do zack não me agradou muito. Por isso, criei o script python abaixo para fazer cache das consultas com readline e facilitar a minha vida.

#!/usr/bin/env python

import atexit
import readline

from os.path import join
from os import environ as env
from subprocess import call

HOME = env['HOME']
INDEXPATH = join(HOME, '.mu', 'results')
MAILDIRPATH = join(HOME, 'Maildir')
HISTORY = '.mailfinder_history'
HISTFILE = join(HOME, HISTORY)

try:
    readline.read_history_file(HISTFILE)
except IOError:
    pass

atexit.register(readline.write_history_file, HISTFILE)

def main():
    query = raw_input('Query: ')
    call(['rm -fr %s' % INDEXPATH], shell = True)
    command = 'mu find -m %s -l %s %s' % (MAILDIRPATH, INDEXPATH, query)
    ret = call([command], env = env, shell = True)

if __name__ == '__main__':
    main()

No mutt, continuo com o meu antigo atalho (S) para para execução das consultas e adicionei outro atalho (F9) para revisitar os resultados da última busca:

macro generic S "mail-finder.pyc~/.mu/results" "Search via mu"
macro index  "~/.mu/results\n" "Display mu find results"

O script de atualização dos índices, por sua vez, ficou assim agora:

#!/bin/sh

mount | grep $MAILDIR &> /dev/null
if [ "$?" == "1" ]; then
    echo "$MAILDIR not mounted. Aborting." > /dev/stderr
    exit 1
fi

exec nice -n 19 /usr/bin/mu index -q -m $MAILDIR

Fim! Legal, né?

PS: O esquema de cores padrão do mutt é meio nojento também. Depois de virar usuário do zenburn, acabei criando um tema equivalente para o mutt, exibido no início deste post.

Textos Relacionados (gerado automaticamente):

1. Frequência de envio de emails

Neste instante e pelos próximos três meses estarei trabalhando no Mercurial, como parte do programa Summer of Code, do Google. O objetivo do meu trabalho é criar uma fundação para permitir que o Mercurial execute no Python 3.

Há alguns dados sobre os estudantes aceitos no blog do Summer of Code. Abaixo, a relação dos top 10 países em número de estudantes aceitos:

Nas próximas semanas uma série de posts, em inglês, envolvendo o trabalho no Mercurial deve aparecer por aqui. Fiquem ligados!

Textos Relacionados (gerado automaticamente):

1. One month and a half in the Summer of Code program
2. Summer of code

Esse era? é o caso da aicore, biblioteca que acompanha o livro Artificial Intelligence for Games^[2] em suas primeira e segunda edição. Apesar do Ian Millington, autor do livro, ter se “esforçado” para fazer o código amigável para outros sistemas, é fato que ele desenvolveu pensando no Windows (e, pior, no compilador do Visual Studio).

No fim de 2009, acabei precisando de uma biblioteca de IA para resolver um problema e decidi portar a aicore para sistemas Unix (para ser sincero, só testei no Mac OS X e no Linux). Conversei com o autor, mas apesar de ter demonstrado interesse, ele jamais aplicou meu patch à árvore principal. Ainda assim, o issue tracker do projeto possui o meu patch e não é difícil aplicá-lo ao código original^[3].

Alguns dos assuntos abordados no livro são^[4]:

• Steering behaviors;
• Pathfinding;
• Decision Making;
• State Machines;
• Fuzzy Logic;
• Waypoints;
• Learning Behaviors;
• Communication;
• Teaching characters.

Conforme descrito na página, para aplicar o patch basta executar o comando:

patch -p0 < /caminho/para/aicore-unix-support.diff

Para compilação, o scons é necessário. Instalá-lo é moleza, supondo que você possui o python instalado (e a maioria das distribuições Linux já vêm com ele). Daí, para compilar a aicore e seus demos, basta executar:

cd /caminho/para/aicore
cd build
scons

E é isso. Os demos são instalados no diretório bin e a biblioteca vai parar no diretório lib.

Textos Relacionados (gerado automaticamente):

1. Página de Inteligência Artificial adicionada ao blog

Sobre o blog, espero que o novo layout possa substituir o antigo, e agora defunto, sirius. Esse tema foi a cara deste blog por alguns anos e espero não ter que brincar de webdesigner pelos próximos dois anos (pelo menos).

Quanto ao conteúdo, nas próximas semanas pretendo publicar guias de como fazer um “clone” de Space Invaders (em C++) e o making-of de nossa animação final da disciplina de computação gráfica.

Não há textos relacionados.

Então, depois de ponderar por um tempo, resolvi abri-lo e fazer uma limpeza geral, pois era impossível que os kernel panics e o superaquecimento fossem normais. Após desmontá-lo (que é mais fácil do que parece) e limpá-lo com um pincel e um aspirador de pó na função de assoprar, percebi uma melhora surpreendente na temperatura média, resumida na tabela abaixo. (Note que não há qualquer rigor científico aqui, mas que melhorou, melhorou .)

Os guias usados foram o vídeo abaixo e o excelente guia do iFixit.

Textos Relacionados (gerado automaticamente):

1. Resolvendo a instabilidade do MacBook – parte 2
2. Resolvendo a instabilidade do MacBook – parte 1

Para minha surpresa, a ventoinha passou a girar menos, o MacBook ficou mais fresco que com o hack anterior e, de quebra, parece que os kernel panics sumiram de vez.

Então fica a dica: Não adianta fazer o reset dessas coisas todas se o firmware está protegido por senha… ^[1]

Textos Relacionados (gerado automaticamente):

1. Resolvendo a instabilidade do MacBook – parte 1
2. Resolvendo a instabilidade do MacBook – final

Kernel panic do Mac OS X

AVISO: Só siga os passos aqui descritos se você souber o que está fazendo. Não me responsabilizo por nada que você fizer. Além disso, parece que o post imediatamente posterior a este apresenta uma solução mais eficiente que a aqui descrita.

(Se você não quiser ler a historinha, pode ir direto para a solução)

Fiquei invocado com a instabilidade e já pensei no pior: “Meu hardware só pode ter ido pro espaço. Vou fazer um teste de memória^[2]!” Rodei o memtest e o teste deu positivo: um dos pentes tinha ido pro espaço. Já pensando no pior, pesquisei preços, mas antes de proceder para a troca dos pentes, limpei as memórias e rodei o memtest novamente. Dessa vez, as memórias passaram no teste! \o/

Voltei a usar o computador e ele até pareceu mais estável… Um pouco antes de outro kernel panic me visitar! Rodei o memtest novamente, estava tudo nos conformes e comecei a desconfiar que havia algum problema crítico no hardware do meu MacBook^[3]. No entanto, no Linux, nunca tive kernel panics gratuitos. Os que aconteceram sempre foram por minha causa. Logo, não parecia que o hardware estava tão ferrado assim.

Como o problema se manifestava mais frequentemente quando eu assistia vídeos no YouTube, resolvi culpar o driver da placa de vídeo e/ou o Adobe Flash^[4]. Cheguei a manipular o driver da placa de vídeo, o que me obrigou a reinstalar o Mac OS X. A parte boa foi que pude comprovar que, mesmo numa instalação nova, o problema persistia (e essa é a parte ruim).

Enfim, coloquei a cabeça para funcionar e percebi que, sempre que os problemas apareciam, a temperatura do processador estava próxima de oitenta e poucos graus e um dos sintomas de que havia possibilidade de kernel panic é que o coreaudiod ficava malucão e o som começa a falhar. Logo, não podia descartar a possibilidade de superaquecimento.

Qualquer Sistema Operacional que dê controle ao usuário permite que ele mude a frequência do processador com alguns poucos cliques (ou comandos). O Mac OS X, não. Pelo menos, não de maneira fácil. Então, resolvi atacar a velocidade do cooler e deixá-lo girando o máximo possível. Instalei o smcFanControl e o FanControl.prefpane sem sucesso. Os problemas continuavam. Até que eu resolvi apelar.

Depois de muito navegar, descobri que um pessoal havia implementado um driver para controle do SpeedStep e que esse driver permitia definir a frequência de operação do processador. No entanto, as instruções do site não são suficientes para colocá-lo para funcionar. Antes de mais nada, baixei o driver^[5] para minha pasta de Downloads e os comandos abaixo a usarão como referência:

cd ~/Downloads
unzip IntelEnhancedSpeedStep_1.4.9.zip
sudo chown -R root:wheel ~/Downloads/IntelEnhancedSpeedStep.kext
sudo chmod -R 755 ~/Downloads/IntelEnhancedSpeedStep.kext

Agora, é importante saber se esse negócio vai funcionar no computador, então, ao invés de já copiá-lo para o diretório de drivers e correr o risco de ficar com um sistema que não funciona, é melhor carregar o driver e testá-lo manualmente. Se o sistema travar, pode esquecer…

sudo kextload ~/Downloads/IntelEnhancedSpeedStep.kext

Ainda funciona? Ótimo! Então podemos deixar o sistema carregá-lo automaticamente na inicialização com os comandos

mv ~/Downloads/IntelEnhancedSpeedStep.kext /System/Library/Extensions
touch /System/Library/Extensions

Perfeito, aqui terminariam as instruções padrão. Só que o Mac OS X possui seu próprio seletor de frequência do processador e, ao menos em meu MacBook, ele interfere com o funcionamento do Intel Enhanced SpeedStep. A solução que encontrei foi desabilitar o AppleIntelCPUPowerManagement, driver padrão do Mac OS X para gerência de energia do processador. Para desabilitá-lo, basta tirá-lo do diretório /System/Library/Extensions e deixá-lo em algum lugar seguro, para backup.

Perfeito. Após um reboot, o driver deve estar carregado e pode ser controlado (sugiro a leitura da página com instruções de como testar o driver) pelo sysctl.

O Intel Enhanced SpeedStep, por padrão, vai funcionar de forma parecida com a do driver da Apple, mas o que eu quero é que o computador fique o menos quente possível. Por isso, meu objetivo é fixar a frequência do processador na menor possível. Há várias formas de fazer isso, escolhi duas: A suave e a agressiva. A suave define que a frequência só deve ser aumentada quando a carga no processador superar 95% (o argumento passado para o kern.cputhrottle_targetload é a porcentagem mínima para variação. 95% é o máximo suportado). Isso já ajuda a deixar o computador relativamente fresco:

sudo sysctl -w  kern.cputhrottle_targetload=95

A agressiva desabilita totalmente a mudança automática da frequência e, portanto, a única forma de mudá-la é manual. Essa foi a alternativa que escolhi:

sudo sysctl -w kern.cputhrottle_auto=0 # desabilita a mudanca automatica de frequencia
sudo sysctl -w kern.cputhrottle_curfreq=1000 # velocidade minima do meu Core2Duo

Infelizmente, o IntelEnhancedSpeedStep parece não salvar as opções entre reboots e, por isso, criei uma entrada para o launchd, com o Lingon, que roda esses comandos na hora do boot (exemplo na figura abaixo).

Configuração do Lingon para criação da entrada do SpeedStep

Depois desse trabalho todo, coloquei o macports para compilar alguns pacotes e fui assistir vídeos no YouTube e não tive nenhum problema. Para verificação, foi só aumentar a frequência do processador que voltei a ter problemas, confirmando minha suspeita de superaquecimento.

Pronto. Problema parcialmente resolvido. Ainda preciso criar coragem para abrir o MacBook para limpar seu interior e, com sorte, melhorar a dissipação do calor. Mas, ao menos, já me livrei dos kernel panics.

Textos Relacionados (gerado automaticamente):

1. Resolvendo a instabilidade do MacBook – parte 2
2. Resolvendo a instabilidade do MacBook – final
3. A Criação de Smaug: O nascimento de uma lenda (Primeira Parte)