Blog do Mitre

Compartilhando informação com o Google Reader

2009-11-02T14:48:00.000-02:00

Já faz muito tempo que deixei de compartilhar itens que leio no Google Reader nesse blog. Não sei se vou retornar esse hábito, mas seja como for, por causa de um comentário de um amigo, eu fui dar uma olhada a quantas andava a evolução do "share" do Google Reader e me impressionei.

Há muitas modificações que foram feitas ao longo do tempo que eu não dava mais a mínima por não usar o recurso, mas somente a pouco eu vi todas as modificações juntas e o resultado é que podemos compartilhar textos com notas, comentar sobre documentos compartilhados por terceiros ou mesmo sem compartilhar, localizar pessoas utilizando ferramentas de busca por nome e/ou interesse, usar o recurso "Like" para marcar textos que tenha gostado e usar esse recursos para ver quem gostou daquele item (talvez seja alguém que valha apenas seguir). Você pode tornar o seu perfil público, mas impedir que alguém te siga (eu acho que fiz isso uma vez sem saber do que se tratava, desculpas aí, ok ?) ou torna ele privado e determinar com quem você quer compartilhar.

Mas recentemente, a região de "Explore" que permite você explorar (e se perder explorando) novos itens, acrescentou o "Popular items" (não sei como foi feita a tradução, "Itens populares" ou "Tópicos populares" ?) que permite visualizar tópicos que possuem um número muito alto de "pessoas que gostaram do tópico" (recursos "Like").

Enfim, compartilhar e receber informação com o Google Reader ganhou recursos realmente interessantes. A ponto de que voltei a usar essa parte do sistema.

Quem quiser seguir os meu itens compartilhados pode acessar a informação dessa página. É, entretanto, necessário notar que não há um botão "Follow" nessa página. Se assinar essa página ela entra no Google reader como um feed RSS qualquer e não no sistema interno do Google Reader. Eu tentei me localizar pela busca existente no "sharing settings" mas não me achei (será quer é para que eu não me ache mesmo ?). Então, caso isso não dê certo, use o e-mail que publico no blog para colocá-lo nos seus contatos. Isso deve permitir que você me encontre. Se isso também não der certo (?) e você ainda não desistiu de me seguir, você pode assinar um dos feeds que eu compartilhei na página pública, buscar por algo que eu tenha marcado com o "Like" (quase tudo que compartilho eu marco com o "Like") o que permitirá ter acesso ao meus itens compartilhados em uma página que terá o botão "Follow" para você clicar. Essa última idéia dá trabalho, mas funciona sempre.

Por que seguir alguém ?

Alguém se deu ao trabalho de filtrar a informação para você separando o que realmente é bom do que não é bom, supondo que escolheu seguir uma pessoa com o perfil que te agrade, claro. Você economiza tempo e trabalho. E também não precisa seguir todos os RSS do mundo.
Precisa de mais de um motivo ? Bom, você pode manter uma conversação inteligente longe do blog original que pode não estar com comentário tão inteligentes assim.

E o lado ruim ?

Você segue 10 indivíduos com mesmo perfil ? Você terá 10 vezes o mesmo tópico compartilhado.
Encontrar pessoas que te agradem seguir nem sempre é tarefa tão fácil quanto parece.
Têm gente que simplesmente marca todos os tópicos de um certo RSS para compartilhar. Fuja disso, a menos que seja algo necessário para ter diálogos em torno daquela fonte que não permite comentários - ou não aceita seus comentários e de seus pares (?) -, mas se não for o caso, assine o feed original.

Rapidinhas, não tão rápidas

2009-10-15T17:40:00.003-03:00

Desde de julho eu não escrevo. Basicamente eu estou com a corda no pescoço e com o carrasco puxando ...

Somente consegui um tempo para escrever no blog apenas porque torci o pé e o analgésico/anti-inflamatório é forte.

O último tópico "Descobrindo o seu ip real" está desatualizado.
Por conta disso, eu sugiro o uso de

alias myip="links -dump http://jfmitre.googlepages.com/ipsimple|head -1|cut -d',' -f 1"

no lugar do comando previamente comentado. O comando ficou um pouco mais complicado, mas é mais provável que esse serviço não sai do ar. Eu não vou atualizar o outro tópico...

Não pude deixar de notar esse tópico de hoje. Fiquei impressionado com o unp. Ele resolve 70 % das dúvidas que eu tenho que responder sobre descompactar no terminal e ainda elimina uns 10 atalhos que possuo para descompactação em lote de arquivos.

Vejamos a configuração de notebook Acer Aspire 5738-6922

Processador & Chipset
Intel Core 2 Duo T6400 - 2.0GHz, Cache L2: 2MB, FSB: 800MHz.
Memória
3GB DDR3 1066MHz.
Expansível até 4GB.
Armazenamento
HD de 320GB - SATA II, Buffer de 8MB, 5400rpm.
Drive DVDRW - lê mídias double layer.
Tela
Tela de 15.6" com tecnologia Acer Cinecrystal.
Resolução nativa: 1366 x 768 pixels.
Gráficos
Intel GMA 4500MHD ( 128MB dedicado ).
Multimídia
WebCam de 1.3 megapixels.
Interface I/O ( entradas e saídas )
4 USB.
1 RJ-11 ( modem ).
1 RJ-45 ( rede Ethernet ).
1 saída de áudio para fones de ouvidos ou lato-falantes externos.
1 entrada para microfone externo.
1 saída VGA para monitores externos.
1 HDMI.
1 leitor de cartões de memória 5 em 1: SD, MMC, MS, MS PRO e xD.
Comunicação
modem 56Kbps.
rede Gigabit 10/100/1000Mbps.
rede Wireless: Wi-Fi 802.11a/b/g/n.
Interface do usuário
Gabinete azul onix, teclado preto.
Teclado com Ç.
Dimensões e peso
peso: 2.8kg.

Sucesso quase absoluto em instalar o Ubuntu. Problema apenas com o microfone interno, ao qual eu nem sei se existe mesmo, e com o headfone, que eu não tentei configurar. O resto, perfeito. Mais ou menos 1100 frames por segundo de vídeo (suficiente para programas 3D que não sejam jogos atuais). Ótima qualidade de som, saída HDMI e memória DDR3.

Esse notebook foi comprado para o laboratório e ficou sob minha guarda por eu ser o primeiro que irá utilizá-lo. Me ordenaram instalar o Windows XP e o Linux que desejasse. E quem foi que disse que o notebook reconheceu o Windows XP ? Eu sei que tem suporte porque há uns 40 drivers (sem brincadeiras) para instalar posteriormente ao OS. Mas eu não consegui passar das primeiras telas do instalador (E é o Windows XP original, ok ? E eu usei duas mídias distintas de CD !). Não imagina minha ~~alegria~~ tristeza com a ausência do Windows ~~, especialmente quando eu abri uma garrafa de vinho para comemorar~~

Mas o que me deixou chateado nesse notebook foi o Linux original do sistema (sim, o notebook veio com um GNU/Linux). Além do patético particionamento do sistema, ao qual 10 GB era tudo de Linux e o restante FAT32, o sistema iniciava no terminal (e se tinha um X funcional, não funcionou comigo) e não tinha toda configuração instalada. Quando eu vi o particionamento eu nem me dei ao trabalho de ver outras coisas. Ah ! O

shutdown -r now

também não funcionou e eu não faço idéia do motivo. Mas como ele travou ao desmontar o HD, eu suponho que algum serviço teimoso não foi corretamente desativado ou que os scripts estavam corrompidos. Seja como for, se fosse meu primeiro contato eu poderia nunca mais querer ouvir falar de Linux na vida e com justa causa.

O livro não está abandonado, apenas não esperem uma nova versão esse ano (especialmente porque desejo manter em PDF apenas versões estáveis e redondinhas do código que qualquer um pode acessar a qualquer hora - e que também anda parado a um bom tempo). As coisas estão realmente muito apertadas para mim e eu não vi muitas modificações no ubuntu 9.10 que justifiquem um esforço concentrado nesse momento.

[esqueci]
Experimente o htop. E se desejar, para não ter que reaprender a digitar htop no lugar de top, sugiro adicionar as linhas abaixo ao ~/.bashrc

# Use o htop no lugar do top, se existir htop
alias top='[ -f /usr/bin/htop ] && htop || /usr/bin/top'

[/esqueci]

Se tiver algum erro grave de português nesse texto, favor, ignore. Analgésicos não ajudam em nada na concentração.

Descobrindo o seu ip real

2009-07-21T16:40:00.001-03:00

Dica especial para quem não se conecta diretamente na internet e usa um roteador para intermediar a conexão (característica típica de quem está conectado a partir de uma rede interna).

Para descobrir o seu ip real, normalmente uma busca na internet retorna sites como ShowMyIP. Para quem não sabe, existem milhares de sites com essa capacidade, pois isso não é nenhum recurso extraordinário.

Mas mais fácil ainda é adicionar as linha

alias myip='lynx -dump http://www.showmyip.com/simple/'

no ~/.bashrc.

Assim, quando quiser saber o seu ip real, basta digitar myip no terminal.
Nesse caso, é necessário ter o lynx instalado no computador. Para quem prefere o links, pode-se usar a linha

alias myip='links -dump http://www.showmyip.com/simple/'

no lugar da linha original.

Dicas de Juliet Kemp

2009-07-19T18:13:00.000-03:00

O Linux Today resumiu uma coleção de dicas de Juliet Kemp do Server Watch.

Quem não viu, vale apena ver. Algumas coisas, como as dicas para configurar o PS2, PS3 e PS4 são como descobrir algo que está diante dos seus olhos todos os dias e nem ao menos se importou em olhar para saber do que se trata. Afinal, "todo mundo configura" o PS1, mas quantos sabem o que é o PS2 ou o PS4 ? É claro que algumas dicas são mais do mesmo para alguns, mas para outros ...

Não se contente com a seleção do Linux Today e verifique as publicações não selecionadas. Aposto que vai descobrir alguma coisa interessante.

Gmail não é mais um aplicativo beta e hoje não é primeiro de abril.

2009-07-07T17:00:00.001-03:00

Essa mensagem é um daqueles ecos da internet que vale apena repetir. O Gmail não é mais um aplicativo beta.

Já acreditei que esse dia nunca chegaria. Já até critiquei o Google por redefinir o conceito de aplicativo beta sem ter o direito disso. Mas o dia chegou... merece um: Uau !!!

E para não dizer que não falei dos demais, parece que o Google Docs e o Google Calendar também deixaram de ser beta...

Vale lembrar aos saudosistas (?) de plantão que o Gmail permite que você volte a usar o logo com o nome beta escrito...

ArchLinux: Um mês depois...

2009-07-06T16:00:00.003-03:00

A exatamente 1 mês atrás eu migrei para o ArchLinux. Eu normalmente escrevo o relato "uma semana depois", mas eu queria adquirir mais experiência com o sistema para ter o que falar dele.

Primeiro ponto: o AUR. Se quando eu instalei o sistema eu somente senti falta de 1 (um) aplicativo, hoje eu tenho 20 aplicativos do AUR instalados. Me parece que a química, física e matemática não conta com um número muito grande de votos... pacote excelentes, como o gElemental*, estão com pouquíssimos votos.

Até me inscrevi e fiz uns comentários pelo AUR até perceber que não me lembro onde fiz os comentários, ou seja, ainda preciso me adaptar melhor com o sistema da comunidade.

Por falar nisso, eu "acidentalmente" conheci um aplicativo chamado yaourt que ajuda muito a baixar um aplicativo do AUR. Entre outras coisas, ele permite atualizar pacotes do AUR. Ainda não experimentei esse ponto (instalei o aplicativo a 2 dias) e não posso opinar quanto a eficácia da solução, mas dada a popularidade dela, deve funcionar muito bem.

