REUNION DU 06/11/02 Ordre du jour : Le temps mis par les actions (problème soulevé par Damien et qques autres au sujet de AVANCER-TOURNER). Définition des primitives/fonctionnalités de notre langage. Que doit faire l'interpréteur. Autres/Tips. Compte rendu de la réunion : Problème de temps 0 Résumé: certaines personnes demandent que les mouvements soient fluides ainsi lorsqu'on effectue la séquence AVANCER-TOURNER dans un système aux temps tous identiques à 1, on se retrouve avec un robot qui avance puis tourne et ceci de façon saccadé. L'idée de Damien est d'une certaine façon (il me corrigera s'il faut) de reconnaitre de telles séquences pour pouvoir effectuer la rotation pendant le mouvement de translation, ce qui rendrait les transitions plus fluides. Mais cette solution demande que la rotation se fasse en temps 0, or si celle-ci se fait toujours en 0 les rotations sur soi-même ne prennent plus de temps et si elles valent parfois 1, il est difficile de trouver dans quel cas on se trouve. Proposition de sureté: tout se fait en temps 1 et le robot avance puis tourne Proposition provisoire (plus sioux): On remplace le "avancer/tourner" par une sorte "d'aller sur la case de gauche/aller sur la case de devant". Du coup tout se fait en temps 1 et on règle le problème du tourner car c'est au moteur graphique de s'apercevoir qu'on tourne ou pas (assez facile). Autres points: dans le même esprit on doit gérer les sauts en temps 1, et pour éviter d'avancer plus vite en sautant (on avance alors de 2 cases) on rajoute un PREPARER_SAUTER qui dure aussi 1 top. Il s'agit ici du langage "assembleur" du robot : le parseur transformera l'instruction 'saut' du langage ROGO en la séquence . Les fonctionnalités du langage Résumé: on veut limiter le plus possible l'utilisation des variables. Dans la version de départ, on les élimine même pour voir si notre langage sera assez puissant. La possibilité de gérer les expressions arithmétiques reste encore controversée (à noter que celles-ci ne servent à rien si on n'a pas de variables). Proposition de sureté: on a définit les primitives/fonctionnalités suivantes Pour les actions: RAMASSER {agit sur la case du robot avec éventuellement la gestion de plusieurs objets par case avec une gestion d'une pile} POSER {idem que ramasser) L'ensemble des déplacement au sol {du style "aller sur case de gauche"} PEPARER_SAUT {ne fait rien mais doit précder un saut} SAUTER {saute 2 cases plus loin} ALLER_VERS obj {attention encore discuté, fait avancer d'une case vers l'objet de type obj} Pour les structures: REPETER n [FOIS] {commence une boucle "for"} FIN {termine une boucle} STOP {permet de briser l'imbrication des évenements, stoppe le robot et toutes les actions} Quelques notes: Les boucles "for" vides seront "nettoyées" dans l'arbre. ALLER_VERS effectue un path finding. L'interpréteur Un sous-projet "interpréteur" parait indispensable, les rôles sont encore très flous, surtout au niveau évènementiel. Si le monde abstrait reçoit seulement du code séquentiel, toute la gestion des évènements se effectuée par une mini machine virtuelle dans l'interpréteur. Le sous-projet "interpréteur" et l'implémentation de la machine virtuelle seront pris en charge par moi-même (Aurélien) et par tout ceux qui voudront se joindre a moi. Cette machine virtuelle devra sauvegarder le contexte lorsqu'un évènement est reçu et tout et tout. Autre Quelques petites idées/propositions, pour les autres sous-projets, qui sont apparues dans la conversation: monde abstrait type les objets présents dans le monde interface graphique offre une barre où le clic sur des icones représentatifs écrit la primitive correspondante dans le "terminal" interface graphique offre un moyen rapide d'accéder au évènements à définir/définis de notre robot pour l'exo. Conclusion Assez productive vers la fin la réunion s'est déroulée dans la joie et la bonne humeur :-) Les problèmes qui restent sont au niveau de la gestion des évènements et leur remplissage (du moins moi j'ai un prob pour voir comment ça se fait dans l'état actuel des choses). Le programme rogo se tourne plus vers un apprentissage des langages évènementiels que des langages objets (koike....) Compte rendu réalisé par Aurélien Moreau