« Réunion du 18-03-2025 » : différence entre les versions
Apparence
| (35 versions intermédiaires par le même utilisateur non affichées) | |||
| Ligne 29 : | Ligne 29 : | ||
= 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]. Je ne fais pas partie des développeurs, ne vous adressez pas à moi pour les joindre. Merci.😉}} | {{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]. Je ne fais pas partie des développeurs, ne vous adressez pas à moi pour les joindre. Merci.😉}} | ||
= Scripts= | = Scripts= | ||
== LlSetHoverHeight== | == LlSetHoverHeight== | ||
<pre>Function: llSetHoverHeight( float height, integer water, float tau );</pre> | <pre>Function: llSetHoverHeight( float height, integer water, float tau );</pre> | ||
* Rôle : Se positionne à l'altitude cible au dessus du sol (ou de l’eau) en tau secondes. | |||
* Dans OpenSim, [https://wiki.secondlife.com/wiki/LlSetHoverHeight/fr llSetHoverHeight] ne fonctionne pas comme sur Second Life. | * Dans OpenSim, [https://wiki.secondlife.com/wiki/LlSetHoverHeight/fr llSetHoverHeight] ne fonctionne pas comme sur Second Life. | ||
* Sur opensim c'est réglé sur l'avatar, il continue à flotter jusqu'à ce qu'on l'arrête. | * Sur opensim c'est réglé sur l'avatar, il continue à flotter jusqu'à ce qu'on l'arrête. | ||
* Il semblerait que l'effet soit perdu après une téléportation ou les traversées (comme sur Second Life). | * Il semblerait que l'effet soit perdu après une téléportation ou les traversées (comme sur Second Life). | ||
* [http://opensimulator.org/mantis/view.php?id=9184 '''Mantis 0009184'''] : Après la mise à niveau d'Opensim 9.2 vers la version 9.3, la fonction llSetHoverHeight() a cessé de fonctionner correctement. | |||
== LlGroundRepel == | |||
<pre>Function: llGroundRepel( float height, integer water, float tau );</pre> | |||
* Cette [https://wiki.secondlife.com/wiki/LlGroundRepel llGroundRepel] amortit de manière critique à 'height' si la hauteur est inférieure ou égale à 0,5 fois la hauteur du sol ou du niveau de l'eau (la plus élevée des deux). | |||
* La fonction est cassée, il faut la corriger. | |||
= Base de données = | = Base de données = | ||
== Problèmes avec SqLite == | == Problèmes avec SqLite sur macOS== | ||
=== Problème === | |||
*Le problème mentionné concerne SQLite sur macOS, où il semble que le [https://fr.wikipedia.org/wiki/Data_mapping mappage] des bibliothèques dynamiques (dylib) soit ignoré. Cela signifie que le système ne parvient pas à localiser ou à utiliser correctement les bibliothèques dynamiques nécessaires pour le fonctionnement de SQLite, ce qui peut entrainer des erreurs ou un comportement inattendu lors de l'exécution de l'application. | |||
* macOS utilise une convention différente en indiquant les types de données en majuscules. | |||
* Le code actuel fonctionne sans problème majeur, car il ne semble pas être affecté. | |||
* Cela pose un problème pour le système de migration que Vincent Sylvester développe, car il effectue une comparaison sensible à la casse de la structure de la table, ce qui entraîne des erreurs ou le système explose. | |||
* MacOS a une bibliothèque SqLite plus récente qui date de 2018 à 2019, mais le passage aux majuscules SqLite a eu lieu en 2021, elle devrait se comporter de la même manière que sous Windows et Linux. libsqlite3.dylib a la date de création Nov 5, 2019 | |||
=== Hypothèse et questions === | |||
* La dylib fournie par l'application pourrait ne pas être utilisée, et la version locale du système est chargée à la place, ce qui entraine des comportements inattendus. | |||
* Il devrait obéir au mapping fourni, à moins que quelque chose n'ait changé. | |||
* Est-ce dotnet ou le système qui en charge un autre ? | |||
* Vincent Sylvester demande à Gavin Hird et à Cuga Rajal de lui confirmer que macOS charge la dylib SqLite fournie. Gavin Hird répond que les fichiers et les bibliothèques ouverts par le processus sont affichés dans le moniteur d'activité. | |||
=== Discutions === | |||
* Il faut gérer cela dans le code, mais cela laisse entendre que le mappage est ignoré, ce qui pourrait causer d'autres problèmes à l'avenir. | |||
* Gavin Hird dit qu'OpenSim n'utilise pas la dylib fournie par le système, il utilise celle dont il est sûr et l'exécute dans l'émulateur de Rosetta[https://fr.wikipedia.org/wiki/Rosetta_(logiciel)] sur sa machine, ce qu'il considère être un problème. | |||
* Vincent résume le problème : s'il charge le code fourni, comment ce changement de majuscule s'est-il retrouvé là ? Il devait déjà être en développement ou quelque chose comme ça. S'il charge celui du système, alors le mappage est ignoré et ce n'est pas bon ; idéalement, il devrait lui obéir. | |||
* Cuga Rajal explique que si la majuscule est la nouvelle norme, les autres systèmes d'exploitation vont aussi l'adopter, et il y aura un mélange de majuscules et de minuscules. | |||
* Vincent Sylvester dit qu'il faut le gérer correctement dans le code dans les deux cas. | |||
* Ubit Umarov dit que .NET utilisera automatiquement la version la plus récente qu'il trouve. | |||
* Vincent Sylvester s'inquiète que quelque chose d'autre soit changé, par exemple que des types soient supprimés ou modifiés. Le pire cas serait les pannes silencieuses ou même la corruption de données, par exemple s'il tronque quelque chose implicitement. Les changements dans la bibliothèque qui nécessitent des modifications dans le code pour le supporter sont un gros problème. Cela signifie que nous devons nous abonner aux mises à jour de toutes les bibliothèques et suivre leurs changements pour savoir s'il y a quelque chose qui pourrait faire disjoncter notre code. | |||
* On peut changer les choses pour s'adapter, mais certains utilisateurs peuvent encore utiliser d'anciennes bases de données et ont donc besoin d'être rétrocompatibles. Ce n'est pas toujours facile quand il y a des changements radicaux. | |||
* Vincent Sylvester a déjà corrigé cela dans le code du nouveau système de migration, puisque le problème peut être reproduit sur Windows en chargeant de force une version plus récente de SQLite. Il n'a testé que le démarrage, sans tests réels, donc cela peut provoquer des bugs imprévus. | |||
=== Tests === | |||
==== Premier test ==== | |||
* Cuga Rajal a démarré OpenSim sur silicon Mac avec sqlite configuré, la bibliothèque sqlite n'est pas listée pas de dylib, seulement des DLL SqLite dans l'arbre OpenSim. S'il utilise la commande grep pour trouver dylib, il obtient 7 résultats, tous système et pas dans pas celle dans lib64. | |||
/opt/homebrew/Cellar/sqlite/3.49.1/lib/libsqlite3.3.49.1.dylib | |||
==== Deuxième test ==== | |||
* Cuga Rajal a fait un autre test sur un Mac Intel. Dotnet a chargé lib64/libsqlite3.dylib. | |||
==== Bilan ==== | |||
* dotnet a probablement compris qu'il ne pouvait pas l'exécuter la dylib fournie, et a cherché la prochaine version qu'il pouvait exécuter. | |||
* La solution est de recompiler une version similaire de la dylib non gérée ( [https://github.com/sqlite/sqlite/releases/tag/version-3.7.5 version 3.7.5] ) avec le support arm64. Une compilation avec arch arm64 pourrait corriger le problème. | |||
* Les bibliothèques avaient été remplacée par Ubit Umarov en 2019. Voir la [http://opensimulator.org/mantis/view.php?id=8624 '''mantis 8624'''] : remplacement des bibliothèques natives pour Mac par celles signées par Geir Nøklebye (Gavin Hird). | |||
* Cugal Rajal va le faire et il va ouvrir une Mantis pour partager le binaire. | |||
= Bugs = | = Bugs = | ||
= | == Crash sur dotnet dans Appel M3 Pro == | ||
= | === Problème === | ||
= | * Impossible de se connecter au simulateur, avec un message d'erreur dans la console "zsh: segmentation fault dotnet OpenSim.dll" | ||
* [http://opensimulator.org/mantis/view.php?id=9183 Mantis 9183] | |||
=== Discution === | |||
* Cuga Rajal dit que cet utilisateur ne veut pas compiler OpenSim, le bug n'est pas reproductible pour les utilisateurs qui suivent les instructions. | |||
* Il utilise la version actuelle de dotnet 8 installée depuis le site de Microsoft. | |||
= Source= | = Source= | ||
http://opensimulator.org/wiki/Chat_log_from_the_meeting_on_2025-03-18 | http://opensimulator.org/wiki/Chat_log_from_the_meeting_on_2025-03-18 | ||
Dernière version du 7 septembre 2025 à 06:16
Changements du code de la semaine
Profil
Limiter le nombre de favoris
- Commit 1855be : Mettre des limites sur certains champs des lieux favoris du profil.
- Commit 75e9a4 : N'envoyer aux viewers que les 20 profils présélectionnés les mieux classés.
- Commit b63acc : Envoyer MaxProfilePicks au vivewer dans simulatorFeatures
- Commit c8b881 : Modifier les favoris, mettre à jour/ajouter, appliquer le nombre maximal de favoris.
- Ubit Umarov a défini à 20 le nombre de lieux favoris du profil, cela correspond à ce qui est appliqué dans Second Life ("le côté obscur").
- Les Viewers ont imposé une limite de 10. Ainsi, maintenant, [ https://jira.firestormviewer.org/browse/FIRE-35252 avec unelimite de 20 favoris, Firestorm est cassé].Ci dessous un extrait de commentaires du rapport de bug de Firestorm :
Ouvrir un profil pour un autre utilisateur fonctionne bien. Il suffit de faire un clic droit sur votre avatar et de sélectionner "profil". Vous obtiendrez un indicateur de chargement bleu et le visualiseur cesse de répondre. La date de naissance montre "chargement", donc il semble essayer de récupérer les informations du profil.
- L'issue est toujours ouverte le jour de la réunion, donc il ne faut pas encore fusionner cela.
- Le problème est sur la dernière version beta de fs.
- Il semble que tous les favoris sont enregistrés, mais que seuls les 20 premiers sont affichés. Le serveur OpenSim effectue probablement un tri basé sur des critères spécifiques comme la date (?) pour déterminer quels favoris afficher dans le profil de l'utilisateur.
- Côté Second Life c'est un changement de code "commercial" qui remplace la limite de 10 Favoris par 20, bien entendu payants.
Animation de l'avatar
- Commit 65eee2 : Modification de l'animation de l'avatar lors du vol forcé, nécessite plus de tests.
- Il y avait un petit bug avec la hauteur de survol qui empêchait de ralentir correctement. Après quelques ajustements, cela fonctionne maintenant beaucoup mieux.
- Lorsque l'avatar est en mode de survol, il affichera maintenant une animation appropriée qui correspond à cette action.
Nombre d'animeshes portés
- Commit 11cb8b : Cosmétiques ; autoriser le port de 3 Animeshes.
- Dans Second Life la limite est de 1 pour le non-premium et de 2 pour le premium. Dans OpenSim tout le monde est premium.
- On peut probablement augmenter cette limite si nécessaire. Il suffit de se référer au commit, de modifier le code source, puis de le compiler
- Mais, le viewer a des restrictions, il y a des limites sur le nombre de pièces jointes animées qu'un utilisateur peut porter.
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. Je ne fais pas partie des développeurs, ne vous adressez pas à moi pour les joindre. Merci.😉 |
Scripts
LlSetHoverHeight
Function: llSetHoverHeight( float height, integer water, float tau );
- Rôle : Se positionne à l'altitude cible au dessus du sol (ou de l’eau) en tau secondes.
- Dans OpenSim, llSetHoverHeight ne fonctionne pas comme sur Second Life.
- Sur opensim c'est réglé sur l'avatar, il continue à flotter jusqu'à ce qu'on l'arrête.
- Il semblerait que l'effet soit perdu après une téléportation ou les traversées (comme sur Second Life).
- Mantis 0009184 : Après la mise à niveau d'Opensim 9.2 vers la version 9.3, la fonction llSetHoverHeight() a cessé de fonctionner correctement.
LlGroundRepel
Function: llGroundRepel( float height, integer water, float tau );
- Cette llGroundRepel amortit de manière critique à 'height' si la hauteur est inférieure ou égale à 0,5 fois la hauteur du sol ou du niveau de l'eau (la plus élevée des deux).
- La fonction est cassée, il faut la corriger.
Base de données
Problèmes avec SqLite sur macOS
Problème
- Le problème mentionné concerne SQLite sur macOS, où il semble que le mappage des bibliothèques dynamiques (dylib) soit ignoré. Cela signifie que le système ne parvient pas à localiser ou à utiliser correctement les bibliothèques dynamiques nécessaires pour le fonctionnement de SQLite, ce qui peut entrainer des erreurs ou un comportement inattendu lors de l'exécution de l'application.
- macOS utilise une convention différente en indiquant les types de données en majuscules.
- Le code actuel fonctionne sans problème majeur, car il ne semble pas être affecté.
- Cela pose un problème pour le système de migration que Vincent Sylvester développe, car il effectue une comparaison sensible à la casse de la structure de la table, ce qui entraîne des erreurs ou le système explose.
- MacOS a une bibliothèque SqLite plus récente qui date de 2018 à 2019, mais le passage aux majuscules SqLite a eu lieu en 2021, elle devrait se comporter de la même manière que sous Windows et Linux. libsqlite3.dylib a la date de création Nov 5, 2019
Hypothèse et questions
- La dylib fournie par l'application pourrait ne pas être utilisée, et la version locale du système est chargée à la place, ce qui entraine des comportements inattendus.
- Il devrait obéir au mapping fourni, à moins que quelque chose n'ait changé.
- Est-ce dotnet ou le système qui en charge un autre ?
- Vincent Sylvester demande à Gavin Hird et à Cuga Rajal de lui confirmer que macOS charge la dylib SqLite fournie. Gavin Hird répond que les fichiers et les bibliothèques ouverts par le processus sont affichés dans le moniteur d'activité.
Discutions
- Il faut gérer cela dans le code, mais cela laisse entendre que le mappage est ignoré, ce qui pourrait causer d'autres problèmes à l'avenir.
- Gavin Hird dit qu'OpenSim n'utilise pas la dylib fournie par le système, il utilise celle dont il est sûr et l'exécute dans l'émulateur de Rosetta[1] sur sa machine, ce qu'il considère être un problème.
- Vincent résume le problème : s'il charge le code fourni, comment ce changement de majuscule s'est-il retrouvé là ? Il devait déjà être en développement ou quelque chose comme ça. S'il charge celui du système, alors le mappage est ignoré et ce n'est pas bon ; idéalement, il devrait lui obéir.
- Cuga Rajal explique que si la majuscule est la nouvelle norme, les autres systèmes d'exploitation vont aussi l'adopter, et il y aura un mélange de majuscules et de minuscules.
- Vincent Sylvester dit qu'il faut le gérer correctement dans le code dans les deux cas.
- Ubit Umarov dit que .NET utilisera automatiquement la version la plus récente qu'il trouve.
- Vincent Sylvester s'inquiète que quelque chose d'autre soit changé, par exemple que des types soient supprimés ou modifiés. Le pire cas serait les pannes silencieuses ou même la corruption de données, par exemple s'il tronque quelque chose implicitement. Les changements dans la bibliothèque qui nécessitent des modifications dans le code pour le supporter sont un gros problème. Cela signifie que nous devons nous abonner aux mises à jour de toutes les bibliothèques et suivre leurs changements pour savoir s'il y a quelque chose qui pourrait faire disjoncter notre code.
- On peut changer les choses pour s'adapter, mais certains utilisateurs peuvent encore utiliser d'anciennes bases de données et ont donc besoin d'être rétrocompatibles. Ce n'est pas toujours facile quand il y a des changements radicaux.
- Vincent Sylvester a déjà corrigé cela dans le code du nouveau système de migration, puisque le problème peut être reproduit sur Windows en chargeant de force une version plus récente de SQLite. Il n'a testé que le démarrage, sans tests réels, donc cela peut provoquer des bugs imprévus.
Tests
Premier test
- Cuga Rajal a démarré OpenSim sur silicon Mac avec sqlite configuré, la bibliothèque sqlite n'est pas listée pas de dylib, seulement des DLL SqLite dans l'arbre OpenSim. S'il utilise la commande grep pour trouver dylib, il obtient 7 résultats, tous système et pas dans pas celle dans lib64.
/opt/homebrew/Cellar/sqlite/3.49.1/lib/libsqlite3.3.49.1.dylib
Deuxième test
- Cuga Rajal a fait un autre test sur un Mac Intel. Dotnet a chargé lib64/libsqlite3.dylib.
Bilan
- dotnet a probablement compris qu'il ne pouvait pas l'exécuter la dylib fournie, et a cherché la prochaine version qu'il pouvait exécuter.
- La solution est de recompiler une version similaire de la dylib non gérée ( version 3.7.5 ) avec le support arm64. Une compilation avec arch arm64 pourrait corriger le problème.
- Les bibliothèques avaient été remplacée par Ubit Umarov en 2019. Voir la mantis 8624 : remplacement des bibliothèques natives pour Mac par celles signées par Geir Nøklebye (Gavin Hird).
- Cugal Rajal va le faire et il va ouvrir une Mantis pour partager le binaire.
Bugs
Crash sur dotnet dans Appel M3 Pro
Problème
- Impossible de se connecter au simulateur, avec un message d'erreur dans la console "zsh: segmentation fault dotnet OpenSim.dll"
- Mantis 9183
Discution
- Cuga Rajal dit que cet utilisateur ne veut pas compiler OpenSim, le bug n'est pas reproductible pour les utilisateurs qui suivent les instructions.
- Il utilise la version actuelle de dotnet 8 installée depuis le site de Microsoft.
Source
http://opensimulator.org/wiki/Chat_log_from_the_meeting_on_2025-03-18