Mostrando postagens com marcador computacao. Mostrar todas as postagens
Mostrando postagens com marcador computacao. Mostrar todas as postagens

11 de mar. de 2012

MateHackers

Algum tempo atrás, surgiu em Porto Alegre um grupo de pessoas unidas em prol de uma nobre causa: montar um Hackerspace. Um Hackerspace? Pras pessoas ficarem invadindo computadores uns dos outros? NÃO! Não é isso que faz um Hacker ¬¬
Club-Mate num Hackerspace alemão...
Um Hackerspace é......... difícil de explicar de cara. É um lugar onde as pessoas que têm projetos "próprios" se juntam pra por esses projetos em prática, fazer acontecer. A idéia é que, com esse lugar, as pessoas possam trocar idéias umas com as outras, aproveitar coisas já feitas por outros, etc, num ambiente mais cooperativo do que aquele que teríamos em nosso próprio lar. (sinceramente, espero ter conseguido dar uma idéia da coisa)

O grande idealizador do grupo? Um alemão, proveniente, creio eu, de Berlim. Como ele fazia parte de um Hackerspace lá, sugeriu a idéia de criarmos um "aqui" (frequentemente eu escrevo como se ainda estivesse no Brasil v_v), "seguindo os moldes" daqueles Hackerspaces que ele já conhecia. [Eu sinceramente tenho a impressão de já ter escrito sobre o Hackerspace aqui nesse blog]

Do Hackerspace de Berlim e do de Stuttgart (acho), pegamos umas "guidelines" que poderiam nos ajudar a montar o Hackerspace aqui -- eu digo pegamos porque até então eu ainda estava ativo na coisa (mas não durei muito tempo como ativo, e agora eu estou mais pra lurker do que qualquer outra coisa). Nessas guidelines, havia uma sugestão do tipo "arranje um meio de conseguir dinheiro", ou algo assim. O meio do Hackerspace de lá? Vender uma bebida a base de Erva-Mate chamada Club-Mate.

Convido, então, o leitor, a que atente à seguinte reportagem da Zero Hora:

http://zerohora.clicrbs.com.br/rs/mundo/noticia/2012/03/berlim-descobre-cerveja-artesanal-de-erva-mate-3691091.html

Não é incrível como tudo consegue estar conectado? Melhor ainda: o nome do Hackerspace de Porto Alegre? MateHackers, em uma referência clara (sim, era essa a idéia na hora -- e eu tenho certeza porque MateHackers ganhou da minha sugestão, ChimaHackers, quando estávamos discutindo sobre o nome) à bebida Club-Mate (aliás, eu fui lá no site dos Hackerspaces e o de Porto Alegre não é o único Hackerspace a estar em construção: temos mais um bom número de outros sendo produzidos).

Enfim... era só isso. Só queria comentar sobre como eu caguei tijolos quando meu irmão me mandou isso no Facebook.

