Revision as of 04:41, 16 December 2021

Languages:

English    Deutsch    Français

Sommaire

Il s'agit d'une alternative à XEngine, moteur de script pleinement fonctionnelle pour les scripts LSL/OSSL, avec :

• multitâche préemptif
• Amélioration de la syntaxe du script
• Ordre d'évaluation des expressions plus proche de la spécification LSL originale
• Contrôle de l'utilisation de la pile et du paquet de mémoire par script
• Nouvelles extensions du langage en option

YEngine effectue une traduction directe du langage de script vers le code .net IL, ce qui le rend plus rapide à compiler que XEngine. XEngine traduit le langage de script en C#, puis utilise le compilateur .net pour générer l'IL, ce qui est naturellement plus lent. Alors que XEngine pouvait compiler des scripts dans d'autres langages comme le C#, YEngine ne prend en charge que le LSL. Pour des raisons de sécurité, ces autres langages ne peuvent pas être utilisés pour l'instant, sauf dans des cas très particuliers et limités.

Une fois qu'un code de script est chargé sur XEngine, la mémoire utilisée par celui-ci ne peut pas être récupérée lors de la suppression du script, sauf si une fonctionnalité .net appelée AppDomains est utilisée.
Mais les AppDomains sont très lourds, utilisent beaucoup plus de mémoire et, pire encore, ont un impact négatif énorme sur les performances des scripts
Pour les appels traversant des domaines (c'est-à-dire le script et le framework principal), tous les paramètres et les valeurs de retour sont sérialisés et désérialisés par les domaines émetteur et récepteur.

Yengine charge le code des scripts d'une manière différente, la plupart de leur mémoire est récupérée à la suppression sans avoir besoin de ces AppDomains.

Multitâche préemptif

YEngine exécute des événements de script en utilisant le multitâche préemptif.
Cela signifie que, à certains points de contrôle ou lorsqu'on le lui demande, un script peut arrêter son exécution, pour être placé dans une file d'attente et attendre son tour pour s'exécuter à nouveau.
Le fil d'exécution libéré peut ainsi continuer à traiter d'autres scripts.

Lorsqu'un nouvel événement commence son exécution, il est autorisé à se dérouler pendant environ 60 ms (sous réserve de modifications) jusqu'à la libération de l'exécution. Lorsqu'il est à nouveau exécuté, il est autorisé à fonctionner pendant 30 ms supplémentaires (sous réserve de modifications). Cela sera répété jusqu'à ce que tout le code de l'événement soit exécuté
Le moteur donnera une plus grande priorité aux événements courts et rapides.

Le script peut également être placé en état de veille pendant un temps déterminé.
Cela permet par exemple de résoudre l'un des problèmes les plus graves de XEngine : llSleep() et autres attentes internes de script.

Avec YEngine, cette attente ne fait qu'arrêter l'exécution qui va attendre dans une file d'attente, jusqu'à ce que le temps de sommeil soit écoulé.

Avec XEngine, un fil d'exécution "coûteux" est placé en mode "Sleep", donc non disponible pour faire quoi que ce soit.

Amélioration de la syntaxe du script

YEngine suit de plus près la syntaxe du script LSL et l'ordre d'exécution.

Des instructions comme

 if(oneKey)
   ...

devrait maintenant fonctionner.

 llSomething; // missing()
 break; // mais voir les nouvelles extensions

sont désormais des erreurs.

Ordre d'évaluation des expressions

L'ordre d'exécution des instructions complexes est plus proche de la spécification LSL que de l'ordre d'exécution de XEngine.

Par exemple, avec i = 1 ;

((i == 2) && (i++ == 1))

cette expression sera évaluée à true suivant la spécification LSL, alors qu'avec XEngine il serait évaluée à false, parce (i == 2) serait testé en premier.

Même si ce n'est pas utile dans ce cas, toujours utiliser des parenthèses (...) pour forcer l'ordre que vous attendez (et faites-le dans n'importe quelle langage) !.

Nouvelles extensions du langage en option

Si la deuxième ligne d'un script est (actuellement la première ligne doit être présente, vide ou avec la sélection du moteur de script)

 yoptions;

Les extensions spécifiques du langage de Yengine sont activées

• switch
• break
• continue
• try catch et finally
• constant
• court-circuit AND et OR

Les scripts utilisant ces fonctionnalités ne se compilent pas et ne fonctionnent pas sur XEngine.

Contrôle de l'utilisation de la pile et du paquet de mémoire par script

YEngine permet le contrôle de la mémoire utilisée par un script.
Il existe deux types de mémoire :

• La pile contient des arguments de fonction et des variables locales simples.
  
• Le tas (heap) contient des variables globales et des variables complexes comme des listes ou des chaînes de caractères, même si elles sont locales à une méthode/événement.
  

La mémoire maximale qu'un script peut utiliser peut être configurée dans la section OpenSim.ini [YEngine].

  ; pile maximale qu'un script peut utiliser en Ko
  ;ScriptStackSize = 2048

  ; mémoire maximale du tas qu'un script peut utiliser en Ko
  ;ScriptHeapSize = 1024

Vous devrez peut-être augmenter ces valeurs

Activation

La configuration par défaut d'OpenSimulator sélectionne le XEngine. Pour passer à YEngine, vous devez modifier le fichier OpenSim.ini:
[Startup] section:

DefaultScriptEngine= "YEngine"

[YEngine] section:

Enable = true

[XEngine] section:

Enable = false

Note : en théorie, OpenSimulator pourrait faire tourner plusieurs moteurs en même temps, mais nous ne devrions pas faire cela avec les moteurs X et Y.

Configuration

Veuillez consulter le fichier OpenSimDefaults.ini, section [YEngine] pour plus de détails.

Comme dans tous les cas, si vous avez besoin de changer quelque chose, copiez les lignes respectives à un endroit similaire dans le fichier OpenSim.ini, et changez-les

Origines

YEngine est un dérivé modifié de XMREngine.
XMREngine a été développé par des équipes de grilles DreamNation et Avination, sur la base des premiers travaux de Meta7.
Il est toujours utilisé par DreamNation.

http://wiki.dreamnation.net/index.php/XMREngine_Script_Engine

De nombreuses informations sur XMREngine ne s'appliquent plus à YEngine. Certaines fonctionnalités peuvent encore fonctionner, mais peuvent être supprimées ou modifiées.