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

De OSWiki
Aller à la navigation Aller à la recherche
 
(7 versions intermédiaires par le même utilisateur non affichées)
Ligne 126 : Ligne 126 :
[11:22] Objet : Script en cours d'exécution
[11:22] Objet : Script en cours d'exécution
</pre>
</pre>
= Incidence des scripts =
= Incidence des scripts sur une région =
<pre>
<pre>
[11:23] Vincent.Sylvester @hg.zetaworlds.com:8002 : Ce n'est pas aussi mauvais que vous le pensez, j'ai eu près de 40 personnes sur une région avec environ 30 lumières de chaque couleur et une lumière ponctuelle ainsi que quelques changeurs de couleur supplémentaires, etc., ça a mieux fonctionné qu'il y a 5 ans, c'est certain.
[11:23] Vincent.Sylvester @hg.zetaworlds.com:8002 : Ce n'est pas aussi mauvais que vous le pensez, j'ai eu près de 40 personnes sur une région avec environ 30 lumières de chaque couleur et une lumière ponctuelle ainsi que quelques changeurs de couleur supplémentaires, etc., ça a mieux fonctionné qu'il y a 5 ans, c'est certain.
Ligne 162 : Ligne 162 :
[11:31] Vincent.Sylvester @hg.zetaworlds.com:8002 : Bonne mesure de l'horloge du processeur en voyant à quelle vitesse la lumière change.
[11:31] Vincent.Sylvester @hg.zetaworlds.com:8002 : Bonne mesure de l'horloge du processeur en voyant à quelle vitesse la lumière change.
</pre>
</pre>
= Nouvelles dans OpenSim cette semaine =  
 
