Mono

Programación

A principios de verano surgió una agria polémica sobre la conveniencia o no de usar Mono (la implementación libre de los estándares ECMA-334 y ECMA-335) dentro de GNOME. El problema en buena medida venía dado por las diferentes opiniones sobre la libertad de Mono. Los que estaban a favor afirmaban que Microsoft había reconocido de manera explícita que renunciaba a denunciar a nadie por usar sus patentes sobre ambos estándares, mientras que los que estaban en contra afirmaban que dicho texto legal era lo suficientemente obtuso como para que no garantizase prácticamente nada, y que habría que abandonar por completo Mono, proponiendo algunos reemplazarlo por Vala. En su momento no escribí nada, en parte porque ya había suficiente polémica, y en parte por falta de tiempo, así que ahora que los ánimos están más calmados me gustaría dar mi opinión sobre una cuestión relacionada.

Para empezar, todo el mundo se centra directamente en si hay riesgo de que haya demandas por patentes a la hora de usar Mono. En ese punto no voy a entrar puesto que se trata de una cuestión legal y yo no soy abogado. Donde sí me gustaría entrar es en el tema de qué aplicaciones es razonable que se escriban en Mono (y, en realidad, en cualquier otro lenguaje que trabaje sobre un runtime, como Java o Python) y cuales deberían ir siempre en Vala.

Para presentar el problema me iré al caso de un viejo conocido de todo el mundo: Windows Vista. Tras su lanzamiento surgieron grandes críticas por su excesivo uso de memoria, lo que obligaba a instalar al menos 2GB para conseguir una fluidez equivalente a la de un Windows XP con 512MB.

Y ese es el problema de utilizar Mono, Java, Perl o Python en donde no se deben usar. Recordemos que el usuario utiliza un ordenador con un fin concreto: realizar un trabajo. Para ello utiliza un programa determinado: si quiere dibujar, utilizará un programa de dibujo; si quiere escribir una carta, utilizará un procesador de texto, etc. Una vez que ha terminado la tarea, cierra el programa (liberando los recursos utilizados) y abre otro para hacer otra tarea.

Por otro lado, tanto los usuarios como los programas necesitan de un sistema operativo que actúe como intermediario. Es importante recalcar que el sistema operativo, hasta cierto punto, debería ser transparente: el usuario no utiliza el sistema operativo para hacer sus trabajos, sino los programas concretos. Así pues, el sistema operativo debe ser parco en el consumo de recursos, pues éstos deben estar disponibles para los programas.

El problema surge cuando hacemos parte del sistema operativo en un lenguaje interpretado o que necesite una máquina virtual. En ese momento nos encontraremos con un consumo mayor de memoria y de procesador, lo que significa que está consumiendo recursos que no debería. Un ejemplo de esto sería programar applets de escritorio o extensiones del gestor de archivos utilizando Mono o Python, o demonios que se queden en ejecución en segundo plano durante toda la sesión. Sin embargo, una aplicación sí puede estar escrita en estos lenguajes porque, a fin de cuentas, es lo que el usuario quiere utilizar. Podría ser deseable que utilice menos recursos, pero ya no es algo tan crítico porque aquí sí estamos utilizando lo que, a fin de cuentas, nos corresponde. Y por aplicación incluyo aquí también aplicaciones oficiales de Gnome, como por ejemplo, Banshee o F-Spot. La clave está en si son programas que permanecen abiertos durante toda la sesión y consumiendo recursos, o son aplicaciones que el usuario lanza expresamente cuando quiere realizar una tarea y que cierra cuando ha terminado de hacerla, liberando los recursos que utilizó. No olvidemos que una aplicación se puede cerrar y volver a abrir, mientras que un applet o un demonio tienen que estar corriendo constantemente para cumplir su función.

