Robots y modelos

Notas sobre pruebas, modelado y aventuras en Java y Android

Archive for the ‘Uncategorized’ Category

Soluciones de acceso remoto desde un Nexus 7 para Windows y GNU/Linux

leave a comment »

Estos días he estado preparando la red de casa para poder acceder remotamente a los ordenadores desde cualquier sitio usando mi tableta Nexus 7. Tras probar unas cuantas cosas, al final he conseguido montar varias soluciones para poder administrar mis máquinas mediante terminales y escritorios remotos y encender mis ordenadores.

Lo dejo todo anotado por aquí por si a alguien le sirve :-). Empezaré contando las opciones gratuitas que hay (aunque requieren trastear), y acabaré hablando de varias opciones que no requieren tanto trabajo (aunque tampoco me resuelven el 100% de los problemas).

OpenVPN: conexión segura a la red de casa

Lo primero que se le pasaría a cualquiera sería abrir puertos a mansalva en su router y entrar a fuego con cualquier programa de acceso remoto tras asegurarse de que el router tenga un nombre fijo asociado a la IP que tengamos en cada momento, usando un servicio como no-ip.com.

Esto, sin embargo, plantea varios problemas:

  • Es un incordio tener que mantener las asociaciones entre los puertos del router y los puertos concretos de cada máquina, y muy propenso a errores.
  • Cada puerto abierto es una vulnerabilidad potencial, y si alguien se cuela por ella se puede colar en todas tus máquinas a la vez. Es necesario que haya el mínimo número de puertos abiertos al exterior, y que lo que esté detrás del puerto esté *muy* bien protegido.

En vez de eso, una opción mucho mejor es crear un túnel cifrado a través de Internet a la red a controlar, de forma que parezca que estamos en esa misma red y podamos acceder a todos los ordenadores como si nada. Para ello se ha de instalar un servidor VPN (Virtual Private Network) en la red a controlar, en un ordenador que esté siempre encendido y que sea visible desde el exterior (con el nombre fijo de no-ip.com, por ejemplo). El candidato ideal para todas estas cosas es el router, precisamente :-D. La mayoría de los routers domésticos no incorporan esta funcionalidad, pero si tienes un router compatible con algunas de las variantes más recientes de Tomato (como la de Toastman, basada en TomatoUSB) puede instalársela y aprovechar el servidor OpenVPN que tienen incorporado. Mi (algo vetusto) WRT54GL es uno de ellos: si queréis compraros uno, quizás os venga mejor el ASUS RT-N16 e EasyTomato.

La mayor complejidad a la hora de montar una VPN con OpenVPN es configurar la autenticación de los usuarios. Aunque se admite la posibilidad de usar un simple par usuario/contraseña (una “static key“), esto no funciona bien cuando hay que darle permiso a varios ordenadores. Es mucho mejor utilizar certificados X.509 (como los de SSL) para autenticar tanto al servidor como al cliente, pero gestionar los certificados (lo que se llama la “Public Key Infrastructure” o PKI) es bastante complejo si no se tienen conocimientos previos. Para esto existen programas que simplifican todo el proceso. Probé XCA (no me convenció la interfaz) y TinyCA (no funcionaba en Arch Linux), así que al final utilicé EasyRSA, un conjunto de guiones Bash del proyecto OpenSSL en el que se basa el cifrado de OpenVPN. Funcionan muy bien, aunque tuve que tirar todas las claves varias veces hasta que quedaron como me gustaron :-). El proceso es básicamente el siguiente:

  • Editar el fichero “vars” de EasyRSA apropiadamente.
  • Generar el fichero de parámetros de Diffie-Helman, que se usarán para generar todas las claves privadas y públicas.
  • Generar el par de claves de nuestra Certification Authority.
  • Generar el par de claves de nuestro servidor OpenVPN (el Common Name debería coincidir con el nombre público del servidor).
  • Generar un par de claves para cada cliente OpenVPN (hay que usar –interact para poder poner el Common Name de cada cliente).

