FTL Parser 2004 - Page 15

Ouais enfin je pensait plutôt l'inverse... ceux qui veulent s'en servir le mettront sur leur calc. Et puis comme ça ça pourrait aussi permettre à d'autre personne de programmer des "plugins"... enfin je vais voir.

En fait si j'intégre ce système FTL Parser ne connaitra aucun plug à l'avance : il devront être installé.

Et sinon quelqu'un a une idée pour savoir comment distinguer plusieurs chaîne de texte, ou atre données lorsqu'elle sont mise bout à bout dans un bloc de mémoire alloué ?

Tu peux mettre un caractère de séparation, mais les performances risquent d'être minables... Tu peux sinon avoir un tableau qui contient les offsets respectifs des données.

Pour les performance... non je ne pense pas. Pas plus que mnt avec malloc en tt cas. Par contre dans les deux cas je perd pas mal en place.

Est-il possibe de rajouter des informations à un fchier TEXT du genre : cryptée, compressé, commentaires... au début ou à la fin du fichier sans que cela se voit depuis un viewer bien sûr ?

Comment ça "sans que ça se voie depuis un viewer" ? Tu veux pouvoir lire le texte (même depuis le Text Editor) comme si de rien n'était ?

Non, non ! Je veux juste rajouter des informations avant le contenu du fichier... ou après même. Au début d'un fichier texte il y a la position du curseur et puis ça taille il me semble. C'est des informations comme celles là que je pensais.

Euh, à part les deux premiers mots, je comprends ta réponse comme un "Oui"

Alors :

Pollux
: Tu veux pouvoir lire le texte (même depuis le Text Editor) comme si de rien n'était ?

Si c pas le cas, rien ne t'interdit de prendre un fichier de type personnalisé (et c même certainement la meilleure solution).

Oui mais après il n'est plus éditable depuis l'éditeur de texte.

Au risque de re-répéter ma question :

Pollux
:

Pollux
:Tu veux pouvoir lire le texte (même depuis le Text Editor) comme si de rien n'était ?

C'est oui (tu veux pouvoir éditer/lire à partir du Text Editor) ou c'est non (tu ne veux pas) ? Parce que tu as qd même dit "Non, non !" dans ./430

Il veut pouvoir éditer et visualiser dans le viewer de ti (le Text Editor)

Si mes vieux souvenirs sont toujours exacts, chaque ligne d'un fichier texte commence par un espace qui correspond au caractère qui est avant les 2 points dans l'éditeur de TI (que tu peux changer avec F2 Command, qui peut être Command, Page Break, PrintObj, ou rien (un espace)). En mettant un autre caractère que ceux déjà prévu par le format sur la première ligne tu peux peut-être faire ce que tu veux.

Ok, je vais essayé de voir ce que je peux faire.
Sinon j'ai enfin réussi à faire une allocation dynamique de la mémoire par bloc de 1ko que ce soit pour les balises XML, pour les paramètres et pour le texte mais malheureusement je n'arrive pas à faire "coexister" pluisuers type de données dans le même bloc.
C'est à dire que j'utilise 3 blocs de mémoire de 1 ko :
- 1 pour le texte et le nom des balises XML (c'est que du texte : des unsigned char)
- 1 pour les paramètres (là c'est une structure)
- 1 pour les balises XML (là aussi c'est une structure).

Je n'ai pas encore trouvé de quoi ça venait et j'ai tellement eu de problème : quand je mettais à la suite une chaîne et une structure avec des paramètres par ex ça plantait.

Déjà avec des bloc de 1 ko la vitesse de parsing à au moins été décuplé et il n'y aurait même plus besoin d'afficher de barre de progression.
Et sinon il est possible de libérer l'espace qui n'est pas utilisé dans ces blocs ? Par exemple un nouveaux bloc de 1024 octets vient d'être alloué et il y a qu'une chaîne de caractère de 10 octets... c'est possible de libérer les 1014 octets inutiles ?

Non.
Mais au lieu d'allouer un prochain bloc pour la prochaine chaine, tu n'as qu'à écrire à la suite de tes 10 octets.

Non, non mais je ne suis pas bête à ce point là !
Oui j'ai oublié de préciser que c'est dans le cas ou c'est la dernière chaine... Bon en fait ça sert à rien parce-que si il n'y a pas assez de mémoire sur la calculatrice le bloc ne peut pas être alloué et puis c'est tout.

Sasume
: Non.

Si on fait un realloc de 10 octets sur ce bloc de 1024 ?? Ca va bien diminuer la taille de ce bloc non ?

Ah oui, effectivement.
Désolé de m'être trompé.

Et ça marche comment realloc ? Ca crée un nouveau bloc de mémoire copie l'ancien dedans puis supprime l'ancien ou c'est plus fin que ça ?

Sémantiquement, c'est comme ça, mais en pratique c'est mieux fait que ça : l'ancien bloc est libéré, puis y a une allocation normale (mais sans écriture dans la RAM), puis y a un déplacement du contenu, puis il y a mise à jour des infos sur le heap (taille du handle, en-têtes pour les emplacements vides...)

En fait lors d'un realloc il n'y a pas deux fois plus de mémoire bouffé ? En fait c'est ça que je voulais savoir. Par exemple si on fait en realloc sur un bloc de 1024 ocets : on le ramène à 1000. Est-ce qu'il arrive un moment ou il y a 2024 ocets de pris lors de l'opération ?
Et puis il me semble que Kevin m'avait doné une autre fonction pour libérer la RAM non utlisé par un bloc mémoire mais je ne sais plus si c'est realloc ou une autre fonction.

Je suis absolument sûr et certain que ça ne prend pas 2x plus de place qd il s'agit de baisser la taille du handle (par contre, ça ne sera pas forcément utile si la mémoire est fragmentée : si tu alloues plein de blocs de 1024 octets, puis que tu fais passer leur taille à 700 octets, tu ne seras pas capable d'utiliser la mémoire libérée à moins de faire des allocations de blocs de moins de 300 octets). Pour l'augmenter, il me semble que c pareil, mais c déjà moins sûr.

l'ideal serait de faire un garbagecollector apres chaque allocation/realloc/free mais dans ce cas il ne faut pas utiliser les pointeurs du C.....

1024 octets, puis que tu fais passer leur taille à 700 octets

Non je ne pense pas que ça arrive... enfin si ça peut mais en général il s'agit de quelues octets... d'ailleurs comme les paramètres font 6 ocets et qu'il prennent toujours la même place je vais prendre un multiple de 6.
Mais pour le texte c'est très aléatoire. Donc ça ne vaut pas plus la peine que ça d'utiliser Realloc ?

LizDog
: l'ideal serait de faire un garbagecollector apres chaque allocation/realloc/free mais dans ce cas il ne faut pas utiliser les pointeurs du C.....

Le faire "à chaque fois" obligerait à faire des memmove, mais effectivement sans handles lockés (ou bien avec une MMU) on éviterait les pbs de mémoire non allouable...


Raphaël> ben, ça dépend de tes durées de vie... si le but est d'allouer un paquet de truc, puis d'attendre que l'utilisateur fasse qqch, puis de tout libérer, ça sert à rien de faire des realloc à la fin du paquet d'allocations

Memory Mangement Unit
C'est ce qui empêche un programme d'aller lire/écrire ailleurs en mémoire que dans son segment de data. Enfin dans les systèmes qui l'intègrent