Yet Another Programming Weblog

Windows 8 Developer Preview disponible para descarga

2011-09-14T16:58:00.000+02:00

Se puede leer vía reddit que Microsoft ha hecho pública una versión de Windows 8 para desarrolladores que se puede descargar gratuitamente. Existe además la posibilidad de descargarse con ella una versión previa de las herramientas de desarrollo para dicho sistema, incluidos Visual Studio 11 Express y un SDK para aplicaciones con estilo Metro. Además se van adelantado detalles concretos de en que va a consistir WinRT, el reemplazo orientado a objetos de la API de win32 y su documentación asociada ¿Podrá retener Microsoft a la gran base de desarrolladores que usan sus productos, algo descontenta con los últimos anuncios estratégicos? ¿Logrará adaptarse con éxito a los dispositivos móviles?

Publicado originalmente para barrapunto, pero, bueno, creo que es de interés de los lectores que queden de este blog

Un Clúster con SLURM, uso y configuración

2011-06-13T10:21:00.004+02:00

He tenido la oportunidad de poner en marcha un clúster (pequeñito) y aprovecho que he hecho una presentación para sus usuarios para colgarla aquí por si resulta de ayuda a alguien o por si alguien la encuentra interesante.

Un Clúster con SLURM, uso y configuración

View more presentations from miguelolivan

Lo que todo programador de C debería saber sobre el "comportamiento indefinido"

2011-05-13T23:23:00.004+02:00

Este ha sido uno de los artículos damnificados por la caída de blogger.com y por eso no lo he puesto aquí antes, pero me gustaría reseñar este What Every C Programmer Should Know About Undefined Behavior 1/3 del blog de LLVM. No solo hace una estupenda introducción al qué y al por qué del comportamiento indefinido en C sino que apunta a una serie de artículos que merece la pena mencionar también: A Guide to Undefined Behavior in C and C++, Part 1, Part 2 y Part 3.

Del primero de esa serie, para que quede claro de qué va el asunto :)

Of course it is physically possible to pick up a basketball and run with it. It is also possible you will get away with it during a game. However, it is against the rules; good players won’t do it and bad players won’t get away with it for long.

Como se puede leer es uno de esos temas que conviene saber (y muy bien) si se pretende hacer código portable. Así que, para leer con detenimiento.

Soy un atento seguidor del blog de LLVM, pero esta vez lo he visto en el twitter de TooManySecrets

¿Testeo o especificaciones?

2011-04-29T11:59:00.003+02:00

¿Cómo se determina el comportamiento de un sistema? ¿Testeo o leyes, estándares, especificaciones...? Como siempre, es mi postura, las dos. El ejemplo surge de una incialización incompleta de un array de caracteres ¿Cómo se debería comportar? Mi teoría en principio, más o menos errónea, era que debía ocurrir lo mismo que con una copia de cadenas en C. Se copia hasta el cero terminador y ahí acaba el proceso. El resto de elementos del array indefinidos, sin inicializar. Pero estaba la duda... ¿Cómo se comporta y/o se debe comportar un sistema?

Para responder a las dos preguntas ni los test son suficiente ni lo que diga el estándar lo es. Los dos juntos pueden calmar más :)

En el punto 8.5.2.3 del estándar C++0x se habla de lo que ocurre si se proporcionan menos caracteres a la inicialización:

If there are fewer initializers than there are array elements, each element not explicitly initialized shall be
zero-initialized

Sin embargo este punto está ausente en el C++98. Los test aparentemente dicen que se suelen rellenar de ceros ¿Por qué? y ¿Podemos confiar en que siempre sea así?

Asumiendo (que quizás sea mucho asumir) que la incialización de cadenas es análoga a la incialalización en forma de lista (con llaves) esto puede tener una expliación. Según se puede leer en el punto 8.5.1.7 del C++98:

If there are fewer initializers in the list than there are members in the aggregate, then each member not explicitly initialized shall be default-initialized (8.5)
[Example:
struct S { int a; char* b; int c; };
S ss = { 1, "asdf" };
initializes ss.a with 1, ss.b with "asdf", and ss.c with the value of an expression of the form
int(), that is, 0. ]

En C++0x pensaba que quizás cambia algo pero el punto 8.5.1.7 para decir básicamente lo mismo:

If there are fewer initializer-clauses in the list than there are members in the aggregate, then each member
not explicitly initialized shall be initialized from an empty initializer list (8.5.4)

Las diferencias vienen de los mejoradas listas de inicialización de C++0x.

Leyendo todo esto yo tengo claro que no me fiaría de que el resto de los caracteres estuviesen a 0, aunque funcione así probablemente en casi todas las implementaciones... O sea, que no conviene fiarse de lo que hay después del cero terminador. Además ¿Para qué? Es tentar a la suerte...

Lecciones a aprender, al menos tal como yo lo veo:

Intentar no buscar los casos difíciles, en los que hay que consultar la ley. En ellos es probable que no todas las implementaciones la hayan leído correctamente
Conocer los estándares y especificaciones que usamos o al menos saber buscar en ellas en caso de duda
Testear. cuantas más pruebas se hagan al código más fácil es encontrar los "casos patológicos"

Lo mínimo imprescindible para controlar código fuente con subversion

2010-12-02T15:41:00.006+01:00

He realizado una presentación para ayudar a un pequeño cursito sobre subversion que voy a dar en breve. Así que publico aquí las transparencias que quizás pueden ser de utilidad para alguien. Está fuertemente inspirado en el manual Version Control with Subversion y concretamente en el apartado del ciclo básico de trabajo con svn con algunos añadidos de gráficos, buenas prácticas, programas auxiliares y algunos enlaces básicos. Por cierto, gracias a Juanjo que le ha echado un vistazo y ha detectado alguna carencia.

Sistemas de control de versiones. Introducción a svn

View more presentations from miguelolivan.

El título de la presentación es "Sistemas de control de versiones. Introducción a subversion" aunque me gustaría más haberlo titulado como este post, "Lo mínimo imprescindible para controlar código fuente con subversion" o como posibles títulos alternativos, dado el público al que va dirigido "Subversion para programadores ocasionales" o "Control de código fuente para científicos". A ver si entre todos podemos hacer que los científicos programen mejor. En beneficio de todos :)

Recuperar ficheros de texto de sistema de ficheros corrupto

2010-11-11T10:55:00.002+01:00

Hace poco he tenido que vivir una de esas historias de terror que uno teme encontrar. Pues llegó. Un sistema de ficheros irrecuperable (RAID lineal con un par de discos que no responden) e información valiosa de la que no se hacía copia de seguridad. El hecho es que la información valiosa son ficheros de texto, código fuente que se hizo de modo improvisado y fuera de repositorios ni backups y que luego se echa de menos. La solución, está claro, sería hacer backup de lo valioso, pero eso ya se empieza a ver claro por los interesados :)

Bueno, al grano ¿Cómo recuperar esos archivos de código fuente? Aquí voy a dar una solución "sencilla", pero que tiene varias precondiciones:
- Que la controladora del disco responda y que se pueda leer del dispositivo
- Que el texto a encontrar tenga menos del tamaño de un bloque del sistema de ficheros. De otro modo también vale, pero tendremos que buscar trozos y ensamblarlos.
- Que dispongamos de un sistema de ficheros donde quepa el backup. (Se podría hacer este proceso por partes o "al vuelo", jugando con el skip de dd, pero se va de la recetilla que he aplicado)

Entonces lo primero de todo (aplicable a cualquier situación donde un disco empiece a hacer cosas raras) es volcar el contenido del disco

#dd if=/dev/sd[ndev] of=/[outfile] bs=[sizeblock] conv=sync,noerror

Donde ndev es el dispositivo en mal estado. En mi caso es en buen estado pero que formaba parte de un todo en mal estado. De todos modos la opción sync, noerror trata de lidiar con errores en disco y rellenar con ceros las partes no leídas. Para este método rellenar con ceros no sería necesario porque no vamos a tratar de reparar el sistema sino hacer un método más basto, suficiente para nuestros propósitos y sin modificar el contenido del disco. Primero usamos la "magia" de strings. En principio es un comando para encontrar información relevante en código objeto, pero va muy bien para encontrar texto en binario (que es su labor básicamente). El comando que he usado es:

$ strings -n20 -a -t d outfile > outfile.str

Dónde la magia está en que consideramos como "cadena mínima". En este caso, con el n se le indica que una cadena consta de al menos veinte caracteres imprimibles. Si alguien va a usar este método puede jugar con él, sabiendo el tamaño de linea a buscar.
Posteriormente se pueden hacer greps o buscar con less sobre outfile.str con la buena noticia de que strings nos ha puesto en la primera columna (gracias al parámetro -t d) en que posición está la cadena. Ahora podemos recuperar el fichero con el mágico dd:

$ dd if=sdb1 bs=1 skip=[pos-offset] count=filesize 2>/dev/null > file.c

Evidentemente tenemos que jugar con offset (la posición en la que se encontraba la cadena encontrada en el fichero) y filesize (el tamaño del fichero). Manual y un poco a pedales, pero si los datos que hemos perdido lo merecen...

Debo notar que es una técnica no destructiva y que es complementaria a la posibilidad de reparar el sistema de ficheros. Espero que le pueda servir a alguien y también se admiten sugerencias de administradores avezados acerca de cómo reparar RAIDs lineales por soft y/o recuperar información binaria de ellos.

Electronic Arts publica EASTL como software libre

2010-10-27T22:40:00.004+02:00

Ya lo he publicado en barrapunto, pero por a alguien más le interesa y como me ha costado un poquillo hacer la entrada con sus enlaces pues la aprovecho para aquí :)

El tema es que un pobrecito hablador ha envíado un enlace con la noticia de que Electronic Arts (EA) ha publicado EASTL como software libre. La EASTL es la versión de EA de la STL, la biblioteca estándar de plantillas de C++. Fue desarrollada por EA motivados por las exigencias extremas del uso de la memoria y CPU en el ámbito de los juegos. Ha sido publicada en la web de software libre de EA en formato zip. Paul Hodge ha creado posteriormente un repositorio en github con el mismo código. En la sección de desarrollo de juegos de reddit han publicado algunos enlaces y comentarios que me han parecido interesantes y los pego a continuación.

Se puede leer allí la propia noticia, las experiencias de un desarrollador tratando de integrarla en un pequeño proyecto existente y también se apunta a una comparativa de rendimiento con otras bibliotecas como la STL estándar o como RDE STL hecha por el autor de esta última.

Actualización y bola extra: Me he encontrado con este artículo que también puede interesar a los lectores de este blog y de la noticia anterior: Start Pre-allocating And Stop Worrying. Los que vistan el blog físicamente (si es que existen) ya saben que estas cosas las suelo poner en mis compartidos de google.

Using the magic behind TFormula

2010-06-28T13:22:00.006+02:00

I wanted to evaluate conditions at runtime and I'm a happy user of ROOT. So I was thinking to use the "magic" behind TFormula. But TFormula has some limitations: the name of the variables are "x, y z, t" and I need to use arbitrary names...

Doing some research I found RooFormulaVar, a class that is part of RooFit and it does the job :) I think that RooFormulaVar lacks proper documentation, so I'm going to describe briefly how to use it to evaluate mathematical and logic expressions at runtime. Using it is easy, if you know how :)

A simple example:


RooRealVar a("a","a",3.);
RooRealVar b("b","b",7.);
RooFormulaVar plus(“aplusb”,”a+b”,RooArgSet(a,b));
//10
cout << plus.getVal() << endl;

Evaluating bitwise operations and passing a set of arguments in a more dynamic way:


TClonesArray tca("RooRealVar",2)
RooRealVar *var1 = new (tca[1]) RooRealVar("var1","var2",0); 
RooRealVar *var2 = new (tca[0]) RooRealVar("var2","var2",0);

RooFormulaVar opor("var1orvar2","var1&var2",RooArgSet(tca));

var1->setVal(2.);
var2->setVal(7.);
//2
cout << opor.getVal() << endl;

var1->setVal(5.);
var2->setVal(1.);
//1
cout << opor.getVal() << endl;

var1->setVal(8.);
var2->setVal(1.);
//0
cout << opor.getVal() << endl;

Finally, evaluating logical expressions:


TClonesArray tca("RooRealVar",2)
RooRealVar *var1 = new (tca[1]) RooRealVar("var1","var2",0); 
RooRealVar *var2 = new (tca[0]) RooRealVar("var2","var2",0);

RooFormulaVar cond("var1littvar2big","var1<1 || var2>10",RooArgSet(tca));


var1->setVal(0.);
var2->setVal(17.);

//true
cout << cond.getVal() << endl;

var1->setVal(3.);
var2->setVal(11.);

//true
cout << cond.getVal() << endl;

var1->setVal(8.);
var2->setVal(1.);
//false
cout << cond.getVal() << endl;

I hope that this blog entry will be useful and someone will save time and code. Cheers and happy coding! :)

Cómo evaluar expresiones lógico-matemáticas en tiempo de ejecución (y usar la magia de TFormula)

2010-06-28T08:57:00.010+02:00

C++ es un lenguaje poco dinámico. En otros lenguajes se dispone del propio lenguaje en tiempo de ejecución y, usando Eval o análogos, se puede evaluar cualquier expresión válida del lenguaje. Esto que puede ser una ventaja y puede ahorrar líneas de código puede ser también peligroso si se usa con poca cabeza. Como casi todo :)

Bueno, de todos modos lo que yo necesitaba no era eval como tal, sino evaluación de condiciones en tiempo de ejecución: poder decirle al programa qué condición debe evaluar en función de una serie de variables que dependen también de una configuración. Todo demasiado dinámico para que resultase sencillo de programar en C++. Había por lo menos tres alternativas, aparte de una cuarta que es la que he elegido :)

Programar una especie de ejecutor de reglas. Para el que tiene un martillo todo son clavos y si sólo te centras en el código la solución pasa por ahí. Mi intuición me dice que hiciese lo que hiciese me iba a quedar corto o introduciría bugs gordos potenciales. Mejor aprovechar algo existente...
Dejar la parte dinámica para un lenguaje dinámico. Hacer librerías que puedan ser llamadas desde dicho lenguaje. La descarté por varias razones, entre ellas el esfuerzo "librerizar" el código y la posible pérdida de rendimiento: la condición ha de evaluarse en le bucle principal y el rendimiento es un requisito clave.
Embeber un lenguaje dinámico dentro de programa. Introduciría dependencias nuevas. Sonaba seductor :), pero seguramente demasiado arriesgado

Prácticamente todas las soluciones son matar moscas a cañonazos y la que he elegido creo que es la más elegante de todas: usar una librería que ya estaba usando, cuya funcionalidad no conocía del todo (y que no está especialmente documentada...)

Así que esta entrada servirá además para mostrar una funcionalidad interesante de ROOT que podría ser usada por separado. Más o menos. El hecho es que ROOT, una librería de gestión y análisis de datos (en grandes cantidades) ya posee un evaluador de formulas que se llama TFormula. Es capaz de evaluar tanto expresiones matemáticas como lógicas o a nivel de bit. Cubre sobradamente mis exigencias. Al informarme más sobre su uso, vi que tenía inconvenientes: el nombre de las variables es fijo (x, y, z ,t) y no creía conveniente configurar las formulas basadas en esos nombres de variables o reemplazar a mano el nombre de las variables por las "por defecto". Entonces, buscando un poquito más encontré que en un sublibrería de ROOT, RooFit, existía una no muy documentada RooFormulaVar, que hace básicamente lo que yo quería, evaluar condiciones (y de paso formulas matemáticas) en base a una cadena de definición. El uso es relativamente sencillo una vez que se descubre cómo, porque no hay una documentación directa de cómo hacerlo. Un uso fácil sería:


RooRealVar a("a","a",3.);
RooRealVar b("b","b",7.);
RooFormulaVar plus(“aplusb”,”a+b”,RooArgSet(a,b));
//10
cout << plus.getVal() << endl;

Si se quiere usar con un número variable de argumentos, se puede usar otro constructor y da más juego, es un poquito más dinámico. Este ejemplo además usa operaciones a nivel de bit:


TClonesArray tca("RooRealVar",2)
RooRealVar *var1 = new (tca[1]) RooRealVar("var1","var2",0); 
RooRealVar *var2 = new (tca[0]) RooRealVar("var2","var2",0);

RooFormulaVar opor("var1orvar2","var1&var2",RooArgSet(tca));

var1->setVal(2.);
var2->setVal(7.);
//2
cout << opor.getVal() << endl;

var1->setVal(5.);
var2->setVal(1.);
//1
cout << opor.getVal() << endl;

var1->setVal(8.);
var2->setVal(1.);
//0
cout << opor.getVal() << endl;

Por último y más importante para mí, evaluar condiciones lógicas, por ejemplo:


TClonesArray tca("RooRealVar",2)
RooRealVar *var1 = new (tca[1]) RooRealVar("var1","var2",0); 
RooRealVar *var2 = new (tca[0]) RooRealVar("var2","var2",0);

RooFormulaVar cond("var1littvar2big","var1<1 || var2>10",RooArgSet(tca));


var1->setVal(0.);
var2->setVal(17.);

//true
cout << cond.getVal() << endl;

var1->setVal(3.);
var2->setVal(11.);

//true
cout << cond.getVal() << endl;

var1->setVal(8.);
var2->setVal(1.);
//false
cout << cond.getVal() << endl;

Espero que sirva a alguien y que esa persona se pueda ahorrar tiempo y código :)

Diseño del software de adquisición de datos para ANAIS

2010-05-18T11:53:00.005+02:00

Creo que puede ser de interés para la audiencia potencial de este blog las transparencias que he preparado para presentar mi trabajo de estos últimos tres meses. Se trata del diseño del software de adquisición de datos para el experimento ANAIS:

Diseño del software de adquisición de datos para ANAIS

View more presentations from miguelolivan.

No tiene que ver con la temática usual del blog pero quizás pueda ser interesante contextualizar el experimento. Se trata de replicar el experimento DAMA que dio un resultado positivo en la búsqueda de candidatos a la materia oscura, pero cuyos resultados son problemáticos en su interpretación, dado que detectores distintos que usan otro tipo de detección no han sido capaces de medir lo mismo. De ahí que el experimento deba repetirse independientemente, para corroborar que los resultados son similares. Para más información sobre la materia oscura se puede leer la wikipedia y para profundizar más en lo que se hace en el el laboratorio de Canfranc: "Dos décadas de búsqueda de materia oscura en el Laboratorio Subterráneo de Canfranc" de María Luisa Sarsa.

Publicado GCC 4.5

2010-04-15T13:05:00.002+02:00

GCC 4.5 acaba de ser publicado. En la lista de cambios se pueden leer las novedades de esta versión. De ellas las más visibles para los usuarios pueden ser las mejoras en el mostrado de errores como indicar la columna por defecto, evitar mostrar más errores en caso de falta de un fichero de inclusión o no mostrar los parámetros por defecto de las plantillas, con la ganancia de legibilidad que eso supondrá. Además viene con mejoras en las optimizaciones, en los lenguajes y plataformas soportadas y con un gran avance en el soporte experimental de C++0x además de la inclusión en la rama principal del sistema de plugins.

Al hilo del sistema de plugins ha surgido una acalorada discusión a raíz de una propuesta de incluir en un futuro por defecto el plugin DragonEgg en la distribución de GCC. DragonEgg en un plugin que reeemplaza las optimizaciones y la generación de código de GCC por las de LLVM.

La misma entrada y previsiblemente más comentarios en Publicado GCC 4.5 en barrapunto. Desde que estoy de editor por allí, por aquí se mueve menos la cosa. Espero que sepan perdonarme, pero no me olvido de este otro lugar :)

Clang ya se autocompila y GCC ya tiene sus primeros plugins

2010-02-10T00:06:00.004+01:00

Como puede leer en el blog de LLVM/Clang, el compilador con licencia similar a la BSD patrocinado por Apple:

¡Clang ha completado su primera autocompilación! Hemos compilado toda la LLVM y el propio Clang con Clang, unas 550k líneas de código en C++. Los binarios resultantes han pasado todos los test de regresión y el Clang resultante puede además generar toda la LLVM y Clang de nuevo. Este tercer Clang resultó plenamente funcional completando así el bootstraping .

Más comentarios en OSNews y reddit. En noticias relacionadas, el sistema de plugins de GCC va dando sus frutos y la fundación Mozilla ha desarrollado Dehydra y Treehydra, unos plugins para hacer análisis estático de código C++.

La misma entrada y espero que más comentarios en Clang ya se autocompila en barrapunto.

Triple arranque en un MacMini

2009-12-23T22:32:00.005+01:00

Pues conseguí un MacMini basado en Intel de 80 Gb y lo primero que decidí hacer es ponerle tres sistemas operativos ¿Para qué dejarse opciones? El caso es que instalar dos es más o menos fácil, basta con mirar el documento que describe como usar el asistente de BootCamp y/o alguna guía de cómo instalar linux en un MacIntel. Pero instalar tres no es tan sencillo, si uno de ellos es Windows (XP) y existen una serie de sutilezas con las que me he encontrado que quizás le viene bien saber a alguien que busque "por ahí" soluciones.

- Windows (XP al menos) sólo se instala bien en la última partición
- Windows (XP al menos) sólo se instala bien si existen menos de cuatro particiones

