Lecciones de un proyecto no proyectado

Hoy se cumplen 10 años desde que PSeInt fue presentado por primera vez en "público". El 29/12/2003 rendí el final de "Programación I", evaluación que incluía mostrar y defender un programa desarrollado por el alumno con lo aprendido en la materia. No tengo ningún registro exacto de cuándo empecé a codificarlo así que tomo esa presentación formal como fecha de nacimiento. Ni se imaginan lo horrible y lleno de bugs que estaba el código, pero como yo no era consiente de ello, se lo vendí a los docentes como si fuera maravilloso, corriendo sin problemas los ejemplos con los que ya lo había probado. Y como en el poco tiempo que dura el examen no se puede ahondar en tantos detalles, los muchos errores escondidos no saltaron a la vista y me fui con una muy buena nota.

Más allá de eso, jamás imaginé que PSeInt seguiría vivo al día de hoy, y mucho menos que iba a cambiar y evolucionar en la forma en que lo hizo. Siempre le vi patas cortas a este proyecto, y eso me privó de explotarlo un poco más, de hacerlo crecer antes, y de utilizarlo para otras cosas, algo que hoy en algún sentido lamento no haber hecho. De eso vengo a contarles en este post. La historia de un proyecto muy querido pero a la vez subvalorado por su desarrollador. Sobre las veces que dejé pasar oportunidades por falta de imaginación, y cómo el tiempo me demostró que siempre se puede hacer algo más. Espero que este post ayude a salvar algún que otro proyecto con potencial de algún lector, que haya quedado escondido en un cajón por su falta de visión a largo plazo.

¿Dónde va la gente cuando viene?

Blogger, la plataforma sobre la cual funciona este blog, me ofrece ciertas estadísticas básicas del tráfico del blog. Una de las listas que me ofrece es la de los posts más leídos, diaramente, semanalmente, mensualmente, o en total. Y resulta que el post de este blog más leído de todos los tiempos es uno de los que menos me interesaba. Ni imaginaba que fuera a llamar tanto la atención. Y por otro lado, otros posts que a mí me parecieron mucho más entretenidos o útiles, recibieron relativamente pocas visitas. Les sugiero, si son más o menos seguidores del blog, que traten de recordar cuales posts les llamaron más la atención, o les resultaron más útiles, antes de hacer click en "seguir leyendo" o de pasar al próximo párrafo, para ver si coinciden más conmigo o con las estadísticas.

Creación de complementos. Paso 3: empaquetado

Llegamos al últimos de esta serie de posts destinado a mostrar cómo se arman complementos para ZinjaI basados en bibliotecas externas. Vamos a ver a hora cómo utilizar la herramienta que empaqueta los archivos y genera el .zpc que después podemos instalar fácilmente en cualquier ZinjaI. Resumiendo mucho, los pasos que necesarios para llegar hasta aquí fueron:

1. Obtener los archivos necesarios para compilar un programa cliente de la biblioteca con MinGW. Esto incluye cabeceras, objetos y dlls. Lograr compilar y ejecutar un ejemplo con estos archivos. Más...
2. Armar una carpeta con lo mínimo necesario y modificar la configuración del proyecto para que busque esa carpeta en un ruta relativa a la instalación de ZinjaI. Más...
3. Generar el índice de autocompletado, configurarlo en el proyecto, agregar un botón para acceder fácilmente a la referencia, y guardar todo eso como template de proyecto. Más...

Resta juntar todo lo que tenemos, acomodarlo para el generador de complementos, y obtener finalmente el archivo .zcp. Veamos cómo.

SFML y sus dependencias

Los cambios en la interfaz binaria de los objetos compilados con MinGW hicieron que deba recompilar algunas bibliotecas externas. Compilar una biblioteca no siempre es fácil en Windows, y encima con SFML me llevé algunas sorpresas interesantes que vengo a comentar aquí.

Las bibliotecas libres suelen tener sus procesos de construcción basados en alguna herramienta libre para tal fin, como pueden ser los scripts de autotools, o la herramienta cmake. Estas herramientas son comunes en GNU/Linux, pero no en Windows (lo común en Windows creo que sería tener un proyecto de Visual Studio). Entonces, como conseguir un entorno apto para estas compilaciones no es tan directo, siempre que podamos conseguir las versiones ya compiladas de las bibliotecas para Windows, mejor (más fácil y más rápido). Es lo que pasó al principio con SFML. Para armar el complemento de sus primeras versiones (1.5 y 1.6), yo no compilé SFML, sino que bajé la versión compilada que se ofrece en su sitio oficial y le agregué lo necesario para utilizarla en ZinjaI (como las plantillas de proyectos ya configurados y los indices de autocompletado).

Creación de complementos. Paso 2: extras

Ya tenemos un proyecto que anda, y configurado de forma que solo copiando un par de carpetas de un ZinjaI a otro podemos replicarlo. En esta tercera parte vamos a pulir algunos detallecitos y a generar el bendito índice de autocompletado que hará que ZinjaI nos ayude a utilizar las clases y funciones de la biblioteca mientras escribimos el programa cliente.

