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

[Boroondas Gupte]

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?
> In the LL viewer (correct me if I'm wrong), LLSelectMgr actually
> returns the permissions (*and owner/creator info*) , so the viewer would
> have to select each and every object within the sim to grab its
> permissions, which seems rather wasteful of bandwidth, and troublesome
> in general.
The mini-map colors objects you own differently, so there must be
another way to get at least owner information.

cheers
Boroondas
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

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

[Thomas Shikami]

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 the group bit, it is set if a group the current agent is in 
owns the prim. (deeded)

For other ownership, group etc. information one needs to hover the mouse 
on that object.
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

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

[Morgaine]

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. If you already do have code ported to
> Snowglobe, it's worth setting up a place to post this so we can review and
> see how best we could integrate that in the current architecture. I
> encourage you to create a JIRA on the public JIRA and attach a patch to it
> (I'm expecting a big patch though...). Considering the breath of the
> feature, you should also create a page on the wiki to store there any
> documentation. Let me know if you need help for this, I'll be happy to
> assist you.
>
>
Merov, are you giving IBM and IBM-sponsored projects an inside track in
Snowglobe?

The IBM-developed OGP code went into Snowglobe with barely any question,
despite being tightly entangled with the legacy networking instead of a
clean separate protocol module.  And now you seem to be embracing with open
arms an almost unknown third party development sponsored by IBM.

Does the rest of the opensource-dev community get similar treatment and
encouragement to add large areas of new functionality into Snowglobe?  We've
been trying to gain your interest and attention in client-side scripting
because that is so massively more important and empowering in an open
community viewer, yet you have seen fit to dismiss it, indeed not even to
engage in the topic.

If Snowglobe is a 2-party playpen for LL and IBM in respect of adding major
functionality, while other open source developers only get to fix your bugs
and tinker at the edges, then please say so.

Alternatively, please pay attention to what the rest of this list wishes for
Snowglobe as well.


Morgaine.




=

On Sat, Mar 6, 2010 at 1:36 AM, Philippe (Merov) Bossut  wrote:

> Hi Tuomas,
>
> First, thanks a lot for joining us here in Snowglobe. I've seen your video
> when it came out a few months ago and I was hoping to see you chime in here
> back then :)
>
> On Tue, Mar 2, 2010 at 2:31 AM, Kantonen Tuomas wrote:
>
>> The project, continuing also in 2010, is split into two parts:
>> overlaying a video image with avatars and virtual objects (augmented
>> reality; AR) and using hand and head gestures to control avatars and
>> interact with virtual objects (augmented virtuality; AV).
>>
>> We have agreed to release our work as open source. However, lack of
>> continuous "forward porting" would soon render the released code
>> unusable. It would therefore be better to have some parts of our
>> work incorporated into the Snowglobe sources.
>>
>
> The whole thing is: which parts? As others mentioned in this thread, we
> eventually would like to develop a plugin architecture that will make easier
> for this kind of work to be developed and integrated. We do have such an
> embryonic API used for media currently. I think we could expand that
> architecture to integrate things like avatar gesture and puppeteering as you
> did (something I also do have some experience with and a personal interest
> in).
>
> 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...).
>
>
>>
>> I've tried to keep all our modifications as small as possible. The
>> project is separated to our own ACME (Augmented Collaboration in Mixed
>> Environments) module, vanilla Snowglobe code and an interface between
>> the two.
>>
>
>> I'd be ready to invest some time to implement a generic AR/AV support
>> for Snowglobe if we could come up with a design that could be accepted
>> by the Snowglobe developers. This would allow anyone to use Snowglobe
>> as AR/AV research platform, with or without our software.
>>
>
> OK, let's start somewhere then. If you already do have code ported to
> Snowglobe, it's worth setting up a place to post this so we can review and
> see how best we could integrate that in the current architecture. I
> encourage you to create a JIRA on the public JIRA and attach a patch to it
> (I'm expecting a big patch though...). Considering the breath of the
> feature, you should also create a page on the wiki to store there any
> documentation. Let me know if you need help for this, I'll be happy to
> assist you.
>
> Cheers,
> - Merov
>
>
>
> ___
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/OpenSource-Dev
> Please read the policies before posting to keep unmoderated posting
> privileges
>
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

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

[Morgaine]

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 stored in
one world's own repository, and that this world also holds all ownership and
permissions data.  This is changing as more grids and independent asset
services appear, leading to a mashup scenario in which a region will contain
elements which are held authoritatively in a variety of places elsewhere.

As you are developing your own viewer, I suggest that you revamp your object
and asset data and metadata handling to include querying external services,
because that is where everyone is heading.

VWRAP is moving in that direction by decoupling all services, realXtend's
Naali already features external WebDAV-based inventories, Opensim has long
had Hypergrid which reflects asset requests back to a traveller's home
region, and the new Connector system in Opensim offers huge scope for
non-centralized object and asset authority.

The days of centralized objects and assets are coming to an end, and new
viewer code needs to take that into account.


Morgaine.




=

On Sat, Mar 6, 2010 at 12:52 AM, Rob Nelson wrote:

> While working on my viewer's object handling stuff, I happened across a
> rather fundamental flaw in the SL viewer's architecture.
>
> When one considers filesystem permissions or even database permissions,
> you notice that permissions are generally attached to the object that a
> user attempts to access, or the permissions are obtainable from a
> central source that has a simple way to grab the permissions.
>
> >From my casual glance at the viewer code, I noticed that the latter is
> the case in the LL viewer.  However, there's a rather large problem for
> those of us who are writing client-side scripting APIs.
>
> 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), LLSelectMgr actually
> returns the permissions (*and owner/creator info*) , so the viewer would
> have to select each and every object within the sim to grab its
> permissions, which seems rather wasteful of bandwidth, and troublesome
> in general.  This works fine for situations where the object is selected
> anyway (when building or right-clicking), but it's horribly inefficient
> for scripting.
>
> I haven't dug deep enough yet to fully grasp what is going on in
> LLSelectMgr, but it seems to me that it would be a lot more efficient to
> simply attach the permissions with each object's properties when they
> are sent to the client by the server, eliminating the need for scripts
> (and bots) to have to spam the server requesting permissions.
>
> Fred Rookstown
> Luna Viewer
>
> ___
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/OpenSource-Dev
> Please read the policies before posting to keep unmoderated posting
> privileges
>
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

