Chat log from the meeting on 2017-03-07

From OpenSimulator

Jump to: navigation, search

[10:59] George Equus: You found what you needed last night Selby?
[10:59] Selby.Evans yes -- thanks
[10:59] George Equus: cool  :)
[11:00] Selby.Evans good educator stuff there --
[11:00] Selby.Evans I will promote it
[11:00] George Equus: Yes Selby, lots of resources
[11:02] Kayaker.Magic Andrew, when you fill out a Mantis form, it asks for a git revision. How do you get that number from git? Is that the output from git describe?
[11:02] Kayaker.Magic (by the way, Hi Andrew!)
[11:03] Andrew.Hellershanks You can get the number from git log.
[11:03] Andrew.Hellershanks The first line of each changelog entry will say "commit" followed by a hash code.
[11:04] Andrew.Hellershanks Mantis is asking for the hash code that follows the word "commit".
[11:04] Kayaker.Magic So to show that I'm using the very latest, I copy that hash.
[11:04] Andrew.Hellershanks Correct.
[11:05] Kayaker.Magic When I run that latest version and ask the viewer what version I am on, it says (dev) or something like that, but I hear people talking about 0.9.2
[11:05] Andrew.Hellershanks The hash code allows the developers to know exactly which commit is the latest on in the source tree you are using.
[11:05] Kayaker.Magic Is there a secret fork I don't know about?
[11:06] Andrew.Hellershanks No. It is just a version number in the source somewhere. It is an easier way to refer to a version of code as there may be different branches ongoing.
[11:08] Kayaker.Magic Any movement towards getting Ubit to come to these meetings again? Or moving to a venue where he will be willing to show up?
[11:09] Andrew.Hellershanks I haven't seen Ubit in the OpenSim IRC channels for the past several weeks. I don't know what he is doing these days.
[11:09] Kayaker.Magic Looks like the last commit to OpenSim was early in Feb.
[11:09] Kayaker.Magic git log
[11:10] Andrew.Hellershanks Development in the master branch is on hold pending testing of the recent changes to the permissions code.
[11:10] Andrew.Hellershanks There may be work still being done in one of the branches.
[11:11] Kayaker.Magic I found a way to reproduce a bug in llListen, submitted a new Mantis 8135
[11:12] James.atLLOUD llListen has a bug? (lol)
[11:12] James.atLLOUD marcus' favorite command.
[11:12] Marcus Llewellyn: Heh
[11:13] Kayaker.Magic For ages, I have occasionally had llListen fail and return -1, never knew why. Now I have a way to make it happen on demand.
[11:13] Marcus Llewellyn: llMessageLinked is prolly more used by me. :)
[11:14] James.atLLOUD I use that alot too. And I'm sorry Marcus, it's the dialog windows that are your favorite.
[11:14] Andrew.Hellershanks I use llListen often as I have gadgets needing input by users.
[11:14] Kayaker.Magic To limit the number of llListens I have open at once, I often have one llListen that converts the message to a llMessageLink and sends it out locally.
[11:15] Marcus Llewellyn: Curiosity: Does this happen for you in objects other than those marked as temp?
[11:15] Andrew.Hellershanks Do you have > 720 temp rez items still rezzed when the llListen fails?
[11:15] Kayaker.Magic I haven't done all combinations... A single script opening and removing listens forever doesn't have the problem.
[11:16] Kayaker.Magic And it was not marked temp.
[11:16] Kayaker.Magic But if I marked it temp, it would get deleted before the problem would appear...
[11:16] James.atLLOUD do you ask about temp because this might be related to projectiles?
[11:17] Kayaker.Magic Well, it was writing projectiles that I discovered a way to get the error to happen on demand.
[11:17] Kayaker.Magic Then I simplified the code to try and make the minimum example for the mantis.
[11:18] Andrew.Hellershanks If the items are not marked temp you can have > 720 and llListen still works?
[11:19] Kayaker.Magic I can try that next I suppose.
[11:19] Kayaker.Magic I usually try to police my own prims and call llDie, temp rez is just a backup.
[11:19] Andrew.Hellershanks It is a large number of objects to have as temp. I wonder if there is some limit on temp objects that isn't on regular objects.
[11:20] Kayaker.Magic No, in my test, the objects usually only exist one at a time. It still fails after the 720'th one is rezzed and deletes itself.
[11:21] Andrew.Hellershanks ok
[11:22] James.atLLOUD interesting number 720. would have guessed a binary prime.
[11:22] Kayaker.Magic It is an estimate.
[11:22] James.atLLOUD ah
[11:23] Kayaker.Magic I rez another every 0.5 seconds, and acording to my chat log it fails after 6 minutes.
[11:23] Kayaker.Magic Curiously, it fails at about the same time in 0.9.1 and in 0.8.2
[11:24] Andrew.Hellershanks That wouldn't surprise me if the llListen related code has not been changed in some time.
[11:24] Marcus Llewellyn: It wouldn't surprise me if it were an old bug. Temp rezzing has never had the importance here that it had back in SL, where it was abused to dodge prim allowances. OpenSim's implementation may not be as robust/tested in some ways.
[11:25] Andrew.Hellershanks right
[11:26] Andrew.Hellershanks The llListen() code in LSL_Api.cs is simple. The problem must lie in another part of the code where the actual listen is handled.
[11:26] Kayaker.Magic I'm logging into another account to try the test without temp rez objects.
[11:26] Andrew.Hellershanks ok
[11:29] Kayaker.Magic Test running, I'll report back in 6 minutes.
[11:31] Andrew.Hellershanks I was hoping I could easily find the module handling the listens but I can't right now.
[11:34] Andrew.Hellershanks I think I just found the relevant code in OpenSim/Region/CoreModules/Scripting/WorldComm/WorldCommModule.cs
[11:35] Andrew.Hellershanks Kayaker, one other thing you could do that might be interesting to see would the the numbers of the listen handles.
[11:35] Marcus Llewellyn: Now find the { if (temp) } stuff. ;)
[11:35] Andrew.Hellershanks grins at Marcus
[11:36] Kayaker.Magic I've rarely seen llListen handles other than 1 in this test.
[11:36] Kayaker.Magic and -1, of course
[11:36] Andrew.Hellershanks There is no reference to "temp" in that file other than in relation to another llListen call.
[11:36] Andrew.Hellershanks Kayaker, ok. I was wondering if it might have continued to go up in value that could indicate they weren't being released properly.
[11:37] Kayaker.Magic Are the numbers a separate series in each script? Or are they region wide resources?
[11:38] Andrew.Hellershanks I'm not the one to ask. I don't know that part of the code.
[11:38] Marcus Llewellyn: I would presume they're a global sim resource, but thats a big presumption.
[11:38] Andrew.Hellershanks The comm module is non-shared.
[11:39] Kayaker.Magic I work hard to keep the number of open lListens in my code small, I remove them when not in use.
[11:39] Andrew.Hellershanks Hm... I see references to limits on the handles.
[11:39] Andrew.Hellershanks Good practice.
[11:39] Kayaker.Magic Yes, there is a maximum you can have open at once.
[11:40] Andrew.Hellershanks Ah. The limits are set in the ini file.
[11:40] Kayaker.Magic For this testing, I am in an empty region with no other scripts and only one listen handle open at once.
[11:40] Andrew.Hellershanks In LL-Function max_listens_per_region sets the maximum number of listens.
[11:41] Andrew.Hellershanks max_listens_per_script sets the maximum number of listen handles.
[11:41] Kayaker.Magic Results of the test: Even rezzing objects that were NOT temp-rez, the test failed after the same ~6 minutes.
[11:41] Andrew.Hellershanks If only one listener is rezzed you should not be running up against those limits.
[11:42] Kayaker.Magic Yes, yet I still get a fail after ~720 atempts.
[11:42] Andrew Hellershanks: ok. It does sound like you are hitting some limit somewhere.
[11:43] Kayaker.Magic I'm adding a note to the Mantis about temp rez not being the issue.
[11:44] Andrew Hellershanks: ok, ty.
[11:44] Andrew Hellershanks: The default values for those two settings are 1000 and 64 respectively.
[11:45] James atLLOUD: nice detective work :)
[11:45] Andrew Hellershanks: To dig in to the code further I need to find the ListenManager code.
[11:50] Andrew Hellershanks: Kayaker, when the listens stop working did you get a -1 for the listen handle or is the listen handle >=1 and it just isn't listening?
[11:50] Kayaker.Magic I get a -1, and then the listens don't work
[11:51] Andrew Hellershanks: ok. That does sound like it exhausted some pool of handles.
[11:51] Kayaker.Magic Yes, and I come back to the same region days later and try a test, and llListen is still returning -1 half the time.
[11:52] Kayaker.Magic Have to restart to fix that, as if some resource is lost forever.
[11:54] James atLLOUD: If Kayaker gets a fix it's all worth it! :)
[11:55] Kayaker.Magic I've had this crop up before, I assume it has happened to others, it will be good to have it fixed for everyone.
[11:55] Andrew Hellershanks: The handles are maintained in a list. That wouldn't be the cause a limit in handles.
[11:56] James atLLOUD: Andrew, can you describe more about the permissions review underway?
[11:57] James atLLOUD: Is there a particular model or practice in reviewing permissions?
[11:57] Selby.Evans Time sharing -- on my blog
[11:57] Marcus Llewellyn: It's never too late to make sure the meeting goes over it's one hour secheduled time. >:)
[11:58] Andrew Hellershanks: James, I said I would be interested in helping with perms testing but I haven't had time to get started on it yet. I don't think anyone else has stepped up to help with testing.
[11:58] James atLLOUD: Ah, ok. That's understandable. Thanx :)
[11:58] Andrew Hellershanks: James, part of the testing process will be comparing perms behaviour in OS against SL.
[11:59] Andrew Hellershanks: Some specific checks that will need to be done can be determined by looking at the changelog and seeing what perms related changes were made.
[11:59] James atLLOUD: OK - that's helpful for me to get a start on it.
[12:00] Andrew Hellershanks: The basic checks that can be done are to set perms on a prim and pass it betwen avatars. Make sure perms don't change.
[12:01] Andrew Hellershanks: Make sure that rezzing and taking an item doesn't change perms on the item.
[12:01] Andrew Hellershanks: Check perms on an object when perms are changed while in inventory. Do they stick. What happens if you change in inventory then give from inventory to another avatar.
[12:02] Andrew Hellershanks: There are a few other cases I can think of such as a vendor giving objects.
[12:02] Andrew Hellershanks: Other perms checks involved groups and land.
[12:02] Kayaker.Magic Can you give someone a full perm item with a copy only script in it?
[12:02] Andrew Hellershanks: hm... I need to save that list as a guide for my own testing. :)
[12:03] Marcus Llewellyn: hehe
[12:03] Marcus Llewellyn: Sooo many edge cases.
[12:03] James atLLOUD: lol - I know that feeling. When I make training I usually can't make it fast enough before someone asks me anyway. then that becomes the training!
[12:03] Andrew Hellershanks: Kayaker, that is another set of check to be done. Check what you can do with an object based on the perms of its contents.
[12:04] Andrew Hellershanks: Marcus, yes. A lot of test cases.
[12:04] Selby.Evans If you use the perm setter in contents, it may not work on all the contents (Firestorm).
[12:04] Andrew Hellershanks: I may do more tests than are required but I don't the implementation of the code re: perms so best to do too many cases than not enough.
[12:05] Andrew Hellershanks: Selby, that would be another possible issue to check. Is that a viewer specific problem or an OS one.
[12:05] Kayaker.Magic Used to be, if you took an object into inventory that was full perm, and it had a copy only item in inventory, the perms on the object would be changed to the minimum of the items in inventory. Annoying.
[12:05] Selby.Evans in particular, script perms may not change.
[12:05] James atLLOUD: I've run into that I think @selby
[12:05] Selby.Evans I have only tried on Firestorm
[12:06] Andrew Hellershanks: Kayaker, yes. The application of folded perms has been changed. That problem may no longer exist. It needs to be tested to see if the issues still exists or not.
[12:08] George Equus: Sometime I pick up object that are No copy when in Inv then I rez it, vanish from Inv, then Take the rezed object, goes back to Inv and find that it now is Copy... and can be rezed as before, only this time leaving original in Inv. weird
[12:08] George Equus: On FS
[12:09] Andrew Hellershanks: ok
[12:09] James atLLOUD: Should these tests be on os .9.1?
[12:09] George Equus: A bug? "by design"?
[12:09] Kayaker.Magic That problem George has seen, I see it on object dragged around on HyperGrid to other grids.
[12:10] George Equus: hmm, could be, not taken note of where objects been picked up.. missed that
[12:10] Andrew Hellershanks: If any of you are doing your own testing of perms related issues, please document the version of OS that is running where you are doing the tests. The hash code for the version please and not just an 0.9.1, or 0.9.2 as that isn't specific enough. Include what you did, what the result was, and what you expected.
[12:11] George Equus: could come from a vendor, straight from the ground Take copy doesn't matter
[12:11] Andrew Hellershanks: yes, tests should be done on the latest code (ie. the version from git master).
[12:11] Kayaker.Magic (asside on llListen issue, running the test on InWorldz which forked off at OS 0.6 and after 10 minutes of testing I do not see the error yet)
[12:12] Selby.Evans I have had the problem George described with objects I made myself using my own scripts and textures.
[12:13] Andrew Hellershanks: I see the code running here has the hash code of 056ccae so it is about the most recent. No perms code was changed since that commit.
[12:14] Andrew Hellershanks: Perms issues are not likely to be viewer specific but it wouldn't hurt to include which viewer and which version of it was used in any testing you have done.
[12:14] George Equus: Just to add to confusion, I had prims I made 100% and finding later that I have no rights to them at all. Have to apply God mode on my own stuff.... and has happened to several others as well
[12:14] Kayaker.Magic Our hour is well over, time to call the meeting to a close?
[12:15] George Equus: Interesting evening.
[12:15] James atLLOUD: Agree @george
[12:15] Andrew Hellershanks: Does anyone else have something they want to talk about before we call this meeting to a close.

Personal tools
About This Wiki