« Réunion du 16-11-2021 » : différence entre les versions
Aller à la navigation
Aller à la recherche
Aucun résumé des modifications |
|||
Ligne 18 : | Ligne 18 : | ||
</pre> | </pre> | ||
=Tests des moteurs de scripts= | =Tests des moteurs de scripts= | ||
X :[http://opensimulator.org/wiki/XEngine XEngine] Y:[http://opensimulator.org/wiki/YEngine YEngine] | |||
<pre> | <pre> | ||
[11:03] Vincent.Sylvester @hg.zetaworlds.com:8002 : En parlant de casser, j'ai regardé les tests ScriptEngine cassés cette semaine, tous sauf trois semblent fonctionner ... plus ou moins. | [11:03] Vincent.Sylvester @hg.zetaworlds.com:8002 : En parlant de casser, j'ai regardé les tests ScriptEngine cassés cette semaine, tous sauf trois semblent fonctionner ... plus ou moins. |
Version du 18 novembre 2021 à 15:15
Bientôt la traduction
Introduction
[11:00] Vincent.Sylvester @hg.zetaworlds.com:8002 : J'ai entendu des rumeurs sur la disparition de cmake, mais je ne suis pas sûr que ce soit vrai. [11:00] Vincent.Sylvester @hg.zetaworlds.com:8002 : les viewers ne l'utilisent-ils pas encore ? [11:00] Andrew Hellershanks : Bonjour à tous. [11:00] Gavin.Hird @grid.xmir.org:8002 : Je ne peux pas dire que j'ai vu cmake décliner en ce moment. [11:01] Gavin.Hird @grid.xmir.org:8002 : je viens de le mettre à jour il y a 2 jours. [11:01] Gavin.Hird @grid.xmir.org:8002 : Salut Andrew [11:01] Vincent.Sylvester @hg.zetaworlds.com:8002 : quelque chose à propos d'une mise à jour qui casse quelque chose, je l'ai juste entendu en passant, mais je n'ai aucune idée des détails. [11:01] Vincent.Sylvester @hg.zetaworlds.com:8002 : les dépendances sont toujours gênantess. [11:01] Gavin.Hird @grid.xmir.org:8002 : peut-être, IDK [11:01] Vincent.Sylvester @hg.zetaworlds.com:8002 : Je me souviens avoir essayé de compiler FS et d'être bloqué en essayant de trouver la version spécifique de python dont il a besoin. [11:02] Selby.Evans @grid.kitely.com:8002 : bonjour à tous. [11:02] Ubit Umarov : les mises à jour des outils linux cassent toujours des choses. [11:02] Ubit Umarov : salut selby.Evans [11:03] Ubit Umarov : à un moment donné, il faudrait spécifier la version exacte de gcc pour compiler un programme, en particulier pour le noyau linux.
Tests des moteurs de scripts
[11:03] Vincent.Sylvester @hg.zetaworlds.com:8002 : En parlant de casser, j'ai regardé les tests ScriptEngine cassés cette semaine, tous sauf trois semblent fonctionner ... plus ou moins. [11:04] Vincent.Sylvester @hg.zetaworlds.com:8002 : J'ai copié le truc de X vers Y, j'ai dû ajuster légèrement deux d'entre eux, mais maintenant ils passent aussi. [11:04] Ubit Umarov : bien, c'est une chose, les tests de script devraient être indépendants du moteur. [11:04] Ubit Umarov : bien sûr, ils ne peuvent pas l'être car les moteurs sont différents... [11:04] Ubit Umarov : mais ils devraient l'être. [11:05] Cuga.Rajal @rajal.org:9000 : Je ne suis pas encore passé de X à Y. Dois-je le faire ? [11:05] Vincent.Sylvester @hg.zetaworlds.com:8002 : Ce sont les mêmes tests, tout ce que j'ai fait jusqu'à présent, c'est de modifier les paramètres de configuration qu'ils définissent afin qu'ils chargent le bon moteur à tester. [11:05] Vincent.Sylvester @hg.zetaworlds.com:8002 : Petit changement dans les tests de croisement pour omettre l'événement de changement qui est déclenché au redémarrage de la région puisque dans Y cela fonctionne évidemment correctement alors que dans X cela ne se déclenche pas. [11:05] Ubit Umarov : certains ont probablement échoué parce qu'ils étaient fondés sur de mauvaises hypothèses. [11:06] Ubit Umarov : le changement est déclenché au démarrage de la région ? [11:06] Jagga Meredith : Je suis heureux avec Yengine [11:06] Ubit Umarov : Je veux dire que la région a changé ? [11:06] Vincent.Sylvester @hg.zetaworlds.com:8002 : Les deux que je n'arrive pas à faire fonctionner sont étranges, les erreurs n'ont pas vraiment de sens pour moi pour le moment, mais ce qu'ils testent n'est pas non plus très important. [11:07] Ubit Umarov : sur notre Jenkins, j'ai désactivé beaucoup de tests. [11:07] Ubit Umarov : certains parce qu'ils sont simplement mauvais. [11:07] Ubit Umarov : d'autres pour gagner du temps [11:07] Vincent.Sylvester @hg.zetaworlds.com:8002: What fires is 0x400 which is region restart, I think that is to be expected given the scene is setup and the script rezzed practically instantly without wait so I guess it runs into that somehow [11:07] Ubit Umarov: as is that box takes like 5 minutes to do all [11:07] Ubit Umarov: i mean to do compile and current subset of tests [11:08] Ubit Umarov: on sundays can take like 10hours :p [11:08] Vincent.Sylvester @hg.zetaworlds.com:8002: What is interesting how in vscode a lot of working tests fail while they are fine on Jenkins [11:08] Ubit Umarov: what is vscode? [11:08] Ubit Umarov: :p [11:08] Vincent.Sylvester @hg.zetaworlds.com:8002: Not sure if that is some version difference or system dependency to blame there [11:09] Vincent.Sylvester @hg.zetaworlds.com:8002: Think is still all nunit 264 [11:09] Ubit Umarov: some tests have time dependencies [11:09] Vincent.Sylvester @hg.zetaworlds.com:8002: I suspect that plays into that some timing and dependency difference not accounted for [11:10] Vincent.Sylvester @hg.zetaworlds.com:8002: Mostly on complex tests that are a bit hard to read still, thankfully most of the script engine tests are pretty straight forward so fixing those wasn't difficult [11:10] Ubit Umarov: well tests will need a deep revision [11:10] Ubit Umarov: some whre made just bad, from start, others did got obsolete [11:11] Ubit Umarov: all on a old nunit version also [11:11] Ubit Umarov: but a few tehre did detect a few of mistakes from me... so some are useful [11:11] Vincent.Sylvester @hg.zetaworlds.com:8002: I mean given how some bugs existed without a test ever finding them is testament to that, but is also not really easy to write them given the abstract nature of how it works [11:12] Vincent.Sylvester @hg.zetaworlds.com:8002: Like poking holes into an onion [11:12] Ubit Umarov: testing is a complex thing [11:13] Ubit Umarov: now all take advantage of internet and automatic updates, turning the end user the tester [11:13] Ubit Umarov: some even make users pay to test, on the so called early access things [11:14] Vincent.Sylvester @hg.zetaworlds.com:8002: Others just throw it out and let the users fix it up [11:14] Vincent.Sylvester @hg.zetaworlds.com:8002: Granted a bit easier with open source heh [11:14] Ubit Umarov: do not tell opensim secrets in public vincent.Sylvester [11:15] Ubit Umarov: errr Ooops [11:15] Ubit Umarov: ;) [11:15] Ubit Umarov: so what news do you have about opensim? [11:16] Vincent.Sylvester @hg.zetaworlds.com:8002: You changed some priority queue thing [11:16] Vincent.Sylvester @hg.zetaworlds.com:8002: Been meaning to ask what that was about actually [11:16] Jamie.Jordan @grid.kitely.com:8002: hi everybody [11:16] Gavin.Hird @grid.xmir.org:8002: Hi Jamie [11:17] Andrew Hellershanks: Hello, Jamie. [11:17] Ubit Umarov: in some timing cases, we did get null references poluting log [11:17] Selby.Evans @grid.kitely.com:8002: hi Jamie [11:17] Andrew Hellershanks: Nothing really to report this week about OpenSim code wise. There were two small changes but it reads like they were just some internal code cleanup. [11:17] Ubit Umarov: so i added some try/catch to "hide" that [11:18] Ubit Umarov: those null refs happen bc opensim left hand has no idea what right is doing [11:18] Andrew Hellershanks: :) [11:18] Ubit Umarov: and somethings do get released while the other is using them [11:18] Ubit Umarov: like when a avatar is gone [11:18] Vincent.Sylvester @hg.zetaworlds.com:8002: Hence removing some locks I see [11:19] Ubit Umarov: locks is a bit diferent [11:19] Andrew Hellershanks: Isn't that also where ref counts come in? [11:19] Ubit Umarov: i replaced some by lower spectrum ones [11:19] Ubit Umarov: what ref counts? [11:20] Ubit Umarov: love ppl talking from.. well somewhere :p [11:20] Ubit Umarov: this things happen also because total blind and massive multitasking [11:21] Andrew Hellershanks: Aren't the things being null referenced objects. AFAIK, objects are supposed to have (or can have) ref counts so the system knows when it is safe to get rid of them. [11:21] Ubit Umarov: very hard to fix now [11:21] Ubit Umarov: system fails to release them [11:22] Ubit Umarov: and also contrary to claims a lot of things need to be cleared by hand [11:22] Vincent.Sylvester @hg.zetaworlds.com:8002: good ole gc [11:22] Ubit Umarov: we have no access to ref counts [11:22] Ubit Umarov: those are internal things [11:23] Ubit Umarov: i did add several IsDeleted things here and there [11:23] Ubit Umarov: but still can't fix all issues, some because multitask [11:23] Andrew Hellershanks: Right. If the system is left to clean up the objects based on the ref counts the system should be deleting the object while still in use. If the code is doing manual clean up in one or more places then all bets are off. [11:24] Ubit Umarov: things are there when tested, then are gone [11:24] Vincent.Sylvester @hg.zetaworlds.com:8002: I wonder if all this being in the udp stack is down to faster cpu and networks now showing things hidden by delays in the past, certainly have had more glitches with timing on my new computer compared to the old one [11:24] Ubit Umarov: and we can't put locks everywhere [11:25] Ubit Umarov: soem of this things did start to show up when i added proper dispose of things GC never releases [11:25] Ubit Umarov: like all framework things that have the method Dispose() [11:26] Ubit Umarov: that opensim never did actually disposed, so no null references visible, ofc things stayed there lost for ever [11:27] Vincent.Sylvester @hg.zetaworlds.com:8002: Well if it then actually disposes and mono voodoo not refusing heh [11:28] Ubit Umarov: as i said that change also moved some locks so they impact less code, just the one that needs them [11:28] Ubit Umarov: yeah GC fails to release memory it was suposed to [11:28] Ubit Umarov: we can still see a region just decide to use 20GB of ram [11:29] Vincent.Sylvester @hg.zetaworlds.com:8002: I wonder if some of it is down to code just being old and relying implicit on delays from back when cpu wasn't so powerful [11:29] Ubit Umarov: only a few timing issues .. not this mem things [11:29] Ubit Umarov: teleports are a damm timing issue thing [11:29] Vincent.Sylvester @hg.zetaworlds.com:8002: I did run some tests regarding that timer event divergence and found it to be related to cpu speed even, which is interesting [11:30] Vincent.Sylvester @hg.zetaworlds.com:8002: Could potentially measure cpu speed by how quickly timer event adds a second [11:30] Ubit Umarov: but opensim has a plague of potencial timing issues [11:30] Ubit Umarov: most bc of its uncontroled multitask [11:30] Ubit Umarov: design [11:31] Ubit Umarov: fear that on a busi region the threads spend more time waiting on locks than doing things [11:31] Ubit Umarov: well at least a lot of time :) [11:32] Vincent.Sylvester @hg.zetaworlds.com:8002: You wouldn't notice it the viewer would go down to single digit fps anyways heh [11:32] Ubit Umarov: viewers are still mostly single thread [11:32] Ubit Umarov: ll is finally moving some thigs to other threads [11:33] Ubit Umarov: that it is the oposite case of multi cores usage.. not using them :P [11:34] Ubit Umarov: opensim was made on the other case.. use cores cpus may have in 2100 [11:34] Andrew Hellershanks: I noticed a timing issue this past week in OS related to keyframe motion. [11:35] Andrew Hellershanks: A sequence of steps that is supposed to be done in 64 seconds takes closer to 68. [11:36] Andrew Hellershanks: I haven't had time to look at the OS code to get any idea as to why there is a difference between expected and actual timing. [11:36] Vincent.Sylvester @hg.zetaworlds.com:8002: Assuming that probably uses the same timing control as timer event, which tends to go out of sync rather quickly as well, especially once you start adding code to the event itself [11:37] Andrew Hellershanks: AFAICR, in 0.8.2 the timing was perfect or so close I didn't notice any discrepancy. [11:37] Ubit Umarov: well as i said months ago i remade KFM code entire [11:37] Ubit Umarov: but its serielization is incompatible to older [11:37] Ubit Umarov: so.. yeach.. on hold :P [11:38] Vincent.Sylvester @hg.zetaworlds.com:8002: When you time these things make sure to use strict floats, as in 3.0f and it makes sense to adjust for the initial timing difference say 2.97f for example, that generally gets you better results [11:38] Ubit Umarov: yes andrew we all know 0.8.2 was perfect [11:38] Ubit Umarov: bahh [11:38] Vincent.Sylvester @hg.zetaworlds.com:8002: From there you can then get a better idea on where the issue starts [11:39] Vincent.Sylvester @hg.zetaworlds.com:8002: Been digging around in timer code a little bit think there is some precision lost on a type conversion, but haven't gotten around to really play with that [11:39] Andrew Hellershanks: Vincent, what do you mean by the initial timing difference. [11:39] Ubit Umarov: well like 0.9 actually does kfm, while 0.8 did.. something [11:40] Ubit Umarov: whatever [11:40] Ubit Umarov: file a mantis, in a for others can repo [11:40] Ubit Umarov: in a form.. [11:40] Vincent.Sylvester @hg.zetaworlds.com:8002: If you run say timer event every 3 seconds it initially doesn't start at 3, but adds say 0.03 to it [11:40] Vincent.Sylvester @hg.zetaworlds.com:8002: Probably because execution time of the code itself [11:41] Vincent.Sylvester @hg.zetaworlds.com:8002: When you adjust for that you end up getting more accurate timing for longer [11:41] Vincent.Sylvester @hg.zetaworlds.com:8002: Guess it adjusts for some of the precision lost somewhere in the pipe [11:42] Vincent.Sylvester @hg.zetaworlds.com:8002: Like I have a feeling if I added debug output to timer event to see how long it itself takes to run probably just skews the results more [11:42] Ubit Umarov: some timing things do have intensional drift [11:42] Ubit Umarov: intencional [11:42] Ubit Umarov: it is called Dilation.. [11:43] Ubit Umarov: just it is not accounted for [11:43] Vincent.Sylvester @hg.zetaworlds.com:8002: OpenSim by nature never really fully idles either so you get a millisecond here or there as well [11:44] Ubit Umarov: we can't account for time Dilation as sl, also bc of the multitask [11:44] Ubit Umarov: so each part drifts its way [11:44] Vincent.Sylvester @hg.zetaworlds.com:8002: It's like that quantum particle thing, as soon as you try to add code to debug things you just skew the results even more [11:44] Ubit Umarov: on my new KFM all the code runs on heartbeat [11:45] Ubit Umarov: so its timing will be more in sync with the region heartbeat [11:46] Ubit Umarov: i just need to figure how to convert the btw old and new serielization [11:46] Ubit Umarov: for regions crossings [11:46] Vincent.Sylvester @hg.zetaworlds.com:8002: I'll wish you luck in that, doesn't sound like funnest of tasks :) [11:50] Andrew Hellershanks: An extra 0.03 per second would account for about half run time error I see. I'll need to retime it to verify the actual difference. I thought I had it written down on a piece of paper near me but I can't find it. [11:51] Vincent.Sylvester @hg.zetaworlds.com:8002: http://opensimulator.org/mantis/view.php?id=3862 That's what I am talking about Andrew [11:51] Vincent.Sylvester @hg.zetaworlds.com:8002: Interesting results which I have yet to really get to the bottom of as to the why, but it helped a bit in understanding some of the timer issues I have had [11:52] Vincent.Sylvester @hg.zetaworlds.com:8002: That said like Ubit mentioned best not to rely on timer event for accuracy [11:52] Vincent.Sylvester @hg.zetaworlds.com:8002: timer event, only slightly more accurate than your inner clock lol [11:52] Ubit Umarov: guys time accuracy does not apply to PCs [11:52] Ubit Umarov: unless on special kernel side devices [11:53] Andrew Hellershanks: Vincent, that does seem similar to the issue I have. [11:53] Ubit Umarov: that is why a car controler does not run on windows or linux [11:53] Gavin.Hird @grid.xmir.org:8002: lol [11:53] Ubit Umarov: ( the display may.. ofc ) [11:54] Ubit Umarov: and there are RTOS versions of linux also [11:54] Gavin.Hird @grid.xmir.org:8002: have you not seen the Windows XP logo when the Tesla car controller crash? [11:54] Ubit Umarov: XP still? [11:54] Vincent.Sylvester @hg.zetaworlds.com:8002: what even is time, just a concept, all it does is make you old :) [11:54] Ubit Umarov: but bet that is on the UI devices [11:54] Gavin.Hird @grid.xmir.org:8002: I have at least seen it on ATMs [11:54] Andrew Hellershanks: I could compensate by adjusting the cycle time but it becomes an issue when not knowing if a grid has done anything to their code to address that issue. If so, the fix needed for one grid would throw things off in another. [11:54] Gavin.Hird @grid.xmir.org:8002: very recently [11:55] Vincent.Sylvester @hg.zetaworlds.com:8002: huh round here they just blow those up lately [11:55] Ubit Umarov: ( by controler i did not meant the UI things of cars.. but the low level things oc ECC etc [11:56] Ubit Umarov: see for exmaple [11:56] Ubit Umarov: a framework ( even a win32) timer [11:56] Ubit Umarov: what is does is to put on the threads work pool a request to run the timer event code [11:57] Ubit Umarov: "one day" when there is a thread free to do it [11:58] Ubit Umarov: just that adds sevel ms delay ( at least 15 on windows ) [11:58] Vincent.Sylvester @hg.zetaworlds.com:8002: If you want to have some fun with timing, just change your clocksource from tsc to hpet, backup your stuff first though [11:59] Andrew Hellershanks: Wow. This hour went by very quickly today. Does anyone have some other topic they wanted to talk about today before we wrap things up? [11:59] Ubit Umarov: well and that is a diference btw game consoles and pcs [11:59] Ubit Umarov: ( or should be.. ) [11:59] Gavin.Hird @grid.xmir.org:8002: ther has been a lot of discussions about map tiles [12:00] Gavin.Hird @grid.xmir.org:8002: storing in the db [12:00] Ubit Umarov: the store on db is actually obsolete [12:00] Andrew Hellershanks: Don't forget about the Open Simulator Community Conference coming up on the weekend of December 11 and 12. Be sure to mark your calendars. [12:00] Ubit Umarov: at least for viewers usage [12:00] Gavin.Hird @grid.xmir.org:8002: someone suggested an elaborate script to clear them out, but it only takes a simple SQL query [12:00] Ubit Umarov: those are clear on each region restart [12:01] Ubit Umarov: ofc not for dead regions :) [12:01] Ubit Umarov: but issue is also on map service disk [12:01] Ubit Umarov: and that is NOT eaasy [12:01] Ubit Umarov: one can't go there and just delete region files [12:02] Gavin.Hird @grid.xmir.org:8002: not? [12:02] Vincent.Sylvester @hg.zetaworlds.com:8002: delete all terrainImage_% pretty much yeah, but if you store assets in files you need to find the files and remove those as well, which is not as easy and then you still have the issue of the different map tile scales which can only be altered when new tiles are submitted, there is no "cut this one out" [12:02] Ubit Umarov: bc map tiles have levels [12:02] Ubit Umarov: high resolution is a region tile [12:02] Ubit Umarov: less is a image made of 4 regions [12:02] Ubit Umarov: less.. etc [12:02] Ubit Umarov: don't remember how many levels [12:02] Gavin.Hird @grid.xmir.org:8002: I just cleaned out 2 years of tiles [12:02] Vincent.Sylvester @hg.zetaworlds.com:8002: I did write some code to upload "water" on shutdown, but that doesn't work so well because the maptile scales are created async to the upload [12:03] Gavin.Hird @grid.xmir.org:8002: shrank the Db by about 8 GB [12:03] Ubit Umarov: that is heavy code actually [12:03] Ubit Umarov: to rebuild all those zoom level tiles [12:03] Vincent.Sylvester @hg.zetaworlds.com:8002: Yes maptiles are created, not updated in db, so regularly cleaning needs to be done [12:04] Vincent.Sylvester @hg.zetaworlds.com:8002: I have some internal code that talks to regions to request new tiles after I nuke them all, but oh boy does that give Robust a workout [12:04] Ubit Umarov: again the ones on DBs as assets are old ones for old v1 viewers [12:04] Ubit Umarov: ( thing we do use them elsewhere also) [12:04] Vincent.Sylvester @hg.zetaworlds.com:8002: yes [12:04] Ubit Umarov: the ones viewers use on map are the more complex ones i just told about [12:05] Vincent.Sylvester @hg.zetaworlds.com:8002: It's a mess and not easy to figure out a good solution to resolve either [12:05] Ubit Umarov: every time we change one region we need to process several images [12:05] Vincent.Sylvester @hg.zetaworlds.com:8002: ... and there is worse garbage collecting in the db as well [12:05] Ubit Umarov: for all those zoom levels [12:05] Ubit Umarov: you casn see the code on the mapservice [12:06] Ubit Umarov: the assets are easy problem [12:06] Ubit Umarov: or easier [12:06] Vincent.Sylvester @hg.zetaworlds.com:8002: I mean uploading water on shutdown "works" to clear the levels, but in turn that creates more database mess [12:07] Vincent.Sylvester @hg.zetaworlds.com:8002: And robust needs them to create the scales so cannot delete them immediately either [12:07] Ubit Umarov: well to suport something like that, one should just use a fixed map asset [12:07] Ubit Umarov: not upload a new water one [12:08] Vincent.Sylvester @hg.zetaworlds.com:8002: Yep [12:08] Ubit Umarov: but several grids do want regions on map een if down [12:09] Ubit Umarov: in fact on several grids like kitely regions are normaly down until someone goes there [12:09] Ubit Umarov: including from click on map :) [12:09] Vincent.Sylvester @hg.zetaworlds.com:8002: A good solution would be Robust regularly going through the list of regions and requesting new tiles, if none are given it assumes water and rebuilds, but that would put a huge burden on it [12:09] Ubit Umarov: se not even easy to define When to clear map tiles [12:09] Vincent.Sylvester @hg.zetaworlds.com:8002: Plus teaching Robust to anything with "regularity" is... fun... [12:10] Ubit Umarov: easy grid can have own needs [12:10] Ubit Umarov: so manual is a solution for now :) [12:11] Andrew Hellershanks: I have sometimes wondered whether there should be some external program to handle maptile generation. That would likely have its own issues. [12:11] Vincent.Sylvester @hg.zetaworlds.com:8002: Ultimately the desire is there for removal given there exist beginnings of code in that direction and it is good programming standard to make sure a piece of software doesn't create massive amounts of orphaned data [12:11] Vincent.Sylvester @hg.zetaworlds.com:8002: But yeah definition thing [12:12] Vincent.Sylvester @hg.zetaworlds.com:8002: Also some of this code on actual maptile handling is... crude... [12:13] Vincent.Sylvester @hg.zetaworlds.com:8002: If you ever seen var regions not have proper tiles just a single region one instead, that's down to some quirk with throttling of the requests it seems, but beats me as to why, removed all incoming rejection things on Robust and it still happens [12:13] Ubit Umarov: well on creating a new map, code does delete the old map asset [12:13] Ubit Umarov: but osgrid does enforce that assets are never deleted, so they stay there :p [12:13] Gavin.Hird @grid.xmir.org:8002: for the version 1 tiles uploaded to the db, it should be possible to create a trigger that zaps the previous record of the same on upload of a new [12:14] Ubit Umarov: in fact we do get a error now with osgrid refusal to delete the asset :) [12:15] Ubit Umarov: ( other grids also.. bc assets services does impose blind rule that assets are never deleted ) [12:15] Vincent.Sylvester @hg.zetaworlds.com:8002: Which is fun ;) [12:16] Ubit Umarov: well it is a rule [12:16] Ubit Umarov: i many cases a nice security thing [12:16] Ubit Umarov: (disk crashes do delete the assets :P ) [12:16] Gavin.Hird @grid.xmir.org:8002: till it is not [12:17] Ubit Umarov: we are luck disks sizes kept growing [12:17] Ubit Umarov: for identical costs [12:18] Gavin.Hird @grid.xmir.org:8002: while they put in inferior components for the same price [12:18] Ubit Umarov: even so some grids did delete assets [12:18] Gavin.Hird @grid.xmir.org:8002: or change the encoding scheme without telling anyone [12:18] Ubit Umarov: gavin that is called making business [12:18] Gavin.Hird @grid.xmir.org:8002: making monkey business [12:18] Vincent.Sylvester @hg.zetaworlds.com:8002: Backups still a headache with the size and file count, forget versioning on any reasonable scale [12:18] Andrew Hellershanks: hehe [12:19] Ubit Umarov: business is the art of legally stealing :p [12:19] Andrew Hellershanks: Vincent, that is another issue. [12:19] Vincent.Sylvester @hg.zetaworlds.com:8002: 2 million assets into git is the best fireworks I have seen lately [12:19] Gavin.Hird @grid.xmir.org:8002: why would you do that? [12:20] Vincent.Sylvester @hg.zetaworlds.com:8002: To see what would happen [12:20] Andrew Hellershanks: Vincent, ouch [12:20] Vincent.Sylvester @hg.zetaworlds.com:8002: I spent two days digging in nunit tests I'm allowed some fun lol [12:20] Andrew Hellershanks: :) [12:21] Cuga.Rajal @rajal.org:9000: Probably not relevant to anyone here, but if your DB is small enough you can clean quite a bit of assets with https://grimore.org/opensim/database/asset_cleaner [12:22] Gavin.Hird @grid.xmir.org:8002: I keep autovacuum on for postgres [12:22] Gavin.Hird @grid.xmir.org:8002: it does not clear all, but it zaps quite a bit of old records [12:22] Cuga.Rajal @rajal.org:9000: yes [12:23] Ubit Umarov: on that.. nothing can delete orphaned assets just because is near impossible to detect them [12:23] Gavin.Hird @grid.xmir.org:8002: it never clears anything in assets [12:23] Gavin.Hird @grid.xmir.org:8002: because as you say, it is impossible for it to know if they are redundant or not [12:23] Andrew Hellershanks: Detecting orphaned assets is not a trivial task. [12:24] Gavin.Hird @grid.xmir.org:8002: unless you have explicitly deleted records, then it clears up the debris and shrinks the db szie [12:24] Ubit Umarov: we can't scan other assets, inventories or regions ( that may be down) to find references to assets [12:24] Vincent.Sylvester @hg.zetaworlds.com:8002: Even knowing where to look, that's still a lot of places to check and that means te queries get heavy very quickly [12:24] Gavin.Hird @grid.xmir.org:8002: like it did today when I deleted 12000 maptiles [12:24] Andrew Hellershanks: Asset references could be buried in rezzer or scripts. [12:24] Ubit Umarov: map tiles are easy [12:25] Gavin.Hird @grid.xmir.org:8002: yeah [12:25] Ubit Umarov: they have a specific asset type [12:25] Vincent.Sylvester @hg.zetaworlds.com:8002: script generated notecards... there's a horror movie for ya [12:25] Gavin.Hird @grid.xmir.org:8002: which type is that? [12:25] Ubit Umarov: map [12:25] Ubit Umarov: lol [12:25] Gavin.Hird @grid.xmir.org:8002: asset type in the asset table is a number [12:26] Selby.Evans @grid.kitely.com:8002: must go -- bye all [12:26] Gavin.Hird @grid.xmir.org:8002: bye Selby [12:26] Vincent.Sylvester @hg.zetaworlds.com:8002: Just apply nuke to terrainImage_% works too lol [12:26] Gavin.Hird @grid.xmir.org:8002: it does [12:26] Ubit Umarov: oops not type [12:27] Andrew Hellershanks: Bye Selby. [12:27] Vincent.Sylvester @hg.zetaworlds.com:8002: I mean if you name your texture that I'll throw coffee beans at you lol [12:27] Andrew Hellershanks: hehe [12:28] Ubit Umarov: it is assetFlags [12:28] Ubit Umarov: public enum AssetFlags : int { Normal = 0, // Immutable asset Maptile = 1, // What it says Rewritable = 2, // Content can be rewritten Collectable = 4, // Can be GC'ed after some time } [12:28] Andrew Hellershanks: Almost half past now. Any other final comments before I close this meeting? [12:28] Jamie.Jordan @grid.kitely.com:8002: have a great day yall [12:28] Andrew Hellershanks: Bye, Jamie. [12:28] Ubit Umarov: something sadly broken [12:29] Ubit Umarov: but it is there on the dbs [12:29] Gavin.Hird @grid.xmir.org:8002: ok, good to know [12:29] Andrew Hellershanks: I wonder how often assets are created when you are editing a script. [12:29] Gavin.Hird @grid.xmir.org:8002: so it is not updated correct= [12:30] Ubit Umarov: in fact used to allow deletes [12:30] Ubit Umarov: if (m_allowedTypes == AllowedRemoteDeleteTypes.All || (int)(asset.Flags & AssetFlags.Maptile) != 0) { result = m_AssetService.Delete(assetID); } [12:30] Vincent.Sylvester @hg.zetaworlds.com:8002: You don't wanna know the mess it makes Andrew, it makes you want to pull your hair out [12:30] Ubit Umarov: on some asset services that had not forgotten this ( like new osgrid one ) [12:31] Gavin.Hird @grid.xmir.org:8002: looks like all my maptiles have flag set to 1 [12:31] Andrew Hellershanks: Vincent. :) There are times I think it should be able to update an existing asset when you make a change. Other times it would need to create a new asset. Knowing which can be done when is not easy. [12:31] Ubit Umarov: wlel it should be a bitthing [12:31] Ubit Umarov: but its use is kinda broken [12:31] Ubit Umarov: bad born code :( [12:31] Cuga.Rajal @rajal.org:9000: I should head out too.. Take care everyone [12:32] Ubit Umarov: but should work on maps [12:32] Jagga Meredith: quick question. Got a grid. DSTZone = "America/Los_Angeles;Pacific Standard Time" but clock is 8 hours ahead. ideas? [12:32] Gavin.Hird @grid.xmir.org:8002: if writing the flag is correct it can be sued for zapping tiles [12:32] Andrew Hellershanks: ok, Cuga. Thanks for dropping by. [12:32] Gavin.Hird @grid.xmir.org:8002: you can be sued for zapping tiles... [12:33] Gavin.Hird @grid.xmir.org:8002: Cheers Cuga [12:33] Andrew Hellershanks: Jagga, sounds like something is set for GMT/UTC time or some function is using the wrong time routine. [12:33] Vincent.Sylvester @hg.zetaworlds.com:8002: I dread, but I gotta keep digging into the data structures at some point [12:33] Jagga Meredith: ok [12:34] Andrew Hellershanks: Jagga, where is that DSTZone thing set? I don't recognize that as the way to set timezone. I usually set it at the system level and not in a shell script before running a program. [12:36] Andrew Hellershanks: Jagga, check how the timezone has bee set on the system. See what you get when you type 'date' in a terminal window. [12:37] Andrew Hellershanks: I need to get going so I'll close this meeting for today. [12:37] Andrew Hellershanks: Thank you all for coming. See you again next week.