Chat log from the meeting on 2017-03-07

[10:59] George Equus: You found what you needed last night Selby?
[10:59] Selby.Evans @grid.kitely.com:8002: yes -- thanks
[10:59] George Equus: cool  :)
[11:00] Selby.Evans @grid.kitely.com:8002: good educator stuff there --
[11:00] Selby.Evans @grid.kitely.com:8002: I will promote it
[11:00] George Equus: Yes Selby, lots of resources
[11:02] Kayaker.Magic @grid.kitely.com:8002: 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 @grid.kitely.com:8002: (by the way, Hi Andrew!)
[11:03] Andrew.Hellershanks @hg.osgrid.org: You can get the number from git log.
[11:03] Andrew.Hellershanks @hg.osgrid.org: The first line of each changelog entry will say "commit" followed by a hash code.
[11:04] Andrew.Hellershanks @hg.osgrid.org: Mantis is asking for the hash code that follows the word "commit".
[11:04] Kayaker.Magic @grid.kitely.com:8002: So to show that I'm using the very latest, I copy that hash.
[11:04] Andrew.Hellershanks @hg.osgrid.org: Correct.
[11:05] Kayaker.Magic @grid.kitely.com:8002: When I run that latest version and ask the viewer what version I am on, it says 0.9.1.0 (dev) or something like that, but I hear people talking about 0.9.2
[11:05] Andrew.Hellershanks @hg.osgrid.org: 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 @grid.kitely.com:8002: Is there a secret fork I don't know about?
[11:06] Andrew.Hellershanks @hg.osgrid.org: 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 @grid.kitely.com:8002: 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 @hg.osgrid.org: 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 @grid.kitely.com:8002: Looks like the last commit to OpenSim was early in Feb.
[11:09] Kayaker.Magic @grid.kitely.com:8002: git log
[11:10] Andrew.Hellershanks @hg.osgrid.org: Development in the master branch is on hold pending testing of the recent changes to the permissions code.
[11:10] Andrew.Hellershanks @hg.osgrid.org: There may be work still being done in one of the branches.
[11:11] Kayaker.Magic @grid.kitely.com:8002: I found a way to reproduce a bug in llListen, submitted a new Mantis 8135
[11:12] James.atLLOUD @hg.osgrid.org: llListen has a bug? (lol)
[11:12] James.atLLOUD @hg.osgrid.org: marcus' favorite command.
[11:12] Marcus Llewellyn: Heh
[11:13] Kayaker.Magic @grid.kitely.com:8002: 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 @hg.osgrid.org: I use that alot too. And I'm sorry Marcus, it's the dialog windows that are your favorite.
[11:14] Andrew.Hellershanks @hg.osgrid.org: I use llListen often as I have gadgets needing input by users.
[11:14] Kayaker.Magic @grid.kitely.com:8002: 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 @hg.osgrid.org: Do you have > 720 temp rez items still rezzed when the llListen fails?
[11:15] Kayaker.Magic @grid.kitely.com:8002: I haven't done all combinations... A single script opening and removing listens forever doesn't have the problem.
[11:16] Kayaker.Magic @grid.kitely.com:8002: And it was not marked temp.
[11:16] Kayaker.Magic @grid.kitely.com:8002: But if I marked it temp, it would get deleted before the problem would appear...
[11:16] James.atLLOUD @hg.osgrid.org: do you ask about temp because this might be related to projectiles?
[11:17] Kayaker.Magic @grid.kitely.com:8002: Well, it was writing projectiles that I discovered a way to get the error to happen on demand.
[11:17] Kayaker.Magic @grid.kitely.com:8002: Then I simplified the code to try and make the minimum example for the mantis.
[11:18] Andrew.Hellershanks @hg.osgrid.org: If the items are not marked temp you can have > 720 and llListen still works?
[11:19] Kayaker.Magic @grid.kitely.com:8002: I can try that next I suppose.
[11:19] Kayaker.Magic @grid.kitely.com:8002: I usually try to police my own prims and call llDie, temp rez is just a backup.
[11:19] Andrew.Hellershanks @hg.osgrid.org: 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 @grid.kitely.com:8002: 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 @hg.osgrid.org: ok
[11:22] James.atLLOUD @hg.osgrid.org: interesting number 720. would have guessed a binary prime.
[11:22] Kayaker.Magic @grid.kitely.com:8002: It is an estimate.
[11:22] James.atLLOUD @hg.osgrid.org: ah
[11:23] Kayaker.Magic @grid.kitely.com:8002: I rez another every 0.5 seconds, and acording to my chat log it fails after 6 minutes.
[11:23] Kayaker.Magic @grid.kitely.com:8002: Curiously, it fails at about the same time in 0.9.1 and in 0.8.2
[11:24] Andrew.Hellershanks @hg.osgrid.org: 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 @hg.osgrid.org: right
[11:26] Andrew.Hellershanks @hg.osgrid.org: 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 @grid.kitely.com:8002: I'm logging into another account to try the test without temp rez objects.
[11:26] Andrew.Hellershanks @hg.osgrid.org: ok
[11:29] Kayaker.Magic @grid.kitely.com:8002: Test running, I'll report back in 6 minutes.
[11:31] Andrew.Hellershanks @hg.osgrid.org: I was hoping I could easily find the module handling the listens but I can't right now.
[11:34] Andrew.Hellershanks @hg.osgrid.org: I think I just found the relevant code in OpenSim/Region/CoreModules/Scripting/WorldComm/WorldCommModule.cs
[11:35] Andrew.Hellershanks @hg.osgrid.org: 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 @hg.osgrid.org grins at Marcus
[11:36] Kayaker.Magic @grid.kitely.com:8002: I've rarely seen llListen handles other than 1 in this test.
[11:36] Kayaker.Magic @grid.kitely.com:8002: and -1, of course
[11:36] Andrew.Hellershanks @hg.osgrid.org: There is no reference to "temp" in that file other than in relation to another llListen call.
[11:36] Andrew.Hellershanks @hg.osgrid.org: 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 @grid.kitely.com:8002: Are the numbers a separate series in each script? Or are they region wide resources?
[11:38] Andrew.Hellershanks @hg.osgrid.org: 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 @hg.osgrid.org: The comm module is non-shared.
[11:39] Kayaker.Magic @grid.kitely.com:8002: 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 @hg.osgrid.org: Hm... I see references to limits on the handles.
[11:39] Andrew.Hellershanks @hg.osgrid.org: Good practice.
[11:39] Kayaker.Magic @grid.kitely.com:8002: Yes, there is a maximum you can have open at once.
[11:40] Andrew.Hellershanks @hg.osgrid.org: Ah. The limits are set in the ini file.
[11:40] Kayaker.Magic @grid.kitely.com:8002: 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 @hg.osgrid.org: In LL-Function max_listens_per_region sets the maximum number of listens.
[11:41] Andrew.Hellershanks @hg.osgrid.org: max_listens_per_script sets the maximum number of listen handles.
[11:41] Kayaker.Magic @grid.kitely.com:8002: Results of the test: Even rezzing objects that were NOT temp-rez, the test failed after the same ~6 minutes.
[11:41] Andrew.Hellershanks @hg.osgrid.org: If only one listener is rezzed you should not be running up against those limits.
[11:42] Kayaker.Magic @grid.kitely.com:8002: 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 @grid.kitely.com:8002: 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 @grid.kitely.com:8002: 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 @grid.kitely.com:8002: 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 @grid.kitely.com:8002: 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 @grid.kitely.com:8002: 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 @grid.kitely.com:8002: 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 @grid.kitely.com:8002: 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 @grid.kitely.com:8002: 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 @grid.kitely.com:8002: 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 @grid.kitely.com:8002: in particular, script perms may not change.
[12:05] James atLLOUD: I've run into that I think @selby
[12:05] Selby.Evans @grid.kitely.com:8002: 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 @grid.kitely.com:8002: 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 @grid.kitely.com:8002: (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 @grid.kitely.com:8002: 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 @grid.kitely.com:8002: 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.