Mono on the beta grid

I was under the impression that after everything is ready for full production, all LSL2 scripts would be recompiled by the system and still keep their running states. Is this true?

According to the wiki; when we are in the MONO enabled sims in Beta grid, we will have to use a mono enabled viewer and there will be a check box to compile it to MONO. If the box isn't checked it will compile like normal.

I don't think so, Tyken, but I could be wrong. I think if you want the benefits, you'll have to recompile your scripts or stalk product designers until they send you a new version.


So the beta grid viewer will have both compilers.. TY!

That was my understanding too, but the last I heard anything about it was at least six months ago (if not more), so I don't know how much has changed. I doubt they'll migrate script states just for the beta testing though. We'll see.

From http://blog.secondlife.com/2006/12/20/town-hall-with-cory-introductory-transcript/


edit: so, assuming nothing but the dates have changed: server-side compiler; scripts must be recompiled to use MONO; it's butt-whoopin' fast.

Can't wait to try it.

*cracks knuckles*
I can't wait to inflict my code on them.

/me hands Periapse some valium.

edit: good to see you're still around, Strife.

I hope it will be possible (in near future) to write scripts in C#. Maybe it will be possible to run both the old LSL and the new one, operating in C# or so (please no Basic or Java ) where the old functions are just wrapped from LSL to Mono (so old scripts and people who used only know how to programm in lsl) can use the old syntax and the others can use C# for example.

If anyone can break it, Strife can!

One thing that's still not clear to me is what happens with existing LSL-VM bytecode. Willl it be re-compiled to Mono VM bytecode transparently? Will the Mono VM have an LSL VM emulation mode? Will sims run both VMs (gak!)?

I think perhaps you are not clear on the difference between the LSL language and the LSL virtual machine (VM). It just so happens that they have the same name, but they are different things. Mono is not a language, it is a VM that runs bytecode. When it is implemented, LSL the language will still be in use, it will simply compile to Mono bytecode instead of LSL VM bytecode. Because there are other languages (such as C#) which also have Mono compilers, running the Mono VM opens the door to SL scripting in those languages.

I believe that both VMs will be run side by side but it won't allow new LSO scripts after some point in time.

I've only disappered into my code. I'm working on an LSO VM at the moment. Currently the VM code can only decompile scripts to LSO assembly. It does a pretty good job at that.

This has revealed to me some rather disturbing aspects of LSO which pretty much explains why LL isn't doing LSO to CIL translation directly. What they have said they are going to do is recompile the script from LSL to CIL and transfer the script state. This is very interesting because translating the script state from one engine to the other is no small feat. The LSO stack is untyped, you can't tell pointers from floats or integers. It means that you have to read the script bytecode and assign types to data that is found in the stack. The trouble is that there are ways of combining LSO bytecodes so that you cannot easily determine how a value got on the stack and consequently you cannot determine it's type. Fortunately the LSL compiler does such a bad job of optimizing code (it doesn't do any optimization) that it can fill in the missing details. You could do LSO to CIL but you would have no way of ensuring that the result was valid.

Currently I'm still working on refactoring the core of my VM. I have it reading the function and event information from an XML file. Next task is to write the actual functions. And if I'm truly feeling brave work out how to store the stack and heap in the memory space properly (not to keen on doing this). Who knows when I'll release it to the public.

Edit:
Come to think of it, I don't think LL has changed the VM in a significant manor since LSL1... only added a few new bytecodes. Which explains a lot.

What i mean is having both the lsl sytax and the C# syntax in use.

I don't really like the current lsl syntax for some reasons, for example lists and some of the stuff. If i read the LL statement correctly, they said that when mono is introduced into beta/live grid, the old syntax will remain so from user side nothing will change on the lsl scripting language. The changes will remain only server sided (other bytecode which is executed more efficiently).

Since it's impossible to switch from lsl to another scripting language, there would be need to support both for a while (and i'm not talking about the VM). Even after Mono release, we will still have to write scripts in LSL, since LSL won't change, it just compiles to another code (may it be C# or whatever). So, when you compile your current LSL scripts with Mono, the LSL language is interpreted to something else (i.e. C#) and then compiled (at least i assume that it does).

I would like to see an option to choose to write scripts in C# or LSL (in the end both will compile to the same bytecode), but programming in C# would allow the advanced users to do more stuff and do it more efficiently as it would be possible to do with the current LSL implementation/syntax (i.e. arrays, List, ListDictionary, SortedList etc.).

So the old syntax could be keep for backward compatibility (so old scripts can recompile in a bytecode readable by Mono VM) and for easy-to-script language for new scripters. C# on other side could be used by the advanced programmers to write the scripts.

So instead lf a
list myList = [0, 5, 3];
...
integer i = llList2Integer(myList, 1);

one could use

int[] myList = {0, 5, 3}
...
int i = myList[1];

or

List<int> myList = new List<int>new int[] {0, 5, 3});
int i = myList[1];