Bajo estas dos premisas, el particionado del sistema da muy poco juego, sabiendo que GPT ya crea una que no se puede obviar. Los pasos, muy resumidos, que he seguido para dejarlo funcionando con triple arranque:

- Instalar OSX
- Ejecutar el asistente de BootCamp
- Instalar rEFIt
- Reparticionar para dejar cuatro particiones
- Instalar windows en la última
- Instalar Linux en la penúltima, instalar grub
- Editar desde OSX el fichero refit.conf para que no arranque por defecto OSX
- En Debian al menos no instala por defecto un par de módulos que, en un equipo de estas características puede estar bien para monitorizar la temperatura y la velocidad del ventilador: applesmc y coretemp. Metiéndolos en /etc/modules se soluciona.

Para todo el proceso he seguido varios enlaces, pero los más importantes son:

Linux en un Mac Mini (Intel Core Duo) que va bastante bien si solo quieres instalar Linux.
Triple Boot via BootCamp en donde se explica bastante bien todos los problemas que me había encontrado previamente y cómo solucionarlos, sobre todo el famoso cannot find hall.dll que salía cuando trataba de instalar Windows en una partición que no era la última

Bueno, en el camino he aprendido algo, aunque no demasiado, de EFI, GTP y otras hierbas. Quizás haya alguien que encuentre algún error, omisión, que le resulte útil o que quiera añadir algo...

La misma entrada y algún comentario más en Triple arranque en un MacMini en barrapunto.

Facebook publica Tornado, servidor web usado en FriendFeed

2009-09-12T00:16:00.004+02:00

Como cuentan en LWN, Facebook ha anunciado el lanzamiento de su servidor web Tornado bajo la licencia Apache. Tornado es un servidor Web no bloqueante escrito en Python, diseñado para gestionar miles de conexiones simultáneas, lo que lo hace ideal para servicios Web de "tiempo real". Tornado es la pieza central de la infraestructura de "tiempo real" de FriendFeed, que tienen previsto mantener activamente. Tornado es similar a "frameworks" Web ya existentes (Django, webapp de Google, web.py) pero se centra en la velocidad y en manejar grandes cantidades de tráfico simultáneo. El código se puede obtener de tornadoweb.org. Lo comentan también en reddit, Slashdot y Hacker News entre otros.

Hay que recordar además que Facebook publicó su versión modificada de memcached, después de haber publicado parte de su código. También recordar que hace poco más de un mes que Facebook ha adquirido Friendfeed.

Más comentarios en Facebook publica Tornado, servidor web usado en FriendFeed en barrapunto

Enlaces varios (VI)

2009-07-27T23:31:00.002+02:00

Hace muchos días que no he podido escribir por aquí, así que quizás a alguien le pueda parecer interesante el dump de cosas que tenía semi-guardadas:

Sobre el lío de la eliminación de los conceptos en el borrador C++0x y su retraso en general:
Smaller is Faster (and Safer Too). De cómo chromium se auto-parchea con diferencias binarias.
Tech Or Management Beyond Age 39?
Dos sobre concurrencia y excepciones: 'Answering email about error handling in concurrent code' de Herb Sutter y 'Concurrency and exceptions' de Joe Duffy

La misma noticia y más comentarios en Enlaces varios (VI) en barrapunto

MinGW publica GCC 4.4.0

2009-06-25T23:25:00.006+02:00

El equipo de MinGW ha publicado los binarios de GCC 4.4.0 para Windows. De entre las novedades destacan un mejor tratamiento de excepciones, una versión de libstdc++ en forma de librería compartida, y soporte para TLS (thread-local storage), además de todas las novedades de la versión 4.4.0. Hay que recordar que la anterior versión soportada oficialmente era GCC 3.4.5. Más en reddit.

El manejo de las excepciones ha mejorado drásticamente debido a que se ha usado una implementación basada en DWARF, dejando de lado el viejo modelo SJLJ, que ya no estará disponible. Además con esta versión las excepciones ya pueden atravesar las fronteras de las DLL sin problemas.

La misma noticia y más comentarios en MinGW publica GCC 4.4.0 en barrapunto

memcpy y la concurrencia

2009-05-26T22:40:00.003+02:00

Si el otro día comentaban en barrapunto que en MS marcaban como peligroso el uso de memcpy hoy podemos encontrar otra razón para usarlo con precaución. En memcpy() concurrency curiosities David Dice habla de un comportamiento antiintuitivo de dicha función que sale a la luz en entornos fuertemente concurrentes: sobreescribir la misma secuencia constante en memoria puede tener valores no válidos temporalmente durante su llamada, leídos por otros threads con resultado catastrófico si no se tiene cuidado. Otro caso más en el que las abstracciones que usamos evolucionan a su manera, quizás con explicación pero con resultados que contradicen la intuición y exigen, a veces, conocer que se cuece allá abajo. (No mucho) más en reddit

La misma entrada y más comentarios en memcpy y la concurrencia en barrapunto

Avances en las implementaciones de C++0x

2009-05-05T19:48:00.002+02:00

Por lo que he leído hace un tiempo y ahora puedo comentar aquí, tanto gcc como VC++ se están poniendo las pilas en la implementación de C++0x.

Vía Drizzt, Qt 4.5.1 y gcc 4.4 leo que entre las más notables novedades de gcc4.4 se incluyen muchas características del C++0x, entre las cuales están declaraciones con auto y la inicialización de objetos con listas. Bien :) Se puede saber más en la página de status de la implementación de c++0x en gcc 4.4 donde se puede ver que la concurrencia no es una de las características más adelantadas, empezando por el modelo de memoria. Tiempo al tiempo...
En VC++ también van a buen ritmo, lo cual es bueno para el estándar, no como pasó con el VC++6 de infausto recuerdo y larga duración :). En el blog oficial de VisualC hablan de decltype (C++0x Features in VC10, Part 3) repasando esa característica de C++0x que por cierto ya está implementada también en gcc. Además apuntan a las dos entradas anteriores, que también resultan instructivas Lambdas, auto, and static_assert: C++0x Features in VC10, Part 1 y Rvalue References: C++0x Features in VC10, Part 2

Y ya que estamos en el tema dos enlaces de propina: Designing Multithreaded Programs in C++0x de Anthony Williams y GCC C++0x Features Exploration en C++ Soup! y por supuesto la imprescindible wikipedia que tiene un estupendo punto de entrada: C++0x

La misma entrada y más comentarios en Avances en las implementaciones de C++0x en barrapunto

Bitácoras de Programación: selección personal

2009-04-20T23:04:00.006+02:00

Llego tarde a la discusión generada con la entrada en la bitácora de leonidas en barrapunto que rvr pasó a portada acerca de blogs y feeds en general relacionados con la programación. Salen por supuesto muchos de los agregadores y planetas que consumo, como reddit, hacker news (uhmm, éste no sale), dzone o planeta código. Pero después de leer todas las respuestas me ha entrado la "necesidad" de hacer mi propia selección personal basada únicamente en gustos. Son bloggers que creo que son un poco distintos y, en su mayor parte combinan el bloguerío con un alto nivel técnico que dejan ver el sus posts. Allá van:

Mbpfernand0's Blog, el nuevo blog técnico de "nuestro" fernand0. El tema fundamental es la programación y la seguridad, aunque creo que no hace ningún asco a temas relacionados. Por cierto, que promete su propia selección de blogs sobre programación. Habrá que estar atento.
El valle del Viento Helado de Drizzt, el Drizzt de barrapunto también. Sistemas operativos, compiladores, administración y seguridad. Muy interesante.
.NET o no .NET, esa es la cuestión. Puedes no compartir sus preferencias tecnológicas, pero para mi es uno de los que mejor escribe y destila conocimiento y experiencia por todos los bits.

En inglés:

intertwingly de Sam Ruby. La web y sus estándares. Para mí, imprescindible.
jeffr_tech's Journal. Detalles internos del desarrollo de FreeBSD. No actualiza mucho pero merece la pena estar suscrito.
daniel.haxx.se de Daniel Stenberg. Del autor de curl y Rockbox entre otros, el blog de un desarrollador prolífico.
Coding Relic de Denton Gentry. Normalmente sobre Software embebido, pero toca otros palos.
Ulrich Drepper. El blog del mantenedor de la glib. Poco prolífico, pero para no perderse ni una sola entrada.
Nynaeve: Adventures in Windows debugging and reverse engineering. No se me ocurriría un mejor título nunca
Y por fin el imprescindible Sutter’s Mill: Herb Sutter on software, hardware, and concurrency

Ahora no se me ocurre ninguno más, pero pueden ser las prisas...

Actualización: He publicado este texto más o menos en un comentario por aquello de completar la información en su sitio. También lo pongo aquí y lo replicaré en mi bitácora en barrapunto, que a su vez se copiará en planeta código, por aquello de que lo que se replica queda y de que hay URLs que desaparecen...

Erlang 5.7/OTP R13A: soporte para Unicode, mejoras en multicore y SSL

2009-03-17T22:42:00.003+01:00

Acaba de salir la nueva versión del conjunto Erlang/OTP, en concreto la versión Erlang 5.7/OTP R13A. La nueva versión de un lenguaje y sus librerías no tiene por qué ser gran noticia, pero en este caso las novedades son tan notables que creo que merece una mención. Entre ellas se encuentran importantes mejoras de rendimiento en entornos multicore y SMP, que es especialmente importante teniendo en cuenta que una de las grandes bazas del lenguaje es su tratamiento de la concurrencia. Además destacan también el soporte para Unicode, posibilidad de usar WxWidgets a través del WxErlang (de momento en beta) y reescritura del soporte para SSL. Muchas de estas características eran necesarias para la introducción de este lenguaje más allá del entorno de las telecomunicaciones que históricamente ha sido su nicho natural. Más comentarios en reddit y Hacker News

La misma entrada y más comentarios en Erlang 5.7/OTP R13A: soporte para Unicode, mejoras en multicore y SSL en barrapunto

Aprendiendo de los errores (II)

2009-03-11T23:44:00.008+01:00

Dan J. Berstein reconoció una vulnerabilidad en djbdns y la recompensó con mil dólares y por supuesto no se han hecho esperar reflexiones acerca de la seguridad informática, su (im)posibilidad y su relación con lo disponible del código.

Entonces leo con interés, vía el nuevo subarrapunto de fernand0, un comentario en hispasec que no por evidente debe dejar de repetirse: no existe software sin fallos de seguridad, pero los que menos tienen son aquellos que han sido diseñados y programados desde su inicio con la seguridad y la simplicidad como guía.

Y ello descarta a casi todo el software y probablemente más al comercial, que tiene más presiones para añadir más y más cosas. Recordemos, que como decía Alan J. Perlis A la larga cualquier programa se vuelve rococó. Después escombros. Lo de siempre, funcionalidad contra robustez y simplicidad :)

De todos modos el caso de djbdns es también interesante por el tipo de fallo encontrado. En Hacker News comentaban que el problema era en la implementación de la compresión que usa en el protocolo DNS para sus paquetes, para eliminar redundancias. Y precisamente Bernstein había hablado negativamente del método de compresión (descrito, claro, en el RFC 1035, 4.1.4, página 30) Extractando de la crítica de Bernstein:

Un problema con la compresión DNS es la cantidad de código necesario para analizarla. Localizar de modo fiable los nombres lleva un trabajo que habría sido evitable para una caché DNS. La compresión LZ77 habría sido mucho más fácil de implementar.

Otro problema con la compresión DNS es la cantidad de código necesario para generarlo correctamente. [...]

Otro problema con la compresión DNS es que no es particularmente efectiva. LZ77 habría funcionado mejor en esos tipos de datos y funcionaría mejor con los tipos de registros que se popularizarían en el futuro [...](Y aquí habla de incompatibilidades de algunas versiones de BIND con el RFC)

Muy interesante todo el texto original, incluidas las elipsis ;) anque bastante específicas del caso DNS. Lo que no me ha quedado claro es la razón de no usar LZ77, si fue un caso de Síndrome NIH, de hackerismo o tenía algo que ver con las patentes sobre estos tipos de compresión que llevaban haciéndose desde 1984 como la del LZ78. Pero vamos como regla general parece mucho mejor usar un algoritmo conocido que inventar uno nuevo, a no ser que trabajes en eso, en innovar...

Creo que la moraleja es clara, como se dice a veces exagerando el mejor código es el que no existe sobre todo desde el punto de vista de la reducción de bugs y aún más si se trata de seguridad.

(Esto se llama Aprendiendo de los errores (II) porque ya escribí en su día Bugs antiguos y moralejas , que iba sobre lo mismo, también salía DJB y el DNS, en aquel caso con el bug/error de diseño que explotó Kaminsky)

La misma entrada y más comentarios en Aprendiendo de los errores (II) en barrapunto

Lo que Paul Graham ha aprendido con Hacker News

2009-02-26T20:24:00.007+01:00

Hacker news es un sitio de envío y comentario de noticias muy al modo de reddit (o digg o menéame), pero con temática muy definida (temática técnica, hacker en el sentido MIT ), con editores estrictos y con políticas severas de ontopic. Pues Paul Graham, su creador ha escrito What I've Learned from Hacker News, o sea, lo que ha aprendido con el sitio. Se puede estar de acuerdo o en desacuerdo en algunas cosas, pero es sin duda interesante. Extracto, lo que me ha llamado la atención:

Recuerda, la motivación original pata Hacker News fue testear un lenguaje nuevo, uno centrado en experimentar con el diseño de lenguajes, no en el rendimiento. Cada vez que el sitio se vuelve lento, me refuerzo a mi mismo recordando la famosa cita de McIlroy y Bentley:
La clave del rendimiento es la elegancia, no un batallón de casos especiales.

Y busco los cuellos de botella que puedo eliminar con menos código. Así he sido capaz de mantener un rendimiento mediocre a pesar de que el crecimiento se ha multiplicado por catorce.

Probablemente lo más importante que he aprendido acerca de la "disolución" es que se mide más por comportamiento que por usuarios. Es el mal comportamiento lo que hay que mantener alejado más que a las malas personas. El comportamiento de los usuarios es sorprendentemente maleable. Si se espera de la gente que se comporte bien tiende a hacerlo. Y viceversa.

Lo más peligroso de la portada son las que es demasiado fácil votar positivo. Si alguien prueba un nuevo teorema, le lleva tiempo al lector decidir si vota positivo o no.Un cómic divertido cuesta menos. Una crítica con un slogan como título cuesta cero, porque la gente lo vota sin ni siquiera visitar el enlace.

La forma más peligrosa de de comentario estúpido no es el argumento largo pero equivocado sino el chiste tonto. Los argumentos largos pero equivocados son bastante raros. Hay una gran correlación entre la calidad y la longitud del comentario.

[...]Visitar un foro online sólo cuesta un clic y se parece mucho superficialmente a trabajar. Puedes estar gastando tu tiempo, pero no estás parado. Alguien esta equivocado en Internet, y tú estás arreglando el problema.

Digg es conocido por su falta de trasparencia. La raíz del problema no son los tipos que llevan Digg sean especialmente furtivos, sino que usan un algoritmo equivocado para generar la portada. En lugar de subir conforme van teniendo más votos, como en Reddit, las historias empiezan arriba y las nuevas que van llegando las van empujando hacia abajo.

La razón de la diferencia es que Digg deriva de Slashdot mientras que Reddit de delicious/popular. Digg es Slashdot con votos en lugar de editores y Reddit es delicious/popular con votos en lugar de agregar a favoritos (Aún se pueden ver los fósiles de sus orígenes en sus diseños gráficos.)

Otra cosa que he aprendido de este experimento es que si vas a distinguir a las personas, hazlo bien. Este es uno de esos problemas en los que no funciona al prototipado rápido.

De hecho este es el argumento intelectualmente honrado para no discriminar a varios tipos de personas. La razón no es que todo el mundo es igual, sino que es malo hacerlo de modo incorrecto y es difícil hacerlo bien.

Yo particularmente estoy de acuerdo en casi todo. Sólo puntualizaría que hay honrosas excepciones en la correlación entre longitud y calidad. Un enlace relevante, una cita, a veces es breve pero muy relevante en la discusión. De todos modos por eso habla de correlación :)

La misma entrada y más comentarios en Lo que Paul Graham ha aprendido con Hacker News en barrapunto

¿Varios pájaros de un tiro?

2009-02-17T13:01:00.003+01:00

Vía intertwingly, el blog de Sam Ruby, me encuentro con una cita extraída de una de las listas del W3C que traduzco sin más:

Un error muy común que los ingenieros de software cometen al diseñar una arquitectura es fijarse en cinco problemas, ver lo que tienen en común e intentar resolver los cinco a la vez. El resultado es casi siempre una solución por debajo de lo estándar para todos ellos.

Sí, una tendencia común, más acusada curiosamente en los desarrolladores que se intentan preocupar por la calidad de su trabajo. Para no caer inercialmente en ella habría que evaluar lo económico del desarrollo con lo limitado de las soluciones, algo que demasiadas veces no se hace.

Me ha recordado además a un "cartel motivador" sobre el principio de responsabilidad única que vi hace poco en reddit (Aquí se pueden ver todos los carteles, por si a alguien le son de utilidad :)

Ah, ya que estoy aquí, recomiendo la lectura del blog de Sam y de las listas relativas al HTML5 para ver flames de altura :)

Actualización egórica: A través de una detección automática de referencias Sam se ha enterado de mi enlace y le ha gustado mi referencia al "cartel motivador", que le da más argumentos en el flame. Y me ha enlazado en un comentario. Nunca lo hubiera pensado :)

La misma entrada y más comentarios en ¿Varios pájaros de un tiro? en barrapunto

Epigramas sobre programación

2009-02-05T23:02:00.004+01:00

Siguiendo un enlace en technovelty he llegado a un artículo de Alan J. Perlis en el que a través de ciento treinta epigramas trató, en 1982, de capturar algunos de los aspectos más curiosos, desconcertantes y antiintuitivos de la computación en general y la programación en particular. Han pasado más de veintiséis años, pero mucha de su naturaleza creo que sigue intacta. Algunos creo haberlos leído en otra parte y supongo que al que lea esto le pueden sonar, pero me gustan, así que aquí van. Traduzco los que me han parecido mejores:

Epigramas:

7. Es más fácil escribir un programa incorrecto que entender uno correcto.

8. Un lenguaje de programación es de bajo nivel cuando sus programas requieren atención sobre lo irrelevante.

9. Es mejor tener 100 funciones operando sobre una estructura de datos que 10 funciones sobre 10 estructuras de datos.

14. A la larga cualquier programa se vuelve rococó. Después escombros.

15. Todo debería desarrollarse de arriba a abajo, excepto la primera vez.

17. Si alguien parece que está asintiendo cuando le explicas tu programa, despiértale.

19. Si un lenguaje no cambia el modo en el que ves la programación es que no merece la pena.

21. La optimización dificulta la evolución.

31. La simplicidad no precede a la complejidad, la sigue.

40. Hay dos modos de escribir programas sin errores. Sólo la tercera funciona.

57. Es más fácil cambiar la especificación para que se ajuste al programa que al contrario.

58. Los locos ignoran la complejidad. Los pragmáticos la sufren. Algunos pueden evitarla. Los genios la eliminan.

63. En computación, los invariantes son efímeros.

65. No te equivoques: los ordenadores procesan números, no símbolos. Medimos nuestro conocimiento (y control) de una actividad en la medida en la que podemos arimetizar.

75. Debido a su vitalidad la informática está a la busca desesperada de nuevos clichés: la banalidad calma nuestros nervios.

93. Cuando alguien diga "Quiero un lenguaje de programación en el que sólo tenga que decir lo que deseo hacer", regálale una piruleta.

95. No tengas buenas ideas si no eres capaz de responsabilizarte de ellas.

104. La prueba del valor de un sistema es su existencia.

115. Mucha gente encuentra el concepto de programar obvio, pero hacerlo les resulta imposible.

MetaEpigramas:

124. Los epigramas son macros, porque son ejecutados en tiempo de lectura.

125. Los epigramas cristalizan incongruencias.

127. Los epigramas desdeñan los detalles y lo hacen con intención: son una documentación de alto nivel excelente.

El lector atento verá que si se juntan la 8 y la 93 no existen lenguajes de alto nivel. Pero si se mezcla con la 125 ya no está tan claro. Bueno, para pensar un rato. Pero no demasiado, que luego hay que codificar :)

La misma entrada y más comentarios en Epigramas sobre programación en barrapunto

5 Secrets To Ninja Writing

2009-02-04T10:14:00.002+01:00

5 Secrets To Ninja Writing. (Vía reddit)

Es mucho más recomendable pinchar en el enlace anterior si conoces el blog de Jeff Atwood, Coding Horror.

Está muy logrado, sobre todo la parodia del abuso de la autorreferencia, un vicio muy de blogstar, muy feo :)

La misma entrada y más comentarios en 5 Secrets To Ninja Writing en barrapunto

El sistema de plugins cada vez más cerca de GCC

2009-01-28T22:47:00.003+01:00

