/* comment */

Lenguaje S (Lógica Computacional)

2011-10-10T02:24:00.001-03:00

En el libro Computability, Complexity and Languages de Davis y Weyuker se describe un lenguaje de programación Y (S para algunos). Dicho lenguaje, sencillo, cumple algunas propiedades teóricas interesantes y es empleado en cátedras de Lógica Computacional.

El código de un programa en S es algo como:

[A1] IF X1 != 0 GOTO B1
     Z1 <- Z1 + 1
     IF Z1 != 0 GOTO E1
[B1] X1 <- X1 - 1
     Y  <- Y  + 1
     Z1 <- Z1 + 1
     IF Z1 != 0 GOTO A

(Función Identidad, Página 17 de Computability, Complexity and Languages)

Es un lenguaje simple, con tres instrucciones: incrementar o decrementar una variable. y saltar a una etiqueta si una variable no es cero.

El rango de las variables es [0, +inf) y toman como valor inicial cero. Además, decrementar una que está en cero no cambia su valor.

También están las etiquetas, que permiten nombrar instrucciones y saltar a ellas mediante IF. Si se salta a una etiqueta inexistente el programa termina. Una extensión al lenguaje es la existencia de macros, similares a las de C.

En el Lenguaje S es conveniente probar los edge-cases antes de empezar a probar formalmente el programa, o tener una ayuda para hacer un seguimiento de la ejecución del mismo.

Como el lenguaje es simple decidí implementar un intérprete y un compilador con una reducida máquina virtual (por el momento sólo en Python). Están bastante incompletos (pero funcionan) y necesitan un lexer-parser real. Aclaro que fue una solución Quick n' Dirty.

El código está en GitHub y bajo licencia NewBSD. Cualquier sugerencia constructiva es bien recibida, por lo que agradezco mucho cualquier fork y pull-request, bug report o comentario.

Datastore en App Engine

2011-09-16T15:26:00.002-03:00

En el post anterior traté las dificultades que nos trajo App Engine, y en particular su Datastore, con la forma en la que diseñamos nuestra aplicación.

Después de correr unas cuantas pruebas, descubrimos que la mayoría de los problemas de performance no provenían del particionamiento espacial (como erróneamente habíamos considerado), sino que de un derivado de las consultas: la cantidad de geoceldas que empleábamos por consulta. Teníamos, entonces, dos formas de solucionarlo: eliminar celdas, o bien encontrar el motivo por el cual la consulta era lenta.

Las consultas con IN en Datastore son compuestas. Se realiza una consulta por cada elemento en la lista del filtro IN en paralelo, y luego se juntan los resultados para no devolver duplicados. Por este motivo, mientras más consultas con filtros IN tendremos mayor consumo de API, y por ende mayor latencia. En una aplicación que depende de respuestas casi instantáneas eso juega en detrimento de nuestra experiencia de usuario.

¿Cómo podemos resolverlo? ¿O al menos optimizarlo?

Como asumimos que los índices ya están bien armados por el desarrollador (no lo vamos a tratar en esta entrada), lo primero que podemos hacer es reordenar la forma en la que consultamos por datos. Un objeto Query en AppEngine tiene varias etapas, que son: construcción, ejecución y obtención. Si necesitamos ejecutar distintas consultas sin relación entre sí (como en un foro querríamos obtener la lista de usuarios activos, comentarios recientes y nuevos posts) conviene que lo hagan en paralelo. Para eso tenemos el método run(), que corre las consultas asincrónicamente. Podríamos generar nuestras consultas al principio, correrlas en paralelo y levantar el resultado recién cuando sea necesario sin tener que bloquear por cada una.

Vuelta a las celdas, esta técnica no nos ayuda en nada pues las consultas IN ya corren en simultáneo. Podemos optar por una optimización básica: reducir el número de celdas. Menos consultas implica que obtener los datos (previo merging) sea un tanto más rápido, en especial si además filtramos por otras propiedades con IN. Sin embargo, en el post anterior vimos que no siempre es posible y que de todas formas tendremos como resultado pérdida de precisión y mayor cantidad de falsos positivos (elementos fuera de nuestro viewport, inútiles en nuestro caso). Terminaríamos aumentando la cantidad de elementos necesarios por consulta a un número poco práctico.

Otra opción es obtener sólo objetos Key. La gran ventaja es que AppEngine no levantará las entidades y tardará menos en filtrar, pero nos dará la información relevante a nuestra consulta: qué markers se encuentran en nuestro viewport actual, y no la información de los que se encuentran allí. La desventaja es que ahora requerimos dos pasos para mostrar datos al usuario. ¿Pero entonces de qué nos sirve? Podemos aprovechar el poder de los navegadores modernos para continuar nuestras optimizaciones allí (tema que no trataremos en este post).
Ahora debemos implementar get_multi, de forma tal que podamos levantar los markers de manera eficiente (en grupos) y una sola vez.

La última optimización que podemos hacer es subdividir las entidades en fragmentos más pequeños. No es evidente, o al menos no es la opción que primero se nos ocurre, pero también debemos considerar el costo de serialización y el peso que conlleva crear objetos con datos que no vamos a aprovechar. En una aplicación que debe presentar feedback rápido al usuario separaríamos nuestra entidad en información de primer nivel (que efectivamente necesitamos) y secundaria (que sólo aprovechamos cuando el usuario está interesado en ese objetivo).

Como dije en un post anterior, desarrollar en AppEngine requiere pensar en un paradigma distinto y presenta desafíos interesantes.

Problemas con consultas geoespaciales en Google AppEngine

2011-09-04T02:06:00.002-03:00

En uno de los proyectos donde estoy trabajando la principal funcionalidad depende de búsqueda de puntos en un mapa. La aplicación debe responder de manera rápida, estable y devolver datos según diversos filtros para luego ser procesados del lado cliente (web).

El stack de AppEngine presentó unos cuantos desafíos, particularmente en Datastore y CPU. Si bien la aplicación es relativamente sencilla, la gran cantidad de puntos y los filtros demandan una forma distinta de pensar.

Datastore
Como el Datastore de AppEngine está basado en BigTable, las consultas sobre el sistema se limitan a desigualdades sobre un solo campo. Esto elimina búsquedas donde encerramos entre rangos de latitud/longitud, y además evita el ordenamiento de los datos.

La solución es usar una especie de función hash para almacenar la posición aproximada de los puntos. La idea es particionar el mapa en una cantidad arbitraria de celdas y utilizar el operador IN de AppEngine. Esto nos ahorra la búsqueda por desigualdad a costo de incrementar el número de consultas (y CPU).

Geomodel es una librería que implementa este sistema. Provee un modelo del que heredamos y los métodos necesarios para generar y consultar las geoceldas. Es totalmente transparente al usuario y sólo requiere que llamemos a un método para actualizar la información de las celdas. Sin embargo, es necesario conocer la teoría para hacer uso correcto de los recursos y no llevarnos sorpresas desagradables.

(Nota: omito el chequeo de errores para ser breve)

Teoría
¿Qué es una geocelda?
Podemos pensar al mapa como un rectángulo. La idea de las geoceldas es partir el mapa en secciones
más pequeños, seleccionar la celda donde se encuentra nuestro punto y reiterar el proceso hasta que logremos una celda arbitrariamente pequeña (como un quadtree). Lo bueno de este sistema es que como trabajamos sobre el par latitud/longitud es independiente a la proyección.

(Nota: Geomodel implementa los métodos de forma distinta y más eficiente, pero la esencia es la misma)

Ejemplo:
Supongamos que tenemos un sistema que va desde 0 a 100 metros para la latitud y la longitud, y queremos celdas de 10 metros de precisión. Para facilitar el ejemplo, sólo partiremos el mapa en 4 celdas por vez, a las que llamaremos Q, W, A y S (por la posición en el teclado).

