In Linux, the easiest way to convert this kind of files is to use the convert command, from the ImageMagick package. For example, converting a PS file to a JPEG file is as easy as typing this command in the console (assuming you have already installed the aforementioned ImageMagick package):

convert original.ps destination.jpeg

Better quality images can be generated using GhostScript (gs). For example, the same convertion produces (at least for me!) better quality jpeg images:

gs -q -dNOPAUSE -dBATCH -sDEVICE=jpeg -r300 -sPAPERSIZE=a4  \
      -sOutputFile=destination.jpeg original.ps

Notice the -sDEVICE parameter, which specify which GV device we want to use and the -r300, which specify the desired resolution (in dpi). -dNOPAUSE and -dBATCH enables the command to be used inside a batch script without requiring user intervention.

They are several devices available, some of the most useful for me are:

• png16m: To convert PS files to PNG
• tiff24nc: To produce non-color tiff files, useful to directly print in several devices
• epswrite: To generate EPS files

Sometimes the original file has excessive blank space. It is possible to use the -dEPScrop  option to remove the margins and try to fit the paper size to the image.

In case the file contains text,  is it possible to further increase quality of the resulting file by using the -dTextAlphaBits=n (where n is 2 or 4) to apply antialiasing to the fonts.

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.

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

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.

Brief review of profiling

Profiling[1] source code requires two phases: First instrumenting the code, and
second, run it to get trace and profile information. A widely-known profile
tool is GnuProf[2], and its usage is simple. First, compile with the ‘-pg’ flag

$ gcc -pg program.c -o program $./program

You will notice that the program runs slower, and, when it finished. You will
get a file called gmon.out. Using gprof tool, you can see which function
consumes most time.

This information is useful in simple cases, to identify the time-killer
functions or methods of a code. You can focus on optimizing the most
time-consuming function, because is where you will get the most benefit[3].

However, there are some cases where gprof is not enough. In parallel
applications, when you have multiple threads, you want to know which thread is
doing what. To get this information, you need a more powerful tool.

TAU

TAU[4] is, among other things, an instrumenting tool for timing and
performance. It can instrument MPI code, and produce profile and trace files in
TAU format, which can be converted to several other formats (Vampirtrace,
Slog2, …)

Setup and config

To use TAU you need to install PDT first (it can be found on [4] also).
Download the source code, and compile it. Don’t forget to specify the compiler
which you are using (Intel in my case):

$ ./configure -ICPC && make

You will have a directory matching your architecture (x86_64 in my case) where
all the PDT files will be found.

Next step is to build TAU. This is an important step. TAU configure have
several options. As we want to add OpenMP support, we need to specify it at
compile time. There is a graphical tool to do this which I do not recomend. My
configure line is this one:


$ ./configure -openmp -TRACE -c++=icpc -fortran=intel -cc=icc \
-pdt=/home/username/soft/pdtoolkit-3.16/ -opari -opari_region \
-opari_construct


-openmp enables OpenMP support. -TRACE enables TRACE generation from program
execution (which is NOT generated by default). Next parameters specify that I
want to use the intel compilers to the instrumentation . Note that, for c, the
Intel compiler is not officially supported, so I specify the compiler name. The
-pdt parameter specifies where the PDT files are found (the ones we built
before). The -opari, -opari_region and -opari_construct enables the usage of
the opari[5] lib to add instrumentation for parallel regions and for
constructs.

This configure won’t generate MPI support, thus, if you want to generate MPI
instrumentation, you should take a look at the documentation (good luck).

Type make install, and it will generate the required files. The important thing
here is to get the Instrumentation makefiles generated, which should reside on
the ${arch}/lib/ subdir. You should have a makefile for each kind of tracing
you wish to use. In my case, I have two makefiles Makefile.tau-icpc-pdt-openmp-trace and
Makefile.tau-icpc-pdt-openmp-opari-trace.

You can check that your configuration is OK by runing the tau_validate script,
inside the main tau directory.


$ ./tau_validate --html --table table.html x86_64 &> results.html


Open results.html and go to the end: Green boxes means that the combination of
trace and architecture will be OK. You should have green boxes on openmp and
openmp-opari.

Code instrumentation

Assuming you are using a Makefile, if you want to add profiling information to
your code, you must include the previously-generated Makefile, and use its
variables to enable the trace. TAU_COMPILER holds the instrumentation script.
TAU_OPTIONS are compile-time values that changes the behaviour of the
instrumentation. In this case, KeepFiles preserves the intermediate files (so
you can see the instrumented code), and -optVerbose shows the compilation
process step by step (WILL be large, but useful). In this case, as we want
OpenMP regions to be automatically instrumented, we use the Opari makefile.


