diego sevilla’s weblog
it is better to remain silent and be thought a fool,
than to open your mouth and remove all doubt -- groucho marx

28/3/2011

martina

Filed under: english, español, fotografía/photo — Diego Sevilla @ 10:38 — In English


martina, originally uploaded by dsevilla.

Vino corriendo hacia mí y salió esta foto :)

She came running to me and I shot this! :)

19/11/2010

Hispania F1 Racing Team

Esta semana (el martes, creo recordar) hubo una charla de este grupo de fórmula uno con capital español (murciano, para más señas). Quizá es que esperaba más de esto, mucha tecnología al límite, ingeniería de desarrollo, pruebas, ciclos cortos de desarrollo, etc., pero me desilusionó un poco la charla.

Explicaré por qué. No pude ir al principio de la charla porque estaba dando clase en el máster de la asignatura «Software como servicio y distribuido» hasta las 5 de la tarde, y la conferencia había empezado a las 4. Con todo, cuando llegué estaban en turno de preguntas, y pude hacerme una idea de lo que había sido la presentación, aunque me habría gustado verla desde el principio.

Parece que no fue excesivamente técnica, al menos en la parte que nos interesa a los informáticos, porque una de las preguntas que se hicieron tuvo que ver con el lenguaje de programación o entorno que utilizaban. La respuesta del ingeniero informático:

- Utilizamos C#. Cuando entré a trabajar en la empresa venía de experiencia de programación en C++. Cuando me explicaron lo que tenía que hacer me eché las manos a la cabeza. Eso no se podía hacer con C++. Aprendí en un par de semanas C# e hicimos el programa.

Como se puede suponer, tengo miles de comentarios a este respecto. Primero, sí que pude ver el interfaz gráfico que habían hecho. Interfaces con esa complejidad estamos acostumbrados a hacer en C++ y Qt para SAES en la Cátedra de Software libre, y no nos echamos las manos a la cabeza. El hecho de que un ingeniero en particular no tenga el conocimiento suficiente, o tenga que tomar una decisión acelerada no sé si debería decidir una estrategia para el futuro. Además, aprender en un par de semanas C# no parece lo más adecuado para hacer un programa de calidad, pero en fin. Continuaba:

- La salida de este programa son ficheros XML que utilizamos para comunicar con los equipos de carrera

Esto es mi favorito. Al nombrar XML parece que todo el mundo dice «ah, claro». XML ya hace que los programas interactúen mágicamente… En fin. ¿Por qué no JSON/YAML? Reconozco que esto es más una manía mía, pero ¿por qué en los nuevos desarrollos de bases de datos (CouchDB, MongoDB) no se utiliza XML sino formatos más sencillos y expresivos?

Me hubiera gustado preguntarles por sus ciclos de desarrollo, pruebas, etc., pero como había llegado tarde, ahí se quedó.

La conversación, a raíz de otra pregunta, giró hacia la colaboración de estos grupos con la Universidad. Uno de los ponentes (no recuerdo su nombre) había estado trabajando para Red Bull anteriormente, y contaba proyectos de colaboración que sus antiguos patronos tenían con Universidades. No es el caso de Hispania, según decía, por problemas políticos, o por problemas de medios de las universidades (laboratorios con material especializado, etc.)

