« Réunion du 16-11-2021 » : différence entre les versions

De OSWiki
Aller à la navigation Aller à la recherche
Aucun résumé des modifications
 
(12 versions intermédiaires par le même utilisateur non affichées)
Ligne 1 : Ligne 1 :
Bientôt la traduction
[http://opensimulator.org/wiki/Chat_log_from_the_meeting_on_2021-11-16 Source ]
=Introduction=
=Introduction=
<pre>
<pre>
Ligne 36 : Ligne 36 :
[11:07] Ubit Umarov : certains parce qu'ils sont simplement mauvais.
[11:07] Ubit Umarov : certains parce qu'ils sont simplement mauvais.
[11:07] Ubit Umarov : d'autres pour gagner du temps
[11:07] Ubit Umarov : d'autres pour gagner du temps
 
[11:07] Vincent.Sylvester @hg.zetaworlds.com:8002 : Ce qui se déclenche est 0x400 qui est le redémarrage de la région, je pense que c'est à prévoir étant donné que la scène est configurée et le script rezze pratiquement instantanément sans attendre donc je suppose qu'il se heurte à cela d'une manière ou d'une autre.
[11:07] Vincent.Sylvester @hg.zetaworlds.com:8002: What fires is 0x400 which is region restart, I think that is to be expected given the scene is setup and the script rezzed practically instantly without wait so I guess it runs into that somehow
[11:07] Ubit Umarov : en l'état, cette boîte prend environ 5 minutes pour tout faire.
[11:07] Ubit Umarov: as is that box takes like 5 minutes to do all
[11:07] Ubit Umarov : je veux dire faire la compilation et le sous-ensemble actuel de tests.
[11:07] Ubit Umarov: i mean to do compile and current subset of tests
[11:08] Ubit Umarov : le dimanche, cela peut prendre 10 heures :p
[11:08] Ubit Umarov: on sundays can take like 10hours :p
[11:08] Vincent.Sylvester @hg.zetaworlds.com:8002 : Ce qui est intéressant, c'est comment dans vscode beaucoup de tests échouent alors qu'ils fonctionnent bien sur Jenkins.
[11:08] Vincent.Sylvester @hg.zetaworlds.com:8002: What is interesting how in vscode a lot of working tests fail while they are fine on Jenkins
[11:08] Ubit Umarov : c'est quoi vscode ?
[11:08] Ubit Umarov: what is vscode?
[11:08] Ubit Umarov: :p
[11:08] Ubit Umarov: :p
[11:08] Vincent.Sylvester @hg.zetaworlds.com:8002: Not sure if that is some version difference or system dependency to blame there
[11:08] Vincent.Sylvester @hg.zetaworlds.com:8002 : Pas sûr qu'il y ait une différence de version ou une dépendance du système à blâmer ici.
[11:09] Vincent.Sylvester @hg.zetaworlds.com:8002: Think is still all nunit 264
[11:09] Vincent.Sylvester @hg.zetaworlds.com:8002 : Je pense que c'est encore tout Nunit 264
[11:09] Ubit Umarov: some tests have time dependencies
[11:09] Ubit Umarov : certains tests ont des dépendances temporelles.
[11:09] Vincent.Sylvester @hg.zetaworlds.com:8002: I suspect that plays into that some timing and dependency difference not accounted for
[11:09] Vincent.Sylvester @hg.zetaworlds.com:8002 : Je soupçonne que cela joue dans cette différence de timing et de dépendance non prise en compte.
[11:10] Vincent.Sylvester @hg.zetaworlds.com:8002: Mostly on complex tests that are a bit hard to read still, thankfully most of the script engine tests are pretty straight forward so fixing those wasn't difficult
[11:10] Vincent.Sylvester @hg.zetaworlds.com:8002 : Principalement sur les tests complexes qui sont encore un peu difficiles à lire, heureusement la plupart des tests du moteur de script sont assez simples donc les corriger n'a pas été difficile.
[11:10] Ubit Umarov: well tests will need a deep revision
[11:10] Ubit Umarov : les tests auront besoin d'une révision profonde
[11:10] Ubit Umarov: some whre made just bad, from start, others did got obsolete
[11:10] Ubit Umarov : certains ont été mal faits dès le départ, d'autres sont devenus obsolètes.
[11:11] Ubit Umarov: all on a old nunit version also
[11:11] Ubit Umarov : tous sur une ancienne version de nunit aussi
[11:11] Ubit Umarov: but a few tehre did detect a few of mistakes from me... so some are useful
[11:11] Ubit Umarov : mais certains ont détecté quelques une de mes erreurs... donc certains sont utiles.
[11:11] Vincent.Sylvester @hg.zetaworlds.com:8002: I mean given how some bugs existed without a test ever finding them is testament to that, but is also not really easy to write them given the abstract nature of how it works
[11:11] Vincent.Sylvester @hg.zetaworlds.com:8002 : Je veux dire que la façon dont certains bugs sont arrivés sans qu'un test ne les détecte jamais en témoigne, mais il n'est pas vraiment facile d'en écrire étant donné la nature abstraite dont  cela fonctionnement.
[11:12] Vincent.Sylvester @hg.zetaworlds.com:8002: Like poking holes into an onion
[11:12] Vincent.Sylvester @hg.zetaworlds.com:8002 : Comme faire des trous dans un oignon
[11:12] Ubit Umarov: testing is a complex thing
[11:12] Ubit Umarov : les tests sont une chose complexe.
[11:13] Ubit Umarov: now all take advantage of internet and automatic updates, turning the end user the tester
[11:13] Ubit Umarov : maintenant tous profitent d'internet et des mises à jour automatiques, transformant l'utilisateur final en testeur.
[11:13] Ubit Umarov: some even make users pay to test, on the so called early access things
[11:13] Ubit Umarov : certains font même payer les utilisateurs pour tester, sur les choses dites d'accès anticipé.
[11:14] Vincent.Sylvester @hg.zetaworlds.com:8002: Others just throw it out and let the users fix it up
[11:14] Vincent.Sylvester @hg.zetaworlds.com:8002 : D'autres lancent simplement et laissent les utilisateurs le réparer.
[11:14] Vincent.Sylvester @hg.zetaworlds.com:8002: Granted a bit easier with open source heh
[11:14] Vincent.Sylvester @hg.zetaworlds.com:8002 : Effectivement, un peu plus facile avec l'open source heh
[11:14] Ubit Umarov: do not tell opensim secrets in public vincent.Sylvester
[11:14] Ubit Umarov : ne pas dire les secrets d'opensim en public vincent.Sylvester
[11:15] Ubit Umarov: errr Ooops
[11:15] Ubit Umarov: errr Ooops
[11:15] Ubit Umarov: ;)
[11:15] Ubit Umarov: ;)
[11:15] Ubit Umarov: so what news do you have about opensim?
</pre>
[11:16] Vincent.Sylvester @hg.zetaworlds.com:8002: You changed some priority queue thing
= Référence nulle et suppression d'objets encore utilisés=
[11:16] Vincent.Sylvester @hg.zetaworlds.com:8002: Been meaning to ask what that was about actually
<pre>
[11:16] Jamie.Jordan @grid.kitely.com:8002: hi everybody
[11:15] Ubit Umarov : alors quelles sont les nouvelles que vous avez sur opensim ?
[11:16] Gavin.Hird @grid.xmir.org:8002: Hi Jamie
[11:16] Vincent.Sylvester @hg.zetaworlds.com:8002 : Tu as modifié un truc de la file d'attente prioritaire
[11:17] Andrew Hellershanks: Hello, Jamie.
[11:16] Vincent.Sylvester @hg.zetaworlds.com:8002 : Je voulais demander de quoi il s'agissait en fait.
[11:17] Ubit Umarov: in some timing cases, we did get null references poluting log
[11:16] Jamie.Jordan @grid.kitely.com:8002 : Bonjour à tous.
[11:17] Selby.Evans @grid.kitely.com:8002: hi Jamie
[11:16] Gavin.Hird @grid.xmir.org:8002 : Salut Jamie
[11:17] Andrew Hellershanks: Nothing really to report this week about OpenSim code wise. There were two small changes but it reads like they were just some internal code cleanup.
[11:17] Selby.Evans @grid.kitely.com:8002 : salut Jamie
[11:17] Ubit Umarov: so i added some try/catch to "hide" that
[11:17] Ubit Umarov : dans certains cas, nous avons eu des références nulles qui ont pollué le journal.
[11:18] Ubit Umarov: those null refs happen bc opensim left hand has no idea what right is doing
[11:17] Andrew Hellershanks : Rien à signaler cette semaine concernant le code d'OpenSim. Il y a eu deux petits changements mais il semble qu'il s'agissait juste d'un nettoyage de code interne.
[11:17] Ubit Umarov : j'ai donc ajouté des try/catch pour "cacher" cela.
[11:18] Ubit Umarov : ces références nulles arrivent parce que la main gauche d'opensim n'a aucune idée de ce que fait la droite.
[11:18] Andrew Hellershanks: :)
[11:18] Andrew Hellershanks: :)
[11:18] Ubit Umarov: and somethings do get released while the other is using them
[11:18] Ubit Umarov : et certaines choses sont libérées pendant que l'autre les utilise.
[11:18] Ubit Umarov: like when a avatar is gone
[11:18] Ubit Umarov : comme lorsqu'un avatar disparaît.
[11:18] Vincent.Sylvester @hg.zetaworlds.com:8002: Hence removing some locks I see
[11:18] Vincent.Sylvester @hg.zetaworlds.com:8002 : D'où la suppression de certains verrous, je vois
[11:19] Ubit Umarov: locks is a bit diferent
[11:19] Ubit Umarov : les verrous sont un peu différents.
[11:19] Andrew Hellershanks: Isn't that also where ref counts come in?
[11:19] Andrew Hellershanks : N'est-ce pas aussi là que les compteurs de réf. entrent en jeu ?
[11:19] Ubit Umarov: i replaced some by lower spectrum ones
[11:19] Ubit Umarov : J'en ai remplacé certaines par des références à plus faible spectre.
[11:19] Ubit Umarov: what ref counts?
[11:19] Ubit Umarov : quels compteurs de référence ?
[11:20] Ubit Umarov: love ppl talking from.. well somewhere :p
[11:20] Ubit Umarov : j'adore les gens qui parlent de... eh bien de quelque part :p
[11:20] Ubit Umarov: this things happen also because total blind and massive multitasking
[11:20] Ubit Umarov : ce genre de choses arrive aussi à cause de l'aveuglement total et du multitâche massif.
[11:21] Andrew Hellershanks: Aren't the things being null referenced objects. AFAIK, objects are supposed to have (or can have) ref counts so the system knows when it is safe to get rid of them.
[11:21] Andrew Hellershanks : Les choses qui sont référencées comme nulles ne sont pas des objets. AFAIK, les objets sont censés avoir (ou peuvent avoir) des compteurs de ref afin que le système sache quand il est sans danger de s'en débarrasser.
[11:21] Ubit Umarov: very hard to fix now
[11:21] Ubit Umarov : très difficile à corriger maintenant.
[11:21] Ubit Umarov: system fails to release them
[11:21] Ubit Umarov : le système ne parvient pas à les libérer.
[11:22] Ubit Umarov: and also contrary to claims a lot of things need to be cleared by hand
[11:22] Ubit Umarov : et aussi contrairement aux affirmations, beaucoup de choses doivent être nettoyées à la main.
[11:22] Vincent.Sylvester @hg.zetaworlds.com:8002: good ole gc
[11:22] Vincent.Sylvester @hg.zetaworlds.com:8002 : bon vieux gc
[11:22] Ubit Umarov: we have no access to ref counts
[11:22] Ubit Umarov : nous n'avons pas accès au nombre de références.
[11:22] Ubit Umarov: those are internal things
[11:22] Ubit Umarov : ce sont des choses internes.
[11:23] Ubit Umarov: i did add several IsDeleted things here and there
[11:23] Ubit Umarov : j'ai ajouté plusieurs choses IsDeleted ici et là.
[11:23] Ubit Umarov: but still can't fix all issues, some because multitask
[11:23] Ubit Umarov : mais je ne peux toujours pas résoudre tous les problèmes, certains à cause du multitâche.
[11:23] Andrew Hellershanks: Right. If the system is left to clean up the objects based on the ref counts the system should be deleting the object while still in use. If the code is doing manual clean up in one or more places then all bets are off.
[11:23] Andrew Hellershanks : C'est vrai. Si le système doit nettoyer les objets en fonction du nombre de références, il devrait supprimer l'objet tant qu'il est encore utilisé. Si le code fait un nettoyage manuel à un ou plusieurs endroits, alors tout est perdu.
[11:24] Ubit Umarov: things are there when tested, then are gone
[11:24] Ubit Umarov : les choses sont là quand elles sont testées, puis elles disparaissent.
[11:24] Vincent.Sylvester @hg.zetaworlds.com:8002: I wonder if all this being in the udp stack is down to faster cpu and networks now showing things hidden by delays in the past, certainly have had more glitches with timing on my new computer compared to the old one
[11:24] Vincent.Sylvester @hg.zetaworlds.com:8002 : Je me demande si le fait d'être dans la pile udp est dû à des processeurs plus rapides et à des réseaux qui montrent maintenant des choses cachées par des retards dans le passé, j'ai certainement eu plus de problèmes de timing sur mon nouvel ordinateur que sur l'ancien.
[11:24] Ubit Umarov: and we can't put locks everywhere
[11:24] Ubit Umarov : et nous ne pouvons pas mettre des verrous partout.
[11:25] Ubit Umarov: soem of this things did start to show up when i added proper dispose of things GC never releases
[11:25] Ubit Umarov : certaines de ces choses ont commencé à apparaître quand j'ai ajouté une méthode de traitement des choses que GC ne libère jamais.
[11:25] Ubit Umarov: like all framework things that have the method Dispose()
[11:25] Ubit Umarov : comme toutes les choses du framework qui ont la méthode Dispose()
[11:26] Ubit Umarov: that opensim never did actually disposed, so no null references visible, ofc things stayed there lost for ever
[11:26] Ubit Umarov : qu'opensim n'a jamais éliminé, donc pas de références nulles visibles, bien sûr les choses sont restées là, perdues pour toujours.
[11:27] Vincent.Sylvester @hg.zetaworlds.com:8002: Well if it then actually disposes and mono voodoo not refusing heh
[11:27] Vincent.Sylvester @hg.zetaworlds.com:8002 : Eh bien, si il élimine alors réellement et mono voodoo ne refuse pas heh
[11:28] Ubit Umarov: as i said that change also moved some locks so they impact less code, just the one that needs them
[11:28] Ubit Umarov : comme je l'ai dit, ce changement a aussi déplacé certains verrous pour qu'ils aient un impact sur moins de code, juste celui qui en a besoin.
[11:28] Ubit Umarov: yeah GC fails to release memory it was suposed to
[11:28] Ubit Umarov : ouais GC ne parvient pas à libérer la mémoire qu'il était supposé libérer.
[11:28] Ubit Umarov: we can still see a region just decide to use 20GB of ram
[11:28] Ubit Umarov : nous pouvons toujours voir une région décider d'utiliser 20GB de ram.
[11:29] Vincent.Sylvester @hg.zetaworlds.com:8002: I wonder if some of it is down to code just being old and relying implicit on delays from back when cpu wasn't so powerful
[11:29] Vincent.Sylvester @hg.zetaworlds.com:8002 : Je me demande si une partie de ce problème n'est pas dû au fait que le code est vieux et qu'il repose implicitement sur des délais datant de l'époque où le processeur n'était pas si puissant.
[11:29] Ubit Umarov: only a few timing issues .. not this mem things
[11:29] Ubit Umarov : seulement quelques problèmes de timing ... pas ce genre de choses.
[11:29] Ubit Umarov: teleports are a damm timing issue thing
[11:29] Ubit Umarov : les téléportations sont un problème de timing.
[11:29] Vincent.Sylvester @hg.zetaworlds.com:8002: I did run some tests regarding that timer event divergence and found it to be related to cpu speed even, which is interesting
</pre>
[11:30] Vincent.Sylvester @hg.zetaworlds.com:8002: Could potentially measure cpu speed by how quickly timer event adds a second
= Problèmes avec l'événement 'timer' = 
[11:30] Ubit Umarov: but opensim has a plague of potencial timing issues
[http://opensimulator.org/mantis/view.php?id=3862  Les  événements timer des scripts sont très imprécis sur une période donnée.]
[11:30] Ubit Umarov: most bc of its uncontroled multitask
<pre>
[11:29] Vincent.Sylvester @hg.zetaworlds.com:8002 : J'ai effectué quelques tests concernant la divergence des événements timer et j'ai constaté qu'elle était liée à la vitesse du processeur, ce qui est intéressant.
[11:30] Vincent.Sylvester @hg.zetaworlds.com:8002 : On pourrait potentiellement mesurer la vitesse du processeur en fonction de la vitesse à laquelle l'événement du timer ajoute une seconde.
[11:30] Ubit Umarov : mais opensim a un tas de problèmes potentiels de timing.
[11:30] Ubit Umarov : surtout en raison de son  multitâche incontrôlé.
[11:30] Ubit Umarov: design
[11:30] Ubit Umarov: design
[11:31] Ubit Umarov: fear that on a busi region the threads spend more time waiting on locks than doing things
[11:31] Ubit Umarov : je crains que sur une région occupée, les threads passent plus de temps à attendre les verrous qu'à faire des choses.
[11:31] Ubit Umarov: well at least a lot of time :)
[11:31] Ubit Umarov : au moins beaucoup de temps :)
[11:32] Vincent.Sylvester @hg.zetaworlds.com:8002: You wouldn't notice it the viewer would go down to single digit fps anyways heh
[11:32] Vincent.Sylvester @hg.zetaworlds.com:8002 : Vous ne le remarquerez pas, le viewer descendrait à des fps à un chiffre de toute façon.
[11:32] Ubit Umarov: viewers are still mostly single thread
[11:32] Ubit Umarov : les viewers sont encore principalement des threads uniques.
[11:32] Ubit Umarov: ll is finally moving some thigs to other threads
[11:32] Ubit Umarov : LL est enfin en train de déplacer certaines choses vers d'autres threads.
[11:33] Ubit Umarov: that it is the oposite case of multi cores usage.. not using them :P
[11:33] Ubit Umarov : c'est le contraire de l'utilisation des multi-cœurs... ne pas les utiliser :P
[11:34] Ubit Umarov: opensim was made on the other case.. use cores cpus may have in 2100
[11:34] Ubit Umarov : opensim a été fait sur l'autre condition.. utiliser les cœurs que les cpus auront en 2100.
[11:34] Andrew Hellershanks: I noticed a timing issue this past week in OS related to keyframe motion.
[11:34] Andrew Hellershanks : J'ai remarqué un problème de timing la semaine dernière dans l'OS lié au mouvement des keyframe.
[11:35] Andrew Hellershanks: A sequence of steps that is supposed to be done in 64 seconds takes closer to 68.
[11:35] Andrew Hellershanks : Une séquence d'étapes qui est censée être réalisée en 64 secondes en prend plus de 68.
[11:36] Andrew Hellershanks: I haven't had time to look at the OS code to get any idea as to why there is a difference between expected and actual timing.
[11:36] Andrew Hellershanks : Je n'ai pas eu le temps de regarder le code du système d'exploitation pour avoir une idée de la raison pour laquelle il y a une différence entre le timing attendu et le timing réel.
[11:36] Vincent.Sylvester @hg.zetaworlds.com:8002: Assuming that probably uses the same timing control as timer event, which tends to go out of sync rather quickly as well, especially once you start adding code to the event itself
[11:36] Vincent.Sylvester @hg.zetaworlds.com:8002 : En supposant que cela utilise probablement le même contrôle de temporisation que l'événement timer, qui a tendance à se désynchroniser assez rapidement, en particulier lorsque vous commencez à ajouter du code à l'événement lui-même.
[11:37] Andrew Hellershanks: AFAICR, in 0.8.2 the timing was perfect or so close I didn't notice any discrepancy.
[11:37] Andrew Hellershanks : AFAICR, dans la 0.8.2 le timing était parfait ou si proche que je n'ai pas remarqué d'écart.
[11:37] Ubit Umarov: well as i said months ago i remade KFM code entire
[11:37] Ubit Umarov : comme je l'ai dit il y a quelques mois, j'ai refait le code entier de KFM.
[11:37] Ubit Umarov: but its serielization is incompatible to older
[11:37] Ubit Umarov : mais sa sérialisation est incompatible avec les anciennes versions.
[11:37] Ubit Umarov: so..   yeach.. on hold :P
[11:37] Ubit Umarov : donc... yeach... en attente :P
[11:38] Vincent.Sylvester @hg.zetaworlds.com:8002: When you time these things make sure to use strict floats, as in 3.0f and it makes sense to adjust for the initial timing difference say 2.97f for example, that generally gets you better results
[11:38] Vincent.Sylvester @hg.zetaworlds.com:8002 : Lorsque vous chronométrez ces choses, assurez-vous d'utiliser des flottants stricts, comme dans 3.0f et il est logique d'ajuster pour la différence de temps initiale, disons 2.97f par exemple, cela vous donne généralement de meilleurs résultats.
[11:38] Ubit Umarov: yes andrew we all know 0.8.2 was perfect
[11:38] Ubit Umarov : oui andrew nous savons tous que la 0.8.2 était parfaite.
[11:38] Ubit Umarov: bahh
[11:38] Ubit Umarov : bahh
[11:38] Vincent.Sylvester @hg.zetaworlds.com:8002: From there you can then get a better idea on where the issue starts
[11:38] Vincent.Sylvester @hg.zetaworlds.com:8002 : A partir de là, vous pourrez avoir une meilleure idée de l'origine du problème.
[11:39] Vincent.Sylvester @hg.zetaworlds.com:8002: Been digging around in timer code a little bit think there is some precision lost on a type conversion, but haven't gotten around to really play with that
[11:39] Vincent.Sylvester @hg.zetaworlds.com:8002 : J'ai creusé un peu dans le code du timer, je pense qu'il y a une certaine précision perdue sur une conversion de type, mais je n'ai pas eu le temps de vraiment jouer avec ça.
[11:39] Andrew Hellershanks: Vincent, what do you mean by the initial timing difference.
[11:39] Andrew Hellershanks : Vincent, que veux-tu dire par la différence de timing initial.
[11:39] Ubit Umarov: well like 0.9 actually does kfm, while 0.8 did.. something
[11:39] Ubit Umarov : en fait, la 0.9 fait kfm, alors que la 0.8 faisait... quelque chose.
[11:40] Ubit Umarov: whatever
[11:40] Ubit Umarov : Peu importe.
[11:40] Ubit Umarov: file a mantis, in a for others can repo
[11:40] Ubit Umarov : déposer un mantis, dans un for que les autres peuvent repo.
[11:40] Ubit Umarov: in a form..
[11:40] Ubit Umarov : dans un form...
[11:40] Vincent.Sylvester @hg.zetaworlds.com:8002: If you run say timer event every 3 seconds it initially doesn't start at 3, but adds say 0.03 to it
[11:40] Vincent.Sylvester @hg.zetaworlds.com:8002 : Si vous exécutez disons un événement timer toutes les 3 secondes, il ne commence pas initialement à 3, mais ajoute disons 0,03 à cette valeur.
[11:40] Vincent.Sylvester @hg.zetaworlds.com:8002: Probably because execution time of the code itself
[11:40] Vincent.Sylvester @hg.zetaworlds.com:8002 : Probablement à cause du temps d'exécution du code lui-même
[11:41] Vincent.Sylvester @hg.zetaworlds.com:8002: When you adjust for that you end up getting more accurate timing for longer
[11:41] Vincent.Sylvester @hg.zetaworlds.com:8002 : Lorsque vous ajustez sur cela, vous finissez par obtenir un timing plus précis pour plus longtemps.
[11:41] Vincent.Sylvester @hg.zetaworlds.com:8002: Guess it adjusts for some of the precision lost somewhere in the pipe
[11:41] Vincent.Sylvester @hg.zetaworlds.com:8002 : Je suppose que cela corrige une partie de la précision perdue quelque part dans le pipe.
[11:42] Vincent.Sylvester @hg.zetaworlds.com:8002: Like I have a feeling if I added debug output to timer event to see how long it itself takes to run probably just skews the results more
[11:42] Vincent.Sylvester @hg.zetaworlds.com:8002 : J'ai l'impression que si j'ajoute une sortie de débogage à l'événement timer pour voir combien de temps il prend lui-même pour s'exécuter, cela ne fera que fausser davantage les résultats.
[11:42] Ubit Umarov: some timing things do have intensional drift
[11:42] Ubit Umarov : certaines choses du timing ont une dérive intensionnelle.
[11:42] Ubit Umarov: intencional
[11:42] Ubit Umarov: intencional
[11:42] Ubit Umarov: it is called Dilation..
[11:42] Ubit Umarov : cela s'appelle la dilatation...
[11:43] Ubit Umarov: just it is not accounted for
[11:43] Ubit Umarov : il n'est pas comptabilisé.
[11:43] Vincent.Sylvester @hg.zetaworlds.com:8002: OpenSim by nature never really fully idles either so you get a millisecond here or there as well
[11:43] Vincent.Sylvester @hg.zetaworlds.com:8002 : OpenSim, par nature, ne tourne jamais complètement au ralenti, donc vous avez aussi une milliseconde ici ou là.
[11:44] Ubit Umarov: we can't account for time Dilation as sl, also bc of the multitask
[11:44] Ubit Umarov : nous ne pouvons pas tenir compte de la dilatation du temps comme sl, aussi à cause du multitâche.
[11:44] Ubit Umarov: so each part drifts its way
[11:44] Ubit Umarov : donc chaque partie dérive à sa façon.
[11:44] Vincent.Sylvester @hg.zetaworlds.com:8002: It's like that quantum particle thing, as soon as you try to add code to debug things you just skew the results even more
[11:44] Vincent.Sylvester @hg.zetaworlds.com:8002 : C'est comme le truc des particules quantiques, dès que l'on essaie d'ajouter du code pour déboguer les choses, les résultats sont encore plus faussés.
[11:44] Ubit Umarov: on my new KFM all the code runs on heartbeat
[11:44] Ubit Umarov : sur mon nouveau KFM, tout le code est exécuté sur les battements de cœur.
[11:45] Ubit Umarov: so its timing will be more in sync with the region heartbeat
[11:45] Ubit Umarov : ainsi son timing sera plus synchrone avec la pulsation de la région.
[11:46] Ubit Umarov: i just need to figure how to convert the btw old and new serielization
[11:46] Ubit Umarov : j'ai juste besoin de comprendre comment convertir l'ancienne vers la nouvelle sérialisation.
[11:46] Ubit Umarov: for regions crossings
[11:46] Ubit Umarov : pour les passages de régions
[11:46] Vincent.Sylvester @hg.zetaworlds.com:8002: I'll wish you luck in that, doesn't sound like funnest of tasks :)
[11:46] Vincent.Sylvester @hg.zetaworlds.com:8002 : Je te souhaite bonne chance pour cela, ça ne semble pas être une tâche des plus amusantes :)
[11:50] Andrew Hellershanks: An extra 0.03 per second would account for about half run time error I see. I'll need to retime it to verify the actual difference. I thought I had it written down on a piece of paper near me but I can't find it.
[11:50] Andrew Hellershanks : Un supplément de 0,03 par seconde expliquerait environ la moitié de l'erreur de temps d'exécution que je vois. Je vais devoir le recalculer pour vérifier la différence réelle. Je pensais l'avoir noté sur un bout de papier près de moi mais je ne le trouve pas.
[11:51] Vincent.Sylvester @hg.zetaworlds.com:8002: http://opensimulator.org/mantis/view.php?id=3862 That's what I am talking about Andrew
[11:51] Vincent.Sylvester @hg.zetaworlds.com:8002 : http://opensimulator.org/mantis/view.php?id=3862 C'est de cela que je parle Andrew
[11:51] Vincent.Sylvester @hg.zetaworlds.com:8002: Interesting results which I have yet to really get to the bottom of as to the why, but it helped a bit in understanding some of the timer issues I have had
[11:51] Vincent.Sylvester @hg.zetaworlds.com:8002 : Des résultats intéressants dont je n'ai pas encore compris le pourquoi, mais qui m'ont aidé à comprendre certains des problèmes de timer que j'ai rencontrés.
[11:52] Vincent.Sylvester @hg.zetaworlds.com:8002: That said like Ubit mentioned best not to rely on timer event for accuracy
[11:52] Vincent.Sylvester @hg.zetaworlds.com:8002 : Cela dit, comme Ubit l'a mentionné, il est préférable de ne pas compter sur l'événement timer pour la précision.
[11:52] Vincent.Sylvester @hg.zetaworlds.com:8002: timer event, only slightly more accurate than your inner clock lol
[11:52] Vincent.Sylvester @hg.zetaworlds.com:8002 : événement timer, seulement légèrement plus précis que votre horloge personnelle.lol
[11:52] Ubit Umarov: guys time accuracy does not apply to PCs
[11:52] Ubit Umarov : la précision de l'heure des hommes ne s'applique pas aux PC.
[11:52] Ubit Umarov: unless on special kernel side devices
[11:52] Ubit Umarov : sauf sur les périphériques spéciaux du noyau.
[11:53] Andrew Hellershanks: Vincent, that does seem similar to the issue I have.
[11:53] Andrew Hellershanks : Vincent, cela semble similaire au problème que j'ai.
[11:53] Ubit Umarov: that is why a car controler does not run on windows or linux
[11:53] Ubit Umarov : c'est pourquoi un contrôleur de voiture ne fonctionne pas sous windows ou linux.
[11:53] Gavin.Hird @grid.xmir.org:8002: lol
[11:53] Gavin.Hird @grid.xmir.org:8002: lol
[11:53] Ubit Umarov: ( the display may.. ofc )
[11:53] Ubit Umarov : ( l'affichage peut.. ofc )
[11:54] Ubit Umarov: and there are RTOS versions of linux also
[11:54] Ubit Umarov : et il y a aussi des versions RTOS de linux.
[11:54] Gavin.Hird @grid.xmir.org:8002: have you not seen the Windows XP logo when the Tesla car controller crash?
[11:54] Gavin.Hird @grid.xmir.org:8002 : n'avez-vous pas vu le logo de Windows XP lors du crash du contrôleur de la voiture Tesla ?
[11:54] Ubit Umarov: XP still?
[11:54] Ubit Umarov : XP toujours ?
[11:54] Vincent.Sylvester @hg.zetaworlds.com:8002: what even is time, just a concept, all it does is make you old :)
[11:54] Vincent.Sylvester @hg.zetaworlds.com:8002 : qu'est-ce que le temps, juste un concept, tout ce qu'il fait c'est vous rendre vieux :)
[11:54] Ubit Umarov: but bet that is on the UI devices
[11:54] Ubit Umarov : mais je parie que c'est sur les appareils de l'interface utilisateur.
[11:54] Gavin.Hird @grid.xmir.org:8002: I have at least seen it on ATMs
[11:54] Gavin.Hird @grid.xmir.org:8002 : Je l'ai au moins vu sur les ATM.
[11:54] Andrew Hellershanks: I could compensate by adjusting the cycle time but it becomes an issue when not knowing if a grid has done anything to their code to address that issue. If so, the fix needed for one grid would throw things off in another.
[11:54] Andrew Hellershanks : Je pourrais compenser en ajustant le temps de cycle mais cela devient un problème quand on ne sait pas si une grille a fait quelque chose dans son code pour résoudre ce problème. Si c'est le cas, le correctif nécessaire pour une grille pourrait perturber les choses dans une autre.
[11:54] Gavin.Hird @grid.xmir.org:8002: very recently
[11:54] Gavin.Hird @grid.xmir.org:8002 : très récemment.
[11:55] Vincent.Sylvester @hg.zetaworlds.com:8002: huh round here they just blow those up lately
[11:55] Vincent.Sylvester @hg.zetaworlds.com:8002 : huh par ici ils les font juste exploser dernièrement.
[11:55] Ubit Umarov: ( by controler i did not meant the UI things of cars.. but the low level things oc ECC etc
[11:55] Ubit Umarov : ( par contrôleur je ne voulais pas dire les choses de l'interface utilisateur des voitures... mais les choses de bas niveau OC ECC etc.
[11:56] Ubit Umarov: see for exmaple
[11:56] Ubit Umarov : voir par exemple
[11:56] Ubit Umarov: a framework ( even a win32) timer
[11:56] Ubit Umarov : un framework (même un timer win32)
[11:56] Ubit Umarov: what is does is to put on the threads work pool a request to run the timer event code
[11:56] Ubit Umarov : ce qu'il fait est de mettre sur le pool de travail des threads une demande d'exécution du code d'événement du timer.
[11:57] Ubit Umarov: "one day" when there is a thread free to do it
[11:57] Ubit Umarov : "Un jour, quand il y aura un fil de discussion libre pour le faire.
[11:58] Ubit Umarov: just that adds sevel ms delay ( at least 15 on windows )
[11:58] Ubit Umarov : cela ajoute juste un retard de plusieurs ms (au moins 15 sous Windows).
[11:58] Vincent.Sylvester @hg.zetaworlds.com:8002: If you want to have some fun with timing, just change your clocksource from tsc to hpet, backup your stuff first though
[11:58] Vincent.Sylvester @hg.zetaworlds.com:8002 : Si vous voulez vous amuser avec la synchronisation, changez simplement votre source d'horloge de tsc à hpet, mais sauvegardez d'abord vos données.
[11:59] Andrew Hellershanks: Wow. This hour went by very quickly today. Does anyone have some other topic they wanted to talk about today before we wrap things up?
[11:59] Andrew Hellershanks : Wow. Cette heure est passée très vite aujourd'hui. Est-ce que quelqu'un voulait parler d'un autre sujet avant de conclure ?
[11:59] Ubit Umarov: well and that is a diference btw game consoles and pcs
[11:59] Ubit Umarov : bien et c'est une différence entre les consoles de jeux et les PC.
[11:59] Ubit Umarov: ( or should be.. )
[11:59] Ubit Umarov : ( ou devrait l'être..)
[11:59] Gavin.Hird @grid.xmir.org:8002: ther has been a lot of discussions about map tiles
</pre>
[12:00] Gavin.Hird @grid.xmir.org:8002: storing in the db
= Tuiles de carte (maptiles)=
[12:00] Ubit Umarov: the store on db is actually obsolete
 
[12:00] Andrew Hellershanks: Don't forget about the Open Simulator Community Conference coming up on the weekend of December 11 and 12. Be sure to mark your calendars.
<pre>
[12:00] Ubit Umarov: at least for viewers usage
[11:59] Gavin.Hird @grid.xmir.org:8002 : il y a eu beaucoup de discussions sur les miniatures des cartes.
[12:00] Gavin.Hird @grid.xmir.org:8002: someone suggested an elaborate script to clear them out, but it only takes a simple SQL query
[12:00] Gavin.Hird @grid.xmir.org:8002 : stockage dans la base de données.
[12:00] Ubit Umarov: those are clear on each region restart
[12:00] Ubit Umarov : le stockage dans la base de données est en fait obsolète.
[12:01] Ubit Umarov: ofc not for dead regions :)
[12:00] Andrew Hellershanks : N'oubliez pas la conférence de la communauté Open Simulator qui aura lieu la fin de semaine du 11 et 12 décembre. Assurez-vous de marquer vos calendriers.
[12:01] Ubit Umarov: but issue is also on map service disk
[12:00] Ubit Umarov : au moins pour l'utilisation des viewers.
[12:01] Ubit Umarov: and that is NOT eaasy
[12:00] Gavin.Hird @grid.xmir.org:8002 : quelqu'un a suggéré un script élaboré pour les effacer, mais il suffit d'une simple requête SQL.
[12:01] Ubit Umarov: one can't go there and just delete region files
[12:00] Ubit Umarov : Elles sont nettoyées à chaque redémarrage de région.
[12:02] Gavin.Hird @grid.xmir.org:8002: not?
[12:01] Ubit Umarov : bien sûr, pas pour les régions mortes :)
[12:02] Vincent.Sylvester @hg.zetaworlds.com:8002: delete all terrainImage_% pretty much yeah, but if you store assets in files you need to find the files and remove those as well, which is not as easy and then you still have the issue of the different map tile scales which can only be altered when new tiles are submitted, there is no "cut this one out"
[12:01] Ubit Umarov : mais le problème est aussi sur le disque de service de la carte.
[12:02] Ubit Umarov: bc map tiles have levels
[12:01] Ubit Umarov : et ce n'est PAS facile.
[12:02] Ubit Umarov: high resolution is a region tile
[12:01] Ubit Umarov : on ne peut pas y aller et simplement supprimer les fichiers de la région.
[12:02] Ubit Umarov: less is a image made of 4 regions
[12:02] Gavin.Hird @grid.xmir.org:8002 : non ?
[12:02] Ubit Umarov: less.. etc
[12:02] Vincent.Sylvester @hg.zetaworlds.com:8002 : supprimer tous les terrainImage_% à peu près oui, mais si vous stockez les ressources dans des fichiers, vous devez trouver les fichiers et les supprimer également, ce qui n'est pas aussi facile, et puis vous avez toujours le problème des différentes échelles des tuiles de la carte qui ne peuvent être modifiées que lorsque de nouvelles tuiles sont soumises, il n'y a pas de "cut this one out".
[12:02] Ubit Umarov: don't remember how many levels
[12:02] Ubit Umarov: parce que les miniatures de la carte ont des niveaux
[12:02] Gavin.Hird @grid.xmir.org:8002: I just cleaned out 2 years of tiles
[12:02] Ubit Umarov : la haute résolution est une tuile de région.
[12:02] Vincent.Sylvester @hg.zetaworlds.com:8002: I did write some code to upload "water" on shutdown, but that doesn't work so well because the maptile scales are created async to the upload
[12:02] Ubit Umarov : moins est une image composée de 4 régions.
[12:03] Gavin.Hird @grid.xmir.org:8002: shrank the Db by about 8 GB
[12:02] Ubit Umarov : moins... etc...
[12:03] Ubit Umarov: that is heavy code actually
[12:02] Ubit Umarov : je ne me souviens pas du nombre de niveaux.
[12:03] Ubit Umarov: to rebuild all those zoom level tiles
[12:02] Gavin.Hird @grid.xmir.org:8002 : Je viens de nettoyer 2 ans de miniatures
[12:03] Vincent.Sylvester @hg.zetaworlds.com:8002: Yes maptiles are created, not updated in db, so regularly cleaning needs to be done
[12:02] Vincent.Sylvester @hg.zetaworlds.com:8002 : J'ai écrit un code pour télécharger "l'eau" à l'arrêt, mais cela ne fonctionne pas très bien parce que les échelles des maptiles sont créées async par rapport au téléchargement.
[12:04] Vincent.Sylvester @hg.zetaworlds.com:8002: I have some internal code that talks to regions to request new tiles after I nuke them all, but oh boy does that give Robust a workout
[12:03] Gavin.Hird @grid.xmir.org:8002 : J'ai réduit la base de données d'environ 8 Go.
[12:04] Ubit Umarov: again the ones on DBs as assets are old ones for old v1 viewers
[12:03] Ubit Umarov : c'est un code lourd en fait.
[12:04] Ubit Umarov: ( thing we do use them elsewhere also)
[12:03] Ubit Umarov : pour reconstruire toutes ces tuiles de niveau du zoom.
[12:04] Vincent.Sylvester @hg.zetaworlds.com:8002: yes
[12:03] Vincent.Sylvester @hg.zetaworlds.com:8002 : Oui, les maptiles sont créés, mais pas mis à jour dans la base de données, donc un nettoyage régulier doit être effectué.
[12:04] Ubit Umarov: the ones viewers use on map are the more complex ones i just told about
12:04] Vincent.Sylvester @hg.zetaworlds.com:8002 : J'ai un code interne qui parle aux régions pour demander de nouvelles tuiles après que je les ai toutes détruites, mais cela donne du fil à retordre à Robust.
[12:05] Vincent.Sylvester @hg.zetaworlds.com:8002: It's a mess and not easy to figure out a good solution to resolve either
[12:04] Ubit Umarov : encore une fois, ce qui est sur les bases de données en tant qu'assets sont les ancienes maptiles pour les anciens viewers v1.
[12:05] Ubit Umarov: every time we change one region we need to process several images
[12:04] Ubit Umarov : ( chose que nous utilisons ailleurs aussi )
[12:05] Vincent.Sylvester @hg.zetaworlds.com:8002: ... and there is worse garbage collecting in the db as well
[12:04] Vincent.Sylvester @hg.zetaworlds.com:8002: oui
[12:05] Ubit Umarov: for all those zoom levels
[12:04] Ubit Umarov : ceux que les viewers utilisent pour la carte sont les plus complexes dont je viens de parler.
[12:05] Ubit Umarov: you casn see the code on the mapservice
[12:05] Vincent.Sylvester @hg.zetaworlds.com:8002 : C'est un bazar et il n'est pas facile de trouver une bonne solution pour le résoudre.
[12:06] Ubit Umarov: the assets are easy problem
[12:05] Ubit Umarov : chaque fois que nous changeons une région, nous devons traiter plusieurs images.
[12:06] Ubit Umarov: or easier
[12:05] Vincent.Sylvester @hg.zetaworlds.com:8002 : ... et il y a aussi une mauvaise collecte des données résiduelles dans la base de données.
[12:06] Vincent.Sylvester @hg.zetaworlds.com:8002: I mean uploading water on shutdown "works" to clear the levels, but in turn that creates more database mess
[12:05] Ubit Umarov : pour tous ces niveaux de zoom
[12:07] Vincent.Sylvester @hg.zetaworlds.com:8002: And robust needs them to create the scales so cannot delete them immediately either
[12:05] Ubit Umarov : vous pouvez  voir le code sur le mapservice.
[12:07] Ubit Umarov: well to suport something like that, one should just use a fixed map asset
[12:06] Ubit Umarov : les assets sont un problème facile à résoudre
[12:07] Ubit Umarov: not upload a new water one
[12:06] Ubit Umarov : ou plus facile.
[12:06] Vincent.Sylvester @hg.zetaworlds.com:8002 : Je veux dire que télécharger de l'eau à l'arrêt "fonctionne" pour effacer les niveaux, mais à son tour cela crée plus de désordre dans la base de données.
[12:07] Vincent.Sylvester @hg.zetaworlds.com:8002 : Et Robust a besoin d'eux pour créer les dimensions, donc ne peut pas les supprimer immédiatement non plus.
[12:07] Ubit Umarov : pour supporter quelque chose comme ça, on devrait juste utiliser un asset de carte fixe.
[12:07] Ubit Umarov : ne pas uploader une nouvelle carte d'eau.
[12:08] Vincent.Sylvester @hg.zetaworlds.com:8002: Yep
[12:08] Vincent.Sylvester @hg.zetaworlds.com:8002: Yep
[12:08] Ubit Umarov: but several grids do want regions on map een if down
[12:08] Ubit Umarov : mais plusieurs grilles veulent que les régions soient sur la carte même si elles sont déconnectées.
[12:09] Ubit Umarov: in fact on several grids like kitely regions are normaly down until someone goes there
[12:09] Ubit Umarov : en fait sur plusieurs grilles comme kitely les régions sont normalement déconnectées jusqu'à ce que quelqu'un y aille.
[12:09] Ubit Umarov: including from click on map :)
[12:09] Ubit Umarov : y compris en cliquant sur la carte :)
[12:09] Vincent.Sylvester @hg.zetaworlds.com:8002: A good solution would be Robust regularly going through the list of regions and requesting new tiles, if none are given it assumes water and rebuilds, but that would put a huge burden on it
[12:09] Vincent.Sylvester @hg.zetaworlds.com:8002 : Une bonne solution serait que Robust passe régulièrement en revue la liste des régions et demande de nouvelles tuiles, si aucune n'est donnée, il suppose qu'il y a de l'eau et reconstruit, mais cela lui imposerait une énorme charge.
[12:09] Ubit Umarov: se not even easy to define When to clear map tiles
[12:09] Ubit Umarov : il n'est même pas facile de définir quand effacer les tuiles de la carte.
[12:09] Vincent.Sylvester @hg.zetaworlds.com:8002: Plus teaching Robust to anything with "regularity" is... fun...
[12:09] Vincent.Sylvester @hg.zetaworlds.com:8002 :De plus, dire quelque chose  à  Robust avec "régularité" est... amusant...
[12:10] Ubit Umarov: easy grid can have own needs
[12:10] Ubit Umarov : une simple grille peut avoir ses propres besoins.
[12:10] Ubit Umarov: so manual is a solution for now :)
[12:10] Ubit Umarov : donc le manuel est une solution pour le moment :)
[12:11] Andrew Hellershanks: I have sometimes wondered whether there should be some external program to handle maptile generation. That would likely have its own issues.
[12:11] Andrew Hellershanks : Je me suis parfois demandé s'il ne devrait pas y avoir un programme externe pour gérer la génération des maptiles. Cela aurait probablement ses propres problèmes.
[12:11] Vincent.Sylvester @hg.zetaworlds.com:8002: Ultimately the desire is there for removal given there exist beginnings of code in that direction and it is good programming standard to make sure a piece of software doesn't create massive amounts of orphaned data
[12:11] Vincent.Sylvester @hg.zetaworlds.com:8002 : En fin de compte, le désir est là pour la suppression étant donné qu'il existe des débuts de code dans cette direction et c'est un bon standard de programmation pour s'assurer qu'un morceau de logiciel ne crée pas de quantités massives de données orphelines.
[12:11] Vincent.Sylvester @hg.zetaworlds.com:8002: But yeah definition thing
[12:11] Vincent.Sylvester @hg.zetaworlds.com:8002 : Mais oui, le truc de la définition
[12:12] Vincent.Sylvester @hg.zetaworlds.com:8002: Also some of this code on actual maptile handling is... crude...
[12:12] Vincent.Sylvester @hg.zetaworlds.com:8002 : Aussi, une partie de ce code sur la manipulation des maptiles est... grossière...
[12:13] Vincent.Sylvester @hg.zetaworlds.com:8002: If you ever seen var regions not have proper tiles just a single region one instead, that's down to some quirk with throttling of the requests it seems, but beats me as to why, removed all incoming rejection things on Robust and it still happens
[12:13] Vincent.Sylvester @hg.zetaworlds.com:8002 : Avez-vous déjà vu que les varegions  n'ont pas de tuiles appropriées, juste une seule région à la place, il semble que c'est à cause d'une bizarrerie avec l'étranglement des requêtes, mais je ne sais pas pourquoi, j'ai supprimé tous les rejets entrants sur Robust et cela se produit toujours.
[12:13] Ubit Umarov: well on creating a new map, code does delete the old map asset
[12:13] Ubit Umarov : mais osgrid fait en sorte que les assets ne soient jamais supprimés, donc ils restent là :p
[12:13] Ubit Umarov: but osgrid does enforce that assets are never deleted, so they stay there :p
[12:13] Ubit Umarov: but osgrid does enforce that assets are never deleted, so they stay there :p
[12:13] Gavin.Hird @grid.xmir.org:8002: for the version 1 tiles uploaded to the db, it should be possible to create a trigger that zaps the previous record of the same on upload of a new
[12:13] Gavin.Hird @grid.xmir.org:8002 : pour les tuiles de la version 1 téléchargées dans la base de données, il devrait être possible de créer un déclencheur qui supprime l'enregistrement précédent de la même tuile lors du téléchargement d'une nouvelle tuile.
[12:14] Ubit Umarov: in fact we do get a error now with osgrid refusal to delete the asset :)
</pre>
[12:15] Ubit Umarov: ( other grids also.. bc assets services does impose blind rule that assets are never deleted )
= Suppression des assets=
[12:15] Vincent.Sylvester @hg.zetaworlds.com:8002: Which is fun ;)
[https://grimore.org/opensim/database/asset_cleaner Nettoyeur d'assets]
[12:16] Ubit Umarov: well it is a rule
<pre>
[12:16] Ubit Umarov: i many cases a nice security thing
[12:14] Ubit Umarov : en fait nous obtenons une erreur maintenant avec le refus d'osgrid de supprimer les assets :)
[12:16] Ubit Umarov: (disk crashes do delete the assets :P )
[12:15] Ubit Umarov : (les autres grilles aussi... car les services de gestion des assets imposent une règle aveugle selon laquelle les assets ne sont jamais supprimés).
[12:16] Gavin.Hird @grid.xmir.org:8002: till it is not
[12:15] Vincent.Sylvester @hg.zetaworlds.com:8002 : Ce qui est amusant ;)
[12:17] Ubit Umarov: we are luck disks sizes kept growing
[12:16] Ubit Umarov : c'est une règle.
[12:17] Ubit Umarov: for identical costs
[12:16] Ubit Umarov : Dans de nombreux cas, c'est une bonne chose pour la sécurité.
[12:18] Gavin.Hird @grid.xmir.org:8002: while they put in inferior components for the same price
[12:16] Ubit Umarov : (les crashs de disque suppriment les assets :P )
[12:18] Ubit Umarov: even so some grids did delete assets
[12:16] Gavin.Hird @grid.xmir.org:8002 : jusqu'à ce que ce ne soit pas le cas.
[12:18] Gavin.Hird @grid.xmir.org:8002: or change the encoding scheme without telling anyone
[12:17] Ubit Umarov : nous avons de la chance que la taille des disques ne cesse d'augmenter.
[12:18] Ubit Umarov: gavin that is called making business
[12:17] Ubit Umarov : pour des coûts identiques
[12:18] Gavin.Hird @grid.xmir.org:8002: making monkey business
[12:18] Gavin.Hird @grid.xmir.org:8002 : alors qu'ils ont mis des composants de qualité inférieure pour le même prix.
[12:18] Vincent.Sylvester @hg.zetaworlds.com:8002: Backups still a headache with the size and file count, forget versioning on any reasonable scale
[12:18] Ubit Umarov : malgré cela, certaines grilles ont supprimé des assets.
[12:18] Gavin.Hird @grid.xmir.org:8002 : ou changer le schéma d'encodage sans le dire à personne.
[12:18] Ubit Umarov : gavin cela s'appelle faire du business
[12:18] Gavin.Hird @grid.xmir.org:8002 : faire des affaires de singe
[12:18] Vincent.Sylvester @hg.zetaworlds.com:8002 : Les sauvegardes sont toujours un casse-tête avec la taille et le nombre de fichiers, oubliez le versioning à une échelle raisonnable.
[12:18] Andrew Hellershanks: hehe
[12:18] Andrew Hellershanks: hehe
[12:19] Ubit Umarov: business is the art of legally stealing :p
[12:19] Ubit Umarov : les affaires sont l'art de voler légalement :p
[12:19] Andrew Hellershanks: Vincent, that is another issue.
[12:19] Andrew Hellershanks : Vincent, c'est un autre problème.
[12:19] Vincent.Sylvester @hg.zetaworlds.com:8002: 2 million assets into git is the best fireworks I have seen lately
[12:19] Vincent.Sylvester @hg.zetaworlds.com:8002 : 2 millions d'assets dans git est le meilleur feu d'artifice que j'ai vu récemment.
[12:19] Gavin.Hird @grid.xmir.org:8002: why would you do that?
[12:19] Gavin.Hird @grid.xmir.org:8002 : pourquoi ferais-tu cela ?
[12:20] Vincent.Sylvester @hg.zetaworlds.com:8002: To see what would happen
[12:20] Vincent.Sylvester @hg.zetaworlds.com:8002 : Pour voir ce qui se passerait
[12:20] Andrew Hellershanks: Vincent, ouch
[12:20] Andrew Hellershanks: Vincent, ouch
[12:20] Vincent.Sylvester @hg.zetaworlds.com:8002: I spent two days digging in nunit tests I'm allowed some fun lol
[12:20] Vincent.Sylvester @hg.zetaworlds.com:8002 : J'ai passé deux jours à creuser dans les tests nunit. J'ai le droit de m'amuser un peu lol.
[12:20] Andrew Hellershanks: :)
[12:20] Andrew Hellershanks: :)
[12:21] Cuga.Rajal @rajal.org:9000: Probably not relevant to anyone here, but if your DB is small enough you can clean quite a bit of assets with https://grimore.org/opensim/database/asset_cleaner
[12:21] Cuga.Rajal @rajal.org:9000 : Probablement que cela ne concerne personne ici, mais si votre BD est assez petite, vous pouvez nettoyer pas mal d'assets avec https://grimore.org/opensim/database/asset_cleaner.
[12:22] Gavin.Hird @grid.xmir.org:8002: I keep autovacuum on for postgres
[12:22] Gavin.Hird @grid.xmir.org:8002 : Je laisse autovacuum activé pour postgres.
[12:22] Gavin.Hird @grid.xmir.org:8002: it does not clear all, but it zaps quite a bit of old records
[12:22] Gavin.Hird @grid.xmir.org:8002 : ça ne nettoie pas tout, mais ça élimine pas mal de vieux enregistrements.
[12:22] Cuga.Rajal @rajal.org:9000: yes
[12:22] Cuga.Rajal @rajal.org:9000: oui
[12:23] Ubit Umarov: on that.. nothing can delete orphaned assets just because is near impossible to detect them
[12:23] Ubit Umarov : sur ce point... rien ne peut supprimer les assets orphelins juste parce qu'il est presque impossible de les détecter.
[12:23] Gavin.Hird @grid.xmir.org:8002: it never clears anything in assets
[12:23] Gavin.Hird @grid.xmir.org:8002 : cela n'efface jamais rien dans les assets.
[12:23] Gavin.Hird @grid.xmir.org:8002: because as you say, it is impossible for it to know if they are redundant or not
[12:23] Gavin.Hird @grid.xmir.org:8002 : parce que comme tu le dis, il  est impossible de savoir s'ils sont redondants ou non.
[12:23] Andrew Hellershanks: Detecting orphaned assets is not a trivial task.
[12:23] Andrew Hellershanks : La détection des assets orphelins n'est pas une tâche triviale.
[12:24] Gavin.Hird @grid.xmir.org:8002: unless you have explicitly deleted records, then it clears up the debris and shrinks the db szie
[12:24] Gavin.Hird @grid.xmir.org:8002 : à moins que vous n'ayez explicitement supprimé des enregistrements, cela nettoie les déchets et réduit la base de données.
[12:24] Ubit Umarov: we can't scan other assets, inventories or regions ( that may be down) to find references to assets
[12:24] Ubit Umarov : nous ne pouvons pas scanner d'autres assets, inventaires ou régions (qui peuvent être hors service) pour trouver des références aux assets.
[12:24] Vincent.Sylvester @hg.zetaworlds.com:8002: Even knowing where to look, that's still a lot of places to check and that means te queries get heavy very quickly
[12:24] Vincent.Sylvester @hg.zetaworlds.com:8002 : Même en sachant où chercher, il y a toujours beaucoup d'endroits à vérifier et cela signifie que les requêtes deviennent très vite lourdes.
[12:24] Gavin.Hird @grid.xmir.org:8002: like it did today when I deleted 12000 maptiles
[12:24] Gavin.Hird @grid.xmir.org:8002 : comme aujourd'hui lorsque j'ai supprimé 12000 maptiles.
[12:24] Andrew Hellershanks: Asset references could be buried in rezzer or scripts.
[12:24] Andrew Hellershanks : Les références aux assets peuvent être enterrées dans des rezzer ou dans des scripts.
[12:24] Ubit Umarov: map tiles are easy
[12:24] Ubit Umarov : les tuiles de carte sont faciles à utiliser.
[12:25] Gavin.Hird @grid.xmir.org:8002: yeah
[12:25] Gavin.Hird @grid.xmir.org:8002 : Oui.
[12:25] Ubit Umarov: they have a specific asset type
[12:25] Ubit Umarov : ils ont un type de ressource spécifique.
[12:25] Vincent.Sylvester @hg.zetaworlds.com:8002: script generated notecards... there's a horror movie for ya
[12:25] Vincent.Sylvester @hg.zetaworlds.com:8002 : des cartes de notes générées par un script... voilà un film d'horreur pour vous.
[12:25] Gavin.Hird @grid.xmir.org:8002: which type is that?
[12:25] Gavin.Hird @grid.xmir.org:8002 : quel est ce type ?
[12:25] Ubit Umarov: map
[12:25] Ubit Umarov : carte
[12:25] Ubit Umarov: lol
[12:25] Ubit Umarov : lol
[12:25] Gavin.Hird @grid.xmir.org:8002: asset type in the asset table is a number
[12:25] Gavin.Hird @grid.xmir.org:8002 : le type d'asset dans la table des assets est un nombre.
[12:26] Selby.Evans @grid.kitely.com:8002: must go -- bye all
[12:26] Selby.Evans @grid.kitely.com:8002 : je dois y aller -- au revoir à tous
[12:26] Gavin.Hird @grid.xmir.org:8002: bye Selby
[12:26] Gavin.Hird @grid.xmir.org:8002 : au revoir Selby
[12:26] Vincent.Sylvester @hg.zetaworlds.com:8002: Just apply nuke to terrainImage_% works too lol
[12:26] Vincent.Sylvester @hg.zetaworlds.com:8002 : Il suffit d'appliquer nuke au terrainImage_% pour que ça marche aussi.
[12:26] Gavin.Hird @grid.xmir.org:8002: it does
[12:26] Gavin.Hird @grid.xmir.org:8002 : ça marche aussi.
[12:26] Ubit Umarov: oops not type
[12:26] Ubit Umarov : oops pas type.
[12:27] Andrew Hellershanks: Bye Selby.
[12:27] Andrew Hellershanks: Bye Selby.
[12:27] Vincent.Sylvester @hg.zetaworlds.com:8002: I mean if you name your texture that I'll throw coffee beans at you lol
[12:27] Vincent.Sylvester @hg.zetaworlds.com:8002 : Je veux dire que si tu nommes ta texture comme ça, je te jette des grains de café dessus.
[12:27] Andrew Hellershanks: hehe
[12:27] Andrew Hellershanks : hehe
[12:28] Ubit Umarov: it is assetFlags
[12:28] Ubit Umarov : c'est assetFlags.
[12:28] Ubit Umarov: public enum AssetFlags : int
[12:28] Ubit Umarov : public enum AssetFlags : int
     {
     {
         Normal = 0,         // Immutable asset
         Normal = 0, // Actif immuable
         Maptile = 1,       // What it says
         Maptile = 1, // Ce qu'il dit
         Rewritable = 2,     // Content can be rewritten
         Rewritable = 2, // Le contenu peut être réécrit
         Collectable = 4,     // Can be GC'ed after some time
         Collectable = 4, // Peut être GC'ed après un certain temps
     }
     }