Hace bastante tiempo que se viene discutiendo el porqué de la falta de sistema de plugins en el compilador libre por excelencia, GCC. Al parecer el principal problema era legal, es decir, el miedo fomentar la proliferación de plugins propietarios. Pues bien, ya se ha establecido el marco de licencias que pueden regir ese sistema, que es la nueva versión de la GCC Runtime Library Exception y con ello su desarrollo está cada vez más cerca. Además esta nueva versión de la licencia permitirá la actualización a la licencia GPLv3 de algunas librerías del propio GCC. La FSF ha proporcionado un documento con las razones para esta licencia y las preguntas más frecuentes sobre ella. Más comentarios en Slashdot: Plug-In Architecture On the Way For GCC.

Actualización: Drizzt se ha puesto de acuerdo, otra vez casualmente, para hablar del mismo tema, con algunos comentarios sobre el cambio de la licencia: El valle del Viento Helado: La arquitectura de plugins del GCC y las licencias.

La misma entrada y más comentarios en El sistema de plugins cada vez más cerca de GCC en barrapunto

Trucos gcc-céntricos y porqué no usarlos

2009-01-14T22:13:00.003+01:00

En el estupendo blog Coding Relic el autor, Denton Gentry, ha publicado recientemente dos trucos muy espectaculares pero gcccéntricos. Bueno en realidad uno es específico de la glibc y el otro sí es una extensión de gcc:

printf-acular en el que se describe cómo personalizar printf para que admita más tipos de datos que los que normalmente admite, en el ejemplo sacar direcciones MAC formateadas.
Variable Scoping with gcc, en el que se explica el (espectacular) funcionamiento de __attribute__(cleanup), que permite funcionalidades del tipo RAII de C++

Y ahora, después de ver un par de extensiones tan útiles, potentes y elegantes es cuando me toca desrecomendarlas :) Creo firmemente en el valor de los estándares y en desarrollar siempre en el nivel más estricto de estándar o visto de otro modo en el nivel más amplio de disponibilidad, siempre y cuando las soluciones sean comparables. Además, es bueno pensar en la gente que retocará el código y cabe la posibilidad de que si no se documenta resulte de sólo escritura. Yo sólo lo vería admisible en un hack puntual documentado como mínimo con neones. No obstante, hay gente que no opina lo mismo como se puede leer en Uso de extensiones del GCC en (el kernel) Linux.

La misma entrada y más comentarios en Trucos gcc-céntricos y porqué no usarlos en barrapunto

La ley de Postel y los programadores

2009-01-07T10:34:00.003+01:00

El otro día leí un comentario acerca de las diferencias en la admisión de parámetros entre los comandos en BSD y GNU. Según se comentaba, los segundos son menos estrictos y se tragan más cosas. El comentarista añadía sobre el comportamiento de la GNU userland: "me gusta a pesar del programador que hay en mi".

Y, por lo que sea, me ha parecido muy revelador: a los programadores no nos gusta, desde un punto de vista egoísta, lo que nos supone la ley de Postel, el principio de robustez. Aquello de ser liberal con lo que se admite como válido da repelús. Y creo que hay más de un motivo:

Nos gusta la precisión. Si somos estrictos en lo que generamos ¿No vamos a exigir lo mismo?
Se suele generar más código para tener el cuenta el ser liberal: más trabajo y más testeo
El comportamiento de nuestro soft no es tan rígido lo que choca con nuestro gusto por las especificaciones precisas, sencillas y breves.

Lo que a veces no vemos es que ser menos estricto mejora la robustez y eso al usuario final, como es normal, le encanta aunque le de igual si se es estricto, si Postel o Dracón, los estándares y todo lo demás.

Este efecto se nota más en ecosistemas heterogéneos con lo que la integración de ese software puede ser más fácil en entornos menos controlados. Así que otra cosa más a pensar antes de desarrollar ¿Nos compensará a la larga el esfuerzo de ser menos estrictos?

La misma entrada y más comentarios en La ley de Postel y los programadores en barrapunto

Facebook publica su versión modificada de memcached

2008-12-13T22:53:00.003+01:00

[Vía reddit] Facebook acaba de publicar su versión de memcached, el sistema de cachés genéricas más usado en aplicaciones web, tras hacer modificaciones para afrontar sus necesidades de rendimiento y escalabilidad. Las modificaciones principales han sido entre otras la eliminación de un buffer por conexión en favor de un pool, reducción de bloqueos innecesarios para un mejor rendimiento en máquinas multicore y el uso intensivo de UDP. El resultado final ha sido la posibilidad de gestionar 200.000 peticiones UDP por segundo con una latencia media de 173 microsegundos. Han subido los cambios a GitHub: facebook-memcached y esperan que los cambios sean incorporados al memcached oficial. Curiosamente hemos hablado recientemente por aquí de memcached en Un vistazo al interior de memcached.

Actualización: Olvidé mencionar que habían toqueteado el kernel :/ JAM hace muy bien resumen de esos apaños
Parece relevante también comentar lo que dicen en High Scalability sobre el memcached de Facebook y las conclusiones que se pueden sacar:

A summary of potential strategies:
Profile everything. Problems are always specific. The understanding of the problem must be specific. The fix must be specific.
Burn profiling into your regression tests. Detect when and where performance tanks as a regular part of your build.
Use resources in proportion to what grows slowest. This requires multiplexing, but at least your resource usage is more predictable and bounded.
Batch work. When you have the CPU do all the work you possibly can in the quantum or the whole system grinds to a halt in processing overhead.
Do work and maintain resources per task. Otherwise locking for shared resources takes more and more time when there's less and less time to do the work that needs to be done.
Change algorithms. Sometimes you simply need to do things differently. Tweaking will only get you so far.

La misma entrada y más comentarios en Facebook publica su versión modificada de memcached en barrapunto

El código fuente como documento definitivo del diseño

2008-12-09T12:31:00.003+01:00

Se trata, cómo no, de Code as Design: Three Essays by Jack W. Reeves. Son unos ensayos muy ilustrativos de la naturaleza particular del desarrollo de software, que por usar la palabra diseño de un modo no usual acaban resultando muy polémicos, pero a mi me parecen más bien esclarecedores. Se recomienda leer enteros antes de opinar :P

Suelo aprovechar cualquier mención para volver a enlazarlo y esta vez ha sido Ricardo Galli en "Los problemas derivados del abuso de las analogías" quien me da la oportunidad de volver a hacerlo :)

Se ha hablado de ellos por aquí en El código fuente visto como diseño y POO, el código como diseño y más cosas.

La misma entrada y más comentarios en El código fuente como documento definitivo del diseño en barrapunto

Memoria transaccional ¿Sólo un juguete para investigadores?

2008-11-27T11:36:00.005+01:00

En Software Transactional Memory: why is it only a research toy? de Calin Cascaval et al. se repasan algunas de las razones por las que, tras unos años de investigación, la memoria transaccional no ha dado el salto para ser usada en otros entornos. Se nombran sobre todo razones de rendimiento, de usabilidad (semántica confusa) y de interacción con sistemas que no la usan. No obstante no todo el mundo se da por vencido y por ejemplo Larry O'Brien escribe en Cascaval et al.'s skepticism on transaction memory una visión un poco más optimista indicando que aún queda espacio para la investigación y la optimización. ¿Acabaremos usando STM o morirá antes de nacer?

La misma entrada y más comentarios en Memoria transaccional ¿Sólo un juguete para investigadores? en barrapunto

Universos paralelos, cuerdas y divulgación científica

2008-11-21T09:28:00.008+01:00

Hay un debate, apasionante y por supuesto no resuelto acerca de cómo divulgar la ciencia, de cómo equilibrar la precisión de lo que se cuenta con lo entretenido de la forma.

Pues bueno, a mi me parece que esto en la divulgación de la ciencia más básica es especialmente importante. Suele uno leer en periódicos, revistas y últimamente en blogs artículos sobre la teoría de cuerdas y sobre universos paralelos sin hacer la menor mención acerca de lo especulativo del asunto. Por eso me ha gustado mucho un apunte de Clifford Johnson en el que lo explica estupendamente (vía Not Even Wrong de Peter Woit) Habla de su participación en un programa de divulgación sobre universos paralelos. Cito y "traduzco":

Para ser sincero estoy un poco preocupado porque es un tema que puede ser aprovechado muy fácilmente por chiflados por personas sensatas por igual, y es, de diversos modos, alimento para mucha charlatanería y sinsentido místico. Cualquier programa de ciencia sobre este tipo de material tiene que ser doblemente -triplemente- cuidadoso, para no dar a la gente una excusa para decir que "los científicos han comprobado esto".

¿Por qué estoy un poco preocupado? Bueno, yo no he visto un montaje final del espectáculo y y no me quiero exceder, pero un primer montaje en bruto que he podido ver sufre de un problema que estos programas pueden tener a veces: un conjunto de científicos en activo muy cuidadosos al hacer comentarios acerca de lo que se conoce, de lo desconocido, de lo que es probable y de lo que es poco probable, y así sucesivamente, y después mucha de esa cautela puede ser socavada por la intercalación de sus observaciones con fragmentos del favorito de cualquier cineasta de la física documental, del tipo que puede ser invocado para decir cosas salvajes y maravillosas - Michio Kaku.

Por favor, no me malinterpreten. No tengo nada en contra de Kaku, me parece un muy buen tipo, y creo que ha realizado un excelente y divertido trabajo para este tipo de programas (tales como el documental sobre Einstein de la otra noche ), pero hay momentos en que sus observaciones más, ermmm, emocionadas e imprudentes pueden ser colocadas en un lugar en el programa que no ayuda en nada a ser prudente con la ciencia. A menudo (quizás siempre?) no es su culpa, un director que no se da cuenta de cómo un detalle puede ser crucial llega a un punto en el que debe elegir entre la inserción de:

* (a) un fragmento de alguno de nosotros que tratamos de ser cuidadosos y no hacer declaraciones equivocadas y/o sensacionalistas, y
* (b) un fragmento un distinguido caballero con un entusiasmo contagioso, agitando sus brazos y diciendo cosas que suenan maravillosas

...Y 99 veces de cada 100 va a elegir la opción (b) si ninguna de las personas de (a) están ahí para orientarle. Esta es, por supuesto, la razón por la que siempre espero [...] que estos espectáculos se realicen de un modo colaborativo entre científicos y cineastas[...]

Hace ya unos días, bastante relacionado con esto, rvr en un par de entradas, El nivel de la divulgación científica (I) y El nivel de la divulgación científica (II) repasaba el mismo problema a la inversa, con la tesis de que debe haber sitio también para la divulgación más superficial.

Sin estar en desacuerdo con esta tesis si debo reconocer que me gustaría que hubiese menos confusión entre ciencia aceptada y especulación. Creo que la diferencia debería ser subrayada por todo el mundo y que conceptos como Método Científico, Reproducibilidad y Falsabilidad tuviesen mayor eco. Cuestión de educación, supongo.

Y bueno, por acabar y por ser algo constructivo recomendar una entrada sobre el tema en Ecos del futuro (que he conocido hace poco, muy bueno): La interpretación de los universos múltiples, en la que sí queda claro lo que es especulativo y lo que no, y porqué.

La misma entrada y más comentarios en Universos paralelos, cuerdas y divulgación científica en barrapunto

Varios sobre concurrencia y rivales de GCC

2008-11-17T18:38:00.005+01:00

Ración de varios variados:

Parallel Programming with Transactional Memory de Ulrich Drepper en el que hace una buena introducción de la memoria transaccional y de su estado actual, que es más bien de investigación, de su posible futuro y de sus posibles problemas, sobre todo de rendimiento. Por cierto, que Clojure usa STM, a ver si algún día le puedo hincar algún diente... (Se ha tratado el tema de la memoria transaccional más veces por aquí)

Otro artículo introductorio de ACM Queue: Erlang for Concurrent Programming de Jim Larson

Cilk++ 1.0 se liberará con una licencia dual, una open source y otra comercial. Cilk++ es un sistema que promete acercar el paralelismo a las masas. Ya veremos, pero una herramienta libre más no está mal.

Things that go Clang in the night: LLVM 2.4 released en Ars Technica. Un poquito más profundo que las notas de prensa que se apuntaban por aquí en Publicado LLVM 2.4 pero tampoco para tirar cohetes.

Y por último pcc, the Portable C Compiler, busca, con el apoyo de BSD Fund financiación para alcanzar una versión de ppc 1.0 usable y poder tener un entorno de desarrollo BSD completo (y puro :) )

Movidillo parece el micromundo de los compiladores libres, veremos si la competición les sirve para mejorar a todos ellos.

La misma entrada y más comentarios en Varios sobre concurrencia y rivales de GCC en barrapunto

Publicado LLVM 2.4

2008-11-11T14:02:00.000+01:00

Acaba de ser anunciada la versión 2.4 de LLVM (Low Level Virtual Machine). A LLVM y su compilador asociado clang se les ha querido ver como un competidor de GCC, en parte por su licencia BSD, por su diseño más modular, por su novedoso enfoque de las optimizaciones y por el apoyo de Apple. La versión 2.4 trae una buena cantidad de novedades entre las que destacan la mejora en la generación de código, compilación más rápida y soporte para la arquitectura PIC16. En el propio anuncio se apunta a una serie de presentaciones y vídeos para saber más. [Vía reddit]

La misma entrada y más comentarios en Publicado LLVM 2.4 en barrapunto

Un vistazo al interior de memcached

2008-11-10T17:07:00.002+01:00

Leo en El valle del Viento Helado un artículo acerca de la arquitectura interna de memcached. memcached es un sistema de cachés genéricas muy usado en aplicaciones web. En el artículo se repasa tanto la elección de libevent como sistema de gestión de eventos sobre descriptores de fichero, el uso de funciones de entrada/salida no bloqueantes y sobre todo una gestión de memoria basada en un slab allocator. Contiene además enlaces con más información sobre el tema aunque como siempre la información última está en el código fuente.

La misma entrada y más comentarios en Un vistazo al interior de memcached en barrapunto

Completado el borrador de C++0x

2008-10-29T13:05:00.003+01:00

Como comenta Herb Sutter en su blog, se ha publicado el borrador (pdf) de C++0x que se pasará a la votación internacional. Creo que es una buen noticia para todos los usuarios de C++, porque como dicen en reddit, map<string, string>::iterator, tu larga década de terror se ha acabado :) Además, y no menos importante, toda una serie de características como rvalues, lambdas, conceptos, librería de operaciones atómicas, librería de threads, soporte para expresiones regulares...

Y uno de los arreglos más importantes, el modelo de memoria. Del borrador:

The fundamental storage unit in the C++ memory model is the byte. A byte is at least large enough to contain any member of the basic execution character set and the eight-bit code units of the Unicode UTF-8 encoding form and is composed of a contiguous sequence of bits, the number of which is implementationdefined.
The least significant bit is called the low-order bit; the most significant bit is called the high-order bit. The memory available to a C++ program consists of one or more sequences of contiguous bytes. Every byte has a unique address.
[...]
A memory location is either an object of scalar type or a maximal sequence of adjacent bit-fields all having non-zero width. [...] Two threads of execution can update and access separate memory locations without interfering with each other.

Enhorabuena a los premiados. Ahora falta que los implementadores hagan su trabajo. MS VC++ parece que va avanzando para llegar a VC++2010. (Estoy seguro que la coincidencia del borrador de C++0x y la publicación este post en el blog de VC++ no es casual...) gcc, aunque más lento, también va avanzando y ya se pueden probar algunas características.

La misma entrada y más comentarios en Completado el borrador de C++0x en barrapunto

Varios sobre concurrencia y el rol de los 'arquitectos'

2008-10-23T09:48:00.003+02:00

Comenzando por el minipost de Miguel de Icaza en el que habla de programación paralela y siguiendo enlaces:

Design Considerations For Parallel Programming de David Callahan
Solving 11 Likely Problems In Your Multithreaded Code de Joe Duffy
Repasando el blog de este último también apunta a .NET Matters: False Sharing
Y también del blog de Joe Duffy, y aunque no es sobre concurrencia y probablemente sean obviedades, me ha gustado A few thoughts on the role of software architects

La misma entrada y más comentarios en Varios sobre concurrencia y el rol de los 'arquitectos' en barrapunto

Las matemáticas 'innatas' en el ser humano

2008-10-14T23:21:00.003+02:00

Nota: Para los lectores de PlanetaCódigo. Esta es una entrada sobre ciencia y matemática y no sobre programación. Si no te interesa no tienes más que saltártela :)

Ayer en la cola de pendientes de menéame leí una noticia demasiado escueta que hablaba de niños aborígenes australianos capaces de contar sin números. Rebuscando un poquito encontré la nota de prensa original, que por lo menos es un poco más explicativa.

Y es que este tipo de estudios sacan resultados que al menos a primera vista pueden resultar antiintuitivos: nuestra capacidad matemática parece estar más allá de nuestra capacidad verbal. O dicho de otro modo, parece que la evolución nos ha hecho más viables con un pequeño coprocesador matemático, aparentemente no específica a nuestra especie porque, como decía otro estudio de hace un tiempo, los monos tienen células dedicadas a contar.

También acerca del equipamiento matemático del ser humano se oyó hace un tiempo (quizás Log or Linear? Distinct Intuitions of the Number Scale in Western and Amazonian Indigene Cultures) que las escalas logarítmicas pueden resultar más intuitivas que las lineales a un humano sin formación cultural y/o matemática.

Me parecen muy reveladoras este tipo de investigaciones ¿Conocéis más publicaciones y/o artículos de este estilo? ¿Qué opináis de la relación entre el ser humano y la matemática?

La misma entrada y más comentarios en Las matemáticas 'innatas' en el ser humano en barrapunto

Reescribiendo una cola sin bloqueos

2008-09-30T10:17:00.001+02:00

Herb Sutter se quejó en Lock-Free Code: A False Sense of Security(*) de lo difícil que es escribir código sin bloqueos incluso para expertos y lo hizo poniendo un ejemplo de una implementación errónea de una cola. Ahora ha retomado el tema para demostrar como sería una implementación correcta en Writing Lock-Free Code: A Corrected Queue.

(*) Hablamos de este artículo en Varios sobre concurrencia: los peligros de 'Lock-Free' y JVM

La misma entrada y más comentarios en Reescribiendo una cola sin bloqueos en barrapunto

¿Cómo funcionan los cierres de exclusión mutua?

2008-09-29T16:26:00.003+02:00

Vía reddit veo un artículo muy didáctico de como funcionan internamente los cierres de exclusión mutua que usamos diariamente y así hacernos a la idea de lo que hay debajo.

La misma entrada y más comentarios en ¿Cómo funcionan los cierres de exclusión mutua? en barrapunto

"Patrones en programación paralela" por Ralph Johnson

2008-09-29T15:25:00.001+02:00

Ralph Johnson, coautor del conocidísimo Design Patterns dió una charla sobre patrones en programación paralela: Parallel Programming Patterns, que está disponible online en un flash con las transparencias integradas para un mejor seguimiento. [Vía Sutter's Mill]

La misma entrada y más comentarios en "Patrones en programación paralela" por Ralph Johnson en barrapunto

Un vistazo al código de chrome

2008-09-03T19:07:00.007+02:00

Una de los aspectos que más me ha interesado de chrome es su arquitectura, aquello de ejecutar un proceso por pestaña para dejar que el sistema operativo haga unos de los trabajos para los que está diseñado: aislar procesos independientes y gestionar la memoria. Entonces he decidido a echarle un vistazo al código, que para eso está ahí ;)

Lo primero que hay que decir es que el IPC se hace mediante pipes con nombre, como parece que debería ser, aunque sea una de esas características de los SO en decadencia, o por ser más preciso, menos de moda. El documento que describe el IPC en chromium es escueto así que he hecho una inmersión en el código, aunque superficial, sobre todo para encontrar detalles de implementación. Los mensajes se gestionan con una clase ChannelProxy (definida en src/chrome/common/ipc_channel_proxy.h) Las pipes se gestionan con la clase Channel (mismo directorio, icp_channel.h) Curiosamente está implementada llamando directamente a la API de win32, ella misma hace de capa de abstracción y de interfaz a implementar.

Otro aspecto que me llamaba mi curiosidad es la serialización de los mensajes y lo hacen especializando Read, Write y Log de ParamTraits (en src/chrome/common/ipc_message_utils.h) a la estructura o tipo de dato en concreto. La serialización los tipos de datos primitivos están en Pickle (src/base/pickle.cc), que es base de Message (src/chrome/common/ipc_message.cc)

Como uno de mis intereses es la multiplataforma he buscado como solucionaban la gestión de threads y procesos. Acerca de los threads se han creado un interfaz sencillo en src/base/platform_thread.h con dos implementaciones, platform_thread_win.cc y platform_thread_posix.cc. Cabe destacar el siguiente comentario de este último fichero:

The POSIX standard does not provide for naming threads, and neither Linux
nor Mac OS X (our two POSIX targets) provide any non-portable way of doing
it either. (Some BSDs provide pthread_set_name_np but that isn't much of a
consolation prize.)

Que creo que dice algo de su política y no se si gustará mucho a los BSDros... El buceo por la gestión de procesos ha sido un poco decepcionante porque sólo existe un process_util::LaunchApp que básicamente llama a un CreateProcess de nuevo de la API de win32. Seguramente han ido pensado previamente en los interfaces y solo están a falta de la implementación en distintas plataformas, pero da una sensación de trabajo a medias, quizás reflejo de un proyecto real (en contraposición de una prueba de concepto) saliendo de su fase temprana. Cabe preguntarse cuanto les costará implementar y testear esas funcionalidades... Ah, calla, que somos millones los betatesters.