En este punto hice una pregunta, dado que tenemos experiencia en colaborar con una empresa, pregunté que para tener una colaboración a nivel de informática no se necesitaban laboratorios especializados (sólo ordenadores y personas). Uno de los ingenieros del equipo (presumo) me interrumpió gritando que «¿Cómo que no necesitas? Para empezar necesitas un superordenador». Intenté responderle a medio hacer la pregunta que no se necesita un supercomputador in situ sino una persona que sepa cómo hacer los programas paralelos que aprovechen en superordenador, y una conexión internet para conectarse al CESGA o al Mare Nostrum (en los tiempos de Internet, los ordenadores no tienen que estar en tu habitación, aparte de que tenemos Ben Arabí, creo recordar de la última vez que estuve allí… Además, ¡¡programan en C#!!, ¿qué supercomputador???)… Cuando me dejó terminar la pregunta, la respuesta del ponente era la misma, cuestiones políticas que escapaban a su nivel de puesto de trabajo que hacía que no se colaborara con la Universidad tampoco en informática. Creo que nuestra experiencia en testing, modelado, etc., sería interesante para ellos, pero aquí estamos.

Finalmente, fallo garrafal (según mi punto de vista). Se quejaban de que tenían un presupuesto limitado, y utilizan software propietario, licencias, etc., en vez de sacar partido al software libre (incluso para C# existe Mono…).

Espero que los ingenieros en otras ramas estén más al día, porque si no, el equipo va a ganar pocas carreras :)

18/11/2010

.

Filed under: General, español, fotografía/photo — Diego Sevilla @ 23:32 — In English


., originally uploaded by dsevilla.

Fotos del concurso de fotografía en Mula del pasado domingo. De esta me gustó especialmente el fondo de colores otoñales. No creía que iba a conseguir esto en Mula :)

7/10/2010

Nuevo dominio para la Cátedra SAES

Filed under: General, español, free software/software libre — Diego Sevilla @ 13:17 — In English

Como alguna vez he escrito por aquí, colaboramos con la empresa SAES de Cartagena y San Fernando para realizar investigación dentro del marco de la Cátedra SAES/UMU de software libre, aplicaciones críticas y en tiempo real. Sólo un pequeño comentario para decir que hemos aunado las direcciones de la cátedra y hemos creado un dominio .org: www.catedrasaes.org. Dentro de él podéis encontrar la lista, incompleta todavía, de proyectos en los que estamos trabajando, e incluso un blog.

19/6/2010

Saramago, por Garzón

Filed under: español, crítica/critics — Diego Sevilla @ 11:21 — In English

Me he propuesto bucear todo lo que pueda en esta figura, la de José Saramago. Sinceramente, entre el estrés de la vida cotidiana, trabajo, hija, investigación, etc., uno se va dejando cosas por el camino. Pero no quiero perder la oportunidad de conocer mejor a uno de los pocos verdaderos iconos del pensamiento crítico con mayúsculas. Garzón escribe de él en público:

Con su muerte se va uno de los escasos intelectuales comprometidos, uno de los más preclaros, por su coherencia y su capacidad para unir acción social, literaria y política. Siempre fue una persona fiel a sus principios. Hoy día, cuando se echan tanto en falta referentes de todo orden, su presencia pública era un lujo.

Y que lo digas, Baltasar. Descanse en paz. Su legado nos sirve cada día.

16/5/2010

Garzón, estamos contigo

Filed under: General, español, crítica/critics — Diego Sevilla @ 12:56 — In English

Siento que después de tanto tiempo escriba en el blog para esto. Pero la verdadera pena es que esté pasando de verdad. Hoy me he paseado por Planet Murcia y me he encontrado con la entrada de El rey de la baraja: No es Garzón, es el franquismo, que me ha llevado a dos artículos muy esclarecedores de Martínez Soler: Franquismo y Gürtel: Aviso a navegantes y Acoso a Garzón: ¿Venganza política y/o corporativa?, este último acompañado de una imagen de eneko bastante acertada:



PD. Pronto empezaré a publicar más. Estamos haciendo muchos avances muy interesantes en la Cátedra SAES, y Martina está creciendo a marchas forzadas y más bonita cada día.

9/2/2010

Primera aproximación de un mecanismo de actores para C++

Filed under: General, español, código/code, free software/software libre — Diego Sevilla @ 13:34 — In English

Desde hace tiempo quiero escribir esta entrada, pero por falta de tiempo no he podido. El mecanismo de actores se utiliza en lenguajes de programación como Erlang y Scala para sincronizar diferentes «actores» que están funcionando en el sistema. Tradicionalmente, la programación con hilos (salvo en casos como BSP, por ejemplo) se ha realizado básicamente como la programación monoproceso, pero haciendo que el programador tuviera en la cabeza las posibles colisiones que varios hilos ejecutando un código podrían tener.