[12:28] Andrew Hellershanks: Almost half past now. Any other final comments before I close this meeting?
[12:28] Andrew Hellershanks : Presque la moitié maintenant. Y a-t-il d'autres commentaires avant de clore cette réunion ?
[12:28] Jamie.Jordan @grid.kitely.com:8002: have a great day yall
[12:28] Jamie.Jordan @grid.kitely.com:8002 : Bonne journée à tous.
[12:28] Andrew Hellershanks: Bye, Jamie.
[12:28] Andrew Hellershanks : Au revoir, Jamie.
[12:28] Ubit Umarov: something sadly broken
[12:28] Ubit Umarov : quelque chose de cassé.
[12:29] Ubit Umarov: but it is there on the dbs
[12:29] Ubit Umarov : mais c'est là sur les dbs.
[12:29] Gavin.Hird @grid.xmir.org:8002: ok, good to know
[12:29] Gavin.Hird @grid.xmir.org:8002 : ok, bon à savoir
[12:29] Andrew Hellershanks: I wonder how often assets are created when you are editing a script.
[12:29] Andrew Hellershanks : Je me demande combien de fois les assets sont créés lorsque vous éditez un script.
[12:29] Gavin.Hird @grid.xmir.org:8002: so it is not updated correct=
[12:29] Gavin.Hird @grid.xmir.org:8002 : donc il n'est pas mis à jour correctement=.
[12:30] Ubit Umarov: in fact used to allow deletes
[12:30] Ubit Umarov : en fait, il est utilisé pour autoriser les suppressions.
[12:30] Ubit Umarov: if (m_allowedTypes == AllowedRemoteDeleteTypes.All
[12:30] Ubit Umarov : if (m_allowedTypes == AllowedRemoteDeleteTypes.All
                             || (int)(asset.Flags & AssetFlags.Maptile) != 0)
                             || (int)(asset.Flags & AssetFlags.Maptile) != 0)
                         {
                         {
                             result = m_AssetService.Delete(assetID);
                             result = m_AssetService.Delete(assetID) ;
                         }
                         }