[opensource-dev] Script Memory Limits UI

[Matt White]

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, please, please!

This screen shot shows exactly what's wrong - I have some attachments
with very simple scripts in them (just a couple of lines of LSL with a
very tight listen), but they are charged a full 64k. I don't need for
the scripts to be Mono - they work great with LSL - but I compiled
them as Mono because "it was the right thing to do", and now that's
coming back to bite me.

I take great pride in making sure my scripts are as tight on resources
as I possibly can, and none of this is taken into account. A two
script item that's compiled as LSL is going to be charged *HALF* as
much as a very simple Mono script, even if the Mono script is just one
line and the LSL scripts are 16k and pushing the limit memory usage.

We listened to you - we moved from LSL to Mono. Now it seems that was
a foolish move.

I predict this feature is going to have exactly the opposite effect
intended - it's going to force everyone to go back to LSL and way from
Mono. (As if we needed another reason besides the several second
pauses every time a script-heavy AV TPs in.)


We're geeks. We can understand the difference in 64k on Mono and 16k
on LSL, but the average SL user does not. This feature, as it's
implemented right now, does not help matters. All it shows is "just a
number" with no indication as to how much memory is actually in use
and if the script is LSL or Mono. Anyone can see that 64 > 16, so 16
must be better. Four times better.

I know the plan is to not start ENFORCING memory limits until Mono
scripts are charged what they use, but I'm scared it won't matter much
- people are going to migrate away from Mono and back to LSL given the
way this screen looks today.

Please consider reworking how this screen looks. Add an "in use"
column or make LSL and Mono be treated fairly... but please don't push
this live as-is!

- Matt
<>___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

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

[Latif Khalifa]

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 that he
>> owns.
> How does LibOMV obtain/build that dictionary

LibOMV keeps track of all object updates and object kills that come
from the sim, and keeps the most current list of prims in a per-sim
dictionary. So it's not a dictionary of all prims in a region, rather
of those that sim sends (based on its interest list, settings of your
"draw distance", etc).
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Script Memory Limits UI

