User:Babbage Linden/Office Hours/2010 04 21

From Second Life Wiki
Jump to navigation Jump to search

Transcript of Babbage Linden's office hours:

[03:09] Ardy Lay: Hi Babbage

[03:09] Moy Loon: Hey!

[03:09] Morgaine Dinova: 'Morning Babbage :-)

[03:09] Skills Hak: Hey!

[03:09] Babbage Linden: hi folks

[03:09] Babbage Linden: sorry I'm late

[03:09] Babbage Linden: i was talking to space about monitoring

[03:10] Memorial Dae: *:-.,_,.-:*'``'Yaaayyyy!!!:-.,_,.-:*'``'*

[03:10] Morgaine Dinova: Babbage: the sun is out in UK, that's a miracle that excuses any lateness

[03:10] Babbage Linden: it certainly is pretty lovely atm

[03:10] Xugu Madison: hey Babbage!

[03:10] Aimee Linden: talking to space can get you sectioned

[03:10] Babbage Linden: so, what would you like to talk about today?

[03:10] Xugu Madison: looking good for 1.38.1 grid-wide today, still?

[03:11] Memorial Dae: lol

[03:11] Babbage Linden: i think so

[03:11] Kaluura Boa: Finally!

[03:11] Babbage Linden: i haven't seen any panicing

[03:11] Moy Loon: Been loving the new functions so far!

[03:11] Babbage Linden: good

[03:11] * Xugu Madison nods, and has been cutting scripts out of stuff

[03:11] Babbage Linden: yay!

[03:11] Babbage Linden: glad to hear it

[03:12] tentacles o.ol: tentacles o.ol [script:Mmm Tentacles :D timer] Script run-time error

[03:12] tentacles o.ol: System.MissingMethodException: Method not found: 'LindenLab.SecondLife.Library.llSetLinkPrimitiveParamsFast'.

at (wrapper managed-to-native) System.Reflection.MonoMethod:InternalInvoke (object,object[])

at System.Reflection.MonoMethod.Invoke (System.Object obj, BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) [0x00000]

[03:12] Memorial Dae: ...we like the crazy new S&#* !

[03:12] Skills Hak: aw this place is 1.36 :<

[03:12] Kaluura Boa: Crashed...

[03:12] Moy Loon: Aww

[03:12] Babbage Linden: heh

[03:12] Ardy Lay: Skills, that's a dman long error message.

[03:12] Babbage Linden: that's a pretty good error message though

[03:12] Skills Hak: no showing off the new goodies :/

[03:12] Ardy Lay: -dman +damn

[03:12] Morgaine Dinova: Who griefed me. My camera was in that space.

[03:12] Babbage Linden: it's pretty clear what the problem is

[03:12] Skills Hak: yea

[03:13] Babbage Linden: so, the new functions have been making the problems of script juicing worse

[03:13] Babbage Linden: so we're looking at fixing that

[03:13] Babbage Linden: but apart from that all feedback seems to be positive

[03:13] Moy Loon: I made a one script ray caster with the new functions, I was going to rez it and make a joke about the meeting being boring, and play wolfenstein instead

[03:13] Ardy Lay: "Juicing"?

[03:13] Skills Hak: that thing is pretty amazing

[03:14] Moy Loon: I hope juicing doesn't go away, It makes updates on lots of prims happen instantly

[03:14] Xugu Madison: sript juicing?!

[03:14] Babbage Linden: i talked about it in my fosdem talk

[03:14] Babbage Linden: if you sit a script in a tight loop doing simple math, it builds up a timer skip value

[03:15] Skills Hak: http://www.youtube.com/watch?v=QGneU76KuSY

[03:15] Felis head: Building The Virtual Babel: Mono In Second Life

[03:15] Babbage Linden: then you can pile in to some heavy lifting and cheat yourself in to grabbing a big timeslice

[03:15] Babbage Linden: which causes the sim to freeze

[03:15] Babbage Linden: we've had a fix for it for a long time

[03:15] Babbage Linden: but it can cause problems with some other scripts that use a different loophole to temporarily use more than 64KB of memory

[03:16] Morgaine Dinova: That's like the flywheel mechanism for gaining more memory, a bit

