Subí el material de la charla (incluido el código de los ejemplos, y el .info que usé para Impressive).  También van a estar disponibles desde el sitio de PyCon.

La charla en sí empieza desde abajo, leyendo los bytes del cable y viendo de qué se trata el protocolo, como para ver que no es complicado, y que son unos poquitos bytes con la información de los eventos a medida que van ocurriendo.

Una vez que tenemos los eventos podemos hacer un montón de cosas (guardarlos en un archivo, hacer que suenen por los parlantes, procesarlos y mandarlos de vuelta al dispositivo para que suenen).
Con los eventos guardados en un archivo podemos hacer otro montón de cosas parecidas.
En algún momento paramos para ver un poco de la especificación de MIDI y el formato de archivos .MID, y después seguimos probando cosas.

Creo que lo más complejo que vimos (y lo que me interesa continuar mejorando) es que si le damos una ‘partitura’ a la computadora, te puede ir siguiendo mientras tocás y alterar los eventos a medida
que suenan.

Alguien filmó una parte en que uso el teclado (piano) como teclado (input device) que es una filmina al final que medio que corta con lo que venía haciendo, pero como hack estaba divertido así que lo puse.  Creo que le puede servir a la gente que quiera usar el dispositivo MIDI para incorporarlo en juegos y cosas así.

Cada vez que preparo una charla peleo para conseguir que el código se vea lindo en las filminas.

Lo que solíamos hacer (creo que fue Nati Bidart que me mostró esto) era abrir el código Python con Kate, exportar como html, abrir el resultado con Firefox y copiar y pegar eso al Impress.  Esa era la forma fácil!  Desafortunadamente eso parece que ya no funciona en OOo 3, o a mí no me anduvo esta vuelta.

Buscando alguna otra alternativa me crucé con este código de Brian Cole.  No parece funcionar así como está, pero con un par de arreglos ahora anda con OOo3 y todo.

Así que, si tirás este código en ~/.openoffice.org/3/user/Scripts/python/ te agrega una macro que te colorea todas las cajas de texto con cierto color de borde (yo lo tengo en Blue 8, que pega con el estilo que estoy usando ahora).

La idea del código original de decidir cuáles cajas de texto corresponde colorear basado en un estilo me parece mejor, pero en un hack rápido no me puse a buscar cómo hacer eso.  Capaz lo agrego en algún momento (se agradecen parches! ).

Resulta que Google Maps recientemente subió datos de rutas, calles e información de geocodificación para varias zonas de la Argentina. Ahora qué vamos a hacer los geo-web-hackers argentinos?

Dos charlas que no había visto antes, las de Chipaca y de Nubis, estuvieron particularmente interesantes. Entornos de desarrollo, verificación y despliegue reproducibles (de John) fue un paseo por distintas herramientas como distutils, setuptools, easy_install, buildout y buildbot. Es una parte del desarrollo que a veces le restamos importancia pero que le suma muchísimo valor al proyecto si se los usa bien, y la charla te dejaba con ganas de aprender a usarlas mejor.

En Hacking Django Nubis mostró de un pantallazo tres formas interesantes de extender la funcionalidad de Django, con xmlrpc, stateful views, y Comet. Son excelentes ejemplos de cómo Django permite jugar o experimentar, sin esclavizarte al framework.

Se sintió un poco raro estar en el evento y no exponer nada, ni charla, ni taller, ni lightning nothing. Estuvo muy bueno, sin embargo, (buenísimo, diría Chipaca en su charla) la experiencia de stress cero, disfrutar de las charlas y los cafés sin estar preparando la mía. Muy mal mi vagancia, y retenme si lo vuelvo a hacer, pero vale la pena de vez en cuando

Cuando nos bajamos del colectivo estaba fresco, un poco nublado. Caminamos un tramo por la ruta, mirando las casitas de Los Cocos y su gente, la mayoría turistas como nosotros a esta altura del año. Después otro tanto por camino de tierra, hasta el Allen. Conozco el Allen Gardiner desde chiquito, con su amplio salón común con el hogar que se enciende en invierno, sus salones dormitorio atiborrados de cuchetas, y sus jardines, el fogón, la pileta. Era un poco como volver a casa.

Llegamos y encaramos para el salón. Rodeando largas mesas cubiertas de notebooks y cables encontramos a la gente, algunos en pares o de a tres mirando algo en un mismo monitor, algunos en la suya. La mayoría ya conocidos en persona, por la lista o el canal de IRC, pero también algunos nuevos.

En una punta estaban las pizarras todavía mostrando el cronograma de actividades, entre sprints, charlas, talleres y caminatas. Viendo que a esa hora se estaba charlando sobre librerías y herramientas para el PyWeek me fui para el fogón a ver qué tal. Encontré que la charla estaba animada, discutiendo si para los menúes conviene más usar algo como un scene graph o como un windowing system, o si lo que hace falta es otra cosa que no es ni uno ni lo otro.

