Planet

Bienvenid@s a mi blog, el cual lo dedicaré para informar sobre mis avances en el proyecto la cosateca.
La cosateca es mi proyecto fín de carrera, y a la vez lo presento al concurso universitario de software libre, pero…¿qué es una cosateca?
Hoy día tenemos en casa solemos tenemos multitud de herramientas y objetos que normalmente compramos para usarlas una vez y no volver a hacerlo hasta pasado mucho tiempo. Esto supone un gasto en la adquisición de una herramienta a la que se le da poca utilidad en la práctica. La cosateca viene a solucionar este problema ofreciendo un espacio en el que se almacenen herramientas que podrían ser solicitadas por las personas durante un tiempo limitado, tal y como sucede hoy día con las bibliotecas.
Para llevar a cabo tal proyecto, usaré como lenguaje de programación Python en la parte “funcional” de la aplicación, y HTML,CSS y demas tecnologias webs para la parte visual.
Para cualquier duda, opinión o sugerencia no lo dudes y escribela, que con mucho gustó la leeré y te responderé.

This is the first post of the Cormoran development blog. Cormoran will be a very fast and lightweight Object-Relational Mapper (ORM) written in Python.
Currently, it accessed a large number of information stored in databases and is necessary to make this process as quickly as possible. This data access is done through applications, and its development is slowed by differences between database engines and the need to learn an additional programming language (SQL, for example).
At this point an ORM accelerates development of applications using databases, but slows the access to information. In general, an application developed with an ORM is several times slower than the same application running SQL directly. For this reason, the Cormoran project aims to improve the speed of execution through a simple and powerful framework and the optimization of different database engines.
Cormoran will be an open source software released under GNU GPL license.

Conforme a lo planificado, en el ciclo #2 del desarrollo se trabajará la previsualización de archivos introducidos por línea de comandos. Al pasarle un único archivo como argumento al programa, éste mostrará durante un tiempo determinado una ventana con la previsualización del archivo.
Sin embargo, este ciclo puede llevar más tiempo del deseado. Esto es debido a la necesidad de implementar 2 funcionalidades que en un principio se pueden ver como una sola, tal como refleja la lista, pero que entrañan una dificultad considerable:

• Detección del tipo de archivo y creación de la vista previa acorde al tipo
• Visualización de la vista previa generada

La primera de ellas conlleva un esfuerzo extra, ya que implica la utilización de diferentes utilidades y librerías para la obtención de vistas en miniatura para cada tipo de archivo. Dependiendo del tipo de archivo, se mostrará lo siguiente:

• Imágenes: miniatura
• Audio: reproducción desde un punto determinado (inicio o medio)
• Vídeo: gif animado con capturas
• Texto: resumen del fichero (número de líneas, palabras, etc…)
• Pdf: gif animado con páginas
• Código fuente: lenguaje de programación y líneas
• Archivos comprimidos: número de archivos y algoritmo de compresión

Como es evidente, en la lista de tipos de archivos no se mencionan gran parte. Se pretenderá dar cabida al mayor número posible de ellos, potenciando en un principio los anteriores.
En cuanto a la segunda tarea, se necesita incorporar a la aplicación una pequeña ventana gráfica que muestre la vista en miniatura obtenida. Se utilizará la librería gtkmm (GTK para C++). Debido al desconocimiento de los bindings utilizados por ella, se necesitará un tiempo extra de aprendizaje.
Como se puede ver, el tiempo previsto para un único ciclo de desarrollo es demasiado grande. Sin embargo, existe una gran dependencia de las dos subtareas descritas. Por tanto, se realizarán de forma conjunta aunque ello conlleve un tiempo mayor.
Se procederá en breve a la descripción e implementación del test correspondiente al ciclo #2.

Con el fin de recapitular el trabajo realizado en cada ciclo, se realizará un pequeño resumen de las decisiones tomadas y de los problemas surgidos a la hora de la implementación.
En este ciclo, el primero del desarrollo, se ha tratado el reconocimiento de opciones introducidas al programa por línea de comandos. En un principio se reconocen únicamente las opciones de:

