User:Ama Omega/archive/Office Hours/2010-10-04

From Second Life Wiki
Jump to navigation Jump to search

List of Attendees

Transcript

[08:53] The region you have entered is running a different simulator version: Second Life RC BlueSteel 10.09.27.210805
[08:53]
[08:53] ANSI Soderstrom has entered chat range (3.5m)
[08:53] ANSI Soderstrom: hi
[08:54] Kopilo Hallard: hey
[08:55] Pauline Darkfury has entered chat range (2.0m)
[08:56] ANSI Soderstrom: hi
[08:56] Haravikk Mistral has entered chat range (6.2m)
[08:56] Kopilo Hallard: heya
[08:56] Pauline Darkfury: hi folks :)
[08:57] Twisted Laws has entered chat range (6.2m)
[08:57] Kopilo Hallard: hmm
[08:57] Kelly Linden has entered chat range (19.4m)
[08:57] ANSI Soderstrom: hm
[08:57] Kopilo Hallard: yay
[08:57] Daniel Voyager has entered chat range (17.4m)
[08:58] Haravikk Mistral: Bah, just realise I've wasted most of a day trying to get Squid cache to work with SL heh
[08:58] Kopilo Hallard: x.x
[08:59] Daniel Voyager: hey Kelly :)
[08:59] Kelly Linden: hello :)
[08:59] Kopilo Hallard: greetings
[08:59] Haravikk Mistral: And you know the problem? I forgot to enable a single option when I installed it, *facepalms*
[08:59] ANSI Soderstrom: huhu
[08:59] Twisted Laws: hello
[08:59] Pauline Darkfury: Not certain, but I think there was a SVC Jira on the texture not being HTTP cache-friendly at the client end, and I think it was a "Won't fix", as that's not intended to work at present
[09:00] Pauline Darkfury: You can probably hack it though ;)
[09:00] Haravikk Mistral: Is what I've been trying to do, helps if I installed it properly in the first place I think hehe, I think I got everything else working okay
[09:01] Kelly Linden: Sorry for missing last week.
[09:01] Kelly Linden: How is everyone doing?
[09:01] ANSI Soderstrom: as usual
[09:01] Kopilo Hallard: I hate xorbase64 other than that good
[09:01] Pauline Darkfury: well, my sim has stopped flatlining at 0.00 dilation for extended periods, so happier now ;)
[09:01] Kopilo Hallard: ^.^
[09:01] Qie Niangao has entered chat range (6.9m)
[09:01] Twisted Laws: doing good, wishing they'd fix loading big scripts in viewer 2 tho
[09:01] Kelly Linden: yay Pauline
[09:02] Kelly Linden: Twisted: the performance issue? Or the highlighting issue?
[09:02] Twisted Laws: both :p but performance is worst
[09:02] Haravikk Mistral: Are you still planning to swap this office hour for a bug triage type session?
[09:02] lufpleh Obstreperous has entered chat range (19.7m)
[09:03] Kelly Linden: Lets do that next week.
[09:03] Kelly Linden: Then I will alternate weeks
[09:03] Haravikk Mistral: k, is just that I noticed all the other bug triages seem to have died, don't suppose you know if there are plans to ressurrect the viewer one?
[09:03] Nexii Malthus has entered chat range (6.9m)
[09:03] Kelly Linden: I don't know how Oz and Q are handling bug triage or how they plan on handling it.
[09:04] Kopilo Hallard: are there any movements on improving the embedded scripting engine (lsl or similar)?
[09:05] Kelly Linden: I'm not quite sure what you mean Kopilo. We are upgrading the version of mono we use and implementing a bunch of fixes for performance and bugs around loading mono scripts.
[09:05] Kelly Linden: Those fixes are going into QA this week
[09:05] Kelly Linden: (finally)
[09:06] Kopilo Hallard: ^.^
[09:06] Pauline Darkfury: how confident do you feel that this will finally nail most/all of the sim freeze on TP in/out?
[09:06] Kelly Linden: It will nail some
[09:06] Haravikk Mistral: Yay! Will that be under a particular channel?
[09:06] Kelly Linden: I dunno haravikk, need to get it past some internal QA first. :)
[09:07] Kelly Linden: It should nail most of the difference between an avatar with 100 mono scripts and an avatar with 11 lsl scripts.
[09:07] Kelly Linden: err 100 lsl scripts
[09:07] Pauline Darkfury: cool
[09:08] Pauline Darkfury: will this make the entire AV in/out sequence multi-threaded?
[09:08] Kelly Linden: I'll spam twitter and beta mailing list and IRC when there is a publicly accessible beta to try.
[09:08] Kelly Linden: Pauline: That was not part of this work. However there has been a lot of work in that direction.
[09:08] Pauline Darkfury: Yup, I know Andrew has been looking at that
[09:09] Kelly Linden: I think actually Simon has been looking at it.
[09:09] Tuft Meili has entered chat range (6.9m)
[09:09] Kelly Linden: Andrew has been looking at making linkability checks faster.
[09:09] Pauline Darkfury: Yes, could be Simon
[09:09] Pauline Darkfury: one of them certainly has
[09:09] Nexii Malthus: :<
[09:10] ANSI Soderstrom: yaay
[09:10] Kelly Linden: performance on region crossing and TP has been a focus of the last sprint or two for our team. Looking forward to seeing those improvements released.
[09:11] Haravikk Mistral: Sweet, um, I have one JIRA issue I wanted to raise this week, SVC-6374 (I think), is /technically/ a regression though it was something changed a while ago
[09:11] Pauline Darkfury: yup, an awful lot of people with fun scripted attachments have been looking forward to some light at the end of the tunnel
[09:11] Nexii Malthus: o/
[09:12] ANSI Soderstrom: SVC-6374 ?
[09:12] ANSI Jira Helper: 
http://jira.secondlife.com/browse/svc-6374
[09:12] Tuft Meili: It will be nice to be able to put mono scripts in attachments again ;)
[09:12] Haravikk Mistral: Basically is that llGetInventoryKey() no longer returns a key for animations you don't have full-perms to. I know this was changed ages ago, but it's really awkward for comparing inventory against llGetAnimationList()
[09:12] Twisted Laws: i've found region crossing are much better than 6 months ago... riding a scripted train thru the mainland.
[09:12] Haravikk Mistral: It's possible to work around it though, so I was hoping it could just return the correct key again
[09:12] Kelly Linden: That seems pretty intentional
[09:13] Haravikk Mistral: For scripts and objects sure, the thing is that animations are already controlled since llStartAnimation() won't accept animation keys
[09:13] Kelly Linden: I think there is concern about what other viewers may do with full keys
[09:13] Haravikk Mistral: And you can lift the key out of a call to llGetAnimationList() anyway if you know what you're looking for, or recently triggered it
[09:13] Aeron Constantine has entered chat range (6.5m)
[09:14] Kopilo Hallard: not all animations in the animationlist can be in inventory either
[09:14] Nexii Malthus: Yeah, llGetAnimationsList is significantly more of a concern if that is the case, so it does look like a regression than intention
[09:14] Pauline Darkfury: Some viewers present a list of all currently active anim keys anyway
[09:14] Kopilo Hallard: it would be better if it returned the name of the animation if possible
[09:14] Nexii Malthus: Not to mention, you can get animation keys in the virgin LL client
[09:15] Nexii Malthus: Characher >> Animation Info
[09:15] Haravikk Mistral: I'm not sure that'd be feasible for llGetAnimationList() Kopilo, I'd love if it was though as it'd work even better for what I need =)
[09:15] Kelly Linden: wow nexii that sucking sound is really annoying
[09:15] Kopilo Hallard: internally there isn't a converter yet
[09:15] Kelly Linden: erm, ANSI sorry
[09:15] Nexii Malthus: That's not me
[09:16] ANSI Soderstrom: hm ?
[09:16] Nexii Malthus: Your pacifier
[09:16] ANSI Soderstrom: :)
[09:16] ANSI Soderstrom: yes, from maggie simpson
[09:16] ANSI Soderstrom: cute, not ?
[09:16] Kelly Linden: not after the first minute. :p
[09:16] Qie Niangao: hmmm... interesting. in 2.2 at least, Develop / Avatar / Animation Info nulls-out the animation key
[09:17] ANSI Soderstrom shouts: better ?
[09:17] Kelly Linden: I think that llGetInventoryKey returning null_key for any inventory that isn't full perm is a more consistent behavior since that is just what it does for all inventory
[09:17] Nexii Malthus: True
[09:18] Click the seat to change your animation or position.
[09:18] ANSI Soderstrom: dont right click me
[09:18] ANSI Soderstrom: its tickling bad
[09:18] Haravikk Mistral: it returns hashes for scripts and notecards though to remain useful in those cases
[09:18] Nexii Malthus: Could a hash be used for llStopAnimation then in that case?
[09:18] Nexii Malthus: Return a hash that is usable
[09:18] Nexii Malthus: A capability of sorts
[09:19] Nexii Malthus: Seems like a good middleground to me
[09:19] Kopilo Hallard: something like the name of the animation? :p
[09:19] Haravikk Mistral: Well you don't need it since you can use the inventory name anyway
[09:19] Kopilo Hallard: unless it is not in your inventory?
[09:19] Haravikk Mistral: I'm hoping for the key since I want to look at the results of llGetAnimationList() to check an avatar is running the anims I expect them to be
[09:19] Nexii Malthus: It would be backwards compatible this way though as well
[09:19] Kopilo Hallard: true
[09:19] Kopilo Hallard: maybe
[09:20] Kopilo Hallard: llAKey2name? :p
[09:20] Haravikk Mistral: There's no reason really to NOT return the key since a hacked viewer can tell you all the UUIDs anyway, and it's no sensitive in the same way as a script which might contain security tokens etc.
[09:21] Nexii Malthus: What is the concern how the UUID can be used Kelly?
[09:21] Twisted Laws: sorry to run, but rl calls me :( see ya all laters
[09:21] Kopilo Hallard: see you
[09:21] Nexii Malthus: Is it just paranoia or an actual security vulnerability?
[09:21] Haravikk Mistral: They're of little use to a script, and llGetAnimationList() would be way better if you wanted to harvest animation keys since you can use it on any avatar you're near
[09:23] Tuft Meili: Concern that you might *play the animation without owning through the UUID somehow?
[09:23] Kelly Linden: The viewer needs only keys to play animations, so getting the key is the same as getting the full perm animation.
[09:23] Kelly Linden: Maybe we should fix llGetAnimationList to not return UUIDs for non-full-perm animations.
[09:23] Haravikk Mistral: Isn't that impossible?
[09:24] Pauline Darkfury: Well, how can llGetAnimationList tell if it's full perm or not?
[09:24] Kelly Linden: Nothing is impossible.
[09:24] Haravikk Mistral: A UUID doesn't have permissions, only inventory entries do don't they?
[09:24] Kopilo Hallard: that assumes full perm scripts are given by a creator to be uses in anything :p
[09:24] Aeron Constantine: a UUID has perms?
[09:24] Pauline Darkfury: Someone may have full perm in their object playing on them, but not be licensed to pass it on full perm
[09:24] Kopilo Hallard: perms are not license
[09:24] Kelly Linden: We could track when the UUID is triggered the permissions associated with it.
[09:24] Nexii Malthus: To show the animatioon of other uses, the viewer has to download the animation via the UUID
[09:25] Haravikk Mistral: But that's just the thing; does a UUID have such information? I thought only inventory entries did?
[09:25] Nexii Malthus: Anything that can be rendered has to be downloaded and streamed somehow, and that is where the man in the middle can attack to steal content, it's how it works
[09:25] Kelly Linden: A uuid by itself does not.
[09:25] Haravikk Mistral: Oh you mean the inventory item used by llStartAnimation?
[09:26] Kelly Linden: right
[09:26] Kopilo Hallard: ^.^
[09:26] Qie Niangao: oy. client-side AOs
[09:26] Tuft Meili: There will be real need for something that lists the names of playing animations if llGetAnimationList is "nerfed".
[09:26] Nexii Malthus: So, yeah, you can use a rogue viewer to steal animations via the UUID, but it seems like paranoia driven effort to put roadblocks
[09:26] Haravikk Mistral: Hmm, still, if you change the output of llGetAnimationList() then that breaks content, as some scripts use it to stop all animations (in order to avoid conflicts)
[09:26] Pauline Darkfury: The thing is, surely it's pointless restricting yet more of LSL when that restriction is not necessary for a standard viewer. A non-standard viewer can just get the key anyway, so if someone was to hack a viewer to use by UUID alone, they can just hack it to steal the UUID in the first place
[09:27] Kelly Linden: internally the animation system is complex, tacking on a few bits for perms wouldn't be too bad. "clientside AOs" or anything that triggered AOs just by UUID would be treated as full perm.
[09:27] Nexii Malthus: Exactly, it's just limiting our freedom Pauline
[09:27] Kopilo Hallard: restricting it on perms is going to make animation creators lose money >.>
[09:27] Kopilo Hallard: maybe
[09:27] Kopilo Hallard: how much content would that break?
[09:27] Kelly Linden: how kopilo?
[09:27] Kopilo Hallard: because a lot of animations are sold no transfer
[09:27] Haravikk Mistral: And I'm trying to use it to check that an avatar is in a desired state, there are plenty of legitimate uses for llGetAnimationList() as-is
[09:28] Kopilo Hallard: or no modify
[09:28] Kopilo Hallard: if something has to be full perm to play the animaiton
[09:28] Haravikk Mistral: I don't think UUID security paranoia should cripple functionality, I want the opposite with llGetInventoryKey() returning a useful value again =P
[09:28] Kelly Linden: I didn't say it had to be full perm to play
[09:28] Kopilo Hallard: ahh
[09:28] Haravikk Mistral: Especially when it'd still be trivial to steal animation UUIDs by hacking your viewer
[09:28] Tuft Meili wishes for more animation priority settings... :)
[09:28] Kopilo Hallard: xD
[09:29] Kelly Linden: Tuft: then everyone would just make new animations at (max_priority)
[09:29] Nexii Malthus: Not true
[09:29] Haravikk Mistral: Not necessarily true, I upload anims with different priorities so I can preload them =)
[09:29] Nexii Malthus: The problem is the standard animations are using valuable priority space
[09:29] Nexii Malthus: standard linden animations*
[09:29] Tuft Meili: True, Nexii
[09:29] Kelly Linden: Maybe we could just switch the priority number to a float.
[09:30] Nexii Malthus: A lot of UCG has to use higher priority to circumvent the static linden assets' priorities
[09:30] Kopilo Hallard: a float would be awesome
[09:30] Haravikk Mistral: Or give scripts the ability to specify priority?
[09:30] Kelly Linden: Then you could set your animations to have a priority of PI
[09:30] Nexii Malthus: And why are priorities not dynamically script-driven instead of specified at upload?
[09:30] Pauline Darkfury: Maybe a llStartAnimPriority(anim,priority)?
[09:30] ANSI Soderstrom: LL can stat a database, and all buyers of a animation go into the database with the animation. and the animation goes not as object in the inventory, only viewable as a list
[09:30] Nexii Malthus: They should be LSL driven
[09:30] Kopilo Hallard: giving the scripts ability to set piority would be sweet as
[09:30] Kelly Linden: because they are part of the asset
[09:30] Nexii Malthus: The base priority should be dynamic I mean*
[09:31] Kelly Linden: that is a significant animation system redesign well beyond the scope of LSL.
[09:31] Nexii Malthus: The per-joint priority is added/subtracted as necessary
[09:31] ANSI Soderstrom: so everyone can see the uuid, but cant use that
[09:31] ANSI Soderstrom: thats the idea aof server sided security
[09:31] Pauline Darkfury: Well, at the moment, people can't use the UUID anyway? And it's easy to get the UUID using standard approved viewers
[09:31] ANSI Soderstrom: tons of databases
[09:31] Kopilo Hallard: authentication*
[09:32] Nexii Malthus: Sorry for going off the tangent there >_>
[09:32] Haravikk Mistral: In any event, please consider SVC-6374, as it is, there's no reason to cripple llGetAnimationList() instead as that would remove even more functionality for the sake of a potential exploit that exists in other forms
[09:32] flexi campfire: https://jira.secondlife.com/browse/svc-6374,
[09:33] Tuft Meili: There are a few tricks you can use to crowd out a running prio-4 animation with your own prio-4, but that uses a lot of script time...
[09:33] ANSI Soderstrom: llGetInventoryKey eturns bad uuids for textues too
[09:33] ANSI Soderstrom: sorry, my "r" key is boken
[09:33] Haravikk Mistral: Ah but textures UUIDs can be used by scripts
[09:33] Pauline Darkfury: Textures are a stickier issue
[09:33] Nexii Malthus: ANSI: That's intentional
[09:33] Haravikk Mistral: Animations can't
[09:33] Pauline Darkfury: Texture UUID approximately equals full perms on it
[09:33] Nexii Malthus: Since you can llSetTexture with the key
[09:34] Kopilo Hallard: lawl
[09:34] Haravikk Mistral: Animation UUID's are useless to a script except for stopping an animation, or inspecting running anims. Textures have llSetTexture, same as sounds UUIDs can be used in scripts =(
[09:34] Kopilo Hallard: don't look in your texture cache then :p
[09:34] Pauline Darkfury: That does neatly raise a point. I'd like to mention SVC-3199
[09:34] flexi campfire: https://jira.secondlife.com/browse/svc-3199
[09:34] Kelly Linden: Haravikk: All right. So, that is not a regression. It was an intentionall and deliberate change to llGetInventoryKey. Making an exception for animations would be a new feature.
[09:35] Pauline Darkfury: Right now, if we want to use commercial textures and change them on mod prims, we have to use a script per prim
[09:35] Kopilo Hallard: >.>
[09:35] Kelly Linden: I'm gonna sideline Pauline here because I want to setup how we can do a script triage.
[09:35] Haravikk Mistral: It's kind of on the line really, as it's a regression for animations which didn't need to be nulled
[09:36] Kelly Linden: Since I didn't plan on doing it this week - I want it to be a little more organized than spur of the moment.
[09:36] Pauline Darkfury: If we set the texture by UUID from a script, there are no asset perms consequences for the prim it goes onto, so a simple texture change across multiple prims in a mod object can be used to obtain the key unless you check the creator
[09:36] Nexii Malthus: non-fullperm commercial textures? … sounds so useless o.o
[09:36] Nexii Malthus: it's like when attachments used to be sold no-mod back in the days
[09:36] Pauline Darkfury: I'm talking about distributing a mod object with texture change, Nexii. I.e. non-fullperm to the customer
[09:37] Kelly Linden: I'm still trying to beat new-jira into submission. For now I'm gonna just work around it and use a wiki page for managing my triage.
[09:37] Kelly Linden: I'll update people when I change that.
[09:37] Kopilo Hallard: lol
[09:37] Kelly Linden: for now: https://wiki.secondlife.com/wiki/User:Kelly_Linden/script_jira_triage
[09:37] Haravikk Mistral: Will need new JIRA queries, as none of the existing bug triage ones seem to work
[09:37] Kelly Linden: yeah
[09:38] Kelly Linden: I'm going to fill out the details section with more info about what I hope to get from a triage, and some caveats that this doesn't mean I'm going to be able to suddenly fix more scripting issues.
[09:39] Haravikk Mistral: And are the triages just for bugs or are new features included as well so they can be organised?
[09:39] Kelly Linden: (I wish it did)
[09:39] Kelly Linden: New features are fine. My primary goal is going to be to clean up the scripting jiras to some extent.
[09:40] Kopilo Hallard: note a lot of them are still closed from server 1.4
[09:40] Kelly Linden: I'd like to be able to clearly indicate issues that are either very unlikely to happen, or just not going to happen any time soon.
[09:40] Kelly Linden: 1.4?
[09:40] Kopilo Hallard: server
[09:40] Kopilo Hallard: ancient
[09:40] Kelly Linden: 1.4 was about 6 years ago?
[09:40] Kopilo Hallard: a lot of the jiras got closed and never reopened
[09:41] Pauline Darkfury: you mean 1.40, Kopillo?
[09:41] Kelly Linden: We didn't have jira with 1.4
[09:41] Kopilo Hallard: yet the problems are still creeping up today
[09:41] Kopilo Hallard: yeah 1.40 sue linden iirc closed them
[09:41] Kopilo Hallard shrugs or was it 2.40... something ancient
[09:41] Kelly Linden: If you have an issue that you think needs to be reopened, we can discuss it at the triage.
[09:41] ANSI Soderstrom: new feature -> https://wiki.secondlife.com/wiki/LlEval
[09:41] Pauline Darkfury: Yup, a lot of issues did get bulk closed in June without being fully considered, being able to raise them again would be useful
[09:42] Kelly Linden: And to emphasize - *scripting jiras*. :)
[09:42] Pauline Darkfury: correction, in July
[09:42] Kelly Linden: ok, not quite ancient.
[09:42] Kelly Linden: Any questions or suggestions about the triage?
[09:43] Aeron Constantine: Rollbacks/Sim Reboots causing duplicate content? :)
[09:43] Kopilo Hallard: should we only list topics if we can make the meeting?
[09:43] Kelly Linden: That isn't about the triage
[09:43] Kelly Linden: It is most helpful, but if you don't mind us deciding something without you then that is fine.
[09:44] Kopilo Hallard: thanks, 3am here that's why I asked
[09:44] Kelly Linden: Depending on how this goes we may not get to all the issues suggested or we may have 45 minutes left over.
[09:44] Kelly Linden: I reserve the right to adjust the process on whim. :)
[09:44] Kopilo Hallard: will you log those changes though?
[09:44] Kopilo Hallard: or the meeting?
[09:45] Kelly Linden: I will fill in the 'triaged date' field on the jiras and comment, and my OH transcripts are here https://wiki.secondlife.com/wiki/User:Kelly_Linden #Office_Hours
[09:46] Kopilo Hallard: ^.^
[09:49] Aeron Constantine: another one bites the dust
[09:49] Kopilo Hallard: seems lindens have the same problems as normal users
[09:49] Pauline Darkfury: heh
[09:49] Aeron Constantine: certainly not ;)
[09:49] Pauline Darkfury: well, they use the same viewers as us
[09:50] Kopilo Hallard: not all of us ;)
[09:50] Nexii Malthus: half of us I'd say
[09:50] Pauline Darkfury: well, Phoenix is just LL SG 1.5 with a bunch of handy features added
[09:50] Nexii Malthus: or even less, since this is inevitably geek populated office hour
[09:51] Pauline Darkfury: as are most of the TPVs in common use (graphical ones, anyway)
[09:51] Nexii Malthus: Lindens have to use the 2.x viewers tho
[09:52] ANSI Soderstrom: "hi kelly, the system is tying to logging you out., please try to relog at 9:56PDT"
[09:52] Kopilo Hallard: lol
[09:52] Pauline Darkfury: lol
[09:52] Nexii Malthus: lol
[09:52] Aeron Constantine: haha
[09:53] Pauline Darkfury: Andrew & Simon have been working on the ghosting issues, so hopefully that should be better / getting better
[09:53] Nexii Malthus: Are there people that actually wait 5 minutes? I always try to login a few seconds after a crash
[09:53] ANSI Soderstrom: better ghosts ?
[09:53] Kopilo Hallard: they are more than white sheets over a rake
[09:53] ANSI Soderstrom: :)
[09:53] Qie Niangao: Nexii: sometimes it's fussy... and it's been fussier more often, lately.
[09:53] Pauline Darkfury: lol
[09:54] Haravikk Mistral: Yeah, I don't have that message come up much anymore (normally I can immediately re-log), but when it does come up I usually have to wait till the actual time it gives =(
[09:54] ANSI Soderstrom: if i get a "wait for relog" message i try 2 times within 10 seconds to log in and then works
[09:54] Nexii Malthus: Having your own client is kinda nice, being able to run a debugger and fix your own crashers :3
[09:54] Haravikk Mistral: Though I don't crash much at all under viewer 2.0, is normally my own fault when I do
[09:54] Pauline Darkfury: The 5 minutes really depends what happens when you crash. Personally, I find I can normally login again within about 30s, just rarely it gets pushed to the 5 minutes
[09:55] Kelly Linden has entered chat range (9.6m)
[09:55] Kopilo Hallard: welcome back
[09:55] ANSI Soderstrom: hey, w b
[09:55] Aeron Constantine: welcome back
[09:55] Nexii Malthus: wb
[09:55] ANSI Soderstrom: 5 minutes are over
[09:55] Pauline Darkfury: wb
[09:55] Aeron Constantine: 5 minutes to spare - impressive
[09:55] Kopilo Hallard: lol
[09:55] ANSI Soderstrom: you are quick
[09:55] Kelly Linden: sorry about that, coworker's build somehow caused incredibuild on my machien to completely spaz and hose my computer
[09:56] Nexii Malthus: lol
[09:56] Aeron Constantine: good times
[09:56] Kelly Linden: 2x 500mb build process and another 200mb and everything nearly unresponsive
[09:56] Nexii Malthus: Owch
[09:56] Pauline Darkfury: evil
[09:56] Nexii Malthus: Wait, so your using each others' computers as a build farm?
[09:56] Kelly Linden: yeah
[09:56] ANSI Soderstrom: lol
[09:57] Click the seat to change your animation or position.
[09:57] Kelly Linden: usually it works without issue and you never notice.
[09:57] Nexii Malthus: Seems silly and unproductive
[09:57] Nexii Malthus: Building is an expensive operation
[09:57] Pauline Darkfury: grid computing like that has been a big thing in some tech offices for quite a few years now
[09:57] Kelly Linden: it is usually nice'd to hell and only runs if your computer is more or less idle
[09:57] Nexii Malthus: Ah
[09:58] Kelly Linden: It cuts a full build down to ~5 minutes.
[09:58] Edwardo Keng has entered chat range (5.8m)
[09:58] Nexii Malthus: nice
[09:58] Kelly Linden: and *usually* it doesn't do this. In fact this is the first time it has for me.
[09:59] Haravikk Mistral: Oh, I just wanted to query the current "roadmap" for scripting at the moment, I take it the current focus is script limits + efficient scripts with C# in the distant future, this being after the Mono speed improvements?
[10:00] Kelly Linden: Mono speed improvements are done. Efficient scripts main project is done, with just "as time permits" remaining
[10:00] ANSI Soderstrom: scipt limits .... :(
[10:00] Pauline Darkfury: small and efficient scripts ahead of limits, I'd hope
[10:00] Kelly Linden: Script limits are a hot topic, but I'm going to push for "little scripts" first, which I was actually hoping to discuss today.
[10:00] Qie Niangao: I was trying to think about how scripts use memory on the sim, and realized I'm utterly clueless. If a script doesn't do anything, can it be swapped to disk cleanly, or will it try to swap back to memory every scheduler frame?
[10:01] Kopilo Hallard: nproc...
[10:01] Kopilo Hallard: nmem
[10:01] Pauline Darkfury: Are you aware of the new "simconsole" project, Kelly?
[10:01] Kelly Linden: It depends a lot on what 'doesn't do anything' means
[10:01] Kopilo Hallard: >.>
[10:01] ANSI Soderstrom: with script limits are shit. nebwies dont build one big mistake, they producing then 20 little crap scripts
[10:01] Kelly Linden: Pauline: I am.
[10:01] Aeron Constantine: script limits would be nice but so would script memory allowances - we have scripts coredump that I feel we could prevent with being able to access a bit more memory if needed
[10:01] Nexii Malthus: It's moved from concept to project now?
[10:01] Rockhound Helstein has entered chat range (5.8m)
[10:02] Kelly Linden: Aeron: Really we need them in this order: little scripts, script limits, big scripts.
[10:02] Pauline Darkfury: In terms of script limits, before they hit, it would be very useful if we could get some real memory info for individual scripts through that, maybe even per-script times as well
[10:02] Kelly Linden: What has nexii?
[10:02] Nexii Malthus: The sim console idea
[10:02] Pauline Darkfury: Andrew, Simon, and Falcon have simconsole in beta, I believe
[10:02] Kelly Linden: Yes, that is nearly a product as far as I understand it.
[10:02] Kopilo Hallard: ^.^
[10:03] Nexii Malthus: incredible, it'll be absolutely useful and should have been there for a long time
[10:03] Tuft Meili: got to go - take care all! *waves*
[10:03] Kelly Linden: So, for "little scripts" it has been discussed as something that could be set at run time, but I'd like to toss out the idea that it be a pre-compile option.
[10:03] Aeron Constantine: yeah Andrew talked about it during his hours
[10:04] Aeron Constantine: (simconsole)
[10:04] Haravikk Mistral: Sorry I seem to have missed what you mean by "little scripts"?
[10:04] Nexii Malthus: Hmm, but then the problem is how scripts can monitor memory usage, or rather 'know' at all, won't the user be paranoid and set it high "in case"?
[10:04] Pauline Darkfury: Well, as someone with an awful lot of scripted objects, some of which are in no-mod prims, some of which the script creator is no longer active in SL, it would be lovely if there was some way we could mitigate the 16/64kB hit if we can't get an update
[10:05] Qie Niangao: (fwiw, I mean like a resize script that's waiting on touch or link-message... if no such event triggers, I'm wondering if the script needs to be loaded in the resident set.)
[10:05] Haravikk Mistral: Could scripts get functions llRequestMemory()? So they could expand memory, and an event if SL wants a script to reduce memory?
[10:05] Nexii Malthus: Resizer scripts issue been tackled already using llSPPF
[10:05] Kelly Linden: Scripts that you can't modify are going to be stuck at the current usage regardless of whether it is a runtime option or precompile.
[10:05] Nexii Malthus: But yes, generally the whole problem of many small multiple scripts
[10:05] Pauline Darkfury: Mmm, sadly there are an awful lot of creators who have been slow to jump on llSLPPF
[10:06] Kelly Linden: Haravikk: that was essentially the previous / current design.
[10:06] Pauline Darkfury: and lots of people who have existing no-mod products without a delete option :(
[10:06] Nexii Malthus: Pauline, that'll always be the case with progressive features
[10:06] Nexii Malthus: Same going to be with meshies for a year or so
[10:06] Kelly Linden: The script limits feature will put pressure on people to upgrade to better designed content that takes advantage of the new features.
[10:07] Haravikk Mistral: Well if SL can calculate an object's memory requirements before it starts executing the scripts things should be fine hopefully, then if memory gets tight it could pause the scripts and then page them to disk
[10:07] Kelly Linden: "little scripts" is the functionality that would allow scripts compiled to mono to set a lower reserved memory size than 64k
[10:07] ANSI Soderstrom: what about region-script limits ?
[10:07] Pauline Darkfury: Well, if the choice is to bin an existing item or take a risk and set the memory lower, but understand it might stack/heap, I'd gladly take the stack/heap chance if I don't lose content I've already paid for and can't get an update for
[10:07] Kelly Linden: ansi: that is script limits, so what about it.
[10:07] ANSI Soderstrom: i heard something about 512sqm pacel : max 30 scripts
[10:08] Kopilo Hallard: x.x
[10:08] Haravikk Mistral: Ah, hmm, I think run-time is preferable, or are you talking about something that would be available sooner, with runtime memory requests later?
[10:08] Kelly Linden: The current design focuses on memory, not script number, which is why I think implementing 'little scripts' first is important
[10:08] Qie Niangao: (In my paging question, I'm not talking about "efficient scripts", I'm wondering about the script memory limits, and whether we'll get the bang we expect from them, if 90% of all scripts are already happily swapped to disk with no performance impact)
[10:08] ANSI Soderstrom: ok
[10:08] Kopilo Hallard: as I understand it, Kelly was saying script memory was more of an issue than script processors?
[10:08] Kopilo Hallard: a few weeks ago
[10:09] Kelly Linden: preprocessor gives a more stable experience to end users who will know when they buy a product what the script cost is.
[10:10] Kelly Linden: rather than buying a product that only uses 4k now but balloons to 200k once they rez it.
[10:10] Haravikk Mistral: Ah good point!
[10:10] Pauline Darkfury: That creates a different type of problem though
[10:10] Aeron Constantine: Pauline, you could lose the content though - we have no mod (ie: no reset) objects that coredump depending on which region they are on
[10:10] Kelly Linden: I think that makes it simpler to understand and use, but it is definitely less powerful than beign set at runtime
[10:10] Haravikk Mistral: So you'd specify the maximum you need, but could runtime stuff still then be used to reduce memory so you can keep running?
[10:11] Pauline Darkfury: Say we want to create a visitor logger which is configurable in terms of the number of people it remembers. Being able to set the memory dynamically allows a single product which can be tuned by the end user
[10:11] Kelly Linden: Haravikk, there is a lot of wiggle room in a design like that.
[10:11] Pauline Darkfury: I'll gladly take the chance of a no-mod becoming broken through stack/heap if I choose too low a value for it, that's preferrable to the object becoming no-rez
[10:11] Kelly Linden: Pauline: right.
[10:12] Haravikk Mistral: It's just that I'd like to be able to play with extra memory if it's available, but then make my scripts play good citizen when they have to, e.g - with caching of remote data
[10:14] Kopilo Hallard: x.x
[10:14] Kelly Linden: Right that seems reasonable too.
[10:14] ANSI Soderstrom: i will be rich weith precompiled noScriptLimit Prims
[10:15] Haravikk Mistral: That way I could make an object with max 20kb memory usage, but still advertise a minimum usage of 6kb for example, so it can grow if there's room to speed itself up, or shrink to play nice
[10:15] Kelly Linden: There will be no such thing as a "no script limit" prim
[10:15] ANSI Soderstrom: damn
[10:16] Haravikk Mistral: What is the planned behaviour for if the memory limit is reached then and a script is unable to reduce its memory?
[10:16] Kelly Linden: Old scripts will be stuck as counting as 64k (for mono, 16k for LSL)
[10:16] Haravikk Mistral: Will the entire object pause? I think that'd be preferable
[10:16] Kopilo Hallard: script error: script is out of memory?
[10:16] Pauline Darkfury: One specific concern I have is the ability for link messages to cause a stack/heap. What are the chances of adding say a llLinkMessageLimit, so that we can have small scripts co-existing with other things which might need larger link messages than we want to allow free memory for per small script?
[10:17] Kelly Linden: I've been working toward a design that does not require scripts that are already running to try and reduce their memory usage. If a script is running it should be able to continue to do so, though it may not be able to request more memory
[10:17] ANSI Soderstrom: what about reading notecards
[10:17] ANSI Soderstrom: i need much memory to read a notecard
[10:18] Kelly Linden: That is an interesting idea Pauline, but I don't have anything in mind for that
[10:18] Nexii Malthus: ooh, link messages is an interesting question
[10:18] Haravikk Mistral: Hmm, I think it'd still be nice if scripts can be informed when memory is tight, so they know when to do something about it without having to poll or something like that?
[10:18] ANSI Soderstrom: but after reading i dont need much memory
[10:18] Kelly Linden: You will need to make sure you have requested enough memory to handle what you will be trying to do.
[10:18] Kopilo Hallard: hmm thought: buffer memory for scripts so they slow down rather then stop all together?
[10:18] Nexii Malthus: Along the same lines of Pauline, what about our ability to send data with llHTTPRequest being only restricted by script memory?
[10:19] Aeron Constantine: well you need a buffer regardless - our product works fine some places but on sims where it has to work hard can dump
[10:19] ANSI Soderstrom: 99% done, wait 100minutes because the scipt is slowed down ?
[10:19] Kopilo Hallard: better than 99% done, crash
[10:19] ANSI Soderstrom: lol
[10:19] Kelly Linden: All right, I think I have covered the time lost to my computer issues. I need to head out now. I'll set up a page for people to add topics for future office hours as well.
[10:20] Pauline Darkfury: The problem for me with link messages is selling plugin scripts which end up coexisting with unknown other scripts, and are controlled by link message. I can easily figure out the worst case for the link messages I expect to receive, but can't account for what other scripts might need to use themselves
[10:20] Qie Niangao: thanks Kelly
[10:20] Nexii Malthus: thx Kelly for hanging a bit longer around
[10:20] Haravikk Mistral: Does a link_message() event trigger a crash if the message to big immediately, or only when you try to parse the message? If the latter then you can filter messages using the integer data first, and build an object so that unfiltered messages should be sent only by scripts that restrict the size of the message accordingly?
[10:20] Aeron Constantine: thanks Kelly
[10:20] Pauline Darkfury: thanks, Kelly :)
[10:20] Aeron Constantine: yes Kopilo - I agree - but we would still need to be able to detect it has gone into tht mode
[10:20] ANSI Soderstrom: cu kelly
[10:20] ANSI Soderstrom: if u want a pacifer,tell me :)
[10:20] Pauline Darkfury: The link_message event causes a stack/heap if there's insufficient memory for the incoming message
[10:20] Kopilo Hallard: totally Aeron
[10:20] Pauline Darkfury: and messages are unlimited in size
[10:20] Kelly Linden: geeze. Can someone email me the chat log?
[10:21] Kelly Linden: kelly@lindenlab.com
[10:21] Kopilo Hallard: see you kelly
[10:21] Kopilo Hallard: ^.^
[10:21] Kelly Linden: I lost half of it.
[10:21] Haravikk Mistral: Hmm, that's odd, as I thought that the message existed in run-time memory and was only copied if you tried to do something with it?
[10:21] Kopilo Hallard: going through my logs now
[10:21] Aeron Constantine: yes Pauline - I have a feeling that's what is happening to us
[10:22] Aeron Constantine: linked messages coming in are causing heaps in other scripts
[10:22] Pauline Darkfury: https://wiki.secondlife.com/wiki/Link_message — "If str and id are bigger than available memory the script will crash with a Stack-Heap Collision. "

Generated with SLog Wikifier

Retrieved from "https://wiki.secondlife.com/w/index.php?title=User:Ama_Omega/archive/Office_Hours/2010-10-04&oldid=1142493"