= Nouvelles d'OpenSim cette semaine =  
* Certains paramètres qui étaient auparavant uniquement disponibles pour XEngine sont maintenant disponibles dans YEngine.
* Certains problèmes de longue date ont finalement été pris en compte,
* Une correction de bogue effectuée la semaine dernière empêche certaines prims de changer de type lorsqu'elles sont configurées en flex avec llSetPrimitiveParams. (mantis [http://opensimulator.org/mantis/view.php?id=7896 7896] et [http://opensimulator.org/mantis/view.php?id=7910 7910]).
* optimisations dans le code pour économiser quelques cycles d'horloge.
* écriture d'un test qui fonctionne sur les deux moteurs de scripts [[XEngine]] et [[YEngine]]
* [http://wiki.secondlife.com/wiki/LSL_Test_Harness LSL Test Harness]
<pre>
<pre>
[11:31] Ubit Umarov : ok, et quelles sont les nouvelles que vous avez sur opensim ?
[11:31] Ubit Umarov : ok, et quelles sont les nouvelles que vous avez sur opensim ?
[11:31] Ubit Umarov: :)
[11:31] Ubit Umarov: :)
[11:32] Andrew Hellershanks : Pas beaucoup de changements cette semaine mais quelques uns.
[11:32] Andrew Hellershanks : Pas beaucoup de changements cette semaine mais quelques uns.
[11:33] Andrew Hellershanks: Some settings that were previously only available for XEngine are now available in YEngine.
[11:33] Andrew Hellershanks : Certains paramètres qui étaient auparavant uniquement disponibles pour XEngine sont maintenant disponibles dans YEngine.
[11:33] Vincent.Sylvester @hg.zetaworlds.com:8002: Mostly bugfixing which I love to see, some long standing issues even that finally get attention, just wish mantis was a bit more flexible in all that
[11:33] Vincent.Sylvester @hg.zetaworlds.com:8002 : La plupart des corrections de bogues que j'aime voir, certains problèmes de longue date ont finalement été pris en compte, mais j'aimerais que mantis soit un peu plus flexible avec tout cela.
[11:33] Vincent.Sylvester @hg.zetaworlds.com:8002: Can't really establish a "to be tested" or "can't fix right now" status
[11:33] Vincent.Sylvester @hg.zetaworlds.com:8002 : On ne peut pas vraiment établir de statut "à tester" ou "ne peut pas être corrigé maintenant".
[11:33] Andrew Hellershanks: There were some changes related to CO2 but I don't know what is CO2.
[11:33] Andrew Hellershanks : Il y a eu des changements liés au CO2 mais je ne sais pas ce qu'est le CO2.
[11:34] Ubit Umarov: jezzz
[11:34] Ubit Umarov: jezzz
[11:34] Vincent.Sylvester @hg.zetaworlds.com:8002: Ask a cow Andrew, they make a lot of it I heard
[11:34] Vincent.Sylvester @hg.zetaworlds.com:8002 : Demande à une vache Andrew, ils en font beaucoup j'ai entendu.
[11:34] Jagga Meredith: some gas? (I know, "don't start")
[11:34] Jagga Meredith : de l'essence ? (Je sais, "ne démarre pas")
[11:34] Andrew Hellershanks: Vincent, I thought that was methane.
[11:34] Andrew Hellershanks : Vincent, je pensais que c'était du méthane.
[11:34] Andrew Hellershanks: :)
[11:34] Andrew Hellershanks : :)
[11:34] Ubit Umarov: those are more methane Vicent :)
[11:34] Ubit Umarov : c'est plutôt du méthane Vincent :)
[11:35] Gavin.Hird @grid.xmir.org:8002: All of you are making a lot of CO2
[11:35] Gavin.Hird @grid.xmir.org:8002 : Vous produisez tous beaucoup de CO2
[11:35] Gavin.Hird @grid.xmir.org:8002: every exhale has 40X the CO2 compared to your inhale
[11:35] Gavin.Hird @grid.xmir.org:8002 : chaque expiration contient 40 fois plus de CO2 que votre inspiration.
[11:35] Ubit Umarov: yes but our CO2 is balanced
[11:35] Ubit Umarov : oui, mais notre CO2 est équilibré.
[11:35] Ubit Umarov: plants did capture all of it in our life time
[11:35] Ubit Umarov : les plantes ont tout capturé au cours de notre vie.
[11:36] Ubit Umarov: so our co is kinda "neutral"
[11:36] Ubit Umarov : donc notre co est en quelque sorte "neutre".
[11:36] Gavin.Hird @grid.xmir.org:8002: CO2 is compltely irrelevant for any discussion. It is a trace gas of 0.04% of the atmosphere
[11:36] Gavin.Hird @grid.xmir.org:8002 : Le CO2 n'est absolument pas pertinent pour toute discussion. C'est un gaz à l'état de trace qui représente 0,04% de l'atmosphère.
[11:36] Ubit Umarov: but yeah on the commits is abotu saving a little of cpu work, so power, so co2 on most regions
[11:36] Ubit Umarov : mais oui, sur les commits, il s'agit d'économiser un peu de travail du processeur, donc de l'énergie, donc du CO2 dans la plupart des régions.
[11:36] Ubit Umarov: :p
[11:36] Ubit Umarov: :p
[11:37] Andrew Hellershanks: One bug fix this past week prevents some prims from changing type when setting them to flex using llSetPrimitiveParams. (mantis 7896 and 7910).
[11:37] Andrew Hellershanks : Une correction de bogue effectuée la semaine dernière empêche certaines prims de changer de type lorsqu'elles sont configurées en flex avec llSetPrimitiveParams. (mantis 7896 et 7910).
[11:37] Ubit Umarov: "try save some zeptogram of CO2"
[11:37] Ubit Umarov : "essayez de sauver quelques zeptogrammes de CO2"
[11:37] Ubit Umarov: not the optimistic on real impact on co2 :p
[11:37] Ubit Umarov : pas optimiste sur l'impact réel sur le co2 :p
[11:37] Gavin.Hird @grid.xmir.org:8002: all power on my regions are generated from hydroelectric plants
[11:37] Gavin.Hird @grid.xmir.org:8002 : toute l'énergie de mes régions est générée par des centrales hydroélectriques.
[11:37] Andrew Hellershanks: Ubit, I read that and have no idea what it meant.
[11:37] Andrew Hellershanks : Ubit, j'ai lu ça et je n'ai aucune idée de ce que cela signifie.
[11:37] Ubit Umarov: wlel you know now :p
[11:37] Ubit Umarov : vous le savez maintenant :p
[11:37] Vincent.Sylvester @hg.zetaworlds.com:8002: Memory has been less of an issue with OpenSim, but given you can only really use one or two cores per instance, think most I have seen is 330% cpu, saving small bits here and there helps
[11:37] Vincent.Sylvester @hg.zetaworlds.com:8002 : La mémoire a été moins un problème avec OpenSim, mais étant donné que vous ne pouvez utiliser qu'un ou deux cœurs par instance, je pense que le maximum que j'ai vu est de 330% de cpu, économiser de petits morceaux ici et là est utile.
[11:38] Andrew Hellershanks looks up the definition of zeptogram
11:38] Andrew Hellershanks cherche la définition de zeptogramme.
[11:38] Andrew Hellershanks: No such word found in the dictionary.
[11:38] Andrew Hellershanks : Aucun mot de ce type n'a été trouvé dans le dictionnaire.
[11:38] Gavin.Hird @grid.xmir.org:8002: :-)
[11:38] Gavin.Hird @grid.xmir.org:8002: :-)
[11:38] Vincent.Sylvester @hg.zetaworlds.com:8002: Some of the changes I can imagine in certain situations when used a lot might make quite some more impact, but nothing you can really measure given the flux of cpu and threading
[11:38] Vincent.Sylvester @hg.zetaworlds.com:8002 : Certains des changements que je peux imaginer dans certaines situations où il est beaucoup utilisé pourraient avoir un impact plus important, mais rien que l'on puisse vraiment mesurer étant donné le flux de cpu et de threading.
[11:38] Ubit Umarov: you have a bad dic lol
[11:38] Ubit Umarov : tu as un mauvais dictionnaire lol
[11:39] Ubit Umarov: it is 10^-21 gram :p
[11:39] Ubit Umarov : c'est 10^-21 gramme :p
[11:39] Gavin.Hird @grid.xmir.org:8002: yeah
[11:39] Gavin.Hird @grid.xmir.org:8002: yeah
[11:39] Gavin.Hird @grid.xmir.org:8002: 1 zeptogram = 0,001 attogram
[11:39] Gavin.Hird @grid.xmir.org:8002 : 1 zeptogramme = 0,001 attogramme
[11:39] Jagga Meredith: *remembers high school math teacher saying "oh yeah, there's things like Tera- and pico- but you'll never use them"
[11:39] Jagga Meredith : *Se souvient du professeur de mathématiques du lycée qui disait "oh oui, il y a des choses comme Tera- et pico- mais vous ne les utiliserez jamais".
[11:39] Gavin.Hird @grid.xmir.org:8002: or 1 000 yoctogram
[11:39] Gavin.Hird @grid.xmir.org:8002 : ou 1 000 yoctogrammes.
[11:40] Andrew Hellershanks: I've never seen zepto before in terms of a unit of measure.
[11:40] Andrew Hellershanks : Je n'ai jamais vu zepto avant en termes d'unité de mesure.
[11:40] Ubit Umarov: well mantis 7896 and 7910 where actually a bug we had since ever
[11:40] Ubit Umarov : en fait, les mantis 7896 et 7910 étaient un bug que nous avions depuis toujours.
[11:40] Ubit Umarov: hope fixed now
[11:40] Ubit Umarov : j'espère que c'est corrigé maintenant.
[11:40] Ubit Umarov: actually did commit that today
[11:40] Ubit Umarov : en fait, je l'ai fait aujourd'hui.
[11:40] Andrew Hellershanks: Jagga, I often use pico.
[11:40] Andrew Hellershanks : Jagga, j'utilise souvent pico.
[11:40] Jagga Meredith: exactly
[11:40] Jagga Meredith : exactement.
[11:40] Vincent.Sylvester @hg.zetaworlds.com:8002: I was looking at an issue earlier this week in regards to links of deleted items not being deleted when commanded as such, but it appears that only "sticks" around until you relog, which I am not sure why that might be, but I suppose that does make it a non-issue or at least self correcting
[11:40] Vincent.Sylvester @hg.zetaworlds.com:8002: En début de semaine je me suis intéressé à un problème qui concerne des items supprimés qui ne sont pas supprimés quand c'est demandé. Mais il semble que ces items "persitent" seulement jusqu'à ce que vous vous reconnectiez. Je n'en suis pas sûr mais, je pense que c'est un problème inexistant ou du moins auto-correctif.
[11:41] Ubit Umarov: hard to same picogram of CO2 changing a few lines of code :p
[11:41] Ubit Umarov : difficile d'économiser le même picogramme de CO2 en changeant quelques lignes de code :p
[11:41] Ubit Umarov: hard to save...
[11:41] Ubit Umarov : difficile d'économiser...
[11:42] Jagga Meredith: is old
[11:42] Jagga Meredith : c'est vieux.
[11:43] Ubit Umarov: some lsl settings on [xengine] are needed on [yengine]   as andrew said some settings that where present only on X are needed also o Y
[11:43] Ubit Umarov : certains paramètres lsl sur le [xengine] sont nécessaires sur le [yengine] comme l'a dit andrew certains paramètres qui n'étaient présents que sur X sont nécessaires aussi sur Y.
[11:43] Ubit Umarov: currently LSLapi code looks for them on respective engine
[11:43] Ubit Umarov : actuellement le code LSLapi les recherche dans les moteurs respectifs.
[11:43] Ubit Umarov: so i did duplicate them
[11:43] Ubit Umarov : j'ai donc fait une copie de ces fichiers.
[11:44] Ubit Umarov: possible in future they should have own section
[11:44] Ubit Umarov : possible dans le futur qu'ils aient leur propre section.
[11:45] Andrew Hellershanks: I think I finally get the CO2 reference in the comment. It was Ubits slightly cryptic way of saying that he made some optimizations in the code to save some clock cycles.
[11:45] Andrew Hellershanks : Je pense avoir enfin compris la référence au CO2 dans le commentaire. C'était la façon légèrement cryptique d'Ubits de dire qu'il a fait quelques optimisations dans le code pour économiser quelques cycles d'horloge.
[11:45] Vincent.Sylvester @hg.zetaworlds.com:8002: I did finish up on fixing up the previously broken and disabled script engine tests for X and made them available as copies to Y as well. Ubit handed me a compliance testing script that appears to work almost completely in Y, with X misbehaving a bit more. I wrote a test for this script to run on both so that changes made to the script engines can now be tested for regressions
[11:45] Vincent.Sylvester @hg.zetaworlds.com:8002 : J'ai fini de corriger les tests de moteur de script précédemment cassés et désactivés pour X et je les ai rendus disponibles en tant que copies pour Y. Ubit m'a remis un script de test de conformité qui semble fonctionner presque complètement dans Y. Il se comporte un peu plus mal pour X. J'ai écrit un test à partir de ce script pour qu'il fonctionne sur les deux, de sorte que les changements apportés aux moteurs de script peuvent maintenant être testés pour les régressions.
[11:45] Ubit Umarov: well not for gavin.Hird
[11:45] Ubit Umarov : pas pour gavin.Hird.
[11:46] Ubit Umarov: but sure on servers in Poland for example
[11:46] Ubit Umarov : mais c'est sûr pour les serveurs en Pologne par exemple.
[11:47] Gavin.Hird @grid.xmir.org:8002: not saving CO2, but reducing the power bill
[11:47] Gavin.Hird @grid.xmir.org:8002 : ne pas économiser du CO2, mais réduire la facture d'électricité.
[11:47] Ubit Umarov: im considering underclock my machine :)
[11:47] Ubit Umarov : j'envisage d'underclocker ma machine :)
[11:47] Gavin.Hird @grid.xmir.org:8002: since Europe is in such a power squeeze, we sell all our power to it, so my price per kWh has gone up 11x the last month
[11:47] Gavin.Hird @grid.xmir.org:8002 : comme l'Europe est dans une telle situation de pénurie d'énergie, nous lui vendons toute notre énergie, donc mon prix par kWh a été multiplié par 11 le mois dernier.
[11:48] Vincent.Sylvester @hg.zetaworlds.com:8002: Working on the tests did find some issues with changed firing randomly when not commanded as such, though I am not entirely sure if that really is the case, scratching me head over that one still
[11:48] Vincent.Sylvester @hg.zetaworlds.com:8002 : En travaillant sur les tests, j'ai trouvé quelques problèmes avec les changements qui se déclenchent de manière aléatoire alors qu'ils ne sont pas commandés en tant que tels, bien que je ne sois pas entièrement sûr que ce soit vraiment le cas, je me gratte encore la tête sur ce point.
[11:49] Andrew Hellershanks: Vincent, good to have a proper set of tests for the scripting engine. Do they test the timing accuracy some script functions?
[11:49] Andrew Hellershanks : Vincent, c'est bien d'avoir un ensemble de tests appropriés pour le moteur de script. Est-ce qu'ils testent la précision du timing de certaines fonctions de script ?
[11:49] Andrew Hellershanks: Hello, Dennis.
[11:49] Andrew Hellershanks : Bonjour, Dennis.
[11:50] Gavin.Hird @grid.xmir.org:8002: Hi Dennis
[11:50] Gavin.Hird @grid.xmir.org:8002 : Salut Dennis
[11:50] Vincent.Sylvester @hg.zetaworlds.com:8002: I could write a test like that I guess
[11:50] Vincent.Sylvester @hg.zetaworlds.com:8002 : Je pourrais écrire un test comme ça, je suppose.
[11:50] Vincent.Sylvester @hg.zetaworlds.com:8002: There exists a test for running a plain script, I copied a lot of that code and just stuffed the compliance test script in there to run
[11:50] Vincent.Sylvester @hg.zetaworlds.com:8002 : Il existe un test pour l'exécution d'un script simple, j'ai copié une grande partie de ce code et j'ai simplement inséré le script de test de conformité pour l'exécuter.
[11:50] Andrew Hellershanks: I have found timing issues with KFM and/or llTargetOmega.
[11:50] Andrew Hellershanks : J'ai trouvé des problèmes de timing avec KFM et/ou llTargetOmega.
[11:50] Vincent.Sylvester @hg.zetaworlds.com:8002: Technically can run any script and check the output
[11:50] Vincent.Sylvester @hg.zetaworlds.com:8002 : Techniquement, on peut exécuter n'importe quel script et vérifier le résultat.
[11:51] Gavin.Hird @grid.xmir.org:8002: has not LL published a large number of script tests?
[11:51] Gavin.Hird @grid.xmir.org:8002 : LL n'a-t-il pas publié un grand nombre de tests de script ?
[11:51] Ubit Umarov: the one i shared with vincent is one of those gavin.Hird
[11:51] Ubit Umarov : celui que j'ai partagé avec Vincent est l'un de ceux-là gavin.Hird
[11:51] Vincent.Sylvester @hg.zetaworlds.com:8002: Timers are strange, but internally given the way they work you can make minor changes to the way you call the timer up which result in increased accuracy, but it will, not even in SL, be accurate over time
[11:52] Gavin.Hird @grid.xmir.org:8002: http://wiki.secondlife.com/wiki/LSL_Test_Harness
[11:52] Gavin.Hird @grid.xmir.org:8002: http://wiki.secondlife.com/wiki/LSL_Test_Harness
[11:52] Ubit Umarov: but usefull bc checks some evaluation order eve
[11:52] Ubit Umarov : mais utile pour vérifier l'ordre des évènements.
[11:52] Gavin.Hird @grid.xmir.org:8002: ok
[11:52] Gavin.Hird @grid.xmir.org:8002: ok
[11:52] Ubit Umarov: a case made VIncent brain smoke a bit :)
</pre>
[11:52] Andrew Hellershanks: Vincent, the problem with that is that it isn't reliable. You copy the script to a different grid and you have to recalculate the adjustments.
 
