holy cow! mono support in the works?

Some guy was trying to get me to try There and it got me googling....

http://secondlife.blogs.com/babbage/2006/05/microthreading_.html

I'm sure you all know about this but I'm totally stoked!

Is the plan to allow people to upload CLR binaries? I would love to be able to program offline in my own dev environment and then update my world objects when I'm ready.

Don't get too excited.

They're talking about using Mono to speed up LSL. The available APIs are not likely to be expanded beyond the "llFoo" calls simply because of the inclusion of Mono, and the inherent delays outside LSL (in dataserver, for example) are going to remain the same.

The biggest problem in LSL is the script scheduler, and that's also likely to remain... complete with having every script "busy-waiting" on events.

I understand the temptation and the seductive quality of reaching out to open source and new technologies, but I think LL should take a step back and reconsider mono.

Critical stuff is not getting done all in the name of pushing forward to a technology that is unproven in the MMO space.. Bugs are not getting fixed, and big improvements could be made to the current status quo.

SL and virtual worlds are a unique programming problem, they are real time massively multi user virtual worlds with millions of tiny scripted, mobile objects all competing for CPU resources. Trying to shoe-horn an architecture that is rooted in a world of thick client applications is, as far as I can tell, a strategical direction that has less payoff then the alternatives.

In fact, already Jim Purbrick is describing the challenges he's running into by having to recreate a new threading architecture .. and he's not going to get a lot of support for what he has done as Mono moves forward. Because of these threading issues, I am concerned that instead of improving the performance and stability of what we have, it will just stay the same as what we had before (or get worse) because of the micro thread complications that is going to occur on each tiny object.

Jim is also talking about a more flexible, less contrained environment that Mono will bring. I am concerned that a less constrained environment is actually going to be a *more* restrictive environment because more flexibility will allow for more mischievous behaviour: thus causing more grid crashes, performance bottlenecks, griefing - etc.

I think there are several alternatives to Mono, but one approach I think is especially compelling: improve what we have (extend and optimize LSL), and for the private island folks with unique requirements, open up a no holds barred native code interface so that people can jack directly into the server and upload their own high end custom code that runs as root (or the equivalent).

This will give everyone (at a much lower cost) what they want - a virtual interactive world that continues to function smoothly, and for those who need it, a platform to develop whatever they wish in any language they care to without impacting the rest of the grid.

I've given up programming LSL for now because its just tooooooooooooo primititve.

I wouldn't mind LL just fixing LSL or going to a new language or whatever.

Just give me the basics at least! Like how about a real array at a VERY minimum. I would kill for a dictionary / hash. Everything after that would be gravey.

Er... Let me set everyone straight on this, since people seem to forget easily:

LSL is a SCRIPTING LANGUAGE. It is not a programming language. It is not for advanced software development. It is not a subset of C or Visual Basic.

You will probably not get arrays or advanced memory managment for a simple reason: You are running your code on the equal to a simulated Commodore-64 computer. A sim needs to run THOUSANDS of these, perhaps hundreds of thousands. Each, I believe, has 16K available space for it's combined program code and datastore. You just don't have the space to use arrays effectivly anyway.

Arrays take a large amount of memory and resources to maintain. 10,000 scripts running arrays in addition to what they're doing now would have a significant effect on the SL systems.

Finally, as to not being a 'powerful' enough language: That's your call. As of now, I can build anything I need with it. I have made semi-secured broadcast network systems, advanced multimedia displays, and toys and gadgets aplenty. LSL may be simple, but it's 'powerful' enough to pull off anything I have needed so far.

Okay then, how about something as simple as an RSS reader? Guess what, if that RSS feed has more than about 2XXX bits, you are out of luck. I know, I've tried. I got something working, but I had to make a custom feed generation routine on my web site backend, and that's not RSS.

LSL is INCREDIBLY limited. It's amazing what we CAN do with it considering the circumstances, but I chalk that up to the ingenuity of the developer base, rather than the implementation of LSL. There have been amazing things created in scripting languages (PHP and Ruby are both considered scripting languages, as are Perl, Python, etc...), so it's not that scripting languages are necessarily automatically inhibited by anything but speed. The problem is that LSL IS VERY, VERY LIMITED. Try using LSL to encrypt anything beyond a simple, easily breakable XOR, and you'll see what I mean. Try designing any sort of useable interface in LSL that is usable for a non-developer. You'll sometimes end up with an ENTIRE SCRIPT that does nothing but show ugly SL dialog menus!

No, I partially agree with Iron Perth. At this point though, I'd settle for Mono, simply because it'll be at least better than what we've got NOW. The day that they completely drop the current implementation of LSL and implement something like Ruby, or even Python... they'll have me for life.

Edit: The other problem is also... why bother with 'thousands of commodore 64s' when most complex objects have dozens of scripts in them? Why not just give us a couple of Tandy 1000's instead? We could collapse most of those scripts into single scripts, which would almost certainly be easier to manage and schedule, while using the SAME amount of memory. Memory limitations are probably the biggest stopping blocks when creating complex scripts.

