Aleluya, creo que ya entiendo mejor Git, gracias a la fantástica charla “Getting Git” en RailsConf 2008 de Scott Chacon. En ella explica (y muy bien) los detalles internos de Git, y qué le diferencia de Subversion: cuando me fijé en que podía borrar commits y cosas del estilo, que las revisiones no eran secuenciales sino que usaban hashes SHA1 y que podía cambiar “mágicamente” de rama me quedé tan sorprendido en su momento que no llegué a entender un pimiento del resto :-D, y eso que me miré los dos Google TechTalks de Git.

Ahora que veo que se trata de un sistema basado en una base de datos de objetos agrupados en un grafo, y que los tags, ramas y etiquetas son sólo punteros a nodos raíz de subgrafos suyos lo entiendo mucho mejor. Bueno, supongo que a alguien que no conociera Subversion y fuera directamente a Git no le chocaría, pero no me gusta usar una herramienta sin entender por lo menos la idea general.

Lo siguiente en la lista es git-svn: la verdad, me daría pena dejar la forja de RedIris para el desarrollo de XMLEye. Podría usar el espacio de github.com, pero entonces ya no tengo el área de ficheros, y todo el tema de tickets. Me pregunto si hay algo parecido a Trac para Git, sería el remate. También quiero curiosear sobre la orden cherry-pick de Git.

Todos los días se aprende algo. Hoy he aprendido que tirarme hasta las 5 de la mañana peleándome con camelbox, ActivePerl, y Strawberry Perl para que funcionara PAR::Packer como $DEITY manda ha sido una gran pérdida de tiempo, y que habría sido mucho más productivo simplemente dormir :-D.

Como ya dije en el post de ayer, estuve mirando cómo mejorar la distribución de los conversores, para que el “usuario medio” no tuviera que ser “usuario que sabe instalar un entorno Perl, tirar de CPAN y llevarse un dolor de cabeza con los fallos que le salgan”. En los entornos UNIX está todo muy depurado y PAR::Packer y PAR funcionan de maravilla a la primera, pero en Windows la cosa no está tan clara.

Primero probé con ActivePerl, que con los repositorios PPM de Uwinnipeg y Bribes quedaba bastante completo. Pero por alguna razón, no incluía bien un fichero que instalaba con install_share. Con ActivePerl me pasé varias horas, y luego probé con Strawberry Perl, en sus versiones 5.8 y 5.10 de Perl, y tenía fallos al instalar desde CPAN. Otras tantas horas. Y luego, cómo no, probé con camelbox, y una vez más con Strawberry Perl. Ya me caía de sueño y harto de mirar en listas de correo y bug trackers, me fui a dormir. (Por cierto, el nombre de Strawberry Perl viene por que es una mejora sobre el Vanilla Perl. Un batido fresquito no vendría mal ahora, no señor…)

Hoy me levanto y me acuerdo de un post de ayer que decía algo de que el fallo que yo encontraba “estaba arreglado en trunk”. Trunk, ¿de qué? Pues trunk del SVN de PAR::Packer, que aunque en el $VERSION de Packer.pm decía 0.980, no era el 0.980 de CPAN que me había dado tantos dolores de cabeza. Strawberry Perl 5.10, PAR::Packer del SVN, sin problemas. Todo instalado y funcionando como la seda.

Qué momento más agridulce de mi vida :-D. Bueno, para la próxima me voy a dormir y consulto con la almohada.

Una cosa: al llamar a pp para generar un EXE en Strawberry Perl, no hace falta darle el –gui para evitar que aparezca una ventana de consola. De hecho, si se lo damos nos quedamos sin stdout y stderr :-/. Es buena idea usar ‘-r’ para pruebas, y con la opción ‘-I blib/lib’ nos aseguramos que los ficheros que instala File::ShareDir aparezcan en los PAR. También es buena idea, y no hace daño, añadir “-M PerlIO”: en ActivePerl daba problemas si no se incluía. Dejo esto apuntado por si alguien con mis problemas busca por Google :-D.

Estos días he estado curioseando sobre la forma de facilitar un poco la distribución de los conversores ACL2->XML y YAML->XML. Es cierto que ACL2::Procesador está mucho mejor que antes del Concurso, ya que al cambiar a una estructura basada en los módulos de CPAN, con un instalador creado mediante Module::Install, ahora se instalan todas las dependencias automáticamente al seguir estos pasos:

perl Makefile.PL
sudo make
make test
sudo make install

Esto le resultará muy familiar a cualquiera que haya compilado e instalado un proyecto de las autotools, pero hay un problema: CPAN no es a prueba de bomba, y el “sudo make” instalará no sólo los paquetes necesarios para ejecutar ACL2::Procesador, sino también los que hacen falta para compilar y depurar el módulo. Además, dos de estas dependencias de compilación son módulos XS, con lo que necesitan un compilador C, además de las bibliotecas y cabeceras que utilizan: libxml2 y libexpat. Para un desarrollador tampoco es gran cosa, pero pedir esto a un usuario medio… pues como que no es muy realista.