A estabilidade é excepcional. Tenho até medo de falar de futuro, mas posso falar de passado. Não houve erros. Não houve problemas. E o sistema de gerenciamento de pacotes é muito robusto.

Para dizer que eu não vi nada de diferente, o camarada de gerencia o virtualbox-ose (que não é o virtualbox_bin) alterou a versão do módulo do kernel dois dias antes do kernel ser atualizado no repositório do core. Isso me confundiu um pouco, por que o pacman não funcionava com a filosofia que eu conheço. Isso fez que eu pensasse que ele tinha feito uma coisa, mas ele fez outra...

Inclusive, isso lembra que o kernel foi atualizado nesse meio tempo. E quando digo isso, eu lembro do drive NVIDIA. Pois... não foi observado qualquer problema nesse ponto. O kernel e o módulo foram atualizados no mesmo momento (e eu não vi como).

Ainda sobre a atualizações de pacotes, duas coisas comuns me chamaram a atenção. NÃO DEVE-SE ignorar mensagens durante a atualização dos pacotes. LER essas mensagens e AGIR (ainda que depois) evita problemas desnecessários. Felizmente, o administradores devem conhecer um pouco a cabeça de usuário (bom, eles são usuários !!!), porque a mensagem que eu devia ter lido estava no portal... (e isso parece ser um fato comum).

Lembra que eu mencionei o OpenFOAM (que era o motivo de eu ter migrado para o openSUSE), pois é... está compilado e rodando no ArchLinux. Ok ... eu precisei trapacear. Eu compilei a primeiro em outro sistema e depois recompilei com o gcc do ArchLinux, sem fazer um "wcleanAll". Existe algum problema de biblioteca/include que não permite que eu compile o sistema inteiro do zero dentro do ArchLinux (acredito que a versão do binutils seja nova demais e eu optei por não resolver isso da forma correta - seguindo filosofia do OpenFOAM), acredite em mim quando digo que isso não é um problema. De forma que o mais importante é que até o OpenFOAM está funcionando.

Bom, o resumo geral dessa história é que eu tive o mês mais produtivo do ano. Eu realmente espero que essa "lua de mel" dure muito.

* O gElemental não vai instalar fácil no sistema. É necessário editar um arquivo do source, que está dentro do tar.bz2 com uma dica que está nos comentários. Depois modificar o md5sum dentro do PKGBUILD para então conseguir instalar. Mas é a melhor a mais bonita tabela periódica que eu conheço para o GNU/Linux

Os bons hábitos do usuário do computador

2009-07-03T22:40:00.003-03:00

Há recomendações que deviam ser seguidas por todos nós, usuários.

Infelizmente, como toda recomendação ou regra, elas são questionadas por alguns e não são seguidas por muitos.

Da série de tópicos: faça o que eu escrevo, mas não faça o que eu faço, proponho relembrar alguns desses bons hábitos, que como já induzi a crer, não são completamente seguidos por mim, mas não deixam de ser bons hábitos.

A maior parte dessas dicas são aplicáveis em qualquer sistema operacional.

Use boas senhas. Nada de 123456, ou password, ou data de aniversário, etc.
Modifique as senhas padrões dos seus aplicativos. Se usa aplicativos ou hardwares com senhas padrões, modifique-os. Você pode não ser dono de uma grande rede, mas não quer dor de cabeça do mesmo jeito.
Não use espaços e/ou caracteres especiais nos nomes dos arquivos. Prefira letras minúsculas separadas por underlines ou notação estilo "WikiPage" (desse jeito que escrevi). Nada de apóstrofo, aspas, ponto de exclamação ou interrogação, nem símbolos como dóllar, hash, arroba, etc. O dóllar ($), por sinal, é um terror, pois $nome é variável, assim, um arquivo que se chame "algo$nome" somente é "protegido" com aspas simples ou usando barra invertida. Esse tipo de caractere trás muitos problemas.
Registre os nomes dos aplicativos que possui e usa. Qualquer gerenciador de programas descente possui esse tipo de habilidade. Não confie na memória. Muito embora, seja interessante fazer uma limpeza no arquivo eliminando aqueles aplicativos que não te foram úteis durante as atividades.
Faça backup. Preferencialmente do sistema inteiro, mas impreterivelmente dos arquivos pessoais em mais de uma mídia/tecnologia (se possível). Um gravador de DVD custa muito pouco hoje em dia, a mídia também é barata.
Faça backup dos seus aplicativos online. E não adianta cobrir o sol com a peneira. Se suas notas estão no evernote e os seus e-mails no gmail, faça backup disso também. Não ignore essa necessidade.
Anote e guarde suas configurações mais usuais. Parece que é a mesma coisa que um backup, e até é, se for para restaurar as configurações no mesmo ambiente. Mas aqui eu estou falando de manter um registro de todas aquelas configurações que de tão intuitivas você nem lembra que são uma alteração que você mesmo induziu ao sistema. Se um dia precisar de usar esses recursos em outro sistema, não tem jeito do backup ser tão eficiente assim.
Não tenha receio de danificar o sistema. Não é a mesma coisa de "pode meter o martelo". O que quero dizer é que há pessoas que não fazem testes porque temem pelas conseqüências da estabilidade (eu mesmo faço isso, e em muitas ocasiões, com boas justificativas técnicas e morais). Mas esse temor pode lhe custar um grande benefício. Vide minha transição para o Arch Linux, eu ganhei muito, perdi nada e não tinha feito isso antes por receio de ficar improdutivo por muito tempo.
O melhor programa é aquele que você sabe usar e que faz o que você quer fazer. Por até haver um programa que seja tecnicamente melhor que outro, mas as vezes, mudar é como utilizar uma bomba para quebrar um vaso de vidro. Use a melhor ferramenta para o seu objetivo e ponto final.
O programa que você não usa, evolui. Mude quando o novo programa for a escolha certa. Completando o item anterior, a melhor ferramente pode ser outra no futuro. Não deixe de mudar. O equilíbrio entre o item anterior e esse é o que estimula a produtividade. A falta de equilíbrio gera problemas de diversos níveis. E lembre-se do item 8.
O computador é uma ferramenta para um objetivo. Não se esqueça disso.
Crie uma metodologia para gerenciar os seus arquivos. E não se acomode. Deixar muitos arquivos bagunçados no computador é algo fatal. Preferencialmente, essa metodologia deve ser tão simples quanto possível, mas não mais simples do que o necessário, intuitiva, fácil de executar e adapatável a evolução usual das idéias, ou seja, que seja facilmente gerenciável.
Leia os manuais. Certo que há manuais mais extensos do que o tempo disponível para lê-los. Certo também que há manuais menos úteis do que devia. Mas eles existem. Se não quer ler o manual de um programa que não sabe usar, considere usar outro programa. Nota: Tutorias e exemplos ajudam muito, mas não são os bons manuais fontes de tutoriais e exemplos ?
As atividade administrativas são executadas pelo administrador, as de usuário comum, pelo usuário comum. Isso é regra básica para gerenciamento de sistemas.
Mantenha o registro do seu hardware. Colete todas as informações possíveis sobre o seu hardware e guarde em algum lugar seguro. Pode até ser em mídia eletrônica, mas lembre-se de não usar apenas no próprio computador.

Apresentando um Makefile em detalhes

2009-06-14T15:00:00.000-03:00

Não tem muito tem e fiz uma introdução ao comando make. Como mencionado, a forma mais simples quanto possível de apresentar essa questão é utilizando um exemplo que seja tão simples quanto possível e que não seja simples demais para não ficar algo muito superficial. Por isso, escolhi o meu próprio Makefile, criado para gerar um dvi/pdf de um código LaTeX. Portanto, eu vou colocar esse código aqui conforme eu for citando, mas se quiser, baixe o mesmo para acompanhar localmente e fazer suas próprias anotações nele. Eu não vou modificar o Makefile hoje, mas eu posso vir a atualizar/modificar ele no futuro (até irei comentar sobre pontos falhos do mesmo durante a exposição).

Primeiro passo

O primeiro passo é definir o objetivo.

No nosso exemplo: Compilar um código LaTeX, considerando a possibilidade de existir uma bibliografia, um índice remissivo, nomenclatura e glossário. Isso é o mais completo que eu conheço. Além disso, o Makefile deve sempre gerar um PDF e gerar um DVI quando possível. Para gerar o PDF, eu quero que o usuário possa escolher entre gerar primeiro um DVI e depois converter para o PDF ou gerar direto o PDF. Eu também quero que o Makefile facilite o meu trabalho para visualizar o documento e que seja possível eliminar o resultado e o lixo intermediário gerado facilmente.

Esse era o meu objetivo nesse caso. E entenda que eu sei como fazer essas coisas no terminal (o make não faz mágica)...

Em outros casos, pode ser: gerar o programa helloworld a partir do código fonte main.c, incluindo uma forma de eliminar o resultado final e os arquivos intermediários.

Lembrando regras básicas de programação.

Recomendações que não são utilizadas por quem recomenda não são, necessariamente, recomendações ruins....

Comente sempre que achar necessidade e quando não achar também, seja sucinto, mas não omita informações. Entretanto, não se culpe se depois alguém disser que não entendeu o que você queria ter dito. Como senhores do programa, naquele momento parece muito claro o que estamos escrevendo. Depois de um certo tempo, isso tornar menos claro. Então, se possível, reveja suas anotações depois de um certo tempo.

O alinhamento do código é muito importante, mas não precisa ser de 8 espaços, pode ser 1 ou 2. Eu gosto de 2, mas nesse caso do meu Makefile eu utilizei apenas 1 espaço. Dizem por aí que o recomendado é 3.

Sempre que possível, faça a tarefa automaticamente. Não peça ao usuário informações que não sejam necessárias, automatize sempre que possível, sem perder a generalidade.

Por fim, porém não menos importante... escreva como usar o seu código. Isso é para você mesmo se lembrar depois...

O Makefile.

O Makefile começa com um cabeçalho.
Informe o que achar necessário.

# File: Makefile
# Author: J. F. Mitre <http://jfmitre.com>
# Created: Sex 29 Mai 2009 10:14:33 BRT
# Last Update: Qui 04 Jun 2009 21:30:21 BRT
# Notes: Arquivo Makefile para compilar códigos em LaTeX
# Execute "make help" para ajuda
###############################################################################

É educado guardar um CHANGELOG. Eu escrevi o programa em uma tacada só na quinta do dia 04. Na sexta anterior tinha sido o dia que eu decidi fazer o arquivo e escrever as idéias. Então meu CHANGELOG é pequeno. Ainda assim, eu não o divulguei...

Teria sido legal colocar uma nota sobre licença. Eu esqueci desse detalhe...

Definições de variáveis

A primeira parte do Makefile é composta por definições de variáveis.

# Programas Selecionados {{{
########################## PROGRAMAS SELECIONADOS #############################

# Comando que gera compila o código LaTeX. Escolha entre: latex ou pdflatex
TEX = latex
# Comando que visualiza o arquivo .dvi
DVIVIEW = kdvi
# Comando que visualiza o arquivo .pdf
PDFVIEW = evince
# Comando que converte o arquivo .dvi em .ps
DVIPS = dvips

# }}}

Esse bloco acima define quais são os valores das variáveis TEX, DVIVIEW, PDFVIEW e DVIPS. São aplicativos do sistema que fazem aquilo o comentário indica. Esse são os comandos que serão utilizados pelo make ao executar um certa tarefa. Esses comandos foram colocados no primeiro bloco, porque podem ser modificados pelo usuário.

Veja como exemplo a variável TEX. Eu posso usar latex ou pdflatex. O primeiro comando gera um arquivo .dvi enquanto o segundo gera diretamente um arquivo .pdf. Eu também posso usar o visualizador que eu quiser para ver um certo formato de arquivo. Ao invés de kdvi, eu poderia especificar okular ou mesmo o evince (embora ele não inclua as imagens na visualização). E assim por diante. São variáveis para o usuário definir...

