Tumulto

Aumento para os magistrados

2011-12-02T18:49:00.001-02:00

Em meio à discussão sobre um aumento para os magistrados, recentemente notícia no jornal Globo, reparei neste comentário favorável ao aumento: apesar de os magistrados ganharem 21 mil reais, o líquido é somente 14 mil reais.

Caros magistrados indignados com seu salário líquido: pagar muito imposto como todo brasileiro não te dá direito a aumento, ok?

Luta entre Bastões

2011-10-19T11:53:00.003-02:00

Me lembrei agora de uma conversa com meus si dai sobre armas brancas, num dia em que eles puderam acompanhar meu jeito de treinar com o kwan.

Um deles, descrente das capacidades do kwan, contou a história de um mestre Fulano que era imbatível com o bastão longo até o dia em que encontrou mestre Siclano, usuário de bastão curto, em uma ponte e perdeu.

Instaurada a controvérsia (?), um outro perguntou: -- Imagine que você põe o bastão curto e o bastão longo para lutar, quem você acha que vence?

Eu esclareço: -- Você está me perguntando o que vai acontecer se eu colocar um bastão curto e um bastão longo, um na frente do outro? -- Sim é isso mesmo.

-- Ora, os dois vão cair no chão e fazer um puta barulho.

Bastões são pedaços de madeira. Artes marciais são estilos e sistemas. Mas quem lutam são os indivíduos.

Novo blog na praça

2011-03-29T15:55:00.000-03:00

Fui convidado a participar de um blog coletivo chamado Coletivo Inconsciente! Decidi que o meu tema para este blog será "a tragédia da vida privada".

Blogger no Android

2011-02-18T09:36:00.001-02:00

Agora que eu tenho uma aplicação para usar o Blogger no Nexus One, talvez consiga atualizar este blog com mais frequência...
Muitos causos ficam esquecidos do trânsito pra casa.

Proíba, e o mercado negro virá

2010-11-26T17:46:00.000-02:00

Qual é o tema do artigo na Wikipedia onde ocorre o seguinte parágrafo? Omissões no texto são propositais para tornar o jogo mais divertido.

"Many social problems have been attributed to the Prohibition era. Mafia groups limited their activities to gambling and theft until ????, when organized bootlegging manifested in response to the effect of Prohibition. A profitable, often violent, black market for ???? flourished. Powerful gangs corrupted law enforcement agencies, leading to racketeering. Stronger ???? surged in popularity because its potency made it more profitable to smuggle."

Uma teoria

2010-11-26T12:58:00.000-02:00

Estava aqui ouvindo pela N-ésima vez a "Back to Black" da Amy Winehouse, que eu comprei em CD recentemente, quando reparei nestes versos:

And life is like a pipe,
and I'm a tiny penny rolling up the walls inside.

Gente.

Será que a Amy Winehouse assistia ao Pica-Pau quando era pequena?

http://www.youtube.com/watch?v=8uvItZ1sPQ4

História para Inspirar

2010-09-04T11:49:00.000-03:00

Pelos idos de 1998, eu e minha irmã assistíamos durante a tarde um bloco especial na programação do Cartoon Network, com alguns anime e outros programas bem interessantes.

Uma tarde, nós vimos uns teasers fantásticos sobre uma garota mágica e umas cartas. Os teasers eram, eles mesmos, muito bem produzidos, e a aura de mistério nos convenceu a agendar a estréia.

Nós assistimos a estréia e ficamos impressionados. CardCaptor Sakura era obviamente um desenho para público infantil mas alguma coisa na personagem principal, e na introdução da história, fez com que agendássemos o horário todos os dias.

E, realmente, todos os dias nós assistimos ao programa. E com o passar do tempo, a natureza da pesonagem principal e dos desafios que aumentavam progressivamente, e a trama que se revelava, nos prendeu ao programa.

Agora, ao contrário de maluquices como Lost, CardCaptor Sakura prometia convenvergência a um desafio final que realmente nos impressionava por dentro, seja pelo modo como a história era contada, seja pelo fato de que os excelentes estúdios da animação japonesa não são de enrolar. E alguma naquelas personagens inspirava você, as emoções simples representadas nas crianças, o otimismo marcante da própria Sakura.

Aconteceu que CardCaptor Sakura nos empolgava, a história que estavamos ouvindo era energizante; em parte por influencia nossa, praticamente todo o nosso grupo de amigos começou a assistir e eu percebi a mesma energia neles. Nós adorávamos acompanhar as aventuras da Sakura e o seu jeito de ser nos contagiava.

Sakura se tornou um modelo de comportamento, talvez. Nós sabemos que um programa para crianças é simplificado, mas exatamente por isso ele se torna um pouco... arquetípico.

Estou contanto essa história porque uma nova história alcançou o lugar ao lado de CardCaptor Sakura nas minhas lembranças.

Eu recomendo fortemente a todos vocês procurar Avatar: The Last Airbender e assistir às três temporadas.

A Infinita Sabedoria do Entretenimento

2010-08-11T23:29:00.000-03:00

O Danilo Gentili está indignado com a decisão do TSE entendendo que sátira política provoca desigualdade entre candidatos em uma eleição.

Eu acho impressionante que ele tenha escrito isso de forma tão clara logo no seu primeiro parágrafo e tenha ignorado por completo o foco da questão em sua longa reclamação.

Danilo, não interessa se o humor é saudável ou se Aristófanes fazia o que queria; por acaso você discorda do fato de que, em um período eleitoral, se nós satirizamos um candidato o outro candidato se beneficia?

Vou assumir que você, apesar de tudo, concorda que satirizar uma pessoa diminua a sua imagem e que, durante um processo eleitoral, este fato é relevante.

Então, Danilo, preciso perguntar a você se por acaso você acredita que sua condição de humorista lhe empresta uma sabedoria sobrenatural para injetar na rede de forças e poderes da sociedade a medida justa de sátira entre todos os candidatos.

Preciso saber se você e seus colegas humoristas são sábios o suficiente para satirizar apenas e tão somente o necessário de modo a evitar o efeito colateral que é a ridicularização de um candidato que está competindo com outros.

Será que você é iluminado o suficiente para não ter preferências durante uma eleição? Satirizar com mais intensidade candidatos em quem não pretende votar?

Entenda, Danilo, que eu acho muita graça na sátira política.

Mas eu não acho graça nenhuma nessa atitude de superioridade misteriosa de que se revestem pessoas cuja missão é entreter em matéria do governo da sociedade.

O TSE tem uma responsabilidade em um país cujo processo eleitoral está longe de funcionar razoavelmente -- sendo que apenas este ano estamos vendo vigorar uma lei tal qual a Lei da Ficha Limpa.

Faça-nos o favor de exercer a sua influência de forma madura no debate sobre o que é ou não é favorável à democracia durante esses poucos meses.

O macete é chamar de censura; daí você tem sempre razao.

Tumulto de casamento

2010-05-24T21:11:00.002-03:00

O tumulto está quase no fim!

Fizemos neste fim de semana uma festa para a família e deu tudo certo, com um buffet de crepes e bastante cerveja.

Em Junho faremos a festa para os amigos, poderemos fechar a lista de presentes de casamento e preencher a sala com coisas que não sejam caixas de papelão.

o fim do software ... neste blog

2010-05-10T21:24:00.000-03:00

A partir de hoje, escreverei artigos sobre software em outro blog. Este aqui voltará então à sua programação normal de pensamentos filosóficos esporádicos e comentários idiotas sobre o dia a dia.

Web Services infinitamente fáceis com JAX-WS

2010-05-10T20:47:00.000-03:00

Isso provavelmente é notícia antiga para os praticantes do J2EE, mas hoje eu aprendi a notação mais básica do JAX-WS e estou impressionado com o esquema em geral.

Eu experimentei um pouco com o esquema do Apache Axis e, apesar de fácil, me fez um pouco perdido por não dominar ainda o macete dos arquivos de configuração e dos artefatos gerados.

Fora isso, eu não vi, no tanto que estudei, o meio de trocar argumentos de um tipo não primitivo com o Axis, o que me deixou um pouco ressabiado -- ou é difícil, ou é impossível.

Agora, com o Metro no GlassFish?

@WebService
public class Echo {
    public String echo (String value) { return value; }
}

Está pronto o EchoService.

Empacotando este negócio em um "Dynamic Web Project" e implantando no GlassFish, o Metro descobre sozinho a existência da classe Echo e configura automaticamente um EchoService muito razoável.

Eu achei, originalmente, que era preciso instalar a ferramenta Apache CXF na incubadora do projeto Eclipse Web Tools mas é desnecessário.

Aparentemente, a engenharia da norma JAX-WS foi muito boa, e existe também uma JAX-B que especifica a tradução de "java" para "xsd" de um modo que o seguinte também funciona como esperado:

public class Bar {
    public String data;
    Bar (String data) { this.data = data; }
}

@WebService
public class Echo {
    public Bar echo (String value) { return new Bar(value); }
}

É tudo o que eu preciso pra passar de fase.

GlassFish em servidor Fedora 11

2010-04-24T18:01:00.000-03:00

Consegui, afinal, configurar um servidor Fedora 11 com o GlassFish instalado.

Estou usando o seguinte script em /etc/init.d para gerenciar o serviço no sistema.

#!/bin/sh
#
# glassfish Sun GlassFish v3
#
# chkconfig:   - 99 1
# description: Sun's modern J2EE implementation based on OSGi

### BEGIN INIT INFO
# Provides: glassfish
# Required-Start: $network
# Required-Stop: $network
# Short-Description: J2EE implementation
# Description: Sun's modern J2EE implementation based on OSGi
### END INIT INFO

# Source function library.
. /etc/rc.d/init.d/functions

exec="/opt/glassfishv3/glassfish/bin/asadmin"
prog="glassfish"
config="/opt/glassfishv3/glassfish/domains/domain1/config/domain.xml"

[ -e /etc/sysconfig/$prog ] && . /etc/sysconfig/$prog

lockfile=/var/lock/subsys/$prog

start() {
    [ -x $exec ] || exit 5
    [ -f $config ] || exit 6
    echo -n $"Starting $prog: "
    ${exec} start-domain domain1 >/dev/null 2>&1
    retval=$?
    [ $retval -eq 0 ] && success $"$prog startup" || failure $"$prog startup"
    echo
    [ $retval -eq 0 ] && touch $lockfile
    return $retval
}

stop() {
    echo -n $"Stopping $prog: "
    ${exec} stop-domain >/dev/null 2>&1
    retval=$?
    [ $retval -eq 0 ] && success $"$prog shutdown" || failure $"$prog shutdown"
    echo
    [ $retval -eq 0 ] && rm -f $lockfile
    return $retval
}

restart() {
    stop
    start
}

reload() {
    restart
}

force_reload() {
    restart
}

rh_status() {
    ${exec} uptime
    uptime_retval=$?
    if [ $uptime_retval -eq 0 ]; then
        return 0
    fi
    if [ -z $lockfile ]; then
        return 2
    fi
    return 3
}

rh_status_q() {
    rh_status >/dev/null 2>&1
}

case "$1" in
    start)
        rh_status_q && exit 0
        $1
        ;;
    stop)
        rh_status_q || exit 0
        $1
        ;;
    restart)
        $1
        ;;
    reload)
        rh_status_q || exit 7
        $1
        ;;
    force-reload)
        force_reload
        ;;
    status)
        rh_status
        ;;
    condrestart|try-restart)
        rh_status_q || exit 0
        restart
        ;;
    *)
        echo $"Usage: $0 {start|stop|status|restart|condrestart|try-restart|reload|force-reload}"
        exit 2
esac
exit $?

Algoritmos da Amazon

2010-04-07T00:41:00.002-03:00

"As someone who has purchased or rated books by Erich Gamma, you might like to know that How You Could Be A Better Friend is now available."

(...)

Amazon, Erich Gamma é autor de um livro sobre engenharia de software. Que porra é essa?

O estilo funcional em C++

2010-03-31T01:14:00.002-03:00

Estava de mau humor e resolvi ironizar a vida estudando numa aula de Java o artigo "Why Functional Programming Matters", que eu copiei do site do Haskell.

Acabei finalmente entendendo (eu acho!) as primeiras implicações importantes de lazy evaluation. O exemplo mais simples dessas implicações no artigo, na minha opinião, está no programa que computa aproximações da raiz quadrada pelo método de Newton-Raphson.

Esse método é basicamente uma expressão matemática que começa com um resultado anterior e usa esse resultado para computar um próximo, garantindo que o próximo é melhor que o anterior.