Para ubicar el punto 2-32:

class Map(object):
    def __init__(self, x, y, cell_size):
        self.x = x
        self.y = y
        self.cell_size = cell_size

    def locate(self, x, y):
        cell = ""
        middle_x, middle_y = self.x / 2, self.y / 2
        size = max(self.x, self.y)
        while size > self.cell_size:
            left, right = int(x > middle_x), int(y > middle_y) 
            cell += ("QW", "AS")[left][right]
            middle_x *= 0.5 + left * 0.25
            middle_y *= 0.5 + right * 0.25
            size /= 2
        return cell
            
m = Map(100, 100, 10)
print m.locate(2, 32)

Vemos que calcular el hash tiene costo Tita(log(max(x, y) / cell_size)). Una propiedad importante es que si dos puntos tienen el mismo prefijo entonces son vecinos, mientras que la inversa no es cierta para todos los casos (ejemplo: 51-50 y 50-51). Esto dificulta la búsqueda de proximidad (pues debemos generar las ocho celdas vecinas), y aumenta el uso de CPU.

Por el tipo de arquitectura de BigTable, para almacenar los registros conviene precomputar una lista de todas las celdas a las que un punto pertenece y almacenarlas en una ListProperty. De esta manera, el costo de una consulta por celda será proporcional a la precisión (número de elementos).

La búsqueda por caja (bounding box) es la que más utilizamos. Para ello se computa una serie de celdas a partir de una vista (viewport) a una resolución determinada, y con esas celdas se consulta a la base de datos. Geomodel filtra los resultados para eliminar aquellos que quedan fuera de la vista, pero eso incrementa el uso de CPU.

Para calcular el viewport necesitamos un par de funciones para obtener los vecinos (izquierdo e inferior) de una celda. Eso lo podemos lograr así:

class Map(Map):

    ...

    @staticmethod
    def right(cell):
        if cell[-1] == "Q":
            return cell[:-1] + "W"
        elif cell[-1] == "A":
            return cell[:-1] + "S"
        elif cell[-1] == "W":
            return Map.right(cell[:-1]) + "Q"
        elif cell[-1] == "S":
            return Map.right(cell[:-1]) + "A"
            
    @staticmethod
    def down(cell):
        if cell[-1] == "Q":
            return cell[:-1] + "A"
        elif cell[-1] == "W":
            return cell[:-1] + "S"
        elif cell[-1] == "A":
            return Map.down(cell[:-1]) + "Q"
        elif cell[-1] == "S":
            return Map.down(cell[:-1]) + "W"

El costo de calcular el vecino es relativo a la precisión, pero en la mayoría de los casos requiere sólo un par de cambios. Con estas funciones sólo resta calcular el viewport, para lo cual calculamos los cuatro extremos de nuestra caja y generamos a partir de ellos el resto:

class Map(Map):

    ...

    @classmethod
    def row(cls, cell, limit):
        yield cell
        while cell != limit:
            cell = cls.right(cell)
            yield cell

    @classmethod
    def col(cls, cell, limit):
        yield cell
        while cell != limit:
            cell = cls.down(cell)
            yield cell

    def viewport(self, n, e, s, w):
        left_col = self.col(self.locate(n, e), self.locate(s, e))
        right_col = self.col(self.locate(n, w), self.locate(s, w))
        for start, stop in zip(left_col, right_col):
            for cell in self.row(start, stop):
                yield cell

Para nuestro mapa, el uso sería:

for cell in m.viewport(0, 0, 20, 20):
    print cell

Vemos que la búsqueda por viewport es simple, pero que requiere una cantidad de recursos importante si se quiere un buen nivel de precisión. En particular, generar las celdas es proporcional a la resolución y tamaño de la caja, por lo que un buen algoritmo debería ser capaz de detectar el tamaño óptimo de las celdas para reducir la cantidad de consultas (por prefijo común, por ejemplo) y no superar el límite práctico de AppEngine.

Existen otros esquemas de partición, pero es aconsejable escoger uno que nos permita ordenar los resultados de forma coherente. Para los interesados, Geomodel particiona en 16 subceldas y asigna un orden similar a un código Morton (Z-Order Curve).

No voy a tratar el análisis de búsqueda por proximidad, al menos no en este post. ¿Por qué? Una idea: el método proximity_fetch en Geomodel tiene +150 líneas. Se puede obtener un resultado similar para celdas pequeñas generando un viewport centrado en el objetivo.

Game of Life (Reprise)

2010-04-20T20:31:00.005-03:00

Sólo por el placer de probarme, (re)escribí una versión de Conway's Game of Life en Ansi C con un par de particularidades. El algoritmo usa bit shifting, por lo que es relativamente difícil de leer. ¿Por qué hacer esto, entonces? Puro ejercicio mental.

En el algoritmo entran en juego dos conceptos básicos: máquinas de estado y operaciones de bit-a-bit. Hay mucho material dando vueltas por ahí como para explicarlo, pero son dos herramientas que encajan perfecto con este problema.

El código tiene menos de 70 líneas en total, y si bien no es "edgeless" como el ejemplo del Game of Life anterior, cumple a la perfección su cometido. El tiempo de ejecución es tan corto que ni siquiera puedo medirlo con time. El código en assembler (gcc archivo.c -s) tiene 391 líneas invariablemente del flag de optimización. Supongo que eso ocurre por el uso de instrucciones de comparación bit-a-bit.

Un posible cambio para eliminar la suma es realizar un mapa de todas las combinaciones de celdas de 3x3, con lo que el input y el estado serían lo mismo. El mapa devolvería el estado de la célula, exactamente igual que en el ejemplo. No lo considero una optimización, más bien lo contrario.

El código está en ~~codepad~~ (UPDATE: acá) y a continuación:

#include <stdio.h>
#include <stdlib.h>

#define COUNT_ALIVE(a, b, c, offset)    (((a >> (offset - 1)) & 1) + \
                                        ((a >> offset) & 1) + \
                                        ((a >> (offset + 1)) & 1) + \
                                        ((b >> (offset - 1)) & 1) + \
                                        ((b >> (offset + 1)) & 1) + \
                                        ((c >> (offset - 1)) & 1) + \
                                        ((c >> offset) & 1) + \
                                        ((c >> (offset + 1)) & 1))

#define IS_ALIVE(a, b)                  ((a >> b) & 1)

char status[2][9] =    {
                    /*   0, 1, 2, 3, 4, 5, 6, 7, 8*/
                        {0, 0, 0, 1, 0, 0, 0, 0, 0},    /* Dead cell */
                        {0, 0, 1, 1, 0, 0, 0, 0, 0}     /* alive cell */
                        };

void print(unsigned long int [], int, int);
void evolve(unsigned long int [], int, int);

int
main(int argc, char** argv)
{
    unsigned long int m[20];
    int i;
    for (i = 0; i < 20; i++)
        m[i] = 0;
    m[3] = 1 << 8;
    m[4] = 1 << 7;
    m[5] = 7 << 7;
    for (i = 0; i < 32; i++)
    {
        printf("= GENERATION %d =\n", i + 1);
        print(m, 20, 20);
        evolve(m, 20, 20);
    }
    return EXIT_SUCCESS;
}

void
print(unsigned long int m[], int x, int y)
{
    int i, j;
    for(i = 0; i < y; i++)
    {
        for(j = 1; j <= x; j++)
            printf("%c", (m[i] >> (x - j)) & 1 ? '#' : ' ' );
        printf("\n");
    }
}

