FTL Parser 2004 - Page 2

Oui, mais la vitesse n'est pas critique dans ce programme. Dans un parseur, s'il réalloue à la volée son buffer, ça risque d'être plus lent que si il ne le fait pas...

Bon alors ajouté à cela j'ai encore un autre problème. Chaque ligne que l'on voit à l'écran représente également une ligne dans le tableau. Donc suivant la taille de la font c'est très variable. Alors chaque ligne fait 65 octets mais c'est de la place gaspillé lorsque la ligne n'est pas pleine ou que l'on utilise la grosse font.
Là aussi il faudrait que j'alloue en fonction de sa mais je ne sais pas comment faire. Voila la structure :

typedef struct
{

unsigned char stick_char:2;
unsigned char color:2;
unsigned char center:1;
unsigned char under_line:1;
unsigned char on_line:3;
unsigned char font:2;
unsigned char animate:2;
unsigned char left:2;
unsigned char right:2;
int x:9;
unsigned char lines:1;

}Str_Mode;

typedef struct
{
char chaine[65];
Str_Mode param;

}Text;
...
TEXT=malloc(sizeof(Text)*100);


Il faudrait peut-être j'utilise un pointeur dans la structure comme ça :
typedef struct
{
char *chaine;
Str_Mode param;
}Text;

Et puis que j'alloue pour chaque ligne la place nécessaire. J'ai déjà essayé mais ça a toujours planté !
Et par contre je ne sais pas comment libérer cette mémoire à la fin : il faut le faire de la même manière que je l'ai alloué c'est à dire ligne par ligne ?

Moi aussi pour mon hibview j'ai ce pb de taille indéfinie. Alors j'ai coupé la poire en deux : j'alloue de le mem en fonction de la taille du fichier : ((taille_fichier)/16) (c'est une estimation que j'ai faite sur tout les fichiers texte de seche que j'ai vu). Et apres, appel a heaprealloc si y'en a pas assez, et si y'en a trop, un heaprealloc pour libérer ce qu'il y a en trop.

Pour mon Parser ça ne marche pas ça ! La taille du fichier ne représente absolument pas la taille du texte final parce-qu'il y a des lignes de codes qui permettent de définir ses "balises" (c'est pas vraiment des balises en fait), de copier du texte à partir d'un autre fichier, de duppliquer un même caractère... et tout ça fait que ça n'est pas proportionnel.
Je vais essayer d'utiliser heaprealloc alors.

Et puis comme je l'avais déjà fait remarquer, la vitesse du programme qui utilise beaucoup malloc dépend pas mal des éléments enregistrer dans le menu home de la calculatrice.

Maintenant, plus rien ne m'arrete, je pense meme que je programme trop et teste de moins en moins....

Moi au début j'avais pleins de plantages et je n'arrivais rien à faire et puis après j'ai programmé assez vite. Par contre pour arriver où j'en suis j'ai dû recommencer plusieurs fois certaines parties. Depuis le début tout à été refait ou presque : je ne programme jamais en une seule fois. Ca me prend bcp de temps mais ça m'évite de faire sortir 50 beta foireuses .

D'ailleurs, ca fait encore un nv concurrent a hibview... ca me motive pour continuer !

Tu trouve ? En tout cas je n'étais pas du tout partit pour concurrencer hibview, textrider ou encore Text Walker. Au début je voulais faire un programme qui interprète du code et puis je me suis vite orienté vers un viewer de texte. Mais dès le départ je voulais faire du texte animé et en niveaux de gris. Je n'ai pas voulu reeprendre le système avec les balises dans mon programmes car je veux que l'utilisateur puisse manipuler facilement de nombreux paramètres à la fois pour chaque ligne de texte. D'ailleurs la syntaxe (qui ressemble plus à un langage) est très différente des autres programmes.
Mais je ne sais pas jusqu'où je vais aller car qd je vois les dernier truc que j'ai programmé ça me faire peur : c'est plus tout carré comme au début. Pour que certains trucs marche comme les alignements par exemple, j'ai du utiliser des ruses qui rendent le codes sources assez incompréhensibles et puis il y a pas mal de modes pour surlignés et certaines couleurs ne ressorte pas. Bref il y a encore du boulot ! Mais c'est très motivant comme projet et c'est pour ça que je l'ai choisi.

Et toi tu es entrain de programmer quoi ? Une autre version de Hibview ou c'est la même que tu améliores ? Et en gros c'est quoi ces caractéristiques par rapport à la version actuelle ? Tu vas utiliser les niveaux de gris ?



