Some days ago I bought a new laptop, a Samsung Q330 with an NVIDIA Optimus Card. After installing Ubuntu 11.04, I realized that 3D acceleration and CUDA was not available despite of installing the closed-source NVIDIA kernel driver. Then I realized that NVIDIA Optimus is not fully supported in Linux (my fault for not checking it first!), so I started googling to see if there was some info available. It turns out that an open source project called bumblebee enables the usage of both NVIDIA and Intel IGP card with the proprietary drivers.

Installing bumblebee in Ubuntu 11.04 is easy: just add the ppa

sudo add-apt-repository ppa:bumblebee/stable

and then install the bumblebee package

sudo apt-get update
sudo apt-get install bumblebee

How it works

In addition to the main X screen associated to the first available PTY of your system, bumblebee will create a secondary one, this one with the nvidia driver. Whenever system requires to use this device, the program will be run on the secondary X and the output will be transferred to the main X screen. Bumblebee allows to configure different X transfer methods, being Xv the default (and the one I am using).

Using CUDA

As usual, to be able to use CUDA in your system, you need to install the correspondent NVIDIA CUDA driver. Traditionally, I used to install it by hand. However, manual install does not seems to work well with bumblebee. There is a PPA for CUDA available for Ubuntu that worked well for me. Installation instructions are available in this other blog, although I will put an abstract here for reference pourposes:

sudo add-apt-repository ppa:aaron-haviland/cuda-4.0
sudo apt-get update
sudo apt-get upgrade
sudo apt-get install nvidia-cuda-gdb nvidia-cuda-toolkit nvidia-compute-profiler libnpp4 nvidia-cuda-doc libcudart4 libcublas4 libcufft4 libcusparse4 libcurand4 nvidia-current nvidia-opencl-dev nvidia-current-dev nvidia-cuda-dev opencl-headers

Notice how OpenCL packages are also installed. As stated in the original post blog, additional packages might be required to compile the NVIDIA GPU Computing SDK.

After restarting your gdm, if everything was OK, you will be able to run your CUDA programs. If at first didn’t work, try using optirun:

optirun ./cudaProgram

This will tell bumblebee to force execution of the program in the GPU Device (by using the secondary X server).

I have not tested the OpenGl / CUDA interoperability with this system, although it should work properly. Performance however might be degraded due to the framebuffer transfer.

During the last month, while preparing a paper for JP2011, engineers from the SAII (A computer research support unit from University of La Laguna) did interesting research about CUDA benchmarking. Although it might be seen as a trivial task, it required some extra effort. In colaboration with people of our research team (GCAP , High performance computing group of La Laguna University), Iván, one of the engineers involved, has made some interesting notes about this issue in his blog. If you are interested in CUDA, and you need to measure execution times with detailed information, you should take a look into this two articles:

• How to measure time in NVIDA CUDA?
• How to make GOOD measurements in NVIDA CUDA?

Introduction

It’s been a while since my last post, but I’ve been working a lot (too much
maybe) recently. As research staff in the TEXT project[0], I am
deeply involved in HPC programming environments.

This post pretends to be a quick help to the (few) people who wants to
instrument OpenMP programs for profiling. We will use TAU and OmpP.

(more…)

Sometimes, when a presentation is getting too big for a file, I try to split the frames on several files, usually one file per slide. Being tired of doing this by hand, I’ve written a Perl script for doing that:

#!/usr/bin/perl -w
# Split a beamer file into several files, with one slide on each
#           Ruymán Reyes Castro
use strict;
use warnings;
use utf8;
my $slide_num = 0;
my $ACTUAL;
my $inside = 0;
while  (<>;) {
 if ( /begin{frame}/ ) {
   # new file begins
   $slide_num++;
 } elsif (/frametitle{(.*)}/) {
    $inside = 1;
   # Extract file name
   my $filename = filenamize($1);
   print "Writing: ".$slide_num."_".$filename." \n";
   # create file
   open ACTUAL, ">;", "R".$slide_num."_".$filename.".tex" or die $1;
   print ACTUAL "\\begin{frame} \n";
   print ACTUAL $_;
 } elsif ( /end{frame}/ ) {
    print ACTUAL $_;
    # End file
    print "Done. \n";
    close ACTUAL;
    $inside = 0;
 } else {
    # Write to file
    print ACTUAL $_ if ($inside) ;
 }
}

