Siguiendo con la actualización bajé la última versión de arduino para la fecha la 0017, e hice la instalación normal para gentoo amd64 que normalmente realizaba, como lo describen en la página oficial. Y finalmente reemplazé el avrdude y el librxtxSerial.so que trae el arduino que son compilados para 32bits, por los instalados en mi sistema.

Pero aquí comenzaron los problemas, al iniciar arduino e intentar bajar el sketch a la board aparecía el error :

avrdude: stk500_recv():

El stk500 es un tipo de programador para avr, que es el que “imita”, por así decirlo, el arduino. Así que lo primero que intenté fué tomar el .hex generado y con avrdude tratar de bajarlo desde la consola, pero devolvió el mismo error.

Al averiguar encontré aquí una frase bastante diciente:

But in any ways, DON’T USE AVRDUDE FROM YOUR DISTRO! because the one provided with the Arduino tools is a patched version.

Ajá! el avrdude que trae arduino viene parchado, así que no puede ser reemplazado como antes, revisado el asunto procedo a dejar el avrdude original y pruebo el programa y para mi sorpresa funcionó.

Pero no todo son alegrías, seguí revisando aquella página y encontré que podía haber un error en la monitorización del serial, así que hago una prueba y efectivamente el programa se cerró, revisando en la consola el reporte que generó fué el siguiente:

A fatal error has been detected by the Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0x00007f8385124803, pid=11115, tid=140202839185680
#
# JRE version: 6.0_17-b04
# Java VM: Java HotSpot(TM) 64-Bit Server VM (14.3-b01 mixed mode linux-amd64 )
# Problematic frame:
# C [librxtxSerial-2.1-7.so+0x8803] read_byte_array+0×43
#
# An error report file with more information is saved as:
# /opt/arduino-0017/hs_err_pid11115.log
#
# If you would like to submit a bug report, please visit:
# http://java.sun.com/webapps/bugreport/crash.jsp
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#
./arduino: line 20: 11115 Abortado java -Dswing.defaultlaf=com.sun.java.swing.plaf.gtk.GTKLookAndFeel processing.app.Base

bueno pues finalmente la solución la postean en la misma fuente: Bajar el paquete rxtx-2.2pre2-bins, desempaquetarlo y copiar los archivos RXTXcomm.jar y x86_64-unknown-linux-gnu/librxtxSerial.so dentro del directorio /lib del arduino reemplazando los archivos ya existentes.

Y gracias a Stephane Cousot y Douglas Edric Stanley contamos con la implementación de OpenCV para processing y/o java.

INSTALACIÓN

Para instalarla tenemos que en primer lugar instalar opencv, lo bueno es que figura en la mayoría de respositorios así que bastaría usar el administrador de paquetes para instalarlo.
aptitude install opencv
urpmi opencv
pacman -S opencv
emerge opencv
....
dependiendo del sistema en el que estes.

Esto debiera instalar las librerías y cabeceras necesarias en las carpetas del sistema /usr/include y /usr/lib. Como estas ubicaciones ya hacen parte del PATH no vanos a tener los problemas que normalmente se presentan en windows. Al parecer en ubuntu algunas librerías se instalan por aparte, por si acaso esta es la lista de librerías que deberías tener instalada:
/usr/lib/libml.so
/usr/lib/libhighgui.so
/usr/lib/libcxcore.so
/usr/lib/libcvaux.so
/usr/lib/libcv.so
Si no es así seguramente es un paquete separado así que por medio del administrador de paquetes lo puedes buscar e instalar.

Ahora descargamos la librería para processing al momento la 01, aconsejable también los ejemplos para java y/o processing.

El procedimiento es el mismo que cualquier librería, descomprimimos el paquete y copiamos la carpeta dentro de processing-1.0.9/libraries/ y listo.

A este momento si tenemos un dispositivo v4l conectado y configurado correctamente (osea funcionando), debería estar funcionando los ejemplos de la librería, y ya se podría trabajar en ella. Pero los que usamos distribuciones de 64 bits encontraremos un problema como es ya habitual.