Empecemos por generar el índice. Lo vamos a hacer automáticamente a partir de las cabeceras (los .h y .hpp). Esto no siempre es lo mejor, porque a veces tienen definidas cosas demás, que no nos interesan para el autocompletado (como las guardas), o porque a veces no se condicen con la documentación. Digamos por ejemplo que para una clase Ventana la documentación dice que va "#include <Ventana.h>", pero en realidad Ventana.h no tiene la clase sino un montón de #ifs que según el sistema operativo hacen un #include diferente con la versión de la clase para cada sistema operativo. El parseo automático dirá por ejemplo que Ventana está en <Win32/Ventana.h> mientras que lo correcto es poner solo <Ventana.h> o de lo contrario no compilará en otro sistema. Como este hay muchos casos, y por eso los índices de wxWidgets y SFML-1 se generaron parseando los archivos de la referencia HTML y no las cabeceras. Pero este parseo es ad-hoc y requiere mucho trabajo (y programar), así que vamos por la forma fácil y esperemos que no traiga demasiados problemas.

Creación de complementos. Paso 1: relatividad

En el post anterior conté algo sobre algunos problemas que aparecían al querer utilizar bibliotecas externas en un proyecto de ZinjaI, y expliqué la solución a un ejemplo paso por paso. El ejemplo se basaba en la biblioteca OpenCV en su versión para Windows. Si siguieron más o menos esos lineamientos, deberían poder compilar un programa básico con OpenCV y verlo corriendo. En ese caso tuvimos que, además de configurar el proyecto, compilar la biblioteca.

En este segundo post vamos a reacomodar esos archivos de la biblioteca, para tener lo justo y necesario en una sola carpeta, carpeta que estará dentro de la carpeta de instalación de ZinjaI para evitar andar desparramando más archivos por el sistema, y para que además podamos llevarla a cualquier otra PC y sin importar dónde se halla instalado ZinjaI en esa otra PC, el proyecto compile igual sin cambios. Todavía se podrán ajustar más detalles muy útiles (como el autocompletado por ejemplo) antes de tener todo listo para armar finalmente la plantilla y el complemento, pero eso quedará para una tercera parte.

Creación de complementos. Paso 0: configurar un proyecto

Alguien en el foro preguntó cómo hacer para utilizar OpenCV (una biblioteca con todo tipo de utilidades para cuestiones relacionadas a la visión computacional y bastante popular por estos días) en ZinjaI y en Windows. Alguna vez ya escribí de forma genérica acerca de cómo configurar un proyecto en ZinjaI para utilizar una biblioteca. Eso sigue siendo bastante cierto, pero el detalle del cambio de ABI del compilador que comenté en este otro post complicó las cosas. Y aún sin ese problema, las instrucciones aquellas son solo para compilar, pero nos vendría bien también armar una plantilla de proyecto, tener un índice de autocompletado, tal vez acceso a la referencia, etc. Entonces hoy voy a tomar el caso de OpenCV como ejemplo y contar paso a paso cómo armar todo eso y empaquetarlo en un complemento para instalar en ZinjaI en dos pasos. Espero que con este ejemplo los usuarios más interesados se animen a amar sus propios templates, autocompletados, o hasta complementos para compartir con los demás usuarios de ZinjaI.

Exportar un pseudocódigo a un lenguaje real

Desde hace muchísimo tiempo, PSeInt tiene la opción para exportar un pseudocódigo a C++. Es decir, para generar un código C++ que haga exactamente lo mismo que hace un algoritmo en pseudocódigo al ejecutarse en PSeInt. No siempre es posible, pero en general se puede obtener una buena aproximación. El objetivo de esta funcionalidad es bastante dudoso. Definitivamente no está pensado para que generen a través de PSeInt programas reales (es decir, para no tener que aprender un lenguaje real, sino hacerlo acá y convertirlo). Está pensado para servir como ayuda cuando el estudiante empieza a aprender un lenguaje real, luego de haber adquirido lo básico mediante el pseudocódigo. Para generar una sintonía entre lo que ya conoce y lo que está aprendiendo.

El único motivo por el cual se convierte a C++ y no a otro lenguaje es porque C++ es el lenguaje que domino bien, en el cual me siento cómodo, y del cual creo conocer lo suficiente como para decidir cómo conviene hacer las traducciones. Pero muchos docentes que utilizan PSeInt para comenzar, luego pasan a otros lenguajes, y me gustaría que PSeInt también pudiera exportar a muchos de esos otros. En este post voy a contar un poco cómo espero lograrlo, solicitando la colaboración de los docentes (o usuarios en general) que tengan gran conocimiento de esos otros lenguajes para proporcionar ejemplos, y voy a hablar también de los problemas y desafíos que esta traducción supone.

Variables de entorno, shells y scripts en GNU/Linux