Filenamize translates the frame title to a string suitable for naming a file

sub filenamize {
   use Encode;
   my $in = Encode::decode('utf-8', shift);
   $in =~ tr/ /_/;
   $in =~ tr/áéíóúñ/aeioun/;
   $in =~ tr/:/_/;
   return $in;
}

It’s only a quick-solution, but maybe it’s useful for someone over there…

WARNING!: This post has been written in English, because I want to practice. If you find some mistake (orthographic, grammatical, whatever), please, don’t laugh and tell me where is it. Thanks for your collaboration!

In the SAII[1], we are currently developing applications using Django Framework[2]. Django is an open source application framework, written in Python. It follows the model-view-controller design pattern (MVC[3]). We chose Django because it’s a powerful environment that allow us to quickly pass from the UML class diagram to the model structure, and after that, it’s only a matter of creating the admin interface with two or three simple calls. This offers you a quickly starting point, and, if you are writing a small application, you’ll only need to customize a few aspects of the admin interface.

Django Logo

Hay veces que necesitas crear en tiempo de ejecución clases nuevas (Ojo, no nuevas instancias de una clase, sino clases en si mismas). Es útil cuando las clases se tienen que generar en función del contenido, o cuando hay que generar muchas clases parecidas y no queremos estar escribiendo.

Un ejemplo es el framework para aplicaciones web Django. En este framework, se pueden generar fomularios HTML automágicamente, por ejemplo, para crear un formulario html que permita introducir los datos del modelo Tutu, simplemente hay que hacer una clase del tipo:

>>> class TutuForm(ModelForm):
...     class Meta:
...         model = Tutu

El problema surge cuando tenemos muchos modelos y tenemos que generar autoformularios para todos. Si tenemos que hacer esta clase para cada uno, se nos hace el código muy grande, y tenemos que trabajar con un esquema fijo de urls por ejemplo.

En este caso, una mejor aproximación es utilizar el concepto de Factoría de Clases, es decir, una función (o clase incluso) que genera nuevas clases en tiempo de ejecución. Es posible hacerlo en varios lenguajes, por ejemplo Perl, pero la belleza de la sintáxis de Python lo hace realmente sencillo y claro:

def formClassFactory(modelName):

   """ Función que genera clases autoformulario en base al nombre del modelo del que queremos el formulario """

   # Buscamos la clase que corresponde al modelo

   modelClass = getModel(modelName)

   # Si no la encuentra, no devolvemos ninguna

   if modelClass == None:

      print "No existe un modelo para esa clase"

      return None

   else:

      print "Model Class" + str(modelClass)

   # creamos la clase fantasma (sólo tiene ámbito local)

   class _innerFormClassTemplate(ModelForm):

      class Meta:

	 # Le injertamos el atributo modelo con la clase

         model = modelClass

         exclude = ('grupo','id', 'user')

   # Devolvemos la clase injertada, con la que podemos definir el formulario modelo del método que queramos

   return _innerFormClassTemplate

El código es muy pythónico y claro, pero aún así lo cuento un poco. Como se dice en la docstring, la función genera clases de formulario automáticamente en función del nombre del modelo que queramos. Por ejemplo, si tenemos un modelo que se llama Tutu, esta función devolverá una clase que genere un formulario, y que excluya tres campos que no queremos que aparezcan.

Para ello, primero obtiene la referencia a la clase cuyo nombre tenemos en una cadena. Se podría hacer con un getattr directamente, pero utilizando la función getModel se realizan ciertas comprobaciones de seguridad que no vienen al caso. Luego comprobamos que la clase devuelta no sea nula, porque en ese caso no existiría el modelo del que queremos generar el formulario.

Aquí es donde aparece El Truco. Creamos una clase, con un nombre cualquiera, con la forma que queremos utilizar. Ésta clase tiene ámbito local a la función, así que sólo existe (a priori) en la función local. Aprovechando que tenemos la variable modelClass, fijamos el valor del atributo model de la clase Meta a modelClass, para que la clase nos genere un formulario modelo de la clase. Lo que hacemos finalmente es que la función nos devuelva una referencia a la clase que hemos creado. Como existe esa referencia, la clase sigue existiendo (recordemos que al ser un lenguaje interpretado, las variables existen mientras hayan referencias hacia ellas), y la podemos utilizar como una nueva clase desde el lugar donde hayamos invocado a la función.

