This topic contains 28 respuestas, has 5 voices, and was last updated by Anónimo Hace 12 años, 1 mes.
-
Entradas
-
-
-
Reproduzco el error con intef6.2. sobre ubuntu 10
En todo caso regenero el archivo de cero y parece que me funciona. Adjunto versión nueva. Comprueba que te funciona.
La pregunta es ¿Lo has generado desde cero con intef 6.2 o viene el archivo de versiones anteriores?
Saludos
-
-
Me ha pasado lo mismo utilizando la versión 6.1, he actualizado a la 6.2 y el error persiste.
Se trata de archivos generados con versiones anteriores. Intento agregrarlos en un nuevo elp (generado con la versión 6.2) y al importar me da el error “Formato de archivo incorrecto). El archivo a importar abre sin problemas.
¿Cuándo habláis de regenerar desde cero, a qué os referís?
Gracias y un saludo.
-
Copia y pega de los contenidos de ese nodo en concreto
-
El problema de hacerlo así es que: a. se trata de un tema completo (con estructura, distintos idevices …), b. sólo puedo tener una instancia de eXe abierta, lo cual complica el proceso.
En resumen, es un trabajazo.
Gracias por la idea. Estoy muy interesado en cualquier avance sobre este tema. Si queréis que pruebe alguna cosa …
Saludos.
-
Hola Vicente:
Si quieres compartir el elp lo miramos a ver si se detecta el problema
Por otro lado, en intef6.2 PUEDES tener dos instancias de exe abiertas!!!!!! Proceso:
1. Abres exe
2. pulsas ctrl t (para abrir pestaña)
3. Te colocas en la nueva pestaña que se te ha abierto en exe. Aparecerá vacía. Observa que ha aparecido a la izquierda un desplegable de firefox
4 En el desplegable aparece history, selecciona un enlace
5. Tienes dos pestañas operativas de exe
En la siguiente versión se simplificará totalmente el proceso 😉
-
Ok. Te adjunto un elp. La prueba que he realizado: creo un elp nuevo con la versión 6.2 e intento insertar el paquete que te envío. Resultado: formato de archivo incorrecto.
Ahora pruebo lo de las pestañas, creo que va a resultar muy útil.
-
Este te funcionará correctamente.
En todo caso lo declaro como bug
-
Lo he probado y la importación sigue dando error.
Gracias por tu ayuda.
-
Hola,
En introduccion.elp y bingyahoo.elp he visto que está el mismo patrón para que falle la inserción del paquete: ambos tienen nodos zombies.
¿Podríais adjuntar los elp’s origen (de donde se han extraido) e indicar a partir de que nodo los habéis extraido?
Un saludo.
-
Hola,
Respecto al paquete que ha subido Antonio (introduccion1.elp) falla porque debe estar generado con un eXe de la rama jsui (incluye un objeto de metadatos LomES que no está en trunk y versiones oficiales).
Antonio, ¿qué has hecho concretamente para eliminar los nodos zombies en introduccion1.elp y bingyahoo_v01.elp?
Un saludo.
-
Hola Pedro:
En efecto introducción1.elp está hecho con jsui
El anterior bingyahoov01.elp lo hice haciendo un copia y pega de código html desde el origunal y generando un archivo completamente nuevo por lo que no deber´ia estar corrupto como dices.
En ambos casos el procedimiento ha sido el mismo, abro dos pestañas y copio y pego. En el archivo nuevo lo guardo cambiando nombre.
-
Sólo comentaros que el fichero modificado por Antonio también me da error, y que ahora estoy problando con la 6.2.
-
Respecto al tema de los nodos zombies, quitarlos resuelve el problema? es posible identificarlos y eliminarlos? (teniendo en cuenta que, hasta donde sé, en este caso el xml representaría un contenido distinto de content.data).
-
Disculpad, pero no me han llegado por correo vuestras respuestas. Menos mal que me ha dado por pasarme por el foro.
El problema de los nodos zombies es que no se deben generar. O sea una vez generados implica editar a mano el content.xml, que no es sencillo. Necesito identificar como se ha generado el elp que contiene nodos zombies (los etiqueta así el propio eXe por algún motivo). Para ello necesito el elp origen y detalles de cómo se ha realizado la extracción que ha generado el elp con nodos zombies. Entre los detalles: versión con la que se ha realizado la extracción, nodo a partir del que se extrae y sistema operativo.
Un saludo.
-
-
Hola,
He estado analizando el elp Busquedasv5 y compruebo que el original ya contiene nodos zombies (2 concretamente). Por lo tanto al extraer el nodo problemático (“Bing y Yahoo!” que contiene apuntadores a los 2 nodos zombies), éste no se podrá insertar ya que dará el error que comentáis.
Necesitaría replicar cómo se han generado dichos nodos zombies y así atajar la fuente del problema. Aporto más información a ver si Raúl se acuerda de cómo se pudo originar:
-Al principio del nodo “Bing y Yahoo” está el primer idevice de Texto libre que empieza por “Existe el mundo más allá de Google”. Cada idevice contiene un campo interno que a su vez contiene un apuntador al nodo padre. En este caso debería ser “none”, pero en lugar de eso apunta a un nodo que ya no existe llamado “Otros buscadores audiovisuales” (el primer nodo zombie).
-El otro idevice problemático es el que lleva por título “Búsqueda de imagenes y vídeos en Bing y Yahoo!”, que está al final del nodo. Dicho idevice contiene un campo interno que a su vez contiene un apuntador al nodo zombie llamado “Altavista”, cuando debería ser “none”.
Eliminando los idevices problemáticos, la extracción/inserción funcionan correctamente. Sin embargo deberíamos intentar replicar el proceso que ha generado esta situación. Raúl, ¿te refresca la memoria la información que te he aportado?.
Mientras seguiré haciendo pruebas. Entiendo que los tiros pueden venir al haber movido idevices y eliminado nodos (ya es algo para empezar a probar).
Un saludo.
-
Hola,
Por si no podemos dar con la fuente del problema (cómo se generan esos apuntadores a nodos zombies), he hecho un commit para limpiar esos apuntadores a nodos zombies cuando se encuentren.
En mis pruebas he podido insertar correctamente las 2 muestras problemáticas después de abrir y guardar los elp’s.
Dicho cambio irá en la próxima versión (intef6.3).
Un saludo.
-
-
Tenemos un problema parecido en un archivo y me gustaría limpiar los nodos zombies. Si monto un entorno de pruebas de la rama trunk, ¿ya está incluida la limpieza o tengo que esperar?
¡Un saludo!
-
Bueno, ya he puesto en marcha el entorno de pruebas del trunck pero persiste el problema. Aver si consigo explicarlo bien:
Queremos insertar el archivo VP03_Contenidos.elp dentro del archivo TFM02_Contenidos.elp y da error de formato de archivo.
Si abrimos el archivo VP03_Contenidos.elp, el .log nos habla de la existencia de muchos nodos zombie. Supongo que serías páginas que no se borraron bien en su día. Con la versión del trunk, he comprobado que se han eliminado los nodos zombies y he podido insertar ese archivo dentro de un archivo vacío.
Sin embargo, con el archivo TFM02_Contenidos.elp, no he podido solucionar el problema. Al abrirlo, no aparece ningún warning , pero si intento insertarlo dentro de un archivo nuevo, en el log se dan unos warning sobre archivos.
Es posible que en estos archivos se den dos problemas: problemas de nodos zombies y problemas en la manera que se guardan los archivos. Agradecería mucho una segunda opinión:
Más pistas:
- Como trabajamos dentro del proyecto TodoFP, utilizamos una versión de la herramienta “ad-hoc” en la que estamos intentando mantener un difícil equilibrio: cumplir con las especificaciones del proyecto y hacer uso de las mejoras de la herramienta (algunas de las cuales hemos financiado nosotros).
- Ahora que se van cumpliendo los objetivos marcados en la hoja de ruta (¡ENHORABUENA!), hay un tema que convendría afrontar en profundidad: la gestión de archivos. Ante problemas heredados de versiones anteriores, se ha aplicado una solución de contingencia: borrar todos los archivos no referenciados en el catálogo de archivos. Esta solución evita que el archivo .elp crezca innecesariamente, pero tiene efectos colaterales indeseados para los que tenemos que manejar un volumen grande de archivos y necesitamos disponer de mecanismo de mantenimiento de archivos ágiles. Por ejemplo: a la hora de traducir un elp, tenemos que traducir archivos utilizados por es elp (pdf-s, imágenes, etc) y necesitamos hacerlo de manera ágil.
- En nuestra versión “particular” hemos eliminado la limpieza de archivos porque nos impide hacer estas acciones. En otros archivos generados en el proyecto TodoFP, también se han introducido archivos directamente en el .elp, ya que en un proyecto de maquetación complejo, puede ser necesario hacerlo. Es decir, la solución de contingencia afecta a bastantes archivos .elp previos, ya que el catálogo se basa en el MD5 del archivo (creo) y estas acciones de actualización externa de archivos hacen que eXe no lo encuentre por MD5 y por lo tanto lo elimina.
- En un mensaje aparte, haré una propuesta de futuro de cara a una gestión de archivos que permita a un usuario “normal” trabajar con la sencillez actual pero también permita hacer un desarrollo y mantenimiento de archivos ágil. Esto último es indispensable en proyectos como TodoFP, donde el número de elps publicados a día de hoy puede ser más de 5.000
-
Hola José Miguel,
Efectivamente en el fichero VP03_Contenidos.elp hay un problema de nodos zombies. Abriendo y guardándo con la versión que tenemos en trunk actualmente, se hace limpieza de dichos nodos y efectivamente ya se puede insertar en otros elp’s.
En el otro fichero, TFM02_Contenidos.elp, no hay problema de nodos zombies. Sin embargo si que, como indicas, hay un problema de indexado de recursos. Concretamente en el elp está indexado un recurso (TFM02_CONT_Medicion_tiempo_Desc.1.html) que físicamente no está. Eso no impide abrir el elp normalmente, pero sí que hace saltar el error al insertar en otro elp. En la consola de error de eclipse puede verse lo siguiente al tratar de insertar el elp:
File “/home/pedro/Desarrollo/workspace/juno/python/iteexe-trunk/exe/engine/path.py”, line 925, in copyfile
return shutil.copyfile(toUnicode(self), toUnicode(dst))
File “/usr/lib/python2.7/shutil.py”, line 82, in copyfile
with open(src, ‘rb’) as fsrc:
<type ‘exceptions.IOError’>: [Errno 2] No such file or directory: u’/tmp/tmpA6tC3F/TFM02_CONT_Medicion_tiempo_Desc.1.html‘
Está tratando de copiar un fichero que no existe físicamente en el elp, de ahí el error “No such file or directory”. Creo que habría que abrir un bug para solucionar esta excepción no controlada y que al menos siga adelante. Otra cosa es la fuente del problema: la gestión de archivos.
Ahora mismo, con la versión actual, no veo proceso automático para limpiar esos recursos que realmente no existen para éste caso concreto. He probado a forzar una limpieza de recursos zombies, pero los recursos siguen en los metadatos. Tan solo quedaría editar a mano el content.xml. Otra opción es aprovechar la corrección del bug para meter código que elimine el recurso de los metadatos cuando se dé la excepción mencionada.
Respecto a la gestión de archivos se me ocurren varias ideas. Una nueva pestaña al mismo nivel de la de autoría, en la que se vería un árbol de todos los recursos indexados. Ya que habría que mostrarlos, y eso implicaría explorar tanto los metadatos como lo que realmente hay en el elp, se podría verificar si ambos índices concuerdan y mostrar visualmente al usuario las incosistencias. Éstas serían de 2 tipos: un recurso indexado en los metadatos que no está físicamente, o un recurso que está físicamente pero no está indexado en los metadatos. A parte se podrían realizar acciones, comó añadir físicamente un archivo, añadirlo a los metadatos, eliminar, etc, etc. Con la nueva interfaz javascript seria bastante sencillo de implementar a nivel interfaz de usuario. Aunque estas ideas mejor sería trasladarlas a otro hilo.
Un saludo.
-
Muchas gracias Pedro.
Intentaré eliminar ese nodo del xml manualmente y también probaré la solución del chapucerillo: meter a mano un archivo con el nombre TFM02_CONT_Medicion_tiempo_Desc.1.html. Ya os contaré a ver que tal.
Las ideas que planteas sobre gestión de archivos me parecen muy interesantes. Es un tema que merece plantear con calma y que ya iremos debatiendo en otro foro.
¡Un saludo!
-
Bien:
Es bueno ver que la solución de los nodos parece que funciona.
Respecto a la gestión de archivos, si puedes Jose Miguel, abres un feature request para que quede documentado y vemos la forma de afrontarlo.
Tenemos una buena velocidad de crucero 😉
Saludos
-
Bueno, con las pista de Pedro, ya he averiguado la fuente del problema. Parece que la persona que hizo el material hizo una primera versión pero tuvo que hacer cambios en casi todos los nombres de archivos, en algunos casos debido a una incorrecta aplicación de la nomenclatura de nuestro proyecto, en otro caso por el sufijo .1 que le ponía eXeLearning a los archivos modificados. No sé qué metodo habrá utilizado, pero, aunque el HTML estaba correctamente actualizado y los archivos también, el catálogo de archivos seguía manteniendo los nombre antiguos.
Probablemente habrá utilizado la exportación XLIFF. Este formato es ideal para traducir contenidos o para hacer mantenimiento en el HTML (buscar y sustituir), pero no se debe utilizar para cambios que impliquen cambios en los nombres de los archivos, ya que esos nombres también se guardan en el catálogo de archivos.
Ha sido necesario repasar el contenido de dicho catálogo para hacer coincidir el nombre del campo _storageName con el nuevo nombre del archivo. Ha sido como hacer un puzzle (unos 400 archivos), pero por lo menos, se demuestra que un formato xml legible permite hacer frente a problemas complejos.
Conclusiones:
1) Si necesitáis hacer cambios masivos en los nombres de archivos, aseguraos de hacerlo modiciando el archivo contentv2.xml.
2) Con calma, hay que pensar en un mecanismo de gestión de archivos que facilite la labor en proyectos de maquetación de contenidos donde se maneje un número alto de archivos. Esto, para la feature request 🙂
Finalmente, una duda: ¿es posible sacar desde Eclipse un listado tipo tabla de los archivos guardados en el objeto exe.engine.resource?
Y sobre todo, ¡muchas gracias por la ayuda! 🙂
-
Hola:
Por desgracia he cantado victoria demasiado pronto. Nos están apareciendo más archivos problemáticos a la hora de importar. Por ejemplo, el archivo adjunto es el resultado de haber borrado páginas de una archivo más extenso, como paso previo a importarlo en otro archivo. Se ha efectuado la acción “Guardar como”. Sin embargo, si hacemos esto:
- Crear un archivo nuevo
- Insertamos este archivo sobre el nuevo
- Nos aparece un mensaje”Formato de archivo erroneo”
- Si hago esa operación desde Eclipse, veo este mensaje en la consola: “Exception: Paquete antiguo. Actualícelo por favor (Archivo..Abrir seguido de Archivo..Guardar como) antes de intentar insertarlo en otro paquete”
¿Cuál puede ser el problema de este archivo?
-
Parece que el proceso de fusión de paquetes es un test ideal para detectar incoherencias en la estructura interna del archivo, ya que afloran problemas que no afectan a otras operaciones (abrir, editar, exportar,…).
He probado en el entorno de desarrollo la versión INTEF6.3. que limpia nodos zombies y ha solucionado los problemas de algunos de los archivos en los que tenemos problemas, pero no todos. He abierto un feature request para tratar este tema en detalle. Asimismo, se proponen algunas propuestas de futuro en la gestión de archivos, de modo que sea más sencillo el desarrollo y mantenimiento de contenidos:
https://forja.cenatic.es/tracker/index.php?func=detail&aid=1504&group_id=197&atid=886
Consideramos que es importante la participación del equipo de TodoFP en este tema, ya que actualmente, algunos de los archivos desarrollados en dicho proyecto dan problemas con las últims de eXe y es importante garantizar el mantenimiento de los contenidos.
You must be logged in to reply to this topic.