La terminal en blanco y una historia de variables globales

En marzo publiqué una actualización de PSeInt, y tardé como 20 días (mayormente por mi culpa, por mi delay con los foros) en notar que a varios usuarios no les funcionaba ni la ejecución básica. Cuando querían ejecutar un algoritmo, la terminal quedaba en blanco; y si querían editar el diagrama de flujo, estaba vacío. Y así algunos problemas más, pero todas cosas gruesas, importantes, absolutamente impresentables.... Y entonces ¿cómo es que subí eso y no me di cuenta? He aquí una historia de variables globales y estáticas en C++, con moraleja conocida: evitarlas a toda costa.

MinGW64 y otras variantes para ZinjaI en Windows

Se supone que ZinjaI está preparado para configurar fácilmente más de un posible compilador. En GNU/Linux, suelo alternar entre gcc y llvm-clang sin problemas. Pero en Windows, el cambio es un poquito más delicado, porque el compilador y demás herramientas afines que están como parte de ZinjaI, y no del sistema. Si bien se suponía que era posible hacerlo de todas formas, y que teóricamente el cambio debía ser simple y directo, de la teoría a la práctica suele haber un buen trecho, y por eso no le tenía plena confianza a esta funcionalidad. Pero hace unos días finalmente lo probé y verifiqué que (muy sorprendentemente) funciona justo como esperaba. Y esto es algo muy bueno, porque ya es hora de empezar a utilizar 64bits. En este post les cuento cómo configurar otro MinGW que no sea el que trae ZinjaI, tomando una versión alternativa de 64bits como ejemplo, qué tiene esto de bueno, y cuáles son por ahora las limitaciones.

La venganza de MotoGT (parte 2/2)

Les comenté hace poco que llegué a la inevitable conclusión de que tengo que reescribir MotoGT. A pesar de algunas ideas nuevas que mencioné para el diseño del juego, lo más importante es que en realidad ya no puedo seguir trabajando sobre el mismo proyecto. Y esto se debe a cuestiones técnicas, cuestiones de programación. Y como programar es lo que me gusta, muy probablemente me divierta más re-escribiendo el juego que jugandolo una vez "terminado".

La venganza de MotoGT (parte 1/2)

Hace unos días, cuando tuve algo más de tiempo libre de lo habitual, gracias a un fin de semana largo, intenté retomar algunas viejas cuestiones pendientes de MotoGT. Mi principal problema era (y es) migrar todo a SFML 2.x. Además, de eso, el juego estaba incompleto, y tenía algunas pocas ideas para mejorarlo. Pero al final no llegué a migrar ni implementar nada nuevo, sino que "solamente" (no es poca cosa) llegué a algunas conclusiones importantes al respecto. Resumiendo: tengo que escribir MotoGT 2, de cero. Los motivos son mayormente técnicos, pero en el medio de todo esto, hay lugar para muchas mejoras en el diseño del juego.

El boom de la Programación Funcional (parte 3/3)

Después de contar cómo fue mi primer acercamiento con la programación funcional y lo importante que me parece aprender algo al respecto (parte 1), y por qué siendo un paradigma tan viejo ha tomado nueva fuerza en los últimos años gracias al auge de la programación paralela principalmente (parte 2), hoy cierro contando muy básicamente cómo se lleva esto a mi lenguaje favorito, C++, que desde 2011 ha facilitado mucho las cosas en este sentido.

El boom de la Programación Funcional (parte 2/3)

Esta es la segunda parte de una trilogía de posts con desvarios propios y ajenos relacionados a la programación funcional. En la primera, hice una pequeña introducción intentando convencerlos de lo útil e interesante que es esto, pero sin decir nada en realidad. Y conté luego cual fue mi primer acercamiento casual a la misma, remontándome gracias a la Internet 30 años atrás. En esta segunda parte, volvemos a la actualidad, y les cuento cómo es que en estos últimos años se ha vuelto más importante.

El boom de la Programación Funcional (parte 1/3)