Con los paquetes Debian se facilita mucho la cosa, claro, pero ¿y si no estamos bajo una distribución basada en Debian, como openSUSE? ¿O si estamos en Windows? Algún usuario potencial en Windows habrá: al fin y al cabo, estoy usando Perl y Java, que por ir tendrían que ir como mínimo en Mac OS X también. No es cosa de cerrarme en banda, tampoco.

No tengo tiempo de hacer paquetes para todo lo habido y por haber, eso está claro. Pero simplificar se puede simplificar. Module::Install tiene dos módulos llamados Module::Install::Bundle y Module::Install::Include que supuestamente permiten incluir en las distribuciones de código las dependencias, pero no me funcionan en absoluto, la verdad.

Donde sí he tenido una grata sorpresa es con los módulos PAR y PAR::Packer. Cualquiera que haya utilizado Java y visto el acrónimo tendrá una idea (JAR = Java ARchive, PAR = Perl ARchive), me imagino. PAR permite crear ficheros .par que agrupan todos los módulos no estándar y bibliotecas necesarias para que nuestro program Perl funcione. Tras instalar PAR y PAR::Packer, ejecutaremos esta orden para crear el .par:

pp -p -o acl2-proc.par script/pprocACL2

Y ejecutarlo sólo requiere el módulo PAR (que es relativamente ligero, y en las Debian se halla disponible como libpar-perl) y Perl:

perl -MPAR acl2-proc.par (fichero Lisp raíz de la demostración)

Más fácil todavía: si no ponemos el -p, se crea no un .par, sino un ejecutable completamente autocontenido, que puede distribuirse sin necesidad de que el usuario instale nada previamente. El único problema es evidentemente el tamaño del ejecutable: pasamos de un .par de 75KB a un fichero de ~2.7MB. Esto es más interesante para la gente de Windows, sobre todo.

Obviamente, los .par son específicos de la plataforma en cuanto usemos un solo módulo que no sea Perl puro. Para ACL2::Procesador no es un problema, pero YAXML::Reverse sí que usa la biblioteca libyaml. Se pueden crear .par multiplataforma, acumulando los resultados de cada plataforma sobre el mismo .par, así:

pp -m -o yaxml.par script/yaml2xml

La verdad es que distribuir un fichero .par y poder olvidarte de CPAN es una alegría, qué más decir. Incluso existe la posibilidad de distribuir un único guión Perl y hacer que se “traiga” e instale el PAR de un repositorio bajo una URL, con el módulo PAR::Repository::Client, pero este módulo es bastante pesado: quizás sea conveniente para redistribuir código entre muchas máquinas que manejemos, pero no tanto para instalarlo en una máquina del usuario.

Mi idea es reunir en varios .tar.bz2 versiones de los conversores que puedan descomprimirse directamente sobre el directorio donde tengamos XMLEye, y que incluyan los .par o ejecutables monolíticos, los descriptores de formato y las hojas de estilo. Así resultará mucho más cómodo que como está ahora.

Tal y como comenté en un post anterior, la semana pasada me hicieron una entrevista en Onda Cádiz, en la que sin duda metí la pata alguna que otra vez :-D. En fin, ya se ha transmitido, y lo he subido tan pronto como he podido. No está entero: tenía un cron con un script para grabar pero me falló =X, y tuve que tirar de la grabadora normal y corriente.

Perdón por la calidad, pero es que ha pasado por cuatro conversiones: TV->HD,HD->DVD, DVD->AVI, AVI->Google Video. No es de extrañar.

Bueno, ya me he montado un DokuWiki en mi propio dominio, sobre el que intentaré ir dejando la suficiente documentación y manuales en inglés y/o español (según el tiempo que tenga) antes de empezar a rondar por listas de correo y tratar de picar el gusanillo de alguien, aunque sólo sea como usuarios.

Me gusta bastante por lo pronto: es muy sencillito pero muy flexible a la vez. Me ha dado algunos quebraderos de cabeza la instalación con el safe_mode de PHP y un bug de DokuWiki (¿alguien sabe para qué es esa función fullpath en PHP? ¿Existe, o sólo está realpath?), pero al final creo que ha quedado bastante bien.

El wiki está aquí: http://wiki.shoyusauce.org, por cierto. Ya lo iré rellenando durante estos días.

En fin, además de esto tengo aún pendiente terminar de traducir el código a inglés y buscarme un sponsor para mis paquetes, que habrá que pasar de Ubuntu a Debian. Hay trabajo de sobra para este verano :-D.