void evolve(unsigned long int m[], int x, int y)
{
    unsigned long int *m2 = calloc(y, sizeof(unsigned long int));
    int itrX, itrY;
    for (itrY = 1; itrY < y - 1; itrY++)
        for (itrX = 1; itrX < x - 1; itrX++)
            m2[itrY] |= (status[IS_ALIVE(m[itrY], itrX)][COUNT_ALIVE(\
                        m[itrY - 1], m[itrY], m[itrY + 1], itrX)] << itrX);
    for (itrY = 0; itrY < y; itrY++)
        m[itrY] = m2[itrY];
    free(m2);
}

EDIT: Me olvidé hacer la respectiva llamada a free, y calloc inicializa a cero.

Quick Pastebin

2010-04-03T20:12:00.003-03:00

Hoy necesitaba pasar unos archivos de una máquina que corre Linux a otra con el mismo sistema operativo. El problema: rsync y scp no funcionan, y no sé el motivo. Tampoco tenía tiempo para andar averiguando, así que en menos de 10 minutos codeé esto:

#!/usr/bin/env python
# -*- coding: utf-8 -*-
#
#       pastebin.py
#       
#       Copyright 2010 Pablo Alejandro Costesich


import urllib2
import urllib
import sys

def paste(text, **kwargs):
    urlapi ='http://pastebin.com/api_public.php'
    values = {'paste_code': text}
    values.update(kwargs)
    data = urllib.urlencode(values)
    req = urllib2.Request(urlapi, data)
    response = urllib2.urlopen(req)
    return response.read()


def main(*args):
    if len(args) == 1:
        print paste(''.join(sys.stdin.readlines()))
    else:
        for filename in args[1:]:
            f = open(filename)
            print paste(''.join(f.readlines()))
    return 0

if __name__ == '__main__':
    main(*sys.argv)

Python Memory Tools

2010-03-25T12:51:00.000-03:00

Ayer publiqué por primera vez una herramienta sobre la que estuve trabajando para resolver un par de problemas en Galaktia. Se trata de un conjunto de funciones decoradoras y clases para implementar el Memory Pattern en callables y brindarles una pseudo transparencia referencial (porque el valor debería depender sólo de los parámetros y no causar efectos colaterales). Es útil para funciones computacionalmente caras e inmutables (o que la actualización de sus valores de retorno tenga un tiempo de expiración largo).

Es una librería muy sencilla y fácil de entender, aunque seguro implementada miles de veces y de distintas maneras. Mi objetivo fue que sea fácil de usar (para mí), donde cada storage se asemeje lo más posible a un diccionario. Esto hace que pueda reemplazar muchas partes de código viejo sin romperlo.

Un ejemplo muy simple de la librería:

from memtools.storages import RedisMemory, MemcacheMemory, Alzheimer
mem = RedisMemory(debug=True)
mem2 = MemcacheMemory(debug=True) # podría usarlo del mismo modo
mem3 = Alzheimer(True) # easter egg, pierde valores a lo random.
@mem
def fib(n):
    if n in (0, 1):
        return 1
    else:
        return fib(n - 1) + fib(n - 2)

print fib(2)
print fib(5)
print fib(3)

mem["asd"] = 1
print mem["asd"]

La biblioteca está bajo licencia BSD y fue escrita enteramente por mí. En una época fue parte del proyecto Galaktia (@galaktia), pero gracias a Manuel Aráoz (@maraoz) y el resto del equipo pude separarla, así que ahora está disponible para todos. Agradezco cualquier modificación, sugerencia o cambio que pueda hacerse para mejorarla (son libres de hacerlo o no). Un fork&merge sería un halago.

Pueden encontrar el código en GitHub o en PyPI.

Puede ser que en un futuro le agregue soporte para memcache en Google App Engine y on-demand value updates (recalcular los valores almacenados para una clave cuando se cumpla una condición).

Eerie ping

2010-02-22T19:11:00.000-03:00

Ayer a la noche hablando con un amigo de la facultad e intercambiando ideas en base a una conversación con raíces en la última edición de la tira electrónica xkcd, salió como desafío mandar un mensaje entre equipos de una red usando la opción "-p" mediante ping.

El código, horrible pero legible, a continuación:

import sys, os
addr = sys.argv[1]
msg = ' '.join(sys.argv[2:])

for i in xrange(0, len(msg), 2):
    a, b = msg[i], (msg[i+1] if i+1 < len(msg) else '\0')
    os.popen("ping -c 1 -p %02X%02X %s" % (ord(a), ord(b), addr))

Experimentos con DBus en Python: Nombre Conocido, Exportando Objetos y Lanzando Señales

2009-12-16T14:35:00.002-03:00

Nombre Conocido

En el tutorial oficial no está documentado, pero tampoco es complejo. Sólo se necesita usar el método dbus.service.BusName para reclamar un nombre y pasarle el bus al que estará asociado.

import gobject
from dbus.service import BusName
from dbus import SessionBus
from dbus.mainloop.glib import DBusGMainLoop

dbus_loop = DBusGMainLoop()
session = SessionBus(mainloop=dbus_loop)

name = BusName('com.blogger.pcostesi.Test', session)

loop = gobject.MainLoop()
gobject.threads_init()
loop.run()

Lo anterior es inseguro, ya que no realizamos ninguna verificación sobre la existencia previa de un servicio del mismo modo. Lo correcto sería envolver el llamado en un bloque try/except, como hace Roberto Alsina.

Una vez que tenemos el BusName reservado para nuestro servicio, podemos exponer objetos.

Exportando Objetos

Para publicar un servicio, es necesario encapsularlo en una clase que herede de dbus.service.Object, y los métodos que quisiéramos que sean accesibles desde el bus deben ser decorados con dbus.service.method. Object tiene que ser inicializado en __init__ para que funcione, pasándole un Nombre Conocido o un Bus y el path del objeto.

Un servicio ejemplo sería:

import gobject
from dbus.service import BusName, Object, method
from dbus import SessionBus
from dbus.mainloop.glib import DBusGMainLoop

dbus_loop = DBusGMainLoop()
session = SessionBus(mainloop=dbus_loop)

class Ejemplo(Object):
    instancias = 0
    def __init__(self, bus, loop):
        # Nombre Conocido de la aplicación
        name = BusName('com.blogger.pcostesi.Test', bus)
        Ejemplo.instancias += 1
        self.loop = loop
        self.path = '/com/blogger/pcostesi/Ejemplo/%s' % Ejemplo.instancias
        super(Ejemplo, self).__init__(name, self.path)
        print self.path, "listo."
    
    @method(dbus_interface='com.blogger.pcostesi.Ejemplo',
            in_signature='s', out_signature='', sender_keyword='sender',
            destination_keyword='dest')
    def saludo(self, saludo, sender='alguien', dest='mi'):
        print "%s dijo a %s: %s" % (sender, dest, saludo)
    
    @method(dbus_interface='com.blogger.pcostesi.CerrarEjemplo')
    def salir(self):
        self.loop.quit()

loop = gobject.MainLoop()
gobject.threads_init()

ejemplo1 = Ejemplo(session, loop)
ejemplo2 = Ejemplo(session, loop)

loop.run()

Y un cliente sólo necesitaría ser así:

import dbus
session = dbus.SessionBus()

ejemplo1 = session.get_object('com.blogger.pcostesi.Test',
        '/com/blogger/pcostesi/Ejemplo/1')
ejemplo2 = session.get_object('com.blogger.pcostesi.Test',
        '/com/blogger/pcostesi/Ejemplo/2')

ej1_saludo = dbus.Interface(ejemplo1,
        dbus_interface='com.blogger.pcostesi.Ejemplo')

ej2_saludo = dbus.Interface(ejemplo2,
        dbus_interface='com.blogger.pcostesi.Ejemplo')

