Este post puede ser útil para los que utilicen el widget TreeView de Gtk+ (no importa el lenguaje mientras haya bindings), y necesiten activar por código celdas en modo edición. Hay algunas cuestiones a tener en cuenta.

Para el Proyecto Final de Carrera estamos desarrollando un sistema de nivel operativo, con funciones de facturación y demás. Necesitamos manejar un TreeView con campos editables, y al finalizar la edición de uno de ellos es necesario dar el foco a otro campo en modo edición, listo para que el usuario comience a cargar datos sin tocar el mouse.

Lo primero que hicimos fue conectar un método al evento Edited del CellRendererText de la columna correspondiente. De esta forma, cuando terminamos la edición en el primer campo, podemos colocar allí el código correspondiente para actualizar el modelo del TreeView y otras operaciones más, entre ellas (la que nos interesa) dar el foco al segundo campo en modo edición. La parte final de este método (el evento se activa al finalizar la edición) había quedado así:

/* ... */

this.tvItems.SetCursor(path,
					   this.tvcCodigoProducto,
					   true);

Hay que tener cuidado al utilizar la función SetCursor. En algunos casos, si no la usamos cuidadosamente, el TreeView no se comportará en forma correcta. Esos casos son por ejemplo cuando el usuario, al estar editando el campo, hace click en otra fila. Esto hace que se dispare el evento Edited, y por lo tanto se activa el modo edición en el segundo campo (SetCursor), pero el foco lo tiene otra fila, y esto hace que el funcionamiento sea incorrecto.

La solución es, antes de ejecutar SetCursor, verificar qué tipo de evento ha ocurrido. En nuestro caso, ejecutamos dicha función sólo si se ha oprimido la tecla Return. El código queda así:

/* Una vez editada la cantidad, automáticamente
 * pasamos el foco al campo de 'código' en modo
 * edición, pero en una nueva fila. A esto lo hacemos
 * únicamente si el usuario presionó la tecla Enter */

Gdk.Event ev = Gtk.Application.CurrentEvent;

if (ev.Type == Gdk.EventType.KeyPress) {
	Gdk.EventKey evKey = (Gdk.EventKey)ev;

	if (evKey.Key == Gdk.Key.Return)
		this.tvItems.SetCursor(path,
							   this.tvcCodigoProducto,
							   true);
}

Lo cual es más lógico también: si se hace click en otra fila, seguramente es porque se quiere editar otro ítem y por lo tanto no es correcto forzar el foco en otro lugar. Además, como se dijo, esto hacía que el TreeView quede en un estado inconsistente.

Hace un tiempo vengo estudiando este sistema de control de versiones distribuído, hecho principalmente en Python, y que lo utilizan algunos grandes proyectos como Mozilla, OpenJDK, NetBeans, etc. En este post, quería compararlo con Subversion, con respecto a mantener distintas ramas de desarrollo.

Aclaro que si bien no tengo una experiencia real con ambos sistemas en el tema, como la podría tener algún desarrollador de un proyecto grande de Software Libre, leyendo los manuales, viendo los ejemplos y utilizándolo en pequeños proyectos con pocos desarrolladores uno puede darse una idea de cómo son las cosas a gran escala.

En muchos lugares se habla de las bondades de los sistemas de control de versiones distribuidos. Una de las ventajas que tienen (entre muchas otras), según se dice, es la facilidad para manejar branches, donde se mencionan las deficiencias de Subversion para manejar varias ramas de desarrollo.

Este post puede servir para alguien que esta pensando en alguna herramienta de versionado, donde se esperan utilizar varios branches en el proyecto, como para poder ver de forma sencilla cómo manejan esto ambos sistemas. Esa “forma sencilla” de verlo podría significar también una divergencia importante con la práctica. Así que si piensan que algo es incorrecto, los invito a dejar un comentario.

En fin, ¿cómo se realizan estas operaciones en ambos sistemas?

Aquí con branch me refiero a una línea de desarrollo para agregar un nuevo feature o corregir un bug, etc. La aclaración es importante, porque en Mercurial casi siempre trabajamos con branches. Si hago un pull y traigo changesets (es decir commits) puede que surjan nuevas ramas. Este no es el significado al que me refiero aquí.

Subversion

En Subversion, no existe el concepto de branch. Un branch es simplemente una copia de un directorio a otro lugar. Uno mismo es el que le da ese significado.

Puedo hacer la copia directamente en el repositorio (donde automáticamente hago un commit):

$ svn copy http://svn.example.com/repos/calc/trunk \
           http://svn.example.com/repos/calc/branches/my-calc-branch \
      -m "Creating a private branch of /calc/trunk."

Committed revision 341.

Si tengo la copia de trabajo correspondiente a todo el repositorio en mi máquina (incluyendo las típicas carpetas trunk, branches y tags):

$ svn copy trunk branches/my-calc-branch
$ svn status
A  +   branches/my-calc-branch
$
$ svn commit -m "Creating a private branch of /calc/trunk."
Adding         branches/my-calc-branch
Committed revision 341.

Luego simplemente comienzo a trabajar en esa carpeta, en mi nuevo branch. Sin embargo, hay una serie de inconvenientes. No podemos dejar que la línea principal de desarrollo se aleje demasiado de nuestro branch (supongamos que estamos agregando un nuevo feature), ya que al intentar fusionar todo luego de un largo tiempo, podemos terminar por frustrarnos. Esto, obviamente, no se aplica sólo a Subversion.

Entonces, periódicamente, traemos los cambios hechos en trunk a nuestra copia de trabajo, que corresponde a la rama en la que estamos trabajando:

$ svn merge -r 100:200 http://svn.example.com/repos/trunk my-working-copy
...
$ svn commit -m "Sync with trunk"