The funny thing is - when your working with extremely small amounts of memory - you do need advanced memory management. You need pointers, references, arrays, etc. To avoid the problem that LSL has of - unnessecary bloat (LSL's lists), and pass-by-value (which combined with lists is especially nasty)

I've programmed on embedded devices before - and being restricted to pass-by-value would simply make many applications impossible since it cuts you down to 1/3rd of the usable memory space for a single variable (original, stack copy, manipulated copy - eg llListReplaceList).

CIL, at least in theory promises to deliver arrays and pass-by-reference based memory access. While I dont expect us to get non-LSL uploads anytime soon, hopefully eventually it will happen.

Perhaps you know something I don't, but why do we need to upgrade to Mono in order to get pass by reference?

Are they using a closed source virtual machine which they can not alter?

The current virtual machine doesnt have any memory protection, so while the LSL bytecode supports pointers - we arnt allowed to use them.

And yes - it is a proprietry virtual machine right now.

So no c# for me?

You don't have to give the user access to pointers in order to have pass-by-reference. Thus, memory protection is not (or should not be) an issue.

If LSL is a proprietary virtual machine, I don't see why they don't work on doing a LUA (or whatever popular script language) port. Mono isn't going to be something we are going to use. If anything, they will use it to build the simulation and tools, but I don't see it becoming the replacement for LSL. For one, it is MUCH more bulky than a small-scale VM-based language. If you think it is hard to do anything complex with LSL in 16kb, Mono will make it nearly impossible.

I remember working wonders in BASIC with 1K ram on my first computer, the Sinclair ZX81 in the early 1980's.

Seems like technology is going backwards.

Lewis

Ya they should let us use Lua. It's pretty easy to get it to work like Stackless Python.

Once their backend is in .NET is possible to use Lua to call .NET directly.

Who implemented the machine?

Well, I had been under the illusion that LL wrote the VM, however, thinking about it now I probably should have known better.

I guess this does change things a bit. However, they should go with Stackless Python, and not Mono. SP has proven itself over at Eve and is perfect for this problem.

That's certainly true enough. Personally I'm primarily looking forward to Mono because I build a lot of things, and would really love to use object orientation to facilitate better code re-use. It'll be way more efficient and faster to develop when I have some base classes that I extended and fill in the blanks, or override and use default functionality. Today I simulate some of that by using multiple scripts and having hooks and callout points where I can code custom things in other scripts.

But with today's system there are still lots of times that I "re-use" code with copy-paste-modify. While this does work and allows me to build whatever I want, it imposes this key limitation: bug fixes to new things don't work retro-actively to the old things I copied them from.

That one thing alone makes Mono exciting to me.

Include/Import would be as good as Mono for code re-use purposes. Well... not AS good, but good!

I've never understood OOP so I'm going through the agonizing steps to learn it.

After looking at C#, Python, C++, smalltalk (hey it runs in Croquet), Java and more I finally decided on Java as the "cheapest" way to learn as in what would run on my computer without spending money (before you protest, I'm on a mac).

I've always heard that Java is "too strict" in use of object and that suits me fine for learning.

I'd learn Mono outright but it seems incomplete.

I'm hoping to learn OOP by the time LSL is

If you really want to learn OOP, stick to Smalltalk. It will force you to really think in the OOP way. I did Smalltalk commercially for many years, reluctantly switching to Java when the Smalltalk market crashed.

Java in the end, creates a more service oriented style of code.

Anybody working with any code generators?

This is another way to get around some of the limitiations of LSL. If a generator is kicking out most of the code, the lack of good reuse mechanisms doesn't hurt so much, the reuse comes from the generator templates.

These days the only code I really want to write, is code that writes other code.

The only thing in Mono that is incomplete is the implementation of some of the Windows specific .NET libraries; the GDI+ code and some other GUI aspects. Remember that Mono is a framework and a compiler, not a language. The language is C# and Mono has full support for the C# 1.0 ECMA spec, and complete enough support for 2.0 that you'll never know what's missing. I've written several non-trivial C# apps that cross-compile in .NET and Mono.

That aside, Java is probably the best way to go. I started off in Visual Basic, and picked up C and C++ for a job later, but never really grasped OOP until taking a class in Java. Java is also an industry standard, so you may get some real world use out of knowing it.

From what I've read, the Mono project was built quickly and was nearly complete all at once, but by the time it was presented, the platform had advanced so far that it was strongly incompatible and would have to have been done over.

I also seem to recall that it would have been used to speed up the LSL virtual machines, but that we wouldn't have had direct access to Mono.

Regarding the Java comment, I've worked in the software development industry for about 30 years now, and while Java started strong, it's not regarded as a forefront language at this point.

The three dominant languages right now are C++, C#, and PHP, in that order.

Java and Perl are neck and neck for fourth place, with Perl moving up and Java staying about where it is.

Uploading our own CIL is a highly sexy idea, though I had gotten the impression that was dropped. Glad to hear LL is still working on it though.

As for the BYVAL discussion -- I do agree, 16k is a bit too tight to write large-scale code in without direct access to the memory system. However, to combat that one can just split the task up. But that usually vastly complicates any single project and can lead to sim memory waste.

Honestly, I almost wonder if there should be two divides here. Leave the llFoo and built-in editor as-is for folks who just want to make their bling flash or their jet belch smoke and fly. While have some kind of bare-to-the-metal direct access to the VM for those us who want to do the more complicated stuff.

Sure, right now folks can do some awesome stuff in LSL, but you have to work three times as hard to accomplish it, and not without some waste.

Indeed, being able to more directly interact with the VM will be very useful. What I think might be best is if LL can integrate compilers for other languages into the client, and then each script asset would have a drop-down menu of what language it's written in.

The top priorities for languages to support are C, C++, ASM, and C#, IMO.