Robots y modelos

Notas sobre pruebas, modelado y aventuras en Java y Android

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 ,

“git add –interactive” en msysGit (Git bajo MinGW en Windows)

leave a comment »

Recientemente tuve que trabajar con Git en Windows. Parece que la versión “oficial” por así decirlo es la compilada por Cygwin, pero no vi ningún binario por ahí para descargar. Instalarme Cygwin en la máquina virtual era demasiado, así que opté por msysGit, una versión de Git ejecutándose bajo MSYS.

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

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.

Written by bluezio

24 de enero de 2009 at 19:56

Publicado en Uncategorized

Tagged with , ,

Generador de citas en formato BibTeX de estándares del W3C

leave a comment »

Ahora mismo estoy escribiendo un artículo sobre XMLEye para intentar enviarlo al ACL2 Workshop 2009, y tuve que escribir a mano varias veces las entradas BibTeX para más de una tecnología del W3C que estaba utilizando. Las usuales, vamos: XML, XHTML, XPath, XSLT, etc. Los de la Collection of Computer Science Bibliographies (estilo DBLP) tienen un listado, pero no tienen un estilo uniforme.

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.

Written by bluezio

10 de enero de 2009 at 19:19

Publicado en Uncategorized