[03:16] Ardy Lay: Ah, okay. I didn't remember calling that juicing.

[03:16] Babbage Linden: yes, I call it a flywheel mechanism

[03:16] Babbage Linden: but aparently the cool kids call it juicing

[03:16] Babbage Linden: anyway, don't rely on it, fixes are coming

[03:16] * Memorial Dae makes note to sculpt a wheel with a fly running in it

[03:17] Babbage Linden: probably a partial one that just addresses the stalls with the 1.38 functions first

[03:17] Babbage Linden: then a full fix once we have soft limits

[03:17] Moy Loon: Aww, What about other methods to make lots of prims update all at once?

[03:17] Babbage Linden: (so the scripts that use the memory loophole will fault up to higher memory)

[03:17] Babbage Linden: we have more efficient scripts improvements on the backlog

[03:18] Babbage Linden: to put in when we can

[03:18] Xugu Madison: Excellent!

[03:18] Babbage Linden: but most work is on C# and Mono 2.x at the moment

[03:18] Moy Loon: Ah

[03:18] * Sebastean Steamweaver stepped in just in time.

[03:18] Memorial Dae: yes

[03:18] Memorial Dae: nice

[03:18] Memorial Dae: nice

[03:18] Moy Loon: What about improvements in regards to the setlinkprimparamsfast, Moving a lot of prims kills sims, because of the physics updates, link checking, ect...

[03:18] Morgaine Dinova: What's the value of 'x'?

[03:18] Xugu Madison: How's C# coming?

[03:19] Babbage Linden: Karel is currently testing a set of existing LSL scripts against the Mono 2.6.x verifier

[03:19] Babbage Linden: we're getting some warnings around using identifiers that begin with whitespace

[03:19] Sebastean Steamweaver: Mooy: Perhaps http://xkcd.com/?

[03:19] Morgaine Dinova: Ah,sounds like 'x' is 6

[03:19] Sebastean Steamweaver: Whoops, wrong thing.

[03:19] Sebastean Steamweaver: http://jira.secondlife.com/browse/SVC-5329

[03:19] Sebastean Steamweaver: llSetPrimParams

[03:19] Babbage Linden: and around identifiers that vary on by case

[03:20] Morgaine Dinova: Hiya Seb :-)

[03:20] Sebastean Steamweaver: Hey Morgaine :)

[03:20] Babbage Linden: so we're looking in to whether those are going to be problems

[03:20] Gaticus Hax: identifiers can start with whitespace?

[03:20] Morgaine Dinova: lol

[03:20] Babbage Linden: in LSL and C# they can't, but in CIL they can

[03:21] Babbage Linden: so we start all identifiers introduced by the UThreadInjector with whitespace

[03:21] Babbage Linden: to avoid clashes with existing variables

[03:21] Babbage Linden: you may remember problems around scripts with variables called "pc" a while ago

[03:21] Babbage Linden: we fixed that by renamed the UThreadInjector variable " pc"

[03:22] Morgaine Dinova: That is being "clever" to the point of being unhelpful, Babbage. People are going to trip up on that.

[03:22] Babbage Linden: now there is some discussion about whether that is valid in verifiable CLI assemblies

[03:23] * Xugu Madison would suggest changing to something statistically unique (like, pc<timestamp in milliseconds>)

[03:23] Babbage Linden: if it turns out that existing compiled LSL scripts are not verifiable we will need to build infrastructure to rewrite them to run in the new sandbox

[03:23] Babbage Linden: which we're hoping we don't have to do

[03:23] * Memorial Dae agrees with the squash

[03:23] Gaticus Hax: I'd have to agree, though it doesn't affect us in world, it doesn't seem like a very maintainable method

[03:23] Babbage Linden: but it's a risk

[03:23] Babbage Linden: so Karel is investigating

[03:23] Xugu Madison: Good luck!

[03:23] Panel 3: Freeze of 0.810425s detected (Mono)

[03:23] Panel 3: Freeze of 0.517477s detected (Mono)

[03:23] Panel 3: Freeze of 1.268741s detected (LSO)

[03:23] Panel 3: Freeze of 1.268741s detected (LSO)