Estoy tratando de agregar algunas opciones a ZinjaI para poder controlar la forma en que ejecuta los programas que compila. Actualmente, gracias a los toolchains alternativos se puede modificar por completo la forma en que se compila un proyecto (utilizando un makefile personalizado, o hasta un script). Ahora quiero poder hacer algo parecido con la ejecución, pero aquí hay ciertos detalles interesantes a tener en cuenta. ¿Para qué serviría esto? Algunos ejemplos son casos donde lo que ZinjaI compila es parte de algo más grande y lo que en realidad hay que ejecutar es ese algo (como los organismos para la comvida por ejemplo). En otros casos hay que correr el ejecutable a través de una herramienta (por ejemplo al utilizar mpi para paralelizar, a través de mpirun). Pero el caso más útil será cuando simplemente se quiera hacer algo antes de la ejecución, como borrar/crear archivos, o definir variables de entorno, para luego ejecutar normalmente. El problema es que hay algunas particularidades de cómo se lanzan nuevos procesos hijos desde un proceso padre en GNU/Linux, y de cómo se gestionan los entornos en los shells que interpretan los scripts, que me han dado más de un dolor de cabeza. Finalmente llegué a una forma muy simple de hacer más o menos lo que quería, forma que no pude encontrar buscando en Google, y por eso vengo a comentarla.

Getters y setters automágicos en C++

Hablando con un amigo y colega hace unos días, me comentaba que en Haxe, un lenguaje con varias cosas tomadas (aparentemente) de actionscript y javascript, se pueden definir atributos con getters y setters en una linea como esta: "public var(A,B)", donde A y B pueden ser "null" si no queremos que se puedan ver o modificar desde fuera de la clase, "default" si queremos que se pueda como si fueran públicos, "get" o "set" si más abajo queremos implementar un getter o setter especial, y otras variantes. Algo interesante de esto es que desde el programa/función "cliente" de la clase (el que la usa para algo mediante su interfaz pública), el acceso a estos atributos no cambia de un caso a otro, sino que es siempre igual, como si fueran públicos. Pero en realidad se mete en medio (si queremos) de forma transparente el getter/setter propio.

A esta clase de cosas que parecen pero no son simples atributos públicos, muchos lenguajes las llaman propiedades. Inmediatamente me acordé de las clases para representar widgets en las ventanas con Borland Builder, donde podía hacer edit1->text="hola" en lugar de edit1->SetText("hola") sin problemas. Y dije: "esto se puede hacer igual de transparente en C++". En el caso de objetos de una interfaz gráfica, hay varias formas de que parezca transparente, pero mi idea era generalizarlo, y plantear algún mecanismo para lograr esto con cualquier atributo sin meter mucho ruido en el código de la clase.

Sobre la Programación Orientada a Objetos

Me crié (hablando de programación) con Basic, y con uno de los viejos, donde había que ponerle a todo números de lineas y no teníamos subs. Eso hizo que mi forma de pensar un código fuera fuertemente "estructurada". Más tarde, alguien me sugirió QBasic como una forma de hacer lo mismo que hacía en Basic (el mismo código) pero con un editor más bonito. Explorando qué más tenía QBasic encontré las subs (funciones o subrutinas) y eso me hizo un poco más modular. Cuando pasé a VisualBasic, mi forma de pensar no cambió. La poca y bizarra orientación a objetos de los primeros VB pasó totalmente desapercibida para mí, y sólo incorporé el concepto de evento.

Con ese background (que llevó varios años y estaba bien acentado), entré a la universidad y me dispararon directamente con la Programación Orientación a Objetos (POO) y bastante de C++. Además, era el primer año que la materia se daba en C++; los docentes eran muy buenos programadores con Pascal/Delphi, y tuvieron que aprender C++ solo para actualizar la materia. Todo esto y más hicieron que la orientación a objetos parezca algo forzada. Y si bien no la cuestioné de entrada, tampoco la entendí ni aproveché tanto en mis primeros proyectos. Solo para la parte visual parecía realmente tener sentido.

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.

Primeros pasos con git (parte 1)

Lo prometido es deuda, así que vamos a empezar a hacer cosas con git. En este post vamos a crear un repositorio "central" en algún lado, clonarlo en otro, y luego modificarlo y publicar los cambios en el primero, para que después un tercero pueda obtener también esos cambios. En realidad este post no es más que una excusa para documentar en algún lado lo básico de mi forma de trabajar con git para la próxima vez que empiece un proyecto, porque ya voy armando una receta y me la suelo olvidar.

Antes de empezar aclaro que considero a un repositorio como "central", al de sourceforge si estamos hablando de alguno de mis proyectos públicos, o a un repositorio en una carpeta especial de mi disco si estamos hablando de uno privado, pero acuérdense que es solo una idea mía, a git le da igual cualquiera. Luego, en otro lugar, en una carpeta de trabajo, hago los cambios y los subo al "central". Más tarde si alguien más quiere ver que hice se baja los cambios, o si yo mismo quiero seguir en otra pc, me los bajo también.

Mejor interfaz para los errores en PSeInt

Siempre digo que aprender a programar involucra aprender dos o tres grandes cosas: en un primer escalón los fundamentos (la lógica), luego el lenguaje, y tal vez un poco más abajo las herramientas (el compilador y el IDE). No es fácil aprender todo al mismo tiempo, y creo que sin dudas los fundamentos son lo primero y más importante, son la parte más universal y duradera de este conocimiento. Por eso siempre planteo que para enseñar a programar debemos primero sentar buenas bases en este aspecto tratando de que los otros dos no "molesten" demasiado. Para evitar que el lenguaje "moleste" es que utilizamos el pseudocódigo. Para evitar que la herramienta "moleste" es que, o bien no utilizamos ninguna (pseudocódigo solo en papel como le gustaba a Dijkstra), o bien propongo PSeInt. Es decir, el pseudocódigo debe ser natural y flexible para que los errores que consuman el tiempo sean los de lógica, y la interfaz intuitiva y rápida para que tampoco desvíe la atención, de forma que todo esto se vuelva invisible.

