¿Todos para uno o uno para todo?

Ya expliqué hace poco que PSeInt está compuesto por varios programas separados, la mayoría de ellos independientes. El usuario percibe al conjunto de programas como si fuera uno, con varias partes trabajando en conjunto. wxPSeInt es el programa que se encarga de ser la interfaz con el usuario, y de gestionar la ejecución de los otros de forma más o menos transparente. Veamos ahora porqué esto es así y qué tiene de interesante o no, según mi experiencia con este modelo.

Empezando por el porqué, tengo que decir que es más bien una cuestión histórica. Primero que nada, lo que quería escribir cuando empecé con PSeInt era solo un intérprete (el módulo pseint), el editor de texto surgió inmediatamente como agregado necesario para poder mostrar las bondades del intérprete, pero los demás módulos no estaban previstos. Desde ese punto de vista, tendría solo dos módulos, un editor de texto y un intérprete de consola. La comunicación sería mínima: el editor guardaría el pseudocódigo en algún temporal y lanzaría el intérprete diciéndole por argumento en la linea de comandos donde estaba ese temporal. Si había errores, el camino de vuelta también sería mediante un archivo temporal. Esto sonaba razonable, y este era más o menos el modelo que seguían la mayoría de los IDEs en lenguajes reales, así que jamás se me cruzó por la cabeza plantear otra alternativa. Mucho tiempo después se fueron agregando algunos módulos nuevos que tampoco requerían de mayor comunicación, como el visualizador (no editor) de diagramas de flujo, o el que exporta a código C++. Por eso seguí con el mismo esquema. Tal vez la primer duda respecto a si este era el camino a seguir vino cuando quise integrar la ejecución paso a paso, y también más tarde para el análisis sintáctico en tiempo real.

Destripando PSeInt

PSeInt es un programa compuesto por muchos programas. Es decir, consta en realidad de varios ejecutables que se invocan y comunican entre ellos, de forma tal que para el usuario final se ven como partes de un único entorno. En este artículo voy a comentar cuales son esas partes (desde ahora módulos, cada uno un ejecutable), y cómo y cuando se comunican. La idea es que sirva de referencia para el siguiente artículo donde discutiré porqué es así, porqué las cosas están separadas o juntas, porqué se comunican de esa manera, y qué tiene esto de bueno o de malo según mi experiencia y las necesidades particulares de este proyecto. De paso, también sirve de documentación para mí y para los que quieran mirar el código fuente.

Primero voy a hacer una descripción rápida de qué hace cada módulo, y luego cómo se relacionan. En este análisis dejo de lado intencionalmente a psdraw, ya que sus funcionalidades serán absorbidas por psdraw2 (algunas ya lo fueron, y las que no, lo serán en las próximas versiones).  Los módulos que componen entonces al sistema de PSeInt son:

Codificar y ejecutar, ¿serie o paralelo?

Se viene algo grande en PSeInt. Por suerte 2012 ha sido un año de muchos muchos avances, y parece que 2013 también va empezar con novedades. Había advertido que no iba a hacer nada nuevo por un buen tiempo, pero me topé con un concepto demasiado bueno como para andar esperando tanto. Navegando sin rumbo llegué a un post de un tal Bret Victor, un tipo que parece tener ideas más que interesantes sobre cómo deberían ser los entornos de programación (entre otras cosas) y cómo la gente debería aprender a programar. Gracias a ese artículo dí con este video. Si miran el video (que dura más de una hora, pero yo solo vi los primeros 20 minutos cuando me decidí a empezar todos estos cambios), van a entender de qué se trata. No estoy 100% de acuerdo en todo lo que propone, pero sí en su gran mayoría, al menos pensando a nivel didáctico que es lo que me ocupa en PSeInt. Y hay momentos de la charla realmente fantásticos, de esos que le abren a uno la cabeza y lo hacen ver las herramientas que tenía desde un punto de vista completamente nuevo.

