Tumulto

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.

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.

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.

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.

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.

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.

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?

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.