Exprimiendo mejor al Diagrama de Flujo

Con la verificación de sintaxis en tiempo real, una mejor sincronización con la ayuda rápida, las plantillas de estructuras de control de la derecha, y la lista de funciones y operadores de la izquierda, el autocompletado y los tooltips, el indentado inteligente, y algunos otros detalles, creo que la interfaz para escribir un algoritmo en pseudocódigo en PSeInt está bastante bien encaminada y completa. La que no está taaan completa es la de edición de diagramas de flujo, ya que hasta hace poco, si bien se podía editar el diagrama y mandar a ejecutar directamente desde ese editor, tenía varias falencias. Por ejemplo, si había errores de sintaxis, había que volver al pseudocódigo para ver cuales eran y dónde estaban, o si se quería hacer un seguimiento paso a paso también. Estas cosas están cambiando, y en este post les cuento las novedades (a nivel usuario) que ya están listas en el repositorio, y también los cambios de diseño interno (a nivel desarrollador) que tengo que analizar antes de seguir en esta linea.

Cuando agregué el diagrama de flujo, era solo un agregado para ver, para generar a partir del pseudocódigo, pero no estaba pensado para trabajar directamente allí. Después vino la edición, y ahí sí pasó a ser más interesante la idea de trabajar con el diagrama de flujo como base y generando el pseudocódigo como resultado, en lugar de ser al revés. Trabajar en el diagrama tiene sus ventajas y desventajas. La primer ventaja es que reduce la posibilidad de errores. En el diagrama no hay errores relacionados a la forma de las estructuras de control. Es decir, uno no puede comerse un FinSi, o anidar mal en el diagrama, pero sí puede ingresar expresiones incorrectas en un "Escribir", poner mal los índices, o generar errores de tipos y cosas no definidas o no declaradas por ejemplo. Otra ventaja es que reduce al mínimo la sintaxis que hay que recordar (solo lo relacionado a expresiones), y hace que armar el algoritmo sea más intuitivo. La desventaja, es que si uno se acostumbra demasiado a esto va a tener más problemas a la hora de pasar a un lenguaje real. En el pseudocódigo, si bien la sintaxis no es tan compleja, la forma de trabajar se parece más a la de un lenguaje real. Dicho esto, quisiera que ambas formas de trabajo estén completas por sí mismas y que el usuario elija cual utilizar en cada momento, o en el mejor de los casos combinar ambas.

Empezando por los cambios en la nueva versión, están las dos mejoras que mencionaba arriba. Por un lado, si el algoritmo contiene errores, se verán en la ventana del diagrama sin necesidad de volver al pseudocódigo. Por ejemplo, si en una expresión de un "Escribir" no cerramos las comillas de una cadena de texto, en la esquina superior izquierda del paralelogramo que representa al "Escribir" aparecerá un marca en rojo con una cruz indicando que allí hay algún error. Al pasar el mouse sobre el escribir en la parte inferior izquierda de la pantalla se verá la versión corta del mensaje de error (en este caso, el "falta cerrar comillas"). Todavía no está hecho, pero es probable que más adelante haciendo click en el icono del error nos lleve a la descripción larga en el editor de pseudocódigo. El único problema de esto es que no se hace "en tiempo real" como en el pseudocódigo, debido a que la verificación en realidad la hace el editor de pseudocódigo, y el camino de ida y vuelta entre ambos editores no está tan aceitado como para usarlo cada 2 segundos (involucra escribir y leer archivos temporales). Entonces, estos errores se marcan solo al intentar ejecutar el algoritmo.

El segundo cambio es más interesante, pero está un poco más en pañales todavía, y se trata de la ejecución paso a paso. Ahora se puede lanzar el paso a paso desde el diagrama y ver en el mismo qué entidades se van ejecutando. En cada momento, la entidad ejecutada se remarca con lineas un poco más gruesas y una flechita verde a su izquierda similar a la que aparece en el margen del pseudocódigo (para que sea más intuitiva la asociación). Hay detalles por revisar, como por ejemplo que hay lineas de pseudocódigo que son un punto en el diagrama y no una entidad, y por eso no se marcan en el diagrama. Tomemos un FinSi, en un programa real, el FinSi no es algo que se ejecute, pero en el paso a paso de PSeInt lo marco para que quede claro cuando se sale de la estructura Si-Entonces. Otro detalle no del todo pulido es el de las llamadas a subprocesos. Por ahora solo se ven las marcas en el proceso que se está visualizando, que puede no ser el que se está ejecutando. Además, al ser esencialmente visual, en el diagrama el seguimiento puede ser más intuitivo (por ejemplo, animando el avance de la flecha para marcar los caminos seleccionados. Pero igual lo que hay ya es un buen punto de partida para empezar a probar.

Finalmente, hablando de cuestiones de implementación, por ahora tengo tres problemas: que el editor de diagramas es un ejecutable separado del editor de pseudocódigo, que (como consecuencia de los primero) los mecanismos de comunicación entre ambos incluyen archivos temporales, y las bibliotecas que utilizo. Ambos editores están separados no solo por razones históricas, sino también por seguridad. Siendo el editor de diagramas más nuevo e inestable, es mejor separarlo para que los problemas no recaigan sobre el otro editor y se pierda bastante trabajo. Los mecanismos de comunicación son híbridos entre sockets y archivos, porque usé sockets para las cosas chiquitas y rápidas y archivos para las cosas más grandes y menos frecuentes. El problema, es que algunas de esas cosas ahora estaría bien que sean frecuente (para actualizar los errores en tiempo real por ejemplo). Finalmente, la biblioteca que usé para el manejo de la ventana y los eventos del editor es freeglut, que es mucho más simple y liviana que wxWidgets, pero también mucho más limitada. Entre sus limitaciones, por ejemplo, no me toma las teclas muertas en su versión para Windows (los acentos por ejemplo, por eso un á se debe ingresar en Windos con Alt+A), o no me deja marcar la ventana como "siempre visible/arriba", cosa que me vendría muy bien para la ejecución paso a paso. Los controles del paso a paso están en la ventana principal, y si esta ventana se superpone con el diagrama, al no estar el diagrama "siempre arriba" cada vez que damos siguiente lo dejamos de ver. Por ahora, la solución fue reacomodar las ventanas para que no se superpongan (mitad pantalla para cada una), pero eso también tiene sus detalles.

Portar la interfaz de freeglut a wx no sería difícil, pero haría un poquito más pesado el ejecutable, y un poco más molesta la compilación (wx por defecto no se compila con el componente para OpenGL, porque tiene más dependencias, y encima el configure de la última versión estable no las detecta correctamente en los Ubuntus). Pero una vez portada tendría más control sobre varias cosas y podría unificar mejor la interfaz (usar menúes convencionales, o barra de herramientas por ejemplo). Además, de ahí a meterlo dentro del otro editor y que dejen de ser cosas separadas hay mucho menos distancias, solucionando finalmente los problemas de comunicación. De todas formas, todavía no me decido a hacer tanto cambio, ni me convenzo de que se justifique. Hay cuestiones de organización de la interfaz y del "workflow" del estudiante que me gustaría analizar antes. Por el momento, vayamos probando estos primeros cambios a ver qué recepción tienen y cuanto interés despierta en los usuarios para que siga ese camino.