La otra cara de esta moneda la han tenido lenguajes y paradigmas que cambiaban la manera de programación hacia esquemas que hicieran más fácil escalar en el número de hilos/cores a la vez que permitían una programación más natural de programas multihilo. Estos nuevos paradigmas también evitaban, por diseño, los problemas que se dan con los candados, reentrancia, etc.

El paradigma sobre el que hablaré hoy es el de los actores. Este mecanismo, que data de 1986, se utiliza en Erlang y en Scala, por ejemplo, pero no he encontrado ejemplos de cómo implementar este mecanismo en C++, salvo un artículo de 1993 de Kafura, Mukherji y Lavender en el que no se hace uso de ninguna característica «moderna» de C++, como los tipos parametrizados o la sobrecarga de operadores.

En resumen, el mecanismo de actores se basa en definir un actor como un objeto reactivo que se ejecuta en su propio hilo. Son similares a los objetos stricto sensu, en el sentido de que se les puede enviar invocaciones (en mi caso eventos), y los actores responden ejecutándolos, como los objetos normales. No obstante, son diferentes porque las invocaciones se ejecutan de manera que no causan problemas de concurrencia. ¿Cómo? Pues asegurando que todas las invocaciones sobre un actor se ejecutan en un mismo hilo. En este sentido, un actor también aglutina, en general, un hilo de ejecución propio en el que se ejecutan las llamadas al mismo (esto puede no ser así exactamente, pero la idea es la misma).

Existe una diferencia con los paradigmas tradicionales de programación. Por ejemplo, para no causar problemas de concurrencia, todos los métodos de un objeto se podrían marcar como «synchronized» al estilo de Java. Esto, efectivamente, hace que no haya problemas de concurrencia (al menos los más usuales), ya que todas las invocaciones a un objeto se realizan en exclusión mutua. Sin embargo, una invocación a objeto normal lleva consigo asociada un hilo de ejecución, y el hilo de ejecución del objeto llamante es el que realiza la llamada al objeto llamado, con lo que también se tienen que prevenir problemas como interbloqueos, esperas de candados, etc.

En resumen, sería casi como un sistema basado en eventos en donde los objetos se envían mensajes que son a su vez procesados en los hilos respectivos de cada actor. Ahora bien, ¿cómo implementar en C++ este mecanismo sin ser excesivamente intrusivo, teniendo en cuenta que el mecanismo de envío de eventos no existe en C++? Pensé en utilizar boost.signal, pero éste no asegura que el objeto receptor va a ejecutar la señal en su propio hilo. Los requisitos que establecí pues para el desarrollo fueron los siguientes:

  1. El mecanismo debe ser poco intrusivo, en el sentido de que las clases que quieran beneficiarse de este mecanismo no tienen por qué escribirse heredando de un interfaz en particular, sino que sólo tienen que definir una serie de tipos para saber tratarlas como actor.
  2. Cualquier clase puede definir de manera sencilla qué eventos puede recibir y cómo actuará ante cualquier evento, y estos serán los únicos requisitos que tendrá que especificar la clase.
  3. Las clases pueden modificar de forma sencilla qué eventos producen y reciben.
  4. Las clases no tendrán que preocuparse de tratar con hilos, asincronía, almacenamiento y reproducción de eventos, etc.
  5. El mecanismo de envío de eventos debe estar integrado en el lenguaje C++ de forma natural. Por ejemplo, con un operador que muestre que se está enviando un evento: objeto < < mensaje;.

Con estos requisitos, pensé hacer la clase actor que pudiera aceptar como parámetro cualquier otra clase, y convertirla así en un actor. Este mecanismo es poco intrusivo, sólo obligando a que la clase que se quiere beneficiar de este mecanismo especifique qué eventos es capaz de recibir. La clase actor que me quedó fue la siguiente, con comentarios al estilo de la literate programming (si alguien está interesado le puedo pasar el código sin los comentarios):

template <typename Klass>
struct actor
{
    typedef typename Klass::events_type VariantType;

Uno de los requisitos que tiene que proveer la clase que se va a convertir en actor es ofrecer el tipo VariantType con los distintos eventos que va a poder recibir. Para esto se usará el tipo boost.variant como se verá después.