ej1_cerrar = dbus.Interface(ejemplo1,
        dbus_interface='com.blogger.pcostesi.CerrarEjemplo')

ej2_cerrar = dbus.Interface(ejemplo2,
        dbus_interface='com.blogger.pcostesi.CerrarEjemplo')

ej1_saludo.saludo('Hola')
ej2_saludo.saludo('Hello')
ej1_cerrar.salir()

Notarán la gran cantidad de parámetros que recibe el decorador. No todos son necesarios, sólo la interfaz. Recomiendo llenar in_signature y out_signature para despejar dudas.

Los keywords que admite son:

dbus_interface: la interfaz a la que el método pertenecerá
in_signature: la firma de entrada de la función, según los Tipos de Datos.
out_signature: la firma de salida de la función, según los Tipos de Datos.
async_callbacks: una tupla que contiene dos strings, cada uno con los nombres de keyword en el método que es decorado (de éxito y de error respectivamente) para cuando son llamados asincrónicamente.

sender_keyword
path_keyword: keyword a la dirección del objeto
rel_path_keyword: similar al anterior, pero el objeto recibirá un path relativo.
destination_keyword
message_keyword
connection_keyword: keyword para pasar un objeto dbus.connection.Connection. Útil por si este objeto está en más de una conexión.
utf8_strings
byte_arrays

Lanzando Señales

A diferencia de los métodos exportados, las señales trabajan sólo con los parámetros de entrada y tienen el mismo nombre que la función a la que se llama. Para crear una señal, lo único que hay que hacer es aplicar el decorador dbus.service.signal.

Agreguemos a nuestro ejemplo anterior una señal para cuando llamemos al método saludo:

import gobject
from dbus.service import BusName, Object, method, signal
from dbus import SessionBus
from dbus.mainloop.glib import DBusGMainLoop

dbus_loop = DBusGMainLoop()
session = SessionBus(mainloop=dbus_loop)

class Ejemplo(Object):
    instancias = 0
    def __init__(self, bus, loop):
        # Nombre Conocido de la aplicación
        name = BusName('com.blogger.pcostesi.Test', bus)
        Ejemplo.instancias += 1
        self.loop = loop
        self.path = '/com/blogger/pcostesi/Ejemplo/%s' % Ejemplo.instancias
        super(Ejemplo, self).__init__(name, self.path)
        print self.path, "listo."
    
    @method(dbus_interface='com.blogger.pcostesi.Ejemplo',
            in_signature='s', out_signature='', sender_keyword='sender',
            destination_keyword='dest')
    def saludo(self, saludo, sender='alguien', dest='mi'):
        print u"%s dijo a %s: %s" % (sender, dest, saludo)
        self.dicho(sender, dest, saludo)
    
    @method(dbus_interface='com.blogger.pcostesi.CerrarEjemplo')
    def salir(self):
        self.loop.quit()
    
    @signal(dbus_interface='com.blogger.pcostesi.Ejemplo', signature='sss')
    def dicho(self, s, d, saludo):
        print 'Notificando: dicho(%s, %s, %s)' % (s, d, saludo)

loop = gobject.MainLoop()
gobject.threads_init()

ejemplo3 = Ejemplo(session, loop)
loop.run()

dbus.service.signal recibe como parámetros:

dbus_interface: interfaz que lanzará la señal
signature: firma que tiene la señal
path_keyword (no puede pasarse como posicional, sólo como keyword)
rel_path_keyword

Y eso es básicamente todo lo necesario de dbus.

Experimentos con DBus en Python: Escuchando Señales

2009-12-16T11:56:00.000-03:00

Señales

Si corren el último ejemplo del post anterior con dbus-monitor --session (para ver los mensajes en el bus), verán que se envían mensajes que no son "llamados" a ninguna función, sino que son emitidas en eventos. Esos mensajes se llaman señales.

Existen dos formas de capturar señales: una es escuchando un bus, mientras que la otra es escuchando una interfaz de un objeto. En un principio pueden sonar similares, pero el propósito de las mismas es radicalmente distinto. Es necesario en ambos casos disponer de un event loop.

En el caso de escuchar un bus tenemos el método add_signal_receiver. Como parámetros, admite:

handler_function, una función (callable) a la que se llamará cuando se reciba la señal. Recibirá como parámetros los argumentos de la señal.
signal_name, el nombre de la señal.
dbus_interface, la interfaz asociada al emisor de la señal. Escucha interfaces y no objetos.
bus_name, el Nombre Conocido de la aplicación.
path, la dirección de un Objeto.
keywords (ver más adelante).

En todas (excepto handler_function) el default es None, que escucha todas. Devuelve un objeto SignalMatch, que tiene un método remove() para eliminar la conexión. Los keywords utf8_strings (booleana) y byte_arrays (booleana) afectan los tipos al llamar el handler.

Un ejemplo de una función catch-all sería:

from dbus import SystemBus
from dbus.mainloop.glib import DBusGMainLoop
import gobject

def handler(*args, **kwargs):
    print '='*10
    print 'args:', args
    print 'kwargs', kwargs

dbus_loop = DBusGMainLoop()
session = SystemBus(mainloop=dbus_loop)

session.add_signal_receiver(handler)

loop = gobject.MainLoop()
gobject.threads_init()
loop.run()

Si tienen un teclado multimedia, prueben presionando play o subiendo y bajando el volumen. Podríamos refinar lo anterior para escuchar sólo elementos con la interfaz org.freedesktop.Hal.Device de este modo:

session.add_signal_receiver(handler,
        dbus_interface='org.freedesktop.Hal.Device',
        sender_keyword='sender')

Para escuchar señales de una interfaz asociada a un objeto, disponemos de connect_to_signal. Los parámetros son:

handler_function, una función (callable) a la que se llamará cuando se reciba la señal. Recibirá como parámetros los argumentos de la señal.
dbus_interface, la interfaz asociada al emisor de la señal.
keywords (ver más adelante).

También cuenta con utf8_strings y byte_arrays, como add_signal_receiver.

Un ejemplo trivial:

from dbus import Interface

class Notifier(object):

    def __init__(self, bus, replace=False, app_name='', loop=None):
        self.proxy = bus.get_object('org.freedesktop.Notifications',
                '/org/freedesktop/Notifications')
        self.interface = Interface(self.proxy,
                dbus_interface='org.freedesktop.Notifications')
        self.app_name = app_name
        self.prev = 0
        self.loop = loop
        self.replace = replace
        self.r = {1: 'expiró', 2: 'fue cerrada por el usuario',
                3: 'se llamó a CloseNotification',
                4: 'pasó algo no esperado'}
        # Conectamos la señal
        self.interface.connect_to_signal('NotificationClosed',
                self.available)
    
    def notify(self, message, timeout=-1):
        self.prev = self.interface.Notify('System', self.prev, '',
                self.app_name, message, [], {}, timeout)
    
    # La señal envía como parámetros id y reason.
    def available(self, id, reason):
        print "La notificación %i se cerró debido a que %s." % (id,
                self.r[reason])
        self.loop.quit()

Y se implementa así:

from dbus import SessionBus
from dbus.mainloop.glib import DBusGMainLoop
import gobject, dbus

dbus_loop = DBusGMainLoop()
session = dbus.SessionBus(mainloop=dbus_loop)

loop = gobject.MainLoop()
gobject.threads_init()

notifier = Notifier(session, app_name='Prueba', loop=loop)
def notify():
    notifier.notify('Hola', 3*1000)

gobject.timeout_add(1000, notify)
loop.run()

Keywords

Tanto add_signal_receiver como su contraparte connect_to_signal en una interfaz o proxy admiten keywords que son utilizadas para pasar información extra a nuestros handlers bajo el nombre que le asignemos. Las más usadas son:

sender_keyword: El nombre único del emisor de la señal.
destination_keyword: El destino de la señal.
interface_keyword: La interfaz asociada que lanza la señal.
member_keyword: El nombre de la señal.
path_keyword: El path o dirección del objeto emisor.
message_keyword: el mensaje, como dbus.lowlevel.SignalMessage

Si no son especificadas, no se pasan.

Experimentos con DBus en Python: Loop de Eventos y Llamados Asincrónicos

2009-12-16T11:24:00.001-03:00

Llamadas Asincrónicas

Ahora, nuestros programas cuentan con la capacidad de realizar llamados por el bus a otros objetos, pero éstos son bloqueantes -- el programa se quedará esperando una respuesta antes de seguir. A menudo, esto es el comportamiento que deseamos y muchas veces nos es suficiente, pero dado que algunos servicios pueden tardar un tiempo largo (como descubrir aparatos bluetooth en el entorno), a veces queremos procesar otras cosas.

Primero, y para que esto sea posible, necesitamos crear un Event Loop. Es un método al que llamaremos y se encargará de esperar eventos para despacharlos a nuestras funciones.

Hay dos loops disponibles: uno para Qt y otro para Gtk. Yo prefiero el de Gtk, principalmente porque tengo varias aplicaciones que usan pygtk y ninguna de pyqt4. Eso es cuestión del lector.

Nota importante: se debe instanciar el loop antes de conectar el bus.

En gtk, haríamos:

from dbus import SessionBus
from dbus import SessionBus
from dbus.mainloop.glib import DBusGMainLoop
import gobject

dbus_loop = DBusGMainLoop()
session = dbus.SessionBus(mainloop=dbus_loop)

# Colocar señales y llamados asincrónicos aquí

loop = gobject.MainLoop()
gobject.threads_init()
loop.run()

O sino, también se puede definir un dbus_loop global de este modo:

from dbus import SessionBus
from dbus import SessionBus
from dbus.mainloop.glib import DBusGMainLoop
import gobject

DBusGMainLoop(set_as_default=True)
session = dbus.SessionBus()

# Colocar señales y llamados asincrónicos aquí

loop = gobject.MainLoop()
# threads_init activa/desactiva threads cuando llama métodos en c
gobject.threads_init()
loop.run()

Prefiero el primero, por una cuestión de ser explícito el dbus_loop que elijo.

Nótese, sin embargo, que ese no es el loop general. Para ello usamos gobject.MainLoop y su método run.

Para PyQT4, tenemos:

# Basado en listing4.py de Roberto Alsina
import sys
import dbus
from dbus import SessionBus
from dbus.mainloop.qt import DBusQtMainLoop
from PyQt4.QtCore import QCoreApplication

app = QCoreApplication(sys.argv)
mainloop = DBusQtMainLoop(set_as_default=True)
dbus.set_default_main_loop(mainloop)

# Colocar señales y llamados asincrónicos aquí

app.exec_()

El código extra es para iniciar QT (framework que todavía no usé en python).

Una vez que sabemos crear un main loop y usarlo, podemos llamar funciones asincrónicamente. Para ello, sólo tenemos que llamar al método que queremos con dos keywords:

reply_handler - Función (callable) a la que se pasa como parámetros los resultados del método remoto
error_handler - Función (callable) que recibe un solo argumento de la clase DBusException

A modo ilustrativo (porque es bastante fácil), una versión modificada del Notifier del post pasado:

from dbus import Interface

class Notifier(object):

    def __init__(self, bus, replace=False, app_name=''):
        self.proxy = bus.get_object('org.freedesktop.Notifications',
                '/org/freedesktop/Notifications')
        self.interface = Interface(self.proxy,
                dbus_interface='org.freedesktop.Notifications')
        self.app_name = app_name
        self.prev = 0
        self.replace = replace
    
    def notify(self, message, timeout=-1):
        self.interface.Notify('System', self.prev, '',
                self.app_name, message, [], {}, timeout,
                reply_handler=self.reply, error_handler=self.error)
    
    def reply(self, n):
        self.prev = n
    
    def error(self, exception):
        print exception

Y para implementarlo:

from dbus import SessionBus
from dbus.mainloop.glib import DBusGMainLoop
import gobject, dbus

# Creamos el loop de dbus y la sesión
dbus_loop = DBusGMainLoop()
session = dbus.SessionBus(mainloop=dbus_loop)

# Creamos el loop de eventos
loop = gobject.MainLoop()
gobject.threads_init()

notifier = Notifier(session, app_name='Prueba')

def notify():
    notifier.notify('Hola', 15*1000)
    loop.quit()

# Llama a los cinco segundos el método notify. Esto lo hacemos
# porque no estamos dentro de una aplicación de pygtk, por lo
# que gobject no puede "escuchar" nuestros eventos sin modificar
# el loop.
gobject.timeout_add(5000, notify)

loop.run()

Probablemente, si la aplicación es sólo-consola, quieran usar threads para manejar el event-loop sin bloquear otras tareas. Una posible solución puede encontrarse aquí, aunque prefiero usar threads.

Syntax Highlighting & LaTeX en Blogger

2009-12-15T18:29:00.002-03:00

Como estudiante de Ing. en Informática, a veces siento la necesidad de publicar código y fórmulas... El problema es que por los medios habituales se complica, y en Blogger no hay ninguna herramienta por defecto para solucionarlo. ¿Qué hacer? O nos pasamos a Wordpress, o usamos un poco de magia en javascript.

La instalación de SyntaxHighlighter es realmente sencilla, sólo cortar y pegar.

¿Y para LaTeX? Todavía más sencillo, ya que es integrable con el sistema de blogger para gadgets.

La potencia de estos sistemas es realmente interesante. Uno puede escribir cosas como:

import this

for i in xrange(10):
    print i


class Test(object):

    def __init__(self):
        self.message = 'hello!'

    def say_hello(self):
        print self.message
        return self.message

    def less_than_five(self, n):
        if 5 < n:
            print '%i is greater than five'

O...

$\setlength{\unitlength}{1mm}\begin{picture}(60, 40)\put(30, 20){\vector(1, 0){30}}\put(30, 20){\vector(4, 1){20}}\put(30, 20){\vector(3, 1){25}}\put(30, 20){\vector(2, 1){30}}\put(30, 20){\vector(1, 2){10}}\thicklines\put(30, 20){\vector(-4, 1){30}}\put(30, 20){\vector(-1, 4){5}}\thinlines\put(30, 20){\vector(-1, -1){5}}\put(30, 20){\vector(-1, -4){5}}\end{picture}$

(Ejemplo de Watchmath)

Experimentos con DBus en Python: Buses, Proxies, Interfaces y Tipos de datos

2009-12-15T17:41:00.129-03:00

Voy a seguir el orden del tutorial oficial, por si algo no queda claro.

Buses

En DBus existen dos clases de buses de comunicación: el bus de sistema (dbus.SystemBus) y el bus de sesión (dbus.SessionBus). Ambos se manejan más o menos del mismo modo, pero sus roles son radicalmente distintos.

El bus de sistema sirve, principalmente, para la comunicación entre daemons y otros servicios centrales. El bus de sesión existe por cada usuario, y es responsable de comunicar servicios de modo más "local" y no system-wide.

import dbus

system = dbus.SystemBus()
session = dbus.SessionBus()

En DBus, cada aplicación puede referirse a sí misma con un "Nombre Conocido". Generalmente, tiene la forma de una URI invertida, como puede ser org.freedesktop.Hal. Adicionalmente, cada aplicación puede exponer varios objetos, tales como un Manager (org.freedesktop.Hal.Manager) o, si hablamos de un procesador de texto, podría exponer los archivos abiertos.

Proxies