[11:53] Andrew Hellershanks: In some cases the viewer may be (part of?) the cause of timing issues.
= Timer et précision =
[11:54] Vincent.Sylvester @hg.zetaworlds.com:8002: Well you can almost always cut 0.3% off the time you want, so 10 becomes 9.7 then you make sure to 9.7f or the double whammy 9.777777f and you get about twice the accuracy over ten minutes than before
<pre>
[11:54] Vincent.Sylvester @hg.zetaworlds.com:8002: On most but the most loaded of regions that tends to work quite well
[11:51] Vincent.Sylvester @hg.zetaworlds.com:8002 : Les timers sont étranges, mais en interne, en fonction de la façon dont ils opèrent, vous pouvez faire des changements mineurs dans la façon dont vous appelez le timer, ce qui augmente la précision, mais il ne sera pas, même dans SL, précis dans le temps.
[11:54] Vincent.Sylvester @hg.zetaworlds.com:8002: I used to calc the difference in timing and once past 1 second just reset the timer event
[11:52] Ubit Umarov : une affaire qui a fait fumer un peu le cerveau de Vincent :)
[11:55] Vincent.Sylvester @hg.zetaworlds.com:8002: Or use a smaller timer in the range of accuracy you want, say every 5 minutes for an hourly check
[11:52] Andrew Hellershanks : Vincent, le problème avec ça, c'est que ce n'est pas fiable. Vous copiez le script sur une grille différente et vous devez recalculer les ajustements.
[11:55] Ubit Umarov: (jesus no :P )
[11:53] Andrew Hellershanks : Dans certains cas, le viewer peut être (en partie ?) la cause des problèmes de timing.
[11:55] Dennis Ravnsholm: thanks
[11:54] Vincent.Sylvester @hg.zetaworlds.com:8002 : Eh bien, tu peux presque toujours réduire de 0,3% le temps que tu veux, donc 10 devient 9,7 puis tu t'assures de 9,7f ou le double 9,777777f et tu obtiens environ deux fois plus de précision sur dix minutes qu'avant.
[11:56] Ubit Umarov: do not do that :p
[11:54] Vincent.Sylvester @hg.zetaworlds.com:8002 : Sur la plupart des régions, sauf les plus chargées, cela fonctionne assez bien.
[11:56] Andrew Hellershanks: I suspect that either the grid code or viewer code doesn't properly track the difference in time when some functions are called.
[11:54] Vincent.Sylvester @hg.zetaworlds.com:8002 : J'avais l'habitude de calculer la différence de temps et, une fois la seconde passée, de réinitialiser l'événement timer.
[11:56] Vincent.Sylvester @hg.zetaworlds.com:8002: I mean there is also the matter of the more you stuff into the timer event the slower that will be overall and it only restarts the count once the event has concluded not when it is fired
[11:55] Vincent.Sylvester @hg.zetaworlds.com:8002 : Ou utiliser un timer plus petit dans la plage de précision que vous voulez, disons toutes les 5 minutes pour une vérification horaire.
[11:56] Andrew Hellershanks: When I wrote a routine to determine pulses per second I took in to account that the time between calls might not be 1 second. I took the pulse count and divided by the actual passage of time since the previous call.
[11:55] Ubit Umarov : (jesus non :P )
[11:57] Vincent.Sylvester @hg.zetaworlds.com:8002: Like if you want something to run twice a second don't stuff a one-liner in there doing ten things, put ten lines all doing one thing, reducing the amount of "subroutines" so to speak
[11:55] Dennis Ravnsholm : Merci.
[11:57] Andrew Hellershanks: Heading out, Kayaker?
[11:56] Ubit Umarov : ne fais pas ça :p
[11:58] Vincent.Sylvester @hg.zetaworlds.com:8002: In the end you are just applying tricks and workarounds though, accurate timing is a billion dollar industry for the stock markets around the globe, little ole OpenSim won't give them a run for their money any day soon
[11:56] Andrew Hellershanks : Je soupçonne que le code de la grille ou celui du viewer ne suit pas correctement la différence de temps lorsque certaines fonctions sont appelées.
[11:58] Kayaker Magic: Not me! Someone landed on my head though...
[11:56] Vincent.Sylvester @hg.zetaworlds.com:8002 : Je veux dire qu'il y a aussi le problème suivant : plus vous remplissez l'événement timer, plus il sera lent dans l'ensemble et il ne redémarre le compte qu'une fois l'événement terminé, pas quand il est déclenché.
[11:58] Gavin.Hird @grid.xmir.org:8002: there are all kinds of stalls in the viewer depending on what else is happening, so I guess it cannot deliver accurate timing
[11:56] Andrew Hellershanks : Lorsque j'ai écrit une routine pour déterminer les impulsions par seconde, j'ai pris en compte le fait que le temps entre les appels pouvait ne pas être de 1 seconde. J'ai pris le nombre d'impulsions et l'ai divisé par le temps réel écoulé depuis l'appel précédent.
[11:58] Andrew Hellershanks: oh, ok. It looked like you were standing.
[11:57] Vincent.Sylvester @hg.zetaworlds.com:8002 : Par exemple, si vous voulez que quelque chose s'exécute deux fois par seconde, ne mettez pas une ligne unique qui fait dix choses, mais dix lignes qui font toutes la même chose, ce qui réduit le nombre de "sous-routines" pour ainsi dire.
[11:59] Kayaker Magic: Welcome Dennis!
[11:57] Andrew Hellershanks : Vous partez, kayakiste ?
[11:59] Kayaker Magic whispers: You are an hour late for the meeting!
[11:58] Vincent.Sylvester @hg.zetaworlds.com:8002 : En fin de compte, vous ne faites qu'appliquer des astuces et des solutions de contournement, le timing précis est une industrie d'un milliard de dollars pour les marchés boursiers dans le monde entier, le petit ole OpenSim ne leur donnera pas une course pour leur argent de sitôt.
[11:59] Andrew Hellershanks: Is there no way to know what the actual time was then compare that against what time it is now? It may not be one second. It might be 1.04 seconds. Timing can be accurate if you use the actual time between calls.
[11:58] Kayaker Magic : Pas moi ! Quelqu'un a atterri sur ma tête pourtant...
[12:01] Vincent.Sylvester @hg.zetaworlds.com:8002: You can get accurate times in larger measures, just below say 10 seconds you run out of digits before the comma
[11:58] Gavin.Hird @grid.xmir.org:8002 : il y a toutes sortes de blocages dans le viewer en fonction de ce qui se passe, donc je suppose qu'il ne peut pas fournir un timing précis.
[12:01] Andrew Hellershanks: I haven't dug in to the portion of code that deals with time passage. I might do that if I can get free of some other work I need to be doing.
[11:58] Andrew Hellershanks : oh, ok. On aurait dit que tu étais debout.
[12:02] Gavin.Hird @grid.xmir.org:8002: the viewer has timing code in llcommon/llfasttimer.cpp/h
[11:59] Kayaker Magic : Bienvenue Dennis !
[12:02] Gavin.Hird @grid.xmir.org:8002: because you also have llcommon/llframetimer.cpp/h
[11:59] Kayaker Magic murmure : Tu as une heure de retard pour la réunion !
[12:02] Andrew Hellershanks: Gavin, ty. I'll have to look for the equivalent in OS.
[11:59] Andrew Hellershanks : N'y a-t-il aucun moyen de savoir quelle était l'heure actuelle et de la comparer à l'heure qu'il est maintenant ? Ce n'est peut-être pas une seconde. Il peut s'agir de 1,04 seconde. Le chronométrage peut être précis si vous utilisez le temps réel entre les appels.
[12:02] Vincent.Sylvester @hg.zetaworlds.com:8002: I suppose one could internally track if the event gets out of sync and reschedule it similar to testing whether the reported timer event happened at modulo zero of set time or not, but that adds complexity which means less overall speed
[12:01] Vincent.Sylvester @hg.zetaworlds.com:8002 : On peut obtenir des temps précis dans des mesures plus grandes, mais en dessous de 10 secondes, il n'y a plus de chiffres avant la virgule.
[12:03] Gavin.Hird @grid.xmir.org:8002: and llcommon/llheartbeat.cpp/h
[12:01] Andrew Hellershanks : Je n'ai pas creusé dans la partie du code qui traite du passage du temps. Je pourrais le faire si je peux me libérer d'un autre travail que je dois faire.
[12:03] Vincent.Sylvester @hg.zetaworlds.com:8002: When you need to run things every minute you generally don't care much for a few seconds
[12:02] Gavin.Hird @grid.xmir.org:8002 : le code du timing du viewer est dans llcommon/llfasttimer.cpp/h
[12:03] Andrew Hellershanks: Timing used to be a bit more accurate than it is now. It is something that I've noticed and affects something I was working on so I may have to dig in to it.
[12:02] Gavin.Hird @grid.xmir.org:8002 : parce que vous avez aussi llcommon/llframetimer.cpp/h.
[12:04] Andrew Hellershanks: Vincent, no but when you are doing things based on time such as things being moved about via KFM it matters.
[12:02] Andrew Hellershanks : Gavin, merci. Je vais devoir chercher l'équivalent dans OS.
[12:05] Vincent.Sylvester @hg.zetaworlds.com:8002: Again that comes down to the lower the interval time the worse it gets
[12:02] Vincent.Sylvester @hg.zetaworlds.com:8002 : Je suppose que l'on pourrait suivre en interne si l'événement est désynchronisé et le reprogrammer, de la même manière que l'on teste si l'événement de la minuterie s'est produit à modulo zéro du temps fixé ou non, mais cela ajoute de la complexité, ce qui signifie moins de vitesse globale.
[12:05] Andrew Hellershanks: I just noticed we are at the top of the hour. Any one have a question they want to ask who may need to be leaving soon?
[12:03] Gavin.Hird @grid.xmir.org:8002 : et llcommon/llheartbeat.cpp/h
[12:05] Andrew Hellershanks: Vincent, not if it is done right.
[12:03] Vincent.Sylvester @hg.zetaworlds.com:8002 : Lorsque vous devez exécuter des choses toutes les minutes, vous ne vous souciez généralement pas beaucoup de quelques secondes.
[12:05] Vincent.Sylvester @hg.zetaworlds.com:8002: Also tweaking the code in the event itself to be less heavy so the event can conclude quickly
[12:03] Andrew Hellershanks : Le  timing était autrefois un peu plus précis qu'il ne l'est aujourd'hui. C'est quelque chose que j'ai remarqué et qui affecte une chose sur laquelle je travaillais, donc je vais peut-être devoir creuser la question.
[12:05] Andrew Hellershanks: Code should not assume that it is being called once per second. It should check how much real time has elapsed between calls and act accordingly.
[12:04] Andrew Hellershanks : Vincent, non, mais quand tu fais des choses basées sur le temps, comme des choses qui sont déplacées via KFM, ça compte.
[12:05] Gavin.Hird @grid.xmir.org:8002: it probalby isn't, Andrew
[12:05] Vincent.Sylvester @hg.zetaworlds.com:8002 : Encore une fois, plus l'intervalle de temps est faible, plus c'est mauvais.
[12:06] Andrew Hellershanks: Gavin, perhaps not. I'm just taking educated guesses as to the cause(s) of the issues I'm seeing.
[12:05] Andrew Hellershanks : Je viens de remarquer que nous sommes au début de l'heure. Est-ce que quelqu'un a une question à poser à quelqu'un qui doit partir bientôt ?
[12:07] Gavin.Hird @grid.xmir.org:8002: sure
[12:05] Andrew Hellershanks : Vincent, pas si c'est bien fait.
[12:07] Vincent.Sylvester @hg.zetaworlds.com:8002: The problem is changing it to be more accurate most likely means heavier code internally which then means timers are worse for region performance as they already are, which in turn means less usage and potentially folks going to while sleep which has a host of other issues
[12:05] Vincent.Sylvester @hg.zetaworlds.com:8002 : Il faut aussi modifier le code de l'événement lui-même pour qu'il soit moins lourd et que l'événement puisse se terminer rapidement.
[12:08] Jagga Meredith: *is getting recursive headache*
[12:05] Andrew Hellershanks : Le code ne devrait pas être appelé une fois par seconde. Il devrait vérifier combien de temps réel s'est écoulé entre les appels et agir en conséquence.
[12:08] Vincent.Sylvester @hg.zetaworlds.com:8002: I mean I guess could always to a ossl variant that uses some atomic clocks or something heh
[12:05] Gavin.Hird @grid.xmir.org:8002 : Il est probable que ce ne soit pas le cas, Andrew.
[12:08] Andrew Hellershanks: No, it doesn't have to be much heavier. It really is about how the code determines how much time has passed.
[12:06] Andrew Hellershanks : Gavin, peut-être pas. Je fais juste des suppositions sur la ou les causes des problèmes que je rencontre.
[12:08] Jagga Meredith: GPS time
[12:07] Gavin.Hird @grid.xmir.org:8002 : bien sûr.
[12:09] Kayaker Magic: Between the server, the internet and the viewer, I just always assume timers will NEVER be accurate and code accordingly.
07] Vincent.Sylvester @hg.zetaworlds.com:8002 : Le problème est que le changer pour qu'il soit plus précis signifie probablement un code plus lourd en interne, ce qui signifie que les timers sont moins bons pour les performances de la région qu'ils ne le sont déjà, ce qui signifie à son tour moins d'utilisation et potentiellement des gens qui vont en sommeil, ce qui provoque une foule d'autres problèmes.
[12:11] Andrew Hellershanks: For example, If you could get the number of clock ticks that have passed since the last time your code ran and you know how many clock ticks there are per second then you would know if it has been one second since the last time your code ran. If there are more, or less ticks, than the number for one second you can take that into account.
[12:08] Jagga Meredith : *a un mal de tête récursif*.
[12:12] Andrew Hellershanks: There might still be some slippage but overall that is a simple way to keep track of the passage of time.
[12:08] Vincent.Sylvester @hg.zetaworlds.com:8002 : Je veux dire que je suppose que l'on peut toujours utiliser une variante d'ossl qui utilise des horloges atomiques ou quelque chose comme ça.
[12:12] Jagga Meredith: you're assuming instantaneous delivery of "clock ticks"
[12:08] Andrew Hellershanks : Non, ça n'a pas besoin d'être beaucoup plus lourd. Il s'agit vraiment de savoir comment le code détermine le temps qui s'est écoulé.
[12:12] Gavin.Hird @grid.xmir.org:8002: and that clock ticks are a constant
[12:08] Jagga Meredith : Temps GPS
[12:12] Vincent.Sylvester @hg.zetaworlds.com:8002: You know that sounds fine in writing but in code that's a different story
[12:09] Kayaker Magic : Entre le serveur, l'internet et le viewer, je suppose toujours que les timers ne seront JAMAIS précis et je code en conséquence.
[12:13] Andrew Hellershanks: Clock ticks at the system level should be a constant or you have some serious problems.
[12:11] Andrew Hellershanks : Par exemple, si vous pouvez obtenir le nombre de ticks d'horloge qui se sont écoulés depuis la dernière fois que votre code a été exécuté et que vous savez combien de ticks d'horloge il y a par seconde, alors vous saurez si une seconde s'est écoulée depuis la dernière fois que votre code a été exécuté. S'il y a plus ou moins de ticks que le nombre de secondes, vous pouvez en tenir compte.
[12:13] Gavin.Hird @grid.xmir.org:8002: yes for realtime clocks
[12:12] Andrew Hellershanks : Il se peut qu'il y ait encore quelques dérapages, mais dans l'ensemble, c'est un moyen simple de suivre le passage du temps.
[12:13] Gavin.Hird @grid.xmir.org:8002: but cpu clock is not constant
[12:12] Jagga Meredith : vous supposez que la transmission des "tics d'horloge" est instantanée.
[12:13] Jagga Meredith: ...like other stuff happening at server level
[12:12] Gavin.Hird @grid.xmir.org:8002 : et que les tics de l'horloge sont une constante.
[12:16] Andrew Hellershanks: You do need to use a reliable clock source. I've done it on embedded systems without any special hardware. .
[12:12] Vincent.Sylvester @hg.zetaworlds.com:8002 : Vous savez, cela semble correct à l'écrit mais dans le code, c'est une autre histoire.
[12:16] Ubit Umarov: i spoke about current kfm and timing issues on several meetings already so, not doing it now
[12:13] Andrew Hellershanks : Les tics d'horloge au niveau du système doivent être constants, sinon vous avez de sérieux problèmes.
[12:18] Andrew Hellershanks: Ubit, I know you said you had made some changes to the code. I just know that the timing isn't as accurate now as it used to be.
[12:13] Gavin.Hird @grid.xmir.org:8002 : oui pour les horloges en temps réel.
[12:20] Andrew Hellershanks: It is getting nearer half past the hour. Any other topics for today before we wrap up todays meeting?
[12:13] Gavin.Hird @grid.xmir.org:8002 : mais l'horloge du processeur n'est pas constante.
[12:21] Andrew Hellershanks: If there is nothing further that will be it for this week.
[12:13] Jagga Meredith : ...comme d'autres choses qui se passent au niveau du serveur.
[12:21] Andrew Hellershanks: Thank you all for coming. See you again next week.
[12:16] Andrew Hellershanks : Vous devez utiliser une source d'horloge fiable. Je l'ai fait sur des systèmes embarqués sans matériel spécial. .
[12:16] Ubit Umarov : J'ai déjà parlé des problèmes de kfm et de timing lors de plusieurs réunions, donc je ne le fais pas maintenant.
[12:18] Andrew Hellershanks : Ubit, je sais que tu as dit que tu avais fait des changements dans le code. Je sais juste que le timing n'est plus aussi précis qu'avant.
</pre>
=Conclusion=
<pre>
[12:20] Andrew Hellershanks : Il est presque l'heure et demie. Y a-t-il d'autres sujets à aborder avant de conclure la réunion d'aujourd'hui ?
[12:21] Andrew Hellershanks : S'il n'y a rien d'autre, ce sera tout pour cette semaine.
[12:21] Andrew Hellershanks : Merci à tous d'être venus. Nous vous reverrons la semaine prochaine.
</pre>
</pre>

