En primer lugar probé DroidCam (la versión gratuita de DroidCamX), que tenía buenos análisis. Requiere instalar un cliente para Windows/Linux y una aplicación en el móvil. El cliente para Windows iba bien, pero sin sonido (dejó de funcionar en Gingerbread y exige arrancar Windows 7 de 64 bits desactivando la comprobación de firma de drivers). Lástima. El cliente en mi Ubuntu Natty de 64 bits (basado en Video4Linux2) no funcionó de ninguna de las formas (y sí, probé con la versión de 64 bits). A veces daba errores de “Failed to write frame (bad address)”, y en otros casos tanto Cheese como Skype daban bonitas pantallas negras.

De todos modos, pensando en apoyar el desarrollo de este programa y las funcionalidades adicionales, eché los 3 euros y compré DroidCamX. Añade autoenfoque por toque, la posiblidad de cambiar la resolución y el códec para la comunicación PC-móvil y un cliente web integrado. Todo funcionó bien menos el cliente web: el formato de vídeo A no servía para resoluciones decentes, el formato B mostraba artefactos y el formato C tenía un parpadeo muy molesto al verlos por la web. Ah, y DroidCamX tampoco funcionó en Ubuntu de ninguna de las formas. Una pena.

Tras dejar DroidCamX como webcam inalámbrica para Windows, decidí probar IP Webcam. Era gratuita, pero inicialmente la descarté ya que no tenía un cliente nativo para Linux. Permite cambiar la resolución y calidad de imagen, controlar el LED del flash a distancia, grabar sonido y tiene una mejor interfaz web. A diferencia de DroidCam, creo que en vez de codificar vídeo, se dedica únicamente a tomar 15 imágenes JPEG por segundo y reunirlas en un flujo continuo (MJPEG). Eso hace que el vídeo sea algo menos suave que el de DroidCam, y que exija más ancho de banda, pero le permite reutilizar drivers genéricos para Windows que convierten un flujo MJPEG en una webcam local, utilizable por Skype y otros programas similares.

En el lado de Ubuntu requiere algo de trabajo, pero se pueden reutilizar varios programas que ya existen para usar IP Webcam como una webcam local. La idea básica es crear un dispositivo Video4Linux2 virtual que lea el flujo MJPEG y sea visible para Cheese, Skype y demás como una webcam más. Originalmente, para Video4Linux existió vloopback, pero este proyecto se abandonó tras la retirada de V4L1 a favor de V4L2 desde la versión 2.6.15 del kernel de Linux. AVLD es otra herramienta parecida para V4L1, también abandonada. Para V4L2, hay otros dos proyectos: v4l2vd (no compila a partir del kernel 2.6.31) y v4l2loopback (compila en mi 2.6.38). Así que la idea básica es crear un dispositivo virtual con v4l2loopback, y luego enviarle los datos de vídeo necesarios para nuestras aplicaciones. Para ello, podemos usar GStreamer y su componente v4l2sink, por ejemplo. Esto da mucho más juego que una simple webcam: podríamos enviar cualquier vídeo o aplicar cualquier efecto a través de esa “webcam”. Pero claro, todo tiene su complicación .

Primero, tenemos que compilar e instalar v4l2loopback, y luego cargar el módulo instalado:

sudo apt-get install git build-essentials linux-source
git clone git://github.com/umlaeute/v4l2loopback.git
cd v4l2loopback
make && sudo make install
sudo modprobe v4l2loopback

Si todo ha ido bien, deberíamos tener un fichero /dev/video* más que antes. Ese será nuestra tubería. Por lo pronto, supongamos que es /dev/video0, el primero de todos. Si queremos que este módulo se cargue automáticamente al iniciar el ordenador, tendremos que añadir estas dos líneas tras la última línea de /etc/modules:

videodev
v4l2loopback

Con el módulo cargado, ya podemos ver si capturamos bien la señal de la webcam. Para ello, iremos a la interfaz web de IP Webcam y cogeremos la URL del flujo MJPEG, que será de la forma http://ip:puerto/videofeed. Con esa dirección, lanzaremos estas órdenes desde una terminal. Si todo ha ido bien, debería salir una ventana con lo que se ve en la pantalla de nuestro Android:

sudo apt-get install gstreamer-0.10-tools
gst-launch souphttpsrc location="http://ip:puerto/videofeed" is_live=true ! \
  jpegdec ! ffmpegcolorspace ! autovideosink

Ahora podemos salir con Ctrl+C de gst-launch, y empezar a reenviar el flujo MJPEG a nuestro dispositivo V4L2 virtual. Tendremos que repetir esto cada vez que reiniciemos el ordenador, por cierto:

gst-launch souphttpsrc location="http://ip:puerto/videofeed" is_live=true ! \
  jpegdec ! ffmpegcolorspace ! v4l2sink device=/dev/video0

Vamos a diseccionar un poco esto:

• Primero, la fuente souphttpsrc accede a la dirección HTTP especificada y va bajando información en directo, sin ningún búfer (is_live=true).
• A continuación, jpegdec identifica cada imagen en el flujo MJPEG y las reúne en un vídeo en el espacio de colores YUV.
• El componente ffmpegcolorspace convierte el vídeo YUV en el formato preferido por el dispositivo V4L2 virtual.
• Finalmente, el sumidero v4l2sink escribe la información en el dispositivo /dev/video0, para que sea visible por Cheese/Skype/etc.

Ahora deberíais poder abrir Cheese o Skype (2.1.0.81, ojo, que la 2.2 beta ahora no va) y veros por pantalla . Si tenéis curiosidad, añadid un par de filtros, como:

gst-launch souphttpsrc location="http://ip:puerto/videofeed" is_live=true \
  ! jpegdec ! ffmpegcolorspace ! mirror ! videobalance saturation=0.0 \
  ! v4l2sink device=/dev/video0

Para más ideas, mirad los complementos que hay en la web oficial de GStreamer. Hay para todo. Una recomendación: si queréis video suave y sesiones largas, lo mejor es que mantengáis el móvil conectado por USB al ordenador y uséis el reenvío de puertos de ADB para enviar los datos a través de USB, en vez de por Wi-Fi. Para ello, tenéis que instalaros el SDK de Android y ejecutar esta orden:

adb forward tcp:8080 tcp:8080

Con esta orden, todo lo que enviéis al puerto 8080 de vuestro ordenador irá al 8080 del móvil, a través del cable USB. Cuando hagáis eso, será mucho más rápido acceder a IP Camera por http://127.0.0.1:8080/ que con vuestra conexión Wi-Fi.

Actualización (12:28): he conseguido que funcione el micrófono en Linux también. El esquema es un poco enrevesado: el flujo WAV de la webcam va a un sumidero nulo de PulseAudio, y la fuente asociada al monitor del sumidero nulo se usa como dispositivo de grabación de la aplicación de videoconferencia. Funciona bien, pero olvidaos de conectar por Wi-Fi . Además, he creado un guión para facilitar el uso de la cámara y el micrófono, aunque tendréis que instalar el SDK de Android y v4l2loopback a mano de todos modos. Lo he colgado por Github, por si alguien lo quiere.

Actualización (domingo 10 julio): tras hablar con el desarrollador, parece que añadirá un enlace al guión en Github en la próxima versión. Gracias a sus sugerencias, el guión ahora instala v4l2loopback por DKMS e inicia IP Webcam automáticamente si el móvil está conectado por USB y ADB está disponible. Definivamente, ha quedado mucho mejor .

Ahora estoy de estancia en la University of York con los desarrolladores de Epsilon (Dimitris Kolovos y Louis Rose), realizando una contribución más grande, y decidieron invitarme al proyecto. La verdad es que está siendo muy interesante y están saliendo cosas curiosas. Estoy ocupado desarrollando EUnit, un marco de pruebas unitarias para temas de modelos, basado en Epsilon. Tengo en la cola de prioridades un artículo acerca de él: cuando tenga algo más definido, hablaré un poco más de EUnit por aquí.

Por lo pronto tengo 50 commits que limpiar y subir al SVN de Eclipse . Por supuesto, estoy usando git-svn: es una alegría ver que puedes replantear tus 50 últimos commits limpiamente sobre los últimos cambios de Dimitris y Louis en SVN.

Una de las cosas que quería añadir en el servidor actualizado (junto con Redmine 0.9.2, la última versión estable a fecha de hoy) era soporte integrado con Git. Sin embargo, hay un problema, conocido por todos los usuarios de la red de la Universidad de Cádiz: el cortafuegos cierra el paso a prácticamente todo salvo correo y HTTP (y ocasionalmente HTTPS). Por eso, muchos de los protocolos que admite Git están fuera de la cuestión: el propio de Git (que de todos modos no serviría para los push), SSH (como lo proponga le da un patatús al CITI) y rsync (en desuso).

Git ha permitido el uso de HTTP y HTTPS desde hace tiempo sobre WebDAV, al estilo de Subversion, pero nunca me ha gustado este método. Además de sus problemas de rendimiento, de no poder usar “hooks” (manejadores de eventos) y de las molestias que origina (hay que meter un trabajo cron que ejecute “git update-server-info” periódicamente en cada repositorio), tiene una pega gravísima: la consistencia del repositorio está a completa merced de todos y cada uno de los clientes que acceden al repositorio.

