Re: [opensource-dev] Snowglobe 2 update
Am 24.02.2010 um 09:51 schrieb Lance Corrimal: > Am Mittwoch, 24. Februar 2010 09:26:12 schrieb Thomas Shikami: >> Philippe (Merov) Bossut schrieb: >>> - SOCKS5: here, Robin volunteered >> >> SOCKS5 is against the TPV Policy term >> 2c. You must not circumvent any security-related features or measures we >> may take to limit access to Second Life. For example: >> 2c.i.You must not mask IP or MAC addresses. >> >> SOCKS5 is usually used by griefers to mask the IP address. > > > I'd say "bull" here. While it is true that the IP address of traffic coming > thru a socks (or any other) proxy is the ip of the proxy, the mac address IN > THE IP HEADER is the one of the router anyways... if any. > > What LL means is "You must not circumvent the viewer finding out its local > mac > address and sending that in the authorization data". Which is silly anyway as any decent network card can change its MAC via its driver. 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
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] Question regarding llSetLinkPimitiveParamsFast() function in 1.38.0
Am 07.03.2010 um 15:39 schrieb Obsidian Kindragon: > Hi all, > > I've a quick question regarding the new llSetLinkPimitiveParamsFast() > function in 1.38.0. Why did LL opt for a new function instead of just > removing the delay from the current llSetLinkPrimitiveParams() function? > I can't conceive any case where removing the delay from the current > function would break any existing content. Simple example where it would break existing content: - someone uses llSetLinkPrimitiveParams() for some animation - the delay is gone and now the timing of the animation is totally different 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 Management Algorithm
Am 08.03.2010 um 18:46 schrieb Kelly Linden: > We are not out to write a new malloc for mono. What we have is a system that > throws an exception when the memory used by the script hits a certain > threshold (64k currently). This exception is caught so we can "crash" the > script. The future small scripts and big scripts projects will add new > functions to set and get this threshold value, allowing scripters to > effectively control how much memory is reserved for their script. We will > continue to use mono's default memory management within the reserved memory > thresholds. It is a much simpler problem to solve. > While your at it, how about a static analyzer for mono/LSL that determines guaranteed lowest memory consumption for a script and sets the threshold there. That would have the benefit of easing scripters work by providing useful defaults for all the easy cases without them having to do anything at all. The scheme should only break down if the mono GC behaves weird. In that case scripters have a huge problem anyway as they cannot set any threshold without being crashed at random by a lazy GC. 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 Management Algorithm
Am 09.03.2010 um 02:54 schrieb Lear Cale: > huh? Can you point to existing technology for this analyzer? Seems > to me like it would require an oracle. It might require an oracle to reach 100%, but if you go for the easy part, its not that hard (assuming a sane GC). LSL is a pretty simple language without many of the problems you have with C like pointers and memory aliasing and stuff like that. Not sure if one could reuse parts of the LLVM analyzers/optimizers for Mono to do this (Mono 2.6 can compile for a LLVM backend). 1. All scripts that only handle integer, float, vector, key and rotation variables without recursive calls can be handled easily. --> The memory size for those types is fixed. --> One could probably compute a complete callgraph and add up the maximum number of used locals too. 2. If the script uses recursion, it depends. If the compiler can figure out the maximum depth, works as 1, if it can eliminate tailcalls, it can do 1. too. If it cannot, its a lost cause and it must assume the worst aka 64kB. 3. If the script uses strings, it depends what operations are used on those strings. The only critical operation is appending strings to other strings, comparing, getting substrings etc. could all be done in constant memory. As all functions that can provide strings to a script have an upper bound on parameter size one could calculate a 'worst case' scenario in many cases. Just assume any LSL function or event that returns/provides a string provides a unique string of maximum size. Sum up and you have a worst case limit. 4. If the script uses lists of other data types use similar techniques as for strings. As LSL does not have any reference types and you cannot nest lists this is not too hard to do because list are essentially flat like strings. This of course assumes some small glitches are allowed like the overhead of copying a string/list, because the gc can free that memory at once if needed. For simple scripts, e.g. the ugly 100s of 'resizer' scripts you find in hairs, shoes etc. this could work pretty well, as those are usually just one link_message handler with trivial code and one or two functions that call llSetPrimitiveParams(). You might overestimate by one or two kB, because you don't know how big the link_message string and key parameters are, but other than that it should work pretty well. Michael > > On Mon, Mar 8, 2010 at 2:03 PM, Michael Schlenker > wrote: >> >> Am 08.03.2010 um 18:46 schrieb Kelly Linden: >> >>> We are not out to write a new malloc for mono. What we have is a system >>> that throws an exception when the memory used by the script hits a certain >>> threshold (64k currently). This exception is caught so we can "crash" the >>> script. The future small scripts and big scripts projects will add new >>> functions to set and get this threshold value, allowing scripters to >>> effectively control how much memory is reserved for their script. We will >>> continue to use mono's default memory management within the reserved memory >>> thresholds. It is a much simpler problem to solve. >>> >> While your at it, how about a static analyzer for mono/LSL that determines >> guaranteed lowest memory consumption for a script and sets the threshold >> there. >> >> That would have the benefit of easing scripters work by providing useful >> defaults for all the easy cases without them having to do anything at all. >> >> The scheme should only break down if the mono GC behaves weird. In that case >> scripters have a huge problem anyway as they cannot set any threshold >> without being crashed at random by a lazy GC. >> >> 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 Management Algorithm
Am 09.03.2010 um 23:57 schrieb Michael Schlenker: > > Am 09.03.2010 um 02:54 schrieb Lear Cale: > >> huh? Can you point to existing technology for this analyzer? Seems >> to me like it would require an oracle. For an example of such a technique for Java bytecodes: http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.100.1873 > > It might require an oracle to reach 100%, but if you go for the easy part, > its not that hard (assuming a sane GC). LSL is a pretty simple language > without many of the problems you have with C like pointers and memory > aliasing and stuff like that. Not sure if one could reuse parts of the LLVM > analyzers/optimizers for Mono to do this (Mono 2.6 can compile for a LLVM > backend). > > 1. All scripts that only handle integer, float, vector, key and rotation > variables without recursive calls can be handled easily. > --> The memory size for those types is fixed. > --> One could probably compute a complete callgraph and add up the maximum > number of used locals too. > > 2. If the script uses recursion, it depends. If the compiler can figure out > the maximum depth, works as 1, if it can eliminate tailcalls, it can do 1. > too. If it cannot, its a lost cause and it must assume the worst aka 64kB. > > 3. If the script uses strings, it depends what operations are used on those > strings. The only critical operation is appending strings to other strings, > comparing, getting substrings etc. could all be done in constant memory. As > all functions that can provide strings to a script have an upper bound on > parameter size one could calculate a 'worst case' scenario in many cases. > Just assume any LSL function or event that returns/provides a string provides > a unique string of maximum size. Sum up and you have a worst case limit. > > 4. If the script uses lists of other data types use similar techniques as for > strings. As LSL does not have any reference types and you cannot nest lists > this is not too hard to do because list are essentially flat like strings. > > This of course assumes some small glitches are allowed like the overhead of > copying a string/list, because the gc can free that memory at once if needed. > > For simple scripts, e.g. the ugly 100s of 'resizer' scripts you find in > hairs, shoes etc. this could work pretty well, as those are usually just one > link_message handler with trivial code and one or two functions that call > llSetPrimitiveParams(). You might overestimate by one or two kB, because you > don't know how big the link_message string and key parameters are, but other > than that it should work pretty well. > > Michael > >> >> On Mon, Mar 8, 2010 at 2:03 PM, Michael Schlenker >> wrote: >>> >>> Am 08.03.2010 um 18:46 schrieb Kelly Linden: >>> >>>> We are not out to write a new malloc for mono. What we have is a system >>>> that throws an exception when the memory used by the script hits a certain >>>> threshold (64k currently). This exception is caught so we can "crash" the >>>> script. The future small scripts and big scripts projects will add new >>>> functions to set and get this threshold value, allowing scripters to >>>> effectively control how much memory is reserved for their script. We will >>>> continue to use mono's default memory management within the reserved >>>> memory thresholds. It is a much simpler problem to solve. >>>> >>> While your at it, how about a static analyzer for mono/LSL that determines >>> guaranteed lowest memory consumption for a script and sets the threshold >>> there. >>> >>> That would have the benefit of easing scripters work by providing useful >>> defaults for all the easy cases without them having to do anything at all. >>> >>> The scheme should only break down if the mono GC behaves weird. In that >>> case scripters have a huge problem anyway as they cannot set any threshold >>> without being crashed at random by a lazy GC. >>> >>> 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 ___ 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] Fixing the 2.0 chat bar focus problem?
Am 17.03.2010 um 00:29 schrieb Zi Ree: > Am Mittwoch 17 März 2010 00:21:42 schrieb Glen Canaday: > >> Most of the people I have known in SL shop, go to clubs, create, RP, and >> hang out, most of which requires chatting without an extra step to >> switch focus. Leaving the chat bar with focus kills wasd movement, but I >> can name no one who doesn't use the arrow keys for that. > > What I usually do is having the chat bar hidden, walk around with WASD or > cursor keys, whatever is appropriate at that moment, and call the chat bar up > by pressing Enter when I need it. That's one thing I would lve to see coming > back in 2.0. Autohide chat bar. +1 Was the first thing i missed from 2.0. 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] display names = the end of 1.x viewers?
Am 18.08.2010 um 01:16 schrieb Bryon Ruxton: > Sorry if lacked clarification, > I was referring to the "current" residents names (as capitalized), NOT the > new display name which will become the person's username as I understand it. > > Because of the added flexibility with Display Names, I see it a good > opportunity to enforce the official First and Last name both capitalized > when shown and possibly clean up the legacy database of "First & Last" > names. This will break content if it hits the scripting layer. E.g. i have some scripts that derive things from the current username (including upper/lowercase distinction), and if you simply capitalized names it would break. Same with the aformentioned scripted access control lists. > > i.e. Someone named currently named "iama Linden" would be changed > automatically to Iama Linden as his display name which he can change to > lower case via his display name box he chooses so, like dahlia here does. > > Even if that was to apply to future usernames "when first chosen". > You could very well enforce a first capital and still allow for lowercase > display names after that, or even have a checkbox to prevent the automatic > JavaScript capitalization at registration. But it would fair to say that > lack of fist name capitalization due to users omission is much more common > than a deliberate intent coming from the user. So I view "initial > capitalization" as a default setting for that reason. > > And 2. you should also prevent anyone to use a display name baring the name > of an existing username in my opinion. NO. That would limit the usefulness for some kind of RP for sure. Might be okay if it was not allowed for IM or if IM always showed the old style name too. And maybe you noticed that lowercase/uppercase transformation is not a lossless operation (okay, might be due to the restrictions on SL firstnames, but in general its a lossy operation). 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] display names = the end of 1.x viewers?
Am 18.08.2010 um 15:05 schrieb Argent: > On Tue, Aug 17, 2010 at 6:47 PM, Michael Schlenker > wrote: > Am 18.08.2010 um 01:16 schrieb Bryon Ruxton: > > And 2. you should also prevent anyone to use a display name baring the name > > of an existing username in my opinion. > > NO. That would limit the usefulness for some kind of RP for sure. > > Can you elaborate on what kind of RP would require you to be able to set your > display name to "Argent Stonecutter"? > Sure. Anywhere you wanna have uniform appearance, like having a bunch of 'Agent Smith' AVs in black suits to give the impression of identical twins or clones. And compare to reality, where you cannot totally prevent anyone to use your name either, unless its used as a corporate name. It would have loved to ban others to use the firstname 'Michael', but that wasn't possible in RL, and so 7 of 28 of my classmates in 1st school class were named Michael. Its just like that, names are not unique if your horizon in time and space gets large enough. BUT there you have of course a point when you fear imposters and other people that try to make your name look bad due to their actions under your 'name'. Same issue in RL, you can go to court over it, or file criminal charges, not nice. The limitation is kind of arbitrary. Maybe if 'Display Names' got some hinting (e.g. by using a different font or some other UI hint), to distinguish them from 'transplanted' usernames it would be good enough for the trivial imposter cases. 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] display names = the end of 1.x viewers?
Am 19.08.2010 um 11:51 schrieb Argent Stonecutter: > > On 2010-08-18, at 13:19, Michael Schlenker wrote: >>> Can you elaborate on what kind of RP would require you to be able to set >>> your display name to "Argent Stonecutter" > >> Sure. Anywhere you wanna have uniform appearance, like having a bunch of >> 'Agent Smith' AVs in black suits to give the >> impression of identical twins or clones. > > That wouldn't be "having the same display name as a user name". > > That would be "having the same display name as another display name". I'm not > talking about that. Is anyone talking about that? > Its a special case of the general case, i didn't check but I'm pretty sure 'Agent Smith' is taken by someone. If it is and you had your way it would not be possible to use that name. But lets have another take at this, you want to ban people from using 'Argent Stonecutter' as a display name, fine. How about any homographs of your current SL name, should they also be banned? http://en.wikipedia.org/wiki/IDN_homograph_attack It opens a can of worms. How about a display option in the viewer that can 'highlight' the fact that your display name is the same as your username (different colour, font or an other UI hint). That would prevent many of the imposter issues, as it would be pretty obvious. Maybe an opt-out to deny the use of current usernames as display names would be appropriate, but a general ban to reuse a current username as a display name sounds a bit excessive. 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] display names = the end of 1.x viewers?
Am 19.08.2010 um 21:30 schrieb Daniel Smith: > On Thu, Aug 19, 2010 at 12:09 PM, Michael Schlenker > wrote: >> >> >> How about a display option in the viewer that can 'highlight' the fact that >> your display name is the same as your username >> (different colour, font or an other UI hint). >> That would prevent many of the imposter issues, as it would be pretty >> obvious. >> >> Maybe an opt-out to deny the use of current usernames as display names would >> be appropriate, but a general ban to reuse a current username >> as a display name sounds a bit excessive. >> > > The default situation should be "I have taken a moment to think about > the implications > of others using my username, and I trust them, and I am fine with > that, so I will > make the decision to turn it on". > > I still have not heard a definitive answer as to what gets logged in > IM and Chat. > Forget the "display" for a moment. What do you want to have logged as > "Michael Schlenker" > that you did not write? Well 'Michael Schlenker' is common enough that i regularly have issues with the name (and even more so initials) being taken already and even getting emails and stuff because of that. So i do not worry about things getting logged with my name, as i know it happens, and does not create huge troubles, unless some malicious person actively exploits it (or some agency is incompetent like the social registry in germany which messed up my records with the ones of my twin for years). But you look from the wrong direction and construct unrealistic scenarios. 1. If you log things, use the UUID internally, store the display name with it (as it can change) and make it just a display option what is shown, ever other way to implement logging is simply wrong 2. For the UI either make an option so display names that match the legacy username of the AV are highlighted or the opposite, to provide an easy non script based option to verify a legacy username users identity via name alone. 3. Provide an explicit opt-out for those that are seriously worried (typically shop owners, or other 'public figures'). That would pretty much match the typical regulations in RL, at least in germany (don't know enough about US or other law). The fact that your current username is unique is just a coincidence of the LL decision to use that username as a key in their database. Its not a natural law to have a unique name. 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] The Plan for Snowglobe
Am 11.09.2010 um 17:31 schrieb Zi Ree: > Am Samstag 11 September 2010 17:22:33 schrieb dilly dobbs: > >> it more like a game with a limited number of opening/learning the interface >> 'quests' so to speak. There has to be some way to keep all of the sign >> ups. > > The old orientation islands had all this. It never really worked out. > And they failed miserably. I was stuck on one of those for a few hours till i found out how to TP away from orientation island. And it took the help of Torleys Videos to find out how to open the freebie boxes. In fact, the orientation island nearly succeeded in keeping me from ever logging in again. I was just determined enough to get past it. 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
