Building The Virtual Babel: Mono In Second Life
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Number of Parts | 97 | |
| Author | ||
| License | CC Attribution 2.0 Belgium: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
| Identifiers | 10.5446/45683 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
FOSDEM 201092 / 97
1
2
4
5
6
8
14
15
16
17
23
29
38
41
42
44
46
47
48
50
53
54
62
63
64
65
66
71
74
75
77
78
79
80
82
84
85
94
00:00
Virtual realityVideo gameStructural loadTrailScheduling (computing)Video game2 (number)Computer clusterVideo gameMultiplication signLoginLecture/Conference
00:46
Video game2 (number)Avatar (2009 film)User-generated contentVideo gameVirtualization6 (number)Core dumpDialectScaling (geometry)MetreBuildingQueue (abstract data type)Multiplication signExistenceServer (computing)Level (video gaming)NeuroinformatikLine (geometry)Real numberPhysical systemWorld of WarcraftProcess (computing)SubsetSoftwareKey (cryptography)Service (economics)Lecture/Conference
03:45
Server (computing)Structural loadField (computer science)Square numberLevel (video gaming)Dot productComputer simulationCore dumpBoundary value problemVideo gameReal numberCuboidCubeObject (grammar)Video gameScripting languageVirtual reality2 (number)Concurrency (computer science)TouchscreenContent (media)NeuroinformatikCausalityPoint (geometry)Right angleNumberLecture/Conference
06:04
Game theoryExecution unitCluster samplingNamespaceCollisionTurtle graphicsMagnetic stripe cardGeneric programmingInheritance (object-oriented programming)WordMessage passingVideo game2 (number)Avatar (2009 film)Game theoryScripting languageStandard deviationVideo gameIntegrated development environmentBitRange (statistics)Disk read-and-write headArmRight angleQuicksortNormal (geometry)Lecture/Conference
08:26
Process (computing)Library (computing)Scripting languageObject (grammar)TelecommunicationCellular automatonPrime idealEmailComa BerenicesEvent horizonWeb 2.0Object (grammar)Cartesian coordinate systemSystem callLibrary (computing)Cuboid2 (number)Cylinder (geometry)Term (mathematics)Video gameCAN busScripting languageTouch typingProcess (computing)Boundary value problemInstant MessagingCodeThread (computing)EmailAvatar (2009 film)NumberSemiconductor memoryOrder (biology)Server (computing)File systemVirtual machineVideo gameMashup <Internet>Computing platformProgrammschleifeLecture/Conference
10:16
Vector graphicsHuman migrationProgramming languageElectronic mailing listScheduling (computing)Type theoryState of matterChainSemiconductor memory2 (number)Formal grammarProgramming languageRecursionType theoryMathematical optimizationFormal verificationSoftware bugElectronic mailing listPointer (computer programming)Vector spaceMultiplication signVirtual machineVideo gameControl flowOpcodeConnected spaceSoftwareBlock (periodic table)Memory managementState of matterRotationFunctional (mathematics)Moment (mathematics)Crash (computing)CompilerParsingBytecodeVariable (mathematics)CuboidVideo gameOpen setStatement (computer science)Lecture/Conference
12:54
Heat transferLimit (category theory)BytecodeConcurrency (computer science)Assembly languageHuman migrationTime domainSerial portCommon Intermediate LanguageSemantics (computer science)Mach's principleData storage devicePointer (computer programming)OpcodeProgram slicingOrder (biology)Set (mathematics)Memory managementVideoconferencingConstructor (object-oriented programming)Slide ruleSystem callMultiplication signHydraulic jumpJust-in-Time-CompilerHand fanFrame problemStack (abstract data type)Functional (mathematics)Object (grammar)Scripting languageVirtual machineJava appletDifferent (Kate Ryan album)Point (geometry)CodeResource allocationProfil (magazine)Computer simulationCartesian coordinate systemDomain nameHuman migrationSemiconductor memoryProcess (computing)TrailRecursionAssembly languageLimit (category theory)InfinityCuboidProgrammschleifeSoftware testingInformationMeasurementFigurate numberType theorySerializability2 (number)IntegerBlock (periodic table)ExpressionMobile WebThread (computing)ChainPhysical systemBuildingFlow separationCommon Intermediate LanguageControl flowConnected spaceSoftwareConcurrency (computer science)Server (computing)InternetworkingGame controllerFamilyBitRight angleState of matterData managementCodeVideo gameSyntaxbaumQuicksortLoop (music)Computer programmingIntegrated development environmentNetwork topology.NET FrameworkLevel (video gaming)WeightForm (programming)Social classLecture/Conference
21:12
Limit (category theory)Resource allocationNP-hardRead-only memoryString (computer science)Point (geometry)Physical systemVariable (mathematics)SpeicherbereinigungChainChainingMemory managementBitOperator (mathematics)Loop (music)Multiplication signScheduling (computing)CodeCalculationScripting languageMathematicsContent (media)32-bitSemiconductor memoryVideo game consolePointer (computer programming)Electronic mailing listSimulationVideo game2 (number)CASE <Informatik>Crash (computing)Computer simulationSpeicherbereinigungRun time (program lifecycle phase)Revision controlSystem callCodeObject (grammar)Right angleMiniDiscBlock (periodic table)Line (geometry)Serial portPatch (Unix)Wave packetPoint (geometry)Sigma-algebraFunctional (mathematics)Electronic signatureComputer fileState of matterChainInterpreter (computing)Exception handlingOpen sourceGame theoryAlgorithm.NET FrameworkEinbettung <Mathematik>PlastikkarteAdaptive behaviorDifferent (Kate Ryan album)Hydraulic jumpImplementationWeightPhysical systemLecture/Conference
28:05
Second LifeFraktalgeometriePixelCuboidStructural loadFluxDemo (music)Graph coloring2 (number)Gamma functionVideoconferencingClosed setWhiteboardVideo gameRaster graphicsScripting languageTouchscreenVideo gameLine (geometry)Color managementLecture/Conference
29:42
SpeichermodellLimit (category theory)Scripting languageData typeEnumerated typeType theoryPrimitive (album)Array data structureVideo gameVirtual memoryWeb serviceOperating systemScripting languageOpen sourceProgramming languageVirtual machineSemiconductor memoryComputer simulationOpen setLimit (category theory)2 (number)Electronic mailing listEmailElectronic program guideMoment (mathematics)Web pageEndliche ModelltheorieC sharpObject (grammar)Video gameWeb 2.0CodeMathematical optimizationSoftware developerHydraulic jumpCartesian coordinate systemProxy serverProcess (computing)Computer programmingMetreSquare numberGraph (mathematics)Message passingMereologyDynamical systemInteractive televisionBlock (periodic table)ScalabilityIntegrated development environmentJust-in-Time-CompilerControl flowProjective planeFunctional (mathematics)Disk read-and-write headDampingCryptographyProper mapServer (computing)Type theoryArray data structureGoodness of fitSoftware bugQuicksortProblemorientierte ProgrammierspracheCellular automatonInternetworkingReal numberCodeRight angleAvatar (2009 film)GodSystem administratorVideoconferencingSource codeEnumerated typeException handlingJava appletLecture/Conference
36:54
Generic programmingProcess (computing)Revision controlGoogolSet (mathematics)MereologyMultiplication signSoftware frameworkMatching (graph theory)WeightOpcodeAssembly languagePointer (computer programming)Generic programmingMoment (mathematics)Shooting methodData managementCodeLecture/Conference
38:48
Information securityMarkup languageFactory (trading post)Einbettung <Mathematik>CodeScripting languageWeightAssembly languageSystem callInformation securityStructural load1 (number)BytecodeProcess (computing)Point (geometry)Moment (mathematics)Computer simulationHookingRight angleSoftware frameworkProfil (magazine)ExplosionMarkup languageLecture/Conference
40:25
WeightVector spaceFile formatLibrary (computing)Electronic mailing listQuaternionSimulationInheritance (object-oriented programming)Scripting languageOvalTouch typingEvent horizonElectronic mailing listException handlingType theorySocial classWeightHash functionState of matterLibrary (computing)Table (information)Event horizonObject (grammar)Demo (music)Moment (mathematics)Physical system.NET FrameworkTransport Layer SecurityTouch typingPhase transitionMechatronicsTerm (mathematics)Line (geometry)System callMultiplication signVideo gameAuthorizationScripting languageWeb 2.0Function (mathematics)1 (number)Functional (mathematics)CodeInheritance (object-oriented programming)String (computer science)Overhead (computing)Computer configurationSet (mathematics)Right angleDynamical systemRevision controlOcean currentParameter (computer programming)Validity (statistics)Video gameBitDisk read-and-write headSoftware frameworkProfil (magazine)Uniform resource locatorRow (database)Array data structureInformation securityComputer simulationTexture mappingCellular automatonError messageHexagonCryptographyEndliche ModelltheorieLecture/Conference
45:19
Integrated development environmentBeta functionCodeSocial classElectric generatorFile viewerVideo gameProgrammer (hardware)Programming languageVisualization (computer graphics)NamespaceCuboidINTEGRALHookingScripting languageC sharp2 (number)Revision controlUnit testingOpen sourceBeta functionPoint (geometry)Assembly languageIntegrated development environmentCompilation albumFunctional (mathematics)Moment (mathematics)Software frameworkRun time (program lifecycle phase)BitSoftware developerVideo gameMultiplication signLibrary (computing)Source codeView (database)Line (geometry)Level (video gaming)Different (Kate Ryan album)Lecture/Conference
47:57
MaizeVideo gameService (economics)Point (geometry)2 (number)Right angleMultiplication signScheduling (computing)Demo (music)Proper mapOpen sourceFile viewerFirewall (computing)SoftwareFreewareVideo gameOpen setLecture/ConferenceMeeting/Interview
48:50
Group actionVirtual machineVideo gameScripting language2 (number)Avatar (2009 film)Client (computing)BitTwitterVideo gameLecture/Conference
49:39
2 (number)TwitterMessage passingTouch typingAvatar (2009 film)String (computer science)Functional (mathematics)IntegerLibrary (computing)Software testingCommunications protocolObject (grammar)Key (cryptography)Video gameLink (knot theory)Bus (computing)Ocean currentVideo gameLecture/Conference
50:47
Execution unitScripting languageMessage passingObject (grammar)Integrated development environmentCode2 (number)Structural loadType theoryPhysical systemPoint (geometry)Line (geometry)InternetworkingProgramming languageString (computer science)Library (computing)IntegerElectronic mailing listBitData storage deviceWeightFunctional (mathematics)Revision controlBoolean algebra.NET FrameworkCodierung <Programmierung>Array data structureDifferent (Kate Ryan album)Video gameCache (computing)Electronic signatureImplementationToken ringHash functionBinary codeASCIIRight angleInformation securityGastropod shellPrototypeVideo gameCryptographyTaylor seriesLecture/Conference
53:57
Web pageTwitterCuboidUniform resource locatorC sharpSoftware testingScripting languageWeb 2.0Touch typingMessage passingStructural loadAuthorizationWeb browserCellular automatonServer (computing)Gastropod shellEvent horizonWeb serviceLecture/Conference
54:47
Video gameScripting language2 (number)Point (geometry)Web 2.0PasswordCartesian coordinate systemTwitterVideo gameWeb pageCellular automatonRight angleLecture/Conference
55:33
Service (economics)Object (grammar)Real numberVideo game2 (number)Uniform resource locatorLink (knot theory)Level (video gaming)Data conversionTwitterReflection (mathematics)Goodness of fitDemo (music)Electronic mailing listEmailSoftware developerRight angleVideo gameReal-time operating systemWeb 2.0Visualization (computer graphics)Lecture/Conference
57:55
Scripting languageSource codeRevision controlOpen sourceEndliche ModelltheorieVideo gameOpen setCode2 (number)Object (grammar)Functional (mathematics)Video gameSoftware bugExploit (computer security)Right angleSemiconductor memoryElectronic mailing listHash functionStructural loadResource allocationBlock (periodic table)Computer simulationCASE <Informatik>Pointer (computer programming)Interpreter (computing)32-bitAxiom of choiceLecture/Conference
Transcript: English(auto-generated)
00:00
Brilliant, it's a brilliant, brilliant track. So I hope you talk about that. I'm going to talk about that, yep. Thanks Miguel. So when I was looking at the schedule, I was like, yeah, I've got loads to talk about, I want an hour, give me an hour, it's going to be great, we're going to talk about loads of stuff. And then I saw the schedule and all the other talks, squeezed in around the place. So I apologize for kind of stealing all the time. I've been working on this mono in Second Life
00:24
for about five years now. So given that the star date is now 2010 and we've been boldly going for five years, there's quite a lot of stuff in the captain's log these days. So I'm Jim Purbrik, I'm going to be talking about Second Life, and more particularly I'm going to be talking about
00:41
scripting in Second Life. So Second Life is now 6. Second Life is an online user-generated virtual world. It was launched in 2003, it's now 6. It's going to have its seventh birthday this summer,
01:01
and it's a user-generated virtual world. So you have people in the virtual world, they're embodied as avatars, they're avatars are built by themselves or their friends, you can buy and sell clothing and items in Second Life. So you can go in Second Life and go, right, I want to be an elephant, so you can go and buy an elephant avatar and be an elephant and walk around, or you can go and make one.
01:20
And being a user-generated virtual world, this is a user-generated birthday cake at the sixth birthday party. So when Second Life launched in 2003, the world looked like this. So there's about 50 regions on this map here. Each of these regions is 256 meters on a side.
01:42
Each of the regions is being simulated on a core of a server. Originally they were all in San Francisco, we're currently just escaping from San Francisco, we have colos all around the place. And one of the reasons that the system scales is that if you have this region here which is being simulated on a single process,
02:00
it's only ever talking to the regions north, south, east and west of it. So you can, as more people turn up to Second Life and more people want land to build castles or shops or dance clubs or whatever it is that they're building, we buy some more racks, we bolt them to the floor, we plug them in, they download the software, they say which regions do you want me to run, and they start running a region.
02:21
So unlike most virtual worlds, most virtual worlds, things like World of Warcraft, are like theme parks. You basically work out, I've got 200 content creators and they're going to fill the world with stuff for three years and they're going to make about this much stuff and that's going to make this much size and we want to make it so that there's only 10 minutes walk
02:40
between each interesting thing. So this world can fill, you can have maybe 5,000 people in this world at any one time before it feels so full and the queues in the theme park are so long that it gets boring. So what you do, because this is computers and not a real theme park, is you pour people in until it feels nice and full and there's lots of people to meet, but not so full that the lines are too long and then you make another copy of the world.
03:02
So when you play World of Warcraft, if you go and get a user account and play World of Warcraft, you'll choose a server and that will define the people that you get to meet in your World of Warcraft existence. So if someone else is on a different server, it's just kind of tough. You can't hang out, you can't meet with each other. Whereas in Second Life what happens is the world constantly gets bigger around the edges.
03:21
So as more and more people turn up, they want more and more stuff, they want more room to do things, we bolt more servers to the ground and this map gets bigger. And that means that if you create a shop in Second Life and you start selling stuff, that means your marketplace is everybody in Second Life. Everybody can come to your shop, everyone can come to your nightclub. Your market is everybody in Second Life. It's not a subset.
03:42
So this is what it looked like in 2003. And... Oh, I've got to point it at the computer and not the screen. This is what it looks like today. So remember those squares on the first map? Each one of these dots on this map is one of those squares. So we now have 25,000 cores running simulators in Second Life,
04:00
plus loads of other servers running other stuff. There's 600 square miles of land. So that's about the same size as Hong Kong and it's about as densely packed as Manhattan, right? There aren't many rolling fields full of wheat because you don't need wheat because you don't eat things. But you do need nightclubs. So you squash loads and loads of nightclubs together and so you end up with something that's the size of Hong Kong
04:21
but as densely populated as Manhattan. So there are 150 people, 150 countries represented in Second Life. There's 40 million user hours per month. There are about nearly 800,000 repeat logins a month. So that's kind of the population. Now this is interesting. The peak concurrency of Second Life is 87,000. That's the biggest single virtual world
04:42
that the world has ever seen. But there are 80 million running scripts in Second Life. So a script is something in Second Life which is in an object and makes it interactive, right? So in Second Life you make something, you point at the floor and say make a cube and it pops up and then you say add a script and now you've got a box with a brain and so you can poke it and the box can go ow when you poke it.
05:02
So that's a script in Second Life and they're used for everything from like making it so that you sit nicely on a chair, making it so that you can open a door, making it so you can dance. But there are 80 million scripts running in Second Life. There's roughly a thousand scripts for every person. So you can look at Second Life as this huge simulated environment
05:21
which humans occasionally visit. But most of the stuff that's going on is scripts. So other numbers, there are 800 gigabytes of new content created a day, there's 390 terabytes of content that we store on our servers and our switches transmit 12 gigabits a second of data. So Second Life's pretty big. You can also make money in Second Life.
05:42
So last year there were 47 million US dollars transferred between residents every month and 10 million US dollars transferred across the boundary between Second Life and real life every month. So you go to Second Life with 10 dollars, you convert it into Linden dollars and then you can go and buy shoes and hats and cars
06:01
and whatever it is that you want to buy in Second Life. So that's Second Life. So today I'm going to be talking about the pixie dust, the secret scripted pixie dust that you sprinkle over stuff in Second Life to make it do things. And this is what turns Second Life from a kind of 3D environment with people that can kind of walk around and say hi to each other to an environment where you can go skydiving
06:21
or skiing or sailing or dancing or whatever it is that you want to do. So as I said before, you use scripts in Second Life to animate your avatar. So you get this kind of like standard duck walk when you log into Second Life. If you want to have a humanoid that animates differently, you'll go and use scripts to do that. If you want to make a tiny avatar,
06:40
this is ingenious, right? We have this range of, mostly the normal Second Life avatars are within a sort of reasonable range. They tend to be big because most people want to be tall when they join. So they tend to be big humanoids. But some people have worked out that if you use special animations, you can kind of make an avatar that kind of crushes his arms into his body and then folds his legs up
07:01
so he's kind of sitting in a tiny ball and then has his head sticking out the top and then you can like plug bits on so you can make it have like a mouse face and then you can have a tiny, cute little mouse avatar that's running around. But the way that works is you have to have an animation. You have to have scripts that control your animations because your avatar is no longer walking like this. Your avatar's kind of stretched up into a ball
07:21
and kind of flapping his hands and feet around. So you have to use scripts for that. And also if you want to be a dragon or you want to be a non-humanoid, you have to use scripts for your animations. Scripts are used for dancing, which is a huge thing in Second Life. They're used for vehicles, seats, games and guns, doors, elevators, teleporters, as I said, non-human avatars.
07:41
Chickens was a really big thing in Second Life. So I talked to Miguel about the chickens in Second Life. You can go and buy chickens and you can breed them into each other and they have genes and they kind of pass on traits to each other with generics, with kind of, what's the word? Inheritance.
08:01
So they inherit genes from each other. And so, collision of namespaces there. So you can go and buy chickens and you can breed them and you can say, I want to get a chicken that's red or green or purple or has tiger stripes or whatever and you can breed them together. And that was a big thing. But after the chickens were turtles and now the big thing in Second Life is bunnies,
08:21
but none of this wildlife would exist in Second Life without scripts. You also use scripts for selling stuff to each other. So instead of being in Second Life to sell stuff, you'll make a vendor like a vending machine, except instead of selling cans of coke, it's selling cars or teleporting objects or whatever.
08:40
So the way scripts work in Second Life is, as I said, you put scripts in prims. You make a box, you put a script in it. You link them together to make objects so cars are like many boxes and cylinders stuck together. You have sensors via events. So you say, I'm going to create an event handler for this thing being touched. And then you have effectors via library calls. So if you want to make a box
09:01
that when you touch it jumps up in the air, you would have an event handler for the touch event and then you'd have a library call to say, move me up in the air. You can communicate between scripts. You can send instant messages to avatars or other scripts. You can send email to the outside world. You can receive email. You can use XML RPC to communicate. You can use HTTP to communicate.
09:20
So you can wire Second Life applications up to the web and people have done cool mashups with that. In terms of the platform, all this is untrusted code. So we're running it on our servers. So we really don't want you to be able to, you know, wander around our memory and do stuff and access our file system. Another interesting thing is that there are 2,000 scripts per process. So in order to get 80 million running scripts in Second Life,
09:41
you have to have many, many scripts in every region. And so every door, every seat, every haircut, every pair of shoes will have scripts in and that adds up to many, many scripts. And, you know, as Alan was saying, the correct number of threads is one. We use a single thread and we run all these scripts on a single thread, but this is untrusted code and we allow people to have four loops.
10:02
So how do we do that? We'll talk about that later. And the other thing is you need to be able to migrate these scripts between processes. You need to be able to put your foot down and drive a car across a boundary and all the scripts in your car need to move from one process to another process. So there's kind of some interesting things going on there. So the language we use currently in Second Life is LSL,
10:21
which is the language I'm wearing at the moment. It's a C-like language. It has vectors and rotations. So it's kind of a DSL. It has, like, language features for 3D built into it. So that's quite exciting, kind of. It's statically typed and there are six of them. You can't make any more. There are six static types. You better like them. The only collection is heterogeneous lists.
10:43
It has states, which is kind of interesting. It's borrowed from various other game scripting engines. It means that you can do stuff like if you click on a door and it opens, it can switch into an I'm open state. Then you click on the door again and it closes. So you can do that kind of thing. So the way LSL is implemented originally,
11:02
on the original VM, it's a textbook 16K bytecode VM. So you have 16 kilobyte block and it'll have a bunch of registers at the top and then it'll have a stack and a heap and they grow up and down and they meet each other in the middle and have a collision and explode and you run out of memory. So it's a textbook implementation, which means it's really easy to migrate. You just take these 16K blocks and you throw them down a network connection
11:22
and they appear at the other end and they've got their registers and their memory and everything's done. It's kind of relatively easy to schedule them because the way the original virtual machine works is it goes through every opcode and checks the time between each one. So it goes, you know, opcode, get time of day, opcode, get time of day, opcode, get time of day, oh, I've run out of time, I'm going to stop executing.
11:43
And it's easy sandboxing because although it has references within itself to variables, basically you just need to check that all the pointers don't go outside that 16K box, which hopefully is okay. We still occasionally have bugs with this virtual machine, so we don't know how safe this is. It was built, we run it, we don't really know how safe it is.
12:03
It wasn't designed like verification in the CLR, for example, by people who actually thought about it for more than 10 minutes. So it's really, really, really slow. It's interpreted, it's not doing any optimisations and it's very, very broken. So, for example, we accidentally got the recursion in the grammar
12:20
around the wrong way, so if you make an if-else statement, if-else chain that's too long, and you kind of have to because you don't have switch statements, then the parser can't recurse. So it just gets bigger and bigger and bigger, and then your compiler crashes. That's kind of one of the ways it's broken. Another interesting way we found when we were implementing this stuff on Mono is that returns are optional.
12:41
So you can have a function which has two control flows. One of them returns a value and the other one doesn't, and that's okay. That will compile and run in LSL. So there's some quite scary features in the language. So the thing I've been doing for ages, and the reason I'm here and the reason I know you all and the reason I've had lots of fun over the last few years
13:01
is that we decided it would be a great idea to run LSL on Mono. Because Mono was coming out, it wasn't Java, which no one was a fan of at Linden Lab, and it had a JIT and it was designed by a bunch of people who knew what they were doing more than we did and had more time than we did. So we were like, okay, let's see if we can run LSL on Mono.
13:21
So this slide here is the talk I gave in Madrid, and it's available online. I also gave it at LangNet, so if you want to go and see that talk, go and find the video. I'm going to quickly run through it because Miguel wants me to talk about this stuff, but there is another talk that you can go and get more detail on this stuff.
13:41
So the big problem with running LSL on Mono is that a lot of the things about the environment in Second Life aren't easy to do when you're running a script on Mono. For example, it's not easy to take a running program, which is in the middle of a for loop, and move it from one Mono virtual machine to another virtual machine, which is what we need to do.
14:02
It's also not particularly easy to have 2,000 threads running at the same time on Mono in a single process. So the big thing that we did is that we rewrite assemblies for concurrency and mobility. So in Miguel's talk earlier on, he said that you've got these two things.
14:20
You can either make a function, and then when you look at it, it's just a blob of code, or you can make an expression tree, and then you can look at the expression tree, and that is totally awesome, but it's not completely true that when you end up with a block of CIL code, that's the end because you can get the block of CIL code, and then you can just pull it apart again, and you can shove new bits into it, and you can make it do things, and you can try and figure out what it's doing.
14:41
So what we did is we induced the stack state, which is actually the same process that... I should have moved all these bullets to the top. Sorry about this. So it's the same process you use when you verify an assembly. You start off at the top of the method, and you go, there's nothing on the stack, and then you get a push integer, a push integer,
15:00
and you go, okay, between these two opcodes, there are now two integers on the stack, and you can keep doing this through all the control flows through the entire method, and so what that means is, once you've done that process, you know all the types that are on the stack at every point in the function, and it means that if you decide that you want to pause execution at that point in the function,
15:20
you know what's on top of the stack, you can make a heap object, and you can make a heap object and copy those values from the stack into the heap object, and then you can make a chain of these heap objects, so what effectively you're doing is making a chain of stack frames on the heap that contain all the information that was on the stack in the actual machine,
15:41
so you basically, and in order to make sure that none of these things get caught in a tight loop, you make sure that you do that test at every backwards jump or every function call, so you avoid infinite looping and infinite recursion by going, okay, there's a backwards jump here, so before I do this backwards jump, see if I've run out of time
16:00
or see if I need to migrate to a different process. If I do, then instead of doing the backwards jump, do a jump to a postfix, which we've injected, which goes, right, call a constructor for a heap object, consume all the things off the stack, store them in a heap object, and then return, and then the calling function will go, are there any of these heap stack frames on the heap stack, and if there are, it will go, okay, I need to stop as well,
16:21
and so it will return, and it will unwind the whole call stack, and it will effectively turn the call stack in mono into a chain of heap objects, and then you can go, okay, I've got the script, which is a serializable class, and I've got these heap objects, which are a chain of serializable objects, so now my entire state, the stack and the heap, are all in serializable object form,
16:41
and then I can shove them down a network connection and move them to a different machine, or I can schedule another script to run. So that's basically what we did. That was the big thing, and it wasn't, you know, it wasn't actually new, it was kind of borrowed, so this is the same thing that happens in Java Go X and Breaks on Java, so several years ago when mobile agents were a big thing,
17:03
people did this kind of stuff to build mobile agent systems that could wander around the internet. But we did it in .net, which no one else had done. So the other thing we did, the other two things that were difficult is that we have a server process, and when you're creating these objects on the ground and you're adding scripts to them, and then you're deleting the object,
17:22
well, you've created an assembly and you've loaded it into mono, and then you've deleted the box. You want to unload it, but you can't. So what we did there is that we load two application domains, and we keep track of how many of these junk assemblies have been loaded into each, and when it hits a level, we go, okay, there's 100 junk assemblies in this application domain,
17:40
then we will move, using the same migration thing, we'll move all the running scripts that still exist in that application domain over to the other one in our process, and then we've got an application domain that just contains junk code, and then we can delete that application domain, create a new one, and then start the process again. So that's how we do code unloading,
18:00
and that allows us to run simulators indefinitely without them filling up with piles of junk assemblies, and the other thing we did is we subverted the profiler to do resource limitations. So we want to make sure that you can't just allocate two gigabytes of memory in our simulator from a single script. We want to ration it between the different scripts and the different people that own land in that region.
18:22
So we subverted the profiler, and every time we have a heap profiler that isn't actually doing profiling, it's actually tracking allocations, and then when an allocation reaches a limit, we use Miguel's code to walk the object tree, figure out how big the object actually is, because the allocation size may be way bigger than the actual resident size,
18:40
and then we'll reset the memory down to the resident size, and then it'll grow again, and we'll measure its size, and we'll reset it, it'll grow again, we'll measure its size, and eventually, if we measure its resident size and it's above its limit, we'll go, sorry, you've had too much memory, and we stop the execution. So if you want more on that, go and see the other talk, which is available online. So I'm going to talk about a few details which kind of came out in the last year or so
19:03
before we shipped this, which we haven't talked about to the Mono community. So one of the big problems, one of the big differences between the CLR and the Java virtual machine is that the CLR has managed pointers. So managed pointers are,
19:21
when you pass an object by value, it will copy the object, so you'll end up with a whole object, a complex object on the stack, but then, if you want to call a method on that object, you'll end up creating a managed pointer, which is a pointer on the stack which points to an object on the stack. So with Java, you can go through the whole stack
19:43
and you can go, okay, these are objects, so when I'm serializing this object to this other process, I need to remember to take all these objects as well. In Mono, you can end up with a pointer which points to a value type that's on the stack. So what do you do about that? You can't persist a managed pointer
20:00
between the function invocation because when you return from the function, the stack will go back to where it was and the pointer will be invalid, so you can't do that. So what we did here is that we step backwards. So we've done this stack, we've induced the stack, and we've gone, okay, in okay managed pointer.
20:22
Right, we want to yield at this point where there's a managed pointer on the stack. Well, that managed pointer must have been generated somewhere in the code. So we actually step backwards through the CIL until we get to a point where there's no managed pointers in the type stack, and we go, right, okay, so we actually, in order to re-synthesize that managed pointer, we need to have these objects
20:41
and we're going to apply this set of opcodes to these objects in order to generate the managed pointer. So instead, we're going to copy these objects with this script, and we're also going to copy this small slice of CIL, and then when we get it over to the other side, we're going to take these two objects, we're going to apply those IL opcodes to the objects to re-synthesize our managed pointer on the other side.
21:02
So this is the big thing that we've added to the whole stack storage and restoring stuff. So yeah, I talked a bit about the memory allocation monitoring. That's one of the big things we've been working on recently,
21:23
but I've mostly touched on it, so I'm going to keep going because I want to talk about new things. So with the scheduling thing, this is one of the things we found in Madrid. So Madrid, the monosum in Madrid was totally awesome because we turned up, and we left like three or four days later with our code running ten times faster. And this is why.
21:40
Because, as I said before, the LSL interpreter would check the time between each instruction, and it turns out it's so slow, nobody really cares. But what we were doing with the mono stuff is that we were checking the time
22:00
every backwards jump or every function call when we were doing this, do I need to yield? And it turned out that because we were running jitted code, this thing was so quick that our performance was very quickly gated by get time of day system calls. And so what we did at the monosummit to fix this, after lots of talking about this stuff,
22:20
is that we allow every script to have an adaptive timer check skip value. So it starts off with zero. So your script will start off calling get time of day after every backwards jump or function call, and then if it turns out that we're nearly always calling that function before we've run out of time,
22:43
we'll go, okay, let's skip the next one. So then we'll skip the next check, and if we're still missing, we'll start skipping more checks, and that can go get bigger and bigger and bigger. And so this makes our code go much faster. We left the monosummit in Madrid with our code going 10 times faster. We were very happy. But then when we released this stuff, we realized that actually people were figuring out
23:02
what was going on. They reverse engineered our scheduler in this algorithm basically and went, right, okay, that means I can sit in a tight loop building up an enormous timer skip value by basically sitting in a tight loop that does nothing in between it, build up a time skip for like 200 timer check skips, and then launch into this massive thing where I'm sorting lists and calling these expensive operations, and I get to skip over 200 of them
23:22
before the scheduler will check time again. And so we're kind of like, ah, yes, very clever. We need to figure out what we're going to do about that. And so probably what we're going to do about that is we're going to make sure we check the time after every expensive operation or when we've run out of timer checks. So this means that you'll still be able
23:40
to get the speed up when you're doing math and calculations where you want to stay in the legitted code and not call backwards out into system calls, but if you start doing things like sorting lists and so on, then we're going to say, right, we're checking the time every time. So that was kind of interesting. This was a fun one. So about two weeks before we shipped Mono in Second Life,
24:02
one of our engineers came to us and said, huh, I just had a crash. And when I had a crash, the simulator didn't do its emergency sim state save. So it turns out that what we were doing before is that when our simulators would crash, they'd go, ah, try not to lose any data. So they would try to basically spool
24:21
all of the content of the simulator out to a disk in an emergency sim state file before then crashing properly. Now, this is arguably not a good thing to do after you've had a SegV. You can kind of get away with it if your scripts are 16K blocks, but what was happening is,
24:40
well, so first of all, we were like, okay, what's happened to our signal handler? It turned out that when you embed Mono, it steals a ton of your signal handlers. So you have a SegV, and Mono catches it and goes, eh, this is not a null reference exception, so I'll just do nothing. So this was a couple of weeks before we wanted to ship, so we were like, oh, shit. We looked at the code, and we ended up implementing signal chaining in Mono.
25:01
So what would happen, we made it so that Mono would go, when you embedded it, it would go, are there any signal handlers already installed? If there are, save them away. And then if a signal happens, and we determine that it's not a managed, it's not a Mono exception, it's not a null reference exception in the Mono runtime, it must be some exception in this huge pile
25:22
of horrible unmanaged code over here that's embedding me, then it will go, right, what was the signal handler that it had installed? And it would call that one. So we made it do signal chaining. So if you have a null reference exception when you're running .NET code, then Mono will handle it, generate a null reference exception. If the instruction pointer is outside managed code,
25:45
and it just goes, okay, this is unmanaged stuff that's going wrong here, then it will do signal chaining and it will call the original signal handler. So we did that. Then we realized that, well, things are still a bit different, because it used to be that all of our scripts were just 16K blocks of memory. So when we were doing this emergency save,
26:00
we would go, take a 16K block, and save its disk, and this one, and this one, and this one, and this one. Now we have Mono scripts running there. So we've had a segv. It's gone through Mono signal handlers and gone, all right, this is not a managed problem, so we're going to call the unmanaged signal handler, and the unmanaged signal handler is going, right, okay, I need to save this Mono script, so I need to go and serialize it.
26:21
So we've had a segv. We've gone through the Mono signal handler. We've gone back into the unmanaged signal handler. Now we need to call back into Mono, after a segv, to say, all right, we need to serialize this object so we can save it to disk. It turns out Mono really doesn't like that. We're totally operating past our Mono warranty now.
26:41
We've avoided our warranty. There's already been a segv, and we're trying to continue to use Mono. So it turns out the garbage collector really doesn't like running after a segv. It's like, what the hell are you doing? You're busted. This should be game over. You should already be dead. But we're crashing, so we kind of don't care about garbage collection because we're going to crash in a minute,
27:01
so it turns out that we were able to just turn off the garbage collector, turn off lots of bits of Mono, and just say, please, try and do it. Just serialize this. Just call this serialization function, and then we'll die. So that was kind of funny. This is one of the great things about open source code. Two weeks before we were going to ship,
27:20
we were able to go, ah, Mono doesn't do what we wanted. We should have realized this earlier, but we didn't. But it's just C code, and it's open source. So we were able to implement signal chaining. The Mono code's really nice. It was a pleasure to work with. Then we submitted the patch, which lived in the Mono bugzilla
27:40
for about 18 months, and it got to the point where people were patching our patch in bugzilla because it hadn't been submitted to Mono. So we had this little mini fork living in bugzilla for about 18 months of our signal chaining code, but I'm pleased to say it's now finally in Mono, and so we were able to upgrade Mono again because we had this fork of Mono for 18 months,
28:01
and now our code's in. We can go and get a new version. So that was kind of fun. This is where we got to, so I'm going to pause for a minute because this song's really awesome.
28:39
I'm just watching this fractal being generated,
28:42
and on the right-hand side, I'm able to explore it. I'm going to click on it, and it can redraw the fractal so quickly where I can just zoom in on it and solve it. We've increased the gamut of things that can be implemented in the second line. It runs a lot faster, and everyone's happy. And we can make a video with Jonathan Cawton
29:00
telling me about Mandelboxer. So this is Jonathan Cawton. It's the guy who did Read Your Brains. He's like a geek rock guy. He's really funny, but yeah. This song's really funny. I recommend you go and listen to it. So yeah, and what's actually happening here is I said everything in Second Life
29:21
is a box that you put scripts on, but each of these pixels is a box in Second Life that's been made really tiny. So they've made a kind of pixelated raster screen by just putting boxes together in Second Life and then changing the color of it. So it's completely ridiculous, but it makes for a good demo. So yeah, I'll skip forward. Go and watch the video.
29:41
Go and listen to the song. It's loads of fun. So that could have been the end, right? Victory! We've shipped it. We've got Mono running in Second Life after doing all this crazy stuff for years and years and years. Oh my god, thank goodness. We've done it, right? We can go home. Scripts run faster in Second Life. The scripters are happy. We mostly fix all the bugs. It's mostly a good thing. And when I said there's 80 million scripts
30:00
running in Second Life earlier, 40 million of them are now running on Mono. So hooray! People like it. So that's good news. So that could have been the end. We could have gone right, OK, job done. Let's kind of go and do something else. And that's what we did for about 12 to 18 months. Second Life was growing. We had scalability issues. We went and did some web services for a while.
30:21
It was kind of a nice break from all this fiddling about with virtual machines. But the thing is, we've now got Second Life with this crafty scripting language, C-Lite scripting language, that's really broken and doesn't have many features. And we've got it running on Mono. So it goes faster on Mono,
30:41
but Mono is a lot more than a JIT. It's a lot more than an efficient virtual machine. So what we really, really wanted to do was to add some of the features that Mono allows to our scripting environment to take advantage of Mono. So after doing some scalability stuff and some web service stuff for a while, we went right, OK, we're going to fix this.
31:01
We're going to make our scripting environment better. We're going to exploit Mono. This is going to be great. So the first thing we're tackling is the memory model. So remember I said earlier, LSL scripts are this 16K block of memory. And they're 16K, and that's the end of it. They're 16K, no. Can they be bigger? No. Can they, no. Can we, no. We can't do anything with LSL.
31:21
16K block, it will always be a 16K block. And it turns out that's fine when you're writing a script which is like, I want to make it so that when people sit on this chair, they sit in the right place, or make sure this door opens and closes. It's really great for that kind of stuff. But we've added features like email and HTTP interaction. And it turns out 16K is a real pain in the ass
31:42
when a web service wants to give you a pile of XML. It also turns out that having a heterogeneous list as your only way of storing dynamic amounts of data is also a really big pain if someone gives you a huge pile of XML. So when you're creating scripts that interact with Second Life, LSL and 16K and DSLs are all right,
32:01
but when you want to open Second Life up to the outside world, 16K is a real pain. And it turns out that what happens is lots of people build a script in Second Life that acts on Second Life. Then they'll build a web server whose sole purpose is to proxy requests from that script, get a huge slab of XML in from the internet, turn it into a comma separated value list
32:22
so that it can be sent back to the script and kind of squeeze functionality out of this tiny little amount of memory that we have. So it's really not good. So especially for breaking down walls between Second Life and the web, 16K is a real pain. So we wanted to get away from that. And there's no reason that monoscripts need to be 16K, right?
32:41
They're not a 16K block. They're a graph of object references. That graph isn't like within reason. So one of the projects we're working on at the moment is the script limits project. And what this is doing is it's saying, for every square meter of land or for every avatar or for every whatever you want to think about it, we're going to give you X kilobytes of memory.
33:03
And that's going to be a pool that your script can draw from. And what that means is that your script can say, I don't want to be 16K. I want to be 128K. Or I want to be 4K. Or I want to be 4 megabytes. And depending on the amount of resources you bought in Second Life or the amount of resources you have available on your avatar,
33:20
your script will be able to say I want to be bigger or I want to be smaller. And that's going to be really great. It's going to mean that lots of these proxies are going to be able to go away. You're going to be able to go, I want to reach out to the web, get a huge pile of XML. I don't care that it's a megabyte. I'm going to work my way through it, find the data I need. And I can just then build an application in Second Life that talks to the web without having to be a web admin,
33:42
without having to run a server, without having to run all this external stuff, which would be great. So that's what the script limits resource pools and big scripts is about. Efficient scripts is kind of just an optimization in a model which was that previously, if you wanted to make an object which would resize itself, you had to put script in every single part of that object.
34:03
And then you had to send messages between this kind of graph of scripts to say, okay, everyone make yourself 80% smaller and kind of reset yourself. So efficient scripts is just saying, look, we're going to make it possible for a single script in an object to operate on all of the linked objects in that object in Second Life.
34:20
So the first thing we're going to do is we're going to sort the memory model out, and this is going to be a huge, huge win. One of the problems at the moment is, although every script is limited to 16K, the amount of memory that scripts as a whole can use in the simulator is unlimited. So what happens is that people go, oh, I've run out of memory in my 16K script, so I'm going to make 400,000 of them,
34:41
and then you end up with the simulator just kind of bogging down and using, you know, going into virtual memory and swapping and it's all just totally horrible. So this is going to set a hard limit on the amount of script, memory, and the entire simulator, but within that block of memory, scripts will be free to say, I want, you know, half a megabyte or a megabyte or whatever it is that they need. So that's the thing we're working on at the moment.
35:00
The next thing we're going to work on is C Sharp. Hurray! Finally, a proper programming language in Second Life. So what's C Sharp going to give us that LSL doesn't have? Well, for a start, it's going to give us arrays. We haven't even got arrays in LSL. It's going to give us primitive types. So having a byte array when you want to be able to do, like, cryptography or talk to the web is quite handy.
35:22
Enumerations, user-defined types, exceptions, all these things that you take for granted that people in LSL don't have, and they have to kind of scratch their head and kind of jump through hoops to make work. And also there's a big ecosystem, right? There's a room full of people here at an open source conference talking about C Sharp. At, you know, Microsoft conferences, there'll be tons of people talking about C Sharp.
35:41
There isn't an LSL developer room at FOSTEM. There aren't huge amounts of LSL code out on the web. I did the, you've probably seen the kind of programming language popularity thing, which goes, you know, basically do a search for programming web pages and then figure out which is the most popular language. And, you know, C Sharp is like,
36:02
has five percent of the hits on the web, which is pretty good. It's the same as Python, not as many as Java, not as many as a couple of other languages, C and stuff. If you do the same job with LSL, you find that LSL is around about the hundredth most popular language in the world. Now, that's pretty good, because, you know, second life's been around five or six years, whatever.
36:20
There's not that many people who program LSL. Having the hundredth most popular language in the world is pretty good, but it means that you can't just do the kind of code by Googling that we're all really used to, right? You want to be able to go, I've got this job I want to do. I'm going to Google for that. All right, there's a block of code. I'm going to base my code on that. Or if it's open source, I'm going to use that code. That's great. You can't easily do that with LSL.
36:41
So the ecosystem is a big thing. We did an Amazon search, and there's like 800 books on C Sharp on Amazon, and there's 28 books on LSL on Amazon, and most of those are kind of general-purpose guides to second life. So this is going to be a big deal. The ecosystem is a big deal. So what do we need to do to make C Sharp work? Well, you'll notice in this part of my talk,
37:00
I have lots of question marks, because I don't completely know, and one of the reasons I'm here is to find out. So if you know, if you can get rid of a question mark for me, then that would be great. So first of all, we need to complete our U-thread injector. So at the moment, we've implemented the tool which takes an assembly and rewrites it to put these yield points in and these post fixes that go and save code. We've implemented enough of that to support LSL.
37:22
If we're going to support C Sharp, we pretty much need to support the whole of the CIL instruction set. So we need to complete the U-thread injector. So first of all, how big of a job is that going to be? Are we going to hit more managed pointer horrors? Are there going to be opcodes which go and execute delegates? Are they going to be a pain to deal with? I don't know. Hopefully not.
37:42
The next big question is are we going to continue using the abandonware academic framework rail, which we currently build our U-thread injector on, or are we going to use Cecil, which in the time we've been doing this has come on from kind of a nice idea to something that's being used for lots of stuff in mono. So are we going to move to Cecil?
38:01
How big of a deal is that going to be? Miguel, please ask somebody to write some documentation for Cecil because it's... I've done some googling. I couldn't find... I was like, how do I use Cecil? That would be good. I would like to know how I use Cecil and how much different it is from rail so we can decide whether they're going to move.
38:21
And one of the big deals there is are we going to support generics or not? So rail will rewrite version one .NET assemblies, but it won't rewrite assemblies that have generics. And so if we don't move to Cecil, we're going to be supporting C-shop one, which means we won't get a lot of the cool Chinese stuff that Miguel talked about earlier.
38:41
We'll get lots of benefits over LSL, but we won't get the whole shooting match. So the next thing we need to do is we need to build a sandbox. So one of the reasons we're doing this now is that finally mono has a bytecode verifier
39:01
and a CoreCLR security sandbox. It's built for Moonlight, but we're a lot like Moonlight in the sense that we're embedding mono in a different process and we are running untrusted code. So we need to do a lot of the same things that Moonlight needs to do. So how is that done? How do we hook into it? We embed mono at the moment.
39:21
I have C-shop assemblies that make internal calls. Mono's totally happy with that. I need to be able to flick a switch somehow to say don't be okay with transparent code that makes internal calls, and I expect my simulator to not start up. I expect it to get to the point where it loads this assembly that has internal calls
39:41
and to go, bah, this is not marked as security critical, so I'm going to explode. So how do I do that? So is CoreCLR security going to be enough? How do I do the assembly markup? I need to effectively define another profile, which is like the Silverlight profile, which goes, these are the things that you can use.
40:02
These are the assemblies that it's okay for scripts to access. These are the things it's not okay for scripts to access. I want to be able to take the whole of the .NET framework, put it through a big sausage factory and plop out the other end this tiny little thing that goes, you have these four assemblies, these ones are security critical, these ones are transparent, and whatever.
40:23
So how do I do that? I need to find out. And some of this I can read docs on, but if you tell me, it's easier, because I don't have to read this. Just tell me, it'll be easier. So another thing we need to do is figure out what our C Sharp API is going to look like. So for a start, we're going to have all of the methods available to scripts that currently are available to LSL scripts,
40:41
and in fact, a lot of this already exists. A lot of this API already exists. We compile LSL scripts down to IL, but then we have a bunch of C Sharp API that those scripts call to call back into the simulator. So we already have our library of LL foo methods, like LL say, LL set texture, or whatever. They already exist.
41:01
It would be great to give people systems.collections. I don't see why not. Hash tables would be great. Array lists would be great to people who've only had hash genius lists for a while. This is going to be awesome. Systems.security.cryptography is a really good one. I'll show you, hopefully, if I have time, I'll show you a demo later of using that. It means that you can just go, you've got byte arrays,
41:20
systems.security.cryptography, you can go a few calls. You can then go and talk to secure websites using OAuth, and it's like 10 lines of code. So we'd like to have that. It would also be nice to have some XML stuff. So which XML things should we make available to scripts? It would be nice to make some more web functionality available to scripts. Which ones should we do there?
41:42
We probably don't want to have remoting, but anything which you can go and talk to the web would be great. So I talked about the .net Silverlight machinery. How does Mono turn the .net framework into the Silverlight framework, and how do we author the stuff we need to author to make our own profile, effectively?
42:01
So types are kind of interesting, because, as I said earlier, LSL is a DSL, so you can do, in LSL, a list is one of the six magical types. There will only be six. So you can go, I want a list L equals foo 42, right? I'll create you a hash genius list. It's a pretty nice syntax. It's a lot nicer than what we currently have here, which is, I want an array list L, which is a new array list,
42:21
which is made from a new object array, which contains foo and 42. That's pretty horrible. So maybe we want to do some of the kind of funky API, you know, chainable API calls, so you can say, okay, I want a new list, add a foo and add a 42. This stuff gets interesting when you get to, we have lots of method calls which take hash genius lists as parameters, which is really horrible.
42:41
I don't like it, but LSL is so limited that sometimes you have to. For example, in LSL, when you want to make an HTTP request, you go, L HTTP request, you give it a URL, then you give it a list of optional stuff, like HTTP method equals post. Well, this gets really horrible in the current C sharp version because you, same problem here.
43:00
You go, okay, I can give it a URL, but then I need to give it a new array list of a new object array over HTTP method post. So, but we can potentially do better than that by making kind of specialized builders for particular functions, right? So we can make an HTTP builder class in C sharp, where we'll go, okay, I want a new HTTP request,
43:21
dot URL, here is a URL, that thing can throw an exception if the URL is wrong or malformed, dot method post, this thing can throw an exception if post is not a valid method, dot make the request. So at the moment what happens is you give a list of objects to a library call, and if you get it wrong, most of the time it will just silently fail. Whereas if we use builders, we can say,
43:41
these are the parameters, these are the types of the parameters, we can strongly type each parameter so that you don't, for example, pass, you know, this is a string when it actually is a constant, and we can make it throw exceptions at the right time. So we kind of, we need to decide about that kind of stuff. C sharp event handling, this is what Miguel designed in Madrid, which we currently still have, and it's working quite nicely.
44:02
So one of the ways things work in Second Life is that the set of events you handle control the UI to the scripted object, right? So if you add a touch handler, then if you hover over the object, your mouse will turn into a finger because you can touch it. And the way this is handled in LSR is you do these state changes. So you can go from a state which doesn't handle an event
44:22
to a state which does handle an event, but it's a bit icky. So the way we're currently planning on doing this in C sharp is that we'll go, right, I've got a script, it can either override or it can use delegates for event handlers. So I can override the onRes event, which is called when my object gets rezzed, which is a term from Tron out of my inventory.
44:42
So that's just a straight override. But then I can say touch, which is a delegate in the parent class. I can say touch is a new script touch delegate which points to the touch method, and then the touch method can just go, hooray, I'm turning myself off. And then it can set the touch delegate in the parent to null. So then you can have straight override event handlers,
45:03
which is what you expect, plus you can use delegates to do the dynamic event handlers, which you need to control the UI. So is that the right model? I'd like to know. Instead of these being delegates, should they be events? Should we be going plus equals some event handler? What's the overhead of events rather than delegates? This is the kind of thing we're currently thinking about.
45:22
So C sharp libraries, at the moment in LSL you don't have libraries. So if you want to add some functionality someone's existed to an LSL script, you have to copy and paste it into your script and compile it, which is just horrible. It would be much nicer to be able to distribute inside Second Life C sharp libraries, which I can just import and then just call.
45:41
But if I'm going to do that, what's the scope? How do I build the command line in Second Life when I don't have a command line interface? How does naming work? If I create a class called foo and then I create a different class called foo or somebody else creates a class called foo, how do we use namespaces to tell the difference? And also, how do I version these things and choose which version I'm going to compile against?
46:01
So lots of questions there, no answers. So that's the stuff we're working on at the moment. If we'd like answers to those questions, then in the even more glorious future, maybe we can get to F sharp, boo, and Haskell on the static side. It would be great to get to Iron Python and Iron Ruby, but at the moment we only can inject our Uthread code into assemblies
46:21
that have been generated from static languages. So the languages like Iron Python and Iron Ruby generate code at runtime, and we need some hook to be able to go, okay, we're going to rewrite that code as well. IDE integration would be great. So we currently have a little text box. It would be great to have MonoDevelop or Visual Studio be able to use these Second Life scripts
46:42
and create Second Life scripts and potentially debug them as well, because I'm not sure we're going to get to the point where we can debug scripts live running in Second Life, but if you could create a script in Visual Studio and have a bunch of mock frameworks that can mock this stuff up, then you could kind of unit test and debug your script in Visual Studio and then press a button and have it uploaded to Second Life,
47:01
which would be great. So how can you help? We're going to publish the C Sharp API soon, so I'd love you to have a look at that C Sharp API as C Sharp programmers and just go, that smells a bit, that's not good, that should be something else. Some of the questions I've asked here, have a look at that, tell us if we're going to do something wrong. We're hopefully going to have a public beta this summer
47:22
if we get all these questions answered. If you would like to, as an open source developer, if you'd like to hack on Second Life, more extensively we have a Snow Globe open source viewer. That's been open source for the last year or so, and that is our open source fork of the viewer, which people can add features to, and we kind of have very quick releases of Snow Globe,
47:41
and then those features eventually migrate into the mainline viewer, but it's a workplace for people to do experimental features in, so please play around with, download Snow Globe, build it, play around with it, and hopefully we can talk now or later, because I'm running out of time, but hopefully we can get some questions. So thank you very much. I'm Jim Purbrick. In Second Life, I'm Babbage Linden.
48:02
I blog at lindenlab.com. I also blog at home. We've got a couple of minutes. Have we got time for a demo? I'm looking for Ruben now. Yeah, well, we're running 10 minutes behind the schedule. We're running 10 minutes behind. Until 10 past. What time is it? It's half past now. Yeah, so 10 minutes.
48:21
Okay, so let me do a quick demo to show you where we are, because it wouldn't be a proper FOSTEM talk without a demo. I did try this earlier, and it mostly worked, so let's give it a go. So if you tried doing this at Microsoft, it doesn't work, because they have firewalls, but this is kind of free and open source, and everyone's got their networks hanging out,
48:42
so I tried it earlier, and it did work. So this is the Second Life viewer. I'm going to connect to the region that was last in, and hopefully this will work.
49:02
It's looking promising. So I was telling Miguel about this group I created yesterday. I have a mono equals monkey group in Second Life, which I have above my avatar's head, because if you talk to an American, there's a disease.
49:20
So I'm doing my bit to try and tell people what mono actually means. So this is Second Life. This is my avatar. So this is a slot machine in Second Life. I've got a couple of scripts on it. Let's have a quick look at them. So the first one is a Twitter OAuth client.
49:41
So this is kind of how you do libraries. This is LSL. This is how you do libraries in Second Life currently. So you basically have to define a protocol. So you define a bunch of integers, and then I've got some helper functions there, which are going to build my message.
50:01
So when my object gets created or read into the world, I call the init function, which sets up the OAuth consumer keys and such. And then when you touch the object, it's going to send a link message, which is kind of like an internal message bus within the object.
50:21
So it's going to say, tell this primitive the message 99903, which I defined at the top, and I'm going to give it a string, which is the message I want it to send to Twitter, and I'm going to give it a toucher, which is the avatar. So let's see if this works. If you have Twitter available, follow SLTester.
50:42
All right, so that's all you're doing there. I'm going to close this. So that's the LSL script, and it's sending effectively a message to the other script in the object. Now, the other script in the object is a C Sharp script. Hooray!
51:01
So this is the nice thing. So at the moment, we've got no sandboxing. This is an internal prototype, so I can do things like use whatever I like. So I'm using system.collections. Hooray! I'm using systemsecurity.cryptography. Hooray! I'm defining my own types for tokens and caches of tokens. This is all awesome.
51:21
I mean, if you've ever scripted anything in Second Life, you'll be quite excited at this point. So I've got a load of code. Now, there's one other bit of this code that I want to show you, which is... As you can see, this is our wonderful IDE. Please replace it with something else.
51:40
So this is the other bit of code that I want to show you. So this is how to do HMAC, which you need to talk OAuth in .NET. You can just go, you know, I want a system text ASCII encoding. I want some bytes from my string using that encoding. I want to get a signature bytes,
52:01
which is my message, in the same way. Then I want just an HMAC SHA-1 object, which is defined by the .NET framework. And then I want a byte array, which is the hash of that message, and I want you to compute the hash on this message using this key. So this is five lines of code, and I borrowed it from the Internet.
52:22
Doing that in LSL took the whole LSL community about two months. So I started trying to build this in LSL at Christmas, and I spent three days on it, and for whatever reason, it turns out you can't use our library functions for SHA-1.
52:40
There's no byte array object, so you have to store things in lists of integers. You have to convert between strings and lists of integers and back again and base64 strings and so on. I spent three days on it, and they went, OK, this is my Christmas holiday. I am going to have a glass of wine and do something else. So then I told the LSL community,
53:01
you know, the LSL script is, when I got back to work, I said, look, I've tried to do this. This is the code I've got to. The whole LSL community has been hacking on it for the last two months, and last week they got a version of it that worked, right? So that's the difference here, OK? You get a load more functionality in C Sharp, but you can go, I want to build an OAuth library. You can go and find the code,
53:21
and you can write five lines of C Sharp instead of having to re-implement SHA-1 in a language which is relatively slow and doesn't have byte arrays, and then implement HMAC on top of SHA-1 in a language that doesn't have byte arrays and doesn't have any way of converting between strings and binary values.
53:41
It's absolutely, it's just, it's unbelievable that people have made the incredible things that they've made in Second Life with these tools, and I'm really glad that we're going to give them C Sharp. So anyway, that's the code. Let's show you it working. So hopefully this will work. So, I'm going to talk... SL tester?
54:01
SL tester? SL tester, yeah, all lowercase. Tester? Tester. T. That is a T. SL tester. So, I'm going to click on the box. The LSL script is going to get the touch event. It's going to send a message to the C Sharp script. The C Sharp script is going to go and talk to Twitter.
54:21
And it's kind of interesting, because this box is acting as a HTTP client, because it's talking to Twitter web services, an HTTP server, because it's registering a URL that's been called back by Twitter, and an HTML browser, because it's going to open up a page to say, you know, is this okay? So it's quite a funky script anyway, but it's much, much easier in C Sharp.
54:41
So I click on the box. It says, Load this web page to authorize Twitter access. So I open the web page, and, you know, you all know about OAuth. The important thing here is that I'm talking to Twitter.com. I'm not talking to my LSL script. So I'm avoiding the password anti-pattern. I'm not giving my Twitter username and password
55:01
to anybody apart from Twitter, right? So that's the whole point. People have built stuff that talks to Twitter from Second Life before, but they've used the password anti-pattern, which is not a good idea. So there's my username. There's my password. So I can choose to deny or allow this thing, so I'm going to allow it.
55:21
Then Twitter is going to call back my script, redirecting me back to the application. This lovely web page, ta-da, was produced by my LSL script, and then it's asking me, Do you want to show the status update? So if I say, Go to page, Babbage Linden gave a demo at FOSDEM in Second Life here. Hooray! We've talked to Twitter.
55:45
So the other nice thing about this is if I click on this link, then it's going to go to slurl.com. Slurl.com is a service we provide that gives you teleport locations into Second Life on the web. So if I click on this link,
56:04
hopefully... So anyway, that doesn't seem to be working. So if you go to Twitter, if you click on that link, then it will give you a map of Second Life pointing back to the location I'm in Second Life, which means you can come and join me. So Twitter's real time, so I can be doing some cool stuff in Second Life.
56:21
The thing in Second Life can go, Hey, your friend did something cool in Second Life and tell your friends on Twitter. Then you can click on a link and you can come back into Second Life. So this is quite fun anyway, but it's also a good demo of why C Sharp in Second Life is a good thing right now. So, hooray, the demo worked. Any questions? We have three minutes, I think.
56:42
Monosecurity enable course COI. Okay, please send me an email. Hooray! That's one question mark done. Any more question marks we can get rid of? Does this API look reasonable, or does it look terrible? Is there anything that's, as a C Sharp developer, is there anything that makes you go, Ah, that's horrible, please fix it. It was designed by Miguel,
57:01
so it may be terrible. The object sensor 3, it automatically initializes any object that implements an innumerable and open aspect. So you can just say, hooray, this parenthesis, and you're going to embrace the data, and it will just add to the list. So that won't be as obvious as it is right now.
57:20
So if we can support C Sharp 3, if we can use Cecil, Well, you should support C Sharp 3. Well, I'd like to, but we need to use Cecil, so then we need to, like, So you need to use Cecil, and I'll make sure that we document Cecil. Yeah, that would be cool. Somebody's going to be very happy next week about that. Or you can use IKVM reflection. Yeah, this is mad enough already.
57:42
Yeah, we'll document mono, Cecil. Yeah, that would be cool. I mean, Cecil looks totally awesome, and all the conversations I had with JB have been really good, so, I mean, Well, the excuse that developers get usually is, well, the API is still changing. It will be documented.
58:06
So why is not everything running on mono yet? You mentioned that most of the stuff is now running on the mono VM, but some stuff still use your old legacy interpreter VM? Yeah, I mean, so the way we implemented it
58:21
is we didn't, just to be conservative, we didn't automatically convert old scripts over to the new VM, okay? So if a script is running on the old VM, and you wanted it to run faster, or you were doing a new version, then you could open source code, and you could say, I want to compile this command. But we didn't automatically convert things that were running in second life already.
58:41
So there's lots of, there are lots of scripts in second life, which are running perfectly fine on the old VM, and, you know, the people who are using them don't want to, you know, maybe can't edit them, and so, you know, those will continue running on other sites. We specifically made the choice that only people who could open, look at the source code, and we're developing the script,
59:01
could convert things to mono, because otherwise you'd like, you know, especially when we still have bugs in the mono implementation, you might have a car in second life. It works fine. You bought it for like, you know, $500 million. You say, all right, convert it to mono. I've heard that's a good idea. You convert it to mono and it explodes, and then your car's broken, and you go back to the person who sold it,
59:20
and they say, why the hell did you convert it to mono? So we encourage people to create new versions of their objects running in mono and sell the new versions, because it's more efficient. But, you know, that hasn't happened everywhere, and even where it has happened, there are people who are happily using their LSR scripts from before anyway.
59:41
So those are all like three-year-old scripts? Well, there are some people who are using, still using some LSR scripts. So if you, because of the memory model, there are some things where, if you're using a hedge genius list, it uses up less memory if you run it on LSR.
01:00:00
than if you run it on mono because mono is using 32-bit pointers and 64-bit pointers, whereas the internal pointers are 16-bit. There are corner cases where LSL is more efficient, but generally mono is more efficient. And that's generally because each LSL script is this 16K block, so even if it's using 2K of memory, it's allocating 16K of memory from the simulator
01:00:23
and it's just got this big block of zeroes in the middle. Whereas if you write a mono script that just uses 2K of memory, it will just allocate 2K of memory. I would like to allow people to use as much as possible of C-sharp,
01:00:46
and a lot of what we're doing now is going to be defining what can we possibly allow people to use in the background. There may be some things that we can't allow because of the way we reroute the segments, yes.
01:01:06
You're probably not going to be able to go add this to the workable, because instantly you've just created a load of work somewhere that we wouldn't be able to track it. So there will be some things that we can't do. Thanks for having me.