(Aliás, procurando no Google por Club-Mate e pelos Hackerspaces, achei um link extremamente cômico: http://hackerspaces.org/wiki/The_Club_Mate_Pattern. Vale a pena conferir)

R$

20 de fev. de 2012

Em Kaiserslautern #3 -- no trabalho...

Do leitor que já ouviu a rádio Farroupilha (eu ouvia todo dia, "por osmose", graças à minha avó) espero que ao menos reconheça a referência, no título da postagem.

Finalmente, o trabalho começou de verdade \o/ Estou empolgadíssimo (e, lol, não escrevo isso esperando que os meus chefes leiam, porque, apesar de brasileiros, duvido que estejam interessados nesse blog)! Inicialmente, o meu trabalho foi meio "dummy": pelo que entendi, o objetivo era que eu aprendesse a brincar com templates (que até então sempre foram uma dor de cabeça pra mim), Doxygen (uma ferramenta de documentação de código que, sério, achei MUITO fodalhona -- dá até pra fazer gráficos UML das relações entre as classes do programa) e o Eclipse (foi a primeira vez que eu realmente usei o Eclipse, relativamente a fundo, e, sinceramente, to até que gostando).

Ainda sobre o Eclipse, no momento em que me pediram pra usá-lo, eu reclamei que ele era muito poluído (era o argumento que eu lembrava de ser o "ponto fraco" dele, na minha opinião -- eu tenho tentado usar o VIM e, convenhamos, qualquer coisa se torna poluída quando se usa o VIM). Depois de 10min na frente do Eclipse, me veio o real problema que eu tive com ele quando tentei usá-lo noutros tempos: ele não me dá (ou é complicado fazer com que ele me dê, porque até agora eu não achei comofas) controle sobre o Makefile que ele gera pra o seu projeto. Além disso, achei um exagero, uma bobagem, que na auto-geração de classes do Eclipse CDT ele já crie o método destrutor como sendo virtual. E se eu não quiser que outras classes herdem da minha classe? Pra que virtual? Achei meio frescura, especialmente depois de ter lido o  Deep-C que me disse pra não sair sempre declarando qualquer destrutor como virtual v_v

Mesmo assim, no fim das contas, estou feliz com o Eclipse: ele me dá syntax highlight bem fodástico (apesar de ter me levado uns 10min pra eu conseguir configurar tudo do jeito que eu queria) e ainda me permite pular direto pra declaração da função simplesmente segurando Ctrl e clicando no seu nome (além de reindentar todo um código que esteja emporcalhadamente mal-indentado, se for o caso, através de um simples atalho -- e a reindentação, apesar de seriamente limitada, é [um pouco] configurável). Também, a opção de refactor dele é simplesmente maravilhosa -- apesar de às vezes dar uns bugzinhos D= -- e, no monitor que me deram, a poluição do browser se faz perfeitamente tolerável (sobra tanto espaço que não consigo ficar só com o Eclipse aberto ocupando todo o espaço da área de trabalho: me obrigo a ficar com a linha de comando ou o firefox (ou ambos) abertos pra diversificar um pouco a partilha do espaço.

Quando terminei o meu "trabalho dummy", no fim da semana passada, ganhei novas instruções: deveria começar a fuçar com sockets. Não sabem os meus chefes que eu acho esse assunto de redes, e ferraria, e bits e protocolos super divertido (além de super engenheiro também), apesar de ser super n00b nisso (mas estou tentando, vá-la, logo estarei sabendo da coisa direitinho).

Assim, o meu carnaval está sendo regado a programação e aprendizado =) (o carnaval aqui é super estranho: como é frio, não tem muita gente nas ruas e eu nem mesmo to sabendo de qualquer aglomeração/festa/coisa do tipo aqui nas redondezas (na cidade). Sei que teve, só, alguma coisa -- uma festa a fantasia, certamente -- no sábado, quando peguei um ônibus "lotado" (cheinho, para os padrões de Porto Alegre) na volta do supermercado, mas não creio que tenha feito grandes alardes "na comunidade")

Eras isso...

R$

23 de jan. de 2012

As Guerras de Copyright

A coisa está cada vez mais apavorante.

Imagem presente no site do megaupload.com
Se as empresas que aprenderam a ganhar dinheiro através da internet estão mobilizando, através de propaganda em massa, pessoas de todas as idades e de todas as regiões do mundo para lutar pelo direito de ter uma rede livre, e se através de uma internet livre é que foi possível movimentar os ativistas de vários países do Oriente Médio para lutar pela sua "liberdade" (ou por o que quer que eles realmente queiram), ao mesmo tempo, cada vez mais eu temo pelo que será do futuro da internet.

A opinião pública é unânime: quem é que seria contra a internet do jeito que ela é atualmente? Alguém é contra a pirataria desenfreada que corre à solta na internet nos sites de compartilhamento? Se o é, sofre de algum necessidade de realização de justiça alheia e, na minha opinião, tem problemas com a realidade.

Milhões e milhões (e eu arriscaria a dizer bilhões) de pessoas estão pouco se lixando se o episódio de Futurama que passou há 10 anos ainda está coberto por leis de direitos autorais. E provavelmente nunca nem mesmo comprariam um DVD oficial do Futurama se lhes não fosse permitido assistir de graça pela internet. Eu não consigo enxergar como essa poderia ser uma "venda perdida", como as grandes empresas detentoras dos direitos autorais gostam de dizer.

Nos últimos dias, com o objetivo de derrubar uma lei que beneficia as grandes detentoras dos direitos autorais (a SOPA/PIPA), vários sites, como o Google, o 9gag, o LolCats, FailBlog, Wikipedia, Reddit, Know Your Meme, Quick Meme, entre outros, se retiraram do ar (ou colocaram avisos sobre o assunto) numa tentativa de conscientização de o quanto a lei seria capaz de retirar a liberdade na rede. O SOPA/PIPA permitiria a censura de sites que potencialmente pudessem liberar conteúdo pirata na internet. É o Algoritmo do Banqueiro voltado para a internet.

Enquanto grandes empresas tentam a todo o custo diminuir a produção de conteúdo de qualidade e meter goela abaixo somente os seus próprios enlatados sem graça, a gente vê exemplos de produtores independentes dando um show de sofisticação e modernidade, dizendo que "se não pode comprar agora, então pirateia mesmo":

"Pirateie." já disse o criador do MineCraft
Terminado todo o alarde sobre o SOPA e sobre o PIPA, ontem mesmo ouvi falar de um tal de "ACTA", um acordo sobre patentes que seria capaz de impedir inclusive a compra de remédios "piratas" (ou seja, construídos sobre a quebra de alguma patente). PUTA QUE PARIU! Quando é que os governos vão parar de incentivar as grandes empresas e começar a pensar no povo? (eu não conheço ainda o tal do acta, mas duvido que ele não se torne bastante "popular" nos próximos tempos, se ele fizer o que disseram que ele faria no video a que eu assisti)

Por fim, devo logo assistir à seguinte palestra, do fim do ano passado:



Creio que o assunto esteja relacionado a essa guerra, que está recém começando e que logo causará um grande número de movimentações pelo mundo todo em prol da liberdade na internet. Vários sites de compartilhamento de arquivos já estão fechados ou sob restrições no funcionamento. A coisa apertou, e se eu tivesse que julgar, as revoluções no Oriente Médio foram só as primeiras.


(é nessas horas que a gente vê que o LulzSecurity e o Anonymous são na verdade os nossos melhores amigos na luta em prol da liberdade)

R$

10 de set. de 2011

Interação Humano-Computador

Entre as cadeiras que estou fazendo esse semestre, sem dúvida aquela que tem as aulas mais massantes e "trabalhos" mais desagradáveis tem sido Interação Homem-Computador (ou Interação Humano-Computador, ou, simplesmente, IHC).

Enquanto ela é ministrada geralmente por um professor da Computação Gráfica (o que, pra mim, de certa forma, me causa uma boa imagem imediata), ela tem estado no mesmo nível da Engenharia de Software do semestre passado.


Esses dias tive de fazer uma apresentação em IHC e, para ter uma noção da matéria -- não consigo prestar atenção na aula -- comecei a ler os capítulos que o professor deixa na ferramente de EAD que nós usamos (o moodle). Tenho de concordar que, apesar de não ser muito bom em apresentar a matéria, o professor é bem dedicado, deixando bastante material para nossos estudos.

Eu li boa parte dos capítulos e até que gostei no início. A matéria é bem "humana" e tenta meio que modelar (ou usar os modelos já criados em outras áreas) o modo como funciona a nossa cognição (tomara que eu esteja falando direitinho). Mas a matéria é pesada e bem chata (convenhamos: eu não estou interessado em como se faz interfaces bonitas!) e depois de um tempo eu já não aguentava mais D=

Enfim enfim... só queria falar um pouco sobre como eu tenho achado a cadeira de IHC. Sem dúvida, uma das piores cadeiras do meu curso. Acho que não sou o único com essa opinião.

R$

24 de ago. de 2011

Makefiles, Autotools, bolsa de iniciação científica, MClone, etc...

(Esse post é praticamente uma continuação do post "Documentando")

Como o leitor que leu o post anterior já deve saber, eu estou tri feliz por estar documentando o MClone. Já expliquei várias coisas, tendo criado alguns arquivos de documentação conforme ía preparando o programa para compilar no computador que uso lá no laboratório.

Hoje tive uma reunião com meu professor, na qual comentei com ele sobre o que andava fazendo. Meu próximo passo seria fazer o Makefile para que semana que vem a gente visse se ele conseguiria compilar o programa no Mac dele. Por causa disso, fui ler sobre Makefiles. Procurei por alguns tutoriais na internet, mas, pelo visto, com esses arquivinhos, ou é oito ou é oitenta: os tutoriais eram muito básicos, mas a documentação do GNU make é grande demais, e eu a evitaria o quanto pudesse. Infelizmente, definitivamente, não achei lugar melhor. Desisti e fui pra documentação. Ela é enorme, e já perdi umas boas horas lendo-a. Aprendi UM MONTE, e pra falar a verdade não posso dizer que me arrependo: nela encontrei vários macetes interessantes.

A minha primeira idéia era fazer uma Makefiles bonito, que funcionasse e que fosse elegante. Resolvi que o farei, pelo aprendizado, mas não deixarei ele lá por muito tempo. Se o tempo permitir, quero ver se leio sobre outra coisa que já adiava há tempos ler: Autotools. Desde uns dois anos atrás pra cá tenho o link de um tal de Autotools: a practitioner's guide to Autoconf, Automake and Libtool que uma vez eu achei na internet procurando pelo motivo de haver uns tais de Makefile.in e Makefile.am (se não me engano era isso) num projeto que eu estava tentando compilar. Agora tenho desculpa pra ler! E uma ótima desculpa, já que tenho me sentido com a maior satisfação do mundo mantendo ativamente um projeto no googlecode (infelizmente, não é um projeto que tenha muita chance de se tornar popular D=).

Para melhorar a minha vida, aliás, tenho deixado todo o código numa pasta do Dropbox, através da qual consigo mexer no código do programa de qualquer lugar. Agora mesmo, ao chegar em casa, lembrei que tinha algo que eu deveria ter feito antes de sair de lá dos labs. Abri o arquivo pela pasta do Dropbox, fiz as modificações que queria, e commitei no svn. Funcionou lindamente \o/ (eu tava com medo de o svn reclamar, por qualquer motivo, mas não aconteceu).

Ao término desse semestre, enfim, acho que vou estar fodão com Makefiles e Autotools =D. Tomara: esse é o tipo de coisa que eu acho muito tri e útil. Só falta eu aprender a usar decentemente um shellzinho u.u

Era isso...

R$

20 de ago. de 2011

Documentando

Estou muito satisfeito com a bolsa de iniciação científica, a qual começou oficialmente este mês.

O meu objetivo, durante meu trabalho lá, será implementar a paralelização do código do MClone, a.k.a, a implementação do trabalho de doutorado do meu professor. Quando peguei o código pela primeira vez, ele estava uma bagunça (ainda está). Desde o seu desenvolvimento inicial, em torno do ano de 1999, um bom número de pessoas, para diferentes fins, modificou o código do MClone. Como elas gostariam dos créditos de sua modificação, causaram um monte de poluição incluindo comentários do tipo "modificado por 'insira_nome_aqui' em 'insira_data_aqui'". Além disso, como não tinham o objetivo de manter o código usável para outrem num futuro distante, não parecem ter se preocupado muito com a legibilidade, mantendo comentadas (das mais variadas formas possíveis) as partes "obsoletas".

Em um certo momento, no início do ano, quando eu comecei a entrar em contato (contato muito frágil, digamos assim) com o programa, percebemos a bagunça. Algumas partes estão muito bonitas, com código limpinho e bem documentado. Outras partes estão complicadas, cheias de comentários aleatórios de código antigo e estruturas de dados com nomes nem um pouco convencionais (e.g., tem uma lista encadeada com o nome de Array). No meio do semestre passado, pegamos cada arquivo e demos uma olhada em o que cada coisa faz. Decidimos que faríamos uma série de classes e reestruturaríamos tudo. Apesar de eu participar dessas reuniões, muito pouco mexi no código até agora: quem mais arrumou (e fez um ótimo trabalho, reestruturando em pastas as classes -- antes, como o código era majoritariamente em C, quase nem víamos classes; agora, as coisas já estão encaminhando, creio --, sempre versionando através do projeto do MClone que a gente criou no GoogleCode) tudo foi o mestrando que trabalhava comigo.

Agora, no início do semestre, voltei a mexer no código. Como precisava conseguir compilar o programa no Ubuntu que eu instalei numa máquina lá da Computação Gráfica, e como pretendia utilizar o Eclipse, e como ao programa faltava um Makefile (acho que ele se perdeu no meio das reestruturações), resolvi documentar tudo, desde o que se deve fazer para compilar utilizando o Eclipse até como é que se faz para instalar as bibliotecas necessárias ao programa. Foi isso que fiz durante quase o dia inteiro de quarta-feira, e isso que pretendo terminar de fazer na segunda-feira.

Documentando o código, percebi algo interessantíssimo: eu ADORO documentar. Adoro escrever explicações sobre de que forma é possível fazer algo que não seria óbvio para qualquer um.

Lendo A Catedral e o Bazar, do Eric Raymond, esses dias, eu me deparei com a seguinte frase (negrito feito por mim):

Many people (especially those who politically distrust free markets) would expect a culture of self-directed egoists to be fragmented, territorial, wasteful, secretive, and hostile. But this expectation is clearly falsified by (to give just one example) the stunning variety, quality, and depth of Linux documentation. It is a hallowed given that programmers hate documenting; how is it, then, that Linux hackers generate so much documentation? Evidently Linux’s free market in egoboo works better to produce virtuous, other-directed behavior than the massively funded documentation shops of commercial software producers.

Eu não sou lá um programador grande coisa... então acho que posso ser bom em documentar (e gostar disso), mesmo, né?

Finalmente, meu professor estava reclamando sobre o fato de que o porte que uma das pessoas que mexia no código antigamente fez para Mac não funciona no computador dele. Sinceramente, acho que após as minhas pequenas arrumações há uma relativa chance de que o programa passe a funcionar no computador dele também - o que seria algo bem legal, né?

Era isso, enfim... o todo foi mais para explicar que eu percebi que gosto de fazer documentação u.u

R$

4 de ago. de 2011

Morrendo e Revivendo - um balanço das minhas férias...

Passei os últimos 17 dias nominalmente morto. Este era o objetivo: sumir. Queria jogar um jogo e fazer algumas coisas que tinha como importantes a serem feitas nas férias. Se não fosse capaz de cumpri-las, acho que teria terminado as férias me sentindo cansado, frustrado, por ter feito tantos planos e cumprido tão poucos.

Finalmente, consegui: assisti ao Senhor dos Anéis, como já disse, e aos três "primeiros" episódios do Star Wars. No dia posterior, dei uma relaxada, fui ao cinema com alguns amigos, e a partir da sexta-feira da semana retrasada comecei a jogar Golden Sun, para GBA. O primeiro jogo (são dois jogos: o primeiro vai até "a metade" da história e o segundo continua exatamente onde o primeiro termina) foi rápido, demorou 4 dias para terminar. O segundo foi até ontem denoite, quando, às 3h da manhã, finalmente venci o último chefe (admito que não aguentava mais =)). Terminou, e agora me sinto com a disposição necessária para vencer mais um semestre.

Esse semestre será complicado, com 7 cadeiras (bem mais do que eu normalmente pego), mas certamente será bom. Voltarei a ter aulas com o melhor professor do curso, na minha opinião \o/.

Além disso, já me propus a entrar em um projeto "sério" com uns amigos nos quais desenvolveremos mais um joguinho (as aspas no sério são justamente por ser um jogo), e dessa vez pretendemos utilizar Löve como "engine" (não conheço direito a Löve e por isso não sei se dá pra chamar assim) para nosso programa.

