Exemplo de laço complicado

Eu sou um defensor da instrução GOTO, acho que as pessoas devem pelo menos aprender como funciona quando tão na escola. Já escrevi muito por aqui a respeito do GOTO, e do preconceito sem noção, etc.

Tudo bem que dá pra resolver qualquer problema com os for e whiles da vida, e os breaks e continues auxiliam, mas não deixa de ficar feio né gente... Não sei se fica menos feio do que usar um GOTO.

Olha esse exemplo aqui de código real que tem um laço complicado. Achei interessante porque vem direto de uma documentação de uma biblioteca, é um programa bem básico, é muito pequeno, e tem um laço bizarro.

lexer = lex.lex()
lexer.input(sometext)
while 1:
    tok = lexer.token()
    if not tok: break
    print tok

Olha só, o sujeito teve que fazer um laço “infinito”, algo sempre chamativo. Aí tem uma atribuição, um teste com break, e um print. O problema é que não dá pra testar o tok de cara, porque é preciso a primeira atribuição. nao dá pra fazer do ... while também porque o print precisa ficar depois do teste. Não tem jeito. O teste teve que ficar no meio desses dois. Aí então faz um “laço infinito com break no meio”. Uma estrutura que não tem nome. Se fosse GOTO, seria simplesmente mais um “laço com um teste”... Pra entender esse programa eu uso mais meus conhecimentos de programação fudamental, sabedora do GOTO, do que as facilidades estruturantes oferecidas pelas estruturas whiles e fors da vida.

Claro que dá pra fazer um jeito do programa ficar mais bonito, e o verdadeiro teste que limita o laço ficar na declaração do while. Tipo:

lexer = lex.lex()
lexer.input(sometext)
tok = lexer.token()
while tok:
     print tok
     tok = lexer.token()

Deve até poder ficar melhor com for. Mas algo levou esse programador a optar por uma única linha de atribuição, e um break, achou que talvez isso fosse mais claro, mais simples, mais de acordo com as famosas “limitações de suas habilidades cognitivas” que preocupavam Dijkstra. Eu pergunto: Será que estamos satisfeitos com nossas linguagens?...

Cruzando a janela

Hoje fiz um negócio legal que meus melhores leitores vão saber apreciar!

No meu último trabalho de uma disciplina aqui na Poli (que vou botar no meu site mais cedo ou mais tarde), tínhamos que fazer um par de programas pra rodar no console mesmo (algo que qualquer um tem que concordar comigo que é absolutamente alien no mundo wirdnws desde o XP, senão o 95). Um programa apenas abre um vídeo de entrada e insere uma marca d'água. O outro detecta ela no vídeo gerado.

Fiz tudo usando a FFmpeg. Terminei os programas, funcionou tudo legal. Mas tinha um probleminha: meu professor parece que não usa muito Linux, e queria códigos fonte de quem usou outros esquemas pra programar...

Como o FFmpeg é uma biblioteca pequena, relativamente independente de outra coisas (bem como o programa que eu fiz) então tinha boa chance de que eu conseguisse compilar tudo no widlows sem mudar o código... Mas eu fiz até melhor (agora vem a coisa legal). Resolvi tentar fazer uma compilação cruzada! Gerar o binário pra ele usar na plataforma estranha que ele usa, mas sem eu precisar instalar aquele sistema operacional bizarro nas minhas máquinas: compilar pro uíndious direto do meu Linux!...

Como fazer? Não tem mistério, é só pegar o Mingw32, o que no Debian é apenas questão de dar um apt-get. Aí pega o código fonte do ffmpeg (lá no SVN...), e dá o configure certo, algo como

./configure --disable-ffplay --disable-ffserver --enable-gpl --enable-cross-compile --enable-memalign-hack --target-os=windows --prefix=/usr/local/ffmpeg-mingw32 --cross-prefix=i586-mingw32msvc-

Na hora que vc der o make, ele deve chamar o mingw32 lá pra tudo, e pronto, vc vai instalar as bibliotecas do ffmpeg na versão da plataforma alien num diretório lá num /usr/local da vida. Aí é só compilar o seu programa com o mingw32 tb, e dar os -I e -L certos da vida. No meu caso tive uma dificuldade só lá, deu uns erros assim quando fui compilar:

/usr/local/ffmpeg-mingw32/lib//libavformat.a(rtsp.o): In function `udp_read_packet':
/home/nwerneck/src/ffmpeg/ffmpeg/libavformat/rtsp.c:1251: undefined reference to `_select@20'
/home/nwerneck/src/ffmpeg/ffmpeg/libavformat/rtsp.c:1256: undefined reference to `___WSAFDIsSet@8'
(...)

