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

Kamilion kamilion at gmail.com
Mon Jan 21 04:24:17 PST 2008


Guess I should finish reading my mail before replying to messages.... Ooopsie!
https://lists.secondlife.com/pipermail/secondlifescripters/2008-January/002135.html

On 1/20/08, Jesse Barnett <jessesa at gmail.com> wrote:
> On 1/20/08, Mark Meijer <meijer78 at gmail.com> wrote:
> >
> > What was the last we heard about it?
> >
> Just last week; http://wiki.secondlife.com/wiki/Mono
> "Target date for the Mono beta is 31 January 2008."

Color me impressed. Still though, I am indeed interested in this topic.

On Jan 21, 2008 4:12 AM, Kamilion <kamilion at gmail.com> wrote:
> 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