Starting Ravi

En fait, ce lancement fait appel à de nombreuses intialisations avec de nombreux paramètres que l'on peut positionner. Cela fait intervenir

• les paramètres de la commande
• le fichier Init.scm interne à Ravi (cf. répertoire Runtime)

On peut notamment automatiser des initialisations personnelles standard, et créer des nouvelles commandes Unix qui s'exécutent "en ravi".

Les paramètres donnés à la commande ravi sont utilisés par différentes instances - en effet, plusieurs mécanismes d'exécution sont activés, qui sont, grosso modo et dans l'ordre, le main en C++ qu'on appèle noyau, la machine virtuelle, l'interpréteur, le programme utilisateur.

D'abord, le noyau interprète les paramètres suivants:

 -boot filename
 -protect
 -debug
 -libdir libroot
 -silent
 +t ...
 -t ...
 -v ou --verbose
 -h ou --help
 -V ou --Version

Les paramètres restants sont passés dans la variable globale Scheme *argv* et analysés par le fichier Init.scm qui reconnait les paramètres suivants (chaque paramètre est une chaîne de caractères au sens Scheme):

 --rcdir dir-name
 -mod modulename
 -no-init-file
 -s
 -e

Les paramètres du noyau

Ces paramètres sont plutôt pour les spécialistes. Notons simplement:

• --verbose commande le le mode "verbeux" de ravi. Dans ce mode apparaissent notamment les noms complets de tous les fichiers chargés, ce qui peut être important pour la mise au point. La fonction Scheme (verbose? opt_bool) positionne le même flag.

• -boot filename permet de lancer un interpréteur autre que l'interpréteur Scheme standard; il pourrait y avoir un CommonLisp, ML, ... C'est un moyen puissant d'innover qui est exploité, modestement, avec l'interpréteur Scheme+objets.

• --help ou -h affiche juste une ligne d'info

• -protect permet de tourner en bloquant le ramasse-miettes

Le fichier Init.scm

L'interpréteur Scheme standard s'initialise avec le fichier Init.scm. Après quelques initalisations de base, il se passe des choses importantes sur lesquelles on peut vouloir intervenir.

Fichiers de configuration et variables globales

Le fichier Init.scm initialise quelques variables globales importantes, en exécutant les fichiers de configuration personnels dans le répertoire $HOME/.ravi. Si ce répertoire n'existe pas, il est crée.

Le paramètre --rcdir dir-name permet de spécifier explicitement un répertoire d'initialisation. Si ce paramètre est présent, il doit être placé en premier après les parmètres du noyau. Si le répertoire n'existe pas, aucune action particulière n'est prise - pas de création.

Voir /home/pandora2/Ravi/local/lib/Ravi0.9.1/make_ravi pour le contenu standard des fichiers du répertoire $HOME/.ravi, détaillé ci-après:

Le fichier paths.scm définit les variables

*module-path*
*ld-path*

Le fichier raviInit.scm charge le module readline.

Le fichier Init.scm initialise les variables suivantes:

*system-architecture* (init par le main)
*suffix-list*
*current-load-path*
*module-path*

Fichiers d'initialisation

La suite dépend du premier paramètre trouvé dans *argv*. (On rappèle que les paramètres traités par le noyau n'y figurent pas).

Si le premier paramètre est -mod, toute la suite des opérations est prise en charge par le module ainsi activé. Par exemple,

  ravi -mod compile monfichier

active le module compile: ce module compilera "monfichier" et ne donnera pas la main à l'interpréteur Scheme en interactif. Ceci est expliqué en détail dans le paragraphe "Lancement d'un module en stand-alone".

Si le premier paramètre n'est pas -mod, on considère qu'il s'agit d'un lancement usuel de l'interpréteur Scheme, et on charge le fichier avec les initialisations personnelles - c'est le fichier $HOME/.RaviInit.scm . (Le paramètre -no-init-file sert à éviter ceci).

Ensuite, les paramètres restants sont considérés séquentiellement comme des noms de fichiers à charger; soyons plus précis - le premier élément de *argv* est considéré comme nom d'un fichier à charger; ce chargement peut entrainer la consommation d'autres paramètres.

Le paramètre -e , comme par exemple

 ravi  -e "(display 'essai)"
 ravi  file1 -e "(display 1)" file2 -e "(display 2)" file3 -e "(display 3)"

"Consommer un paramètre" veut dire ici qu'on met à jour la variable *argv*. Il existe pour cela une fonction dans ravi;

(next-argv mess)

Cette fonction a pour résultat le prochain paramètre, et pour effet de bord d'effacer ce parametre de la liste *argv*. S'il n'y a pas/plus de parametre, on provoque une erreur. L'argument mess sert de message d'erreur si le parametre n'existe pas. Si on veut qu'il n'y ait pas d'erreur, tester (pair? *argv*) avant l'appel de next-argv.

nb On pourrait complexifier cette fonction en lui donnant un 2ieme arg pour définir valeur/action si absence d'arg.

Un exemple d'appel:

 ravi monmodule param1 param2

La dernière ligne du fichier monmodule.scm pourrait être:

  (traitement (next-argv "camera") 
	(next-argv "nombre d'images"))

Remarque: cette partie d'initialisation se fait avant d'entrer dans l'interpréteur; ce n'est donc pas tout à fait pareil qu'un load manuel ... le traitement d'erreurs est un peu différent.

Lancement d'un module en stand-alone

A la fin d'un module éventuellement capable de tourner "en batch", il faut un bout de code correspondant au raisonnement suivant:

"Si je suis lancé en tant que module indépendant, avec le paramètre -mod, alors je dois traiter le fichier donné en paramètre; sinon je travaille comme un module chargé normalement".

Comment procéder? Grâce à la variable *init-module*, qui est positionnée dans le fichier Init.scm, on peut savoir qu'on est dans ce cas. Regardons l'exemple-type du module r-ig - générateur d'interface - puisque d'autres fonctions inhabituelles apparaissent dans ce contexte.

(if (eq? *init-module* 'r-ig)
    (global-tag #t
                (lambda ()
                  (gen-module (next-argv "file-name"))
                  (display "tvb\n"))
                (lambda (a b)
                  (error-reset-port a b)
                  (display "Error in r-ig\n")
                  (quit #f))))

Cela définit un traitement "batch" avec, en cas d´erreur un code d'erreur visible au niveau Unix.

Remarques

• Cette séquence doit se trouver soit dans un fichier interprété, soit dans la partie "postlude" d'un fichier compilé. cf. compilateur

• La variable *interactive* a la valeur #f pendant cette exécution.

Quelques fonctions non-standard utiles

• global-tag
• global-exit
• erreur
• error
• error-reset-port
• quit
• next-argv