[Garmin Kawaguichi]

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

___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Script Memory Limits UI

[Garmin Kawaguichi]

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. 
 However, before we enforce script limits, which again is still a ways off, we 
will enable the ability to set a lower max memory size for mono scripts.  If 
your script really only uses 4k, congrats you can set it to that and it will 
only count as 4k, and you won't be able to use more until you change it.  This 
will be implemented before we enforce limits."

GCI


- Original Message - 
From: "Matt White" 
To: 
Sent: Saturday, March 06, 2010 5:21 PM
Subject: [opensource-dev] Script Memory Limits UI


before posting to keep unmoderated posting privileges___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Script Memory Limits UI

[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 opposed to LSL which takes 16k no matter what...

If that's the case, if we have to modify all our scripts, after switching to
Mono (which in itself was a tremendous work because it implied merging
scripts and updating everything to our customers), then I am sorry to say
the interest of using Mono over LSL has suddenly gone through the floor.



On 6 March 2010 17:39, Garmin Kawaguichi wrote:

>  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.  However, before we enforce script limits, which again is still
> a ways off, we will enable the ability to set a lower max memory size for
> mono scripts.  If your script really only uses 4k, congrats you can set it
> to that and it will only count as 4k, and you won't be able to use more
> until you change it.  *This will be implemented before we enforce limits*
> ."
>
> GCI
>
>
> - Original Message -
> From: "Matt White" 
> To: 
> Sent: Saturday, March 06, 2010 5:21 PM
> Subject: [opensource-dev] Script Memory Limits UI
>
> before posting to keep unmoderated posting privileges
>
> ___
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/OpenSource-Dev
> Please read the policies before posting to keep unmoderated posting
> privileges
>
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Script Memory Limits UI

[Michael Schlenker]

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 opposed to LSL which takes 16k no matter what...
> 
> If that's the case, if we have to modify all our scripts, after switching to 
> Mono (which in itself was a tremendous work because it implied merging 
> scripts and updating everything to our customers), then I am sorry to say the 
> interest of using Mono over LSL has suddenly gone through the floor.
> 

The comment from Kelly Linden on the blog didn't sound like it, it was more 
like:
- The default allowed memory footprint of a mono script is 64 kB
- In the future a mono script will be allowed to request more OR less maximum 
memory for itself
- IF you know that your script only needs a tiny amount of memory, you can set 
its limit lower to ease the pressure on the sim
  (which makes it an option for example to use 16 scripts with 4 kB and trivial 
functions instead of one 64 kB script that needs to multiplex things)
- We don't want to break content. Most of the time we cannot guarantee or 
measure the maximum memory usage of a script and to prevent bad effects like 
prims that only work when the phase of the moon is right (aka the garbage 
collector timing) we simply assume a static maximum of 64kB. 

I agree on the issue of a horrible UI for the 2.0er memory usage though. It 
should simply sum the number of scripts and show how many LSL and how many Mono 
scripts are involved. The 16kB/64kB details are misleading and useless. 

Michael
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Script Memory Limits UI

[Morgaine]

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, 2010 at 4:39 PM, Garmin Kawaguichi <
garmin.kawagui...@magalaxie.com> wrote:

>  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.  However, before we enforce script limits, which again is still
> a ways off, we will enable the ability to set a lower max memory size for
> mono scripts.  If your script really only uses 4k, congrats you can set it
> to that and it will only count as 4k, and you won't be able to use more
> until you change it.  *This will be implemented before we enforce limits*
> ."
>
> GCI
>
>
> - Original Message -
> From: "Matt White" 
> To: 
> Sent: Saturday, March 06, 2010 5:21 PM
> Subject: [opensource-dev] Script Memory Limits UI
>
> before posting to keep unmoderated posting privileges
>
> ___
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/OpenSource-Dev
> Please read the policies before posting to keep unmoderated posting
> privileges
>
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Script Memory Limits UI

[Marine Kelley]

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
modifying existing scripts. This is unacceptable for all well established
business owners who made many different script that are now spread across
SL. To me, a script should take as many bytes as it needs, not more, and
that amount of memory should vary with time. Otherwise it is not
practicable, and will break content once the limits are in place.



On 6 March 2010 21:41, Michael Schlenker  wrote:

>
> 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 opposed to LSL which takes 16k no matter what...
> >
> > If that's the case, if we have to modify all our scripts, after switching
> to Mono (which in itself was a tremendous work because it implied merging
> scripts and updating everything to our customers), then I am sorry to say
> the interest of using Mono over LSL has suddenly gone through the floor.
> >
>
> The comment from Kelly Linden on the blog didn't sound like it, it was more
> like:
> - The default allowed memory footprint of a mono script is 64 kB
> - In the future a mono script will be allowed to request more OR less
> maximum memory for itself
> - IF you know that your script only needs a tiny amount of memory, you can
> set its limit lower to ease the pressure on the sim
>  (which makes it an option for example to use 16 scripts with 4 kB and
> trivial functions instead of one 64 kB script that needs to multiplex
> things)
> - We don't want to break content. Most of the time we cannot guarantee or
> measure the maximum memory usage of a script and to prevent bad effects like
> prims that only work when the phase of the moon is right (aka the garbage
> collector timing) we simply assume a static maximum of 64kB.
>
> I agree on the issue of a horrible UI for the 2.0er memory usage though. It
> should simply sum the number of scripts and show how many LSL and how many
> Mono scripts are involved. The 16kB/64kB details are misleading and useless.
>
> Michael
> ___
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/OpenSource-Dev
> Please read the policies before posting to keep unmoderated posting
> privileges
>
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Script Memory Limits UI

[Garmin Kawaguichi]

:))

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 "small scripts" to 
LSL - is that a valid way to save on memory usage? 
[16:10] Kelly Linden: sebastean unfortunately yes. It is not the behavior we 
like, we would rather it make more sense to move to mono so we could deprecate 
LSL but that obviously isn't happening any time soon. 

