ZinjaI+GIT y scripts de bash con interfaz gráfica

Iba a empezar describiendo lo maravilloso que es git, pero voy a dar eso por sentado e ir al grano: ¿cómo es que en ZinjaI no hay ninguna funcionalidad específica de integración con git? Antes de que se ilusionen, les adelanto que no, no estoy trabajando en eso. Peeeero... además de justificar mi no, en este post les cuento cómo integrar igual algunas acciones habituales.

Herramientas mágicas: Gcov

Hoy retomo la serie de "herramientas mágicas" para presentarles GCov. Es una herramienta que yo al principio ni conocía, ni tampoco conocía ninguna de su tipo. Alguien alguna vez en el foro me sugirió que la integre en ZinjaI, y lo hice (de una forma bastante básica) solo porque me costaba poco tomando la integración previa de GProf como base. Pero luego de eso, con el tiempo le fui encontrando usos, empezando por uno no tan obvio y, recientemente, para lo que usualmente se supone que es.

La escencia de la programación de computadores

El gran Brian Kernighan escribió una vez, hace como mil años (circa 1976), la siguiente frase:

"Controlling complexity is the essence of computer programming."

Una posible traducción sería: "El control de la complejidad es la esencia de la programación de computadoras." Debo haber leído esta cita por primera vez hace al menos 10 años. En su momento me pareció una más. No eran palabras rimbombantes, ni conceptos extraños. Parecía más bien un punto de vista, una opinión, con algo de cierto, algo de exagerado, como tantas otras. Otras frases me impactaron/gustaron mucho más cuando las leí por primera vez. Sin embargo, con esta pasó algo muy especial. Con el tiempo, muuuy lentamente, a medida que cometía mis propios errores e iba aprendiendo con cada uno de ellos a programar un poquito mejor, me fui dando cuenta de que esa no es una frase más, sino una de las verdades más profundas e indiscutibles que podemos enunciar sobre la programación.

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.

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.

Aplicaciones visuales con ZinjaI

Después de algunos años ya de utilizar ZinjaI en combinación con wxFormBuilder, creo que la integración de ambas herramientas ha quedado bastante aceitada. Para quien no lo conozca, wxFormBuilder es una programa que permite "dibujar" interfaces (digamos ventanas para nuestros programas) de forma visual (como si fuera Visual Basic, o  Borland Builder), y luego generar automáticamente el código fuente C++ (o Python) que produce esas interfaces para usarlas en nuestros proyectos. Por un lado nos automatiza un poco una tarea a veces tediosa y repetitiva, y por otro nos ahorra escribir mucho código y consecuentemente también investigar la forma de utilizar la biblioteca de componentes gráficos.

Desde un proyecto de ZinjaI, podemos aprovechar esto, y ZinjaI está particularmente preparado para simplificar mucho la interacción entre ambas partes, y estas características de ZinjaI han mejorado bastante en las últimas versiones. Por eso en este post voy a resumir qué se puede hacer, en líneas generales cómo funciona a nivel del código (y aquí va otro uso interesante del polimorfismo) y los pasos básicos para empezar a aprovecharlo. Espero con esto mostrar lo simple y rápido que es hacer GUIs con esta combinación de herramientas.

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.

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.

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.