La semana pasada recibí entre el miércoles y el jueves a través de mis profesores y la dirección de la Escuela Superior de Ingeniería llamadas para ir a entrevistas en Canal Sur y Onda Cádiz.

La entrevista a Canal Sur fue la semana pasada (jueves) y fue algo rápido e informal. Quedamos en el CASEM del campus de Puerto Real y fue cosa de 20-30 minutos. Creo que tiene que haber salido ya, pero estoy hasta arriba de exámenes y trabajos y me temo que he acabado perdiéndomelo. Tendré que llamarles :-X.

Por otro lado, hoy tuve la entrevista en Onda Cádiz. Tenía poco tiempo y tuve que atrasarla una semana, ya que perder una mañana para ir a la Zona Franca me habría supuesto un buen disgusto, con tanto trabajito y presentación :-D. Ha sido un placer, la verdad. He tenido cosa de 25-30 minutos para hablar del Concurso, de software libre, de estándares abiertos y (cómo no) de XMLEye. A ver si esta vez me he explicado lo bastante sencillo como para que alguien entienda para qué sirve en pocas palabras y sin muchos tecnicismos.

Seguramente habrá fallos e incorrecciones en más de una cosa: mencioné a los ganadores pero no a los finalistas por falta de tiempo, y me equivoqué al decir que Juan Pedro (autor de Psychosynth) era de la universidad de Sevilla y no de Granada. Espero que no os ofendáis :-X.

Bueno, estaré pendiente a ver si consigo grabar esta entrevista. Saldrá el 6 de junio alrededor de las 21:00 horas. Se puede ver Onda Cádiz por internet a través de esta dirección.

Bueno bueno, acabo de volver de la fase final del Concurso, donde he tenido el gustazo de recibir el Primer Premio en la categoría Educativa. Quitando que el dinero es bienvenido, cómo no :-D, me alegra mucho que se reconozcan los esfuerzos de todos nosotros, que es lo realmente importante.

Me gustaría agradecer a todos los demás finalistas, a los organizadores y a todos los involucrados por dejarme pasar unos dos días fantásticos con mucho frikeo ubuntero, debianero y demás. La visita a los jardines del Real Alcázar se aguó un poco, pero fue muy bonita de todas formas.

Felicidades a todos los demás, que todos somos premiados. Empezando por Psychosynth, que dan ganas de tontear con él sólo de verlo :-D, y que no me extraña que sea el premiado en absoluto. Y siguiendo con el robotito R4P (espero que resolváis el problema con los horns de los servos, y poned fotos de la versión negra), Minirok (Dato, eres de GNOME en el fondo, lo sé ;-)), Pigmeo (sigo pensando que aunque no es prioritario, se debería poner la creación de un simulador en un documento por si alguien se siente dispuesto a echar el rato), y Zenphp (se nota de dónde viene el nombre al hablar con el autor).

Un recuerdo también a las menciones, en particular Pleim, de mi misma universidad, que por desgracia no se pudo pasar, y a los de Pro Evolution Chapping, con un juego peligrosamente adictivo. Pero por favor, entrenad un poco más y no os metáis tantos goles en propia puerta :-D.

¡Suerte a todos en vuestros proyectos a partir de ahora!

Bueno, este post llega casi con una semana de retraso, pero de todas formas allá va.

El viernes pasado, tal y como comentó mi compañero David (autor de Pleim) en su blog, fue la entrega de premios de dicha fase final. Expusimos, en este mismo orden:

• Felipe, con FichaPráctica, un software para la gestión de fichas didácticas para asignaturas de primaria/educación especial/párvulos y de escuelas de idiomas. No llegó a poder implementar código, pero creo que ya tuvo bastante con la recogida de requisitos y aprender las herramientas. Fue interesante su discusión acerca de las limitaciones que existen a la hora de crear interfaces ricas en un entorno Web, y de cómo ésto le hacía pensar en elaborar un editor para sus contenidos.
• Servidor con XMLEye. En fin, no dije nada que no hubiera dicho ya, aunque habría invitado algunas preguntas. Los vídeos dieron algunos problemas, pero nada que mplayer no pudiera arreglar. Nada en absoluto supera a ese reproductor, excepto quizá en su interfaz (¿pero quién necesita interfaz? :-D)
• David, con Pleim. Por cierto, gracias por la felicitación, David, y mucho ánimo con tu proyecto, que podría ser muy útil para más de uno de nosotros. Estaría muy bien que su clasificador se integrara con cosas como el buscador Tracker de GNOME (¿o han cambiado recientemente a otro?), o con servidores web como Apache.
• Mi compañero de carrera Alejandro, con su forja de software. A ver si alguien explota de verdad su potencial y le saca todos los bugs :-D. No es fácil depurar una aplicación tan grande por sí mismo, y menos cuando tienes que ir rodeando problemas y problemas de integración entre muchas herramientas que no estaban pensadas para ello. De todas formas, su forja ya se está usando bastante, con más de 40 proyectos registrados (que para una forja tan joven, y de una sola universidad, no está nada mal en mi opinión).