GCI
  - Original Message - 
  From: Morgaine 
  To: Garmin Kawaguichi 
  Cc: Matt White ; opensource-dev@lists.secondlife.com 
  Sent: Saturday, March 06, 2010 9:49 PM
  Subject: Re: [opensource-dev] Script Memory Limits UI


  You have to be joking.  (Or rather, Kelly has to be joking.)

___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Script Memory Limits UI

[Kitty]

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.  However, before we enforce script limits, which again is still a
ways off, we will enable the ability to set a lower max memory size for mono
scripts.  If your script really only uses 4k, congrats you can set it to
that and it will only count as 4k, and you won't be able to use more until
you change it.  This will be implemented before we enforce limits."

Sorry about that :(. That empty one obviously wasn't supposed to go out at
all :o.
 
A Mono script that fits into 4Kb and accomplishes something useful would be
very interesting to see giving how much of a memory hog Mono is: the default
"Hello World!" manages to munch up 3.5Kb already (2x 512-bytes for the 2
functions in there and the other 2Kb is the stack I guess).
 
A very simple poseball script I wrote ages ago:
Legacy LSL - 2317 bytes in use / 14,067 available
Mono - 11,154 bytes in use / 54,382 available
 
Even if you can limit the amount of memory used legacy LSL seems like an
uncontested win: with 14Kb left to play with there is still plenty of room
to add quite a bit more if need be and it'll all easily fit within that
16Kb.
 
To play it safe the Mono one would have to be limited to something that's
very close to that same 16Kb anyway and with the downside that any more code
would make it surpass the legacy LSL's memory requirement.
 
With Mono apparently compiling every/most functions into multiples of
512-bytes blocks it always seemed very wasteful of memory since most
functions have a good chance of consisting of X bytes of code followed by a
(few) hundred bytes worth of "NOP" padding. Multiply that by amount of
functions (or event handlers) inside of a non-trivial Mono scripts and you
end up with double digit Kbs worth of "wasted" memory.
 
I'd rather see that deficiency in Mono addressed before anything else.
 
Kitty
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

[opensource-dev] svn compile failure on Ubuntu 9.10

[Glen Canaday]

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.dir/all] Error 2
make: *** [all] Error 2

I'm no good with templates - never use them. Anyone?