Que fique claro que um Makefile mais sofisticado teria colocar essas opções como argumentos, mas como eu disse, esse Makefile que eu escolhi é mais complexo que o básico e mais simples que o completo.

O bloco seguinte são as opções do programas

# Opções dos comandos {{{
############################ OPÇÕES DOS COMANDOS ##############################

# Opções do comando TEX especificado acima
OPTDVI = -halt-on-error
# Opções do comando dvips, que converte o arquivo .dvi para o .ps
OPTPS = -Z
# Opções do comando comando "pdflatex"
OPTPDF =
# Formato de conversão utilizado pelo ps2pdf (necessário especificar)
FORMATO = a4
# Estilos dos glossários, nomenclaturas, etc.
STYLENLS = nomencl.ist
STYLEGLS = nomencl.ist
# Opções do comando make
OPTMAKE = -s

# }}}

Se o usuário não conhece o comando, fica muito difícil dar palpites aqui. É necessário olhar o man de cada aplicativo para saber porque coloquei certas opções e para escolher outras. Afirmo que essas opções são agradáveis para 99 % dos usuários. Dois únicos cuidados são: definir o tamanho do papel para o ps2pdf e definir o estilo para o glossário e nomenclaturas. Note que eu usei o mesmo, mas há casos onde existe um estilo pré-definido e casos onde são diferentes os estilos.

Novamente, as opções padrões ficam no interior do Makefile, as alternativas deviam ser passadas por linha de comando, algo que eu não fiz intencionalmente... (quem sabe em uma versão futura)

Seguindo, encontramos mais variáveis.

# Outros programas {{{
############################# OUTROS PROGRAMAS ################################

# Comando que gera o índice, a nomenclatura, etc. Não existe outro atualmente
MAKEINDEX = makeindex
# Comando que gera a bibliografia, não existe outro atualmente
BIB = bibtex
# Conversão entre arquivo .ps e arquivo .pdf, existem outros, mas esse é o
# melhor para o GNU/Linux.
PSPDF = ps2pdf
# Eliminar arquivo. Não é razoável fazer de outra forma.
RM = rm -fv
# Comando make (até existem outros, mas não para esse Makefile).
MAKE = make

# }}}

Essas variáveis, são os outros comandos. Comandos no sistema que eu NÃO quero que sejam modificados. Quem gera o índice, e o makeindex, não existe outro. Quem gera a bibliografia é o bibtex, não existe outro.
Quem deleta arquivos é o rm. Bom, até existem outras formas de usá-lo, mas você quer mesmo modificar isso?

Da mesma forma, o make é o make. Até existem outros, como o colormake, mas fracamente, se é para usar um comando, use o mesmo que foi digitado, ou seja, se eu digito cmake, ele compilaria com o cmake, se eu digito make, ele compila com o make. Se entendeu a minha lógica, é melhor não modificar nesse comando até que consiga fazer o sincronismo entre o digitado pelo usuário e essa variável sem que o usuário deva especificar no interior.

Embora o autor (eu) não recomende modificá-las, essas variáveis são como quaisquer outras. Podem, sim, ser modificadas. O maior exemplo disso é o ps2pdf. Existem inúmeras formas de converter um arquivo .ps em um arquivo .pdf, mas apenas uma foi disponibilizada por mim, porque assim eu defini.

Execução
Passada a parte de configuração, vem a parte de execução.

Os primeiros comandos são preparações, eventualmente necessárias.

# Indentificação do nome do arquivo
DOC := $(shell egrep -l '^[^%]*\\begin\{document\}' *.tex |rev|cut -b5- |rev)

# Verificando se existe bibliografia
BIBFILE := $(shell egrep -l '^[^%]*\\bibliography\{' $(DOC).tex)

# Verifica se é uma apresentação do prosper
PROSPER := $(shell egrep -l '^[^%]*\\documentclass\[.*\]\{prosper\}' *.tex)

O primeiro comando define qual é o arquivo principal dentro do diretório em que ele é executado.
É um comando no shell. Ele gera a variável DOC, essa variável é utilizada como $(DOC) (se fosse um shellscript, seria $DOC, mas não é um shellscript, é um Makefile). De forma que $(DOC).tex é o arquivo principal da estrutra LaTeX (que pode conter vários documentos independentes).

Nesse ponto, vemos a primeira falha do autor. Ele não deixou claro, mas se existirem dois arquivo .tex com nomes diferentes contem um \begin{document} NÃO COMENTADO no mesmo diretório, haverá erro de compilação.

Porque o comando seguinte, verifica o arquivo $(DOC).tex procurando pela existência do comando que define se existe ou não uma bibliografia.

O terceiro comando é um daqueles casos de automação úteis. Oras, se o documento .tex for um código do prosper, então o DVI não faz sentido... logo, eu posso identificar esses casos e resolver o problema dele gerando sempre um PDF no final.

Relembrando as ações básicas

Gerar um $(DOC).dvi, gerar um $(DOC).pdf, limpar os arquivos intermediários, eliminar tudo que foi gerado pelo Makefile, inclusive o produto final e mostrar o resultado, tanto do dvi, quanto do pdf.

A ordem dos blocos não importa, exceto pelo primeiro bloco.

Bloco $(DOC).dvi, o primeiro bloco

# Gerando o "arquivo" DVI ...
$(DOC).dvi:
# mas ele é esperto o bastando para saber que não gera-se DVI com o pdflatex.
# E também gerará o PDF caso seja o proper seja utilizado.
   @if [ ! -z $(PROSPER) ]; then \
    $(MAKE) dvi; \
    $(DVIPS) $(OPTPS) $(DOC).dvi; \
    $(PSPDF) -sPAPERSIZE=$(FORMATO) $(DOC).ps $(DOC).pdf; \
   elif [ $(TEX) == latex ]; then \
    $(MAKE) dvi; \
   elif [ $(TEX) == pdflatex ]; then \
    $(MAKE) $(DOC).pdf; \
   fi

Em teoria, esse bloco gera um arquivo DVI, mas ele DEVE ser esperto o bastante para saber que não se gera um DVI quando utiliza-se o pdflatex, e o serviço NUNCA para no DVI quando se está utilizando o prosper.

Mas o primeiro detalhe é o nome do bloco: $(DOC).dvi. O nome do bloco é o nome do suposto produto final. Isso é MUITO importante, porque evita que você compile novamente aquilo que já foi compilado, ou seja, se ao digitar "make $(DOC).dvi" no terminal o make encontrar o arquivo $(DOC).dvi, então ele para ali mesmo.

O segundo detalhe é posição do bloco dentro do código. Ele é o primeiro bloco, logo, ao digitar "make" sem argumentos, será ele que será executado.

Todos os comandos que compõem esse bloco estão afastados de um tab da margem esquerda.

O algorítimo é outro assunto, mas para melhor entendimento do Makefile, eu vou passar por esse bloco mais detalhadamente.

A primeira linha verifica se a variável $(PROSPER) não está vazia. Por que ela não está vazia, deve-se criar o DVI, converter esse DVI para o formato PS e depois converter o PS para o PDF. Porque não converter direto do DVI para o PDF ? Porque fica muito melhor assim de acordo com minha opinião. Um Makefile mais completo devia dar margem a outras opiniões. Caso $(TEX) seja igual a "latex" e não seja um arquivo prosper, então, eu quero gerar um dvi. Se $(TEX) for igual a pdflatex, então eu quero gerar um pdf diretamente. Por que isso foi feito ? Caso eu digite make no terminal, não é esse o bloco que será executado ? Então, se eu tiver selecionado pdflatex, eu certamente quero um pdf, eu não quero o DVI (porque o pdflatex não gera dvi :-0 ), logo crie o pdf. Melhor que uma mensagem de "erro" antipática (criada porquem escreveu o Makefile) que não lhe permita usar o make sem argumento diretamente no terminal.

O arroba na frente do if significa que eu não quero que o comando ecoe pelo terminal. Por padrão, o comando make funciona como se estivesse em permanente modo de debug. Mostrando quais são os comando que serão executados e executando-os. Eu não quero que ele escreva o comando na tela ? Então coloco o arroba na frente. O arroba na frente do if serve para todo o grupo de "uma única linha" do if.

Digo uma única linha, porque a barra invertida no final de cada linha significa que o comando continua na linha seguinte. O motivo pelo qual fiz isso no arquivo, é porque é mais fácil lidar com erros de formatos quando se utiliza a barra invertida (que deve ser o último caractere de uma certa linha).

Note os comandos no interior das condições.

    $(MAKE) dvi; \

ou então,

    $(MAKE) $(DOC).pdf; \

Esse comandos estão invocando o próprio make, que invoca um bloco dentro do Makefile. Um dos blocos chama-se "dvi" e o outro "$(DOC).pdf". Por similaridade com o "$(DOC).dvi", acredito que todos imagem o que seja o "$(DOC).pdf". Por sua vez, o bloco "dvi". É quem faz o serviço sujo. É ele quem de fato realiza o trabalho de compilar os código fonte gerando o resultado. Eu poderia dispensar esse bloco adicional, contudo, o código fica mais legível com ele, que faz um papel de subrotina ou função (como preferir).

Antes olhar o bloco que faz o serviço sujo. Vamos observar o bloco $(DOC).pdf

Bloco $(DOC).pdf

# Gera o arquivo PDF...
$(DOC).pdf:
# de um arquivo DVI, convertendo-o para PS e em seguida para PDF caso
# o comando padrão seja o latex ou diretamente, caso o comando padrão seja 
# o pdflatex.
# Também diminuimos o esforço caso o prosper esteja sendo usado.
   @if [ ! -z $(PROSPER) ]; then \
    $(MAKE) $(DOC).dvi; \
   elif [ $(TEX) = latex ]; then \
    $(MAKE) $(DOC).dvi; \
    $(DVIPS) $(OPTPS) $(DOC).dvi; \
    $(PSPDF) -sPAPERSIZE=$(FORMATO) $(DOC).ps $(DOC).pdf; \
   elif [ $(TEX) = pdflatex ]; then \
    $(MAKE) pdflatex; \
   fi

Primeiro, ele verifica se é um arquivo prosper e caso seja, passa ao bloco $(DOC).dvi o dever de cuidar desse caso. Se $(TEX) for igual a "latex", então primeiro deve-se gerar um DVI e sem seguida converter para ps e por fim, converter para pdf. Nesse ponto nota-se claramente a vantagem de ter o bloco com o nome $(DOC).dvi. Caso o DVI exista, ele não será recriado. Caso $(TEX) seja pdflatex, então chame o comando "$(MAKE) pdflatex", ou seja, o originalíssimo nome de bloco igual a "pdflatex" para a criar um pdf com o "pdflatex".

Bloco dvi

Aquele que faz o serviço sujo. Ele é idêntico ao bloco "pdflatex". O único motivo para os dois blocos existirem é porque assim eu defini. Até as opções, que são diferentes variáveis para cada comando, não justifica tal escolha. Primeiro porque eu poderia usar um if para gerar diferentes opções para cada comando, segundo porque as opções do comando latex são iguais as do comando pdflatex.

E porque defini dois blocos ? Porque eu estava com pressa para assistir uma defesa de tese nesse dia e não percebi o que tinha escrito até que era tarde demais. Aí tive pouco tempo para modificar.

Reconheço e reafirmo a utilidade de existir o bloco dvi e o bloco pdflatex, assim como devia existir o bloco pdf. porque a intuição humana fará o usuário digitar "make dvi" ou "make pdflatex" ou "make pdf" e assim é muito bom sincronizar o código a intuição humana. Mas definitivamente, não precisa ser dois blocos grandes e idênticos.

Bom, o bloco dvi é dado abaixo