El tipo plantea un entorno de desarrollo donde los pasos para programar no son primero codificar, luego ejecutar para ver que sale, y repetir; sino que propone codificar y ver qué sale en simultáneo. Es decir, a medida que el programador va codificando el programa, este se va ejecutando, y si a mitad de una ejecución cambia algo del código fuente, la ventana de ejecución refleja inmediatamente esos cambios. El video muestra otras cosas interesantes, pero esa idea tan simple y complicada a la vez fue la que más me impactó. Aquí les presento mi video, de solo 2 minutos, con algunas de estas ideas llevadas a PSeInt:

Trucos para depurar con ZinjaI

Este artículo bien podría llamarse "Tips para convertirse en un ZinjaI Master (parte 5)", pero preferí ponerle un título diferente donde aparezca la palabra "Depuración" ya que trata de este tema en particular, y los tips son algo más específicos. En la pestaña Depuración del cuadro de Preferencias (al cual se accede con el ítem "Preferencias..." del menú "Archivo"), los tres últimos ítems son bastante particulares, pero bien utilizados ayudan mucho.

El primero, "Mejorar inspecciones automáticamente según tipo", hace que cuando ingresemos (durante la depuración) una inspección de algún tipo configurado allí (se configuran con el botón "Opciones" que tiene al lado), ZinjaI la modifique automáticamente. Por ejemplo, cuando trabajamos con la clase std::string, usualmente queremos inspeccionar el contenido de la cadena, y no la estructura de la clase. En gcc, por ejemplo, esta clase tiene el contenido del string en un puntero llamado _M_p que está dentro de un struct miembro llamado _M_dataplus; y la clase tiene además otras cosas que en general no nos interesa ver, como el npos. En resúmen, si el string es s, no interesa evaluar solamente el valor de "s._M_dataplus._M_p" en lugar de "s". Sin esta opción, hay que buscar dentro de la clase el atributo que queremos, lo cual se hace fácilmente con un par de dobles clicks sobre el valor de la inspección y borrando luego las inspecciones que sobren, pero se torna tedioso y repetitivo. Con esta opción, ZinjaI puede hacerlo automáticamente.

Tips para convertirse en un ZinjaI Master (parte 4)

En la última (eso creo) entrega de esta serie, voy a hablar un poco de la personalización de ZinjaI. Es decir, de cosas que podemos configurar desde las preferencias o desde las opciones de proyectos, generalmente para mayor comodidad. No voy a cubrir todo lo que se puede configurar en ZinjaI, sino sólo lo que me parece destacable en el contexto de esta serie de posts.

Para empezar, hay una opción en la pestaña "General" del cuadro de Preferencias (al que se accede con el ítem "Preferencias..." del menú "Archivo") que dice "Ocultar paneles automáticamente". Cuando digo paneles me refiero a esas subventanas que aparecen en los bordes de la ventana principal, como el arbol de archivos, los resultados de la compilación, la ayuda rápida, el árbol de símbolos, etc. Por defecto, estos paneles aparecen cuando alguna acción en ZinjaI los necesita (por ejemplo, el de compilación al compilar) y se quedan ahí ocupando buen espacio hasta que los cerremos. Y si el monitor no es tan grande, ese espacio es importante, así que molestan. Algunos desaparecen con la tecla Escape, otros no. Pero si los cerramos, a algunos después hay que ir a buscarlos al menú cuando se necesitan otra vez, o aprender algún otro atajo de teclado (y creo que ya tienen bastante por ahora). Entonces no es tan cómodo.

Tips para convertirse en un ZinjaI Master (parte 3)

Después de darles algunos tips para moverse fácilmente por el código, y para realizar algunas operaciones de edición básicas en un periquete, en esta tercera parte voy a comentarles sobre algunas otras funcionalidades afines que han quedado fuera de las dos primeras para no hacerlas tan largas, o porque no son tan triviales.

