Hace un par de meses descubrí la existencia de Vala, un nuevo lenguaje de programación similar a C# pero con una característica muy interesante: en lugar de compilar directamente a código máquina o a código de una máquina virtual, compila a código C, usando GObject para implementar el sistema de clases y objetos. La gran ventaja de  esto es que permite crear bibliotecas y clases GObject sin necesidad de lidiar con la complejidad de este sistema, lo que, para los fans de Gnome nos resulta especialmente atractivo. También permite trabajar en un lenguaje moderno, lo suficientemente parecido a C# como para que casi no se note la diferencia, pero sin perder ni un ápice de rendimiento (lo siento, sigo sin creerme que un JIT consiga siempre mejores rendimientos, fuera de casos patológicos  y pruebas de laboratorio).

Otro detalle que me ha parecido fascinante es que simplifica mucho la gestión de memoria. Al contrario de lo que podría parecer, no utiliza un recolector de basura como el de Java, sino conteo de referencias. Lo interesante es que todo el proceso es muy transparente, pues el propio lenguaje se encarga de utilizarlo casi siempre. Así, un trozo de código como éste:

using GLib;

class cPrueba:Object {

}

int main() {

    cPrueba miObjeto,miObjeto2;

    miObjeto=new cPrueba();
    stdout.printf("Referencias: %udn",miObjeto.ref_count);
    miObjeto2=miObjeto;
    stdout.printf("Referencias: %ud %udn",miObjeto.ref_count,miObjeto2.ref_count);
    miObjeto=new cPrueba();
    stdout.printf("Referencias: %ud %udn",miObjeto.ref_count,miObjeto2.ref_count);
    return 0;
}

cuando se ejecuta, devuelve la siguiente salida por pantalla:

Referencias: 1d
Referencias: 2d 2d
Referencias: 1d 1d

Vemos que, cuando se hace la primera asignación, se crea un nuevo objeto de tipo cPrueba y se asigna a miObjeto, con lo que su contador de referencias es 1. Luego hacemos la segunda asignación. Como miObjeto y miObjeto2 son, realmente, punteros al mismo objeto (y apuntan, por tanto, a la misma zona de memoria), lo único que hace Vala es incrementar en uno el contador de referencias; por eso los contadores de referencias de miObjeto y miObjeto2 valen 2 en la segunda línea de la salida: porque en realidad son el mismo objeto, pero está referenciado por dos punteros.

Cuando, finalmente, asignamos un nuevo objeto a miObjeto, primero Vala libera el objeto al que apunta, lo que en la práctica consiste en decrementar su contador de referencias. Si en ese momento éste pasase a valer cero, entonces ese objeto quedaría huérfano (ningún puntero apunta a él), por lo que Vala procedería a destruirlo automáticamente, liberando su memoria; sin embargo, en este ejemplo eso no ocurre porque miObjeto2 está apuntando al objeto viejo, así que lo único que ocurre es que su contador de referencias pasa a valer 1. Por su parte, se crea un nuevo objeto de tipo cPrueba, apuntado por miObjeto, cuyo contador de referencias también vale 1, como vemos en la tercera línea de la salida.

Si observamos el código fuente generado (usando valac -C prueba.vala) su función MAIN queda como:

gint _main (void) {
    cPrueba* miObjeto;
    cPrueba* miObjeto2;
    cPrueba* _tmp0;
    cPrueba* _tmp2;
    cPrueba* _tmp1;
    cPrueba* _tmp3;
    gint _tmp4;
    miObjeto = NULL;
    miObjeto2 = NULL;
    _tmp0 = NULL;
    miObjeto = (_tmp0 = cprueba_new (), (miObjeto == NULL) ? NULL : (miObjeto = (g_object_unref (miObjeto), NULL)), _tmp0);
    fprintf (stdout, "Referencias: %udn", ((GObject*) miObjeto)->ref_count);
    _tmp2 = NULL;
    _tmp1 = NULL;
    miObjeto2 = (_tmp2 = (_tmp1 = miObjeto, (_tmp1 == NULL) ? NULL : g_object_ref (_tmp1)), (miObjeto2 == NULL) ? NULL : (miObjeto2 = (g_object_unref (miObjeto2), NULL)), _tmp2);
    fprintf (stdout, "Referencias: %ud %udn", ((GObject*) miObjeto)->ref_count, ((GObject*) miObjeto2)->ref_count);
    _tmp3 = NULL;
    miObjeto = (_tmp3 = cprueba_new (), (miObjeto == NULL) ? NULL : (miObjeto = (g_object_unref (miObjeto), NULL)), _tmp3);
    fprintf (stdout, "Referencias: %ud %udn", ((GObject*) miObjeto)->ref_count, ((GObject*) miObjeto2)->ref_count);
    return (_tmp4 = 0, (miObjeto == NULL) ? NULL : (miObjeto = (g_object_unref (miObjeto), NULL)), (miObjeto2 == NULL) ? NULL : (miObjeto2 = (g_object_unref (miObjeto2), NULL)), _tmp4);
}

(He omitido toda la parte de la definición GObject de la clase ejemplo porque no aporta nada). Vemos en las distintas líneas como cada vez que se hace una asignación de un objeto a una variable, primero se procede a liberar lo que hubiese en dicha variable utilizando una llamada a g_object_unref, para asegurarse de que el contador de referencias decrece correctamente. Luego llama a g_object_ref con la variable que se copia para incrementar su contador de referencias. Como vemos, este proceso automático nos simplifica la vida lo suficiente como para que nos podamos olvidar de la gestión automática de la memoria…

