Auto-formation à SCOL

Explication détaillée des résultats à obtenir

Lors des premières semaines, j'ai eu pour tâche de me former au langage fonctionnel SCOL, à la méthode de programmation par modules DMS et à l'éditeur de sites SCS (cf. annexes : extraits du tutorial SCOL/DMS). Il s'agissait d'être rapidement opérationnel, pour pouvoir vite enchaîner sur les projets importants. L'un des objectifs principaux était de "penser" programmation fonctionnelle, c'est à dire sans boucle, avec le moins possible d'effets de bord, mais aussi penser chaque procédure de façon récursive. L'apprentissage de la programmation SCOL modulaire avec le système DMS imposait aussi la maîtrise des notions de client/serveur et des problèmes de précédence : par exemple quand un module est déjà prêt à envoyer un message réseau à un autre alors que le module destinataire n'est même pas encore compilé. Enfin, la maîtrise de l'éditeur SCS en lui-même est assez aisée, puisqu'il est destiné à un relativement grand public, et le vrai problème était le manque de documentation sur les modules, leurs réflexes et leurs actions.

Axes d'étude et de recherche choisis

Les premiers jours du stage ont été occupés à récupérer la version la plus récente de SCOL, des différents modules DMS existants et surtout à pourchasser les documentations disponibles qui n'étaient pas centralisées ni même répertoriées. Voici les documents qui m'ont été les plus utiles tout au long de mon stage :

A partir du moment où j'ai réussi à rassembler ces documents, j'ai pu prendre le temps de les étudier avant de me lancer corps et âme dans la programmation SCOL.

Ensuite est venu le moment de me former à l'éditeur de sites SCS : Cryonics Pro (cf. annexes : documentation de l'éditeur SCS) pour pouvoir travailler sur la maquette du jeu Bürgermeister dont nous allons parler dans le second chapitre.

Enfin, après avoir acquis de bonnes notions de programmation SCOL et d'utilisation des modules avec SCS, il a fallu se former à la programmation de modules DMS pour pouvoir travailler sur les modules dont avait besoin l'équipe de Cryopolis 2 (cf. chapitre 3).

Déroulement concret des études, expérimentations, mises au point

La programmation SCOL a commencé d'une façon assez classique :

Hello world.pkg :

fun main()=

_showconsole;

_fooS strcatn "Hello"::" "::"World"::nil;;

Paint.pkg :


fun onclick(window,paramr,posx,posy,boutons)=

_PAINTcircle window posx posy 20 20 DRAW_SOLID 0 0 DRAW_SOLID 0;;

fun onmove(wind,p,x,y,s)=

_PAINTrectangle wind x y 5 5 DRAW_SOLID 0 0 DRAW_SOLID 0;;



fun main()=

let _CRwindow _channel nil nil nil 320 200 WN_MENU | WN_MINBOX "Paint" ->

window in

{

_PAINTrectangle window 10 10 50 50 DRAW_SOLID 5 15 DRAW_INVISIBLE 0;

_CBwinClick window @onclick nil;

_CBcursorMove window @onmove nil;

};;

Après un petit "Hello World" traditionnel et quelques autres minuscules programmes pour commencer à appréhender la syntaxe de SCOL, on m'a clairement demandé d'orienter mon auto-formation sur des fonctions qui seraient utiles pour le projet en cours de post-production à ce moment : Scotland Yard. Il y avait besoin de faire des fonctions de recherche dichotomique sur des chaînes de caractères contenues dans un gros fichier. Etant donné l'esprit des langages fonctionnels, j'ai d'abord fait un programme à base de listes de chaînes de caractères :

algo 1

Voici les fonctions de recherche :

typeof linelist = [S r1];;

fun finddichotomi_core(list,x,deb,fin,term)=

if deb>fin

then _echostrterm term "string not found\n"

else

let deb + (fin - deb) / 2 -> half in

{

if x==atoi(nth_list list half)

then

_echostrterm term strcatn "found: "::x::"\n"::nil

else if x<atoi(nth_list list half)

then finddichotomi_core list x deb (half-1) term

else finddichotomi_core list x (half+1) fin term

}

};;





fun finddichotomi(list,x,term)=

finddichotomi_core linelist x 0 (sizelist linelist)-1 term;;

Puis, étant donné qu'il fallait que la fonction de recherche soit très rapide, j'ai pris l'initiative de refaire les fonctions de parsage du fichier et les fonctions de recherche dichotomique en utilisant un tableau :

 algo 2

Voici les fonctions de recherche :

fun finddichotomatab_core(mytab,x,deb,fin,term)=

