Blog de Pigmeo

El II Concurso Universitario de Software Libre, en el que el proyecto Pigmeo participaba, ha terminado con estos resultados.

De entre los 95 proyectos y 6 finalistas, Pigmeo ha quedado finalista de la categoría “Mejor Proyecto Innovador”, aunque no ha conseguido el primer premio, que se lo llevó el robot R4P. Quiero dar la enhorabuena también a Dato por su proyecto Minirok, a Antonio por XMLEye, a Juan Pedro por Psychosynth y a Juan Belón por zenphp.

Aunque el concurso haya terminado, el desarrollo del proyecto continuará en el sitio web oficial de Pigmeo. Os recomiendo que os apuntéis a la lista de correo de anuncios sobre el proyecto para mantenerse al día.

Resulta que Pigmeo 0.0.1 tenía varios fallos bastante graves y no me había dado cuenta, así que me veo obligado a publicar esta nueva versión que solo arregla esos fallos y no añade mucho más (aunque sí tiene varias cosas nuevas).

Bugs resueltos:

• La compilación no funcionaba correctamente (se requería Mono.Cecil.dll antes de iniciar la compilación, pero el script copiaba el archivo tras la compilación, por lo que daba un error de compilación)
• Pigmeo Compiler no se podía ejecutar en Windows
• La gestión de excepciones descontroladas (unhandled exceptions) no funcionaba correctamente en Windows cuando se utilizaba la interfaz de WinForms. Ahora funciona perfectamente en Windows y en Linux, además lo hace de manera más limpia

Nuevas características:

• Usando Pigmeo Compiler podemos mostrar información sobre un ejecutable de .NET (archivos .exe) antes de compilarlo, tanto desde la consola como desde la interfaz de WinForms
• Cuando salta una excepción desconocida mientras estamos ejecutando la interfaz WinForms, se genera un resumen muy detallado del error y el estado de la aplicación antes de que saltase la excepción, y se permite enviar por e-mail a los desarrolladores
• Se cambió completamente la forma de almacenar los textos de los distintos idiomas. Ahora todo puede traducirse a cualquier idioma mucho más fácilmente
• Añadido un programa de ejemplo escrito en C# y en Visual Basic .NET. El código fuente está acompañado por el .exe y el código en lenguaje ensamblador generado por Pigmeo Compiler

Página de la nueva versión: Pigmeo 0.0.2

Antes de compilar un archivo .exe para convertirlo a lenguaje ensamblador, podemos obtener información sobre el archivo, tanto desde la consola como desde la interfaz WinForms (pulsando en el botón que tiene un icono de información).

Cuando se soporten más interfaces gráficas será muy simple hacer que desde ellas también se pueda mostrar esta información.

Obteniendo información del archivo .exe desde la consola

Es una versión alpha, no contiene suficientes características para ser usada para crear casi ningún programa útil.

Sólo necesitas tener instalada una máquina virtual de .NET (CLR), como Mono o Microsoft .NET, y debería funcionar en cualquier sistema operativo para el cual haya disponible un CLR de .NET. Por el momento se ha comprobado que funciona en Linux y en Windows.

Soporta las siguientes características:

• Arquitectura PIC14
• Modelo PIC16F716
• Acceder a variables estáticas definidas tanto en el propio programa como en librerías externas a las que se hace referencia
• Se soportan más de la mitad de los registros disponibles en el PIC16F716
• Forzar al compilador a que llame a ciertas variables de determinada manera, usando el Custom Attribute [AsmName()]
• Forzar al compilador a que almacene ciertas variables en posiciones determinadas de memoria, usando el Custom Attribute [Location()]
• Asignar valores constantes a variables estáticas de tipo uint8/byte
• Copiar variables estáticas de tipo uint8/byte
• Sumar dos variables de tipo uint8/byte
• Sumar dos variables de tipo uint8/byte con comprobación de desbordamiento
• Restar dos variables de tipo uint8/byte
• Bucles infinitos
• Instrucción goto
• Posibilidad de elegir qué hacer cuando el programa termina:
• Quedarse en un bucle infinito sin hacer nada
• Reiniciar el programa
• Posibilidad de elegir cómo implementar el soporte para excepciones:
• No se permiten excepciones
• Terminar el programa cuando salte cualquier excepción
• Interfaz para la línea de comandos
• Interfaz gráfica WinForms

Toda la información sobre esta versión está disponible en http://en.pigmeo.org/wiki/Pigmeo_0.0.1