El comando “svn merge” es muy similar a “svn diff”, pero aplica los cambios a mi copia de trabajo.

Como dice en el libro de Subversion, fusionar los cambios suena fácil, pero puede resultar en un dolor de cabeza. Yo, el usuario, soy el que tengo que controlar los merges que hago. Subversion (las versiones menores a las 1.5) no lo hacen. Esto significa que puedo fusionar los cambios dos veces, por ejemplo, o puedo comparar dos cosas sin ningún tipo de relación e intentar aplicar los cambios resultantes a mi copia de trabajo. Cuando ejecuto un comando parecido al de arriba, Subversion no sabe qué significan esos cambios. Simplemente se aplican a la copia de trabajo.

Supongamos que el día al fin ha llegado, y quiero traer a trunk mi nuevo feature, desarrollado en mi branch. Como dice en el libro, si están pensando en comparar la última revisión de trunk con la última del branch, se equivocan: ¿qué pasaría con los cambios hechos en trunk que nunca sucedieron en el branch? Se borrarían, y eso no es lo que queremos.

Lo que hay que hacer es comparar el estado inicial del branch con su estado final. De esta forma adiciono a trunk los cambios que he realizado en mi branch. Para esto tengo que saber en qué revisión creé mi branch. Una forma fácil de averiguar esto con Subversion:

$ svn log --verbose --stop-on-copy \

http://svn.example.com/repos/calc/branches/my-calc-branch

…
------------------------------------------------------------------------
r341 | user | 2002-11-03 15:27:56 -0600 (Thu, 07 Nov 2002) | 2 lines
Changed paths:
   A /calc/branches/my-calc-branch (from /calc/trunk:340)

$

El procedimiento completo, sacado del libro, es este:

$ cd calc/trunk
$ svn update
At revision 405.

$ svn merge -r 341:405 http://svn.example.com/repos/calc/branches/my-calc-branch
U   integer.c
U   button.c
U   Makefile

$ svn status
M   integer.c
M   button.c
M   Makefile

# ...examine the diffs, compile, test, etc...

$ svn commit -m "Merged my-calc-branch changes r341:405 into the trunk."
Sending        integer.c
Sending        button.c
Sending        Makefile
Transmitting file data ...
Committed revision 406.

Noten lo descriptivos que son los mensajes de commit. Esto es necesario hacerlo así, para saber luego, por ejemplo, que ya se han aplicado los cambios del branch, y qué cambios involucran. Es información crítica: supongan que siguen trabajando en el branch y quieren traer los nuevos cambios hechos. Necesitan saber qué cambios ya han sido aplicados para no volver a traerlos a trunk. Para hacer eso, básicamente se ejecutan los comandos anteriores, alterando el rango de las revisiones según corresponda.

Cuando estaba aprendiendo Subversion, leí muy por arriba estas cosas, ya que no eran las que iba a utilizar habitualmente, y además me pareció un poco complicado, con varias advertencias de posibles problemas al fusionar cambios, etc. Por eso estoy copiando los ejemplos del libro, y ahora, en realidad, estoy viendo bien cómo funciona.

Sin embargo una de las cosas que sí aprendí a hacer ya que me parecieron muy útiles, que tiene relación con esto, es “deshacer” un commit, o sea, anular sus cambios. La forma de hacerlo es la siguiente:

$ svn merge -r 303:302 http://svn.example.com/repos/calc/trunk
U  integer.c

$ svn status
M  integer.c

$ svn diff
…
# verify that the change is removed
…

$ svn commit -m "Undoing change committed in r303."
Sending        integer.c
Transmitting file data .
Committed revision 350.

Simplemente se invierten, como habrán notado, el orden de las revisiones a comparar, resultando en un patch contrario al que aplica, en este caso, el commit 303, provocando la anulación de sus modificaciones. Sin embargo, si quiero traer un objeto eliminado de vuelta, no utilizo el comando anterior, sino “svn copy”.

Todas estas cosas que pueden parecer complicadas (y de hecho lo son), parecen estar comenzando a cambiar a partir de Subversion 1.5. Por ejemplo, algunos de los nuevos features, que podemos leer en las release notes, son merge tracking y la resolución interactiva de conflictos. Sin embargo el primero, como se menciona, posee una funcionalidad básica.

Mercurial

Veamos ahora cómo es esto en Mercurial. Aquí un desarrollador no posee únicamente la copia de trabajo, como en Subversion, sino el repositorio completo. Una forma fácil de crear un branch en Mercurial es clonar mi repositorio actual. Supongamos que tengo uno en la carpeta myproject:

$ hg clone myproject myproject-1.0
updating working directory
2 files updated, 0 files merged, 0 files removed, 0 files unresolved

De esta forma puedo comenzar a trabajar en el nuevo branch creado:

$ cd myproject-1.0
$ echo 'Alguna nueva funcionalidad' > algunArchivo
$ hg commit -A -m 'Nuevo feature!'
adding algunArchivo

Con esta manera de crear ramas, hay una relación uno-a-uno entre los branches en los que estoy trabajando y las carpetas existentes. Si necesito centralizar el branch porque voy a trabajar con otros desarrolladores y queremos tener un lugar común donde subir los cambios, entonces puedo subir el repositorio por FTP por ejemplo, a la carpeta donde el script hgwebdir.cgi verifique la existencia de repositorios. Con copiar la carpeta allí y realizar unas simples configuraciones en el archivo .hg/hgrc ya estamos. Otra es, si tenemos acceso shell a la máquina servidor, clonar el repositorio allí mismo.

Estos son los repositorios Mercurial de Mozilla. Allí se pueden ver varios. En uno de ellos se hace un merge con otro, como se puede ver en este changeset.