{

if deb>fin

then _echostrterm term "string not found\n"

else

let deb + (fin - deb) / 2 -> half in

{

if !strcmp x mytab.half

then

_echostrterm term strcatn "found: "::x::" at pos: "::(itoa

half)::"\n"::nil

else if 1==strcmp x mytab.half

then finddichotomatab_core mytab x (half+1) fin term

else finddichotomatab_core mytab x deb (half-1) term

}

};;





fun finddichotomatab(mytab,x,term)=

finddichotomatab_core mytab x 0 (sizetab mytab)-1 term;;

Toutes ces fonctions ont été essayées sur des fichiers de tests grâce au jeu Scotland Yard, puis elles ont été intégrées dans une bibliothèque de routines utilisée dans tous les projets importants.

Une fois formé correctement au langage SCOL, j’ai eu l’occasion d’apprendre la programmation modulaire distribuée avec DMS. C’est avec cette norme que l’on crée les modules DMS, qui sont ensuite intégrés dans un site SCS.

Le site SCS utilise une " architecture à copie ". Cela signifie que chaque machine du site (machines clientes et machine serveur) abrite une copie du site, ou plus exactement une approximation du site tel qu’il est défini par le concepteur. L’intérêt de cette démarche est que le concepteur du site ne définit qu’une seule architecture pour son site.

L’architecture d’un site SCS est modulaire : un site est constitué d’un nombre variable de modules, connectés entre eux par des liens. Chaque module gère une ou plusieurs fonctionnalités : log, authentification, espace 3d, ... Chaque module peut avoir un fonctionnement distribué : une partie du traitement s’effectue sur le serveur, une autre sur les clients.

Le rôle de l’auteur d’un site SCS est donc de sélectionner un certain nombre de modules et de les assembler en tendant des liens entre eux.

Un des problèmes majeurs dans la réalisation d’une application mettant en relation différents utilisateurs est de concevoir la répartition du traitement entre le serveur et les clients. Ce problème est éminemment technique, et donc hors de portée a priori de celui qui va construire un site SCS. Ceci est un autre argument pour une " architecture à copie ".

Le problème de la distribution sera donc réglé à l’intérieur d’un module, par celui qui programme le module.

Dans le cas général, chaque module sera divisé en deux, une partie fonctionnant sur le serveur, une autre sur les clients. La communication entre la partie cliente et la partie serveur d’un même module sera gérée exclusivement par l’auteur du module, en utilisant les techniques classiques de communication incluses dans SCOL. La communication entre les modules se fera sous forme de liens, et sera donc définie par l’auteur du site.

Créer un site consiste à assembler un ensemble de modules. Chaque machine (clients ou serveur) abrite une copie approximative de ce site : cela signifie que certains modules ne sont pas représentés sur chaque machine. Par exemple seul le module de l’espace 3d ou se trouve un utilisateur est représenté sur sa machine ; par contre tous les modules espace 3d du site sont représentés sur le serveur. Il y a derrière cette observation la question de l’activation dynamique des modules.

Un module serveur peut déclencher l’activation du module client correspondant. Le système gère pour chaque module serveur la liste des modules clients activés, ce qui lui permet notamment d’effectuer un filtre sur les messages, ce qui garantit la sécurité. L’activation n’est donc pas automatique.

Pour activer un module, il faut transmettre le module, les liens partant du module client, les zones utilisées par le module, ainsi qu’un paramètre. Une fois que le module est activé, il est possible de lui envoyé des messages ou des actions, même si le client doit d’abord télécharger des fichiers pour lancer le module : le système gère une file d’attente des messages et des actions.

J’ai aussi eu l’occasion d’essayer l’éditeur de sites SCS pour apprendre à le manipuler.

Interprétation et critique des résultats

Cette période d'auto-formation a été bien utile dans le sens où elle m'a permis de revoir les notions de programmation fonctionnelles qui avaient été vues en cours de LISP, car même si le langage SCOL en est assez éloigné par sa syntaxe, ce sont tous les deux des langages du même type. Les langages fonctionnels ne sont pas très utilisés en pratique à l'EPITA, et l'état d'esprit nécessaire pour "penser" fonctionnel est probablement moins inné chez les épitéens que chez les personnes possédant une formation universitaire pendant laquelle ils abordent le CAML et le LISP. Il a donc fallu déployer quelques efforts pour se mettre dans la philosophie SCOL. Le problème du manque de documentation ou plutôt du manque de circulation de l'information a été un peu pénalisant. Il a souvent fallu parcourir des fichiers sources de modules DMS pour comprendre les subtilités qui n'était pas explicitées dans les quelques fichiers d'aide ou de documentation.

Cette période a néanmoins été mise à profits pour prendre le temps de maîtriser assez le SCOL pour faire tout ce qui a suivi : du SCOL pur pour la post-production de Scotland Yard, de la programmation modulaire DMS pour Cryopolis 2 et de l'utilisation de SCS Cryonics Pro pour la maquette de Bürgermeister.