Robots y modelos

Notas sobre pruebas, modelado y aventuras en Java y Android

Posts Tagged ‘par

Usando PAR::Packer y Strawberry Perl en Windows

with 2 comments

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.

Written by bluezio

24 de junio de 2008 at 11:05

Publicado en Desarrollo

Tagged with , , ,

Mejorando la distribución de los guiones Perl

leave a comment »

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.

Written by bluezio

22 de junio de 2008 at 10:38

Publicado en Desarrollo

Tagged with , , , , , , ,