(Actualización) Un tímido buceo en src/net/base me dice que el código de red es muy windowscéntrico, con muchas inclusiones de winsock2.h, incluso en cabeceras :/ aún les queda trabajillo por delante. Los interfaces de las clases parecen bien definidos y eso les ahorrará trabajo, pero es bien sabido que un interfaz no es válido y está maduro hasta que no funciona en todas la plataformas a las que se dirige...

Uhmmm, acabo de ver un enlace de donde se baja las fuentes que se suponen del desarrollo en linux. Seguiremos informando, pero ya sólo esta distinción de obtención de fuentes no da buena espina...

(Actualización2)Ya lo he bajado pero es básicamente el mismo código. Me debo estar perdiendo algo, porque sino está muy verde...

(Actualización3) Leo en kriptópolis que Chrome usa CSP en lugar de PKCS :O No hay rastro de ningún PKCS (11 por ejemplo, el que usa El DNIe) ni de NSS (la librería criptográfica de Netscape que usa firefox) Me temo que la portabilidad no se la han tomado en serio o quieren que se la hagan otros... Alucino.(fin actualizaciones).

Desde el punto de vista gráfico he visto que tiene muchas de dependencias de la WTL, lo que dice también poco de la portabilidad en primera instancia. Ya veremos a ver como solucionan ese temilla, aparentemente con lo que figura en src/base/gfx. No obstante hay pocos restos de WTL en los .h, así que quizás ya van bastante adelantados... Misma sensación de a medias.

Seguro que habría mucho más que decir, sobre todo del diseño e implementación de JavaScript, V8 pero creo que se escribirá de eso suficiente (ya se ha escrito mucho de su eficiencia, veremos cuanto hay de hype) y de temas relacionados como la ejecución de ruby sobre V8... Ains que bien se lo hace google ;)

La misma entrada y más comentarios en Un vistazo al código de chrome en barrapunto

(Aún otra) entrevista (más) a Stroustrup sobre C++0x

2008-08-22T09:02:00.002+02:00

Veo, vía Slashdot, aún otra entrevista más a Bjarne Stroustrup sobre C++0x: The State of the Language: An Interview with Bjarne Stroustrup por Danny Kalev. La verdad es que me ha parecido mejor que la media y diría que es un buen repaso introductorio a esta nueva estandarización de C++. (Las entrevistas a Stroustrup son ya un clásico en esta bitácora :) )

La misma entrada y más comentarios en (Aún otra) entrevista (más) a Stroustrup sobre C++0x en barrapunto

Varios sobre concurrencia: los peligros de 'Lock-Free' y JVM

2008-08-13T22:26:00.005+02:00

Ración de varios sobre concurrencia:

"Lock-Free Code: A False Sense of Security" de Herb Sutter que viene a decir algo que por aquí intuíamos:
[Lock-free code is] hard even for experts. It’s easy to write lock-free code that appears to work, but it’s very difficult to write lock-free code that is correct and performs well. Even good magazines and refereed journals have published a substantial amount of lock-free code that was actually broken in subtle ways and needed correction.
es decir, entre otras cosas, recordar ser humildes.
Si aún siendo humildes queremos saber más sobre estos temas podemos echarle un vistazo a "Just What-the-Heck is a 'wait-free' algorithm?" de Cliff Click en el que repasa este tipo de algoritmos que según los que saben de ésto aún son más difíciles de codificar que los 'lock-free' (son un subconjunto de ellos no obstante)
The Java Memory Model in 500 Words Un breve resumen, casi chuleta, del modelo de memoria en Java.
Si lo que nos interesa son más las implementaciones que las especificaciones podemos echar un vistazo a The Hotspot Java Virtual Machine, una completa presentación con detalles de implementación de dicha máquina virtual. Repasa compilación, sincronización, recolección de basura y posibles direcciones de investigación.

La misma entrada y más comentarios en Varios sobre concurrencia: los peligros de 'Lock-Free' y JVM en barrapunto

Sobre los aspectos estéticos de la programación

2008-08-04T11:07:00.007+02:00

Jonathan Edwards en una entrevista en un webzine de reciente creación, Wheel Me Out, ha tocado uno de los temas que le hacen a uno seguir teniendo pasión por esto de la programación. Cito (traduciendo) lo que más me ha gustado(*):

Veo la programación como una actividad profundamente creativa, pero no exactamente como una forma de arte en el sentido usual del término. Los programas no expresan sentimientos humanos entonces no creo que tengamos derecho a llamarlos arte. Los programadores desarrollan cierto sentido estético que hace de un programa bien diseñado un programa bonito, pero es una clase de belleza fría y matemática. De hecho sostengo que la estética puede ser una mala guía para los programadores.

[...]

La belleza de la programación es intelectual. Es el placer que sentimos cuando un problema complejo de pronto se revela bastante simple visto desde la perspectiva adecuada. Esta sensación de profundidad es la que motiva a algunas personas a ser matemáticos o físicos. [...] Programar es también un tema de poder. Es la lucha del programador para crear orden del caos. Somos como pequeños dioses en nuestros universos de bolsillo. Estamos limitados solo por nuestra imaginación. Desgraciadamente nuestra imaginación es más limitada de lo que nos gusta admitir, lo que en mi opinión es el trágico defecto de la programación, aunque esta opinión no es compartida ampliamente.

Obviamente, se resalta el aspecto más sublime, cuando todos los que nos dedicamos a esto sabemos que el día a día puede ser bastante distinto, bastante poco elevado. No obstante, en lo que a mi respecta me sigue enganchando la posibilidad de simplificar lo complejo, de encontrar una buena solución y el poder de hacerlo en el universo de bolsillo :)

(*)Pedí permiso para traducirlo íntegramente y me pidieron la dirección del blog. No me contestaron después. Espero que me ampare el derecho de cita...(Actualización: desde Wheel Me Out me han dado permiso para traducirlo, pero creo que con el extracto ya traducido será suficiente. Gracias al webzine de todos modos por el permiso y por generar la entrevista)

La misma entrada y más comentarios en Sobre los aspectos estéticos de la programación en barrapunto

Varios sobre D

2008-07-29T17:46:00.003+02:00

Se acumulan cosillas sobre D que me he ido guardando, así que, haciendo un dump:

El enlace que me ha hecho juntarlos todos: "Grafting Functional Support on Top of an Imperative Language - How to D 2.0 implements immutability and functional purity" de Andrei Alexandrescu. Muy interesante aunque no se vaya a usar D ni programación funcional por aquello del manejo de los invariantes y su aproximación a la concurrencia, además de hacer notar las "limitaciones" del const de C++. Más en reddit.
The A-Z of Programming Languages: D, entrevista a Walter Bright, el creador de D, extendida en reddit con respuestas del propio Bright, asiduo por esos lares.
También vía reddit, D Postmortem, en el que se analiza los problemas que se encontró un usuario de D en un proyecto no trivial. También tuvo muchas respuestas en reddit, algunas también del equipo de desarrollo de D, Bright incluido

La misma entrada y más comentarios en Varios sobre D en barrapunto

Bugs antiguos y moralejas

2008-07-12T23:39:00.004+02:00

A veces coinciden en el tiempo sucesos de los que se puede sacar una especie de moraleja común y la serie reciente de errores con muchísimos años de historia me parece una de ellas. La grave vulnerabilidad en el protocolo DNS, que ha hecho actualizar a toda internet ha sido el ejemplo más claro, pero no el único y las tres historias son muy instructivas...

El primero, hace unos dos meses detectó un bug de 25 años en los BSD, en seekdir()[1] en el que, en algunos casos seekdir() no daba el resultado correcto. Como comentan en la propia historia, un bug muy difícil de encontrar y muy fácil de corregir.

El segundo es un bug con 33 años de antigüedad en yacc, encontrado por Otto Moerbeek[2], quien curiosamente también ha tenido un papel muy relevante en el descubrimiento del bug anterior.

El último es más peliagudo: problemas de diseño en el protocolo DNS permitían a un atacante hacer DNS cache poisoning de modo más efectivo que anteriores técnicas[3]. El descubridor de la vulnerabilidad, Dan Kaminsky, hace comentarios muy interesantes al respecto (las negritas son mías):

DJB was right. All those years ago, Dan J. Bernstein was right: Source Port Randomization should be standard on every name server in production use.

There is a fantastic quote that guides a lot of the work I do: Luck is the residue of design. Dan Bernstein is a notably lucky programmer, and that's no accident. The professor lives and breathes systems engineering in a way that my hackish code aspires to one day experience. DJB got "lucky" here — he ended up defending himself against an attack he almost certainly never encountered.

Such is the mark of excellent design. Excellent design protects you against things you don't have any information about. And so we are deploying this excellent design to provide no information.

Es muy curioso seguir los enlaces, porque la historia del parche es muy poco común y puede enseñar de la parte técnica y de la parte social del ecosistema internet.

Creo que la moraleja de todos ellos es clara, sobre todo leyendo las historias. Pero por recopilarlas (aún a riesgo de decir obviedades):

El DNS o SMTP son protocolos pensados para una Internet que ya no existe: ninguno de ellos se diseñó pensando en la seguridad.
Que lleve muchos años funcionando no significa que funcione en todas las circunstancias.
Si se va a usar un software de un modo poco usual, aunque sea uno muy estable, conviene prepararse mentalmente para encontrar bugs.
Los errores de diseño son más difíciles de arreglar (si es posible)
Un buen diseño sobrepasa las expectativas del diseñador.
Abierto no implica seguro, ni libre de fallos (Cerrado tampoco, claro[4])

[1]Un buen resumen en castellano, con interesantes conclusiones en El valle del viento helado "Un bug de 25 años en los BSD: seekdir()"
[2]Comentado en barrapunto en Corregido un error de hace 33 años en Yacc
[3]Comentado en barrapunto en Un agujero de seguridad en el protocolo DNS causa gran alarma
[4]Me ha llamado la atención el caso de un bug casi trivial en el en interop de .NET desde C++ nativo que lleva la menos seis años sin ser resuelto. No es el único caso ni el más grave ni la única empresa donde sucede eso, por supuesto. Sólo me ha parecido un ejemplo ilustrativo...

La misma entrada y más comentarios en Bugs antiguos y moralejas en barrapunto

Parámetro "lo digo en serio" en Content-Type para IE8

2008-07-03T23:06:00.005+02:00

Pues esa es la propuesta que se puede leer en el blog de desarrollo del Internet Exporer 8: añadir un authoritative=true al Content-Type, o sea, fiarse de cual es el tipo de contenido que está proporcionando el servidor, pero sólo si lo dice en serio...

Por supuesto esta propuesta ha levantado bastantes reacciones. Unos, como Sam Ruby en authoritative=true, lo ven desde el punto de vista pragmático como un mal menor al evitar content-sniffing. Otros, como Daniel Stenberg en This is the type and I mean it se lo toman con humor. Más en las listas de la w3c y en reddit: Microsoft's "I mean it" content-type parameter

La misma entrada y más comentarios en Parámetro "lo digo en serio" en Content-Type para IE8 en barrapunto

Lenguajes de la A a la Z: Entrevistas

2008-06-26T14:03:00.006+02:00

En Computerworld están publicando extensas entrevistas acerca de un montón de lenguajes de la A a la Z. La verdad es que había visto alguna referencia, pero después de la de Stroustrup (y sus repercusiones en Slashdot y reddit) le he prestado más atención y parece que pueden ser bastante curiosas. También en LtU - The A-Z of Programming Languages prometen seguirles la pista, enlazando a su vez a las pasadas:

Ada - S. Tucker Taft
ASP.NET - Microsoft
AWK - Alfred V. Aho
Bash - Chet Ramey
C++ - Bjarne Stroustrup
Forth - Charles Moore (Actualizado (27/06/08) -No creo poder seguir el ritmo de actualizaciones ;)-)

Actualización: La entrevista a Stroustrup también se comenta en la portada de barrapunto

La misma entrada y más comentarios en Lenguajes de la A a la Z: Entrevistas en barrapunto

Propuesta para introducir C++ en gcc

2008-06-20T09:52:00.004+02:00

Volviendo al tono un poco menos noticioso de esta bitácora, me gustaría referenciar la propuesta de Ian Lance Taylor de permitir determinadas características de C++ en el código de gcc, sobre todo aquellas que permiten hacer el código más compacto y mantenible. Nombra explícitamente STL, polimorfismo y punteros inteligentes en contraposición a la recolección de basura que se usa en gcc. Hay que hacer notar que la propuesta debería ser aprobada (no sin antes haber pasado por el adecuado flame C vs C++) aunque Ian propone crear una rama gcc-in-c++ para experimentar.

Me ha parecido una propuesta muy razonable, con una exposición muy clara de lo que se ganaría con el cambio. Es precisamente el (moderado) uso de las características de C++ lo que me ha parecido más reseñable. C++ es un lenguaje grande y no todas son adecuadas a todos los problemas, con lo que hay veces que es sano delimitar como se usa. Esto da lugar no obstante a estándares de codificación con casi obsesivo nivel de detalle, pero de los que se puede aprender si se lee con atención crítica.

Por cierto que para evitar dependencias indeseadas (y que C++ se convieta en el caballo de troya que potencialmente es) se propone un enlazado estático con la libstdc++. No sé que opinará Ulrich Drepper.

Se puede leer más sobre el tema en el propio blog de Ian , en reddit (posteado por un servidor), en LWN y (con poco éxito de crítica y público) en menéame.

La misma entrada y más comentarios en Propuesta para introducir C++ en gcc en barrapunto

Reddit abre su código

2008-06-18T18:19:00.002+02:00

Reddit, el sitio colaborativo de promoción de enlaces, que cuenta con una gran sección de programación, ha abierto su código, disponible en code.reddit.com. La licencia elegida ha sido la Common Public Attribution License (CPAL)

La misma entrada y más comentarios en Reddit abre su código en barrapunto

code_swarm: visualización del desarrollo de proyectos libres

2008-06-17T12:42:00.006+02:00

Acabo de ver vía slashdot (y me lo perdí en reddit) un proyecto de visualización del desarrollo de proyectos libres: code_swarm. A partir del control de fuentes genera vídeos en los que se puede seguir la evolución histórica del desarrollo de Python, PostgreSQL, Eclipse o Apache httpd. El autor promete además liberar el código para que cualquiera lo pueda aplicar a otros proyectos. Bonito, hipnótico y hasta revelador...

Actualización: Ya ha liberado el código en codeswarm - Google Code. A disfrutar...

La misma entrada y más comentarios en code_swarm: visualización del desarrollo de proyectos libres en barrapunto

Elizabeth Loftus y los recuerdos falsos

2008-06-04T14:13:00.003+02:00

Vía El psicoanálisis ¡vaya timo! de El cerebro de Darwin me he encontrado con los estudios de Elizabeth Loftus acerca de un tema tan atractivo como los recuerdos falsos. En particular hay un buen resumen en "Our changeable memories: legal and practical implications". Me quedo con la cita de Eduardo Galeano a modo de resumen (que no he podido encontrarla en castellano, la traduzco de la traducción :\)

La memoria nace cada día, brotando del pasado y contraponiéndose a él.

La misma entrada y más comentarios en Elizabeth Loftus y los recuerdos falsos en barrapunto

Varios sobre concurrencia: Lock-free en Java, STM vs locks y consejos

2008-05-29T23:03:00.002+02:00

Varios sobre concurrencia (versión n)

Cliff Click hizo una presentación sobre estructuras sin bloqueos en Java en la JavaOne 2008. El (interesante) pdf de la presentación está online y, no sé si más interesante, el código fuente: Highly Scalable Java en SourceForge
En el blog del mismo Cliff Click hay una argumentadísima discusión de STM vs locks (Bloqueos frente a memoria transaccional por software) Esto si son discusiones :) (por cierto, que la original está en STM criticism from Azul Systems)
Por último, Herb Sutter en Maximize Locality, Minimize Contention da consejos sobre programación concurrente, algunos de sentido común. Además propone un ejemplo muy claro de falsa compartición y remedios un poco drásticos de evitarla.

Pequeña nota sentimental: hoy hace cinco años que escribí mi primera bitácora en barrapunto y hace muy poquito yapw ha sobrepasado las 100 entradas. Casi no me lo creo, como pasa el tiempo...

La misma entrada y más comentarios en Lock-free en Java, STM vs locks y consejos en barrapunto

Firefox 3, SQLite, fsync, ext3 y otras abstracciones

2008-05-26T23:19:00.004+02:00

Vía LWN leo un buen resumen de uno de los grandes problemas de Firefox 3 en linux: es fácilmente observable como dicho navegador se congela durante bastantes segundos hasta que vuelve a responder. Es debido, al parecer al (ab)uso de las actualizaciones en SQLite, que usa fsync, que a su vez tiene un más que pobre rendimiento en ext3. La buena noticia es que todos ellos están tratando de mejorar.

A la vez que me parece un enlace interesante del que se pueden aprender bastantes cosas y un ejemplo de la tesis que manejaba el otro día en ¿Demasiadas capas de abstracción?: Los sistemas tienden a ser cada vez más complejos, y esto genera algunos problemas, pero la tendencia no tiene marcha atrás... En este caso además se le une la complejidad de la portabilidad. El mismo código usa implementaciones distintas de las mismas abstracciones, con lo que el testeo se complica enormemente y probablemente sólo es viable en un escenario de software libre.

La misma entrada y más comentarios en Firefox 3, SQLite, fsync, ext3 y otras abstracciones en barrapunto

¿Demasiadas capas de abstracción?

2008-05-20T15:38:00.004+02:00

Vuelve otra vez uno de mis temas favoritos, el de la complejidad inherente y creciente de los sistemas de información, tratado esta vez por Ian Lance Taylor en Layered Programming. Me permito citraducir un párrafo, un poco al vuelo:

Cada vez es más difícil ser un experto en sistemas. Cuando aprendí a programar, era posible entender todo tu programa, desde el código fuente hasta el código máquina. Sin embargo, cuando escribes una aplicación moderna en Ajax esto es se vuelve imposible. Hay demasiados intérpretes diferentes. Hay demasiado código ejecutándolo. Ni arreglarlo con un nuevo nivel base por encima del procesador (el navegador(?)) ayudaría. Todo esto nos conduce a una pérdida de rendimiento a veces notable y, lo que es a veces más importante, una perdida de seguridad.

No podemos volver atrás. Pero me pregunto si podremos confluir en un modelo de programación que pueda ser comprendido en su totalidad en todas sus capas. O si las cosas simplemente van a ser más complicadas cada vez.[0]

Y no sólo me permito la cita, sino que además respondo :) Y mi respuesta (que me perdonen Alvin y Heidi Toffler) es pesimista, en el sentido de que no hay vuelta atrás al idílico pasado en el era posible comprender completa, local y globalmente un sistema. La tendencia es la de más lenguajes, más plataformas y más capas, incluso dentro de los propios procesadores y nunca la contraria.

Pero no es por los ejemplos concretos que vemos a diario por que creo que esto va a seguir siendo así, sino por el trasfondo. Los sistemas de información van evolucionando unos sobre otros y rara vez se da el caso de retroceso de una paso evolutivo exitoso[1], lo que se conoce como Ley (o hipótesis) de Dollo[2] en evolución biológica, que nos vuelve a dar un ejemplo de uno de mis juegos mentales preferidos, el paralelismo entre sistemas biológicos e informáticos [3]. A quien mejor he leído referirse a este paralelismo es a Richard P. Gabriel en su Objects Have Failed y que explora de nuevo en Design Beyond Human Abilities (pdf)

No obstante, a pesar de la tendencia natural, creo que uno de los deberes de un diseñador, arquitecto, desarrollador, programador o comoquierallamársele es contener en lo posible la complejidad del sistema global [4]

[0] El primer comentario apunta, yo creo que con acierto, a "The Law of Leaky Abstractions" de Spolsky.
[1] Existen sistemas que tienen diversos enfoques o paradigmas, que yo asimilaría a distintas ramas evolutivas. La tesis de Dollo aplicada a los sistemas informáticos sería válida sólo en el progreso de una rama evolutiva. En diversas ramas evolutivas se pueden dar una tendencia y la contraria, claro...
[2] Hablé hace tiempo de esta ley en La ley de Dollo y los sistemas informáticos
[3] Otro ejemplo de dicho paralelismo podría ser el del monocultivo, del que escribí hace ya mucho en Los peligros del monocultivo y Los peligros del monocultivo (de nuevo)
[4] Conviene recordar un par de mantras clásicos: "Controlar la complejidad es la esencia de la programación de ordenadores" de Brian Kernighan y "Cualquier problema de computación puede ser resuelto con un nuevo nivel de indirección, excepto si el problema es que hay demasiados niveles de indirección" de David Wheeler (La exactitud de esta última es dudosa, pero me gusta esa versión)

La misma entrada y más comentarios en ¿Demasiadas capas de abstracción? en barrapunto

Reparación de ficheros vía P2P

2008-05-05T15:56:00.001+02:00