O casi, porque existe, al menos, un caso en el que no se cumple todo ésto: las listas. Sin embargo, tras buscar y rebuscar, encontré que es un bug en Vala, así que ya está reportado (http://bugzilla.gnome.org/show_bug.cgi?id=586577) y debería estar corregido en breve, asi que no añadais una llamada a unref a mano, sino simplemente esperad a que lo corrijan y recompilad para eliminar el memory leak.

Existe, de todas formas, una opción alternativa, que es utilizar LibGee y su ArrayList. Este tipo de listas no tiene el bug que comento, por lo que, si se utiliza, no hay riesgo de memory leaks.

Pese a todo, es importante señalar un par de detalles sobre las listas de Glib en Vala: si vemos la documentacion, hay varias formas de declararlas, en concreto:

• var milista = List<contenido_de_lista>();
• List<contenido_de_lista> milista = List<contenido_de_lista>();
• List milista = List<contenido_de_lista>();

Siendo contenido_de_lista una clase de elementos que contendra la lista. Asi, si quiero hacer una lista de strings la definiria como List<string>.  La cuestion es que, en base a las pruebas que he hecho, solo se realiza gestion de memoria si la lista se define como en la primera o la segunda opcion, porque solo ahi el compilador podra estar seguro de que el contenido es una clase derivada de Object y tiene, por tanto, contador de referencias. Si definimos la lista como en el tercer caso no se realizara gestion de memoria, por lo que podriamos incluso encontrarnos con que metemos en una lista global un elemento definido localmente y que, al terminar la funcion en donde se definio dicho elemento y volver a la funcion principal, dicho elemento es liberado, consiguiendo un hermoso core dump en cuanto intentemos acceder a dicho dato en la lista. Por tanto, mi consejo es utilizar siempre listas bien definidas, salvo que se sepa perfectamente lo que se esta haciendo.

Actualizado. Acabo de terminar una nueva versión de DeVeDe; sin embargo no os abalanceis como locos a por ella porque todavía no está disponible. La razón es que uno de los (pocos) cambios que hice fue migrar el código a GtkBuilder; el problema es que varias de las funcionalidades que aporta se han añadido en la nueva GTK 2.16, la cual viene en Ubuntu 9.04, la cual no sale oficialmente hasta mañana. Eso significa que si saco ahora esta nueva versión, nadie podrá usarla a menos que (como yo) instale una versión Release Candidate de Ubuntu. Por esa razón no la sacaré hasta el sábado (por aquello de dar tiempo a la gente a que migre de manera calmada y ordenada).

Sin embargo, aprovecho para escribir una breve introducción a GtkBuilder (breve porque tampoco hay mucho que explicar, es muy sencilla de usar).

¿Qué es GtkBuilder?

GtkBuilder es una biblioteca que llevará a cabo las mismas funciones que actualmente realiza LibGlade: a partir de una serie de ficheros XML creados con Glade u otro editor, generará las ventanas de una aplicación, incluyendo todos sus widgets internos.

¿Pero si va a hacer las mismas funciones, por qué sacar una nueva biblioteca en lugar de seguir con la vieja?

Por una razón muy simple: LibGlade no forma parte de GTK, sino que sigue un desarrollo completamente independiente. Eso la limita en algunos aspectos (por ejemplo, velocidad a la hora de soportar nuevos widgets y propiedades). Por otro lado, no tenía sentido que una biblioteca tan fundamental fuese un elemento externo. Por último, aunque LibGlade siempre funcionó muy bien y está bien implementada, había algunas cosas que se podían mejorar.

Por todo ésto los desarrolladores de GTK decidieron crear una biblioteca integrada en GTK y que fuese lo más parecida posible a LibGlade, con el objetivo de reemplazarla: GtkBuilder había nacido.

Trabajando con GtkBuilder

La forma de trabajar con GtkBuilder es muy similar a LibGlade. La principal diferencia es que en GtkBuilder no es posible generar sólo una parte del árbol (aunque se están planteando el soportar esta opción). Esto significa que es más eficiente poner cada ventana en un fichero XML independiente.

Si ya tienes un fichero .glade puedes convertirlo fácilmente al nuevo formato usando el script gtk-builder-convert. Como primer parámetro recibe el fichero .glade a convertir; como segundo parámetro, el fichero de salida en formato GtkBuilder; por último, opcionalmente se le puede pasar un parámetro -r seguido del identificador de un widget (usualmente una ventana), de manera que sólo convertirá dicho widget y todos sus hijos. Esta última opción permite separar una antigua interfaz Glade con todas las ventanas en un único fichero, en varios ficheros GtkBuilder, cada uno con una sola ventana.

Un ejemplo: gtk-builder-convert viejo_proyecto.glade ventana_ppal.ui -r main_win creará un fichero ventana_ppal.ui que contendrá la ventana main_win y todos sus elementos, del proyecto viejo_proyecto.glade.

Por cierto, la extensión de los nuevos archivos es .ui. Es un detalle que me costó encontrar.

La primera gran diferencia con Glade es que no hace falta importar ningún módulo, pues ya está dentro de GTK.

Trabajar con GtkBuilder es tan sencillo como:

class MiClase:
    __init__(self):
        builder=gtk.Builder()
        builder.set_translation_domain("mi_aplicacion")
        builder.add_from_file("path/to/file.ui")
        builder.connect_signals(self)
        ventana=builder.get_object("nombre_ventana")

En la primera línea creamos un objeto de tipo GtkBuilder; en la segunda especificamos cual es el nombre de nuestra aplicación de cara a usar GETTEXT para las locales; a continuación le indicamos qué fichero .ui contiene la definición de la interfaz que queremos generar. Estas tres líneas reemplazan a la única línea que utilizábamos con LibGlade.

En la siguiente línea le indicamos que conecte las señales con los métodos de nuestra clase; es igual que el método signal_autoconnect de LibGlade.

Por último, pedimos una referencia a un objeto concreto; es igual que el viejo método get_widget de LibGlade.

Trabajando con Glade

Las nuevas versiones de Glade-3 no sólo soportan el nuevo formato, sino que incluso trabajan por defecto en él. En general se sigue trabajando exactamente igual que antes; la única diferencia es que es recomendable que cada ventana vaya en un fichero (y, por tanto, en un proyecto) diferente.

Un detalle muy interesante es la comprobación del soporte de versiones de GTK en el nuevo Glade: si tenemos abierta una interfaz y escogemos Editar->Preferencias, nos saldrá el siguiente cuadro de diálogo:

En la parte inferior vemos la opción Versiones de los toolkit necesarias. Dicha opción nos permite comprobar si en esta interfaz estamos usando algun widget que no esté soportado por alguna versión antigua de GTK o de GtkBuilder. Esto es precisamente lo que me ocurrió con esta versión de DeVeDe: el nuevo constructor de menús sólo está soportado a partir de GTK 2.16, que viene a partir de Ubuntu 9.04.

En otra entrada explicaré como se trabaja con las GtkComboBox y sus listas asociadas, pues GtkBuilder permite generar todo desde Glade, sin necesidad de picar apenas código.

En la última versión de DeVeDe añadí por fin soporte para multithreading en Mencoder. Por desgracia no es algo tan simple como decirle «Usa threads», sino que hay que decirle cuantos queremos usar.

Alguno dirá: «¡Pues tantos como núcleos tengamos en nuestro ordenador, por supuesto!»

Y efectivamente, esa es la respuesta. El problema viene cuando queremos saber cuantos núcleos tenemos en nuestro ordenador. La primera solución que consideramos es leer /proc/cpuinfo y contar el número de veces que aparece la palabra processor. Por desgracia la cosa no es tan sencilla por culpa de un infame invento de Intel: el HyperThreading. Esta tecnología lo que hace es simular dos núcleos en procesadores de un único núcleo.

Los procesadores actuales no siempre ejecutan las instrucciones en el mismo orden en que están escritas en la memoria, sino que pueden enviar antes algunas que están después, siempre y cuando no dependan de los resultados de ninguna instrucción anterior. Esto permite aprovechar mejor tiempos muertos en la ejecución de instrucciones (por ejemplo, el tiempo que tiene que esperar una instrucción de carga a que llegue un dato desde la memoria). Pues bien, la mayor independencia de instrucciones se da entre procesos diferentes: es posible entremezclar las instrucciones de dos procesos cualesquiera sin que haya riesgo de dependencia, precisamente porque son completamente independientes (valga la redundancia). Los ingenieros de Intel lo entendieron rápidamente y se les ocurrió que podrían llenar huecos en la ejecución de un proceso con instrucciones de otro, aprovechando así al máximo las distintas unidades funcionales del procesador. Desde fuera el procesador parecería tener dos núcleos, y así lo verían los sistemas operativos, cuando en realidad sólo habría uno. Esto permitía incluso no tener que modificar nada en el software.

Sobre el papel la idea parecía muy prometedora, y de hecho Intel afirmaba que se conseguían aumentos de rendimiento de hasta el 30%. Pero en la práctica no sólo era raro acercarse a dicha cifra, sino que había veces que las aplicaciones iban incluso más lentas. La razón no residía en el hyperthreading en sí, sino en su interacción con el Replay System de los procesadores Pentium 4 (que son los únicos que, hoy por hoy, incorporan HT). En X-bit labs explican muy bien en qué consiste, así que no lo repetiré aquí porque quedaría muy largo y peor explicado.

¿Y qué ocurre en el caso particular de Mencoder? En general la gente no se pone de acuerdo. Algunos aseguran que no hay ninguna mejora, pero que tampoco empeora, mientras que otros afirman que va peor si se utilizan multiples hilos. Ante la duda decidí tomar la opción conservadora, lo que implica calcular con precisión el número real de núcleos. Por desgracia no he encontrado una manera «oficial» de saber esa cantidad, sino que hay que deducirla de los datos que ofrece /proc/cpuinfo. Para entender bien la nomenclatura me referiré como procesador a cada uno de los chips que hay en un ordenador, como núcleo real a cada uno de los núcleos físicos de un procesador, y como núcleo virtual al número de núcleos que cree ver un sistema operativo. Así, en un sistema con dos procesadores, en el que cada uno hay dos núcleos, tendremos un total de cuatro núcleos reales. Si encima todos tienen HyperThreading, tendremos un sistema con ocho núcleos virtuales.

Estos son los cuatro parámetros importantes en un sistema con múltiples núcleos y/o procesadores:

• Physical id: identificador único de cada procesador (chip).
• Core id: identificador único de cada núcleo real dentro de un mismo procesador.
• Cpu cores: número de núcleos reales en este procesador.
• Siblings: número de núcleos virtuales en este procesador.

A la vista de estas definiciones podría parecer que basta con contar el número de combinaciones diferentes de Physical id y Core id para saber cuantos núcleos tenemos. Eso hice en la versión 3.8 de DeVeDe y el batacazo no tardó en llegar: un usuario con un procesador AMD Phenom (cuatro núcleos) se quejaba de que sólo usaba un núcleo.

Tras recibir una copia de su /proc/cpuinfo la sorpresa fue mayúscula: ¡las cuatro entradas processor tenían exactamente el mismo Physical id y Core id, y el número de cores en cada una era uno en lugar de cuatro!

Era necesaria una nueva aproximación al problema, así que recopilé las descripciones de todas las máquinas que pude, lo que complicó aún más la cosa porque los valores bailaban y diferían mucho de lo que sería lógico: en sistemas con dos núcleos Cpu cores vale 2, pero en el sistema con cuatro núcleos sólo vale 1. Lo mismo ocurría con el valor de Siblings. Probé varias aproximaciones, cada cual más complicada, hasta que encontré la solución: cada entrada en cpuinfo se corresponde con un núcleo virtual, así que basta con calcular a qué porcentaje de un núcleo real se corresponde. Ese valor lo obtenemos con el cociente entre Cpu cores y Siblings.

En efecto, en mi procesador Athlon X2 y en un Intel Core 2 Duo, Cpu cores y Siblings valen ambos 2 en cada entrada processor, con lo que 2/2=1. En el procesador Phenom de cuatro núcleos ambos valen 1 en cada entrada, con lo que 1/1=1. Pero en un procesador con HyperThreading Siblings vale 2, mientras que Cpu cores vale 1, con lo que 1/2=0,5. Cada entrada processor cuenta como medio núcleo en la máquina con HyperThreading, mientras que en el resto de sistemas cuenta como un núcleo.
¿Y qué pasa en una máquina con un sólo procesador de único núcleo? Pues que no aparece ninguna de esas dos entradas, por lo que hay que asumir que Cpu cores y Siblings valen 1 salvo que aparezcan en la descripción del procesador.

Así pues, basta con ir sumando el cociente entre Siblings y Cpu cores para cada una de las entradas para, al final, obtener el número de núcleos reales del sistema. Este es el sistema que usaré en DeVeDe 3.9, que saldrá dentro de unas semanas.

En Trabajando con GtkTreeView en Python explicaba como utilizar el complejo pero versatil widget GtkTreeView. Sin embargo, faltaba un detalle importante: ¿como usar selección múltiple?

Lo primero es poner el selector del GtkTreeView en modo de selección múltiple:

treeview.get_selection().set_mode(gtk.SELECTION_MULTIPLE)

Ahora ya podremos marcar más de una fila simultáneamente usando las teclas Mayúsculas y Control.

Leer los elementos marcados es tan sencillo como obtener primero el iterador y el arbol:

tree,iter = self.z88tree.get_selection().get_selected_rows()

Si el iterador es None, no hay ninguna fila seleccionada, pero si lo está, no tenemos más que recorrer los elementos del iterador para acceder a las filas. Con ellas, podemos usar el método get_value del arbol para obtener el valor de cada una.

En este ejemplo almacenamos en la lista ret el valor de la columna cero de cada fila seleccionada:

ret = []
for item in iter:
    ret.append(tree.get_value(tree.get_iter(item),0))

Fácil, fácil, para toda la familia.