La interfaz de PSeInt arrastra varias decisiones de diseño tomadas por razones "históricas" a veces, técnicas otras, o hasta simplemente por no pensarlas demasiado. En los últimos años he intentado pensarlas más y con un sentido didáctico, pero arrastrando la inercia inicial. Un punto importante y ejemplificador de esto que hablo es la forma en que se muestran los errores de un algoritmo dentro del editor. En este artículo cuento los porqués de algunos cambios que estoy probando para la próxima versión, y los invito a dejar sus opiniones.

Primeros pasos con git (parte 0)

Trabajé durante mil años sin usar sistemas de control de versiones (cosas como svn, cvs, git, mercurial, bazaar, etc) ni nada parecido, y durante todo ese tiempo no sentí la necesidad de hacerlo. Principalmente porque trabajaba solo, o en pequeños grupos, entonces el modelo de llevar y traer zips/tgzs fechados alcanzaba como para no complicarse "por demás" con todo un repositorio. Sin embargo, en algún momento quise ofrecer el código de ZinjaI y PSeInt "en tiempo real" (que cada cambio que haga esté inmediatamente disponible para quien lo quiera probar), porque eso es algo que me gusta de muchos proyectos de los que soy usuario, y porque tiene otras ventajas adicionales (como por ejemplo que algunos usuarios puedan ayudar con el testing de forma temprana).

Hasta entonces, como dije, solo había usado los sistemas de control de versiones para clonar repositorios ajenos y nada más. A partir de ese momento, empecé a experimentar un poco con crear repositorios, hacer y publicar cambios, etc. Y tuve que elegir un sistema en particular, y me incliné por git porque era el que estaba de moda, y porque es un producto que nace de la mano del mismísimo Torvalds para gestionar nada menos que El Kernel, así que potencia y flexibilidad estaban garantizadas. Además, su popularidad prometía mucha documentación actualizada, es decir, un fácil y rápido aprendizaje.

MinGW y las calling conventions

Ya hace más de 6 meses que no vemos publicada una nueva versión "oficial" de ZinjaI. Es normal que en el primer tercio del año los esfuerzos se dirijan mayormente a PSeInt, y este año se han presentado motivaciones adicionales para que así sea aún en mayor medida y por algo más de tiempo. Sin embargo, el desarrollo de ZinjaI nunca se detiene por completo, y quienes observan de tanto en tanto el repositorio saben que siempre hay algo nuevo, aunque solo sea un bug. Pero esta vez hay una razón más para retrasar el lanzamiento de una nueva versión, y esta es un cambio importante en mingw (el port del compilador gcc a Windows). Siempre lleva tiempo actualizar gcc ya que hay que "armarlo" por partes, compilar algunas bibliotecas que agrego en ZinjaI, y luego acomodar y empaquetar todo, pero esta nueva versión tiene algo especial. En qué consiste este cambio y cómo nos afecta a los usuarios de ZinjaI es lo que voy a tratar de explicar en este post.

En cajas de 12

Programar me divierte, y mucho. Pero estoy hablando de resolver problemas interesantes, no de hacer ABMs y páginas webs para el negocio de la esquina (no lo tomen a modo despectivo). Me refiero a problemas de optimización, algoritmos y estructuras de datos por ejemplo. Por eso, cuando veo algún contest de programación, intento participar. Un contest de programación es una competencia, donde hay que resolver problemas programando, y gana el que resuelve más problemas, o el que los resuelve en menos tiempo, o el que hace el código más eficiente. Allí suelen aparecer problemas muy interesantes, y suele ser además el pie para después sentarme a aprender algo nuevo (a pelear otra vez con ese problema que no me salió durante la competencia). Un contest de mucho nombre a nivel mundial es el Google Code Jam, y ya se imaginarán por qué. Empecé a participar ahí creo que en 2008, y hasta el día de hoy sigo más o menos igual: cada año avanzo dos o tres rondas, pero nunca llego a las finales, y usualmente ni siquiera estoy cerca. Solo un año me gané una remera, pero ese año el contest no era global, sino limitado a Latinoamérica.

Cuando me inscribí por primera vez en el sistema online para participar, tuve que llenar un formulario con varias preguntas, entre ellas una que decía si me gustaría trabajar en Google. Obviamente Google busca, además de buena publicidad, identificar buenos programadores para reclutar. Como todo geek que se precie de tal dije que sí sin pensarlo porque: a) ¿a quien no le gustaría trabajar en la empresa más importante del mundo en lo que a software se refiere? b) ¿qué importa qué responda, si total está claro que está fuera de mi alcance? Pero todo esto viene al caso, por algo que pasó hace poco.

Herramientas mágicas: CppCheck