Cuando di mi primer curso de Git en 2008, algunos de los asistentes me dijeron tajantemente que ni hablar de activar SSH en sus máquinas, así que probamos el acceso por HTTP. Curiosamente, el primer día que lo probamos y estuvimos mandando commits en rápida sucesión, se corrompió el repositorio varias veces. Al siguiente día, no se corrompió en absoluto, y le estábamos mandando cosas incluso más rápido que antes. Pero entonces llegó uno de los asistentes que faltaba, y dicho y hecho: a los pocos minutos estaba corrompido. El origen del problema: la versión de Curl del asistente que había venido (único usuario de MacBook en la sala, jeje) era antigua. Cuando Git trabaja sobre WebDAV, el servidor HTTP sirve de poco más que de un área de subida de ficheros. Si la versión de la biblioteca curl instalada en el cliente tiene fallos, éstos repercutirán en el repositorio (como con Curl 7.16.0). Ah, y por supuesto no hay nada de atomicidad: si el usuario pulsa Ctrl+C en mitad de la actualización o se le va la conexión, puede que el repositorio también se quede en un estado inconsistente.

Por estas razones, descarté incluso HTTP/HTTPS, y no metí Git en la instalación actual de Neptuno. Todo se quedó en una instalación de Gitosis en mi servidor doméstico. Sin embargo, Git 1.6.6 incluye “smart HTTP“, que arregla los problemas de rendimiento, llama a los “hooks”, evita la necesidad del trabajo cron con “git update-server-info” y proporciona las mismas garantías de atomicidad que el acceso por SSH. El “truco” es que ya el servidor HTTP no es una tonta área de almacenamiento WebDAV, sino un CGI que implementa los servicios que usualmente se invocan mediante SSH a través de HTTP. Lo bueno de todo esto es que además, al ser HTTP, podría integrarlo directamente con el esquema de autenticación de Redmine, con lo que un proyecto público admitiría fetch anónimo pero limitaría los push a los miembros con derecho a commit, y un proyecto privado exigiría los derechos apropiados para tanto fetch como push. La única “pega” es que hay que tener Git 1.6.6 como mínimo tanto en el cliente como en el servidor, pero bueno, los verdaderos usuarios de Git se lo compilan desde las fuentes, que no es tan difícil .

Sin embargo, esta configuración de Apache que combina las instrucciones del CGI con una variación de la propuesta en la web de Redmine no sirve directamente:

SetEnv GIT_PROJECT_ROOT /var/www/git
SetEnv GIT_HTTP_EXPORT_ALL
ScriptAlias /git/ /usr/libexec/git-core/git-http-backend/
PerlLoadModule Apache::Authn::Redmine
<Location /git>
  Order deny,allow
  Allow from all

  PerlAccessHandler Apache::Authn::Redmine::access_handler
  PerlAuthenHandler Apache::Authn::Redmine::authen_handler
  AuthType Basic
  AuthName "Redmine Git Repository"
  Require valid-user

  RedmineDSN "DBI:mysql:database=databasename;host=my.db.server"
  RedmineDbUser "usuario"
  RedmineDbPassword "contraseña"
</Location>

Cuando lo probé, no podía crear clones de forma anónima de un proyecto público: tenía siempre que introducir contraseña. Además, tampoco podía hacer push en un proyecto público, por mucho que pusiera la contraseña. La explicación es algo larga, pero es interesante (y me llevó unos buenos tirones de pelos y media mañana :-/). Está dividida en dos partes:

• El hecho de que fallaran los clones anónimos es que el manejador de autenticación de Redmine, pensado para WebDAV como está, distingue las acciones de “sólo lectura” (las que pueden hacerse de forma anónima en proyectos públicos y que no requieren derechos de escritura para los miembros de proyectos privados) del resto a través de sus métodos HTTP. Por omisión, estos métodos son GET, PROPFIND, OPTIONS y REPORT: por definición, no deberían producir cambios en los recursos a los que acceden. Sin embargo, al hacer “fetch” con smart HTTP de Git se hace una petición POST al servicio git-upload-pack, y hace que pida contraseña: nos quedamos sin fetch anónimo.
• El segundo problema se debe a que git-http-backend, el CGI necesario en el servidor para “smart HTTP”, obliga por omisión a que todos los push (peticiones al servicio git-receive-pack)  tengan algún tipo de autenticación. De lo contrario, los rechaza con un código de error 403 (Forbidden). Y aquí volvemos con el problema de distinguir las acciones por los métodos HTTP: el servicio git-receive-pack se utiliza en dos fases. La primera fase es un GET a /git/repositorio/info/refs?service=git-receive-pack: git-http-backend exige autenticación, pero el manejador de Redmine no se la pide al usuario, ya que es un método de sólo lectura. Resultado: un bonito Forbidden (403) para cualquiera que quiera hacer push. Los tirones de pelos en este lado vienen de que Git, al ver que el push por smart HTTP no ha ido, asume que el servidor es de tipo WebDAV, y hace más peticiones que hacen más difícil encontrar el problema. Actualización 14/03/2010: puede que en dentro de poco se deje de pedir contraseña para el GET.