Compilando desde linux usando la interfaz de WinForms [ogg + theora, 5MiB]
Compilando desde linux usando la interfaz de WinForms [avi + xvid, 4,9MiB]

Compilando desde la consola en linux [ogg + theora, 4,7MiB]
Compilando desde la consola en linux [avi + xvid, 5,1MiB]
Este último vídeo también incluye algunos ejemplos de los parámetros que se le pueden pasar al compilador, y se ve cómo automáticamente detecta el idioma del sistema (que en la consola se configura mediante variables de entorno).

Programa de ejemplo escrito en Visual Basic .NET

Código fuente en lenguaje ensamblador generado por Pigmeo Compiler

Y un pantallazo de Pigmeo Compiler compilando este programa desde linux, utilizando la interfaz de WinForms:

Compilando el siguiente programa escrito en C#: ejemplo001.cs

El compilador de C# que más nos guste nos genera el .exe (que hace referencia a PIC16F716.dll) y Pigmeo Compiler lo convierte a lenguaje ensamblador: ejemplo001.asm. Podemos fijarnos en que se compiló para el PIC16F716 (sin especificarlo a la hora de utilizar Pigmeo Compiler), ya que el compilador de pigmeo automáticamente detecta la “librería de dispositivo” que se utilizó cuando el programa en C# fue compilador a .exe y sin intervención del usuario sabe para qué arquitectura y qué rama/dispositivo estamos compilando, en este caso la arquitectura es PIC14 y el dispositivo es PIC16F716.

Y con mpasm, gpasm o cualquier otro programa ensamblador (que sea compatible) para PICs de 8 bits generamos el archivo binario (.hex) que podemos grabar en nuestro microcontrolador.

He preparado un Custom Attribute para que los desarrolladores de Pigmeo puedan marcar métodos/funciones indicando que ese método aún no está implementado, debe ser reescrito o faltan cosas por hacer. Este método se utiliza en el desarrollo de Mono (aunque no he utilizado nada de código de Mono, ni siquiera lo he visto) y me parece útil para encontrar más fácilmente las tareas pendientes pero que no son lo suficientemente importantes o urgentes como para reportarlas como un bug, además de servir como complemento al bugzilla.

En la siguiente imagen podemos ver cómo se marcan las funciones con el atributo PigmeoToDo, que obviamente se compilan y se integran en los metadatos de los ejecutables y las librerías, es decir, los atributos son datos que se almacenan en pigmeo-compiler.exe, Pigmeo.Internal.dll, Pigmeo.dll, PIC16F716.dll… no son variables accesibles desde otras partes del programa.

un método marcado con el Custom Attribute PigmeoToDo

Entonces… ¿cómo sabemos qué métodos poseen el atributo PigmeoToDo?
He implementado una clase (Pigmeo.Internal.FindPigmeoToDos, dentro de la librería Pigmeo.Internal.dll) que puede utilizarse desde cualquier otro programa del proyecto Pigmeo para cargar las librerías y los ejecutables uno a uno y mostrar las funciones marcadas con PigmeoToDo.

De momento el compilador puede llamarse con el parámetro todo o ToDo y conseguimos que el compilador se lea a sí mismo en tiempo de ejecución y nos muestre las cosas que faltan por hacer:

(Este artículo es una traducción de How Pigmeo Works, parte de la documentación oficial para desarrolladores de Pigmeo. Al contrario que la documentación para usuarios, la doc. para desarrolladores sólo se publicará en inglés)

Para entender cómo funciona Pigmeo, antes debemos entender cómo funciona .NET.

Cómo funciona .NET

Cuando quieres escribir una aplicación en C#, Visual Basic .NET, C++/CLI o cualquier otro lenguaje de .NET, lo primero que haces es escribir el código fuente. Este código fuente se compila a CIL/IL/MSIL, el lenguaje intermedio de .NET (parecido a otros tipos de lenguaje ensamblador), y se almacena en archivos .exe que contienen bytecodes de CIL (al igual que ocurre en java). Estos bytecodes son representaciones binarias del juego de instrucciones definido por CIL. Cabe destacar que estos archivos .exe no son ejecutables de Windows aunque tengan la misma extensión.

Los bytecodes de CIL almacenados en los ejecutables de .NET (los archivos .exe) se compilan a código máquina por el CLR (cuando el usuario lo ejecuta), la máquina virtual de .NET, y entonces son ejecutados por el procesador. Hay que tener en cuenta que CIL no está orientado a ninguna arquitectura de hardware en particular, por lo que cualquier máquina virtual (CLR) en cualquier arquitectura y cualquier sistema operativo puede compilar y ejecutar los archivos ejecutables de .NET.