Mas era só mandar linkar tb uma tal -lw2_32. E aí pronto, gerei as versões binárias pro meu professor rodar meu trabalho na arquitetura estranha que ele usa!... Ah, mas não acabou ainda gente. Tem um detalhe muuuito importante que não pode esquecer. Nesse sistema operacional bizarro existe uma coisa que não pode ser omitida. Algo que é até intuitivo, como tudo que a micoshoft faz, não sei como esqueci de fazer isso.

Seu programa executável nesse tal sistema PRECISA ser um arquivo que o nome termine com a string ".exe". Por exemplo, meu programa chamava "insere", aí tem que mudar o nome pra "insere.exe", por exemplo. Se você não fizer isso o programa SIMPLESMENTE NÃO FUNCIONA. O sistema vai dizer que ele "não soube detectar o formato do programa" uma mensagem de erro super trágica assim.

É só isso, se vc se lembrar de mudar o nome, deve dar tudo certo. Sugere-se tb que o nome não tenha mais de 14 caracteres, contando com a extensão, ou seja, 8 de nome + '.' + 3 de extensão. Não sei porque isso... Vai saber o que esse povo inventa nesses sistema propriatas.

Ah, eu compilei o programa com ligação estática tb, pra ter certeza de que tudo ia funcionar... Isso parece tb que é algo bem comum pra quem trabalha nesse outro sistema aí, então não foi feio.


***
DIGRESSÃO:
A propósito, aprendi algo sobre a FFmpeg muito legal, é a primeira biblioteca que eu vejo que simplesmente abandonou a idéia de fazer "releases", eles mandam você pegar direto o SVN e pronto.

FFmpeg has always been a very experimental and developer-driven project. It is a key component in many multimedia projects and has new features added constantly. New, official "releases" are few and far between. In short, if you want to work with FFmpeg, you are advised to go along with SVN development rather than relying on formal releases. SVN snapshots work really well 99% of the time so people are not afraid to use them.

Traduzindo pra ser legal:

FFmpeg sempre foi um projeto muito experimental, e conduzido pelos desenvolvedores. Ela é um componente chave em muitos projetos de multimídia e tem novidades adicionadas contantemente. Lançamentos oficiais novos são poucos e distantes um do outro. Resumindo, se você quiser trabalhar com a FFmpeg, é aconselhável que você siga o desenvolvimento no SVN ao invés de contar com lançamentos formais. Snapshots do SVN funcionam muito bem 99% do tempo, então as pessoa snão tem medo de utilizá-los.

Isso é muito bacana, por faz algum tempo que o desenvolvimento de software livre vinha desafiando essa visão do mundo dos propriatas (praticante da propriataria de software) de que software é desenvolvido num beco escuro na Zona Fantasma por engenheiros ignotos Lovecraftianos, e empacotados quando eles ficam "prontos".


(Engenheiros na zona fantasma)

Ora, os melhores softwares nunca ficam prontos... Eles estão em constante desenvolvimento e novas características vão sendo incorporadas aos poucos. Essa é a realidade da coisa. Encarar tudo como uma escultura, ou construção de uma casa, é um absurdo. (Aliás, quem já fez uma escultura ou saca, sabe que elas nunca ficam realmente prontas tb... É tudo igual, a diferença é que é tão fácil reformar um programa de computador, que fica mais fácil sucumbir à tentação de dar mais e mais umas mexidinhas...)

Os propriatas de software precisam fazer isso pra ganhar dinheiro, e pra fazer marketing, pra vender aquela ilusão do "software garantido", "com a qualidaaaade do fulano". No mundo livre isso não existe. O que existe é a percepção da realidade que software seguro, é o software velho. Ou você escolhe usar um velho que é comprovado mas menos estribado, ou você vive no avant garde, mas se arriscando a tomar uma cacetada de vez em quando. É por isso que vários projetos criam a idéia do "pacote estável" e o "pacote em testes", e ainda a "distribuição de desenvolviemnto", que é o código no SVN do servidor central onde se gerencia o projeto... No Debian isso é bem claro, existem as diferentes fontes de pacotes em que você pode tentar manter o seu sistema (eventulamente você sempre resolve que precisa de um certo pacote do unstable, ou precisa votlar pra uma certa versão antiga de algum outro pacote...)

O FFmpeg aí jogou no lixo isso tudo. É pegar do svn e pronto!... Você consegue imaginar algo parecido sendo feito por propriatas?? Algo como cobrar uma mensalidade pra você acessar lá a versão SVN do Altokod, ou do C0rreu dal? Duvido que rolasse.

