Elmord's Magic Valley

Software, lingüística, mitologia nórdica e rock'n'roll

FISL 16

2015-07-11 23:27 -0300. Tags: comp, life, freedom

Nos últimos quatro dias ocorreu o 16º Fórum Internacional do Software Livre. Minha proposta de palestra sobre o lash não foi aceita (o que por um lado foi bom, porque o projeto anda meio dormente devido a obrigações mestrariosas e má administração temporal), mas eu assisti uma porção de palestras, a maioria das quais foram bem boas. Também encontrei o Marcus Aurelius por lá, que trabalhou como voluntário na tradução do site do FISL para o esperanto, e troquei umas palavras com seu Lucas Zawacki, que estava no espaço do Dumont Hackerspace (e que ganhou a Hackathon EBC/FISL 16 com o aplicativo Pautaí, por sinal; congrats!).

Eis um resumo das palestras que eu assisti por lá. O site do FISL contém a programação completa, com link para os vídeos da maioria das palestras.

Dia 1

Email criptografado: usando GPG e icedove para criptografar sua correspondência, por Felipe Cabral

A idéia era que fosse uma oficina, mas acabou sendo mais uma palestra sobre conceitos básicos de PGP. Também foi visto um programinha chamado Seahorse (pacote seahorse no Debian) para gerar e administrar chaves de PGP e afins. Eu fui na palestra achando que ia aprender alguma coisa que me ajudasse a fazer o PGP funcionar no Claws Mail. Turns out que no Thunderbird/Icedove, tudo o que é necessário para fazer o PGP funcionar é instalar o add-on Enigmail (pacote enigmail no Debian), seguir os passos de configuração que serão apresentados depois que o Enigmail é instalado, e ser feliz. Me deu até vontade de experimentar o Thunderbird de novo, mas tem que ver isso aí. Meanwhile, continuo unenlightened quanto ao Claws.

Half my life with Perl, por Randal Schwartz

O autor do Programming Perl (a.k.a. Camel Book), entre outros, e atual host do podcast FLOSS Weekly, conta sua vida e seu envolvimento com o Perl. Foi uma palestra bem interessante, mesmo eu não conhecendo grandes coisas do Perl e sua comunidade.

Negócios em Software Livre, isso existe?, por Vagner Fonseca

Uma palestra sobre como ganhar dinheiro vendendo serviços baseados em software livre para empresas, tais como suporte, customização de programas livres de acordo com as necessidades da empresa, soluções de monitoramento de rede e de uso de recursos, entre outros. Também foram discutidos tipos de contrato (por projeto, por hora, contrato de suporte) e quando cada tipo vale a pena (basicamente, cobrar por projeto só vale a pena para coisas bem simples e punctuais, caso contrário corre-se o risco de algo demorar muito mais do que o previsto e o cidadão acabar efetivamente pagando para trabalhar; em contrato de suporte se cobra menos do que em um contrato por hora, mas tem-se a estabilidade e se consome um tempo mais limitado por semana em uma empresa, então é possível atender mais de uma ao mesmo tempo), entre outras coisas.

"Enemy spotted - Applying infovis at security field", por Felipe Afonso Espósito

Uma palestra sobre visualização de dados e como isso pode ser usado com dados de segurança. Não tenho muito mais o que comentar.

Let's Encrypt: Uma Autoridade Certificadora Gratuita e Automatizada, por Seth Schoen

Seth Schoen, membro da EFF, falou (em português!) sobre o andamento do Let's Encrypt, uma iniciativa da EFF, Mozilla, University of Michigan e outros para criar uma autoridade certificadora e um mecanismo para obtenção e validação automática e gratuita de certificados digitais, e instalação automática em servidores web, eliminando uma barreira que existe atualmente para se usar HTTPS. A data prevista para o serviço ser disponibilizado para o público é 14 de setembro deste ano.

Eu pretendia assistir a APIs em Tempo Real Usando Websockets em PHP, mas a sala lotou e eu não cheguei a tempo. Ao invés disso, eu e o Marcus ficamos tentando entender as entranhas do cua-mode do Emacs, inter alia.

Dia 2

Encontro de Hackers GNU

Alexandre Oliva (FSF Latin America), Felipe Sanches, e Deborah Anne Nicholson (Open Invention Network, MediaGoblin) falaram sobre uma porção de projetos relacionados com liberdade digital. Entre eles, o Twister, uma plataforma peer-to-peer de microblogging, e MediaGoblin, uma plataforma descentralizada de compartilhamento de mídia. Também foram mencionadas algumas idéias de projetos que seriam interessantes de criar, como uma plataforma peer-to-peer para distribuição de código (eu mencionei que já existe um projeto nesse sentido).

Outra idéia interessante que o Alexandre Oliva mencionou é que os ambientes computacionais modernos são pouco programáveis (sounds weirdly familiar), e que seria interessante criar uma biblioteca que facilitasse para o usuário descobrir que funções o programa chama quando se clica em algum botão ou menu e tornasse esses programas programáveis. O conceito é parecido com o que eu vejo como ideal de ambiente computacional, mas eu nunca tinha pensando em pôr essa funcionalidade em uma biblioteca, ao invés de algo mais fundamental. É uma abordagem interessante de se pensar.

O Felipe Sanches também comentou a questão de firmware aberto, as dificuldades envolvidas em reverse-engineering de firmware e hardware, e a necessidade de incentivar o compartilhamento de informação sobre técnicas de engenharia reversa.

Programação Orientada a Objetos em C puro: o caso do htop, por Hisham Muhammad

O autor do htop falou sobre as técnicas de programação que usou no desenvolvimento desse programa, em particular o uso de orientação a objetos em C. Eu já sabia um pouco sobre o assunto, mas a palestra valeu a pena mesmo assim. Mais para o final, o Hisham falou sobre o uso de collections para gerenciar "ownership" de ponteiros (alocação e liberação de memória) em C, e como isso torna a gerência manual de memória do C menos horrível de se usar. Por fim, ele falou sobre o dit, um editor de texto que ele escreveu reusando componentes do htop.

Assinatura digital e o padrão ICP-Brasil, por Paulo Cesar Barbosa Fernandes

Uma palestra sobre o padrão brasileiro de assinaturas digitais, seus aspectos legais, e algumas informações gerais sobre o uso de assinaturas digitais. Talvez a coisa mais importante que eu aprendi na palestra é que uma assinatura digital obtida adequadamente seguindo o padrão ICP-Brasil tem o valor legal de uma assinatura de papel (embora ainda haja legislação a ser atualizada para levar isso em conta).

Desvendando o IPv6: Tecnologia indispensável para o Futuro da Internet, por Lucenildo Lins de Aquino Júnior

Nada muito aprofundado tecnicamente, mas foi uma boa palestra. O mais surprising aqui foi saber que uma boa parte do tráfego da Internet já é em IPv6, inclusive no Brasil (pelo menos em São Paulo), mas não lembro mais os números. Até me deu alguma esperança de que teremos o bendito IPv6 em alguns anos.

What's new in systemd in 2015, and what's coming in 2016, por Lennart Poettering

Exatamente o que o título diz. Foram mencionadas funcionalidades de configuração de rede, resolução de DNS, containers, e todas essas coisas que nós nos perguntamos se deviam mesmo fazer parte do systemd, mas isso fica para outra discussão.

Finding a Great Project to Work On, or Great People to Work on Your Project, por Deborah Anne Nicholson