¿Cómo corregir esto? Pues haciendo que el manejador de Redmine distinga las peticiones “de sólo lectura” del resto no por método HTTP, sino por dirección, tal y como viene en la página man del CGI (segundo ejemplo de configuración de Apache). Podría haber desarrollado un nuevo manejador de autenticación, pero duplicaría todo el código salvo en un par de sitios. He preferido añadir una nueva directiva que activa este comportamiento, que por omisión está deshabilitado: RedmineGitSmartHttp. Para usarla, pondríamos esta línea dentro del anterior <Location /git>:

RedmineGitSmartHttp yes

y ya todo debería ir sin problemas. Esto no afectará a los bloques <Location /svn> que tengamos en otra parte: se usan instancias distintas del manejador de autenticación, y esas instancias no tendrán esta opción activada, por lo que mantendrán el antiguo comportamiento. Bueno, por lo menos así me ha funcionado en mi servidor de pruebas y así lo indican sus registros . He probado con proyectos públicos y no públicos en SVN y Git en el mismo Redmine y ha ido bien.

Para aquellos interesados en el código, he enviado un parche al proyecto Redmine, para que lo fusilen revisen más y mejores ojos que los míos. A ver qué tal lo reciben. Para aplicarlo, hay que descomprimir las fuentes de Redmine, poner el parche en su directorio principal, y ejecutar esto:

patch -p1 < 0001-Redmine.pm-add-Git-smart-HTTP-support.patch

Un último detalle: Git necesitará nuestro usuario y contraseña para autenticarse. Una opción es clonar con http://usuario@host/git/repositorio, poniendo el usuario en la URL y metiendo la contraseña cada vez que haga falta, pero es muy incómodo: por desgracia, no guarda las contraseñas automáticamente como hace SVN. Otra opción es crear un fichero ~/.netrc (¡sólo legible por nuestro usuario!) con nuestro usuario y contraseña:

machine mihost
login miusuario
password mipassword

No me termina de gustar eso de tener mi contraseña guardada en la máquina, pero bueno, ya pasaba con SVN, así que supongo que es el precio a pagar por no tirar de SSH :-/.

El primer paso es instalar los paquetes necesarios. Olvidaos de “Sistema → Administración → Soporte de idiomas”: eso instala SCIM, que es más engorroso de configurar (los acentos no funcionan directamente) y tiene menos cosas que uim. IBus tampoco sirve si queréis seguir metiendo acentos de la forma normal. Ejecutad estas órdenes en su lugar:

sudo aptitude install uim uim-anthy uim-el
sudo im-switch -s uim-toolbar

Salimos y entramos de nuestra sesión, y ya podemos introducir texto en japonés, pulsando Ctrl+Espacio para activar el IME. Tendremos que retocar un poco en las preferencias de uim, añadiendo el método de entrada de Anthy y ajustando los accesos de teclado a nuestro gusto. Una vez hayamos hecho eso, para introducir texto en japonés, tendremos de cambiar al modo de Anthy y al método de entrad en hiragana, escribir lo que queramos y pulsar espacio. Se nos mostrarán diversos candidatos: seleccionamos el que sea con las flechas del teclado y pulsamos Intro. Hay muchas otras teclas que podríamos usar: F6 para cambiar todo a hiragana y F7 para cambiar todo a katakana. Podemos activar entrada predictiva y todo.

Con eso están listas las aplicaciones GTK+ y Qt. Ahora sólo nos queda el señorito Emacs . En algunos sitios se recomienda añadir Emacs*useXIM: false a un fichero .Xresources bajo nuestro directorio personal, pero no me sirvió de nada (ni siquiera ejecutando xrdb -merge ~/.Xresources). En otros sitios se recomienda cargar el Elisp “iso-transl”, pero eso sólo arregla los acentos, y no la tecla Componer. Al final, lo que sí me funcionó es ejecutar Emacs dándole el valor “@im=none” a la variable de entorno XMODIFIERS. Lo he ido haciendo desde siempre con un alias en mi “~/.bashrc”, pero entonces sólo podía ejecutar Emacs desde una terminal, y no desde el menú de GNOME o con Alt+F2.