Enfim enfim... esse semestre "promete". Infelizmente, vejo que terei de deixar alguns projetos "de lado" (o que significa que devo "fulfil" eles nas férias), como a tradução do livro de Haskell (frustrante pensar que o mantenedor do projeto nunca mais entrou no github desde abril - se bobear já até morreu ou está acometido de uma grave doença e eu to xingando ele, coitado D=) e os meus videos no Youtube (eu até tinha criado uma conta google com o nome "Satyrslair", mas no fim acho que vou deixar ela "de molho" durante um tempinho D=). De qualquer forma, estou feliz e contente com esse novo semestre que começa \o/

22 de jul. de 2011

apt-file

Estava eu tentando esses tempos compilar o sndpeek, um programa que o Fialho me sugeriu como começo ao meu trabalho final de CG, quando me apareceu um erro de compilação motivado pela falta de uma lib no meu computador. Estou certo de que se eu fosse mais novo nesse assunto, teria me escabelado e esperneado e ficado horas tentando descobrir o motivo do erro, mas felizmente ao menos por esses erros mais babacas eu já passei em outros tempos e fiquei feliz de saber de cara o que deveria fazer: era necessário que eu instalasse a lib que estava faltando.

Infelizmente, quando vi que o makefile incluía um "-l" que eu não conhecia, fiquei meio sem saber qual poderia ser o nome da lib, então fui ao Synaptic (uso Ubuntu, como o leitor deve saber), tirei o "-l" do escrito, e coloquei o que sobrou na busca. Na hora, o Synaptic não achou nada que me parecesse ser o que eu procurava, no que a minha próxima solução foi buscar no google por essa lib.

No meio das buscas, achei esse link, o qual me agradou profundamente. Não que ele tenha me sido útil no momento, mas eu já teria perdido menos tempo em outras ocasiões se soubesse do tal apt-file. Instalei o tal imediatamente e testei-o, só pela brincadeira.

Enfim... essa postagem é somente para compartilhar o causo e o programa que considerei muito útil. Para quem não está a fim de abrir o link para saber do que trata o apt-file, ele ajuda a procurar nos repositórios pelo pacote do qual um certo arquivo faz parte. Assim, digitar (na linha de comando), por exemplo:

$ apt-file search alsa/asoundlib.h

E receber como retorno:

libasound2-dev: /usr/include/alsa/asoundlib.h

Genial, não?

Não sei quanto aos leitores, mas pra mim me pareceu maravilhoso!

Enfim, enfim... era só isso \o/

R$

10 de jun. de 2011

Sobre a disciplina de Engenharia de SW

Estou fazendo 5 cadeiras esse semestre (em ordem do horários na semana): Otimização Combinatória, Fundamentos de Tolerância a Falhas, Computação Gráfica, Modelos de Linguagens de Programação e Engenharia de Software.

Todas as cadeiras, sem exceção, são, de alguma forma, sobre assuntos interessantes. Otimização Combinatória (OC), por exemplo, é legal porque o professor que ministra a disciplina é muito bom, como também é o caso de Fundamentos de Tolerância a Falhas (FTF) (essa última poderia ser EXTREMAMENTE ruim - já que é tri envolvidona com essas coisas de engenheiro de que eu realmente não gosto -, não fosse a professora ser uma das melhores professoras do instituto). Computação Gráfica (CG) é disparada a melhor: o professor é sem dúvida o melhor professor com quem estou tendo aula e o mesmo posso dizer da matéria da disciplina. Modelos de Linguagem de Programação (MLP) é uma disciplina legal, com um professor extremamente dedicado, apesar de não ser o mais eloquente em sala de aula. Ele tenta, mas, apesar de o todo ser bem legal, a sua aula não é das melhores.

As cadeiras descritas no parágrafo anterior eu posso dizer que são bem cansativinhas, no fim das contas: FTF tem questionário pra fazer (tu demora entre 1h e 2h pra terminar cada questionário), MLP tem tema em quase todas as aulas (alguns são ENORMES; outros são questão de 15min pra terminar), CG tem trabalhos bem bem bem grandes pra entregar a cada duas semanas, e OC, apesar de não ter trabalhos, é bem complicadona (o professor é fodão mas as provas são bem cobradas e o assunto da cadeira é tenso). Mesmo assim, não são ruins: como eu disse, de alguma forma eu me interesso ou pelo assunto, ou pela aula, etc.

Uma cadeira, em compensação, consegue estar sendo disparada a pior cadeira que estou fazendo desde que entrei na computação: Engenharia de Software.

Quando comecei a cadeira, esperava uma coisa: aprenderemos sobre como são os "processos de desenvolvimento de software", dando uma passada sobre cada um, entendendo as filosofias relacionadas a eles e os motivos que levaram à sua criação. Imaginava que veríamos também algumas boas práticas que fossem independentes dos processos.

