Programación seria en el mac

Como sabéis, el mac trae las herramientas básicas de programación incluídas en el OS X. Destacan los compiladores GCC y Xcode pero no son menos prácticas las herramientas de depuración y análisis de aplicaciones: gdb, shark, etc.

Pues he encontrado una página de complementos y mejoras de estas aplicaciones para programar cálculo numérico serio. Pasaos por el proyecto en sourceforge y os sorprenderéis. Tienen en binario un montón de herramientas recién salidas del horno. Yo ya me he bajado el GCC 4.4, que tiene autovectorización y soporte para C++0X (entre otras cosas) y estoy echando el ojo al resto de librerías. Un gran hallazgo.

Por cierto, aquí hay info sobre el lanzamiento de GCC 4.4 y aquí sobre el estado de la implementación del nuevo estándar de C++.

No voy a hablar del lanzamiento de Ubuntu 9.10...

Al menos hasta que lo pruebe (descargado está).

Librerías dinámicas de VTK en OS X

Acostumbrado como estoy al sencillo sistema de librerías compartidas en GNU/Linux, no acabo de entender varios mecanismos que se usan en OS X. Uno es el caso de las librerías dinámicas, las famosas ".dylib".

En teoría el concepto es el mismo que el de las ".so", pero hay cosas que me desesperan. Cuando compilo una aplicación que usa las librerías VTK, al estar instaladas en /usr/local/lib, el maldito sistema no las encuentra. Como llevo tiempo haciendo apaños, os cuento hasta dónde he llegado y si alguien tiene la solución definitiva, por favor que me la cuente antes de que empiece a linkar estáticamente (!!).Por cierto, es indiferente usar cmake que qmake, con automake no he probado pero después de acostumbrarme a los otros dos como que cada vez me da más pereza.

Problema: si compilamos el programa e intentamos lanzarlo desde una terminal, nos escupe diciendo que no puede encontar las librerías libvtk* y sus respectivos símbolos. Si analizamos los links del ejecutable con:

otool -L ejecutable

Obtenemos una bonita lista donde podemos comprobar que las librerías VTK no tienen su correspondiente path.

Después de leer detenidamente un montón de documentación vía web de la que no guardo los links, me entero que a partir de Leopard hay una opción para usar -rpath (runpaths) tanto de forma global como relativa. Bien, recompilo VTK con el RPATH activado (esto tarda un rato)... y no funciona. Genial, es como cuando he intentado compilar en x86_64 y no puedo porque carbon sólo es 32 bits y cocoa me da error con QT 4.5 (!). Si es que sobre el papel todo es muy bonito, pero luego... en fin, vamos a los apaños.

Solución/apaño #1: añadir en .bash_profile una línea para que la carpeta de las librerías VTK esté en el path de búsqueda. Después de un rato de amena lectura, consigo enterarme que en el mac es:

export DYLD_LIBRARY_PATH=$DYLD_LIBRARY_PATH:/usr/local/lib/vtk-5.2/

Bien, hecho esto, primera victoria: los ejecutables corren desde la bash. Después de pensar (ingenuo de mí) que estaba todo solucionado, cuando voy a debuggear (toma palabro!) desde Xcode... la misma historia!

Solución-apaño #2: después de trastear un buen rato con la ingente cantidad de opciones de compilación en Xcode, resulta que no es ahí (bravo!). Hay que añadir la variable de entorno en el ejecutable, como os pongo en esta captura:

Bueno, ahora funcionar funciona. Pero miedo me da lanzar shark o alguna otra aplicación de análisis. El caso es que hace tiempo no tuve este problema así que no sé si es un bug de VTK 5.2 o es que soy cada vez más torpe.

¿Alguna idea?

Libros libres... de software libre

He encontrado a través de esta página una buena recopilación de libros listos para descargar tanto de GNU/Linux en general como de programas libres como GIMP, Inkscape, OpenOffice, etc.

Os dejo una muestra:

Manuales Informática

Cuadernos de Tecnología

Buscar y sustituir palabras en muchos archivos

Después de empezar a usar find para borrar los archivos, me estoy aficionando a usarlo y he encontrado una utilidad que quiero compartir. Además, la sintaxis es delicada y puede que tenga que echar mano de esto que escribo para recordarla.

El problema que tenía es: dados unos archivos que se llamen parecido... pongamos "grid.vtk"; queremos sustituír una o varias palabras en todos ellos, en mi caso "scalars" por "power_density". Estoy seguro que hay un montón de aplicaciones "de ventanas con botones" que lo pueden hacer, pero también estoy seguro de que se tarda más usándolas. Así que repetid conmigo: La bash es nuestra amiga, la bash es nuestra amiga...

