Aller au contenu

« Réunion du 31-10-2023 » et « Réunion du 07-11-2023 » : différence entre les pages

De OSWiki
(Différence entre les pages)
Page créée avec « = Changements du code de la semaine= * Aucun changement dans le code cette semaine. * Le master va bientôt être mis à jour vers dotnet6. = Avertissement = {{Avertissement_résumé|fond=pink |bord=red |message = Ce résumé existe pour orienter vos recherches. Des erreurs d'interprétation ne sont pas à exclure. Pour plus de précisions, veuillez vous référer aux sources ou vous adresser directement aux développeurs d'OpenSimulator en assistant aux [http:/... »
 
Page créée avec « = Changements du code de la semaine= * [http://opensimulator.org/viewgit/?a=commit&p=opensim&h=80e930e9a6dfe8b982a168374d4512ab34490639 Mise à jour des librairies gérées pour Mac, avec une nouvelle signature] = Avertissement = {{Avertissement_résumé|fond=pink |bord=red |message = Ce résumé existe pour orienter vos recherches. Des erreurs d'interprétation ne sont pas à exclure. Pour plus de précisions, veuillez vous référer aux sources ou vous adresse... »
 
Ligne 1 : Ligne 1 :
= Changements du code de la semaine=
= Changements du code de la semaine=
* Aucun changement dans le code cette semaine.
* [http://opensimulator.org/viewgit/?a=commit&p=opensim&h=80e930e9a6dfe8b982a168374d4512ab34490639 Mise à jour des librairies gérées pour Mac, avec une nouvelle signature]
* Le master va bientôt être  mis à jour vers dotnet6.
 
= Avertissement =
= Avertissement =
{{Avertissement_résumé|fond=pink |bord=red |message = Ce résumé existe pour orienter vos recherches. Des erreurs d'interprétation ne sont pas à exclure. Pour plus de précisions, veuillez vous référer aux sources ou vous adresser directement aux développeurs d'OpenSimulator en assistant aux [http://opensimulator.org/wiki/Office_hours réunions du mardi] ou  sur [http://opensimulator.org/wiki/IRC le canal IRC]}}
{{Avertissement_résumé|fond=pink |bord=red |message = Ce résumé existe pour orienter vos recherches. Des erreurs d'interprétation ne sont pas à exclure. Pour plus de précisions, veuillez vous référer aux sources ou vous adresser directement aux développeurs d'OpenSimulator en assistant aux [http://opensimulator.org/wiki/Office_hours réunions du mardi] ou  sur [http://opensimulator.org/wiki/IRC le canal IRC]}}
= Modules =
 
=== Test sur les cartes de région ===
= Code général =
* Génération d'une carte avec 13 niveaux de zoom au lieux de 9 niveaux, 12000 tuiles de région en 20 minutes environ (10 tuiles par seconde).  
=== Utilisation du CPU ===
* Système beaucoup plus rapide que l'ancien système utilisé actuellement. La tuile est chargée en mémoire et affichée directement dans le niveau de zoom choisi. Cela semble fonctionner correctement dans les tests. Les tuiles  sont  verrouillées et ajoutées ensuite pour qu'elles ne puissent pas  entrer en conflit  avec elles-mêmes comme elles le font actuellement. Lorsqu'une région s'enregistre, cela peut prendre un certain temps pour qu'elle apparaisse à tous les niveaux de zoom, mais la carte dans le viewer est lente à se mettre à jour au premier chargement, donc ce n'est pas un gros problème. Ensuite le chargement est rapide.  
* L'utilisation de Dotnet provoquerait une utilisation plus importante du CPU, mais tout le monde n'a pas vu d'augmentation spéctaculaire.
* Le plus gros problème du système actuel est qu'il ne rend pas correctement les varregions.
* Observation de Vincent Sylvester : Augmentation probable de l'ordre de 15 à 30 % selon les cas. Il a remarqué que c'était un peu linéaire jusqu'à un certain point et que l'utilisation a tendance à augmenter beaucoup plus rapidement puis à ralentir un peu. "C'est effrayant de voir une utilisation de 250% cpu avec beaucoup d'utilisateurs."
* Problème potentiel : Quelque chose qui tourne deux fois plus vite sans aucune limitation pourrait causer des goulots d'étranglement ailleurs.
* NDLR 🏗️ (je sature il reste encore 6 minutes de chat.)


= Bugs =
= Bugs =
=== Non prise en compte des modifications des primitives ===
=== Les librairies non gérées de macOS ne se chargent pas ===
* Problème de [https://fr.wikipedia.org/wiki/S%C3%A9rialisation sérialisation ].
* Lien du ticket 0009097 (en) : http://opensimulator.org/mantis/view.php?id=9097
* Il serait utile d'avoir des tests pour vérifier que la suppression d'une prim d'une scène soit effective et ne laisse pas un fantôme de la prim.
* Affecte macOS spécifiquement, branche dotnet6. Même résultat sur Mac x86_64 et Mac arm64 .
* Mise en évidence :
* Les certificats Apple Developer utilisés pour signer les bibliothèques non gérées de macOS étaient sur le point d'expirer. La génération de nouveaux certificats nécessitait la révocation des anciens. En conséquence, opensim n'a pas pu démarrer. Les trois bibliothèques non gérées dans le repo ne parvenaient pas à se charger à cause du certificat de distribution révoqué qui était utilisé pour les bibliothèques non gérées dans le tronc (branche dotnet6).
** Si vous déconnectez, reliez et supprimez rapidement certains éléments de la base de données, même si la région semble vide, redémarrez-la et les prims réapparaissent.
* Les nouvelles librairies ont été transférées dans la branche dotnet6, OpenSim est opérationnel sur macOS, '''les utilisateurs de macOS devront faire une mise à jour.''' Les librairies fonctionneront sur n'importe quel macOS 10.5-latest.  
**  Prendre un objet lié, éditer les parties liées, délier une partie, dupliquer cette partie par shift drag, puis tout lier à nouveau et la charger dans l'inventaire. Au prochain redémarrage, la partie non liée est de nouveau sur le sol. Si on fait ça, on peut voir dans la base de données l'objet lié puis la prim non liée est ajoutée, ensuite le nouvel objet lié, l'objet lié d'origine qui est supprimé et ensuite quand on fait l'inventaire le nouvel objet lié  est supprimé, la prim non liée  reste par contre.
* Précision de Gavin Hird : si un logiciel est démarré depuis le terminal, la signature n'est pas vérifiées.
* Explication possible:  la façon asynchrone dont ces tâches sont planifiées  pour ne pas retarder les choses et c'est si rapide que le résultat est perdu.
* NDLR : je n'ai jamais utilisé un Mac de ma vie, donc je vais m'arrêter là dans le résumé de ce sujet de peur de faire de grosses erreurs.
* Solution : les mises à jour de la DB DOIVENT être retardées.
===Disparition de la bibliothèque OpenSim ===
 
* La bibliothèque OpenSim aurait disparu dans l'inventaire du viewer (NDLR: sur Argentoratum c'est le cas).
= Tests =
* Ubit Umarov a encore la bibliothèque même dans Firestorm Beta avec les récents changements.  
=== Tests unitaires ===
* Le problème doit venir de la configuration Robust. (NDRL : je devais regarder ce qui se passe, je mettrai la solution ici si je la trouve).
* '''Si quelqu'un veut aider à écrire des tests  il ou elle est  bienvenu.e.'''
* Nunit et Xunit semblent être les deux solutions les plus utilisées actuellement. Xunit est recommandé pour l'utilisation de dotnet, Nunit étant le deuxième de la liste.
* La configuration pour faire fonctionner Xunit a réussi donc maintenant, il existe une écriture pour utiliser Xunit. Des test de Xunit sont  en cours et un  travail de préparation de la base de données a été réalisé.
* Voir [[Réunion_du_17-10-2023#Tests_unitaires | la réunion du 17-10-2023]]
* Certains anciens tests ne sont plus utiles mais d'autres ont signalé des bogues dans le passé, donc ils ne sont pas tous inutiles. Certains changements sur dotnet6 peuvent altérer les tests car les réultats attendus par les tests ont changé.
* Le but n'est pas de les réécrire un par un les tests, juste d'avoir des idées sur les parties à tester et peut-être sur les outils qui existent comme le moteur de script fictif, les aides de scène et autres. 
* Le plan est de documenter les tests qui existaient, de définir les tests les plus importants et de comprendre comment ils  fonctionnaient. Cela pourrait donner une idée de ce qu'il faut encore tester comme :
** 🔹 les connexions,
** 🔹 l'inventaire,
** 🔹 la sérialisation de la base de données,
** 🔹 les téléports et
** 🔹 les franchissements de régions.
** 🔹 Les tests sur  les permissions sont les plus récents, les règles de permissions de SL sont déroutantes. Le code de permission, l'accès aux parcelles et aux domaines sont un sac d'embouilles pour le moment, écrire des tests pour cela sera amusant.
** 🔹 Idéalement il faudrait tester chaque module en lui envoyant des données et en vérifiant si le test réussit comme prévu ou échoue.
** 🔹 Le problème des sensor est un peu plus difficile à tester.  Un sensor qui ne fonctionne pas est ennuyeux, mais pas immédiatement dangereux. L'inventaire se corrompt à cause d'une mauvaise sérialisation, c'est un peu plus grave.
* La prochaine chose à faire est de trouver comment enregistrer les résultats des tests et les intégrer à [https://fr.wikipedia.org/wiki/Jenkins_(logiciel) jenkins].
* Jenkins peut tout à fait faire du dotnet, il suffit de changer quelques commandes, le reste est identique.
* Priorité : passer en revue les changements de dotnet à partir de master et écrire des tests pour ces changements.
 
= [http://opensimulator.org/wiki/Compatible_Viewers Viewer] =
=== Demande des développeurs de viewers ===
* Si OpenSimulator veut obtenir le support des viewers, il est essentiel que toutes les différences avec SL soient documentées. Les développeurs de viewers, ont VRAIMENT BESOIN de cela.
* C'est une chose plus facile à dire qu'à faire car SL ne documente correctement pas ses protocoles et tous le reste. Si les développeurs ont  des questions, ils peuvent les poser sur la liste de diffusion et sur irc toute la journée et toute la semaine.
* Les différences  pour OpenSim :
** le baking de l'avatar  qui se fait côté viewer,
** Les profils
** Hypergrid
** la gestion des varregions,
** la longueur autorisée du fichier son,
** la hauteur de construction, la taille maximale de la prim, le nombre de groupes autorisés, etc.
** pas de limite pour la longueur des identifiants de groupe et tout le reste en dehors des limites de la taille des champs de la base de données,
** alias d'url,
** [https://wiki.secondlife.com/wiki/AIS AIS] V3 n'arrivera peut-être jamais. AIS : moyen pour le Second Life Viewer de récupérer la liste des articles d'inventaire.


=== Nouveautés côté SL ===
= Viewers=
* Mise à jour de l'[https://wiki.secondlife.com/wiki/AIS AIS] qui est une véritable rupture pour le code des viewers et il y en aura d'autres.
=== Dayturn ===
* Voir [[Réunion_du_03-10-2023#Viewers| Réunion du 03-10-2023]]
* Compilation du viewer Windows avec Visual Studio 2022
* Gavin Hird a pour projet d'essayer Mumble avec la version Mac du viewer.


===[http://sldev.free.fr/ Cool Vl viewer] ===
=== Firestorm ===
* supporte AIS.
* Avec la version 7.0 alpha certaines choses ne fonctionnent plus à cause d'un changement de protocole d'inventaire. Des vignettes d'inventaire s'affichent mais ne fonctionnent pas parce que les développeurs utilisent le code pour [[Réunion_du_03-10-2023#Viewer_et_AIS |l'AIS V3 (voir la réunion du 03-10-2023)]].


=== Sharpview ===
=== Viewer Second Life ===
Le support des varrégions fonctionne dans Sharpview. En grande partie. Les jonctions entre régions ne fonctionnent pas encore.
* Il semble que SL travaille sur beaucoup de choses à la fois et tout devient instable dans les viewers.
* Gavin.Hird est presque sûr que SL developpe une version Xbox du viewer. Ils pourraient aussi abandonner le support Mac, parce qu'ils ont mis à jour les instructions de construction pour la version Windows, mais les instructions de la version Mac sont significativement dépassées. Les utilisateurs de Mac seront à la traîne par rapport aux utilisateurs de Windows en termes de fonctionnalités et de performances dixit le chef technique de SL.  Apple a dit qu'ils allaient se débarrasser d'OpenGL et la seule chose qui fonctionne sur macOS est Metal.
* Vincent.Sylvester trouve qu'il aurait fallu plus de modularité pour une adaptation à d'autres contrôles de jeu.
* Joe Magarac dit que la prise en charge des contrôleurs de jeu utilisera la norme Human Interface Device. Cette norme prend en charge la plupart des appareils qui se branchent sur un port USB.
* Paradoxalement, il est aussi question d'un viewer pour iPad.
* Le projet du Viewer mobile fonctionne avec [https://fr.wikipedia.org/wiki/Vulkan_(API) Vulkan]. Cuga.Raja suppose qu'UDP ne sera plus utilisé (donc passage à TCP) pour le Viewer mobile. L'ancienne idée pour le mobile était d'utiliser une sorte de streaming vidéo côté serveur.
* Les viewers OpenSim sont à 95% du code Linden Lab. D'après Ubit Umarov, la corde de la dépendance est peut-être sur le point de se rompre. Certains changements sont tout simplement trop mauvais pour être suivis. Quand firestorm a speraté OpenSim et SL, ils ont arrêté de faire du code pour nous... Vincent Sylvester dit  changer le pipeline de développement et nettoyer le désordre des dépendances ne serait pas seulement bénéfique pour nous, mais rendrait généralement plus facile le développement d'un viewer en utilisant le code Linden Lab. C'est une entreprise de grande envergure et cela ne résout pas complètement le problème de la compatibilité.
* Le problème est que personne n'est capable de réécrire le moteur de rendu.


= Projets en cours / Infos=
===Sharpview===
* [https://wiki.secondlife.com/wiki/AIS AIS] V3: changements de code sur tout ce qui concerne le stockage... toutes les bases de données et l'enregistrement des régions pour SL.
* Sharpview est 0% de code Linden Lab et 100% [https://fr.wikipedia.org/wiki/Rust_(langage) Rust].
* Lorsque quelqu'un veut le code, il est dirigé vers un test open source de la pile de rendu, et il doit le compiler et de le construire. Jusqu'à présent, personne ne l'a fait.
* '''Test : ce lien mène vers un jeu factice avec la même structure que Sharpview''' et qui doit être compilé : https://github.com/John-Nagle/ui-mock .
** Tout est géré par le système [https://fr.wikipedia.org/wiki/Cargo_(informatique) Cargo] de Rust ([https://doc.rust-lang.org/stable/cargo/ Site officiel(en)].  Il suffit d'installer Rust, d'essayer "cargo build", et de voir ce qui se passe.
** Ce test fonctionne sous Windows et Linux.  
** Il faut encore tester sous MacOS. Faites savoir  à Joe Magarac comment cela fonctionne. Il devra être compilé dans Xcode pour que l'application finale s'exécute comme une application de bureau, donc idéalement il doit être signé.


= Compilation =
* Il a été question de compilation [https://fr.wikipedia.org/wiki/Compilation_anticip%C3%A9e#Articles_connexes AOT (Ahead-of-Time)] et [https://fr.wikipedia.org/wiki/Compilation_%C3%A0_la_vol%C3%A9e JIT (Just-in-Time)]. Il semble qu'OpenSim ait choisi la compilation JiT . Le changement de performance entre AOT et JIT est principalement sur le chargement des méthodes.
= Source=
= Source=
* http://opensimulator.org/wiki/Chat_log_from_the_meeting_on_2023-10-31
http://opensimulator.org/wiki/Chat_log_from_the_meeting_on_2023-11-07
<!--
[1:01 PM PT]  Ubit Umarov: i did made several changes to how we did use memory
[1:01 PM PT]  Ubit Umarov: and dotnet gc is a bit better
[1:02 PM PT]  Ubit Umarov: but for example all lludp packet buffers are now reused
[1:02 PM PT]  Ubit Umarov: that is a lot less stress on gc
[1:03 PM PT]  Vincent.Sylvester @hg.zetaworlds.com: I need to explore some ways to profile what goes on and see what takes up the most cpu time, that may point to where something is running a bit too often
[1:03 PM PT]  Ubit Umarov: ( well that started in 0.9.1 ?? )
[1:03 PM PT]  Ubit Umarov: profile needs to do several http requests
[1:03 PM PT]  Clifford.Hanger @alternatemetaverse.com:8002: i have 2 identical regions running on nessie and yeti i see minor difference in cpu
[1:04 PM PT]  Ubit Umarov: but thing on overall cpu usage is now a lot less also
[1:04 PM PT]  Vincent.Sylvester @hg.zetaworlds.com: It's just a worry of mine, when you have "natural" throttles in the form of slow code and they suddenly go away you might get hiccups elsewhere when code was tuned to work at similar speeds
[1:04 PM PT]  Clifford.Hanger @alternatemetaverse.com:8002: one is 8% the other 9%
[1:04 PM PT]  Ubit Umarov: lludp sending is now also done with fastfoward serialization without intermediate structures
[1:05 PM PT]  Ubit Umarov: and some some caps..
[1:05 PM PT]  Jagga Meredith: could that be within the real of statistical error?
[1:05 PM PT]  Jagga Meredith: realm
[1:05 PM PT]  Clifford.Hanger @alternatemetaverse.com:8002: i think so
[1:06 PM PT]  Clifford.Hanger @alternatemetaverse.com:8002: both regions are empty
[1:06 PM PT]  Clifford.Hanger @alternatemetaverse.com:8002: of people
[1:06 PM PT]  Clifford.Hanger @alternatemetaverse.com:8002: both have same content
[1:06 PM PT]  Ubit Umarov: well cpu load is not that a big metric...  things need to use cpu to work :P
[1:07 PM PT]  Vincent.Sylvester @hg.zetaworlds.com: It's difficult to measure that stuff accurately given the amount of variables you have in play. It is mostly just looking at usage during peak hours and comparing that to how things used to behave. Noticing mostly a difference in how usage grows more quickly and then levels off, over a more linear growth
-->

Dernière version du 30 novembre 2024 à 12:51

Changements du code de la semaine

Avertissement

Attention : Ce résumé existe pour orienter vos recherches. Des erreurs d'interprétation ne sont pas à exclure. Pour plus de précisions, veuillez vous référer aux sources ou vous adresser directement aux développeurs d'OpenSimulator en assistant aux réunions du mardi ou sur le canal IRC


Code général

Utilisation du CPU

  • L'utilisation de Dotnet provoquerait une utilisation plus importante du CPU, mais tout le monde n'a pas vu d'augmentation spéctaculaire.
  • Observation de Vincent Sylvester : Augmentation probable de l'ordre de 15 à 30 % selon les cas. Il a remarqué que c'était un peu linéaire jusqu'à un certain point et que l'utilisation a tendance à augmenter beaucoup plus rapidement puis à ralentir un peu. "C'est effrayant de voir une utilisation de 250% cpu avec beaucoup d'utilisateurs."
  • Problème potentiel : Quelque chose qui tourne deux fois plus vite sans aucune limitation pourrait causer des goulots d'étranglement ailleurs.
  • NDLR 🏗️ (je sature il reste encore 6 minutes de chat.)

Bugs

Les librairies non gérées de macOS ne se chargent pas

  • Lien du ticket 0009097 (en) : http://opensimulator.org/mantis/view.php?id=9097
  • Affecte macOS spécifiquement, branche dotnet6. Même résultat sur Mac x86_64 et Mac arm64 .
  • Les certificats Apple Developer utilisés pour signer les bibliothèques non gérées de macOS étaient sur le point d'expirer. La génération de nouveaux certificats nécessitait la révocation des anciens. En conséquence, opensim n'a pas pu démarrer. Les trois bibliothèques non gérées dans le repo ne parvenaient pas à se charger à cause du certificat de distribution révoqué qui était utilisé pour les bibliothèques non gérées dans le tronc (branche dotnet6).
  • Les nouvelles librairies ont été transférées dans la branche dotnet6, OpenSim est opérationnel sur macOS, les utilisateurs de macOS devront faire une mise à jour. Les librairies fonctionneront sur n'importe quel macOS 10.5-latest.
  • Précision de Gavin Hird : si un logiciel est démarré depuis le terminal, la signature n'est pas vérifiées.
  • NDLR : je n'ai jamais utilisé un Mac de ma vie, donc je vais m'arrêter là dans le résumé de ce sujet de peur de faire de grosses erreurs.

Disparition de la bibliothèque OpenSim

  • La bibliothèque OpenSim aurait disparu dans l'inventaire du viewer (NDLR: sur Argentoratum c'est le cas).
  • Ubit Umarov a encore la bibliothèque même dans Firestorm Beta avec les récents changements.
  • Le problème doit venir de la configuration Robust. (NDRL : je devais regarder ce qui se passe, je mettrai la solution ici si je la trouve).

Viewers

Dayturn

  • Compilation du viewer Windows avec Visual Studio 2022
  • Gavin Hird a pour projet d'essayer Mumble avec la version Mac du viewer.

Firestorm

  • Avec la version 7.0 alpha certaines choses ne fonctionnent plus à cause d'un changement de protocole d'inventaire. Des vignettes d'inventaire s'affichent mais ne fonctionnent pas parce que les développeurs utilisent le code pour l'AIS V3 (voir la réunion du 03-10-2023).

Viewer Second Life

  • Il semble que SL travaille sur beaucoup de choses à la fois et tout devient instable dans les viewers.
  • Gavin.Hird est presque sûr que SL developpe une version Xbox du viewer. Ils pourraient aussi abandonner le support Mac, parce qu'ils ont mis à jour les instructions de construction pour la version Windows, mais les instructions de la version Mac sont significativement dépassées. Les utilisateurs de Mac seront à la traîne par rapport aux utilisateurs de Windows en termes de fonctionnalités et de performances dixit le chef technique de SL. Apple a dit qu'ils allaient se débarrasser d'OpenGL et la seule chose qui fonctionne sur macOS est Metal.
  • Vincent.Sylvester trouve qu'il aurait fallu plus de modularité pour une adaptation à d'autres contrôles de jeu.
  • Joe Magarac dit que la prise en charge des contrôleurs de jeu utilisera la norme Human Interface Device. Cette norme prend en charge la plupart des appareils qui se branchent sur un port USB.
  • Paradoxalement, il est aussi question d'un viewer pour iPad.
  • Le projet du Viewer mobile fonctionne avec Vulkan. Cuga.Raja suppose qu'UDP ne sera plus utilisé (donc passage à TCP) pour le Viewer mobile. L'ancienne idée pour le mobile était d'utiliser une sorte de streaming vidéo côté serveur.
  • Les viewers OpenSim sont à 95% du code Linden Lab. D'après Ubit Umarov, la corde de la dépendance est peut-être sur le point de se rompre. Certains changements sont tout simplement trop mauvais pour être suivis. Quand firestorm a speraté OpenSim et SL, ils ont arrêté de faire du code pour nous... Vincent Sylvester dit changer le pipeline de développement et nettoyer le désordre des dépendances ne serait pas seulement bénéfique pour nous, mais rendrait généralement plus facile le développement d'un viewer en utilisant le code Linden Lab. C'est une entreprise de grande envergure et cela ne résout pas complètement le problème de la compatibilité.
  • Le problème est que personne n'est capable de réécrire le moteur de rendu.

Sharpview

  • Sharpview est 0% de code Linden Lab et 100% Rust.
  • Lorsque quelqu'un veut le code, il est dirigé vers un test open source de la pile de rendu, et il doit le compiler et de le construire. Jusqu'à présent, personne ne l'a fait.
  • Test : ce lien mène vers un jeu factice avec la même structure que Sharpview et qui doit être compilé : https://github.com/John-Nagle/ui-mock .
    • Tout est géré par le système Cargo de Rust (Site officiel(en). Il suffit d'installer Rust, d'essayer "cargo build", et de voir ce qui se passe.
    • Ce test fonctionne sous Windows et Linux.
    • Il faut encore tester sous MacOS. Faites savoir à Joe Magarac comment cela fonctionne. Il devra être compilé dans Xcode pour que l'application finale s'exécute comme une application de bureau, donc idéalement il doit être signé.

Compilation

  • Il a été question de compilation AOT (Ahead-of-Time) et JIT (Just-in-Time). Il semble qu'OpenSim ait choisi la compilation JiT . Le changement de performance entre AOT et JIT est principalement sur le chargement des méthodes.

Source

http://opensimulator.org/wiki/Chat_log_from_the_meeting_on_2023-11-07

Récupérée de « https://cogito.no-ip.info/cogito/OSWiki/index.php?title=Réunion_du_31-10-2023&oldid=211 »