He estado haciendo unos diagramas sencillos sobre el formato HFP y los he incluído en las especificaciones que hay colgadas en la sección de documentación de Mandarina . Aun así, como el blog está para algo, colgaré aquí los diagramas para que se vea que, aunque muy poco a poco, sí que estamos avanzando.
Diagrama del formato HFP
Bastantes proyectos ya han mostrado avances significativos en estos momentos, ya sea en el apartado de planificación, documentación o código ejecutable. Por desgracia, éste NO es el caso de Mandarina.
Por el momento estamos construyendo una librería dll (en C++) llamada libgajo que servirá de soporte para el manejo de paquetes y sólo hemos colgado unas especificaciones (que hace falta mejorar, en cuanto a presentación y en cuanto a información) sobre el formato HFP (HaseFroch Package).
¿Cuál es el estado de libgajo? Realmente aún está muy verde, hace dos días replanteé totalmente su estructura y volví a empezar desde cero, hoy he eliminado todo el código antiguo del repositorio y lo he dejado en un directorio llamado deprecated por si alguien siente curiosidad por saber QUÉ es lo que me motivó a desechar el código escrito. Os aseguro que no os costará adivinarlo.
Actualmente en la librería libgajo he definido unas cuantas clases, una clase base de la que derivan otras dos HFP_DirReader y HFP_FileReader que sirven para extraer la información de ficheros y directorios contenidos en un paquete HFP, y unas cuantas clases de excepciones. Tengo que añadir las contrapartidas de HFP_DirReader y HFP_FileReader, que se encargarán de leer un arbol de directorios y empaquetarlo en un archivo. Falta, además, añadir la verificación de checksums y la capacidad de leer y añadir firmas digitales (tal y como se especifica en el documento sobre HFP). “Por último”, se tiene que añadir una clase (o varias) que sirva para manejar el compresor, de ello se está ocupando Sergi.
En realidad, libgajo no se limita a eso, pues se tendrán que añadir rutinas que extraigan la metainformación del paquete y permitan tratarla con facilidad, pero eso ya vendrá.
Más novedades, leyendo posts sobre otros proyectos he visto que nos tenemos que poner las pilas en cuanto a metodología de trabajo, veo que hay algunos proyectos que se están llevando con auténtica profesionalidad, y aunque no esperamos actuar talmente como profesionales, actuar siguiendo ciertas pautas nos resultará beneficioso. Para ello, hemos empezado por la reestructuración del repositorio svn, adaptándola a una forma más estandarizada (tal y como se comenta en un post de eOPSOA).
Hemos decidido que en cuanto acabe las tareas que me he autoasignado sobre libgajo documentaré las clases que he estado programando y mejoraré las especificaciones de HFP (al menos en cuanto a presentación) para hacerlas más leíbles.
No utilizaremos gráficos gantt (de momento) ni nada parecido para planear nuestras tareas por que tenemos horarios muy irregulares y nunca sabemos si podremos acabar algo o no.
En cuanto a lo que sigue al desarrollo de libgajo: una vez acabada la libgajo tendremos que empezar a darle utilidad. El caso es que queremos avanzar lo más rápido posible, y por ello hemos decidido que inicialmente puede que hagamos los programas en Python (3k), y una vez que tengamos algo usable haremos sus hermanos “mayores” programados en C++ para conseguir mayor eficiencia.
Sí! No lo habéis leido mal, ya lo tenemos hecho! Nos ha costado muchas horas de sueño y mucho esfuerzo y trabajo de campo.
Sin más preámbulos os dejo un screenshot de los mismos:
Hahahahaha, realmente ya nos gustaría tener el proyecto tan avanzado. La cosa es que un poco de humor nunca viene mal, además, con el nombre de nuestro proyecto.. lo tenemos a huevo Hehehe.
Bueno, hasta otra!
Pues hemos estado indagando un poco en el asunto de que el IDE no nos dejara compilar DLL’s en linux y hemos encontrado la solución a este temita que nos tenía mosqueados.
El primer error que cometíamos era indicar en las opciones del proyecto que nos compilara solamente para la plataforma Windows. Debíamos dejarlo como estaba, para todas las plataformas (Unix, Mac y Windows).
Hecho esto, tanto el ejecutable como la DLL compilan perfectamente. La sorpresa es que el ejecutable aparece sin la extensión característica (.exe) y la DLL sin la suya (.dll). Esto es lo que nos hizo comer la olla y liarnos en el tema de toquetear las opciones del proyecto. Que el ejecutable era para windows no había duda, pues lo abriamos con Wine y voilá, lo corría perfectamente. El tema era la dll, que nos la daba con extension .so. Nos ha hecho sospechar que el ejecutable funcione para Windows a pesar de la no-extensión y de la compilación “multiplataforma”, y supuestamente el DLL no debería de funcionar. El caso es todo el contrario, hemos puesto una bonita extension .dll a nuestra DLL de prueba, y hemos exportado la función que habia dentro al ejecutable y… sí! Funciona perfectamente! Problema solucionado!
Aquí os dejo el código de los programas de prueba, por si alguien le interesa.
Ejecutable:
#include <stdio.h>
#include <stdlib.h>
#include <conio.h>
#include <windows.h>int main()
{
/*Definimos el tipo para la funcion a exportar*/
typedef void (*pfunc)();/*Hande de windows*/
HANDLE hdll;/*El puntero a la funcion*/
pfunc HelloDllFunc;/*Cargamos la libreria con LoadLibrary*/
hdll = LoadLibrary(”HelloWorld.dll”);/*Obtenemos la dirección de la funcion a utilizar con GetProcAddress*/
HelloDllFunc = (pfunc)GetProcAddress(hdll, “printHelloWorld”);/*Llamamos a la funcion*/
HelloDllFunc();/*Paramos la ejecucion con un getch, de la libreria conio.h*/
getch();return 0;
}
DLL:
#include <stdio.h>
//Funcion de la dll que imprime por pantalla “Hello World!” 4 veces
void printHelloWorld()
{
int i;
for (i=0; i<4;i++){
fprintf(stdout, “Hello World!\n\n”);
}
}
Como veis el código está bien comentado así que deberíais entenderlo fácilmente. Sino siempre nos podéis preguntar. Si preferís que subamos el tarball con los proyectos de Code::Blocks pedidlo y lo subiremos a un Rapidshare, Megaupload o algo parecido.
Por cierto, también os dejo el link del HOWTO para configurar el Code::Blocks para compilar para Windows:
http://forums.codeblocks.org/index.php?topic=3343.0
Pues nada, a continuar trabajando! Esperamos que le sirva de ayuda a alguien esto también!
Érase una vez un dibujo que quería ser el logo de nuestro proyecto… ¿se presentará alguna alternativa más :p ?
Logo candidato para el proyecto Mandarina
Durante ésta semana pasada, ésta y la siguiente nuestro tiempo es escaso y no tenemos el suficiente como para poderlo dedicar a Mandarina (exámenes, trabajos…), aunque intentamos sacarlo de debajo de las piedras para poder ir haciendo algo.
Entre otras cosas intentamos montar nuestro entorno de trabajo, y como ya dije en un post anterior, escogimos Code::Blocks. La principal ventaja de este IDE es que es multiplataforma, y entre las plataformas que soporta se encuentra Windows. Lo primero que pensamos fue programar desde Linux y utilizar MingW32 como compilador cruzado, combinándolo con Wine para ir haciendo las pruebas (al menos al principio).
El proceso de configuración del IDE para conseguir nuestro propósito lo hicimos a partir de éste tutorial que enlazo:
http://forums.codeblocks.org/index.php?topic=3343.0
Cuando intentamos compilar ejecutables no tuvimos ningun tipo de problema, pero cuando intenté compilar una DLL la cosa ya fué otro cantar. El mensaje de error era el siguiente:
“libgajo” does not support the current platform. Skipping…
Por cierto, la librería que dará soporte al manejo de paquetes se llamará LibGajo, lo decidimos así porque la palabra gajo tiene cierta relación con la palabra Mandaria y porqué en el buscador Google la búsqueda del vocablo libgajo (por el momento) devuelve 0 entradas.
Volviendo al tema anterior, ¿Qué hicimos para solucionarlo? Pues descargar la versión instalable de Code::Blocks para Windows (con MingW32 integrado) e instalarlo y usarlo a través de Wine. Por lo general utilizamos la versión de Linux, y sólo cuando tenemos que compilar pasamos a la versión que corre sobre Wine. Obviamente ésto que hemos hecho es una chapuza, y esperamos que sea sólo provisional, cuando encontremos la solución definitiva ya lo comentaremos.
Hasta otra!
Bueno, antes que nada, tenemos que decir que nos alegra que dentro de la comunidad de ReactOS la aparición de nuestro proyecto haya causado buena impresión (nos hemos enterado por un comentario en la entrada inmediatamente anterior). Pero éste post, además de una respuesta a este comentario que nos ha hecho tanta ilusión, es por que en ese mismo comentario he encontrado una cosa que me ha sorprendiso sobremanera :p …
Prometo que ha sido casualidad, nunca había pasado por el blog de ReactOS antes (lo que tampoco es sorprendente porqué es de creación reciente, ¡rodolí!) (observad el tema escogido,jeje): http://reactos.wordpress.com/
Acabo de subir al repositorio svn de Mandarina la especificación del formato HFP (HaseFroch Package, el formato que tendran los paquetes de software de Mandarina). De momento es una versión provisional que requiere un poco de experimentación para ver si es necesario algun cambio.
Faltan detalles, como los que se refieren a metadatos sobre el paquete. En una segunda revisión añadiré información sobre ése aspecto, aunque de momento avanzo que la metainformación sobre el paquete se encontrará en ficheros individuales dentro de un directorio llamado ‘meta’.
[Solucionado]
Para ver el repositorio svn de Mandarina vía web podéis acceder a través de esta dirección:
https://forja.rediris.es/websvn/wsvn/cusl3-mandarina/
Para acceder al repositorio mediante métodos más “tradicionales”, simplemente ejecutad:
svn checkout https://forja.rediris.es/svn/cusl3-mandarina
Podéis hacer tantas sugerencias como queráis sobre el formato, pues todavía está casi todo por decidir y lo que hemos colgado es algo provisional. Saludos!
Hace tiempo estuvimos pensando qué IDE escogeríamos para programar y gestionar Mandarina. La conclusión a la que llegamos es que sería interesante que el IDE cumpliera los siguientes requisitos:
De momento pensamos utilizar el compilador MinGW desde GNU/Linux (nos da palo saltar a MS Windows) y Wine para ir probando la ejecución, aunque de tanto en tanto saltaré a Hasefroch para cerciorarme del todo, no será lo usual.
El caso es que teníamos en mente: Eclipse y Code::Blocks , al final nos decantamos por el segundo, que es mucho más rápido 
.
Nos dejamos características interesantes, como que el IDE tenga soporte para svn, tal y como Eclipse tiene, pero… el soporte que Eclipse da a svn es francamente molesto.. cada dos por tres pide contraseñas y hace perder mucho más tiempo del que se gana. Para actualizar el repositorio ya utilizaremos otras herramientas (como por ejemplo rapidsvn, un buen entorno gráfico que facilita la tarea)
El camino que esperamos siga Mandarina es el siguiente:
v0.0:
v0.1:
v0.2:
v0.3:
v0.4:
Más adelante quien sabe qué vendrá, es posible que, dado que éste roadmap es talvez demasiado precipitado, sufra algun que otro cambio en el futuro. Colgaré un enlace estático para que sea accesible sin tener que hacer ninguna búsqueda.