Si de verdad de la buena queremos hacer ese cambio y que se vea desde todas partes, podemos aprovecharnos del hecho de que emacs y emacs-snapshot son enlaces simbólicos a las alternativas seleccionadas con update-alternatives. Podemos ver las alternativas escogidas mediante:

update-alternatives --get-selections | grep emacs

Instalar una nueva alternativa no es tan complicado como parece. Crearemos un fichero “/usr/local/bin/emacs-snapshot-gtk-noim” con los contenidos necesarios, y le daremos permisos de ejecución:

sudo tee /usr/local/bin/emacs-snapshot-gtk-noim <<EOF
#!/bin/sh

env XMODIFIERS=@im=none /usr/bin/emacs-snapshot-gtk \$@
EOF
sudo chmod +x /usr/local/bin/emacs-snapshot-gtk-noim

Ahora debemos instalar este guión como una alternativa a emacs-snapshot y activarla, introduciendo el número correspondiente:

sudo update-alternatives --install /usr/bin/emacs-snapshot \
  emacs-snapshot /usr/local/bin/emacs-snapshot-gtk-noxim 0
sudo update-alternatives --config emacs-snapshot

Como /usr/bin/emacs usa emacs-snapshot, y emacs-snapshot usa nuestro guión, podremos utilizar ambas órdenes sin más desde cualquier terminal o con ALT+F2. El único aguafiestas es la entrada “Emacs Snapshot (GTK)” del menú de GNOME, que tiene una ruta directa a emacs-snapshot-gtk. Podemos editarlo bajo “Sistema → Preferencias → Menú principal” manualmente sólo para nuestro usuario, o cambiarlo para todos los usuarios con:

sudo sed -i 's/emacs\-snapshot\-gtk/emacs\-snapshot/' \
  /usr/share/applications/emacs-snapshot.desktop
update-menus

Con esto ya podemos usar de nuevo los acentos y la tecla Componer bajo Emacs, pero aún no hemos arreglado lo del japonés. Emacs, como buen sistema operativoeditor que se precie, trae sus propios métodos de entrada. Integraremos uim entre ellos y lo seleccionaremos como método por omisión, añadiendo estas líneas al final del fichero .emacs que se encuentra en el directorio personal:

;; save all files as UTF-8 by default
(setq default-buffer-file-coding-system 'utf-8)

;; read uim.el with LEIM initializing
(require 'uim-leim)

;; set default IM (ex. use Anthy)
(setq default-input-method "japanese-anthy-uim")

Ahora, una vez abramos Emacs, podremos introducir acentos de nuevo sin más, y con Ctrl+\ activaremos uim usando Anthy, que nos permite introducir japonés
directamente. Olvidaos de la barra de herramientas que usáis en las aplicaciones GTK+/Qt: no hará nada en Emacs.

Bueno, volviendo a la tecla Componer que comenté anteriormente. Con esta tecla se pueden escribir caracteres “raros” y cadenas completas (véase esta página) mucho más fácilmente. Por ejemplo, § (el símbolo de sección) es pulsar y soltar la tecla Componer, pulsar y soltar “s” y pulsar y soltar “o” (Componer+s+o), y ≠ es Componer+=+/. Recomiendo seguir el enlace anterior: se pueden hacer cosas muy curiosas personalizando el fichero “~/.XCompose” debidamente, como introducir ☺ mediante Componer+:+).

La tecla Componer no está disponible por omisión, así que tendremos que asignarla a alguna tecla que no usemos. Para ello tenemos un método fácil en Ubuntu: en “Sistema → Preferencias → Teclado → Distribuciones”, seleccionamos la distribución que estamos usando y pulsamos “Opciones de distribución”. Bajo “Posición de la tecla Componer” podemos marcar, por ejemplo, “Windows izquierda”. Cerramos todo y ya podemos Componer todo lo que queramos con esa tecla.

De hecho, una vez implementado (un algoritmo recursivo descendente LL(1)), me sorprende lo flexible que es Lisp en algunos aspectos. Ya conocía la existencia de las macros de Lisp y en su momento las usé para crearme un pequeño marco de trabajo para definir reglas de un chatbot, en CLIPS, pero no sabía que había algo parecido a nivel léxico. También se conocen como macros, pero se tratan de caracteres especiales que invocan determinadas funciones, generando las estructuras apropiadas. Si uno ve el algoritmo base (sin macros), es curioso ver que sólo podríamos leer átomos (símbolos y números), aunque aún así, se pueden leer números enteros, flotantes, y racionales (fracciones exactas, como 22/9, sin pasar a coma flotante). Los famosos “(” y “)” que producen listas son, de hecho, macros, y también “;” (produce comentarios), “`” y “,” y demás. De todas formas, como el repertorio de carácteres disponibles para macros parece estar ya prefijado por el estándar Common Lisp, se suelen usar las dispatching macros para añadir extensiones, que consisten en secuencias de caracteres de la forma #nX, donde n es un número entero y X es un carácter que identifica la función a invocar..

Por ejemplo, está #|, que sirve para crear los comentarios en bloque, #=, que sirve para construir estructuras de datos en Lisp con múltiples referencias al mismo elemento (incluso referencias cíclicas), #nA (para obtener matrices multidimensionales), #( (para vectores), etc. Hay incluso macros para definir números en bases arbitrarias (incluyendo fracciones: ¿alguien quiere escribir una fracción en base 7?).

Evidentemente, no lo he implementado todo en ACL2::Lisp::Parser. El algoritmo principal está, incluso con los detalles del tratamiento de mayúsculas (el símbolo hola se entiende como HOLA, pero hol\a es HOLa, por ejemplo), pero la lectura de números en bases distintas a la decimal y la mayoría de las macros de # (excepto #|, que es muy común) no está hecha. Dicho módulo trae read_lisp_program (lee programas), read_lisp_token (lee elementos individuales) y try_read_lisp_token (intenta leer e informa de la localización en que se produce el fallo de análisis, si hay uno). Podía haberlo escrito con Parse::RecDescent, pero como vi que al final no me produciría una gran ventaja frente a escribirlo manualmente con el libro de Lisp por delante, lo descarté, para evitar añadirme una dependencia más.

En base a este código, he reescrito todas las partes que dependían de ACL2::AnalisisLisp en alguna medida, incluyendo el código que limpiaba la salida de ACL2, deshaciendo el ajuste de líneas en los párrafos de texto, y no tocando los párrafos que constituían expresiones Lisp. Antes había una expresión regular un tanto críptica que funcionaba en la mayoría de los casos, pero ahora el código de limpieza sabe cuándo algo puede ser código Lisp o no. El resto del código ha sufrido cambios parecidos. El mayor cambio externo es que ahora se incluyen los comentarios originales del código Lisp en la salida XML y se reproduce exactamente el código original, en vez de una versión “limpiada”. Como de costumbre, el cambio al analizador Lisp y la jerarquía de nodos del árbol de sintaxis abstracto ha sido un cambio más interno que externo, pero de todos modos será útil para seguir adelante y añadir nuevas funcionalidades.

Las principales novedades que trae esta versión son básicamente:

• Organización de órdenes en categorías: muchas órdenes repetían el mismo código una y otra vez. Este era sobre todo el caso de las órdenes que no producen prácticamente ninguna salida específica, como DEFPKG, DEFABBREV o DEFMACRO. Ahora lo que se hace es agrupar estas órdenes en categorías, para que compartan el mismo código. Con eso podré añadir más rápidamente órdenes de ACL2 que no sean tan usadas. Las órdenes que necesitan código específico se siguen usando directamente (como DEFUN, DEFTHM o ENCAPSULATE). De hecho, el orden actual para una orden X cualquiera es:

1. Se intenta cargar el módulo ACL2::Orden::X, y analizar la orden mediante una instancia la clase contenida en dicho módulo.
2. Si no funciona, se prueban en un orden prefijado todas las categorías, y se usa la primera que funcione. Actualmente, hay dos: DefinitionCategory (para las órdenes DEFXXX que no necesitan código especial) y FallbackCategory. La segunda categoría lo acepta todo, e imprime la salida de ACL2 como una lista de párrafos y S-expresiones, junto con el resumen debidamente procesado, si lo tenía. Su utilidad es para no fallar estrepitosamente ante órdenes de ACL2 aún no implementadas o código Lisp arbitrario (ACL2 es un entorno Lisp, al fin y al cabo). De todas formas, ACL2::Procesador sigue dando fallos fatales cuando no entiende algo en la salida de una orden para la que tiene código específico (de lo contrario, las pruebas de regresión serían inútiles).

• Revisión del algoritmo de análisis de un fichero .lisp: ahora el grafo de dependencias es más sencillo, descartando los antiguos nodos que incluían a los ficheros .acl2 que servían para establecer el estado inicial de ACL2 antes de certificar un libro. Esto se debe a que ahora, cuando se procesa un fichero X.lisp y se encuentra un fichero X.acl2 o cert.acl2 en el mismo directorio, se usan los contenidos del primero de esos ficheros en vez del propio fichero X.lisp. Es ACL2 el que lee X.lisp y lo interpreta. De todas formas, ACL2 de hecho vuelve a volcar las fórmulas de X.lisp en la salida del evento CERTIFY-BOOK. Este nuevo esquema es más fiable de entrada, y además ahora le añadimos un prólogo y un epílogo a cada fichero .lisp procesado para asegurarnos de que funcione en más implementaciones de Lisp.

Esta versión ha sido probada con ACL2 2.9.4 bajo CLisp 2.44.1 (paquete Ubuntu 1:2.44.1-4ubuntu2), ACL2 3.0.1 bajo CMUCL (paquete Debian cmucl, versión 19a-release-20040728-9), ACL2 3.1 bajo CLisp, ACL2 3.2.1 bajo GCL (paquete Debian gcl 2.6.7-45), ACL2 3.3 bajo GCL, y ACL2 3.4 bajo GCL. Con eso tengo cubiertas varias implementaciones de Lisp y varias versiones de ACL2.

Para la siguiente versión, lo que quiero hacer es cambiar el “analizador” Lisp que tengo (me da vergüenza llamarlo así ) por uno que implemente el algoritmo de la función read, tal y como viene en el libro  de “Common Lisp, the Language”, particularmente en las secciones 22.1 y 22.2. Tenía hecho una gramática LALR(1) tentativa en Parse::Eyapp (muy buen módulo para los fans de bison/flex o ANTLR) en una de mis ramas, pero va a ser que no: la sintaxis es demasiado compleja como para hacerla fácilmente :-/. Por ejemplo, ahora mismo el código no tiene forma de saber si algún trozo de código Lisp es una lista, un átomo, una cadena, y no entiende de comentarios de bloque. Puestos a parchear el código que hay, prefiero hacer algo en condiciones, que además sea capaz de reconocer correctamente programas Lisp no válidos tal y como lo hace ACL2 (o casi). Seguramente revise un poco el algoritmo, ya que a diferencia del algoritmo original, me interesa poder recuperar el código fuente original al 100%.

También me dieron algunos quebraderos de cabeza los widgets: el del tiempo hizo que KDE se cerrara estrepitosamente, y el widget de monitorización del sistema no dejaba de salir por mucho que lo retirara.

Por último, Dragon Player no estaba del todo integrado con KDE, parece: en primer lugar, era incapaz de abrir vídeos que estuvieran bajo alguna carpeta de red. No me sorprende, pero si al final voy a trabajar como en GNOME, pues me quedo con GNOME, la verdad. Tuve otros problemas con las claves SSH y demás, pero éstos sí los pude resolver buscando un poco. Aun así, la verdad es que KDE 4 me está gustando mucho en términos de funcionalidad. Para KDE 4.4 o 4.5, creo que me cambiaré definitivamente .

MSYS es una implementación de un entorno POSIX minimalista sobre MinGW, un marco base que permite desarrollar programas para Windows sobre herramientas GNU. Es mucho más ligero que Cygwin, y los ejecutables generados no requieren del DLL usual de éste, que ocupa bastante.

La ventaja principal de msysGit es que en teoría consiste simplemente en seguir los pasos de un instalador. Sin embargo, no resulta tan fácil: no todo funciona directamente tras instalarlo. En particular, la terminal estilo bash que proporciona da bastantes problemas: acabé descartándola por la línea de órdenes usual de Windows XP (cmd). Sí, es horrible, pero por lo menos funciona.

Lo que realmente era vital para mí era “git add –interactive” (suelo ponerlo bajo el alias “git ai“): lo uso todo el tiempo, y me resulta realmente útil. git-gui será gráfico, pero es incomodísimo en comparación con él. Además, permite enviar al índice sólo parte de los cambios, dividir los cambios en partes más pequeñas, o incluso editar el cambio antes de pasarlo al índice. También uso mucho “git rebase –interactive” para limpiar mis commits, retirando los enfoques que he ido descartando y disimulando los errores que he cometido .

Para que ambos funcionaran debidamente, tuve que instalar la última versión de less del proyecto GnuWin32, y la última versión oficial de Vim para Windows. Después cambié los nombres de less.exe y vim.exe del subdirectorio bin dentro del de Git a otros que no interfirieran, y puse los directorios en que estaban los binarios del nuevo less y Vim en la variable de entorno PATH.

Con esto quedó todo bien. El único pero es que sólo funciona si uso cmd, pero espero que los de msysGit afinen un poco más el asunto en futuras versiones.

Como me daba mucha pereza tener que hacerlo a mano, busqué un poco y encontré una web que aparentemente hacía justo lo que quería: transformaba este feed RDF oficial con las últimas y primeras versiones oficiales. Sin embargo, parece que sólo lo hacía cada cierto tiempo, y por ello algunas entradas se encontraban desactualizadas. Vaya hombre. Y además el código que utilizaba no estaba en ningún sitio, así que no podía repetir la transformación por mi cuenta.

Pero bueno, nada que wget y una hoja XSLT sencillita no arreglen. Me he hecho un sencillo guión Bash que descarga con wget la última versión del feed RDF (sólo si la copia local se encuentra desactualizada) y genera un .bib mediante una transformación con xsltproc. Nada muy complicado, pero bueno, me resuelve el problema perfectamente. El código fuente está en su repositorio Git bajo mi cuenta de Gitorious.

Ah, y por cierto: si os vale con una cita en formato XHTML, los del proyecto de automatización de publicaciones del W3C ya lo tienen hecho en condiciones.

Así que decidí cambiar de router, y puestos a ello, preferí cambiar a uno con cuyo firmware pudiera trastear: el Cisco-Linksys WRT54GL. Sé que hay otros routers ya que permiten utilizar firmware de terceras partes, pero éste tenía muy buenas críticas en general, y al fin y al cabo tiene a Cisco por detrás. Nadie fue despedido por comprar de IBM, dicen .

El único “pero” es que el WRT54GL es un router neutro, con lo que necesitaría un módem ADSL con salida Ethernet, cosa de que no dispongo, y que parece más difícil de encontrar de lo que pensaba (por lo menos uno de calidad). Como no quería depender del USR9105, por si acaso, aproveché un SMC Barricade 7904WBRA2 que me enviaron los de Ya.com hace unas cuantas semanas.

La idea general es que el SMC hace sólo de módem y primer firewall (tiene desactivado todos los demás servicios, incluido la parte inalámbrica), utilizando una configuración de “falso monopuesto” por así decirlo: la IP fija del router Linksys es el único host en la DMZ, con lo que recibe todas las conexiones entrantes. Con un latiguillo del WAN del Linksys al switch del SMC y un poco de configuración todo quedó muy bien. El Linksys actúa como segundo firewall y es el que atiende a todas las máquinas de mi LAN.

Por supuesto, el firmware que traía el Linksys no estaba mal, pero no era del todo de mi agrado: de hecho, me gustaba más el de mi USR9105. Así que busqué un poco y encontré varias opciones: DD-WRT, Tomato, y un largo etcétera. De todas ellas miré un poco por encima y Tomato fue la que más me gustó de lejos:

1. La documentación es muy buena: DD-WRT es el único que podría superarla.
2. La interfaz de usuario es fantástica, y supera con creces todo lo que he conocido.
3. Es más ligero que DD-WRT, pero tampoco anda corto en absoluto: además de todo lo que suele traer un router, incorpora muchas funcionalidades de monitorización y el QoS más fácil de configurar que he visto hasta ahora.
4. Está basado en el código original de Linksys (se hallaba bajo la GPL), con lo que sé que partieron de algo sólido.
5. Tiene un tomatito muy simpático .

Por ejemplo, nada más instalarlo (aplauso para los de Linksys que sólo tuve que subir un fichero por la interfaz web y punto), pude darme cuenta del origen del problema en última instancia: mldonkey deja muchas conexiones olvidadas a medias, que no contabiliza para el límite de conexiones. Con la información de monitorización de Tomato y algo de prueba y error tengo controlado ese problema, y lo mejor es que de todas formas, si alguna vez se sale de madre, puedo cortar todas las conexiones inactivas con un simple clic.

Otro detalle más: la recepción de Wi-Fi en mi portátil era del 60-65% con el USR, y del 74% inicialmente con el Linksys. Tomato me dejó aumentar la potencia de la señal y ahora tengo un 80%, que no es moco de pavo . Además, permite configurar de forma muy sencilla dnsmasq, que actúa como caché DNS y servidor DHCP: en un momento pude darle a mi servidor Debian una IP estática asignada por MAC y un nombre de host de acuerdo a su DNS dinámica. Ya tenía algo así en mi servidor Debian, pero esto queda mucho mejor (muerte a las IP estáticas ).

En resumen: si el WRT54GL ya es buen hardware de por sí, Tomato lo hace aún mejor, y todo por el módico precio de 70€ (gastos de envío incluidos). Aún tengo que comprobar si aguanta una semana con esta carga de trabajo sin colgarse, pero por lo pronto me está causando muy buenas impresiones. Y sí, mi configuración de red es un poco rara: también tengo un puente de red (nivel 2 OSI) entre el servidor Debian y mi portátil, pero eso ya lo dejo para otro día .