Archivos para Septiembre, 2008

Experiencias con Canon LiDE 25

26 Septiembre, 2008 a 15:43 · Archivado en Uncategorized

El otro día tuve que comprarme un escáner (cosas de la vida hoy en día y su insana afición a los papelajos), y estuve buscando modelos y modelos. De entre los que tenía mi tienda de confianza, estuve mirando y curiosamente el más barato (un Canon LiDE 25) es el que salió mejor parado con un soporte “bueno” (que no completo) por la gente de la base de datos de SANE.

Dicho y hecho, en cuanto llegué a casa sólo tuve que conectarlo por el cable USB y SANE lo reconoció sin más problemas. Acostumbrado a los problemas de mi antiguo (y tanto) Primax Colorado 1200p, la verdad es que fue una maravilla. Ya quisieran los de Windows tener una experiencia de instalación como esta: ni CD de instalación ni chorradas. Por supuesto, no gracias a Canon: resulta que este escáner utiliza el chipset Plustek, revendido por la compañía del mismo nombre a otras compañías, como Epson o HP.

Pero claro, me resultaba algo molesto tener que tirar de SANE o abrir el Gimp manualmente cada vez que quisiera usarlo, si tenía esos tres botoncitos de una sola pulsación. No me esperaba gran cosa, pero recibí una grata sorpresa cuando me enteré de que precisamente hay un proyecto para este tipo de cosas: scanbuttond es un demonio que se queda en segundo plano y pregunta varias veces por segundo mediante libusb por el estado de esos botones, y ejecuta un shell script cuando detecta una pulsación, pasándole el nombre del dispositivo y el número del botón.

En mi Ubuntu Hardy 8.04.1 tuve que instalar los paquetes scanbuttond, tiff2ps y netpbm y seguir las instrucciones (adaptando los guiones un poco) presentados en este howto de la gentuza de Gentoo, ¡y listo! Más o menos esto fueron los cambios que hice:

  • Quité de sbd-print.sh las opciones de scanimage específicas al escáner HP que tenía el autor del howto. Para ello, lo mejor es conseguir el nombre del dispositivo de nuestro escáner con “scanimage –list-devices”, y luego mirar con “scanimage –help -d <dispositivo>”.
  • Cambié el cliente de correo en sbd-mail.sh de Thunderbird a GNOME Evolution. Basta con esto: “sudo -u <usuario> evolution “mailto:foo@bar?attach=${TMPFILE}.jpeg”
  • Añadí la opción “-a” a la invocación de GIMP, con lo que la imagen escaneada se abre en una ventana nueva en vez de abrir otra instancia completa de GIMP. También fue útil añadir “&” al final para que se ejecutara en segundo plano (o si no, no podría escanear otra imagen hasta que cerrara esa instancia de GIMP).

Con eso ya bastaría, pero tendríamos que ejecutar nosotros scanbuttond en nuestra sesión de usuario. Lo cual tampoco está mal, pero prefiero que ese tipo de cosas queden como servicios y estén disponibles aunque no haya X. Así que me hice un guión chapucerillo de /etc/init.d a partir del de winbind (start es “scanbuttond” y stop es “killall scanbuttond”, en fin…), y pensaba que con eso estaría listo, pero no: resulta que, claro, de esa forma se intenta ejecutar Evolution y GIMP desde root, y root no tiene permiso para conectarse a las X. Tampoco quería dejar las X abiertas a cualquiera. En este artículo mencionan algunas alternativas, pero al final me decidí por añadir simplemente estas dos líneas antes del “case” de buttonpressed.sh:

export XAUTHORITY=~misuaurio/.Xauthority
export DISPLAY=":0.0"

Y con esto ya va sin más problemas: tengo así botones para fotocopiar, abrir en el GIMP y enviar por correo, que no está mal. Los resultados del escaneo tampoco son estelares, pero qué vas a pedir de un escáner de 50 euros :-D .

Actualización (27/5/09): sigue funcionando en Jaunty sin problemas. Empezó a hacerme ruidos y demás. lsusb lo mostraba, pero sane-find-scanner y scanimage -L no lo detectaban bien (sane-find-scanner decía que había un escáner, pero no sabía el modelo). Buscando un poco, encontré una orden a partir de la cual sacar bastante información:

sudo SANE_DEBUG_PLUSTEK=12 SANE_DEBUG_DLL=12 SANE_DEBUG_SANEI_USB=255 scanimage -L 2>&1 | tee salida.log | less

Mirando, encontré una línea del estilo de “sanei_usb_open: lisbusb complained: Broken pipe” cerca de donde libusb empezaba a sacar información en serio del escáner, una vez el backend plustek de SANE lo hubo detectado, y bastantes mensajes sobre ioctl y demás. Según parece, la forma más sencilla de interpretar este mensaje es un problema de conexión pura y dura. Sospechaba de mi hub/stand de portátil “made in china”, así que cambié el cable a uno de los puertos USB del portátil, y funciona perfectamente :-D .

Dejar un comentario

Encuesta y libro de Git

6 Septiembre, 2008 a 9:02 · Archivado en Uncategorized ·Etiquetado ,