Por un lado están los autocódigos. Ya hablé de ellos en otro post, así que no voy a volver a explayarme. Si no saben lo que son, escriban "fori(N)" (reemplazando N por lo que quieran) y presionen la tecla Tab justo después de cerrar el paréntesis. Tengo que decir que agregarlos me llevó bastante tiempo porque no me ponía de acuerdo conmigo mismo acerca de cuál sería la forma menos intrusiva de invocarlos (problema cuya solución inspiró NetBeans si mal no recuerdo a través de un comentario de un usuario). Pero una vez implementados, resultaron mucho más útiles de lo que imaginaba, y ahora no vivo sin ellos. Pueden seguir el link que puse antes para ver cuales hay configurados por defecto y cómo definir nuevos con lo que ustedes quieran o necesiten.

Tips para convertirse en un ZinjaI Master (parte 2)

Ya les revelé en el post anterior "secretos" varios para deslizarse de un punto a otro de su proyecto con apenas un puñado de teclas. Digo "secretos" entre comillas porque estos atajos no son secretos para nada. Están a la vista en los menúes y la mayoría comentados en la ayuda. Pero por alguna misteriosa razón, el 99% de los usuarios no los ve, entonces, cuando uso algunos de estos atajos en público no falta quien me pregunte cómo hice eso tan rápido. ¿Después de al menos un cuatrimestre de programar con ZinjaI, jamás le pegaron una mirada al menú Editar para ver que había?. Supongo que la respuesta es no, yo tampoco lo haría al principio. Soy de los que empiezan a usar y ya, sin manuales; pero cuando me decido a adoptar finalmente una herramienta para un trabajo prolongado me tomo un ratito para jugar con su interfaz y ver qué cosas pueden ser útiles que no conozca. En fin, en esta segunda entrega, quiero comentar atajos de teclados para pequeñas tareas de edición, bastante triviales, pero que hacemos millones de veces mientras programamos.

Tips para convertirse en un ZinjaI Master (parte 1)

No hay IDE en el mundo con el que pueda desarrollar programas en C++ más rápido que con ZinjaI. Y esto se debe a una razón simple y clara: yo lo hice, ergo, yo conozco todas sus mañas y sus trucos. Y que quede claro otra vez: el hecho de que yo sea mucho mucho más rápido con ZinjaI que con algún otro IDE nada tiene que ver con que ZinjaI sea o no sea superior a ese otro IDE. Entonces, dejando para otro día la discusión de si es el mejor o el peor, y suponiendo que si alguien se toma la molestia de leer esto es porque ya ha decidido darle una oportunidad, voy a tratar de compartir en esta serie de posts muchos de esos trucos y explicar muchas de esas mañas que decía antes, para que el lector usuario de ZinjaI pueda aspirar a ser el programador más rápido del oeste.

Para empezar, es fundamental poder moverse cómodamente por el código. Y en ZinjaI hay muchas formas de ir y venir por el mismo. Están las formas convencionales de todo editor de texto: Ctrl+F para buscar, Ctrl+G para ir a un número de linea en particular, F3 y Shift+F3 para repetir la última búsqueda hacia atrás o hacia adelante, y Ctrl+Alt+F para mover el foco del teclado al cuadro de búsqueda rápida que aparece en la barra herramientas. Pero hay algunos atajos específicos que pueden resultar muy muy útiles.

Sobre medios y objetivos

¿Qué guía el desarrollo de un proyecto de software libre? Esta es para mí una pregunta muy interesante, donde hay muchas respuestas válidas. Con ella apunto a analizar cómo se decide hacia dónde debe ir el futuro de un proyecto, cuáles son sus objetivos a corto, mediano y largo plazo, en qué aspectos del proyecto se deben centrar los mayores esfuerzos, o cómo descubrir los puntos fuertes y débiles del mismo, entre otras cosas. En general se distinguen muy fácilmente los casos extremos. Por un lado, proyectos respaldados por grandes organizaciones que toman decisiones en grupo, luego de discusiones (que pueden ser formales y protocolares, o simples encuentros en una sala de chat o mediante envío de mails informales en listas dedicadas). Estos proyectos suelen tener una buena estructura jerárquica, objetivos claros en varios frentes a largo plazo bien documentados, a veces intereses políticos, etc. Por otro lado están los proyectos pequeños, que empiezan una o unas pocas personas, y que básicamente suelen seguir los caprichos de esas pocas personas, o guiarse por sus necesidades e intereses particulares. En el medio de todo esto, está la gran mayoría de los proyectos, y hay tantas y tan diversas variantes que no se me ocurre ni cómo agruparlas.