Me ha parecido curiosa esta historia de slashdot: usar la comprobación de integridad de los sistemas P2P, en este caso BitTorrent, para verificar y corregir un fichero corrupto. Muy útil en casos en los que no se disponga de un gran ancho de banda...

La misma entrada y más comentarios en Reparación de ficheros vía P2P en barrapunto

Varios sobre concurrencia: Erlang, MPI y C++0x

2008-05-02T17:05:00.003+02:00

Varios rápidos sobre concurrencia;

Erlang Versus MPI - Final Results and Source Code: Midiendo el rendimiento de Erlang contra MPI. Como todas las comparativas, seguramente es cuestionable, pero da mejor resultado en general a MPI. Proporciona fuentes de los tests. Más comentarios en programing reddit (posteado por un servidor :) )
También vía programming reddit (éste posteado por el bot oficial, gst) Network Programming in Erlang, una introducción sencillita e interesante.
The Future of Concurrency in C++ (pdf). Una presentación que repasa las novedades referentes a concurrencia aprobadas para C++0x y algunas cosas más. Vía comp.programming.threads (sí, aún hay gente que lee Usenet)

La misma entrada y más comentarios en Varios sobre concurrencia: Erlang, MPI y C++0x en barrapunto

Generación automática de exploits aprovechando los parches

2008-04-29T15:52:00.004+02:00

La idea, hay que reconocerlo, es buenísima: crear automáticamente el programa que explotará la vulnerabilidad que trata de solucionar un parche mediante la información del mismo parche. La generación se realiza a través de la comparación entre el programa parcheado y el original. El artículo que desarrolla las posibles técnicas es Automatic Patch-Based Exploit Generation is Possible: Techniques and Implications. Parece que la cosa últimamente va de diferencias binarias :) (como en Actualizando el kernel Linux sin reiniciar )

Más comentarios en Bruce Schneier: Reverse-Engineering Exploits from Patches, programming reddit: Automatic Patch-Based Exploit Generation y LtU: Automatic Patch-Based Exploit Generation.

Actualización: Como Apunta Drizzt en las publicaciones de la gente de bindiff se examina más detenidamente el tema de la comparación binaria. En la misma entrada Drizzt también aporta algún enlace más al respecto.

La misma entrada y más comentarios en Generación automática de "exploits" aprovechando los parches en barrapunto

Entrevista a Mario Bunge

2008-04-28T09:26:00.007+02:00

Nota: Si eres lector de planeta código y sólo te interesa el desarrollo, sáltate esta entrada. Pero es un enlace que me parece de interés general :)

Vía Cuchitril Literario me encuentro con una buena pero breve entrevista a Mario Bunge. En ella se dice de la filosofía de Heidegger:

[...] se aprovechó de la tradición académica alemana según la cual lo incomprensible es profundo.

[...] fenomenología, existencialismo, esas cosas abstrusas que nadie entiende pero si usted dice que no entiende, pasa por tonto

O dicho de otro modo: no todas las veces que no entiendes algo es porque tú seas limitado. Plantéate que quizás no tenga ningún sentido...

Mario Bunge en la wikipedia

La misma entrada y más comentarios en Entrevista a Mario Bunge en barrapunto

Actualizando el kernel Linux sin reiniciar

2008-04-25T12:20:00.005+02:00

Leyendo el blog de Daniel Stenberg me entero de que ksplice ofrece la posibilidad de hacer actualizaciones de seguridad en el kernel Linux sin reiniciar, siempre y cuando los cambios no supongan modificaciones semánticas en los datos. Según el autor este tipo de modificaciones son aproximadamente un 80% del total de vulnerabilidades críticas. Es, aparentemente, el sueño de muchos administradores de sistemas...

Más información en el artículo de presentación, Ksplice: An automatic system for rebootless Linux kernel security updates (pdf), en la lista del kernel, A system for rebootless kernel security updates y en programming.reddit.

Actualizando el kernel Linux sin reiniciar en barrapunto

La vida privada de volatile

2008-04-24T22:34:00.003+02:00

El estándar de C(++) tiene unas cuantas esquinitas. Seguramente volatile es una de ellas. Para aclarar el significado exacto de este calificativo en Coding Relic han publicado La vida privada de volatile, en donde no solo se analiza la letra del estándar sino que se examina el código generado para MIPS en distintos casos.

Conviene recordar los posibles usos de volatile, así como para qué no debe usarse:

How does the C "volatile" keyword really work? de Ian Lance Taylor. El resumen es bastante claro
If you are using volatile for anything other than manipulating memory mapped hardware, or for very limited communication between threads, it is very likely that you are making a mistake. Think carefully about what volatile means and about what it does not mean.
En la misma linea, Volatile: Almost Useless for Multi-Threaded Programming
Varias discusiones en usenet: C++, volatile member functions, and threads, volatile guarantees? y Memory Barriers, Compiler Optimizations, etc., todas ellas en comp.programming.threads
Una discusión sobre lo que es, que no es y que quizás debiera ser volatile en Should volatile Acquire Atomicity and Thread Visibility Semantics?, lo que lleva a arreglar el modelo de memoria de C++.

La vida privada de volatile en barrapunto

La aritmética de punteros, su desbordamiento y la seguridad

2008-04-09T23:09:00.004+02:00

Me he enterado vía el valle del viento helado de una nueva polémica acerca de gcc y su implementación. El hecho es que gcc cambió su comportamiento en cuanto a comparaciones entre punteros incrementados y ha provocado muchos meses después una alerta de seguridad desproporcionada y según los desarrolladores de gcc, falsa (Se puede oír desde aquí el ruido y la furia)

El caso es que, entrando en profundidad, es una optimización casi "trivial" que hace que p + C1 < p + C2 pase a ser C1 < C2 sin tener en cuenta el posible desbordamiento (overflow) de ambas operaciones. Hay que decir además que el estándar (de C y de C++) declara no definido el valor del resultado de la suma entre un puntero y un entero cuando se sobrepasa el tamaño del objeto al que apunta.

Es muy importante este último punto, porque deja traslucir un error de concepto: la comprobación de overflow propuesta en la alerta(*) es muy burda porque sólo se comprueba el desbordamiento de la operación aritmética, no que nos estamos saliendo del rango permitido. Sin embargo lo que deben saber el programador y el programa a la vez, cuando están manejando aritmética de punteros es cual es el desplazamiento (offset) máximo, de cuanta memoria se dispone. Si eso no lo sabe, es inútil cualquier otra comprobación...

Hay que hacer notar además que la optimización de la que se habla aquí la aplican casi todos los compiladores y lo que provoca la alerta es en realidad el cambio de comportamiento, no que sea incorrecto.

También recuerda esto que es muy mala política basar el código en detalles de implementación específicos de la plataforma. En este caso y en muchos otros, los desarrolladores de gcc tiran de cita del estándar para argumentar sus decisiones. Los usuarios se quejan, llamándoles abogados del lenguaje (language lawyer) pero en momentos como esos hay que recordar que probablemente están defendiendo sus decisiones de implementación y lo importante de esas decisiones para el éxito de una tecnología.

(*)char *buf; int len; len = 1 << 30; if (buf+len < buf){ Overflow }

La aritmética de punteros, su desbordamiento y la seguridad en barrapunto

Un par de enlaces más (sobre C++)

2008-04-01T12:34:00.003+02:00

Sólo un par de enlaces más para complementar la entrada anterior, la entrevista con Stroustrup (lástima que hayan salido después, hubiesen quedado bien en la misma entrada...)

La entrevista de Strosutrup comentada en Slashdot, sobre todo desde el punto de vista de la enseñanza del lenguaje. Como siempre, comentarios a la vez encendidos e interesantes...
Trip Report: February/March 2008 ISO C++ Standards Meeting de Herb Sutter en el que se repasa las últimas incorporaciones a C++0x. Destaca, por supuesto, la incorporación de funciones lambda y clausuras. Pero hay más, como la herencia de constructores...

Un par de enlaces más (sobre C++) en barrapunto

(Otra) entrevista a Stroustrup

2008-03-29T00:19:00.004+01:00

Por si alguien había pensado que me había olvidado de C++0x y de Stroustrup esta entrada viene a demostrar que no :) Uno no tiene porqué estar de acuerdo con Bjarne Stroustrup, incluso puede odiar C++ por las milsetecientascincuetaydos razones por las que puede resultar odioso, pero lo que no se puede negar es que Bjarne ha tenido una gran influencia y sus opiniones son, por lo menos dignas de ser leídas. Algunas de las entrevistas que se le han hecho (incluso alguna que no le han hecho ;) ) me suelen parecer intensas y con elementos para la reflexión.
Pues bueno, en DDJ le han hecho una nueva entrevista. Extractaré lo que me ha interesado (Espero me sepan disculpar que no traduzca esta vez. Si me ha costado más de un mes hacer una nueva entrada no quiero imaginarme cuando publicaría esto con traducción...):

Sobre los distintos paradigmas de programación:

No programming paradigm is best for everything. What you have is a problem and a solution to it; then, you try to map that solution into code for execution. You do that with resource constraints and concerns for maintainability. Sometimes, that mapping is best done with OOP, sometimes with generic programming, sometimes with functional programming, etc.

OOP is appropriate where you can organize some key concepts into a hierarchy and manipulate the resulting classes through common base classes. Please note that I equate OO with the traditional use of encapsulation, inheritance, and (run time) polymorphism. You can choose alternative definitions, but this one is well-founded in history.

Sobre C++0x:

The progress on standard libraries has not been what I hoped for. We will get regular expressions, hash tables, threads, many improvements to the existing containers and algorithms, and a few more minor facilities. We will not get the networking library, the date and time library, or the file system library.

The standard will be finished in late 2008, but it takes forever to go through all the hoops of the ISO process. So, we must face the reality that "C++0x" may become C++10.

C++0x y el multithreading:

The new memory model and a task library was voted into C++0x in Kona. That provides a firm basis for share-memory multiprocessing as is essential for multicores. Unfortunately, it does not address higher-level models for concurrency such as thread pools and futures, shared memory parallel programming, or distributed memory parallel processing.

Consejos para el desarrollo en el mundo real. Me gusta especialmente cuando se recuerda el carácter complejo y casi orgánico de los sistemas (como Richard P. Gabriel en Objects Have Failed):

Think. Discuss with colleagues and potential users. Get a good first-order understanding of the problem domain. If possible, try to be a user of an existing system in that field. Then, without too much further agonizing, try to build a simplified system to try out the fundamental ideas of a design. That "simplified system" might become a throwaway experiment or it may become the nucleus of a complete system. I'm a great fan of the idea of "growing" a system from simpler, less complete, but working and tested systems. To try out all the tool chains before making too grand plans.

Sobre las habilidades que les suelen faltar a los estudiantes:

I saw so many students who simply didn't have the notion that code itself is a topic of interest and that well-structured code is a major time saver. The notion of organizing code to be sure that it is correct and maybe even for someone else to use and modify is alien: They see code as simply something needed to hand in the answers to an exercise.

Vía programming.reddit.

"(Otra) entrevista a Stroustrup" en barrapunto

Firefox usará el asignador de memoria experimental de FreeBSD

2008-02-20T18:52:00.004+01:00

Leo en (cómo no...) en programming.reddit que Firefox 3 beta 3 utiliza el asignador de memoria dinámica experimental de FreeBSD (jemalloc) en lugar del asignador de la plataforma de ejecución. Al parecer ha dado buenos resultados en cuanto velocidad y reducción de la fragmentación en los test de rendimiento para las tres plataformas mayoritarias (Windows, Mac OS X y Linux)

Para el que esté interesado en estos temas hay disponible un artículo muy interesante sobre jemalloc: A Scalable Concurrent malloc(3) Implementation for FreeBSD (pdf) en el que se explica su implementación, que coge ideas entre otros de hoard, y ciertamente tiene muy buena pinta. Hablé de hoard hace poco en Problemas de memoria (y algunas soluciones).

Firefox usará el asignador de memoria de FreeBSD en barrapunto

Notas sobre errores fatales y portabilidad

2008-02-13T22:52:00.007+01:00

Es escasa y dispersa la información que he encontrado acerca de la gestión de errores fatales en distintos sistemas operativos y lo que afecta al funcionamiento de los programas sobre ellos. Así que voy a juntar lo que he ido recopilando en una sola entrada. Puede ser un poco batiburrillo, pero igual le es de utilidad a alguien... (Para mi seguro, que así no pierdo los enlaces). Ordenadas de general a específico[1]:

En ANSI C existe signal que permite cambiar la gestión este tipo eventos, entre los que se encuentran SIGSEGV, violación de segmento y SIGFPE, error aritmético. No obstante, por desgracia, su comportamiento en programas con más de un thread no está especificado. Además por si fuese poco ANSI tampoco especifica el handler por defecto, es decir, qué es lo que pasa si salta una señal de ese tipo.

De hecho, de los que he probado, en windows con la librería de C del VisualStudio al menos, las señales funcionan por thread y en linux es global por proceso...

En POSIX si que se define el comportamiento por defecto de las señales. En concreto SIGSEGV y SIGFPE abortan el proceso completo . Se pueden ver los comportamientos por defecto de las distintas señales en POSIX en la documentación de <signal.h> del OpenGroup. Además, POSIX(R) recomienda pasarse a sigaction (que sólo es POSIX(R), no ANSI).

Windows NT no genera señal de violación de segmento, pero se le puede instalar handler

En win32 un error fatal se gestiona como una excepción estructurada (SHE) que en C++ se mapea a un excepción normal[2]. Además, una excepción estructurada no capturada, por defecto, supone la muerte del thread en el que se produce, pero no del proceso global .

Existe una forma de sobrescribir este comportamiento por defecto y es SetUnhandledExceptionFilter. Recomiendan en Nynaeve[3] no hacer cosas demasiado complicadas en el manejador, como parece lógico.

En un artículo de DeveloperWorks comentan un modo de convertir señales en excepciones pero que es un hack completamente erróneo: C++ exception-handling tricks for Linux porque da a entender que se puede replicar el comportamiento por defecto de Windows. Sin embargo, como se puede leer en "Program Error Signals" de la documentación de la glibc:
La acción por defecto de todas estas señales es terminar el proceso. Si se bloquean o ignoran estas señales o se establece un handler que retorna normalmente, tu programa cascará espantosamente en el momento en que suceda la señal no ser que(*) haya sido generada a través de raise o kill en lugar de un error real.
cosa que he podido comprobar con el código de DW tratando de ignorar una violación de segmento.

En resumen, lo más juicioso (y homogéneo entre plataformas) sería parar el proceso completo en caso de uno de estos errores y tratar de informar lo más completamente posible del error. En caso de win32 habría que forzar el fin del proceso, ya que no es la acción por defecto[4].

[1]El orden es de mayor a menor, de general a específico. Debería ser obvio para un programador: a igualdad de condiciones, se debería usar lo que funcione en el estándar más aceptado y amplio ¿por qué limitar el ámbito de aplicación? Primero, buscar en ANSI, y si la funcionalidad no está elegir conscientemente una solución más específica. En el fondo para mi no es más que una consecuencia de la ley de Postel sobre el el código: "Cuanto más estricto (más estándar) es lo que escribes, más aumentarás la interoperabilidad". Puede parecer una obviedad, pero en esas pequeñas microdecisiones de los programadores no es nada extraño usar extensiones del estándar sin necesidad. Y en caso de necesidad se puede echar mano de librerías libres, muchas de ellas con un alto nivel de portabilidad.

[2]Pongo en cursiva normal porque entra la duda si en esos casos, de tan bajo nivel, una excepción, que se confunde con excepciones de de otro tipo, es lo más clarificador para el usuario-programador, máxime cuando el C++ estándar no posee excepciones para gestionar estos casos...

[3]Un blog que he descubierto hace poco... interesante. Además sobre el mismo tema: Beware of custom unhandled exception filters in DLLs y You might be using unhandled exception filters without even knowing it

[4]Cabe preguntarse porque se permite la ejecución del proceso en un caso tan excepcional... habida cuenta además de que una excepción no capturada de de C++ provoca, por defecto el fin del proceso... En este caso está sin duda justificado el Fail Fast: lo que hay que hacer es arreglar el programa, no dejarlo seguir...

(*)Me despisté al traducir. Gracias a Javier Noval por leerse los enlaces y hacerme notar el error ;)

Notas sobre errores fatales y portabilidad en barrapunto

(Otros) problemas con la memoria y (otras) soluciones

2008-02-04T11:04:00.000+01:00

Alguien en programming.reddit hizo una pregunta de esas difíciles: ¿Cómo manejar en un programa en C los casos en los que la memoria se agota? Y digo que es una de esas preguntas difíciles porque depende del tipo de software que estás haciendo, de su criticidad y del nivel requerido de robustez. Ya se sabe, el difícil compromiso de la gestión de errores críticos.

Y como se ve en las respuestas de los redditenses no sólo depende de nuestro sistema, sino de detalles de implementación de más abajo, como suele ser usual en los casos no del todo raros en los que las abstracciones que usamos comienzan a flaquear. En este caso se habla del comportamiento de Linux (el kernel) a la hora de tratar la falta de memoria, que por defecto usa una estrategia optimista que deja reservar (pero no usar, claro) más memoria de la disponible. No obstante este comportamiento se puede cambiar a uno un poco más controlable a través del parámetro overcommit_memory, que se introdujo no hace tanto... El comportamiento por defecto es llamar al OOM Killer que es un método tan drástico como poco predecible. Todo esto esta muy bien explicado en When Linux Runs Out of Memory que vi referenciado por aquí en tiempos de mayor intensidad técnica :)

Además en las respuestas se apunta a un libro online de los que vienen bien cuando las condiciones son más extremas de lo usual: Small Memory Software. Patterns for systems with limited memory. Apuntado en éste mi del.icio.us particular.

(El título es "(Otros) problemas con la memoria y (otras) soluciones " porque no hace mucho escribí Problemas de memoria (y algunas soluciones), sobre el cuello de botella que supone la gestión de memoria sobre todo en sistemas multicore)

"(Otros) problemas con la memoria y (otras) soluciones" en barrapunto

Los usuarios y la primera impresión

2008-01-22T10:32:00.000+01:00

Repasando la pila de cosas pendientes de leer me he encontrado con un inspiradísimo Larry O'Brien en una frase que es solo lateral en su razonamiento de que se nota más a los programadores muy malos que a los muy buenos

Medir la satisfacción [para medir la calidad de un desarrollo] es un indicador insuficiente, porque la satisfacción tiende a ser un delta de la última experiencia, no un valor absoluto.

Y es curiosísimo, porque tengo exactamente esa percepción tanto en un lado como en el otro, de programador y de usuario: no importa lo que ocurra posteriormente a un error fatal del sistema; el sistema llevará para siempre ese estigma. Da igual que se corrigiese para siempre, en la siguiente versión. Para no ser absolutamente pesimistas, a nivel interno ayuda muchísimo que exista (y se use) un sistema de seguimiento de incidencias, que esté documentado cuándo, dónde y cómo se producía el problema y cuándo (desde que versión) y cómo se solucionó. A nivel externo... ya digo, un estigma :/ Aunque una labor continuada de comunicación, que tal mal se les suele dar a los desarrolladores, puede ayudar bastante...

Es también por el miedo a que la primera impresión no sea buena por lo que muchos programadores se resisten al famoso release early, release often. Pero no publicar versiones también es fuente de mala imagen, de eso los desarrolladores deben de ser conscientes... Y es que es difícil conjugar el causar una buena impresión con publicar pronto. Yo tengo en esto una política que no sé si es la más acertada, pero es la mía: minimizar la funcionalidad de la primera iteración, limitarla a lo esencial, que sea mínima pero bien testeada. Por cierto, que Joel no está de acuerdo con esta estrategia desde el punto de vista estratégico/comercial/ISV... Mucho que discutir desde distintas vertientes, incluido el modelo de negocio y de desarrollo de software, claro :)

Por cierto que este mismo tema, desde el punto de vista estrictamente estético, fue tratado por Jeff Atwood con un ejemplo muy desafortunado, comparando Frets on Fire con Guitar Hero. No puedo ser imparcial en este caso porque estoy enganchado al FoF en el que uno se puede creer que toca con el teclado como Stevie Ray Vaughan con su guitarra en Texas Flood. Aquí, al menos para mi, es el sonido y no la imagen lo importante :)

Los usuarios y "la primera impresión" en barrapunto

Problemas de memoria (y algunas soluciones)

2007-12-05T17:01:00.000+01:00

Gracias a Lambda The Ultimate he encontrado un artículo muy ilustrativo sobre el típico flame de gestión automática de memoria contra gestión manual: Quantifying the Performance of Garbage Collection vs. Explicit Memory Management de Matthew Hertz, Yi Feng, Emery D. Berger. Si hacemos caso de sus conclusiones:

Si las aplicaciones se ejecutan en sistemas con al menos tres veces más memoria RAM de la necesaria entonces la recolección de basura proporciona un rendimiento razonable. Sin embargo si el sistema dispone de menos RAM o las aplicaciones tienen que competir con otras por memoria entonces se debe esperar que la recolección de basura traiga consigo un coste de rendimiento sustancial.

Como es sabido, no es blanco ni negro, sino que es una cuestión de compromisos, pero al menos ahora tenemos algún dato para tomar la decisión. De todos modos el artículo tiene más cosas que esta conclusión: compara diversas estrategias de recolección de basura y tiene muchas referencias interesantes.