Uma palestra muito boa sobre, entre outras coisas, como fazer com que um projeto seja "welcoming" a novos colaboradores, especialmente não-desenvolvedores (pessoas envolvidas com tradução, documentação, divulgação, arte, etc.). Alguns dos tópicos mencionados são coisas que deveriam ser senso comum, mas infelizmente não são, tais como ter uma descrição de o que é o projeto na página inicial, links para mailing lists, FAQs, informação de contato, etc. Outro ponto mencionado é que se você como desenvolvedor não tem grandes skills comunicativos, encontre uma pessoa para fazer esse papel no seu projeto. Also, incentive e recompense os esforços dos colaboradores. Provavelmente é melhor assistir o vídeo do que eu tentar explicar (talvez eu tenha skills comunicativos sub-ótimos).

Acho que esse foi o melhor dia do FISL para mim.

Dia 3

Ocorreu uma miniDebConf (conferência sobre o Debian) durante esse dia na sala 41D.

Debian: o que é, e como funciona, por Antonio Terceiro

Uma palestra introdutória sobre o Debian, que no entanto me ensinou sobre uma porção de recursos online do Debian que eu não conhecia, tais como o blog Bits from Debian, o Ultimate Debian Database (que é mais útil para desenvolvedores do Debian), um pastebin, a página com informações para se tornar um novo membro do Debian, páginas onde se pode navegar pelos fontes do Debian e fazer buscas textuais no código, e um security bug tracker.

Não sou programador, como posso ajudar o Projeto Debian?, por Luiz Guaraldo

Não lembro mais o que foi visto nessa.

Containers and systemd, por Lennart Poettering

Uma palestra sobre o suporte a containers do systemd. A palestra começou com "everyone knows what containers are", except I didn't, então embora as funcionalidades apresentadas tenham parecido interessantes, eu meio que fiquei boiando sobre como as coisas funcionam.

Empacotamento de software no Debian, por João Eriberto Mota Filho

Uma palestra muito boa sobre o processo de criar um pacote Debian, cobrindo as ferramentas utilizadas, o ambiente de empacotamento, os arquivos que se deve editar, etc. Se você pretende criar um .deb na vida, assista.

Dependências de pacotes de código fonte, por Thadeu Lima de Souza Cascardo

Essa palestra pode ser resumida a "pacotes de fonte possuem dependências". Foram vistos alguns conceitos como dependências de compilação vs. dependências de execução, mas nada do que eu esperava ver foi visto, tal como como baixar pacotes fonte e suas dependências e compilá-los usando as ferramentas do Debian. A palestra terminou com o palestrante debugando um script em Perl que ele escreveu para calcular as dependências recursivas de um pacote fonte, e eu fui embora fazer outras coisas pelo mundo.

Dia 4

Decidi almoçar em casa e só consegui chegar às 13h e pouco no FISL.

Javascript e as novidades nas funções em ES2015+, por Felipe Nascimento de Moura

Cheguei uns 10 minutos atrasado na palestra. Ficou bem pouco claro para mim o que eram coisas novas do JavaScript vs. coisas que já existem. Foram vistas features como generators (que o Firefox já suporta há mais de oito mil anos, mas agora eles vão entrar no EcmaScript oficial, com uma sintaxe levemente diferente), execução assíncrona, setInterval para executar ações periodicamente, "arrow functions" (uma sintaxe nova para funções anônimas, e que captura o valor de this), e outras coisas que ya no recuerdo más.

HTTP: passado, presente e futuro, por Luiz Fernando Rodrigues

Aprendi o suficiente para querer me informar melhor sobre o HTTP/2, but that's it.

Programming Efficiently, por Jon "Maddog" Hall

A palestra foi mais sobre a importância da eficiência em programação, e não sobre técnicas de programação eficiente. O Maddog também falou sobre o fato de que muita gente sai de uma escola/faculdade sem saber como funciona o hardware, que o Raspberry Pi foi criado para ser uma máquina "hackable" e boa para o aprendizado, e que ele usou alguns Banana Pi para montar um cluster pequeno, barato e com bom poder computacional que pode ser usado para ensinar high-performance computing e afins. A palestra foi bem boa, embora não fosse sobre o que eu pensei.

How much of your computer is non-free, and how worried should you be?, por Matthew Garrett

Palestra sobre o fato de que nossos dispositivos contêm bem mais processadores do que normalmente a gente pensa, normalmente rodando software proprietário que não temos nem como ver nem como modificar. Exemplos particularmente alarmantes são HDs (com uma menção de uma galera que conseguiu fazer um HD bootar um kernel Linux) e SD cards. Worse still, muitos desses dispositivos só aceitam firmwares assinados pelo fabricante, usualmente encriptados, o que nos impede de analisar e controlar o comportamento desses dispositivos. Recomendo assistir o vídeo.

Archlinux: Você no comando, por Israel Lopes dos Santos

Uma palestra introdutória sobre o Arch Linux, explicando a filosofia da distribuição, o gerenciador de pacotes, o fato de que criar um pacote para o Arch é relativamente fácil e que qualquer um pode submeter um pacote para o Arch User Repository (AUR). Na seção de perguntas, um cidadão resolveu criticar o uso de "Linux" ao invés de "GNU/Linux" de uma maneira indireta/irônica que o palestrante não entendeu. Foi bem desnecessário; ser indireto e irônico não ganha ninguém à causa, na minha humilde opinião.

That was it. 9/10 would go again.

3 comentários

Como usar o modelo LaTeX do INF/UFRGS para TCCs e afins

2015-06-26 01:16 -0300. Tags: comp, latex, academia

Salve! Como muita gente cai neste blog procurando pelos modelos LaTeX do INF/UFRGS, e eu parei de disponibilizar o meu "pack" em favor do repositório oficial, resolvi escrever um tutorial de como usar o modelo.

Instalando o LaTeX

GNU/Linux

Nas distribuições Debian, Ubuntu e afins, você pode instalar os pacotes do LaTeX com o comando:

sudo apt-get install texlive-latex-base texlive-lang-portuguese

Se você já possui o comando pdflatex, você já tem o LaTeX instalado e pode dispensar esse passo. Porém, é possível que você não tenha o pacote texlive-lang-portuguese, o que pode causar problemas como hifenação incorreta e strings na língua errada na capa do modelo e outras partes com texto pré-definido. Se isso acontecer, verifique se o pacote está instalado. Mesmo que o seu trabalho seja em inglês, o modelo pode não funcionar corretamente na ausência desse pacote.

Outros sistemas

É possível usar o LaTeX em outros sistemas operacionais, como o Windows, mas nunca fiz isso e não sei como é a experiência. Se alguém tiver alguma dica, deixe nos comentários.

ShareLaTeX

Uma outra opção é usar o ShareLaTeX.com, uma espécie de Google Docs para documentos LaTeX. A vantagem é que você não precisa instalar nada, e pode acessar de qualquer lugar. A desvantagem é que se o servidor do ShareLaTeX.com sair do ar você está ralado, então eu recomendo baixar regularmente o .zip com os arquivos para não correr esse risco.

Instalando o iiufrgs

O pacote iiufrgs, que contém os modelos do INF/UFRGS, fica disponível em um repositório do GitHub. Para baixá-lo, você pode clicar em Download ZIP na barra lateral da página, ou usar o comando git para clonar o repositório:

git clone https://github.com/schnorr/iiufrgs.git

A vantagem de usar o git é que você pode usar o comando git pull dentro do diretório do repositório para atualizá-lo.

Dentro do repositório, há um diretório inputs, que contém o pacote propriamente dito, e um diretório examples, que contém alguns documentos de exemplo.

Para usar o modelo, é necessário que os arquivos em inputs estejam no path do LaTeX. Há diversas maneiras de fazer isso:

That's it.

Preparando o documento

O diretório exemplos contém uma porção de (adivinhe só?) arquivos de exemplo para os diversos tipos de documentos:

Copie o arquivo apropriado para o diretório onde você vai colocar seu projeto LaTeX (que pode ser um diretório vazio qualquer que você criou, ou uma cópia do inputs caso tenha optado por não instalar o iiufrgs no local padrão, ou faça upload do arquivo de exemplo para o seu projeto no ShareLaTeX). Renomeie o arquivo se for do seu interesse.

Agora é necessário editar algumas partes do arquivo.

A linha \documentclass indica o tipo de documento a ser gerado. Ela tem a seguinte cara:

\documentclass[cic,tc]{iiufrgs}

Como você já copiou um documento de exemplo do tipo apropriado, a princípio você não tem que mexer nessa linha. Se seu documento for em inglês, adicione a opção english na linha:

\documentclass[cic,tc,english]{iiufrgs}

Há outras opções, que estão documentadas nos comentários do arquivo.

Como mencionado, não há um exemplo de Plano de Estudos e Pesquisa; para isso, use o arquivo ppgc-diss.tex e altere a opção diss para pep na linha \documentclass. Você provavelmente também vai querer apagar coisas como dedicatória e agradecimentos do documento.

As próximas coisas a alterar são a linha \title, que contém o título do trabalho, e \author, que contém o nome do autor. Essa linha tem o formato:

\author{último nome}{primeiro nome e nomes do meio}

A linha \advisor, que contém o nome do orientador, segue o mesmo formato, mas inclui também o título (Prof. Dr., por exemplo). Se houver um co-orientador, descomente a linha \coadvisor e preencha da mesma maneira.

Descomente a linha \location e preencha com a cidade e UF adequados (i.e.,

\location{Porto Alegre}{RS}

que por alguma razão não é o default nos arquivos de exemplo; go figure).

O documento possui uma série de linhas comentadas definindo comandos \nominataWhatever. Na segunda página do PDF gerado a partir do modelo, fica um quadrinho com os nomes dos responsáveis por diversos setores da universidade (reitor, bibliotecário-chefe, etc.). Confira no PDF se os nomes inclusos estão atualizados. Se algum não estiver correto, descomente a linha correspondente e substitua o nome. Note ainda que alguns títulos têm concordância de gênero (e.g., "Bibliotecário-chefe" vs. "Bibliotecária-chefe"), então lembre-se de ajustar a linha com o título do cargo também. Você pode descobrir quem é o bibliotecário/a-chefe atual no site da biblioteca do INF.

Mais adiante, há uma série de comandos \keyword; estas aparecem como palavras-chave do documento na página do resumo/abstract. Escolher as palavras-chave é uma arte esotérica e misteriosa; consulte seu orientador em caso de dúvida.

A próxima coisa a mudar é a "dedicatória", que costuma ser uma citação de sua preferência. Ela é opcional, mas é uma das partes mais divertidas de escrever a monografia anyway. Logo depois, vem a seção de agradecimentos, que também é opcional (or so they say).

Em seguida, vem o o bloco \begin{abstract}, onde vai o resumo na língua do documento. Não pode haver linhas em branco entre o fim do texto e o \end{abstract}; caso contrário, a compilação do documento dá um erro de "There's no line here to end". Go figure.

A seguir, vem o bloco \begin{englishabstract}{keyword1, keyword2, …}. Apesar do nome, o que vai nesse bloco é o resumo na outra língua: se a monografia for em português, aí vai o abstract em inglês; se a monografia for em inglês, aí vai o abstract em português. O segundo argumento do bloco é a lista de palavras-chave/keywords (as mesmas que você usou antes com os comandos \keyword, mas na outra língua). Também não pode haver linhas em branco antes do \end{englishabstract}.

A seguir, vem a lista de abreviaturas; confira as instruções nos comentários. Note, entretanto, que essa lista deveria estar em ordem alfabética, que eu saiba. Em seguida, há a lista de símbolos, que vem comentada por padrão, mas você pode descomentá-la e preenchê-la de maneira análoga se você usa algum símbolo matemático que requeira explicação no seu documento.

A seguir vêm os comandos \listoffigures, \listoftables e \tableofcontents, que geram automaticamente as respectivas listas. Você não precisa mexer nesses comandos.

Finalmente, vem o texto do documento propriamente dito. No documento de exemplo, há algumas instruções sobre citações, figuras e outros detalhes, que você pode (deve) ler, mas no final você deve apagar tudo desde o \chapter{Introdução} até logo antes do \bibliographystyle e substituir pelo conteúdo da sua monografia. Se você preferir criar arquivos separados para cada capítulo para se organizar, você pode usar o comando:

\input{arquivo.tex}

que é uma espécie de #include, que insere o conteúdo do arquivo especificado nesse ponto do documento. Você pode incluir arquivos em outros diretórios. Por exemplo, você pode criar um diretório capitulos e usar \input{capitulos/introducao.tex}.

A linha \bibliography{nome} diz o nome (sem a extensão) do arquivo onde estão suas referências bibliográficas (no formato BibTeX). Por exemplo, se a linha diz:

\bibliography{biblio}

então o LaTeX vai procurar as referências no arquivo biblio.bib.

Compilando o documento

Se você está usando o ShareLaTeX, tudo o que você tem que fazer é clicar no botão "faz". Há outras IDEs de edição de LaTeX com funcionalidades análogas. Se não é o seu caso, continue lendo.

O comando principal para compilação de documentos LaTeX é o pdflatex. A sintaxe básica é pdflatex arquivo.tex. Se a compilação for bem-sucedida, será gerado um arquivo.pdf com o resultado, bem como um arquivo.log com mensagens do LaTeX e outros arquivo.* usados internamente pelo LaTeX.

Se ocorrer um erro durante a compilação, por padrão o pdflatex cai em um prompt de depuração muito doido. Para sair do prompt, digite x e dê ENTER. Para evitar cair no prompt, use a opção -halt-on-error antes do nome do arquivo.

Outra opção útil é -file-line-error, que precede os erros com nome-do-arquivo:linha:. Alguns editores de texto, como Emacs e Vim, possuem funcionalidades para rodar um comando externo de compilação, coletar as mensagens de erro e saltar diretamente para a linha onde ocorreu o erro, desde que as mensagens de erro contenham a localização do erro em um formato reconhecido (que é o que essa opção faz).

O comando pdflatex realiza apenas uma passada pelo arquivo. Porém, coisas como gerar os números das páginas no índice e números de seção em referências requerem duas passadas pelo arquivo. Além disso, a geração de bibliografia requer a chamada do comando bibtex, e depois disso é necessário rodar o pdflatex novamente (mais duas vezes). O mais prático é escrever um Makefile para rodar todos esses comandos de uma vez. Crie um arquivo chamado Makefile com o seguinte conteúdo:

# As linhas 'export' só são necessárias se você optou por não instalar o
# iiufrgs em um local padrão e não colocar seu documento e os arquivos de
# 'inputs/' no mesmo diretório.
export TEXINPUTS = .:caminho-completo-do-diretório-inputs:
export BSTINPUTS = $(TEXINPUTS)
export BIBINPUTS = $(TEXINPUTS)

PDFLATEX = pdflatex -halt-on-error -file-line-error
FILENAME = nome-do-seu-documento-sem-a-extensão

all:
	$(PDFLATEX) $(FILENAME).tex
	$(PDFLATEX) $(FILENAME).tex
	bibtex $(FILENAME)
	$(PDFLATEX) $(FILENAME).tex
	$(PDFLATEX) $(FILENAME).tex

Note que as linhas indentadas devem ser precedidas de um caractere TAB, não de espaços. Note também que o bibtex recebe o nome do arquivo LaTeX (não o nome do arquivo de bibliografia), sem a extensão.