AMD64

Si corres algún ejemplo de opencv en processing sobre 64bits puedes encontrar un error del tipo:

!!! required library not found : /usr/lib/libOpenCV.so: /usr/lib/libOpenCV.so: wrong ELF class: ELFCLASS32 (Possible cause: architecture word width mismatch)

Si has visto mis post anteriores ya sabrás cual es el problema, tenemos que encontrar un libOpenCV.so compilado para 64bits, pero esta vez la solución fué un poco más “elaborada”, ya que este paquete no existe en los repositorios, fué un paquete compilado especialmente para la implementación de OpenCv en Processing.

Tendremos entonces que compilarlo de las fuentes que se incluyen en el paquete de lka librería que descargamos. Para una solución más sencilla subí el archivo compilado a mi servidor, así que lo pueden descargar de aquí: libOpenCV.so y reemplazar el existente en processing-1.0.9/libraries/OpenCV/library. Con esto queda solucionado y podrás utilizar opencv en 64bits sin problema.

Si quieres compilarlo estos son los pasos que yo seguí, para evitar compilar las clases, lo que hize fué extraer del archivo processing-1.0.9/libraries/OpenCV/library/OpenCV.jar los archivos Bob.class y OpenCV.class, con cualquier gestor de compresión de archivos lo puedes hacer, y los copié en processing-1.0.9/libraries/OpenCV/source/java/hypermedia/video luego desde consola

cd processing-1.0.9/libraries/OpenCV/source/java
javah -jni hypermedia.video.OpenCV

esto nos genera un fichero cabecera hypermedia_video_OpenCV.h, lo movemos a processing-1.0.9/libraries/OpenCV/source/cpp y compilamos la libreria libOpenCV.so
mv ./hypermedia_video_OpenCV.h processing-1.0.9/libraries/OpenCV/source/cpp
cd processing-1.0.9/libraries/OpenCV/source/cpp
g++ -shared OpenCV.cpp -o libOpenCV.so -I/usr/include/opencv/ -I/usr/lib/jvm/java-1.6.0-openjdk/include/ -lcv -lhighgui -fPIC

esto nos genera la librería libOpenCV.so que podemos copiar a processing-1.0.9/libraries/OpenCV/library reemplazando la anterior, y listo!! OpenCV funcionando.

Como recordarán para que funcionara processing en 64bits antiguamente teníamos que hacer una par de cosas, primero tocaba instalar jikes y reemplazar el que incluía processing con éste, esto ya no es necesario. Posteriormente tocaba reemplazar el java que venía incluído con uno nativo, cosa que permite usar el sun-jdk o el open-jdk, como lo mecioné anteriormente.

Ahora si descargas processing, que a la fecha su versión es la 1.0.9, verás que funciona perfectamente sin hacerle ningún cambio, lo cual es una muy buena noticia. Pero, como parte del combo yo instalo la librería GSVideo, verás que comienzan los problemas.

GSVIDEO 0.6

Al descargar e instalar la última versión (gsvideo-0.6-pre0.zip a la fecha), verás que processing nos vota un error del tipo:

Exception in thread “Animation Thread” java.lang.UnsatisfiedLinkError: Unable to load library ‘gstreamer-0.10′: /usr/lib/libgstreamer-0.10.so.0.22.0: wrong ELF class: ELFCLASS64

Como bien lo dice (o podrán intuir) el problema radica en la arquitectura de 64bits. Pero ¿porqué presenta este problema si GSVideo es una librería multiplataforma?, la respuesta es simple, en realidad el problema está en que gsvideo requiere de gstreamer instalado, es decir nativo, de 64bits, y cuando es llamado por processing lo procesa dentro de un java de 32bits lo cual genera la incompatibilidad.