Là j'ai pas mal avancé depuis la dernière fois. Les alignements marchent enfin correctement : on peut aligner à la fois à droite et à gauche en même temps. J'ai fait pas mal de raffistolage dans le code , mais l'essentiel est que ça marche.
Et puis en attendant la dernière version de TinyX j'utilise GX_DrawChar de GraphX pour la petite font. D'ailleurs si je ne peux toujours pas avoir la derrnière version de TinyX je vais peut-être gardé celle-là mais ça fait que je charge inutilement la petite font de TinyX.

[img]http://perso.wanadoo.fr/raphael.domenge/Espace%20FTP/FTL Parser.gif[/img]

Raphaël :
Bon alors ajouté à cela j'ai encore un autre problème. Chaque ligne que l'on voit à l'écran représente également une ligne dans le tableau. Donc suivant la taille de la font c'est très variable. Alors chaque ligne fait 65 octets mais c'est de la place gaspillé lorsque la ligne n'est pas pleine ou que l'on utilise la grosse font.
Là aussi il faudrait que j'alloue en fonction de sa mais je ne sais pas comment faire. Voila la structure :

typedef struct
{

unsigned char stick_char:2;
unsigned char color:2;
unsigned char center:1;
unsigned char under_line:1;
unsigned char on_line:3;
unsigned char font:2;
unsigned char animate:2;
unsigned char left:2;
unsigned char right:2;
int x:9;
unsigned char lines:1;

}Str_Mode;

typedef struct
{
char chaine[65];
Str_Mode param;

}Text;
...
TEXT=malloc(sizeof(Text)*100);


Il faudrait peut-être j'utilise un pointeur dans la structure comme ça :
typedef struct
{
char *chaine;
Str_Mode param;
}Text;
Et puis que j'alloue pour chaque ligne la place nécessaire. J'ai déjà essayé mais ça a toujours planté !

je sais pas trop quel est ta syntaxe, mais tu pouurais pas tout simplement faire pointer ton char * chaine sur la chaine de caractere dans ton texte ? Certes cela t'oblige ensuite a afficher caratere par caratere, mais au moins ca t'économise de la mem. Parec que sinon, tu pourras jamais afficher un texte qui fait plus de 30 ko...

Et par contre je ne sais pas comment libérer cette mémoire à la fin : il faut le faire de la même manière que je l'ai alloué c'est à dire ligne par ligne ?

eh oui !
[cite]Pour mon Parser ça ne marche pas ça ! La taille du fichier ne représente absolument pas la taille du texte final parce-qu'il y a des lignes de codes qui permettent de définir ses "balises" (c'est pas vraiment des balises en fait), de copier du texte à partir d'un autre fichier, de duppliquer un même caractère... et tout ça fait que ça n'est pas proportionnel.[cite]moi non plus, c'est juste une estimation, que je recalibre lorsque j'etudie le texte

Et toi tu es entrain de programmer quoi ? Une autre version de Hibview ou c'est la même que tu améliores ? Et en gros c'est quoi ces caractéristiques par rapport à la version actuelle ? Tu vas utiliser les niveaux de gris ?

j'ai changé pas mal de chose, je l'améliore oui. Je me pose encore des question sur l'implémentation, donc je préfère ne pas me prononcer sur ce qui va etre dedans. En tout cas, JackosKing va me faire une routine d'affcihage de chaine gras italique pour des font personnalisé : ca c'est à peu pres sur (ca depend de lui e fait) que ca va y etre.

Est-ce que vous pensez que ça peut-être intéressant que je créer un mode "fonction" pour mon programme afin qu'il puisse être utiliser par un autre programme ?
En fait l'autre programme lancerait FTL Parser 2004 et écrirai le nom du fichier à parser dans un fichier temporaire, pour que une fois exécuté, FTL Parser 2004 se mettent en mode fonction (il ferait donc passer l'intro et le menu) et parserai le nom du fichier écrit dans le fichier temporaire ? Bon c'est un peu compliqué tout ça et j'espère que vous comprendrez sinon je peux réexpliquer.
Ca pourrait être utilise pour écrire la doc pour les jeux par exemple.

Il vaut mieux appeler FTL avec des arguments précisant qu'on doit virer l'intro

Ouais je vais peut-être faire comme ça, merci !

J'ai tenter d'allouer la mémoire ligne par ligne et mnt ça marche enfin sans perte de mémoire et j'aurais une petite question :