En la primer entrega de la serie Herramientas Mágicas les presenté Valgrind, un analizador dinámico. Lo de dinámico es porque analiza al programa en movimiento, mientras se ejecuta. No es el único de este tipo, ya volveremos a eso, pero ahora voy a presentar un analizador estático: CppCheck. Esto quiere decir que, por el contrario, este tipo de analizador no ejecuta al programa en cuestión, sino que se basa solamente en inspeccionar muy minuciosamente su código fuente.

Para hacer una analogía con algo conocido, digamos que un analizador estático es parecido a medio compilador. Sería la parte del compilador que mira el código generando los warnings y errores, no la que traduce. Pero el objetivo del compilador es traducir a código máquina. Dado que para ello tiene que hacer un análisis previo del código fuente, va detectando "de paso" (como efecto colateral) potenciales errores que avisa en forma de warning. Pero solo hace el análisis necesario para traducir y eventualmente optimizar, y no pierde tiempo en otros detalles. Un analizador estático como CppCheck, en cambio, tiene por objetivo el encontrar errores, por lo que el tipo de análisis que hace toma más tiempo, para detectar cosas más específicas o intrincadas.

Sobre optimizaciones y precisión numérica

Recibí un correo diciendo que el siguiente código en PSeInt:
    a<-rc(13);
    Escribir a<a;
evidenciaba un error de lógica, ya que el resultado daba Verdadero, cuando debiera dar Falso (un número no puede ser menor que sí mismo). Pruebo el código en GNU/Linux y da Falso, pero el usuario dijo que usaba Windows. Entonces voy a Windows y efectivamente da Verdadero. Así que abro ZinjaI y me dispongo a Depurar en Windows, pero he aquí la sorpresa: en el depurador da Falso. Cuando se trata de variables sin inicializar, o manejo de direcciones de memoria, no es raro que una versión Debug dé mejor que una Release, pero en este caso estaba seguro que no se trataba de eso. Estaba a punto de ponerme a analizar el código objeto generado en cada caso (o sea, leer ensamblador, o tal vez saltar por la ventana, estaba decidiendo), pero antes noté algo interesante.

And the winner is....

Como muchos ya habrán notado, PSeInt fue uno de los nueve candidatos a proyecto del mes de junio en SourceForge. Con algún criterio cada semana en SourceForge se eligen los "proyectos destacados de la semana" y se muestran en la portada. Hace poco me entero que estos proyectos se eligen cada semana de entre los que hayan publicado actualizaciones la semana anterior, y no entre todos. Esto explica cómo PSeInt llegó a esa lista en tres oportunidades. A fin de mes, de entre los proyectos de las 4 semanas, se elige un subconjunto para posibles proyectos del mes, y se deja la decisión final al público en general mediante una votación. Para evitar que una persona vote muchas veces, el voto se autentica mediante una cuenta de twitter. Y así funciona. Ahora, habiendo finalizado la votación de mayo, vengo a hacer algunos comentarios y reflexiones acerca de cómo se dieron las cosas.

Algunos porqués del pseudocódigo

Tengo una eterna discusión (en el buen sentido de la palabra) con varios usuarios de PSeInt acerca de hasta dónde debe llegar este lenguaje. Me han sugerido agregar la posibilidad de leer y escribir archivos, de declarar estructuras o pseudo-clases, de usar tipos de datos más específicos, escribir las palabras claves en inglés, agregar operadores como el de desplazamiento de bits, o hasta en algún caso incorporar una instrucción para enviar y recibir datos por el puerto serie (¿?). El dilema es el de siempre, ¿cuánto de pseudo y cuánto de código? Pareciera que mucho de pseudo significa que no se parece casi nada a un lenguaje real y que tiene en principio poca potencia (digamos que muchas cosas no se pueden hacer); mientras que mucho de código pareciera implicar que será fácil pasar luego a un lenguaje real (será más parecido), y que tal vez se puedan hacer cosas bastante complejas.

Depuración (parte 3): Controlando la ejecución II

En el post anterior mencioné los mecanismos básicos para controlar la ejecución del programa: puntos de interrupción, step over y step in. En esta tercera parte voy a completar la idea con algunos más para detener el programa y una aclaración importante sobre el nivel de granularidad con que se pueden indicar estos puntos de la ejecución en el código fuente. También, les voy a contar sobre algunos otras formas especiales para volver atrás en el tiempo o alterar (casi) arbitrariamente la ejecución, cosas que en la práctica permiten analizar varias veces un mismo error, o ensayar algunas soluciones antes de codificarlas. La ventaja radica en no tener que reiniciar el programa y llegar nuevamente hasta el punto conflictivo, lo cual puede llevar bastante tiempo o ser tedioso. Pero además, como efecto colateral, esto sentará una base que permitirá hacer algunos trucos para sortear ciertas limitaciones más adelante cuando hablemos de inspección de expresiones y otras acciones similares.

Depuración (parte 2): Controlando la ejecución I

