FTL Parser 2004 - Page 1

Voici donc mon nouveau projet pour Ti89 : FTL Parser 2004.
Il s'agit donc d'un parser de fichier TEXT qui interptète un "langage de formatage de texte" afin d'afficher des pages en niveaux de gris avec du texte animé.
Vous trouverez l'ensemble des caractéristiques et détails du projet sur cette page :
http://perso.wanadoo.fr/raphael.domenge/programmes_ti89/projet_ftl_parser/ftl_parser2004.htm

Voici un petit shot pour vous faire une idée du programme :

Ouf il marche enfin !

l'image risque pas de passer là, vu que t'as donné l'url de ton ftp

C'est assez impressionnant le scrolling et le texte qui défile.
Chapo c'est vraiment cool. Par contre il est possible de changer la police d'un document?

Oui c'est possible vu qu'il gère les 3 fonts. Sinon pour la vitesse du scrolling il faut dire merci à TinyX !

Bon sinon je vais profiter de topic pour poser mes questions afin de résoudre mes problèmes.
Il y en a que je n'arrive pas à résoudre : dans mon programme j'ai un chargeur de fichier qui fait planter le programme lorsque preos est installé et qu'au moins un fichier est installé.
Parce-qu'en fait afin de reconnaître les types de fichiers, mon programmes les ouvrent tous un par un pour tester la première ligne du fichier.
Il n'y aurait pas quelqu'un qui sait ce quoi cela peut venir et ce que je pourrais faire. Je précise aussi qu'avec d'autre kernel je n'ai pas de pb.

As-tu essaye d'avoir les fichiers de preos et d'essayer avec un autre kernel installe ?

ce programme est superbe !! Mais ca ne serait pas possible d'implementer une compatibilité avec les textes au format Txtrider/Hibview ?

Ou un convertisseur ?

As-tu essaye d'avoir les fichiers de preos et d'essayer avec un autre kernel installe ?

Ah, non il ne me semble pas. Parce-que tu penses que ça vient de quoi ?

ce programme est superbe !!

merci !

Mais ca ne serait pas possible d'implementer une compatibilité avec les textes au format Txtrider/Hibview ?

il ne faut pas oublier Text Walker de Brunni.

Si j'y est pensé mais je pense que Txtrider et Hibview suffisent largement (ce sont de superbes programmes) et mes objectifs de départ n'était pas les mêmes.

mais je pense qu'un convertisseur serait possible. En travaillant sur les chaines de caractères et en recherchant les balises.
Je vais essayer de faire ca en C mais vu mon niveau je ne pense pas arriver a un truc super. Mais ca peut etre marrant a faire. Je vais essayer ce week end je pense. Mais bon faut pas que, je m'emballe

Je pensais déjà faire un convertisseur html. Ca ne doit pas être trop compliqué. je n'ai déjà pas fait directement du html parce-que je ne savais aps comment j'allais formaté tout ça et puis comme je voulais ajouter pleins de trucs et faire plutôt un "langage" je me suis orienté vers le format que j'utilise actuellement.

golstein
: Je vais essayer de faire ca en C