Au début je déclare le tableau comme ceci :

Text Tableau[500];
avec tjrs la même structure à savoir :

typedef struct
{

unsigned char stick_char:2;
unsigned char color:2;
unsigned char center:1;
unsigned char under_line:1;
unsigned char on_line:3;
unsigned char font:2;
unsigned char animate:2;
unsigned char left:2;
unsigned char right:2;
int x:9;
unsigned char lines:1;

}Str_Mode;

typedef struct
{
char *chaine;
Str_Mode param;

}Text;

Et ensuite au fur et à mesure que le fichier est parsé j'alloue un bloc de mémoire en fonction de la ligne mais j'aimerais savoir ou est stocké le Text Tableau[500]; ? ... Sur le stack ?
Et c'est correct si je fais comme cela ? : Je déclare un tabbleau qui contient la structure (paramètres et pointeurs vers les lignes) sur le stack et ensuite j'alloue au fur et à mesure la mémoire que j'ai besoin pour chaque lignes ?
Bon j'espère seulement qu'il reste encore assez de mémoire sur le stack.
En gros ça doit faire (2+2+1+1+3+2+2+2+2+9+1)*500 = 13500 + taille du pointeur * 500... au fait ça fait combien un pointeur ?
Ca fait bcp tout ça ! A mon avis il ne doit pas y avoir assez de place.

Ça dépend, c'est une var globale ou locale ?
Et la taille de ta structure est de l'ordre de 6 octets à mon avis (fais un sizeof(Str_Mode) pour savoir).

C'est une variable locale il me semble : elle est déclaré dans la fonction main().

Et la taille de ta structure est de l'ordre de 6 octets à mon avis (fais un sizeof(Str_Mode) pour savoir).

Ok.

Si c'est une var locale la place est prise sur la pile.

Sinon elle va où ? Dans le programme ?

Oui

Depuis que j'alloue la mémoire ligne par ligne et au fur et à mesure que le texte est parsé, c'est beaucoup plus lent : au début ça va assez vite et puis ça ralenti de plus de plus lors de l'interprétation du fichiers. C'est très net avec les gros fichiers.
C'est normal ? Il y a un truc pour éviter ça ?

Tu fais des realloc ou bien tu fais plusieurs malloc ?

Si tu as besoin d'un bloc contigu, tu peux utiliser realloc avec comme incrémentation de taille non pas 'size+=1000' mais plutôt 'size+=1000+(size>>2)'.
Sinon, comme le sous-entend Sasume, le mieux serait de faire une liste chaînée de blocs de taille fixe.

Tu fais des realloc ou bien tu fais plusieurs malloc ?

Non je fais un alloc pour chaque ligne du tableau.
Il vaudrait mieux que j'utilise realloc ? Enfin là c'est plus possible parce-que je n'alloue plus d'un coup mon tableau comme avant mais j'alloue un bloc par ligne lors de l'interpretation du fichier afin de calculer précisément la bonne quantité de mémoire qu'il faut allouer.

Sinon, comme le sous-entend Sasume, le mieux serait de faire une liste chaînée de blocs de taille fixe.

Heu... comment ça ? Au début j'allouait un bloc de taille fixe par ligne mais il fallait faire pour le nombre maximum de caractère par ligne avec la petite fonte et les caractères serrés (c'est un paramètre). Ca faisait beacoup trop de mémoire, surtout que c'est très rare d'utiliser ça dans un fichier TEXT.

Et alors c'est normal si ça ralentit au fur et à mesure que le texte est parsé ? C'est parce-qu'il y a moins en moins de mémoire disponible ?

Et puis sinon j'aurais une autre question : Je vais peut-être (enfin c'est prévu) faire de mon programme une fonction qui pourra aussi bien être utilisé par les programme BASIC que les programmes C.
Bon pour le BASIC ça devrai être facile mais pour exécuté mon programme depuis un autre programme C avec un argument c'est possible ? Je sais qu'il est facilement possible d'exécuter un autre programme mais avec un argument, ça je ne vois pas trop comment faire.

Et puis sinon vous en pensez quoi de la synatxe du language ? ... Bon je vous rassure maintenant le formatage ne se fait plus comme avant c'est à dire plus ligne par ligne. D'ailleurs il faudra que je mettent la doc à jour.

Raphaël
:

Tu fais des realloc ou bien tu fais plusieurs malloc ?