El siguiente paso es configurar el cliente. En el caso de Android, OpenVPN tiene un cliente oficial, aunque el que estoy usando (y con el que me va bien, así que para qué cambiar :-D) es el de Arne Schwabe. Por cierto, este último ya no requiere root desde Android 4.0, creo, ya que utiliza un API estándar de Android. En general, con seguir los pasos que da la aplicación irá bien, aunque tendréis que toquetear un poco hasta que termine de funcionar. Un pequeño problema que yo tuve fue en el detalle del enrutado. Mi router neutro está detrás de un módem+router del que es destino por omisión para todas las conexiones entrantes (DMZ), y esto en general funciona bien para las conexiones TCP. Sin embargo, no es así para las conexiones UDP, que son las que usa OpenVPN por omisión: tuve que poner explícitamente un mapeo de puertos hasta que funcionó bien.

Con esta conexión pude sacar otro beneficio: poder entrar en la interfaz web de mi router y usar sus funciones de Wake-on-LAN (también cortesía de Tomato) para encender remotamente mis ordenadores. La clave para poder hacer esto es que estén conectados por cable al router, y que tengan debidamente configurada la BIOS para admitir esta forma de encendido. Esto varía de ordenador a ordenador, así que no puedo dar mucha más información :-/. Si todo va bien, con un clic enciendes el ordenador, te esperas un minuto o dos e inicias sesión por alguno de los métodos inferiores.

OpenSSH y JuiceSSH: terminales remotas

Con la VPN permitiendo a nuestra tableta ser parte de la red de casa, lo siguiente es ver cómo abrir una terminal (texto puro y duro) a una de las máquinas. Esto es muy eficiente y requiere muy poco ancho de banda, y es ideal para administrar sistemas remotamente. El protocolo ideal para estas cosas es SSH (Secure SHell), y para ello necesitaremos instalar un servidor SSH en la máquina a la que nos vayamos a conectar (el de OpenSSH es estupendo), y un cliente SSH en la tableta.

En Android hay unos cuantos clientes SSH. Originalmente usaba ConnectBot, pero hace unos meses me cambié a JuiceSSH, que en mi opinión tiene una interfaz muy superior. Hay una versión de pago, pero con la versión gratuita vais sobrados. Por cierto, no olvidéis usar Byobu para multiplexado de sesiones (o por lo menos tmux) si os conectáis a una máquina con Ubuntu.

Otro uso para SSH es como túnel para protocolos inseguros, como VNC (cuando se usa sin cifrado), que veremos a continuación.

TightVNC, TigerVNC, x11vnc y bVNC: pantallas compartidas remotas

El siguiente paso era conseguir acceso a un entorno gráfico. Básicamente, hay dos protocolos estándar para esto: RDP (Remote Desktop Protocol, el “escritorio remoto” de Windows) y VNC (Virtual Network Computing). RDP viene de serie en muchas versiones de Windows (en Linux no es tan popular: existe xrdp pero es peliagudo de configurar), permite transmitir el audio del ordenador remoto y es muy eficiente y flexible, pero tiene la pega de que al iniciar sesión remotamente se cierra la sesión local. Si tienes que darle soporte a un familiar, no le va a hacer gracia que su música o su partida de GranjaPueblo se interrumpa mientras le arreglas el cacharro :-D.

Por eso, prefiero VNC, que permite “compartir” la pantalla, con lo que la otra persona podrá ir viendo todo lo que vas haciendo. Al igual que con SSH, necesitaremos instalar un servidor en el ordenador a administrar y un cliente en la tableta.

El servidor a usar depende mucho del sistema operativo. Para Windows, el mejor (de los gratuitos) que hay ahora mismo es TightVNC 2.6. Se puede instalar como un servicio, de forma que esté disponible incluso antes de iniciar sesión, y es muy fácil de montar. De hecho, veremos que es el que te instala JumpDesktop cuando le pides acceso por VNC en Windows. TightVNC hereda de las versiones de código abierto de RealVNC, que se publicaron bajo la GNU GPL.

Para Linux, podríamos también usar TightVNC, pero sería una versión demasiado antigua (la 1.3). En este caso es mucho mejor trabajar con TigerVNC 1.2, un fork de TightVNC con mejor soporte para Linux. TigerVNC permite abrir un servidor X virtual al que conectarse remotamente por VNC como si fuera una pantalla normal y corriente: sólo tenemos que establecer la contraseña con “vncpasswd”, abrir el servidor con “vncserver” desde una sesión SSH y listo.Si lo que queremos es conectarnos a una pantalla “de verdad” en una sesión ya abierta, tendremos que usar x11vnc. Es un poco más complicado de usar, pero no mucho más. Tendremos que ejecutar una orden como ésta desde una sesión SSH, y luego ya podremos entrar con el cliente oportuno:

