Re: [opensource-dev] Linux 64bit and gstreamer
On Fri, Dec 10, 2010 at 09:33:36PM +0100, Altair Sythos Memo wrote: > On Fri, 10 Dec 2010 12:51:54 -0500 > Mike Chase wrote: > > > Hi all, I have a new machine coming and given the amount of memory it > > has I'd really like to run it 64bit linux (probably ubuntu). I'd > > really like to stay with the ability to run SnowStorm (and the Mesh > > viewer builds). Can someone point me to a summary of 64bit support > > for Linux for that series of viewers? I know in the past I was able > > to run a 32bit version but with no streaming media. Thats a non > > starter for me as I own a club in SL and its kinda nice to be able to > > hear what's being played in the club. > > sudo apt-get install ia32-libs ia32-libs-gtk ia32-libs-kde ia32-libs-sdl Huh huh... No need to install 32bit libs! Just compile the viewer yourself! I've been running native 64 bit since day one. -- Carlo Wood ___ 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] STORM-797 and other ideas about Landmarks&SLURLS (was "Daily Scrum Summary - dec. 23")
I can't believe that it isn't possible to create a LM without going there, precisely for this reason. What LL might really mean is that they can't check if it's allowed to *create* a LM without going there first. So, it's a permission problem. But, since there clearly is a way to attempt to go anywhere (by using the map, or an slurl) that whole 'permission' thing is flawed. It's meaningless. I used to have a sim and I didn't allow people to create a LM (I only wanted them to there when I (or another resident) actually was there, and invited them over. However, once they got (group) access, they came anyway, without being invited... I asked how, and they said: simple, I clicked on the map. The problem here is therefore (imho): LL needs to understand it is impossible to control whether or not someone creates a LM and allow us to write code that creates arbitrary LM's for any place, without going there first. On Fri, Dec 24, 2010 at 12:17:21PM +0100, Opensource Obscure wrote: > On Fri, Dec 24, 2010 at 11:03, Vadim Savchuk > wrote: > > > Do you mean creating a landmark in your inventory by pasting a SLURL? > > I'm not sure that's possible: AFAIR, to create a landmark we perform a > > request to the server, which creates landmark of the current location in our > > inventory. The protocol doesn't support remote locations. > > sorry, I was not clear (ouch, my English!) > > What you described is exactly the problem I have with landmarks. > Having to teleport somewhere to get a landmark can be a PITA. > I remember LL confirmed there are no workarounds for this > (as you said, it's a protocol limitation). > > What I was thinking about was a new, different way to achieve > something we usually achieve through landmarks.. > (find a place in our Inventory + teleport there + optionally > share that place reference with other users) > ..a way that could avoid that very limitation you mentioned > (the need to be in a place in order to create a landmark). > > In the past I often didn't use landmarks - instead I copied SLURLs > from web pages and paste them into local chat, then click over > the links, then teleport. > Thanks to some new features, this is now less useful than in > the past - but I think some 1.x viewers users still do this. > > Going through local chat is clearly lame, and confusing for > people around you. That's why I said I would like to > "copy/paste" a SLURL into Inventory, create > (not a landmark) and then clickit to teleport. > I'm thinking about management of Bookmarks in current > main web browsers, where you're allowed to edit > both name and destination of a bookmark, tag it, > assign to multiple folders (or tags). > > Does this make sense to anyone here? > > Opensource Obscure > ___ > 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 -- Carlo Wood ___ 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] STORM-34 Test Binaries
> I kinda have to agree with hitomi. I agree with Andrew; it's a privacy sensitive thing and users shouldn't accidently flip it without thinking because it's on the normal 'General' page. If they need or want it, then I'm sure they'll find it, like they find everything else. Also, it will take a while before a user needs links to favourite places on their login page: those are not newbies. It's sufficient to put the option in a place that requires more knowledge (and exploration) of the viewer interface. -- Carlo Wood ___ 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] Indicating privacy implications of preference settings (was: STORM-34 Test Binaries)
Ok, good points. I take back what I said :). The best way forward seems to put it where people might first look and then make clear that everyone can see them with text right there. On Tue, Dec 28, 2010 at 10:58:01PM +0100, Boroondas Gupte wrote: > On 12/28/2010 09:40 PM, Celierra Darling wrote: > > It seems a little unclear to try to communicate "this can have privacy > implications" by putting the setting on the privacy tab. It might be > better to write the setting label so it's more explicit (i.e. something > like "Show my favorites to anyone under 'Start At' before logging in" or > "Show my favorites under 'Start At' on login (before authenticating)" or > etc.). > > I have to agree that placing settings on the "privacy" tab is not a good way > to > indicate the fact that they have privacy implications. It goes against the > principle that a setting should be placed where users expect it. I.e., if you > know (or suspect) a setting exists, but don't know where to find it, where > would you first look for it? Education about the consequences of changing the > setting can be postponed until after you found it. > > Of course, besides looking at tab labels, placing similar or related settings > together can help in finding them. But the common property "affects privacy" > seems to me too week a reason for placing settings on the same tab, when that > property is not the goal of a setting but rather a side effect (even although > a > side effect inherent to the goal itself, not just to the setting's > implementation). > > Further, when a user finds a setting on the "privacy" tab and realizes this > placement means the setting has privacy implications, how would she or he know > whether enabling or disabling the setting grants higher privacy? Of course, if > one can derive from the description of a setting what it actually does and > then > thinks it all through, one gets the answer as well as how one's privacy would > be affected. While the users are probably well capable to do that, do they > want > to do that—when they could just as well be told openly about the setting's > effect, e.g. like in Celierra's labeling proposals above? > > 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 -- Carlo Wood ___ 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] Very Strange occurrence...
It is still a (serious) bug. The viewer should have showed '???', not Grumpity. On Wed, Dec 29, 2010 at 08:44:02AM -0800, Brian McGroarty wrote: > That was the result of a brief load server configuration problem yesterday, > and > it shouldn't repeat. The message didn't come from Grumpity, and the response > wouldn't have gone back to Grumpity either. The viewer simply didn't know > which > cached name to use. -- Carlo Wood ___ 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] Inventory incremental search (VWR-23712)
One reason that it's collecting dust might be that it isn't know if the author of the patch signed the Contribution Argeement. On Tue, Jan 04, 2011 at 03:32:45PM +0100, Satomi Ahn wrote: > Hello and happy new year. > > I hate spamming this list, but there is an easy bug I'd like to see > fixed in the viewer, and which seems to have been only taking dust in > the JIRA for two entire months. > > This is about one of the bugs who contribute to the general feeling of > sluggishness in Viewer 2, so I believe you should really consider > inclusion in viewer-development ;-). > > Enough spoken, everything is there, patch included: > https://jira.secondlife.com/browse/VWR-23712 > > -- > Satomi Ahn > ___ > 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 -- Carlo Wood ___ 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] Very Strange occurrence...
On Wed, Jan 05, 2011 at 04:44:31PM -0500, Kent Quirk (Q Linden) wrote: > So the reason that semi-plausible strings are used for these things is that > they're the only strings available when we use the test floater feature from > the login screen. > > But we should probably try not to use real names. > > And yes, Jonathan, these should mostly never be visible. But sometimes things > happen. Nevertheless, it is a bug; if whatever failed is outside the influence of the viewer itself, then still it should not have shown this. The viewer should be fixed to show the account name, or at least the UUID, in this -hopefully- rare case. -- Carlo Wood ___ 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] STORM-243 - simulator version notifications
Delete! On Tue, Jan 18, 2011 at 10:22:45AM -0500, Kent Quirk (Q Linden) wrote: > Hi, folks. I've just commented on STORM-243, which requests that we have Yet > Another Option to allow suppression of the toast that tells you the simulator > version changed when you changed to a new region. > > I think we should delete it entirely. Does anyone care to still get that > notification, now that there are usually 3 different simulator versions live > on the grid at any time? I don't mean "I can think of an obscure scenario > when someone might care." I mean does anyone really need a notification about > this, or can we just delete it? > > ___ > 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 -- Carlo Wood ___ 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] Review viewer -- draw distance slider
If you like Snowglobe v1, then why aren't you using Singularity? http://www.singularityviewer.org/downloads It's been worked on hard to make it entirely Viewer 2 engine with a viewer 1 UI. It's perfect. It's also incredibly much faster due to other improvements ;) On Fri, 10 Jun 2011 20:59:38 -0700 a...@skyhighway.com wrote: > Guys, the whole thing with the easily accessible slider for draw > distance is really great! Inspiring, actually. It's almost enough > to make me wanna try out the v2 viewer again. i hope the feature > gets back-ported to Snowglobe v1 by someone better at that stuff than > me. > > The binocs idea for the icon is the best! It's totally like the > average person is going to think about it. And it's the way our eyes > work. Maybe spend time coming up with the best binocs icon or icon > loc so it doesn't get confused with what everybody sees for "search" > everywhere, but i can't think of anything better unless it was a > magnifying glass (also over-used), eyeglasses, or a telescope. Maybe > somebody wants to look at a collection on the web of what camera mfrs > put on their focus buttons? (Maybe just the word "ZOOM" instead of an > image?) > > And, being able to pull it down as far as possible is a good thing. > Sometimes in tight spaces with lots of avis anything else is just a > waste. Or distraction. Or both. And however far out it can go, even > for short periods or whatever would be awesome! There's the maps and > then there's actually being able to *see* what's up. But one thing i > don't think i've seen in the discussion, wouldn't it be a good idea > to have an auto-reset take place on every tp? Have it go to some > standard value that works pretty good most places, and it'll save > forgetful or excited people problems. i mean, if the control is > right there and easy to adjust, why not make it more useful than just > improved eyesight? > > Thx again! You guys are great! > > - AK > > > In case you missed the message from Oz in a different thread here is > the review viewer for the proposed draw distance slider: > http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repooz_project-3/rev/232119/index.html > > There is a temporary binocular graphic next to volume slider where you > access the control from. > > There is discussion within LL if this will be taken in. The concerns > are for new residents 1) having too many options on the screen and 2) > performance or experience issues if the slider is moved too far in > either direction. > > Please write back with your feedback, > > -Jonathan > ___ > 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 -- Carlo Wood ___ 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] Review viewer -- draw distance slider
I think that no matter what you draw, the icon will not be clear to the majority of people. The icon only needs to be recognizable to those who saw it before. They will have to learn it's meaning from the tool tip imho. Nevertheless, binoculars are usually used for either zoom or search, so I think another icon would be better. Thinking about an avatar with a (half) sphere around it, I'd use as icon a circle with a dot in it, or a half circle with a vertical line in the center, ie: _ - _ . . / O \ --|-- On Mon, 13 Jun 2011 12:14:11 +0200 Opensource Obscure wrote: > While clear, such an icon doesn't look much self-explaining to me > with regard to its associated Draw Distance functionality. > > I still feel binoculars may be the best option. > > Binoculars may not be a commonly used glyph outside of SL, > but it's a fact that many Second Life features are just .. not > commonly used features. In most applications / online services / > information environments or RL appliances, you just don't have the > concept of "Draw Distance" or anything similar. > > On Mon, Jun 13, 2011 at 11:49, Hitomi Tiponi > wrote: > > Yes it's possible (see attached) - but something like that says > > 'landscape' or 'plants' to me. > > > > > > From: Argent Stonecutter > > To: Hitomi Tiponi > > Cc: a...@skyhighway.com; opensource-dev@lists.secondlife.com > > Sent: Mon, 13 June, 2011 1:58:54 > > Subject: Re: [opensource-dev] Review viewer -- draw distance slider > > > > On 2011-06-12, at 17:30, Hitomi Tiponi wrote: > >> /me looks forward to seeing someone draw this one in a 16x16 pixel > >> grid :) > > > > I think three small pine trees could be rendered in a 16x16 grid. > > > > ___ > > 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 > > > > > -- Carlo Wood ___ 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] More proposals for draw distance slider icon (Mike Chase)
On Tue, 14 Jun 2011 13:49:30 -0500 Daniel wrote: > For the icon, label it "DD" for draw distance. That will fit in > 16x16 pixels, and not conflict with other symbols. I like this idea. Made an icon for it: -- Carlo Wood <>___ 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] Draw Distance will not be automated
Draw distance never makes a significant difference for me. Strange actually, cause I think it should... But it's not a very important factor it seems :/ Something that seems to correlate a lot with a low FPS is the number of avatars that have to be rendered. On Sun, 19 Jun 2011 06:49:19 -0400 "Oz Linden (Scott Lawrence)" wrote: > This has gotten a bit out of hand... We are absolutely not going to > automate draw distance. > > This got started as a speculative discussion that forked off of the > draw distance slider in which I asked whether or not it might be > possible to create a system that _if_explicitly_requested_, some > smart software could look at what factors in a users configuration > might be changed to improve FPS and advise the user on changes that > might improve performance. While DD might be one such parameter, > the system I asked about would not be an interesting contribution at > all if it were the only factor, and I never envisioned a system that > would actually change anything automatically - it would inform and > educate the user as to what settings changes might be made to improve > performance. > > > ___ > 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 -- Carlo Wood ___ 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] Mesh viewers and tcmalloc issues
On Sun, 2 Oct 2011 10:20:47 +0200 Henri Beauchamp wrote: > Really, the only true motivation behind the use of tcmalloc in mesh > viewers (it was not use for non-mesh viewers) is to provide aligned > allocations. Without it, and the way the mesh viewer code is written, > the viewer simply crashes as soon as it tries to perform an SSE2 > operation on an unaligned structure. Use _mm_malloc, if that doesn't exist use posix_memalign and if that also doesn't exist, just use malloc. That will work (for sse2 alignment). tcmalloc is to get speed from not having to lock threads when they allocate memory: they each have their own pool. I never saw any evidence that the main thread is waiting considerable long times (ie > 10 usec) on a lock in malloc because other threads are trying to alloc/free memory, so I don't see the need for tcmalloc in the viewer. I think LL fell in love with it for their server, but the decision to use it for the viewer is wrong. -- Carlo Wood ___ 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] Inventory Patch you should integrate
On Thu, 9 Feb 2012 20:14:10 +0100 Henri Beauchamp wrote: > On Thu, 09 Feb 2012 14:11:30 -0500, Oz Linden (Scott Lawrence) wrote: > > > Henri, that protocol is not subject to change at this very late > > date. > > LOL !... You are kidding me, right ?... What's the use to ask for > feedback if everything is already settled ?... That got to be a > (very bad) joke !!! This is exactly what you can and should expect from Linden Lab by now... When did they EVER really listen? -- Carlo Wood ___ 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] Pathfinding alpha announced
On Fri, 17 Feb 2012 22:33:59 -0200 Tigro Spottystripes wrote: > Wouldn't it be better if the "types" for the diffferent Walkable > coeficients were bitmasks instead of just A, B , C, D? Or perhaps > even just an editable list of IDs (integers values) and the > associated weights for each integer Don't try to have influence on what LL designed behind closed doors. It is already set in stone. -- Carlo Wood ___ 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] tired of the bad testting
On Mon, 26 Mar 2012 12:15:20 -0400 "Oz Linden (Scott Lawrence)" wrote: > On 2012-03-25 23:56 , Flats Fixed wrote: > the latest stable came out. it broke the teleporters at 2100 meters. > you know guys this is not a jira this is simple testing. love the > new policy but the fact is the team is running people out of SL. test > it befor it goes stable. > > Perhaps you could provide a clear problem report? > > What software were you using? The latest stable. > What did you do? Try to teleport back after teleporting to 2100 meter. > What did you expect to happen? The same as with the older viewers. > What actually happened? It didn't 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] Linux toolchain update... testers needed.
On Wed, 6 Jun 2012 13:59:02 -0700 Christian Goetze wrote: > I believe the main challenge is to rebuild all the third party > dependencies in 64bit ... Rofl - something that LL certainly isn't capable of ;) Loads of third party viewers have done this already however. I have never used anything else than a native 64-bit build, ever since I started using SL. -- Carlo Wood ___ 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] New HTTP Library & Project Viewer
On Fri, 27 Jul 2012 16:59:18 -0400 holydoughnuts wrote: > On 7/27/2012 1:46 PM, Oz Linden (Scott Lawrence) wrote: > > Project Viewer for testing is here: > > > > http://wiki.secondlife.com/wiki/Linden_Lab_Official:Alternate_Viewers#HTTP > > > > Especially if you have had problems when you enable the use of > > HTTP, we would very much appreciate your giving this a try. We > > know that it does not yet solve all the problems, but we think that > > it solves some and provides the first steps needed for solving some > > more in the future. > I threw this at a pretty modest CPU, an Athlon II 170u single core > dealie, and the difference there was pretty substantial. Under Linux, > HTTP texture loads went from slightly sluggish, to feeling about the > same as with them switched off. > > On Windows 7, the difference was much more dramatic. Mainstream > viewers have been painful and jerky for a long time on that machine > even with HTTP textures off. This viewer is running firmly on the "I > can live with this" side, even with HTTP textures enabled. Flying > around in some heavily built areas was even tolerable. The implementation that I wrote for Singularity (not yet in the the official release) is more on the side of "blazing fast" :p. The bottleneck is entirely server-side, but I've seen download speeds of 1 MB/s non-stop till all textures were there. This code should be in the next release in about a week. I'm currently working on implementing upcoming support for connection reuse by the servers (although that will still take a long time before they will start to support that, I understood). I'd like to opt that this code will be an alternative for third party viewers, and might very well turn out to be more robust ;) -- Carlo Wood ___ 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] New HTTP Library & Project Viewer
On Sun, 29 Jul 2012 10:07:18 +0200 Henri Beauchamp wrote: > On Sun, 29 Jul 2012 05:23:15 +0200, Carlo Wood wrote: > > > On Fri, 27 Jul 2012 16:59:18 -0400 > > holydoughnuts wrote: > > > > The implementation that I wrote for Singularity (not yet in the > > the official release) is more on the side of "blazing fast" :p. > > The bottleneck is entirely server-side, but I've seen download > > speeds of 1 MB/s non-stop till all textures were there. > > With just a few tweakings to the texture fetcher (and in particular > a setting that permits up to 32 concurrent HTTP fetches), I get much > more than 1MB/s in the Cool VL Viewer... In fact, I'm more in the > 10MB/s+ range while rezzing in heavily textured areas and the rezzing > time is pretty low... This has been so for many months (well over > a year actually) already. I agree that that would be an advantage for the user; but it's not clear to me if it is allowed (or will be in the near future) to have 32 concurrent fetches. The rationale that it SHOULD be allowed is that the user will download those textures anyway; so, you might as well allow them to get it quickly, in a short time: this has no influence on the average number of open file descriptors on the server. I understand that LL is afraid that once viewers can keep sockets open (for reuse) that the servers run out of filedescriptors. Of course, this is all to true. Therefore I propose to set a limit on the maximum number of UNUSED filedescriptors. However, there should be no limit or a much higher limit, on the number of connections that are actually in use. The question is then: when is a filedescriptor "unused"? Well, I'd say that for the sake of re-use, it can be considered unused if there hasn't been a new request for it for -say- a second. It's probably best to define multiple stages, that is: * Allow a maximum of 32 connections. * Allow up to 32 connections that are unused for 1 second. * Allow up to 8 connections that are unused for 10 seconds. * Allow up to 2 connections that are unused for 1 minute. * Allow 1 connection to be unused for 20 minutes (or whenever one leaves a region and it can be determined that this server won't be needed or used anymore). Of course this means that upon teleport to a new region with many unknown textures, the viewer will make 32 new SSH connections, but that is MUCH less than one new connection PER TEXTURE, as we have now. Then all those connections are reused until all textures have been downloaded (a few seconds). Other strategies are possible, like NOT immediately creating a new connection as long as the maximum of 32 connections haven't been used up yet, but waiting with that until there's a queue of requests building up. Bottom line is, I'm afraid that Linden Lab is going to take the (too) simplistic route as they often have done in the past, and do something very silly like: * Allow a maximum of 2 connections, and allow to keep them open indefinitely. I hope you see the difference :p I argue that something like that makes no sense and would hurt the user because they'd have to wait unnecessary long before everything downloads. -- Carlo Wood ___ 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] New HTTP Library & Project Viewer
On Tue, 31 Jul 2012 19:03:09 -0700 Kadah wrote: Kadah, Please note that I cannot read your posts. They have no clear text in them, and exist only of a Microsoft(tm) company specific attachment. You might want to fix this. -- Carlo Wood ___ 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] New HTTP Library & Project Viewer
On Thu, 2 Aug 2012 02:01:45 -0700 Dahlia Trimble wrote: > I can't help but think something is wrong here. A single TCP/IP link > is more than capable of saturating available network bandwidth with > efficient transfers of large volumes of data provided the end-points > can produce and consume quickly enough. > > It seems part of the problem may in the request/response nature of > HTTP. The viewer needs to make a request for each asset it needs as > it discovers it needs it. It sends a request for each asset, and the > provider endpoint then has to do whatever it does to make the asset > available before beginning to send it back to the client. This may > occur relatively instantly in the case of assets in a server memory > cache, or a lot longer depending on where it needs to be pulled from > or how it may need to be prepared. Assuming this is the case, having > multiple overlapping requests can improve the overall download rate > of multiple assets by allowing some downloads to occur while others > are prepared, albeit at the expense of additional connections. Having > a persistent connection reduces some of the delays introduced by > re-establishing a connection for each asset, but it does nothing to > reduce the time that the server endpoint needs to acquire and prepare > the asset to send. > > Now (assuming this isn't the case already) if the producer endpoint > could be made aware of future requests, it could fetch and prepare > the asset for transfer prior to the actual request being received, > thereby reducing or eliminating the time delays inherent in the > request-response paradigm. This *may* be as simple as adding > additional optional UUIDs and parameters to the asset request for > assets that the viewer would likely be requesting next. If this were > the case, a single connection could have a higher effective > throughput by ensuring minimal delays between request and response, > and reduce the need for more simultaneous connections. > > Such a solution may or may not be practical or easily implemented in > existing infrastructure, or may not be as efficient as other designs. > My point is more or less meant to bring more perspectives into the > discussion by considering other bottlenecks that may exist, which if > mitigated, could reduce the need for excessive connections. > > Thoughts? > -dahlia Dahlia, an overwhelming amount of past experience has taught us that Linden Lab is not interested if you "think along" with them about the server, or the viewer-server protocol,either with suggestions, designs or anything. This list is set up to get feedback about viewer bugs, and to announce things they came up with (in most cases someone else came up with than the ones that we're allowed to talk with). So, it's a complete waste of your time to do anything else than to just sit back and read what Linden Lab is going to push through (no matter what arguments you come with, or what flaws you point out). [ That being said, they came up with "pipelining" as the solution for the problem you mention. That allows a viewer to send new requests over the same connection, without having to wait for a reply for former requests. This isn't the most efficient solution, but a lot better (still depending on the closed source server implementation though) than how it works so far. ] -- Carlo Wood ___ 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] New HTTP Library & Project Viewer
On Thu, 02 Aug 2012 12:21:20 -0700 Kadah wrote: I stand corrected :/. And I'm disappointed in the mail viewer that I use (Claws Mail). I see nothing, and it treats your message as an attachment. When I click on that it allows me to "Open" it with abiword -- which I normally only need to open .doc documents -- hence my accusation... Before this mail program I used mutt, and that had no problem showing signed mails directly :\ -- Carlo Wood ___ 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] New HTTP Library & Project Viewer
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Using debian, I installed claws-mail-pgpinline plugin, and can now see your mails as I should :). Thanks for your kind patience! - -- Carlo Wood -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUBUBxY4m/Sxh1iSsrVAQI+lQP/XSbTU8Jwewvr6vyYo5NW/XqwwZ/S24ZG EtaRpx6jf/Iv6Yq61nNH+iYhEockE3guiVA1+L8SG1jDeqjHTZLBdzMIvXZVRnVr ETs6FowTia4kHfMACC/CDdcuZwG0VKKVDNRq1+SOmAPdaLj3gbvqeIle1/2eYBke lKbivKq+NXM= =8f6F -END PGP SIGNATURE- ___ 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] Review Request: patch potential memory leak in llgl.h
On Thu, 20 Sep 2012 07:08:11 - "Gistya Eusebio" wrote: > > > > On Sept. 19, 2012, 2:12 p.m., Aleric Inglewood wrote: > > > There is semi-colon where it doesn't belong. Otherwise ok > > > (Singularity has this patch since a long time). > > Oh really, where? It compiled and ran fine on my machine. Perhaps it's the ONLY semi-colon you added? Semi-colons have the tendency to compile if you add one at random; still doesn't belong there though. With regard to white-space, you also should start the line with a TAB instead of spaces to match the already existing lines, and the added comment is something that should be in the commit message, not in the code. > > > - Gistya > > > --- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/603/#review1265 > --- > > > On Sept. 19, 2012, 8:26 a.m., Gistya Eusebio wrote: > > > > --- > > This is an automatically generated e-mail. To reply, visit: > > http://codereview.secondlife.com/r/603/ > > --- > > > > (Updated Sept. 19, 2012, 8:26 a.m.) > > > > > > Review request for Viewer. > > > > > > Description > > --- > > > > In llvertexbuffer.cpp we call: delete mFence; > > > > mFence is an instance of class LLGLSyncFence which is a sub-class > > of LLGLFence, which is defined in llgl.h. > > > > However, class LLGLFence should have a virtual destructor because > > it's the base class. This patch fixes that potential memory leak, > > adding a virtual destructor to class LLGLFence. The virtual > > destructor ensures that the destructor for the derived class also > > gets called when we call "delete mfence;". > > > > To quote Björn Pollex, "If you have a class that is supposed to be > > usable polymorphically, it should also be deletable > > polymorphically." > > > > (Unless I'm missing something...!) > > > > NOTE: I notice that related code is commented in methods "void > > LLVertexBuffer::placeFence() const" and "void > > LLVertexBuffer::waitFence() const" -- maybe we commented it out > > because this memory leak was unresolved? Perhaps it can be > > uncommented now? I haven't tried yet. There was no note as to why > > the code is commented out. > > > > > > Diffs > > - > > > > indra/llrender/llgl.h UNKNOWN > > > > Diff: http://codereview.secondlife.com/r/603/diff/ > > > > > > Testing > > --- > > > > I did compile this with OS X 10.8 as a build target successfully. I > > made other changes too, so while my FPS seems improved, it could be > > from any number of issues. I did notice that any llCharacters that > > are moving around don't get rendered properly by my build, but I > > don't know if it's because of this code revision or something else. > > I need to do further testing on that. > > > > > > Thanks, > > > > Gistya Eusebio > > > > > -- Carlo Wood ___ 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] Fwd: I'm back baby!
On Sat, 27 Oct 2012 18:11:45 +0100 Gareth Nelson wrote: > Been away from SL for quite a long time, is there a 64-bit binary > build for linux lieing around somewhere? https://github.com/downloads/singularity-viewer/SingularityViewer/Singularity-x86_64-1.7.2.2956.tar.bz2 is linux 64bit. -- Carlo Wood ___ 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] Formal Animation Set Replacer
On Sat, 3 Nov 2012 11:49:36 -0500 Argent Stonecutter wrote: > I think the requirement for this is somewhat overstated, and I hope > that LL does not include any such function in the viewer. A well > written LSL based AO has very little overhead, because it can get by > with fairly slow timers by using control inputs to detect state > changes. Even the somewhat convoluted Franimation Overrider is low > overhead, and I suspect the overhead of running it is not much > different from the network overhead of a client-based AO. > ___ 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 LSL AO's have always failed majorly. I'd welcome any official server-level support for replacing the standard stand/walk/run/sit/turn animations, so they work like the non-AO ones (not that is flawless... happens too often you "walk" while playing the 'stand' animation :/) -- Carlo Wood ___ 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] gcc 4.7.1: lotsa warnings about boost
On Sun, 06 Jan 2013 11:56:31 +0100
Lance Corrimal wrote:
> Hi,
>
>
> Whenever I'm building the current development source on openSUSE 12.2
> (read: with gcc 4.7.1) I get lots of warnings about boost-related
> things. Some of them I've been able to correct myself, others I'm
> stumped... the causes seem to be in 3p-boost itself, and i'd rather
> build with exactly the same libs as the lab...
>
> here's one of many examples:
>
> http://paste.opensuse.org/77018665 (it's way too long and unreadable
> for email)
>
> any ideas / tips / hints for me? google results seem to suggest
> something or the other about namespaces...
This is just one of the many many examples showing that a lot of the
Linden code was written by people who probably learned C++ in a 2 week
course before starting to hack the viewer code.
The solution is rather simple, really. Now I haven't looked at v-d in a
while, but last time I compiled it I compiled it with gcc 4.7.2 and
boost 1.49 and that gave me the same error as I see at the top of your
paste (only looked at the first error by the way), which can be
resolved by simply removing the nonsensical 'namespace boost'.
Everywhere where you see
namespace boost {
// something with *intrusive*
}
remove the 'namespace boost {' and '}'.
--
Carlo Wood
___
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] Review Request: BUG-840: Viewer 3.4.2 (Beta) breaks almost every sliding door script in SL
Not only sliding doors, my normal door stopped working too more than half the time; and a LOT of others scripted objects... Even watching it doesn't always help. On Sat, 16 Feb 2013 18:53:02 - "MartinRJ Fayray" wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/616/ > --- > > (Updated Feb. 16, 2013, 10:53 a.m.) > > > Review request for Viewer. > > > Description > --- > > Fixes missing childprim- position/rotation-updates when the avatar > was 20+m away and didn't have the object in view when it was changed. > > > Repository: https://bitbucket.org/MartinRJ/bug-840 > > > This addresses bug BUG-840. > https://jira.secondlife.com/browse/BUG-840 > > > Diffs > - > > indra/newview/lldrawable.cpp fbbee98b7512 > > Diff: http://codereview.secondlife.com/r/616/diff/ > > > Testing (updated) > --- > > Create an object with two prims, add a script with a listener on > PUBLIC_CHANNEL and make it change the relative position of the child > prim in the listen-event. > > Move the avatar 20+ m away from the test object, and look in the > opposite direction, so that the object is not in view. > > Shout something in public chat so that the child prim changes its > relative position. > > Turn around so that the test object is in view again. > > Expected result: the prims visibly changed. > > Without this fix, the child prim would not update its position (or > rotation). > > This fix has to be tested against the following related bugs: > BUG-840 [positionbug], BUG-840: Viewer 3.4.2 (Beta) breaks almost > every sliding door script in SL MAINT-2275 [vehiclebug], Child prims > are "left behind" by animated, moving physical objects MAINT-1742 > [selection], Child object does not update position while selected. > MAINT-2247 [selection] Child object does not update rotation while > selected. > > > Thanks, > > MartinRJ Fayray > -- Carlo Wood ___ 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] Serious regression in SSB-enabled regions
On Sun, 24 Feb 2013 10:36:12 -0800 Darien Caldwell wrote: > Yes, this was brought up to Nyx and Oz at Oz's last User Group > meeting, by inusaito.kanya They were supposed to file a bug under > Sunshine, but probably good to have someone else do it as well, in > case they didn't. I'm unable to comment on SUN issues (or even make > them) but I gave it my vote regardless. I'm unable to add a comment either to this issue. What utter crap is this??? ___ 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] Serious regression in SSB-enabled regions
On Sun, 24 Feb 2013 20:09:19 +0100 Henri Beauchamp wrote: > > I'm unable to comment on SUN issues (or even make them) > > Gotta love the new closed JIRA !... Way to go, LL... I was about to type "fuck you Linden Lab" in my previous post, but assumed they might be assholes enough to then kick me of this list... The phrase "way to go" is inventive. It would never have occurred to me to use that in this context. This whole "open source" HAHAHA project is a pathetic, lame, grrr - I want to SPIT on it. LL should be sued for fucking CALLING this "open" in ANY way. I hate you. A REAL Open Source coder, Carlo Wood PS I'd add a comment HERE regarding SUN-38, but I learned years ago already that LL doesn't listen to anyone. They are just going to give you the finger Henri (and everyone else in SL) but not going to fix this. I'm not even going to TRY add a (technical) comment. Seriously, why is ANYONE still HELPING them? Why doesn't everyone just leave this list, stop going to their meetings, and stop giving them patches? Are you all stupid or what? ___ 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] Reminder: Collaboration in 3D virtual environments- take the survey and earn 100L$ I need you assistance please
On Wed, 24 Jul 2013 14:32:57 +0200 Ambrosia wrote: > Would you please top spamming this mailing list over and over? > > Thank you. I just added a special spam filter rule to my spamassassin a while back. -- Carlo Wood ___ 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] ThrottleBandwidthKBPS - kilobit per second or kiloBYTE per second?
On Fri, 26 Jul 2013 13:58:47 +0200 Henri Beauchamp wrote: > This setting is indeed only relevant to UDP traffic, or at least in > LL's and most TPV viewers. IIRC, I saw attempts to account for this > limit with HTTP texture fetching traffic in Singularity, but that > would need to be checked for certainty. Singularity has a separate debug setting for HTTP bandwidth usage (HTTPThrottleBandwidth). -- Carlo Wood ___ 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] ThrottleBandwidthKBPS - kilobit per second or kiloBYTE per second?
Well, since everyone has to download the same amount of data in the end, its rather hard to use a "disproportional" amount of resources, unless a viewer just downloads the SAME thing over and over again, which would be severe bug. The only other thing that might be called using too much resources is when the sim is failing to deliver data, and connections that are made just time out. In that case it will be the viewers that have the most aggressive re-try policy that are using the most resources. For clear reason, in those situations it will be the viewers that retry most aggressively that will succeed faster than others to retrieve the data. In my experience, this is V3. Even on servers where most TPV's fail completely to get any data because of huge number of disconnects and timeout - V3 *still* manages to get all data in around 2 minutes time! I'm able to run a V3 viewer myself but independent sources told me that they saw V3 make up to 40+ connections at a time to the texture/mesh service. On Tue, 30 Jul 2013 15:08:28 +0200 Niran wrote: > Names or it didn't happen. > > > 2013/7/30 Kadah > > > > > > > On 7/26/2013 10:47 AM, Argent wrote: > > > > > > On Jul 26, 2013 12:32 PM, "Darien Caldwell" > > > mailto:darien.caldw...@gmail.com>> > > > wrote: > > >> So basically while this system is probably beneficial to those > > >> with > > > bad internet connections, it's rather punitive to those who have > > > excellent, wide pipe connections. The only way to increase the > > > bandwidth max is to recompile the viewer. > > > > > > One should also consider how much of Linden Labs bandwidth one is > > > entitled to before dismissing it as 'punitive'. :) > > > > Indeed. There's been a number of incidents where few users in a > > region on [VIEWER NAME REDACTED] can use a high disproportional > > amount of sim resources and and cause rather sever problems for > > others. Just last week I got trapped in a region due to this. That > > was fun. ___ > > 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 > > -- Carlo Wood ___ 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] grid code exploited
On Tue, 1 Oct 2013 02:09:58 -0500 Flats Fixed wrote: > seems your staff OZ has exploited your closed grid code and has > rendered a whole sim on Mainland _ Bailywick Useless. And Staff is > unable to fix it. this is a serious issue OZ fix it. Only people that > have this knowledge of the Closed grid is Staff. > You really should take the meds that your psychiatrist prescribes, otherwise they don't have any effect :/ -- Carlo Wood ___ 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] Avatar Hover Height feature
On Mon, 2 Feb 2015 20:49:49 +0100
Henri Beauchamp wrote:
> Are you ***kidding*** me
etc...
LOL - Henri, I respect you a LOT, for technical reasons.
I even once told Oz that if you said something he better
listen because it would be worthwhile.
However,
sometimes I wonder why you aren't being smarter than this :p
At the time I was enthusiastic about working on an opensource
viewer (even though that meant given my private info, which I
agree is rather silly and annoying; and I understand why you
refuse that)... That was before Oz - we worked on the viewer
for a YEAR before finally being confronted with the fact that
Linden Lab ('s internal coders) hadn't even LOOKED at our
contributions and EVERYTHING we did had been /dev/null-ed and
not used in their next release. I didn't reconfirmation: I left.
Then Oz came and promised change: everyone would work on the
same repository and be treated the same (Lindens and open source
programmers a-like). I never believed that, but I gave him a chance:
because of his promises I ported ALL of (one year) of work
to the new code base. Then I gave them TWO MONTHS to merge my
work - which failed; and I left again and never returned.
By now (years and years later) it's a blatant fact that the
above was a lie: Lindens and open source coders are still *not*
being treated the same.
Bottom line is. Linden Lab only uses and likes "invented here".
The don't listen to others, nor are they interested in what
others have to say. Things are STILL being developed behind
closed doors mostly (and have been since the very beginning),
that will never change. If you come with a good idea, it will
be shrugged of. Trying to communicate with Linden Lab is a waste
of your time.
When the viewer developers figured this out and therefore
concentrated on COOL INNOVATIVE stuff that they didn't NEED
Linden Lab for; Linden Lab got very very frustrated, until they
finally came with the Third Party Viewer ToS that literally
forbids TPV devs to come with cool innovate stuff; so now
it's again and 100% closed-door-"invented here"-Linden-Only
stuff pushed out to some repository after which it is Oz's task
to make sure all the TPV's copy and support the new functionality
in the name of 'shared experience' etc. At no point in this
development cycle they are going to listen to you, let alone
do something (different) because of a bright insight that you
have.
Stop Wasting Your Time.
Just let them kill SL in peace.
Regards,
Carlo Wood
PS Needless to say that I completely agree with the technical point you
have been making. But it's not just the hover height that is
problematic lol. The whole animation (format) is useless. That format
was never intended to be used by many different shapes (but only by a
single shape, one that the animation is specifically intended for).
However, if you accept that design error then what is really needed
is neither a Z-offset nor a fake bounding box. What a viewer (script)
would need control over are two reals: an offset and a (vertical)
scaling factor.
The problem is this:
If an avatar of 2 meter is standing straight up, then -say- by default
their feet are on the floor (tuned to be on server side).
If the same avatar bends its knees so that the feet--pelvis distance
decreases from 1 meter (say) to 0.4 meter (say), then its feet would
be 0.6 meter above the ground because the pelvis height is fixed (well,
the avatar center is, but that has the same height basically).
Therefore, in order to get the feet on the ground again the used
animation format includes an offset of -0.6m: moving the whole avatar
down 0.6 meter. This is why this format is only usable for a single
shape: that 0.6 meter is only fixed for a given shape.
A smaller avatar, lets say one of 1.5 m (with otherwise the same shape)
has thus a feet--pelvis distance of 1.5/2 = 0.75m. This is "known" by
the server and corrected for: the pelvis is moved down 0.25m so that
the feet touch the floor when standing up.
Then, when that smaller avatar plays the same animation (made for the
2m tall one), it pulls up its feet 0.6/2*1.5 = 0.45 meter and the
animation moves the whole avatar down 0.6 meter... resulting in the
feet being buried 0.15m into the ground.
The old way to "fix" this is by telling the server: Hey, I'm REALLY
1.8 meter tall (instead of 1.5m), causing the server to not move you
down 0.25m but only 0.1m - causing the feet to precisely touch the
ground again. I don't consider that a good solution :p.
The new Hover solution is actually better - except that it was
baked into the shape itself and isn't the correct way to fix this
either - and therefore (like the first case) needs fast and dynamic
changes (ie, every time you change animation) which is no longer
possible - making it MUCH worse than what we used to have.
Still, the Hover is just an offset and therefore not what
Re: [opensource-dev] Client-side prediction
On Sat, Feb 06, 2010 at 03:09:50PM +, Nexii Malthus wrote: > Hm, I'm probably terrible with explaining it in words. > > I think a step-by-step picture can help show what I did. > > http://i45.tinypic.com/2zgx4kg.png I don't think that predicting a rotation will be very practical. In most cases people walk straight and make sharp corners; so if you detect that an angle, I'd assume that changed direction, NOT assume that they are walking in a circle. If you want to include prediction of curved paths then I think you should add another sample (three points) and choose "circle" if the path matches the path that one would follow if one holds down the left or right arrow key while walking... but then again, not that useful. If people are walking around in mouse look, you just can't predict anything -- unless the lag is so small that rotation prediction is hardly necessary to begin with :/ -- Carlo Wood ___ 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] retrieving scripts attached to an object
Could it be that you don't select the prim?
If it isn't selected, the contents aren't synced.
On Mon, Feb 15, 2010 at 04:47:14PM +0200, Mahmoud Ismail wrote:
>
>
>
> Hi all,
>
> as a proof of concept i was creating a floater which instantiated by a button
> on the Pie Menu
> in that floater i've created a Button in which i was try to get all inventory
> items attached to the selected object
>
> but, i found that it gives no script items although there're two script files
> "Note: i didn't open these files just press on New Script"
> now, sometimes when i opened these files first then press my button it gives
> results
>
> here's my button code:
>
>InventoryObjectList inventory_list;
> object->getInventoryContents(inventory_list);
> llinfos<<"Loop on inv_objects "< for(InventoryObjectList::iterator inv_obj=inventory_list.begin() ;inv_obj!=
> inventory_list.end();++inv_obj)
> {
> LLPointer obj=*inv_obj;
> llinfos<<"Type : "<getType() << " Name : "<
> getName()< }
>
> anyone could tell me why i've to open the script file in order to be known as
> an inventory item for that object
>
> another request, if anyone have any material could help me in understanding of
> the workflow of the scripting module (from creating scripts till saving)
> please
> pass it.
>
> thanks in advance,
>
> Best Regards,
> Mahmoud Ismal
>
> ___
> 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
--
Carlo Wood
___
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] step by step guide to compiling snowglobe
On Wed, Feb 17, 2010 at 02:30:07PM -0500, kow wrote: > Snowglobe should work out of the box with VS2005. Emerald and Imprudence are > easier options if you're using VS2008. I believe the only issue with VS2008 + > snowglobe is boost, and the libs from Emerald or Imprudence can be dropped in > to fix that. One would wonder why Emerald can fix this, and LL can't. -- Carlo Wood ___ 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 scripting in Snowglobe
On Thu, Feb 18, 2010 at 10:57:52AM -0500, Kent Quirk (Q Linden) wrote: > This makes me sad. > > I've been trying to have an open discussion about some of the design issues in > my office hours, specifically to understand the constraints and requirements > of > the community. But every office hour seems to be followed up by flames on this > list and in other forums interpreting what was said in the worst possible way. I don't have time to attend office hours at those exact moments. Not everyone lives in the States. > I'm afraid the tone and direction of this discussion are making it impossible > for us to talk about this project productively. Yeah right. I read the posts too, and they seem to be all true. This remark sounds like a poor excuse to explain why there is no open development of client-side scripting ON THIS LIST, where it belongs. I'm sorry, but I agree with the statement of Maggie that the only sane conclusion is that, as always seems to be the case, "it is being done in secret with the intention of maximizing spin control of reactions of the user community until such initiatives are fait accompli" LL is simply not willing nor interested to listen to the (open source) community; they want no discussion and want to push what they think is best. > Q -- Carlo Wood ___ 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] step by step guide to compiling snowglobe
On Thu, Feb 18, 2010 at 01:06:54PM -0600, Jonathan Irvin wrote: > As far as SnowGlobe goes, I wish it was more modular like linux goes. To > where > we can add packages or remove them from the base install to grant us this or > that. When one module gets updated we can just download it as needed. I would like that too, but... as long as "we" want to stay in sync with the "official" viewer of Linden Lab (or they with us), we cannot make any large changes. I consider this a very bad thing personally, so I'm not in favour of staying in sync. I think Snowglobe would benefit to let go of trying to be merge-able with the "official viewer" and start to really allow BIG changes. > AlsoHey Linden Labs, when are we going to put Second Life in linux package > format so we can just link to your repo and have us be able to install and > upgrade from our respective package managers, i.e Yum & Apt-Get? Actually, that is the task of linux distributors. For example, in the case of debian, of volunteers that become "package manager" for a specific packet. In our case, that would be Robin Cornelius. It's not fair to look at Linden Lab for making linux packages for every distribution out there. However, they *should* listen to package managers with some kind of priority. If those request a bug fix that only LL can fix, then that is backed up by a very large number of users and should get high priority. -- Carlo Wood ___ 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 scripting in Snowglobe
On Thu, Feb 18, 2010 at 01:31:43PM -0500, kow wrote: > I for one agree with Q. You're not really stating what you agree with here... but lets assume you mean that: - It's ok that nothing was communicated on this list about anything prior to some decisions made by LL about client-side scripting. - People shouldn't whine or flame about not being taken seriously when we tell them what has been decided behind closed doors. > The biggest complaints come from the most insignificant people. That is a flame, and pretty personal one too. But I'll try to read between the lines and make something of it; you probably mean that you didn't see any comments yet from the most active opensource coders of snowglobe yet. Those people are intelligent, of course, and have had close(r) communication with a handful of Lindens than the others, getting to know them a lot better than the average office hour visitor. Those people understand that the decisions being communicated by THOSE Lindens are not the decision of those Lindens personally (at least, I hope not, or they DO deserve the flames). Most snowglobe assigned Lindens have very little influence in the whole. They are just coders with a big boss that demands apparently pretty stricty that they cannot talk about things. I'm sure that most Lindens that we have contact with are just like you and me, they just got hired by LL and are now being frustrated by the tension that LL policy as a whole is creating between the entity Linden Lab and the "open source community" that they attracted to work on snowglobe. I think that most of the really active coders think that their personal relationship with their fellow hackers inside Linden Lab is more important than venting their frustration on a public mailinglist KNOWING that it is going to be useless, since that decision has indeed already been made (they ARE going to use mono) and even the Lindens that we CAN communicate with can't do anything about it. If anything, I admite Q for not falling back to "Sorry, but it's not my decision to make", but despite the pressure from the opensource community keeps acting as-if Linden Lab has one single mind and direction (which no doubt is the policy of LL management). > If LL prioritized development based on the > complaints in this mailing list, they would be rewriting SL for Linux > using GTK and maintaining a dozen branches for ever popular flavour of > unix. But then we'd just be playing a thinly veiled OpenCroquet. When I read such proposals I didn't take them seriously either. And perhaps it IS necessary to play parent and take the decision yourself in order to protect your kid; but it can be done better by at least first have an open discussion (on this mailinglist) about the pros and cons of whatever BIG decision (like using mono). And then I mean ***NOT*** to ask for "feedback" and then sit back and read everything and then make your decision, Babbage. I mean, to actively participate in the discussion and try to convince people with logical arguments and having an open mind for ideas that are not your own. Then, in the end, I guess someone "authoritive" has to make the final decision (because in most cases not everyone will agree with the same), which could be done in a form like: - We had a meeting today with u, v, w, x, y, z and q Linden, and after careful consideration we decided to go for mono for the following reasons: * point 1 * point 2 * it's the only thing we really have the expertise for in-house * Foobar had the argument this and that, but blah blah. * Carlo was right, but we felt that over all the advantages of mono weight more heavily than his proposal, as we already discussed on the list * and so on. > Instead of making accusations and generating pages upon pages of > arguments based on hearsay, why not ask a well thought out question that > a developer can answer with a simple yes or no? I'd much rather Q and > his coworkers spent time developing cool things than entertaining your > pointless nerd rage about Mono. I applaud your speech, and again, I agree that not any of these Lindens is personally responsible, so they don't deserve any flames. However, on this route that LL as a whole is taking now, the only logical result would be that Snowglobe splits off and becomes a TRUE opensource community driven project. And that would mean, at least in the eyes of Linden Lab, that the whole opensource project has failed. -- Carlo Wood ___ 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 scripting in Snowglobe
On Fri, Feb 19, 2010 at 02:17:17PM +0100, Carlo Wood wrote: > If anything, I admite Q for not falling back to "Sorry, but admire* ___ 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 scripting in Snowglobe
On Fri, Feb 19, 2010 at 01:30:28PM +, Morgaine wrote: > I would avoid your terminology though, because both kinds of script > application > employ "client-side scripting", both types create dynamic "extensions", and > both types can be implemented as "plugins" --- your terms directly describe > the > technologies that can be used in both types of application and don't > distinguish between the two differing requirements. It would just add to the > confusion. Plugins are inheritly unsafe and will have access to anything a normal process has. If client-side scripting is going to be provided on a plugin with the same access to the system, then it's still a plugin. Hence, I see no problem talking about "plugins" for "trusted" applications and not even mention scripting in that case (for now). Then we can reserve the word client-side-scripting for third party / downloaded scripts. -- Carlo Wood ___ 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] Consensus? was: Client-side scripting in Snowglobe
It seems to me that most people still talk about untrusted, portable, and grid-wide supported downloadable scripts when talking about Client-side scripting (sorry Morgaine). So, I propose to go with that, and call anything else "Client-extensions". --- The remainder of this post is about Client-extensions. I sense consensus on the following layered design: [current code base] + lots of hooks to be written | | V C++ API [1] | | V IPC API [2] | | V Plugin(s) One or more plugins then could provide a client-side scripting engine; either for trusted for any language, or a secure API for an engine running the mono bytecode that LL is working on (or whatever). - A scripting engine for language XYZ. [1] Ie, based on the yet to be written LLStateMachine class. [2] Ie, a socket. What is more important is the protocol that is being used here. I can imagine that this will be LLSD, or something simular. -- Carlo Wood PS Note that personally I'm against using mono for clientside scripting... ___ 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] Consensus? was: Client-side scripting in Snowglobe
On Sun, Feb 21, 2010 at 04:57:18PM -0800, Dzonatas Sol wrote: > When LL said "here is a sphere the size of a quarter in diameter... > 1 2 3 4 5 6" as one points top, bottom, left, right, back, front. > And says "Stupid" with a superiority look. > > Obviously the person that was challenged, the one to be hired, said "Odd." > > If you know if it is "even" or "odd" then you know who gets the last > move, and wins. This is clearly a way to measure someones spatial insight. Now note that if it's a game, and coins are not allowed to be moved around once they are placed, then it's very unlikely that you will be able to place 6 coins on the surface of that sphere (with diameter equal to the coin), because the one who'd put down the fifth coin would not put it such that you can put down the sixth coin, but somewhere in the middle of the left-over surface, leaving no spot for the sixth coin. Calling people stupid over this game surprises me however (because I happen to have a extremely large spatial insight, officially measured mind you (although, they couldn't actually graph it in their graph because I scored not just out of the graph but even off the paper that the graph outline was printed on)), because I'm having a hardtime to quickly guess if you CAN put five coins on the sphere... It seems not unlikely that only four coins will make it... which would mean that the one that begins will try to leave open as much space as possible when putting down the third coin. The person to move second would try to use as much space as possible. So, first goes on top say, second on grounds of symmetry probably on the bottom, then again forced to play without any strategy, the third coin just goes on the side, and the fourth coin, wanting to be last, takes the exact opposite of that, leaving two places free: Oh hell... that way you STILL end up with six coins being placed, even though both tried to screw the other with strategy. The only freedom that still exists would be the one placing the second coin: by not placing it exactly on the opposite side, you'll likely end up with only five coins. However, since putting it on the exact opposite side caused this player to win, he has little reason to play it elsewhere. Hence, due to perfect symmetry, the first player has no real choice, ever. And the second one, who wins, can control the game completely; hence 6 coins. Not THAT simple however. -- Carlo Wood ___ 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] Consensus? was: Client-side scripting in Snowglobe
There is no need for A != B. Why not define the words A and B such that A includes B? B \in A Then you can still talk about the subject, since there is still a C = A \not B, such that the intersection of B and C is empty. In other words, yes Client-Extensions include plugins that implement Client-side scripting, but it won't give confusion because if someone means that, they will say "Client-side scripting", so if they DON'T say that, they probably mean something else, either something broader (including client-side script plugins) or something entirely different even. On Mon, Feb 22, 2010 at 04:51:20AM +, Morgaine wrote: > The moral of the story as it pertains to our topic is that when the superset > is > ambiguous as in our case (all scripts running client-side are naturally > "client-side scripts"), then the ambiguity won't stop until you subset the > space into disjoint subsets so that you can discuss each subset separately > without confusion. > > That's what I've been trying to do, because "client-side script" is a > universal > term that naturally denotes all scripts running in the client by simple plain > English, so you can't call just one subset of the scripts by that name without > creating ambiguity. -- Carlo Wood ___ 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] Consensus? was: Client-side scripting in Snowglobe
On Tue, Feb 23, 2010 at 03:10:55PM +, Morgaine wrote: > For the simple reason that in our case there is no C = A \not B, because A is > the set of all scripts that execute client-side, and that includes all the > possible types of scripting/programming that we are discussing here: they are > all subsets of A. No, A (client-extension) is all plugins, and B (client-side scripting) is all untrusted client-side scripting. -- Carlo Wood ___ 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] Third party viewer policy
On Tue, Feb 23, 2010 at 12:45:01PM -0800, Brent Tubbs wrote: > For a while I've been batting around the idea of creating an SVN-bot to enable > much-improved version control for inworld scripts; a must-have when you're > developing as part of a team. The same-creator policy on content export would > seem to prohibit that though. > > I realize that you probably don't want to have different rules for each > different content type, but the one-size-fits-all rule in the current policy > doesn't fit scripts well at all. I didn't even READ the TVP all that well, I'm just going to stubbornly use my own common sense. If anything that is not common sense is going to be enforced then by all means I don't want to be part of SL anymore. In this case the common sense says: If something is full perm, you may export it. Second Inventory does this, and I doubt that is suddenly made illegal. Scripts that a team work on are definitely full-perm (from the point of view of SL permissions), so you can export it all you like. -- Carlo Wood ___ 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] Third party viewer policy
On Tue, Feb 23, 2010 at 01:16:18PM -0800, Ambroff Linden wrote: > You can certainly do this using debconf, see the source for the sun-java6-bin > [1] package in 9.10 for an example. That package uses debconf to present > localized and frontend agnostic dialogs to prompt the user to accept a special > license. He said "main". A construct like that would demand the package to be in non-free, which is highly highly to be discouraged, to the point that I'd understand it if Robin would stop caring anymore. It is also completely unnecessary. -- Carlo Wood ___ 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] Third party viewer policy
On Tue, Feb 23, 2010 at 04:05:57PM -0700, Lawson English wrote: > MY concern is about prototyping viewers. I can certainly add a thing to > timestamp a version string during login, but with smalltalk, I'm > constantly tweaking the code *while* I'm connected to SL. Does this mean > I have to log out every time I modify something in my squeak client just > so I can change the version string? Common sense again (see previous post, not claiming you're not using common sense ;): The whole version string is only needed in order to detect viewers that are KNOWN bad. That is, LL is not going to make a list of viewers that may connect, and everyone else is going to be barred; they will contact devlopers of third party viewers with lots of users and request changes, and when those changes are not made, then they will bar the access of that viewer to the grid. Thus, any viewer that doesn't have a large user base, like the personal play toy of some developer, does not have to meet this requirement: whatever it is, it is unknown to Linden Lab and THUS they cannot have a reason to want to bar access of it. If your viewer is very different from whatever you based it on then you can just pick some unique, but constant, version string, and that's it. -- Carlo Wood ___ 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] Third party viewer policy
On Thu, Feb 25, 2010 at 12:34:17AM +0100, Henri Beauchamp wrote: > As far as I am concerned I will not provide such info to Linden Lab as > I consider it a breach of my privacy (call me paranoid if you want). Same here. As some people know, I have a large background with IRC. Admins and IRC operators that used their Real Life name (mostly through email), have been known to be called at home on their private phone with death threats to their kids. If LL demands the RL info of developers to be published, then please make an example by starting with listing all the Real Life names and addresses of the Linden employees. -- Carlo Wood ___ 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] Third party viewer policy
On Wed, Feb 24, 2010 at 11:48:38PM -0700, Lawson English wrote: > Actually that is NOT common sense. When the author of some > intellectual bit of property agrees to distribution, its generally > for existing channels of distribution only. The SL TOS only applies > to intellectual property distributed by Linden Lab in the manner > that the content creator agreed to. Someone ELSE coming along and > saying "oh, full perms means I own the IP rights to this and can > take it anywhere I please and do anything I want in any way I want > without consideration for the original creator" goes against even > the CC license, and the LL full perms isn't the CC license or any > kind of abbreviation of it. So ok, the entry in the TPV Policy has to be changed then. Note that is also makes the 'Save to RAW terrain file' illegal in most cases (it's almost never the owner of the sim that created the terrain all by himself alone). Are we going to remove this function from the viewer? -- Carlo Wood ___ 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] Third party viewer policy
On Thu, Feb 25, 2010 at 11:33:58AM +0100, Marine Kelley wrote: > This is a non-issue anyway, most people will not agree to expose their > RL identity on LL's website just to list a piece of work of theirs, > unless said piece of work is required to be listed in order to be > accepted on their grid. And I have not read anything anywhere that was > even remotely implying such a thing. If this was required, expect most > viewers to be stopped dead in their tracks. Very true. This list is going to stay empty, nobody is going to add their real name, and if it was required in order to get a viewer to connect at all they will just stop developing it; or spoof the indentification of the viewer. It's too ridiculous for words. And what exactly is the use of all this, except to make the life of honest users harder? Rogue viewers/developers will just spoof the indentification anyway; they are not interested in being listed or following the TPV policy. Seems to me that Linden Lab is planning for a follow up with more enforcement, as soon as most popular viewers are actually on that list for a while. I therefore think it's better for all of us if that list stays entirely empty :/ [to clarify: that is better for progress and development than when in the end you need some digital signature binary-only plugin in order to connect]. -- Carlo Wood ___ 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] Third party viewer policy
On Thu, Feb 25, 2010 at 03:35:06PM +0100, Henri Beauchamp wrote: > "Hello Henri, > > Thank you for contacting us regarding your issue. > > I am sorry but we can only offer support on issues with the official > SL viewer. > > We do not support any third party viewer as we are not responsible > for their software. > > If you experience the issue with the official viewer then we will > assist to the best of our ability. The only reasonable response to THIS, is faking a random MAC address in order to connect (if that is really the problem here). If they don't want to help, then you gotta help yourself. Seriously though, ... I imagine a not-so-smart person reading your technical support request and having no idea what you talk about. "MAC address? What is that? libomv light? Uh uh". Fortunately the phrase "text-only viewer" got through and brought a smile back on her face: pull-down menu, default response *click*. NEXT! "Oh, I'm so good at my work; dealing with like 5 requests per minute!". -- Carlo Wood ___ 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] Third party viewer policy
On Thu, Feb 25, 2010 at 05:31:20PM -0600, Soft Linden wrote: > There have been no bans related to the TPV policy release. > > I know there's been some work on migrating some servers to a data > center with better connectivity to the other sims, etc. There was also > a login problem lasting a couple minutes yesterday around 19:30 > Pacific. I wouldn't be surprised if it was related to one of these. Instead of a "Sorry, we don't help you", support would better answer with "Sorry, we have not disabled null-MAC's yet, so it probably was a temporary problem, or should be. Can you still login with the normal viewer?" -- Carlo Wood ___ 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] Request for help on compiling Snowglobe
Linden Lab neither supports standalone nor 64bit. (Snowglobe is often broken for standalone because it's never tested by LL when they make changes). On top of that, almost non of the opensource developers that volunteer here use windows natively (I don't know of any). I know that Robin did some work on windows, but in a virtual machine I imagine? And he's really a debian guy, swamped with lots of work. I wish I could help, I haven't touched windows in my life :p Hopefully I'm wrong and some windows expert will jump out of nowhere, but otherwise I'm afraid that YOU will have to become our windows standalone-build expert. On Wed, Feb 24, 2010 at 03:21:47PM -0500, malachi wrote: > i have been trying since snowglobe started to compile this thing. and > for some reason i have yet to be successful in doing so. i think > snowglobe hates me. i can compile the standard client source just fine. > but when it comes to snowglobe i always seem to get hundreds of errors. > so im finally done trying to sort it out alone > > anyone here willing to spend a few minutes to help me figure out what is > going wrong with snow that wont allow it to compile? > > > > i have tried this with visual studio 2008, visual c++ 2008 express, > visual studio 2005, visual c++ 2005, i have tried all versions of cmake > and python and have tried while using vista and win7 both 32bit and > 64bit OS. > > so far im down to just Build: 21 succeeded, 50 failed, 30 up-to-date, 2 > skipped. which is way better than it was before lol. > ___ > 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 -- Carlo Wood ___ 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] TPV Policy makes Secondlife *content* incompatible with CC-SA licenses
On Thu, Feb 25, 2010 at 01:05:28AM -0300, Tigro Spottystripes wrote: > if it's just about copying and modification, but not use, then how come > we can't use, say a texture, without explicit permission from the > creator under the risk of being prosecuted for copyright infringement? I'm not using textures, I'm just using UUID's. I'd like to see how law stops me from creating a new asset with the same UUID's as another asset. Long story short: it isn't about civil law. It's about LL letting as know what is their policy, what might cause them to stop viewers from connecting (or users from connecting) to their service. LL is not going to sue anyone for copyright infringment if you export a GPL script or a CSS texture, or when you write a viewer that allows all kinds of nasty things. They can't, since all of that is legal. I'm not a lawyer, but my understanding is that even if someone made some art, a photo of that art and then uploads that texture to SL, then by the act of uploading (due to the TOS) they can't sue LL or anyone else if they download that texture and view it in a viewer. What a "viewer" is is rather vague; but ok, lets say that then someone not only exports this texture but prints in a book and sells that book; then imho only the original copyright holder can sue that person, and still not LL; it's simply non of their business (although they might decide to ban the author of that book, but they can do that anyway, also without reason). -- Carlo Wood ___ 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] FAQ posted for Third Party Viewer Policy
Imho, one major source of confusion is still there. There is a huge difference between Legal Ramifications (ie, being sued and brought before court etc), and just having ones Second Life account banned. The difference between these two is completely lacking in the TPVP as well as in the FAQ. While it is clear that Linden Lab can terminate anyones account (at least, that's what I think-- maybe this TPVP is needed in order to allow that?), before you can *sue* a developer is whole different ball game. It is this major difference that needs to be clarified: * You cannot legally stop anyone from making modifications, and distributing viewer code (based on LL's GPL-ed source tree). * You cannot hold anyone, with the law in hand, responsible for what others do with that source code; EVEN if the source code in question is breaking every TPV rule. The way the TPV Policy is formulated now, it's extremely unclear if Linden Lab intents to (try to) bring developers for court if their distributed viewer does not comply with the demands in the TPV. The FAQ does not clearify this. Actually, I'm not even sure if it is possible to sue users that use a viewer to break a rule of the TPV (mostly 'content theft' I'd imagine, but also griefing), much less a user that uses a viewer that allows users to do so, without that they actually do it. Basically this question needs to be added to the FAQ: * Will Linden Lab ever take legal actions against any of it's users, or even developers of Third-Party viewers, with regard to the rules in the TPV Policy document? The answer should be: No, because breaking any of the rules isn't really illegal in the sense of the Law. The only action LL will take is reserve the right to terminate accounts and withhold people from using the Second Life service anymore. -- Carlo Wood ___ 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] FAQ posted for Third Party Viewer Policy
On Sat, Feb 27, 2010 at 01:10:10PM +, Gareth Nelson wrote: > In general, I have to agree with those who say that this will only > burden legit developers - griefers will just ignore the policy and > spoof the official viewer +1 Especially the clear intend of Linden Lab to make being listed in the Third Party Directory mandatory, but also the fact that once you are listed you are vulnerable to being spoofed by all the REALLY bad guys out there, makes me believe that it is in anyone's interest to not be listed in the TPV directory and cross your fingers that nobody will so that it stays empty. In that case the ball is in LL's garden again with a lot less chance they will start banning your viewer because it's not listed. I don't believe that this whole TPV policy thing is doing ANYTHING except make the lives of honest developers harder. I am sure that everyone on this list that is trying to honestly create a nice viewer and make things Better will agree with me that so far all of this has only brought them frustration and they wished this never happened. At the same time, the Bad Guys will not care at ALL. They were ALREADY doing things that are reason for a ban. Not complying to the TPV policy doesn't increase their risk a bit, and they will just ignore it. After all, the only result of not following TPV policy is a termination of SL accounts. Imho, it is not possible that the existance of this TPV policy suddenly opens up the possibility to bring those Bad developers before court; it's impossible to make them responsible for what users do with their code. I'm not a lawyer, clearly, but something that comes to mind is the fact that copying movies is highly illegal, yet nobody even tried to sue the developers of azureus/vuze. -- Carlo Wood ___ 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] FAQ posted for Third Party Viewer Policy
On Sun, Feb 28, 2010 at 05:30:39PM -0800, Bryon Ruxton wrote: > i.e. You either comply AND feature in the "viewer registry". OR ignore it, as > you said and you’d be in breach of the TOS as such: “5.6 You will indemnify > Linden lab from claims arising from breach of this Agreement by you, from your > use of Second Life, from loss of Content due to your actions, or from alleged > infringement by you”. > > And I don’t think opting out of the "viewer registry" should or ever will be > an > option. And what might your Linden name be? Please, all viewer developers, THINK before you chain yourself to this "list". Adding your viewer will make it so much easier for LL to do what they do best: namely, do what they want despite all complains. DO NOT ADD YOUR VIEWER... at least not until the great majority agrees with the literal wording of the final published TPV policy, and we're far from that. -- Carlo Wood ___ 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] FAQ posted for Third Party Viewer Policy
On Sun, Feb 28, 2010 at 06:08:14PM -0800, Joe Linden wrote: > I'll let the text from the policy speak for itself on this question: "You must > not use or provide any functionality that Linden Lab s viewers do not have for > exporting content from Second Life unless the functionality verifies that the > content to be exported was created by the Second Life user who is using the > Third-Party Viewer." Assuming that "exporting" means "writing to harddisk", it is thus ok to export textures, sounds, animations, ... and everything else in the cache. -- Carlo Wood ___ 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] FAQ posted for Third Party Viewer Policy
On Sun, Feb 28, 2010 at 07:55:57PM -0800, Bryon Ruxton wrote: > Of course, I know that Tigro. But just like any web site can detect a > user-agent and block it, I'd like to be able to detect the viewer agent, > (perhaps via llGetAgentInfo) of the avatar getting on my land anyway. > Such would be useful for various other reasons such a compatibility checks, > analysis of traffic sources, who you visitors are etc... Actually, since you clearly WILL use this info to ban people from your shops,... it's a violation of privacy. Look at that scam object that was released not long ago, being sold for a monthly fee of L$ 700... It adds peoples names to a central database once they are detected (hopefully without any false-positives) to use a known-bad viewer (ie, neillife or cryolife, listed by name in the blog threads). Result: that account is from then on banned in EVERY sim that uses this object. There is so much wrong with that that I won't even begin. Add to that remarks in the said blog like "every possible banned thief is a benefit", and the conclusion is easy: If LL makes the agent ID's public, people will soon ban *ALL* minor TPV's (being all of them, except maybe emerald, because that has already a pretty large userbase) "just in case". The result: Total death to all TPV development; nobody will be able to start with their own new viewer, because nobody will use a viewer that is instantly banned JUST because it's used by a minority and you "never know if won't be stealing my stuff". Hence, privacy. -- Carlo Wood ___ 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] FAQ posted for Third Party Viewer Policy
On Sun, Feb 28, 2010 at 10:15:28PM -0500, Maggie Leber (sl: Maggie Darwin) wrote: > There is already at least one viewer developer who is also selling a > product claiming to identify (by some secret proprietary means) > avatars running "bad" viewers and ban them. Scenario: Newbie visits Second life. Newbie tries out a few viewers to see which he likes best, and settles with Snowglobe. Newbie is banned from all those places that his new friends say have good shops. -- Carlo Wood PS For those who didn't read about this before: that is because once detected, your account name is added to a central database, and it doesn't matter anymore what viewer you are using. ___ 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] FAQ posted for Third Party Viewer Policy
On Mon, Mar 01, 2010 at 02:15:16PM +0100, Marine Kelley wrote: > > > > >If LL makes the agent ID's public, people will soon ban > >*ALL* minor TPV's (being all of them, except maybe emerald, > >because that has already a pretty large userbase) "just in case". > > > Ahem ! Define "minor" TPV please. *and* Restrained Life, of course ;) (sorry, it's just that I never hear about your viewer while in-world, while lots of people talk about using emerald). But that probably has to do more with me than anything else :p Not making a joke about liking to be banned in the first place, Carlo Wood ___ 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] Eclipse Guru's
On Tue, Mar 02, 2010 at 08:09:53PM -0800, Fire wrote: > I am wondering who else on this list uses > eclipse, and am particularly interested in how and if you use this in a team > environment. I've tried eclipse several times over the years, each time I came to the same conclusion: it's written and maintained by java developers, and the support for C++ was extremely hard to find, if at all (that may have improved). The main reason I never started to use it is that it has (or had?) an integrated editor. They wish syntax highlighting (me too), they wish being able to collapse functions (I think) (I don't care, I navigate differently than by scrolling over my code, lol) and so on... resulting in a heavily integrated editor that you can't replace with one of your own. My demand for an IDE is that I can use vim and ctags, and that was not possible when I tried it (or so badly documented that I couldn't find out how). I doubt that my own developing environment is worse than eclipse. I use my shell functions and aliases to speed up things, still working from the commandline but at least as efficient and powerful. Yes, I have to type "vi " a lot, and then double-click and paste and hit return to get to the source file and line where the last compile error is, but that takes me 0.5 seconds and it never bothered me in the least. Overview of classes and inheritance is delivered by doxygen if you need it, syntax highlighting and code navigation is integrated in vim (plus a whole lot more) etc, and top that off, I use good old grep to find anything and everything in a code base no matter how large that is. -- Carlo Wood ___ 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
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
[opensource-dev] Script Memory Management Algorithm
Lets assume that the *average* script uses
8 to 16 kB of real memory. LL's design allocates
64 kB regardless, leading to an overhead of
400 to 800% (meaning they need to buy 5 to
9 times the memory that is theoretically needed).
In that light, I gave it some more thought, and
think something as complex as my rmalloc's algorithm,
with it's 19% overhead, isn't needed (note that
it's both faster than gmalloc as well as three
times more efficient; so complexity is not always
a bad thing ;).
Nevertheless, in this case, since the scripts
use a maximum of 64 kB, you can use the
following design:
Let each allocated block be a power of 2
kilobytes, with a maximum of 64 kB (and a
minimum of 1 KB, or 4 if even the tiniest
script needs that).
It is easy to see that this would lead
to an overhead of 25% on average per
allocated block.
We'd still have to deal with "holes" of a
full 64 kB where blocks became totally
unused, but normally scripts in objects are
started all at once when a sim reboots, and
only seldom stopped. The scripts that will
most likely attribute to random starting
and stopping of scripts will be the scripts
in attachments. A worst case scenario would
be one where there are 50 avies in a sim
(during a meeting), then a new avie enters
with some scripts which need to be allocated
at the top of the heap; then the previous
50 avies leave. That would create a hole
in the heap of the size of all the scripts
of those 50 avies. If script memory would
be relocatable, then this problem doesn't
exist of course. I can't simply estimate
the average overhead caused by this, but
because the algorithm described here is
basically the one used by gmalloc (which
in my test used 62% overhead) I'm pretty
sure that it will be less than -say- 100%
overhead; still 4 to 8 times more efficient
than the current design on the table.
The API for this design would be something
like the following:
namespace script_memory_management {
void* ll_sbrk(ptrdiff_t); // Increment the size of the heap
int ll_brk(void*);// Set the size of the heap explicitely
void* ll_malloc64(void);// Get a new 64 kB block.
void ll_free64(void*); // Free such a block.
void* ll_malloc(size_t s); // Allocate s bytes of memory for a script.
void ll_free(void*); // Free it again.
...
Assuming here that scripts cannot deal with
relocation, otherwise one should also have:
void* ll_realloc(size_t s); // Allocate a different size of memory.
ll_malloc then will round the number of requested bytes up
to the nearest power of 2 (kBs) and retrieve a block from one
of the free lists (maintained for 32, 16, 8, 4, 2 and 1 kB)
(note that if scripts only seldom use 1 or 2 kB it might
be more efficient to use a minimum of 2 or 4 kB instead of 1).
Each 64 kB block would contain either one 64 kB allocation,
or two 32 kB block allocations, or four 16 kB block allocations,
etc, but never allocations of mixed sizes, thus making it
easy to find a free block of such size.
A free list is usually maintained by adding pointers inside
the (unused) memory blocks, linking them together to a linked
list of free memory blocks of a given size. That causes allocating
to be instant, but freeing memory requires to traverse this
list in order to update it's pointers. With the number of
scripts that normally run in a sim this will not be a problem.
--
Carlo Wood
___
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 Faces Of Client-Side Code
On Sat, Mar 06, 2010 at 11:19:43PM -0800, Ricky wrote: > Client Plugins Ok, although I'd prefer if-- for example-- media plugins run in a sandbox; think about the recent mention of the quicktime exploit. > 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. Since this and Client Extensions are both interpreted code, these are basically the same-- just with different permissions. I don't think we should at this point make a difference between scripts based on their source or permissions, but only based on their implementation layer. > 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. This deals with where the code comes from, not how it runs. > 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. In other words, Client Extensions-- but with more restrictions (less permissions). ... > 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. The implementation of this is still the same, just even less permissions. No? In terms of layers (one thing build ON TOP of another), we have, imho: SNOW-553 (C++ hooks; LLStateMachine) | V Inter Process Communication (IPC) support (C++; sockets; serialization) | V Plugins | V Client Extensions (including Dynamic Client Scripts, User Scripts etc). -- Carlo Wood ___ 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
It's not impossible... it's actually rather simple. That being said, I wouldn't be surprised if LL feels it's too difficult for them. [ I suppose remarks like this (that it is simple) have usually not got any weight, therefore I already added the fact that I wrote a malloc library myself in the past that is faster and three times more efficient than gmalloc (never released though), and already posted a rough outline of how it could be done. Now I, reluctantly, let me add that the concept of some individual here knowing something that Linden Lab can't do, is also not impossible. When I deleted my home directory a few years ago, then ONLY thing I could find on the net; from the FAQ to the developers of the filesystem itself, was: you CANNOT undelete files on an ext3 filesystem. Well, I did; I recovered all 50,000 files completely; and wrote a (free, open source) program to prove it (ext3grep) (in case you never heard of that, then I guess you never deleted file from an ext3 filesystem ;) The HOWTO webpage that I wrote at the same time, has been translated to Japanese, Russian, and so on. My English version got 50,000 hits in the first three days after release). I didn't take "it's impossible" for granted then, and thousands of people thanked me for that (literally, by email). I'm not going to take "it's impossible" in this case either, because this is way way way more simple :/. Sorry, but LL is just lazy. That is the reason. You're right, let them say that and I'll crawl back under my rock: "We're just lazy". ] On Tue, Mar 09, 2010 at 08:54:45AM +0100, Marine Kelley wrote: > supposed to do themselves. Oh of course this is a hard job, allocating > memory dynamically in an environment like this. Perhaps it is > impossible. I have yet to hear a Linden say, in all honesty, "sorry > guys, we can't do it as initially planned, we have to ask you to > participate by tailoring your scripts, because we can't do it from our > side". What I have heard so far is "you will be provided tools to > adapt to the change that is taking place". The two mean exactly the > same thing, but a little honesty does not hurt. This additional > workload was not planned, is a shift of work that we were not supposed > to take in charge in the first place, with no compensation, so I'd > have liked a little explanation at least. -- Carlo Wood ___ 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
This is exactly the kind of reaction that drives me away from here.
I propose a simple way get FOUR times the memory for all the scripts, at
no other cost than adding some malloc code to your mono engine.
And you simply say, "This is what we ARE doing, we're not going to change that".
Why this immovable stubbornness about internal development decisions?
In case with the below you mean to say "allowing people to set ammount
of memory at which their scripts crash, up front, is as good," then
read the past posts on this list again.
People say that it is NOT, by FAR not, as good. Scripters shouldn't
have to manually figure out the maximum ammount of memory their scripts
can possibly use and use that as the fixed ammount of memory that
their script reserves. That was last done 10 years ago. Just have the
server take care of this: give a script a minimum, and when it needs
more, give it more. No hassle for the users.
On Mon, Mar 08, 2010 at 09:46:44AM -0800, Kelly Linden wrote:
> 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.
>
> - Kelly
>
> On Sun, Mar 7, 2010 at 5:50 AM, Carlo Wood wrote:
>
> Lets assume that the *average* script uses
> 8 to 16 kB of real memory. LL's design allocates
> 64 kB regardless, leading to an overhead of
> 400 to 800% (meaning they need to buy 5 to
> 9 times the memory that is theoretically needed).
>
> In that light, I gave it some more thought, and
> think something as complex as my rmalloc's algorithm,
> with it's 19% overhead, isn't needed (note that
> it's both faster than gmalloc as well as three
> times more efficient; so complexity is not always
> a bad thing ;).
>
> Nevertheless, in this case, since the scripts
> use a maximum of 64 kB, you can use the
> following design:
>
> Let each allocated block be a power of 2
> kilobytes, with a maximum of 64 kB (and a
> minimum of 1 KB, or 4 if even the tiniest
> script needs that).
>
> It is easy to see that this would lead
> to an overhead of 25% on average per
> allocated block.
>
> We'd still have to deal with "holes" of a
> full 64 kB where blocks became totally
> unused, but normally scripts in objects are
> started all at once when a sim reboots, and
> only seldom stopped. The scripts that will
> most likely attribute to random starting
> and stopping of scripts will be the scripts
> in attachments. A worst case scenario would
> be one where there are 50 avies in a sim
> (during a meeting), then a new avie enters
> with some scripts which need to be allocated
> at the top of the heap; then the previous
> 50 avies leave. That would create a hole
> in the heap of the size of all the scripts
> of those 50 avies. If script memory would
> be relocatable, then this problem doesn't
> exist of course. I can't simply estimate
> the average overhead caused by this, but
> because the algorithm described here is
> basically the one used by gmalloc (which
> in my test used 62% overhead) I'm pretty
> sure that it will be less than -say- 100%
> overhead; still 4 to 8 times more efficient
> than the current design on the table.
>
> The API for this design would be something
> like the following:
>
> namespace script_memory_management {
>
> void* ll_sbrk(ptrdiff_t); // Increment the size of the heap
> int ll_brk(void*); // Set the size of the heap explicitely
>
> void* ll_malloc64(void); // Get a new 64 kB block.
> void ll_free64(void*); // Free such a block.
>
> void* ll_malloc(size_t s); // Allocate s bytes of memory for a
> script.
> void ll_free(void*); // Free it again.
>
> ...
>
> Assuming here that scripts cannot deal with
> relocation, otherwise one should also have:
>
> void* ll_realloc(size_t s); // Allocate a different size of memory.
>
>
> ll_malloc then will round the number of requested bytes up
> to the neares
Re: [opensource-dev] Script Memory Management Algorithm
It makes little sense to me to put time into convincing a random non-Linden. And since LL is going to ignore the whole discussion/idea anyway, I have better things to do. Sorry. On Wed, Mar 10, 2010 at 11:56:36AM -0500, Lear Cale wrote: > If it were a simple change, I'm sure it would be considered. What > you're suggesting sounds like would require a massive rewrite. I > agree that a dynamic system would be much better, easier to code and > less wasted memory. But without detailed knowledge of how the system > is currently implemented, it's not possible to assess how difficult it > would be to change from a fixed allocation scheme to a dynamic one. > > It's easy to ask for changes without regard to the cost. LL needs to > consider the cost, in terms of effort and risk. Can you do a > cost/benefit analysis on your suggestion? Or are you just being > immovably stubborn? There would be a one-time cost to write it. I doubt that needed four to eight times the amount of physical RAM weight up against any (possible) maintenance cost (which I estimate to be neglectable in the first place). > Lear -- Carlo Wood ___ 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] Backport of Tattoo and Alpha support to v1.23 ?
On Wed, Mar 10, 2010 at 03:54:44PM +0100, Lance Corrimal wrote: > plain wrong, since you can't NOT wear system hair. > you can wear system hair of length 0, otherwise known as a "bald hair base". > the one you're wearing while creating an alpha layer in a viewer with this > unfinished patch becomes broken, and turns you into a cloud. The patch is broken :p -- Carlo Wood ___ 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 limit vs server CPU utilization as a key metric
On Wed, Mar 10, 2010 at 03:51:31AM -0800, Ann Otoole wrote: > If you guys want to really help then give us the ability to disable scripts by > attachment creator name. There are certain products that cause problems. Made > by people LL props up as shining examples of how creators should be BTW lmao. This is the kind of witch-hunt that I hope won't happen. It's better to find out what is happening, understand it, and then fix it; then to start shooting uninformed around and try to get some kind of improvement by trial&error. -- Carlo Wood ___ 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] Request for comments about llSetAgentEnvironment / SVC-5520
On Wed, Mar 10, 2010 at 09:42:27AM -0800, Kelly Linden wrote: > I admit I only briefly skimmed the jira. I was mostly reacting to the panic I > saw here. I don't think it needs a permission request in the case of parcel > owners, but that is just my personal opinion. I do believe the environment > should be promoted to being part of the content and not part of the viewer, I > think we get more amazing in world experiences that way. +1 WindLight settings should have made a shared experiece a long long long time ago. For years people have been complaining about delivering half-work, about not finishing it! It is no different than whether the region default is midday, sunrise, sunset or midnight (or anything in between). A *shared experience* is an important part of Second Life, it is even mentioned in the TPV policy as being of major importance, something I whole heartedly agree with! To me, it is crucial to know that my friends, when we are exploring, see the same thing as me, so that we can react to it and weave a story around our collective experience, without that I have to ask: what is your draw distance? what is your environment setting? :( Hence, all windlight settings should at LEAST be part of the region default and be set the moment you enter, without popups or permission request by default. I suppose that some people do NOT want a shared experience and to live in their own little isolated world. Well, can't deny them power over their own viewer, so there should be an opt-in to ignore windlight settings (and keep the current one). But may I remind you that there is ALSO no opt-in to ignore the music url of a parcel, and keep the one you have set? More important questions are these: * Who can change the windlight settings? * Should there we windlight settings per estate only, or per parcel as well? And things that I would like personally are things that promote sharing windlight settings: * Allow windlight settings to be 'traded' like objects. It should be possible for ANYONE to create their own windlight setting (that only they see at that moment) and then "hand that over" to friends, or to the estate owner, or to a parcel owner, or just keep a collection of them to play with. -- Carlo Wood ___ 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] New topic: Snowglobe 2.0 way forward?
Who is going to reject a contribution to snowglobe? Ok... some can write a technically perfect patch, but with an impact that nobody wants, that's a fact (think about 2.0). So there has to be line: at some point it has to be decided if a patch should be accepted; but how does that work? On Wed, Mar 10, 2010 at 01:20:44PM -0500, Mike Monkowski wrote: > Except for Merov's contributions, I don't think Snowglobe ever had a > planned direction. The direction was just the sum of the contributions > people made to it. And I expect it will continue that way. If someone > thinks that chat needs to be fixed and they have the time to fix it, > then they probably will. The real question is whether such a > contribution would be accepted. I happen to think it would be dangerous > to reject such a contribution. > > Mike -- Carlo Wood ___ 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] Request for comments about llSetAgentEnvironment / SVC-5520
On Wed, Mar 10, 2010 at 06:40:23PM +0100, Latif Khalifa wrote: > I'm talking about implementation of > http://jira.secondlife.com/browse/VWR-7677 not the LSL script setting > environment. Yes, the region setting would be shown by default, > because otherwise it wouldn't make any sense. Asking for permissions > for stuff like setting light and sky settings makes as much sense as > asking for permission to show a house in your viewer once you have > entered a region. +2 If region settings aren't shown by default (where people can use advanced to reject any changes to their environment for all I care), then it makes no sense. While, if an in-world object uses LSL to change the windlight settings of one particular user, it should ask for permissions first. Even if that object is owner by the sim owner. -- Carlo Wood ___ 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] Request for comments about llSetAgentEnvironment / SVC-5520
On Wed, Mar 10, 2010 at 09:57:50AM -0800, Kelly Linden wrote: > The very sky around you should be part of the content, part of the > place. I can't get over how awesome I think that would be. > > - Kelly This is the first time I actually hope that LL is going to do what they want... if Kelly represents what they want that is :p Still a bit concerned about the immeasurable delay that occured between implementing WindLight in the viewer and now, though :/ when are we ever going to see this finished? -- Carlo Wood ___ 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] Request for comments about llSetAgentEnvironment / SVC-5520
On Wed, Mar 10, 2010 at 01:05:38PM -0500, Maggie Leber (sl: Maggie Darwin) wrote: > I can just imagine a new use for all those tiny little ex-adfarm > parcels along mainland roads: noob traps that force a blinding > Windlight set on the unwary. You're being a child with all this :/. Why aren't you complaining about: * noob traps that force a high pitched squeel in my headphones when I enter their parcel. God forbids parcel media. * noob traps that force me to look at 4 meter high advertisement billboards. God forbids texturing by users, or building. * noob traps that cause unexpected main road walkers to drop into 4 meter deep holes. God forbid terrain editting, or at LEAST diable phantom for parcel owners so they can't cover up their traps! * noob, noob?? Damnit, even I walk often happy and immersed into a parcel when suddenly "You are ejected from this parcel!" I want to decide myself where I go ok? Suddenly being banned from a parcel for, no reason whatsoever mind you, highly destroys my feeling of being immersed the world. Why not have a prim pittbull chase me or something realistic? Being ejected should be an opt-in, at the very least!!! -- Carlo Wood ___ 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 2.0^H^H^H1.3 way forward?
On Fri, Mar 12, 2010 at 08:47:57AM -0800, Soft Linden wrote: > With larger features like mesh coming along, know that you'll be > signing up for an awfully large chunk of porting work though. Last time I asked there was nothing being done about mesh. There were no plans and certainly no code! Are you telling us now that mesh "support" is going to be done in secret too? -- Carlo Wood PS "support" between quotes, because I can't take anything serious that is added in secret, without talking with your backbenchers first. ___ 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 2.0^H^H^H1.3 way forward?
Why "fix" this? What is the urge in using it at ALL? Imho, ignoring it so much better. How care that it exists, and is broken? Just don't use it! Sorry, I really don't get why anyone here is trying to get to compile it, trying to fix it, trying to run it, trying to use it. Is there anything added to 2.0 code that actually is an improvement over snowglobe 1.3 ? Don't be fooled by the "2", yes 2 > 1 in mathematics, but this just a different viewer. The version number is COMPLETELY irrelevant. Hell, from now on I'm going to refer to it as 0.2. Wake up! On Fri, Mar 12, 2010 at 12:21:29PM -0500, Robert Martin wrote: > And lastly could somebody please create some sort of Skin SDK so that > the folks fixing YOUR errors have the resources to do things > "properly" -- Carlo Wood ___ 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] Request for comments about llSetAgentEnvironment / SVC-5520
On Fri, Mar 12, 2010 at 10:18:15AM -0500, Lear Cale wrote: > I agree. WL settings are about the appearance of the environment, not > the GUI per se. > And Carlo has a great suggestion that WL settings should be supported > as inventory items, similar to LMs. (Going to make a JIRA for that, > Carlo?) Welll... making jira's a bit like reporting theft of your bike to the police. The police keeps saying they want it, but at some point you stop doing it. -- Carlo Wood ___ 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] oh give me a break
What worries me is that before, correctly, it was stated: copybot is not illegal, copying something and then SELLING it is. If some really good hacker does exactly that what everyone says: get content that simply can't be protected, then that doesn't mean he will start a business with it and make USD$ 100,000 per year with products of others. And until someone does that (sell products of others), it's innocent childs play. Therefore, copying stuff isn't that bad by itself imho (please raise your hand if you really never download a movie from the internet). I really, really hate witch hunts, where something is blown out of proportions and then attacked in ways that have nothing in common with reality anymore. -- After a couple of weeks in SL I decide happily to become a magician: someone with knowledge that the average user didn't have. Someone who could do things in-world that most people didn't even know were possible. Being able to do magic doesn't make one evil. You can use magic for good things too. Now all those dreams have been killed with this TPV policy, making my happy fantasies illegal and having a ban hanging like a dark cloud above my head. I wish that just immoral things were made illegal... not fun things. On Sun, Mar 14, 2010 at 07:41:53PM +0100, Marine Kelley wrote: > Err... Content theft has always been a problem, will always be a problem, and > LL better be on the same page with developers, content makers and customers > here. Content theft is not to be tolerated and must be fought. But some > critical parts of the whole system have been put on the client side at a time > when there was no question of the client to be open-sourced. Then LL decided > to > open-source it, and had to face many vulnerabilities that were suddenly > exposed, and to plug them one by one. -- Carlo Wood ___ 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] oh give me a break
Now you mention it... Yes, a few people are making thousands of dollars per month and are having their RL day job in SL... so, now they would kill to protect that income, but... Imho, SL would have have had better products if everything had been free and open (no permission system). Then one could learn from others and improve things, build upon the experience and work of others, and nobody would make money of it or have to be afraid that others would. The fact that scripts can't be copied is lucky for those that are making real money in SL, it is their only and last protection against losing their income. That brings me to the fact that LL is currently working in secret and without discussion on the implementation of client-side scripting, and from the tiny bit of information that leaked out, they are apparently trying hard to make also THOSE scripts hard to copy / inspect / improve upon. Why? Is anyone already making money with client-side scripting? No. So why try to make it impossible to copy it? Anti open source? Or maybe just trying to protect their OWN income by using the law (TPV) on one hand and obscurity (binary client-side script blobs) on the other hand to avoid that four years worth of assets flow to other grids. I'm sorry to think that LL would be happy if opensim grids would be bare lands that literally lag four or more years behind in content. That is why I have to wonder if LL's suddenly attempts to protect Intellectual Properties isn't actually driven by self preservation only. And I still want OPEN client-side script development. On Sun, Mar 14, 2010 at 03:22:03PM -0700, Lawson English wrote: > So lets open up all scripting sources too. I mean no need for content > protection there, either, right? -- Carlo Wood ___ 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] oh give me a break
I hope that because your post was a reaction to mine, people will NOT think that I share your ideals in the same anarchistic way. I feel the need to state that I don't. First of all, I have a good friend in-world that makes his living in-world. And I'd do anything to help him, because he is a very cool, nice person and everything he does (and sells) is his own original and hard work. Secondly, this mailinglist, and this thread in particular is to wake up Linden Lab with the GOAL of a better communication. Shouting that "we hackers" should force them to "free" Second Life content by breaking the law is hardly constructive. My goal is that Linden Lab becomes less secretive and more open about their plans and designs before those are set in stone; the only reasonable goal can be one where then a civil and professional discussion follows where everyone has their say, after which LL (with new insights) makes their decision and convinces everyone of the real reasons why they make that decision (thus not: "the users want this", but "sorry, you are right, but we can't do that because we a for-profit company". Whatever the argument, if it was correct I'd shut up. On Sun, Mar 14, 2010 at 09:01:15PM -0600, New Hax wrote: [...snip...] > Everyone who believes in a real OPEN grid should get out there and > copy and FREE (do not charge for it) as much proprietary content as > you can. Teach content makers and Linden Labs by force (we have > control) that the only future is FREE. [...snip...] -- Carlo Wood ___ 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] oh give me a break
On Mon, Mar 15, 2010 at 01:29:16AM +, Thomas Grimshaw wrote: > *I own and even have developed software that can copy any content from > second life. Have I ever used this to violate copyright? Nope, I just > didn't want to spend time building in content protection when the > software was only for my use (to export my own builds, animations etc to > opensim). Or wanting to modify it for personal reasons (not to modify it and then sell it). Lots of products are no-mod under the false impression that that makes it harder to copy them, while it only advocates copying. I only ever buy things that are modify. Often I want them to be copy too, because I want a backup if I'm going to modify something (or maybe multiple versions until I'm satisfied with the end result). Finally, I need them to be trans often, because I have a partner in world and we share everything. What is mine is his and visa versa. Buying two of the same doesn't work if you want to modify things (The product costs only L$ 100 (USD$ 0.36) but modding it to fit my avie costs 2 HOURS (USD$ 100) and I really don't like to do that TWICE). How could we (... ok Linden Lab, cause we don't control the servers), improve things? * Allow people to keep a copy of modifiable objects in their inventory: change "no copy" to mean: only one may be rezzed at a time; but you can copy them inside your inventory and change them all seperatedly. (In fact, why not allow to sell products that can be rezzed N times, but no more). * Allow giving no-trans copies to your partner anyway (make being a partner have a meaning). Still only one could be rezzed at a time if it's no-copy, but in that case you could buy two. * Allow transfering modifications (after all those are your I.P.). Thus: buy Product --> copy product (in inventory, always possible) --> rez one copy and modify Product (this copy will have to remember the original anyway, because it needs to keep track of how many are rezzed), then allow to transfer/copy the changes between the two to anyone; this new asset should allow the new owner to apply it to the same Product (which they can buy from the original creator of needed), in fact this should be automated: * Allow to point-click buy objects in world. Such an object might be created by X, then modified by Y and then modified by Z; each could have put a price on their modifications. The result might be too expensive, so it should be possible to quickly view the previous mods as well. > *So what can we do? > > *Please excuse a possibly callous tone - but STOP whining and start > thinking outside of the box. You *will never be able to stop piracy > completely* - so don't even try. I've already explained why I think that > piracy is a war of convenience, and the solution is simple - make your > content more convenient. See above :) *) *) .--. | | | | <--- Original box here. | | | | `--' > - Maximise accessibility. Keep your stores lag-free, don't use silly > teleport routing, and make your store organisation transparent. Sorry, but the most annoying of all is to see a product in-world and then have to find the creator, then his picks, then guess which pick might be a LM to the shop where the product is sold, and then either end up in bare land cause the shop moved or to end up on a sim-sized "shop" where you can't find the product. What is wrong with this image: "OMG! I want that!" *right-click->buy->pay*done*. > - Don't intimidate your customers. For goodness sake, shut off those > stupid "copybot protection" scripts (they don't even work), and take > down those copyright notices. If these people are in YOUR store, it > means they're not in a store selling pirated stuff. Treat them with respect. My creator-friend has this text in his Picks: Please don't copybot my products. If you can't afford it, ask me and I'll give to you for free. [...snip...] Carlo (without an 's'). ___ 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] oh give me a break
On Mon, Mar 15, 2010 at 04:22:58PM -0600, Maya Remblai wrote: > Not true. See the following example that actually happened to me: > > Person A rips a large number of products, including mine. He boxes them > and gives them away, for free, claiming he has my permission (which he > doesn't). Now, the total value of my products involved was $150 USD. If > he only gave the box to 10 people (it was actually more than that) I'm > now out $1500 USD. Person A has done a huge amount of monetary damage to > me by taking away sales. Not entirely true, first of all, he didn't steal any money from you, nor any goods; unless you suddenly saw a significant drop in revenue then nothing really happened, financially spoken. It certainly isn't true that if he did NOT give that box to those ten people that all ten would have come to you and spend L$ 40,000 in your shop. In fact, most people spend a fixed amount of money in SL. If they get anything for free on top of that, it doesn't cause them to spend less real money. So, surely, you didn't get any MORE money because of this.. but you didn't *lose* $1500 either, not even a fraction of that. -- Carlo Wood ___ 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 related with rotation of object
Why do you want to know that? What is the patch that you're working on; which jira is relevant to this? On Wed, Mar 17, 2010 at 07:41:18PM +0900, Rustam Rakhimov wrote: > > Hi second live programmerriors (programmers+warriors), > > I have a question related with rotation of object. Where exactly rotation > parameters are saved in. > > For clarifying my question lets bring some example. I have some cube object, > that object has a properties, like position, size(width, height, length) and > rotation parameters. So as you know rotation parameter saves in three values > (x,y,z) or (roll, pitch, yaw), so I want to know where is exactly these > parameters of object saved, and how I can manipulate with them. > As I know if I'm going to use setRotation(x,y,z) function of lviewerobject > then > that object can be rotated. And what does it means these three values of > rotation, It's not degree of angle. > > So is there anyone who know where I can find these variables. > > I'm really sorry for my poor English, if something is not clear please inform > me, I can clarify situation more > > > take care !!! > > > > Rustam > ___ > 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 -- Carlo Wood ___ 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 scripting REST/HTTP doc sample
Heyas Dzonatas, nice work. I think this approach needs serious consideration. Perhaps you can be so friendly as to explain to the list what defines REST, and why this approach is a RESTfull implementation? On Wed, Mar 17, 2010 at 10:21:06AM -0700, Dzonatas Sol wrote: > Here is a sample of the REST/HTTP doc for SNOW-375. > > SNOW-375 adds a HTTP server in the viewer to be easily accessible by any > process or client-side script in a language agnostic manner. > > I posted this here to hopefully encourage forward movement in > client-side scripting and to avoid the backpedal and reinventions. > > Note: This is tried, tested, and works. This is not just "talk" or > made-up documentation. > > + > > SNOW-375: REST/HTTP URI patterns and response summary as of March 2010 > > All names that appears in angle brackets, <>, are variable. > > Note full URI paths used, yet these don't include the > "http://host:port/"; designation. > > Example URI: http://localhost:50140/ControlGroup/SavedSettings > > All responses are wrapped in LLSD (examples not included in this doc). > > Most of these use the GET method, and combined/burst throughput via the > POST method. > > > /ControlGroup > > Response is a list of control groups. > > > > /ControlGroup/ > > Response is a list of valid variables in a controlgroup with default > settings > > is currently either "SavedSettings" or "SavedPerAccountSettings" > > > > /ControlGroup// > > Response is a detailed and update of current settings for the specific > variable identified. > > is currently either "SavedSettings" or "SavedPerAccountSettings" > is a valid variable name from one of the variable control > groups. > > > > /Agent/Groups > > Response is a list with details of groups joined by the connected agent. > > > > /AvatarTracker/Friends > > Response is the UUID list of the agent's friends and basic status of each. > > > > /AvatarTracker/Friend/ > > Response is a detailed relationship information for a specified friend UUID. > > > > /GestureManager/Items > > Response is a list of UUID of active gestures. > > > > /GestureManager/Item/ > > Response is the details of a MultiGesture structure for the UUID specified. > > > > /Inventory/Item/ > > Response is the details of an inventory item specified by the UUID. > > > > /Inventory/Root > > Response is the UUID of the root inventory folder. > > > > /Inventory/Category/ > > Response is the UUIDs of the descendant categories and items of the > specified UUID. > > > > /Asset/Notecard/ > > Response is the notecard item specified by UUID converted to XML format > (rather than 'linden notecard format'). > > > /Interface/Connect > > POST: Attempt to negotiate a connection to enable the above resources. > * Details of connection steps not included in this doc. > > > /AvatarTracker/Friend/s > /GestureManager/Item/s > /Inventory/Item/s > /Inventory/Category/s > > POST: List of UUIDs for combined query, as above where is replace > with just an "s". > Response: List of combined queries as if each item is an individual > responses to each UUID. -- Carlo Wood ___ 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] "vendor" branch and Snowglobe 2.0
On Wed, Mar 17, 2010 at 05:52:55PM -0700, Philippe (Merov) Bossut wrote: > Long Story > I'm pretty much done with all the export script writing now and I'm moving to > make all that live so that updates from the viewer trunk come in more > regularly > and automatically. "regulary" doesn't mean that commits by internal developers are merged before committed, or that their commit messages are lost, is it? Ie, if at 15:00 Foobar Linden commits 5 lines with the text "Don't sleep(1) here", then I'm happy with that being delayed 24 hours, but I'd really still like to see it committed to snowglobe (whatever trunk) as a single commit of 5 lines with the same comment (and WHO did that commit). Can you elaborate on how this is going to look like? Thanks, -- Carlo Wood ___ 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] Proposal: Howto add a new feature to snowglobe.
Here is some food for thought: -- Question: Who determines what is added to the viewer and what not? I propose (to be decided by Lindens, not others) the following: There are two different categories of things that can be added to the viewer: Category 1: Bug fixes; intended behavior is not as expected. Category 2: Features; intended behavior is changed (added). Category 1 -- These are handled the same as category 2, but without the need to decide at the user-experience level if the patch is wanted. Thus, for *accepted* feature AND bug fix: A committer writes the patch. The patch is reviewed by other committers. No committer can stop a patch entirely, but they can request patches to be taken back to the drawing board based on: * CPU usage (FPS drop) * Memory usage * Coding style * Maintainability (how easy it is to make changes without breaking it) * Robustness (chance it breaks accidently by changes elsewhere) Committer are expected to work together and respect eachother, but especially the original committer needs to be prepared to spend another week or two to address each and every comment made by other committers (for which the jira is used). When all other committers involved, with a minimum of one other committer, are satisfied; the patch may be committed. Category 2 -- In the case of a new feature, the new feature should really first be discussed on this list, before being implemented. What is being discussed are the effects on the users, not the technical effects like CPU usage etc. Non-committers can (politely) provide insight and feedback, but do not have any vote on whether or not a new feature will be added. In fact, nobody has a vote: in the end it's the call of Linden Lab, where we assume that if any Linden speaks his/her decision on the list that that is the internal decision of Linden Lab (and another Linden will not suddenly oppose). Each feature must be carried by a committer. That is, someone must step forward and offer to write it, test it and be prepared to through the hassle of Catergory 1 above. In most cases this will be a committer whose own idea the feauture is, that is the advantage of putting time into actually writing (good) patches. It is not a bad thing that committers have this priveledge. Of course, it is also possible that a committer decides to backup an idea of someone else. [There is no reason he cannot be paid for that, but I expect that in general this will not be the case]. Linden Lab will take the following into account when making their decision about a new feature: * This is about Snowglobe ONLY; whether or not it's also added to the official viewer is a separate issue. * They will NOT take maintainability into account, that is the responsibility of the open source community. * If the new feature has no last impact on the user base, which can always be achieved by making it optional and/or not the default, they will let themselves strongly be influenced by the consensus of the list discussion. * The opinion of committers is taking more into account than the opinion of non-committers, because it's the committers who have to maintain the code. * The decision is made in a timely manner (ie, within two weeks after the discussion on this list dies out). If no decision is communicated within a reasonable time, they right to a final decision forfeits and the feature may be added (all with gentlemen agreement of course). For example, the Life Cycle of a new feature might be the following: * User thinks of new feature and adds it to the jira. * Several people find it and vote for it. * Feature comes to the attention of someone on this list and brings it under the attention of a committer. * Committer commits himself (haha) and post to the list with implementation detail ideas. * Everyone has their say in a civil and polite way. * The design (on "paper") goes through a few cycles until the committer that committed himself doesn't want to make more changes. * Linden Lab gives the red or green light. * In case of a green light, the committer writes a patch and tests it. Then attaches it to the jira. * At least one other committer tests it and makes comments about implementation details. * Original committer rewrites the patch and/or fixes bugs, until all other committers that want to spend time on reviewing are satidfied. * The patch is committed. -- Carlo Wood ___ 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] Request for clarification on mailing list guidelines
Imho, the jira should be used for technical facts regarding a bug only, and not for opinions. General feedback is better discussed on this list. On Thu, Mar 18, 2010 at 08:38:53AM -0500, Sheet Spotter wrote: > If a topic generates more than five replies in less than 24 hours, it's time > to > redirect that conversation to one of our other tools, either the wiki, the bug > tracker, or a thread in the appropriate forum. > > There are a few discussions occurring in [opensource-dev] which have been > occurring for a considerable time. These discussions each have a JIRA entry > that deals with the specific issue. -- Carlo Wood ___ 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] Proposal: Howto add a new feature to snowglobe.
In what respect did I miss this? Are you implying that it should be possible to add new features that Linden Lab *disagrees* with? If not, and as you say they don't disagree with VWRAP, then I don't see the issue. VWRAP compatibility falls in category 2, it's a new "feature", hardly anyone here will be even interested in given feedback because it's rather straight forward (add VWRAP compatibility to snowglobe) and that will not change any ones user experience, apart from adding possibilities). LL will say: ok go ahead, and then we can start to implement it. The main reason that I think that LL has the last say in what goes into snowglobe is because they (merov? maybe it should just be merov's call) has to keep syncing the main viewer with snowglobe. For example, if I propose to run 'indent' on the source code and change the indentation of every source line then Merov will stop that 100MB patch from being committed. It is mainly with that issue in mind that I wanted to give LL the last say about new features. If it was possible to add arbitrary extra code and/or make arbitrary changes without that it gets harder and harder to keep up with changes in the main viewer, then it would the call of the open source community as much as that of LL imho. But that is not the case. On Thu, Mar 18, 2010 at 05:23:44PM +, Morgaine wrote: > Carlo, you're missing something very important in your write-up. > > The issue that you haven't covered is that Snowglobe is intended for > interoperation with other worlds as well, not just with SL. Our work in VWRAP > has the goal of allowing a single client to work with any virtual world that > can speak the protocol, and this applies very directly to Snowglobe. [...] -- Carlo Wood ___ 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] Proposal: Howto add a new feature to snowglobe.
Seem like a good moment to point out that is was ME who made up the name VWRAP :) *proud* *eternal fame* *immortality syndrome* YAY! On Thu, Mar 18, 2010 at 05:41:53PM +, Morgaine wrote: > I expect that before long, the prefix 'vw' will become as fashionable as 'e' > and now 'i'. ;-) > > Morgaine. -- Carlo Wood ___ 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] Proposal: Howto add a new feature to snowglobe.
On Thu, Mar 18, 2010 at 07:56:39PM +, Morgaine wrote: > If it was possible to add arbitrary extra code and/or make > arbitrary changes without that it gets harder and harder to > keep up with changes in the main viewer, then it would the > call of the open source community as much as that of LL imho. > But that is not the case. > > Nobody referred to "arbitrary extra code", no straw men please. ;-) That is not a strawman. Only if ANY code would not get in the way of merging it would be ok to not ask LL for permission. > Some things will be perfectly reasonable to expect in Snowglobe, agreed by > patch developers and full committers to be a good thing, even when Lindens may > choose not to import them back into their vendor branch (yet). As an example, Allow me to quote from my original post: Linden Lab will take the following into account when making their decision about a new feature: * This is about Snowglobe ONLY; whether or not it's also added to the official viewer is a separate issue. Thus, I already formulated it that way. -- Carlo Wood ___ 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] Proposal: Howto add a new feature to snowglobe.
On Thu, Mar 18, 2010 at 06:00:08PM -0300, Tigro Spottystripes wrote: > what if the bug fix includes changes in behavior that for some users is > considered a bug in itself? (like how it happened at first with the > issue of auto-granted permissions permanency being abused, where the > initial proposal of simply auto-revoking hen the avatar stands up would > break content that produced a graceful transition from sitting to > standing up by animating the avatar right after it stopped being sat on > the prim) If it really breaks a lot of content then the bug was apparently a feature ;). In that case it might be considered undesirable to "fix" the bug as if it never existed; some backwards compatibility might be needed. However, I don't think that that should be very much the concern of Linden Lab. If the consensus on the list is that a bug should be fixed even if it breaks existing content then we have apparently a reason for that. Linden Lab (read: merov) should foremost look at the extra work that it will create to keep the internal repository in sync with a snowglobe that has this feature / bug fix. If Linden Lab does not want the bug fix as you decribe, then I think the best approach is to try and convince the committer who offered to put time into fixing it, to do it in a different way, so that his patch WILL be accepted in the official viewer. -- Carlo Wood ___ 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 Mecurial Repository
What is the advantage again of hg (over svn)? (why the move) On Thu, Mar 18, 2010 at 05:18:54PM -0700, Dzonatas Sol wrote: >It would > be the wrong impression, further, to assume the same committers will > take on the extra load to help move to hg. -- Carlo Wood ___ 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 Mecurial Repository
Doesn't hg use diff3 in the end, to do the merges? Every repository does. The difference between CVS and subversion was that CVS applies diff3 on the source files, and therefore couldn't deal with renaming files at all. Subversion has the provision of remembering file renaming separately, so it can front-end that for diff3. hg doesn't add anything in that regard it seems. Surely it remembers renaming of files, cool-- so does subversion. What cutting a complete function out of one file and moving it to a different place in the same file, or moving it to another file? (function aware). What about adding namespaces around functions, so that the functions are the same, but inside a namespace now? (C++ / namespace aware) What about indenting and other whitespace changes? Does it do (merge) that? Does it do anything new? On Fri, Mar 19, 2010 at 09:41:43AM -0700, Dzonatas Sol wrote: > Yes, the greater community has used git, yet the main point is we need > to expire svn in order to help maintain merges easier and in a more > distributed fashion. LL uses hg internally. -- Carlo Wood ___ 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 Mecurial Repository
Actually, I think I understand why. LL is using hg internally, and has been for a while. They just pushed things out as svn for public access, but that process caused all the meta data to be lost and had to be done manually, and therefore only sometimes in big large chunks. It is for the benefit of snowglobe that commits to the internal repository are available with meta data and as the original change sets, once they are merged with the public repository. With hg this is possible: just push the changeset to the "public hg repository", but only if that public repository run hg itself. On top of that, merging branches is much easier (according to http://hginit.com/00.html), that holds for merging changes from internal into snowglobe but also for TPV's assuming they switch to hg as well. It should become much easier for us and for others using hg to merge 'upstream' changes with the ever growning set of local patches and extensions. -- Carlo Wood ___ 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] left and right arrows change to strafing in mouselook
On Sat, Mar 20, 2010 at 01:08:52AM -0500, SuezanneC Baskerville wrote: > A thread about WASD keys caused me to think of something that has always > bugged > me about SL, the way the left and right arrow keys change from rotating to > strafing when you enter mouselook. This not being a combat game, there > doesn't seem much point to this. Because of this, I hardly ever use > mouselook. > I suspect this seems senseless and is annoying to many other non-gamers. > > Perhaps making this optional would be appropriate for Snowglobe. +1 Exactly the same for me: once in mouse look I lose all control over my avatar because of this, so I never use it except when I'm sitting or just standing still, to look around. -- Carlo Wood ___ 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] Third party viewer policy: commencement date
On Sat, Mar 20, 2010 at 09:21:25AM -0700, Joe Linden wrote: > The updated version of the Third Party Viewer Policy was posted here about a > week ago: > http://secondlife.com/corporate/tpv.php That says that if a developer changes the code and distributes it, you reserve the right to pursue any and all legal and equitable remedies: 3 a. If you are a [...] Developer of Third-Party Viewers, you must not: [...] design Third-Party Viewers to [...] If we believe you are or have been associated with activities that violate this paragraph, either within or outside of Second Life, we may take any enforcement action we deem appropriate [...] and pursuit of all legal and equitable remedies. 7 d. You (Developer of Third-Party Viewers) assume all risks, expenses, and defects of any Third-Party Viewers that you [use,] develop, or(!) distribute. This is not compatible with the GPL. Therefore, anyone who contributed to the GPL-ed code has a case if they want to retract their contribution. -- Carlo Wood ___ 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