Non je fais un alloc pour chaque ligne du tableau.
[...] Et alors c'est normal si ça ralentit au fur et à mesure que le texte est parsé ? C'est parce-qu'il y a moins en moins de mémoire disponible ?

Oui ! cf ce topic : topics/16-28731-avez-vous-deja-remarquez-que (dont tu es l'auteur )
Si tu utilises realloc, tu n'auras pas ce problème.
Ce que je te conseille, c'est de faire une première allocation, en fonction de la taille du fichier, et de l'augmenter au fur et à mesure (avec des grands pas), si ça ne suffit pas.

Heu... comment ça ? Au début j'allouait un bloc de taille fixe par ligne mais il fallait faire pour le nombre maximum de caractère par ligne avec la petite fonte et les caractères serrés (c'est un paramètre). Ca faisait beacoup trop de mémoire, surtout que c'est très rare d'utiliser ça dans un fichier TEXT.

Non, je voulais dire faire une liste chaînée de blocs de 2 ko par exemple, et lorsque tu veux allouer qqch (pour une ligne), tu regardes si tu as assez de place pour le rajouter à l'intérieur du dernier bloc de 2ko alloué, si oui c'est bon, sinon tu alloues un autre bloc de 2ko et ainsi de suite. Ca t'évite des realloc trop nombreux, et qui peuvent ralentir au fur et à mesure que ton bloc devient plus gros. En plus, tu n'as plus de limite des 64k.

Je pensais pas que ça avait un rapport. J'avais déjà vu que c'est plus lent surtout si l'écran home était bien rempli mais je savais pas que plus on utilisais malloc plus c'était lent.
Il va falloir que j'essaye avec realloc alors mais il faudra qd même que je le fasse aussi souvent qu'avec malloc pour avoir une quantité de mémoire précise.
Et au fait avec realloc, est-ce que ce qui est enregustré avant est détruit ? Normalement non ? Une fois j'avais essayé mais ça foirait pas mal.

de l'augmenter au fur et à mesure (avec des grands pas), si ça ne suffit pas.

Et si je ne le fais pas avec des grands pas ça revient au même ou pas ?

Raphaël
: Et au fait avec realloc, est-ce que ce qui est enregustré avant est détruit ? Normalement non ? Une fois j'avais essayé mais ça foirait pas mal.

La réponse est dans la doc.

Et si je ne le fais pas avec des grands pas ça revient au même ou pas ?

Oui. Enfin, il y a quand même des différences. Je te laisse les trouver tout seul.
Si la limite des 64ko te gêne, la solution de Pollux est bien.

Il va falloir que j'essaye avec realloc alors mais il faudra qd même que je le fasse aussi souvent qu'avec malloc pour avoir une quantité de mémoire précise.

De toute façon ce n'est pas un problème d'allouer 3 ko de trop si ton prog demande un truc du genre 20 ko (et il faut compter en plus la taille du prog dans la RAM demandée, donc 3 ko ça risque d'être vraiment négligeable).
Evidemment il faut faire attention de ne pas allouer 3 ko en trop pour chaque ligne sinon ce n'est plus du tout négligeable

Et au fait avec realloc, est-ce que ce qui est enregustré avant est détruit ? Normalement non ? Une fois j'avais essayé mais ça foirait pas mal.

Oui. En fait realloc(p,s) est grosso modo équivalent à { void *q=malloc(s); if (q) memcpy(q,p,s); free(p); return q; }, donc si tu utilise un bloc de 60 ko, un realloc dessus va nécessiter 120 ko de RAM ! C'est pour ça que si tu as besoin de pas mal de mémoire, ma méthode de blocs est plus adaptée. Si tu n'en as pas besoin de bcp, realloc va peut-être avoir l'avantage d'être légèrement plus simple.

Ouais mais alors là j'ai encore un autre problème qui se pose lorsque j'utilise realloc : je ne sais pas quel structure utilisé.
Avant j'utilisais cette structure :
typedef struct
{
char *chaine;
Str_Mode param;

}Text;
et j'allouais au fur et à mesure la mémoire, mais alors là je ne sais pas comment faire.
Il faudrait que j'indique une valeur pour la chaine du genre :
typedef struct
{
char chaine[65];
Str_Mode param;

}Text;

Mais ça va me bouffer 3 fois plus de mémoire que ce qu'il m'en faut habituellement !
Il faut que je fasse comment comme je ne connais pas à l'avance la taille que va faire la chaîne ?

Là à chaque fois qu'il y a besoin d'utiliser realloc ça plante pourtant je laisse suffisament de mémoire à chaque fois.
Finalement je vais peut-être revenir à la source précédenrte qui utilisais malloc() et puis ça ira bien comme ça.

Pollux
: Sinon, comme le sous-entend Sasume, le mieux serait de faire une liste chaînée de blocs de taille fixe.

N'importe quoi. Les listes chaînées sont à proscrire dans un environnement 1. sans MMU (fragmentation!) et 2. à nombre de handles très limité.

Pollux
:

Heu... comment ça ? Au début j'allouait un bloc de taille fixe par ligne mais il fallait faire pour le nombre maximum de caractère par ligne avec la petite fonte et les caractères serrés (c'est un paramètre). Ca faisait beacoup trop de mémoire, surtout que c'est très rare d'utiliser ça dans un fichier TEXT.

