Bounties (or the carrot-on-a-stick story?) Re: [sldev] Opening the server source?

Dzonatas dzonatas at dzonux.net
Tue Jul 3 11:46:59 PDT 2007


Just like these bounties were found, so far, to be completely fictional:

http://wiki.secondlife.com/wiki/Linden_Lab_Bounties

"We'd like to work with the community to come up with feature coding 
ideas that are worthy of large bounties (e.g. best submission for a 
problem receives several islands for several years).

NOTE: we are not yet offering bounties. This page is here to describe 
how the program should work.

Some suggestions

This list is here to point out avenues of development that are 
impedance-matched for bounty development. They're relatively 
self-contained, and could be accomplished by a small group of hackers.

    * At least a 5x improvement in OpenJPEG performance as used in the 
Second Life Viewer to decode images
    * Move avatar mouths in a believable way based on voice audio chat 
streams being played
    * Cross platform TTS with tunable voices and a quality level on par 
with ATT Natural Voices. Must be able to tune number of simultaneous 
voices to control CPU load, be thread safe, and play back audio with 
correct stereo positioning.
    * Cross platform STT with accuracy on par with current 
speech-to-text solutions. Must consume less than 5% of the CPU and be 
thread safe.
    * Rearchitect the keyboard handling in a non-hacky way, so that it 
becomes possible to do key remapping (and also solve all of our other 
keyboard architectural foibles!).

If you aren't a Linden, please don't add more features to this list, but 
instead file the issue in JIRA, and perhaps refer to it from the talk page.
Process for making this a reality

We want the community to help us build this program. To that end, we're 
putting this in the list of items to consider for future roundtables, 
and encourage discussion on the mailing list. "

NOTE: It's not like LL has not shown any intention to move forward on 
these. All, except one, of the items listed above have been done and 
that one I know has had several contributors, so far. The only barrier I 
see that stops LL from paying these bounties is the fact that LL is not 
in agreement with itself on how to pay these. That fact may be hidden 
from other LL employees who don't know who is being contracted to do 
work for LL and being payed-off a little sum (while being pushed to the 
street).

Lindens, would you *please* learn to work together on this offer you made!

Dzonatas wrote:
> I've benchmarked fast compilations. One of the first steps to speed-up 
> up compilations tremendously is to use a fully mapped and state 
> written LR parser. When you use bison/yacc, you get as far as the 
> tables being generated. Bison/yacc also has the rarely used features 
> to map all the states and put it in a very nicely detailed output 
> format. Those state maps can be used to design a highly efficient 
> parser. One that can compile on-the-fly much faster than the default, 
> the straight bison/yacc created look-up table. For one, you get the 
> full C/C++ compiler optimization with the specially designed state 
> maps for which the default created look-up table prevents.
>
> It appears hinted on Babbage's website that the ability to compile 
> scripts under VS, or such, would be possible in-order to better 
> optimize the executable. I highly doubt there real is any time savings 
> for such import process in comparison to what a faster parser can do. 
> Especially, when it comes time where one would like to take those same 
> scripts and allow them to work efficiently on sims that don't speak Mono.
>
> I heard a rumor that Sun wanted to offer a Java enabled SL sim, but I 
> haven't heard of the LSL to Java compiler.
>
> The only reason why you really want to keep these executables 
> pre-compiled is to hide the source. In thinking in terms of a sim that 
> might be running a business that does tons of monetary transactions in 
> a day, I highly doubt that sim would want something like Mono or Java 
> compiled programs on its sim because Mono and Java feature unmanaged 
> pointers for their speed. Not only is that a disaster waiting to 
> happen, I bet it takes more time to try to validate unmanaged pointers 
> than it would to compile on-the-fly the right way without any 
> unmanaged pointers.
>
> Oh wait, these are just fictional businesses, like I'm just a 
> fictional peon.
>
> Chance Unknown wrote:
>> i thought the point was that the bytecodes stored with the scripts
>> would be in CIL (or MSIL for gates fanboys), allowing the binary image
>> to be transported around without the need to recompile it.
>>
>> wasnt that the ooooooo thing babbage linden was working on?
>>
>> On 7/3/07, Dzonatas <dzonatas at dzonux.net> wrote:
>>>
>>>  LOL not even. It can be completely transparent, if desired, all in 
>>> SL. Just
>>> like Mono enabled sims, it would be limited to those, however.
>>>
>>>  One feature I've had built-in to Atomatrix from the start is the 
>>> ability to
>>> compile on-the-fly (or just-in-time). A simple flag that an LSL 
>>> script is
>>> compilable and validated is all that is needed to effectively handle
>>> on-the-fly compilation.  It validation tracking is needed, we could add
>>> resources to track origination of the validator, like a PGP stamp.
>>>
>>>  This is a very useful tool. For example, lets say I want to take a 
>>> script
>>> compiled in LSL, to a sim that uses Mono and use it there. It would
>>> recompile when it arrives at that sim.
>>>
>>>  Same thing for the event to take that Mono-compiled LSL script or 
>>> to a sim
>>> that uses Atomatrix. When it arrives, it gets recompiled.
>>>
>>>  That way each sim can easily use the best local implementation and not
>>> worry about foreign compilations.
>>>
>>>  =)
>>>
>>>
>>>
>>>  Chance Unknown wrote:
>>> So are you suggesting we need visual studio to script our prims now? 
>>> Um no
>>> thanks, ill stick with SL.
>>>
>>>
>>> On 7/3/07, Dzonatas < dzonatas at dzonux.net> wrote:
>>> > Adam Frisby wrote:
>>> > > Argent Stonecutter wrote:
>>> > >> IN fact you've got an LSL to Mono compiler on your disk right now.
>>> > >
>>> > > We do? I thought LL were keeping that internal since it's
>>> > > simulator-only stuff?
>>> > >
>>> >
>>> > Kewl!  I could make a LSL to Atomatrix compiler.
>>> >
>>> > Mono/.NET and Sun's Java are nice, but they fall short of the more
>>> > advanced object-orientated systems. Mono/.NET and Java are more of a
>>> > object-oriented program language rather than an object-orientated
>>> > program environment.
>>> >
>>> > --
>>> > Power to Change the Void
>>> > _______________________________________________
>>> > Click here to unsubscribe or manage your list subscription:
>>> >
>>> /index.html
>>> >
>>>
>>>
>>>
>>> -- 
>>>  Power to Change the Void
>>
>>
>

-- 
Power to Change the Void


More information about the SLDev mailing list