O que os propriatas fazem é manter a versão de desenvolvimento deles em segredo, bem escondida na Zona Fantasma (wikipédia se vc ainda não sabe do que se trata). Aí dá essa ilusão de que "não interessa" aos usuários mundanos. No mundo livre todas versões de tudo tão sempre à disposição. Aí o que acontece? As pessoas vivem angustiadas por se depararem com o comprometimento entre o novo e o seguro... Aí eu pergunto, você realmente prefere viver na alienação?... Ignorance is bliss??...

editor de textos de ouro

É de conhecimento geral meu gosto por certos programas como TeX, usar linguagens como C++, BASH, Flex, Prolog. Isso tudo nem tem muito a ver com ser livre ou não, ou com o poder dos interpretadores, ou qualquer coisa "capitalista". Tem a ver com o fato dessas coisas se integrarem muito bem com editores de texto, ao invés de dependerem de interfacezinhas gráficas cheias de botozinhos de vários tipos, scrolls enigmáticos, orelhas etc.

Tem várias coisas que você pode fazer uma vez que seu trabalho dependa não de uma estrutura de dados abstrata a que você tem acesso por uma interface, mas sim de um arquivo sendo editado dentro de um edito de texto. Por exemplo, você pode fazer buscas e substituições não só em conteúdos de texto de objetos, mas mesmo em comandos. Como você faz no M$oft word (ou openoffice que seja) pra substituir todos itálicos de seu texto por bold? (Talvez não seja um bom exemplo, mas dá a idéia.)

Olha aqui outro exemplo do tipo de coisa que você faz dentro de um editor de textos. Também não é um exemplo de uma coisa útil, mas é sem dúvida algo divertido!



Eu saí dividindo as janelas do emacs formando o famoso desenho da espiral que se faz pra mostrar as propriedades da proporção áurea! Não foi automático, ainda.

Você vai me dizer: “pô, Nicolau, e exemplo de coisa útil de verdade, não tem?” Quando eu tiver eu mando, mas a diversão tem prioridade. Isso de ser “sério” é uma tola ilusão...

um passo pra trás implica em dois pra frente

"Ô Nicolau, usa Java! Bota aí um Eclipse!... Usa W1mbous CE, me, NT, 2000, XP, Vista... Tira esse TWM, bota um Gnome, KDE, Windowmaker... Porque vc não usa Java????"
"Sai fora, não suporto..."
"Então usa .NET... Ou Delphi, pq vc nunca fez sequer um programa em Delphi? Ooopa, vc usa o que?? EMACS? Eeeeca!..."
"Cara, eu gosto mais é de programar em C++, às vezes Prolog..."
"Prolog? Isso é muito velho, vc vive no passado. Retrógrado."
"É bem mania de programador de Prolog, fazer backtracking. Antigamente as coisas eram feitas para durar, cara... E pra funcionarem direito. E elas ainda duram e funcionam..."

Como integrar seu blog ao digg

A HelenaN outro dia me fez finalmente entrar no tal digg. Procurei e procurei um jeito que botar o digg no meu blog, e finalmente funcionou, depois que eu li esse blog aqui:
Testing Blogger Beta (now New Blogger): Testing adding Digg vote button to every post

Aí eu pergunto: “CAN YOU DIGG IT!??!”

---

Se você também quer integrar o digg ao seu blog no blogger, Aqui vai o macete. No meu blog, eu usei os seguintes códigos. Nos posts:

<p>
<!-- DIGG -->
<div style='float:right; margin-left:10px;'>
<script type='text/javascript'>
digg_url = '<data:post.url/>';
digg_bgcolor = '#f6f7f7';
digg_title = '<data:post.title/>';
digg_bodytext = '<data:post.url/>';
digg_skin = 'compact';
digg_window = 'new';
</script>
<script src='http://digg.com/tools/diggthis.js' type='text/javascript'/>
</div>
<data:post.body/>
</p>

E na barra lateral:

<div align="center">
<script type="text/javascript">
digg_url = 'http://philogroky.blogspot.com';
digg_skin = 'new';
digg_color='#ffffff'
</script>
<script src="http://digg.com/tools/diggthis.js" type="text/javascript"></script>
</div>

O digg_color muda a cor em volta do botão (parece que não rola transparência ainda). O skin é o modelo do botão, e o url, o url!... Tem uma opção ainda que te permite já sugerir antecipadamente o título da notícia, categoria et cætera... Isso tudo tem na documentação no próprio site do digg.