Para solucionarlo volvemos a la opción de instalar un jdk y reemplazar el existente en processing por este. Para esto podemos seguir las instrucciones que escribí aquí. Tengan en cuenta que aunque las instrucciones son para el open-jdk, también son válidas para el sun-jdk si es de su preferencia.

Con esto volvemos a ejecutar nuestros ejemplos de GSVideo en processing y ya no tendremos ningún problema.

OpenGL

Podríamos pensar que ya está listo nuestro processing para trabajar, pero no es así, si volvemos a probar todo encontraremos un nuevo problema: lo que antes probamos con la librería OpenGL ya no funciona, ¿porqué?.

Si nos fijamos el error que ahora vota es muy similar al anterior de GSVideo:

Exception in thread “Animation Thread” java.lang.UnsatisfiedLinkError: /opt/processing-1.0.9/libraries/opengl/library/libgluegen-rt.so: /opt/processing-1.0.9/libraries/opengl/library/libgluegen-rt.so: wrong ELF class: ELFCLASS32 (Possible cause: architecture word width mismatch)

Como podremos observar es un error nuevamente de arquitectura, pero esta vez nos dice “wrong ELF class: ELFCLASS32″, es decir, que la librería que encontró (libgluegen-rt.so), es de 32 bits y que eso es incorrecto. Pues si analizamos el cambio que hicimos nos daremos cuenta fácilmente del problema, al reemplazar el java que traía processing que era de 32 bits por el que nosostros instalamos que es de 64bits, generó la incompatibilidad con el opengl de 32bits que traía processing.