    typedef actor<Klass> self;

    actor (Klass& a)
        : delegate_ (a)
    {
        thread_ = boost::thread (boost::ref (*this));
    }

Cada actor posee su propio hilo. Esto, por supuesto puede modificarse después. Sólo quería hacer una prueba de concepto. En scala existen schedulers que enlazan actores con hilos.

    // Thread func.
    void operator()()
    {
        std::cout << “running thread” << std::endl;

        while(!stop_)
        {
            bool b;
            {
                boost::lock_guard<boost::mutex> guard (list_mutex_);
                b = el_.empty();
            }

            if (b)
            {
                boost::unique_lock<boost::mutex> lock (mut_);

                // wait on the cond. var.
                cond_.wait (lock);
            }

            while (true)
            {
                VariantType vtv;
                {
                    boost::lock_guard<boost::mutex> guard (list_mutex_);
                    if (el_.empty())
                        break;

                    vtv = el_.front();
                    el_.pop_front();
                }

                // Call the delegate without holding the mutex locked
                boost::apply_visitor (detail::event_caller<Klass> (delegate_),
                                      vtv);
            }
        }
    }

El operator()() de la clase actor ejecuta el código del hilo. He utilizado variables de condición porque me parecen más ricas semánticamente. El hilo básicamente extrae eventos de la cola de eventos y los ejecuta sobre el delegate. Como los eventos de la cola pueden ser de diferentes tipos (nótese que este punto es especialmente difícil en C++), hay que utilizar estructuras que permitan tratar diferentes tipos de eventos de forma genérica. Para eso he usado la construcción boost::apply_visitor de boost.variant. Con el uso de una clase especial, detail::event_caller, que se verá más abajo, se consigue llamar a la clase original, a los métodos process(Evento), para cada uno de los eventos recibidos.

    template <typename Event>
    self& operator<<(Event& e)
    {
        std::cout << “Received event” << std::endl;
        {
            boost::lock_guard<boost::mutex> lock (list_mutex_);
            el_.push_back (e);
        }

        // signal that a new event is available
        cond_.notify_one();

        return *this;
    }

El operador << se puede usar para enviar un evento al actor. Esta es una construcción que queda muy natural. Enviar un mensaje es diferente a realizar una llamada, aunque también se puede pensar en un mecanismo de llamada a función modificado. Al final, el envío de mensajes, como se verá después, será algo así como actor << Clase::Evento(valores);.

    void join()
    {
        thread_.join();
    }

    void stop()
    {
        stop_ = true;
        cond_.notify_one();
    }

private:
    Klass& delegate_;

    typedef std::deque<VariantType>  event_list;
    event_list el_;
    bool stop_; // stop?
    boost::thread thread_;

    boost::mutex mut_;
    boost::mutex list_mutex_;
    boost::condition_variable cond_;
};

Por completitud, aquí está la clase detail::event_caller. Es necesaria para visitar un tipo boost.variant a través de la función boost::apply_visitor. Simplemente llama a la función process() correspondiente.

namespace detail
{

template <typename Klass>
struct event_caller : public boost::static_visitor<>
{
    Klass& instance_;

    event_caller (Klass& i)
        : instance_ (i)
    {
    }

    template <typename T>
    void operator()( T const & operand ) const
    {
        instance_.process (operand);
    }
};
}

Llegamos a la clase sobre la que queremos construir el actor, llamada para este ejemplo TestClass. La clase define internamente un par de eventos (Event1 y Event2), y, como comentamos arriba, el tipo events_type, como un boost.variant de los diferentes eventos que puede recibir. Se pueden ver los métodos process() más abajo. En este caso la clase tiene métodos propios para retornar un actor interno. Esto no tiene por qué ser así, y como se ha visto, los actores son independientes de las clases de las que actúan en representación.

class TestClass
{
public:
    typedef actor<TestClass> actor_type;

    struct Event1
    {
        int data;
    };

    struct Event2
    {
        std::string ss;
    };

