Aquests dies (ja en fa uns 10) estic dedicat "full time" al projecte de fi de carrera. I d'aquesta manera fins que l'acabi. S'han acabat totes les bromes ;-)
El faig com m'agrada a mi fer les coses de sistema i de xarxa, en C pelat, vim, make... Això té avantatges i inconvenients. En general resulta divertit. Aprenc coses noves, i millor les que ja conec. Au, vos pas una petita llista de "trucs" i eines (ben documentats i des de fa temps O:-) que m'han alegrat aquests dies:
Definitivament SubVersion s'ha de provar. Dóna mil voltes al CVS. Els avantatges no es poden comptar. El coneixia damunt el paper, pero mantenia tots els meus projectes en CVS per costum. Ricardo, gràcies per recomanar-me el pas a SVN!
Quan programes en llenguatges d'alt nivell, o en C sense baixar gaire, no passa res. Però quan programes a un nivell relativament baix, i te poses a gestionar memòria i punters tu mateix, el C és propens a deixar-te passar errors que provoquen problemes en temps d'execució en general mals de detectar. Ni vos imaginau de quina manera ajuda a destapar errors d'aquest tipus el fet de desenvolupar i provar els programes damunt un parell de plataformes (i guanyes portabilitat entre quasi tots els UNIX si programes una cosa que funciona damunt dos o tres). Jo ara mateix ho faig funcionar tot damunt GNU/Linux sobre PPC i x86, i damunt Darwin sobre PPC. Per tres ó quatre vegades m'he pensat que un programa estava bé i quan l'he provat damunt una arquitectura distinta ha petat miserablement, i ha resultat esser un error genèric que no es manifestava habitualment a altres arquitectures. Per exemple, un malloc d'un byte de menys que feia que el programa escrivís a una posició que se suposava que no havia de tocar. Als PowerPC (per temes d'alineament de paraules) no petava quasi mai, i als x86 petava quasi sempre.
Parlant d'errors d'aquests, he "descubert" una feature bonissima de la glibc actual, que permet activar un mode de depuració de la gestió de memòria: basta donar-li valor a la variable d'entorn MALLOC_CHECK_. Si no val res, comportament per defecte, com sempre. Si val zero, ignora tants d'errors com sigui possible a veure què passa. Si val u, imprimeix un missatge per a cada error. Si val dos, atura el programa (abort) al primer error. Tot això resulta molt útil perquè aquests tipus d'errors sòn molt fotuts. Moltes vegades no els veus quan es produeixen, no saps ni que existeixen. El programa peta després, a un lloc que pareix que no té res a veure, que toca memòria corrompuda per algun altre tros. Però no sempre. Ningú hauria de programar sense aquesta punyetera variable activada durant les proves, per anar trobant i eliminant els bugs des del principi (un que fot moltissim és el d'una cridada a free() que fa un Segmentation Fault, i resulta que la causa és a l'altre punta del programa, que fa qualque desastre amb la memòria que t'havia donat un malloc() -relacionat o no- amb el tamany mal calculat). Si l'activau habitualment, veureu com hi ha molts de programes que feu servir cada dia que estan plens d'errors de gestió de memòria ;-)
Sobre la depuració en general... ja ho sabeu, però gdb rulez. No he vist un depurador millor, mai. Compilau els vostres programes amb -ggdb i disfrutau la depuració ;-)
I sobre el rendiment... he fet una petita llibreria de recorregut recursiu de subdirectoris. Partint de zero. I no m'he aturat fins que he aconseguit un rendiment comparable al de la comanda find. Com he detectat el codi més lent per decidir on havia d'optimitzar primer? Molt fàcil, he compilat amb -pg. Això fa que el programa quan s'executa generi informació de "profiling" dins un fitxer anomenat gmon.out, que es pot interpretar executant "gprof programa gmon.out". Això produeix una sortida amb estadistiques del temps que es passa el programa a cada funció, amb percentatges i tal i qual, tot desglosat d'una manera molt clara.
Més coses, però ja està bé per avui, me'n torn a programar que aquests dies estic a tope i he d'aprofitar ;-)