Réunion du 18-01-2022
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
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
- Mono: mise en œuvre open source de la plateforme de développement Microsoft .NET
- 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 donc 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 est 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:50] Vincent.Sylvester @hg.zetaworlds.com:8002 : Et ça me rappelle, Gavin, tu as vu que le mantis sur postgres ne fonctionnait pas, as-tu pu reproduire ça ?
[11:50] Gavin.Hird @grid.xmir.org:8002 : Je n'ai pas vu cela
[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: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] 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...
[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 that is changinf to a .net5 or standard lib
[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:56] Vincent.Sylvester @hg.zetaworlds.com:8002: OpenSim has clean and well structured code in comparison
[11:56] Ubit Umarov: possible can't anymore
[11:56] Gavin.Hird @grid.xmir.org:8002: current supported versions are in the 4.high or even 5 versions
[11:56] Vincent.Sylvester @hg.zetaworlds.com:8002: 4.1.9 is total nightmare, 8 dlls that wants
[11:56] Vincent.Sylvester @hg.zetaworlds.com:8002: All manners of random things
[11:56] Ubit Umarov: like all religion kids, possible they just blindly moved to .net5/6 and relatives
[11:57] Gavin.Hird @grid.xmir.org:8002: nuget(?) install
[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:58] Ubit Umarov: vincent main software job is to force users to by more powerfull machines
[11:58] Vincent.Sylvester @hg.zetaworlds.com:8002: Space heaters
[11:58] Gavin.Hird @grid.xmir.org:8002: it actually does more like supporting new features in postgres 13 and 14
[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:59] Andrew Hellershanks: :)
[11:59] Andrew Hellershanks: We are at the top of the hour.
[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] Ubit Umarov: what uuid error?
[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: it is a casting error in
[12:00] Gavin.Hird @grid.xmir.org:8002: casting error with libomv (or what it is called)
[12:01] Ubit Umarov: libomv has nothing to do with pgsql
[12:01] Gavin.Hird @grid.xmir.org:8002: you keep saying that
[12:01] Gavin.Hird @grid.xmir.org:8002: but it does
[12:01] Gavin.Hird @grid.xmir.org:8002: it cannot do a cast
[12:01] Gavin.Hird @grid.xmir.org:8002: with uuid as it is implemented in libomv
[12:01] Ubit Umarov: wel then the cast needs a workaround
[12:02] Ubit Umarov: ut has own uuid?
[12:02] Ubit Umarov: possible the casts need the full namespace spec
[12:02] Ubit Umarov: uuid is also a native type of that hign?
[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: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 >
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>
[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] Ubit Umarov: Can't convert .NET type OpenMetaverse.UUID to PostgreSQL uu
[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: it tells uu
[12:04] Ubit Umarov: :)
[12:04] Gavin.Hird @grid.xmir.org:8002: uuid is native dataype in postgres
[12:05] Ubit Umarov: ok then isolation is needed
[12:05] Ubit Umarov: one needs to have full namespace spec
[12:06] Ubit Umarov: why that is a issue with new mono and not older.. well.. no idea
[12:06] Gavin.Hird @grid.xmir.org:8002: deprecations
[12:06] Gavin.Hird @grid.xmir.org:8002: or actually removal of support in npgsql
[12:07] Gavin.Hird @grid.xmir.org:8002: but then BOOM - mono was not updated any more
[12:07] Ubit Umarov: PGSQLGenericTableHandler
[12:08] Ubit Umarov: well that is a "clever" to it all thing
[12:08] Ubit Umarov: not that simple do fix
[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: it does not support upsert, so there are issues with some tables bacause of that
[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: guess m_Fields[name].GetValue(row) is UUID is other 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: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: some are just done as string
[12:10] Jamie.Jordan @grid.kitely.com:8002: Have a great week yall
[12:11] Ubit Umarov: and not just on the db.. even on main opensim code
[12:11] Andrew Hellershanks: ok, Jamie. You too. Thanks for dropping by
[12:11] Ubit Umarov: and worse
[12:11] Gavin.Hird @grid.xmir.org:8002: the postgres tables are partly native uuid and partly varchar
[12:11] Ubit Umarov: some where born as uuid and now have more things
[12:11] Ubit Umarov: like the uui
[12:11] Ubit Umarov: ie uuid+ gridhost etc
[12:12] Andrew Hellershanks: Right.
[12:12] Gavin.Hird @grid.xmir.org:8002: Griduser UserID is also a gem
[12:13] Ubit Umarov: hard to fix that mess now
[12:13] Ubit Umarov: it is on a lot of places
[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: and on same that natice is just a 36 chars string and with the useless '-'
[12:14] Ubit Umarov: that native..
[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 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 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: 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: guess here
[12:22] Ubit Umarov: yeha guess it is there
[12:27] Andrew Hellershanks: Almost half past the hour. Any last minute items for today?
[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.
[12:29] Gavin.Hird @grid.xmir.org:8002: it compiled faster than on any of the Intel kit I have
[12:29] Andrew Hellershanks: :)
[12:30] Andrew Hellershanks: Time to wrap the meeting for today.
[12:30] Gavin.Hird @grid.xmir.org:8002: warp
[12:30] Kayaker Magic: Yup, I need to run.
[12:30] Andrew Hellershanks: Good luck with your work on Postgres issues. Postgres support doesn't see a lot of love.
[12:30] Kayaker Magic: bye all!
[12:30] Andrew Hellershanks: Thank you all for coming. See you again next week.