He aqui un manual y/o/u documentacion.

[mortimor]

Pregunta para los de los concursos de tutoriales y manuales y esas cosas.

El fichero que adjunto en que categoría entraría si hubiese otro concurso??? :D:D:D


PD: Abstenganse los NO-Programadores.

[Wonder Boy]

Ese mortimor con ese tochazo documento que no tiene desperdicio precisamente que digamos... :D ;)

Un Saludo y Suerte mortimor!
;-D

[chui]

¡ ¡ ¡ ¡ Gracias por tu currada Mortimor ! ! ! !

[chui]

Mortimor, leyendo tu documento y haciendo pruebas con esto:

int main(int n_arg, char **arg)
{
IMLElement elem=NULL;
IMLElement subelem=NULL;

printf("HacerDoc %i\n",HacerDoc());
printf("doc->SaveFile: %i\n",doc->SaveFile(doc,"ejemplo.xml"));
printf("doc->GetNumChilds %i\n",doc->GetNumChilds(doc));
printf("doc->GetSingleElement %i\n",doc->GetSingleElement(doc,"raiz",&elem,0));
printf("elem->GetType %i\n",elem->GetType(elem));
printf("elem->GetName %s\n",elem->GetName(elem));
printf("elem->GetNumChilds %i\n",elem->GetNumChilds(elem));
printf("elem->GetSingleElement %i\n",elem->GetSingleElement(elem,"subelem0",&subelem,0));

return 0;
}


Todo funciona bien (tanto compilando como funcionando) si no incluyo la ultima linea donde quiero pillar el 'subelem0' desde 'raiz'.
Se produce un error de compilación 'too many arguments to function GetSingleElement' para IMLElement.
He mirado mi ML_Element.h y puedo ver:
int (*GetSingleElement) (struct MLElement *this, char * name, struct MLElement **out);

Por lo que no se especifica el indice al final como argumento.
¿Esta mal mi lib o un bug en tu doc?
Si es un bug en tu doc... ¿Como recorres el documento buscando elementos sin indice?

Quizas sea un tonteria, pero a mi me tiene todo loco.

[chui]

Usando IMLNode y GetSingleChild parece que funciona correctamente.


----------------------------------------------------------------------------------

int main(int n_arg, char **arg)
{
IMLNode elem=NULL;
IMLNode subelem=NULL;

printf("HacerDoc %i\n",HacerDoc());
printf("doc->SaveFile: %i\n",doc->SaveFile(doc,"ejemplo.xml"));
printf("doc->GetNumChilds %i\n",doc->GetNumChilds(doc));
printf("doc->GetSingleChild %i\n",doc->GetSingleChild(doc,"raiz",&elem,0
));
printf("elem->GetType %i\n",elem->GetType(elem));
printf("elem->GetName %s\n",elem->GetName(elem));
printf("elem->GetNumChilds %i\n",elem->GetNumChilds(elem));

printf("elem->GetSingleChild %i\n",elem->GetSingleChild(elem,"subelem0",
&subelem,1));
printf("subelem->GetType %i\n",subelem->GetType(subelem));
printf("subelem->GetName %s\n",subelem->GetName(subelem));
printf("subelem->GetNumChilds %i\n",subelem->GetNumChilds(subelem));

subelem->Release(subelem); subelem=NULL;
elem->Release(elem); elem=NULL;
doc->Release(doc); doc=NULL;

return 0;
}

----------------------------------------------------------------------------------


La salida es:

HacerDoc 0
doc->SaveFile: 0
doc->GetNumChilds 3
doc->GetSingleChild 2
elem->GetType 3
elem->GetName raiz
elem->GetNumChilds 13
elem->GetSingleChild 3
subelem->GetType 3
subelem->GetName subelem0
subelem->GetNumChilds 0

Sobre el XML creado en HacerDoc:

<?xml version="1.0"?>
<raiz autor="Mortimor" prueba="666">
<subelem0/>
<subelem1/>
<subelem2/>
<subelem3/>
<subelem4/>
</raiz>



¿Que diferencia funcional hay entre GetSingleChild y GetSingleElement?

[chui]

Yo mismo al final he encontrado la diferencia, y como es logico sin GetSingleElement no se puede trabajar.

Asi que he parcheado tu codigo para que funcione con indice:

------------------------------------------------------------------------------------
En el fichero ML_Element:
------------------------------------------------------------------------------------

int mlelement_GetSingleElement (IMLElement this, char * name, IMLElement *out, int index)
{
int i,loc=0;

for (i=0;i<this->p_this->num_childs;i++)
{
if ((this->p_this->childs[i]->type==NODE_Element)&&(strcmp(this->p_this->childs[i]->name,name)==0))
{
if (loc==index)
{
*out=(IMLElement) malloc (sizeof(struct MLElement));
if (*out==NULL) return -1;/*No hay memoria*/
mlelement_init(*out,this->p_this->childs[i]);
return i;
}
else loc++;
}
}

return -2;
}

------------------------------------------------------------------------------------

Supongo que tu ya lo tendras bien; si es asi, por favor deja en el FTP la version correcta.


Por lo demas... GRACIAS.... El prototipo del parseo de los mapas Vorton que estoy construyendo parece que funciona dabuten.

:p :p :p

[mortimor]

Vaya, tenias razon. Es que la version que he colgado en el ftp no era la que lo tenia cambiado. es cosa de la lib. ya cuelgo el arreglo. Creo que eso lo cambie en la ultima version al compilarlo para windows y no lo cambie en la principal (en la que sera la 0.2 estaba bien)

De todos modos estoy todavia revisando el documento, si encuentras algun bug comunicamelo, aqui pongo la version revisada del DOC con menos fallos. Es que queria que la tuvieses cuanto antes y no la revise.

Aqui pongo el Doc nuevo, tiene un par de erratas corregidas. Lo dejo en el ftp tambien, con el codigo actualizado.

Perdona las molestias.

[mortimor]

Sorry, se me olvido adjuntar.

[mortimor]

Ya ta, advierto que la version 0.2 tiene pinta de quedar mucho mejor. Respecto a la funcionalidad.... en cuanto acabe de integrar el XPath y le ponga las listas de nodos... esto va a ser la hostia.

[chui]

Dabuten, en cuanto llege a casa lo descargo y hago algunas pruebas mas.

Tienes que echar un vistazo al prototipo de parseo de los mapas de Vorton; seguro que le encuentras algun fallo o quizas lo mejores con facilidad.

[enkonsierto]

¿Es facil hacer niveles del vorton?

[mortimor]

Cuendo vuelva a casa le hecho un vistazo.

[chui]

Es bastante facil hacer un mapa para Vorton.

Por ejemplo, para la parte del mapa que puede verse en la beta1-pre1 que deje el otro dia, es este fichero texto:

<?xml version="1.0"?>
<?vortonMap version="beta1"?>
<map level="1-1">

<!-- 1 -->
<obj type="DUSTBIN" x="0" y="64"/>
<obj type="DUSTBIN" x="11" y="72"/>
<obj type="DUSTBIN" x="28" y="84"/>
<obj type="DUSTBIN" x="36" y="84"/>
<obj type="DUSTBIN" x="55" y="64"/>
<obj type="DUSTBIN" x="64" y="72"/>

<!-- 2 -->
<obj type="BRICK" x="0" y="192"/>
<obj type="BRICK" x="8" y="192"/>
<obj type="FIRE" x="16" y="192"/>
<obj type="FIRE" x="64" y="224"/>
<obj type="CYCLOP" x="18" y="224" vel="1"/>
<obj type="CYCLOP" x="28" y="224" vel="2"/>
<obj type="CYCLOP" x="38" y="224" vel="3"/>