¿Entonces debemos utilizar siempre C para realizar las aplicaciones de escritorio, complementos y demonios? Aparentemente sería lo deseable; sin embargo, tiene el grave problema de que programar en C no es tan cómodo, ni los programas son tan mantenibles, como programar con Python, C# o Java (por algo existen). Y es justo aquí donde Vala brilla con luz propia: al tratarse de un lenguaje de alto nivel, con gestión de memoria asistida y una biblioteca de funciones y componentes que crece día a día, simplifica la escritura y mantenimiento del código hasta el nivel de los otros lenguajes comentados; y al compilarse directamente a código nativo, sin necesidad de ningún runtime extra, el resultado es prácticamente tan bueno como si se hubiese utilizado C desde el principio. Por supuesto, Vala también se puede utilizar para escribir aplicaciones, pero considero que aquí ya es cuestión de preferencias, así que cada uno utilice lo que más le guste: Perl, Python, C, Vala, Mono, Lisp, Ook… Pero para partes del sistema operativo o del escritorio considero que sólo se debería utilizar Vala.

Y debo reconocer que consejos vendo pero para mí no tengo, porque una de mis aplicaciones (GtkPSproc) está escrita justo al revés: el programa principal, que sólo se lanza cuando el usuario quiere imprimir algo, y que lleva la interfaz gráfica y hace todo el trabajo, está escrito en C, mientras que un pequeño applet (que, por tanto, está ejecutándose desde que se inicia el escritorio hasta que se apaga la máquina) que se encarga de reenviar la impresión al programa principal, está escrito en Python. En mi defensa diré que la aplicación principal la escribí antes de aprender Python, y que escribir el applet en python fue una chapuza inicial que acabó quedando como definitiva (¿Cuela?).

Vala de plata

Programación, tutoriales

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.

Gemelos

Sin categoría

Acabo de lanzar dos nuevas versiones de mis programas.

El primero es HTMLProc. Al principio sólo iba a corregir el uso de os.Popen2 (está obsoleto en Python 2.6), pero al probarlo descubrí que sólo añadía el tamaño a las imágenes añadidas en las páginas principales, pero no en las imágenes de las páginas añadidas con el comando include. Ya está corregido y aproveché para subir de nuevo todas las páginas corregidas.

El segundo es DeVeDe. La lista de cambios está en su sección, así que poco voy a comentar, salvo un par de detalles:

  • Ahora permite reempaquetar un fichero sin recomprimir: ésto es muy útil para ficheros VOB, los cuales están en formato MPEG-2 y, por tanto, en teoría deberían poder utilizarse «tal cual» con DeVeDe. Por desgracia, si se usan activando la opción «Este fichero ya está en formato MPEG-PS» DeVeDe falla. La razón es que es un PS con algunos campos extra, lo que hace que DVDAuthor se lie y falle. Al activar esta opción, DeVeDe extrae el audio y el vídeo y los vuelve a meter en un PS, pero sin recomprimirlo, simplemente copiandolo; de esta manera no tiene campos extra, y además no se pierde ni un ápice de calidad porque no se está descomprimiendo y volviendo a comprimir.
  • Elimina ficheros viejos en caso de que existiesen previamente, al usar LN: si se hacía una previsualización de un fichero con la opción «Este fichero ya está en formato MPEG-PS» y se cancelaba la conversión, nunca se borraba el enlace, por lo que si se intentaba hacer otra previsualización, fallaba.
  • Ahora soporta ficheros de subtítulos cuyos nombres contengan caracteres reservados en XML: en efecto, antes, si un nombre de fichero de subtítulos tenía un caracter específico de XML, DeVeDe fallaba.
  • Ahora ya no se cuelga al añadir un vídeo en un formato desconocido: en versiones anteriores, cuando se añadía un vídeo en un contenedor conocido pero con un codec desconocido, al intentar obtener los parámetros del vídeo (tamaño, tasa, etc) MPlayer lanzaba una gran cantidad de mensajes de error que saturaban la salida de error, lo que hacía que DeVeDe se colgase. Un ejemplo es un fichero FLV de Flash: el contenedor es reconocido por MPlayer, pero el contenido no.

Que lo disfruteis con salud.

Con gettext y a lo loco

Programación

Hoy estaba preparando la nueva versión de DeVeDe para enviarla a los traductores y, cuando ejecuté el script para actualizar los ficheros de cadenas salió un error: no podía encontrar el fichero devede.glade. Obvio, porque había cambiado a GtkBuilder, así que quité el fichero en POTFILES.IN y añadí todos los nuevos. Sin embargo, me encontré con que ahora no encontraba ni la mitad de las frases.

