Second Life In Mono

Orientation Island with all 700+ LSL scripts compiled to CIL, assembled in to CLR assemblies and running in the Mono VM embedded in the Second Life simulator. The Mono scripted birds sing and the Mono scripted hands spin and go "bing" when you touch them. There's still lots of bug fixing, optimisation and integration to be done, but it's looking good.

Comments

[blaze]

can you give us a quick rundown on how mono is going to work? Will we be able to program in different languages that compile into the CIL or is everything still going to be written in LSL?

This will have a major impact on classes, documentation, so any heads up you can give us now will save us all a lot of grief in the future.

[Bino Arbuckle]

Awesome! Hopefully this will lead to a scripting renaissance of sorts; an expanded programming environment allowing older scripts to be revamped and new ideas to finally be put into place.

[Tony Walsh]

Hi,
What's the general road map or timeline for Mono implementation? In other words, when will we see it rolled into a public version of Second Life?

[Jim Purbrick]

The first step is to get Mono working as a replacement for the current interpreter. That now looks like it's going to be possible, but there is still a lot of work to be done. That should get us a faster VM, which will be worthwhile in itself.

Longer term we'd like to be able to allow other languages that target the CLR, like C#, VB, Boo, Nemerle and Python to be used to script Second Life and/or to extend LSL to take advantage of CIL features like objects and arrays. There are still lots of decisions to be made here. Would it be better to allow multiple languages in SL or to improve and extend LSL? Is LSL's strength it's simplicity? We'd also like to open up some of the Mono libraries for use within Second Life.

[blaze]

I think everything depends on the memory constraints.

If the memory contraints are going to continue, then I think improving LSL to have language artifacts for IPC seems like a good idea.

For example, it would be nice to be able to do a cross process procedural call without having to set up link messages.

eg:
let's say we had a procedure call like:

call dequeueData(scriptName, link, params)

the call keyword would turn it into an RPC call through a link message and in another script we could define a function like

link dequeueData(scriptSource, link, params) {
.. regular code
}

Where the "link" keyword would tell the compiler that really it's supposed to listen for an RPC call and that it's listening for link messages.

C# and other languages don't really have these type of artifacts because the memory contraints aren't really a factor.

BTW, how are the memory contraints working with mono? Is that going to be an issue?

And will memory contraints ever be taken care of at some point in the future?

[Elle Pollack]

What about having any sort of a LSL-to-Mono translator to aid in the conversion? I know of at least one text-based world that intends to do something like that when the coders release the next version in Java and need to translate its user-coding languages into the new system.

[Elle Pollack]

What about having any sort of a LSL-to-Mono translator to aid in the conversion? I know of at least one text-based world that intends to do something like that when the coders release the next version in Java and need to translate its user-coding languages into the new system.

[blaze]

Yeah, another possibility is to add more tools for automatic upload of LSL scripts.

This way we can develop languages which compile into LSL.

[Prokofy Neva]

Could you comment on whether or not all the existing scripts in SL will simply stop working when you make this switch? Or only work if their creators come on and rework them? Or only work in 75 percent of the cases? Or work, but be clunky and not do stuff like recompile? Let's hear your prognosis on the impact on businesses of this switch from one language to another. We know you've given a one-liner on the Herald blog that you are "working to make this transition smootho" but I want a really honest report on how the world will really look on "The Day After" not about how "you are working to make it smooth".