--GC
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

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

[Thickbrick Sleaford]

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/lleventtimer.o] Error 1
> make[1]: *** [llcommon/CMakeFiles/llcommon.dir/all] Error 2
> make: *** [all] Error 2
> 
> I'm no good with templates - never use them. Anyone?
> 
> --GC


This looks like SNOW-506:
http://jira.secondlife.com/browse/SNOW-506

IIRC there are two places where this happens (this and SNOW-514), and in both 
replacing the inheritance from protected to public seems to work.

-- 
Thickbrick
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Script Memory Limits UI

[Argent Stonecutter]

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 in real-time kernels.
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

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

[Glen Canaday]

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.hpp:290:31:
 
error: missing binary operator before token "("

Here's the output of 'cat installed.xml | grep boost':

boost
boost
http://s3.amazonaws.com/viewer-source-downloads/install_pkgs/boost-1.39.0-darwin-20100119.tar.bz2
http://s3.amazonaws.com/viewer-source-downloads/install_pkgs/boost-1.39.0-linux-20100119.tar.bz2
http://s3.amazonaws.com/viewer-source-downloads/install_pkgs/boost-1.39.0-linux64-20100119.tar.bz2
http://s3.amazonaws.com/viewer-source-downloads/install_pkgs/boost-1.39.0-windows-20100119.tar.bz2
boost
http://www.boost.org/LICENSE_1_0.txt

The dates are out of whack with what Brad Linden posts - he's got a 
20100222a up there. I DLd and got this extracted into the source tree 
and now get:

/home/glen/Programs/Second 
Life/Snowglobe-2.0-build/trunk/indra/../libraries/include/boost/coroutine/detail/coroutine_impl.hpp:59:
 
error: declaration of ‘typedef class 
boost::coroutines::detail::context_base 
boost::coroutines::detail::coroutine_impl::context_base’
/home/glen/Programs/Second 
Life/Snowglobe-2.0-build/trunk/indra/../libraries/include/boost/coroutine/detail/context_base.hpp:55:
 
error: changes meaning of ‘context_base’ from ‘class 
boost::coroutines::detail::context_base’

*sigh*. Never ever once has any compile of any SL viewer worked. I'm 
even downgraded to 32-bit just to get this stuff to work because of 
issues with 64-bit linux last year.

Is there a version of boost and a way to get it in there that won't bust 
the build?

--GC

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:
>> error: ‘LLInstanceTracker’ is an
>> inaccessible base of ‘LLEventTimer’
>> make[2]: *** [llcommon/CMakeFiles/llcommon.dir/lleventtimer.o] Error 1
>> make[1]: *** [llcommon/CMakeFiles/llcommon.dir/all] Error 2
>> make: *** [all] Error 2
>>
>> I'm no good with templates - never use them. Anyone?
>>
>> --GC
>>  
>
> This looks like SNOW-506:
> http://jira.secondlife.com/browse/SNOW-506
>
> IIRC there are two places where this happens (this and SNOW-514), and in both
> replacing the inheritance from protected to public seems to work.
>
>

___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

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

[Glen Canaday]

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:
>> error: ‘LLInstanceTracker’ is an
>> inaccessible base of ‘LLEventTimer’
>> make[2]: *** [llcommon/CMakeFiles/llcommon.dir/lleventtimer.o] Error 1
>> make[1]: *** [llcommon/CMakeFiles/llcommon.dir/all] Error 2
>> make: *** [all] Error 2
>>
>> I'm no good with templates - never use them. Anyone?
>>
>> --GC
>>  
>
> This looks like SNOW-506:
> http://jira.secondlife.com/browse/SNOW-506
>
> IIRC there are two places where this happens (this and SNOW-514), and in both
> replacing the inheritance from protected to public seems to work.
>
>

___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Script Memory Limits UI

[Carlo Wood]

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 than
> by calling a LSL function to request memory. Which means modifying existing
> scripts. This is unacceptable for all well established business owners who 
> made
> many different script that are now spread across SL. To me, a script should
> take as many bytes as it needs, not more, and that amount of memory should 
> vary
> with time. Otherwise it is not practicable, and will break content once the
> limits are in place.