    // Obligatory
    typedef boost::variant< Event1, Event2 > events_type;

    actor_type& the_actor()
    {
        return *actor_;
    }

    // Ctor.
    TestClass()
        : actor_ (new actor_type (*this))
    {
    }

    ~TestClass()
    {
        actor_->stop();
        actor_->join();
        delete actor_;
    }

private:
    actor_type* actor_;

public:
    void process (Event1 const& e)
    {
        std::cout << “Processed event: “  << e.data << std::endl;
    }

    void process (Event2 const& e)
    {
        std::cout << “Processed event 2: “  << e.ss << std::endl;
    }
};

Por último, ¿cómo se usa este mecanismo de actores? Lo ideal es proveer de mecanismos que sean semánticamente ricos y que sigan el principio de mínima sorpresa. Con las clases de arriba podemos escribir código sencillo como el siguiente:

    TestClass::Event1 ev;
    ev.data = -2;

    TestClass::Event2 ev2;
    ev2.ss = “abcdef.”;

    TestClass tc;

    TestClass::actor_type& ac = tc.the_actor();

Primero se crean un par de eventos de los dos tipos que puede recibir la clase TestClass, y se obtiene el actor ac. Se puede usar ese actor para enviar eventos a la clase:

    // Send the event2
    ac << ev2;

    // Send message
    ac << ev;
    for (int i = 0; i < 2000; ++i)
    {
        ev.data = i;
        ac << ev;
        ac << ev2;
    }

Aquí se envía primero un evento de tipo Event1, y luego otro del tipo 2. Después se entra en un bucle que envía ambos mensajes, modificando el primer evento con un dato distinto. El programa va mostrando la salida de eventos de la clase en orden:

...
Processed event: 1996
Processed event 2: abcdef.
Processed event: 1997
Processed event 2: abcdef.
Processed event: 1998
Processed event 2: abcdef.
Processed event: 1999
Processed event 2: abcdef.

Un último apunte. Las diferencias con los actores de otros lenguajes dinámicos (Scala, por ejemplo), son que en estos lenguajes se puede especificar un procesado basado en máquinas de estados, como por ejemplo, cuando se recibe el evento 1, después sólo se puede recibir el evento 2. Esta máquina de estados se puede implementar. Es una primera implementación de prueba.

No dudéis en contactar conmigo para ideas o comentarios.

7/2/2010

Más ventas de objetivos

Filed under: General, español, fotografía/photo — Diego Sevilla @ 23:23 — In English

Renovando mi equipo fotográfico, he puesto en venta tres objetivos, por si le puede interesar a alguien. Están en Ebay. Son los que he tenido tiempo de poner hoy, que hacer fotos, escribir las descripciones, etc., te lleva al final toda la tarde. Vendrán más anuncios, como mi D200 (ya que he comprado la D700), y alguna otra cosa más, como una Hasselblad 500c/m con un carl-zeiss 80mm/2.8 T* que no uso, y que voy a vender. Ahí van las referencias:

5/2/2010

C++ más rápido que C, o atoi versus boost.spirit v2

Filed under: General, español, código/code, free software/software libre — Diego Sevilla @ 20:42 — In English

Leo en C++ soup un test que hizo Alex Ott comparando la implementación de la función atoi de la librería de C con la versión de boost.spirit versión 2. En su artículo ponía de manifiesto que la versión de boost spirit es unas 3 veces más rápida. Sinceramente, es un resultado que alienta las nuevas técnicas de meta-programación basadas en templates para C++. Ya traté el tema hace un tiempo para mostrar cómo el compilador no generaba código para las sentencias de log cuando la clase se creaba con un parámetro de template false.

http://typography.soup.io/

Filed under: General, español, fotografía/photo — Diego Sevilla @ 19:40 — In English

No me canso de mirarlo. Una fuente de inspiración contínua de arte gráfico con tipografía, recopilado de varias fuentes. Para muestra un botón:

7/1/2010

Curso de fotografía digital, por «El Mundo»

Filed under: español, crítica/critics, fotografía/photo — Diego Sevilla @ 21:43 — In English