[12:30] Vincent.Sylvester @hg.zetaworlds.com:8002: You don't wanna know the mess it makes Andrew, it makes you want to pull your hair out
[12:30] Vincent.Sylvester @hg.zetaworlds.com:8002 : Tu ne veux pas savoir le bordel que ça fait Andrew, ça te donne envie de t'arracher les cheveux.
[12:30] Ubit Umarov: on some asset services that had not forgotten this ( like new osgrid one )
[12:30] Ubit Umarov : sur certains services de ressources qui n'ont pas oublié cela (comme le nouveau service osgrid).
[12:31] Gavin.Hird @grid.xmir.org:8002: looks like all my maptiles have flag set to 1
[12:31] Gavin.Hird @grid.xmir.org:8002 : on dirait que tous mes maptiles ont un drapeau à 1.
[12:31] Andrew Hellershanks: Vincent. :)  There are times I think it should be able to update an existing asset when you make a change. Other times it would need to create a new asset. Knowing which can be done when is not easy.
[12:31] Andrew Hellershanks : Vincent :)  Il y a des moments où je pense qu'il faudrait pouvoir mettre à jour un asset existant lorsque tu fais un changement. D'autres fois, il faudrait créer un nouvel asset. Savoir quoi faire et quand n'est pas facile.
[12:31] Ubit Umarov: wlel it should be a bitthing
[12:31] Ubit Umarov : bien, cela devrait être une petite chose.
[12:31] Ubit Umarov: but its use is kinda broken
[12:31] Ubit Umarov : mais son utilisation est un peu cassée.
[12:31] Ubit Umarov: bad born code :(
[12:31] Ubit Umarov : mauvais code à la base :(
[12:31] Cuga.Rajal @rajal.org:9000: I should head out too.. Take care everyone
[12:31] Cuga.Rajal @rajal.org:9000 : Je dois y aller aussi... Prenez soin de vous
[12:32] Ubit Umarov: but should work on maps
[12:32] Ubit Umarov : mais il faut travailler sur les cartes.
[12:32] Jagga Meredith: quick question.  Got a grid.  DSTZone = "America/Los_Angeles;Pacific Standard Time" but clock is 8 hours ahead. ideas?
</pre>
[12:32] Gavin.Hird @grid.xmir.org:8002: if writing the flag is correct it can be sued for zapping tiles
= Conclusion et fuseau horaire=
[12:32] Andrew Hellershanks: ok, Cuga. Thanks for dropping by.
<pre>
[12:32] Gavin.Hird @grid.xmir.org:8002: you can be sued for zapping tiles...
[12:32] Jagga Meredith : petite question.  J'ai une grille.  DSTZone = "America/Los_Angeles;Pacific Standard Time" mais l'horloge a 8 heures d'avance. des idées ?
[12:33] Gavin.Hird @grid.xmir.org:8002: Cheers Cuga
[12:32] Gavin.Hird @grid.xmir.org:8002 : si l'écriture du flag est correcte il peut être utilisé pour le nettoyage des tuiles.
[12:33] Andrew Hellershanks: Jagga, sounds like something is set for GMT/UTC time or some function is using the wrong time routine.
[12:32] Andrew Hellershanks : ok, Cuga. Merci d'être passé.
[12:33] Vincent.Sylvester @hg.zetaworlds.com:8002: I dread, but I gotta keep digging into the data structures at some point
[12:32] Gavin.Hird @grid.xmir.org:8002 : vous pouvez être accusé de détruire des tuiles...
[12:33] Gavin.Hird @grid.xmir.org:8002 : Merci Cuga
[12:33] Andrew Hellershanks : Jagga, il semble que quelque chose soit réglé sur l'heure GMT/UTC ou qu'une fonction utilise la mauvaise routine de temps.
[12:33] Vincent.Sylvester @hg.zetaworlds.com:8002 : Je redoute, mais je dois continuer à creuser dans les structures de données à un moment donné.
[12:33] Jagga Meredith: ok
[12:33] Jagga Meredith: ok
[12:34] Andrew Hellershanks: Jagga, where is that DSTZone thing set? I don't recognize that as the way to set timezone. I usually set it at the system level and not in a shell script before running a program.
[12:34] Andrew Hellershanks : Jagga, où se trouve ce truc DSTZone ? Je ne reconnais pas ça comme la façon de définir le fuseau horaire. Je le règle habituellement au niveau du système et non dans un script shell avant de lancer un programme.
[12:36] Andrew Hellershanks: Jagga, check how the timezone has bee set on the system. See what you get when you type 'date' in a terminal window.
[12:36] Andrew Hellershanks : Jagga, vérifie comment le fuseau horaire a été défini sur le système. Regarde ce que tu obtiens lorsque tu tapes 'date' dans une fenêtre de terminal.
[12:37] Andrew Hellershanks: I need to get going so I'll close this meeting for today.
[12:37] Andrew Hellershanks : J'ai besoin d'y aller donc je vais clore cette réunion pour aujourd'hui.
[12:37] Andrew Hellershanks: Thank you all for coming. See you again next week.
[12:37] Andrew Hellershanks : Merci à tous d'être venus. Nous nous reverrons la semaine prochaine.
</pre>
</pre>

Dernière version du 18 novembre 2021 à 19:07

Source

Introduction

[11:00] Vincent.Sylvester @hg.zetaworlds.com:8002 : J'ai entendu des rumeurs sur la disparition de cmake, mais je ne suis pas sûr que ce soit vrai.
[11:00] Vincent.Sylvester @hg.zetaworlds.com:8002 : les viewers ne l'utilisent-ils pas encore ?
[11:00] Andrew Hellershanks : Bonjour à tous.
[11:00] Gavin.Hird @grid.xmir.org:8002 : Je ne peux pas dire que j'ai vu cmake  décliner en ce moment.
[11:01] Gavin.Hird @grid.xmir.org:8002 : je viens de le mettre à jour il y a 2 jours.
[11:01] Gavin.Hird @grid.xmir.org:8002 : Salut Andrew
[11:01] Vincent.Sylvester @hg.zetaworlds.com:8002 : quelque chose à propos d'une mise à jour qui casse quelque chose, je l'ai juste entendu en passant, mais je n'ai aucune idée des détails.
[11:01] Vincent.Sylvester @hg.zetaworlds.com:8002 : les dépendances sont toujours gênantess.
[11:01] Gavin.Hird @grid.xmir.org:8002 : peut-être, IDK
[11:01] Vincent.Sylvester @hg.zetaworlds.com:8002 : Je me souviens avoir essayé de  compiler FS et d'être bloqué en essayant de trouver la version spécifique de python dont il a besoin.
[11:02] Selby.Evans @grid.kitely.com:8002 : bonjour à tous.
[11:02] Ubit Umarov : les mises à jour des outils linux cassent toujours des choses.
[11:02] Ubit Umarov : salut selby.Evans
[11:03] Ubit Umarov : à un moment donné, il faudrait spécifier la version exacte de gcc pour compiler un programme, en particulier pour le noyau linux.

Tests des moteurs de scripts

X :XEngine Y:YEngine 

[11:03] Vincent.Sylvester @hg.zetaworlds.com:8002 : En parlant de casser, j'ai regardé les tests ScriptEngine cassés cette semaine, tous sauf trois semblent fonctionner ... plus ou moins.
[11:04] Vincent.Sylvester @hg.zetaworlds.com:8002 : J'ai copié le truc de X vers Y, j'ai dû ajuster légèrement deux d'entre eux, mais maintenant ils passent aussi.
[11:04] Ubit Umarov : bien, c'est une chose, les tests de script devraient être indépendants du moteur.
[11:04] Ubit Umarov : bien sûr, ils ne peuvent pas l'être car les moteurs sont différents...
[11:04] Ubit Umarov : mais ils devraient l'être.
[11:05] Cuga.Rajal @rajal.org:9000 : Je ne suis pas encore passé de X à Y. Dois-je le faire ?
[11:05] Vincent.Sylvester @hg.zetaworlds.com:8002 : Ce sont les mêmes tests, tout ce que j'ai fait jusqu'à présent, c'est de modifier les paramètres de configuration qu'ils définissent afin qu'ils chargent le bon moteur à tester.
[11:05] Vincent.Sylvester @hg.zetaworlds.com:8002 : Petit changement dans les tests de croisement pour omettre l'événement de changement qui est déclenché au redémarrage de la région puisque dans Y cela fonctionne évidemment correctement alors que dans X cela ne se déclenche pas.
[11:05] Ubit Umarov : certains ont probablement  échoué parce qu'ils étaient fondés sur de mauvaises hypothèses.
[11:06] Ubit Umarov : le changement est déclenché au démarrage de la région ?
[11:06] Jagga Meredith : Je suis heureux avec Yengine
[11:06] Ubit Umarov : Je veux dire que la région a changé ?
[11:06] Vincent.Sylvester @hg.zetaworlds.com:8002 : Les deux que je n'arrive pas à faire fonctionner sont étranges, les erreurs n'ont pas vraiment de sens pour moi pour le moment, mais ce qu'ils testent n'est pas non plus très important.
[11:07] Ubit Umarov : sur notre Jenkins, j'ai désactivé beaucoup de tests.
[11:07] Ubit Umarov : certains parce qu'ils sont simplement mauvais.
[11:07] Ubit Umarov : d'autres pour gagner du temps
[11:07] Vincent.Sylvester @hg.zetaworlds.com:8002 : Ce qui se déclenche est 0x400 qui est le redémarrage de la région, je pense que c'est à prévoir étant donné que la scène est configurée et le script rezze pratiquement instantanément sans attendre donc je suppose qu'il se heurte à cela d'une manière ou d'une autre.
[11:07] Ubit Umarov : en l'état, cette boîte prend environ 5 minutes pour tout faire.
[11:07] Ubit Umarov : je veux dire faire la compilation et le sous-ensemble actuel de tests.
[11:08] Ubit Umarov : le dimanche, cela peut prendre 10 heures :p
[11:08] Vincent.Sylvester @hg.zetaworlds.com:8002 : Ce qui est intéressant, c'est comment dans vscode beaucoup de tests échouent alors qu'ils fonctionnent bien sur Jenkins.
[11:08] Ubit Umarov : c'est quoi vscode ?
[11:08] Ubit Umarov: :p
[11:08] Vincent.Sylvester @hg.zetaworlds.com:8002 : Pas sûr qu'il y ait une différence de version ou une dépendance du système à blâmer ici.
[11:09] Vincent.Sylvester @hg.zetaworlds.com:8002 : Je pense que c'est encore tout Nunit 264
[11:09] Ubit Umarov : certains tests ont des dépendances temporelles.
[11:09] Vincent.Sylvester @hg.zetaworlds.com:8002 : Je soupçonne que cela joue dans cette différence de timing et de dépendance non prise en compte.
[11:10] Vincent.Sylvester @hg.zetaworlds.com:8002 : Principalement sur les tests complexes qui sont encore un peu difficiles à lire, heureusement la plupart des tests du moteur de script sont assez simples donc les corriger n'a pas été difficile.
[11:10] Ubit Umarov : les tests auront besoin d'une révision profonde
[11:10] Ubit Umarov : certains ont été mal faits dès le départ, d'autres sont devenus obsolètes.
[11:11] Ubit Umarov : tous sur une ancienne version de nunit aussi
[11:11] Ubit Umarov : mais certains ont détecté quelques une de mes erreurs... donc certains sont utiles.
[11:11] Vincent.Sylvester @hg.zetaworlds.com:8002 : Je veux dire que la façon dont certains bugs sont arrivés sans qu'un test ne les détecte jamais en témoigne, mais il n'est pas vraiment facile d'en écrire étant donné la nature abstraite dont  cela fonctionnement.
[11:12] Vincent.Sylvester @hg.zetaworlds.com:8002 : Comme faire des trous dans un oignon
[11:12] Ubit Umarov : les tests sont une chose complexe.
[11:13] Ubit Umarov : maintenant tous profitent d'internet et des mises à jour automatiques, transformant l'utilisateur final en testeur.
[11:13] Ubit Umarov : certains font même payer les utilisateurs pour tester, sur les choses dites d'accès anticipé.
[11:14] Vincent.Sylvester @hg.zetaworlds.com:8002 : D'autres lancent simplement et laissent les utilisateurs le réparer.
[11:14] Vincent.Sylvester @hg.zetaworlds.com:8002 : Effectivement, un peu plus facile avec l'open source heh
[11:14] Ubit Umarov : ne pas dire les secrets d'opensim en public vincent.Sylvester
[11:15] Ubit Umarov: errr Ooops
[11:15] Ubit Umarov: ;)

Référence nulle et suppression d'objets encore utilisés

[11:15] Ubit Umarov : alors quelles sont les nouvelles que vous avez sur opensim ?
[11:16] Vincent.Sylvester @hg.zetaworlds.com:8002 : Tu as modifié un truc de la file d'attente prioritaire
[11:16] Vincent.Sylvester @hg.zetaworlds.com:8002 : Je voulais demander de quoi il s'agissait en fait.
[11:16] Jamie.Jordan @grid.kitely.com:8002 : Bonjour à tous.
[11:16] Gavin.Hird @grid.xmir.org:8002 : Salut Jamie
[11:17] Selby.Evans @grid.kitely.com:8002 : salut Jamie
[11:17] Ubit Umarov : dans certains cas, nous avons eu des références nulles qui ont pollué le journal.
[11:17] Andrew Hellershanks : Rien à signaler cette semaine concernant le code d'OpenSim. Il y a eu deux petits changements mais il semble qu'il s'agissait juste d'un nettoyage de code interne.
[11:17] Ubit Umarov : j'ai donc ajouté des try/catch pour "cacher" cela.
[11:18] Ubit Umarov : ces références nulles arrivent parce que la main gauche d'opensim n'a aucune idée de ce que fait la droite.
[11:18] Andrew Hellershanks: :)
[11:18] Ubit Umarov : et certaines choses sont libérées pendant que l'autre les utilise.
[11:18] Ubit Umarov : comme lorsqu'un avatar disparaît.
[11:18] Vincent.Sylvester @hg.zetaworlds.com:8002 : D'où la suppression de certains verrous, je vois
[11:19] Ubit Umarov : les verrous sont un peu différents.
[11:19] Andrew Hellershanks : N'est-ce pas aussi là que les compteurs de réf. entrent en jeu ?
[11:19] Ubit Umarov : J'en ai remplacé certaines par des références à plus faible spectre.
[11:19] Ubit Umarov : quels compteurs de référence ?
[11:20] Ubit Umarov : j'adore les gens qui parlent de... eh bien de quelque part :p
[11:20] Ubit Umarov : ce genre de choses arrive aussi à cause de l'aveuglement total et du multitâche massif.
[11:21] Andrew Hellershanks : Les choses qui sont référencées comme nulles ne sont pas des objets. AFAIK, les objets sont censés avoir (ou peuvent avoir) des compteurs de ref afin que le système sache quand il est sans danger de s'en débarrasser.
[11:21] Ubit Umarov : très difficile à corriger maintenant.
[11:21] Ubit Umarov : le système ne parvient pas à les libérer.
[11:22] Ubit Umarov : et aussi contrairement aux affirmations, beaucoup de choses doivent être nettoyées à la main.
[11:22] Vincent.Sylvester @hg.zetaworlds.com:8002 : bon vieux gc
[11:22] Ubit Umarov : nous n'avons pas accès au nombre de références.
[11:22] Ubit Umarov : ce sont des choses internes.
[11:23] Ubit Umarov : j'ai ajouté plusieurs choses IsDeleted ici et là.
[11:23] Ubit Umarov : mais je ne peux toujours pas résoudre tous les problèmes, certains à cause du multitâche.
[11:23] Andrew Hellershanks : C'est vrai. Si le système doit nettoyer les objets en fonction du nombre de références, il devrait supprimer l'objet tant qu'il est encore utilisé. Si le code fait un nettoyage manuel à un ou plusieurs endroits, alors tout est perdu.
[11:24] Ubit Umarov : les choses sont là quand elles sont testées, puis elles disparaissent.
[11:24] Vincent.Sylvester @hg.zetaworlds.com:8002 : Je me demande si le fait d'être dans la pile udp est dû à des processeurs plus rapides et à des réseaux qui montrent maintenant des choses cachées par des retards dans le passé, j'ai certainement eu plus de problèmes de timing sur mon nouvel ordinateur que sur l'ancien.
[11:24] Ubit Umarov : et nous ne pouvons pas mettre des verrous partout.
[11:25] Ubit Umarov : certaines de ces choses ont commencé à apparaître quand j'ai ajouté une méthode de traitement des choses que GC ne libère jamais.
[11:25] Ubit Umarov : comme toutes les choses du framework qui ont la méthode Dispose()
[11:26] Ubit Umarov : qu'opensim n'a jamais éliminé, donc pas de références nulles visibles, bien sûr les choses sont restées là, perdues pour toujours.
[11:27] Vincent.Sylvester @hg.zetaworlds.com:8002 : Eh bien, si il élimine alors réellement et mono voodoo ne refuse pas heh  
[11:28] Ubit Umarov : comme je l'ai dit, ce changement a aussi déplacé certains verrous pour qu'ils aient un impact sur moins de code, juste celui qui en a besoin.
[11:28] Ubit Umarov : ouais GC ne parvient pas à libérer la mémoire qu'il était supposé libérer.
[11:28] Ubit Umarov : nous pouvons toujours voir une région décider d'utiliser 20GB de ram.
[11:29] Vincent.Sylvester @hg.zetaworlds.com:8002 : Je me demande si une partie de ce problème n'est pas dû au fait que le code est vieux et qu'il repose implicitement sur des délais datant de l'époque où le processeur n'était pas si puissant.
[11:29] Ubit Umarov : seulement quelques problèmes de timing ... pas ce genre de choses.
[11:29] Ubit Umarov : les téléportations sont un problème de timing.