[03:24] Babbage Linden: Johnny is currently adding more tests around the script lifecycle

[03:24] Babbage Linden: which will help us identify the problems with serialization/deserialization we were seeing with 1.38

[03:25] Babbage Linden: it turns out that the lifecycle wasn't very well specified

[03:25] Babbage Linden: so, we've tighted that up, added tests to enforce it and now we're fixing problems found by the tests

[03:25] Morgaine Dinova: What are the states of the lifecycle?

[03:25] Babbage Linden: running, stopped and faulted

[03:26] Babbage Linden: on serialization and deserialization scripts weren't consistently setting faults

[03:26] Babbage Linden: which meant we didn't see all serialization problems

[03:27] Babbage Linden: (only the subsequent deserialization failures, which weren't the root cause)

[03:27] Babbage Linden: when we have C# it will be easier to cause serialization errors

[03:27] Babbage Linden: (by forgetting to make a class serializable that needs to be)

[03:27] Morgaine Dinova: Interesting.

[03:27] Babbage Linden: and the runtime also needs to be able to deal with exceptions that will occur more often

[03:28] Babbage Linden: so, it's important that we get the lifecycle properly defined and the exception handling robust

[03:28] * Xugu Madison nodnods

[03:28] Panel 3: Freeze of 0.508596s detected (Mono)

[03:28] Panel 3: Freeze of 0.542384s detected (LSO)

[03:28] * Xugu Madison also cheers at "exception handling"

[03:28] Sebastean Steamweaver: Hmm

[03:28] Babbage Linden: it's work we need to do for C#, but it will also help reintroduce the sim freeze fixes

[03:28] Babbage Linden: without the problems we saw with 1.38

[03:29] Babbage Linden: the other work we're doing is researching the Moonlight sandbox definition technology

[03:29] Babbage Linden: so that we can define the critical and safe critical parts of our platform

[03:30] Babbage Linden: the attributes that Mono will use to enforce the sandbox in the simulator

[03:30] Babbage Linden: we're reusing the annotations on the BCL used by Moonlight

[03:30] Babbage Linden: but need to add out own annotations to the LindenLab.SecondLife.* namespace

[03:31] Xugu Madison: You have your own annotations?

[03:31] Morgaine Dinova: Is the BCL in ECMA?

[03:31] Babbage Linden: morgaine, yes

[03:31] Morgaine Dinova: Coolness

[03:32] Babbage Linden: there are some non-BCL libraries I'd like to expose like System.Cryptography, so I'm trying to find the legal status of those

[03:33] Babbage Linden: but, at the moment, our profile is the BCL restricted by the Silverlight annotations

[03:33] Babbage Linden: (so System.IO.File is in the BCL, but Silverlight stops you using it freely)

[03:34] Babbage Linden: the last thing we're doing is working out whether we should initially aim to support C#1 or C#2

[03:34] Babbage Linden: making C#1 work in the CoreCLR sandbox will require some changes

[03:35] Babbage Linden: making our UThreadInjector work on C#2 assemblies will require us to port it to Cecil

[03:35] Babbage Linden: so, we're weighing up the risks and work involved in each choice

[03:35] * Xugu Madison would favour C#2, move forwards even if it takes a bit longer

[03:35] Morgaine Dinova: Is System.IO.File still in the runtime, but just proven not called from CLI within the sandbox?

[03:36] Babbage Linden: morgaine, yes there are some classes and methods that are available for use by platform assemblies, but not by untrusted code

[03:36] Panel 3: Freeze of 0.788685s detected (LSO)

[03:36] Panel 3: Freeze of 0.822106s detected (Mono)

[03:36] Panel 3: Freeze of 0.617341s detected (LSO)

[03:36] Panel 3: Freeze of 0.617341s detected (Mono)

[03:36] Panel 3: Freeze of 1.261972s detected (Mono)

[03:36] Panel 3: Freeze of 1.237735s detected (LSO)

[03:37] Babbage Linden: we use application domains to manage assembly unloading

[03:37] Babbage Linden: so, application domains need to be available

[03:37] Babbage Linden: but we don't want scripts being able to load and unload domains

[03:37] Babbage Linden: so, the application domain code would be marked as security critical

[03:37] Babbage Linden: available, but restricted

[03:38] Babbage Linden: (application domains are also in the BCL, but scripts won't be able to manipulate them)

[03:39] Babbage Linden: apart from the C# work, I've mostly been looking at getting http textures infrastructure in to 1.40

[03:39] Kaluura Boa: Hooooo!

[03:39] Sebastean Steamweaver: For textures in general?

[03:39] Babbage Linden: which is going to be close

[03:39] Babbage Linden: but will hopefully make it

[03:39] Babbage Linden: which is going to be close

[03:40] Babbage Linden: yes

[03:40] Morgaine Dinova: Since the sandbox is on your servers, you give it your trust and you take the risks from your confidence in your checks, which is appropriate. Please note though Babbage that it's quite a different kettle of fish when you run untrusted code on OUR boxes. (Referring to Firefly). No-go, unless you accept responsibility for any mishaps on our machinery.

[03:40] Sebastean Steamweaver: That will be very nice if it makes it in.

[03:40] Morgaine Dinova: (To Babbage)

[03:41] Babbage Linden: morgaine, it's a big deal, definitely

[03:41] * Morgaine Dinova nods

[03:41] Babbage Linden: we trust sandboxes in browsers, but there is huge potential for problems there

[03:42] Babbage Linden: one of the reasons that we're reusing the moonlight sandbox rather than building a new one is that that sandbox is trusted in browsers

[03:42] Morgaine Dinova: And there are hundreds of thousands of people being exploited by botnets as a result of the exploits in those sandboxes.

[03:42] Babbage Linden: but, we still need to be very careful about all the changes we make

[03:42] Babbage Linden: yes, indeed

[03:43] Babbage Linden: which is why we should all be running modern operating systems, with all updates and the latest versions of browsers

[03:43] Babbage Linden: building and maintaining a sandbox is a huge commitment

[03:43] Babbage Linden: which is why I'm glad that we're moving to use an existing one

[03:44] Babbage Linden: rather than trying to build and maintain our own

[03:44] Morgaine Dinova: It'll be many years before the Moonlight sandbox is trusted in browsers. Even Silverlight won't be trusted for a good few years yet, since it's so little used. Moonlight, even less. They're both orders of magnitude less tested than the JS sandbox, which despite that has had a stream of exploits.

[03:44] Babbage Linden: but, it means we need to be super careful about any changes or extensions we make

[03:45] Morgaine Dinova: Oh, it's fine .... on your equipment :P And I hope it works safely :-)

[03:45] Babbage Linden: the moonlight sandbox is going to see a lot more use and developer eyeballs than the LSL sandbox

[03:45] Babbage Linden: so, we're moving in the right direction :-D

[03:46] Morgaine Dinova: :-)

[03:46] Babbage Linden: so, that's an update on what we've been up to

[03:46] * Xugu Madison idly feeds developer eyeballs to the Moonlight sandbox

[03:47] Sebastean Steamweaver: Hehe

[03:47] Babbage Linden: Rand has also been making good progress with the C# API docs

[03:47] Morgaine Dinova: Very interesting update Babbage, thank you.

[03:47] Babbage Linden: which are looking good

[03:47] Babbage Linden: and should be available in a month or so

[03:47] Xugu Madison: Excellent!

[03:47] Sebastean Steamweaver: I was about to ask :) Awesome.

