[opensource-dev] The Faces Of Client-Side Code

A while back, before the 2.0 announce interrupted our conversation, I had made a post about what I saw as three different forms of client-side scripting/plugins/whathaveyou. I've since been convinced that I missed something. So here goes again, with a (hopefully) improved set of definitions: Cli

Re: [opensource-dev] svn compile failure on Ubuntu 9.10

Ah, cool. I'll give it a shot in a bit. --GC On 03/06/2010 07:47 PM, Thickbrick Sleaford wrote: > On Sunday 07 March 2010 02:14:57 Glen Canaday wrote: > >> /home/glen/Programs/Second >> Life/Snowglobe-2.0-build/trunk/indra/../libraries/include/boost/coroutine/d >> etail/coroutine_impl.hpp:59:

Re: [opensource-dev] Script Memory Limits UI

In response to the OP. I agree the UI will have to present that information differently. As it is now people will merely make a decision on memory usage and choose LSL scripts, and remove mono scripts. Likely negatively impacting their own experience. Scripters will be driven to compile scripts as

Re: [opensource-dev] Client-side Permissions Management

Rob Nelson wrote: > Consider a user in a sandbox who wants to clean up his mess. If he were > using a viewer based on LibOMV, all the viewer would have to do is loop > through the region's object dictionary and return/delete objects that he > owns. In the LL viewer (correct me if I'm wrong), LLSe

Re: [opensource-dev] Script Memory Limits UI

On Sat, 6 Mar 2010 20:49:35 + Morgaine wrote: > You have to be joking. (Or rather, Kelly has to be joking.) > > It's been decades since computer users last had to specify the memory > requirements of their programs in advance of running them. > > Has 1970 returned again? This is progress?

Re: [opensource-dev] svn compile failure on Ubuntu 9.10

On Sunday 07 March 2010 02:14:57 Glen Canaday wrote: > /home/glen/Programs/Second > Life/Snowglobe-2.0-build/trunk/indra/../libraries/include/boost/coroutine/d > etail/coroutine_impl.hpp:59: error: declaration of ‘typedef class > boost::coroutines::detail::context_base > boost::coroutines::detail::

Re: [opensource-dev] Script Memory Limits UI

On Sat, Mar 06, 2010 at 09:51:49PM +0100, Marine Kelley wrote: > This is exactly how I had interpreted it, and this means that a script has to > explicitely request less memory than the default 64k if the scripter wants to > use less memory. And I don't think there will be any other way to do that

Re: [opensource-dev] svn compile failure on Ubuntu 9.10

My bad, SNOW-431: http://jira.secondlife.com/browse/SNOW-431 On 03/06/2010 06:13 PM, Thickbrick Sleaford wrote: > On Sunday 07 March 2010 00:57:42 Glen Canaday wrote: > >> Dead compile: >> >> /home/glen/Programs/Second >> Life/Snowglobe-2.0-build/trunk/indra/llcommon/llinstancetracker.h:170: >

Re: [opensource-dev] svn compile failure on Ubuntu 9.10