Dernière version du 1 décembre 2021 à 13:27

Traduction prochaine.

Source : http://opensimulator.org/wiki/Chat_log_from_the_meeting_on_2021-11-30

Introduction & Migration des assets sur Osgrid

Migration des assets sur Osgrid 

[11:01] Selby.Evans @grid.kitely.com:8002 : bonjour à tous.
[11:01] Gavin.Hird @grid.xmir.org:8002 : Salut Selby, Andrew
[11:01] Andrew Hellershanks : Bonjour à tous.
[11:01] Gavin.Hird @grid.xmir.org:8002 : Je pensais à la question des assets osg.
[11:02] Gavin.Hird @grid.xmir.org:8002 : pas la région.
[11:02] Ubit Umarov : salut andrew et selby.Evans
[11:02] Gavin.Hird @grid.xmir.org:8002 : :-)
[11:02] Ubit Umarov : ahh bien cela prendra du temps.
[11:02] Ubit Umarov : estimé à 1 mois
[11:02] Gavin.Hird @grid.xmir.org:8002 : donc l'année prochaine.
[11:02] Ubit Umarov : jusqu'à la fin de l'opération.
[11:03] Gavin.Hird @grid.xmir.org:8002 : Salut Jagga
[11:03] Andrew Hellershanks : Bonjour, Jagga.
[11:03] Jagga Meredith : Bonjour.
[11:03] Ubit Umarov : yeha pas sûr que les vacances aient été prises en compte dans cette estimation du temps.
[11:03] Andrew Hellershanks : Le temps pour faire quoi ?
[11:03] Gavin.Hird @grid.xmir.org:8002 : Je suppose que l'ordinateur fonctionne aussi vite que n'importe quel autre jour, férié ou non.
[11:04] Ubit Umarov : pour ceux qui ne comprennent pas, osgrid a déplacé les services d'assets vers un autre datacenter.
[11:04] Ubit Umarov : depuis quelques mois maintenant, les nouveaux services fonctionnent, récupérant les assets manquants des anciens services.
[11:04] Gavin.Hird @grid.xmir.org:8002 : et (ndlr : OSGrid) a posté un message indiquant que les ressources qui n'ont pas été récemment utilisées ne seront plus dans l'inventaire pendant environ un mois
[11:04] Ubit Umarov : maintenant cela a été arrêté.
[11:05] Andrew Hellershanks : Oh. Copier les données va prendre un certain temps...
[11:05] Ubit Umarov : les services vont signaler les manquants, comme manquants.
[11:05] Ubit Umarov : le reste des assets est en train d'être copié.
[11:05] Ubit Umarov : et cela va prendre beaucoup de temps.
[11:05] Andrew Hellershanks : Où cela est-il affiché sur le site Web d'osgrid ? Je ne le vois pas sous "News".
[11:05] Ubit Umarov : car il y a environ 5 To de données.
[11:06] Ubit Umarov : C'est sur le forum.
[11:06] Ubit Umarov : gavin l'a trouvé :)
[11:06] Gavin.Hird @grid.xmir.org:8002: https://forums.osgrid.org/viewtopic.php?f=8&t=6836
[11:07] Ubit Umarov : il semble que la recherche des assets manquants par les nouveaux services sur les anciens services ait  perturbé le processus de copie, provoquant ainsi beaucoup de retard.
[11:07] Ubit Umarov : à ce qu'on m'a dit :)
[11:07] Andrew Hellershanks : Oh. Ils l'ont enterré dans le forum ? Je lis rarement les forums.
[11:07] Gavin.Hird @grid.xmir.org:8002 : cela signifie probablement que les couronnes de Noël qu'on n'a pas utilisées depuis Noël dernier devront être oubliées cette année.
[11:08] Andrew Hellershanks : Bonjour, Jamie
[11:08] Vincent.Sylvester @hg.zetaworlds.com:8002 : Il est assez difficile de régler le déplacement des données concernant les assets, même lorsqu'il s'agit de fichiers, car le déplacement d'une grandes quantités de petits fichiers n'est pas ce pour quoi la plupart des systèmes de transfert sont optimisés. Avec rsync, j'ai commencé à tester les paramètres des tampons et du cache ainsi que l'exécution de plusieurs instances sur une partie de l'ensemble des données, car un seul rsync, même avec le multithreading intégré, ne se comporte pas bien lorsqu'il s'agit de déplacer 300 000 fichiers de quelques Ko chacun.  La structure de données des assets, même dans une configuration imbriquée, est un cauchemar, sans parler d'essayer de faire des sauvegardes par version sous une forme raisonnable sans vraiment repousser les limites de ce que la compression peut faire.
[11:09] Ubit Umarov : bien entendu, vous, les gens de l'hypergrid, ne devriez pas constater le problème.