Watch them do it; you don't really think there is a Linden that can write
a malloc library (for scripts), right?

Willing to donate his librmalloc code, that is EXTREMELY efficient with memory,
Carlo Wood


PS Here is an old post that I digged up, about a test that I did with rmalloc:

  Here is the result of a stress test program which allocates 100 random
  sized blocks, freeing and allocating at random so on average about 5000
  blocks are allocated at the same moment.

  gnu malloc:

  program output:
  max_heap_size = 8499200
  average heap size = 8372077; average allocated 5143466
  time 37.715371 s

  my malloc (called 'rmalloc'):

  program output:
  max_heap_size = 6220752
  average heap size = 6135204; average allocated 5143466
  time 35.703490 s

Thus, gmalloc had on average 8372077 - 5143466 = 3228611 bytes overhead (62%)
while rmalloc had on average 6135204 - 5143466 =  991738 bytes overhead (19%).

___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

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

[Thickbrick Sleaford]

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::coroutine_impl ContextImpl>::context_base’
> /home/glen/Programs/Second
> Life/Snowglobe-2.0-build/trunk/indra/../libraries/include/boost/coroutine/d
> etail/context_base.hpp:55: error: changes meaning of ‘context_base’ from
>  ‘class
> boost::coroutines::detail::context_base’
> 

What I did to get a non-standalone 32-bit build going with gcc4.4 was replace 
the boost in install.xml to the one from snowglobe 1.x trunk (REAL 1.39), then 
copy the libraries/include/boost/coroutine/ folder from the original boost 
package that came with 2.0 (1.34, but the file is named 1.39) into the 
unpacked new tree. Hopefully there will be proper 1.39 boost packages for 2.0 
soon.

Other than this and the SNOW-506 problem you listed above, I also had copy my 
system's libuuid.so.1 into the build tree, because (I think) the supplied 
version didn't agree with my system's DBus.

-- 
Thickbrick

___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Script Memory Limits UI

[Tayra Dagostino]

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?

each evolved OS have memory limit per user, per core or per
thread/program, is the only way to don't kill a machine if a
process/program/thread got crazy and waste all machine resource... 

the concept is good, don't waste memory, if a script need less resource
why allocate 64k (use 20k to 30k dynamically, waste 34K-44k...), maybe
the way to obtain is not shared as better

maybe before deploy this to the grid is better fit inside compiler
something usefull, like in place of "the script correctly compiled"
something like "script compiled: xxkb of code, yykb of static data,
zzkb of max dynamic data allocable", so a developer can tuneup the
scripts
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

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

[Jason Giglio]

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), LLSelectMgr actually
> returns the permissions (*and owner/creator info*) , so the viewer would
> have to select each and every object within the sim to grab its
> permissions, which seems rather wasteful of bandwidth, and troublesome
> in general.  This works fine for situations where the object is selected
> anyway (when building or right-clicking), but it's horribly inefficient
> for scripting.

A small but important distinction... it's not every object in the sim,
it's something more like "every object that's kind of close by".

I tried to write a client side feature that would gather a list of all
scripted objects in a sim, and the wall I ran into was that the viewer
is completely ignorant of the existence of up to half the objects in a
sim, and has no way of asking for information on them.

-Jason
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Script Memory Limits UI

[Frans]

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 LSL for
marketing reasons, to make a product report a lower value
Preventing LL from achieving it's goal of a full move towards MONO.

As for the dynamic vs fixed memory usage. Of course it would make sense to
have dynamic memory usage, but I haven't seen a response yet on how to solve
the problem that Kelly described, about scripts suddenly running out of
available memory to use, when they fill up lists with info, etc. And break
because of it. Or is this considered not to be a big problem?

-- 
Jeroen Frans
Virtual World Technology Specialist.
VesuviusGroup.com
SL: Frans Charming
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

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

