[sldev] Opening the server source?

[Dzonatas]

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