En el momento de invocar a la función y obtener la clase, podemos crear una instancia de la misma, como por ejemplo:

  form = formClassFactory(_type)(instance = grp)

Como hemos visto, una factoría de clases es una forma muy cómoda de gestionar la creación de muchas clases similares, ahorrándo código y tiempo, sin poner en peligro la legibilidad.

Algunos enlaces para ampliar:

[1] http://www.ibm.com/developerworks/linux/library/l-pymeta.html?S_TACT=105AGX03&S_CMP=ART

[2] http://rgruet.free.fr/PQR25/PQR2.5.html

Recientemente he estado utilizando Thunderbird y Google Calendar para gestionar el correo con el primero, y las citas con el segundo. A veces, la interfaz de Google Calendar se me hace pesada, no sólo porque hay que cargar el navegador, sino porque ciertas cosas no puedes hacerlas, como por caejemplo, copiar una cita de un día a otro (tienes que crearla de nuevo).

El otro día conocí la extensión Lightning de Thunderbird, que permite integrar la funcionalidad de Sunbird (gestor de calendarios de mozilla). Está muy interesante, y funciona bastante bien. Tiene todas las características habituales: Eventos, tareas, vistas de calendario, etc.

Pero claro, tengo todo en google calendar, que tiene la ventaja de poder acceder a él desde cualquier sitio, así que no me interesaba pasarme por completo a Lightning.

Aunque Google Calendar permite exportar en formato ical o xml, Lightning por defecto sólo permite leer los calendarios en sólo lectura. El problema es que para escribir en el calendario, tienes que autentificarte como usuario de google (¡y no es una característica estándar precisamente!)

Para permitir importar los calendarios en modo de escritura, existe una extensión de Lighting (y Sunbird) llamada muy originalmente Provider for Google Calendar. Con sólo poner la URL privada del calendario de google en lugar de la pública, y proporcionar el usuario y contraseña cuando se nos solicite, podremos acceder tranquilamente a los calendarios, y modificarlos sin problema.

Cuidado con las versiones. Provider for Google Calendar sólo es operativa con las versiones más recientes de Lightning y de Thunderbird. La versión que se encuentra en el repositorio de Ubuntu es basura, así que es mejor si la instalan a mano.

Para terminar, aquí hay un tutorial muy sencillo de cómo utilizar el plugin. Que lo disfruten si les interesa ;)

En el primer post que puse (hace algún tiempo) en este blog, mostraba las fotos de como tenía mi cuartucho en el garage, con la supuesta infraestructura de servidor y demás.

El servidor que estaba encima del armario, hacía de servidor web, de correo, de ssh, de DNS, de Lineage 2 , y de algunas cosas más que ya no recuerdo. Estaba configurado con un Gentoo Hardened, que (supuestamente) era bastante seguro.

Sin embargo, cada vez me llevaba más tiempo mantenerlo, con las actualizaciones de seguridad que fallaban, con discos duros que se estropeaban, etc. Pensé en cambiarlo por otro servidor, pero eso me llevaría bastante tiempo, así que recordé las palabras de mi maestro Jake hace tiempo, en las que me recomendaba que usara dreamhost y me dejara de problemas.

Así que lo hice, contraté 3 años de hosting, y ahora, poco a poco, estoy migrando las cosas aquí. Primero los blogs, luego los repositorios de subversion, y finalmente las backups de las prácticas. Espero que esté todo para finales de febrero, para empezar con buen pié el segundo cuatrimestre.

Ahora en casa no tengo servidor. La configuración de red (firewall, dhcp, etc) la gestionan ahora dos routers, el Linksys ADSL2 Gateway AG241 y el Linksys WRT54G que tengo con el firmware de HyperWRT.

El primero se encarga de la conexión al ADSL y de la red del cuartucho. Tiene el cortafuegos principal y es el que tiene el dhcp. A éste router está conectado el otro, a través del cable más largo de mi casa, que llega hasta el cuarto de la tele. El WRT se encarga de la red Wifi y la red pequeña para los windows, donde se engancha mi familia sin riesgo de sufrir el acoso de los hackers. Aquí también está enchufada la Playstation 3, pero en una DMZ, para no tener problemas con el juego online.