<!-- 3 -->
<obj type="BLOQ" x="20" y="320"/>
<obj type="BLOQ" x="44" y="326"/>
<obj type="FIRE" x="12" y="352"/>
<obj type="FIRE" x="52" y="352"/>

</map>


Con unas pequeñas indicaciones en un pdf TODOS podremos crear fases facilmente. Otra historia sera crear los graficicos y musica de cada nivel. :D

[chui]

Mortimor-> He dejado en el ftp en tu directorio mi ml.tar.gz. Te puede servir para depurar errores.

Con la nueva version he detectado:

- Algun puntero se va de madre al intentar liberar el doc (doc->Release(doc)).

- En la gp32 con el wrap incluido se pierden 15Ks en el primer barrido (carga, parseo y liberacion por barrido). Luego extrañamente en el resto de barridos se pierden 2Ks hasta que se resetea.

Quizas sean bugs mios. ¿Puedes echarle un vistazo? En definitiva es el esqueleto del parser para los mapas Vorton.

[mortimor]

Bueno, si tengo un rato esta noche le hecho un vistazo. ES que creo que puede que haya mezclado dos versiones o que haya cambiado algo en un sitio y en otro no (ajustes .... ajustes...) y ahora vaya peor.

[chui]

En cuanto lo tengas parcheao, pegame un toque por aqui o mejor a sdl_gp32@yahoo.es

:p :D :p

[mortimor]

He estado haciendo pruebas. He cambiado un par de cosas que creo ahora estan mejor (como los buffers de datos que devuelve en algunos puntos, ahora me aseguro de que tengan detras un \0 para que puedan usarse tambien como cadenas).

Por otro lado... lo he compilado, tu codigo. en el VS y no me da errores ni excepciones. Encontre un error en tu codigo (una cadena en vez de ponerla a NULL la comparabas con NULL, eso es muy malo si luego la liberas por segunda vez o la sobreescribes perdiendo memoria:D:D:D). Pero parece estar bien.

He observado lo de la memoria con el Visor de procesos del VS (aunque no controlo muy bien esta utilidad), ya veremos como va funcionando. Te subire ahora la version revisada de tu codigo con tos los cambios en mi directorio del ftp. Pero, insisto, a mi no me daningun error como los que tu me decias; bueno despues de los cambios que le he hecho (aunque no son gran cosa).

[chui]

Ya me imaginaba que tendria algun bug... gracias... **** doble = :D

Ahora funciona bien, pero he podido ver en la GP32 que se pierden 2Ks cada vez que se realiza el parser... no es gran cosa, pero existe esa perdida.

Los primeros 13Ks perdidos en la primera iteracion se debe al GPSDK (posiblemente el GPFatInit necesita mem para la tabla FAT).

Con este programa, puede verse que en la primera iteraccion se pierden 13Ks, pero en las siguientes iteracion se pierden 0 bytes:

-------------------------------------------

void GpMain(void *arg)
{
int i;
for (i=0;i<1000;i++)
{
int m=gm_availablesize();

FILE *f=fopen(FILE_NAME,"r");
tmp_str=calloc(10,1024);
fread(tmp_str,1,100,f);
fclose(f);
free(tmp_str);

dimeNum("Perdida: ",(m-gm_availablesize()));
}
}

-------------------------------------------


Sin embargo, con el siguiente programa se pierden 15120 bytes con la primera iteracion y en las siguientes 2808, 2820 2904, 2832, 2852, 2864, 2868, 2852, 2896,2860,2804,2800,2828,2864,2824,2820...
:

-------------------------------------------

void GpMain(void *arg)
{
int i;
for (i=0;i<1000;i++)
{
int m=gm_availablesize();

DocumentFromCOM(IID_IMLDocument,&doc);
doc->LoadFile(doc,FILE_NAME);
doc->Release(doc);

dimeNum("Perdida: ",(m-gm_availablesize()));
}
}

