Robots y modelos

Notas sobre pruebas, modelado y aventuras en Java y Android

Reutilizar un móvil Android como webcam con DroidCamX e IP Webcam

with 5 comments

A raíz de este artículo de El Androide Libre, me puse a probar DroidCamX e IP Webcam para convertir mi Nexus S (corriendo una ROM basada en Gingerbread 2.3.4) en una webcam HD, posiblemente con micrófono incorporada. He tenido éxito con IP Webcam y he conseguido que funcione tanto en Windows 7 como en Ubuntu Natty, pero me ha llevado su buen rato. Dejo aquí los apuntes para que Google pueda encontrarlos :-D.

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 :-D.

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 :-D. 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 :-D. 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 :-D.

Anuncios

Written by bluezio

8 de julio de 2011 at 8:30

Eclipse Commiter en Epsilon

leave a comment »

Me alegra decir que acabo de entrar como Committer en el proyecto Epsilon de Eclipse GMT. La verdad es que llevaba desde verano del 2009 contribuyendo pequeños cambios para cubrir fallos que me encontraba y necesidades que tenía.

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 :-D. 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.

Written by bluezio

18 de abril de 2011 at 15:09

Publicado en Desarrollo

Tagged with , , , ,

Smart HTTP de Git y Redmine

with 5 comments

Actualmente estoy preparando la actualización de un servidor Redmine que gestiono. Es una actualización bastante grande: no es sólo cuestión de actualizar la instancia Redmine, sino todo el sistema y herramientas de apoyo. Lleva demasiado tiempo sin tocarse y tiene una distribución antigüilla.

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 :-D. 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 :-/.

Written by bluezio

24 de febrero de 2010 at 9:50

Publicado en Desarrollo

Tagged with , , , ,

Entrada de acentos y japonés en Emacs/GTK+/Qt en Ubuntu 9.10 (Karmic Koala)

with one comment

He estado las últimas horas peleándome para que la entrada de japonés, el español y la tecla Componer convivieran pacíficamente en mi Ubuntu 9.10, y por fin lo he dejado como me gusta, así que lo dejo por aquí antes de que se me olvide :-D.

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 :-D. 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.

Written by bluezio

13 de diciembre de 2009 at 17:00

ACL2::Procesador: nueva versión 1.187

leave a comment »

Estos últimos días he estado dándole fuerte al teclado y he escrito el nuevo analizador Lisp, basado en el algoritmo del libro “Common Lisp: the Language”, tras descartar dos ramas con un analizador basado en Parse::Eyapp que producía árboles de referencias a listas Perl, y otro que producía árboles AST. Por supuesto, hay algunos cambios y simplificaciones, dado que no intento tener un entorno de ejecución de Lisp, sino simplemente de análisis del código. Por ejemplo, se preserva el espacio en blanco, y los comentarios de líneas (“; hola”) y de bloque (#| hola |#), aunque se pueden limpiar fácilmente. Es curioso saber que los comentarios de bloque en Lisp, a diferencia de los de C++, sí que se anidan.

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.

Written by bluezio

12 de abril de 2009 at 20:42

Publicado en Uncategorized

Versión 1.186 de ACL2::Procesador

leave a comment »

Acabo de marcar en SVN y subir a la forja de Rediris la versión 1.186 de ACL2::Procesador. Aceptaron el artículo que enviamos mis antiguos directores de PFC y yo a ACL2 2009, así que es hora de darle un lavado de cara en algunos aspectos, aprovechando que estoy en vacaciones de Semana Santa :-D.

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í :-D) 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%.

Written by bluezio

7 de abril de 2009 at 16:53

Publicado en Uncategorized

KDE 4.2: nada, aún no

leave a comment »

KDE 4.2 es supuestamente la primera versión de la serie KDE 4 que sí está dirigida al usuario final, tras una KDE 4.0 sólo para aventureros y una KDE 4.1 para “early adopters”. O eso dicen: yo no estoy tan seguro. Está claro que hay muchísimas ideas buenas detrás, y va a ser un gustazo cuando todo haya quedado fino, pero ahora mismo hay demasiados bugs aquí y allá. Por ejemplo, no conseguí de ninguna de las formas configurar mi pantalla dual, que fue tremendamente fácil en GNOME. Ni tirando de xrandr, ni con KRandRTray, ni poniendo manualmente la entrada Virtual en el xorg.conf, nada de nada.

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 :-D.

Written by bluezio

7 de febrero de 2009 at 22:21

Publicado en Uncategorized

Tagged with ,