Desde hace relativamente pocos años, el paradigma de la programación funcional ha tomado un nuevo auge, hasta el punto en que hoy en día podríamos considerarlo como una especie de "trending topic" en el mundillo de la programación en general. Podría decir que los conceptos esenciales son más viejos que la programación misma. Pero, para alguien como yo, que tuve toda mi formación inicial en lenguajes estructurados y procedurales, que luego pasé a la "moderna" orientación a objetos, y que desde hace años C++ es mi herramienta de trabajo en el día a día, esto es nuevo. Es algo que empezó a hacerme ruido con la estandarización de C++11, y que por lo que veo, gracias al auge del paralelismo, llegó para quedarse.

Hay muchos programadores sueltos que han tenido una formación similar a la mía, y que aún no descubren lo enriquecedor que es el mundo de la programación funcional. A esos colegas les estoy escribiendo. Por que si bien, es muy probable que yo nunca use de verdad un lenguaje realmente funcional, las ideas que me va implantando el aprender sobre este paradigma sí repercuten en mi forma de pensar los problemas y analizar las implementaciones. Creo que todo informático debería tener una formación básica en programación funcional, con el solo objetivo de abrirle la cabeza a otra forma de analizar un programa y de entender la programación.

Mientras tanto, en PSeInt... (II)

Es tiempo de volver a hablar de PSeInt. Hace no mucho escribí un artículo que empezaba con "Hace ya un buen rato que no vemos versiones nuevas de PSeInt. En buena parte se debe a que..." y continuaba con una serie de excusas y pseudo-promesas. La mayoría de las excusas siguen siendo muy ciertas, y algunas hasta se agravaron, pero como dije aquella vez, esto no significa que en el desarrollo de PSeInt no ocurra nada. A solo dos días de aquel post publiqué una actualización con esos pocos cambios que había comentado. Esta vez no van a ser dos días, pero sí otra vez muy pocos hasta que publique oficialmente una nueva versión. Este post es más o menos un informe de situación para actualizar esa lista de excusas y pseudo-promesas, comentando otra vez qué fue lo poco que estuvo ocurriendo, y qué esperar para el futuro.

Herramientas personalizadas en ZinjaI

Desde hace algunas versiones, ZinjaI permite definir hasta 20 herramientas personalizadas. Esto es, hay items en el menú de herramientas (y opcionalmente sus correspondientes botones en la barra de herramientas, y/o sus atajos de teclado) para los cuales el usuario puede configurar acciones a gusto. En la última versión, hay mejoras que las hacen más flexibles y fáciles de usar que antes. Esto está pensado para cosas que requieren ejecutar programas externos a ZinjaI, como puede ser abrir una referencia de una biblioteca en un navegador, ejecutar scripts de mantenimiento, o ejecutar un proyecto de forma alternativas. Pueden configurarse herramientas "globales" (para esa instalación de ZinjaI, siempre disponibles), y por proyecto (disponibles en cualquier ZinjaI solo para ese proyecto). En este post pongo algunos ejemplos de uso para mostrar qué cosas se pueden hacer y presentar algunas de las opciones nuevas que pueden resultarles útiles.

Aprendiendo a programar... otra vez

Durante el año pasado aprendí muchísimo sobre C++. Leí cuanto blog especializado me pasó cerca, y miré cuanta charla encontré en Internet de gente que está en la cresta de la ola. Entendí detalles muy finos que desconocía de C++03, traté de incorporar todo lo que pude del nuevo C++11, y hasta algunas cosas muy frescas de C++14. Y mi forma de encarar este nuevo contenido fue variando hasta dar un giro de 180 grados. Empecé pensando que sabía programar (con el viejo C++, y también hablando en general) y que el proceso consistiría en aprender solo otro lenguaje. Pero terminé dándome cuenta que en realidad aprendí a programar "otra vez". O mejor dicho, que recién ahora estoy aprendiendo a programar como se debe.

Herramientas Mágicas: Doxygen