x11vnc -rfbauth ~/.vnc/passwd &

Un aspecto molesto de Linux que no he podido solventar aún es cómo entrar por VNC sin haber iniciado sesión, como se puede hacer en Windows. La solución que he adoptado por lo pronto es entrar automáticamente en mi cuenta de usuario e inmediatamente bloquear la pantalla por contraseña de forma automática, usando las opciones de KDE 4. Para no tener que abrir el servidor VNC yo, he añadido esta línea al final de ~/.xprofile:

x11vnc -rfbauth ~/.vnc/passwd -forever &

La opción “-forever” evitará que se cierre el servidor VNC cuando cierre mi sesión en algún momento. De esta forma, puedo encender remotamente mi ordenador y luego entrar a una sesión remota sin más.

Con los servidores resueltos, el siguiente paso es seleccionar un buen cliente VNC para Android. Primero probé el que tiene más solera de los gratuitos, androidVNC, pero no me gustó demasiado la interfaz: era bastante primitiva, la verdad. Tras mirar un poco, en un hilo de comentarios vi al autor de bVNC promocionar su aplicación, y tras probarla creo que es muchísimo mejor, y que se merece más instalaciones. El manejo es más cómodo, y permite compartir fácilmente el portapapeles, cambiar de modo de color sobre la marcha y desplazarse por la pantalla, además de implementar más opciones de seguridad, como SSL anónimo o túneles SSH. Lo único que me costó trabajo fue averiguar cómo hacer clic derecho, pero mirando la ayuda se resolvió todo.

JumpDesktop: pantallas compartidas y escritorios remotos seguros sin VPN

De todos modos, la verdad es que estaba algo molesto con la dificultad en bVNC a la hora de hacer clic sobre ciertos elementos pequeños, la imposibilidad de dejar “flotar” el cursor sin hacer clic y otros detalles varios de la interfaz. Son cosas menores, pero me puse a buscar clientes VNC mejores. Y tras hacerlo, di con JumpDesktop: un cliente RDP y VNC con mejor acabado aún, aunque de pago (unos 7,5€  a fecha de hoy). Un detalle aparentemente tonto es que ahora el cursor se puede manejar con una “lupa” que tiene debajo, permitiendo dejar flotando el ratón sobre un punto dado y apuntar con mucha más exactitud y comodidad. El botón derecho es mucho más sencillo de introducir, además :-D. JumpDesktop parece estar en desarrollo activo: hace poco han sacado una versión con soporte para los gestos multitouch de Windows 8.

El precio sería un tanto alto si no fuera porque tiene otra ventaja: puede operar a través de NAT y cortafuegos sin necesidad de montar una VPN. Yo ya tenía montada mi VPN, pero la verdad es que me intrigó bastante de cara a otras posibilidades. Tienes que instalar un software específico en cada máquina con Windows o Mac (lástima, nada para Linux) e introducir las credenciales de una cuenta de Google en cada una. Esas credenciales no se mandan a JumpDesktop, sino que se usan para iniciar sesión en Google Talk y utilizar el protocolo XMPP en que se basa Talk para establecer la conexión VNC o RDP oportuna. Lo probé con varias máquinas y funcionó estupendamente, así que no me arrepiento demasiado del gasto :-D. Las contraseñas se guardan localmente en cada dispositivo y no se mandan a JumpDesktop, así que si hay que fiarse de alguien es de Google.

Pero, por si acaso, me dió por mirar la competencia, y encontré otras dos opciones parecidas que también se saltaban NAT y cortafuegos: Splashtop y TeamViewer. Las dos son gratuitas para uso personal, y luego ofrecen productos de pago para uso profesional. Por mi parte bien: probé Splashtop y su Streamer no me funcionó bajo Arch Linux, así que lo descarté inmediatamente.