Non, je voulais dire faire une liste chaînée de blocs de 2 ko par exemple, et lorsque tu veux allouer qqch (pour une ligne), tu regardes si tu as assez de place pour le rajouter à l'intérieur du dernier bloc de 2ko alloué, si oui c'est bon, sinon tu alloues un autre bloc de 2ko et ainsi de suite. Ca t'évite des realloc trop nombreux, et qui peuvent ralentir au fur et à mesure que ton bloc devient plus gros. En plus, tu n'as plus de limite des 64k.

Pas génial comme idée. Des tonnes de blocs de 2 KO chacun = mémoire très fragmentée.

Pollux
:

Et au fait avec realloc, est-ce que ce qui est enregustré avant est détruit ? Normalement non ? Une fois j'avais essayé mais ça foirait pas mal.

Oui. En fait realloc(p,s) est grosso modo équivalent à { void *q=malloc(s); if (q) memcpy(q,p,s); free(p); return q; }, donc si tu utilise un bloc de 60 ko, un realloc dessus va nécessiter 120 ko de RAM !

Pas sous TIGCCLIB. Notre realloc est implémenté en termes de HeapRealloc. Ce n'est pas entièrement conforme au standard ANSI (le bloc est libéré quand la mémoire est insuffisante, alors que le standard prévoit qu'il ne soit pas touché), mais ça évite exactement ce problème.

N'importe quoi. Les listes chaînées sont à proscrire dans un environnement 1. sans MMU (fragmentation!) et 2. à nombre de handles très limité.

Tu te fous de ma gueule? Je sais parfaitement ce que je dis, relis mes posts si tu n'as pas compris. Pour atteindre le 10ème de 2000 handles avec des blocs de 2 ko, il faut allouer 400 ko

Pas génial comme idée. Des tonnes de blocs de 2 KO chacun = mémoire très fragmentée.

Mais n'importe quoi! Il a besoin d'allouer de la mémoire pour chaque ligne, or une ligne = au maximum en small font avec que des 'i', 80 octets. La perte est au plus de 4% (et même si chaque ligne était composée de 'i', on en perdrait en moyenne seulement la moitié).

Pas sous TIGCCLIB. Notre realloc est implémenté en termes de HeapRealloc. Ce n'est pas entièrement conforme au standard ANSI (le bloc est libéré quand la mémoire est insuffisante, alors que le standard prévoit qu'il ne soit pas touché), mais ça évite exactement ce problème.

Hmm... Il m'avait semblé que HeapRealloc allouait un nouveau bloc à la barbare, mais je me suis peut-être trompé (c'était y a lgtps )

Ceux qui ont analysé le HeapRealloc de AMS ont conclu qu'il est au contraire très "intelligent".

Et sinon pour lire un fichier, il y a moyen de le lire directement à l'endroit où il est par un pointeur de lieu de le chargé comme je fais dans un buffer ?

oui
Suffit de recuperer le handle du fichier et de faire une "dereference" dessus et tu auras un pointeur ( si la TI se met a reordonner la RAM tu risque d'avoir un pointeur invalide... CF la doc pour savoir comment y remedier)

D'accord merci.

C'est bon si je fais comme ça ? :
SYM_ENTRY *sym = SymFindPtr (SYMSTR (Name_File), 0);
unsigned char *Buffer_File = HeapDeref (sym->handle);

Bon par contre il y a des pertes de mémoire. Il faut faire un HeapFree() ou un truc comme ça non ?

Utilise HLock, pas HeapDeref, sinon à la prochaine réorganisation de la RAM, ben...