Algunas implementaciones de .NET son Mono, la implementación de .NET hecha por Microsoft, DotGNU, Rotor…

Por lo tanto funciona de la siguiente manera:
[C# / VB.NET / C++/CLI / Boo / Chrome / J# / Nemerle / Ruby.NET / IronScheme / IronPython / IKVM.NET / cualquier otro lenguaje que sea compilado a CIL] => compilador => .exe + librerías en el GAC => Máquina Virtual (CLR) => código máquina => procesador

Cómo funciona Pigmeo

Si queremos ejecutar nuestra aplicación en un microcontrolador o algún tipo de sistema embebido, podemos ejecutar un CLR en él y dejar que sea el CLR quien compile y ejecute nuestros bytecodes en CIL (el archivo .exe), como lo hace el .NET Micro Framework, pero requiere muchísimos recursos, así que Pigmeo genera el código máquina en un ordenador común.

Desarrollando aplicaciones en .NET para microcontroladores usando Pigmeo, se escribe el código fuente y se compila a bytecodes de CIL de manera normal. Después Pigmeo Compiler toma el archivo .exe, lo junta con las librerías necesarias y convierte solamente las partes útiles de estos archivos a lenguaje ensamblador para la arquitectura de destino.

Una vez que tenemos nuestra aplicación compilada a lenguaje ensamblador ya podemos utilizar un programa ensamblador para convertirlo a código máquina listo para ser enviado al microcontrolador a través de un programador (como PIC³PROG o PICkit).

Cuando la aplicación haya sido grabada en el microcontrolador ya puede ejecutarse normalmente.

Como resumen:
[C# / VB.NET / C++/CLI / Boo / Chrome / J# / Nemerle / Ruby.NET / IronScheme / IronPython / IKVM.NET / cualquier otro lenguaje que sea compilado a CIL] => compilador => .exe + librerías en el GAC => Pigmeo Compiler => lenguaje ensamblador para la arquitectura de destino => programa ensamblador => código máquina => cualquier programador/grabador de microcontroladores => procesador del microcontrolador

Para facilitar la depuración o para cualquiera que quiera ver el código fuente generado por Pigmeo Compiler he implementado un sencillo editor de texto con resaltado de sintaxis para lenguaje ensamblador, que abre automáticamente el archivo con el que estemos trabajando.

Vídeo de ejemplo del editor de lenguaje ensamblador [ogg + theora]
Vídeo de ejemplo del editor de lenguaje ensamblador [avi + xvid]

La GUI de WinForms corriendo en Gentoo Linux, sobre Mono 1.2.6. Versión 0.0.9999-SVN de Pigmeo Compiler:
Vídeo de ejemplo de Pigmeo Compiler [ogg + theora]
Vídeo de ejemplo de Pigmeo Compiler [avi + xvid]

Se ve cómo se elige un archivo a ejecutar, automáticamente se configuran las rutas para los archivos de destino; luego configuramos para que se muestren los mensajes de depuración y cambiamos entre español e inglés un par de veces para que se vea cómo los controles se adaptan a cada idioma. Se vuelve al panel de compilación y compilamos.

Algunos mensajes de salida están en inglés y otros en español. Esto es así porque todo lo relacionado con los desarrolladores de pigmeo (incluyendo los mensajes de depuración) solamente está en inglés, ya que los usuarios finales no tienen por qué ver estos mensajes, en cambio los textos verbose (los precedidos por “INFO:”) se muestran en español (salvo que aún no estén traducidos).

Creo que para ser una versión de desarrollo (aún no hay ninguna release estable) no está nada mal.

Ya he añadido todas las opciones de configuración del compilador a la interfaz WinForms.

El resultado (corriendo en linux):

Como se ve, lo he traducido todo al español. El idioma puede elegirse desde esta misma ventana (está al final del panel, se ve en la segunda imagen) y los controles cambian de posición y se redimensionan automáticamente según el idioma, así que la propia interfaz gráfica se adapta y no se necesitan distintas versiones para cada idioma.

La primera interfaz gráfica que voy a implementar es la de WinForms, que aunque ni es estándar ni libre, sí es la más fácil de portar ya que Mono la soporta casi perfectamente en linux.

Una imagen del compilador utilizando la interfaz de WinForms en Gentoo Linux:

La misma versión del compilador, usando exactamente la misma interfaz y utilizando el mismo binario, sin necesidad de recompilarlo siquiera, corriendo en Windows XP con estilo clásico:

Y de nuevo en Windows XP pero esta vez utilizando el estilo de Windows XP:

Además el compilador automáticamente ha detectado que mi sistema está configurado en español, así que la interfaz se muestra en español (el idioma puede configurarse en tiempo de ejecución desde el panel de configuración del compilador), como puede leerse en el menú “Archivo”, pero como todos los demás strings aún no están traducidos entonces se muestran en inglés.

Los que programamos en C# estamos tan acostumbrados a usar Console.WriteLine() para todo que a veces se nos olvida que existen las entradas y salidas estándares.

Console.WriteLine() y Console.Out.WriteLine() escriben un string a la salida estándar seguido de un caracter de fin de línea. Console.In es un objeto TextReader que nos permite leer fácilmente la entrada estándar. Console.Error.WriteLine() es quien nos permite mostrar un string en una línea de la salida de error.

He cambiado el código necesario para que los mensajes de error que se muestren por consola se redirijan a la salida de error, y tanto los warnings como los mensajes de aviso y depuración se muestren en la salida estándar. Cuando estamos en una interfaz gráfica todos estos mensajes se muestran mezclados en un solo TextBox, y además se envían inevitablemente (por elección de diseño, no por culpa de la implementación) a las salidas estándar y de error. De paso he agrupado los métodos que gestionan el envío de mensajes entre la lógica de compilación y las interfaces gráficas, de manera que esté todo bien organizado y sólo haya un sitio desde el que realmente se llamen a las entradas y salida estándar.

Por otro lado, y siguiendo mi intención de hacer el compilador tan portable como sea posible, lo he implementado todo de manera que si en el futuro se añaden al compilador interfaz ncurses o para el framebuffer, los mensajes que vayan a la salida estándar y de error no se muestren en la consola.

Aunque he mantenido la lógica del compilador bien separada de las interfaces gráficas, lo que sí he hecho es integrar todas las interfaces dentro del mismo ejecutable. Al principio mi intención era generar una librería para cada interfaz gráfica y que ésta se cargase según los parámetros pasados desde la consola, o bien crear una librería que incluyese la lógica del compilador y además un ejecutable por cada interfaz existente, debiendo llamar a ejecutables distintos según la interfaz deseada. El problema es que para mostrar los avisos y errores generados por el compilador, y mostrar claramente el porcentaje de progreso de la compilación me vi obligado a integrar tanto la lógica de compilación como las interfaces en el mismo ejecutable, a no ser que quisiese emplear temporizadores para ir actualizando el progreso de compilación y mostrarlo de manera actualizada en la pantalla.

Entonces surgió otro problema: ¿qué ocurre cuando ejecutamos el compilador y en el sistema no hay soporte para cierta librería gráfica, o estamos en una consola, sin X11 ni Windows?

Por defecto la máquina virtual muestra una excepcion de inicialización de una clase perteneciente a la librería gráfica utilizada, pero es una solución muy poco elegante. Por lo tanto, Pigmeo Compiler detecta la plataforma de ejecución automáticamente (utilizando Environment.OSVersion.Platform) y se ejecuta por defecto utilizando la interfaz de GTK# cuando se encuentra en sistemas derivados de Unix y la interfaz WinForms cuando está en Windows, pero además se detecta cuándo una librería gráfica no está disponible, por lo que si ejecutándose desde Linux (por ejemplo) se intenta utilizar GTK# y no está disponible, automáticamente se cambiará a la interfaz basada en WinForms, que también funciona en Linux. Además, si ninguna interfaz gráfica está disponible (porque la máquina virtual no encuentre las librerías necesarias o porque nos encontremos en una interfaz sólo texto) se muestra un aviso y se comienza la compilación desde la consola.

Por supuesto, esto solamente es el comportamiento por defecto, y podemos elegir manualmente la interfaz que queremos utilizar con el parámetro –ui de Pigmeo Compiler.

Al poco tiempo de haber comenzado a programar Pigmeo Compiler encontré monomerge, una aplicación que agrupa varios assemblies de .NET (ejecutables y librerías) en un solo ejecutable. Aparentemente me iba a ahorrar gran parte del trabajo, lo que viene a ser casi todo el frontend de Pigmeo Compiler.

Tras varios intentos fallidos y tras darme cuenta de que gran parte del código tendría que reescribirlo de todas formas, desistí y comencé a trabajar en mi propio “mezclador” de assemblies. Con esto me refiero a que monomerge agrupa las librerías y los ejecutables con todos los tipos que incluyen, es decir, todas las clases y estructuras que existen en los assemblies. Al principio parece una buena idea, es bastante cómodo de implementar y tenemos lo que queremos: un solo ejecutable con todas las librerías necesarias, sólo necesitamos una máquina virtual (el CLR de .NET) y ya tenemos nuestra aplicación funcionando sin un montón de librerías molestando. Realmente esto no es tan sencillo, porque los compiladores que generan estos assemblies incluyen en ellos absolutamente todos los tipos (clases y estructuras) que estén definidos en el código fuente, y eso es un problema a la hora de compilar para un microcontrolador, con recursos muy limitados, ya que la mayoría de propiedades y métodos implementados en las clases y estructuras nunca llegan a usarse.

Por lo tanto monomerge descartado, y estoy escribiendo el frontend del compilador desde cero, procesando instrucción a instrucción (en CIL) empezando por el EntryPoint de la aplicación (normalmente la función estática main(), pero no necesariamente), y detectando exactamente qué propiedades (variables) y métodos (funciones) y de qué tipos (clases y estructuras) realmente se utilizan en la aplicación, para lograr que en la aplicación compilada para microcontroladores sólo se implementen las cosas utilizadas y realmente necesarias, y no haya una sobrecarga innecesaria y completamente ineficiente.

Para estructurar el código de manera más organizada y sobre todo para poder utilizar extension methods estoy escribiendo el código en C# 3.0. Puede parece algo extraño porque no es demasiado utilizado aún, pero hay partes del framework que no serían nada útiles sin los extension methods. No es mayor problema ya que desde hace bastante tiempo el compilador de mono (mcs/gmcs/smcs) soporta gran parte de C# 3.0 y la última versión ya lo soporta casi todo. La versión de la máquina virtual implementada por Microsoft que los soporta ya hace tiempo que está disponible como descarga para windows y Visual Studio 2008 (en la calle desde el 19 de noviembre de 2007) también permite elegir la versión del lenguaje para la que compilar (incluyendo la 3.0).

No obstante los usuarios finales ni siquiera necesitan instalar una de las últimas versiones de la máquina virtual de .NET (CLR) porque los binarios generados son compatibles con la versión 2.0 ya que las características añadidas a C# 3.0 son sólamente syntactic sugar, aunque quienes quieran utilizar estas funciones añadidas al .NET Framework en sus programas necesitarán una versión actual que lo soporte.

Como ya he comentado, ya principal razón de compilar para C# 3.0 es poder utilizar extension methods, que nos permitirán añadir funciones muy útiles a las clases ya existentes del .NET Framework sin necesidad de reescribir las clases ni sustituir las librerías, por ejemplo podremos hacer “byte a=5; a.Getbit(3);” para obtener el tercer bit de la representación binaria del valor de la variable “a”. Me hubiese gustado poder hacer lo mismo utilizando indizadores, por ejemplo: “byte a=5; a[3];” lo que nos permitiría leer y modificar bits independientes de manera mucho más cómoda. C# 3.0 no soporta extensiones de indizadores ni propiedades pero se espera que C# 4.0 sí lo haga.

Antes de que se una cualquier otro desarrollador quiero terminar la estructura principal del proyecto, sobre todo del compilador y el framework, porque son decisiones de diseño y no de implementación, y ese tipo de decisiones prefiero hacerlas sólo ya que de otra manera es mucho más fácil que acabemos discutiendo. Para el final del concurso espero tener terminado el diseño global de compilador y framework, y de momento acabo de terminar las pautas de desarrollo (en inglés) que indican a grandes rasgos cómo se debe escribir el código, más que nada para que sea lo más legible, usable y portable posible, aunque no es demasiado pedante y da bastante libertad al desarrollador.

Supongo que la regla más “incómoda” sea la de documentar casi todo el código fuente con comentarios XML, y documentar absolutamente todas las clases, métodos y variables públicas del framework. Esto es así porque aunque la documentación “real” cueste escribirla, los comentarios en XML son muy útiles para entender el código, y sobre todo el código del framework que va a ser utilizado por los usuarios finales para escribir sus propios programas para microcontroladores. No puedo permitir que un usuario normal quiera utilizar alguna clase incluída en pigmeo-framework y no tenga ni la más mínima idea de cómo utilizarlo. Obligando a los desarrolladores de pigmeo a escribir comentarios XML me aseguro de que cuando un usuario escriba código fuente y su entorno de desarrollo le autocomplete el nombre y los parmámetros de las funciones y variables estos usuarios vean claramente una pequeña descripción de lo que van a utilizar. No hay nada más incómodo que utilizar librerías sin documentar.

El proyecto pigmeo se divide en varios subproyectos. La piedra angular del compilador (pigmeo-compiler uno de los subproyectos) es su paradigma: la programación orientada a aspectos. Utilizando las clases del namespace System.Reflection de .NET podemos modificar directamente los binarios de .NET. Como System.Reflection es algo engorroso utilizaré un librería intermedia: Cecil. Es GPL así que no hay ningún problema en utilizarla. El usuario final obviamente no tendrá que preocuparse por Cecil, reflexión ni AOP ya que sólo se utiliza desde pigmeo-compiler, y no desde pigmeo-framework (el framework utilizado por los usuarios finales).

Cecil está muy bien organizado y permite acceder a todas las clases, métodos, instrucciones en lenguaje intermedio (CIL)… mediante una jerarquía bien estructurada. El gran problema de Cecil es que no tiene absolutamente nada de documentación, solo unos pocos ejemplos, y ni siquiera está documentado el código fuente mediante XML (muy útil para ver la descripción de clases y objectos en el autocompletado del entorno de desarrollo), por lo que te encuentras con cientos o incluso miles de clases y funciones con nombres extraños y sin ningún tipo de explicación, así que acceder a algunas partes del ejecutable que se está intentando modificar resulta prácticamente imposible.

Cecil se utilizará para la primera parte del compilador: el frontend. El frontend lee el ejecutable de .NET y genera OTRO ejecutable con el mismo programa pero organizado de una manera totalmente diferente, parecida al bajo nivel (o más bien “desorganización”) del lenguaje ensamblador. Por ejemplo las clases estáticas con sus propiedades también estáticas funcionan como variables globales en C y C++, son accesibles desde cualquier parte del programa. Estas propiedades estáticas en el frontend se cambian de nombre a uno válido para el programa ensamblador, y se agrupan en una sola clase que más tarde en el backend específico para la arquitectura de destino se convertirán de golpe a variables globales en lenguaje ensamblador. La idea es que a partir del ejecutable de .NET generado por el compilador de C#, VB.NET o el lenguaje que sea, se genere un segundo ejecutable de .NET tan válido como el primero pero estructurado de manera que sea mucho más fácil convertirlo a lenguaje ensamblador, eliminando la complicada estructura original del ejecutable y además optimizando el código para todas las arquitecturas, es decir, optimizaciones que son válidas para cualquier arquitectura de destino, y no dependen de ninguna en particular. Las optimizaciones específicas para cada arquitectura se procesarán en el backend.

Por si a alguien le parece extraño que diga “ejecutable de .NET” que sepa que el compilador del lenguaje de alto nivel utilizado (C#, VB.NET,C++/CLI, nemerle…) lo que genera no es código máquina, sino un “.exe” que aunque comparte la extensión de los ejecutables nativos de Windows NO lo es, sino que es un archivo que contiene, entre otras cosas, el código en lenguaje intermedio (CIL) que para ser ejecutado debe ser interpretado por una máquina virtual o CLR (Microsoft .NET, mono, Portable .NET…).

No me extiendo más, porque para eso está la documentación para desarrolladores.

Mi primer mensaje a dos semanas de comenzar el concurso… que nadie se piense que lo he dejado de lado, es que estos días me ha pillado muy ocupado. Ya he terminado, me he estado organizando y ya está todo listo para empezar. La idea global del desarrollo del proyecto está lista (aunque seguro que cambio bastantes cosas según voy avanzando) y me acabo de registrar en la forja de rediris.

Todo lo que haga (sobre todo la documentación) lo publicaré en la web oficial del proyecto: http://en.pigmeo.org
En http://es.pigmeo.org está la versión en español para más adelante traducirlo todo tranquilamente, pero de momento todo lo publicaré en la web en inglés, tengo que centrarme en picar código y documentar, y no en traducir.

Sobre la forja: intentaré utilizar la menor cantidad de recursos posibles de rediris porque seguramente tras terminar el concurso migre a un sitio más “internacional”. Espero que esto no influya demasiado en la calificación final. Cosas como documentación para usuarios, documentación para desarrolladores, lista extendida de características, enlaces a todas las partes del proyecto (foros, listas de correo…) y demás cosas iran publicadas directamente en el sitio web oficial.