Tras una discusión con otro compañero que deseaba desarrollar software libre y posiblemente participar en el próximo CUSL (¡ánimo!), en el que hablamos, entre otras cosas, del típico dilema de si coger GPL/LGPL/BSD para su software, llegó el Rector y se realizó la entrega de premios, en la que tuve el honor de recibir el Primer Premio. Pero bueno, esto es sólo cosa del momento: mis compañeros han invertido también mucho tiempo en esto y han conseguido muy buenos resultados para el poco tiempo que la universidad y la vida en general nos deja :-).

Además, queda mucho por hacer aún. A ver si se relajan las cosas otra vez un poco y le puedo echar más tiempo otra vez a XMLEye.

(Por cierto, el Windows Vista que traía el portátil fue bonito… hasta que se terminó de bajar la ISO de la Release Candidate de Ubuntu Hardy. Me da hasta casi pena, tuvo una vida tan corta… :-D)

Bueno, ayer grabé algunos paseos en forma de vídeo (no son técnicamente screencasts, al no tener sonido) para la exposición de este viernes en el CUSL2-UCA. Usé gtk-recordMyDesktop. Quería usar una imagen de VirtualBox que preparé con un disco inmutable (de tal forma que al reiniciar la máquina virtual volviera a un Ubuntu Gutsy limpio), pero mi ordenador no da para tanto :-D, así que simplemente creé un nuevo usuario llamado screencast y listo.

Primero daré un paseo por la web de la forja, mostrando los ficheros y documentación disponibles:

Aquí detallo el proceso de instalación, que es tan fácil como añadir un nuevo repositorio con su clave GPG e instalar algunos paquetes:

Luego veremos cómo se pueden ver demostraciones ACL2 y editarlas en paralelo con el visor. También haremos alguna que otra búsqueda sencilla:

A continuación muestro cómo también se pueden abrir ficheros YAML 1.0 sin problemas con la versión empaquetada de YAXML::Reverse (la versión ahora en SVN tiene YAML 1.1 y JSON, abriendo los ficheros de marcadores de Firefox 3, por ejemplo pero tengo que reempaquetarla), abriendo un descriptor de módulo Perl y el ejemplo de la factura de la web de YAXML. También puede abrir volcados de la base de datos de Django, ya que se trata de YAML 1.0 igualmente. Tiene soporte para las anclas y vínculos de YAML si se usan las hojas yaxml de preprocesado y visualización.

Por último, muestro cómo lanzar xmleye directamente desde la interfaz abriendo algunos ficheros y que está también disponible en inglés (emulo el cambio de local cambiando el valor de LC_ALL):

Esta semana y media he dedicado un par de ratos a mejorar y revisar los materiales que usé en un taller reciente sobre elaboración de paquetes Debian. Aquí están todos los talleres que hicimos entre algunos alumnos y profesores en la ESI de Cádiz:

http://www.uca.es/softwarelibre/talleres/index_html

Ya he enviado la última versión al responsable, que la pondrá dentro de un par de días. Fue un taller con bastantes imprevistos, pero ya está todo a prueba de bala… bueno, de flecha, tampoco tengo tanta confianza :-D.

Con lo que hay ahí creo que daría para 2 sesiones de 1:30 a toda pastilla o 2 horas más cómodamente, una con la elaboración básica y otra con cómo hacerte tu propio repositorio para facilitar la distribución. Está probado sobre Gutsy y Hardy, ya que en Hardy sudo tiene una nueva opción (-E) que me dió algunos quebraderos de cabeza.

Están las fuentes de la presentación (LaTeX usando Beamer, bajo la GPL), código fuente para los paquetes y demás, la configuración necesaria para Lighttpd y un guión que instala las dependencias básicas, instalando paquetes, ficheros de configuración, y preparando un fichero de entrada para generar claves GPG en modo batch.

Se acepta cualquier comentario y crítica constructiva :-).

Ah, y de paso: he sacado una nueva versión del paquete Debian de ACL2::Procesador en mi repositorio, que no incluía build-essential entre sus dependencias. Cuando ACL2 certifica un libro externo, de hecho compila un programa C, cosa de la que no me acordaba. Los empaquetadores de ACL2 sin embargo no lo habían incluido entre sus dependencias. En fin, ya está arreglado.

A ver si preparo algunos screencasts de la aplicación y los pongo por aquí, que me falta contenido multimedia :-D.