Seja N o número cuja raiz quadrada você deseja aproximar, e uma aproximação anterior x. O procedimento começa chutando x, por exemplo 1. O método afirma que o próximo x deve ser ( x + ( N / x ) / 2 .

O artigo descreve um programa para resolver o método. O programa segue abaixo; para entendê-lo completamente, estude o artigo.

repeat f a = cons a ( repeat f ( f a ) )

within e ( cons a ( cons b rest ) ) =

  = b , if abs(a - b) <= eps

  = within e ( cons b rest), otherwise

next N x = ( x + N / x ) / 2

sqrt a0 e N = within e ( repeat ( next N ) a0 )

O espírito geral do programa é assim:

repeat é uma função que gera uma lista contendo um elemento inicial seguido do resultado da função f com argumento elemento-anterior. Observe que repeat gera uma lista infinita, assumindo que f está definida para todo a.

within é uma função que percorre uma lista procurando um par de elementos cuja diferença seja menor que um epsilon.

A notação de parâmetros em within faz o que eu chamo de "desempacotar a lista". O segundo argumento é uma lista; a definição de within desempacota os dois primeiros, chamando-os de a e b.

next computa a próxima aproximação da raiz quadrada de N com aproximação anterior x segundo o método de Newton-Raphson.

sqrt computa a raiz quadrada de um número conforme uma tolerância e e um chute inicial a0; sua definição aplica within a repeat, e repeat a next.

sqrt basicamente avalia within à lista gerada por repeat , e repeat gera a lista de resultados de next.

Este programa, segundo a intuição de um programador acostumado a linguagens imperativas, nunca termina, porque repeat nunca termina de gerar a lista infinita.

Porém, lazy evaluation garante que esse programa termina -- garante que repeat será avaliado apenas o número de vezes necessária para que within se satisfaça. Eu entendo que o segredo disso está no momento em que o interpretador avalia o "desempacotamento" de uma lista, porque este é o momento em que o processamento exige a geração de mais um elemento.

Isso é mesmo sensacional. Como seriam esses pequenos componentes em C++0x?

Vamos começar brincando com uma versão muito eficiente de abs, o que não tem nada a ver com o problema em questão.

template
auto abs (Number x) -> typename std::enable_if< std::is_signed::value, Number>::type
{
return x < 0 ? -x : x ;
}

template
auto abs (Number x) -> typename std::enable_if< ! std::is_signed::value, Number>::type
{
return x;
}

A notação acima é a nova notação para funções em C++0x, onde a especificação do retorno fica depois da lista de argumentos.

A definição de abs faz uso de SFINAE para sobrecarregar dois templates, de outro modo indistinguíveis, usando std::enable_if.

Assim, abs pode se reduzir a nada quando nem mesmo faz sentido que o número possua um sinal.

Em seguida, vamos chamar as listas de Range e declarar a forma geral de uma função unpack.

template
auto unpack (Range& r) -> Value;

template
auto unpack (Sequence& s) -> decltype(s.front())
{
typename Sequence::value_type v = s.front();
s.pop_front();
return v;
}

Definimos o significado de unpack providenciando uma sobrecarga, exclusiva para Containers da STL, que faz o que deve fazer. Em português, unpack resulta o elemento à esquerda e modifica a lista para conter o resto.

Assim, definimos within:

namespace detail
{

  template 
  auto within (Number eps, Number a, Number b, Range rest) -> Number
  {
    if (abs(a - b) <= eps) return b;
    else {
      const Number c = unpack(rest);
      return within(eps, b, c, rest);
    }
  }

}

template 
// requires(ValueType(Range) == Number)
auto within (Number eps, Range list) -> Number
{
  const Number a = unpack(list);
  const Number b = unpack(list);
  return detail::within(eps, a, b, list);
}

within desempacota a e b e delega para uma subrotina; a subrotina faz o que se espera. Observe que a lista a processar é um desses tais Ranges.

O componente equivalente a repeat deve gerar esse Range.

namespace detail
{
template
struct repeat_range
{
    Function f;
    Value x;

    auto operator() () -> decltype(f(x))
    {
      return x = f(x);
    }
};

template
auto unpack (repeat_range& r) -> decltype(r())
{
    return r();
}
}

template
// requires(UnaryFunction(Function) && Domain(Function) == Value)
auto repeat (Function f, Value a) -> detail::repeat_range
{
return detail::repeat_range { f, a };
}

Um Range é um objeto especial, que representa a lista; definimos um repeat_range que continuamente aplica uma função, e definimos unpack para este Range. (Observe como repeat_range usa o último valor gerado na geração do próximo.)
A função repeat é utilitária e constrói o Range com os argumentos certos.

A notação de construção usada na definição de repeat também é nova, e generaliza a inicialização entre structs C e objetos C++.

Por último, implementamos a função importante para a aplicação, sqrt. Escolhi ocultar o equivalente a next porque a mim não interessa muito.

namespace detail
{
template
auto sqrt (Number N, Number x) -> Number
{
    return (x + (N / x)) / 2;
}
}

template
auto sqrt (Number N, Number x, Number eps) -> Number
{
return
    within(eps,
      repeat(
        [=] (Number x) { return detail::sqrt(N, x); },
        x
      )
    );
}

Agora, isso é punk. A função no detail computa a próxima aproximação é trivial. O driver principal, por outro lado, é complexo.

Em primeiro lugar, aquela notação esquisita ali é uma expressão lambda. Para todos os efeitos, a avaliação desta expressão produz uma função, que vira argumento para repeat.

repeat, portanto, aplicará uma função lambda -- que por sua vez computa a próxima aproximação da raiz de N com chute x -- ao valor inicial x. O símbolo [=] significa que os nomes dentro do lambda se tornam cópias por valor dos objetos de mesmo nome no escopo maior.

repeat, como vimos antes, produz um Range, sobre o qual within opera. E within procura um par de valores neste Range -- aplicando unpack quando necessário -- em busca de um par cuja diferença seja menor que eps.

Assim, nesmo programa C++, simulamos com significativo esforço a lazy evaluation funcional, para computar a raiz quadrada. Usando __attribute__((const)) esse programa deve otimizar até o Nirvana, mas eu não verifiquei.

O programa esparramado no texto acima funciona de verdade com o GCC 4.5 e provavelmente funciona também com o ICC 11.1.

Interface Programador-Máquina

2010-03-18T21:08:00.001-03:00

Ouvi algo interessante em uma aula do curso 6.00 do MIT, vendo o vídeo no celular, sobre a sobrecarga de operadores; o professor argumentava que essa era uma carecterística boa da linguagem de programação porque permitia uma interface consistente de programação.

Esse é um uso interessante das palavras; em geral, dizemos interface para nos referir a um contrato de comunicação entre dois pedaços de código executável.

Realmente, da mesma forma como essa representação é um contrato ou protocolo entre dois pedaços de código executável que se comunicam, também há contrato ou protocolo entre quaisquer duas coisas que se comunicam, como por exemplo o programador e a máquina.

Isso nos leva a pensar na linguagem de programação, como regra de sintaxe e semântica, como uma interface; e em pensar na qualidade de uma linguagem de programação como a qualidade dessa interface.

O meta-caso-de-uso que essa interface pretende realizar é "expressar o programa que eu tenho em mente"; o componente que implementa essa interface é o compilador. Realmente é o compilador, e não a máquina física; o compilador, sob essa ótica, é a máquina abstrata, que interpreta a expressão do programa e faz algo de útil. De fato, normas como C e C++ descrevem o efeito do programa sobre uma máquina abstrata.

Então, o que há com y + x ?

Há interface de alta qualidade na medida em que + significa o que você aprendeu ao longo de uma década de ensino de aritmética. Este julgamento fundamenta ambos os lados da divergência sobre se este símbolo deve ou deve não ser sobrecarregado para significar "concatenar duas strings". O lado deve entende que qualquer indivíduo compreende + como "juntar", "unir", "somar". O lado deve não entende que concatenar é "pôr um na frente do outro", que não possui a propriedade de associatividade.

O tema da aula no vídeo que eu estava assistindo era classes em Python e uma introdução aos abstract data types. Acho essa discussão pertinente porque ADTs são um conceito de meta-linguagem, e um ADT existe apenas na mente do programador. Faço essa distinção como a distinção entre o conjunto dos inteiros de que trata a álgebra e o tipo int da linguagem de programação.

Quando o programador representa um ADT na linguagem de programação como uma classe, ele por sua vez oferece a outro programador uma interface de programação. O usuário do ADT, por assim dizer, escreverá programas que dissertam sobre esse ou aquele valor. Assim, eu concordo com o professor: se eu estou descrevendo um ADT numérico, é muito conveniente poder sobrecarregar o símbolo + e permitir aos meus usuários falar sobre coisas na forma de y + x .

Agora, há algo de estético nessa história toda. Suponha que por qualquer motivo você não pode usar o símbolo + . Que nome você escolheria, add ou sum? Ou plus? add tem algo de imperativo, enquanto sum é um substantivo; ambos sugerem uma leitura diferente da expressão; e plus é apenas o nome de um símbolo!

add(y, x) // add y to x

sum(y, x) // the sum of y and x

plus(y, x) // y plus x

O Elements of Programming argumenta que o projetista de um ADT deve se esforçar para determinar uma "base computacional" para o ADT, um conjunto mínimo de operações básicas e eficientes que permitem ao programador expressar todos os programas úteis possíveis que discursam sobre seus valores.

Este é o aspecto aritmético de uma interface programador-máquina, por assim dizer; uma boa escolha de nomes é seu aspecto estético, talvez. Parte do processo de decifragem ou aprendizagem de um sistema -- rotina de um arqueólogo de sistemas legados -- é justamente aprender os símbolos na caótica cultura desse sistema, que podem ou não fazer sentido como se espera de um sistema "fresquinho".

Parte do esforço hercúleo em se convencer de um teorema de matemática avançada é justamente ler a notação simbólica usada -- que, sendo altamente abstrata, é frequentemente irreprodutível em linguagem natural. (E às vezes a diferença entre um signo e outro é meia dúzia de três ou quatro pixel.)

Produzir uma interface programador-máquina eficiente é sempre bom, mas programadores em execesso usam a eficiência como desculpa para produzir interfaces incompreensíveis. E no fim das contas todos nós sabemos que o custo de um projeto de sistema convencional é dominado por seu custo de manutenção.

Problema os ícones especiais do Nautilus

2010-03-09T00:02:00.000-03:00

Não sei por que cargas d'água o ícone especial da pasta "Vídeos" na minha pasta de usuário no Nautilus perdeu a graça.

O Nautilus, para pastas especiais como "Imagens", "Música" etc. usa ícones especiais com umas figuras bem legais, como um trecho de rolo de filme pro "Vídeos".

Depois de muito procurar, percebi que o responsável pelo tema dos ícones usava alguma fonte de informação pra decidir quais pastas são especiais e aplicar ícones especiais -- ou não aplicar, de acordo com o tema.

Depois de procurar ainda mais, descobri esta fonte de informação no Fedora 12:

$HOME/.config/user-dirs.dirs

Realmente a linha de configuração para a pasta de vídeos estava com o nome errado.

Instalando o J2EE da Sun no Fedora 11

2010-02-25T23:22:00.000-03:00

Dois pequenos probleminhas.

Em primeiro lugar, o instalador reclama dizendo "Expression NOME_DO_PRODUTO is undefined on line 86, column 289 in /templates/components.ftl."

O problema é o código de localização; execute o instalador com LANG=C e pronto.

Em segundo lugar, eu uso um hostname personalizado meus sistemas -- este aqui se chama elisa. Nunca me dei ao trabalho de colocar o nome no /etc/hosts porque o mDNS funciona muito bem sem isso.

O instalador não gosta dessa situação e reclama em uma caixa de diálogo sobre "host name invalid".

Já estou usando esse esquema em outro lugar -- GlassFish J2EE 6 com Eclipse Galileo no Fedora 11 -- e funciona muito bem.

Teste do Buzz

2010-02-10T11:36:00.001-02:00

Teste. Será que vai aparecer no Buzz?

Aniversário!

2010-01-26T15:26:00.002-02:00

Dia 31 na Drinkeria Maldita!

Funções/Objetos

2010-01-26T14:14:00.000-02:00

Hoje vi em uma base de código-fonte uma função cujo nome é "signalCatcher" -- um substantivo. A regra geral de estilo é: dados são chamados por substantivos, funções por verbos no infinitivo.

Mas faz sentido que "signalCatcher" seja o nome daquilo que você vai entregar ao mecanismo de sinais para tratar os sinais da aplicação, certo?

Eu acredito que a linguagem de programação do futuro não deve fazer distinção entre objetos-dados e objetos-função, mesmo sintaticamente; ambos ocupam espaço na memória e portanto exigem alocação, e são mencionados através de referências.

Em C, todas as funções são efetivamente objetos imutáveis, mas houve o tempo em que funções não eram imutáveis; esse tempo poderia voltar. E apesar de a maioria dos objetos ser mutável, alguns objetos são propositalmente imutáveis, e seus projetistas procuram maneiras de armazená-los em ROM.

Uma função deve ser um objeto cujo tipo é função, um tipo genérico variando na lista de parâmetros e na lista de resultados. O valor de um objeto do tipo função deve ser interpretado como uma sequência de instruções para o processador alvo, organizada de acordo com uma convenção de chamada apropriada. Esta convenção apóia a operação fundamental que o programa realiza sobre o objeto, chamar.

É claro que, ainda assim, uma função é um objeto bem especial. Em particular porque não é um objeto cujo tamanho é regular -- não se pode saber qual é o tamanho de um objeto função apenas conhecendo seu tipo.

Procurando apartamento!

2010-01-13T15:43:00.000-02:00

Estou procurando apartamento no Rio de Janeiro.
Se souber de algo, avise!

Programação e Semiótica 7

2010-01-13T14:17:00.000-02:00

Um novo exemplo para diminuir o tédio dos leitores e usar esses conceitos para entender o processamento de texto nos computadores.

Falemos sobre um programa que, por sua vez, deseja falar sobre textos em linguagem natural. Este programa fará referência a objetos cujo interpretante é "texto em linguagem de gente".

O que é texto em linguagem de gente? É uma sequência de símbolos que os seres humanos são capazes de entender como caracteres do seu idioma, que por sua vez se agrupam para formar palavras, frases etc. Nos idiomas latinos dizemos que as letras se agrupam para formar palavras; em idiomas como o japonês muitas vezes apenas um caracteres já é uma palavra inteira.

Mas o computador não sabe nada sobre caracteres, apenas sobre números. Com certeza o computador é capaz de representar na memória números uns na frente dos outros.

A intuição fundamental é a possibilidade de estabelecer um mapa de caracteres onde cada caractere está mapeado para um número e vice-versa. Formalmente, o mapa é uma função bijetora entre os conjuntos "números inteiros" e "caracteres".

Assim, um programa processador de texto faz referência a objetos cujo primeiro tipo é "número inteiro" e cujo segundo tipo é "caractere do mapa tal".

Suponha o seguinte mapa: a = 1, b = 2, c = 3 etc. O texto "abc" seria um objeto composto por três objetos numéricos contíguos 123.

Como poderia um programa colocar palavras em ordem alfabética? Toma dois objetos "palavra" e compara os dois caracteres iniciais como números; se forem diferentes, a ordem é numérica; se forem iguais fazemos a mesma coisa com o segundo caractere e assim por diante. Essa é a ordenação lexicográfica.

Esse esquema é interessante quando podemos usar um objeto de tamanho fixo e tipo "número" para todos os caracteres desejados. Mas com o advento da Internet e a interligação entre sistemas de todo o mundo se tornou inviável usar mapas de caracteres pequenos.

O que acontece quando um sistema do Japão envia 123 para um sistema do Brasil? Que mapa de caracteres o sistema do Brasil deve tomar como interpretante desses números? Essa dificuldade é a causa de muitos fenômenos bizarros na Internet, onde páginas mostram um monte de lixo onde deveriam estar caracteres latinos acentuados ou coisa parecida.

A primeira lição da interligação de sistemas processadores de texto é que não existe objeto "texto" compreensível sem um interpretante "mapa de caracteres" associado. Essa associação é um problema que sempre deve ser resolvido, mesmo que a solução seja um contrato entre todas as partes definindo um e apenas um mapa válido. Esse tipo de contrato não se mostrou viável a longo prazo.

Alguns sistemas de programação experimentaram construir tipos mais complexos para objetos; não apenas "texto" mas "texto ASCII" ou "texto ISO-8859-1" -- embutindo no tipo do objeto também o tipo do mapa de caracteres. Isso é interessante para apoiar contratos como o anterior, mas um pouco estranho quando o sistema deve aceitar diversos tipos de texto de diversas partes do mundo.

Estas parecem as coisas básicas que sempre queremos fazer com texto: contar o número de caracteres, decidir se dois textos são iguais, decidir qual de dois textos deve aparecer antes na ordem do dicionário, e inspecionar o texto letra por letra (para imprimir na tela, por exemplo). Com os mapas numéricos simples, podemos fazer todas essas coisas simplesmente trabalhando com pares de números: os primeiros de cada texto, depois os segundos de cada texto, etc.

Nesses mapas, existe uma referência sensata que atravessa a representação dos objetos da mais pura -- os números -- para a mais abstrata -- o caractere do texto.

Essa facilidade eventualmente terminou, o que ainda parece muito traumático para programadores acostumados com essa situação tão segura.

Eventualmente a comunidade internacional decidiu dar um basta na multiplicidade dos mapas e resolveu produzir o super-mapa Unicode. Este mapa é um catálogo de praticamente todos os caracteres usados na galáxia, associados cada um deles a um número inteiro positivo. Infelizmente, são muitos caracteres, que não podem ser representados com números pequenos.

A princípio, os indivíduos decidiram usar números grandes e manter o esquema de mapa com objetos de tamanho fixo. Assim, o processamento par-a-par continuaria possível. Mas os objetos texto explodiram de tamanho e essa esquema se mostrou inviável.

Então um compromisso foi firmado: um novo mapa foi produzido para o Unicode onde quase 90% dos textos continuaria com o mesmo tamanho, e apenas 10% seria maior. Este mapa às vezes usa um número por caracteres, às vezes dois, às vezes três e às vezes quatro. Este simples fato é o pesadelo dos programadores novatos de processamento de texto.

Por que este mapa UTF-8 possui uma representação tão estranha com objetos caractere de tamanho variável, deixou de ser sensata a referência direta número-a-caractere. Um sistema que recebe 1234 3456 5678 e deve interpretar esses números como texto deve não mais assumir que o primeiro número é um caractere, e o segundo um caractere etc. É possível que na realidade os dois primeros números sejam um caractere juntos.

Uma sequência de números que deve ser interpretada como UTF-8 não pode mais ser percorrida ingenuamente número a número, e os algoritmos de processamento baseados em comparações par-a-par estão quebrados. Isso, novamente, se deve ao fato de que UTF-8 viola propositalmente premissas simples de significação dos números que compõe um texto.

Isso foi um problema grave porque programas antigos despreocupadamente tratavam seu texto de forma crua, diretamente com os números, confortados pelas premissas do processamento de texto -- ao invés de fazer isso com funções especiais em módulos de processamento de texto.

Quando o significado dos números foi alterado nos processos de substituição de mapa por mapa, consertar esses programas foi tarefa infernal. Os programas com funções especiais de tratamento de texto modificaram apenas estas funções e foram livrados deste mal.

Esta vitória do encapsulamento pode ser compreendida pelo encapsulamento de uma função sígnica -- a compreensão dos signos-número como signos-letra encapsulada em certos entes responsáveis, e uma transformação cultural pôde ser efetivada apenas instruindo estes entes responsáveis, e não todos os entes.

No final das contas o problema se tornou tão bem resolvido que surgiu um componente tão reusável que surge por toda parte, a libiconv.

Programação e Semiótica 6

2010-01-12T13:37:00.000-02:00

Entender o texto de um programa sob a ótica da semiótica é um pouco mais fácil do que entender outros tipos de texto porque o limiar de realidade do programa está bem delineado e bem próximo: a máquina.

Por essa razão, não é preciso uma poderosa metafísica para entender o que é um objeto, mesmo que este esteja, para o programa escrito, totalmente oculto.

Bolei o seguinte diagrama para descrever as três propriedades fundamentais de um objeto segundo as regras da máquina.

Estas três propriedades são a "base" de um objeto e o determinam completamente; seu estado ou padrão de bits, seu local ou endereço, seu tamanho ou comprimento em bytes.

Local e tamanho são propriedades espaciais, sendo a memória um universo unidimensional. Falamos sobre onde um objeto está, e ao longo de que comprimento. Estado é uma propriedade temporal, e (potencialmente) muda a cada instante. Falamos sobre qual é o estado de um objeto (agora).

Mas eu venho insistindo que o programa escrito em linguagem de alto nível nada sabe sobre objetos, exceto aquilo que pode falar sobre eles através de referências, e tentando aplicar a nomenclatura da semiótica para dizer isso.

Bolei o seguinte diagrama para relacionar os três conceitos que eu estou tentando usar, que envolvem toda expressão no programa escrito sobre objetos.

Uma expressão em um programa escrito como "y = x + x" possui, além dos elementos sintáticos = e + os nomes y e x; estes nomes são tradicionalmente chamados variáveis e eu os estou chamando aqui de referências. Esses nomes significam objetos por intermédio de um tipo (que eu acredito ser equivalente ao interpretante.)

Linguagens como C++ prendem referência e tipo através da sintaxe; a ferramenta que interpreta o programa sempre sabe qual é o tipo associado a um nome como x. Linguagens como Javascript não prendem referência e tipo dessa forma, de modo que a ferramenta deve sempre considerar o contexto de uma expressão para inferir um tipo para x.

A vantagem do C++ (e similares) é a possibilidade de se apoiar em uma ferramenta para evitar que uma referência absurda seja formada e usada; linguagens como essa permitem a dedução da validade semântica a partir da validade sintática. Este é o sonho da análise estática de programas: descobrir erros no significado a partir do (uso da) sintaxe.

No seguinte exemplo em C++:

complex c1 = { 1.0, 1.0 };

c1 é uma referência cujo interpretante estático é "número complexo". Conhecendo os segredos deste interpretante, poderíamos compreender o resto do texto, o próprio objeto, como o número complexo 1 + i.

A vantagem do Javascript (e similares) é a possibilidade de se expressar
sobre objetos através de múltiplos tipos viáveis de acordo com a conveniência; linguagens como essa simplificam a validade sintática para aumentar as opções de validade semântica.

No seguinte exemplo em Javascript:

nome = "Pedro Lamarão";

nome é uma referência sem interpretante estático. Conhecendo os segredos da sintaxe da linguagem, saberíamos que aspas duplas implicam o interpretante "texto", e portanto nome significa o meu nome.

Independentemente de onde o leitor obtém um tipo-interpretante para uma variável-referência, é através deste que o objeto-estado possuirá uma conotação -- um significado imediato. Os três tipos fundamentais em máquinas contemporâneas são o inteiro-sem-sinal, o inteiro-com-sinal e o ponto-flutuante.

Programas do mundo real, porém, estão muito interessados em coisas como letras, textos, nomes de pessoas e lugares, valores em moeda local, fotos etc. Diversos programas precisam impor significados adicionais a objetos fundamentalmente aritméticos para serem úteis.

Essa necessidade nos leva naturalmente a pensar em objetos compostos por objetos simples e sobre a diferença conceitual entre um objeto na máquina concreta e um valor em um conjunto abstrato. Certos programas dirão que um certo objeto possui o valor "Pedro Lamarão" -- mesmo sabendo que a máquina fundamentalmente só compreende números.

O relacionamento entre as idéias objeto e valor, e a idéia de composição de objetos, torna o processo semiótico de um programa muito mais rico, interessante e passível de absurdos -- onde nem sempre se consegue responder com facilidade a perguntas simples como "x é igual a y?"

Semiótica e Programação 5

2010-01-07T10:51:00.002-02:00

Agora, para um pensamento menos entediante.

Considere que autenticação é o processo pelo qual um sujeito se convence que um certo signo de fato significa um certo objeto -- uma certa credencial de fato significa um certo indivíduo, por exemplo.

Quando você ouve a campainha e alguém dizer "Olá" e pensa "Deve ser fulano" você autentica o signo vocal para se convencer ainda mais usando o olho mágico.

O método de autenticação em sistemas de informação com a interação mais simples é a checagem de um segredo compartilhado. O sistema conhece um segredo para um username e assume que se alguém apresentar o username e o segredo, então deve ser o significado daquele username.

O programa em execução, após executar essa interação com sucesso, construirá um objeto na memória, e manterá uma referência para ele cujo significado ulterior é username-do-usuário. Já que a autenticação foi bem sucedida, o programa confiará até terminar que esta referência é adequada, e poderá usá-la para julgar se deve ou deve não permitir o usuário a abrir certos arquivos etc.

Esta confiança no significado daquela referência é perfeitamente adequada para programas convencionais: a memória de um programa convencional em um sistema convencional é exclusiva, de modo que ele pode facilmente se convencer de que o objeto referenciado é íntegro.

Às vezes programadores movem para sistemas diferentes onde as regras são diferentes, e esse tipo de expectativa implícita é violada com consequências drásticas.

O jovem programador que move sua atividade para a web pode escrever um site em script que autentica o usuário e guarda o username em um objeto da sessão. O programa subjacente então continuamente fará certa referência a este objeto para tomar decisões de segurança, afinal, esta referência está para o objeto certo, não é?

Porém, neste ambiente, o programador não pode assumir a integridade do objeto -- não ingenuamente, como eu assumi acima. Como a web é um sistema bem distribuído e como o browser acessa o site um arquivo por vez, sem qualquer continuidade, este objeto ao qual o script faz referência não está sob seu controle. Ele existe em uma memória distante, fora do seu controle.

Fora do seu controle significa sob controle de um outro agente: o cliente. Suponha então que eu faça um acesso a uma página restrita e posicione arbitrariamente um objeto com o username de outra pessoa justamente no local onde a referência do programa assume que ele esteja. Assim, eu posso mentir ao programa sobre quem eu sou, me valendo de uma ingenuidade no significado do programa.

Perceber esse furo de segurança no site pode ser difícil porque o texto do programa do site pode adequadamente obter o username e compará-lo com regras de autorização em todos os lugares. O problema aqui é semanticamente anterior a esta comparação: o problema está na premissa de que uma certa referência está de fato para um objeto com o significado esperado.

Assim, os defeitos nos processos de autenticação em sistemas de informação são compreensíveis sob a ótica de uma função sígnica com "defeito" -- uma oportunidade através da qual o par em uma conversação tem condições de mentir. Concretamente, esse defeito existe no programa na forma de uma confiança indevida sobre o objeto de uma referência.

Semiótica e Programação 4

2010-01-06T11:29:00.000-02:00

O padrão Proxy ocorre sempre que um objeto no sistema existe como substituto de outro objeto, por alguma razão. Em um sistema distribuído entre muitos computadores físicos, um objeto local pode ser substituto de um objeto que está em outro computador, ocultando o mecanismo de comunicação entre computadores.

O objeto proxy, de um modo ou de outro, possuirá uma referência ao objeto proxied; e o programa que possui uma referência ao objeto proxy possuirá uma referência ao objeto proxied.

Esses múltiplos níveis de indireção trazem problema para a expressão e compreensão do programa devido a frequente ausência de interpretantes para humanos -- também conhecidos como documentação.

Considere um objeto whatever que é um proxy para um objeto em um computador central, e uma rotina com essa aparência:

   get_name (whatever) -> (s1)
   ; s1 is the name of whatever

Um programa chama get_name e obtém uma referência ao objeto "nome" de um outro objeto qualquer.

Agora, resta a pergunta: se o programa que eu estou rodando modificar o valor de s1, o que acontece com whatever? Se Fulana rodar o mesmo programa depois que eu, que valor de s1 ela vai obter? s1 é uma referência para uma cópia ou é uma referência para o original?

Essa diferença é importante por razões que não apenas as consequências de modificar o objeto. A memória do computador é finita e portanto os programas devem cuidar de destruir os objetos que já acabaram de usar. Mas o que o programa que usa get_name deve fazer com o objeto referenciado por s1? Ele deve destruí-lo? Ele pode destruí-lo? Com certeza ele não pode destruir um objeto que está referenciado por diversos outros programas.

Por que (alguns) programas devem cuidar da presença dos objetos na memória, e dar manutenção nessa memória, existe sempre o problema de dispor de espaço para objetos ocuparem e por quanto tempo. Quando um programa faz algo como:

   string s4 = "Marcelinho"

a expressão de que "existe um s4 que é um texto" é interpretada implicitamente como "precisamos arranjar espaço para um texto pelo tempo necessário".

Quando o programa lida com objetos que foram criados por ele mesmo e são locais, o uso do espaço e do tempo é óbvio porque explícito; referências a objetos ocultos demandam maiores explicações.

As referências indiretas como os objetos proxies levam o problema além quando tornam possível que uma referência seja absurda -- uma referência a nenhum-objeto. Há programas onde faz sentido uma referência a nenhum-objeto e há programas onde isso não faz sentido. O programador deve deixar isso sempre claro sob pena de não ser compreendido.

Documentação é a única solução geral na medida em que linguagens de programação em geral não oferecem mecanismos sintáticos para se especificar esses atributos de uma referência.

Nem mesmo C++, que possui duas notações para referências com diversos graus de rigor sintático, consegue expressar tudo o que se deseja expressar, e a confusão sobre a especificação de "rvalue references" indica que ainda não está firmada a sintaxe do futuro.

Linguagens como Java, onde a quase totalidade dos objetos são criados por um gestor central em memória desconhecida, permitem ao programa ignorar a manutenção da memória mas ainda sofrem do problema de compreensão das referências.

Quando começamos a considerar as referências polimórficas a situação fica ainda mais punk.

URIs e a semiose da web

2010-01-04T17:15:00.000-02:00

(TODO: Será que estou usando os termos certos? Suponho que "significante" seja o mesmo que "interpretante" mas a nomenclatura da Semiótica não está bem firme na minha memória.)

Existe bastante semiose na comunicação entre programas de computador, mesmo que seja uma semiose extremamente simples, com um universo de possibilidades bastante limitado.

O serumano ao acessar uma página na Web digita no browser: http://www.twitter.com/pedrolamarao -- uma URI.

Existe algo de muito interessante acontecendo entre o serumano, o browser e um servidor perdido na rede; algo descrito em grande pompa teórica na especificação das URIs.

Em primeiro lugar, esse texto é bastante opaco para a maioria das pessoas; muitas delas compreendem que "twitter" é o nome de um "site" e que estão querendo ver as paradas de "pedrolamarao".

Alguns mais acostumados com a Web sabem que "http" é o nome das coisas que são da Web, e que existem outros nomes próprios de outros programas, como "ftp".

Realmente esse texto, ou esse símbolo, se divide em duas partes, e deve ser interpretado em dois estágios, ou como composto de dois símbolos distintos.

O primeiro símbolo é "http" que deve ser interpretado de acordo com um esquema bem simples -- a pura comparação textual. "http" vai para cá, "ftp" vai para lá e assim por diante. O nome desse símbolo é schema e esse símbolo será o interpretante do símbolo seguinte: deve-se interpretar o resto do texto de acordo com este princípio do texto.

Existe uma infinitude de possíveis schemas, já que um schema é apenas e tão somente um monte de letras em sequência. Além disso, o acordo entre todos nós sobre o que um schema significa pode ou pode não ser bem definido; é claro que a Internet inteira concorda sobre o que é "http", mas duvido que algum de vocês saiba como interpretar "astrotv" da mesma forma que eu.

Quando o schema é "http" o sistema sabe que deve usar o browser Web. Ao menos, assim esperamos que seja, quando clicamos em "http://www.twitter.com/pedrolamarao" sublinhado em azul naquele email que recebemos. O browser Web, por sua vez, sabe que o segundo símbolo -- "www.twitter.com/pedrolamarao" -- é composto também por diversos símbolos, quando a URI é "http".

O primeiro deste último conjunto é chamado authority e possui um entre poucos interpretantes aceitáveis. Neste caso, o domain name system ou DNS é o nome do sistema responsável. Este sistema dirá ao browser Web onde está o servidor responsável. Mais detalhes são irrelevantes. Restam poucos outros interpretantes aceitáveis, e seus sistemas são cheios de números.

O segundo deste último conjunto é chamado path. Este path possui um interpretante básico: o sistema de arquivos do servidor significado pelo authority. É o mesmo que os arquivos na máquina de qualquer pessoa. É claro que, como é da natureza do mundo, existem diversos outros interpretantes possíveis, como por exemplo algum outro programa dentro do servidor Web que mapeia "pedrolamarao" para um negócio em um banco de dados.

Porém, tudo o que o browser Web precisa saber, parte do seu acordo com o servidor Web, é que para qualquer path o servidor Web enviará uma porção de dados. Na maioria das vezes, esses dados estão de acordo com a norma HTML ou CSS e devem ser interpretados através destas -- seus interpretantes. É claro que nem sempre é assim, já que vêm também scripts Javascript, fotos JPEG, música MP3 etc. etc.

Como o browser sabe qual será o interpretante mais adequado para cada um desses símbolos bizarros de 0s e 1s que vêm pela rede? A semiose durante um simples abrir de página é complexa e cheia de elementos, e será finita apenas até o ponto em que o engenheiro perder o interesse nos detalhes do sistema.

A cada passagem de símbolo a símbolo por um interpretante escolhido por qualquer agente nessa confusão toda há chance para algum problema. Administradores de servidor Web vivem às voltas com "página não encontrada" e arrancam os cabelos para entender porque um determinado path não foi encontrado. Volta e meia um browser Web resolve imprimir um monte de lixo na tela quando o usuário tem certeza que está baixando um filme. Às vezes um sujeito digita o nome de um site e o browser Web diz "nome não encontrado". O que acontece quando a configuração do DNS está com defeito!? E alguns infelizes usam sistemas que não tem muita certeza sobre o que fazer com nomes começando com "http".

Toda vez que surge um novo sistema de componentes na indústria há bravatas sobre o desenvolvimento de um novo tipo de "nome globalmente único". É o grande sonho da humanidade, ser capaz de nomear os entes sem ambiguidade. Todo um conjunto de sociedades esotéricas existe em desespero para aprender o Idioma de Adão, que soube nomear todas as coisas sem hesitação. Os humanos com senso prático compreendem que nomes são acordos entre as partes e estabelecem tais acordos entre si. O schema "http" por exemplo possui um significado em acordo estabelecido sob a autoridade do IANA. Mas você sabe o que IANA significa?..

Semiótica e Programação 3

2009-12-30T15:50:00.000-02:00

Do ponto de vista do Java e do C#, C++ é uma linguagem fracamente tipada. Apesar de dizer isso abusar dos termos, existe um fundo de verdade ali.

C++, ao contrário de Java e C#, permite a formação de referências arbitrárias a qualquer objeto -- mesmo objetos hipotéticos.

Programas como este são aceitáveis, para o compilador:

list<string>* l = (list<string>*)0x12345;
l->sort();

Esta propriedade é inútil para a maioria dos programas, o que torna C++ excessivamente complicada aos olhos da maioria dos programadores. Se o programa está dizendo que naquele lugar ocorre um list<string> então isso deve ser verdade, certo? Boa sorte!

Existem programas que fazem uso dessa possibilidade, como programas para máquinas onde certos endereços são especiais e têm significado pré-definido.

Programas como este também são aceitáveis:

dog* marley = new dog();

spaceship* one = (spaceship*)marley;

one->launch();

Essa possibilidade é inerente à máquina, na medida em que o significante de uma referência existe apenas no mundo do discurso; a máquina conhece apenas bits. A reinterpretação de um padrão de bits é uma operação de pura semiótica: não é necessário computar nada, apenas compreender os bits de uma forma diferente. Assim sendo, C++ se limita a dizer que não fará esforço para garantir que esse programa faz sentido -- o problema é todo seu.

A estrutura que o tipo de uma referência impõe ao programa pode ser tal que nem todos os padrões de bits possíveis para aquele segmento de memória tenham um significado. Assim, apesar de o programa afirmar que ali está um objeto spaceship, o padrão de bits que ocorre ali pode não representar um objeto spaceship -- e o programa é literalmente um absurdo.

Em outras palavras, esse programa potencialmente viola invariantes do tipo spaceship, que são pré-condições automáticas para a chamada da função launch.

A reinterpretação irrestrita de objetos é uma das características mais estranhas dessa linguagem, e mais difícil de pôr em prática de forma útil.

Um desses usos é a transferência de objetos entre programas através de um dispositivo, técnica em que o programa receptor obtém uma pura sequência de bytes e assume que ali está o objeto transferido. Isso é chamado serialização porque torna o objeto, que possui significado e estrutura, em um série de bits.

Outro desses usos é a técnica de move construction do Elements of Programming, onde o objeto é reinterpretado de acordo com sua underlying class e copiado como tal -- e esta cópia é justamente a movimentação desejada.

Semiótica e Programação 2

2009-12-29T16:48:00.001-02:00

Linguagens cuja proposta é tipagem forte permitem através de sua sintaxe a expressão de constrições sobre a manipulação do estado de um objeto denotado por uma referência. Linguagens cuja proposta é tipagem fraca permitem manipulações de objetos com pouca constrição.

Entendendo uma referência nesse contexto como o mesmo que um signo, o tipo é o significante de uma referência, impondo significado ao objeto denotado.

Para o programa, o tipo impõe constrições sobre as manipulações possíveis ou válidas desse objeto. Em linguagens como C++, a diferenciação dos tipos permite a seleção de uma entre diversas operações possíveis de modo particularmente significativo para o objeto referenciado.

Naturalmente, programas podem formar diversas referências ao mesmo objeto, o que causa diversas dificuldades à especificação do significado de um programa como um todo e atrapalha ferramentas de transformação de código -- o "problema de aliasing".

A especificação da máquina abstrata que determina o significado de um programa deve responder de algum modo a questão: suponha uma referência a cujo tipo é A e uma referência b cujo tipo é B onde ambas denotam o mesmo objeto; suponha que um programa escreva um valor válido através de a e então leia um valor através de b; qual é o significado desse programa para A e B arbitrários?

Linguagens de tipagem fraca frequentemente realizam conversões auto-mágicas internamente de modo que o programa acima sempre possui um significado compreensível. C++ dirá que o programa acima possui em geral um significado indefinido.

Semiótica e Programação

2009-12-28T11:11:00.000-02:00

É interessante observar que podemos sem erro considerar todo nome de variável e função em um programa C++ como uma referência. Esta referência, assim como possivelmente muitas outras, denotam um certo objeto que, em si, não passa de uma combinação de três informações: um local, uma quantidade de armazenagem, e um estado atual. Referências cujo tipo é ponteiro-para-Foo conotam um objeto do tipo Foo.

Adeus, Redes Sociais

2009-12-19T19:12:00.002-02:00

Apaguei minha conta no Orkut e no Facebook.

^^

Ele é o Tao

2009-12-18T17:21:00.000-02:00

Por incrível que possa parecer, eu tenho uma veia mística forte correndo pelo meu corpo. Vivi na prática atividades místicas por alguns anos, o que me faz algo menos iludido do que apenas alguém que pensa no assunto. Então a minha prática de artes marciais satisfez a veia mística de modo que hoje os leitores desse blog devem acreditar que eu passo meu tempo todo pensando em kung fu ou programação de computadores.

Pois bem, essa combinação atual de interesses, fora as circunstâncias gerais da vida, me levam a ser místico ao estilo tao te ching de ser. E o tao te ching é uma obra que beira ao ininteligível.

Isso, misticamente falando. Por que tao é intraduzível etc. Porém, compreendendo que o que é místico não está à parte do mundo, mas apenas esquisitamente dentro dele, existe um procedimento interessante para desvendar o indesvendável: fazer o oposto do que o místico ensina e interpretá-lo ao pé da letra.

O tao te ching tem uma frase, no meio do livro, que é um tiro de significado na cara do leitor. O Autor diz [1] no capítulo XLII: Homens violentos e fortes não morrem de causas naturais. Este fato é a fundação da minha Lei.

A frase é simples e interessante. O homem violento não morre de causas naturais, ele é morto; sua vida sofre uma interrupção abrupta durante alguma violência qualquer.

Relendo o livro, encontramos o tema da continuidade abordado com frequência em imagens como a do homem que tem algo, e teme perder algo, e perde algo. Este homem é como o homem violento que luta por algo e morre na luta. Ele não continua; lutando pela vida, ele se transforma pela morte; lutando para ter, ele perde.

Assim, o livro trás sempre à tona esta propriedade da existência pela qual, misteriosamente, sempre uma coisa se transforma justamente na outra coisa que ela não é.

O livro frequentemente toma ares de manual de governo, porque a filosofia do mundo antigo não era um adereço a se apreciar, mas uma direção para a vida. A filosofia do tao te ching é peculiar nesse sentido porque, sendo filosofia aquilo que diz a você o que fazer, ela diz a você para não fazer nada.

Quando o livro diz a você que o ideal é não fazer nada, é possível entender como isso pode ser bom à luz da fundação da minha Lei: o homem que luta vence e perde, o homem que não luta continua apenas sendo o que é.

Assim também se pode compreender passagens esquisitas como as do capítulo XLI: o Tao em sua maior clareza é obscuro. Quem avança nesse Caminho, se retira. Sua Via suave é áspera. Seu pico é um vale. (...) Sua estabilidade é mudança. Sua forma é sem forma. Seu preenchimento é vacância. Seu pronunciamento é silêncio. Sua realidade é Ilusão.

Assim também, no treino de artes marciais, o praticante aprende que deve se tornar maleável para, paradoxalmente, ser estável; que deve relaxar os músculos para produzir força.

O paradoxo e a revolta da mente estão na causalidade: todos sabem que para que haja força deve haver contração muscular, portanto é absurdo dizer que relaxamente muscular é a chave da aplicação da força. A observação, porém, é limitada no espaço e no tempo: a imediateza da expansão de fibras e da produção de forças de repulsão. A observação causal é ineficaz na compreensão do onde e do quando das condições através das quais é possível e desejável produzir esses fenômenos.

Assim, o tao te ching observa como tolo o indivíduo que, para se sentir feliz, adquire aquela riqueza que o fará ser assaltado e se sentir infeliz; aquele homem que para deseja a vitória e luta, e, lutando, sofre a derrota.

O homem sábio "possui" ou "conhece" o tao, que está fora de relação com o claro ou com o obscuro. O mestre de kung fu está fora de relação com puxar ou empurrar e, apesar de estar sempre onde está, nunca pode ser encontrado por um punho que o procura.

O caminho do tao parece anátema ao caminho de Thelema mas para mim parecem mesmo duas fases de uma mesma proposta; a diferença sendo que, enquanto o texto de instruções do tao propõe que não fazer é o método, o texto de instruções de Thelema propõe que fazer é o método.

O thelemita deve fazer aquilo que ele quer fazer; porque aquilo que ele quer fazer é justamente ser quem ele é. Assim, quando o thelemita faz o que quer, ele não está fazendo nada, apenas sendo.

Quando a obviedade de afirmações sobre a "ação natural" começa a irritar o leitor, a fundação da Lei retorna para a atenção: o homem violento não morre de causas naturais, e morrer de causas naturais é algo desejável. A tranquilidade é desejável, assim como a continuidade. Inércia é movimento. Onde não há tranquilidade, onde não há continuidade, não há inércia, e o homem se afasta do tao é então se torna bonito ou feio, rico ou pobre, forte ou fraco.

[1] o texto que eu leio é uma tradução das mais distantes possíveis: do chinês para o inglês por James Legge, do inglês para o próprio inglês por Aleister Crowley, e desse último para o português por mim mesmo.

Queremos Massacration no Rock Band!

2009-12-07T14:51:00.002-02:00

If you want to be Metal, the laws you must obey!

bytes e suas interpretações

2009-12-01T21:29:00.001-02:00

Houve época em que, ao programar C#, sempre me irritava ver a notação byte -- me parecia estúpido ter um tipo na linguagem de programação chamado byte.

Li hoje em um manual da Intel:

"Although bytes, words, and doublewords are fundamental data types, some instructions support additional interpretations of these data types to allow operations to beperformed on numeric data types (signed and unsigned integers, and floating-point numbers)."

Hoje, programando em C++, me irrita que não exista uma distinção entre char-que-é-sequência-opaca-de-bits, char-que-é-número-inteiro e char-que-é-elemento-alfabético.

O texto do manual é interessante; para a máquina, realmente existe apenas o byte e suas variantes como padrões de bits; o que quer que você faça de interessante com esse byte implica uma interpretação desse byte.

A máquina é untyped; não existe mecanismo formal pelo qual se possa deduzir que uma interpretação para este byte é correta ou incorreta. Dependendo de quem você é, isso pode parecer ótimo ou absurdo.

As razões porque isso é ótimo são boas, mas diminuiriam muito com algumas poucas extensões do C++. Programadores de aritmética com poucos recursos computacionais aprendem rapidamente, por exemplo, que a máquina pode computar muito rapidamente produto e divisão por 2 sem usar as instruções de produto e divisão de inteiros -- usando as instruções de shift de sequências de bytes. Esses programadores podem argumentar que essa é a vantagem da programação untyped.

Felizmente, podemos pensar de trás pra frente; aceitando como axioma que a memória representa sempre bits, então devem haver implementações ótimas para produto_por_2 e quociente_por_2 -- assim como é_par e é_negativo. Isso sugere que uma linguagem de programação com esses operadores nativos para números inteiros satisfaz as necessidades do programador acima -- diminuindo drasticamente a necessidade de permitir shifts em objetos do tipo inteiro.

Essa idéia me vem do "Elements of Programming", de Stepanov e McJones; no livro eles discutem a idéia de "base computacional" de uma estrutura de dados. Quando aritmética inteira é implementada em uma máquina binária, produto_por_2, quociente_por_2, é_par e é_negativo devem fazer parte da base computacional dos tipos inteiros -- simplesmente por serem especialmente rápidas.

(No livro, eles não estudam representações de números reais; alguém se habilita a compor uma base computacional para números reais representados como em IEEE 754?)

[Editado!]

Acho, além disso, interessante a definição de certos tipos de dados inúteis no manual da Intel, como bit field e string. Essas definições parecem mais sugestões de uso que definições, já que nem um bit field nem um string é mais que um ou mais bytes contíguos.

Me parece que essas definições apóiam a definição posterior de operações extendidas ou especializadas sobre bytes, como referências a bits individuais ou cópia otimizada de bytes contíguos. É claro que essas são, ainda, operações simples sobre sequências de bits, e não demandam interpretação especial.

C++ em múltiplas configurações

2009-11-29T12:12:00.000-02:00

Parte dos meus esforços em entender o ambiente de programação C++ é buscar os padrões de uso do pré-processador, algo que eu nunca encontrei catalogado sistematicamente.

Ao meu ver, existem dois grandes grupos de usuários do pré-processador: programadores que usam macros como formas de reusar código totalmente inline, e programadores que usam macros para variar a definição de um programa C++ de acordo com variáveis de configuração.

A comunidade do C++ acredita que a necessidade de usar macros hoje praticamente não existe; essas pessoas deveriam ser mais específicas e dizer que a necessidade de usar macros para reusar código totalmente inline já não existe, porque compiladores otimizadores e templates de função são capazes de fazer isso.

(Eu chamo reusar código totalmente inline a uma forma de reuso que insere código diretamente no chamador, sem utilizar o mecanismo de chamada de subrotina, que envolve empilhamento, desempilhamento e saltos.)

Porém, não há solução sintática para o problema das configurações -- ao menos, não há solução bem conhecida. É interessante ler sobre a história do autoconf.

Otimização nas Sombras do C++

2009-11-26T15:25:00.001-02:00

Eu não encontro pessoalmente esse tipo de coisa com muita frequência atualmente, mas foi tempo em que volta e meia me aparecia código-fonte muito esperto, ou críticas muito espertas sobre o meu código-fonte, com relação a quão "ótimo" ele é.

Em C, essas espertezas eram invariavelmente transformações de uma notação legível e imediatamente representativa do algoritmo lógico por uma notação ilegível, equivalente mas que executava mais rápido.

Truques de aritmética de ponteiros para escrever mais rápido na memória, truques horrendos com while e switch sem break pra desenrolar loops -- vários truques cujo objetivo é escrever o mesmo código gerando um programa melhor.

De certa forma, os truques dessa época eram motivados pelos compiladores dessa época, máquinas de transformação burra de C para assembler. Com o objetivo de gerar o melhor assembler, programadores produziam pior C -- mais rápido, sim, mas menos legível e de mais difícil manutenção.

Com o passar do tempo, os compiladores se tornaram otimizadores, capazes de inlining, remoção de código morto, desenrolamento de loops, progragação de valores constantes etc.

As máquinas, por sua vez, introduziram pipelines para otimizar o trabalho de processador mais e mais rápido que a memória, capazes de execução computações intermediárias simultaneamente a recuperação de dados da memória, especulação sobre valores futuros para adiantar computações etc.

Compiladores cientes do pipeline passaram a otimizar ainda mais, ordenando e reordenando instruções de modo a obter o melhor desempenho do otimizador alvo.

Quem tem à mão um excelente compilador otimizador não precisa mais se preocupar em produzir código esperto. O compilador quase invariavelmente é melhor do que o programador humano. Ele também é a ferramenta adequada para a esperteza -- porque projetos críticos frequentemente transformam um código-fonte em programas para diversas máquinas, onde as peculiaridades variam muito.

Mas então, um dia, surgiram as máquinas multi-processadas. A seguinte citação resume a tragédia da programação para tais máquinas:

Yeah, I know. "Multithreading is hard" is a cliché, and it bugs me, because it is not some truism describing a fundamental property of nature, but it’s something we did. We made multithreading hard because we optimized so heavily for the single threaded case.

O problema fundamental de um programa multithreaded em uma máquina onde os processadores compartilham a memória é o de garantir que um certo objeto lógico -- uma sequência de bytes na memória -- não será escrito e lido de forma incosistente por múltiplos processadores -- porque um está escrevendo pela metade quando outro está lendo, etc.

Por mais que um programador faça esforço para ordenar adequadamente as instruções em um programa -- de modo que qualquer ordem de leitura possível faça algum sentido -- o fato é que o otimizador do compilador, e o otimizador do pipeline, fará mágicas com a presença e a ordem das instruções, violando a expectativa do programador.

Desse modo, os truques espertos da atualidade não são truques para otimizar o assembler e sim truques para evitar inconsistência no acesso concorrente à memória.

As pessoas legais agora falam sobre atomics e memory barriers.

O que há de curioso aqui é que esse problema espirra em certas direções mesmo onde não há múltiplos threads. Ao programar uma máquina com suporte a memory mapped I/O o mesmo problema de consistência ocorre sobre um endereço memory mapped -- reordenar leituras e escritas ali resulta no caos.

Tendo chegado até aqui, releia seu livro favorito sobre C++ sobre o significado da palavra-chave volatile.

Importei meus blogs antigos!

2009-11-24T21:01:00.001-02:00

Meu primeiro post no Blogger foi em 2001!!!

Mais sombras no Ambiente de Programação C++

2009-11-23T17:55:00.000-02:00

Estou lendo a ementa do curso de pós-graduação em Análise e Projeto de Sistemas da PUC-Rio, onde ocorre o seguinte:

"Laboratório de Linguagens de Programação

Objetivo – Capacitar o aluno a distinguir os principais componentes de linguagens de programação não convencionais tais como: programação orientada a objetos, programação orientada a eventos e programação para Internet/intranet."

A presença de "programação orientada a eventos" ali é interessante; a ementa prossegue em explicar que neste módulo o aluno aprenderá a programar Applets Java, que são orientados a eventos.

O que se chama "orientação a eventos" ali é uma técnica de projeto de aplicativos úteis plugados em algum tipo de framework de apoio, que cuida de enviar os tais eventos para o aplicativo.

Há um sub-grupo dos programadores de C++ que dirá a você que "não programa interfaces de usuário". Essa é uma afirmação interessante porque, compreendido com rigor máximo, significa que os programas produzidos por essa pessoa produzem resultados totalmente invisíveis.

Todo programa de computador possui uma interface de usuário -- senão, o usuário nunca veria seu resultado. Programadores C++ são criados desde o berço para produzir programas cuja interface com o usuário é o terminal -- um dispositivo capaz de apresentar um mapa de 80x24 caracteres.

O que há de interessante nisso é que existe um mecanismo subjacente a esse terminal que suporta a parafernália usada para pôr ali os tais caracteres -- std::cout, printf etc. Esse mecanismo é inicializado, mantido e finalizado pela implementação do C++ de forma oculta ao usuário.

Existem ambientes peculiares onde o C++ não inicializa nada disso -- ou inicializa essas coisas de forma inesperada. Os compiladores da Microsoft oferecem um parâmetro de chamada ao compilador para selecionar o "subsistema" -- CONSOLE ou WINDOWS. Aplicativos compilados para o subsistema WINDOWS não fazem coisas úteis quando o programa chama printf.

No projeto onde estou alocado agora, o sistema implantado no dispositivo-alvo é altamente customizado, e a biblioteca padrão C++ apresenta esquisitices parecidas. Não existe um "terminal" e chamar printf às vezes não faz nada, às vezes bloquea o sistema eternamente em um signal handler.

Bibliotecas como a Qt e a Glib oferecem uma terceira via, que talvez pudesse ser compreendida como um terceiro subsistema, o EVENT_LOOP. Esse subsistema possui sua própria API e faz tudo pela aplicação, que apenas inicia operações no sistema e senta esperando por notificações sobre o resultado. Assim são os Applets Java.

Tudo isso sugere que o ambiente de execução do C++ executa mais que apenas o código da aplicação, e de fato existem atividades que ocorrem antes de main iniciar e depois de main finalizar. O programador atento procurará pelo código-fonte ou executável do CRT no seu sistema -- o C Run-Time.

A Habilidade da Lentidão

2009-11-16T22:45:00.001-02:00

Na outra semana estivemos no mo kwoon com um colega novo, aprendendo os primeiros mistérios do kung fu.

Este novo colega, julguei, se enquadrou facilmente no grupo dos afobados; sempre seu discurso o convidava a dar "exemplos" do golpeamentos, e cada um deles mais e mais próximo do corpo da pessoa com quem estava conversando. Assim é a ansiedade de quem conhece a arte marcial através de romances e obras audio-visuais.

Em um determinado momento, discutindo os princípios do ving tsun, este novo colega levantou uma questão sobre a eficácia de um posicionamento defensivo: por mais que o outro esteja posicionado adequadamente, eu posso desarmá-lo sendo bem rápido, não posso?

A objeção padrão a esse tipo de hipótese é simples: e se o outro for tão rápido quanto você? Há diversos caminhos interessantes de discussão que iniciam com essa resposta.

Nesse dia, porém, me sentido inspirado para falar sobre a minha experiência pessoal. Isso acontece às vezes durante a aula e eu me dou a liberdade de falar porque, sendo um igual, me parece inspirador para os mais novos ouvir sobre as minhas dificuldades e realizações.

Elaborando o meu relato, eis o que eu tenho a dizer sobre o assunto.

É claro o poder de agir em alta velocidade é útil e desejável. Mas a percepção de que este poder é o grande poder, ou mesmo o verdadeiro poder, é enganosa. Em particular, os modos de viver e produzir em nossa sociedade constróem um excesso de valor sobre este poder em particular; além do grande apelo dramático de certos filmes.

Quando eu comecei a treinar artes marciais logo se tornou evidente uma quantidade enorme de tensão no meu corpo. Esta tensão habitava, porém, um corpo vazio do impulso de agir -- o período de treinamento mais particularmente focalizado em "golpear" parecia quase totalmente inútil.

Mas, como inevitável, em um determinado momento a tensão encontrou seu caminho e se tornou então evidente a ansiedade por agir que estava contendo. É ainda verdade que passo boa parte do meu tempo resolvendo uma ansiedade por agir. Essa ansiedade não resolvida se resolve em impulsos de ação -- de súbito, uma vontade de ler, de súbito, uma vontade de falar, de súbito, uma vontade de produzir, de súbito, uma vontade de não fazer nada.

Se você está convencido de que esse modo de ser é razoável, então o poder de agir e completar ações em alta velocidade parecerá o ideal da vida. Afinal, se um determinado surto de ação dura pouco, é preciso fazer muito com esse pouco. Assim, quem vive de ansiedades em ansiedades realiza pouco, porque não se pode fazer muito em pouco tempo.

Estrategicamente, podemos enxergar nessa pessoa a empresa que se vê presa na teia do time to market. Essa empresa está sempre se "reajustando" ao "mercado", mudando de rumo de acordo com suas "tendências", se "alinhando" com cliente. A cada momento suas prioridares são reavaliadas e alguma outra coisa se torna prioridade máxima.

Esta empresa nunca realizará as atividades com prioridade não-máxima, nunca realizará os projetos de médio a longo prazo. Ela está cheia da ansiedade por obter os resultados cuja possibilidade só passou a enxergar hoje. Está sempre correndo atrás de algum prejuízo.

Ela não compreende que a possibilidade que se realiza hoje está amadurecendo desde a tempo passado. Se ela vê hoje as condições de formação da possibilidade futura, poderá agir para obter os resultados do futuro. O indivíduo que se interessa por uma atividade hoje, se trabalhar com paciência, poderá realizar as grandes coisas que exigem muitos dias de atenção.

Assim, enquanto é sempre possível resolver as crises e se adequar às mutações através da habilidade da rapidez, é também sempre possível resolver as crises e se adequar às mutações através da habilidade da lentidão. Atuar com lentidão exige -- permite! -- atuar com antecipação. Para atuar com antecipação, é preciso ser lento; para atuar com antecipação, é preciso acompanhar com cuidado as correntes das mutações; não se precipitar.

Não é fácil atuar com lentidão, o que pode não parecer intuitivo. Quando o indivíduo experimenta exercícios simples, como andar a um passo com metade da velocidade do seu passo normal, ele compreende rapidamente que a ansiedade é uma propriedade fundamental do seu corpo -- não obstante a quantidade que ocorre em um e em outro.

Mesmo a alta velocidade corporal exige o lento acomodamento da mente à situação; quando a mente é um turbilhão, não é possível agir em alta velocidade sob controle; citando um belo anime, quando um guerreiro usa suas armas fora de controle, ele pode cortar algo que não deseja cortar, ou mesmo cortar aquilo que ele deve defender.

Se tornou, então, foco do meu treinamento em artes marciais a habilidade de agir lentamente, com eficiência. Pelas razões expostas acima, agir lentamente com eficiência não é uma contradição. É um objetivo necessário a quem acumula tensão e ansiedade; provavelmente seria diferente para disposições pessoais diferentes.

As sombras do Ambiente de Programação C++

2009-11-13T11:55:00.001-02:00

Estou realmente escrevendo sobre este assunto! É claro que, até reunir material suficiente para um livro maneiro, vai demorar muito tempo. Até lá espero encontrar alguma publicação legal que aceite artigos.

Minha motivação inicial para entender os mistérios do ambiente de programação C++ foi estudar a ABI do C++, que seria necessário implementar no sistema operacional C++.

Existem outros aspectos interessantes desse ambiente, porém, que são pouco focalizados pelas obras educativas sobre a linguagem.

Um deles é o relacionamento entre o mundo restrito da norma ISO C e o mundo maior do sistema. C fala a você sobre unidades de tradução e estabelece regras mínimas sobre como múltiplas unidades de tradução podem compor um programa válido. Ao redor da linguagem, porém, existe o problema de processar cada uma dessas unidades e produzir de fato um negócio único equivalente a este programa. Existirão então diversos blocos intermediários, os "objetos compilados", e existirá um componente ligador. A norma C não descreve este ligador, apenas impõe seus requisitos.

Outro é o modo como os mecanismo de linguagem e do sistema são usados na prática como mecanismos de abstração, e como os projetos de engenharia fazem uso desses mecanismos para lidar com problemas reais de configuração. O ambiente como um todo provê diversas maneiras de abstrair certos trechos de código; desde a seleção de arquivos a compilar, onde um arquivo pode conter a listagem para o sistema A enquanto outro contém a listagem para o sistema B; até a composição de bibliotecas dinâmicas no momento da carga na memória, onde o programa usa a versão A da biblioteca no sistema A, e a versão B da biblioteca no sistema B.

Para lidar com toda essa parafernália sistêmica ao redor do C são imprescindíveis ferramentas que operam fora da linguagem, dirigindo todas as ferramentas de forma conveniente. O projeto de middleware de televisão digital da TQTVD tem, por exemplo, aproximadamente mil unidades de tradução individuais a processar. Certamente o programador não deve chamar as ferramentas uma vez para cada um desses arquivos, sob pena de tornar o dia de trabalho um desperdício de horas absurdo. Existem portanto ferramentas para apoiar essa tarefa que, apesar de não fazer parte da definição da linguagem ou do compilador, são absolutamente imprescindíveis para se trabalhar com ela.

Tudo isso implica que a expertise no desenvolvimento de sistemas em C++ envolve diversas outras habilidades e técnicas individuais, fora aquelas envolvendo a expressão de programas em C++. Essas outras habilidades e técnicas se tornam tão mais importantes quanto o projeto pressione o programador para fora da abstração de um sistema para o mundo concreto das diversas máquinas.

Sob outro ângulo, posso comparar as listas de componentes teórica e prática que compõe o pipeline de transformação de código-fonte. Teoricamente, o pipeline C é: pré-processador, compilador, ligador ou arquivador. Na prática do projeto onde estou envolvido é: configurador de build, ferramenta de build, compilador.

Uma lição que estou tirando de tudo isso é que os melhores pensamentos sobre a linguagem de programação ideal nunca resultariam em um excelente sistema construído se essa linguagem não for implementada em ferramentas adequadas, que suportem um ciclo de desenvolvimento extremamente conveniente. O esquema de compilação separada do C oferece bons mecanismos de abstração, sem dúvida, mas torna o tempo de compilação uma infinitude de "começa e termina" processos.

Em contra-partida, opiniões sobre características de linguagem de programação do tipo "viagem na maionese" ou "impossível" parecem refletir o fato de que, até então, ninguém soube produzir uma ferramenta que a implementasse. O mecanismo de "export" do C++ por exemplo foi considerado um fracasso; agora que as técnicas de LTO e serialização de ASTs de programas estão se tornando mais difundidas, talvez com mais cinco ou dez anos "export" seja trivial.

MIT OpenCourseWare

2009-11-12T16:15:00.000-02:00

Estou cursando Introdução à Ciência da Computação no MIT todos os dias de manhã, indo para o trabalho!

Para quem não sabe, em 2002 o MIT lançou o projeto OpenCourseWare para publicar material didático dos seus cursos online sob uma licença do Creative Commons.

Alguns cursos do MIT agora têm vídeos das palestras disponíveis como parte do OCW. Dá pra assistir perfeitamente no meu telefone de manhã.

Baixar MP3 e bandalhas no trânsito

2009-11-09T10:03:00.000-02:00

Hoje de manhã presenciei uma peripécia no trânsito que finalmente me iluminou sobre a razão porque eu parei de baixar mp3 na Internet.

Estávamos seguindo pelo aterro até a Presidente Antônio Carlos e havia um trânsito razoável. Parados do lado daquele monumento de guerra, antes do MAM, vimos um e outro carro passando pela pista interna que tem ali na frente do monumento -- uma pista para um carro que começava um pouco antes e terminava a uns cem metros de onde estávamos.

Discutimos um pouco a validade daquela peripécia, porque o sujeito não ia ganhar muito tempo com aquilo, e eu pensei que não valia a pena ganhar tão pouco tempo com um truque daqueles.

Depois, pensei por que não valia a pena; afinal, ganharia-se um tempo zero, certo? Desconsiderando o problema do primeiro eu da classe média.

Me ocorreu então que tipo de pressa levaria uma pessoa a se desviar da rota normal para tentar economizar tempo. Pensei: espero que esse sujeito esteja economizando um tempo útil, porque de outro modo ele está se aborrecendo à toa. Então me ocorreu um processo de ansiedade que levaria um motorista a procurar rotas "espertas" para chegar mais cedo onde quer que seja.

Então eu entendi porque eu mesmo nunca faria aquilo: porque um processo de ansiedade tem em geral dois futuros, a satisfação ou a supressão; e satisfazer a uma ansiedade é o mesmo que alimentá-la.

Esta é a razão porque eu não uso mais programas de baixar mp3, nem tenho um instalado no meu sistema. Quando você tem gosto por música e descobre os navegadores de mp3 surge uma ansiedade -- a ansiedade de ter tudo. O mundo se transforma de um local onde você não pode ouvir tudo que existe, porque precisa transformar recursos em CDs, para um mundo onde você pode ter tudo, em troca de algum tempo de pesquisa e espera. Os baixadores de mp3 são pessoas que se vangloriam por pegar álbuns inteiros, como se baixar músicas individuais fosse indigno e revelasse a condição de ouve-por-modinha ao invés de um apreciador verdadeiro. Os programas passam 24h por dia ligados obtendo as coletâneas mais obscuras encontráveis, entupindo o HD, e o indivíduo faz ALT+TAB frequentemente para observar as barras de progressão de download.

Quando eu percebi essa ansiedade, cortei o hábito.

Java vs. C#, uma perspectiva estranha

2009-11-03T19:55:00.002-02:00

Você pode achar o que quiser na disputa entre Java e C#, mas onde na documentação da Microsoft você vai encontrar uma afirmação tão direta, sincera e esclarecedora?

"Prior to Java 2 Standard Edition, JDK 1.4, the AWT focus subsystem was inadequate."

http://java.sun.com/javase/6/docs/api/java/awt/doc-files/FocusSpec.html

bug bizarro no RVCT 2.2

2009-10-29T15:13:00.002-02:00

Descobrimos um bug bizarro no RVCT 2.2 onde a compilação de uma chamada a um operador de conversão do std::auto_ptr gera as seguintes instruções:

1. push into stack from register
2. unconditionally jump to (1)

Alguém já viu isso?

Dell, meu CD arranhou, e agora?

2009-10-19T23:02:00.001-02:00

Está chegando o segundo teste do atendimento ao cliente da Dell. Não posso mais dizer suporte ao cliente porque o meu contrato de suporte expirou, certo?

Pois bem, o CD do Windows XP que acompanhava a minha primeira máquina Dell arranhou. E adivinha? O Windows XP naquela máquina não inicia mais.

O que eu quero é bem simples: uma cópia nova deste CD. Posso até mesmo fazer o download, se eles quiserem economizar a mídia e a entrega. Mas será que a Dell vai se prontificar a substituir esse CD?

Site pessoal

2009-10-17T16:36:00.003-03:00

Estou a fim de um site pessoal mais glamouroso. Acabei de abrir um ticket no registro.br pelo domínio pedro.lamarao.nom.br.

Vou reunir ali meu site de Google Sites, e este blog, que já mostra ali no canto o meu feed do Twitter.

Sobre o assim chamado golpe de Honduras

2009-09-24T11:29:00.001-03:00

Um direitista safado, e grande amigo, me apontou para este artigo que argumenta sobre a falsidade de se considerar golpe de estado o que está acontecendo agora em Honduras.

O resumo executivo é: a Constituição de Honduras determina a deposição imediata do Presidente caso ele faça esforços para promover a própria reeleição.

Leia!

C++ e puramente funcional

2009-09-18T17:27:00.002-03:00

Usando GCC 4.5, Dehydra e um script maroto, seria possível implementar uma verificação estática de que uma função é puramente funcional?

__attribute__((user("functionally_pure")) int foo_free_of_side_effects (int x, int y);

byte, address e dispositivos

2009-09-02T22:44:00.004-03:00

Suponha que você tem uma variante de C++0x onde existem apenas os tipos: byte, address e size. byte é uma sequência de oito bits, address é uma posição na memória e size é a distância entre duas posições na memória.

Com bytes você pode fazer bit shifting e outras operações próprias de sequências de bits; com address você pode navegar pela memória, obtendo sucessores e predecessores; com size você pode navegar pela memória a passos largos.

Suponha, além disso, que o programa tem à disposição um allocator que obtém pedaços de memória com tamanho fixo, e acesso a dispositivos por uma API razoável.

Que tipos de programa você poderia escrever?

Você poderia copiar dados de um dispositivo para outro:


void copy (device& in, device& out)
{
  const size length = allocator.page_size();
  address buffer = allocator.allocate_page();

  size n;
  while ((n = in.read(buffer, length)) > 0) out.write(buffer, n);
}

Você poderia copiar dados, criptografando com XOR:


void copy_and_encrypt (device& in, device& out, byte key)
{
  const size length = allocator.page_size();
  address buffer = allocator.allocate_page();

  size n;
  while ((n = in.read(buffer, length)) > 0)
  {
    for (address i = buffer; i != buffer + length; ++i) *i ^= key;
    out.write(buffer, n);
  }
}

Acredito que você poderia realizar praticamente todo tipo de criptografia apenas com operações binárias.

De onde um programa obteria a chave? De outro dispositivo de entrada, talvez.

Meu ponto é que nada disso está relacionado com aritmética em domínios numéricos; mesmo com a existência de size no programa, que é claramente uma "quantidade". Ainda é possível escrever programas interessantes mesmo sem a possibilidade de realizar aritmética com valores do tipo size.

Dualidade memória/dispositivo

2009-08-31T21:21:00.004-03:00

Ainda pensando sobre linguagem de programação e sistema, e na possibilidade de se projetar uma API de dispositivos apenas com byte e address<>, me ocorreram os seguintes pensamentos sobre a relação entre os dispositivos e a memória.

A memória é uma sequência onde ocorrem símbolos, na máquina binária contemporânea esses símbolos são bits e a unidade de armazenagem prática aos programas é o byte.

Além disso, na máquina de von Neumann, toda a operação do programa ocorre sobre a memória, inclusive operação sobre dispositivos, que ocorrem ao programa na forma de intervalos especialmente posicionados na memória.

Programas no sistema Unix, por outro lado, vêem dispositivos na forma de arquivos, com o qual trocam dados; o dispositivo é uma origem de dados e um destino de dados. A API fundamental de dispositivos é read e write. A realização básica de um arquivo é o próprio arquivo de dados, ocorrendo em um sistema de arquivamento.

É claro que o Unix, aplicando sua filosofia de simplicidade, exibe tudo como arquivo, inclusive todos os dispositivos; programas podem trocar dados com qualquer dispositivo representável em /dev. De fato, existe /dev/mem que reflete como um dispositivo a própria memória.

Por fim, borrando a distinção entre o que o processo de usuário vê e o que o sistema vê, existem os mecanismo de mapeamento em memória, que representam dispositivos (entre outras coisas) como intervalos de memória ao processo.

É fácil observar que a memória, fisicamente, e o dispositivo, abstratamente, são elementos e conceitos que se substituem e se sobrepõe. A noção de character device no Unix parece nascer exatamente daqueles dispositivos cuja natureza é a de um intervalo de átomos, um conceito cuja necessidade surge após a decisão de representar tudo como arquivos.

A união de memória virtual e o aspecto memória de um dispositivo ocorre no mecanismo de mapeamento em memória; no projeto de uma API de I/O assíncrono, a necessidade de expor páginas da memória de um processo ao driver do dispositivo para DMA também ocorre.

Programas sintonizados à API de arquivos frequentemente desejam comunicar a subprogramas dados em memória, e então a necessidade de um pseudo-dispositivo cuja representação é memória surge.

Tudo isso implica que o projeto de uma API de dispositivos é o projeto de uma API de memória, e todo projeto de um abstract data type dispositivo implica o projeto de um abstract data type intervalo-de-memória.

Que um aspecto ofereça melhor desempenho a um programa é função das necessidades desse programa. Programas que lêem arquivos frequentemente mapeiam este arquivo na memória e o lêem como um intervalo de memória. Programas que computam na memória o digest SHA-1 de uma informação frequentemente operam um pseudo-dispositivo onde escrevem blocos fixos de dados iterativamente.

Fundamentalmente, eis a questão: um dispositivo deve ser convertível para um intervalo-de-memória e vice-versa. O desafio é projetar tal API segundo todos os critérios de boas práticas realisticamente em um sistema.

Mudando de assunto, eis o projeto 9.1 do Elements of Programming:

"Modern computing systems include highly optimized library procedures for copying memory; for example, memmove and memcpy, which use optimization techniques not discussed in this book. Study the procedures provided on your platform, determine the techniques they use (for example, loop unrolling and software pipelining), and design abstract procedures expressing as many of these techniques as possible. What type requirements and preconditions are necessary for each technique? What language extensions would allow a compiler full flexibility to carry out these optimizations?"

Máquina de Turing

2009-08-25T21:30:00.002-03:00

Acho que atingi uma compreensão de como uma máquina de computação contemporânea cumpre os requisitos restritos da máquina universal de computação.

A máquina universal de computação é uma máquina que opera sobre símbolos ocorrendo um espaço unidimensional infinito. A máquina transforma seu estado de acordo com o símbolo atual; ela pode, por exemplo, avançar ou retroceder no espaço de símbolos, reescrever o símbolo em uma determinada posição, ou qualquer outra coisa.

A máquina se torna útil com a especificação do conjunto de símbolos representáveis e do significado de todos esses símbolos. Assim, um símbolo pode significar "avance três posições" e outro símbolo pode significa "substitua o próximo símbolo com o símbolo seguinte a esse, e vice-versa.

É claro que nenhuma máquina concreta terá acesso a um espaço infinito para símbolos; portanto, podemos falar sobre uma máquina universal restrita com espaço finito para símbolos.

Uma máquina universal binária é uma máquina cujos símbolos são 0 e 1. Uma tal máquina não pode significar muita coisa com apenas um símbolo, mas nada impede que significados especiais sejam atribuídos a sequências específicas de símbolos.

Assim, podemos falar sobre símbolos complexos, compostos por uma sequência de símbolos, que na máquina binária será uma sequência de 0s e 1s. A máquina binária possui portanto uma regra implícita: enquanto um símbolo complexo não for compreendido, ela avança para o próximo símbolo.

Quando um símbolo completo é compreendido, a máquina realiza a transformação especificada para aquele símbolo complexo.

É claro que, em uma máquina concreta, o número de símbolos complexos especificáveis é finito, já que os próprios símbolos complexos devem ser sequências finitas de símbolos fundamentais, e portanto existe uma combinação finita de tais símbolos complexos.

Mas um conjunto suficientemente grande pode representar todas as operações possíveis sobre uma memória sequencial de símbolos fundamentais, como: se o valor lógico do próximo símbolo complexo for verdade avance para a posição determinada pelo símbolo complexo seguinte a este, senão pelo símbolo complexo duas posições depois.

Isso é verdade porque, se podemos computar matemática fundamental, podemos computar qualquer coisa.

Tipos de dados primitivos 2

2009-08-21T14:10:00.003-03:00

Em C++, existe uma certa ambiguidade no significado dos tipos primitivos.

Tome char, por exemplo. char pode ser apenas char, pode ser signed char ou pode ser unsigned char. Mas char deve ser caractere, certo? Qual é o significado de um caractere ser signed ou unsigned? Nenhuma.

Existe, é claro, uma razão porque é possível especificar unsigned ou signed char; porque char é um valor inteiro de tamanho 1. De certa forma, char é o menor de todos os int, e foi projetado para ser usado como tal. Em uma máquina convencional, char é um inteiro de 8 bits. C99 na prática exige que char ocupe 8 bits.

Em C original, o ponteiro para char possuía a propriedade adicional de representar qualquer endereço válido de memória. Portanto, uma função que lê dados de um dispositivo qualquer para a memória aceitaria um parâmetro do tipo ponteiro para char significando o endereço de memória de um buffer.

É claro que isso provoca uma confusão com outro sigficado de ponteiro para char, a string de bytes terminada por NULL, ou NTBS. Por esse motivo, alguns programas e bibliotecas usam ponteiro para unsigned char para representar segmentos opacos de memória, como buffers de I/O.

Em C99, qualquer ponteiro é conversível para um ponteiro para algum char. Em C++ isso não é permitido. Em ambas as linguagens, qualquer ponteiro é conversível para um ponteiro para void.

Aritmética de ponteiro não é permitia para um ponteiro para void, infelizmente; programas que desejam atravessar a memória por qualquer razão devem usar ponteiros para char. Isso exige o uso de conversões por reinterpretação, como a notação de cast com parênteses, ou reinterpret_cast.

Existem aqui diversas necessidades diferentes. Uma delas é endereçar memória opaca, sem interpretação, e endereçá-la completamente. Outra é representar o menor valor inteiro possível na plataforma. Outra é representar um caractere. Outra é representar um segmento de texto.

Representar um caractere como o menor inteiro da plataforma é, hoje sabemos, uma ingenuidade, e existem diversas representações de caracteres que usam um número variado dessas unidades para caracteres, ou usam um número fixo de duas ou mais dessas unidades.

Assim, quando ocorre em um programa um caractere literalmente, como f, qual é a quantidade de armazenagem que o valor correspondente ocupa na memória? Depende da representação de caracteres usada no sistema alvo -- e naturalmente na unidade de memória da arquitetura alvo.

Eu não gosto dessa notação de signed e unsigned. Parece ter havido um problema original em que os ints tiveram de ser subitamente diferenciados entre inteiros e inteiros positivos. Não entendo como isso pode ter sido súbito, mas ainda não conheço bem a história da computação para saber como eram as máquinas quando C foi projetada. Me parece apenas que é um sistema de tipos obsoleto. As máquinas conhecem os naturais, ou inteiros positivos, representados em base 2 e conhece os inteiros representados em base 2 com complemento de dois.

Caracteres são um outro tipo de informação, distinto de números, apesar de logicamente relacionáveis -- a representação de um caractere é um índice em uma tabela.

Declarações, nomes e objetos

2009-08-18T11:06:00.002-03:00

Uma linguagem como C++ é chamada declarativa porque o elemento central de sua sintaxe é a declaração.

Uma declaração é uma construção sintática que associa um nome a um sujeito -- ou um identificador e um objeto. O caso simples é a declaração de uma variável.

Creio que um objeto é um ente totalmente abstrato do discurso, ao contrário do que a literatura sugere. Certamente podemos falar sobre o objeto e descrever suas propriedades; mas na máquina concreta, o significado de um objeto transita entre seus três aspectos fundamentais: seu valor, sua armazenagem e sua localização.

O tipo de um objeto, por princípio, corresponde ao domínio de seus valores. Assim, podemos considerar os dois tipos primitivos fundamentais que sugeri anteriormente, byte e address. byte é um pseudo-tipo para "o que quer que seja, armazenável na memória". address é o tipo do valor "localização na memória de um valor do tipo T". address é o tipo do valor "localização na memória do que quer que seja".

Em C++, a função de "o que quer que seja" é cumprida por char; char é a unidade de memória na máquina abstrata C++. A função de "localização na memória do que quer que seja" é cumprida em parte por void*, para o qual podemos converter qualquer T*, e em parte por char*, que garantidamente pode endereçar qualquer localização válida na memória.

Valores do tipo byte são apenas copiáveis; é possível, no mínimo, reproduzir o padrão de bits de uma armazenagem para a outra.
Valores do tipo address são copiáveis; além disso, o domínio de address é equivalente ao domínio dos naturais, e suporta a mesma aritmética; por fim, existe a operação de-referência, que transforma um valor address em um valor T.

Com esses dois tipos podemos fazer muito pouco, mas podemos fazer algo; é possível escrever um programa capaz de copiar dados de um dispositivo para o outro apenas com byte e address. Seria também possível escrever programas capazes de rearranjos e outras operações similares.

Esses programas não poderiam ser muito sofisticados porque os únicos julgamentos possíveis seriam sobre localizações de objetos, e não seus valores. Seria possível, por exemplo, escrever um programa que inverte uma sequência de bytes, etc.

Tipos de dados primitivos

2009-08-17T14:12:00.003-03:00

Após uma longa considerção sobre o assunto, e bastante tempo livre durante as férias, cheguei a uma opinião sobre que conjunto de tipos de dados primitivos eu gostaria de ver em Pedro C++.

A idéia de que há signed e unsigned como qualificadores distintos do tipo de dados não me parece muito coerente; um signed integer e um unsigned integer são valores em domínios completamente distintos. De fato, um unsigned integer é um natural, e foi essa intuição que me levou eventualmente a compilar a seguinte lista:

byte
address
natural
integer
rational
real
complex

Com os tipos primitivos byte a address seria possível escrever um sistema capaz de transportar dados entre dispositivos. Um tal sistema, ou sub-sistema, não tem interesse na representação de um dado; isso percebe-se claramente nas APIs de I/O do Unix, cujo tipo de dado é void*. Este tipo, em Pedro C++, seria um address.

Para a computação matemática pura temos a seleção completa de domínios algébricos. natural, integer e real são verdadeiramente primitivos, enquanto rational e complex são derivados destes. Em uma máquina convencional, natural é representado diretamente em base 2, integer é representado em base 2 por complemento de dois, e real é representado na forma dada em IEEE 754. Uma linguagem rica permitira que esses tipos sejam genéricos no tamanho; natural<16> é um natural ocupando dois bytes, integer<64> é um inteiro ocupando 8 bytes.

Deve ser possível, com base em natural, implementar qualquer domínio homomórfico com os naturais, como por exemplo caracteres em um mapa de caracteres.

É claro que nada disso é remotamente suficiente para uma linguagem na prática; é preciso ainda falar sobre muitas coisas muito simples, como a representação e o tipo de valores representados literalmente no programa etc.

NOTA: não tenho certeza se "homomórfico" foi a palavra certa ali em cima.

2009-08-11T10:58:00.003-03:00

Por que eu desejo escrever explicitamente sobre o ambiente de programação C++?
Por que existem documentos com frases assim:

To compile your programs, link with the C++CSP2 library. On GCC this can be achieved by using the "-lcppcsp2" option on the command-line.

Se eu tentar compilar o programa de exemplo deste documento seguindo essas instruções à risca ocorerrá o seguinte:

/usr/bin/ld: cannot find -lcppcsp2
collect2: ld returned 1 exit status

Por quê? Por que você não pode ingenuamente dizer quais bibliotecas você quer; o ambiente de ligação de programas com bibliotecas envolve a localização da biblioteca. Onde ela está?

Concordar Dói

2009-08-10T15:48:00.003-03:00

Estou lendo agora artigos sobre certas construções em máquinas programáveis chamadas "corotinas". O artigo que eu estou terminando de ler nesse exato momento insinua, cheira, pinta, sugere e diz explicitamente que "corotinas" são muito melhores que "subrotinas" por infinitas razões.

Compreender o que é "corotina" para esse autor me obriga a compreender como "corotina" é melhor que "subrotina"; talvez depois de compreender como isso é verdade para essa pessoa, eu saberia destilar meu próprio conhecimento.

É intrigante como esse concordar é revoltante. A leitura do texto é difícil por essa razão; eu não quero concordar com julgamentos sobre o valor do que eu estou aprendendo agora.

Porém, acho interessante como a idéia de concordar com uma idéia temporariamente, a título de argumentação, é tão difícil. A mente rejeita este estado de acordo, mesmo que breve, como se realizá-lo por um breve momento fosse já uma desestruturação da ordem estabelecida.

E isso digo eu, que não estou particularmente interessado em defender "subrotinas". Como é seria a experiência de aprendizado de uma pessoa pessoalmente determinada a gostar de "subrotinas"? Será que esse aprendizado é possível?

Creio que há aqui um defeito no texto, se estiver nele codificada uma intenção de educar; o texto me rejeita, tanto quanto eu o rejeito.

Novo projeto: monografia sobre o ambiente de programação C++

2009-08-08T13:55:00.003-03:00

Como algumas pessoas sabem, um dos meus objetivos de mais longo prazo é projetar um sistema operacional em C++ e aplicar nesse projeto os métodos da orientação ao objetos, da programação genérica e da programação funcional.

Seria, é claro, ingênuo simplesmente acreditar que essa atividade é como programar uma variante do Unix convencional, meramente usando o compilador C++. A linguagem impõe requisitos muito mais interessantes sobre a ABI do sistema que C, uma linguagem simplória nesse sentido.

Assim sendo, comecei a estudar a questão da ABI do sistema e como C++ lida com ela, bem como o suporte ao mecanismo central da programação genérica em C++, os templates.

Tudo isso me sugeriu este novo projeto: escrever uma monografia sobre o ambiente completo de programação em C++, evidenciando detalhes ocultos ao programador, como a atuação do linker, do assembler, do compilador, do loader e mesmo de drivers de compilação como o make.

Quem sabe esse não será meu primeiro livro publicado?

Comentário do dia

2009-08-06T16:18:00.002-03:00

-- Você não sabe como é bom. É bom demais. Nego me paga pra ler um livro. Sabe como é?

Sigyn: componentes genéricos para networking

2009-08-01T00:47:00.001-03:00

Gostaria de anunciar o lançamento da biblioteca Sigyn.

A Sigyn contém diversos componentes genéricos para o desenvolvimento
de servidores de rede concorrentes. Ela também contém exemplos para
protocolos básicos como chargen e discard.

O código-fonte da biblioreca está disponível neste repositório
Subversion:

http://ccppbrasil.googlecode.com/svn/users/pedro.lamarao/sigyn

Documentação sobre a biblioteca está disponível aqui:

http://code.google.com/p/ccppbrasil/wiki/Sigyn

Pesquisando Sistemas Operacionais

2009-07-28T13:01:00.002-03:00

O iniciante em qualquer nova área de conhecimento sofre muito, na minha experiência, com as exigências transversais ao puro conhecimento que se impõe a ele.

O programador iniciante, por exemplo, sofre com a ferramenta de compilação, com o ambiente de compilação, com as peculiaridades do linker e do loader no sistema que ele está usando.

Da mesma forma, quem deseja iniciar uma pesquisa em sistemas operacionais deve lidar com problemas transversais aos algortimos de escalonamento e gerência de memória, como a singela atividade de bootar o kernel.

Reencontrei hoje uma ferramenta que me auxiliou muito nas minhas primeiras tentativas: o GRUB. Essa ferramenta não só facilita o processo de boot, resolvendo os problemas iniciais, como oferece ao kernel um protocolo de início muito similar ao protocolo de início da própria linguagem de programação, com uma função main.

O projeto GRUB vai além e oferece código-fonte em assembler e C para um kernel capaz de imprimir "Hello World!" de modo que qualquer programador minimamente determinado poderá iniciar seus estudos.

Viagem a São Paulo

2009-07-03T18:00:00.004-03:00

Estarei em São Paulo segunda, terça e quarta-feira da semana que vem.
Se alguém quiser aproveitar, estarei disposto a passear e pegar alguma balada. ;-)

Ficarei hospedado no Estanplaza Berrini.

Passei de nível!

2009-07-03T10:40:00.001-03:00

Agora sou um orgulhoso praticante do nível Luk Dim Boon Kwan no Instituto Tang Son Ving Tsun.

Terra e

2009-05-14T01:24:00.001-03:00

Acabei de terminar de ver Terra e. O nome significa algo como "em direção à Terra". Foi um anime... esplêndido.

Defesa da Monografia...

2009-04-24T16:36:00.001-03:00

...dez!

Defesa da Monografia

2009-04-24T13:06:00.002-03:00

...às 14h30. Logo depois de comer. A ansiedade está misturada com a comida. Estou enjoado. o.0

Elogio ao Rythmbox

2009-04-16T10:58:00.003-03:00

O Rythmbox é um "media player" para o GNOME com suporte ao protocolo DAAP.

Através do DAAP, o Rythmbox encontra automaticamente todos os colegas de trabalho na mesma rede que você, pra que ambos compartilhem suas coleções de música entre si.

É uma maravilha que não demanda esforço.

Aqui na rede do trabalho você encontraria os seguintes compartilhamentos:

- all your mp3 are belong to us
- E = m.c^2
- Lay down your souls to the gods Rock and Roll
- Músicas do FULANO
- Radiola do seu zé

Problemas de Linguagem

2009-04-02T18:18:00.002-03:00

Eu sou um esotérico, certo. Um ateísta, antes de ateísta um agnóstico, e um esotérico por prazer.

Não obstante, eu sou uma pessoa inteligente.

Por ser inteligente, não consigo suportar certas idéias, como por exemplo a idéia de que a descoberta da anti-matéria é prova irrefutável da existẽncia do mundo espiritual. [1]

Recentemente alguém me alertou para a relevância da obra de Wittgenstein. Achei esta pérola na Wikipedia, na página dedicada a ele.

"In this regard, one can see affinities between Wittgenstein and Kant. In the Critique of Pure Reason, Kant argues that when concepts grounded in experience are applied outside of the range of possible experience, the result is contradictions and confusion. Thus the second part of the Critique consists of refutations, typically by reductio ad absurdum, of logical proofs of the existence of God and the existence of souls, and attacks on strong notions of infinity and necessity. In this way, Wittgenstein's objections to applying words outside the contexts in which they have an established meaning mirror Kant's objections to the non-empirical use of empirical reason."

[1] Sua Divina Graça A. C. Bhaktivedanta Swami Prabhupada, "Fácil Viagem a Outros Planetas", Editora THE BHAKTIVEDANTA BOOK TRUST INTERNATIONAL, 1998

Mais sobre a Vontade

2009-04-01T20:08:00.002-03:00

Sendo um Thelemita, ou um Telemita se você preferir, é natural que o problema de "fazer a própria vontade" seja constantemente trazido de volta à atenção.

Um dos aspectos mais intrigantes sobre esse problema é o de se observar que, dado um conceito do que é a Vontade de um ser humano, todos sempre fazem a própria vontade, a todo momento, invariavelmente.

Isto é assim se você entende por Vontade justamente aquele aspecto do ser humano que o mobiliza, e se você entende a mobilidade de um ser humano é sempre baseada na mobilidade do seu corpo, isto é, tudo o que um ser humano faz é, no fim das contas, algo que seu corpo faz.

Nós sabemos que o corpo humano é movido através de uma intrigante interação entre ossos, fibras musculares e neurônios. O corpo se move porque o cérebro comunica aos neurônios que comuniquem às fibras musculares que se contraiam ou relaxem, de tal modo que os ossos são puxados uns para perto dos outros ou largados à mercê da gravidade, o que por fim tem o impressionante efeito final de fazer o corpo inteiro, ou parte dele, se mover.

Assim sendo, qual é o sentido em dizer que uma pessoa não está fazendo sua própria vontade, ou que não está fazendo aquilo que ela quer? Nenhum.

Porém, é indiscutível que praticamente todas as pessoas tem a experiência desagradável de que não estão fazendo algo porque querem. Uma das razões porque isso é assim é porque a pessoa em questão se percebe enredada por algum poder que a coage de alguma maneira.

Acredito que um dos motivos porque o crime de violência física é tido como abominável, em comparação com crimes chamados "colarinho branco" que, não obstante, tem um impacto negativo em um número bem maior de pessoas.

Crimes de violência física atuam diretamente sobre a liberdade do corpo de um ser humano; quando eu, que sou forte, agarro o braço de uma outra pessoa, que é fraca, esta outra pessoa se vẽ privada da liberdade de ir para longe de mim.

Agora, quando uma operadora de telefonia inflige a um indivíduo cobranças indevidas mês após mês, transtornando essa pessoa horrores com a necessidade de falar horas a fio com um burocrata, esse mal se refletirá em uma multa. Entendo que isto é assim em parte porque, fora todas as outras considerações relevantes, há pouca violação na liberdade dos corpos aqui; o indivíduo continua sempre com a opção de se afastar, de romper o relacionamento.

Existem outros aspectos interessantes desse problema, como a pedagogia. Muito se fala superficialmente sobre convencer o aluno a entender os assuntos, ao invés de decorar as informações, mas pouco se fala sobre o uso do verbo convencer nessa história. Existe algo de seduzir no ato de educar. Alguém que ainda não compreende não tem como saber o valor daquilo que irá um dia compreender, se cumprir as regras de um processo pedagógico. Essa pessoa atravessará esse processo porque motivo? Uma das maneiras de fazer isso é através do medo, outra através da sedução. Haverá quem diga que uma coisa é instância particular da outra.

Em todos esses casos há algo de privação da liberdade do outro envolvido, o que nos leva de volta a pensar, nesses casos, como é possível que uma pessoa faça sempre sua vontade. (Fazer às vezes sua vontade não faz sentido como regra fundamental de uma ética.)

POSIX/C++

2009-02-28T16:38:00.003-03:00

No final de 2007, o IEEE aprovou a criação do projeto "POSIX-C++ Binding", com o propósito de aumentar a portabilidade de programas C++ que façam uso das interfaces de sistema especificadas em POSIX.

Este grupo de trabalho foi "fretado" inicialmente para entregar seu produto em Dezembro de 2011.

Discussões ocorrem em uma lista de discussão pública.

Os trabalhos iniciais envolveram a adequação da nova biblioteca de threads, componente da biblioteca padrão do C++0x, e especificar sua implementação sobre as interfaces de sistema especificadas em POSIX.

Dois outros projetos estão atualmente em discussão: bindings C++ para as interfaces de sockets, e bindings C++ para as interfaces do ligador dinâmico.

Eu estou trabalhando no projeto de bindings C++ para as interfaces de sockets; mais informações podem ser obtidas aqui. Meu trabalho está acontecendo sob a bandeira do Grupo de Usuários de C e C++ do Brasil.

Na próxima reunião do grupo de trabalho, dia 07 de Março, esses dois projetos serão tema da pauta de discussão. Infelizmente eu ainda não obtive um visto para participar dessa reunião; com sorte isso será possível.

O objetivo da binding para as interfaces de socket é basicamente produzir uma classe que aplique as técnicas de gerência de recurso em C++ no projeto de uma classe que represente um socket. Outros objetivos são melhorar a utilização das estruturas de dados representativas de endereços de socket, o uso de atributos de socket e das interfaces de tradução de nomes.

Ao longo deste processo se tornou claro que seria útil acrescentar às estruturas de dados simples especificadas em POSIX elementos como construtores e sobrecargas de operadores, para tornar mais simples e mais eficiente a inicialização de objetos destes tipos e sua operação.

Estou prestes a publicar agora meus primeiros trabalhos nesse sentido, na forma de uma modificação da GNU libc, usável com o GCC 4.4. Informações estão na mesma página mencionada acima.

Do Largo do Machado até em casa...

2009-01-28T22:09:00.001-02:00

...dá quarenta minutos a pé. com esfihas no bucho.

Notícias

2009-01-26T23:39:00.002-02:00

Pois!

Passei o mês quase todo doente. :-(
Estou cheio dep orlbmes...
Há quinze dias uma inflamação na garganta está enchendo o meu saco.

Só hoje eu ganhei ânimo suficiente pra fazer atividades físicas.
Um colega de treino está se preparando para participar de uma competição full contact.
Estamos treinando pra ajudá-lo.
Emocionante. :-)

Comprei, finalmente, um teclado!
É um sintetizador Yamaha S03.
Usei pouco, até agora.
A turma da empresa marcou um ensaio quinta...

Finalmente escolhemos um nome legal para a escola de kung fu e estamos preparando cartazes para propaganda.
Com a escolha do nome, registrei um domínio, e em breve colocaremos um website sobre a escola.

E o meu aniversário está chegando!
Provavelmente não estarei bem o suficiente pra beber... >|

Eu Não Sabia que Podia

2008-12-02T10:44:00.003-02:00

Fernanda recentemente me apresentou aos vídeos do Pat Condell no YouTube. Preciso dizer que são vídeos verdadeiramente inspiradores.

Resolvi começar a ler o livro do Richard Dawkins, que tia Elizabeth me deu de presente, pra aproveitar o momentum. A frase tópico deste texto foi tirada do Prefácio do "Deus, um Delírio".

Eu acho esta frase muito interessante, realmente; a sensação ou experiência que ela denota era algo que víamos com frequencia no trabalho da Loja Nova Ísis e que, às vezes, ocorre conosco treinando artes marciais.

É impressionante como, de alguma forma, nosso corpo, enquanto máquina biológica, é capaz de fazer coisas de que nós não somos conscientes. Esse fato mecânico e biológico é verdade seja para as mínimas coisas, como por exemplo a capacidade de sustentar pressão usando os braços e pernas, seja para coisas em um nível mais alto de abstração, como fazer sua opinião e gosto pessoal coexistir com outras pessoas.

Sendo um libertário e acreditando que todas as pessoas tem o direito de fazer de sua vida aquilo que lhes der na telha, creio que "eu não sabia que podia" é o verdadeiro inferno.

Risco

2008-11-14T00:21:00.000-02:00

Cross-post: esse papo de pessoas que não oferecem risco soa familiar...

Atividades

2008-11-12T00:58:00.002-02:00

Acho que há quem se atualize sobre a minha vida por aqui, não?

Este fim de semana estive pela sexta vez esse ano em São Paulo, como parte da organização do Seminário sobre C e C++ em Sistemas Embarcados. Está sendo uma atividade muito frutífera contribuir para o crescimento desta comunidade; ver todas as 340 pessoas naquele auditório foi recompensador.

Agora estamos discutindo e trabalhando para a realização de uma Conferência em Fevereiro; creio que a qualidade deste evento será a coroa do trabalho de um ano.

Enquanto essas coisas acontecem, estou com mais de cinquenta páginas de monografia de projeto final escritas esperando Resumo e Conclusão. A pesquisa que motivou este texto, sobre a POSIX/C++ Network Library e quem sabe uma POSIX/C++ File Library, está em andamento com bons resultados. Em breve publicarei um novo paper na lista de discussão do working group.

Por sinal, este trabalho precisa de voluntários, e eu ainda não sei como motivar a comunidade a contribuir. Nem mesmo eu sou arrogante ao ponto de dizer "trabalhem para mim" mas a única coisa que consigo pensar é justamente aquilo sobre o qual já estou pensando...

Gostaria de dizer que estou prestes a me formar mas é possível que eu entre pelo cano. Estou a tanto tempo desligado da universidade que é perfeitamente possível que eu tenha sido convocado para fazer o ENADE... Sabe o que acontece quando você não faz o ENADE? ¬¬

Mas vou considerar para mim mesmo que a defesa da minha monografia será minha formatura, e então vou desbloquear minha lista de promessas. A primeira a cumprir será começar um curso de dança de salão; forró e gafieira.

Depois de nove anos de artes marciais, creio que será possível aprender a dançar.

Estou pensando ainda se vou mesmo fazer aulas de direção. Não me interesso por carros, e nem mesmo tenho um. Prefiro que as mulheres dirijam pra mim.

Aliás, estou em contagem regressiva para sair para o meu próprio apê! Minha prima Karen me fez uma excelente proposta: ficar no apê dela quando ela sair de lá. Fica em Copacabana; o contrato dela termina em Maio. Eu já estou sabendo os valores, creio que seja possível! Porém, eu teria que me adiantar cinco meses ao cronograma familiar.

Estou querendo ir à reunião do POSIX/C++ em Nova Iorque em Março, o que fode com quaisquer planos de torrar dinheiro. Não tenho certeza se será o melhor momento ou não, talvez nem seja particularmente útil ir defender minha proposta pessoalmente, já que há pouca controvérsia; eu gostaria de ir por mim mesmo. Que onda, rapaz!

Por fim, você precisa visitar o Livemocha hoje mesmo! Adivinha em que curso eu me matriculei? その通り　です！

É isso. 待った　ね！

Furei!

2008-10-11T22:24:00.002-03:00

Finalmente!
Furei dois de uma só vez.

A menina que fez o piercing pra mim, a Gaby, fez um trabalho maneiro.
As argolinhas são legais e eu achei a distância entre elas boa.

Importância

2008-10-10T00:18:00.002-03:00

Já a alguns meses, eu sou responsável por uma sessão semanal de treino de kung fu; responsável porque, sendo o mais antigo, espera-se que eu seja como o irmão mais velho quando os pais não estão presentes.

Meus irmãos mais novos gostam de treinar kung fu e isto me dá oportunidade de entrar em contato próximo com suas expectativas e ansiedades; nesse processo, muitas coisas estranhas acontecem.

De certa forma, a arte marcial é como qualquer outro tipo de arte; por um lado, a execução da arte é matéria de habilidade, enquanto por outro lado ela é inspiração, instinto e emoção. Essas são coisas de que a nossa cultura não trata.

Durante o almoço, conversando com meus colegas sobre instrumentos musicais, chegamos a um ponto de pouca controvérsia: aprender um instrumento musical é exercitar o corpo para adequá-lo àquela execução. Isso é difícil porque é difícil se disciplinar, é difícil adequar o comportamento, é difícil... bem.

Por mais que eu seja um ser inteligente, capaz de refletir a minha impressão do mundo em pensamento, ainda assim sou um ser que se comporta de maneira tal; é irrelevante que se pense "você deve ser assim", ou "o ideal é fazer desse jeito" ou mesmo "putz, queria tanto fazer como ele". O conhecimento é um fator determinante para a ação mas ele é um fator praticamente irrelevante diante de um universo silencioso de tendências, hábitos e características intrínsecas.

Eu não sou capaz de ser qualquer coisa; em particular, eu não sou capaz de não ser eu. Isso parece contraditório diante da idéia de "aprendizado" mas eu penso que a própria idéia de "aprendizado" é contraditória, a idéia de que através de algum processo você "melhora", deixa de ser, digamos, mau, e passa a ser bom.

É certo que eu deixo de ser como era ontem e passo a ser como serei amanhã, porém. A minha percepção, em particular, é de que a cada dia meu poder aumenta. Porém, isso é de se esperar, já que eu sou arrogante; e quando deixarei de ser?

Em combate os nervos afloram, a violência encontra os caminhos das profundezas até a flor da pele, e você se percebe com uma vontade insuportável de machucar uma pessoa que, de outro modo, é muito querida.

Em reunião você retruca e critica o outro, construindo pra si um pedestal moral ou uma vitória épica, porque ser ideal e ser vitorioso é tão desejável que a construção do outro como incompetente, irrelvante ou fraco não é tanto aceitável como... consequente.

Qual é o significado de ser melhor? É certo que parte do eu é ser bom e dar prazer àqueles que são queridos; o que é, por outro lado, deixar de ser, digamos, mau humorado pelo outro? Ou introspectivo?

Diante de um colega em treino de arte marcial, faz sentido não ser agressivo naquele dia em que você está agressivo? O que é conversar com uma pessoa querida e se irritar com algo que você ouviu e então pensar "não vou me irritar porque me irritar é errado"?

Acredito que todo relacionamento possui uma dinâmica fraca ou forte em que o poder se alterna entre líder e liderado, entre aquele que é responsável pela saúde do relacionamento e aquele que é o "estagiário" da situação; especialmente entre as pessoas jovens, é ingenuidade acreditar que será possível encontrar um relacionamento que simplesmente "é", "funciona" e pronto.

Porém, é contraditório que se viva o tempo para construir o mundo constantemente; que a vida seja preenchida por um constante liderar da situação em direção ao que será, e ainda não é, a própria vida; isso é viver para o futuro. É como aquele que ganha dinheiro e guarda para, um dia, gastar; quando é esse dia?

Quanta sabedoria você acumulará até que chegue o dia em que você se permite se irritar quando você se irritar?

Esses questionamentos são insuportáveis, como todos os outros, na medida em que circularmente criticam justamente a atitude que os produz.

A muito tempo atrás eu disse a uma pessoa importante que eu era como se descreveu Kenshin Himura no Seisouhen OVA: uma espada sem bainha, nunca guardada, nunca descansando, sempre prestes a cortar em pedaços.

Às vezes eu penso que o que eu preciso é ser salvo de mim mesmo. Este pensamento é circularmente perfeito para uma pessoa cujo senso de importância está sempre focado no outro.

A Criação do Mundo

2008-09-29T20:37:00.000-03:00

Eu me pergunto se algum dia vou me cansar de criar o mundo e começar a viver nele...

Abstinência

2008-09-18T23:38:00.000-03:00

Por conta de um problema no estômago e adjacências, estou proibido de ingerir álcool por dois meses.

...

¬¬'

Graduação...

2008-08-19T23:06:00.001-03:00

Ah, gente boa, eu estou quase terminando o meu projeto... ^^'

Ah, família...

2008-08-17T23:44:00.001-03:00

Aniversário da Luísa nesse fim de semana.
Passei o fim da tarde de domingo com as meninas vendo vídeo e passeando no play.
Fazia tempo que eu não tinha oportunidade de brincar tanto com as meninas...

Tsubasa Reservoir Chronicle OST

2008-08-11T21:07:00.002-03:00

A trilha sonora de Tsubasa Reservoir Chronicle compete seriamente pela posição de trilha sonora mais bonita da história da televisão.

"you are my love", do disco Future Soundscape I, é linda demais.

Mas o ponto forte dessa trilha é de "a song of storm and fire". Essa música é certamente muito bonita, uma mistura de um canto bem lírico com uma faixa usando efeitos eletrônicos bem leves.

Mas é inexplicável o efeito que essa música tem quando você acompanhou a série como um todo. Essa faixa é a trilha de algumas das cenas de maior drama, onde a determinação do personagem Syaorang Li de lutar pela pessoa mais importante é posta a prova.

Este é um tema recorrente na série; ouvir a música e se lembrar da emoção correspondente é de arrepiar.

Acho que esta associação explica porque nós, fãs de anime, reagimos de maneira tão intensa à trilha sonora das obras que conhecemos.

Ah! Megami-sama

2008-08-06T01:12:00.001-03:00

Esse anime é tão bonitinho que eu não consigo me concentrar nos defeitos.
Está ótimo pra melhorar o meu humor nesses tempos de sinusite.

O Ser Solitário

2008-07-29T22:09:00.003-03:00

Acabei de descobrir a existência de um livro chamado The Loner's Manifesto.

"But just as Homo sapiens no longer needs prehensile toes, we no longer all need to be social animals in order to survive as a species. Mandatory social interaction is an evolutionary remnant which those who wish to may discard. The world has changed since barns needed raising."

As páginas seguintes continuam descrevendo diversas posições e relatos sobre o ser solitário. Em particular, na dificuldade que é ser solitário em sociedade.

Eu estava lendo hoje um artigo sobre uma ferramenta chamada Twitter. Esse negócio é o cúmulo da vida online: é um micro-blog onde você "posta" coisas como "saí pra lanchar" ou "bocejo".

Ao contrário do que a maioria dos meus conhecidos pode acreditar, eu não gosto de conversar pela Internet. A interação com as outras pessoas, pra mim, só é atraente quando é intensa. Acumulei centenas de contatos de ICQ, MSN, GTalk e afins ao longo de uma vida com o computador mas raramente tenho uma longa conversa online, na maioria das vezes com gente que está muito longe de mim.

Eu prefiro não ter qualquer conversa a ter uma conversa pela metade; pra mim uma conversa inclui olhar a pessoa, a maneira como ela se move, os olhos etc.

Além disso, conversar não é algo que eu tenha vontade de consumir a todo momento. Neste ponto, eu sou um solitário. Eu aprecio profundamente estar ao lado de uma pessoa em silêncio, como por exemplo ler um livro no quarto enquanto minha mãe ou minha irmã estudam. Existe um prazer todo especial em olhar para o teto e me perder em pensamento.

Eu não sei como isso funciona, e estou interessado em buscar pensamentos nesse livro, mas existe um grande prazer em se estar sozinho.

Zzz....

2008-07-24T00:12:00.000-03:00

E olha que eu não estou trabalhando tanto quantos uns caras por aí.

Casamentos

2008-07-07T00:25:00.001-03:00

Ser padrinho de casamento é complicado, bicho.
Você quer bem ao casal e acaba arrumando responsabilidade pra tudo que é lado.
Entre cartórios e festas de fim de solteirice foram-se meus próximos quinze dias.

Teenage Mutant Ninja Turtles

2008-06-29T23:36:00.001-03:00

Há algo de errado comigo? Ninguém achou esse filme irado. Acabei de ver, achei irado. Alguma coisa muito estranha aconteceu com o meu sangue nos últimos anos, está difícil achar alguma coisa ruim...

Schopenhauer já sabia?

2008-06-17T21:54:00.003-03:00

A muito tempo atrás, em uma discussão familiar sobre um imperativo qualquer, me ocorreu a dificuldade em diferenciar duas frases: "eu não quero", e "eu não quero".

Considere que alguém pergunte: você quer ir comer uma pizza?

Há um estado em que você pensa "putz, tudo menos pizza", no qual a resposta é: não.
Há um estado em que você pensa "sei lá, tanto faz", no qual a resposta é: não.

Na época, pensei que a diferença pudesse ser conduzida na ênfase:
eu não quero.
eu não quero.

Depois. pensei que um truque de entonação acrescentaria o significado com mais força:
eu não quero.
eu não... quero.

Não consegui fazer melhor sem acrescentar mais palavras.
É natural que algumas coisas não se expresse diretamente com um vocabulário finito qualquer; em inglês dizer "foi o azar" não é possível de maneira direta, porque não existe palavra em inglês para "azar".

Pois bem; em português eu acho que não há expressão que naturalmente signifique a ausência de vontade. Além disso, provavelmente por causa disso, assume-se constantemente no discurso uma vontade assertiva no outro; é uma dificuldade enorme comunicar a outra pessoa que você está ausente de vontade.

Outros tipos de ausência também são difíceis de comunicar. É uma tarefa diplomática considerável comunicar a uma pessoa que, apesar de sua comida não ser ruim, você na verdade não gostou dela. É praticamente inconcebível que uma pessoa possa dizer "eu não gostei" ao mesmo tempo que não acha a coisa ruim.

É provável que essa dificuldade seja compartilhada por todos os falantes de línguas derivadas do Latim, filhos da cultura européia. Os vazios são o forte dos orientais, e não dos ocidentais.

Pois bem. Com o passar do tempo, a expressão da vontade ganhou na minha mente um modelo em três partes; três idéias que se confundem sempre que se está falando sobre um imperativo qualquer, quando se está falando daquilo que se pretende fazer: eu desejo, eu necessito, eu posso.

Eu não tenho qualquer teoria sobre como estas três expressões seriam determinavelmente os três vetores que completamente descrevem o espaço da vontade humana; apenas me parece uma maneira curiosamente conveniente de modelar certos problemas da expressão. Situações em que se poderia encontrar o seguinte discurso:

-- Mas porque você está fazendo isso? Você não precisa fazer isso!
-- Eu não estou fazendo porque preciso, estou fazendo porque quero.

(Vou fazer um esforço para não tabular associações místicas entre essas três idéias e toda a profusão de três que há nos livros esotéricos.)

O modelo se baseia no significado natural dos três verbos: desejar, necessitar e poder. Todos esses três verbos comunicam um imperativo. É possível ordená-los por uma relação de força biológica; aquilo que você necessita impõe mais que aquilo que você meramente pode. Não acredito que essa ordenação seja mais importante que qualquer outra, exatamente porque somos homo sapiens organizados socialmente em uma civilização.

Uma ordenação como essas colocaria eu posso em um ápice da civilização; o momento em que os imperativos do corpo são postos em cheque com tal facilidade que o imperativo da mente se torna abordável. Dicotomias mente-corpo me interessam pouco, porém.

Meu interesse em um tal modelo surgiu através de situações em que a minha própria posição era incompreendida. Percebi que, pensando desta forma, eu era capaz de entender a mim mesmo posicionado principalmente em um dos três pilares enquanto o outro me procurava em algum dos outros dois.

É importante notar que o modelo não distingue as coisas que você quer entre coisas que você necessita, deseja ou pode ter; ele distingue as ações que você toma entre ações que você necessita tomar, ações que você deseja tomar e ações que você pode tomar. A diferença é sutil e ocorre entre a idéia de um modelo estrutural da idéi de um modelo comportamental.

Não sei se existe um modelo equivalente com quatro pilares; não consigo encontrar um verbo que seja fundamentalmente diferente desses três, nesse contexto.

Estou cansado, continuo depois.

Projeto Orientado a Componentes, parte IV

2008-05-08T14:57:00.006-03:00

Uma ligeira digressão, para aproveitar a oportunidade que se apresenta; apresentei esta semana um brevíssimo seminário sobre interoperabilidade entre C++ e Java (com ênfase na ferramenta SWIG).

O problema a resolver, quando a necessidade de interoperabilidade entre C++ e a Java surge, é exatamente um problema de projeto de componente, por uma via indireta: se não é tão necessária a garantia de substituição de componentes, é inescapável a completa separação entre a implementação do "componente C++" e do "componente Java" devido ao completo isolamento entre seus espaços de memória.

Esta mesma situação ocorre em um sistema convencional de componentes em que cada componente se localiza em processos distintos, ou mesmo em sistemas distintos, se comunicando através de algum mecanismo inter-processos. O próximo passo na escala evolutiva do projeto de sistemas, o projeto orientado a serviços, lida explicitamente com esta situação, já que se assume como normal que serviços se localizam em sistemas (portanto processos) distintos.

Esse contexto, e as restrições que ele impõe, transforma a natureza da troca de informação; a memória de um processo não é mais um recurso compartilhado entre rotinas.

Considere a seguinte função em C, parte de uma interface de componente IFoo. (O componente concreto Foo implementa a interface IFoo.)


  Foo*
  foo_retrieve_from_persistence (char* foo_name);

Esta função recebe uma NTBS identificando unicamente um objeto Foo na persistência e retorna o endereço do objeto Foo na memória, trazendo o objeto para a memória uma primeira vez se necessário.

Suponha que seja desejável, através de um programa Java, usar objetos Foo obtidos através desta função.

Do componente Bar, uma operação obtém uma referência a uma implementação de IFoo e decide chamar a operação foo_retrieve_from_persistence, passando como argumento uma NTBS. Observe que uma NTBS é uma referência a um espaço contíguo de memória; simplesmente entregar esse endereço para o componente Foo causará um desastre quando este componente resolver acessar esse endereço em seu próprio espaço de memória, cujo significado é incerto. Do mesmo problema sofre o valor de retorno da função; este é o endereço de um objeto na memória do componente Foo, cujo significado no espaço da memória de Bar é incerto.

Essa situação exibe a impossibilidade de tratar a semântica de referência, na travessia do limiar entre componentes, da mesma maneira como é tratada em projetos mais simples. Como já dissemos, não é possível assumir a memória como recurso compartilhado entre operações em um projeto orientado a componentes. [1]

A solução canônica é copiar esses valores. Esta tarefa deve ser realizado por aquele elemento do sistema que existe no umbral entre componentes e é responsável por transportar informação de um lado para o outro. Este elemento deverá, então, copiar todo o segmento de memória endereçado por foo_name da memória do componente Bar para a memória do componente Foo. Esta atividade se denomina "data marshalling" em um certo vocabulário e regras particulares de "data marshalling" são chamadas "type maps" em um certo outro vocabulário.

Este é um exemplo simples de "type map" que transporta um objeto String do Java para um argumento de tipo const std::string& do C++.


  // na prática, estes objetos são argumentos de uma função JNI.
  extern JNIEnv* jenv;
  extern jstring jargN;

  // type map
  const char *argN_pstr = (const char *)jenv->GetStringUTFChars(jargN, 0);
  if (!argN_pstr) return 0;
  std::string argN_str(argN_pstr);

A função GetStringUTFChars realiza a tarefa concreta de copiar os segmentos de memória do espaço de memória Java para o espaço de memória C++. Assim, a operação da interface de componente Java/JNI terá a seguinte forma:


  public static native jlong foo_retrieve_from_persistence (String foo_name);

Essa solução, infelizmente, não resolverá o problema do valor de retorno da função. Foo não é um tipo primitivo da linguagem; não existe uma função na JNI para copiar objetos Foo. Mesmo que existisse, Foo é um objeto; o que nós queremos fazer com ele é chamar suas operações. De certa forma, nossa vontade se divide em duas: expor ao programa Java as operações da classe Foo e expor ao programa Java objetos Foo sobre o qual operar. Essas duas necessidades serão resolvidas com mecanismos diferentes.

Digamos que esta seja a classe Foo.


class Foo {
public:

    Foo (char* name);

    char*
    ask_question (char* question);

    char*
    get_name () const;

};

A primeira vontade é realizável produzindo, para cada operação de Foo, uma operação na interface do componente IFoo.


    Foo*
    Foo_new (char* name);

    void
    Foo_delete (Foo* foo);

    char*
    Foo_ask_question (Foo* foo, char* question);

    char*
    Foo_get_name (const Foo* foo);

A segunda é entregando ao programa Java o endereço do objeto Foo necessário. Chegamos, aparentemente, a um impasse; já que nosso problema original era justamente como transportar o valor de retorno da função foo_retrieve_from_persistence, que é do tipo Foo*! Porém, tendo caminhado até aqui, o problema se torna ligeiramente diferente, e uma solução é possível. Agora que nós temos todas as operações de Foo que desejamos exportadas pela interface de componente IFoo, tudo o que resta é entregar ao componente cliente uma referência opaca a um objeto Foo. O componente cliente da interface nunca necessitará resolver (ou de-referenciar) esta referência; ele apenas mantém este valor para usá-lo como argumento de chamada a uma operação da interface IFoo. [2]

Endereços de memória do C++ podem ser guardados apropriadamente na memória do Java como um valor do tipo Long. Assim, o valor de retorno da operação Foo_create é resolvido pelo seguinte "type map":


  // este é o objeto retornado pela chamada JNI
  jlong jresult = 0;
  // este é o objeto retornado pela função C++
  Foo* result = NULL;

  // type map
  result = new Foo(arg1_str); // vide type map anterior
  *(Foo **)&jresult = result;

  // por fim...
  return jresult;

e a operação na interface de componente Java/JNI terá a seguinte forma:


  public static native jlong Foo_create (String name);

Assim, o programa Java chamador de Foo_create através desta interface receberá um valor Long que contém o endereço, na memória do C++, do objeto Foo recém-criado. A operação Foo_get_name através desta interface terá a seguinte forma:


  public static native String Foo_get_name (jlong foo);

sendo que o valor de retorno da operação Foo_get_name do componente IFoo será "marshalled" pelo "type map" como já vimos anteriormente.

Havendo resolvido o problema da possibilidade de referenciar, de maneira opaca, um objeto Foo da memória do C++ na memória do Java, e o problema de chamar operações da classe Foo em C++, podemos então criar uma classe Foo em Java cujo único propósito é imitar a classe Foo em C++ por conveniência.


class Foo {

  private Long cPtr;

  // @Override
  public void finalize () {
    delete();
  }

  public void delete () {
    IFooJNI.Foo_delete(cPtr);
  }

  public Foo (String name) {
    cPtr = IFooJNI.Foo_new(name);
  }

  public String ask_question (String question) {
    return IFooJNI.Foo_ask_question(cPtr, question);
  }

  public String get_name () {
    return IFooJNI.Foo_get_name(cPtr);
  }

};

Desta forma concretizamos uma forma ideal de interoperabilidade entre Java e C++ onde, para cara classe C++, há uma classe Java equivalente, responsável por esconder as chamadas à interface de componente JNI que, por sua vez, é responsável por realizar o transporte de informação através do umbral dos componentes.

Nestes exemplos ocultamos o fato de que, para a JNI, é necessário não somente um componente Java/JNI mas também um componente C++/JNI além do próprio componente que implementa a interface IFoo; também não lidamos com os casos em que registramos "objetos callback" criados no Java em sistemas C++; não lidamos com a vontade de transportar exceções disparadas em C++ de volta para o chamador Java; entre outras coisas de que não falamos.

[1] É claro que um projeto pode se utilizar da noção de componentes de uma forma restrita, para obter um conjunto restrito de benefícios, abandonando esta restrição; é possível, por exemplo, obter os benefícios de recompilação veloz e carga de código por demanda abandonando a possibilidade de distribuir os componentes de modo a mantê-los sempre no mesmo espaço de memória e permitir o uso convencional de ponteiros.

[2] Em projetos de sistemas com componentes é comum que esta idéia do "endereço opaco" seja generalizada para qualquer tipo de informação "opaca" que seja capaz de identificar univocamente um objeto de Foo no domínio do componente Foo; por exemplo, um "nome", ou um GUID, ou outra coisa qualquer.

Projeto Orientado a Componentes, parte III

2008-04-29T22:57:00.006-03:00

Agora, uma pausa para reflexão. Esta dicotomia interface versus implementação é difícil de definir. Por baixo dos panos nós temos memória de onde nós lemos e para onde nós escrevemos. O que caracteriza uma interface e o que a distingue de uma implementação?

Essa pergunta só pode ser respondida em um determinado contexto. Um bom sistema escrito em assembler talvez tenha interfaces mais bem definidas que um mau sistema escrito em Java. Porém, está claro para a indústria que certos mecanismos de linguagem favorecem o estabelecimento de boas interfaces no sistema implementado.

Além disso, a noção de interface surge diante de um problema de substituição. É interface aquilo que, mantendo-se estável, permite a substituição daquilo que é implementação. Porém, o que é este permite? Este permite, quando caracterizado, por conseguinte caracteriza o que é interface.

Suponha um sistema escrito em C++ por uma equipe que considera irrisório o tempo de recompilação do código-fonte. Neste contexto, podemos seguramente aceitar que a seguinte substituição mantém estável uma interface.

antes


class Foo {
public:

Foo ();

void
mutate_stuff ();

int
observe_stuff () const;

private:
Bar* m_bar;
};

depois


class Foo {
public:

Foo ();

void
mutate_stuff ();

int
observe_stuff () const;

private:
int m_cache;
shared_ptr<bar> m_bar;
};

Após a alteração acima e uma recompilação o sistema continua a funcionar normalmente. [1] Dizendo de forma mais extensa: neste contexto, a substituição realizada não altera propriedades observáveis externamente da classe, de modo que do ponto de vista de um observador, a classe mantém estável sua interface. (Apenas membros privados foram alterados.)

Agora vamos alterar as nossas premissas. O tempo de recompilação desse sistema é enorme e o ciclo de testes não pode esperar, de modo que a estrutura de classes do sistema foi particionada e esta classe mora dentro de um objeto compartilhado, uma biblioteca dinâmica.

A equipe realiza a substituição, recompila o objeto compartilhado e o entrega a uma equipe de testes.
E os testes falham miseravelmente.

Isto acontece porque, neste novo contexto, há mais propriedades observáveis a considerar, que devem se manter estáveis -- que fazem parte da interface da classe.
Neste caso, o layout de um objeto da classe Foo é uma propriedade observável; um programa compilado criando objetos da definição antes criará objetos com um layout diferente daquele esperado pelo objeto compartilhado que espera objetos dada a definição depois.
A definição depois tem um int no offset onde a definição antes tinha um ponteiro, ela ocupa mais memória etc.

Podemos dizer que o primeiro caso é o caso de um projeto orientado a objetos, onde a alteração de elementos privados da classe não altera a interface; e podemos dizer que o segundo caso é o caso de um projeto orientado a componentes, onde a alteração do layout na memória de uma classe altera sua interface.

Como no segundo caso nós estamos violando a interface do componente, nós não podemos substituir o componente de antes pelo componente de depois impunemente. Dito de trás para a frente, pelo fato de não podermos substituir o componente de antes pelo componente de depois, por definição estamos violando sua interface.

Imagine então o que acontece em um sistema spaghetti, onde todas as classes mantém referência a todas as outras classes; uma violação de interface em um "componente" perturbará implacavelmente todos os outros "componentes".

Quando projetamos um sistema pensando em componentes, ou quando desejamos aplicar a idéia forte de interface para melhorar o nosso projeto diminuindo o acoplamento entre as coisas que são distintas, é útil usar das ferramentas à disposição para dar forma ao que é uma interface.

Linguagens que se propõe a facilitar o desenvolvimento de componentes, como Java e C#, possuem como parte integrante do seu vocabulário e mecanismo nativo uma interface em contraste com as classes. Normalmente algo do tipo:


interface IFoo {

void
mutate_stuff ();

int
observe_stuff () const;

};

Em C++ não existe uma construção análoga mas é possível emulá-la integralmente usando classes, da seguinte maneira:


class IFoo {

virtual
void
mutate_stuff () = 0;

virtual
int
observe_stuff () const = 0;

};

(O leitor astuto observará que esta construção-interface não possui atributos.)

O propósito de usar construções como estas é evidenciar a natureza destes elementos como interfaces -- aquilo que se deseja manter estável -- e diminuir a chance disto que é interface ser inadvertidamente alterado -- causando o desastre. A construção-interface é a melhor amiga do projetista de componentes, permitindo a representação de um conceito de projeto diretamente na linguagem do código-fonte, restringindo as possibilidades de violação durante o processo de implementação, ou ao menos tornando a (necessidade de) violação claramente evidente.

Infelizmente para nós nem tudo que existe na fronteira de um componente pode ser uma interface, já que é preciso comunicar coisas de um componente para outro. E quem pode viver comunicando apenas doubles e bools? Nós queremos comunicar objetos.

Além disso, as construções-interface não são garantia de estabilidade de interfaces, já que há mais sobre o que é publicamente observável em um objeto que sua estrutura: há o seu comportamento.

[1] Estamos, naturalmente, assumindo que o programador não é louco e que a alteração tem algum sentido, exatamente como aparenta ter.

Projeto Orientado a Componentes, parte II

2008-04-28T22:36:00.005-03:00

Quando dizemos que componentes são por definição intercambiáveis estamos continuando uma longa tradição de bons projetistas de bons sistemas, cujo conjunto de características sempre integrará, por mais sofisticada a metodologia e/ou a nomenclatura, a aplicação da separação entre interface e implementação. [1]

Se a interface continua a mesma, podemos substituir a implementação sem perturbar o comportamento do sistema. Obviamente que o comportamento do sistema deve mudar de alguma forma, senão trocar a porcaria do componente não teria propósito. Esperamos, portanto, que erros sejam corrigidos (de modo que o sistema de fato funcione como deveria), ou que o desempenho aumente (de modo que o sistema funcione antes que eu caia no sono) ou sei lá.

Aplicávamos esta distinção já na era do projeto estruturado; e no projeto essencial; e no projeto orientado a objetos; e agora no projeto orientado a componentes e aplicaremos no projeto orientado a serviços quando finalmente este troço alcançar a plebe.

Em um sistema orientado a objetos, nós temos tipicamente dois elementos em evidência como detalhe de implementação: a estrutura de um objeto, e as instruções levadas a cabo por seus métodos. Nós queremos liberdade para alterar a estrutura de um objeto e queremos liberdade para alterar a instruções executadas por seus métodos. (Há mais por debaixo do pano, como sempre.)

Em um sistema orientado a componentes, um terceiro elemento surge ofuscando, como se fosse, os outros dois; o componente propriamente dito. Entendemos que um componente possui uma interface e uma implementação; sendo a implementação de um componente composta por inúmeras classes. Além disso, um componente é um artefato componente (heh) de um sistema implantado; é parte da definição de componente que este seja intercambiável por um outro, que implemente a mesma interface, em um sistema implantado -- em contraste com um tipo de substituição que exige recompilação.

Esta última restrição, quando posta no contexto dos sistemas operacionais reais, com seus linkers e loaders reais, nos trás à crux do problema de projeto orientado a componentes: a implementação de uma classe integrante de um componente absolutamente não pode depender de um detalhe de implementação de uma classe integrante de outro componente.

Observe que esta restrição não é exatamente uma novidade, já que bons sistemas isolarão módulos através de interfaces para aumentar a coesão e diminuir o acoplamento; porém, quando componentes entram na jogada, a metodologia exige uma restrição mais forte.

(De fato, esta restrição metodológica se torna uma impossibilidade tecnológica assim que os componentes são levados ao próximo estágio, passam a não mais morar no mesmo espaço de memória virtual, e começam a ser chamados "distribuídos" ou "serviços".) [2]

É por esta razão que os líderes do Projeto Spaghetti falharão em "componentizar" seu sistema; mesmo que, à primeira vista, seja possível seccionar sua estrutura de classes em artefatos binários distintos.

[1] Nós, filhos da cultura européia, nem escrevendo programas nos livramos da dicotomia corpo versus espírito. Nem imagino o que seria uma metodologia de desenvolvimento de sistemas desenvolvida por monges taoístas chineses.

[2] E portanto, domar a restrição metodológica significa poder conviver com a impossibilidade tecnológica e eventualmente programar os sistemas do futuro.

Projeto Orientado a Componentes, parte I

2008-04-28T21:34:00.002-03:00

Ano passado fiz um curso de extensão em Projeto Orientado a Componentes com UML; na época, eu estava progredindo na minha capacidade de construir modelos mentais de projetos de software orientados a objeto e já havia lido bastante sobre web services e arquiteturas orientada a serviços.

O mais interessante sobre os Componentes é a maneira como eles dão um nó na sofisticação aparente dos sistemas e obrigam o projetista a voltar aos básicos. Digo isso porque estes sistemas são aparentemente sofisticados; na prática, eles apresentam baixa coesão e alto acoplamento, significando que elementos deste sistema se relacionam diretamente com praticamente todos os outros de maneira ad hoc, fenômeno que, em sua forma mais concreta, denomina-se código spaghetti.

É possível construir um sistema orientado a objetos onde todos os objetos conhecem ponteiros para todos os outros, ou praticamente todos os outros, usando truques safados como embrulhar todo mundo em shared_ptr e tornando todas as classes enable_shared_from_this e olerê olará. Isto, é claro, se você tem um mínimo de conhecimento sobre C++ contemporâneo -- e se você está de fato escrevendo seu sistema em C++! -- e se você se importa com a memória. O sistema acima é "orientado a objetos". Muitos deles, embolados entre si.

Quando você se propõe a fazer sistemas orientados a componentes, porém, o buraco se alarga e se torna mais profundo. Os componentes existem com o propósito de serem intercambiáveis. Você não tem componentes se você não pode tirar um deles e colocar outro no lugar impunemente.

Frequentemente, os responsáveis por sistemas spaghetti ou aberrações similares, diante dos problemas insuportáveis causados inevitavelmente pela baixa coesão e pelo alto acoplamento, tentam "componentizar" seus sistemas com o intuito de obter os benefícios maravilhosos oferecidos pelos livros.

Vamos, então, pegar pedaços do sistema e enfiar dentro de DLLs!

Certamente isto não funciona.

Pitty

2008-04-24T22:38:00.002-03:00

Pitty.
Eu estou ouvindo Pitty.
A semana inteira.
Obsessivamente.

Eu herdei a máquina de um sujeito no trabalho, tem uma pasta "Música" cheia de tralha.
Tem até o "Canto para Minha Morte", do Raul, que eu nunca consegui achar.

Meu player saiu do "Pink Floyd" e entrou em "Pitty".
É impressionante.
Eu não consigo parar. :-(

A banda é razoável e a música é aquele rockzinho[tm] razoável; mas a minha pira é com o que ela diz nas músicas. Não é nada demais; por outro lado... Não sei que porra de fase é essa em que eu entrei. Deve ser o que as pessoas sentem lendo livros de auto-ajuda.

Televisão Digital

2008-04-19T08:31:00.002-03:00

Pra quem ainda não sabe, eu dei uma saidinha da indústria da segurança, e estou agora trabalhando com a televisão digital.
Essa semana cumpri minha primeira meta e construí uma aplicação para o set top box capaz de controlar o playback de vídeo.

As capacidades do set top box são muito legais.
A televisão digital será um brinquedo muito maneiro.
Falta pouco pra chegar ao consumidor.
E todos rodarão meu software em casa. :-)

para Sofia sobre kung fu

2008-04-13T22:05:00.004-03:00

2008-03-??

Sofia-chan,

hoje no treino coletivo do mo kwoon tive a oportunidade de ver um si dai treinando com seu próprio si dai.
[Nota: mo kwoon é o local de treino de artes marciais; si dai é um irmão mais novo entre os irmãos kung fu.]

Este si dai si hing, coitado, deu um pouco de pena; atrapalhado com a responsabilidade, parecia mais encenando uma peça de teatro que treinando artes marciais.

A dificuldade que eu observei está na vontade de ensinar uma determinada coisa e então construir uma situação onde isso é possível. Isto é, eu quero falar sobre isso, portanto você deve se posicionar de acordo para que o que eu estou dizendo seja fundamentado.

Há pouco kung fu nessa atitude. Esse constante "faz assin, agora faz assado, agora acontece como eu digo" me parece uso de ba lek nesse contexto. A ferramenta do aprendizado, chi sao, é suficiente para que as questões surjam naturalmente do resultado das ações.
[Nota: ba lek é a força aplicada contra a natureza das circunstâncias; chi sao é o treino de combate simbólico do Ving Tsun, onde os dois braços se põe em contato.]

Eu acho que é desnecessário ensinar qualquer uma coisa em particular, e acho que isso se torna cada vez mais evidente com a progressão dos níveis. Aquilo que é importante para cada um é guia suficiente para a introdução dos elementos do sistema de kung fu. A própria pessoa, diante da dificuldade, bem, terá uma dificuldade; o desejo de transpô-la é suficiente para direcionar a sessão de treino aos elementos necessários.

Esse pensamento pode, de certa forma, contradizer a forma sistêmica de transmitir o kung fu -- ou talvez de desencorajá-la ou diminuir o seu valor.

Eu não entendo as coisas dessa forma; entendo que o próprio sistema é um elemento proposto como solução na discussão que naturalmente segue à aproximação do indivíduo e da família kung fu.

Quando o indivíduo aborda a família kung fu, ele tem um problema, um propósito; que seja obter a capacidade de lutar. Dado isto, é natural que o sistema seja apresentado e que o indivíduo ingresse na família.

Mas quem irá parar um estranho na rua para dizer que o problema dele se resolve com Ving Tsun? Isso é tolice. Da mesma forma, no chi sao não se deve parar o si dai para discursar sobre um problema que ele ainda não tem -- ou melhor, para um problema que ainda não ocorreu a ele.

Há um contraponto, no meu pensamento, entre a estase e a dinâmica do kung fu em um praticante, no tocante ao seu desenvolvimento. É natural, e indiscutível, que um si hing cuja responsabilidade é de estimular o chi sao do si dai não deve simplesmente aceitar a situação totalmente como é -- da mesma forma como ele busca melhorar o próprio kung fu, ele busca estimular o kung fu do si dai. Mas isso não é contraditório? Estimular é intencionar que o objeto mude. Como você pode permitir que uma pessoa seja como ela é mas estimulá-la a mudar?

Uma forma de resolver este dilema é buscar no indivíduo o que é sua essência e o que é mero comportamento decorrente de uma história de vida -- talvez. Eu acho perigoso fragmentar o indivíduo desta forma e resolvo na prática este dilema agindo de acordo com a intuição. Eu admito que, apesar de tudo, resta no processo de aprendizado uma atitude fundamental do tipo: você é bom como você é em quase sua totalidade exceto... nisto. Acredito que, do ponto de vista de quem transmite o kung fu, o que a pessoa é não importa, ou, é sempre aceitável; como ela se comporta pode melhorar.

Para nossa família kung fu a natureza desse "pode melhorar" é clara: melhorar é expressar a si mesmo com melhor posicionamento, melhor distância, melhor timing, melhor energia. Além disso, melhor não é mais, melhor é justo; o tanto quanto necessário para realizar sua vontade.
[Nota: timing é timing.]

O que é a vontade do indivíduo é algo intocável pela crítica; não faz sentido dizer ao outro que ele não deve querer o que ele quer. Este fato escapa a muitos processos didáticos, infelizmente. O impulso de impor ao outro uma forma para o seu mundo é natural ao homem; ele é inescapável de certa forma, ao bicho que se comunica de forma tão sofisticada como nós.

Quando nós falamos, nós entregamos ao outro a forma da nossa mente, a estrutura do nosso mundo. É natural que, então, a forma da mente do outro, seu mundo, se ponha a perigo de transmutação. Mesmo a mais singela apresentação de um fato isolado -- uma experiência sensorial! -- apresenta um elemento potencialmente desestruturante, reestruturante. Que dirá um contra-ponto, uma contradição.

chi sao é como o debate dos corpos; esta é a minha estrutura, esta é a sua estrutura, o que acontece quando estas coisas são postas em contato? Apenas esta atitude inicial é suficiente para prover todas as condições necessárias ao aprendizado.

O debate, infelizmente, não possui o tipo de ligação com o corpo que o chi sao tem, de modo que muitas "vitórias" em debates são... ilegítimas, para dizer o mínimo. O ba lek, e como lidar com ele, é uma arte que não sei onde aprender, nesse contexto.

Sei que o Ving Tsun me habilitou a construir minha própria arte e só.

Projeto: Eclipse + CppUnit

2008-04-06T19:24:00.003-03:00

Estou prestes a apresentar para o ccppbrasil.org um projeto de integração da CppUnit com o Eclipse TPTP.

Será uma oportunidade interessante de aprender a desenvolver sobre a plataforma OSGi e uma maneira de estimular a comunidade a aplicar as técnicas de testes de unidade.

A arquitetura do TPTP Test é assim: para um determinado "tipo de teste" registra-se um adaptador de implantação, um adaptador de ambiente e um adaptador de execução, bem como um runner para este "tipo de teste" no agente remoto.

A tarefa será implementar esses adaptadores para programas executáveis nativos e bibliotecas compartilhadas, resolvendo LD_LIBRARY_PATH e assuntos relacionados, depois implementar uma biblioteca de suporte em C para que programas joguem na saída padrão o histórico de execução da forma correta e por fim implementar com um wrapper Java um runner para suites de teste CppUnit na forma de plug-in.

Na verdade as tarefas ainda estão se abrindo porque não consegui dominar o problema de projeto completamente, o que me aborreceu um pouco, já que vou passar a semana ocupado com outros assuntos.

Encontro de Nerds em São Paulo

2008-04-02T23:29:00.003-03:00

Ora, aqui estamos nós!
O Encontro foi muito bom, evoluindo o formato do anterior.
Os nerds são inteligentes e conhecedoras das coisas, e bebem bastante cerveja e são engraçados demais.
Nosso trabalho continua no site ccppbrasil.org.

Quarto Encontro CCPP Brasil

2008-03-29T06:18:00.003-03:00

Cheguei há pouco na rodoviária de São Paulo.

Entrei em uma lan house pra anotar os endereços de que eu precisava. ¬¬

Cheguei cedo demais aqui; o ônibus fez a viagem em cinco horas e meia.
A turma só vai acordar depois das 07h, provavelmente às 08h.

Vou passar o tempo comendo e fumando.

Desta vez vou ficar hospedado no Formule One Jardins.
A estação de metrô da vez é Trianon-Masp.
Pra facilitar a minha vida comecei este mapa com marcadores para as estações do metrô.

OpenMP

2008-03-24T11:17:00.003-03:00

Reavaliar as hipóteses vigentes é sempre interessante quando você já possui alguma experiência; um retorno à "infância" do aprendizado, talvez, a uma época em que a sua sensação de segurança era mínima.

Acrescentar uma anotação tão singela quanto:

#pragma omp parallel

causou um desastre tremendo em um loop pequenininho dentro de pixman-mmx.c nesse fim de semana, experimentando com o André um novo caminho de otimização.

Se o seu compilador implementa OpenMP a diretiva acima transforma o bloco do loop seguinte de modo a despachar iterações individuais a um time de threads de trabalho.

Quando a hipótese de que uma iteração será seguida de outra some dependências entre acessos a dados surgem: enquanto uma iteração lê um endereço outra iteração escreve nesse enredeço, boom. Experimentamos muitos SIGSEGV com este loop. Eventualmente a implementação foi transformada de modo a eliminar essas dependências.

É interessante que se você não tem em mente essa questão não se dará ao trabalho e seus loops não terão iterações independentes. Porém, mesmo sem OpenMP, o GCC 4.3 produziu uma melhoria impressionante na execução deste código; certamente porque seus otimizadores aproveitaram novas oportunidades oferecidas por iterações livres de side effects observáveis.

ccppbrasil.org

2008-03-15T13:06:00.001-03:00

yo! _o/

argh!

2008-03-12T17:20:00.003-03:00

Acabei de perceber que estou a dias escrevendo em um dos blogs antigos ainda disponíveis pra mim no painel do Blogger.

O que vocês perderam nos últimos dias?

Fiz escalada pela primeira vez, na via MM do morro da Babilônia.

Estarei novamente dia 29 em São Paulo, parte da organização do Quarto Encontro de Programadores de C e C++ do Brasil.

Estou, após uma longa volta pelo Centro do Rio de Janeiro, de volta à rua da Assembléia, para trabalhar na Quality Software com a televisão digital.

Vou ser papai.

...

okay, essa última é mentira.

De volta às origens

2008-03-12T17:14:00.000-03:00

Depois de alguns anos perambulando pelo Centro do Rio de Janeiro, estarei em Abril de volta à rua da Assembléia.

lar, doce lar.