Siguiendo con la vieja serie de post sobre Herramientas Mágicas, hoy voy a comentar la tercera y última herramienta del grupo que inicialmente tenía en mente cuando empecé con esta serie. Esta la menos mágica, pero no es menos útil que las otras dos. Hay varias herramientas más para comentar, ya lo haré más adelante, pero estas primeras tres son las que me resultaron más útiles en general. La herramienta en cuestión es Doxygen, y sirve para generar documentación acerca de un código fuente. Es ideal para documentar las interfaces de nuestras bibliotecas. A esta altura deberíamos suponer que la mayoría de ustedes ya la conoce o conoce alguna otra similar. Pero... (no le digan a nadie) yo me gradué de informático sin haber usado nada que se le parezca. Para ayudar a que eso no le vuelva a ocurrir a otros, voy a escribir un poco contando de qué se trata, presentar un ejemplo, mostrar que ZinjaI puede facilitar su uso, etc.

¿Soy un programador o un depurador?

De las múltiples actividades de las que consta el día día de un programador, en mi caso (y en el de muchos) tipear código o dibujar diagramas de clases (por dar un par de ejemplos de actividades "estereotípicas") no es lo que más me ocupa. La mayor parte de mi tiempo como programador se me va "depurando". No es que le reste importancia a las etapas previas (todo lo contrario, cada vez las valoro más), ni que sea tan animal que por cada linea de código que escriba cometa tres errores. Pero es así. Y esto se contradice un poco bastante con lo que a uno le enseñan en la universidad, sobre primero pensar, diseñar, analizar, bosquejar en papel, y solo luego sentarse a codificar. Se puede argumentar que tanto depurar es consecuencia de saltarse o apurarse en las etapas previas. Entonces: ¿es una muy mala señal pasar más tiempo depurando prototipos erróneos o incompletos, que pensando primero y escribiendo luego las cosas bien, sin tantos defectos? Creo que no necesariamente.

Bibliotecas externas en versión debug

Siempre pensé que era mejor utilizar versiones "release" de las bibliotecas de terceros en mis proyectos, para todas las compilaciones, aún en mis versiones para debug. Es decir, que si mi programa usa una biblioteca B, al depurarlo me interesa solo depurar mi parte. Agregar la información de depuración de B sería agregar ruido. Hace poco comprobé que esto no siempre es recomendable. Es algo que ahora me parece muy obvio, pero la verdad es que antes no le había dado importancia. Nunca había usado intensivamente una versión debug de una biblioteca externa, y por eso no había notado las muchas ventajas que esto tiene.

Por qué la ejecución era tan leeenta en el depurador

Hace unos días comenté que había estado renegando para depurar un proyecto en Windows porque al correrlo en el depurador la ejecución tardaba 17 veces más de lo normal. Encontré en aquel momento un workaround para salir del paso, pero no sabía entonces la causa real del problema. Cerré el post prometiendo escribir si la averiguaba, y ahora vengo a cumplir con eso. Ya encontré la causa, y una solución muy simple que, como siempre, estará incluida en ZinjaI para la próxima versión (muy pronto).

Cuando la ejecución en el depurador es mucho más leeenta

Saben que en ZinjaI (y en muchísimos otros IDEs) tenemos dos formas de ejecutar un proyecto: la "normal" y la "debug". La "normal" (Ejecución->Ejecutar o F9) guarda, compila y ejecuta el resultado como si hubiésemos hecho doble click en el exe desde el explorador de archivos. La ejecución "debug" (Depuración->Iniciar o F5), en cambio, ejecuta a través de gdb. Es decir, ejecuta gdb (el verdadero depurador que hay detrás de ZinjaI), y le pide a este que cargue y ejecute el exe. Para tener control sobre esta ejecución, gdb puede hacer internamente cosas raras, normalmente sin que lo notemos. Me dí cuenta hace poco que en Windows alguna de estas cosas raras puede hacer que el programa corra mucho más lento que en la ejecución normal. Y cuando un programa, en su ejecución normal revienta luego de unos pocos minutos de proceso, este "enlentecimiento" se torna un problema grave, porque para intentar depurarlo debemos esperar una eternidad hasta llegar al problema, cada vez que lo probamos. Ahora tengo un mecanismo interesante para resolver el problema de analizar el error con el depurador sin esperar tanto tiempo.