Robots y modelos

Notas sobre pruebas, modelado y aventuras en Java y Android

Posts Tagged ‘debian

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

Mejorando la distribución de los guiones Perl

leave a comment »

Estos días he estado curioseando sobre la forma de facilitar un poco la distribución de los conversores ACL2->XML y YAML->XML. Es cierto que ACL2::Procesador está mucho mejor que antes del Concurso, ya que al cambiar a una estructura basada en los módulos de CPAN, con un instalador creado mediante Module::Install, ahora se instalan todas las dependencias automáticamente al seguir estos pasos:

perl Makefile.PL
sudo make
make test
sudo make install

Esto le resultará muy familiar a cualquiera que haya compilado e instalado un proyecto de las autotools, pero hay un problema: CPAN no es a prueba de bomba, y el “sudo make” instalará no sólo los paquetes necesarios para ejecutar ACL2::Procesador, sino también los que hacen falta para compilar y depurar el módulo. Además, dos de estas dependencias de compilación son módulos XS, con lo que necesitan un compilador C, además de las bibliotecas y cabeceras que utilizan: libxml2 y libexpat. Para un desarrollador tampoco es gran cosa, pero pedir esto a un usuario medio… pues como que no es muy realista.

Con los paquetes Debian se facilita mucho la cosa, claro, pero ¿y si no estamos bajo una distribución basada en Debian, como openSUSE? ¿O si estamos en Windows? Algún usuario potencial en Windows habrá: al fin y al cabo, estoy usando Perl y Java, que por ir tendrían que ir como mínimo en Mac OS X también. No es cosa de cerrarme en banda, tampoco.

No tengo tiempo de hacer paquetes para todo lo habido y por haber, eso está claro. Pero simplificar se puede simplificar. Module::Install tiene dos módulos llamados Module::Install::Bundle y Module::Install::Include que supuestamente permiten incluir en las distribuciones de código las dependencias, pero no me funcionan en absoluto, la verdad.

Donde sí he tenido una grata sorpresa es con los módulos PAR y PAR::Packer. Cualquiera que haya utilizado Java y visto el acrónimo tendrá una idea (JAR = Java ARchive, PAR = Perl ARchive), me imagino. PAR permite crear ficheros .par que agrupan todos los módulos no estándar y bibliotecas necesarias para que nuestro program Perl funcione. Tras instalar PAR y PAR::Packer, ejecutaremos esta orden para crear el .par:

pp -p -o acl2-proc.par script/pprocACL2

Y ejecutarlo sólo requiere el módulo PAR (que es relativamente ligero, y en las Debian se halla disponible como libpar-perl) y Perl:

perl -MPAR acl2-proc.par (fichero Lisp raíz de la demostración)

Más fácil todavía: si no ponemos el -p, se crea no un .par, sino un ejecutable completamente autocontenido, que puede distribuirse sin necesidad de que el usuario instale nada previamente. El único problema es evidentemente el tamaño del ejecutable: pasamos de un .par de 75KB a un fichero de ~2.7MB. Esto es más interesante para la gente de Windows, sobre todo.

Obviamente, los .par son específicos de la plataforma en cuanto usemos un solo módulo que no sea Perl puro. Para ACL2::Procesador no es un problema, pero YAXML::Reverse sí que usa la biblioteca libyaml. Se pueden crear .par multiplataforma, acumulando los resultados de cada plataforma sobre el mismo .par, así:

pp -m -o yaxml.par script/yaml2xml

La verdad es que distribuir un fichero .par y poder olvidarte de CPAN es una alegría, qué más decir. Incluso existe la posibilidad de distribuir un único guión Perl y hacer que se “traiga” e instale el PAR de un repositorio bajo una URL, con el módulo PAR::Repository::Client, pero este módulo es bastante pesado: quizás sea conveniente para redistribuir código entre muchas máquinas que manejemos, pero no tanto para instalarlo en una máquina del usuario.