Problèmes avec l'événement 'timer'

Les événements timer des scripts sont très imprécis sur une période donnée. 

[11:29] Vincent.Sylvester @hg.zetaworlds.com:8002 : J'ai effectué quelques tests concernant la divergence des événements timer et j'ai constaté qu'elle était liée à la vitesse du processeur, ce qui est intéressant.
[11:30] Vincent.Sylvester @hg.zetaworlds.com:8002 : On pourrait potentiellement mesurer la vitesse du processeur en fonction de la vitesse à laquelle l'événement du timer ajoute une seconde.
[11:30] Ubit Umarov : mais opensim a un tas de problèmes potentiels de timing.
[11:30] Ubit Umarov : surtout en raison de son  multitâche incontrôlé.
[11:30] Ubit Umarov: design
[11:31] Ubit Umarov : je crains que sur une région occupée, les threads passent plus de temps à attendre les verrous qu'à faire des choses.
[11:31] Ubit Umarov : au moins beaucoup de temps :)
[11:32] Vincent.Sylvester @hg.zetaworlds.com:8002 : Vous ne le remarquerez pas, le viewer descendrait à des fps à un chiffre de toute façon.
[11:32] Ubit Umarov : les viewers sont encore principalement des threads uniques.
[11:32] Ubit Umarov : LL est enfin en train de déplacer certaines choses vers d'autres threads.
[11:33] Ubit Umarov : c'est le contraire de l'utilisation des multi-cœurs... ne pas les utiliser :P
[11:34] Ubit Umarov : opensim a été fait sur l'autre condition.. utiliser les cœurs que les cpus auront en 2100.
[11:34] Andrew Hellershanks : J'ai remarqué un problème de timing la semaine dernière dans l'OS lié au mouvement des keyframe.
[11:35] Andrew Hellershanks : Une séquence d'étapes qui est censée être réalisée en 64 secondes en prend plus de 68.
[11:36] Andrew Hellershanks : Je n'ai pas eu le temps de regarder le code du système d'exploitation pour avoir une idée de la raison pour laquelle il y a une différence entre le timing attendu et le timing réel.
[11:36] Vincent.Sylvester @hg.zetaworlds.com:8002 : En supposant que cela utilise probablement le même contrôle de temporisation que l'événement timer, qui a tendance à se désynchroniser assez rapidement, en particulier lorsque vous commencez à ajouter du code à l'événement lui-même.
[11:37] Andrew Hellershanks : AFAICR, dans la 0.8.2 le timing était parfait ou si proche que je n'ai pas remarqué d'écart.
[11:37] Ubit Umarov : comme je l'ai dit il y a quelques mois, j'ai refait le code entier de KFM.
[11:37] Ubit Umarov : mais sa sérialisation est incompatible avec les anciennes versions.
[11:37] Ubit Umarov : donc... yeach... en attente :P
[11:38] Vincent.Sylvester @hg.zetaworlds.com:8002 : Lorsque vous chronométrez ces choses, assurez-vous d'utiliser des flottants stricts, comme dans 3.0f et il est logique d'ajuster pour la différence de temps initiale, disons 2.97f par exemple, cela vous donne généralement de meilleurs résultats.
[11:38] Ubit Umarov : oui andrew nous savons tous que la 0.8.2 était parfaite.
[11:38] Ubit Umarov : bahh
[11:38] Vincent.Sylvester @hg.zetaworlds.com:8002 : A partir de là, vous pourrez avoir une meilleure idée de l'origine du problème.
[11:39] Vincent.Sylvester @hg.zetaworlds.com:8002 : J'ai creusé un peu dans le code du timer, je pense qu'il y a une certaine précision perdue sur une conversion de type, mais je n'ai pas eu le temps de vraiment jouer avec ça.
[11:39] Andrew Hellershanks : Vincent, que veux-tu dire par la différence de timing initial.
[11:39] Ubit Umarov : en fait, la 0.9 fait kfm, alors que la 0.8 faisait... quelque chose.
[11:40] Ubit Umarov : Peu importe.
[11:40] Ubit Umarov : déposer un mantis, dans un for que les autres peuvent repo.
[11:40] Ubit Umarov : dans un form...
[11:40] Vincent.Sylvester @hg.zetaworlds.com:8002 : Si vous exécutez disons un événement timer toutes les 3 secondes, il ne commence pas initialement à 3, mais ajoute disons 0,03 à cette valeur.
[11:40] Vincent.Sylvester @hg.zetaworlds.com:8002 : Probablement à cause du temps d'exécution du code lui-même
[11:41] Vincent.Sylvester @hg.zetaworlds.com:8002 : Lorsque vous ajustez sur cela, vous finissez par obtenir un timing plus précis pour plus longtemps.
[11:41] Vincent.Sylvester @hg.zetaworlds.com:8002 : Je suppose que cela corrige une partie de la précision perdue quelque part dans le pipe.
[11:42] Vincent.Sylvester @hg.zetaworlds.com:8002 : J'ai l'impression que si j'ajoute une sortie de débogage à l'événement timer pour voir combien de temps il prend lui-même pour s'exécuter, cela ne fera que fausser davantage les résultats.
[11:42] Ubit Umarov : certaines choses du timing ont une dérive intensionnelle.
[11:42] Ubit Umarov: intencional
[11:42] Ubit Umarov : cela s'appelle la dilatation...
[11:43] Ubit Umarov : il n'est pas comptabilisé.
[11:43] Vincent.Sylvester @hg.zetaworlds.com:8002 : OpenSim, par nature, ne tourne jamais complètement au ralenti, donc vous avez aussi une milliseconde ici ou là.
[11:44] Ubit Umarov : nous ne pouvons pas tenir compte de la dilatation du temps comme sl, aussi à cause du multitâche.
[11:44] Ubit Umarov : donc chaque partie dérive à sa façon.
[11:44] Vincent.Sylvester @hg.zetaworlds.com:8002 : C'est comme le truc des particules quantiques, dès que l'on essaie d'ajouter du code pour déboguer les choses, les résultats sont encore plus faussés.
[11:44] Ubit Umarov : sur mon nouveau KFM, tout le code est exécuté sur les battements de cœur.
[11:45] Ubit Umarov : ainsi son timing sera plus synchrone avec la pulsation de la région.
[11:46] Ubit Umarov : j'ai juste besoin de comprendre comment convertir l'ancienne vers la nouvelle sérialisation.
[11:46] Ubit Umarov : pour les passages de régions
[11:46] Vincent.Sylvester @hg.zetaworlds.com:8002 : Je te souhaite bonne chance pour cela, ça ne semble pas être une tâche des plus amusantes :)
[11:50] Andrew Hellershanks : Un supplément de 0,03 par seconde expliquerait environ la moitié de l'erreur de temps d'exécution que je vois. Je vais devoir le recalculer pour vérifier la différence réelle. Je pensais l'avoir noté sur un bout de papier près de moi mais je ne le trouve pas.
[11:51] Vincent.Sylvester @hg.zetaworlds.com:8002 : http://opensimulator.org/mantis/view.php?id=3862 C'est de cela que je parle Andrew
[11:51] Vincent.Sylvester @hg.zetaworlds.com:8002 : Des résultats intéressants dont je n'ai pas encore compris le pourquoi, mais qui m'ont aidé à comprendre certains des problèmes de timer que j'ai rencontrés.
[11:52] Vincent.Sylvester @hg.zetaworlds.com:8002 : Cela dit, comme Ubit l'a mentionné, il est préférable de ne pas compter sur l'événement timer pour la précision.
[11:52] Vincent.Sylvester @hg.zetaworlds.com:8002 : événement timer, seulement légèrement plus précis que votre horloge personnelle.lol
[11:52] Ubit Umarov : la précision de l'heure des hommes ne s'applique pas aux PC.
[11:52] Ubit Umarov : sauf sur les périphériques spéciaux du noyau.
[11:53] Andrew Hellershanks : Vincent, cela semble similaire au problème que j'ai.
[11:53] Ubit Umarov : c'est pourquoi un contrôleur de voiture ne fonctionne pas sous windows ou linux.
[11:53] Gavin.Hird @grid.xmir.org:8002: lol
[11:53] Ubit Umarov : ( l'affichage peut.. ofc )
[11:54] Ubit Umarov : et il y a aussi des versions RTOS de linux.
[11:54] Gavin.Hird @grid.xmir.org:8002 : n'avez-vous pas vu le logo de Windows XP lors du crash du contrôleur de la voiture Tesla ?
[11:54] Ubit Umarov : XP toujours ?
[11:54] Vincent.Sylvester @hg.zetaworlds.com:8002 : qu'est-ce que le temps, juste un concept, tout ce qu'il fait c'est vous rendre vieux :)
[11:54] Ubit Umarov : mais je parie que c'est sur les appareils de l'interface utilisateur.
[11:54] Gavin.Hird @grid.xmir.org:8002 : Je l'ai au moins vu sur les ATM.
[11:54] Andrew Hellershanks : Je pourrais compenser en ajustant le temps de cycle mais cela devient un problème quand on ne sait pas si une grille a fait quelque chose dans son code pour résoudre ce problème. Si c'est le cas, le correctif nécessaire pour une grille pourrait perturber les choses dans une autre.
[11:54] Gavin.Hird @grid.xmir.org:8002 : très récemment.
[11:55] Vincent.Sylvester @hg.zetaworlds.com:8002 : huh par ici ils les font juste exploser dernièrement.
[11:55] Ubit Umarov : ( par contrôleur je ne voulais pas dire les choses de l'interface utilisateur des voitures... mais les choses de bas niveau OC ECC etc.
[11:56] Ubit Umarov : voir par exemple
[11:56] Ubit Umarov : un framework (même un timer win32)
[11:56] Ubit Umarov : ce qu'il fait est de mettre sur le pool de travail des threads une demande d'exécution du code d'événement du timer.
[11:57] Ubit Umarov : "Un jour, quand il y aura un fil de discussion libre pour le faire.
[11:58] Ubit Umarov : cela ajoute juste un retard de plusieurs ms (au moins 15 sous Windows).
[11:58] Vincent.Sylvester @hg.zetaworlds.com:8002 : Si vous voulez vous amuser avec la synchronisation, changez simplement votre source d'horloge de tsc à hpet, mais sauvegardez d'abord vos données.
[11:59] Andrew Hellershanks : Wow. Cette heure est passée très vite aujourd'hui. Est-ce que quelqu'un voulait parler d'un autre sujet avant de conclure ?
[11:59] Ubit Umarov : bien et c'est une différence entre les consoles de jeux et les PC.
[11:59] Ubit Umarov : ( ou devrait l'être..)

Tuiles de carte (maptiles)

[11:59] Gavin.Hird @grid.xmir.org:8002 : il y a eu beaucoup de discussions sur les miniatures des cartes.
[12:00] Gavin.Hird @grid.xmir.org:8002 : stockage dans la base de données.
[12:00] Ubit Umarov : le stockage dans la base de données est en fait obsolète.
[12:00] Andrew Hellershanks : N'oubliez pas la conférence de la communauté Open Simulator qui aura lieu la fin de semaine du 11 et 12 décembre. Assurez-vous de marquer vos calendriers.
[12:00] Ubit Umarov : au moins pour l'utilisation des viewers.
[12:00] Gavin.Hird @grid.xmir.org:8002 : quelqu'un a suggéré un script élaboré pour les effacer, mais il suffit d'une simple requête SQL.
[12:00] Ubit Umarov : Elles sont nettoyées à chaque redémarrage de région.
[12:01] Ubit Umarov : bien sûr, pas pour les régions mortes :)
[12:01] Ubit Umarov : mais le problème est aussi sur le disque de service de la carte.
[12:01] Ubit Umarov : et ce n'est PAS facile.
[12:01] Ubit Umarov : on ne peut pas y aller et simplement supprimer les fichiers de la région.
[12:02] Gavin.Hird @grid.xmir.org:8002 : non ?
[12:02] Vincent.Sylvester @hg.zetaworlds.com:8002 : supprimer tous les terrainImage_% à peu près oui, mais si vous stockez les ressources dans des fichiers, vous devez trouver les fichiers et les supprimer également, ce qui n'est pas aussi facile, et puis vous avez toujours le problème des différentes échelles des tuiles de la carte qui ne peuvent être modifiées que lorsque de nouvelles tuiles sont soumises, il n'y a pas de "cut this one out".
[12:02] Ubit Umarov: parce que les miniatures de la carte ont des niveaux
[12:02] Ubit Umarov : la haute résolution est une tuile de région.
[12:02] Ubit Umarov : moins est une image composée de 4 régions.
[12:02] Ubit Umarov : moins... etc...
[12:02] Ubit Umarov : je ne me souviens pas du nombre de niveaux.
[12:02] Gavin.Hird @grid.xmir.org:8002 : Je viens de nettoyer 2 ans de miniatures
[12:02] Vincent.Sylvester @hg.zetaworlds.com:8002 : J'ai écrit un code pour télécharger "l'eau" à l'arrêt, mais cela ne fonctionne pas très bien parce que les échelles des maptiles sont créées async par rapport au téléchargement.
[12:03] Gavin.Hird @grid.xmir.org:8002 : J'ai réduit la base de données d'environ 8 Go.
[12:03] Ubit Umarov : c'est un code lourd en fait.
[12:03] Ubit Umarov : pour reconstruire toutes ces tuiles de niveau du zoom.
[12:03] Vincent.Sylvester @hg.zetaworlds.com:8002 : Oui, les maptiles sont créés, mais pas mis à jour dans la base de données, donc un nettoyage régulier doit être effectué.
12:04] Vincent.Sylvester @hg.zetaworlds.com:8002 : J'ai un code interne qui parle aux régions pour demander de nouvelles tuiles après que je les ai toutes détruites, mais cela donne du fil à retordre à Robust.
[12:04] Ubit Umarov : encore une fois, ce qui est sur les bases de données en tant qu'assets sont les ancienes maptiles pour les anciens viewers v1.
[12:04] Ubit Umarov : ( chose que nous utilisons ailleurs aussi )
[12:04] Vincent.Sylvester @hg.zetaworlds.com:8002: oui
[12:04] Ubit Umarov : ceux que les viewers utilisent pour la carte sont les plus complexes dont je viens de parler.
[12:05] Vincent.Sylvester @hg.zetaworlds.com:8002 : C'est un bazar et il n'est pas facile de trouver une bonne solution pour le résoudre.
[12:05] Ubit Umarov : chaque fois que nous changeons une région, nous devons traiter plusieurs images.
[12:05] Vincent.Sylvester @hg.zetaworlds.com:8002 : ... et il y a aussi une mauvaise collecte des données résiduelles dans la base de données.
[12:05] Ubit Umarov : pour tous ces niveaux de zoom
[12:05] Ubit Umarov : vous pouvez  voir le code sur le mapservice.
[12:06] Ubit Umarov : les assets sont un problème facile à résoudre
[12:06] Ubit Umarov : ou plus facile.
[12:06] Vincent.Sylvester @hg.zetaworlds.com:8002 : Je veux dire que télécharger de l'eau à l'arrêt "fonctionne" pour effacer les niveaux, mais à son tour cela crée plus de désordre dans la base de données.
[12:07] Vincent.Sylvester @hg.zetaworlds.com:8002 : Et Robust a besoin d'eux pour créer les dimensions, donc ne peut pas les supprimer immédiatement non plus.
[12:07] Ubit Umarov : pour supporter quelque chose comme ça, on devrait juste utiliser un asset de carte fixe.
[12:07] Ubit Umarov : ne pas uploader une nouvelle carte d'eau.
[12:08] Vincent.Sylvester @hg.zetaworlds.com:8002: Yep
[12:08] Ubit Umarov : mais plusieurs grilles veulent que les régions soient sur la carte même si elles sont déconnectées.
[12:09] Ubit Umarov : en fait sur plusieurs grilles comme kitely les régions sont normalement déconnectées jusqu'à ce que quelqu'un y aille.
[12:09] Ubit Umarov : y compris en cliquant sur la carte :)
[12:09] Vincent.Sylvester @hg.zetaworlds.com:8002 : Une bonne solution serait que Robust passe régulièrement en revue la liste des régions et demande de nouvelles tuiles, si aucune n'est donnée, il suppose qu'il y a de l'eau et reconstruit, mais cela lui imposerait une énorme charge.
[12:09] Ubit Umarov : il n'est même pas facile de définir quand effacer les tuiles de la carte.
[12:09] Vincent.Sylvester @hg.zetaworlds.com:8002 :De plus, dire quelque chose  à  Robust  avec "régularité" est... amusant...
[12:10] Ubit Umarov : une simple grille peut avoir ses propres besoins.
[12:10] Ubit Umarov : donc le manuel est une solution pour le moment :)
[12:11] Andrew Hellershanks : Je me suis parfois demandé s'il ne devrait pas y avoir un programme externe pour gérer la génération des maptiles. Cela aurait probablement ses propres problèmes.
[12:11] Vincent.Sylvester @hg.zetaworlds.com:8002 : En fin de compte, le désir est là pour la suppression étant donné qu'il existe des débuts de code dans cette direction et c'est un bon standard de programmation pour s'assurer qu'un morceau de logiciel ne crée pas de quantités massives de données orphelines.
[12:11] Vincent.Sylvester @hg.zetaworlds.com:8002 : Mais oui, le truc de la définition
[12:12] Vincent.Sylvester @hg.zetaworlds.com:8002 : Aussi, une partie de ce code sur la manipulation des maptiles est... grossière...
[12:13] Vincent.Sylvester @hg.zetaworlds.com:8002 : Avez-vous déjà vu que les varegions  n'ont pas de tuiles appropriées, juste une seule région à la place, il semble que c'est à cause d'une bizarrerie avec l'étranglement des requêtes, mais je ne sais pas pourquoi, j'ai supprimé tous les rejets entrants sur Robust et cela se produit toujours.
[12:13] Ubit Umarov : mais osgrid fait en sorte que les assets ne soient jamais supprimés, donc ils restent là :p
[12:13] Ubit Umarov: but osgrid does enforce that assets are never deleted, so they stay there :p
[12:13] Gavin.Hird @grid.xmir.org:8002 : pour les tuiles de la version 1 téléchargées dans la base de données, il devrait être possible de créer un déclencheur qui supprime l'enregistrement précédent de la même tuile lors du téléchargement d'une nouvelle tuile.

