From ypankrat at meralabs.com Wed Oct 1 14:23:23 2008 From: ypankrat at meralabs.com (Yuri Pankratov) Date: Wed Oct 1 14:23:20 2008 Subject: [sldev] [IDEA] A new data structure for SL database servers Message-ID: <001201c9240b$f24f8e30$c006520a@YURI> Hello everyone, I am new to this mailing list so let me introduce myself first. My name is Yuri Pankratov, I am a post-grad student and a research engineer from Russia. I have been a SL resident for quite some time now and while I find SL to be a wonderful idea with great implementation, I have to say that it is facing some scalability problems: with so many concurrent users the database servers are extremely stressed. This causes many unwanted things to happen, like increased lag, inaccessible inventory or inventory loss. I have suffered all these things myself. There is good news, though. It happened so I became a research engineer in an R&D company. One of the company's projects is devoted to the creation of an innovative distributed data structure which would allow to create virtually infinite data repositories. An even better news is that the data structure provides a O(log n) data search algorithm, which means that you can quickly find required data even in a very large data repository. The data structure in its current implementation is intended to store data in XML format. That gave me a thought: "Hey, most SL data is stored in XML form, so maybe our data structure would be just the thing for storing SL data!". I would be really glad if Linden developers would take interest in my idea. I also welcome everyone to express their opinion on the topic. The name of my company is MeraLabs and the name of the data structure is "Metrized Small World". Now, some useful links: My company's website: http://meralabs.com This is an example of how the data structure looks: http://meralabs.com/media/meralabs/images/skeleton_100k_v2.png An article describing the data structue in detail: http://meralabs.com/media/meralabs/publications/files/METRIZED_SMALL_WORLD_PROPERTIES_BASED_DATA_STRUCTURE.pdf The company's press-release which metions the data structure: http://www.24-7pressrelease.com/press-release/meralabs-company-presents-an-innovative-data-storage-technology-63155.php Also you may want to see another our press-release which describes our concept of Cognitive Internet (I think it goes well with the philosophy of SL creators): http://www.24-7pressrelease.com/press-release/meralabs-envisions-that-the-internet-of-the-future-will-be-cognitive-66192.php Best regards, Yuri Pankratov. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20081002/1749365a/attachment.htm From tom at streamsense.net Wed Oct 1 14:36:46 2008 From: tom at streamsense.net (Thomas Grimshaw) Date: Wed Oct 1 14:37:03 2008 Subject: [sldev] [IDEA] A new data structure for SL database servers In-Reply-To: <001201c9240b$f24f8e30$c006520a@YURI> References: <001201c9240b$f24f8e30$c006520a@YURI> Message-ID: <48E3ED6E.7080008@streamsense.net> Yuri Pankratov wrote: > > I also welcome everyone to express their opinion on the topic. > Is the technology being developed as closed and proprietary? If so, it's probably not going to stir up much interest in this list, and you may wish to send a proposal directly to linden lab. Tom From ypankrat at meralabs.com Wed Oct 1 14:49:52 2008 From: ypankrat at meralabs.com (Yuri Pankratov) Date: Wed Oct 1 14:49:45 2008 Subject: [sldev] [IDEA] A new data structure for SL database servers (2) Message-ID: <004b01c9240f$a3cc62c0$c006520a@YURI> > Is the technology being developed as closed and proprietary? If so, > it's probably not going to stir up much interest in this list, and you may > wish to send a proposal directly to linden lab. > > Tom Yes, it is a patented technology. Yet it is still in its prototype phase, so my aim is not to sell it, but to know if Linden Lab developers would be interested in it. Then probably it would be a good idea to send a proposal directly to Linden Lab. By the way, if you could give me a hint of how I can send the proposal to LL, I would be really grateful (I didn't find that information on their website). Establishing contact with LL so we can (probably) join efforts to bring good ideas to life would be a good start. Yuri. From alissa_sabre at yahoo.co.jp Wed Oct 1 15:02:32 2008 From: alissa_sabre at yahoo.co.jp (Alissa Sabre) Date: Wed Oct 1 15:02:43 2008 Subject: [sldev] Several questions regarding "fully localized viewer" Message-ID: M Linden wrote on a recent blog posting ( http://blog.secondlife.com/2008/09/29/4-months-at-the-lab/ ): Experience Localization: ... By the end of the year, the viewer will be fully localized for all our major markets. This sounds great and exciting ... but what does "fully localized" mean? What improvements can we expect by the end of the year regarding viewer localization? What geographical/cultural regions does your "major markets" cover? Well, when do you disclose the planned features list for the "fully localized" viewer? When can people outside LL see the viewer source with the features? I can't wait! Alissa Sabre -------------------------------------- Enjoy MLB with MAJOR.JP! Ichiro, Matsuzaka, Matsui, and more! http://pr.mail.yahoo.co.jp/mlb/ From robla at lindenlab.com Wed Oct 1 15:18:35 2008 From: robla at lindenlab.com (Rob Lanphier) Date: Wed Oct 1 15:18:49 2008 Subject: [sldev] Several questions regarding "fully localized viewer" In-Reply-To: References: Message-ID: <48E3F73B.5060909@lindenlab.com> On 10/1/08 3:02 PM, Alissa Sabre wrote: > M Linden wrote on a recent blog posting > ( http://blog.secondlife.com/2008/09/29/4-months-at-the-lab/ ): > > Experience Localization: ... By the end of the year, the viewer > will be fully localized for all our major markets. > > This sounds great and exciting ... but what does "fully localized" > mean? > Hi Alissa, My understanding is that there's been a lot of work going on both with working with outside firms on updating our existing viewer translations, and doing a lot of work to revamp the infrastructure to make it easier to work with you all on translations. Danica Linden is responsible for our localization strategy and has more details. Rather than pulling in Danica for a more detailed response here, I'd like to refer you to (previously) well-kept secret, which is the community translations project (ctproject) mailing list: https://lists.secondlife.com/cgi-bin/mailman/listinfo/ctproject Danica manages the list. There hasn't been much traffic on that mailing list yet, but this seems like quite an appropriate topic to discuss there. Rob From alissa_sabre at yahoo.co.jp Wed Oct 1 15:52:25 2008 From: alissa_sabre at yahoo.co.jp (Alissa Sabre) Date: Wed Oct 1 15:52:37 2008 Subject: [sldev] [i18n][l10n:zh] Viewer Chinese Translation - In-Reply-To: <48E2E3BD.4000106@gmail.com> References: <48E2E3BD.4000106@gmail.com> Message-ID: <1en4kYsfJdds46ox3LJ4.alissa_sabre@yahoo.co.jp> > Umm, no. "Atom" is a different word than "element"(we're not talking > about the chemical type either, mind you). I know that prims in SL is > meant to be taken as "geometric primitives", but I'm not sure how to > translate that, so I put it as "elemental pieces". I'm not fluent in Chinese either, but I do have a feeling the suggested "??" is far better than "??" (simple/introductory), which is apparently a mistake. I don't think "??" nor "??" is better. Another thing is: You suggests "??" instead of "????" for "in-world". I guess you are not comfortable with ??, because SL is not a game. I'm afraid, however, that, as you know, the English words "in-world", or just "inworld" recently, have some special meaning in our context, and the users may not get that meaning if we simply say "??" (or probably " ???" when "in-world" is used as an adjective.) When I proposed revising Japanese translation, I used "SL?" (in-SL) because I and my colleagues couldn't find a good words... Hope this helps and Lindens starts hearing voices from translators' outside LL, Alissa Sabre -------------------------------------- Enjoy MLB with MAJOR.JP! Ichiro, Matsuzaka, Matsui, and more! http://pr.mail.yahoo.co.jp/mlb/ From infinity at lindenlab.com Wed Oct 1 16:06:10 2008 From: infinity at lindenlab.com (Meadhbh S. Hamrick) Date: Wed Oct 1 16:06:14 2008 Subject: [sldev] LLSD base16/base85 support In-Reply-To: <61dbdd7d0809131601p6251d16bh24d09e849fc8ceff@mail.gmail.com> References: <48CC282B.9080309@signpostmarv.name> <61dbdd7d0809131601p6251d16bh24d09e849fc8ceff@mail.gmail.com> Message-ID: <82AEA2E9-C38A-4A4D-B2F8-6E7E1E031BDE@lindenlab.com> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 486 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20081001/593971b9/PGP-0001.pgp From robla at lindenlab.com Wed Oct 1 16:52:49 2008 From: robla at lindenlab.com (Rob Lanphier) Date: Wed Oct 1 16:53:03 2008 Subject: [sldev] Re: [sl-ux] [i18n][l10n:zh] Viewer Chinese Translation - feedbackwanted? In-Reply-To: <48E2D92E.4030101@gmail.com> References: <48E2D92E.4030101@gmail.com> Message-ID: <48E40D51.4060101@lindenlab.com> On 9/30/08 6:58 PM, Geneko Nemeth wrote: > In the past year, partly out of being unsatisfied with the existing > translation (which is inaccurate and outdated), I translated parts of > the Viewer into Chinese (simplified). > > I tried to submit (see http://jira.secondlife.com/browse/VWR-4263 ) > however, it wasn't accepted. Didn't stop me from continuing to translate > other parts of the client however. > Hi Geneko, There's been a lot that's happened since you last submitted that translation. As you might guess from my mail earlier today on sldev, I think this would be a great topic for discussion on the ctprojects list: https://lists.secondlife.com/cgi-bin/mailman/listinfo/ctproject I'm really glad you've continued this work undeterred! Rob From darien.caldwell at gmail.com Wed Oct 1 16:57:14 2008 From: darien.caldwell at gmail.com (Darien Caldwell) Date: Wed Oct 1 16:57:18 2008 Subject: [sldev] [i18n][l10n:zh] Viewer Chinese Translation - feedback wanted? In-Reply-To: <48E30EAD.8010302@mac.com> References: <48E2D92E.4030101@gmail.com> <48E2DDB0.5070301@mac.com> <48E2E3BD.4000106@gmail.com> <48E2EDC7.6080300@weblogsinc.com> <48E30EAD.8010302@mac.com> Message-ID: <835a5b860810011657q1442254tb0d61715de8f944f@mail.gmail.com> Elemental piece makes sense for primitive. That's what it is. And between Ghost and Force, I would go with Force, or perhaps a 'Presence'. Ghost adds a whole other factor that doesn't need to be there (haunting, slime, etc). On 9/30/08, Tammy Nowotny wrote: > > > Tateru Nino wrote: >> If I had to translate 'agent', I'd probably select 'spirit' - maybe ?? >> ? (Chinese isn't exactly my forte). An invisible force capable of action. >> For primitive, perhaps ??. >> >> > > I am going wayyy out into Cultural-Stereotype land here... but it seems > to me that the Chinese language should be rich in words for ghosts, > spirits, etc. And even concepts like "prim" or "rezz" might have > parallels in Eastern spiritual practices. > > --Tammy > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > From kakurady at gmail.com Wed Oct 1 17:16:05 2008 From: kakurady at gmail.com (Geneko Nemeth) Date: Wed Oct 1 17:16:16 2008 Subject: [sldev] Re: [sl-ux] [i18n][l10n:zh] Viewer Chinese Translation - feedbackwanted? In-Reply-To: <48E40D51.4060101@lindenlab.com> References: <48E2D92E.4030101@gmail.com> <48E40D51.4060101@lindenlab.com> Message-ID: <48E412C5.4010404@gmail.com> Huh? A post earlier? Where... nevermind, found it. Now that's sneaky. :3 I'll subscribe to it then. Kakurady Drakenar (Geneko Nemeth) Rob Lanphier ??: > On 9/30/08 6:58 PM, Geneko Nemeth wrote: > >> In the past year, partly out of being unsatisfied with the existing >> translation (which is inaccurate and outdated), I translated parts of >> the Viewer into Chinese (simplified). >> >> I tried to submit (see http://jira.secondlife.com/browse/VWR-4263 ) >> however, it wasn't accepted. Didn't stop me from continuing to translate >> other parts of the client however. >> >> > > > Hi Geneko, > > There's been a lot that's happened since you last submitted that > translation. As you might guess from my mail earlier today on sldev, I > think this would be a great topic for discussion on the ctprojects list: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/ctproject > > I'm really glad you've continued this work undeterred! > > Rob > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20081001/8368e46a/attachment.htm From poppy at lindenlab.com Wed Oct 1 17:31:26 2008 From: poppy at lindenlab.com (Paul Oppenheim (Poppy Linden)) Date: Wed Oct 1 17:30:51 2008 Subject: [sldev] Several questions regarding "fully localized viewer" In-Reply-To: <48E3F73B.5060909@lindenlab.com> References: <48E3F73B.5060909@lindenlab.com> Message-ID: <48E4165E.2030002@lindenlab.com> +1 https://lists.secondlife.com/cgi-bin/mailman/listinfo/ctproject + poppy Rob Lanphier wrote: > On 10/1/08 3:02 PM, Alissa Sabre wrote: >> M Linden wrote on a recent blog posting >> ( http://blog.secondlife.com/2008/09/29/4-months-at-the-lab/ ): >> >> Experience Localization: ... By the end of the year, the viewer >> will be fully localized for all our major markets. >> >> This sounds great and exciting ... but what does "fully localized" >> mean? >> > > Hi Alissa, > > My understanding is that there's been a lot of work going on both with > working with outside firms on updating our existing viewer translations, > and doing a lot of work to revamp the infrastructure to make it easier > to work with you all on translations. Danica Linden is responsible for > our localization strategy and has more details. > > Rather than pulling in Danica for a more detailed response here, I'd > like to refer you to (previously) well-kept secret, which is the > community translations project (ctproject) mailing list: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/ctproject > > Danica manages the list. There hasn't been much traffic on that mailing > list yet, but this seems like quite an appropriate topic to discuss there. > > Rob > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges From kakurady at gmail.com Wed Oct 1 17:31:49 2008 From: kakurady at gmail.com (Kakurady Drakenar) Date: Wed Oct 1 17:31:55 2008 Subject: [sldev] [i18n][l10n:zh] Viewer Chinese Translation - feedback wanted? In-Reply-To: <48E2EDC7.6080300@weblogsinc.com> References: <48E2D92E.4030101@gmail.com> <48E2DDB0.5070301@mac.com> <48E2E3BD.4000106@gmail.com> <48E2EDC7.6080300@weblogsinc.com> Message-ID: <48E41675.1000002@gmail.com> Meh... nice try. But ??? is a kind of spirit like whiskey is. It's a common type of mistake, really... Kakurady Drakenar (Geneko Nemeth) Tateru Nino ??: > If I had to translate 'agent', I'd probably select 'spirit' - maybe ?? > ? (Chinese isn't exactly my forte). An invisible force capable of action. > For primitive, perhaps ??. > > Kakurady Drakenar wrote: > >> Umm, no. "Atom" is a different word than "element"(we're not talking >> about the chemical type either, mind you). I know that prims in SL is >> meant to be taken as "geometric primitives", but I'm not sure how to >> translate that, so I put it as "elemental pieces". >> >> As for resident, agent and avatar, I do distinguish between resident and >> avatar. It's just "agent" is a tad bit hard to translate. Also, it was >> just a suggestion. >> >> (Last thing, automatic translators can't grip the Chinese language very >> well. Then again...) >> >> Kakurady Drakenar (Geneko Nemeth) >> >> Tammy Nowotny ??: >> >> >>> I don't know any Chinese. but I have two thoughts: >>> >>> You are using the same term for agent, avatar and resident. Those are >>> actually three different concepts in SL. The resident is the human being >>> who pushes the mouse and bangs the keyboard. The agent is the entity >>> which does things in world. The avatar is the visible representation of >>> the agent. >>> >>> Also, you might want to use the Chinese word for "atom" or "element" to >>> translate "prim/primitive." The SL term "primitive" is not based on the >>> primary meaning of the word "primitive." >>> >>> >>> >>> >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/SLDev >> Please read the policies before posting to keep unmoderated posting privileges >> >> >> > > From gareth at litesim.com Wed Oct 1 22:01:50 2008 From: gareth at litesim.com (Gareth Nelson) Date: Wed Oct 1 22:01:52 2008 Subject: [sldev] LLSD base16/base85 support In-Reply-To: <82AEA2E9-C38A-4A4D-B2F8-6E7E1E031BDE@lindenlab.com> References: <48CC282B.9080309@signpostmarv.name> <61dbdd7d0809131601p6251d16bh24d09e849fc8ceff@mail.gmail.com> <82AEA2E9-C38A-4A4D-B2F8-6E7E1E031BDE@lindenlab.com> Message-ID: <61dbdd7d0810012201y7c87216fs2d6fa9ecb7180a65@mail.gmail.com> Something seems rather incorrect here...... On Thu, Oct 2, 2008 at 12:06 AM, Meadhbh S. Hamrick wrote: > this is because Marv updated the wiki to add base85 support, then sent a > message out to this list claiming the llsd implementation does not match the > documentation. It does make me think if some of the wiki articles should be protected if they are to form the standard reference for the time being. Of course, i'm looking forward to the actual RFC :) From secret.argent at gmail.com Thu Oct 2 06:54:27 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Thu Oct 2 06:54:22 2008 Subject: [sldev] LLSD base16/base85 support In-Reply-To: <82AEA2E9-C38A-4A4D-B2F8-6E7E1E031BDE@lindenlab.com> References: <48CC282B.9080309@signpostmarv.name> <61dbdd7d0809131601p6251d16bh24d09e849fc8ceff@mail.gmail.com> <82AEA2E9-C38A-4A4D-B2F8-6E7E1E031BDE@lindenlab.com> Message-ID: <5312B235-D4A0-4F0C-916B-2C95131EF7C8@gmail.com> On 2008-10-01, at 18:06, Meadhbh S. Hamrick wrote: > so i think the discussion went something like...if we're going to > have to modify code, why would we want to modify code to add a 7% > improvement when we could modify code to add an undefined, but > expectedly higher value? Concur. On highly repetitive text I have seen gzip-9 produce 10x improvement. And XML is stupidly repetitive. From me at signpostmarv.name Thu Oct 2 07:46:52 2008 From: me at signpostmarv.name (SignpostMarv Martin) Date: Thu Oct 2 07:46:56 2008 Subject: [sldev] LLSD base16/base85 support In-Reply-To: <82AEA2E9-C38A-4A4D-B2F8-6E7E1E031BDE@lindenlab.com> References: <48CC282B.9080309@signpostmarv.name> <61dbdd7d0809131601p6251d16bh24d09e849fc8ceff@mail.gmail.com> <82AEA2E9-C38A-4A4D-B2F8-6E7E1E031BDE@lindenlab.com> Message-ID: <48E4DEDC.2010002@signpostmarv.name> Umm, I think you'll find I didn't update the wiki to add base85 support, I updated the DTD to reflect the documentation. It specifically states "Parsers may support base16 and base85." Therefore the DTD must support this statement. Meadhbh S. Hamrick wrote: > this is because Marv updated the wiki to add base85 support, then sent > a message out to this list claiming the llsd implementation does not > match the documentation. > > base85 is NOT canonical. > > if you find an implementation that accepts base85, great! more power > to you. but as far as OGP is concerned, we will currently barf on XML > serializations that include base85. in other words... while you are > free to generate messages that include base85 encodings, we are also > free not to honor them. as neither the original LLSD wiki page (before > Marv changed it) or the implementation used base85, it is not > currently considered canonical. > > there's a process for getting things changed in OGP and in our > existing non-OGP implementation. the process involves "consensus and > working code." it does not involve changing the wiki to match a > feature you want, then complaining that specifications and/or > implementation don't match the wiki. > > i believe there was a discussion about base85 and the conclusion was > that it buys you about a 7% savings over base64 which is minimal > compared to the types of savings expected from just using a gzip > transfer encoding. > > so i think the discussion went something like...if we're going to have > to modify code, why would we want to modify code to add a 7% > improvement when we could modify code to add an undefined, but > expectedly higher value? > > -cheers > -m/? > > On Sep 13, 2008, at 4:01 PM, Gareth Nelson wrote: > >> As far as i'm aware, the sample python code and llcommon/llsd.cpp both >> totally lack this support. >> >> On Sat, Sep 13, 2008 at 9:52 PM, SignpostMarv Martin >> > wrote: >>> The current LLSD spec (not the OGP drafts) mentions optional support for >>> base16 & base85 support. >>> >>> Now, some of the peeps in AW Groupies hadn't even heard of base85 till I >>> mentioned it yesterday- do any of LL's current services use either >>> of these >>> optional encodings ? >>> >>> ~ Marv. >>> >>> _______________________________________________ >>> Policies and (un)subscribe information available here: >>> http://wiki.secondlife.com/wiki/SLDev >>> Please read the policies before posting to keep unmoderated posting >>> privileges >>> >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/SLDev >> Please read the policies before posting to keep unmoderated posting >> privileges > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3244 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20081002/bb19082f/smime-0001.bin From missannotoole at yahoo.com Thu Oct 2 07:59:52 2008 From: missannotoole at yahoo.com (Ann Otoole) Date: Thu Oct 2 07:59:55 2008 Subject: [sldev] [IDEA] A new data structure for SL database servers Message-ID: <396644.4221.qm@web59101.mail.re1.yahoo.com> CAIDA has had Walrus out for years: http://www.caida.org/tools/visualization/walrus/ Visualization: http://www.caida.org/tools/visualization/walrus/gallery1/ I seriously doubt Secondlife data can be coerced into an directed graph structure at the moment. Perhaps parts. Nor does a traversed graph structure lend itself to high performance. However a true object model does lend itself well to a graph model and code can be diagnosed for defects rapidly when properly documented in a metadata repository and displayed using tools that can model relationships in a 3D representation. In fact I think it would do wonders for the future of Secondlife if the developers had the time and inclination to come up with a way to render code relationships inside of a Secondlife simulator so they could "fly through" and spot broken relationships and acyclic (recursive) references that lead to software failures. Such a tool would certainly be "eating one's own dog food" and would likely lead to significant improvements over time in code reliability. The problem would be the 15,000 primitive limit in the simulators. Anyway I encourage the Lab's developers to have a look at the rich toolset that CAIDA makes available. Many many gems in that repository. ----- Original Message ---- From: Yuri Pankratov To: sldev@lists.secondlife.com Sent: Wednesday, October 1, 2008 5:23:23 PM Subject: [sldev] [IDEA] A new data structure for SL database servers Hello everyone, I am new to this mailing list so let me introduce myself first. My name is Yuri Pankratov, I am a post-grad student and a research engineer from Russia . I have been a SL resident for quite some time now and while I find SL to be a wonderful idea with great implementation, I have to say that it is facing some scalability problems: with so many concurrent users the database servers are extremely stressed. This causes many unwanted things to happen, like increased lag, inaccessible inventory or inventory loss. I have suffered all these things myself. There is good news, though. It happened so I became a research engineer in an R&D company. One of the company's projects is devoted to the creation of an innovative distributed data structure which would allow to create virtually infinite data repositories. An even better news is that the data structure provides a O(log n) data search algorithm, which means that you can quickly find required data even in a very large data repository. The data structure in its current implementation is intended to store data in XML format. That gave me a thought: "Hey, most SL data is stored in XML form, so maybe our data structure would be just the thing for storing SL data!". I would be really glad if Linden developers would take interest in my idea. I also welcome everyone to express their opinion on the topic. The name of my company is MeraLabs and the name of the data structure is "Metrized Small World". Now, some useful links: My company's website: http://meralabs.com This is an example of how the data structure looks: http://meralabs.com/media/meralabs/images/skeleton_100k_v2.png An article describing the data structue in detail: http://meralabs.com/media/meralabs/publications/files/METRIZED_SMALL_WORLD_PROPERTIES_BASED_DATA_STRUCTURE.pdf The company's press-release which metions the data structure: http://www.24-7pressrelease.com/press-release/meralabs-company-presents-an-innovative-data-storage-technology-63155.php Also you may want to see another our press-release which describes our concept of Cognitive Internet (I think it goes well with the philosophy of SL creators): http://www.24-7pressrelease.com/press-release/meralabs-envisions-that-the-internet-of-the-future-will-be-cognitive-66192.php Best regards, Yuri Pankratov. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20081002/c3c4f899/attachment.htm From ypankrat at meralabs.com Thu Oct 2 08:56:30 2008 From: ypankrat at meralabs.com (Yuri Pankratov) Date: Thu Oct 2 08:57:12 2008 Subject: [sldev] [IDEA] A new data structure for SL database servers (3) Message-ID: <000c01c924a7$7791ec00$c006520a@YURI> > CAIDA has had Walrus out for years Indeed. But my post was not about Walrus or any other CAIDA production at all...it was about the "Metrized Small World" data structure. > I seriously doubt Secondlife data can be coerced into an directed graph > structure at the moment. Perhaps parts. Why do you think it is imposible? Is there some fundamental obstacle that prevents SL data from being stored in XML format??? I'd like to hear your argumentation. > Nor does a traversed graph structure lend itself to high performance. I disargee with you on that part. The data strcuture I am talking about can be as effective as distributed hash tables. And again, you provide no argumentation. ----- Original Message ----- From: Ann Otoole To: Yuri Pankratov ; sldev@lists.secondlife.com Sent: Thursday, October 02, 2008 6:59 PM Subject: Re: [sldev] [IDEA] A new data structure for SL database servers CAIDA has had Walrus out for years: http://www.caida.org/tools/visualization/walrus/ Visualization: http://www.caida.org/tools/visualization/walrus/gallery1/ I seriously doubt Secondlife data can be coerced into an directed graph structure at the moment. Perhaps parts. Nor does a traversed graph structure lend itself to high performance. However a true object model does lend itself well to a graph model and code can be diagnosed for defects rapidly when properly documented in a metadata repository and displayed using tools that can model relationships in a 3D representation. In fact I think it would do wonders for the future of Secondlife if the developers had the time and inclination to come up with a way to render code relationships inside of a Secondlife simulator so they could "fly through" and spot broken relationships and acyclic (recursive) references that lead to software failures. Such a tool would certainly be "eating one's own dog food" and would likely lead to significant improvements over time in code reliability. The problem would be the 15,000 primitive limit in the simulators. Anyway I encourage the Lab's developers to have a look at the rich toolset that CAIDA makes available. Many many gems in that repository. ----- Original Message ---- From: Yuri Pankratov To: sldev@lists.secondlife.com Sent: Wednesday, October 1, 2008 5:23:23 PM Subject: [sldev] [IDEA] A new data structure for SL database servers Hello everyone, I am new to this mailing list so let me introduce myself first. My name is Yuri Pankratov, I am a post-grad student and a research engineer from Russia . I have been a SL resident for quite some time now and while I find SL to be a wonderful idea with great implementation, I have to say that it is facing some scalability problems: with so many concurrent users the database servers are extremely stressed. This causes many unwanted things to happen, like increased lag, inaccessible inventory or inventory loss. I have suffered all these things myself. There is good news, though. It happened so I became a research engineer in an R&D company. One of the company's projects is devoted to the creation of an innovative distributed data structure which would allow to create virtually infinite data repositories. An even better news is that the data structure provides a O(log n) data search algorithm, which means that you can quickly find required data even in a very large data repository. The data structure in its current implementation is intended to store data in XML format. That gave me a thought: "Hey, most SL data is stored in XML form, so maybe our data structure would be just the thing for storing SL data!". I would be really glad if Linden developers would take interest in my idea. I also welcome everyone to express their opinion on the topic. The name of my company is MeraLabs and the name of the data structure is "Metrized Small World". Now, some useful links: My company's website: http://meralabs.com This is an example of how the data structure looks: http://meralabs.com/media/meralabs/images/skeleton_100k_v2.png An article describing the data structue in detail: http://meralabs.com/media/meralabs/publications/files/METRIZED_SMALL_WORLD_PROPERTIES_BASED_DATA_STRUCTURE.pdf The company's press-release which metions the data structure: http://www.24-7pressrelease.com/press-release/meralabs-company-presents-an-innovative-data-storage-technology-63155.php Also you may want to see another our press-release which describes our concept of Cognitive Internet (I think it goes well with the philosophy of SL creators): http://www.24-7pressrelease.com/press-release/meralabs-envisions-that-the-internet-of-the-future-will-be-cognitive-66192.php Best regards, Yuri Pankratov. From kakurady at gmail.com Sun Oct 5 09:51:43 2008 From: kakurady at gmail.com (Kakurady Drakenar) Date: Sun Oct 5 09:51:51 2008 Subject: [sldev] Nvidia 3D Goggles? References: cea888700809172229p4762e549w38bb0fbac67bfbd8@mail.gmail.com Message-ID: <48E8F09F.6010807@gmail.com> I think I would like the "cardboard box" effect for avatars. "Hey look... that guy got impostored". Would be pretty fun! Particles, on the other hand.... Since I don't have such a device, I can't say if this would make the user dizzy or not... Geneko Nemeth (Kakurady Drakenar) From grant at lindenlab.com Mon Oct 6 14:36:05 2008 From: grant at lindenlab.com (Grant Linden) Date: Mon Oct 6 14:36:08 2008 Subject: [sldev] RX Office hours - Update on the viewer Skinning project and general UI discussion Message-ID: <907af5560810061436m4a333bd6yf4be88798123f046@mail.gmail.com> At the next Rx Office Hours - Update on the viewer Skinning project and general UI discussion Thursday October 9th from 3:00-4:00 PM SLT http://slurl.com/secondlife/Beaumont/148/155/46/?title=Linden%20Village For more news about the RX team and to suggest topics for future RX Office Hours please visit our wiki page: https://wiki.secondlife.com/wiki/Resident_Experience The SL-UX Email Discussion List is the ongoing conversation about the Second Life UI and Resident Experience. Residents and Lindens join together to discuss, brain storm and refine the Second Life UI. Join here: https://lists.secondlife.com/cgi-bin/mailman/listinfo/sl-ux -- Steven Grant (Grant Linden) User Experience Designer Linden Lab | Second Life -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20081006/1aa3b611/attachment.htm From ramzi at lindenlab.com Mon Oct 6 19:13:43 2008 From: ramzi at lindenlab.com (Ramzi) Date: Mon Oct 6 19:13:49 2008 Subject: [sldev] Security Update 2008-10-06 to SL Viewers and source code Message-ID: <48EAC5D7.5020503@lindenlab.com> Dear SLDEVelopers, I want to let you know that Linden Lab released a mandatory security update to the official and Release Candidate viewers, to address a potential security issue. Updated source code is available at: http://wiki.secondlife.com/wiki/Source_downloads The full text of the announcement to Second Life Residents is on the Status Page of secondlifegrid.net, and repeated here below for your convenience. Best regards, Ramzi Linden - http://status.secondlifegrid.net/2008/10/06/post275/ Security Update to Second Life viewers: 2008-10-06 Today, we released an important update that improves the security of the Second Life viewer for all Residents. This update eliminates a recently discovered issue, and we're requiring that all Residents download and install it to ensure that everyone remains secure while using Second Life. You will be prompted to download and install the update when you log-in, or you can get it from the Downloads page. More details about the improvements included in this update are available below. ------------- Linden Lab has released a Security Update to the Second Life viewer software today to address a potential security issue. This Security Update includes an additional security patch related to the Security Update issued on 26-Sept-2008. Available for: Second Life Viewer 1.20.15 / 1.20.16 Second Life Release Candidate Viewer 1.21.4 Description: We recently updated the Second Life server and viewers to enhance the communications code. All transfer operations are now restricted to files that the user has expressly chosen, and specific directories that the viewer uses for transferring data. For the safety of all Second Life users, we are releasing this updated viewer to all Residents. Potential vulnerabilities had been identified in those message communications directed at a Second Life viewer over the previous protocol. By taking advantage of this vulnerability, while extremely difficult technically, a malicious user could potentially use the viewer to access files on the victim?s computer. We currently have no evidence of this vulnerability ever being exploited. This Security Update 2008-10-06 is required to continue to log-in to Second Life. By downloading the update, you will upgrade the software on your computer to version 1.20.17: * Second Life Release Viewer 1.20.17 For Residents who use the Release Candidate viewer, you are required to update to RC5, which also includes other latest bug fixes: * Second Life Release Candidate Viewer 1.21 RC5 Earlier versions of Second Life (1.19.1, 1.19, and before) include the serious vulnerabilities and are no longer supported. You will be prompted to upgrade to the latest version on your next login. For any Residents who prefer / have been using earlier versions that do not include WindLight rendering, we have created a page on the Second Life Wiki that explains how to turn all related graphics settings to "Low," effectively turning off WindLight in the current official viewer: https://wiki.secondlife.com/wiki/Turn_off_WindLight_rendering The source code for these new 1.20 and 1.21 RC5 viewers will be made available via the usual open source channels. For discussion about the issue, please visit this thread in the SL Forums: http://forums.secondlife.com/forumdisplay.php?f=353 From robla at lindenlab.com Mon Oct 6 19:24:48 2008 From: robla at lindenlab.com (Rob Lanphier) Date: Mon Oct 6 19:24:53 2008 Subject: [sldev] Security Update 2008-10-06 to SL Viewers and source code - CLARIFICATION In-Reply-To: <48EAC5D7.5020503@lindenlab.com> References: <48EAC5D7.5020503@lindenlab.com> Message-ID: <48EAC870.9090108@lindenlab.com> Clarification on source code access: We're going to delay the general release of the source code until tomorrow. Early access to the source code for this fix are available on an as needed basis to developers of some widely available viewers (contact me for details). General source code access should be provided sometime tomorrow here: http://wiki.secondlife.com/wiki/Source_downloads Sorry for the inconvenience, and thanks for your patience. Rob On 10/06/2008 07:13 PM, Ramzi wrote: > Dear SLDEVelopers, > > I want to let you know that Linden Lab released a mandatory security > update to the official and Release Candidate viewers, to address a > potential security issue. Updated source code is available at: > http://wiki.secondlife.com/wiki/Source_downloads > > The full text of the announcement to Second Life Residents is on the > Status Page of secondlifegrid.net, and repeated here below for your > convenience. > > Best regards, > Ramzi Linden > > > - > http://status.secondlifegrid.net/2008/10/06/post275/ > > Security Update to Second Life viewers: 2008-10-06 > > Today, we released an important update that improves the security of > the Second Life viewer for all Residents. This update eliminates a > recently discovered issue, and we're requiring that all Residents > download and install it to ensure that everyone remains secure while > using Second Life. You will be prompted to download and install the > update when you log-in, or you can get it from the Downloads page. > > More details about the improvements included in this update are > available below. > > ------------- > > Linden Lab has released a Security Update to the Second Life viewer > software today to address a potential security issue. This Security > Update includes an additional security patch related to the Security > Update issued on 26-Sept-2008. > > Available for: > > Second Life Viewer 1.20.15 / 1.20.16 > Second Life Release Candidate Viewer 1.21.4 > > Description: > > We recently updated the Second Life server and viewers to enhance the > communications code. All transfer operations are now restricted to > files that the user has expressly chosen, and specific directories > that the viewer uses for transferring data. For the safety of all > Second Life users, we are releasing this updated viewer to all Residents. > > Potential vulnerabilities had been identified in those message > communications directed at a Second Life viewer over the previous > protocol. By taking advantage of this vulnerability, while extremely > difficult technically, a malicious user could potentially use the > viewer to access files on the victim?s computer. We currently have no > evidence of this vulnerability ever being exploited. > > This Security Update 2008-10-06 is required to continue to log-in to > Second Life. By downloading the update, you will upgrade the software > on your computer to version 1.20.17: > > * Second Life Release Viewer 1.20.17 > > For Residents who use the Release Candidate viewer, you are required > to update to RC5, which also includes other latest bug fixes: > > * Second Life Release Candidate Viewer 1.21 RC5 > > Earlier versions of Second Life (1.19.1, 1.19, and before) include the > serious vulnerabilities and are no longer supported. You will be > prompted to upgrade to the latest version on your next login. > > For any Residents who prefer / have been using earlier versions that > do not include WindLight rendering, we have created a page on the > Second Life Wiki that explains how to turn all related graphics > settings to "Low," effectively turning off WindLight in the current > official viewer: > https://wiki.secondlife.com/wiki/Turn_off_WindLight_rendering > > The source code for these new 1.20 and 1.21 RC5 viewers will be made > available via the usual open source channels. > > For discussion about the issue, please visit this thread in the SL > Forums: http://forums.secondlife.com/forumdisplay.php?f=353 > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges From tom at streamsense.net Mon Oct 6 19:34:56 2008 From: tom at streamsense.net (Thomas Grimshaw) Date: Mon Oct 6 19:35:02 2008 Subject: [sldev] Security Update 2008-10-06 to SL Viewers and source code - CLARIFICATION In-Reply-To: <48EAC870.9090108@lindenlab.com> References: <48EAC5D7.5020503@lindenlab.com> <48EAC870.9090108@lindenlab.com> Message-ID: <48EACAD0.8020507@streamsense.net> What is the security flaw? Is there a jira with a source patch available for those who need a more urgent fix? Tom Rob Lanphier wrote: > Clarification on source code access: We're going to delay the general > release of the source code until tomorrow. Early access to the source > code for this fix are available on an as needed basis to developers of > some widely available viewers (contact me for details). General source > code access should be provided sometime tomorrow here: > http://wiki.secondlife.com/wiki/Source_downloads > > Sorry for the inconvenience, and thanks for your patience. > > Rob From robla at lindenlab.com Mon Oct 6 19:45:21 2008 From: robla at lindenlab.com (Rob Lanphier) Date: Mon Oct 6 19:45:23 2008 Subject: [sldev] Security Update 2008-10-06 to SL Viewers and source code - CLARIFICATION In-Reply-To: <48EACAD0.8020507@streamsense.net> References: <48EAC5D7.5020503@lindenlab.com> <48EAC870.9090108@lindenlab.com> <48EACAD0.8020507@streamsense.net> Message-ID: <48EACD41.9070604@lindenlab.com> As I said, contact me if you have a widely-available viewer that you need to patch. Contact me if you have other circumstances that make it difficult for you to wait until tomorrow. Rob On 10/06/2008 07:34 PM, Thomas Grimshaw wrote: > What is the security flaw? Is there a jira with a source patch > available for those who need a more urgent fix? > > Tom > > Rob Lanphier wrote: >> Clarification on source code access: We're going to delay the general >> release of the source code until tomorrow. Early access to the source >> code for this fix are available on an as needed basis to developers of >> some widely available viewers (contact me for details). General source >> code access should be provided sometime tomorrow here: >> http://wiki.secondlife.com/wiki/Source_downloads >> >> Sorry for the inconvenience, and thanks for your patience. >> >> Rob > From jay_reynolds_freeman at mac.com Mon Oct 6 19:49:03 2008 From: jay_reynolds_freeman at mac.com (Jay Reynolds Freeman) Date: Mon Oct 6 19:49:05 2008 Subject: [sldev] Security Update 2008-10-06 to SL Viewers and source code - CLARIFICATION In-Reply-To: <48EACAD0.8020507@streamsense.net> References: <48EAC5D7.5020503@lindenlab.com> <48EAC870.9090108@lindenlab.com> <48EACAD0.8020507@streamsense.net> Message-ID: <82D4C414-4D97-4AB6-8E1F-0702E074DF57@mac.com> Under the GNU license, do you have a choice? Don't you have to make source available as soon as you release an application? (Not being so much nit-picky as irked: I was working on something in a local client build and am interrupted ...) -- Jay Reynolds Freeman --------------------- Jay_Reynolds_Freeman@mac.com http://web.mac.com/jay_reynolds_freeman (personal web site) From robla at lindenlab.com Mon Oct 6 20:08:48 2008 From: robla at lindenlab.com (Rob Lanphier) Date: Mon Oct 6 20:08:51 2008 Subject: [sldev] Security Update 2008-10-06 to SL Viewers and source code -CLARIFICATION In-Reply-To: <82D4C414-4D97-4AB6-8E1F-0702E074DF57@mac.com> References: <48EAC5D7.5020503@lindenlab.com> <48EAC870.9090108@lindenlab.com><48EACAD0.8020507@streamsense.net> <82D4C414-4D97-4AB6-8E1F-0702E074DF57@mac.com> Message-ID: <48EAD2C0.8020206@lindenlab.com> On 10/06/2008 07:49 PM, Jay Reynolds Freeman wrote: > Under the GNU license, do you have a choice? Don't you have to > make source available as soon as you release an application? Linden Lab is GPL licensors, not GPL licensees, so we're not bound to the terms of the GPL. > (Not being so much nit-picky as irked: I was working on something > in a local client build and am interrupted ...) Sorry for the inconvenience. We should be getting source out tomorrow. Rob From tateru.nino at gmail.com Mon Oct 6 20:22:11 2008 From: tateru.nino at gmail.com (Tateru Nino) Date: Mon Oct 6 20:22:38 2008 Subject: [sldev] Security Update 2008-10-06 to SL Viewers and source code - CLARIFICATION In-Reply-To: <82D4C414-4D97-4AB6-8E1F-0702E074DF57@mac.com> References: <48EAC5D7.5020503@lindenlab.com> <48EAC870.9090108@lindenlab.com> <48EACAD0.8020507@streamsense.net> <82D4C414-4D97-4AB6-8E1F-0702E074DF57@mac.com> Message-ID: <48EAD5E3.1020808@weblogsinc.com> No, they hold copyright on the source code. The rest of us must comply with the GPL as our only rights to access the source code. The Lab obviously does not have that restriction, as they are the source of copyright provenance. Jay Reynolds Freeman wrote: > Under the GNU license, do you have a choice? Don't you have to > make source available as soon as you release an application? > > (Not being so much nit-picky as irked: I was working on something > in a local client build and am interrupted ...) > > -- Jay Reynolds Freeman > --------------------- > Jay_Reynolds_Freeman@mac.com > http://web.mac.com/jay_reynolds_freeman (personal web site) > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > -- Tateru Nino http://www.massively.com/ From tom at streamsense.net Mon Oct 6 22:10:00 2008 From: tom at streamsense.net (Thomas Grimshaw) Date: Mon Oct 6 22:10:15 2008 Subject: [sldev] Security Update 2008-10-06 to SL Viewers and source code - CLARIFICATION In-Reply-To: <48EAD5E3.1020808@weblogsinc.com> References: <48EAC5D7.5020503@lindenlab.com> <48EAC870.9090108@lindenlab.com> <48EACAD0.8020507@streamsense.net> <82D4C414-4D97-4AB6-8E1F-0702E074DF57@mac.com> <48EAD5E3.1020808@weblogsinc.com> Message-ID: <48EAEF28.6040908@streamsense.net> Provided, of course, that the source code being withheld is entirely Linden Lab code.. if the fix involved any third party source then there might be complications. ~T Tateru Nino wrote: > No, they hold copyright on the source code. The rest of us must comply > with the GPL as our only rights to access the source code. The Lab > obviously does not have that restriction, as they are the source of > copyright provenance. > > Jay Reynolds Freeman wrote: > >> Under the GNU license, do you have a choice? Don't you have to >> make source available as soon as you release an application? >> >> (Not being so much nit-picky as irked: I was working on something >> in a local client build and am interrupted ...) >> >> -- Jay Reynolds Freeman >> --------------------- >> Jay_Reynolds_Freeman@mac.com >> http://web.mac.com/jay_reynolds_freeman (personal web site) >> >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/SLDev >> Please read the policies before posting to keep unmoderated posting >> privileges >> >> > > From GordonWendt at gmail.com Mon Oct 6 22:15:27 2008 From: GordonWendt at gmail.com (Gordon Wendt) Date: Mon Oct 6 22:15:31 2008 Subject: [sldev] Security Update 2008-10-06 to SL Viewers and source code - CLARIFICATION In-Reply-To: <48EAC870.9090108@lindenlab.com> References: <48EAC5D7.5020503@lindenlab.com> <48EAC870.9090108@lindenlab.com> Message-ID: <493033a70810062215w30224554ic9e8bc36d8df18d7@mail.gmail.com> So this is essentially a huge fuck you to all the third party viewer makers and users since while I'd guess the vast majority of third party viewers are using the old code solely for the old UI and graphics if nothing else you have essentially told them don't bother because with one or two days notice all your work is worthless and we're going to push this out on you whether you like it or not. I won't be surprised and won't hold any blame against them if some of the third party viewer makers give up if your going to treat them like this. This is unacceptable behavior from LL and further proof of an unacceptable attitude towards it's customer base. Some of you are going to ask who am I to say this? I am a loyal user of SL, I have overall been a defender of SL and LL time and time again but LL still does stupid stuff like this over and over again to it's customers. Rob, Since you want this list to be constructive I will give some constructive suggestions. Listen to the third party client designers, they say they hate windlight or new UI changes ok fine roll out the changes but don't screw them over. I realize it takes extra work to make multiple patches for multiple versions so pick maybe two or at most three versions, the release and two backdated. Give the release your full attention however when it comes to huge fixes like this that can't be optional put in the extra work and make a compatible patch for the latest 1.9 series viewer. I guarantee that the extra work will pay itself back in the goodwill you will get not only from the creators of third party viewers but from the users who use them as well. I believe it would be impossible for to get solid numbers on how many people use third party vs the main viewer (although LL may very well have them) however I strongly believe that they are numerous and grow each time LL decides to turn their UI a different color. My immediate suggestion would be to roll this out on time however at the same time give a short timeframe until when you'll have a patch out for the 1.9 series and stick to that timeline. Because of the extra testing involved I understand that it would take awhile but with the promise of a compatible patch I'm sure that many people would be willing to wait and use the LL viewer temporarily until it came out even if that was a month from now. Otherwise you face killing your open source initiative by crapping on third party designers and users one too many times. Note: My language comes out as being unsophisticated and harsh in the above and probably breaks a few rules however despite my intentions to go over and edit the swears out however after finishing it I have realized that it would take away the honesty I am attempting to convey here and if that gets be modbitted so be it if it makes a difference... and that's not just trying to be dramatic if it makes a difference it really is worth whatever fate Rob has in store for people who curse on the mailing list. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20081007/ac41c754/attachment.htm From chaosstar at gmail.com Tue Oct 7 00:50:43 2008 From: chaosstar at gmail.com (Ambrosia) Date: Tue Oct 7 00:50:47 2008 Subject: [sldev] Security Update 2008-10-06 to SL Viewers and source code - CLARIFICATION In-Reply-To: <493033a70810062215w30224554ic9e8bc36d8df18d7@mail.gmail.com> References: <48EAC5D7.5020503@lindenlab.com> <48EAC870.9090108@lindenlab.com> <493033a70810062215w30224554ic9e8bc36d8df18d7@mail.gmail.com> Message-ID: <9bb32d430810070050q4651f2a4ub8a0174a7f6af3fa@mail.gmail.com> Um, Gordon. Rob said 3rd party viewer creators can contact him and ask for the source code in advance. Which will be released to the public tomorrow, so either way tomorrow 3rd party coders can patch the fix into the most ancient viewers there are. While I understand the frustration about no immediate availability of the fix, this hardly makes any work 'worthless', and what you get is a 24 hour delay -if your request does not get approved-. Seriously, take a breather here. it's not like they're doing the delay just to laugh at your face. They're doing it so the majority of SL users is potentially protected before the source (and thus an exact way to put together attack code) gets released. And, as he said, if you maintain a 3rd party viewer, you can apply to get it earlier. On Tue, Oct 7, 2008 at 07:15, Gordon Wendt wrote: > So this is essentially a huge fuck you to all the third party viewer makers > and users since while I'd guess the vast majority of third party viewers are > using the old code solely for the old UI and graphics if nothing else you > have essentially told them don't bother because with one or two days notice > all your work is worthless and we're going to push this out on you whether > you like it or not. I won't be surprised and won't hold any blame against > them if some of the third party viewer makers give up if your going to treat > them like this. This is unacceptable behavior from LL and further proof of > an unacceptable attitude towards it's customer base. Some of you are going > to ask who am I to say this? I am a loyal user of SL, I have overall been a > defender of SL and LL time and time again but LL still does stupid stuff > like this over and over again to it's customers. > > Rob, Since you want this list to be constructive I will give some > constructive suggestions. Listen to the third party client designers, they > say they hate windlight or new UI changes ok fine roll out the changes but > don't screw them over. I realize it takes extra work to make multiple > patches for multiple versions so pick maybe two or at most three versions, > the release and two backdated. Give the release your full attention however > when it comes to huge fixes like this that can't be optional put in the > extra work and make a compatible patch for the latest 1.9 series viewer. I > guarantee that the extra work will pay itself back in the goodwill you will > get not only from the creators of third party viewers but from the users who > use them as well. I believe it would be impossible for to get solid numbers > on how many people use third party vs the main viewer (although LL may very > well have them) however I strongly believe that they are numerous and grow > each time LL decides to turn their UI a different color. My immediate > suggestion would be to roll this out on time however at the same time give a > short timeframe until when you'll have a patch out for the 1.9 series and > stick to that timeline. Because of the extra testing involved I understand > that it would take awhile but with the promise of a compatible patch I'm > sure that many people would be willing to wait and use the LL viewer > temporarily until it came out even if that was a month from now. Otherwise > you face killing your open source initiative by crapping on third party > designers and users one too many times. > > > Note: My language comes out as being unsophisticated and harsh in the above > and probably breaks a few rules however despite my intentions to go over and > edit the swears out however after finishing it I have realized that it would > take away the honesty I am attempting to convey here and if that gets be > modbitted so be it if it makes a difference... and that's not just trying to > be dramatic if it makes a difference it really is worth whatever fate Rob > has in store for people who curse on the mailing list. > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > From Anders at Arnholm.se Tue Oct 7 06:44:07 2008 From: Anders at Arnholm.se (Anders Arnholm) Date: Tue Oct 7 06:44:53 2008 Subject: [sldev] Security Update 2008-10-06 to SL Viewers and source code - CLARIFICATION In-Reply-To: <9bb32d430810070050q4651f2a4ub8a0174a7f6af3fa@mail.gmail.com> References: <48EAC5D7.5020503@lindenlab.com> <48EAC870.9090108@lindenlab.com> <493033a70810062215w30224554ic9e8bc36d8df18d7@mail.gmail.com> <9bb32d430810070050q4651f2a4ub8a0174a7f6af3fa@mail.gmail.com> Message-ID: <48EB67A7.8070708@Arnholm.se> Ambrosia skrev: > Um, Gordon. > > Rob said 3rd party viewer creators can contact him and ask for the > source code in advance. > > Which will be released to the public tomorrow, so either way tomorrow > 3rd party coders can patch the fix into the most ancient viewers there > are. > > While I understand the frustration about no immediate availability of > the fix, this hardly makes any work 'worthless', and what you get is a > 24 hour delay -if your request does not get approved-. > > Seriously, take a breather here. it's not like they're doing the delay > just to laugh at your face. They're doing it so the majority of SL > users is potentially protected before the source (and thus an exact > way to put together attack code) gets released. And, as he said, if > you maintain a 3rd party viewer, you can apply to get it earlier. > To be honest the release note and the vunurable code is what is needed to make a attack code, the patch for fix it not ac much. It's pretty clear how to make the code as i said in the forum about this relase, the holding the code back only makes it take longer till all viewers are updated. And yes please code now so i can update my Nicholaz build for 1.19. Maybe I still have time to fix this before sunday. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From Anders at Arnholm.se Tue Oct 7 08:24:17 2008 From: Anders at Arnholm.se (Anders Arnholm) Date: Tue Oct 7 08:25:01 2008 Subject: [sldev] Security Update 2008-10-06 to SL Viewers and source code - CLARIFICATION In-Reply-To: <48EB67A7.8070708@Arnholm.se> References: <48EAC5D7.5020503@lindenlab.com> <48EAC870.9090108@lindenlab.com> <493033a70810062215w30224554ic9e8bc36d8df18d7@mail.gmail.com> <9bb32d430810070050q4651f2a4ub8a0174a7f6af3fa@mail.gmail.com> <48EB67A7.8070708@Arnholm.se> Message-ID: <48EB7F21.5090104@Arnholm.se> Anders Arnholm skrev: > To be honest the release note and the vunurable code is what is needed > to make a attack code, the patch for fix it not ac much. It's pretty > clear how to make the code as i said in the forum about this relase, > the holding the code back only makes it take longer till all viewers > are updated. And yes please code now so i can update my Nicholaz build > for 1.19. > > Maybe I still have time to fix this before sunday. Got patches from Rob now.. Compileing and in the strange situation that I can't release this when the biold is ready and done as Rob asked me not to spead the code, and GPL prevents med from spreading the binary without the code. I just hope then have the code out before i get home and test it in a few hours. But my first analys was correct, the patch don't help in specifiyng the error or how to make a exploit code thats all that in the release note. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From tateru.nino at gmail.com Tue Oct 7 09:10:06 2008 From: tateru.nino at gmail.com (Tateru Nino) Date: Tue Oct 7 09:10:35 2008 Subject: [sldev] Security Update 2008-10-06 to SL Viewers and source code - CLARIFICATION In-Reply-To: <48EB7F21.5090104@Arnholm.se> References: <48EAC5D7.5020503@lindenlab.com> <48EAC870.9090108@lindenlab.com> <493033a70810062215w30224554ic9e8bc36d8df18d7@mail.gmail.com> <9bb32d430810070050q4651f2a4ub8a0174a7f6af3fa@mail.gmail.com> <48EB67A7.8070708@Arnholm.se> <48EB7F21.5090104@Arnholm.se> Message-ID: <48EB89DE.5090001@gmail.com> Anders Arnholm wrote: > Anders Arnholm skrev: >> To be honest the release note and the vunurable code is what is >> needed to make a attack code, the patch for fix it not ac much. It's >> pretty clear how to make the code as i said in the forum about this >> relase, the holding the code back only makes it take longer till all >> viewers are updated. And yes please code now so i can update my >> Nicholaz build for 1.19. >> >> Maybe I still have time to fix this before sunday. > Got patches from Rob now.. Compileing and in the strange situation > that I can't release this when the biold is ready and done as Rob > asked me not to spead the code, and GPL prevents med from spreading > the binary without the code. I just hope then have the code out before > i get home and test it in a few hours. > I think the intention was for the binaries to be redistributable, as a special exception - though the source availability would obviously be delayed a day or so. A quick email should sort that out for sure, though. From sldev at free.fr Tue Oct 7 09:35:59 2008 From: sldev at free.fr (Henri Beauchamp) Date: Tue Oct 7 09:36:08 2008 Subject: [sldev] Security Update 2008-10-06 to SL Viewers and source code - CLARIFICATION In-Reply-To: <48EAC870.9090108@lindenlab.com> References: <48EAC5D7.5020503@lindenlab.com> <48EAC870.9090108@lindenlab.com> Message-ID: <20081007183559.72d10993.sldev@free.fr> On Mon, 06 Oct 2008 19:24:48 -0700, Rob Lanphier wrote: > Clarification on source code access: We're going to delay the general > release of the source code until tomorrow. Early access to the source > code for this fix are available on an as needed basis to developers of > some widely available viewers (contact me for details). Rob provided me with the sources (thanks again, Rob !), so I could update the Cool SL Viewer (http://sldev.free.fr/) with two new releases (for Linux only for now. Windoze and Mac builds will follow real soon): v1.20.17.0 CoolRelease 1 v1.19.0.5 CoolRelease 31 (yes, it was possible and easy to port the patch to v1.19.0.5). Yet the sources and patches will not be published before LL publishes their own sources. Henri. From monkowsk at watson.ibm.com Tue Oct 7 09:47:04 2008 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Tue Oct 7 09:49:18 2008 Subject: [sldev] Security Update 2008-10-06 to SL Viewers and source code In-Reply-To: <48EAC5D7.5020503@lindenlab.com> References: <48EAC5D7.5020503@lindenlab.com> Message-ID: <48EB9288.5040805@watson.ibm.com> Ramzi wrote: > Earlier versions of Second Life (1.19.1, 1.19, and before) include the > serious vulnerabilities and are no longer supported. You will be > prompted to upgrade to the latest version on your next login. I hope the puppeteering branch will still be supported. Will someone at Linden add the patch to that branch? Mike From soft at lindenlab.com Tue Oct 7 10:07:07 2008 From: soft at lindenlab.com (Soft) Date: Tue Oct 7 10:07:11 2008 Subject: [sldev] Security Update 2008-10-06 to SL Viewers and source code In-Reply-To: <48EB9288.5040805@watson.ibm.com> References: <48EAC5D7.5020503@lindenlab.com> <48EB9288.5040805@watson.ibm.com> Message-ID: On Tue, Oct 7, 2008 at 11:47 AM, Mike Monkowski wrote: > Ramzi wrote: >> >> Earlier versions of Second Life (1.19.1, 1.19, and before) include the >> serious vulnerabilities and are no longer supported. You will be prompted to >> upgrade to the latest version on your next login. > > I hope the puppeteering branch will still be supported. Will someone at > Linden add the patch to that branch? The puppeteering branch is frozen. There was an announcement that it would be unsupported when it dropped, which we should probably put somewhere prominent in that source tree. I would suggest doing a diff against the base and newer revision and applying that to a live branch if you want to use it as a production viewer. There are likely other security updates that never made that branch. From soft at lindenlab.com Tue Oct 7 10:22:56 2008 From: soft at lindenlab.com (Soft) Date: Tue Oct 7 10:23:06 2008 Subject: [sldev] Security Update 2008-10-06 to SL Viewers and sourcecode - CLARIFICATION In-Reply-To: <20081007183559.72d10993.sldev@free.fr> References: <48EAC5D7.5020503@lindenlab.com> <48EAC870.9090108@lindenlab.com> <20081007183559.72d10993.sldev@free.fr> Message-ID: On Tue, Oct 7, 2008 at 11:35 AM, Henri Beauchamp wrote: > On Mon, 06 Oct 2008 19:24:48 -0700, Rob Lanphier wrote: > >> Clarification on source code access: We're going to delay the general >> release of the source code until tomorrow. Early access to the source >> code for this fix are available on an as needed basis to developers of >> some widely available viewers (contact me for details). > > Rob provided me with the sources (thanks again, Rob !), so I could update > the Cool SL Viewer (http://sldev.free.fr/) with two new releases (for > Linux only for now. Windoze and Mac builds will follow real soon): > > v1.20.17.0 CoolRelease 1 > v1.19.0.5 CoolRelease 31 (yes, it was possible and easy to port the patch > to v1.19.0.5). > > Yet the sources and patches will not be published before LL publishes > their own sources. Thank you, Henri. It's okay to publish now. http://svn.secondlife.com/trac/linden/changeset/1283 From monkowsk at watson.ibm.com Tue Oct 7 11:35:34 2008 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Tue Oct 7 11:36:00 2008 Subject: [sldev] Security Update 2008-10-06 to SL Viewers and source code In-Reply-To: References: <48EAC5D7.5020503@lindenlab.com> <48EB9288.5040805@watson.ibm.com> Message-ID: <48EBABF6.6030702@watson.ibm.com> Soft, That was my plan, but I had hoped to be able to run the branch as is to verify that my patch was correct. My reading of the original notice on this security update was that even viewers that specified -channel would not work. Is that correct? Mike Soft wrote: > On Tue, Oct 7, 2008 at 11:47 AM, Mike Monkowski wrote: > >>Ramzi wrote: >> >>>Earlier versions of Second Life (1.19.1, 1.19, and before) include the >>>serious vulnerabilities and are no longer supported. You will be prompted to >>>upgrade to the latest version on your next login. >> >>I hope the puppeteering branch will still be supported. Will someone at >>Linden add the patch to that branch? > > > The puppeteering branch is frozen. There was an announcement that it > would be unsupported when it dropped, which we should probably put > somewhere prominent in that source tree. > > I would suggest doing a diff against the base and newer revision and > applying that to a live branch if you want to use it as a production > viewer. There are likely other security updates that never made that > branch. > From tom at streamsense.net Tue Oct 7 11:40:13 2008 From: tom at streamsense.net (Thomas Grimshaw) Date: Tue Oct 7 11:40:25 2008 Subject: [sldev] Compile error: 1.19.1(4) VC8 Message-ID: <48EBAD0D.9030304@streamsense.net> Hi all, I'm experiencing an issue with llutf16string whilst copmiling the 1.19.1(4) release viewer, can anybody shed any light on this? The typedef is in place and doesn't seem to throw an error.. http://pastebin.com/m2250ab61 Thanks Tom From AndromedaQuonset at comcast.net Tue Oct 7 12:15:25 2008 From: AndromedaQuonset at comcast.net (Andromeda Quonset) Date: Tue Oct 7 12:15:48 2008 Subject: [sldev] Compile error: 1.19.1(4) VC8 In-Reply-To: <48EBAD0D.9030304@streamsense.net> References: <48EBAD0D.9030304@streamsense.net> Message-ID: <20081007191546.25DCA41AF40@stupor.lindenlab.com> Tom, I wish I could help you. I have also tried to compile 1.19.1(4) release viewer. I am down to 10 errors remaining, and it includes the same llutf16string issue that you have. I have posted my compile output in this list, in a message dated Sept 13, 2008. Nobody responded, and unless something changes, I have pretty much concluded that the 1.19.1(4) release viewer is not compile-able. Regards, Andro At 12:40 PM 10/7/2008, you wrote: >Hi all, > >I'm experiencing an issue with llutf16string whilst copmiling the >1.19.1(4) release viewer, can anybody shed any light on this? The >typedef is in place and doesn't seem to throw an error.. > >http://pastebin.com/m2250ab61 > >Thanks > >Tom From jay_reynolds_freeman at mac.com Tue Oct 7 13:33:55 2008 From: jay_reynolds_freeman at mac.com (Jay Reynolds Freeman) Date: Tue Oct 7 13:34:26 2008 Subject: [sldev] Building 1.20.17, no "develop.py" ... ?? In-Reply-To: References: <48EAC5D7.5020503@lindenlab.com> <48EAC870.9090108@lindenlab.com> <20081007183559.72d10993.sldev@free.fr> Message-ID: I am trying to build the 1.20.17 viewer on a fairly garden-variety Macintosh / Leopard / Xcode installation, and am following the instructions on the Wiki for CMake-based builds. All goes unremarkably till I get to: "1) Go into the linden/indra directory, and run develop.py" ... and there isn't any "develop.py" to be found. A "find . -name *py" in my linden directory turns up lots of python files, but no "develop.py" anywhere to be seen. A find for develop* turns up nothing at all. I have built several previous versions of the viewer before, with no more than minor problems, but none of the 1.20 series -- the most recent for me is 1.19.4. My "linden" directory is brand new and contains nothing but what the download-and-build instructions put there. Any hints? And thank you ... -- Jay Reynolds Freeman --------------------- Jay_Reynolds_Freeman@mac.com http://web.mac.com/jay_reynolds_freeman (personal web site) From sldev at free.fr Tue Oct 7 13:54:44 2008 From: sldev at free.fr (Henri Beauchamp) Date: Tue Oct 7 13:54:48 2008 Subject: [sldev] Security Update 2008-10-06 to SL Viewers and source code In-Reply-To: <48EBABF6.6030702@watson.ibm.com> References: <48EAC5D7.5020503@lindenlab.com> <48EB9288.5040805@watson.ibm.com> <48EBABF6.6030702@watson.ibm.com> Message-ID: <20081007225444.255ad365.sldev@free.fr> On Tue, 07 Oct 2008 14:35:34 -0400, Mike Monkowski wrote: > Soft, > That was my plan, but I had hoped to be able to run the branch as > is to verify that my patch was correct. > My reading of the original notice on this security update was that > even viewers that specified -channel would not work. Is that correct? No. LL never blocked third party viewers as long as they are using a -channel (or --channel for v1.2x viewers) name which is different from theirs. When a different channel name is used, no check is currently done on the viewer version (in particular, there is no forced update). The only thing that could prevent you from running an old viewer would be changes in the messaging protocol with the servers... For example, newer server versions could at some point blacklist a given protocol for a given message, or old messages could become deprecated and no more usable. But currently, you should be able to run any viewer from v1.18 onwards. AFAIK, v1.17 and before are deprecated and unusable with current servers. Henri. From tom at streamsense.net Tue Oct 7 13:57:06 2008 From: tom at streamsense.net (Thomas Grimshaw) Date: Tue Oct 7 13:57:14 2008 Subject: [sldev] Building 1.20.17, no "develop.py" ... ?? In-Reply-To: References: <48EAC5D7.5020503@lindenlab.com> <48EAC870.9090108@lindenlab.com> <20081007183559.72d10993.sldev@free.fr> Message-ID: <48EBCD22.2010202@streamsense.net> the .17 release is just a minor patch, i'm pretty sure you could use the develop.py from the .16 release ~T Jay Reynolds Freeman wrote: > I am trying to build the 1.20.17 viewer on a fairly garden-variety > Macintosh / Leopard / Xcode installation, and am following the > instructions > on the Wiki for CMake-based builds. All goes unremarkably till I get to: > > "1) Go into the linden/indra directory, and run develop.py" > > ... and there isn't any "develop.py" to be found. > > A "find . -name *py" in my linden directory turns up lots of > python files, but no "develop.py" anywhere to be seen. A find for > develop* turns up nothing at all. > > I have built several previous versions of the viewer before, with > no more than minor problems, but none of the 1.20 series -- the most > recent for me is 1.19.4. My "linden" directory is brand new and > contains nothing but what the download-and-build instructions put there. > > Any hints? And thank you ... > > -- Jay Reynolds Freeman > --------------------- > Jay_Reynolds_Freeman@mac.com > http://web.mac.com/jay_reynolds_freeman (personal web site) > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges From gigstaggart at gmail.com Tue Oct 7 14:14:46 2008 From: gigstaggart at gmail.com (Jason Giglio) Date: Tue Oct 7 14:14:51 2008 Subject: [sldev] Security Update 2008-10-06 to SL Viewers and source code - CLARIFICATION In-Reply-To: <48EB89DE.5090001@gmail.com> References: <48EAC5D7.5020503@lindenlab.com> <48EAC870.9090108@lindenlab.com> <493033a70810062215w30224554ic9e8bc36d8df18d7@mail.gmail.com> <9bb32d430810070050q4651f2a4ub8a0174a7f6af3fa@mail.gmail.com> <48EB67A7.8070708@Arnholm.se> <48EB7F21.5090104@Arnholm.se> <48EB89DE.5090001@gmail.com> Message-ID: <48EBD146.5050807@gmail.com> Tateru Nino wrote: > I think the intention was for the binaries to be redistributable, as a > special exception - though the source availability would obviously be > delayed a day or so. A quick email should sort that out for sure, though. If Linden Lab is giving people permission to violate the GPL by releasing binaries without source, then that is more of a big deal than the delay. Many contributors would be unhappy with that situation. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3266 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20081007/83f6ada5/smime.bin From sldev at free.fr Tue Oct 7 14:18:23 2008 From: sldev at free.fr (Henri Beauchamp) Date: Tue Oct 7 14:18:27 2008 Subject: [sldev] Security Update 2008-10-06 to SL Viewers and sourcecode - CLARIFICATION In-Reply-To: References: <48EAC5D7.5020503@lindenlab.com> <48EAC870.9090108@lindenlab.com> <20081007183559.72d10993.sldev@free.fr> Message-ID: <20081007231823.31bed5e4.sldev@free.fr> On Tue, 7 Oct 2008 12:22:56 -0500, Soft wrote: > On Tue, Oct 7, 2008 at 11:35 AM, Henri Beauchamp wrote: > > .../... > > Yet the sources and patches will not be published before LL publishes > > their own sources. > > Thank you, Henri. It's okay to publish now. > > http://svn.secondlife.com/trac/linden/changeset/1283 Ok, links to sources and patch published. The patch for v1.19.0.5 might be of interest to others, so here is the direct link: http://sldev.free.fr/patches/11905/slviewer-0-v11905-FileAccessSecurity.patch.bz2 Henri. From gigstaggart at gmail.com Tue Oct 7 14:30:43 2008 From: gigstaggart at gmail.com (Jason Giglio) Date: Tue Oct 7 14:30:48 2008 Subject: [sldev] Security Update 2008-10-06 to SL Viewers and sourcecode - CLARIFICATION In-Reply-To: <20081007231823.31bed5e4.sldev@free.fr> References: <48EAC5D7.5020503@lindenlab.com> <48EAC870.9090108@lindenlab.com> <20081007183559.72d10993.sldev@free.fr> <20081007231823.31bed5e4.sldev@free.fr> Message-ID: <48EBD503.5030105@gmail.com> Henri Beauchamp wrote: > Ok, links to sources and patch published. The patch for v1.19.0.5 might > be of interest to others, so here is the direct link: > http://sldev.free.fr/patches/11905/slviewer-0-v11905-FileAccessSecurity.patch.bz2 Thank you for making patches out of these important updates. It is much appreciated. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3266 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20081007/5d2d50cb/smime.bin From robla at lindenlab.com Tue Oct 7 14:52:19 2008 From: robla at lindenlab.com (Rob Lanphier) Date: Tue Oct 7 14:52:25 2008 Subject: [sldev] Building 1.20.17, no "develop.py" ... ?? In-Reply-To: References: <48EAC5D7.5020503@lindenlab.com> <48EAC870.9090108@lindenlab.com><20081007183559.72d10993.sldev@free.fr> Message-ID: <48EBDA13.3030807@lindenlab.com> Hi Jay, The 1.20 branch predates the incorporation of CMake, so instructions that reference ./develop.py don't apply. Looks like the Mac build instructions didn't previously reflect this, so I just edited them to make them (hopefully) more accurate: https://wiki.secondlife.com/wiki/Compiling_the_viewer_(Mac_OS_X) Rob On 10/7/08 1:33 PM, Jay Reynolds Freeman wrote: > I am trying to build the 1.20.17 viewer on a fairly garden-variety > Macintosh / Leopard / Xcode installation, and am following the > instructions > on the Wiki for CMake-based builds. All goes unremarkably till I get to: > > "1) Go into the linden/indra directory, and run develop.py" > > ... and there isn't any "develop.py" to be found. > > A "find . -name *py" in my linden directory turns up lots of > python files, but no "develop.py" anywhere to be seen. A find for > develop* turns up nothing at all. > > I have built several previous versions of the viewer before, with > no more than minor problems, but none of the 1.20 series -- the most > recent for me is 1.19.4. My "linden" directory is brand new and > contains nothing but what the download-and-build instructions put there. > > Any hints? And thank you ... > > -- Jay Reynolds Freeman > --------------------- > Jay_Reynolds_Freeman@mac.com > http://web.mac.com/jay_reynolds_freeman (personal web site) > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges From jay_reynolds_freeman at mac.com Tue Oct 7 15:08:16 2008 From: jay_reynolds_freeman at mac.com (Jay Reynolds Freeman) Date: Tue Oct 7 15:08:19 2008 Subject: [sldev] Building 1.20.17, no "develop.py" ... ?? In-Reply-To: <48EBDA13.3030807@lindenlab.com> References: <48EAC5D7.5020503@lindenlab.com> <48EAC870.9090108@lindenlab.com> <20081007183559.72d10993.sldev@free.fr> <48EBDA13.3030807@lindenlab.com> Message-ID: <76FFF35F-158F-4E6B-AC52-7D2B78169647@mac.com> Thanks to Rob, that was indeed the problem, and thanks for updating the build instructions, they are now quite clear. -- Jay Reynolds Freeman --------------------- Jay_Reynolds_Freeman@mac.com http://web.mac.com/jay_reynolds_freeman (personal web site) On Oct 7, 2008, at 2:52 PM, Rob Lanphier wrote: Hi Jay, The 1.20 branch predates the incorporation of CMake, so instructions that reference ./develop.py don't apply. Looks like the Mac build instructions didn't previously reflect this, so I just edited them to make them (hopefully) more accurate: https://wiki.secondlife.com/wiki/Compiling_the_viewer_(Mac_OS_X) Rob On 10/7/08 1:33 PM, Jay Reynolds Freeman wrote: > I am trying to build the 1.20.17 viewer on a fairly garden-variety > Macintosh / Leopard / Xcode installation, and am following the > instructions > on the Wiki for CMake-based builds. All goes unremarkably till I > get to: > > "1) Go into the linden/indra directory, and run develop.py" > > ... and there isn't any "develop.py" to be found. > > A "find . -name *py" in my linden directory turns up lots of > python files, but no "develop.py" anywhere to be seen. A find for > develop* turns up nothing at all. > > I have built several previous versions of the viewer before, with > no more than minor problems, but none of the 1.20 series -- the most > recent for me is 1.19.4. My "linden" directory is brand new and > contains nothing but what the download-and-build instructions put > there. > > Any hints? And thank you ... > > -- Jay Reynolds Freeman > --------------------- > Jay_Reynolds_Freeman@mac.com > http://web.mac.com/jay_reynolds_freeman (personal web site) > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges From latifer at streamgrid.net Tue Oct 7 20:53:01 2008 From: latifer at streamgrid.net (Latif Khalifa) Date: Tue Oct 7 20:53:05 2008 Subject: [sldev] Security Update 2008-10-06 to SL Viewers and sourcecode - CLARIFICATION In-Reply-To: <20081007231823.31bed5e4.sldev@free.fr> References: <48EAC5D7.5020503@lindenlab.com> <48EAC870.9090108@lindenlab.com> <20081007183559.72d10993.sldev@free.fr> <20081007231823.31bed5e4.sldev@free.fr> Message-ID: <5ebce2ec0810072053i2466db78v6f93c7f1c560e63b@mail.gmail.com> On Tue, Oct 7, 2008 at 11:18 PM, Henri Beauchamp wrote: > On Tue, 7 Oct 2008 12:22:56 -0500, Soft wrote: > >> On Tue, Oct 7, 2008 at 11:35 AM, Henri Beauchamp wrote: >> > .../... >> > Yet the sources and patches will not be published before LL publishes >> > their own sources. >> >> Thank you, Henri. It's okay to publish now. >> >> http://svn.secondlife.com/trac/linden/changeset/1283 > > Ok, links to sources and patch published. The patch for v1.19.0.5 might > be of interest to others, so here is the direct link: > http://sldev.free.fr/patches/11905/slviewer-0-v11905-FileAccessSecurity.patch.bz2 Has support UDPBlackListed flag from message template been added to that patch set? Its very important to include it too. I guess the patch is: http://svn.secondlife.com/trac/linden/changeset/1202 -- L From LilyfloppyDiamond at secondlife.com Wed Oct 8 05:09:00 2008 From: LilyfloppyDiamond at secondlife.com (Robbie Lockett) Date: Wed Oct 8 00:10:12 2008 Subject: [sldev] Famous branded timepieces for a song Message-ID: 41de01c92914$e536d330$0301a8c0@muratttt4595da Why pay hundreds of thousands for the original when you can pick up a mirror copy for a mere fraction of the price? For just $49 ~ $249, you can purchase an IDENTICAL timepiece to the original. http://fendgain.com/ From tinacloud at gmx.de Wed Oct 8 01:26:29 2008 From: tinacloud at gmx.de (tinacloud@gmx.de) Date: Wed Oct 8 01:26:33 2008 Subject: [sldev] [Patch] VWR-7896 - Landmark pushpins do not change color after visiting them. Message-ID: <20081008082629.130710@gmx.net> Hi Developers! I sent in a patch to fix the "Landmark pushpins do not change color after visiting them" problem. There were a few things in the viewer that prevented the correct behavior from happening. The patch fixes it and you will now see all (subsequently) visited landmarks correctly marked as "visited". The status change is not visible in real time, you need to open a new inventory window after visiting to see the change without logging out. http://jira.secondlife.com/secure/attachment/19319/landmark_visited.diff I didn't manage to get the real time update working yet, the inventory code is hard to follor and littered with inheritances and (seemingly) dead code. I'll try to come up with a solution for this, but for the time being the patch at least repairs the broken landmark behavior. Please review and comment! Zi! -- Psssst! Schon vom neuen GMX MultiMessenger geh?rt? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger From Anders at Arnholm.se Wed Oct 8 01:51:08 2008 From: Anders at Arnholm.se (Anders Arnholm) Date: Wed Oct 8 01:51:51 2008 Subject: [sldev] Compile error: 1.19.1(4) VC8 In-Reply-To: <20081007191546.25DCA41AF40@stupor.lindenlab.com> References: <48EBAD0D.9030304@streamsense.net> <20081007191546.25DCA41AF40@stupor.lindenlab.com> Message-ID: <48EC747C.2010906@Arnholm.se> Andromeda Quonset skrev: > Tom, > > I wish I could help you. I have also tried to compile 1.19.1(4) > release viewer. > I am down to 10 errors remaining, and it includes the same > llutf16string issue that you have. > I have posted my compile output in this list, in a message dated Sept > 13, 2008. Nobody responded, and unless something changes, I have > pretty much concluded that the 1.19.1(4) release viewer is not > compile-able. Hmmmmmmm I compiled that yesterday but on linux, the file in questions however differs at thet part between windows and Linux. My guess form the error is that a version of the compiler that doesn't support that code is being used. If i recall correctly 1.19.4 was for a old version of Visual studio. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From gareth at litesim.com Wed Oct 8 03:38:47 2008 From: gareth at litesim.com (Gareth Nelson) Date: Wed Oct 8 03:38:50 2008 Subject: [sldev] SDL on win32 Message-ID: <61dbdd7d0810080338r185420e8k4aad49a4bc961b5f@mail.gmail.com> I've been pondering why this is not used........ SDL is designed for being cross-platform, yet the viewer only uses it on linux. If SDL was used on all platforms instead then it would make certain tasks a lot simpler (say for example that firefox plugin i've been working on). So, before I waste time messing around with this - is there any reason SDL is not already used for the other platforms? From tinacloud at gmx.de Wed Oct 8 03:47:17 2008 From: tinacloud at gmx.de (Bettina Marks) Date: Wed Oct 8 03:47:22 2008 Subject: [sldev] [Patch] VWR-423 - Selecting group charter text causes Apply/Ignore/Cancel popup Message-ID: <20081008104717.130710@gmx.net> Hello Developers! I submitted a patch to correct the behavior in the group information panel. Right now after opening the group information panel, changing the focus in this window will cause the viewer to ask you if you want to commit changed information, even though you didn't change anything or don't even have the rights to do so. I found a few problems with the code and corrected them. The patch is on Jira. http://jira.secondlife.com/secure/attachment/18973/group_charter_apply_fix.patch Please review and discuss! Yours, Zi! -- Psssst! Schon vom neuen GMX MultiMessenger geh?rt? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger From gareth at litesim.com Wed Oct 8 03:54:10 2008 From: gareth at litesim.com (Gareth Nelson) Date: Wed Oct 8 03:54:13 2008 Subject: [sldev] Security Update 2008-10-06 to SL Viewers and source code - CLARIFICATION In-Reply-To: <48EBD146.5050807@gmail.com> References: <48EAC5D7.5020503@lindenlab.com> <48EAC870.9090108@lindenlab.com> <493033a70810062215w30224554ic9e8bc36d8df18d7@mail.gmail.com> <9bb32d430810070050q4651f2a4ub8a0174a7f6af3fa@mail.gmail.com> <48EB67A7.8070708@Arnholm.se> <48EB7F21.5090104@Arnholm.se> <48EB89DE.5090001@gmail.com> <48EBD146.5050807@gmail.com> Message-ID: <61dbdd7d0810080354t628010b3v9a0837afd2e44d30@mail.gmail.com> Personally i'd be rather more worried about this attitude of "you must have a widely-used alternative viewer to get this apparently vital security update". They aren't telling people it's ok to violate the GPL as-such, since I doubt they'll allow it after this incident. How many users must an alternative viewer have before it becomes eligible for security updates? On Tue, Oct 7, 2008 at 10:14 PM, Jason Giglio wrote: > Tateru Nino wrote: >> I think the intention was for the binaries to be redistributable, as a >> special exception - though the source availability would obviously be >> delayed a day or so. A quick email should sort that out for sure, though. > > If Linden Lab is giving people permission to violate the GPL by > releasing binaries without source, then that is more of a big deal than > the delay. Many contributors would be unhappy with that situation. > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges > From soft at lindenlab.com Wed Oct 8 04:15:12 2008 From: soft at lindenlab.com (Soft) Date: Wed Oct 8 04:15:19 2008 Subject: [sldev] Security Update 2008-10-06 to SL Viewers and source code- CLARIFICATION In-Reply-To: <61dbdd7d0810080354t628010b3v9a0837afd2e44d30@mail.gmail.com> References: <48EAC5D7.5020503@lindenlab.com> <48EAC870.9090108@lindenlab.com> <493033a70810062215w30224554ic9e8bc36d8df18d7@mail.gmail.com> <48EB67A7.8070708@Arnholm.se> <48EB7F21.5090104@Arnholm.se> <48EB89DE.5090001@gmail.com> <48EBD146.5050807@gmail.com> <61dbdd7d0810080354t628010b3v9a0837afd2e44d30@mail.gmail.com> Message-ID: The least "widely used" viewer we shared source with has about 6 users. It's honestly not a numbers game, which is why Rob said "widely available," not "widely used." We were reaching out to known viewer maintainers in advance of a full public source disclosure in order to reduce the chance of the information being misused. Working with distributions to prep a fix before full source disclosure is common with open source projects, from the Linux kernel to the most popular ssh, network filesystem and office projects. If you have suggestions for refining the process, please - speak up. But I doubt any of us would advocate dumping a future exploit in the wild before we've even started QA on the fix. On Wed, Oct 8, 2008 at 5:54 AM, Gareth Nelson wrote: > Personally i'd be rather more worried about this attitude of "you must > have a widely-used alternative viewer to get this apparently vital > security update". They aren't telling people it's ok to violate the > GPL as-such, since I doubt they'll allow it after this incident. > > How many users must an alternative viewer have before it becomes > eligible for security updates? > > On Tue, Oct 7, 2008 at 10:14 PM, Jason Giglio wrote: >> Tateru Nino wrote: >>> I think the intention was for the binaries to be redistributable, as a >>> special exception - though the source availability would obviously be >>> delayed a day or so. A quick email should sort that out for sure, though. >> >> If Linden Lab is giving people permission to violate the GPL by >> releasing binaries without source, then that is more of a big deal than >> the delay. Many contributors would be unhappy with that situation. From tom at streamsense.net Wed Oct 8 04:18:53 2008 From: tom at streamsense.net (Thomas Grimshaw) Date: Wed Oct 8 04:19:06 2008 Subject: [sldev] Security Update 2008-10-06 to SL Viewers and source code- CLARIFICATION In-Reply-To: References: <48EAC5D7.5020503@lindenlab.com> <48EAC870.9090108@lindenlab.com> <493033a70810062215w30224554ic9e8bc36d8df18d7@mail.gmail.com> <48EB67A7.8070708@Arnholm.se> <48EB7F21.5090104@Arnholm.se> <48EB89DE.5090001@gmail.com> <48EBD146.5050807@gmail.com> <61dbdd7d0810080354t628010b3v9a0837afd2e44d30@mail.gmail.com> Message-ID: <48EC971D.8070107@streamsense.net> Would it not be worth considering some kind of rapid deployment program that developers can choose to sign up to, to receive patches early providing they've agreed to non disclosure? This would mean that the serious developers could get the source they need as early as possible, without having to request the patches as such. ~T Soft wrote: > The least "widely used" viewer we shared source with has about 6 > users. It's honestly not a numbers game, which is why Rob said "widely > available," not "widely used." We were reaching out to known viewer > maintainers in advance of a full public source disclosure in order to > reduce the chance of the information being misused. > > Working with distributions to prep a fix before full source disclosure > is common with open source projects, from the Linux kernel to the most > popular ssh, network filesystem and office projects. If you have > suggestions for refining the process, please - speak up. But I doubt > any of us would advocate dumping a future exploit in the wild before > we've even started QA on the fix. > > > On Wed, Oct 8, 2008 at 5:54 AM, Gareth Nelson wrote: > >> Personally i'd be rather more worried about this attitude of "you must >> have a widely-used alternative viewer to get this apparently vital >> security update". They aren't telling people it's ok to violate the >> GPL as-such, since I doubt they'll allow it after this incident. >> >> How many users must an alternative viewer have before it becomes >> eligible for security updates? >> >> On Tue, Oct 7, 2008 at 10:14 PM, Jason Giglio wrote: >> >>> Tateru Nino wrote: >>> >>>> I think the intention was for the binaries to be redistributable, as a >>>> special exception - though the source availability would obviously be >>>> delayed a day or so. A quick email should sort that out for sure, though. >>>> >>> If Linden Lab is giving people permission to violate the GPL by >>> releasing binaries without source, then that is more of a big deal than >>> the delay. Many contributors would be unhappy with that situation. >>> > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges > From Anders at Arnholm.se Wed Oct 8 04:28:57 2008 From: Anders at Arnholm.se (Anders Arnholm) Date: Wed Oct 8 04:29:39 2008 Subject: [sldev] Security Update 2008-10-06 to SL Viewers and source code- CLARIFICATION In-Reply-To: References: <48EAC5D7.5020503@lindenlab.com> <48EAC870.9090108@lindenlab.com> <493033a70810062215w30224554ic9e8bc36d8df18d7@mail.gmail.com> <48EB67A7.8070708@Arnholm.se> <48EB7F21.5090104@Arnholm.se> <48EB89DE.5090001@gmail.com> <48EBD146.5050807@gmail.com> <61dbdd7d0810080354t628010b3v9a0837afd2e44d30@mail.gmail.com> Message-ID: <48EC9979.4000402@Arnholm.se> Soft skrev: > The least "widely used" viewer we shared source with has about 6 > users. It's honestly not a numbers game, which is why Rob said "widely > available," not "widely used." We were reaching out to known viewer > maintainers in advance of a full public source disclosure in order to > reduce the chance of the information being misused. > Rob was quick in sending the patch, that not what we discuss. > Working with distributions to prep a fix before full source disclosure > is common with open source projects, from the Linux kernel to the most > popular ssh, network filesystem and office projects. If you have > suggestions for refining the process, please - speak up. But I doubt > any of us would advocate dumping a future exploit in the wild before > we've even started QA on the fix. > > In this case I have to object, the details on how to write the exploit was in the release note. And yes it happed to send out code before to know developers, when it comes to open-ssh all developemt in the cvs is open to anyone to read. Not close stuff there and they have one of the higest trackrecords in security handling. To be honset all binaries that leave LL should been have passed QA. When you sent the build out, the code fix should have been QA passed (it was not a hard to check fix.). The problem in this case then comes with GPL, we who got the patch had to wait with releasing the bug fix for not violating the GPL. When the binaries are out the code should be out, imho the two should alwars be built and packes in one command, all versions spread at the same time. Personally i think a open CM system is a great gain for any open source project. Linux have it, OpenBSD have it (OpenSSH). Firefox have it. I know LL have some internal politics making this hard :-) But over all the fix as clear as possible as early as possible is a good thing there is nothing good in security by obsurity. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From soft at lindenlab.com Wed Oct 8 04:35:08 2008 From: soft at lindenlab.com (Soft) Date: Wed Oct 8 04:35:10 2008 Subject: [sldev] Security Update 2008-10-06 to SL Viewers and source code-CLARIFICATION In-Reply-To: <48EC971D.8070107@streamsense.net> References: <48EAC5D7.5020503@lindenlab.com> <48EAC870.9090108@lindenlab.com> <493033a70810062215w30224554ic9e8bc36d8df18d7@mail.gmail.com> <48EB67A7.8070708@Arnholm.se> <48EB7F21.5090104@Arnholm.se> <48EB89DE.5090001@gmail.com> <48EBD146.5050807@gmail.com> <61dbdd7d0810080354t628010b3v9a0837afd2e44d30@mail.gmail.com> <48EC971D.8070107@streamsense.net> Message-ID: We're in the process of roughing out something like that exactly. These are my meeting notes from a discussion we held about this. This is draft only, not set policy. Again, feedback is welcome: * Security release ** How do we want to handle security source releases in the future? ** Ideal process: *** Stage 1: Internal fix *** Stage 2: Concurrent with QA, distribute patch to trusted list of people **** Pre-generated list **** Agreement in place with us regarding non-disclosure ***** ?? Can known devs fasttrack onto list late? **** ?? permission to release binary in advance of source *** Stage 3: Announcement and binary release **** QA'd LL release **** Trusted list releases binaries, holds source **** Short embargo before mainstream source release *** Stage 4: Source publication **** We push source, clear trusted list to push source if prev. asked not to This was only an open source meeting. Decisions about when/where/how we release details or early prevention advice were outside the scope of the team present. On Wed, Oct 8, 2008 at 6:18 AM, Thomas Grimshaw wrote: > Would it not be worth considering some kind of rapid deployment program that > developers can choose to sign up to, to receive patches early providing > they've agreed to non disclosure? > > This would mean that the serious developers could get the source they need > as early as possible, without having to request the patches as such. > > ~T > > Soft wrote: >> >> The least "widely used" viewer we shared source with has about 6 >> users. It's honestly not a numbers game, which is why Rob said "widely >> available," not "widely used." We were reaching out to known viewer >> maintainers in advance of a full public source disclosure in order to >> reduce the chance of the information being misused. >> >> Working with distributions to prep a fix before full source disclosure >> is common with open source projects, from the Linux kernel to the most >> popular ssh, network filesystem and office projects. If you have >> suggestions for refining the process, please - speak up. But I doubt >> any of us would advocate dumping a future exploit in the wild before >> we've even started QA on the fix. >> >> >> On Wed, Oct 8, 2008 at 5:54 AM, Gareth Nelson wrote: >> >>> >>> Personally i'd be rather more worried about this attitude of "you must >>> have a widely-used alternative viewer to get this apparently vital >>> security update". They aren't telling people it's ok to violate the >>> GPL as-such, since I doubt they'll allow it after this incident. >>> >>> How many users must an alternative viewer have before it becomes >>> eligible for security updates? >>> >>> On Tue, Oct 7, 2008 at 10:14 PM, Jason Giglio >>> wrote: >>> >>>> >>>> Tateru Nino wrote: >>>> >>>>> >>>>> I think the intention was for the binaries to be redistributable, as a >>>>> special exception - though the source availability would obviously be >>>>> delayed a day or so. A quick email should sort that out for sure, >>>>> though. >>>>> >>>> >>>> If Linden Lab is giving people permission to violate the GPL by >>>> releasing binaries without source, then that is more of a big deal than >>>> the delay. Many contributors would be unhappy with that situation. >>>> >> >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/SLDev >> Please read the policies before posting to keep unmoderated posting >> privileges >> > > From soft at lindenlab.com Wed Oct 8 04:43:33 2008 From: soft at lindenlab.com (Soft) Date: Wed Oct 8 04:43:35 2008 Subject: [sldev] Security Update 2008-10-06 to SL Viewers and source code-CLARIFICATION In-Reply-To: <48EC9979.4000402@Arnholm.se> References: <48EAC5D7.5020503@lindenlab.com> <48EAC870.9090108@lindenlab.com> <493033a70810062215w30224554ic9e8bc36d8df18d7@mail.gmail.com> <48EB67A7.8070708@Arnholm.se> <48EB7F21.5090104@Arnholm.se> <48EB89DE.5090001@gmail.com> <48EBD146.5050807@gmail.com> <61dbdd7d0810080354t628010b3v9a0837afd2e44d30@mail.gmail.com> <48EC9979.4000402@Arnholm.se> Message-ID: On Wed, Oct 8, 2008 at 6:28 AM, Anders Arnholm wrote: > > In this case I have to object, the details on how to write the exploit was > in the release note. Yes. That was not intentional. A well-intended dev edited the release notes, which should only be maintained by a member of the release team. That shouldn't repeat. > The problem in this > case then comes with GPL, we who got the patch had to wait with releasing > the bug fix for not violating the GPL. And that still needs to be discussed. If early limited source disclosure becomes policy, we need to either live with having everyone wait, or we need to find a way to allow people to release the binary early while still complying with the licenses we offer. > But over all the fix as clear as possible as early as possible is a good > thing there is nothing good in security by obsurity. As repeated, that philosophy is about fortifying technology instead of leaving holes merely because they're difficult to see. It's never been a prescription for a project telling the world every way that it can be hurt before taking any steps to protect itself. From Anders at Arnholm.se Wed Oct 8 04:57:02 2008 From: Anders at Arnholm.se (Anders Arnholm) Date: Wed Oct 8 04:57:39 2008 Subject: [sldev] Security Update 2008-10-06 to SL Viewers and source code-CLARIFICATION In-Reply-To: References: <48EAC5D7.5020503@lindenlab.com> <48EAC870.9090108@lindenlab.com> <493033a70810062215w30224554ic9e8bc36d8df18d7@mail.gmail.com> <48EB67A7.8070708@Arnholm.se> <48EB7F21.5090104@Arnholm.se> <48EB89DE.5090001@gmail.com> <48EBD146.5050807@gmail.com> <61dbdd7d0810080354t628010b3v9a0837afd2e44d30@mail.gmail.com> <48EC9979.4000402@Arnholm.se> Message-ID: <48ECA00E.4040103@Arnholm.se> Soft skrev: > On Wed, Oct 8, 2008 at 6:28 AM, Anders Arnholm wrote: > > Yes. That was not intentional. A well-intended dev edited the release > notes, which should only be maintained by a member of the release > team. That shouldn't repeat. > > Peronally i think that was good, made it possible to deside how important the update was to apply, if one shoudl log out and update ort wait for next connection or next compile. > >> The problem in this >> case then comes with GPL, we who got the patch had to wait with releasing >> the bug fix for not violating the GPL. >> > > And that still needs to be discussed. If early limited source > disclosure becomes policy, we need to either live with having everyone > wait, or we need to find a way to allow people to release the binary > early while still complying with the licenses we offer. > > It would help, but over all I don't think with holding informaition on what the error is is a good solution, not when the fix exists, and in this moment it does. The bad once are the fist the looks for the problems. They don't wait for us to go over the code and find the problems for them. With holding back the fix you don't hold back the problem just the spead of the fix to the last users imho. >> But over all the fix as clear as possible as early as possible is a good >> thing there is nothing good in security by obsurity. >> > > As repeated, that philosophy is about fortifying technology instead of > leaving holes merely because they're difficult to see. It's never been > a prescription for a project telling the world every way that it can > be hurt before taking any steps to protect itself. > > Making the code available is a part of sending out the cure, over all i think thats a better way to approct the problem. When it comes to security I'm sure there are buffer problems caused by incoming network traffic. I think i see an increased number of crashes when servers behave bader, that is a typical sign of something bad in the network code. I wish i had time to dive into that part of the code, how ever RL coding takes to much time at the moment. Sadly no-one pay's me to hack SL code... -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From sldev at free.fr Wed Oct 8 05:29:15 2008 From: sldev at free.fr (Henri Beauchamp) Date: Wed Oct 8 05:29:21 2008 Subject: [sldev] Security Update 2008-10-06 to SL Viewers and sourcecode - CLARIFICATION In-Reply-To: <5ebce2ec0810072053i2466db78v6f93c7f1c560e63b@mail.gmail.com> References: <48EAC5D7.5020503@lindenlab.com> <48EAC870.9090108@lindenlab.com> <20081007183559.72d10993.sldev@free.fr> <20081007231823.31bed5e4.sldev@free.fr> <5ebce2ec0810072053i2466db78v6f93c7f1c560e63b@mail.gmail.com> Message-ID: <20081008142915.5353d0ac.sldev@free.fr> On Wed, 8 Oct 2008 05:53:01 +0200, Latif Khalifa wrote: > On Tue, Oct 7, 2008 at 11:18 PM, Henri Beauchamp wrote: > > On Tue, 7 Oct 2008 12:22:56 -0500, Soft wrote: > > > >> On Tue, Oct 7, 2008 at 11:35 AM, Henri Beauchamp wrote: > >> > .../... > >> > Yet the sources and patches will not be published before LL publishes > >> > their own sources. > >> > >> Thank you, Henri. It's okay to publish now. > >> > >> http://svn.secondlife.com/trac/linden/changeset/1283 > > > > Ok, links to sources and patch published. The patch for v1.19.0.5 might > > be of interest to others, so here is the direct link: > > http://sldev.free.fr/patches/11905/slviewer-0-v11905-FileAccessSecurity.patch.bz2 > > Has support UDPBlackListed flag from message template been added to > that patch set? Its very important to include it too. I guess the > patch is: > > http://svn.secondlife.com/trac/linden/changeset/1202 The corresponding patch also exists for v1.19.0.5 in the Cool SL Viewer patches set. Here is the direct link: http://sldev.free.fr/patches/11905/slviewer-0-v11905-SecurityFixBackport.patch.bz2 Please, see the Cool SL Viewer website for a full list of the many patches it uses: http://sldev.free.fr/ Henri. From tim at t-hart.com Wed Oct 8 05:53:23 2008 From: tim at t-hart.com (Tim 't Hart) Date: Wed Oct 8 05:53:11 2008 Subject: [sldev] FMOD version used in official viewer Message-ID: <988AC910122A4CC8B2EF00F7E52CCAC1@yuki> I recently compiled version 1.20.17 of the viewer and everything is working great. However, when I run the compiled exe from the normal viewer installation folder, I get a warning about a version mismatch caused by FMOD. The warning is as follows: WARNING: LLAudioEngine_FMOD::init: Error : You are using the wrong FMOD version (3.74)! You should be using FMOD 3.75 When compiling my version of the viewer, I indeed used the latest FMOD 3.75 sources (which is the most recent v3 of FMOD). But the version of fmod.dll supplied by LL is version 3.74 (161280 bytes), so that explains the warning. However, JIRA entry VWR-1437 seems to suggest that LL was/is indeed using 3.75 of FMOD. So my question is: Why is LL now shipping a 3.74 version of the library? Did you convert back to using 3.74? And if so, should we be doing the same? Or have you just mistakenly shipped an old version of the dll with the viewer? From TammyNowotny at mac.com Wed Oct 8 06:39:52 2008 From: TammyNowotny at mac.com (Tammy Nowotny) Date: Wed Oct 8 06:40:54 2008 Subject: [sldev] FMOD version used in official viewer In-Reply-To: <988AC910122A4CC8B2EF00F7E52CCAC1@yuki> References: <988AC910122A4CC8B2EF00F7E52CCAC1@yuki> Message-ID: <48ECB828.5060905@mac.com> Tim 't Hart wrote: > I recently compiled version 1.20.17 of the viewer and everything is working > great. However, when I run the compiled exe from the normal viewer > installation folder, I get a warning about a version mismatch caused by > FMOD. The warning is as follows: > > WARNING: LLAudioEngine_FMOD::init: Error : You are using the wrong FMOD > version (3.74)! You should be using FMOD 3.75 > > When compiling my version of the viewer, I indeed used the latest FMOD 3.75 > sources (which is the most recent v3 of FMOD). But the version of fmod.dll > supplied by LL is version 3.74 (161280 bytes), so that explains the warning. > > However, JIRA entry VWR-1437 seems to suggest that LL was/is indeed using > 3.75 of FMOD. So my question is: Why is LL now shipping a 3.74 version of > the library? Did you convert back to using 3.74? And if so, should we be > doing the same? Or have you just mistakenly shipped an old version of the > dll with the viewer > Maybe this may be helpful: I can tell you (from peeking at the logs from my stream, http://orange.neostreams.info:12978/ ) that Mac (and probably Linux) listeners use FMOD 3.75 whereas most users (the Windows ones) use FMOD 3.74. I have no idea why that is. Which operating system are you useing Tim't? From soft at lindenlab.com Wed Oct 8 10:56:27 2008 From: soft at lindenlab.com (Soft) Date: Wed Oct 8 10:56:32 2008 Subject: [sldev] Open Source Meeting Thu 2pm Message-ID: Our Thursday open source meetings take place at 2pm. If there is anything you would like on the agenda... have at it! http://wiki.secondlife.com/wiki/Open_Source_Meeting/Agenda From monkowsk at watson.ibm.com Wed Oct 8 13:39:09 2008 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Wed Oct 8 13:39:45 2008 Subject: [sldev] Open Source Meeting Thu 2pm In-Reply-To: References: Message-ID: <48ED1A6D.8040902@watson.ibm.com> I've added: "An update from WorkingOnIt Linden about [VWR-3943] Out of Memory in Smartheap Library errors. It has 148 votes, 55 watchers, and has been around since last year. If we could get more information about the progress, we might be able to help fix it." Although it hasn't been discussed on the mailing list (which is sort of a prerequisite for a meeting item) it has been discussed on JIRA, so I figured that would qualify it for including in the agenda. I realize theat "WorkingOnIt Linden" is an everybody and nobody ID, but if anybody could speak to the issue, it would be appreciated. Mike Soft wrote: > Our Thursday open source meetings take place at 2pm. If there is > anything you would like on the agenda... have at it! > http://wiki.secondlife.com/wiki/Open_Source_Meeting/Agenda > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges > > From gareth at litesim.com Thu Oct 9 03:05:22 2008 From: gareth at litesim.com (Gareth Nelson) Date: Thu Oct 9 03:05:25 2008 Subject: [sldev] Re: SDL on win32 In-Reply-To: <61dbdd7d0810080338r185420e8k4aad49a4bc961b5f@mail.gmail.com> References: <61dbdd7d0810080338r185420e8k4aad49a4bc961b5f@mail.gmail.com> Message-ID: <61dbdd7d0810090305h1072957am8d8d197f583e3dad@mail.gmail.com> no comment anyone? On Wed, Oct 8, 2008 at 11:38 AM, Gareth Nelson wrote: > I've been pondering why this is not used........ SDL is designed for > being cross-platform, yet the viewer only uses it on linux. If SDL was > used on all platforms instead then it would make certain tasks a lot > simpler (say for example that firefox plugin i've been working on). > > So, before I waste time messing around with this - is there any reason > SDL is not already used for the other platforms? > From makosoft at googlemail.com Thu Oct 9 03:06:21 2008 From: makosoft at googlemail.com (Aidan Thornton) Date: Thu Oct 9 03:06:26 2008 Subject: [sldev] Security Update 2008-10-06 to SL Viewers and sourcecode - CLARIFICATION In-Reply-To: <5ebce2ec0810072053i2466db78v6f93c7f1c560e63b@mail.gmail.com> References: <48EAC5D7.5020503@lindenlab.com> <48EAC870.9090108@lindenlab.com> <20081007183559.72d10993.sldev@free.fr> <20081007231823.31bed5e4.sldev@free.fr> <5ebce2ec0810072053i2466db78v6f93c7f1c560e63b@mail.gmail.com> Message-ID: On 10/8/08, Latif Khalifa wrote: > On Tue, Oct 7, 2008 at 11:18 PM, Henri Beauchamp wrote: >> On Tue, 7 Oct 2008 12:22:56 -0500, Soft wrote: >> >>> On Tue, Oct 7, 2008 at 11:35 AM, Henri Beauchamp wrote: >>> > .../... >>> > Yet the sources and patches will not be published before LL publishes >>> > their own sources. >>> >>> Thank you, Henri. It's okay to publish now. >>> >>> http://svn.secondlife.com/trac/linden/changeset/1283 >> >> Ok, links to sources and patch published. The patch for v1.19.0.5 might >> be of interest to others, so here is the direct link: >> http://sldev.free.fr/patches/11905/slviewer-0-v11905-FileAccessSecurity.patch.bz2 > > Has support UDPBlackListed flag from message template been added to > that patch set? Its very important to include it too. I guess the > patch is: > > http://svn.secondlife.com/trac/linden/changeset/1202 Hi, Yep, that's important - it looks like the patch relevant to this exploit. I think I actually spotted this issue myself a year or so ago, but it looks like for some reason I never actually got around to reporting it; probably because I didn't have the ability to fake source addresses and therefore couldn't test it properly. (As soon as the exploit was described, I guessed this was it.) Whoops - sorry about that. Aidan. From secret.argent at gmail.com Thu Oct 9 04:19:59 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Thu Oct 9 04:19:42 2008 Subject: [sldev] Re: SDL on win32 In-Reply-To: <61dbdd7d0810090305h1072957am8d8d197f583e3dad@mail.gmail.com> References: <61dbdd7d0810080338r185420e8k4aad49a4bc961b5f@mail.gmail.com> <61dbdd7d0810090305h1072957am8d8d197f583e3dad@mail.gmail.com> Message-ID: > So, before I waste time messing around with this - is there any reason > SDL is not already used for the other platforms? Among other things, the other ports predated the SDL port? Other possibilities: the SDL port is newer, and possibly less stable, and since it's just another layer over the regular API on Mac and Windows it will almost certainly add *some* overhead to calling the native API directly. And it's not like SL has CPU cycles to burn. From tofu.linden at lindenlab.com Thu Oct 9 04:26:18 2008 From: tofu.linden at lindenlab.com (Tofu Linden) Date: Thu Oct 9 04:26:08 2008 Subject: [sldev] SDL on win32 In-Reply-To: <61dbdd7d0810080338r185420e8k4aad49a4bc961b5f@mail.gmail.com> References: <61dbdd7d0810080338r185420e8k4aad49a4bc961b5f@mail.gmail.com> Message-ID: <48EDEA5A.5030200@lindenlab.com> Gareth Nelson wrote: > I've been pondering why this is not used........ SDL is designed for > being cross-platform, yet the viewer only uses it on linux. If SDL was > used on all platforms instead then it would make certain tasks a lot > simpler (say for example that firefox plugin i've been working on). > > So, before I waste time messing around with this - is there any reason > SDL is not already used for the other platforms? Linden Lab already had Win32 and OSX LLWindow implementations with which it was happy before the SDL implementation came along - there has never been a clearly positive net gain from switching all platforms to SDL. SDL doesn't handle everything we need from an LLWindow implementation natively, so there would always be platform-specific pieces (to which SDL is at best orthogonal and at worst somewhat obstructive). From gareth at litesim.com Thu Oct 9 04:32:21 2008 From: gareth at litesim.com (Gareth Nelson) Date: Thu Oct 9 04:32:23 2008 Subject: [sldev] SDL on win32 In-Reply-To: <48EDEA5A.5030200@lindenlab.com> References: <61dbdd7d0810080338r185420e8k4aad49a4bc961b5f@mail.gmail.com> <48EDEA5A.5030200@lindenlab.com> Message-ID: <61dbdd7d0810090432y3bba989aw1bba6faa64f526ce@mail.gmail.com> What platform-specific features are missing from SDL for the purposes of getting a window onscreen? On Thu, Oct 9, 2008 at 12:26 PM, Tofu Linden wrote: > Gareth Nelson wrote: >> I've been pondering why this is not used........ SDL is designed for >> being cross-platform, yet the viewer only uses it on linux. If SDL was >> used on all platforms instead then it would make certain tasks a lot >> simpler (say for example that firefox plugin i've been working on). >> >> So, before I waste time messing around with this - is there any reason >> SDL is not already used for the other platforms? > > Linden Lab already had Win32 and OSX LLWindow implementations with which > it was happy before the SDL implementation came along - there has > never been a clearly positive net gain from switching all platforms to > SDL. SDL doesn't handle everything we need from an LLWindow > implementation natively, so there would always be platform-specific > pieces (to which SDL is at best orthogonal and at worst somewhat > obstructive). > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges > From tofu.linden at lindenlab.com Thu Oct 9 04:44:11 2008 From: tofu.linden at lindenlab.com (Tofu Linden) Date: Thu Oct 9 04:43:59 2008 Subject: [sldev] SDL on win32 In-Reply-To: <61dbdd7d0810090432y3bba989aw1bba6faa64f526ce@mail.gmail.com> References: <61dbdd7d0810080338r185420e8k4aad49a4bc961b5f@mail.gmail.com> <48EDEA5A.5030200@lindenlab.com> <61dbdd7d0810090432y3bba989aw1bba6faa64f526ce@mail.gmail.com> Message-ID: <48EDEE8B.5030805@lindenlab.com> Gareth Nelson wrote: > What platform-specific features are missing from SDL for the purposes > of getting a window onscreen? None at all, though LLWindow (and friends) do a lot more than getting a window on the screen. > On Thu, Oct 9, 2008 at 12:26 PM, Tofu Linden wrote: >> Gareth Nelson wrote: >>> I've been pondering why this is not used........ SDL is designed for >>> being cross-platform, yet the viewer only uses it on linux. If SDL was >>> used on all platforms instead then it would make certain tasks a lot >>> simpler (say for example that firefox plugin i've been working on). >>> >>> So, before I waste time messing around with this - is there any reason >>> SDL is not already used for the other platforms? >> Linden Lab already had Win32 and OSX LLWindow implementations with which >> it was happy before the SDL implementation came along - there has >> never been a clearly positive net gain from switching all platforms to >> SDL. SDL doesn't handle everything we need from an LLWindow >> implementation natively, so there would always be platform-specific >> pieces (to which SDL is at best orthogonal and at worst somewhat >> obstructive). From alissa_sabre at yahoo.co.jp Wed Oct 8 16:44:25 2008 From: alissa_sabre at yahoo.co.jp (Alissa Sabre) Date: Thu Oct 9 06:52:04 2008 Subject: [sldev] SDL on win32 In-Reply-To: <61dbdd7d0810080338r185420e8k4aad49a4bc961b5f@mail.gmail.com> References: <61dbdd7d0810080338r185420e8k4aad49a4bc961b5f@mail.gmail.com> Message-ID: <1dt4dt8kx4nn1dz4s7uds86o.alissa_sabre@yahoo.co.jp> > is there any reason > SDL is not already used for the other platforms? SDL currently supports input methods only under X11. Even under X11, SDL supports it very poorly. That's my number one reason to avoid using SDL. Alissa Sabre -------------------------------------- Enjoy MLB with MAJOR.JP! Ichiro, Matsuzaka, Matsui, and more! http://pr.mail.yahoo.co.jp/mlb/ From sly_squash at hotmail.com Sun Oct 12 19:39:23 2008 From: sly_squash at hotmail.com (Joshy Squashy) Date: Sun Oct 12 19:39:27 2008 Subject: [sldev] [HELP] Building 1.21.5_RC for VS2008 Message-ID: Hello, I was just wondering if we've tested 1.21 for VS2008. I saw on http://wiki.secondlife.com/wiki/User:Michelle2_Zenovka/cmake that, by using "develop.py configure -G VC90" instead of "develop.py configure -G VC80", it tells cmake to ready the project to be opened by VS2008. When I do this and build the project (excluding that llkdu.dll rule and what not) the project compiles and links but the viewer does not startup for some reason. When I run CMake to produce a VS2005 project, however, it compiles and runs fine. ~Squash Otoro _________________________________________________________________ See how Windows Mobile brings your life together?at home, work, or on the go. http://clk.atdmt.com/MRT/go/msnnkwxp1020093182mrt/direct/01/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20081012/8e2f36c5/attachment.htm From tom at streamsense.net Sun Oct 12 19:41:39 2008 From: tom at streamsense.net (Thomas Grimshaw) Date: Sun Oct 12 19:41:46 2008 Subject: [sldev] [HELP] Building 1.21.5_RC for VS2008 In-Reply-To: References: Message-ID: <48F2B563.3000307@streamsense.net> This is due to a libboost incompatibility. Build against a more recent version of boost and you should do fine.. http://jira.secondlife.com/browse/VWR-9541 ~Tom Joshy Squashy wrote: > Hello, > > I was just wondering if we've tested 1.21 for VS2008. > > I saw on > http://wiki.secondlife.com/wiki/User:Michelle2_Zenovka/cmake that, by > using "develop.py configure -G VC90" instead of "develop.py configure > -G VC80", it tells cmake to ready the project to be opened by VS2008. > When I do this and build the project (excluding that llkdu.dll rule > and what not) the project compiles and links but the viewer does not > startup for some reason. When I run CMake to produce a VS2005 > project, however, it compiles and runs fine. > > ~Squash Otoro > > > > ------------------------------------------------------------------------ > See how Windows Mobile brings your life together?at home, work, or on > the go. See Now > > ------------------------------------------------------------------------ > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges From fire at eslteacherlink.co.kr Sun Oct 12 22:53:47 2008 From: fire at eslteacherlink.co.kr (Fire in Korea) Date: Sun Oct 12 22:53:49 2008 Subject: [sldev] Voice via bots Message-ID: <1dabc2a30810122253l3a83b47fvb60e880f12be2b7a@mail.gmail.com> Hi everyone, Just wondering, anyone figure out a way to pump voice or audio through a bots voice channel? From tinacloud at gmx.de Mon Oct 13 11:45:29 2008 From: tinacloud at gmx.de (Zi Ree) Date: Mon Oct 13 11:45:49 2008 Subject: [sldev] [PATCH] VWR-9127 - Delete key does not function when editing teleport destination text in "offer teleport" dialoge Message-ID: <200810132045.30670.tinacloud@gmx.de> Hi Developers! I found a fix for the dysfunctional edit keys in a couple of alert dialogues. Please review and comment. http://jira.secondlife.com/secure/attachment/19551/edit_keys_in_alert_dialogs.patch Thanks! Zi! From chaosstar at gmail.com Mon Oct 13 23:58:29 2008 From: chaosstar at gmail.com (Ambrosia) Date: Mon Oct 13 23:58:32 2008 Subject: [sldev] Bug in current trunk: Unable to upload scripts Message-ID: <9bb32d430810132358o43ed72f1na1620fcc31937ce9@mail.gmail.com> Greetings, thought I'd point out the just-created JIRA on this: http://jira.secondlife.com/browse/VWR-9784 I've been waiting for the past few trunk updates, figuring it might be an intentional change for some backend changes, but it's been the status quo for a short while now. Scripts simply cannot be uploaded. Switching back to an older 1.21 trunk based viewer makes the script upload work nicely. I don't know if it's caused by some other changes that still need to be finalized, but I've noticed that nobody else seems to have publically noticed so far. --Chalice Yao From grant at lindenlab.com Tue Oct 14 10:16:02 2008 From: grant at lindenlab.com (Grant Linden) Date: Tue Oct 14 10:16:08 2008 Subject: [sldev] RX Office hours - Coco Linden updates us all on the Featurettes initiative Message-ID: <907af5560810141016tb22e970s6dad43730f27b67f@mail.gmail.com> RX Office hours - Coco Linden updates us all on the Featurettes initiative Thursday October 16th from 3:00-4:00 PM SLT http://slurl.com/secondlife/Beaumont/148/155/46/?title=Linden%20Village For more news about the RX team and to suggest topics for future RX Office Hours please visit our new wiki page: https://wiki.secondlife.com/wiki/Resident_Experience The SL-UX Email Discussion List is the ongoing conversation about the Second Life UI and Resident Experience. Residents and Lindens join together to discuss, brain storm and refine the Second Life UI. Join here: https://lists.secondlife.com/cgi-bin/mailman/listinfo/sl-ux -- Steven Grant (Grant Linden) User Experience Designer Linden Lab | Second Life -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20081014/dc7f0319/attachment.htm From soft at lindenlab.com Wed Oct 15 09:57:07 2008 From: soft at lindenlab.com (Soft) Date: Wed Oct 15 09:57:10 2008 Subject: [sldev] Bug in current trunk: Unable to upload scripts In-Reply-To: <9bb32d430810132358o43ed72f1na1620fcc31937ce9@mail.gmail.com> References: <9bb32d430810132358o43ed72f1na1620fcc31937ce9@mail.gmail.com> Message-ID: On Tue, Oct 14, 2008 at 1:58 AM, Ambrosia wrote: > Greetings, > > thought I'd point out the just-created JIRA on this: > > http://jira.secondlife.com/browse/VWR-9784 > > I've been waiting for the past few trunk updates, figuring it might be > an intentional change for some backend changes, > but it's been the status quo for a short while now. Scripts simply > cannot be uploaded. Switching back to an older 1.21 trunk > based viewer makes the script upload work nicely. > > I don't know if it's caused by some other changes that still need to > be finalized, but I've noticed that nobody else > seems to have publically noticed so far. I believe I have a fix. I'll update the JIRA when that goes in. From tinacloud at gmx.de Wed Oct 15 14:01:47 2008 From: tinacloud at gmx.de (Zi Ree) Date: Wed Oct 15 14:01:53 2008 Subject: [sldev] [PATCH]VWR-7913 - Teleport History Message-ID: <200810152301.47525.tinacloud@gmx.de> Hello Developers! I implemented a teleport history floater so you can look back at the places you've been to and quickly teleport back, copy the SLURL or look at it on the map. http://jira.secondlife.com/browse/VWR-7913 Comments are welcome! Zi! From aimee at ama-zing.co.uk Wed Oct 15 14:24:29 2008 From: aimee at ama-zing.co.uk (Aimee Walton) Date: Wed Oct 15 14:24:34 2008 Subject: [sldev] [PATCH]VWR-7913 - Teleport History In-Reply-To: <200810152301.47525.tinacloud@gmx.de> References: <200810152301.47525.tinacloud@gmx.de> Message-ID: On 15 Oct 2008, at 22:01, Zi Ree wrote: > Hello Developers! > > I implemented a teleport history floater so you can look back at the > places > you've been to and quickly teleport back, copy the SLURL or look at > it on the > map. Doesn't that duplicate part of the Landmarks and Navigation project, and as such is unlikely to get officially adopted? http://jira.secondlife.com/browse/VWR-7900 Not wanting to discourage you, but you're probably duplicating work. Aimee. From tinacloud at gmx.de Wed Oct 15 14:36:16 2008 From: tinacloud at gmx.de (Zi Ree) Date: Wed Oct 15 14:36:21 2008 Subject: [sldev] [PATCH]VWR-7913 - Teleport History In-Reply-To: References: <200810152301.47525.tinacloud@gmx.de> Message-ID: <200810152336.17145.tinacloud@gmx.de> Am Mittwoch 15 Oktober 2008 schrieb Aimee Walton: > On 15 Oct 2008, at 22:01, Zi Ree wrote: > > I implemented a teleport history floater so you can look back at the > Doesn't that duplicate part of the Landmarks and Navigation project, > and as such is unlikely to get officially adopted? I didn't know such a project existed. But that's not a problem. Maybe my code can serve as an example on how to code things like this :) > http://jira.secondlife.com/browse/VWR-7900 Thanks for the link! > Aimee. Zi! From lenglish5 at cox.net Wed Oct 15 14:41:57 2008 From: lenglish5 at cox.net (Lawson English) Date: Wed Oct 15 14:42:02 2008 Subject: [sldev] [META] reading lists and indexing lists Message-ID: <48F663A5.2090306@cox.net> I've been playing around with the various web-pages for AWG, pyogp, OGP, etc., and I've tried to create pages that index items of interest in various ways. Just about anything AWG, OGP, etc, should be findable via at least one of these categories. http://wiki.secondlife.com/wiki/Category:Grid_Interoperability --catchall for anything OGP related http://wiki.secondlife.com/wiki/Category:Open_Grid_Public_Beta --catchall for OGP Beta http://wiki.secondlife.com/wiki/Category:Grid_Interoperability_Chat_Logs --catchall for all office hour and other in-world meetings related to OGP and AWG http://wiki.secondlife.com/wiki/AW_Groupies#Misc_User_Pages --catchall index for user pages on the wiki of a technical nature --if you have something of interest to other people add the category to the bottom so others can find it http://wiki.secondlife.com/wiki/Category:Pyogp_Kitchen_Sink --catchall index for pages related to pyogp Enjoy. Lawson From robla at lindenlab.com Wed Oct 15 15:22:50 2008 From: robla at lindenlab.com (Rob Lanphier) Date: Wed Oct 15 15:23:12 2008 Subject: [sldev] [PATCH]VWR-7913 - Teleport History In-Reply-To: <200810152301.47525.tinacloud@gmx.de> References: <200810152301.47525.tinacloud@gmx.de> Message-ID: <48F66D3A.9000605@lindenlab.com> On 10/15/08 2:01 PM, Zi Ree wrote: > Hello Developers! > > I implemented a teleport history floater so you can look back at the places > you've been to and quickly teleport back, copy the SLURL or look at it on the > map. > > http://jira.secondlife.com/browse/VWR-7913 > > Comments are welcome! > Thanks for the patch! Also, thanks for bringing it up here. Given that this is a UI feature, you may also want to discuss this on the sl-ux mailing list (where usability issues are discussed): https://lists.secondlife.com/cgi-bin/mailman/listinfo/sl-ux I imagine as the group of us who look through the incoming patches look at this, we'll want to get the input of the usability folks, so raising it there puts us a little further ahead than we might be otherwise. Rob From lenglish5 at cox.net Wed Oct 15 19:55:06 2008 From: lenglish5 at cox.net (Lawson English) Date: Wed Oct 15 19:55:10 2008 Subject: [sldev] Re: [Gridnauts] What's the difference between... In-Reply-To: <001e01c92f24$4afc59f0$0700a8c0@acl13c6f3e2ec1> References: <48F663A5.2090306@cox.net> <001e01c92f24$4afc59f0$0700a8c0@acl13c6f3e2ec1> Message-ID: <48F6AD0A.4090403@cox.net> Colin Withers wrote: > Sorry for asking this basic question. I joined the Gridnauts program > but due to unforseeen RL commitments I have not had any chance yet to > get too involved. I do have a fully developed OpenSim grid of my own. > > What I would like to ask is this: > > Imagine I am in SL (or the beta grid). I then log out, and then log > into my OpenSim. Now imagine I have a viewer where this process is > automated and while it is doing the log-out/log-in process a teleport > splash screen appears with a progress bar. I am now in my OpenSim > having 'apparently' teleported, but I notice that my appearance is not > the same as when I started, and I have not the inventory I started with. > > What's the difference between that, and what the Gridnauts are > currently doing? With the gridnauts viewer, you are logging into an "AgentDomain" which then vouches for you to each region/grid you decide to visit. There are currently many dozens of test sims/grids that accept this authorization process so when you leave a sim or grid, you're not logging out of one sim/grid and logging into another. In the long run, we hope to keep inventory management and group IM services going even if you don't bother to visit any sim/grid at all. This will allow very lightweight clients as a side benefit and should relieve a lot of burden on the sims right now, which have to do EVERYTHING. Lawson From soft at lindenlab.com Thu Oct 16 07:51:32 2008 From: soft at lindenlab.com (Soft) Date: Thu Oct 16 07:51:35 2008 Subject: [sldev] Open Source Meeting Thu 2pm Message-ID: Our Thursday open source meetings take place at 2pm. If there is anything you would like on the agenda... have at it! http://wiki.secondlife.com/wiki/Open_Source_Meeting/Agenda From intertricity at gmail.com Fri Oct 17 11:12:05 2008 From: intertricity at gmail.com (intertricity@gmail.com) Date: Fri Oct 17 11:12:09 2008 Subject: [sldev] Accessing eye bones through bvh? Message-ID: <000e0cd5149c2372a9045976e7b9@google.com> I found and played with the bvh deformations from this JIRA -> https://jira.secondlife.com/browse/VWR-2242 I'm curious to know if it's possible to acces and offset the eye bone positions- even though I don't see anything like lEye or similar, it was worth asking :) Thanks in advance! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20081017/9ae65f41/attachment.htm From monkowsk at watson.ibm.com Fri Oct 17 14:10:35 2008 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Fri Oct 17 14:11:07 2008 Subject: [sldev] Accessing eye bones through bvh? In-Reply-To: <000e0cd5149c2372a9045976e7b9@google.com> References: <000e0cd5149c2372a9045976e7b9@google.com> Message-ID: <48F8FF4B.7040800@watson.ibm.com> The translation to the Linden bones is done through the app_setting/anim.ini file. Bones for the eyes are not listed there, so they couldn't be translated. If you want to hack it, the Linden bones are named mEyeLeft and mEyeRight (found in character/avatar_skeleton.xml and character/avatar_lad.xml), but I don't know what would happen. They are driven together with the Eye_Spread mesh morph when adjusting appearance for Eye Spacing. Mike intertricity@gmail.com wrote: > I found and played with the bvh deformations from this JIRA -> > https://jira.secondlife.com/browse/VWR-2242 > > I'm curious to know if it's possible to acces and offset the eye bone > positions- even though I don't see anything like lEye or similar, it was > worth asking :) > > Thanks in advance! From open at autistici.org Sat Oct 18 04:09:20 2008 From: open at autistici.org (Opensource Obscure) Date: Sat Oct 18 04:09:24 2008 Subject: [sldev] [VWR] Shadows on Linux Message-ID: <5a16e34fc26c8ce3f83a7ede5ff63594@localhost> I just moved from a Nvidia 7300 graphic card to a 9600 GT, that AFAIK should support the shadow draft viewer. Are shadows present in the Linux codebase? Which branch should I check out, and which steps should I take before and after compiling the sources in order to enable shadows (if possible at all) ? (I know how to compile the viewer sources and apply patches on my system, but not much more than this) Thanks in advance. Opensource Obscure From soft at lindenlab.com Sat Oct 18 06:35:43 2008 From: soft at lindenlab.com (Soft) Date: Sat Oct 18 06:35:46 2008 Subject: [sldev] [VWR] Shadows on Linux In-Reply-To: <5a16e34fc26c8ce3f83a7ede5ff63594@localhost> References: <5a16e34fc26c8ce3f83a7ede5ff63594@localhost> Message-ID: On Sat, Oct 18, 2008 at 6:09 AM, Opensource Obscure wrote: > > Are shadows present in the Linux codebase? > > Which branch should I check out, > and which steps should I take before and after compiling the > sources in order to enable shadows (if possible at all) ? Shadows are merged into the maint-render-8 branch, and should merge up to trunk after not very long. I don't know if Linux is yet at parity on shadows. Perhaps others can help out here. From marinekelley at gmail.com Sat Oct 18 09:03:30 2008 From: marinekelley at gmail.com (Marine Kelley) Date: Sat Oct 18 09:03:35 2008 Subject: [sldev] maint-render-10 crashes at launch, can't create texture In-Reply-To: <1e0ce1090809021607o7ea523f4gd6d077b97e63b883@mail.gmail.com> References: <1e0ce1090809011537t452ed8e7n230d8cba4b8b2728@mail.gmail.com> <48BCE0BF.80306@gmail.com> <1e0ce1090809021607o7ea523f4gd6d077b97e63b883@mail.gmail.com> Message-ID: <9e52a8c10810180903m6a5a2673t876d44ffd67c2dc3@mail.gmail.com> Hi, I have the exact same problem, after compiling 1.21.6 downloaded from the source downloads page, added the relevant libraries (which were working fine until 1.20.17, but I never tried with a 1.21.* until now), running the viewer crashes on startup. I am running on Windows, compiling with VC2005 Express, the target is "Release". My log is identical to azdel's. I'm pretty sure the artwork and other zip files are ok, since their names are all *viewer_1-21-r99587.zip The crash occurs within LLImageJ2C::decodeChannels(), so probably related to a texture decoding going nuts. Please help, I have very little time to even apply my patch to this new version, and cannot even make it to run from a vanilla code... Anybody found the solution to this problem ? Thanks in advance, Marine -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20081018/3c2bc9a0/attachment.htm From open at autistici.org Sat Oct 18 10:37:17 2008 From: open at autistici.org (Opensource Obscure) Date: Sat Oct 18 10:37:21 2008 Subject: [sldev] [VWR] Shadows on Linux In-Reply-To: References: <5a16e34fc26c8ce3f83a7ede5ff63594@localhost> Message-ID: On Sat, 18 Oct 2008 08:35:43 -0500, Soft wrote: > On Sat, Oct 18, 2008 at 6:09 AM, Opensource Obscure > wrote: >> >> Are shadows present in the Linux codebase? >> >> Which branch should I check out, >> and which steps should I take before and after compiling the >> sources in order to enable shadows (if possible at all) ? > > Shadows are merged into the maint-render-8 branch, and should merge up > to trunk after not very long. I don't know if Linux is yet at parity > on shadows. Perhaps others can help out here. rev 99647 from maint-render-8 branch built without errors, and shadows are working: http://www.flickr.com/photos/opensourceobscure/2952254820 :) thanks for this feature! at the moment the viewer crashes very often here, sometimes even before I can see the world. this was a main problem at first because I couldn't enable the RenderDeferred and RenderUseFBO options in Advanced menu > Debug Settings (you need to enable those options to actually enable shadows) when the viewer crashes, the error message is "ERROR: checkTextureChannels: GL texture state corruption detected" as a workaround in order to enable RenderUseFBO and RenderDeferred options without having to get in-world, i think one could add these lines in a settings file (maybe ~/.secondlife/user_settings/settings_developer.xml ?) RenderUseFBO Comment Whether we want to use GL_EXT_framebuffer_objects. Type Boolean Value 1 RenderDeferred Comment Use deferred rendering pipeline. Type Boolean Value 1 Opensource Obscure -- http://friendfeed.com/oobscure From dnbyena at gmail.com Sat Oct 18 10:44:11 2008 From: dnbyena at gmail.com (Khyota) Date: Sat Oct 18 10:44:16 2008 Subject: [sldev] [VWR] Shadows on Linux In-Reply-To: References: <5a16e34fc26c8ce3f83a7ede5ff63594@localhost> Message-ID: <48fa206d.2386460a.07ba.ffffaefe@mx.google.com> > rev 99647 from maint-render-8 branch built without errors, > and shadows are working: > http://www.flickr.com/photos/opensourceobscure/2952254820 > > :) thanks for this feature! > > at the moment the viewer crashes very often here, sometimes even > before I can see the world. this was a main problem at first > because I couldn't enable the RenderDeferred and RenderUseFBO > options in Advanced menu > Debug Settings > > (you need to enable those options to actually enable shadows) > > when the viewer crashes, the error message is > "ERROR: checkTextureChannels: GL texture state corruption detected" > > as a workaround in order to enable RenderUseFBO and RenderDeferred > options without having to get in-world, i think one could add these > lines in a settings file > (maybe ~/.secondlife/user_settings/settings_developer.xml ?) > > > RenderUseFBO > > Comment > Whether we want to use GL_EXT_framebuffer_objects. > Type > Boolean > Value > 1 > > > RenderDeferred > > Comment > Use deferred rendering pipeline. > Type > Boolean > Value > 1 > > > > Opensource Obscure > -- > http://friendfeed.com/oobscure > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges I just finished a build too, but i get a fatal error at startup ERROR: setImage: ASSERT (gGL.getTexUnit(0)->bind(this)) Console says 2008-10-18T17:39:33Z INFO: loadGPUClass: GPU is NVIDIA GeForce 8400 2008-10-18T17:39:33Z INFO: applyBaseMasks: Setting GPU Class to Class1 2008-10-18T17:39:33Z INFO: LLViewerImageList::updateMaxResidentTexMem: Total Video Memory set to: 240 MB 2008-10-18T17:39:33Z INFO: LLViewerImageList::updateMaxResidentTexMem: Available Texture Memory set to: 180 MB 2008-10-18T17:39:34Z llrender/llimagegl.cpp(456) : error 2008-10-18T17:39:34Z ERROR: setImage: ASSERT (gGL.getTexUnit(0)->bind(this)) From soft at lindenlab.com Sat Oct 18 10:58:21 2008 From: soft at lindenlab.com (Soft) Date: Sat Oct 18 10:58:25 2008 Subject: [sldev] [VWR] Shadows on Linux In-Reply-To: <48fa206d.2386460a.07ba.ffffaefe@mx.google.com> References: <5a16e34fc26c8ce3f83a7ede5ff63594@localhost> <48fa206d.2386460a.07ba.ffffaefe@mx.google.com> Message-ID: On Sat, Oct 18, 2008 at 12:44 PM, Khyota wrote: > >> rev 99647 from maint-render-8 branch built without errors, >> and shadows are working: >> http://www.flickr.com/photos/opensourceobscure/2952254820 >> >> :) thanks for this feature! >> >> at the moment the viewer crashes very often here, sometimes even >> before I can see the world. this was a main problem at first >> because I couldn't enable the RenderDeferred and RenderUseFBO >> options in Advanced menu > Debug Settings >> >> (you need to enable those options to actually enable shadows) >> >> when the viewer crashes, the error message is >> "ERROR: checkTextureChannels: GL texture state corruption detected" >> >> as a workaround in order to enable RenderUseFBO and RenderDeferred >> options without having to get in-world, i think one could add these >> lines in a settings file >> (maybe ~/.secondlife/user_settings/settings_developer.xml ?) >> >> >> RenderUseFBO >> >> Comment >> Whether we want to use GL_EXT_framebuffer_objects. >> Type >> Boolean >> Value >> 1 >> >> >> RenderDeferred >> >> Comment >> Use deferred rendering pipeline. >> Type >> Boolean >> Value >> 1 >> >> >> >> Opensource Obscure >> -- >> http://friendfeed.com/oobscure >> >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/SLDev >> Please read the policies before posting to keep unmoderated posting >> privileges > I just finished a build too, but i get a fatal error at startup > ERROR: setImage: ASSERT (gGL.getTexUnit(0)->bind(this)) > > Console says > > 2008-10-18T17:39:33Z INFO: loadGPUClass: GPU is NVIDIA GeForce 8400 > 2008-10-18T17:39:33Z INFO: applyBaseMasks: Setting GPU Class to Class1 > 2008-10-18T17:39:33Z INFO: LLViewerImageList::updateMaxResidentTexMem: Total > Video Memory set to: 240 MB > 2008-10-18T17:39:33Z INFO: LLViewerImageList::updateMaxResidentTexMem: > Available Texture Memory set to: 180 MB > 2008-10-18T17:39:34Z llrender/llimagegl.cpp(456) : error > 2008-10-18T17:39:34Z ERROR: setImage: ASSERT (gGL.getTexUnit(0)->bind(this)) With both of the above - if you would write up JIRAs and post them here, I'll hand them directly to the graphics devs. I don't know if any of them are using Linux during development, so discovering these before QA does would be helpful. From dnbyena at gmail.com Sat Oct 18 11:15:11 2008 From: dnbyena at gmail.com (Khyota) Date: Sat Oct 18 11:15:16 2008 Subject: [sldev] [VWR] Shadows on Linux In-Reply-To: References: <5a16e34fc26c8ce3f83a7ede5ff63594@localhost> <48fa206d.2386460a.07ba.ffffaefe@mx.google.com> Message-ID: <200810181415.11990.dnbyena@gmail.com> On Saturday 18 October 2008 01:58:21 pm Soft wrote: > With both of the above - if you would write up JIRAs and post them > here, I'll hand them directly to the graphics devs. I don't know if > any of them are using Linux during development, so discovering these > before QA does would be helpful. Done, hope i included enough info. http://jira.secondlife.com/browse/VWR-9891 From dnbyena at gmail.com Sat Oct 18 11:34:24 2008 From: dnbyena at gmail.com (Khyota) Date: Sat Oct 18 11:34:31 2008 Subject: [sldev] [VWR] Shadows on Linux In-Reply-To: References: <5a16e34fc26c8ce3f83a7ede5ff63594@localhost> Message-ID: <200810181434.25241.dnbyena@gmail.com> Since shadows have been merged to maint-render-8 is shadow-draft-2 still maintained? If not, would this still be vaild? http://jira.secondlife.com/browse/VWR-9502 From soft at lindenlab.com Sat Oct 18 11:40:15 2008 From: soft at lindenlab.com (Soft) Date: Sat Oct 18 11:40:17 2008 Subject: [sldev] [VWR] Shadows on Linux In-Reply-To: <200810181434.25241.dnbyena@gmail.com> References: <5a16e34fc26c8ce3f83a7ede5ff63594@localhost> <200810181434.25241.dnbyena@gmail.com> Message-ID: On Sat, Oct 18, 2008 at 1:34 PM, Khyota wrote: > Since shadows have been merged to maint-render-8 is shadow-draft-2 still > maintained? > > If not, would this still be vaild? > http://jira.secondlife.com/browse/VWR-9502 If those warnings still exist in maint-render-8 it's still valid, but it would be great if you'd add a note about the new branch. If they died with maint-render-8 you can consider it dead. :) From dnbyena at gmail.com Sat Oct 18 11:45:22 2008 From: dnbyena at gmail.com (Khyota) Date: Sat Oct 18 11:45:28 2008 Subject: [sldev] develop.py script issues Message-ID: <200810181445.22951.dnbyena@gmail.com> Here are a couple issues that Soft suggested i mention here concerning develop.py script. /develop.py --standalone build is required to build standalone even after it is configured with ./develop.py --standalone configure. http://jira.secondlife.com/browse/VWR-9816 ./develop.py clean does not clean out downloaded library lists and configure stuff after non-standalone build. http://jira.secondlife.com/browse/VWR-9815 Any comments? From soft at lindenlab.com Sat Oct 18 11:50:18 2008 From: soft at lindenlab.com (Soft) Date: Sat Oct 18 11:50:20 2008 Subject: [sldev] develop.py --standalone script issues Message-ID: On Sat, Oct 18, 2008 at 1:45 PM, Khyota wrote: > Here are a couple issues that Soft suggested i mention here concerning > develop.py script. > > /develop.py --standalone build is required to build standalone even after it > is configured with ./develop.py --standalone configure. > http://jira.secondlife.com/browse/VWR-9816 > > ./develop.py clean does not clean out downloaded library lists and configure > stuff after non-standalone build. > http://jira.secondlife.com/browse/VWR-9815 > > Any comments? Specifically, help would be appreciated since these are with --standalone builds. We very rarely do these as Lindens since we're generally focused on the version we package. Patches or specific pointers would likely see these fixed months sooner. From thordain at thordain.com Sun Oct 19 16:02:56 2008 From: thordain at thordain.com (Thordain Curtis) Date: Sun Oct 19 16:02:58 2008 Subject: [sldev] maint-render-10 crashes at launch, can't create texture In-Reply-To: <9e52a8c10810180903m6a5a2673t876d44ffd67c2dc3@mail.gmail.com> References: <1e0ce1090809011537t452ed8e7n230d8cba4b8b2728@mail.gmail.com> <48BCE0BF.80306@gmail.com> <1e0ce1090809021607o7ea523f4gd6d077b97e63b883@mail.gmail.com> <9e52a8c10810180903m6a5a2673t876d44ffd67c2dc3@mail.gmail.com> Message-ID: On Sat, Oct 18, 2008 at 12:03 PM, Marine Kelley wrote: > Hi, I have the exact same problem, after compiling 1.21.6 downloaded from > the source downloads page, added the relevant libraries (which were working > fine until 1.20.17, but I never tried with a 1.21.* until now), running the > viewer crashes on startup. I am running on Windows, compiling with VC2005 > Express, the target is "Release". > > My log is identical to azdel's. I'm pretty sure the artwork and other zip > files are ok, since their names are all *viewer_1-21-r99587.zip > > The crash occurs within LLImageJ2C::decodeChannels(), so probably related > to a texture decoding going nuts. > > Please help, I have very little time to even apply my patch to this new > version, and cannot even make it to run from a vanilla code... Anybody found > the solution to this problem ? > > Thanks in advance, > Marine > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > I also had a crash at the same point after pull changes form 1.21.6. The 1.21 branch had thus far worked perfectly for me. Doing a quick debug showed my error was comming up in KDU as well, so I simply removed the dll file. Second Life is designed to use the open jpeg library when kdu is absent. This seemed to work just fine. You might give it a try. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20081019/76a1f445/attachment.htm From marinekelley at gmail.com Sun Oct 19 22:09:26 2008 From: marinekelley at gmail.com (Marine Kelley) Date: Sun Oct 19 22:09:30 2008 Subject: [sldev] maint-render-10 crashes at launch, can't create texture In-Reply-To: References: <1e0ce1090809011537t452ed8e7n230d8cba4b8b2728@mail.gmail.com> <48BCE0BF.80306@gmail.com> <1e0ce1090809021607o7ea523f4gd6d077b97e63b883@mail.gmail.com> <9e52a8c10810180903m6a5a2673t876d44ffd67c2dc3@mail.gmail.com> Message-ID: <9e52a8c10810192209q5370d83at24adca7c9188ac8a@mail.gmail.com> It works ! There were several problems actually : VC2005 Express, llkdu.dll to remove, SL to fully uninstall. Thank you for your help ! Marine 2008/10/20 Thordain Curtis > > On Sat, Oct 18, 2008 at 12:03 PM, Marine Kelley wrote: > >> Hi, I have the exact same problem, after compiling 1.21.6 downloaded from >> the source downloads page, added the relevant libraries (which were working >> fine until 1.20.17, but I never tried with a 1.21.* until now), running the >> viewer crashes on startup. I am running on Windows, compiling with VC2005 >> Express, the target is "Release". >> >> My log is identical to azdel's. I'm pretty sure the artwork and other zip >> files are ok, since their names are all *viewer_1-21-r99587.zip >> >> The crash occurs within LLImageJ2C::decodeChannels(), so probably related >> to a texture decoding going nuts. >> >> Please help, I have very little time to even apply my patch to this new >> version, and cannot even make it to run from a vanilla code... Anybody found >> the solution to this problem ? >> >> Thanks in advance, >> Marine >> >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/SLDev >> Please read the policies before posting to keep unmoderated posting >> privileges >> > > I also had a crash at the same point after pull changes form 1.21.6. The > 1.21 branch had thus far worked perfectly for me. Doing a quick debug > showed my error was comming up in KDU as well, so I simply removed the dll > file. Second Life is designed to use the open jpeg library when kdu is > absent. This seemed to work just fine. You might give it a try. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20081020/648f88ce/attachment.htm From chaosstar at gmail.com Mon Oct 20 00:03:08 2008 From: chaosstar at gmail.com (Ambrosia) Date: Mon Oct 20 00:03:14 2008 Subject: [sldev] Anybody still getting JIRA-notify e-mails? Message-ID: <9bb32d430810200003k194a70d1wfd6aca08d6db6d5@mail.gmail.com> Greetings! Is anybody still getting mails from jira-notify? My last one is from the 18th, and weekends usually are the most busy time when it comes to JIRA. Something seems b0rked here. --Chalice Yao From GordonWendt at gmail.com Mon Oct 20 00:31:40 2008 From: GordonWendt at gmail.com (Gordon Wendt) Date: Mon Oct 20 00:31:43 2008 Subject: [sldev] Anybody still getting JIRA-notify e-mails? In-Reply-To: <9bb32d430810200003k194a70d1wfd6aca08d6db6d5@mail.gmail.com> References: <9bb32d430810200003k194a70d1wfd6aca08d6db6d5@mail.gmail.com> Message-ID: <493033a70810200031y134e6842t6d60b900b8ae1404@mail.gmail.com> I haven't however it's tough to tell which Linden to contact in a case like this (if any) although I think the JIRA admins are the ones that would be best suited to fix this. This is quite concerning though and I hope that for no apparent reason this has broken and hopefully it will be fixed soon. -Gordon On Mon, Oct 20, 2008 at 3:03 AM, Ambrosia wrote: > Greetings! > > Is anybody still getting mails from jira-notify? > > My last one is from the 18th, and weekends usually are the most busy > time when it comes to JIRA. > > Something seems b0rked here. > > --Chalice Yao > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20081020/5f67798a/attachment.htm From robla at lindenlab.com Mon Oct 20 00:41:07 2008 From: robla at lindenlab.com (Rob Lanphier) Date: Mon Oct 20 00:41:09 2008 Subject: [sldev] Anybody still getting JIRA-notify e-mails? In-Reply-To: <9bb32d430810200003k194a70d1wfd6aca08d6db6d5@mail.gmail.com> References: <9bb32d430810200003k194a70d1wfd6aca08d6db6d5@mail.gmail.com> Message-ID: <48FC3613.3020502@lindenlab.com> Looks broken. I've flagged the problem, and will follow up tomorrow. Thanks for the heads up! Rob On 10/20/2008 12:03 AM, Ambrosia wrote: > Greetings! > > Is anybody still getting mails from jira-notify? > > My last one is from the 18th, and weekends usually are the most busy > time when it comes to JIRA. > > Something seems b0rked here. > > --Chalice Yao > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges > From AndromedaQuonset at comcast.net Mon Oct 20 10:20:43 2008 From: AndromedaQuonset at comcast.net (Andromeda Quonset) Date: Mon Oct 20 10:20:52 2008 Subject: [sldev] Anybody still getting JIRA-notify e-mails? In-Reply-To: <9bb32d430810200003k194a70d1wfd6aca08d6db6d5@mail.gmail.com > References: <9bb32d430810200003k194a70d1wfd6aca08d6db6d5@mail.gmail.com> Message-ID: <20081020172050.5DCD441B27D@stupor.lindenlab.com> I've had 2 emails from Jira this morning. Neither one explicitly says it is from jira-notify. One is from a Linden, and the other one is from lindenrobot. At 01:03 AM 10/20/2008, you wrote: >Greetings! > >Is anybody still getting mails from jira-notify? > >My last one is from the 18th, and weekends usually are the most busy >time when it comes to JIRA. > >Something seems b0rked here. > >--Chalice Yao From TammyNowotny at mac.com Mon Oct 20 10:47:51 2008 From: TammyNowotny at mac.com (Tammy Nowotny) Date: Mon Oct 20 10:48:05 2008 Subject: [sldev] Anybody still getting JIRA-notify e-mails? In-Reply-To: <20081020172050.5DCD441B27D@stupor.lindenlab.com> References: <9bb32d430810200003k194a70d1wfd6aca08d6db6d5@mail.gmail.com> <20081020172050.5DCD441B27D@stupor.lindenlab.com> Message-ID: <48FCC447.2060504@mac.com> I am getting some... I don't know if it'a complete set of email updates, but I do get them, Perhaps your spam filter is mistakenly catching these messages, Chalice? Andromeda Quonset wrote: > I've had 2 emails from Jira this morning. Neither one explicitly says > it is from jira-notify. > > One is from a Linden, and the other one is from lindenrobot. > > At 01:03 AM 10/20/2008, you wrote: >> Greetings! >> >> Is anybody still getting mails from jira-notify? >> >> My last one is from the 18th, and weekends usually are the most busy >> time when it comes to JIRA. >> >> Something seems b0rked here. >> >> --Chalice Yao > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > From dnbyena at gmail.com Mon Oct 20 10:58:14 2008 From: dnbyena at gmail.com (Khyota) Date: Mon Oct 20 10:58:19 2008 Subject: [sldev] Anybody still getting JIRA-notify e-mails? In-Reply-To: <48FCC447.2060504@mac.com> References: <9bb32d430810200003k194a70d1wfd6aca08d6db6d5@mail.gmail.com> <20081020172050.5DCD441B27D@stupor.lindenlab.com> <48FCC447.2060504@mac.com> Message-ID: <200810201358.14638.dnbyena@gmail.com> On Monday 20 October 2008 01:47:51 pm Tammy Nowotny wrote: > I am getting some... I don't know if it'a complete set of email > updates, but I do get them, > > Perhaps your spam filter is mistakenly catching these messages, Chalice? > > Andromeda Quonset wrote: > > I've had 2 emails from Jira this morning. Neither one explicitly says > > it is from jira-notify. > > > > One is from a Linden, and the other one is from lindenrobot. > > > > At 01:03 AM 10/20/2008, you wrote: > >> Greetings! > >> > >> Is anybody still getting mails from jira-notify? > >> > >> My last one is from the 18th, and weekends usually are the most busy > >> time when it comes to JIRA. > >> > >> Something seems b0rked here. > >> > >> --Chalice Yao > > > > _______________________________________________ > > Policies and (un)subscribe information available here: > > http://wiki.secondlife.com/wiki/SLDev > > Please read the policies before posting to keep unmoderated posting > > privileges > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges IM getin lots, like 5 every 10 mins. From robla at lindenlab.com Mon Oct 20 11:01:39 2008 From: robla at lindenlab.com (Rob Lanphier) Date: Mon Oct 20 11:01:46 2008 Subject: [sldev] Anybody still getting JIRA-notify e-mails? In-Reply-To: <48FCC447.2060504@mac.com> References: <9bb32d430810200003k194a70d1wfd6aca08d6db6d5@mail.gmail.com><20081020172050.5DCD441B27D@stupor.lindenlab.com> <48FCC447.2060504@mac.com> Message-ID: <48FCC783.3020206@lindenlab.com> The jira-notify mailing list was broken, but fixed early this morning. The problem was specifically with the jira-notify mailing list, which gets notified upon every single change in public issues on jira.secondlife.com: https://lists.secondlife.com/cgi-bin/mailman/listinfo/jira-notify It's a pretty high volume list normally. Watchlists and other individual mails were unaffected by this problem. Rob On 10/20/08 10:47 AM, Tammy Nowotny wrote: > I am getting some... I don't know if it'a complete set of email > updates, but I do get them, > > Perhaps your spam filter is mistakenly catching these messages, Chalice? > > Andromeda Quonset wrote: >> I've had 2 emails from Jira this morning. Neither one explicitly >> says it is from jira-notify. >> >> One is from a Linden, and the other one is from lindenrobot. >> >> At 01:03 AM 10/20/2008, you wrote: >>> Greetings! >>> >>> Is anybody still getting mails from jira-notify? >>> >>> My last one is from the 18th, and weekends usually are the most busy >>> time when it comes to JIRA. >>> >>> Something seems b0rked here. >>> >>> --Chalice Yao >> >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/SLDev >> Please read the policies before posting to keep unmoderated posting >> privileges >> > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges From whump at lindenlab.com Mon Oct 20 18:06:42 2008 From: whump at lindenlab.com (Bill Humphries) Date: Mon Oct 20 18:06:45 2008 Subject: [sldev] [Urgent] Agent Domain Outage Message-ID: <951C9E92-8675-4743-BF05-C10353247204@lindenlab.com> Sorry for the inconvenience. Due to complications, the OGP Beta will be temporarily offline until tomorrow, October 20th. -- whump From darien.caldwell at gmail.com Tue Oct 21 00:23:24 2008 From: darien.caldwell at gmail.com (Darien Caldwell) Date: Tue Oct 21 00:23:27 2008 Subject: [sldev] Anybody still getting JIRA-notify e-mails? In-Reply-To: <48FCC783.3020206@lindenlab.com> References: <9bb32d430810200003k194a70d1wfd6aca08d6db6d5@mail.gmail.com> <20081020172050.5DCD441B27D@stupor.lindenlab.com> <48FCC447.2060504@mac.com> <48FCC783.3020206@lindenlab.com> Message-ID: <835a5b860810210023v50fe407asd47b21f9f3493555@mail.gmail.com> thanks, I thought something was up. On 10/20/08, Rob Lanphier wrote: > The jira-notify mailing list was broken, but fixed early this morning. > The problem was specifically with the jira-notify mailing list, which > gets notified upon every single change in public issues on > jira.secondlife.com: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/jira-notify > > It's a pretty high volume list normally. > > Watchlists and other individual mails were unaffected by this problem. > > Rob > > On 10/20/08 10:47 AM, Tammy Nowotny wrote: >> I am getting some... I don't know if it'a complete set of email >> updates, but I do get them, >> >> Perhaps your spam filter is mistakenly catching these messages, Chalice? >> >> Andromeda Quonset wrote: >>> I've had 2 emails from Jira this morning. Neither one explicitly >>> says it is from jira-notify. >>> >>> One is from a Linden, and the other one is from lindenrobot. >>> >>> At 01:03 AM 10/20/2008, you wrote: >>>> Greetings! >>>> >>>> Is anybody still getting mails from jira-notify? >>>> >>>> My last one is from the 18th, and weekends usually are the most busy >>>> time when it comes to JIRA. >>>> >>>> Something seems b0rked here. >>>> >>>> --Chalice Yao >>> >>> _______________________________________________ >>> Policies and (un)subscribe information available here: >>> http://wiki.secondlife.com/wiki/SLDev >>> Please read the policies before posting to keep unmoderated posting >>> privileges >>> >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/SLDev >> Please read the policies before posting to keep unmoderated posting >> privileges > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > From alissa_sabre at yahoo.co.jp Tue Oct 21 02:13:12 2008 From: alissa_sabre at yahoo.co.jp (Alissa Sabre) Date: Tue Oct 21 04:53:39 2008 Subject: [sldev] develop.py --standalone script issues In-Reply-To: References: Message-ID: <9odsJe04kwneb4G37ds4e14c.alissa_sabre@yahoo.co.jp> > > Here are a couple issues that Soft suggested i mention here concerning > > develop.py script. > Specifically, help would be appreciated since these are with > --standalone builds. We very rarely do these as Lindens since we're > generally focused on the version we package. Patches or specific > pointers would likely see these fixed months sooner. Soft made a similar suggestion to me, so I'm writing this. http://jira.secondlife.com/browse/VWR-9557 My issue is: when I go a standalone build on a Fedora 9 x86 box with NVIDIA graphics driver installed, the build fails. The particular cause of failure is: llrender.cpp:115: error: 'glActiveTextureARB' was not declared in this scope Quick analysis showed: - Installing NVIDIA graphics driver replaces Fedora supplied GL/gl.h and GL/glext.h with NVIDIA's own. - A declaration of the function glActiveTextureARB is included in NVIDIA's header files, but in a slightly different way, that makes the build to fail. See my JIRA filings for more details. Declaring the function glActiveTextureARB in an SL header file, e.g., llrender/llglheaders.h suppresses the error. I'm not sure it is the way to go. For the moment, my workaround is not to go standalone build. Any ideas? Alissa Sabre -------------------------------------- Enjoy MLB with MAJOR.JP! Ichiro, Matsuzaka, Matsui, and more! http://pr.mail.yahoo.co.jp/mlb/ From robin.cornelius at gmail.com Tue Oct 21 05:19:20 2008 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Tue Oct 21 05:19:24 2008 Subject: [sldev] develop.py --standalone script issues In-Reply-To: <9odsJe04kwneb4G37ds4e14c.alissa_sabre@yahoo.co.jp> References: <9odsJe04kwneb4G37ds4e14c.alissa_sabre@yahoo.co.jp> Message-ID: On Tue, Oct 21, 2008 at 10:13 AM, Alissa Sabre wrote: > Soft made a similar suggestion to me, so I'm writing this. > > http://jira.secondlife.com/browse/VWR-9557 > > My issue is: when I go a standalone build on a Fedora 9 x86 box with > NVIDIA graphics driver installed, the build fails. The particular > cause of failure is: > How are you installing the nvidia driver? using a package from your distro or using the nvidia binary installer? If you are using the Nvidia binary installer there is a command line option to suppress the install of nvidia's version of the gl*.h header files which prevents it trashing mesa's. If you reinstall mess-common-dev (on debian anyway, guess Fedora has a similar package) it puts the correct gl.h file back in place that has the required defines. I pretty much do this every time i upgrade the Nvidia driver and then have to reinstall mesa-dev my self as i always forget to use the command option to stop header install. Regards Robin From dnbyena at gmail.com Tue Oct 21 09:28:41 2008 From: dnbyena at gmail.com (Khyota) Date: Tue Oct 21 09:28:48 2008 Subject: [sldev] Source code in the wrong language? Message-ID: <200810211228.42050.dnbyena@gmail.com> In http://jira.secondlife.com/browse/VWR-9985 we have someone crashing when he tries to save his gesture, this is in the japenesse translation of the viewer. His error is 2008-10-21T13:17:12Z newview/llpreviewgesture.cpp(1630) : error 2008-10-21T13:17:12Z ERROR: addStep: Unknown step type: ???? could there be mixed languages in the source code? O.o From mumismo at gmail.com Tue Oct 21 09:50:59 2008 From: mumismo at gmail.com (Jordi Polo) Date: Tue Oct 21 09:51:03 2008 Subject: [sldev] Source code in the wrong language? In-Reply-To: <200810211228.42050.dnbyena@gmail.com> References: <200810211228.42050.dnbyena@gmail.com> Message-ID: For the record, ???? is a transliteration for "sound" Isn't it just something a user saved with that name? On Wed, Oct 22, 2008 at 1:28 AM, Khyota wrote: > > In http://jira.secondlife.com/browse/VWR-9985 we have someone crashing > when he > tries to save his gesture, this is in the japenesse translation of the > viewer. > > His error is > > 2008-10-21T13:17:12Z newview/llpreviewgesture.cpp(1630) : error > 2008-10-21T13:17:12Z ERROR: addStep: Unknown step type: ???? > > could there be mixed languages in the source code? O.o > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > -- Jordi Polo Carres NLP laboratory - NAIST http://www.bahasara.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20081022/ad30b482/attachment.htm From soft at lindenlab.com Tue Oct 21 09:57:27 2008 From: soft at lindenlab.com (Soft) Date: Tue Oct 21 09:57:31 2008 Subject: [sldev] Source code in the wrong language? In-Reply-To: References: <200810211228.42050.dnbyena@gmail.com> Message-ID: "Sound" "Step" "Wait", etc are labels for various components of a gesture. These shouldn't be getting translated. It's possible that there's an unwanted translation lookup in the viewer that snuck in as part of a viewer translation process. 2008/10/21 Jordi Polo : > > For the record, ???? is a transliteration for "sound" > Isn't it just something a user saved with that name? > > > On Wed, Oct 22, 2008 at 1:28 AM, Khyota wrote: >> >> In http://jira.secondlife.com/browse/VWR-9985 we have someone crashing >> when he >> tries to save his gesture, this is in the japenesse translation of the >> viewer. >> >> His error is >> >> 2008-10-21T13:17:12Z newview/llpreviewgesture.cpp(1630) : error >> 2008-10-21T13:17:12Z ERROR: addStep: Unknown step type: ???? >> >> could there be mixed languages in the source code? O.o >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/SLDev >> Please read the policies before posting to keep unmoderated posting >> privileges > > > > -- > Jordi Polo Carres > NLP laboratory - NAIST > http://www.bahasara.org > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > From soft at lindenlab.com Tue Oct 21 10:32:32 2008 From: soft at lindenlab.com (Soft) Date: Tue Oct 21 10:32:35 2008 Subject: [sldev] Source code in the wrong language? In-Reply-To: References: <200810211228.42050.dnbyena@gmail.com> Message-ID: Bagh. The viewer has hard-coded copies of strings which it compares against ones in a list that gets translated. I'll change this to use the list index position, rather than the literal string. 2008/10/21 Soft : > "Sound" "Step" "Wait", etc are labels for various components of a > gesture. These shouldn't be getting translated. It's possible that > there's an unwanted translation lookup in the viewer that snuck in as > part of a viewer translation process. > > 2008/10/21 Jordi Polo : >> >> For the record, ???? is a transliteration for "sound" >> Isn't it just something a user saved with that name? >> >> >> On Wed, Oct 22, 2008 at 1:28 AM, Khyota wrote: >>> >>> In http://jira.secondlife.com/browse/VWR-9985 we have someone crashing >>> when he >>> tries to save his gesture, this is in the japenesse translation of the >>> viewer. >>> >>> His error is >>> >>> 2008-10-21T13:17:12Z newview/llpreviewgesture.cpp(1630) : error >>> 2008-10-21T13:17:12Z ERROR: addStep: Unknown step type: ???? >>> >>> could there be mixed languages in the source code? O.o >>> _______________________________________________ >>> Policies and (un)subscribe information available here: >>> http://wiki.secondlife.com/wiki/SLDev >>> Please read the policies before posting to keep unmoderated posting >>> privileges >> >> >> >> -- >> Jordi Polo Carres >> NLP laboratory - NAIST >> http://www.bahasara.org >> >> >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/SLDev >> Please read the policies before posting to keep unmoderated posting >> privileges >> > From dnbyena at gmail.com Tue Oct 21 10:41:59 2008 From: dnbyena at gmail.com (Khyota) Date: Tue Oct 21 10:42:07 2008 Subject: [sldev] Source code in the wrong language? In-Reply-To: References: <200810211228.42050.dnbyena@gmail.com> Message-ID: <200810211341.59126.dnbyena@gmail.com> On Tuesday 21 October 2008 01:32:32 pm Soft wrote: > Bagh. The viewer has hard-coded copies of strings which it compares > against ones in a list that gets translated. I'll change this to use > the list index position, rather than the literal string. Good job Soft! ^_^ From richard at lindenlab.com Tue Oct 21 11:46:47 2008 From: richard at lindenlab.com (Richard Nelson) Date: Tue Oct 21 11:46:50 2008 Subject: [sldev] Source code in the wrong language? In-Reply-To: References: <200810211228.42050.dnbyena@gmail.com> Message-ID: Currently only the combobox has the ability to distinguish between the name of a selection and the text value of the selection (which will be localized). We need to apply this uniformly to scroll_list widgets as well. Meanwhile, using an index will suffice. R. On Tue, 21 Oct 2008 10:32:32 -0700, Soft wrote: > Bagh. The viewer has hard-coded copies of strings which it compares > against ones in a list that gets translated. I'll change this to use > the list index position, rather than the literal string. > > 2008/10/21 Soft : >> "Sound" "Step" "Wait", etc are labels for various components of a >> gesture. These shouldn't be getting translated. It's possible that >> there's an unwanted translation lookup in the viewer that snuck in as >> part of a viewer translation process. >> >> 2008/10/21 Jordi Polo : >>> >>> For the record, ???? is a transliteration for "sound" >>> Isn't it just something a user saved with that name? >>> >>> >>> On Wed, Oct 22, 2008 at 1:28 AM, Khyota wrote: >>>> >>>> In http://jira.secondlife.com/browse/VWR-9985 we have someone crashing >>>> when he >>>> tries to save his gesture, this is in the japenesse translation of the >>>> viewer. >>>> >>>> His error is >>>> >>>> 2008-10-21T13:17:12Z newview/llpreviewgesture.cpp(1630) : error >>>> 2008-10-21T13:17:12Z ERROR: addStep: Unknown step type: ???? >>>> >>>> could there be mixed languages in the source code? O.o >>>> _______________________________________________ >>>> Policies and (un)subscribe information available here: >>>> http://wiki.secondlife.com/wiki/SLDev >>>> Please read the policies before posting to keep unmoderated posting >>>> privileges >>> >>> >>> >>> -- >>> Jordi Polo Carres >>> NLP laboratory - NAIST >>> http://www.bahasara.org >>> >>> >>> _______________________________________________ >>> Policies and (un)subscribe information available here: >>> http://wiki.secondlife.com/wiki/SLDev >>> Please read the policies before posting to keep unmoderated posting >>> privileges >>> >> > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ From dnbyena at gmail.com Tue Oct 21 12:50:45 2008 From: dnbyena at gmail.com (Khyota) Date: Tue Oct 21 12:51:17 2008 Subject: [sldev] Why is framerate so much lower in my viewer builds? Message-ID: <200810211550.46398.dnbyena@gmail.com> Ive tested 6 linux builds already in a controlled setting same postion, same graphics settings res(640x480) no changes in the sim, etc. After all textures are loaded i check the framerate. Im on openSuSE 11.0 x86_64 AMD Athlon 64 3200 Geforce 8400gs I built the (standalone) realease tarball, trunk, and openal branch w/o openal (no audio in any of those) and w openal for audio :) (no mozlib in any) . I also grabed the official release and the build service build from here which im going to call the marvin24, marvin 24 is the older 1.20.17 w Scons, it does not use kdu either. http://download.opensuse.org/repositories/home:/marvin24/openSUSE_11.0 The realease tarball, trunk, and openal w/o openal all acheived around 31-34 fps. Openal w openal slowed down to about 28-30. extra cpu power for audio? But amazingly both the offical release and the marvin24 build ran at 48-50fps! Are there any optimizations that i could be missing? I took a screenshot in the trunk and offical builds with the frame texture and the fps thing whatver its called open just incase anyone can catch something. (fps goes down when i take a snapshot though) -------------- next part -------------- A non-text attachment was scrubbed... Name: trunk.png Type: image/png Size: 314179 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20081021/f152ea36/trunk-0001.png -------------- next part -------------- A non-text attachment was scrubbed... Name: official.png Type: image/png Size: 312803 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20081021/f152ea36/official-0001.png From monkowsk at watson.ibm.com Tue Oct 21 14:07:00 2008 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Tue Oct 21 14:07:26 2008 Subject: [sldev] Why is framerate so much lower in my viewer builds? In-Reply-To: <200810211550.46398.dnbyena@gmail.com> References: <200810211550.46398.dnbyena@gmail.com> Message-ID: <48FE4474.2010207@watson.ibm.com> My first guess would be that you're not compiling optimized since the relative times for the fast timers is the same but the absolute times are quite different. Everything is slower, not just one part of the rendering. Mike Khyota wrote: > Ive tested 6 linux builds already in a controlled setting same postion, same > graphics settings res(640x480) no changes in the sim, etc. After all textures > are loaded i check the framerate. > > Im on openSuSE 11.0 x86_64 AMD Athlon 64 3200 Geforce 8400gs > > I built the (standalone) realease tarball, trunk, and openal branch w/o openal > (no audio in any of those) and w openal for audio :) (no mozlib in any) . I > also grabed the official release and the build service build from > here which im going to call the marvin24, marvin 24 is the older 1.20.17 w > Scons, it does not use kdu either. > > http://download.opensuse.org/repositories/home:/marvin24/openSUSE_11.0 > > The realease tarball, trunk, and openal w/o openal all acheived around 31-34 > fps. Openal w openal slowed down to about 28-30. extra cpu power for audio? > > But amazingly both the offical release and the marvin24 build ran at 48-50fps! > > Are there any optimizations that i could be missing? > > I took a screenshot in the trunk and offical builds with the frame texture and > the fps thing whatver its called open just incase anyone can catch something. > (fps goes down when i take a snapshot though) From grant at lindenlab.com Tue Oct 21 14:28:35 2008 From: grant at lindenlab.com (Grant Linden) Date: Tue Oct 21 14:28:39 2008 Subject: [sldev] RX Office hours - Open UI discussion leading with the the radial (pie) menu Message-ID: <907af5560810211428q7ce47979o31dbd5b1972e9e13@mail.gmail.com> RX Office hours - Open UI discussion leading with the the radial (pie) menu. Thursday October 23rd from 3:00-4:00 PM SLT http://slurl.com/secondlife/Beaumont/148/155/46/?title=Linden%20Village For more news about the RX team and to suggest topics for future RX Office Hours please visit our wiki page: https://wiki.secondlife.com/wiki/Resident_Experience -- Steven Grant (Grant Linden) User Experience Designer Linden Lab | Second Life -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20081021/99e251e2/attachment.htm From alissa_sabre at yahoo.co.jp Tue Oct 21 19:29:16 2008 From: alissa_sabre at yahoo.co.jp (Alissa Sabre) Date: Tue Oct 21 19:29:24 2008 Subject: [sldev] develop.py --standalone script issues In-Reply-To: References: <9odsJe04kwneb4G37ds4e14c.alissa_sabre@yahoo.co.jp> Message-ID: <1eb4ds6e94e15e0dkwif24e.alissa_sabre@yahoo.co.jp> Robin, > > http://jira.secondlife.com/browse/VWR-9557 > > > > My issue is: when I go a standalone build on a Fedora 9 x86 box with > > NVIDIA graphics driver installed, the build fails. The particular > > cause of failure is: > How are you installing the nvidia driver? using a package from your > distro or using the nvidia binary installer? NVIDIA binary installer, because Fedora doesn't provide one. > If you are using the Nvidia binary installer there is a command line > option to suppress the install of nvidia's version of the gl*.h header > files which prevents it trashing mesa's. If you reinstall > mess-common-dev (on debian anyway, guess Fedora has a similar package) > it puts the correct gl.h file back in place that has the required > defines. Thank you, Robin. You are right. The particular option for NVIDIA binary installer is "--no-opengl-headers", and the package name for GL header files in Fedora is "mesa-libGL-devel". Re-installing mesa-libGL-devel package through yum and re-installing NVIDIA driver with --no-opengl-headers option solved the issue. # I'm having other issues and have not yet built successfully, but it's aother story. Thank you again, Alissa -------------------------------------- Enjoy MLB with MAJOR.JP! Ichiro, Matsuzaka, Matsui, and more! http://pr.mail.yahoo.co.jp/mlb/ From alissa_sabre at yahoo.co.jp Tue Oct 21 19:47:29 2008 From: alissa_sabre at yahoo.co.jp (Alissa Sabre) Date: Tue Oct 21 19:47:38 2008 Subject: [sldev] strange behaviour of cmake on Windows Message-ID: <1dscds4ts4fu4t7nsf2ds7kw.alissa_sabre@yahoo.co.jp> I'm having a build problem on Windows. I'm working on 1.21.6 using Visual C++ Express 2005 on Windows XP. When I run develop.py with -GVC80 after modifying develop.py as suggested in Victor's mail ( https://lists.secondlife.com/pipermail/sldev/2008-September/011628.html ), I got a series of similar error messages from cmake. The first one is: CMake Error at CMakeLists.txt:34 (add_subdirectory): add_subdirectory not given a binary directory but the given source directory "C:/alissa/dev/1.21.6/linden/indra/llcharacter" is not a subdirectory of "c:/alissa/Dev/1.21.6/linden/indra". When specifying an out-of-tree source a binary directory must be explicitly specified. The strange thing is that, the first directory C:/alissa/dev/1.21.6/linden/indra/llcharacter is surely a subdirectory of c:/alissa/Dev/1.21.6/linden/indra where CMake says it isn't. I'm afraid that the case differences in the path components (i.e., "c:" vs "C:" and "/Dev/" vs "/dev/") and cmake simply goes mad with it, but I don't even know why cmake understood the same upper directory path differently. How can I solve this? Any clue is appreciated. Alissa Sabre -------------------------------------- Enjoy MLB with MAJOR.JP! Ichiro, Matsuzaka, Matsui, and more! http://pr.mail.yahoo.co.jp/mlb/ From lenglish5 at cox.net Tue Oct 21 22:44:06 2008 From: lenglish5 at cox.net (Lawson English) Date: Tue Oct 21 22:44:08 2008 Subject: [sldev] Why is framerate so much lower in my viewer builds? In-Reply-To: <200810211550.46398.dnbyena@gmail.com> References: <200810211550.46398.dnbyena@gmail.com> Message-ID: <48FEBDA6.1070403@cox.net> Khyota wrote: > Ive tested 6 linux builds already in a controlled setting same postion, same > graphics settings res(640x480) no changes in the sim, etc. After all textures > are loaded i check the framerate. > > Im on openSuSE 11.0 x86_64 AMD Athlon 64 3200 Geforce 8400gs > > I built the (standalone) realease tarball, trunk, and openal branch w/o openal > (no audio in any of those) and w openal for audio :) (no mozlib in any) . I > also grabed the official release and the build service build from > here which im going to call the marvin24, marvin 24 is the older 1.20.17 w > Scons, it does not use kdu either. > > http://download.opensuse.org/repositories/home:/marvin24/openSUSE_11.0 > > The realease tarball, trunk, and openal w/o openal all acheived around 31-34 > fps. Openal w openal slowed down to about 28-30. extra cpu power for audio? > > But amazingly both the offical release and the marvin24 build ran at 48-50fps! > > Are there any optimizations that i could be missing? > > I took a screenshot in the trunk and offical builds with the frame texture and > the fps thing whatver its called open just incase anyone can catch something. > (fps goes down when i take a snapshot though) > I believe there are commercial versions of the open source libs that are more efficient, that LL distributes with the standalone viewer. Some people grab those libs and replace the open source versions the final build and report higher framerates, IIRC Lawson From vector at leafpile.com Tue Oct 21 23:32:41 2008 From: vector at leafpile.com (Vector Hastings) Date: Tue Oct 21 23:32:33 2008 Subject: [sldev] Trying to turn off those script swirl lights Message-ID: I'm trying to turn off those script swirl lights. I keep focusing on llhudeffecttrail.cpp and llhudeffectbeam.cpp, but I can't seem to isolate the place where it having a script in a prim activate causes rendering of those spherical or spiraling particles. I'd like to create a switch to turn it off (like you can turn off the selection beam with "ShowSelectionBeam") so that machinimators can film scripted props without getting those swirling lights in the picture. Any experience or guidance on where the body is buried would be a big help. Thanks, Vector Hastings From sldev at free.fr Wed Oct 22 00:10:32 2008 From: sldev at free.fr (Henri Beauchamp) Date: Wed Oct 22 00:10:35 2008 Subject: [sldev] Trying to turn off those script swirl lights In-Reply-To: References: Message-ID: <20081022091032.030eb6a0.sldev@free.fr> On Tue, 21 Oct 2008 23:32:41 -0700, Vector Hastings wrote: > I'm trying to turn off those script swirl lights. > > I keep focusing on llhudeffecttrail.cpp and llhudeffectbeam.cpp, but I can't > seem to isolate the place where it having a script in a prim activate causes > rendering of those spherical or spiraling particles. > > I'd like to create a switch to turn it off (like you can turn off the > selection beam with "ShowSelectionBeam") so that machinimators can film > scripted props without getting those swirling lights in the picture. > > Any experience or guidance on where the body is buried would be a big help. The involved code is in indra/newview/llviewermessage.cpp in function process_chat_from_simulator() (search for the "// Make swirly things only for talking objects" comment). Henri. From chaosstar at gmail.com Wed Oct 22 00:38:11 2008 From: chaosstar at gmail.com (Ambrosia) Date: Wed Oct 22 00:38:16 2008 Subject: [sldev] strange behaviour of cmake on Windows In-Reply-To: <1dscds4ts4fu4t7nsf2ds7kw.alissa_sabre@yahoo.co.jp> References: <1dscds4ts4fu4t7nsf2ds7kw.alissa_sabre@yahoo.co.jp> Message-ID: <9bb32d430810220038wf1a3ac2s14aaf17bbdb6caa3@mail.gmail.com> You'll notice that one path says 'dev' while the other says 'Dev'. Call it a hunch, but I think cmake, even under windows, is probably case sensitive. On Wed, Oct 22, 2008 at 04:47, Alissa Sabre wrote: > I'm having a build problem on Windows. > > I'm working on 1.21.6 using Visual C++ Express 2005 on Windows XP. > > When I run develop.py with -GVC80 after modifying develop.py as > suggested in Victor's mail ( > https://lists.secondlife.com/pipermail/sldev/2008-September/011628.html ), > I got a series of similar error messages from cmake. The first one is: > > CMake Error at CMakeLists.txt:34 (add_subdirectory): > add_subdirectory not given a binary directory but the given source > directory "C:/alissa/dev/1.21.6/linden/indra/llcharacter" is not a > subdirectory of "c:/alissa/Dev/1.21.6/linden/indra". When specifying an > out-of-tree source a binary directory must be explicitly specified. > > The strange thing is that, the first directory > > C:/alissa/dev/1.21.6/linden/indra/llcharacter > > is surely a subdirectory of > > c:/alissa/Dev/1.21.6/linden/indra > > where CMake says it isn't. I'm afraid that the case differences > in the path components (i.e., "c:" vs "C:" and "/Dev/" vs "/dev/") and > cmake simply goes mad with it, but I don't even know why cmake > understood the same upper directory path differently. > > How can I solve this? Any clue is appreciated. > > Alissa Sabre > > > > -------------------------------------- > Enjoy MLB with MAJOR.JP! Ichiro, Matsuzaka, Matsui, and more! > http://pr.mail.yahoo.co.jp/mlb/ > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges > From chaosstar at gmail.com Wed Oct 22 00:40:18 2008 From: chaosstar at gmail.com (Ambrosia) Date: Wed Oct 22 00:40:23 2008 Subject: [sldev] Why is framerate so much lower in my viewer builds? In-Reply-To: <48FEBDA6.1070403@cox.net> References: <200810211550.46398.dnbyena@gmail.com> <48FEBDA6.1070403@cox.net> Message-ID: <9bb32d430810220040i7d5a8c7fr5fd996252ffff720@mail.gmail.com> The big lib that tends to get put in from the LL-releases that boosts performance is lldku.dll (and/or whatever the Linux version uses. lldku.so?). Just copy that one into your viewer's main folder and try again. We can only hope that one day libjpeg will be on par in speed. On Wed, Oct 22, 2008 at 07:44, Lawson English wrote: > Khyota wrote: >> >> Ive tested 6 linux builds already in a controlled setting same postion, >> same graphics settings res(640x480) no changes in the sim, etc. After all >> textures are loaded i check the framerate. >> >> Im on openSuSE 11.0 x86_64 AMD Athlon 64 3200 Geforce 8400gs >> >> I built the (standalone) realease tarball, trunk, and openal branch w/o >> openal (no audio in any of those) and w openal for audio :) (no mozlib in >> any) . I also grabed the official release and the build service build from >> here which im going to call the marvin24, marvin 24 is the older 1.20.17 w >> Scons, it does not use kdu either. >> >> http://download.opensuse.org/repositories/home:/marvin24/openSUSE_11.0 >> >> The realease tarball, trunk, and openal w/o openal all acheived around >> 31-34 fps. Openal w openal slowed down to about 28-30. extra cpu power for >> audio? >> >> But amazingly both the offical release and the marvin24 build ran at >> 48-50fps! >> Are there any optimizations that i could be missing? >> >> I took a screenshot in the trunk and offical builds with the frame texture >> and the fps thing whatver its called open just incase anyone can catch >> something. (fps goes down when i take a snapshot though) >> > > I believe there are commercial versions of the open source libs that are > more efficient, that LL distributes > with the standalone viewer. Some people grab those libs and replace the open > source versions the final build > and report higher framerates, IIRC > > Lawson > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > From sldev at free.fr Wed Oct 22 00:52:51 2008 From: sldev at free.fr (Henri Beauchamp) Date: Wed Oct 22 00:52:55 2008 Subject: [sldev] Why is framerate so much lower in my viewer builds? In-Reply-To: <9bb32d430810220040i7d5a8c7fr5fd996252ffff720@mail.gmail.com> References: <200810211550.46398.dnbyena@gmail.com> <48FEBDA6.1070403@cox.net> <9bb32d430810220040i7d5a8c7fr5fd996252ffff720@mail.gmail.com> Message-ID: <20081022095251.53c93abe.sldev@free.fr> On Wed, 22 Oct 2008 09:40:18 +0200, Ambrosia wrote: > The big lib that tends to get put in from the LL-releases that boosts > performance is lldku.dll (and/or whatever the Linux version uses. > lldku.so?). Just copy that one into your viewer's main folder and try > again. We can only hope that one day libjpeg will be on par in speed. Actually, to use Kakadu under linux, you need to copy both libkdu_v42R.so and libllkdu.so. The former goes into the lib/ directory and the later in the bin/ directory. > Khyota wrote: >> >> Ive tested 6 linux builds already in a controlled setting same postion, >> same graphics settings res(640x480) no changes in the sim, etc. After all >> textures are loaded i check the framerate. >> >> Im on openSuSE 11.0 x86_64 AMD Athlon 64 3200 Geforce 8400gs >> >> I built the (standalone) realease tarball, trunk, and openal branch w/o >> openal (no audio in any of those) and w openal for audio :) (no mozlib in >> any) . I also grabed the official release and the build service build from >> here which im going to call the marvin24, marvin 24 is the older 1.20.17 w >> Scons, it does not use kdu either. >> >> http://download.opensuse.org/repositories/home:/marvin24/openSUSE_11.0 >> >> The realease tarball, trunk, and openal w/o openal all acheived around >> 31-34 fps. Openal w openal slowed down to about 28-30. extra cpu power for >> audio? >> >> But amazingly both the offical release and the marvin24 build ran at >> 48-50fps! >> Are there any optimizations that i could be missing? You can have a look at what optimizations I use for the Cool SL Viewer by checking the make-SL and cmake-SL scripts I use to compile it: http://sldev.free.fr/make-SL (for v1.20 and older viewers) http://sldev.free.fr/cmake-SL (for v1.21 and later viewers). Henri. From dnbyena at gmail.com Wed Oct 22 04:39:06 2008 From: dnbyena at gmail.com (Khyota) Date: Wed Oct 22 04:39:13 2008 Subject: [sldev] Why is framerate so much lower in my viewer builds? In-Reply-To: <48FE4474.2010207@watson.ibm.com> References: <200810211550.46398.dnbyena@gmail.com> <48FE4474.2010207@watson.ibm.com> Message-ID: <200810220739.06491.dnbyena@gmail.com> On Tuesday 21 October 2008 05:07:00 pm Mike Monkowski wrote: > My first guess would be that you're not compiling optimized since the > relative times for the fast timers is the same but the absolute times > are quite different. Everything is slower, not just one part of the > rendering. > > Mike > > Khyota wrote: > > Ive tested 6 linux builds already in a controlled setting same postion, > > same graphics settings res(640x480) no changes in the sim, etc. After all > > textures are loaded i check the framerate. > > > > Im on openSuSE 11.0 x86_64 AMD Athlon 64 3200 Geforce 8400gs > > > > I built the (standalone) realease tarball, trunk, and openal branch w/o > > openal (no audio in any of those) and w openal for audio :) (no mozlib in > > any) . I also grabed the official release and the build service build > > from here which im going to call the marvin24, marvin 24 is the older > > 1.20.17 w Scons, it does not use kdu either. > > > > http://download.opensuse.org/repositories/home:/marvin24/openSUSE_11.0 > > > > The realease tarball, trunk, and openal w/o openal all acheived around > > 31-34 fps. Openal w openal slowed down to about 28-30. extra cpu power > > for audio? > > > > But amazingly both the offical release and the marvin24 build ran at > > 48-50fps! > > > > Are there any optimizations that i could be missing? > > > > I took a screenshot in the trunk and offical builds with the frame > > texture and the fps thing whatver its called open just incase anyone can > > catch something. (fps goes down when i take a snapshot though) Thanks everyone for your reply, Mike was correct and i have been building with 0 optimiziation. Mistaked that the deb in Relwithdebinfo meant debian not debug. The develop.py scriopt does that by default, and Relwithdebinfo uses O0, however Release uses O2.Now ive got a build running as fast as it should. btw I wanted to be sure Kdu was not the reason for bad perfomance so i waited until all textures were decoded before recording the framerate :) From alissa_sabre at yahoo.co.jp Wed Oct 22 03:20:45 2008 From: alissa_sabre at yahoo.co.jp (Alissa Sabre) Date: Wed Oct 22 04:46:10 2008 Subject: [sldev] A question regarding GL texture mapping in LLFontGL Message-ID: <1dx4dt4kwtds86xz0sQhkJk1.alissa_sabre@yahoo.co.jp> I have a question. In function LLFontGL::render in a viewer source llrender/llfontgl.cpp, there is a misterious code. On around line 820-830, there are codes to show a character glyph bitmap on the screen by drawing a rectangle (GL_QUAD) with the character glyph bitmap as a texture. What I don't understand is the purpose of PAD_AMT. In the code, the source bitmap and the target screen are carefully pixel aligned (i.e., the coverage of a single texel of the texture and the coverage of a single fragment on the window are exactly matched.) So, I think drawing a rectangle that has an exact size as the glyph is enough. However, the LL written code draws slightly large rectangle. A magic constant PAD_AMT is 0.5f, and the code draws a rectangle with 0.5 pixels larger in all four edges. Texture coordinates are also enlarged 0.5 texels in a same way... The actual texture is prepared as one pixel larger in four edges for the purpose, and that margin pixels are filled with a full transparency (alpha = 0.0). The min and max texture filters are set to GL_NEAREST, so there are no mixture of colors from surrounding texels, Well, I see this code has nothing bad. It works totally fine. But, why? Why we need to do this? I modified the code so taht PAD_AMT to be 0.0, rebuild the viewer, and run it. I saw no difference at all. Two possible reasons came to my mind: One possibility is a workaround for a broken GL implementation (bad texture unit.) There might be a broken GL that mistakenly interpolates nearby texels or samples texture bitmap at a wrong position, and LL dev tried to eliminate garbages on that particular graphic card. Another possibility is that the code is a historic remnant. In LLFontGL::render, I see several commented-out codes that tried subpixel alignment of the character glyph images. I can imagine that in an older versions, LLFontGL::render tried to draw rectangles at non integral coordinates, using some interpolation (probably GL_LINEAR). Of course, I may be wrong and the real purpose of PAD_AMT is totally different. Should we keep it? May I remove it? Comments? Alissa Sabre -------------------------------------- Enjoy MLB with MAJOR.JP! Ichiro, Matsuzaka, Matsui, and more! http://pr.mail.yahoo.co.jp/mlb/ From thordain at thordain.com Wed Oct 22 05:58:31 2008 From: thordain at thordain.com (Thordain Curtis) Date: Wed Oct 22 05:58:35 2008 Subject: [sldev] A question regarding GL texture mapping in LLFontGL In-Reply-To: <1dx4dt4kwtds86xz0sQhkJk1.alissa_sabre@yahoo.co.jp> References: <1dx4dt4kwtds86xz0sQhkJk1.alissa_sabre@yahoo.co.jp> Message-ID: If I recall correctly, when using OpenGL with an orthographic projection corresponding to exact screen size, integer coordinates refer to the corner of a pixel (versus DirectX where integer coordinates refer to the center of a pixel). Drawing at integer coordinates would result in the centers of each texel being aligned to borders of pixels. This may or may not produce rasterization artifacts, but it's generally considered the "right thing to do(tm)" to align the center of each texel to the center of each pixel. Drawing to x + 0.5, y + 0.5 guarantees that this will happen. Removing the padding may not product noticable effects with true type font rendering because the fonts are antialiased so it may "look right". On Wed, Oct 22, 2008 at 6:20 AM, Alissa Sabre wrote: > I have a question. > > In function LLFontGL::render in a viewer source llrender/llfontgl.cpp, > there is a misterious code. On around line 820-830, there are codes > to show a character glyph bitmap on the screen by drawing a rectangle > (GL_QUAD) with the character glyph bitmap as a texture. > > What I don't understand is the purpose of PAD_AMT. > > In the code, the source bitmap and the target screen are carefully > pixel aligned (i.e., the coverage of a single texel of the texture and > the coverage of a single fragment on the window are exactly matched.) > So, I think drawing a rectangle that has an exact size as the glyph is > enough. However, the LL written code draws slightly large rectangle. > > A magic constant PAD_AMT is 0.5f, and the code draws a rectangle with > 0.5 pixels larger in all four edges. Texture coordinates are also > enlarged 0.5 texels in a same way... The actual texture is prepared > as one pixel larger in four edges for the purpose, and that margin > pixels are filled with a full transparency (alpha = 0.0). > > The min and max texture filters are set to GL_NEAREST, so there are no > mixture of colors from surrounding texels, > > Well, I see this code has nothing bad. It works totally fine. But, > why? Why we need to do this? I modified the code so taht PAD_AMT to > be 0.0, rebuild the viewer, and run it. I saw no difference at all. > > Two possible reasons came to my mind: > > One possibility is a workaround for a broken GL implementation (bad > texture unit.) There might be a broken GL that mistakenly > interpolates nearby texels or samples texture bitmap at a wrong > position, and LL dev tried to eliminate garbages on that particular > graphic card. > > Another possibility is that the code is a historic remnant. In > LLFontGL::render, I see several commented-out codes that tried > subpixel alignment of the character glyph images. I can imagine that > in an older versions, LLFontGL::render tried to draw rectangles at non > integral coordinates, using some interpolation (probably GL_LINEAR). > > Of course, I may be wrong and the real purpose of PAD_AMT is totally > different. > > Should we keep it? May I remove it? Comments? > > Alissa Sabre > > > -------------------------------------- > Enjoy MLB with MAJOR.JP! Ichiro, Matsuzaka, Matsui, and more! > http://pr.mail.yahoo.co.jp/mlb/ > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20081022/ca267f57/attachment.htm From soft at lindenlab.com Wed Oct 22 06:12:42 2008 From: soft at lindenlab.com (Soft) Date: Wed Oct 22 06:12:45 2008 Subject: [sldev] Open Source Meeting Thu 2pm Message-ID: Our Thursday open source meetings take place at 2pm. If there is anything you would like on the agenda... have at it! http://wiki.secondlife.com/wiki/Open_Source_Meeting/Agenda From alissa_sabre at yahoo.co.jp Wed Oct 22 06:17:36 2008 From: alissa_sabre at yahoo.co.jp (Alissa Sabre) Date: Wed Oct 22 06:18:22 2008 Subject: [sldev] strange behaviour of cmake on Windows In-Reply-To: <9bb32d430810220038wf1a3ac2s14aaf17bbdb6caa3@mail.gmail.com> References: <9bb32d430810220038wf1a3ac2s14aaf17bbdb6caa3@mail.gmail.com> Message-ID: <1en4s54sP7fx4L2wsQ1kwPf.alissa_sabre@yahoo.co.jp> > You'll notice that one path says 'dev' while the other says 'Dev'. Yes. > Call it a hunch, but I think cmake, even under windows, is probably > case sensitive. I guess so too. I have no idea why so. I just cd to a directory, and ran as "python develop.py -GVC80". So I assume develop.py and/or cmake somehow find full pathname for those two directories in different ways, causing a different path names. If so, it seems a bug of either develop.py or cmake. What should I do then? -------------------------------------- Enjoy MLB with MAJOR.JP! Ichiro, Matsuzaka, Matsui, and more! http://pr.mail.yahoo.co.jp/mlb/ From chaosstar at gmail.com Wed Oct 22 06:22:06 2008 From: chaosstar at gmail.com (Ambrosia) Date: Wed Oct 22 06:22:13 2008 Subject: [sldev] strange behaviour of cmake on Windows In-Reply-To: <1en4s54sP7fx4L2wsQ1kwPf.alissa_sabre@yahoo.co.jp> References: <9bb32d430810220038wf1a3ac2s14aaf17bbdb6caa3@mail.gmail.com> <1en4s54sP7fx4L2wsQ1kwPf.alissa_sabre@yahoo.co.jp> Message-ID: <9bb32d430810220622l2d3dcce5rec93c0af0cc772c2@mail.gmail.com> Well, is the folder, by chance, named 'Dev' on your system? :> Try renaming the actual folder to 'dev', or if that is already the case, to 'Dev' Not quite a fix per se, but perhaps a workaround. I don't know why it happens. I have uppercase letters in my path to my viewer source. On Wed, Oct 22, 2008 at 15:17, Alissa Sabre wrote: >> You'll notice that one path says 'dev' while the other says 'Dev'. > > Yes. > >> Call it a hunch, but I think cmake, even under windows, is probably >> case sensitive. > > I guess so too. > > I have no idea why so. I just cd to a directory, and ran as "python > develop.py -GVC80". So I assume develop.py and/or cmake somehow find > full pathname for those two directories in different ways, causing a > different path names. If so, it seems a bug of either develop.py or > cmake. > > What should I do then? > -------------------------------------- > Enjoy MLB with MAJOR.JP! Ichiro, Matsuzaka, Matsui, and more! > http://pr.mail.yahoo.co.jp/mlb/ > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges > From vector at leafpile.com Wed Oct 22 11:50:34 2008 From: vector at leafpile.com (Vector Hastings) Date: Wed Oct 22 11:50:27 2008 Subject: [sldev] Trying to turn off those script swirl lights In-Reply-To: <20081022091032.030eb6a0.sldev@free.fr> Message-ID: hee, hee, that's awesome! What a comment. And that explains why those lights only come on when it is communicating. Thanks so much Vector -----Original Message----- From: sldev-bounces@lists.secondlife.com [mailto:sldev-bounces@lists.secondlife.com]On Behalf Of Henri Beauchamp Sent: Wednesday, October 22, 2008 12:11 AM To: sldev@lists.secondlife.com Subject: Re: [sldev] Trying to turn off those script swirl lights On Tue, 21 Oct 2008 23:32:41 -0700, Vector Hastings wrote: > I'm trying to turn off those script swirl lights. > > I keep focusing on llhudeffecttrail.cpp and llhudeffectbeam.cpp, but I can't > seem to isolate the place where it having a script in a prim activate causes > rendering of those spherical or spiraling particles. > > I'd like to create a switch to turn it off (like you can turn off the > selection beam with "ShowSelectionBeam") so that machinimators can film > scripted props without getting those swirling lights in the picture. > > Any experience or guidance on where the body is buried would be a big help. The involved code is in indra/newview/llviewermessage.cpp in function process_chat_from_simulator() (search for the "// Make swirly things only for talking objects" comment). Henri. _______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/SLDev Please read the policies before posting to keep unmoderated posting privileges From soft at lindenlab.com Thu Oct 23 15:09:21 2008 From: soft at lindenlab.com (Soft) Date: Thu Oct 23 15:09:24 2008 Subject: [sldev] Linux keyboard shortcuts Message-ID: I'd like to get a final decision on which modifier keys to use with the function or numeric keys for: https://jira.secondlife.com/browse/VWR-2085 This has lingered long enough that we should grab a set and go. Any consensus on which combination to use? From dnbyena at gmail.com Thu Oct 23 16:03:44 2008 From: dnbyena at gmail.com (Cam) Date: Thu Oct 23 16:03:47 2008 Subject: [sldev] Linux keyboard shortcuts In-Reply-To: References: Message-ID: <22c010080810231603o6538ce55l43f8f4f01dcba6ad@mail.gmail.com> I vote for hte Ctrl Shift Fn series, it only involves the change from alt to shift, and i havnet found any conflicts so far. On 10/23/08, Soft wrote: > I'd like to get a final decision on which modifier keys to use with > the function or numeric keys for: > > https://jira.secondlife.com/browse/VWR-2085 > > This has lingered long enough that we should grab a set and go. Any > consensus on which combination to use? > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > From sldev at free.fr Thu Oct 23 17:37:36 2008 From: sldev at free.fr (Henri Beauchamp) Date: Thu Oct 23 17:37:39 2008 Subject: [sldev] Linux keyboard shortcuts In-Reply-To: <22c010080810231603o6538ce55l43f8f4f01dcba6ad@mail.gmail.com> References: <22c010080810231603o6538ce55l43f8f4f01dcba6ad@mail.gmail.com> Message-ID: <20081024023736.4f4aac05.sldev@free.fr> On Thu, 23 Oct 2008 19:03:44 -0400, Cam wrote: > I vote for hte Ctrl Shift Fn series, it only involves the change from > alt to shift, and i havnet found any conflicts so far. Agreed. From dnbyena at gmail.com Thu Oct 23 17:12:19 2008 From: dnbyena at gmail.com (Khyota) Date: Thu Oct 23 22:49:55 2008 Subject: [sldev] Linux keyboard shortcuts moar In-Reply-To: References: Message-ID: <200810232012.19774.dnbyena@gmail.com> On Thursday 23 October 2008 06:09:21 pm Soft wrote: > I'd like to get a final decision on which modifier keys to use with > the function or numeric keys for: > > https://jira.secondlife.com/browse/VWR-2085 > > This has lingered long enough that we should grab a set and go. Any > consensus on which combination to use? > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges Speaking of shortcuts, im having trouble gtting Ctrl Alt Shift = to work, to disable paritcles. Could at be that since shift is pressed it registers as a + instead? From marinekelley at gmail.com Fri Oct 24 00:08:56 2008 From: marinekelley at gmail.com (Marine Kelley) Date: Fri Oct 24 00:09:26 2008 Subject: [sldev] Setting Windlight through Estate parameters Message-ID: <3D0D2F31-0CBE-4D30-B206-B8506B754391@gmail.com> Hello all, Yesterday I have released a new feature to the custom viewer I maintain : the ability to control someone's Windlight settings through a script. This allows a land owner to make the visitor (who is using my viewer and a "relay" attachment) see the place exactly the way they want and not being able to change. I think it was a popular request for the regular SL viewer, is it still worked on ? Of course I reckon it is far more complicated to update the server code to add LSL functions (llSetWindlightParams([]) or such), and update the viewers to compile them and actually make weather change when requested and upon relog, than to merely obey a special chat message like I did. There is certainly a JIRA feature request but I can't access it from here to check. Is there a chance for it to hit release in 1.22 ? Or maybe later ? Marine From soft at lindenlab.com Fri Oct 24 00:23:55 2008 From: soft at lindenlab.com (Soft) Date: Fri Oct 24 00:23:58 2008 Subject: [sldev] Setting Windlight through Estate parameters In-Reply-To: <3D0D2F31-0CBE-4D30-B206-B8506B754391@gmail.com> References: <3D0D2F31-0CBE-4D30-B206-B8506B754391@gmail.com> Message-ID: I believe you want http://jira.secondlife.com/browse/VWR-7677 I'm also linking this to a related internal issue. I don't think it's under active development right now, though. On Fri, Oct 24, 2008 at 2:08 AM, Marine Kelley wrote: > Hello all, > > Yesterday I have released a new feature to the custom viewer I maintain : > the ability to control someone's Windlight settings through a script. This > allows a land owner to make the visitor (who is using my viewer and a > "relay" attachment) see the place exactly the way they want and not being > able to change. > > I think it was a popular request for the regular SL viewer, is it still > worked on ? Of course I reckon it is far more complicated to update the > server code to add LSL functions (llSetWindlightParams([]) or such), and > update the viewers to compile them and actually make weather change when > requested and upon relog, than to merely obey a special chat message like I > did. > > There is certainly a JIRA feature request but I can't access it from here to > check. Is there a chance for it to hit release in 1.22 ? Or maybe later ? > > Marine > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > From tom at streamsense.net Fri Oct 24 00:56:39 2008 From: tom at streamsense.net (Thomas Grimshaw) Date: Fri Oct 24 00:57:16 2008 Subject: [sldev] Setting Windlight through Estate parameters In-Reply-To: References: <3D0D2F31-0CBE-4D30-B206-B8506B754391@gmail.com> Message-ID: <49017FB7.2050601@streamsense.net> Soft wrote: > I believe you want http://jira.secondlife.com/browse/VWR-7677 > > I'm also linking this to a related internal issue. I don't think it's > under active development right now, though. > This seems kinda ludicrous.. i mean the environment settings are rendered useless if they're not settable by the estate owner.. and how hard is it to implement, honestly? A few more protocol messages and a UI adjustment? ~T From marinekelley at gmail.com Fri Oct 24 01:10:46 2008 From: marinekelley at gmail.com (Marine Kelley) Date: Fri Oct 24 01:10:59 2008 Subject: [sldev] Setting Windlight through Estate parameters In-Reply-To: References: <3D0D2F31-0CBE-4D30-B206-B8506B754391@gmail.com> Message-ID: <76EFE53C-1C57-41D6-893A-5200DD4B49C2@gmail.com> That's the one, thank you Soft ! Too bad it is not under development right now, it would make a lot of land owners smile, including myself :) Marine On 24 oct. 08, at 09:23, Soft wrote: > I believe you want http://jira.secondlife.com/browse/VWR-7677 > > I'm also linking this to a related internal issue. I don't think it's > under active development right now, though. > > > On Fri, Oct 24, 2008 at 2:08 AM, Marine Kelley > wrote: >> Hello all, >> >> Yesterday I have released a new feature to the custom viewer I >> maintain : >> the ability to control someone's Windlight settings through a >> script. This >> allows a land owner to make the visitor (who is using my viewer and a >> "relay" attachment) see the place exactly the way they want and not >> being >> able to change. >> >> I think it was a popular request for the regular SL viewer, is it >> still >> worked on ? Of course I reckon it is far more complicated to update >> the >> server code to add LSL functions (llSetWindlightParams([]) or >> such), and >> update the viewers to compile them and actually make weather change >> when >> requested and upon relog, than to merely obey a special chat >> message like I >> did. >> >> There is certainly a JIRA feature request but I can't access it >> from here to >> check. Is there a chance for it to hit release in 1.22 ? Or maybe >> later ? >> >> Marine >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/SLDev >> Please read the policies before posting to keep unmoderated posting >> privileges >> From open at autistici.org Fri Oct 24 04:41:02 2008 From: open at autistici.org (Opensource Obscure) Date: Fri Oct 24 04:41:04 2008 Subject: [sldev] Setting Windlight through Estate parameters In-Reply-To: <49017FB7.2050601@streamsense.net> References: <3D0D2F31-0CBE-4D30-B206-B8506B754391@gmail.com> <49017FB7.2050601@streamsense.net> Message-ID: <4bbdaa050ca38c23d66031935b3d5f47@localhost> On Fri, 24 Oct 2008 08:56:39 +0100, Thomas Grimshaw wrote: > Soft wrote: >> I believe you want http://jira.secondlife.com/browse/VWR-7677 >> >> I'm also linking this to a related internal issue. I don't think it's >> under active development right now, though. >> > This seems kinda ludicrous.. i mean the environment settings are > rendered useless if they're not settable by the estate owner.. and how > hard is it to implement, honestly? A few more protocol messages and a UI > adjustment? I strongly agree. I voted the issue and I'm going spread the word about it. I feel that WindLight is under-valued / under-used because probably many people don't bother with tweaking Environment settings, so they can't even appreciate the effort put in this feature. opensource obscure From gigstaggart at gmail.com Fri Oct 24 08:17:20 2008 From: gigstaggart at gmail.com (Jason Giglio) Date: Fri Oct 24 08:17:24 2008 Subject: [sldev] Setting Windlight through Estate parameters In-Reply-To: <3D0D2F31-0CBE-4D30-B206-B8506B754391@gmail.com> References: <3D0D2F31-0CBE-4D30-B206-B8506B754391@gmail.com> Message-ID: <4901E700.6060806@gmail.com> Marine Kelley wrote: > Hello all, > > Yesterday I have released a new feature to the custom viewer I > maintain : the ability to control someone's Windlight settings through > a script. This allows a land owner to make the visitor (who is using > my viewer and a "relay" attachment) see the place exactly the way they > want and not being able to change. > This is exactly the sort of feature that http://jira.secondlife.com/browse/SVC-550 Was intended for. By setting aside a reserved block of client-exported chat channels for open source use and a reserved block for LL use, these features could transition from community features to Linden features with minimal client side code changes. -Jason -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3266 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20081024/53f5e104/smime-0001.bin From tom at streamsense.net Fri Oct 24 10:04:35 2008 From: tom at streamsense.net (Thomas Grimshaw) Date: Fri Oct 24 10:05:04 2008 Subject: [sldev] Win32 : Process not exiting cleanly Message-ID: <49020023.8030702@streamsense.net> Hey, Are any other windows users experiencing an issue where the client remains memory resident after being closed? It's happening to me on the official release 1.21 on two windows machines, i'd like to confirm that others are experiencing this issue before i start trying to isolate the bug. Thanks ~T From marinekelley at gmail.com Fri Oct 24 11:29:33 2008 From: marinekelley at gmail.com (Marine Kelley) Date: Fri Oct 24 11:29:38 2008 Subject: [sldev] Win32 : Process not exiting cleanly In-Reply-To: <49020023.8030702@streamsense.net> References: <49020023.8030702@streamsense.net> Message-ID: <9e52a8c10810241129r314b20b7ha66131174514d93c@mail.gmail.com> oh yes, almost 50% of the time, and it has been doing that forever 2008/10/24 Thomas Grimshaw > Hey, > > Are any other windows users experiencing an issue where the client remains > memory resident after being closed? > > It's happening to me on the official release 1.21 on two windows machines, > i'd like to confirm that others are experiencing this issue before i start > trying to isolate the bug. > > Thanks > > ~T > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20081024/f63c985f/attachment.htm From carjay at gmx.net Fri Oct 24 11:55:06 2008 From: carjay at gmx.net (Carsten Juttner) Date: Fri Oct 24 11:55:15 2008 Subject: [sldev] Win32 : Process not exiting cleanly In-Reply-To: <49020023.8030702@streamsense.net> References: <49020023.8030702@streamsense.net> Message-ID: <49021A0A.90204@gmx.net> Hello Thomas, Thomas Grimshaw wrote: > Are any other windows users experiencing an issue where the client > remains memory resident after being closed? > > It's happening to me on the official release 1.21 on two windows > machines, i'd like to confirm that others are experiencing this issue > before i start trying to isolate the bug. I never saw this on my win32 test machine but there are several JIRAs about it. See http://jira.secondlife.com/browse/VWR-9577 Carsten From dnbyena at gmail.com Sat Oct 25 19:53:29 2008 From: dnbyena at gmail.com (Khyota) Date: Sat Oct 25 19:53:34 2008 Subject: [sldev] fix for the distortion when zooming out with ctrl 8 bug Message-ID: <200810252253.29497.dnbyena@gmail.com> http://jira.secondlife.com/browse/VWR-5241 Me and Carjay McGinnis worked on this tonight. Zoom out this way changes the field of vision by 20%, the default being 60 degrees. When it starts getting closer to 180 degrees the view gets extremely distorted. The 6th increment puts it at 179.159 and causes a nasty image, the 7th puts it at 180 because thats ware the maximum is set, PI radians. Seeing that the minimum was set for 0.1rad i set the maximum for 0.9*PI rad and it causes no distortion. This was a really simple fix and i hope it can get imported quickly. From alissa_sabre at yahoo.co.jp Sat Oct 25 20:42:42 2008 From: alissa_sabre at yahoo.co.jp (Alissa Sabre) Date: Sat Oct 25 20:42:46 2008 Subject: [sldev] strange behaviour of cmake on Windows In-Reply-To: <9bb32d430810220622l2d3dcce5rec93c0af0cc772c2@mail.gmail.com> References: <9bb32d430810220622l2d3dcce5rec93c0af0cc772c2@mail.gmail.com> <1dscds4ts4fu4t7nsf2ds7kw.alissa_sabre@yahoo.co.jp> Message-ID: <1dsmdY4f24ds4e19es7ds4J.alissa_sabre@yahoo.co.jp> This is a summary and follow up to a thread I began. > I'm having a build problem on Windows. > > I'm working on 1.21.6 using Visual C++ Express 2005 on Windows XP. > CMake Error at CMakeLists.txt:34 (add_subdirectory): > add_subdirectory not given a binary directory but the given source > directory "C:/alissa/dev/1.21.6/linden/indra/llcharacter" is not a > subdirectory of "c:/alissa/Dev/1.21.6/linden/indra". When specifying an > out-of-tree source a binary directory must be explicitly specified. > the first directory > is surely a subdirectory + (of the second, although they are partly in different cases.) Several comments received on this list in mind, I examined CMake source, develop.py, and related python files. I'm still puzzled and not sure what exactly is occuring, but I found a stable workaround. - Never use upper case letters in the full path name to the SL development directory. - Patch develop.py so that it receives the drive letter from getcwd() in upper case. (The patch is attached for your reference.) The detailed story follows: The most strange thing is that this behaviour is unstable, i.e., it is sometimes hard to reproduce. I kept receiving the above message for about a week, but when I tried the same thing on a different Windows PC, the issue disappeared. I believe I did the same thing; even the full path name to the development directory was same. (It contained /Dev/ with capital D.) But develop.py worked fine on the machine. I first thought it was a version issue of some development tool, then. However, I was still wrong because the next day, on that second machine, I received the above message when I worked on another copy of SL source... When I received the error, the full path didn't contain any capital letter. (The case difference cmake complained was in the drive letter.) That means, even with the same version of development tools, the above _difference_ may or may not detected by CMake. Even on the same hard drive, the drive letter may or may not recognized as in the same case. I have no idea why. We can change directory name to lowercase, but we can't change the case of drive letter. So, workaround to rename the direcotry doesn't apply to the drive letter. I examined sources. I found the followings: - The first full path name is found by CMake by calling getcwd() C library function. - The second full path name is found by develop.py by calling python os.getcwd() method and passed to CMake as a command line argument. - For whatever reason, CMake tests the case of the drive letter got from getcwd() and makes it upper case if it is in lower case. There is a comment saying "make sure the drive letter is capital". So, I assumed that python os.getcwd() sometimes returns DOS drive letter in upper case and sometimes in lower case. How should we fix it? Well, I believe it is a fundamental bug of CMake that CMake always compares DOS path names in a case sensitive way (and probably Macintosh path names, too.) If my assumption that python returns drive letter in a random case is correct, I believe it is a bug of python, too. A bug should be fixed at a location where the bug is in, IMHO. However, I considered fixing develop.py as a workaround is easier. Hence, I produced the attached patch. It works fine for me. Alissa Sabre -------------- next part -------------- Index: linden/indra/develop.py =================================================================== --- linden/indra/develop.py (revision 715) +++ linden/indra/develop.py (working copy) @@ -53,6 +53,16 @@ if err.errno != errno.EEXIST or not os.path.isdir(path): raise +def getcwd(): + cwd = os.getcwd() + if 'a' <= cwd[0] <= 'z' and cwd[1] == ':': + # CMake wants DOS drive letters to be in uppercase. The above + # condition never asserts on platforms whose full path names + # always begin with a slash, so we don't need to test whether + # we are running on Windows. + cwd = cwd[0].upper() + cwd[1:] + return cwd + def quote(opts): return '"' + '" "'.join([ opt.replace('"', '') for opt in opts ]) + '"' @@ -141,7 +151,7 @@ # do a sanity check to make sure we have a generator if not hasattr(self, 'generator'): raise "No generator available for '%s'" % (self.__name__,) - cwd = os.getcwd() + cwd = getcwd() created = [] try: for d in self.build_dirs(): @@ -396,7 +406,7 @@ '%(opts)s %(dir)r' % args) def run_build(self, opts, targets): - cwd = os.getcwd() + cwd = getcwd() if targets: targets = ' '.join(['-target ' + repr(t) for t in targets]) else: @@ -530,11 +540,11 @@ + os.path.join(build_dir,'SecondLife.sln') \ + ' --config RelWithDebInfo' \ + ' --startup secondlife-bin' - print 'Running %r in %r' % (vstool_cmd, os.getcwd()) + print 'Running %r in %r' % (vstool_cmd, getcwd()) self.run(vstool_cmd) def run_build(self, opts, targets): - cwd = os.getcwd() + cwd = getcwd() build_cmd = self.get_build_cmd() for d in self.build_dirs(): From lear.cale at gmail.com Tue Oct 28 04:44:54 2008 From: lear.cale at gmail.com (Lear Cale) Date: Tue Oct 28 04:44:57 2008 Subject: [sldev] cmake: "could not create named generator" with VS 2008 Express (v9) In-Reply-To: References: Message-ID: I get the following when trying to run cmake to build the latest client (21.6), for Windows. BTW, the instructions in the wiki leave out a few things. At the very least, you need python installed, which it doesn't cover. I installed cygwin, including installing all development, and I added C:/cygwin/bin to my Windows PATH directory. Cygwin includes Python, and it works fine with my other Python scripts. It also (now) neglects to mention that you need MS VS C++; that happened thanks to the changes for cmake. Once I get things working I'll be happy to help fix the wiki. This is a new machine; installing a development system for the first time on it. I'm a software engineer, but I do all my pro work on Unix. sh-3.2$ python develop.py -G VC90 Running 'cmake -G "Visual Studio 9 2008" -DUNATTENDED:BOOl=FALSE -DSTANDALONE:BOOL=FALSE "" "c:\\BUILD\\SL\\linden\\indr a"' in 'build-VC90' CMake Error: Could not create named generator Visual Studio 9 2008 I get a similar error running it without arguments, or passing -G VC80. If I run cmake from Programs menu, it fails to find Python, but I led it to it. After that, it fails to find or unpack prebuilt ogg-vorbis. I had to guess where to build the binaries, and probably guessed wrong, but I doubt that's the cause. Any clue what's going wrong and what to do to fix it? Thanks Lear -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20081028/7540f6d0/attachment.htm From tom at streamsense.net Tue Oct 28 04:55:42 2008 From: tom at streamsense.net (Thomas Grimshaw) Date: Tue Oct 28 04:55:47 2008 Subject: [sldev] cmake: "could not create named generator" with VS 2008 Express (v9) In-Reply-To: References: Message-ID: <4906FDBE.6010303@streamsense.net> Lear Cale wrote: > BTW, the instructions in the wiki leave out a few things. Please feel free to update or amend the wiki where you see any issues. ~T From jodiah at my-webhome.com Tue Oct 28 07:09:21 2008 From: jodiah at my-webhome.com (jodiah@my-webhome.com) Date: Tue Oct 28 07:09:25 2008 Subject: [sldev] Compiling source with VC++ 2008 (VC90) Express Edition (Boost Hell) Message-ID: <20081028070921.8b0823960ceb6a56f7ddf638f99b00cb.ba39e51b3e.wbe@email.secureserver.net> An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20081028/c4970e78/attachment.htm From bill.hoffman at kitware.com Tue Oct 28 07:13:01 2008 From: bill.hoffman at kitware.com (Bill Hoffman) Date: Tue Oct 28 07:13:06 2008 Subject: [sldev] cmake: "could not create named generator" with VS 2008 Express (v9) In-Reply-To: References: Message-ID: <49071DED.1010604@kitware.com> Lear Cale wrote: > I get the following when trying to run cmake to build the latest client > (21.6), for Windows. > > BTW, the instructions in the wiki leave out a few things. At the very > least, you need python installed, which it doesn't cover. I installed > cygwin, including installing all development, and I added C:/cygwin/bin > to my Windows PATH directory. Cygwin includes Python, and it works fine > with my other Python scripts. > > It also (now) neglects to mention that you need MS VS C++; that happened > thanks to the changes for cmake. Once I get things working I'll be > happy to help fix the wiki. > > This is a new machine; installing a development system for the first > time on it. I'm a software engineer, but I do all my pro work on Unix. > > > sh-3.2$ python develop.py -G VC90 > Running 'cmake -G "Visual Studio 9 2008" -DUNATTENDED:BOOl=FALSE > -DSTANDALONE:BOOL=FALSE "" "c:\\BUILD\\SL\\linden\\indr > a"' in 'build-VC90' > CMake Error: Could not create named generator Visual Studio 9 2008 > What cmake are you running? Looks like you might be running the cygwin cmake which does not support visual studio. You should run the cmake from www.cmake.org. -Bill From robla at lindenlab.com Tue Oct 28 09:51:05 2008 From: robla at lindenlab.com (Rob Lanphier) Date: Tue Oct 28 09:51:17 2008 Subject: [sldev] Improving build instructions (Re: cmake: "could not create named generator"...) In-Reply-To: <4906FDBE.6010303@streamsense.net> References: <4906FDBE.6010303@streamsense.net> Message-ID: <490742F9.9030701@lindenlab.com> On 10/28/08 4:55 AM, Thomas Grimshaw wrote: > Lear Cale wrote: >> BTW, the instructions in the wiki leave out a few things. > Please feel free to update or amend the wiki where you see any issues. Hi Lear, Sorry for the confusion on the instructions. Which page were you looking at specifically? Even just providing a pointer to the instructions that you're using is often useful, because sometimes that helps us identify bigger problems that we can collectively fix. As an aside for everyone, now that 1.21 has been out for a little while, we can now treat older, non-CMake based branches as the exception rather than the rule. I may just start doing that if someone doesn't beat me to it. Rob From lear.cale at gmail.com Tue Oct 28 10:34:34 2008 From: lear.cale at gmail.com (Lear Cale) Date: Tue Oct 28 10:34:48 2008 Subject: [sldev] Re: Improving build instructions (Re: cmake: "could not create named generator"...) In-Reply-To: <490742F9.9030701@lindenlab.com> References: <4906FDBE.6010303@streamsense.net> <490742F9.9030701@lindenlab.com> Message-ID: The problem is on https://wiki.secondlife.com/wiki/Get_source_and_compile, which starts out with the cmake cross-platform building page. What we need is a preamble to that, with platform-specific requirements. Fortunately, most are covered (though a bit out of date) in the section that follows -- the deprecated stuff you're recommending we get rid of, "Old (pre-CMake) Build Instructions". We need to collect the stuff from there that still applies and move it above the cmake page. Big thanks to Jordiah Jensen and Michelle2 Zenovka, whose pages have pretty much all the necessary steps -- but unfortunately end with the same problem, presumably "BOOST hell". Allegedly this is caused by VC++ V9; I'm tempted to back-rev to 2005. BTW, previously the Quicktime SDK was not required, but now it is. Perhaps that's unintentional and could be fixed in develop.py or whatever other files it uses. Thanks again Lear On Tue, Oct 28, 2008 at 12:51 PM, Rob Lanphier wrote: > On 10/28/08 4:55 AM, Thomas Grimshaw wrote: > > Lear Cale wrote: > >> BTW, the instructions in the wiki leave out a few things. > > Please feel free to update or amend the wiki where you see any issues. > > Hi Lear, > > Sorry for the confusion on the instructions. Which page were you > looking at specifically? Even just providing a pointer to the > instructions that you're using is often useful, because sometimes that > helps us identify bigger problems that we can collectively fix. > > As an aside for everyone, now that 1.21 has been out for a little while, > we can now treat older, non-CMake based branches as the exception rather > than the rule. I may just start doing that if someone doesn't beat me > to it. > > Rob > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20081028/246e5458/attachment.htm From lear.cale at gmail.com Tue Oct 28 10:36:51 2008 From: lear.cale at gmail.com (Lear Cale) Date: Tue Oct 28 10:36:53 2008 Subject: [sldev] cmake: "could not create named generator" with VS 2008 Express (v9) In-Reply-To: <49071DED.1010604@kitware.com> References: <49071DED.1010604@kitware.com> Message-ID: That was it, Bill -- thanks. Thanks also to Jodiah Jensen and Mitchell2 Zenovka, whos build pages got me back on track, up to the dreaded "BOOST hell". -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20081028/600457e2/attachment.htm From robla at lindenlab.com Tue Oct 28 12:58:21 2008 From: robla at lindenlab.com (Rob Lanphier) Date: Tue Oct 28 12:58:32 2008 Subject: [sldev] Re: Improving build instructions (Re: cmake: "could not create named generator"...) In-Reply-To: References: <4906FDBE.6010303@streamsense.net> <490742F9.9030701@lindenlab.com> Message-ID: <49076EDD.7090400@lindenlab.com> On 10/28/08 10:34 AM, Lear Cale wrote: > The problem is on https://wiki.secondlife.com/wiki/Get_source_and_compile, > which starts out with the cmake cross-platform building page. > > What we need is a preamble to that, with platform-specific > requirements. Fortunately, > most are covered (though a bit out of date) in the section that > follows -- the deprecated > stuff you're recommending we get rid of, "Old (pre-CMake) Build > Instructions". > We need to collect the stuff from there that still applies and move it > above the > cmake page. Agreed. I've started this: https://wiki.secondlife.com/wiki/User:Rob_Linden/Get_source_and_compile Even though it's in my user space, feel free to edit brutally. The idea is to make this version the new "Get source and compile" page after some radical fixups. > Big thanks to Jordiah Jensen and Michelle2 Zenovka, whose pages have > pretty much > all the necessary steps -- but unfortunately end with the same > problem, presumably > "BOOST hell". Allegedly this is caused by VC++ V9; I'm tempted to > back-rev to > 2005. > > BTW, previously the Quicktime SDK was not required, but now it is. > Perhaps that's > unintentional and could be fixed in develop.py or whatever other files > it uses. Quicktime SDK should be optional. If it's required, it's a bug, and should be filed as such (under "VWR" with component: "Source code") Thanks for struggling through! Hopefully, we can use your input to make the process smoother. Rob From sly_squash at hotmail.com Tue Oct 28 13:50:23 2008 From: sly_squash at hotmail.com (Joshy Squashy) Date: Tue Oct 28 13:50:25 2008 Subject: [sldev] RE: cmake: "could not create named generator" with VS 2008 Express (v9) (Lear Cale) In-Reply-To: <20081028190434.AA451113A15@stupor.lindenlab.com> References: <20081028190434.AA451113A15@stupor.lindenlab.com> Message-ID: Hello, I've had that same error. The problem is that you need to install the latest version of activepython. The ogg-vorbis thing isn't the real error; the real error is the "elementNode" thing that likely precedes the ogg-vorbis error on the line above. ~Squash Otoro > Message: 1 > Date: Tue, 28 Oct 2008 07:44:54 -0400 > From: "Lear Cale" > Subject: [sldev] cmake: "could not create named generator" with VS > 2008 Express (v9) > To: sldev@lists.secondlife.com > Message-ID: > > Content-Type: text/plain; charset="iso-8859-1" > > I get the following when trying to run cmake to build the latest client > (21.6), for Windows. > > BTW, the instructions in the wiki leave out a few things. At the very least, > you need python installed, which it doesn't cover. I installed cygwin, > including installing all development, and I added C:/cygwin/bin to my > Windows PATH directory. Cygwin includes Python, and it works fine with my > other Python scripts. > > It also (now) neglects to mention that you need MS VS C++; that happened > thanks to the changes for cmake. Once I get things working I'll be happy to > help fix the wiki. > > This is a new machine; installing a development system for the first time on > it. I'm a software engineer, but I do all my pro work on Unix. > > > sh-3.2$ python develop.py -G VC90 > Running 'cmake -G "Visual Studio 9 2008" -DUNATTENDED:BOOl=FALSE > -DSTANDALONE:BOOL=FALSE "" "c:\\BUILD\\SL\\linden\\indr > a"' in 'build-VC90' > CMake Error: Could not create named generator Visual Studio 9 2008 > > I get a similar error running it without arguments, or passing -G VC80. > > If I run cmake from Programs menu, it fails to find Python, but I led it to > it. After that, it fails to find or unpack prebuilt ogg-vorbis. I had to > guess where to build the binaries, and probably guessed wrong, but I doubt > that's the cause. > Any clue what's going wrong and what to do to fix it? > Thanks Lear _________________________________________________________________ Stay organized with simple drag and drop from Windows Live Hotmail. http://windowslive.com/Explore/hotmail?ocid=TXT_TAGLM_WL_hotmail_102008 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20081028/34ecb05f/attachment.htm From lear.cale at gmail.com Tue Oct 28 14:06:32 2008 From: lear.cale at gmail.com (Lear Cale) Date: Tue Oct 28 14:06:36 2008 Subject: [sldev] Re: cmake: "could not create named generator" with VS 2008 Express (v9) In-Reply-To: References: Message-ID: OK, built, run, and get this error: ERROR: LLAppViewer::initConfiguration: Cannot load default configuration file c:\BUILD\SL\linden\indra\build-VC90\newview\app_settings\settings_files.xml But the file is there and is valid XML. Repeatable. Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20081028/23a228db/attachment.htm From lear.cale at gmail.com Tue Oct 28 14:29:13 2008 From: lear.cale at gmail.com (Lear Cale) Date: Tue Oct 28 14:29:15 2008 Subject: [sldev] Re: cmake: "could not create named generator" with VS 2008 Express (v9) In-Reply-To: References: Message-ID: ooops no, the file isn't there. There's no app_settings folder in indra/build-VC90/newview, it's in indra/newview. I'd set the working directory, but evidently it didn't take. False alarm. On Tue, Oct 28, 2008 at 5:06 PM, Lear Cale wrote: > OK, built, run, and get this error: > > ERROR: LLAppViewer::initConfiguration: Cannot load default configuration > file > c:\BUILD\SL\linden\indra\build-VC90\newview\app_settings\settings_files.xml > > But the file is there and is valid XML. > Repeatable. > > Thanks > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20081028/51e7040a/attachment.htm From brad at lindenlab.com Tue Oct 28 14:59:44 2008 From: brad at lindenlab.com (Brad Kittenbrink (Brad Linden)) Date: Tue Oct 28 14:59:40 2008 Subject: [sldev] Compiling source with VC++ 2008 (VC90) Express Edition (Boost Hell) In-Reply-To: <20081028070921.8b0823960ceb6a56f7ddf638f99b00cb.ba39e51b3e.wbe@email.secureserver.net> References: <20081028070921.8b0823960ceb6a56f7ddf638f99b00cb.ba39e51b3e.wbe@email.secureserver.net> Message-ID: <49078B50.9080108@lindenlab.com> I will be attempting to solve the "boost hell" issues for the 1.22 viewer release. I'll be posting my progress at VWR-9541 . -Brad jodiah@my-webhome.com wrote: > Hello all, > > I have successfully compiled the 1.21.6 source code (1.21-r99587) > using Visual C++ 2008 Express Edition and posted a synopsis of the > steps I took at: > https://wiki.secondlife.com/wiki/User:Jodiah_Jensen > for anyone interested. > > Please note that even though this compiled successfully, the code does > not run to completion. It appears I am suffering from "Boost Hell" as > pointed out on Michelle Zenovka's page > https://wiki.secondlife.com/wiki/User:Michelle2_Zenovka/cmake#boost_hell. > > If anyone has pointers on how I can get the latest boost libraries to > work with the 1.21.6 SL source in VC++2008, please let me know. > (latest version of boost I have is 1.36 and I built the program > option, regex, and signal libraries, but I am having trouble getting > the source to link with my new libraries. Also, trying to use the 1.36 > headers in the "\linden\libraries\include\boost" path of the source > tree, results in hundreds of errors when building.) > > Regards, > Jodiah > ------------------------------------------------------------------------ > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20081028/4fc500e3/attachment.htm From russhaverty at googlemail.com Tue Oct 28 16:48:29 2008 From: russhaverty at googlemail.com (Russell Haverty) Date: Tue Oct 28 16:48:34 2008 Subject: [sldev] Linden Lab and unfair business practices Message-ID: <5c0efdf70810281648h2420b9b1x56f72589fda7f648@mail.gmail.com> Hi all, I'd like to let you all know that as of this moment, I will halt my work on the second life client source code. The reason is that I no longer wish to indirectly support Linden Lab; since they seem to be repeatedly attacking the community, I feel it is no longer appropriate for the community to support them. If anyone is still in the dark about what i'm talking about, i'm referring to the ludicrous pricing increase to openspace sims. As of the 1st of January 2008, you will now pay half the tier cost of a full sim, and in return, receive less than a quarter of the resources. We all know that linden lab are making an absolute killing on their virtual real estate; this latest move can be seen as nothing more than greed. I encourage anybody who is interested in this topic to first check out the linden blog post at: http://blog.secondlife.com/2008/10/27/openspace-pricing-and-policy-changes/ And also consider voting for the (very active) JIRA: http://jira.secondlife.com/browse/MISC-1776 Thank you all for your time, and I apologise for the scarcely on-topic post. Russell -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20081028/e443fbe4/attachment.htm From tom at streamsense.net Tue Oct 28 16:51:26 2008 From: tom at streamsense.net (Thomas Grimshaw) Date: Tue Oct 28 16:51:35 2008 Subject: [sldev] Linden Lab and unfair business practices In-Reply-To: <5c0efdf70810281648h2420b9b1x56f72589fda7f648@mail.gmail.com> References: <5c0efdf70810281648h2420b9b1x56f72589fda7f648@mail.gmail.com> Message-ID: <4907A57E.60404@streamsense.net> Russell Haverty wrote: > I'd like to let you all know that as of this moment, I will halt my > work on the second life client source code. OpenSimulator development has suddenly become a whole lot more attractive. ~T From ordinal.malaprop at fastmail.fm Tue Oct 28 17:07:59 2008 From: ordinal.malaprop at fastmail.fm (ordinal.malaprop@fastmail.fm) Date: Tue Oct 28 17:08:05 2008 Subject: [sldev] Linden Lab and unfair business practices In-Reply-To: <4907A57E.60404@streamsense.net> References: <5c0efdf70810281648h2420b9b1x56f72589fda7f648@mail.gmail.com> <4907A57E.60404@streamsense.net> Message-ID: I must admit that I have not heard the term "opensim" quite so many times as recently. Usually in the context of "opensim here I come". On 28 Oct 2008, at 23:51, Thomas Grimshaw wrote: > Russell Haverty wrote: >> I'd like to let you all know that as of this moment, I will halt my >> work on the second life client source code. > OpenSimulator development has suddenly become a whole lot more > attractive. > > ~T > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges From tom at streamsense.net Tue Oct 28 17:12:58 2008 From: tom at streamsense.net (Thomas Grimshaw) Date: Tue Oct 28 17:13:06 2008 Subject: [sldev] Linden Lab and unfair business practices In-Reply-To: References: <5c0efdf70810281648h2420b9b1x56f72589fda7f648@mail.gmail.com> <4907A57E.60404@streamsense.net> Message-ID: <4907AA8A.2070203@streamsense.net> Interestingly enough, it made it into a national daily paper here in the UK yesterday: http://www.guardian.co.uk/technology/blog ~T ordinal.malaprop@fastmail.fm wrote: > I must admit that I have not heard the term "opensim" quite so many > times as recently. Usually in the context of "opensim here I come". From robla at lindenlab.com Tue Oct 28 17:39:32 2008 From: robla at lindenlab.com (Rob Lanphier) Date: Tue Oct 28 17:39:44 2008 Subject: [sldev] Re: Improving build instructions (Re: cmake: "could notcreate named generator"...) In-Reply-To: <49076EDD.7090400@lindenlab.com> References: <4906FDBE.6010303@streamsense.net> <490742F9.9030701@lindenlab.com> <49076EDD.7090400@lindenlab.com> Message-ID: <4907B0C4.6020505@lindenlab.com> On 10/28/08 12:58 PM, Rob Lanphier wrote: > I've started this: > https://wiki.secondlife.com/wiki/User:Rob_Linden/Get_source_and_compile > > Even though it's in my user space, feel free to edit brutally. The idea > is to make this version the new "Get source and compile" page after some > radical fixups. > In working on this, I've found a lot of duplicate information up there on the wiki, where people have started fresh with new pages rather than fixing what's there. One huge way for you all to contribute is to actually delete outdated information that someone may stumble upon on a search request. Rob From GordonWendt at gmail.com Tue Oct 28 22:37:40 2008 From: GordonWendt at gmail.com (Gordon Wendt) Date: Tue Oct 28 22:37:45 2008 Subject: [sldev] Linden Lab and unfair business practices In-Reply-To: <5c0efdf70810281648h2420b9b1x56f72589fda7f648@mail.gmail.com> References: <5c0efdf70810281648h2420b9b1x56f72589fda7f648@mail.gmail.com> Message-ID: <493033a70810282237k74044acexdbb4e465d7aa7426@mail.gmail.com> Oh come on, I understand you're upset and frustrated and I agree with you however you have the forums as the official channel and for the people who refuse to believe that despite the fact that this is what's said on the blog (and there are a few on the JIRA) you have the JIRA to spam and abuse but don't drag this mailing list down as well with your offtopic tripe. Unless your talking about the technical issues regarding open space sims and how the infastructure works, Which I think is a discussion that we should be having, then it is off topic and doesn't belong here. Even though they seem to be willing to let the JIRA go down the toilet at the moment to let all the OS owners throw their temper tantrum, which is what it has devolved into rather than a logical set of complaints and issues with the change a few people exciluded, I really hope that People will keep it off of here since as I said it is in volation of the list rules and also because this is supposed to be the mature techie group of second life residents. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20081029/3838ee8f/attachment.htm From GordonWendt at gmail.com Tue Oct 28 22:41:31 2008 From: GordonWendt at gmail.com (Gordon Wendt) Date: Tue Oct 28 22:41:35 2008 Subject: [sldev] Infastructure vis a vis sim infastructure particularly open space sims Message-ID: <493033a70810282241w5914401cu96e774b0672971a4@mail.gmail.com> I realize that this is not the original place set out for this discussion but since Jack Linden has openly invited ideas in regards to how to handle this I figured I would start a thread to discuss and brainstorm the issues of infastructure especially sim infastructure. I added open source sims to the title since that's the hot topic at the moment but if it branches out that's great and since LL has stated their willingness to at least listen I'm all for taking them up on the idea. -G.W. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20081029/005ffdd0/attachment.htm From dahliatrimble at gmail.com Tue Oct 28 23:11:07 2008 From: dahliatrimble at gmail.com (Dahlia Trimble) Date: Tue Oct 28 23:11:11 2008 Subject: [sldev] Infastructure vis a vis sim infastructure particularly open space sims In-Reply-To: <493033a70810282241w5914401cu96e774b0672971a4@mail.gmail.com> References: <493033a70810282241w5914401cu96e774b0672971a4@mail.gmail.com> Message-ID: meh... I never liked openspace sims anyway. Some brainstormed straw dog ideas, not all pertaining to the open space issue, to be taken with a grain of salt: 1. Develop a means of constraining expensive (currently) unaccountable resources, such as: 1a. quantity and resolution of textures 1b. total number of prims per avatar 1c. total number of textures per avatar 1d. maximum script cycles per second per avatar 1e. maximum number of script cycles per square meter of land per land owner 1f. etc. 2. Develop a means of constraining resource usage per open space region so as to not use more that 1/4 of the cpu resources 3. Develop a means where a viewer user can restrict the level of "rendering cost" available to any displayed avatar, i.e., high rendering cost attachments are not displayed, or attachments requiring excessive texture downloading are displayed with a single texture. 4. Allow content creators a means of developing multiple Levels Of Detail (LOD) in content, so if an offending object has an excessive resource cost it can be displayed in a controlled, compromised way, i.e., a few low resolution textures instead of many high resolution ones. 5. Develop an accounting method that can notify an open space region owner that content/use is excessive. 6. Develop a means where open space region owners can increase resource availability by paying an increase in tier. 7. Develop a means where resource usage credits can be traded between open space regions. 7a. Develop a transaction fee for credit trading. Use this to fund infrastructure improvements. 8. Vote for my suggestions for other regional accounting enhancements here: http://jira.secondlife.com/browse/SVC-2648 On Tue, Oct 28, 2008 at 10:41 PM, Gordon Wendt wrote: > I realize that this is not the original place set out for this discussion > but since Jack Linden has openly invited ideas in regards to how to handle > this I figured I would start a thread to discuss and brainstorm the issues > of infastructure especially sim infastructure. I added open source sims to > the title since that's the hot topic at the moment but if it branches out > that's great and since LL has stated their willingness to at least listen > I'm all for taking them up on the idea. > > -G.W. > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20081028/a5657577/attachment.htm From GordonWendt at gmail.com Tue Oct 28 23:15:28 2008 From: GordonWendt at gmail.com (Gordon Wendt) Date: Tue Oct 28 23:15:33 2008 Subject: [sldev] Infastructure vis a vis sim infastructure particularly open space sims In-Reply-To: References: <493033a70810282241w5914401cu96e774b0672971a4@mail.gmail.com> Message-ID: <493033a70810282315t25560ec1ib1a9dad89bcef447@mail.gmail.com> Incidentally, a log (I don't like the source more than anyone else but it's the only one I could find) of an impromptu meeting with Jack is very good reading on what has been asked and his responses which include some ideas that he has responded that he would "talk to his colleagues" about. It's long and it's a lot of ranting and raving but do a find for Jack Linden and then from his responses go back to the questions and you'll get some pretty good things that have been covered. I'll try to go through later and see if I can outline some of the stuff that was covered in that and post it here. The log is posted here: http://secondthoughts.typepad.com/second_thoughts/2008/10/jack-jacks-the.html Credit goes to: Prokofy Neva for posting the log up. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20081029/cf630bde/attachment.htm From missannotoole at yahoo.com Tue Oct 28 23:26:12 2008 From: missannotoole at yahoo.com (Ann Otoole) Date: Tue Oct 28 23:26:15 2008 Subject: [sldev] Infastructure vis a vis sim infastructure particularly open space sims Message-ID: <144913.61884.qm@web59101.mail.re1.yahoo.com> I don't think this mailing list is appropriate for this discussion at all. If this were a technical issue then it would have been solved via technical means. There is something else involved and my gut feeling is that LL needs to be looking at who is making suggestions that could cause catastrophic damage to SL and study why such suggestions are being made. After all there are other companies that would gain from SL ending. And who is already a partnered with those companies and why is it odd suggestions are being tossed in, etc. Nope, This is not technical. This is global power money politics and it is company vs company so LL needs to begin evaluating it's trust with internal and external resources. Something is just wrong with the picture here. Anyway angry customers ranting all over blogs and quitting SL etc. is not going to change an executive decision that had better have considered the repercussions before the decision was made. If LL asks this list for suggestions then fair game for a discussion. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20081028/0fd91ba9/attachment-0001.htm From GordonWendt at gmail.com Tue Oct 28 23:32:52 2008 From: GordonWendt at gmail.com (Gordon Wendt) Date: Tue Oct 28 23:32:56 2008 Subject: [sldev] Infastructure vis a vis sim infastructure particularly open space sims In-Reply-To: <144913.61884.qm@web59101.mail.re1.yahoo.com> References: <144913.61884.qm@web59101.mail.re1.yahoo.com> Message-ID: <493033a70810282332o51fce5bbk3197707a7167de@mail.gmail.com> Anne I take great insult at the accusation that I have an exterior not to mention a sinister motive behind my original post to the point where I am violating good practice and polite behavior to respond on list rather than privately. I am going to officially ask that you withdraw that accusation unless you actually have proof to back it up. Who is hurting LL is definitely off-topic for this list so I won't answer that on list although I'll reply to you on that off list in case you want to continue the conversation there as rules and good practice dictate we should. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20081029/fb3bd67e/attachment.htm From missannotoole at yahoo.com Wed Oct 29 00:10:42 2008 From: missannotoole at yahoo.com (Ann Otoole) Date: Wed Oct 29 00:10:47 2008 Subject: [sldev] Infastructure vis a vis sim infastructure particularly open space sims Message-ID: <787547.96207.qm@web59103.mail.re1.yahoo.com> Wasn't about you and didn't quote you or anything Gordon. I don't see how you inferred that at all. My opinion that this is not a topic for sldev stands. It is political and possibly legal and thus sldev is not the place unless LL solicits the group for technical recommendations. Anyone else around here that starts a non tech thing going gets "moderated" (banned) so it is unwise to even start such topics here. If Rob OKs the discussion then fine. But let's not start allowing some people to conduct policy and legal threads while banning others that dare to do so. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20081029/e1de5eb8/attachment.htm From GordonWendt at gmail.com Wed Oct 29 00:18:47 2008 From: GordonWendt at gmail.com (Gordon Wendt) Date: Wed Oct 29 00:18:50 2008 Subject: [sldev] Infastructure vis a vis sim infastructure particularly open space sims In-Reply-To: <787547.96207.qm@web59103.mail.re1.yahoo.com> References: <787547.96207.qm@web59103.mail.re1.yahoo.com> Message-ID: <493033a70810290018v650abac6k84900e69e42fd869@mail.gmail.com> Since this is a technical list this will be my last on list on the topic. I must have misunderstood then but it did seem that it was pointed towards me as the initiator of this thread. As far as it being a political and legal issue it does have those elements which is actually why I narrowly phrased my original post to deal just with the technical. If your reading political and legal meddling into that then that's your issue to deal with. -G.W. On Wed, Oct 29, 2008 at 3:10 AM, Ann Otoole wrote: > Wasn't about you and didn't quote you or anything Gordon. I don't see how > you inferred that at all. > > My opinion that this is not a topic for sldev stands. > It is political and possibly legal and thus sldev is not the place unless > LL solicits the group for technical recommendations. > > Anyone else around here that starts a non tech thing going gets "moderated" > (banned) so it is unwise to even start such topics here. > > If Rob OKs the discussion then fine. > But let's not start allowing some people to conduct policy and legal > threads while banning others that dare to do so. > > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20081029/a2175fec/attachment.htm From GordonWendt at gmail.com Wed Oct 29 00:23:39 2008 From: GordonWendt at gmail.com (Gordon Wendt) Date: Wed Oct 29 00:23:43 2008 Subject: [sldev] Re: Infastructure vis a vis sim infastructure particularly open space sims In-Reply-To: <493033a70810282241w5914401cu96e774b0672971a4@mail.gmail.com> References: <493033a70810282241w5914401cu96e774b0672971a4@mail.gmail.com> Message-ID: <493033a70810290023te61b68ck18a3b9d2ff61dfb8@mail.gmail.com> One of the issues that has been somewhat adressed but keeps coming up is the idea of hard coding limits in. That has recieved a we'll look into it from Jack but it seems that although everyone has a different idea of what those limits would be that's an interesting thought. Of course that woudl require technological and possibly physical changes which is why it has recieved the response it has I think but it's an intresting idea. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20081029/245a0d8b/attachment.htm From dahliatrimble at gmail.com Wed Oct 29 00:50:20 2008 From: dahliatrimble at gmail.com (Dahlia Trimble) Date: Wed Oct 29 00:50:23 2008 Subject: [sldev] Infastructure vis a vis sim infastructure particularly open space sims In-Reply-To: <144913.61884.qm@web59101.mail.re1.yahoo.com> References: <144913.61884.qm@web59101.mail.re1.yahoo.com> Message-ID: With apologies to the list members: Ann, my suggestions were freely offered as possible technical means of improving LL's product. I am not in any position to benefit from any loss of business that LL may incur from implementing them. If you feel that my suggestions are meant to harm LL's business, then I also suggest that LL is free to ignore them at their discretion. Perhaps you should ignore them as well. On Tue, Oct 28, 2008 at 11:26 PM, Ann Otoole wrote: > I don't think this mailing list is appropriate for this discussion at all. > > If this were a technical issue then it would have been solved via technical > means. > > There is something else involved and my gut feeling is that LL needs to be > looking at who is making suggestions that could cause catastrophic damage to > SL and study why such suggestions are being made. > After all there are other companies that would gain from SL ending. And who > is already a partnered with those companies and why is it odd suggestions > are being tossed in, etc. > > Nope, This is not technical. This is global power money politics and it is > company vs company so LL needs to begin evaluating it's trust with internal > and external resources. > > Something is just wrong with the picture here. > > Anyway angry customers ranting all over blogs and quitting SL etc. is not > going to change an executive decision that had better have considered the > repercussions before the decision was made. > > If LL asks this list for suggestions then fair game for a discussion. > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20081029/a4e0260c/attachment.htm From gareth at litesim.com Wed Oct 29 02:16:39 2008 From: gareth at litesim.com (Gareth Nelson) Date: Wed Oct 29 02:16:41 2008 Subject: [sldev] Linden Lab and unfair business practices In-Reply-To: <5c0efdf70810281648h2420b9b1x56f72589fda7f648@mail.gmail.com> References: <5c0efdf70810281648h2420b9b1x56f72589fda7f648@mail.gmail.com> Message-ID: <61dbdd7d0810290216y3ed67e2fne10b13e44c530487@mail.gmail.com> > The reason is that I no longer wish to indirectly support Linden Lab; since > they seem to be repeatedly attacking the community, I feel it is no longer > appropriate for the community to support them. By working on the client you're supporting the community too, refusing to work on a piece of software due to political reasons relating to the original authors of that software is simply childish. > We all know that linden lab are making an absolute killing on their virtual > real estate; this latest move can be seen as nothing more than greed. We don't actually have all the details to make that judgement, though I repeat again: refusing to work on a piece of software due to political reasons relating to the original authors of that software is simply childish > Thank you all for your time, and I apologise for the scarcely on-topic post. May I ask what patches you actually had in the viewer? From gareth at litesim.com Wed Oct 29 02:19:43 2008 From: gareth at litesim.com (Gareth Nelson) Date: Wed Oct 29 02:19:46 2008 Subject: [sldev] Linden Lab and unfair business practices In-Reply-To: <493033a70810282237k74044acexdbb4e465d7aa7426@mail.gmail.com> References: <5c0efdf70810281648h2420b9b1x56f72589fda7f648@mail.gmail.com> <493033a70810282237k74044acexdbb4e465d7aa7426@mail.gmail.com> Message-ID: <61dbdd7d0810290219m7d966555o9973c31c103b056d@mail.gmail.com> On Wed, Oct 29, 2008 at 5:37 AM, Gordon Wendt wrote: > I really hope that People will keep it off of here since > as I said it is in volation of the list rules and also because this is > supposed to be the mature techie group of second life residents. I'd say it all depends on what patches the original poster had, or if they were working on something of particular value. Russel: If you were working on anything of particular value, care to share your work thus far so others can continue? From gareth at litesim.com Wed Oct 29 02:23:23 2008 From: gareth at litesim.com (Gareth Nelson) Date: Wed Oct 29 02:23:26 2008 Subject: [sldev] Linden Lab and unfair business practices In-Reply-To: <493033a70810282237k74044acexdbb4e465d7aa7426@mail.gmail.com> References: <5c0efdf70810281648h2420b9b1x56f72589fda7f648@mail.gmail.com> <493033a70810282237k74044acexdbb4e465d7aa7426@mail.gmail.com> Message-ID: <61dbdd7d0810290223y27f8f8a8h86e7ee443674a2b5@mail.gmail.com> On the technical side of things, just saw this on the JIRA: Dale Innis - 28/Oct/08 12:27 PM Seems like it should be possible to prevent "abuse" (i.e. people loading their OpenSpace sims to an extent that hurts the performance of the others on the same machine) by appropriate fiddling with the operating system or hypervisor or whatever. Talk to the techies, and put in CKRM policies or whatever to ensure that each sim process gets at least its fair share of the CPU. (If it's about disk access or network bandwidth rather than CPU, there are perhaps similar things that would let you do similar things for those.) I'd go further by dynamically renicing "abusive" sim processes down, but that's just me....... On Wed, Oct 29, 2008 at 5:37 AM, Gordon Wendt wrote: > Oh come on, I understand you're upset and frustrated and I agree with you > however you have the forums as the official channel and for the people who > refuse to believe that despite the fact that this is what's said on the blog > (and there are a few on the JIRA) you have the JIRA to spam and abuse but > don't drag this mailing list down as well with your offtopic tripe. Unless > your talking about the technical issues regarding open space sims and how > the infastructure works, Which I think is a discussion that we should be > having, then it is off topic and doesn't belong here. Even though they seem > to be willing to let the JIRA go down the toilet at the moment to let all > the OS owners throw their temper tantrum, which is what it has devolved into > rather than a logical set of complaints and issues with the change a few > people exciluded, I really hope that People will keep it off of here since > as I said it is in volation of the list rules and also because this is > supposed to be the mature techie group of second life residents. > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > From secret.argent at gmail.com Wed Oct 29 03:49:09 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Wed Oct 29 03:48:46 2008 Subject: [sldev] Linden Lab and unfair business practices In-Reply-To: <61dbdd7d0810290223y27f8f8a8h86e7ee443674a2b5@mail.gmail.com> References: <5c0efdf70810281648h2420b9b1x56f72589fda7f648@mail.gmail.com> <493033a70810282237k74044acexdbb4e465d7aa7426@mail.gmail.com> <61dbdd7d0810290223y27f8f8a8h86e7ee443674a2b5@mail.gmail.com> Message-ID: <755A54DB-06EC-4717-AB4B-C15499011F22@gmail.com> I think that any technical solution involving CPU resource balancing is going to require Linux kernel hacking and is probably outside Linden Labs core business (to say the least). Hypervisors, if not already in use, would add significant overhead. This is not really a technical issue, it's a matter of establishing a business case at LL and so it's really outside the scope of this list. My comments on this subject are on record in the forums. I voted for the 1776 Jira, but I'm not going to discuss things there, either. From gareth at litesim.com Wed Oct 29 04:09:48 2008 From: gareth at litesim.com (Gareth Nelson) Date: Wed Oct 29 04:09:51 2008 Subject: [sldev] Linden Lab and unfair business practices In-Reply-To: <755A54DB-06EC-4717-AB4B-C15499011F22@gmail.com> References: <5c0efdf70810281648h2420b9b1x56f72589fda7f648@mail.gmail.com> <493033a70810282237k74044acexdbb4e465d7aa7426@mail.gmail.com> <61dbdd7d0810290223y27f8f8a8h86e7ee443674a2b5@mail.gmail.com> <755A54DB-06EC-4717-AB4B-C15499011F22@gmail.com> Message-ID: <61dbdd7d0810290409o27ea0cc3lc1da8f093c042cbc@mail.gmail.com> if sim_is_overloaded: renice +x where x is whatever is deemed appropriate Trivial On Wed, Oct 29, 2008 at 10:49 AM, Argent Stonecutter wrote: > I think that any technical solution involving CPU resource balancing is > going to require Linux kernel hacking and is probably outside Linden Labs > core business (to say the least). Hypervisors, if not already in use, would > add significant overhead. This is not really a technical issue, it's a > matter of establishing a business case at LL and so it's really outside the > scope of this list. > > My comments on this subject are on record in the forums. I voted for the > 1776 Jira, but I'm not going to discuss things there, either. > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > From secret.argent at gmail.com Wed Oct 29 05:05:32 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Wed Oct 29 05:05:10 2008 Subject: [sldev] Linden Lab and unfair business practices In-Reply-To: <61dbdd7d0810290409o27ea0cc3lc1da8f093c042cbc@mail.gmail.com> References: <5c0efdf70810281648h2420b9b1x56f72589fda7f648@mail.gmail.com> <493033a70810282237k74044acexdbb4e465d7aa7426@mail.gmail.com> <61dbdd7d0810290223y27f8f8a8h86e7ee443674a2b5@mail.gmail.com> <755A54DB-06EC-4717-AB4B-C15499011F22@gmail.com> <61dbdd7d0810290409o27ea0cc3lc1da8f093c042cbc@mail.gmail.com> Message-ID: <512D30E4-9DA1-41D5-9394-D40271A3D0AF@gmail.com> For every problem there is an answer that is easy, simple and wrong. Nice is far too crude a tool for managing resource allocation issues between competing CPU-bound processes... the automatic priority juggling already in the UNIX or Linux kernel does a better job of that than you can by manual intervention. But even if that was likely to work here, I have learned the hard way that technical fixes to social and political problems, and problems in a product offering or business model, do not work worth a damn. This is not really a technical issue, it's a matter of establishing a business case at LL and so it's really outside the scope of this list. From chess at us.ibm.com Wed Oct 29 05:53:16 2008 From: chess at us.ibm.com (David M Chess) Date: Wed Oct 29 05:53:20 2008 Subject: [sldev] Linden Lab and unfair business practices In-Reply-To: <20081029092329.E631D41B23F@stupor.lindenlab.com> Message-ID: Boy, am I not liking this thread's Subject line. :) > From: "Gareth Nelson" > On the technical side of things, just saw this on the JIRA: > Dale Innis - 28/Oct/08 12:27 PM > Seems like it should be possible to prevent "abuse" (i.e. people > loading their OpenSpace sims to an extent that hurts the performance > of the others on the same machine) by appropriate fiddling with the > operating system or hypervisor or whatever. Talk to the techies, and > put in CKRM policies or whatever to ensure that each sim process gets > at least its fair share of the CPU. (If it's about disk access or > network bandwidth rather than CPU, there are perhaps similar things > that would let you do similar things for those.) > > I'd go further by dynamically renicing "abusive" sim processes down, > but that's just me....... Thanks for the quote, Gareth; I was just looking through sldev to see if this technical question had come up. It actually seems likely to me that they've considered using CKRM policies or hypervisor settings or some equivalent to insulate the OpenSpace sims from each other, and to keep them from using more than one-quarter of a machine when there's contention, and it just turned out not to work for some reason. The technical folks who discovered that it didn't work probably aren't quite sure of exactly why, and they probably haven't described the issues in enough detail up the chain that it can come back to us via Jack with any fidelity at all; information flow is a difficult thing. BUT, just in case, because stranger things have happened, I do hope that someone reading this forwards a quick note to someone on the ground, saying "are you guys aware of the severity of this OpenSpace sim resource contention problem, and have you looked into using the OS or CKRM or the hypervisor or whatever to limit the OpenSpace processes from using more than a quarter of the machine when there's contention?", and then maybe even lets us know what the reply is. It could be, like, "oh, is that still a problem? sorry, I was busy with something else; we'll give CKRM a try and let you know; it'll probably work." And think how much pain that could avert! :) Of course people will (still) complain when it turns out their OpenSpace sims get really slow under loads that don't stress a full sim at all, but well... TANSTAAFL an' all. -- Dale Innis (DaleInnisEmail at gmail.com) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20081029/fb65607f/attachment.htm From TammyNowotny at mac.com Wed Oct 29 06:49:37 2008 From: TammyNowotny at mac.com (Tammy Nowotny) Date: Wed Oct 29 06:49:46 2008 Subject: [sldev] Linden Lab and unfair business practices In-Reply-To: <61dbdd7d0810290223y27f8f8a8h86e7ee443674a2b5@mail.gmail.com> References: <5c0efdf70810281648h2420b9b1x56f72589fda7f648@mail.gmail.com> <493033a70810282237k74044acexdbb4e465d7aa7426@mail.gmail.com> <61dbdd7d0810290223y27f8f8a8h86e7ee443674a2b5@mail.gmail.com> Message-ID: <490869F1.1090104@mac.com> One simple fix (although it would still create an uproar) might be to create a new Opensim equivalenet which has less than 1/4 the number of prims :-) Gareth Nelson wrote: > On the technical side of things, just saw this on the JIRA: > Dale Innis - 28/Oct/08 12:27 PM > Seems like it should be possible to prevent "abuse" (i.e. people > loading their OpenSpace sims to an extent that hurts the performance > of the others on the same machine) by appropriate fiddling with the > operating system or hypervisor or whatever. Talk to the techies, and > put in CKRM policies or whatever to ensure that each sim process gets > at least its fair share of the CPU. (If it's about disk access or > network bandwidth rather than CPU, there are perhaps similar things > that would let you do similar things for those.) > > I'd go further by dynamically renicing "abusive" sim processes down, > but that's just me....... > > > From monkowsk at watson.ibm.com Wed Oct 29 07:24:49 2008 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Wed Oct 29 07:25:40 2008 Subject: [sldev] Re: Improving build instructions (Re: cmake: "could notcreate named generator"...) In-Reply-To: <4907B0C4.6020505@lindenlab.com> References: <4906FDBE.6010303@streamsense.net> <490742F9.9030701@lindenlab.com> <49076EDD.7090400@lindenlab.com> <4907B0C4.6020505@lindenlab.com> Message-ID: <49087231.80107@watson.ibm.com> Rob Lanphier wrote: > In working on this, I've found a lot of duplicate information up there > on the wiki, where people have started fresh with new pages rather than > fixing what's there. You mean like: >>I've started this: >>https://wiki.secondlife.com/wiki/User:Rob_Linden/Get_source_and_compile Sorry, I couldn't resist. The irony was too obvious. :-) Mike From ian at ianbetteridge.co.uk Wed Oct 29 07:49:24 2008 From: ian at ianbetteridge.co.uk (Ian Betteridge) Date: Wed Oct 29 07:49:26 2008 Subject: [sldev] Linden Lab and unfair business practices In-Reply-To: <490869F1.1090104@mac.com> References: <5c0efdf70810281648h2420b9b1x56f72589fda7f648@mail.gmail.com> <493033a70810282237k74044acexdbb4e465d7aa7426@mail.gmail.com> <61dbdd7d0810290223y27f8f8a8h86e7ee443674a2b5@mail.gmail.com> <490869F1.1090104@mac.com> Message-ID: Another simple fix: don't sell anymore openspace sims until they've actually worked out a way to make them cost-effective (ie, profitable for them, useful for us) to provide. And if they can't make them cost-effective, don't sell them. Which is my way of saying that this is a business issue, rather than a technical one, and therefore probably not appropriate for this list ;) On Wed, Oct 29, 2008 at 1:49 PM, Tammy Nowotny wrote: > One simple fix (although it would still create an uproar) might be to create > a new Opensim equivalenet which has less than 1/4 the number of prims :-) > > Gareth Nelson wrote: >> >> On the technical side of things, just saw this on the JIRA: >> Dale Innis - 28/Oct/08 12:27 PM >> Seems like it should be possible to prevent "abuse" (i.e. people >> loading their OpenSpace sims to an extent that hurts the performance >> of the others on the same machine) by appropriate fiddling with the >> operating system or hypervisor or whatever. Talk to the techies, and >> put in CKRM policies or whatever to ensure that each sim process gets >> at least its fair share of the CPU. (If it's about disk access or >> network bandwidth rather than CPU, there are perhaps similar things >> that would let you do similar things for those.) >> >> I'd go further by dynamically renicing "abusive" sim processes down, >> but that's just me....... >> >> > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > From grant at lindenlab.com Wed Oct 29 08:52:09 2008 From: grant at lindenlab.com (Grant Linden) Date: Wed Oct 29 08:52:14 2008 Subject: [sldev] RX Office hours - General UI discussion - Suggested topic: new approaches to HUDS Message-ID: <907af5560810290852k28959559na669a242c258c519@mail.gmail.com> RX Office hours - General UI discussion - Suggested topic: new approaches to HUDS Thursday October 29th from 3:00-4:00 PM SLT http://slurl.com/secondlife/Beaumont/148/155/46/?title=Linden%20Village For more news about the RX team and to suggest topics for future RX Office Hours please visit our wiki page: https://wiki.secondlife.com/wiki/Resident_Experience The SL-UX Email Discussion List is the ongoing conversation about the Second Life UI and Resident Experience. Residents and Lindens join together to discuss, brain storm and refine the Second Life UI. Join here: https://lists.secondlife.com/cgi-bin/mailman/listinfo/sl-ux -- Steven Grant (Grant Linden) User Experience Designer Linden Lab | Second Life -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20081029/f232f724/attachment-0001.htm From robin.cornelius at gmail.com Wed Oct 29 09:01:45 2008 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Wed Oct 29 09:01:48 2008 Subject: [sldev] Linden Lab and unfair business practices In-Reply-To: References: <5c0efdf70810281648h2420b9b1x56f72589fda7f648@mail.gmail.com> <493033a70810282237k74044acexdbb4e465d7aa7426@mail.gmail.com> <61dbdd7d0810290223y27f8f8a8h86e7ee443674a2b5@mail.gmail.com> <490869F1.1090104@mac.com> Message-ID: On Wed, Oct 29, 2008 at 2:49 PM, Ian Betteridge wrote: > Another simple fix: don't sell anymore openspace sims until they've > actually worked out a way to make them cost-effective (ie, profitable > for them, useful for us) to provide. And if they can't make them > cost-effective, don't sell them. > > Which is my way of saying that this is a business issue, rather than a > technical one, and therefore probably not appropriate for this list ;) If you do have any technical ideas for this, then please link to the META jira http://jira.secondlife.com/browse/SVC-3335 I guess there is no one-fits all solution here and the problem is social/political and technical but we can at least try to address ideas on the technical front and that is as good as place as any to link to and continue discussions. Robin From soft at lindenlab.com Wed Oct 29 11:09:09 2008 From: soft at lindenlab.com (Soft) Date: Wed Oct 29 11:09:12 2008 Subject: [sldev] Open Source Meeting Thu 2pm Message-ID: Our Thursday open source meetings take place at 2pm. If there is anything you would like on the agenda... have at it! http://wiki.secondlife.com/wiki/Open_Source_Meeting/Agenda From soft at lindenlab.com Wed Oct 29 11:22:10 2008 From: soft at lindenlab.com (Soft) Date: Wed Oct 29 11:22:13 2008 Subject: [sldev] Infastructure vis a vis sim infastructure particularlyopen space sims In-Reply-To: References: <144913.61884.qm@web59101.mail.re1.yahoo.com> Message-ID: I know this stuff is really rough right now. A lot of us are really sorry that it's happened, and are hopeful that the land team will offer more choices. In the mean time, please know that other posters can be every bit as much on edge as you are while figuring out what comes next. It's so easy to start a nasty chain of negative reactions when you have a bunch of people who are more angry than normal, and more readily angered than normal. JIRA is absolutely the best place for ideas on technical solutions to openspace overuse. Gigs created this meta issue for these ideas: https://jira.secondlife.com/browse/SVC-3335 With those and other ideas, I hope we can help the land team consider new choices. From dnbyena at gmail.com Wed Oct 29 11:20:05 2008 From: dnbyena at gmail.com (Khyota) Date: Wed Oct 29 11:26:11 2008 Subject: [sldev] Open Source Meeting Thu 2pm In-Reply-To: References: Message-ID: <200810291420.05884.dnbyena@gmail.com> On Wednesday 29 October 2008 02:09:09 pm Soft wrote: > Our Thursday open source meetings take place at 2pm. If there is > anything you would like on the agenda... have at it! > http://wiki.secondlife.com/wiki/Open_Source_Meeting/Agenda > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges Im having trouble deciding what weather things belong there or not, how does it have to relate to opensourceness? From soft at lindenlab.com Wed Oct 29 11:36:23 2008 From: soft at lindenlab.com (Soft) Date: Wed Oct 29 11:36:26 2008 Subject: [sldev] Open Source Meeting Thu 2pm In-Reply-To: <200810291420.05884.dnbyena@gmail.com> References: <200810291420.05884.dnbyena@gmail.com> Message-ID: On Wed, Oct 29, 2008 at 1:20 PM, Khyota wrote: > On Wednesday 29 October 2008 02:09:09 pm Soft wrote: > >> Our Thursday open source meetings take place at 2pm. If there is >> anything you would like on the agenda... have at it! >> http://wiki.secondlife.com/wiki/Open_Source_Meeting/Agenda > > Im having trouble deciding what weather things belong there or not, how does > it have to relate to opensourceness? Well, general issues about the use of the open source code are all appropriate. These are licensing questions, build questions, ideas for changes to the code, and questions about how to report bugs or submit fixes. We've usually got a few developers present, Rob the open source strategy guru, often Liana for licensing issues, and often a QA person as well. If you're at all unsure, it's okay to ask on this list. I don't remember you coming up with any wild non-opensource topics at the meetings to date, if there's any worry. From tongb at ohio.edu Wed Oct 29 11:45:30 2008 From: tongb at ohio.edu (Bruce Tong) Date: Wed Oct 29 11:51:49 2008 Subject: [sldev] Sim Size Limits? Message-ID: <4f335a50810291145w632761f2v6a97f0c8d93e7047@mail.gmail.com> Just out of curiosity, why are sims always 256m x 256m in size? Is the system running into an issue like a maximum floating point value? Does it have to do with resources used to model the terrain? I wonder if "open space" might be a matter addressed by just letting people define private regions to be larger without getting more prims. Mind you, I still think the issue raging is more a matter of built up demand for inexpensive, small, private sims. That customer demand eventually translates into technical requirements, of course, that are different from providing "open space." -- Bruce Tong Software Engineer Office of Information Technology Ohio University From chaosstar at gmail.com Wed Oct 29 11:57:19 2008 From: chaosstar at gmail.com (Ambrosia) Date: Wed Oct 29 11:57:22 2008 Subject: [sldev] Sim Size Limits? In-Reply-To: <4f335a50810291145w632761f2v6a97f0c8d93e7047@mail.gmail.com> References: <4f335a50810291145w632761f2v6a97f0c8d93e7047@mail.gmail.com> Message-ID: <9bb32d430810291157p3a46c9aai63a9790515c25dcc@mail.gmail.com> Well, I presume the number is inspired by the maximum 8bit value :> That and it's what they started out as, and by now that number is used in lots of parts of the viewer code, the sim code, and LSL scripts all over the grid. Changing the size now would have to be a very careful process, given that all products that check for certain coordinates are probably not made to handle anything above 256m. Just think about it, any product that On Wed, Oct 29, 2008 at 19:45, Bruce Tong wrote: > Just out of curiosity, why are sims always 256m x 256m in size? Is the > system running into an issue like a maximum floating point value? Does > it have to do with resources used to model the terrain? I wonder if > "open space" might be a matter addressed by just letting people define > private regions to be larger without getting more prims. > > Mind you, I still think the issue raging is more a matter of built up > demand for inexpensive, small, private sims. That customer demand > eventually translates into technical requirements, of course, that are > different from providing "open space." > > -- > Bruce Tong > Software Engineer > Office of Information Technology > Ohio University > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges > From robin.cornelius at gmail.com Wed Oct 29 12:11:30 2008 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Wed Oct 29 12:11:37 2008 Subject: [sldev] Open Source Meeting Thu 2pm In-Reply-To: References: Message-ID: <4908B562.1080701@gmail.com> Soft wrote: > Our Thursday open source meetings take place at 2pm. If there is > anything you would like on the agenda... have at it! > http://wiki.secondlife.com/wiki/Open_Source_Meeting/Agenda Just wanted to remind people that USA is still on Summer Time/Day Light Saving (DST) Until 2nd Nov (i think), Europe has already switched back, so for us Europeans (and possibly others) it will be an hour different to normal. Robin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 260 bytes Desc: OpenPGP digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20081029/d104b2c6/signature.pgp From soft at lindenlab.com Wed Oct 29 12:16:41 2008 From: soft at lindenlab.com (Soft) Date: Wed Oct 29 12:16:43 2008 Subject: [sldev] Sim Size Limits? In-Reply-To: <4f335a50810291145w632761f2v6a97f0c8d93e7047@mail.gmail.com> References: <4f335a50810291145w632761f2v6a97f0c8d93e7047@mail.gmail.com> Message-ID: On Wed, Oct 29, 2008 at 1:45 PM, Bruce Tong wrote: > Just out of curiosity, why are sims always 256m x 256m in size? Is the > system running into an issue like a maximum floating point value? Does > it have to do with resources used to model the terrain? I wonder if > "open space" might be a matter addressed by just letting people define > private regions to be larger without getting more prims. > > Mind you, I still think the issue raging is more a matter of built up > demand for inexpensive, small, private sims. That customer demand > eventually translates into technical requirements, of course, that are > different from providing "open space." 256 isn't a magic number. It's more an issue of the sims all being the *same* size. If there could be more or fewer sims meeting up against sim edges, there would need to be significant rearchitecting of the viewer and simulator... not to mention existing scripts, as Ambrosia points out. We'll probably get away from that 256 meter limit eventually. But in the near term, engineering time would be better spent making actions happening across sim borders run more seamlessly. From dnbyena at gmail.com Wed Oct 29 12:22:04 2008 From: dnbyena at gmail.com (Khyota) Date: Wed Oct 29 12:23:17 2008 Subject: [sldev] Open Source Meeting Thu 2pm In-Reply-To: <4908B562.1080701@gmail.com> References: <4908B562.1080701@gmail.com> Message-ID: <200810291522.04885.dnbyena@gmail.com> On Wednesday 29 October 2008 03:11:30 pm Robin Cornelius wrote: > Soft wrote: > > Our Thursday open source meetings take place at 2pm. If there is > > anything you would like on the agenda... have at it! > > http://wiki.secondlife.com/wiki/Open_Source_Meeting/Agenda > > Just wanted to remind people that USA is still on Summer Time/Day Light > Saving (DST) Until 2nd Nov (i think), Europe has already switched back, > so for us Europeans (and possibly others) it will be an hour different > to normal. > > Robin Yes good point. and thanks soft! Since were in the middle of daylight time Transitions i think i should bring up http://jira.secondlife.com/browse/SVC-1385 "Redefine SL system time as UTC/GMT instead of PST-PDT California time" Khyota From TammyNowotny at mac.com Wed Oct 29 12:39:24 2008 From: TammyNowotny at mac.com (Tammy Nowotny) Date: Wed Oct 29 12:45:39 2008 Subject: [sldev] Sim Size Limits? In-Reply-To: <4f335a50810291145w632761f2v6a97f0c8d93e7047@mail.gmail.com> References: <4f335a50810291145w632761f2v6a97f0c8d93e7047@mail.gmail.com> Message-ID: <4908BBEC.10109@mac.com> Bruce Tong wrote: > Just out of curiosity, why are sims always 256m x 256m in size? Is the > system running into an issue like a maximum floating point value? Does > it have to do with resources used to model the terrain? I wonder if > "open space" might be a matter addressed by just letting people define > private regions to be larger without getting more prims. > > I think it was just an arbitrary power of 2: 128 was too small and 512 was too big. Hence, 256 was the logical choice. (Hmm, maybe 128 wasn't too small, since most SL residents still have their draw distance set to less than 128 * sqrt (2): i.e., most of us can't see all the way across a single sim.) The new OpenSim regions have also been 256 by 256 but the size of the region isn't hardwired into the data standards. But (if I am not mistaken) all regions on an OpenSim grid still have to be the same size. From robla at lindenlab.com Wed Oct 29 13:24:55 2008 From: robla at lindenlab.com (Rob Lanphier) Date: Wed Oct 29 13:24:54 2008 Subject: [sldev] Re: Improving build instructions (Re: cmake: "could notcreate named generator"...) In-Reply-To: <49087231.80107@watson.ibm.com> References: <4906FDBE.6010303@streamsense.net> <490742F9.9030701@lindenlab.com> <49076EDD.7090400@lindenlab.com> <4907B0C4.6020505@lindenlab.com> <49087231.80107@watson.ibm.com> Message-ID: <4908C697.6010406@lindenlab.com> On 10/29/2008 07:24 AM, Mike Monkowski wrote: > Rob Lanphier wrote: >> In working on this, I've found a lot of duplicate information up there >> on the wiki, where people have started fresh with new pages rather than >> fixing what's there. > > You mean like: > > >>I've started this: > >>https://wiki.secondlife.com/wiki/User:Rob_Linden/Get_source_and_compile > > Sorry, I couldn't resist. The irony was too obvious. :-) :-P Fine, now that I'm done, I've merged it in here: https://wiki.secondlife.com/wiki/Get_source_and_compile This may create a little bit of confusion as there's still statements like "Lindens still use VS2003", and such in the instructions. However, let's all try to get this stuff as accurate and up-to-date as possible. Rob From zha.ewry at gmail.com Wed Oct 29 13:43:20 2008 From: zha.ewry at gmail.com (Zha Ewry) Date: Wed Oct 29 13:43:25 2008 Subject: [sldev] Sim Size Limits? In-Reply-To: <4908BBEC.10109@mac.com> References: <4f335a50810291145w632761f2v6a97f0c8d93e7047@mail.gmail.com> <4908BBEC.10109@mac.com> Message-ID: <920d7d850810291343p58b68c5cy8f74168e3cd58583@mail.gmail.com> The client makes a bunch of 256x256 assumptions. It *knows* where the edge of the sim is,w hen to hand off, and if there is a sim adjacent, based on it's geometry of the grid, and the handles of the sims it is talking to. Breaking that is both a protocol issue and a code issue. I expect, in time, it will be tackle,d but I agree that it's less of an urgent issue than many, many other issued, including, as Soft mentioned, having crossing be less disruptive. ~ Zha On Wed, Oct 29, 2008 at 3:39 PM, Tammy Nowotny wrote: > > > Bruce Tong wrote: >> >> Just out of curiosity, why are sims always 256m x 256m in size? Is the >> system running into an issue like a maximum floating point value? Does >> it have to do with resources used to model the terrain? I wonder if >> "open space" might be a matter addressed by just letting people define >> private regions to be larger without getting more prims. >> >> > > I think it was just an arbitrary power of 2: 128 was too small and 512 was > too big. Hence, 256 was the logical choice. (Hmm, maybe 128 wasn't too > small, since most SL residents still have their draw distance set to less > than 128 * sqrt (2): i.e., most of us can't see all the way across a single > sim.) > > The new OpenSim regions have also been 256 by 256 but the size of the region > isn't hardwired into the data standards. But (if I am not mistaken) all > regions on an OpenSim grid still have to be the same size. > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > From gigstaggart at gmail.com Wed Oct 29 15:43:28 2008 From: gigstaggart at gmail.com (Jason Giglio) Date: Wed Oct 29 15:43:32 2008 Subject: [sldev] Infastructure vis a vis sim infastructure particularly open space sims In-Reply-To: <493033a70810282241w5914401cu96e774b0672971a4@mail.gmail.com> References: <493033a70810282241w5914401cu96e774b0672971a4@mail.gmail.com> Message-ID: <4908E710.7060302@gmail.com> Gordon Wendt wrote: > I realize that this is not the original place set out for this > discussion but since Jack Linden has openly invited ideas in regards to > how to handle this I figured I would start a thread to discuss and > brainstorm the issues of infastructure especially sim infastructure. I > added open source sims to the title since that's the hot topic at the > moment but if it branches out that's great and since LL has stated their > willingness to at least listen I'm all for taking them up on the idea. > > -G.W. > > http://jira.secondlife.com/browse/SVC-3335 The technical limitations on openspaces metaissue is here. Link all related ideas to this. -Jason -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3266 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20081029/1836eefa/smime.bin From me at signpostmarv.name Wed Oct 29 16:01:42 2008 From: me at signpostmarv.name (SignpostMarv Martin) Date: Wed Oct 29 16:01:27 2008 Subject: [sldev] Sim Size Limits? In-Reply-To: <9bb32d430810291157p3a46c9aai63a9790515c25dcc@mail.gmail.com> References: <4f335a50810291145w632761f2v6a97f0c8d93e7047@mail.gmail.com> <9bb32d430810291157p3a46c9aai63a9790515c25dcc@mail.gmail.com> Message-ID: <4908EB56.1040103@signpostmarv.name> I've given thought to this issue recently: 1) Resource usage- Making more resources available to fewer instances of the sim code, say 1 or 2 regions running on the same hardware that runs four (class 5/6 uses quad core, right ?). This I assume would be as complex as making more instances run in the same resources- likely still complex, though it's probably easier to implement as keeping the region dimensions the same but improving the capabilities. 2) Sim arrangement- Given that the Grid is currently only available to be arranged in a 2-dimensional grid, sim blocks would likely have to be in collections of powers of 2, or at least square (you can just imagine people literally playing tetris with regions here). 3) Co-ordinate addressing- The current system relies on integers for grid co-ordinates and though the function llGetRegionCorner() returns a vector, the values are practically integers also. As long as the dimensions of a region were multiples of 256, existing LSL code based on this function would not break. What would break however, is any code that calculates grid offsets, as well as any practical conversational references. As for object movement code that relies on a 256x256 dimension, I'm not sure how many there are (with the exception of inter-sim warpPos teleporters) that make such calculations, since CHANGED_REGION would still fire correctly. Be thankful region co-ordinates are specified by the ZERO_VECTOR corner, and not the center of the sim (else you'd have to have the system altered to use floats to specify the region position) 4) Increased network traffic- With a fixed 256x256 limit, sims typically only communicate with the horizontally and vertically adjacent sims. With a 512x512 sim size, you'd either have two options: a) restrict neighbouring sims to identically sized-regions only b) have to deal with the issue of network traffic increasing with each multiple of 256 (1 = 4 sims, 2 = 8 sims, 3 = 12 sims, etc) 5) Physics- People have a hard enough time crossing region borders in vehicles as it is. I'm sure that should multiple region dimensions be allowed to co-exist as neighbours, there would be issues occurring that would result in objects appearing to travel into the wrong sim. Where I think the issue of multiple region dimensions co-existing might be addressed is via Region domain, e.g. if it were possible for multiple regions to be logically addressed as a single region- either for purposes of load balancing, or for the purposes of increasing region dimensions. This is analogous to RAID, where at the simplest levels- RAID 0 and RAID 1, where a RAID 0 type setup would be to produce larger logical regions, and a RAID 1 setup would be to provide an apparent increase in resources (higher prim limits, agent capacity etc.). Arbitrarily allowing a single region to have flexible dimensions (regardless of whether it's multiples of 256, or a true floating scale) would be too messy in my opinion- a RAID-like load balancing/splitting system would sort of solve the increase network traffic issue, as each of the child Region domains would likely handle the adjoining regions in the same manner that contemporary regions do, and it would also perhaps allow for more creative region shapes (e.g. tetrominoes ). ~ Marv. Ambrosia wrote: > Well, I presume the number is inspired by the maximum 8bit value :> > > That and it's what they started out as, and by now that number is used > in lots of parts of the viewer code, the sim code, and LSL scripts all > over the grid. Changing the size now would have to be a very careful > process, given that all products that check for certain coordinates > are probably not made to handle anything above 256m. > > Just think about it, any product that > > On Wed, Oct 29, 2008 at 19:45, Bruce Tong wrote: > >> Just out of curiosity, why are sims always 256m x 256m in size? Is the >> system running into an issue like a maximum floating point value? Does >> it have to do with resources used to model the terrain? I wonder if >> "open space" might be a matter addressed by just letting people define >> private regions to be larger without getting more prims. >> >> Mind you, I still think the issue raging is more a matter of built up >> demand for inexpensive, small, private sims. That customer demand >> eventually translates into technical requirements, of course, that are >> different from providing "open space." >> >> -- >> Bruce Tong >> Software Engineer >> Office of Information Technology >> Ohio University >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/SLDev >> Please read the policies before posting to keep unmoderated posting privileges >> >> > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges > > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3244 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20081029/32b3d7d6/smime-0001.bin From aimee at ama-zing.co.uk Wed Oct 29 16:09:14 2008 From: aimee at ama-zing.co.uk (Aimee Walton) Date: Wed Oct 29 16:09:18 2008 Subject: [sldev] Sim Size Limits? In-Reply-To: <920d7d850810291343p58b68c5cy8f74168e3cd58583@mail.gmail.com> References: <4f335a50810291145w632761f2v6a97f0c8d93e7047@mail.gmail.com> <4908BBEC.10109@mac.com> <920d7d850810291343p58b68c5cy8f74168e3cd58583@mail.gmail.com> Message-ID: <09312EE0-9D2C-4F56-87B3-A1823F6779FA@ama-zing.co.uk> Possibly also I imagine due to limitations of what the physics engine at the time could handle. This is something I've been thinking about a bit recently, SL aviation is pretty much stifled by playing Russian roulette on sim crossing and 256x256 is a bit tight to fly around in. In theory you could do a larger one as a server side only modification, backwards compatible with existing viewers, by making it pretend to be a 2x2 group of four regions when talking to the client, faking the handoffs, but I'm no expert on the protocol issues. You could possibly get something close by making arrangements so that a group of four regions are guaranteed to be running on the same simulator, so region crossings still happen, but they should be as smooth as possible. However then you have the management headache of coarser granularity allocating regions to servers. Aimee. On 29 Oct 2008, at 20:43, Zha Ewry wrote: > The client makes a bunch of 256x256 assumptions. It *knows* where the > edge of the sim is,w hen to hand off, and if there is a sim adjacent, > based on it's geometry of the grid, and the handles of the sims it is > talking to. Breaking that is both a protocol issue and a code issue. I > expect, in time, it will be tackle,d but I agree that it's less of an > urgent issue than many, many other issued, including, as Soft > mentioned, having crossing be less disruptive. > > ~ Zha From secret.argent at gmail.com Thu Oct 30 05:02:42 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Thu Oct 30 05:02:18 2008 Subject: [sldev] RX Office hours - General UI discussion - Suggested topic: new approaches to HUDS In-Reply-To: <907af5560810290852k28959559na669a242c258c519@mail.gmail.com> References: <907af5560810290852k28959559na669a242c258c519@mail.gmail.com> Message-ID: <232D28A6-025B-44EB-8EA5-2875AA43817F@gmail.com> Anyone have a log of this session? From secret.argent at gmail.com Thu Oct 30 05:10:56 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Thu Oct 30 05:10:33 2008 Subject: [sldev] Sim Size Limits? In-Reply-To: <4f335a50810291145w632761f2v6a97f0c8d93e7047@mail.gmail.com> References: <4f335a50810291145w632761f2v6a97f0c8d93e7047@mail.gmail.com> Message-ID: <34B36F91-2C2E-4712-BBC1-B88B28313B18@gmail.com> On 2008-10-29, at 13:45, Bruce Tong wrote: > Just out of curiosity, why are sims always 256m x 256m in size? Is the > system running into an issue like a maximum floating point value? Does > it have to do with resources used to model the terrain? I wonder if > "open space" might be a matter addressed by just letting people define > private regions to be larger without getting more prims. That would break so many scripts. Back in the old suggestion system I called for an explicit mechanism for scripts to ask the simulator size. This wouldn't allow for larger sims soon, until it gets used in scripts that are currently looking at <256,256,*> as the sim edge, but the absence of such a call absolutely ensures that you can't make them larger. I think I have a Jira out for this too, but Jira seems to be down right now so I can't check. This is such an obvious functionality that I'm still boggled it wasn't in there at the start. From secret.argent at gmail.com Thu Oct 30 05:16:26 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Thu Oct 30 05:16:02 2008 Subject: [sldev] Sim Size Limits? In-Reply-To: <4908BBEC.10109@mac.com> References: <4f335a50810291145w632761f2v6a97f0c8d93e7047@mail.gmail.com> <4908BBEC.10109@mac.com> Message-ID: <08D5CAD2-BFEF-4280-93FC-B0D00AB4D387@gmail.com> > I think it was just an arbitrary power of 2: 128 was too small and > 512 was too big. 512 isn't too big. 1024 would have been about right. Imagine a more open, less cramped Second Life. From secret.argent at gmail.com Thu Oct 30 05:29:40 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Thu Oct 30 05:29:16 2008 Subject: [sldev] Sim Size Limits? In-Reply-To: <4908EB56.1040103@signpostmarv.name> References: <4f335a50810291145w632761f2v6a97f0c8d93e7047@mail.gmail.com> <9bb32d430810291157p3a46c9aai63a9790515c25dcc@mail.gmail.com> <4908EB56.1040103@signpostmarv.name> Message-ID: <1FC4833F-49D3-4B68-BD55-FE271F50533C@gmail.com> On 2008-10-29, at 18:01, SignpostMarv Martin wrote: > The current system relies on integers for grid co-ordinates and though > the function llGetRegionCorner() returns a vector, the values are > practically integers also. I'm not sure I understand this. Region coordinates are floating point numbers, and whether they are or not... 512 and 1024 are perfectly good integer and floating point values. What does the fact that they're integer or floating point have to do with anything? Grid coordinates can be multiples of 256, 512, 1024, etcetera. > As for object movement code that relies on a 256x256 dimension, I'm > not > sure how many there are (with the exception of inter-sim warpPos > teleporters) that make such calculations, since CHANGED_REGION would > still fire correctly. There's teleporters that check to make sure you're specifying a region in sim, scanners that check for impossible coordinates sometimes returned by sensors, physical and non-physical objects that need to check to see if they're likely to go off-world, etcetera, etcetera, etcetera. We need to add a region size call NOW, if this is ever going to be changed. From aimee at ama-zing.co.uk Thu Oct 30 07:05:25 2008 From: aimee at ama-zing.co.uk (Aimee Walton) Date: Thu Oct 30 07:05:30 2008 Subject: [sldev] RX Office hours - General UI discussion - Suggested topic: new approaches to HUDS In-Reply-To: <232D28A6-025B-44EB-8EA5-2875AA43817F@gmail.com> References: <907af5560810290852k28959559na669a242c258c519@mail.gmail.com> <232D28A6-025B-44EB-8EA5-2875AA43817F@gmail.com> Message-ID: Did Grant get the date wrong, or is the daylight saving adjustment now 25 hours? :D I think it's meant to be today. Aimee. On 30 Oct 2008, at 12:02, Argent Stonecutter wrote: > Anyone have a log of this session? From doug at lindenlab.com Thu Oct 30 07:10:18 2008 From: doug at lindenlab.com (Douglas Soo) Date: Thu Oct 30 07:10:22 2008 Subject: [sldev] Sim Size Limits? In-Reply-To: <08D5CAD2-BFEF-4280-93FC-B0D00AB4D387@gmail.com> References: <4f335a50810291145w632761f2v6a97f0c8d93e7047@mail.gmail.com> <4908BBEC.10109@mac.com> <08D5CAD2-BFEF-4280-93FC-B0D00AB4D387@gmail.com> Message-ID: Actually, there are a few good reasons why 256 is probably a reasonable number, mostly relating to floating-point and fixed point precision: - 32 bit floating point gets you around 7 decimal points of precisions - this means that once you hit a distance of about 256 meters, you're looking at somewhere around millimeter to centimeter precision. So once you go too much beyond 256 meters, you're going to start having precision issues when tightly positioning objects in the world reference frame. Note that if we had been thinking further ahead at the time, we would have positioned 0,0,0 at center of the region, and doubled our precision at the edges. - Until we hit the highest precision level, we will often send object positions in 16-bit fixed point representations (I believe). Increasing the size of a region would increase the distance at which we would start having to send full-precision 32-bit data down to the client. This could have some impact on bandwidth utilization, and possibly rezzing speed of distant objects. - The larger the area of the region, the more objects we need to support in order to be able to maintain a reasonable density of content across an entire simulator node. I think with the 512MB initial constraint on memory usage at the time that we started, this was probably a reasonable number. - The smaller the region, the more regions an individual viewer needs to connect to at a certain draw distance. Since the renderer in its current implementation can realistically use only a 512 meter draw distance at best, this generally limits a viewer to talking to around half a dozen regions right now. Reducing that size would cause you to have to connect to a much larger number of regions. Also, as you reduce size of a region, the boundary zones where you have to start sharing simulation (which someday we will eventually do properly) increase, which means that you generate more edge traffic on the simulation side. This is not to say that there was necessarily a HUGE amount of conscious thought put into this (if there was, we would have put the origin at the center as mentioned above) - but 256 meters is not actually an unreasonable value. In any case, this is an incredibly difficult constant to change in the system - it would require lots of protocol changes, as well as a fairly major overhaul of the server side, so it's a somewhat moot discussion right now. :) - Doug On Thu, 30 Oct 2008 05:16:26 -0700, Argent Stonecutter wrote: >> I think it was just an arbitrary power of 2: 128 was too small and 512 >> was too big. > > 512 isn't too big. > > 1024 would have been about right. > > Imagine a more open, less cramped Second Life. > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges -- Douglas Soo Engineering Director Linden Lab From kf6kjg at gmail.com Thu Oct 30 19:52:50 2008 From: kf6kjg at gmail.com (Ricky) Date: Thu Oct 30 19:52:56 2008 Subject: [sldev] Sim Size Limits? In-Reply-To: References: <4f335a50810291145w632761f2v6a97f0c8d93e7047@mail.gmail.com> <4908BBEC.10109@mac.com> <08D5CAD2-BFEF-4280-93FC-B0D00AB4D387@gmail.com> Message-ID: <3bb9647e0810301952w563f515cx1c9231cf1755b386@mail.gmail.com> Getting a function defined that returns the size of the simulator would make any future transition a little easier. Also note that code (read: server, client, and script code,) should not assume that simulators are always going to have their Z0 matched to the world's Z0. In the future it would be really nice to have different sized sims, and even stacked sims. A use case for stacked sims is underground, aboveground, high-altitude, and "space" sims. On a side note, physics for a space sim might be made easier making the sim capable of being larger without hurting the physics engine. Simply reduce prim-level collisions to only sphere-sphere collisions. Most space sims would be about flying craft at insane velocities... :D Does anybody have a JIRA link for a function to request the sim size? Ricky On Thu, Oct 30, 2008 at 7:10 AM, Douglas Soo wrote: > Actually, there are a few good reasons why 256 is probably a reasonable > number, mostly relating to floating-point and fixed point precision: > > - 32 bit floating point gets you around 7 decimal points of precisions - > this means that once you hit a distance of about 256 meters, you're looking > at somewhere around millimeter to centimeter precision. So once you go too > much beyond 256 meters, you're going to start having precision issues when > tightly positioning objects in the world reference frame. Note that if we > had been thinking further ahead at the time, we would have positioned 0,0,0 > at center of the region, and doubled our precision at the edges. > - Until we hit the highest precision level, we will often send object > positions in 16-bit fixed point representations (I believe). Increasing the > size of a region would increase the distance at which we would start having > to send full-precision 32-bit data down to the client. This could have some > impact on bandwidth utilization, and possibly rezzing speed of distant > objects. > - The larger the area of the region, the more objects we need to support in > order to be able to maintain a reasonable density of content across an > entire simulator node. I think with the 512MB initial constraint on memory > usage at the time that we started, this was probably a reasonable number. > - The smaller the region, the more regions an individual viewer needs to > connect to at a certain draw distance. Since the renderer in its current > implementation can realistically use only a 512 meter draw distance at best, > this generally limits a viewer to talking to around half a dozen regions > right now. Reducing that size would cause you to have to connect to a much > larger number of regions. Also, as you reduce size of a region, the > boundary zones where you have to start sharing simulation (which someday we > will eventually do properly) increase, which means that you generate more > edge traffic on the simulation side. > > This is not to say that there was necessarily a HUGE amount of conscious > thought put into this (if there was, we would have put the origin at the > center as mentioned above) - but 256 meters is not actually an unreasonable > value. > > In any case, this is an incredibly difficult constant to change in the > system - it would require lots of protocol changes, as well as a fairly > major overhaul of the server side, so it's a somewhat moot discussion right > now. :) > > - Doug > > > On Thu, 30 Oct 2008 05:16:26 -0700, Argent Stonecutter < > secret.argent@gmail.com> wrote: > > I think it was just an arbitrary power of 2: 128 was too small and 512 was >>> too big. >>> >> >> 512 isn't too big. >> >> 1024 would have been about right. >> >> Imagine a more open, less cramped Second Life. >> >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/SLDev >> Please read the policies before posting to keep unmoderated posting >> privileges >> > > > > -- > Douglas Soo > Engineering Director > Linden Lab > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20081030/19a46cf1/attachment.htm From jacek.antonelli at gmail.com Thu Oct 30 20:26:33 2008 From: jacek.antonelli at gmail.com (Jacek Antonelli) Date: Thu Oct 30 20:26:36 2008 Subject: [sldev] RX Office hours - General UI discussion - Suggested topic: new approaches to HUDS In-Reply-To: References: <907af5560810290852k28959559na669a242c258c519@mail.gmail.com> <232D28A6-025B-44EB-8EA5-2875AA43817F@gmail.com> Message-ID: <105c09f0810302026m273a2431j4550ce873ddff2d3@mail.gmail.com> Yep, Grant made a little goof on the date, the discussion was today (Oct 30). Transcript is available, but there was a topic change. Nearly all of the discussion was about the discussions themselves: frequency, scheduling, Linden involvement, etc. There's a bit of HUD talk at the end (starting around 15:47), though. https://wiki.secondlife.com/wiki/User:Benjamin_Linden/Office_Hours/2008-10-30 - Jacek On Thu, Oct 30, 2008 at 9:05 AM, Aimee Walton wrote: > Did Grant get the date wrong, or is the daylight saving adjustment now 25 > hours? :D > > I think it's meant to be today. > > Aimee. > > On 30 Oct 2008, at 12:02, Argent Stonecutter wrote: > >> Anyone have a log of this session? From kakurady at gmail.com Thu Oct 30 21:25:41 2008 From: kakurady at gmail.com (Geneko Nemeth) Date: Thu Oct 30 21:25:50 2008 Subject: [sldev] RX Office hours - General UI discussion - Suggested topic: new approaches to HUDS In-Reply-To: <105c09f0810302026m273a2431j4550ce873ddff2d3@mail.gmail.com> References: <907af5560810290852k28959559na669a242c258c519@mail.gmail.com> <232D28A6-025B-44EB-8EA5-2875AA43817F@gmail.com> <105c09f0810302026m273a2431j4550ce873ddff2d3@mail.gmail.com> Message-ID: <490A88C5.1070204@gmail.com> In particular, Benjamin Linden's idea that interested residents gather into an "user experience interest group"(RXIG?) seems to be well-accepted. In addition, it is suggested that Linden involvement be reduced to a monthly meeting. No Lindens? Whoa. Granted, three Lindens could be a bit too much... In any case I hope this could lead to more residents participating in UX discussion. We could use a better representation of UX needs. Oh yeah, and RXIG isn't really a pretty name. Any ideas? Geneko Nemeth (Kakurady Drakenar) Jacek Antonelli ??: > Yep, Grant made a little goof on the date, the discussion was today > (Oct 30). Transcript is available, but there was a topic change. > Nearly all of the discussion was about the discussions themselves: > frequency, scheduling, Linden involvement, etc. There's a bit of HUD > talk at the end (starting around 15:47), though. > > https://wiki.secondlife.com/wiki/User:Benjamin_Linden/Office_Hours/2008-10-30 > > - Jacek From blindwanderer at gmail.com Thu Oct 30 21:53:16 2008 From: blindwanderer at gmail.com (Strife Onizuka) Date: Thu Oct 30 21:53:20 2008 Subject: [sldev] Wiki & Jira - Database locked - Speculations Message-ID: <89ca6da00810302153x2a453adam32a8a1bfbef03ac1@mail.gmail.com> Both the wiki and jira have their backend databases locked (read only). No announcement or real message from the lab. So I'm left speculating what is going on. On the wiki this has been marked with the message "Read only mode. Disaster recovery." I think there is some connection to this and the instillation of Extension:BreadCrumbs2 on the wiki but I can't be sure. Mind you I'm kinda miffed that they would install that and not install Extension:Cite. That's life. Wonder if the Template:Multi-lang update had anything to do with it? Maybe should probably install the version of ParserFunctions that is intended to run with 1.13 (and not keep using the version that was designed for 1.8 or there abouts) I don't know. Or maybe the Category bug finally broke the db. Oh god I bet thats it, Extension:BreadCrumbs2 depends upon the category system. -- Strife -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20081031/f185a247/attachment.htm From q at lindenlab.com Thu Oct 30 22:09:46 2008 From: q at lindenlab.com (Kent Quirk (Q Linden)) Date: Thu Oct 30 22:09:51 2008 Subject: [sldev] Sim Size Limits? In-Reply-To: <3bb9647e0810301952w563f515cx1c9231cf1755b386@mail.gmail.com> References: <4f335a50810291145w632761f2v6a97f0c8d93e7047@mail.gmail.com><4908BBEC.10109@mac.com><08D5CAD2-BFEF-4280-93FC-B0D00AB4 D387@gmail.com> <3bb9647e0810301952w563f515cx1c9231cf1755b386@mail.gmail.com> Message-ID: <412F7250-B82F-47AC-959F-21EBC231BF55@lindenlab.com> While all the features you suggest might be nice in a clean-slate environment, there are some assumptions that are baked in rather deeply to Second Life. One of them is that the world is flat. I agree that there are valid use cases for it to be otherwise -- but they're not anything we will achieve anytime soon. In Second Life, a sim has two coordinates, not three, and there's no reasonably foreseeable future that will add a third coordinate. Nor, as Doug implies, are we likely to change the 256x256 sim size because of the far-reaching effects of such a change, both internally and externally. I'm sorry, but this is one of those "Won't Finish" sorts of issues. Q On Oct 30, 2008, at 10:52 PM, Ricky wrote: > Getting a function defined that returns the size of the simulator > would make any future transition a little easier. Also note that > code (read: server, client, and script code,) should not assume that > simulators are always going to have their Z0 matched to the world's > Z0. In the future it would be really nice to have different sized > sims, and even stacked sims. A use case for stacked sims is > underground, aboveground, high-altitude, and "space" sims. > > On a side note, physics for a space sim might be made easier making > the sim capable of being larger without hurting the physics engine. > Simply reduce prim-level collisions to only sphere-sphere > collisions. Most space sims would be about flying craft at insane > velocities... :D > > Does anybody have a JIRA link for a function to request the sim size? > Ricky > > On Thu, Oct 30, 2008 at 7:10 AM, Douglas Soo > wrote: > Actually, there are a few good reasons why 256 is probably a > reasonable number, mostly relating to floating-point and fixed point > precision: > > - 32 bit floating point gets you around 7 decimal points of > precisions - this means that once you hit a distance of about 256 > meters, you're looking at somewhere around millimeter to centimeter > precision. So once you go too much beyond 256 meters, you're going > to start having precision issues when tightly positioning objects in > the world reference frame. Note that if we had been thinking > further ahead at the time, we would have positioned 0,0,0 at center > of the region, and doubled our precision at the edges. > - Until we hit the highest precision level, we will often send > object positions in 16-bit fixed point representations (I believe). > Increasing the size of a region would increase the distance at which > we would start having to send full-precision 32-bit data down to the > client. This could have some impact on bandwidth utilization, and > possibly rezzing speed of distant objects. > - The larger the area of the region, the more objects we need to > support in order to be able to maintain a reasonable density of > content across an entire simulator node. I think with the 512MB > initial constraint on memory usage at the time that we started, this > was probably a reasonable number. > - The smaller the region, the more regions an individual viewer > needs to connect to at a certain draw distance. Since the renderer > in its current implementation can realistically use only a 512 meter > draw distance at best, this generally limits a viewer to talking to > around half a dozen regions right now. Reducing that size would > cause you to have to connect to a much larger number of regions. > Also, as you reduce size of a region, the boundary zones where you > have to start sharing simulation (which someday we will eventually > do properly) increase, which means that you generate more edge > traffic on the simulation side. > > This is not to say that there was necessarily a HUGE amount of > conscious thought put into this (if there was, we would have put the > origin at the center as mentioned above) - but 256 meters is not > actually an unreasonable value. > > In any case, this is an incredibly difficult constant to change in > the system - it would require lots of protocol changes, as well as a > fairly major overhaul of the server side, so it's a somewhat moot > discussion right now. :) > > - Doug > > > On Thu, 30 Oct 2008 05:16:26 -0700, Argent Stonecutter > wrote: > > I think it was just an arbitrary power of 2: 128 was too small and > 512 was too big. > > 512 isn't too big. > > 1024 would have been about right. > > Imagine a more open, less cramped Second Life. > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > > > > -- > Douglas Soo > Engineering Director > Linden Lab > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20081031/7d4f789e/attachment-0001.htm From robla at lindenlab.com Thu Oct 30 22:56:13 2008 From: robla at lindenlab.com (Rob Lanphier) Date: Thu Oct 30 22:56:13 2008 Subject: [sldev] Wiki & Jira - Database locked - Speculations In-Reply-To: <89ca6da00810302153x2a453adam32a8a1bfbef03ac1@mail.gmail.com> References: <89ca6da00810302153x2a453adam32a8a1bfbef03ac1@mail.gmail.com> Message-ID: <490A9DFD.9030105@lindenlab.com> Strife, the notice is here: http://status.secondlifegrid.net/ We'd update the banner, but unfortunately, the database being in read-only mode means we can't update it (since the banner is in the db) This had nothing to do with the installation of the breadcrumb extension. Our service provider had a fileserver failure. Sorry that Breadcrumb jumped in line in front of Cite. I can't promise anything since it isn't my call, but I suspect that Cite can get installed reasonably soon as well. Rob On 10/30/2008 09:53 PM, Strife Onizuka wrote: > Both the wiki and jira have their backend databases locked (read > only). No announcement or real message from the lab. So I'm left > speculating what is going on. > > On the wiki this has been marked with the message "Read only mode. > Disaster recovery." > > I think there is some connection to this and the instillation of > Extension:BreadCrumbs2 on the wiki but I can't be sure. Mind you I'm > kinda miffed that they would install that and not install > Extension:Cite. That's life. Wonder if the Template:Multi-lang update > had anything to do with it? > > Maybe should probably install the version of ParserFunctions that is > intended to run with 1.13 (and not keep using the version that was > designed for 1.8 or there abouts) I don't know. > > Or maybe the Category bug finally broke the db. Oh god I bet thats it, > Extension:BreadCrumbs2 depends upon the category system. > > -- Strife > ------------------------------------------------------------------------ > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges From secret.argent at gmail.com Fri Oct 31 04:53:17 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Fri Oct 31 04:52:57 2008 Subject: [sldev] Sim Size Limits? In-Reply-To: References: <4f335a50810291145w632761f2v6a97f0c8d93e7047@mail.gmail.com> <4908BBEC.10109@mac.com> <08D5CAD2-BFEF-4280-93FC-B0D00AB4D387@gmail.com> Message-ID: <8B74D242-DEEC-4C32-BDA8-75099958ED10@gmail.com> On 2008-10-30, at 09:10, Douglas Soo wrote: > - 32 bit floating point gets you around 7 decimal points of > precisions - this means that once you hit a distance of about 256 > meters, you're looking at somewhere around millimeter to centimeter > precision. But you can build up to 4096 meters. > - The larger the area of the region, the more objects we need to > support in order to be able to maintain a reasonable density of > content across an entire simulator node. I think with the 512MB > initial constraint on memory usage at the time that we started, > this was probably a reasonable number. The reason for this thread, really, is that there seems to be a common feeling that SL is too crowded with objects, and the density of objects is too high. Hence the demand for OpenSpaces even before the prim increase. > In any case, this is an incredibly difficult constant to change in > the system - it would require lots of protocol changes, as well as > a fairly major overhaul of the server side, so it's a somewhat moot > discussion right now. :) Regardless, if it's ever going to get changed, we need llGetRegionSize () or equivalent. From me at signpostmarv.name Fri Oct 31 05:01:30 2008 From: me at signpostmarv.name (SignpostMarv Martin) Date: Fri Oct 31 05:01:21 2008 Subject: [sldev] Sim Size Limits? In-Reply-To: <8B74D242-DEEC-4C32-BDA8-75099958ED10@gmail.com> References: <4f335a50810291145w632761f2v6a97f0c8d93e7047@mail.gmail.com> <4908BBEC.10109@mac.com> <08D5CAD2-BFEF-4280-93FC-B0D00AB4D387@gmail.com> <8B74D242-DEEC-4C32-BDA8-75099958ED10@gmail.com> Message-ID: <490AF39A.2090705@signpostmarv.name> >> In any case, this is an incredibly difficult constant to change in >> the system - it would require lots of protocol changes, as well as a >> fairly major overhaul of the server side, so it's a somewhat moot >> discussion right now. :) > > Regardless, if it's ever going to get changed, we need > llGetRegionSize() or equivalent. Returned in most cases as <256.0,256.0,4096.0>, or <256.0,256.0,0.0> ? ~ Marv. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3244 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20081031/1a3004c2/smime.bin From tongb at ohio.edu Fri Oct 31 05:05:28 2008 From: tongb at ohio.edu (Bruce Tong) Date: Fri Oct 31 05:05:31 2008 Subject: [sldev] Sim Size Limits? In-Reply-To: <8B74D242-DEEC-4C32-BDA8-75099958ED10@gmail.com> References: <4f335a50810291145w632761f2v6a97f0c8d93e7047@mail.gmail.com> <4908BBEC.10109@mac.com> <08D5CAD2-BFEF-4280-93FC-B0D00AB4D387@gmail.com> <8B74D242-DEEC-4C32-BDA8-75099958ED10@gmail.com> Message-ID: <4f335a50810310505q1ff56574i92c32bf59793d5b2@mail.gmail.com> On Fri, Oct 31, 2008 at 7:53 AM, Argent Stonecutter wrote: > The reason for this thread, really, is that there seems to be a common > feeling that SL is too crowded with objects, and the density of objects is > too high. Hence the demand for OpenSpaces even before the prim increase. I would say there are two issues that are very different: * Some simulations desire a vast amount of open space that is not economical when sims are always 256m x 256m. * There is a (possibly great) demand for inexpensive, smaller private sims. Those are really marketing and product issues. But technical assumptions and limits are always present. Learning a little about those assumptions and limits was the reason I started the thread, and I appreciate the answers to those questions as well as the discussion that resulted. -- Bruce Tong Software Engineer Office of Information Technology Ohio University From chaosstar at gmail.com Fri Oct 31 05:06:34 2008 From: chaosstar at gmail.com (Ambrosia) Date: Fri Oct 31 05:06:37 2008 Subject: [sldev] Sim Size Limits? In-Reply-To: <490AF39A.2090705@signpostmarv.name> References: <4f335a50810291145w632761f2v6a97f0c8d93e7047@mail.gmail.com> <4908BBEC.10109@mac.com> <08D5CAD2-BFEF-4280-93FC-B0D00AB4D387@gmail.com> <8B74D242-DEEC-4C32-BDA8-75099958ED10@gmail.com> <490AF39A.2090705@signpostmarv.name> Message-ID: <9bb32d430810310506y5cc9083p44007d37b39f1fac@mail.gmail.com> <256.0,256.0,4096.0> I'd say. Makes it easy to autoadjust to new building heights sometime in some future. Also, yeah, I'm all for adding this function, even if no sim size changes will be done anytime soon. It doesn't hurt to add, and will, over the years, remove the issue with scripts not being prepated for any possible change. Someday. On Fri, Oct 31, 2008 at 13:01, SignpostMarv Martin wrote: > >>> In any case, this is an incredibly difficult constant to change in the >>> system - it would require lots of protocol changes, as well as a fairly >>> major overhaul of the server side, so it's a somewhat moot discussion right >>> now. :) >> >> Regardless, if it's ever going to get changed, we need llGetRegionSize() >> or equivalent. > > Returned in most cases as <256.0,256.0,4096.0>, or <256.0,256.0,0.0> ? > > > ~ Marv. > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > From secret.argent at gmail.com Fri Oct 31 05:15:11 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Fri Oct 31 05:14:50 2008 Subject: [sldev] Sim Size Limits? In-Reply-To: <412F7250-B82F-47AC-959F-21EBC231BF55@lindenlab.com> References: <4f335a50810291145w632761f2v6a97f0c8d93e7047@mail.gmail.com><4908BBEC.10109@mac.com><08D5CAD2-BFEF-4280-93FC-B0D00AB4 D387@gmail.com> <3bb9647e0810301952w563f515cx1c9231cf1755b386@mail.gmail.com> <412F7250-B82F-47AC-959F-21EBC231BF55@lindenlab.com> Message-ID: Likely or not, a routine that simply returns the vector "<256,256,4096>" right now seems to be a cheap way of making it possible for you to change your mind in the future. From blindwanderer at gmail.com Fri Oct 31 08:04:16 2008 From: blindwanderer at gmail.com (Strife Onizuka) Date: Fri Oct 31 08:04:19 2008 Subject: [sldev] Wiki & Jira - Database locked - Speculations In-Reply-To: <490A9DFD.9030105@lindenlab.com> References: <89ca6da00810302153x2a453adam32a8a1bfbef03ac1@mail.gmail.com> <490A9DFD.9030105@lindenlab.com> Message-ID: <89ca6da00810310804n4f2c7dd9pda0f501f028fccd5@mail.gmail.com> It's all cool, I assumed it was something you guys were doing (not your service provider). Didn't expect you not to know about it. With cite I was just griping for the sake of griping. There are likely several small extensions we could benefit from, though I can't think of them off hand. The Variables extension makes most things possible, though not all, so I've been able to work around some of these deficiencies (my footnote(s) templates duplicate 90% of the functionality of Cite). The Loop extension would be useful to fill some of the gaps. Breadcrumbs looks promising. We will likely make use of it on LSL Portal content. -- Strife On Fri, Oct 31, 2008 at 1:56 AM, Rob Lanphier wrote: > Strife, the notice is here: > http://status.secondlifegrid.net/ > > We'd update the banner, but unfortunately, the database being in > read-only mode means we can't update it (since the banner is in the db) > > This had nothing to do with the installation of the breadcrumb > extension. Our service provider had a fileserver failure. > > Sorry that Breadcrumb jumped in line in front of Cite. I can't promise > anything since it isn't my call, but I suspect that Cite can get > installed reasonably soon as well. > > Rob > > On 10/30/2008 09:53 PM, Strife Onizuka wrote: > > Both the wiki and jira have their backend databases locked (read > > only). No announcement or real message from the lab. So I'm left > > speculating what is going on. > > > > On the wiki this has been marked with the message "Read only mode. > > Disaster recovery." > > > > I think there is some connection to this and the instillation of > > Extension:BreadCrumbs2 on the wiki but I can't be sure. Mind you I'm > > kinda miffed that they would install that and not install > > Extension:Cite. That's life. Wonder if the Template:Multi-lang update > > had anything to do with it? > > > > Maybe should probably install the version of ParserFunctions that is > > intended to run with 1.13 (and not keep using the version that was > > designed for 1.8 or there abouts) I don't know. > > > > Or maybe the Category bug finally broke the db. Oh god I bet thats it, > > Extension:BreadCrumbs2 depends upon the category system. > > > > -- Strife > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > Policies and (un)subscribe information available here: > > http://wiki.secondlife.com/wiki/SLDev > > Please read the policies before posting to keep unmoderated posting > privileges > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20081031/2f56d04f/attachment-0001.htm From lenglish5 at cox.net Fri Oct 31 08:33:46 2008 From: lenglish5 at cox.net (Lawson English) Date: Fri Oct 31 08:33:49 2008 Subject: [sldev] RX Office hours - General UI discussion - Suggested topic: new approaches to HUDS In-Reply-To: <490A88C5.1070204@gmail.com> References: <907af5560810290852k28959559na669a242c258c519@mail.gmail.com> <232D28A6-025B-44EB-8EA5-2875AA43817F@gmail.com> <105c09f0810302026m273a2431j4550ce873ddff2d3@mail.gmail.com> <490A88C5.1070204@gmail.com> Message-ID: <490B255A.9070602@cox.net> Geneko Nemeth wrote: > In particular, Benjamin Linden's idea that interested residents gather > into an "user experience interest group"(RXIG?) seems to be > well-accepted. In addition, it is suggested that Linden involvement be > reduced to a monthly meeting. > > No Lindens? Whoa. Granted, three Lindens could be a bit too much... > > In any case I hope this could lead to more residents participating in > UX discussion. We could use a better representation of UX needs. > > > Oh yeah, and RXIG isn't really a pretty name. Any ideas? > In the AWG, we use VAG --Viewpoint Advocacy Groups: http://wiki.secondlife.com/wiki/AW_Groupies#Viewpoint_Advocacy_Groups Lawson From soft at lindenlab.com Fri Oct 31 09:46:41 2008 From: soft at lindenlab.com (Soft) Date: Fri Oct 31 09:47:14 2008 Subject: [sldev] Sim Size Limits? In-Reply-To: References: <4f335a50810291145w632761f2v6a97f0c8d93e7047@mail.gmail.com> <4908BBEC.10109@mac.com> <3bb9647e0810301952w563f515cx1c9231cf1755b386@mail.gmail.com> <412F7250-B82F-47AC-959F-21EBC231BF55@lindenlab.com> Message-ID: It's an interesting thought and very easy to implement. Is there a JIRA on this? Also - should the <0,0,0> origin assumption be baked in, or should it be min and max sim extents? On Fri, Oct 31, 2008 at 7:15 AM, Argent Stonecutter wrote: > Likely or not, a routine that simply returns the vector "<256,256,4096>" > right now seems to be a cheap way of making it possible for you to change > your mind in the future. > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > From me at signpostmarv.name Fri Oct 31 10:27:58 2008 From: me at signpostmarv.name (SignpostMarv Martin) Date: Fri Oct 31 10:27:45 2008 Subject: [sldev] Sim Size Limits? In-Reply-To: References: <4f335a50810291145w632761f2v6a97f0c8d93e7047@mail.gmail.com> <4908BBEC.10109@mac.com> <3bb9647e0810301952w563f515cx1c9231cf1755b386@mail.gmail.com> <412F7250-B82F-47AC-959F-21EBC231BF55@lindenlab.com> Message-ID: <490B401E.50005@signpostmarv.name> Well I'd imagine the ZERO_VECTOR origin assumption should be baked in as long as llGetRegionCorner() in global co-ords always corresponds to ZERO_VECTOR in local co-ords. Otherwise I'd recommend llGetRegionDimensions() return [,] where a refers to how far away the point of origin is from llGetRegionCorner()- if a 512x512 sim had a point of origin in the center, so that llGetPos() would return values betwee <-256,-256,0> and <256,256,4096>, would be <128,128,0>. Similar future proofness for stacking sims vertically, <0,0,1024|2048|4096|etc.>. Assuming that there's no issue with dropping lists in as global constants, something such as REGION_DIMENSION_CLASSIC would return [<256,256,4096>,ZERO_VECTOR], enabling any current script to do a quick check of if(llGetRegionDimensions() == REGION_DIMENSION_CLASSIC){ // use old code }else {// put new code here, or warn of potential borkage } ~ Marv. Soft wrote: > It's an interesting thought and very easy to implement. Is there a JIRA on this? > > Also - should the <0,0,0> origin assumption be baked in, or should it > be min and max sim extents? > > On Fri, Oct 31, 2008 at 7:15 AM, Argent Stonecutter > wrote: > >> Likely or not, a routine that simply returns the vector "<256,256,4096>" >> right now seems to be a cheap way of making it possible for you to change >> your mind in the future. >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/SLDev >> Please read the policies before posting to keep unmoderated posting >> privileges >> >> > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges > > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3244 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20081031/e23dcd30/smime.bin From mark at identityserver.net Fri Oct 31 14:09:17 2008 From: mark at identityserver.net (Domino Marama) Date: Fri Oct 31 14:09:30 2008 Subject: [sldev] Oblong Sculptie LODs - Linden support wanted. Message-ID: <1225487357.6580.10.camel@domino-laptop> Members of the community have got together and come up with a fix to the oblong sculptie ratios which would give us exact control over all LODs for some sculptie map sizes. https://jira.secondlife.com/browse/VWR-9384 Unfortunately Qarl doesn't agree with one part of our solution and removing it would basically make a lot of the additional ratios useless. Qarl Linden "unless there's an objection, i'm going to implement everything but the ^2 thing - and you guys are more than welcome to try to get a different linden to take-up your cause." I'm not sure what else I can add to what I've already said in the comments on the Jira, except that a lot of artists would be very happy if someone can take up our cause and convince Qarl that it's worth keeping that part of the patch. Here's hoping! Domino