[03:47] Babbage Linden: the initial release is going to be a skeleton

[03:48] Babbage Linden: which shows the API, but leaves examples and notes mostly blank

[03:48] Babbage Linden: the calls will link to the LSL function calls, which contain all the notes and caveats there

[03:48] Morgaine Dinova: Man pages would be nice

[03:48] Babbage Linden: it's going to be a wiki, so we'll all be able to maintain and update it with examples when we get to beta

[03:49] * Morgaine Dinova wonders if there are wiki2* tools

[03:49] Sebastean Steamweaver: How long will it be in beta before it's released to the grid?

[03:49] Babbage Linden: and I think Rand has done a good job finding a layout which feels reasonably comfortable to both LSL and C# developers

[03:49] Sebastean Steamweaver: I know that's been asked, I just can't rmember.

[03:50] Babbage Linden: sebastean, I would like to release it as early as possible and have a long beta

[03:50] Babbage Linden: that was very useful for the Mono development

[03:50] Sebastean Steamweaver: That sounds like a good plan to me.

[03:50] Babbage Linden: and we want to get all behaviour changes ironed out before we go to agni and people start relying on behaviours

[03:50] Morgaine Dinova: That's good. Unlike the politically driven ultra-short V2 beta :-(

[03:51] Babbage Linden: bug fixing becomes much harder once we have to consider backwards compatibility