A raíz de una de esas referencias me he encontrado con un asignador de memoria dinámica (allocator): hoard, curiosamente desarrollado por Emery Berger, uno de los autores del artículo anterior. Este asignador promete evitar uno de los grandes cuellos de botella de la programación con threads y sistemas multicore: la gestión de la memoria dinámica, el heap. Citando también del primer artículo:

En particular, las versiones recientes de hoard mantiene en el espacio local del thread la lista de los espacios libres (freelist) y usa generalmente operaciones atómicas sólo cuando se sincronizan o se rellenan.

Muy interesante...

Problemas de memoria (y algunas soluciones) en barrapunto

Recursos para optimizar programas en C++ y ensamblador

2007-11-29T13:52:00.000+01:00

Ya se sabe, la optimización prematura es la raíz de todo mal. Pero hay veces que es necesario optimizar y en estos casos no viene mal una ayuda... Por un lado conocer la estructura de las arquitecturas modernas de uso común en cuanto a memoria y cachés. De eso ya se ha encargado Ulrich Drepper como hemos comentado hace poco por aquí.

Por otro lado, he encontrado gracias a programming.reddit una serie de recursos entre los que se encuentran documentos en pdf que podrían ayudarnos. Todos ellos están escritos por Agner Fog y están reunidos en Software optimization resources. Son bastante extensos y por lo que he ojeado con bastante información valiosa. De ellos destacaría (es el que más he mirado), Optimizing software in C++ (An optimization guide for Windows, Linux and Mac platforms) (pdf) que repasa formas de optimizar C++ reparando además en particularidades de plataformas y compiladores.

Además hay también una guía para para optimizar ensamblador para plataformas x86, tablas con características de las instrucciones de Intel y AMD, programas de test y más enlaces. A disfrutar con la lectura, pero a usar con precaución ;)

Recursos para optimizar programas en C++ y ensamblador en barrapunto

Lo que todo programador debería saber sobre la memoria (pdf)

2007-11-22T10:42:00.000+01:00

Ulrich Drepper ha acabado de publicar online la serie de artículos acerca de la memoria, cachés en arquitecturas modernas de uso común y de lo que el programador puede hacer al respecto. Cuando comenzó ya lo comentamos por aquí en Lo que todo programador debería saber sobre la memoria.

Y como prometió lo ha publicado ahora en pdf: "What Every Programmer Should Know About Memory" por Ulrich Drepper. Como puede ser que alguien interesado no se haya enterado de su existencia, la aparición del pdf puede ser un buen momento para recordarla...

Lo que todo programador debería saber sobre la memoria (pdf) en barrapunto

Programando con threads: algunos enlaces

2007-11-08T11:08:00.000+01:00

Algunos enlaces a tener en cuenta si programas con threads:

"Avoid Calling Unknown Code While Inside a Critical Section" por Herb Sutter. Como simepre, las secciones críticas cuanto más pequeñas mejor, pero además conviene saber qué es lo que se llama en ellas... (Me recuerda un poco al mantra Trata el código de los demás como si fuese tuyo)
"Single Threaded Memory Model" de Ian Lance Taylor: como comentaba hace ya mucho en Los peligros de programar con threads el compilador puede llegar a hacer optimizaciones que den al traste con la intuitiva atomicidad de algunas variables cogidas por mutex. Pues bien, aparentemente ese problema que podría parecer remoto se puede reproducir con gcc. La solución, como siempre, conocer bien el estándar y el uso de volatile. De todos modos queda patente que se necesita algo parecido a un modelo de memoria que tenga en cuenta la concurrencia, como se comentaba también en Threads y C++(estándar)

Programando con threads: algunos enlaces en barrapunto

El programador (una apología)

2007-10-18T23:16:00.000+02:00

Me apetece hacer apología del puesto de programador, porque creo que es necesario por dos motivos fundamentales y relacionados: no se le considera un puesto apetecible por ser jerárquicamente bajo y no se tiene conciencia de que la experiencia en la programación sea útil. En resumen, que el puesto de programador no se considera de futuro[1]. Pero no es el futuro profesional del programador[2] de lo que quiero hacer apología, sino de la labor del programador en si: difícil pero necesaria y apasionante[3].

Los buenos programadores son imprescindibles para que este mundo funcione. En la eterna, manida y estéril discusión de las atribuciones profesionales se suele denostar la labor de programador en favor de la figura del arquitecto de software. No voy a entrar aquí en lo importante de una buena dirección y coordinación en un proyecto de desarrollo (que lo es), sino de lo importante que es el trabajo de base. Porque el de programador en un puesto intrínsecamente bajo desde el punto de vista jerárquico. ¿Significa eso que es un trabajo rutinario, sin retos ni creatividad? En absoluto. Es un trabajo muy decisivo, a veces creativo y de gran responsabilidad casi por definición.

Es difícil porque hacer software es intrínsecamente difícil[4][5] Y el creer que toda la dificultad se puede abstraer del programador hacia arriba en la jerarquía no deja de ser una especie de pensamiento mágico alejado de toda realidad. Es prácticamente imposible hacer un análisis y diseño completos sin resquicios y teniendo en cuenta todos los detalles del sistema final, tanto funcionales como de rendimiento y seguridad. Es muy frecuente que aparezcan aspectos dependientes de que la implementación sea óptima y adecuada al uso del sistema final.

Es de una gran responsabilidad porque, entre otras cosas, es muy fácil hacerlo mal y no es trivial descubrirlo[6]. El programador moldea con sus manos el sistema final que va estar funcionando, transforma en realidad, en funcional, un concepto ideal. Y es el que más directamente que se da de bruces con las limitaciones del mundo real, de las herramientas y los sistemas. Es el que, si es brillante, es capaz de dar soluciones a esas limitaciones o al menos no acrecentarlas. Pero un programador no muy hábil o simplemente poco disciplinado o descuidado puede provocar errores, tanto fáciles de detectar como demasiado sutiles para ser detectados cuando deben, en la fase más temprana posible del desarrollo.[7]

Tengo que decir que lo que yo entiendo por programador es lo que a veces se denomina "desarrollador", algo un poco más amplio que solo tirar líneas, pero me niego a renunciar a usar el término: me gusta decir programador, me gusta programar.

[1] Y es posible que no lo sea :( Me gustaría pensar que, por lo que cuento después, lo es.
[2] Bueno, hay muchos futuros dentro del desarrollo. Uno, ascender. Otro, especializarse. Pero bueno del futuro profesional prefiero que hablen los comentaristas...
[3] Obviamente hay mucho que comentar de los aspectos sociales del programador, que pueden condicionar, pero no hablaré de ellos. Para saber más pasa por aquí ( bueno, o por aquí)
[4] "The complexity of software is an essential property, not an accidental one. Hence, descriptions of a software entity that abstract away its complexity often abstract away its essence" No silver Bullet, Frederick P. Brooks
[5] Un poco más actual: Software Is Hard, Kyle Wilson
[6] Me gusta mucho la frase de Brian Kernighan: "Depurar es el doble de difícil que escribir el código por primera vez. Entonces, si escribes código tan inteligentemente como te sea posible, no vas a ser, por definición, suficientemente listo para depurarlo" Depurar es otra habilidad quizás no demasiado valorada del programador experto.
[7] Metodologías de desarrollo y/o testeo adecuadas y acordes con el proyecto aceleran la caza de errores, pero la disciplina y experiencia del programador son la base del desarrollo de calidad.

"El programador (una apología)" en barrapunto

¿Está acabando internet con el contenido extenso?

2007-10-10T11:01:00.000+02:00

Se suele recordar mucho últimamente que el vídeo mató a la estrella de la radio por aquello del cambio de formato y de la (no) adaptación de la industria musical a esos nuevos formatos. Lo mismo seguramente se puede ampliar al resto de los contenidos culturales, en el amplio sentido de la palabra, y sobre todo al libro ¿Mató internet el contenido extenso? ¿Mató internet a los libros?

El caso es que últimamente he visto varios casos en los cuales el modo de publicación es controvertido porque se trata de contenidos de un volumen grande, más grande que un post de blog, para entendernos. Primero fue Ulrich Drepper que dudó que opción tomar y tomó la resolución de publicarlo por partes en LWN. Ian Lance Taylor ha publicado un número enorme de post, veinte, muy interesantes (para mi al menos ;) ) sobre enlazadores, pero demuestra claramente que el blog no sirve para crear contenidos amplios y legibles a la vez.

¿Cual es la tendencia? Hemos visto decaer sitios de generación y promoción de contenidos que premiaban calidad y extensión, como k5 o libertonia. Triunfan sitios del tipo digg, reddit o meneame en los que sólo se hace referencia y se extracta brevemente. No se me entienda mal, los sitios me parecen útiles, programming.reddit y tecnologia.meneame los visito y uso. Pero creo que tienden a ser autocontenidos, a quedarse más en si mismos que a servir para lo que probablemente deberían servir: promocionar contenido de calidad. Es la tendencia al minimalismo, tanto en la referencia como en el comentario: estos sistemas premian la brevedad y la concisión, con buenas razones, pero en perjuicio de contenido espeso y en favor del impactante. /. en las dos versiones que uso estaría a medio camino, pero no se acaba de librar de este mal... Es el signo de los tiempos, en los que la sobrecarga informativa va acompañada de atención parcial continuada...

Pues bueno, Charles Petzold, que escribe mucho mejor que yo y que además tiene un buen curriculum de libros espesos publicados reflexiona sobre ello en Hard Work, No Pay: What's the Point?, teniendo en cuenta que lo hace, al menos en parte, desde el punto de vista de un autor. Se pregunta ¿por qué libros y no entradas en blogs? Y responde (citraduzco un poco al vuelo)

Es fácil convencerse de que los pedacitos de prosa representan el nivel óptimo de granularidad de información. Es parte de la visión utópica de la web como una plétora de páginas débilmente enlazadas cuya sinergia genera toda la información que necesitamos. Esta ilusión está afectando a la manera en la que aprendemos y tengo miedo de que no tengamos una visión más amplia y completa que solo un libro puede proporcionar. Un buen autor encontrará una selva poco manejable de información y cortará una senda coherente para pasar a través de ella, a través de una narrativa que enlaza el material.

Respuesta que me ha gustado mucho porque ilustra muy bien el tipo de libros que deberían sobrevivir a la mencionada sobrecarga informativa: aquellos que son capaces de establecer un poco de orden y hacer un poco más comprensible la realidad fragmentada.

¿Está acabando internet con el contenido extenso? en barrapunto

Lo que todo programador debería saber sobre la memoria

2007-10-04T09:00:00.001+02:00

Así titula Ulrich Drepper un artículo sobre los posibles cuellos de botella que se generan en las arquitecturas modernas de uso común, explicando el comportamiento de las caches de CPU, el diseño de los controladores de memoria, el DMA... Debería ser útil para esos momentos en los que las abstracciones que usamos empiezan a fallar y debemos conocer lo que hay debajo.

El modo de publicarlo es un poco, bueno, llamémosle arcaico, pero nos conformaremos porque el contenido lo merece, y porque es el deseo del autor, claro... El caso es que se va a publicar por partes en LWN.net y al comienzo serán accesibles solo para suscriptores y posteriormente para el resto. Al final publicarán la versión pdf que probablemente será muy interesante para imprimir. Actualización (22/11/07): Ya está disponible la versión en pdf: "What Every Programmer Should Know About Memory" por Ulrich Drepper

He ido actualizando esta entrada conforme se han liberado las todas las partes del documento, muy interesantes:

Bonus Track: Como creo que pega en esta entrada, pongo el link a unas charlas con diapositivas de Herb Sutter sobre temas similares: Machine Architecture: Things Your Programming Language Never Told You (jejeje, Sutter y Drepper ¿lo mejor de los los dos mundos?)

Lo que todo programador debería saber sobre la memoria en barrapunto

Paul Graham Facts

2007-10-02T17:31:00.000+02:00

Paul Graham Facts. Sólo apto para quien sepa quien es Paul Graham (bueno, y aún así...) Ejemplo: Paul Graham is so good, he always tips using $2.56 cheques made out by Donald Knuth

Actualización: por si alguien es tan masoquista de quedarse con ganas de más: Bruce Schneier Facts. Espero que me sepan perdonar :)

Paul Graham Facts en barrapunto

Intel anuncia un compilador con memoria transaccional

2007-09-24T11:11:00.000+02:00

Intel está trabajando en un compilador que gestiona memoria transaccional y que está ya en estado de prototipo. Al parecer se puede descargar y usar y para hacernos una idea ponen un miniejemplo de uso. Parece que esta tecnología está saltando de la investigación académica a la industria, habrá que ir viendo lo que da de si, porque, como ya comenté por aquí, hay gente que no acaba de verlo claro.

Intel anuncia un compilador con memoria transaccional en barrapunto

¿Necesitan una reescritura las bases de datos relacionales?

2007-09-21T13:30:00.000+02:00

Hoy en High Scalability enlazan a un artículo que 'denuncia' la obsolescencia del diseño e implementación de las actuales bases de datos relacionales: The End of an Architectural Era (It’s Time for a Complete Rewrite). Con una implementación que tiene en cuenta las arquitecturas actuales con sus cuellos de botella en cuanto a CPU, memoria y recursos de red, como ajustar el tamaño de los árboles-B al tamaño de la caché L2 o hacer los procesos de consulta en cada nodo con un solo hilo han conseguido rebajar hasta en dos órdenes de magnitud en el test TPC-C.

Este artículo forma una serie con “One Size Fits All”: An Idea Whose Time Has Come and Gone y One Size Fits All? – Part 2: Benchmarking Results en los que resalta no solo que el diseño y la implementación de los RDBMS son algo obsoleto sino que no son lo más adecuado para todos los escenarios (como ya se han dado cuenta los que se han encontrado con el problema)

Y ya un poco offtopic en este tema me gustaría resaltar una frase:

In the programming language community, there has been an explosion of “little languages” such as Python, Perl, Ruby and PHP. The idea is that one should use the best language available for any particular task at hand. Also little languages are attractive because they are easier to learn than general purpose languages. From afar, this phenomenon apears to be the death of “one size fits all” in the programming language world

O sea que en el futuro se llevará el programador políglota (bueno, o no, depende de quien mande...)

¿Necesitan una reescritura las bases de datos relacionales? en barrapunto

Sam Ruby y Erlang

2007-09-06T11:21:00.000+02:00

Asisto con una mezcla de envidia y escepticismo a la conversión a Erlang de Sam Ruby. Sam Ruby es un típico goleor tecnológico ™ Siempre está a la última en cuanto a estándares y lenguajes sobre la web. De hecho, algunos los hace él :) Como buen experimentador de tecnología, como buen gurú, hace sus apuestas de futuro. La última apuesta de Ruby, muy interesante, es a varias bandas: REST, Hadoop, Erlang/OTP y los Microformatos.

Asisto con envidia sobre todo por la fase de enamoramiento compulsivo por la que está pasando (muy interesante para los demás, por cierto) con Erlang, aunque resulta extraña en alguien con tanta experiencia como él. Sino no se puede explicar que diga, en su última entrada, algo tan bonito como:

Con muchos frameworks y lenguajes, tengo la sensación de que estoy trabajando con un armario de metal con capas de pintura para barcos; cuando se le hace un rasguño salen a relucir los bordes afilados. Con Erlang tengo la sensación de un armario victoriano de caoba; cuando uno raya en la madera simplemente sale a relucir más valiosa madera.

Pero este enamoramiento nos está dando a los demás la posibilidad de seguir sus pasos y disfrutar de su código, que no está nada mal... El último paso ha sido un conversor de Atom a JSON, pero anteriormente ha hecho alguna cosita más, como envíar XHTML-IM sobre TLS con Erlang y una pequeña entrada sobre Comunicación entre procesos en Erlang. A ver si dura :)

Sam Ruby y Erlang en barrapunto

La humildad como virtud del programador

2007-08-08T17:11:00.000+02:00

Y no me refiero a modestia frente a los otros (que también puede ser una buena cualidad) sino humildad con uno mismo y con lo difícil de hacer realmente bien este trabajo. En este sentido, sin más, le cedo la palabra a Jonathan Edwards, quien en Beautiful Code dice:

Una lección que he aprendido por la vía difícil es que no somos lo suficientemente listos. Incluso los programadores más brillantes cometen errores estúpidos con frecuencia. No solo errores de tecleo (typos) sino errores básicos de diseño que ponen en una situación difícil al código, y que a posteriori deberían haber sido obvios. La mente humana no es capaz de comprender en su conjunto la complejidad de un programa de tamaño moderado, mucho menos los sistemas monstruosos que construimos hoy en día. Esta es la amarga pastilla que nos tenemos que tragar, porque programar atrae y recompensa al inteligente, y su cultura fomenta la arrogancia intelectual. Me ha ha sido de inmensa ayuda trabajar con el supuesto de que soy demasiado estúpido para hacer las cosas correctamente. Esto me hacer usar de modo conservador aquello que ha funcionado, testear cautelosamente las nuevas ideas antes de confiar en ellas y por encima de todo, apreciar la simplicidad.

Curiosamente habla de un libro que me gustaría mucho adquirir y cuya existencia comenté por aquí.

Sobre el mismo tema, me gustaría recordar una famosísima cita de Brian Kernighan:

Depurar es el doble de difícil que escribir el código por primera vez. Entonces, si escribes código tan inteligentemente como te sea posible, no vas a ser, por definición, suficientemente listo para depurarlo.

Actualización: Creo que no ha quedado claro (he escrito la entrada demasiado rápido), pero lo que me parece curioso del comentario de Jonathan Edwards, es que es una justificación de porqué no escribió en Beautiful Code a pesar de estar invitado para ello, con una explicación tan inspirada que irónicamente merecería estar en el libro... :)

La humildad como virtud del programador en barrapunto

Varios sobre concurrencia: JVM, clasificaciones y consejos

2007-08-06T23:39:00.000+02:00

Una ración de enlaces relacionados con la programación concurrente:

El título lo dice todo: Where the metal meets JVM (An interview with Cliff Click) (Encontrado vía Pensamientos ágiles) Interesantísimo repaso a la implementación de la concurrencia en la máquina virtual de Java y de su relación con el hardware subyacente, con sutilezas en cuanto al modelo de memoria de cada arquitectura. Una buena conclusión, después de leerlos sería: no te fíes de que funcione, estudia bien las especificaciones, no vaya a ser que te lleves sorpresas con el run anyware ;)
Gracias a sammael, dos artículos sobre también sobre el mismo tema: Introduction to nonblocking algorithms y Synchronization optimizations in Mustang, ambos de Brian Goetz. Un vistazo a java.util.concurrent y algunos detalles sobre el presente y futuro de la concurrencia en java. Complementarios al anterior.
Herb Sutter en "How Much Scalability Do You Have or Need?" vuelve a clasificar las soluciones para aprovechar la concurrencia del hardware; en este caso se clasifica mediante la escalabilidad que se necesita, desde usar un solo core hasta la explotación de todos los recursos disponibles.
"10 Ways to Reduce Lock Contention in Threaded Programs" de Michael Suess, que también cita a Goetz. Tanto el primer enlace como éste subrayan la dificultad de pasarse de listo y tratar de programar sin bloqueos. Aquí se califica de optimización prematura y se proponen alternativas muy interesantes como granularizar los bloqueos (y evitar el big lock que seguramente debería ser la primera implementación...) o usar bloqueos de lectura o de escritura (si están disponibles y es posible). Se trataría del primer paso (los primeros diez pasos) en la optimización

Varios sobre concurrencia: JVM, clasificaciones y consejos en barrapunto

Un vistazo a Threading Building Blocks

2007-07-26T10:31:00.000+02:00

Según se puede leer en Ars technica: Intel open sources multicore programming tool Intel libera Threading Building Blocks, una herramienta hasta ahora propietaria que ayuda a la programación concurrente. La noticia ha salido en muchos sitios con comentarios interesantes (Slashdot, OSNews o en barrapunto)

Había oído hablar de esta herramienta en la entrevista a Sanjiv Shah de OpenMP en thinking parallel, pero como él trabaja en Intel siempre parece más sospechoso tratándose de un producto comercial. Ahora que lo han liberado he estado echándole un vistazo y bueno, creo que tiene su ámbito de aplicación y que puede ser muy interesante para facilitar algunas tareas sin reinventar alguna rueda.

Por analizar un poco la librería, consta como de cuatro partes:

Algortimos para bucles paralelos: parallel_for, parallel_reduce, parallel_while. Me ha parecido de lo más interesante de la librería porque es muy fácil de implementar y te ahorra mucha gestión. Al algoritmo se le pasa un contenedor sobre el que operar y un functor y el lo procesa en paralelo automágicamente, aunque parece ser algo parametrizable.
Contenedores seguros a accesos concurrentes: concurrent_hash_map, concurrent_vector, concurrent_queue. Usan internamente los bloqueos de grano fino y estructuras de datos sin bloqueos. Que bien que no haya que hacerlo por uno mismo, tiene pinta de ser complicadillo y muy fácil hacerlo mal
Utilidades para gestión de la concurrencia: mutexes de diverso tipo (si, recursivos también), locks, operaciones atómicas
Un gestor de tareas: una ayuda para programar orientado a tareas, threads más ligeros que los del sistema.