-------------------------------------------

Por lo que deduzco que se pierden menos de 3Ks por iteracción. Lo que me deja loco es que no se pierde un numero exacto; quizas sea algo del gpsdk o del c-wrapper.

Espero que no te moleste que ponga aqui supuestos fallos de tu libreria. Solo deseo ayudar. Ahora mismo tal cual esta se incluira en Vorton; la perdida es muy pequeña.

Como siempre... MUCHAS GRACIAS POR TU CURRADA, LA LIB ES COJONUDA.

[mortimor]

No me hagas la rosca :D:D:D

LA verdad es que supongo que sera de la LIB, ya que el codigo no es muy uniforme y hay operaciones que se realizan de forma diferente segun el sitio en el que esten implementadas (aunque se suponga que deben hacer lo mismo).

A demas, teniendo en cuenta el fallo aquel de la primera version que te pase, seguro que se trata de algo parecido. A ver si tengo tiempo y reviso tol codigo, es que ahora acabo de llegar de un velatorio.... y mañana tengo la continuacion :(.

[chui]

Siento mucho lo del velatorio... y en serio no te hago la rosca... la lib funciona muy bien, tio.

Cabe la posibilidad de un fallo en el c-wrapper o la gpsdk.

Es muy extraño que tu lib pierda en cada iteracion distinto numero de bytes haciendo exactamente lo mismo.

[mortimor]

Arreglado el problema. Nueva version en el ftp. Era una chorrada de los destructores (creo, pruebalo).

[chui]

En cuanto llega a casa lo pruebo. ESPERO QUE SE ARREGLE BIEN ! ! !

Yo me he creado una version de tu lib que muestra mensajes de depuracion:

1- Al principio de cada funcion muestra por stdout el nombre de la funcion.
2. He cambiado todos los malloc/free como ML_malloc y ML_free para poder tracearlos... EL RESULTADO ES MUY SORPRENDENTE.


Aqui dejo la paranoia; para analizar los resultados he creado un script unix para saber que no se reserva.

[chui]

En un vistazo rapido, puedo ver que lo que se reserva en la funcion node_Clone, en el punto:

.....
tmp->num_childs=this->num_childs;
if (this->num_childs>0)
{
tmp->childs=(p_node *) ML_malloc (this->num_childs*sizeof(p_node));
if (tmp->childs==NULL)
{
if (tmp->data) ML_free (tmp->data);
ML_free(tmp);
return NULL;
}

for (i=0;i<this->num_childs;i++)
.....

PARECE QUE EL PUNTERO DE ESE MALLOC NO SE LIBERA !

En casa con mas calma quizas encuentre mas... si no me estoy engañando con mi sistema de log-debug y el script shell para localizarlos no liberados.

[chui]

He revisado todas las reservas no liberadas detectadas.... TODAS SE PRODUCEN DENTRO DE node_Clone y UNA en node_AddRef.

Es posible que sea en el malloc comentado antes del node_Clone.

[mortimor]

Es en el node_destructor, precisamente no se liberaba this->childs despues de liberar los hijos.

Menudo fallo. por eso se petaba. Lo he detectado este medio dia.

[chui]

¡¡¡ Cojonudo !!!!!

¿Entonces la última version bajada al FTP esta arreglado ese problema?

[mortimor]

En un principio si. Pero solo la he probado con un xml muy pequeño, que solo tenia la PI inicial. No he tenido mas tiempo por el tema que mencione ayer. Si no encuentras mas bugs me metere a incluir ya las nuevas funciones.

[chui]

AHORA SI....

IMPRESIONANTE

:D :p :D


Funcionalidad: Completa para VortonMap.
Perdida de Memoria: 0 bytes (200 pasadas).


:p :D :p

[mortimor]

Gracias, Gracias..... :D:D:D

Pues espera a ver la version 0.2 que esta en camino. Sorpresa :D:D:D