# Gerando o arquivo DVI com o latex
dvi: 
# Compliação inicial do arquivo tex
$(TEX) $(OPTDVI) $(DOC).tex
# Se existe bibliografia ...
   @if [ ! -z $(BIBFILE) ]; then\
    $(BIB) $(DOC).aux; \
    $(TEX) $(OPTDVI) $(DOC).tex; \
    $(BIB) $(DOC).aux; \
    $(TEX) $(OPTDVI) $(DOC).tex; \
   fi
# Se existe glossário, nomenclatura ou indice...
   @if [ -f "$(DOC).nlo" ]; then \
    $(MAKEINDEX) $(DOC).nlo $(STYLENLS) -o $(DOC).nls; \
    $(TEX) $(OPTDVI) $(DOC).tex; \
   fi
   @if [ -f "$(DOC).glo" ]; then \
    $(MAKEINDEX) $(DOC).glo -s $(STYLEGLS) -o $(DOC).gls; \
    $(TEX) $(OPTDVI) $(DOC).tex; \
   fi
   @if [ -f "$(DOC).nlo" ]; then \
    $(MAKEINDEX) $(DOC).nlo $(STYLENLS) -o $(DOC).nls; \
    $(TEX) $(OPTDVI) $(DOC).tex; \
   fi
   @if [ -f "$(DOC).glo" ]; then \
    $(MAKEINDEX) $(DOC).glo -s $(STYLEGLS) -o $(DOC).gls; \
    $(TEX) $(OPTDVI) $(DOC).tex; \
   fi
   @if [ -f "$(DOC).idx" ]; then \
    $(MAKEINDEX) $(DOC).idx; \
    $(TEX) $(OPTDVI) $(DOC).tex; \
    $(MAKEINDEX) $(DOC).idx; \
    $(TEX) $(OPTDVI) $(DOC).tex; \
   fi 
# Uma última vez apenas para confirmar que tudo está ok...
   $(TEX) $(OPTDVI) $(DOC).tex

Observe que ele não passa de um bloco de comandos em lista para os quais são efetuadas operações adicionais caso exista bibliografia, glossário, nomenclatura e índice. Nada diferente do que faria se estivesse escrevendo um shellscript, ou seja, nada diferente do que faria se estivesse digitando tudo no terminal. Todos os comandos são repetidos pelo menos duas vezes para assegurar o sucesso de qualquer projeto, não importa o tamanho. Mas esse tipo de dica é latex/terminal/linux não Makefile. Caso venha a compilar o código fonte em c, teriamos algo como "$(GCC) $(GCC_FLAGS) $(CODE)" e seria apenas uma vez.

Blocos clean e cleanall

... ou melhor dizendo limpando o diretório. Os dois blocos são reponsáveis por eliminar os arquivos não mais desejados. O bloco clean limpa os arquivos intermediários (e como tem arquivos intermediários nesse caso). o bloco cleanall, elimina todos os arquivos, inclusive os resultados, ou seja, o pdf e o dvi gerado.

# Limpando o básico dos arquivos gerados pelo compilador
clean:
   @$(RM) *.aux *.log 
   @$(RM) *.toc *.lot *.lof
   @$(RM) *.ttt *.fff *.blg *.out
   @$(RM) *.ind *.ilg *.idx *.aux *.glo
   @$(RM) *.gls *.abx *.nlo *.syx *.nls
   @$(RM) *.ps 
   @$(RM) *.tex.backup
   @$(RM) *.bib.backup *.bib.bak
   @$(RM) *.tex.bak
   @$(RM) *.bbl
   @$(RM) *.*~
   @$(RM) Makefile~

# Limpando tudo, inclusive os arquivos finais.
cleanall: 
   $(MAKE) clean
   @$(RM) *.dvi *.pdf

Detalhe interessante fica por conta de como o cleanall foi criado. Ele usa o bloco clean e depois elimina o que sobrou, que são os resultados. Essa é a forma elegante de aproveitar os comandos de um bloco em outro bloco.

Blocos de visualização

Quatro blocos adicionais foram criados para permitir visualizar o resultado: show e shownew, showpdf e shownewpdf.

show:
   @if [ ! -z $(PROSPER) ]; then \
    $(MAKE) $(DOC).dvi; \
    $(PDFVIEW) $(DOC).pdf; \
   elif [ $(TEX) == latex ]; then \
    $(MAKE) $(DOC).dvi; \
    $(DVIVIEW) $(DOC).dvi; \
   elif [ $(TEX) == pdflatex ]; then \
    $(MAKE) $(DOC).pdf; \
    $(PDFVIEW) $(DOC).pdf; \
   fi

# Idem ao "show", a diferença é que aqui 
# é feito uma nova compilação, de um jeito ou de outro
shownew:
   $(MAKE) cleanall
   @if [ ! -z $(PROSPER) ]; then \
    $(MAKE) $(DOC).dvi; \
    $(PDFVIEW) $(DOC).pdf; \
   elif [ $(TEX) == latex ]; then \
    $(MAKE) $(DOC).dvi; \
    $(DVIVIEW) $(DOC).dvi; \
   elif [ $(TEX) == pdflatex ]; then \
    $(MAKE) $(DOC).pdf; \
    $(PDFVIEW) $(DOC).pdf; \
   fi

# Idem ao "show", mas para arquivos PDF apenas
showpdf: 
   $(MAKE) $(DOC).pdf
   $(PDFVIEW) $(DOC).pdf

# Idem ao "shownew", mas para arquivos PDF apenas
shownewpdf: 
   $(MAKE) cleanall    
   $(MAKE) $(DOC).pdf
   $(PDFVIEW) $(DOC).pdf

# }}}

Nesse ponto, espero que tenham compreendido o suficiente do código para compreender o que foi feito. Pois o objetivo é visualizar o arquivo. Se for um DVI abrir o visualizador de DVI, se for um PDF abrir um visualizador de pdf, caso não exista o arquivo, crie-o.

Os blocos com "new" no nome, são assim definidas porque eliminam o pdf/dvi que eventualmente exista, compila novamente e exibe o novo arquivo.

Os blocos com "pdf" no nome, força que seja visualizado o pdf, não importa qual o processo que o gera. Os demais vão exibir o DVI sempre que esse for válido/existir ou o PDF, em contrário.

Finalizando

O último bloco (que eu não vou transcrever para esse ponto) é o bloco help, que permite que o usuário digite "make help" para descobrir quais são os comandos diponíveis.

Conclusão
Esse texto ficou longo demais. Então vou ser breve.

Falta discutir alguns pontos e abordar um Makefile para programação em si (ou seja, para arquivo C/C++/Fortran). Assim como algumas normas de etiqueta para esses tipos de Makefile. Entenda: existem nomes de variáveis que são reconhecidos por qualquer programador no mundo, como GCC_FLAGS, porque usá-las ou não usá-las. E finalmente discutir porque usar o Makefile e não um shellscript. Existem fatores que induzem a usar o Makefile, mas se é apenas para você, porque usar o make ? Mas não prometo a terceira parte para logo...

Uma quarta parte agendada para daqui a muito (muito mesmo) tempo, seria como lidar de forma correta com as opções dentro do Makefile. Esse é o ponto mais delicado e complexo e daria um ar profissional ao Makefile (como os dos grandes programas). Mas é também o que dá mais trabalho, portanto, exige planejamento e detalhamento ... e tempo para escrever.

Nemiver: Interface gráfica para o gdb

2009-06-11T01:00:00.000-03:00

Uma das grandes dificuldades de utilizar o vim como uma IDE de programação é que este, apesar de vários esforços em contrário, não possui um interface amigável para realizar um debug em um programa. Diga-se de passagem, isso é ponto para emacs, que possui esse tipo de recurso.

Pode-se dizer que o gdb é "A Interface". Digo, muito provavelmente um profissional qualificado deve conhecer o suficiente do gdb para usá-lo no terminal. Eu ainda não cheguei nesse nível.

Na busca de uma interface gráfica, eu encontrei o Nemiver. Uma leve é muito competente interface gráfica do projeto GNOME para o gdb.

Possui o básico, breakpoints, next, step in e out, monitorar valores, etc e etc. Não me deixou na mão em nenhum ponto que eu considere crucial.

Dica rápida, abra o aplicativo executável compilado com a opção de debug e depois abra o código fonte através da opção "Selecionar do alvo executável". Lá estão todos os códigos que compõem aquele aplicativo. A ajuda é interessante. Realmente ajuda nos pontos chaves.

Seu concorrente mais próximo em objetivo é o KDbg, mas, seguindo a diferença básica entre GNOME e KDE, o Nemiver possui uma interface muito mais limpa e objetiva.

Colorindo as "man pages"

2009-06-07T11:15:00.002-03:00

Para colorir uma página de manual sem alterar o paginador padrão do comando man, defina as linhas abaixo no ~/.bashrc.

#  begin blinking
export LESS_TERMCAP_mb=$'\E[01;31m'
#  begin bold
export LESS_TERMCAP_md=$'\E[01;33m'
#  end mode
export LESS_TERMCAP_me=$'\E[0m'
#  begin standout-mode - info box
export LESS_TERMCAP_so=$'\E[01;41;37m'
#  end standout-mode
export LESS_TERMCAP_se=$'\E[0m'
#  begin underline
export LESS_TERMCAP_us=$'\E[01;32m'
#  end underline
export LESS_TERMCAP_ue=$'\E[0m'

Recarregue o ~/.bashrc (abra uma nova janela do terminal após salvar o arquivo) e digite "man man" (página de manual do comando man) para ver como ficou o resultado.

Traduzindo

Blinking é piscando ... você já viu alguma coisa piscando no man ? Eu não faço idéia de onde a configuração de "begin blinking" vai atual... eu não vi o vermelho (número 31) em negrito (01) em lugar algum das páginas que verifiquei.

A variável relativa a "begin bold" refere-se ao conteúdo que tradicionalmente está em negrito, ou seja, nomes dos programas e opções da maioria das páginas man. Bem como títulos de seções. O 01 refere-se ao negrito (sugiro fortemente que mantenha) e 33 é amarelo.

A variável relativa a "begin standout-mode" refere-se aquela caixa que fica na parte de baixo da janela e indica a a linha (posição relativa e absoluta no texto). Nessa configuração pessoal, eu usei 41, que refere-se ao background com cor vermelha e branco (37) como cor da fonte.

A variável relativa a "begin underline" refere-se ao conteúdo que tradicionalmente está em sublinhado. Aplica-se quase todos os valores das opções da página de uma manual. No meu exemplo, eu utilizo 01, que é referente a negrito, e 32, que é a cor verde.

Todos os "end alguma coisa" refere-se a restabelecer a coloração normal do texto após aplicar a modificação de cor. A menos que queira um carnaval de cores sem sentido na sua página de manual, é conveniente manter a configuração acima.

As cores

O código de cores e efeitos é simples. As Funções ZZ inclui uma função que lhe ajuda com essa tarefa, mas você não precisa instalar a mesma para usar as cores, basta visitar a página de testes para descobrir quais são as cores que lhe interessa.

Na prática, onde está 01 acima, pode variar entre 00, modo normal, 01, modo em negrito. O 04 forma escrita sublinhada (e eu não sei porque), pois o bom senso diz que o 02 e 03 deviam existir... Pois, ... acho que o bom senso não foi respeitado, pois não funciona comigo... ou que deve ter algum significado especial esse 04.

Onde lê-se 41 nas variáveis acima, pode-se alterar entre 40 e 47. Aí a figura da página das funções ZZ ajuda, pois essa configuração refere-se a cor de fundo.

Onde lê-se 37, ou melhor, números na casa de 30, pode-se usar números entre 30 e 37 e essas referem-se a cor da fonte. Novamente o link da página de testes da funções ZZ ajuda muito, porque você deve combinar os valores de fundo e fonte para que tudo fique visível. Note inclusive que seria muito ruim usar uma fonte azul com um fundo preto...

Nota: 30 é preto, mas preto com negrito fica cinza e torna-se visível sob o fundo preto. Observe que existe uma grosseira variação na tonalidade da cor conforme o status da fonte. É basicamente por isso que uso negrito em tudo acima. Torna o que é importante mais nítido...