• –time, -t : tiempo que dura la previsualización de archivos individuales
• –noaux, -n : no mostrar un panel auxiliar con la vista en miniatura de archivos en tiempo real (objetivo de uno de los últimos ciclos)
• –version : mostrar la versión del programa
• –help : mostrar la ayuda del programa

En un futuro, se añadirán opciones para cambiar el tamaño y colocación de las ventanas, no previsualizar archivos de un tipo determinado, etc… Esto no conllevará apenas trabajo ya que para leer las opciones se ha utilizado las funciones “getopt”, un estándar en estas tareas, que permiten añadir nuevas opciones de forma sencilla.
Además, se ha confeccionado la estructura del código del proyecto, así como los archivos auxiliares Makefile, Readme, License, ChangeLog y Authors.

Tras varios días de trabajo, se ha terminado con el primer ciclo de desarrollo. Lo primero que se llevó a cabo fue la implementación del reconocedor de opciones introducidas por línea de comandos. Tras ello, se probó que todo funcionaba de acuerdo al test descrito en el post anterior. Por último, se refinó y estructuró el código escrito y se volvió a comprobar que funcionaba correctamente a pesar de las modificaciones.
Queda, por tanto, finalizado el ciclo #1 de la implementación con éxito.

As I stated in the previous post, we are considering integrating Boost.GIL into GNU/Psychosynth to constitute its foundations for audio processing. I have writen a very long email to my Master Thesis advisor describing the rationale behind this and I then thought that it would be nice if all the community could participate in the debate.
I turned the email into a wiki page.
It is in Spanish only. If you can read it and are familiar with these topics, I would thank a lot your suggestions and contributions.

Acabo de darme cuenta de porque casi nadie hace baterías de test de casi nada, y no es porque no lo enseñan en la universidad... Acabo de hacerme la batería de test de la función ftruncate (es en la que mas modificaciones he hecho ultimamente con las optimizaciones. Ademas, por algun sitio tenia que empezar...) siguiendo las indicaciones de funcionalidad y errores de OpenGroup y me ocupa 254 lineas... y eso que solo he comentado lo que hace cada test, que ahora me toca programarlo :-/ Ahora bien, con la paliza que me voy a pegar, ¿que deberia hacer, acceder a las funciones a bajo nivel, o hacerlo rollo shell script y que ya que me pego la paliza con los test al menos que sirva para que otros no tengan que implementarselos tambien?Y en plan recursivo... ¿deberia hacer una bateria de test para la bateria de test para testear que la bateria de test testea correctamente? X-D

Hello mates,
Recently I have been announcing in several places like the mailing lists and the last GNU Hackers Meeting (a 5 minutes video presentation availible through the link) that big changes are going to happen in GNU Psychosynth during this year. This evolution proccess has just started, due to the following facts:

• GNU Psychosynth is the topic of my PFC –the Spanish equivalent of a Mater’s Thesis.
• GNU Psychosynth is now a contestant in the fifth edition of the Spanish Free Software contest for university students.