TeamViewer sí funcionó bastante bien en Linux. El problema es la aplicación para Android, que no es tan buena como la de JumpDesktop. Mover el ratón exige arrastrarlo por toda la pantalla de forma bastante irritante, y no se pueden usar las flechas de mi teclado Bluetooth ni las combinaciones de tipo Ctrl+X o Alt+Y. Además, la aplicación y el servicio eran propensos a cuelgues y corrupción de su base de datos interna si cerrabas e iniciabas sesión con cierta frecuencia (normal durante mis pruebas), y no respetaban bien la multitarea de Android. En general, JumpDesktop me resultó más agradable de usar, y al estar basado en estándares, la falta de un cliente Linux no es importante: uso OpenVPN y luego abro el cliente VNC o RDP que prefiera :-D. De todos modos, TeamViewer tiene una importante ventaja si tenéis que dar soporte a otras personas: no requiere introducir nuestras credenciales en las máquinas que vayamos a controlar. Cada máquina tiene asignado un número, y cada vez que lanzamos TeamViewer se nos genera una contraseña de un uso. El dueño de la máquina a controlar nos puede dar ambos datos por teléfono, nos conectamos, resolvemos el problema y listo. Esto puede ser crucial en ciertas situaciones. Otra ventaja es que incorpora transferencia de archivos entre la tableta y la máquina remota, que en otros casos puede venir bien.

Resumen

Mis recomendaciones personales son más o menos las siguientes:

  • Todo basado en estándares y software libre: Tomato, OpenVPN (servidor+cliente VPN), OpenSSH (servidor+cliente SSH), TightVNC, TigerVNC, x11vnc y bVNC. Lo cubren todo, son BSD o GPL y encima gratis. La pega es que requieren bastante configuración inicial. Hay clientes mejores que bVNC como JumpDesktop (aunque son cerrados y de pago).
  • Acceso RDP a través de NAT y cortafuegos sin usar VPN, usando credenciales de Google: JumpDesktop. Quizás lo de dar las credenciales de Google duela mucho menos si usas las claves específicas de aplicación que da Google al activar autenticación de doble factor. Estas contraseñas se pueden revocar automáticamente cuando ya no las necesites, y no valen para acceder a las partes más sensibles de la cuenta.
  • Acceso VNC a través de NAT y cortafuegos sin usar VPN: JumpDesktop con credenciales de Google o TeamViewer con claves permanentes o de un solo uso. TeamViewer tiene más funcionalidad y cliente Linux, pero JumpDesktop tiene mejor acabado en Android.

Tengo entendido que Splashtop es mejor para videojuegos, pero no pienso usar el acceso remoto de esa forma, así que no me he molestado mucho más con ello :-D.

Written by bluezio

18 de marzo de 2013 at 3:10

Publicado en Uncategorized

Reemplazando java.util.Random por el Mersenne Twister

leave a comment »

Esta mañana un compañero me mandó un enlace sobre la (mala) calidad del generador de números pseudoaleatorios que viene con la biblioteca estándar de Java: la clase Random. Ya había oído cosas acerca de que era malo, pero esto lo dejó bastante claro:
 
http://www.alife.co.uk/nonrandom/
 
La cosa es que no debería verse un patrón en la imagen que genera la applet, y además se repite con bastante facilidad. Java dispone de otra implementación mejor (SecureRandom), pero tiene dos pegas:
  • No puedes saber con total seguridad qué proveedor se está usando, ya que depende de lo que venga de serie en la JVM. Si quieres uno concreto lo puedes indicar por nombre, pero entonces te atas a una JVM determinada.
  • setSeed(…) no reinicia el algoritmo con la nueva semilla, sino que alimenta a la semilla existente con la nueva información. Dado que SecureRandom es para uso criptográfico más que para simulaciones, no es mala idea, pero yo necesito que los resultados sean los mismos siempre que ponga la misma semilla :-/.

Por ello, tuve que descartar SecureRandom también, y la única opción era buscar un PRNG bueno en alguna biblioteca externa. Mirando un poco encontré Uncommons Maths, una biblioteca escrita en Java puro de sólo 50KB y bajo la ASL 2.0, que encima superaba la batería Diehard (que parece ser una buena referencia en el mundillo de los PRNG). Según este hilo de Stack Overflow, los resultados del autor original son reproducibles y j.u.Random no cumple esa batería de pruebas.