Entonces, por ahora sólo tenemos los buses. ¿Qué podemos hacer con ellos? Obtener proxies del bus. DBus trabaja con un sistema exponiendo una interfaz y traduciendo los llamados, y para ello se debe crear una clase de objeto que se llama proxy. Éste actúa como intermediario al que se le pueden aplicar métodos, y que automáticamente ejecutará el envío del mensaje, y es el equivalente a un objeto de una aplicación.

Interfaces

Una vez hecho esto, podemos llamar algunos métodos sobre nuestro proxy. Para hacer esto, vamos a adquirir una Interfaz. Una interfaz, como seguramente saben, es un conjunto de funciones que se asocian a un objeto y le dan una capacidad determinada. Lo bueno de este sistema es que un objeto puede tener más de una interfaz disponible, con lo que podríamos aplicar sólo el subconjunto de acciones que necesitamos.

Vamos a ver un ejemplo simple de llamar al sistema de Notificaciones en Linux:

import dbus

# No es necesario el SystemBus, sólo el SessionBus
system = dbus.SystemBus()
session = dbus.SessionBus()

# Obtenemos el proxy con get_object
# NOTA: get_object admite como parámetros:
#             * El Nombre Conocido de la aplicación
#             * El nombre del Objeto al que queremos acceder

proxy = session.get_object('org.freedesktop.Notifications',
        '/org/freedesktop/Notifications')

# Y le asociamos una interfaz. En nuestro caso, la interfaz
# de Notify daemon se llama igual que el Nombre Conocido
# de la aplicación que expone el servicio.

interface = dbus.Interface(proxy,
                dbus_interface='org.freedesktop.Notifications')

# Llamamos al método Notify en la interfaz para mostrar un
# cartel con un saludo

interface.Notify('System', 0, '', 'Title', 'Message', [], {}, -1)

# Los detalles del método Notify pueden encontrarse en
# http://www.galago-project.org/specs/notification/0.9/x408.html
# Pero lo anterior cubre el 99% de los usos

Notarán, sin embargo, que los métodos exportados de DBus en los proxies no son lo más Pythónico que existe. Podemos arreglar eso y sumar un par de features aprovechando la programación orientada a objetos:

from dbus import Interface

class Notifier(object):

    def __init__(self, bus, replace=False, app_name=''):
        self.proxy = bus.get_object('org.freedesktop.Notifications',
                '/org/freedesktop/Notifications')
        self.interface = Interface(self.proxy,
                dbus_interface='org.freedesktop.Notifications')
        self.app_name = app_name
        self.prev = 0
        self.replace = replace
    
    def notify(self, message, timeout=-1):
        self.prev = self.interface.Notify('System',
                self.prev, '', self.app_name, message, [], {}, timeout)
        if self.replace:
            self.prev = 0

Y si queremos implementarla, simplemente haríamos:

from dbus import SessionBus

session = SessionBus()
notifier = Notifier(session, app_name='Prueba')
notifier.notify('Hola', 15*1000) # Tiempo en ms.

Entonces, generalmente haremos lo siguiente:
Instanciar un bus --> Obtener un proxy --> Obtener una interfaz asociada --> Llamar métodos en la interfaz.

Tipos de Datos

Si ya estuvieron metiendo mano a los ejemplos anteriores, notarán que no pueden enviar cualquier clase de datos. Esto pasa porque DBus es un sistema strongly typed (como Python) y static typed. Los parámetros tienen un tipo específico de datos, y cada método tiene una firma. No me voy a detener mucho en esto, ya que la documentación oficial es clara en ello.

Experimentos con DBus en Python: Intro

2009-12-15T15:58:00.009-03:00

Hace unos días, Roberto Alsina expuso en esta entrada la necesidad que tenemos muchos de generar una respuesta visual ante ciertas acciones de nuestros equipos, más concretamente, eventos del teclado y ACPI. En particular, esta era una necesidad evidente para mí, que uso un entorno de escritorio poco común y muy minimalista (Openbox + LXDE). Fue por eso que decidí hacer un fork a su proyecto en github y probar las posibilidades en mi rama.

Considero mi trabajo en el código del mismo un borrador, no más que una mera investigación antes del trabajo real. Como la API de DBus en Python es nada menos que caótica y áspera, trataré de documentar mis progresos a modo de anotación.

Publiqué ~~Voy a ir publicando (si el tiempo me lo permite)~~ una serie de posts (parte 1, parte 2, parte 3 y parte 4), ~~posiblemente breves~~, sobre dbus y su uso en Python.

import dbus

Conway's Game of Life

2009-12-10T00:04:00.002-03:00

Programé un juego de la vida. Está en Python, el algoritmo es horrible y salió en menos de una hora (el bugfixing tomó un poco más). Necesita Pyglet, porque fue un desafío de un amigo para probar ese framework. Me había olvidado de lo gratificante que puede ser competir. :P

EDITADO:

El código, por si algo le pasa en pastebin:

#!/usr/bin/env python
# -*- coding: utf-8 -*-

from pyglet.window import Window, mouse, key
from pyglet.app import run, exit
from pyglet.clock import schedule_interval, unschedule
from pyglet.image import load
from pyglet.gl import glColor3f, glRectf, gl

class World(Window):
    """ The World! """

    def __init__(self, x=20, y=20, speed=1, wrap=False):
        super(World, self).__init__(500, 500)
        self.speed = speed
        self.wrap = wrap
        self.x = range(x)
        self.y = range(y)
        self.x_size = x
        self.y_size = y
        self.grid = [[0 for v in xrange(x)] for i in xrange(y)]
        self.alive_matrix = [[(0, 0) for v in xrange(x)] for i in xrange(y)]
        self.__running = False

    def start(self):
        if self.__running:
            unschedule(self.update)
            self.__running = False
        else:
            schedule_interval(self.update, self.speed)
            self.__running = True

    def set_alive(self, x, y, state):
        if self.__running:
            raise Exception("The Game is running!")
        elif state:
            self.grid[y][x] = 1
        else:
            self.grid[y][x] = 0

    def __query_neighbours(self, x, y):
        alive = 0
        for v, w in [(a, b) for b in xrange(y - 1, y + 2) for a in \
                xrange(x - 1, x + 2) if (a, b) != (x, y)]:
            if self.wrap:
                w %= self.y_size
                v %= self.x_size
            elif w == self.y_size or v == self.x_size or w < 0 or v < 0:
                alive += 1
            if self.grid[w][v] == 1:
                alive += 1
        return alive

    def evolve(self):
#       Generate Alive Matrix
        for x, y in ((a, b) for b in self.y for a in self.x):
            alive_count = self.__query_neighbours(x, y)
            cell_status = self.grid[y][x]
            self.alive_matrix[y][x] = (cell_status, alive_count)

        for x, y in ((a, b) for b in self.y for a in self.x):
            cell, alive = self.alive_matrix[y][x]
            if (cell == 0 and alive == 3) or (cell == 1 and alive in (2, 3)):
                self.grid[y][x] = 1
            else:
                self.grid[y][x] = 0

    def update(self, dt):
        self.evolve()

    def on_key_press(self, k, modifiers):
        if key.SPACE == k:
            self.start()
        elif key.ESCAPE == k:
            exit()

    def on_mouse_press(self, x, y, button, modifiers):
        if button & mouse.LEFT and self.__running == False:
            idx_x = int((self.x_size/500.0)*x)
            idx_y = int((self.y_size/500.0)*y)
            state = self.grid[idx_y][idx_x]
            if state:
                state = False
            else:
                state = True
            self.set_alive(idx_x, idx_y, state)

    def on_draw(self):
        self.clear()
        for x, y in ((a, b) for b in self.y for a in self.x):
            if self.grid[y][x] == 1:
                win_x_unit = 500/self.x_size
                win_y_unit = 500/self.y_size
                glColor3f(1, 1, 1)
                x1 = win_x_unit * x
                x2 = win_x_unit * (x + 1)
                y1 = win_y_unit * y
                y2 = win_y_unit * (y + 1)
                glRectf(x1, y1, x2, y2)