This means that a lot of workforce is going to be put in this project. I would like to be able to implement most of the features that have been delayed for a long time: hierarchical patches that can be saved and loaded, MIDI and some limited (at first) sequencing support, plugins and LADSPA support among others.
This implies working very hard in the base framework and API compatibility will be broken and that these changes will not trascend to the 3D client. Actually, if everything goes well a new UI will be built on top of QT or GTK+Clutter that supports Meego devices and multitouch interfaces. From our experience with the program, the only thing that made the 3D interesting was that it made the interface “zoomable”. The new UI will be 2D but zoomable, improving actual usability and opening new grounds for experimentation with tangible interfaces.
Many interesting things will be explored in the new code. One of them is the new upcoming C++ standard. We will be using C++0x features as soon as they are supported by the latest GCC stable release. This means that one will have to keep in sync with GCC upstream to compile, but opens new grounds in code quality, reduces dependency with Boost and will make us contribute with the Free Software support of C++0x as we discover bugs in the implementation –like I sadly discovered today that one can not store std::unique_ptr instances in the current implementation of std::map as in GCC 4.4.
Also, we are going to adapt the Boost Generic Image Library to work with audio signals and constitute the foundations of our sound data structures and static algorithms. This will be a unique approach compared to other audio software and hopefully provide a more efficient, compatible, generic and bug free code base.
Let’s mention that we will be using a new forge during the following months, as required by the Free Software Contest. I will use that for task management and other forge activities but you can still access the former BZR repository –I will be developing using BZR still and only mirror to the new SVN.
Finally, the project will have the support of the ArtQuimia Music Production School, which will give us insights from a music professional perspective and lend professional music hardware for testing.
I hope that you like the new direction that the software is taking and that you actively participate in the mailing list, IRC and other means to give us ideas about how to build the best live audio performance software ever!

Aunque he tardado algun tiempo en actualizar cosas debido a lo saturada que tengo la agenda este año entre el trabajo y la carrera (aunque segun he visto en los blogs de los demas no soy el unico, bien por nosotros :-) ) al fin ha llegado el viernes tarde y para desconectar de una semana demasiado corta en tiempo (se me ha pasado volando sin darme cuenta, con lo que me jode...) y demasiado larga en estress en la que incluso he perdido mi maravilloso Android (snif...) me he puesto a darle un pequeño empujon al proyecto y a falta de uno hay dos: primero, ya tenemos links simbolicos, y segundo, ya tenemos una plataforma seria de plugins, aunque por ironico que parezca no por culpa del codigo para generar los links simbolicos, sino por culpa de la creacion de su tabla.En primer lugar, los links simbolicos tienen sus propias funciones dentro de FUSE (symlink para crearlos y readlink para parsearlos), los cuales hasta ahora no las habia implementado porque no eran necesarias para el nucleo del sistema de archivos, asi que como primera aproximacion al sistema de plugins decidi mapearlas directamente dentro de la clase, al igual que he hecho con sus equivalentes en la base de datos.Sin embargo para la creacion de la tabla no podia mapear ninguna funcion sino que tenia que ejecutarse cuando terminara de hacerse la base de datos entera, asi que buscando algun ejemplo de como hacer un sistema de notificacion de eventos en python (podia hacermelo yo y los ejemplos que encontre eran muy parecidos, pero queria ver si ya habia algo bien hecho y probado que poder reutilizar. Al menos esa es una de las ventajas del software libre, que si ya hay algo bien hecho no hay porque duplicar esfuerzos, ¿no?) y entre todo lo que encontre el que mas se parecia a lo que necesitaba para el sistema de plugins fue este codigo. Sin embargo aparte de que no me gustaba mucho como tenia implementado el sistema de carga de plugins (¿un archivo de configuracion? Por favor... con lo comodo y practico que es tener un directorio desde donde cargarlos al igual que se hacia con las extensiones del sistema del MacOS Classic...) tambien hacia referencia a PyDispatcher, el cual tambien hacia referencia a Louie. ¿Cual escoger? Al final como muchas otras veces en que tengo alternativas de codigo y me da igual uno que otro, deje que Ubuntu eligiera por mi para ver cual era el metodo mas estandar, y como Louie era el unico que tenia paquetes dentro de los repositorios oficiales, pues me decante por el :-)Asi que aunque ha sido por algo completamente accidental, ahora tenemos un sistema de notificacion de eventos bastante avanzado. Puede que sea un problema con vistas a una futura implementacion como sistema de ficheros nativo (mas librerias externas, mas problemas de integracion), pero como apenas todavia estamos en las primeras fases de desarrollo todavia hay tiempo de modificarlo mas adelante si hace falta. De momento en cualquier caso hara falta una plataforma de plugins mas solida que la que tengo actualmente de mapear las funciones directamente, asi que a lo mejor con suerte incluso consigo matar dos pajaros de un tiro y consigo desarrollar un sistema de plugins lo suficientemente bueno como para que me lo incluyan en la libreria estandar de python (y eso si que seria un puntazo... ;-) ).Proximo paso, aprender un poco mas como funciona Louie y desarrollar el plugin de log :-D