Compilar la versión del repositorio en Windows

En el artículo anterior expliqué los pasos para instalar todo lo necesario y compilar la versión de ZinjaI o PSeInt de los repositorios git en GNU/Linux. En este voy a comentar cómo hacerlo en un sistema Windows. Ya saben que vamos a necesitar el compilador, unas cuantas bibliotecas, git, y algo de paciencia.

Lo primero que vamos a instalar entonces son las herramientas para compilar: compilador y bibliotecas. Se puede intentar instalar todo (MinGW y wxWidgets mínimamente) por separado, pero requiere de muchos pasos. La forma más sencilla es hacer una instalación completa de cualquier versión no tan vieja de ZinjaI, ya que el instalador de ZinjaI incluye casi todo lo necesario. Entonces, vayan al sitio de ZinjaI, a la sección "Descargas", click en "Descargar el instalador para Windows", y luego de esperar unos segundos ejecuten el instalador. En el asistente de instalación de ZinjaI deben tener la precaución de seleccionar todos los componentes en la tercera página (a esto me refería con "completa", "wxWidgets" y "OpenGL" serán necesarios y no están seleccionados por defecto).

Compilar la versión del repositorio en GNU/Linux

Para los inquietos e impacientes que quieren probar lo último de lo último, para los curiosos y corajudos que quieren ver y meter mano en los oscuros rincones del código fuente, para los que están en trabados por un bug que necesitan resuelto para ayer, para los que están aburridos, y para cualquiera que quiera colaborar o simplemente meter la nariz tras bambalinas; para todos ellos están los repositorios git. git es el sistema de control de versiones que utilizo en mis proyectos. Estos repositorios contienen el código fuente tal cual está ahora en mi PC, siempre actualizado con los últimos cambios y retoques, mucho antes de que estos aparezcan bonitamente empaquetados en una nueva versión oficial en la sección descargas. Yo lo utilizo como si fuese centralizado (aunque uno de los puntos fuertes de git es su gestión distribuida), y la versión que hay en los servidores de sourceforge es la que considero máster. Cada cambio que hago en mi PC va a parar casi inmediatamente allí.

Pero muchos usuarios no han usado nunca un software de control de versiones, o no están familiarizados con el proceso de compilación mediante makefiles y la configuración del entorno. Por ello, voy a explicar desde cero en un par de posts como preparar todo y compilar ZinjaI o PSeInt (los pasos son los mismos) desde los fuentes de estos repositorios, tanto en GNU/Linux (en este artículo) como en Microsoft Windows (en el próximo). Así, cuando comente en el blog que tengo alguna funcionalidad nueva en desarrollo, ya saben donde tienen que ir a buscarla si no quieren esperar, o si quieren ayudarme a testearla.

SourceForge, cada día mejor

Desde que comencé a publicar mis proyectos de software libre utilizo SourceForge. Allá por el 2004 cuando decidí "colgar" PSeInt en algún lugar de la web, la gente de la lista de mails de gleducar me sugirió SourceForge, y dado que yo no conocía casi nada al respecto, acepté la sugerencia. Desde entonces y hasta el día de hoy, mis proyectos se han alojado exclusivamente allí, y después de varios años de utilizar sus servicios puedo sacar algunas conclusiones.

Para empezar, tuvo sus puntos flojos en algunas ocasiones. Hace un tiempo solía tener problemas con algunos mirrors que en combinación con ciertos navegadores me dejaban a veces las descargas incompletas. En otros momentos el acceso al sitio era bastante lento. Las interfaces para realizar algunas tareas solían ser tediosas. Pero todo eso fue cambiando, a veces de a poco, a veces de golpe, y mantener mi confianza en este servicio cuando aparecieron alternativas muy prometedoras y populares (como pueden ser google code o github), está pagando con creces.

