« Réunion du 12-07-2022 » : différence entre les versions

De OSWiki
Aller à la navigation Aller à la recherche
Aucun résumé des modifications
 
(27 versions intermédiaires par le même utilisateur non affichées)
Ligne 1 : Ligne 1 :
Source : http://opensimulator.org/wiki/Chat_log_from_the_meeting_on_2022-07-12
Source : http://opensimulator.org/wiki/Chat_log_from_the_meeting_on_2022-07-12


<pre style="white-space: pre-wrap;word-wrap: break-word;">
=Introduction =
[11:04] Ubit Umarov: ahh andrew's cat did remember the meeting
 
[11:04] Andrew Hellershanks: I'm on a phone call,
[11:04] '''Ubit Umarov'''  : ahh le chat d'andrew s'est souvenu de la réunion.
[11:04] Misterblue Waves: we got up to 48c last summer -- the plants didn't do well
 
[11:05] Ubit Umarov: Ohh ok we wil type softly
[11:04] '''Andrew Hellershanks'''  : Je suis au téléphone,
[11:05] Ubit Umarov: yeah but 48 here is rare.. like 45years rare
 
[11:06] Ubit Umarov: well about opensim, again not much
[11:04] '''Misterblue Waves'''  : nous sommes montés jusqu'à 48c l'été dernier -- les plantes n'ont pas bien résisté.
[11:06] Vincent.Sylvester @hg.zetaworlds.com:8002: Two changes last week, another cleanup on libomv and a fix for fsassets not properly using its folders. I rolled back mono to 122 on Friday and am now awaiting what that does to regions. So far haven't heard of further crashes, but will have to leave it for a bit to make sure. FS has a new beta out with support for the grid status rss now supported in OpenSim.
 
[11:06] Misterblue Waves: same for us -- getting above 100F is rare
[11:05] '''Ubit Umarov'''  : Ohh ok on va taper doucement
[11:06] Ubit Umarov: i did a little commit related to a fsassets flag
 
[11:07] Ubit Umarov: or option, actually not that good...
[11:05] '''Ubit Umarov'''  : ouais mais 48 ici c'est rare... comme 45 ans rare.
[11:07] Ubit Umarov: to run several instances of fsassets will just not work
 
