« Réunion du 18-01-2022 » : différence entre les versions

De OSWiki
Aller à la navigation Aller à la recherche
 
(21 versions intermédiaires par le même utilisateur non affichées)
Ligne 22 : Ligne 22 :
[11:04] Gavin.Hird @grid.xmir.org:8002 : 5°C de trop
[11:04] Gavin.Hird @grid.xmir.org:8002 : 5°C de trop
</pre>
</pre>
= Cache des objets =
= Bogue du cache des objets =
[https://github.com/aurora-sim Aurora]: projet dérivé d'OpenSim qui met l'accent sur l'assistance à tous les utilisateur.
 
<pre>
<pre>
[11:04] Vincent.Sylvester @hg.zetaworlds.com:8002 : Gavin as-tu vu la correction du bug du cache objet ?
[11:04] Vincent.Sylvester @hg.zetaworlds.com:8002 : Gavin as-tu vu la correction du bug du cache d'objet ?
[11:04] Gavin.Hird @grid.xmir.org:8002 : Je l'ai compilé
[11:04] Gavin.Hird @grid.xmir.org:8002 : Je l'ai compilé
[11:04] Gavin.Hird @grid.xmir.org:8002 : donc d'un jour à l'autre.
[11:04] Gavin.Hird @grid.xmir.org:8002 : donc d'un jour à l'autre.
Ligne 35 : Ligne 37 :
[11:05] Ubit Umarov : c'est 1 heure sur les anciennes versions.
[11:05] Ubit Umarov : c'est 1 heure sur les anciennes versions.
[11:06] Ubit Umarov : il vaut mieux recharger quelques prims au cas où vous auriez besoin d'en tester plusieurs et attendre 15 minutes.
[11:06] Ubit Umarov : il vaut mieux recharger quelques prims au cas où vous auriez besoin d'en tester plusieurs et attendre 15 minutes.
[11:06] Vincent.Sylvester @hg.zetaworlds.com:8002 : J'ai désactivé le caps sur certaines régions pour tester et j'ai du mal à voir ce que cela  fait en termes de performances. Bien sûr, les prims sont mises en cache pour qu'elles s'affichent plus rapidement, mais j'ai du mal à "voir" la différence.
[11:06] Vincent.Sylvester @hg.zetaworlds.com:8002 : J'ai désactivé les caps sur certaines régions pour tester et j'ai du mal à voir ce que cela  fait en termes de performances. Bien sûr, les prims sont mises en cache pour qu'elles s'affichent plus rapidement, mais j'ai du mal à "voir" la différence.
[11:07] Ubit Umarov : Ohh c'est énorme
[11:07] Ubit Umarov : Ohh c'est énorme
[11:07] Ubit Umarov : au retour dans une région
[11:07] Ubit Umarov : au retour dans une région
[11:07] Vincent.Sylvester @hg.zetaworlds.com:8002 : Je n'en doute pas, surtout si la connexion est plus lente, etc.
[11:07] Vincent.Sylvester @hg.zetaworlds.com:8002 : Je n'en doute pas, surtout si la connexion est plus lente, etc.
[11:07] Ubit Umarov : très visible.
[11:07] Ubit Umarov : très visible.
[11:08] Ubit Umarov : Bien sûr, de temps en temps Firestorm s'étrangle en rezzant les prims.s
[11:08] Ubit Umarov : Bien sûr, de temps en temps Firestorm s'étrangle en rezzant les prims.
[11:08] Ubit Umarov : et de temps en temps, aucune idée pourquoi, certaines restent trasparentes jusqu'à ce qu'elles soient touchées.
[11:08] Ubit Umarov : et de temps en temps, aucune idée pourquoi, certaines restent trasparentes jusqu'à ce qu'elles soient touchées.
[11:09] Vincent.Sylvester @hg.zetaworlds.com:8002 : Peut-être que le test sur les varegions  avec 50000 objets le remplit probablement ou quelque chose comme ça, en fait la taille du cache par défaut n'est pas très grande.
[11:09] Vincent.Sylvester @hg.zetaworlds.com:8002 : Peut-être que le test sur les varegions  avec 50000 objets le remplit probablement ou quelque chose comme ça, en fait la taille du cache par défaut n'est pas très grande.
[11:09] Ubit Umarov: also culling by distance is viewer side
[11:09] Ubit Umarov : le tri des objets par la distance est aussi réalisé côté du viewer.
[11:09] Ubit Umarov: ( where the bug was.. )
[11:09] Ubit Umarov : ( où le bug était.. )
[11:10] Vincent.Sylvester @hg.zetaworlds.com:8002: I was probably expecting more like back in the day waiting half an hour for a region to load fully or something with it turned off
[11:10] Vincent.Sylvester @hg.zetaworlds.com:8002 : Je m'attendais probablement à ce que ce soit plus comme à l'époque où il fallait attendre une demi-heure pour qu'une région se charge complètement ou quelque chose comme ça avec le cache désactivé.
[11:10] Ubit Umarov: thats a bad aspect of the object cache
[11:10] Ubit Umarov : c'est un mauvais point du cache d'objet.
[11:10] Ubit Umarov: viewer wants to get all the prims on a region at start
[11:10] Ubit Umarov : le viewer veut avoir toutes les prims d'une région au départ.
[11:11] Gavin.Hird @grid.xmir.org:8002: if not culling will be rather random
[11:11] Gavin.Hird @grid.xmir.org:8002 : si ce n'est pas le cas, le tri sera plutôt aléatoire.
[11:11] Ubit Umarov: i did soem work on server side culling even o top of that
[11:11] Ubit Umarov : j'ai fait un peu de travail sur la sélection côté serveur même en plus de cela.
[11:11] Ubit Umarov: option there
[11:11] Ubit Umarov : l'option est là.
[11:11] Ubit Umarov: but is heavy and did not finished
[11:11] Ubit Umarov : mais c'est lourd et je n'ai pas fini.
[11:11] Ubit Umarov: just SL never considered regions with 120K prims
[11:11] Ubit Umarov : SL n'a jamais envisagé de régions avec 120K prims.
[11:12] Ubit Umarov: but on other hand opensim never did culling as SL regions did
[11:12] Ubit Umarov : mais d'un autre côté opensim n'a jamais fait de filtrage comme le faisaient les régions SL.
[11:12] Ubit Umarov: so.. same thing
[11:12] Ubit Umarov : donc... même chose
[11:12] Vincent.Sylvester @hg.zetaworlds.com:8002: Was starting to lose my sanity over this thinking it was some obscure packet loss somewhere or something
[11:12] Vincent.Sylvester @hg.zetaworlds.com:8002 : Je commençais à perdre la raison en pensant que c'était une obscure perte de paquets quelque part ou quelque chose comme ça.
[11:12] Gavin.Hird @grid.xmir.org:8002: they rather have 1000 prims(meses) with 3 millions tries each to contend with
[11:12] Gavin.Hird @grid.xmir.org:8002 : ils préfèrent avoir 1000 prims(meshes) avec 3 millions de tests chacun pour faire face à la situation.
[11:13] Vincent.Sylvester @hg.zetaworlds.com:8002: It going all the way to LL and then being half a decade old code is just comical, the cherry on top
[11:13] Vincent.Sylvester @hg.zetaworlds.com:8002 : Cela va jusqu'à LL et ensuite c'est un code vieux d'une demi-décennie, c'est juste comique, la cerise sur le gâteau.
[11:13] Ubit Umarov: aurora did had culling
[11:13] Ubit Umarov : Aurora a fait de la sélection.
[11:13] Ubit Umarov: but also heavy
[11:13] Ubit Umarov : mais aussi lourd
[11:14] Ubit Umarov: interest lists per user.. looked at all the time..
[11:14] Ubit Umarov : listes d'intérêt par utilisateur... regardées tout le temps...
[11:14] Vincent.Sylvester @hg.zetaworlds.com:8002: Speaking of prims, been digging about today and found an old linkset with xml encoding utf 16 followed by utf 8 data
</pre>
[11:15] Vincent.Sylvester @hg.zetaworlds.com:8002: That based on some idea or should I just ignore that as bad formatting?
= Plusieurs formats d'encodages dans une vielle archive =
[11:16] Andrew Hellershanks: Sounds odd for it to have two different string encodings.
* [[OpenSim_Archives/fr |OAR - Archives OpenSim]
[11:16] Gavin.Hird @grid.xmir.org:8002: possibly written and updated by two different viewers
* [https://fr.wikipedia.org/wiki/UTF-8 UTF-8] --[https://fr.wikipedia.org/wiki/UTF-16 UTF-16]
[11:16] Andrew Hellershanks: Could be.
* BOM = Bakes on Mesh (moulage sur le maillage) :fonctionnalité qui permet d'afficher les textures  de l'avatar du système sur des pièces jointes en meshes.
[11:17] Vincent.Sylvester @hg.zetaworlds.com:8002: It's also missing a bunch of parameters in the xml like particle system and such things
* [[Related_Software/fr#Forks_d.27OpenSimulator | Grille InWorldz (voir Halcyon)]]
[11:17] Ubit Umarov: xml is a crap
<pre>
[11:17] Gavin.Hird @grid.xmir.org:8002: doe the thing rez?
[11:14] Vincent.Sylvester @hg.zetaworlds.com:8002 : En parlant de prims, j'ai creusé un peu aujourd'hui et j'ai trouvé un viel objet lié avec un encodage xml utf 16 suivi de données utf 8.
[11:17] Ubit Umarov: and opensim use of has not been the best
[11:15] Vincent.Sylvester @hg.zetaworlds.com:8002 : C'est basé sur l'idée que je dois simplement ignorer que c'est un mauvais formatage ?
[11:17] Ubit Umarov: and opensim use of it has not been the best
[11:16] Andrew Hellershanks : Cela semble étrange qu'il y ait deux encodages de chaînes différents.
[11:18] Ubit Umarov: also ms documentation on it is confusing
[11:16] Gavin.Hird @grid.xmir.org:8002 : peut-être écrit et mis à jour par deux personnes différentes.
[11:18] Ubit Umarov: so.. yeah  utf-16 may had shown up on oars
[11:16] Andrew Hellershanks : C'est possible.
[11:18] Ubit Umarov: at least on the first line
[11:17] Vincent.Sylvester @hg.zetaworlds.com:8002 : Il manque aussi un tas de paramètres dans le xml comme le système de particules et d'autres choses.
[11:18] Ubit Umarov: while actual data was utf-8
[11:17] Ubit Umarov : xml est une merde
[11:19] Vincent.Sylvester @hg.zetaworlds.com:8002: Haven't tried, I just found the asset data being flagged as malformed by the xml parsing so looking at it the linkset xml itself claimed utf16 encoding in the parameter of the header, but the parts xml all said utf8, weird double structure in there
[11:17] Gavin.Hird @grid.xmir.org:8002: est-ce que la chose se rezze ?
[11:19] Ubit Umarov: use of BOM also not that clear
[11:17] Ubit Umarov : et l'utilisation d'opensim n'a pas été la meilleure.
[11:19] Vincent.Sylvester @hg.zetaworlds.com:8002: It should be an inventory item so I might be able to find and rez it
[11:18] Ubit Umarov : aussi la documentation de MS est confuse.
[11:19] Gavin.Hird @grid.xmir.org:8002: double structure - like DNA?
[11:18] Ubit Umarov : donc... ouais l'utf-16 a pu apparaître dans les OARs
[11:20] Vincent.Sylvester @hg.zetaworlds.com:8002: Well like one xml open and close tag around a bunch of others for each link part
[11:18] Ubit Umarov : au moins sur la première ligne.
[11:20] Ubit Umarov: well and possible several oar formats outthere now
[11:18] Ubit Umarov : alors qu'en réalité les données étaient en utf-8
[11:20] Ubit Umarov: think inworldz had its own variant?
[11:19] Vincent.Sylvester @hg.zetaworlds.com:8002: Je n'ai pas essayé, j'ai juste trouvé les données d'assets marquées comme malformées par le parseur xml. En regardant le xml de l'OAR lui-même on voit la déclaration d'un encodage utf16 dans le paramètre de l'en-tête, mais les parties xml disent toutes utf8, une double structure bizarre là-dedans.
[11:20] Vincent.Sylvester @hg.zetaworlds.com:8002: Original creator is from osgrid back when that other profiles system was in use
[11:19] Ubit Umarov : l'utilisation de la BoM n'est pas non plus très claire.
[11:21] Ubit Umarov: i think the utf-16 on the header line is ignored if there is a BOM
[11:19] Vincent.Sylvester @hg.zetaworlds.com:8002 : Cela devrait être un élément de l'inventaire donc je pourrais le trouver et le "rezzer".
[11:22] Vincent.Sylvester @hg.zetaworlds.com:8002: Forcing utf8 encoding it parsed just fine though so at least the rest of it seems proper
[11:19] Gavin.Hird @grid.xmir.org:8002 : structure double - comme l'ADN ?
[11:22] Vincent.Sylvester @hg.zetaworlds.com:8002: Surprises me that it probably works as asset in OpenSim like that
[11:20] Vincent.Sylvester @hg.zetaworlds.com:8002 : Eh bien, comme une balise xml ouverte et fermée autour d'un tas d'autres pour chaque partie du lien.
[11:23] Ubit Umarov: guess that utf16 is still there even on new oars
[11:20] Ubit Umarov : il est possible que plusieurs formats OAR existent maintenant.
[11:23] Ubit Umarov: let me xee
[11:20] Ubit Umarov : je pense que Inworldz avait sa propre variante ?
[11:23] Vincent.Sylvester @hg.zetaworlds.com:8002: There are certainly some whacky data structures in OpenSim
[11:20] Vincent.Sylvester @hg.zetaworlds.com:8002 : Le créateur original vient d'osgrid, à l'époque où cet autre système de profils était utilisé.
[11:24] Vincent.Sylvester @hg.zetaworlds.com:8002: I recall decoding parcel blob data was a fun trip into bits and byte land
[11:21] Ubit Umarov : je pense que le utf-16 de la ligne d'en-tête est ignoré s'il y a une BOM.
[11:24] Gavin.Hird @grid.xmir.org:8002: xee - is that a new xml keyword?
[11:22] Vincent.Sylvester @hg.zetaworlds.com:8002: En forçant l'encodage utf8, il a été parsé correctement, donc au moins le reste semble correct.
[11:22] Vincent.Sylvester @hg.zetaworlds.com:8002 : Je suis surpris qu'il fonctionne probablement comme un asset dans OpenSim dans cet état.
[11:23] Ubit Umarov : je suppose que l'utf16 est toujours là même dans les nouveaux OARs.
[11:23] Ubit Umarov : laisse-moi vérifier (xee pour see dans la version originale).
[11:23] Vincent.Sylvester @hg.zetaworlds.com:8002 : Il y a certainement quelques structures de données farfelues dans OpenSim.
[11:24] Vincent.Sylvester @hg.zetaworlds.com:8002 : Je me souviens que le décodage des données du blob de parcel était un voyage amusant au pays des bits et des octets.
[11:24] Gavin.Hird @grid.xmir.org:8002 : xee - est-ce un nouveau mot clé xml ?
[11:24] Ubit Umarov: <SceneObjectGroup><SceneObjectPart xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
[11:24] Ubit Umarov: <SceneObjectGroup><SceneObjectPart xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
[11:24] Ubit Umarov: no idea why we thave that xsi bs
[11:24] Ubit Umarov : Je ne sais pas pourquoi nous avons ce xsi.
[11:25] Ubit Umarov: <?xml version="1.0" encoding="utf-16"?>
[11:25] Ubit Umarov: <?xml version="1.0" encoding="utf-16"?>
<RegionSettings>
<RegionSettings>
[11:26] Ubit Umarov: <?xml version="1.0" encoding="utf-16"?>
[11:26] Ubit Umarov: <?xml version="1.0" encoding="utf-16"?>
<archive major_version="0" minor_version="8">
<archive major_version="0" minor_version="8">
[11:26] Ubit Umarov: well this was broken from start
[11:26] Ubit Umarov : Eh bien, c'était cassé depuis le début.
[11:26] Vincent.Sylvester @hg.zetaworlds.com:8002: Thing is the data in there is utf8 most likely, because most of it is now
[11:26] Vincent.Sylvester @hg.zetaworlds.com:8002 : Le truc, c'est que les données qu'il contient sont probablement utf8, parce que la plupart d'entre elles le sont maintenant.
[11:26] Ubit Umarov: can't change now
[11:26] Ubit Umarov : on ne peut pas changer maintenant
[11:26] Ubit Umarov: utf-16 is a stupid encode
[11:26] Ubit Umarov : utf-16 est un code stupide.
[11:26] Ubit Umarov: but windows and linux went for it
[11:26] Ubit Umarov : mais Windows et Linux l'ont adopté.
[11:27] Ubit Umarov: like many early adopters of unicode
[11:27] Ubit Umarov : comme beaucoup d'adopteurs précoces de l'unicode.
[11:27] Ubit Umarov: at a point utf-16 was the entire unicode
[11:27] Ubit Umarov : à un moment donné, utf-16 était l'unicode complet.
[11:27] Ubit Umarov: unicode was so clever that decided 16bits was all that would be needed
[11:27] Ubit Umarov : l'unicode était si intelligent qu'il a décidé que 16bits étaient tout ce dont il avait besoin.
[11:28] Andrew Hellershanks: Yup. 64k should be enough for anyone. :)
[11:28] Andrew Hellershanks : Ouaip. 64k devrait être suffisant pour tout le monde :)
[11:28] Ubit Umarov: yeah when present all xml headers ssay utf8
[11:28] Ubit Umarov : ouais quand ils sont présents tous les en-têtes xml disent utf8
[11:28] Ubit Umarov: opoe utf-16
[11:28] Ubit Umarov : opoe utf-16
[11:28] Ubit Umarov: hmm let me see a file in binary
[11:28] Ubit Umarov : hmm laissez-moi vérifier dans un fichier en binaire.
[11:29] Vincent.Sylvester @hg.zetaworlds.com:8002: lxml.etree.XMLSyntaxError: Document labelled UTF-16 but has UTF-8 content, line 1, column 38
[11:29] Vincent.Sylvester @hg.zetaworlds.com:8002 : lxml.etree.XMLSyntaxError : Document étiqueté UTF-16 mais dont le contenu est UTF-8, ligne 1, colonne 38.
[11:30] Vincent.Sylvester @hg.zetaworlds.com:8002: Thankfully can always tell it to force utf8 in that case
[11:30] Vincent.Sylvester @hg.zetaworlds.com:8002 : Heureusement, on peut toujours lui dire de forcer utf8 dans ce cas.
[11:31] Ubit Umarov: file is utf8
[11:31] Ubit Umarov : le fichier est utf8
[11:31] Vincent.Sylvester @hg.zetaworlds.com:8002: Just really odd given it was also missing normal parameters for prims, I'd imagine those would eventually get added when reloading the asset via an archive, but doesn't seem to be the case either
[11:31] Vincent.Sylvester @hg.zetaworlds.com:8002 : C'est vraiment étrange car il manquait aussi les paramètres normaux pour les prims, j'aurais imaginé qu'ils seraient éventuellement ajoutés lors du rechargement de l'asset via une archive, mais cela ne semble pas être le cas non plus.
[11:31] Ubit Umarov: in fact ascii
[11:31] Ubit Umarov : en fait ascii
[11:31] Ubit Umarov: one byte per char
[11:31] Ubit Umarov : un octet par caractère
[11:31] Ubit Umarov: and no BOM
[11:31] Ubit Umarov : et pas de BOM
[11:32] Ubit Umarov: no idea how it works LOL
[11:32] Ubit Umarov : aucune idée de comment cela fonctionne LOL
[11:32] Ubit Umarov: ms xml crap
[11:32] Ubit Umarov : MS XML de merde
[11:32] Ubit Umarov: 3c 3f 78 6d 6c 20 76 65 72 73 69 6f 6e 3d 22 31 2e 30 22 20 65 6e 63 6f 64 69 6e 67 3d 22 75 74 66 2d 31 36 22 3f 3e 0d 0a 3c 61 72 63 68 69 76 65 20 6d 61 6a 6f 72 5f 76 65 72 73 69 6f 6e 3d
[11:32] Ubit Umarov: 3c 3f 78 6d 6c 20 76 65 72 73 69 6f 6e 3d 22 31 2e 30 22 20 65 6e 63 6f 64 69 6e 67 3d 22 75 74 66 2d 31 36 22 3f 3e 0d 0a 3c 61 72 63 68 69 76 65 20 6d 61 6a 6f 72 5f 76 65 72 73 69 6f 6e 3d
[11:32] Vincent.Sylvester @hg.zetaworlds.com:8002: I imagine if proper structure was enforced half the stuff in world wouldn't load anymore
[11:32] Vincent.Sylvester @hg.zetaworlds.com:8002 : J'imagine que si une structure correcte était appliquée, la moitié des choses dans le monde ne seraient plus chargées.
[11:32] Ubit Umarov: see? simple plain ascii
[11:32] Ubit Umarov : vous voyez ? un simple ascii ordinaire.
[11:34] Ubit Umarov: guess on read we do force utf8
[11:34] Ubit Umarov : je suppose qu'en lecture nous forçons utf8.
[11:34] Vincent.Sylvester @hg.zetaworlds.com:8002: I figured as much given the parser said it was all utf8 anyways
[11:34] Vincent.Sylvester @hg.zetaworlds.com:8002 : Je m'en doutais puisque l'analyseur syntaxique a dit que tout était en utf8 de toute façon.
[11:35] Vincent.Sylvester @hg.zetaworlds.com:8002: Got stuck on something else after that, but that's a different story for another time
[11:35] Vincent.Sylvester @hg.zetaworlds.com:8002 : J'ai été bloqué sur quelque chose d'autre après ça, mais c'est une autre histoire pour une autre fois.
[11:35] Ubit Umarov: utf-16 also has bit order issues lol
[11:35] Ubit Umarov : utf-16 a aussi des problèmes d'ordre de bit lol
[11:35] Ubit Umarov: byte order
[11:35] Ubit Umarov : ordre des octets
[11:36] Ubit Umarov: xml is so well done protocoll
[11:36] Ubit Umarov : le xml est un protocole si bien fait.
[11:36] Ubit Umarov: for a crap made on knees
[11:36] Ubit Umarov : pour une merde faite sur des genoux
[11:36] Vincent.Sylvester @hg.zetaworlds.com:8002: I been making more modules lately and found the old dreaded thread stuck on shutdown gets worse the more modules I add
</pre>
[11:37] Andrew Hellershanks: I thought that problem went away as of 0.9
 
[11:37] Vincent.Sylvester @hg.zetaworlds.com:8002: I thought so too
= Blocage de threads , bogue dans Mono =
[11:37] Vincent.Sylvester @hg.zetaworlds.com:8002: It is starting to look a bit like the reason for that is usage or data contained in those threads
* [https://fr.wikipedia.org/wiki/Mono_(logiciel) Mono]: mise en œuvre open source  de la plateforme de développement [https://fr.wikipedia.org/wiki/Microsoft_.NET Microsoft .NET]
[11:37] Vincent.Sylvester @hg.zetaworlds.com:8002: Given I add modules that put a lot of data out into the system tend to make the most impact
 
[11:38] Vincent.Sylvester @hg.zetaworlds.com:8002: So I wonder if the cause is some form of memory leak or other orphaned data that fails to clear
* [https://fr.wikipedia.org/wiki/Visual_Studio_Code VScode]: Visual Studio Code est un éditeur de code extensible développé par Microsoft pour Windows, Linux et macOS
[11:38] Vincent.Sylvester @hg.zetaworlds.com:8002: Especially when I do a lot of testing with the modules thus cause more data to go back and forth
<pre>
[11:39] Vincent.Sylvester @hg.zetaworlds.com:8002: On master I still see some red during shutdown on random threads not shutting down cleanly, though only on mono
[11:36] Vincent.Sylvester @hg.zetaworlds.com:8002 : J'ai créé plus de modules ces derniers temps et j'ai constaté que le redoutable thread bloqué à l'arrêt s'aggrave avec l'ajout de modules.
[11:40] Vincent.Sylvester @hg.zetaworlds.com:8002: on windows .net doing tests in vscode it all works splendidly
[11:37] Andrew Hellershanks : Je pensais que ce problème avait disparu avec la 0.9.
[11:40] Ubit Umarov: mono has issues on threads stop
[11:37] Vincent.Sylvester @hg.zetaworlds.com:8002 : Je le pensais aussi
[11:40] Ubit Umarov: lets them stuck on some things
[11:37] Vincent.Sylvester @hg.zetaworlds.com:8002: Il semblerait que l'origine de cela vienne de l'utilisation ou les données contenues dans ces threads.
[11:41] Ubit Umarov: in same cases can't even kill then the wai it wants, then gets stuck
[11:37] Vincent.Sylvester @hg.zetaworlds.com:8002 : Étant donné que j'ajoute les modules qui mettent beaucoup de données dans le système, ils ont tendance à avoir le plus d'impact.
[11:38] Vincent.Sylvester @hg.zetaworlds.com:8002 : Donc, je me demande si l'origine de cela ne serait pas une fuite de mémoire ou d'autres données orphelines qui ne parviennent pas à être effacées.
[11:38] Vincent.Sylvester @hg.zetaworlds.com:8002 : Surtout quand je fais beaucoup de tests avec les modules, ce qui entraîne plus d'allers-retours de données.
[11:39] Vincent.Sylvester @hg.zetaworlds.com:8002 : Sur master, je vois encore du rouge pendant l'arrêt des threads aléatoires qui ne s'arrêtent pas proprement, mais seulement sur Mono.
[11:40] Vincent.Sylvester @hg.zetaworlds.com:8002 : sous Windows .net, je fais des tests dans vscode et tout fonctionne parfaitement.
[11:40] Ubit Umarov : mono a des problèmes sur l'arrêt des threads.
[11:40] Ubit Umarov : et les laisse se bloquer sur certaines choses.
[11:41] Ubit Umarov: de la même façon, on ne peut même pas  les tuer comme il le faudrait, alors ils restent bloqués
[11:41] Jagga Meredith whispers: -[[[[[[[[[
[11:41] Jagga Meredith whispers: -[[[[[[[[[
[11:41] Ubit Umarov: ...the way...
[11:42] Vincent.Sylvester @hg.zetaworlds.com:8002 : On peut toujours vérifier si le simulateur répond aux "pings" et le faire disparaître , mais bien sûr, ce n'est pas l'idéal non plus...
[11:42] Vincent.Sylvester @hg.zetaworlds.com:8002: One can always check if the simulator responds to "pings" and nuke it, but of course not ideal either
[11:43] Andrew Hellershanks : Vincent, pour faire cela correctement, il faut plus d'un ping et suffisamment de temps entre eux pour permettre à l'instance de sauvegarder les données primaires dans la base de données afin qu'elle ne soit pas tuée alors qu'elle est encore en train de s'éteindre.
[11:42] Vincent.Sylvester @hg.zetaworlds.com:8002: It surprises me that bug is still in mono after all this time
</pre>
[11:42] Vincent.Sylvester @hg.zetaworlds.com:8002: Would assume we can't be the only ones to see it
 
[11:42] Gavin.Hird @grid.xmir.org:8002: mono is not being updated any more
= Mort de Mono ?=
[11:42] Ubit Umarov: well mono is now dead
* [https://www.mono-project.com/ Projet Mono]
[11:42] Gavin.Hird @grid.xmir.org:8002: yes
* [https://en.wikipedia.org/wiki/.NET_Framework_version_history .NET_Framework]
[11:42] Ubit Umarov: on its down hill
<pre>
[11:43] Ubit Umarov: ms made all the devel it needs to canabilze parts of it to dotnet
[11:42] Vincent.Sylvester @hg.zetaworlds.com:8002 : Je suis surpris que le bogue soit toujours dans mono après tout ce temps.
[11:43] Andrew Hellershanks: Vincent, to do that properly requires more than one ping and enough time between them to have allowed the instance to have saved prim data to the data base so that it doesn't get killed while it is still in the process of shutting down.
[11:42] Vincent.Sylvester @hg.zetaworlds.com:8002 : Je suppose que nous ne sommes pas les seuls à le voir.
[11:43] Ubit Umarov: now.. basicly dead
[11:42] Gavin.Hird @grid.xmir.org:8002 : mono n'est plus mis à jour.
[11:43] Kayaker Magic: so how is progress on mono's dotnet on Linux?
[11:42] Ubit Umarov : eh bien, mono est maintenant mort.
[11:43] Ubit Umarov: no updates in almost one year
[11:42] Gavin.Hird @grid.xmir.org:8002 : oui.
[11:43] Ubit Umarov: who cares..
[11:42] Ubit Umarov : sur sa pente descendante
[11:44] Ubit Umarov: opensim is a huge pain to covert to dotnet
[11:43] Ubit Umarov : MS a fait tout le developpement dont il a besoin pour cannibaliser certaines parties de dotnet.
[11:44] Ubit Umarov: we aill lose some features
[11:43] Ubit Umarov : maintenant... fondamentalement mort.
[11:44] Ubit Umarov: Xengine is one
[11:43] Kayaker Magic : où en est la progression de mono's dotnet sur Linux ?
[11:44] Ubit Umarov: even Yengine may have issues
[11:43] Ubit Umarov : aucune mise à jour depuis presque un an.
[11:45] Ubit Umarov: bitmap operations need to be converted to use other external lib, because removed from .net
[11:43] Ubit Umarov : qui s'en soucie...
[11:46] Ubit Umarov: that measn no map, no dynamic textures, even no lludp textures fetch some viewers still use
[11:44] Ubit Umarov : opensim est un gros problème à convertir en dotnet.
[11:46] Ubit Umarov: ann and no sculpt maps
[11:44] Ubit Umarov : nous allons perdre quelques fonctionnalités.
[11:47] Ubit Umarov: .net5 and 6 is just a huge breaking change
[11:44] Ubit Umarov : Xengine en est une
[11:47] Ubit Umarov: and .net framework 4.8 is suposed to last several years still
[11:44] Ubit Umarov : même Yengine peut avoir des problèmes.
[11:47] Ubit Umarov: problem is  mono
[11:45] Ubit Umarov : les opérations bitmap doivent être converties pour utiliser d'autres librairies externes, car elles ont été retirées de .net.
[11:47] Ubit Umarov: how it lost all devs
[11:46] Ubit Umarov : cela veut dire pas de map, pas de textures dynamiques, même pas de récupération de textures lludp que certains viewers utilisent toujours.
[11:48] Vincent.Sylvester @hg.zetaworlds.com:8002: Last commit two weeks ago it says
[11:46] Ubit Umarov : ann et pas de carte de sculpt.
[11:48] Vincent.Sylvester @hg.zetaworlds.com:8002: I mean thankfully is open source, but yeah
[11:47] Ubit Umarov : .net5 et 6 induisent une énorme rupture
[11:48] Gavin.Hird @grid.xmir.org:8002: also no usable 64-bit arm version of mono
[11:47] Ubit Umarov: et .net framework 4.8 est censé durer encore plusieurs années.
[11:48] Ubit Umarov: well no release since Feb last here
[11:47] Ubit Umarov : le problème, c'est mono
[11:48] Ubit Umarov: yeah no new things on mono
[11:47] Ubit Umarov : comment a t-il perdu tous les devs ?
[11:49] Ubit Umarov: ms will slow start killing it to "sell" dotnet
[11:48] Vincent.Sylvester @hg.zetaworlds.com:8002 : Le dernier commit date de deux semaines.
[11:49] Vincent.Sylvester @hg.zetaworlds.com:8002: It got so much traction 5 and 6 flew out the door quickly and then MS killed it by buying it
[11:48] Vincent.Sylvester @hg.zetaworlds.com:8002 : Je veux dire heureusement que c'est open source, mais ouais.
[11:49] Ubit Umarov: also ms does not care
[11:48] Gavin.Hird @grid.xmir.org:8002 : il n'y a pas non plus de version 64-bit arm de mono utilisable.
[11:49] Ubit Umarov: who does use linux and mono on the users universe?
[11:48] Ubit Umarov : pas de sortie depuis février dernier ici.
[11:49] Ubit Umarov: 0.001% of all users?
[11:48] Ubit Umarov : ouais, pas de nouvelles choses sur mono.
[11:50] Vincent.Sylvester @hg.zetaworlds.com:8002: Er that reminds me, Gavin, you saw the mantis on postgres not working, were you able to reproduce that?
[11:49] Ubit Umarov : ms va lentement commencer à le tuer pour "vendre" dotnet.
[11:50] Gavin.Hird @grid.xmir.org:8002: I did not see that
[11:49] Vincent.Sylvester @hg.zetaworlds.com:8002 : Il a eu tellement de succès que les versions 5 et 6 se sont envolées rapidement, puis MS l'a tué en le rachetant.
[11:51] Kayaker Magic: Lots of the commercial OpenSim grids use Linux/Mono. Lots of the mid-sized users (between grids and sim-on a stick) use Linux/Mono
[11:49] Ubit Umarov : aussi ms ne s'en soucie pas
[11:51] Vincent.Sylvester @hg.zetaworlds.com:8002: 8959 is the id iirc
[11:49] Ubit Umarov : qui utilise linux et mono dans l'univers des utilisateurs ?
[11:51] Gavin.Hird @grid.xmir.org:8002: postgres don't run on mono higher than 6.6.0.161
[11:49] Ubit Umarov : 0,001% de tous les utilisateurs ?
[11:52] Gavin.Hird @grid.xmir.org:8002: without a larger rewrite
[11:51] Kayaker Magic : Beaucoup de grilles commerciales d'OpenSim utilisent Linux/Mono. Beaucoup d'utilisateurs de taille moyenne (entre les grilles et les sim-on a stick) utilisent Linux/Mono.
[11:52] Ubit Umarov: yes and opensim users are like 0.000000001% of all users :p
[11:52] Ubit Umarov : oui et les utilisateurs d'opensim sont comme 0.000000001% de tous les utilisateurs :p
[11:52] Ubit Umarov: all ms users..
[11:52] Ubit Umarov : tous les utilisateurs de ms...
[11:52] Vincent.Sylvester @hg.zetaworlds.com:8002: Well I was able to get OpenSim to load with just one error by updating the Npgsql and supply two additional dlls to it
</pre>
[11:52] Vincent.Sylvester @hg.zetaworlds.com:8002: Though as Ubit pointed out those are a bad idea
 
[11:53] Gavin.Hird @grid.xmir.org:8002: you can get it to laod, but try logging in
= Problème avec PostgreSQL =
[11:53] Vincent.Sylvester @hg.zetaworlds.com:8002: Yeah there is an issue with user accounts parsing uuid field
*[https://fr.wikipedia.org/wiki/PostgreSQL PostgreSQL] : est un système de gestion de base de données relationnelle et objet (SGBDRO). C'est un outil libre disponible selon les termes d'une licence de type BSD.
[11:54] Vincent.Sylvester @hg.zetaworlds.com:8002: I'm not familiar with postgres so attempting to fix that....
* [http://opensimulator.org/mantis/view.php?id=8959  Mantis 0008959 : Postgresql ne se charge pas, quelque chose avec un certificatecallback]
[11:54] Gavin.Hird @grid.xmir.org:8002: as I said, a rather large rewrite
* [https://www.npgsql.org/ Npgsql]: Npgsql est un fournisseur de données ADO.NET open source pour PostgreSQL, il permet aux programmes écrits en C#, Visual Basic, F# d'accéder au serveur de base de données PostgreSQL. Il est implémenté en code 100% C#, est gratuit et open source.
[11:54] Ubit Umarov: our current Npgsql.dll fails to run on last stable mono??
* [https://www.nuget.org/packages/Npgsql/3.2.7 Npgsql 3.2.7]
[11:54] Gavin.Hird @grid.xmir.org:8002: yes
* [https://fr.wikipedia.org/wiki/NuGet NuGet] : gestionnaire de paquets de la plate forme de développement Microsoft .NET.
[11:54] Ubit Umarov whispers: why i  hell??
* [https://fr.wikipedia.org/wiki/Bloatware Bloatware]: désigne tantôt un logiciel utilisant une quantité excessive de ressources système, tantôt un logiciel accumulant une quantité importante de fonctionnalités disparates.
[11:54] Ubit Umarov: should not
* [https://pastebin.com/XDg6XaUi Pastbin de Vincent.Sylvester]
[11:55] Vincent.Sylvester @hg.zetaworlds.com:8002: You have to use version 3.2.7 of it and supply two additional dlls then it kinda works
* [https://fr.wiktionary.org/wiki/upsert upsert] : (Bases de données) Insertion dans une table, ou mise à jour de l'enregistrement s'il existe.
[11:55] Gavin.Hird @grid.xmir.org:8002: you have your work cut out in front of you ;-)
<pre>
[11:55] Gavin.Hird @grid.xmir.org:8002: except 3.2.7 is proably already unsupported too
[11:50] Vincent.Sylvester @hg.zetaworlds.com:8002 : Et ça me rappelle, Gavin, as-tu vu la mantis à propos de postgres qui ne fonctionnait pas, as-tu pu reproduire ça ?
[11:55] Ubit Umarov: vince that is changinf to a .net5 or standard lib
[11:50] Gavin.Hird @grid.xmir.org:8002 : Je n'ai pas vu cela
[11:55] Vincent.Sylvester @hg.zetaworlds.com:8002: Tell me about it I looked at the Npgsql source to remove the need for said dlls...
[11:51] Vincent.Sylvester @hg.zetaworlds.com:8002 : 8959 est l'identifiant si je me souviens bien.
[11:56] Vincent.Sylvester @hg.zetaworlds.com:8002: OpenSim has clean and well structured code in comparison
[11:51] Gavin.Hird @grid.xmir.org:8002 : postgres ne fonctionne pas sur les versions de mono supérieures à 6.6.0.161
[11:56] Ubit Umarov: possible can't anymore
[11:52] Gavin.Hird @grid.xmir.org:8002 : sans une réécriture plus importante
[11:56] Gavin.Hird @grid.xmir.org:8002: current supported versions are in the 4.high or even 5 versions
[11:52] Vincent.Sylvester @hg.zetaworlds.com:8002 : J'ai réussi à charger OpenSim avec une seule erreur en mettant à jour le Npgsql et en lui fournissant deux dlls supplémentaires.
[11:56] Vincent.Sylvester @hg.zetaworlds.com:8002: 4.1.9 is total nightmare, 8 dlls that wants
[11:52] Vincent.Sylvester @hg.zetaworlds.com:8002 : Bien que, comme Ubit l'a souligné, ce soit une mauvaise idée.
[11:56] Vincent.Sylvester @hg.zetaworlds.com:8002: All manners of random things
[11:53] Gavin.Hird @grid.xmir.org:8002 : tu peux le faire fonctionner, mais essaie de te connecter.
[11:56] Ubit Umarov: like all religion kids, possible they just blindly moved to .net5/6 and relatives
[11:53] Vincent.Sylvester @hg.zetaworlds.com:8002 : Oui, il y a un problème avec les comptes utilisateurs qui analysent le champ uuid.
[11:57] Gavin.Hird @grid.xmir.org:8002: nuget(?) install
[11:54] Vincent.Sylvester @hg.zetaworlds.com:8002 : Je ne suis pas familier avec postgres et j'essaie de résoudre ce problème. ....
[11:57] Vincent.Sylvester @hg.zetaworlds.com:8002: It's total bloatware, the latest version is 8 times the size of the one OpenSim uses
[11:54] Gavin.Hird @grid.xmir.org:8002 : comme je l'ai dit, c'est une réécriture assez importante.
[11:58] Ubit Umarov: vincent main software job is to force users to by more powerfull machines
[11:54] Ubit Umarov : notre Npgsql.dll actuelle ne fonctionne pas avec la dernière version stable de mono ?
[11:58] Vincent.Sylvester @hg.zetaworlds.com:8002: Space heaters
[11:54] Gavin.Hird @grid.xmir.org:8002 : Oui.
[11:58] Gavin.Hird @grid.xmir.org:8002: it actually does more like supporting new features in postgres 13 and 14
[11:54] Ubit Umarov murmure : pourquoi diable ??
[11:58] Ubit Umarov: ofc is is larger and needs more cpu to do the same.. that is what software is all abotu :p
[11:54] Ubit Umarov : ça ne devrait pas le faire
[11:55] Vincent.Sylvester @hg.zetaworlds.com:8002 : Il faut utiliser la version 3.2.7 et fournir deux dlls supplémentaires pour que ça marche un peu.
[11:55] Gavin.Hird @grid.xmir.org:8002 : vous avez du pain sur la planche ;-)
[11:55] Gavin.Hird @grid.xmir.org:8002 : sauf que la version 3.2.7 n'est probablement pas supportée non plus.
[11:55] Ubit Umarov : Vince, c'est le changement vers une librairie .net5 ou standard.
[11:55] Vincent.Sylvester @hg.zetaworlds.com:8002 : Dites-moi, j'ai regardé les sources de Npgsql pour supprimer le besoin de ces dlls...
[11:56] Vincent.Sylvester @hg.zetaworlds.com:8002 : OpenSim a un code propre et bien structuré en comparaison.
[11:56] Ubit Umarov: il se peut que ça ne soit pas possible.
[11:56] Gavin.Hird @grid.xmir.org:8002 : les versions actuellement supportées sont dans les versions 4.high ou même 5
[11:56] Vincent.Sylvester @hg.zetaworlds.com:8002 : 4.1.9 est un cauchemar total, 8 dlls réclamées...
[11:56] Vincent.Sylvester @hg.zetaworlds.com:8002 : Toutes sortes de choses aléatoires
[11:56] Ubit Umarov : comme tous les enfants de la religion, il est possible qu'ils soient passés aveuglément à .net5/6 avec leur famille.
[11:57] Gavin.Hird @grid.xmir.org:8002 : installation de nuget( ?)
[11:57] Vincent.Sylvester @hg.zetaworlds.com:8002 : C'est un bloatware total, la dernière version est 8 fois plus grande que celle utilisée par OpenSim.
[11:58] Ubit Umarov : le principal travail de Vincent est de forcer les utilisateurs à acheter des machines plus puissantes.
[11:58] Vincent.Sylvester @hg.zetaworlds.com:8002 : Chauffage de l'espace
[11:58] Gavin.Hird @grid.xmir.org:8002 : en fait, il s'agit plutôt de supporter les nouvelles fonctionnalités de postgres 13 et 14.
[11:58] Ubit Umarov : bien sûr, il est plus grand et nécessite plus de processeurs pour faire la même chose. c'est ce qu'est le logiciel :p
[11:59] Andrew Hellershanks: :)
[11:59] Andrew Hellershanks: :)
[11:59] Andrew Hellershanks: We are at the top of the hour.
[11:59] Andrew Hellershanks : Nous sommes au début de l'heure.
[12:00] Vincent.Sylvester @hg.zetaworlds.com:8002: If the postgres connector code was a bit easier to understand I might be inclined to try to fix that uuid error just bending over and embedding the two dlls in there, but I feel I will go down a rabbit hole of further errors down the line
[12:00] Vincent.Sylvester @hg.zetaworlds.com:8002 : Si le code du connecteur postgres était un peu plus facile à comprendre, je serais peut-être enclin à essayer de corriger cette erreur d'uuid en me penchant et en intégrant les deux dlls dans le code, mais je sens que je vais m'enfoncer dans un tunnel d'erreurs supplémentaires.
[12:00] Ubit Umarov: what uuid error?
[12:00] Ubit Umarov : quelle erreur d'uuid ?
[12:00] Andrew Hellershanks: One small bit of OpenSim news. The biggest change this past week was saving some nanoseconds by handling the checks for empty strings in a more efficient manner.
[12:00] Gavin.Hird @grid.xmir.org:8002 : il s'agit d'une erreur de conversion de type dans
[12:00] Gavin.Hird @grid.xmir.org:8002: it is a casting error in
[12:00] Gavin.Hird @grid.xmir.org:8002 : erreur de conversion de type avec libomv (ou ce qui est appelé)
[12:00] Gavin.Hird @grid.xmir.org:8002: casting error with libomv (or what it is called)
[12:01] Ubit Umarov : libomv n'a rien à voir avec pgsql
[12:01] Ubit Umarov: libomv has nothing to do with pgsql
[12:01] Gavin.Hird @grid.xmir.org:8002 : tu n'arrêtes pas de dire ça...
[12:01] Gavin.Hird @grid.xmir.org:8002: you keep saying that
[12:01] Gavin.Hird @grid.xmir.org:8002 : mais c'est le cas.
[12:01] Gavin.Hird @grid.xmir.org:8002: but it does
[12:01] Gavin.Hird @grid.xmir.org:8002 : il ne peut pas faire de cast.
[12:01] Gavin.Hird @grid.xmir.org:8002: it cannot do a cast
[12:01] Gavin.Hird @grid.xmir.org:8002 : avec l'uuid tel qu'il est implémenté dans libomv.
[12:01] Gavin.Hird @grid.xmir.org:8002: with uuid as it is implemented in libomv
[12:01] Ubit Umarov : alors le cast a besoin d'une solution de contournement.
[12:01] Ubit Umarov: wel then the cast needs a workaround
[12:02] Ubit Umarov : .?. a son propre uuid ?
[12:02] Ubit Umarov: ut has own uuid?
[12:02] Ubit Umarov : il est possible que les casts aient besoin de la spécification complète de l'espace de noms.
[12:02] Ubit Umarov: possible the casts need the full namespace spec
[12:02] Ubit Umarov : uuid est aussi un type natif de cette chose ?
[12:02] Ubit Umarov: uuid is also a native type of that hign?
[12:03] Ubit Umarov : ou c'est ms (Microsoft)  guid ?
[12:02] Ubit Umarov: thing?
[12:03] Ubit Umarov: or is it ms guid ?
[12:03] Vincent.Sylvester @hg.zetaworlds.com:8002: https://pastebin.com/XDg6XaUi
[12:03] Vincent.Sylvester @hg.zetaworlds.com:8002: https://pastebin.com/XDg6XaUi
[12:04] Vincent.Sylvester @hg.zetaworlds.com:8002: Error loading plugin OpenSim.Services.Interfaces.IUserAccountService from OpenSim.Services.UserAccountService.dll. Exception: Can't convert .NET type >
[12:04] Vincent.Sylvester @hg.zetaworlds.com:8002 : Erreur lors du chargement du plugin OpenSim.Services.Interfaces.IUserAccountService à partir de OpenSim.Services.UserAccountService.dll. Exception : Impossible de convertir le type .NET >
System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.InvalidCastException: Can't convert .NET type OpenMetaverse.UUID to PostgreSQL uu>
System.Reflection.TargetInvocationException : Une exception a été levée par la cible d'une invocation. ---> System.InvalidCastException : Impossible de convertir le type .NET OpenMetaverse.UUID en uu de PostgreSQL.
[12:04] Gavin.Hird @grid.xmir.org:8002: I think it has to do with ms guid, but O cannot recall exactly right now
[12:04] Gavin.Hird @grid.xmir.org:8002 : Je pense que ça a à voir avec le ms guid, mais je ne me souviens pas exactement pour le moment.
[12:04] Ubit Umarov: Can't convert .NET type OpenMetaverse.UUID to PostgreSQL uu
[12:04] Ubit Umarov : Impossible de convertir le type .NET OpenMetaverse.UUID en uu PostgreSQL.
[12:04] Ubit Umarov: uu ?
[12:04] Ubit Umarov: uu ?
[12:04] Vincent.Sylvester @hg.zetaworlds.com:8002: id
[12:04] Vincent.Sylvester @hg.zetaworlds.com:8002: id
[12:04] Gavin.Hird @grid.xmir.org:8002: uuid
[12:04] Gavin.Hird @grid.xmir.org:8002: uuid
[12:04] Ubit Umarov: it tells uu
[12:04] Ubit Umarov : il dit uu
[12:04] Ubit Umarov: :)
[12:04] Ubit Umarov : :)
[12:04] Gavin.Hird @grid.xmir.org:8002: uuid is native dataype in postgres
[12:04] Gavin.Hird @grid.xmir.org:8002 : uuid est le type de données natif de postgres.
[12:05] Ubit Umarov: ok then isolation is needed
[12:05] Ubit Umarov : ok alors un isolement est nécessaire.
[12:05] Ubit Umarov: one needs to have full namespace spec
[12:05] Ubit Umarov : il faut avoir une spécification complète de l'espace de noms.
[12:06] Ubit Umarov: why that is a issue with new mono and not older.. well.. no idea
[12:06] Ubit Umarov : pourquoi c'est un problème avec le nouveau mono et pas avec l'ancien... enfin... aucune idée.
[12:06] Gavin.Hird @grid.xmir.org:8002: deprecations
[12:06] Gavin.Hird @grid.xmir.org:8002 : déprecations
[12:06] Gavin.Hird @grid.xmir.org:8002: or actually removal of support in npgsql
[12:06] Gavin.Hird @grid.xmir.org:8002 : ou en fait la suppression du support dans npgsql.
[12:07] Gavin.Hird @grid.xmir.org:8002: but then BOOM - mono was not updated any more
[12:07] Gavin.Hird @grid.xmir.org:8002 : mais ensuite BOOM - mono n'était plus mis à jour.
[12:07] Ubit Umarov: PGSQLGenericTableHandler
[12:07] Ubit Umarov : PGSQLGenericTableHandler
[12:08] Ubit Umarov: well that is a "clever" to it all thing
[12:08] Ubit Umarov : Bon, c'est une chose "complexe" que tout cela.
[12:08] Ubit Umarov: not that simple do fix
[12:08] Ubit Umarov : ce n'est pas si simple à réparer.
[12:08] Gavin.Hird @grid.xmir.org:8002: actaully it is pretty dumb and needs to be rewriten
[12:08] Gavin.Hird @grid.xmir.org:8002 : en fait, c'est plutôt stupide et doit être réécrit.
[12:08] Gavin.Hird @grid.xmir.org:8002: it does not support upsert, so there are issues with some tables bacause of that
[12:08] Gavin.Hird @grid.xmir.org:8002 : il ne supporte pas l'upsert, il y a donc des problèmes avec certaines tables à cause de cela.
[12:09] Ubit Umarov: else if (m_Fields[name].GetValue(row) is UUID)
[12:09] Ubit Umarov: else if (m_Fields[name].GetValue(row) is UUID)
                         {
                         {
Ligne 257 : Ligne 287 :
                             UUID.TryParse(reader[name].ToString(), out uuid);
                             UUID.TryParse(reader[name].ToString(), out uuid);
                             m_Fields[name].SetValue(row, uuid);
                             m_Fields[name].SetValue(row, uuid);
[12:09] Ubit Umarov: guess m_Fields[name].GetValue(row) is UUID is other uuid
[12:09] Ubit Umarov : je suppose que m_Fields[name].GetValue(row) est UUID est un autre uuid.
[12:09] Vincent.Sylvester @hg.zetaworlds.com:8002: With mariadb getting uuid field type soon might be good to revisit the connectors in general is my thinking on this, squeeze some performance out of them perhaps :)
[12:09] Vincent.Sylvester @hg.zetaworlds.com:8002 : Avec mariadb qui disposera bientôt du type de champ uuid, il serait peut-être bon de revoir les connecteurs en général, c'est ce que je pense, pour en tirer quelques performances peut-être :)
[12:10] Ubit Umarov : alors le code passe via string pour être converti en openmetaverse :)
[12:10] Ubit Umarov: then code goes via string to convert it to openmetaverse :)
[12:10] Ubit Umarov: then code goes via string to convert it to openmetaverse :)
[12:10] Ubit Umarov: uuid on opensim and dbs is a mess
[12:10] Ubit Umarov : l'uuid sur opensim et les bases de données forment un gros  foutoir.
[12:10] Ubit Umarov: some are just done as string
[12:10] Ubit Umarov: certains sont simplement utilisés comme des  chaînes de caractères.
[12:10] Jamie.Jordan @grid.kitely.com:8002: Have a great week yall
[12:10] Jamie.Jordan @grid.kitely.com:8002 : Bonne semaine à tous
[12:11] Ubit Umarov: and not just on the db.. even on main opensim code
[12:11] Ubit Umarov : et pas seulement sur la base de données, même sur le code principal d'opensim.
[12:11] Andrew Hellershanks: ok, Jamie. You too. Thanks for dropping by
[12:11] Andrew Hellershanks : ok, Jamie. Toi aussi. Merci d'être passé.
[12:11] Ubit Umarov: and worse
[12:11] Ubit Umarov : et pire encore...
[12:11] Gavin.Hird @grid.xmir.org:8002: the postgres tables are partly native uuid and partly varchar
[12:11] Gavin.Hird @grid.xmir.org:8002 : les tables postgres sont en partie des uuid natifs et en partie des varchar.
[12:11] Ubit Umarov: some where born as uuid and now have more things
[12:11] Ubit Umarov : certaines sont apparues en tant que uuid et ont maintenant plus de choses.
[12:11] Ubit Umarov: like the uui
[12:11] Ubit Umarov : comme l'uui
[12:11] Ubit Umarov: ie  uuid+ gridhost etc
[12:11] Ubit Umarov : c'est à dire uuid+ gridhost etc...
[12:12] Andrew Hellershanks: Right.
[12:12] Andrew Hellershanks : Exact.
[12:12] Gavin.Hird @grid.xmir.org:8002: Griduser UserID is also a gem
[12:12] Gavin.Hird @grid.xmir.org:8002 : Griduser UserID est aussi une gemme.
[12:13] Ubit Umarov: hard to fix that mess now
[12:13] Ubit Umarov : difficile de réparer ce désordre maintenant.
[12:13] Ubit Umarov: it is on a lot of places
[12:13] Ubit Umarov : il est présent à beaucoup d'endroits.
[12:13] Gavin.Hird @grid.xmir.org:8002: :-)
[12:13] Gavin.Hird @grid.xmir.org:8002 : :-)
[12:14] Ubit Umarov: so use of dbs native uuid is not that great
[12:14] Ubit Umarov : donc l'utilisation de l'uuid natif de la base de données n'est pas très utile.
[12:14] Ubit Umarov: and on same that natice is just a 36 chars string and with the useless '-'
[12:14] Ubit Umarov : et en même temps ce natif est juste une chaîne de 36 caractères avec le '-' inutile.
[12:14] Ubit Umarov: that native..
[12:15] Gavin.Hird @grid.xmir.org:8002 : le natif supporte en fait 3 implémentations différentes de l'uuid.
[12:15] Gavin.Hird @grid.xmir.org:8002: the native actually support 3 different implementations of uuid
[12:17] Gavin.Hird @grid.xmir.org:8002 : PostgreSQL accepte également les formes alternatives suivantes pour la saisie : utilisation de chiffres en majuscules, format standard entouré d'accolades, omission de certains ou de tous les traits d'union, ajout d'un trait d'union après tout groupe de quatre chiffres.
[12:17] Gavin.Hird @grid.xmir.org:8002: PostgreSQL also accepts the following alternative forms for input: use of upper-case digits, the standard format surrounded by braces, omitting some or all hyphens, adding a hyphen after any group of four digits.
[12:19] Gavin.Hird @grid.xmir.org:8002 : PostgreSQL fournit des fonctions de stockage et de comparaison pour les UUIDs, mais la base de données de base n'inclut aucune fonction pour générer des UUIDs, parce qu'aucun algorithme unique n'est bien adapté à chaque application.
[12:19] Gavin.Hird @grid.xmir.org:8002: PostgreSQL provides storage and comparison functions for UUIDs, but the core database does not include any function for generating UUIDs, because no single algorithm is well suited for every application
[12:20] Ubit Umarov : je ne sais pas si le crash nécessite un débogage pour trouver où se trouve le mélange de types.
[12:20] Ubit Umarov: well no idea that crash needs some debug to find where is the types mix
[12:21] Ubit Umarov: cmd.Parameters.Add(m_database.CreateParameter(fields[i], keys[i], m_FieldTypes[fields[i]]));
[12:21] Ubit Umarov: cmd.Parameters.Add(m_database.CreateParameter(fields[i], keys[i], m_FieldTypes[fields[i]]));
[12:21] Ubit Umarov: guess here
[12:21] Ubit Umarov: je devine que ça se passe là.
[12:22] Ubit Umarov: yeha guess it is there
[12:22] Ubit Umarov : Ouais, je suppose que c'est là.
[12:27] Andrew Hellershanks: Almost half past the hour. Any last minute items for today?
</pre>
[12:28] Gavin.Hird @grid.xmir.org:8002: got the macOS version of the viewer building on the latest Xcode. Now the Intel version also compiles on an Apple Silicon machine
 
[12:29] Andrew Hellershanks: Sounds good, Gavin.
=Une petite nouvelle d'OpenSim=
[12:29] Gavin.Hird @grid.xmir.org:8002: it compiled faster than on any of the Intel kit I have
<pre>
[12:00] Andrew Hellershanks : Une petite nouvelle d'OpenSim. Le plus gros changement de la semaine dernière a été de gagner quelques nanosecondes en gérant les vérifications des chaînes vides de manière plus efficace.
</pre>
 
= Conclusion=
<pre>
[12:27] Andrew Hellershanks : Il est presque l'heure et demie. Des questions de dernière minute pour aujourd'hui ?
[12:28] Gavin.Hird @grid.xmir.org:8002 : j'ai réussi à compiler la version macOS du viewer avec le dernier Xcode. Maintenant la version Intel compile aussi sur une machine Apple Silicon.
[12:29] Andrew Hellershanks : C'est bien, Gavin.
[12:29] Gavin.Hird @grid.xmir.org:8002 : La compilation est plus rapide que sur n'importe quel kit Intel que j'ai.
[12:29] Andrew Hellershanks: :)
[12:29] Andrew Hellershanks: :)
[12:30] Andrew Hellershanks: Time to wrap the meeting for today.
[12:30] Andrew Hellershanks : Il est temps de conclure la réunion d'aujourd'hui.
[12:30] Gavin.Hird @grid.xmir.org:8002: warp
[12:30] Gavin.Hird @grid.xmir.org:8002 : warp
[12:30] Kayaker Magic: Yup, I need to run.
[12:30] Kayaker Magic : Oui, je dois courir.
[12:30] Andrew Hellershanks: Good luck with your work on Postgres issues. Postgres support doesn't see a lot of love.
[12:30] Andrew Hellershanks : Bonne chance avec votre travail sur les problèmes de Postgres. Le support Postgres ne bénéficie pas de beaucoup d'amour.
[12:30] Kayaker Magic: bye all!
[12:30] Kayaker Magic : au revoir à tous !
[12:30] Andrew Hellershanks: Thank you all for coming. See you again next week.
[12:30] Andrew Hellershanks : Merci à tous d'être venus. Nous vous reverrons la semaine prochaine.
</pre>
</pre>

Dernière version du 19 janvier 2022 à 16:29

Source : http://opensimulator.org/wiki/Chat_log_from_the_meeting_on_2022-01-18

Introduction

[11:01] Gavin.Hird @grid.xmir.org:8002 : Salut Andrew
[11:01] Andrew Hellershanks : Bonjour, tout le monde.
[11:02] Ubit Umarov : Oh, voici M. Andrew White Hellershanks.
[11:02] Andrew Hellershanks : Blanc est mon deuxième prénom ;)
[11:02] Gavin.Hird @grid.xmir.org:8002 : l'hiver est pâle.
[11:02] Ubit Umarov : la nourriture et les boissons sont si vieilles ici.
[11:02] Selby.Evans @grid.kitely.com:8002 : bonjour à tous.
[11:02] Andrew Hellershanks : J'essaie de me fondre dans le décor avec les 30 cm de neige que nous avons dehors.
[11:02] Ubit Umarov : et le pari est venu de régions encore plus anciennes.
[11:03] Jamie.Jordan @grid.kitely.com:8002 : Salut Selby
[11:03] Ubit Umarov : oh ? il n'y a pas de neige ici.
[11:03] Gavin.Hird @grid.xmir.org:8002 : C'est vrai, Ubit - la dégradation de la nourriture n'est pas une bonne chose.
[11:03] Ubit Umarov : Il se peut que Gavin ait un bot de plus en neige.
[11:03] Gavin.Hird @grid.xmir.org:8002: pas god
[11:03] Gavin.Hird @grid.xmir.org:8002: good*
 [11:03] Ubit Umarov : ou un peu plus..
[11:03] Gavin.Hird @grid.xmir.org:8002 : Gavin a 0 mm de couverture neigeuse
[11:04] Ubit Umarov : ok il semble que nous ayons un problème de fautes de frappe :)
[11:04] Gavin.Hird @grid.xmir.org:8002 : 5°C de trop

Bogue du cache des objets

Aurora: projet dérivé d'OpenSim qui met l'accent sur l'assistance à tous les utilisateur. 

[11:04] Vincent.Sylvester @hg.zetaworlds.com:8002 : Gavin as-tu vu la correction du bug du cache d'objet ?
[11:04] Gavin.Hird @grid.xmir.org:8002 : Je l'ai compilé
[11:04] Gavin.Hird @grid.xmir.org:8002 : donc d'un jour à l'autre.
[11:04] Gavin.Hird @grid.xmir.org:8002: :-)
[11:04] Vincent.Sylvester @hg.zetaworlds.com:8002 : Super !
[11:05] Gavin.Hird @grid.xmir.org:8002 : peut-être vendredi.
[11:05] Ubit Umarov : rappelez-vous que sur opensim une prim est retenue pour le cache que  15mins après le dernier changement/rez.
[11:05] Ubit Umarov : sur SL c'est moins de 5 minutes.
[11:05] Ubit Umarov : avant c'était 1 heure ici...
[11:05] Ubit Umarov : c'est 1 heure sur les anciennes versions.
[11:06] Ubit Umarov : il vaut mieux recharger quelques prims au cas où vous auriez besoin d'en tester plusieurs et attendre 15 minutes.
[11:06] Vincent.Sylvester @hg.zetaworlds.com:8002 : J'ai désactivé les caps sur certaines régions pour tester et j'ai du mal à voir ce que cela  fait en termes de performances. Bien sûr, les prims sont mises en cache pour qu'elles s'affichent plus rapidement, mais j'ai du mal à "voir" la différence.
[11:07] Ubit Umarov : Ohh c'est énorme
[11:07] Ubit Umarov : au retour dans une région
[11:07] Vincent.Sylvester @hg.zetaworlds.com:8002 : Je n'en doute pas, surtout si la connexion est plus lente, etc.
[11:07] Ubit Umarov : très visible.
[11:08] Ubit Umarov : Bien sûr, de temps en temps Firestorm s'étrangle en rezzant les prims.
[11:08] Ubit Umarov : et de temps en temps, aucune idée pourquoi, certaines restent trasparentes jusqu'à ce qu'elles soient touchées.
[11:09] Vincent.Sylvester @hg.zetaworlds.com:8002 : Peut-être que le test sur les varegions  avec 50000 objets le remplit probablement ou quelque chose comme ça, en fait la taille du cache par défaut n'est pas très grande.
[11:09] Ubit Umarov : le tri des objets par la distance est aussi réalisé côté du viewer.
[11:09] Ubit Umarov : ( où le bug était.. )
[11:10] Vincent.Sylvester @hg.zetaworlds.com:8002 : Je m'attendais probablement à ce que ce soit plus comme à l'époque où il fallait attendre une demi-heure pour qu'une région se charge complètement ou quelque chose comme ça avec le cache désactivé.
[11:10] Ubit Umarov : c'est un mauvais point du cache d'objet.
[11:10] Ubit Umarov : le viewer veut avoir toutes les prims d'une région au départ.
[11:11] Gavin.Hird @grid.xmir.org:8002 : si ce n'est pas le cas, le tri sera plutôt aléatoire.
[11:11] Ubit Umarov : j'ai fait un peu de travail sur la sélection côté serveur même en plus de cela.
[11:11] Ubit Umarov : l'option est là.
[11:11] Ubit Umarov : mais c'est lourd et je n'ai pas fini.
[11:11] Ubit Umarov : SL n'a jamais envisagé de régions avec 120K prims.
[11:12] Ubit Umarov : mais d'un autre côté opensim n'a jamais fait de filtrage comme le faisaient les régions SL.
[11:12] Ubit Umarov : donc... même chose
[11:12] Vincent.Sylvester @hg.zetaworlds.com:8002 : Je commençais à perdre la raison en pensant que c'était une obscure perte de paquets quelque part ou quelque chose comme ça.
[11:12] Gavin.Hird @grid.xmir.org:8002 : ils préfèrent avoir 1000 prims(meshes) avec 3 millions de tests chacun pour faire face à la situation.
[11:13] Vincent.Sylvester @hg.zetaworlds.com:8002 : Cela va jusqu'à LL et ensuite c'est un code vieux d'une demi-décennie, c'est juste comique, la cerise sur le gâteau.
[11:13] Ubit Umarov : Aurora a fait de la sélection.
[11:13] Ubit Umarov : mais aussi lourd
[11:14] Ubit Umarov : listes d'intérêt par utilisateur... regardées tout le temps...

Plusieurs formats d'encodages dans une vielle archive

  • [[OpenSim_Archives/fr |OAR - Archives OpenSim]
  • UTF-8 --UTF-16
  • BOM = Bakes on Mesh (moulage sur le maillage) :fonctionnalité qui permet d'afficher les textures de l'avatar du système sur des pièces jointes en meshes.
  • Grille InWorldz (voir Halcyon)
[11:14] Vincent.Sylvester @hg.zetaworlds.com:8002 : En parlant de prims, j'ai creusé un peu aujourd'hui et j'ai trouvé un viel objet lié avec un encodage xml utf 16 suivi de données utf 8.
[11:15] Vincent.Sylvester @hg.zetaworlds.com:8002 : C'est basé sur l'idée que je dois simplement ignorer que c'est un mauvais formatage ?
[11:16] Andrew Hellershanks : Cela semble étrange qu'il y ait deux encodages de chaînes différents.
[11:16] Gavin.Hird @grid.xmir.org:8002 : peut-être écrit et mis à jour par deux personnes différentes.
[11:16] Andrew Hellershanks : C'est possible.
[11:17] Vincent.Sylvester @hg.zetaworlds.com:8002 : Il manque aussi un tas de paramètres dans le xml comme le système de particules et d'autres choses.
[11:17] Ubit Umarov : xml est une merde
[11:17] Gavin.Hird @grid.xmir.org:8002: est-ce que la chose se rezze ?
[11:17] Ubit Umarov : et l'utilisation d'opensim n'a pas été la meilleure.
[11:18] Ubit Umarov : aussi la documentation de MS est confuse.
[11:18] Ubit Umarov : donc... ouais l'utf-16 a pu apparaître dans les OARs
[11:18] Ubit Umarov : au moins sur la première ligne.
[11:18] Ubit Umarov : alors qu'en réalité les données étaient en utf-8
[11:19] Vincent.Sylvester @hg.zetaworlds.com:8002:  Je n'ai pas essayé, j'ai juste trouvé les données d'assets marquées comme malformées par le parseur xml. En regardant le xml de l'OAR lui-même on voit la déclaration d'un encodage utf16 dans le paramètre de l'en-tête,  mais les parties xml disent toutes utf8,  une double structure bizarre là-dedans.
[11:19] Ubit Umarov : l'utilisation de la BoM n'est pas non plus très claire.
[11:19] Vincent.Sylvester @hg.zetaworlds.com:8002 : Cela devrait être un élément de l'inventaire donc je pourrais le trouver et le "rezzer". 
[11:19] Gavin.Hird @grid.xmir.org:8002 : structure double - comme l'ADN ?
[11:20] Vincent.Sylvester @hg.zetaworlds.com:8002 : Eh bien, comme une balise xml ouverte et fermée autour d'un tas d'autres pour chaque partie du lien.
[11:20] Ubit Umarov : il est possible que plusieurs formats OAR existent maintenant.
[11:20] Ubit Umarov : je pense que Inworldz avait sa propre variante ?
[11:20] Vincent.Sylvester @hg.zetaworlds.com:8002 : Le créateur original vient d'osgrid, à l'époque où cet autre système de profils était utilisé.
[11:21] Ubit Umarov : je pense que le utf-16 de la ligne d'en-tête est ignoré s'il y a une BOM.
[11:22] Vincent.Sylvester @hg.zetaworlds.com:8002: En forçant l'encodage utf8, il a été parsé correctement, donc au moins le reste semble correct.
[11:22] Vincent.Sylvester @hg.zetaworlds.com:8002 : Je suis surpris qu'il fonctionne probablement comme un asset dans OpenSim dans cet état.
[11:23] Ubit Umarov : je suppose que l'utf16 est toujours là même dans les nouveaux OARs.
[11:23] Ubit Umarov : laisse-moi vérifier (xee pour see dans la version originale).
[11:23] Vincent.Sylvester @hg.zetaworlds.com:8002 : Il y a certainement quelques structures de données farfelues dans OpenSim.
[11:24] Vincent.Sylvester @hg.zetaworlds.com:8002 : Je me souviens que le décodage des données du blob de parcel était un voyage amusant au pays des bits et des octets.
[11:24] Gavin.Hird @grid.xmir.org:8002 : xee - est-ce un nouveau mot clé xml ?
[11:24] Ubit Umarov: <SceneObjectGroup><SceneObjectPart xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
[11:24] Ubit Umarov : Je ne sais pas pourquoi nous avons ce xsi.
[11:25] Ubit Umarov: <?xml version="1.0" encoding="utf-16"?>
<RegionSettings>
[11:26] Ubit Umarov: <?xml version="1.0" encoding="utf-16"?>
<archive major_version="0" minor_version="8">
[11:26] Ubit Umarov : Eh bien, c'était cassé depuis le début.
[11:26] Vincent.Sylvester @hg.zetaworlds.com:8002 : Le truc, c'est que les données qu'il contient sont probablement utf8, parce que la plupart d'entre elles le sont maintenant.
[11:26] Ubit Umarov : on ne peut pas changer maintenant
[11:26] Ubit Umarov : utf-16 est un code stupide.
[11:26] Ubit Umarov : mais Windows et Linux l'ont adopté.
[11:27] Ubit Umarov : comme beaucoup d'adopteurs précoces de l'unicode.
[11:27] Ubit Umarov : à un moment donné, utf-16 était l'unicode complet.
[11:27] Ubit Umarov : l'unicode était si intelligent qu'il a décidé que 16bits étaient tout ce dont il avait besoin.
[11:28] Andrew Hellershanks : Ouaip. 64k devrait être suffisant pour tout le monde :)
[11:28] Ubit Umarov : ouais quand ils sont présents tous les en-têtes xml disent utf8
[11:28] Ubit Umarov : opoe utf-16
[11:28] Ubit Umarov : hmm laissez-moi vérifier dans un fichier en binaire.
[11:29] Vincent.Sylvester @hg.zetaworlds.com:8002 : lxml.etree.XMLSyntaxError : Document étiqueté UTF-16 mais dont le contenu est UTF-8, ligne 1, colonne 38.
[11:30] Vincent.Sylvester @hg.zetaworlds.com:8002 : Heureusement, on peut toujours lui dire de forcer utf8 dans ce cas.
[11:31] Ubit Umarov : le fichier est utf8
[11:31] Vincent.Sylvester @hg.zetaworlds.com:8002 : C'est vraiment étrange car il manquait aussi les paramètres normaux pour les prims, j'aurais imaginé qu'ils seraient éventuellement ajoutés lors du rechargement de l'asset via une archive, mais cela ne semble pas être le cas non plus.
[11:31] Ubit Umarov : en fait ascii
[11:31] Ubit Umarov : un octet par caractère
[11:31] Ubit Umarov : et pas de BOM
[11:32] Ubit Umarov : aucune idée de comment cela fonctionne LOL
[11:32] Ubit Umarov : MS XML de merde
[11:32] Ubit Umarov: 3c 3f 78 6d 6c 20 76 65 72 73 69 6f 6e 3d 22 31 2e 30 22 20 65 6e 63 6f 64 69 6e 67 3d 22 75 74 66 2d 31 36 22 3f 3e 0d 0a 3c 61 72 63 68 69 76 65 20 6d 61 6a 6f 72 5f 76 65 72 73 69 6f 6e 3d
[11:32] Vincent.Sylvester @hg.zetaworlds.com:8002 : J'imagine que si une structure correcte était appliquée, la moitié des choses dans le monde ne seraient plus chargées.
[11:32] Ubit Umarov : vous voyez ? un simple ascii ordinaire.
[11:34] Ubit Umarov : je suppose qu'en lecture nous forçons utf8.
[11:34] Vincent.Sylvester @hg.zetaworlds.com:8002 : Je m'en doutais puisque l'analyseur syntaxique a dit que tout était en utf8 de toute façon.
[11:35] Vincent.Sylvester @hg.zetaworlds.com:8002 : J'ai été bloqué sur quelque chose d'autre après ça, mais c'est une autre histoire pour une autre fois.
[11:35] Ubit Umarov : utf-16 a aussi des problèmes d'ordre de bit lol
[11:35] Ubit Umarov : ordre des octets
[11:36] Ubit Umarov : le xml est un protocole si bien fait.
[11:36] Ubit Umarov : pour une merde faite sur des genoux

Blocage de threads , bogue dans Mono

  • VScode: Visual Studio Code est un éditeur de code extensible développé par Microsoft pour Windows, Linux et macOS
[11:36] Vincent.Sylvester @hg.zetaworlds.com:8002 : J'ai créé plus de modules ces derniers temps et j'ai constaté que le redoutable thread bloqué à l'arrêt s'aggrave avec l'ajout de modules.
[11:37] Andrew Hellershanks : Je pensais que ce problème avait disparu avec la 0.9.
[11:37] Vincent.Sylvester @hg.zetaworlds.com:8002 : Je le pensais aussi
[11:37] Vincent.Sylvester @hg.zetaworlds.com:8002: Il semblerait que l'origine de cela vienne de l'utilisation ou les données contenues dans ces threads.
[11:37] Vincent.Sylvester @hg.zetaworlds.com:8002 : Étant donné que j'ajoute les modules qui mettent beaucoup de données dans le système, ils ont tendance à avoir le plus d'impact.
[11:38] Vincent.Sylvester @hg.zetaworlds.com:8002 : Donc, je me demande si l'origine de cela ne serait pas une fuite de mémoire ou d'autres données orphelines qui ne parviennent pas à être effacées.
[11:38] Vincent.Sylvester @hg.zetaworlds.com:8002 : Surtout quand je fais beaucoup de tests avec les modules, ce qui entraîne plus d'allers-retours de données.
[11:39] Vincent.Sylvester @hg.zetaworlds.com:8002 : Sur master, je vois encore du rouge pendant l'arrêt des threads aléatoires qui ne s'arrêtent pas proprement, mais seulement sur Mono.
[11:40] Vincent.Sylvester @hg.zetaworlds.com:8002 : sous Windows .net, je fais des tests dans vscode et tout fonctionne parfaitement.
[11:40] Ubit Umarov : mono a des problèmes sur l'arrêt des threads.
[11:40] Ubit Umarov : et les laisse se bloquer sur certaines choses.
[11:41] Ubit Umarov: de la même façon, on ne peut même pas  les tuer comme il le faudrait, alors ils restent bloqués
[11:41] Jagga Meredith whispers: -[[[[[[[[[
[11:42] Vincent.Sylvester @hg.zetaworlds.com:8002 : On peut toujours vérifier si le simulateur répond aux "pings" et le faire disparaître , mais bien sûr, ce n'est pas l'idéal non plus...
[11:43] Andrew Hellershanks : Vincent, pour faire cela correctement, il faut plus d'un ping et suffisamment de temps entre eux pour permettre à l'instance de sauvegarder les données primaires dans la base de données afin qu'elle ne soit pas tuée alors qu'elle est encore en train de s'éteindre.

Mort de Mono ?

[11:42] Vincent.Sylvester @hg.zetaworlds.com:8002 : Je suis surpris que le bogue soit toujours dans mono après tout ce temps.
[11:42] Vincent.Sylvester @hg.zetaworlds.com:8002 : Je suppose que nous ne sommes pas les seuls à le voir.
[11:42] Gavin.Hird @grid.xmir.org:8002 : mono n'est plus mis à jour.
[11:42] Ubit Umarov : eh bien, mono est maintenant mort.
[11:42] Gavin.Hird @grid.xmir.org:8002 : oui.
[11:42] Ubit Umarov : sur sa pente descendante
[11:43] Ubit Umarov : MS a fait tout le developpement dont il a besoin pour cannibaliser certaines parties de dotnet.
[11:43] Ubit Umarov : maintenant... fondamentalement mort.
[11:43] Kayaker Magic : où en est la progression de mono's dotnet sur Linux ?
[11:43] Ubit Umarov : aucune mise à jour depuis presque un an.
[11:43] Ubit Umarov : qui s'en soucie...
[11:44] Ubit Umarov : opensim est un gros problème à convertir en dotnet.
[11:44] Ubit Umarov : nous allons perdre quelques fonctionnalités.
[11:44] Ubit Umarov : Xengine en est une
[11:44] Ubit Umarov : même Yengine peut avoir des problèmes.
[11:45] Ubit Umarov : les opérations bitmap doivent être converties pour utiliser d'autres librairies externes, car elles ont été retirées de .net.
[11:46] Ubit Umarov : cela veut dire pas de map, pas de textures dynamiques, même pas de récupération de textures lludp que certains viewers utilisent toujours.
[11:46] Ubit Umarov : ann et pas de carte de sculpt.
[11:47] Ubit Umarov : .net5 et 6 induisent une énorme rupture
[11:47] Ubit Umarov: et .net framework 4.8 est censé durer encore plusieurs années.
[11:47] Ubit Umarov : le problème, c'est mono
[11:47] Ubit Umarov : comment a t-il perdu tous les devs ?
[11:48] Vincent.Sylvester @hg.zetaworlds.com:8002 : Le dernier commit date de deux semaines.
[11:48] Vincent.Sylvester @hg.zetaworlds.com:8002 : Je veux dire heureusement que c'est open source, mais ouais.
[11:48] Gavin.Hird @grid.xmir.org:8002 : il n'y a pas non plus de version 64-bit arm de mono utilisable.
[11:48] Ubit Umarov : pas de sortie depuis février dernier ici.
[11:48] Ubit Umarov : ouais, pas de nouvelles choses sur mono.
[11:49] Ubit Umarov : ms va lentement commencer à le tuer pour "vendre" dotnet.
[11:49] Vincent.Sylvester @hg.zetaworlds.com:8002 : Il a eu tellement de succès que les versions 5 et 6 se sont envolées rapidement, puis MS l'a tué en le rachetant.
[11:49] Ubit Umarov : aussi ms ne s'en soucie pas
[11:49] Ubit Umarov : qui utilise linux et mono dans l'univers des utilisateurs ?
[11:49] Ubit Umarov : 0,001% de tous les utilisateurs ?
[11:51] Kayaker Magic : Beaucoup de grilles commerciales d'OpenSim utilisent Linux/Mono. Beaucoup d'utilisateurs de taille moyenne (entre les grilles et les sim-on a stick) utilisent Linux/Mono.
[11:52] Ubit Umarov : oui et les utilisateurs d'opensim sont comme 0.000000001% de tous les utilisateurs :p
[11:52] Ubit Umarov : tous les utilisateurs de ms...

Problème avec PostgreSQL

  • PostgreSQL : est un système de gestion de base de données relationnelle et objet (SGBDRO). C'est un outil libre disponible selon les termes d'une licence de type BSD.
  • Mantis 0008959 : Postgresql ne se charge pas, quelque chose avec un certificatecallback
  • Npgsql: Npgsql est un fournisseur de données ADO.NET open source pour PostgreSQL, il permet aux programmes écrits en C#, Visual Basic, F# d'accéder au serveur de base de données PostgreSQL. Il est implémenté en code 100% C#, est gratuit et open source.
  • Npgsql 3.2.7
  • NuGet : gestionnaire de paquets de la plate forme de développement Microsoft .NET.
  • Bloatware: désigne tantôt un logiciel utilisant une quantité excessive de ressources système, tantôt un logiciel accumulant une quantité importante de fonctionnalités disparates.
  • Pastbin de Vincent.Sylvester
  • upsert : (Bases de données) Insertion dans une table, ou mise à jour de l'enregistrement s'il existe.
[11:50] Vincent.Sylvester @hg.zetaworlds.com:8002 : Et ça me rappelle, Gavin, as-tu vu la mantis à propos de postgres  qui ne fonctionnait pas, as-tu pu reproduire ça ?
[11:50] Gavin.Hird @grid.xmir.org:8002 : Je n'ai pas vu cela
[11:51] Vincent.Sylvester @hg.zetaworlds.com:8002 : 8959 est l'identifiant si je me souviens bien.
[11:51] Gavin.Hird @grid.xmir.org:8002 : postgres ne fonctionne pas sur les versions de mono supérieures à 6.6.0.161
[11:52] Gavin.Hird @grid.xmir.org:8002 : sans une réécriture plus importante
[11:52] Vincent.Sylvester @hg.zetaworlds.com:8002 : J'ai réussi à charger OpenSim avec une seule erreur en mettant à jour le Npgsql et en lui fournissant deux dlls supplémentaires.
[11:52] Vincent.Sylvester @hg.zetaworlds.com:8002 : Bien que, comme Ubit l'a souligné, ce soit une mauvaise idée.
[11:53] Gavin.Hird @grid.xmir.org:8002 : tu peux le faire fonctionner, mais essaie de te connecter.
[11:53] Vincent.Sylvester @hg.zetaworlds.com:8002 : Oui, il y a un problème avec les comptes utilisateurs qui analysent le champ uuid.
[11:54] Vincent.Sylvester @hg.zetaworlds.com:8002 : Je ne suis pas familier avec postgres et j'essaie de résoudre ce problème. ....
[11:54] Gavin.Hird @grid.xmir.org:8002 : comme je l'ai dit, c'est une réécriture assez importante.
[11:54] Ubit Umarov : notre Npgsql.dll actuelle ne fonctionne pas avec la dernière version stable de mono ?
[11:54] Gavin.Hird @grid.xmir.org:8002 : Oui.
[11:54] Ubit Umarov murmure : pourquoi diable ??
[11:54] Ubit Umarov : ça ne devrait pas le faire
[11:55] Vincent.Sylvester @hg.zetaworlds.com:8002 : Il faut utiliser la version 3.2.7 et fournir deux dlls supplémentaires pour que ça marche un peu.
[11:55] Gavin.Hird @grid.xmir.org:8002 : vous avez du pain sur la planche ;-)
[11:55] Gavin.Hird @grid.xmir.org:8002 : sauf que la version 3.2.7 n'est probablement pas supportée non plus.
[11:55] Ubit Umarov : Vince, c'est le changement vers une librairie .net5 ou standard.
[11:55] Vincent.Sylvester @hg.zetaworlds.com:8002 : Dites-moi, j'ai regardé les sources de Npgsql pour supprimer le besoin de ces dlls...
[11:56] Vincent.Sylvester @hg.zetaworlds.com:8002 : OpenSim a un code propre et bien structuré en comparaison.
[11:56] Ubit Umarov: il se peut que ça ne soit pas possible.
[11:56] Gavin.Hird @grid.xmir.org:8002 : les versions actuellement supportées sont dans les versions 4.high ou même 5
[11:56] Vincent.Sylvester @hg.zetaworlds.com:8002 : 4.1.9 est un cauchemar total, 8 dlls réclamées...
[11:56] Vincent.Sylvester @hg.zetaworlds.com:8002 : Toutes sortes de choses aléatoires
[11:56] Ubit Umarov : comme tous les enfants de la religion, il est possible qu'ils soient passés aveuglément à .net5/6 avec leur famille.
[11:57] Gavin.Hird @grid.xmir.org:8002 : installation de nuget( ?)
[11:57] Vincent.Sylvester @hg.zetaworlds.com:8002 : C'est un bloatware total, la dernière version est 8 fois plus grande que celle utilisée par OpenSim.
[11:58] Ubit Umarov : le principal travail de Vincent est de forcer les utilisateurs à acheter des machines plus puissantes.
[11:58] Vincent.Sylvester @hg.zetaworlds.com:8002 : Chauffage de l'espace
[11:58] Gavin.Hird @grid.xmir.org:8002 : en fait, il s'agit plutôt de supporter les nouvelles fonctionnalités de postgres 13 et 14.
[11:58] Ubit Umarov : bien sûr, il est plus grand et nécessite plus de processeurs pour faire la même chose. c'est ce qu'est le logiciel :p
[11:59] Andrew Hellershanks: :)
[11:59] Andrew Hellershanks : Nous sommes au début de l'heure.
[12:00] Vincent.Sylvester @hg.zetaworlds.com:8002 : Si le code du connecteur postgres était un peu plus facile à comprendre, je serais peut-être enclin à essayer de corriger cette erreur d'uuid en me penchant et en intégrant les deux dlls dans le code, mais je sens que je vais m'enfoncer dans un tunnel d'erreurs supplémentaires.
[12:00] Ubit Umarov : quelle erreur d'uuid ?
[12:00] Gavin.Hird @grid.xmir.org:8002 : il s'agit d'une erreur de conversion de type dans
[12:00] Gavin.Hird @grid.xmir.org:8002 : erreur de conversion de type avec libomv (ou ce qui est appelé)
[12:01] Ubit Umarov : libomv n'a rien à voir avec pgsql
[12:01] Gavin.Hird @grid.xmir.org:8002 : tu n'arrêtes pas de dire ça...
[12:01] Gavin.Hird @grid.xmir.org:8002 : mais c'est le cas.
[12:01] Gavin.Hird @grid.xmir.org:8002 : il ne peut pas faire de cast.
[12:01] Gavin.Hird @grid.xmir.org:8002 : avec l'uuid tel qu'il est implémenté dans libomv.
[12:01] Ubit Umarov : alors le cast a besoin d'une solution de contournement.
[12:02] Ubit Umarov : .?. a son propre uuid ?
[12:02] Ubit Umarov : il est possible que les casts aient besoin de la spécification complète de l'espace de noms.
[12:02] Ubit Umarov : uuid est aussi un type natif de cette chose ?
[12:03] Ubit Umarov : ou c'est ms (Microsoft)  guid ?
[12:03] Vincent.Sylvester @hg.zetaworlds.com:8002: https://pastebin.com/XDg6XaUi
[12:04] Vincent.Sylvester @hg.zetaworlds.com:8002 : Erreur lors du chargement du plugin OpenSim.Services.Interfaces.IUserAccountService à partir de OpenSim.Services.UserAccountService.dll. Exception : Impossible de convertir le type .NET >
System.Reflection.TargetInvocationException : Une exception a été levée par la cible d'une invocation. ---> System.InvalidCastException : Impossible de convertir le type .NET OpenMetaverse.UUID en uu de PostgreSQL.
[12:04] Gavin.Hird @grid.xmir.org:8002 : Je pense que ça a à voir avec le ms guid, mais je ne me souviens pas exactement pour le moment.
[12:04] Ubit Umarov : Impossible de convertir le type .NET OpenMetaverse.UUID en uu PostgreSQL.
[12:04] Ubit Umarov: uu ?
[12:04] Vincent.Sylvester @hg.zetaworlds.com:8002: id
[12:04] Gavin.Hird @grid.xmir.org:8002: uuid
[12:04] Ubit Umarov : il dit uu
[12:04] Ubit Umarov : :)
[12:04] Gavin.Hird @grid.xmir.org:8002 : uuid est le type de données natif de postgres.
[12:05] Ubit Umarov : ok alors un isolement est nécessaire.
[12:05] Ubit Umarov : il faut avoir une spécification complète de l'espace de noms.
[12:06] Ubit Umarov : pourquoi c'est un problème avec le nouveau mono et pas avec l'ancien... enfin... aucune idée.
[12:06] Gavin.Hird @grid.xmir.org:8002 : déprecations
[12:06] Gavin.Hird @grid.xmir.org:8002 : ou en fait la suppression du support dans npgsql.
[12:07] Gavin.Hird @grid.xmir.org:8002 : mais ensuite BOOM - mono n'était plus mis à jour.
[12:07] Ubit Umarov : PGSQLGenericTableHandler
[12:08] Ubit Umarov : Bon, c'est une chose "complexe" que tout cela.
[12:08] Ubit Umarov : ce n'est pas si simple à réparer.
[12:08] Gavin.Hird @grid.xmir.org:8002 : en fait, c'est plutôt stupide et doit être réécrit.
[12:08] Gavin.Hird @grid.xmir.org:8002 : il ne supporte pas l'upsert, il y a donc des problèmes avec certaines tables à cause de cela.
[12:09] Ubit Umarov: else if (m_Fields[name].GetValue(row) is UUID)
                        {
                            UUID uuid = UUID.Zero;

                            UUID.TryParse(reader[name].ToString(), out uuid);
                            m_Fields[name].SetValue(row, uuid);
[12:09] Ubit Umarov : je suppose que m_Fields[name].GetValue(row) est UUID est un autre uuid.
[12:09] Vincent.Sylvester @hg.zetaworlds.com:8002 : Avec mariadb qui disposera bientôt du type de champ uuid, il serait peut-être bon de revoir les connecteurs en général, c'est ce que je pense, pour en tirer quelques performances peut-être :)
[12:10] Ubit Umarov : alors le code passe via string pour être converti en openmetaverse :)
[12:10] Ubit Umarov: then code goes via string to convert it to openmetaverse :)
[12:10] Ubit Umarov : l'uuid sur opensim et les bases de données forment un gros  foutoir.
[12:10] Ubit Umarov: certains sont simplement utilisés comme des  chaînes de caractères.
[12:10] Jamie.Jordan @grid.kitely.com:8002 : Bonne semaine à tous
[12:11] Ubit Umarov : et pas seulement sur la base de données, même sur le code principal d'opensim.
[12:11] Andrew Hellershanks : ok, Jamie. Toi aussi. Merci d'être passé.
[12:11] Ubit Umarov : et pire encore...
[12:11] Gavin.Hird @grid.xmir.org:8002 : les tables postgres sont en partie des uuid natifs et en partie des varchar.
[12:11] Ubit Umarov : certaines sont apparues en tant que uuid et ont maintenant plus de choses.
[12:11] Ubit Umarov : comme l'uui
[12:11] Ubit Umarov : c'est à dire uuid+ gridhost etc...
[12:12] Andrew Hellershanks : Exact.
[12:12] Gavin.Hird @grid.xmir.org:8002 : Griduser UserID est aussi une gemme.
[12:13] Ubit Umarov : difficile de réparer ce désordre maintenant.
[12:13] Ubit Umarov : il est présent à beaucoup d'endroits.
[12:13] Gavin.Hird @grid.xmir.org:8002 : :-)
[12:14] Ubit Umarov : donc l'utilisation de l'uuid natif de la base de données n'est pas très utile.
[12:14] Ubit Umarov : et en même temps ce natif est juste une chaîne de 36 caractères avec le '-' inutile.
[12:15] Gavin.Hird @grid.xmir.org:8002 : le natif supporte en fait 3 implémentations différentes de l'uuid.
[12:17] Gavin.Hird @grid.xmir.org:8002 : PostgreSQL accepte également les formes alternatives suivantes pour la saisie : utilisation de chiffres en majuscules, format standard entouré d'accolades, omission de certains ou de tous les traits d'union, ajout d'un trait d'union après tout groupe de quatre chiffres.
[12:19] Gavin.Hird @grid.xmir.org:8002 : PostgreSQL fournit des fonctions de stockage et de comparaison pour les UUIDs, mais la base de données de base n'inclut aucune fonction pour générer des UUIDs, parce qu'aucun algorithme unique n'est bien adapté à chaque application.
[12:20] Ubit Umarov : je ne sais pas si le crash nécessite un débogage pour trouver où se trouve le mélange de types.
[12:21] Ubit Umarov: cmd.Parameters.Add(m_database.CreateParameter(fields[i], keys[i], m_FieldTypes[fields[i]]));
[12:21] Ubit Umarov: je devine que ça se passe là.
[12:22] Ubit Umarov : Ouais, je suppose que c'est là.

Une petite nouvelle d'OpenSim

[12:00] Andrew Hellershanks : Une petite nouvelle d'OpenSim. Le plus gros changement de la semaine dernière a été de gagner quelques nanosecondes en gérant les vérifications des chaînes vides de manière plus efficace.

Conclusion

[12:27] Andrew Hellershanks : Il est presque l'heure et demie. Des questions de dernière minute pour aujourd'hui ?
[12:28] Gavin.Hird @grid.xmir.org:8002 : j'ai réussi à compiler la version macOS du viewer avec le dernier Xcode. Maintenant la version Intel compile aussi sur une machine Apple Silicon.
[12:29] Andrew Hellershanks : C'est bien, Gavin.
[12:29] Gavin.Hird @grid.xmir.org:8002 : La compilation est plus rapide que sur n'importe quel kit Intel que j'ai.
[12:29] Andrew Hellershanks: :)
[12:30] Andrew Hellershanks : Il est temps de conclure la réunion d'aujourd'hui.
[12:30] Gavin.Hird @grid.xmir.org:8002 : warp
[12:30] Kayaker Magic : Oui, je dois courir.
[12:30] Andrew Hellershanks : Bonne chance avec votre travail sur les problèmes de Postgres. Le support Postgres ne bénéficie pas de beaucoup d'amour.
[12:30] Kayaker Magic : au revoir à tous !
[12:30] Andrew Hellershanks : Merci à tous d'être venus. Nous vous reverrons la semaine prochaine.
Récupérée de « https://cogito.no-ip.info/cogito/OSWiki/index.php?title=Réunion_du_18-01-2022&oldid=4142 »