Yup, that was it. Next item, looks like SNOW-411 (http://jira.secondlife.com/browse/SNOW-411) is the problem. Here's the output from gcc: indra/viewer_components/login/lllogin.cpp:32: /home/glen/Programs/Second Life/Snowglobe-2.0-build/trunk/indra/../libraries/include/boost/mpl/aux_/numeric_op

Re: [opensource-dev] Script Memory Limits UI

On 2010-03-06, at 14:49, Morgaine wrote: > It's been decades since computer users last had to specify the > memory requirements of their programs in advance of running them. About a decade. Mac OS required you to specify the partition size required by your program. This was also pretty common

Re: [opensource-dev] svn compile failure on Ubuntu 9.10

On Sunday 07 March 2010 00:57:42 Glen Canaday wrote: > Dead compile: > > /home/glen/Programs/Second > Life/Snowglobe-2.0-build/trunk/indra/llcommon/llinstancetracker.h:170: > error: ‘LLInstanceTracker’ is an > inaccessible base of ‘LLEventTimer’ > make[2]: *** [llcommon/CMakeFiles/llcommon.dir/lle

[opensource-dev] svn compile failure on Ubuntu 9.10

Dead compile: /home/glen/Programs/Second Life/Snowglobe-2.0-build/trunk/indra/llcommon/llinstancetracker.h:170: error: ‘LLInstanceTracker’ is an inaccessible base of ‘LLEventTimer’ make[2]: *** [llcommon/CMakeFiles/llcommon.dir/lleventtimer.o] Error 1 make[1]: *** [llcommon/CMakeFiles/llcommon.

Re: [opensource-dev] Script Memory Limits UI

Oh! And read the Kelly's comments in https://blogs.secondlife.com/community/technology/blog/2010/03/05/server-138 -beta-now-open : "Right now there is no way to change how much memory a mono script uses,

Re: [opensource-dev] Script Memory Limits UI

:)) No, just I'm reading the blog https://blogs.secondlife.com/community/technology/blog/2010/03/05/server-138-beta-now-open#comment-776254 and also Found in : http://wiki.secondlife.com/wiki/Beta_Server_Office_Hours/Minutes/2010-03-04 [16:09] Sebastean Steamweaver: Kelly, I've been saving my

Re: [opensource-dev] Script Memory Limits UI

This is exactly how I had interpreted it, and this means that a script has to explicitely request less memory than the default 64k if the scripter wants to use less memory. And I don't think there will be any other way to do that than by calling a LSL function to request memory. Which means modifyi

Re: [opensource-dev] Script Memory Limits UI

You have to be joking. (Or rather, Kelly has to be joking.) It's been decades since computer users last had to specify the memory requirements of their programs in advance of running them. Has 1970 returned again? This is progress? Morgaine. On Sat, Mar 6,

Re: [opensource-dev] Script Memory Limits UI

Am 06.03.2010 um 21:25 schrieb Marine Kelley: > Does that mean we have to modify ALL our scripts to add function calls to > tailor the memory right, most of the time not even knowing how much is needed > ? I thought the memory taken by Mono scripts was variable, to a maximum of > 64k, as oppos

Re: [opensource-dev] Script Memory Limits UI

Does that mean we have to modify ALL our scripts to add function calls to tailor the memory right, most of the time not even knowing how much is needed ? I thought the memory taken by Mono scripts was variable, to a maximum of 64k, as opposed to LSL which takes 16k no matter what... If that's the

Re: [opensource-dev] Script Memory Limits UI

Oh! And read the Kelly's comments in https://blogs.secondlife.com/community/technology/blog/2010/03/05/server-138-beta-now-open : "Right now there is no way to change how much memory a mono script uses, and it is true that at any given point it probably uses less than 64k, by some amount. How

Re: [opensource-dev] Script Memory Limits UI

Try with this mailing list, it's more approriate! https://lists.secondlife.com/cgi-bin/mailman/listinfo/server-beta GCI - Original Message - From: "Matt White" To: Sent: Saturday, March 06, 2010 5:21 PM Subject: [opensource-dev] Script Memory Limits UI

Re: [opensource-dev] Client-side Permissions Management

On Sat, Mar 6, 2010 at 1:17 PM, Boroondas Gupte wrote: > Rob Nelson schrieb: >> Consider a user in a sandbox who wants to clean up his mess.  If he were >> using a viewer based on LibOMV, all the viewer would have to do is loop >> through the region's object dictionary and return/delete objects th

[opensource-dev] Script Memory Limits UI

Hello! I've attached a screen shot of the new Script Information screen that you can see when you log into the beta 1.38 server with the SL2 client. Linden Lab - I'm begging you.. *PLEASE* do not push this feature out to the main grid until Mono scripts are actually charged what they use. Please,

Re: [opensource-dev] Client-side Permissions Management

The whole approach to objects and assets needs to change anyway, because of interop. Interop is a process --- it doesn't appear suddenly out of nowhere, you have to pave the way by evolving your code into a more flexible form. There is an implicit assumption in the viewer that everything is store

Re: [opensource-dev] Snowglobe as an mixed reality platform

On Sat, Mar 6, 2010 at 1:36 AM, Philippe (Merov) Bossut wrote: > > At the same time, I don't think it's reasonable to wait for the Glorious > Future to show up before considering contributions and experimentations like > yours (or we'll never get anywhere...). > > OK, let's start somewhere then.

Re: [opensource-dev] Client-side Permissions Management

Boroondas Gupte schrieb: > The mini-map colors objects you own differently, so there must be > another way to get at least owner information. > The server sends two bits with each prim that defines ownership. One bit is the owner bit, it is set if the current agent owns the prim. The other is th

Re: [opensource-dev] Client-side Permissions Management

Rob Nelson schrieb: > Consider a user in a sandbox who wants to clean up his mess. If he were > using a viewer based on LibOMV, all the viewer would have to do is loop > through the region's object dictionary and return/delete objects that he > owns. How does LibOMV obtain/build that dictionary? >