[11:07] Ubit Umarov: unless you do have a network disk as storage
= Fsassets : instances multiples =
[11:07] Andrew Hellershanks: .0
* [http://opensimulator.org/viewgit/?a=shortlog&p=opensim Journal des commits OpenSim]
[11:08] Ubit Umarov: fs just writes things on a disk..  has no idea abotu multi instances
* [http://opensimulator.org/mantis/my_view_page.php Mantis : suivi de bogues]
[11:08] Ubit Umarov: the metadata does depend on mysql doing the multi server thing, that seems not that good either
* Fsassets : http://opensimulator.org/wiki/FSAssets_Service/fr
[11:09] Ubit Umarov: so, not that usefaull that option..
* Hash Bukets :  utilisés pour répartir les éléments de données à des fins de tri ou de consultation. L'objectif de ce travail est de pouvoir rechercher un élément spécifique dans un délai plus court.
[11:09] Ubit Umarov: or useful
 
[11:09] Ubit Umarov: hmmwhat was the other? libomv?
[11:06] '''Ubit Umarov'''  : à propos d'opensim, encore une fois pas grand chose.
[11:10] Ubit Umarov: hmm guess minor thing also
 
[11:10] Vincent.Sylvester @hg.zetaworlds.com:8002: Is the fsassets thing mostly file locking or what's the problem there?
[11:06] '''Vincent.Sylvester @hg.zetaworlds.com:8002''' : Deux changements la semaine dernière, un autre nettoyage de libomv[https://bitbucket.org/opensimulator/libopenmetaverse/src/master/] et un correctif pour fsassets qui n'utilise pas correctement ses dossiers. Je suis repassé à  mono[https://fr.wikipedia.org/wiki/Mono_(logiciel)] 122[https://www.mono-project.com/docs/about-mono/releases/6.12.0.122/] vendredi et j'attends maintenant ce que cela fait aux régions. Jusqu'à présent, je n'ai pas entendu parler de nouveaux crashs, mais je vais devoir le laisser un peu pour être sûr. Firestorm[https://www.firestormviewer.org/] (FS) a sorti une nouvelle beta avec le support du statut de la grille rss[https://fr.wikipedia.org/wiki/RSS] maintenant supporté dans OpenSim.
[11:11] Ubit Umarov: ah yes.. was using a generic c# exceptionto report bad string on parse
 
[11:12] Kayaker Magic: One problem with multiple fsassets is there is small chance of two of them generating the same UUID at the same time.
[11:06] '''Misterblue Waves'''  : même chose pour nous -- il est rare de dépasser les 100F(https://fr.wikipedia.org/wiki/Degr%C3%A9_Fahrenheit) (38°C).
[11:12] Ubit Umarov: changed to  FormatException to match ehat .net guid does
 
[11:12] Ubit Umarov: fs does not gen uuids
[11:06] '''Ubit Umarov'''  : j'ai fait un petit commit[https://git-scm.com/docs/git-commit/fr] lié à un flag fsassets.
[11:12] Kayaker Magic: OK, then multiple Robusts.
 
[11:13] Ubit Umarov: the thing with multiple robusts is that you do need a shared storage
[11:07] '''Ubit Umarov'''  : ou une option, en fait pas si bonne...
[11:13] Ubit Umarov: fs as no provision for any on that
 
[11:14] Ubit Umarov: each instance will just read and write from own disk
[11:07] '''Ubit Umarov'''  : pour exécuter plusieurs instances de fsassets, cela ne fonctionnera pas.
[11:14] Ubit Umarov: something that will not work that all, unless it is a special shared network disk
 
[11:14] Ubit Umarov: or you are running all that on same machine, not that useful either
[11:07] '''Ubit Umarov'''  : à moins d'avoir un disque réseau comme stockage [https://fr.wikipedia.org/wiki/Serveur_de_stockage_en_r%C3%A9seau](NAS)
[11:15] Ubit Umarov: on that fsassets is worse than just normal assets, that at least depend on mysql/maria only
 
[11:16] Ubit Umarov: fsassets multiinstances that did work, where done by spliting as per a few bits of the asset UUID
[11:07] '''Andrew Hellershanks''' : .0
[11:16] Ubit Umarov: thing we still have code for that, not sure
 
[11:17] Ubit Umarov: ofc does not work that well with the "random" guid type we are using
[11:08] '''Ubit Umarov'''  : fsasset ne fait qu'écrire des choses sur un disque, il n'a aucune idée de ce que sont les instances multiples.
[11:17] Ubit Umarov: not that random
 
[11:18] Ubit Umarov: this is why osgrid is running on own proprietary assets..
[11:08] '''Ubit Umarov'''  : les métadonnées[https://fr.wikipedia.org/wiki/M%C3%A9tadonn%C3%A9e] dépendent de mysql[https://fr.wikipedia.org/wiki/MySQL] qui fait le truc du multi serveur, ça ne semble pas très bon non plus.
[11:18] Ubit Umarov: was using a variant of fsassets, that actually also did smoke if using more than one instance
 
[11:18] Ubit Umarov: now using somthign else
[11:09] '''Ubit Umarov'''  : donc, pas si utile que ça cette option...
[11:19] Ubit Umarov: ofc no issue if you have a nove NAS machine and a 100Gbit network ;)
 
[11:19] Ubit Umarov: a nice NAS..
[11:09] '''Ubit Umarov'''  : hmm quel était l'autre ? libomv ?
[11:19] Vincent.Sylvester @hg.zetaworlds.com:8002: Given the simplicity of what that has to do in the end it's easier to write in something else that supports proper file locking out of the box I guess. Ideally directly in C to get the most speed
 
[11:20] Ubit Umarov: file lock actually seems to fail on linux
[11:10] '''Ubit Umarov'''  : hmm je suppose que c'est aussi une chose mineure.
[11:21] Ubit Umarov: that fsassets code also runs several instances on a single robust...
 
[11:21] Vincent.Sylvester @hg.zetaworlds.com:8002: It's not built-in so whatever language or code needs to handle it on its own
[11:10] '''Vincent.Sylvester @hg.zetaworlds.com:8002''' : Est-ce que le truc de fsassets est principalement un verrouillage de fichier ou quel est le problème ?
[11:21] Ubit Umarov: one as assets main instance, others as slaves that connect to it
 
[11:21] Misterblue Waves: the GUIDs are not random enough or is the content hashing not being unique?
[11:11] '''Ubit Umarov'''  : ah oui... j'utilisais une exception c# [https://fr.wikipedia.org/wiki/C_sharp] générique pour signaler une mauvaise chaîne de caractères lors de l'analyse.
[11:22] Ubit Umarov: there was still a lock issue, bc several maintnance threads could be fired in that case..
 
[11:22] Ubit Umarov: that should be ok now...
[11:12] '''Kayaker Magic'''  : Un problème avec plusieurs fsassets est qu'il y a peu de chance que deux d'entre eux génèrent le même UUID[https://fr.wikipedia.org/wiki/Universally_unique_identifier] en même temps.
[11:23] Ubit Umarov: my comments where only when ppl did tried to run several assets service instances on dif machines..
 
[11:23] Ubit Umarov: as i said, that is a fail, unless they are usiign a network shared disk
[11:12] '''Ubit Umarov'''  : changé en FormatException pour correspondre à ce que .net[https://fr.wikipedia.org/wiki/.NET_Framework] guid [https://fr.wikipedia.org/wiki/Globally_unique_identifier] fait.
[11:24] Vincent.Sylvester @hg.zetaworlds.com:8002: Or something that emulates the behavior of one I suppose
 
[11:24] Ubit Umarov: yeah
[11:12] '''Ubit Umarov'''  : fsassets ne génère pas d'uuids.
[11:24] Ubit Umarov: then ofc one needs to compare the added latency to the latency of just one...
 
[11:25] Ubit Umarov: on this, region and viewers caches are fundamental
[11:12] '''Kayaker Magic'''  : OK, alors plusieurs Robusts[http://opensimulator.org/wiki/ROBUST/fr].
[11:26] Ubit Umarov: in nomral cases, only region caches should be used
 
[11:26] Ubit Umarov: in cases on users that spend most time on a few regions, even viewer caches
[11:13] '''Ubit Umarov'''  : le problème avec des robusts multiples est que vous avez besoin d'un stockage partagé.
[11:27] Vincent.Sylvester @hg.zetaworlds.com:8002: From what I log on disk io I rarely see more than a few mbit when assets are moving, so it's not a big load until you get to hundreds of gigabytes
 
[11:27] Vincent.Sylvester @hg.zetaworlds.com:8002: Bigger problem is backing up millions of files in thousands of directories
[11:13] '''Ubit Umarov'''  : fsasset n'est pas prévu pour cela.
[11:28] Ubit Umarov: well many ppl even totally forgot that fsassets uses mysql and disk files
 
[11:28] Ubit Umarov: and lost the disk files :(
[11:14] '''Ubit Umarov'''  : chaque instance va juste lire et écrire depuis son propre disque.
[11:28] Kayaker Magic: oops! I hate it when tht happens!
 
[11:28] Misterblue Waves: would something like S3 be better -- not AWS but one of the compatible interfaces of modern hash buckets
[11:14] '''Ubit Umarov'''  : quelque chose qui ne fonctionnera pas du tout, à moins que ce soit un disque réseau partagé spécial.
[11:28] Ubit Umarov: sadly happened a few times
 
[11:29] Vincent.Sylvester @hg.zetaworlds.com:8002: It should probably use even more sql on that, things like notecards saving their description to the assets means even if they are empty the hash always differs so it creates tons of empty notecard assets
[11:14] '''Ubit Umarov'''  : ou on peut faire tourner tout cela sur la même machine, ce qui n'est pas très utile non plus.
[11:30] Vincent.Sylvester @hg.zetaworlds.com:8002: AWS is overpriced junk you'll be paying more running that than just some decent bare metal and when they lose your data you are sol
 
[11:30] Ubit Umarov: several large grids are running fine
[11:15] '''Ubit Umarov'''  : sur ce point fsassets est pire que les  assets[http://opensimulator.org/wiki/Assets] normaux, qui au moins dépendent uniquement de mysql/maria [https://fr.wikipedia.org/wiki/MariaDB].
[11:30] Ubit Umarov: some mb with own solutions
 
[11:31] Ubit Umarov: well i nev4er did like fsassets
[11:16] '''Ubit Umarov'''  : les multi-instances fsassets qui ont fonctionné, ont été installée séparant quelques bits de l'UUID de l'asset.
[11:31] Misterblue Waves: agree on AWS, but a lot of other places are providing S3 compatible storage (DigitalOcean, ...)
 
[11:31] Ubit Umarov: sure mysql is possible a bad choice
[11:16] '''Ubit Umarov'''  : a t-on toujours du code pour cela, je n'en suis pas sûr.
[11:31] Vincent.Sylvester @hg.zetaworlds.com:8002: Toying with the idea of crawling all notecards for empty <data> lines and just nuking them or setting their hash to a single one instead
 
[11:31] Ubit Umarov: inworldz did used other db engine, if i remember
[11:17] '''Ubit Umarov'''  : bien sûr, cela ne fonctionne pas très bien avec le type guid "aléatoire" que nous utilisons.
[11:32] Ubit Umarov: a more direct key,value thing
 
[11:32] Ubit Umarov: guess non sql even
[11:17] '''Ubit Umarov'''  : pas si aléatoire que cela
[11:32] Vincent.Sylvester @hg.zetaworlds.com:8002: For a few things a few data structures in OpenSim things like mongodb would work, potentially even better than sql, but then you have another db system to maintain and deal with also, so a trade off
 
[11:33] Vincent.Sylvester @hg.zetaworlds.com:8002: For avatar data and groups it might be faster, but means whole new db connector etc
[11:18] '''Ubit Umarov'''  : c'est pourquoi osgrid[https://www.osgrid.org/] fonctionne avec ses propres assets propriétaires...
[11:33] Vincent.Sylvester @hg.zetaworlds.com:8002: Already a pain to maintain the ones we have
 
[11:33] Ubit Umarov: well our dbs are a disaster
[11:18] '''Ubit Umarov'''  : j'utilisais une variante de fsassets, qui faisait aussi de la fumée si on utilisait plus d'une instance.
[11:33] Vincent.Sylvester @hg.zetaworlds.com:8002: Some, not all
 
[11:33] Ubit Umarov: guess a good example on how to make things as slow as possible
[11:18] '''Ubit Umarov'''  : maintenant j'utilise quelque chose d'autre.
[11:33] Ubit Umarov: region db ... duhh what a waste
 
[11:34] Vincent.Sylvester @hg.zetaworlds.com:8002: Inventory might also benefit from document style db rather than large table
[11:19] '''Ubit Umarov'''  : bien sûr, il n'y a pas de problème si vous avez une bonne machine NAS et un réseau 100Gbit ;)
[11:34] Vincent.Sylvester @hg.zetaworlds.com:8002: Anything bound to a single user or uuid I suppose
 
[11:35] Vincent.Sylvester @hg.zetaworlds.com:8002: Useless for assets, want a proper table with keys and indexes there
[11:19] '''Vincent.Sylvester @hg.zetaworlds.com:8002''' : Etant donné la simplicité de ce que cela doit faire au final, il est plus facile d'écrire avec quelque chose d'autre qui supporte le verrouillage des fichiers de manière appropriée, je suppose. Idéalement directement en C[https://fr.wikipedia.org/wiki/C_(langage)]pour obtenir la plus grande vitesse.
[11:35] Vincent.Sylvester @hg.zetaworlds.com:8002: Come to think of it I meant to check if different charset and collation had a performance impact on groups as it did with griduser data
 
[11:35] Vincent.Sylvester @hg.zetaworlds.com:8002: Seems mixing those things is a fail on mariadb
[11:20] '''Ubit Umarov'''  : le verrouillage des fichiers semble échouer sous linux [https://fr.wikipedia.org/wiki/Linux].
[11:36] Vincent.Sylvester @hg.zetaworlds.com:8002: Needs all uniform ones to speed up inner join
 
[11:36] Ubit Umarov: seems mariadb is a fail on anything large
[11:21] '''Ubit Umarov'''  : ce code fsassets exécute aussi plusieurs instances sur un seul robust...
[11:36] Ubit Umarov: even mysql
 
[11:36] Kayaker Magic: I have some stuff set up at OpenSim Fest, and one of the regions stopped working. Scripts froze, I was not allowed to compile my own scripts or rez more objects. Shelenn told me it was caused by an OpenSim bug that Ubit already knew about. Which bug was that?
[11:21] '''Vincent.Sylvester @hg.zetaworlds.com:8002''' : Ce n'est pas intégré, donc le langage ou le code doit le gérer lui-même.
[11:36] Ubit Umarov: only a few forks of mysql do hold, i was told
 
[11:37] Vincent.Sylvester @hg.zetaworlds.com:8002: Development has picked up pace lately so maybe that will be change positively in future
[11:21] '''Ubit Umarov'''  : une comme instance principale des assets, les autres comme esclaves qui s'y connectent.
[11:37] Misterblue Waves: I've used MariaDB successfully for small deployments (that's what I use for my Docker based regions)
 
[11:37] Ubit Umarov: no idea
[11:21] '''Misterblue Waves'''  : les GUIDs ne sont pas assez aléatoires ou le contenu n'est pas unique ?
[11:37] Ubit Umarov: they are running a thing called opensim-ngc
 
[11:37] Vincent.Sylvester @hg.zetaworlds.com:8002: If you overload a region with too many scene updates the queue for that fills up and it just stop processing completely
[11:22] '''Ubit Umarov'''  : il y avait toujours un problème de verrouillage, car plusieurs threads de maintenance pouvaient être déclenchés dans ce cas...
[11:37] Ubit Umarov: that ofc does claim to be better than core
 
[11:38] Vincent.Sylvester @hg.zetaworlds.com:8002: Not much can be done on that though
[11:22] '''Ubit Umarov'''  : ça devrait être ok maintenant...
[11:38] Ubit Umarov: so you do need to ask them :)
 
[11:38] Vincent.Sylvester @hg.zetaworlds.com:8002: scene update queue has a fixed size, once full it's full and just dies
[11:23] '''Ubit Umarov'''  : mes commentaires ne concernaient que les personnes qui essayaient de faire tourner plusieurs instances de service d'assets sur différentes machines...
[11:38] Ubit Umarov: i do not remember such issue..
 
[11:39] Vincent.Sylvester @hg.zetaworlds.com:8002: Seen that a few times, always told to remove some heavy scripts, timers and things, no more issues
[11:23] '''Ubit Umarov'''  : comme je l'ai dit, ça ne marche pas, sauf s'ils utilisent un disque partagé sur le réseau.
[11:39] Ubit Umarov: what scene updates??
 
[11:39] Vincent.Sylvester @hg.zetaworlds.com:8002: The ones generated by scripts, avatars etc. Forgot the actual name, but it's not scripts that die it's scene updates
[11:24] '''Vincent.Sylvester @hg.zetaworlds.com:8002''' : Ou quelque chose qui émule le comportement de ce type de disque, je suppose.
[11:39] Ubit Umarov: you are imagining thngs again vicent :p
 
[11:39] Ubit Umarov: events queue?
[11:24] '''Ubit Umarov'''  : Oui
[11:40] Ubit Umarov: those self limit.. do not stop things
 
[11:40] Ubit Umarov: ofc many ways a script can still freze a region..
[11:24] '''Ubit Umarov'''  : alors bien sûr il faut comparer la latence ajoutée à la latence d'un seul...
[11:40] Vincent.Sylvester @hg.zetaworlds.com:8002: You can test if its that by typing commands into the console, if it fails with some error no matter what you type you know its borked
 
[11:41] Vincent.Sylvester @hg.zetaworlds.com:8002: Reducing script load usually resolves this
[11:25] '''Ubit Umarov'''  : sur ce point, les caches de région et de viewers sont fondamentaux.
[11:41] Kayaker Magic: After they "fixed it" I was able to add more scripted items.
 
[11:41] Ubit Umarov: well i don't remember that issue on core.. possible..  but don't remember
[11:26] '''Ubit Umarov'''  : dans les cas normaux, seuls les caches des régions devraient être utilisés.
[11:42] Ubit Umarov: i mean a specific one
 
[11:42] Vincent.Sylvester @hg.zetaworlds.com:8002: You have to load the regions pretty heavily for that to happen most stay well under that or write scripts that don't cause so many updates to be fired
[11:26] '''Ubit Umarov'''  : dans le cas d'utilisateurs qui passent le plus de temps sur quelques régions, aussi les caches de viewer.
[11:43] Ubit Umarov: well i do remember regions totally down
 
[11:43] Vincent.Sylvester @hg.zetaworlds.com:8002: Doesn't happen often enough to really warrant looking into it that much. Easier to just write better scripts
[11:27] '''Vincent.Sylvester @hg.zetaworlds.com:8002''' : D'après ce que j'enregistre sur disk i/o[https://fr.wikipedia.org/wiki/Entr%C3%A9es-sorties], je vois rarement plus de quelques mbits lorsque les assets sont déplacés, ce n'est donc pas une charge importante pour atteindre des centaines de gigaoctets.
[11:43] Ubit Umarov: jst because a simple LED scritp
 
[11:43] Ubit Umarov: we jsut could not tp in the region or nearby ones :)
[11:27] '''Vincent.Sylvester @hg.zetaworlds.com:8002''' : Le plus gros problème est de sauvegarder des millions de fichiers dans des milliers de répertoires.
[11:44] Ubit Umarov: similar script will do the same still
 
[11:44] Vincent.Sylvester @hg.zetaworlds.com:8002: I have only seen this on a region with like 90k prims and over 8000 scripts
[11:28] '''Ubit Umarov'''  : beaucoup de gens ont même oublié que fsassets utilise mysql avec des fichiers disques.
[11:44] Ubit Umarov: change glow or color etc on a prim is a full update
 
[11:44] Ubit Umarov: that region had like 1000 LEDs :)
[11:28] '''Ubit Umarov'''  : et ont perdu les fichiers du disque :(
[11:45] Ubit Umarov: we all see that issue at xmas.. with some bad xmas lights
 
[11:45] Vincent.Sylvester @hg.zetaworlds.com:8002: Could probably find the queue and figure out what the max size is and add some debug to alert when it gets close to full
[11:28] '''Kayaker Magic'''  : oops ! Je déteste quand ça arrive !
[11:45] Vincent.Sylvester @hg.zetaworlds.com:8002: Just never looked where that is
 
[11:46] Ubit Umarov: there you are again with a queue... waht queue??
[11:28] '''Misterblue Waves'''  : quelque chose comme S3[https://fr.wikipedia.org/wiki/Amazon_S3] serait mieux -- pas AWS[https://fr.wikipedia.org/wiki/Amazon_Web_Services] mais l'une des interfaces compatibles des hash buckets modernes.
[11:46] Ubit Umarov: there are several
 
[11:46] Kayaker Magic: After seeing some bad xmas light scripts, I build some ZERO LAG ones that use texture animation to blink.
[11:28] '''Ubit Umarov'''  : c'est malheureusement arrivé plusieurs fois.
[11:46] Ubit Umarov: and none a issue
 
[11:47] Ubit Umarov: yes  blink needs to be done with clever tex anim
= Les bases de données =
[11:48] Vincent.Sylvester @hg.zetaworlds.com:8002: When a script moves a prim, that gets added to a queue as a scene update, usually gets processed almost immediately unless you have a lot of those updates happening
* Documentation OpenSim de la Base de données  : http://opensimulator.org/wiki/Database:Documentation (en)
[11:48] Ubit Umarov: wel it is a old issue, also at SL
* MariaDB : https://fr.wikipedia.org/wiki/MariaDB
[11:48] Vincent.Sylvester @hg.zetaworlds.com:8002: Not sure where in code that is I never looked much into it
* Mysql : https://fr.wikipedia.org/wiki/MySQL
[11:48] Ubit Umarov: lludp updates queue per user??
* MongoDB : https://fr.wikipedia.org/wiki/MongoDB
[11:49] Ubit Umarov: well those are heavy..  but a major issue currently
* sql : [https://sql.sh/]
[11:49] Vincent.Sylvester @hg.zetaworlds.com:8002: Possible, all I know is it's something that fills up and then overloads stopping update processing because you can still walk around and chat, but scripts appear as if they are stopped
* Collation  : énumération de signes typographiques avec leurs équivalences, afin d’en déduire le comportement des chaînes de caractères notamment dans les opérations de comparaison et de tri spécifiques à une langue.— (Frédéric Brouard, Rudi Bruchez, Christian Soutou, SQL, Pearson Education France, 13 juillet 2012)[https://fr.wiktionary.org/wiki/collation]
[11:49] Ubit Umarov: they do not fill up
 
[11:49] Ubit Umarov: ma fill your machine ram :p
[11:29] '''Vincent.Sylvester @hg.zetaworlds.com:8002''' : Il devrait probablement utiliser encore plus de sql pour cela, pour des choses comme les notecards  qui enregistrent leur description dans des assets ce qui implique que, même si elles sont vides, le hash[https://fr.wikipedia.org/wiki/Fonction_de_hachage] est toujours différent, ce qui crée des tonnes d'assets de notecards vides.
[11:50] Vincent.Sylvester @hg.zetaworlds.com:8002: As it doesn't happen immediately and only when more scripts and people are on the region tells me it's some processing for the updates done on scene
 
[11:50] Vincent.Sylvester @hg.zetaworlds.com:8002: Usually just writing better scripts and reducing the load fixes this
[11:30] '''Vincent.Sylvester @hg.zetaworlds.com:8002''' : AWS, c'est de la camelote hors de prix, vous paierez plus cher pour l'utiliser que pour un simple serveur matériel décent et quand ils perdent vos données, vous êtes foutu.
[11:50] Ubit Umarov: scripts need to be good
 
[11:51] Vincent.Sylvester @hg.zetaworlds.com:8002: You can have a region with hundreds of thousands of prims and one script that kills it
[11:30] '''Ubit Umarov'''  : plusieurs grandes grilles fonctionnent bien.
[11:51] Ubit Umarov: a single bad script can stop a region, as i said
 
[11:51] Ubit Umarov: .. still...
[11:30] '''Ubit Umarov'''  : quelques mb avec leurs propres solutions
[11:51] Ubit Umarov: specially using some OSSL there should had never need added
 
[11:51] Ubit Umarov: details..
[11:31] '''Ubit Umarov'''  : Je n'ai jamais aimé  fsassets.
[11:51] Kayaker Magic: A bad programmer can write FORTRAN in any language;.
 
[11:52] Vincent.Sylvester @hg.zetaworlds.com:8002: Writing stuff for light changing and animations can be insanely heavy
[11:31] '''Misterblue Waves'''  : d'accord pour AWS, mais beaucoup d'autres fournisseurs proposent un stockage compatible S3 (DigitalOcean[https://en.wikipedia.org/wiki/DigitalOcean](en), ...)
[11:52] Andrew Hellershanks: Hello, everyone. Finally off the phone call. :P  Last part of it was giving the person directions to the place they were driving to as it turned out they were headed north when they should have been going south.
 
[11:52] Vincent.Sylvester @hg.zetaworlds.com:8002: Still writing on danceballs and other lighting stuff I check what cpu does, sometimes a poorly written line gives me 100% cpu heh
[11:31] '''Ubit Umarov'''  : bien sûr mysql est peut-être un mauvais choix.
[11:53] Andrew Hellershanks: Vincent, doesn't take much to do that.
 
[11:53] Vincent.Sylvester @hg.zetaworlds.com:8002: In the same tune if you can figure out what it does internally you can change a color 60 times a second without much load
[11:31] '''Vincent.Sylvester @hg.zetaworlds.com:8002''' : Je suis en train de jouer avec l'idée d'explorer toutes les notecards à la recherche de lignes <data> vides et de les détruire ou de mettre leur hash à une seule place.
[11:54] Andrew Hellershanks: I have been helping people do some X and Y engine compatibility tests this past week. Their scripts trigger an exception in YEngine during compilation. Not sure what is causing that. Runtime I was getting an out of heap exception.
 
[11:55] Vincent.Sylvester @hg.zetaworlds.com:8002: lol ouch
[11:31] '''Ubit Umarov'''  : inworldz a utilisé un autre moteur de base de données, si je me souviens bien.
[11:55] Vincent.Sylvester @hg.zetaworlds.com:8002: That takes some serious effort
 
[11:55] Andrew Hellershanks: Looking at the OS code I found some ini settings to change heap sizes and that solved the heap issue.
[11:32] '''Ubit Umarov''' : un truc plus direct de type clé et valeur.
[11:55] Andrew Hellershanks: Still no idea about the compile time error.
 
[11:55] Ubit Umarov: ohh really?
[11:32] '''Ubit Umarov'''  : je pense qu'il n'y a même pas de sql.
[11:55] Ubit Umarov: mab next time RTFM ?
 
[11:55] Ubit Umarov: maybe.. :p
[11:32] '''Vincent.Sylvester @hg.zetaworlds.com:8002''' : Pour certaines choses, quelques structures de données dans OpenSim, des choses comme mongodb  fonctionneraient, potentiellement  mieux que sql, mais alors on a un autre système de base de données à maintenir et à gérer aussi, donc un compromis...
[11:56] Andrew Hellershanks: Ubit, yes. There are ini settings for setting stack and heap sizes in YEngine but they aren't listed in the ini file.
 
[11:56] Vincent.Sylvester @hg.zetaworlds.com:8002: The compiler errors are usually very descriptive unless you broke something internally
[11:33] '''Vincent.Sylvester @hg.zetaworlds.com:8002''' : Pour les données des avatars et des groupes, cela pourrait être plus rapide, mais cela implique un tout nouveau connecteur de base de données, etc.
[11:56] Vincent.Sylvester @hg.zetaworlds.com:8002: You ideally shouldn't need to adjust heap at all
 
[11:56] Kayaker Magic: If people use old OpenSim.ini settings for YEngine heap sizes, that can cause the problem you describe
[11:33] '''Vincent.Sylvester @hg.zetaworlds.com:8002''' : c'est déjà une douleur de maintenir ceux que nous avons
[11:56] Andrew Hellershanks: The error is the generic one -> NullReferenceException: Object reference not set to an instance of an object
 
[11:57] Vincent.Sylvester @hg.zetaworlds.com:8002: Also I think latest release should have proper heap size calc in there, was a bug on that before
[11:33] '''Ubit Umarov'''  : Nos bases de données sont un désastre.
[11:57] Ubit Umarov: http://opensimulator.org/wiki/YEngine
 
[11:57] Ubit Umarov: "Memory heap and stack use control"  very clear there
[11:33] '''Vincent.Sylvester @hg.zetaworlds.com:8002''' : Certaines, pas toutes
[11:57] Vincent.Sylvester @hg.zetaworlds.com:8002: Always test with release or master code
 
[11:58] Vincent.Sylvester @hg.zetaworlds.com:8002: I'd be curious to see that script and figure out where it generates all that heap
[11:33] '''Ubit Umarov'''  : un bon exemple de comment rendre les choses aussi lentes que possible.
[11:58] Andrew Hellershanks: YEngine will accept ini settings to set the stack and heap sizes but those settings are not in the existing ini files.
 
[11:58] Vincent.Sylvester @hg.zetaworlds.com:8002: Haven't had a single script hit those limits yet
[11:33] '''Ubit Umarov'''  : region db[http://opensimulator.org/wiki/Regions_(database_table)] ... duhhh quel gaspillage
[11:58] Vincent.Sylvester @hg.zetaworlds.com:8002: Well outside of testing for it specifically
 
[11:58] Andrew Hellershanks: I'm not as concerned about the heap issue as much as I am about the exception when trying to compile the code.
[11:34] '''Vincent.Sylvester @hg.zetaworlds.com:8002''' : L'inventaire pourrait également bénéficier d'une base de données de type document plutôt que de grandes tables.
[11:59] Vincent.Sylvester @hg.zetaworlds.com:8002: Yeah that you kinda need to have a debugger connected to it I guess
 
[11:59] Andrew Hellershanks: I found the YEngine has some settings for debug modes but the debug ones that are supposed to save the original script and save the IL file don't seem to work (or the file was saved somewhere other than I expected).
[11:34] '''Vincent.Sylvester @hg.zetaworlds.com:8002''' : Tout ce qui est lié à un seul utilisateur ou uuid, je suppose.
[12:00] Ubit Umarov: they are at opensimdefaults.ini
 
[12:00] Vincent.Sylvester @hg.zetaworlds.com:8002: Mean like visual studio to see directly in code where it barfs
[11:35] '''Vincent.Sylvester @hg.zetaworlds.com:8002''' : Inutile pour les assets, il faut une vraie table avec des clés et des index à ce niveau.
[12:00] Andrew Hellershanks: Vincent, Yes, that is what I was planning on doing. I might add some extra debug code as the backtrace tells me where it dies.
 
[12:01] Vincent.Sylvester @hg.zetaworlds.com:8002: If you get anywhere with it feel free to mantis it so others can test as well, more brains the better to figure illusive things like that out
[11:35] '''Vincent.Sylvester @hg.zetaworlds.com:8002''' : En y réfléchissant, je voulais vérifier si le jeu de caractères et la collation avaient un impact sur les performances des groupes, comme c'est le cas pour les données de griduser[http://opensimulator.org/wiki/GridUser].
[12:01] Ubit Umarov: yeah to read the IL will help you a lot :p
 
[12:01] Andrew Hellershanks: I didn't write the two scripts in question. One is almost 4600 lines line.
[11:35] '''Vincent.Sylvester @hg.zetaworlds.com:8002''' : Il semble que le regroupement de ces éléments soit un échec dans mariadb.
[12:02] Andrew Hellershanks: Ubit, I know. I was just hoping to find something that might help narrow down what is triggering the exception.
 
[12:02] Andrew Hellershanks: A debugger or adding in extra debug messages may be my best option.
[11:36] '''Vincent.Sylvester @hg.zetaworlds.com:8002''' : Cela nécessite  des éléments uniformes pour accélérer inner join [https://sql.sh/cours/jointures/inner-join].
[12:02] Ubit Umarov: x had no control of mem usage
 
[12:03] Vincent.Sylvester @hg.zetaworlds.com:8002: If they are that long maybe what you are seeing is the fail on the heap allocation itself
[11:36] '''Ubit Umarov'''  : il semble que mariadb est défaillante pour tout ce qui est volumineux.
[12:03] Ubit Umarov: so it is normal that some scripts will try to eat all memory
 
[12:03] Andrew Hellershanks: It had a 256k stack size setting in the ini but that was about it.
[11:36] '''Ubit Umarov'''  : même mysql
[12:03] Vincent.Sylvester @hg.zetaworlds.com:8002: You almost have as bad a luck with bugs as I do lol
 
[12:03] Ubit Umarov: Y controls stack and heap
[11:36] '''Ubit Umarov'''  : seuls quelques forks de mysql tiennent, m'a-t-on dit.
[12:04] Andrew Hellershanks: Vincent, that's what I'm thinking. it would have been nicer if it had said that in the first place and not just no ref to object.
 
[12:04] Andrew Hellershanks: Vincent, only when it isn't my code.
[11:37] '''Vincent.Sylvester @hg.zetaworlds.com:8002''' : Le développement s'est accéléré ces derniers temps, alors peut-être que cela va changer positivement à l'avenir.
[12:04] Ubit Umarov: and yes in same cases ppl need to make those very large to run old X scripts
 
[12:04] Selby.Evans @grid.kitely.com:8002: byr all
[11:37] '''Misterblue Waves'''  : J'ai utilisé MariaDB avec succès pour de petits déploiements (c'est ce que j'utilise pour mes régions installée avec Docker [https://fr.wikipedia.org/wiki/Docker_(logiciel)]).
[12:04] Andrew Hellershanks: This is part of a compatibility test to see what changes (if any) need to be made to the script so it works in YEngine.
 
[12:05] Ubit Umarov: well assuming it did fail by controled Yengined stach overflow
= Script tueur de région =
[12:05] Kayaker Magic: Bye Selby!
 
[12:05] Ubit Umarov: cya Selby.Evans
[11:36] '''Kayaker Magic'''  : J'ai quelques trucs mis en place pour OpenSim Fest, et une des régions a cessé de fonctionner. Les scripts ont gelé, je n'avais pas de droit de compiler mes propres scripts ou à recharger plus d'objets. Shelenn m'a dit que c'était dû à un bug d'OpenSim que Ubit connaissait déjà. Quel bug était-ce ?
[12:05] Andrew Hellershanks: Selby, ok. Thanks for being here.
 
[12:05] Ubit Umarov: it may had crash because native stack overflow :)
[11:37] '''Ubit Umarov'''  : aucune idée
[12:05] Vincent.Sylvester @hg.zetaworlds.com:8002: Well my best guess is that with scripts that long there is probably something in there not up to proper LSL standard and it's barfing on that. I have seen a lot of old scripts written under X perform poorly because they used bad list appends and such things. Fixing those and writing in proper LSL standard you get performance and less issues with memory consumption
 
[12:05] Ubit Umarov: well when ubode does that, it is very visible :)
[11:37] '''Ubit Umarov'''  : ils utilisent une chose appelée opensim-ngc (https://github.com/OpenSim-NGC][https://fr.wikipedia.org/wiki/Fork_(d%C3%A9veloppement_logiciel)].
[12:06] Vincent.Sylvester @hg.zetaworlds.com:8002: Rewriting script that large not so easy of course, might be better to just lint it a bit
 
[12:07] Andrew Hellershanks: Vincent, That is part of my question. Is it something bad in the script or something in the YEngine code. I wasn't expecting an exception during what I think is just the compilation phase.
[11:37] '''Vincent.Sylvester @hg.zetaworlds.com:8002''' : Si on surcharge une région en provoquant trop de mises à jour de scènes, la file d'attente pour cela se remplit et le traitement s'arrête complètement.
[12:08] Ubit Umarov: well it depends on what you call exception
 
[12:08] Ubit Umarov: "exception" can be a lot of things
[11:37] '''Ubit Umarov'''  : qui, bien sûr, prétend être meilleur que le projet de base (le noyau).
[12:08] Vincent.Sylvester @hg.zetaworlds.com:8002: Line 2547 probably and maybe the list append on line 574, need to see the script to determine that really
 
[12:08] Andrew Hellershanks: What I call an exception is that thing that is reported by YEngine as ...Exception in the error message.
[11:38] '''Vincent.Sylvester @hg.zetaworlds.com:8002''' : Il n'y a pas grand chose à faire à ce niveau.
[12:09] Ubit Umarov: it usually tells more
 
[12:10] Vincent.Sylvester @hg.zetaworlds.com:8002: Well null reference errors are something you see on parts of code that try to get properties or iterate for example. It tells you a reference is missing which means whatever code is trying to interact with an object the object has changed format for example. That's just one way that can happen though. Given it runs out of heap perhaps internal structures like list sizes are exceeded when it allocates space for them so the reference to each item falls apart
[11:38] '''Ubit Umarov'''  : donc tu dois leur demander :)
[12:10] Andrew Hellershanks: Sure. There is a backtrace.
 
[12:11] Ubit Umarov: it is on on compile that it has nothing to do with those script memory settings
[11:38] '''Vincent.Sylvester @hg.zetaworlds.com:8002''' : la file d'attente de mise à jour des scènes a une taille fixe, une fois pleine, elle est pleine et meurt.
[12:11] Ubit Umarov: if it is..
 
[12:11] Kayaker Magic: Andrew: I just looked up YEngine stack and heap sizes, the recommended values are 2048 and 1024, This changed at one point, it sounds like you had the old smaller values.
[11:38] '''Ubit Umarov'''  : Je ne me souviens pas d'un tel problème...
[12:11] Ubit Umarov: Grrr
 
[12:11] Ubit Umarov: he now said it is on compile..
[11:39] '''Vincent.Sylvester @hg.zetaworlds.com:8002''' : J'ai vu cela plusieurs fois, on m'a toujours dit de supprimer certains scripts lourds, des timers [https://wiki.secondlife.com/wiki/Timer/fr] et autres, et il n'y a plus de problèmes.
[12:12] Ubit Umarov: just need to read the damm message
 
[12:12] Andrew Hellershanks: The first error I ran in to was the Exception that appeared when I told the viewer I wanted to compile the scripts. Once I received an updated version of the code I just got the HeapException error.
[11:39] '''Ubit Umarov'''  : quelles mises à jour de la scène ??
[12:12] Vincent.Sylvester @hg.zetaworlds.com:8002: ... we be poking in the dark here without script and logs basically, if you cannot figure it out this week just mantis it :)
 
[12:12] Ubit Umarov: sure, some are still criptic..
[11:39] '''Vincent.Sylvester @hg.zetaworlds.com:8002''' : Celles qui sont générées par les scripts, les avatars, etc. J'ai oublié le nom exact, mais ce ne sont pas les scripts qui meurent, ce sont les mises à jour des scènes.
[12:13] Object: Script running
 
[12:13] Andrew Hellershanks: Now that I have doubled the heap size I will try compiling the scripts once again on the original version of code in case the no ref to object exception is also heap related.
[11:39] '''Ubit Umarov''' : tu imagines encore des choses vincent :p
[12:14] Ubit Umarov: no ref to object is a more severl thing
 
[12:14] Ubit Umarov: just get the full error
[11:39] '''Ubit Umarov'''  : la file d'attente des événements[https://wiki.secondlife.com/wiki/Category:LSL_Events/fr] ?
[12:15] Andrew Hellershanks: I would discuss it in the IRC channel but I still can't reach the channel since the nationwide Internet outage on Friday.
 
[12:15] Ubit Umarov: oh?
[11:40] '''Ubit Umarov'''  : ces auto limites... n'arrêtent pas les choses.
[12:16] Vincent.Sylvester @hg.zetaworlds.com:8002: Just mantis it if you get nowhere with it this week or something, better get more brains looking over it and I been cleaning up the mantis as best as I can so feel free to add lol
 
[12:16] Andrew Hellershanks: yea. A major Internet and cell phone provider experience an outage on Friday starting around 5am. I didn't get Internet back until around 10:30pm. Some people were expected to be out as many as 3 days.
[11:40] '''Ubit Umarov'''  : bien sûr, un script peut toujours geler une région de plusieurs manières...
[12:16] Vincent.Sylvester @hg.zetaworlds.com:8002: BGP again they say
 
[12:16] Ubit Umarov: wel in this case, a mantis without the scropt to repo is a problem
[11:40] '''Vincent.Sylvester @hg.zetaworlds.com:8002''' : Tu peux tester si c'est ça en tapant des commandes dans la console, si ça échoue avec une erreur, peu importe ce que tu tapes, tu sais que c'est bloqué.
[12:16] Ubit Umarov: script..
 
[12:17] Ubit Umarov: and provide the script, specially a large one, can be a issue
[11:41] '''Vincent.Sylvester @hg.zetaworlds.com:8002''' : La réduction de la charge des scripts résout généralement ce problème.
[12:17] Andrew Hellershanks: Vincent, sure. My notes say that even with the larger heap size it still throws an exception when I ask for the scripts to be compiled.
 
[12:17] Vincent.Sylvester @hg.zetaworlds.com:8002: Script and logs, well steps to reproduce and logs in most cases
[11:41] '''Kayaker Magic'''  : Après qu'ils l'aient "corrigé", j'ai pu ajouter plus d'objets scriptés.
[12:17] Ubit Umarov: ohh
 
[12:17] Andrew Hellershanks: If I am allowed to provide the script I will mark it private.
[11:41] '''Ubit Umarov'''  : Je ne me souviens pas de ce problème sur le noyau... possible... mais je ne m'en souviens pas...
[12:18] Ubit Umarov: it may just be a missing script
 
[12:18] Kayaker Magic: Finding a small script to reproduce an error is often difficult.
[11:42] '''Ubit Umarov'''  : Je veux dire un problème spécifique.
[12:18] Ubit Umarov: that may give a null ref error
 
[12:18] Andrew Hellershanks: To repro the problem just right click object, more, more, scripts, compile (Mono).
[11:42] '''Vincent.Sylvester @hg.zetaworlds.com:8002''' : Tu dois charger les régions assez lourdement pour que cela se produise. La plupart restent bien en dessous de cela ou écrivent des scripts qui ne provoquent pas autant de mises à jour.
[12:18] Ubit Umarov: yeap sounds like a missing script asset
 
[12:18] Ubit Umarov: read the error message
[11:43] '''Ubit Umarov'''  : Je me souviens de régions complètement à plat.
[12:19] Andrew Hellershanks: at OpenSim.Region.ScriptEngine.Yengine.XMRInstance.PostEvent (OpenSim.Region.ScriptEngine.Shared.EventParams evt) [0x0001f] in XMRInstRun.cs:69
 
[12:19] Andrew Hellershanks: at (wrapper remoting-invoke-with-check) OpenSim.Region.ScriptEngine.Yengine.XMRInstance.PostEvent(OpenSim.Region.ScriptEngine.Shared.EventParams)
[11:43] '''Vincent.Sylvester @hg.zetaworlds.com:8002''' : Cela n'arrive pas assez souvent pour justifier un examen approfondi. Il est plus facile d'écrire de meilleurs scripts.
[12:19] Andrew Hellershanks: etc...
 
[12:19] Vincent.Sylvester @hg.zetaworlds.com:8002: Most obvious problem with that used to be too small packet size on the database to store the asset
[11:43] '''Ubit Markov''' : simplement à cause d'un simple script de LED.
[12:19] Andrew Hellershanks: I'll see if I can learn anything more about it and mantis.
 
[12:20] Ubit Umarov: on a post event?
[11:43] '''Ubit Umarov'''  : nous ne pouvions plus nous tp dans la région ou les régions voisines :)
[12:20] Ubit Umarov: odd
 
[12:20] Andrew Hellershanks: hm... now that is an intereting thought, Vincent.
[11:44] '''Ubit Umarov'''  : un script similaire fera toujours la même chose.
[12:20] Ubit Umarov: well can't guess
 
[12:20] Ubit Umarov: and that is running it
[11:44] '''Vincent.Sylvester @hg.zetaworlds.com:8002''' : Je n'ai vu cela que sur une région avec environ 90k prims et plus de 8000 scripts.
[12:20] Andrew Hellershanks: The text of the script as sitting on my computer is 211772 bytes long.
 
[12:21] Ubit Umarov: or starting
[11:44] '''Ubit Umarov'''  : changer l'éclat ou la couleur etc. d'une prim est une mise à jour complète.
[12:21] Vincent.Sylvester @hg.zetaworlds.com:8002: Used to have like 16mb of max packet size on older mysql versions, since then it was increased default value should be much higher now like 1G even on some flavors
 
[12:22] Ubit Umarov: well scripts used to have a limit of 64k bytes on sources
[11:44] '''Ubit Umarov'''  : cette région avait peut-être 1000 LEDs :)
[12:22] Vincent.Sylvester @hg.zetaworlds.com:8002: Was big fail on HG assets back then
 
[12:22] Andrew Hellershanks: Ubit, It does look a bit more like it is an issue after the script starts to run. Something to do with llMessageLinked. I am thinking of adding extra code in to LSL_Api.cs to print out what the function receives.
[11:45] '''Ubit Umarov''' : nous avons tous vu ce problème à Noël... avec de mauvaises lumières de Noël.
[12:23] Ubit Umarov: but that seems is needs a more detailed debug
 
[12:23] Andrew Hellershanks: The Engine is dying and not leaving any useful information about what line of the script it was trying to run at the time it die.d
[11:45] '''Vincent.Sylvester @hg.zetaworlds.com:8002''' : On pourrait probablement trouver la file d'attente et déterminer quelle est la taille maximale et ajouter un débogage pour alerter lorsqu'elle est proche du plein.
[12:23] Ubit Umarov: that is not on lsl_api
 
[12:23] Andrew Hellershanks: I was hoping one of the Debug settings would help.
[11:45] '''Vincent.Sylvester @hg.zetaworlds.com:8002''' : Je n'ai jamais regardé où c'était.
[12:23] Andrew Hellershanks: llMessageLinked is not in LSL_Api.cs??
 
[12:23] Ubit Umarov: and it is that one ?
[11:46] '''Ubit Umarov'''  : tu es encore là avec une file d'attente... quelle file d'attente ??
[12:24] Andrew Hellershanks: That function is mentioned further down in the backtrace.
 
[12:24] Ubit Umarov: well i can't guess what you didn't told :p
[11:46] '''Ubit Umarov'''  : il y en a plusieurs.
[12:24] Vincent.Sylvester @hg.zetaworlds.com:8002: It's like a fox hunt with an invisible fox
 
[12:25] Ubit Umarov: nahh just very bad problem report
[11:46] '''Kayaker Magic'''  : Après avoir vu quelques mauvais scripts de lumières de Noël, j'ai écrit des scripts ZERO LAG qui utilisent des animations de textures pour clignoter [https://wiki.secondlife.com/wiki/LlSetLinkTextureAnim].
[12:25] Ubit Umarov: :p
 
[12:26] Vincent.Sylvester @hg.zetaworlds.com:8002: If you don't get anywhere debugging it mantis it, if they don't want to share set it to private so at least Ubit can have a look at it
[11:46] '''Ubit Umarov'''  : et aucun problème.
[12:26] Andrew Hellershanks: Yes, the script would have to be marked private.
 
[12:27] Vincent.Sylvester @hg.zetaworlds.com:8002: Dirty secrets lol
[11:47] '''Ubit Umarov'''  : oui le clignotement doit être fait avec une animation de texture intelligente.
[12:27] Andrew Hellershanks: Proprietary code that is part of a larger system.
 
[12:28] Vincent.Sylvester @hg.zetaworlds.com:8002: Hopefully not some multi pose animation thing, haven't seen a single one written properly yet they are all massively over complicated and poorly written to the point they consume a ton of resources
[11:48] '''Vincent.Sylvester @hg.zetaworlds.com:8002''' : Quand un script déplace une prim, cela est ajouté à une file d'attente comme une mise à jour de la scène, généralement traitée presque immédiatement, sauf si on a beaucoup de ces mises à jour.
[12:28] Vincent.Sylvester @hg.zetaworlds.com:8002: Some just don't even work anymore under Y
 
[12:29] Vincent.Sylvester @hg.zetaworlds.com:8002: Or use ossl functions that need to be set true
[11:48] '''Ubit Umarov'''  : il s'agit d'un vieux problème, également chez SL.
[12:29] Andrew Hellershanks: Vincent, interesting that they some don't work in Y (assuming it isn't just perms).
 
[12:29] Vincent.Sylvester @hg.zetaworlds.com:8002: They fail on the lists they generate or on typecasts
[11:48] '''Vincent.Sylvester @hg.zetaworlds.com:8002''' : Je ne suis pas sûr de l'endroit du code où cela se trouve, je ne l'ai jamais beaucoup étudié.
[12:29] Andrew Hellershanks: Probably not too surprising though.
 
[12:30] Andrew Hellershanks: oh, right. Probably ones that use the "memory saving trick".
[11:48] '''Ubit Umarov'''  : lludp[http://opensimulator.org/wiki/LLUDP_ClientStack/fr] met à jour la queue par utilisateur ??
[12:30] Vincent.Sylvester @hg.zetaworlds.com:8002: Also prime suspects for that "scripts stopped working" thing I mentioned earlier
 
[12:30] Vincent.Sylvester @hg.zetaworlds.com:8002: Oh yeah when that happens the things like llSetText also don't update so there is a hint at which queue that is
[11:49] '''Ubit Umarov'''  : c'est  lourd, c'est un problème majeur actuellement.
[12:31] Vincent.Sylvester @hg.zetaworlds.com:8002: But yeah if you don't get anywhere just make a private mantis ticket for it
 
[12:32] Ubit Umarov: yeha guess that will take some deeper debug
[11:49] '''Vincent.Sylvester @hg.zetaworlds.com:8002''' : Possible, tout ce que je sais c'est que c'est quelque chose qui se remplit et qui surcharge en arrêtant le traitement des mises à jour parce qu'on peut toujours se promener et chatter, mais les scripts apparaissent comme s'ils étaient arrêtés.
[12:33] Misterblue Waves: gotta run... take care all
 
[12:33] Ubit Umarov: cya
[11:49] '''Ubit Umarov'''  : ils ne se remplissent pas.
[12:34] Andrew Hellershanks: As long as I can still access the mantis. Don't know why I still can't access the IRC channels.
 
[12:34] Ubit Umarov: but that means there are more scripts
[11:49] '''Ubit Umarov'''  : ils remplissent la RAM de ta machine :p
[12:34] Andrew Hellershanks: ok, Misterblue.
 
[12:34] Andrew Hellershanks: We are now half past the hour. Unless there is any last minute items I will wrap up the meeting.
[11:50] '''Vincent.Sylvester @hg.zetaworlds.com:8002''' : Comme cela ne se produit pas immédiatement et seulement lorsqu'il y a plus de scripts et de personnes sur la région, cela me faire dire que c'est un traitement  lié à la mises à jour de  la scène.
[12:34] Ubit Umarov: on the linkset
 
[12:35] Ubit Umarov: so guess the entire object will be needed to debug
[11:50] '''Vincent.Sylvester @hg.zetaworlds.com:8002''' : En général, il suffit d'écrire de meilleurs scripts et de réduire la charge pour résoudre ce problème.
[12:37] Andrew Hellershanks: ok, I'll call this one done and dusted. :)   Thank you all for coming. See you again next week.
 
</pre>
[11:50] '''Ubit Umarov'''  : les scripts doivent être bons.
 
[11:51] '''Vincent.Sylvester @hg.zetaworlds.com:8002''' : On peut avoir une région avec des centaines de milliers de prims et un seul script qui la tue.
 
[11:51] '''Ubit Umarov'''  : un seul mauvais script peut arrêter une région, comme je l'ai dit.
 
[11:51] '''Ubit Umarov'''  : ... toujours...
 
[11:51] '''Ubit Umarov'''  : spécialement en utilisant des OSSL [http://opensimulator.org/wiki/OSSL](en) qui n'auraient jamais dû être ajoutées.
 
[11:51] '''Ubit Umarov'''  : détails...
 
[11:51] '''Kayaker Magic'''  : Un mauvais programmeur peut écrire FORTRAN dans n'importe quel langage ;.
 
[11:52] '''Vincent.Sylvester @hg.zetaworlds.com:8002''' : Ecrire des trucs pour les changements de lumière et les animations peut être incroyablement lourd.
 
[11:52] '''Andrew Hellershanks'''  : Bonjour à tous. J'ai enfin terminé l'appel téléphonique :P La dernière partie de l'appel consistait à donner à la personne des indications sur l'endroit où elle se rendait en voiture, car il s'est avéré qu'elle se dirigeait vers le nord alors qu'elle aurait dû aller vers le sud.
 
[11:52] '''Vincent.Sylvester @hg.zetaworlds.com:8002''' : Je scripte toujours  des boules de danse et d'autres trucs d'éclairage. Je vérifie ce que fait le cpu, parfois une ligne mal écrite me donne 100% de cpu heh.
 
[11:53] '''Andrew Hellershanks'''  : Vincent, il ne faut pas grand-chose pour faire ça.
 
[11:53] '''Vincent.Sylvester @hg.zetaworlds.com:8002''' : Dans le même esprit, si on arrive à comprendre ce qui se passe en interne, on peut changer une couleur 60 fois par seconde sans trop de charge.
 
= Script : erreur out of heap =
* Moteur de scripts Xengine : http://opensimulator.org/wiki/Xengine/fr
* Moteur de scripts Yengine : http://opensimulator.org/wiki/YEngine/fr
* Tas : En informatique, un tas1 (ou monceau au Canada2, heap en anglais) est une structure de données de type arbre qui permet de retrouver directement l'élément que l'on veut traiter en priorité. [https://fr.wikipedia.org/wiki/Tas_(informatique)]
* Pile : En informatique, une pile (en anglais stack) est une structure de données fondée sur le principe « dernier arrivé, premier sorti » (en anglais LIFO pour last in, first out), ce qui veut dire qu'en général, le dernier élément ajouté à la pile est le premier à en sortir1. [https://fr.wikipedia.org/wiki/Pile_(informatique)]
* Fichiers ini : http://opensimulator.org/wiki/Configuring_Scripting/fr#Fichiers_ini_importants
* opensimdefaults.ini  : <dossier du simulateur>bin/opensimdefaults.ini
 
[11:54] '''Andrew Hellershanks'''  : J'ai aidé des gens à faire des tests de compatibilité entre les moteurs X et Y la semaine dernière. Leurs scripts déclenchent une exception dans YEngine pendant la compilation. Je ne suis pas sûr de la cause de ce problème. Au moment de l'exécution, j'obtenais une exception out of heap.
 
[11:55] '''Vincent.Sylvester @hg.zetaworlds.com:8002''' : lol ouch
 
[11:55] '''Vincent.Sylvester @hg.zetaworlds.com:8002''' : Cela demande de sérieux efforts.
 
[11:55] '''Andrew Hellershanks'''  : En regardant le code du système d'exploitation, j'ai trouvé des paramètres ini pour changer la taille du tas et cela a résolu le problème du tas.
 
[11:55] '''Andrew Hellershanks'''  : Toujours aucune idée sur l'erreur de compilation.
 
[11:55] '''Ubit Umarov'''  : ohh vraiment ?
 
[11:55] '''Ubit Umarov'''  : la prochaine fois RTFM [https://fr.wikipedia.org/wiki/RTFM_(expression)]?
 
[11:55] '''Ubit Umarov'''  : peut-être... :p
 
[11:56] '''Andrew Hellershanks'''  : Ubit, oui. Il y a des paramètres ini pour définir la taille de la pile et du tas dans YEngine mais ils ne sont pas listés dans le fichier ini.
 
[11:56] '''Vincent.Sylvester @hg.zetaworlds.com:8002''' : Les erreurs du compilateur sont généralement très explicites, sauf si on a cassé quelque chose en interne.
 
[11:56] '''Vincent.Sylvester @hg.zetaworlds.com:8002''' : Idéalement, on ne devrait pas avoir besoin d'ajuster le heap du tout.
 
[11:56] '''Kayaker Magic'''  : Si les gens utilisent les anciens paramètres de OpenSim.ini pour les tailles de heap de YEngine, cela peut causer le problème que tu décris.
 
[11:56] '''Andrew Hellershanks'''  : L'erreur est une erreur générique -> NullReferenceException : La référence de l'objet n'est pas définie sur une instance d'un objet.
 
[11:57] '''Vincent.Sylvester @hg.zetaworlds.com:8002''' : Je pense aussi que la dernière version devrait calculer correctement la taille du tas, il y avait un bug à ce sujet auparavant.
 
[11:57] '''Ubit Umarov''' : http://opensimulator.org/wiki/YEngine
 
[11:57] '''Ubit Umarov'''  : "Contrôle de l'utilisation du tas de mémoire et de la pile" très clair ici.
 
[11:57] '''Vincent.Sylvester @hg.zetaworlds.com:8002''' : Toujours tester avec le code de la version ou du master
 
[11:58] '''Vincent.Sylvester @hg.zetaworlds.com:8002''' : Je serais curieux de voir ce script et de comprendre où il génère tout ce tas de données.
 
[11:58] '''Andrew Hellershanks'''  : YEngine accepte les paramètres ini pour définir la taille de la pile et du tas mais ces paramètres ne sont pas dans les fichiers ini existants.
 
[11:58] '''Vincent.Sylvester @hg.zetaworlds.com:8002''' : Aucun script n'a encore atteint ces limites.
 
[11:58] '''Vincent.Sylvester @hg.zetaworlds.com:8002''' : Eh bien, en dehors de l'essai pour cela spécifiquement
 
[11:58] '''Andrew Hellershanks'''  : Je ne suis pas aussi préoccupé par le problème du tas que par l'exception lors de la tentative de compilation du code.
 
[11:59] '''Vincent.Sylvester @hg.zetaworlds.com:8002''' : Oui, il faut avoir un débogueur[https://fr.wikipedia.org/wiki/D%C3%A9bogueur] connecté, je suppose.
 
[11:59] '''Andrew Hellershanks'''  : J'ai trouvé que  YEngine a quelques paramètres pour les modes de débogage mais ceux qui sont censés sauvegarder le script original et sauvegarder le fichier IL ne semblent pas fonctionner (ou le fichier a été sauvegardé ailleurs que prévu).
 
[12:00] '''Ubit Umarov'''  : ils sont dans opensimdefaults.ini
 
[12:00] '''Vincent.Sylvester @hg.zetaworlds.com:8002''' : Pour que Visual Studio[https://fr.wikipedia.org/wiki/Microsoft_Visual_Studio] permet de voir directement où le code se bloque.
 
[12:00] '''Andrew Hellershanks'''  : Vincent, oui, c'est ce que j'avais prévu de faire. Je pourrais ajouter du code de débogage supplémentaire car le backtrace[https://fr.wikipedia.org/wiki/Trace_d%27appels]  me dit où il s'arrête.
 
[12:01] '''Vincent.Sylvester @hg.zetaworlds.com:8002''' : Si tu arrives à le faire, n'hésite pas à le publier pour que d'autres puissent le tester aussi, plus il y a de cerveaux, mieux c'est pour comprendre des choses mystérieuses comme ça.
 
[12:01] '''Ubit Umarov'''  : oui, lire le IL vous aidera beaucoup :p
 
[12:01] '''Andrew Hellershanks'''  : Je n'ai pas écrit les deux scripts en question. L'un d'eux fait presque 4600 lignes.
 
[12:02] '''Andrew Hellershanks'''  : Ubit, je sais. J'espérais juste trouver quelque chose qui pourrait aider à préciser ce qui déclenche l'exception.
 
[12:02] '''Andrew Hellershanks'''  : Un débogueur ou l'ajout de messages de débogage supplémentaires pourrait être ma meilleure option.
 
[12:02] '''Ubit Umarov'''  : X n'avait aucun contrôle sur l'utilisation de la mémoire.
 
[12:03] '''Vincent.Sylvester @hg.zetaworlds.com:8002''' : Si elles sont aussi longues, peut-être que ce que tu vois est l'échec de l'allocation du tas lui-même.
 
[12:03] '''Ubit Umarov'''  : il est donc normal que certains scripts essaient de manger toute la mémoire.
 
[12:03] '''Andrew Hellershanks'''  : Il y avait un paramètre de taille de pile de 256k dans l'ini mais c'est à peu près tout.
 
[12:03] '''Vincent.Sylvester @hg.zetaworlds.com:8002''' : Tu as presque autant de malchance que moi avec les bugs lol
 
[12:03] '''Ubit Umarov'''  : Y contrôle la pile et le tas
 
[12:04] '''Andrew Hellershanks'''  : Vincent, c'est ce que je pense. Il aurait été plus intéressant de le dire dès le départ et de ne pas se contenter de dire pas de référence à l'objet.
 
[12:04] '''Andrew Hellershanks'''  : Vincent, seulement quand ce n'est pas mon code.
 
[12:04] '''Ubit Umarov'''  : et oui, dans les mêmes cas, les gens ont besoin de l'augmenter pour exécuter les vieux scripts X.
 
[12:04] '''Selby.Evans @grid.kitely.com:8002'''  : au revoir tout le monde.
 
[12:04] '''Andrew Hellershanks'''  : Ceci fait partie d'un test de compatibilité pour voir quels changements (s'il y en a) doivent être faits au script pour qu'il fonctionne dans YEngine.
 
[12:05] '''Ubit Umarov'''  : en supposant qu'il ait échoué à cause d'un débordement de pile contrôlé par Yengine.
 
[12:05] '''Kayaker Magic'''  : Au revoir Selby !
 
[12:05] '''Ubit Umarov'''  : cya Selby.Evans
 
[12:05] '''Andrew Hellershanks'''  : Selby, ok. Merci d'être venu.
 
[12:05] '''Ubit Umarov'''  : il se peut qu'il ait crashé à cause d'un débordement de pile natif :)
 
[12:05] '''Vincent.Sylvester @hg.zetaworlds.com:8002''' : Je pense qu'avec des scripts aussi longs, il y a probablement quelque chose qui n'est pas conforme à la norme LSL et qui est rejeté par le système. J'ai vu beaucoup de vieux scripts écrits sous X fonctionner mal parce qu'ils utilisaient de mauvais ajouts de listes et d'autres choses du genre. En les corrigeant et en écrivant dans la norme LSL appropriée, on obtient des performances et moins de problèmes de consommation de mémoire.
 
[12:05] '''Ubit Umarov'''  : bon quand ubode fait ça, c'est très visible :)
 
[12:06] '''Vincent.Sylvester @hg.zetaworlds.com:8002''' : Réécrire un script aussi grand n'est pas si facile bien sûr, peut-être mieux de juste '''lint'''(?) un peu.
 
[12:07] '''Andrew Hellershanks'''  : Vincent, c'est une partie de ma question. Est-ce que c'est une erreur dans le script ou quelque chose dans le code YEngine. Je ne m'attendais pas à une exception pendant ce que je pense être juste la phase de compilation.
 
[12:08] '''Ubit Umarov'''  : cela dépend de ce que tu appelles exception.
 
[12:08] '''Ubit Umarov'''  : "exception" peut être beaucoup de choses
 
[12:08] '''Vincent.Sylvester @hg.zetaworlds.com:8002''' : Ligne 2547 probablement et peut-être list append à la ligne 574, cela nécessite de voir le script pour vraiment savoir.
 
[12:08] '''Andrew Hellershanks'''  : Ce que j'appelle une exception est ce qui est rapporté par YEngine comme ...Exception dans le message d'erreur.
 
[12:09] '''Ubit Umarov'''  : il en dit généralement plus.
 
[12:10] '''Vincent.Sylvester @hg.zetaworlds.com:8002''' : Eh bien les erreurs de référence nulle sont quelque chose qu'on voit sur des parties de code qui essaient d'obtenir des propriétés ou d'itérer par exemple. Cela indique qu'une référence est manquante, ce qui signifie que le code qui essaie d'interagir avec un objet a changé de format, par exemple. Ce n'est qu'une des façons dont cela peut se produire. Étant donné qu'il n'y a plus de tas, peut-être que les structures internes comme les tailles des listes sont dépassées lorsqu'il leur alloue de l'espace et que la référence à chaque élément disparaît.
 
[12:10] '''Andrew Hellershanks'''  : Bien sûr. Il y a un backtrace.
 
[12:11] '''Ubit Umarov'''  : c'est sur la compilation que ça n'a rien à faire avec les paramètres de mémoire du script.
 
[12:11] '''Ubit Umarov'''  : si c'est le cas...
 
[12:11] '''Kayaker Magic'''  : Andrew : Je viens de regarder les tailles de pile et de tas de YEngine, les valeurs recommandées sont 2048 et 1024, Cela a changé à un moment donné, il semble bien que les anciennes valeurs étaient plus petites.
 
[12:11] '''Ubit Umarov''' : Grrr
 
[12:11] '''Ubit Umarov'''  : il dit maintenant que c'est sur la compilation...
 
[12:12] '''Ubit Umarov'''  : il faut juste lire le message...
 
[12:12] '''Andrew Hellershanks'''  : La première erreur à laquelle j'ai été confronté était l'exception qui est apparue lorsque j'ai dit au viewer que je voulais compiler les scripts. Une fois que j'ai reçu une version mise à jour du code, je n'ai eu que l'erreur HeapException.
 
[12:12] '''Vincent.Sylvester @hg.zetaworlds.com:8002''' : ... nous sommes en train de fouiller dans l'obscurité, sans script et sans logs (journaux) , si on ne peut pas le comprendre cette semaine, il suffit de le mettre sur la Mantis [http://opensimulator.org/mantis/my_view_page.php] :)
 
[12:12] '''Ubit Umarov'''  : bien sûr, certains sont encore critiques...
 
[12:13] '''Objet''' : Script en cours d'exécution
 
[12:13] '''Andrew Hellershanks'''  : Maintenant que j'ai doublé la taille du tas, je vais essayer de compiler à nouveau les scripts sur la version originale du code au cas où l'exception "no ref to object" serait également liée au tas.
 
[12:14] '''Ubit Umarov'''  : pas de référence à l'objet est une chose plus grave.
 
[12:14] '''Ubit Umarov'''  : il suffit d'avoir l'erreur complète.
 
[12:15] '''Andrew Hellershanks'''  : J'en discuterais bien dans le canal IRC[http://opensimulator.org/wiki/IRC/fr] mais je ne peux toujours pas joindre le canal depuis la panne nationale d'Internet de vendredi.
 
[12:15] '''Ubit Umarov''' : oh?
 
[12:16] '''Vincent.Sylvester @hg.zetaworlds.com:8002''' : Il suffit d'utiliser Mantis si vous n'arrivez à rien cette semaine ou une solution de ce type, il vaut mieux que d'autres cerveaux y jettent un coup d'œil et j'ai nettoyé la mantis du mieux que je pouvais, alors n'hésitez pas à ajouter des choses lol
 
[12:16] '''Andrew Hellershanks'''  : oui. Un important fournisseur d'accès Internet et de téléphonie mobile a subi une panne vendredi à partir de 5 heures du matin. Je n'ai récupéré Internet que vers 22h30. On s'attendait à ce que certaines personnes soient privées d'Internet pendant 3 jours.
 
[12:16] '''Vincent.Sylvester @hg.zetaworlds.com:8002''' : encore BGP[https://fr.wikipedia.org/wiki/Border_Gateway_Protocol], dit-on
 
[12:16] '''Ubit Umarov'''  : dans ce cas, une mantis sans le script à partager est un problème.
 
[12:17] '''Ubit Umarov'''  : et fournir le script, spécialement un grand, peut être un problème.
 
[12:17] '''Andrew Hellershanks'''  : Vincent, bien sûr. Mes notes indiquent que même avec une taille de tas plus importante, une exception est toujours émise lorsque je demande la compilation des scripts.
 
[12:17] '''Vincent.Sylvester @hg.zetaworlds.com:8002''' : Script et logs, bien les étapes à reproduire et les logs dans la plupart des cas.
 
[12:17] '''Ubit Umarov''' : ohh
 
[12:17] '''Andrew Hellershanks'''  : Si je suis autorisé à fournir le script, je le marquerai comme privé.
 
[12:18] '''Ubit Umarov'''  : c'est peut-être juste un script manquant.
 
[12:18] '''Kayaker Magic'''  : Trouver un petit script pour reproduire une erreur est souvent difficile.
 
[12:18] '''Ubit Umarov'''  : cela peut donner une erreur de référence nulle.
 
[12:18] '''Andrew Hellershanks'''  : Pour reproduire le problème il suffit de faire un clic droit sur l'objet, plus, plus, scripts, compiler (Mono).
 
[12:18] '''Ubit Umarov'''  : oui, cela ressemble à un script manquant.
 
[12:18] '''Ubit Umarov'''  : lisez le message d'erreur.
 
[12:19] '''Andrew Hellershanks''' : at OpenSim.Region.ScriptEngine.Yengine.XMRInstance.PostEvent (OpenSim.Region.ScriptEngine.Shared.EventParams evt) [0x0001f] in XMRInstRun.cs:69
 
[12:19] '''Andrew Hellershanks''' : at (wrapper remoting-invoke-with-check) OpenSim.Region.ScriptEngine.Yengine.XMRInstance.PostEvent(OpenSim.Region.ScriptEngine.Shared.EventParams)
 
[12:19] '''Andrew Hellershanks''' : etc...
 
[12:19] '''Vincent.Sylvester @hg.zetaworlds.com:8002''' : Le problème le plus évident était la taille trop petite des paquets de la base de données pour stocker l'asset.
 
[12:19] '''Andrew Hellershanks'''  : Je vais voir si je peux apprendre quelque chose de plus à ce sujet et sur mantis.
 
[12:20] '''Ubit Umarov'''  : sur un post événement ?
 
[12:20] '''Ubit Umarov'''  : étrange.
 
[12:20] '''Andrew Hellershanks'''  : hm... c'est une idée intéressante, Vincent.
 
[12:20] '''Ubit Umarov'''  : Je ne peux pas deviner.
 
[12:20] '''Ubit Umarov'''  : et c'est ce qui le fait fonctionner.
 
[12:20] '''Andrew Hellershanks'''  : Le texte du script tel qu'il se trouve sur mon ordinateur fait 211772 octets.
 
[12:21] '''Ubit Umarov'''  : ou en cours d'exécution.
 
[12:21] '''Vincent.Sylvester @hg.zetaworlds.com:8002''' : La taille maximale des paquets était de 16 Mo sur les anciennes versions de mysql. Depuis, elle a été augmentée ; la valeur par défaut devrait être beaucoup plus élevée maintenant, comme 1G même sur certaines versions.
 
[12:22] '''Ubit Umarov'''  : les scripts avaient une limite de 64k bytes sur les sources.
 
[12:22] '''Vincent.Sylvester @hg.zetaworlds.com:8002''' : C'était un gros défaut sur les assets de HG [http://opensimulator.org/wiki/Hypergrid/fr] à l'époque
 
[12:22] '''Andrew Hellershanks'''  : Ubit, il semble que ce soit un problème après le début de l'exécution du script. Quelque chose à voir avec llMessageLinked[https://wiki.secondlife.com/wiki/LlMessageLinked/fr]. Je pense ajouter du code supplémentaire dans LSL_Api.cs pour imprimer ce que la fonction reçoit.
 
[12:23] '''Ubit Umarov'''  : mais cela semble nécessiter un débogage plus détaillé.
 
[12:23] '''Andrew Hellershanks'''  : Le moteur meurt et ne laisse aucune information utile sur la ligne du script qu'il essayait d'exécuter au moment où il est mort.
 
[12:23] '''Ubit Umarov'''  : ce n'est pas sur lsl_api.
 
[12:23] '''Andrew Hellershanks'''  : J'espérais que l'un des paramètres de débogage pourrait aider.
 
[12:23] '''Andrew Hellershanks'''  : llMessageLinked n'est pas dans LSL_Api.cs ? ?
 
[12:23] '''Ubit Umarov'''  : et c'est celui-là ?
 
[12:24] '''Andrew Hellershanks'''  : Cette fonction est mentionnée plus bas dans le backtrace.
 
[12:24] '''Ubit Umarov'''  : Je ne peux pas deviner ce que vous n'avez pas dit :p
 
[12:24] '''Vincent.Sylvester @hg.zetaworlds.com:8002''' : C'est comme une chasse au renard avec un renard invisible.
 
[12:25] '''Ubit Umarov'''  : nahh juste un très mauvais rapport de problème
 
[12:25] '''Ubit Umarov'''  : :p
 
[12:26] '''Vincent.Sylvester @hg.zetaworlds.com:8002''' : Si tu n'arrives pas à déboguer, mets-le sur mantis, s'ils ne veulent pas le partager, mets-le sur privé pour qu'au moins Ubit puisse y jeter un œil.
 
[12:26] '''Andrew Hellershanks'''  : Oui, le script doit être considéré comme privé.
 
[12:27] '''Vincent.Sylvester @hg.zetaworlds.com:8002''' : De sombres secrets lol
 
[12:27] '''Andrew Hellershanks'''  : Un code propriétaire qui fait partie d'un système plus large.
 
[12:28] '''Vincent.Sylvester @hg.zetaworlds.com:8002''' : J'espère qu'il ne s'agit pas d'une animation à plusieurs poses, je n'en ai pas encore vu une seule écrite correctement, elles sont toutes massivement trop compliquées et mal écrites au point de consommer une tonne de ressources.
 
[12:28] '''Vincent.Sylvester @hg.zetaworlds.com:8002''' : Certains ne fonctionnent même plus sous Y.
 
[12:29] '''Vincent.Sylvester @hg.zetaworlds.com:8002''' : Ou utiliser les fonctions ossl qui doivent être mises à true.
 
[12:29] '''Andrew Hellershanks'''  : Vincent, c'est intéressant de voir que certaines ne fonctionnent pas en Y (en supposant que ce n'est pas seulement les perms).
 
[12:29] '''Vincent.Sylvester @hg.zetaworlds.com:8002''' : Ils se plantent sur les listes qu'ils génèrent ou sur les typages.
 
[12:29] '''Andrew Hellershanks'''  : Ce n'est probablement pas très surprenant.
 
[12:30] '''Andrew Hellershanks'''  : oh, c'est vrai. Probablement ceux qui utilisent le " truc pour sauver la mémoire ".
 
[12:30] '''Vincent.Sylvester @hg.zetaworlds.com:8002''' : Aussi les premiers suspects pour le truc "les scripts ont cessé de fonctionner" que j'ai mentionné plus tôt.
 
[12:30] '''Vincent.Sylvester @hg.zetaworlds.com:8002''' : Oh oui, lorsque cela se produit, les choses comme llSetText[https://wiki.secondlife.com/wiki/LlSetText] ne sont pas non plus mises à jour, ce qui permet de savoir de quelle file il s'agit.
 
[12:31] '''Vincent.Sylvester @hg.zetaworlds.com:8002''' : Mais oui, si vous n'arrivez à rien, créez simplement un ticket mantis privé pour cela.
 
[12:32] '''Ubit Umarov'''  : yeha, je suppose que cela va demander un débogage plus profond.
 
[12:33] '''Misterblue Waves'''  : je dois y aller... à bientôt !
 
[12:33] '''Ubit Umarov''' : cya
 
[12:34] '''Andrew Hellershanks'''  : Tant que je peux encore accéder à la mantis. Je ne sais pas pourquoi je ne peux toujours pas accéder aux canaux IRC.
 
[12:34] '''Ubit Umarov'''  : mais cela signifie qu'il y a plus de scripts.
 
[12:34] '''Andrew Hellershanks'''  : ok, Misterblue.
 
[12:34] '''Ubit Umarov'''  : sur l'objet lié.
 
[12:35] '''Ubit Umarov'''  : donc je suppose que l'objet entier sera nécessaire pour déboguer.
 
= Conclusion =
[12:34] '''Andrew Hellershanks'''  : Nous sommes maintenant à l'heure et demie. Sauf s'il y a des questions de dernière minute, je vais conclure la réunion.
 
[12:37] '''Andrew Hellershanks'''  : ok, je vais dire que cette réunion est terminée :)  Merci à tous d'être venus. On se revoit la semaine prochaine.

Dernière version du 27 juillet 2022 à 19:03

Source : http://opensimulator.org/wiki/Chat_log_from_the_meeting_on_2022-07-12

Introduction

[11:04] Ubit Umarov  : ahh le chat d'andrew s'est souvenu de la réunion.

[11:04] Andrew Hellershanks  : Je suis au téléphone,

[11:04] Misterblue Waves  : nous sommes montés jusqu'à 48c l'été dernier -- les plantes n'ont pas bien résisté.

[11:05] Ubit Umarov  : Ohh ok on va taper doucement

[11:05] Ubit Umarov  : ouais mais 48 ici c'est rare... comme 45 ans rare.

Fsassets : instances multiples

[11:06] Ubit Umarov  : à propos d'opensim, encore une fois pas grand chose.

[11:06] Vincent.Sylvester @hg.zetaworlds.com:8002 : Deux changements la semaine dernière, un autre nettoyage de libomv[1] et un correctif pour fsassets qui n'utilise pas correctement ses dossiers. Je suis repassé à mono[2] 122[3] vendredi et j'attends maintenant ce que cela fait aux régions. Jusqu'à présent, je n'ai pas entendu parler de nouveaux crashs, mais je vais devoir le laisser un peu pour être sûr. Firestorm[4] (FS) a sorti une nouvelle beta avec le support du statut de la grille rss[5] maintenant supporté dans OpenSim.

[11:06] Misterblue Waves  : même chose pour nous -- il est rare de dépasser les 100F(https://fr.wikipedia.org/wiki/Degr%C3%A9_Fahrenheit) (38°C).

[11:06] Ubit Umarov  : j'ai fait un petit commit[6] lié à un flag fsassets.

[11:07] Ubit Umarov  : ou une option, en fait pas si bonne...

[11:07] Ubit Umarov  : pour exécuter plusieurs instances de fsassets, cela ne fonctionnera pas.

[11:07] Ubit Umarov  : à moins d'avoir un disque réseau comme stockage [7](NAS)

[11:07] Andrew Hellershanks : .0

[11:08] Ubit Umarov  : fsasset ne fait qu'écrire des choses sur un disque, il n'a aucune idée de ce que sont les instances multiples.

[11:08] Ubit Umarov  : les métadonnées[8] dépendent de mysql[9] qui fait le truc du multi serveur, ça ne semble pas très bon non plus.

[11:09] Ubit Umarov  : donc, pas si utile que ça cette option...

[11:09] Ubit Umarov  : hmm quel était l'autre ? libomv ?

[11:10] Ubit Umarov  : hmm je suppose que c'est aussi une chose mineure.

[11:10] Vincent.Sylvester @hg.zetaworlds.com:8002 : Est-ce que le truc de fsassets est principalement un verrouillage de fichier ou quel est le problème ?

[11:11] Ubit Umarov  : ah oui... j'utilisais une exception c# [10] générique pour signaler une mauvaise chaîne de caractères lors de l'analyse.

[11:12] Kayaker Magic  : Un problème avec plusieurs fsassets est qu'il y a peu de chance que deux d'entre eux génèrent le même UUID[11] en même temps.

[11:12] Ubit Umarov  : changé en FormatException pour correspondre à ce que .net[12] guid [13] fait.

[11:12] Ubit Umarov  : fsassets ne génère pas d'uuids.

[11:12] Kayaker Magic  : OK, alors plusieurs Robusts[14].

[11:13] Ubit Umarov  : le problème avec des robusts multiples est que vous avez besoin d'un stockage partagé.

[11:13] Ubit Umarov  : fsasset n'est pas prévu pour cela.

[11:14] Ubit Umarov  : chaque instance va juste lire et écrire depuis son propre disque.

[11:14] Ubit Umarov  : quelque chose qui ne fonctionnera pas du tout, à moins que ce soit un disque réseau partagé spécial.

[11:14] Ubit Umarov  : ou on peut faire tourner tout cela sur la même machine, ce qui n'est pas très utile non plus.

[11:15] Ubit Umarov  : sur ce point fsassets est pire que les assets[15] normaux, qui au moins dépendent uniquement de mysql/maria [16].

[11:16] Ubit Umarov  : les multi-instances fsassets qui ont fonctionné, ont été installée séparant quelques bits de l'UUID de l'asset.

[11:16] Ubit Umarov  : a t-on toujours du code pour cela, je n'en suis pas sûr.

[11:17] Ubit Umarov  : bien sûr, cela ne fonctionne pas très bien avec le type guid "aléatoire" que nous utilisons.

[11:17] Ubit Umarov  : pas si aléatoire que cela

[11:18] Ubit Umarov  : c'est pourquoi osgrid[17] fonctionne avec ses propres assets propriétaires...

[11:18] Ubit Umarov  : j'utilisais une variante de fsassets, qui faisait aussi de la fumée si on utilisait plus d'une instance.

[11:18] Ubit Umarov  : maintenant j'utilise quelque chose d'autre.

[11:19] Ubit Umarov  : bien sûr, il n'y a pas de problème si vous avez une bonne machine NAS et un réseau 100Gbit ;)

[11:19] Vincent.Sylvester @hg.zetaworlds.com:8002 : Etant donné la simplicité de ce que cela doit faire au final, il est plus facile d'écrire avec quelque chose d'autre qui supporte le verrouillage des fichiers de manière appropriée, je suppose. Idéalement directement en C[18]pour obtenir la plus grande vitesse.

[11:20] Ubit Umarov  : le verrouillage des fichiers semble échouer sous linux [19].

[11:21] Ubit Umarov  : ce code fsassets exécute aussi plusieurs instances sur un seul robust...

[11:21] Vincent.Sylvester @hg.zetaworlds.com:8002 : Ce n'est pas intégré, donc le langage ou le code doit le gérer lui-même.

[11:21] Ubit Umarov  : une comme instance principale des assets, les autres comme esclaves qui s'y connectent.

[11:21] Misterblue Waves  : les GUIDs ne sont pas assez aléatoires ou le contenu n'est pas unique ?

[11:22] Ubit Umarov  : il y avait toujours un problème de verrouillage, car plusieurs threads de maintenance pouvaient être déclenchés dans ce cas...

[11:22] Ubit Umarov  : ça devrait être ok maintenant...

[11:23] Ubit Umarov  : mes commentaires ne concernaient que les personnes qui essayaient de faire tourner plusieurs instances de service d'assets sur différentes machines...

[11:23] Ubit Umarov  : comme je l'ai dit, ça ne marche pas, sauf s'ils utilisent un disque partagé sur le réseau.

[11:24] Vincent.Sylvester @hg.zetaworlds.com:8002 : Ou quelque chose qui émule le comportement de ce type de disque, je suppose.

[11:24] Ubit Umarov  : Oui

[11:24] Ubit Umarov  : alors bien sûr il faut comparer la latence ajoutée à la latence d'un seul...

[11:25] Ubit Umarov  : sur ce point, les caches de région et de viewers sont fondamentaux.

[11:26] Ubit Umarov  : dans les cas normaux, seuls les caches des régions devraient être utilisés.

[11:26] Ubit Umarov  : dans le cas d'utilisateurs qui passent le plus de temps sur quelques régions, aussi les caches de viewer.

[11:27] Vincent.Sylvester @hg.zetaworlds.com:8002 : D'après ce que j'enregistre sur disk i/o[20], je vois rarement plus de quelques mbits lorsque les assets sont déplacés, ce n'est donc pas une charge importante pour atteindre des centaines de gigaoctets.

[11:27] Vincent.Sylvester @hg.zetaworlds.com:8002 : Le plus gros problème est de sauvegarder des millions de fichiers dans des milliers de répertoires.

[11:28] Ubit Umarov  : beaucoup de gens ont même oublié que fsassets utilise mysql avec des fichiers disques.

[11:28] Ubit Umarov  : et ont perdu les fichiers du disque :(

[11:28] Kayaker Magic  : oops ! Je déteste quand ça arrive !

[11:28] Misterblue Waves  : quelque chose comme S3[21] serait mieux -- pas AWS[22] mais l'une des interfaces compatibles des hash buckets modernes.

[11:28] Ubit Umarov  : c'est malheureusement arrivé plusieurs fois.

Les bases de données

[11:29] Vincent.Sylvester @hg.zetaworlds.com:8002 : Il devrait probablement utiliser encore plus de sql pour cela, pour des choses comme les notecards qui enregistrent leur description dans des assets ce qui implique que, même si elles sont vides, le hash[25] est toujours différent, ce qui crée des tonnes d'assets de notecards vides.

[11:30] Vincent.Sylvester @hg.zetaworlds.com:8002 : AWS, c'est de la camelote hors de prix, vous paierez plus cher pour l'utiliser que pour un simple serveur matériel décent et quand ils perdent vos données, vous êtes foutu.

[11:30] Ubit Umarov  : plusieurs grandes grilles fonctionnent bien.

[11:30] Ubit Umarov  : quelques mb avec leurs propres solutions

[11:31] Ubit Umarov  : Je n'ai jamais aimé fsassets.

[11:31] Misterblue Waves  : d'accord pour AWS, mais beaucoup d'autres fournisseurs proposent un stockage compatible S3 (DigitalOcean[26](en), ...)

[11:31] Ubit Umarov  : bien sûr mysql est peut-être un mauvais choix.

[11:31] Vincent.Sylvester @hg.zetaworlds.com:8002 : Je suis en train de jouer avec l'idée d'explorer toutes les notecards à la recherche de lignes vides et de les détruire ou de mettre leur hash à une seule place.

[11:31] Ubit Umarov  : inworldz a utilisé un autre moteur de base de données, si je me souviens bien.

[11:32] Ubit Umarov  : un truc plus direct de type clé et valeur.

[11:32] Ubit Umarov  : je pense qu'il n'y a même pas de sql.

[11:32] Vincent.Sylvester @hg.zetaworlds.com:8002 : Pour certaines choses, quelques structures de données dans OpenSim, des choses comme mongodb fonctionneraient, potentiellement mieux que sql, mais alors on a un autre système de base de données à maintenir et à gérer aussi, donc un compromis...

[11:33] Vincent.Sylvester @hg.zetaworlds.com:8002 : Pour les données des avatars et des groupes, cela pourrait être plus rapide, mais cela implique un tout nouveau connecteur de base de données, etc.

[11:33] Vincent.Sylvester @hg.zetaworlds.com:8002 : c'est déjà une douleur de maintenir ceux que nous avons

[11:33] Ubit Umarov  : Nos bases de données sont un désastre.

[11:33] Vincent.Sylvester @hg.zetaworlds.com:8002 : Certaines, pas toutes

[11:33] Ubit Umarov  : un bon exemple de comment rendre les choses aussi lentes que possible.

[11:33] Ubit Umarov  : region db[27] ... duhhh quel gaspillage

[11:34] Vincent.Sylvester @hg.zetaworlds.com:8002 : L'inventaire pourrait également bénéficier d'une base de données de type document plutôt que de grandes tables.

[11:34] Vincent.Sylvester @hg.zetaworlds.com:8002 : Tout ce qui est lié à un seul utilisateur ou uuid, je suppose.

[11:35] Vincent.Sylvester @hg.zetaworlds.com:8002 : Inutile pour les assets, il faut une vraie table avec des clés et des index à ce niveau.

[11:35] Vincent.Sylvester @hg.zetaworlds.com:8002 : En y réfléchissant, je voulais vérifier si le jeu de caractères et la collation avaient un impact sur les performances des groupes, comme c'est le cas pour les données de griduser[28].

[11:35] Vincent.Sylvester @hg.zetaworlds.com:8002 : Il semble que le regroupement de ces éléments soit un échec dans mariadb.

[11:36] Vincent.Sylvester @hg.zetaworlds.com:8002 : Cela nécessite des éléments uniformes pour accélérer inner join [29].

[11:36] Ubit Umarov  : il semble que mariadb est défaillante pour tout ce qui est volumineux.

[11:36] Ubit Umarov  : même mysql

[11:36] Ubit Umarov  : seuls quelques forks de mysql tiennent, m'a-t-on dit.

[11:37] Vincent.Sylvester @hg.zetaworlds.com:8002 : Le développement s'est accéléré ces derniers temps, alors peut-être que cela va changer positivement à l'avenir.

[11:37] Misterblue Waves  : J'ai utilisé MariaDB avec succès pour de petits déploiements (c'est ce que j'utilise pour mes régions installée avec Docker [30]).

Script tueur de région

[11:36] Kayaker Magic  : J'ai quelques trucs mis en place pour OpenSim Fest, et une des régions a cessé de fonctionner. Les scripts ont gelé, je n'avais pas de droit de compiler mes propres scripts ou à recharger plus d'objets. Shelenn m'a dit que c'était dû à un bug d'OpenSim que Ubit connaissait déjà. Quel bug était-ce ?

[11:37] Ubit Umarov  : aucune idée

[11:37] Ubit Umarov  : ils utilisent une chose appelée opensim-ngc (https://github.com/OpenSim-NGC][31].

[11:37] Vincent.Sylvester @hg.zetaworlds.com:8002 : Si on surcharge une région en provoquant trop de mises à jour de scènes, la file d'attente pour cela se remplit et le traitement s'arrête complètement.

[11:37] Ubit Umarov  : qui, bien sûr, prétend être meilleur que le projet de base (le noyau).

[11:38] Vincent.Sylvester @hg.zetaworlds.com:8002 : Il n'y a pas grand chose à faire à ce niveau.

[11:38] Ubit Umarov  : donc tu dois leur demander :)

[11:38] Vincent.Sylvester @hg.zetaworlds.com:8002 : la file d'attente de mise à jour des scènes a une taille fixe, une fois pleine, elle est pleine et meurt.

[11:38] Ubit Umarov  : Je ne me souviens pas d'un tel problème...

[11:39] Vincent.Sylvester @hg.zetaworlds.com:8002 : J'ai vu cela plusieurs fois, on m'a toujours dit de supprimer certains scripts lourds, des timers [32] et autres, et il n'y a plus de problèmes.

[11:39] Ubit Umarov  : quelles mises à jour de la scène ??

[11:39] Vincent.Sylvester @hg.zetaworlds.com:8002 : Celles qui sont générées par les scripts, les avatars, etc. J'ai oublié le nom exact, mais ce ne sont pas les scripts qui meurent, ce sont les mises à jour des scènes.

[11:39] Ubit Umarov  : tu imagines encore des choses vincent :p

[11:39] Ubit Umarov  : la file d'attente des événements[33] ?

[11:40] Ubit Umarov  : ces auto limites... n'arrêtent pas les choses.

[11:40] Ubit Umarov  : bien sûr, un script peut toujours geler une région de plusieurs manières...

[11:40] Vincent.Sylvester @hg.zetaworlds.com:8002 : Tu peux tester si c'est ça en tapant des commandes dans la console, si ça échoue avec une erreur, peu importe ce que tu tapes, tu sais que c'est bloqué.

[11:41] Vincent.Sylvester @hg.zetaworlds.com:8002 : La réduction de la charge des scripts résout généralement ce problème.

[11:41] Kayaker Magic  : Après qu'ils l'aient "corrigé", j'ai pu ajouter plus d'objets scriptés.

[11:41] Ubit Umarov  : Je ne me souviens pas de ce problème sur le noyau... possible... mais je ne m'en souviens pas...

[11:42] Ubit Umarov  : Je veux dire un problème spécifique.

[11:42] Vincent.Sylvester @hg.zetaworlds.com:8002 : Tu dois charger les régions assez lourdement pour que cela se produise. La plupart restent bien en dessous de cela ou écrivent des scripts qui ne provoquent pas autant de mises à jour.

[11:43] Ubit Umarov  : Je me souviens de régions complètement à plat.

[11:43] Vincent.Sylvester @hg.zetaworlds.com:8002 : Cela n'arrive pas assez souvent pour justifier un examen approfondi. Il est plus facile d'écrire de meilleurs scripts.

[11:43] Ubit Markov : simplement à cause d'un simple script de LED.

[11:43] Ubit Umarov  : nous ne pouvions plus nous tp dans la région ou les régions voisines :)

[11:44] Ubit Umarov  : un script similaire fera toujours la même chose.

[11:44] Vincent.Sylvester @hg.zetaworlds.com:8002 : Je n'ai vu cela que sur une région avec environ 90k prims et plus de 8000 scripts.

[11:44] Ubit Umarov  : changer l'éclat ou la couleur etc. d'une prim est une mise à jour complète.

[11:44] Ubit Umarov  : cette région avait peut-être 1000 LEDs :)

[11:45] Ubit Umarov  : nous avons tous vu ce problème à Noël... avec de mauvaises lumières de Noël.

[11:45] Vincent.Sylvester @hg.zetaworlds.com:8002 : On pourrait probablement trouver la file d'attente et déterminer quelle est la taille maximale et ajouter un débogage pour alerter lorsqu'elle est proche du plein.

[11:45] Vincent.Sylvester @hg.zetaworlds.com:8002 : Je n'ai jamais regardé où c'était.

[11:46] Ubit Umarov  : tu es encore là avec une file d'attente... quelle file d'attente ??

[11:46] Ubit Umarov  : il y en a plusieurs.

[11:46] Kayaker Magic  : Après avoir vu quelques mauvais scripts de lumières de Noël, j'ai écrit des scripts ZERO LAG qui utilisent des animations de textures pour clignoter [34].

[11:46] Ubit Umarov  : et aucun problème.

[11:47] Ubit Umarov  : oui le clignotement doit être fait avec une animation de texture intelligente.

[11:48] Vincent.Sylvester @hg.zetaworlds.com:8002 : Quand un script déplace une prim, cela est ajouté à une file d'attente comme une mise à jour de la scène, généralement traitée presque immédiatement, sauf si on a beaucoup de ces mises à jour.

[11:48] Ubit Umarov  : il s'agit d'un vieux problème, également chez SL.

[11:48] Vincent.Sylvester @hg.zetaworlds.com:8002 : Je ne suis pas sûr de l'endroit du code où cela se trouve, je ne l'ai jamais beaucoup étudié.

[11:48] Ubit Umarov  : lludp[35] met à jour la queue par utilisateur ??

[11:49] Ubit Umarov  : c'est lourd, c'est un problème majeur actuellement.

[11:49] Vincent.Sylvester @hg.zetaworlds.com:8002 : Possible, tout ce que je sais c'est que c'est quelque chose qui se remplit et qui surcharge en arrêtant le traitement des mises à jour parce qu'on peut toujours se promener et chatter, mais les scripts apparaissent comme s'ils étaient arrêtés.

[11:49] Ubit Umarov  : ils ne se remplissent pas.

[11:49] Ubit Umarov  : ils remplissent la RAM de ta machine :p

[11:50] Vincent.Sylvester @hg.zetaworlds.com:8002 : Comme cela ne se produit pas immédiatement et seulement lorsqu'il y a plus de scripts et de personnes sur la région, cela me faire dire que c'est un traitement lié à la mises à jour de la scène.

[11:50] Vincent.Sylvester @hg.zetaworlds.com:8002 : En général, il suffit d'écrire de meilleurs scripts et de réduire la charge pour résoudre ce problème.

[11:50] Ubit Umarov  : les scripts doivent être bons.

[11:51] Vincent.Sylvester @hg.zetaworlds.com:8002 : On peut avoir une région avec des centaines de milliers de prims et un seul script qui la tue.

[11:51] Ubit Umarov  : un seul mauvais script peut arrêter une région, comme je l'ai dit.

[11:51] Ubit Umarov  : ... toujours...

[11:51] Ubit Umarov  : spécialement en utilisant des OSSL [36](en) qui n'auraient jamais dû être ajoutées.

[11:51] Ubit Umarov  : détails...

[11:51] Kayaker Magic  : Un mauvais programmeur peut écrire FORTRAN dans n'importe quel langage ;.

[11:52] Vincent.Sylvester @hg.zetaworlds.com:8002 : Ecrire des trucs pour les changements de lumière et les animations peut être incroyablement lourd.

[11:52] Andrew Hellershanks  : Bonjour à tous. J'ai enfin terminé l'appel téléphonique :P La dernière partie de l'appel consistait à donner à la personne des indications sur l'endroit où elle se rendait en voiture, car il s'est avéré qu'elle se dirigeait vers le nord alors qu'elle aurait dû aller vers le sud.

[11:52] Vincent.Sylvester @hg.zetaworlds.com:8002 : Je scripte toujours des boules de danse et d'autres trucs d'éclairage. Je vérifie ce que fait le cpu, parfois une ligne mal écrite me donne 100% de cpu heh.

[11:53] Andrew Hellershanks  : Vincent, il ne faut pas grand-chose pour faire ça.

[11:53] Vincent.Sylvester @hg.zetaworlds.com:8002 : Dans le même esprit, si on arrive à comprendre ce qui se passe en interne, on peut changer une couleur 60 fois par seconde sans trop de charge.

Script : erreur out of heap

[11:54] Andrew Hellershanks  : J'ai aidé des gens à faire des tests de compatibilité entre les moteurs X et Y la semaine dernière. Leurs scripts déclenchent une exception dans YEngine pendant la compilation. Je ne suis pas sûr de la cause de ce problème. Au moment de l'exécution, j'obtenais une exception out of heap.

[11:55] Vincent.Sylvester @hg.zetaworlds.com:8002 : lol ouch

[11:55] Vincent.Sylvester @hg.zetaworlds.com:8002 : Cela demande de sérieux efforts.

[11:55] Andrew Hellershanks  : En regardant le code du système d'exploitation, j'ai trouvé des paramètres ini pour changer la taille du tas et cela a résolu le problème du tas.

[11:55] Andrew Hellershanks  : Toujours aucune idée sur l'erreur de compilation.

[11:55] Ubit Umarov  : ohh vraiment ?

[11:55] Ubit Umarov  : la prochaine fois RTFM [39]?

[11:55] Ubit Umarov  : peut-être... :p

[11:56] Andrew Hellershanks  : Ubit, oui. Il y a des paramètres ini pour définir la taille de la pile et du tas dans YEngine mais ils ne sont pas listés dans le fichier ini.

[11:56] Vincent.Sylvester @hg.zetaworlds.com:8002 : Les erreurs du compilateur sont généralement très explicites, sauf si on a cassé quelque chose en interne.

[11:56] Vincent.Sylvester @hg.zetaworlds.com:8002 : Idéalement, on ne devrait pas avoir besoin d'ajuster le heap du tout.

[11:56] Kayaker Magic  : Si les gens utilisent les anciens paramètres de OpenSim.ini pour les tailles de heap de YEngine, cela peut causer le problème que tu décris.

[11:56] Andrew Hellershanks  : L'erreur est une erreur générique -> NullReferenceException : La référence de l'objet n'est pas définie sur une instance d'un objet.

[11:57] Vincent.Sylvester @hg.zetaworlds.com:8002 : Je pense aussi que la dernière version devrait calculer correctement la taille du tas, il y avait un bug à ce sujet auparavant.

[11:57] Ubit Umarov : http://opensimulator.org/wiki/YEngine

[11:57] Ubit Umarov  : "Contrôle de l'utilisation du tas de mémoire et de la pile" très clair ici.

[11:57] Vincent.Sylvester @hg.zetaworlds.com:8002 : Toujours tester avec le code de la version ou du master

[11:58] Vincent.Sylvester @hg.zetaworlds.com:8002 : Je serais curieux de voir ce script et de comprendre où il génère tout ce tas de données.

[11:58] Andrew Hellershanks  : YEngine accepte les paramètres ini pour définir la taille de la pile et du tas mais ces paramètres ne sont pas dans les fichiers ini existants.

[11:58] Vincent.Sylvester @hg.zetaworlds.com:8002 : Aucun script n'a encore atteint ces limites.

[11:58] Vincent.Sylvester @hg.zetaworlds.com:8002 : Eh bien, en dehors de l'essai pour cela spécifiquement

[11:58] Andrew Hellershanks  : Je ne suis pas aussi préoccupé par le problème du tas que par l'exception lors de la tentative de compilation du code.

[11:59] Vincent.Sylvester @hg.zetaworlds.com:8002 : Oui, il faut avoir un débogueur[40] connecté, je suppose.

[11:59] Andrew Hellershanks  : J'ai trouvé que YEngine a quelques paramètres pour les modes de débogage mais ceux qui sont censés sauvegarder le script original et sauvegarder le fichier IL ne semblent pas fonctionner (ou le fichier a été sauvegardé ailleurs que prévu).

[12:00] Ubit Umarov  : ils sont dans opensimdefaults.ini

[12:00] Vincent.Sylvester @hg.zetaworlds.com:8002 : Pour que Visual Studio[41] permet de voir directement où le code se bloque.

[12:00] Andrew Hellershanks  : Vincent, oui, c'est ce que j'avais prévu de faire. Je pourrais ajouter du code de débogage supplémentaire car le backtrace[42] me dit où il s'arrête.

[12:01] Vincent.Sylvester @hg.zetaworlds.com:8002 : Si tu arrives à le faire, n'hésite pas à le publier pour que d'autres puissent le tester aussi, plus il y a de cerveaux, mieux c'est pour comprendre des choses mystérieuses comme ça.

[12:01] Ubit Umarov  : oui, lire le IL vous aidera beaucoup :p

[12:01] Andrew Hellershanks  : Je n'ai pas écrit les deux scripts en question. L'un d'eux fait presque 4600 lignes.

[12:02] Andrew Hellershanks  : Ubit, je sais. J'espérais juste trouver quelque chose qui pourrait aider à préciser ce qui déclenche l'exception.

[12:02] Andrew Hellershanks  : Un débogueur ou l'ajout de messages de débogage supplémentaires pourrait être ma meilleure option.

[12:02] Ubit Umarov  : X n'avait aucun contrôle sur l'utilisation de la mémoire.

[12:03] Vincent.Sylvester @hg.zetaworlds.com:8002 : Si elles sont aussi longues, peut-être que ce que tu vois est l'échec de l'allocation du tas lui-même.

[12:03] Ubit Umarov  : il est donc normal que certains scripts essaient de manger toute la mémoire.

[12:03] Andrew Hellershanks  : Il y avait un paramètre de taille de pile de 256k dans l'ini mais c'est à peu près tout.

[12:03] Vincent.Sylvester @hg.zetaworlds.com:8002 : Tu as presque autant de malchance que moi avec les bugs lol

[12:03] Ubit Umarov  : Y contrôle la pile et le tas

[12:04] Andrew Hellershanks  : Vincent, c'est ce que je pense. Il aurait été plus intéressant de le dire dès le départ et de ne pas se contenter de dire pas de référence à l'objet.

[12:04] Andrew Hellershanks  : Vincent, seulement quand ce n'est pas mon code.

[12:04] Ubit Umarov  : et oui, dans les mêmes cas, les gens ont besoin de l'augmenter pour exécuter les vieux scripts X.

[12:04] Selby.Evans @grid.kitely.com:8002  : au revoir tout le monde.

[12:04] Andrew Hellershanks  : Ceci fait partie d'un test de compatibilité pour voir quels changements (s'il y en a) doivent être faits au script pour qu'il fonctionne dans YEngine.

[12:05] Ubit Umarov  : en supposant qu'il ait échoué à cause d'un débordement de pile contrôlé par Yengine.

[12:05] Kayaker Magic  : Au revoir Selby !

[12:05] Ubit Umarov  : cya Selby.Evans

[12:05] Andrew Hellershanks  : Selby, ok. Merci d'être venu.

[12:05] Ubit Umarov  : il se peut qu'il ait crashé à cause d'un débordement de pile natif :)

[12:05] Vincent.Sylvester @hg.zetaworlds.com:8002 : Je pense qu'avec des scripts aussi longs, il y a probablement quelque chose qui n'est pas conforme à la norme LSL et qui est rejeté par le système. J'ai vu beaucoup de vieux scripts écrits sous X fonctionner mal parce qu'ils utilisaient de mauvais ajouts de listes et d'autres choses du genre. En les corrigeant et en écrivant dans la norme LSL appropriée, on obtient des performances et moins de problèmes de consommation de mémoire.

[12:05] Ubit Umarov  : bon quand ubode fait ça, c'est très visible :)

[12:06] Vincent.Sylvester @hg.zetaworlds.com:8002 : Réécrire un script aussi grand n'est pas si facile bien sûr, peut-être mieux de juste lint(?) un peu.

[12:07] Andrew Hellershanks  : Vincent, c'est une partie de ma question. Est-ce que c'est une erreur dans le script ou quelque chose dans le code YEngine. Je ne m'attendais pas à une exception pendant ce que je pense être juste la phase de compilation.

[12:08] Ubit Umarov  : cela dépend de ce que tu appelles exception.

[12:08] Ubit Umarov  : "exception" peut être beaucoup de choses

[12:08] Vincent.Sylvester @hg.zetaworlds.com:8002 : Ligne 2547 probablement et peut-être list append à la ligne 574, cela nécessite de voir le script pour vraiment savoir.

[12:08] Andrew Hellershanks  : Ce que j'appelle une exception est ce qui est rapporté par YEngine comme ...Exception dans le message d'erreur.

[12:09] Ubit Umarov  : il en dit généralement plus.

[12:10] Vincent.Sylvester @hg.zetaworlds.com:8002 : Eh bien les erreurs de référence nulle sont quelque chose qu'on voit sur des parties de code qui essaient d'obtenir des propriétés ou d'itérer par exemple. Cela indique qu'une référence est manquante, ce qui signifie que le code qui essaie d'interagir avec un objet a changé de format, par exemple. Ce n'est qu'une des façons dont cela peut se produire. Étant donné qu'il n'y a plus de tas, peut-être que les structures internes comme les tailles des listes sont dépassées lorsqu'il leur alloue de l'espace et que la référence à chaque élément disparaît.

[12:10] Andrew Hellershanks  : Bien sûr. Il y a un backtrace.

[12:11] Ubit Umarov  : c'est sur la compilation que ça n'a rien à faire avec les paramètres de mémoire du script.

[12:11] Ubit Umarov  : si c'est le cas...

[12:11] Kayaker Magic  : Andrew : Je viens de regarder les tailles de pile et de tas de YEngine, les valeurs recommandées sont 2048 et 1024, Cela a changé à un moment donné, il semble bien que les anciennes valeurs étaient plus petites.

[12:11] Ubit Umarov : Grrr

[12:11] Ubit Umarov  : il dit maintenant que c'est sur la compilation...

[12:12] Ubit Umarov  : il faut juste lire le message...

[12:12] Andrew Hellershanks  : La première erreur à laquelle j'ai été confronté était l'exception qui est apparue lorsque j'ai dit au viewer que je voulais compiler les scripts. Une fois que j'ai reçu une version mise à jour du code, je n'ai eu que l'erreur HeapException.

[12:12] Vincent.Sylvester @hg.zetaworlds.com:8002 : ... nous sommes en train de fouiller dans l'obscurité, sans script et sans logs (journaux) , si on ne peut pas le comprendre cette semaine, il suffit de le mettre sur la Mantis [43] :)

[12:12] Ubit Umarov  : bien sûr, certains sont encore critiques...

[12:13] Objet : Script en cours d'exécution

[12:13] Andrew Hellershanks  : Maintenant que j'ai doublé la taille du tas, je vais essayer de compiler à nouveau les scripts sur la version originale du code au cas où l'exception "no ref to object" serait également liée au tas.

[12:14] Ubit Umarov  : pas de référence à l'objet est une chose plus grave.

[12:14] Ubit Umarov  : il suffit d'avoir l'erreur complète.

[12:15] Andrew Hellershanks  : J'en discuterais bien dans le canal IRC[44] mais je ne peux toujours pas joindre le canal depuis la panne nationale d'Internet de vendredi.

[12:15] Ubit Umarov : oh?

[12:16] Vincent.Sylvester @hg.zetaworlds.com:8002 : Il suffit d'utiliser Mantis si vous n'arrivez à rien cette semaine ou une solution de ce type, il vaut mieux que d'autres cerveaux y jettent un coup d'œil et j'ai nettoyé la mantis du mieux que je pouvais, alors n'hésitez pas à ajouter des choses lol

[12:16] Andrew Hellershanks  : oui. Un important fournisseur d'accès Internet et de téléphonie mobile a subi une panne vendredi à partir de 5 heures du matin. Je n'ai récupéré Internet que vers 22h30. On s'attendait à ce que certaines personnes soient privées d'Internet pendant 3 jours.

[12:16] Vincent.Sylvester @hg.zetaworlds.com:8002 : encore BGP[45], dit-on

[12:16] Ubit Umarov  : dans ce cas, une mantis sans le script à partager est un problème.

[12:17] Ubit Umarov  : et fournir le script, spécialement un grand, peut être un problème.

[12:17] Andrew Hellershanks  : Vincent, bien sûr. Mes notes indiquent que même avec une taille de tas plus importante, une exception est toujours émise lorsque je demande la compilation des scripts.

[12:17] Vincent.Sylvester @hg.zetaworlds.com:8002 : Script et logs, bien les étapes à reproduire et les logs dans la plupart des cas.

[12:17] Ubit Umarov : ohh

[12:17] Andrew Hellershanks  : Si je suis autorisé à fournir le script, je le marquerai comme privé.

[12:18] Ubit Umarov  : c'est peut-être juste un script manquant.

[12:18] Kayaker Magic  : Trouver un petit script pour reproduire une erreur est souvent difficile.

[12:18] Ubit Umarov  : cela peut donner une erreur de référence nulle.

[12:18] Andrew Hellershanks  : Pour reproduire le problème il suffit de faire un clic droit sur l'objet, plus, plus, scripts, compiler (Mono).

[12:18] Ubit Umarov  : oui, cela ressemble à un script manquant.

[12:18] Ubit Umarov  : lisez le message d'erreur.

[12:19] Andrew Hellershanks : at OpenSim.Region.ScriptEngine.Yengine.XMRInstance.PostEvent (OpenSim.Region.ScriptEngine.Shared.EventParams evt) [0x0001f] in XMRInstRun.cs:69

[12:19] Andrew Hellershanks : at (wrapper remoting-invoke-with-check) OpenSim.Region.ScriptEngine.Yengine.XMRInstance.PostEvent(OpenSim.Region.ScriptEngine.Shared.EventParams)

[12:19] Andrew Hellershanks : etc...

[12:19] Vincent.Sylvester @hg.zetaworlds.com:8002 : Le problème le plus évident était la taille trop petite des paquets de la base de données pour stocker l'asset.

[12:19] Andrew Hellershanks  : Je vais voir si je peux apprendre quelque chose de plus à ce sujet et sur mantis.

[12:20] Ubit Umarov  : sur un post événement ?

[12:20] Ubit Umarov  : étrange.

[12:20] Andrew Hellershanks  : hm... c'est une idée intéressante, Vincent.

[12:20] Ubit Umarov  : Je ne peux pas deviner.

[12:20] Ubit Umarov  : et c'est ce qui le fait fonctionner.

[12:20] Andrew Hellershanks  : Le texte du script tel qu'il se trouve sur mon ordinateur fait 211772 octets.

[12:21] Ubit Umarov  : ou en cours d'exécution.

[12:21] Vincent.Sylvester @hg.zetaworlds.com:8002 : La taille maximale des paquets était de 16 Mo sur les anciennes versions de mysql. Depuis, elle a été augmentée ; la valeur par défaut devrait être beaucoup plus élevée maintenant, comme 1G même sur certaines versions.

[12:22] Ubit Umarov  : les scripts avaient une limite de 64k bytes sur les sources.

[12:22] Vincent.Sylvester @hg.zetaworlds.com:8002 : C'était un gros défaut sur les assets de HG [46] à l'époque

[12:22] Andrew Hellershanks  : Ubit, il semble que ce soit un problème après le début de l'exécution du script. Quelque chose à voir avec llMessageLinked[47]. Je pense ajouter du code supplémentaire dans LSL_Api.cs pour imprimer ce que la fonction reçoit.

[12:23] Ubit Umarov  : mais cela semble nécessiter un débogage plus détaillé.

[12:23] Andrew Hellershanks  : Le moteur meurt et ne laisse aucune information utile sur la ligne du script qu'il essayait d'exécuter au moment où il est mort.

[12:23] Ubit Umarov  : ce n'est pas sur lsl_api. 

[12:23] Andrew Hellershanks  : J'espérais que l'un des paramètres de débogage pourrait aider.

[12:23] Andrew Hellershanks  : llMessageLinked n'est pas dans LSL_Api.cs ? ?

[12:23] Ubit Umarov  : et c'est celui-là ?

[12:24] Andrew Hellershanks  : Cette fonction est mentionnée plus bas dans le backtrace.

[12:24] Ubit Umarov  : Je ne peux pas deviner ce que vous n'avez pas dit :p

[12:24] Vincent.Sylvester @hg.zetaworlds.com:8002 : C'est comme une chasse au renard avec un renard invisible.

[12:25] Ubit Umarov  : nahh juste un très mauvais rapport de problème

[12:25] Ubit Umarov  : :p

[12:26] Vincent.Sylvester @hg.zetaworlds.com:8002 : Si tu n'arrives pas à déboguer, mets-le sur mantis, s'ils ne veulent pas le partager, mets-le sur privé pour qu'au moins Ubit puisse y jeter un œil.

[12:26] Andrew Hellershanks  : Oui, le script doit être considéré comme privé.

[12:27] Vincent.Sylvester @hg.zetaworlds.com:8002 : De sombres secrets lol

[12:27] Andrew Hellershanks  : Un code propriétaire qui fait partie d'un système plus large.

[12:28] Vincent.Sylvester @hg.zetaworlds.com:8002 : J'espère qu'il ne s'agit pas d'une animation à plusieurs poses, je n'en ai pas encore vu une seule écrite correctement, elles sont toutes massivement trop compliquées et mal écrites au point de consommer une tonne de ressources.

[12:28] Vincent.Sylvester @hg.zetaworlds.com:8002 : Certains ne fonctionnent même plus sous Y.

[12:29] Vincent.Sylvester @hg.zetaworlds.com:8002 : Ou utiliser les fonctions ossl qui doivent être mises à true.

[12:29] Andrew Hellershanks  : Vincent, c'est intéressant de voir que certaines ne fonctionnent pas en Y (en supposant que ce n'est pas seulement les perms).

[12:29] Vincent.Sylvester @hg.zetaworlds.com:8002 : Ils se plantent sur les listes qu'ils génèrent ou sur les typages.

[12:29] Andrew Hellershanks  : Ce n'est probablement pas très surprenant.

[12:30] Andrew Hellershanks  : oh, c'est vrai. Probablement ceux qui utilisent le " truc pour sauver la mémoire ".

[12:30] Vincent.Sylvester @hg.zetaworlds.com:8002 : Aussi les premiers suspects pour le truc "les scripts ont cessé de fonctionner" que j'ai mentionné plus tôt.

[12:30] Vincent.Sylvester @hg.zetaworlds.com:8002 : Oh oui, lorsque cela se produit, les choses comme llSetText[48] ne sont pas non plus mises à jour, ce qui permet de savoir de quelle file il s'agit.

[12:31] Vincent.Sylvester @hg.zetaworlds.com:8002 : Mais oui, si vous n'arrivez à rien, créez simplement un ticket mantis privé pour cela.

[12:32] Ubit Umarov  : yeha, je suppose que cela va demander un débogage plus profond.

[12:33] Misterblue Waves  : je dois y aller... à bientôt !

[12:33] Ubit Umarov : cya

[12:34] Andrew Hellershanks  : Tant que je peux encore accéder à la mantis. Je ne sais pas pourquoi je ne peux toujours pas accéder aux canaux IRC.

[12:34] Ubit Umarov  : mais cela signifie qu'il y a plus de scripts.

[12:34] Andrew Hellershanks  : ok, Misterblue.

[12:34] Ubit Umarov  : sur l'objet lié.

[12:35] Ubit Umarov  : donc je suppose que l'objet entier sera nécessaire pour déboguer.

Conclusion

[12:34] Andrew Hellershanks  : Nous sommes maintenant à l'heure et demie. Sauf s'il y a des questions de dernière minute, je vais conclure la réunion.

[12:37] Andrew Hellershanks  : ok, je vais dire que cette réunion est terminée :) Merci à tous d'être venus. On se revoit la semaine prochaine.

Récupérée de « https://cogito.no-ip.info/cogito/OSWiki/index.php?title=Réunion_du_12-07-2022&oldid=6266 »