Sobre los problemas de PSeInt en Mac OS

Desde hace meses venía recibiendo reportes de usuarios de PSeInt en Mac advirtiendo que una vez iniciado el editor, no se abrían ni la ventana de ejecución, ni el editor de diagramas de flujo (o sea que era completamente inútil). Y era un problema que no podía reproducir yo mismo, así que me era muy difícil de analizar, mucho más de corregir. Finalmente la semana pude hacerlo, encontré una solución que publiqué hace unos pocos días. Pero esto destapó viejos problemas en mi modelo de desarrollo para Mac OS; problemas que ya conocía y sabía que eran un bomba de tiempo.

En primer lugar, no tengo ninguna Mac real. Pruebo las versiones para Mac a través de Virtual Box; pero la verdad es que dependo en gran medida de los usuarios para detectar y reportar muchos de los problemas. Obviamente no soy usuario de Mac, pero da la casualidad de que tampoco lo son ninguno de mis familiares, ni colegas o más amigos cercanos, así que a veces me es muy difícil analizar, o siquiera ver un error.

Para estos casos, PSeInt tiene un sistema interno de log que puedo activar para que vaya registrando qué hace, los errores internos, información sobre el sistema y la configuración, etc. Entonces si yo no reproduzco el error, pero el usuario sí, tal vez enviándome su log me dé una buena pista de lo que sucede.

 

En la sección de "Reporte de errores" de la ayuda está el link para generar el log.

Pero en este caso el log no servía para nada. Lo primero que hace el log es pedirle a todos los módulos que informen su versión, para lo cual el editor debe ejecutarlos silenciosamente. Veía en el log que los módulos que aparentemente no estaban funcionando sí se ejecutaban correctamente a la hora de informar sus versiones. Eso quiere decir que esos módulos al menos podían arrancar... Pero luego, cuando el usuario hacía click en "ejecutar" o en "editar diagrama de flujo", el log decía que los módulos ni siquiera arrancaban. Es decir, no era que arrancaban y se detenían o daban algún tipo de error; sino que ni arrancaba, como si no existieran o les fallase alguna dependencia.

Y para completar la confusión, si de casualidad lograba acceso a una Mac con el problema (digamos que se acerca un alumno a consulta con una Mac y lo molesto para probar algo de esto), al intentar desde una consola ejecutar un módulo exactamente de la misma forma en que lo hace el editor (la linea de comandos completa y exacta queda registrada en el log) funcionaba sin problemas! Es decir, el módulo estaba bien, el comando era correcto, el contexto también, pero por alguna razón al editor no le funcionaba.

En este caso, luego de varios reportes de error por mail y por el foro, pude notar que el problema surgía con una actualización de Mac OS, y no de PSeInt. Parece ser que algo cambió en alguna actualización de High Sierra (10.13.x, yo tenía 10.10 y 10.12 en las VMs), y dejó de andar desde allí en adelante. Finalmente conseguí acceso a un Mojave (10.14) para testear.

Y luego de googlear un buen rato, me encontré con un usuario sugiriendo un bug en wxWidgets, y comentando que uno de sus dos modos de ejecución funcionaba, y el otro no: en wxWidgets se puede usar el método Open de la clase wxProcess, o la función libre wxExecute. Yo uso la función para todo, pero pudiendo ahora probar los cambios, y leyendo en los fuentes de wx las diferencias entre ambas formas, descubrí que la verdadera diferencia era activar o no la redirección de entrada/salida del proceso hijo. Era por esto, que cuando los módulos se comunicaban con el editor mediante cin/cout funcionaban bien (porque el padre redireccionaba estas entradas y salidas a un par de streams de wx para poder controlarlas); pero cuando se comunicaban por sockets (o que directamente no necesitaban comunicarse) ya no. El workaround simple fue forzar la redirección en todos, aunque no sea necesaria.

Pero en realidad esta no es la verdadera causa del problema. No puedo culpar a un bug de wx si estoy usando una versión increíblemente desactualizada de la biblioteca (2.8.12). Seguramente este y otros problemas ya estén resueltos. Peeero, mi verdadero problema es el toolchain que tengo para generar los binarios para Mac. Está basado en IMCROSS, lo armé hace ya varios años, y nunca fue actualizado (si siguen el link verán que la info es muy vieja). Una versión actual de wx no compila con ese toolchain. Y esto es lo que hace que mi código no pueda modernizarse a C++11, y también siga atado a wx2.

Ahora encontré algunos potenciales reemplazos (como este proyecto), y en cuanto pueda trataré de actualizar mis herramientas para dejar de renegar con estas cosas. Es algo que sé que debería haber hecho hace mucho tiempo; pero las dificultades para testear todo esto hacen que el proceso sea un poco más problemático de lo necesario, y la falta de tiempo hace que priorice otras cosas antes que esta migración. Sin embargo ahora creo que está realmente cerca, van terminando de encajar las piezas que faltaban. Espero en breve pasar a C++11 y wx3, al menos en PSeInt.