Suppression des assets

Nettoyeur d'assets 

[12:14] Ubit Umarov : en fait nous obtenons une erreur maintenant avec le refus d'osgrid de supprimer les assets :)
[12:15] Ubit Umarov : (les autres grilles aussi... car les services de gestion des assets imposent une règle aveugle selon laquelle les assets ne sont jamais supprimés).
[12:15] Vincent.Sylvester @hg.zetaworlds.com:8002 : Ce qui est amusant ;)
[12:16] Ubit Umarov : c'est une règle.
[12:16] Ubit Umarov : Dans de nombreux cas, c'est une bonne chose pour la sécurité.
[12:16] Ubit Umarov : (les crashs de disque suppriment les assets :P )
[12:16] Gavin.Hird @grid.xmir.org:8002 : jusqu'à ce que ce ne soit pas le cas.
[12:17] Ubit Umarov : nous avons de la chance que la taille des disques ne cesse d'augmenter.
[12:17] Ubit Umarov : pour des coûts identiques
[12:18] Gavin.Hird @grid.xmir.org:8002 : alors qu'ils ont mis des composants de qualité inférieure pour le même prix.
[12:18] Ubit Umarov : malgré cela, certaines grilles ont supprimé des assets.
[12:18] Gavin.Hird @grid.xmir.org:8002 : ou changer le schéma d'encodage sans le dire à personne.
[12:18] Ubit Umarov : gavin cela s'appelle faire du business
[12:18] Gavin.Hird @grid.xmir.org:8002 : faire des affaires de singe
[12:18] Vincent.Sylvester @hg.zetaworlds.com:8002 : Les sauvegardes sont toujours un casse-tête avec la taille et le nombre de fichiers, oubliez le versioning à une échelle raisonnable.
[12:18] Andrew Hellershanks: hehe
[12:19] Ubit Umarov : les affaires sont l'art de voler légalement :p
[12:19] Andrew Hellershanks : Vincent, c'est un autre problème.
[12:19] Vincent.Sylvester @hg.zetaworlds.com:8002 : 2 millions d'assets dans git est le meilleur feu d'artifice que j'ai vu récemment.
[12:19] Gavin.Hird @grid.xmir.org:8002 : pourquoi ferais-tu cela ?
[12:20] Vincent.Sylvester @hg.zetaworlds.com:8002 : Pour voir ce qui se passerait
[12:20] Andrew Hellershanks: Vincent, ouch
[12:20] Vincent.Sylvester @hg.zetaworlds.com:8002 : J'ai passé deux jours à creuser dans les tests nunit. J'ai le droit de m'amuser un peu lol.
[12:20] Andrew Hellershanks: :)
[12:21] Cuga.Rajal @rajal.org:9000 : Probablement que cela ne concerne personne ici, mais si votre BD est assez petite, vous pouvez nettoyer pas mal d'assets avec https://grimore.org/opensim/database/asset_cleaner.
[12:22] Gavin.Hird @grid.xmir.org:8002 : Je laisse autovacuum activé pour postgres.
[12:22] Gavin.Hird @grid.xmir.org:8002 : ça ne nettoie pas tout, mais ça élimine pas mal de vieux enregistrements.
[12:22] Cuga.Rajal @rajal.org:9000: oui
[12:23] Ubit Umarov : sur ce point... rien ne peut supprimer les assets orphelins juste parce qu'il est presque impossible de les détecter.
[12:23] Gavin.Hird @grid.xmir.org:8002 : cela n'efface jamais rien dans les assets.
[12:23] Gavin.Hird @grid.xmir.org:8002 : parce que comme tu le dis, il  est impossible de savoir s'ils sont redondants ou non.
[12:23] Andrew Hellershanks : La détection des assets orphelins n'est pas une tâche triviale.
[12:24] Gavin.Hird @grid.xmir.org:8002 : à moins que vous n'ayez explicitement supprimé des enregistrements, cela nettoie les déchets et réduit la base de données.
[12:24] Ubit Umarov : nous ne pouvons pas scanner d'autres assets, inventaires ou régions (qui peuvent être hors service) pour trouver des références aux assets.
[12:24] Vincent.Sylvester @hg.zetaworlds.com:8002 : Même en sachant où chercher, il y a toujours beaucoup d'endroits à vérifier et cela signifie que les requêtes deviennent très vite lourdes.
[12:24] Gavin.Hird @grid.xmir.org:8002 : comme aujourd'hui lorsque j'ai supprimé 12000 maptiles.
[12:24] Andrew Hellershanks : Les références aux assets peuvent être enterrées dans des rezzer ou dans des scripts.
[12:24] Ubit Umarov : les tuiles de carte sont faciles à utiliser.
[12:25] Gavin.Hird @grid.xmir.org:8002 : Oui.
[12:25] Ubit Umarov : ils ont un type de ressource spécifique.
[12:25] Vincent.Sylvester @hg.zetaworlds.com:8002 : des cartes de notes générées par un script... voilà un film d'horreur pour vous.
[12:25] Gavin.Hird @grid.xmir.org:8002 : quel est ce type ?
[12:25] Ubit Umarov : carte
[12:25] Ubit Umarov : lol
[12:25] Gavin.Hird @grid.xmir.org:8002 : le type d'asset dans la table des assets est un nombre.
[12:26] Selby.Evans @grid.kitely.com:8002 : je dois y aller -- au revoir à tous
[12:26] Gavin.Hird @grid.xmir.org:8002 : au revoir Selby
[12:26] Vincent.Sylvester @hg.zetaworlds.com:8002 : Il suffit d'appliquer nuke au terrainImage_% pour que ça marche aussi.
[12:26] Gavin.Hird @grid.xmir.org:8002 : ça marche aussi.
[12:26] Ubit Umarov : oops pas type.
[12:27] Andrew Hellershanks: Bye Selby.
[12:27] Vincent.Sylvester @hg.zetaworlds.com:8002 : Je veux dire que si tu nommes ta texture comme ça, je te jette des grains de café dessus.
[12:27] Andrew Hellershanks : hehe
[12:28] Ubit Umarov : c'est assetFlags.
[12:28] Ubit Umarov : public enum AssetFlags : int
    {
        Normal = 0, // Actif immuable
        Maptile = 1, // Ce qu'il dit
        Rewritable = 2, // Le contenu peut être réécrit
        Collectable = 4, // Peut être GC'ed après un certain temps
    }