Una rápida búsqueda en google me dio la solución: por defecto, intltool-update confunde los ficheros .ui de glade con descripciones ui de Bonobo. Para solucionarlo no hay más que añadir la cadena [type: gettext/glade] antes de cada nombre de fichero de glade en POTFILES.IN.

Microerrores

Sin categoría

Acabo de sacar una microrevisión de DeVeDe, la 3.13.1, en donde corrijo un par de fallos… fallitos… despistes realmente.

Para empezar, ahora ya se puede grabar la estructura del DVD (faltaba una w al crear la ventana). Por otro lado, la ventana de propiedades de un título se cerraba cada vez que se cambiaba la acción. Ambos fallos debidos a la migración a GtkBuilder. Por último, he corregido un detalle que impedía copiar la fuente de letra para subtítulos cuando se instalaba desde un paquete DEB, con lo que si nunca se había ejecutado antes, no se podía utilizar.

A disfrutarlo.

De uno a otro confín

Sin categoría

Hoy voy a poner una bonita foto que hice hace unos días, a ver qué os parece:

Si pinchais sobre ella la podreis ver a tamaño real (8192 x 1616 pixels).

Esta panorámica de Vigo la hice a partir de cinco fotos, uniéndolas luego con Hugin, un programa libre específico para este tipo de tareas. El proceso fue prácticamente automático, no tuve que tocar nada. Es cierto que si uno se fija, puede ver un par de zonas en donde se nota un poco la unión, pero también ha influído el hecho de que no sólo roté la cámara, sino que también me tuve que desplazar por las características del sitio desde donde las saqué.

La licencia de uso de esta foto es Creative Commons BY-NC-SA: Creative Commons License
Esta obra está bajo una licencia de Creative Commons

Mal número si no crece

Nueva versión

Me refiero, obviamente, a la versión 13 de DeVeDe, que estaba terminada y prometida desde finales del mes pasado. No la publiqué antes no sólo por movidas personales, sino también porque necesita de la versión 2.16 de GTK, que sólo está disponible en la nueva Ubuntu.

Los cambios son pequeños, muy pequeños: para empezar, unas correcciones en la traducción a griego, y por otro lado la comentada migración de LibGlade a GtkBuilder.

En la próxima versión quiero hacer algunos cambios internos en el código que convierte los archivos, para que sea más sencillo añadir nuevos formatos de salida. También espero añadir nuevas opciones, como por ejemplo permitir hacer DVDs sin menú principal, o añadir por defecto ficheros de subtítulos que haya en el mismo directorio que una película, para poder hacer más cosas con un simple Arrastrar y Soltar. También quiero retocar un poco más la interfaz para que sea más utilizable en equipos con pantallas pequeñas (como los netbooks).

¡Que la disfruteis!

Ubuntu y el Asus F5GL

Trucos, tutoriales

Actualizado el fichero de prioridades. Finalmente conseguí hacer que el Asus F5GL de mi amigo funcione como es debido. Para ello, ha «bastado» con instalar la versión 9.04 (la actual estable) y añadir el núcleo de la versión 9.10, con el correspondiente sistema de pinning para que se actualice pero sin tocar nada del resto del sistema. Para los que tengan el mismo problema, explicaré cual es el proceso:

Seguir leyendo Ubuntu y el Asus F5GL →

Tiempos modernos

Sin categoría

Actualizado: A veces, por casualidad, cuando sólo pretendes pasar un buen rato, te tropiezas con una obra maestra. Hablo nada menos que de Tiempos modernos, el film de Charles Chaplin. En tono de comedia, aunque con un trasfondo dramático (pues, como dijo Roberto Benigni en una entrevista, la comedia sin drama no es comedia, sino bufonada), realiza una gran crítica social de la Gran Depresión, en los años 30; un período, en mi opinión, de grandes paralelismos con el actual por culpa de la (maldita) crisis que estamos sufriendo.

No diré nada más sobre ella porque, como cualquier otra gran obra, lo mejor es pasar de leer críticas y verla directamente. Por eso lo único que haré será animaros a que la consigais como podais, bien comprándola en alguna oferta de grandes almacenes, pidiéndosela prestada a un amigo, o bajándotela de tu eMule más próximo. O, como comentó Anónimo en el primer comentario, podeis probar en la Biblioteca más próxima.