Tumulto

A Habilidade da Lentidão

noreply@blogger.com (P.) — Tue, 17 Nov 2009 00:45:00 +0000

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++

noreply@blogger.com (P.) — Fri, 13 Nov 2009 13:55:00 +0000

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

noreply@blogger.com (P.) — Thu, 12 Nov 2009 18:15:00 +0000

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

noreply@blogger.com (P.) — Mon, 09 Nov 2009 12:03:00 +0000

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

noreply@blogger.com (P.) — Tue, 03 Nov 2009 21:55:00 +0000

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

noreply@blogger.com (P.) — Thu, 29 Oct 2009 17:13:00 +0000

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?

noreply@blogger.com (P.) — Tue, 20 Oct 2009 01:02:00 +0000

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

noreply@blogger.com (P.) — Sat, 17 Oct 2009 19:36:00 +0000

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

noreply@blogger.com (P.) — Thu, 24 Sep 2009 14:29:00 +0000

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

noreply@blogger.com (P.) — Fri, 18 Sep 2009 20:27:00 +0000

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

noreply@blogger.com (P.) — Thu, 03 Sep 2009 01:44:00 +0000

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

noreply@blogger.com (P.) — Tue, 01 Sep 2009 00:21:00 +0000

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

noreply@blogger.com (P.) — Wed, 26 Aug 2009 00:30:00 +0000

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

noreply@blogger.com (P.) — Fri, 21 Aug 2009 17:10:00 +0000

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

noreply@blogger.com (P.) — Tue, 18 Aug 2009 14:06:00 +0000

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

noreply@blogger.com (P.) — Mon, 17 Aug 2009 17:12:00 +0000

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.

noreply@blogger.com (P.) — Tue, 11 Aug 2009 13:58:00 +0000

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

noreply@blogger.com (P.) — Mon, 10 Aug 2009 18:48:00 +0000

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++

noreply@blogger.com (P.) — Sat, 08 Aug 2009 16:55:00 +0000

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

noreply@blogger.com (P.) — Thu, 06 Aug 2009 19:18:00 +0000

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

Sigyn: componentes genéricos para networking

noreply@blogger.com (P.) — Sat, 01 Aug 2009 03:47:00 +0000

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

noreply@blogger.com (P.) — Tue, 28 Jul 2009 16:01:00 +0000

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

noreply@blogger.com (P.) — Fri, 03 Jul 2009 21:00:00 +0000

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!

noreply@blogger.com (P.) — Fri, 03 Jul 2009 13:40:00 +0000

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

Terra e

noreply@blogger.com (P.) — Thu, 14 May 2009 04:24:00 +0000

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