Habiendo introducido las nociones básicas en la parte 1, vamos a profundizar sobre los dos aspectos prácticos más importantes: el control de la ejecución y la inspección de los datos en memoria. En esta parte 2 (y la que sigue) voy a hablar del control de la ejecución. Con el control de la ejecución me refiero a cómo definimos cuándo y hasta dónde se ejecuta. Hay que saber que el mecanismo básico es el punto de interrupción, pero cualquier depurador nos provee un conjunto de instrucciones para avanzar de a poco sin tener que explicitar nuevos puntos de interrupción. Por ejemplo, si estoy detenido en cierto punto y quiero que ejecute una sola linea y vuelva a detenerse (ejecución paso a paso), tendría que poner un punto de interrupción en la siguiente línea y decirle luego que continúe ejecutando, y una vez detenido nuevamente quitar ese punto de interrupción. Si bien es un mecanismo válido, los depuradores tienen instrucciones para hacer todo esto junto y de forma transparente, de modo que al usuario el usuario ni se entere de ese punto de interrupción auxiliar. Y así, hay comandos para avanzar por linea o por instrucción (que no es lo mismo), hasta llegar a cierta línea, o hasta salir de cierta función, etc. También hay mecanismos para alterar la ejecución y volver a ejecutar una línea que ya pasamos, y otros trucos útiles. De eso habla este post.

Herramientas mágicas: Memcheck (de Valgrind)

La caja de herramientas básica de todo programador debe contener mínimamente un editor, un compilador y un depurador. Y si están empaquetados en su IDE de confianza mucho mejor. Pero además del kit básico, hay varias otras herramientas dando vueltas que pueden resultar muy muy útiles en muchos casos, y que conviene conocer. Sin embargo, no siempre se conocen, y por eso empiezo esta sección, para presentarles las que yo fui encontrando con el tiempo. Son herramientas que antes no extrañaba porque no sabía que existían, a las que tal vez no les encontré el potencial de entrada, pero que después de usarlas un tiempo y explorarlas mejor me parecieron geniales. Por esto, las terminé integrando en ZinjaI, mediante el menú genérico "Herramientas", donde pongo todo lo que no es básico e imprescindible para el alumno, pero sí útil para otros usuarios algo más exigentes.

En esta primera entrega voy a hablar de memcheck, una de las herramientas incluidas en un paquete más grande que se conoce como Valgrind. Valgrind es un framerwork para herramientas de análisis dinámico. Es decir, una infraestructura para analizar automáticamente cómo se comporta un programa cuando se ejecuta (de ahí el "dinámico"). Sobre esta infraestructura se construyen herramientas específicas, por eso cuando instalamos valgrind estamos instalando varias (6 al menos) herramientas que comparten una base común respecto a cómo ejecutan y analizan el programa, pero que centran su atención en partes diferentes, y por ello extraen información diferente. La más interesante de ellas es memcheck, que sirve para analizar cómo usa la memoria un programa, y detectar errores.

Depuración (parte 1): ¿para qué sirve y cómo funciona?

Si hay una habilidad imprescindible en todo buen programador, es la habilidad para depurar un programa. La depuración es en general el proceso de corregir errores, pero cuando hablamos de programación, yendo a la práctica, la clave es ejecutar el programa con un "depurador", una herramienta que nos permite interrumpirlo en cualquier momento para ver qué está haciendo o qué tiene en su memoria. Un programador habilidoso en la depuración, sabe dónde interrumpirlo o qué buscar en la memoria a la hora de encontrar la causa de un problema, o entender cierto comportamiento. Y esto se adquiere con la práctica, como todo en la programación. Hay que conocer qué pueden hacer en teoría las herramientas, pero la práctica y la experiencia nos ayudarán a decidir cómo utilizarlas. Sin embargo, hay muchas funcionalidades básicas de un depurador que puede aprovechar incluso el principiante para entender cómo funciona un ejemplo o una estructura en particular.

El problema es que a pesar de lo importante que nos parezca a muchos programadores, cuando se enseña a programar en general se le da poco y nada de importancia. En la mayoría de los casos, los libros de programación no dedican un capítulo a esto, ni los docentes dedican una de sus clases. Pareciera que es algo para aprender cuando ya sabemos programar, para dejar para cursos avanzados y segundas partes, y esa idea no puede estar más equivocada. Las nociones básicas y el hábito de usar un depurador se deben inculcar desde temprano (desde que dejamos el pseudocódigo y pasamos a un lenguaje real diría yo). Por eso, en esta serie les voy a empezar a contar a los principiantes qué se puede hacer con un depurador, y daré algunas pistas para los más curiosos o avanzados de cómo hace lo que hace, aunque esto último no sea necesario saberlo para comenzar a utilizarlo.

Ayuda, lo necesito urgente!

Una vez más vengo a atacar (solo un poquito) a los usuarios, esos que a veces defiendo tanto. No quiero generalizar, así que al que no le toca que no le toque. Tampoco es que yo tenga un trastorno bipolar, doble personalidad o alguna de esas condiciones psicológicas que no se exactamente qué significan. Lo que pasa es que valoro mucho y trato de fomentar la contribución de muchos buenos usuarios por un lado, pero también a veces me sacan de quicio los mensajes de otros por el otro. En el fondo, puede que todo sea mi culpa, así que vamos a tratar de hacer una crítica constructiva de ambos extremos de la comunicación (va con un poco de humor para no enojar a nadie).