...
include ~/PATH_TO_TAU/x86_64/lib/Makefile.tau-icpc-pdt-openmp-opari-trace

TAU_OPTIONS = -optKeepFiles -optVerbose

CC = $(TAU_COMPILER)$(TAU_OPTIONS) icc -openmp FC =
$(TAU_COMPILER)$(TAU_OPTIONS) ifort -openmp LOADER =
$(TAU_COMPILER)$(TAU_OPTIONS) ifort -openmp
...


Run your makefile as usual, and you will get the instrumented code.

Getting the traces

Now that you have produced an instrumented binary , you just need to run it as
usual. As we are instrumenting OpenMP code, be sure to set the OMP_NUM_THREADS
variable to the number of threads you want to use.

When finished, you should have a trace file called trace.[0-9]+.trc for each
thread. If you have only one, the instrumentation didn’t detect your parallel
regions. If you have none, the code have been incorrectly instrumented!

Showing the traces

TAU comes with a good visualization tool, called Jumpshot[6]. To use Jumpshot,
you need Java. Jumpshot can read traces in Slog2 format, which is NOT the
default format of TAU. You need to convert the traces first:


# First step is to merge the per-thread traces to a single file
$ PATH_TO_TAU/x86_64/bin/tau_merge tautrace.0.0.* omp_trace.trc
# Now, produce an slog2 file. Notice the tau.edf file, generated by the
# previous tool
$ PATH_TO_TAU/x86_64/bin/tau2slog2 omp_trace.trc tau.edf -o omp_trace.slog2


This last file is the one that can be shown in jumpshot:

$ PATH_TO_TAU/x86_64/bin/jumpshot omp_trace.slog2

You will have some interesting shots of the flow of the application,
like shown in the image. Explaining the graphics is out of the
scope of this post.

OmpP

Detailed information about OpenMP regions can be shown using OmpP[7],
a specific OpenMP Profiler.

Setup and Config

Setup is quite straightforward. Just Download the last version from OmpP[7], and
edit the Makefile.defs with the values for your machine. Then, run make
and make install. You will have a directory with the OmpP installed.

Instrumenting code

Manual instrumentation is possible, like in the case of TAU, but we will focus on
automatic instrumentation. OmpP uses its own opari version to automatically do this.

To add OmpP information to your makefile, edit your makefile like in the example:


OMPP = PATH_TO_OMPP/ompp/bin/kinst-ompp
OMPPFLAGS= -IPATH_TO_OMPP/ompp/include/ -LPATH_TO_OMPP/home/rreyes/soft/ompp/lib/
..
CC = $(OMPP) icc
FC = $(OMPP) ifort
..
CFLAGS = $(OMPPFLAGS) -O3
FFLAGS = $(OMPPFLAGS) -O3


Theoretically the second one is not needed, but, at least in my case, the includes
were not added by the compilation script.

When hitting make, you may get some complains about a missing header file. It seems
to me that some error arises during the instrumentation, but the easiest way to
solve it is to copy the contents of the include dir from ompp to one of your
include directories.

Getting the traces

Run your program as usual (don’t forget about the OMP_NUM_THREADS variable), and you
will get an txt file, with detailed information about the program behaviour.

Showing information

If you wish to watch a graphical version, you must change the default behaviour of
OmpP to generate CSV files instead of ASCII. This can be accomplished by the follwing
commmand:


export OMPP_OUTFORMAT=CSV


Then, re-run your application, and you will see that, instead of a txt file, a csv
file is written.

The paraprof[8] tool, from the previously installed TAU packaged can be used to see
the results. Just load paraprof, and then open the csv file.
Documentation

Links

[0] http://www.project-text.eu/
[1] http://en.wikipedia.org/wiki/Profiling_(computer_programming)
[2] http://www.ibm.com/developerworks/library/l-gnuprof.html
[3] http://en.wikipedia.org/wiki/Amdahl’s_law
[4] http://www.cs.uoregon.edu/research/tau/home.php
[5] http://www.fz-juelich.de/jsc/kojak/opari/
[6] http://www.mcs.anl.gov/research/projects/perfvis/software/viewers/index.htm
[7] http://www.cs.utk.edu/~karl/ompp.html
[8] http://www.cs.uoregon.edu/research/tau/docs/paraprof/index.html

#!/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…

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

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

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 ;)

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í ;)