For example, we already have an issue where certain scripts or functions on scripts "break" with the introduction of each new game patch (yes *game* is was I would call something that might destroy many businesses when it makes major changes all the time -- in fact I'd call that game "Russian Roulette" lol). Only if the scripters come on and rework them and take ownership of this problem would there be amelioration of this "Day After" -- sounds like.

But a widespread phenom in SL is oldbies and even talented newbies who leave the game after putting out stuff that they collect money on. They go off to play WOW or go back to college or whatever and they aren't there to do customer service -- they come in to cash out their vendors and the furious IMs to them from angry customers are merely capped, or they answer them with comments like "well, it works for me". They hate customer service and view it as something for chumps.

So who is going to take care of all those broken scripts? Seems like the rational thing to do right now until this transition is made is never to buy a single scripted product ever again unless you know the creator is committed to the world and has a hands-on, customer-service approach to it.

[Jim Purbrick]

Blaze, there will be memory constraints of some sort as server memory is a scarce resource, but moving to Mono potentially allows us to move from the current model where each script is a 16KB blob of bytecode, stack and heap to something more flexible. The current model of chaining together a load of scripts to overcome the memory limitations is a pain to manage and ends up wasting the memory that you're running out of in the first place.

[Jim Purbrick]

Elle, we already have an LSL to Mono translator. The LSL compiler can generate LSL bytecode and/or CIL assembler. The Mono Orientation Island was running Mono bytecode produced by compiling the original LSL source code for the Orientation island scripts.

[Jim Purbrick]

Prok, all the existing scripts will not stop working when we make the switch. The LSL source for existing scripts will be compiled to Mono bytecode and then run on the Mono VM. There are a number of ways this can happen. The simplest way is that we just set a batch job running compiling all the existing source then switch VMs and load the new bytecode. By switching to Mono on a preview grid before the main grid people would have time to test their scripts before we switched the main grid. I currently have scripts running on Mono side-by-side with LSL2 interpreted scripts, so it may even be possible to run both in parallel for a while to make the migration easier.

[blaze]

Which mono VM are you using? How stable is it? The LSL VM as been through quite a lot of testing..

[StrifeOnizuka]

Wouldn't it be better to compile the bytecode to Mono? Some scripts text has gone missing, and by recompiling the bytecode it will break all existing products that rely on the data that is stored in the scripts memory. All Darklife backbacks would be rendered dead, as would all scripts that check owner on state entry.

[StrifeOnizuka]

This will also effect all scripts that use PRIM_TYPE that were compiled before SL 1.5
As with 1.5 the value of PRIM_TYPE was changed from 1 to 9.

[Coyote Ingmann]

If SL is going to a mono VM, I'd really *really* like to be able to use non LSL languages like Python. I already know Python and I'd be able to get scripting a lot faster.

Also, I don't know about other players, but given a choice of a language that only works in one environment, or one that works in a lot of places, I'd rather learn the one that offers me more flexibility.

Finally, I'd rather LL spend resources on exposing game engine elements to the underlying Mono VM than on implementing yet another language feature, like say arrays.

[KaiNyak]

Personaly I think LSL is best for the Teen Grid only because some of us have learend what we have never dreamed of learning *excuse my spelling sry*.All im saying is if you switch some people may quit cause LSL is best for noobs and i myself love lsl.You have created LSL and people enjoy using it cause there knowing of other types of compiling is probly 0 corse it might be better cause if they had the dream for creating a game there in the right place but i think SL needs to stick with LSL for the TG i meen i dont go to the MG for few years LOL.Im also guessing if you switched the compiller we will lose all of our old scripts I.E. LSL scripts and start all over?

[KaiNyak]

Personaly I think LSL is best for the Teen Grid only because some of us have learend what we have never dreamed of learning *excuse my spelling sry*.All im saying is if you switch some people may quit cause LSL is best for noobs and i myself love lsl.You have created LSL and people enjoy using it cause there knowing of other types of compiling is probly 0 corse it might be better cause if they had the dream for creating a game there in the right place but i think SL needs to stick with LSL for the TG i meen i dont go to the MG for few years LOL.Im also guessing if you switched the compiller we will lose all of our old scripts I.E. LSL scripts and start all over?

[KaiNyak]

oops sry comp messed up

[vanler odets]

I think the idea of mono is ok but it all depends is everything strill going to be written in lsl or are we going to have to learn mono as the new scripting language because that would suck consdiring the amount of hours I spent in the teen grid learning lsl for Dark Wind and thinking of every one elses hard work they put into there items it would suck to see it disappear like that and we would have to start from square 1.

[Jim Purbrick]

KaiNyak and Vanler, it will still be possible to use LSL to script Second Life. Other languages may also be available, but LSL will stay. Current scripts will also continue to work, they will be recompiled from LSL source to run on the Mono VM.

[Huns]

It's not a good idea to recompile all scripts from source. That would effectively cause every script in the entire world to lose its state. For some it wouldn't matter. For others... it could get extremely ugly.

You will need to either allow current scripts to keep running on the current LSL2 VM, or figure out some way of translating a running LSL2 memory image into a running Mono memory image.

[seer]

I for one can't wait for mono to come in. yes they will probably have to run the Vm's side by side but i will be converting all my scripts to c#. All the crappy workaround to features that are built into most languages liek c# but not in LSL. Man the speed increase just by fixing those would be massive let allow the VM been faster as well!

I would eb more than happy to test the system and would love to see what the c#/mono api's for second life look like

[Zenigma Suntzu]

You should deprecate (but still support "forever") LSL with only bug fixes, and move to the Mono languages. My preference would be Python.

There's no way you can be as good at language design as the Python community because you don't have the time, and you pick up all improvements going forward for free.

Then, you should concentrate on improving the SL API and not worry about language features at all.

[Jim Purbrick]

Zenigma, Yes the goal is to continue support for LSL but to allow other languages rather than extending LSL. Similarly we hope to leverage parts of the existing .NET framework APIs as well as the Mono VM technology itself.