Mono and coding in other languages?

I'm back from a long hiatus and am wondering now what the status on this whole .NET thing is. Apparently Philip Linden made a post two weeks ago saying the Mono integration is close to be put onto the main grid.

What means "close" and when or how will we be allowed to write code outside SL in other languages, i.e. C# or C++/CLI?

Thanks.

No info on the CLR integration status or timescale, sorry, but just out of interest, what do you see as the advantage (for the scripter) of being able to code for SL in C#, C++, etc? I would of course love to see script execution speed increased, which I understand to be one of the advertised benefits of the new runtime engine, but apart from that I see the primary limiting factors in terms of current LSL scripting being the somewhat opaque and inconsistent nature of the runtime library (particularly with regard to the physics/vehicle functions), and the script memory limit. From my (admittedly limited) experience of LSL coding, I can't see how you'd actually find enough space to define any complex application-level classes or structures, let alone use them, even if they were made available.

If the new runtime comes complete with the ability to link to pre-compiled user-written library functions, or supplies a whole new raft of built-in (useful) function calls, or removes the per-script memory limit, then I can see the benefit - however I have not seen any indication in the rather vague posts on the subject I have read so far that might be the case. The way I understand it atm (and I may well be wrong) is that all that's going to happen (from the end-coder's point of view) is that you will able to choose your own preferred syntax for expressing simple loops and conditionals around the same set of LSL function calls, within the existing per script memory limits.

You can get the latest info on Babbage's blog

http://secondlife.blogs.com/babbage/2005/12/mono_log.html

While running scripts in other languages is a possiblity that may open up, there is currently no plan to have us writing in anything but LSL.

The biggest change is what the scripts are being compiled to and having CLI byte code running next to LSL bytecode.

DO YOU FEAR THE "BIG REBOOT!" MUH AHhhhahahaha.. ahem...

It's cool.

The latest word from the Lindens is that they are currently only working on making LSL faster. Providing an API and allowing people to upload compiled code is not being actively pursued.

I don't like LSL. It's syntax is really weird and inconsistent. --edit: And don't get me started on these lists and lack of proper arrays.

Also, they were actually considering the idea to inject external compiled CIL, did that one get scrapped or why isn't it being pursued anymore?

"They were considering" doesn't mean "they were actively pursuing".

I'm sure they're still considering it, but it's a hella lot of work for something that's not going to directly benefit LL and will open a huge support and security can of worms.

They have to document and standardise the API at a MUCH lower level.

They will have to freeze their API a lot harder than it is now. For example, if they need to change the details of how event handlers work they could do it... they'd have to crunch through the whole asset server and recompile every script, but they could do it... it wouldn't in principle be any different from what they're doing in 1.9.1 to get rid of PRIM_TYPE_LIGHT. If they don't have the source to the CIL, they won't be able to do that any more.

They have to document and standardise llFoo calls for all the hidden layers of stuff that the LSL compiler's hiding from people at the moment... things like <wavylines>

llSetEventHandler(address function, integer handler_name);

And giving people lower level access means that it'll be easier for them to not only exploit security holes, but also more easily cheat on their resource allocation tricks. For example, right now if they delay a call for 10s you have to make a new script and write a bunch of message handling to get around it. Imagine if you could just create a thread to make that call...

The lower level APIs have to be written one way or another, for the LSL2CIL compiler, because it has to link to something in the code it outputs. And there's this thing called versioning, it works pretty well in .NET and also Mono. And there's also this thing called code access security, where you can outright deny access on function level basis if the user code doesn't have the appropriate runtime rights. Using CAS you can prevent user code from accessing the i.e. threading library, or the other way around, telling the code which classes or assemblies they're actually allowed to call.

LL is currently working on code security, Philip said in the recent audio town hall. I beleive the issue is in validating code. The speedup that we see is in the actual mechanics of executing LSL, not so much in what is being executed. Things that are currently slow, will remain slow.

Yes, but they don't have to be publishable quality APIs, and they don't have to be documented, and they don't have to be stable. Versioning actually makes this a bigger issue, because it lets them change the internal APIs with every new release without breaking existing code. They can't do that with published APIs, particularly ones that have to be safe from hostile programmers.

I'm not saying they couldn't do it, I'm saying that it wouls require a lot of work to create, publish, document and maintain these APIs. I've done it, and the change in effort as you go from "internal routine" through "shared routine", "internal API", "API published to partners", and "API published to customers", to "API published to potentially hostile customers" is like ten times as much work getting ready for release for each step.

This is no doubt one reason why there's still things in LSL like "a-1" being a syntax error.

Code access security is useful, of course, but it's a tool to use in solving this problem: it doesn't make it go away, it just converts it from "practically unsolvable problem" to "expensive problem"...