Parseo y mayusculización en PSeInt

Estoy casi seguro de que esa palabra (mayusculización) no existe, pero viene bien para hablar de algo que pasa en PSeInt cuando le pedimos que haga algo con un algoritmo que no sea simplemente guardarlo. Por ejemplo, si le pedimos que genere el diagrama de flujo, ya sea para verlo o editarlo, todos los identificadores pasan a estar en mayúsculas. Si le pedimos que exporte a código C++ ocurre algo similar, pero en este caso con minúsculas. Si le pedimos que lo ejecute y el intérprete encuentra errores, los identificadores que pone para aclarar entre paréntesis en los mensajes de error están siempre en mayúsculas. Y así ocurre con algunas otras situaciones menos frecuentes.

La justificación es bastante simple: para simplificar el "parseo" del pseucódigo, todo se pasa a mayúsculas. "To parse" significa analizar, o procesar, y el "parser" es una parte fundamental de cualquier intérprete/compilador. Sin embargo, es muy frecuente no dejarle al parser toodo el trabajo, sino hacer antes un preprocesamiento del código para simplificar algunas tareas posteriores (que no son difíciles en realidad, solo tediosas o poco eficientes de otra forma). En muchos casos, parte de este preproceso está en el parser mismo, ya que lo realiza internamente.

La estrella del show

En este mini-show que componen mis proyectos personales, unos posts en un blog que pareciera tener alguna fijación con los insectos, y otros delirios afines, donde ustedes, lectores y usuarios, son los preciados espectadores que busco cautivar, PSeInt se roba todos los flashes. Mientras que a mis últimos 7 posts les llevó unos 10 días llegar a la (para nada envidiable) cantidad de 50 visitas a cada uno, la nueva versión de PSeInt tuvo más 200 descargas en sus primeras 10 horas de vida y eso que esas 10 horas fueron entre las 10 de la noche y las 8 de la mañana, lo que implica que la mayoría de los usuarios estaba cenando, durmiendo, mirando tele, o haciendo cualquier otra cosa, pero no creo que trabajando o estudiando tanto (aunque pensandolo bien yo suelo hacer mis tareas de mantenimiento, lo que incluye actualizaciones, durante la noche). Para el final de su primer día, había llegado a nada menos que 900 descargas.

Nuevo miniproyecto: wxTimeLineEditor

Hace un tiempo agregué en la página de PSeInt, en la parte de documentación, una "linea de tiempo" que resume los hitos más importantes para ese proyecto. Me pareció útil para ver rápidamente cómo evolucionó el proyecto en estos casi 9 años, porque creo que la historia de PSeInt tiene varios matices interesantes, dado que nació con pocas expectativas, y tiempo después el hecho publicarlo como software libre me generó unas cuantas gratas sorpresas, y con él fui aprendiendo muchas cosas. En fin, la linea de tiempo no era realmente un gráfico de una linea de tiempo, sino una simple tabla de fechas y acontecimientos porque en aquel momento no encontré un software que me permita generar el gráfico como yo quería. Lo que buscaba era algo sencillo, offline, y que permita exportar la imagen. Probé unos cuantos, algunos muy malos, otros innecesariamente complicados, otros solo para Windows, y algunos muy buenos pero que no se ajustaban a lo que yo quería, o que me daban errores varios al utilizarlos. Finalmente decidí programar algo yo, ya que tomando la experiencia que ya conté del graficador de diagramas de flujo, iba a ser trabajo de una tarde/noche o a lo sumo un fin de semana, al menos para las muy pocas funcionalidades que realmente necesitaba, "los extras vendrán después" pensé. A la noche tenía mi preciado grafiquito. Así es el poder que da aprender a programar, si no encuentro lo que quiero, tengo siempre la alternativa de hacerlo (o intentar, tampoco hago magia :). En fin, la noticia es que ahora registré el proyecto en SourceForge y si les sirve para algo ya pueden empezar a descargarlo.