Si corrijo algún error en mi branch myproject-1.0, seguramente también queramos llevar esas correcciones en la linea principal de desarrollo (digamos, trunk), en el cual, supongamos, también se han hecho modificaciones. Para hacer esto, nos ubicamos en el directorio en donde queremos llevar los cambios (la linea principal en este caso), y ejecutamos un pull indicando la carpeta del branch:

$ cd myproject/
$ hg pull ../myproject-1.0
pulling from ../myproject-1.0
searching for changes
adding changesets
adding manifests
adding file changes
added 2 changesets with 2 changes to 2 files (+1 heads)
(run 'hg heads' to see heads, 'hg merge' to merge)
$ hg merge
2 files updated, 0 files merged, 0 files removed, 0 files unresolved
(branch merge, don't forget to commit)

Con el comando pull lo que hago es traer los cambios (changesets) hechos en el repositorio que le paso como argumento. Cada changeset sabe cuál es su padre, por lo tanto al pullear, se armarán las ramas que sean necesarias. Después del pull, yo sigo en la revisión en la que estaba. Nada ha cambiado en mi copia de trabajo, simplemente se sincronizó mi repositorio actual con el otro.

Notar que Mercurial me avisa que han quedado varios heads: un head es un changeset sin hijos. Con el comando “hg view” puedo ver el panorama actual del repositorio:

El comando “hg merge” fusiona, justamente, mi copia de trabajo con otra revisión. Lo que hace es aplicar a mi copia de trabajo todos los cambios de la otra rama, según corresponda.

Notar que si bien estamos diciendo que utilizamos un branch, myproject-1.0, estos dos heads aquí, también representan branches, pero del tipo “little picture” (como se explica en el libro de Mercurial). Este tipo de branches aparecen todos los días, cuando pulleamos cambios de otro repositorio: son parte del trabajo cotidiano. En cambio el branch myproject-1.0 es del tipo “big picture”, ya que vamos a trabajar en la versión 1.0, corrigiendo errores, etc.

Si “hg merge” detecta conflictos, se ejecuta algún visor de diferencias, como meld o kdiff3. Mercurial se encarga de buscarlo en el sistema, o podemos setearlo nosotros en el archivo ~/.hgrc. Estos visores tienen tres vistas: a la izquierda están mis cambios, en el medio el resultado, y a la derecha los cambios del otro. Entonces es muy sencillo resolver el conflicto.

Como Mercurial nos recuerda después de ejecutar el merge, no debemos olvidarnos de hacer un commit aquí. Este commit tendrá como padres a los dos heads actuales:

Si bien estamos hablando de un sistema distribuído, obviamente que si queremos compartir cambios, la manera sencilla de trabajar es poner un repositorio central visto por todos los desarrolladores, al cual todos puedan subir sus cambios, y del cual puedan bajar los cambios de otros. Si realizo commits en mi repositorio local y quiero subirlos al remoto (con un push), Mercurial me avisará si es que estoy por generar heads remotamente. Si esto sucede, tengo que hacer un pull, mergear los dos heads, y luego subir el resultado.

Esta situación es similar en Subversion a cuando intentamos hacer un commit y nos dice que tenemos que ejecutar un update antes: entonces aplica los cambios en nuestra copia de trabajo, resolvemos los conflictos si es necesario, y realizamos un commit.

Otra forma de crear un branch en Mercurial, es hacerlo en el mismo repositorio, con Named Branches. Así nos ahorramos el tener que subir algo al servidor. Por defecto, si no hemos cambiado nada, trabajamos en el branch llamado default.

Con el comando “branches” puedo ver cuáles hay en mi repositorio:

$ hg branches
default                        0:34b3e0e21c40

Y con el comando “branch” veo en qué branch estoy trabajando ahora:

$ hg branch
default

Supongamos que hemos hecho unos commits en la rama default:

$ hg log
changeset:   1:7c0e8fbd1fb1
user:        Milton Pividori <mimail@proveedor.com>
date:        Sun Oct 12 13:52:18 2008 -0300
summary:     Agrego chau.cs

changeset:   0:936587b0804a
user:        Milton Pividori <mimail@proveedor.com>
date:        Sun Oct 12 13:52:05 2008 -0300
summary:     Agrego hola.cs

Entonces, para comenzar a trabajar en un nuevo branch, digamos myproject-1.0, hacemos:

$ hg branch myproject-1.0
marked working directory as branch myproject-1.0
$ hg branch
myproject-1.0

Como nos indica el comando “branch”, ahora estamos trabajando en nuestro nuevo branch recién creado. El comando por sí sólo no hace nada. Simplemente le indica a Mercurial que a partir de ahora, vamos a comenzar a trabajar en este branch. Si hacemos un commit, Mercurial marcará el changeset como perteneciente a ese branch, y así con todos los changesets siguientes. Supongamos que hemos realizado tres commits más en este nuevo branch:

$ hg log -b myproject-1.0
changeset:   4:188979745f99
branch:      myproject-1.0
tag:         tip
user:        Milton Pividori <mimail@proveedor.com>
date:        Sun Oct 12 14:05:53 2008 -0300
summary:     Agrego comoestas.cs

changeset:   3:06231db27675
branch:      myproject-1.0
user:        Milton Pividori <mimail@proveedor.com>
date:        Sun Oct 12 14:01:02 2008 -0300
summary:     Nuevo feature en chau.cs

changeset:   2:d2d1fd5f5b39
branch:      myproject-1.0
user:        Milton Pividori <mimail@proveedor.com>
date:        Sun Oct 12 14:00:48 2008 -0300
summary:     Nuevo feature en hola.cs

Y supongamos que el trabajo en la rama default continúa con más commits. Entonces el panorama en el repositorio luce como esto:

La rama de la izquierda corresponde a default, y la de la derecha a myproject-1.0. Para moverme entre los distintos branches de un repositorio, utilizo el comando “hg update nombreBranch”. Si después de eso realizo más commits, obviamente, pertenecerán al branch al que me he movido.

Supongamos que mi trabajo en el branch myproject-1.0 ha terminado, y quiero fusionar los cambios con default. Para eso me muevo al branch default (notar que llamo branch a la linea principal de trabajo), o sea a donde quiero llevar mis cambios, y utilizo, nuevamente, el comando “hg merge” seguido del nombre del branch del que quiero traer los cambios:

$ hg update default
2 files updated, 0 files merged, 1 files removed, 0 files unresolved
$ hg merge myproject-1.0
merging chau.cs
merging hola.cs
1 files updated, 2 files merged, 0 files removed, 0 files unresolved
(branch merge, don't forget to commit)
$ hg ci -m "Merge de myproject-1.0 a default"

El nuevo commit pertenecerá al branch default. Este comportamiento es el esperado: fusiono los cambios de un branch dentro del que yo estoy trabajando.

Aquí pueden ver una captura de meld cuando se presenta un conflicto, y a continuación el estado final del repositorio, luego de fusionar los cambios de mi branch a default:

Veamos cómo deshacer un commit con Mercurial. Supongamos que éste es el estado actual del repositorio:

Si me doy cuenta que el changeset 4 (“Bug fix en bar”) es incorrecto, entonces lo deshago con el comando “hg backout”:

$ hg backout --merge 4
reverting bar
created new head
changeset 7:cad3793b208a backs out changeset 4:e56015c82591
merging with changeset 7:cad3793b208a
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
(branch merge, don't forget to commit)

El comando “backout” crea una nueva revisión teniendo como padre aquella que quiere deshacer. Por lo tanto se generará un nuevo head. La opción “–merge” automáticamente fusiona los cambios con la otra cabeza.

Después del commit, el repositorio queda así:

Al mensaje de log lo genera Mercurial.

Conclusiones finales

Creo que realizar branches y luego fusionarlos es bastante más fácil en Mercurial. No tengo que ver en qué revisión comencé el branch y calcular el rango como en Subversion. No tengo que preocuparme de no aplicar dos veces los mismos cambios. Si sigo trabajando en mi branch, traer los nuevos cambios es muy sencillo, ya que Mercurial es el que controla esto. No hace falta ser descriptivo con los logs de los commits, porque con “hg view” puedo ver gráficamente el panorama y saber qué commits fueron realizados para fusionar cambios.

Revertir el cambio de una revisión parece sencillo en ambos, salvo que en Mercurial el comando para resucitar un objeto eliminado, que en definitiva es anular un commit, sigue siendo “backout”. En Subversion había que utilizar “copy”. De todas formas habría que probarlos en situaciones reales en contextos más complicados.

A grandes rasgos (y según lo que yo entendí y veo más notorio), la gran diferencia entre los sistemas de control de versiones centralizados como Subversion o CVS y los distribuidos como Git, Mercurial y Bazaar, es que los primeros imponen más restricciones que sus pares distribuidos. En Subversion por ejemplo, si accedo a mi repositorio vía Internet, y en algún momento no tengo conexión, entonces no puedo hacer commits. Si quiero ver los logs de algunas revisiones o realizar otras operaciones que no sean updates o commits, necesito acceder al repositorio central, lo que es más lento.

En los sistemas centralizados hay un servidor central, y varias copias de trabajo, una por cada desarrollador. En los sistemas distribuidos puede o no haber un servidor central con el repositorio, pero la diferencia es que todos los desarrolladores tienen el repositorio completo, no una copia de trabajo. Es decir que cada persona posee la versión actual más toda la historia del proyecto en su computadora, lo que permite operar en modo offline. Esto puede parecer ineficiente, pero de hecho no lo es: los grandes proyectos de Software Libre como Linux, NetBeans, OpenJDK, Mozilla, y en un futuro GNOME también, usan estos sistemas, ya que ofrecen grandes beneficios (especialmente para los proyectos Open Source). Imagínense hacer commits, crear branches, etc, sin necesidad de conexión. Y cuando termino mi trabajo, luego de revisarlo bien, ahí recién puedo subir todo, o sino decirle a mi colega desarrollador que actualice su repositorio desde el mío.

En definitiva, con un sistema distribuido puedo trabajar con menos restricciones que con uno centralizado.

Estos días estaba leyendo el capítulo 9 de un libro de Mercurial. Uno de los subcapítulos está dedicado a la búsqueda de revisiones o changesets que han introducido bugs. Realizar esto con Mercurial es fácil, ya que tengo todo el repositorio disponible para trabajar offline, por lo que las búsquedas entre changesets son mucho más rápidas.

Imagínense que encontramos un error en nuestro proyecto, y queremos ver en qué revisión fue introducido para realizar un backout del mismo. Para esto, en Mercurial, podemos utilizar el comando “bisect”. Hagamos el ejemplo que se muestra en el libro para ser breves y correctos. Ejecutamos:

$ hg init test
$ cd test

Con un script bash creo automáticamente algunos changesets, e introduzco un bug en el commit 22:

#!/bin/bash

buggy_change=22
for (( i = 0; i < 35; i++ )); do
	if [[ $i = $buggy_change ]]; then
		echo 'i have a gub' > myfile$i
		hg commit -q -A -m 'buggy changeset'
	else
		echo 'nothing to see here, move along' > myfile$i
		hg commit -q -A -m 'normal changeset'
	fi
done

Ejecuto el script en el directorio del repositorio. Esperamos unos momentos a que finalice. Encontrarán varios archivos myfile*. Actualmente estamos, obviamente, en la revisión tip (o HEAD en Subversion):

$ hg parent
changeset:   34:a1c784850dca
tag:         tip
user:        Milton Pividori <miltondp@gmail.com>
date:        Wed Sep 03 10:53:58 2008 -0300
summary:     normal changeset

$

Para saber si en la revisión actual se encuentra el bug, simplemente ejecutamos esto:

$ grep 'i have a gub' myfile*
myfile22:i have a gub
$

Para comenzar las pruebas, ejecutamos:

$ hg bisect --reset

Le indicamos a Mercurial que la revisión tip (o sea, la 34 en nuestro caso, y la actual de la copia de trabajo), es “bad”, ya que contiene el bug (o mejor dicho, posee esa característica de la cual queremos saber en qué changeset se introdujo. Digo esto, porque podríamos querer buscar qué changeset solucionó determinado bug, con lo cual la revisión “bad” sería la que no tiene el error):

$ hg bisect --bad
$

De alguna forma, sabemos que la revisión 10 no tiene el bug, así que la marcamos como “good”. En este caso y a los fines del ejemplo saber esto es sencillo, pero digo “de alguna forma” porque en la práctica debería ser la revisión más tardía sin el bug, lo cual podría llevarnos un tiempo.

$ hg bisect --good 10
Testing changeset 22:3103b305bc80 (24 changesets remaining, ~4 tests)
0 files updated, 0 files merged, 12 files removed, 0 files unresolved
$

Vean que Mercurial nos está diciendo cuántos changesets va a procesar, y la cantidad aproximada de tests que vamos a tener que realizar. Como utiliza búsqueda binaria o dicotómica, la cantidad de comparaciones o pruebas es logarítmica, lo cual obviamente reduce mucho el proceso de búsqueda.

Al ejecutar el comando anterior, la copia de trabajo se actualiza a la revisión 22 ( (34 + 10) / 2 = 22 ). Ahora realizamos el test en esta revisión y le decimos a Mercurial si la misma es “bad” o “good”:

$ grep 'i have a gub' myfile*
myfile22:i have a gub
$

Lo anterior nos indica que es “bad”. Claro que esto se puede automatizar tanto como queramos. Podemos crear un script que haga casi todo:

#!/bin/bash

if ( grep -q 'i have a gub' myfile* )
then
	result=bad
else
	result=good
fi
echo this revision is $result
hg bisect --$result

Lo ejecutamos:

$ ./test.sh
this revision is bad
Testing changeset 16:2deb07b463cf (12 changesets remaining, ~3 tests)
0 files updated, 0 files merged, 6 files removed, 0 files unresolved
$

Ahora Mercurial nos sitúa en la revisión 16 ( (10 + 22) / 2 = 16 ). Faltan unos 3 tests aún. Volvemos a correr nuestro script:

$ ./test.sh
this revision is good
Testing changeset 19:dc33070521ae (6 changesets remaining, ~2 tests)
3 files updated, 0 files merged, 0 files removed, 0 files unresolved

$ ./test.sh
this revision is good
Testing changeset 20:98953c61831c (3 changesets remaining, ~1 tests)
1 files updated, 0 files merged, 0 files removed, 0 files unresolved

$ ./test.sh
this revision is good
Testing changeset 21:d1616a476608 (2 changesets remaining, ~1 tests)
1 files updated, 0 files merged, 0 files removed, 0 files unresolved

$ ./test.sh
this revision is good
The first bad revision is:
changeset:   22:3103b305bc80
user:        Milton Pividori <miltondp@gmail.com>
date:        Wed Sep 03 10:53:56 2008 -0300
summary:     buggy changeset

La revisión que introdujo el bug que estamos buscando es la 22. Con algún tipo de software que automatice la práctica de “Integración continua”, podríamos indicar que seamos notificados cuando alguna revisión o changeset (independientemente del sistema de control de versiones utilizado) no pasa las pruebas o no compila por ejemplo. Esto nos habilitaría a detectar exactamente qué commit introdujo errores o bugs.

Sin embargo, puede pasar que no haya una prueba determinada que me indique que cierta revisión tiene un error, sino que nos demos cuenta de eso más tarde, y nos interese saber en qué changeset se introdujo el mismo para revertirlo (obviamente que esto no es tan sencillo. Habría que estudiar ese changeset para saber dónde está el error). Luego de introducir la prueba de unidad que verifica ese error que estamos buscando, podemos utilizarla para encontrar la revisión que introdujo el problema con algún script y el comando “bisect” que vimos anteriormente, automatizando la operación. Luego, en caso de ser los cambios de dicha revisión simples como el ejemplo, podemos revertirlo de esta forma en Mercurial (primero vuelvo a la revisión tip con “hg update”):

$ hg update
$ hg backout -m "Elimino el bug" 22
removing myfile22
created new head
changeset 35:37d16077cdac backs out changeset 22:a7281f19f281
the backout changeset is a new head - do not forget to merge
(use "backout --merge" if you want to auto-merge)

Ahora hay dos “heads” en mi repositorio (un “head” es un changeset que no tiene hijos), por lo tanto debemos, como nos está indicando Mercurial, hacer un merge entre ambos (podríamos haber utilizado la opción –merge del comando backout directamente).

Con el comando “hg view” podemos ver esto gráficamente:

Notar que el “padre” de la nueva revisión 35 (que soluciona el bug) es el changeset 22. O sea que este cambio no introduce todos los cambios entre ésta revisión y la 34. Por lo tanto debemos hacer, como ya nos había indicado Mercurial, un merge:

$ hg merge
0 files updated, 0 files merged, 1 files removed, 0 files unresolved
(branch merge, don't forget to commit)
$ hg status
R myfile22
$ hg commit -m "Merge hecho"
$

Otra vez, ejecuto “hg view” para ver todo esto gráficamente:

Notar que los changeset de la nueva revisión tip 36 son los commits 34 y 35.

Si bien nunca hice estas cosas con Subversion, por lo que me acuerdo de haber leído, en este sistema de control de versiones hacer esto no es tan sencillo. Justamente una de las críticas a Subversion es que es fácil hacer branches, pero difícil fusionarlos.

El jueves pasado, como indicaba en el post anterior, se realizaron las elecciones para Consejeros Estudiantiles en la UTN, tanto a nivel local como nacional. Nosotros presentamos una lista, Pensamiento Sistémico, que logró la mayoría de los votos, colocando 2 consejeros en los 3 puestos disponibles en el Consejo Departamental de Sistemas, así que es una gran alegría para todos los que estuvimos directamente involucrados, tanto como las personas que nos apoyaron con su voto, a las cuales les doy las gracias.

También hay que agradecer a aquellos que nos dieron una mano en el momento de las elecciones como fiscales, controlando que todo se desarrolle con normalidad. Y por último a Carlos Ignacio Feck, el apoderado de la lista, que trabajó mucho para que todo esto sea posible.

Por lo que entiendo, quedamos como consejeros titulares y suplentes:

• Titular: Milton Pividori. Suplente: Luis Ignacio Larreteguy.
• Titular: Matías Fabricio Gareli Fabrizi. Suplente: Sergio Del Castillo.

De todas formas esta semana se informará bien en el Emilio, y lo importante es que vamos a tener voto en el Consejo para llevar adelante nuestras ideas, así como aquellas de los alumnos.

Bueno, ahora hay que asumir esta responsabilidad y moverse para hacer nuestro aporte a la carrera y a la Facultad. Estos días voy a dejar como comentario en este post los datos para el contacto, ya que todavía nos estamos organizando con esto.

Presentación

Somos un grupo de alumnos de la UTN – Facultad Regional Santa Fe, estudiantes de Ingeniería en Sistemas de Información, que llegando al final de la carrera con varias ideas que se podrían incorporar a la misma, hemos decidido participar como candidatos para Consejeros Estudiantiles por el Consejo Departamental de Sistemas, que se eligirán el próximo jueves 12 de junio.

Hemos conformado una lista llamada Pensamiento Sistémico, la cual es totalmente independiente. Por el momento somos 6 alumnos, de 3er, 4to y 5to año de la carrera:

• Carlos Ignacio Feck.
• Luis Ignacio Larrateguy.
• Matías Fabricio Gareli Fabrizi.
• Milton Damián Pividori.
• Sergio José del Castillo.
• Leonardo Bórtoli.

Estructura gubernamental de la Universidad

Resumiendo la estructura gubernamental de la Universidad, decimos que existen cuatro niveles de gobierno: El Consejo Superior Universitario (que lo integra, entre otros, el rector de la UTN y es el máximo nivel de gobierno de la Universidad), el Consejo Directivo (formado por el decano, docentes, no docentes, graduados y estudiantes; es a nivel Facultad), los Consejos Departamentales (que lo integra el Director del Departamento, docentes, graduados y estudiantes, y donde se discuten cuestiones relacionadas con la carrera) y finalmente Materias Básicas. Como hemos dicho antes, nosotros nos postularemos por los cargos de Consejeros Estudiantiles por el Consejo Departamental de Sistemas únicamente.

¿De qué se encarga el Consejo Departamental, en nuestro caso el de Sistemas? Se discute y decide sobre la política académica de la carrera Ingeniería en Sistemas de Información. Entre otras cosas, esto incluye los planes de estudio y la administración del presupuesto del Departamento.

¿Qué se vota? ¿Cómo? ¿Cuándo?

Se realizan las elecciones de Consejeros Estudiantiles a nivel local y nacional. El día es el jueves 12 de junio. El voto es obligatorio. Para emitirlo, es necesario identificarse llevando en el día de las elecciones: la Libreta Universitaria, el D.N.I. o la Cédula de Identidad.

Nuestras propuestas

• Un mayor contacto entre los Consejeros y los estudiantes, habilitándolos a los últimos a una mayor participación en la toma de decisiones dentro de la carrera de Ingeniería en Sistemas de Información, además de la posibilidad de realizar preguntas, plantear dudas, solucionar inconvenientes con cuestiones relacionadas con el cursado o exámenes por ejemplo. Se verá la factibilidad que haya en organizar reuniones periódicas con los estudiantes interesados en participar.
• La creación de un Grupo de Investigación de Software Libre, que pueda formentar el uso de este tipo de aplicaciones, que ofrezca alternativas libres a las herramientas existentes para la realización de trabajos prácticos en el cursado de las distintas materias, así como la organización de distintos eventos relacionados con esta filosofía.
• Enseñanza del uso de herramientas que conducen a buenas prácticas en el desarrollo de software, como sistemas de control de versiones, herramientas para realizar pruebas de unidad (unit testing), seguimiento de errores y automatización de prácticas como la integración continua.
• Reuniones informativas sobre las actividades de investigación que se realizan en los distintos grupos de la Facultad, motivando a los alumnos en la participación de los mismos.

Hace un tiempo tuve la necesidad de incluir código fuente en C# en un documento de un TP. Gracias a un desarrollador de GNOME he encontrado el paquete listings, en el Planet GNOME.

No sólo sirve para incluir archivos de código fuente, sino también para ficheros de configuración por ejemplo. Es realmente muy util. Pueden bajarse un manual aquí.

Un ejemplo simple:

\begin{lstlisting}[frame=single]
class X {
     string my_string;
     int    very_important_value;
}
\end{lstlisting}

Se pueden setear varias opciones, como “frame”, que dibuja una caja alrededor del código. También se pueden incluir archivos completos con el comando “\lstinputlisting”. Aquí un ejemplo.

Bueno, estuve haciendo unas pruebas con Python y C#. Hay una implementación de código abierto (bajo la licencia de Microsoft Ms-PL) del intérprete de Python escrita en C#, que permite ejecutar estos programas compilando el código Python a CIL (el código intermedio). También tiene una consola, como Python, y es posible utilizar toda la biblioteca de .NET. Se llama IronPython.

Esta implementación, en su versión estable actual 1.1, tiene compatibilidad con CPython 2.4.4. Esto significa que un programa escrito para ser corrido con Python 2.4.4 puede correrse también con IronPython 1.1. Sin embargo no es que podemos correr cualquier cosa hecha para Python con IronPython: un juego que utiliza el módulo PyGame no funciona (por lo menos yo no pude).

Les voy a mostrar un ejemplo en el que desde Python creo una clase que hereda de otra creada en C#. Sip, ¡esto está muy bueno!

Esta es la clase Persona (si, es algo bien sencillo) en C#:

using System;

public class Persona
{
	private string nombre;
	private string apellido;

	public Persona(string nombre, string apellido)
	{
		this.nombre = nombre;
		this.apellido = apellido;

		Console.WriteLine("Constructor C#");
	}

	public string Nombre
	{
		get { return this.nombre; }
		set { this.nombre = value; }
	}

	public string Apellido
	{
		get { return this.apellido; }
		set { this.apellido = value; }
	}

	public string NombreEnMayusculas
	{
		get {
			return this.nombre.ToUpper();
		}
	}

	public string ApellidoEnMayusculas
	{
		get {
			return this.apellido.ToUpper();
		}
	}
}

Para los que no conocen C#, esas cuatro ultimas cosas raras que están definidas se llaman propiedades. Vienen a reemplazar los getters y setters. Así, en lugar de setear el nombre con un objeto.setNombre(“Nombre nuevo”), lo hacemos con un objeto.Nombre = “Nombre nuevo”. Pueden ser de sólo lectura (cuando hay sólo un get), sólo escritura, o lectura/escritura.

En fin, la clase Python es esta:

import clr
clr.AddReferenceToFile("Persona.dll")

import Persona

class Mujer(Persona):

    def imprimirNombreCompleto(self):
        print self.Nombre + ' ' + self.Apellido

    def nombreEnMinusculas(self):
        return self.Nombre.lower()

    def apellidoEnMinusculas(self):
        return self.Apellido.lower()

x = Mujer('Juana', 'Vargas')
x.imprimirNombreCompleto()

print x.NombreEnMayusculas + ' ' + x.ApellidoEnMayusculas
print x.nombreEnMinusculas() + ' ' + x.apellidoEnMinusculas()
print x.nombreEnMinusculas() + ' ' + x.ApellidoEnMayusculas

(Cuando copian y pegan, las comillas simples se cambian. Así que no va a compilar a menos que las reemplacen)

Los pasos para probar este codigo son:

1. Compilar la clase hecha en C# a una librería (Persona.dll) ejecutando: “mcs -t:library -out:Persona.dll Persona.cs”, suponiendo que han llamado al archivo de la clase C# Persona.cs
2. Instalan la versión Community Edition de IronPython (IPCE). La pueden bajar aquí. Hay que agregar a la variable de entorno PATH el lugar donde lo descompriman.
3. Corren el archivo Mujer.py (suponiendo que así lo han llamado) con IronPython: “ipy.exe Mujer.py”

La salida de eso es:

Constructor C#
Juana Vargas
JUANA VARGAS
juana vargas
juana VARGAS

Python desde C#

Lamentablemente el ejemplo anterior invertido no es posible (crear una clase en C# que herede de la de Python), sin embargo obvio que sí se pueden ejecutar métodos y otras cosas.

Python es un lenguaje dinámico, y esta característica complica las cosas. Si bien IronPython ha demostrado que CLR (Common Language Runtime) tiene buen soporte para los lenguejes dinámicos, se está trabajando en una capa que está encima de CLR, llamada DLR (Dynamic Language Runtime) que lo hace muchísimo mejor para este tipo de lenguajes. DLR hace que sea mucho más fácil implementar lenguajes dinámicos en .NET, además de poder compartir código con otros lenguajes (dinámicos y estáticos).

En este tipo de estrategias, para encontrar una buena acción a llevar a cabo, el agente genera un árbol. El nodo principal representa el estado inicial del mismo. Por ejemplo, dicho estado indica que está en la posición (X,Y), con una cantidad determinada de energía y el conocimiento de N celdas. El agente aplica las acciones que son posibles en este nodo (estado), y así genera más nodos, que serán los hijos del primero, por cada una de las acciones aplicadas. Esto representa la expansión del nodo principal.

Así el agente va expandiendo nodos. Una vez que lo hace con el nodo principal, tiene que elegir otro. Y aquí es justamente donde difiere cada estrategia. Por lo demás, son idénticas. Algunas de las formas de ir eligiendo los nodos podría ser por profundidad, amplitud, o costo uniforme. En esta última existe un costo por cada acción, y la estrategia elije el siguiente nodo a expandir según cuál tenga el menor costo. Otra estrategia es la avara, la cual en lugar de utilizar un costo para los nodos, usa una heurística, que indica qué tan lejos del objetivo está, entonces toma una decisión según la acción que más lo acerque al mismo.

Volviendo al tema del post, en el trabajo práctico teníamos que mostrarle a los profesores que nuestro código funcionaba correctamente, es decir, si habíamos elegido la estrategia de amplitud, entonces la lista de nodos expandidos tenía que tener un orden de acuerdo a la misma. Una forma de hacerlo era escribir un archivo XML que vaya indicando cómo se forma el árbol y qué nodos se eligen. Pero es un poco tedioso leer un archivo así.

Estaría muy bueno que al correr el simulador se dibuje un árbol, por ejemplo en PDF, con los nodos que han sido elegidos por el algoritmo implementado, mostrando información de los mismos y qué acciones fueron tomadas para llegar a ellos. Esto parece complicado, pero no lo es si utilizamos LaTeX y el paquete qtree.

Lo que debemos hacer es guardar en una cola los nodos que el algoritmo fue expandiendo, es decir, eligiendo. También hay que pensar en un número de niveles a dibujar, que coincide por supuesto con los nodos elegidos para expandir. El código siguiente, en Java, escribe el documento LaTeX completo, listo para compilar:

private void toLatex(LinkedList nodosSeleccionados, int niveles) {

	/* Salida para latex (genera un arbol usando el paquete qtree). El
	 * siguiente código genera el documento completo para compilar. Sólo
	 * hay que disponer de los paquetes necesarios. */

	// Clase del documento y opciones generales
	Busqueda.logLatex.debug("\\documentclass[a0,landscale]{a0poster}");

	// Paquetes utilizados
	Busqueda.logLatex.debug("\\usepackage{mathptmx}");
	Busqueda.logLatex.debug("\\usepackage[scaled=.90]{helvet}");
	Busqueda.logLatex.debug("\\usepackage{courier}");
	Busqueda.logLatex.debug("\\usepackage{qtree}");
	Busqueda.logLatex.debug("\\usepackage{nodo}");
	Busqueda.logLatex.debug("\\usepackage[spanish]{babel}");
	Busqueda.logLatex.debug("\\usepackage[utf8]{inputenc}");

	Busqueda.logLatex.debug("\\title{Árbol de ejecución - Estrategia: " +
		this.nombreEstrategia() + "}");
	Busqueda.logLatex.debug("\\author{}");
	Busqueda.logLatex.debug("\\begin{document}");
	Busqueda.logLatex.debug("\\maketitle");

	StringBuffer sf = new StringBuffer();
	int cuentaArboles = 0;
	int nivelesProcesados = 0;

	for (Nodo unNodo : nodosSeleccionados) {
		if (cuentaArboles == 0)
			sf.append("\\begin{figure}[!h]\n");

		sf.append("\\Tree " + unNodo.toQtree() + "\n");
		cuentaArboles++;

		if (cuentaArboles == 4) {
			cuentaArboles = 0;
			sf.append("\\end{figure}\n");
		}

		nivelesProcesados++;

		if (nivelesProcesados >= niveles)
			break;
	}

	if (cuentaArboles > 0)
		sf.append("\\end{figure}");
	sf.append("\n");
	Busqueda.logLatex.debug(sf.toString());
	Busqueda.logLatex.debug("\\end{document}");
}

Sólo hay que colocar el documento generado (nosotros utilizamos log4j para las salidas) junto a los archivos de qtree. Claro que no genera el árbol en la forma estándar (debido a cómo el paquete dibuja los árboles), sino que toma un nodo (por ejemplo el primero elegido, que vendría a ser la raíz), lo dibuja junto a sus hijos, luego pasa al siguiente nodo expandido y lo dibuja en un subárbol aparte con sus hijos, y así sucesivamente.

De esta forma, es mucho más cómodo visualizar el funcionamiento de nuestro algoritmo, que implementa alguna estrategia de búsqueda, que seguir con la vista un críptico archivo de texto. Los árboles generados se leen de izquierda a derecha, de arriba a abajo. Este orden de lectura, como mencioné antes, representa la secuencia de nodos que el algoritmo fue eligiendo para expandir.

Algunos ejemplos de archivos PDF generados…

Python es un lenguaje de programación libre, multiplataforma, poderoso y al mismo tiempo muy fácil de utilizar. Si bien, siendoles sincero, nunca lo he aprendido y utilizado (por falta de tiempo), sí he visto código y experiencias de profesionales que afirman esto. Si estas interesando en aprender un nuevo lenguaje de programación, te recomiendo elegir python, y asistir a estas jornadas, que se realizan por segundo año consecutivo en nuestra ciudad. Es muy recomendable registrarse, y de ser posible, adquirir un certificado del evento, no sólo por las razones obvias, sino también para apoyarnos económicamente.

Bueno, ese es el problema con la clase Calculador que proveyó la cátedra de Inteligencia Artificial. No tiene paquete. Si ya se armaron todo su código ordenadito en paquetes no van a poder utilizarla. Sólo se puede desde una clase sin paquete… pero queda muy desordenado poner todas las clases en un mismo paquete, y además no es recomendado.

Pero hay una solución. Podemos seguir teniendo nuestro proyecto ordenado y utilizar esta bendita clase.

Lo que pueden hacer los profesores directamente es ponerle un paquete a la clase Calculador y armar un jar. Es lo más fácil, obvio… pero esto que voy a mencionar aquí es útil para cuando encuentren un archivo .class sin su código fuente, el programador no incluyó la clase en un paquete, es imposible contactar a esta persona o no quiere cambiarlo, y tienen su proyecto organizado con una jerarquía de paquetes (sí, se tienen que dar todas estas condiciones Es poco probable pero esto me divirtió toda la tarde).

Como dije antes, Java 1.4 y superiores no permiten importar clases del default package desde clases que sí pertenecen a uno. Entonces lo que se puede hacer es armar un wrapper, compilar con java 1.3 (que sí permite importar estas clases) y utilizar el wrapper en nuestro proyecto. No hace falta bajarse el jdk viejo… ésta página soluciona nuestros problemas.

Les dejo a disposición de ustedes un archivo jar que al importar en su proyecto pueden comenzar a utilizar el Calculador del TP (las clases Calculador y Pair se traducen a CalculadorWrapper y PairWrapper), hasta que los profesores liberen una versión corregida.

Si ejecutan java -jar CalculadorWrapper.jar les tira por pantalla una prueba de los métodos de la clase.