Não funcionou ?

Infelizmente, a configuração acima não funciona em qualquer distribuição. Eu conheço essa dica a muito tempo, mas não funciona(va) no openSUSE... Há um tópico no fórum que tenta esclarecer alguma coisa (mas cuidado, porque lá tem alguma informações trocadas/erradas), tudo que consegui foi colocar a "info box" colorido... o que não adianta nada. Eu só pude confirmar que essa dica realmente funcionava hoje, no Arch Linux.... Nunca testei no Ubuntu

Alternativas ?
No Viva o Linux possui uma dica que ensina como usar o most como paginador do man e uma dica de como criar uma função para ler o resultado do man no vim nos comentários. A dica sobre o most e o man você também encontra em outros lugares, como aqui.

E falando do vim, no wiki existe uma dica mais completa (com várias dicas nos comentários adicionando outras informações) de como colocar o vim para ser o leitor das páginas de manual que eu ainda não testei, e não sei se testarei, mas inclui uma personalização da sintaxe, o que é necessário, pois o padrão não é muito bom.

No meu vim, essa dica também funciona.

Nem tudo fica colorido ?

Curiosamente, o vim é o único que permitiria você de adivinhar o que deve ou não colorir. Entenda que por padrão, não há como o paginador comum (seja ele qual for), adivinhar o que deve ser colorido sem a formatação da página informe isso a ele. Ou seja, o que não está em negrito e o que não está sublinhado, não será identificado como um ponto a ser colorido... e nem tudo que devia ter sofrido com essas modificações de formato de fato sofreram em algumas páginas de manual (veja "man find" ou "man vim" e compare com "man man" e "man cp").

E é aí que o vim pode levar vantagem, pois pode-se alterar a sintaxe para ele utilizar expressões regulares para identificar o que é uma opção, valor, etc, etc. Infelizmente, isso não é o padrão.

Mudando radicalmente a distribuição

2009-06-06T16:00:00.000-03:00

Imagine dirigindo um caminhão e mandando esse caminhão fazer uma curva para direita. Agora, imagine que ao fazer isso, o caminhão vire para a esquerda. Consegue ver um problema aqui ?

Pois é exatamente assim que eu estava me sentindo ao usar o openSUSE 11.1. Pela terceira vez em 2 meses ele "quebrou algum recurso". Dessa vez o locale foi corrompido, e assim como eu já havia visto em outro computador, ele "acreditou" que eu estava utilizando uma codificação exótica da qual eu nunca tinha ouvido falar...

Quem já usou o openSUSE sabe o quanto somos reféns do yast. Se o Yast diz que eu estou utilizando UTF-8, o que eu poderia fazer ? Editar o arquivo na mão ? Não no openSUSE. No openSUSE não se edita diretamente NENHUM arquivo de configuração. O máximo que eu poderia fazer é editar um arquivo que seria o responsável de editar o outro arquivo (é... arquivo que gerencia arquivo).

Por esses motivo é perdi definitivamente a minha paciência com o openSUSE e instalei o Arch Linux.

Por que o Arch Linux ?

Se eu escrever: vire a direita, ele vira a direita... se isso está certo ou errado é problema meu.
Possui um excelente gerenciador de pacotes.
São raras as perguntas sem respostas. Digo, é a maior taxa de solved/resolvido por unidade de tópicos que eu já vi em um fórum.

E a instabilidade ?

Mais instável do que andava a última versão do openSUSE ? Definitivamente, não. Além disso, como eu disse, para toda pergunta existe uma resposta, assim, quando há um problema, surge uma solução ... De qualquer forma, assim que eu terminar de configurar o sistema eu irei fazer um backup de partição para assegurar uma restauração rápida em caso de necessidade. Afinal, minha máquina principal é uma máquina produtiva e as vezes não pode parar. Embora, eu tenha uma máquina na universidade que sempre pode me servir em caso de necessidade (eu trato essa máquina de forma mais conservadora, limitando programas existentes, freqüência de atualizações, etc, assim, nela o openSUSE ainda está ok).

Ainda assim, existe um ponto a ser levado em consideração. A tal da instabilidade é teórica. Digo isso porque até agora, eu só vi estabilidade e soluções de problemas. Tudo que não funcionava no openSUSE está funcionando agora. Exemplo, o gerenciador de discos removíveis encriptados, que não funcionava no meu openSUSE corretamente.

Mais a melhor impressão que tive do sistema sobre essa questão foi quando eu abri o krename. O krename existente no openSUSE foi compilado com o KDE4 e não funciona. O disponível no Arch Linux foi compilado com o KDE3 e FUNCIONA. Qual dos dois foi menos responsável ?

Por tudo isso e mais alguma coisa, a tal instabilidade é teórica. Espero alguma turbulência em grandes upgrades que possam requerer alguma modificação grosseira no arquivo de configuração. Nada além disso.

Problemas ?

Claro que eu tive problemas !!! Mas como disse acima, todos os problemas tinham solução em algum lugar da internet.

É engraçado como o sistema, por exemplo, me lembrou que eu tenho duas placas de rede na máquina (eu só uso uma, a outra sempre fica desabilitada), mas eu demorei a correlacionar o fato de ter uma instabilidade em conseguir conectar ou não por conta da ordem de leitura dos módulos delas... Mas é a tal coisa, para instalar o Arch Linux deve conhecer sua máquina. A distribuição não perdoa quem esquece esses detalhes...

Alguns problemas, ou melhor, questões, estavam associados ao pouco uso do pacman e ao desconhecimento de nomes de pacotes e seu conteúdo. Um exemplo, como eu saberia a priori que o okular estava no pacote kdegraphics ? Mas todas essas perguntas são respondidas por alguém.

Todos os meus problemas foram solucionados em menos de 1 dia. Recorde histórico nesses mais de 10 anos de uso do GNU/Linux. Seria eu aprendendo alguma coisa ou o sistema não querendo mais informação do que a necessária ?

Uma curiosidade

Para um sistema que requer que eu configure o teclado com um arquivo de configuração escrito manualmente, foi muito curioso encontrar tantas linhas de configuração no /etc/vimrc e /etc/gvimrc. São vários detalhes que me obrigam a alertar sobre a necessidade de olhar esses dois arquivos antes de usar os programas. O problema está para quem já tem um .vimrc e não quer configurações conflitantes entre os arquivos. Por tudo isso, eu sugeriria uma remoção significativa do conteúdo desses dois arquivos...

E porque eu usava o openSUSE mesmo ?

Resposta fácil. Na época que comecei a usá-lo, era a única distribuição que compilava o openFOAM (programa livre para simulação CFD). E o sistema não foi ruim. Na verdade eu gostei muito da versão 10.3, apesar de me sentir um pouco incomodado com o excesso de camadas entre minhas edições de configuração e os arquivos de configuração propriamente dito e com a velocidade do Yast. A verdade é que tudo funcionou e eu não podia desejar menos. E a inércia faz com que continue-se utilizando a mesma distro quando tudo vai bem (especialmente com as melhorias do Yast). Mas os problemas atuais do openSUSE 11.1 foram fatais, sistema estava lento demais, demorava muito para abrir alguns módulos do Yast quando não o próprio GNOME (chegava ao ponto de ser possível fazer um lanche enquanto o sistema dava boot), alguns erros "sem lógica" apareciam do nada, etc. O último problema, que foi o de codificação, foi fatal. Se eu o usasse por mais tempo eu correria o risco de corromper todos os meus arquivos. Seria uma tragédia. Tradicionalmente, eu restauraria a partição de um backup estável, mas resolvi por um fim nisso. Pelo menos em casa. Na universidade eu vou esperar aparecer um "problema-desculpa" para usar o Debian.

g3data

Ainda não aprendi como fazer contribuições, mas o único programa que instalei que não estava nos repositórios oficiais é o g3data. Um simpático programa para interpolar gráficos que estão em formato de imagem (png, pelo menos, nunca tentei com outro). Ele está no AUR, mas desatualizado (ok, pouquinho desatualizado, mas sabe como é, não ?). Então eu criei o meu próprio PKGBUILD. Para ser bem honesto, eu apenas peguei o que estava no AUR e modifiquei os campos necessários.

Eu não vou contribuir oficialmente enquanto não ler toda aquela documentação que parece existir por aí. Afinal, se eu fizer algo errado não vai ser por omissão. E espero não cometer nenhum pecado ao fazer essa modificação e disponibilizá-la aqui...

Comentários finais

Espero ter tempo para aprender alguma coisa sobre o AUR.

É realmente maravilhoso utilizar o /etc/rc.conf para configurar o sistema.

Claro que eu instalei o tema padrão do Ubuntu no meu Arch Linux... (para quem não sabe, é o meu tema predileto). Até isso ficou melhor no Arch Linux do que no openSUSE, que adora reclamar do tema...

Tenho minhas dúvidas se eu vou escrever alguma dica para o Arch Linux nesse blog. Não sei se vou aprender algo que não tenha sido detalhadamente divulgado por outro em algum lugar e eu raramente repito assuntos que possam ser encontrados na internet, exceto quando é algo que considero muito raro ou importante. Acho que gastei todo meu conhecimento inédito nesse tópico... Mas provável é que eu escreva reviews sobre certos assuntos...

Eu agora tenho nautilus-actions. Não funcionava no openSUSE como devia (dava trabalho para instalar e funcionava a meia-boca)

E o nautilus mostra os modos de "visão de ícones/em lista/compacta" ao lado da barra de enderenços (o openSUSE não mostra ela, penso que era uma configuração, mas nunca achei como restaurar ao "normal")

Eu agora tenho gdmsetup. Estava com saudades dos bons e velhos aplicativos...

As fontes estão mais bonitas... e eu não fiz nada para isso...

E o OpenFOAM ? Bem, se por acaso de um dia ensolarado eu necessitar de ter a versão de desenvolvimento novamente na minha máquina pessoal. Com 100% de certeza não será para executar coisa alguma. Agora existe uma versão instalada em um cluster do lab. Logo, me basta saber o usar bem o editor de textos via terminal (entenda, vim ou emacs). Mas ainda que esse cenário mude, o OpenFOAM tem mostrado uma filosofia de empacotar sua própria versão de tudo. Portanto, tudo que eu teria é trabalho em ler os arquivos de configuração e a documentação e assim determinar exatamente quais são os componentes necessários (e suas respectivas versões) para uma compilação com sucesso. Aliás, hoje é mais fácil compilar o OpenFOAM no Ubuntu do que no openSUSE de forma que todos os argumentos que nos levaram a utilizar o openSUSE foram destruídos.

Sinceramente, espero nunca ter que abandonar o Arch Linux.
É muito agradável, leve, simples, etc.

Uma introdução ao comando make

2009-06-04T22:20:00.001-03:00

Eu peço uma licença poética a todos para facilitar aqui a explicação sobre o que é o comando make. Considere este um dos programas mais complexo e mais simples do universo *nix. Essa contradição somada a um rico e super-direto manual, tende a não fornecer uma das melhores famas a esse programa.

O programa.

O make é um programa como qualquer outro, normalmente instalado no GNU/Linux como um pacote independente. Sua função é muito simples. O make executa instruções contidas em um certo arquivo. Digitando apenas make no terminal, o comando busca pelo arquivo Makefile existente dentro do mesmo diretório onde foi executado. O arquivo com as instruções pode ser manualmente especificado com a opção -f. Nesse caso, ele pode estar em qualquer diretório e ter
qualquer nome.

O arquivo Makefile - Conceitos básicos.

Me permitam fazer o paralelo de associar a idéia de um Makefile, com um script para shell. Pois os dois possuem a mesma função prática.

O script executa instruções divididas de acordo com opções pré-estabelecidas no seu interior. O make executa instruções estabelecidas de acordo com cada uma dos blocos de instruções de um arquivo Makefile.