La gente escribe (por mail, por formularios en el sitio web, por los foros, por el chat, da igual) preguntando/diciendo cosas de PSeInt, ZinjaI, C++, programación, o cualquier cosa que les parezca. Muchos mensajes son útiles, muchos habría que ignorarlos, otros no lo se porque ni siquiera los entiendo. Hay problemas en dos niveles: qué quieren decir, y cómo lo dicen. Empecemos por el primero, más básico, elemental, aplicable a cualquier comunicación escrita en cualquier ámbito. Para que entiendan bien todos (especialmente los que lo hacen), lo voy a tratar de poner su lenguaje:
 * PARA EMPEZAR NO GRITEN.
 * Ezkrivan vien x fabor q no kuezta muchio.
 * No den ordenes ni exijan respuesta inmediata nunca jamás!
 * Aprendan comunicar al español con otros persona antes que quiere comunicar la máquina para C++.
 * Usen una coma un punto seguido dos puntos algo los signos de puntuación no muerden ayudan a entender mejor las oraciones gracias
 * Sean amables, soperútanos.

¿Cómo escribir aplicaciones portables?

Antes de decir nada tengo que hacer una aclaración sobre el título, y es qué entiendo por "portable", ya que es una palabra que se puede usar para indicar varias cosas y su significado por defecto en relación a aplicaciones de software creo que ha cambiado con el tiempo. Cuando yo uso "portable", me refiero a aplicaciones que pueden correr en distintos sistemas operativos o arquitecturas de software y hardware (por ejemplo, que puedo hacer andar tanto en Windows como GNU/Linux). La idea es que una aplicación es más portable cuanto menos depende de elementos específicos de un sistema operativo en particular. Creo que los desarrolladores seguimos teniendo ese concepto asociado a "portabilidad".

Sin embargo, actualmente muchos usuarios finales asocian "portable" al hecho de poder llevar la aplicación de una PC a otra en su pendrive para usar sin necesidad de instalarla, como un solo exe que se ejecuta y ya, o como un zip que solo hay que descomprimir. De hecho pueden encontrar googleando que por ahí alguien ofrece PSeInt portable o ZinjaI portable en este sentido, y supongo que todo lo que hizo ese alguien fue instalarlo en una pc y luego comprimir la carpeta de instalación en un zip/rar/autoextraíble/lo-que-prefieran. No se dejen engañar, mis programas se pueden copiar sin necesidad de instalar, siempre, cualquier versión, sin problemas ni modificaciones. El único trabajo adicional que hace el instalador es crear accesos directos y asociar las extenciones, pero sacando eso, no es más que un gran zip preguntando donde descomprimirse (lugar que tranquilamente puede ser un pendrive). Pero esa no es la idea de portabilidad que me preocupa, sino la anterior, y de los detalles de implementación relacionadas a esa primer interpretación es de lo que habla este post.

La importancia del testing

Cualquiera que trabaja en un ambiente profesional sabe que en un proyecto de software se dedican tiempo y recursos planificados para testing y control de calidad en general (QA). Se requiere gente capacitada y con un sexto sentido para averiguar como reventar un sistema en dos simples pasos (mi novia trabaja como tester y creanme que es increíble la facilidad que tiene para encontrar errores que jamás se me habría ocurrido siquiera buscar). Pero también, cualquier programador que desarrolla un proyecto artesanalmente por hobbie, fuera de toda formalidad como sucede a muchísimos proyectos de software libre, sabe lo tedioso que puede ser lograr eso. Ya lo dije muchas veces, en ZinjaI, en PSeInt, y en MotoGT desarrollo a mi ritmo, lo que creo necesario, y soy accidentalmente mi propio tester cuando uso las dos primeras herramientas en mi trabajo, o cuando juego un rato con el tercero.

Pero como buen seguidor del modelo de bazar de Raymond, trato de liberar seguido y esto convierte a mis usuarios en mi mayor recurso de testing. El proceso suele ser: cambio algo, lo pruebo en mi notebook mientras lo desarrollo (una prueba para nada general), lo publico creyendo ingénuamente que les va a funcionar a todos, y luego recibo unos cuantos reportes de errores. A veces son solo detalles, otras veces burradas importantes que no debieron publicarse nunca. Estos errores pueden hacerme perder muchos usuarios, ya que se pueden llevar una muy mala primera imágen y no volver. Pero más allá de eso creo que tengo que hacer una consideración especial, principalmente para con PSeInt: los usuarios son estudiantes que recién empiezan, y el software promete facilitarles el aprendizaje, pero el estudiante por su inexperiencia podría no distinguir un error en la interpretación de un error en su algoritmo. Esto ocurre, y atenta directamente contra el objetivo del proyecto, confunde al estudiante, va en una dirección perfectamente opuesta. Y entonces es doblemente preocupante. Por eso, hace un tiempo empecé a construir de a poco un sistema muy muy básico de testing automático para el núcleo del intérprete, y de eso habla este artículo.

Feliz Cumpleaño!

