Forum de Ti-Gen.org, le site francophone des TI

Bienvenue Invité ! Se connecter Mes sujets	Administrer
Utilisateurs actifs : Aucun membre + 1 visiteur

Avant de poster sur le forum, il y a des régles de bases à respecter pour une bonne entente et un respect de tous.
Veuillez lire la charte du forum.

:: Index » GFA-Basic TI68K » News » Développement du futur GFA-Basic (59 réponse(s))

./REPRISE DU POST PRECEDENT (post n°38) Marquer comme non lu.

geogeo

Ecrit le: Lundi 11 septembre 2006 à 15:23

Fondateur

Groupe: Staff de Ti-Gen

Groupe: Orage Studio

Messages: 4258

Membre n°3

Inscrit le 29 janvier 2004

L'algo que j'utilise (l'algorithme de l'aiguillage (shunting algorithm) de Dijkstra) pour passer de la notation infixe à la notation postfixe se présente en gros de cette façon:
Dès que je vois un nombre, une variable, une chaîne de caractères, les signes spécifiques aux instructions Print et Input ou encore un marqueur End Tag. Ils sont directement mis dans la pile d'opérandes. La virgule est ignoré donc 5,4 revient au même que 5 4. Dès que je rencontre le signe * par exemple je regardes la pile d'opérateurs pour savoir si * à une priorité élevé qui lui permet d'être extrait de suite par rapport à un autre opérateur. Admettons que * est extrait. Dans ce cas je vérifie si la pile d'opérandes contient 2 opérandes valides...
Bien sûr il y a un moyen de vérifier que * est valide ou non syntaxiquement mais vérifier ceci durant la phase de création de la notation postfixe risque de compliquer l'algo pour pas grand chose.
Je peux bien entendu auparavant détecter les erreurs de syntaxe mais je devrais tenir compte des opérateurs unaires des exceptions et franchement d'après l'expérience de GFA Basic v1 cela demande pas mal de tests... sachant que nous sommes sur une plateforme limité en mémoire et notamment avec un processeur avec une fréquence assez faible, ma stratégie est de founir un parseur le plus compact et le plus rapide possible et un interpréteur respectant les mêmes conditions au détriment de certaines régles syntaxique.
Encore une fois le code que j'ai exposé représente le seule et unique cas d'acceptation de code mal organisé.

-Edité le Lundi 11 septembre 2006 à 15:24 par geogeo-

Webmaster du site.
Programmeur sur TI68K. Arkanoid, Nebulus, GFA-Basic.

Plus d'informations sur GFA-Basic (un langage Basic pour TI68K).
http://www.tigen.org/gfabasic

./Post n°39 Marquer comme non lu.

Pollux

Ecrit le: Lundi 11 septembre 2006 à 16:06

Membre: Vétéran

Messages: 95

Membre n°306

Inscrit le 11 juin 2004

ben en fait quand tu empiles * il te suffirait d'empiler aussi la profondeur de la pile d'opérandes : comme ça quand tu dépileras le * il suffira de vérifier que la profondeur de la pile d'opérandes est supérieure de 1 à la profondeur qu'elle avait au moment de l'empilement -- i.e. que * a bien un et un seul argument supplémentaire... (et accessoirement ça te permettra de faire la distinction entre entier*entier et pointeur*, ton parseur sera donc plus puissant)

./Post n°40 Marquer comme non lu.

geogeo

Ecrit le: Lundi 11 septembre 2006 à 16:56

Fondateur

Groupe: Staff de Ti-Gen

Groupe: Orage Studio

Messages: 4258

Membre n°3

Inscrit le 29 janvier 2004

Je n'avais pas penser à ça. Je vais donc implémenter cette idée.

Webmaster du site.
Programmeur sur TI68K. Arkanoid, Nebulus, GFA-Basic.

Plus d'informations sur GFA-Basic (un langage Basic pour TI68K).
http://www.tigen.org/gfabasic

./Post n°41 Marquer comme non lu.

Kevin Kofler

Ecrit le: Mardi 12 septembre 2006 à 00:26

Administrateur

Groupe: Staff de Ti-Gen

Messages: 4814

Membre n°40

Inscrit le 08 février 2004

Tiens, l'algo que tu as choisi ressemble beaucoup à mon bidouillage pour Tokens89, ça me fait plaisir d'entendre que Dijkstra a eu cette idée aussi.