Mi idea es reunir en varios .tar.bz2 versiones de los conversores que puedan descomprimirse directamente sobre el directorio donde tengamos XMLEye, y que incluyan los .par o ejecutables monolíticos, los descriptores de formato y las hojas de estilo. Así resultará mucho más cómodo que como está ahora.

Written by bluezio

22 de junio de 2008 at 10:38

Publicado en Desarrollo

Tagged with , , , , , , ,

DokuWiki al poder

leave a comment »

Bueno, ya me he montado un DokuWiki en mi propio dominio, sobre el que intentaré ir dejando la suficiente documentación y manuales en inglés y/o español (según el tiempo que tenga) antes de empezar a rondar por listas de correo y tratar de picar el gusanillo de alguien, aunque sólo sea como usuarios.

Me gusta bastante por lo pronto: es muy sencillito pero muy flexible a la vez. Me ha dado algunos quebraderos de cabeza la instalación con el safe_mode de PHP y un bug de DokuWiki (¿alguien sabe para qué es esa función fullpath en PHP? ¿Existe, o sólo está realpath?), pero al final creo que ha quedado bastante bien.

El wiki está aquí: http://wiki.shoyusauce.org, por cierto. Ya lo iré rellenando durante estos días.

En fin, además de esto tengo aún pendiente terminar de traducir el código a inglés y buscarme un sponsor para mis paquetes, que habrá que pasar de Ubuntu a Debian. Hay trabajo de sobra para este verano :-D.

Written by bluezio

1 de junio de 2008 at 0:22

Publicado en Desarrollo

Tagged with , ,

Materiales de un taller Debian

leave a comment »

Esta semana y media he dedicado un par de ratos a mejorar y revisar los materiales que usé en un taller reciente sobre elaboración de paquetes Debian. Aquí están todos los talleres que hicimos entre algunos alumnos y profesores en la ESI de Cádiz:

http://www.uca.es/softwarelibre/talleres/index_html

Ya he enviado la última versión al responsable, que la pondrá dentro de un par de días. Fue un taller con bastantes imprevistos, pero ya está todo a prueba de bala… bueno, de flecha, tampoco tengo tanta confianza :-D.

Con lo que hay ahí creo que daría para 2 sesiones de 1:30 a toda pastilla o 2 horas más cómodamente, una con la elaboración básica y otra con cómo hacerte tu propio repositorio para facilitar la distribución. Está probado sobre Gutsy y Hardy, ya que en Hardy sudo tiene una nueva opción (-E) que me dió algunos quebraderos de cabeza.

Están las fuentes de la presentación (LaTeX usando Beamer, bajo la GPL), código fuente para los paquetes y demás, la configuración necesaria para Lighttpd y un guión que instala las dependencias básicas, instalando paquetes, ficheros de configuración, y preparando un fichero de entrada para generar claves GPG en modo batch.

Se acepta cualquier comentario y crítica constructiva :-).

Ah, y de paso: he sacado una nueva versión del paquete Debian de ACL2::Procesador en mi repositorio, que no incluía build-essential entre sus dependencias. Cuando ACL2 certifica un libro externo, de hecho compila un programa C, cosa de la que no me acordaba. Los empaquetadores de ACL2 sin embargo no lo habían incluido entre sus dependencias. En fin, ya está arreglado.

A ver si preparo algunos screencasts de la aplicación y los pongo por aquí, que me falta contenido multimedia :-D.

Written by bluezio

13 de abril de 2008 at 18:16

Publicado en Desarrollo

Tagged with , ,

Paquetes Debian, repositorio Debian, manual de paquetes Debian

leave a comment »

Mucho Debian veo ahí en el título. 😀

Tras una semana de prueba y error y de limpiar bugs a mansalva, he conseguido una versión mucho más estable de pprocACL2 y XMLEye, y lo que es más importante, he creado un repositorio Debian con todos los paquetes necesarios. Además, tengo la grata sorpresa de que mi programa compila y funciona sin más problemas en IcedTea: el único “pero” es que la salida HTML no se muestra del todo bien, pero son detalles sin importancia realmente. Por fin he podido quitar sun-java6-jdk de Build-Depends. He tenido que poner en Depends del paquete IcedTea (con preferencia) y el JRE de Sun (por si el usuario ya lo tiene, ya que java2-runtime por defecto en Gutsy es GCJ, en el que no funciona bien Swing, y sólo SWT.

De paso, he aprovechado lo que he ido aprendiendo todo este tiempo para hacer una pequeña guía (bueno, el PDF tiene ~60 páginas) de cómo crear un paquete Debian, siguiendo una serie de buenas prácticas. No intento competir con otras guías fantásticas que hay por ahí (hay algunas referencias en mi propia guía a ellas), pero vi que no había gran cosa en español, y que no se hablaba bien de ciertas opciones como crear nuestro propio repositorio con reprepro, sincronizarlo con lftp, o usar cowdancer para agilizar el proceso de construcción pbuilder, entre otras cosas. El manual está bajo la GNU FDL y su código fuente está en el repositorio.

Tuve que hacerme mis propias hojas XSLT para convertir DocBook a LaTeX, ya que las que había dejaban mucho que desear (creo que el autor no comprendía bien que LaTeX  es quien debe ocuparse de la presentación, y no él). Están en el subdirectorio manualDebian/hojasXSL, y hay dos: una para generar ficheros LaTeX, y otra para los BibTeX (la salida se ha de volcar a un fichero llamado bibliografia.bib).

Ahora empezaré a trabajar en la documentación del programa. También podría trabajar un poco en las traducciones y en hacer que se integre bien en Windows.

Para instalar los paquetes, hay que añadir estas líneas a /etc/apt/sources.list (también se puede usar Orígenes de software bajo el menú Sistema, y entrar en la pestaña Software de terceros):

deb http://www.shoyusauce.org/packages/ubuntu gutsy main
deb-src http://www.shoyusauce.org/packages/ubuntu gutsy main

Hay que descargarse la clave GPG con la que he firmado mis paquetes, y añadirla al anillo de claves de confianza de apt:

wget http://www.shoyusauce.org/packages/claveDebian.asc
sudo apt-key add claveDebian.asc

Ahora ya podemos actualizar e instalar XMLEye y pprocACL2:

sudo aptitude install xmleye pprocACL2

De por sí no tienen tantas dependencias, pero a la hora de desarrollar he tenido que empaquetar algunos módulos con muchas subdependencias como PAR::Packer. Por supuesto, no hay que instalar ambos: son completamente independientes. XMLEye puede usarse simplemente como un visor XML.

He subido también un tar.bz2 con el código fuente de pprocACL2 y XMLEye. En el código fuente de pprocACL2 hay una serie de ficheros .lisp de ejemplo bajo t/testInputs, que están muy probados. Provienen de los tutoriales disponibles de ACL2. El ejemplo hanoi-use.lisp es el más interesante, ya que incluye enlaces entre una demostración y el libro cuyos teoremas y funciones usa.

Written by bluezio

4 de marzo de 2008 at 10:52

Publicado en Uncategorized

Tagged with , , , , , , , ,

Primera versión subida al repositorio

leave a comment »

Bueno, ¡por fin!

Tras varios meses de pulido, mezclados con exámenes de la universidad, el examen de japonés, trabajos y otras cosas, he podido subir una versión “potable” al repositorio.

Mi enfoque en este concurso ha sido el de, además de ampliar las capacidades de mi PFC, convertirlo en un producto software completo, bien documentado y probado. Durante este tiempo he tenido que reescribir buena parte del visor para implementar una interfaz TDI (Tabbed Document Interface), ya que en el momento de presentar el PFC sólo manejaba un documento a la vez.

Esto no sirve cuando tenemos documentos que enlazan a otros documentos y queremos verlos todos de una vez, como en el caso de las demostraciones de ACL2 que usan libros (es decir, colecciones de teoremas y funciones ya demostrados). A partir de ahora se puede pulsar en un enlace que nos lleve a otro documento sin más problemas, siguiendo un esquema particular de direcciones URL.

He aprovechado el componente InfoNode Tabbed Pane, que se halla bajo la GPL para uso no comercial, y he cambiado un poco los patrones de diseño detrás de la interfaz. Antes intenté un esquema MVC, pero no funcionó del todo, y se quedó en el MVC “mutilado” de Swing, en el que se integra la vista y el controlador. Extendido a la ventana principal, esto era un galimatías.

Así que probé a cambiar un poco el enfoque, usando “modelos de presentación” además de los modelos normales. Estos modelos factorizan propiedades útiles para varias vistas a la vez, e inútiles para el modelo, dejando a la vista mucho más sencilla. De esa forma podré en el futuro definir casos de prueba para aspectos relacionados con la presentación del documento, sin tener que comunicarme con los propios controles Swing.

Otras mejoras incluyen la posibilidad de que un usuario sin permisos de administrador edite los tipos definidos por el usuario (que siguen la filosofía de los ficheros de menú FreeDesktop.org) para personalizar las órdenes relacionadas con el post-procesador desde el tipo no XML original. Realmente el fichero original no se sobreescribe, sino que se escribe uno nuevo bajo el $HOME del usuario que toma prioridad sobre él.

Además, la actualización del documento es realmente “automática”: antes me limitaba a ejecutar de nuevo el post-procesador y reabrir el fichero cuando el usuario cerraba el editor. Ahora se usa un hilo en segundo plano que monitoriza el fichero en busca de cambios. Para ACL2, eso permitiría tener Emacs por un lado y el visor por otro, editando y grabando en un lado y viendo los cambios en el otro.

Esto ha hecho ya que el visor deje de ser “el visor para ppACL2” y pase a ser “el visor XMLEye” propiamente dicho. De hecho, pienso definir algún que otro formato adicional en estas semanas para demostrar su flexibilidad.

Por el lado del post-procesador, he seguido exactamente el mismo enfoque: hasta el momento era una colección “informe”, por así decirlo, de módulos y scripts Perl. He refactorizado el código siguiendo las recomendaciones para módulos del CPAN, estructurándolo con casos de prueba en base al módulo Test::More. Un desarrollador puede instalarse el módulo Module::Install y generar fácilmente tarballs de distribucióncon “make dist” desde la versión de Subversion. Estos tarballs son autocontenidos y se descargarán las dependencias del post-procesador cuando el usuario ejecute el script de instalación.

En el apartado de funcionalidad, el post-procesador es capaz ahora de seguir el grafo de dependencias a partir del fichero principal de una demostración y de enlazar todos los libros y demás usados, para que después en el visor se pueda saltar entre ellos.

A nivel general, el propio post-procesador se ha vuelto más “inteligente”: antes el visor tenía que lanzar él mismo ACL2 y luego ejecutar el post-procesador sobre el fichero principal. Para evitar que el visor tuviera que conocer el detalle de cómo se enlazan entre sí las demostraciones, ahora el post-procesador dirige el proceso completo a partir del fichero .lisp que abramos, e incluso evita tener que volver a analizar un mismo fichero varias veces, al estilo de la herramienta GNU Make.

Esto me deja así con un post-procesador mucho más funcional y un visor realmente genérico, por lo que en las últimas semanas he comenzado a pensar en las bestias negras de todo programador :-D: el manual y los paquetes Debian / instaladores para Windows. Por el lado de los paquetes Debian lo tengo casi listo (queda pulirlo un poco y subirlo al SVN), pero el manual voy a tener que empezarlo ahora.

Tomaré el manual sencillo del PFC como base, pero lo reescribiré usando DocBook y añadiré un tutorial en cómo definirse uno mismo un nuevo tipo de documento.

En fin, esto es todo por hoy :-D, que ya me vale. Lo siguiente: paquetes Debian para Gutsy.

Written by bluezio

25 de febrero de 2008 at 19:04

Publicado en Desarrollo

Tagged with , , , , ,