Por lo pronto he pasado uno de mis programas de Random al MersenneTwisterPRNG (una implementación del Mersenne Twister de Matsumoto y Nishimura), que es el recomendado por el autor para simulaciones de propósito general. Ha sido más fácil de lo que esperaba, ya que todos los PRNG de Uncommon Maths heredan de Random, así que es un sustituto limpio. Y por si no fuera poco, Uncommon Maths también implementa algunas distribuciones comunes de probabilidad (normal, Poisson, exponencial y binomial por lo menos) e incorpora PRNG con más rendimiento (basados en operaciones lógicas XOR) o con más seguridad (AES). Está muy completa la biblioteca :-).

Written by bluezio

16 de enero de 2013 at 0:14

Publicado en Uncategorized

Tagged with

Despiece de Sony Ericsson MW600 y cuestiones de sostenibilidad

with 26 comments

La semana pasada mi querido manos libres estéreo Bluetooth Sony Ericsson MW600 dejó de encenderse de repente. Originalmente pensaba que sería su mal hábito de quedarse “colgado”, y seguí las recomendaciones habituales de dejar que se descargara a lo largo de varios días, para que se apagara completamente y volviera a responder tras volverlo a cargar.

Sin embargo, en este caso no sirvió de nada en absoluto. De hecho, el problema es que no encendía. A veces, al conectar el MW600 a un cargador mostraba un indicador de batería lleno, y justo tras desconectar y volver a conectarlo mostraba la animación. Este comportamiento tan raro me hizo sospechar de la batería, así que consulté con el servicio técnico y me dijeron que no había otra opción que llevarlo a reparar. El problema es que el aparato estaba fuera de garantía: lo compré en noviembre de 2010, así que ya habían pasado más de los 12 meses que tenía (lo compré en Amazon UK). Me podría salir el arreglo más caro que un MW600 nuevo :-/.

Por ello, mi siguiente paso fue intentar desmontar el bicho a mano y mirar si podía reemplazar la batería por mi cuenta. Aunque no he podido localizar un proveedor minorista de una batería compatible, me ha servido para aprender un poco cómo está hecho un bicho de éstos. Ayer estuve mirando cascos estéreo Bluetooth por todos lados, y por mucho que me pese el MW600 sigue teniendo la mejor relación calidad/precio, así que he pedido otro MW600 de Amazon España por 26€. En Play.com estaba a 20€, pero al ser de UK la garantía volvía a ser de 1 año, en vez de los 2 años que tenemos por ley en España.

Tras decidir reemplazar el aparato, he repetido el desmontaje, esta vez con un propósito más ingenieril y hasta el final :-D. Dejo por aquí los pasos por si alguien tiene curiosidad. Notaréis que mi unidad está algo dañada: eso es por el primer desmontaje, que fue algo manazas :-).

Aquí tenéis el sujeto de pruebas, por el lado del control capacitivo de volumen:

Hay mucha gente que se queja de este control capacitivo y preferiría una rueda tradicional, pero personalmente creo que este diseño es más resistente mecánicamente (no hay partes móviles) y aguanta mejor el polvo y humedad. También se puede ver la pinza, que de hecho es uno de los puntos débiles del MW600: uno de mis familiares rompió la suya sin querer tras engancharse con un mueble. Es plástico normal y corriente, al fin y al cabo.

El primer paso para desmontar este trasto es quitar la pinza, precisamente. La forma más fácil es coger un palito largo y fino (o la punta de un destornillador de estrella) y presionar sobre uno de los pivotes que encajan la pinza al resto del cuerpo del aparato. Os lo marco en rojo aquí:

Sacada la pinza, nos quedará así:

Como puede verse, la pinza del MW600 no es mucho mejor que un alfiler para tender la ropa: un simple muelle da su “fuerza”, y la unión entre el muelle, el cuerpo y la pinza en sí es puramente mecánica, con un eje de plástico. De todos modos, algo más fuerte pesaría y ocuparía más.

El siguiente paso es retirar los botones de goma que permiten pausar canciones y llamadas y saltar entre canciones. Los podéis ver aquí:

Si os fijáis bien, los controles de la música tienen un pequeño “marco” de plástico alrededor. Este marco es lo que fija los botones al cuerpo principal del aparato. Para retirarlo, basta con introducir un objeto fino en el hueco (que sea blando, o si no puede que deforméis el marco sin querer, como yo :-P) y hacer palanca. El marco tiene una serie de clips de sujeción que se retiran haciendo presión. Os quedará así:

Bueno, casi: si lo habéis hecho bien, aún tendréis los tres botones del aparato :-). En mi primer desmontaje no retiré estos botones antes de los pasos siguientes y el botón izquierdo saltó. Como veis, están simplemente pegados: son botones de membrana, y no interruptores “de verdad” (más resistentes, pero más grandes, pesados y costosos). Los botones de goma son simplemente una forma cómoda de pulsar esos botones pequeños.

Con los botones retirados, ya podemos quitar el protector de plástico que cubre el extremo con el conector MicroUSB. Para ello, antes hay que despegar con una uña o un objeto blando y fino el embellecedor que oculta el tornillo:

Tras retirar el tornillo (¡cuidado con perderlo!) podemos sacar el protector y la cubierta de goma del botón de encendido (está simplemente encajada):

De nuevo, el botón “de verdad” es pequeñísimo. En este caso sí que es un interruptor normal. Después comentaré una cosa interesante del puerto MicroUSB, pero por ahora retiraremos el tubo de plástico que cubre la parte central de la unidad, simplemente sacándolo por el extremo del MicroUSB (está simplemente encajado):

Como veis, el tubo de plástico es de una sola pieza, y el botón de llamada (encajado y punto) oculta otro interruptor pequeño que sale directamente de la placa del MW600. Si le damos la vuelta al cuerpo del aparato, podemos acceder a la batería:

Aquí tenemos la batería del MW600. Retirarla exige algo de esfuerzo, ya que está pegada (sí, pegada) al fondo del compartimento, pero con un poco de cuidado sale:

Como veis, es una GP0836L17 de 0.6Wh. Buscando un poco, parece ser fabricada por GP Batteries (datasheet). Mide 8.2mm (diámetro) x 35.5mm (largo) y es una batería cilíndrica de ión litio de 170mAh a 3.7V. Se puede ver que es de ión-litio tras retirar la pegatina negra que cubre la mitad superior para que no se vea el blanco de la batería a través del tubo de plástico:

El problema es que GP Batteries es una mayorista y no vende a particulares. En Amazon.com parecen vender una compatible con MW600 y con sus modelos anteriores MH100 y MH600, aunque es de ión-polímero y el vendedor no envía a España. Además, por $15 + envío + aduanas sale más económico comprar un MW600 nuevo. Por cierto, sus dimensiones no se corresponden con ningún estándar, así que olvidaos de buscar una genérica por ahí. Aquí la tenéis al lado de una pila AAA:

Como veis, usar una pila estándar habría añadido un centímetro más de largo y algo más de diámetro. ¿Habría merecido la pena que la batería fuera reemplazable, por sostenibilidad? Es cierto que pesa bastante más, y eso podría causar rechazo a los potenciales compradores. Pero no dejo de pensar que simplemente usar una celda de ión-litio con dimensiones estándar ya habría sido suficiente para poder arreglarlo con destornillador y datasheet en mano. Lo malo de todos estos bichos con baterías imposibles de reemplazar es que son bombas de relojería para el comprador: por muy bien que los trate, eventualmente fallarán. ¿De verdad tenemos que comprar uno nuevo cada 18-24 meses?

Volviendo al tema: ya hemos hecho todo el desmontaje útil, pero ahora vamos a terminar de abrir el cacharro, ya por curiosidad :-). Vamos a retirar el protector del extremo de los cascos, quitando el tornillo que está justo por la parte de la pinza:

El pequeño objeto dorado que vemos de canto es el micrófono de llamadas. Ahora vamos a retirar la cubierta superior del aparato. Cuidado: a partir de aquí todo es básicamente irreversible, ya que está todo pegado y volver a pegarlo justo como estaba va a ser difícil.

Para retirar la cubierta superior, hay que retirar cuatro clips de sujeción (dos en cada lado de cada extremo), y despegar la parte que protege a la pantalla OLED:

Por la parte del micrófono notaréis que he despegado dos pequeñas placas impresas. Son las antenas, como os imaginaréis por el diseño en espiral que tienen dibujadas. Ah, y están pegadas con celofán transparente de dos caras :-D. La pantalla OLED está pegada a la placa. Con un poco de fuerza por el extremo cercano al micrófono, se levanta fácilmente:

La pantalla no se puede separar de la placa, ya que su cable está unido directamente a ella, en vez de conectado a un enchufe como suele ocurrir en los portátiles. El “ribbon cable” usado es ligero y fino, pero como hubiera que cambiar la pantalla… ¿no se podría haber usado un conector normal? Así se podría cambiar la pantalla, aunque podría añadir un par de milímetros al largo del aparato.

En fin, volviendo al tema. La placa madre y la placa hija con el control capacitivo están pegadas al armazón de plástico. Tras despegarlas, ya podemos ver toda la electrónica del MW600:

Como veis, el MW600 está formado por una placa principal con casi toda la circuitería y 4 placas hijas conectadas con “ribbon cables”: la superior tiene los controles capacitivos (4 zonas diferenciadas), la inferior tiene 3 botones de membrana con los controles de música, y las dos pequeñas al lado del micrófono forman la antena del aparato. Se me pasó hacer una foto del otro lado, pero curiosamente el conector USB no está soldado a la placa, sino que hace contacto mediante 3 puntos del otro lado de la placa principal: esto indica que se podría cambiar fácilmente el puerto USB (si no fuera por tanto pegamento). Lo mismo pasa con el compartimento de la batería: las dos pestañas de contacto simplemente tocan dos puntos de la placa. Sin embargo, el conector de los cascos está soldado con estaño. Supongo que esto le dará bastante resistencia mecánica al conector.

Y aquí están todas las piezas del MW600 (os destaco el conector Micro USB):

Tras despiezar el bicho, pienso que no me importaría pagar algo más por un trasto más sostenible: la pantalla podría estar conectada normalmente en vez de pegada a la placa, y se podría sujetar mediante clips de sujeción en vez de tanto pegamento. La batería podría usar pilas recargables normales, o por lo menos celdas de tamaños estándar. Sin embargo, todo esto añadiría peso y coste, evidentemente. Al final es un equilibrio, y ahora mismo está ganando reducir costes de producción y peso, pero es prácticamente imposible hacer ningún tipo de mantenimiento en estas cosas.

Me encanta el MW600, pero si saliera una variante con batería reemplazable ya sería perfecto. Lo malo es que esta obsolescencia programada le viene de perlas a los fabricantes :-/. Por lo menos el MW600 te permite usar tus propios cascos, con lo que se reducen los puntos de fallo, pero la batería sigue siendo un problema. El problema es que prácticamente no existen manos libres con baterías reemplazables: el único que he visto es el Motorola H300, que utiliza una pila AAA estándar, pero es antiquísimo.

Intenté “castigar” a Sony Ericsson comprando un manos libres de otro fabricante, pero por mucho que busqué no encontré mejores alternativas para mi caso. Como salgo a correr todos los días, las alternativas que incorporan los cascos en el propio aparato se estropearían rápidamente por sudor o estrés mecánico (Plantronics Backbeat 903+, Motorola S10 HD, Sennheiser MM100, LG HBS700, Nokia BH505). Necesito sonido estéreo para escuchar música, así que los modelos de una sola oreja no valdrían. Eso me deja de nuevo con los modelos de tipo clip (como el MW600): el Samsung HS3000 (al andar o correr genera ruido), el Samsung HM3700 (interesante, pero imposible de comprar en Europa y sin controles de música), el Samsung HM6450 (igual que el HM3700), el Jabra CLIPPER (conector de cascos delicado) o unos cuantos de Nokia (más limitados y caros que el MW600 desde España).

Lástima: a ver si en un futuro alguien se da cuenta de que este ritmo de tirar y comprar cacharros cada 18-24 meses no es sostenible :-/.

Written by bluezio

8 de julio de 2012 at 19:03

Publicado en Uncategorized

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

with 3 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.

Written by bluezio

8 de julio de 2011 at 8:30

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

Seguir

Recibe cada nueva publicación en tu buzón de correo electrónico.

Únete a otros 260 seguidores