Cela dit, cet algorithme n'est pas utilisé dans les parseurs modernes pour de bonnes raisons, et la détection d'erreurs en est une. Je parle d'expérience quand je dis qu'un parseur sans détection d'erreurs, c'est ch**nt. Tu fais une faute banale, et hop, tu as un programme qui fait n'importe quoi ou plante carrément, et bonne chance pour trouver l'erreur. (C'est encore pire dans le cas de Tokens89 vu que ça peut donner des programmes qui ne se détokénisent plus. Dans GFA au moins, personne ne s'attend que ce soit détokénisable.

) Au fait, une des raisons pour lesquelles Tokens89 ne fait pas de détection d'erreurs est qu'il y a au moins 5 phases de preprocessing pour gérer les cas particuliers de la syntaxe du TI-BASIC, donc ce que voit le parseur n'est plus ce que l'utilisateur a rentré, et des erreurs ont déjà été masquées par le preprocessing. Au moins (d'après la description) GFA n'a pas ce hack.

Je te conseille de te documenter sur le parsing LL et/ou LR. Le LL est plus adapté au parsing "à la main", le LR est mieux pour les parseurs autogénérés. Idéalement, tu devrais porter Flex et Bison pour TIGCC, ça serait utile à tout le monde qui a besoin de parser quelque chose avec TIGCC, pas seulement GFA, et ça te permettrait de faire un parseur beaucoup plus fiable beaucoup plus rapidement.

Membre de l'équipe de TIGCC: http://tigcc.ticalc.org
Mainteneur du portage Linux/Unix de TIGCC: http://tigcc.ticalc.org/linux/
Membre de l'équipe de CalcForge: http://www.calcforge.org:70/

Participez à la reprise de Ti-Gen!

./Post n°42 Marquer comme non lu.

geogeo

Ecrit le: Mardi 12 septembre 2006 à 21:12

Fondateur

Groupe: Staff de Ti-Gen

Groupe: Orage Studio

Messages: 4258

Membre n°3

Inscrit le 29 janvier 2004

J'ai déjà regardé Bison et Flex et je pense que sérieusement ce n'est pas adapté à notre plateforme. Ce serait bien trop volumineux pour des utilisations de syntaxes banales.
Avant de coder directement un algo qui puisse me permettre de passer de la notation infixe à la notation postfixe, j'ai fait quantité de recherches et je me suis documenté sur les différentes grammaires. La grammaire LL m'a beaucoup plu mais j'ai cherché une solution qui m'évitait de construire un arbre syntaxique (je voulais un truc rapide et qui consomme très peu de mémoire).
Dans GFA Basic v1 la gestion des erreurs était assez indigeste (quantité de conditions lors de la notation infixe...) mais en regardant de près avec GFA Basic v2 je n'ai que plus vraiment de tests lors de la notation infixe. Tout ce fait lors d'une "simulation" de la validité de la notation postfixe avec des optimisations basiques au passage (genre 3*3 = 9 ou encore ajouter un opérateur correct entre 5constante (ici l'opérateur de multiplication)).
Mais c'est vrai que l'algo de Dijkstra nécessite de faire des bidouilles sur la notation postfixe (genre ajouter des parenthèses, ajouter des tags...).

Mais il est clair que si je codes un langage sur PC j'utiliserais Flex et Bison avec un parsing bien plus évolué.
En tout cas le code de GFA Basic v2 est bien plus structuré et surtout bien commenté pour que lorsque j'ajouterais une fonctionnalité je ne me casse pas la tête.

Avec l'idée de Pollux, maintenant toutes les syntaxes invalides sont détectées.

Webmaster du site.
Programmeur sur TI68K. Arkanoid, Nebulus, GFA-Basic.

Plus d'informations sur GFA-Basic (un langage Basic pour TI68K).
http://www.tigen.org/gfabasic

./Post n°43 Marquer comme non lu.

Pollux

Ecrit le: Mercredi 13 septembre 2006 à 00:41

Membre: Vétéran

Messages: 95

Membre n°306

Inscrit le 11 juin 2004

de toute façon c'est exactement le même mécanisme qu'un parseur LL classique comme celui-là :

primary() {
  if (val = parse(String | Number))
    return Leaf(val);
  else
    throw error;
}
mult() {
  result = primary();
  while (op = parse(* | /))
    result = Node(op,result,primary());
  return result;
}
expr() {
  result = mult();
  while (op = parse(+ | -))
    result = Node(op,result,mult());
  return result;
}

On peut garder rigoureusement la même structure en générant à la place une expression RPN :

primary() {
  if (val = parse(String | Number))
    rpn << val;
  else
    throw error;
}
mult() {
  primary();
  while (op = parse(* | /))
    primary(), rpn << op;
}
expr() {
  mult();
  while (op = parse(+ | -))
    mult(), rpn << op;
}

./Post n°44 Marquer comme non lu.

geogeo

Ecrit le: Mercredi 13 septembre 2006 à 19:39

Fondateur

Groupe: Staff de Ti-Gen

Groupe: Orage Studio

Messages: 4258

Membre n°3

Inscrit le 29 janvier 2004

ok merci pour ton aide

Webmaster du site.
Programmeur sur TI68K. Arkanoid, Nebulus, GFA-Basic.

Plus d'informations sur GFA-Basic (un langage Basic pour TI68K).
http://www.tigen.org/gfabasic

./Post n°45 Marquer comme non lu.

geogeo

Ecrit le: Mardi 19 septembre 2006 à 20:09

Fondateur

Groupe: Staff de Ti-Gen

Groupe: Orage Studio

Messages: 4258

Membre n°3

Inscrit le 29 janvier 2004

tama> Désolé j'ai pris un peu de retard. Il me reste une étape de développement avant que tu puisses faire des tests.
-Edité le Mardi 19 septembre 2006 à 20:09 par geogeo-

Webmaster du site.
Programmeur sur TI68K. Arkanoid, Nebulus, GFA-Basic.

Plus d'informations sur GFA-Basic (un langage Basic pour TI68K).
http://www.tigen.org/gfabasic

./Post n°46 Marquer comme non lu.

tama

Ecrit le: Mercredi 20 septembre 2006 à 13:47

Membre: Membre

Messages: 41

Membre n°1384

Inscrit le 13 juin 2006

./Post n°47 Marquer comme non lu.

tama

Ecrit le: Dimanche 24 septembre 2006 à 21:36

Membre: Membre

Messages: 41

Membre n°1384

Inscrit le 13 juin 2006

ça avance ?

./Post n°48 Marquer comme non lu.

geogeo

Ecrit le: Lundi 25 septembre 2006 à 20:27

Fondateur

Groupe: Staff de Ti-Gen

Groupe: Orage Studio

Messages: 4258

Membre n°3

Inscrit le 29 janvier 2004

J'ai un bug assez génant que je n'arrive pas à corriger, cf partie programmation C d'où mon retard.
Tout est là sauf la génération du fichier tokenisé pour GFA-TEM. Après correction du bug je te fais sur le champ une version de teste.

Webmaster du site.
Programmeur sur TI68K. Arkanoid, Nebulus, GFA-Basic.

Plus d'informations sur GFA-Basic (un langage Basic pour TI68K).
http://www.tigen.org/gfabasic

./Post n°49 Marquer comme non lu.

tama

Ecrit le: Samedi 30 septembre 2006 à 11:03

Membre: Membre

Messages: 41

Membre n°1384

Inscrit le 13 juin 2006

Alors toujours pas de version test ??

./Post n°50 Marquer comme non lu.

geogeo

Ecrit le: Samedi 30 septembre 2006 à 13:05

Fondateur

Groupe: Staff de Ti-Gen

Groupe: Orage Studio

Messages: 4258

Membre n°3

Inscrit le 29 janvier 2004

Ca va venir. Je codes lentement en ce moment à cause des cours, projets...

Webmaster du site.
Programmeur sur TI68K. Arkanoid, Nebulus, GFA-Basic.

Plus d'informations sur GFA-Basic (un langage Basic pour TI68K).
http://www.tigen.org/gfabasic

./Post n°51 Marquer comme non lu.

geogeo

Ecrit le: Dimanche 1er octobre 2006 à 19:15

Fondateur

Groupe: Staff de Ti-Gen

Groupe: Orage Studio

Messages: 4258

Membre n°3

Inscrit le 29 janvier 2004

Je viens de développer aujourd'hui la communication du parser avec GFA-TEM. Me reste à gérer les structures style (For, If, Goto...).
Donc c'est sûr est certain que tu auras une version bêta durant la semaine prochaine. J'ia plus grand chose à finaliser.
A oui la version que tu auras ne devra être utilisée que pour détecter les bugs et non pour un usage courant. Et il faudra prendre des précautions, par exemple arhciver le contenu de ta machine. De plus cette bêta sera bridée pour permettre à GFA-Tem de correctement fonctionner. Mais ça ne changera rien aux tests.

Webmaster du site.
Programmeur sur TI68K. Arkanoid, Nebulus, GFA-Basic.

Plus d'informations sur GFA-Basic (un langage Basic pour TI68K).
http://www.tigen.org/gfabasic

./Post n°52 Marquer comme non lu.

geogeo

Ecrit le: Vendredi 6 octobre 2006 à 23:08

Fondateur

Groupe: Staff de Ti-Gen

Groupe: Orage Studio

Messages: 4258

Membre n°3

Inscrit le 29 janvier 2004

Bon je viens de me rendre compte de quelques chose, il faut mieux que je recodes l'ensemble des structures au lieu d'insérer une partie de l'ancien code de la version 1.0 de GFA-Basic dans la nouvelle version.
Je suis donc obligé de repousser encore la date de tests. Je préfères avoir une version du parseur de GFA Basic finalisée (c'est à dire qui supporte tout) et ensuite je pourrais me concentrer plus facilement sur GFA-TEM (une fois fini le parseur le développement avancera plus vite).
La nouvelle version de GFA Basic supporte énormément d'ajouts. Coder une interface pour GFA Tem risque d'engendrer beaucoup de bugs et donc les tests seront faux.
De plus je fais en sorte que le code de GFA Basic soit portable sur PC et sur d'autres machines.

Désolé Tama, les tests c'est pas pour demain. J'espères sortir une version pendant le mois de Décembre. J'ai de moins en moins de temps pour coder à cause de mes études.

Néanmoins je penses entre temps poster un article sur la programmation objet en C.

Webmaster du site.
Programmeur sur TI68K. Arkanoid, Nebulus, GFA-Basic.

Plus d'informations sur GFA-Basic (un langage Basic pour TI68K).
http://www.tigen.org/gfabasic

./Post n°53 Marquer comme non lu.

Kevin Kofler

Ecrit le: Vendredi 6 octobre 2006 à 23:11

Administrateur

Groupe: Staff de Ti-Gen

Messages: 4814

Membre n°40

Inscrit le 08 février 2004

geogeo :
Néanmoins je penses entre temps poster un article sur la programmation objet en C.

./Post n°54 Marquer comme non lu.

geogeo

Ecrit le: Samedi 7 octobre 2006 à 00:32

Fondateur

Groupe: Staff de Ti-Gen

Groupe: Orage Studio

Messages: 4258

Membre n°3

Inscrit le 29 janvier 2004

Bah quoi ? Il est bien de connaître d'autres styles de programmation. Cela ne veut pas dire qu'il faut l'utiliser tout le temps! De plus il est vrai que la programmation orientée objet ne devrait être utilisée qu'avec des langages orientés objet or sur TI on a que le C!

Webmaster du site.
Programmeur sur TI68K. Arkanoid, Nebulus, GFA-Basic.

Plus d'informations sur GFA-Basic (un langage Basic pour TI68K).
http://www.tigen.org/gfabasic

./Post n°55 Marquer comme non lu.

tama

Ecrit le: Samedi 7 octobre 2006 à 12:07

Membre: Membre

Messages: 41

Membre n°1384

Inscrit le 13 juin 2006

lol ok

./Post n°56 Marquer comme non lu.

geogeo

Ecrit le: Lundi 30 octobre 2006 à 19:29

Fondateur

Groupe: Staff de Ti-Gen

Groupe: Orage Studio

Messages: 4258

Membre n°3

Inscrit le 29 janvier 2004

Je laisse petit à petit tomber l'interpréteur pour du compilé. D'où le temps de travail long.

Webmaster du site.
Programmeur sur TI68K. Arkanoid, Nebulus, GFA-Basic.

Plus d'informations sur GFA-Basic (un langage Basic pour TI68K).
http://www.tigen.org/gfabasic

./Post n°57 Marquer comme non lu.

geogeo

Ecrit le: Jeudi 30 novembre 2006 à 19:17

Fondateur

Groupe: Staff de Ti-Gen

Groupe: Orage Studio

Messages: 4258

Membre n°3

Inscrit le 29 janvier 2004

Comme tu l'aura vu Tama rien n'est sortie depuis plus d'un an. Je ne peux plus rien annoncer comme sortie à cause de la quantité de travail importante que j'ai. Tout du moins GFA Basic reste un projet que je désires concrétisé mais qui arrive tout en bas de ma liste de priorités.
Je ne ferais donc que des annonces que lorsque que j'aurai vraiment quelque chose de concret.
Quoi qu'il en soit si quelqu'un veut les sources de GFA Basic v2 pour avancer dessus pas de pb.

Webmaster du site.
Programmeur sur TI68K. Arkanoid, Nebulus, GFA-Basic.

Plus d'informations sur GFA-Basic (un langage Basic pour TI68K).
http://www.tigen.org/gfabasic