Desde que lo han hecho opensource le han asignado un domino propio, http://www.threadingbuildingblocks.org/ en el que hay bastante información. En particular el tutorial al que le he echado un vistazo es Intel® Threading Building Blocks: Tutorial

Por dar alguna nota no positiva... bueno, de momento solo soporta plataformas desde Intel Pentium 4, porteriores y compatibles, aunque en una de las FAQ del proyecto dicen que soportar todos los procesadores, sistemas operativos y compiladores es una las piedras angulares del proyecto. Veremos.

También me ha llamado la atención que dijesen (extraído del artículo de ars technica):

Java and .NET versions of TBB are currently being evaluated by Intel, and may eventually be announced. But Intel maintains that C++ is the company's priority, and it's where they'll be focusing the engineering resources that they're adding to the project.

Puede ayudar a hacer un poco más multiplataforma el código paralelizado en C++, aunque ya existen muchas librerías que lo hacen, como Boost.Thread. Supongo que estará bien usarlo cuando se necesita mucho rendimiento, una aproximación más sencilla no vale y paralelizarlo de este modo sale rápido y óptimo.

Un vistazo a Threading Building Blocks en barrapunto

¿Testeo o corrección?

2007-07-23T10:11:00.000+02:00

Andaba yo descubriendo otro blog, el de Andrew Koenig, cuando, a raíz de dos post suyos seguidos (uno de aserciones contra excepciones y otro sobre la depuración) he reparado en el tema... últimamente se hace mucho hincapié en el desarrollo guiado por pruebas, pero según se puede ver en el segundo post, hay veces que las pruebas, e incluso el uso, no son garantía de corrección.

Por eso es tan importante que las pruebas sean realistas. Por eso es tan importante extraer información del sistema en todas la etapas del ciclo de vida. Por eso es tan importante un buen sistema de registro del sistema. Pero sobre todo, por eso es importante pensar bien antes de codificar.

También me ha recordado uno esos principios de desarrollo polémicos: Los fallos, cuanto antes mejor (Fail Fast). Es uno de los principios en el diseño de Erlang. Como dice Joe Armstrong en una entrevista reciente:

La filosofía de Erlang fue siempre construir sistemas con un montón de procesadores baratos y permitir que fallen. No prevenimos el fallo; vivimos con él y recuperamos el sistema cuando ocurren.

Hay que recordar que se trata de fallos irrecuperables, no de casos raros dentro de la lógica del programa. Es mejor dejar claro un error fatal que tratar de continuar cuando no se puede y que se pierda el rastro de lo sucedido...

Por supuesto el título es falaz, debería haber sido Testeo y corrección y todos contentos, pero espero que se me permita el recurso :)

¿Testeo o corrección? en barrapunto

Leyes sobre el desarrollo de software con nombre propio

2007-07-18T11:05:00.000+02:00

Leo en haacked un listado de leyes que tienen algo que ver con el desarrollo de software y que además tienen nombre propio. Las hay serias y las hay humorísticas o simplemente pesimistas. Entre divertido, iluminador y deprimente.

De las que más me gustan:

La ley de Postel: Sé conservador con lo que envías, liberal con lo que recibes. Ya hablé de ella por aquí en ¿Postel o Dracón?
La ley de Parkinson: El trabajo se expande hasta consumir(*) todo el tiempo previsto para él. (*)Al menos, añadiría yo ;)
El principio de Kerchkhoff: En criptografía un sistema debería ser seguro incluso si todo acerca del sistema es de conocimiento público excepto una pequeña cantidad de información: la clave.

Habla también de las típicas leyes de estos casos, Murphy, Pareto, Sturgeon, Brooks...

Actualización: Joey deVilla inspirado en el post anterior ha hecho una recopilación francamente impresionante de leyes o dichos referidos al desarrollo del software.

Leyes sobre el desarrollo de software con nombre propio en barrapunto

Beautiful Code

2007-07-17T18:50:00.000+02:00

El bloguerío de esto de la programación anda revuelto por la publicación de un libro que parece muy interesante Beautiful Code: Leading Programmers Explain How They Think. Y es extraño que ande tan revolucionado sin una causa económica (al parecer lo que se saque con este libro irá a AI) pero viendo los autores quizás sea para tanto; que me suenen: Brian Kernighan, Tim Bray, Charles Petzold, Diomidis Spinellis, Douglas C. Schmidt, Yukihiro Matsumoto... aunque seguro que me dejo a alguien importante :) Cinco de ellos han sido ya nombrados por aquí, que cosas...

El libro consta de 33 capítulos en los que otros tantos autores piensan en alto sobre la arquitectura de sus proyectos (o de los proyectos de otro) los compromisos que se tomaron en su construcción y cuando fue importante romper las reglas. Dado lo heterogéneo del grupo de autores seguro que hay de todo un poco, pero el tema me parece tan interesante que inmediatamente lo he puesto en mi lista de deseos de anobii, aunque creo que dentro de poco se caerá de la lista :)

Por hacerme eco de algunos de los los comentarios que ha generado, Bryan Cantrill reflexiona sobre la recursividad en el mundo real y recibe interesantes respuestas. Alberto Savoia, uno de los autores, en "Pardon My French, But This Code Is C.R.A.P." reflexiona sobre el código malo, que es mucho más abundante, parafraseando a Strurgeon ("90% of everything is crap." - Sturgeon’s Law (one of many variants) "When applied to software, Sturgeon’s Law is hopelessly optimistic." - Savoia’s Corollary to Sturgeon’s Law) y a Sartre ("Hell is other people." - J. P. Sartre "Hell is other people’s code." - T-Shirt seen recently in Mountain View, CA) :)

Beautiful Code en barrapunto

Varios sobre concurrencia y patrones de diseño

2007-07-11T23:37:00.000+02:00

Ración de enlaces:

The Pillars of Concurrency por Herb Sutter Un resumen de los distintos escenarios en lo que se debe aplicar la concurrencia y de las posibles soluciones presentes y futuras. Comentado en LtU, The Pillars of Concurrency
Un par de vídeos (que aún no he visto, pero que tienen muy buena pinta): C++ Threads por Lawrence Crowl y Concurrency/message passing Newsqueak por Rob Pike (En la tendencia de que los materiales se cuelguen más "en bruto", vídeos y entrevistas en audio y video en lugar de transcritos... más fácil de hacer pero peor para buscar algo concreto y al ser en lenguaje oral es posible que peor para los no nativos. Aunque estos parece que con las diapositivas se pueden seguir bien...)
Un par de enlaces para reflexionar acerca de los patrones de diseño: Rethinking Design Patterns de Jeff Atwood, que viene a recordar los argumentos que se citaron por aquí en Enlaces varios (IV), que los patrones de diseño son síntomas de defectos en los lenguajes de programación. También Patterns I Hate #2: Template Method, que parece ser una serie en la que se medita sobre lo que se gana y se pierde con algunos patones.

Varios sobre concurrencia y patrones de diseño en barrapunto

Artículos de Alexandrescu sobre C++

2007-07-05T18:28:00.000+02:00

Leo a través de la sección de programación de reddit que Andrei Alexandrescu ha puesto en su página, disponibles para descarga y consulta los artículos que ha publicado en C/C++ User's Journal. Para quienes no lo conozcan, Andrei Alexandrescu es el autor de Modern C++ Design uno de los libros más influyentes y que más bien (¿y mal?) ha hecho por el C++ y sus lectores/escritores.

Me han llamado la atención especialmente Lock-Free Data Structures, Lock-Free Data Structures with Hazard Pointers y C++ and The Perils of Double-Checked Locking aunque solo sea por la introducción a la programación con bloqueos y sin bloqueos que me ha parecido hasta didáctica. También hay otros artículos sobre punteros inteligentes, constructores de movimiento y otras técnicas y temas diversos. Más para leer...

Artículos de Alexandrescu sobre C++ en barrapunto

El mejor código es el que no existe

2007-06-27T16:30:00.000+02:00

Bueno, la frase es demoledora y como toda frase lapidaria, conviene matizarla. Pero contiene tanta sabiduría (pesimista o realista, tu eliges) que creo que debe convertirse en uno de los mantras a repetirse frecuentemente.

Me lo recordó hace unos días la entrada de Jeff Atwood, The Best Code is No Code At All, muy recomendable. Si, antes de codificar, de desplegar miles de millones de líneas de código hay que pensárselo muy bien. Codificar es divertido, es muy estimulante... Pero antes de empezar, antes de abrir siquiera el editor debería pasar por la cabeza, en alguna milésima de segundo, al menos alguna de estas preguntas:

¿Debo escribir este código?
¿Estaré reinventado alguna rueda?
¿Soluciona el problema que quiero solucionar?
¿Se puede hacer mejor, más compacto, más legible, solo pensando un poquito antes de teclear?

Ya decía que conviene matizar: el programa vacío no hace nada y parece que es bueno que los programas hagan algo :) Se trata de un un recordatorio ¡Cuidado con el exceso de código! Creo que no hay aberración mayor que valorar la producción por líneas de código; es como si pagaran por bugs cometidos...

Jeff cita otro artículo en el que se exhorta a comenzar con código minimalista y completarlo a través de test. Es una buena idea, pero en estos tiempos de exaltación del Test-driven development conviene recordar también que los test no lo son todo, que pararse a pensar sigue siendo imprescindible.

En resumen serás esclavo de tu código, así que piénsatelo bien ;)

El mejor código es el que no existe, en barrapunto

AMQP ¿El nuevo Middleware universal?

2007-06-25T12:23:00.000+02:00

Según leo en Toward a Commodity Enterprise Middleware John O'Hara en JPMorgan, harto de "el problema del Middleware" se construyó (diseñó e implementó) el suyo propio para sus sistemas: AMQP (Advanced Message Queuing Protocol)

Se basa en el paso de mensajes y su gestión, permite mensajes del tipo publicación/suscripción, guardar y reenviar o envío de ficheros, separa la capa de trasporte de la de gestión de colas, tiene un protocolo binario que lo hace menos pesado en cómputo y ancho de banda que los Servicios Web y está preparado para pasar los firewalls sin perdida de seguridad. Suena bien.

Para no cometer uno de los errores de CORBA, existe ya más de una implementación, la de referencia: OpenAMQ, otra de Apache incubator, Apache Qpid, y una última en Erlang, RabbitMQ todas ellas software libre.

Al parecer la industria está entendiendo (por fin) que el modo de hacer tecnologías interoperables es haciendo implementaciones de referencia funcionales y libres, teniendo comunidad de usuarios (y no clientes) De todos modos habrá que ver si tiene una adopción tan masiva como pretenden. Lo debería ser si efectivamente el middleware se logra convertir (ojalá) en una Comoddity

(En El auge y la caída de CORBA (y lo que podemos aprender) se comentaba que existía ICE otro prometedor middleware libre, en este caso más parecido a CORBA, según parece)

AMQP ¿El nuevo Middleware universal? en barrapunto

Repasando Python 3000 (o Python 3.0)

2007-06-20T11:53:00.000+02:00

En su bitácora de Artima Guido van Rossum ha actualizado las previsiones que tiene acerca del proyecto llamado Python 3000 (que acabará siendo python 3.0)

Repasa las novedades de las versiones 2.6, que será versión puente y la 3.0. De esta última destacan el tratamiento de Unicode y entradas y salidas, el sistema de clases y tipos (con "anotaciones" que se podrán usar como tipado estático opcional), cambios en excepciones y enteros y algunos otros cambios como la eliminación de reduce() (que fue explicada en The fate of reduce() in Python 3000)

Al parecer romperá uno de los tabúes más sagrados de la informática: la compatibilidad hacia atrás, aunque habrá herramientas de conversión entre la versión 2.6 y la 3.0.

Lo comentan entre otros sitios en Lambda the Ultimate: Python 3000 Status Update, en donde, por supuesto, van a echar a faltar reduce()

Repasando Python 3000 (o Python 3.0) en barrapunto

Errores en el diseño e interpretación de experimentos

2007-06-18T11:09:00.000+02:00

Nota: Esto en planeta código es un poco offtopic, pero me parece lo suficientemente interesante para publicarlo en YAPW. Disculpen las molestias :)

Acabo de leer en la página de Peter Norvig una interesantísima recopilación de errores comunes en el diseño e interpretación de experimentos. Estamos demasiado acostumbrados a que se les den publicidad a determinados "estudios" que cometen algunos de los errores que Norvig repasa. Por ejemplo, hacer estudios sin una Prueba controlada aleatoria, confundir correlación con causa o mal entendimiento de la probabilidad condicionada(*) Una lectura recomendable y como decía el otro día, también de cultura general, porque afecta a la base de la metodología científica.

(*)Aunque ya comentaba Tío Petros que el ser humano parece peor equipado de lo que debería para entender intuitivamente la probabilidad, así que tenemos que hacer un esfuerzo adicional...

Errores en el diseño e interpretación de experimentos en barrapunto

Evidencias en el desarrollo de software

2007-06-07T23:10:00.000+02:00

Navegápolis es un blog que me gusta muchísimo. Hasta ahora no lo había referenciado porque su temática tiende más a la gestión y bueno, a mi me gusta más hablar de lo más pegado al código.

En este caso comenta Algunas evidencias del desarrollo de software extraídas directamente del libro Facts and Fallacies of Software Engineering. Haciendo una selección sobre la ya hecha por Juan Palacio:

El factor más importante en el trabajo con software no son las herramientas, ni las técnicas usadas por los programadores; sino la calidad de los programadores.
Normalmente las estimaciones se realizan al comenzar el ciclo de vida. Tiene un cierto sentido, si no fuera porque de esta forma se hace la estimación antes de definir los requisitos, y por lo tanto antes de conocer el problema.
La reutilización de pequeñas librerías o subrutinas llava empleándose 50 años de forma satisfactoria. La reutilización de grandes componentes es normalmente un problema sin resolver, aunque todo el mundo coincide en que es importante y deseable
Es 3 veces más difícil construir componentes reusables que no reusables (apunté en su día a Software Reusability: Myth Or Reality?)
La localización y limpieza de errores es la fase que más tiempo consume en el ciclo de vida.

Al parecer es el típico libro que, como The Mythical Man-Month, a uno le gustaría que se leyese más y en ámbitos menos técnicos. Del mismo modo a uno también le gustaría que determinadas estadísticas sobre proyectos fracasados fuesen más conocidas. Me parece de cultura general, pero debo estar equivocado :(

Evidencias en el desarrollo de software en barrapunto

Enlaces varios (V)

2007-06-04T19:54:00.000+02:00

Ración de enlaces que amenazaban con desbordar los marcados Keep New en bloglines, por si alguien les puede sacar utilidad:

Chaotic Perspectives en Adding Simplicity. De como hay que renunciar a alguna de las letras de ACID si se quiere sistemas muy pero que muy escalables. Me ha recordado, por el tema a Transactionless de Martin Fowler, a Building a high volume app without a RDMS or Domain objects comentado en Thoughts on Scaling Without a Database y a como hacen otros, como bloglines o flickr para manejar grandes cantidades de datos. Ah y por contrastar y por controversia Getting Your Priorities Straight. Scalability and Performance are the Least of your Worries
Una gran noticia que ha pasado casi desapercibida: GCC 4.2 ya soporta OpenMP. ¡Enhorabuena a los premiados!
En thinking parallel acabaron con las entrevistas a los gurús de la programación paralela y postean una interesante lista de blogs y enlaces sobre programación paralela y similares que aún no he sido capaz de procesar
Un artículo muy bonito de Matias Capeletto, el Camino de un ciclo. Describe con una sencillez envidiable la evolución de de C++, desde C hasta C++09, con sólo el ejemplo de un bucle. Actualización: vía lambda the ultimate me encuentro con un papel de Bjarne Stroustrup en el que repasa lo mismo, pero en 59 páginas. Por lo que cuentan toca además de temas técnicos temas políticos, así que debe estar bastante entretenido... Evolving a language in and for the real world: C++ 1991-2006 (pdf)
De como en Electronic Arts se crearon su propia STL para cubrir sus necesidades Quién pudiera dedicarse a reinventar ruedas más bonitas :)

Enlaces Varios (V) en barrapunto

Visualizando redes sociales: amigos en Barrapunto y menéame

2007-06-01T09:30:00.000+02:00

He hecho dos programitas que sacan las relaciones de amistad en en el interior de dos comunidades virtuales, barrapunto y menéame. Después he sacado imágenes gráficas de dichas relaciones, para visualizar, en lo posible, la compleja estructura de esas "relaciones sociales". Aunque el análisis de los datos no es muy riguroso, el resultado puede interesar tanto a los que les gusta el análisis de redes sociales online como a los que les gusta la ver programitas de ejemplo. En este caso están hechos en Erlang, y están acompañados de algún enlace que he ido recopilando en el camino.

La red social de barrapunto

Me gusta mucho ver gráficos relacionados con las ciencias que tratan de estudiar la complejidad, como los de visual complexity^*, no porque sepa mucho de ello, sino como mero aficionado. El caso es que llamó mucho la atención también la representación visual de la red social de feevy (comentado por gente que sabe de esto, de entre los cuales me excluyo, en Un mar de flores).

(^*Otra actualización:Parece que alguien envió esta entrada a visualcomplexity y ha sido aceptada: Social Network of barrapunto. Gracias al anónimo submitter que lo envió. Me siento muy halagado ;) )

Pues bien, el otro día se me ocurrió que se podría hacer lo mismo con los usuarios de barrapunto, que en el fondo no deja de ser una red con unas relaciones muy bien definidas: la relación de amistad y enemistad. Y también se me ocurrió que lo podría hacer con un programita que capturara esas relaciones y las dejara en formato DOT. Para ello he usado Erlang. ¿Por qué? Pues porque si. Se podía haber hecho con wget o curl y awk, y/o perl o ... Pero bueno, me apetecía hacer algo más que un Hola mundo! en este lenguaje. Y, a decir verdad, me lo he pasado muy bien programando en él y descubriéndolo.

Comentaba Alex que para visualizar la redes sociales solían usar SocNetV, pero que en este caso usó Graphviz Ambos admiten para modelar las redes el lenguaje de definición DOT. Son los programas que yo he usado para los gráficos que viene a continuación.

Primero la imagen tal cual, sin ordenar demasiado, con socnetv:

Intentando desenredar la red, estos programas tienen criterios para representar la información en función de una serie de parámetros que suelen calcularse en función del las distintas definiciones de centralidad...

Pegaré aquí las imágenes que creo que van a dar una información más interesante. Esta siguiente está generada con el socnetv, aplicando una de las ordenaciones en circulo por centralidad (en este caso, creo, "in degree centrality"):

Usando el comando nop bp.file | twopi -Tpng -o bptwopi.png, de graphviz:

La imagen que más me gusta es esta, que da alguna información de la organización, pero acercándose uno puede ver detalles (usando nop bp.file | fdp -Tpng -o bpfdp.png)... Lo malo es que subiéndola a flickr se baja tanto la resolución como la calidad. Se admiten sugerencias para subir las imágenes a un sitio donde las dejen poner a mucha resolución...Actualización: Gracias a resete-e y su cuenta de flickr pro hay imágenes de alta resolución. Muchas gracias ;)

La red social de menéame

Mientras iba haciendo el primer programa, se me ocurrió que casi por el mismo precio podría tener un segundo programa que obtuviese los datos de menéame. Solo apuntar que en este caso la red está aún más enmarañada porque hay más actores y más relaciones...

Las imágenes análogas a las anteriores serían:
(Nota: La última imagen parece en negro, pero si se pincha sobre ella sale a resolución completa...)

Los datos

Segunda actualización: No tenía donde poner los ficheros de datos, pero Eduardo de http://hombrelobo.com/ me cedió amablemente espacio, así que todos los interesados en los datos en bruto pueden jugar con ellos y con graphviz, SocNetV y con lo que quieran. Traté de embeber los svg en HTML, pero creo que no merece la pena porque son muy grandes y firefox (al menos) se queda un poco tonto. Mejor bajárselos y verlos con algún visor... Bueno, los enlaces:

Que los disfruten ;)

"Análisis"

Se ve que hay islitas, cosa que me ha sorprendido, por aquello de los seis grados de separación, pero también lo comentaba Ugarte en su entrada. Pensándolo un poco más detenidamente, tanto en este caso como en el de los enlaces feevy son casi todas relaciones fuertes en el sentido en el que se comenta en un mar de flores. No todas las relaciones débiles entre usuarios (yo leo poco a tal, yo conozco a cual, pero no le sigo) no salen en este esquema, es seguro que en ese caso todos estarían conectados... No obstante, en el caso de las gráficas de las dos comunidades, las islas son menores que en feevy, la red está más clusterizada... (este razonamiento hay que tomarlo con precaución: yo soy sólo un aficionado ;))

Más redes

Se me pasó por la cabeza un proyecto más ambicioso en en que se definiesen parámetros de búsqueda (expresiones regulares y alguna otra cosa...) pero me resultó demasiado grande para el poco uso que le iba a dar. Si alguien tiene ganas, se puede modificar muy fácilmente para sacar la red de slashdot (casi trivial) o de digg... ¿twitter? (por cierto, que alguien sacó el gráfico de los usuarios holandeses de twitter, también vía de Ugarte)