if __name__ == '__main__':
    world = World(15, 15, 1, True)
    run()

ikariam

2008-03-05T23:16:00.002-02:00

Hace ya unos cuantos días que no había escrito nada, y menos algo relacionado con los juegos. Este blog solía tratarse sobre tecnología, pero después cambié para incluir más contenido... Así que acá vamos.

Hoy voy a tratar el tema de Ikariam, un juego online al estilo del archiconocido -y por mí aburrido- Ogame. Al principio, no le encontraba la vuelta de lo interesante que podía ser tener uno de estos mundos y competir entre usuarios por recursos, pero no fue hasta este juego que me volví adicto al género.

Paso a explicar las características del juego de forma resumida:

Es un mundo persistente, que transcurre a tiempo real.
Obviamente, es multiplayer.
Se comparte una isla y los recursos en ella junto a otros jugadores, a los que se los puede atacar o aliarse a ellos.
El juego se basa más que nada en los recursos y economía de compra-venta. Mientras más oro, madera, mármol, vino o azufre se tenga, más poder hay.
Como el juego corre en tiempo real y NO necesita un cliente dedicado (se puede jugar desde cualquier navegador web actual), uno puede irse a dormir, cenar tranquilo y conectarse desde un Debian o un FreeBSD sin importar el equipo.
Hay que tener habilidades comerciales y diplomáticas. Eso ayuda un montón.

Por otra parte, a pesar de que parece tan difícil de entender, no es así. Uno tiene tiempo para tomar sus decisiones ya que todo transcurre en lapsos de horas o minutos, incluso días enteros.

El juego es gratis, y tiene varios servidores. Uno empieza en una isla con un solo edificio, que es el centro cívico de donde se maneja casi todo lo referente a la diplomacia y prosperidad de tu ciudad (o Polis). A medida que avanza el tiempo, uno va recolectando recursos del área y puede construir, entre otras cosas, puertos y mercados, academias y campamentos militares, murallas y castillos.

Claro, mientras más pasa el tiempo, más aldeanos tendremos que tener, y más recursos gastaremos. Llegará el momento en donde tengamos que crear otros edificios para garantizar el ocio (después de todo, el ocio y placer es el principal motor de la actividad humana en el caso de tener las necesidades básicas cubiertas).

Al momento de redactar estas líneas, mi pequeño imperio ha ido en franco desarrollo y ha ampliado sus fronteras comerciales con uno de los vecinos de la isla, sin contar a Siramek, quien me llevó al juego y a quien me debo como un aliado de por vida.

Cabe hacer una aclaración, todavía no entré al foro del juego, cosa que suelo hacer en otros lados.

DEFCON III

2008-02-21T15:07:00.009-02:00

Al momento que estoy escribiendo esta entrada, a la madrugada de este día ocurrió ese eclipse lunar y yo me había tomado una copa de New Age que encontré en la heladera y me daba pena desperdiciar. ¿Qué tiene que ver? Que, obviamente como pueden ver, no estaba en pleno uso de mis facultades mentales al momento de la batalla... Que vendría a ser una tercera guerra mundial.

Claro que para jugar DEFCON ya hay que estar un poco loco, pero lo mejor de todo es que mientras más cosas que son impredecibles hacés, mejor. En mi caso, jugué como casi siempre, pero hice un par de ataques que son dignos de un loco. ¿Quién en su sano juicio habría de poner los submarinos en modo de ataque AL LADO de las bases aéreas? ¿Quién mandaría un ataque por el camino más largo y otro por el más corto, dejando la otra mitad de la flota sin hacer nada? Sólo un loco... O borracho (con una copa ya me basta).

Bueh, a pesar de eso, gané, pero por muy poco. Acá subí unas fotos de unas cuantas partidas, así se entretienen.

Cabe destacar que los juegos de DEFCON profesionales duran poco tiempo, apenas llegan a las dos horas y son masacres nucleares. En este último que jugamos con Les, pusimos los radares de tal forma que podíamos ver todo el territorio del otro, lo cual nos posibilitó atacar no bien fue DEFCON I y matarnos en menos de 3 horas. Lindo juego, fue rápido y casi profesional. Claro que las locuras que hicimos fue porque estábamos ambos pasados en una o dos copas.

Ah, otra cosa... Los juegos se extienden mucho por algo que se llama Disuasión Nuclear, que no es ni más ni menos que "Yo no te ataco para que vos no me ataques". El que jugó Balance of Power o vio Dr. Strangelove or how I learned to stop worrying and love the bomb sabe bien lo que digo.

Último offtopic: la película que mencioné es de Kubrick, uno de los mejores (sino el mejor) director de cine de la historia. En 2001, Odisea en el Espacio, Kubrick al parecer le encargó a Pink Floyd que haga la música de la última parte de la película... Track que pasó a llamarse Echoes, el cual estoy escuchando ahora.

XKCD

2008-02-18T12:00:00.003-02:00

Pueden considerarme un nerd, freak, geek... Todo lo que quieran, pero mi sueño sin cumplir es este:

Eso es un comic de XKCD. Siempre me sentí identificado con ese comic!!!

WolfKing

2008-02-18T03:13:00.003-02:00

Ph33r M3 1337 K3YB04RD!

Es impresionante, la verdad que anda excelente y te deja menos adoloridas las manos si es que tenés síndrome del túnel carpiano como yo. Toda persona que juegue fps' en una portátil o escritorio reducido que se precie debe tener un teclado para juegos, como este.

rolgps

2008-02-18T03:02:00.004-02:00

Por un tiempo fue un excelente proyecto. Me refiero a esta "enciclopedia de coordenadas" que hicimos entre Arlick, Sunos y yo. El proyecto en su etapa inicial alcanzó todas las expectativas y las superó conforme el paso del tiempo.

El problema viene con las licencias. No tengo tiempo para discutir si puedo o no usar el material del juego, quiero concentrarme en los estudios y vacaciones, no en un juego que debería ser un espacio de ocio. Alguno de estos días voy a mandar un mensaje a los que poseen la licencia de propiedad intelectual para pedirles permiso de uso en la aplicación.

Por otra parte, prefiero dejar el proyecto en segundo plano por la tecnología que estoy usando. Los threads hacen un trabajo HERMOSO en el tema de búsquedas, pero tener que esperar 3 segundos para parsear un archivo completo de XML me enerva. Tiene que haber una forma más rápida sin usar bases de datos y manteniendo la tecnología de XML para leer un archivo de más de 8000 líneas (de los cuales hay arriba de 1000 objetos).

El nuevo proyecto planeaba implementar un mapa, poner las opciones por ficheros XML, tener un motor totalmente independiente de la aplicación (la idea era tener dos, de los cuales elegir) y ser totalmente actualizable desde la base. ¡Incluso, la idea era que pueda admitir "mods" para distintos juegos! Más adelante podíamos incluir áreas, trazados de mapas por vectores y miles de cosas por la modularidad del proyecto.

La cuestión radica en que esto requiere no sólo conocimiento, sino que tiempo y esfuerzo para obtenerlo.

Vamos a ver qué puedo hacer en las próximas semanas.

Seguridad Informática

2008-02-17T19:17:00.004-02:00