Feito isso, agora é só rodar make para compilar seu documento. No Vim, você pode usar o comando :make para compilar, e :copen para listar os erros encontrados. No Emacs, você pode usar M-x compile. (No latex-mode do Emacs também há um comando tex-compile, acessível via C-c C-c, que serve para compilar o documento, mas ele não vai usar o Makefile. Eu sou novo nestas terras do Emacs, então não sei bem como isso funciona. Também existe um modo mais avançado de edição de LaTeX chamado AUCTeX, mas não tenho experiência com ele.)

lastpage.sty

O iiufrgs usa um arquivo lastpage.sty para determinar o número da última página, que ele inclui no quadrinho CIP na segunda página do documento. Se você se deparou com o erro:

! LaTeX Error: File `lastpage.sty' not found.

você tem duas opções:

Bibliografia

A maneira normal de trabalhar com referências bibliográficas no LaTeX é através do BibTeX. O iiufrgs vem com um arquivo BibTeX de exemplo, biblio.bib, que aparentemente saiu da coleção pessoal de alguém e foi gerado pelo JabRef (pacote jabref no Debian/Ubuntu/etc), um gerenciador gráfico de bibliografias em BibTeX. Eu nunca usei o JabRef, mas se você gosta de ferramentas gráficas, pode querer experimentá-lo. Caso contrário, continue lendo.

O arquivo .bib é basicamente uma seqüência de entradas bibliográficas. Uma entrada tem mais ou menos essa cara:

@tipo-de-publicação{label-da-sua-escolha,
  title = {Título da Publicação},
  author = {Turing, Alan and Church, Alonzo and Gödel, Kurt},
  year = {2101},
  booktitle = {Proceedings of the 42nd Intergalactic Conference on Computability Theory},
  pages = {123--134},
  publisher = {ACM}
}

tipo-da-publicação é algo como article (artigo em journal), inproceedings (artigo de conferência), book (livro inteiro), incollection (capítulo de livro, quando o autor do capítulo é diferente do autor/editor do livro), electronic (publicação na Internet), ou uma infinidade de outras possibilidades. O tipo de publicação define os campos que podem aparecer dentro da entrada e o formato como ela aparece na bibliografia do PDF gerado.

label-da-sua-escolha é a label que você vai usar com os comandos \cite e afins.

BibTeX é um mundo à parte e eu não vou tentar explicar tudo o que há para explicar aqui; para mais informações, procure por "BibTeX" na Internet. Deixo, entretanto, algumas dicas:

Fim do conto

Acho que era isso. Em um post futuro, pode ser que eu escreva uma introduçãozinha aos comandos de formatação do LaTeX, mas com o que aparece no arquivo de exemplo já dá para se virar um pouco. Você pode dar uma olhada nos outros posts com a tag latex.

Dúvidas, sugestões e correções podem ser deixadas nos comentários.

2 comentários

Trocando de janela pelo nome

2015-06-23 02:50 -0300. Tags: comp, unix

Por uma série de acidentes enquanto experimentava window managers hoje,

  1. Eu me dei conta de que seria bem conveniente poder trocar de janela digitando uma parte do título ao invés de procurar na barra de tarefas ou dar vinte Alt+Tabs até encontrar a janela. (Eu me dei conta disso quando, depois de não conseguir achar a janela que eu queria no i3, a minha primeira reação foi querer dar C-x b (o comando switch-buffer do Emacs) e digitar o nome da janela.)
  2. Eu descobri ferramentas apropriadas para tornar isso possível.

[Screenshot do programa 'dmenu']

Você vai precisar de:

Com isso, podemos escrever um pequeno script para apresentar um menu e selecionar a janela escolhida.

O script

#!/bin/bash

option="$(
    wmctrl -xl |
        #         \1       \2       \3       \4       \5
        #         win-id   desktop  class    hostname title
        sed -r 's|([^ ]* +)([^ ]* +)([^ ]* +)([^ ]* +)(.*)|\1 \3 \5|' |
        sort -k 3 |
        dmenu -i -l 10
    )" || exit 1

wmctrl -ia "${option%% *}"

wmctrl -l lista as janelas existentes. A opção -x inclui a classe da janela na listagem. O sed não é estritamente necessário, mas deixa a lista menos poluída removendo campos desnecessários; você pode alterar essa linha para escolher os campos. O ID da janela é meio irrelevante para o usuário, mas precisamos dele para poder passá-lo ao wmctrl para ativar a janela.

sort -k 3 ordena o menu pelo título da janela. Você pode comentar essa linha fora se não quiser ordenar a lista, ou mudar os parâmetros para obter uma ordem diferente (e.g., sort -k 2 para ordenar pela classe).

Quanto ao dmenu, a opção -i faz com que ele ignore maiúsculas vs. minúsculas ao filtrar as opções pelo texto digitado pelo usuário. -l 10 indica que queremos uma opção por linha, e que no máximo 10 linhas devem ser mostradas de cada vez. Por padrão, o dmenu usa apenas uma linha e mostra as opções lado a lado. (Uma coisa meio ruim do dmenu é que ele não dá nenhuma indicação de que é possível scrollar o menu; ele só mostra as primeiras N opções e as demais ficam escondidas.)

wmctrl -a JANELA ativa a primeira janela cujo título contenha a string specificada. Como queremos que a seleção seja inambígua, utilizamos a opção -i, que permite especificar o ID da janela ao invés do título. Para extrair o ID da seleção, removemos tudo depois do primeiro espaço na string ("${option%% *}").

Instalação

Salve o script no local de sua preferência, dê permissão de execução a ele (chmod +x nome-do-script), e associe-o a alguma tecla de atalho no seu ambiente gráfico favorito. Por exemplo, no IceWM isso pode ser feito adicionando no ~/.icewm/keys uma linha como:

key "Super+Tab" /caminho/do/script

substituindo Super+Tab pelo atalho de sua preferência (Super é a tecla "janelinha").

Para mais informações e possibilidades, consulte a manpage dos programas.

Comentários

Ensinando inglês

2015-06-09 23:28 -0300. Tags: lang, comic, img, random

Quadrinho:

Quadro 1:

B: Como se diz "fazer" em inglês?

A: "Do".

B: Mas "do" não é pra fazer pergunta?

---

Quadro 2 (cena imaginada por A):

A: Ah, sim, o inglês usa "do" como um auxiliar dummy em perguntas, provavelmente como uma maneira de equilibrar a tendência histórica do inglês de deslocar o verbo para o começo em perguntas, como as demais línguas germânicas, com a tendência a  uma ordem SVO mais rígida, provavelmente motivada pela perda de morfologia que permita distinguir substantivos e verbos em inglês, o que pressiona a língua a desambiguar usando a sintaxe ...

---

Quadro 3:

A:

A: É, serve pra fazer pergunta também.

Baseado em fatos reais.

(E eu ia mudar o texto para "distinguir substantivos e verbos facilmente em inglês", mas já gastei meu estoque de paciência com o GIMP hoje.)

2 comentários

Emacs, again

2015-06-05 02:30 -0300. Tags: comp, editor, emacs

No último sábado eu resolvi experimentar usar o Emacs de novo. O plano era ficar usando durante um mês e depois escrever um post relatando a experiência. Porém, como ao longo dos três anos de blog eu observei que em geral quando eu deixo um post para escrever depois eu acabo não escrevendo, em parte porque eu acabo esquecendo o que eu ia escrever, resolvi escrever um post inicial agora. (Além disso, quando eu comecei a escrever esse post eu não estava conseguindo dormir e precisava passar o tempo.)

So far, estou curtindo horrores.

Da primeira vez que eu tentei usar o Emacs, eu larguei de mão em dois ou três dias. Acho que o principal fator de diferença foi que dessa vez eu resolvi usar a versão gráfica do Emacs. Assim, quando eu não consigo fazer alguma coisa pelos comandos de teclado eu posso recorrer ao mouse e get stuff done. Dito isso, como eu não sou exatamente um fã do mouse, na prática eu acabo me motivando a aprender os comandos anyway.

(Um vício bem mais difícil de eu me livrar é usar as setas, Home/End e afins ao invés dos comandos "tradicionais" do Emacs. Right now eu larguei um pano de prato por cima do lado não-alfabético do teclado para ver se me habituo a não usar essas teclas.)

Mas por quê?

Tudo começou porque eu estava meio de saco cheio do Claws Mail, experimentei o Thunderbird e não gostei muito (não lembro mais por quê), e aí lembrei do Gnus e resolvi experimentar. No fim das contas eu consegui resolver o problema que eu estava tendo com o Claws comentando fora um teste no código-fonte e não curti muito o Gnus, mas a essas alturas eu já tinha mexido um bocado no Emacs e ressurgiu o interesse, reforçado pelos seguintes acontecimentos:

E aqui estamos.

Coming from Vim...

Em alguns aspectos, o Emacs pode ser mais "difícil" de usar do que o Vim. Seguem algumas observações nesse sentido.

Enquanto usar o Vim sem nenhuma customização é relativamente ok, usar o Emacs sem nenhuma customização não é uma experiência tão agradável. Desde que eu comecei a usar o Emacs, quase todo dia eu adiciono alguma coisa no meu ~/.emacs, que provavelmente vai continuar crescendo na mesma taxa por um bom tempo. (De certa forma o ponto do editor é ser customizado/reprogramado to death, então eu desconfio que enquanto eu usar o Emacs eu não vou parar de mexer no ~/.emacs; porém, eu espero mexer nele com menos freqüência depois de algum tempo de uso.)

Além disso, embora o Emacs ganhe bonito em flexibilidade, certas configurações simples são mais fáceis de fazer no Vim do que no Emacs. Por exemplo, no Vim define-se um keybinding novo em termos das teclas que teriam que ser pressionadas para realizar o comando desejado. No Emacs, cada tecla é associada a uma função que é executada quando a tecla é pressionada, o que por um lado é bem mais limpo do que a maneira como o Vim faz as coisas (definir uma ação complexa em termos de keypresses pode ser um inferno), mas por outro lado exige que uma função em Emacs Lisp seja definida sempre que se quer associar uma seqüência de comandos a uma tecla.

Dito isso, Emacs Lisp é uma linguagem infinitamente mais agradável de usar do que Vimscript. Além disso, é fácil descobrir qual é o nome da função associada a cada tecla, usando os comandos Ctrl-h k (describe-key) e Ctrl-h c (describe-key-briefly), o que facilita na hora de definir funções novas em termos das funções das teclas existentes.

Além disso, embora eu tenha mudado as cores do editor para texto branco no fundo preto, o restante do esquema de cores se adaptou sozinho, e eu achei o esquema de cores tão bom que nem desativei o syntax highlighting (que normalmente é a primeira coisa que eu faço quando uso o Vim em outro computador). A única exceção foi o AUCTeX, que escolheu umas cores diferentes do resto do editor por alguma razão.

Comandos

Enquanto o Vim possui um modo específico para dar comandos (o Normal mode), o que permite que os comandos sejam teclas simples1, o Emacs possui apenas um "modo" (no sentido Vim da palavra2), e os comandos de edição normalmente são introduzidos por um keystroke envolvendo Control ou Alt (Meta no linguajar emacsístico). Muitos comandos exigem uma seqüência de keystrokes: o comando para abrir um arquivo é Ctrl-x Ctrl-f, por exemplo, e o comando para abrir um arquivo em uma nova janela é Ctrl-x 4 Ctrl-f. Da primeira vez que eu experimentei o Emacs eu achei esses comandos totalmente bizarros e meio que larguei ele de mão por causa disso. Porém, agora que eu resolvi usar o editor de novo com a mente em um modo (heh) mais propenso a aceitar coisas novas (e com a interface gráfica para me salvar nos momentos difíceis), eu tenho me adaptado aos comandos novos relativamente fácil.

Embora seja tentador logo no começo alterar o keymap para usar comandos mais intuitivos, eu resolvi fazer um esforço para aprender os comandos convencionais do editor, e só definir keybindings novas para comandos que eu mesmo criei ou que não têm uma keybinding padrão, for most part. Até agora tem sido relativamente tranqüilo. Se depois de mais tempo de uso eu vir que algum keybinding realmente não me agrada, eu mudo. O mais difícil tem sido lembrar de usar Ctrl-s no Emacs e Ctrl-f no Firefox para procurar texto, e usar Ctrl-f (forward) para avançar um caractere e Ctrl-b (back) para voltar um caractere, e analogamente Meta-f e Meta-b para avançar e voltar uma palavra. Esses aí eu sou capaz de acabar rebindando para Ctrl-. e Ctrl-, ou algo do tipo (ou me conformar em usar as setas mesmo), se não me habituar nas próximas semanas.

O Emacs usa uma notação especial para descrever keystrokes. Basicamente, C-x significa Ctrl-x, M-x significa Meta-x (Alt-x), C-M-x significa Ctrl-Meta-x, RET é o Enter, SPC é o espaço, DEL é o backspace, e seqüências de teclas são escritas separadas por espaço (C-x C-f significa "tecle Ctrl-x, e depois tecle Ctrl-f"). Eu vou usar essa notação no restante do post.

Uma coisa legal do Emacs é que todo comando possui um nome (o nome da função Lisp que o implementa). Mesmo quando não se sabe o atalho de teclado que ativa o comando, é possível dar M-x e digitar o nome do comando (que freqüentemente é relativamente fácil de adivinhar, pois a nomenclatura é mais ou menos consistente; além disso é possível usar TAB para completar os nomes). Se o comando possui um atalho associado, após executar o comando o Emacs mostra uma mensagem como You can run the command `mark-paragraph' with M-h, e assim você aprende a tecla do comando.