Erlang

En otro orden de cosas... lo he programado en Erlang y ha sido una gratísima experiencia. Hay quien dice que la iteración es humana, la recursión es divina, pero Erlang con su tail recursion (recusión terminal) te la facilita o más bien te la hace obligatoria para recorrer los conjuntos de datos. Pero tanto el uso de esa recursión, el manejo de listas y tuplas como la sintaxis me ha resultado muy muy natural. El hecho de que cada "sentencia" sea separada por comas, el final un punto, las flechas... todo muy intuitivo, un poco como escribir un texto, salvando las distancias ;)

Otro punto fuerte de el lenguaje es el tratamiento de la concurrencia, que es muy sencillo teniendo en cuenta una serie de premisas que ya comentó Joe Armstrong en su entrevista en Thinking parallel. Erlang no usa threads nativos sino que tiene sus propios "procesos ligeros" con lo que logra una gran escalabilidad en cuanto a número de procesos disponibles.

En este ejemplo no se observa muy bien, porque no creo que el programa lo requiriese, pero el lector atento del código podría añadirle una cierta concurrencia para hacer peticiones en paralelo, pero en este caso no es muy útil...

Aquí voy a pegar el código que he usado tal cual, con la advertencia que no es un código muy probado y tal y cual, etc, etc :)
(por cierto y a modo de recordatorio, el comando que he usado para generar el código HTML con resaltado de sintaxis es enscript --highlight=erlang --color --language=html --output=soc_graph.html soc_graph.erl)
Blogger se comió los tabuladores, los he sustituido por espacios...
El programa de barrapunto:


-module(soc_graph).
-export([do_it/0]).
-export([get_friends/1]).
-export([get_users/1]).

do_it() ->
  init_file(),
  get_users({self(),1}),
  end_file().

%get_users gets user list
get_users({Pid,Step}) -> get_users(0,{Pid,Step}).
get_users(Pan,{Pid,Step}) ->
  URL=io_lib:format("http://barrapunto.com/search.pl?threshold=-1&op=users&sort=1i&start=~.10B",[Pan]),
  { ok, {Status, Headers, Body }} = http:request(URL),
  {match, Matches}=regexp:matches(Body,"barrapunto.com/~.*/journal"),
  Lst_new = [string:substr(Body,Start+16 ,Length-16-8 ) || {Start,Length} <- Matches],
  case Lst_new of
      [] -> get_users_done;
      %_ -> spawn(soc_graph,get_friends,[{Pid,Lst_new}]),
      _ -> get_friends({Pid,Lst_new}),
      get_users(Step+Pan,{Pid,Step})
  end.
    
%get_friends gets user id and get friend list
%Pid is unused (refactoring?)
get_friends({Pid,[H|T]}) ->
  URL=io_lib:format("http://barrapunto.com/~~~s/friends",[H]),
  io:format("~s~n",[H]),
  { ok, {Status, Headers, Body }} = http:request(URL),
  Reg_exp="barrapunto.com/~.*/friends",
  {match, Matches}=regexp:matches(Body,"barrapunto.com/~.*/friends"),
  Frnd_new = [string:substr(Body,Start+16 ,Length-16-8 ) || {Start,Length} <- Matches],
  New_user=replace_forb_chars(H),
  Frnd_flt=lists:filter(noself(New_user),Frnd_new),
  to_file([{H,Frnd_flt}]),
  get_friends({Pid,T});
get_friends({Pid,[]}) -> ok_friends.

noself(H) ->
fun(S) ->
  case regexp:match(S,H) of
      {match,_,_} -> false;
      nomatch -> true;
      {error,_} -> true
  end  
end.

%replace_forb_char replaces special (regexp) characters in user name
replace_forb_chars(S) ->
replace_forb_chars(S,".$()*+").
replace_forb_chars(S,[RH|RT]) ->
  Regexp="["++[RH]++"]",
  {ok,Newstr,_}=regexp:gsub(S,Regexp,Regexp),
  replace_forb_chars(Newstr,RT);
replace_forb_chars(S,[]) ->
  S.
    


%to_file writes friends into DOT file
to_file(Frnd) ->
  %this line violates DRY (Refactor?)
    {ok,F}=file:open("bp.file",[write]),
  to_file(F,Frnd).
to_file(F,[{User,Frnds}|T]) ->
  %TODO: Format of map/frineds
  Out_Frnd= fun(Frnd)-> io:format(F,"\"~s\" -> \"~s\"~n",[User,Frnd]) end,
  lists:map(Out_Frnd,Frnds),
  to_file(F,T);
to_file(F,[]) ->
  file:close(F),
  ok_to_file.

%init_file initializes the DOT file  
init_file() ->
  %this line violates DRY (Refactor?)
    {ok,F}=file:open("mnm.file",[write]),
  io:format(F,"digraph mydot {~nnode [color=red, shape=ellipse];~n",[]),
  file:close(F).

%end_file inserts the coda in the DOT file  
end_file() ->
  %this line violates DRY (Refactor?)
    {ok,F}=file:open("mnm.file",[append]),
  io:format(F,"[weight=1, color=black];~n}~n",[]),
  file:close(F).

La modificación para menéame:


-module(soc_graph).
-export([do_it/0]).
-export([get_friends/1]).
-export([get_users/1]).

do_it() ->
  init_file(),
  get_users({self(),1}),
  end_file().

%get_users gets user list
get_users({Pid,Step}) -> get_users(1,{Pid,Step}).
get_users(Pan,{Pid,Step}) ->
  URL=io_lib:format("http://meneame.net/topusers.php?sortby=0&page=~.10B",[Pan]),
  { ok, {Status, Headers, Body }} = http:request(URL),
  {match, Matches}=regexp:matches(Body,"/user/[^\"]*"),
  Lst_new = [string:substr(Body,Start+6 ,Length-6) || {Start,Length} <- Matches],
  case Lst_new of
      [] -> get_users_done;
      %_ -> spawn(soc_graph,get_friends,[{Pid,Lst_new}]),
      _ -> get_friends({Pid,Lst_new}),
      timer:sleep(1000),
      get_users(Step+Pan,{Pid,Step})
  end.
    

%get_friends gets user id and get friend list
%Pid is unused (refactoring?)
get_friends({Pid,[H|T]}) ->
  URL=io_lib:format("http://meneame.net/user/~s/friends",[H]),
  io:format("~s~n",[H]),
  Reg_exp="friends_of=[^\"]*",
  { ok, {Status, Headers, Body }} = http:request(URL),
  {match, Start, Length}=regexp:match(Body,Reg_exp),
  User_Id = string:substr(Body,Start+11 ,Length-11 ),
  Frnd_new=get_friends_page(1,User_Id,[]),
  New_user=replace_forb_chars(H),
  Frnd_flt=lists:filter(noself(New_user),Frnd_new),
  to_file([{H,Frnd_flt}]),
  get_friends({Pid,T});
get_friends({Pid,[]}) -> ok_friends.


%get_friends_page gets friend list
%Pid is unused (refactoring?)
get_friends_page(Page,User_Id,Frnd) ->
  Reg_exp2="/user/[^\"]*",
  URL2=io_lib:format("http://meneame.net/backend/get_friends_bars.php?id=~s&p=~.10B&type=from",[User_Id,Page]),
  { ok, {Status2, Headers2, Body2 }} = http:request(URL2),
  {match, Matches}=regexp:matches(Body2,Reg_exp2),
  Frnd_new = [string:substr(Body2,Start2+6 ,Length2-6) || {Start2,Length2} <- Matches],
  case Frnd_new of
      [] -> Frnd;
      _  -> get_friends_page(Page + 1,User_Id,lists:append(Frnd,Frnd_new))
  end.

noself(H) ->
fun(S) ->
  case regexp:match(S,H) of
      {match,_,_} -> false;
      nomatch -> true;
      {error,_} -> true
  end  
end.


%replace_forb_char replaces special (regexp) characters in user name
replace_forb_chars(S) ->
replace_forb_chars(S,".$()*+").
replace_forb_chars(S,[RH|RT]) ->
  Regexp="["++[RH]++"]",
  {ok,Newstr,_}=regexp:gsub(S,Regexp,Regexp),
  replace_forb_chars(Newstr,RT);
replace_forb_chars(S,[]) ->
  S.
    
%to_file writes friends into DOT file
to_file(Frnd) ->
  %this line violates DRY (Refactor?)
    {ok,F}=file:open("mnm.file",[append]),
  to_file(F,Frnd).
to_file(F,[{User,Frnds}|T]) ->
  %TODO: Format of map/frineds
  Out_Frnd= fun(Frnd)-> io:format(F,"\"~s\" -> \"~s\"~n",[User,Frnd]) end,
  lists:map(Out_Frnd,Frnds),
  to_file(F,T);
to_file(F,[]) ->
  file:close(F),
  ok_to_file.

%init_file initializes the DOT file  
init_file() ->
  %this line violates DRY (Refactor?)
    {ok,F}=file:open("mnm.file",[write]),
  io:format(F,"digraph mydot {~nnode [color=red, shape=ellipse];~n",[]),
  file:close(F).

%end_file inserts the coda in the DOT file  
end_file() ->
  %this line violates DRY (Refactor?)
    {ok,F}=file:open("mnm.file",[append]),
  io:format(F,"[weight=1, color=black];~n}~n",[]),
  file:close(F).

Referencias sobre Erlang

Sequential programming y Concurrent Programming: primeros pasos en Erlang
Erlang stdlib: lo primero que debería mirar uno de un nuevo lenguaje. Reinventar la rueda es una cosa muy fea, a no ser que vayas a hacer una rueda más bonita ;P
Erlang Cookbook: ejemplos de cosas comunes en erlang. Recetillas
Comenté alguna otra referencia para empezar con este lenguaje en Programando con Erlang

¿Postel o Dracón?

2007-05-03T11:50:00.001+02:00

La primera vez que leí sobre la ley de Postel: "Sé conservador con lo que envias, liberal con lo que recibes"(*) me pareció tan filosóficamente interesante que intenté escribir una entrada al respecto, pero no supe, porque no tengo el gen gurú necesario para ello. Por eso, no está mal recurrir a los gurús de verdad, que sean ellos los que digan parte de lo que le ronda a uno por la cabeza. El caso es que en una semana dos blogstars de esto de la programación y la tecnología han comentado algo relacionado, así que les cedo la palabra, claro (cada una de las entradas da mucho más de si, pero claro, para eso está enlazadas, para que se lean ;)):

Jeff Atwood en Coding Horror habla de en "JavaScript and HTML: Forgiveness by Default" de como siendo tolerante a fallos se crea un ecosistema más robusto. En sus palabras: "el perdón por defecto es un requisito imprescindible para una adopción a gran escala tan masiva como la de la web". Eso si, no habla del precio que hay que pagar, porque una implementación tolerante a fallos, en general es más compleja. Hay que preguntarse ¿qué hacer con los errores?
Sam Ruby en "Different Drummer" habla del diseño de HTML5 y se pregunta si ganarán los que siguen a Dracón o a Postel. Él se decanta por Postel, claro. El resto del post muy interesante también. Muy gurú. Muy Sam Ruby :)
Por cierto que habla de Silverlight y dice que también es Draconiano. En eso no me voy a meter, le cedo la palabra a otro que sabe más que yo (no voy a llamarle gurú porque igual no le gusta): Yogur Griego: "Silverlight ¿el imperio contraataca?"
Hablando de gurús y aunque no es nuevo, no me resisto a enlazar otra vez "Objects Have Failed" de Richard P. Gabriel debido a que uno de sus argumentos para la irrelevancia de los objetos es (exagerando creo, tiene algún recurso literario, quizás por eso me gusta más...):
En el viejo mundo nos centrábamos en la eficiencia, la limitación de recursos, el rendimiento, los programas monolíticos, los sistemas aislados, los programas hechos por un sólo autor y las aproximaciones matemáticas. En el nuevo mundo pasarán a primer plano la robustez, la flexibilidad, la adaptación, los sistemas distribuidos, los programas de múltiples autores y las metáforas biológicas de la computación.

(*)Otras veces nombrado como "Sé conservador con lo que haces, liberal con lo que aceptas de otros". El enunciado es susceptible de ser políticamente interpretable más aún en esta segunda encarnación del principio. En este caso yo creo que es más bien interpretable desde el punto de vista de la ética. Como referencia se puede leer lo que dice Tim Berners-Lee acerca de esto y de una frase (que fué durante un tiempo firma mía) acerca del funcionamiento descentralizado "We have no kings or presidents. We believe in rough consensus and running code". Eso si, con grandes influencias de Unitarismo universalista, una religión más o menos buenrollista, si es que eso es posible...

"¿Postel o Dracón?" en barrapunto

Entrevista sobre YARV

2007-04-30T14:48:00.000+02:00

Vía la sección de reddit de programación (que a pesar de su sistema de filtrado y puntuación, también tiene el mal del exceso de información... ) he encontrado una serie de entrevistas sobre la nueva máquina virtual que ejecutará Ruby: YARV. Responden las dos personas más involucradas en ello, Matz (recordemos, el creador del lenguaje) y a Koichi Sasada, el desarrollador principal.

En la segunda parte de la entrevista se habla de las distintas implementaciones de los entornos de ejecución de Ruby. Por resumir, Koichi dice: "Necesitamos especificaciones, buenos test y buenos benchmarks". Por las bitácoras de barrapunto se ha hablado de ello, porque Robert h Quinn está trabajando en los test, según comentaba en GSoC 2007 : De que va mi proyecto

Sobre todo me ha gustado la tercera parte, sobre el pasado el presente y el futuro de los threads en Ruby.En esta parte se argumentan las razones por las que se abandonó la implementación de threads en espacio de usuario por el uso de los threads nativos del sistema, además de explicar como eso afecta el soporte de continuaciones.
(Hablamos de estas cosas hace unos meses en Noticias sobre Ruby 2.0 (que al parecer no son sobre 2.0 estrictamente...)

Actualización: Como me comenta Robert h Quinn, en On Ruby tienen una serie de entrevistas a los desarrolladores de distintas implementaciones de entornos de ejecución de Ruby. Más para leer...

"Entrevista sobre YARV" en barrapunto

Programando con Erlang

2007-04-18T23:53:00.000+02:00

Dave Thomas ha escrito una serie de apuntes introductorios a erlang, aprovechando el nuevo libro, Programming Erlang de Joe Armstrong (un esfuerzo publicitario, porque el libro se publica bajo el amparo de los programadores pragmáticos, pero aquí nos da igual, ¿no?)

Entonces pasemos a los enlaces:

A First Erlang Program Un programita para usar la API de servicios web de amazon
Adding Concurrency to Our Erlang Program El mismo programa, pero concurrente

Y algunos enlaces más

What's all this fuss about Erlang?
por Joe Armstrong, una introducción al lenguaje
Concurrent Programming in Erlang, Part I (pdf 884 KB) un libro introductorio con el que estuve trasteando hace un tiempo, también de Armstrong (entre otros)

Publicitado también desde los programadores pragmáticos... ¿le pasará lo mismo que a Ruby? ¿tendrá el mismo crecimiento? Personalmente lo dudo, a pesar de que el lenguaje tiene unas características muy interesantes, entre otras el tratamiento de la concurrencia. La principal pega la comenta el propio Armstrong en el artículo introductorio: ¿Es Erlang difícil? No, pero es diferente.

(Se habló en barrapunto de él hace bastante tiempo en Otro lenguaje de programación: Erlang)

Programando con Erlang en barrapunto

Twitter, RoR, escalabilidad y flames

2007-04-17T14:37:00.000+02:00

Ha sido imposible escapar al contrahype: un desarrollador de twitter, el servicio webdospuntocero de moda (¿o ya no está de moda?, no sé, a mi que no me pregunten, que yo en estas cosas estoy muy démodé), Alex Payne, declaró que Ruby on Rails no escala, que tiene un cuello de botella en la base de datos (comentado en barrapunto en Entrevista con Alex Payne, uno de los desarrolladores de Twitter) y se desató el multiflame. Debido a la relevancia y al ruido conseguido por los fans de RoR parece que se les tenía ganas... El hecho es que se ha levantado una polvareda de bytes bastante importante, lo que en estos tiempos significa una conversación fragmentada de post cruzados en muchísimos blogs y alguna lista de correo, que aún quedan :)

Tengo que reconocer que me gustan los flames, sobretodo si no me tocan de cerca, porque en general y con un poco de suerte, de tanto ruido se puede extraer información interesante...

Aunque, debo confesar, esta vez me ha sorprendido que la onda expansiva ha llegado hasta la blogosfera hispana, cosa que no suele ser usual... Primero pues, los enlaces en castellano. Ah, seguro que me dejo algo, se admiten sugerencias de enlaces interesantes :)

Ricardo Galli: Los problemas de Twitter (y la escalibilidad)
Un muy reciente La polémica sobre la escalabilidad de Rails (tan reciente que lo ha escrito mientras yo redactaba esto y que es un buen resumen y además apunta posibles soluciones...) de Sergio Gil (porras), aunque ya dejó algún mensaje interesante en barrapunto: La escalabilidad de Rails
rvr ya hizo referencia hace casi un año a un artículo, Does Rails Scale Down? que pone de manifiesto el posible peligro.
"Los dolores de Ruby on Rails" en la lista de correo ror-es

Ahora en inglés. De David Heinemeier Hansson:

Twitter trouble. Primera reacción de DHH (Parodiada en DHH translation con mucha acidez. Puro flame.)
Scaling to multiple databases with Rails Solución rápida a la conexión a distintas bases de datos con rails

Ha habido respuesta de diversa índole, pero se pueden rastrear fácilmente. Solo voy a resaltar alguna que se va por las ramas, que son las que más me interesan ;)

Is platform selection premature optimisation? ¿cuando se empieza a optimizar? Dice el dicho, comentado ahora mismo en la bitácora de fernand0, que Primero haz que funcione, segundo hazlo elegante y después hazlo que sea rápido Y estoy completamente de acuerdo, pero a twitter el tercer paso le vino demasiado rápido, me temo... O sea ¿cuando llega el momento de optimizar?
Twitter and Rails brouhaha Sobre la conveniencia de evaluar lenguajes y frameworks separadamente
Actualización: Me olvidé de poner uno interesante "Reddit: Language vs. Platform" en Coding Horror, en el que se recuerda el caso reddit con interesantes lecturas también...

Dice Juan Lupión en "sobre railes" que permanezcamos a la escucha. Desde luego, un flame es un flame ;)

Twitter, RoR, escalabilidad y flames en barrapunto

Orientación a objetos: algunas críticas

2007-04-10T23:55:00.000+02:00

Vía Reddit me he encontrado con un escrito, intencionadamente provocador diría yo, de Joe Armstrong (de nuevo): Why OO Sucks. No obstante me gustaría resaltar los argumentos, que dan que pensar y para eso estamos aquí:

Las estructuras de datos y las funciones no deberían ir juntas:
Esto es una característica en principio ventajosa de la POO, pero puede ser una servidumbre, además de que no deja aprovechar algoritmos genéricos al estilo de C++ con la STL. No obstante hay que decir que variaciones de la programación orientada a objetos permiten el Duck typing, como en python o ruby que favorece la posibilidad de hacer algoritmos más genéricos...
Todo debe ser un objeto:
Relacionada con la anterior, todo dato debe ser un objeto y tener la parafernalia necesaria para serlo. En esto los lenguajes van mejorando, creo yo, reduciendo lo necesario para ser objeto, a veces haciéndolo implícito.
La estructura de datos está dispersa por todos lados:
Y no le falta razón. Esto es particularmente importante si las estructuras de datos van a ser usadas para hacer la interoperabilidad entre sistemas heterogéneos
Los objetos tienen un estado privado:
Esta es una crítica muy desde la perspectiva de la Programación funcional (bueno, las otras también...) pero muy interesante. La primera vez que oí eso de que en Erlang (por ejemplo) no se podía reasignar variables me resultó muy chocante, pero ver hacer las cosas de un modo diferente es muy ilustrativo a veces... Es el "truco" de estos lenguajes de no usar el estado para evitar efectos laterales, muy relevante también para programación concurrente.

Mi opinión sobre el tema ya la expresé en ¿Ha muerto la orientación a objetos?: Conceptos como encapsulamiento, interfaces, reusabilidad pueden seguir siendo útiles, pero hay que evaluar el impacto positivo, no sea que matemos moscas a cañonazos...

Y ahora una serie de enlaces sobre el mismo tema:

Object-Oriented Considered Harmful
OOP Is Much Better in Theory Than in Practice Una crítica desde el punto de vista del programador de a pie, comentado en lambda the ultimate y The Server Side
¿Porque ARC no es especialmente orientado a Objetos? por Paul Graham
Listado de críticas a la orientación a objetos en dmoz que enlaza a un muy interesante Objects Have Failed de Richard P. Gabriel
Software Reusability: Myth Or Reality? Una de las supuestas ventajas de la OO es la reusabilidad, pero ¿es posible conseguirla?
Y por fin algo por contrastar: Invasion Of The Dynamic Language Weenies como respuesta a los fans forofos de los lenguajes dinámicos...

"Orientación a objetos: algunas críticas" en barrapunto