O Diagrama de Casos de Uso é extremamente amigável. O cliente, ao ver um desses diagramas, não fica com dúvida alguma sobre o que o usuário é capaz de fazer, certo?
Como começamos a cadeira sem falar muito em UML e RUP (ou o tal do "Processo Unificado), achei que a coisa ficaria assim, sem foco na tal bendita UML. Pensei que no máximo aprenderíamos que existem "esse esse e esse" diagrama e que logo passaríamos adiante, continuando com as filosofias. Passado algum tempo, porém, estagnamos num tal de Diagrama de Casos de Uso (que não foi embora até agora T_T) e, a cada aula, tudo o que vemos são mais e mais diagramas e diagramas (e como esses diagramas da UML se relacionam com o único processo de desenvolvimento de software que importa: o Processo Unificado), motivo pelo qual tenho faltado frequentemente às aulas .

Novamente, cri: "aaa... o motivo de as aulas estarem ruins é relativo ao foco que a gente tá dando em coisas desnecessárias, e não tem nenhuma relação com a professora". Nos últimos tempos, porém, tenho é me incomodado justamente com ela.

Que as suas aulas são monótonas todos já sabem, e isso não é um problema "at all" (exemplifico com o professor de MLP, que tem aulas monótonas mas que ensina a matéria muitíssimo bem). Que ela se incomoda com a conversalhada constante da turma também todo mundo já sabe (aliás... a conversalhada é fruto das aulas monótonas, diga-se de passagem), e é por isso que ultimamente tem feito a chamada no início das aulas, liberando aqueles que aparecem só para ganhar presença (ao menos é o que parece).

Seu trabalho final, porém, é a maior de suas loucuras: estamos usando o Processo Unificado (ou seja, gerando infinitos diagramas e "documentos" - não sei se esses documentos são parte do RUP, mas acho que ao menos ela quer que creiamos que sim - escritos com páginas e páginas que eu duvido que ela vá ler) pra, em 5 etapas, desenvolver uma loja virtual fail fake, de acordo com a especificação feita por outro grupo (sim... ee... no caso... um outro grupo está desenvolvendo a loja de acordo com a especificação do meu grupo). A cada etapa, além de enviarmos via moodle o "documento" com todos os diagramas e bobagens mais gerados, ela ainda EXIGE QUE LEVEMOS UMA CÓPIA IMPRESSA. E, pior do que isso, ela é inconsistente em suas especificações: na etapa 2, não pediu que levássemos uma cópia impressa do relatório individual (esse relatório era pra falarmos sobre as dificuldades que tivemos e coisas mais) gerado por cada aluno, mas somente do "documento" gerado pelo grupo inteiro. Na etapa 3, pediu que levássemos TAMBÉM o relatório individual.
Aqui vai outro adorável diagraminha da UML. Só pra dizer que eu pus outra imagem no blog u.u
Pobres das nossas árvores. Como disse um colega, 90% da mata atlântica deve ter sido desmatada por causa dos caras da Engenharia de Software.

Enfim enfim... essa postagem é só uma reclamação da cadeira de Engenharia de Software. Não aguento mais. Tomara que acabe duma vez... e certamente não farei mais cadeira alguma com essa querida professora - a qual não nominei aqui, apesar de obviamente grande parte dos meus leitores a conhecer.

Não precisava ter lido se não quisesse u.u

R$

21 de abr. de 2011

Coding Dojo

Participei, hoje, pela primeira vez, de um coding dojo.

O contador de tempo que a gente tinha lá até que pode-se dizer que era bem parecidinho com esse daí u.u

Para o leitor que talvez não saiba, explicarei como funciona, através de minhas palavras (o que pode confundir ou pode clarear a mente do leitor, randomicamente).

Coding dojo é uma atividade em que se reúne um certo grupo de indivíduos programadores para resolver um problema, seguindo algumas estipuladas regras. A idéia é que os programadores que não conhecem a linguagem de programação usada na reunião (essa linguagem é decidida pelo grupo) tenham contato com ela e aprendam os seus basics - pra mim foi tri bom, porque eu nunca tinha mexido com Python.

Estipula-se um tempo (no nosso caso, foi 5min) durante o qual cada programador poderá permanecer programando. Além disso, sempre haverá alguém "ao lado" do programador do momento, para ajudá-lo. A ordem em que se escolhe o programador do momento é dada através (foi assim no nosso caso, ao menos) de uma fila:

Seja PM o programador do momento, AJ o ajudante do momento, e P = (p1,...,pn) a fila dos programadores da platéia, n sendo o número total de programadores menos 2, o processo de troca de programadores se dá, ao término do tempo estipulado, de forma que

PM <-- AJ   ,    AJ <-- p1   ,   pn <-- PM   ,   pk <-- pk+1   ,   1 < k < n

Eu não entendi se isso é natural de todos os coding dojos ou se é só aqui que ocorre sempre assim, mas a gente usa uma técnica de programação chamada TDD: Test Driven Development. A idéia é que, se o nosso algoritmo resolve o problema que estamos tentando resolver, ele deve passar em alguns testes (podem ser testes bem óbvios, como "a entrada está certa", ou "para dada saída, o algoritmo deveria responder tal resposta"). Assim, formulando testes, vamos literalmente "construindo" um algoritmo que faz aquilo que queremos, com a vantagem de que os casos de possíveis erros são testados já na hora de criar o algoritmo. Além disso, ao solucionar-se um teste, a platéia pode comentar sobre o que poderia ter sido feito para melhorar o código, ou coisas do tipo, refletindo, enfim, sobre o código apresentado na tela (eu não explicitei isso, mas a idéia é que a platéia esteja, como tal, realmente vendo o que está acontecendo no computador onde o programa está sendo desenvolvido, através, por exemplo, de um projetos).

Enfim... eu participei de um coding dojo, e achei bem legal (e aprendi um pouquinho de Python =D). Fiquei feliz, principalmente porque o problema que a gente tava resolvendo era muito tri (fizemos altas referências à teoria das categorias)  e porque nas próximas vezes espera-se que tenhamos mais do que os pouquíssimos cinco que fomos hoje, na estréia da série 2011 dos coding dojo INF/UFRGS.

Por fim, deixo o link do site do Coding Dojo INF/UFRGS:
http://www.inf.ufrgs.br/pet/index.php?option=com_content&view=article&id=7&Itemid=21 

Lá o leitor encontrará o código de todas as reuniões dos dojos de 2010 e - espero eu -, de 2011 (quando tivermos mais dojos =D). Além disso, vale avisar (caso o leitor seja meu colega) que a participação nos dojos poderá valer créditos complementares num futuro creio que relativamente distante u.u

Eras isso...

R$

5 de abr. de 2011

Traduzindo o Learn you a Haskell for Great Good


Vou pôr em prática um projeto em que vinha pensando há alguns dias - desde que comecei a ler o Learn You a Haskell For Great Good. Vou ajudar na tradução do referido livro.

Estava há uns dias lendo ele - e parei no capítulo 6, Higher Order Functions (apesar de saber já o que tem ali dentro u.u) - e pensando em como seria bom se o livro estivesse em português. Não por mim: a linguagem do livro é boa e mesmo em inglês não tenho nenhuma dificuldade para entender o que está sendo dito. Mas, tendo procurado no google por material sobre Haskell na internet em português, não achei absolutamente nenhum tutorial de qualidade. Certo é que eu procurei só na primeira página, mas, enfim, admita-se que, se há, é em pequenina quantidade.

Assim, tendo falado com um cara que, pelo que vi, já traduziu três capítulos do livro (me pergunto o motivo, mas os capítulos são o 1, o 8 e o 9 O.o), em conjunto com mais "dois outros programadores" (palavras dele), resolvi ajudar. O projeto é pequeno: no github, tem 6 watchers (contando comigo) e 3 forks; mas creio que a sua utilidade será grande =D

Droga é que finalmente terei de aprender (isso não é tão ruim assim, mas a verdade é que eu estava evitando há um tempo isso) a usar o famigerado github, que sempre me deixa meio assustado - essa coisa de criar um fork com um projeto igual e depois ficar mandando pull requests é meio estranha pra mim D=. Bom é que finalmente estarei fazendo alguma coisa "para a comunidade", como sempre pretendi. Gosto dessa coisa de ser útil para a comunidade, mas nunca fui bom o suficiente para produzir algo bom o suficiente para ser aceito por todos. Acho que agora finalmente poderei me sentir útil ao traduzir um livro que certamente é conhecido por todos aqueles que apredem Haskell.

Enfim... era isso \o/

R$

29 de mar. de 2011

Sobre programação e linguagens funcionais

(Para o leitor que está procurando leitura sobre Haskell: Learn you a Haskell for Great Good. Fikdik).

Estou aprendendo Haskell.


Haskell é uma linguagem funcional bastante eficiente e absurdamente bonita. Normalmente, em outro momento, por ser linguagem funcional, eu simplesmente ignoraria a sua existência, já que não creio que seja algo que eu deva usar com muita frequência na minha vida no futuro. Mas... err... não é outro momento.

Estou fazendo uma cadeira chamada Modelos de Linguagens de Programação onde sou obrigado a "me confrontar" com outros paradigmas de programação, como, por exemplo, o funcional. Além dele, pelo que vi, teremos o lógico e, obviamente, o imperativo. A cadeira é legal, e tem tudo para ser uma cadeira interessante, apesar de normalmente as aulas do professor não serem das mais divertidas (mas ele se esforça, e é o que conta =D). Mesmo assim, o assunto me chama muito a atenção, afinal, vim para a computação porque gostava dessa idéia mágica de fazer os computadores fazerem aquilo que quero que eles façam.

O que é divertido que é no fim da cadeira o professor pede que escrevamos dois programas equivalentes utilizando paradigmas diferentes. Ele disse que não sabia se seria assim nesse semestre, mas já defini as linguagens que vou usar (se for assim): Lua para o paradigma imperativo (infelizmente, acho que não poderei usar muito as belezas funcionais da linguagem) e Haskell para o paradigma funcional.

Enfim... o professor colocou no moodle um link para um tutorial que estou lendo sobre Haskell que achei significativamente bom: o Learn you a Haskell for Great Good. É ótimo, apesar de, às vezes, muito lento. Mesmo assim, estou satisfeitíssimo: acho que até o fim de semana já estarei mais ou menos dominando boa parte da linguagem =D

Enfim... é isso. Talvez eu tente falar alguma coisa sobre Haskell num futuro próximo =D

R$

26 de mar. de 2011

Ponteiros em C - Tutorial

Há muito tempo venho pensando em escrever sobre ponteiros. Assim como eu, creio que muitos estudantes iniciantes tiveram sérios problemas para entender esse assunto que, no fim das contas, depois de aprendido, é até que bem fácil. Já vi até bastantes livros sobre o assunto e tutoriais na internet e tudo é muito parecido, sinceramente: falam sobre uma variável de ponteiro, e aí falam sobre o endereço de memória e sobre o que tá guardado no endereço de memória, e sobre aquele asteriscozinho, e depois sobre passar por valor e por referência e blá blá blá . Quando tive as aulas disso no meu primeiro semestre simplesmente ignorei a existência deles, crente de que não me seriam úteis. Estava enganado e, no fim das contas, tive de aprender a coisa na marra.

É do meu interesse que esse post se torne algo como um bom lugar onde as pessoas possam procurar sobre como usar ponteiros em C. Assim, faço questão de pedir que o leitor comente, ao término - ou não necessariamente ao término - da leitura, sobre o que achou, me indicando erros (para que eu possa corrigir) e me sugerindo alguma coisa que ache relevante ao trabalho.

Introdução

Como o assunto é complicado, pretendo ser o que já ouvi muitos chamarem de prolixo. Devo falar, falar e falar, tentando, assim, ser bem claro em minhas definições. Na primeira parte, utilizarei uma analogia para definir bem o conceito em si, não me apegando necessariamente à linguagem C. Mesmo assim, conhecimento prévio das outras estruturas da linguagem é muitíssimo bem vindo, já que não será nem um pouco abordado aqui. No segundo capítulo, elucidarei alguns assuntos que considero de suma importância antes de começar a falar de ponteiros. Assim, discorrerei um pouco sobre os vários usos do operador * na linguagem C e farei algumas considerações sobre ponteiros do C e as referências existentes em C++. Em geral, os usuários da linguagem C já devem estar acostumados com os assuntos tratados na segunda parte; mesmo assim, ainda considero interessante a sua leitura, para que entendam a maneira como pretendo prosseguir pensando ao abordar os temas posteriores.

Na terceira parte, deverei discorrer realmente sobre o uso dos ponteiros em C, destacando suas utilidades, dando exemplos e, principalmente, salientando as várias possibilidades de usos do operador *. Minha sugestão é que o leitor leia esse e os subsequentes capítulos testando trechos de código próprios, além daqueles que estarão disponíveis no próprio post. Por fim, no quarto e último capítulo, sugerirei alguns lugares onde o leitor poderá procurar por mais informações, além de fazer algumas considerações finais.

Capítulo 1

O conceito de ponteiro é nem um pouco intuitivo. Poderíamos dizer que "um ponteiro é uma variável que aponta para um endereço de memória", ou seja, que guarda um endereço de memória (frequentemente, de outra variável). Mesmo assim, concordemos que essa definição, apesar de bonita, só serve pra inglês ver. Assim, tive a idéia (eu duvido que alguém ainda não tenha pensado nisso, mas depois de uma boa procura no google concluí que, se alguém pôs em prática, ainda não ficou conhecido) de usar uma analogia mais intuitiva sobre o mundo real e "o mundo dos ponteiros".

Começaremos a nossa analogia conhecendo a Joana e o Mário. Naturalmente, a Joana é mais baixinha que o Mário, já que normalmente as mulheres são mais baixinhas (estou errado?).
Figura 1.1
Continuando a nossa história, esses nossos dois novos amigos, no mundo real, assumem uma outra forma: eles são endereços de memória. Como tais, eles só podem carregar uma informação de cada vez junto com eles.

No nossa história, o Mário está com o número de telefone da Joana, a saber, 2345678. Já a Joana, está com o número da casa da mãe do Mário: 41.

Figura 1.2
Ao longo da nossa história, isso vai ficar mais claro, mas vale lembrar (como o leitor até mesmo já deve ter percebido) que as coisas no mundo dos ponteiros funcionam de um modo diferente daquele percebido por nós no mundo real. Assim, um exemplo bem característico é o fato de que pessoas no mundo dos ponteiros nunca vivem juntas, ou seja: em cada casa, só cabe uma pessoa. Além disso, às pessoas às vezes são atribuídos chapéus, arbitrariamente, os quais elas são obrigadas a ficar usando durante um tempo indeterminado. Outra coisa[!!!]: nem todo mundo tem casa! Aliás, pouquíssimas pessoas têm. E às vezes essas casas passam de mão em mão, rapidamente.

Voltando a falar de ponteiros e fazendo um paralelo do seu mundo para o nosso, temos agora informações suficientes para definir o que eles são. Sem muita enrolação, os ponteiros são as casas. Elas guardam exatamente uma pessoa (um endereço de memória), tendo ela um chapéu ou não.

Quando um programador, no mundo real, declara uma variável qualquer (um int, por exemplo), ele aloca alguns endereços de memória para uso no seu programa. Isso significa, no mundo dos ponteiros, que agora aquelas pessoas têm chapéu, até que o programa acabe ou que a variável seja, de alguma forma, desalocada.

Acalme-se, jovem programador: ainda temos muito texto pela frente. O importante agora é só saber exatamente aquilo que eu disse: ponteiros são casas, ou seja, variáveis que guardam endereços de memória. A figura 1.3 faz um resumo da nossa analogia:
Figura 1.3

 Capítulo 2

Aqui eu faço uma pausa: esqueçamos nossa história por um tempo. Antes de continuar explicando sobre ponteiros precisamos de um certo embasamento. Assim, divido o capítulo em duas partes: uma sobre referências em C++ e outra em que combinarei com o leitor alguns padrões de notação (e, sim, essa última é, acho, a parte mais importante do capítulo).

2.1 Sobre referências em C++
A linguagem C, na minha opinião, é "completa" no que trata de ponteiros. Com ela, podemos - o leitor não precisa entender do que estou falando nesse primeiro momento - referenciar (usando o &) e desreferenciar (usando o *). Com o "advento" do C++, inventaram as "referências" (não confundir com o "referenciar" e o "desreferenciar" da frase anterior), que tem uma semântica parecida com a dos ponteiros, mas que não é completa por si só, precisando ainda dos ponteiros para se basear. Além disso, as ditas referências "mudam" a semântica do operador "&", diminuindo a sua ortogonalidade.

Assim, me abstenho de fazer qualquer consideração sobre o que são e como funcionam as referências nos capítulos seguintes, me limitando a dizer que elas simplesmente não existem na linguagem C. Dessa forma, pessoas com dúvidas sobre protótipos de funções (i.e., a declaração da função) utilizando, em qualquer parte, um &, devem procurar outro tutorial na internet sobre o assunto.


2.2 O operador *
Muitas vezes, o grande motivo pelo qual o programador iniciante se confunde com ponteiros não tem nada a ver com o ponteiro em si, mas com o operador *. No início do capítulo 3, eu ensinarei como o são declarados ponteiros em C. Aqui, farei um pequeno resumo.

Para declarar um ponteiro, basta seguir o padrão "<tipo>* <nome da variável>;". Isso também serve para, ao escrever uma nova função, especificar que você quer que haja um parâmetro que seja um ponteiro. O código a seguir exemplifica o que quero dizer:


Sabendo que o * é um operador (unário, diga-se de passagem), ele não é influenciado por espaços (bem como qualquer operador). Um exemplo disso seria o operador de soma: tanto faz escrever 2+3, 2+ 3 ou 2 + 3, ou qualquer combinação diferente (inclusive com um número maior de espaços). Assim, frequentemente vemos pessoas jogando o operador * para todos os lados, o que normalmente confunde o programador inexperiente:


Nos trechos acima, parece trivial enxergar que o tipo daquelas variáveis é ponteiro. Mas e quando temos uma função que recebe um ponteiro e manipula esse ponteiro dentro de si? Mais adiante veremos um exemplo, mas antes preciso discutir sobre a utilidade de um irmão gêmeo do operador *, o operador de desreferência. No capítulo 3, o veremos com mais detalhes, mas aqui faço um resumo sobre ele.

Agora que você já sabe para que servem os ponteiros (fazer referência a endereços de memória) e já viu qe eles têm um tipo (ou seja, referenciam endereços de memória alocados com o propósito de guardar uma informação daquele tipo), você já deve ter percebido que eles não seriam muito úteis se não tivéssemos um mecanismo para acessar aqueles endereços, certo? O C disponibiliza, para tanto, o operador * (sim, ele mesmo, mas usado num outro contexto). O exemplo abaixo deve deixar claro como usá-lo (ao menos tenta).


Você saberia me dizer o que cada uma das funções acima faz (por favor, sem ler os comentários)? Creio que alguns leitores desavisados me diriam que a primeira e a última função fazem exatamente a mesma coisa, o que não é verdade. Mesmo assim, creio que a ambiguidade deixa de existir quando o * fica perto do tipo, como na terceira função. Dessa forma, para que não haja esse tipo de problema, usarei o asterisco, daqui para a frente, sempre perto do tipo.

Vale reforçar aqui o seguinte: uma vez usado o asterisco, ele se torna parte do tipo. Dessa forma, faz sentido dizer que o tipo de uma variável é, por exemplo, um ponteiro de inteiro (int*). Isso é importante para a continuação do texto.


Capítulo 3

Voltando à nossa história (do Mário e da Joana), vamos definir ponteiros, sua sintaxe e seus vários usos. Como já vimos antes, no capítulo 1, ponteiros são as casas dos endereços de memória, ou, melhor, são as casas das pessoas no mundo dos ponteiros.

Como também já visto, casas são um bem extremamente difícil de se adquirir no mundo dos ponteiros, além de frequentemente passarem de mão em mão rapidamente (ponteiros, nos programas, estão frequentemente trocando o endereço para o qual estão apontando).

3.1 Declarando ponteiros
Para criar uma casa no mundo dos ponteiros (ponteiro em C), deve-se utilizar a seguinte sintaxe:
<tipo>* <nome_da_nova_variável>;

Essa sintaxe também serve para indicar que uma função pretende receber como parâmetro um ponteiro. O seguinte trecho de código (também utilizado no capítulo 2) exemplifica o caso:


Em C, quando uma variável é criada, ela não é inicializada com nenhum valor. No caso de ponteiros, é como se, ao terminar de construir uma casa, um endereço de memória vileiro já fosse lá e invadisse, tomando-a para si. Assim, a forma de expulsar o morador indesejável do lugar é atribuindo um endereço de memória "nulo" pra ela. Em C, a constante "NULL" (que é o mesmo que escrever o valor 0, mas aconselho fortemente que se use NULL em vez de 0) serve como tal endereço, e, no mundo dos ponteiros, ele definitivamente é o cara mais rico do mundo.

Como eu disse, o mundo dos ponteiros têm uma série de especificidades, muitas das quais ainda não foram numeradas (e que, ao longo do tempo, serão reveladas). Uma delas é o fato de que cada pessoa tem um número, relativo ao seu endereço de memória. Dessa forma, poderíamos dizer que o NULL é o 0, por exemplo. Da mesma forma, o Mário poderia ser, por exemplo, o 40.000, e a mãe do Mário, como já visto (veja a figura 1.2), seria o 41.

Como ponteiros são variáveis como qualquer outra, a atribuição é feita do mesmo jeito, através do sinal de "=". Além disso, ponteiros são números, como qualquer inteiro, o que implica que também podemos manipulá-los como manipularíamos inteiros, através de somas, multiplicações ou substrações, por exemplo (isso seria o mesmo que ficar mudando arbitrariamente o dono da casa).

O seguinte trecho de código mostra um exemplo desse tipo de manipulação. Eu crio um array de 20 inteiros e um ponteiro. Mando o ponteiro apontar para o primeiro endereço de memória desse array e percorro o array, sem fazer nada (acalme-se, jovem programador, logo faremos alguma coisa). Caso o leitor não entenda o "+4", eu explico: nesse código, estou supondo que o inteiro tenha o tamanho de 4 bytes. Como cada endereço de memória aponta para um byte diferente, tenho que pular 4 bytes para chegar no início de um novo inteiro. Mais para a frente, mostrarei uma outra forma mais interessante de pular exatamente o tamanho do inteiro (independente de qual seja esse tamanho).


Como eu disse, logo esse código fará alguma coisa, mas antes precisamos de um pouco mais de informações. Em primeiro lugar, quero apresentar ao leitor dois novos operadores: o irmão gêmeo do *, e o operador &.

3.2 Os operadores * e &
Suponha agora que você saiba em que casa mora atualmente a Joana (tenha um ponteiro dela) e que queira perguntar a ela que informação ela guarda. Obviamente, dependendo do tipo da informação (int, char, etc), você terá de perguntar não só a ela, mas também a algumas outras pessoas que têm numeração imediatamente posterior a ela (no caso de um, por exemplo, serão mais 3 pessoas, além dela). O operador de desreferência (*) tem como objetivo lhe permitir isso.

Assim, dado um ponteiro (uma casa), você poderá, utilizando o *, alcançar o endereço de memória que ele aponta (o morador da casa). Utilizaremos o trecho de código anterior para exemplificar o uso do *:


Você consegue me dizer o que o trecho de código acima faz? Ele pega o valor int do endereço de memória para o qual o ponteiro está apontando, e soma-o com a variável soma. É interessante compreender aqui a importância do tipo do ponteiro: o que aconteceria se o tipo do ponteiro que estamos utilizando fosse char, que utiliza somente 1 byte? E o que aconteceria se o ponteiro apontasse para uma struct que utilizasse, por exemplo, 8 bytes? Como eu disse antes, os ponteiros lêem endereços de memória, sem se preocupar com o que tem dentro deles. Assim, o ponteiro de char leria somente 1 byte (e não seria problema nenhum, no nosso caso) e o ponteiro do tipo da referida struct leria 8 bytes (o que seria um problema quando chegássemos na última iteração do for, já que haveria a possibilidade de lermos endereços não alocados para uso do nosso programa, i.e., pessoas sem chapéu).

Com o objetivo de introduzir o operador &, preciso contar mais uma coisa sobre o mundo dos ponteiros. Todas as pessoas, no mundo dos ponteiros, podem ter um número incontável de clones (fique claro, aqui, que ser clone é um propriedade reflexiva, o que significa que, se o Mário tem um clone, então o Mário é um clone desse clone, bem como o clone é clone do Mário). Assim, normalmente, nas chamadas de funções (no mundo deles, festas), os endereços de memória, preguiçosos, em vez de irem eles mesmos, mandam clones de si. Que forma melhor para convidar alguém para uma festa do que mandar um convite justamente para a casa da pessoa? É exatamente para isso que serve o operador &. Quando usamos o &, o operador de referência, pegamos o endereço de memória da variável à qual esse operador está sendo atribuída. O trecho de código a seguir tenta exemplificar o caso:

Apesar de por agora ele parecer não ter muita utilidade, o operador & terá um uso significativamente importante no futuro.

3.3 Sizeof()
Quando apresentei o operador *, escrevi um trecho de código que somava todos os elementos de um vetor de tamanho 20 e colocava a soma numa variável chamada soma. Naquele momento, para iterar entre os elementos do vetor, simplesmente supus que o tamanho de um inteiro era de 4 bytes. Assim, a cada iteração, para atualizar o lugar para onde o ponteiro (passar a casa - o ponteiro - de um dono para o outro - os endereços de memória) estava apontando, eu somava 4 ao valor do ponteiro.

O problema é que freqüentemente o tamanho de um int muda, dependendo do compilador usado, das configurações usadas na compilação e da arquitetura para a qual o programa foi compilado. Ao mesmo tempo, seria um problema se, a cada lugar onde eu fosse compilar o programa, eu tivesse que setar todos os tamanhos direitinho. Para resolver o problema, existe a função sizeof(), que retorna exatamente o tamanho do tipo passado como parâmetro. Ela será muito mais útil para outros fins, mais para a frente. Mesmo assim, o exemplo a trecho de código a seguir exemplifica o seu uso e mostra como aquele nosso outro exemplo poderia ser escrito de uma forma mais interessante:

3.4 Passagens de parâmetros
Antes de começar a falar sobre um assunto bastante novo, gostaria de fazer algumas considerações. Em primeiro lugar, caso o leitor seja um programador principiante, sugiro que tente brincar mais com os ponteiros, fazendo códigos próprios e testando os resultados. Sugiro que volte à seção 2.2 e tente reler o código, agora entendendo melhor o que foi dito lá. Em segundo lugar, gostaria de pedir que o leitor testasse cada um dos trechos de código que serão exibidos a seguir, já que podem acabar causando alguma confusão. O assunto, admita-se, é extremamente não intuitivo, apesar de não ser difícil.

Em terceiro lugar, quero fazer uma distinção entre variável e endereço de memória. Uma variável é uma abstração de um ou mais endereços de memória. Como eu já disse, no mundo dos ponteiros, isso equivale a dar chapéus para as pessoas que estão sendo "ocupadas" para uma variável. Mesmo assim, no texto a seguir, os dois conceitos meio que se confundem, no sentido de que "chamar uma variável para uma festa" é o mesmo que "chamar os endereços de memória de uma variável para uma festa", ou, melhor "chamar as pessoas com o chapéu relativo a uma variável para uma festa". Quando falo que uma variável é preguiçosa, quero dizer que "todas as pessoas com chapéus daquela variável são preguiçosas". Com isso dito, creio que podemos ir em frente.

Figura 3.1 - Achei que era interessante por essa figura aqui =D


Como eu disse em outro momento, as pessoas, no mundo dos ponteiros, têm um número indeterminado de clones. Além disso, lá, quando falamos em chamadas de função no mundo real, estamos falando de festas. Para exemplificar o caso, peguemos a seguinte função:

O programador iniciante, ao olhar para essa função, acharia natural que, após a chamada da função, a variável passada como parâmetro tivesse o seu valor incrementado de 1. O que acontece é que, como também já foi dito antes, as pessoas no mundo dos ponteiros são preguiçosas, e, a menos que sejam chamadas em específico elas mesmas, elas naturalmente mandam clones de si mesmas para as festas. Para o mundo real, isso significa que a linguagem C, ao receber uma chamada de função como aquela, copia o valor da variável passada como parâmetro para outro endereço de memória e, em vez de manipular a variável, manipula esse novo endereço de memória, mantendo a variável intacta.

Para exemplificar, utilizemos a nossa função e o seguinte trecho de código:


Para resolver o problema, precisamos de um jeito de chamar a variável certa (e não um clone dela) para a festa. Aliás, as pessoas no mundo dos ponteiros são muito bem educadas: elas SEMPRE vão, quando chamadas, elas mesmas, para as festas. Como eu já disse em outro momento, qual modo melhor para chamar alguém para a festa do que justamente entregar o convite em sua casa? O equivalente a isso, em C, seria modificar a função incrementa de forma que ela recebesse uma casa - um ponteiro - como parâmetro. Assim, na hora da chamada, passaríamos uma casa como parâmetro, fazendo com que a própria variável comparecesse à festa. Veremos como isso ocorreria num exemplo real:


O que houve aqui? Em primeiro lugar, quero avisar ao leitor que ponteiros também são variável, e, como tais, ocupam endereços de memória. Assim, obviamente, casas são formadas por pessoas (o que talvez torne o dono de uma casa um escravocrata, no mundo dos ponteiros). Como casas são pessoas, elas também têm clones. E como elas têm clones, elas também são preguiçosas e às vezes resolvem mandar seus clones no seu lugar nas festas.

Assim, realmente, quando a casa foi passada como parâmetro, ela, em vez de ir para a festa, mandou um clone seu em seu lugar. Dessa forma, se o clone fosse modificado - no caso, não ocorreu, mas ele poderia ter sido -, a casa original permaneceria intacta. Mesmo assim, o conteúdo da casa e do clone eram o mesmo: ambos apontavam para o mesmo endereço de memória. Assim, esse endereço de memória não tinha como fugir: ele FOI sim à festa, tendo sido modificado.

Esse tipo de passagem de parâmetro (mandando a casa da pessoa, em vez de a pessoa) é chamado de passagem de parâmetros por referência, e frequentemente causa problemas até mesmo a programadores um tanto experientes, visto que é muito fácil esquecer um asterisco aqui ou ali.

3.5 Alocando espaço
Um último assunto antes de terminar o capítulo 3: malloc(), free(), e acessos a endereços inválidos de memória.

O leitor deve lembrar que, lá em cima, eu falei sobre o NULL, o cara mais rico do mundo dos ponteiros. Feliz ou infelizmente, a sua fortuna normalmente dura pouco tempo: tão logo ele ganha uma casa, ele logo já perde para um outro alguém. Traduzindo, é uma boa prática de programação atribuir NULL a todos os ponteiros que não podem ser imediatamente inicializados. Mesmo assim, ninguém cria ponteiros se não for usar, a menos que o NULL tenha algum sentido útil no seu programa (e de vez em quando tem).

De qualquer forma, como eu disse, o NULL é um cara rico. Assim, como pessoa rica, pessoas comuns não têm acesso a ele. Dessa forma, se um programador, em seu programa, tentar acessar o endereço de memória NULL, através de um ponteiro, por exemplo (utilizando o operador *, no caso), o seu programa irá travar. Além disso, há uma certa probabilidade de que, se o programa tentar acessar endereços de memória sem chapéu (ou seja, não alocados devidamente para o programa), o programa também trave. Por isso, é altamente recomendado só acessar pessoas com chapéus, já que essas são as já conhecidas pelo seu programa.

O uso de vetores e variáveis torna dar chapéus para os programas uma tarefa significativamente fácil. Mesmo assim, tem vezes em que o programador simplesmente não sabe, por qualquer motivo, quantos chapéus deverá distribuir (ou seja, quantos endereços deverá alocar). Pode ser que o tamanho mude conforme a entrada do usuário, ou mesmo que ele queira alocar o dobro do espaço alocado toda vez que todo o espaço alocado tiver sido utilisado.

Para solucionar esse problema, existe a função malloc(). Ela retorna um ponteiro do tipo void com o espaço alocado. O tipo void* é um tipo especial, na linguagem C. Ele significa "nenhum tipo", ou "qualquer tipo". Assim, podemos atribuir a esse tipo ponteiros do tipo que quisermos. O trecho de código a seguir exemplifica o uso da função (ignore a parte do "free()" por um momento):


Infelizmente, a linguagem C++ (sim, aqui falo do C++) é meio chata com atribuições de tipos diferentes. Assim, para manter a compatibilidade entre as duas linguagens, quando utilizamos malloc(), é interessante colocar um typecast (um aviso de qual é o tipo que queremos que o malloc seja) à esquerda do uso da função. No trecho de código acima, esse typecast é feito através do (int*) à esquerda do malloc(). Como parâmetro, a referida função só exige um número, que significa o espaço em bytes que queremos assim.

No nosso caso, queremos alocar o espaço de 10 inteiros para o ponteiro "meu_ponteiro" (por isso aquela multiplicação dentro do malloc(). Isso não significa que ele guardará todo esse espaço em sua variável. Diferentemente, ao término da atribuição, o ponteiro terá guardado o endereço de memória do início da área alocada. Assim, daquele endereço até o fim da área alocada (no nosso caso, sizeof(int) * 10) todas as pessoas, no mundo dos ponteiros, terão chapéus.

Para desalocar esse espaço, devemos usar a função free(). Ela recebe um ponteiro como parâmetro e simplesmente desaloca aquela área (retira o chapéu das pessoas da área).

Capítulo 4

Finalmente, chegamos ao final do nosso estudo sobre ponteiros. Esse capítulo só trás algumas considerações finais sobre o meu texto, me identifica e mais alguns detalhes.


Todas as imagens do texto foram feitas utilizando o KolourPaint, no Ubuntu. Por esse motivo, os textos nas imagens ficaram sem acento - tentei por acento, não consegui de primeira, desisti. Além disso, tentei e consegui usar o "syntaxHighlight 1.5.1". Depois de conseguir, percebi que realmente o Pastebin tinha um sistema de embedding muitíssimo bom (além de me permitir usar tabulações no código) e passei a usá-lo.

Esse post teve inspiração em várias coisas que andei vendo e pensando nos últimos tempos, mas destaco especialmente a série de aulas de C que o Fialho tem postado em seu blog, Lines of Code, de vez em quando. Além disso, não deixo nenhuma bibliografia utilizada, já que, realmente, não usei nenhuma.

Aviso especialmente que nenhum trecho de código postado foi testado, o que significa que, sim, PODE HAVER ERROS. Dessa forma, peço que o leitor me ajude com correções e sugestões, no caso de querer contribuir.


------------------------
Era isso... se tiverem algo mais com o que contribuir, peço que postem comentários. E, humildemente, peço que, se forem repostar isso em algum lugar (estou meio orgulhosinho do meu texto, e acho que ele ficou bom mesmo, né?), ao menos mantenham o link original de onde foi retirado =D

R$

20 de mar. de 2011

Trote universitário CiC UFRGS, bebedeira, HPS

Estou abismado.

A cada hora recebo notícias e mais notícias de um assunto que gerou polêmica desde ontem denoite, quando mandaram para a lista da graduação do curso de Ciência da Computação (CiC) da UFRGS (onde estudo) um e-mail com o link de uma notícia da ZH dizendo que um aluno do nosso curso teria entrado em coma após um trote violento no Parque da Redenção, na capital.

Na hora, achei uma extrema bobagem, mas obviamente aquilo era só a ponta do iceberg. Criou-se uma flamewar (em termos: teve um cara que resolveu dizer que trote é algo que não deveria acontecer, e blá blá blá, dizendo que trote é fascista - Hitler? -, militarista, sádico e autoritário. Gente assim, obviamente, é troll nato, que não merece atenção, lamentavelmente) na lista da graduação, ao mesmo tempo em que se comentava a cada momento no Chat da Cic, na lista da Patota e ainda na comunidade da UFRGS. Até na lista da graduação da Astrofísica (da UFRGS) teve discussão sobre o assunto (um professor que não sabia de NADA lá resolveu mandar por e-mail a reportagem MENTIROSA da Zero Hora comentando coisas como "olha a barbaridade que esses estudantes fizeram"). Na Astrofísica, meu irmão mandou um e-mail com todos os comentários e desmentiu a história do professor.

Hoje, sábado, às 12h20 da noite (ou seja, já é domingo, pra quem aceita essa coisa de trocar de dia depois da meia-noite), as notícias ainda não terminaram, de certa forma: o cara voltou pra casa, desmentiu a história através do orkut (assumiu a responsabilidade, dizendo que bebeu sim de livre e espontânea vontade) - claro que houve trolls dizendo que o perfil dele era fake u.u -, e agora dizem alguns jornais que a família tá reclamando que os veteranos não prestaram socorro a ele rápido o suficiente e obrigaram a família a ir levá-lo pra o hospital, em vez de eles próprios fazê-lo.

Li um horror, tanto na comunidade da UFRGS, quanto na lista da graduação e no chat da CiC (e até no buzz) e concluí que o melhor lugar a se ler sobre o assunto, no fim das contas, é esse blog.

No fim, uma conclusão: sabem aquelas reportagens de jornal onde se fala um monte de coisas sobre as quais a gente fica assustado pensando que deve ter sido um negócio horrível (ou acha tri, no meu caso, porque a barbárie foi grande e divertidamente sádica)? Em geral, elas são só sensacionalismo barato da mídia T_T (talvez feliz, talvez infelizmente)

// O Correio do Povo chegou a dizer que ele foi obrigado a ingerir ÁLCOOL DE COZINHA!!!

R$

7 de fev. de 2011

Procrastinação

Apesar de achar o título uma palavra extremamente feia - que só fui conhecer no inglês e depois descobri que o pessoal também a usa no português -, entendo que ela realmente precisa receber o título de título dessa postagem.

Desde que as férias começaram, comecei a fazer várias coisas - e planejei várias outras que nem comecei ainda. Comecei a ler O Senhor dos Anéis (aliás, até agora não me arrependi nem um pouco), comecei a ler o tal do Guia Foca, comecei a aprender Lua (uma linguagem de programação brasileira, mantida pela UFRJ, muito usada em configuração de jogos, interpretada e extremamente eficiente - apesar de isso me ter parecido um paradoxo, no início -, além de sexy u.u) e, por último, comecei a ler alguns artigos/dissertações por causa do meu novo "trabalho" (entre aspas porque, como sempre, não gosto da etimologia da palavra: "tripalium", i.e. tortura).

--[[
Aliás, sobre o segundo e o terceiro item, gostaria de comentar algumas coisas.

Tenho lido o Guia Foca e achado muito bom. O Guia é extremamente didático, e se divide em 3 "dificuldades": iniciante, intermediário e avançado. Li inteiro o iniciante (porque não queria perder informação alguma - e, sério, o iniciante fala de algumas coisas que eu nem imaginava) e achei muito bom, apesar dos freqüentes erros. Aliás, esse é um sério problema do Guia: o cara escreve relativamente mal, na minha opinião. Mesmo assim, somente um erro que encontrei era erro sobre a explicação. Todos os outros eram erros de português. Frases siamesas, falta de preposições quando necessárias, vírgula no lugar de ponto, ponto no lugar de vírgula, etc.

Agora, tendo chegado no intermediário, ando parado (aliás... estou parado em tudo. Por isso o título do post n_n): tenho a impressão de que ele está repetindo tudo. Na verdade, acho que era essa a proposta. Provavelmente, no avançado, ele vá repetir muitas coisas do intermediário e adicionar outras, além de retirar aquelas que são mais "iniciantes". Só que, como li já o iniciante, resolvi que vou ler parte a parte.

O objetivo final de ler o Guia Foca é aprender a fuçar no linux para então saber como funciona o Xorg. Tenho tido alguns sérios problemas com os drivers da NVIDIA para minha placa de video para o ubuntu. Creio que aprender sobre o assunto, além de útil, me ajude a resolver o problema.

Sobre Lua, o livro que estou lendo é extremamente agradável. A leitura é fácil, a linguagem é absurdamente bonita (até agora não tive nada a reclamar dela) e estou parado no capítulo 8. Tenho muita vontade de começar a ler, quando me paro na frente do computador, me vem uma súbita preguiça e acabo nem começando. A linguagem é claramente imperativa, mas dá pra fazer umas "gambiarras" (na minha opinião inicial, ao menos) pra "emular" muito bem orientação a objetos. Além disso, ela também "aceita" o paradigma funcional. Como funções são "valores" na linguagem, dá pra inclusive passar elas por parâmetro pras chamadas de outras funções e coisas do tipo. Até agora, não tenho como reclamar: não me mostraram nada que eu ache incômodo na linguagem, sem falar que ela trata strings de uma forma extremamente eficiente e intuitiva (são "valores" também). O melhor de tudo, nela se escreve pouco (digo isso porque é a primeira linguagem "em que se escreve pouco" que eu pego até agora =D).
--]]

Voltando a o que eu estava dizendo, comecei muita coisa desde o início dessas férias. Estou feliz porque tem cara de que terei tempo para terminar todas aquelas que precisam ser terminadas antes do fim das aulas. Estou triste porque não consegui jogar nenhum joguinho. Não terminei Kingdom Hearts - estou parado há MUITO tempo D= -, não comecei Final Fantasy IV (DS), não fiz o joguinho que queria fazer em Lua usando a Löve (uma engine 2D com cara de muitíssimo bonita, como tudo o que vi de Lua até agora) com o Fialho e o Apus (na real, foram os únicos que demonstraram interesse em fazer o jogo, e por isso Lua é uma ótima escolha), não voltei a participar dos grupos musicais de que queria voltar a participar, não estudei alemão, não voltei à natação, e dormi bastante.

Apesar de tudo, tenho dois grandes trunfos para o término das férias: em primeiro lugar, estarei realmente descasado dessa vez. Diferentemente das outras férias, em que eu ficava frustrado porque estava sempre cheio de coisas pra fazer, dessa vez eu simplesmente joguei tudo pro alto e literalmente fiz somente aquilo que me agradava. Meio egoísta da minha parte, talvez, mas ao menos não estarei estressado ao começarem as aulas, minha mãe não me encherá o saco (na real, ela vai, de qualquer forma, porque sempre reclama que estou resmungando, apesar de ela ser a única pessoa a reclamar disso ¬¬ - beijo, mãe =D) com meu mau humor, e estarei totalmente disposto a acordar cedo pras aulas nos dias em que tiver de fazer isso. Em segundo lugar, estou significativamente satisfeito com a minha veia musical: apesar de ainda não ter voltado a nenhum grupo musical religioso do qual fazia parte (e até é bem possível que nem possa voltar, já que as aulas de LIBRAS serão bem no horário dos ensaios musicais da igreja), começarei a brincar de tocar flauta transversal (finalmente, "dei um jeito" de conseguir uma \o/). Além disso, arranjei alguém com quem tocar as maravilhosas músicas de video-game que eu tanto amo, em arranjos que nós mesmos faremos (ou talvez consigamos algum na internet, também, sei lá o>) para flauta e violão. O objetivo final mesmo é só se divertir, tocar por tocar, brincar, fazer barulho, ou música, como quiserem chamar u.u

Queria ver se conseguia a partitura da "La Historia del Tango", do Astor Piazzolla, pra tocar com o Kim (o amigo do violão). A música é pra flauta e violão, e eu sempre achei a música tri legal, apesar de bastante difícil D=. Abaixo ficam dois videos, dos movimentos 2 - Café 1930 e 3 - Nightclub 1960. Toquei esses dois movimentos num quarteto de clarinete que "formamos" no Festival de Música da UNISINOS, em novembro de 2006 (eu era um aluno, assim como mais umas 6 pessoas que lá estavam, e o professor - que era meu professor na OSPA também - me pôs pra tocar junto com ele e mais dois que lá estavam, ambos militares). Fica aí, pra que, quando eu quiser ouvir, eu possa =D





(ai ai... que preguiça T_T)

Era isso.........

R$

30 de set. de 2010

Documentação

Estou agoniado...

Estava dando uma olhada na documentação do ZSNES e, sinceramente, o negócio tá triste. Não dá pra achar nada!!! D=

Por acaso, pra falar a verdade, encontrei: encontrei um link pra um "manual" feito pras versões 1.42 e 1.50 (ambas, já, obsoletas, apesar de úteis - alguns jogos, como Kirby Avalanche, não rodam na atual versão 1.51, no que a minha recomendação normalmente é usar uma versão mais antiga, como a 1.36, que considero a melhor nesse sentido; além disso, a versão 1.42 é a última versão em que a internet está "ativada", tendo essa funcionalidade sido retirada do emulador a partir da versão 1.50, em virtude dos vários bugs que ela tinha), o qual pode ser baixado nesse link. Mesmo assim, mesmo tendo achado alguma documentação sobre "como usar" o ZSNES, não consegui nem chegar perto de tentar começar a entender (conseguiram acompanhar a distância??!!) o código do ZSNES, em qualquer parte que eu tente começar a ler. São tantos arquivos, com tanta coisa, tanta informação, tantas referências de arquivo pra arquivo, tantas bibliotecas diferentes "includadas", que eu nem sei por onde começar. Mas... quem é que quer continuar com o projeto do ZSNES, que tá parado há um tempão (desde o fim de 2006)!?!? (tá tá, na verdade, eu nem olhei o código do ZSNES: eu só procurei pra ver se achava alguma coisa próxima do que o Juliano  - um colega meu - tinha me dito: quando falei sobre o manual do ZSNES que tinha achado, ele pensou que fosse um manual relativo a programação e tudo mais, e como o Fialho concordou com a possibilidade, resolvi procurar)

(Quanto ao não ter conseguido entender o código, eu realmente já tinha tentado uma vez, sem muito ânimo, e não deu em nada, no que rapidamente desisti: estava tentando entender o motivo de o ZSNES simplesmente não compilar para arquiteturas x64 D=)

Mas, pra falar a verdade, o que me agonia é o tamanho da falta de preocupação dos caras que escrevem programas em manter uma documentação decente, atualizada, e tal. Ano passado, passei semanas tentando resolver os vários problemas de compilação de um programa que estava tentando usar, chamado Quagga (na real, o programa, em si, funcionava bem, mas a extensão dele que eu estava tentando usar é que era bugada). Toda a vez que eu consertava algum problema (uma referência mal-feita, um include faltando, etc), aparecia um novo erro. Me incomodava que, quando eu ía olhar o código, não dava pra entender bulhufas: as variáveis tinham nomes mágicos como HWDIDUGTHERE (tá tá... só um exemplo) e os comentários só apareciam no início do arquivo, dizendo que o arquivo era de código aberto e que nenhuma garantia sobre o seu funcionamento era dada... ¬¬

Quando tu ía ler a documentação do programa (tinha um arquivinho bonitinho disso), tu via que, de uma versão pra outra, eles só mudavam o número da versão, sem realmente escrever se alguma coisa tiver mudado (lembro que o arquivo era o mesmo já há um tempão e que tinha versões em que ele nem tinha sido mudado para casar com a versão do programa D=)

Algo muito próximo me tem acontecido com uma biblioteca que, pelo que vi, até que é bem popular na internet para parsear midi. Tenho tentado usá-la, mas o negócio tá tr00. O nome dela é libjdkmidi, mas ela recentemente (beeem recentemente: dia 14 de setembro de 2010, duas semanas atrás, praticamente) mudou de nome pra jdksmidi. Até duas semanas atrás ela tinha uma página bonitinha, cheia de detalhezinhos sobre como testar (apesar de não muito úteis, já que os arquivos sobre os quais a página falava não existem mais no pacote O.o), que felizmente foi "mirroreada" por um outro site, o qual agora tenho usado pra dar uma olhada.

De qualquer forma, o que me acontece é que a biblioteca tem uma documentação DESGRAÇADA!!! Tão desgraçada que eu tive de baixar um programa que a usa (e foi meio sacrificoso instalar o programa, já que tava faltando um include no meio do tudo pra ele poder compilar sem reclamar) pra poder entender. Tão desgraçada que, basicamente, ela me mostra uma lista de todas as classes que compõem a biblioteca (que foi escrita em C++) de várias formas diferentes: primeiro na ordem dos arquivos, depois em diagrama de classes (que bom, em?? Agora eu conheço a hierarquia das classes da biblioteca, em!?!?), e por último em ordem alfabética. Como referência, é 10. Como tutorial, é 0.

Assim, sou obrigado a ficar lendo o maravilhoso código desse cara pra entender como usar esse lixo ¬¬

Não acho isso certo, e certamente, se eu tivesse feito, teria feito no mínimo diferente. Maaasss... como é o que tem... e como os programadores não parecem muito a fim de mudar (vide código dos kernels do linux), e como eu creio ser somente um no meio de milhões gostando desse modo de fazer as coisas, então, acho que terei de me acostumar D=

(será que alguém vai concordar comigo?!?!)

Eras isso...

R$

28 de mai. de 2010

PostgreSQL + pgAdminIII no linux

Se você não me conhece:

Se você quer saber como criar um banco de dados e usar o pgAdminIII para brincar com ele, clique nesse link. O resto do post é só um comentário sobre o que houve comigo quando precisei fazê-lo =D

(escrevo isso porque sei que possivelmente alguém vá cair aqui tentando resolver algum problema com ambos os programas e vai querer me mandar a algum lugar feio por descobrir que isso é somente um post sobre o que me aconteceu quando fui usar esses programas)

Se você me conhece:

Diferentemente do que pareceu ser lá na UFRGS, quando eu fui tentar instalar o PostgreSQL no meu windows, só tive problemas. Descobri que, por algum motivo, o "Microsoft C++ Redistributable" (seja lá pra que exatamente ele sirva) estava com sérios problemas, e tudo o que necessitasse dele pra executar dava um erro bizarro, do qual, tendo procurado-o na internet, pouco ainda sei.

Depois de uma hora e meia descobrindo, procurando na internet e tentando resolver o problema, concluí que isso não era coisa pra hoje, já que tenho que estudar pra prova de Fundamentos de Bancos de Dados de uma vez. Vim pra o Linux, no que me encontrei em mais um problema: por algum motivo, diferentemente do que um colega meu tinha dito, o pgAdminIII simplesmente não estava conseguindo encontrar o tal banco default que o Postgres cria direto quando é instalado (ao menos, pelo que tinha entendido, ele só tinha adicionado o banco e tudo tinha se resolvido magicamente D=). Assim, tive de procurar na internet como criar um banco novo a mão.

Foi um tanto frustrante num primeiro momento, já que eu não agüentava mais simplesmente não estudar - é uma droga quando tu tem tempos pré-definidos pras coisas e não consegue fazê-las acontecer dentro desse tempo -, mas, depois de um tempo lendo a maravilhosa documentação do Postgres (sério, eles têm uma documentação muito boa \o/), concluí que isso não estava me levando a lugar algum: quando eu tentava o comando createdb, ele dava um erro fatal e não fazia nada D=.

Enfim, depois de um tempo, encontrei esse link, que resolveu o meu problema. Agora posso estudar FBD feliz e saltitante.

Uma pena eu ter perdido a manhã inteira com esses contratempos D= (e ainda depois de tudo ter resolvido vir aqui postar isso no blog).

É isso...

R$

10 de mai. de 2010

Trígrafos

Vocês sabem o que são trígrafos (em inglês, trigraphs)?!!? [sim, eu me dei ao trabalho de traduzir a palavra pra o meu maravilhoso português]

Tá tá... todo mundo sabe: se dígrafo é um conjunto de duas letras pronunciadas juntas uma com a outra, então trígrafo deve ser o análogo relativo a três letras. Mas o que eu não sabia é que existem trígrafos no C (a linguagem de programação \o/ \o/).

Os tais trígrafos são uma forma de escrever alguns caracteres "diferentes" de maneira alternativa no padrão ISOC98. Alguns países do mundo simplesmente não têm algumas letras e, por isso, necessitam dessas formas mágicas para escrever tais caracteres. A seguir vai a lista dos caracteres que tem uma segunda notação "trigráfica" no C (ou, ao menos, os caracteres que eu descobri):

??= <==> # pound sign
??( <==> [ left bracket
??) <==> ] right bracket
??< <==> { left brace
??> <==> } right brace
??/ <==> \ backslash
??’ <==> ^ caret
??! <==> | vertical bar
??- <==> ~ tilde

A seguir vai um programa exemplo que fiz pra ver se funciona. Incrível: é só rodar o código

gcc teste_trigraphs.c -o teste.exe -trigraphs

e o programa compila perfeitamente substituindo todas as aparições dos caracteres trigráficos do código pelos caracteres comuns.


// teste_trigraphs.c
//
// Programa cujo único intuito é verificar se os caracteres
// trigráficos vão se tornar os "normais" após a compilação
#include <stdio.h>

int main ()
{
puts("teste dos tais trihgrafos: ??' deve virar ^ \n");
int a = 2,
b = 255,
c;

c = a ??! b;
printf("%d\n", c);

puts("Sera que vao funcionar esses tais de trihgrafos??!!\n");
return 0;
}


Infelizmente (ou felizmente, porque, pelamorde Deus, esse negócio é significativamente feio) esse treco tá pra ficar "deprecado" logo e, se já não era conhecido hoje em dia, daqui a uns tempos, se bobear, vai ser até insultado (e os professores de Técnicas de Construção de Programas vão tirar nota quando virem esses trecos no trabalho final, dizendo que isso diminui a legibilidade do código). Importante, porém, é ler esse link aqui:

http://www-949.ibm.com/software/rational/cafe/blogs/cpp-standard/tags/trigraph

Parece que tem lugares no mundo que, sem os trígrafos, vão acabar ficando sem as backslashes. D= D= Certamente isso vai ser uma grande tristeza pra eles...

Bom... eras isso...

Tomara que também tenham gostado dessa minha descoberta encantadora \o/ \o/

R$