[Glen Canaday]

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: error: declaration of ‘typedef class
>> boost::coroutines::detail::context_base
>> boost::coroutines::detail::coroutine_impl> ContextImpl>::context_base’
>> /home/glen/Programs/Second
>> Life/Snowglobe-2.0-build/trunk/indra/../libraries/include/boost/coroutine/d
>> etail/context_base.hpp:55: error: changes meaning of ‘context_base’ from
>>   ‘class
>> boost::coroutines::detail::context_base’
>>
>>  
> What I did to get a non-standalone 32-bit build going with gcc4.4 was replace
> the boost in install.xml to the one from snowglobe 1.x trunk (REAL 1.39), then
> copy the libraries/include/boost/coroutine/ folder from the original boost
> package that came with 2.0 (1.34, but the file is named 1.39) into the
> unpacked new tree. Hopefully there will be proper 1.39 boost packages for 2.0
> soon.
>
> Other than this and the SNOW-506 problem you listed above, I also had copy my
> system's libuuid.so.1 into the build tree, because (I think) the supplied
> version didn't agree with my system's DBus.
>
>

___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

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

[Ricky]

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:

Client Plugins - Binaries compiled per-platform and placed in a special
folder in the client directory by the user/admin of the client's
installation.
  These should have no security restrictions, and should have access to any
file on your computer that the system allows, and access to any internal
process of the client.
  Provides the ability to build parts of the client without recompiling: eg.
Client-side script interpreters, better joystick support, expose further
public APIs via sockets or whatever, etc.
  Also is free to access system libraries, such as OpenGL, windowing
toolkits, etc.

Client Extensions - Interpreted code packages placed in a special folder in
the client directory by the user/admin of the client's installation.
  These should run in a broad sandbox: Limited local disk access (max
datastore size, etc.) to a special file in the local user folder. Eg:
~/.secondlife/slfirst_lastname/extensions/extensionname.eds  (Extension
DataStore) But can still access much the same client hooks as the Plugins.
  Provides fast prototyping, and lower entry difficulty, than Plugins, but
will most likely not have the freedom to tap into a lot of system stuff.
 Also will not typically run as fast or in as little memory space as the
binary plugins.

Dynamic Client Scripts - Interpreted scripts loaded from the server via the
server-side permissions system.
  May still need a better name...
  Could be stored in Notecards and a server-side script could petition, via
llRequestPermissions, to be able to request that the client download the
notecard named via a llLoadClientScript(string name, integer channel) or
similar command. The notecard would then be downloaded by the client and the
plugins/extensions that had registered as able to interpret scripts would
then be queried as to their ability to understand the code, and the one that
answered with the most certainty could be given the task.  Some sort of
first-line header in the notecard would help this process along.
  Executed within TIGHT sandboxing: Limited, or no access to local disk
storage, and limited to tasks such as drawing on the HUD layer of the GUI,
creating floaters to draw in, communicating back to the world via the
predefined channel number, etc.  The limits are, of course, up to the
plugin/extension maker.  Another potential limit would be the automatic
unloading of the script when the host object is out of range, or is no
longer attached.  Of course the Plugin maker could decide when, or if, the
user should be asked before loading the script, even if the server-side has
given its permission.
  Provides the ability to make advanced HUDs, radars, etc.  These would
mostly eliminate the need for object-based HUDs, improving server speed by
taking non-content load off the server, and still allow the specialized
groups in SL the ability to create HUDs and tools that users could be given
automatically upon entering a "role-play" area.

UserScripts (Term borrowed from GreaseMonkey) - Interpreted scripts loaded
dynamically into the client by the user.
  Function just like Dynamic Client Scripts, except the source is the user
themselves opening a local text file, or opening a console window and typing
commands.
  Provides local quick changes, and even personal never-touched-the-server
HUD objects, floaters, etc.  Lowest entry difficulty of the whole set of
ideas.


Note that should the Client Plugins be implemented, all the rest, and more,
could and would be implemented in droves.  Also any security restrictions,
or lack thereof, would be created by the plugin designer.  The above
security restrictions would then be only guidelines.

These seem to cover the whole range of what has been discussed so far.
 Morgaine's interpreted client scripts/plugins communicating via sockets
would be considered Client Extensions and would be implemented starting with
a really generic Client Plugin.  This is assuming that I've understood
Morgaine's idea correctly! :)

Yes, I've been mulling this over and over in my brain since the previous
conversation was interrupted  I had just gotten to the point where I was
enjoying the back and forth of problem solving!

Ricky
Cron Stardust
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges