Carga de paquetes con la versión de TOL

[Pedro Gea]

El mecanismo de carga de paquetes no tiene en cuenta la versión de TOL. Por ejemplo si ejecuto:

#Require BysMcmc;

con la versión 2.0.1 de TOLBase, se carga el paquete BysMcmc.6.2 cuya _.autodoc.minTolVersion es "v3.1 b025".

[Víctor de Buen Remiro]

Este error fue arreglado hace tiempo en versiones posteriores con la incorporación de nuevas capacidades de TOL que no existían entonces, pero voy a ver si es posible encontrar un parche.

[Víctor de Buen Remiro]

(In [4278]) Fixes #1457

[Víctor de Buen Remiro]

(In [4284]) Refs #1457

[Víctor de Buen Remiro]

He conseguido arreglar el problema en mi máquina, lo malo es que no hay una forma sencilla de compilar el código C++ y generar el instalador de esa versión porque pertenece a una rama obsoleta de TOL y resulta demasiado complicado restaurar todas las dependencias con las que construyó en su día.

Finalmente he visto que el principal cambio era el uso de la nueva función Compare.VersionString la cual he podido reproducir en TOL, aunque sea de forma menos eficiente pero con idénticos resultados, así que la he incluido en la StdLib de la 2.0.1.

Quien quiera mantener la versión 2.0.1 puede parchearla manualmente descargándose el ​StdLib.zip y descomprimiéndolo en el directorio .../TolBase/bin

En todo caso quiero recordar que se trata de una versión obsolescente que hay que ir abandonando cuanto antes porque igual que este problema ha sido posible arreglarlo pueden surgir otros para los que no haya solución.

[Pedro Gea]

La StdLib que se suministra está llena de trazas del tipo:

...
TRACE a=BysMcmc.4.7
TRACE tok.a=[[  "BysMcmc", "4", "7", "0", "0"]]
TRACE b=BysMcmc.4.2
TRACE tok.b=[[  "BysMcmc", "4", "2", "0", "0"]]
TRACE a=BysMcmc.6.2
TRACE tok.a=[[  "BysMcmc", "6", "2", "0", "0"]]
...

No entiendo porqué no se puede crear una nueva versión de la 2.0.1 con ese parche en la stdlib, más allá del deseo de pasar a la versión oficial, ya que se trata de un bug que desarma la compatibilidad de los usuarios que mantengan el uso de la 2.0.1 en algún proyecto e instalen la 3.1 y descarguen los paquetes válidos sólo para la 3.1 y posteriores.

[Víctor de Buen Remiro]

No se puede porque ya no tengo en mi disco los mecanismos de compilación de TOL, contribuciones externas y demás. Me puedo tirar dos días para reconstruir eso y me parece absurdo perder el tiempo de esa forma.

Quizás lo que se puede hacer es no tratar de reconstruir TOL sino tomar el resultado del instalador, modificarlo manualmente como fichero .zip que es inyectandole los ficheros que han cambiado y volver a subirlo con el mismo nombre, pues lo que no puedo es cambiar de núemro de versión ni esas cosas.

Voy a ver si eso es posible.

[Víctor de Buen Remiro]

No encuentro ninguna forma de hacerlo. Si alguien sabe como modificar un NSIS comprimido ejecutable que me diga cómo porque con 7z, rar ni winzip de evaluación lo he podido conseguir.

TOLBase.2.0.1 lo generaba en una máquina vieja con VC8 que ya fenecido hace meses y en mi máquina no lo tengo así que jo tengo ninguna forma de reconstruir el setup.

[Víctor de Buen Remiro]

(In [4308]) Refs #1457

[Víctor de Buen Remiro]

Jorge ha conseguido revivir la máquina dónde él construía versiones binarias de TOL con VC8 y hemos podido subirla

[Pedro Gea]

Con la última versión subida (v2.0.1 b9.01) se corrige el problema y se da por resuleto este tique.

[Pedro Gea]

No sé si tiene que ver con esto o no. Pero a veces ya me desespero un poco con los mecanismos de gestión de paquetes.

Con la versión última de TOLBase 2.0.1 v2.0.1 b.9.01 2012-03-06 18:40:23 i686-win teniendo instalados dos versiones de un paquete con la misma versión mínima de TOL (_.autodoc.minTolVersion="v2.0.1 b.4") concretamente con MMS.0.6049 y MMS.0.6050 si hago #Require MMS; se carga la 49 aunque puedo cargar la 50 si hago #Require MMS.0.6050. ¿Qué está ocurriendo?

[Víctor de Buen Remiro]

Pues a mí me ha cargado perfectamente la MMS.0.6050 con tol 2.0.1
No sé si hay algún problema o no pero lo que resulta complicado es arreglar las cosas hacia atrás y sin haber medio de reproducir el supuesto problema.
Desde la 2.0.1 se ha arreglado y mejorado mucho del sistema de paquetes.
La 2.0.1 es una versión obsolescente y lo que hay que ir haciendo es abandonarla.
En el peor de los casos basta con hacer una lista de requires con las versiones exactas que se necesitan y cargarlas antes de hacer nada cuando se use la 2.0.1.
Se puede meter en un fichero y hacer un include condicional a la versión.

[Víctor de Buen Remiro]

Una posibilidad es cambiar la versión de TolPackage a 2.1 y que así puedan convivir dos sistemas de paquetes en la misma máquina.
Voy a probarlo.

[Víctor de Buen Remiro]

(In [4333]) Refs #1457

[Víctor de Buen Remiro]

(In [4334]) Refs #1457

[Pedro Gea]

Me asigno el tique que ya sé por donde va el problema y la solución y no tiene mucho que ver con los últimos comentarios.

[Pedro Gea]

(In [4339]) Se deshace el cambio [4334]. Refs #1457

[Pedro Gea]

(In [4340]) Se deshace el cambio [4333]. Refs #1457

[Pedro Gea]

El problema que se encontraba con la versión 2.0.1 es por un archivo VersSyncInfo.oza corrupto y el funcionamiento del método TolPackage::Client::LocalLastCompatible que se apoya en esta información:

• En versiones anteriores de 2.0.1 eso no ocurría porque en caso de no encontrarse correspondencia en el archivo el paquete era aceptado en la lista candidata.
• En la versión actual de 2.0.1 se cambió el criterio y si no se encuentra en la lista el paquete (aunque esté instalado) no se acepta.
• En la versión 3.1 el método LocalLastCompatible deja de apoyarse en el archivo VersSyncInfo.oza

Para solucionar la corrupción del archivo basta con hacer:

Real TolPackage::Client::RemoteUpdateVersSyncInfo(False);