Ya corregí el error que tenía el grabber (hay veces que no me gustan o no entiendo las traducciones de las cosas a español) de darklyrics.com. Y envié el parche a bugzilla.
Heroe del día: foo = re.escape (foo) venció por decisión unánime a:
foo = foo.replace ('(', '\(')
foo = foo.replace (')', '\)')
# ...
# así por cada caracter que hay que tendría que escapar
Rhhythmbox es un reproductor de archivos de audio similar a iItunes para linux, aunque hay muchos similares este es mi favorito y he tratado de colaborar de a poco con él, ayer mandé mi segundo parche y mañana debo enviar el tercero.
Antes un poco de historia:
Cuando deje Windows por la paz, una de las razones principales es que no era divertido, de hecho era bastante incómodo realizar tareas muy comunes, otras tareas eran obligatorias así que disfrutarlas o no era lo de menos. Navegar era la principal, no me sentía bien haciéndolo, me limitaba bastante, no sabía realmente que era pero algo no me gustaba.
La solución llegó algún tiempo después de cambiarme a GNU/Linux. Apareció Galeon, en ese momento era el navegador número uno del software libre, con su ligereza, velocidad, sus pestañas para navegar, me hicieron redescubrir la navegación de web. Como un año después comenzó el desarrollo de Firefox y este se convirtió en el ganador, aunque ya me fue por la sencilla elegancia de Epiphany.
Una vez solucionado tan importante tarea, durante mucho tiempo me incomodaba escuchar música en la computadora, organizar todos los discos, tags con soporte a caracteres internacionales, encontrar rápido la canción que busco. Sin embargo con el XMMS (clon de winamp) sobrevivía. Luego llegó la revolución llamada iTunes y programas similares comenzaron a emerger en Linux. Rhythmbox fue uno de ellos.
Rhythmbox + last.fm me satisfacen en mis necesidades musicales, es una actividad que realizo con placer por que las herramientas cumplen su propósito de forma adecuada. Por eso he querido contribuir en algunas ocasiones a la comunidad de Rhythmbox y del sitio last.fm. Ya he enviado algún parche antes a Rhythmbox y estoy en el canal de IRC para ayudar a algún usuario, pero ahora realmente deseo hacerlo de forma constante.
Promesas nada más, pero este es mi TODO, muchas cosas no se integrarán al código principal, pero es algo que quiero dar para el que pueda tomarlo:
Al fin de cada punto del TODO pongo el lenguaje en el que voy a hacerlo o al menos el que creo que utilizaré. No puedo dejar de mencionar lo sencillo que es hacer código en Python, en el futuro cuando termine me gustaría hablar de las dificultades que tuve para hacer cada cosa y en que intervino el lenguaje necesario en esas actividades.
Siendo Rhythmbox una aplicación hecha en GTK+, hace que el que desee colaborar tenga que conocer en mayor o menor medida GObjects, GTK, Glib, GStreamer. A veces hacer eso puede resultar una tarea grande, hay muchas convenciones que seguir, mucha documentación (las API's) para leer, pero pocos ejemplos de como hacer las cosas, entonces a base de intentos, imaginación y mucho google, uno tiene que ir descubriendo que hace cada cosa, si lo que uno cree es verdad y como se realizan las cosas que uno quiere. Este es un proceso de experimentación que se lleva mucho mejor acabo en la limpia sintaxis de Python agregado al hecho de que es un lenguaje "interpretado" o por lo menos que quita una tarea del proceso de programamción:
Edita, salva, compila, ejecuta.
Doy gracias por Python, PyGTK (Gtk+ en Python) y especiamenet Rhythmbox tenga soporte a plugins en Python... gracias doc y todos los que han hecho estas grandes piezas de software.
El jueves pasado inenté dar una plática de Django en el ITNL, por invitación del Grupo de Usuarios de GNU/Linux del ITTNL.
Y digo intenté por que la hice muy larga al parecer, en parte por que no parecían muy conocedores de los temas previos necesarios para esto y tuve que explicarlos uno a uno, y en otro por que me faltó hacer un resumen más estricto.
Quedamos que en otra ocasión daré la continuación. Por lo pronto dejo la presentación en PDF y mi script (está en UTF-8, lo tengo que aclarar por que mi sitio está en ISO-8859-1). Es sólo de la parte de que dí que es una plática general de lo que es programar en Web, tardé 40 minutos en darla.
Por cierto, la idea era dar el tutorial oficial sencillamente, por lo que leerlo y seguirlo debe dar el mismo o mejor resultado.
Un mal día, mi jefe llegó preguntando por un forma de analizar unos logs de un programa que utilizamos. Primero una cosa sencilla, y mi tonta cabeza pensó:
Procesamiento de texto + Algoritmo simple = Perl
No lo vuelvo a hacer.
En ese momento pareció y fue buena idea, detectar un patrón de texto en un archivo, organizar un poco el texto y limpiarlo, parecía y fue factible, cuestión de minutos, más tiempo en recordar Perl, afinar la expresión regular, ver unos cuantos ejemplos sobre arreglos (pero se veía que llegaba a cosas oscuras) y listo.
Luego al ver el resultado y que había áreas de oportunidad, el requerimiento creció considerablemente; se encontró un error y seguimos para adelante.
El error fue resuelto, no sin sus problemas. En mi cabeza rondaban distintas formas de resolverlo, alguien con idea en el problema del análisis de texto podrá recordar estos problemas alguna vez:
Teoricamente el archivo tiene la forma:
[Una linea]
[Una linea]
...
Pero en realidad tenía la forma:
[Una linea]
[Una linea][Una linea]
[Una linea][Una mentirosa linea][Una linea]
[Una
linea]
[Una
linea][Una linea]
...
Y combinaciones peores que esa. Así que como opciones encontré:
Al final, después de pensarle un poco dí con una solución correcta. Pero recae muy poco en el poder de Perl de manejar expresiones regulares, tanto que podría haberlo escrito en Python sin ningún contratiempo, al menos no hubiera sido peor que lo que había hecho en Perl.
Pero hasta ese momento puedo presumir de que Perl había realizado su tarea sin muchos problemas. El problema fue cuando quise implementar los requerimientos extras.
En cuanto a mis requisitos para el lenguaje, una vez diseñada mi solución (y que decidí limpiar un poco el código) son:
Estas cosas suenan de lo más natural e inocencentes y han probado ser una desgracia infinita para mí. No por que no pueda resolver mi problema, sino por que no encuentro la forma correcta de hacerlo. Me centraré en el problema de las referencias para ejemplificar. Tengo un archivo de pruebas que voy generando mientras voy aprendiendo gramática nuevas (Sí, mientras voy aprendiendo formas nuevas de hacer lo mismo sigh).
Al inicio del archivo declaro mis buenas intenciones, la prueba es
clásica, declaro una variable ($a) luego hago una referencia a ella
$b y modifico el valor de la variable via su referencia. No me voy a
meter en lo feo que se ve \$, yo creo que esto aceptable en un
lenguaje como Perl:
# Trying to learn how to use references in perl
# Lesson 1: Make reference with \$ and dereference with $$
$a = "pp";
$b = \$a;
$$b = "qq";
print "\$a changed via \$\$b $a\n";
Después intento hacer lo mismo via referencias, tomo la referencia de
$a via \$a sin variables intermedias, está todo bien, cuando
declaro la variable con my, no pongo $$, sólo en el resto de los
casos. Esto es coherente, puedo pasar de mi lección 1 a la lección 2
sin problemas:
# Lesson 2: This works for functions too in the same way \$ and $$
sub t {
my $p = shift;
$$p = "rr";
}
t(\$a);
print "\$a changed via t(\\\$a) $a\n";
Por alguna extraña razón en mi script de trabajo, necesito utilizar prototipos (que por cierto no pudieron ser más feos) así que me pongo a probar como hacer prototipos. Y aquí es donde surge la duda, ¿qué recibe la función? Siendo coherente con la lección 2, una referencia a escalar (\$), no un escalar realmente, pero aparentemente las referencias a escalaras son... escalares. Así que yo no me fuí con el ejemplo anterior y jugué un poco, después de esto obtuve este código funcional:
# Lesson 3a: with prototypes
sub u ($);
u(\$a);
sub u ($) {
my $p = shift;
$$p = "ss";
}
print "\$a changed via u(\\\$a) $a, with prototype u(\$)\n";
Poniendo atención a la linea de asignación en la función `$$p = "ss"`. Por que aquí viene el momento en que decimos Bienvenido a Perl:
# Lesson 3b: same to the one above but using declaring the reference
# in the function no in the call
sub v (\$);
v($a);
sub v (\$) {
my $p = shift;
$$p = "tt";
}
print "\$a changed via v(\$a) $a, with prototype v(\\\$)\n";
Veamos, utilizando una referencia ahora sí, entonces, resulta que $p
tiene una referencia que con $$p se puede "desreferenciar". Bien
entonces si \$a es una referencia y $a es un escalar, ambos
enviados a una función, $$p, sirve para acceder al mismo valor
en ambos casos? ¿\$a y $a son sinónimos? No, pero me dan el mismo
resultado, ¿cómo se supone que debo hacerlo? Buscando esta respuesta
se me ocurrió otra combinación:
# Lesson 3c: same to the others, not declaring reference in the call
# nor the declaration, just use it via $$
sub w ($);
w($a);
sub w ($) {
my $p = shift;
$$p = "tt";
}
print "\$a changed via w(\$a) $a, with prototype w(\$)\n";
Aquí es donde nos paramos de la mesa y mejor nos vamos a otra cosa. La
función espera un scalar, recibe un scalar, y mágicamente, con la
soberana autoridad de hacer lo que se le da la gana "desreferencia"
un scalar ¿? Sí. Eso hizo y tengo un nuevo valor para $a.
En este momento me parecía que la última, ya que aunque no era explicita -ni mucho menos- era la menos fea (la \ es horrible). Aunque es la peor en términos de su significado (no dice nada al respecto de que se esta haciendo). Pero cuando intenté extender esto a arreglos me dí cuenta que esa era mi peor opción.
Eso lo pondré en otro episodio más de: No importa cuanto procesamiento de texto te prometan, si un lenguaje programación no es capaz de mantener una sintaxis estable y elegante para estructuras de datos complejas gira la página y vete al siguiente.
