[sldev] Re: LSL and geometry hierarchy issues (Mark Meijer)

Kamilion kamilion at gmail.com
Mon Jan 21 04:12:40 PST 2008


On Jan 20, 2008 3:36 PM, Argent Stonecutter <secret.argent at gmail.com> wrote:
> Oh my, what mixed feelings! I heartily agree with your assessment of
> Mono - it is a wheel to heavy for the axle that LSL (or any
> comparable wheel) must ride upon. Most of the open source
> alternatives that come to mind, though, are also quite hefty.
>
> What languages, though, do you think would serve significantly better
> than LSL? The ones that come mind for me are Scheme and Forth, simply
> because both have a simple inner interpreter that could readily be
> wrapped around any axle. The other names that come up in these
> discussions - Lua, Tcl, Javascript, and the like - are likely too
> heavy already.

What about Ruby 1.9? Or is that a little too risky, considering you
can even monkeypatch the core from the debugger console?

For those who arn't aware, Ruby is a fully object oriented language.
Everything is an object. Objects have methods. Any method or any
object can redefine methods.

It can be quite english-like to read.

@future = 2.weeks.from.now unless today(:christmas)

if @future.nil
    @future = "There is no future"
    @future += String.new(" but what we make") if currentyear == 1983
    @future << [" ", "--", " ", "Sarah", " ", "J.", " ", "Connor"]
end


It should be noted: Ruby 1.9 was just released with an entirely new
runtime engine called YARV with MUCH MUCH improved performance. Ruby
1.8 is quite pokey in comparison.

There are also other ruby VMs... jRuby for java, IronRuby for .net/Mono...




However, make no mistake, I support Mono over all of the other solutions.

Reason One: OpenSim can already run C# scripts,
http://teddmaa.blogspot.com/2007/09/pure-c-support.html

Reason Two: Mono can interpret practically any language. IronRuby,
IronPython, C#, Perl, Parrot, Javascript, VB and so on,
http://www.oreillynet.com/xml/blog/2007/05/monodlr_hello_dynamic_language.html

Reason Three: Eventually, simulators may be embedded in commercial
devices. (I already have a single OpenSim simulator running on a
Linksys NSLU2.) Makes sense to use something that can speak any
language.

Reason Four: Eventually, the client may gain a mono VM of it's own.
Or, a new viewer based on libsecondlife that can render textures prims
& particles will eventually work. There are already gecko bindings for
.net/mono.

Reason Five: Mono allows for near-limitless expansion. No limits are
*required* to be set.

Reason Six: Mono-based scripts will most likely gain properties of
their own: UI-set resource limits (In the Properties panel for a
script, allow process priority & memory allocation -- Set it at 32KB
of memory. Or 128KB of memory. Or if it only requires 2KB of memory,
why use the default of 16KB?) or script-requested resource limit
expansions. (Wouldn't it be great to allocate an extra 16KB just
before you llHTTPRequest a large page, do your parsing, then release
the extra memory?) It's far better to do all your work in a single
64KB script than split it into 10 smaller 16KB scripts with huge
linked message routines. Object owners should be able to specify
script priorities. Got an SLEx cube? High priority. Couch with
anim-balls? Low priority.

Mono is still young. With a little lovin' and optimization it could
really grow to be a stable and useful plot device. After all.... Look
at the story of OpenJPEG: Went from being too slow to be usable to
nearly on par with libkdu. Just needed some clever people to notice
it. There's always low-hanging fruit to pluck.

Lindens, Is it possible to get a simulator running the mono engine
somewhere on the beta grid with the new het-grid stuff? Perhaps named
something like "Mono Sandbox" ?
I know it's partially working and still buggy, but so's havok4.
It would be nice to be able to play with it, even if it's not
finished. Who cares if the sim crashes every hour if you can spend
five minutes poking with a script that works so much faster? Debug
logs are useful too! And I bet we can point out some glaring bugs too,
just like Havok4.

Since Joshua Bell was kind enough to share the LL roadmap with us on
SLDEV, could we at least get a little data about where the mono
project is, what's done, what's broke, and what we can do to help fix
it?


More information about the SLDev mailing list