Esto era el PyCamp. Veinte programadores durante un fin de semana largo en las sierras de Córdoba. Para cuando nos fuimos a casa el martes, después de un sprint de la CDPedia, un WebFramework deathmatch, y una pila de charlitas y almuerzos, había resuelto mi primer bug de Python, participado de una reunión de PyAr, avanzado bastante con pynethack y comido un montón.

El clima acompañó de a ratos. Llovió uno de los días que queríamos salir a caminar, y nos dejó a todos adentro y sin enchufar las compus por miedo a los cortes de luz con picos de tensión. En los días de sol pudimos subir al mástil y hasta meternos en la pileta un poco. La comida estuvo excelente, y el ambiente en general fue de lo mejor. Por un lado podíamos dedicar todo el tiempo a hacer cosas con Python que por lo general postergamos, y por otros las charlas, debates y hasta los momentos de café fueron cosas que aportaron la mayor riqueza al campamento.

Para los que se lo perdieron, seguramente habrá otro, no se dejen estar. Para los que sí fueron, fue un enorme gusto poder compartirlo con ustedes, amigos!

(Hay más fotos acá, gracias Facu!)

Lo que hubo que recortar fue:

• GConf. No teniendo GConf atrás para guardar y buscar variables se pierde la persistencia de características como la de las preferencias o el tamaño de la ventana, cada vez que reinicies el juego. Se podría hacer con un archivo de configuración eventualmente, pero no era nada tremendo.
• LibGnomeUI. En realidad resultó ser sólo la funcionalidad de gnome-window-icon, que parece estar deprecada ya, o sea que nada grave.
• LibGnome. Se usaba para ubicar los archivos de datos del programa, para mostrar el archivo de ayuda, para interactuar con el session manager, y para un par de otras cositas.

… y después anduvo!

Me sorprendió lo poco intrincado que se hizo convertir esta Gnome-App en una Gtk-App. Un poco más de trabajo y tuve un instalador para Windows de Five-or-More. En particular, me gustó que lo que tuve que resignar fue sólo la Gnomosidad de la aplicación, y que no encontré que usara algún super-widget que hiciera mucha magia y que fuera exclusivo de Gnome.

Un poco después me encontré con esta página donde explican que están trabajando en hacer que muchas bibliotecas chiquitas que antes formaban parte de Gnome pasen a formar parte de Gtk, y en dejar en bibliotecas de Gnome sólo lo Gnome-específico. En particular, parece que LibGnome y LibGnomeUI van a ser deprecadas por allá por 2.19.

Me parece una idea excelente; como desarrollador, no haría falta más depender de Gnome cuando en realidad se necesitaba otra cosa que viene con (o que depende de) Gnome. Hace poco hubo en PyAr una discusión sobre si convenía usar pygnome en Windows, y estaría muy bueno en cambio sólo necesitarlo si estás haciendo una aplicación para Gnome, o que quieras hablar con GConf o con GnomeVFS especificamente, por ejemplo. Y como usuario de Gnome, me da esperanzas de ver menos dependencias ‘exóticas’ en los paquetes de aplicaciones Gnome.

Todo salió de las CDC UNLUX 2007.

Imagínense la charla de Nethack donde la Rayis nos contaban las virtudes del juego, su profundidad y complejidad, la cantidad de combinaciones posibles y desconocidas, y la fascinación generada por un juego aparentemente tan sencillo… ahora imaginen que en el público había 5 o 6 personas de PyAr.

Naturalmente después de la charla, alguien tiró la idea de que estaría buenísimo poder scriptear Nethack con Python. La idea de ponerse a escribir un bot que juegue Nethack y sobreviva en el calabozo suena, por lo menos para algunos que recuerdan con nostalgia los torneos de cRobots, tan divertido como realmente jugarlo.

Entonces me puse a hackear algo para hacer eso.

Mi idea original era hacer bindings de Nethack para Python, pero eso resultó bastante complicado. Después de bajar el código y mirarlo un rato, se nota que el código viene evolucionando hace unos veinte años ya.

La opción más clara resultó ser entonces aprovechar un servidor como DGameLaunch que permite jugar vía telnet, y usar Python para hacer screen-scraping.

Estoy usando pexpect para recibir los datos y mandar los comandos, y el screen scraping lo implementé bastante a mano con la documentación de las secuencias de escape de xterm. Probé hacerlo con curses, pero las screens buffereadas de las que podés leer no entienden los caracteres de escape. Si ya había un módulo de emulación de xterm (con una VT100 me alcanza creo ) que permita leer la información de la pantalla, o si resulta que sí se puede con curses, avisen!

La idea no es escribir bots para conectarse a servidores públicos como nethack.alt.org, si no jugar contra un servidor local. Lo que hay hasta ahora puede caminar por ahí (pero no bajar ni subir escaleras), comer y beber cosas del inventario, y consultar sus atributos. De a poco va avanzando y estoy contento con eso!