[sldev] MONO: region request.

[Joshua Bell]

There was also a glitch where expired presence wasn't being cleared 
properly on the beta grid, which has been fixed. That may have been 
contributing to the troubles as well.

Periapse Linden wrote:
> 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
>>>   
>>>       
> _______________________________________________
> Click here to unsubscribe or manage your list subscription:
> /index.html
>