Entonces ¿cómo lo solucionamos?, pues de un modo similar al caso anterior, instalamos el paquete de opengl para java que es llamado jogl, y reemplazamos los archivos de processing/libraries/opengl/library/* con estos.

Para el caso de gentoo el paquete jogl se encuentra en el java-overlay, para las demás distribuciones no sabría decirles si existe un paquete precompilado, pero googleando se darán cuenta o en último caso está la posibilidad de compilarlo desde las fuentes.

Yo manejo los overlays con layman, así que estos fueron mis pasos:
layman -a java-overlay
echo "dev-java/jogl ~amd64" >> /etc/portage/package.keywords
echo "dev-java/gluegen ~amd64" >> /etc/portage/package.keywords
emerge -av jogl

Con esto ya tengo instalado jogl en mis sistema, lo cual generó los archivos:

/usr/lib64/gluegen/libgluegen-rt.so
/usr/share/gluegen/lib/gluegen.jar
/usr/share/gluegen/lib/gluegen-rt.jar
para dev-java/gluegen, que instaló como dependencia, y:

/usr/lib64/jogl/libjogl_awt.so
/usr/lib64/jogl/libjogl.so
/usr/share/jogl/lib/jogl.jar
para dev-java/jogl.

Ahora lo único que tendremos que hacer es copiar estos archivos a processing-1.0.9/libraries/opengl/library/ reemplazando los que se encuentren allí.

Con esto ya deberíamos tener funcionando processing completo sobre amd64.

Ahora, la solución a usar la librería OpenGL. Como te habrás fijado cuando se intenta usar esta librería vota un error del estilo:

java.lang.UnsatisfiedLinkError: /self-installed/processing-0135/libraries/opengl/library/libjogl_drihack.so: /self-installed/processing-0135/libraries/opengl/library/libjogl_drihack.so: wrong ELF class: ELFCLASS32 (Possible cause: architecture word width mismatch)

Esto es claramente por usar librerías de 32 bits (wrong ELF class: ELFCLASS32 (Possible cause: architecture word width mismatch)), para solucionarlo podemos bajar la librería de soporte OpenGL para java (JOGL) de su página oficial.

Al final de la página encontrarás los links de descarga, hay versión para tanto para linux amd64 como para windows 64bits.

Una vez lo descarges todo lo que tendrás que hacer es descomprimirlo y copiar todo el contenido de la carpeta  /lib  a  processing/opengl/library/ , sobreescribe lo que ya exista.

——————————————————————–

Actualización:
En gentoo se encuentra el paquete jogl en el overlay java-overlay. Para usarlo instalamos layman, añadimos el overlay e instalamos.
emerge -av layman
layman -a java-overlay
emerge -av jogl
Portage va a pedir que desenmascares algunos paquetes que se encuentran el la rama ~amd64.
Esto nos instala jogl y gluegen como dependencia, luego copiamos o hacemos un enlace simbólico de los archivos instalados dentro de processing/libraries/opengl/library/ re-escribiendo los archivos originales.

Ecosistema Digital from Sergio Romero on Vimeo.

Ball Game from Sergio Romero on Vimeo.

Yo instalé el paquete java-1.6.0-openjdk-devel, que como lo mencioné entre líneas difiere del de sun, en que este es un jdk opensource.

Una vez instalado el jdk, se ubica la carpeta donde se instaló, generalmente los gestores gráficos de paquetes, como synaptic y adept, permiten ver los archivos instalados por dicho paquete, así podremos ubicar la carpeta raiz del jdk, que, para el caso del java-1.6.0-openjdk-devel sobre un Mandriva Free 2009 x86_64, se instaló en ‎/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64. Dentro de dicha carpeta tendrá que haber mímino una carpeta bin, una lib y una del jre.

Procederemos a borrar o mover la carpeta java del processing y hacer el link simbólico, para ello desde consola y como root.

rm -R /opt/processing-1.0.1/javaln -s /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64 /opt/processing-1.0.1/java

y listo tendremos nuestro processing funcionando. No olvides que para ejecutarlo en caso de dar algún error prueba con:

cd /opt/processing-1.0.0 && ./processing

Como novedad trae la implementación del método GSCapture.list(), para listar los dispositivos de captura conectados. Este método asume que el elemento de fuente es v4l2src, pero se le puede pasar el parámetro v4lsrc, GSCapture.list(“v4lsrc”). Además incluye la posibilidad de definir pipelines con la clase GSPipeline que terminen en filesink, para hacer captura a disco, un paso más cerca de GSMovieMaker.

También incluye unas facilidades de sintaxis, ya no es necesario emplear un array para escoger el dispositivo de captura en el constructor del objeto GSCapture, por ejemplo:

de esto:
cam = new GSCapture(this, 320, 240, new String[] {“device”}, new String[] {“/dev/video1″},15);

se pasó a esto:
cam = new GSCapture(this, 320, 240, “/dev/video1″,15);

Lo que ven en la imagen es un ejemplo de captura simple + el ejemplo ASCII video en Processing 1.0.1 + gsvideo 0.4.5 sobre un sistema Linux Mint Felicia (prácticamente un Ubuntu Intrepid), capturando de mi tarjeta de radio y tv Kworld Plus Lite PCI. Para lograrlo simplemente inicié Processing, luego tvtime en el canal que deseé, cerré tvtime y arranque el ejemplo de processing, y así toma la señal del dispositivo con el último canal sintonizado.

El método GSCapture.list() aún no me ha funcionado, pero seguiré probando y posteándo.

PD: probado en Mandriva Free x86_64 2009 y funciona perfectamente, aunque el método GSCapture.list() presenta el mismo error que en 32 bits.

Este excelente software de producción digital audiovisual lanza su primera versión estable.

Según parece la descarga estuvo disponible desde el 24 de este mes, y hubo record de descargas a tal punto que se saturó varias veces el servidor, pero bueno yo hasta ahora me entero y aquí esta la captura de Processing 1.0 sobre Sabayón GNU/Linux. Los colores de la interfaz cambiaron, y si alcanzar a ver el panel inferior notarán que también cambió el icono, no he tenido tiempo de probarlo mucho aún, pero siempre me ha parecido feo que la versión para linux incluya la librería video la cual no funciona en linux, solo en windows y mac, en fin para eso está GSVideo.

http://dev.mysql.com/downloads/workbench/