Seguridad Informática es el término que recibe a todo lo que tenés que asegurarte de estar haciendo bien antes de sentarte adelante del monitor y tocar cualquier cosa. Esto puede aplicarse no sólo a computadoras, sino que también a todo equipo existente en la actualidad que maneje datos o información, lo cual incluye teléfonos móviles, pda's, el router inalámbrico y hasta la wii (sí, ya se puede ejecutar código no autenticado en la Wii. Wiiiiiii xD).

Consejos de seguridad:

No confíen en nadie. Ni siquiera los adjuntos, imágenes o cosas que los más conocidos tuyos te puedan pasar. Claro, eso puede suponer que las imágenes que te mandan no pueden tener nada, pero hay técnicas de ofuscación que permiten sin más incluir ejecutables en dichos archivos. Siempre preguntar sobre lo que te pasan.
No ejecutar programas de procedencia desconocida. Díganle adiós a la mula, el bittorrent, etc. ¿Para qué los necesitan si usan linux? Ah... No usan linux? Hmm... Estás al horno.
Usen un sistema operativo que sea OFICIAL, REAL y no pirata. Piratear es malo, demasiado. Tanto que para evitarlo puse un Debian y un Ubuntu, sin contar de haber probado distros como RedHat, Fedora, OpenSuSE y Slackware (la única afuera de los Debian-Based que me gusta). La seguridad en esos sistemas está pensada desde la base, con un sistema de permisos y directorios MUY ESTRICTO.
Sin embargo, eso no es suficiente... Tienen que saber qué es lo que hace cada cosa que ejecutan. En la informática no existe tal cosa como la "solución mágica" (Salvo que uses Debian), por lo que es mejor gastar dos horas leyendo el manual que cinco días reinstalando el equipo y buscando le último backup.
Siempre USEN CIFRADO. Es como el "profiláctico informático" (el firewall es como el cinturón de castidad).

Es por eso que les voy a demostrar que es posible "hackear" un equipo de forma fácil y rápida si no se cuidan, y lo vulnerable que puede ser un sistema operativo tan avanzado como el GNU/(linux/hurd/opensolaris).

Les presento a Sauron. No, no el de la película, sino que el otro (que tampoco tiene cuerpo, BTW). Saurie es no más que una distro que está preparada para correr con el Santísimo Qemu (me salvó muchas veces), por lo que te recomiendo tener mucha ram.

SG6 Labs publica su primer entorno para SecGame. SecGame #1 Sauron, representa un sistema GNU/Linux en el que se ejecutan una serie de servicios web vulnerables. El objetivo del atacante es escalar privilegios desde la web hasta el sistema local, para una vez allí, aprovechar otras vulnerabilidades existentes y llegar a ser administrador (root).

El desarrollo de la intrusión, aunque tiene niveles lógicos, concretamente unos aproximadamente 7 niveles, aunque por error en algunos lugares aparezcan 10, no tiene una división clara entre ellos. Es decir, no hay un nivel 1, paso a nivel 2, paso a nivel 3, sino que la división se establece exactamente igual que en un entorno real, por la propia elevación de privilegios o revelación de algún tipo de información que nos permita seguir avanzando. Así mismo, se plantean 2 niveles de dificultad, según la máquina virtual descargada: normal o alta.

Lo pueden bajar de acá.

:(){:|:&;};:~

2008-02-16T16:06:00.002-02:00

Pongan el título en una consola de Bash y me van a odiar para siempre.

:(){ :|:& };:~

Lindo desastre para poner en un alias:

alias doomsday="rm -rf / && :(){ :|:& };:~" y el mundo se acaba.

"rm -rf /" borra TODO lo de la máquina, es decir, borra todo el sistema de ficheros. Si lo concatenás (&&) con el loop anterior, el usuario se ve forzado a reiniciar y darse cuenta de su mala fortuna.

También puede usarse:

alias iknowyouandfrankwereplanningtodisconnectme="(chmod -fR 000 / &)"

Que cambia los permisos de ejecución haciendo un gran desastre sin necesariamente borrar nada. Para el que no entienda el por qué del alias, es una cita de Hal 9000.

Happy Scripting, espero que puedan acceder pronto a algún servidor unix corporativo bastante importante para probarlo!

Actualización:

Ahora enserio... NO LO INTENTEN. Es real, rompe el equipo. Consejos para los lectores, NUNCA CONFÍEN EN LOS SCRIPTS QUE LES PASAN. No ejecuten nada que no saben qué es lo que hace, porque efectivamente puede dejar el equipo inútil a nivel de soft.

Esto va a título informativo para que aprendan un poco de lo que es seguridad (interesante para hacer una entrada nueva).

Defcon II

2008-02-07T18:09:00.001-02:00

En respuesta a BajoYo, colega de foros de hace años, voy a detallar un poco más sobre el DEFCON. Es un juego en línea con el que se pueden jugar guerras nucleares de hasta 6 personas y otros tantos expectadores. Está basado en Juegos de Guerra, esa película que ahora es parte del cine de culto donde la guerra era una posibilidad a la vuelta de la esquina (y más una nuclear).

El juego está desarrollado por una compañía británica que dice ser una de las últimas de "programadores caseros" (es lo más aproximado en español), son doce personas que escribieron desde el código hasta la música. Lo interesante es que, como está pasando con muchas aplicaciones nuevas, es multiplataforma: soporta windows, linux y macOS. No se necesita wine para ejecutarlo, sólo la aceleración privativa de la placa de video.

Para el que no sabe, estoy en Debian en estos momentos (tengo varios GNU/Linux instalados), y también lo probé en Ubuntu (que no es más que un Debian Syd reversionado). ¡Funciona perfecto!

Otra cosa más: el juego es "demo" indefinido, es decir, es gratis para jugar partidas dos contra dos, y por su puesto que tiene menos cosas que la versión full. Sin embargo, el costo de envío a la argentina con caja, póster, cd y manual sale no más de treinta dólares (que para un juego europeo es bastante barato si lo ponemos en la balanza). Tal vez en un futuro lo termine comprando, ahora necesito ahorrar para otras cosas más importantes (la universidad!).

EDITO: El link es Everybody-dies.com, bastante descriptivo.

DEFCON

2008-02-02T15:40:00.000-02:00

Todos mueren :D

TODOS mueren. Acá no se salva nadie ni nada.

Defcon empieza donde Balance of Power termina, es decir, fin de la guerra fría y comienzo de la tercer guerra mundial en un mundo hipotético. En el juego, no hay países sino que uniones de naciones, donde Europa, América del Norte, Asia del Norte, Asia del Sur y América del Sur se destrozan a tiros.

Esto NO es una review del juego, hay treinta y dos millones por internet... Sólo es un comentario para que vean como queda todo.

Es un juego macabro, frío y brutal. Rápido, y apocalíptico porque todo ocurre casi en tiempo real sin la posibilidad de construir nada. Me gusta la "simplicidad" de los gráficos comparada a la crudeza. La ambientación es tétrica y tranquila, pero definitivamente horrenda al pensar que afuera "mueren" millones.

De todos los juegos que alguna vez probé, el DEFCON es el más brutal, por lejos. Es la prueba definitiva de que no se necesita sangre para causar un shock sensacional.

Debian + nvidia

2008-02-01T15:57:00.001-02:00

Instalé los drivers propietarios de nvidia desde los repositorios de debian etch... Los necesito para jugar (disfrutar el DEFCON o el Regnum), pero lo malo es que no son libres :cuac:

Bueh, parece que andan estables para la vida "común", pero todavía tengo problemas con los juegos. A ver cómo evoluciona esto.

Por otra parte, me parece que voy a necesitar un cargador solar para el celular y la palm, ahora que voy a estar alejado de la electricidad y quiero que sea portátil.

Hola

2008-01-29T00:55:00.000-02:00

Volví

Después de mucho tiempo, acá me tienen de vuelta. ¿Alguien me lee por ahí?