[03:51] Babbage Linden: (see the previous script juicing and memory use discussion)

[03:51] Panel 3: Freeze of 0.542152s detected (LSO)

[03:51] Panel 3: Freeze of 0.571318s detected (Mono)

[03:51] * Sebastean Steamweaver is looking forward to script versioning.

[03:52] * Xugu Madison is fairly unsympathetic towards devs who meddle with the system to get it to do stuff it wasn't intended to

[03:52] Babbage Linden: xugu, right, but unfortunately LSL was previously specified by its implementation

[03:53] Babbage Linden: so, it's hard to point at a documentation and say you're exploiting a bug

[03:53] Memorial Dae: ...feature

[03:53] Babbage Linden: I think there will be some uses that are just accidental rather than intentional

[03:53] Babbage Linden: so, we'll do what we can to avoid problems

[03:53] Panel 3: Freeze of 0.862732s detected (Mono)

[03:53] Panel 3: Freeze of 0.904218s detected (LSO)

[03:53] Babbage Linden: ok, a few minutes left

[03:53] Sebastean Steamweaver: Babbage, since there's only a few minutes left and things seem a bit quieter, I wanted to ask a quick question - and no worries, I'm not looking for discussion, this is just a plumb-line question. I know this is all our favorite topic, too ;) I know that you all are busy with Mono and C#, etc. My question is, when and if there is time at some point in the near or farther future, would you be open to the implementation llSet/GetObjectScale? Again, this is just "when there is time" whenever that might be.

[03:53] Fury Rosewood: welcome back ardy

[03:54] Ardy Lay: Thanks

[03:54] Babbage Linden: sebastean, yes definitely

[03:54] Fury Rosewood: welcome

[03:54] Babbage Linden: at this point I would like to let the 1.38 functions bake a while

[03:54] Babbage Linden: while we work on C# and Mono 2.6

[03:54] Babbage Linden: then do another pass on the API after that

[03:55] * Sebastean Steamweaver nods, "Letting things settle and givingus time to chew on what we have."

[03:55] Babbage Linden: when we will hopefully have a more complete picture of where 1.38 changes worked and where more is needed

[03:55] Babbage Linden: right

[03:55] Babbage Linden: ok, 5 minutes left

[03:56] Sebastean Steamweaver: I'm ecstatic about these functions. There are many instances I've replaed upwards of 15 scripts with one.

[03:56] Sebastean Steamweaver: replaced*

[03:56] Babbage Linden: anything else we should cover today?

[03:56] Morgaine Dinova: "Yes definitely" sounds fairly promising :-)

[03:56] * Xugu Madison nods, and agrees

[03:56] Xugu Madison: I think we're done :)

[03:56] Panel 3: Freeze of 0.543549s detected (LSO)

[03:56] Panel 3: Freeze of 0.559018s detected (Mono)

[03:56] * Babbage Linden faints

[03:56] Sebastean Steamweaver: Indeed :) And I'm glad I was in for the C# update, I almost missed it.

[03:57] Babbage Linden: ok, thanks for coming everyone

[03:57] Morgaine Dinova: Great chat Babbage, thanks.

[03:57] * Sebastean Steamweaver brings Babbage the smelling salts.

[03:57] Memorial Dae: Wow, one for the record books

[03:57] Xugu Madison: Thanks for hosting Babbage!

[03:57] Babbage Linden: hopefully I'll see you all next week

[03:57] Sebastean Steamweaver: Yes, thank you Babbage
Retrieved from "https://wiki.secondlife.com/w/index.php?title=User:Babbage_Linden/Office_Hours/2010_04_21&oldid=873212"