O Makefile, portanto, contém instruções em série de algo que deseja fazer. Exatamente da mesma forma que seria, caso estivesse escrevendo um script.

O Makefile é dividido em blocos de comandos. Cada bloco possui um nome, e esse nome tona-se um argumento para o comando make.

Veja um exemplo de bloco:

clean:
    rm -vf *.backup
    rm -vf *~
    rm -vf *.o

O nome do bloco é "clean".
As instruções são para utilizar o comando rm com as opções -vf (verbose e force).
Eles estão uma linha abaixo do nome e separado de pelo menos uma tabulação da primeira coluna da lina.

O uso do make.

Tradicionalmente, o uso básico do make consiste em algumas poucas opções:

make
Digitando apenas make no terminal, o programa procura pelo Makefile e executa o primeiro dos blocos de comandos existentes dentro desse arquivo.
make -f ARQUIVO
Esse exemplo é igual ao anterior, mas o arquivo Makefile está em um lugar qualquer do disco, com um nome qualquer também... Não é um uso comum.
make dothat
Nesse exemplo, dothat representa o nome de uma das instâncias existentes dentro do arquivo Makefile.
No nosso simples exemplo, poderíamos escrever "make clean" e ele executaria as instruções daquele bloco naquele comando. Note que se "clean" for o primeiro bloco de comandos, digitar apenas "make" ou "make clean" produz o mesmo resutado.

No próximo texto sobre o assunto, estudaremos um Makefile detalhadamente. Será o Makefile que eu escrevi e disponibilizei para compilar o códigos em LaTeX. Não é um Makefile tão simples, nem tão complicado. Dará um interessante estudo de caso.

Nova forma de disponibilizar scripts e arquivos de configuração

2009-06-04T22:00:00.000-03:00

Eu perdi a paciência com o Snipt mais rápido do que eu podia imaginar.

Assim, na busca de um lugar que pudesse aceitar os meus pequenos arquivos de configuração e scripts, eu me optei pelo Google Sites.

O Google Sites está muito melhor que o falecido Google Pages e conta com um número muito bom de recursos, inclusive, com formas específicas para compartilhar artigos que o tornam muito próximos de um "Google Drive" (vide template "File Cabinet"). A disponibilidade de 100 MB é muito mais do que eu preciso para compartilhar arquivos de configuração...

A escolha natural do Google Sites dá-se depois de pensar em como transferir os arquivos que eu compartilho via Google Pages (que com o fim deste, serão automaticamente transferidos para o Google Sites).

Bom, os três arquivos compartilhados recentemente nesse blog, o ~/.vimrc, o Makefile para LaTeX e o latexfilter, foram atualizados para a última versão e transferidos para o Google Sites. Note no fim de cada uma dessas páginas a existência do arquivo anexado.

Todos os arquivos de configuração e scripts disponibilizados aqui estão disponíveis na barra lateral do blog. E serão atualizados silenciosamente quando tiverem apenas algumas pequenas correções...

Não tenho certeza de que vou atualizar os links nos tópicos oficiais, o mais provável é que fique como está...

Nota: Para gerar essas páginas bonitinhas, abra o arquivo vim, selecione o esquema de cores de sua preferência e digite no modo de comando:

   :so $VIMRUNTIME/syntax/2html.vim

No meu .vimrc, existe um mapeamento que correlaciona o \2html em modo normal com esse comando acima. O gvim exibe em "Editar" > "Esquema de cores" todos os esquemas de cores que possui instalado.

.vimrc atualizado

2009-06-03T18:30:00.001-03:00

O meu .vimrc foi atualizado.

A nova versão possui tantas melhorias que nem seria possível listar tudo nesse blog.
Destaques, além das importantes pequenas correções, vão para:

Correção ortográfica. Com correção simultânea a digitação por duas formas diferentes. Destaque para palavras repetidas uma após a outra (tipo oi oi), entre outras. Nota para modificação do acesso ao dicionário que contorna um bug que eu encontrei...
Esquema visual aprimorado com função para identificar a resolução do monitor e ajustar a fonte no gvim (dependente de variável no .bashrc)
Ajustes para lidar com textos encriptados pelo GNU GPG.
Para LaTeX, temos a integração da bibliografia de um arquivo arquivo .bib com um dicionário para autocompletar.
e o ajuste da forma de realizar a verificação do log gerado pelo vim (sintaxe e integração de script).

Do mais, se alguém tiver uma dica de algo que seja muito melhor que Snipt, favor me informar. Ele não é ruim, mas me parece muito pesado...

Snippets

2009-06-01T13:40:00.003-03:00

Snippets são trechos reutilizáveis de código ou texto. Normalmente escreve-se uma palavra chave e um TAB e o trecho é inserido no conteúdo atual. Existe para mais de um editor de textos (vim, gedit, etc).

O maior problema dessa idéia brilhante é que é necessário configurar seus snippets. Não seria legal se você pudesse usar o que outras pessoas já fizeram ?

Pois, olhe os links externos da referência sobre snippet na wikipédia.

Infelizmente, a forma de escrever um snippet varia um pouquinho entre editores, mas nada que comprometa o reaproveitamento, pois escrever um snippet é algo muito simples.

A premissa é que você gasta tempo agora (e não vai ser tão pouco assim, um dia, pelo menos) configurando o que será necessário várias vezes ao longo de sua produtividade (o que lhe fará ganhar muitos dias). O ganho de tempo é extraordinário.

Agora, falta apenas uma extensão para o Firefox. Na verdade a extensão até existe, mas é experimental e para versão 2.0, ou seja, não existe de fato...

O domínio desse blog

2009-05-31T12:00:00.002-03:00

Problema resolvido... agora, outra mensagem dessa apenas em 2010.

Senhores, acabo de consultar o painel de controle da LocalWeb e eles ainda não contabilizaram o meu pagamento anual pelo domínio...

Não é algo completamente inexplicável, porque eu fiz o pagamento no dia 27 último por boleto bancário. A questão é que o prazo vence no dia primeiro (amanhã). Assim, se por qualquer motivo não houver acesso correto a esse blog, já sabem... o blog não morreu, está apenas descansando.

Problema resolvido... agora, outra mensagem dessa apenas em 2010.

Filtrando o log do LaTeX

2009-05-30T20:20:00.003-03:00

Quem está acompanhando, sabe que estou envolvido em simplificar minha vida para usar o vim como plataforma de desenvolvimento (parte 1 e parte 2).

Mais uma etapa do que diz respeito ao uso do LaTeX com o vim foi vencida com o script latexfilter.

Trata-se de um script MUITO simples que filtra os erros, alertas e informações de overfull e underfull box. É claro que o processo formata a saída de uma forma mais ou menos elegante.

Veja um exemplo, usando nomes fictícios:

./book.tex
Package pdftex.def Warning: Option `bb' does not make sense,
LaTeX Warning: Float too large for page by 120.685pt on input line 116.
Underfull \hbox (badness 10000) in paragraph at lines 142--145
./introducao.tex
Underfull \hbox (badness 10000) in paragraph at lines 211--213
Overfull \hbox (4.15698pt too wide) in paragraph at lines 214--227
./modelagem.tex
LaTeX Font Warning: Font shape `T1/aett/bx/n' undefined
LaTeX Warning: Reference `fig:experimentob' on page 2 undefined on input line 1
LaTeX Warning: Reference `fig:experimentob' on page 2 undefined on input line 1
! LaTeX Error: File `figuras/experimental/esquema_semnomesDDD' not
Underfull \hbox (badness 10000) in paragraph at lines 701--707
Overfull \hbox (21.79932pt too wide) in paragraph at lines 772--772

Esse exemplo, mostra o nome do arquivo, seguido das mensagens associadas a aquele arquivo, o nome do arquivo seguinte e suas mensagens, etc e etc. Observe que em alguns casos, uma certa mensagem está acompanhada da informação da linha (lines) no final da linha. Essa informação corresponde a linha dentro do arquivo cuja a relação de problema é feita.

Fica tudo muito simples. Ficará mais simples ainda quando eu mandar o vim aplicar o filtro e abrir o arquivo, reconhecendo palavras chaves e identificando-as com cores, com uma única tecla de atalho...

Makefile para LaTeX

2009-05-30T14:15:00.002-03:00

Acabo de concluir um Makefile para LaTeX.

Ele identifica a existência ou não de bibliografia, índices, glossários e nomenclaturas e qual é o nome do arquivo principal da estrutura do documento. Também agiliza as coisas para quem usa o prosper (para fazer apresentações com o LaTeX). Pois, nesse caso, apenas o PDF interessa. Note que essa questão existe unicamente para meu próprio conforto.

Não se pode ter dois documentos principais (ou seja, com o \begin{document}) com a extensão .tex no mesmo diretório (bom, até pode, mas o resultado é imprevisível). Se a extensão desse segundo for .tex.old não tem problema algum. E se o \begin{document} estiver comentado, o Makefile o ingnora.

Esse Makefile não trata arquivos .ps. Eu não gosto desses arquivos e por isso ele não é tratado, embora, em alguns casos, ele seja criado como um arquivo intermediário.

Esse script suporta o comando latex e o comando pdflatex. O primeiro gera um .dvi, que nesse script deve ser convertido para .ps e depois para .pdf (existem outras formas, mas não estão implementadas). O segundo gera um pdf diretamente.

Alguns do programas internos podem ser configurados (com o valor da variável TEX, que pode ser latex ou pdflatex ou o nome dos visualizadores de arquivo). Além de opções internas de cada comando. Nota-se que alguns comandos não podem ser modificados facilmente. Isso foi feito para ser assim mesmo. O caso mais "polêmico" é que a única forma de converter o .ps para o .pdf implementada é com o ps2pdf.

Para ajuda, digite "make help" no terminal dentro do lugar onde está o Makefile (com esse nome) ou "make -f ArquivoMakefile help" caso tenha modificado o nome do arquivo.

Esse arquivo Makefile faz parte do esforço para transformar o vim em uma suíte completa para o LaTeX. Esforço esse quase concluído (eu ainda não divulguei outras melhorias já existentes), falta apenas melhorar a análise de "warnings" e "errors" do arquivo .log criado. A leitura direta do .log retarda muito a identificação dos erros. Portanto eu irei destacar as palavras chaves de alerta e erro para encontrar rapidamente a informação que interessa no log.

Configurando o vim

2009-05-28T00:45:00.004-03:00

Recentemente eu resolvi configurar definitivamente o meu .vimrc.

Isso é mais trabalhoso do que parece.

Antes de mais nada, qual é o meu perfil ou o que eu preciso do vim (ou de um editor)?

Eu escrevo, e muito, em LaTeX, quase tudo que escrevo é em LaTeX ou texto puro.
Eu programo em FORTRAN. E nem me diga que isso é coisa do passado (ainda que de fato seja).
Pretendo programar em C/C++. Ainda em que processo (lento) de estudo, um dia eu chego lá.
Eu uso muito shellscript (quase sempre em uma função muito pessoal para ser publicada).
Irei programar em Python (pena que não estou com tempo para estudá-lo).
Quero um corretor ortográfico (português e inglês).
Necessário um recurso de auto-completar códigos (especialmente para o LaTeX).
Gerenciamento de projetos, o que significa gerenciar tags e arquivos.
Programação para web básica, voltado ao mínimo necessário para escrever no blogger (as vezes eu escrevo antes no meu computador)

Definidos os meus objetivos, o como resolver isso é que era o problema. Contar a história na ordem cronológica dos eventos seria muito complicado. Então, vamos aos resultados.

Status atual do meu vim em relação aos meus objetivos :

Para LaTeX está quase completamente pronto (aprende-se coisas novas todos os dias, o que ontem era pronto, hoje ainda tem coisas para fazer). O FORTRAN está em versão minimalista. Para C/C++ eu ainda não fiz muito (algumas medidas para o LaTeX aplicam-se aqui diretamente). Quanto ao shellscript, não pesquisei nada além do mínimo.
Para o Python existem muitas dicas, ainda não tive tempo e/ou paciência para ler tudo, mas é impossível deixar de ler tópicos sobre o assunto.
O corretor ortográfico básico está implementado, mas ainda não é a melhor solução. O recurso de autocompletar foi aplicado para o LaTeX, é uma mistura de dicionário com o snipMate e de dicionário propriamente dito. O gerenciamento de projetos foi estabelecido com uma unificação da taglist (plugin que integra o ctags ao vim) e NERDTree (plugin que gerencia arquivos em disco). A programação para web eu já fiz alguma coisa, mas, no momento, não é nada que valha apena divulgar (além do meu .vimrc).

Em uma versão mais completa, segue minha lista de plugins atual.

txt.vim - Estilo para escrever arquivos de texto
fortran.vim - Melhorias para a sintaxe em FORTRAN
taglist - Integra o ctags ao vim
NERDTree - Gerenciador de arquivos via vim
snipMate - Completa trechos pré-configurados (não sei como consegui sobreviver até hoje sem usar um plugin do tipo, e olha que eu conhecia o similar dele para o gedit)
PotWiki - Wiki para gerenciar tarefas e pequenos textos
Calendar - Calendário integrado ao vim.

Como eu mostrei acima, meus objetivos ainda não foram completamente alcançados. O motivo pelo qual eu estou escrevendo agora, é para não deixar o tópico seguinte ser muito longo.

Mas a configuração do LaTeX está bem desenvolvida. Então, vamos lá.

Primeiro instale os plugins, especialmente o taglist, o NERDTree e o snipMate.

Agora pegue meu arquivo "tex.snippets" e substitua o original (cuidado com os tabs, você não pode perder as tabulações no processo de cópia), ainda que você não tenha o meu estilo de escrever em LaTeX, certamente você não escreve como o snipMate acha que você escreve. Aliás, os snippets existentes valem mais como exemplos do que como função prática, parece até que é intencional.

Leia esse texto sobre como integrar o LaTeX com o taglist.
Basicamente consiste em criar (ou editar) um arquivo ~/.ctags e adicionar o conteúdo:

  --langdef=tex
--langmap=tex:.tex
--regex-tex=/\\subsubsection[ \t]*\*?\{[ \t]*([^}]*)\}/- \1/s,subsubsection/
--regex-tex=/\\subsection[ \t]*\*?\{[ \t]*([^}]*)\}/+\1/s,subsection/
--regex-tex=/\\section[ \t]*\*?\{[ \t]*([^}]*)\}/\1/s,section/
--regex-tex=/\\chapter[ \t]*\*?\{[ \t]*([^}]*)\}/\1/c,chapter/
--regex-tex=/\\label[ \t]*\*?\{[ \t]*([^}]*)\}/\1/l,label/
--regex-tex=/\\ref[ \t]*\*?\{[ \t]*([^}]*)\}/\1/r,ref/

Essas linhas são as definições de tags. As quatro primeiras são a estrutura de capítulos a "subsubseções". as duas últimas referem-se sobre labels e referências.

Agora instale meu .vimrc, ou melhor, instale o que te interessa, porque o meu vimrc não vai funcionar assim, a frio, na sua máquina. Quando a configuração estiver completa eu disponibilizarei o diretório .vim também (com todos os scripts adicionais).

Ele está muito bem dividido e comentado, quem quiser apenas a parte LaTeX não terá qualquer dificuldade em fazê-lo, mas observe que o meu resultado está vinculado a configuração do taglist e do NERDTree, assim como configurações escolhidas para mapeamentos e abreviações. Portanto, ler a coisa de uma forma geral pode ser muito interessante.

Aqui eu quero destacar uma certa solução. A de complementação de palavras.
Será visto no .vimrc:

  au BufNewFile,BufRead *.tex set dictionary=~/.vim/dict/latex.dic

O dicionário não está acumulativo, ou seja, que abre o arquivo tex não terá acesso a dicionários gerais, assim foi feito intencionalmente para
evitar sobreposição desenecessária de dicionários. Caso também queira outro dicionário (de palavras, por exemplo) adicione

  au BufNewFile,BufRead *.tex set dictionary+=/CAMINHO/SEU/DICIONARIO.dic

após a linha mostrada anteriormente, isso fará com que o dicionário latex.dic seja o primeiro listado e em seguida o seu dicionário.

Nesse dicionário latex.dic está o pulo do gato. Ali eu escrevi as palavras chaves do snippets (portanto, eu não preciso publicar isso). Porque eu tenho muitos snippets e no futuro terei ainda mais (com pedaços de esquações, por exemplo) e eu não memorizarei tudo assim, como se eu fosse um HD.

A configuração do dicionário está relacionada as teclas <F7>, <F8> e <C-D>

A outra linha de configuração eu devo agradecer ao Kile. Eu peguei os dicionários do Kile e coloquei usei...

Como havia alguns probleminhas, eu editei o conteúdo dos dicionários para que eles apareçam corretamente com as teclas de mapeamento.

Assim, todo espaço foi eliminado, o traço e a vírgula, viraram ponto. No primeiro momento parece que é um erro grave, mas o espaço e o traço não são comandos/opções LaTeX. A vírgula, por outro lado, é um opção LaTeX. Mas fica muito fácil saber onde tem vírgula e onde não tem, porque, vírgula surge apenas em dois lugares, nas opções e em coordenadas. As coordenadas são fáceis de identificar, porque estão entre (X,Y), por exemplo. As opções não. Porém, a questão é que não há a menor chance de uma pessoa se confundir aqui porque ou isso aparece em opções que você sabe usar (logo não há problemas) ou aparece em opções que você não sabe usar, logo, terá de consultar o manual e não terá qualquer problemas então. O objetivo é oferecer dicas, não ensinar LaTeX.

  au BufNewFile,BufRead *.tex set dictionary+=~/.vim/dict/tex/*.cwl
  \ iskeyword+=\\,.,{,},[,],*,=,/,(,),>,<

O diretório "tex" do caminho acima, você pode pegar aqui. Dentro dele verá um diretório chamado "notinuse", são onde estão os comandos de pacotes que eu não uso (ou não estou interessado em ajuda). Para se ter uma idéia, no Kile padrão, apenas o latex-document.cwl e o tex.cwl são usados (e eu estou usando muito mais que isso). Os demais são desabilitados (recomendaria habilitar, no mínimo, o latex-mathsymbols.cwl, mas esse é um pensamento matemático). Dá para notar que quanto mais verbetes no dicionário, mais lento fica. Então, o ideal é criar o templates para o snipMate assim que perceber que algum comando está sendo mais usado do que imaginado inicialmente e com o tempo descobrir quais os pacotes você não quer habilitado nesse recurso.

Ainda não é a perfeição, mas agora o que o LaTeX está funcionando a pleno vapor, eu preciso trabalhar... então, eu devo ser mais lento nas implementações das minhas configurações para o vim.

Referências:

vimbook - tirei muitas dicas dali, mais do que isso, aprendi coisas para adaptar e escrever outras. Aliás, essa foi a força motriz para a iniciativa dessa configuração.
aurelio.net - referência clássica, mesmo que eu não tivesse visitado a página do camarada (e eu visitei), eu teria absorvido através de terceiros.
vivaotux - muitas dicas sobre vim (plugins e outras coisas).
Vim (Página oficial) - a documentação existente nesse site é fantástica.

Alguns arquivos vimrc:

A base inicial do meu trabalho foi o vimrc-ivan.txt completado pelos do voyeg3r (tanto o antigo quanto o novo), ou seja, eu juntei os três, tirei tudo que era duplicado ou que eu não queria e fiquei com o meu básico. Dos demais eu usei uma ou outra coisa apenas (o do aurélio é, como eu disse, pego pela onda das referências).

Por falar nisso, alguém conhece os scripts .vim que estão referênciados no arquivo vimrc do Ivan ? Porque parecem ser scripts fantásticos, mas não achei nenhum deles na net. Eu não sei se nunca foi publicado, por serem pessoais demais, ou se saiu do ar depois que a url que referência a página do Ivan deixou de ser correta... Se alguém tiver essa dica, comente, por favor...

Como colaborar com o livro "Introdução ao GNU/Linux"

2009-05-17T00:25:00.001-03:00

Para ajudar no desenvolvimento do livro, una-se a lista de discussão:

http://groups.google.com/group/introducaoaognulinux

Com isso você será adicionado como usuário do projeto do livro o que permitirá que faça as alterações via svn.

Você pode fazer as modificações e enviar para um dos autores (preferencialmente ao primeiro autor, que sou eu).

Uma forma simplesmente de colaborar é tendo idéias novas e boas para acrescentar. Deixe as idéias nos comentário na lista de coisas para fazer no wiki do projeto ou via e-mail para os autores.

Você também contará com o meu muito obrigado ao divulgar o material.

E por falar na lista de coisas para fazer, não custa lembrar que o livro é aberto, e que está em edição permanente (daqui por diante, em uma velocidade menor do que até aqui). Arquivos PDFs devem ser liberados com freqüência irregular, mas de tempos em tempos teremos uma nova versão estável do documento.

Quando digo estável, quero dizer que é uma versão acabada, onde uma certa idéia foi implementada como um todo no documento. Por exemplo, a versão 1.1 foi liberada hoje. Ela possui melhorias para quem utilizará o documento apenas em formato digital (inclusão do links clicáveis no documento) e algumas correções no português (na verdade, inglês. É "drivers" e não "drives"). Essa versão também inclui pequenas adições ao FAQ.

A primeira versão teve quase 1000 downloads. Espero que a versão 1.1 tenha tantos downloads quanto a 1.0 (afinal, "drives" é de matar).

Introdução ao GNU/Linux

2009-05-11T19:30:00.013-03:00

Em abril desse ano, eu apresentei o curso de extensão `Introdução ao GNU/Linux'' no Programa de Engenharia Química (COPPE/UFRJ).

Com o objetivo de prover uma referência por escrito e atualizada sobre o GNU/Linux, eu comecei a escrever um documento que ganhei volume e corpo de um livro. Livro esse que eu tenho o prazer de anunciar como um projeto livre.

O livro Introdução ao GNU/Linux está disponível para download em PDF, e código fonte

Ele foi escrito para um público que nunca teve contato com o sistema operacional GNU/Linux, mas não para quem nunca teve contato com computadores.

Sobre o Livro "Introdução ao GNU/Linux"

O GNU/Linux é um sistema operacional, que por definição é um programa responsável por conectar o usuário ao hardware, capaz de unificar o núcleo criado por Linus Torvalds em 1991 e diversas ferramentas criadas por terceiros.

Esse livro introduz ao leitor detalhes sobre (i) a arquitetura do GNU/Linux, partindo de um breve histórico até sua estrutura atual, (ii) os principais softwares para uso em computadores pessoais, como gerenciadores de arquivos, editores de texto, navegadores de internet, entre outros, (iii) os principais utilitários para uso de terminal, como man, ls, rm, cat, ssh, scp, entre outros e (iv) completando com um guia de sobrevivência na administração de um sistema GNU/Linux, apresentando os utilitários de configuração de rede, impressora, instalação de programas, além de outros pontos associados a utilização do GNU/Linux em computadores pessoais.

Sobre a licença do livro

O uso deste documento é regido pela licença GNU Free Documentation License, Versão 1.3 ou qualquer outra publicada posteriormente, da Free Software Foundation. Uma cópia dessa licença pode ser lida no anexo D do livro ou na página http://www.gnu.org/copyleft/fdl.html.

Infelizmente o Google Codes não permite que seja selecionado a licença GNU Free Documentation License, Version 1.3 ou superior como licença padrão do projeto, por isso, na barra ao lateral do site do projeto está escrito "GNU General Public License v3" e isso não é verdade. Por serem licenças complementares e compatíveis, eu não me preocupei. Caso alguém saiba de algo que eu não saiba, favor, informar.