Viewer & Glow

Les viewers Dayturn7 pour macOS et pour Windows 

[11:09] Jamie.Jordan @grid.kitely.com:8002 : Bonjour tout le monde, je n'ai pas réussi à charger la viewer aujourd'hui.
[11:09] Gavin.Hird @grid.xmir.org:8002 : ok...
[11:10] Ubit Umarov : la visionneuse a fonctionné correctement pour moi ici.
[11:10] Gavin.Hird @grid.xmir.org:8002 : en parlant de viewer, j'ai posté une nouvelle version il y a quelques jours.
[11:10] Andrew Hellershanks : Jamie, np. Tu as quand même réussi à venir ici.
[11:10] Ubit Umarov : seul sl a  des problèmes.
[11:10] Andrew Hellershanks : Gavin, quelque chose de nouveau et d'excitant ?
[11:10] Gavin.Hird @grid.xmir.org:8002 : oui.
[11:10] Selby.Evans @grid.kitely.com:8002 : Bonjour Jamie.
[11:10] Ubit Umarov : il faut se souvenir de l'url de Gavin :)
 vous pouvez définir des objets lumineux (glow) pour qu'ils soient 100 % transparents et qu'ils conservent leur luminosité.
[11:11] Ubit Umarov : je veux dire l'url de téléchargement du viewer.
[11:11] Gavin.Hird @grid.xmir.org:8002 : excellent pour faire des fantômes et d'autres choses.
[11:11] Jamie.Jordan @grid.kitely.com:8002 : Salut Selby
[11:11] Andrew Hellershanks : Il ne se conservait pas du réglage du glow avant maintenant ?
[11:11] Gavin.Hird @grid.xmir.org:8002: https://www.dayturn.com/viewer/index.php?resources/
[11:11] Gavin.Hird @grid.xmir.org:8002 : non.
[11:11] Ubit Umarov : ohh comme la lumière de la lune noire sur l'océan ?
[11:12] Ubit Umarov : ils ont oublié de vérifier le glow sur les prims transp ?
[11:12] Gavin.Hird @grid.xmir.org:8002 : c'est un type différent de glow Ubit.
[11:12] Ubit Umarov : mais une classe de bugs similaire :P
[11:12] Gavin.Hird @grid.xmir.org:8002 : ils l'ont fait.
[11:12] Andrew Hellershanks : IIRC, je n'utilise pas de glow supérieur à environ 30%, au delà, la texture est effacée sur la prim et tout ce que vous voyez est blanc.
[11:12] Ubit Umarov : ( mais la lune ne devrait pas être sombre )
[11:13] Gavin.Hird @grid.xmir.org:8002 : La configuration minimale requise est maintenant Windows 10, c'était XP....
[11:13] Kayaker Magic : Hmm, j'ai profité de l'absence de lumière sur la transparence pour faire des lumières clignotantes !
[11:13] Andrew Hellershanks : Gavin, c'est un grand saut. Cela peut exclure un certain nombre d'utilisateurs.
[11:13] Gavin.Hird @grid.xmir.org:8002: oui
[11:14] Ubit Umarov : ça fait sauter 7 et 8 :)
[11:14] Gavin.Hird @grid.xmir.org:8002 : j'ai aussi monté la version macOS d'un cran.
[11:14] Ubit Umarov: et vista!
[11:14] Gavin.Hird @grid.xmir.org:8002: Vista
[11:14] Gavin.Hird @grid.xmir.org:8002: :-)
[11:14] Ubit Umarov : opensim supporte vista !
[11:14] Ubit Umarov : pas XP :(
[11:15] Ubit Umarov : ( vista peut utiliser .net 4.6, XP ne le peut pas, c'est juste ça )

Lumières clignotantes "J'espère que toutes les lumières de Noël utiliseront une animation de texture"

[11:14] Kayaker Magic : Hmm, je donnerais bien à Gavin une copie de mes lumières clignotantes, mais cet asset ne peut pas être trouvé dans l'inventaire :(
[11:15] Gavin.Hird @grid.xmir.org:8002 : Il existe un script de lumières clignotantes dans la bibliothèque LSL.
[11:15] Gavin.Hird @grid.xmir.org:8002 : J'ai donné à Ubit une copie, donc peut-être qu'il l'a dans sa librairie ?
[11:15] Gavin.Hird @grid.xmir.org:8002 : donné*.
[11:15] Ubit Umarov : l'asset sera là en 2022 :)
[11:15] Andrew Hellershanks : Kayaker, l'article du forum dit que vous devrez peut-être attendre un mois.
[11:16] Ubit Umarov : un script clignotant ?
[11:16] Gavin.Hird @grid.xmir.org:8002 : oui.
[11:16] Ubit Umarov : oui, j'ai l'asset.
[11:16] Gavin.Hird @grid.xmir.org:8002 : il utilise le glow.
[11:16] Ubit Umarov : qui en a besoin ?
[11:16] Ubit Umarov: 
   timer()
    {
        isOn = !isOn;
        if( isOn ) llSetLinkPrimitiveParamsFast( LINK_THIS,[PRIM_GLOW,faceNo,glowAmount] );
        else llSetLinkPrimitiveParamsFast( LINK_THIS,[PRIM_GLOW,faceNo,0.0] );
    }
[11:16] Ubit Umarov: c'est ça
[11:17] Andrew Hellershanks : Un script simple et agréable.
[11:17] Gavin.Hird @grid.xmir.org:8002: url de téléchargement du viewer : https://www.dayturn.com/viewer/index.php?resources/
[11:17] Kayaker Magic : Ce n'est pas un script clignotant, il utilise llSetTextureAnim pour déplacer la couleur et la TRANSPARENCE entre les parties du mesh.
[11:18] Gavin.Hird @grid.xmir.org:8002 : mettez-le dans un cube Ubit.
[11:18] Ubit Umarov : les clignotants peuvent être un bon tueur de région.
[11:18] Kayaker Magic : Donc le viewer fait tout le travail.
[11:19] Gavin.Hird @grid.xmir.org:8002 : Le CPU de la région est à 0.11% donc je suis sûr qu'un script de clignotant ne la tuera pas.
[11:18] Andrew Hellershanks : Ubit, cela dépend en partie du timer utilisé.
[11:19] Ubit Umarov: définir une lumière (ou glow) est unc mise à jour complète de la prim prim envoyée  à tous les viewers dans la vue
[11:19] Ubit Umarov: il semble que les régions soient complètement hors service à cause de cela
[11:19] Ubit Umarov: flood complet sur lludp
[11:19] Ubit Umarov: llSetTextureAnim est une bonne façon d'éviter cela
[11:19] Gavin.Hird @grid.xmir.org:8002: CPU for the region is 0.11% so I am sure one blinker script will not kill it
[11:19] Kayaker Magic : Ouais, j'ai vu des gens mettre une région à genoux avec des lumières de Noël ! C'est pourquoi j'ai écrit ce clignotant orienté  client.
[11:20] Jagga Meredith: kewl
[11:21] Ubit Umarov : j'espère que toutes les lumières de Noël utiliseront une animation de texture ou similaire.
[11:22] Andrew Hellershanks : J'en ai vu plusieurs qui utilisent des timers courts (ou presque) pour que les scripts affichent un nombre élevé de temps d'exécution.
[11:22] Ubit Umarov : ce n'est pas seulement le CPU.
[11:22] Ubit Umarov : c'est une utilisation massive de lludp.
[11:22] Objet : Script en cours d'exécution

Incidence des scripts sur une région

[11:23] Vincent.Sylvester @hg.zetaworlds.com:8002 : Ce n'est pas aussi mauvais que vous le pensez, j'ai eu près de 40 personnes sur une région avec environ 30 lumières de chaque couleur et une lumière ponctuelle ainsi que quelques changeurs de couleur supplémentaires, etc., ça a mieux fonctionné qu'il y a 5 ans, c'est certain.
[11:23] Vincent.Sylvester @hg.zetaworlds.com:8002 : Nous avons parcouru un bon bout de chemin depuis l'époque où trop de mises à jour de prims  faisaient planter les régions.
[11:23] Gavin.Hird @grid.xmir.org:8002 : voici le script blink.
[11:23] Vincent.Sylvester @hg.zetaworlds.com:8002 : Maintenant, vous obtenez juste des échecs dans la file d'attente de mise à jour des scènes, ce qui donne l'impression que les scripts se sont arrêtés.
[11:24] Jagga Meredith : non copiable
[11:24] Vincent.Sylvester @hg.zetaworlds.com:8002 : Je reçois ça de temps en temps quand les gens décident de placer des scripts de 800 lignes dans quelque chose juste pour aligner une porte.
[11:24] Andrew Hellershanks : La première indication qu'un script peut causer des problèmes est le temps d'exécution élevé du script. Les utilisateurs ne peuvent pas voir de statistiques sur le trafic UDP.
[11:24] Ubit Umarov : en fait, ils le peuvent.
[11:24] Gavin.Hird @grid.xmir.org:8002 : l'aspect est un peu étrange lorsque la transparence est de 100%.
[11:24] Ubit Umarov : mais pas la source.
[11:25] Vincent.Sylvester @hg.zetaworlds.com:8002 : J'ai pas mal d'éclairage avec des fonctions normalement gourmandes, avec quelques astuces vous pouvez réduire l'impact sur la région, mais un faux mouvement et le processeur s'en va...
[11:25] Ubit Umarov : mais lludp est là en plus des stats.
[11:25] Ubit Umarov : ( ce qu'on ne voit pas c'est http, sauf sur singularity =
[11:26] Vincent.Sylvester @hg.zetaworlds.com:8002 : Je n'ai pas vu un seul utilisateur consommer plus de 3mbit après que la région soit chargée pour lui, à moins que vous ne fassiez du DSL sur un morceau de ficelle mouillée, vous êtes généralement bien sur le front du réseau.
[11:26] Kayaker Magic : En parlant de mauvais scripts, Discovery Grid a découvert qu'un de ses utilisateurs utilisait un script qui sauvegardait une carte chaque seconde, et en a faisait plusieurs copies.
[11:26] Ubit Umarov : singularity a un truc sympa sur l'utilisation de la bande passante http.
[11:26] Ubit Umarov : maintenant je vois que j'utilise 50Mo tout seul :p
[11:26] Ubit Umarov : sur une région
[11:27] Vincent.Sylvester @hg.zetaworlds.com:8002 : Si nous entrons dans une discussion sur les déficiences du protocole, nous en aurons pour des jours, il y a tellement d'appels redondants et de choses qui se produisent, au final, cela fonctionne comme par magie, même si cela ne devrait probablement pas fonctionner.
[11:28] Ubit Umarov : j'ai changé la restriction http sur les assets.
[11:28] Andrew Hellershanks : :)
[11:28] Gavin.Hird @grid.xmir.org:8002 : maintenant le cube avec le script peut être copié.
[11:29] Ubit Umarov : remplacé throttle par autre chose, juste plus intéressé par l'utilisation raisonnable.
[11:29] Jagga Meredith : *regarde le cube, hypnotisée*.
[11:29] Ubit Umarov : et avec le type de priorité des données.
[11:29] Ubit Umarov : au cas où vous n'auriez pas remarqué, les avatars se rechargent beaucoup plus vite maintenant :p
[11:29] Andrew Hellershanks : hm... je me demande si quelqu'un a déjà fabriqué une lampe à lave ?
[11:29] Ubit Umarov : si vous et votre région avez de la bande passante...
[11:30] Vincent.Sylvester @hg.zetaworlds.com:8002 : Les fondus de couleurs lents sont faciles à réaliser dans Yengine grâce à une meilleure gestion des délais de script.
[11:30] Vincent.Sylvester @hg.zetaworlds.com:8002 : Il faut juste trouver le bon point d'équilibre pour la complexité de la fonction et la chose s'écrit toute seule.
[11:31] Ubit Umarov : (notez que cela n'a rien à voir avec certaines forks qui ont simplement supprimé les étranglements sans aucun code de remplacement).
[11:31] Ubit Umarov : a
[11:31] Vincent.Sylvester @hg.zetaworlds.com:8002 : Bonne mesure de l'horloge du processeur en voyant à quelle vitesse la lumière change.

Nouvelles d'OpenSim cette semaine

  • Certains paramètres qui étaient auparavant uniquement disponibles pour XEngine sont maintenant disponibles dans YEngine.
  • Certains problèmes de longue date ont finalement été pris en compte,
  • Une correction de bogue effectuée la semaine dernière empêche certaines prims de changer de type lorsqu'elles sont configurées en flex avec llSetPrimitiveParams. (mantis 7896 et 7910).
  • optimisations dans le code pour économiser quelques cycles d'horloge.
  • écriture d'un test qui fonctionne sur les deux moteurs de scripts XEngine et YEngine
  • LSL Test Harness
[11:31] Ubit Umarov : ok, et quelles sont les nouvelles que vous avez sur opensim ?
[11:31] Ubit Umarov: :)
[11:32] Andrew Hellershanks : Pas beaucoup de changements cette semaine mais quelques uns.
[11:33] Andrew Hellershanks : Certains paramètres qui étaient auparavant uniquement disponibles pour XEngine sont maintenant disponibles dans YEngine.
[11:33] Vincent.Sylvester @hg.zetaworlds.com:8002 : La plupart des corrections de bogues que j'aime voir, certains problèmes de longue date ont finalement été pris en compte, mais j'aimerais que mantis soit un peu plus flexible avec tout cela.
[11:33] Vincent.Sylvester @hg.zetaworlds.com:8002 : On ne peut pas vraiment établir de statut "à tester" ou "ne peut pas être corrigé maintenant".
[11:33] Andrew Hellershanks : Il y a eu des changements liés au CO2 mais je ne sais pas ce qu'est le CO2.
[11:34] Ubit Umarov: jezzz
[11:34] Vincent.Sylvester @hg.zetaworlds.com:8002 : Demande à une vache Andrew, ils en font beaucoup j'ai entendu.
[11:34] Jagga Meredith : de l'essence ? (Je sais, "ne démarre pas")
[11:34] Andrew Hellershanks : Vincent, je pensais que c'était du méthane.
[11:34] Andrew Hellershanks : :)
[11:34] Ubit Umarov : c'est plutôt du méthane Vincent :)
[11:35] Gavin.Hird @grid.xmir.org:8002 : Vous produisez tous beaucoup de CO2
[11:35] Gavin.Hird @grid.xmir.org:8002 : chaque expiration contient 40 fois plus de CO2 que votre inspiration.
[11:35] Ubit Umarov : oui, mais notre CO2 est équilibré.
[11:35] Ubit Umarov : les plantes ont tout capturé au cours de notre vie.
[11:36] Ubit Umarov : donc notre co est en quelque sorte "neutre".
[11:36] Gavin.Hird @grid.xmir.org:8002 : Le CO2 n'est absolument pas pertinent pour toute discussion. C'est un gaz à l'état de trace qui représente 0,04% de l'atmosphère.
[11:36] Ubit Umarov : mais oui, sur les commits, il s'agit d'économiser un peu de travail du processeur, donc de l'énergie, donc du CO2 dans la plupart des régions.
[11:36] Ubit Umarov: :p
[11:37] Andrew Hellershanks : Une correction de bogue effectuée la semaine dernière empêche certaines prims de changer de type lorsqu'elles sont configurées en flex avec llSetPrimitiveParams. (mantis 7896 et 7910).
[11:37] Ubit Umarov : "essayez de sauver quelques zeptogrammes de CO2"
[11:37] Ubit Umarov : pas optimiste sur l'impact réel sur le co2 :p
[11:37] Gavin.Hird @grid.xmir.org:8002 : toute l'énergie de mes régions est générée par des centrales hydroélectriques.
[11:37] Andrew Hellershanks : Ubit, j'ai lu ça et je n'ai aucune idée de ce que cela signifie.
[11:37] Ubit Umarov : vous le savez maintenant :p
[11:37] Vincent.Sylvester @hg.zetaworlds.com:8002 : La mémoire a été moins un problème avec OpenSim, mais étant donné que vous ne pouvez utiliser qu'un ou deux cœurs par instance, je pense que le maximum que j'ai vu est de 330% de cpu, économiser de petits morceaux ici et là est utile.
11:38] Andrew Hellershanks cherche la définition de zeptogramme.
[11:38] Andrew Hellershanks : Aucun mot de ce type n'a été trouvé dans le dictionnaire.
[11:38] Gavin.Hird @grid.xmir.org:8002: :-)
[11:38] Vincent.Sylvester @hg.zetaworlds.com:8002 : Certains des changements que je peux imaginer dans certaines situations où il est beaucoup utilisé pourraient avoir un impact plus important, mais rien que l'on puisse vraiment mesurer étant donné le flux de cpu et de threading.
[11:38] Ubit Umarov : tu as un mauvais dictionnaire lol
[11:39] Ubit Umarov : c'est 10^-21 gramme :p
[11:39] Gavin.Hird @grid.xmir.org:8002: yeah
[11:39] Gavin.Hird @grid.xmir.org:8002 : 1 zeptogramme = 0,001 attogramme
[11:39] Jagga Meredith : *Se souvient du professeur de mathématiques du lycée qui disait "oh oui, il y a des choses comme Tera- et pico- mais vous ne les utiliserez jamais".
[11:39] Gavin.Hird @grid.xmir.org:8002 : ou 1 000 yoctogrammes.
[11:40] Andrew Hellershanks : Je n'ai jamais vu zepto avant en termes d'unité de mesure.
[11:40] Ubit Umarov : en fait, les mantis 7896 et 7910 étaient un bug que nous avions depuis toujours.
[11:40] Ubit Umarov : j'espère que c'est corrigé maintenant.
[11:40] Ubit Umarov : en fait, je l'ai fait aujourd'hui.
[11:40] Andrew Hellershanks : Jagga, j'utilise souvent pico.
[11:40] Jagga Meredith : exactement.
[11:40] Vincent.Sylvester @hg.zetaworlds.com:8002: En début de semaine je me suis intéressé à un problème qui concerne des items supprimés qui ne sont pas supprimés quand c'est demandé. Mais il semble que ces items "persitent"  seulement jusqu'à ce que vous vous reconnectiez. Je n'en suis pas sûr mais, je pense que c'est un problème inexistant ou du moins auto-correctif.
[11:41] Ubit Umarov : difficile d'économiser le même picogramme de CO2 en changeant quelques lignes de code :p
[11:41] Ubit Umarov : difficile d'économiser...
[11:42] Jagga Meredith : c'est vieux.
[11:43] Ubit Umarov : certains paramètres lsl sur le [xengine] sont nécessaires sur le [yengine] comme l'a dit andrew certains paramètres qui n'étaient présents que sur X sont nécessaires aussi sur Y.
[11:43] Ubit Umarov : actuellement le code LSLapi les recherche dans les moteurs respectifs.
[11:43] Ubit Umarov : j'ai donc fait une copie de ces fichiers.
[11:44] Ubit Umarov : possible dans le futur qu'ils aient leur propre section.
[11:45] Andrew Hellershanks : Je pense avoir enfin compris la référence au CO2 dans le commentaire. C'était la façon légèrement cryptique d'Ubits de dire qu'il a fait quelques optimisations dans le code pour économiser quelques cycles d'horloge.
[11:45] Vincent.Sylvester @hg.zetaworlds.com:8002 : J'ai fini de corriger les tests de moteur de script précédemment cassés et désactivés pour X et je les ai rendus disponibles en tant que copies pour Y. Ubit m'a remis un script de test de conformité qui semble fonctionner presque complètement dans Y. Il se comporte un peu plus mal pour X. J'ai écrit un test à partir de ce script pour qu'il fonctionne sur les deux, de sorte que les changements apportés aux moteurs de script peuvent maintenant être testés pour les régressions.
[11:45] Ubit Umarov : pas pour gavin.Hird.
[11:46] Ubit Umarov : mais c'est sûr pour les serveurs en Pologne par exemple.
[11:47] Gavin.Hird @grid.xmir.org:8002 : ne pas économiser du CO2, mais réduire la facture d'électricité.
[11:47] Ubit Umarov : j'envisage d'underclocker ma machine :)
[11:47] Gavin.Hird @grid.xmir.org:8002 : comme l'Europe est dans une telle situation de pénurie d'énergie, nous lui vendons toute notre énergie, donc mon prix par kWh a été multiplié par 11 le mois dernier.
[11:48] Vincent.Sylvester @hg.zetaworlds.com:8002 : En travaillant sur les tests, j'ai trouvé quelques problèmes avec les changements qui se déclenchent de manière aléatoire alors qu'ils ne sont pas commandés en tant que tels, bien que je ne sois pas entièrement sûr que ce soit vraiment le cas, je me gratte encore la tête sur ce point.
[11:49] Andrew Hellershanks : Vincent, c'est bien d'avoir un ensemble de tests appropriés pour le moteur de script. Est-ce qu'ils testent la précision du timing de certaines fonctions de script ?
[11:49] Andrew Hellershanks : Bonjour, Dennis.
[11:50] Gavin.Hird @grid.xmir.org:8002 : Salut Dennis
[11:50] Vincent.Sylvester @hg.zetaworlds.com:8002 : Je pourrais écrire un test comme ça, je suppose.
[11:50] Vincent.Sylvester @hg.zetaworlds.com:8002 : Il existe un test pour l'exécution d'un script simple, j'ai copié une grande partie de ce code et j'ai simplement inséré le script de test de conformité pour l'exécuter.
[11:50] Andrew Hellershanks : J'ai trouvé des problèmes de timing avec KFM et/ou llTargetOmega.
[11:50] Vincent.Sylvester @hg.zetaworlds.com:8002 : Techniquement, on peut exécuter n'importe quel script et vérifier le résultat.
[11:51] Gavin.Hird @grid.xmir.org:8002 : LL n'a-t-il pas publié un grand nombre de tests de script ?
[11:51] Ubit Umarov : celui que j'ai partagé avec Vincent est l'un de ceux-là gavin.Hird
[11:52] Gavin.Hird @grid.xmir.org:8002: http://wiki.secondlife.com/wiki/LSL_Test_Harness
[11:52] Ubit Umarov : mais utile pour vérifier l'ordre des évènements.
[11:52] Gavin.Hird @grid.xmir.org:8002: ok