Outra coisa que ajuda é que o help do Emacs é muito bom de usar. Todos os comandos de ajuda começam com C-h; C-h ? mostra todas as opções de ajuda. C-h f mostra a documentação de uma função ou comando, C-h k mostra a documentação do comando associado a uma tecla, C-h c mostra o nome do comando associado à tecla, C-h m mostra a documentação do modo atual, C-h r abre o manual do Emacs, entre outros. Como já mencionado, a documentação de uma função vem com um link para o código-fonte, quando disponível (no Debian, é necessário instalar o pacote emacs24-el). O link não é parte do texto da documentação, mas sim uma funcionalidade do próprio Emacs: se você pedir o help de uma função que você mesmo definiu no seu ~/.emacs, o Emacs vai mostrar um link para o ponto da definição no arquivo. (Até as poucas funções definidas em C têm links para a definição no fonte, mas nesse caso o Emacs abre uma janela perguntando o diretório onde se encontra o fonte C do Emacs, que eu não tenho aqui.)

Uma coisa um pouco ruim é que quase todos os keystrokes já têm um comando associado, seja por padrão, seja pelo modo em uso, o que limita as escolhas para novos keybindings que não conflitem com os existentes. Por convenção, o Emacs reserva C-c seguido por uma letra para o usuário, mas C-c seguido por outras coisas são reservados para os modos. Porém, existe um refúgio: a tecla C-z por padrão vem associada ao comando suspend-frame, que suspende o Emacs em modo texto e minimiza a janela no modo gráfico. Eu basicamente não uso esse comando no modo gráfico anyway (e ele também fica acessível via C-x C-z), então o que eu fiz foi rebindar ele como uma "prefix key" e colocar os comandos novos que eu defino sob o C-z (por exemplo, C-z C-z para salvar e fechar o arquivo e C-z d para inserir a data atual). Como C-z é um comando padrão do Emacs, isso tem a vantagem de que basicamente nenhum modo usa essa tecla.