Hoy debido a la huelga he decidido quedarme en casa, no por apoyarla y no ir a trabajar, sino que ayer me hice una copia de seguridad y he trabajado desde aquí debido al miedo que tenia a los piquetes (no estoy de acuerdo con las reformas, pero tampoco con los sindicatos como la mayoría de la población).Al final ha sido mas ruido que otra cosa y podría haber ido sin problemas, pero el caso es que como he terminado pronto me he puesto a darle un empujón al sistema de archivos y bueno... hemos alcanzado otro checkpoint :-D Ahora modulo de log esta operativo, he limpiado el modulo de symlinks (ya no hay funciones mapeadas, todas son lanzadas por eventos gracias a louie :-) ) y empieza a discernirse un borrador de como implementar el sistema de plugins. Esto ultimo es debido a que en el modulo de log no tenia manera de tener una referencia para acceder a la base de datos, ya que antes accedía a través del objeto del sistema de archivos (como se puede ver en symlinks, aunque lo voy a cambiar en breve para unificarlo) y ahora al tener el objeto otra estructura perdía toda referencia a ella, y guardarlo en una variable global me decía el bicho que nanai. ¿Como hacerlo? Pues construyendo una clase. Era reacio a hacerlo a pesar de mi gusto por la orientación a objetos porque entonces ya no bastaría con cargar el modulo para tenerlo habilitado, sino que ademas tendría que meterme dentro, leer la clase y crear un objeto, y eso ya es mucho engorro. Por el momento lo he solucionado con la chapuza de crear una instancia del objeto al final del modulo (niños, no miréis :-P ) pero la ventaja de usar orientación a objetos es que mi idea de en un futuro implementar un sistema de dependencias entre plugins (inspirado en APT para mas señas... ;-) ) va a ser mucho mas sencillo :-)En fin, en cualquier caso el modulo de logs ya esta listo, aunque tendré que diseñar algún método para agrupar los eventos y así poder discernir cuales son validos para loggear y cuales no, porque cuando ya estaba operativo con solo hacer un ls me ha salido todo esto...[piranna@Tontodelculo:~/Proyectos/FUSE/PirannaFS/test]> sqlite3 db.sqlite SQLite version 3.6.22Enter ".help" for instructionsEnter SQL statements terminated with a ";"sqlite> select * from log;|__init__|DB|2010-09-29 18:34:31||{'self': , 'db_name': '../test/db.sqlite'}|||readlink|FileSystem|2010-09-29 18:34:32||{'path': '/nano_link.txt', 'self': }|||readlink|FileSystem|2010-09-29 18:34:32||{'path': '/nano_link.txt', 'self': }|||readlink|FileSystem|2010-09-29 18:34:32||{'path': '/nano_link.txt', 'self': }|||readlink|FileSystem|2010-09-29 18:34:33||{'path': '/nano_link.txt', 'self': }|||readlink|FileSystem|2010-09-29 18:34:33||{'path': '/nano_link.txt', 'self': }|||readlink|FileSystem|2010-09-29 18:34:33||{'path': '/nano_link.txt', 'self': }|||readlink|FileSystem|2010-09-29 18:34:33||{'path': '/nano_link.txt', 'self': }|||readlink|FileSystem|2010-09-29 18:34:33||{'path': '/nano_link.txt', 'self': }|||readlink|FileSystem|2010-09-29 18:34:33||{'path': '/nano_link.txt', 'self': }|||readlink|FileSystem|2010-09-29 18:34:34||{'path': '/nano_link.txt', 'self': }|||readlink|FileSystem|2010-09-29 18:34:34||{'path': '/nano_link.txt', 'self': }|||readlink|FileSystem|2010-09-29 18:34:34||{'path': '/nano_link.txt', 'self': }|||readlink|FileSystem|2010-09-29 18:34:34||{'path': '/nano_link.txt', 'self': }|||readlink|FileSystem|2010-09-29 18:34:34||{'path': '/nano_link.txt', 'self': }|||readlink|FileSystem|2010-09-29 18:34:34||{'path': '/nano_link.txt', 'self': }|||readlink|FileSystem|2010-09-29 18:34:34||{'path': '/nano_link.txt', 'self': }|||readlink|FileSystem|2010-09-29 18:34:35||{'path': '/nano_link.txt', 'self': }|||readlink|FileSystem|2010-09-29 18:34:35||{'path': '/nano_link.txt', 'self': }|||readlink|FileSystem|2010-09-29 18:34:35||{'path': '/nano_link.txt', 'self': }|||readlink|FileSystem|2010-09-29 18:34:35||{'path': '/nano_link.txt', 'self': }|||readlink|FileSystem|2010-09-29 18:34:35||{'path': '/nano_link.txt', 'self': }|||readlink|FileSystem|2010-09-29 18:34:35||{'path': '/nano_link.txt', 'self': }|||readlink|FileSystem|2010-09-29 18:34:35||{'path': '/nano_link.txt', 'self': }|||readlink|FileSystem|2010-09-29 18:34:36||{'path': '/nano_link.txt', 'self': }|||readlink|FileSystem|2010-09-29 18:34:36||{'path': '/nano_link.txt', 'self': }|||readlink|FileSystem|2010-09-29 18:34:36||{'path': '/nano_link.txt', 'self': }|||readlink|FileSystem|2010-09-29 18:34:36||{'path': '/nano_link.txt', 'self': }|||readlink|FileSystem|2010-09-29 18:34:36||{'path': '/nano_link.txt', 'self': }|||readlink|FileSystem|2010-09-29 18:34:36||{'path': '/nano_link.txt', 'self': }|||readlink|FileSystem|2010-09-29 18:34:36||{'path': '/nano_link.txt', 'self': }|||readlink|FileSystem|2010-09-29 18:34:37||{'path': '/nano_link.txt', 'self': }|||readlink|FileSystem|2010-09-29 18:34:37||{'path': '/nano_link.txt', 'self': }|||readlink|FileSystem|2010-09-29 18:34:37||{'path': '/nano_link.txt', 'self': }|||readlink|FileSystem|2010-09-29 18:34:37||{'path': '/nano_link.txt', 'self': }|||readlink|FileSystem|2010-09-29 18:34:37||{'path': '/nano_link.txt', 'self': }|||readlink|FileSystem|2010-09-29 18:34:37||{'path': '/nano_link.txt', 'self': }|||readlink|FileSystem|2010-09-29 18:34:37||{'path': '/nano_link.txt', 'self': }|||readlink|FileSystem|2010-09-29 18:34:38||{'path': '/nano_link.txt', 'self': }|||readlink|FileSystem|2010-09-29 18:34:38||{'path': '/nano_link.txt', 'self': }|||readlink|FileSystem|2010-09-29 18:34:38||{'path': '/nano_link.txt', 'self': }|||readlink|FileSystem|2010-09-29 18:34:38||{'path': '/nano_link.txt', 'self': }|||readlink|FileSystem|2010-09-29 18:34:38||{'path': '/nano_link.txt', 'self': }|||readlink|FileSystem|2010-09-29 18:34:39||{'path': '/nano_link.txt', 'self': }||sqlite>Si, efectivamente, FUSE hace muchas llamadas al sistema... ;-)P.D.: entrada libre de faltas de "hortográfia" ;-) dedicada a Pau y su muy buen consejo :-)