[12:28] Andrew Hellershanks : Presque la moitié maintenant. Y a-t-il d'autres commentaires avant de clore cette réunion ?
[12:28] Jamie.Jordan @grid.kitely.com:8002 : Bonne journée à tous.
[12:28] Andrew Hellershanks : Au revoir, Jamie.
[12:28] Ubit Umarov : quelque chose de cassé.
[12:29] Ubit Umarov : mais c'est là sur les dbs.
[12:29] Gavin.Hird @grid.xmir.org:8002 : ok, bon à savoir
[12:29] Andrew Hellershanks : Je me demande combien de fois les assets sont créés lorsque vous éditez un script.
[12:29] Gavin.Hird @grid.xmir.org:8002 : donc il n'est pas mis à jour correctement=.
[12:30] Ubit Umarov : en fait, il est utilisé pour autoriser les suppressions.
[12:30] Ubit Umarov : if (m_allowedTypes == AllowedRemoteDeleteTypes.All
                            || (int)(asset.Flags & AssetFlags.Maptile) != 0)
                        {
                            result = m_AssetService.Delete(assetID) ;
                        }
[12:30] Vincent.Sylvester @hg.zetaworlds.com:8002 : Tu ne veux pas savoir le bordel que ça fait Andrew, ça te donne envie de t'arracher les cheveux.
[12:30] Ubit Umarov : sur certains services de ressources qui n'ont pas oublié cela (comme le nouveau service osgrid).
[12:31] Gavin.Hird @grid.xmir.org:8002 : on dirait que tous mes maptiles ont un drapeau à 1.
[12:31] Andrew Hellershanks : Vincent :)  Il y a des moments où je pense qu'il faudrait pouvoir mettre à jour un asset existant lorsque tu fais un changement. D'autres fois, il faudrait créer un nouvel asset. Savoir quoi faire et quand n'est pas facile.
[12:31] Ubit Umarov : bien, cela devrait être une petite chose.
[12:31] Ubit Umarov : mais son utilisation est un peu cassée.
[12:31] Ubit Umarov : mauvais code à la base :(
[12:31] Cuga.Rajal @rajal.org:9000 : Je dois y aller aussi... Prenez soin de vous
[12:32] Ubit Umarov : mais il faut travailler sur les cartes.

Conclusion et fuseau horaire

[12:32] Jagga Meredith : petite question.  J'ai une grille.  DSTZone = "America/Los_Angeles;Pacific Standard Time" mais l'horloge a 8 heures d'avance. des idées ?
[12:32] Gavin.Hird @grid.xmir.org:8002 : si l'écriture du flag est correcte il peut être utilisé pour le nettoyage des tuiles.
[12:32] Andrew Hellershanks : ok, Cuga. Merci d'être passé.
[12:32] Gavin.Hird @grid.xmir.org:8002 : vous pouvez être accusé de détruire des tuiles...
[12:33] Gavin.Hird @grid.xmir.org:8002 : Merci Cuga
[12:33] Andrew Hellershanks : Jagga, il semble que quelque chose soit réglé sur l'heure GMT/UTC ou qu'une fonction utilise la mauvaise routine de temps.
[12:33] Vincent.Sylvester @hg.zetaworlds.com:8002 : Je redoute, mais je dois continuer à creuser dans les structures de données à un moment donné.
[12:33] Jagga Meredith: ok
[12:34] Andrew Hellershanks : Jagga, où se trouve ce truc DSTZone ? Je ne reconnais pas ça comme la façon de définir le fuseau horaire. Je le règle habituellement au niveau du système et non dans un script shell avant de lancer un programme.
[12:36] Andrew Hellershanks : Jagga, vérifie comment le fuseau horaire a été défini sur le système. Regarde ce que tu obtiens lorsque tu tapes 'date' dans une fenêtre de terminal.
[12:37] Andrew Hellershanks : J'ai besoin d'y aller donc je vais clore cette réunion pour aujourd'hui.
[12:37] Andrew Hellershanks : Merci à tous d'être venus. Nous nous reverrons la semaine prochaine.
Récupérée de « https://cogito.no-ip.info/cogito/OSWiki/index.php?title=Réunion_du_16-11-2021&oldid=3813 »