ScriptEngines/fr

Moteurs de script
OpenSimulator supporte l'écriture de scripts via des moteurs de scripts. Les moteurs de script sont des modules de région normaux.

Cette page traite des parties communes des moteurs de script. OpenSimulator dispose actuellement de deux moteurs de script publics XEngine et YEngine. Pour plus d'informations, veuillez consulter XEngine et YEngine.

Pour des informations sur l'ancien DotNetEngine qui a été déprécié dans OpenSimulator 0.6.8 et ensuite retiré du code principal, veuillez consulter DotNetEngine et OpenSim.Region.ScriptEngine.


 * Note : Cette page représente un objectif d'implémentation. La plupart de ces éléments fonctionnent déjà, mais certaines parties ne sont pas encore implémentées.

Paramètres d'OpenSim.ini
Maintenant, plusieurs moteurs de script peuvent être actifs en même temps. La directive script_engine dans OpenSim.ini n'est plus utilisée ! A la place, dans la section [Startup], vous trouverez XEngine est le moteur par défaut, pour le remplacer par n'importe quel autre moteur, modifiez le commentaire pour activer la ligne XEngine peut également être désactivé en définissant les paramètres suivants Ce paramètre est par défaut à true. OpenSimulator doit pouvoir exécuter plusieurs moteurs de script simultanément, mais cela devrait être évité.

Utilisation de plusieurs moteurs de script
Pour exécuter un script sur un moteur spécifique, commencez le script avec une première ligne comme : En option, il peut être suivi d'un code de langage : Attention : il y a un petit effet de bord. Si vous commencez votre script par quelque chose comme (commençant par "//" et finissant par " :") vous obtiendrez une erreur

"Selected engine unavailable. Running script on XEngine"( Traduction du message : 'Le moteur sélectionné n'est pas disponible. Exécution du script sur XEngine".)

Un moteur de script définit un moyen de charger et d'exécuter un script. Il utilise des compilateurs et des environnement d'exécution pour y parvenir.

Les compilateurs prennent le texte du script et le convertissent en un assembly .NET. Un tel assembly doit faire référence à un environnement d'exécution (runtime), qui fournit des stubs d'API.

Actuellement, un compilateur existe pour lsl.

Un runtime existe pour l'API LSL et pour l'API OSSL. Statut/Fonctions de LSL

Ce qui suit décrit la structure des répertoires (sous /OpenSim/Region/) :

Une API (Interface de Programmation d'Application) est définie comme une implémentation, une interface et un runtime. La raison de cette approche apparemment compliquée est liée aux scripts exécutés dans les AppDomains en dehors du code normal d'OpenSimulator.

La création d'une API est assez simple, mais quelques conventions de dénomination doivent être respectées pour que l'Api fonctionne correctement. Le runtime du script utilise la réflexion pour faire correspondre les runtimes Api aux implémentations, et il utilise les noms pour trouver ces correspondances.

Tout d'abord, créez l'implémentation de votre API.

Ici, le nom de la classe (XXX_Api) est utilisé par réflexion, il doit se terminer par "_Api" pour être reconnu comme un Api.

Placez le fichier dans OpenSim/Région/ScriptEngines/Shared/Api/Implementaton/

Par convention, il doit être nommé XXX_Api.cs.

Ensuite, créez une interface pour lier l'Api au runtime :

Placez ce fichier dans OpenSim/Région/ScriptEngines/Api/Interface, nommé IXXX_Api.

Maintenant, le fichier stub est nécessaire pour connecter le script à l'Api. Ce fichier stub sera chargé dans le script AppDomain, et ne doit pas contenir de processus. Il transmet simplement les appels à l'API en dehors de l'AppDomain.

Enregistrez ce fichier dans OpenSim/Region/ScriptEngines/Shared/Api/Runtime, nommez-le XXX_Stub.cs.

Ici, le nom ApiTypeXXX est le nom obligatoire, par lequel le moteur de script reconnaît cette Api et la fait correspondre à l'implémentation de l'API.

Veuillez noter que votre Api devient ici une partie d'une classe partielle, qui, à son tour, devient la classe de base du script.

Au chargement du script, le runtime de l'Api (stub) est appelé avec une référence à l'interface IScriptApi de l'implémentation. Celle-ci, convertie en interface personnalisée, est utilisée pour accéder aux implémentations des fonctions.

La raison pour laquelle nous ne pouvons pas faire directement référence à l'implémentation est que cela entraînerait le chargement de l'implémentation entière dans l'AppDomain du script. Nous devons éviter cela pour maintenir une empreinte mémoire faible.

Le répertoire OpenSim/Region/ScriptEngines/Shared/CodeTools contient tous les compilateurs, convertisseurs et autres outils de manipulation de code. Il est partagé entre tous les moteurs de script. Grâce au compilateur partagé, les moteurs de script peuvent également partager des assemblys compilés, éliminant ainsi la nécessité de recompiler chaque script pour chaque moteur de script.

Génération du code
La génération de code LSL vers C# est commune à tous les moteurs de script. Elle s'effectue actuellement en traduisant le code LSL en C#, puis en le compilant. Le code compilé appelle ensuite des méthodes dans LSL_Api.cs (OpenSim/Region/ScriptEngine/Shared/Api/Implementation/LSL_Api.cs) qui correspondent aux fonctions LSL ou des méthodes dans OSSL_Api.cs pour les fonctions OSSL, etc.

Depuis OpenSimulator 0.7.4, il existe également un mécanisme permettant de rendre les fonctions de script disponibles depuis les modules de région sans avoir à patcher OpenSimulator lui-même. Voir OSSL_Script_Library/ModInvoke pour plus de détails.

L'analyse du script LSL est lancée par CSCodeGenerator.Convert (OpenSim/Region/ScriptEngine/Shared/CodeTools/CSCodeGenerator.cs). Il prend le LSL et utilise un analyseur/lexer pour le convertir en un arbre de syntaxe abstraite (AST), avant de convertir cet AST en C# via le LSL2CSCodeTransformer.

Le parseur (lsl.parser.cs) et le lexer (lsl.lexer.cs) sont générés en utilisant les outils de compilation de Malcolm Crowe en C# à partir du répertoire trunk/managed/lsl2cs dans le opensim-libs repository à partir des fichiers lsl.parser et lsl.lexer. '''Notez que si vous régénérez ceci, vous devrez changer l'avant-dernier numéro du tableau arr dans la classe ArgumentDeclarationList_5 générée dans lsl.parser.cs de 1 à 0. Nous devons trouver pourquoi ce bug se produit.'''

Le C# converti est ensuite compilé en DLL par la classe OpenSimulator Compiler (via la méthode PerformScriptCompile qui a également déclenché la conversion LSL -> C# comme décrit ci-dessus).

Vous pouvez voir le C# converti qui a été compilé en définissant

dans votre fichier OpenSim.ini. Celui-ci apparaîtra dans le répertoire bin/ScriptEngines// avec le nom de fichier CommonCompiler_source_CommonCompiler_compiled_.lsl.