A GNU Free Documentation License permite que você copie, modifique e/ou redistribua o documento inteiro ou parte do documento sobre os seus termos e respeitando as seções invariantes (no caso desse documento, são apenas as licenças em si).

A única exigência da GNU FDL é que os autores originais devem ser referenciados (não abre-se mão do direito autoral, algo que eu não poderia fazer nunca no Brasil) e de que a parte do conteúdo utilizado em outros trabalhos proveniente desse projeto (uma figura ou capítulo, por exemplo) também deve ser distribuído pela GNU FDL.

Como colaborar com projeto ?

Para ajudar no desenvolvimento do livro, una-se a lista de discussão: http://groups.google.com/group/introducaoaognulinux

Com isso você será adicionado como usuário do projeto do livro o que permitirá que faça as alterações.

Você pode fazer as modificações e enviar para um dos autores (preferencialmente ao primeiro autor, que sou eu).

Outra forma simples de colaborar é divulgando o material.

O que ainda resta a ser feito ?

Há uma lista de coisas a fazer e uma lista dos erros esperados.

Também tenho o objetivo de manter o livro atualizado. Idéia simples, fazer não é tão simples.

Novas versão em PDF devem ser lançadas periodicamente, conforme a atualização do documento.

Novas idéias são bem vindas.

Concurso Científico Tecnoclasta 2008/2009

2009-04-09T22:24:00.004-03:00

Apesar do pouco tempo, ainda há tempo. O prazo para o Concurso Científico Tecnoclasta 2008/2009 vai até amanhã, 10 de abril.

Já fiz a minha inscrição (com um tópico do Notas em CFD) - veja os inscritos nos comentários. Eu quase perdi o prazo... Talvez, considerando que o prazo termina na sexta-feira santa, ele seja estendido (~~mas não conte com isso~~). O prazo foi prorrogado até o dia 17 de abril.

Esse ano o concurso incluí duas categorias, uma das quais permite que quem não tenha blogs também participe. Veja as regras no tópico do Tecnoclasta.

Vale lembrar que mais do que um concurso com prêmios, essa iniciativa é uma forma divulgar informação científica de qualidade pela net.

Lamento de ter esquecido de divulgar o concurso antes e espero mesmo que tenha uma pequena prorrogação em função do feriado.

Micro dica vim, python e calculadora no OpenSUSE

2009-03-04T13:07:00.006-03:00

O Sérgio escreveu como usar uma calculadora científica no vim. Quem tentou seguir da dica dele no openSUSE recebeu um aviso informando que havia um problema na linha de comando.

E há um problema sim, mas com o vim, não com o comando. O vim padrão do openSUSE não tem suporte a python. Para resolver esse problema instale o pacote vim-enhanced e os seus problemas serão resolvidos. Simples assim.

Zenity e seus problemas no OpenSUSE 11.1

2009-02-14T20:30:00.003-02:00

Quando veio o OpenSUSE 11.1, veio um inconveniente. Todas as vezes que eu executava algum aplicativo com o zenity, ele abria em background.

Eu lidei com esse importuno por quase três meses e hoje eu finalmente fui a caça de uma solução. A primeira coisa que fiz foi instalar uma versão mais nova do programa via yast de repositórios da comunidade. Não funcionou. Então, eu compilei na mão o programa. Também não funcionou.

Aí eu fiz um downgrade na versão, instalando um zenity mais antigo. Aí funcionou.
Quem, como eu, estiver enfrentando esse problema pode utilizar esse link tipo "1-click install" aqui. Esse arquivo foi obtido com uma busca por zenity nesse outro link.

O pacote que estou utilizando atualmente, sem o problema, é a versão 2.20. A versão que acompanha o OpenSUSE é a 2.24.0 a versão mais atual (enquanto escrevo esse texto) é a 2.24.1.

E antes que alguém pergunte: Porque está utilizando o zenity ? Porque não utiliza python ? A resposta é bem simples. Arquivos legados. São pequenos e valiosos scripts que eu já escrevi a muito tempo e que utilizam o zenity. Talvez algum dia eu os reescreva em python, mas certamente esse dia não será hoje ou amanhã.

Se não sabe o que é o zenity e está curioso para saber, leia esse excelente texto (traduzido) aqui. Veja também a página de downloads do zenity e seu manual oficial.

[update]
Ao reler o título do tópico eu percebi o quanto eu fui injusto com o OpenSUSE 11.1. O problema não é do OpenSUSE é do zenity.
Sei disso porque lido com mais de uma distro e o problema é observado em todas que possuem versão mais atual do zenity (a título de exemplo, posso citar o Arch Linux atualizado em 18 fevereiro de ~~2008~~ 2009)
[/update]

E o meu substituto do Google Notebook é ...

2009-01-24T16:00:00.003-02:00

Eu já disse aqui (e vocês devem saber por inúmeras fontes também) que o Google Notebook foi cancelado.

Dessa forma começou uma migração em massa dos usuários do Google Notebook para outros serviços. A um ponto interessante nessa frase. Como você usa o Google Notebook ?. O Google Notebook não é apenas um aplicativo para fazer clip de páginas da internet. Ele tem múltiplas faces (notas pessoais, extensões para firefox, integração com outros serviços, compartilhamento de notas e, claro, suporte a "web clipping", que vai de uma página ou fração dela a uma simples url) e várias formas de organização (divide "notebooks", com suporte a seções e labels).

Quando olhamos o problema nesse aspecto, parece até que o Google Notebook é único. Pois ele integra vários elementos em um único serviço. Dos possíveis candidatos eu selecionei três, por serem os únicos que encontrei que uniu duas características, que para meus interesses, são fundamentais. O suporte a criação de notas pelo usuários e a web clipping e a possibilidade de importar o conteúdo do Google Notebook para o seu sistema (isso porque eu não vou importar 89 notas manualmente entre sistemas)

Logo após o anúncio do Google, três serviços candidatos a substituto fizeram o anúncio de suporte a importação de notas do Google Notebook: o überNote, o Evernote e Zoho Notebook. E eu utilizei o serviço dos três para ver "qual era" a de cada um.

O überNote é sistema prático e simples. Ele não tem suporte a mais de um notebook, mas tem suporte a tags. A ferramenta de migração do Google Notebook para o überNote funciona bem. Mas, há vários problemas no sistema. Por exemplo, a formatação do CSS não é tão ajustada a tela quanto eu acredito que deveria ser. Eu até criei um estilo para o Stylish básico para resolver essa questão. Mas também tem uma certa lentidão do serviço (e instabilidade também) atribuída a aumento expressivo do número de usuários recentemente (algo que eu até poderia relevar por hora). De qualquer forma, o problema maior foi o fato de que o sistema não funciona de forma tão limpa quanto me pareceu a primeira vez. Está cheio de pequenos detalhes desagradáveis. Ele possuí bookmarklet (funcional) e uma extensão para o firefox (que eu não gostei). Não permite salvar o item novo de forma inteligente e organizada como no Google Notebook ao usar a extensão dele.

Existe alguns detalhes que me fizeram pensar que ele seria a minha escolha (o fato de ser simples, por exemplo). Cheguei mesmo a acreditar nisso. Mas ao ver os problemas e ver que a solução não viria rápido, mas, principalmente, ao ver que já havia outros que já tinha a solução do problema pronta, eu deixei ele de lado. Destaque positivo para o gerenciamento de tarefas dentro do sistema. O destaque negativo ficou para o design, que eu achei feio, e para os pequenos bugs do dia-a-dia.

O Zoho Notebook é muito bonito. É, provavelmente, o mais belo de todos. Possuí suporte a diversos notebooks e a várias páginas dentro de cada notebook, o que funciona como uma divisão de seção. Apesar da beleza, o Zoho Notebook tem baixa usabilidade. A parte esquerda da tela dá grande destaque aos itens que eu posso adicionar. Isso é muito chato, especialmente porque poderia ser substituído por coisas mais úteis, ou, pelo menos, dar mais destaque ao notebooks existentes. Nem cheguei a testar direto a extensão dele, mas me pareceu muito similar a do Google Notebook. Se eu tivesse que escolher entre ele e o überNote, apesar de todos os pequenos bugs, eu ficaria com o überNote. Ah! Não procurei direito, mas a primeira vista ele não tem suporte a tags.

Restou o Evernote, o último a criar a fermenta de migração do Google Notebook. E talvez por isso seja o que faz o melhor trabalho com essa migração. Ele possuí suporte a múltiplos notebooks (um notebook que você pode marcar como padrão, pode, portanto, funcionar como uma inbox do sistema), suporte a tags e subtags (eu já criei 4 níveis de tags apenas para testar, não sei se existe limite, mas, se esse existe, é maior que 4). E é justamente a questão da subtag que permite que você crie duas formas de organização. Uma por ações, outra para lugar, outra para seção, outra para referência temática ou o que mais você desejar/necessitar (o melhor do GTD, literalmente. Eu criei uma tag para cada notebook e utilizei as subtags para dividir as seções. Também criei tags de ação - to do, maybe, etc - e tags de lugar - web, home, work, etc).

E quando eu digo que a importação foi a que melhor se adaptou a saída do Google Notebook, está no fato de que cada notebook importado é criado com um tag Google e com subtags que são as seções e labels daquele notebook importado. Verá que se fizer uma ação conjunta de importar-organizar, tudo ficar muito limpo e fácil de gerenciar no novo sistema (se não fizer isso, pode virar um caos).

O Evernote também tem uma extensão bem fraquinha para o firefox e um bookmarklet. Na verdade eu acho que fizeram o bookmarklet e converteram a mesma como uma extensão. Elas permitem salvar o item em um notebook "a escolha" e colocar tags durante o salvamento da nota.

O Evernote têm (como os outros) suporte a vários tipos de mídia e assim como o überNote tem uma forma de criar lista de tarefas com caixinha de seleção de itens.

E tem vários recursos extras (que eu não usei ainda) como, entre outros, o reconhecimento óptico de caracteres e o suporte a notas de voz. E outros que eu já testei, como a possibilidade de salvar uma buscar realizada no sistema. Também tem um software de desktop para Mac e Windows (que funciona razoavelmente bem - mas não perfeito - no wine). Eu acreditei que consideraria isso dispensável, mas até que sou obrigado a reconhecer que ter uma cópia offline das minhas notas não é uma idéia tão ruim assim.

Seu ponto fraco é que ele tem duas versões, uma premium, paga, e uma free. A free permite um tráfego de 40 MB por mês. Não se assuste. Isso é muito se você quiser fazer apenas o que fazia no Google Notebook. Não conheço ninguém que faça 20 mil notas por mês ou que colete 270 páginas da web (números aproximados, claro). Contudo, para um sistema que promete ser o catálogo de tudo (suas fotos, inclusive), 40 MB não é legal.

De qualquer forma, você não precisa se preocupar com isso. Afinal, você era usuário do Google Notebook que não suportava nem upload de fotos, quanto mais notas de voz. De qualquer forma a tendência das pessoas é se empolgar com as novas coisas e utilizar tudo de tudo. Assim, esse índice pode ser algo que você deve ficar de olho. Eu por exemplo, decidi que a cada finalzinho de mês do "ciclo" de 40 MB eu vou aproveitar para fazer o upload de minhas fotos principais para o Evernote - aquelas que você realmente quer guardar. Também vou fazer o upload de documentos (o sistema suporta anexos) que eu considere tão importantes que eu não posso perder. Um verdadeiro drive na web.

Como já disse, de forma não explícita, eu escolhi o Evernote. Apesar de ter gostado muito do überNote, os pequenos bugs foram fatais. Além disso, o Evernote está, hoje, mais estável (porque já era grande, assim como o Zoho). Têm mais recursos de organização das notas e permite um melhor aproveitamento da interface.