[sldev] MONO: region request.
Periapse Linden
periapse at lindenlab.com
Wed Apr 16 10:33:53 PDT 2008
I'll check this out. I also am getting reports by various adult and TG
residents of login issues. This is complicated by the fact that the
aditi backbone was down until Babbage discovered it before the morning
Mono office hour and fixed it. However I've heard reports even since
then of people still being unable to successfully log in with the beta
viewer, however they *can* log in to the beta grid using a Release or RC
viewer. In all cases so far these are people who recently downloaded the
beta viewer (as in last couple of days). I've not heard of problems from
people who downloaded the beta viewer more than a week ago.
It's possible that something got wedged. On Friday the aging
1.18.6.77968 beta viewer was replaced with one built off of the 1.20
codebase. Sadly, that new viewer lacked the Mono UI. The beta viewer
download has been reverted back to the 1.18.6.77968 one, but maybe some
setting got missed. I will re-download and install the beta viewer and
try to dupe the problems I've been hearing about.
--Periapse
Tateru Nino wrote:
> A lot of people tell me they're having login problems with certain
> viewer versions. It's all anecdotal at the moment, though. Just under
> a hundred or so reports, which isn't statistically huge.
>
> Brandon Husbands wrote:
>> Trying to get on to the beta grid for office hours but not able to
>> log in, anyone else having issues?
>>
>> On Wed, Apr 9, 2008 at 12:03 PM, Periapse Linden
>> <periapse at lindenlab.com <mailto:periapse at lindenlab.com>> wrote:
>>
>> Yes, Tateru, as you say there are two different runtimes, LSL2 and
>> Mono. At launch the Mono runtime will be completely "opt-in": any
>> LSL script that you created or have modify permission for may be
>> compiled to Mono. From then on the script will run only under Mono
>> (unless recompiled again back to LSL2). We need this opt-in
>> paradigm because although Mono is feature compatible with LSL2,
>> the same script will have different behaviors and characteristics
>> depending on which runtime it uses. The simple performance
>> differences between the two runtimes mean that scripts change
>> behavior, and may need modification to be useful when they switch
>> to Mono.
>>
>> Thus in order to not break existing content, we want to ship with
>> both runtimes, and keep Mono opt-in. Eventually we may turn off
>> compilation to LSL2 bytecode. This will make Mono automatic for
>> all new script content, however we are unlikely to turn off the
>> LSL2 runtime on the entire grid. There are simply too many
>> scripts, actively running in the world, whose creators have left
>> SL or who don't want to QA and release a Mono version.
>>
>> The idea which started this thread was a suggestion to allow
>> estate or parcel owners the ability to selectively turn off only
>> the LSL2 runtime. This would mean that scripted attachments using
>> LSL2 would silently fail to run, much like the way the current "no
>> scripts" switch works, but only for LSL2. I see merit in the
>> suggestion, but I think it's simply too early to know if such a
>> feature would be truly useful. Mono definitely improves the
>> performance dramatically for scripts that do a lot of math, but
>> has much more humble returns for simple scripts like AOs or
>> attachment size/color modders. After Mono launches market pressure
>> will develop to encourage scripters to make Mono versions
>> available for those calculation intensive scripts that most
>> benefit from Mono. This process, a kind of natural selection, may
>> obviate the utility of a selective LSL2 disabler. Let's discuss
>> this feature again after we see how Mono is adopted post launch.
>>
>> Any who want more details on our current thinking, plans, or who
>> want to discuss this feature request, or propose others, are
>> welcome to attend our Mono office hours. See the Mono beta
>> <https://wiki.secondlife.com/wiki/Mono_beta_FAQ> wiki page for the
>> schedule.
>>
>>
>>
>> Tateru Nino wrote:
>>> Robin Cornelius wrote:
>>>> On Wed, Apr 9, 2008 at 1:43 PM, Nik Radford
>>>> <nik at terminaldischarge.net> <mailto:nik at terminaldischarge.net>
>>>> wrote:
>>>>
>>>>
>>>>> I don't see why this is something that couldn't at least be
>>>>> considered.
>>>>> Something like an option in the region estate tools "Enable
>>>>> LSL2 Runtime
>>>>> for region" and "Enable Mono Runtime for region" with tick
>>>>> boxes and such.
>>>>>
>>>>>
>>>>
>>>> I though, but am probably wrong, that the mono runtime emulates
>>>> the
>>>> lsl2 runtime for mono regions so that lsl2 on a mono region is
>>>> basically wrapped my mono and i recall (but again may have
>>>> imagined)
>>>> that even doing this was faster than the native lsl2 engine.
>>>>
>>>> Please correct me if i have gone mad.
>>>>
>>> Two different runtimes. One for LSL source compiled to Mono
>>> bytecode and one for LSL source compiled to LSL2 bytecode. That,
>>> as I understand it, is where we're headed in the near-term. Each
>>> sim having two script runtimes.
>>>
>>
>> _______________________________________________
>> Click here to unsubscribe or manage your list subscription:
>> /index.html
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> Click here to unsubscribe or manage your list subscription:
>> /index.html
>>
>
More information about the SLDev
mailing list