No es que me sorprenda ya, pero podríamos tener unos medios (y unos políticos) de mayor calidad, ¿no? Vamos, que en portada llamen a Zapatero y a González «los reyes del paro»… Que les falte rigor, vale, pero que les falte la educación también… Vía.

30/12/2009

Vídeos y clases sobre Scheme, LISP, Clojure, etc.

Filed under: english, español, código/code, free software/software libre — Diego Sevilla @ 15:57 — In English

Las encontré el otro día por casualidad. En la entrada del sitio web enlazan varias y contiene vídeos. En particular, me encantó ésta, sobre Scribble, el sistema de documentación de PLT Scheme, y que utiliza el módulo de presentaciones de DrScheme (slideshow) para crear una presentación inicial con gancho para la audiencia.

29/12/2009

Pobre Miguel Hernández

Filed under: General, español, crítica/critics — Diego Sevilla @ 17:03 — In English

No escapa a las catetas y sesgadas manos de la derecha.

21/12/2009

SOAP, entre lo peor de la década

Filed under: english, español, crítica/critics, código/code — Diego Sevilla @ 20:09 — In English

Yo ya lo dije hace tiempo… Vía, que a su vez lo saca del “radar” de O’reilly. En ese artículo compara SOAP con CORBA, pero ni de lejos. Sobre todo porque la primera ha fracasado por su pésimo diseño arquitectural, mientras que CORBA fracasó por intereses económicos, no por que la tecnología estuviera mal diseñada.

El desafío de Arc, en Clojure

No conocía que Paul Graham, el inventor de un dialecto de Lisp llamado Arc, había lanzado un desafío. El desafío incluye escribir varias páginas web en cascada en la que la primera pide algo al usuario a través de un formulario. Al pulsar el botón de enviar del formulario, se muestra una segunda página con un enlace que lleva a una tercera que muestra lo que el usuario escribió. El ejemplo en Arc se supone que es extremadamente simple (gracias, por supuesto, a un framework Web escrito para el lenguaje en cuestión.

Tampoco sabía que se habían lanzado en masa a mostrar cómo resolver este problema en otros lenguajes, pero enlazo aquí la resolución en Clojure también porque esa página lleva enlaces a otros ejemplos de cómo resolverlo, y enlaces a los foros de Arc.

API design matters

Filed under: General, español, crítica/critics, código/code — Diego Sevilla @ 0:33 — In English

API design matters. Una versión distribuida de esto intento hacer en la asignatura de distribuidos. En sistemas distribuidos el API importa aún más.

12/12/2009

having a baby leaves you this way :)

Filed under: english, español, fotografía/photo — Diego Sevilla @ 11:43 — In English


having a baby leaves you this way :) , originally uploaded by dsevilla.

(a.k.a. wonders of iso 3200)

I saw her in the bathroom and I had to do this :)

Nikon D700 + Nikkor 50mm/1.4.

11/12/2009

Mark Volkmann: Clojure

Filed under: english, español, free software/software libre — Diego Sevilla @ 22:06 — In English

Interesante página sobre clojure..

4/12/2009

Sacha di Manolo: Ride on

Filed under: General, español — Diego Sevilla @ 23:39 — In English

Buscando la música del anuncio retro de Citroën me he encontrado con esta:


Y su MySpace.

PD. ¿Por qué todos los artistas emergentes tienen que tener su sitio en MySpace? Es lo más caótico y peor diseñado que me podía haber imaginado en mis peores pesadillas. Supongo que los veinteañeros lo verán de lo más normal tener páginas totalmente desestructuradas, pero yo…

2/12/2009

Carta a mis nietos. Enrique Amat en La Verdad de hoy

Filed under: General, español, crítica/critics — Diego Sevilla @ 0:42 — In English

De lo mejor que he leído últimamente. Vía.

Next Page »

Creative Commons License
This work is licensed under a Creative Commons License.
EWWV  AWStats  Site Meter 22 queries. 0.157 seconds. Powered by WordPress
406021 email messages processed in this box. 10858 were spam

0