Al grano, abrimos una bash, nos situamos en el directorio del que cuelgan todos los subdirectorios que contienen los archivos que queremos modificar y lanzamos:

find -iname grid.vtk -exec sed -i 's/scalars/Power_density/g' {} \;

Ahora la explicación:

-iname es el nombre de los archivos que queremos cambiar. Acepta comodines. En este caso son todos aquellos que se llamen grid.vtk.
-exec le dice a find que ejecute este comando en cada uno de los archivos:
sed -i 's/scalars/Power_density/g' {} \;
donde:
-i le dice a sed que edite el archivo
s es la opción de sustitución, en este caso busca scalars y lo sustituye por Power_density
g es la opción para que lo haga para todas las coincidencias en el archivo
{} el la ruta al archivo que ha encontrado find, y
\; es el final del comando find, que tendrá algún sentido pero lo desconozco, lo uso como una receta.

Como veréis, la sintaxis de sed se parece mucho a vim, así que aprendemos 2x1.

Comparación Ubuntu Intrepid - Leopard

He encontrado en Phoronix una curiosa comparativa entre los dos sistemas operativos que vengo usando en el portátil ahora mismo (aunque también uso el openSuse, pero en los fijos). Para ello han usado un mac mini de la anterior generación, con gráfica intel integrada; vamos, que no han buscado un hardware muy rebuscado.

Los resultados son como poco desconcertantes. En la parte gráfica, incluídos juegos sobre OpenGL, Leopard arrasa. La explicación parece ser la arquitectura MESA de linux sobre los drivers de Intel y parece que están trabajando en ellooooo (que diría el bigotes ;-).

En multimedia, las cosas se igualan. Las codificaciones tanto de MP3 como de OGG son un poco más rápidas en ubuntu 64 bits pero más lentas en ubuntu 32, quedando el OS X en medio. Sí que el mac es más lento cuando se codifica vídeo con FFmpeg.

Al comprimir archivos, ubuntu es mucho mejor usando gzip, quedando en tablas cuando se usa 7-zip.

En operaciones de lectura-escritura en disco, Leopard con su HFS+ simplemente apabulla al EXT3. Será interesante ver la ganancia de Linux con EXT4, siempre que los desarrolladores consigan programar sin que se produzcan pérdidas de datos por la nueva escritura retardada que proporciona(!). Voy a ser malo... qué raro que se haya descubierto el problema en Kubuntu, con KDE4... jejeje.

De Java paso de hablar. Total, para lo que vale...

La gestión de bases de datos con SQLite es muuuucho más rápida en mac. Si se mira la gestión XML, se iguala con el ubuntu 32 bits, quedando el ubuntu 64 como ganador en este aspecto.

Conclusión: un cacao. Yo lo resumiría como: ubuntu, usando todo el arsenal open source, gana en innovación (64 bits y últimas versiones de compiladores y aplicaciones). Mientras, OS X se lleva la palma en integración: drivers más eficientes, equipos más equilibrados, etc. Sólo me contradice el caso del sistema de archivos, ¡pero es que HFS es muy bueno!

Lo que creo que faltaría para que la comparativa fuera más justa y completa: que hubieran usado la última versión de Xcode, que trae el gcc-4.2; y, por parte de ubuntu, incluír un benchmark del EXT4.

Borrar archivos recursivamente

Supongo que a alguno le ha pasado que, moviendo datos entre distintos sistemas, acabas con una buena colección de archivos específicos del sistema donde no deberían estar.

Más en concreto, al sincronizar datos entre sistemas OSX y GNU/Linux con rsync, si se nos olvida utilizar la salvaguarda --exclude=.DS_Store, arrastramos uno de estos archivos por carpeta, lo que resulta cuanto menos molesto. También pasa algo parecido si hemos usado windows con los archivos Desktop.ini y otros del estilo *.ext.

Usando la bash se pueden borrar todos de un plumazo. Primero nos situamos en el directorio superior y buscamos a ver si tenemos archivos de ese tipo. Por ejemplo, para la morralla que deja el mac, haríamos en nuestro linux:

find -iname .DS_Store

Si nos sale una ristra de direcciones, podemos comprobar que no corresponden a ninguna partición montada de HFS+. En caso de que "casualmente" lo esté, cuidado, desmontadla primero. Una vez asegurados que queremos borrar todos los archivos de la lista, le decimos al comando que los elimine mediante:

find -iname .DS_Store -exec rm {} \;

Si alguno es de sólo lectura, nos pedirá confirmación de borrado.