Sigo con mi aprendizaje y enseñanza simultánea de Git :-) . Hace poco la gente de la lista de correo ha publicado la Git User’s Survey 2008, que está arrojando algunos resultados muy interesantes. Traduciendo del mensaje de la lista de correo con el resumen parcial de los resultados tras las primeras 1000 respuestas, parece ser que:

  • El 59% de la gente que usa Git sabe C, y el 52-53% saben Ruby y/o shell scripting. Le sigue la gente de Python y luego los de Perl. Java tiene un 42% (buenas noticias para los de JGit y EGit). Tcl/Tk está muy bajo, por lo que parece que conseguir contribuidores para gitk va a estar complicado. 12 respuestas no eran ni programadores.
  • Algunos usos interesantes de Git incluyeron:
    • Emplear Git para seguir otros proyectos que usan SVN (lo que hago yo ahora, y es muy cómodo).
    • Sistemas de ficheros versionados.
    • Distribución de materiales / colaboración al redactar documentos.
    • Creación de zonas de pruebas en las que ver exactamente qué hacen los instaladores binarios.
    • Almacenamiento de resultados de pruebas y compilaciones.
  • La mayoría de la gente usa paquetes binarios para conseguir Git (59%), y luego vienen los medio frikis con los paquetes fuente y tarballs (28%) y los muy muy frikis que lo sacan del repositorio directamente (22%).
  • La mayoría de los usuarios de Git trabajan sobre Linux, luego viene MacOS X, y luego Windows. Hay 2 usándolo en iPhone, supuestamente… :-/
  • En cuanto a porcelanas, la mayoría de la gente usa core-git, y si no, o usa sus propios scripts o Easy Git. Si se trata de sistemas de gestión de parches a la quilt, lo que se emplea más es StGIT.
  • En herramientas gráficas vence por goleada gitk y git-gui, pero QGit tiene un respetable 11%. GitNub está ahí, pero parece más un visor para MacOS X de las contribuciones a un repositorio alojado a GitHub que un visor de Git en general. Dicen que JGit y EGit están avanzando, así que a lo mejor vemos integración en condiciones con Git para la edición del año que viene. También se está implementando algo del estilo en KDevelop 4.
  • En interfaces Web, domina gitweb con un 80% (git instaweb y tachán, se entiende), y le sigue Gitorious (14%), que está muy bien si quieres algo estilo forja: es una web, y al mismo tiempo un proyecto de software libre (te puedes descargar su código e instalar tu propia versión, no como GitHub, cuyo código es cerrado). Está cgit por ahí, un CGI hecho entero en C que tiene pinta de ser muy limpio y ligero (6%). Mira, han mencionado Redmine, el que enseñé a la gente del curso de Git.
  • A la gente no le interesaría pagar por soporte comercial, con un rotundo “no” del 69% (y un 22% “no aplicable”).

De todas formas, esto irá cambiando un poco conforme se vayan recogiendo algunas respuestas. Ya hay una parte 2 y una parte 3 de ese resumen, pero no tengo tiempo para traducirlas :-D .

Por otro lado, Scott Chacon está trabajando en un libro de Git que recoge muchos gráficos de gran calidad y sus screencasts, y está pidiendo colaboración de la comunidad. Sólo he tenido tiempo de echarle un vistazo, pero tiene muy buena pinta.

Dejar un comentario

Saxon y XSLT2

6 Septiembre, 2008 a 8:31 · Archivado en Uncategorized ·Etiquetado , , ,

Últimamente estoy trabajando bastante con XLST 2 y XPath 2.0, empleando la biblioteca Saxon (que le da tropecientas vueltas a Xalan, y lo digo por experiencia). La verdad es que se pueden hacer cosas ahora que de otra forma me serían muy complicadas en XSLT 1.0, aunque tiene sus pequeños detalles molestos. El último día me tiré varias horas rascándome la cabeza de por qué una secuencia de elementos que creaba con xsl:for-each de XSLT acababa creando nuevos nodos en vez de utilizar los existentes, haciendo que fallara la prueba de identidad “. is $nodo” (sólo devuelve true si se trata exactamente de la misma copia del mismo nodo).

Es decir, si por ejemplo tengo este bucle que recorre una serie de elementos del árbol XML:

<xsl:for-each select="a|b|c">
  <xsl:sequence select="."/>
</xsl:for-each>

Si queremos recoger los resultados en una variable, uno pensaría hacerlo así:

<xsl:variable name="x">
  <xsl:for-each select="a|b|c">
    <xsl:sequence select="."/>
  </xsl:for-each>
</xsl:variable>

Sin embargo, esto no funciona como es esperado: los a, b y c dentro de x son copias de los originales. Tras mucho rebuscar por San Google, no encontré nada, pero el estándar XSLT 2.0 incluye en su punto 5.7 lo siguiente:

The sequence may be used to construct the content of a new element or document node. This happens when the sequence constructor appears as the content of a literal result element, or of one of the instructions xsl:copy, xsl:element, xsl:document, xsl:result-document, or xsl:message. It also happens when the sequence constructor is contained in one of the elements xsl:variable, xsl:param, or xsl:with-param, when this instruction has no as attribute. For details, see 5.7.1 Constructing Complex Content.

Es decir, que con añadir una declaración de tipo de secuencia a la variable sirve:

<xsl:variable name="x" as="item()*">
  <xsl:for-each select="a|b|c">
    <xsl:sequence select="."/>
  </xsl:for-each>
</xsl:variable>

Para los que no lo sepan, “item()*” indica que tenemos cero o más (“*”) elementos de cualquier tipo (“item()”). Podríamos concretarlo más si nos preocuparan temas de tipado o quisiéramos forzar una cierta conversión (como de entero a cadena), pero en este caso no hace falta.

Dejo esto apuntado por si alguna otra persona tiene el mismo problema que yo (que no lo creo, pero bueno :-D ).

Dejar un comentario