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

[Rob Lanphier]

Liana isn't here this week, but she's working out something now.

I'll give you a little bit of the inside story on this.  There was a lot
of pressure at launch time to say something about this, even though I
personally didn't feel like bounties were the right thing to do at this
stage.  We should have remained silent on this, since we didn't have a
concrete plan for moving forward.

I don't want to have this conversation this week, while Liana's out, so
I'll leave it at that.  Can we pick this back up next week?

Rob

On 7/3/07 11:46 AM, Dzonatas wrote:
> 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
>>>
>>>
>>
>


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 249 bytes
Desc: OpenPGP digital signature
Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070703/59fd46ef/signature-0001.pgp