So it would be much easier to handle such lists or perform operations on them (removing, inserting, searching or looping). So scripter would have the choicse to deceide if he will use the old LSL syntax or the more powerfull C# one

No, LSL code won't be translated to C# or any other language -- it will be compiled directly to Mono bytecode. That's one thing LL has been working on as part of this project, a LSL -> Mono compiler.

I'm sure the LSL language will be around for a long time to come. What other language(s) LL will decide to support in the standard viewer (if any) is still unknown, but I wouldn't be surprised to see some of the third-party viewers supporting other languages, and perhaps even standalone compilers.

Didn't we just hear something about server-side compilation though? That might make this impossible. In fact, changing to server-side compilation miight be in ORDER to make this impossible, until LL can come to grips with the possibility of non-LSL source code (which will admittedly be harder to support). Or am I being too cynical? Heh.

Or was that just in reference to converting existing LSL scripts/bytecode?

Technically, couldn't we have made a compiler for C# to LSL bytecode regardless of mono/CIL? Somewhat of one, at least?

That is effectively what LSLEditor is doing, I reads the LSL code and translates to C# which it compiles to .NET (the M$ version of MONO). Aphones’ is the only person that can say for sure, but that is my guess as a devoted LSLEdior user.

Last time I decompiled LSLEditor, they were using RegExp to translate LSL into C# (which is the WRONG solution) then using the C# compiler class to convert the text into an assembly. I have no expectation that this has changed.

No you could not translate you source into LSO and then use LL's compiler to convert it because that is not how the new system works. LL's compiler converts LSL to CIL, not LSO. The conversion tool does parse the LSO but only to get the stack information.

LL will not support LSO to CIL because they cannot ensure the validity of the output. They cannot ensure that it will run as it did before the translation. There are some bytecodes that if used cannot be converted in a meaningful way.

Interesting observation. Is there any way that that assembly code is exposed or can be created directly? I guess its a mute point if MONO is so close, but as a hardware person I still prefer to avoid any abstraction layers.

Actually, its the opposite. Mono is the Open-Source attempt to make .NET availabale on Plattforms/OS's other than Microsofts Windows ^^

But in addition to .NET languages, Mono can also run Java, Pyton, etc. The reason why they choosed Mono is cause it's plattform independend (which is important since SL Client runs on linux too and the servers too i guess).

I believe the big reason they chose Mono over JS, Java, Lua, and Python was that it gave them choices. CIL has many languages that compile into it; it doesn't lock them into a single language. Efficiency, versatility and licensing cost were far more important then it being open source, anyway how many main stream linux scripting engines aren't open source?

Every now and then the discussion has come up on the forums as to what should replace LSL, a sizable contingent of big names lobbied for VM's that supported C style languages (and lobbied against non-C style languages).

I won't go into further details about the past but to put it simply, Mono being open source was a minor issue.

----

You could decompile LSLEditor and then add in code so you could save the compiled script. It wouldn't be a big change. LSLEditor is written in C# and last I checked didn't have any CIL obfuscation applied to it so it should still be easy to decompile with the .Net Reflector

Something that converts <insert language here> to LSL, which then gets compiled. One recalls that C++ was originally a pre-processor that spit out C.

I can imagine a language almost identical to LSL, except that it has better arrays and lists of lists, and whatever. If it can be compiled directly to the Mono VM, great. If not, use offical LSL as an intermediate format.

Using LSL as an intermediate language is a fun idea in concept, but it is never, EVER going to work. This worked in C because it is a relatively low-level language, and is structured well enough to handle higher-level language constructs in a pretty straightforward manner (e.g. function pointer struct members for virtual methods). There is no WAY you'd be able to translate 95% of C, C++, Java, C#, Perl, or Python to LSL and be able to actually run in the 16kB memory limit.

Lee, I've been using a C preprocessor on LSL for years.

We've been calling it ESL. I do all my coding in it. I have three libraries, a function library consisting of about 60 functions, a header library that makes nice headers, and an encryption library that probably needs updating again as it depends on the function library (and the function library is always in flux). I don't provide much in the way of documentation and the code contains a lot of undocumented macro's and places where you can change the behavior of the code generation with defines.

/54/c4/18335/1.html - Talks about ESL & SciTe
http://sl.sdfjkl.org/secondlife/scite/index.html - SciTe-ez

https://wiki.secondlife.com/wiki/User:Strife_Onizuka - My userpage on the wiki with my SciTe config files for LSL/ESL. Incorporating lslint for syntax checking and LSLEditor for testing.
http://mailerdaemon.home.comcast.net/CombinedLibrary.zip - My function library.

I would recommend bypassing Scite-EZ which is seriously out of date and skipping straight to the latest version of Scite which will work fine with Strife's config files. Then you have the latest updates for other languages.

And if anyone is interested in it then don't pass up Indent which is there in his User page. Takes a while to get your head around it but then you can completely customize every facet of auto indent.