En la imagen aparece un esquema sencillo de como está la red ahora.

Ya describiré las máquinas que hay en detalle, sobre todo la PlayStation y Endymion, que son las que estoy “tocando” últimamente. Venturis e Hyperion son las máquinas viejas, que no tengo conectadas, pero que usaré para cosas más adelante, cuando tenga tiempo.

Espero tener menos problemas con esta configuración, y así poder dedicar mi tiempo a cosas más molonas que se puedan contar aquí ;)

Un comentario sobre la Depuracion en C

Cuando se programa, normalmente uno no se da cuenta de lo grande que es un código, o de o complejo que es un programa, hasta que se cuelga, y hay que depurarlo. La técnica habitual consiste en ir poniendo printf en sitios estratégicos para ver que está haciendo nuestra criatura, pero el problema es que pecamos de inconsistentes. Un mensaje puede decir “Leyendo puntero” y otro decir “Esto no debería de salir nunca”, y si no sabemos exactamente donde está esa cadena, nos quedamos donde estábamos.
Llevaba tiempo queriendo homogeneizar las cadenas que uso para depurar los programas, sobre todo los muy grandes. Había visto en algunos códigos de GNU unas macros que encapsulaban un printf, de forma que tu ponías algo como DEBUG(“Tutu vale %d“, tutu), y se transformaba en algo como “Depuración, línea 55, archivo titi.c: Tutu vale 3“.

Incluso en otras que he visto, se puede especificar un nivel de depuración (si estás en depuración 1 sólo muestras las llamadas a funciones, pero si estás en 500 muestras todas las asignaciones, y cosas así). Sin embargo, hay un problema, ¿como pasas un número de parámetros variable a una macro?

Un recordatorio sobre las Macros en C
Recordemos que una macro es una cadena que interpreta el preprocesador, haciendo una sustitución sencilla de esa cadena por la equivalencia que hayamos definido. Si la macro permite parámetros, simplemente se sustituye el parámetro por el valor en la aparición de la cadena. Por ejemplo, si tenemos la macro

#define SUMAR(A,B) a + b

y nos encontramos con:

int z,x,y;
z = SUMAR(x,y);

El preprocesador cambiará la línea anterior por:

int z,x,y;
z = x + y;

En ese sentido, el printf nos presenta un problema, porque los argumentos que se le pasan, son variables. Podemos hacer printf(“tutu %d tete %f titi %s\n”, tutu, tete, titi) o también podemos hacer simplemente printf(“wisconsin\n”), por lo tanto, no podemos definir una macro concreta para un printf, porque no sabríamos los parámetros que habría que pasarle.
¿Por qué se llama entonces este post Macro Debug?
Porque sí se puede… pero sólo desde que salió el estándar C99. Acorde, entre otras pocas, con la wikipedia, en el estándar de C99 se implementaron por primera vez las macros con argumentos variables, justamente para poder hacer macros que encapsulen a un printf y similares, sin tener que hacer funciones específicas.

Hacerlo es bastante sencillo:

#define DEBUG(FILENAME,STRING,...) printf("DEBUG: " FILENAME " " STRING, __VA_ARGS)


Cuando usemos esa macro, por ejemplo, haciendo

DEBUG(__FILE__,"Tutu %d tete %c", tutu, tete)

el preprocesador nos generará la línea:

printf("DEBUG: main.c Tutu %d tete %c", tutu, tete);

Como podemos ver, el preprocesador extiende automáticamente las comillas para ocupar todos los parámetros consecutivos. Usando esta función (con los parámetros que se quieran poner), se puede tener una salida homogénea para la depuración del código. Incluso, si no queremos generar código de depuración pero no queremos borrar todas las líneas de debug porque pueden hacernos falta en un futuro, podemos hacer:

#ifdef I_WANT_DEBUG
#define DEBUG(FILENAME,STRING,...)
printf("DEBUG: " FILENAME " " STRING, __VA_ARGS)
#else
#define DEBUG(FILENAME,STRING,...) ;
#endif

Usando el código anterior, si está definida la macro I_WANT_DEBUG, generaremos el código de printf, de lo contrario, generaremos una sentencia vacía.

Buena suerte a todos.