Emacs as a daemon

Enquanto o modo de uso normal do Vim (e editores de texto em geral) é abrir o editor, editar arquivos e fechar, o modo de uso normal do Emacs (e sistemas operacionais em geral) é deixar o editor aberto o tempo inteiro enquanto se está trabalhando, em parte porque o editor tende a acumular estado (arquivos e aplicativos abertos, modos em uso), em parte porque ele demora um pouco mais para carregar do que o Vim (especialmente a versão gráfica, e especialmente se o ~/.emacs faz mil coisas na inicialização). Porém, é possível rodar o Emacs como um daemon, e aí pode-se usar o comando emacsclient para abrir um novo "frame" (janela) do Emacs conectado à sessão já em execução, o que é mais rápido do que iniciar o editor do zero. emacsclient -a "" inicia um daemon automaticamente se já não houver um rodando, e conecta-se a um existente se houver. Além disso, é possível passar as opções -t para rodar no terminal e -c para criar uma nova janela gráfica (por padrão ele abre o arquivo passado na linha de comando em uma janela existente, se houver). É um comando bem útil para setar como o valor da variável de ambiente EDITOR, que programas como git, crontab, etc., usam para determinar o editor a ser usado.

Shell mode

O Emacs possui um "modo shell" (M-x shell), que executa o bash ou afim dentro de um buffer do Emacs, onde os comandos normais de edição do Emacs ficam disponíveis. O modo tem algumas bizarrices (o texto é um buffer normal, o que significa que é possível editar a saída dos comandos que já foram executados, apagar o prompt [update: isso é controlável pela variável comint-prompt-read-only; mais informações no help da variável (C-h v comint-prompt-read-only)], etc.), mas é interessante se você quer realizar o máximo de tarefas possível sem sair do Emacs.

O shell mode toma conta do completion de nomes de arquivos e comandos, mas ele usa a função de completion do Emacs, que por padrão exclui certos tipos de arquivos que normalmente não se tem interesse em abrir num editor de textos (e.g., arquivos .o), o que não faz muito sentido em um shell. A solução que eu encontrei foi adicionar um "hook" (função que roda quando um modo é iniciado) no meu ~/.emacs que anula a lista de extensões a ignorar no buffer do shell.

Outro "gotcha" é que como o buffer usa os comandos normais do Emacs, coisas como Ctrl-C, seta para cima, etc., não têm o comportamento normal do terminal. Os comandos Ctrl-* devem ser precedidos de C-c (e.g., C-c C-c para interromper o processo, C-c C-z para suspender, etc.). Manipulação de histórico é feita através de M-p e M-n (de "previous" e "next", análogo ao C-p e C-n para trocar de linha no buffer).

Como trata-se de um buffer simples, coisas que exigem poderes "gráficos" do terminal, como aplicativos de tela cheia, não funcionam no shell mode. Porém, é possível adicionar suporte a cores no buffer (para coisas como ls --color) rodando a função ansi-color-for-comint-mode-on (seja via M-x, seja no ~/.emacsrc (lembrando de pôr parênteses em volta do comando nesse caso)). Vale ainda notar que o shell mode seta a variável de ambiente TERM para dumb, o que faz com que ls, grep e companhia não usem cores por default. É possível contornar isso alterando o ~/.bashrc para mudar o valor de TERM (para vt100, por exemplo) se a variável INSIDE_EMACS estiver setada, mas aí os programas que usam TERM para decidir se vão operar em modo tela cheia ou não vão incorretamente assumir que podem rodar em tela cheia dentro do shell mode. Não sei se há algum valor de TERM que indique suporte a cores mas não às demais funções gráficas do terminal.

Também existe um "modo terminal" (M-x term), que é um emulador de terminal de verdade (não apenas um buffer com um shell) onde se pode rodar qualquer programa de terminal, mas aí perdem-se os comandos normais do Emacs. Além disso, pelo que eu testei o emulador é pra lá de lento (o alsamixer leva uns três ou quatro segundos para abrir com o processador a 800MHz3).

M-x finish-post RET

Por hoje ficamos por aqui. Eu provavelmente hei de postar mais coisas à medida em que for descobrindo funções novas no editor, e atualizar meu ~/.emacs no GitHub ocasionalmente.

_____

1 Na verdade, faz uns cinco anos que eu uso o Vim com keybindings especiais para não ter que trocar de modo para os comandos de edição mais freqüentes, então eu já usava um editor não-modal for most part, o que significa que de certa forma eu não aproveitava muito das vantagens de usar o Vim.

2 O que o Emacs chama de modos são coisas como o html-mode, latex-mode, c-mode, etc., chamados major modes, que alteram o comportamento do editor (como comandos e syntax highlighting) para facilitar a edição de um certo tipo de arquivo, ou aplicações como o Gnus. Também há os minor modes, que são usados em conjunto com os major modes e se comportam mais ou menos como algumas opções ativadas com :set no Vim.

3 Normalmente eu uso a máquina em modo de economia de energia e só seto o governor do cpufreq para performance quando vou fazer alguma coisa mais pesada, primariamente porque com a freqüência baixa o fan faz menos barulho.

9 comentários

Blog multilíngüe

2015-05-31 00:19 -0300. Tags: about

Faz uma porção de tempo que eu venho considerando a possibilidade de postar algumas coisas em inglês por aqui. Isso é uma coisa que ainda me deixa meio receoso, mas tem algumas situações em que eu acho que postar em inglês seria mais úti, seja para o mundo (e.g., posts sobre o Chicken, em que a comunidade de usuários é pequena (acho) e limitar a audiência a falantes de português seria muito... limitante), seja para mim (e.g., posts sobre design de linguagens de programação, em que eu hipoteticamente poderia ter feedback de mais gente se eu escrevesse em inglês), seja para ambos (e.g., posts sobre o lash, ou conlanging).

Pronto, falei.

Eu pensei em criar um blog separado para postar em inglês, mas aí pensei que isso seria inconveniente para os leitores usuais (todos os quais falam inglês anyway, dos que eu conheço), que teriam que olhar em dois lugares diferentes para ver se há posts novos. Por ora, o que eu provavelmente vou acabar fazendo é postar tudo aqui e usar uma tag english nos posts em inglês, até eu arranjar uma solução melhor.

Na verdade, desde antes dos primórdios deste blog, uma das motivações originais para eu escrever meu próprio blog system ao invés de usar um pronto era implementar suporte a multilingualismo "the right way". Eu estive pensando sobre isso e me dei conta de que é mais complicado do que parece. Por exemplo:

Enfim, nada muito difícil de implementar, na verdade, mas é um bocado de coisas que eu não tinha parado para pensar antes.

4 comentários

lash status update

2015-05-14 23:42 -0300. Tags: comp, prog, pldesign, lash, life

Faz quase dois meses desde o primeiro commit do lash. O status do projeto é o seguinte:

No decorrer dessa última semana, o parser original, baseado na biblioteca Comparse de parser combinators, foi substituído por um parser descendente recursivo escrito à mão. Os motivos principais para a reescrita foram que a Comparse não mantém informação de linha e coluna dos elementos parseados, aparentemente não tem suporte nenhum a error reporting (o parser simplesmente "backtracka" quando se depara com um erro, até que o parser inicial backtracka e devolve #f), e o parser estava com uns comportamentos estranhos diante de algumas entradas (o que não é culpa da Comparse, mas não tinha por que eu perder tempo debugando se eu já teria que reescrever o parser uma hora ou outra pelos outros motivos citados). O handling de espaços e newlines no parser antigo também estava o caos, enquanto no atual aparentemente tudo funciona como deveria nesse quesito.

O parser novo reconhece quase toda a linguagem prevista para a "release inicial", lança exceções nos pontos certos do código ao encontrar erros de sintaxe (embora as exceções ainda não sejam muito descritiva, mas já é um começo), e armazena a linha e a coluna de cada construção nos nós da árvore sintática (com pequenos erros, mas nada difícil de resolver). O código ainda está meio crude, e tem muita coisa que ainda dá para refatorar (e.g., repetições que estão codificadas como loops explícitos ao invés de uma construção que abstraia a repetição), mas isso vai ir se resolvendo ao longo do tempo. De repente as partes mais abstratas do parser podem até virar uma biblioteca de parser combinators no futuro (com a diferença de que eu estou usando uma struct mutável e exceções ao invés de uma mônada para manter o estado do parser e indicar erros, o que seria meio unusual para uma biblioteca de parser combinators, mas whatever; ninguém disse que seriam parser combinators funcionais).

O parser novo reconhece mais construções do que o resto do shell é capaz de executar (por exemplo, pipelines, redirects, &, &&, ||, $()... em outras palavras, praticamente todas as funções do shell), o que de certa forma é bom, porque me compele a implementar as coisas que faltam. Nos últimos dias o desenvolvimento anda numa taxa mais ou menos ok (para mim), e acho que é mais ou menos realista prever uma release 0.1* mais ou menos funcional para julho. Pelo menos é (mais ou menos) isso que eu espero. Isso é bom, porque em um momento de otimismo em março eu submeti uma proposta de palestra para o FISL sobre o shell e, na vaga possibilidade de ela ser aceita, até lá seria bom o shell estar num estado usável. (Eu submeti a proposta sob a premissa de que se tudo desse errado com o shell e eu fosse aceito era só pedir para tirarem a palestra, mas a essa altura acho que isso não será mais necessário. Tudo isso assumindo que eu seja aceito, o que seria muito doido, na real.)

Comecei a usar a wiki do projeto no GitHub para fazer anotações. O plano que ela venha a conter:

Para editar a wiki é necessário criar uma conta no GitHub, aparentemente, mas acho que podemos conviver com isso. Contribuições são sempre bem-vindas.

Quanto à linguagem do shell, algumas coisas mudaram:

Durante o desenvolvimento do novo parser eu descobri um "bug" no Chicken que faz com que variáveis criadas com define dentro de um cond sejam declaradas como globais. A galera na mailing list parece ser da opinião de que isso não é um bug e sim uma feature, entretanto. Meanwhile, eu resolvi o problema no lash redefinindo o cond para wrappear as cláusulas em um (let () ...) implícito (o que cria um "scope boundary" que torna as definições locais), e de brinde ainda lançar uma exceção se nenhuma cláusula for verdadeira. Scheme, yay.

Enquanto o lash anda às mil maravilhas, o mestrado vai por água abaixo, mas isso é assunto possivelmente para outro post.

_____

* No momento eu não estou numerando as versões, mas pelo esquema de numeração previsto (<major>.<minor>.<número de commits desde o último update do minor>), estaríamos na versão 0.0.31. Parece bastante, mas é porque eu tenho o hábito de commitar loucamente enquanto estou mexendo no código.

1 comentário

Breakup

2015-05-14 20:55 -0300. Tags: lang, img, random, comic

Para fins de conservação para a posteridade, inflijo-vos este quadrinho que eu postei no reddit mais ou menos um ano atrás.

Quadrinho:
A: So you and Mary are over?
B: Yeah.

A: Why? You made such a good couple.
B: It would never work out. She thinks Proto-Indo-European had an */a/.
A: Oh. What?

B: I told her: "Maybe in the latest stages, but not originally. */a/ is really just underlying */eh₂/". But she shook her head and said: "Not typologically plausible". It was horrible.
A: WTF?
B: Yeah, I know!

1 comentário

You're doing it completely wrong

2015-04-28 22:03 -0300. Tags: comp, prog, wrong, ramble

Encontrei um e-mail de três anos atrás que explica uma das coisas que eu acho que estão "completely wrong" com os ambientes computacionais modernos. O texto era para ter servido de base para um post que nunca foi escrito. Reproduzo-o semi-intacto abaixo. (Fico feliz que a minha visão ainda seja a mesma, mas por outro lado o "plano para os próximos dez mil anos" parece longe de se realizar...)

* * *

From: Vítor De Araújo
To: Carolina Nogueira
Subject: You're doing it completely wrong
Date: Mon, 12 Mar 2012 00:37:18 -0300

[Core dump follows.]

Acho que eu não vou escrever o post tão cedo, então explico agora. O que há de completely wrong é que os programas em execução são "caixas pretas"; em geral um programa é um brinquedo estático, que tu não pode "olhar dentro" e modificar facilmente. Em um mundo ideal tu deveria poder alterar partes de qualquer programa sem ter que recompilar tudo, e de preferência sem sequer ter que fechar e abrir o programa para as mudanças entrarem em efeito.

Exemplo simples: o Pidgin a cada 60 segundos manda um "XMPP ping" pro servidor de XMPP (Jabber), para ver se a conexão ainda está de pé. Se eu quiser mudar de quanto em quanto tempo ele manda o request, ou quanto tempo ele espera por uma resposta, eu tenho que alterar o fonte. Idealmente:

  1. Isso poderia ser (e talvez já seja) uma variavelzinha feliz do programa, que eu deveria poder alterar durante a execução;
  2. Alterar o fonte não deveria ser nenhum grande mistério; o fonte deveria ser facilmente acessível e modificável a partir do programa, e eu deveria poder recompilar uma função ou módulo individual sem ter que recompilar o universo. (Mais de uma vez eu quis mudar coisinhas simples do Pidgin, e.g., eliminar o atalho Ctrl-Up, que bizonhamente exigem alterar o fonte, e falhei miseravelmente em conseguir fazer o troço compilar.)

Além disso, deveria ser fácil desfazer qualquer modificação. Versioning é uma tecnologia muito supimpa dos anos 60 que, como muitas tecnologias supimpas do passado, se perdeu com a popularização de maquininhas pequenas com recursos insuficientes pra suportar a coisa. Hoje em dia temos recursos sobrando, mas a tecnologia caiu no esquecimento.

Exemplo menos simples: o Claws Mail por padrão ordena as mensagens em ordem ascendente de data (da mais antiga pra mais recente), e ele lembra o critério de ordenação por pasta, o que quer dizer que o usuário tem que alterar pra ordem decrescente individualmente pra cada uma das mais de oito mil pastas que há (Inbox, Sent, Queue, Trash, Drafts pra cada mailbox, mais os feeds de RSS). Provavelmente 99.5% das pessoas esperam ordem decrescente por padrão, e provavelmente teria que alterar pouca coisa do código pra mudar o padrão, mas a barreira pra alterar o software é muito grande (baixar fontes, encontrar o trecho de código relevante, se entender com ./configures e bibliotecas da vida, recompilar o mundo, fechar e abrir o programa). Idealmente, eu deveria poder apontar para um menu relacionado com o que eu quero, teclar alguma combinação mágica, e ir parar na função que aquele menu ativa. Daí em diante eu deveria conseguir navegar pelo código até achar o trecho relevante; os nomes de funções e variáveis deveriam funcionar como links (coisa que acho que é possível com a maior parte das IDEs atuais). Tendo achado o dito cujo, eu deveria poder alterar o código, mandar recompilar aquele trecho, e as mudanças se tornarem imediatamente efetivas.

E aparentemente essa utopia toda já existiu, sob o nome de Lisp Machine. Este cara diz:

Within DW, you can move your mouse over any object or subobject that has been displayed, whether or not it was part of any GUI. You get this virtually for free and have to work hard to suppress it if you don't want it. But it doesn't require any special programming.

One of the most common ways to get a foothold in Genera for debugging something is to (1) find a place where the thing you want to use appears visually, (2) click Super-Left to get the object into your hands for read-eval-print, inspection, etc, (3) use (ed (type-of *)) to find its source reliably and with no foreknowledge of what the type is, who wrote the program, what their file conventions were, who loaded it, or any of myriad other things that other systems make me do.

Quer dizer, tu pode pegar um objeto qualquer presente na tela (e praticamente tudo é um objeto, pelo visto), descobrir o tipo/classe dele e mandar editar o código correspondente [(ed (type-of *))]. Eu queria rodar o simulador de Genera aqui pra ver isso funcionando na prática, mas não consegui fazer ele funcionar total... :-(

Enfim, muita tecnologia gloriosa do passado se perdeu. Um dos meus objetivos para os próximos dez mil anos é avançar o estado da arte a o que ele era nos anos 80... :P

Aí o camarada se pergunta: será que faz sentido ter essa tecnologia em um desktop? Será que o "usuário final" tem algum interesse nisso tudo? A resposta é a mesma que se pode dar para justificar a presença de uma linha de comando em um sistema visando o "usuário final" (e.g., Ubuntu, Mac OS):

  1. Mesmo que o usuário final não tenha interesse, se é de ajuda ao desenvolvedor e não prejudica o usuário de maneira alguma, não há por que não ter a feature.
  2. Alguns usuários têm interesse em explorar o funcionamento do sistema e usar as features mais avançadas. Em particular, se a barreira para editar os programas for pequena e for fácil desfazer quaisquer modificações, é bem possível que muito mais gente tenha interesse em bagunçar com os internals das coisas.
  3. Uma coisa muito legal que se vê com Ubuntus da vida é que mesmo um usuário que não saiba usar a linha de comando pode pedir ajuda num fórum e alguém que sabe pode ajudar o cara a resolver um problema que envolva brincar de linha de comando. Da mesma forma, um usuário poderia resolver problemas que envolvessem alterar um programa com a ajuda de pessoinhas em fóruns e afins.

Além de dar todo o poder para os cidadãos infra-vermelhos, o que lembra um pouco as idéias do camarada Alan Kay [1][2], a tendência é que a facilidade de alterar e testar os programas leve a programas mais bem testados, menos bugados e que tendam à perfeição mais rápido. Todos comemora.

Existem mil dificuldades envolvidas na criação de um sistema assim, especialmente se quisermos abandonar o modelo da Lisp Machine de uma máquina mono-usuário em que todos os processos podem tudo, mas isso fica pra outra discussão.

Escrevi bem mais do que eu pretendia. Parece que eu até tenho material para um post... :P

Comentários

Um teto

2015-04-20 23:05 -0300. Tags: misc, philosophy

Hoje de madrugada eu acordei com algumas cousas na cabeça que não tinham nenhum motivo aparente para estar lá. E foram as seguintes:

Você provavelmente já ouviu a teoria de que a vida na Terra veio de outro planeta. (Ignoremos o fato de que isso não explica absolutamente nada sobre a origem da vida.) Normalmente a idéia é que a vida surgiu em algum outro lugar e se espalhou pelo universo, veio de brinde num asteróide, etc.

Você também já deve ter ouvido a idéia de que nós vivemos dentro de uma simulação. A idéia é freqüentemente motivada pelo fato de que algumas coisas no nosso universo parecem ter comportamento discreto (i.e., "digital").

Mas e se fosse um pouco diferente...

* * *

Imagine que houvesse uma forma de vida inteligente completamente diferente da nossa (não baseada em DNA) em algum canto do universo. Um belo dia, meio que por acaso, os pesquisadores do planeta Xrbna descobrem essas cousas que nós chamamos ácidos nucléicos, aminoácidos, etc. Talvez inicialmente eles tivessem chegado nessas moléculas puramente teoricamente, i.e., alguém estava ponderando sobre "o que aconteceria se eu montasse uma molécula assim assado" e se deu conta de que ela tinha propriedades interessantes. A galera continua brincando com essas entidades, teorica ou fisicamente, mais ou menos como a galera começou a experimentar com configurações de Life nos anos 1970, até que alguém descobre uma configuração particular que é capaz de produzir cópias semi-idênticas de si mesma. Animados (ou o equivalente alienígena de animados), os xrbnanianos resolvem criar versões físicas da molécula e colocá-las em um ou alguns planetas (de preferência bem longe deles) para ver o que acontecia. Em (pelo menos) um desses planetas, ao longo de alguns bilhõezinhos de anos, aconteceu um bocado de coisas.

Now, eu não estou propondo que foi assim que a vida terrestre surgiu, mas eu estou interessado no cenário. Se a vida na Terra tivesse surgido assim:

Agora suponha que nós déssemos um jeito de criar um equivalente físico de Life ou algo similar. Será que em algum ponto esse sistema desenvolveria consciência? Será que nós reconheceríamos a consciência quando a víssemos? Nós seríamos capazes de entender o que se passa na "cabeça" desse sistema? Nós já temos dificuldade de entender o que se passa na cabeça de outras criaturas vivas mais distantes de nós; nós seríamos capazes de entender uma criatura de uma natureza completamente diferente da nossa? Que outras coisas podem ser "conscientes" à nossa volta sem que nós saibamos? Faz sentido usar o termo "consciente" nesse contexto, ou será que haveria outras propriedades tão interessantes quanto consciência nesses sistemas, mas tão diferentes de o que nós chamamos de consciência que esse termo não seria aplicável?

Quais seriam as implicações éticas de "matar" um jogo de Life "gone conscious"? O jogo só é consciente se for implementado fisicamente, ou uma simulação também é consciente? E se a simulação for feita com papel e caneta ao invés de por uma máquina? E se eu escrever uma fórmula fechada f(i) que calcula o estado do jogo para cada iteração i, a fórmula é consciente, ou "contém consciência" de alguma forma? Se não é, por que não? Em que ponto a informação contida na fórmula se torna consciência?

* * *

Esses questionamentos não são nenhuma novidade para os filósofos, e eu já tinha lido coisas similares na vida, mas acho que essa é a primeira vez que eu realmente entendo ("grok") o problema. Acho que é hora de eu ler o Gödel, Escher, Bach de novo.

7 comentários

Main menu

Posts recentes

Tags

comp (87) life (35) prog (34) unix (30) random (26) lang (23) mundane (21) about (19) mind (16) web (13) img (13) pldesign (12) ramble (11) rant (11) privacy (8) bash (7) esperanto (7) lash (7) academia (6) home (6) shell (6) freedom (5) conlang (5) misc (5) copyright (4) mestrado (4) book (4) worldly (4) lisp (4) music (4) film (3) kbd (3) security (3) wrong (3) latex (3) editor (3) politics (3) cook (2) android (2) poem (2) php (2) treta (2) comic (2) c (2) physics (2) network (2) pointless (1) audio (1) philosophy (1) perl (1) emacs (1) kindle (1)

Elsewhere

Quod vide


Copyright © 2012-2015 Vítor Bujés Ubatuba De Araújo
O conteúdo deste blog, a menos que de outra forma especificado, pode ser utilizado segundo os termos da licença Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International.

Powered by Blognir.