fais le plutot en C++ : tu pourras utiliser la classe String, tu te feras moins ch***
(A moins que tu ne veuilles t'entrainer avec les char * )

J'ai amélioré encore un peu l'édition du programme : maintenant si une même une série de paramètres ou un même mode d'affichage est utilisé sur plusieurs lignes vous n'êtes plus obligé d'attribuer le mode d'affichage ou la série de paramètre. Vous n'avez qu'à encarder votre texte avec des " et les attributs du texte sont conservés d'une ligne à l'autre.

Par exemple au lieu de taper :
#def<TXT>={f2,c2,sc}
"Voici mon la ligne de texte 1"=<TXT>
"Voici mon la ligne de texte 2"=<TXT>
"Voici mon la ligne de texte 3"=<TXT>
...
vous ne taper plus que :

#def<TXT>={f2,c2,sc}
"Voici mon la ligne de texte 1"=<TXT>
"Voici mon la ligne de texte 2"
"Voici mon la ligne de texte 3"

Par contre je n'ai toujours pas résolu le problème de plantage lorsque avec preOs.

il ne faut pas oublier Text Walker de Brunni.

Merci
J'avais effectivement fait quelques convertisseurs, et je pense qu'il s'agit d'une solution correcte pour les lecteurs qui n'utilisent pas la syntaxe de txtrider. (le nombre de cours qui sont à ce format...)
Sinon je t'avoue que je suis impressionné par ton shot. Bon il y a le scrolling que perso je n'aime pas trop (en tous cas s'il est comme dans hibtext) car tu te perds assez facilement, mais bon s'il y a un mode page par page comme hibview, y'a pas de prob
Sinon je peux te filer la source du convertisseur HTML, mais c'est du QBasic...
Et tu dis que ça tourne en IDLE, mais comment tu fais en nvg, parce que si tu mets le timer à 0xff (tourne très rapidement) ta calc passera plus de temps à se mettre en idle qu'à vraiment économiser des piles...

J'ai lu ton truc, c'est marrant. Maintenant ça semble un peu fastidieux... un menu pour organiser ses cours. Ca peut ressembler à ça.#Menu Electrotechnique Puissance  Formule   Forme de base;f1   Spécial;f2 Examen;haha #FinMenu #Texte :f1 iE P=U*Ii :f2 #Lit cours\spécial :haha ©I1Faut pas rêver! #FinTexteJe vais encore faire le prétentieux, mais ça me fait penser à un de mes projets. C'est en partie du code text walker, mais avec des commandes supplémentaires. Le but est surtout de faire

Sinon je t'avoue que je suis impressionné par ton shot.

Ah, bon ? C'est quoi qui t'impressionnes ?! Il n'y a rien de très compliqué dans l'affichage.
Et par contre le langage tu le trouves comment parce-qu'en réalité c'est ça le plus important je pense. (je ne m'attend pas à un éloge cette fois ! )
Par contre j'ai encore pas mal de truc à ajouter au langage.

Bon il y a le scrolling que perso je n'aime pas trop

Oui je m'en suis parfaitement rendu compte et je vais essayer de trouver la meilleur solution pour y remédier. Mais pour l'instant mon programme n'est aps très avancé bien qu'il soit parfaitement fonctionnel. J'attends les récations de votre part pour savoir comment continuer le développement du programme.

Sinon je peux te filer la source du convertisseur HTML, mais c'est du QBasic...

Merci, c'est gentil, mais par contre je ne connais pas le Qbasic... mais bonj ça ne doit pas être très dur à comprendre. par contre ce qui m'intéresse c'est de la manière dont tu as programmé ça.

Et tu dis que ça tourne en IDLE, mais comment tu fais en nvg

Je fais comme Kevin m'a indiquer :

void gray_idle(void)
{
pokeIO(0x600005,0b10111);
}

Voilà comment je fais avec le timer :
if(!timer) // si le timer à expiré
{
OSFreeTimer(USER_TIMER);
OSRegisterTimer(USER_TIMER,4);
timer = 1;
}
while(timer==1 && !keys_push) // tant que le timer n'a pas expiré et qu'aucune touche n'a été pressé
{
gray_idle(); // réduit la consommation des piles

timer=!OSTimerExpired(USER_TIMER); // vérifie l'état du timer
keys_push=(_keytest(RR_UP)||_keytest(RR_DOWN)||_keytest(RR_ESC));
}
keys_push=0;

Tu en penses quoi ? C'est valable ou pas.
Sinon pour le menu par exemple c'est une simple boucle qui teste si la touche ESC est pressé ou non et dans la boucle je met la fonction gray_idle().

Maintenant ça semble un peu fastidieux...

C'est quoi qui te semble fastidieux ? Parce-que j'ai vraiment fait au plus simple : si il y a une erreur de syntaxe, le programme ne va pas la repérer de même qu'il ne va pas vérifier si c'est bien une virgule qui séparent les paramètres.

Ah, bon ? C'est quoi qui t'impressionnes ?! Il n'y a rien de très compliqué dans l'affichage.

Non, c'est joli et le défilement, le texte défilant, ombré et tout en niveaux de gris, c'est super!

Oui je m'en suis parfaitement rendu compte et je vais essayer de trouver la meilleur solution pour y remédier. Mais pour l'instant mon programme n'est aps très avancé bien qu'il soit parfaitement fonctionnel. J'attends les récations de votre part pour savoir comment continuer le développement du programme.

Perso, je pensais à un défilement ligne par ligne (et pas continu) comme tu fais sur PC avec les barres de défilement. L'écran de la TI est trop lent et un scrolling comme ça n'est pas très adapté... Mais ce n'est qu'un avis personnel hein! Je sais qu'il y en a (hibou je t'attends) qui trouvent le scrolling ainsi très adapté.

Merci, c'est gentil, mais par contre je ne connais pas le Qbasic... mais bonj ça ne doit pas être très dur à comprendre. par contre ce qui m'intéresse c'est de la manière dont tu as programmé ça.

La source (tu peux la compiler avec n'importe quelle version de QB je crois, que tu l'as peut-être même sur ton PC, car il était inclus au DOS)
La manière de base n'est pas compliquée. Tu peux toujours détecter un format avec text walker, ça commence par un ©. Il suffit de convertir la suite en HTML, en RTF ou en txtrider:
Balise Text Walker: ©I1
Balise Txtrider: (n'existe pas) -> un warning pour la route!
Balise HTML: <i>
Balise RTF: \i (pas sûr)
Comme tu le vois, il suffit de remplacer les balises par leurs correspondantes, et les autres caractères sont écrits tels quels dans le fichier de sortie. Comme le fonctionnement de tous ces "langages" est séquenciel (tu lis et affiches des lettres dans le format courant tant que tu ne rencontres pas caractère de format spécial), il n'y a aucun problème, cependant cela risque d'être plus compliqué chez toi. Mais bon, mes convertisseurs sont dépassés maintenant car Text Walker a beaucoup trop de spécialités (on aurait tort de ne pas en profiter d'ailleurs) et il est très difficile de le faire en HTML (macros, lignes, rectangles, fenêtres, ...) déjà les styles, c'est le gros bordel à convertir, et il y a tout de même un support natif pour les macros, mais pas pour les arguments (faut pas rêver!)

C'est quoi qui te semble fastidieux ? Parce-que j'ai vraiment fait au plus simple : si il y a une erreur de syntaxe, le programme ne va pas la repérer de même qu'il ne va pas vérifier si c'est bien une virgule qui séparent les paramètres.

Non, le problème n'est pas là. C'est juste que:
#def<TXT>={c2,f2,sc}
"FTL PARSER 2004 est le nom d'un"=<TXT>
"programme pour TI89 qui permet"=<TXT>
"de parser des fichiers TEXT au"=<TXT>
Me semble beaucoup plus compliqué que:
FTL PARSER 2004 est le nom d'un programme pour TI89 qui permet de parser des fichiers TEXT au
Comme on l'aurait fait avec Txtrider. Et là tu dois toi-même décomposer les lignes? Enfin, tu vois...

Non, le problème n'est pas là. C'est juste que: ...

Oui c'est là la grosse faiblesse. En fait je gère tout ligne par ligne et non pas caractères par carctères. Pour le moment je ne vois pas trop comment faire pour que le programme décompose lui même les lignes avec les 3 fonts et tous les modes.
C'est vraiment le truc qui m'ennuie le plus mais je vais essayer de corriger ça.

L'écran de la TI est trop lent et un scrolling comme ça n'est pas très adapté...

Encore sur le shot ça va mais en vrai le texte qui défile est assez flou et c'est d'ailleurs pour ça que je le fait défiler aussi lentement.
Au pire je peux intégrer une commande qui permet de régler la vitesse du texte.

Tu as regardé la source?

Oui c'est là la grosse faiblesse. En fait je gère tout ligne par ligne et non pas caractères par carctères. Pour le moment je ne vois pas trop comment faire pour que le programme décompose lui même les lignes avec les 3 fonts et tous les modes. C'est vraiment le truc qui m'ennuie le plus mais je vais essayer de corriger ça.

Tu pourrais simplement faire défiler de 8 lignes à chaque fois, c'est la hauteur de la fonte normale. Sinon tu dois bien savoir quelle ligne devra venir en bas ou en haut de l'écran lorsque tu fais défiler, donc tu peux prendre cette taille pour un défilement de cette ampleur...

Tu as regardé la source?

oui. C'est bien plus compliqué que ce que je croyais.

Tu pourrais simplement faire défiler de 8 lignes à chaque fois

oui mais il y a aussi la grosse font qui fait plus. Surtout quand elle est souligné.

J'ai commencé à refaire mon parser intégralement : cette fois il sera beaucoup plus élaborer tout en supportant le même langage sauf que l'on ne sera plus obligé de décomposer le texte en ligne lorsqu'il y en a pas besoin (je sens que pour les alignements ça va être chaud ! )
Depuis le début de l'après midi j'avais un gros bug dans mon programme qui le faisait planté. Je me rend compte maintenant que je comptait le nombre de retour à la ligne du fichier TEXT pour savoir combien de lignes il fallait allouer dans le tableau qui contient le texte formaté. Et comme maintenant il y a moins de retour à la ligne qui de ligne afficher à l'écran bah forcément il manque de la mémoire.
Alors je voulais savoir comment je pourrais faire pour allouer une quantité de mémoire précise pour rentrer mon texte formaté et surtout en fonction de la place que ça va prendre. Parce-que je ne vais pas allouer un tableau de 64 ko pour un texte de 1 ko à parser.
... Quelqu'un aurait une idée ? En attendant je vais continuer à refaire le parser.

Bon bah voilà j'ai complètement reprogrammé le paser pour ne plus avoir à formater lignes par lignes !
Par contre j'aurais besoin de savoir d'après le post 15 si ça vaut le coup ou pas que je mette l'idle ou pas vu que j'utilise un timer pour faire défiler texte et que lorsque l'on se déplace pour lire le texte il est souvent utilisé pour rien ?

Alors je voulais savoir comment je pourrais faire pour allouer une quantité de mémoire précise pour rentrer mon texte formaté et surtout en fonction de la place que ça va prendre. Parce-que je ne vais pas allouer un tableau de 64 ko pour un texte de 1 ko à parser.

HeapRealloc?

Par contre j'aurais besoin de savoir d'après le post 15 si ça vaut le coup ou pas que je mette l'idle ou pas vu que j'utilise un timer pour faire défiler texte et que lorsque l'on se déplace pour lire le texte il est souvent utilisé pour rien ?

Ca vaut toujours le coup. Franchement c'est une fonctionnalité que tu ne dois pas oublier car souvent on laisse sa calculatrice allumée avec un cours affiché, et là il ne faudrait pas que ça bouffe les piles.

HeapRealloc?

Elle à quoi de plus que malloc() cette fonction ?
Bon je me suis peut-être mal exprimé : maintenant que je ne formate plus ligne par ligne il m'est impossible de savoir à l'avance la taille du tableau à alloué (c'est fonction du texte à affiché mais çe n'est pas organisé pareil suivant la taille de la font).
Mais, bon ça ne doit pas être trop compliqué de créer une fonction qui va calculer la quantité précise de mémoire.

Ca vaut toujours le coup. Franchement c'est une fonctionnalité que tu ne dois pas oublier car souvent on laisse sa calculatrice allumée avec un cours affiché, et là il ne faudrait pas que ça bouffe les piles.

Oui mais tout les 1/5 de seconde il n'est plus utilisé car il faut affiché le texte animé. Mais ça ne fait rien quand même ?

Raphaël
:

HeapRealloc?

Elle à quoi de plus que malloc() cette fonction ?

Ça.
Enfin, je ne pense pas que ce soit une bonne idée d'utiliser beaucoup d'HeapRealloc parce que ça risque de ralentir pas mal.

Personnellement, quand j'ai une chaîne de caractères de taille variable à gérer, en général, je fais un HeapRealloc à chaque modification. AutoClBr faisait un HeapRealloc à chaque parenthèse fermée jusqu'à la version 1.04 (les nouvelles versions utilisent un algorithme un peu différent qui permet de calculer la taille à l'avance), et on ne le remarquait même pas (même avec des milliers de parenthèses à fermer).

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...
Mais si j'ai bien compris, il ne le ferait qu'au début, donc ça ne gêerait pas du tout (puisque le temps mis sera quand même très rapide, bien que ça ralentisse).

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.

sinon, tes questions, ton entrain,... me rappelle qd je commancais a faire hibtext. Je pensais pas que j'arriverais a faire ce que je voulais faire, et au fur et a mesure, j'y arrivais qd meme. Maintenant, plus rien ne m'arrete, je pense meme que je programme trop et teste de moins en moins.... D'ailleurs, ca fait encore un nv concurrent a hibview... ca me motive pour continuer !

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

Bah, tu n'es pas le seul. Il n'y a qu'à voir les routines de floats de TIGCC 0.95 bêta 2. La multiplication et la division en temps de compilation ne marchent pas du tout. Ça sera corrigé dans la bêta 3.