Hoy se cumple un año desde el primer post de Cucarachas Racing. Lo normal es que quien cumple años reciba algún regalo, pero ¿qué se le puede regalar a un blog? (tal vez un poco de difusión, nunca viene mal, es lo único que se me ocurre). En fin, el punto es que no tiene sentido regalarle algo a un blog, pero como para celebrar igual que después de un año hay gente que sigue viniendo a leer o al menos mirar rápidamente las cosas que escribo, voy a invertir la costumbre y regalarles yo algo a esos lectores. Algo así como lo que les pasa a muchos cuando crecen y empiezan a trabajar, que tienen que llevar comida al trabajo el día de sus cumpleaños (¿que no era al revés cuando eramos chicos?).

Así que yendo al grano, como regalo de cumpleaños les ofrezco El Gran Libro Negro de las Cucarachas Pixeladas (badum, tish...). Y sí, ¿o esperaban que sortee un auto, o licencias de Windows originales? No, no hay tanto presupuesto, es solo un libro. Y no, no tiene nada nuevo, más que el formato. Más allá de lo rimbombante que suene su nombre, se trata de una recopilación de todo lo que ha pasado este año en este blog, pero en formato de libro digital. Por supuesto que libre y gratuito (bajo licencia CC BY SA).

¿Ser o no ser una tortuga?

Alan Perlis fue un pionero que se dedicó a las ciencias de la computación, especializándose en el estudio de lenguajes de programación (no en programar con ellos, sino en discutir sus diseños y fundamentos), lo cual incluso le valió el primer premio Turing (podríamos decir el Nobel de la informática). Entre las muchas cosas que escribió, hay una frase muy popular en el mundo de la programación que es la siguiente: "To understand a program you must become both the machine and the program". Podría traducirse como "para entender un programa de computadora tenés que convertirte en los dos, el programa y la computadora". Es una frase muy interesante que siempre acepté como válida (según mi experiencia) y jamás se me ocurrió cuestionar.

Por otro lado, Seymour Papert es un matemático del MIT que investigó entre otras cosas sobre la enseñanza y el aprendizaje en niños, las ciencias de la computación y la inteligencia artificial. Como fruto de todo esto, surgió el lenguaje LOGO, el de la tortuga. Además, escribió muchas cosas, entre ellas un libro genial llamado "Mindstorm: children, computers and  powerful ideas", donde habla del aprendizaje de los niños, de la enseñanza de la matemática, de su esperanza de que el uso masivo de computadoras cambiaría todo eso, y de cómo el lenguaje de tortugas fue concebido para empezar a dar ese paso. Papert sin duda fue un adelantado.

Nada que no pueda hacer un script de bash (parte 2)

Siguiendo con esta idea de utilizar bash para combinar algunas de las cientos de pequeñas herramientas que se encuentran en casi cualquier GNU/Linux para automatizar tareas varias, en este segundo post traigo algunos ejemplos adicionales. Hay que aclarar, que al igual que en la primer parte, los ejemplos no están explicados 100%, sino que se comenta rápidamente qué hacen y cómo. Un lector con algunos conocimientos mínimos de programación y del uso de la linea de comandos debería poder entender los ejemplos, pero seguramente necesitará googlear un poco más o consultar los manuales para poder modificar estas ideas para sus propias necesidades. De todas formas, el objetivo era solo tirar la primera piedra, para despertar un poco la curiosidad, y si les interesa podrán encontrar fácilmente mucho más material.

Nada que no pueda hacer un script de bash (parte 1)

El título de este post es una frase que uso mucho. Bash, el shell más común en sistemas GNU/Linux, es un intérprete de comandos en modo consola. Soy de esos que usan mucho mucho la consola, porque creen que así las cosas se hacen más rápido. Mucho más rápido, solo que hay que saber un montón muy grande de trucos, nombres comandos, y argumentos, en apariencia crípticos. Por eso la gente prefiere las ventanitas gráficas, porque no hay que recordar nada, todo es intuitivo. Y las ventanas son geniales para eso, pero es ridículo a mi criterio (y el de otros, recomiendo mucho esta vieja lectura, también en español), comparar las limitaciones de una interfaz gráfica simple, con la potencia de una simple linea de comandos.

Pero tampoco es que tengamos que recordar tantos comandos. Diría que la mayoría de los que usamos las terminales usamos regularmente un 5% de los comandos disponibles, y solo sabemos un 3% de sus argumentos. Es así, se puede hacer mucho con poco. Y si somos haraganes, o nos gusta automatizar todo, podemos tomarnos el trabajo de armar un script con las partes difíciles, largas o tediosas, para luego nunca más tener que escribirlas otra vez, sino simplemente invocar al script. Yo tengo mi notebook llena de pequeños scripts, para todo. Y por eso en realidad no sé tanto de bash, porque las operaciones simples son pocas, y las complicadas están dentro de scripts, así que no necesito memorizarlas. Pero sí necesité ejemplos en primera instancia para hacer esos scripts. Y de eso se tratan estos posts. Pienso presentar algunos ejemplos cortos y explicarlos para que vean la potencia de bash y otras herramientas con las cuales se combina, y para que vean el tipo de cosas que se pueden hacer. Espero que aprendan algo, los motive a acercarse a las lineas de comandos, y se les ocurran ideas para sus propias tareas.

¿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.