Foro - Perl en Español

En principio, sí.

Yo ya no uso Windows desde hace muchos años, y no puedo darte muchas pistas, pero antes de intentar compilar algo, en Windows, intentaría bajar el módulo por otros medios (por ejemplo, con el PPM de ActivePerl).

Hola, explorer. A ver si lo he entendido bien. Yo antes tenía ActivePerl instalado. Lo he desinstalado para probar con CamelBox y ahora me falta el módulo Win32::GUI::DIBitmap. Lo que tengo que hacer es volver a instalar ActivePerl, manteniendo Camelbox, e instalar este módulo desde PPM. Una vez instalado el módulo a la hora de compilarlo con Perl2exe, con la opción -I le especifico la ruta donde se encuentra el módulo en ActivePerl, ¿no? ¿ O debería poner un "use lib ''" y la dirección donde buscar el módulo junto con use Win32::GUI::DIBilmap?

Opción 1: Con la opción -I indicar la ruta del módulo.

Opción 2: en el script poner "use lib 'C:...';"
"use Win32::GUI::DIBilmap;"

En la documentación de CamelBox viene como hacer convivir CamelBox con otras distribuciones.

Quizás debas ponerte en contacto con ellos...

En cuanto a perl2exe, creo que había varias maneras de indicar la ruta a los módulos que, por sí mismo, no es capaz de encontrar. La opción del 'use lib' está bien porque es justo lo que el programa necesita para encontrar el módulo, y por ende, perl2exe.

Cuestión de probar...

Hola, explorer.

El programa se compila y funciona correctamente. Solamente tengo un problema, para mi algo raro, la verdad.

Resulta que lo único que no funciona del programa es el script de actualizar. Cuando ejecuto el script Update (solo este script, no el programa entero) funciona correctamente. El problema ocurre cuando lo ejecuto desde la interfaz. De hecho, no carga la interfaz porque me dice lo que aparece en la imagen.

¿Por qué ahora no funciona el programa cuando lo ejecuto entero (desde la línea de comandos MSDOS) y sí funciona el script que falla cuando lo ejecuto de forma individual?

Por lo que puedo ver, hay un problema con DateTime::Locale, indicando que DateTime::Locale::Catalog no ha devuelto un valor correcto.

Quizás la diferencia sea de ejecutarlo en MS-DOS a ejecutarlo en Windows... quizás las locales sean distintas. O quizás algún módulo esté en una versión vieja... no lo sé...

Yo usaría el depurador, para ver el porqué DateTime::Locale falla.

Creo que me explique mal. Me refería que los dos casos son bajo MS-DOS. Lo que pasa que en uno ejecuto el programa entero con la interfaz y todo y el otro ejecuto solo el programa que genera los rss. Cuando ejecuto solo el de generar rss los genera bien pero cuando lo hago desde el programa completo, falla. He ejecutado con el depurador y me da el siguiente error:

perl -d prueba.pl

Bueno, es la salida normal del depurador, cuando lo arrancas.

Lo curioso son las dos advertencias que salen:

• cwd dice que puede confundirse con una posible futura palabra reservada. Cámbiala por cwd().
  
• En la línea 1358, dice que se está redefiniendo la subrutina ventanaAC_Resize(). O sea, que está definida dos veces.

Pero no creo que ninguno de estos problemas tenga que ver con el problema del locale.

Lo que habría que hacer es averiguar por qué. Yo hablé del depurador, porque iría paso a paso, hasta justo antes de que saliese el mensaje de error, para seguir la pista de lo que va haciendo. Requiere un poco de paciencia, pero a veces no queda otro remedio, para saber si se nos ha pasado algo. O por si no es culpa nuestra, sino de algún módulo en que confiábamos.

Otra forma de resolverlo, sería podando nuestro programa (quitando/comentando cosas) hasta llegar a un mínimo de líneas en que el error se sigue reproduciendo. Y a partir de ahí, ver por qué esas líneas no se comportan como debieran.

Hola, explorer.

Creo, bueno estoy casi seguro, que he encontrado el problema.

He probado a crear la interfaz desde la cual llamar al programa que genera los rss y funciona correctamente. Esa interfaz solo contiene un botón generar. Con lo cual deduzco que el problema viene cuando yo quiero utilizar los módulos de ActivePerl.

Todo funciona bien cuando creo el .exe del programa entero, excluyendo del programa el script update. Con lo cual, al poner use lib 'C:/Perl/site/lib/'; para acceder a los módulos Win32/GUI de ActivePerl el programa debe confundirse y buscar los módulos de los RSS en ActivePerl. Yo creo que si se pudiera añadir solamente esos dos módulos (Win32::GUI::DIBitmap y Win32::GUI::Grid) el programa funcionaría correctamente. El problema es que no sé cómo hacerlo.

¿Alguna idea, por favor?

Iba a decirte que probaras con

no lib 'C:/Perl/lib/RSS/';

pero me temo que no funcionaría. Hay que indicar a 'no lib' una ruta idéntica a la que se almacena dentro de @INC, y me temo que solo estará metida 'C:/Perl/lib/'.

La solución drástica y rápida es la de eliminar o renombrar los directorios lib/RSS/ dentro de los de ActivePerl.

Otra opción, pero que tampoco he probado... Al inicio del programa, vaciar completamente @INC, e ir añadiendo (con 'use lib') aquellas rutas de las que estamos seguros que contienen los módulos que nos interesan. El problema con esta solución es que los módulos dependen unos de otros. Deberíamos estar seguros de que no se nos olvida ninguna ruta.

Si haces un perl -V te saca las rutas por defecto que están en @INC.

Hola, explorer.

Ya he quitado de ActivePerl los módulos de RSS. Lo que no sé es por qué tarda tanto tiempo en crear un .exe usando PAR. Cuando lo creo sin Update.pm no tarda más que unos minutos pero si lo hago con Update.pm tarda más de media hora, incluso puede que más por eso todavía no he podido probar un .exe completo. He probado a crearlo con perl2exe y lo genera pero al ejecutarlo me da error con el DIBitmap.dll. El caso es que sí que está esa librería en ActivePerl. Los únicos programas .exe que he podido generar y probar han sido con "pp -o setup.exe setup.pl".

Editado: Acabo de crear el .exe con PAR y al ejecutarlo me dice que no encuetra Class/Singleton.pm y sí que está en C:/camelbox/site/lib/Class/Singleton.pm . ¿Por qué no lo encuentra si está en el @INC?