Timer et précision

[11:51] Vincent.Sylvester @hg.zetaworlds.com:8002 : Les timers sont étranges, mais en interne, en fonction de la façon dont ils opèrent, vous pouvez faire des changements mineurs dans la façon dont vous appelez le timer, ce qui augmente la précision, mais il ne sera pas, même dans SL, précis dans le temps.
[11:52] Ubit Umarov : une affaire qui a fait fumer un peu le cerveau de Vincent :)
[11:52] Andrew Hellershanks : Vincent, le problème avec ça, c'est que ce n'est pas fiable. Vous copiez le script sur une grille différente et vous devez recalculer les ajustements.
[11:53] Andrew Hellershanks : Dans certains cas, le viewer peut être (en partie ?) la cause des problèmes de timing.
[11:54] Vincent.Sylvester @hg.zetaworlds.com:8002 : Eh bien, tu peux presque toujours réduire de 0,3% le temps que tu veux, donc 10 devient 9,7 puis tu t'assures de 9,7f ou le double 9,777777f et tu obtiens environ deux fois plus de précision sur dix minutes qu'avant.
[11:54] Vincent.Sylvester @hg.zetaworlds.com:8002 : Sur la plupart des régions, sauf les plus chargées, cela fonctionne assez bien.
[11:54] Vincent.Sylvester @hg.zetaworlds.com:8002 : J'avais l'habitude de calculer la différence de temps et, une fois la seconde passée, de réinitialiser l'événement timer.
[11:55] Vincent.Sylvester @hg.zetaworlds.com:8002 : Ou utiliser un timer plus petit dans la plage de précision que vous voulez, disons toutes les 5 minutes pour une vérification horaire.
[11:55] Ubit Umarov : (jesus non :P )
[11:55] Dennis Ravnsholm : Merci.
[11:56] Ubit Umarov : ne fais pas ça :p
[11:56] Andrew Hellershanks : Je soupçonne que le code de la grille ou celui du viewer ne suit pas correctement la différence de temps lorsque certaines fonctions sont appelées.
[11:56] Vincent.Sylvester @hg.zetaworlds.com:8002 : Je veux dire qu'il y a aussi le problème suivant : plus vous remplissez l'événement timer, plus il sera lent dans l'ensemble et il ne redémarre le compte qu'une fois l'événement terminé, pas quand il est déclenché.
[11:56] Andrew Hellershanks : Lorsque j'ai écrit une routine pour déterminer les impulsions par seconde, j'ai pris en compte le fait que le temps entre les appels pouvait ne pas être de 1 seconde. J'ai pris le nombre d'impulsions et l'ai divisé par le temps réel écoulé depuis l'appel précédent.
[11:57] Vincent.Sylvester @hg.zetaworlds.com:8002 : Par exemple, si vous voulez que quelque chose s'exécute deux fois par seconde, ne mettez pas une ligne unique qui fait dix choses, mais dix lignes qui font toutes la même chose, ce qui réduit le nombre de "sous-routines" pour ainsi dire.
[11:57] Andrew Hellershanks : Vous partez, kayakiste ?
[11:58] Vincent.Sylvester @hg.zetaworlds.com:8002 : En fin de compte, vous ne faites qu'appliquer des astuces et des solutions de contournement, le timing précis est une industrie d'un milliard de dollars pour les marchés boursiers dans le monde entier, le petit ole OpenSim ne leur donnera pas une course pour leur argent de sitôt.
[11:58] Kayaker Magic : Pas moi ! Quelqu'un a atterri sur ma tête pourtant...
[11:58] Gavin.Hird @grid.xmir.org:8002 : il y a toutes sortes de blocages dans le viewer en fonction de ce qui se passe, donc je suppose qu'il ne peut pas fournir un timing précis.
[11:58] Andrew Hellershanks : oh, ok. On aurait dit que tu étais debout.
[11:59] Kayaker Magic : Bienvenue Dennis !
[11:59] Kayaker Magic murmure : Tu as une heure de retard pour la réunion !
[11:59] Andrew Hellershanks : N'y a-t-il aucun moyen de savoir quelle était l'heure actuelle et de la comparer à l'heure qu'il est maintenant ? Ce n'est peut-être pas une seconde. Il peut s'agir de 1,04 seconde. Le chronométrage peut être précis si vous utilisez le temps réel entre les appels.
[12:01] Vincent.Sylvester @hg.zetaworlds.com:8002 : On peut obtenir des temps précis dans des mesures plus grandes, mais en dessous de 10 secondes, il n'y a plus de chiffres avant la virgule.
[12:01] Andrew Hellershanks : Je n'ai pas creusé dans la partie du code qui traite du passage du temps. Je pourrais le faire si je peux me libérer d'un autre travail que je dois faire.
[12:02] Gavin.Hird @grid.xmir.org:8002 : le code du timing du viewer  est dans llcommon/llfasttimer.cpp/h
[12:02] Gavin.Hird @grid.xmir.org:8002 : parce que vous avez aussi llcommon/llframetimer.cpp/h.
[12:02] Andrew Hellershanks : Gavin, merci. Je vais devoir chercher l'équivalent dans OS.
[12:02] Vincent.Sylvester @hg.zetaworlds.com:8002 : Je suppose que l'on pourrait suivre en interne si l'événement est désynchronisé et le reprogrammer, de la même manière que l'on teste si l'événement de la minuterie s'est produit à modulo zéro du temps fixé ou non, mais cela ajoute de la complexité, ce qui signifie moins de vitesse globale.
[12:03] Gavin.Hird @grid.xmir.org:8002 : et llcommon/llheartbeat.cpp/h
[12:03] Vincent.Sylvester @hg.zetaworlds.com:8002 : Lorsque vous devez exécuter des choses toutes les minutes, vous ne vous souciez généralement pas beaucoup de quelques secondes.
[12:03] Andrew Hellershanks : Le  timing était autrefois un peu plus précis qu'il ne l'est aujourd'hui. C'est quelque chose que j'ai remarqué et qui affecte une chose sur laquelle je travaillais, donc je vais peut-être devoir creuser la question.
[12:04] Andrew Hellershanks : Vincent, non, mais quand tu fais des choses basées sur le temps, comme des choses qui sont déplacées via KFM, ça compte.
[12:05] Vincent.Sylvester @hg.zetaworlds.com:8002 : Encore une fois, plus l'intervalle de temps est faible, plus c'est mauvais.
[12:05] Andrew Hellershanks : Je viens de remarquer que nous sommes au début de l'heure. Est-ce que quelqu'un a une question à poser à quelqu'un qui doit partir bientôt ?
[12:05] Andrew Hellershanks : Vincent, pas si c'est bien fait.
[12:05] Vincent.Sylvester @hg.zetaworlds.com:8002 : Il faut aussi modifier le code de l'événement lui-même pour qu'il soit moins lourd et que l'événement puisse se terminer rapidement.
[12:05] Andrew Hellershanks : Le code ne devrait pas être appelé une fois par seconde. Il devrait vérifier combien de temps réel s'est écoulé entre les appels et agir en conséquence.
[12:05] Gavin.Hird @grid.xmir.org:8002 : Il est probable que ce ne soit pas le cas, Andrew.
[12:06] Andrew Hellershanks : Gavin, peut-être pas. Je fais juste des suppositions sur la ou les causes des problèmes que je rencontre.
[12:07] Gavin.Hird @grid.xmir.org:8002 : bien sûr.
07] Vincent.Sylvester @hg.zetaworlds.com:8002 : Le problème est que le changer pour qu'il soit plus précis signifie probablement un code plus lourd en interne, ce qui signifie que les timers sont moins bons pour les performances de la région qu'ils ne le sont déjà, ce qui signifie à son tour moins d'utilisation et potentiellement des gens qui vont en sommeil, ce qui provoque une foule d'autres problèmes.
[12:08] Jagga Meredith : *a un mal de tête récursif*.
[12:08] Vincent.Sylvester @hg.zetaworlds.com:8002 : Je veux dire que je suppose que l'on peut toujours utiliser une variante d'ossl qui utilise des horloges atomiques ou quelque chose comme ça.
[12:08] Andrew Hellershanks : Non, ça n'a pas besoin d'être beaucoup plus lourd. Il s'agit vraiment de savoir comment le code détermine le temps qui s'est écoulé.
[12:08] Jagga Meredith : Temps GPS
[12:09] Kayaker Magic : Entre le serveur, l'internet et le viewer, je suppose toujours que les timers ne seront JAMAIS précis et je code en conséquence.
[12:11] Andrew Hellershanks : Par exemple, si vous pouvez obtenir le nombre de ticks d'horloge qui se sont écoulés depuis la dernière fois que votre code a été exécuté et que vous savez combien de ticks d'horloge il y a par seconde, alors vous saurez si une seconde s'est écoulée depuis la dernière fois que votre code a été exécuté. S'il y a plus ou moins de ticks que le nombre de secondes, vous pouvez en tenir compte.
[12:12] Andrew Hellershanks : Il se peut qu'il y ait encore quelques dérapages, mais dans l'ensemble, c'est un moyen simple de suivre le passage du temps.
[12:12] Jagga Meredith : vous supposez que la transmission des "tics d'horloge" est instantanée.
[12:12] Gavin.Hird @grid.xmir.org:8002 : et que les tics de l'horloge sont une constante.
[12:12] Vincent.Sylvester @hg.zetaworlds.com:8002 : Vous savez, cela semble correct à l'écrit mais dans le code, c'est une autre histoire.
[12:13] Andrew Hellershanks : Les tics d'horloge au niveau du système doivent être constants, sinon vous avez de sérieux problèmes.
[12:13] Gavin.Hird @grid.xmir.org:8002 : oui pour les horloges en temps réel.
[12:13] Gavin.Hird @grid.xmir.org:8002 : mais l'horloge du processeur n'est pas constante.
[12:13] Jagga Meredith : ...comme d'autres choses qui se passent au niveau du serveur.
[12:16] Andrew Hellershanks : Vous devez utiliser une source d'horloge fiable. Je l'ai fait sur des systèmes embarqués sans matériel spécial. .
[12:16] Ubit Umarov : J'ai déjà parlé des problèmes de kfm et de timing lors de plusieurs réunions, donc je ne le fais pas maintenant.
[12:18] Andrew Hellershanks : Ubit, je sais que tu as dit que tu avais fait des changements dans le code. Je sais juste que le timing n'est plus aussi précis qu'avant.

Conclusion

[12:20] Andrew Hellershanks : Il est presque l'heure et demie. Y a-t-il d'autres sujets à aborder avant de conclure la réunion d'aujourd'hui ?
[12:21] Andrew Hellershanks : S'il n'y a rien d'autre, ce sera tout pour cette semaine.
[12:21] Andrew Hellershanks : Merci à tous d'être venus. Nous vous reverrons la semaine prochaine.
Récupérée de « https://cogito.no-ip.info/cogito/OSWiki/index.php?title=Réunion_du_30-11-2021&oldid=3845 »