From yoz at lindenlab.com Fri Oct 1 01:26:46 2010 From: yoz at lindenlab.com (Yoz Grahame) Date: Fri, 1 Oct 2010 01:26:46 -0700 Subject: [opensource-dev] Overview of JPEG 2000 codec In-Reply-To: References: Message-ID: On 30 September 2010 22:05, Patrick N. wrote: > How about this, it should greatly accelerate graphic loading in the > virtual worlds. > > http://code.google.com/intl/en/speed/webp/ > We were discussing that in the office today. It's got promise (for us, anyway - I'd be surprised if it got much traction on the web any time soon) but needs the alpha channel work completed at the very least. Progressive rendering would be nice but it's not vital - we can provide the benefits in other ways. Having another channel we can use for bump maps would also be very helpful. Another format referenced in the discussion is JPEG-XR (originally released as "HD Photo" by Microsoft, now an ISO standard), which has all of the above features. It might be worth doing a comparison, bearing in mind that compression/quality ratio is not the only thing we care about. -- Yoz -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101001/24994f36/attachment.htm From Lance.Corrimal at eregion.de Fri Oct 1 01:54:31 2010 From: Lance.Corrimal at eregion.de (Lance Corrimal) Date: Fri, 1 Oct 2010 10:54:31 +0200 Subject: [opensource-dev] Overview of JPEG 2000 codec In-Reply-To: References: Message-ID: <201010011054.32016.Lance.Corrimal@eregion.de> Am Freitag, 1. Oktober 2010, 10:26:46 schrieb Yoz Grahame: > Another format referenced in the discussion is JPEG-XR (originally released > as "HD Photo" by Microsoft, now an ISO standard), which has all of the > above features. It might be worth doing a comparison, bearing in mind that > compression/quality ratio is not the only thing we care about. did you ever notice how may people are online in SL only at the beginning of the month? ...yes, that's because their connection gets capped after a few days of SL usage... because SL kicks up even more traffic than downloading pirated music 0.o or in other words, minimizing traffic through higher compression of textures could be a nice thing. bye, LC From tom at streamsense.net Fri Oct 1 01:58:46 2010 From: tom at streamsense.net (Thomas Grimshaw) Date: Fri, 01 Oct 2010 09:58:46 +0100 Subject: [opensource-dev] Overview of JPEG 2000 codec In-Reply-To: <201010011054.32016.Lance.Corrimal@eregion.de> References: <201010011054.32016.Lance.Corrimal@eregion.de> Message-ID: <4CA5A2C6.80301@streamsense.net> On 01/10/2010 09:54, Lance Corrimal wrote: > did you ever notice how may people are online in SL only at the > beginning of > the month? ...yes, that's because their connection gets capped after a few days of SL > usage... because SL kicks up even more traffic than downloading pirated music > 0.o Second Life is, at its core, designed to be a bandwidth hungry application, and users need to budget for that. However, an optional discard level cap could be useful to conserve bandwidth for people on crappy ISP's (or in australia) Tom From yoz at lindenlab.com Fri Oct 1 02:35:23 2010 From: yoz at lindenlab.com (Yoz Grahame) Date: Fri, 1 Oct 2010 02:35:23 -0700 Subject: [opensource-dev] Overview of JPEG 2000 codec In-Reply-To: <201010011054.32016.Lance.Corrimal@eregion.de> References: <201010011054.32016.Lance.Corrimal@eregion.de> Message-ID: On 1 October 2010 01:54, Lance Corrimal wrote: > > or in other words, minimizing traffic through higher compression of > textures > could be a nice thing. > Absolutely, and it's a major factor, it's just not the only one. All the recent discussion about OpenJPEG vs KDU is because of decode performance, which is also vital. Plus, the other features I mentioned earlier. -- Yoz -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101001/288af0d9/attachment.htm From missannotoole at yahoo.com Fri Oct 1 02:38:47 2010 From: missannotoole at yahoo.com (Ann Otoole) Date: Fri, 1 Oct 2010 02:38:47 -0700 (PDT) Subject: [opensource-dev] Overview of JPEG 2000 codec In-Reply-To: <201010011054.32016.Lance.Corrimal@eregion.de> References: <201010011054.32016.Lance.Corrimal@eregion.de> Message-ID: <662461.50388.qm@web120509.mail.ne1.yahoo.com> That would indicate we need region/location information panels accessible prior to teleport informing people of the expected bandwidth cost of the location. That way people on bandwidth limited plans can try to avoid going places that are costly. Want more traffic? Learn how to minimize texture counts. ________________________________ From: Lance Corrimal To: opensource-dev at lists.secondlife.com Sent: Fri, October 1, 2010 4:54:31 AM Subject: Re: [opensource-dev] Overview of JPEG 2000 codec Am Freitag, 1. Oktober 2010, 10:26:46 schrieb Yoz Grahame: > Another format referenced in the discussion is JPEG-XR (originally released > as "HD Photo" by Microsoft, now an ISO standard), which has all of the > above features. It might be worth doing a comparison, bearing in mind that > compression/quality ratio is not the only thing we care about. did you ever notice how may people are online in SL only at the beginning of the month? ...yes, that's because their connection gets capped after a few days of SL usage... because SL kicks up even more traffic than downloading pirated music 0.o or in other words, minimizing traffic through higher compression of textures could be a nice thing. bye, LC _______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101001/eb5192b0/attachment.htm From chaosstar at gmail.com Fri Oct 1 02:52:39 2010 From: chaosstar at gmail.com (Ambrosia) Date: Fri, 1 Oct 2010 11:52:39 +0200 Subject: [opensource-dev] Overview of JPEG 2000 codec In-Reply-To: References: Message-ID: I hope the point was brought up that Webp only does lossy compression tho, while Jpeg2k Also does lossless. In light of sculpts requiring lossless compression, I'd not expect the need for a jpeg2k decoder to go away anytime soon for at least that kind of texture, alas, unless lossless textures'd get stored as PNG images. PNGs result in smaller files than Jpeg2k when the image is a classic type of texture that'd use lossless compression, like cliparts with lots of pixels of the same color, tho Jpeg2k seems to excel at lossless compression when complex images are involved. > We were discussing that in the office today. It's got promise (for us, > anyway - I'd be surprised if it got much traction on the web any time soon) > but needs the alpha channel work completed at the very least. Progressive > rendering would be nice but it's not vital - we can provide the benefits in > other ways. Having another channel we can use for bump maps would also be > very helpful. > Another format referenced in the discussion is JPEG-XR (originally released > as "HD Photo" by Microsoft, now an ISO standard), which has all of the above > features. It might be worth doing a comparison, bearing in mind that > compression/quality ratio is not the only thing we care about. > -- Yoz > From jicall2002 at yahoo.com Fri Oct 1 03:12:20 2010 From: jicall2002 at yahoo.com (Elenia) Date: Fri, 1 Oct 2010 03:12:20 -0700 (PDT) Subject: [opensource-dev] New features in beta version of today... ? Message-ID: <849936.11860.qm@web55505.mail.re4.yahoo.com> Laurent Bechir has wrote : >> Hello, >> Is there new features in this week version of 2.2 beta viewer like there >> was last week? or is it just bug fixes this time ? Im' trying to do >> videos in french to show the new features when they are some :) hello here you are an abstract on the new features of 2.2 beta viewer in french http://forums.jeuxonline.info/showpost.php?p=21418763&postcount=1 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101001/c5d79ab6/attachment.htm From laurent.bechir at madonie.org Fri Oct 1 05:34:00 2010 From: laurent.bechir at madonie.org (Laurent Bechir) Date: Fri, 01 Oct 2010 14:34:00 +0200 Subject: [opensource-dev] New features in beta version of today... ? In-Reply-To: <849936.11860.qm@web55505.mail.re4.yahoo.com> References: <849936.11860.qm@web55505.mail.re4.yahoo.com> Message-ID: <4CA5D538.7000800@madonie.org> Elenia a ?crit : > hello > > here you are an abstract on the new features of 2.2 beta viewer in french > http://forums.jeuxonline.info/showpost.php?p=21418763&postcount=1 > Thank you. In fact I've already put these in a first video : http://youtu.be/OfHz-CuzcOI?hd=1 I just missed the double click teleport feature. It will be in a next one. I was wondering if 2.2 will have other features added before its release. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101001/ad9e18b5/attachment-0001.htm From hitomi.tiponi at yahoo.co.uk Fri Oct 1 05:45:57 2010 From: hitomi.tiponi at yahoo.co.uk (Hitomi Tiponi) Date: Fri, 1 Oct 2010 12:45:57 +0000 (GMT) Subject: [opensource-dev] New features in beta version of today... ? Message-ID: <363439.10965.qm@web23908.mail.ird.yahoo.com> There isn't much there - mainly bug fixes and tidying up. Even since that release there has been very little new functionaliy. Incidentally it seems that 210676 bears little resemblance to 210670 or 210680 - maybe Esbee got fed up of all the changes that Richard Linden did to the Viewer and ditched them (despite them having come in between beta versions). I know I was as they plugged a loophole (using 'panels' under 'layout_stack') that I was exploiting to get StarLight to work and meant several hours of re-coding :(. >Hello, > >Is there new features in this week version of 2.2 beta viewer like there >was last week or is it just bug fixes this time ? Im' trying to do >videos in french to show the new features when they are some :) > >Thank you -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101001/06440923/attachment.htm From wolfpup67 at earthlink.net Fri Oct 1 05:54:09 2010 From: wolfpup67 at earthlink.net (WolfPup Lowenhar) Date: Fri, 1 Oct 2010 08:54:09 -0400 Subject: [opensource-dev] New features in beta version of today... ? In-Reply-To: <363439.10965.qm@web23908.mail.ird.yahoo.com> References: <363439.10965.qm@web23908.mail.ird.yahoo.com> Message-ID: <001201cb6167$bd838530$388a8f90$@net> Actualy Richard Linden?s work landed in viewer-development two days after the beta was branched off. And there are some issues that have come about since the drop that are being worked on. So his work should appear in the next beta after all the issues have been corrected(bug fixing). From: opensource-dev-bounces at lists.secondlife.com [mailto:opensource-dev-bounces at lists.secondlife.com] On Behalf Of Hitomi Tiponi Sent: Friday, October 01, 2010 8:46 AM To: Opensource_dev Subject: Re: [opensource-dev] New features in beta version of today... ? There isn't much there - mainly bug fixes and tidying up. Even since that release there has been very little new functionaliy. Incidentally it seems that 210676 bears little resemblance to 210670 or 210680 - maybe Esbee got fed up of all the changes that Richard Linden did to the Viewer and ditched them (despite them having come in between beta versions). I know I was as they plugged a loophole (using 'panels' under 'layout_stack') that I was exploiting to get StarLight to work and meant several hours of re-coding :(. >Hello, > >Is there new features in this week version of 2.2 beta viewer like there >was last week or is it just bug fixes this time ? Im' trying to do >videos in french to show the new features when they are some :) > >Thank you No virus found in this incoming message. Checked by AVG - www.avg.com Version: 9.0.856 / Virus Database: 271.1.1/3170 - Release Date: 10/01/10 02:34:00 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101001/64868730/attachment.htm From soft at lindenlab.com Fri Oct 1 06:06:36 2010 From: soft at lindenlab.com (Brian McGroarty) Date: Fri, 1 Oct 2010 06:06:36 -0700 Subject: [opensource-dev] Overview of JPEG 2000 codec In-Reply-To: <201010011054.32016.Lance.Corrimal@eregion.de> References: <201010011054.32016.Lance.Corrimal@eregion.de> Message-ID: On Fri, Oct 1, 2010 at 1:54 AM, Lance Corrimal wrote: > Am Freitag, 1. Oktober 2010, 10:26:46 schrieb Yoz Grahame: > > > Another format referenced in the discussion is JPEG-XR (originally > released > > as "HD Photo" by Microsoft, now an ISO standard), which has all of the > > above features. It might be worth doing a comparison, bearing in mind > that > > compression/quality ratio is not the only thing we care about. > > did you ever notice how may people are online in SL only at the beginning > of > the month? > > ...yes, that's because their connection gets capped after a few days of SL > usage... because SL kicks up even more traffic than downloading pirated > music > The concurrency charts don't show evidence of this monthly cycle. -- Brian McGroarty | Linden Lab Sent from my Newton MP2100 via acoustic coupler -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101001/cf499580/attachment.htm From esbee at lindenlab.com Fri Oct 1 06:43:11 2010 From: esbee at lindenlab.com (Sarah (Esbee) Hutchinson) Date: Fri, 1 Oct 2010 09:43:11 -0400 Subject: [opensource-dev] Reminder - New time for Snowstorm Daily Scrum Meetings Message-ID: Good morning all, My email to the list appears not to have made it to the list yesterday, so I'm resending now. Starting today, the Snowstorm Daily Scrum meetings will now be held at 10:30am PT. I'll be announcing new times for our sprint planning, retrospective and review meetings by the end of the day as well. Best, Esbee -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101001/2c4e9a56/attachment.htm From esbee at lindenlab.com Fri Oct 1 07:37:34 2010 From: esbee at lindenlab.com (Sarah (Esbee) Hutchinson) Date: Fri, 1 Oct 2010 10:37:34 -0400 Subject: [opensource-dev] New features in beta version of today... ? In-Reply-To: <001201cb6167$bd838530$388a8f90$@net> References: <363439.10965.qm@web23908.mail.ird.yahoo.com> <001201cb6167$bd838530$388a8f90$@net> Message-ID: As Wolfpup notes, we didn't get the work from Richard until after the Viewer 2.2 Beta was cut. We won't be introducing new work from viewer-development until this Beta cycle is complete and the current beta has gone to Release. - Esbee On Fri, Oct 1, 2010 at 8:54 AM, WolfPup Lowenhar wrote: > Actualy Richard Linden?s work landed in viewer-development two days after > the beta was branched off. And there are some issues that have come about > since the drop that are being worked on. So his work should appear in the > next beta after all the issues have been corrected(bug fixing). > > > > *From:* opensource-dev-bounces at lists.secondlife.com [mailto: > opensource-dev-bounces at lists.secondlife.com] *On Behalf Of *Hitomi Tiponi > *Sent:* Friday, October 01, 2010 8:46 AM > *To:* Opensource_dev > *Subject:* Re: [opensource-dev] New features in beta version of today... ? > > > > There isn't much there - mainly bug fixes and tidying up. Even since that > release there has been very little new functionaliy. > > Incidentally it seems that 210676 bears little resemblance to 210670 or > 210680 - maybe Esbee got fed up of all the changes that Richard Linden did > to the Viewer and ditched them (despite them having come in between beta > versions). I know I was as they plugged a loophole (using 'panels' under > 'layout_stack') that I was exploiting to get StarLight to work and meant > several hours of re-coding :(. > > >Hello, > > > >Is there new features in this week version of 2.2 beta viewer like there > >was last week or is it just bug fixes this time ? Im' trying to do > >videos in french to show the new features when they are some :) > > > >Thank you > > > > No virus found in this incoming message. > Checked by AVG - www.avg.com > Version: 9.0.856 / Virus Database: 271.1.1/3170 - Release Date: 10/01/10 > 02:34:00 > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101001/0abf8973/attachment.htm From gigstaggart at gmail.com Fri Oct 1 09:50:46 2010 From: gigstaggart at gmail.com (Gigs) Date: Fri, 01 Oct 2010 12:50:46 -0400 Subject: [opensource-dev] 2.0 Absolute Dealbreaker - script count feature request In-Reply-To: References: <742565.2526.qm@web82101.mail.mud.yahoo.com> Message-ID: <4CA61166.1020404@gmail.com> On 09/29/2010 07:06 PM, Kelly Linden wrote: > * In my mind the biggest issue is that mono scripts will appear 4x worse > than LSL scripts. This is really the reason I am hesitant to push a > function like this through before we have the ability for mono scripts > to better reflect how much memory they may use. We need more development > time for any solution on that front. Right now because a mono script > could use 64k, that is the only number we have available to count. Maybe > it would be nice to have an API to access number of scripts, number of > LSL vs. Mono scripts, amount of memory used and script time used. > However we rapidly get away from my desired philosophy of minimal > interfaces. Don't overcomplicate things. Just count mono scripts as 16k as well. The average size of them is less than 16k, so it's still a conservative number. We don't need perfection. The person with 255 scripts in each shoe will still show up as using a lot. Splitting hairs over kilobyte perfect accuracy is pointless. -Jason From lee.ponzu at gmail.com Fri Oct 1 10:04:07 2010 From: lee.ponzu at gmail.com (Ponzu) Date: Fri, 1 Oct 2010 13:04:07 -0400 Subject: [opensource-dev] Faster for people with crappy internet? (was Re: Overview of JPEG 2000 codec Message-ID: On Fri, Oct 1, 2010 at 4:58 AM, Thomas Grimshaw wrote: > On 01/10/2010 09:54, Lance Corrimal wrote: > > did you ever notice how may people are online in SL only at the > > beginning of > > the month? ...yes, that's because their connection gets capped after a > few days of SL > > usage... because SL kicks up even more traffic than downloading pirated > music > > 0.o > I have never seen this reflected in the concurrency data. Maybe it is only a myth. > > Second Life is, at its core, designed to be a bandwidth hungry > application, and users need to budget for that. > > However, an optional discard level cap could be useful to conserve > bandwidth for people on crappy ISP's (or in australia) > > Nobody has crappier internet than I (satellite). However, before expending any resources on making SL Faster for people with crappy internet, first you need to show that there are enough of us to matter, and also that our internet won't be improving any time soon. No sense making expensive changes (cheap ones are fine 8-) for a dwindling group of users. Which begs the question: What does the internet connection of current users look like, and how is that population changing or likely to change in the future? regards, ponzu -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101001/42ecdd96/attachment.htm From tom at streamsense.net Fri Oct 1 10:06:04 2010 From: tom at streamsense.net (Thomas Grimshaw) Date: Fri, 01 Oct 2010 18:06:04 +0100 Subject: [opensource-dev] Faster for people with crappy internet? (was Re: Overview of JPEG 2000 codec In-Reply-To: References: Message-ID: <4CA614FC.5080401@streamsense.net> On 01/10/2010 18:04, Ponzu wrote: > Nobody has crappier internet than I (satellite). Well, we're really talking about transfer caps, here, rather than available bandwidth. Available bandwidth can be appeased by the network slider. But transfer caps are the biggest problem, and pretty much everyone in Australia is affected, and a lot of people on the less decent ISP's in the UK. From q at lindenlab.com Fri Oct 1 10:07:58 2010 From: q at lindenlab.com (Kent Quirk (Q Linden)) Date: Fri, 1 Oct 2010 13:07:58 -0400 Subject: [opensource-dev] 2.0 Absolute Dealbreaker - script count feature request In-Reply-To: <4CA61166.1020404@gmail.com> References: <742565.2526.qm@web82101.mail.mud.yahoo.com> <4CA61166.1020404@gmail.com> Message-ID: On Oct 1, 2010, at 12:50 PM, Gigs wrote: > On 09/29/2010 07:06 PM, Kelly Linden wrote: >> * In my mind the biggest issue is that mono scripts will appear 4x worse >> than LSL scripts. This is really the reason I am hesitant to push a >> function like this through before we have the ability for mono scripts >> to better reflect how much memory they may use. We need more development >> time for any solution on that front. Right now because a mono script >> could use 64k, that is the only number we have available to count. Maybe >> it would be nice to have an API to access number of scripts, number of >> LSL vs. Mono scripts, amount of memory used and script time used. >> However we rapidly get away from my desired philosophy of minimal >> interfaces. > > > Don't overcomplicate things. Just count mono scripts as 16k as well. > The average size of them is less than 16k, so it's still a conservative > number. > > We don't need perfection. The person with 255 scripts in each shoe will > still show up as using a lot. Splitting hairs over kilobyte perfect > accuracy is pointless. > I don't actually have an opinion about the right answer, but I will note that if this is going to be used for things like banning people, then we can't ever change it to be something accurate later. The pattern we see is: * We build something that has a numeric limit * Someone builds something that pushes right to the limit * We change something, and the thing that used to work no longer works * People scream that we broke content So if we create a call that returns approximate results now, it *always* has to return the same results. This is one reason we are reluctant to add new measurements; people come to depend on them even when they shouldn't. Q From lee.ponzu at gmail.com Fri Oct 1 10:11:33 2010 From: lee.ponzu at gmail.com (Ponzu) Date: Fri, 1 Oct 2010 13:11:33 -0400 Subject: [opensource-dev] 2.0 Absolute Dealbreaker - script count feature request In-Reply-To: <4CA61166.1020404@gmail.com> References: <742565.2526.qm@web82101.mail.mud.yahoo.com> <4CA61166.1020404@gmail.com> Message-ID: On Fri, Oct 1, 2010 at 12:50 PM, Gigs wrote: > > > Don't overcomplicate things. Just count mono scripts as 16k as well. > The average size of them is less than 16k, so it's still a conservative > number. > > We don't need perfection. The person with 255 scripts in each shoe will > still show up as using a lot. Splitting hairs over kilobyte perfect > accuracy is pointless. > > Good point. So, maybe a simple interface would be to provide number of mono scripts and number of non-mono scripts. User could make his own memory per script estimates and multiply to get memory estimate, if needed. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101001/ae62118c/attachment.htm From suezanne at gmail.com Fri Oct 1 10:15:44 2010 From: suezanne at gmail.com (SuezanneC Baskerville) Date: Fri, 1 Oct 2010 12:15:44 -0500 Subject: [opensource-dev] WebP, a new image format for the Web Message-ID: Google is putting out a new open source image format, said to offer higher compression rates than JPEG2000. I just thought someone with the appropriate technical knowledge ought to take a look at in case it might be useful for use in Second Life. http://blog.chromium.org/2010/09/webp-new-image-format-for-web.html<%20http://blog.chromium.org/2010/09/webp-new-image-format-for-web.html> *To improve on the compression that JPEG provides, we used an image > compressor based on the VP8 codec that Google open-sourcedin May 2010. We applied the techniques from VP8 video intra frame coding to > push the envelope in still image coding. We also adapted a very lightweight > container based on RIFF. > While this container format contributes a minimal overhead of only 20 bytes > per image, it is extensible to allow authors to save meta-data they would > like to store. > > While the benefits of a VP8 based image format were clear in theory, we > needed to test them in the real world. In order to gauge the effectiveness > of our efforts, we randomly picked about 1,000,000 images from the web > (mostly JPEGs and some PNGs and GIFs) and re-encoded them to WebP without > perceptibly compromising visual quality. This resulted in an average 39% > reduction in file size. We expect that developers will achieve in practice > even better file size reduction with WebP when starting from an uncompressed > image. > * http://code.google.com/speed/webp/ -- v i r t u a l w o r l d e n t h u s i a s t -- http://www.google.com/profiles/s u e z a n n e -- -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101001/5ee7a5ed/attachment.htm From overdrive at dceo.rutgers.edu Fri Oct 1 10:33:48 2010 From: overdrive at dceo.rutgers.edu (Ron Festa) Date: Fri, 1 Oct 2010 13:33:48 -0400 Subject: [opensource-dev] WebP, a new image format for the Web In-Reply-To: References: Message-ID: VP8 focuses too much on PSNR which for still photo usage comes out blurrier. Plus Google's ref-spec VP8 is not exactly known for being CPU friendly on encode or decode. Even then they're comparing to standard JPEG, not JPEG2000 which there has yet to be a comparison test of. Even then its an unproven format that so far only shows its better at compression then standard JPEG even when jpgcrunch is used. IMO, its not worth using until the issues are resolved and even then its still got a long way to go for adoption. Ron Festa Virtual Worlds Admin Division of Continuing Studies at Rutgers University PGP key: http://bit.ly/b1ZyhY Phone: 732-474-8583 On Fri, Oct 1, 2010 at 1:15 PM, SuezanneC Baskerville wrote: > Google is putting out a new open source image format, said to offer higher > compression rates than JPEG2000. > > I just thought someone with the appropriate technical knowledge ought to > take a look at in case it might be useful for use in Second Life. > > http://blog.chromium.org/2010/09/webp-new-image-format-for-web.html > > *To improve on the compression that JPEG provides, we used an image >> compressor based on the VP8 codec that Google open-sourcedin May 2010. We applied the techniques from VP8 video intra frame coding to >> push the envelope in still image coding. We also adapted a very lightweight >> container based on RIFF. >> While this container format contributes a minimal overhead of only 20 bytes >> per image, it is extensible to allow authors to save meta-data they would >> like to store. >> >> While the benefits of a VP8 based image format were clear in theory, we >> needed to test them in the real world. In order to gauge the effectiveness >> of our efforts, we randomly picked about 1,000,000 images from the web >> (mostly JPEGs and some PNGs and GIFs) and re-encoded them to WebP without >> perceptibly compromising visual quality. This resulted in an average 39% >> reduction in file size. We expect that developers will achieve in practice >> even better file size reduction with WebP when starting from an uncompressed >> image. >> * > > > http://code.google.com/speed/webp/ > -- > v i r t u a l w o r l d e n t h u s i a s t > -- http://www.google.com/profiles/s u e z a n n e -- > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101001/74388249/attachment.htm From overdrive at dceo.rutgers.edu Fri Oct 1 10:35:49 2010 From: overdrive at dceo.rutgers.edu (Ron Festa) Date: Fri, 1 Oct 2010 13:35:49 -0400 Subject: [opensource-dev] WebP, a new image format for the Web In-Reply-To: References: Message-ID: Also forgot to add this link as its a good write up and comparison of x264 vs vp8 vs JPEG w/jpgcrunch for still images: http://x264dev.multimedia.cx/?p=541 Ron Festa Virtual Worlds Admin Division of Continuing Studies at Rutgers University PGP key: http://bit.ly/b1ZyhY Phone: 732-474-8583 On Fri, Oct 1, 2010 at 1:33 PM, Ron Festa wrote: > VP8 focuses too much on PSNR which for still photo usage comes out > blurrier. Plus Google's ref-spec VP8 is not exactly known for being CPU > friendly on encode or decode. Even then they're comparing to standard JPEG, > not JPEG2000 which there has yet to be a comparison test of. Even then its > an unproven format that so far only shows its better at compression then > standard JPEG even when jpgcrunch is used. IMO, its not worth using until > the issues are resolved and even then its still got a long way to go for > adoption. > > Ron Festa > Virtual Worlds Admin > Division of Continuing Studies at Rutgers University > PGP key: http://bit.ly/b1ZyhY > Phone: 732-474-8583 > > > On Fri, Oct 1, 2010 at 1:15 PM, SuezanneC Baskerville wrote: > >> Google is putting out a new open source image format, said to offer higher >> compression rates than JPEG2000. >> >> I just thought someone with the appropriate technical knowledge ought to >> take a look at in case it might be useful for use in Second Life. >> >> http://blog.chromium.org/2010/09/webp-new-image-format-for-web.html >> >> *To improve on the compression that JPEG provides, we used an image >>> compressor based on the VP8 codec that Google open-sourcedin May 2010. We applied the techniques from VP8 video intra frame coding to >>> push the envelope in still image coding. We also adapted a very lightweight >>> container based on RIFF. >>> While this container format contributes a minimal overhead of only 20 bytes >>> per image, it is extensible to allow authors to save meta-data they would >>> like to store. >>> >>> While the benefits of a VP8 based image format were clear in theory, we >>> needed to test them in the real world. In order to gauge the effectiveness >>> of our efforts, we randomly picked about 1,000,000 images from the web >>> (mostly JPEGs and some PNGs and GIFs) and re-encoded them to WebP without >>> perceptibly compromising visual quality. This resulted in an average 39% >>> reduction in file size. We expect that developers will achieve in practice >>> even better file size reduction with WebP when starting from an uncompressed >>> image. >>> * >> >> >> http://code.google.com/speed/webp/ >> -- >> v i r t u a l w o r l d e n t h u s i a s t >> -- http://www.google.com/profiles/s u e z a n n e -- >> >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/OpenSource-Dev >> Please read the policies before posting to keep unmoderated posting >> privileges >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101001/57b580b9/attachment-0001.htm From tateru at taterunino.net Fri Oct 1 10:45:21 2010 From: tateru at taterunino.net (Tateru Nino) Date: Sat, 02 Oct 2010 03:45:21 +1000 Subject: [opensource-dev] WebP, a new image format for the Web In-Reply-To: References: Message-ID: <4CA61E31.1050601@taterunino.net> Hmm. Only supports a single image data chunk and no alpha channels in this release. True, you could break compatibility and extend it, but I'm not sure that's really the way to go. Not close to a drop-in replacement yet, even after banging it on some rocks. On 2/10/2010 3:15 AM, SuezanneC Baskerville wrote: > Google is putting out a new open source image format, said to offer > higher compression rates than JPEG2000. > > I just thought someone with the appropriate technical knowledge ought > to take a look at in case it might be useful for use in Second Life. > > http://blog.chromium.org/2010/09/webp-new-image-format-for-web.html > <%20http://blog.chromium.org/2010/09/webp-new-image-format-for-web.html> > > /To improve on the compression that JPEG provides, we used an > image compressor based on the VP8 codec that Google open-sourced > > in May 2010. We applied the techniques from VP8 video intra frame > coding to push the envelope in still image coding. We also adapted > a very lightweight container based on RIFF > . > While this container format contributes a minimal overhead of only > 20 bytes per image, it is extensible to allow authors to save > meta-data they would like to store. > > While the benefits of a VP8 based image format were clear in > theory, we needed to test them in the real world. In order to > gauge the effectiveness of our efforts, we randomly picked about > 1,000,000 images from the web (mostly JPEGs and some PNGs and > GIFs) and re-encoded them to WebP without perceptibly compromising > visual quality. This resulted in an average 39% reduction in file > size. We expect that developers will achieve in practice even > better file size reduction with WebP when starting from an > uncompressed image. > / > > > http://code.google.com/speed/webp/ > -- > v i r t u a l w o r l d e n t h u s i a s t > -- http://www.google.com/profiles/s u e z a n n e -- > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting privileges -- Tateru Nino http://dwellonit.taterunino.net/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101002/3cd0dc31/attachment.htm From lee.ponzu at gmail.com Fri Oct 1 11:41:27 2010 From: lee.ponzu at gmail.com (Ponzu) Date: Fri, 1 Oct 2010 14:41:27 -0400 Subject: [opensource-dev] Faster for people with crappy internet? (was Re: Overview of JPEG 2000 codec In-Reply-To: <4CA614FC.5080401@streamsense.net> References: <4CA614FC.5080401@streamsense.net> Message-ID: On Fri, Oct 1, 2010 at 1:06 PM, Thomas Grimshaw wrote: > On 01/10/2010 18:04, Ponzu wrote: > >> Nobody has crappier internet than I (satellite). >> > > Well, we're really talking about transfer caps, here, rather than available > bandwidth. > > Available bandwidth can be appeased by the network slider. But transfer > caps are the biggest problem, and pretty much everyone in Australia is > affected, and a lot of people on the less decent ISP's in the UK. > > and me. 17GB per 30 day period, in a sliding window. Point is still that caps will be increased as time goes on (or decreased, as international economic system collapses, but taht is a differnt sim). -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101001/e237192e/attachment.htm From lee.ponzu at gmail.com Fri Oct 1 11:43:43 2010 From: lee.ponzu at gmail.com (Ponzu) Date: Fri, 1 Oct 2010 14:43:43 -0400 Subject: [opensource-dev] 2.0 Absolute Dealbreaker - script count feature request In-Reply-To: References: <742565.2526.qm@web82101.mail.mud.yahoo.com> <4CA61166.1020404@gmail.com> Message-ID: On Fri, Oct 1, 2010 at 1:07 PM, Kent Quirk (Q Linden) wrote: > > > > I don't actually have an opinion about the right answer, but I will note > that if this is going to be used for things like banning people, then we > can't ever change it to be something accurate later. The pattern we see is: > > * We build something that has a numeric limit > * Someone builds something that pushes right to the limit > * We change something, and the thing that used to work no longer works > * People scream that we broke content > > So if we create a call that returns approximate results now, it *always* > has to return the same results. > > At some point (sooner better than later) SL has to start obsoleting old ways of doing things. To my way of thinking, it is better to obsolete a little bit overy so often rather than keep backwad compatibility until you have to break a lot at once. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101001/f0cb5459/attachment.htm From esbee at lindenlab.com Fri Oct 1 11:49:08 2010 From: esbee at lindenlab.com (Sarah (Esbee) Hutchinson) Date: Fri, 1 Oct 2010 14:49:08 -0400 Subject: [opensource-dev] Snowstorm Daily Scrum Summary - Friday, October 1, 2010 Message-ID: Date: Tue Oct 1, 2010 Also available here: https://wiki.secondlife.com/wiki/Snowstorm_Daily_Scrum_Archive *=== General Notes ===* * Focusing this week on Second Life Viewer 2.2 Beta bug fixes. We'll spin up Sprint 5 next week. *===Team Status===* * * * ====Merov Linden==== PAST * STORM-306: water flicker issue: fork beta, move bugs, port SNOW-643 (Aleric's fix), this is done but it doesn't solve the issue at hand :( FUTURE * STORM-306: I've an idea using SG 2.0/2.1 as a benchmark to isolate the commit that shows the bug. Good use of my time? * STORM-137 : FMOD issue: fix upload issue with Brad. Hopefully, the rest will be easy. * Check incoming 2.2.0 beta bugs * STORM-105 : Perf decompression: put new data out, check the work done by opensource-dev community on similar tests. IMPEDIMENTS * Kakadu license upgrade ====Oz Linden==== OOO - Vacation ====Q Linden==== PAST * lots of administrivia and process work * some discussion about test automation * triage FUTURE * hr, administration * triage IMPEDIMENTS * 24 hours in a day ====Esbee Linden==== PAST * VWR triage * Process discussion * Bug hunting * Backlog reviews FUTURE * VWR triage * Backlog grooming & new feature request review * Prep for Sprint 5 * Find new meeting times for Sprint Planning, Retrospective, and Review meetings * Viewer roadmap planning IMPEDIMENTS * None ====Paul ProductEngine==== PAST * STORM-212 Gear button is always disabled in My Profile->My Picks ** Fixed * STROM-263 Cog button in lower-left of sidebar panel does not close popup menu on second click ** Estimate ~8 hours. Need to finish fix according to Vadim's comments. FUTURE * STORM-263 Cog button in lower-left of sidebar panel does not close popup menu on second click IMPEDIMENTS *none ====Andrew ProductEngine==== PAST * Major bug STORM-160 (Mini-inspector floater doesn't appear after click on 'i' icon in IM or Nearby chat window) ** Closed as cannot reproduce again. * Bug STORM-250 (Unexpected "More" text appears in the About Landmark panel after minimising the floater). ** Not sure about estimate, naybe 6 more hours, but hope there will be someone more familiar with this code who'll help. FUTURE * STORM-250 (Unexpected "More" text appears in the About Landmark panel after minimising the floater). IMPEDIMENTS *none ====Vadim ProductEngine==== PAST *Task STORM-214 (URL-name of pick is shown as hyperlink on 'My Picks' SP): ** Implemented. * Task STORM-215 (URL-name of group is shown as hyperlink on Build Tools' floater): ** Implemented. * Bug STORM-261 (In V2.2.0 Script Editor, cannot see any line numbers other than the current one): ** Resolved as not reproducible. * Bug STORM-268 (Texture Edit - Pick Texture Window drops the vertical scroll bar): ** Resolved as not reproducible. * Bug STORM-222 (indra/llxuixml/llxuiparser.cpp:32:25: error: expat/expat.h: No such file or directory): ** Reviewed. FUTURE * Bug STORM-213 (URL-name of object is shown as hyperlink on group notification toast). IMPEDIMENTS * We need more tasks. :-) ====Seth ProductEngine (Sergey)==== PAST * BUG (STORM-278) Inventory does not fully load until I make a search ** Could not reproduce the issue using reporter's scenario. * BUG (STORM-264) Resize grab areas on detached sidebar panels are tiny and unmarked ** WIP. Added resize handles. Working on detached tabs resizing. FUTURE * BUG (STORM-264) Resize grab areas on detached sidebar panels are tiny and unmarked ** Estimated: 1 - 2 hours. * BUG (STORM-214) URL-name of pick is shown as hyperlink on 'My Picks' SP ** Estimated: 4 - 6 hours. IMPEDIMENTS * none ====Andrey ProductEngine==== PAST * smoke & integration testing of 210676 done on Win7, OSX, Linux FUTURE * do regression testing in scope defined in DRTVWR-4 IMPEDIMENTS * none ====Grumpity ProductEngine (Anya)==== PAST * QA going forward meeting & planning FUTURE * Future QA process meeting IMPEDIMENTS *need new s3 key * who will be merge monkey once we hit oct1? * what about those code reviews? * -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101001/9725cb3d/attachment-0001.htm From esbee at lindenlab.com Fri Oct 1 12:13:22 2010 From: esbee at lindenlab.com (Sarah (Esbee) Hutchinson) Date: Fri, 1 Oct 2010 15:13:22 -0400 Subject: [opensource-dev] New Snowstorm Team Scrum Meeting Times Message-ID: Hi all, I've just finished adjusting our team calendar to reflect our new meeting times - these should work well for both east and west coasters moving forward. :) *Snowstorm Team Daily Scrum - *Daily from 10:30-10:45am PT *Sprint Planning Meeting - *Every two weeks on Tuesday from 10-1pm PT *Next one is Tuesday, Oct 5* *Sprint Review Meeting - *Every two weeks on Friday from 1-2pm PT *Next one is Friday, Oct 15* *Sprint Retrospective Meeting - *Every two weeks on Monday from 11:30-12:30pm PT *Next one if Monday, Oct 18* * * *Snowstorm Team Members - If you have any overlaps, please make every effort to rearrange other meetings so we won't have to move these meetings around weekly. Thank you!!* * * Cheers! Esbee -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101001/d96a33bd/attachment.htm From soft at lindenlab.com Fri Oct 1 12:22:58 2010 From: soft at lindenlab.com (Brian McGroarty) Date: Fri, 1 Oct 2010 12:22:58 -0700 Subject: [opensource-dev] Faster for people with crappy internet? (was Re: Overview of JPEG 2000 codec In-Reply-To: References: <4CA614FC.5080401@streamsense.net> Message-ID: On Fri, Oct 1, 2010 at 11:41 AM, Ponzu wrote: > On Fri, Oct 1, 2010 at 1:06 PM, Thomas Grimshaw wrote: > >> On 01/10/2010 18:04, Ponzu wrote: >> >>> Nobody has crappier internet than I (satellite). >>> >> >> Well, we're really talking about transfer caps, here, rather than >> available bandwidth. >> >> Available bandwidth can be appeased by the network slider. But transfer >> caps are the biggest problem, and pretty much everyone in Australia is >> affected, and a lot of people on the less decent ISP's in the UK. >> >> > and me. 17GB per 30 day period, in a sliding window. > > Point is still that caps will be increased as time goes on (or decreased, > as international economic system collapses, but taht is a differnt sim). > Devs concerned about crazy-limited connections shouldn't worry about the small changes that may someday come with a different image CODEC. They can cut texture transfers in half -today- at the expense of texture blurriness. A test should be straightforward, if anyone feels strongly enough to take a whack at it. Add a "texture fidelity" slider that scales the measure the viewer uses to decide what discard level it wants. See where you still find it tolerable. -- Brian McGroarty | Linden Lab Sent from my Newton MP2100 via acoustic coupler -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101001/8934a3fa/attachment.htm From tateru.nino at gmail.com Fri Oct 1 12:45:38 2010 From: tateru.nino at gmail.com (Tateru Nino) Date: Sat, 02 Oct 2010 05:45:38 +1000 Subject: [opensource-dev] Faster for people with crappy internet? (was Re: Overview of JPEG 2000 codec In-Reply-To: References: <4CA614FC.5080401@streamsense.net> Message-ID: <4CA63A62.5090906@gmail.com> On 2/10/2010 5:22 AM, Brian McGroarty wrote: > On Fri, Oct 1, 2010 at 11:41 AM, Ponzu > wrote: > > On Fri, Oct 1, 2010 at 1:06 PM, Thomas Grimshaw > > wrote: > > On 01/10/2010 18:04, Ponzu wrote: > > Nobody has crappier internet than I (satellite). > > > Well, we're really talking about transfer caps, here, rather > than available bandwidth. > > Available bandwidth can be appeased by the network slider. > But transfer caps are the biggest problem, and pretty much > everyone in Australia is affected, and a lot of people on the > less decent ISP's in the UK. > > > and me. 17GB per 30 day period, in a sliding window. > Point is still that caps will be increased as time goes on (or > decreased, as international economic system collapses, but taht is > a differnt sim). > > > Devs concerned about crazy-limited connections shouldn't worry about > the small changes that may someday come with a different image CODEC. > They can cut texture transfers in half -today- at the expense of > texture blurriness. > > A test should be straightforward, if anyone feels strongly enough to > take a whack at it. Add a "texture fidelity" slider that scales the > measure the viewer uses to decide what discard level it wants. See > where you still find it tolerable. I read that three times, with different reactions. After a little thought, though, yes. I'd _totally_ use that if it were an option. Right on the main UI next to a draw-distance slider. -- Tateru Nino http://dwellonit.taterunino.net/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101002/36945140/attachment.htm From gcanaday at gmail.com Fri Oct 1 14:39:31 2010 From: gcanaday at gmail.com (Glen Canaday) Date: Fri, 01 Oct 2010 17:39:31 -0400 Subject: [opensource-dev] Faster for people with crappy internet? (was Re: Overview of JPEG 2000 codec In-Reply-To: <4CA63A62.5090906@gmail.com> References: <4CA614FC.5080401@streamsense.net> <4CA63A62.5090906@gmail.com> Message-ID: <1285969171.1960.2.camel@glen-desktop> On Sat, 2010-10-02 at 05:45 +1000, Tateru Nino wrote: > > > On 2/10/2010 5:22 AM, Brian McGroarty wrote: > > On Fri, Oct 1, 2010 at 11:41 AM, Ponzu wrote: > > On Fri, Oct 1, 2010 at 1:06 PM, Thomas Grimshaw > > wrote: > > On 01/10/2010 18:04, Ponzu wrote: > > Nobody has crappier internet than I > > (satellite). > > > > > > Well, we're really talking about transfer caps, > > here, rather than available bandwidth. > > > > Available bandwidth can be appeased by the network > > slider. But transfer caps are the biggest problem, > > and pretty much everyone in Australia is affected, > > and a lot of people on the less decent ISP's in the > > UK. > > > > > > and me. 17GB per 30 day period, in a sliding window. > > > > Point is still that caps will be increased as time goes on > > (or decreased, as international economic system collapses, > > but taht is a differnt sim). > > > > > > Devs concerned about crazy-limited connections shouldn't worry about > > the small changes that may someday come with a different image > > CODEC. They can cut texture transfers in half -today- at the expense > > of texture blurriness. > > > > > > A test should be straightforward, if anyone feels strongly enough to > > take a whack at it. Add a "texture fidelity" slider that scales the > > measure the viewer uses to decide what discard level it wants. See > > where you still find it tolerable. > > > I read that three times, with different reactions. After a little > thought, though, yes. I'd _totally_ use that if it were an option. > Right on the main UI next to a draw-distance slider. > -- > Tateru Nino > http://dwellonit.taterunino.net/ Totally seconded. That's very nice - it's almost like using fog to hide a draw distance limit. As the human eye sees things blurrier as they get further away, it seems like a healthy method of bandwidth capping to me. That way they only fully load those textures that are in view and within the slider's distance. --GC From bryon at slearth.com Fri Oct 1 18:19:13 2010 From: bryon at slearth.com (Bryon Ruxton) Date: Fri, 01 Oct 2010 18:19:13 -0700 Subject: [opensource-dev] 2.0 Absolute Dealbreaker - script count feature request In-Reply-To: Message-ID: > * We change something, and the thing that used to work no longer works > * People scream that we broke content > So if we create a call that returns approximate results now, it *always* has > to return the same results. Q, in this case, I disagree. Changing the SCRIPT_MEMORY reports later will not technically break content, it would just requires to slightly alter the interpretation of it. Modifying the cap variables for event(s) to lower numbers, is the only things at stake here. If you put the information out on the wiki right away, as to what to expect of the function in the future. I would see no valid reason for anyone to whine about such a change later on if informed prior. The change can also be planned ahead in our code and work seamlessly with no issues along the way, if you are certain as to what the changes will be. (e.g. if the number is not longer a strict multiple of 16, then apply different rules...done!) As long as it is planned carefully and followed through to the end goal, that seems fine to me on the short to medium term. > This is one reason we are reluctant to add new measurements; people come to > depend on them even when they shouldn't. Understandable view on your side... but the facts that some people don't have the proper judgment or skills to rely or analyze statistics accurately, shouldn't be a reason to deprive those who can use it properly as well as ethically, with valid and useful reasons for doing so. On 10/1/10 10:07 AM, "Kent Quirk (Q Linden)" wrote: > I don't actually have an opinion about the right answer, but I will note that > if this is going to be used for things like banning people, then we can't ever > change it to be something accurate later. The pattern we see is: > > * We build something that has a numeric limit > * Someone builds something that pushes right to the limit > * We change something, and the thing that used to work no longer works > * People scream that we broke content From erikba at odysseus.anderson.name Fri Oct 1 19:05:41 2010 From: erikba at odysseus.anderson.name (Erik Anderson) Date: Fri, 1 Oct 2010 19:05:41 -0700 Subject: [opensource-dev] 2.0 Absolute Dealbreaker - script count feature request In-Reply-To: References: Message-ID: I hate to break in like this, but we're discussing how inaccurate it is for Mono scripts to contribute a different multiple than LSL scripts, but in the end aren't we just counting scripts? Would it be more accurate to report a script count and let the user do whatever multiple they want, and then later when there's a better number out there for memory usage release that as a new number? If any assumptions are made by the scriptor at that point they know where the accuracy lies... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101001/8dc6b650/attachment.htm From tinacloud at gmx.de Sat Oct 2 01:43:32 2010 From: tinacloud at gmx.de (Zi Ree) Date: Sat, 2 Oct 2010 10:43:32 +0200 Subject: [opensource-dev] 2.0 Absolute Dealbreaker - script count feature request In-Reply-To: References: Message-ID: <201010021043.32902.tinacloud@gmx.de> Am Samstag 02 Oktober 2010 03:19:13 schrieb Bryon Ruxton: > Q, in this case, I disagree. Changing the SCRIPT_MEMORY reports later will > not technically break content, it would just requires to slightly alter the > interpretation of it. Modifying the cap variables for event(s) to lower You never worked in customer support, did you? :P > Understandable view on your side... but the facts that some people don't > have the proper judgment or skills to rely or analyze statistics > accurately, shouldn't be a reason to deprive those who can use it properly > as well as ethically, with valid and useful reasons for doing so. Even people who know what they are doing can't do anything with the numbers reported. You don't know how much memory a Mono script uses, so it's of no use to you how many scripts there are inside an object. The avatar with 200 scripts on them might actually use less memory and CPU time than another avatar with 20 scripts on them. Unless we get *proper* metrics on cpu time and memory consumption, all this talk about script conut and memory is utterly useless and will only confuse people and lead to drama. Zi From lee.ponzu at gmail.com Sat Oct 2 07:07:51 2010 From: lee.ponzu at gmail.com (Ponzu) Date: Sat, 2 Oct 2010 10:07:51 -0400 Subject: [opensource-dev] 2.0 Absolute Dealbreaker - script count feature request In-Reply-To: <201010021043.32902.tinacloud@gmx.de> References: <201010021043.32902.tinacloud@gmx.de> Message-ID: On Sat, Oct 2, 2010 at 4:43 AM, Zi Ree wrote: > Am Samstag 02 Oktober 2010 03:19:13 schrieb Bryon Ruxton: > > Unless we get *proper* metrics on cpu time and memory consumption, all this > talk about script conut and memory is utterly useless and will only confuse > people and lead to drama. > > There is "right", and there is "soon". A function that returns the number of scripts is not *wrong*, and it sounds like it should be easy. The right functions will take longer. Adding better functions later does not break any content. Don't let the perfect drive out the good. lee -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101002/8d86d4d7/attachment.htm From Lance.Corrimal at eregion.de Sat Oct 2 07:49:48 2010 From: Lance.Corrimal at eregion.de (Lance Corrimal) Date: Sat, 2 Oct 2010 16:49:48 +0200 Subject: [opensource-dev] 2.0 Absolute Dealbreaker - script count feature request In-Reply-To: References: <201010021043.32902.tinacloud@gmx.de> Message-ID: <201010021649.48968.Lance.Corrimal@eregion.de> Am Samstag 02 Oktober 2010 schrieb Ponzu: > On Sat, Oct 2, 2010 at 4:43 AM, Zi Ree wrote: > > Am Samstag 02 Oktober 2010 03:19:13 schrieb Bryon Ruxton: > > > > Unless we get *proper* metrics on cpu time and memory > > consumption, all this talk about script conut and memory is > > utterly useless and will only confuse people and lead to drama. > > There is "right", and there is "soon". A function that returns the > number of scripts is not *wrong*, and it sounds like it should be > easy. The right functions will take longer. Adding better > functions later does not break any content. > > Don't let the perfect drive out the good. > > lee phoenix already does that, in its radar you can define a warning that tells you when the script count in the sim changes by more than a threshold that you define... so there already _is_ a way to count all scripts in a sim. bye, LC From miss_c_27 at yahoo.com Sat Oct 2 09:34:49 2010 From: miss_c_27 at yahoo.com (miss c) Date: Sat, 2 Oct 2010 09:34:49 -0700 (PDT) Subject: [opensource-dev] 2.0 Absolute Dealbreaker - script count feature request In-Reply-To: References: Message-ID: <671583.50665.qm@web82108.mail.mud.yahoo.com> THANK YOU, what he said. Why lie and make up some weird inaccurate number to leave people guessing, just give us a script counter, LOL. ________________________________ From: Erik Anderson To: Bryon Ruxton Cc: opensource-dev at lists.secondlife.com Sent: Fri, October 1, 2010 9:05:41 PM Subject: Re: [opensource-dev] 2.0 Absolute Dealbreaker - script count feature request I hate to break in like this, but we're discussing how inaccurate it is for Mono scripts to contribute a different multiple than LSL scripts, but in the end aren't we just counting scripts? Would it be more accurate to report a script count and let the user do whatever multiple they want, and then later when there's a better number out there for memory usage release that as a new number? If any assumptions are made by the scriptor at that point they know where the accuracy lies... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101002/d1ccd426/attachment.htm From cg at lindenlab.com Sat Oct 2 09:38:31 2010 From: cg at lindenlab.com (CG Linden) Date: Sat, 2 Oct 2010 09:38:31 -0700 Subject: [opensource-dev] Platform specific static quick download links to latest installers In-Reply-To: References: Message-ID: Shortened quick links: http://bit.ly/viewer-dev-latest-Linux http://bit.ly/viewer-dev-latest-Mac http://bit.ly/viewer-dev-latest-Windows All results: http://bit.ly/viewer-dev-latest On Thu, Sep 23, 2010 at 2:59 PM, CG Linden wrote: > The links are now active. > -- > cg > > > On Thu, Sep 23, 2010 at 2:09 PM, CG Linden wrote: > >> Linux: >> >> http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repo/snowstorm_viewer-development/arch/Linux/quicklink.html >> >> Mac: >> >> http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repo/snowstorm_viewer-development/arch/Darwin/quicklink.html >> >> Windows: >> >> http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repo/snowstorm_viewer-development/arch/CYGWIN/quicklink.html >> >> Those links will start working once TeamCity cranked out a new build. >> -- >> cg >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101002/21ea7ebe/attachment.htm From robertltux at gmail.com Sat Oct 2 09:42:34 2010 From: robertltux at gmail.com (Robert Martin) Date: Sat, 2 Oct 2010 12:42:34 -0400 Subject: [opensource-dev] 2.0 Absolute Dealbreaker - script count feature request In-Reply-To: <671583.50665.qm@web82108.mail.mud.yahoo.com> References: <671583.50665.qm@web82108.mail.mud.yahoo.com> Message-ID: On Sat, Oct 2, 2010 at 12:34 PM, miss c wrote: > THANK YOU, what he said.? Why lie and make up some weird inaccurate number > to leave people guessing, just give us a script counter, LOL. > what i would suggest is 1 have a way to see TOTAL scripts LSL scripts and Mono scripts 2 if any ARC type number is used then guess LOW 3 figure out ways that can be found to make scripts obsolete (skirt sitter and resize scripts are the Low Hanging Fruit on this one) -- Robert L Martin btw could somebody please set the Reply To: flag correctly??? From miss_c_27 at yahoo.com Sat Oct 2 12:57:43 2010 From: miss_c_27 at yahoo.com (miss c) Date: Sat, 2 Oct 2010 12:57:43 -0700 (PDT) Subject: [opensource-dev] TCMalloc Memory Profiling? Message-ID: <142371.88164.qm@web82103.mail.mud.yahoo.com> I saw the memoryprofiling debug option to enable the TCMalloc's memory profiling. Reading up on it here http://goog-perftools.sourceforge.net/doc/tcmalloc.html Will this enhance the performance of my viewer or is this legacy? If it will enhance it, why is this option not on by default? Can someone enlighten me please? Thank you Miss -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101002/8e04a271/attachment.htm From exile at weylan-yutani.com Sat Oct 2 13:38:14 2010 From: exile at weylan-yutani.com (Robert "Exile In Paradise" Murphey) Date: Sat, 02 Oct 2010 15:38:14 -0500 Subject: [opensource-dev] 2.0 Absolute Dealbreaker - script count feature request In-Reply-To: <201010021043.32902.tinacloud@gmx.de> References: <201010021043.32902.tinacloud@gmx.de> Message-ID: <1286051894.8450.20.camel@nostromo> On Sat, 2010-10-02 at 10:43 +-0200, Zi Ree wrote: +AD4 Unless we get +ACo-proper+ACo metrics on cpu time and memory consumption, all this +AD4 talk about script conut and memory is utterly useless and will only confuse +AD4 people and lead to drama. One approach is to use a cost-per-LSLcall function to generate a +ACI-CPU Cost+ACI, in a notionally similar way to how avatar rendering cost is calculated for geometry. The Cost table could even be 1+-delay where delay is the number of seconds of delay already imposed on the call. Cost Per Script Scan the tokens present in the compiled script against a weighted list of cost-per-LSLfunction for +ACI-estimated load+ACI. Track actual min, max, and average CPU and memory resources consumed over time. Cost Per Object Add the resource costs for all the scripts present in all prims of an object for a total cost for that object. Track and update the min, max and average for the object. Cost Per Avatar Add all the costs of scripted objects, attachments and huds to generate a total cost per avatar on the simulator. Total all resources used, and update min, max and average by avatar. Cost Per Region I would also suggest a total CPU and Memory cost by avatar in a region in addition to the existing Top Scripts and Top Colliders reports. In the Estate/Region Debug menu, would benefit from a +ACI-Total Cost by Object Owner+ACI report - Show the total costs and memory consumed by the avatar in the region along WITH all of their objects separately and together. This way, a lightweight avatar with 1000 objects can be truly measured by +ACI-total load+ACI against a heavyweight avatar (tons of attachments) with few objects. Give people the tools to see weighted CPU costs, Memory costs and rudimentary profiling of those metrics over time rather than just the point in time snapshots. -- Robert +ACI-Exile In Paradise+ACI Murphey Remember, there's a big difference between kneeling down and bending over. - Frank Zappa From sllists at boroon.dasgupta.ch Sat Oct 2 15:21:13 2010 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Sun, 03 Oct 2010 00:21:13 +0200 Subject: [opensource-dev] TCMalloc Memory Profiling? In-Reply-To: <142371.88164.qm@web82103.mail.mud.yahoo.com> References: <142371.88164.qm@web82103.mail.mud.yahoo.com> Message-ID: <4CA7B059.6000707@boroon.dasgupta.ch> On 10/02/2010 09:57 PM, miss c wrote: > I saw the memoryprofiling debug option to enable the TCMalloc's memory > profiling. Reading up on it here > http://goog-perftools.sourceforge.net/doc/tcmalloc.html I guess you're talking about the "MemProfiling" debug setting? (When talking about less well known debug settings, please always mention their exact name to avoid confusion. Sometimes there are several similar ones.) > Will this enhance the performance of my viewer or is this legacy? While I don't know what that option does exactly, it sounds like it doesn't choose which library to use for memory allocation, but rather enables profiling *if* the used library is TCMalloc. I don't how TCMalloc usage would be enabled, but I guess that'd be a compile time option, not a run time one. While the usage of TCMalloc might make things faster compared to other malloc implementations, enabling /profiling/ (presumably: measuring how many allocations happen where and when in the program) is more likely to slows things down. > If it will enhance it, why is this option not on by default? Can > someone enlighten me please? According to http://google-perftools.googlecode.com/svn/trunk/doc/heapprofile.html , their heap profiling (which might well be what the debug option toggles) "can be useful for * Figuring out what is in the program heap at any given time * Locating memory leaks * Finding places that do a lot of allocation" This means it's mostly interesting for developers who are either debugging something and thus want to see what happens in the memory they've allocated or who are hunting memory leaks or other reasons of extensive memory usage (or rapid allocation/deallocation cycles, etc.). I don't think enabling it would directly benefit the typical end user in any way. Cheers, Boroondas PS: There's lots off guesswork involved in the above, so anyone who knows more/better, please correct me. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101003/6529d74b/attachment.htm From secret.argent at gmail.com Sat Oct 2 16:40:58 2010 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sat, 2 Oct 2010 18:40:58 -0500 Subject: [opensource-dev] 2.0 Absolute Dealbreaker - script count feature request In-Reply-To: References: <742565.2526.qm@web82101.mail.mud.yahoo.com> Message-ID: On 2010-09-29, at 18:06, Kelly Linden wrote: > * In the end the number of scripts shouldn't be important. I have lofty desires to remove the arbitrary limit on script size so that we can stop the silly games of splitting scripts apart because you need 10k more memory than the default. On the other side being able to declare that your script really only needs 4k would be hugely beneficial. At that point reporting the reserved memory is more meaningful than the number of scripts. Could this be applied to LSL scripts as well, since they could be made potentially MUCH smaller? A kilobyte might be enough for a poseball, for example, and even less for a titler or particle script. From kelly at lindenlab.com Sat Oct 2 18:47:01 2010 From: kelly at lindenlab.com (Kelly Linden) Date: Sat, 2 Oct 2010 18:47:01 -0700 Subject: [opensource-dev] 2.0 Absolute Dealbreaker - script count feature request In-Reply-To: References: <742565.2526.qm@web82101.mail.mud.yahoo.com> Message-ID: On Sat, Oct 2, 2010 at 4:40 PM, Argent Stonecutter wrote: > On 2010-09-29, at 18:06, Kelly Linden wrote: > > * In the end the number of scripts shouldn't be important. I have lofty > desires to remove the arbitrary limit on script size so that we can stop the > silly games of splitting scripts apart because you need 10k more memory than > the default. On the other side being able to declare that your script really > only needs 4k would be hugely beneficial. At that point reporting the > reserved memory is more meaningful than the number of scripts. > > Could this be applied to LSL scripts as well, since they could be made > potentially MUCH smaller? A kilobyte might be enough for a poseball, for > example, and even less for a titler or particle script. > > Unfortunately no. LSL scripts take up 16k of memory no matter how much they actually use. - Kelly -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101002/2e23fa4e/attachment.htm From secret.argent at gmail.com Sun Oct 3 03:05:29 2010 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sun, 3 Oct 2010 05:05:29 -0500 Subject: [opensource-dev] 2.0 Absolute Dealbreaker - script count feature request In-Reply-To: References: <742565.2526.qm@web82101.mail.mud.yahoo.com> Message-ID: On 2010-10-02, at 20:47, Kelly Linden wrote: > On Sat, Oct 2, 2010 at 4:40 PM, Argent Stonecutter wrote: >> Could this be applied to LSL scripts as well, since they could be made potentially MUCH smaller? A kilobyte might be enough for a poseball, for example, and even less for a titler or particle script. > > Unfortunately no. LSL scripts take up 16k of memory no matter how much they actually use. I know they do. That's why I was asking if that could be changed. Have a script size box in the script editor, when you compile you can select 1k, 2k, 4k... up to 16k. That could potentially save a lot of memory... megabytes for locations with lots of scripted furniture. From malachi at tamzap.com Sun Oct 3 07:27:52 2010 From: malachi at tamzap.com (malachi) Date: Sun, 03 Oct 2010 10:27:52 -0400 Subject: [opensource-dev] CAN WE PLEASE STOP VIEWER DEVELOPMENT FOR 5 MINUTES Message-ID: could we please take 5 minutes away from the client that we all obviously have our second thoughts about to begin with. and focus on grid infrastructure.???? i honestly dont care if i am forced to use the dreaded 2.x client. if the grid actually responded to something you did. things like just loading my clothing. or if i save a script it should still exist after i close the edit box. but the fact that any script added to a prim inworld gets eaten and destroyed server side is a huge issue. could LL drop the client work for 5 minutes and see what is going on on the server? or is that too much to ask? because as it seems over the last few weeks its been new client code new client code new client code while the server just gradually falls off a cliff. what good is a client that runs like fiber when the server it connects to only speaks in dialup? -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ From carlo at alinoe.com Sun Oct 3 07:33:51 2010 From: carlo at alinoe.com (Carlo Wood) Date: Sun, 3 Oct 2010 16:33:51 +0200 Subject: [opensource-dev] CAN WE PLEASE STOP VIEWER DEVELOPMENT FOR 5 MINUTES In-Reply-To: References: Message-ID: <20101003143351.GA26388@alinoe.com> Welcome to open source viewer, closed source server. On Sun, Oct 03, 2010 at 10:27:52AM -0400, malachi wrote: > could we please take 5 minutes away from the client that we all obviously > have our second thoughts about to begin with. and focus on grid > infrastructure.???? > > i honestly dont care if i am forced to use the dreaded 2.x client. if the > grid actually responded to something you did. things like just loading my > clothing. or if i save a script it should still exist after i close the > edit box. but the fact that any script added to a prim inworld gets eaten > and destroyed server side is a huge issue. could LL drop the client work > for 5 minutes and see what is going on on the server? or is that too much > to ask? because as it seems over the last few weeks its been new client > code new client code new client code while the server just gradually falls > off a cliff. what good is a client that runs like fiber when the server it > connects to only speaks in dialup? > > > -- > Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting privileges -- Carlo Wood From oz at lindenlab.com Sun Oct 3 07:38:53 2010 From: oz at lindenlab.com (Oz Linden (Scott Lawrence)) Date: Sun, 03 Oct 2010 10:38:53 -0400 Subject: [opensource-dev] CAN WE PLEASE STOP VIEWER DEVELOPMENT FOR 5 MINUTES In-Reply-To: References: Message-ID: <4CA8957D.3040402@lindenlab.com> On 2010-10-03 10:27, malachi wrote: > could we please take 5 minutes away from the client that we all obviously > have our second thoughts about to begin with. and focus on grid > infrastructure.???? > > i honestly dont care if i am forced to use the dreaded 2.x client. if the > grid actually responded to something you did. things like just loading my > clothing. or if i save a script it should still exist after i close the > edit box. but the fact that any script added to a prim inworld gets eaten > and destroyed server side is a huge issue. could LL drop the client work > for 5 minutes and see what is going on on the server? or is that too much > to ask? because as it seems over the last few weeks its been new client > code new client code new client code while the server just gradually falls > off a cliff. what good is a client that runs like fiber when the server it > connects to only speaks in dialup? The subject of this list is the open source, which does not include the server side. Discussions of interactions with the server are of course in scope. There is little conflict in the people involved with server side and viewer side development, so stopping viewer development would do little to change server problem resolution even if that is where the problem is. It sounds as though you are experiencing some serious problems, but the descriptions above are not nearly complete enough for anyone to determine what the real problems are, much less determine who could best solve them. From Kindragon at comcast.net Sun Oct 3 09:33:15 2010 From: Kindragon at comcast.net (Obsidian Kindragon) Date: Sun, 03 Oct 2010 10:33:15 -0600 Subject: [opensource-dev] CAN WE PLEASE STOP VIEWER DEVELOPMENT FOR 5 MINUTES In-Reply-To: <4CA8957D.3040402@lindenlab.com> References: <4CA8957D.3040402@lindenlab.com> Message-ID: <4CA8B04B.4090801@comcast.net> On 10/3/2010 8:38 AM, Oz Linden (Scott Lawrence) wrote: > On 2010-10-03 10:27, malachi wrote: >> could we please take 5 minutes away from the client that we all obviously >> have our second thoughts about to begin with. and focus on grid >> infrastructure.???? >> >> i honestly dont care if i am forced to use the dreaded 2.x client. if the >> grid actually responded to something you did. things like just loading my >> clothing. or if i save a script it should still exist after i close the >> edit box. but the fact that any script added to a prim inworld gets eaten >> and destroyed server side is a huge issue. could LL drop the client work >> for 5 minutes and see what is going on on the server? or is that too much >> to ask? because as it seems over the last few weeks its been new client >> code new client code new client code while the server just gradually falls >> off a cliff. what good is a client that runs like fiber when the server it >> connects to only speaks in dialup? > The subject of this list is the open source, which does not include the > server side. Discussions of interactions with the server are of course > in scope. > > There is little conflict in the people involved with server side and > viewer side development, so stopping viewer development would do little > to change server problem resolution even if that is where the problem is. > > It sounds as though you are experiencing some serious problems, but the > descriptions above are not nearly complete enough for anyone to > determine what the real problems are, much less determine who could best > solve them. > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting privileges > I agree with OZ here. The issue could be client side or server side, but as Oz stated we don't have enough information. I think Malachi needs to describe the steps he's using to reproduce the issue (even if it's not consistently occurring) for each of the problems he's seeing so people can reproduce and add it to an existing JIRA or open a new one if one doesn't already exist for the specific problem. - Obsidian Stormwind From lee.ponzu at gmail.com Sun Oct 3 10:37:49 2010 From: lee.ponzu at gmail.com (Ponzu) Date: Sun, 3 Oct 2010 13:37:49 -0400 Subject: [opensource-dev] Question about LOD debug setting Message-ID: I picked up a notecard that says to increase RenderVolumeLODFactor to 4. Is this reasonable, do you think? And if so, why not increase the default a bit (currently seems to be 1.125 lee ==notecard says=== well, its until they fix this lod problem, its just a workaround. Debugging your LOD settings is something that can and will make all your sculpts hold the intended detail better. Follow these easy steps: 1. Show the "Advanced" menu with Ctrl-Alt-D, or Opt-Ctrl-D on a Mac. 2. Select "debug settings" near the bottom. 3. In the blank space, copy and paste the word: RenderVolumeLODFactor 4. In the box below, set the number. The recommended setting is as high as 4 to have all your sculpts looking as the creator intended. Unlike increasing your draw distance, this will NOT create lag for yourself or those around you! And it will improve the look of all sculpts. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101003/0d81e4cc/attachment.htm From leliel.mirihi at gmail.com Sun Oct 3 11:54:36 2010 From: leliel.mirihi at gmail.com (leliel) Date: Sun, 3 Oct 2010 11:54:36 -0700 Subject: [opensource-dev] Question about LOD debug setting In-Reply-To: References: Message-ID: On Sun, Oct 3, 2010 at 10:37 AM, Ponzu wrote: > I picked up a notecard that says to increase?RenderVolumeLODFactor to 4. ?Is > this reasonable, do you think? ?And if so, why not increase the default a > bit (currently seems to be 1.125 It is reasonable, the default setting is a bit low. It varies with your graphics settings tho, 0 for low, 1.125 for mid & high, and 2 for ultra IIRC. I find 3 a good compromise between quality and performance. > Unlike increasing your draw distance, this will NOT create lag for yourself This however, is blatantly false. If rendering everything at full detail all the time didn't cause a drop in frame rate than why would we even bother with LOD? From lee.ponzu at gmail.com Sun Oct 3 12:02:24 2010 From: lee.ponzu at gmail.com (Ponzu) Date: Sun, 3 Oct 2010 15:02:24 -0400 Subject: [opensource-dev] Question about LOD debug setting In-Reply-To: References: Message-ID: On Sun, Oct 3, 2010 at 2:54 PM, leliel wrote: > > > Unlike increasing your draw distance, this will NOT create lag for > yourself > > This however, is blatantly false. If rendering everything at full > detail all the time didn't cause a drop in frame rate than why would > we even bother with LOD? > Understood. She was only talking about sculpties, however. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101003/2d1d8b11/attachment.htm From javajoint at gmail.com Sun Oct 3 11:57:14 2010 From: javajoint at gmail.com (Daniel Smith) Date: Sun, 3 Oct 2010 11:57:14 -0700 Subject: [opensource-dev] CAN WE PLEASE STOP VIEWER DEVELOPMENT FOR 5 MINUTES In-Reply-To: <4CA8B04B.4090801@comcast.net> References: <4CA8957D.3040402@lindenlab.com> <4CA8B04B.4090801@comcast.net> Message-ID: I agree with Oz on this as well. There are different folks working on the client and server sides. Throwing the client folks over to fix server side problems runs the risk of actually slowing things down. The huge, looming issue on the client side is simply this: evolution. Where could the 2.x viewer be, 2 years from now? Where could a 3.x viewer, with a plugin architecture, be in 2 years? Where could a Unity-based viewer be in 2 years? Without a good plugin architecture, this viewer is going to keep growing. It will become even more of a monolithic piece of code that wont run well on lower end machines. With a good plugin architecture, there is the opportunity for a solid core + customization. Chrome and Firefox come to mind as examples on the web side. Having said all that though, think about this: It is a Sunday. Go look at what Unity 3.x (you can download it for free) is capable of. Can any 2.x codebase get to that level of quality in the next 2 years? I dont think so. Consider what it would take to have a Unity foundation, layered with the SL-specific experience on top. Then think about it the other way (trying to get the existing standard of 2.x to that level of quality, and on all of those platforms). My thought would be: get mesh out there on 2.x viewer, and then put on the brakes and consider direction. Daniel - daniel.org/blog -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101003/001c71b1/attachment.htm From tinacloud at gmx.de Sun Oct 3 12:02:53 2010 From: tinacloud at gmx.de (Zi Ree) Date: Sun, 3 Oct 2010 21:02:53 +0200 Subject: [opensource-dev] 2.0 Absolute Dealbreaker - script count feature request In-Reply-To: <201010021649.48968.Lance.Corrimal@eregion.de> References: <201010021649.48968.Lance.Corrimal@eregion.de> Message-ID: <201010032102.53864.tinacloud@gmx.de> Am Samstag 02 Oktober 2010 16:49:48 schrieb Lance Corrimal: > phoenix already does that, in its radar you can define a warning that > tells you when the script count in the sim changes by more than a > threshold that you define... so there already _is_ a way to count all > scripts in a sim. Counting scripts on the sim is part of the sim stats (ctrl shift 1), we're talking about per object or per avatar. Zi From Lance.Corrimal at eregion.de Sun Oct 3 12:15:46 2010 From: Lance.Corrimal at eregion.de (Lance Corrimal) Date: Sun, 3 Oct 2010 21:15:46 +0200 Subject: [opensource-dev] 2.0 Absolute Dealbreaker - script count feature request In-Reply-To: <201010032102.53864.tinacloud@gmx.de> References: <201010021649.48968.Lance.Corrimal@eregion.de> <201010032102.53864.tinacloud@gmx.de> Message-ID: <201010032115.46718.Lance.Corrimal@eregion.de> Am Sonntag 03 Oktober 2010 schrieb Zi Ree: > Am Samstag 02 Oktober 2010 16:49:48 schrieb Lance Corrimal: > > phoenix already does that, in its radar you can define a warning > > that tells you when the script count in the sim changes by more > > than a threshold that you define... so there already _is_ a way > > to count all scripts in a sim. > > Counting scripts on the sim is part of the sim stats (ctrl shift > 1), we're talking about per object or per avatar. Ah... didn't see that part. From miss_c_27 at yahoo.com Sun Oct 3 12:29:28 2010 From: miss_c_27 at yahoo.com (miss c) Date: Sun, 3 Oct 2010 12:29:28 -0700 (PDT) Subject: [opensource-dev] another script fighting question Message-ID: <144753.66835.qm@web82104.mail.mud.yahoo.com> No one in concierge seems to know this, so I thought I would ask the viewer specialists here. When you first call for top scripts in region tools what is the order it is returning initially. I know it's not random because some avatars come up in the same spots everytime. I know its not time, because some avies and objects are higher than others. Could it possibly be calls on the server?? or is it something as simple as UUID order. I NEED A CLASS 7! Combating the lag every hour on the hour. TY Miss -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101003/36d039f4/attachment.htm From missannotoole at yahoo.com Sun Oct 3 12:48:55 2010 From: missannotoole at yahoo.com (Ann Otoole) Date: Sun, 3 Oct 2010 12:48:55 -0700 (PDT) Subject: [opensource-dev] Question about LOD debug setting In-Reply-To: References: Message-ID: <145511.34932.qm@web120511.mail.ne1.yahoo.com> It simply depends on your computer and video card. I can run that setting at 4 with no noticeable difference. LL's quest to remain mired in circa 1999 graphics is admirable and noble and all but is costing SL/LL a vast amount of money. When mesh is rolled out and the inevitable "use all available resources" happens then I dare say SL will look a lot better but will probably lose the lower end anyway as they get tired and drop out because they can't have a decent experience and they choose alcohol, tobacco, reefer, and pizza over a decent gaming rig. As is said at Microsoft: Upgrade or die" This too shall happen with SL if SL is to survive a long time. If LL doesn't do it then someone else will. As for defaults yes the ultra default should be 4. LL recently changed the gpu_table.txt settings and any card that defults to ultra can more than handle RenderVolumeLODFactor at 4 with no noticeable impact. My GT240 on Kirstens with full shadows tweaked for realism gets a great frame rate with RenderVolumeLODFactor at 4. With shadows off and RenderVolumeLODFactor at 4 I get better than 29.97 FPS which is cinematic quality. However I get tired of ARC pundits spreading lies. Especially the ones saying mesh is low ARC since currently a theoretical mesh with 64 ktris/fr (64,000 polys per frame) will register less than 20 ARC depending on the settings and scripts involved. It is, after all, one damned prim to ARC. Oh, and BTW, the "ARC" will have to be changed to show mesh render cost and leave out the script cost. Make a script cost measure and a real ktris/fr worst case cost estimate measure for the avatar. And then we need parcel/region render cost metrics available as well. And an estimated bytes downloaded measure for people on capped bandwidth plans. The entire concept of impact metrics needs to be revisited and done right IMHO. ________________________________ From: leliel To: opensource-dev Sent: Sun, October 3, 2010 2:54:36 PM Subject: Re: [opensource-dev] Question about LOD debug setting On Sun, Oct 3, 2010 at 10:37 AM, Ponzu wrote: > I picked up a notecard that says to increase RenderVolumeLODFactor to 4. Is > this reasonable, do you think? And if so, why not increase the default a > bit (currently seems to be 1.125 It is reasonable, the default setting is a bit low. It varies with your graphics settings tho, 0 for low, 1.125 for mid & high, and 2 for ultra IIRC. I find 3 a good compromise between quality and performance. > Unlike increasing your draw distance, this will NOT create lag for yourself This however, is blatantly false. If rendering everything at full detail all the time didn't cause a drop in frame rate than why would we even bother with LOD? _______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101003/c8c6fa4d/attachment.htm From miss_c_27 at yahoo.com Sun Oct 3 12:59:45 2010 From: miss_c_27 at yahoo.com (miss c) Date: Sun, 3 Oct 2010 12:59:45 -0700 (PDT) Subject: [opensource-dev] 2.0 Absolute Dealbreaker - script count feature request !!!!!!! In-Reply-To: References: <742565.2526.qm@web82101.mail.mud.yahoo.com> Message-ID: <495891.93754.qm@web82101.mail.mud.yahoo.com> This is why we need it [12:52] Counted scripts from 19 attachments on Sxxxxxt Cxxxxxxx: 1102 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101003/8406c645/attachment.htm From sllists at boroon.dasgupta.ch Sun Oct 3 13:26:23 2010 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Sun, 03 Oct 2010 22:26:23 +0200 Subject: [opensource-dev] Unity 3D as possible base for future (maybe even official) SL Viewers (was: CAN WE PLEASE STOP VIEWER DEVELOPMENT FOR 5 MINUTES) In-Reply-To: References: <4CA8957D.3040402@lindenlab.com> <4CA8B04B.4090801@comcast.net> Message-ID: <4CA8E6EF.9060703@boroon.dasgupta.ch> On 10/03/2010 08:57 PM, Daniel Smith wrote: > Consider what it would take to have a Unity foundation, layered with > the SL-specific experience on top. What it would take? At least Linux support for Unity. While the percentage of Linux users among SL users might still be small enough to be regarded negligible by some people, the percentage of Linux users amongst the open source developer community around Linden Lab's current official viewer is certainly significant. Of course, one might assume a Unity based Viewer project would attract enough new developers that one wouldn't have to rely on as many from the current developer community as possible, but somehow I don't think that'd be the case. Then, I'd image Linden Lab would probably want to use Unity Pro for development while most community developers would stick to the free (as in beer) Unity license. Can developers with the free license even collaborate in projects otherwise developed with the Pro one? Or would this turn this new viewer into a pure in-house project, even if the new viewer was open source, too? (Well, as open source as it can be with the engine being proprietary.) Boroondas From javajoint at gmail.com Sun Oct 3 13:44:54 2010 From: javajoint at gmail.com (Daniel Smith) Date: Sun, 3 Oct 2010 13:44:54 -0700 Subject: [opensource-dev] Unity 3D as possible base for future (maybe even official) SL Viewers (was: CAN WE PLEASE STOP VIEWER DEVELOPMENT FOR 5 MINUTES) In-Reply-To: <4CA8E6EF.9060703@boroon.dasgupta.ch> References: <4CA8957D.3040402@lindenlab.com> <4CA8B04B.4090801@comcast.net> <4CA8E6EF.9060703@boroon.dasgupta.ch> Message-ID: On Sun, Oct 3, 2010 at 1:26 PM, Boroondas Gupte wrote: > On 10/03/2010 08:57 PM, Daniel Smith wrote: > > Consider what it would take to have a Unity foundation, layered with > > the SL-specific experience on top. > What it would take? At least Linux support for Unity. > Yep, that came up as a point on my blog, and I answered: > Now, let?s look at the deployment platforms in Unity 3.0, > which just came out on Monday ? all of these will be available soon: > > Mac, Windows, Web, iPhone, Android, Wii, PS3, and Xbox 360 > > I think that?s amazing. Don?t you? Yes, it sucks a little that Linux isn?t > in there. ? But? if there is that potential to get a better experience for > 95% of the current users, and to open up a bunch of new platforms to them > and new users, then my gut says that is the right way to go. > Also.. I would think that the current Linux viewer could maintain compatibility. -- Daniel Smith - Sonoma County, California http://daniel.org/resume -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101003/fd05dbb9/attachment.htm From lee.ponzu at gmail.com Sun Oct 3 13:47:55 2010 From: lee.ponzu at gmail.com (Ponzu) Date: Sun, 3 Oct 2010 16:47:55 -0400 Subject: [opensource-dev] 2.0 Absolute Dealbreaker - script count feature request !!!!!!! In-Reply-To: <495891.93754.qm@web82101.mail.mud.yahoo.com> References: <742565.2526.qm@web82101.mail.mud.yahoo.com> <495891.93754.qm@web82101.mail.mud.yahoo.com> Message-ID: On Sun, Oct 3, 2010 at 3:59 PM, miss c wrote: > This is why we need it > > [12:52] Counted scripts from 19 attachments on Sxxxxxt Cxxxxxxx: 1102 > > > I suggest a different approach. Enable health/damage in your sim, and then *kill* them. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101003/15ec6faf/attachment.htm From Celierra at gmail.com Sun Oct 3 14:00:00 2010 From: Celierra at gmail.com (Celierra Darling) Date: Sun, 3 Oct 2010 17:00:00 -0400 Subject: [opensource-dev] Unity 3D as possible base for future (maybe even official) SL Viewers (was: CAN WE PLEASE STOP VIEWER DEVELOPMENT FOR 5 MINUTES) In-Reply-To: References: <4CA8957D.3040402@lindenlab.com> <4CA8B04B.4090801@comcast.net> <4CA8E6EF.9060703@boroon.dasgupta.ch> Message-ID: More than whether 2.x can technically get Unity features in two years, a question would be how to teach or incentivize creators to use those features without creating a laggy Tragedy of the Commons situation on the machines the viewers are running on. If you consider how much work and discussion is needed to develop metrics and limits (for example, in that script metrics thread), two years (or more!) might be taken up in just planning and testing those rules. The social considerations need to be thought about just as carefully as (if not more than) technical ones. (Also, adding additional platforms won't be free either - they each need extra work for their different quirks, user interfaces, and strengths and weaknesses. Trying to use a Windows PC viewer on the Wii or Android would be a train wreck. It's not like C# scripting was suddenly free after getting mono.) Celi On Sun, Oct 3, 2010 at 2:57 PM, Daniel Smith wrote: > > Where could a Unity-based viewer be in 2 years? > ... > Consider what it would take to have a Unity foundation, layered with the > SL-specific experience on top. Then think about it the other way (trying to > get the existing standard of 2.x to that level of quality, and on all of > those platforms). -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101003/cc7601bb/attachment.htm From gcanaday at gmail.com Sun Oct 3 14:56:05 2010 From: gcanaday at gmail.com (Glen Canaday) Date: Sun, 03 Oct 2010 17:56:05 -0400 Subject: [opensource-dev] Unity 3D as possible base for future (maybe even official) SL Viewers In-Reply-To: References: <4CA8957D.3040402@lindenlab.com> <4CA8B04B.4090801@comcast.net> <4CA8E6EF.9060703@boroon.dasgupta.ch> Message-ID: <1286142965.3438.12.camel@glen-desktop> No Linux support is a total deal-breaker for me. I really don't care how many platforms are supported, and that includes gaming consoles, if mine isn't. Gaming consoles are irrelevant, as SL is not a game and would not sell at Best Buy even if it were, making that support a completely moot point. I don't pay for the "privilege" of using an operating system on my hardware. Just because someone else does does not mean I (and the rest of the Linux users in SL, including a pretty good percentage of Lindens) should be shut out. If a commercial piece of software does not support the entire user base and is not GPL or LGPL, then it should be off the table completely. If you really want to do something like this, look to Ogre instead. --GC On Sun, 2010-10-03 at 13:44 -0700, Daniel Smith wrote: > > > On Sun, Oct 3, 2010 at 1:26 PM, Boroondas Gupte > wrote: > On 10/03/2010 08:57 PM, Daniel Smith wrote: > > Consider what it would take to have a Unity foundation, > layered with > > the SL-specific experience on top. > What it would take? At least Linux support for Unity. > > Yep, that came up as a point on my blog, and I answered: > > Now, let?s look at the deployment platforms in Unity 3.0, > which just came out on Monday ? all of these will be available > soon: > > Mac, Windows, Web, iPhone, Android, Wii, PS3, and Xbox 360 > > I think that?s amazing. Don?t you? Yes, it sucks a little that > Linux isn?t in there. ? But? if there is that potential to get > a better experience for 95% of the current users, and to open > up a bunch of new platforms to them and new users, then my gut > says that is the right way to go. > > Also.. I would think that the current Linux viewer could maintain > compatibility. > > -- > Daniel Smith - Sonoma County, California > http://daniel.org/resume > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting privileges From javajoint at gmail.com Sun Oct 3 15:09:01 2010 From: javajoint at gmail.com (Daniel Smith) Date: Sun, 3 Oct 2010 15:09:01 -0700 Subject: [opensource-dev] Unity 3D as possible base for future (maybe even official) SL Viewers In-Reply-To: <1286142965.3438.12.camel@glen-desktop> References: <4CA8957D.3040402@lindenlab.com> <4CA8B04B.4090801@comcast.net> <4CA8E6EF.9060703@boroon.dasgupta.ch> <1286142965.3438.12.camel@glen-desktop> Message-ID: On Sun, Oct 3, 2010 at 2:56 PM, Glen Canaday wrote: > No Linux support is a total deal-breaker for me. > > I never said anything about the Linux viewer going away. I note that we have Pocket Metaverse now, and have had AjaxLife in the past. If it helps at all, I started with BSD Unix in 1981, Linux in 1994 ;) As is the case with web browsers, a VR client to the same server could take many forms. Ultimately, it's about what the community wants, and if a critical mass of developers decides to give them that. It doesn't have to be an official Linden effort at all. All I am saying is, in 2 years time, I cant see the current codebases even getting to the point where Unity 3.0 is today, in terms of graphics, physics, animation, terrain, and sound. But, I could see a pretty decent SL app done in Unity within that amount of time. And, of course, I am just an interested observer. I dont speak for LL, Vivaty, AOL, Autodesk, or anywhere else I have worked :) Daniel -- Daniel Smith - Sonoma County, California http://daniel.org/resume -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101003/27c22e6d/attachment.htm From gcanaday at gmail.com Sun Oct 3 15:15:47 2010 From: gcanaday at gmail.com (Glen Canaday) Date: Sun, 03 Oct 2010 18:15:47 -0400 Subject: [opensource-dev] Unity 3D as possible base for future (maybe even official) SL Viewers In-Reply-To: References: <4CA8957D.3040402@lindenlab.com> <4CA8B04B.4090801@comcast.net> <4CA8E6EF.9060703@boroon.dasgupta.ch> <1286142965.3438.12.camel@glen-desktop> Message-ID: <1286144147.3438.18.camel@glen-desktop> On Sun, 2010-10-03 at 15:09 -0700, Daniel Smith wrote: > > > On Sun, Oct 3, 2010 at 2:56 PM, Glen Canaday > wrote: > No Linux support is a total deal-breaker for me. > > I never said anything about the Linux viewer going away. > I note that we have Pocket Metaverse now, and have had AjaxLife in the > past. > If it helps at all, I started with BSD Unix in 1981, Linux in 1994 ;) > > As is the case with web browsers, a VR client to the same server could > take many forms. > > Ultimately, it's about what the community wants, and if a critical > mass of developers decides to give them that. It doesn't have to be > an official Linden effort at all. > > All I am saying is, in 2 years time, I cant see the current codebases > even getting to the point where Unity 3.0 is today, in terms of > graphics, physics, animation, terrain, and sound. > But, I could see a pretty decent SL app done in Unity within that > amount of time. > > And, of course, I am just an interested observer. I dont speak for > LL, Vivaty, AOL, Autodesk, or anywhere else I have worked :) > > Daniel It's hard to see exactly where the rendering engine will go, really, in 2 years. For a plugin-based client, as some (including myself) are rather nudging towards, the renderer is just a part of the whole and could in theory be hot-swapped if desired to A/B different engines. Even if those renderers swapped between opengl and directx, it could still fly. But to suggest that the main client perhaps go to something that does not work across the board doesn't really include the whole of the population - something which LL would be keen to retain. That's why I suggested Ogre instead. I personally think it would be a better fit and more productive to look at. Others may have different opinions. --GC > -- > Daniel Smith - Sonoma County, California > http://daniel.org/resume > From Reed at ChangingWorldsBuildingDreams.com Sun Oct 3 15:39:39 2010 From: Reed at ChangingWorldsBuildingDreams.com (Reed Steamroller) Date: Sun, 3 Oct 2010 18:39:39 -0400 Subject: [opensource-dev] Unity 3D as possible base for future (maybe even official) SL Viewers In-Reply-To: <1286144147.3438.18.camel@glen-desktop> References: <4CA8957D.3040402@lindenlab.com> <4CA8B04B.4090801@comcast.net> <4CA8E6EF.9060703@boroon.dasgupta.ch> <1286142965.3438.12.camel@glen-desktop> <1286144147.3438.18.camel@glen-desktop> Message-ID: Run Unity in a VM. Works for me. On Sun, Oct 3, 2010 at 6:15 PM, Glen Canaday wrote: > On Sun, 2010-10-03 at 15:09 -0700, Daniel Smith wrote: > > > > > > On Sun, Oct 3, 2010 at 2:56 PM, Glen Canaday > > wrote: > > No Linux support is a total deal-breaker for me. > > > > I never said anything about the Linux viewer going away. > > I note that we have Pocket Metaverse now, and have had AjaxLife in the > > past. > > If it helps at all, I started with BSD Unix in 1981, Linux in 1994 ;) > > > > As is the case with web browsers, a VR client to the same server could > > take many forms. > > > > Ultimately, it's about what the community wants, and if a critical > > mass of developers decides to give them that. It doesn't have to be > > an official Linden effort at all. > > > > All I am saying is, in 2 years time, I cant see the current codebases > > even getting to the point where Unity 3.0 is today, in terms of > > graphics, physics, animation, terrain, and sound. > > But, I could see a pretty decent SL app done in Unity within that > > amount of time. > > > > And, of course, I am just an interested observer. I dont speak for > > LL, Vivaty, AOL, Autodesk, or anywhere else I have worked :) > > > > Daniel > > It's hard to see exactly where the rendering engine will go, really, in > 2 years. For a plugin-based client, as some (including myself) are > rather nudging towards, the renderer is just a part of the whole and > could in theory be hot-swapped if desired to A/B different engines. Even > if those renderers swapped between opengl and directx, it could still > fly. But to suggest that the main client perhaps go to something that > does not work across the board doesn't really include the whole of the > population - something which LL would be keen to retain. > > That's why I suggested Ogre instead. I personally think it would be a > better fit and more productive to look at. Others may have different > opinions. > > --GC > > > -- > > Daniel Smith - Sonoma County, California > > http://daniel.org/resume > > > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting > privileges > -- William Reed Seal Foss (Reed Steamroller) Chief Creative Officer Sand Castle Studios LLC | Second Life http://www.ChangingWorldsBuildingDreams.com Reed at ChangingWorldsBuildingDreams.com http://www.Twitter.com/ReedSteamroller -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101003/cafda38e/attachment-0001.htm From secret.argent at gmail.com Sun Oct 3 16:03:40 2010 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sun, 3 Oct 2010 18:03:40 -0500 Subject: [opensource-dev] Unity 3D as possible base for future (maybe even official) SL Viewers In-Reply-To: References: <4CA8957D.3040402@lindenlab.com> <4CA8B04B.4090801@comcast.net> <4CA8E6EF.9060703@boroon.dasgupta.ch> <1286142965.3438.12.camel@glen-desktop> <1286144147.3438.18.camel@glen-desktop> Message-ID: <771CA649-FB82-417E-B70A-DC7855CDB82B@gmail.com> On 2010-10-03, at 17:39, Reed Steamroller wrote: > Run Unity in a VM. Works for me. Run a 3d graphical application in a VM? [insert picture of the Biting Pear of Salamanca here] From sythos at gmail.com Sun Oct 3 16:26:27 2010 From: sythos at gmail.com (Altair Sythos Memo) Date: Mon, 4 Oct 2010 01:26:27 +0200 Subject: [opensource-dev] Unity 3D as possible base for future (maybe even official) SL Viewers In-Reply-To: <771CA649-FB82-417E-B70A-DC7855CDB82B@gmail.com> References: <4CA8957D.3040402@lindenlab.com> <4CA8B04B.4090801@comcast.net> <4CA8E6EF.9060703@boroon.dasgupta.ch> <1286142965.3438.12.camel@glen-desktop> <1286144147.3438.18.camel@glen-desktop> <771CA649-FB82-417E-B70A-DC7855CDB82B@gmail.com> Message-ID: <20101004012627.5769de27.sythos@gmail.com> On Sun, 3 Oct 2010 18:03:40 -0500 Argent Stonecutter wrote: > On 2010-10-03, at 17:39, Reed Steamroller wrote: > > Run Unity in a VM. Works for me. > > Run a 3d graphical application in a VM? Xen have a nice and working abstraction layer (tryed on nvidia) and allow guest OS to use full 3D hardware from guest to host.... this don't mean performance are like use from native os... From sldev at free.fr Sun Oct 3 16:46:24 2010 From: sldev at free.fr (Henri Beauchamp) Date: Mon, 4 Oct 2010 01:46:24 +0200 Subject: [opensource-dev] Question about LOD debug setting In-Reply-To: References: Message-ID: <20101004014624.2e674895.sldev@free.fr> On Sun, 3 Oct 2010 13:37:49 -0400, Ponzu wrote: > I picked up a notecard that says to increase RenderVolumeLODFactor to 4. Is > this reasonable, do you think? And if so, why not increase the default a > bit (currently seems to be 1.125 4 is OK for viewer v1.23.5. For Snowglobe (v1 and v2) and viewer 2, you should not use more than 3, because when using larger values, you will get graphic glitches with very small prims, especially with attachments: zooming out, they will vanish (as expected), but zooming back in, they will stay hidden 4 times out of 5 (zooming fast out and back in may get the small primes to appear again)... Henri. From exile at weylan-yutani.com Sun Oct 3 17:04:48 2010 From: exile at weylan-yutani.com (Robert "Exile In Paradise" Murphey) Date: Sun, 03 Oct 2010 19:04:48 -0500 Subject: [opensource-dev] Unity 3D as possible base for future (maybe even official) SL Viewers In-Reply-To: <1286144147.3438.18.camel@glen-desktop> References: <4CA8957D.3040402@lindenlab.com> <4CA8B04B.4090801@comcast.net> <4CA8E6EF.9060703@boroon.dasgupta.ch> <1286142965.3438.12.camel@glen-desktop> <1286144147.3438.18.camel@glen-desktop> Message-ID: <1286150688.2719.13.camel@nostromo> On Sun, 2010-10-03 at 18:15 -0400, Glen Canaday wrote: > That's why I suggested Ogre instead. I personally think it would be a > better fit and more productive to look at. Others may have different > opinions. Well, I run Linux and agree that being shut out after years of being supported would be suboptimal for me. Running in a VM is an exercise that only a masochist can love compared to an application natively supported. Plus, a VM position forces people to purchase additional OSes just to support one (or a handful) of apps, which add massive overheard in additional administration. At-home-VM is a temporary workaround, not a "platform strategy". Remember - SL is supposed to be Fast, Easy, Fun... not an enterprise-level support nightmare just to boot and run in the first place. Unity3D seems like a lot of "lose" to me: for the same amount of effort to switch to that, re-base on something else that keeps the same supported set of platforms or extends it without dropping already supported platforms. OGRE may be a great suggestion, especially in light of the RealXtend folks having already broken a LOT of the ground of an "SL client that uses OGRE rendering." Why re-reinvent their wheel? Maybe talk to them about Naali and see what goes from there? -- Robert "Exile In Paradise" Murphey Promise her anything, but give her Exxon unleaded. From xotmid at gmail.com Sun Oct 3 17:20:11 2010 From: xotmid at gmail.com (Brandon Husbands) Date: Sun, 3 Oct 2010 19:20:11 -0500 Subject: [opensource-dev] Unity 3D as possible base for future (maybe even official) SL Viewers In-Reply-To: <1286150688.2719.13.camel@nostromo> References: <4CA8957D.3040402@lindenlab.com> <4CA8B04B.4090801@comcast.net> <4CA8E6EF.9060703@boroon.dasgupta.ch> <1286142965.3438.12.camel@glen-desktop> <1286144147.3438.18.camel@glen-desktop> <1286150688.2719.13.camel@nostromo> Message-ID: Unity is the biggest POS i have ever used.... Not well designed. IMHO. Its like trying to do SL in javascript. Not literally but you know what i mean. It was never designed for a heavy network transport now multi player / mmo style. A FPS maybe but nothing on a grand scale. On Sun, Oct 3, 2010 at 7:04 PM, Robert "Exile In Paradise" Murphey < exile at weylan-yutani.com> wrote: > On Sun, 2010-10-03 at 18:15 -0400, Glen Canaday wrote: > > That's why I suggested Ogre instead. I personally think it would be a > > better fit and more productive to look at. Others may have different > > opinions. > > Well, I run Linux and agree that being shut out after > years of being supported would be suboptimal for me. > > Running in a VM is an exercise that only a masochist can love > compared to an application natively supported. > > Plus, a VM position forces people to purchase additional OSes > just to support one (or a handful) of apps, which add massive > overheard in additional administration. At-home-VM is a > temporary workaround, not a "platform strategy". > Remember - SL is supposed to be Fast, Easy, Fun... not an > enterprise-level support nightmare just to boot and run in > the first place. > > Unity3D seems like a lot of "lose" to me: for the same amount > of effort to switch to that, re-base on something else that keeps > the same supported set of platforms or extends it without dropping > already supported platforms. > > OGRE may be a great suggestion, especially in light of the RealXtend > folks having already broken a LOT of the ground of an "SL client > that uses OGRE rendering." Why re-reinvent their wheel? > Maybe talk to them about Naali and see what goes from there? > > -- > Robert "Exile In Paradise" Murphey > Promise her anything, but give her Exxon unleaded. > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting > privileges > -- ------------------------------------------------------------------------------------------------------------------------------- This email is a private and confidential communication. Any use of email may be subject to the laws and regulations of the United States. You may not Repost, Distribute nor reproduce any content of this message. ------------------------------------------------------------------------------------------------------------------------------- ------------------------------------------------------------------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101003/9d86b729/attachment.htm From mysticaldemina at xrgrid.com Sun Oct 3 17:41:52 2010 From: mysticaldemina at xrgrid.com (mysticaldemina at xrgrid.com) Date: Sun, 3 Oct 2010 20:41:52 -0400 Subject: [opensource-dev] Unity 3D as possible base for future (maybe even official) SL Viewers In-Reply-To: References: <4CA8957D.3040402@lindenlab.com> <4CA8B04B.4090801@comcast.net><4CA8E6EF.9060703@boroon.dasgupta.ch><1286142965.3438.12.camel@glen-desktop><1286144147.3438.18.camel@glen-desktop><1286150688.2719.13.camel@nostromo> Message-ID: <51D72C5392864F128AB05A712BD29339@TWEEDY64> Alright, this is the most incorrect post I have ever seen so I would guess you have used Unity for maybe a total of an one hour. First of all you can use any network technology you like. It does come with a very basic P2P network, but you can use many game server that you like included some that support fail over and fault tolerance configurations. In fact there are those using SL's server and rendering prims and sculpties in Unity. The scripting language can also use C# and supports a way more complete set of functions then is available in SL. This list is so long I don't know where to start on functionality it supports that LSL doesn't support. Not sure your point about FPS, it has Ambers Occlusion culling, beast lighting and deferred lighting which lets it create FPS you can't do in SL for the same amount of content. So if you are going to comment on Unity please do your homework and don't mislead people. M. _____ From: opensource-dev-bounces at lists.secondlife.com [mailto:opensource-dev-bounces at lists.secondlife.com] On Behalf Of Brandon Husbands Sent: Sunday, October 03, 2010 8:20 PM To: Robert Exile In Paradise Murphey Cc: opensource-dev at lists.secondlife.com Subject: Re: [opensource-dev] Unity 3D as possible base for future (maybe even official) SL Viewers Unity is the biggest POS i have ever used.... Not well designed. IMHO. Its like trying to do SL in javascript. Not literally but you know what i mean. It was never designed for a heavy network transport now multi player / mmo style. A FPS maybe but nothing on a grand scale. On Sun, Oct 3, 2010 at 7:04 PM, Robert "Exile In Paradise" Murphey wrote: On Sun, 2010-10-03 at 18:15 -0400, Glen Canaday wrote: > That's why I suggested Ogre instead. I personally think it would be a > better fit and more productive to look at. Others may have different > opinions. Well, I run Linux and agree that being shut out after years of being supported would be suboptimal for me. Running in a VM is an exercise that only a masochist can love compared to an application natively supported. Plus, a VM position forces people to purchase additional OSes just to support one (or a handful) of apps, which add massive overheard in additional administration. At-home-VM is a temporary workaround, not a "platform strategy". Remember - SL is supposed to be Fast, Easy, Fun... not an enterprise-level support nightmare just to boot and run in the first place. Unity3D seems like a lot of "lose" to me: for the same amount of effort to switch to that, re-base on something else that keeps the same supported set of platforms or extends it without dropping already supported platforms. OGRE may be a great suggestion, especially in light of the RealXtend folks having already broken a LOT of the ground of an "SL client that uses OGRE rendering." Why re-reinvent their wheel? Maybe talk to them about Naali and see what goes from there? -- Robert "Exile In Paradise" Murphey Promise her anything, but give her Exxon unleaded. _______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges -- ---------------------------------------------------------------------------- --------------------------------------------------- This email is a private and confidential communication. Any use of email may be subject to the laws and regulations of the United States. You may not Repost, Distribute nor reproduce any content of this message. ---------------------------------------------------------------------------- --------------------------------------------------- ---------------------------------------------------------------------------- --------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101003/7e78e94f/attachment-0001.htm From dz at bitzend.net Sun Oct 3 18:37:40 2010 From: dz at bitzend.net (dz) Date: Sun, 3 Oct 2010 18:37:40 -0700 Subject: [opensource-dev] Uses of the Lookat target Crosshairs Message-ID: Folks, Apologies if this is NOT the place to post this...but I really don't know who else to ask. Yesterday I encountered an avatar who exhibited a very strange behavior. Whenever someone in the club spoke in local chat, a Look At target would attach to them. I understand there is a toggle to have your look at swap to the the most recent to chat, but this look at target was white... which is not a standard cross hair color. The other incredibly odd thing was that the look at target stayed locked once there.. Because I was using the phoenix browser, which puts names on the targets, I could see that there were as many as 30 of these targets active at once. Does anyone know of a way to determine what the white target denotes, how it gets attached to multiple targets at once? When i asked the avatar I got a very rude response... When I carried my concern to the club owner, I got more rudeness and denials.. but it seemed clear that there was some intent behind the crosshairs, as they were removed shortly after I expressed my concerns. D -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101003/18e27af4/attachment.htm From latifer at streamgrid.net Sun Oct 3 18:55:26 2010 From: latifer at streamgrid.net (Latif Khalifa) Date: Mon, 4 Oct 2010 03:55:26 +0200 Subject: [opensource-dev] Uses of the Lookat target Crosshairs In-Reply-To: References: Message-ID: You are reading too much into these "targets". Those are just viewer effects that help your viewer position head and the direction of eyes of the avatar to the desired location. They have no other use. Latif On Mon, Oct 4, 2010 at 3:37 AM, dz wrote: > Folks, > > Apologies if this is NOT the place to post this...but I really don't know > who else to ask. > > Yesterday I encountered an avatar who exhibited a very strange behavior. > Whenever someone in the club spoke in local chat, a Look At target would > attach to them.? I understand there is a toggle to have your look at swap to > the the most recent to chat,?? but this look at target was white...? which > is not a standard cross hair color. > > The other incredibly odd thing? was that the look at target stayed locked > once there..? Because I was using the phoenix browser, which puts names on > the targets, I could see that there were as many as 30 of these targets > active at once. > > Does anyone know of a way to determine? what the white target denotes, how > it gets attached to multiple targets at once? > > When i asked the avatar? I got a very rude response...? When I carried my > concern to the club owner, I got more rudeness and denials.. but it seemed > clear that there was some intent behind the crosshairs, as they were removed > shortly after I expressed my concerns. > > D > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting > privileges > From xotmid at gmail.com Sun Oct 3 18:56:37 2010 From: xotmid at gmail.com (Brandon Husbands) Date: Sun, 3 Oct 2010 20:56:37 -0500 Subject: [opensource-dev] Unity 3D as possible base for future (maybe even official) SL Viewers In-Reply-To: <51D72C5392864F128AB05A712BD29339@TWEEDY64> References: <4CA8957D.3040402@lindenlab.com> <4CA8B04B.4090801@comcast.net> <4CA8E6EF.9060703@boroon.dasgupta.ch> <1286142965.3438.12.camel@glen-desktop> <1286144147.3438.18.camel@glen-desktop> <1286150688.2719.13.camel@nostromo> <51D72C5392864F128AB05A712BD29339@TWEEDY64> Message-ID: Actually its not inaccurate. The tools themselves are clunky.. And i am not taking this as a lsl vs their language. I am talking about the engine itself. From a lower level perspective. Unity is really more of a middleware when it comes to graphics engines. sure you can use any network you want but in a whole as what it offers as a base is not what would be able to be used for something on the scale of sl. Also as a user you would not have those midddle ware tools that you see unless you want the whole thing to be clunky. Its rigging and control system is designed for rapid prototyping and higher level designig. I would put unity as an equivilant to making a mod for a fps with "good" tools unlike most mod systems. But as a complete engine from a graphics and other standpoints The hero engine blows that away. Actually there are quite a few game engines that surpass unity. And if we take thoes its like compairing writing with QT vs flash. (not quick time... but QT). Flash is great as a packaged thing but its limited. Now unity can me modified and such to some extent but no where whats needed for a SL type of thing. And for the record I am not a fan boi of any engine or system. But i have developed a mmo from the ground up in 2001 to playable alpha 2 on the cusp of beta before the project was shelved due to funding. Having written a majority of the Engine and most of the server code. I would thing these are subjects i am quite capable of assessing. On Sun, Oct 3, 2010 at 7:41 PM, wrote: > Alright, this is the most incorrect post I have ever seen so I would > guess you have used Unity for maybe a total of an one hour. > > > > First of all you can use any network technology you like. It does come > with a very basic P2P network, but you can use many game server that you > like included some that support fail over and fault tolerance > configurations. In fact there are those using SL?s server and rendering > prims and sculpties in Unity. > > > > The scripting language can also use C# and supports a way more complete set > of functions then is available in SL. This list is so long I don?t know > where to start on functionality it supports that LSL doesn?t support. > > > > Not sure your point about FPS, it has Ambers Occlusion culling, beast > lighting and deferred lighting which lets it create FPS you can?t do in SL > for the same amount of content. > > > > So if you are going to comment on Unity please do your homework and don?t > mislead people. > > > > M. > > > > > > > ------------------------------ > > *From:* opensource-dev-bounces at lists.secondlife.com [mailto: > opensource-dev-bounces at lists.secondlife.com] *On Behalf Of *Brandon > Husbands > *Sent:* Sunday, October 03, 2010 8:20 PM > *To:* Robert Exile In Paradise Murphey > *Cc:* opensource-dev at lists.secondlife.com > *Subject:* Re: [opensource-dev] Unity 3D as possible base for future > (maybe even official) SL Viewers > > > > Unity is the biggest POS i have ever used.... > Not well designed. IMHO. Its like trying to do SL in javascript. > Not literally but you know what i mean. > > It was never designed for a heavy network transport now multi player / mmo > style. > > A FPS maybe but nothing on a grand scale. > > On Sun, Oct 3, 2010 at 7:04 PM, Robert "Exile In Paradise" Murphey < > exile at weylan-yutani.com> wrote: > > On Sun, 2010-10-03 at 18:15 -0400, Glen Canaday wrote: > > That's why I suggested Ogre instead. I personally think it would be a > > better fit and more productive to look at. Others may have different > > opinions. > > Well, I run Linux and agree that being shut out after > years of being supported would be suboptimal for me. > > Running in a VM is an exercise that only a masochist can love > compared to an application natively supported. > > Plus, a VM position forces people to purchase additional OSes > just to support one (or a handful) of apps, which add massive > overheard in additional administration. At-home-VM is a > temporary workaround, not a "platform strategy". > Remember - SL is supposed to be Fast, Easy, Fun... not an > enterprise-level support nightmare just to boot and run in > the first place. > > Unity3D seems like a lot of "lose" to me: for the same amount > of effort to switch to that, re-base on something else that keeps > the same supported set of platforms or extends it without dropping > already supported platforms. > > OGRE may be a great suggestion, especially in light of the RealXtend > folks having already broken a LOT of the ground of an "SL client > that uses OGRE rendering." Why re-reinvent their wheel? > Maybe talk to them about Naali and see what goes from there? > > -- > Robert "Exile In Paradise" Murphey > Promise her anything, but give her Exxon unleaded. > > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting > privileges > > > > > -- > > ------------------------------------------------------------------------------------------------------------------------------- > This email is a private and confidential communication. Any use of email > may be subject to the laws and regulations of the United States. You may not > Repost, Distribute nor reproduce any content of this message. > > ------------------------------------------------------------------------------------------------------------------------------- > > ------------------------------------------------------------------------------------------------------------------------------- > -- ------------------------------------------------------------------------------------------------------------------------------- This email is a private and confidential communication. Any use of email may be subject to the laws and regulations of the United States. You may not Repost, Distribute nor reproduce any content of this message. ------------------------------------------------------------------------------------------------------------------------------- ------------------------------------------------------------------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101003/4dd77b64/attachment.htm From mysticaldemina at xrgrid.com Sun Oct 3 19:36:03 2010 From: mysticaldemina at xrgrid.com (mysticaldemina at xrgrid.com) Date: Sun, 3 Oct 2010 22:36:03 -0400 Subject: [opensource-dev] Unity 3D as possible base for future (maybe even official) SL Viewers In-Reply-To: References: <4CA8957D.3040402@lindenlab.com><4CA8B04B.4090801@comcast.net><4CA8E6EF.9060703@boroon.dasgupta.ch><1286142965.3438.12.camel@glen-desktop><1286144147.3438.18.camel@glen-desktop><1286150688.2719.13.camel@nostromo><51D72C5392864F128AB05A712BD29339@TWEEDY64> Message-ID: <099C27DF404C4A48A05B1D20510E7CFF@TWEEDY64> Obviously these are subjective statements but I think your statements are based on an incomplete understanding of the tool and probably limited experience using it. Not sure how you can say it is clunky. I have a scene hierarchy where I can list and see every object in my seen. It's like seeing every prim in my region. I can select any object and view it in the inspector. Scripts are assigned to objects and not copied and duplicated into each prim. I can edit a script once and every object that uses it gets that update. In the inspector I can see every public value of the script and change its value without having to actually edit the script. I can use assets directly from my disk without having to upload them when creating. That is much faster than waiting for SL to do things. Scripts can access to every bone in the skeleton system and I can override animations to adjust the bones to a given scene's needs, for instance if two avatars are a different height and I can adjust the bones to make their hands connect so they can really walk hand in hand. I can create keyed animations in Unity or use animations from other programs. Animates can throw events which can trigger code to do things. From missannotoole at yahoo.com Sun Oct 3 21:01:00 2010 From: missannotoole at yahoo.com (Ann Otoole) Date: Sun, 3 Oct 2010 21:01:00 -0700 (PDT) Subject: [opensource-dev] Question about LOD debug setting In-Reply-To: <20101004014624.2e674895.sldev@free.fr> References: <20101004014624.2e674895.sldev@free.fr> Message-ID: <290905.70556.qm@web120511.mail.ne1.yahoo.com> Whats the jira for this defect you say exists that I have never once observed despite always using a setting of 4? There is a different debug setting calledRenderMaxNodeSize that produces the behavior you noted btw. It's default is 8192. Go lower and what you describe happens. ________________________________ From: Henri Beauchamp To: opensource-dev at lists.secondlife.com Sent: Sun, October 3, 2010 7:46:24 PM Subject: Re: [opensource-dev] Question about LOD debug setting On Sun, 3 Oct 2010 13:37:49 -0400, Ponzu wrote: > I picked up a notecard that says to increase RenderVolumeLODFactor to 4. Is > this reasonable, do you think? And if so, why not increase the default a > bit (currently seems to be 1.125 4 is OK for viewer v1.23.5. For Snowglobe (v1 and v2) and viewer 2, you should not use more than 3, because when using larger values, you will get graphic glitches with very small prims, especially with attachments: zooming out, they will vanish (as expected), but zooming back in, they will stay hidden 4 times out of 5 (zooming fast out and back in may get the small primes to appear again)... Henri. _______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101003/2b8c7539/attachment.htm From xotmid at gmail.com Sun Oct 3 21:36:45 2010 From: xotmid at gmail.com (Brandon Husbands) Date: Sun, 3 Oct 2010 23:36:45 -0500 Subject: [opensource-dev] Unity 3D as possible base for future (maybe even official) SL Viewers In-Reply-To: <099C27DF404C4A48A05B1D20510E7CFF@TWEEDY64> References: <4CA8957D.3040402@lindenlab.com> <4CA8B04B.4090801@comcast.net> <4CA8E6EF.9060703@boroon.dasgupta.ch> <1286142965.3438.12.camel@glen-desktop> <1286144147.3438.18.camel@glen-desktop> <1286150688.2719.13.camel@nostromo> <51D72C5392864F128AB05A712BD29339@TWEEDY64> <099C27DF404C4A48A05B1D20510E7CFF@TWEEDY64> Message-ID: Ive used it, and fount it blehh. I think we are failing to communicate about our conception of what is possible and what is used. Are you saying that the normal user would have full access to what you use to develop the "client"? As its a middle ware really i fail to see how your going to implement that. I could be wrong. There are so many propitiatory things that you'd have to code in and handle rendering for with sl. Also remember you can not change the server backend. I just do not see it possible or powerful enough to handle what sl uses and does. I guess its the same concept between higher level langs and lower level ones. I could be wrong about this and just be old school in my thoughts. If your so sure that it can do what needs to be done why have you not already done a prototype. From robin.cornelius at gmail.com Mon Oct 4 02:14:13 2010 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Mon, 4 Oct 2010 10:14:13 +0100 Subject: [opensource-dev] Uses of the Lookat target Crosshairs In-Reply-To: References: Message-ID: On Mon, Oct 4, 2010 at 2:55 AM, Latif Khalifa wrote: > You are reading too much into these "targets". Those are just viewer > effects that help your viewer position head and the direction of eyes > of the avatar to the desired location. They have no other use. > Yes as Latif says there only purpose is for the head turn/look at animation so that your avatar will turn its head towards the chat source for a nice i'm listening to you effect. The LL viewer uses a small back off so that in busy areas you are not flipping your head everywhere and i would guess the LL viewer correctly clears the look at effect after a short time. Some viewers (i believed introduced by Emerald) seem to make a big deal out of the look at crosshairs, then if another viewer comes along that does not correctly clear the lookat effect you get rude IMs asking why your crosshairs are on me. I've had this before with one of my viewers, it was not clearing the look at, so in a busy area i quickly ended up with crosshairs on everyone who had spoken then started getting rude IMs from emerald users who had the look at cross hairs turned on and could see where they were pointed. Robin From sldev at free.fr Mon Oct 4 02:17:40 2010 From: sldev at free.fr (Henri Beauchamp) Date: Mon, 4 Oct 2010 11:17:40 +0200 Subject: [opensource-dev] Question about LOD debug setting In-Reply-To: <290905.70556.qm@web120511.mail.ne1.yahoo.com> References: <20101004014624.2e674895.sldev@free.fr> <290905.70556.qm@web120511.mail.ne1.yahoo.com> Message-ID: <20101004111740.412b75fe.sldev@free.fr> On Sun, 3 Oct 2010 21:01:00 -0700 (PDT), Ann Otoole wrote: > Whats the jira for this defect you say exists that I have never once observed > despite always using a setting of 4? I don't contribute to the JIRA any more: what's the point when LL marks the issues as "will not finish" or just plain ignores them for years, and when even your patches are not taken into account because they want a contribution agreement that endangers your privacy and anhilates your anonimity ?... As for a repro, I just sent you a test object in-world: it's derivated from a collar, and I reduced it to its simplest expression (5 prims in total) to demonstrate the issue: a torus (the 'collar'), and four little LEDs on its side, each made out of a sphere (around 0.015m big), hollowed at 70% and dimpled at 95%. Remove all attachments on your Av (so that there is no possible issue with the number of prims attached to your Av), and "Wear" the demonstrator (it attaches to your Av's spine and appears around its neck). - Start Snowglobe v1.4, 1.5 or v2.2, or even tyhe latest beta viewer v2.2 - Set your RenderVolumeLODFactor to 1.0, and zoom in and out on the leds: no problem. - Set your RenderVolumeLODFactor to 4.0 and zoom out and back in. 4 times out of 5 the LEDs do not come back when zooming it. In fact, the slower you zoom in, the less they are likely to reappear. If you zoom in real fast, they may come back. - Log off and start viewer v1.23.5. - Repeat the procedure: no issue at all, even with larger LOD factors. In fact any LOD factor above 2.0 shows the issue from times to time, and anything above 3.0 shows it almost everytime. > There is a different debug setting calledRenderMaxNodeSize that produces > the behavior you noted btw. It's default is 8192. Go lower and what you > describe happens. This has no influence whatsoever on the above issue. It's also set to 8192 for me anyway, and even doubling this number doesn't prevent the issue from happening Henri. From teravus at gmail.com Mon Oct 4 05:32:04 2010 From: teravus at gmail.com (Teravus Ovares) Date: Mon, 4 Oct 2010 08:32:04 -0400 Subject: [opensource-dev] Unity 3D as possible base for future (maybe even official) SL Viewers In-Reply-To: References: <4CA8957D.3040402@lindenlab.com> <4CA8B04B.4090801@comcast.net> <4CA8E6EF.9060703@boroon.dasgupta.ch> <1286142965.3438.12.camel@glen-desktop> <1286144147.3438.18.camel@glen-desktop> <1286150688.2719.13.camel@nostromo> <51D72C5392864F128AB05A712BD29339@TWEEDY64> <099C27DF404C4A48A05B1D20510E7CFF@TWEEDY64> Message-ID: When working on IdealistViewer, I noticed that, generally, third party 'general purpose' renderers like Irrlicht and Ogre are not well suited for rendering objects at the quantity that SecondLife prims require. Rendering prims /can/ be done with them, however, not at the level that can be done with the SecondLife viewer. With Irrlicht, for example, the memory load of a typical 5000 prim scene runs up against the 2GB memory limit. With SecondLife prims, it's more about segmenting the render data so that only the unique things are kept and everything else is a reference to something that was calculated before. Out of the box, Irrlicht requires per-instance knowledge about texture, mesh buffer, face and lighting settings configurations. This and reference/const/value type semantics used in the engine causes far more data duplications then are necessary. Prims are strange for rendering. The prim's mesh result is complex in terms of vertex count however, in a given 5000 prim scene there's on average 130 'unique' prim mesh. Those 130 unique mesh are duplicated with various textures, colors, orientations and associated data to make for the entire prim count in the region. In theory, you can manage memory reasonably well by using a 'mesh factory' pattern where by the mesh factory keeps track of instance counts and generates a new mesh when required. In practice, however, the associated data makes this very difficult. In Irrlicht, the API is such that the texture configuration data is 'stuck in with' the mesh data object. So, to get the variability that the secondlife prim scene requires, you're also duplicating the mesh and making small changes to the object's visual configuration data. Irrlicht, like Ogre, is better optimized for a smaller number of more complex mesh objects then a very large number of highly 'instancable' objects with very small differences. I'd comment on the opposite of the last statement... but I don't really know about how the SecondLife viewer works under the hood to do so (OpenSimulator Developer). I don't think that this issue is going to 'go away'. In fact, introducing mesh in the viewer is going to make that memory, speed, and instancing balance even more difficult to maintain. The gap between the viewer and 3rd party 'general purpose' rendering tools will narrow in both directions.. the viewer will get better at managing arbitrary mesh and 3rd party 'general purpose' rendering tools will be able to render secondlife scenes better because there will be less 'prim' to render as a result of there being arbitrary mesh. In either case, the future is full of interesting technical challenges. I think in unity, like with Irrlicht, smaller, more specialized scenes will work OK with regards to prim rendering. And, I don't think 3rd party renderers are going to be able to come close to the capability of the SecondLife viewer when dealing with prim. They're just not designed for the same type of data. The object models and API just are not really appropriate for prim. I'm not saying that it isn't worth pursuing a render plugin architecture. I am saying, however, that given that 3rd party 'general purpose' renderers are never going to be able to meet the SecondLife viewer's capability in rendering prim, it probably shouldn't be very high on the priority of things to do. Regards Teravus On Mon, Oct 4, 2010 at 12:36 AM, Brandon Husbands wrote: > Ive used it, and fount it blehh. I think we are failing to communicate > about our conception of what is possible and what is used. > > Are you saying that the normal user would have full access to what you use > to develop the "client"? > As its a middle ware really i fail to see how your going to implement that. > I could be wrong. There are so many propitiatory things that you'd have to > code in and handle rendering for with sl. Also remember you can not change > the server backend. I just do not see it possible or powerful enough to > handle what sl uses and does. I guess its the same concept between higher > level langs and lower level ones. I could be wrong about this and just be > old school in my thoughts. > > If your so sure that it can do what needs to be done why have you not > already done a prototype. > From what your saying should be easy to get connected and render the scene. > > > I would love to be wrong in that regard but then again i just don't see how > your going to handle such things in a closed source engine. > > > > > On Sun, Oct 3, 2010 at 9:36 PM, wrote: > >> Obviously these are subjective statements but I think your statements >> are based on an incomplete understanding of the tool and probably limited >> experience using it. >> >> >> >> Not sure how you can say it is clunky. I have a scene hierarchy where I >> can list and see every object in my seen. It?s like seeing every prim in my >> region. I can select any object and view it in the inspector. >> >> >> >> Scripts are assigned to objects and not copied and duplicated into each >> prim. I can edit a script once and every object that uses it gets that >> update. >> >> >> >> In the inspector I can see every public value of the script and change its >> value without having to actually edit the script. >> >> >> >> I can use assets directly from my disk without having to upload them when >> creating. That is much faster than waiting for SL to do things. >> >> >> >> Scripts can access to every bone in the skeleton system and I can override >> animations to adjust the bones to a given scene?s needs, for instance if two >> avatars are a different height and I can adjust the bones to make their >> hands connect so they can really walk hand in hand. >> >> >> >> I can create keyed animations in Unity or use animations from other >> programs. Animates can throw events which can trigger code to do things. >> From scripts you can create and edit the animations and their key data. >> You can layer animations, set their weights. You can sync the length of >> layers. Cross fade animations. >> >> >> >> You have materials like you do in Maya. >> >> >> >> I can create custom shaders. >> >> >> >> You can have spot lights, point lights and directional lights. >> >> >> >> You can create your own skyboxes. >> >> >> >> You can use water any where, not limited to just one plane with the water >> shader. >> >> >> >> I can use meshes. Any object in the scene can have a skeleton. >> >> >> >> I can edit meshes and vertices in real-time allowing me to create >> parameterized content in real-time. >> >> >> >> I can load assets from a URL or through websockets. >> >> >> >> I can load textures from a URL or through websockets. >> >> >> >> There is a profiler that lets me see in great detail what the engine is >> doing. >> >> >> >> I can use Visual Studio to develop my scripts with all the features of >> Visual Studio. >> >> >> >> I can run a debugger and debug the scripts and libraries I am using in the >> scene. >> >> >> >> I can do baked lighting including ambient occlusion inside the tool >> >> >> >> I can do occlusion culling so I can have very large scenes. >> >> >> >> I can control what assets are loading and stream the rest in the >> background. >> >> >> >> I can use libraries of code. >> >> >> >> From one code base I can be published to many platforms including web and >> mobile phone. Linux is the big one they are missing a native support for. >> >> >> >> Should I go on? >> >> >> >> >> >> This is a group that is focused on Second Life client so not trying to >> convince anyone to switch. But I do think it is fair that people give >> accurate information based on real experience and not guessing. I think if >> you understood the tool more you will see your statements are based on >> inaccurate understanding of the tool. >> >> >> >> I personally do believe that the game development platforms will outpace >> anyone doing proprietary client development and as such the days are quickly >> approaching where you won?t be able to justify the cost of developing your >> own client rendering engines when you can get the features off the shelf for >> $1200 that would cost you way more to do yourself. I also believe you won?t >> stay up and will find yourself quickly falling behind. >> >> >> >> M. >> >> >> >> >> >> >> >> >> ------------------------------ >> >> *From:* Brandon Husbands [mailto:xotmid at gmail.com] >> *Sent:* Sunday, October 03, 2010 9:57 PM >> *To:* mysticaldemina at xrgrid.com >> *Cc:* Robert Exile In Paradise Murphey; >> opensource-dev at lists.secondlife.com >> >> *Subject:* Re: [opensource-dev] Unity 3D as possible base for future >> (maybe even official) SL Viewers >> >> >> >> Actually its not inaccurate. The tools themselves are clunky.. And i am >> not taking this as a lsl vs their language. I am talking about the engine >> itself. From a lower level perspective. Unity is really more of a >> middleware when it comes to graphics engines. sure you can use any network >> you want but in a whole as what it offers as a base is not what would be >> able to be used for something on the scale of sl. >> >> Also as a user you would not have those midddle ware tools that you see >> unless you want the whole thing to be clunky. >> >> Its rigging and control system is designed for rapid prototyping and >> higher level designig. >> >> I would put unity as an equivilant to making a mod for a fps with "good" >> tools unlike most mod systems. >> >> But as a complete engine from a graphics and other standpoints The hero >> engine blows that away. Actually there are quite a few game engines that >> surpass unity. And if we take thoes its like compairing writing with QT vs >> flash. (not quick time... but QT). >> >> Flash is great as a packaged thing but its limited. Now unity can me >> modified and such to some extent but no where whats needed for a SL type of >> thing. >> >> And for the record I am not a fan boi of any engine or system. But i have >> developed a mmo from the ground up in 2001 to playable alpha 2 on the cusp >> of beta before the project was shelved due to funding. >> Having written a majority of the Engine and most of the server code. I >> would thing these are subjects i am quite capable of assessing. >> >> >> On Sun, Oct 3, 2010 at 7:41 PM, wrote: >> >> Alright, this is the most incorrect post I have ever seen so I would guess >> you have used Unity for maybe a total of an one hour. >> >> >> >> First of all you can use any network technology you like. It does come >> with a very basic P2P network, but you can use many game server that you >> like included some that support fail over and fault tolerance >> configurations. In fact there are those using SL?s server and rendering >> prims and sculpties in Unity. >> >> >> >> The scripting language can also use C# and supports a way more complete >> set of functions then is available in SL. This list is so long I don?t know >> where to start on functionality it supports that LSL doesn?t support. >> >> >> >> Not sure your point about FPS, it has Ambers Occlusion culling, beast >> lighting and deferred lighting which lets it create FPS you can?t do in SL >> for the same amount of content. >> >> >> >> So if you are going to comment on Unity please do your homework and don?t >> mislead people. >> >> >> >> M. >> >> >> >> >> >> >> ------------------------------ >> >> *From:* opensource-dev-bounces at lists.secondlife.com [mailto: >> opensource-dev-bounces at lists.secondlife.com] *On Behalf Of *Brandon >> Husbands >> *Sent:* Sunday, October 03, 2010 8:20 PM >> *To:* Robert Exile In Paradise Murphey >> *Cc:* opensource-dev at lists.secondlife.com >> *Subject:* Re: [opensource-dev] Unity 3D as possible base for future >> (maybe even official) SL Viewers >> >> >> >> Unity is the biggest POS i have ever used.... >> Not well designed. IMHO. Its like trying to do SL in javascript. >> Not literally but you know what i mean. >> >> It was never designed for a heavy network transport now multi player / mmo >> style. >> >> A FPS maybe but nothing on a grand scale. >> >> On Sun, Oct 3, 2010 at 7:04 PM, Robert "Exile In Paradise" Murphey < >> exile at weylan-yutani.com> wrote: >> >> On Sun, 2010-10-03 at 18:15 -0400, Glen Canaday wrote: >> > That's why I suggested Ogre instead. I personally think it would be a >> > better fit and more productive to look at. Others may have different >> > opinions. >> >> Well, I run Linux and agree that being shut out after >> years of being supported would be suboptimal for me. >> >> Running in a VM is an exercise that only a masochist can love >> compared to an application natively supported. >> >> Plus, a VM position forces people to purchase additional OSes >> just to support one (or a handful) of apps, which add massive >> overheard in additional administration. At-home-VM is a >> temporary workaround, not a "platform strategy". >> Remember - SL is supposed to be Fast, Easy, Fun... not an >> enterprise-level support nightmare just to boot and run in >> the first place. >> >> Unity3D seems like a lot of "lose" to me: for the same amount >> of effort to switch to that, re-base on something else that keeps >> the same supported set of platforms or extends it without dropping >> already supported platforms. >> >> OGRE may be a great suggestion, especially in light of the RealXtend >> folks having already broken a LOT of the ground of an "SL client >> that uses OGRE rendering." Why re-reinvent their wheel? >> Maybe talk to them about Naali and see what goes from there? >> >> -- >> Robert "Exile In Paradise" Murphey >> Promise her anything, but give her Exxon unleaded. >> >> >> >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/OpenSource-Dev >> Please read the policies before posting to keep unmoderated posting >> privileges >> >> >> >> >> -- >> >> ------------------------------------------------------------------------------------------------------------------------------- >> This email is a private and confidential communication. Any use of email >> may be subject to the laws and regulations of the United States. You may not >> Repost, Distribute nor reproduce any content of this message. >> >> ------------------------------------------------------------------------------------------------------------------------------- >> >> ------------------------------------------------------------------------------------------------------------------------------- >> >> >> >> >> -- >> >> ------------------------------------------------------------------------------------------------------------------------------- >> This email is a private and confidential communication. Any use of email >> may be subject to the laws and regulations of the United States. You may not >> Repost, Distribute nor reproduce any content of this message. >> >> ------------------------------------------------------------------------------------------------------------------------------- >> >> ------------------------------------------------------------------------------------------------------------------------------- >> > > > > -- > > ------------------------------------------------------------------------------------------------------------------------------- > This email is a private and confidential communication. Any use of email > may be subject to the laws and regulations of the United States. You may not > Repost, Distribute nor reproduce any content of this message. > > ------------------------------------------------------------------------------------------------------------------------------- > > ------------------------------------------------------------------------------------------------------------------------------- > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101004/9aa331df/attachment-0001.htm From neil at knowsense.co.uk Mon Oct 4 05:51:09 2010 From: neil at knowsense.co.uk (Neil Canham) Date: Mon, 4 Oct 2010 13:51:09 +0100 Subject: [opensource-dev] Unity 3D as possible base for future (maybe even official) SL Viewers In-Reply-To: References: <4CA8957D.3040402@lindenlab.com> <4CA8B04B.4090801@comcast.net> <4CA8E6EF.9060703@boroon.dasgupta.ch> <1286142965.3438.12.camel@glen-desktop> <1286144147.3438.18.camel@glen-desktop> <1286150688.2719.13.camel@nostromo> <51D72C5392864F128AB05A712BD29339@TWEEDY64> <099C27DF404C4A48A05B1D20510E7CFF@TWEEDY64> Message-ID: Just want to says thanks Teravus for a very insightful and informative post. Neil Canham On Mon, Oct 4, 2010 at 1:32 PM, Teravus Ovares wrote: > When working on IdealistViewer, I noticed that, generally, third party > 'general purpose' renderers like Irrlicht and Ogre are not well suited for > rendering objects at the quantity that SecondLife prims require. Rendering > prims /can/ be done with them, however, not at the level that can be done > with the SecondLife viewer. > > With Irrlicht, for example, the memory load of a typical 5000 prim scene > runs up against the 2GB memory limit. > > With SecondLife prims, it's more about segmenting the render data so that > only the unique things are kept and everything else is a reference to > something that was calculated before. Out of the box, Irrlicht requires > per-instance knowledge about texture, mesh buffer, face and lighting > settings configurations. This and reference/const/value type semantics > used in the engine causes far more data duplications then are necessary. > > Prims are strange for rendering. The prim's mesh result is complex in > terms of vertex count however, in a given 5000 prim scene there's on average > 130 'unique' prim mesh. Those 130 unique mesh are duplicated with various > textures, colors, orientations and associated data to make for the entire > prim count in the region. In theory, you can manage memory reasonably well > by using a 'mesh factory' pattern where by the mesh factory keeps track of > instance counts and generates a new mesh when required. In practice, > however, the associated data makes this very difficult. In Irrlicht, the > API is such that the texture configuration data is 'stuck in with' the mesh > data object. So, to get the variability that the secondlife prim scene > requires, you're also duplicating the mesh and making small changes to the > object's visual configuration data. > > Irrlicht, like Ogre, is better optimized for a smaller number of more > complex mesh objects then a very large number of highly 'instancable' > objects with very small differences. I'd comment on the opposite of the > last statement... but I don't really know about how the SecondLife viewer > works under the hood to do so (OpenSimulator Developer). > > I don't think that this issue is going to 'go away'. In fact, introducing > mesh in the viewer is going to make that memory, speed, and instancing > balance even more difficult to maintain. The gap between the viewer and > 3rd party 'general purpose' rendering tools will narrow in both directions.. > the viewer will get better at managing arbitrary mesh and 3rd party 'general > purpose' rendering tools will be able to render secondlife scenes better > because there will be less 'prim' to render as a result of there being > arbitrary mesh. > > In either case, the future is full of interesting technical challenges. > I think in unity, like with Irrlicht, smaller, more specialized scenes will > work OK with regards to prim rendering. And, I don't think 3rd party > renderers are going to be able to come close to the capability of the > SecondLife viewer when dealing with prim. They're just not designed for the > same type of data. The object models and API just are not really > appropriate for prim. I'm not saying that it isn't worth pursuing a render > plugin architecture. I am saying, however, that given that 3rd party > 'general purpose' renderers are never going to be able to meet the > SecondLife viewer's capability in rendering prim, it probably shouldn't be > very high on the priority of things to do. > > Regards > > Teravus > > > On Mon, Oct 4, 2010 at 12:36 AM, Brandon Husbands wrote: > >> Ive used it, and fount it blehh. I think we are failing to communicate >> about our conception of what is possible and what is used. >> >> Are you saying that the normal user would have full access to what you use >> to develop the "client"? >> As its a middle ware really i fail to see how your going to implement >> that. >> I could be wrong. There are so many propitiatory things that you'd have to >> code in and handle rendering for with sl. Also remember you can not change >> the server backend. I just do not see it possible or powerful enough to >> handle what sl uses and does. I guess its the same concept between higher >> level langs and lower level ones. I could be wrong about this and just be >> old school in my thoughts. >> >> If your so sure that it can do what needs to be done why have you not >> already done a prototype. >> From what your saying should be easy to get connected and render the >> scene. >> >> I would love to be wrong in that regard but then again i just don't see >> how your going to handle such things in a closed source engine. >> >> >> >> >> On Sun, Oct 3, 2010 at 9:36 PM, wrote: >> >>> Obviously these are subjective statements but I think your statements >>> are based on an incomplete understanding of the tool and probably limited >>> experience using it. >>> >>> >>> >>> Not sure how you can say it is clunky. I have a scene hierarchy where I >>> can list and see every object in my seen. It?s like seeing every prim in my >>> region. I can select any object and view it in the inspector. >>> >>> >>> >>> Scripts are assigned to objects and not copied and duplicated into each >>> prim. I can edit a script once and every object that uses it gets that >>> update. >>> >>> >>> >>> In the inspector I can see every public value of the script and change >>> its value without having to actually edit the script. >>> >>> >>> >>> I can use assets directly from my disk without having to upload them when >>> creating. That is much faster than waiting for SL to do things. >>> >>> >>> >>> Scripts can access to every bone in the skeleton system and I can >>> override animations to adjust the bones to a given scene?s needs, for >>> instance if two avatars are a different height and I can adjust the bones to >>> make their hands connect so they can really walk hand in hand. >>> >>> >>> >>> I can create keyed animations in Unity or use animations from other >>> programs. Animates can throw events which can trigger code to do things. >>> From scripts you can create and edit the animations and their key data. >>> You can layer animations, set their weights. You can sync the length of >>> layers. Cross fade animations. >>> >>> >>> >>> You have materials like you do in Maya. >>> >>> >>> >>> I can create custom shaders. >>> >>> >>> >>> You can have spot lights, point lights and directional lights. >>> >>> >>> >>> You can create your own skyboxes. >>> >>> >>> >>> You can use water any where, not limited to just one plane with the water >>> shader. >>> >>> >>> >>> I can use meshes. Any object in the scene can have a skeleton. >>> >>> >>> >>> I can edit meshes and vertices in real-time allowing me to create >>> parameterized content in real-time. >>> >>> >>> >>> I can load assets from a URL or through websockets. >>> >>> >>> >>> I can load textures from a URL or through websockets. >>> >>> >>> >>> There is a profiler that lets me see in great detail what the engine is >>> doing. >>> >>> >>> >>> I can use Visual Studio to develop my scripts with all the features of >>> Visual Studio. >>> >>> >>> >>> I can run a debugger and debug the scripts and libraries I am using in >>> the scene. >>> >>> >>> >>> I can do baked lighting including ambient occlusion inside the tool >>> >>> >>> >>> I can do occlusion culling so I can have very large scenes. >>> >>> >>> >>> I can control what assets are loading and stream the rest in the >>> background. >>> >>> >>> >>> I can use libraries of code. >>> >>> >>> >>> From one code base I can be published to many platforms including web and >>> mobile phone. Linux is the big one they are missing a native support for. >>> >>> >>> >>> Should I go on? >>> >>> >>> >>> >>> >>> This is a group that is focused on Second Life client so not trying to >>> convince anyone to switch. But I do think it is fair that people give >>> accurate information based on real experience and not guessing. I think if >>> you understood the tool more you will see your statements are based on >>> inaccurate understanding of the tool. >>> >>> >>> >>> I personally do believe that the game development platforms will outpace >>> anyone doing proprietary client development and as such the days are quickly >>> approaching where you won?t be able to justify the cost of developing your >>> own client rendering engines when you can get the features off the shelf for >>> $1200 that would cost you way more to do yourself. I also believe you won?t >>> stay up and will find yourself quickly falling behind. >>> >>> >>> >>> M. >>> >>> >>> >>> >>> >>> >>> >>> >>> ------------------------------ >>> >>> *From:* Brandon Husbands [mailto:xotmid at gmail.com] >>> *Sent:* Sunday, October 03, 2010 9:57 PM >>> *To:* mysticaldemina at xrgrid.com >>> *Cc:* Robert Exile In Paradise Murphey; >>> opensource-dev at lists.secondlife.com >>> >>> *Subject:* Re: [opensource-dev] Unity 3D as possible base for future >>> (maybe even official) SL Viewers >>> >>> >>> >>> Actually its not inaccurate. The tools themselves are clunky.. And i am >>> not taking this as a lsl vs their language. I am talking about the engine >>> itself. From a lower level perspective. Unity is really more of a >>> middleware when it comes to graphics engines. sure you can use any network >>> you want but in a whole as what it offers as a base is not what would be >>> able to be used for something on the scale of sl. >>> >>> Also as a user you would not have those midddle ware tools that you see >>> unless you want the whole thing to be clunky. >>> >>> Its rigging and control system is designed for rapid prototyping and >>> higher level designig. >>> >>> I would put unity as an equivilant to making a mod for a fps with "good" >>> tools unlike most mod systems. >>> >>> But as a complete engine from a graphics and other standpoints The hero >>> engine blows that away. Actually there are quite a few game engines that >>> surpass unity. And if we take thoes its like compairing writing with QT vs >>> flash. (not quick time... but QT). >>> >>> Flash is great as a packaged thing but its limited. Now unity can me >>> modified and such to some extent but no where whats needed for a SL type of >>> thing. >>> >>> And for the record I am not a fan boi of any engine or system. But i have >>> developed a mmo from the ground up in 2001 to playable alpha 2 on the cusp >>> of beta before the project was shelved due to funding. >>> Having written a majority of the Engine and most of the server code. I >>> would thing these are subjects i am quite capable of assessing. >>> >>> >>> On Sun, Oct 3, 2010 at 7:41 PM, wrote: >>> >>> Alright, this is the most incorrect post I have ever seen so I would >>> guess you have used Unity for maybe a total of an one hour. >>> >>> >>> >>> First of all you can use any network technology you like. It does come >>> with a very basic P2P network, but you can use many game server that you >>> like included some that support fail over and fault tolerance >>> configurations. In fact there are those using SL?s server and rendering >>> prims and sculpties in Unity. >>> >>> >>> >>> The scripting language can also use C# and supports a way more complete >>> set of functions then is available in SL. This list is so long I don?t know >>> where to start on functionality it supports that LSL doesn?t support. >>> >>> >>> >>> Not sure your point about FPS, it has Ambers Occlusion culling, beast >>> lighting and deferred lighting which lets it create FPS you can?t do in SL >>> for the same amount of content. >>> >>> >>> >>> So if you are going to comment on Unity please do your homework and don?t >>> mislead people. >>> >>> >>> >>> M. >>> >>> >>> >>> >>> >>> >>> ------------------------------ >>> >>> *From:* opensource-dev-bounces at lists.secondlife.com [mailto: >>> opensource-dev-bounces at lists.secondlife.com] *On Behalf Of *Brandon >>> Husbands >>> *Sent:* Sunday, October 03, 2010 8:20 PM >>> *To:* Robert Exile In Paradise Murphey >>> *Cc:* opensource-dev at lists.secondlife.com >>> *Subject:* Re: [opensource-dev] Unity 3D as possible base for future >>> (maybe even official) SL Viewers >>> >>> >>> >>> Unity is the biggest POS i have ever used.... >>> Not well designed. IMHO. Its like trying to do SL in javascript. >>> Not literally but you know what i mean. >>> >>> It was never designed for a heavy network transport now multi player / >>> mmo style. >>> >>> A FPS maybe but nothing on a grand scale. >>> >>> On Sun, Oct 3, 2010 at 7:04 PM, Robert "Exile In Paradise" Murphey < >>> exile at weylan-yutani.com> wrote: >>> >>> On Sun, 2010-10-03 at 18:15 -0400, Glen Canaday wrote: >>> > That's why I suggested Ogre instead. I personally think it would be a >>> > better fit and more productive to look at. Others may have different >>> > opinions. >>> >>> Well, I run Linux and agree that being shut out after >>> years of being supported would be suboptimal for me. >>> >>> Running in a VM is an exercise that only a masochist can love >>> compared to an application natively supported. >>> >>> Plus, a VM position forces people to purchase additional OSes >>> just to support one (or a handful) of apps, which add massive >>> overheard in additional administration. At-home-VM is a >>> temporary workaround, not a "platform strategy". >>> Remember - SL is supposed to be Fast, Easy, Fun... not an >>> enterprise-level support nightmare just to boot and run in >>> the first place. >>> >>> Unity3D seems like a lot of "lose" to me: for the same amount >>> of effort to switch to that, re-base on something else that keeps >>> the same supported set of platforms or extends it without dropping >>> already supported platforms. >>> >>> OGRE may be a great suggestion, especially in light of the RealXtend >>> folks having already broken a LOT of the ground of an "SL client >>> that uses OGRE rendering." Why re-reinvent their wheel? >>> Maybe talk to them about Naali and see what goes from there? >>> >>> -- >>> Robert "Exile In Paradise" Murphey >>> Promise her anything, but give her Exxon unleaded. >>> >>> >>> >>> _______________________________________________ >>> Policies and (un)subscribe information available here: >>> http://wiki.secondlife.com/wiki/OpenSource-Dev >>> Please read the policies before posting to keep unmoderated posting >>> privileges >>> >>> >>> >>> >>> -- >>> >>> ------------------------------------------------------------------------------------------------------------------------------- >>> This email is a private and confidential communication. Any use of email >>> may be subject to the laws and regulations of the United States. You may not >>> Repost, Distribute nor reproduce any content of this message. >>> >>> ------------------------------------------------------------------------------------------------------------------------------- >>> >>> ------------------------------------------------------------------------------------------------------------------------------- >>> >>> >>> >>> >>> -- >>> >>> ------------------------------------------------------------------------------------------------------------------------------- >>> This email is a private and confidential communication. Any use of email >>> may be subject to the laws and regulations of the United States. You may not >>> Repost, Distribute nor reproduce any content of this message. >>> >>> ------------------------------------------------------------------------------------------------------------------------------- >>> >>> ------------------------------------------------------------------------------------------------------------------------------- >>> >> >> >> >> -- >> >> ------------------------------------------------------------------------------------------------------------------------------- >> This email is a private and confidential communication. Any use of email >> may be subject to the laws and regulations of the United States. You may not >> Repost, Distribute nor reproduce any content of this message. >> >> ------------------------------------------------------------------------------------------------------------------------------- >> >> ------------------------------------------------------------------------------------------------------------------------------- >> >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/OpenSource-Dev >> Please read the policies before posting to keep unmoderated posting >> privileges >> > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101004/daa63068/attachment-0001.htm From zak.escher at gmail.com Mon Oct 4 07:55:27 2010 From: zak.escher at gmail.com (Zak Escher) Date: Mon, 4 Oct 2010 10:55:27 -0400 Subject: [opensource-dev] New Snowstorm Builds? Message-ID: There hasn't been a new build of Snowstorm (Second Life 2.2.1 (210917) Sep 30 2010 05:11:51 (Second Life Development)) for several days. Any ETA on when new builds will be available? -- ----- Zak Escher email: zak.escher at gmail.com Join me in Second Life http://secondlife.com/ss/?u=f76730f9dee0d54e3cc51e29da87373a -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101004/8e77e1f1/attachment.htm From dz at bitzend.net Mon Oct 4 07:56:26 2010 From: dz at bitzend.net (dz) Date: Mon, 4 Oct 2010 07:56:26 -0700 Subject: [opensource-dev] Uses of the Lookat target Crosshairs In-Reply-To: References: Message-ID: Folks, Thanks for the informed responses. I admit that most of my concern was NOT a function of seeing the cross-hairs, but rather the response I got when I inquired about it. The fact that the avatar was 10 days old, was folded up in a corner not moving, and that he basically told me to "kiss his ass" when I asked him what viewer he was using. I might also be willing to admit it was a "mistake" like Robin suffered, except the crosshairs disappeared shortly after I suggested I would be Abuse Reporting a member of his staff group in a conversation with the club owner. It seems clear that this user is NOT using a "standard" viewer, has control over the targets, and an attitude like "If you come here, we can do whatever we like" (until it looks like you might really know something about whats going on). After three years of SL, and a LOT of online time, these kinds of things raise all kinds of red flags. Robin.... Was "Your viewer" in use before or after the recent TPV changes? Did you intentionally alter the look at target color so that the text did not conform to the standard color codes used everywhere else? Did you sit folded up in a corner 24/7 outside a busy club? For me, the bottom line seems to be that the knowledgeable viewer folks don't see any reason to be concerned over what is most likely just a bug in someone's implementation of LookAt crosshairs. I find it just too weird that I've only seen this happen for 2 avatars, and approaching both of them in a civil manner has resulted in a response typical of a child caught with cookie crumbs on their lips. I also realize none of those issues are relevant to this mailing list... SO Thank you all again for your feedback ( and the work you all do (wink) )... D On Mon, Oct 4, 2010 at 2:14 AM, Robin Cornelius wrote: > On Mon, Oct 4, 2010 at 2:55 AM, Latif Khalifa > wrote: > > You are reading too much into these "targets". Those are just viewer > > effects that help your viewer position head and the direction of eyes > > of the avatar to the desired location. They have no other use. > > > > Yes as Latif says there only purpose is for the head turn/look at > animation so that your avatar will turn its head towards the chat > source for a nice i'm listening to you effect. The LL viewer uses a > small back off so that in busy areas you are not flipping your head > everywhere and i would guess the LL viewer correctly clears the look > at effect after a short time. > > Some viewers (i believed introduced by Emerald) seem to make a big > deal out of the look at crosshairs, then if another viewer comes along > that does not correctly clear the lookat effect you get rude IMs > asking why your crosshairs are on me. I've had this before with one of > my viewers, it was not clearing the look at, so in a busy area i > quickly ended up with crosshairs on everyone who had spoken then > started getting rude IMs from emerald users who had the look at cross > hairs turned on and could see where they were pointed. > > Robin > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101004/c73df733/attachment.htm From mrfrans at gmail.com Mon Oct 4 09:28:07 2010 From: mrfrans at gmail.com (Frans) Date: Mon, 4 Oct 2010 18:28:07 +0200 Subject: [opensource-dev] Unity 3D as possible base for future (maybe even official) SL Viewers In-Reply-To: References: <4CA8957D.3040402@lindenlab.com> <4CA8B04B.4090801@comcast.net> <4CA8E6EF.9060703@boroon.dasgupta.ch> <1286142965.3438.12.camel@glen-desktop> <1286144147.3438.18.camel@glen-desktop> <1286150688.2719.13.camel@nostromo> <51D72C5392864F128AB05A712BD29339@TWEEDY64> <099C27DF404C4A48A05B1D20510E7CFF@TWEEDY64> Message-ID: Teravus++ On Mon, Oct 4, 2010 at 2:32 PM, Teravus Ovares wrote: > When working on IdealistViewer, I noticed that, generally, third party > 'general purpose' renderers like Irrlicht and Ogre are not well suited for > rendering objects at the quantity that SecondLife prims require. Rendering > prims /can/ be done with them, however, not at the level that can be done > with the SecondLife viewer. > > With Irrlicht, for example, the memory load of a typical 5000 prim scene > runs up against the 2GB memory limit. > > With SecondLife prims, it's more about segmenting the render data so that > only the unique things are kept and everything else is a reference to > something that was calculated before. Out of the box, Irrlicht requires > per-instance knowledge about texture, mesh buffer, face and lighting > settings configurations. This and reference/const/value type semantics > used in the engine causes far more data duplications then are necessary. > > Prims are strange for rendering. The prim's mesh result is complex in > terms of vertex count however, in a given 5000 prim scene there's on average > 130 'unique' prim mesh. Those 130 unique mesh are duplicated with various > textures, colors, orientations and associated data to make for the entire > prim count in the region. In theory, you can manage memory reasonably well > by using a 'mesh factory' pattern where by the mesh factory keeps track of > instance counts and generates a new mesh when required. In practice, > however, the associated data makes this very difficult. In Irrlicht, the > API is such that the texture configuration data is 'stuck in with' the mesh > data object. So, to get the variability that the secondlife prim scene > requires, you're also duplicating the mesh and making small changes to the > object's visual configuration data. > > Irrlicht, like Ogre, is better optimized for a smaller number of more > complex mesh objects then a very large number of highly 'instancable' > objects with very small differences. I'd comment on the opposite of the > last statement... but I don't really know about how the SecondLife viewer > works under the hood to do so (OpenSimulator Developer). > > I don't think that this issue is going to 'go away'. In fact, introducing > mesh in the viewer is going to make that memory, speed, and instancing > balance even more difficult to maintain. The gap between the viewer and > 3rd party 'general purpose' rendering tools will narrow in both directions.. > the viewer will get better at managing arbitrary mesh and 3rd party 'general > purpose' rendering tools will be able to render secondlife scenes better > because there will be less 'prim' to render as a result of there being > arbitrary mesh. > > In either case, the future is full of interesting technical challenges. > I think in unity, like with Irrlicht, smaller, more specialized scenes will > work OK with regards to prim rendering. And, I don't think 3rd party > renderers are going to be able to come close to the capability of the > SecondLife viewer when dealing with prim. They're just not designed for the > same type of data. The object models and API just are not really > appropriate for prim. I'm not saying that it isn't worth pursuing a render > plugin architecture. I am saying, however, that given that 3rd party > 'general purpose' renderers are never going to be able to meet the > SecondLife viewer's capability in rendering prim, it probably shouldn't be > very high on the priority of things to do. > > Regards > > Teravus -- Jeroen Frans Virtual World Technology Specialist @ http://VesuviusGroup.com Second Life: Frans Charming blog about SL @ http://secondslog.blogspot.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101004/1f1ae409/attachment.htm From gcanaday at gmail.com Mon Oct 4 09:37:35 2010 From: gcanaday at gmail.com (Glen Canaday) Date: Mon, 04 Oct 2010 12:37:35 -0400 Subject: [opensource-dev] Unity 3D as possible base for future (maybe even official) SL Viewers In-Reply-To: References: <4CA8957D.3040402@lindenlab.com> <4CA8B04B.4090801@comcast.net> <4CA8E6EF.9060703@boroon.dasgupta.ch> <1286142965.3438.12.camel@glen-desktop> <1286144147.3438.18.camel@glen-desktop> <1286150688.2719.13.camel@nostromo> <51D72C5392864F128AB05A712BD29339@TWEEDY64> <099C27DF404C4A48A05B1D20510E7CFF@TWEEDY64> Message-ID: <1286210255.2052.8.camel@glen-desktop> I agree with Neil -> very nice post. But I do think that this really hasn't been tested well enough to declare that all scene-graphers and 3rd-party renderers won't perform well on SL data, though. For me, that's up in the air and is something that should be tested before it's tossed out. That would go for Unity, Irrlicht, Ogre, OSG, and others. Some will likely suck, some possibly won't, but we'll never know until they're tried. I wont say "zOmg don't use Unity because it doesn't support Linux!" but I will say that anything that might work, and would be workable as an alpha-test-tangent-etc for a possible *official* 3.0, can't be something that doesn't support all 3 major platforms natively. That was my original beef with the idea of trying Unity out - can't suggest it as a candidate for official use. Anything that doesn't support them all should be relegated to TPV. --GC On Mon, 2010-10-04 at 08:32 -0400, Teravus Ovares wrote: > When working on IdealistViewer, I noticed that, generally, third party > 'general purpose' renderers like Irrlicht and Ogre are not well suited > for rendering objects at the quantity that SecondLife prims require. > Rendering prims /can/ be done with them, however, not at the level > that can be done with the SecondLife viewer. > > With Irrlicht, for example, the memory load of a typical 5000 prim > scene runs up against the 2GB memory limit. > > With SecondLife prims, it's more about segmenting the render data so > that only the unique things are kept and everything else is a > reference to something that was calculated before. Out of the box, > Irrlicht requires per-instance knowledge about texture, mesh buffer, > face and lighting settings configurations. This and > reference/const/value type semantics used in the engine causes far > more data duplications then are necessary. > > Prims are strange for rendering. The prim's mesh result is complex in > terms of vertex count however, in a given 5000 prim scene there's on > average 130 'unique' prim mesh. Those 130 unique mesh are duplicated > with various textures, colors, orientations and associated data to > make for the entire prim count in the region. In theory, you can > manage memory reasonably well by using a 'mesh factory' pattern where > by the mesh factory keeps track of instance counts and generates a new > mesh when required. In practice, however, the associated data makes > this very difficult. In Irrlicht, the API is such that the texture > configuration data is 'stuck in with' the mesh data object. So, to > get the variability that the secondlife prim scene requires, you're > also duplicating the mesh and making small changes to the object's > visual configuration data. > > Irrlicht, like Ogre, is better optimized for a smaller number of more > complex mesh objects then a very large number of highly 'instancable' > objects with very small differences. I'd comment on the opposite of > the last statement... but I don't really know about how the > SecondLife viewer works under the hood to do so (OpenSimulator > Developer). > > I don't think that this issue is going to 'go away'. In fact, > introducing mesh in the viewer is going to make that memory, speed, > and instancing balance even more difficult to maintain. The gap > between the viewer and 3rd party 'general purpose' rendering tools > will narrow in both directions.. the viewer will get better at > managing arbitrary mesh and 3rd party 'general purpose' rendering > tools will be able to render secondlife scenes better because there > will be less 'prim' to render as a result of there being arbitrary > mesh. > > In either case, the future is full of interesting technical > challenges. I think in unity, like with Irrlicht, smaller, more > specialized scenes will work OK with regards to prim rendering. And, > I don't think 3rd party renderers are going to be able to come close > to the capability of the SecondLife viewer when dealing with prim. > They're just not designed for the same type of data. The object > models and API just are not really appropriate for prim. I'm not > saying that it isn't worth pursuing a render plugin architecture. I > am saying, however, that given that 3rd party 'general purpose' > renderers are never going to be able to meet the SecondLife viewer's > capability in rendering prim, it probably shouldn't be very high on > the priority of things to do. > > Regards > > Teravus > > > On Mon, Oct 4, 2010 at 12:36 AM, Brandon Husbands > wrote: > Ive used it, and fount it blehh. I think we are failing to > communicate about our conception of what is possible and what > is used. > > Are you saying that the normal user would have full access to > what you use to develop the "client"? > As its a middle ware really i fail to see how your going to > implement that. > I could be wrong. There are so many propitiatory things that > you'd have to code in and handle rendering for with sl. Also > remember you can not change the server backend. I just do not > see it possible or powerful enough to handle what sl uses and > does. I guess its the same concept between higher level langs > and lower level ones. I could be wrong about this and just be > old school in my thoughts. > > If your so sure that it can do what needs to be done why have > you not already done a prototype. > From what your saying should be easy to get connected and > render the scene. > > I would love to be wrong in that regard but then again i just > don't see how your going to handle such things in a closed > source engine. > > > > > > On Sun, Oct 3, 2010 at 9:36 PM, > wrote: > Obviously these are subjective statements but I think > your statements are based on an incomplete > understanding of the tool and probably limited > experience using it. > > > > Not sure how you can say it is clunky. I have a scene > hierarchy where I can list and see every object in my > seen. It?s like seeing every prim in my region. I can > select any object and view it in the inspector. > > > > Scripts are assigned to objects and not copied and > duplicated into each prim. I can edit a script once > and every object that uses it gets that update. > > > > In the inspector I can see every public value of the > script and change its value without having to actually > edit the script. > > > > I can use assets directly from my disk without having > to upload them when creating. That is much faster > than waiting for SL to do things. > > > > Scripts can access to every bone in the skeleton > system and I can override animations to adjust the > bones to a given scene?s needs, for instance if two > avatars are a different height and I can adjust the > bones to make their hands connect so they can really > walk hand in hand. > > > > I can create keyed animations in Unity or use > animations from other programs. Animates can throw > events which can trigger code to do things. From > scripts you can create and edit the animations and > their key data. You can layer animations, set their > weights. You can sync the length of layers. Cross > fade animations. > > > > You have materials like you do in Maya. > > > > I can create custom shaders. > > > > You can have spot lights, point lights and directional > lights. > > > > You can create your own skyboxes. > > > > You can use water any where, not limited to just one > plane with the water shader. > > > > I can use meshes. Any object in the scene can have a > skeleton. > > > > I can edit meshes and vertices in real-time allowing > me to create parameterized content in real-time. > > > > I can load assets from a URL or through websockets. > > > > I can load textures from a URL or through websockets. > > > > There is a profiler that lets me see in great detail > what the engine is doing. > > > > I can use Visual Studio to develop my scripts with all > the features of Visual Studio. > > > > I can run a debugger and debug the scripts and > libraries I am using in the scene. > > > > I can do baked lighting including ambient occlusion > inside the tool > > > > I can do occlusion culling so I can have very large > scenes. > > > > I can control what assets are loading and stream the > rest in the background. > > > > I can use libraries of code. > > > > From one code base I can be published to many > platforms including web and mobile phone. Linux is > the big one they are missing a native support for. > > > > Should I go on? > > > > > > This is a group that is focused on Second Life client > so not trying to convince anyone to switch. But I do > think it is fair that people give accurate information > based on real experience and not guessing. I think if > you understood the tool more you will see your > statements are based on inaccurate understanding of > the tool. > > > > I personally do believe that the game development > platforms will outpace anyone doing proprietary client > development and as such the days are quickly > approaching where you won?t be able to justify the > cost of developing your own client rendering engines > when you can get the features off the shelf for $1200 > that would cost you way more to do yourself. I also > believe you won?t stay up and will find yourself > quickly falling behind. > > > > M. > > > > > > > > > > > ______________________________________________________ > From: Brandon Husbands [mailto:xotmid at gmail.com] > Sent: Sunday, October 03, 2010 9:57 PM > To: mysticaldemina at xrgrid.com > Cc: Robert Exile In Paradise Murphey; > opensource-dev at lists.secondlife.com > > > > Subject: Re: [opensource-dev] Unity 3D as possible > base for future (maybe even official) SL Viewers > > > > Actually its not inaccurate. The tools themselves are > clunky.. And i am not taking this as a lsl vs their > language. I am talking about the engine itself. From > a lower level perspective. Unity is really more of a > middleware when it comes to graphics engines. sure you > can use any network you want but in a whole as what it > offers as a base is not what would be able to be used > for something on the scale of sl. > > Also as a user you would not have those midddle ware > tools that you see unless you want the whole thing to > be clunky. > > Its rigging and control system is designed for rapid > prototyping and higher level designig. > > I would put unity as an equivilant to making a mod for > a fps with "good" tools unlike most mod systems. > > But as a complete engine from a graphics and other > standpoints The hero engine blows that away. Actually > there are quite a few game engines that surpass unity. > And if we take thoes its like compairing writing with > QT vs flash. (not quick time... but QT). > > Flash is great as a packaged thing but its limited. > Now unity can me modified and such to some extent but > no where whats needed for a SL type of thing. > > And for the record I am not a fan boi of any engine or > system. But i have developed a mmo from the ground up > in 2001 to playable alpha 2 on the cusp of beta before > the project was shelved due to funding. > Having written a majority of the Engine and most of > the server code. I would thing these are subjects i am > quite capable of assessing. > > > > > On Sun, Oct 3, 2010 at 7:41 PM, > wrote: > > Alright, this is the most incorrect post I have ever > seen so I would guess you have used Unity for maybe a > total of an one hour. > > > > First of all you can use any network technology you > like. It does come with a very basic P2P network, but > you can use many game server that you like included > some that support fail over and fault tolerance > configurations. In fact there are those using SL?s > server and rendering prims and sculpties in Unity. > > > > The scripting language can also use C# and supports a > way more complete set of functions then is available > in SL. This list is so long I don?t know where to > start on functionality it supports that LSL doesn?t > support. > > > > Not sure your point about FPS, it has Ambers Occlusion > culling, beast lighting and deferred lighting which > lets it create FPS you can?t do in SL for the same > amount of content. > > > > So if you are going to comment on Unity please do your > homework and don?t mislead people. > > > > M. > > > > > > > > > ______________________________________________________ > From: opensource-dev-bounces at lists.secondlife.com > [mailto:opensource-dev-bounces at lists.secondlife.com] > On Behalf Of Brandon Husbands > Sent: Sunday, October 03, 2010 8:20 PM > To: Robert Exile In Paradise Murphey > Cc: opensource-dev at lists.secondlife.com > Subject: Re: [opensource-dev] Unity 3D as possible > base for future (maybe even official) SL Viewers > > > > > Unity is the biggest POS i have ever used.... > Not well designed. IMHO. Its like trying to do SL in > javascript. > Not literally but you know what i mean. > > It was never designed for a heavy network transport > now multi player / mmo style. > > A FPS maybe but nothing on a grand scale. > > On Sun, Oct 3, 2010 at 7:04 PM, Robert "Exile In > Paradise" Murphey wrote: > > On Sun, 2010-10-03 at 18:15 -0400, Glen Canaday wrote: > > That's why I suggested Ogre instead. I personally > think it would be a > > better fit and more productive to look at. Others > may have different > > opinions. > > > Well, I run Linux and agree that being shut out after > years of being supported would be suboptimal for me. > > Running in a VM is an exercise that only a masochist > can love > compared to an application natively supported. > > Plus, a VM position forces people to purchase > additional OSes > just to support one (or a handful) of apps, which add > massive > overheard in additional administration. At-home-VM is > a > temporary workaround, not a "platform strategy". > Remember - SL is supposed to be Fast, Easy, Fun... not > an > enterprise-level support nightmare just to boot and > run in > the first place. > > Unity3D seems like a lot of "lose" to me: for the same > amount > of effort to switch to that, re-base on something else > that keeps > the same supported set of platforms or extends it > without dropping > already supported platforms. > > OGRE may be a great suggestion, especially in light of > the RealXtend > folks having already broken a LOT of the ground of an > "SL client > that uses OGRE rendering." Why re-reinvent their > wheel? > Maybe talk to them about Naali and see what goes from > there? > > -- > Robert "Exile In Paradise" Murphey > Promise her anything, but give her Exxon unleaded. > > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep > unmoderated posting privileges > > > > > > -- > ------------------------------------------------------------------------------------------------------------------------------- > This email is a private and confidential > communication. Any use of email may be subject to the > laws and regulations of the United States. You may not > Repost, Distribute nor reproduce any content of this > message. > ------------------------------------------------------------------------------------------------------------------------------- > ------------------------------------------------------------------------------------------------------------------------------- > > > > > > -- > ------------------------------------------------------------------------------------------------------------------------------- > This email is a private and confidential > communication. Any use of email may be subject to the > laws and regulations of the United States. You may not > Repost, Distribute nor reproduce any content of this > message. > ------------------------------------------------------------------------------------------------------------------------------- > ------------------------------------------------------------------------------------------------------------------------------- > > > > > > -- > ------------------------------------------------------------------------------------------------------------------------------- > This email is a private and confidential communication. Any > use of email may be subject to the laws and regulations of the > United States. You may not Repost, Distribute nor reproduce > any content of this message. > ------------------------------------------------------------------------------------------------------------------------------- > ------------------------------------------------------------------------------------------------------------------------------- > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated > posting privileges > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting privileges From blackhat at blackhatdesign.com Mon Oct 4 09:43:56 2010 From: blackhat at blackhatdesign.com (Black Hat Design) Date: Mon, 4 Oct 2010 11:43:56 -0500 Subject: [opensource-dev] Uses of the Lookat target Crosshairs In-Reply-To: References: Message-ID: I am going to have to agree that too much is read into "look at targets" but I will also have to disagree that this tool serves only rudimentary uses. Tools of this nature have been in use for ages before TPVs came on the scene. I remember using them when I was an administrator in the Dreamland sandbox ages ago. It was a very useful tool for keeping an eye on people that were known to make weapons that would take out two or three sims back in the day. It is also a really useful tool for building and it was especially so back before the viewer allowed access to the advanced features that are now commonplace. Unless you used an addon back then, you could not disable camera restraints or limit select distance which made building large structures a real pain. Max Case used to make a scripted tool called "Builders Eye" which was a useful tool to get past this barrier. I remember it well as he was kind enough to customize it a bit for me once I contacted him about adding a feature. This sort of tool is still commonly used in clubs to follow avatars through crowds.. useful if there are giveaways and the club owner or DJ needs to pass a a prize in a lag infested area without pulling up search, typing in an avies name, pulling up a profile and then dropping the object on them. You can see an example of such a tool here https://marketplace.secondlife.com/p/Club-Tool-Dance-HUD-Emote-HUD-DJ-HUD-Host-HUD/1377702 And again, it is also very useful for building or pointing out specific objects to another avatar. A very popular tool used by educators is Cam Sync which allows both avatars to wear a HUD so that a students viewpoint becomes the same as the instructors. It can be useful for a variety of things other than building such as pointing out a specific object in a store as well. You can find that item here https://www.xstreetsl.com/modules.php?name=Marketplace&file=item&ItemID=1020372 If the trend continues that such tools serve no function other than pure evil then the viewer will cease to have any useful functionality at all. After all what harm is there in someone looking at your avatar? Will we soon raise notions of evildoings because you can make your avatar entirely invisible thanks to code that arose from Viewer 2 or could that actually be useful? Would all avatars going alpha during interviews or other events cut down on lag or would we just assume that evil intentions are behind it all and eject avatars that are making use of the viewers functionality? All tools that are useful can also do harm. You can use a telephone to call a doctor or the fire department but you can also use it to harass and threaten someone. There sure are a lot of telephones out there in spite of all the evil potential that they harbor. Dirk Talamasca -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101004/29c70218/attachment.htm From dahliatrimble at gmail.com Mon Oct 4 10:36:48 2010 From: dahliatrimble at gmail.com (Dahlia Trimble) Date: Mon, 4 Oct 2010 10:36:48 -0700 Subject: [opensource-dev] Unity 3D as possible base for future (maybe even official) SL Viewers In-Reply-To: References: <4CA8957D.3040402@lindenlab.com> <4CA8B04B.4090801@comcast.net> <4CA8E6EF.9060703@boroon.dasgupta.ch> <1286142965.3438.12.camel@glen-desktop> <1286144147.3438.18.camel@glen-desktop> <1286150688.2719.13.camel@nostromo> <51D72C5392864F128AB05A712BD29339@TWEEDY64> <099C27DF404C4A48A05B1D20510E7CFF@TWEEDY64> Message-ID: There are a few improvements that could be made in Idealist to help with more complex scenes that the SL viewer appears to implement. Idealist always uses full resolution textures for all prim surfaces, and is incapabile of downloading lower resolution textures from the server and decoding them. This means that even if a prim surface only occupies a few pixles on the screen, that the entire texture would be loaded into memory even if it was a high resolution texture, such as 1024x1024. As far as I'm aware the SL viewer only loads the necessary resolution into memory that is needed for display in the displayed screen area. Using many large textures has the potential to dramatically lower frame rates since any textures that dont fit into graphics memory must be moved there for every frame that they are in camera view. Similar techniques exist for mesh complexity. The SL viewer appears to reduce prim complexity as a function of displayed area, and Idealist does not. Hence more vertex data is in memory and must exist in graphics memory for every frame rendered. SL uses a "Interest List" to manage which items are displayable at any given time, and OpenSimulator did not have any such feature at the time Idealist was being actively developed. Hence, all objects in the scene (or multiple scenes) are elegible for display and further compound memory requirements. Idealist probably could implement many of these features, however the current architecture puts a premium on mesh generation, or rather on the loading of mesh data into the irrlicht layer. This is due to existing overhead in the movement of data from managed space (C#) into unmanaged space (Irrlicht/c++). There may be opportunity for optimization here, I've heard rumors that Unity has added managed functions to Mono that allow for a more direct flow of content-related data into unmanaged space. One feature patch that was submitted to Idealist does scene object culling as a function of camera distance. This did appear to improve performance, unfortunately there are a few bugs that pop up when moving closer to enable viewing of previously disabled objects, the translations/rotations of some objects are corrupted. This bug has never been resolved. Unity has built in support for many similar features, however, using them is difficult (but not impossible) with complex scenes such as in SL. I have a sneaking suspicion they could all be resolved. ;) I also belive they could be resolved to a significant degree in Idealist, however it may require some redesign of the current scene management and managed/unmanaged interface layer. Most general purpose game engines are designed for more general use. The SL viewer appears to be highly optimized for SL content which is not typical of other applications. I am of the opinion that many game engines can come close to the SL viewer performance for SL content, however there will be situations where they break down (as described above with Idealst) but also likely are situations where certain quirks in the SL viewer are exploited creatively to produce a given unique effect. Conversely, many game engines offer features not available in the SL viewer, such as advanced client side physics and scripting, very flexible animated mesh support, and advanced materials and rendering. There are advantages on either approach chosen. Some game engines require the scene to be "flattened" to achieve good performance, or organized in a way where scene objects can be combined into single entities rather than large groups of individual objects (addressable prims). This is due to the architecture of the scene management and how quickly it can manage heirachies of objects for display during each frame. Such engines may require even more extensive workarounds to achieve useful performance with existing SL/OpenSimulater scenes. -Dahlia On Mon, Oct 4, 2010 at 5:32 AM, Teravus Ovares wrote: > When working on IdealistViewer, I noticed that, generally, third party > 'general purpose' renderers like Irrlicht and Ogre are not well suited for > rendering objects at the quantity that SecondLife prims require. Rendering > prims /can/ be done with them, however, not at the level that can be done > with the SecondLife viewer. > > With Irrlicht, for example, the memory load of a typical 5000 prim scene > runs up against the 2GB memory limit. > > With SecondLife prims, it's more about segmenting the render data so that > only the unique things are kept and everything else is a reference to > something that was calculated before. Out of the box, Irrlicht requires > per-instance knowledge about texture, mesh buffer, face and lighting > settings configurations. This and reference/const/value type semantics > used in the engine causes far more data duplications then are necessary. > > Prims are strange for rendering. The prim's mesh result is complex in > terms of vertex count however, in a given 5000 prim scene there's on average > 130 'unique' prim mesh. Those 130 unique mesh are duplicated with various > textures, colors, orientations and associated data to make for the entire > prim count in the region. In theory, you can manage memory reasonably well > by using a 'mesh factory' pattern where by the mesh factory keeps track of > instance counts and generates a new mesh when required. In practice, > however, the associated data makes this very difficult. In Irrlicht, the > API is such that the texture configuration data is 'stuck in with' the mesh > data object. So, to get the variability that the secondlife prim scene > requires, you're also duplicating the mesh and making small changes to the > object's visual configuration data. > > Irrlicht, like Ogre, is better optimized for a smaller number of more > complex mesh objects then a very large number of highly 'instancable' > objects with very small differences. I'd comment on the opposite of the > last statement... but I don't really know about how the SecondLife viewer > works under the hood to do so (OpenSimulator Developer). > > I don't think that this issue is going to 'go away'. In fact, introducing > mesh in the viewer is going to make that memory, speed, and instancing > balance even more difficult to maintain. The gap between the viewer and > 3rd party 'general purpose' rendering tools will narrow in both directions.. > the viewer will get better at managing arbitrary mesh and 3rd party 'general > purpose' rendering tools will be able to render secondlife scenes better > because there will be less 'prim' to render as a result of there being > arbitrary mesh. > > In either case, the future is full of interesting technical challenges. > I think in unity, like with Irrlicht, smaller, more specialized scenes will > work OK with regards to prim rendering. And, I don't think 3rd party > renderers are going to be able to come close to the capability of the > SecondLife viewer when dealing with prim. They're just not designed for the > same type of data. The object models and API just are not really > appropriate for prim. I'm not saying that it isn't worth pursuing a render > plugin architecture. I am saying, however, that given that 3rd party > 'general purpose' renderers are never going to be able to meet the > SecondLife viewer's capability in rendering prim, it probably shouldn't be > very high on the priority of things to do. > > Regards > > Teravus > > > > On Mon, Oct 4, 2010 at 12:36 AM, Brandon Husbands wrote: > >> Ive used it, and fount it blehh. I think we are failing to communicate >> about our conception of what is possible and what is used. >> >> Are you saying that the normal user would have full access to what you use >> to develop the "client"? >> As its a middle ware really i fail to see how your going to implement >> that. >> I could be wrong. There are so many propitiatory things that you'd have to >> code in and handle rendering for with sl. Also remember you can not change >> the server backend. I just do not see it possible or powerful enough to >> handle what sl uses and does. I guess its the same concept between higher >> level langs and lower level ones. I could be wrong about this and just be >> old school in my thoughts. >> >> If your so sure that it can do what needs to be done why have you not >> already done a prototype. >> From what your saying should be easy to get connected and render the >> scene. >> >> I would love to be wrong in that regard but then again i just don't see >> how your going to handle such things in a closed source engine. >> >> >> >> >> On Sun, Oct 3, 2010 at 9:36 PM, wrote: >> >>> Obviously these are subjective statements but I think your statements >>> are based on an incomplete understanding of the tool and probably limited >>> experience using it. >>> >>> >>> >>> Not sure how you can say it is clunky. I have a scene hierarchy where I >>> can list and see every object in my seen. It?s like seeing every prim in my >>> region. I can select any object and view it in the inspector. >>> >>> >>> >>> Scripts are assigned to objects and not copied and duplicated into each >>> prim. I can edit a script once and every object that uses it gets that >>> update. >>> >>> >>> >>> In the inspector I can see every public value of the script and change >>> its value without having to actually edit the script. >>> >>> >>> >>> I can use assets directly from my disk without having to upload them when >>> creating. That is much faster than waiting for SL to do things. >>> >>> >>> >>> Scripts can access to every bone in the skeleton system and I can >>> override animations to adjust the bones to a given scene?s needs, for >>> instance if two avatars are a different height and I can adjust the bones to >>> make their hands connect so they can really walk hand in hand. >>> >>> >>> >>> I can create keyed animations in Unity or use animations from other >>> programs. Animates can throw events which can trigger code to do things. >>> From scripts you can create and edit the animations and their key data. >>> You can layer animations, set their weights. You can sync the length of >>> layers. Cross fade animations. >>> >>> >>> >>> You have materials like you do in Maya. >>> >>> >>> >>> I can create custom shaders. >>> >>> >>> >>> You can have spot lights, point lights and directional lights. >>> >>> >>> >>> You can create your own skyboxes. >>> >>> >>> >>> You can use water any where, not limited to just one plane with the water >>> shader. >>> >>> >>> >>> I can use meshes. Any object in the scene can have a skeleton. >>> >>> >>> >>> I can edit meshes and vertices in real-time allowing me to create >>> parameterized content in real-time. >>> >>> >>> >>> I can load assets from a URL or through websockets. >>> >>> >>> >>> I can load textures from a URL or through websockets. >>> >>> >>> >>> There is a profiler that lets me see in great detail what the engine is >>> doing. >>> >>> >>> >>> I can use Visual Studio to develop my scripts with all the features of >>> Visual Studio. >>> >>> >>> >>> I can run a debugger and debug the scripts and libraries I am using in >>> the scene. >>> >>> >>> >>> I can do baked lighting including ambient occlusion inside the tool >>> >>> >>> >>> I can do occlusion culling so I can have very large scenes. >>> >>> >>> >>> I can control what assets are loading and stream the rest in the >>> background. >>> >>> >>> >>> I can use libraries of code. >>> >>> >>> >>> From one code base I can be published to many platforms including web and >>> mobile phone. Linux is the big one they are missing a native support for. >>> >>> >>> >>> Should I go on? >>> >>> >>> >>> >>> >>> This is a group that is focused on Second Life client so not trying to >>> convince anyone to switch. But I do think it is fair that people give >>> accurate information based on real experience and not guessing. I think if >>> you understood the tool more you will see your statements are based on >>> inaccurate understanding of the tool. >>> >>> >>> >>> I personally do believe that the game development platforms will outpace >>> anyone doing proprietary client development and as such the days are quickly >>> approaching where you won?t be able to justify the cost of developing your >>> own client rendering engines when you can get the features off the shelf for >>> $1200 that would cost you way more to do yourself. I also believe you won?t >>> stay up and will find yourself quickly falling behind. >>> >>> >>> >>> M. >>> >>> >>> >>> >>> >>> >>> >>> >>> ------------------------------ >>> >>> *From:* Brandon Husbands [mailto:xotmid at gmail.com] >>> *Sent:* Sunday, October 03, 2010 9:57 PM >>> *To:* mysticaldemina at xrgrid.com >>> *Cc:* Robert Exile In Paradise Murphey; >>> opensource-dev at lists.secondlife.com >>> >>> *Subject:* Re: [opensource-dev] Unity 3D as possible base for future >>> (maybe even official) SL Viewers >>> >>> >>> >>> Actually its not inaccurate. The tools themselves are clunky.. And i am >>> not taking this as a lsl vs their language. I am talking about the engine >>> itself. From a lower level perspective. Unity is really more of a >>> middleware when it comes to graphics engines. sure you can use any network >>> you want but in a whole as what it offers as a base is not what would be >>> able to be used for something on the scale of sl. >>> >>> Also as a user you would not have those midddle ware tools that you see >>> unless you want the whole thing to be clunky. >>> >>> Its rigging and control system is designed for rapid prototyping and >>> higher level designig. >>> >>> I would put unity as an equivilant to making a mod for a fps with "good" >>> tools unlike most mod systems. >>> >>> But as a complete engine from a graphics and other standpoints The hero >>> engine blows that away. Actually there are quite a few game engines that >>> surpass unity. And if we take thoes its like compairing writing with QT vs >>> flash. (not quick time... but QT). >>> >>> Flash is great as a packaged thing but its limited. Now unity can me >>> modified and such to some extent but no where whats needed for a SL type of >>> thing. >>> >>> And for the record I am not a fan boi of any engine or system. But i have >>> developed a mmo from the ground up in 2001 to playable alpha 2 on the cusp >>> of beta before the project was shelved due to funding. >>> Having written a majority of the Engine and most of the server code. I >>> would thing these are subjects i am quite capable of assessing. >>> >>> >>> On Sun, Oct 3, 2010 at 7:41 PM, wrote: >>> >>> Alright, this is the most incorrect post I have ever seen so I would >>> guess you have used Unity for maybe a total of an one hour. >>> >>> >>> >>> First of all you can use any network technology you like. It does come >>> with a very basic P2P network, but you can use many game server that you >>> like included some that support fail over and fault tolerance >>> configurations. In fact there are those using SL?s server and rendering >>> prims and sculpties in Unity. >>> >>> >>> >>> The scripting language can also use C# and supports a way more complete >>> set of functions then is available in SL. This list is so long I don?t know >>> where to start on functionality it supports that LSL doesn?t support. >>> >>> >>> >>> Not sure your point about FPS, it has Ambers Occlusion culling, beast >>> lighting and deferred lighting which lets it create FPS you can?t do in SL >>> for the same amount of content. >>> >>> >>> >>> So if you are going to comment on Unity please do your homework and don?t >>> mislead people. >>> >>> >>> >>> M. >>> >>> >>> >>> >>> >>> >>> ------------------------------ >>> >>> *From:* opensource-dev-bounces at lists.secondlife.com [mailto: >>> opensource-dev-bounces at lists.secondlife.com] *On Behalf Of *Brandon >>> Husbands >>> *Sent:* Sunday, October 03, 2010 8:20 PM >>> *To:* Robert Exile In Paradise Murphey >>> *Cc:* opensource-dev at lists.secondlife.com >>> *Subject:* Re: [opensource-dev] Unity 3D as possible base for future >>> (maybe even official) SL Viewers >>> >>> >>> >>> Unity is the biggest POS i have ever used.... >>> Not well designed. IMHO. Its like trying to do SL in javascript. >>> Not literally but you know what i mean. >>> >>> It was never designed for a heavy network transport now multi player / >>> mmo style. >>> >>> A FPS maybe but nothing on a grand scale. >>> >>> On Sun, Oct 3, 2010 at 7:04 PM, Robert "Exile In Paradise" Murphey < >>> exile at weylan-yutani.com> wrote: >>> >>> On Sun, 2010-10-03 at 18:15 -0400, Glen Canaday wrote: >>> > That's why I suggested Ogre instead. I personally think it would be a >>> > better fit and more productive to look at. Others may have different >>> > opinions. >>> >>> Well, I run Linux and agree that being shut out after >>> years of being supported would be suboptimal for me. >>> >>> Running in a VM is an exercise that only a masochist can love >>> compared to an application natively supported. >>> >>> Plus, a VM position forces people to purchase additional OSes >>> just to support one (or a handful) of apps, which add massive >>> overheard in additional administration. At-home-VM is a >>> temporary workaround, not a "platform strategy". >>> Remember - SL is supposed to be Fast, Easy, Fun... not an >>> enterprise-level support nightmare just to boot and run in >>> the first place. >>> >>> Unity3D seems like a lot of "lose" to me: for the same amount >>> of effort to switch to that, re-base on something else that keeps >>> the same supported set of platforms or extends it without dropping >>> already supported platforms. >>> >>> OGRE may be a great suggestion, especially in light of the RealXtend >>> folks having already broken a LOT of the ground of an "SL client >>> that uses OGRE rendering." Why re-reinvent their wheel? >>> Maybe talk to them about Naali and see what goes from there? >>> >>> -- >>> Robert "Exile In Paradise" Murphey >>> Promise her anything, but give her Exxon unleaded. >>> >>> >>> >>> _______________________________________________ >>> Policies and (un)subscribe information available here: >>> http://wiki.secondlife.com/wiki/OpenSource-Dev >>> Please read the policies before posting to keep unmoderated posting >>> privileges >>> >>> >>> >>> >>> -- >>> >>> ------------------------------------------------------------------------------------------------------------------------------- >>> This email is a private and confidential communication. Any use of email >>> may be subject to the laws and regulations of the United States. You may not >>> Repost, Distribute nor reproduce any content of this message. >>> >>> ------------------------------------------------------------------------------------------------------------------------------- >>> >>> ------------------------------------------------------------------------------------------------------------------------------- >>> >>> >>> >>> >>> -- >>> >>> ------------------------------------------------------------------------------------------------------------------------------- >>> This email is a private and confidential communication. Any use of email >>> may be subject to the laws and regulations of the United States. You may not >>> Repost, Distribute nor reproduce any content of this message. >>> >>> ------------------------------------------------------------------------------------------------------------------------------- >>> >>> ------------------------------------------------------------------------------------------------------------------------------- >>> >> >> >> >> -- >> >> ------------------------------------------------------------------------------------------------------------------------------- >> This email is a private and confidential communication. Any use of email >> may be subject to the laws and regulations of the United States. You may not >> Repost, Distribute nor reproduce any content of this message. >> >> ------------------------------------------------------------------------------------------------------------------------------- >> >> ------------------------------------------------------------------------------------------------------------------------------- >> >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/OpenSource-Dev >> Please read the policies before posting to keep unmoderated posting >> privileges >> > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101004/40968685/attachment-0001.htm From makosoft at gmail.com Mon Oct 4 13:05:01 2010 From: makosoft at gmail.com (Aidan Thornton) Date: Mon, 4 Oct 2010 21:05:01 +0100 Subject: [opensource-dev] 2.0 Absolute Dealbreaker - script count feature request In-Reply-To: References: <742565.2526.qm@web82101.mail.mud.yahoo.com> Message-ID: On Sun, Oct 3, 2010 at 2:47 AM, Kelly Linden wrote: > Unfortunately no. LSL scripts take up 16k of memory no matter how much they > actually use. Is there any technical reason why this can't be made adjustable, though? I know that changing the amount of script memory available for LSL scripts would require a recompile, since it's fixed at compilation time, but I suspect it could be done. From javajoint at gmail.com Mon Oct 4 13:15:25 2010 From: javajoint at gmail.com (Daniel Smith) Date: Mon, 4 Oct 2010 13:15:25 -0700 Subject: [opensource-dev] Unity 3D as possible base / 2.x Codebase plugin capable? Message-ID: Am happy to see some input on the idea of Unity. It makes me smile. My intent, of course, was to jolt a bit out of idea of a monolithic 2.x codebase. A lot of folks want the viewer to do quite a bit (mesh editor, anyone?). Fulfilling the wishlist without going to a plugin strategy will result in a bloated client that will run on fewer and fewer machines. So if Unity is relegated to a cool TPV project somewhere, that's fine ;) Proposing something radical like that will hopefully get people to think more about what it would take to do a very plugin oriented client (can the 2.x codebase do it? or does it call for a reset of sorts?) Where do people want to see an SL client, 2 years from now? I dont think much of possible approaches that dont handle the physics / animation / terrain / sound angles. It's just asking to reinvent too many wheels. Oh, and as for the objection to Unity outputting to game consoles: snap out of it. The mere existence of code on a console doesn't make it a game. The overall idea is to make SL / OS ubiquitous (Linux client doesnt go away, other approaches open up the Web, phones, and consoles.. all good moves). cheers, Daniel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101004/72be6e94/attachment.htm From mrfrans at gmail.com Mon Oct 4 13:38:57 2010 From: mrfrans at gmail.com (Frans) Date: Mon, 4 Oct 2010 22:38:57 +0200 Subject: [opensource-dev] Unity 3D as possible base / 2.x Codebase plugin capable? In-Reply-To: References: Message-ID: I really hope LL is not going to add a Mesh Editor in the client. That's just going to be so bloated. I agree though, that plugins will be important, and some months(year?) ago it was mentioned that there is a team at LL working on doing just that. Can anyone (at LL) confirm that there is still a team working on making plugins a possibility? -Frans On Mon, Oct 4, 2010 at 10:15 PM, Daniel Smith wrote: > > Am happy to see some input on the idea of Unity. It makes me smile. > > My intent, of course, was to jolt a bit out of idea of a monolithic 2.x > codebase. A lot of folks want the viewer to do quite a bit (mesh editor, > anyone?). Fulfilling the wishlist without going to a plugin strategy will > result in a bloated client that will run on fewer and fewer machines. > > So if Unity is relegated to a cool TPV project somewhere, that's fine ;) > > Proposing something radical like that will hopefully get people to think > more about what it would take to do a very plugin oriented client (can the > 2.x codebase do it? or does it call for a reset of sorts?) Where do people > want to see an SL client, 2 years from now? > > I dont think much of possible approaches that dont handle the physics / > animation / terrain / sound angles. It's just asking to reinvent too many > wheels. Oh, and as for the objection to Unity outputting to game consoles: > snap out of it. The mere existence of code on a console doesn't make it a > game. The overall idea is to make SL / OS ubiquitous (Linux client doesnt > go away, other approaches open up the Web, phones, and consoles.. all good > moves). > > cheers, > > Daniel > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting > privileges > -- Jeroen Frans Virtual World Technology Specialist @ http://VesuviusGroup.com Second Life: Frans Charming blog about SL @ http://secondslog.blogspot.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101004/9f71dfa5/attachment.htm From kelly at lindenlab.com Mon Oct 4 13:40:14 2010 From: kelly at lindenlab.com (Kelly Linden) Date: Mon, 4 Oct 2010 13:40:14 -0700 Subject: [opensource-dev] 2.0 Absolute Dealbreaker - script count feature request In-Reply-To: References: <742565.2526.qm@web82101.mail.mud.yahoo.com> Message-ID: On Mon, Oct 4, 2010 at 1:05 PM, Aidan Thornton wrote: > On Sun, Oct 3, 2010 at 2:47 AM, Kelly Linden wrote: > > Unfortunately no. LSL scripts take up 16k of memory no matter how much > they > > actually use. > > Is there any technical reason why this can't be made adjustable, > though? I know that changing the amount of script memory available for > LSL scripts would require a recompile, since it's fixed at compilation > time, but I suspect it could be done. > LSL is crufty and hacky. It would be a serious engineering and QA effort to implement such a feature. The language is pretty specific and hard coded to 16k. Even if we had a patch ready it would be a lot of QA to be sure it worked as expected. Right now if we are doing anything of this level of work we should be working on implementing a better language and not duct taping LSL. - Kelly -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101004/183367e3/attachment.htm From robertltux at gmail.com Mon Oct 4 13:52:57 2010 From: robertltux at gmail.com (Robert Martin) Date: Mon, 4 Oct 2010 16:52:57 -0400 Subject: [opensource-dev] Fwd: Unity 3D as possible base / 2.x Codebase plugin capable? In-Reply-To: References: Message-ID: ---------- Forwarded message ---------- From: Robert Martin Date: Mon, Oct 4, 2010 at 4:52 PM Subject: Re: [opensource-dev] Unity 3D as possible base / 2.x Codebase plugin capable? To: Frans On Mon, Oct 4, 2010 at 4:38 PM, Frans wrote: > I really hope LL is not going to add a Mesh Editor in the client. That's > just going to be so bloated. > personally i see very little that could be done CORRECTLY in world now i could see maybe some sort of way to send just delta info to the server and or some sort of autoupload/publish on SL plugin being of use but if you stage your 3d utility correctly you should not need to do a reupload or edit after the fact. BTW for those of you that want to to use "Legacy Mesh" clothing with a .DAE avatar you can export the current avatar mesh with a certain flaming TPV that took over certain green stone code. -- Robert L Martin -- Robert L Martin From oz at lindenlab.com Mon Oct 4 14:00:21 2010 From: oz at lindenlab.com (Oz Linden (Scott Lawrence)) Date: Mon, 04 Oct 2010 17:00:21 -0400 Subject: [opensource-dev] New Snowstorm Builds? In-Reply-To: References: Message-ID: <4CAA4065.4030800@lindenlab.com> On 2010-10-04 10:55, Zak Escher wrote: > There hasn't been a new build of Snowstorm (Second Life 2.2.1 (210917) > Sep 30 2010 05:11:51 (Second Life Development)) for several days. Any > ETA on when new builds will be available? There just have not been any new commits since then. People have been focused on beta bugs, mostly. Nice to see that we're developing an expectation of frequent fresh meat, though :-) From gcanaday at gmail.com Mon Oct 4 15:05:29 2010 From: gcanaday at gmail.com (Glen Canaday) Date: Mon, 04 Oct 2010 18:05:29 -0400 Subject: [opensource-dev] Unity 3D as possible base / 2.x Codebase plugin capable? In-Reply-To: References: Message-ID: <1286229929.1932.10.camel@glen-desktop> On Mon, 2010-10-04 at 13:15 -0700, Daniel Smith wrote: > > Am happy to see some input on the idea of Unity. It makes me smile. > > My intent, of course, was to jolt a bit out of idea of a monolithic > 2.x codebase. A lot of folks want the viewer to do quite a bit (mesh > editor, anyone?). Fulfilling the wishlist without going to a plugin > strategy will result in a bloated client that will run on fewer and > fewer machines. > > So if Unity is relegated to a cool TPV project somewhere, that's > fine ;) > Proposing something radical like that will hopefully get people to > think more about what it would take to do a very plugin oriented > client (can the 2.x codebase do it? or does it call for a reset of > sorts?) Where do people want to see an SL client, 2 years from now? > Hey, when it gets all-around support, it can come right back out of TPV and be an option.. > That's where I was going with my own project. Sounds like there are quite a few people thinking in the same direction - I like that. My first run through, should I ever be able to get it off the ground, was to just split up the current code base so that it would be simpler to implement things just like this. If Unity worked better on a given machine, then by all means use it, and the same with Ogre or Irrlicht or the Linden engine or OSG or etc. > I dont think much of possible approaches that dont handle the > physics / animation / terrain / sound angles. It's just asking to > reinvent too many wheels. Oh, and as for the objection to Unity > outputting to game consoles: snap out of it. The mere existence of > code on a console doesn't make it a game. The overall idea is to make > SL / OS ubiquitous (Linux client doesnt go away, other approaches open > up the Web, phones, and consoles.. all good moves). > Oh, don't misunderstand, I've got nothing against putting it on a console. The more platforms, the merrier. I don't know how useful the XBox controller would be in a heavy chat environment, but to each his own, I suppose! --GC From fire at b3dMultitech.com Mon Oct 4 15:06:56 2010 From: fire at b3dMultitech.com (Fire) Date: Mon, 4 Oct 2010 15:06:56 -0700 Subject: [opensource-dev] Unity 3D as possible base / 2.x Codebase plugin capable? In-Reply-To: References: Message-ID: Im in all support for Unity 3d Daniel!!! Very cool! Keep the embers burning! On Mon, Oct 4, 2010 at 1:15 PM, Daniel Smith wrote: > > Am happy to see some input on the idea of Unity. It makes me smile. > > My intent, of course, was to jolt a bit out of idea of a monolithic 2.x > codebase. A lot of folks want the viewer to do quite a bit (mesh editor, > anyone?). Fulfilling the wishlist without going to a plugin strategy will > result in a bloated client that will run on fewer and fewer machines. > > So if Unity is relegated to a cool TPV project somewhere, that's fine ;) > > Proposing something radical like that will hopefully get people to think > more about what it would take to do a very plugin oriented client (can the > 2.x codebase do it? or does it call for a reset of sorts?) Where do people > want to see an SL client, 2 years from now? > > I dont think much of possible approaches that dont handle the physics / > animation / terrain / sound angles. It's just asking to reinvent too many > wheels. Oh, and as for the objection to Unity outputting to game consoles: > snap out of it. The mere existence of code on a console doesn't make it a > game. The overall idea is to make SL / OS ubiquitous (Linux client doesnt > go away, other approaches open up the Web, phones, and consoles.. all good > moves). > > cheers, > > Daniel > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101004/42175ab1/attachment-0001.htm From stickman at gmail.com Mon Oct 4 21:47:48 2010 From: stickman at gmail.com (Stickman) Date: Mon, 4 Oct 2010 21:47:48 -0700 Subject: [opensource-dev] Unity 3D as possible base / 2.x Codebase plugin capable? In-Reply-To: References: Message-ID: On Mon, Oct 4, 2010 at 1:38 PM, Frans wrote: > I really hope LL is not going to add a Mesh Editor in the client. That's > just going to be so bloated. I think it's a terrible idea for LL to try to recreate tools that teams of professionals have already been working on for years. Photoshop, Gimp, Blender, Max, Maya -- there are specialty tools out there, many of them free, that already do a much, much better job than LL ever could, simply because that is their only job and they have years of a head start. What I would like to see is a better connection with existing tools. Being able to have SL work with other programs easier, better conversion and import support, to cut steps out of the design workflow. For example, texture work often involves modifying a texture, test it out, modifying it again, and repeat forever. Having SL "watch" a texture, model, or other file for a change and automatically update it in SL so you can see exactly what it will look like would cut out a lot of steps. Even if it was only a local view. Heck, even if I had to pay for every single time I hit the save button in Photoshop or Blender. Though I'd prefer it be integrated in a way that all people could see what I was working on, then I hit "finalize" and it does the final upload. Having said that, very simple editors that are not designed to have fancy features but be as basic as possible would allow people to create things without going to an outside source. But it must be clear and planned that they will never evolve beyond a basic level. A simple whiteboard-style application for textures, being able to push vertices around on a model or sculpty. Nothing fancy, but enough to create something simple or touch something up without starting up an external program. That's my opinion. I know it's not universal, but it's my view based on my limited experience as a content creator. Stickman From partners at scifipc.com Mon Oct 4 23:21:07 2010 From: partners at scifipc.com (Science Fiction Computer - SCi-Fi PC) Date: Tue, 5 Oct 2010 16:21:07 +1000 Subject: [opensource-dev] Unity 3D as possible base / 2.x Codebase plugin capable? In-Reply-To: References: Message-ID: LL Snowstorm/Opensource-Dev, To stimulate SL growth and accessibility to the mainstream, one or the collective SL Viewer developers and/or decision makers ought to think & design universally. If mesh becomes a standard in SL, a basic mesh editor ought to be included by default. The ability to plugin with existing professional tools such as Photoshop, Gimp, Blender, Max, etc. is essential for high-end content production and advanced SL users. However, to deny a new users who are discovering either 3D Second Life or the 3D Web for the first time a complete basic set of content creation tools for the 3D world they are introduced to (of which would include a mesh editor), may seriously discourage them; along with potential opportunity for regular influx of new & emerging content creators within our community from Low, Medium, and High End. SL Viewer Mesh Editor doesn't need to be Maya, it just needs to be 'there' and 'basic' to encourage new content creators to create and feel that they begin to learn and participate without significant barriers. We must try and avoid any situation where a New User in SL feels disadvantaged or unable to create before they start. Regards, DMC Zsigmond-Jurassic Science Fiction. -----Original Message----- From: opensource-dev-bounces at lists.secondlife.com [mailto:opensource-dev-bounces at lists.secondlife.com] On Behalf Of Stickman Sent: Tuesday, October 05, 2010 2:48 PM To: Frans Cc: opensource-dev at lists.secondlife.com Subject: Re: [opensource-dev] Unity 3D as possible base / 2.x Codebase plugin capable? On Mon, Oct 4, 2010 at 1:38 PM, Frans wrote: > I really hope LL is not going to add a Mesh Editor in the client. That's > just going to be so bloated. I think it's a terrible idea for LL to try to recreate tools that teams of professionals have already been working on for years. Photoshop, Gimp, Blender, Max, Maya -- there are specialty tools out there, many of them free, that already do a much, much better job than LL ever could, simply because that is their only job and they have years of a head start. What I would like to see is a better connection with existing tools. Being able to have SL work with other programs easier, better conversion and import support, to cut steps out of the design workflow. For example, texture work often involves modifying a texture, test it out, modifying it again, and repeat forever. Having SL "watch" a texture, model, or other file for a change and automatically update it in SL so you can see exactly what it will look like would cut out a lot of steps. Even if it was only a local view. Heck, even if I had to pay for every single time I hit the save button in Photoshop or Blender. Though I'd prefer it be integrated in a way that all people could see what I was working on, then I hit "finalize" and it does the final upload. Having said that, very simple editors that are not designed to have fancy features but be as basic as possible would allow people to create things without going to an outside source. But it must be clear and planned that they will never evolve beyond a basic level. A simple whiteboard-style application for textures, being able to push vertices around on a model or sculpty. Nothing fancy, but enough to create something simple or touch something up without starting up an external program. That's my opinion. I know it's not universal, but it's my view based on my limited experience as a content creator. Stickman _______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges From Celierra at gmail.com Tue Oct 5 00:08:54 2010 From: Celierra at gmail.com (Celierra Darling) Date: Tue, 5 Oct 2010 03:08:54 -0400 Subject: [opensource-dev] Unity 3D as possible base / 2.x Codebase plugin capable? In-Reply-To: References: Message-ID: I don't see why mesh editing needs to be considered "basic"? I would consider building through prims to be the most basic, to learn how objects/prims/links work and what features are available and what texturing is and the such. New users also have all the free tools and those existing tutorials available to start working with meshes, so new users should hopefully still feel like they have an advancement path. Even if prim objects became totally non-competitive on the market, people probably still start out just experimenting for their own use, so prims should still be a good stepping stone while learning for their quick results and feedback. What would a mesh editor in the viewer add? (Well, one likely feature of an in-world tool would be to enable people to work concurrently with others and see others' changes as they are made, but I doubt you're referring to that aspect.) Ironically, what I would think of as the most basic conceptual transitions going from prims to meshes are probably the most difficult to program. To ease the transition to meshes when the time comes for a new content creator, what I could imagine is the introduction of some tools and concepts from a mesh's content creation process - hierarchical links to allow stacking transformations? a way to palletize the textures applied to an object? - but while still working with prims in-world. Maybe it can even go as far as a full conversion tool if someone were ambitious enough to code such a thing (to convert and tinker). But I wouldn't go as far as controlling subdivisions or twiddling edge normals or nudging vertices -- a list that is in increasing order of usability difficulty, but decreasing order of programming complexity, and thus the irony of a "basic" mesh editor. Celi On Tue, Oct 5, 2010 at 2:21 AM, Science Fiction Computer - SCi-Fi PC < partners at scifipc.com> wrote: > LL Snowstorm/Opensource-Dev, > > To stimulate SL growth and accessibility to the mainstream, one or the > collective SL Viewer developers and/or decision makers ought to think & > design universally. > > If mesh becomes a standard in SL, a basic mesh editor ought to be included > by default. > > The ability to plugin with existing professional tools such as Photoshop, > Gimp, Blender, Max, etc. is essential for high-end content production and > advanced SL users. > > However, to deny a new users who are discovering either 3D Second Life or > the 3D Web for the first time a complete basic set of content creation > tools > for the 3D world they are introduced to (of which would include a mesh > editor), may seriously discourage them; along with potential opportunity > for > regular influx of new & emerging content creators within our community from > Low, Medium, and High End. > > SL Viewer Mesh Editor doesn't need to be Maya, it just needs to be 'there' > and 'basic' to encourage new content creators to create and feel that they > begin to learn and participate without significant barriers. > > We must try and avoid any situation where a New User in SL feels > disadvantaged or unable to create before they start. > > Regards, > > DMC Zsigmond-Jurassic > Science Fiction. > > > > -----Original Message----- > From: opensource-dev-bounces at lists.secondlife.com > [mailto:opensource-dev-bounces at lists.secondlife.com] On Behalf Of Stickman > Sent: Tuesday, October 05, 2010 2:48 PM > To: Frans > Cc: opensource-dev at lists.secondlife.com > Subject: Re: [opensource-dev] Unity 3D as possible base / 2.x Codebase > plugin capable? > > On Mon, Oct 4, 2010 at 1:38 PM, Frans wrote: > > I really hope LL is not going to add a Mesh Editor in the client. That's > > just going to be so bloated. > > I think it's a terrible idea for LL to try to recreate tools that > teams of professionals have already been working on for years. > Photoshop, Gimp, Blender, Max, Maya -- there are specialty tools out > there, many of them free, that already do a much, much better job than > LL ever could, simply because that is their only job and they have > years of a head start. > > What I would like to see is a better connection with existing tools. > Being able to have SL work with other programs easier, better > conversion and import support, to cut steps out of the design > workflow. For example, texture work often involves modifying a > texture, test it out, modifying it again, and repeat forever. Having > SL "watch" a texture, model, or other file for a change and > automatically update it in SL so you can see exactly what it will look > like would cut out a lot of steps. Even if it was only a local view. > Heck, even if I had to pay for every single time I hit the save button > in Photoshop or Blender. Though I'd prefer it be integrated in a way > that all people could see what I was working on, then I hit "finalize" > and it does the final upload. > > Having said that, very simple editors that are not designed to have > fancy features but be as basic as possible would allow people to > create things without going to an outside source. But it must be clear > and planned that they will never evolve beyond a basic level. A simple > whiteboard-style application for textures, being able to push vertices > around on a model or sculpty. Nothing fancy, but enough to create > something simple or touch something up without starting up an external > program. > > That's my opinion. I know it's not universal, but it's my view based > on my limited experience as a content creator. > > Stickman > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting > privileges > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101005/ab2a5e8a/attachment.htm From merov at lindenlab.com Tue Oct 5 00:51:16 2010 From: merov at lindenlab.com (Philippe (Merov) Bossut) Date: Tue, 5 Oct 2010 00:51:16 -0700 Subject: [opensource-dev] WebP, a new image format for the Web In-Reply-To: <4CA61E31.1050601@taterunino.net> References: <4CA61E31.1050601@taterunino.net> Message-ID: Hi, I was puzzled by this "yet another image format" from Google and did some quick research tonight. Not much turned up in the data provided by Google and, as always, the best starting point is Wikipedia: http://en.wikipedia.org/wiki/WebP . Short but to the point. The critical part is the Math: WebP is based on block prediction and encoding, something that works well for compressing frame to frame videos but one has to wonder about still images. Why would blocks be predictable spatially? Similar textures? May be but loss of precision would be horrendous, something that I don't thing the JPEG (a group of Pro Photographers) would swallow. Besides, it reminds me a lot about fractal compression of the mid 90's and we all know how this ended... Then, if prediction fails, WebP falls back to DCT so no better than classical JPEG and the blocking artifacts are as "good" as what JPEG gives us... a problem that, precisely, wavelet compression (used in jpeg2000) solved. It seems to me that, as far as encoding differences from levels to levels, wavelets do that uniformly on the whole image much better already and its mathematical underpinning is much stronger (see St?phane Mallat papers' on Optimal Image Compression). Not to mention that wavelet gives us LOD (Level of Details == discard level == subres access) that we *do* use in SL and random spatial access that, unfortunately, we do not use in SL (though we ought to). Anyway, WebP gives us neither one not the other. As for the 39% better compression touted by Google, I fail to see that as a big selling point, especially when taking the huge compression time they apparently experience into account. You also get much better compression rate with jpeg2000 than with jpeg any day. But, even with good old jpeg, if you take the time to compute adapted quantization tables for each image, you would get much better compression rates. Now, no one does this because it takes too long at compress time (which is typically done on cameras...) so everyone uses the same set of "standard" (read "ought to work for all run of the mill picture taking situations") quantization tables. So, if you were to really compare apple to apple, I'm not even sure that WebP is that much better than standard jpeg. More: 8 bits per channel only? That must be a typo... I won't even go down the "raw" and high dynamic range debate familiar to folks with an interest in photography. Well, I don't see why the method can't be extended to 16 bits though. Then this: comparing "visually" differences between JPEG images pulled from the web and reencoded with WebP to judge quality? No seriously, I almost cried... I thought Google had better standards for quality of engineering. What a disappointment. My take: keep on the radar (because it's Google...) but I don't see the urgency to jettison JPEG2000 for static images yet. Cheers, - Merov On Fri, Oct 1, 2010 at 10:45 AM, Tateru Nino wrote: > Hmm. Only supports a single image data chunk and no alpha channels in this > release. True, you could break compatibility and extend it, but I'm not sure > that's really the way to go. Not close to a drop-in replacement yet, even > after banging it on some rocks. > > > On 2/10/2010 3:15 AM, SuezanneC Baskerville wrote: > > Google is putting out a new open source image format, said to offer higher > compression rates than JPEG2000. > > I just thought someone with the appropriate technical knowledge ought to > take a look at in case it might be useful for use in Second Life. > > http://blog.chromium.org/2010/09/webp-new-image-format-for-web.html > > *To improve on the compression that JPEG provides, we used an image >> compressor based on the VP8 codec that Google open-sourcedin May 2010. We applied the techniques from VP8 video intra frame coding to >> push the envelope in still image coding. We also adapted a very lightweight >> container based on RIFF. >> While this container format contributes a minimal overhead of only 20 bytes >> per image, it is extensible to allow authors to save meta-data they would >> like to store. >> >> While the benefits of a VP8 based image format were clear in theory, we >> needed to test them in the real world. In order to gauge the effectiveness >> of our efforts, we randomly picked about 1,000,000 images from the web >> (mostly JPEGs and some PNGs and GIFs) and re-encoded them to WebP without >> perceptibly compromising visual quality. This resulted in an average 39% >> reduction in file size. We expect that developers will achieve in practice >> even better file size reduction with WebP when starting from an uncompressed >> image. >> * > > > http://code.google.com/speed/webp/ > -- > v i r t u a l w o r l d e n t h u s i a s t > -- http://www.google.com/profiles/s u e z a n n e -- > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting privileges > > > -- > Tateru Ninohttp://dwellonit.taterunino.net/ > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101005/899c20a9/attachment-0001.htm From izzee at hotmail.co.uk Tue Oct 5 01:31:07 2010 From: izzee at hotmail.co.uk (izze euler) Date: Tue, 5 Oct 2010 08:31:07 +0000 Subject: [opensource-dev] Problem with displaying Arabic menu text in SL client Message-ID: Hi, I have been looking to get Arabic text working on the SL client, but so far with no luck. I am only looking to display Arabic for menus and text on the client. What I have found is that the Arabic text is being displayed left-to-right, rather than right-to-left. I have added a language to SL, so I have the Arabic translations in UTF8 format in XML files, as with the other languages such as Chinese. I used Notepad++ to copy the translations to the XML files, and they are displayed right-to-left correctly. However, when loaded into the SL client, the text is being reversed so that it reads left-to-right. I have tried reversing the text, so that it displays left-to-right in the XML file, in the hope that it will then be reversed and display right-to-left in the client. I cannot read or write Arabic, but I have been told that the characters are displayed disjoint, most likely due to the wrong ordering of the characters breaking associations between them in the XML file. Has anyone looked into this problem, or have any ideas to what I could try? Does anyone have this working? Kind Regards, Izze -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101005/a5842705/attachment.htm From sllists at boroon.dasgupta.ch Tue Oct 5 03:19:57 2010 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Tue, 05 Oct 2010 12:19:57 +0200 Subject: [opensource-dev] Problem with displaying Arabic menu text in SL client In-Reply-To: References: Message-ID: <4CAAFBCD.1070904@boroon.dasgupta.ch> Hi Izze On 10/05/2010 10:31 AM, izze euler wrote: > I have been looking to get Arabic text working on the SL client, but > so far with no luck. I am only looking to display Arabic for menus and > text on the client. > > What I have found is that the Arabic text is being displayed > left-to-right, rather than right-to-left. I have added a language to > SL, so I have the Arabic translations in UTF8 format in XML files, as > with the other languages such as Chinese. > > I used Notepad++ to copy the translations to the XML files, and they > are displayed right-to-left correctly. However, when loaded into the > SL client, the text is being reversed so that it reads left-to-right. Unicode has special control characters to switch between left-to-right and right-to-left in mixed language documents. Additionally, I think some programs switch direction automatically when they encounter characters they know belong to a right-to-left written script. So if the translations are displayed correctly, Notepad++ is capable of at least one of those, probably the former (interpreting the control characters). > I have tried reversing the text, so that it displays left-to-right in > the XML file, in the hope that it will then be reversed and display > right-to-left in the client. I cannot read or write Arabic, but I have > been told that the characters are displayed disjoint, most likely due > to the wrong ordering of the characters breaking associations between > them in the XML file. Arabic script relies heavily on ligatures. Ligatures are glyphs that represent multiple characters. Other than the ligatures used for latin script (fl, fi ffi, etc.) which merely make the rendered text look "nicer", ligatures in scripts like Arabic, Devanagari (a script used for Sanskrit, Hindi and other Indian languages), Bengali (another Indian language and script) and probably many others look very distinct from the characters they represent and aren't "optional". (Typographs and typesetters might argue that Latin ligatures aren't optional either. But omitting ligatures in these other scripts will not only look typographically wrong but, well, just wrong. (I don't know whether it'd be considered an orthographic error in the respective cultures.)) > Has anyone looked into this problem, or have any ideas to what I could > try? We've discussed the problem this summer, see here: http://wiki.secondlife.com/wiki/Open_Source_Meeting/2010-07-13 The issue is that while the SL client has support for displaying Unicode characters, it lacks the ability to use Unicode's script direction markers and the feature of converting specific character sequences to the matching ligatures. For pre-set strings (e.g. your UI translation), the first problem can be worked around by writing stuff backwards, as you already tried. To work around the second problem, you'd have to directly write the ligature "characters" (so you have only one character per wanted glyph). I don't know Unicode well enough to tell whether "characters" for all possible glyphs exist. It might well be that some ligatures always have to be created on-the-fly from a sequence of single-character "characters". Of course, both of these workarounds aren't feasible for chat and other run-time user input, because users will be used to write sequences of single characters in reading order rather than ligature "characters" in left-to-right order. Also, entering these ligature "characters" (if they even exist) might be complicated and time consuming, because their usual keyboard layout might not give direct access to them. > Does anyone have this working? Adding these features to Linden Lab's homebrewn text rendering system would be a major effort that probably none of us is capable of. Alissa Sabre once adapted the Viewer to use Pango for text rendering. ( See http://wiki.secondlife.com/wiki/User:Alissa_Sabre/Pango_adaptation_in_SL_viewer) Pango can handle bidirectional text and ligatures just fine, so this solved the problems. However, these changes haven't been integrated in the official viewer and her patches are now out of date. For chat, using Dzonatas' Icesphere (allows for IM and chat in separate GTK+ windows, thus also using Pango) has been recommended to some Arabic users, and that seems to work alright. Both, the sender and receiver, will have to use it to be able to chat in Arabic script. Cheers, Boroondas -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101005/f1832d0f/attachment.htm From sythos at gmail.com Tue Oct 5 03:38:44 2010 From: sythos at gmail.com (Francesco Rabbi) Date: Tue, 5 Oct 2010 12:38:44 +0200 Subject: [opensource-dev] Problem with displaying Arabic menu text in SL client In-Reply-To: <4CAAFBCD.1070904@boroon.dasgupta.ch> References: <4CAAFBCD.1070904@boroon.dasgupta.ch> Message-ID: <-8408346637686232673@unknownmsgid> U+200F Reverse direction Notes: - Microsoft have a bug, this char don't work sometimes (msoffice 2011 for Mac affected too) - parser work left2right put the char on left side of each entry in all XML files -- Sent by iPhone Il giorno 05/ott/2010, alle ore 12:19, Boroondas Gupte < sllists at boroon.dasgupta.ch> ha scritto: Hi Izze On 10/05/2010 10:31 AM, izze euler wrote: I have been looking to get Arabic text working on the SL client, but so far with no luck. I am only looking to display Arabic for menus and text on the client. What I have found is that the Arabic text is being displayed left-to-right, rather than right-to-left. I have added a language to SL, so I have the Arabic translations in UTF8 format in XML files, as with the other languages such as Chinese. I used Notepad++ to copy the translations to the XML files, and they are displayed right-to-left correctly. However, when loaded into the SL client, the text is being reversed so that it reads left-to-right. Unicode has special control characters to switch between left-to-right and right-to-left in mixed language documents. Additionally, I think some programs switch direction automatically when they encounter characters they know belong to a right-to-left written script. So if the translations are displayed correctly, Notepad++ is capable of at least one of those, probably the former (interpreting the control characters). I have tried reversing the text, so that it displays left-to-right in the XML file, in the hope that it will then be reversed and display right-to-left in the client. I cannot read or write Arabic, but I have been told that the characters are displayed disjoint, most likely due to the wrong ordering of the characters breaking associations between them in the XML file. Arabic script relies heavily on ligatures. Ligatures are glyphs that represent multiple characters. Other than the ligatures used for latin script (fl, fi ffi, etc.) which merely make the rendered text look "nicer", ligatures in scripts like Arabic, Devanagari (a script used for Sanskrit, Hindi and other Indian languages), Bengali (another Indian language and script) and probably many others look very distinct from the characters they represent and aren't "optional". (Typographs and typesetters might argue that Latin ligatures aren't optional either. But omitting ligatures in these other scripts will not only look typographically wrong but, well, just wrong. (I don't know whether it'd be considered an orthographic error in the respective cultures.)) Has anyone looked into this problem, or have any ideas to what I could try? We've discussed the problem this summer, see here: http://wiki.secondlife.com/wiki/Open_Source_Meeting/2010-07-13 The issue is that while the SL client has support for displaying Unicode characters, it lacks the ability to use Unicode's script direction markers and the feature of converting specific character sequences to the matching ligatures. For pre-set strings (e.g. your UI translation), the first problem can be worked around by writing stuff backwards, as you already tried. To work around the second problem, you'd have to directly write the ligature "characters" (so you have only one character per wanted glyph). I don't know Unicode well enough to tell whether "characters" for all possible glyphs exist. It might well be that some ligatures always have to be created on-the-fly from a sequence of single-character "characters". Of course, both of these workarounds aren't feasible for chat and other run-time user input, because users will be used to write sequences of single characters in reading order rather than ligature "characters" in left-to-right order. Also, entering these ligature "characters" (if they even exist) might be complicated and time consuming, because their usual keyboard layout might not give direct access to them. Does anyone have this working? Adding these features to Linden Lab's homebrewn text rendering system would be a major effort that probably none of us is capable of. Alissa Sabre once adapted the Viewer to use Pango for text rendering. ( See http://wiki.secondlife.com/wiki/User:Alissa_Sabre/Pango_adaptation_in_SL_viewer) Pango can handle bidirectional text and ligatures just fine, so this solved the problems. However, these changes haven't been integrated in the official viewer and her patches are now out of date. For chat, using Dzonatas' Icesphere (allows for IM and chat in separate GTK+ windows, thus also using Pango) has been recommended to some Arabic users, and that seems to work alright. Both, the sender and receiver, will have to use it to be able to chat in Arabic script. Cheers, Boroondas _______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101005/aa05ecbe/attachment-0001.htm From izzee at hotmail.co.uk Tue Oct 5 04:32:43 2010 From: izzee at hotmail.co.uk (izze euler) Date: Tue, 5 Oct 2010 11:32:43 +0000 Subject: [opensource-dev] Problem with displaying Arabic menu text in SL client In-Reply-To: <-8408346637686232673@unknownmsgid> References: <4CAAFBCD.1070904@boroon.dasgupta.ch>, <-8408346637686232673@unknownmsgid> Message-ID: Are you able to give an example on how to use this character within an XML file? Izze From: sythos at gmail.com Date: Tue, 5 Oct 2010 12:38:44 +0200 Subject: Re: [opensource-dev] Problem with displaying Arabic menu text in SL client To: sllists at boroon.dasgupta.ch CC: izzee at hotmail.co.uk; opensource-dev at lists.secondlife.com U+200F Reverse direction Notes:- Microsoft have a bug, this char don't work sometimes (msoffice 2011 for Mac affected too) - parser work left2right put the char on left side of each entry in all XML files -- Sent by iPhone Il giorno 05/ott/2010, alle ore 12:19, Boroondas Gupte ha scritto: Hi Izze On 10/05/2010 10:31 AM, izze euler wrote: -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101005/8948e66c/attachment.htm From lee.ponzu at gmail.com Tue Oct 5 06:57:15 2010 From: lee.ponzu at gmail.com (Ponzu) Date: Tue, 5 Oct 2010 09:57:15 -0400 Subject: [opensource-dev] Unity 3D as possible base / 2.x Codebase plugin capable? In-Reply-To: References: Message-ID: On Tue, Oct 5, 2010 at 3:08 AM, Celierra Darling wrote: > I don't see why mesh editing needs to be considered "basic"? One philosophical stance is that all types of building whould include an easy path for novices to do that sort of building. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101005/e536cdf4/attachment.htm From esbee at lindenlab.com Tue Oct 5 07:00:19 2010 From: esbee at lindenlab.com (Sarah (Esbee) Hutchinson) Date: Tue, 5 Oct 2010 10:00:19 -0400 Subject: [opensource-dev] Daily Scrum Update - Monday, October 4, 2010 Message-ID: These emails keep getting corrupted on send (likely due to my extraneous formatting). You can also view the daily updates on the wiki, here: https://wiki.secondlife.com/wiki/Snowstorm_Daily_Scrum_Archive But here's a far less fancy update for those who prefer email! :) - Esbee *Daily Scrum Update - Monday, October 4* * * *General Notes* * Merge Monkey of the Day: Merov *Team Status* *====Merov Linden====* *PAST* * STORM-137: fmod on Windows: fixed fmod.dl not been copied over to build-vc80/newview/RelWithDebInfo. Modif in viewer_manifest.py and cmake/CMakeLists.txt. Committed to dev branch. * STORM-306: water flicker issue: identified the issue as being introduced mid-July in the viewer code. * STORM-330 : Crash in texture rendering: got that crash under the debugger on Windows and logged it immediately. * HR stuff *FUTURE* * New round of SG JIRA scrubbing to prepare sprint planning * Merge Monkeying * STORM-137 : FMOD issue: fix upload issue with Brad. Hopefully, the rest will be easy. * STORM-105 : Perf decompression: put new data out, check the work done by opensource-dev community on similar tests. * STORM-281: integrate? * STORM-306: back burner: bissect and incremental builds till I pinpoint the culprit... *IMPEDIMENTS* * Kakadu license upgrade *====Oz Linden====* *PAST* * Caught up on email from my vacation * Answered questions from a couple of people on Contribution Agreements * Office Hour * Put in request for change to the download page for Development builds * Started running third party viewer crash reports *FUTURE* * Clarify wiki documentation on where to get code and download binaries * Get current on autobuild developments * Work on proposals for open code review and build systems * Help with code reviews? *IMPEDIMENTS* * none *====Q Linden====* *PAST* * HR stuff, administration * Planning Q4 * Documenting release process * Crashhunting in beta * Meeting on test automation * Looking into antialiasing *FUTURE* * Answer PE questions on STORM-325 and 295 * HR stuff * Q4 planning * Further meetings on test automation * Writing automation for LLDir *IMPEDIMENTS* * paperwork/planning blocking me from coding *====Esbee Linden====* *PAST* * VWR triage * Process discussions * Bug hunting * Backlog reviews * Set up new meeting times for Sprint Planning, Retrospective, and Review meetings * HR Stuff * Q4 planning *FUTURE* * VWR triage * Backlog grooming & new feature request review * Prep for Sprint 5 * Viewer roadmap planning * Systems requirements research * HR Stuff * Q4 planning *IMPEDIMENTS* * None *====Paul ProductEngine ====* *PAST* * STORM-263 Cog button in lower-left of sidebar panel does not close popup menu on second click ** Fixed, tomorrow will test and send for a review *FUTURE* * other bugs *IMPEDIMENTS* *none *====Andrew ProductEngine====* *PAST* * Bug STORM-264 (Resize grab areas on detached sidebar panels are tiny and unmarked) ** Reviewed. * Bug STORM-325 ("i" button no longer opens profiles). ** Reproduced in viewer-beta, investigated, found changeset with fix in viewer-development and left comment in ticket. * Major bug STORM-295 (Mini-inspector fades out if adjust voice volume). ** Reproduced in viewer-beta, investigated, found changeset with fix in viewer-development and left comment in ticket. * Major bug STORM-315 (Changes to Environment Editor are not saved and do not persist across sessions). ** Started investigating. Estimate- 6 hours. *FUTURE* * STORM-315 (Changes to Environment Editor are not saved and do not persist across sessions). *IMPEDIMENT*S * STORM-295 and STORM-325 are fixed in viewer-development. What should be done with these fixes? Should changesets with them be transplanted from one repository to another, or simply fixed the same way manually, or left untouched to wait merge with development? *====Vadim ProductEngine====* OOO - Vacation. Will be back to office on Oct, 11th. *====Seth ProductEngine (Sergey)====* *PAST* * BUG (STORM-316) Debug: Inventory.Folders by Name/Sort by Date/Sort by Name/System Folders to Top Do not apply and settings changes do not persist after relogging. ** Investigated. Waiting for Esbee's reply in JIRA. * BUG (STORM-314) Wear button in My Appearance greyed out ** Investigated. Could not reproduce with reporter's scenario. Probably misfiled. * BUG (STORM-310) crash after setting sound preferences ** Could not reproduce. * BUG (STORM-305) Undocked minimized SP tabs are restored after re-login ** WIP. *FUTURE* * BUG (STORM-305) Undocked minimized SP tabs are restored after re-login ** Estimated: 4 hours. *IMPEDIMENTS* * STORM-316 needs answer from Esbee (?) *====Andrey ProductEngine====* *PAST* * smoke test of 210917 at viewer-development * integrated tickets verification on 210917 at viewer-development *FUTURE* * regression testing of 210917 at viewer-development in scope of changes from previous development builds *IMPEDIMENTS* * none -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101005/7335ac81/attachment.htm From dmahalko at gmail.com Tue Oct 5 08:19:47 2010 From: dmahalko at gmail.com (Dale Mahalko) Date: Tue, 5 Oct 2010 10:19:47 -0500 Subject: [opensource-dev] Unity 3D as possible base / 2.x Codebase plugin capable? In-Reply-To: References: Message-ID: An in-world prim-to-mesh converter would both be incredibly powerful and yet also easy to use. Heck, it could be practically transparent to the end-user. Make prims, arrange, and link them * Prims are merged automagically into a mesh * Embedded and overlapping internal surfaces are removed * The original prims disappear from world * The mesh is now the stand-in for the prims Unlink the mesh * The mesh disappears and is discarded. * Prims are reloaded back into the world for editing as individual objects This could shed massive amounts of hidden vertexes from linked prim sculptures, prim vehicles, houses, roads, etc, and significantly improve frame-rates, all while being mostly transparent to the end user... perhaps little more than a checkbox option in the editor : "Make linked prims into a mesh?" Though I would hope for a way to separately link together prims to make the physics collision surface for a high-prim object. That way a beautiful vase with curved handles can have a simple cylinder collision surface to go with it, and take load off the physics engine. This could be anti-griefed by making sure that the collision surface always has fewer vertexes than the visible mesh it is joined to. - Dale Mahalko / Scalar Tardis On Tue, Oct 5, 2010 at 2:08 AM, Celierra Darling wrote: > I don't see why mesh editing needs to be considered "basic"? ?I would > consider building through prims to be the most basic, to learn how > objects/prims/links work and what features are available and what texturing > is and the such. From danielravennest at gmail.com Tue Oct 5 08:25:36 2010 From: danielravennest at gmail.com (Daniel) Date: Tue, 05 Oct 2010 10:25:36 -0500 Subject: [opensource-dev] Vertex Edit Capability In-Reply-To: References: Message-ID: <4CAB4370.2060702@gmail.com> I submitted JIRA issue VWR-23202 to provide the simplest in-world editing capability, that of moving vertexes on a mesh. The reasons why include making a clothing item fit better, a large mesh object fit within a land parcel, or fit the other objects in a linkset. As someone learning to build it would also be more fun and interesting to edit shapes. Even for an advanced builder, while we can load the parts of a complex build into our 3D program and get them to fit each other, we cannot load all possible avatar shapes, or the surrounding land for large items, and see how the mesh will fit the surroundings until it is there. I am not proposing a full blown mesh editor, that is best left to specialized software. What I want to see is a way to adjust items so they are more useful once imported/transferred to others, and a learning path for new people. Once they have a taste of modifying a simple library mesh, if they want to do more advanced work they can get some outside software. This is similar in my mind to what we do with textures. We can adjust the color tint, tiling ratio, etc on a texture (simple mods), but if we want to make a whole new texture you get GIMP or Photoshop. For the UI, I suggest using the same XYZ movement gizmo we use now for whole prims, the same numerical input boxes, and the same selection highlight. Just add a radio button to "Edit vertex" like the "Edit linked parts" on that's already there. To simplify asset database and server overhead, it may make sense to do the editing local in the client until you leave edit mode. But I will leave technical implementation to those who know more about that side of things. Daniel > > > Date: Mon, 4 Oct 2010 21:47:48 -0700 > From: Stickman > > > Having said that, very simple editors that are not designed to have > fancy features but be as basic as possible would allow people to > create things without going to an outside source. But it must be clear > and planned that they will never evolve beyond a basic level. > > Stickman > > > ------------------------------ > > From: "Science Fiction Computer - SCi-Fi PC" > Subject: Re: [opensource-dev] Unity 3D as possible base / 2.x Codebase > plugin capable? > > > If mesh becomes a standard in SL, a basic mesh editor ought to be included > by default. > > ... > > SL Viewer Mesh Editor doesn't need to be Maya, it just needs to be 'there' > and 'basic' to encourage new content creators to create and feel that they > begin to learn and participate without significant barriers. > > We must try and avoid any situation where a New User in SL feels > disadvantaged or unable to create before they start. > > Regards, > > DMC Zsigmond-Jurassic > Science Fiction. > From miss_c_27 at yahoo.com Tue Oct 5 08:29:50 2010 From: miss_c_27 at yahoo.com (miss c) Date: Tue, 5 Oct 2010 08:29:50 -0700 (PDT) Subject: [opensource-dev] Inventory Organization Feature Request Message-ID: <291262.52694.qm@web82104.mail.mud.yahoo.com> As a user, I would like to be able to have better tools to keep my inventory neater and put less load on the server when it loads. I would love a search for duplicate uuid option so I can easily remove duplicates. I would also like an option to have certain things received go in designated folders, for instance if i open a purchased item and there is a landmark in the box , the landmark automatically can go into the landmark folder. Maybe possibly a warning popup saying I already have an item with this uuid in my inventory and asking if they can discard the new one. An option when i do a search to be able to select all items returned without selecting the folder its in, for instance if i search for key phrase floating text or unpackboxscript I can highlight all the returns just deleting that one item out of every folder. I would also like a function to remove old landmarks where the parcel no longer exists, same with avatar calling cards. Every single landmark in my inventory loads up when I start my viewer to check to see if I have visited that place before, it remembers places I havent vistted since 2006, just so it can change the pushpin color, is this really needed? Thank you Miss -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101005/262da917/attachment.htm From cg at lindenlab.com Tue Oct 5 08:47:27 2010 From: cg at lindenlab.com (CG Linden) Date: Tue, 5 Oct 2010 08:47:27 -0700 Subject: [opensource-dev] Inventory Organization Feature Request In-Reply-To: <291262.52694.qm@web82104.mail.mud.yahoo.com> References: <291262.52694.qm@web82104.mail.mud.yahoo.com> Message-ID: You might want to split this up into several things: - Duplicate avoidance (I believe you may be surprised at how rare true duplicates are, since every time you take something scripted back from the world into inventory, it will be a new asset with a different script state - so even this duplicate detection may involve several user stories) - Improved unpacking (How about -not- unpacking and using a delivery to folders and subfolders instead? Do you really want things to be auto-sorted by class? Many people would disagree there) - Improved selection (How about making ctrl-A select all -visible- items in the inventory window?) - Improve performance by changing the way inventory is loaded and accessed (there is work in progress on the server/web service side there). -- cg On Tue, Oct 5, 2010 at 8:29 AM, miss c wrote: > As a user, I would like to be able to have better tools to keep my > inventory neater and put less load on the server when it loads. I would > love a search for duplicate uuid option so I can easily remove duplicates. > I would also like an option to have certain things received go in > designated folders, for instance if i open a purchased item and there is a > landmark in the box , the landmark automatically can go into the landmark > folder. Maybe possibly a warning popup saying I already have an item with > this uuid in my inventory and asking if they can discard the new one. An > option when i do a search to be able to select all items returned without > selecting the folder its in, for instance if i search for key phrase > floating text or unpackboxscript I can highlight all the returns just > deleting that one item out of every folder. I would also like a function to > remove old landmarks where the parcel no longer exists, same with avatar > calling cards. Every single landmark in my inventory loads up when I start > my viewer to check to see if I have visited that place before, it remembers > places I havent vistted since 2006, just so it can change the pushpin > color, is this really needed? > > Thank you > > Miss > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101005/934272b9/attachment.htm From sllists at boroon.dasgupta.ch Tue Oct 5 09:14:14 2010 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Tue, 05 Oct 2010 18:14:14 +0200 Subject: [opensource-dev] Access to an object's inventory without rezing (was: Inventory Organization Feature Request) In-Reply-To: References: <291262.52694.qm@web82104.mail.mud.yahoo.com> Message-ID: <4CAB4ED6.6030108@boroon.dasgupta.ch> On 10/05/2010 05:47 PM, CG Linden wrote: > # Improved unpacking (How about -not- unpacking and using a delivery to > folders and subfolders instead? Do you really want things to be > auto-sorted by class? Many people would disagree there) Well, that's something the buyer can't choose. It depends on the seller. But how about not unpacking (in case of in-object delivery) and being able to access the contained items anyway? See VWR-2427 (Allow objects containing other items to be expanded within the Inventory). Cheers, Boroondas -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101005/e044f7e9/attachment.htm From josh at lindenlab.com Tue Oct 5 09:30:58 2010 From: josh at lindenlab.com (Joshua Bell) Date: Tue, 5 Oct 2010 09:30:58 -0700 Subject: [opensource-dev] Problem with displaying Arabic menu text in SL client In-Reply-To: References: <4CAAFBCD.1070904@boroon.dasgupta.ch> <-8408346637686232673@unknownmsgid> Message-ID: On Tue, Oct 5, 2010 at 4:32 AM, izze euler wrote: > Are you able to give an example on how to use this character within an XML > file? > Using that character won't have any effect. As Boroondas mentioned, Second Life's text engine is pretty basic and simply doesn't support: - Right-to-Left scripts - typically this functionality is called "BiDi" since the direction actually changes within text strings for numbers, foreign words, etc. - Contextual shaping (think: ligatures as a mandatory language feature) - Combining characters/diacritics* (think: characters merge into single glyphs) - Complex word breaking (for languages that don't use spaces) This is a big task, and (as Boroondas also mentioned) is probably best tackled by a thorough overhaul/replacement of SL's text rendering engine as Alissa Sabre attempted. Additionally, if we're talking about a localized version of the UI and not just rendering text content correctly, you'd also want to flip the X coordinates for some (but not all) UI layout if the app was running with a UI language that was RTL, which would require changes to the XUI engine and some of the controls. (Since, ideally you don't have to touch all of the control rects in all of the XUI files) -- Josh * I look forward to the day when someone writes a text engine that handles the character combining logic for classical Mayan. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101005/2c4b102f/attachment.htm From missannotoole at yahoo.com Tue Oct 5 10:04:01 2010 From: missannotoole at yahoo.com (Ann Otoole) Date: Tue, 5 Oct 2010 10:04:01 -0700 (PDT) Subject: [opensource-dev] Latest LL viewer beta has inventory count issues? In-Reply-To: <291262.52694.qm@web82104.mail.mud.yahoo.com> References: <291262.52694.qm@web82104.mail.mud.yahoo.com> Message-ID: <612206.92170.qm@web120515.mail.ne1.yahoo.com> Anyone else noticing the inventory counts in the latest LL beta client are increasingly less than the count in the production release client and that cache clear does not correct it? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101005/9363b0ae/attachment.htm From javajoint at gmail.com Tue Oct 5 10:58:48 2010 From: javajoint at gmail.com (Daniel Smith) Date: Tue, 5 Oct 2010 10:58:48 -0700 Subject: [opensource-dev] Vertex Edit Capability In-Reply-To: <4CAB4370.2060702@gmail.com> References: <4CAB4370.2060702@gmail.com> Message-ID: On Tue, Oct 5, 2010 at 8:25 AM, Daniel wrote: > I submitted JIRA issue VWR-23202 to provide the simplest in-world > editing capability, that of moving vertexes on a mesh. > > One of the most likely starting points I see is the terrain editor. That is a limited mesh editor in itself. (one of the other Daniels) -- Daniel Smith - Sonoma County, California http://daniel.org/resume -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101005/0a727993/attachment.htm From q at lindenlab.com Tue Oct 5 12:07:24 2010 From: q at lindenlab.com (Kent Quirk (Q Linden)) Date: Tue, 5 Oct 2010 15:07:24 -0400 Subject: [opensource-dev] Unity 3D as possible base for future (maybe even official) SL Viewers In-Reply-To: References: <4CA8957D.3040402@lindenlab.com> <4CA8B04B.4090801@comcast.net> <4CA8E6EF.9060703@boroon.dasgupta.ch> <1286142965.3438.12.camel@glen-desktop> <1286144147.3438.18.camel@glen-desktop> <1286150688.2719.13.camel@nostromo> <51D72C5392864F128AB05A712BD29339@TWEEDY64> <099C27DF404C4A48A05B1D20510E7CFF@TWEEDY64> Message-ID: Agreed (a day late). Teravus' post is great -- very insightful, and it mimics our own thinking. The complexity of what we render, and the fact that it's not professionally created content, means that we get all sorts of edge cases that aren't a problem in traditional graphics engines. Many systems, including Unity, put constraints on the content they'll render to achieve speed or certain effects. We don't have the same sorts of limitations, and so our engine needs to be special. I know we've had people who've evaluated Unity as well as other engines, including Ogre, and it's by no means a simple problem to figure out how to get our content into those systems without choking them. It may be possible, and one of the things I'd like to do is abstract our renderer better so that we have the ability to try a few experiments without re-implementing all of the viewer. Anyway, I guess that graphics systems are kind of like Tolstoy's unhappy families: each one sucks in its own way. It so happens that ours is designed for our content (surprise!), and our content is weird, so other engines may not be as obviously well suited to displaying it as you might think. Q On Oct 4, 2010, at 8:32 AM, Teravus Ovares wrote: > When working on IdealistViewer, I noticed that, generally, third party 'general purpose' renderers like Irrlicht and Ogre are not well suited for rendering objects at the quantity that SecondLife prims require. Rendering prims /can/ be done with them, however, not at the level that can be done with the SecondLife viewer. > > With Irrlicht, for example, the memory load of a typical 5000 prim scene runs up against the 2GB memory limit. > > With SecondLife prims, it's more about segmenting the render data so that only the unique things are kept and everything else is a reference to something that was calculated before. Out of the box, Irrlicht requires per-instance knowledge about texture, mesh buffer, face and lighting settings configurations. This and reference/const/value type semantics used in the engine causes far more data duplications then are necessary. > > Prims are strange for rendering. The prim's mesh result is complex in terms of vertex count however, in a given 5000 prim scene there's on average 130 'unique' prim mesh. Those 130 unique mesh are duplicated with various textures, colors, orientations and associated data to make for the entire prim count in the region. In theory, you can manage memory reasonably well by using a 'mesh factory' pattern where by the mesh factory keeps track of instance counts and generates a new mesh when required. In practice, however, the associated data makes this very difficult. In Irrlicht, the API is such that the texture configuration data is 'stuck in with' the mesh data object. So, to get the variability that the secondlife prim scene requires, you're also duplicating the mesh and making small changes to the object's visual configuration data. > > Irrlicht, like Ogre, is better optimized for a smaller number of more complex mesh objects then a very large number of highly 'instancable' objects with very small differences. I'd comment on the opposite of the last statement... but I don't really know about how the SecondLife viewer works under the hood to do so (OpenSimulator Developer). > > I don't think that this issue is going to 'go away'. In fact, introducing mesh in the viewer is going to make that memory, speed, and instancing balance even more difficult to maintain. The gap between the viewer and 3rd party 'general purpose' rendering tools will narrow in both directions.. the viewer will get better at managing arbitrary mesh and 3rd party 'general purpose' rendering tools will be able to render secondlife scenes better because there will be less 'prim' to render as a result of there being arbitrary mesh. > > In either case, the future is full of interesting technical challenges. I think in unity, like with Irrlicht, smaller, more specialized scenes will work OK with regards to prim rendering. And, I don't think 3rd party renderers are going to be able to come close to the capability of the SecondLife viewer when dealing with prim. They're just not designed for the same type of data. The object models and API just are not really appropriate for prim. I'm not saying that it isn't worth pursuing a render plugin architecture. I am saying, however, that given that 3rd party 'general purpose' renderers are never going to be able to meet the SecondLife viewer's capability in rendering prim, it probably shouldn't be very high on the priority of things to do. > > Regards > > Teravus > > > On Mon, Oct 4, 2010 at 12:36 AM, Brandon Husbands wrote: > Ive used it, and fount it blehh. I think we are failing to communicate about our conception of what is possible and what is used. > > Are you saying that the normal user would have full access to what you use to develop the "client"? > As its a middle ware really i fail to see how your going to implement that. > I could be wrong. There are so many propitiatory things that you'd have to code in and handle rendering for with sl. Also remember you can not change the server backend. I just do not see it possible or powerful enough to handle what sl uses and does. I guess its the same concept between higher level langs and lower level ones. I could be wrong about this and just be old school in my thoughts. > > If your so sure that it can do what needs to be done why have you not already done a prototype. > From what your saying should be easy to get connected and render the scene. > > I would love to be wrong in that regard but then again i just don't see how your going to handle such things in a closed source engine. > > > > > On Sun, Oct 3, 2010 at 9:36 PM, wrote: > Obviously these are subjective statements but I think your statements are based on an incomplete understanding of the tool and probably limited experience using it. > > > Not sure how you can say it is clunky. I have a scene hierarchy where I can list and see every object in my seen. It?s like seeing every prim in my region. I can select any object and view it in the inspector. > > > Scripts are assigned to objects and not copied and duplicated into each prim. I can edit a script once and every object that uses it gets that update. > > > In the inspector I can see every public value of the script and change its value without having to actually edit the script. > > > I can use assets directly from my disk without having to upload them when creating. That is much faster than waiting for SL to do things. > > > Scripts can access to every bone in the skeleton system and I can override animations to adjust the bones to a given scene?s needs, for instance if two avatars are a different height and I can adjust the bones to make their hands connect so they can really walk hand in hand. > > > I can create keyed animations in Unity or use animations from other programs. Animates can throw events which can trigger code to do things. From scripts you can create and edit the animations and their key data. You can layer animations, set their weights. You can sync the length of layers. Cross fade animations. > > > You have materials like you do in Maya. > > > I can create custom shaders. > > > You can have spot lights, point lights and directional lights. > > > You can create your own skyboxes. > > > You can use water any where, not limited to just one plane with the water shader. > > > I can use meshes. Any object in the scene can have a skeleton. > > > I can edit meshes and vertices in real-time allowing me to create parameterized content in real-time. > > > I can load assets from a URL or through websockets. > > > I can load textures from a URL or through websockets. > > > There is a profiler that lets me see in great detail what the engine is doing. > > > I can use Visual Studio to develop my scripts with all the features of Visual Studio. > > > I can run a debugger and debug the scripts and libraries I am using in the scene. > > > I can do baked lighting including ambient occlusion inside the tool > > > I can do occlusion culling so I can have very large scenes. > > > I can control what assets are loading and stream the rest in the background. > > > I can use libraries of code. > > > From one code base I can be published to many platforms including web and mobile phone. Linux is the big one they are missing a native support for. > > > Should I go on? > > > > This is a group that is focused on Second Life client so not trying to convince anyone to switch. But I do think it is fair that people give accurate information based on real experience and not guessing. I think if you understood the tool more you will see your statements are based on inaccurate understanding of the tool. > > > I personally do believe that the game development platforms will outpace anyone doing proprietary client development and as such the days are quickly approaching where you won?t be able to justify the cost of developing your own client rendering engines when you can get the features off the shelf for $1200 that would cost you way more to do yourself. I also believe you won?t stay up and will find yourself quickly falling behind. > > > M. > > > > > > From: Brandon Husbands [mailto:xotmid at gmail.com] > Sent: Sunday, October 03, 2010 9:57 PM > To: mysticaldemina at xrgrid.com > Cc: Robert Exile In Paradise Murphey; opensource-dev at lists.secondlife.com > > > Subject: Re: [opensource-dev] Unity 3D as possible base for future (maybe even official) SL Viewers > > > Actually its not inaccurate. The tools themselves are clunky.. And i am not taking this as a lsl vs their language. I am talking about the engine itself. From a lower level perspective. Unity is really more of a middleware when it comes to graphics engines. sure you can use any network you want but in a whole as what it offers as a base is not what would be able to be used for something on the scale of sl. > > Also as a user you would not have those midddle ware tools that you see unless you want the whole thing to be clunky. > > Its rigging and control system is designed for rapid prototyping and higher level designig. > > I would put unity as an equivilant to making a mod for a fps with "good" tools unlike most mod systems. > > But as a complete engine from a graphics and other standpoints The hero engine blows that away. Actually there are quite a few game engines that surpass unity. And if we take thoes its like compairing writing with QT vs flash. (not quick time... but QT). > > Flash is great as a packaged thing but its limited. Now unity can me modified and such to some extent but no where whats needed for a SL type of thing. > > And for the record I am not a fan boi of any engine or system. But i have developed a mmo from the ground up in 2001 to playable alpha 2 on the cusp of beta before the project was shelved due to funding. > Having written a majority of the Engine and most of the server code. I would thing these are subjects i am quite capable of assessing. > > > > On Sun, Oct 3, 2010 at 7:41 PM, wrote: > > Alright, this is the most incorrect post I have ever seen so I would guess you have used Unity for maybe a total of an one hour. > > > First of all you can use any network technology you like. It does come with a very basic P2P network, but you can use many game server that you like included some that support fail over and fault tolerance configurations. In fact there are those using SL?s server and rendering prims and sculpties in Unity. > > > The scripting language can also use C# and supports a way more complete set of functions then is available in SL. This list is so long I don?t know where to start on functionality it supports that LSL doesn?t support. > > > Not sure your point about FPS, it has Ambers Occlusion culling, beast lighting and deferred lighting which lets it create FPS you can?t do in SL for the same amount of content. > > > So if you are going to comment on Unity please do your homework and don?t mislead people. > > > M. > > > > > From: opensource-dev-bounces at lists.secondlife.com [mailto:opensource-dev-bounces at lists.secondlife.com] On Behalf Of Brandon Husbands > Sent: Sunday, October 03, 2010 8:20 PM > To: Robert Exile In Paradise Murphey > Cc: opensource-dev at lists.secondlife.com > Subject: Re: [opensource-dev] Unity 3D as possible base for future (maybe even official) SL Viewers > > > Unity is the biggest POS i have ever used.... > Not well designed. IMHO. Its like trying to do SL in javascript. > Not literally but you know what i mean. > > It was never designed for a heavy network transport now multi player / mmo style. > > A FPS maybe but nothing on a grand scale. > > On Sun, Oct 3, 2010 at 7:04 PM, Robert "Exile In Paradise" Murphey wrote: > > On Sun, 2010-10-03 at 18:15 -0400, Glen Canaday wrote: > > That's why I suggested Ogre instead. I personally think it would be a > > better fit and more productive to look at. Others may have different > > opinions. > > Well, I run Linux and agree that being shut out after > years of being supported would be suboptimal for me. > > Running in a VM is an exercise that only a masochist can love > compared to an application natively supported. > > Plus, a VM position forces people to purchase additional OSes > just to support one (or a handful) of apps, which add massive > overheard in additional administration. At-home-VM is a > temporary workaround, not a "platform strategy". > Remember - SL is supposed to be Fast, Easy, Fun... not an > enterprise-level support nightmare just to boot and run in > the first place. > > Unity3D seems like a lot of "lose" to me: for the same amount > of effort to switch to that, re-base on something else that keeps > the same supported set of platforms or extends it without dropping > already supported platforms. > > OGRE may be a great suggestion, especially in light of the RealXtend > folks having already broken a LOT of the ground of an "SL client > that uses OGRE rendering." Why re-reinvent their wheel? > Maybe talk to them about Naali and see what goes from there? > > -- > Robert "Exile In Paradise" Murphey > Promise her anything, but give her Exxon unleaded. > > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting privileges > > > > > -- > ------------------------------------------------------------------------------------------------------------------------------- > This email is a private and confidential communication. Any use of email may be subject to the laws and regulations of the United States. You may not Repost, Distribute nor reproduce any content of this message. > ------------------------------------------------------------------------------------------------------------------------------- > ------------------------------------------------------------------------------------------------------------------------------- > > > > > -- > ------------------------------------------------------------------------------------------------------------------------------- > This email is a private and confidential communication. Any use of email may be subject to the laws and regulations of the United States. You may not Repost, Distribute nor reproduce any content of this message. > ------------------------------------------------------------------------------------------------------------------------------- > ------------------------------------------------------------------------------------------------------------------------------- > > > > > -- > ------------------------------------------------------------------------------------------------------------------------------- > This email is a private and confidential communication. Any use of email may be subject to the laws and regulations of the United States. You may not Repost, Distribute nor reproduce any content of this message. > ------------------------------------------------------------------------------------------------------------------------------- > ------------------------------------------------------------------------------------------------------------------------------- > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting privileges > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting privileges -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101005/76c4ea5a/attachment-0001.htm From elllamcmahon at googlemail.com Tue Oct 5 12:41:06 2010 From: elllamcmahon at googlemail.com (Ellla McMahon) Date: Tue, 5 Oct 2010 20:41:06 +0100 Subject: [opensource-dev] Latest LL viewer beta has inventory count issues? In-Reply-To: <612206.92170.qm@web120515.mail.ne1.yahoo.com> References: <291262.52694.qm@web82104.mail.mud.yahoo.com> <612206.92170.qm@web120515.mail.ne1.yahoo.com> Message-ID: Recently reported against Second Life Server 10.9.10.210079SVC-6353Inventory fails to load fully It has been ongoing for well over a year > so maybe not the issue you are seeing. Reporter *was* using Second Life 2.2.0 (210127), so maybe this issue is more obvious in the 2.2 Beta. Older issue SVC-5902 Client gives up before finishing to load full inventory due to packet loss and request for a refresh button VWR-23074Unloading item on my inventory, cause some useless relog. Other possibly related (to a slow/incomplete Inventory loading) issues - VWR-23308 Can't rename a new folder - STORM-314 Wear button in My Appearance greyed out On 5 October 2010 18:04, Ann Otoole wrote: > Anyone else noticing the inventory counts in the latest LL beta client are > increasingly less than the count in the production release client and that > cache clear does not correct it? > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101005/f5805402/attachment.htm From esbee at lindenlab.com Tue Oct 5 14:28:42 2010 From: esbee at lindenlab.com (Sarah (Esbee) Hutchinson) Date: Tue, 5 Oct 2010 17:28:42 -0400 Subject: [opensource-dev] Daily Scrum Update - Tuesday, October 5, 2010 Message-ID: Tuesday, October 5, 2010 *General Notes* * Merge Monkey of the Day: Merov *Team Status* *====Merov Linden====* *PAST* * JIRA triage to prepare sprint planning * Merge Monkeying: move things in beta, v-d, also pulled beta in v-d so we have those fixed in v_d as well. * More HR stuff *FUTURE* * Sprint planning! * STORM-137 : FMOD issue: fix upload issue with Brad. Hopefully, the rest will be easy. * STORM-105 : Perf decompression: put new data out, check the work done by opensource-dev community on similar tests. * STORM-306: back burner: bissect and incremental builds till I pinpoint the culprit... *IMPEDIMENTS* * Kakadu license upgrade *====Oz Linden====* *PAST* * Clarified wiki documentation on where to get code and download binaries ** Updated to use new auto-update direct links ** Submitted request to change main download page to match * TPVP Changes *FUTURE* * Worked on proposals for open code review and build systems * Get current on autobuild developments *IMPEDIMENTS* * none *====Q Linden====* *PAST* * HR stuff * Q4 planning * Further meetings on test automation * Writing automation for LLDir *FUTURE* * HR stuff * Q4 planning * Answer PE questions on STORM-325 and 295 *IMPEDIMENTS* * My brain *====Esbee Linden====* *PAST* * VWR triage * Sprint 5 planning * Backlog reviews * Q4 planning * Systems requirements research *FUTURE* * VWR triage * Sprint 5 Planning * Viewer roadmap planning * Systems requirements research * Q4 planning * HR Stuff *IMPEDIMENTS* * None *====Paul ProductEngine ====* *PAST* * STORM-263 Cog button in lower-left of sidebar panel does not close popup menu on second click ** Fixed, tomorrow will test and send for a review *FUTURE* * other bugs *IMPEDIMENTS* *none *====Andrew ProductEngine====* *PAST* * Bug STORM-264 (Resize grab areas on detached sidebar panels are tiny and unmarked) ** Reviewed. * Bug STORM-325 ("i" button no longer opens profiles). ** Reproduced in viewer-beta, investigated, found changeset with fix in viewer-development and left comment in ticket. * Major bug STORM-295 (Mini-inspector fades out if adjust voice volume). ** Reproduced in viewer-beta, investigated, found changeset with fix in viewer-development and left comment in ticket. * Major bug STORM-315 (Changes to Environment Editor are not saved and do not persist across sessions). ** Started investigating. Estimate- 6 hours. *FUTURE* * STORM-315 (Changes to Environment Editor are not saved and do not persist across sessions). *IMPEDIMENTS* * STORM-295 and STORM-325 are fixed in viewer-development. What should be done with these fixes? Should changesets with them be transplanted from one repository to another, or simply fixed the same way manually, or left untouched to wait merge with development? *====Vadim ProductEngine====* OOO - Vacation. Will be back to office on Oct, 11th. *====Seth ProductEngine (Sergey)====* *PAST* * BUG (STORM-316) Debug: Inventory.Folders by Name/Sort by Date/Sort by Name/System Folders to Top Do not apply and settings changes do not persist after relogging. ** Investigated. Waiting for Esbee's reply in JIRA. * BUG (STORM-314) Wear button in My Appearance greyed out ** Investigated. Could not reproduce with reporter's scenario. Probably misfiled. * BUG (STORM-310) crash after setting sound preferences ** Could not reproduce. * BUG (STORM-305) Undocked minimized SP tabs are restored after re-login ** WIP. *FUTURE* * BUG (STORM-305) Undocked minimized SP tabs are restored after re-login ** Estimated: 4 hours. *IMPEDIMENTS* * STORM-316 needs answer from Esbee (?) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101005/e999050d/attachment.htm From malachi at tamzap.com Tue Oct 5 14:36:03 2010 From: malachi at tamzap.com (malachi) Date: Tue, 05 Oct 2010 17:36:03 -0400 Subject: [opensource-dev] Where oh where has my rendering gone? Message-ID: Oh where oh where could it be! Anyone can point me in the direction of the RGB rendering system in the client? Am thinking about making a switch for b&w output to the client. just have no idea where to start poking this beast. -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ From missannotoole at yahoo.com Tue Oct 5 14:43:59 2010 From: missannotoole at yahoo.com (Ann Otoole) Date: Tue, 5 Oct 2010 14:43:59 -0700 (PDT) Subject: [opensource-dev] Latest LL viewer beta has inventory count issues? In-Reply-To: References: <291262.52694.qm@web82104.mail.mud.yahoo.com> <612206.92170.qm@web120515.mail.ne1.yahoo.com> Message-ID: <616899.39574.qm@web120501.mail.ne1.yahoo.com> Could be related to an existing pjira which is why I asked. However it is restricted to code after the LL production release candidate. I observe this in the latest Kirstens and the beta viewer. Deleting cache and refreshing in the production viewer produces the expected inventory count. Therefore it "appears" to be related to the newer code base only. However I do know asset data is "vanishing". I have a ticket open and never looked at in respect to a humble shoe texture I created and uploaded to SL that has vanished from the asset system. Easily replacable yes but highly annoying to know data seemingly vanishes into thin air that way. However the inventory record for that texture remains intact. When previewed or rezzed the texture just stays gray. No matter who tries to view it. That is an asset issue not an inventory issue. ________________________________ From: Ellla McMahon To: Ann Otoole Cc: opensource-dev at lists.secondlife.com Sent: Tue, October 5, 2010 3:41:06 PM Subject: Re: [opensource-dev] Latest LL viewer beta has inventory count issues? Recently reported against Second Life Server 10.9.10.210079SVC-6353Inventory fails to load fully It has been ongoing for well over a year > so maybe not the issue you are seeing. Reporter was using Second Life 2.2.0 (210127), so maybe this issue is more obvious in the 2.2 Beta. Older issue SVC-5902 Client gives up before finishing to load full inventory due to packet loss and request for a refresh button VWR-23074 Unloading item on my inventory, cause some useless relog. Other possibly related (to a slow/incomplete Inventory loading) issues * VWR-23308Can't rename a new folder * STORM-314Wear button in My Appearance greyed out On 5 October 2010 18:04, Ann Otoole wrote: Anyone else noticing the inventory counts in the latest LL beta client are increasingly less than the count in the production release client and that cache clear does not correct it? > > >_______________________________________________ >Policies and (un)subscribe information available here: >http://wiki.secondlife.com/wiki/OpenSource-Dev >Please read the policies before posting to keep unmoderated posting privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101005/6f457383/attachment-0001.htm From lee.ponzu at gmail.com Tue Oct 5 16:49:52 2010 From: lee.ponzu at gmail.com (Ponzu) Date: Tue, 5 Oct 2010 19:49:52 -0400 Subject: [opensource-dev] Daily Scrum Update - Tuesday, October 5, 2010 In-Reply-To: References: Message-ID: I hope all this HR stuff is OK. It is making us nervous out here. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101005/9ae61513/attachment.htm From esbee at lindenlab.com Tue Oct 5 19:10:09 2010 From: esbee at lindenlab.com (Sarah (Esbee) Hutchinson) Date: Tue, 5 Oct 2010 22:10:09 -0400 Subject: [opensource-dev] Daily Scrum Update - Tuesday, October 5, 2010 In-Reply-To: References: Message-ID: We've all been working on our end-of-year reviews. Nothing to worry about! :) (We'll make a point of being more clear about this in future, sorry!) - Esbee On Tue, Oct 5, 2010 at 7:49 PM, Ponzu wrote: > I hope all this HR stuff is OK. It is making us nervous out here. > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101005/e8f69aef/attachment.htm From q at lindenlab.com Tue Oct 5 19:29:04 2010 From: q at lindenlab.com (Kent Quirk (Q Linden)) Date: Tue, 5 Oct 2010 22:29:04 -0400 Subject: [opensource-dev] Where oh where has my rendering gone? In-Reply-To: References: Message-ID: <86DC83B1-9F3E-4576-97ED-A8E5F2A8D0CF@lindenlab.com> Well, it's not quite like that. To pull this off, you'd have to take everywhere we set a color, and set it instead to its equivalent black and white value (there's a formula that's traditionally used, although there's no "correct" way to do it: Y = 0.3*R + 0.59*G + 0.11*B). You *might* be able to get away with modifying the LLColor4 constructor to do this, but it's probably going to have some surprising results when you assign a value and don't get the same value back. Next, you'd have to filter all of the textures so that all textures are first converted to B&W before being used. That's also a troublesome task, and is likely to be slow. On certain graphics cards, you could try to convert all the pixel shaders to do a B&W conversion for each pixel before rendering, but I don't know enough about our system to know if that would catch all the useful cases or not. I hope that helps, but I'm not particularly optimistic. :/ Q On Oct 5, 2010, at 5:36 PM, malachi wrote: > Oh where oh where could it be! > > Anyone can point me in the direction of the RGB rendering system in the > client? Am thinking about making a switch for b&w output to the client. > just have no idea where to start poking this beast. > > > -- > Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting privileges From secret.argent at gmail.com Wed Oct 6 04:48:09 2010 From: secret.argent at gmail.com (Argent Stonecutter) Date: Wed, 6 Oct 2010 06:48:09 -0500 Subject: [opensource-dev] Vertex Edit Capability In-Reply-To: References: <4CAB4370.2060702@gmail.com> Message-ID: On 2010-10-05, at 12:58, Daniel Smith wrote: > One of the most likely starting points I see is the terrain editor. That is a limited mesh editor in itself. That would be... really horrible. The terrain editor only operates on one axis and is extremely hard to use for any kind of precise work. I'd rather go the other way and get a basic mesh editor first, then maybe see about improving the terrain editor to match. From esbee at lindenlab.com Wed Oct 6 07:04:46 2010 From: esbee at lindenlab.com (Sarah (Esbee) Hutchinson) Date: Wed, 6 Oct 2010 10:04:46 -0400 Subject: [opensource-dev] Esbee's Office Hour Canceled for this week Message-ID: I've got a conflicting meeting today, so I need to cancel my office hours this week. We'll resume next week. Sorry for the late notice, folks! - Esbee -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101006/6c40235f/attachment.htm From oz at lindenlab.com Wed Oct 6 08:24:06 2010 From: oz at lindenlab.com (Oz Linden (Scott Lawrence)) Date: Wed, 06 Oct 2010 11:24:06 -0400 Subject: [opensource-dev] Latest LL viewer beta has inventory count issues? In-Reply-To: <616899.39574.qm@web120501.mail.ne1.yahoo.com> References: <291262.52694.qm@web82104.mail.mud.yahoo.com> <612206.92170.qm@web120515.mail.ne1.yahoo.com> <616899.39574.qm@web120501.mail.ne1.yahoo.com> Message-ID: <4CAC9496.1050605@lindenlab.com> On 2010-10-05 17:43, Ann Otoole wrote: > However I do know asset data is "vanishing". I have a ticket open and > never looked at in respect to a humble shoe texture I created and > uploaded to SL that has vanished from the asset system. Easily > replacable yes but highly annoying to know data seemingly vanishes > into thin air that way. However the inventory record for that texture > remains intact. When previewed or rezzed the texture just stays gray. > No matter who tries to view it. That is an asset issue not an > inventory issue. Do you have an id for that ticket? The first question is whether the UUID actually exists correctly in the asset store and the viewer is failing to retrieve it correctly, or whether the data in the asset store is itself lost or corrupted. From josh at lindenlab.com Wed Oct 6 08:57:34 2010 From: josh at lindenlab.com (Joshua Bell) Date: Wed, 6 Oct 2010 08:57:34 -0700 Subject: [opensource-dev] Where oh where has my rendering gone? In-Reply-To: <86DC83B1-9F3E-4576-97ED-A8E5F2A8D0CF@lindenlab.com> References: <86DC83B1-9F3E-4576-97ED-A8E5F2A8D0CF@lindenlab.com> Message-ID: On Tue, Oct 5, 2010 at 7:29 PM, Kent Quirk (Q Linden) wrote: > Well, it's not quite like that. To pull this off, you'd have to take > everywhere we set a color, and set it instead to its equivalent black and > white value (there's a formula that's traditionally used, although there's > no "correct" way to do it: Y = 0.3*R + 0.59*G + 0.11*B). You *might* be > able to get away with modifying the LLColor4 constructor to do this, but > it's probably going to have some surprising results when you assign a value > and don't get the same value back. > How about post-processing every frame before the final swapBuffers call? That seems like it could be done with a shader and only touching a small amount of code. This would affect the UI as well as the world viewport, however, without some significant refactoring, but given that we already have some post-processing effects (glow, etc) perhaps there's already a good spot to slot this in? (Don't trust me too much, though, as I've never written a non-trivial shader and have never touched the viewer's render pipeline!) Of course, once you have monochrome output, you could tweak the shader and get sepia-toned rendering. Old-timey SL, anyone? -- Josh -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101006/4c3b071f/attachment.htm From josh at lindenlab.com Wed Oct 6 09:00:34 2010 From: josh at lindenlab.com (Joshua Bell) Date: Wed, 6 Oct 2010 09:00:34 -0700 Subject: [opensource-dev] Latest LL viewer beta has inventory count issues? In-Reply-To: <4CAC9496.1050605@lindenlab.com> References: <291262.52694.qm@web82104.mail.mud.yahoo.com> <612206.92170.qm@web120515.mail.ne1.yahoo.com> <616899.39574.qm@web120501.mail.ne1.yahoo.com> <4CAC9496.1050605@lindenlab.com> Message-ID: On Wed, Oct 6, 2010 at 8:24 AM, Oz Linden (Scott Lawrence) wrote: > On 2010-10-05 17:43, Ann Otoole wrote: > > However I do know asset data is "vanishing". I have a ticket open and > > never looked at in respect to a humble shoe texture I created and > > uploaded to SL that has vanished from the asset system. > > Do you have an id for that ticket? The first question is whether the > UUID actually exists correctly in the asset store and the viewer is > failing to retrieve it correctly, or whether the data in the asset store > is itself lost or corrupted. > +1 - there's a fairly deep pipeline between where the assets are actually stored and the viewer, and of course there's the possibility of a bug anywhere in between. An asset ID is all we need to start investigating. -- Josh (Caches and proxies and redirects, oh my!) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101006/39ba8c6d/attachment.htm From javajoint at gmail.com Wed Oct 6 10:02:55 2010 From: javajoint at gmail.com (Daniel Smith) Date: Wed, 6 Oct 2010 10:02:55 -0700 Subject: [opensource-dev] Vertex Edit Capability In-Reply-To: References: <4CAB4370.2060702@gmail.com> Message-ID: On Wed, Oct 6, 2010 at 4:48 AM, Argent Stonecutter wrote: > On 2010-10-05, at 12:58, Daniel Smith wrote: > > One of the most likely starting points I see is the terrain editor. That > is a limited mesh editor in itself. > > That would be... really horrible. The terrain editor only operates on one > axis and is extremely hard to use for any kind of precise work. > > Heh, then it turns out to be 'likely, but not so useful'... Aside from that bit, my gut tells me it may be more useful for the codebase to really support plugins, and then to go from there. Slapping a lot of new functionality on to the current code seems like a recipe for bloat. Daniel Smith - Sonoma County, California http://daniel.org/resume -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101006/8d6a929e/attachment-0001.htm From secret.argent at gmail.com Wed Oct 6 10:38:50 2010 From: secret.argent at gmail.com (Argent) Date: Wed, 6 Oct 2010 12:38:50 -0500 Subject: [opensource-dev] Where oh where has my rendering gone? In-Reply-To: References: <86DC83B1-9F3E-4576-97ED-A8E5F2A8D0CF@lindenlab.com> Message-ID: On Wed, Oct 6, 2010 at 10:57 AM, Joshua Bell wrote: > Of course, once you have monochrome output, you could tweak the shader and > get sepia-toned rendering. Old-timey SL, anyone? Don't forget the vignetting and cracquelaire effect. From missannotoole at yahoo.com Wed Oct 6 11:28:18 2010 From: missannotoole at yahoo.com (Ann Otoole) Date: Wed, 6 Oct 2010 11:28:18 -0700 (PDT) Subject: [opensource-dev] Where oh where has my rendering gone? In-Reply-To: References: <86DC83B1-9F3E-4576-97ED-A8E5F2A8D0CF@lindenlab.com> Message-ID: <652730.30980.qm@web120507.mail.ne1.yahoo.com> Or if you have an invidia card just use the control panel and make it gray scale. At least for viewing anyway. Might not work so good for filming. ________________________________ From: Joshua Bell To: Kent Quirk (Q Linden) Cc: "opensource-dev at lists.secondlife.com" Sent: Wed, October 6, 2010 11:57:34 AM Subject: Re: [opensource-dev] Where oh where has my rendering gone? On Tue, Oct 5, 2010 at 7:29 PM, Kent Quirk (Q Linden) wrote: Well, it's not quite like that. To pull this off, you'd have to take everywhere we set a color, and set it instead to its equivalent black and white value (there's a formula that's traditionally used, although there's no "correct" way to do it: Y = 0.3*R + 0.59*G + 0.11*B). You *might* be able to get away with modifying the LLColor4 constructor to do this, but it's probably going to have some surprising results when you assign a value and don't get the same value back. > How about post-processing every frame before the final swapBuffers call? That seems like it could be done with a shader and only touching a small amount of code. This would affect the UI as well as the world viewport, however, without some significant refactoring, but given that we already have some post-processing effects (glow, etc) perhaps there's already a good spot to slot this in? (Don't trust me too much, though, as I've never written a non-trivial shader and have never touched the viewer's render pipeline!) Of course, once you have monochrome output, you could tweak the shader and get sepia-toned rendering. Old-timey SL, anyone? -- Josh -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101006/c28e4315/attachment.htm From akanevsky at productengine.com Wed Oct 6 14:19:39 2010 From: akanevsky at productengine.com (Anya Kanevsky) Date: Wed, 6 Oct 2010 14:19:39 -0700 Subject: [opensource-dev] Daily Scrum Update - Wednesday, October 6 Message-ID: Date: Wed Oct 6 == GENERAL NOTES == * Merge Monkey of the Day: Merov == DAILY SCRUM == === Merov Linden=== PAST * Sprint planning: meeting and timing * STORM-306: Lots of tests. Narrowed down the changes to *1 file*! Have some hope to pin that bugger shortly. :) FUTURE * STORM-137 : FMOD issue: fix upload issue with Brad. Hopefully, the rest will be easy. * STORM-105 : Perf decompression: put new data out, check the work done by opensource-dev community on similar tests. * STORM-306: back burner: bissect and incremental builds till I pinpoint the culprit... IMPEDIMENTS * Kakadu license upgrade ==Oz Linden== PAST * Caught up on the state of autobuild * More wiki updates * Worked on open build service definition * Got an S3 account FUTURE * Prep a budget proposal for open build service & code review system * Office Hour * Pester Team Chopper about opening up autobuild * Update develop.secondlife.com * Work on updates to TPV Directory processes IMPEDIMENTS * none === Q Linden=== PAST * HR (annual reviews) * Q4 / 2011 planning * Unit test system research and use FUTURE * Finish HR * Q4 / 2011 planning * Unit test working IMPEDIMENTS * OSX 10.6 builds are not officially supported so I'm wrangling that === Esbee Linden==== PAST * VWR triage * Sprint 5 planning * Q4+ planning * Systems requirements research * Reviewed versions, "viewer-development bug queue and viewer 2.2.0 Beta" and prioritized all bugs FUTURE * VWR triage * Review Snowstorm Jira tickets * Viewer roadmap planning * Systems requirements research * Q4+ planning * End of year review discussion with Q IMPEDIMENTS * None === Paul ProductEngine=== PAST: * STORM-263 Cog button in lower-left of sidebar panel does not close popup menu on second click ** Fixed FUTURE: * other bugs IMPEDIMENTS: *none === Seth Productengine === PAST: * BUG (STORM-305) Undocked minimized SP tabs are restored after re-login ** WIP. 90% complete. The issue required some changes in basic floater behavior because regular floaters should be unminimized on viewer start. FUTURE: * BUG (STORM-305) Undocked minimized SP tabs are restored after re-login ** Estimated: 2 hours. IMPEDIMENTS: * STORM-316 needs answer from Esbee (?) === Andrew Productengine === PAST: * Major bug STORM-315 (Changes to Environment Editor are not saved and do not persist across sessions). ** Investigated. This issue turned to be time consuming, because I was unfamiliar with this floater behaviour and its code. Part of this issue doesn't reproduce on Win7, code seems fine too. Another part to me seems not like a bug- because code there doesn't even try save water color outside of presets, and it wasn't done in viewer 2.1.1 so if reporter wishes it another way perhaps it should be story and not defect. Wrote about investigation resulsts and asked a question in ticket. * Bug STORM-299 (World map floater opens instead Mini-map if double-click on minimized Mini-map) ** WIP. Estimate - 1 hour. FUTURE: * STORM-299 (World map floater opens instead Mini-map if double-click on minimized Mini-map) IMPEDIMENTS: * STORM-295 and STORM-325 are fixed in viewer-development. What should be done with these fixes? Should changesets with them be transplanted from one repository to another, or simply fixed the same way manually, or left untouched to wait merge with development? === Vadim Productengine === * OOO - Vacation. Will be back to office on Oct, 11th. === Andrey Productengine === PAST: * smoke test of 210917 at viewer-development * integrated tickets verification on 210917 at viewer-development FUTURE: * regression testing of 210917 at viewer-development in scope of changes from previous development builds IMPEDIMENTS: * none From sllists at boroon.dasgupta.ch Wed Oct 6 15:41:16 2010 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Thu, 07 Oct 2010 00:41:16 +0200 Subject: [opensource-dev] Remaining build issues for 64bit linux standalone out-of-source (without unit tests) In-Reply-To: <4C7E37E7.5080105@boroon.dasgupta.ch> References: <4C766008.1070001@boroon.dasgupta.ch> <4C78DB67.5040005@boroon.dasgupta.ch> <4C7D501C.5040709@boroon.dasgupta.ch> <4C7E37E7.5080105@boroon.dasgupta.ch> Message-ID: <4CACFB0C.2020808@boroon.dasgupta.ch> A lot of fixes from my previous list have been integrated by now, so the list of remaining not-yet-integrated build fixes for 64bit out-of-source has become a lot shorter :-) . *Please note: Unit tests are currently broken for out-of-source builds .* Run cmake or develop.py configure with -DLL_TESTS:BOOL=FALSE or uncheck LL_TESTS in cmake-gui and reconfigure to disable them if you try building out-of-source. I've isolated the fixes for the remaining issues into repositories of their own (except for those that should be pulled together) and turned them into daggy fixes to allow for easy merging with as many revisions as possible. VWR-23047 (aka SNOW-512 / SNOW-287): PIC required for standalone * Fixed - On Review (fix at http://bitbucket.org/boroondas/vwr-23047) * Fixes for VWR-20911 and SNOW-748 are also in this repository * Fixes for all 3 issues should be pulled together to avoid breakage STORM-222 : expat.h not found on STANDALONE * Fixed in http://bitbucket.org/boroondas/storm-222 * Approved by Vadim ProductEngine VWR-23296 : missing LL_TEST conditions (i.e. SNOW-651 *+* SNOW-654 ) * The ability to turn off building and executing of /all/ unit tests is needed to work around other issues (which we'll have to fix later) * Fixed at http://bitbucket.org/boroondas/vwr-23296 * Should be easy to review (but note there are several changesets) STORM-275 (a.k.a. VWR-20893): "class Linux_x86_64Manifest" missing from viewer_manifest.py Breaking linux 64-bit build. * Fixed at http://bitbucket.org/boroondas/storm-275 Many thanks to Techwolf Lupindo, Aimee Trescothick and Robin Cornelius who made the original fixes. Cheers, Boroondas -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101007/1186f2e2/attachment.htm From suezanne at gmail.com Wed Oct 6 15:56:04 2010 From: suezanne at gmail.com (SuezanneC Baskerville) Date: Wed, 6 Oct 2010 17:56:04 -0500 Subject: [opensource-dev] How is the XUI part of the interface designed? Message-ID: There's a bunch of xml files in the Second Life program folder, for one example, floater_tools.xml, which is for the build editor. I know that we can modify these by editing the text files and restarting SL to see the changes we have made. Are they designed by creating text files from scratch or is there any kind of GUI design editor involved, or any other kind of aid or assistance that increases designer efficiency about repeated edit-text-restart-SL cycles? If so what it the GUI designer or design helper called? There used to be an "Edit UI" mode in 1.x viewers, that showed pixel offsets and I think allowed you to move interface elements while running SL. Is this mode still available in 2.x viewers? I wanting to see if the build editor can be made into a compact, long thin bar instead of big rectangle that is always in the way. -- v i r t u a l w o r l d e n t h u s i a s t -- http://www.google.com/profiles/s u e z a n n e -- -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101006/4b607dcd/attachment.htm From nexisentertainment at gmail.com Wed Oct 6 16:50:42 2010 From: nexisentertainment at gmail.com (Rob Nelson) Date: Wed, 06 Oct 2010 16:50:42 -0700 Subject: [opensource-dev] How is the XUI part of the interface designed? In-Reply-To: References: Message-ID: <4CAD0B52.4040003@gmail.com> There's a GUI editor, but last I checked, only LL employees and a select few really know how to use it; The manual is still in some LL wiki somewhere. Rob On 10/6/2010 3:56 PM, SuezanneC Baskerville wrote: > There's a bunch of xml files in the Second Life program folder, for > one example, floater_tools.xml, which is for the build editor. > > I know that we can modify these by editing the text files and > restarting SL to see the changes we have made. > > Are they designed by creating text files from scratch or is there any > kind of GUI design editor involved, or any other kind of aid or > assistance that increases designer efficiency about repeated > edit-text-restart-SL cycles? > > If so what it the GUI designer or design helper called? > > There used to be an "Edit UI" mode in 1.x viewers, that showed pixel > offsets and I think allowed you to move interface elements while > running SL. Is this mode still available in 2.x viewers? > > I wanting to see if the build editor can be made into a compact, long > thin bar instead of big rectangle that is always in the way. > > > > -- > v i r t u a l w o r l d e n t h u s i a s t > -- http://www.google.com/profiles/s u e z a n n e -- > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting privileges -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101006/0b100546/attachment.htm From robertltux at gmail.com Wed Oct 6 17:02:26 2010 From: robertltux at gmail.com (Robert Martin) Date: Wed, 6 Oct 2010 20:02:26 -0400 Subject: [opensource-dev] How is the XUI part of the interface designed? In-Reply-To: <4CAD0B52.4040003@gmail.com> References: <4CAD0B52.4040003@gmail.com> Message-ID: On Wed, Oct 6, 2010 at 7:50 PM, Rob Nelson wrote: > There's a GUI editor, but last I checked, only LL employees and a select few > really know how to use it;? The manual is still in some LL wiki somewhere. > > Rob oh really could Some Linden please put both on the public wiki somewhere?? -- Robert L Martin From richard at lindenlab.com Wed Oct 6 17:15:13 2010 From: richard at lindenlab.com (Richard Nelson) Date: Wed, 06 Oct 2010 17:15:13 -0700 Subject: [opensource-dev] How is the XUI part of the interface designed? In-Reply-To: References: <4CAD0B52.4040003@gmail.com> Message-ID: Unfortunately there is no GUI editor for UI layout. We currently hand-edit XML. A GUI editor is something I've wanted to do for a while, and the framework is mostly in place. But it is still a pretty large task to undertake. R. On Wed, 06 Oct 2010 17:02:26 -0700, Robert Martin wrote: > On Wed, Oct 6, 2010 at 7:50 PM, Rob Nelson > wrote: >> There's a GUI editor, but last I checked, only LL employees and a >> select few >> really know how to use it; The manual is still in some LL wiki >> somewhere. >> >> Rob > > oh really could Some Linden please put both on the public wiki > somewhere?? > -- Using Opera's revolutionary email client: http://www.opera.com/mail/ From q at lindenlab.com Wed Oct 6 19:30:51 2010 From: q at lindenlab.com (Kent Quirk (Q Linden)) Date: Wed, 6 Oct 2010 22:30:51 -0400 Subject: [opensource-dev] How is the XUI part of the interface designed? In-Reply-To: References: <4CAD0B52.4040003@gmail.com> Message-ID: There's no GUI editor. However, there is a nice little assistance tool. From the login screen ONLY, you can invoke the GUI Preview tool by hitting alt-ctrl-T (or cmd-ctrl-T on a Mac). It will bring up a dialog that you can use to display any of our dialog boxes, in two languages at once if you want. If you configure it, you can also have it open the dialog file in your text editor, and the "show rectangles" checkbox makes it easy to see which parts of the dialog have which names. If you edit a dialog, you can show and hide it, and it will reload. So you should be able to experiment with a layout rather easily; it's not a live graphical editor, but it makes it pretty easy to edit. Just realize the dialogs are not "live", and so sometimes things won't look right, or may have overlapping fields because only one of them is visible at any given time. Q On Oct 6, 2010, at 8:15 PM, Richard Nelson wrote: > Unfortunately there is no GUI editor for UI layout. We currently > hand-edit XML. A GUI editor is something I've wanted to do for a while, > and the framework is mostly in place. But it is still a pretty large task > to undertake. > > R. > > On Wed, 06 Oct 2010 17:02:26 -0700, Robert Martin > wrote: > >> On Wed, Oct 6, 2010 at 7:50 PM, Rob Nelson >> wrote: >>> There's a GUI editor, but last I checked, only LL employees and a >>> select few >>> really know how to use it; The manual is still in some LL wiki >>> somewhere. >>> >>> Rob >> >> oh really could Some Linden please put both on the public wiki >> somewhere?? >> > > > -- > Using Opera's revolutionary email client: http://www.opera.com/mail/ > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting privileges From suezanne at gmail.com Wed Oct 6 20:04:20 2010 From: suezanne at gmail.com (SuezanneC Baskerville) Date: Wed, 6 Oct 2010 22:04:20 -0500 Subject: [opensource-dev] opensource-dev Digest, Vol 9, Issue 27 In-Reply-To: References: Message-ID: Thanks, Kent, I'm glad I asked. The keystroke, by the way, appears to be Control Shift T, not Control Alt T, on my XP system running the Development Viewer. I'd like to replace the Focus, Move, Edit, Create, and Land buttons with a list, I suppose a combo_box, to save horizontal space. How does one do that? > > ------------------------------ > > Message: 7 > Date: Wed, 6 Oct 2010 22:30:51 -0400 > From: "Kent Quirk (Q Linden)" > Subject: Re: [opensource-dev] How is the XUI part of the interface > designed? > > There's no GUI editor. However, there is a nice little assistance tool. > From the login screen ONLY, you can invoke the GUI Preview tool by hitting > alt-ctrl-T (or cmd-ctrl-T on a Mac). It will bring up a dialog that you can > use to display any of our dialog boxes, in two languages at once if you > want. If you configure it, you can also have it open the dialog file in your > text editor, and the "show rectangles" checkbox makes it easy to see which > parts of the dialog have which names. > > If you edit a dialog, you can show and hide it, and it will reload. So you > should be able to experiment with a layout rather easily; it's not a live > graphical editor, but it makes it pretty easy to edit. Just realize the > dialogs are not "live", and so sometimes things won't look right, or may > have overlapping fields because only one of them is visible at any given > time. > > Q > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101006/34539aaf/attachment.htm From q at lindenlab.com Wed Oct 6 20:25:30 2010 From: q at lindenlab.com (Kent Quirk (Q Linden)) Date: Wed, 6 Oct 2010 23:25:30 -0400 Subject: [opensource-dev] opensource-dev Digest, Vol 9, Issue 27 In-Reply-To: References: Message-ID: <33A6ACA5-3C64-4ED5-BD29-EDB759C23541@lindenlab.com> That sort of thing is more involved, I'm afraid; you have to change the control. I don't know offhand if the XUI commit binding mechanism can be made to work with only XUI change -- I kind of doubt it. If not, you'll have to change the c++ event handlers from 4 individual event handlers to one that does all 4 things on change of the combo_box. It's probably worth some spelunking through XUI to see if there's an example of binding the combo box; if not, I bet one of the devs around here would help you write the C++ changes to make it work. Q On Oct 6, 2010, at 11:04 PM, SuezanneC Baskerville wrote: > Thanks, Kent, I'm glad I asked. > > The keystroke, by the way, appears to be Control Shift T, not Control Alt T, on my XP system running the Development Viewer. > > I'd like to replace the Focus, Move, Edit, Create, and Land buttons with a list, I suppose a combo_box, to save horizontal space. How does one do that? > > > ------------------------------ > > Message: 7 > Date: Wed, 6 Oct 2010 22:30:51 -0400 > From: "Kent Quirk (Q Linden)" > Subject: Re: [opensource-dev] How is the XUI part of the interface > designed? > > There's no GUI editor. However, there is a nice little assistance tool. From the login screen ONLY, you can invoke the GUI Preview tool by hitting alt-ctrl-T (or cmd-ctrl-T on a Mac). It will bring up a dialog that you can use to display any of our dialog boxes, in two languages at once if you want. If you configure it, you can also have it open the dialog file in your text editor, and the "show rectangles" checkbox makes it easy to see which parts of the dialog have which names. > > If you edit a dialog, you can show and hide it, and it will reload. So you should be able to experiment with a layout rather easily; it's not a live graphical editor, but it makes it pretty easy to edit. Just realize the dialogs are not "live", and so sometimes things won't look right, or may have overlapping fields because only one of them is visible at any given time. > > Q > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting privileges -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101006/36f24779/attachment.htm From garmin.kawaguichi at magalaxie.com Thu Oct 7 03:39:34 2010 From: garmin.kawaguichi at magalaxie.com (Garmin Kawaguichi) Date: Thu, 7 Oct 2010 12:39:34 +0200 Subject: [opensource-dev] opensource-dev Digest, Vol 9, Issue 27 References: Message-ID: >> The keystroke, by the way, appears to be Control Shift T, not Control Alt T, on my XP system running the Development Viewer. Note : there are 2 keystrokes : Ctrl - T = the XUI PREVIEW TOOL and Ctrl - Shift - T = TEST FLOATER (under SL 2.1.1 (207998)) GCI -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101007/698e4ada/attachment.htm From lee.ponzu at gmail.com Thu Oct 7 07:21:19 2010 From: lee.ponzu at gmail.com (Ponzu) Date: Thu, 7 Oct 2010 10:21:19 -0400 Subject: [opensource-dev] [JIRA] Updated: (SH-173) [VWR-22868] Development Viewer freezes just after startup / greedy with file handles / 'WARNING: ll_apr_warn_status: APR: Too many open files' In-Reply-To: <812188005.6728.1286426230615.JavaMail.j2ee-jira@linden-jiraprod01.managed.contegix.com> References: <812188005.6728.1286426230615.JavaMail.j2ee-jira@linden-jiraprod01.managed.contegix.com> Message-ID: On Thu, Oct 7, 2010 at 12:37 AM, Merov Linden (JIRA) < no-reply at secondlife.com> wrote: > > [ > https://jira.secondlife.com/browse/SH-173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel] > > Merov Linden updated SH-173: > ---------------------------- > > Status: Open (was: Resolved) > Resolution: (was: Fixed) > > Re-opening to port to 2.2.0 beta > > Hi, Merov. FYI, I have been running this in my build. I increased the limit to 64, but aside from that it works the same and seems to work fine. i am not trying to make more work for you, but I wanted to mention something you probably figured out already. This fix is a simple minded hack that does the job, but not very elegantly. You folks can figure out better than I what the right value should be (64 or 32 or other). Maybe the Server team will have an opinion. Maybe the value should be a settable parameter. Maybe it should be dynamic... In any case, I am glad it is fixed because it was making me crazy 8-) regards, lee -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101007/13f7c299/attachment.htm From oz at lindenlab.com Thu Oct 7 07:26:36 2010 From: oz at lindenlab.com (Oz Linden (Scott Lawrence)) Date: Thu, 07 Oct 2010 10:26:36 -0400 Subject: [opensource-dev] [JIRA] Updated: (SH-173) [VWR-22868] Development Viewer freezes just after startup / greedy with file handles / 'WARNING: ll_apr_warn_status: APR: Too many open files' In-Reply-To: References: <812188005.6728.1286426230615.JavaMail.j2ee-jira@linden-jiraprod01.managed.contegix.com> Message-ID: <4CADD89C.6070500@lindenlab.com> On 2010-10-07 10:21, Ponzu wrote: > > > On Thu, Oct 7, 2010 at 12:37 AM, Merov Linden (JIRA) > > wrote: > > > [ > https://jira.secondlife.com/browse/SH-173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel > ] > > Merov Linden updated SH-173: > ---------------------------- > > Status: Open (was: Resolved) > Resolution: (was: Fixed) > > Re-opening to port to 2.2.0 beta > > Hi, Merov. > > FYI, I have been running this in my build. I increased the limit to > 64, but aside from that it works the same and seems to work fine. > > i am not trying to make more work for you, but I wanted to mention > something you probably figured out already. This fix is a simple > minded hack that does the job, but not very elegantly. You folks can > figure out better than I what the right value should be (64 or 32 or > other). Maybe the Server team will have an opinion. Maybe the value > should be a settable parameter. Maybe it should be dynamic... > > In any case, I am glad it is fixed because it was making me crazy 8-) > Good to hear that the quick fix is stable for you (if it works with your latency, it probably works for everyone). The better fix is certainly something that will require some careful coordination with the server side and how those connections are managed, but that will not be forgotten (if only because it is likely that there are significant performance improvements available). -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101007/e85b7fec/attachment.htm From izzee at hotmail.co.uk Thu Oct 7 08:25:08 2010 From: izzee at hotmail.co.uk (izze euler) Date: Thu, 7 Oct 2010 15:25:08 +0000 Subject: [opensource-dev] Problem with displaying Arabic menu text in SL client In-Reply-To: References: , <4CAAFBCD.1070904@boroon.dasgupta.ch>, <-8408346637686232673@unknownmsgid>, , Message-ID: Would it be possible to create images containing the arabic text and displaying those instead of processing through Second Life's text engine? Izze Date: Tue, 5 Oct 2010 09:30:58 -0700 From: josh at lindenlab.com To: opensource-dev at lists.secondlife.com Subject: Re: [opensource-dev] Problem with displaying Arabic menu text in SL client On Tue, Oct 5, 2010 at 4:32 AM, izze euler wrote: Are you able to give an example on how to use this character within an XML file? Using that character won't have any effect. As Boroondas mentioned, Second Life's text engine is pretty basic and simply doesn't support:Right-to-Left scripts - typically this functionality is called "BiDi" since the direction actually changes within text strings for numbers, foreign words, etc. Contextual shaping (think: ligatures as a mandatory language feature) Combining characters/diacritics* (think: characters merge into single glyphs) Complex word breaking (for languages that don't use spaces)This is a big task, and (as Boroondas also mentioned) is probably best tackled by a thorough overhaul/replacement of SL's text rendering engine as Alissa Sabre attempted. Additionally, if we're talking about a localized version of the UI and not just rendering text content correctly, you'd also want to flip the X coordinates for some (but not all) UI layout if the app was running with a UI language that was RTL, which would require changes to the XUI engine and some of the controls. (Since, ideally you don't have to touch all of the control rects in all of the XUI files) -- Josh * I look forward to the day when someone writes a text engine that handles the character combining logic for classical Mayan. _______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101007/c20e6d9a/attachment-0001.htm From josh at lindenlab.com Thu Oct 7 09:28:08 2010 From: josh at lindenlab.com (Joshua Bell) Date: Thu, 7 Oct 2010 09:28:08 -0700 Subject: [opensource-dev] Problem with displaying Arabic menu text in SL client In-Reply-To: References: <4CAAFBCD.1070904@boroon.dasgupta.ch> <-8408346637686232673@unknownmsgid> Message-ID: On Thu, Oct 7, 2010 at 8:25 AM, izze euler wrote: > Would it be possible to create images containing the arabic text and > displaying those instead of processing through Second Life's text engine? > > Possible? Yes, it's just software. Practical? No. Given the amount of text in the UI and the flexibility of the UI to scale text, render text with different colors, wrap text messages, and (of course) the need to handle strings that aren't built into the viewer - localized strings provided by server messages, text chat, etc - the work involved would be much larger than integrating a new text engine. The ongoing maintenance costs would be tremendous. Any any hack suggested to reduce the cost turns it either into a non-general solution (i.e. something we wouldn't want to ship/maintain) or approaches the general solution (e.g. render composed strings into images on the fly... by integrating a new text engine) -- Josh -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101007/3c68120f/attachment.htm From javajoint at gmail.com Thu Oct 7 09:45:57 2010 From: javajoint at gmail.com (Daniel Smith) Date: Thu, 7 Oct 2010 09:45:57 -0700 Subject: [opensource-dev] goodbye snowstorm Message-ID: In some small way, I've contributed some ideas (but not code) to SnowStorm. I do hope SnowStorm, and the 2.x codebase, prosper and find greater acceptance. However, I am a tech/developer/VW enthusiast, and will be focusing my energy elsewhere. I dont like how Linden Lab is treating the Education and Non-Profit communities (ending their 50% discount). I cannot, in good conscience, contribute to the efforts of a company that treats its customers that way. My efforts will go towards the development of OpenSim, OpenSim grids, Unity, and possibly the 1.x and/or 2.x codebases in the TPV sphere. It may well be that I receive no compensation for those efforts, but I will feel much better about participating in that community. Linden Lab cannot treat customers the way it has, and expect to outsource some of their development efforts for free. Daniel Smith -- Daniel Smith - Sonoma County, California http://daniel.org/resume -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101007/2a3f815a/attachment.htm From javajoint at gmail.com Thu Oct 7 09:45:57 2010 From: javajoint at gmail.com (Daniel Smith) Date: Thu, 7 Oct 2010 09:45:57 -0700 Subject: [opensource-dev] goodbye snowstorm Message-ID: In some small way, I've contributed some ideas (but not code) to SnowStorm. I do hope SnowStorm, and the 2.x codebase, prosper and find greater acceptance. However, I am a tech/developer/VW enthusiast, and will be focusing my energy elsewhere. I dont like how Linden Lab is treating the Education and Non-Profit communities (ending their 50% discount). I cannot, in good conscience, contribute to the efforts of a company that treats its customers that way. My efforts will go towards the development of OpenSim, OpenSim grids, Unity, and possibly the 1.x and/or 2.x codebases in the TPV sphere. It may well be that I receive no compensation for those efforts, but I will feel much better about participating in that community. Linden Lab cannot treat customers the way it has, and expect to outsource some of their development efforts for free. Daniel Smith -- Daniel Smith - Sonoma County, California http://daniel.org/resume -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101007/2a3f815a/attachment-0001.htm From dzonatas at gmail.com Thu Oct 7 10:34:36 2010 From: dzonatas at gmail.com (Dzonatas Sol) Date: Thu, 07 Oct 2010 10:34:36 -0700 Subject: [opensource-dev] Problem with displaying Arabic menu text in SL client In-Reply-To: References: , <4CAAFBCD.1070904@boroon.dasgupta.ch>, <-8408346637686232673@unknownmsgid>, , Message-ID: <4CAE04AC.6080405@gmail.com> Have you looked at Icesphere in order to render Arabic text? These mainly work in text chat, as the chat gets automatically translated and rendered properly. Since the windows are detached in Icesphere, the menu text would be based upon your system settings. Let me know if you have any more questions. http://icyspherical.blogspot.com/ Icesphere uses SNOW-375 as an interface, which probably is related to your idea of a different text engine. It's more of an API than a text engine. izze euler wrote: > Would it be possible to create images containing the arabic text and > displaying those instead of processing through Second Life's text engine? > > Izze > > ------------------------------------------------------------------------ > Date: Tue, 5 Oct 2010 09:30:58 -0700 > From: josh at lindenlab.com > To: opensource-dev at lists.secondlife.com > Subject: Re: [opensource-dev] Problem with displaying Arabic menu text > in SL client > > > On Tue, Oct 5, 2010 at 4:32 AM, izze euler > wrote: > > Are you able to give an example on how to use this character > within an XML file? > > > Using that character won't have any effect. As Boroondas mentioned, > Second Life's text engine is pretty basic and simply doesn't support: > > * Right-to-Left scripts - typically this functionality is called > "BiDi" since the direction actually changes within text strings > for numbers, foreign words, etc. > * Contextual shaping (think: ligatures as a mandatory language > feature) > * Combining characters/diacritics* (think: characters merge into > single glyphs) > * Complex word breaking (for languages that don't use spaces) > > This is a big task, and (as Boroondas also mentioned) is probably best > tackled by a thorough overhaul/replacement of SL's text rendering > engine as Alissa Sabre attempted. > > Additionally, if we're talking about a localized version of the UI and > not just rendering text content correctly, you'd also want to flip the > X coordinates for some (but not all) UI layout if the app was running > with a UI language that was RTL, which would require changes to the > XUI engine and some of the controls. (Since, ideally you don't have to > touch all of the control rects in all of the XUI files) > > -- Josh > > * I look forward to the day when someone writes a text engine that > handles the character combining logic for classical Mayan. > > _______________________________________________ Policies and > (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the > policies before posting to keep unmoderated posting privileges > ------------------------------------------------------------------------ > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting privileges -- --- https://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering, Virtual Reality, Consultant From esbee at lindenlab.com Thu Oct 7 10:55:38 2010 From: esbee at lindenlab.com (Sarah (Esbee) Hutchinson) Date: Thu, 7 Oct 2010 13:55:38 -0400 Subject: [opensource-dev] TIME CHANGE - Snowstorm Daily Scrum - Friday, October 8, 2010 Message-ID: Due to a company meeting tomorrow scheduled at the same time, we've moved the Snowstorm Team Daily Scrum time to 11:30am PT (for this Friday only). You can view our updated calendar, here: https://www.google.com/calendar/hosted/lindenlab.com/embed?src=lindenlab.com_k0e2g2gmqrhm0esbrh31f0qbac at group.calendar.google.com&ctz=America/Los_Angeles&gsessionid=OK - Esbee -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101007/bebc61e1/attachment.htm From lee.ponzu at gmail.com Thu Oct 7 11:22:25 2010 From: lee.ponzu at gmail.com (Ponzu) Date: Thu, 7 Oct 2010 14:22:25 -0400 Subject: [opensource-dev] Problem with displaying Arabic menu text in SL client In-Reply-To: <4CAE04AC.6080405@gmail.com> References: <4CAAFBCD.1070904@boroon.dasgupta.ch> <-8408346637686232673@unknownmsgid> <4CAE04AC.6080405@gmail.com> Message-ID: Pass the text to Google translate, and then display the results?? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101007/0fdd3716/attachment.htm From akanevsky at productengine.com Thu Oct 7 11:44:05 2010 From: akanevsky at productengine.com (Anya Kanevsky) Date: Thu, 7 Oct 2010 11:44:05 -0700 Subject: [opensource-dev] Daily Scrum Summary - Thursday, October 7 Message-ID: Date: Thu Oct 7 == GENERAL NOTES == * Merge Monkey of the Day: Merov ... again == DAILY SCRUM == === Merov Linden=== PAST * STORM-306: Lots and lots of tests bringing the faulty changes in and cornering the 1 line culprit... Pushed a fix on my branch. Got it reviewed by Q. Pulled into beta (tested locally and it fixes the problem). * Merge monkey on viewer-development and viewer-beta FUTURE * Beta monitoring (merges, try to identify bugs I can contribute to) * STORM-137 : FMOD issue: fix upload issue with Brad. Hopefully, the rest will be easy. * STORM-105 : Perf decompression: put new data out, check the work done by opensource-dev community on similar tests. IMPEDIMENTS * Kakadu license upgrade ==Oz Linden== PAST * Office Hour - mostly about TPV Policy changes ** Follow-up: will be posting archival versions of TPVP on the wiki * Worked on updates to TPV Directory processes * Updated Snowstorm process descriptions * Corrected some more of the references to where to get code FUTURE * Prep a budget proposal for open build service & code review system * Pester Team Chopper about opening up autobuild IMPEDIMENTS * none === Q Linden=== PAST * HR (annual reviews) - not quite done * Q4 / 2011 planning - not quite done (sigh) * Explaining Snowstorm process FUTURE * Finish HR * Q4 / 2011 planning * Process work * Unit test working IMPEDIMENTS * None === Esbee Linden==== PAST * VWR triage * Q4+ planning * Systems requirements research * Reviewed versions, "viewer-development bug queue and viewer 2.2.0 Beta" and prioritized all bugs FUTURE * VWR triage * Viewer release process review * Review Snowstorm Jira tickets * Viewer roadmap planning * Systems requirements research * Q4+ planning * End of year review discussion with Q IMPEDIMENTS * None === Paul ProductEngine=== PAST: * STROM-263 Cog button in lower-left of sidebar panel does not close popup menu on second click ** Finally fixed and put in bitbucket. for real this time. * STORM-302 Parcel lists scroll bar overlaps with other components if panel is undocked ** Investigating. Rough estimate ~ 3-4 hours FUTURE: * STORM-302 Parcel lists scroll bar overlaps with other components if panel is undocked IMPEDIMENTS: *none === Seth Productengine === PAST: * BUG (STORM-305) Undocked minimized SP tabs are restored after re-login **Fix ready but it may cause inconsistent floater behavior. **Waiting for clarifications in JIRA. *(STORM-300) Minimized undocked tab is shown over restored another undocked tab ** Investigated. Looks like expected behavior. Asked Esbee in JIRA. * BUG (STORM-190) [TRUNCATION] many langs -- "Next Owner:" in floatear_bulk_perms.xml ** Returned "Fixed" resolution. Reopened by mistake. * BUG (STORM-296) The cursor look so like if an user is able to add non - landmark into Favorites folder ** Investigating. FUTURE: * BUG (STORM-296) The cursor look so like if an user is able to add non - landmark into Favorites folder ** Estimated: 6 hours. * Pick other issues from sprint 5 or beta 2.2.0. IMPEDIMENTS: * STORM-316 * STORM-305 * STORM-300 === Andrew Productengine === PAST: * Bug STORM-299 (World map floater opens instead Mini-map if double-click on minimized Mini-map) ** Fixed and sent for integration. * Bug STORM-187 (Opening the sidebar shrinks a wide chat text window, but closing doesn't restore it) ** Fixed and sent for review. * Bug STORM-301 (Camera view remains on Edit Appearance mode after undocked 'My Appearance' tab was minimized while being in 'Edit Outfit' mode) ** Started investigating. Estimate - 4 hours. FUTURE: * STORM-301 (Camera view remains on Edit Appearance mode after undocked 'My Appearance' tab was minimized while being in 'Edit Outfit' mode). IMPEDIMENTS: * none === Vadim Productengine === * OOO - Vacation. Will be back to office on Oct, 11th. === Andrey Productengine === PAST: * regression testing of changes in r210917-211218 on Windows and Linux * reported STORM-345, 347, 348 FUTURE: * beta 3 regression testing IMPEDIMENTS: * none === Grumpity ProductEngine === PAST * QA access issues * STORM-315: Esbee will split into tasks/stories * STORM-316: Esbee to make decision on desired behavior * STORM-295/325: transplanted to beta * beta build to PEQA for testing overnight * take over daily summary dooties FUTURE: * STORM-305, STORM-316, STORM-300 * QA synchup IMPEDIMENTS: * none From hitomi.tiponi at yahoo.co.uk Thu Oct 7 11:45:02 2010 From: hitomi.tiponi at yahoo.co.uk (Hitomi Tiponi) Date: Thu, 7 Oct 2010 19:45:02 +0100 (BST) Subject: [opensource-dev] How is the XUI part of the interface designed? Message-ID: <558092.76095.qm@web23906.mail.ird.yahoo.com> Thanks for that Q - hadn't spotted that. I've been torturing the xml to within an inch of it's life with StarLight, including having completely re-done the profile panels. I think I have now learnt most of what can and can't be done with it -so if anybody wants to ask any questions I will be happy to try and help. Largely you can do quite a few things as long as you remember the elements have to be somewhere in that particular floater/widget, and you don't try and be too ambitious with it - and you may find that the layout elements can seem like a dark art at times as they often don't seem to work as you would expect. Hopefully LL will allow an easier method for incorporating skinning and xml changes that residents develop as add-ons - the way that Kirstens S20 (based on Viewer 2) works makes it a lot easier, and reduces the need for regular updates. And in case you are wondering the standards that LL use for laying out the xml are dependent on who wrote it - but it does seem somewhat better in that regard than Viewer 1! >There's no GUI editor. However, there is a nice little assistance tool. > From the login screen ONLY, you can invoke the GUI Preview tool by hitting >alt-ctrl-T > (or cmd-ctrl-T on a Mac). It will bring up a dialog that you can use to >display any of our > dialog boxes, in two languages at once if you want. If you configure it, you >can also have > it open the dialog file in your text editor, and the "show rectangles" >checkbox makes it > easy to see which parts of the dialog have which names. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101007/96070376/attachment-0001.htm From angel_of_crimson at hotmail.com Thu Oct 7 13:39:35 2010 From: angel_of_crimson at hotmail.com (Erin Mallory) Date: Thu, 7 Oct 2010 16:39:35 -0400 Subject: [opensource-dev] userstory: VWR-23337 Message-ID: As a user, especially one tired of dealing with support constantly, I really want to see VWR-23337 added to snowstorm backlog please! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101007/3e32478c/attachment.htm From brad at lindenlab.com Thu Oct 7 14:00:25 2010 From: brad at lindenlab.com (Brad Kittenbrink (Brad Linden)) Date: Thu, 7 Oct 2010 14:00:25 -0700 Subject: [opensource-dev] Where oh where has my rendering gone? In-Reply-To: References: <86DC83B1-9F3E-4576-97ED-A8E5F2A8D0CF@lindenlab.com> Message-ID: On Wed, Oct 6, 2010 at 8:57 AM, Joshua Bell wrote: > On Tue, Oct 5, 2010 at 7:29 PM, Kent Quirk (Q Linden) wrote: > >> Well, it's not quite like that. To pull this off, you'd have to take >> everywhere we set a color, and set it instead to its equivalent black and >> white value (there's a formula that's traditionally used, although there's >> no "correct" way to do it: Y = 0.3*R + 0.59*G + 0.11*B). You *might* be >> able to get away with modifying the LLColor4 constructor to do this, but >> it's probably going to have some surprising results when you assign a value >> and don't get the same value back. >> > > How about post-processing every frame before the final swapBuffers call? > That seems like it could be done with a shader and only touching a small > amount of code. This would affect the UI as well as the world viewport, > however, without some significant refactoring, but given that we already > have some post-processing effects (glow, etc) perhaps there's already a good > spot to slot this in? > > (Don't trust me too much, though, as I've never written a non-trivial > shader and have never touched the viewer's render pipeline!) > > Of course, once you have monochrome output, you could tweak the shader and > get sepia-toned rendering. Old-timey SL, anyone? > > -- Josh > > This is definitely the approach I'd recommend. To do this you'll want to reenable the old postprocessing filters which were part of a pre-release version of windlight but got disabled. llrender/llpostprocess.{h,cpp} newview/llfloaterpostprocess.{h,cpp} newview/app_settings/shader/class{1,2}/effects/*.glsl Most of this legacy code is probably horribly incompatible with the current renderer (particularly since deferred rendering has redesigned the way the renderer is organized), but at least it's a place to start looking... -Brad -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101007/30919687/attachment.htm From nexisentertainment at gmail.com Thu Oct 7 14:50:00 2010 From: nexisentertainment at gmail.com (Rob Nelson) Date: Thu, 07 Oct 2010 14:50:00 -0700 Subject: [opensource-dev] Where oh where has my rendering gone? In-Reply-To: References: <86DC83B1-9F3E-4576-97ED-A8E5F2A8D0CF@lindenlab.com> Message-ID: <4CAE4088.4090306@gmail.com> By the way, what happened to the rest of windlight that was supposed to be implemented? The volumetric clouds, server-side settings sharing, etc? Is it possible for a dev to get approval to release the viewer-side half-implemented versions of those so the community can finish them up? Rob On 10/7/2010 2:00 PM, Brad Kittenbrink (Brad Linden) wrote: > > > On Wed, Oct 6, 2010 at 8:57 AM, Joshua Bell > wrote: > > On Tue, Oct 5, 2010 at 7:29 PM, Kent Quirk (Q Linden) > > wrote: > > Well, it's not quite like that. To pull this off, you'd have > to take everywhere we set a color, and set it instead to its > equivalent black and white value (there's a formula that's > traditionally used, although there's no "correct" way to do > it: Y = 0.3*R + 0.59*G + 0.11*B). You *might* be able to get > away with modifying the LLColor4 constructor to do this, but > it's probably going to have some surprising results when you > assign a value and don't get the same value back. > > > How about post-processing every frame before the final swapBuffers > call? That seems like it could be done with a shader and only > touching a small amount of code. This would affect the UI as well > as the world viewport, however, without some significant > refactoring, but given that we already have some post-processing > effects (glow, etc) perhaps there's already a good spot to slot > this in? > > (Don't trust me too much, though, as I've never written a > non-trivial shader and have never touched the viewer's render > pipeline!) > > Of course, once you have monochrome output, you could tweak the > shader and get sepia-toned rendering. Old-timey SL, anyone? > > -- Josh > > > This is definitely the approach I'd recommend. > > To do this you'll want to reenable the old postprocessing filters > which were part of a pre-release version of windlight but got disabled. > > llrender/llpostprocess.{h,cpp} > newview/llfloaterpostprocess.{h,cpp} > newview/app_settings/shader/class{1,2}/effects/*.glsl > > Most of this legacy code is probably horribly incompatible with the > current renderer (particularly since deferred rendering has redesigned > the way the renderer is organized), but at least it's a place to start > looking... > > -Brad > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting privileges -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101007/59c60e0f/attachment.htm From wolfpup67 at earthlink.net Thu Oct 7 15:33:32 2010 From: wolfpup67 at earthlink.net (WolfPup Lowenhar) Date: Thu, 7 Oct 2010 18:33:32 -0400 Subject: [opensource-dev] Where oh where has my rendering gone? In-Reply-To: References: <86DC83B1-9F3E-4576-97ED-A8E5F2A8D0CF@lindenlab.com> Message-ID: <000601cb666f$ac46b870$04d42950$@net> Legacy code?.... woops. me remembers removing some of that type of code while working on a new feature for chat/IM logging (which should be coming as soon as lldir_mac get cleaned up). From: opensource-dev-bounces at lists.secondlife.com [mailto:opensource-dev-bounces at lists.secondlife.com] On Behalf Of Brad Kittenbrink (Brad Linden) Sent: Thursday, October 07, 2010 5:00 PM To: Joshua Bell Cc: opensource-dev at lists.secondlife.com Subject: Re: [opensource-dev] Where oh where has my rendering gone? On Wed, Oct 6, 2010 at 8:57 AM, Joshua Bell wrote: On Tue, Oct 5, 2010 at 7:29 PM, Kent Quirk (Q Linden) wrote: Well, it's not quite like that. To pull this off, you'd have to take everywhere we set a color, and set it instead to its equivalent black and white value (there's a formula that's traditionally used, although there's no "correct" way to do it: Y = 0.3*R + 0.59*G + 0.11*B). You *might* be able to get away with modifying the LLColor4 constructor to do this, but it's probably going to have some surprising results when you assign a value and don't get the same value back. How about post-processing every frame before the final swapBuffers call? That seems like it could be done with a shader and only touching a small amount of code. This would affect the UI as well as the world viewport, however, without some significant refactoring, but given that we already have some post-processing effects (glow, etc) perhaps there's already a good spot to slot this in? (Don't trust me too much, though, as I've never written a non-trivial shader and have never touched the viewer's render pipeline!) Of course, once you have monochrome output, you could tweak the shader and get sepia-toned rendering. Old-timey SL, anyone? -- Josh This is definitely the approach I'd recommend. To do this you'll want to reenable the old postprocessing filters which were part of a pre-release version of windlight but got disabled. llrender/llpostprocess.{h,cpp} newview/llfloaterpostprocess.{h,cpp} newview/app_settings/shader/class{1,2}/effects/*.glsl Most of this legacy code is probably horribly incompatible with the current renderer (particularly since deferred rendering has redesigned the way the renderer is organized), but at least it's a place to start looking... -Brad _____ No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1120 / Virus Database: 422/3182 - Release Date: 10/07/10 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101007/431c9027/attachment-0001.htm From suezanne at gmail.com Thu Oct 7 16:50:52 2010 From: suezanne at gmail.com (SuezanneC Baskerville) Date: Thu, 7 Oct 2010 18:50:52 -0500 Subject: [opensource-dev] userstory: VWR-23337 (Erin Mallory) opensource-dev Digest, Vol 9, Issue 30 Message-ID: Presumably "VWR-23337" should be VWR-2337 "sl crash kills internet connection" On Thu, Oct 7, 2010 at 5:33 PM, wrote: > > Today's Topics: > > ? 1. userstory: VWR-23337 (Erin Mallory) -- v i r t u a l?? w o r l d?? e n t h u s i a s t -- http://www.google.com/profiles/s u e z a n n e -- From angel_of_crimson at hotmail.com Thu Oct 7 18:15:50 2010 From: angel_of_crimson at hotmail.com (Erin Mallory) Date: Thu, 7 Oct 2010 21:15:50 -0400 Subject: [opensource-dev] userstory: VWR-23337 (Erin Mallory) opensource-dev Digest, Vol 9, Issue 30 In-Reply-To: References: Message-ID: nope. 23337 not 2337 > Date: Thu, 7 Oct 2010 18:50:52 -0500 > From: suezanne at gmail.com > To: opensource-dev at lists.secondlife.com > Subject: Re: [opensource-dev] userstory: VWR-23337 (Erin Mallory) opensource-dev Digest, Vol 9, Issue 30 > > Presumably "VWR-23337" should be VWR-2337 "sl crash kills internet connection" > > > On Thu, Oct 7, 2010 at 5:33 PM, > wrote: > > > > Today's Topics: > > > > 1. userstory: VWR-23337 (Erin Mallory) > > -- > v i r t u a l w o r l d e n t h u s i a s t > -- http://www.google.com/profiles/s u e z a n n e -- > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting privileges -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101007/996b38b2/attachment.htm From angel_of_crimson at hotmail.com Fri Oct 8 11:02:19 2010 From: angel_of_crimson at hotmail.com (Erin Mallory) Date: Fri, 8 Oct 2010 14:02:19 -0400 Subject: [opensource-dev] tos acceptance issues Message-ID: As a user, it would be nice if the 2.x versions of SL would allow ALL accounts to accept the new terms of service instead of denying that option to all/some of them. Depending on the build, some versions of 2.x do not allow any accounts to accept tos even after cancel and reattempt. Some allow only some accounts to do so. this is like the third time this bug has resurfaced. can we please fix it so everyone can log in? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101008/8e24b75a/attachment.htm From stickman at gmail.com Fri Oct 8 11:08:36 2010 From: stickman at gmail.com (Stickman) Date: Fri, 8 Oct 2010 11:08:36 -0700 Subject: [opensource-dev] tos acceptance issues In-Reply-To: References: Message-ID: > As a user, it would be nice if the 2.x versions of SL would allow ALL > accounts to accept the new terms of service instead of denying that option > to all/some of them. I also noticed that clicking on links in the TOS and using the mousewheel to scroll wasn't working. I _think_ I was using 2.x at the time, but I don't totally recall. Stickman From bryon at slearth.com Fri Oct 8 14:00:24 2010 From: bryon at slearth.com (Bryon Ruxton) Date: Fri, 08 Oct 2010 14:00:24 -0700 Subject: [opensource-dev] Jira Issue Resolution Issue Message-ID: As a user I would like to be able to reopen Jira issues wrongly closed by ignorant people who can't read, creating havok. Like this one there: Stone Tremont added a comment - 08/Oct/10 2:17 AM This is not a bug because you do not pay prims, avatars are payed via whole objects. This should be a feature request. I have a way to set different prices for variations in vendors, you just need to make a more advanced, intuitive script like mine. https://jira.secondlife.com/browse/VWR-3048 Please reopen this issue! As per Gigs Taggart's comment, its used to work.. It you are going to allow any kiddo to close issues, the same should true for reopening them, or it doesn't make any sense at all. From angel_of_crimson at hotmail.com Fri Oct 8 14:57:40 2010 From: angel_of_crimson at hotmail.com (Erin Mallory) Date: Fri, 8 Oct 2010 17:57:40 -0400 Subject: [opensource-dev] Jira Issue Resolution Issue In-Reply-To: References: Message-ID: yes we used to have the ability to reopen. and the person in question has closed allot. so have others. its like they dont READ the issue before closing. to the point i've considered aring them for a form of griefing > Date: Fri, 8 Oct 2010 14:00:24 -0700 > From: bryon at slearth.com > To: opensource-dev at lists.secondlife.com > Subject: [opensource-dev] Jira Issue Resolution Issue > > As a user I would like to be able to reopen Jira issues wrongly closed by > ignorant people who can't read, creating havok. Like this one there: > > Stone Tremont added a comment - 08/Oct/10 2:17 AM > This is not a bug because you do not pay prims, avatars are payed via whole > objects. This should be a feature request. I have a way to set different > prices for variations in vendors, you just need to make a more advanced, > intuitive script like mine. > > https://jira.secondlife.com/browse/VWR-3048 > > Please reopen this issue! As per Gigs Taggart's comment, its used to work.. > It you are going to allow any kiddo to close issues, the same should true > for reopening them, or it doesn't make any sense at all. > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting privileges -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101008/9e5a7e80/attachment.htm From akanevsky at productengine.com Fri Oct 8 16:13:19 2010 From: akanevsky at productengine.com (Anya Kanevsky) Date: Fri, 8 Oct 2010 16:13:19 -0700 Subject: [opensource-dev] Daily Scrum Summary - Friday, October 8 Message-ID: Date: Fr Oct 7 == GENERAL NOTES == * Merge Monkey of the Day: Merov ... again == DAILY SCRUM == === Merov Linden=== PAST * STORM-306: Lots and lots of tests bringing the faulty changes in and cornering the 1 line culprit... Pushed a fix on my branch. Got it reviewed by Q. Pulled into beta (tested locally and it fixes the problem). * Merge monkey on viewer-development and viewer-beta FUTURE * Beta monitoring (merges, try to identify bugs I can contribute to) * STORM-137 : FMOD issue: fix upload issue with Brad. Hopefully, the rest will be easy. * STORM-105 : Perf decompression: put new data out, check the work done by opensource-dev community on similar tests. IMPEDIMENTS * Kakadu license upgrade ==Oz Linden== * TBD === Q Linden=== * TBD === Esbee Linden==== PAST * VWR triage * Q4+ planning * Systems requirements research * Reviewed versions, "viewer-development bug queue and viewer 2.2.0 Beta" and prioritized all bugs FUTURE * VWR triage * Viewer release process review * Review Snowstorm Jira tickets * Viewer roadmap planning * Systems requirements research * Q4+ planning * End of year review discussion with Q IMPEDIMENTS * None === Paul ProductEngine=== PAST: * STORM-302 Parcel lists scroll bar overlaps with other components if panel is undocked ** Fixed and sent for a review * STORM-211 Fade timer is reset for all toasts displayed in the notificaitons channel ** Investigating. Estimate ~6-8 hours FUTURE: * STORM-211 Fade timer is reset for all toasts displayed in the notifications channel IMPEDIMENTS: * none === Seth Productengine === PAST: * BUG (STORM-296) The cursor look so like if an user is able to add non - landmark into Favorites folder ** Fixed. * BUG (STORM-289) Internal browser navigation bar disappears after minimize/restore ** Investigating. Issue caused by resizing panels in layout stack. FUTURE: * BUG (STORM-289) Internal browser navigation bar disappears after minimize/restore ** Estimated: 8 hours. IMPEDIMENTS: * none === Andrew Productengine === PAST: * Bug STORM-301 (Camera view remains on Edit Appearance mode after undocked 'My Appearance' tab was minimized while being in 'Edit Outfit' mode) ** Investigated and discussed with Seth. This ticket turned out to be not as easy as it seemed, so increased estimate and started working on issue from Sprint 5. * Major bug STORM-313 (Build parcel property is displayed incorrectly) ** Investigated. Estimate- 5 hours. FUTURE: * STORM-313 (Build parcel property is displayed incorrectly). IMPEDIMENTS: * none * From Friday's report: ** Looked through STORM-182 (Uninstalling a beta client can result in all chatlogs being deleted as well if logging is left to default location)- it doesn't seem to be viewer issue- perhaps it should be on some team that is working on installer, or if just behaviour (not code) should be investigated and discussed, perhaps this issue is not for devs. === Vadim Productengine === * OOO - Vacation. Will be back to office on Oct, 11th. === Andrey Productengine === PAST: * smoke and regression testing of 2.2.0 Beta 3 on Windows and Mac, see DRTVWR-9 for details * verified tickets linked to DRTVWR-7 on Beta 3 build FUTURE: * return to viewer-development builds testing IMPEDIMENTS: * none === Grumpity === PAST * Process discussions * weekly QA synchup FUTURE: * QA synch notes & followup * need to clarify beta process * take STORM-315 from Esbee and split it. IMPEDIMENTS: * none From merov at lindenlab.com Fri Oct 8 19:31:32 2010 From: merov at lindenlab.com (Philippe (Merov) Bossut) Date: Fri, 8 Oct 2010 19:31:32 -0700 Subject: [opensource-dev] Fix for "Attachments displayed in mouselook" bug Message-ID: Hi guys, I need to go home and can't clean up the whole hg/JIRA now but, for you at home who can build and can test, I think I've a neat one liner to fix that one: diff -r b0cd7e150009 indra/newview/pipeline.cpp --- a/indra/newview/pipeline.cpp Wed Oct 06 19:57:45 2010 -0700 +++ b/indra/newview/pipeline.cpp Fri Oct 08 19:25:41 2010 -0700 @@ -9049,7 +9049,7 @@ BOOL LLPipeline::hasRenderType(const U32 type) const { - return mRenderTypeEnabled[type]; + return (type != 0) && mRenderTypeEnabled[type]; } Long story as to why that works but it does... at least in the tests I did... Feedback (good or bad) appreciated. Cheers, - Merov -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101008/ae660790/attachment.htm From lee.ponzu at gmail.com Sat Oct 9 07:58:19 2010 From: lee.ponzu at gmail.com (Ponzu) Date: Sat, 9 Oct 2010 10:58:19 -0400 Subject: [opensource-dev] Fix for "Attachments displayed in mouselook" bug In-Reply-To: References: Message-ID: Putting in now. Funny thing is I *like* seeing my hair and glasses when I am in Mouselook. it makes me feel like I am really looking out of my avatars eyes. Maybe it needs to be an option 8-) On Fri, Oct 8, 2010 at 10:31 PM, Philippe (Merov) Bossut < merov at lindenlab.com> wrote: > return (type != 0) && mRenderTypeEnabled[type]; -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101009/b8516ac7/attachment.htm From lee.ponzu at gmail.com Sat Oct 9 08:07:05 2010 From: lee.ponzu at gmail.com (Ponzu) Date: Sat, 9 Oct 2010 11:07:05 -0400 Subject: [opensource-dev] Fix for "Attachments displayed in mouselook" bug In-Reply-To: References: Message-ID: Photo attached, from behind my eyes 8-) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101009/314c0555/attachment-0001.htm -------------- next part -------------- A non-text attachment was scrubbed... Name: Inside Ponzu.jpg Type: image/jpeg Size: 81260 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101009/314c0555/attachment-0001.jpg From secret.argent at gmail.com Sat Oct 9 09:19:43 2010 From: secret.argent at gmail.com (Argent) Date: Sat, 9 Oct 2010 11:19:43 -0500 Subject: [opensource-dev] Fix for "Attachments displayed in mouselook" bug In-Reply-To: References: Message-ID: I don't normally gripe about stuff like this, but somehow this one triggered my twitches from 20 years of supporting PhD programmers. Brilliant guys, but sometimes it's SO hard to figure out what they're trying to do. This is a case where the trinary "?:" operator is much more readable and understandable. (type == 0) ? FALSE : mRenderTypeEnabled[type]; But even better: if(type == 0) return FALSE; // explain why here .. eg "in this context we are always rendering attached prims on the head when blah blah..." else return mRenderTypeEnabled[type]; From zabb65 at gmail.com Sat Oct 9 11:59:18 2010 From: zabb65 at gmail.com (Zabb65) Date: Sat, 9 Oct 2010 14:59:18 -0400 Subject: [opensource-dev] Fix for "Attachments displayed in mouselook" bug In-Reply-To: References: Message-ID: I tend to agree with Argent on this, it should have a comment if there is a hack in place to make it all function. I ran it through hg blame and it claims that revision 11977 was when a big block in pipeline.cpp changed 11977: BOOL LLPipeline::hasRenderType(const U32 type) const 11977: { 11977: return mRenderTypeEnabled[type]; 11977: } previously this function was in a header and looked like BOOL hasRenderType(const U32 type) const { return (type && (mRenderTypeMask & (1< wrote: > I don't normally gripe about stuff like this, but somehow this one > triggered my twitches from 20 years of supporting PhD programmers. > Brilliant guys, but sometimes it's SO hard to figure out what they're > trying to do. > > This is a case where the trinary "?:" operator is much more readable > and understandable. > > (type == 0) ? FALSE : mRenderTypeEnabled[type]; > > But even better: > > if(type == 0) > ?return FALSE; // explain why here .. eg "in this context we are > always rendering attached prims on the head when blah blah..." > else > ?return mRenderTypeEnabled[type]; > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting privileges > From sllists at boroon.dasgupta.ch Sat Oct 9 13:50:53 2010 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Sat, 09 Oct 2010 22:50:53 +0200 Subject: [opensource-dev] Fix for "Attachments displayed in mouselook" bug In-Reply-To: References: Message-ID: <4CB0D5AD.9060203@boroon.dasgupta.ch> On 10/09/2010 08:59 PM, Zabb65 wrote: > I ran it through hg blame and it claims that revision 11977 was when a > big block in pipeline.cpp changed > [...] > http://hg.secondlife.com/viewer-development/changeset/c09f9bcd9d20 > however does not show this, and I suspect that it is heavily truncated > on bitbucket, even though the full patch can be pulled from the hg > repository itself. I can't see it in the raw changeset, either. Probably |hg blame| got confused by the huge merges and them being backed out and un-backed out ('backed in'?) again. The revision where this really changed seems to be 83606bbdc084 . Found via hg bisect, like this: hg bisect -g 0 hg bisect -b 467c72e14d6e hg bisect -c'grep "(mRenderTypeMask & (1< I tend to agree with Argent on this, it should have a comment if there > is a hack in place to make it all function. > [...] > Comments for hacks like this are a good thing. Leaving them only in > commit messages leaves them to be lost and forgotten and then broken > by whoever browses the code. Yeah, this is definitely something that needs in-code documentation. > On Sat, Oct 9, 2010 at 12:19, Argent wrote: >> I don't normally gripe about stuff like this, but somehow this one >> triggered my twitches from 20 years of supporting PhD programmers. >> Brilliant guys, but sometimes it's SO hard to figure out what they're >> trying to do. >> >> This is a case where the trinary "?:" operator is much more readable >> and understandable. >> >> (type == 0) ? FALSE : mRenderTypeEnabled[type]; >> >> But even better: >> >> if(type == 0) >> return FALSE; // explain why here .. eg "in this context we are >> always rendering attached prims on the head when blah blah..." >> else >> return mRenderTypeEnabled[type]; >> Maybe it's because I'm in academia myself, but I don't think these are significantly more readable than Merov's line. The real issue is IMHO the lack of comments. Of course, the original implementation was rather confusing. Implicit casting to bool is commonly used for null pointer checks, but (without wanting to blame anyone) can probably safely be declared bad style for non-pointer variables, comments being present or not. Maybe a stupid question, but why do we need special casing here at all? Can't we just set |mRenderTypeEnabled[0]| to |FALSE| at an appropriate place? (Of course with a comment there explaining why we do that.) Cheers, Boroondas -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101009/6c14c085/attachment.htm From lee.ponzu at gmail.com Sat Oct 9 19:57:49 2010 From: lee.ponzu at gmail.com (Ponzu) Date: Sat, 9 Oct 2010 22:57:49 -0400 Subject: [opensource-dev] Fix for "Attachments displayed in mouselook" bug In-Reply-To: References: Message-ID: Would it be better to just store FALSE in mRenderTypeEnabled[0]? On Sat, Oct 9, 2010 at 12:19 PM, Argent wrote: > I don't normally gripe about stuff like this, but somehow this one > triggered my twitches from 20 years of supporting PhD programmers. > Brilliant guys, but sometimes it's SO hard to figure out what they're > trying to do. > > This is a case where the trinary "?:" operator is much more readable > and understandable. > > (type == 0) ? FALSE : mRenderTypeEnabled[type]; > > But even better: > > if(type == 0) > return FALSE; // explain why here .. eg "in this context we are > always rendering attached prims on the head when blah blah..." > else > return mRenderTypeEnabled[type]; > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101009/20a203bf/attachment.htm From dave at meadowlakearts.com Sat Oct 9 20:29:19 2010 From: dave at meadowlakearts.com (Dave Booth) Date: Sat, 09 Oct 2010 22:29:19 -0500 Subject: [opensource-dev] Fix for "Attachments displayed in mouselook" bug In-Reply-To: References: Message-ID: <4CB1330F.7080000@meadowlakearts.com> On 10/9/2010 10:07, Ponzu wrote: > Photo attached, from behind my eyes 8-) > > > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting privileges looks like you wear the same glasses I do :) From tateru.nino at gmail.com Sat Oct 9 20:30:55 2010 From: tateru.nino at gmail.com (Tateru Nino) Date: Sun, 10 Oct 2010 14:30:55 +1100 Subject: [opensource-dev] Fix for "Attachments displayed in mouselook" bug In-Reply-To: References: Message-ID: <4CB1336F.1090201@gmail.com> Well, that depends. That element might be used for something else, elsewhere. If the _intended_ behaviour of the function (and of the array/container) is documented, then it's relatively easy to make decisions about how best to implement that, clearly, concisely and efficiently - or at least to argue it back and forth :) All too many times, we've gone too far down the wrong rabbit-hole because we've tried to treat the code as the documentation when the code doesn't necessarily express what it is actually intended to do. On 10/10/2010 1:57 PM, Ponzu wrote: > Would it be better to just store FALSE in mRenderTypeEnabled[0]? > > On Sat, Oct 9, 2010 at 12:19 PM, Argent > wrote: > > I don't normally gripe about stuff like this, but somehow this one > triggered my twitches from 20 years of supporting PhD programmers. > Brilliant guys, but sometimes it's SO hard to figure out what they're > trying to do. > > This is a case where the trinary "?:" operator is much more readable > and understandable. > > (type == 0) ? FALSE : mRenderTypeEnabled[type]; > > But even better: > > if(type == 0) > return FALSE; // explain why here .. eg "in this context we are > always rendering attached prims on the head when blah blah..." > else > return mRenderTypeEnabled[type]; > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated > posting privileges > > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting privileges -- Tateru Nino http://dwellonit.taterunino.net/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101010/0600c2dc/attachment.htm From lee.ponzu at gmail.com Sun Oct 10 09:14:13 2010 From: lee.ponzu at gmail.com (Ponzu) Date: Sun, 10 Oct 2010 12:14:13 -0400 Subject: [opensource-dev] Fix for "Attachments displayed in mouselook" bug In-Reply-To: <4CB1336F.1090201@gmail.com> References: <4CB1336F.1090201@gmail.com> Message-ID: On Sat, Oct 9, 2010 at 11:30 PM, Tateru Nino wrote: > Well, that depends. That element might be used for something else, > elsewhere. > > If the _intended_ behaviour of the function (and of the array/container) is > documented, then it's relatively easy to make decisions about how best to > implement that, clearly, concisely and efficiently - or at least to argue it > back and forth :) > > You are right, of course. i did track it a little. I found where mRenderTypeEnabled[0] is set to TRUE, and I don't see any place where it is used. type is an enum that does not seem ever take the value 0. So, I set mRenderTypeEnabled[0] to FALSE, and put in a couple of llasserts(). So far, things seem to work as expected. Tateru's wrong rabbit hole is still a possibility of course. I am not suggesting wholesale distribution of this fix. Merov's seems to do the trick just ine. lee -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101010/1ad6e728/attachment.htm From lee.ponzu at gmail.com Sun Oct 10 09:32:07 2010 From: lee.ponzu at gmail.com (Ponzu) Date: Sun, 10 Oct 2010 12:32:07 -0400 Subject: [opensource-dev] Fix for "Attachments displayed in mouselook" bug In-Reply-To: References: Message-ID: Well, this is pretty common idiom for code that deals with bit masks. Funny. The problem is that the bitmask (hard to understand?) was replaced with a simple array (easy to understand? and that is when the error was introduced. On Sat, Oct 9, 2010 at 2:59 PM, Zabb65 wrote: > I tend to agree with Argent on this, it should have a comment if there > is a hack in place to make it all function. > > I ran it through hg blame and it claims that revision 11977 was when a > big block in pipeline.cpp changed > > 11977: BOOL LLPipeline::hasRenderType(const U32 type) const > 11977: { > 11977: return mRenderTypeEnabled[type]; > 11977: } > > previously this function was in a header and looked like > > BOOL hasRenderType(const U32 type) const { > return (type && > (mRenderTypeMask & (1< > Subtle isn't it? > > http://hg.secondlife.com/viewer-development/changeset/c09f9bcd9d20 > however does not show this, and I suspect that it is heavily truncated > on bitbucket, even though the full patch can be pulled from the hg > repository itself. > > So, this change is good, I support it, but make the hack for > attachment hiding obvious so that it doesn't have more creep later on. > Comments for hacks like this are a good thing. Leaving them only in > commit messages leaves them to be lost and forgotten and then broken > by whoever browses the code. > > On Sat, Oct 9, 2010 at 12:19, Argent wrote: > > I don't normally gripe about stuff like this, but somehow this one > > triggered my twitches from 20 years of supporting PhD programmers. > > Brilliant guys, but sometimes it's SO hard to figure out what they're > > trying to do. > > > > This is a case where the trinary "?:" operator is much more readable > > and understandable. > > > > (type == 0) ? FALSE : mRenderTypeEnabled[type]; > > > > But even better: > > > > if(type == 0) > > return FALSE; // explain why here .. eg "in this context we are > > always rendering attached prims on the head when blah blah..." > > else > > return mRenderTypeEnabled[type]; > > _______________________________________________ > > Policies and (un)subscribe information available here: > > http://wiki.secondlife.com/wiki/OpenSource-Dev > > Please read the policies before posting to keep unmoderated posting > privileges > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101010/03c23d4f/attachment-0001.htm From lee.ponzu at gmail.com Sun Oct 10 09:47:23 2010 From: lee.ponzu at gmail.com (Ponzu) Date: Sun, 10 Oct 2010 12:47:23 -0400 Subject: [opensource-dev] Fix for "Attachments displayed in mouselook" bug In-Reply-To: References: Message-ID: This code below means it used to be inline, but now is a function call (unless the compiler is optimizing or something). You guys know the code waaaay better tahn I, but is it worth moving it back to the .h file? return type && mRenderTypeEnabled[type] looks hard to beat for inlining, and it is probably called a zillion times. On Sat, Oct 9, 2010 at 2:59 PM, Zabb65 wrote: > I tend to agree with Argent on this, it should have a comment if there > is a hack in place to make it all function. > > I ran it through hg blame and it claims that revision 11977 was when a > big block in pipeline.cpp changed > > 11977: BOOL LLPipeline::hasRenderType(const U32 type) const > 11977: { > 11977: return mRenderTypeEnabled[type]; > 11977: } > > previously this function was in a header and looked like > > BOOL hasRenderType(const U32 type) const { > return (type && > (mRenderTypeMask & (1< > Subtle isn't it? > > http://hg.secondlife.com/viewer-development/changeset/c09f9bcd9d20 > however does not show this, and I suspect that it is heavily truncated > on bitbucket, even though the full patch can be pulled from the hg > repository itself. > > So, this change is good, I support it, but make the hack for > attachment hiding obvious so that it doesn't have more creep later on. > Comments for hacks like this are a good thing. Leaving them only in > commit messages leaves them to be lost and forgotten and then broken > by whoever browses the code. > > On Sat, Oct 9, 2010 at 12:19, Argent wrote: > > I don't normally gripe about stuff like this, but somehow this one > > triggered my twitches from 20 years of supporting PhD programmers. > > Brilliant guys, but sometimes it's SO hard to figure out what they're > > trying to do. > > > > This is a case where the trinary "?:" operator is much more readable > > and understandable. > > > > (type == 0) ? FALSE : mRenderTypeEnabled[type]; > > > > But even better: > > > > if(type == 0) > > return FALSE; // explain why here .. eg "in this context we are > > always rendering attached prims on the head when blah blah..." > > else > > return mRenderTypeEnabled[type]; > > _______________________________________________ > > Policies and (un)subscribe information available here: > > http://wiki.secondlife.com/wiki/OpenSource-Dev > > Please read the policies before posting to keep unmoderated posting > privileges > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101010/678552a0/attachment.htm From tateru.nino at gmail.com Sun Oct 10 09:53:56 2010 From: tateru.nino at gmail.com (Tateru Nino) Date: Mon, 11 Oct 2010 03:53:56 +1100 Subject: [opensource-dev] Fix for "Attachments displayed in mouselook" bug In-Reply-To: References: Message-ID: <4CB1EFA4.9010704@gmail.com> The original code looks very efficient, especially for inlining. Anyone have any idea if it actually does what it is supposed to do by accident or by design? On 11/10/2010 3:47 AM, Ponzu wrote: > This code below means it used to be inline, but now is a function call > (unless the compiler is optimizing or something). You guys know the > code waaaay better tahn I, but is it worth moving it back to the .h file? > > return type && mRenderTypeEnabled[type] > > looks hard to beat for inlining, and it is probably called a zillion > times. > > > > On Sat, Oct 9, 2010 at 2:59 PM, Zabb65 > wrote: > > I tend to agree with Argent on this, it should have a comment if there > is a hack in place to make it all function. > > I ran it through hg blame and it claims that revision 11977 was when a > big block in pipeline.cpp changed > > 11977: BOOL LLPipeline::hasRenderType(const U32 type) const > 11977: { > 11977: return mRenderTypeEnabled[type]; > 11977: } > > previously this function was in a header and looked like > > BOOL hasRenderType(const U32 type) const > { return (type && > (mRenderTypeMask & (1< > Subtle isn't it? > > http://hg.secondlife.com/viewer-development/changeset/c09f9bcd9d20 > however does not show this, and I suspect that it is heavily truncated > on bitbucket, even though the full patch can be pulled from the hg > repository itself. > > So, this change is good, I support it, but make the hack for > attachment hiding obvious so that it doesn't have more creep later on. > Comments for hacks like this are a good thing. Leaving them only in > commit messages leaves them to be lost and forgotten and then broken > by whoever browses the code. > > On Sat, Oct 9, 2010 at 12:19, Argent > wrote: > > I don't normally gripe about stuff like this, but somehow this one > > triggered my twitches from 20 years of supporting PhD programmers. > > Brilliant guys, but sometimes it's SO hard to figure out what > they're > > trying to do. > > > > This is a case where the trinary "?:" operator is much more readable > > and understandable. > > > > (type == 0) ? FALSE : mRenderTypeEnabled[type]; > > > > But even better: > > > > if(type == 0) > > return FALSE; // explain why here .. eg "in this context we are > > always rendering attached prims on the head when blah blah..." > > else > > return mRenderTypeEnabled[type]; > > _______________________________________________ > > Policies and (un)subscribe information available here: > > http://wiki.secondlife.com/wiki/OpenSource-Dev > > Please read the policies before posting to keep unmoderated > posting privileges > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated > posting privileges > > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting privileges -- Tateru Nino http://dwellonit.taterunino.net/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101011/64e7113d/attachment.htm From oz at lindenlab.com Mon Oct 11 06:05:07 2010 From: oz at lindenlab.com (Oz Linden (Scott Lawrence)) Date: Mon, 11 Oct 2010 09:05:07 -0400 Subject: [opensource-dev] Remaining build issues for 64bit linux standalone out-of-source (without unit tests) In-Reply-To: <4CACFB0C.2020808@boroon.dasgupta.ch> References: <4C766008.1070001@boroon.dasgupta.ch> <4C78DB67.5040005@boroon.dasgupta.ch> <4C7D501C.5040709@boroon.dasgupta.ch> <4C7E37E7.5080105@boroon.dasgupta.ch> <4CACFB0C.2020808@boroon.dasgupta.ch> Message-ID: <4CB30B83.1070508@lindenlab.com> > > VWR-23296 : missing > LL_TEST conditions (i.e. SNOW-651 > *+* SNOW-654 > ) > > * The ability to turn off building and executing of /all/ unit > tests is needed to work around other issues (which we'll have to > fix later) > * Fixed at http://bitbucket.org/boroondas/vwr-23296 > * Should be easy to review (but note there are several changesets) > I'm hesitant to move this to the main development branch, because I'd rather not make it easy to not do tests. If they're broken, we should instead invest in fixing them (or the means of running them). I'd like to hear more discussion on this... specifically, what are the problems that are causeing the tests not to be useful? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101011/5c5e65dd/attachment.htm From wolfpup67 at earthlink.net Mon Oct 11 06:22:26 2010 From: wolfpup67 at earthlink.net (WolfPup Lowenhar) Date: Mon, 11 Oct 2010 09:22:26 -0400 Subject: [opensource-dev] Remaining build issues for 64bit linux standalone out-of-source (without unit tests) In-Reply-To: <4CB30B83.1070508@lindenlab.com> References: <4C766008.1070001@boroon.dasgupta.ch> <4C78DB67.5040005@boroon.dasgupta.ch> <4C7D501C.5040709@boroon.dasgupta.ch> <4C7E37E7.5080105@boroon.dasgupta.ch> <4CACFB0C.2020808@boroon.dasgupta.ch> <4CB30B83.1070508@lindenlab.com> Message-ID: <000c01cb6947$590f23b0$0b2d6b10$@net> For some of us disabling of the tests means less time actually compiling the code. Especially if the system the code is being compiled on is an older system. As an example below is my system specs taken directly from the current dev build I did over the weekend. CPU: Intel(R) Pentium(R) D CPU 2.80GHz (2800.13 MHz) Memory: 2046 MB OS Version: Microsoft Windows 7 32-bit (Build 7600) Graphics Card Vendor: NVIDIA Corporation Graphics Card: GeForce 8500 GT/PCI/SSE2 On the above system if I build and run everything from a clean checkout it will take ~3hrs to do a complete build all the way to packaging. Now if I turn off the building and running of those test but compile time is cut in half which means more time for me to test any changes I have made in the code. I know there are some out there that talk about doing incremental builds when your testing something and that might be ok for if you make a minor change the same day you have done a build but if you're making changes over multiple days it is best to me for the date of the build in about SecdondLife to be set to the new date each time so you can keep track of those changes. From: opensource-dev-bounces at lists.secondlife.com [mailto:opensource-dev-bounces at lists.secondlife.com] On Behalf Of Oz Linden (Scott Lawrence) Sent: Monday, October 11, 2010 9:05 AM To: Boroondas Gupte Cc: Second Life Open Source Developer Mailing List Subject: Re: [opensource-dev] Remaining build issues for 64bit linux standalone out-of-source (without unit tests) VWR-23296 : missing LL_TEST conditions (i.e. SNOW-651 + SNOW-654 ) * The ability to turn off building and executing of all unit tests is needed to work around other issues (which we'll have to fix later) * Fixed at http://bitbucket.org/boroondas/vwr-23296 * Should be easy to review (but note there are several changesets) I'm hesitant to move this to the main development branch, because I'd rather not make it easy to not do tests. If they're broken, we should instead invest in fixing them (or the means of running them). I'd like to hear more discussion on this... specifically, what are the problems that are causeing the tests not to be useful? _____ No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1136 / Virus Database: 422/3190 - Release Date: 10/11/10 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101011/677e5c0e/attachment.htm From q at lindenlab.com Mon Oct 11 07:44:21 2010 From: q at lindenlab.com (Kent Quirk (Q Linden)) Date: Mon, 11 Oct 2010 10:44:21 -0400 Subject: [opensource-dev] Jira Issue Resolution Issue In-Reply-To: References: Message-ID: <24253B0F-0639-4CC2-AAD1-3FE2626B6605@lindenlab.com> So we've modified the JIRA system again to allow residents to reopen issues in VWR and STORM. But with power comes responsibility -- we aren't going to tolerate edit wars, and we're not going to let JIRA be a place to vent your frustrations with us or with each other. Please keep it polite. Reopening because of a mistake or a misunderstanding is reasonable, especially when accompanied by a good explanation. But reopening because you don't like a decision is a waste of everyone's time, and will result in temporary or permanent loss of JIRA access. I should note that on the Snowstorm team we're trying to aggressively prune down JIRA to actionable issues. "FIX LAG" is not a useful JIRA to us, even if you don't think we've fixed it, because it's too broad and unactionable. A summary JIRA with 3 separate problems doesn't help us track it, especially when 2 of them have been fixed. So we may close these, and we'll try to explain why. If the reason is that we can't use the issue the way it's written, then please don't reopen it, write a new and better one. Thanks for your help on this. Q On Oct 8, 2010, at 5:57 PM, Erin Mallory wrote: > yes we used to have the ability to reopen. and the person in question has closed allot. so have others. its like they dont READ the issue before closing. to the point i've considered aring them for a form of griefing > > > > Date: Fri, 8 Oct 2010 14:00:24 -0700 > > From: bryon at slearth.com > > To: opensource-dev at lists.secondlife.com > > Subject: [opensource-dev] Jira Issue Resolution Issue > > > > As a user I would like to be able to reopen Jira issues wrongly closed by > > ignorant people who can't read, creating havok. Like this one there: > > > > Stone Tremont added a comment - 08/Oct/10 2:17 AM > > This is not a bug because you do not pay prims, avatars are payed via whole > > objects. This should be a feature request. I have a way to set different > > prices for variations in vendors, you just need to make a more advanced, > > intuitive script like mine. > > > > https://jira.secondlife.com/browse/VWR-3048 > > > > Please reopen this issue! As per Gigs Taggart's comment, its used to work.. > > It you are going to allow any kiddo to close issues, the same should true > > for reopening them, or it doesn't make any sense at all. > > > > > > _______________________________________________ > > Policies and (un)subscribe information available here: > > http://wiki.secondlife.com/wiki/OpenSource-Dev > > Please read the policies before posting to keep unmoderated posting privileges > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting privileges -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101011/b7ae1e35/attachment.htm From robertltux at gmail.com Mon Oct 11 09:44:59 2010 From: robertltux at gmail.com (Robert Martin) Date: Mon, 11 Oct 2010 12:44:59 -0400 Subject: [opensource-dev] Jira Issue Resolution Issue In-Reply-To: <24253B0F-0639-4CC2-AAD1-3FE2626B6605@lindenlab.com> References: <24253B0F-0639-4CC2-AAD1-3FE2626B6605@lindenlab.com> Message-ID: On Mon, Oct 11, 2010 at 10:44 AM, Kent Quirk (Q Linden) wrote: > If the reason is that we can't use the issue the way it's written, then > please don't reopen it, write a new and better one. Just make sure on the Linden side we have a few things laid out 1 if a linden closes a jira then there should be a comment with a "long form" reason as to why it has been closed then close it 2 if a jira needs an edit/rewrite to be useful then leave a comment as to why and how (this is a meta issue , this needs to be split into N jiras for tracking , fix requires breaking laws of Government/Physics, duplicate of older jira, fix involves code we are dropping altogether ect) 3 "WorkingOnIt Linden"* should only have an issue assigned for maybe two weeks since a lot of times WorkingOnIt Linden means BlowingItOff Linden is actually NOT working on it. -- Robert L Martin *prove me wrong but if you look in the logs i would almost bet money that WOI Linden assigned jiras are mostly closed by 1 target version became outdated 2 no linden actually picked it up 3 some linden closed it with WONT FIX/ CAN'T FIX or anything that boils down to it not actually being fixed From oz at lindenlab.com Mon Oct 11 10:04:08 2010 From: oz at lindenlab.com (Oz Linden (Scott Lawrence)) Date: Mon, 11 Oct 2010 13:04:08 -0400 Subject: [opensource-dev] Remaining build issues for 64bit linux standalone out-of-source (without unit tests) In-Reply-To: <4CACFB0C.2020808@boroon.dasgupta.ch> References: <4C766008.1070001@boroon.dasgupta.ch> <4C78DB67.5040005@boroon.dasgupta.ch> <4C7D501C.5040709@boroon.dasgupta.ch> <4C7E37E7.5080105@boroon.dasgupta.ch> <4CACFB0C.2020808@boroon.dasgupta.ch> Message-ID: <4CB34388.7030903@lindenlab.com> On 2010-10-06 18:41, Boroondas Gupte wrote: > A lot of fixes from my previous list > > have been integrated by now, so the list of remaining > not-yet-integrated build fixes for 64bit out-of-source has become a > lot shorter :-) . > > *Please note: Unit tests are currently broken for out-of-source builds > .* > Run cmake or develop.py configure with -DLL_TESTS:BOOL=FALSE or > uncheck LL_TESTS in cmake-gui and reconfigure to disable them if you > try building out-of-source. > > I've isolated the fixes for the remaining issues into repositories of > their own (except for those that should be pulled together) and turned > them into daggy fixes to allow for easy merging with as many revisions > as possible. > > VWR-23047 (aka SNOW-512 > / SNOW-287): PIC required for standalone > > * Fixed - On Review (fix at http://bitbucket.org/boroondas/vwr-23047) > * Fixes for VWR-20911 > and SNOW-748 > are also in this > repository > * Fixes for all 3 issues should be pulled together to avoid breakage > > > STORM-222 : expat.h not > found on STANDALONE > > * Fixed in http://bitbucket.org/boroondas/storm-222 > * Approved by Vadim ProductEngine > > > VWR-23296 : missing > LL_TEST conditions (i.e. SNOW-651 > *+* SNOW-654 > ) > > * The ability to turn off building and executing of /all/ unit > tests is needed to work around other issues (which we'll have to > fix later) > * Fixed at http://bitbucket.org/boroondas/vwr-23296 > * Should be easy to review (but note there are several changesets) > > > STORM-275 (a.k.a. > VWR-20893): "class Linux_x86_64Manifest" missing from > viewer_manifest.py Breaking linux 64-bit build. > > * Fixed at http://bitbucket.org/boroondas/storm-275 > > I've posted a build made with all of the above except VWR-23296 (global switch to disable tests - see my other reply to this thread) at: http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repo/oz_viewer-review1/rev/211764/index.html All platforms built, and since that's what these changes were about it's probably good. The Mac version appears to be working fine - if a few people could do a quick smoke test of the other platforms and report all clear, then I'll push these changes into viewer-development. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101011/ebbb2c26/attachment.htm From akanevsky at productengine.com Mon Oct 11 10:54:19 2010 From: akanevsky at productengine.com (Anya Kanevsky) Date: Mon, 11 Oct 2010 10:54:19 -0700 Subject: [opensource-dev] Daily Scrum Summary - Monday, October 11 Message-ID: Date: Mon Oct 11 == GENERAL NOTES == * Merge Monkey of the Day: Merov ... again * Beta fixes should be done on a beta branch * With rare exceptions when we need to stabilize and release a beta, beta fixes should merged into Beta asap. == DAILY SCRUM == === Merov === PAST * STORM-137: Fixed a last Windows viewer packaging issue. Emailed chopper on what I did. Asked community members to help me test the standalone build case. Ready for review. * SH-277 (Attachments are visible in mouselook mode): Found a 1 liner fix in the nick on time on Friday evening! Emailed opensource-dev to get folks to test if that really fixed the issue but didn't get anything useful. How to * Finished HR paperwork FUTURE * Beta monitoring and merge monkey-ing (merges, try to identify bugs I can contribute to) * SH-277 : Finish so we can push a fix on beta. * STORM-105 : Perf decompression: put new data out, check the work done by opensource-dev community on similar tests. IMPEDIMENTS * None ==Oz Linden== PAST * Pester Team Chopper about opening up autobuild ** Plan is to publish at the end of their current sprint (1.5 weeks) * Pulled build changes to a viewer-development tree and built ** Testing - looks ready to integrate * Got access and development briefing for web site changes ** (develop.secondlife.com, viewerdirectory.secondlife.com) FUTURE * Prep a budget proposal for open build service & code review system * Start updating develop.secondlife.com IMPEDIMENTS * none === Q Linden=== PAST * HR (annual reviews) - mostly done (one left) * Q4 / 2011 planning - not quite done (sigh) * Process work (finishing today, I hope) FUTURE * Process work * Unit test working IMPEDIMENTS * None === Esbee Linden==== PAST * VWR triage * Q4+ planning * Systems requirements research * Reviewed versions, "viewer-development bug queue and viewer 2.2.0 Beta" and prioritized all bugs * Finished end of year review paperwork FUTURE * VWR triage * Viewer release process review * Review Snowstorm Jira tickets * Viewer roadmap/Q4 planning planning * Systems requirements analysis IMPEDIMENTS * None === Paul ProductEngine=== PAST: * STORM-211 Fade timer is reset for all toasts displayed in the notifications channel ** Fixed FUTURE: * STORM-211 Fade timer is reset for all toasts displayed in the notifications channel ** Carefully test fix IMPEDIMENTS: * none === Seth Productengine === PAST: * BUG (STORM-289) Internal browser navigation bar disappears after minimize/restore ** Fixed. FUTURE: * BUG (STORM-294) Selection goes out of Favorites overflow list if scroll it by keyboard ** Estimated: 4-6 hours. IMPEDIMENTS: * none === Andrew Productengine === PAST: * Major bug STORM-313 (Build parcel property is displayed incorrectly) ** Came across comment in code which led me to EXT-4610 ([BSI] parcel settings icons do not match parcel settings) where decision to make the icon the way it is now was made. So this bug seems to be expected behaviour, but because it wasn't closed as such by Esbee and was reported by Oz, asked Esbee a question in ticket and will either make changes or close floater depending on answer. * Bug STORM-301 (Camera view remains on Edit Appearance mode after undocked 'My Appearance' tab was minimized while being in 'Edit Outfit' mode) WIP, will finish on Monday. Estimate- 3 hours. * The 2h+ downtime of grid today made the work a bit slower. FUTURE: * STORM-301 IMPEDIMENTS: * Looked through STORM-182 (Uninstalling a beta client can result in all chatlogs being deleted as well if logging is left to default location)- it doesn't seem to be viewer issue- perhaps it should be on some team that is working on installer, or if just behaviour (not code) should be investigated and discussed, perhaps this issue is not for devs. * STORM-313 === Vadim Productengine === * OOO - Vacation. Will be back to office on Oct, 11th. === Andrey Productengine === PAST: * smoke and regression testing of 2.2.0 Beta 3 on Windows and Mac, see DRTVWR-9 for details * verified tickets linked to DRTVWR-7 on Beta 3 build FUTURE: * return to viewer-development builds testing IMPEDIMENTS: * none === Grumpity ProductEngine === PAST * crashhunters, another monday * getting access for QA FUTURE: * QA synch notes & followup * take STORM-315 from Esbee and split it. * crashhunters * STORM - 313 * STORM- 182 * etherpad for updates? IMPEDIMENTS: * none From lee.ponzu at gmail.com Mon Oct 11 11:40:44 2010 From: lee.ponzu at gmail.com (Ponzu) Date: Mon, 11 Oct 2010 14:40:44 -0400 Subject: [opensource-dev] SHH-277 Message-ID: Merov said... * SH-277 (Attachments are visible in mouselook mode): Found a 1 liner fix in the nick on time on Friday evening! Emailed opensource-dev to get folks to test if that really fixed the issue but didn't get anything useful. Lee says... It looks like the right fix to me. I also looked at the code a little bit. There is other email about that. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101011/cb7994e6/attachment.htm From sllists at boroon.dasgupta.ch Mon Oct 11 13:12:34 2010 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Mon, 11 Oct 2010 22:12:34 +0200 Subject: [opensource-dev] Remaining build issues for 64bit linux standalone out-of-source (without unit tests) In-Reply-To: <4CB30B83.1070508@lindenlab.com> References: <4C766008.1070001@boroon.dasgupta.ch> <4C78DB67.5040005@boroon.dasgupta.ch> <4C7D501C.5040709@boroon.dasgupta.ch> <4C7E37E7.5080105@boroon.dasgupta.ch> <4CACFB0C.2020808@boroon.dasgupta.ch> <4CB30B83.1070508@lindenlab.com> Message-ID: <4CB36FB2.4000102@boroon.dasgupta.ch> On 10/11/2010 03:05 PM, Oz Linden (Scott Lawrence) wrote: >> >> VWR-23296 : missing >> LL_TEST conditions (i.e. SNOW-651 >> *+* SNOW-654 >> ) >> >> * The ability to turn off building and executing of /all/ unit >> tests is needed to work around other issues (which we'll have >> to fix later) >> * Fixed at http://bitbucket.org/boroondas/vwr-23296 >> * Should be easy to review (but note there are several changesets) >> > > I'm hesitant to move this to the main development branch, because I'd > rather not make it easy to not do tests. If they're broken, we should > instead invest in fixing them (or the means of running them). As I've already stated in a jira comment , I don't think this is a question of either-or. As long as we /have/ the LL_TESTS option (and I haven't introduced it, it was already there), it should do what its name suggests. *This shouldn't stop us from fixing the tests.* In fact, my plan for the time after having gotten all build fixes I need with LL_TESTS set to FALSE into viewer-development (which I hope will be soon) was to set LL_TESTS back on TRUE and hunt down the change(s) needed to build like that. (We already had these fixes in Snowglobe 2. I hope nothing new got broken regarding unit tests, since then.) Even once the tests can be run on all platforms, we /might/ want to keep the LL_TESTS option around for the following cases: * Developer A breaks a tests, but this only manifests on Developer B's platform (thus A didn't catch it during his/her own builds). Developer B isn't able to fix A's mistake (not B's area of expertise), but would like to continue his/her own development based on the newest code and of course test whether it at least builds (and maybe test new or fixed functionality). B would file a bug about the broken test (probably to be fixed by A), set LL_TESTS to FALSE and continue development. Hopefully, the broken test gets fixed before B's development is ready for integration, so B can then set LL_TESTS back to TRUE for a final test before his/her stuff ends up in viewer-development. If the test can't be fixed in time, the test-breaking commit should probably be backed out. * Developer C has a slow machine and is working on something of which he/she assumes that it isn't unit tested anyway, yet, or that his/her change is easy and save enough to be very unlikely to break any tests. During development, C does several builds with LL_TESTS set to FALSE to get shorter build times. Only before requesting integration, C does a final build with LL_TESTS turned back on. Of course, for the first scenario, it would be good to be able to only disable the offending test and keep the other tests in place. But for now, the all-or-nothing LL_TESTS is what we have. (Short of editing CMake scripts.) > I'd like to hear more discussion on this... specifically, what are the > problems that are causeing the tests not to be useful? They would be useful if the system for running them wasn't broken. When I set LL_TESTS to TRUE, I currently get errors like this: [ 10%] Generating PROJECT_llmath_TEST_llbboxlocal_ok.txt LD_LIBRARY_PATH += ['/usr/lib'] LD_LIBRARY_PATH = '/usr/lib' Running: ${BUILD_DIR}/llmath/PROJECT_llmath_TEST_llbboxlocal --touch=${BUILD_DIR}/llmath/PROJECT_llmath_TEST_llbboxlocal_ok.txt --sourcedir=${SRC_DIR}/indra/llmath ${BUILD_DIR}/llmath/PROJECT_llmath_TEST_llbboxlocal: error while loading shared libraries: libllcommon.so: cannot open shared object file: No such file or directory Failure running: ${BUILD_DIR}/llmath/PROJECT_llmath_TEST_llbboxlocal --touch=${BUILD_DIR}/llmath/PROJECT_llmath_TEST_llbboxlocal_ok.txt --sourcedir=${SRC_DIR}/indra/llmath Error: 127 make[2]: *** [llmath/PROJECT_llmath_TEST_llbboxlocal_ok.txt] Error 127 make[1]: *** [llmath/CMakeFiles/llmath_tests.dir/all] Error 2 make: *** [all] Error 2 I.e., LD_LIBRARY_PATH is missing some entry. When building parallel, I see equivalent errors about other unit tests. Why should we fix VWR-23296 first and the unit test execution later? Simple: As long as unit test execution is broken, it's easier to tell whether we've fixed VWR-23296 completely (i.e. have wrapped ALL adding of test targets into LL_TESTS conditions). Not that grepping for "\o/" would be difficult, but yeah ... you get the idea. Cheers, Boroondas -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101011/28d5d85e/attachment.htm From bryon at slearth.com Mon Oct 11 14:28:53 2010 From: bryon at slearth.com (Bryon Ruxton) Date: Mon, 11 Oct 2010 14:28:53 -0700 Subject: [opensource-dev] Jira Issue Resolution Issue In-Reply-To: <24253B0F-0639-4CC2-AAD1-3FE2626B6605@lindenlab.com> Message-ID: Thanks Q >reopening because you don't like a decision is a waste of everyone's time, and will result in temporary or permanent loss of JIRA access. Sounds good to me. On 10/11/10 7:44 AM, "Kent Quirk (Q Linden)" wrote: > So we've modified the JIRA system again to allow residents to reopen issues in > VWR and STORM. > > But with power comes responsibility -- we aren't going to tolerate edit wars, > and we're not going to let JIRA be a place to vent your frustrations with us > or with each other. Please keep it polite. Reopening because of a mistake or a > misunderstanding is reasonable, especially when accompanied by a good > explanation. But reopening because you don't like a decision is a waste of > everyone's time, and will result in temporary or permanent loss of JIRA > access. > > I should note that on the Snowstorm team we're trying to aggressively prune > down JIRA to actionable issues. > > "FIX LAG" is not a useful JIRA to us, even if you don't think we've fixed it, > because it's too broad and unactionable. A summary JIRA with 3 separate > problems doesn't help us track it, especially when 2 of them have been fixed. > So we may close these, and we'll try to explain why. If the reason is that we > can't use the issue the way it's written, then please don't reopen it, write a > new and better one. > > Thanks for your help on this. > Q -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101011/a6e656e7/attachment.htm From gigstaggart at gmail.com Mon Oct 11 14:29:55 2010 From: gigstaggart at gmail.com (Gigs) Date: Mon, 11 Oct 2010 17:29:55 -0400 Subject: [opensource-dev] Jira Issue Resolution Issue In-Reply-To: References: <24253B0F-0639-4CC2-AAD1-3FE2626B6605@lindenlab.com> Message-ID: <4CB381D3.6040105@gmail.com> On 10/11/2010 12:44 PM, Robert Martin wrote: > 3 "WorkingOnIt Linden"* should only have an issue assigned for maybe > two weeks since a lot of times WorkingOnIt Linden means BlowingItOff > Linden is actually NOT working on it. Workingonit Linden should have never been created. "Working on it" should be represented as a workflow status, not as a fake account. -Jason From richard at lindenlab.com Mon Oct 11 14:38:09 2010 From: richard at lindenlab.com (Richard Nelson) Date: Mon, 11 Oct 2010 14:38:09 -0700 Subject: [opensource-dev] opensource-dev Digest, Vol 9, Issue 27 In-Reply-To: <33A6ACA5-3C64-4ED5-BD29-EDB759C23541@lindenlab.com> References: <33A6ACA5-3C64-4ED5-BD29-EDB759C23541@lindenlab.com> Message-ID: Just create a combo_box like this: and put it in the proper spot in floater_tools.xml and everything should just work. FWIW, I recommend doing development of XUI in your OS-equivalent Application Data directory: on Windows 7, for example, copy floater_tools.xml to c:\users\your_account\application data\roaming\secondlife\skins\default\xui\en\ and edit in place. Enjoy. R. On Wed, 06 Oct 2010 20:25:30 -0700, Kent Quirk (Q Linden) wrote: > That sort of thing is more involved, I'm afraid; you have to change the > control. I don't know offhand if the XUI commit binding mechanism can be > made to work with only XUI change -- I kind of doubt it. If not, you'll > have to change the c++ event handlers from 4 individual event handlers > to one that does all 4 things on change of the combo_box. > > It's probably worth some spelunking through XUI to see if there's an > example of binding the combo box; if not, I bet one of the devs around > here would help you write the C++ changes to make it work. > > Q > > On Oct 6, 2010, at 11:04 PM, SuezanneC Baskerville wrote: > >> Thanks, Kent, I'm glad I asked. >> >> The keystroke, by the way, appears to be Control Shift T, not Control >> Alt T, on my XP system running the Development Viewer. >> >> I'd like to replace the Focus, Move, Edit, Create, and Land buttons >> with a list, I suppose a combo_box, to save horizontal space. How does >> one do that? >> >> >> ------------------------------ >> >> Message: 7 >> Date: Wed, 6 Oct 2010 22:30:51 -0400 >> From: "Kent Quirk (Q Linden)" >> Subject: Re: [opensource-dev] How is the XUI part of the interface >> designed? >> >> There's no GUI editor. However, there is a nice little assistance tool. >> From the login screen ONLY, you can invoke the GUI Preview tool by >> hitting alt-ctrl-T (or cmd-ctrl-T on a Mac). It will bring up a dialog >> that you can use to display any of our dialog boxes, in two languages >> at once if you want. If you configure it, you can also have it open the >> dialog file in your text editor, and the "show rectangles" checkbox >> makes it easy to see which parts of the dialog have which names. >> >> If you edit a dialog, you can show and hide it, and it will reload. So >> you should be able to experiment with a layout rather easily; it's not >> a live graphical editor, but it makes it pretty easy to edit. Just >> realize the dialogs are not "live", and so sometimes things won't look >> right, or may have overlapping fields because only one of them is >> visible at any given time. >> >> Q >> >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/OpenSource-Dev >> Please read the policies before posting to keep unmoderated posting >> privileges > -- Using Opera's revolutionary email client: http://www.opera.com/mail/ From sllists at boroon.dasgupta.ch Mon Oct 11 15:10:21 2010 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Tue, 12 Oct 2010 00:10:21 +0200 Subject: [opensource-dev] LL_TESTS for standalone out-of-source builds (was: Remaining build issues for 64bit linux standalone out-of-source (without unit tests)) In-Reply-To: <4CB36FB2.4000102@boroon.dasgupta.ch> References: <4C766008.1070001@boroon.dasgupta.ch> <4C78DB67.5040005@boroon.dasgupta.ch> <4C7D501C.5040709@boroon.dasgupta.ch> <4C7E37E7.5080105@boroon.dasgupta.ch> <4CACFB0C.2020808@boroon.dasgupta.ch> <4CB30B83.1070508@lindenlab.com> <4CB36FB2.4000102@boroon.dasgupta.ch> Message-ID: <4CB38B4D.80004@boroon.dasgupta.ch> On 10/11/2010 10:12 PM, Boroondas Gupte wrote: > In fact, my plan for the time after having gotten all build fixes I > need with LL_TESTS set to FALSE into viewer-development (which I hope > will be soon) was to set LL_TESTS back on TRUE and hunt down the > change(s) needed to build like that. (We already had these fixes in > Snowglobe 2. I hope nothing new got broken regarding unit tests, since > then.) Looks like Aleric's patch from SNOW-756 (which still applies :-) ) is all that's needed, so I moved that to VWR-23385 and will daggify that fix ASAP. With this change, all tests succeed on my machine. YAY!! \o/ Cheers, Boroondas -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101012/ae8b4b0b/attachment-0001.htm From cg at lindenlab.com Mon Oct 11 15:21:05 2010 From: cg at lindenlab.com (CG Linden) Date: Mon, 11 Oct 2010 15:21:05 -0700 Subject: [opensource-dev] LL_TESTS for standalone out-of-source builds (was: Remaining build issues for 64bit linux standalone out-of-source (without unit tests)) In-Reply-To: <4CB38B4D.80004@boroon.dasgupta.ch> References: <4C766008.1070001@boroon.dasgupta.ch> <4C78DB67.5040005@boroon.dasgupta.ch> <4C7D501C.5040709@boroon.dasgupta.ch> <4C7E37E7.5080105@boroon.dasgupta.ch> <4CACFB0C.2020808@boroon.dasgupta.ch> <4CB30B83.1070508@lindenlab.com> <4CB36FB2.4000102@boroon.dasgupta.ch> <4CB38B4D.80004@boroon.dasgupta.ch> Message-ID: Yay \o/ for "daggifying" :) -- cg On Mon, Oct 11, 2010 at 3:10 PM, Boroondas Gupte wrote: > On 10/11/2010 10:12 PM, Boroondas Gupte wrote: > > In fact, my plan for the time after having gotten all build fixes I need > with LL_TESTS set to FALSE into viewer-development (which I hope will be > soon) was to set LL_TESTS back on TRUE and hunt down the change(s) needed > to build like that. (We already had these fixes in Snowglobe 2. I hope > nothing new got broken regarding unit tests, since then.) > > Looks like Aleric's patch from SNOW-756(which still applies :-) ) > is all that's needed, so I moved that to VWR-23385and will daggify that fix ASAP. > With this change, all tests succeed on my machine. > YAY!! \o/ Cheers, > Boroondas > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101011/173d6ec9/attachment.htm From akanevsky at productengine.com Mon Oct 11 15:57:22 2010 From: akanevsky at productengine.com (Anya Kanevsky) Date: Mon, 11 Oct 2010 15:57:22 -0700 Subject: [opensource-dev] tos acceptance issues In-Reply-To: References: Message-ID: Erin, Is there a JIRA that details which builds and which versions of 2.x presented this problem? Repro steps? Which accounts were and were not allowed to accept TOS? Thank you, Anya 2010/10/8 Erin Mallory : > As a user, it would be nice if the 2.x versions of SL would allow ALL > accounts to accept the new terms of service instead of denying that option > to all/some of them. > Depending on the build, some versions of 2.x do not allow any accounts to > accept tos even after cancel and reattempt.? Some allow only some accounts > to do so.? this is like the third time this bug has resurfaced.? can we > please fix it so everyone can log in? > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting > privileges > From andrew at lindenlab.com Mon Oct 11 16:03:22 2010 From: andrew at lindenlab.com (Andrew Meadows) Date: Mon, 11 Oct 2010 16:03:22 -0700 Subject: [opensource-dev] simconsole is available for experimentation Message-ID: <4CB397BA.6080103@lindenlab.com> As mentioned in my office hours, and Oskar Linden's office hours last week: Thanks to Brad and Falcon Linden the SL simulator will soon support a very simple command line interface (CLI) console we're calling "simconsole". The motivation for it was primarily for debug and prototyping, and the list of commands available is currently very short, but we'll add some more soon and maybe it will become a useful tool for intrepid Residents. The simulator support is currently on the beta grid (aditi). It was just promoted to the "Second Life Beta Server" channel today so is on most of the regions there. It was previously on just four regions using the "andrew-maint-server" channel. In order to play around with the simconsole you need viewer UI support. I've just created a bitbucket clone of lindenlab/viewer-development with the simconsole UI added for those who want to build and play around with it. Clone or pull from here: http://bitbucket.org/andrew_linden/viewer-development To open the console type: CTRL + SHIFT + ` (CTRL + SHIFT + backtick) I think there is a "help" command, but otherwise there isn't any documentation yet. You'll have to be an LL admin or estate manager to run any of the commands that change anything. - Andrew From sllists at boroon.dasgupta.ch Mon Oct 11 16:24:53 2010 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Tue, 12 Oct 2010 01:24:53 +0200 Subject: [opensource-dev] LL_TESTS for standalone out-of-source builds In-Reply-To: References: <4C766008.1070001@boroon.dasgupta.ch> <4C78DB67.5040005@boroon.dasgupta.ch> <4C7D501C.5040709@boroon.dasgupta.ch> <4C7E37E7.5080105@boroon.dasgupta.ch> <4CACFB0C.2020808@boroon.dasgupta.ch> <4CB30B83.1070508@lindenlab.com> <4CB36FB2.4000102@boroon.dasgupta.ch> <4CB38B4D.80004@boroon.dasgupta.ch> Message-ID: <4CB39CC5.90109@boroon.dasgupta.ch> On 10/12/2010 12:21 AM, CG Linden wrote: > Yay \o/ for "daggifying" :) Done: http://bitbucket.org/boroondas/vwr-23385 Ready for review. Cheers, Boroondas From miss_c_27 at yahoo.com Mon Oct 11 16:26:13 2010 From: miss_c_27 at yahoo.com (miss c) Date: Mon, 11 Oct 2010 16:26:13 -0700 (PDT) Subject: [opensource-dev] Translate hotkey? Message-ID: <741386.67474.qm@web82101.mail.mud.yahoo.com> Is there a translate hotkey, command or setting in the viewer that will translate note cards into your viewer language? Thanks, Miss -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101011/f998577b/attachment.htm From angel_of_crimson at hotmail.com Mon Oct 11 17:34:41 2010 From: angel_of_crimson at hotmail.com (Erin Mallory) Date: Mon, 11 Oct 2010 20:34:41 -0400 Subject: [opensource-dev] tos acceptance issues In-Reply-To: References: , Message-ID: theres already jiras about it yes. I do not have the numbers on hand, though i think somone else might have already mentioned the jira numbers. > From: akanevsky at productengine.com > Date: Mon, 11 Oct 2010 15:57:22 -0700 > Subject: Re: [opensource-dev] tos acceptance issues > To: angel_of_crimson at hotmail.com > CC: opensource-dev at lists.secondlife.com > > Erin, > Is there a JIRA that details which builds and which versions of 2.x > presented this problem? Repro steps? Which accounts were and were not > allowed to accept TOS? > > Thank you, > Anya > > 2010/10/8 Erin Mallory : > > As a user, it would be nice if the 2.x versions of SL would allow ALL > > accounts to accept the new terms of service instead of denying that option > > to all/some of them. > > Depending on the build, some versions of 2.x do not allow any accounts to > > accept tos even after cancel and reattempt. Some allow only some accounts > > to do so. this is like the third time this bug has resurfaced. can we > > please fix it so everyone can log in? > > > > _______________________________________________ > > Policies and (un)subscribe information available here: > > http://wiki.secondlife.com/wiki/OpenSource-Dev > > Please read the policies before posting to keep unmoderated posting > > privileges > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101011/4e306a87/attachment.htm From kf6kjg at gmail.com Mon Oct 11 21:58:12 2010 From: kf6kjg at gmail.com (Ricky) Date: Mon, 11 Oct 2010 21:58:12 -0700 Subject: [opensource-dev] Corrupted OpenGL & Hard Crash Message-ID: Server: Various beta grid sims Client: 2.1.2.210027 OS: Mac OS 10.6.4 with a 64bit kernel, on a newer Mac Mini Less than an hour ago I was on my first exploration of the beta grid (getting used to the place in prep for mesh!) and was flying around the regions connected to the first login location I found myself at. I explored for a couple of hours, running across normal laggy spots, region crossings, heavily scripted areas, etc., when suddenly my screen showed blocky interference across it. This covered the UI, so I snapped a screenshot just in case, and when I minimized SL I saw that my desktop was showing the same corruption so I took another shot. I figured that somehow SL had corrupted OpenGL, if that's even possible, I don't know, so I brought back up SL to close it... And then my system hardlocked. I couldn't even get access to force quit, even using the keyboard shortcuts. I eventually forced the system off by pressing and holding the power button. During the lockup I would occasionally be able to see and control my mouse cursor, but not all the time. Most of the rest of the screen never redrew, not even the menu bar. I have Activity Monitor docked up there so that I can keep an eye on CPU. CPU had been a constant low mid, and showed lower than the the screen shots when the system locked. I have the log from this session, if it would be helpful. However, the client never got to send a crash report, as far as I can tell. After the reboot, I tried running the same version of the SL client again, but it froze before it displayed again, so I force-quit it. The next run ran perfectly. So I quit it and made a copy of the SecondLife.old log so that I could keep it with the the images. Has anyone else run across anything remotely similar? I've done a cursory search of the JIRA, but nothing seemed to match for me. Ricky Cron Stardust -------------- next part -------------- A non-text attachment was scrubbed... Name: Screen shot 2010-10-11 at 9.00.51 PM.png Type: image/png Size: 1296244 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101011/33fb7582/attachment-0002.png -------------- next part -------------- A non-text attachment was scrubbed... Name: Screen shot 2010-10-11 at 9.01.18 PM.png Type: image/png Size: 2169241 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101011/33fb7582/attachment-0003.png From stickman at gmail.com Mon Oct 11 23:09:22 2010 From: stickman at gmail.com (Stickman) Date: Mon, 11 Oct 2010 23:09:22 -0700 Subject: [opensource-dev] Corrupted OpenGL & Hard Crash In-Reply-To: References: Message-ID: > Has anyone else run across anything remotely similar? ?I've done a > cursory search of the JIRA, but nothing seemed to match for me. Only time I've seen stuff like this was during GPU overheating, usually when a fan fails. It wasn't quite like this, however. More random data rather than rearranged data. But maybe a Mac handles it differently. And maybe it's not overheating at all. First thing I'd do, however, was check temperatures and make sure you don't have a cooling failure somewhere. Stickman From open at autistici.org Tue Oct 12 00:43:22 2010 From: open at autistici.org (Opensource Obscure) Date: Tue, 12 Oct 2010 08:43:22 +0100 Subject: [opensource-dev] simconsole is available for experimentation In-Reply-To: <4CB397BA.6080103@lindenlab.com> References: <4CB397BA.6080103@lindenlab.com> Message-ID: <1e43512c8215fe7c6684d4d8b20895a2@localhost> On Mon, 11 Oct 2010 16:03:22 -0700, Andrew Meadows wrote: > To open the console type: CTRL + SHIFT + ` (CTRL + SHIFT + backtick) this sounds awesome! :)) sorry to be picky about suck a trivial detail - in future releases, could you please change the shortcut to something I can type on my non-US keyboards? Backtick is not available on Italian keyboards, and I suspect this is true for other keyboard layouts as well. CTRL + SHIFT + J is available, as well as CTRL + SHIFT + U, and they're universal. Opensource Obscure From open at autistici.org Tue Oct 12 00:47:24 2010 From: open at autistici.org (Opensource Obscure) Date: Tue, 12 Oct 2010 08:47:24 +0100 Subject: [opensource-dev] =?utf-8?q?Translate_hotkey=3F?= In-Reply-To: <741386.67474.qm@web82101.mail.mud.yahoo.com> References: <741386.67474.qm@web82101.mail.mud.yahoo.com> Message-ID: <0cbefae1530365807ff851b5720fb5a5@localhost> On Mon, 11 Oct 2010 16:26:13 -0700 (PDT), miss c wrote: > Is there a translate hotkey, command or setting in the viewer that will > translate note cards into your viewer language? AFAIK no (not yet?) - the only translation system used in official viewers is about realtime translation of chat. Opensource Obscure From open at autistici.org Tue Oct 12 01:06:38 2010 From: open at autistici.org (Opensource Obscure) Date: Tue, 12 Oct 2010 09:06:38 +0100 Subject: [opensource-dev] tos acceptance issues In-Reply-To: References: , Message-ID: <650de56cd9a2871bff54f2b6f332909e@localhost> Hi Erin I'm sure you realize yourself that LL may not be going to work on that, if they don't have detailed jiras and precise direct links to those jiras. I could look for those jiras myself, then post the answer to the list, I'm not affected by this issue and my time is limited, so I'm going to pay attention to other bugs. Hopefully someone more directly concerned by this issue will do that. That's what I'd suggest you to do, by the way. Opensource Obscure On Mon, 11 Oct 2010 20:34:41 -0400, Erin Mallory wrote: > theres already jiras about it yes. I do not have the numbers on hand, > though i think somone else might have already mentioned the jira > numbers. > >> From: akanevsky at productengine.com >> Date: Mon, 11 Oct 2010 15:57:22 -0700 >> Subject: Re: [opensource-dev] tos acceptance issues >> To: angel_of_crimson at hotmail.com >> CC: opensource-dev at lists.secondlife.com >> >> Erin, >> Is there a JIRA that details which builds and which versions of 2.x >> presented this problem? Repro steps? Which accounts were and were not >> allowed to accept TOS? >> >> Thank you, >> Anya >> >> 2010/10/8 Erin Mallory : >> > As a user, it would be nice if the 2.x versions of SL would allow ALL >> > accounts to accept the new terms of service instead of denying that option >> > to all/some of them. >> > Depending on the build, some versions of 2.x do not allow any accounts to >> > accept tos even after cancel and reattempt. Some allow only some accounts >> > to do so. this is like the third time this bug has resurfaced. can we >> > please fix it so everyone can log in? >> > >> > _______________________________________________ >> > Policies and (un)subscribe information available here: >> > http://wiki.secondlife.com/wiki/OpenSource-Dev >> > Please read the policies before posting to keep unmoderated posting >> > privileges >> > From miss_c_27 at yahoo.com Tue Oct 12 01:07:05 2010 From: miss_c_27 at yahoo.com (miss c) Date: Tue, 12 Oct 2010 01:07:05 -0700 (PDT) Subject: [opensource-dev] LLTextbox ETA? Message-ID: <967515.85952.qm@web82108.mail.mud.yahoo.com> Is there an ETA on when LLTextbox will work in the official viewer? It only works in the Phoenix viewer. Thank you Miss -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101012/2849d0a9/attachment.htm From wolfpup67 at earthlink.net Tue Oct 12 05:56:24 2010 From: wolfpup67 at earthlink.net (WolfPup Lowenhar) Date: Tue, 12 Oct 2010 08:56:24 -0400 Subject: [opensource-dev] LLTextbox ETA? In-Reply-To: <967515.85952.qm@web82108.mail.mud.yahoo.com> References: <967515.85952.qm@web82108.mail.mud.yahoo.com> Message-ID: <000901cb6a0c$ef6a1610$ce3e4230$@net> Here is the relevant LL jira: https://jira.secondlife.com/browse/STORM-138 There you can see that the work has been done for the most part there it just needs to go through the final steps. From: opensource-dev-bounces at lists.secondlife.com [mailto:opensource-dev-bounces at lists.secondlife.com] On Behalf Of miss c Sent: Tuesday, October 12, 2010 4:07 AM To: opensource-dev at lists.secondlife.com Subject: [opensource-dev] LLTextbox ETA? Is there an ETA on when LLTextbox will work in the official viewer? It only works in the Phoenix viewer. Thank you Miss _____ No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1136 / Virus Database: 422/3191 - Release Date: 10/11/10 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101012/67fe71ac/attachment.htm From oz at lindenlab.com Tue Oct 12 06:46:13 2010 From: oz at lindenlab.com (Oz Linden (Scott Lawrence)) Date: Tue, 12 Oct 2010 09:46:13 -0400 Subject: [opensource-dev] Don't fork Beta Message-ID: <4CB466A5.5000501@lindenlab.com> Unless you are working on an issue that has already specifically been marked to be fixed in Beta, please don't use a clone of the viewer-beta branch; doing so makes it more difficult to cleanly pull your changes into viewer-development. From oz at lindenlab.com Tue Oct 12 07:28:00 2010 From: oz at lindenlab.com (Oz Linden (Scott Lawrence)) Date: Tue, 12 Oct 2010 10:28:00 -0400 Subject: [opensource-dev] Oz office hour change... Message-ID: <4CB47070.8040902@lindenlab.com> I've moved my Monday office hour back (earlier) by a half hour - it's now 07:00-08:00. The wiki calendar links and feeds have been updated. From sldev at free.fr Tue Oct 12 08:15:23 2010 From: sldev at free.fr (Henri Beauchamp) Date: Tue, 12 Oct 2010 17:15:23 +0200 Subject: [opensource-dev] simconsole is available for experimentation In-Reply-To: <4CB397BA.6080103@lindenlab.com> References: <4CB397BA.6080103@lindenlab.com> Message-ID: <20101012171523.7244503f.sldev@free.fr> I was curious about this new feature, but since I'm not using viewer 2 I just bacported it... You'll find attached to this message a patch which is a backport of the sim console to v1.23.5 (will also work with Snowglobe v1: there's one reject in CMakeList.txt but you can ignore it safely since it deals with the list of XML UI files which doesn't exist any more in SG1's CMakeList.txt file). The floater was also made resizable and the shortcut was changed to CTRL SHIFT C. The menu entry for opening the console is in Advanced -> Consoles. Note that for now, this feature seems pretty useless (only one variable available and you can't even change it). Type "help" in the console to get the list of commands and variables from the server. Henri. On Mon, 11 Oct 2010 16:03:22 -0700, Andrew Meadows wrote: > As mentioned in my office hours, and Oskar Linden's office hours last > week: > > Thanks to Brad and Falcon Linden the SL simulator will soon support a > very simple command line interface (CLI) console we're calling "simconsole". > The motivation for it was primarily for debug and prototyping, and > the list of commands available is currently very short, but we'll add > some more soon and maybe it will become a useful tool for intrepid > Residents. > > The simulator support is currently on the beta grid (aditi). It was just > promoted to the "Second Life Beta Server" channel today so is on most of > the regions there. It was previously on just four regions using the > "andrew-maint-server" channel. > > In order to play around with the simconsole you need viewer UI support. > I've just created a bitbucket clone of lindenlab/viewer-development with > the simconsole UI added for those who want to build and play around with > it. Clone or pull from here: > > http://bitbucket.org/andrew_linden/viewer-development > > To open the console type: CTRL + SHIFT + ` (CTRL + SHIFT + backtick) > > I think there is a "help" command, but otherwise there isn't any > documentation yet. > > You'll have to be an LL admin or estate manager to run any of the > commands that change anything. > > - Andrew -------------- next part -------------- A non-text attachment was scrubbed... Name: slviewer-0-v12350-FloaterSimConsole.patch.bz2 Type: application/octet-stream Size: 3491 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101012/2af4111b/attachment-0001.obj From sldev at free.fr Tue Oct 12 08:25:52 2010 From: sldev at free.fr (Henri Beauchamp) Date: Tue, 12 Oct 2010 17:25:52 +0200 Subject: [opensource-dev] Missing capabilities. Message-ID: <20101012172552.cff21494.sldev@free.fr> Hello, There are, in my opinion, missing capabilities for the new viewer 2 features, namely the capabilities dealing with inventory item links support, multiple attachments per point support, and multiple clothing layers support. Without the correpsonding capabilities, it is impossible for the viewer to adapt its sets of tools to the servers in OpenSim grids. Of course, I could just make the assumption that these features are only available in SL and then disable them for OpenSim, but I'm pretty sure they will appear in the latter, sooner or later... So, either LL implements the corresponding new capabilities in their server (and future viewer versions), or we would need OpenSim server developpers to "reserve" the capabilities (so that the viewer developpers may simply test for either the SL grids or the presence of the capabilities to decide whether the corresponding features should be enabled or not after login). It's also a bit worrying to see that LL doesn't seem to care much any more about backward compatibility (and therefore about OpenSim compatibility)... Any thought on this ? Henri. From kelly at lindenlab.com Tue Oct 12 08:37:42 2010 From: kelly at lindenlab.com (Kelly Linden) Date: Tue, 12 Oct 2010 08:37:42 -0700 Subject: [opensource-dev] Missing capabilities. In-Reply-To: <20101012172552.cff21494.sldev@free.fr> References: <20101012172552.cff21494.sldev@free.fr> Message-ID: I'm confused on this. While the term 'capability' is a bit vague, in SL development / programming it is very specific. It is not a flag that indicates the availability of a feature - it is an access point to access features. It has the great side benefit of being able to indicate the availability of those features by the presence of the capability. However not all features are new capabilities. What I'm getting at is that we shouldn't add dummy capabilities to indicate the presence of a features that doesn't use a capability. It sounds like we need some ability to indicate the availability of specific features - either some feature map or versioning on specific capabilities. If we extended the ability of an existing capability, perhaps we should have included a version in some way when we did so. If the feature did not use capabilities (the inventory is still a mix of legacy, event poll and capabilities isn't it?) - then perhaps there is another way to determine if the feature is supported. Or did I misunderstand the problem? - Kelly On Tue, Oct 12, 2010 at 8:25 AM, Henri Beauchamp wrote: > Hello, > > There are, in my opinion, missing capabilities for the new viewer 2 > features, namely the capabilities dealing with inventory item links > support, multiple attachments per point support, and multiple clothing > layers support. > > Without the correpsonding capabilities, it is impossible for the viewer > to adapt its sets of tools to the servers in OpenSim grids. Of course, > I could just make the assumption that these features are only available > in SL and then disable them for OpenSim, but I'm pretty sure they will > appear in the latter, sooner or later... > > So, either LL implements the corresponding new capabilities in their > server (and future viewer versions), or we would need OpenSim server > developpers to "reserve" the capabilities (so that the viewer developpers > may simply test for either the SL grids or the presence of the > capabilities to decide whether the corresponding features should be > enabled or not after login). > > It's also a bit worrying to see that LL doesn't seem to care much any > more about backward compatibility (and therefore about OpenSim > compatibility)... > > Any thought on this ? > > Henri. > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101012/5c2f75f1/attachment.htm From sldev at free.fr Tue Oct 12 11:38:50 2010 From: sldev at free.fr (Henri Beauchamp) Date: Tue, 12 Oct 2010 20:38:50 +0200 Subject: [opensource-dev] Missing capabilities. In-Reply-To: References: <20101012172552.cff21494.sldev@free.fr> Message-ID: <20101012203850.68458b18.sldev@free.fr> On Tue, 12 Oct 2010 08:37:42 -0700, Kelly Linden wrote: > I'm confused on this. While the term 'capability' is a bit vague, in SL > development / programming it is very specific. It is not a flag that > indicates the availability of a feature - it is an access point to access > features. It has the great side benefit of being able to indicate the > availability of those features by the presence of the capability. However > not all features are new capabilities. > > What I'm getting at is that we shouldn't add dummy capabilities to indicate > the presence of a features that doesn't use a capability. It sounds like we > need some ability to indicate the availability of specific features - either > some feature map or versioning on specific capabilities. If we extended the > ability of an existing capability, perhaps we should have included a version > in some way when we did so. If the feature did not use capabilities (the > inventory is still a mix of legacy, event poll and capabilities isn't it?) - > then perhaps there is another way to determine if the feature is supported. Be it by a "fake" capabilty (in the SL acception of the term) returning (for example) a simple "true" string, or by another mean (a map of flags returned by a new server message ?... But then we'd need to know if that server message is supported or not on the grid we connect to...), there is indeed a need for the viewer to know whether or not the servers (and this includes the assets server in the particular case of inventory links) can or cannot support the new features. The failure to know this and to take it into account in the viewer is one of the reasons why viewer 2 is incompatible with OpenSim grids (other reasons being viewer 2's inability to use asset server tiles for the world map, or hard coded URLs in the code, for example). So, yes, something should be done to correct this problem. Another nice thing to have would be to be able to determine on login whether the viewer connects to SL or to an OpenSim grid, since with the TPV policy and the differences between the existing grids TOS, the viewer may or may not use some features depending on the grid it connects to (so far I detect SL grids based on their URI (IP or plain text URI), but this is not as reliable as a returned value from the grid servers would be). Henri. From falcon at lindenlab.com Tue Oct 12 12:24:07 2010 From: falcon at lindenlab.com (Matthew (Falcon) Breindel) Date: Tue, 12 Oct 2010 12:24:07 -0700 Subject: [opensource-dev] simconsole is available for experimentation In-Reply-To: <1e43512c8215fe7c6684d4d8b20895a2@localhost> References: <4CB397BA.6080103@lindenlab.com> <1e43512c8215fe7c6684d4d8b20895a2@localhost> Message-ID: Hi Opensource, The console is also available under the 'Develop' menu (ctrl+alt+Q). It seems to keep moving around, but in the build I'm looking at it's under Develop | Network | Region Debug Console. In other builds I think it's in Develop | Consoles | Region Debug Console. I'll look into changing the shortcut anyway, though. Cheers, Falcon On Tue, Oct 12, 2010 at 12:43 AM, Opensource Obscure wrote: > On Mon, 11 Oct 2010 16:03:22 -0700, Andrew Meadows > wrote: > > > To open the console type: CTRL + SHIFT + ` (CTRL + SHIFT + backtick) > > this sounds awesome! :)) > > sorry to be picky about suck a trivial detail - in future releases, > could you > please change the shortcut to something I can type on my non-US > keyboards? > > Backtick is not available on Italian keyboards, and I suspect this is > true for > other keyboard layouts as well. > > CTRL + SHIFT + J is available, as well as CTRL + SHIFT + U, > and they're universal. > > Opensource Obscure > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101012/03bcc8fe/attachment.htm From akanevsky at productengine.com Tue Oct 12 13:56:34 2010 From: akanevsky at productengine.com (Anya Kanevsky) Date: Tue, 12 Oct 2010 13:56:34 -0700 Subject: [opensource-dev] Daily Scrum Summary - Tuesday, Oct 12 Message-ID: Date: Tue Oct 12 == GENERAL NOTES == * Merge Monkey of the Day: Merov ... again * Beta fixes should be done on a beta branch * With rare exceptions when we need to stabilize and release a beta, beta fixes should merged into Beta asap. == DAILY SCRUM == === Merov === PAST * STORM-365 (n? SH-277) "Attachments are visible in mouselook mode" : Took that one on, created patch, got it reviewed by davep, merged into beta * STORM-137: Got code review and tweaks from Techwolf. Merged in my dev branch. Builds on TC. Testing that on Linux and Windows before calling it done. * Merge monkeying on viewer-beta FUTURE * STORM-137: Test and ask for review (again) before integration (in v-d) * Beta monitoring and merge monkey-ing (merges, try to identify bugs I can contribute to) * OH * STORM-105 : Perf decompression: put new data out, check the work done by opensource-dev community on similar tests. * STORM-104: kdu upgrade IMPEDIMENTS * None ==Oz Linden== PAST * Proposed budget for open build service & code review system * Even more process review... * Pulled together lots of build changes, built and tested viewers FUTURE * Start updating develop.secondlife.com * Get the build fixes checked in to viewer-development IMPEDIMENTS * none === Q Linden=== PAST * HR (annual reviews) - finally done * Process work and long meetings * Accessibility meeting FUTURE * 2.2 Release * Unit test working IMPEDIMENTS * Antialiasing bug? (This is probably resolved - we need to get it to viewer-development) === Esbee Linden==== PAST * Viewer release process review * VWR triage * Systems requirements research * Accessibility meeting FUTURE * VWR triage * Discuss status of next beta release w/Q * Systems requirements analysis * Viewer 2.2 Release IMPEDIMENTS * None === Paul ProductEngine=== PAST: * STORM-211 Fade timer is reset for all toasts displayed in the notifications channel ** Today while testing found one case in which behavior is wrong. Investigating. Estimate ~ 4 hours. FUTURE: * STORM-211 Fade timer is reset for all toasts displayed in the notifications channel IMPEDIMENTS: * none === Seth Productengine === PAST: * BUG (STORM-294) Selection goes out of Favorites overflow list if scroll it by keyboard ** WIP. Currently fixed for only one scrolling direction. FUTURE: * BUG (STORM-294) Selection goes out of Favorites overflow list if scroll it by keyboard ** Estimated: 2-3 hours. IMPEDIMENTS: * none === Andrew Productengine === PAST: * Critical bug STORM-310 (crash after setting sound preferences) ** Tested on different builds and closed as cannot reproduce. * Bug STORM-301 (Camera view remains on Edit Appearance mode after undocked 'My Appearance' tab was minimized while being in 'Edit Outfit' mode) ** Fixed and sent for review. FUTURE: * STORM-362 ([HARD CODED] ALL LANGS: Unlocalized keyboard keys under Advanced menu > Shortcuts (French viewer)). IMPEDIMENTS: * none === Vadim Productengine === PAST: * Bug STORM-298 (My Landmarks panel scrolls down while deleting a landmark from Favorites bar): ** Fixed. FUTURE: * Bug STORM-290 (Home SP is white and does not contain any information after clearing Viewer settings on PC) ** ETA 3h. * Subtasks of STORM-304 (disable URL higlighting in various places) -- ETA 4h ** STORM-358 (... in the nearby chat toasts) ** STORM-359 (... in the llGiveInventory dlg) ** STORM-360 (... in Message Well window) IMPEDIMENTS: * none === Andrey Productengine === === Grumpity === PAST * crashhunters * viewer release process * QA synch notes & followup * Split STORM-315 (Changes to environment editor) into 3 new issues in VWR FUTURE: * ooo 11am - 1pm * STORM-313 (pending Esbee's office hour wednesday) * STORM-182 (Uninstaling beta deletes logs) - needs a home * STORM-316 (inventory debug settings) IMPEDIMENTS: * none From kelly at lindenlab.com Tue Oct 12 14:06:02 2010 From: kelly at lindenlab.com (Kelly Linden) Date: Tue, 12 Oct 2010 14:06:02 -0700 Subject: [opensource-dev] Broken Rubber Bands In-Reply-To: References: <1286031980.2164.4.camel@glen-desktop> <4CB47226.5020601@SLFBI.com> Message-ID: If anyone is interested his code is here: http://bitbucket.org/simon_linden/viewer-dev cc'ing the opensource-dev list as this seems appropriate for that list at this point. - Kelly On Tue, Oct 12, 2010 at 8:27 AM, Kelly Linden wrote: > Actually one of my coworkers has been working on some features along these > lines. The two parts I'm aware of prevent flying into the horizon if there > is no neighbor sim and some attenuation of movement if it has been too long > since getting an update from the sim. He was also working on some region > crossing specific bits to try and improve the prediction logic and reduce > rubber banding, however he was getting mixed results on that front. > > I've forwarded him your email just so he has another data point, and I'll > see if I can't find his repo to share should anyone want to give his patches > a try. > > - Kelly > > On Tue, Oct 12, 2010 at 7:35 AM, AnnMarie at SLFBI.com wrote: > >> Border crossing rubber-banding, especially when riding a vehicle, can >> vary from zero to annoying to purgatory to re-boot depending on the >> severity. >> My current SLURL is sim Sunell, <60902, 26106???, -136289?????> which >> puts me at least 13 billion meters below ground on my way to SL hell. >> It will require a re-log to recover. >> >> DUH. The client side viewer would not have to be very smart to figure >> out something was wrong and discontinue stretching a rubber band that is >> obviously broken. >> >> Why cannot the viewer and server have a simple uplink command that says >> "I'm totally lost, please put me back at the last known vector"? It >> could even have a popup to explain you have been restored to an earlier >> valid location. >> >> _______________________________________________ >> Click here to unsubscribe or manage your list subscription: >> https://lists.secondlife.com/cgi-bin/mailman/listinfo/secondlifescripters >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101012/dcc0fb59/attachment.htm From simon at lindenlab.com Tue Oct 12 14:38:45 2010 From: simon at lindenlab.com (Simon Linden) Date: Tue, 12 Oct 2010 14:38:45 -0700 Subject: [opensource-dev] Broken Rubber Bands In-Reply-To: References: <1286031980.2164.4.camel@glen-desktop> <4CB47226.5020601@SLFBI.com> Message-ID: Hi - Yes, I updated that repository with my first attempt at improving the viewer prediction code. The changes are: * Configurable settings for tapering off viewer-side motion prediction * Limit predicted motion at region edges based on adjacent regions * Bug fixes around region crossing timers and object positions I just spent some time looking into the server code, however, and see that the viewer needs more refinement. The server expects the viewer motion prediction code to follow the velocity and acceleration it sent to the viewer, so my new taper-off code should not kick in unless the simulator stops sending updates (which would indicate a bad lag event, rather than no updates due to constant motion). Some of my changes should help, however. The viewer will check the edge of the region, and if there is no neighbor region, stops the object motion. Normally the simulator will send down another update quickly as the object bounces off the edge, but this prevents the sail-into-the-sunset effect when the simulator lags badly. Predicted object motion is also pinned to the allowable underground distance and top of the region. I did some experiments with region crossings and attempts to predict some lag but didn't find a solution that worked well. As AnnMarie mentioned, vehicle crossings seem to be the worst and I'll be looking into that next. The viewer can probably be more intelligent on how it predicts region crossings, perhaps allowing for a bit of lag with normal objects and possibly accounting for the re-seating of AVs on vehicles, but I haven't worked out the details yet. - Simon Linden On Tue, Oct 12, 2010 at 2:06 PM, Kelly Linden wrote: > If anyone is interested his code is here: > http://bitbucket.org/simon_linden/viewer-dev > > cc'ing the opensource-dev list as this seems appropriate for that list at > this point. > > - Kelly > > On Tue, Oct 12, 2010 at 8:27 AM, Kelly Linden wrote: > >> Actually one of my coworkers has been working on some features along these >> lines. The two parts I'm aware of prevent flying into the horizon if there >> is no neighbor sim and some attenuation of movement if it has been too long >> since getting an update from the sim. He was also working on some region >> crossing specific bits to try and improve the prediction logic and reduce >> rubber banding, however he was getting mixed results on that front. >> >> I've forwarded him your email just so he has another data point, and I'll >> see if I can't find his repo to share should anyone want to give his patches >> a try. >> >> - Kelly >> >> On Tue, Oct 12, 2010 at 7:35 AM, AnnMarie at SLFBI.com wrote: >> >>> Border crossing rubber-banding, especially when riding a vehicle, can >>> vary from zero to annoying to purgatory to re-boot depending on the >>> severity. >>> My current SLURL is sim Sunell, <60902, 26106???, -136289?????> which >>> puts me at least 13 billion meters below ground on my way to SL hell. >>> It will require a re-log to recover. >>> >>> DUH. The client side viewer would not have to be very smart to figure >>> out something was wrong and discontinue stretching a rubber band that is >>> obviously broken. >>> >>> Why cannot the viewer and server have a simple uplink command that says >>> "I'm totally lost, please put me back at the last known vector"? It >>> could even have a popup to explain you have been restored to an earlier >>> valid location. >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101012/b0a234ac/attachment.htm From daleinnisemail at gmail.com Tue Oct 12 14:51:58 2010 From: daleinnisemail at gmail.com (Dale Innis) Date: Tue, 12 Oct 2010 17:51:58 -0400 Subject: [opensource-dev] Broken Rubber Bands In-Reply-To: References: <1286031980.2164.4.camel@glen-desktop> <4CB47226.5020601@SLFBI.com> Message-ID: On Tue, Oct 12, 2010 at 5:38 PM, Simon Linden wrote: > Some of my changes should help, however.? The viewer will check the edge of > the region, and if there is no neighbor region, stops the object motion. >? Predicted object motion is also pinned to the > allowable underground distance and top of the region. These will be major, and very welcome, changes to the SL experience! (Not to mention giving us oldbies one more class of "In my day..." stories to tell...) From dahliatrimble at gmail.com Tue Oct 12 16:29:34 2010 From: dahliatrimble at gmail.com (Dahlia Trimble) Date: Tue, 12 Oct 2010 16:29:34 -0700 Subject: [opensource-dev] Broken Rubber Bands In-Reply-To: References: <1286031980.2164.4.camel@glen-desktop> <4CB47226.5020601@SLFBI.com> Message-ID: Could checking to see if a user is still pressing a movement key fit into the algorithm? It seems it could be a useful input to help determine if the user really wants to continue along a dead-reckoning path. On Tue, Oct 12, 2010 at 2:51 PM, Dale Innis wrote: > On Tue, Oct 12, 2010 at 5:38 PM, Simon Linden wrote: > > > Some of my changes should help, however. The viewer will check the edge > of > > the region, and if there is no neighbor region, stops the object motion. > > > Predicted object motion is also pinned to the > > allowable underground distance and top of the region. > > These will be major, and very welcome, changes to the SL experience! > > (Not to mention giving us oldbies one more class of "In my day..." > stories to tell...) > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101012/ac9c6396/attachment.htm From sllists at boroon.dasgupta.ch Tue Oct 12 16:30:52 2010 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Wed, 13 Oct 2010 01:30:52 +0200 Subject: [opensource-dev] quick smoke test (was: Remaining build issues for 64bit linux standalone out-of-source (without unit tests)) In-Reply-To: <4CB34388.7030903@lindenlab.com> References: <4C766008.1070001@boroon.dasgupta.ch> <4C78DB67.5040005@boroon.dasgupta.ch> <4C7D501C.5040709@boroon.dasgupta.ch> <4C7E37E7.5080105@boroon.dasgupta.ch> <4CACFB0C.2020808@boroon.dasgupta.ch> <4CB34388.7030903@lindenlab.com> Message-ID: <4CB4EFAC.8070405@boroon.dasgupta.ch> On 10/11/2010 07:04 PM, Oz Linden (Scott Lawrence) wrote: > On 2010-10-06 18:41, Boroondas Gupte wrote: >> [...] >> >> VWR-23047 (aka >> SNOW-512 / SNOW-287): PIC required for standalone >> [...] >> STORM-222 : expat.h not >> found on STANDALONE >> [...] >> VWR-23296 : missing >> LL_TEST conditions (i.e. SNOW-651 >> *+* SNOW-654 >> ) >> [...] >> STORM-275 (a.k.a. >> VWR-20893): "class Linux_x86_64Manifest" missing from >> viewer_manifest.py Breaking linux 64-bit build. >> [...] > > I've posted a build made with all of the above except VWR-23296 > (global switch to disable tests - see my other reply to this thread) at: > http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repo/oz_viewer-review1/rev/211764/index.html > > All platforms built, and since that's what these changes were about > it's probably good. The Mac version appears to be working fine - if a > few people could do a quick smoke test of the other platforms and > report all clear, then I'll push these changes into viewer-development. Looks good, I guess. While testing I noticed that STORM-312 / VWR-19643 (spacenavigator not working with recent Linux kernels) is still broken in LL builds. But this isn't related to these changes and affects all other LL builds, too. LL should upgrade libndofdev on Linux (no code changes needed and new lib version will work fine with old kernels, too.) Cheers, Boroondas -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101013/934884d3/attachment.htm From nexiim at gmail.com Tue Oct 12 16:46:54 2010 From: nexiim at gmail.com (Nexii Malthus) Date: Wed, 13 Oct 2010 00:46:54 +0100 Subject: [opensource-dev] Broken Rubber Bands In-Reply-To: References: <1286031980.2164.4.camel@glen-desktop> <4CB47226.5020601@SLFBI.com> Message-ID: Yeah, that is true. It should be able to detect the very source that causes most movements. There might be issues on scripts that influence an avatars movements via control events though, while that could be avoided by checking if control events have been taken, it might misidentify scripts that take controls but don't act on physics, such as AOs. I think the simulator could have a much better prediction system itself as well, it shouldn't all fall on the client. For example if an avatar presses forward, the simulator should "jump" the avatar forwards as if the avatar had pressed forwards back in time by their average ping time. This would make it appear as if the sim is more responsive. The client could also then simulate the forwards movement instantenously. Modern FPS games have even smarter methods for synchronizing and predicting physics accurately, such as tracking the recent positions of all players and then 'correcting' recent collisions based on the players' connections in realtime. - Nexii On Wed, Oct 13, 2010 at 12:29 AM, Dahlia Trimble wrote: > Could checking to see if a user is still pressing a movement key fit into > the algorithm? It seems it could be a useful input to help determine if the > user really wants to continue along a dead-reckoning path. > > > On Tue, Oct 12, 2010 at 2:51 PM, Dale Innis wrote: > >> On Tue, Oct 12, 2010 at 5:38 PM, Simon Linden >> wrote: >> >> > Some of my changes should help, however. The viewer will check the edge >> of >> > the region, and if there is no neighbor region, stops the object motion. >> >> > Predicted object motion is also pinned to the >> > allowable underground distance and top of the region. >> >> These will be major, and very welcome, changes to the SL experience! >> >> (Not to mention giving us oldbies one more class of "In my day..." >> stories to tell...) >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/OpenSource-Dev >> Please read the policies before posting to keep unmoderated posting >> privileges >> > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101013/69119367/attachment.htm From kelly at lindenlab.com Tue Oct 12 16:56:29 2010 From: kelly at lindenlab.com (Kelly Linden) Date: Tue, 12 Oct 2010 16:56:29 -0700 Subject: [opensource-dev] Broken Rubber Bands In-Reply-To: References: <1286031980.2164.4.camel@glen-desktop> <4CB47226.5020601@SLFBI.com> Message-ID: It is true - the server could use improvements and they could both do with working better together. And this is something we want to do, eventually. However these specific changes are about addressing some of the worst offenders - the blatently horrible cases where you fly off into the sunset because the sim or network hiccups or maybe even prevent you from spiraling into the ground when you drive across a border. Lets avoid designing or re-designing full-on client side physics and movement prediction here, for now. :) - Kelly On Tue, Oct 12, 2010 at 4:46 PM, Nexii Malthus wrote: > Yeah, that is true. It should be able to detect the very source that causes > most movements. There might be issues on scripts that influence an avatars > movements via control events though, while that could be avoided by checking > if control events have been taken, it might misidentify scripts that take > controls but don't act on physics, such as AOs. > > I think the simulator could have a much better prediction system itself as > well, it shouldn't all fall on the client. > > For example if an avatar presses forward, the simulator should "jump" the > avatar forwards as if the avatar had pressed forwards back in time by their > average ping time. This would make it appear as if the sim is more > responsive. The client could also then simulate the forwards movement > instantenously. > > Modern FPS games have even smarter methods for synchronizing and predicting > physics accurately, such as tracking the recent positions of all players and > then 'correcting' recent collisions based on the players' connections in > realtime. > > - Nexii > > > On Wed, Oct 13, 2010 at 12:29 AM, Dahlia Trimble wrote: > >> Could checking to see if a user is still pressing a movement key fit into >> the algorithm? It seems it could be a useful input to help determine if the >> user really wants to continue along a dead-reckoning path. >> >> >> On Tue, Oct 12, 2010 at 2:51 PM, Dale Innis wrote: >> >>> On Tue, Oct 12, 2010 at 5:38 PM, Simon Linden >>> wrote: >>> >>> > Some of my changes should help, however. The viewer will check the >>> edge of >>> > the region, and if there is no neighbor region, stops the object >>> motion. >>> >>> > Predicted object motion is also pinned to the >>> > allowable underground distance and top of the region. >>> >>> These will be major, and very welcome, changes to the SL experience! >>> >>> (Not to mention giving us oldbies one more class of "In my day..." >>> stories to tell...) >>> _______________________________________________ >>> Policies and (un)subscribe information available here: >>> http://wiki.secondlife.com/wiki/OpenSource-Dev >>> Please read the policies before posting to keep unmoderated posting >>> privileges >>> >> >> >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/OpenSource-Dev >> Please read the policies before posting to keep unmoderated posting >> privileges >> > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101012/ffdac046/attachment-0001.htm From wolfpup67 at earthlink.net Tue Oct 12 18:42:59 2010 From: wolfpup67 at earthlink.net (WolfPup Lowenhar) Date: Tue, 12 Oct 2010 21:42:59 -0400 Subject: [opensource-dev] LL_TESTS for standalone out-of-source builds (was: Remaining build issues for 64bit linux standalone out-of-source (without unit tests)) In-Reply-To: <4CB38B4D.80004@boroon.dasgupta.ch> References: <4C766008.1070001@boroon.dasgupta.ch> <4C78DB67.5040005@boroon.dasgupta.ch> <4C7D501C.5040709@boroon.dasgupta.ch> <4C7E37E7.5080105@boroon.dasgupta.ch> <4CACFB0C.2020808@boroon.dasgupta.ch> <4CB30B83.1070508@lindenlab.com> <4CB36FB2.4000102@boroon.dasgupta.ch> <4CB38B4D.80004@boroon.dasgupta.ch> Message-ID: <000001cb6a77$f7db0690$e79113b0$@net> On the subject of the reason for killing test here is another reason that I have attached this is from a full build I did today. The error listed in the file is actually coded around and in visual studio you have to set that test to not treat warnings as errors so that it will not fail! From: opensource-dev-bounces at lists.secondlife.com [mailto:opensource-dev-bounces at lists.secondlife.com] On Behalf Of Boroondas Gupte Sent: Monday, October 11, 2010 6:10 PM To: opensource-dev at lists.secondlife.com Subject: [opensource-dev] LL_TESTS for standalone out-of-source builds (was: Remaining build issues for 64bit linux standalone out-of-source (without unit tests)) On 10/11/2010 10:12 PM, Boroondas Gupte wrote: In fact, my plan for the time after having gotten all build fixes I need with LL_TESTS set to FALSE into viewer-development (which I hope will be soon) was to set LL_TESTS back on TRUE and hunt down the change(s) needed to build like that. (We already had these fixes in Snowglobe 2. I hope nothing new got broken regarding unit tests, since then.) Looks like Aleric's patch from SNOW-756 (which still applies :-) ) is all that's needed, so I moved that to VWR-23385 and will daggify that fix ASAP. With this change, all tests succeed on my machine. YAY!! \o/ Cheers, Boroondas _____ No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1136 / Virus Database: 422/3191 - Release Date: 10/11/10 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101012/83a0f044/attachment-0002.htm -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101012/83a0f044/attachment-0003.htm From missannotoole at yahoo.com Tue Oct 12 22:21:57 2010 From: missannotoole at yahoo.com (Ann Otoole) Date: Tue, 12 Oct 2010 22:21:57 -0700 (PDT) Subject: [opensource-dev] Local Lights In-Reply-To: References: Message-ID: <869961.31146.qm@web120516.mail.ne1.yahoo.com> When is the last time anyone checked on local lights. I recall that 7 limit was removed a ways back and then during a discussion people were still saying there was a limit of 7. So I decided to test it. This is the current LL SLv2 Beta with ultra and everything settable in the UI maxed: http://annotoole.com/images/256locallightsonLLbeta.png This is in Kirstens S20(39) with the lighting on: http://annotoole.com/images/256locallightsonkirstensS20%2839%29.png Yes that is two hundred and fifty six local lights on in that screenshot. In the SLv2 Beta only 2 local lights worked at all. Any reason why the capabilities of the LL viewer keep being ratcheted down? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101012/80b72bb8/attachment.htm From leliel.mirihi at gmail.com Wed Oct 13 00:30:59 2010 From: leliel.mirihi at gmail.com (leliel) Date: Wed, 13 Oct 2010 00:30:59 -0700 Subject: [opensource-dev] Local Lights In-Reply-To: <869961.31146.qm@web120516.mail.ne1.yahoo.com> References: <869961.31146.qm@web120516.mail.ne1.yahoo.com> Message-ID: On Tue, Oct 12, 2010 at 10:21 PM, Ann Otoole wrote: > When is the last time anyone checked on local lights. I recall that 7 limit > was removed a ways back and then during a discussion people were still > saying there was a limit of 7. So I decided to test it. The limit was never raised. The OpenGL fixed function pipleline only supports a maximum of 8 light sources, this has been true for the last 20 years. > In the SLv2 Beta only 2 local lights worked at all. That's a bug, there's a jira entry for it somewhere. > Any reason why the capabilities of the LL viewer keep being ratcheted down? This isn't a fare comparison. Kirsten's viewer has deferred rendering enabled by default, which lets it render an effectively infinite number of light sources. The official viewer still uses the fixed function lights since the deferred rendering code isn't quite production ready. If you test again with them both using either deferred or fixed function lighting they will behave the same. From tillie at xp2.de Wed Oct 13 03:35:49 2010 From: tillie at xp2.de (tillie at xp2.de) Date: Wed, 13 Oct 2010 12:35:49 +0200 (CEST) Subject: [opensource-dev] [JIRA] Commented: (SH-157) [VWR-21040] UI:Preferences/Graphics/Advanced: Local lights on/off is missing Message-ID: <1286966149.917@xp2.de> Runitai Linden (JIRA) wrote .. > Runitai Linden commented on SH-157: > ----------------------------------- > > That setting probably isn't coming back since so few people use it. As a work > around if you REALLY want to disable local lights on your machine, open the advanced > menu (Ctrl-alt-D), go to Advanced->Debug Settings, and modify the setting "RenderShaderLightingMaxLevel" > to "1", then reload shaders by toggling some setting in preferences or relog. > I just put in a change that reloads shaders automatically whenever this value changes, > so that last step won't be necessary forever. Please tell me that is a persistant toggle? There are already so many things I have to enable/disable manually EACH TIME after relog. :-( Removing toggles like that for enabling/disabling local lights is big annoyance for me. I always thought you wanted to improve the client, not make it worse. I am paying for 1 1/2 sims right now, but I somehow have the feeling you not really care about us customers. Tillie From open at autistici.org Wed Oct 13 04:10:54 2010 From: open at autistici.org (Opensource Obscure) Date: Wed, 13 Oct 2010 12:10:54 +0100 Subject: [opensource-dev] [JIRA] Commented: (SH-157) [VWR-21040] UI:Preferences/Graphics/Advanced: Local lights on/off is missing In-Reply-To: <1286966149.917@xp2.de> References: <1286966149.917@xp2.de> Message-ID: <059617df159a9dd068bb9c4ac4d920dc@localhost> On Wed, 13 Oct 2010 12:35:49 +0200 (CEST), tillie at xp2.de wrote: > Please tell me that is a persistant toggle? You can easily launch the SL viewer using your customized advanced settings (no need to manually tweak them) by creating one (or more) specific desktop icons or menu entries, where the viewer is called with your favorite settings. AFAIK, all Debug Settings can be set this way before logging in - just add "-set SettingName SETTINGVALUE". This will work even if a setting is not session-persistant. HTH, Opensource Obscure From sllists at boroon.dasgupta.ch Wed Oct 13 04:37:23 2010 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Wed, 13 Oct 2010 13:37:23 +0200 Subject: [opensource-dev] LLMatrix3::orthogonalize test (was: LL_TESTS for standalone out-of-source builds) In-Reply-To: <000001cb6a77$f7db0690$e79113b0$@net> References: <4C766008.1070001@boroon.dasgupta.ch> <4C78DB67.5040005@boroon.dasgupta.ch> <4C7D501C.5040709@boroon.dasgupta.ch> <4C7E37E7.5080105@boroon.dasgupta.ch> <4CACFB0C.2020808@boroon.dasgupta.ch> <4CB30B83.1070508@lindenlab.com> <4CB36FB2.4000102@boroon.dasgupta.ch> <4CB38B4D.80004@boroon.dasgupta.ch> <000001cb6a77$f7db0690$e79113b0$@net> Message-ID: <4CB599F3.6090807@boroon.dasgupta.ch> On 10/13/2010 03:42 AM, WolfPup Lowenhar wrote: > > On the subject of the reason for killing test here is another reason > that I have attached this is from a full build I did today. The error > listed in the file is actually coded around and in visual studio you > have to set that test to not treat warnings as errors so that it will > not fail! > I tried removing the skip line to re-enable the test, like so: *diff -r 27535365bd4c indra/llmath/tests/m3math_test.cpp* --- a/indra/llmath/tests/m3math_test.cpp Fri Oct 08 01:13:23 2010 +0200 +++ b/indra/llmath/tests/m3math_test.cpp Wed Oct 13 13:16:30 2010 +0200 @@ -280,7 +280,6 @@ llmat_obj.setRows(llvec1, llvec2, llvec3); llmat_obj.orthogonalize(); - skip("Grr, LLMatrix3::orthogonalize test is failing. Has it ever worked?"); ensure("LLMatrix3::orthogonalize failed ", is_approx_equal(0.19611613f, llmat_obj.mMatrix[0][0]) && is_approx_equal(0.78446454f, llmat_obj.mMatrix[0][1]) && On my system that test seems to work fine after that: LD_LIBRARY_PATH += ['/home/das-g/slsrc/hg/build/build/llcommon', '/usr/lib', '/usr/local/lib'] LD_LIBRARY_PATH = '/usr/local/lib:/home/das-g/slsrc/hg/build/build/llcommon:/usr/lib' Running: /home/das-g/slsrc/hg/build/build/llmath/INTEGRATION_TEST_m3math Unit test group_started name=m3math_h Unit test group_completed name=m3math_h Total Tests: 13 Passed Tests: 13 YAY!! \o/ Maybe someone has fixed LLMatrix3::orthogonalize but forgot to re-enable the test? Or is LLMatrix3::orthogonalize behaving differently on different platforms? (That should affect quaternion calculations and auto-leveling in Flycam mode, so it's unlikely to go unnoticed.) Anyway, would be good if others could re-enable the test, too, and see whether it also passes for them. Cheers, Boroondas PS: LLMatrix3::orthogonalize is a bit of a misnomer. Without having looked at its code (just at input and desired output in the test) it seems to orthogonalize *and* normalize (or "ortho*normalize*" for short). Should the method be renamed to reflect this? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101013/dc1f7d20/attachment.htm From oz at lindenlab.com Wed Oct 13 05:05:16 2010 From: oz at lindenlab.com (Oz Linden (Scott Lawrence)) Date: Wed, 13 Oct 2010 08:05:16 -0400 Subject: [opensource-dev] quick smoke test In-Reply-To: <4CB4EFAC.8070405@boroon.dasgupta.ch> References: <4C766008.1070001@boroon.dasgupta.ch> <4C78DB67.5040005@boroon.dasgupta.ch> <4C7D501C.5040709@boroon.dasgupta.ch> <4C7E37E7.5080105@boroon.dasgupta.ch> <4CACFB0C.2020808@boroon.dasgupta.ch> <4CB34388.7030903@lindenlab.com> <4CB4EFAC.8070405@boroon.dasgupta.ch> Message-ID: <4CB5A07C.5080203@lindenlab.com> On 2010-10-12 19:30, Boroondas Gupte wrote: > Looks good, I guess. While testing I noticed that STORM-312 > / VWR-19643 > (spacenavigator not > working with recent Linux kernels) is still broken in LL builds. But > this isn't related to these changes and affects all other LL builds, > too. LL should upgrade libndofdev on Linux (no code changes needed and > new lib version will work fine with old kernels, too.) Changes are all committed to viewer-development. We'll deal with the spacenavigator issue separately ... probably time to do a comprehensive review of all lib dependencies and see what else needs upgrading. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101013/51b7272f/attachment.htm From kf6kjg at gmail.com Wed Oct 13 15:02:30 2010 From: kf6kjg at gmail.com (Ricky) Date: Wed, 13 Oct 2010 15:02:30 -0700 Subject: [opensource-dev] Shadows of Ruth Message-ID: Sounds like a really cool title for a book... However, I just logged into Aditi using the new Mesh project viewer, and find myself a foggy cloud. That's OK, I know how to clear that up, and I don't really care anyways. Then I found myself ecstatic to be (finally) able to active shadows! (Looks really cool!) And then I noticed it. Even though I was a cloud, my shadow was that of the old Ruth. Hrm.... Not too big an issue, as the Cloud/Ruth goes away pretty quickly normally, but might want looking at. (And no, I was too lazy to go looking for applicable JIRAs.. I'm in Aditi with this viewer, skipping some critical schoolwork, for a very specific reason... :P ) Ricky Cron Stardust From akanevsky at productengine.com Wed Oct 13 18:14:32 2010 From: akanevsky at productengine.com (Anya Kanevsky) Date: Wed, 13 Oct 2010 18:14:32 -0700 Subject: [opensource-dev] Daily Scrum Summary - Wednesday, October 13 Message-ID: I haven't been putting this header in, but as usual, every day's summary is available on the wiki: http://wiki.secondlife.com/wiki/Snowstorm_Daily_Scrum_Archive Date: Wed Oct 13 == GENERAL NOTES == * Merge Monkey of the Day: Oz == DAILY SCRUM == === Merov === PAST * STORM-137: Ready for review. * STORM-104: kdu upgrade: Started to move things around quite a bit in preparation of that change... * External build: worked with team chopper to understand what was going wrong there. Got some insight in this. * OH FUTURE * Beta monitoring and merge monkey-ing (merges, try to identify bugs I can contribute to) * STORM-104: kdu upgrade * STORM-105 : Perf decompression: put new data out, check the work done by opensource-dev community on similar tests. IMPEDIMENTS * None ==Oz Linden== PAST * Updating develop.secondlife.com (changes not yet published) * Build fixes checked in to viewer-development ** STORM-222 ** STORM-275 ** STORM-368 ** STORM-374 * Helped with merge problem in mesh development * Reviewed and checked in fixes for STORM-137 and STORM-367 FUTURE * Figure out how to test updated libcurl VWR-22780 ** So that we can unblock VWR-20801 (socks 5 proxy) * Merge Monkey ** Pull outstanding beta fixes ** Drain Snowstorm integration queue * More changes to develop site * Office Hour IMPEDIMENTS * none === Q Linden=== PAST * Release * Office hours FUTURE * Release * Now worried about STORM-381 * Testing * OOO tomorrow fri IMPEDIMENTS * Release * Gotta slow down personally === Esbee Linden==== PAST * Viewer release process review * Viewer 2.2 Beta & Release prep * VWR triage * Systems requirements research FUTURE * Write Viewer 2.2 Release blog post * VWR triage * Systems requirements analysis * Viewer 2.2 Release * Office Hours * Playing with the Mesh Project Viewer! IMPEDIMENTS * None === Paul ProductEngine=== PAST: * STORM-211 Fade timer is reset for all toasts displayed in the notifications channel ** Today while testing found one case in which behavior is wrong. Will give VS this bug. FUTURE: * Other tickets by priority IMPEDIMENTS: * none === Seth Productengine === PAST: * BUG (STORM-294) Selection goes out of Favorites overflow list if scroll it by keyboard ** Fixed. Reassigned for reviewing. FUTURE: * BUG (STORM-303) Favorites folder content isn't refreshed while re-ordering landmaks ** Estimated: 6-8 hours. IMPEDIMENTS: * none === Andrew Productengine === PAST: * STORM-362 ([HARD CODED] ALL LANGS: Unlocalized keyboard keys under Advanced menu > Shortcuts (French viewer)) ** Found Eli's recent changeset with fix and closed as cannot reproduce. * Bug STORM-279 (Inability to uncheck avatar cloth in Ultra graphics settings, despite debug setting working) ** Fixed and sent for review. * Bug STORM-322 (Group Member Search: gives more entries then the search string suggests) ** Investigated. Estimate- 8 hours. FUTURE: * Bug STORM-322 (Group Member Search: gives more entries then the search string suggests). IMPEDIMENTS: * none === Vadim Productengine === PAST: * Bug STORM-358 (URL-name of object is shown as a hyperlink in the nearby chat toasts) : ** Fixed. * Bug STORM-359 (URL-name of object is shown as a hyperlink in the llGiveInventory dlg): ** Fixed. * Bug STORM-360 (URL-name of object is shown as a hyperlink in Message Well window): ** Fixed. * Bug STORM-290 (Home SP is white and does not contain any information after clearing Viewer settings on PC): ** Investigated, resolved as not reproducible (intermittent server problem). * Filed bug STORM-376 (Toast close button sometimes doesn't disappear), investigated, found its reason. FUTURE: * If no higher priority tasks arise, will ** fix bug STORM-376 ** take something from the viewer-development backlog. IMPEDIMENTS: * none === Andrey Productengine === PAST: * integrity tests against 211863 at v-d done * smoke tests almost done (couple of tests left for OSX build) * planned regression subset completed on 43% FUTURE: * complete regression 211863 at v-d regression testing IMPEDIMENTS: * none === Grumpity === PAST * crashhunters * viewer release process * QA synch notes & followup * Split STORM-315 (Changes to environment editor) into 3 new issues in VWR FUTURE: * ooo 11am - 1pm * STORM-313 (pending Esbee's office hour wednesday) * STORM-182 (Uninstaling beta deletes logs) - needs a home * STORM-316 (inventory debug settings) IMPEDIMENTS: * none From sllists at boroon.dasgupta.ch Thu Oct 14 05:19:51 2010 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Thu, 14 Oct 2010 14:19:51 +0200 Subject: [opensource-dev] LLMatrix3::orthogonalize test In-Reply-To: References: <4C766008.1070001@boroon.dasgupta.ch> <4C78DB67.5040005@boroon.dasgupta.ch> <4C7D501C.5040709@boroon.dasgupta.ch> <4C7E37E7.5080105@boroon.dasgupta.ch> <4CACFB0C.2020808@boroon.dasgupta.ch> <4CB30B83.1070508@lindenlab.com> <4CB36FB2.4000102@boroon.dasgupta.ch> <4CB38B4D.80004@boroon.dasgupta.ch> <000001cb6a77$f7db0690$e79113b0$@net> <4CB599F3.6090807@boroon.dasgupta.ch> Message-ID: <4CB6F567.9050605@boroon.dasgupta.ch> On 10/14/2010 08:05 AM, Celierra Darling wrote: > For matrices, "orthogonal matrix" implies orthonormal rows and columns. Ah, right, I forgot. Thanks for the reminder. (I /should/ have known that.) > It's a bit confusing, but that's the real way the term is used > (see http://en.wikipedia.org/wiki/Orthogonal_matrix ).... Yeah, I was somehow thinking of bases rather than matrices. Bases can of course be orthogonal without the basis vectors being unit vectors, and vice versa. While we can (and apparently do in the SL code) represent bases as matrices, as long as the class is called something with "Matrix", its methods should adhere to the matrix terminology, of course, so it's fine to stick with the current name. Cheers, Boroondas -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101014/0bf6579e/attachment.htm From sllists at boroon.dasgupta.ch Thu Oct 14 12:06:44 2010 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Thu, 14 Oct 2010 21:06:44 +0200 Subject: [opensource-dev] VWR-23239: memory leak in LLUIString In-Reply-To: <4CA4AFF1.9@boroon.dasgupta.ch> References: <4C9C9256.7080106@boroon.dasgupta.ch> <4CA4AFF1.9@boroon.dasgupta.ch> Message-ID: <4CB754C4.8020504@boroon.dasgupta.ch> On 09/30/2010 05:42 PM, Boroondas Gupte wrote: > On 09/24/2010 01:58 PM, Boroondas Gupte wrote: >> Looking through recently merged commits, I noticed that changeset >> 80af8db446df changes >> >> LLUIString::mArgs into a pointer. This pointer gets initialized with >> a new object in one of the constructors >> >> (the other constructors set it to NULL), or lazily (i.e. when still >> NULL when an actual object is required) through LLUIString::getArgs() >> . >> >> Though I can't seem to find where mArgs gets deleted again. Is it >> being leaked? >> >> As far as I can see, mArgs (which is private) doesn't get assigned >> any pointers from outside the LLUIString instance and is never passed >> out through any method, so it should be save to delete it in the >> destructor of LLUIString. > > Filed as VWR-23239 . Proposed a fix a week ago, but looks like this didn't get a lot of attention, yet. The fix might look simple and straight forward, but both, the potential leak and this fix are difficult to test for. (E.g. adding a static instance counter to LLFormatMapString and outputting its value in the constructors and the destructor of LLFormatMapString didn't lead to conclusive results. Maybe objects of the same type are being leaked elsewhere, too.) So code review is essential here. Cheers, Boroondas -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101014/3fd5411d/attachment.htm From wolfpup67 at earthlink.net Thu Oct 14 17:58:58 2010 From: wolfpup67 at earthlink.net (WolfPup Lowenhar) Date: Thu, 14 Oct 2010 20:58:58 -0400 Subject: [opensource-dev] O.O Display name code DROP! Message-ID: <000001cb6c04$2650ce50$72f26af0$@net> Well folks my night is going to be interesting as now I have to hard merge my logging code to the new code as there are changes to the way logs are EVEN saved .llsd instead of .txt which is going to make things interesting for me as now I have to change my history look up code for the new file extension and maybe even the name formatting itself! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101014/f1986b8c/attachment.htm From akanevsky at productengine.com Thu Oct 14 18:24:57 2010 From: akanevsky at productengine.com (Anya Kanevsky) Date: Thu, 14 Oct 2010 18:24:57 -0700 Subject: [opensource-dev] Daily Scrum Summary - Thursday, October 14 Message-ID: Date: Thu Oct 14 https://wiki.secondlife.com/wiki/Snowstorm_Daily_Scrum_Archive == GENERAL NOTES == * Merge Monkey of the Day: Oz * RC Blocker resolved, waiting for new build. == DAILY SCRUM == === Merov === PAST * STORM-104: kdu upgrade: Static linking to kdu done and works. FUTURE * STORM-104: kdu upgrade: fix unit tests, make switch at build time work, test and verify some more. * STORM-105 : Perf decompression: put new data out, check the work done by opensource-dev community on similar tests. IMPEDIMENTS * Latest KDU bits ==Oz Linden== PAST * Merge Monkey ** Pulled outstanding beta fixes ** Drain Snowstorm integration queue * Got Development Viewer links on main download page fixed FUTURE * Figure out how to test updated libcurl VWR-22780 ** So that we can unblock VWR-20801 (socks 5 proxy) * Merge Monkey ** Waiting for fix for STORM-28 * More changes to develop site * Office Hour IMPEDIMENTS * none === Q Linden=== OOO === Esbee Linden==== PAST * Viewer release process discussion * Viewer 2.2 Release prep * VWR triage FUTURE * Write Viewer 2.2 Release blog post * Systems requirements analysis * VWR Triage * Viewer 2.2 Release IMPEDIMENTS * None === Paul ProductEngine=== PAST:- *STORM-196 'Undo changes' button is absent on 'Edit wearable' panel ** Fixed * STORM-258 [NAME] text instead Users name is shown when user recieves offer friendship. ** Fixed * STORM-293 Friend permissions icons overlap long names on 'My Friends' tab ** WIP. Estimate ~ 2-3 hours FUTURE: * STORM-293 Friend permissions icons overlap long names on 'My Friends' tab IMPEDIMENTS: * none === Seth Productengine === PAST: * BUG (STORM-294) Selection goes out of Favorites overflow list if scroll it by keyboard ** Updated fix according to feedback. * BUG (STORM-303) Favorites folder content isn't refreshed while re-ordering landmaks ** WIP. Could not find the root cause of defect for now. FUTURE: * BUG (STORM-303) Favorites folder content isn't refreshed while re-ordering landmaks ** Estimated: 4-6 hours. IMPEDIMENTS: * none === Andrew Productengine === PAST: * Bug STORM-322 (Group Member Search: gives more entries then the search string suggests) ** WIP. Fixed in not very good way, fixing in better one. Estimate- 3-4 hours. FUTURE: * Bug STORM-322 (Group Member Search: gives more entries then the search string suggests). IMPEDIMENTS: * none === Vadim Productengine === PAST: * Bug STORM-297 ("" text appears in confirmation message, if there is "<" symbol in Landmarks name): ** Investigated, failed to fix, bounced back to sprint backlog. * Took over bug STORM-211 (Fade timer is reset for all toasts displayed in the notifications channel) from Paul. ** Found the flaw in Paul's fix. Will carefully test the fix and submit it tomorrow. FUTURE: * Complete STORM-211. * Bug STORM-376 (Toast close button sometimes doesn't disappear). IMPEDIMENTS: * STORM-297 needs input === Andrey Productengine === PAST: * smoke + integrity testing of Viewer Release 2.2.0 (211892). Smoke tests were failed by STORM-377 & ** STORM-381 FUTURE: * switch to viewer-development testing until new release build is shipped IMPEDIMENTS: * none From jamey at beau.org Thu Oct 14 21:31:01 2010 From: jamey at beau.org (Jamey Fletcher) Date: Thu, 14 Oct 2010 23:31:01 -0500 Subject: [opensource-dev] O.O Display name code DROP! In-Reply-To: <000001cb6c04$2650ce50$72f26af0$@net> References: <000001cb6c04$2650ce50$72f26af0$@net> Message-ID: <4CB7D905.60706@beau.org> WolfPup Lowenhar wrote: > Well folks my night is going to be interesting as now I have to hard > merge my logging code to the new code as there are changes to the way > logs are EVEN saved .llsd instead of .txt which is going to make things > interesting for me as now I have to change my history look up code for > the new file extension and maybe even the name formatting itself! Is that the crash & console logs, or the chat logs too? From wolfpup67 at earthlink.net Thu Oct 14 21:57:28 2010 From: wolfpup67 at earthlink.net (WolfPup Lowenhar) Date: Fri, 15 Oct 2010 00:57:28 -0400 Subject: [opensource-dev] O.O Display name code DROP! In-Reply-To: <4CB7D905.60706@beau.org> References: <000001cb6c04$2650ce50$72f26af0$@net> <4CB7D905.60706@beau.org> Message-ID: <000001cb6c25$7787f660$6697e320$@net> Actualy the file extension change is only to chat and IM logs. And I have already found a bug in the code! https://jira.secondlife.com/browse/VWR-23437 the above jira is the bug and it is not being cause be my file name modification as the mod is working fine for group IM's. From: opensource-dev-bounces at lists.secondlife.com [mailto:opensource-dev-bounces at lists.secondlife.com] On Behalf Of Jamey Fletcher Sent: Friday, October 15, 2010 12:31 AM To: opensource-dev at lists.secondlife.com Subject: Re: [opensource-dev] O.O Display name code DROP! WolfPup Lowenhar wrote: > Well folks my night is going to be interesting as now I have to hard > merge my logging code to the new code as there are changes to the way > logs are EVEN saved .llsd instead of .txt which is going to make things > interesting for me as now I have to change my history look up code for > the new file extension and maybe even the name formatting itself! Is that the crash & console logs, or the chat logs too? _______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges _____ No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1136 / Virus Database: 422/3196 - Release Date: 10/14/10 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101015/538bd9a7/attachment.htm From jamey at beau.org Thu Oct 14 23:15:13 2010 From: jamey at beau.org (Jamey Fletcher) Date: Fri, 15 Oct 2010 01:15:13 -0500 Subject: [opensource-dev] O.O Display name code DROP! In-Reply-To: <000001cb6c25$7787f660$6697e320$@net> References: <000001cb6c04$2650ce50$72f26af0$@net> <4CB7D905.60706@beau.org> <000001cb6c25$7787f660$6697e320$@net> Message-ID: <4CB7F171.9000600@beau.org> WolfPup Lowenhar wrote: > Actualy the file extension change is only to chat and IM logs. And I > have already found a bug in the code! > https://jira.secondlife.com/browse/VWR-23437 > the above jira is the bug and it is not being cause be my file name > modification as the mod is working fine for group IM?s. Ok - so instead of just opening wordpad/nano/vi/emacs/religious editor of choice, and reading with eyeballs mark I, we're going to have to have a specialized decoder/converter, to read something that as far as I can tell, is going to take up a hell of a lot more storage for ... what purpose? Is there actually a *reason* for this change, or is it just to screw around in the code to do provide an opportunity for new bugs, such as the one you found already? Goddess knows, all of the bugs in the current code are *completely* eradicated. From Lance.Corrimal at eregion.de Thu Oct 14 23:30:35 2010 From: Lance.Corrimal at eregion.de (Lance Corrimal) Date: Fri, 15 Oct 2010 08:30:35 +0200 Subject: [opensource-dev] O.O Display name code DROP! In-Reply-To: <4CB7F171.9000600@beau.org> References: <000001cb6c04$2650ce50$72f26af0$@net> <000001cb6c25$7787f660$6697e320$@net> <4CB7F171.9000600@beau.org> Message-ID: <201010150830.35948.Lance.Corrimal@eregion.de> Am Freitag 15 Oktober 2010 schrieb Jamey Fletcher: > WolfPup Lowenhar wrote: > > Actualy the file extension change is only to chat and IM logs. > > And I have already found a bug in the code! > > > > https://jira.secondlife.com/browse/VWR-23437 > > > > the above jira is the bug and it is not being cause be my file > > name modification as the mod is working fine for group IM?s. > > Ok - so instead of just opening wordpad/nano/vi/emacs/religious > editor of choice, and reading with eyeballs mark I, we're going to > have to have a specialized decoder/converter, to read something > that as far as I can tell, is going to take up a hell of a lot > more storage for ... what purpose? > > Is there actually a *reason* for this change, or is it just to > screw around in the code to do provide an opportunity for new > bugs, such as the one you found already? Any "reason" that comes to mind would be higly insulting. From chaosstar at gmail.com Thu Oct 14 23:31:39 2010 From: chaosstar at gmail.com (Ambrosia) Date: Fri, 15 Oct 2010 08:31:39 +0200 Subject: [opensource-dev] O.O Display name code DROP! In-Reply-To: <4CB7F171.9000600@beau.org> References: <000001cb6c04$2650ce50$72f26af0$@net> <4CB7D905.60706@beau.org> <000001cb6c25$7787f660$6697e320$@net> <4CB7F171.9000600@beau.org> Message-ID: Wait, what? The new chat/IM logs are saved in LLSD of all things? Why? To make chat/IM history work with the display names or...what? And there is no option to also store a .txt copy? On Fri, Oct 15, 2010 at 08:15, Jamey Fletcher wrote: > WolfPup Lowenhar wrote: > >> Actualy the file extension change is only to chat and IM logs. And I >> have already found a bug in the code! > >> https://jira.secondlife.com/browse/VWR-23437 > >> the above jira is the bug and it is not being cause be my file name >> modification as the mod is working fine for group IM?s. > > Ok - so instead of just opening wordpad/nano/vi/emacs/religious editor > of choice, and reading with eyeballs mark I, we're going to have to have > a specialized decoder/converter, to read something that as far as I can > tell, is going to take up a hell of a lot more storage for ... what purpose? > > Is there actually a *reason* for this change, or is it just to screw > around in the code to do provide an opportunity for new bugs, such as > the one you found already? > > Goddess knows, all of the bugs in the current code are *completely* > eradicated. > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting privileges > From stickman at gmail.com Thu Oct 14 23:46:49 2010 From: stickman at gmail.com (Stickman) Date: Thu, 14 Oct 2010 23:46:49 -0700 Subject: [opensource-dev] O.O Display name code DROP! In-Reply-To: References: <000001cb6c04$2650ce50$72f26af0$@net> <4CB7D905.60706@beau.org> <000001cb6c25$7787f660$6697e320$@net> <4CB7F171.9000600@beau.org> Message-ID: > The new chat/IM logs are saved in LLSD of all things? NOT MY CHAT LOGS! That's where I keep all my text! I am also very interested in the purpose of this change, and if there will be provided (by LL or a loving developer) a handy and lightweight notepad replacement to read and search these log files, or maybe a tool to parse them into plain text. I kinda use my chatlogs a lot. Creating an extra step to read them doesn't make me happy. :< It means there's an "event horizon" date and if I'm unsure of when a conversation happened I need to do two searches using different tools. Stickman From dave at meadowlakearts.com Fri Oct 15 00:19:03 2010 From: dave at meadowlakearts.com (Dave Booth) Date: Fri, 15 Oct 2010 02:19:03 -0500 Subject: [opensource-dev] O.O Display name code DROP! In-Reply-To: References: <000001cb6c04$2650ce50$72f26af0$@net> <4CB7D905.60706@beau.org> <000001cb6c25$7787f660$6697e320$@net> <4CB7F171.9000600@beau.org> Message-ID: <4CB80066.7060008@meadowlakearts.com> On 10/15/2010 01:46, Stickman wrote: >> The new chat/IM logs are saved in LLSD of all things? > NOT MY CHAT LOGS! That's where I keep all my text! Me too - thats a change needs a backout immediately. Whiskey Tango Foxtrot????? From Lance.Corrimal at eregion.de Fri Oct 15 00:58:27 2010 From: Lance.Corrimal at eregion.de (Lance Corrimal) Date: Fri, 15 Oct 2010 09:58:27 +0200 Subject: [opensource-dev] O.O Display name code DROP! In-Reply-To: <4CB80066.7060008@meadowlakearts.com> References: <000001cb6c04$2650ce50$72f26af0$@net> <4CB80066.7060008@meadowlakearts.com> Message-ID: <201010150958.27128.Lance.Corrimal@eregion.de> My wife works inworld for a big estate, in sales and tenant support and staff training, and basically EVERY CASE DOCUMENTATION is based on plaintext chat- and IM logs. When I told her about this change earlier I almost had to tie her down to keep her to go over to linden village with a shotgun... and she's usually the most peace-loving person ever. Am Freitag, 15. Oktober 2010, 09:19:03 schrieb Dave Booth: > On 10/15/2010 01:46, Stickman wrote: > >> The new chat/IM logs are saved in LLSD of all things? > > > > NOT MY CHAT LOGS! That's where I keep all my text! > > Me too - thats a change needs a backout immediately. > > Whiskey Tango Foxtrot????? From nexisentertainment at gmail.com Fri Oct 15 01:00:44 2010 From: nexisentertainment at gmail.com (Rob Nelson) Date: Fri, 15 Oct 2010 01:00:44 -0700 Subject: [opensource-dev] O.O Display name code DROP! In-Reply-To: <000001cb6c25$7787f660$6697e320$@net> References: <000001cb6c04$2650ce50$72f26af0$@net> <4CB7D905.60706@beau.org> <000001cb6c25$7787f660$6697e320$@net> Message-ID: <4CB80A2C.1080404@gmail.com> So basically, LL decided to go from simply changing the formatting of their logs to (if what I am hearing is correct), of all things, LLSD XML notation, possibly the worst formatting of log possible? Has ANYONE over there at LL looked at the sheer amount of overhead LLSD produces? We'll have log folders that are larger in size than our cache folders. "[{TIME}] {DISPLAY NAME} ({REAL.NAME}) says: {STUFF}" would have been MORE than sufficient for logging purposes. Rob On 10/14/2010 9:57 PM, WolfPup Lowenhar wrote: > > Actualy the file extension change is only to chat and IM logs. And I > have already found a bug in the code! > > https://jira.secondlife.com/browse/VWR-23437 > > the above jira is the bug and it is not being cause be my file name > modification as the mod is working fine for group IM's. > > *From:* opensource-dev-bounces at lists.secondlife.com > [mailto:opensource-dev-bounces at lists.secondlife.com] *On Behalf Of > *Jamey Fletcher > *Sent:* Friday, October 15, 2010 12:31 AM > *To:* opensource-dev at lists.secondlife.com > *Subject:* Re: [opensource-dev] O.O Display name code DROP! > > WolfPup Lowenhar wrote: > > Well folks my night is going to be interesting as now I have to hard > > merge my logging code to the new code as there are changes to the way > > logs are EVEN saved .llsd instead of .txt which is going to make things > > interesting for me as now I have to change my history look up code for > > the new file extension and maybe even the name formatting itself! > > Is that the crash & console logs, or the chat logs too? > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting > privileges > > ------------------------------------------------------------------------ > > No virus found in this message. > Checked by AVG - www.avg.com > Version: 10.0.1136 / Virus Database: 422/3196 - Release Date: 10/14/10 > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting privileges -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101015/5f3df8ca/attachment.htm From stickman at gmail.com Fri Oct 15 01:45:52 2010 From: stickman at gmail.com (Stickman) Date: Fri, 15 Oct 2010 01:45:52 -0700 Subject: [opensource-dev] O.O Display name code DROP! In-Reply-To: <4CB80A2C.1080404@gmail.com> References: <000001cb6c04$2650ce50$72f26af0$@net> <4CB7D905.60706@beau.org> <000001cb6c25$7787f660$6697e320$@net> <4CB80A2C.1080404@gmail.com> Message-ID: > "[{TIME}] {DISPLAY NAME} ({REAL.NAME}) says: {STUFF}" would have been MORE > than sufficient for logging purposes. [01:49] TehSticks (Stickman Ingmann) says: I second this format. Anyone see any drawbacks? Dates, maybe? -Stickman From marinekelley at gmail.com Fri Oct 15 01:57:18 2010 From: marinekelley at gmail.com (Marine Kelley) Date: Fri, 15 Oct 2010 10:57:18 +0200 Subject: [opensource-dev] O.O Display name code DROP! In-Reply-To: References: <000001cb6c04$2650ce50$72f26af0$@net> <4CB7D905.60706@beau.org> <000001cb6c25$7787f660$6697e320$@net> <4CB80A2C.1080404@gmail.com> Message-ID: <73604444-FDB5-46C1-950A-0FC2A5B34864@gmail.com> On 15 oct. 2010, at 10:45, Stickman wrote: >> "[{TIME}] {DISPLAY NAME} ({REAL.NAME}) says: {STUFF}" would have >> been MORE >> than sufficient for logging purposes. > > [01:49] TehSticks (Stickman Ingmann) says: I second this format. > Anyone see any drawbacks? Dates, maybe? > +1 ! No need to put too much info, all we need is a CLEAR way to tell which name is Display and which name is User, so that the reader won't be confused if they are attentive enough. I don't see any good reason for the change of the chat log format if the current format can hold the info we need already. It would be best if older viewers could read newer chatlogs without much loss in final readability. LLSD would definitely not permit that. From Lance.Corrimal at eregion.de Fri Oct 15 02:04:25 2010 From: Lance.Corrimal at eregion.de (Lance Corrimal) Date: Fri, 15 Oct 2010 11:04:25 +0200 Subject: [opensource-dev] O.O Display name code DROP! In-Reply-To: <4CB80A2C.1080404@gmail.com> References: <000001cb6c04$2650ce50$72f26af0$@net> <000001cb6c25$7787f660$6697e320$@net> <4CB80A2C.1080404@gmail.com> Message-ID: <201010151104.25526.Lance.Corrimal@eregion.de> Am Freitag, 15. Oktober 2010, 10:00:44 schrieb Rob Nelson: > So basically, LL decided to go from simply changing the formatting of > their logs to (if what I am hearing is correct), of all things, LLSD XML > notation, possibly the worst formatting of log possible? > > Has ANYONE over there at LL looked at the sheer amount of overhead LLSD > produces? We'll have log folders that are larger in size than our cache > folders. > > "[{TIME}] {DISPLAY NAME} ({REAL.NAME}) says: {STUFF}" would have been > MORE than sufficient for logging purposes. what about sticking to the old format (i.e. without the "says" unless its a shout or a whisper)? [{TIME}] {DISPLAYNAME} ({LOGINNAME}): {STUFF} as it used to be..? bye, LC From leliel.mirihi at gmail.com Fri Oct 15 02:23:47 2010 From: leliel.mirihi at gmail.com (leliel) Date: Fri, 15 Oct 2010 02:23:47 -0700 Subject: [opensource-dev] O.O Display name code DROP! In-Reply-To: <201010151104.25526.Lance.Corrimal@eregion.de> References: <000001cb6c04$2650ce50$72f26af0$@net> <000001cb6c25$7787f660$6697e320$@net> <4CB80A2C.1080404@gmail.com> <201010151104.25526.Lance.Corrimal@eregion.de> Message-ID: On Fri, Oct 15, 2010 at 2:04 AM, Lance Corrimal wrote: > Am Freitag, 15. Oktober 2010, 10:00:44 schrieb Rob Nelson: >> ? So basically, LL decided to go from simply changing the formatting of >> their logs to (if what I am hearing is correct), of all things, LLSD XML >> notation, possibly the worst formatting of log possible? >> >> Has ANYONE over there at LL looked at the sheer amount of overhead LLSD >> produces? We'll have log folders that are larger in size than our cache >> folders. My log folder is a whopping 35MB after almost 4 years. LLSD would have to be very inefficient in order for my log directory to over take the cache directory within the next decade. >> "[{TIME}] {DISPLAY NAME} ({REAL.NAME}) says: {STUFF}" would have been >> MORE than sufficient for logging purposes. > > > what about sticking to the old format (i.e. without the "says" unless its a > shout or a whisper)? > > [{TIME}] {DISPLAYNAME} ({LOGINNAME}): {STUFF} > > as it used to be..? I'll play devil's advocate and say llsd isn't that far off from this. It's definitely more verbose, but the main difference is the UUID instead of LOGNAME. Here's an actual line from my log file. {'from':'\xe7\xa4\xbc\xe5\xad\x90','from_id':udba66655-e06a-47d9-a241-f055b85041ef,'message':':o','source_type':i1,'time':'2010/08/31 17:38'} From makosoft at gmail.com Fri Oct 15 03:16:42 2010 From: makosoft at gmail.com (Aidan Thornton) Date: Fri, 15 Oct 2010 11:16:42 +0100 Subject: [opensource-dev] O.O Display name code DROP! In-Reply-To: <4CB7F171.9000600@beau.org> References: <000001cb6c04$2650ce50$72f26af0$@net> <4CB7D905.60706@beau.org> <000001cb6c25$7787f660$6697e320$@net> <4CB7F171.9000600@beau.org> Message-ID: On Fri, Oct 15, 2010 at 7:15 AM, Jamey Fletcher wrote: > Is there actually a *reason* for this change, or is it just to screw > around in the code to do provide an opportunity for new bugs, such as > the one you found already? I suspect the reason for the change is that with display names, the names of participants in IMs and group chat no longer uniquely identify them - and the usernames, which are unique, aren't available at the point where the logging of chat and IMs is done. This also has the interesting side-effect that it's incredibly difficult to figure out who actually said something just from your chat logs, because the only information in there that actually identifies them is their UUID. From nexisentertainment at gmail.com Fri Oct 15 04:22:44 2010 From: nexisentertainment at gmail.com (Rob Nelson) Date: Fri, 15 Oct 2010 04:22:44 -0700 Subject: [opensource-dev] O.O Display name code DROP! In-Reply-To: <201010151104.25526.Lance.Corrimal@eregion.de> References: <000001cb6c04$2650ce50$72f26af0$@net> <000001cb6c25$7787f660$6697e320$@net> <4CB80A2C.1080404@gmail.com> <201010151104.25526.Lance.Corrimal@eregion.de> Message-ID: <4CB83984.40905@gmail.com> On 10/15/2010 2:04 AM, Lance Corrimal wrote: > Am Freitag, 15. Oktober 2010, 10:00:44 schrieb Rob Nelson: >> So basically, LL decided to go from simply changing the formatting of >> their logs to (if what I am hearing is correct), of all things, LLSD XML >> notation, possibly the worst formatting of log possible? >> >> Has ANYONE over there at LL looked at the sheer amount of overhead LLSD >> produces? We'll have log folders that are larger in size than our cache >> folders. >> >> "[{TIME}] {DISPLAY NAME} ({REAL.NAME}) says: {STUFF}" would have been >> MORE than sufficient for logging purposes. > > what about sticking to the old format (i.e. without the "says" unless its a > shout or a whisper)? > > [{TIME}] {DISPLAYNAME} ({LOGINNAME}): {STUFF} > > as it used to be..? > > > bye, > LC Well, yeah. Also, Marine, I stuck that ({REAL.NAME}) in there because I figured that their display name would have changed between now and when that log was written. However, context may be lost if the display name is omitted, so I couldn't exactly dump that, either. From open at autistici.org Fri Oct 15 04:35:40 2010 From: open at autistici.org (Opensource Obscure) Date: Fri, 15 Oct 2010 12:35:40 +0100 Subject: [opensource-dev] O.O Display name code DROP! In-Reply-To: <4CB83984.40905@gmail.com> References: "<000001cb6c04$2650ce50$72f26af0$@net>" <000001cb6c25$7787f660$6697e320$@net> <4CB80A2C.1080404@gmail.com> <201010151104.25526.Lance.Corrimal@eregion.de> <4CB83984.40905@gmail.com> Message-ID: <0b57e0512ded83d6553eea9fc61fe08b@localhost> OMG!!!!!?!?! THIS WILL [destroy SL economy|eat all your cheese|kill your kittens] !!!11!!!1! I can't believe nobody is considering the idea that the current setting may just be an overlooking and that the default behaviour could be restored before this goes into production. Opensource Obscure From carlo at alinoe.com Fri Oct 15 04:38:13 2010 From: carlo at alinoe.com (Carlo Wood) Date: Fri, 15 Oct 2010 13:38:13 +0200 Subject: [opensource-dev] O.O Display name code DROP! In-Reply-To: <4CB83984.40905@gmail.com> References: <000001cb6c04$2650ce50$72f26af0$@net> <000001cb6c25$7787f660$6697e320$@net> <4CB80A2C.1080404@gmail.com> <201010151104.25526.Lance.Corrimal@eregion.de> <4CB83984.40905@gmail.com> Message-ID: <20101015113813.GA15440@alinoe.com> I didn't know LLSD was capabable of appending, does this new format mean that my 50 MB chat.txt file is going to be re-written from scratch, every time I sync it with the latest chat? I was hoping that log files are updated very frequently, so that if I crash I don't lose text. But writing several megabytes to disk every line of chat seems unfeasible. So, how is this appending being done? -- Carlo Wood From leliel.mirihi at gmail.com Fri Oct 15 04:47:21 2010 From: leliel.mirihi at gmail.com (leliel) Date: Fri, 15 Oct 2010 04:47:21 -0700 Subject: [opensource-dev] O.O Display name code DROP! In-Reply-To: <20101015113813.GA15440@alinoe.com> References: <000001cb6c04$2650ce50$72f26af0$@net> <000001cb6c25$7787f660$6697e320$@net> <4CB80A2C.1080404@gmail.com> <201010151104.25526.Lance.Corrimal@eregion.de> <4CB83984.40905@gmail.com> <20101015113813.GA15440@alinoe.com> Message-ID: On Fri, Oct 15, 2010 at 4:38 AM, Carlo Wood wrote: > I was hoping that log files are updated very > frequently, so that if I crash I don't lose > text. But writing several megabytes to disk > every line of chat seems unfeasible. It's 115 bytes + display name + message per line. Just where are these several megabytes coming from? From stickman at gmail.com Fri Oct 15 04:53:05 2010 From: stickman at gmail.com (Stickman) Date: Fri, 15 Oct 2010 04:53:05 -0700 Subject: [opensource-dev] O.O Display name code DROP! In-Reply-To: References: <000001cb6c04$2650ce50$72f26af0$@net> <000001cb6c25$7787f660$6697e320$@net> <4CB80A2C.1080404@gmail.com> <201010151104.25526.Lance.Corrimal@eregion.de> <4CB83984.40905@gmail.com> <20101015113813.GA15440@alinoe.com> Message-ID: > It's 115 bytes + display name + message per line. Just where are these > several megabytes coming from? Lack of "append" in LLSD. Sounds a bit extreme to me. I prefer Opensource's line of thinking, where this is simply some sort of oversight that can be repaired. The current format is missing important information, such as the username and display name, and only contains their UUID, which is less than ideal for a chat log to contain. If it's not, the Lindens should be waking up soon and see a huge thread of people screaming that the sky is falling and put some authority down on the situation. Looking forward to it, those clouds are looking awfully close. -Stickman From leliel.mirihi at gmail.com Fri Oct 15 05:15:38 2010 From: leliel.mirihi at gmail.com (leliel) Date: Fri, 15 Oct 2010 05:15:38 -0700 Subject: [opensource-dev] O.O Display name code DROP! In-Reply-To: References: <000001cb6c04$2650ce50$72f26af0$@net> <000001cb6c25$7787f660$6697e320$@net> <4CB80A2C.1080404@gmail.com> <201010151104.25526.Lance.Corrimal@eregion.de> <4CB83984.40905@gmail.com> <20101015113813.GA15440@alinoe.com> Message-ID: On Fri, Oct 15, 2010 at 4:53 AM, Stickman wrote: >> It's 115 bytes + display name + message per line. Just where are these >> several megabytes coming from? > > Lack of "append" in LLSD. Sounds a bit extreme to me. The latest Snowstorm build had no trouble appending to the chat.llsd file the Display Names project viewer created two months back, it even showed the last 8 lines when I logged in. > I prefer Opensource's line of thinking, where this is simply some sort > of oversight that can be repaired. The Display Names project viewer has been using this format for months, I doubt it's an over sight. > The current format is missing important information, such as the > username and display name, and only contains their UUID, which is less > than ideal for a chat log to contain. It does have the display name, you can see it in the line I posted above. It looks like gibberish because I was using a Unicode name at the time. From chaosstar at gmail.com Fri Oct 15 05:22:32 2010 From: chaosstar at gmail.com (Ambrosia) Date: Fri, 15 Oct 2010 14:22:32 +0200 Subject: [opensource-dev] O.O Display name code DROP! In-Reply-To: References: <000001cb6c04$2650ce50$72f26af0$@net> <000001cb6c25$7787f660$6697e320$@net> <4CB80A2C.1080404@gmail.com> <201010151104.25526.Lance.Corrimal@eregion.de> Message-ID: On Fri, Oct 15, 2010 at 11:23, leliel wrote: > On Fri, Oct 15, 2010 at 2:04 AM, Lance Corrimal > wrote: >> Am Freitag, 15. Oktober 2010, 10:00:44 schrieb Rob Nelson: >>> ? So basically, LL decided to go from simply changing the formatting of >>> their logs to (if what I am hearing is correct), of all things, LLSD XML >>> notation, possibly the worst formatting of log possible? >>> >>> Has ANYONE over there at LL looked at the sheer amount of overhead LLSD >>> produces? We'll have log folders that are larger in size than our cache >>> folders. > > My log folder is a whopping 35MB after almost 4 years. LLSD would have > to be very inefficient in order for my log directory to over take the > cache directory within the next decade. > That's smaller than each of my several chat.txt's that I have backed up :p From wolfpup67 at earthlink.net Fri Oct 15 05:24:01 2010 From: wolfpup67 at earthlink.net (WolfPup Lowenhar) Date: Fri, 15 Oct 2010 08:24:01 -0400 Subject: [opensource-dev] O.O Display name code DROP! In-Reply-To: References: <000001cb6c04$2650ce50$72f26af0$@net> <000001cb6c25$7787f660$6697e320$@net> <4CB80A2C.1080404@gmail.com> <201010151104.25526.Lance.Corrimal@eregion.de> <4CB83984.40905@gmail.com> <20101015113813.GA15440@alinoe.com> Message-ID: <000c01cb6c63$d9b597f0$8d20c7d0$@net> As I am testing the viewer the .llsd files to append with no issues on that part. From: opensource-dev-bounces at lists.secondlife.com [mailto:opensource-dev-bounces at lists.secondlife.com] On Behalf Of Stickman Sent: Friday, October 15, 2010 7:53 AM To: leliel Cc: opensource-dev at lists.secondlife.com Subject: Re: [opensource-dev] O.O Display name code DROP! > It's 115 bytes + display name + message per line. Just where are these > several megabytes coming from? Lack of "append" in LLSD. Sounds a bit extreme to me. I prefer Opensource's line of thinking, where this is simply some sort of oversight that can be repaired. The current format is missing important information, such as the username and display name, and only contains their UUID, which is less than ideal for a chat log to contain. If it's not, the Lindens should be waking up soon and see a huge thread of people screaming that the sky is falling and put some authority down on the situation. Looking forward to it, those clouds are looking awfully close. -Stickman _______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges _____ No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1136 / Virus Database: 422/3196 - Release Date: 10/14/10 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101015/b9e88abc/attachment-0001.htm From carlo at alinoe.com Fri Oct 15 05:29:40 2010 From: carlo at alinoe.com (Carlo Wood) Date: Fri, 15 Oct 2010 14:29:40 +0200 Subject: [opensource-dev] O.O Display name code DROP! In-Reply-To: References: <000001cb6c04$2650ce50$72f26af0$@net> <000001cb6c25$7787f660$6697e320$@net> <4CB80A2C.1080404@gmail.com> <201010151104.25526.Lance.Corrimal@eregion.de> <4CB83984.40905@gmail.com> <20101015113813.GA15440@alinoe.com> Message-ID: <20101015122940.GA5078@alinoe.com> On Fri, Oct 15, 2010 at 04:47:21AM -0700, leliel wrote: > On Fri, Oct 15, 2010 at 4:38 AM, Carlo Wood wrote: > > I was hoping that log files are updated very > > frequently, so that if I crash I don't lose > > text. But writing several megabytes to disk > > every line of chat seems unfeasible. > > It's 115 bytes + display name + message per line. Just where are these > several megabytes coming from? -rw-r--r-- 1 carlo carlo 60282480 Sep 28 00:30 chat.txt That is 60 MB. And that is BEFORE we're using LLSD. -- Carlo Wood From carlo at alinoe.com Fri Oct 15 05:31:26 2010 From: carlo at alinoe.com (Carlo Wood) Date: Fri, 15 Oct 2010 14:31:26 +0200 Subject: [opensource-dev] O.O Display name code DROP! In-Reply-To: References: <000001cb6c04$2650ce50$72f26af0$@net> <000001cb6c25$7787f660$6697e320$@net> <4CB80A2C.1080404@gmail.com> <201010151104.25526.Lance.Corrimal@eregion.de> <4CB83984.40905@gmail.com> <20101015113813.GA15440@alinoe.com> Message-ID: <20101015123126.GB5078@alinoe.com> On Fri, Oct 15, 2010 at 04:53:05AM -0700, Stickman wrote: > If it's not, the Lindens should be waking up soon and see a huge > thread of people screaming that the sky is falling and put some > authority down on the situation. HAHAHA (not) As if they care. You still don't know them do you? -- Carlo Wood From dave at meadowlakearts.com Fri Oct 15 06:33:01 2010 From: dave at meadowlakearts.com (Dave Booth) Date: Fri, 15 Oct 2010 08:33:01 -0500 Subject: [opensource-dev] O.O Display name code DROP! In-Reply-To: References: <000001cb6c04$2650ce50$72f26af0$@net> <000001cb6c25$7787f660$6697e320$@net> <4CB80A2C.1080404@gmail.com> <201010151104.25526.Lance.Corrimal@eregion.de> <4CB83984.40905@gmail.com> <20101015113813.GA15440@alinoe.com> Message-ID: <4CB8580D.9060901@meadowlakearts.com> On 10/15/2010 06:53, Stickman wrote: > If it's not, the Lindens should be waking up soon and see a huge > thread of people screaming that the sky is falling and put some > authority down on the situation. Looking forward to it, those clouds > are looking awfully close. The sky may not be falling and its not a question of unreasoning panic or hyperbole, but the whole point of logs is to be able to go back to them after the fact and see who said what. I'd even grudgingly accept a format change provided theres more in there as an identifier than just a bare uuid - its GOT to have at a minimum both the real name and the display name they are using at the time. Without both those the utility of any kind of logging becomes questionable. Logs will still be of value to resolve disputes since they record the uuids of the participants (although that process becomes a LOT less straightforward since one has to look up the uuid to find any name) but what about situations where inworld activities are being logged for another purpose, like documenting RP story arcs? Somebody changes "roles" in the RP a few months down the line and switches their display name to match and suddenly all the logs of their previous character seem to refer to their current one since theres no contemporaneous logging of the display name. Certainly one of the RP groups I spend time with is going to have a hard time, since theres a lot of stuff they use logs for - copying them over to group websites to provide records and narrative so that we keep decent continuity. To provide a more silly example of why its a bad idea, to know that uuid 00000000-0000-0000-0000-0000000000000 was yelling "Fear my sparkly colors!" just isnt funny if you cant remember that user Joe.Lame was using the display name of "Phils Codpiece" at the time...... From leliel.mirihi at gmail.com Fri Oct 15 06:35:22 2010 From: leliel.mirihi at gmail.com (leliel) Date: Fri, 15 Oct 2010 06:35:22 -0700 Subject: [opensource-dev] O.O Display name code DROP! In-Reply-To: <20101015122940.GA5078@alinoe.com> References: <000001cb6c04$2650ce50$72f26af0$@net> <000001cb6c25$7787f660$6697e320$@net> <4CB80A2C.1080404@gmail.com> <201010151104.25526.Lance.Corrimal@eregion.de> <4CB83984.40905@gmail.com> <20101015113813.GA15440@alinoe.com> <20101015122940.GA5078@alinoe.com> Message-ID: On Fri, Oct 15, 2010 at 5:29 AM, Carlo Wood wrote: > On Fri, Oct 15, 2010 at 04:47:21AM -0700, leliel wrote: >> On Fri, Oct 15, 2010 at 4:38 AM, Carlo Wood wrote: >> > I was hoping that log files are updated very >> > frequently, so that if I crash I don't lose >> > text. But writing several megabytes to disk >> > every line of chat seems unfeasible. >> >> It's 115 bytes + display name + message per line. Just where are these >> several megabytes coming from? > > -rw-r--r-- 1 carlo carlo 60282480 Sep 28 00:30 chat.txt > > That is 60 MB. And that is BEFORE we're using LLSD. What does the size of the file have to do with anything? Do you really think the viewer is reading the whole file in and appending the message then writing the whole thing out for every line of chat? Once again, where are these several megabytes coming from? FYI the relevant code is in indra/newview/lllogchat.cpp::LLLogChat::saveHistory() From danielravennest at gmail.com Fri Oct 15 06:57:25 2010 From: danielravennest at gmail.com (Daniel) Date: Fri, 15 Oct 2010 08:57:25 -0500 Subject: [opensource-dev] O.O Display name code DROP! In-Reply-To: References: Message-ID: <4CB85DC5.7030800@gmail.com> Apparently you don't chat much, mine is ten times larger over the same period. On 10/15/2010 7:24 AM, opensource-dev-request at lists.secondlife.com wrote: > My log folder is a whopping 35MB after almost 4 years. From leliel.mirihi at gmail.com Fri Oct 15 07:17:19 2010 From: leliel.mirihi at gmail.com (leliel) Date: Fri, 15 Oct 2010 07:17:19 -0700 Subject: [opensource-dev] O.O Display name code DROP! In-Reply-To: <4CB85DC5.7030800@gmail.com> References: <4CB85DC5.7030800@gmail.com> Message-ID: On Fri, Oct 15, 2010 at 6:57 AM, Daniel wrote: > ?Apparently you don't chat much, mine is ten times larger over the same > period. I only logged IMs for two years. So my chat.txt file is 15409876 bytes and 265570 lines which gives me an average message size of 58 bytes. The 115 bytes for llsd would be ~66% over head per line which is a bit excessive (that's sarcasm). Just to be clear I think this is a stupid change. I'm arguing for it because so many people were screaming the sky was falling without backing it up with hard numbers or even a user story, which has now been provided. From esbee at lindenlab.com Fri Oct 15 07:34:28 2010 From: esbee at lindenlab.com (Sarah (Esbee) Hutchinson) Date: Fri, 15 Oct 2010 10:34:28 -0400 Subject: [opensource-dev] Canceled Today - Snowstorm Sprint Review Meeting Message-ID: Good morning all, Sprint 5 has been focused on overall stabilization of the current Viewer 2.2 Beta. As such, we have no new user stories that require product review and discussion, so I'm canceling today's Sprint Review meeting. We'll still get together on Monday for the Sprint Retrospective and I encourage everybody to be thinking about how we did this sprint and how we can improve in the next. --Esbee -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101015/b44ade7e/attachment.htm From kf6kjg at gmail.com Fri Oct 15 08:10:26 2010 From: kf6kjg at gmail.com (Ricky) Date: Fri, 15 Oct 2010 08:10:26 -0700 Subject: [opensource-dev] Corrupted OpenGL & Hard Crash In-Reply-To: References: Message-ID: I apologize! I forgot that a great many people don't have the luxury of high speed internet. Which is why I'm responding to the list: hopefully others who might makes the same mistake either here or elsewhere can learn from my mistake... Ricky Cron Stardust PS: As an (lame) excuse: I daily have to work with emails, FTP, etc. that are sending files in the 5 to 25 MB range... Which is why my mind skipped on looking at the filesizes; they uploaded fast. On Fri, Oct 15, 2010 at 12:32 AM, Opensource Obscure wrote: > Hi Ricky - watch out! You sent 4.5 MB of attachments! > ;0 > I suggest using JPG for this kind of image files - the SL viewer > itself can save in this format, and you can even adjust the > quality - using something as low as 60 will still produce > decent-quality files, at a smaller size. > > HTH > bye > Opensource Obscure > > On Mon, 11 Oct 2010 21:58:12 -0700, Ricky wrote: >> Server: Various beta grid sims >> Client: 2.1.2.210027 >> OS: Mac OS 10.6.4 with a 64bit kernel, on a newer Mac Mini >> >> Less than an hour ago I was on my first exploration of the beta grid >> (getting used to the place in prep for mesh!) and was flying around >> the regions connected to the first login location I found myself at. >> I explored for a couple of hours, running across normal laggy spots, >> region crossings, heavily scripted areas, etc., when suddenly my >> screen showed blocky interference across it. ?This covered the UI, so >> I snapped a screenshot just in case, and when I minimized SL I saw >> that my desktop was showing the same corruption so I took another >> shot. ?I figured that somehow SL had corrupted OpenGL, if that's even >> possible, I don't know, so I brought back up SL to close it... ?And >> then my system hardlocked. ?I couldn't even get access to force quit, >> even using the keyboard shortcuts. ?I eventually forced the system off >> by pressing and holding the power button. >> >> During the lockup I would occasionally be able to see and control my >> mouse cursor, but not all the time. ?Most of the rest of the screen >> never redrew, not even the menu bar. ?I have Activity Monitor docked >> up there so that I can keep an eye on CPU. ?CPU had been a constant >> low mid, and showed lower than the the screen shots when the system >> locked. >> >> I have the log from this session, if it would be helpful. ?However, >> the client never got to send a crash report, as far as I can tell. >> After the reboot, I tried running the same version of the SL client >> again, but it froze before it displayed again, so I force-quit it. >> The next run ran perfectly. ?So I quit it and made a copy of the >> SecondLife.old log so that I could keep it with the the images. >> >> Has anyone else run across anything remotely similar? ?I've done a >> cursory search of the JIRA, but nothing seemed to match for me. >> >> Ricky >> Cron Stardust > > From lee.ponzu at gmail.com Fri Oct 15 09:00:06 2010 From: lee.ponzu at gmail.com (Ponzu) Date: Fri, 15 Oct 2010 12:00:06 -0400 Subject: [opensource-dev] You are not alone 8-) (was Re: Corrupted OpenGL & Hard Crash Message-ID: Something similar happened to me last night, and I doubt it was overheating. Mesh Viewer. Bizarro graphics and then a total OS X lock up. Had to finally cycle power. next try, similar, but before the lockup I got into preferences and changed graphics from High to Med. After that, things worked ok. if it happens again, I will try to get better data. On Tue, Oct 12, 2010 at 12:58 AM, Ricky wrote: > Server: Various beta grid sims > Client: 2.1.2.210027 > OS: Mac OS 10.6.4 with a 64bit kernel, on a newer Mac Mini > > Less than an hour ago I was on my first exploration of the beta grid > (getting used to the place in prep for mesh!) and was flying around > the regions connected to the first login location I found myself at. > I explored for a couple of hours, running across normal laggy spots, > region crossings, heavily scripted areas, etc., when suddenly my > screen showed blocky interference across it. This covered the UI, so > I snapped a screenshot just in case, and when I minimized SL I saw > that my desktop was showing the same corruption so I took another > shot. I figured that somehow SL had corrupted OpenGL, if that's even > possible, I don't know, so I brought back up SL to close it... And > then my system hardlocked. I couldn't even get access to force quit, > even using the keyboard shortcuts. I eventually forced the system off > by pressing and holding the power button. > > During the lockup I would occasionally be able to see and control my > mouse cursor, but not all the time. Most of the rest of the screen > never redrew, not even the menu bar. I have Activity Monitor docked > up there so that I can keep an eye on CPU. CPU had been a constant > low mid, and showed lower than the the screen shots when the system > locked. > > I have the log from this session, if it would be helpful. However, > the client never got to send a crash report, as far as I can tell. > After the reboot, I tried running the same version of the SL client > again, but it froze before it displayed again, so I force-quit it. > The next run ran perfectly. So I quit it and made a copy of the > SecondLife.old log so that I could keep it with the the images. > > Has anyone else run across anything remotely similar? I've done a > cursory search of the JIRA, but nothing seemed to match for me. > > Ricky > Cron Stardust > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101015/836cdebd/attachment-0001.htm From lee.ponzu at gmail.com Fri Oct 15 10:07:27 2010 From: lee.ponzu at gmail.com (Ponzu) Date: Fri, 15 Oct 2010 13:07:27 -0400 Subject: [opensource-dev] Project-MESH viewer Message-ID: I tried this viewer last night. As I am sure you Lindens know, it is based on a version of viewer-development that is many days old. (Some complaint, huh?) Could perhaps someone help the Mesh team pull the most relevant changesets from viewer-dev so their next release lacks the more annoying problems? (such as my personal favorite, SH-173 8-) best regards, lee -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101015/fdd6f31f/attachment.htm From oz at lindenlab.com Fri Oct 15 10:29:15 2010 From: oz at lindenlab.com (Oz Linden (Scott Lawrence)) Date: Fri, 15 Oct 2010 13:29:15 -0400 Subject: [opensource-dev] Project-MESH viewer In-Reply-To: References: Message-ID: <4CB88F6B.9020404@lindenlab.com> On 2010-10-15 13:07, Ponzu wrote: > I tried this viewer last night. As I am sure you Lindens know, it is > based on a version of viewer-development that is many days old. (Some > complaint, huh?) > Could perhaps someone help the Mesh team pull the most relevant > changesets from viewer-dev so their next release lacks the more > annoying problems? (such as my personal favorite, SH-173 8-) How frequently a team pulls from viewer-development is up to the team. It should not surprise you to hear that in the final days leading up to releasing a viewer, this task might take a back seat to putting the finishing touches on the feature one is building the Project Viewer to test. It happens that the last few days have also been a busy time in the viewer-development repository, with fixes coming back from the viewer-beta and yesterday the Display Names project merging in. I think that if I were deciding on when to sync with the latest from viewer-development, I too might have decided to wait a bit. Have no fear... any future mesh project viewers will have pulled more from viewer-development, and it will all come together before being in a Beta or released Viewer. From nyx at lindenlab.com Fri Oct 15 10:43:55 2010 From: nyx at lindenlab.com (Nyx Linden) Date: Fri, 15 Oct 2010 13:43:55 -0400 Subject: [opensource-dev] Project-MESH viewer In-Reply-To: <4CB88F6B.9020404@lindenlab.com> References: <4CB88F6B.9020404@lindenlab.com> Message-ID: <4CB892DB.1020004@lindenlab.com> We just pulled from viewer-development yesterday actually, but we had already released the initial beta viewer. We try to stay reasonably up to date, but we don't merge the latest changes every day. Don't worry we will stay synced! -Nyx On 10/15/2010 01:29 PM, Oz Linden (Scott Lawrence) wrote: > On 2010-10-15 13:07, Ponzu wrote: > >> I tried this viewer last night. As I am sure you Lindens know, it is >> based on a version of viewer-development that is many days old. (Some >> complaint, huh?) >> Could perhaps someone help the Mesh team pull the most relevant >> changesets from viewer-dev so their next release lacks the more >> annoying problems? (such as my personal favorite, SH-173 8-) >> > How frequently a team pulls from viewer-development is up to the team. > It should not surprise you to hear that in the final days leading up to > releasing a viewer, this task might take a back seat to putting the > finishing touches on the feature one is building the Project Viewer to > test. > > It happens that the last few days have also been a busy time in the > viewer-development repository, with fixes coming back from the > viewer-beta and yesterday the Display Names project merging in. I think > that if I were deciding on when to sync with the latest from > viewer-development, I too might have decided to wait a bit. > > Have no fear... any future mesh project viewers will have pulled more > from viewer-development, and it will all come together before being in a > Beta or released Viewer. > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting privileges > From lee.ponzu at gmail.com Fri Oct 15 12:39:30 2010 From: lee.ponzu at gmail.com (Ponzu) Date: Fri, 15 Oct 2010 15:39:30 -0400 Subject: [opensource-dev] Project-MESH viewer In-Reply-To: <4CB88F6B.9020404@lindenlab.com> References: <4CB88F6B.9020404@lindenlab.com> Message-ID: Yikes. It sounds like you think I was complaining. not at all. Just encouraging a little. ponzu On Fri, Oct 15, 2010 at 1:29 PM, Oz Linden (Scott Lawrence) < oz at lindenlab.com> wrote: > On 2010-10-15 13:07, Ponzu wrote: > > I tried this viewer last night. As I am sure you Lindens know, it is > > based on a version of viewer-development that is many days old. (Some > > complaint, huh?) > > Could perhaps someone help the Mesh team pull the most relevant > > changesets from viewer-dev so their next release lacks the more > > annoying problems? (such as my personal favorite, SH-173 8-) > > How frequently a team pulls from viewer-development is up to the team. > It should not surprise you to hear that in the final days leading up to > releasing a viewer, this task might take a back seat to putting the > finishing touches on the feature one is building the Project Viewer to > test. > > It happens that the last few days have also been a busy time in the > viewer-development repository, with fixes coming back from the > viewer-beta and yesterday the Display Names project merging in. I think > that if I were deciding on when to sync with the latest from > viewer-development, I too might have decided to wait a bit. > > Have no fear... any future mesh project viewers will have pulled more > from viewer-development, and it will all come together before being in a > Beta or released Viewer. > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101015/d2a17bf1/attachment.htm From garmin.kawaguichi at magalaxie.com Fri Oct 15 13:46:14 2010 From: garmin.kawaguichi at magalaxie.com (Garmin Kawaguichi) Date: Fri, 15 Oct 2010 22:46:14 +0200 Subject: [opensource-dev] O.O Display name code DROP! References: <000001cb6c04$2650ce50$72f26af0$@net> Message-ID: It was a JIRA from Samia Bechir https://jira.secondlife.com/browse/VWR-22940 dated from September 10 You can vote for it GCI ----- Original Message ----- From: WolfPup Lowenhar To: OpenSource Mailing List Sent: Friday, October 15, 2010 2:58 AM Subject: [opensource-dev] O.O Display name code DROP! Well folks my night is going to be interesting as now I have to hard merge my logging code to the new code as there are changes to the way logs are EVEN saved .llsd instead of .txt which is going to make things interesting for me as now I have to change my history look up code for the new file extension and maybe even the name formatting itself! ------------------------------------------------------------------------------ _______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101015/e5cf9343/attachment.htm From marc at inworlddesigns.com Fri Oct 15 14:12:39 2010 From: marc at inworlddesigns.com (Marc Adored) Date: Fri, 15 Oct 2010 17:12:39 -0400 Subject: [opensource-dev] O.O Display name code DROP! In-Reply-To: References: <000001cb6c04$2650ce50$72f26af0$@net> Message-ID: All this panic did anyone stop to think that maybe this is part of a bigger plan? The first thing that cam to mind for me was maybe it makes it easier for programs to format them and probably better for searching and stuff (withen a program). Also maybe there are plans for a built in log viewer coming soon? I think that this format is less then ideal but then again I have no idea what might be planned and why this specific format was chosen On Fri, Oct 15, 2010 at 4:46 PM, Garmin Kawaguichi wrote: > It was a JIRA from Samia Bechir > https://jira.secondlife.com/browse/VWR-22940?dated from September 10 > You can vote for it > > GCI > > > > ----- Original Message ----- > From: WolfPup Lowenhar > To: OpenSource Mailing List > Sent: Friday, October 15, 2010 2:58 AM > Subject: [opensource-dev] O.O Display name code DROP! > > Well folks my night is going to be interesting as now I have to hard merge > my logging code to the new code as there are changes to the way logs are > EVEN saved .llsd instead of .txt which is going to make things interesting > for me as now I have to change my history look up code for the new file > extension and maybe even the name formatting itself! > > ________________________________ > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting > privileges > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting > privileges > From kf6kjg at gmail.com Fri Oct 15 14:36:06 2010 From: kf6kjg at gmail.com (Ricky) Date: Fri, 15 Oct 2010 14:36:06 -0700 Subject: [opensource-dev] O.O Display name code DROP! In-Reply-To: References: <000001cb6c04$2650ce50$72f26af0$@net> Message-ID: Besides, back on Sept 2nd this was already discussed, and plans invented. https://lists.secondlife.com/pipermail/opensource-dev/2010-September/003162.html All that's needed is a linked XSL stylesheet to make it just as easy to read as the text files were. Just using a web browser instead of a text editor. Josh solved the XSL in this response: https://lists.secondlife.com/pipermail/opensource-dev/2010-September/003164.html Tis is actually a good step. Admittedly the file size might jump, but I'm pretty sure each of us has the drive space, and appending to a file is trivial. I do believe it can be done in near constant time, relative to the file size. Ricky Cron Stardust On Fri, Oct 15, 2010 at 2:12 PM, Marc Adored wrote: > All this panic did anyone stop to think that maybe this is part of a > bigger plan? The first thing that cam to mind for me was maybe it > makes it easier for programs to format them and probably better for > searching and stuff (withen a program). Also maybe there are plans for > a built in log viewer coming soon? I think that this format is less > then ideal but then again I have no idea what might be planned and why > this specific format was chosen > > On Fri, Oct 15, 2010 at 4:46 PM, Garmin Kawaguichi > wrote: >> It was a JIRA from Samia Bechir >> https://jira.secondlife.com/browse/VWR-22940?dated from September 10 >> You can vote for it >> >> GCI >> >> >> >> ----- Original Message ----- >> From: WolfPup Lowenhar >> To: OpenSource Mailing List >> Sent: Friday, October 15, 2010 2:58 AM >> Subject: [opensource-dev] O.O Display name code DROP! >> >> Well folks my night is going to be interesting as now I have to hard merge >> my logging code to the new code as there are changes to the way logs are >> EVEN saved .llsd instead of .txt which is going to make things interesting >> for me as now I have to change my history look up code for the new file >> extension and maybe even the name formatting itself! >> >> ________________________________ >> >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/OpenSource-Dev >> Please read the policies before posting to keep unmoderated posting >> privileges >> >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/OpenSource-Dev >> Please read the policies before posting to keep unmoderated posting >> privileges >> > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting privileges > From labrat.hb at gmail.com Fri Oct 15 14:52:54 2010 From: labrat.hb at gmail.com (Harold Brown) Date: Fri, 15 Oct 2010 14:52:54 -0700 Subject: [opensource-dev] O.O Display name code DROP! In-Reply-To: References: <000001cb6c04$2650ce50$72f26af0$@net> Message-ID: This is another change that a very small percentage of people wanted that was made without consideration to how it affects the larger community. The PROPER change should have been to add an OPTION to log to .llsd for those people making log files of Office Hours parsing log files for posting to the wiki was the reason for this change. On Fri, Oct 15, 2010 at 2:36 PM, Ricky wrote: > Besides, back on Sept 2nd this was already discussed, and plans > invented. ?https://lists.secondlife.com/pipermail/opensource-dev/2010-September/003162.html > > All that's needed is a linked XSL stylesheet to make it just as easy > to read as the text files were. ?Just using a web browser instead of a > text editor. ?Josh solved the XSL in this response: > https://lists.secondlife.com/pipermail/opensource-dev/2010-September/003164.html > > Tis is actually a good step. ?Admittedly the file size might jump, but > I'm pretty sure each of us has the drive space, and appending to a > file is trivial. ?I do believe it can be done in near constant time, > relative to the file size. > > Ricky > Cron Stardust > > On Fri, Oct 15, 2010 at 2:12 PM, Marc Adored wrote: >> All this panic did anyone stop to think that maybe this is part of a >> bigger plan? The first thing that cam to mind for me was maybe it >> makes it easier for programs to format them and probably better for >> searching and stuff (withen a program). Also maybe there are plans for >> a built in log viewer coming soon? I think that this format is less >> then ideal but then again I have no idea what might be planned and why >> this specific format was chosen >> >> On Fri, Oct 15, 2010 at 4:46 PM, Garmin Kawaguichi >> wrote: >>> It was a JIRA from Samia Bechir >>> https://jira.secondlife.com/browse/VWR-22940?dated from September 10 >>> You can vote for it >>> >>> GCI >>> >>> >>> >>> ----- Original Message ----- >>> From: WolfPup Lowenhar >>> To: OpenSource Mailing List >>> Sent: Friday, October 15, 2010 2:58 AM >>> Subject: [opensource-dev] O.O Display name code DROP! >>> >>> Well folks my night is going to be interesting as now I have to hard merge >>> my logging code to the new code as there are changes to the way logs are >>> EVEN saved .llsd instead of .txt which is going to make things interesting >>> for me as now I have to change my history look up code for the new file >>> extension and maybe even the name formatting itself! >>> >>> ________________________________ >>> >>> _______________________________________________ >>> Policies and (un)subscribe information available here: >>> http://wiki.secondlife.com/wiki/OpenSource-Dev >>> Please read the policies before posting to keep unmoderated posting >>> privileges >>> >>> _______________________________________________ >>> Policies and (un)subscribe information available here: >>> http://wiki.secondlife.com/wiki/OpenSource-Dev >>> Please read the policies before posting to keep unmoderated posting >>> privileges >>> >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/OpenSource-Dev >> Please read the policies before posting to keep unmoderated posting privileges >> > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting privileges > From trilobyte550m at gmail.com Fri Oct 15 15:00:42 2010 From: trilobyte550m at gmail.com (Trilo Byte) Date: Fri, 15 Oct 2010 15:00:42 -0700 Subject: [opensource-dev] Project-MESH viewer In-Reply-To: References: Message-ID: But on the flipside, the Project MESH viewer has working shadows for nVidia GPU's on Mac (never happened before on any known config), and anti-aliasing's fixed. If we could get that bit out of the mesh viewer and into the 2.2 pipeline, we'd really be in great shape IMO. Trilo On Oct 15, 2010, at 10:07 AM, Ponzu wrote: > I tried this viewer last night. As I am sure you Lindens know, it is based on a version of viewer-development that is many days old. (Some complaint, huh?) > > Could perhaps someone help the Mesh team pull the most relevant changesets from viewer-dev so their next release lacks the more annoying problems? (such as my personal favorite, SH-173 8-) > > best regards, > lee > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting privileges From kf6kjg at gmail.com Fri Oct 15 15:23:49 2010 From: kf6kjg at gmail.com (Ricky) Date: Fri, 15 Oct 2010 15:23:49 -0700 Subject: [opensource-dev] O.O Display name code DROP! In-Reply-To: References: <000001cb6c04$2650ce50$72f26af0$@net> Message-ID: Actually, IMHO that was the catalyst, not the reason. The reason was that there needs to be a pile of information about the posts. The log files just don't contain enough information, especially with Display Names. With an expanded format, such as any of LLSD/XML/JSON, you can associate all the needed information in an expandable, fairly future-proof format. Text files just don't cut it. Named fields, as given by any of the above formats, allow adding fields without breaking any tools made for the new format. Text doesn't. Neither any of the common flavors of CSV. It's just sad that the files weren't in one of these formats a long time ago. Something I'm going to take to heart as I develop games and tools. Now, as to LLSD over any of the others. The reason is ease of coding. LLSD is something already used, and fairly well-defined, in the viewer. A custom XML or JSON format would take defining the syntax, creating a standard, etc. LLSD is already there, and well known. The functions for converting to it are all already in place. As such it's less bloat to the viewer to use that format. In fact, depending on how the structure exists in the code (I haven't looked,) it may have even been easier to export as LLSD than the original text. Adding an option WOULD have been bloat. if you want text in the original style, JSON, Wikicode, or prettified HTML, all it takes is running the log file though the proper XSL stylesheet using your favorite XML processing tool. Pretty trivial. Such tools could even be built into the viewer, but I don't see the need. Those who do, feel free to add to a TPV, or provide a solid, reasoned argument for such. Or you can get it added to a TPV, if the author finds it useful to them. Over-all I think this was a good move: the files are easier to write lexers for as we can leverage existing parsers, and they are still not too hard to read from a human standpoint - assuming useful line breaks in the files. Ricky Cron Stardust On Fri, Oct 15, 2010 at 2:52 PM, Harold Brown wrote: > This is another change that a very small percentage of people wanted > that was made without consideration to how it affects the larger > community. > > The PROPER change should have been to add an OPTION to log to .llsd > for those people making log files of Office Hours parsing log files > for posting to the wiki was the reason for this change. > > On Fri, Oct 15, 2010 at 2:36 PM, Ricky wrote: >> Besides, back on Sept 2nd this was already discussed, and plans >> invented. ?https://lists.secondlife.com/pipermail/opensource-dev/2010-September/003162.html >> >> All that's needed is a linked XSL stylesheet to make it just as easy >> to read as the text files were. ?Just using a web browser instead of a >> text editor. ?Josh solved the XSL in this response: >> https://lists.secondlife.com/pipermail/opensource-dev/2010-September/003164.html >> >> Tis is actually a good step. ?Admittedly the file size might jump, but >> I'm pretty sure each of us has the drive space, and appending to a >> file is trivial. ?I do believe it can be done in near constant time, >> relative to the file size. >> >> Ricky >> Cron Stardust >> >> On Fri, Oct 15, 2010 at 2:12 PM, Marc Adored wrote: >>> All this panic did anyone stop to think that maybe this is part of a >>> bigger plan? The first thing that cam to mind for me was maybe it >>> makes it easier for programs to format them and probably better for >>> searching and stuff (withen a program). Also maybe there are plans for >>> a built in log viewer coming soon? I think that this format is less >>> then ideal but then again I have no idea what might be planned and why >>> this specific format was chosen >>> >>> On Fri, Oct 15, 2010 at 4:46 PM, Garmin Kawaguichi >>> wrote: >>>> It was a JIRA from Samia Bechir >>>> https://jira.secondlife.com/browse/VWR-22940?dated from September 10 >>>> You can vote for it >>>> >>>> GCI >>>> >>>> >>>> >>>> ----- Original Message ----- >>>> From: WolfPup Lowenhar >>>> To: OpenSource Mailing List >>>> Sent: Friday, October 15, 2010 2:58 AM >>>> Subject: [opensource-dev] O.O Display name code DROP! >>>> >>>> Well folks my night is going to be interesting as now I have to hard merge >>>> my logging code to the new code as there are changes to the way logs are >>>> EVEN saved .llsd instead of .txt which is going to make things interesting >>>> for me as now I have to change my history look up code for the new file >>>> extension and maybe even the name formatting itself! >>>> >>>> ________________________________ >>>> >>>> _______________________________________________ >>>> Policies and (un)subscribe information available here: >>>> http://wiki.secondlife.com/wiki/OpenSource-Dev >>>> Please read the policies before posting to keep unmoderated posting >>>> privileges >>>> >>>> _______________________________________________ >>>> Policies and (un)subscribe information available here: >>>> http://wiki.secondlife.com/wiki/OpenSource-Dev >>>> Please read the policies before posting to keep unmoderated posting >>>> privileges >>>> >>> _______________________________________________ >>> Policies and (un)subscribe information available here: >>> http://wiki.secondlife.com/wiki/OpenSource-Dev >>> Please read the policies before posting to keep unmoderated posting privileges >>> >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/OpenSource-Dev >> Please read the policies before posting to keep unmoderated posting privileges >> > From angel_of_crimson at hotmail.com Fri Oct 15 15:25:12 2010 From: angel_of_crimson at hotmail.com (Erin Mallory) Date: Fri, 15 Oct 2010 18:25:12 -0400 Subject: [opensource-dev] O.O Display name code DROP! In-Reply-To: References: <000001cb6c04$2650ce50$72f26af0$@net>, , , Message-ID: Speak for yourself. My drives are only 250gig and 500 gig. Even with having lost 3 years wroth of logs, in txt format, my log folders are ALREADY almost half a gig. That's in just 3 months. ... > From: kf6kjg at gmail.com > Date: Fri, 15 Oct 2010 14:36:06 -0700 > To: marc at inworlddesigns.com > CC: opensource-dev at lists.secondlife.com > Subject: Re: [opensource-dev] O.O Display name code DROP! > > Besides, back on Sept 2nd this was already discussed, and plans > invented. https://lists.secondlife.com/pipermail/opensource-dev/2010-September/003162.html > > All that's needed is a linked XSL stylesheet to make it just as easy > to read as the text files were. Just using a web browser instead of a > text editor. Josh solved the XSL in this response: > https://lists.secondlife.com/pipermail/opensource-dev/2010-September/003164.html > > Tis is actually a good step. Admittedly the file size might jump, but > I'm pretty sure each of us has the drive space, and appending to a > file is trivial. I do believe it can be done in near constant time, > relative to the file size. > > Ricky > Cron Stardust > > On Fri, Oct 15, 2010 at 2:12 PM, Marc Adored wrote: > > All this panic did anyone stop to think that maybe this is part of a > > bigger plan? The first thing that cam to mind for me was maybe it > > makes it easier for programs to format them and probably better for > > searching and stuff (withen a program). Also maybe there are plans for > > a built in log viewer coming soon? I think that this format is less > > then ideal but then again I have no idea what might be planned and why > > this specific format was chosen > > > > On Fri, Oct 15, 2010 at 4:46 PM, Garmin Kawaguichi > > wrote: > >> It was a JIRA from Samia Bechir > >> https://jira.secondlife.com/browse/VWR-22940 dated from September 10 > >> You can vote for it > >> > >> GCI > >> > >> > >> > >> ----- Original Message ----- > >> From: WolfPup Lowenhar > >> To: OpenSource Mailing List > >> Sent: Friday, October 15, 2010 2:58 AM > >> Subject: [opensource-dev] O.O Display name code DROP! > >> > >> Well folks my night is going to be interesting as now I have to hard merge > >> my logging code to the new code as there are changes to the way logs are > >> EVEN saved .llsd instead of .txt which is going to make things interesting > >> for me as now I have to change my history look up code for the new file > >> extension and maybe even the name formatting itself! > >> > >> ________________________________ > >> > >> _______________________________________________ > >> Policies and (un)subscribe information available here: > >> http://wiki.secondlife.com/wiki/OpenSource-Dev > >> Please read the policies before posting to keep unmoderated posting > >> privileges > >> > >> _______________________________________________ > >> Policies and (un)subscribe information available here: > >> http://wiki.secondlife.com/wiki/OpenSource-Dev > >> Please read the policies before posting to keep unmoderated posting > >> privileges > >> > > _______________________________________________ > > Policies and (un)subscribe information available here: > > http://wiki.secondlife.com/wiki/OpenSource-Dev > > Please read the policies before posting to keep unmoderated posting privileges > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting privileges -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101015/0e6ff1b4/attachment.htm From angel_of_crimson at hotmail.com Fri Oct 15 15:31:44 2010 From: angel_of_crimson at hotmail.com (Erin Mallory) Date: Fri, 15 Oct 2010 18:31:44 -0400 Subject: [opensource-dev] O.O Display name code DROP! In-Reply-To: References: <000001cb6c04$2650ce50$72f26af0$@net>, , , , , Message-ID: Actually its a bad move. For one: logs should NOT have fields. The display name used at the time should NOT change in the logs once someone changes their user name, which appears to be what this file format does. TWO, to require you users to download a style sheet and use a web browser to view logs is just asininely retarded. Users who need their logs regularly need to access them FAST and in an EASY format to read and print. This is another case where LL took a good idea and implemented it so badly as to make it a total fail. This really needs to be undone. > From: kf6kjg at gmail.com > Date: Fri, 15 Oct 2010 15:23:49 -0700 > To: labrat.hb at gmail.com > CC: opensource-dev at lists.secondlife.com > Subject: Re: [opensource-dev] O.O Display name code DROP! > > Actually, IMHO that was the catalyst, not the reason. The reason was > that there needs to be a pile of information about the posts. The log > files just don't contain enough information, especially with Display > Names. With an expanded format, such as any of LLSD/XML/JSON, you can > associate all the needed information in an expandable, fairly > future-proof format. Text files just don't cut it. Named fields, as > given by any of the above formats, allow adding fields without > breaking any tools made for the new format. Text doesn't. Neither any > of the common flavors of CSV. It's just sad that the files weren't in > one of these formats a long time ago. Something I'm going to take to > heart as I develop games and tools. > > Now, as to LLSD over any of the others. The reason is ease of coding. > LLSD is something already used, and fairly well-defined, in the > viewer. A custom XML or JSON format would take defining the syntax, > creating a standard, etc. LLSD is already there, and well known. The > functions for converting to it are all already in place. As such it's > less bloat to the viewer to use that format. In fact, depending on > how the structure exists in the code (I haven't looked,) it may have > even been easier to export as LLSD than the original text. > > Adding an option WOULD have been bloat. if you want text in the > original style, JSON, Wikicode, or prettified HTML, all it takes is > running the log file though the proper XSL stylesheet using your > favorite XML processing tool. Pretty trivial. Such tools could even > be built into the viewer, but I don't see the need. Those who do, > feel free to add to a TPV, or provide a solid, reasoned argument for > such. Or you can get it added to a TPV, if the author finds it useful > to them. > > Over-all I think this was a good move: the files are easier to write > lexers for as we can leverage existing parsers, and they are still not > too hard to read from a human standpoint - assuming useful line breaks > in the files. > > Ricky > Cron Stardust > > > On Fri, Oct 15, 2010 at 2:52 PM, Harold Brown wrote: > > This is another change that a very small percentage of people wanted > > that was made without consideration to how it affects the larger > > community. > > > > The PROPER change should have been to add an OPTION to log to .llsd > > for those people making log files of Office Hours parsing log files > > for posting to the wiki was the reason for this change. > > > > On Fri, Oct 15, 2010 at 2:36 PM, Ricky wrote: > >> Besides, back on Sept 2nd this was already discussed, and plans > >> invented. https://lists.secondlife.com/pipermail/opensource-dev/2010-September/003162.html > >> > >> All that's needed is a linked XSL stylesheet to make it just as easy > >> to read as the text files were. Just using a web browser instead of a > >> text editor. Josh solved the XSL in this response: > >> https://lists.secondlife.com/pipermail/opensource-dev/2010-September/003164.html > >> > >> Tis is actually a good step. Admittedly the file size might jump, but > >> I'm pretty sure each of us has the drive space, and appending to a > >> file is trivial. I do believe it can be done in near constant time, > >> relative to the file size. > >> > >> Ricky > >> Cron Stardust > >> > >> On Fri, Oct 15, 2010 at 2:12 PM, Marc Adored wrote: > >>> All this panic did anyone stop to think that maybe this is part of a > >>> bigger plan? The first thing that cam to mind for me was maybe it > >>> makes it easier for programs to format them and probably better for > >>> searching and stuff (withen a program). Also maybe there are plans for > >>> a built in log viewer coming soon? I think that this format is less > >>> then ideal but then again I have no idea what might be planned and why > >>> this specific format was chosen > >>> > >>> On Fri, Oct 15, 2010 at 4:46 PM, Garmin Kawaguichi > >>> wrote: > >>>> It was a JIRA from Samia Bechir > >>>> https://jira.secondlife.com/browse/VWR-22940 dated from September 10 > >>>> You can vote for it > >>>> > >>>> GCI > >>>> > >>>> > >>>> > >>>> ----- Original Message ----- > >>>> From: WolfPup Lowenhar > >>>> To: OpenSource Mailing List > >>>> Sent: Friday, October 15, 2010 2:58 AM > >>>> Subject: [opensource-dev] O.O Display name code DROP! > >>>> > >>>> Well folks my night is going to be interesting as now I have to hard merge > >>>> my logging code to the new code as there are changes to the way logs are > >>>> EVEN saved .llsd instead of .txt which is going to make things interesting > >>>> for me as now I have to change my history look up code for the new file > >>>> extension and maybe even the name formatting itself! > >>>> > >>>> ________________________________ > >>>> > >>>> _______________________________________________ > >>>> Policies and (un)subscribe information available here: > >>>> http://wiki.secondlife.com/wiki/OpenSource-Dev > >>>> Please read the policies before posting to keep unmoderated posting > >>>> privileges > >>>> > >>>> _______________________________________________ > >>>> Policies and (un)subscribe information available here: > >>>> http://wiki.secondlife.com/wiki/OpenSource-Dev > >>>> Please read the policies before posting to keep unmoderated posting > >>>> privileges > >>>> > >>> _______________________________________________ > >>> Policies and (un)subscribe information available here: > >>> http://wiki.secondlife.com/wiki/OpenSource-Dev > >>> Please read the policies before posting to keep unmoderated posting privileges > >>> > >> _______________________________________________ > >> Policies and (un)subscribe information available here: > >> http://wiki.secondlife.com/wiki/OpenSource-Dev > >> Please read the policies before posting to keep unmoderated posting privileges > >> > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting privileges -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101015/4850655c/attachment.htm From marc at inworlddesigns.com Fri Oct 15 15:38:54 2010 From: marc at inworlddesigns.com (Marc Adored) Date: Fri, 15 Oct 2010 18:38:54 -0400 Subject: [opensource-dev] O.O Display name code DROP! In-Reply-To: References: <000001cb6c04$2650ce50$72f26af0$@net> Message-ID: Download a stylesheet? The file would contain a link directly to the stylesheet and would be automatically loaded. Also I'm not sure about your operating system but I'm pretty sure the file extension already opens in your default browser and once the stylesheet is specified it will look just like a plain text log file just loaded in your browser through the same process and opening a text file. The only fear here is change and the unknown. It's not going to be any harder to read the logs just different. Sorry like Ricky said its more future proof and thats all there is too it the only mistake was not setting this up earlier so the change didn't frighten so many people On Fri, Oct 15, 2010 at 6:31 PM, Erin Mallory wrote: > Actually its a bad move.? For one: logs should NOT have fields.? The display > name used at the time should NOT change in the logs once someone changes > their user name, which appears to be what this file format does. > TWO, to require you users to download a style sheet and use a web browser to > view logs is just asininely retarded.? Users who need their logs regularly > need to access them FAST and in an EASY format to read and print. > This is another case where LL took a good idea and implemented it so badly > as to make it a total fail. ? This really needs to be undone. > >> From: kf6kjg at gmail.com >> Date: Fri, 15 Oct 2010 15:23:49 -0700 >> To: labrat.hb at gmail.com >> CC: opensource-dev at lists.secondlife.com >> Subject: Re: [opensource-dev] O.O Display name code DROP! >> >> Actually, IMHO that was the catalyst, not the reason. The reason was >> that there needs to be a pile of information about the posts. The log >> files just don't contain enough information, especially with Display >> Names. With an expanded format, such as any of LLSD/XML/JSON, you can >> associate all the needed information in an expandable, fairly >> future-proof format. Text files just don't cut it. Named fields, as >> given by any of the above formats, allow adding fields without >> breaking any tools made for the new format. Text doesn't. Neither any >> of the common flavors of CSV. It's just sad that the files weren't in >> one of these formats a long time ago. Something I'm going to take to >> heart as I develop games and tools. >> >> Now, as to LLSD over any of the others. The reason is ease of coding. >> LLSD is something already used, and fairly well-defined, in the >> viewer. A custom XML or JSON format would take defining the syntax, >> creating a standard, etc. LLSD is already there, and well known. The >> functions for converting to it are all already in place. As such it's >> less bloat to the viewer to use that format. In fact, depending on >> how the structure exists in the code (I haven't looked,) it may have >> even been easier to export as LLSD than the original text. >> >> Adding an option WOULD have been bloat. if you want text in the >> original style, JSON, Wikicode, or prettified HTML, all it takes is >> running the log file though the proper XSL stylesheet using your >> favorite XML processing tool. Pretty trivial. Such tools could even >> be built into the viewer, but I don't see the need. Those who do, >> feel free to add to a TPV, or provide a solid, reasoned argument for >> such. Or you can get it added to a TPV, if the author finds it useful >> to them. >> >> Over-all I think this was a good move: the files are easier to write >> lexers for as we can leverage existing parsers, and they are still not >> too hard to read from a human standpoint - assuming useful line breaks >> in the files. >> >> Ricky >> Cron Stardust >> >> >> On Fri, Oct 15, 2010 at 2:52 PM, Harold Brown wrote: >> > This is another change that a very small percentage of people wanted >> > that was made without consideration to how it affects the larger >> > community. >> > >> > The PROPER change should have been to add an OPTION to log to .llsd >> > for those people making log files of Office Hours parsing log files >> > for posting to the wiki was the reason for this change. >> > >> > On Fri, Oct 15, 2010 at 2:36 PM, Ricky wrote: >> >> Besides, back on Sept 2nd this was already discussed, and plans >> >> invented. >> >> ?https://lists.secondlife.com/pipermail/opensource-dev/2010-September/003162.html >> >> >> >> All that's needed is a linked XSL stylesheet to make it just as easy >> >> to read as the text files were. ?Just using a web browser instead of a >> >> text editor. ?Josh solved the XSL in this response: >> >> >> >> https://lists.secondlife.com/pipermail/opensource-dev/2010-September/003164.html >> >> >> >> Tis is actually a good step. ?Admittedly the file size might jump, but >> >> I'm pretty sure each of us has the drive space, and appending to a >> >> file is trivial. ?I do believe it can be done in near constant time, >> >> relative to the file size. >> >> >> >> Ricky >> >> Cron Stardust >> >> >> >> On Fri, Oct 15, 2010 at 2:12 PM, Marc Adored >> >> wrote: >> >>> All this panic did anyone stop to think that maybe this is part of a >> >>> bigger plan? The first thing that cam to mind for me was maybe it >> >>> makes it easier for programs to format them and probably better for >> >>> searching and stuff (withen a program). Also maybe there are plans for >> >>> a built in log viewer coming soon? I think that this format is less >> >>> then ideal but then again I have no idea what might be planned and why >> >>> this specific format was chosen >> >>> >> >>> On Fri, Oct 15, 2010 at 4:46 PM, Garmin Kawaguichi >> >>> wrote: >> >>>> It was a JIRA from Samia Bechir >> >>>> https://jira.secondlife.com/browse/VWR-22940?dated from September 10 >> >>>> You can vote for it >> >>>> >> >>>> GCI >> >>>> >> >>>> >> >>>> >> >>>> ----- Original Message ----- >> >>>> From: WolfPup Lowenhar >> >>>> To: OpenSource Mailing List >> >>>> Sent: Friday, October 15, 2010 2:58 AM >> >>>> Subject: [opensource-dev] O.O Display name code DROP! >> >>>> >> >>>> Well folks my night is going to be interesting as now I have to hard >> >>>> merge >> >>>> my logging code to the new code as there are changes to the way logs >> >>>> are >> >>>> EVEN saved .llsd instead of .txt which is going to make things >> >>>> interesting >> >>>> for me as now I have to change my history look up code for the new >> >>>> file >> >>>> extension and maybe even the name formatting itself! >> >>>> >> >>>> ________________________________ >> >>>> >> >>>> _______________________________________________ >> >>>> Policies and (un)subscribe information available here: >> >>>> http://wiki.secondlife.com/wiki/OpenSource-Dev >> >>>> Please read the policies before posting to keep unmoderated posting >> >>>> privileges >> >>>> >> >>>> _______________________________________________ >> >>>> Policies and (un)subscribe information available here: >> >>>> http://wiki.secondlife.com/wiki/OpenSource-Dev >> >>>> Please read the policies before posting to keep unmoderated posting >> >>>> privileges >> >>>> >> >>> _______________________________________________ >> >>> Policies and (un)subscribe information available here: >> >>> http://wiki.secondlife.com/wiki/OpenSource-Dev >> >>> Please read the policies before posting to keep unmoderated posting >> >>> privileges >> >>> >> >> _______________________________________________ >> >> Policies and (un)subscribe information available here: >> >> http://wiki.secondlife.com/wiki/OpenSource-Dev >> >> Please read the policies before posting to keep unmoderated posting >> >> privileges >> >> >> > >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/OpenSource-Dev >> Please read the policies before posting to keep unmoderated posting >> privileges > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting > privileges > From dave at meadowlakearts.com Fri Oct 15 15:44:22 2010 From: dave at meadowlakearts.com (Dave Booth) Date: Fri, 15 Oct 2010 17:44:22 -0500 Subject: [opensource-dev] O.O Display name code DROP! In-Reply-To: References: <000001cb6c04$2650ce50$72f26af0$@net> Message-ID: <4CB8D946.2050809@meadowlakearts.com> On 10/15/2010 17:38, Marc Adored wrote: Bollocks. From sllists at boroon.dasgupta.ch Fri Oct 15 15:49:11 2010 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Sat, 16 Oct 2010 00:49:11 +0200 Subject: [opensource-dev] LLSD logs (was: O.O Display name code DROP!) In-Reply-To: References: <000001cb6c04$2650ce50$72f26af0$@net> Message-ID: <4CB8DA67.4080800@boroon.dasgupta.ch> On 10/15/2010 11:36 PM, Ricky wrote: > Besides, back on Sept 2nd this was already discussed, and plans > invented. https://lists.secondlife.com/pipermail/opensource-dev/2010-September/003162.html That was more throwing ideas around than actual plans. We probably can't even be sure the display names team was aware of that discussion. > All that's needed is a linked XSL stylesheet to make it just as easy > to read as the text files were. Just using a web browser instead of a > text editor. Josh solved the XSL in this response: > https://lists.secondlife.com/pipermail/opensource-dev/2010-September/003164.html That could be used for the XML serialization of LLSD. It looks like the new log format uses the "notation serialization" (who came up with that name?) of LLSD, which is more compact and supposed to be more human readable as-is but probably difficult to format using standard tools. > Tis is actually a good step. Admittedly the file size might jump, but > I'm pretty sure each of us has the drive space, and appending to a > file is trivial. I do believe it can be done in near constant time, > relative to the file size. Yeah, the new format looks just as suited for appending as the old was. What seems strange to me though: Why is a string used for the time, rather than LLSD's date type? Cheers, Boroondas -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101016/141aed3e/attachment.htm From suezanne at gmail.com Fri Oct 15 15:59:26 2010 From: suezanne at gmail.com (SuezanneC Baskerville) Date: Fri, 15 Oct 2010 17:59:26 -0500 Subject: [opensource-dev] O.O Display name code DROP! In-Reply-To: <000001cb6c25$7787f660$6697e320$@net> References: <000001cb6c04$2650ce50$72f26af0$@net> <4CB7D905.60706@beau.org> <000001cb6c25$7787f660$6697e320$@net> Message-ID: What happened to that jira issue? It appears to have been moved to SEC or something like that. On Thu, Oct 14, 2010 at 11:57 PM, WolfPup Lowenhar wrote: > Actualy the file extension change is only to chat and IM logs. And I have > already found a bug in the code! > > > > https://jira.secondlife.com/browse/VWR-23437 > > > > the above jira is the bug and it is not being cause be my file name > modification as the mod is working fine for group IM?s. > > > > *From:* opensource-dev-bounces at lists.secondlife.com [mailto: > opensource-dev-bounces at lists.secondlife.com] *On Behalf Of *Jamey Fletcher > *Sent:* Friday, October 15, 2010 12:31 AM > *To:* opensource-dev at lists.secondlife.com > *Subject:* Re: [opensource-dev] O.O Display name code DROP! > > > > WolfPup Lowenhar wrote: > > Well folks my night is going to be interesting as now I have to hard > > merge my logging code to the new code as there are changes to the way > > logs are EVEN saved .llsd instead of .txt which is going to make things > > interesting for me as now I have to change my history look up code for > > the new file extension and maybe even the name formatting itself! > > Is that the crash & console logs, or the chat logs too? > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting > privileges > ------------------------------ > > No virus found in this message. > Checked by AVG - www.avg.com > Version: 10.0.1136 / Virus Database: 422/3196 - Release Date: 10/14/10 > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting > privileges > -- v i r t u a l w o r l d e n t h u s i a s t -- http://www.google.com/profiles/s u e z a n n e -- -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101015/c265e160/attachment.htm From marc at inworlddesigns.com Fri Oct 15 16:00:34 2010 From: marc at inworlddesigns.com (Marc Adored) Date: Fri, 15 Oct 2010 19:00:34 -0400 Subject: [opensource-dev] O.O Display name code DROP! In-Reply-To: <4CB8D946.2050809@meadowlakearts.com> References: <000001cb6c04$2650ce50$72f26af0$@net> <4CB8D946.2050809@meadowlakearts.com> Message-ID: Which part is bullocks? The accurate description of how things will change or the accurate description of how things will change? Fact is it's not going to change much for anyone when its finished (assuming they are going to provide a stylesheet for it). You will still simply double click the file to open it and view the log and you can search the same way you did before with ctrl+f or whatever your os's normal search keys are. nothing changes but the program it opens in. If for some reason it is not associated with your browser simply double clicking the file will ask you what to open it with and you just tell it to remember that and your back to normal. So as I see it no disadvantage outside of a slightly larger file size. But a big advantage on the other side. Its a easier format to "parse" which will allow you to see it and search it easier and faster in whatever program that is made to parse the files either built into the viewer or an external log management system. Above all that a change like this had to happen. There was no way around it. With Display names being variables now it had to happen. They had to have a way to link the variable to the constant... This to them and the more i read to me seemed like the best solution. Its already a built in format the viewer already uses and is very extensible when it comes to adding/removing things and styling. Essentially if they load a local stylesheet that would allow you to modify the stylesheet to make your logs look the way you want them like changing a theme. I'm sure this idea will be used for an internal log viewer if its added. All I am really saying is wait for it. It is beta and doesn't seemed to be finished yet. To people who know what is capable with the format know what might be planned. I know for someone who doesn't know about the format or anything outside of plaintext it might be garbage right now but the potential is huge On Fri, Oct 15, 2010 at 6:44 PM, Dave Booth wrote: > ?On 10/15/2010 17:38, Marc Adored wrote: > > > > Bollocks. > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting privileges > From armin.weatherwax at googlemail.com Fri Oct 15 16:05:32 2010 From: armin.weatherwax at googlemail.com (Armin Weatherwax) Date: Sat, 16 Oct 2010 01:05:32 +0200 Subject: [opensource-dev] Project-MESH viewer In-Reply-To: <4CB892DB.1020004@lindenlab.com> References: <4CB88F6B.9020404@lindenlab.com> <4CB892DB.1020004@lindenlab.com> Message-ID: <201010160105.32606.Armin.Weatherwax@gmail.com> Nyx Linden wrote: > We just pulled from viewer-development yesterday actually, but we had > already released the initial beta viewer. > We try to stay reasonably up to date, but we don't merge the latest > changes every day. > > Don't worry we will stay synced! > > ? -Nyx Its anyway awsome - ty and all working on it :) Armin From yoz at lindenlab.com Fri Oct 15 16:14:16 2010 From: yoz at lindenlab.com (Yoz Grahame) Date: Fri, 15 Oct 2010 16:14:16 -0700 Subject: [opensource-dev] O.O Display name code DROP! In-Reply-To: <4CB8D946.2050809@meadowlakearts.com> References: <000001cb6c04$2650ce50$72f26af0$@net> <4CB8D946.2050809@meadowlakearts.com> Message-ID: On 15 October 2010 15:44, Dave Booth wrote: > On 10/15/2010 17:38, Marc Adored wrote: > > > > Bollocks. > Thanks for providing a succinct example of what really isn't OK around here. Disagreement: Fine. Passionate argument: Fine, as long as it's civil and reasoned. Confrontational rudeness with no redeeming value: Out Of Order. If it's possible to provide actual reasoned argument in a civil tone, we would welcome it. If not, we would welcome (and assist) your departure. -- Yoz Linden -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101015/97d8ab9d/attachment.htm From suezanne at gmail.com Fri Oct 15 16:21:59 2010 From: suezanne at gmail.com (SuezanneC Baskerville) Date: Fri, 15 Oct 2010 18:21:59 -0500 Subject: [opensource-dev] Replying to OpenSource-Dev using Gmail. Message-ID: I switched my listmanager settings from Digest to individual messages recently. I use Gmail. I just tried to reply to an OSD thread, and it appears that the mail would be going to one individual rather than to the mailing list. I didn't seem to have this problem with the list set to send digests, however then the mail is filled with repeatedly quoted text. Also with the list sent to not use digest mode, the From field in Gmail shows an individual's name rather than Open Source Dev Request like it does when the list is in digest mode. Anyone know how to make Gmail do a little better with this list? -- v i r t u a l w o r l d e n t h u s i a s t -- http://www.google.com/profiles/s u e z a n n e -- -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101015/b45e6753/attachment-0001.htm From sllists at boroon.dasgupta.ch Fri Oct 15 16:22:48 2010 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Sat, 16 Oct 2010 01:22:48 +0200 Subject: [opensource-dev] O.O Display name code DROP! In-Reply-To: References: <000001cb6c04$2650ce50$72f26af0$@net> <4CB7D905.60706@beau.org> <000001cb6c25$7787f660$6697e320$@net> Message-ID: <4CB8E248.60001@boroon.dasgupta.ch> On 10/16/2010 12:59 AM, SuezanneC Baskerville wrote: > What happened to that jira issue? It appears to have been moved to SEC > or something like that. It has been moved to DN-179 . (I guess "DN" stands for "display names".) Why we can't see that jira project although display names has been on Aditi for some while now, I don't know. Cheers, Boroondas -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101016/22267b47/attachment.htm From leyla at lindenlab.com Fri Oct 15 16:23:27 2010 From: leyla at lindenlab.com (Leyla Linden) Date: Fri, 15 Oct 2010 16:23:27 -0700 Subject: [opensource-dev] O.O Display name code DROP! In-Reply-To: <4CB8D946.2050809@meadowlakearts.com> References: <000001cb6c04$2650ce50$72f26af0$@net> <4CB8D946.2050809@meadowlakearts.com> Message-ID: Hi All, The chat log format change wasinitially done so we could easily add more information in the chat logs. Now that the display name can change it's nice to have more data like an agent_id that can be hooked up to inspectors. But seeing as how many people rely on easily readable text chat logs, we're going to revert them back to text files. The only difference is that they'll include both display names and usernames, much like Rob Nelson suggested. - Leyla -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101015/cfba05d3/attachment.htm From marc at inworlddesigns.com Fri Oct 15 16:25:44 2010 From: marc at inworlddesigns.com (Marc Adored) Date: Fri, 15 Oct 2010 19:25:44 -0400 Subject: [opensource-dev] O.O Display name code DROP! In-Reply-To: References: <000001cb6c04$2650ce50$72f26af0$@net> <4CB8D946.2050809@meadowlakearts.com> Message-ID: Oh well so much for progress :( Is linden labs going to provide a tool to convert current llsd logs back to plaintext? On Fri, Oct 15, 2010 at 7:23 PM, Leyla Linden wrote: > Hi All, > The chat log format change wasinitially done so we could easily add > more information in the?chat logs. ?Now that the display name can > change it's nice to have?more?data like an agent_id that can be hooked > up to inspectors. > But seeing as how many people rely on easily readable text chat logs, > we're going to revert them back to text files. ?The only difference is that > they'll include both display names and usernames, much like Rob > Nelson suggested. > - Leyla > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting > privileges > From marc at inworlddesigns.com Fri Oct 15 16:28:25 2010 From: marc at inworlddesigns.com (Marc Adored) Date: Fri, 15 Oct 2010 19:28:25 -0400 Subject: [opensource-dev] Replying to OpenSource-Dev using Gmail. In-Reply-To: References: Message-ID: Use reply to all it replies to the person ad cc's to the mailing list. Somehow the person in the TO field doesnt get a duplicate either like you think they would so it works perfect. On Fri, Oct 15, 2010 at 7:21 PM, SuezanneC Baskerville wrote: > I switched my listmanager settings from Digest to individual messages > recently. > > I use Gmail. > > I just tried to reply to an OSD thread, and it appears that the mail would > be going to one individual rather than to the mailing list. > > I didn't seem to have this problem with the list set to send digests, > however then the mail is filled with repeatedly quoted text. > > Also with the list sent to not use digest mode, the From field in Gmail > shows an individual's name rather than Open Source Dev Request like it does > when the list is in digest mode. > > Anyone know how to make Gmail do a little better with this list? > > -- > v i r t u a l?? w o r l d?? e n t h u s i a s t > -- http://www.google.com/profiles/s u e z a n n e -- > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting > privileges > From teravus at gmail.com Fri Oct 15 16:39:22 2010 From: teravus at gmail.com (Teravus Ovares) Date: Fri, 15 Oct 2010 19:39:22 -0400 Subject: [opensource-dev] Replying to OpenSource-Dev using Gmail. In-Reply-To: References: Message-ID: On that note, there's a gmail Lab feature which makes 'Reply to All' default and makes it so you have to dig for 'Reply' when you want to reply to someone individually off list. I use it for this e-mail address.. but be careful. It might not be appropriate for every situation. -Teravus On Fri, Oct 15, 2010 at 7:21 PM, SuezanneC Baskerville wrote: > I switched my listmanager settings from Digest to individual messages > recently. > > I use Gmail. > > I just tried to reply to an OSD thread, and it appears that the mail would > be going to one individual rather than to the mailing list. > > I didn't seem to have this problem with the list set to send digests, > however then the mail is filled with repeatedly quoted text. > > Also with the list sent to not use digest mode, the From field in Gmail > shows an individual's name rather than Open Source Dev Request like it does > when the list is in digest mode. > > Anyone know how to make Gmail do a little better with this list? > > -- > v i r t u a l w o r l d e n t h u s i a s t > -- http://www.google.com/profiles/s u e z a n n e -- > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101015/b7e6fa43/attachment.htm From suezanne at gmail.com Fri Oct 15 16:49:52 2010 From: suezanne at gmail.com (SuezanneC Baskerville) Date: Fri, 15 Oct 2010 18:49:52 -0500 Subject: [opensource-dev] Replying to OpenSource-Dev using Gmail. In-Reply-To: References: Message-ID: Thanks. Gee, it would be nice if it would work like it looks like it would work. On Fri, Oct 15, 2010 at 6:39 PM, Teravus Ovares wrote: > On that note, there's a gmail Lab feature which makes 'Reply to All' > default and makes it so you have to dig for 'Reply' when you want to reply > to someone individually off list. I use it for this e-mail address.. > but be careful. It might not be appropriate for every situation. > > -Teravus > > On Fri, Oct 15, 2010 at 7:21 PM, SuezanneC Baskerville > wrote: > >> I switched my listmanager settings from Digest to individual messages >> recently. >> >> I use Gmail. >> >> I just tried to reply to an OSD thread, and it appears that the mail would >> be going to one individual rather than to the mailing list. >> >> I didn't seem to have this problem with the list set to send digests, >> however then the mail is filled with repeatedly quoted text. >> >> Also with the list sent to not use digest mode, the From field in Gmail >> shows an individual's name rather than Open Source Dev Request like it does >> when the list is in digest mode. >> >> Anyone know how to make Gmail do a little better with this list? >> >> -- >> v i r t u a l w o r l d e n t h u s i a s t >> -- http://www.google.com/profiles/s u e z a n n e -- >> >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/OpenSource-Dev >> Please read the policies before posting to keep unmoderated posting >> privileges >> > > -- v i r t u a l w o r l d e n t h u s i a s t -- http://www.google.com/profiles/s u e z a n n e -- -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101015/f1c7e62e/attachment.htm From sythos at gmail.com Fri Oct 15 16:56:23 2010 From: sythos at gmail.com (Altair Sythos Memo) Date: Sat, 16 Oct 2010 01:56:23 +0200 Subject: [opensource-dev] O.O Display name code DROP! In-Reply-To: References: <000001cb6c04$2650ce50$72f26af0$@net> <4CB8D946.2050809@meadowlakearts.com> Message-ID: <20101016015623.ed3f5624.sythos@gmail.com> On Fri, 15 Oct 2010 16:23:27 -0700 Leyla Linden wrote: > Hi All, > > The chat log format change wasinitially done so we could easily add > more information in the chat logs. Now that the display name can > change it's nice to have more data like an agent_id that can be hooked > up to inspectors. > > But seeing as how many people rely on easily readable text chat logs, > we're going to revert them back to text files. The only difference > is that they'll include both display names and usernames, much like > Rob Nelson suggested. a nice way is use "realname.txt" as file format, and inside use "displayed name" (if there is one), so inside logs there is a track of displayed name too (about how KV work now) From sllists at boroon.dasgupta.ch Fri Oct 15 17:03:05 2010 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Sat, 16 Oct 2010 02:03:05 +0200 Subject: [opensource-dev] VWR-23437 / DN-179: Personal IM logs not being generated (was: O.O Display name code DROP!) In-Reply-To: <000001cb6c25$7787f660$6697e320$@net> References: <000001cb6c04$2650ce50$72f26af0$@net> <4CB7D905.60706@beau.org> <000001cb6c25$7787f660$6697e320$@net> Message-ID: <4CB8EBB9.4080109@boroon.dasgupta.ch> On 10/15/2010 06:57 AM, WolfPup Lowenhar wrote: > > Actualy the file extension change is only to chat and IM logs. And I > have already found a bug in the code! > > > > https://jira.secondlife.com/browse/VWR-23437 > > > > the above jira is the bug and it is not being cause be my file name > modification as the mod is working fine for group IM's. > Looks like it got fixed: http://bitbucket.org/lindenlab/viewer-development/changeset/9a2f511d0bb5 Can't test it right now, due to another issue. Boroondas -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101016/8e2a7d11/attachment-0001.htm From marc at inworlddesigns.com Fri Oct 15 17:06:14 2010 From: marc at inworlddesigns.com (Marc Adored) Date: Fri, 15 Oct 2010 20:06:14 -0400 Subject: [opensource-dev] Replying to OpenSource-Dev using Gmail. In-Reply-To: References: Message-ID: The problem is the list sends the email to you from the sender not from the list so gmail replies to the person because reply replies to the sender. My other lists don't have this issue so I'm pretty sure its a setting set differently in mailman that linden might should change to make replying act like you think it would. I see a lot of replies to emails that never hit the list but the sender never knew because they just hit reply. Countless times have I seen people say "I think this was relavant to the whole list" and forwarding it to the list so people can see. I guarantee you the person who sent them the email thought it was going to the whole list. On Fri, Oct 15, 2010 at 7:49 PM, SuezanneC Baskerville wrote: > Thanks. > > Gee, it would be nice if it would work like it looks like it would work. > > > > On Fri, Oct 15, 2010 at 6:39 PM, Teravus Ovares wrote: >> >> On that note, there's a gmail Lab feature which makes 'Reply to All' >> default and makes it so you have to dig for 'Reply' when you want to reply >> to someone individually off list.???? I use it for this e-mail address.. >> but be careful.?? It might not be appropriate for every situation. >> >> -Teravus >> >> On Fri, Oct 15, 2010 at 7:21 PM, SuezanneC Baskerville >> wrote: >>> >>> I switched my listmanager settings from Digest to individual messages >>> recently. >>> >>> I use Gmail. >>> >>> I just tried to reply to an OSD thread, and it appears that the mail >>> would be going to one individual rather than to the mailing list. >>> >>> I didn't seem to have this problem with the list set to send digests, >>> however then the mail is filled with repeatedly quoted text. >>> >>> Also with the list sent to not use digest mode, the From field in Gmail >>> shows an individual's name rather than Open Source Dev Request like it does >>> when the list is in digest mode. >>> >>> Anyone know how to make Gmail do a little better with this list? >>> >>> -- >>> v i r t u a l?? w o r l d?? e n t h u s i a s t >>> -- http://www.google.com/profiles/s u e z a n n e -- >>> >>> _______________________________________________ >>> Policies and (un)subscribe information available here: >>> http://wiki.secondlife.com/wiki/OpenSource-Dev >>> Please read the policies before posting to keep unmoderated posting >>> privileges >> > > > > -- > v i r t u a l?? w o r l d?? e n t h u s i a s t > -- http://www.google.com/profiles/s u e z a n n e -- > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting > privileges > From jamey at beau.org Fri Oct 15 17:11:30 2010 From: jamey at beau.org (Jamey Fletcher) Date: Fri, 15 Oct 2010 19:11:30 -0500 Subject: [opensource-dev] O.O Display name code DROP! In-Reply-To: References: <000001cb6c04$2650ce50$72f26af0$@net> Message-ID: <4CB8EDB2.5000906@beau.org> Marc Adored wrote: > Download a stylesheet? The file would contain a link directly to the > stylesheet and would be automatically loaded. Also I'm not sure about > your operating system but I'm pretty sure the file extension already > opens in your default browser and once the stylesheet is specified it > will look just like a plain text log file just loaded in your browser > through the same process and opening a text file. The only fear here > is change and the unknown. It's not going to be any harder to read the > logs just different. Sorry like Ricky said its more future proof and > thats all there is too it the only mistake was not setting this up > earlier so the change didn't frighten so many people Let's see... Future Proof. Program to read and process a text file - anywhere from a few hundred bytes, to a small OS-wannabe like emacs. Program to process LLSD and display it - several hundred K minimum, oh, and *REQUIRED* network connection live so the referenced DTD can be retrieved - more like a program that is ALREADY being considered an OS-replacement, such as Internet Explorer, Mozilla, Safari, or Chrome, each several dozen megabytes. Ok, so let's look at a project that's *GOT* a nice long history already (some 30+ years) and is *VERY* interested in future-proofing. Minor project, really, called Project Gutenberg. Here's what *they* have to say on the subject: http://www.gutenberg.org/wiki/Gutenberg:General_FAQ#G.17._Why_is_Project_Gutenberg_so_set_on_using_Plain_Vanilla_ASCII.3F When you really, really, *REALLY* want it to be readable - ASCII plaintext is the way to go. From kf6kjg at gmail.com Fri Oct 15 17:12:08 2010 From: kf6kjg at gmail.com (Ricky) Date: Fri, 15 Oct 2010 17:12:08 -0700 Subject: [opensource-dev] LLSD logs (was: O.O Display name code DROP!) In-Reply-To: <4CB8DA67.4080800@boroon.dasgupta.ch> References: <000001cb6c04$2650ce50$72f26af0$@net> <4CB8DA67.4080800@boroon.dasgupta.ch> Message-ID: Ah yes, I'd forgotten that there was more than one form for LLSD... I've only worked with the XML-style one thus far! Since, as you say, the format is not in the XML style, then it is likely that they hadn't. Or that they had, but chose this style for being more "human friendly" - like you said. Since, as the linked page describes, the plan is to move this format into JSON, maybe this is a good opportunity for a community dev to get it fully into JSON format. ECMAScript 5th edition looks to be finalized: http://www.ecma-international.org/publications/standards/Ecma-262.htm Then we could just use some JSON tools to write a converter. Or we write a patch for exporting in XML notation, as that provides some fun options, as discussed previously. Ricky Cron Stardust On Fri, Oct 15, 2010 at 3:49 PM, Boroondas Gupte wrote: > On 10/15/2010 11:36 PM, Ricky wrote: > > Besides, back on Sept 2nd this was already discussed, and plans > invented. > https://lists.secondlife.com/pipermail/opensource-dev/2010-September/003162.html > > That was more throwing ideas around than actual plans. We probably can't > even be sure the display names team was aware of that discussion. > > All that's needed is a linked XSL stylesheet to make it just as easy > to read as the text files were. Just using a web browser instead of a > text editor. Josh solved the XSL in this response: > https://lists.secondlife.com/pipermail/opensource-dev/2010-September/003164.html > > That could be used for the XML serialization of LLSD. It looks like the new > log format uses the "notation serialization" (who came up with that name?) > of LLSD, which is more compact and supposed to be more human readable as-is > but probably difficult to format using standard tools. > > Tis is actually a good step. Admittedly the file size might jump, but > I'm pretty sure each of us has the drive space, and appending to a > file is trivial. I do believe it can be done in near constant time, > relative to the file size. > > Yeah, the new format looks just as suited for appending as the old was. > > What seems strange to me though: Why is a string used for the time, rather > than LLSD's date type? > > Cheers, > Boroondas > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting > privileges > From marc at inworlddesigns.com Fri Oct 15 17:31:48 2010 From: marc at inworlddesigns.com (Marc Adored) Date: Fri, 15 Oct 2010 20:31:48 -0400 Subject: [opensource-dev] O.O Display name code DROP! In-Reply-To: <4CB8EDB2.5000906@beau.org> References: <000001cb6c04$2650ce50$72f26af0$@net> <4CB8EDB2.5000906@beau.org> Message-ID: > > Let's see... ?Future Proof. > > Program to read and process a text file - anywhere from a few hundred > bytes, to a small OS-wannabe like emacs. ?Program to process LLSD and > display it - several hundred K minimum, oh, and *REQUIRED* network > connection live so the referenced DTD can be retrieved - And why would a network connection be required for a local DTD? also why else would you need to look at a log unless it was for something you where doing online? So even IF it was a remote DTD it wouldn't matter. Who here disconnects their internet to look at logs? What paranoia provokes that? > more like a > program that is ALREADY being considered an OS-replacement, such as > Internet Explorer, Mozilla, Safari, or Chrome, each several dozen megabytes. > Well you can exaggerate the problem all you want but most applications now run in a browser anyways and more then likely they will have their browser already open whether its posting logs to a blog or to the wiki or responding to a forum post guess what the browser is already open hmm don't see a problem.... > Ok, so let's look at a project that's *GOT* a nice long history already > (some 30+ years) and is *VERY* interested in future-proofing. ?Minor > project, really, called Project Gutenberg. ?Here's what *they* have to > say on the subject: > http://www.gutenberg.org/wiki/Gutenberg:General_FAQ#G.17._Why_is_Project_Gutenberg_so_set_on_using_Plain_Vanilla_ASCII.3F > > When you really, really, *REALLY* want it to be readable - ASCII > plaintext is the way to go. It's not really about readable its about future proofing and linking a variable name with a constant name and adding features that some may find useful. Like I said most probably wont even notice the change and some will probably even like the fact that it opens in a program probably already open. Anyways all of this means nothing anymore because all of the complaining made them reverse it so none of it matters anymore but I felt the need to respond because once again someone took what was wrote made assumptions(incorrect ones at that) about what was said and responded. I understand the reasons people are mad I hate change too. The only difference is I don't instantly discount change and start fighting against it. Its the same as when I talk to someone and I say something about viewer 2 and they say "oh I don't like viewer 2". I ask why and they say "oh I used it for about 2 seconds and switched back" that comment alone completely discredits anything else that comes out of that persons mouth about the viewer. They have no right speaking anything about it when they didn't give it a fair chance. Just like this change it didn't even get finished yet before people went nuts about it. I suppose using log formats like this: [44/44/4444 10:10:10] Display Name(real.name): something here will be fine for reading. From josh at lindenlab.com Fri Oct 15 17:28:39 2010 From: josh at lindenlab.com (Joshua Bell) Date: Fri, 15 Oct 2010 17:28:39 -0700 Subject: [opensource-dev] LLSD logs (was: O.O Display name code DROP!) In-Reply-To: References: <000001cb6c04$2650ce50$72f26af0$@net> <4CB8DA67.4080800@boroon.dasgupta.ch> Message-ID: On Fri, Oct 15, 2010 at 5:12 PM, Ricky wrote: > Ah yes, I'd forgotten that there was more than one form for LLSD... > I've only worked with the XML-style one thus far! Since, as you say, > the format is not in the XML style, then it is likely that they > hadn't. Or that they had, but chose this style for being more "human > friendly" - like you said. > > Since, as the linked page describes, the plan is to move this format > into JSON, maybe this is a good opportunity for a community dev to get > it fully into JSON format. ECMAScript 5th edition looks to be > finalized: > http://www.ecma-international.org/publications/standards/Ecma-262.htm > > Then we could just use some JSON tools to write a converter. Or we > write a patch for exporting in XML notation, as that provides some fun > options, as discussed previously. > We have source code up at: http://hg.secondlife.com/llsd ... and most of the supported languages can read/write Notation, XML, JSON and Binary serializations of LLSD. Notation serialization is loosely deprecated but has some benefits over JSON in that all LLSD types are explicitly serialized, whereas when serializing to JSON the consumer must interpret values in the correct format (e.g. data['foo'][2]['bar'].asUUID()). That's the intended use of LLSD, but not everyone follows that intent. -- Josh -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101015/4e72a1d0/attachment.htm From kf6kjg at gmail.com Fri Oct 15 17:32:55 2010 From: kf6kjg at gmail.com (Ricky) Date: Fri, 15 Oct 2010 17:32:55 -0700 Subject: [opensource-dev] O.O Display name code DROP! In-Reply-To: <4CB8EDB2.5000906@beau.org> References: <000001cb6c04$2650ce50$72f26af0$@net> <4CB8EDB2.5000906@beau.org> Message-ID: I'd have to say that future proof and archival safe are two separate qualities. Logs might need to be archived, but 90% (guessing) of the content is fluff only useful for a couple of months to a year at the most. However, the tools that read them (such as converters / archivers) have a much longer lifespan. If you do want 50+ year archival quality, then use a trivial exporter to convert to the ASCII format of your choice when you run your archival process and send it to paper punch tape. (I'm not being insulting here: paper punch tape is THE most long-lived digital format I've ever met.) As to the stylesheet: I propose that it be installed with the viewer and be located in the same folder as the logs. This way it can be archived along with the files by your favorite archival/storage tools. And viewing the file is likewise not an issue. Every modern computer already has a browser installed and in use. And if you still needed to read the log from a GUI-less computer, the logs are still ASCII. The tags surrounding the data are just helpful to the computer. This isn't a binary format we are discussing; it's a formatted text file. Formatted in a way that makes it easier for a computer to read while still being useful to the humans involved. On Fri, Oct 15, 2010 at 5:11 PM, Jamey Fletcher wrote: > Marc Adored wrote: > >> Download a stylesheet? The file would contain a link directly to the >> stylesheet and would be automatically loaded. Also I'm not sure about >> your operating system but I'm pretty sure the file extension already >> opens in your default browser and once the stylesheet is specified it >> will look just like a plain text log file just loaded in your browser >> through the same process and opening a text file. The only fear here >> is change and the unknown. It's not going to be any harder to read the >> logs just different. Sorry like Ricky said its more future proof and >> thats all there is too it the only mistake was not setting this up >> earlier so the change didn't frighten so many people > > Let's see... ?Future Proof. > > Program to read and process a text file - anywhere from a few hundred > bytes, to a small OS-wannabe like emacs. ?Program to process LLSD and > display it - several hundred K minimum, oh, and *REQUIRED* network > connection live so the referenced DTD can be retrieved - more like a > program that is ALREADY being considered an OS-replacement, such as > Internet Explorer, Mozilla, Safari, or Chrome, each several dozen megabytes. > > Ok, so let's look at a project that's *GOT* a nice long history already > (some 30+ years) and is *VERY* interested in future-proofing. ?Minor > project, really, called Project Gutenberg. ?Here's what *they* have to > say on the subject: > http://www.gutenberg.org/wiki/Gutenberg:General_FAQ#G.17._Why_is_Project_Gutenberg_so_set_on_using_Plain_Vanilla_ASCII.3F > > When you really, really, *REALLY* want it to be readable - ASCII > plaintext is the way to go. > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting privileges > From marc at inworlddesigns.com Fri Oct 15 17:46:34 2010 From: marc at inworlddesigns.com (Marc Adored) Date: Fri, 15 Oct 2010 20:46:34 -0400 Subject: [opensource-dev] Fwd: O.O Display name code DROP! In-Reply-To: References: <000001cb6c04$2650ce50$72f26af0$@net> <4CB8EDB2.5000906@beau.org> Message-ID: Woops forgot to reply to all so it went to the list :P I think your post here: https://lists.secondlife.com/pipermail/opensource-dev/2010-September/003167.html Was a very good one explaining what the advantages could be. A true xml format like that would be easy to read and easy to parse. Of course its not a line by line conversation like you read in the viewer but it is in an order and all information would be provided in an easy to read format provided the viewer exports the xml with proper line endings and tab spacing :P Did a jira ever get posted about that? On Fri, Oct 15, 2010 at 8:32 PM, Ricky wrote: > I'd have to say that future proof and archival safe are two separate > qualities. ?Logs might need to be archived, but 90% (guessing) of the > content is fluff only useful for a couple of months to a year at the > most. ?However, the tools that read them (such as converters / > archivers) have a much longer lifespan. ?If you do want 50+ year > archival quality, then use a trivial exporter to convert to the ASCII > format of your choice when you run your archival process and send it > to paper punch tape. ?(I'm not being insulting here: paper punch tape > is THE most long-lived digital format I've ever met.) > > As to the stylesheet: I propose that it be installed with the viewer > and be located in the same folder as the logs. ?This way it can be > archived along with the files by your favorite archival/storage tools. > > And viewing the file is likewise not an issue. ?Every modern computer > already has a browser installed and in use. ?And if you still needed > to read the log from a GUI-less computer, the logs are still ASCII. > The tags surrounding the data are just helpful to the computer. ?This > isn't a binary format we are discussing; it's a formatted text file. > Formatted in a way that makes it easier for a computer to read while > still being useful to the humans involved. > > On Fri, Oct 15, 2010 at 5:11 PM, Jamey Fletcher wrote: >> Marc Adored wrote: >> >>> Download a stylesheet? The file would contain a link directly to the >>> stylesheet and would be automatically loaded. Also I'm not sure about >>> your operating system but I'm pretty sure the file extension already >>> opens in your default browser and once the stylesheet is specified it >>> will look just like a plain text log file just loaded in your browser >>> through the same process and opening a text file. The only fear here >>> is change and the unknown. It's not going to be any harder to read the >>> logs just different. Sorry like Ricky said its more future proof and >>> thats all there is too it the only mistake was not setting this up >>> earlier so the change didn't frighten so many people >> >> Let's see... ?Future Proof. >> >> Program to read and process a text file - anywhere from a few hundred >> bytes, to a small OS-wannabe like emacs. ?Program to process LLSD and >> display it - several hundred K minimum, oh, and *REQUIRED* network >> connection live so the referenced DTD can be retrieved - more like a >> program that is ALREADY being considered an OS-replacement, such as >> Internet Explorer, Mozilla, Safari, or Chrome, each several dozen megabytes. >> >> Ok, so let's look at a project that's *GOT* a nice long history already >> (some 30+ years) and is *VERY* interested in future-proofing. ?Minor >> project, really, called Project Gutenberg. ?Here's what *they* have to >> say on the subject: >> http://www.gutenberg.org/wiki/Gutenberg:General_FAQ#G.17._Why_is_Project_Gutenberg_so_set_on_using_Plain_Vanilla_ASCII.3F >> >> When you really, really, *REALLY* want it to be readable - ASCII >> plaintext is the way to go. >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/OpenSource-Dev >> Please read the policies before posting to keep unmoderated posting privileges >> > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting privileges > From bryon at slearth.com Fri Oct 15 17:49:51 2010 From: bryon at slearth.com (Bryon Ruxton) Date: Fri, 15 Oct 2010 17:49:51 -0700 Subject: [opensource-dev] O.O Display name code DROP! In-Reply-To: Message-ID: Hi Leyla, Glad to keep the current text format if there are no real goals for changing it. For one that would have broken the integrity of current log files. On that point I would actually love to know if the filenames of IM logs is to eventually change, from say First Last.txt to first.last.txt (for legacy names). Please consider that one carefully, as that would require us to change all file names of existing logs to avoid new sets of files being created on top existing log files, when starting using that viewer's code, should it change. i.e. Being able to keep the IM history for each Agent or Group name in one unique file is important here. And Sythos?s suggestion would be correct for separate IM logs specifically, for avoiding redundant repetition of the username unnecessarily for each line. On 10/15/10 4:23 PM, "Leyla Linden" wrote: > Hi All, > > The chat log format change wasinitially done so we could easily add? > more information in the?chat logs. ?Now that the display name can? > change it's nice to have?more?data like an agent_id that can be hooked > up to inspectors. > > But seeing as how many people rely on easily readable text chat logs,? > we're going to revert them back to text files. ?The only difference is that? > they'll include both display names and usernames, much like Rob > Nelson suggested.? > > - Leyla > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting privileges -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101015/eaef4a2f/attachment.htm From kf6kjg at gmail.com Fri Oct 15 18:10:57 2010 From: kf6kjg at gmail.com (Ricky) Date: Fri, 15 Oct 2010 18:10:57 -0700 Subject: [opensource-dev] Fwd: O.O Display name code DROP! In-Reply-To: References: <000001cb6c04$2650ce50$72f26af0$@net> <4CB8EDB2.5000906@beau.org> Message-ID: NO I completely forgot to post a JIRA entry on that! Just got it in though: https://jira.secondlife.com/browse/VWR-23451 Any useful counter-arguments/expansions can go there. :) Ricky Cron Stardust On Fri, Oct 15, 2010 at 5:46 PM, Marc Adored wrote: > Woops forgot to reply to all so it went to the list :P > > > I think your post here: > > https://lists.secondlife.com/pipermail/opensource-dev/2010-September/003167.html > > Was a very good one explaining what the advantages could be. A true > xml format like that would be easy to read and easy to parse. Of > course its not a line by line conversation like you read in the viewer > but it is in an order and all information would be provided in an easy > to read format provided the viewer exports the xml with proper line > endings and tab spacing :P > > Did a jira ever get posted about that? > > On Fri, Oct 15, 2010 at 8:32 PM, Ricky wrote: >> I'd have to say that future proof and archival safe are two separate >> qualities. ?Logs might need to be archived, but 90% (guessing) of the >> content is fluff only useful for a couple of months to a year at the >> most. ?However, the tools that read them (such as converters / >> archivers) have a much longer lifespan. ?If you do want 50+ year >> archival quality, then use a trivial exporter to convert to the ASCII >> format of your choice when you run your archival process and send it >> to paper punch tape. ?(I'm not being insulting here: paper punch tape >> is THE most long-lived digital format I've ever met.) >> >> As to the stylesheet: I propose that it be installed with the viewer >> and be located in the same folder as the logs. ?This way it can be >> archived along with the files by your favorite archival/storage tools. >> >> And viewing the file is likewise not an issue. ?Every modern computer >> already has a browser installed and in use. ?And if you still needed >> to read the log from a GUI-less computer, the logs are still ASCII. >> The tags surrounding the data are just helpful to the computer. ?This >> isn't a binary format we are discussing; it's a formatted text file. >> Formatted in a way that makes it easier for a computer to read while >> still being useful to the humans involved. >> >> On Fri, Oct 15, 2010 at 5:11 PM, Jamey Fletcher wrote: >>> Marc Adored wrote: >>> >>>> Download a stylesheet? The file would contain a link directly to the >>>> stylesheet and would be automatically loaded. Also I'm not sure about >>>> your operating system but I'm pretty sure the file extension already >>>> opens in your default browser and once the stylesheet is specified it >>>> will look just like a plain text log file just loaded in your browser >>>> through the same process and opening a text file. The only fear here >>>> is change and the unknown. It's not going to be any harder to read the >>>> logs just different. Sorry like Ricky said its more future proof and >>>> thats all there is too it the only mistake was not setting this up >>>> earlier so the change didn't frighten so many people >>> >>> Let's see... ?Future Proof. >>> >>> Program to read and process a text file - anywhere from a few hundred >>> bytes, to a small OS-wannabe like emacs. ?Program to process LLSD and >>> display it - several hundred K minimum, oh, and *REQUIRED* network >>> connection live so the referenced DTD can be retrieved - more like a >>> program that is ALREADY being considered an OS-replacement, such as >>> Internet Explorer, Mozilla, Safari, or Chrome, each several dozen megabytes. >>> >>> Ok, so let's look at a project that's *GOT* a nice long history already >>> (some 30+ years) and is *VERY* interested in future-proofing. ?Minor >>> project, really, called Project Gutenberg. ?Here's what *they* have to >>> say on the subject: >>> http://www.gutenberg.org/wiki/Gutenberg:General_FAQ#G.17._Why_is_Project_Gutenberg_so_set_on_using_Plain_Vanilla_ASCII.3F >>> >>> When you really, really, *REALLY* want it to be readable - ASCII >>> plaintext is the way to go. >>> _______________________________________________ >>> Policies and (un)subscribe information available here: >>> http://wiki.secondlife.com/wiki/OpenSource-Dev >>> Please read the policies before posting to keep unmoderated posting privileges >>> >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/OpenSource-Dev >> Please read the policies before posting to keep unmoderated posting privileges >> > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting privileges > From nexisentertainment at gmail.com Fri Oct 15 20:55:21 2010 From: nexisentertainment at gmail.com (Rob Nelson) Date: Fri, 15 Oct 2010 20:55:21 -0700 Subject: [opensource-dev] O.O Display name code DROP! In-Reply-To: References: <000001cb6c04$2650ce50$72f26af0$@net> <4CB8D946.2050809@meadowlakearts.com> Message-ID: <4CB92229.3070307@gmail.com> I CONTRIBUTED SOMETHING ;_; Rob On 10/15/2010 4:23 PM, Leyla Linden wrote: > The only difference is that > they'll include both display names and usernames, much like Rob > Nelson suggested. > > - Leyla > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting privileges -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101015/6b17062b/attachment.htm From marc at inworlddesigns.com Fri Oct 15 22:10:50 2010 From: marc at inworlddesigns.com (Marc Adored) Date: Sat, 16 Oct 2010 01:10:50 -0400 Subject: [opensource-dev] Viewer 2 beta crash osx Message-ID: Ok so I have been having the crashing problem on login every since viewer 2. I can still login fine with the viewer 1.x viewers but none of the viewer 2 viewers login fully they just crash. I have tried clearing cache and deleting everything blah blah even reinstalled osx and same thing. Here is a video of when it crashes http://www.youtube.com/watch?v=nw9I1W6ugvI What else can I provide to help figure out what it might be? From angel_of_crimson at hotmail.com Fri Oct 15 23:11:01 2010 From: angel_of_crimson at hotmail.com (Erin Mallory) Date: Sat, 16 Oct 2010 02:11:01 -0400 Subject: [opensource-dev] Viewer 2 beta crash osx In-Reply-To: References: Message-ID: I would attach that video, any logs you can collect, and possibly a screen of anything odd in your inventory to a jira. I might also attach some logs of a successful login in with 1.x I knwo the codebases are different, but theres always the slim hope that by comparing the two something might become obvious. beyond that i dunno? > Date: Sat, 16 Oct 2010 01:10:50 -0400 > From: marc at inworlddesigns.com > To: opensource-dev at lists.secondlife.com > Subject: [opensource-dev] Viewer 2 beta crash osx > > Ok so I have been having the crashing problem on login every since > viewer 2. I can still login fine with the viewer 1.x viewers but none > of the viewer 2 viewers login fully they just crash. I have tried > clearing cache and deleting everything blah blah even reinstalled osx > and same thing. Here is a video of when it crashes > > http://www.youtube.com/watch?v=nw9I1W6ugvI > > What else can I provide to help figure out what it might be? > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting privileges -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101016/ff041e09/attachment.htm From marc at inworlddesigns.com Fri Oct 15 23:16:29 2010 From: marc at inworlddesigns.com (Marc Adored) Date: Sat, 16 Oct 2010 02:16:29 -0400 Subject: [opensource-dev] Viewer 2 beta crash osx In-Reply-To: References: Message-ID: Well I think I just narrowed it down. I turned off streaming media and I am able to login now. I guess viewer 2 auto loads the media even if it isn't set to auto play? I should have thought of it earlier and I don't know why I didn't. I can't play streaming media in the v1.x viewers either but they don't try to play the streams auto or something because I don't have to disable it on them I just can't play them. On Sat, Oct 16, 2010 at 2:11 AM, Erin Mallory wrote: > I would attach that video, any logs you can collect, and possibly a screen > of anything odd in your inventory to a jira.? I might also attach some logs > of a successful login in with 1.x? I knwo the codebases are different, but > theres always the slim hope that by comparing the two something might become > obvious.? beyond that i dunno? > >> Date: Sat, 16 Oct 2010 01:10:50 -0400 >> From: marc at inworlddesigns.com >> To: opensource-dev at lists.secondlife.com >> Subject: [opensource-dev] Viewer 2 beta crash osx >> >> Ok so I have been having the crashing problem on login every since >> viewer 2. I can still login fine with the viewer 1.x viewers but none >> of the viewer 2 viewers login fully they just crash. I have tried >> clearing cache and deleting everything blah blah even reinstalled osx >> and same thing. Here is a video of when it crashes >> >> http://www.youtube.com/watch?v=nw9I1W6ugvI >> >> What else can I provide to help figure out what it might be? >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/OpenSource-Dev >> Please read the policies before posting to keep unmoderated posting >> privileges > From Lance.Corrimal at eregion.de Sat Oct 16 02:09:48 2010 From: Lance.Corrimal at eregion.de (Lance Corrimal) Date: Sat, 16 Oct 2010 11:09:48 +0200 Subject: [opensource-dev] latest viewer-development checkout doesn't build... Message-ID: <201010161109.48155.Lance.Corrimal@eregion.de> ... it tries do download some of the prebuild libraries by scp which of course dies at LL's external firewall... any reason for this? bye, LC From sllists at boroon.dasgupta.ch Sat Oct 16 04:11:52 2010 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Sat, 16 Oct 2010 13:11:52 +0200 Subject: [opensource-dev] What is the expected behaviour when double clicking floater edges? (VWR-23452) Message-ID: <4CB98878.5090008@boroon.dasgupta.ch> Personally, I didn't expect double clicking the edges or corners of a resizeable floater to do anything at all, so I didn't do it until it happened to me yesterday by accident. I was surprised to see the floater change size and figured I must have been moving the mouse, thus dragging the edge. But when trying again, noticed this also happened when the mouse pointer wasn't moving at all, so I filed bug VWR-23452 . Further investigation revealed that the double clicked edge became aligned to the edges of other floaters or the edge of the Second Life window. While unexpected to me, this might be useful for arranging floaters and doesn't look like a bug but rather like a deliberately coded feature. Is it? I didn't know about this yet, but it looks like this was already present in 1.23. Cheers, Boroondas -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101016/3b63743f/attachment.htm From wolfpup67 at earthlink.net Sat Oct 16 05:16:02 2010 From: wolfpup67 at earthlink.net (WolfPup Lowenhar) Date: Sat, 16 Oct 2010 08:16:02 -0400 Subject: [opensource-dev] latest viewer-development checkout doesn't build... In-Reply-To: <201010161109.48155.Lance.Corrimal@eregion.de> References: <201010161109.48155.Lance.Corrimal@eregion.de> Message-ID: <001201cb6d2b$e65cbdd0$b3163970$@net> Actually there is a jira on this issue generated last night. https://jira.secondlife.com/browse/VWR-23455 From: opensource-dev-bounces at lists.secondlife.com [mailto:opensource-dev-bounces at lists.secondlife.com] On Behalf Of Lance Corrimal Sent: Saturday, October 16, 2010 5:10 AM To: opensource-dev at lists.secondlife.com Subject: [opensource-dev] latest viewer-development checkout doesn't build... ... it tries do download some of the prebuild libraries by scp which of course dies at LL's external firewall... any reason for this? bye, LC _______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges _____ No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1136 / Virus Database: 422/3199 - Release Date: 10/15/10 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101016/23d976a0/attachment.htm From oz at lindenlab.com Sat Oct 16 08:01:38 2010 From: oz at lindenlab.com (Oz Linden (Scott Lawrence)) Date: Sat, 16 Oct 2010 11:01:38 -0400 Subject: [opensource-dev] Project-MESH viewer In-Reply-To: References: Message-ID: <4CB9BE52.6070401@lindenlab.com> On 2010-10-15 18:00, Trilo Byte wrote: > But on the flipside, the Project MESH viewer has working shadows for nVidia GPU's on Mac (never happened before on any known config), and anti-aliasing's fixed. If we could get that bit out of the mesh viewer and into the 2.2 pipeline, we'd really be in great shape IMO. The AA fix is in the 2.2 pipeline (I did that merge) ... not sure about the other (since I don't know which change that was). From oz at lindenlab.com Sat Oct 16 08:19:37 2010 From: oz at lindenlab.com (Oz Linden (Scott Lawrence)) Date: Sat, 16 Oct 2010 11:19:37 -0400 Subject: [opensource-dev] O.O Display name code DROP! In-Reply-To: <4CB8E248.60001@boroon.dasgupta.ch> References: <000001cb6c04$2650ce50$72f26af0$@net> <4CB7D905.60706@beau.org> <000001cb6c25$7787f660$6697e320$@net> <4CB8E248.60001@boroon.dasgupta.ch> Message-ID: <4CB9C289.5000503@lindenlab.com> On 2010-10-15 19:22, Boroondas Gupte wrote: > On 10/16/2010 12:59 AM, SuezanneC Baskerville wrote: >> What happened to that jira issue? It appears to have been moved to >> SEC or something like that. > It has been moved to DN-179 > . (I guess "DN" stands for > "display names".) Why we can't see that jira project although display > names has been on Aditi for some while now, I don't know. The fact that it became invisible when assigned to the development team is a configuration error. I've put in a request for a fix, and expect that it will be done in the next few days (the person who normally makes such changes returns from vacation on Monday, I think). As Boroondas noted, the part of that issue that broke the creation of personal chat logs has been fixed and integrated into the current development viewer. The issue of whether or not to create .txt and/or .llsd logs is being tracked separately: https://jira.secondlife.com/browse/VWR-22940 Please don't add comments to that issue that amount to just agreeing with or disagreeing with one or another of the points already made there (this list is an ok place for that, if you feel you must do it somewhere). The Jira tracker isn't a forum, and comments like that don't add much value. The various points of view are pretty well represented there now. This issue won't be dropped... watch this thread and the issue for updates. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101016/92e75848/attachment.htm From missannotoole at yahoo.com Sat Oct 16 09:24:43 2010 From: missannotoole at yahoo.com (Ann Otoole) Date: Sat, 16 Oct 2010 09:24:43 -0700 (PDT) Subject: [opensource-dev] Project-MESH viewer In-Reply-To: <4CB9BE52.6070401@lindenlab.com> References: <4CB9BE52.6070401@lindenlab.com> Message-ID: <440748.46271.qm@web120511.mail.ne1.yahoo.com> Are you planning to enable shine on prims with lighting/shadows on or is full lighting effects disable shininess something we need to accept as permanent and texture around? (Note that lighting in Kirstens also disables shine) ________________________________ From: Oz Linden (Scott Lawrence) To: opensource-dev at lists.secondlife.com Sent: Sat, October 16, 2010 11:01:38 AM Subject: Re: [opensource-dev] Project-MESH viewer On 2010-10-15 18:00, Trilo Byte wrote: > But on the flipside, the Project MESH viewer has working shadows for nVidia >GPU's on Mac (never happened before on any known config), and anti-aliasing's >fixed. If we could get that bit out of the mesh viewer and into the 2.2 >pipeline, we'd really be in great shape IMO. The AA fix is in the 2.2 pipeline (I did that merge) ... not sure about the other (since I don't know which change that was). _______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101016/3ab051c2/attachment.htm From geenz at geenzo.com Sat Oct 16 09:41:48 2010 From: geenz at geenzo.com (Geenz Spad) Date: Sat, 16 Oct 2010 11:41:48 -0500 Subject: [opensource-dev] Project-MESH viewer In-Reply-To: <440748.46271.qm@web120511.mail.ne1.yahoo.com> References: <4CB9BE52.6070401@lindenlab.com> <440748.46271.qm@web120511.mail.ne1.yahoo.com> Message-ID: Shiny does work with the deferred renderer (or Lighting and Shadows as it's now called in the Mesh viewer). It's simply handled differently; it reflects light in the form of what's known as specular reflectance, instead of reflecting the sky environment (at one point it reflected both around 2008 and 2009). Different shiny settings effects the overall brightness and distribution of the specular exponent. On Sat, Oct 16, 2010 at 11:24 AM, Ann Otoole wrote: > Are you planning to enable shine on prims with lighting/shadows on or is > full lighting effects disable shininess something we need to accept as > permanent and texture around? (Note that lighting in Kirstens also disables > shine) > > ------------------------------ > *From:* Oz Linden (Scott Lawrence) > *To:* opensource-dev at lists.secondlife.com > *Sent:* Sat, October 16, 2010 11:01:38 AM > *Subject:* Re: [opensource-dev] Project-MESH viewer > > On 2010-10-15 18:00, Trilo Byte wrote: > > But on the flipside, the Project MESH viewer has working shadows for > nVidia GPU's on Mac (never happened before on any known config), and > anti-aliasing's fixed. If we could get that bit out of the mesh viewer and > into the 2.2 pipeline, we'd really be in great shape IMO. > > The AA fix is in the 2.2 pipeline (I did that merge) ... not sure about > the other (since I don't know which change that was). > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting > privileges > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101016/0c082ba5/attachment-0001.htm From secret.argent at gmail.com Sat Oct 16 12:17:59 2010 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sat, 16 Oct 2010 14:17:59 -0500 Subject: [opensource-dev] O.O Display name code DROP! In-Reply-To: References: <000001cb6c04$2650ce50$72f26af0$@net> Message-ID: <3B7CD934-CFEF-49AC-A25E-AE9A15E32FA2@gmail.com> On 2010-10-15, at 16:36, Ricky wrote: > All that's needed is a linked XSL stylesheet to make it just as easy > to read as the text files were. 1. It's not in XML, it's in notation format. This is a good thing, because... 2. LLSD is really badly designed from the point of XSL transformations. Instead of having the type and value as attributes, they have them in completely separate tags, so the ordering of tags matters so you have to use streaming XSLT. 3. There are more tools people use for browsing and reading log files than text editors. If you can't grep it, for example, it's junk. From missannotoole at yahoo.com Sat Oct 16 12:27:09 2010 From: missannotoole at yahoo.com (Ann Otoole) Date: Sat, 16 Oct 2010 12:27:09 -0700 (PDT) Subject: [opensource-dev] Project-MESH viewer In-Reply-To: References: <4CB9BE52.6070401@lindenlab.com> <440748.46271.qm@web120511.mail.ne1.yahoo.com> Message-ID: <970815.70232.qm@web120505.mail.ne1.yahoo.com> There is no shine at all when lighting/shadows is enabled. Sorry. None whatsoever. Full shine black is just flat black. Full shine white is just flat white. Full shine textures are just the textures. It is completely broken. And this, in turn, "breaks content" that was sold with the expectation it was shiny. On the bright side it might make people rely less on shine to hide things that cannot be textured properly (sculpts generated from a wad of prims) or to cover a lack of decent texturing. I'm already discontinuing use of shine as much as possible because of this content breaker. And yes we will need the other aspects of texturing for mesh as soon as possible if possible. Wet looking skin with bulging veins on Cthu'lhu would indeed be awesome. But shine was broken once with windlight. Now it has been obliterated with deferred rendering. I don't expect to live long enough to see real time true reflectivity in Second Life. Like latex that actually reflects. Would be nice but there are miles and miles to go to get that gpu capability for real time translated to opengl and then farther to go to show up in Second life. Or third life or whatever this concept is called at that point 50 years from now if there is still an internet (doubtful) and civilians are allowed to be in possession of computers beyond what they are "chipped" with. ________________________________ From: Geenz Spad To: opensource-dev at lists.secondlife.com Sent: Sat, October 16, 2010 12:41:48 PM Subject: Re: [opensource-dev] Project-MESH viewer Shiny does work with the deferred renderer (or Lighting and Shadows as it's now called in the Mesh viewer). It's simply handled differently; it reflects light in the form of what's known as specular reflectance, instead of reflecting the sky environment (at one point it reflected both around 2008 and 2009). Different shiny settings effects the overall brightness and distribution of the specular exponent. On Sat, Oct 16, 2010 at 11:24 AM, Ann Otoole wrote: Are you planning to enable shine on prims with lighting/shadows on or is full lighting effects disable shininess something we need to accept as permanent and texture around? (Note that lighting in Kirstens also disables shine) > > > ________________________________ From: Oz Linden (Scott Lawrence) >To: opensource-dev at lists.secondlife.com >Sent: Sat, October 16, 2010 11:01:38 AM >Subject: Re: [opensource-dev] Project-MESH viewer > > > On 2010-10-15 18:00, Trilo Byte wrote: >> But on the flipside, the Project MESH viewer has working shadows for nVidia >>GPU's on Mac (never happened before on any known config), and anti-aliasing's >>fixed. If we could get that bit out of the mesh viewer and into the 2.2 >>pipeline, we'd really be in great shape IMO. > >The AA fix is in the 2.2 pipeline (I did that merge) ... not sure about >the other (since I don't know which change that was). > >_______________________________________________ >Policies and (un)subscribe information available here: >http://wiki.secondlife.com/wiki/OpenSource-Dev >Please read the policies before posting to keep unmoderated posting privileges > > >_______________________________________________ >Policies and (un)subscribe information available here: >http://wiki.secondlife.com/wiki/OpenSource-Dev >Please read the policies before posting to keep unmoderated posting privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101016/96ddb677/attachment.htm From nexiim at gmail.com Sat Oct 16 12:48:37 2010 From: nexiim at gmail.com (Nexii Malthus) Date: Sat, 16 Oct 2010 20:48:37 +0100 Subject: [opensource-dev] What is the expected behaviour when double clicking floater edges? (VWR-23452) In-Reply-To: <4CB98878.5090008@boroon.dasgupta.ch> References: <4CB98878.5090008@boroon.dasgupta.ch> Message-ID: Oh, wow, that's cool. Never knew that too. - Nexii On Sat, Oct 16, 2010 at 12:11 PM, Boroondas Gupte < sllists at boroon.dasgupta.ch> wrote: > Personally, I didn't expect double clicking the edges or corners of a > resizeable floater to do anything at all, so I didn't do it until it > happened to me yesterday by accident. I was surprised to see the floater > change size and figured I must have been moving the mouse, thus dragging the > edge. But when trying again, noticed this also happened when the mouse > pointer wasn't moving at all, so I filed bug VWR-23452 > . > > Further investigation revealed that the double clicked edge became aligned > to the edges of other floaters or the edge of the Second Life window. While > unexpected to me, this might be useful for arranging floaters and doesn't > look like a bug but rather like a deliberately coded feature. > > Is it? I didn't know about this yet, but it looks like this was already > present in 1.23. > > Cheers, > Boroondas > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101016/130d08e4/attachment.htm From leliel.mirihi at gmail.com Sat Oct 16 14:58:48 2010 From: leliel.mirihi at gmail.com (leliel) Date: Sat, 16 Oct 2010 14:58:48 -0700 Subject: [opensource-dev] Project-MESH viewer In-Reply-To: <970815.70232.qm@web120505.mail.ne1.yahoo.com> References: <4CB9BE52.6070401@lindenlab.com> <440748.46271.qm@web120511.mail.ne1.yahoo.com> <970815.70232.qm@web120505.mail.ne1.yahoo.com> Message-ID: On Sat, Oct 16, 2010 at 12:27 PM, Ann Otoole wrote: > There is no shine at all when lighting/shadows is enabled. Sorry. None > whatsoever. Full shine black is just flat black. Full shine white is just > flat white. Full shine textures are just the textures. It is completely > broken. And this, in turn, "breaks content" that was sold with the > expectation it was shiny. Shiny enables specular highlights, not reflections. Physically the two are the same thing, but in raster based graphics they are separate. That weird metallic colored blob we had before was just a quick and dirt hack, with lighting & shadows enabled the viewer will do true specular highlights which depend on the angle of the light and the camera in order to be visible. > I don't expect to live long enough to see real time true reflectivity in > Second Life. Like latex that actually reflects. Would be nice but there are > miles and miles to go to get that gpu capability for real time translated to > opengl and then farther to go to show up in Second life. Or third life or > whatever this concept is called at that point 50 years from now if there is > still an internet (doubtful) and civilians are allowed to be in possession > of computers beyond what they are "chipped" with. OpenGL has been able to do reflections for a long time now, it's just a very demanding process since you have to render the scene from the point of view of each reflective object in addition to the camera's view point. Older games would cheat and just render one cube map for the whole scene and use it for all reflections, but that may not be acceptable in sl. Once again, the dynamic, user made content in sl is what holds us back. There is no way to limit the number of reflective objects in view and using more then a hand full would bring all but the current top of the line cards to their knees. What we need is fine grain control over how objects are rendered instead of just everything in the view plain been drawn in full (LOD'd) detail. The shadow maps & GI code does this with a distance based cut off. Having a distance / size cut off for reflections would help a lot with any over use of them. Adding in full impostors for all objects would be even better. Over all I'd say the viewer needs to start doing some serious resource management if we ever want to have a draw distance measured in kilometers. From angel_of_crimson at hotmail.com Sat Oct 16 15:01:14 2010 From: angel_of_crimson at hotmail.com (Erin Mallory) Date: Sat, 16 Oct 2010 18:01:14 -0400 Subject: [opensource-dev] question Message-ID: Why is it 2.0 seems to autodecline inventory for most people if they crash or get logged out before they can accept the inventory? this is really annoying. is there a way to change that somewhere? Im sick of throwing away money and losing gifts because stuff doesn't get delivered. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101016/3cdb1c67/attachment.htm From secret.argent at gmail.com Sat Oct 16 15:27:37 2010 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sat, 16 Oct 2010 17:27:37 -0500 Subject: [opensource-dev] Reflections in SL. Re: Project-MESH viewer In-Reply-To: References: <4CB9BE52.6070401@lindenlab.com> <440748.46271.qm@web120511.mail.ne1.yahoo.com> <970815.70232.qm@web120505.mail.ne1.yahoo.com> Message-ID: <63A17F4C-7BC0-4977-A741-D6852C0EE073@gmail.com> On 2010-10-16, at 16:58, leliel wrote: > OpenGL has been able to do reflections for a long time now, it's just > a very demanding process since you have to render the scene from the > point of view of each reflective object in addition to the camera's > view point. Older games would cheat and just render one cube map for > the whole scene and use it for all reflections, but that may not be > acceptable in sl. Sure it is. They had it working on First Look 1.13.57575. The source code for which is in the old viewer archives. It was nerfed some (the cube map was reduced to about 32x32) but the RenderDynamicReflections option was still there right up to Windlight. People LOVED it, particularly in rave-style clubs. From suezanne at gmail.com Sat Oct 16 15:31:25 2010 From: suezanne at gmail.com (SuezanneC Baskerville) Date: Sat, 16 Oct 2010 17:31:25 -0500 Subject: [opensource-dev] Reflections in SL. Re: Project-MESH viewer In-Reply-To: <63A17F4C-7BC0-4977-A741-D6852C0EE073@gmail.com> References: <4CB9BE52.6070401@lindenlab.com> <440748.46271.qm@web120511.mail.ne1.yahoo.com> <970815.70232.qm@web120505.mail.ne1.yahoo.com> <63A17F4C-7BC0-4977-A741-D6852C0EE073@gmail.com> Message-ID: I'd be quite content with mirror surfaces that only, for example, reflected avatars. I think people would enjoy mirrors no matter how much restriction had to be placed on them to keep them from hogging excess resources. On Sat, Oct 16, 2010 at 5:27 PM, Argent Stonecutter wrote: > On 2010-10-16, at 16:58, leliel wrote: > > OpenGL has been able to do reflections for a long time now, it's just > > a very demanding process since you have to render the scene from the > > point of view of each reflective object in addition to the camera's > > view point. Older games would cheat and just render one cube map for > > the whole scene and use it for all reflections, but that may not be > > acceptable in sl. > > Sure it is. They had it working on First Look 1.13.57575. The source code > for which is in the old viewer archives. It was nerfed some (the cube map > was reduced to about 32x32) but the RenderDynamicReflections option was > still there right up to Windlight. People LOVED it, particularly in > rave-style clubs. > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting > privileges > -- v i r t u a l w o r l d e n t h u s i a s t -- http://www.google.com/profiles/s u e z a n n e -- -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101016/79918eee/attachment.htm From secret.argent at gmail.com Sat Oct 16 16:00:57 2010 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sat, 16 Oct 2010 18:00:57 -0500 Subject: [opensource-dev] Reflections in SL. Re: Project-MESH viewer In-Reply-To: References: <4CB9BE52.6070401@lindenlab.com> <440748.46271.qm@web120511.mail.ne1.yahoo.com> <970815.70232.qm@web120505.mail.ne1.yahoo.com> <63A17F4C-7BC0-4977-A741-D6852C0EE073@gmail.com> Message-ID: <83F49DDA-A0A3-4F44-882C-4DD6D042A743@gmail.com> On 2010-10-16, at 17:31, SuezanneC Baskerville wrote: > I'd be quite content with mirror surfaces that only, for example, reflected avatars. They had a lot better than that... http://www.sluniverse.com/pics/pic.aspx?id=139865 From leliel.mirihi at gmail.com Sat Oct 16 16:04:52 2010 From: leliel.mirihi at gmail.com (leliel) Date: Sat, 16 Oct 2010 16:04:52 -0700 Subject: [opensource-dev] Reflections in SL. Re: Project-MESH viewer In-Reply-To: References: <4CB9BE52.6070401@lindenlab.com> <440748.46271.qm@web120511.mail.ne1.yahoo.com> <970815.70232.qm@web120505.mail.ne1.yahoo.com> <63A17F4C-7BC0-4977-A741-D6852C0EE073@gmail.com> Message-ID: On Sat, Oct 16, 2010 at 3:31 PM, SuezanneC Baskerville wrote: > I'd be quite content with mirror surfaces that only, for example, reflected > avatars. > > I think people would enjoy mirrors no matter how much restriction had to be > placed on them to keep them from hogging excess resources. I suppose low quality reflections are better then nothing. But I think LL has their hands full with other things at the moment. If we want them we'll have to code them up ourselves. Maybe adding in DoF, HDR, and volumetric lighting while we're at it. ^.^ From dave at meadowlakearts.com Sat Oct 16 16:18:51 2010 From: dave at meadowlakearts.com (Dave Booth) Date: Sat, 16 Oct 2010 18:18:51 -0500 Subject: [opensource-dev] Reflections in SL. Re: Project-MESH viewer In-Reply-To: <83F49DDA-A0A3-4F44-882C-4DD6D042A743@gmail.com> References: <4CB9BE52.6070401@lindenlab.com> <440748.46271.qm@web120511.mail.ne1.yahoo.com> <970815.70232.qm@web120505.mail.ne1.yahoo.com> <63A17F4C-7BC0-4977-A741-D6852C0EE073@gmail.com> <83F49DDA-A0A3-4F44-882C-4DD6D042A743@gmail.com> Message-ID: <4CBA32DA.6030207@meadowlakearts.com> On 10/16/2010 18:00, Argent Stonecutter wrote: > On 2010-10-16, at 17:31, SuezanneC Baskerville wrote: >> I'd be quite content with mirror surfaces that only, for example, reflected avatars. > They had a lot better than that... > > http://www.sluniverse.com/pics/pic.aspx?id=139865 > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting privileges > Yeah, windlight added so much but we lost a lot at the same time - Thats one of the biggies we lost. That single image of Argents has more "reality" to it than we'll ever see in a current viewer no matter how far we tweak our windlight settings or how carefully we create and texture our meshes.... Just what was it about introducing windlight that required the nerfing of that kind of awesome anyway? From oz at lindenlab.com Sat Oct 16 16:45:55 2010 From: oz at lindenlab.com (Oz Linden (Scott Lawrence)) Date: Sat, 16 Oct 2010 19:45:55 -0400 Subject: [opensource-dev] Reflections in SL. Re: Project-MESH viewer In-Reply-To: References: <4CB9BE52.6070401@lindenlab.com> <440748.46271.qm@web120511.mail.ne1.yahoo.com> <970815.70232.qm@web120505.mail.ne1.yahoo.com> <63A17F4C-7BC0-4977-A741-D6852C0EE073@gmail.com> Message-ID: <4CBA3933.6030306@lindenlab.com> On 2010-10-16 19:04, leliel wrote: > On Sat, Oct 16, 2010 at 3:31 PM, SuezanneC Baskerville > wrote: >> I'd be quite content with mirror surfaces that only, for example, reflected >> avatars. >> >> I think people would enjoy mirrors no matter how much restriction had to be >> placed on them to keep them from hogging excess resources. > I suppose low quality reflections are better then nothing. But I think > LL has their hands full with other things at the moment. If we want > them we'll have to code them up ourselves. Now there's a sentiment I can get behind ! :-) From leliel.mirihi at gmail.com Sat Oct 16 17:02:34 2010 From: leliel.mirihi at gmail.com (leliel) Date: Sat, 16 Oct 2010 17:02:34 -0700 Subject: [opensource-dev] Reflections in SL. Re: Project-MESH viewer In-Reply-To: <4CBA3933.6030306@lindenlab.com> References: <4CB9BE52.6070401@lindenlab.com> <440748.46271.qm@web120511.mail.ne1.yahoo.com> <970815.70232.qm@web120505.mail.ne1.yahoo.com> <63A17F4C-7BC0-4977-A741-D6852C0EE073@gmail.com> <4CBA3933.6030306@lindenlab.com> Message-ID: On Sat, Oct 16, 2010 at 4:45 PM, Oz Linden (Scott Lawrence) wrote: > ?On 2010-10-16 19:04, leliel wrote: >> On Sat, Oct 16, 2010 at 3:31 PM, SuezanneC Baskerville >> ?wrote: >>> I'd be quite content with mirror surfaces that only, for example, reflected >>> avatars. >>> >>> I think people would enjoy mirrors no matter how much restriction had to be >>> placed on them to keep them from hogging excess resources. >> I suppose low quality reflections are better then nothing. But I think >> LL has their hands full with other things at the moment. If we want >> them we'll have to code them up ourselves. > > Now there's a sentiment I can get behind ! ? :-) Make it so people don't have to jump through hoops to build the viewer and patches may start coming in more frequently. O.o From jay_reynolds_freeman at mac.com Sat Oct 16 17:14:42 2010 From: jay_reynolds_freeman at mac.com (Jay Reynolds Freeman) Date: Sat, 16 Oct 2010 17:14:42 -0700 Subject: [opensource-dev] Reflections in SL. Re: Project-MESH viewer In-Reply-To: <4CBA3933.6030306@lindenlab.com> References: <4CB9BE52.6070401@lindenlab.com> <440748.46271.qm@web120511.mail.ne1.yahoo.com> <970815.70232.qm@web120505.mail.ne1.yahoo.com> <63A17F4C-7BC0-4977-A741-D6852C0EE073@gmail.com> <4CBA3933.6030306@lindenlab.com> Message-ID: Now, wouldn't the vampire folks be delighted with a mirror that had a "don't reflect my avatar" option ... -- Jay Reynolds Freeman --------------------- Jay_Reynolds_Freeman at mac.com http://web.mac.com/jay_reynolds_freeman (personal web site) On Oct 16, 2010, at 4:45 PM, Oz Linden (Scott Lawrence) wrote: On 2010-10-16 19:04, leliel wrote: > On Sat, Oct 16, 2010 at 3:31 PM, SuezanneC Baskerville > wrote: >> I'd be quite content with mirror surfaces that only, for example, reflected >> avatars. >> >> I think people would enjoy mirrors no matter how much restriction had to be >> placed on them to keep them from hogging excess resources. > I suppose low quality reflections are better then nothing. But I think > LL has their hands full with other things at the moment. If we want > them we'll have to code them up ourselves. Now there's a sentiment I can get behind ! :-) _______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges From suezanne at gmail.com Sat Oct 16 18:10:24 2010 From: suezanne at gmail.com (SuezanneC Baskerville) Date: Sat, 16 Oct 2010 20:10:24 -0500 Subject: [opensource-dev] Property Lines gone mad in Development Viewer 2.2.1 (212233) Message-ID: Anyone seen any problems with the property lines in the latest Development Viewer? https://jira.secondlife.com/browse/VWR-23464 https://jira.secondlife.com/secure/attachment/44866/SL+-+property+lines+gone+mad+450.jpg Property lines in Development Viewer 2.2.1 (212233) are behaving abnormally. They are not where property lines should be. These lines do appear and disappear depending on the Show Property Lines setting. First: I turned on Show Property Lines. Bug Observed: red lines, not on property boundaries, appear, more than there should be, extending into the air in some cases. -- v i r t u a l w o r l d e n t h u s i a s t -- http://www.google.com/profiles/s u e z a n n e -- -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101016/d930dc8f/attachment.htm From geenz at geenzo.com Sat Oct 16 19:49:38 2010 From: geenz at geenzo.com (Jonathan Goodman) Date: Sat, 16 Oct 2010 21:49:38 -0500 Subject: [opensource-dev] Project-MESH viewer In-Reply-To: References: <4CB9BE52.6070401@lindenlab.com> <440748.46271.qm@web120511.mail.ne1.yahoo.com> <970815.70232.qm@web120505.mail.ne1.yahoo.com> Message-ID: <4CBA6442.2010800@geenzo.com> Case in point... http://www.flickr.com/photos/50275732 at N04/5079086973/ The floors have Shiny set to medium. leliel wrote: > On Sat, Oct 16, 2010 at 12:27 PM, Ann Otoole wrote: >> There is no shine at all when lighting/shadows is enabled. Sorry. None >> whatsoever. Full shine black is just flat black. Full shine white is just >> flat white. Full shine textures are just the textures. It is completely >> broken. And this, in turn, "breaks content" that was sold with the >> expectation it was shiny. > > Shiny enables specular highlights, not reflections. Physically the two > are the same thing, but in raster based graphics they are separate. > That weird metallic colored blob we had before was just a quick and > dirt hack, with lighting& shadows enabled the viewer will do true > specular highlights which depend on the angle of the light and the > camera in order to be visible. > >> I don't expect to live long enough to see real time true reflectivity in >> Second Life. Like latex that actually reflects. Would be nice but there are >> miles and miles to go to get that gpu capability for real time translated to >> opengl and then farther to go to show up in Second life. Or third life or >> whatever this concept is called at that point 50 years from now if there is >> still an internet (doubtful) and civilians are allowed to be in possession >> of computers beyond what they are "chipped" with. > > OpenGL has been able to do reflections for a long time now, it's just > a very demanding process since you have to render the scene from the > point of view of each reflective object in addition to the camera's > view point. Older games would cheat and just render one cube map for > the whole scene and use it for all reflections, but that may not be > acceptable in sl. > > Once again, the dynamic, user made content in sl is what holds us > back. There is no way to limit the number of reflective objects in > view and using more then a hand full would bring all but the current > top of the line cards to their knees. What we need is fine grain > control over how objects are rendered instead of just everything in > the view plain been drawn in full (LOD'd) detail. The shadow maps& GI > code does this with a distance based cut off. Having a distance / size > cut off for reflections would help a lot with any over use of them. > Adding in full impostors for all objects would be even better. > > Over all I'd say the viewer needs to start doing some serious resource > management if we ever want to have a draw distance measured in > kilometers. > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting privileges -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101016/317bb52f/attachment-0001.htm From djshag at hotmail.com Sat Oct 16 20:03:00 2010 From: djshag at hotmail.com (Patnad Babii) Date: Sat, 16 Oct 2010 23:03:00 -0400 Subject: [opensource-dev] Project-MESH viewer In-Reply-To: <4CBA6442.2010800@geenzo.com> References: <4CB9BE52.6070401@lindenlab.com> <440748.46271.qm@web120511.mail.ne1.yahoo.com> <970815.70232.qm@web120505.mail.ne1.yahoo.com> <4CBA6442.2010800@geenzo.com> Message-ID: ?Or third life orwhatever this concept is called at that point 50 years from now if there isstill an internet (doubtful) and civilians are allowed to be in possessionof computers beyond what they are "chipped" with.? We have to all stand together for our rights of free speech, creativity and don?t let them implant you chips then we all should be fine in 50 years from now. Just think about it there a general awakening that is happening, people start to realize that the gov has too much power, we just need to take it back. From: Jonathan Goodman Sent: Saturday, October 16, 2010 10:49 PM To: opensource-dev at lists.secondlife.com Subject: Re: [opensource-dev] Project-MESH viewer Case in point... http://www.flickr.com/photos/50275732 at N04/5079086973/ The floors have Shiny set to medium. leliel wrote: On Sat, Oct 16, 2010 at 12:27 PM, Ann Otoole mailto:missannotoole at yahoo.com wrote: There is no shine at all when lighting/shadows is enabled. Sorry. None whatsoever. Full shine black is just flat black. Full shine white is just flat white. Full shine textures are just the textures. It is completely broken. And this, in turn, "breaks content" that was sold with the expectation it was shiny. Shiny enables specular highlights, not reflections. Physically the two are the same thing, but in raster based graphics they are separate. That weird metallic colored blob we had before was just a quick and dirt hack, with lighting & shadows enabled the viewer will do true specular highlights which depend on the angle of the light and the camera in order to be visible. I don't expect to live long enough to see real time true reflectivity in Second Life. Like latex that actually reflects. Would be nice but there are miles and miles to go to get that gpu capability for real time translated to opengl and then farther to go to show up in Second life. Or third life or whatever this concept is called at that point 50 years from now if there is still an internet (doubtful) and civilians are allowed to be in possession of computers beyond what they are "chipped" with. OpenGL has been able to do reflections for a long time now, it's just a very demanding process since you have to render the scene from the point of view of each reflective object in addition to the camera's view point. Older games would cheat and just render one cube map for the whole scene and use it for all reflections, but that may not be acceptable in sl. Once again, the dynamic, user made content in sl is what holds us back. There is no way to limit the number of reflective objects in view and using more then a hand full would bring all but the current top of the line cards to their knees. What we need is fine grain control over how objects are rendered instead of just everything in the view plain been drawn in full (LOD'd) detail. The shadow maps & GI code does this with a distance based cut off. Having a distance / size cut off for reflections would help a lot with any over use of them. Adding in full impostors for all objects would be even better. Over all I'd say the viewer needs to start doing some serious resource management if we ever want to have a draw distance measured in kilometers. _______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges -------------------------------------------------------------------------------- _______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101016/da51a923/attachment.htm From tateru at taterunino.net Sat Oct 16 20:09:59 2010 From: tateru at taterunino.net (Tateru Nino) Date: Sun, 17 Oct 2010 14:09:59 +1100 Subject: [opensource-dev] Reflections in SL. Re: Project-MESH viewer In-Reply-To: <4CBA3933.6030306@lindenlab.com> References: <4CB9BE52.6070401@lindenlab.com> <440748.46271.qm@web120511.mail.ne1.yahoo.com> <970815.70232.qm@web120505.mail.ne1.yahoo.com> <63A17F4C-7BC0-4977-A741-D6852C0EE073@gmail.com> <4CBA3933.6030306@lindenlab.com> Message-ID: <4CBA6907.5050708@taterunino.net> On 17/10/2010 10:45 AM, Oz Linden (Scott Lawrence) wrote: > On 2010-10-16 19:04, leliel wrote: >> On Sat, Oct 16, 2010 at 3:31 PM, SuezanneC Baskerville >> wrote: >>> I'd be quite content with mirror surfaces that only, for example, reflected >>> avatars. >>> >>> I think people would enjoy mirrors no matter how much restriction had to be >>> placed on them to keep them from hogging excess resources. >> I suppose low quality reflections are better then nothing. But I think >> LL has their hands full with other things at the moment. If we want >> them we'll have to code them up ourselves. > Now there's a sentiment I can get behind ! :-) > A year or two ago, I was treated to a demonstration of working mirrors in SL. It was an override of Shiny, and I had to install a custom shader file to my SL viewer installation directory. As far as I know, the project died because - in order to work - it needs a bit or a texture property flag from Linden lab on the server-side, otherwise it is "surprising or unexpected" functionality that potentially breaks content, and thus is a no-no under the TPVP. -- Tateru Nino http://dwellonit.taterunino.net/ From kf6kjg at gmail.com Sat Oct 16 20:57:52 2010 From: kf6kjg at gmail.com (Ricky) Date: Sat, 16 Oct 2010 20:57:52 -0700 Subject: [opensource-dev] O.O Display name code DROP! In-Reply-To: <3B7CD934-CFEF-49AC-A25E-AE9A15E32FA2@gmail.com> References: <000001cb6c04$2650ce50$72f26af0$@net> <3B7CD934-CFEF-49AC-A25E-AE9A15E32FA2@gmail.com> Message-ID: I agree, the XML notation is far from perfect (see some of my posts last year about the subject,) however I consider it better than either text or this almost-JSON notation for a variety of reasons, all laid out in https://jira.secondlife.com/browse/VWR-23451 for ease of reference. Assuming that the order of fields is fixed, a fair assumption as LLSD requires it I believe, then the XSLT isn't so bad, and a prototype has already been made. On the subject of using other standard tools, such as grep/sed/awk/etc., I fully agree. This is why I'd fight against any binary or compressed format. However, no such proposal has been made. All formats so far don't have any less information in any less accessible of a format than the text files. If the file doesn't have proper line breaks, then that's another issue. Albeit one fairly easily resolved by passing it through sed with the right expression. Ricky Cron Stardust On Sat, Oct 16, 2010 at 12:17 PM, Argent Stonecutter wrote: > > On 2010-10-15, at 16:36, Ricky wrote: >> All that's needed is a linked XSL stylesheet to make it just as easy >> to read as the text files were. > > 1. It's not in XML, it's in notation format. This is a good thing, because... > 2. LLSD is really badly designed from the point of XSL transformations. Instead of having the type and value as attributes, they have them in completely separate tags, so the ordering of tags matters so you have to use streaming XSLT. > 3. There are more tools people use for browsing and reading log files than text editors. If you can't grep it, for example, it's junk. From Lance.Corrimal at eregion.de Sun Oct 17 01:34:47 2010 From: Lance.Corrimal at eregion.de (Lance Corrimal) Date: Sun, 17 Oct 2010 10:34:47 +0200 Subject: [opensource-dev] O.O Display name code DROP! In-Reply-To: References: <000001cb6c04$2650ce50$72f26af0$@net> <3B7CD934-CFEF-49AC-A25E-AE9A15E32FA2@gmail.com> Message-ID: <201010171034.47758.Lance.Corrimal@eregion.de> Am Sonntag 17 Oktober 2010 schrieb Ricky: > I agree, the XML notation is far from perfect (see some of my posts > last year about the subject,) however I consider it better than > either text or this almost-JSON notation for a variety of reasons, > all laid out in https://jira.secondlife.com/browse/VWR-23451 for > ease of reference. > > Assuming that the order of fields is fixed, a fair assumption as > LLSD requires it I believe, then the XSLT isn't so bad, and a > prototype has already been made. > > On the subject of using other standard tools, such as > grep/sed/awk/etc., I fully agree. This is why I'd fight against > any binary or compressed format. However, no such proposal has > been made. Guys, keep one thing in mind: the average user has no inclination of "processing" the logfiles with anything. The average user, at best, will open the logfiles in notepad to look at them, and to find stuff like "what was the name of that place that i heard about at that or that date". The average user runs windows, where tools such as grep/awk/sed are not exactly common, either. bye, LC From marc at inworlddesigns.com Sun Oct 17 01:39:51 2010 From: marc at inworlddesigns.com (Marc Adored) Date: Sun, 17 Oct 2010 04:39:51 -0400 Subject: [opensource-dev] O.O Display name code DROP! In-Reply-To: <201010171034.47758.Lance.Corrimal@eregion.de> References: <000001cb6c04$2650ce50$72f26af0$@net> <3B7CD934-CFEF-49AC-A25E-AE9A15E32FA2@gmail.com> <201010171034.47758.Lance.Corrimal@eregion.de> Message-ID: Lance check the jira if the file ext is changes to xml it will automatically open in IE,Firefox,Chrome,Whatever Browser they have as default and it will display styled to look just like the plain text old versions only underneath it will contain much more information. Those stylesheets can also be highly dynamic to include/exclude whatever information about each line of log with javascript On Sun, Oct 17, 2010 at 4:34 AM, Lance Corrimal wrote: > Am Sonntag 17 Oktober 2010 schrieb Ricky: >> I agree, the XML notation is far from perfect (see some of my posts >> last year about the subject,) however I consider it better than >> either text or this almost-JSON notation for a variety of reasons, >> all laid out in https://jira.secondlife.com/browse/VWR-23451 for >> ease of reference. >> >> Assuming that the order of fields is fixed, a fair assumption as >> LLSD requires it I believe, then the XSLT isn't so bad, and a >> prototype has already been made. >> >> On the subject of using other standard tools, such as >> grep/sed/awk/etc., I fully agree. ?This is why I'd fight against >> any binary or compressed format. ?However, no such proposal has >> been made. > > Guys, keep one thing in mind: > > the average user has no inclination of "processing" the logfiles with > anything. > > The average user, at best, will open the logfiles in notepad to look > at them, and to find stuff like "what was the name of that place that > i heard about at that or that date". > > The average user runs windows, where tools such as grep/awk/sed are > not exactly common, either. > > > bye, > LC > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting privileges > From nexisentertainment at gmail.com Sun Oct 17 01:54:59 2010 From: nexisentertainment at gmail.com (Rob Nelson) Date: Sun, 17 Oct 2010 01:54:59 -0700 Subject: [opensource-dev] O.O Display name code DROP! In-Reply-To: <201010171034.47758.Lance.Corrimal@eregion.de> References: <000001cb6c04$2650ce50$72f26af0$@net> <3B7CD934-CFEF-49AC-A25E-AE9A15E32FA2@gmail.com> <201010171034.47758.Lance.Corrimal@eregion.de> Message-ID: <4CBAB9E3.9060108@gmail.com> This. Say Joe Everyguy wants to look for a rather hot conversation he had with what he assumes was a very attractive-looking female yesterday. With a text logfile, he just has to open the log in notepad and CTRL+F for "VerySexy Lady". Since that was her display name at the time, it's included along with her real name (trucker.bob) and is therefore searchable. (Since the realname is included as well, it is also searchable.) With what I've seen of the LLSD log, he'd open it up, be presented with what he thinks is gibberish, and then close it. If he tried to search for "VerySexy Lady", he wouldn't find anything because only the UUID is included. If the desire is to come up with a more easily parsed format for OH records, add an option to log to a non-LLSD XML file that is more easily transformed using XSL. Something like: STUFF What was said What was said What was said Rob On 10/17/2010 1:34 AM, Lance Corrimal wrote: > Am Sonntag 17 Oktober 2010 schrieb Ricky: >> I agree, the XML notation is far from perfect (see some of my posts >> last year about the subject,) however I consider it better than >> either text or this almost-JSON notation for a variety of reasons, >> all laid out in https://jira.secondlife.com/browse/VWR-23451 for >> ease of reference. >> >> Assuming that the order of fields is fixed, a fair assumption as >> LLSD requires it I believe, then the XSLT isn't so bad, and a >> prototype has already been made. >> >> On the subject of using other standard tools, such as >> grep/sed/awk/etc., I fully agree. This is why I'd fight against >> any binary or compressed format. However, no such proposal has >> been made. > Guys, keep one thing in mind: > > the average user has no inclination of "processing" the logfiles with > anything. > > The average user, at best, will open the logfiles in notepad to look > at them, and to find stuff like "what was the name of that place that > i heard about at that or that date". > > The average user runs windows, where tools such as grep/awk/sed are > not exactly common, either. > > > bye, > LC > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting privileges > From oz at lindenlab.com Sun Oct 17 05:01:33 2010 From: oz at lindenlab.com (Oz Linden (Scott Lawrence)) Date: Sun, 17 Oct 2010 08:01:33 -0400 Subject: [opensource-dev] Reflections in SL. Re: Project-MESH viewer In-Reply-To: References: <4CB9BE52.6070401@lindenlab.com> <440748.46271.qm@web120511.mail.ne1.yahoo.com> <970815.70232.qm@web120505.mail.ne1.yahoo.com> <63A17F4C-7BC0-4977-A741-D6852C0EE073@gmail.com> <4CBA3933.6030306@lindenlab.com> Message-ID: <4CBAE59D.4070107@lindenlab.com> On 2010-10-16 20:02, leliel wrote: > Make it so people don't have to jump through hoops to build the viewer > and patches may start coming in more frequently. O.o Oddly, that's exactly what I'm working on... From oz at lindenlab.com Sun Oct 17 05:09:33 2010 From: oz at lindenlab.com (Oz Linden (Scott Lawrence)) Date: Sun, 17 Oct 2010 08:09:33 -0400 Subject: [opensource-dev] offered items are lost by viewer crashes In-Reply-To: References: Message-ID: <4CBAE77D.40700@lindenlab.com> [hint: use a more descriptive subject line when posting] On 2010-10-16 18:01, Erin Mallory wrote: > Why is it 2.0 seems to autodecline inventory for most people if they > crash or get logged out before they can accept the inventory? this is > really annoying. is there a way to change that somewhere? Im sick of > throwing away money and losing gifts because stuff doesn't get delivered. There is an issue on this.... https://jira.secondlife.com/browse/VWR-7245 This certainly seems like something we should get onto someones backlog.... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101017/b67d5de0/attachment.htm From I_really_needed_a_new_mailbox at gmx.de Sun Oct 17 05:23:16 2010 From: I_really_needed_a_new_mailbox at gmx.de (Zai Lynch) Date: Sun, 17 Oct 2010 14:23:16 +0200 Subject: [opensource-dev] offered items are lost by viewer crashes In-Reply-To: <4CBAE77D.40700@lindenlab.com> References: <4CBAE77D.40700@lindenlab.com> Message-ID: > > There is an issue on this.... > > https://jira.secondlife.com/browse/VWR-7245 > Actually, that's an issue filed against 1.20 in 2008 (and not updated since). AFAIK, the problem with friendship-offers described in the issue is still persistent, however, the mentioned problem from the mail in regards of inventory offers shouldn't be. I think that V2 should actually make it less likely to loose inventory, as inventory is auto-accepted and not pending until approval anymore. -- @ZaiLynch -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101017/ebda0f56/attachment.htm From secret.argent at gmail.com Sun Oct 17 08:20:19 2010 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sun, 17 Oct 2010 10:20:19 -0500 Subject: [opensource-dev] Reflections in SL. Re: Project-MESH viewer In-Reply-To: <4CBA32DA.6030207@meadowlakearts.com> References: <4CB9BE52.6070401@lindenlab.com> <440748.46271.qm@web120511.mail.ne1.yahoo.com> <970815.70232.qm@web120505.mail.ne1.yahoo.com> <63A17F4C-7BC0-4977-A741-D6852C0EE073@gmail.com> <83F49DDA-A0A3-4F44-882C-4DD6D042A743@gmail.com> <4CBA32DA.6030207@meadowlakearts.com> Message-ID: <34273972-261A-40D0-87ED-51CD0E51E56C@gmail.com> On 2010-10-16, at 18:18, Dave Booth wrote: > Yeah, windlight added so much but we lost a lot at the same time - Thats > one of the biggies we lost. That single image of Argents has more > "reality" to it than we'll ever see in a current viewer no matter how > far we tweak our windlight settings or how carefully we create and > texture our meshes.... Just what was it about introducing windlight that > required the nerfing of that kind of awesome anyway? To be fair,that level of awesome had been nerfed long before windlight. Later versions reduced the cube map from the 1024x1024 you see there to 32x32. Trying to get that resolution with a later version of the viewer was likely to crash you right off. From secret.argent at gmail.com Sun Oct 17 08:22:36 2010 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sun, 17 Oct 2010 10:22:36 -0500 Subject: [opensource-dev] Reflections in SL. Re: Project-MESH viewer In-Reply-To: <4CBA6907.5050708@taterunino.net> References: <4CB9BE52.6070401@lindenlab.com> <440748.46271.qm@web120511.mail.ne1.yahoo.com> <970815.70232.qm@web120505.mail.ne1.yahoo.com> <63A17F4C-7BC0-4977-A741-D6852C0EE073@gmail.com> <4CBA3933.6030306@lindenlab.com> <4CBA6907.5050708@taterunino.net> Message-ID: <57AF6E3B-AD6C-4752-A5F2-98FCA6FCAEF9@gmail.com> On 2010-10-16, at 22:09, Tateru Nino wrote: > A year or two ago, I was treated to a demonstration of working mirrors > in SL. It was an override of Shiny, and I had to install a custom shader > file to my SL viewer installation directory. As far as I know, the > project died because - in order to work - it needs a bit or a texture > property flag from Linden lab on the server-side, otherwise it is > "surprising or unexpected" functionality that potentially breaks > content, and thus is a no-no under the TPVP. The original mirror project back in SL 1.13 was an override of shiny too. It was optional. So long as it's optional I don't see why it would violate the TPVP. From secret.argent at gmail.com Sun Oct 17 08:25:51 2010 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sun, 17 Oct 2010 10:25:51 -0500 Subject: [opensource-dev] O.O Display name code DROP! In-Reply-To: References: <000001cb6c04$2650ce50$72f26af0$@net> <3B7CD934-CFEF-49AC-A25E-AE9A15E32FA2@gmail.com> Message-ID: <5232FBA4-492F-41C9-9CE4-683CF5631C85@gmail.com> On 2010-10-16, at 22:57, Ricky wrote: > Assuming that the order of fields is fixed, a fair assumption as LLSD > requires it I believe, then the XSLT isn't so bad, and a prototype has > already been made. That depends on the details of the XSL transform tool. Streaming tools preserve order but there's no requirement to do so. > On the subject of using other standard tools, such as > grep/sed/awk/etc., I fully agree. This is why I'd fight against any > binary or compressed format. LLSD XML format breaks non-XML tools almost as badly as binary would. It's completely unacceptable. The notation format, with a line break between messages, is the only format proposed so far that should even be considered. From geenz at geenzo.com Sun Oct 17 08:26:37 2010 From: geenz at geenzo.com (Geenz Spad) Date: Sun, 17 Oct 2010 10:26:37 -0500 Subject: [opensource-dev] Reflections in SL. Re: Project-MESH viewer In-Reply-To: <57AF6E3B-AD6C-4752-A5F2-98FCA6FCAEF9@gmail.com> References: <4CB9BE52.6070401@lindenlab.com> <440748.46271.qm@web120511.mail.ne1.yahoo.com> <970815.70232.qm@web120505.mail.ne1.yahoo.com> <63A17F4C-7BC0-4977-A741-D6852C0EE073@gmail.com> <4CBA3933.6030306@lindenlab.com> <4CBA6907.5050708@taterunino.net> <57AF6E3B-AD6C-4752-A5F2-98FCA6FCAEF9@gmail.com> Message-ID: <4CBB15AD.4080007@geenzo.com> I could see the new "Shiny" (in reality, they should be called specular highlights) breaking content that relied on the darkening properties of the classic Shiny shader. Which is why I've modified the deferred shiny shader to "darken" the object's diffuse shading depending on the shiny value, without resorting to silly environment maps to make things "Shiny". http://www.flickr.com/photos/50275732 at N04/5088357599/in/photostream/ Argent Stonecutter wrote: > On 2010-10-16, at 22:09, Tateru Nino wrote: >> A year or two ago, I was treated to a demonstration of working mirrors >> in SL. It was an override of Shiny, and I had to install a custom shader >> file to my SL viewer installation directory. As far as I know, the >> project died because - in order to work - it needs a bit or a texture >> property flag from Linden lab on the server-side, otherwise it is >> "surprising or unexpected" functionality that potentially breaks >> content, and thus is a no-no under the TPVP. > > The original mirror project back in SL 1.13 was an override of shiny too. > > It was optional. > > So long as it's optional I don't see why it would violate the TPVP. > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting privileges -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101017/2897d9ff/attachment.htm From kf6kjg at gmail.com Sun Oct 17 08:34:33 2010 From: kf6kjg at gmail.com (Ricky) Date: Sun, 17 Oct 2010 08:34:33 -0700 Subject: [opensource-dev] O.O Display name code DROP! In-Reply-To: <4CBAB9E3.9060108@gmail.com> References: <000001cb6c04$2650ce50$72f26af0$@net> <3B7CD934-CFEF-49AC-A25E-AE9A15E32FA2@gmail.com> <201010171034.47758.Lance.Corrimal@eregion.de> <4CBAB9E3.9060108@gmail.com> Message-ID: Typically Joe Everyguy, from my experience as an IT professional, will just double-click (or single click depending on settings) the file from Windows Explorer/Mac Finder. (Us *NIX folks have our own way of looking at things...) if the file has the .xml extension it will work correctly. If we do find that a fair portion of users go the long route of Open notepad, go to file>open, browse to the file, select, and click the Open button, then we can simply leave a SGML comment up near the top that says something to the effect of: Ricky Crons Stardust On Sun, Oct 17, 2010 at 1:54 AM, Rob Nelson wrote: > ?This. ?Say Joe Everyguy wants to look for a rather hot conversation he > had with what he assumes was a very attractive-looking female > yesterday. ?With a text logfile, he just has to open the log in notepad > and CTRL+F for "VerySexy Lady". ?Since that was her display name at the > time, it's included along with her real name (trucker.bob) and is > therefore searchable. (Since the realname is included as well, it is > also searchable.) > > With what I've seen of the LLSD log, he'd open it up, be presented with > what he thinks is gibberish, and then close it. ?If he tried to search > for "VerySexy Lady", he wouldn't find anything because only the UUID is > included. > > If the desire is to come up with a more easily parsed format for OH > records, add an option to log to a non-LLSD XML file that is more easily > transformed using XSL. ?Something like: > > > location="secondlife:///..." timestamp="Date/Time">STUFF > timestamp="Date/Time">What was said > timestamp="Date/Time">What was said > timestamp="Date/Time">What was said > > > Rob > > On 10/17/2010 1:34 AM, Lance Corrimal wrote: >> Am Sonntag 17 Oktober 2010 schrieb Ricky: >>> I agree, the XML notation is far from perfect (see some of my posts >>> last year about the subject,) however I consider it better than >>> either text or this almost-JSON notation for a variety of reasons, >>> all laid out in https://jira.secondlife.com/browse/VWR-23451 for >>> ease of reference. >>> >>> Assuming that the order of fields is fixed, a fair assumption as >>> LLSD requires it I believe, then the XSLT isn't so bad, and a >>> prototype has already been made. >>> >>> On the subject of using other standard tools, such as >>> grep/sed/awk/etc., I fully agree. ?This is why I'd fight against >>> any binary or compressed format. ?However, no such proposal has >>> been made. >> Guys, keep one thing in mind: >> >> the average user has no inclination of "processing" the logfiles with >> anything. >> >> The average user, at best, will open the logfiles in notepad to look >> at them, and to find stuff like "what was the name of that place that >> i heard about at that or that date". >> >> The average user runs windows, where tools such as grep/awk/sed are >> not exactly common, either. >> >> >> bye, >> LC >> >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/OpenSource-Dev >> Please read the policies before posting to keep unmoderated posting privileges >> > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting privileges > From sllists at boroon.dasgupta.ch Sun Oct 17 11:14:18 2010 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Sun, 17 Oct 2010 20:14:18 +0200 Subject: [opensource-dev] VWR-23459: Viewer compiled against Boost-1.42 crashes when certain command line options are given Message-ID: <4CBB3CFA.4040703@boroon.dasgupta.ch> Hi all The current viewer-development source can be compiled against boost 1.42 but will crash when command line options are passed that are the prefix of another command line option. Aleric had fixed the that problem in Snowglobe (both, 1 and 2) at SNOW-626 . The same fix still seems to work for viewer-development, so I've daggified the changeset and filed VWR-23459 to track integration into viewer-development. (I didn't want to move SNOW-626, because it's a subtask of SNOW-623 No Boost 1.42 compatibility and the other subtasks of that don't apply to viewer-development.) http://bitbucket.org/boroondas/vwr-23459 Please review and test: * Does not change behavior for non-standalone * Does not change behavior for standalone with boost 1.41 or earlier. * Fixes the crashes for standalone with boost 1.42. (See VWR-23459 for repro.) Cheers, Boroondas -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101017/c3005bd7/attachment.htm From miss_c_27 at yahoo.com Sun Oct 17 12:40:54 2010 From: miss_c_27 at yahoo.com (miss c) Date: Sun, 17 Oct 2010 12:40:54 -0700 (PDT) Subject: [opensource-dev] Again About Scripting Issues specifically KELLY LINDEN Message-ID: <160144.68114.qm@web82108.mail.mud.yahoo.com> Running more and more tests about the lag in regions it seems more and more to point towards this issue more than anything else. https://jira.secondlife.com/browse/SVC-3895 with over 900 votes "Rezzing Mono scripted object cripples sim FPS" Now Kelly mentioned on this post it had something to do with the mono secuirty.dll. When I did a search for Security.dll and mono in google it pulled up mailing lists and posts where this is actually a mono bug coming from their software. The portion I gather is it was fixed or improved in newer versions. I looked all over the wiki but I could not find what version of mono we are using. Does anyone know? I know this is more of a server function, but we have discussed at length for adding more tools to the viewer to monitor lag, but this would really make a huge difference if we just needed to update the mono version on the servers. If there is a server mailing list, please point me in that direction. Thanks Miss Fighting the lag every hour on the hour -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101017/c059a160/attachment.htm From miss_c_27 at yahoo.com Sun Oct 17 13:00:23 2010 From: miss_c_27 at yahoo.com (miss c) Date: Sun, 17 Oct 2010 13:00:23 -0700 (PDT) Subject: [opensource-dev] Again About Scripting Issues specifically KELLY LINDEN In-Reply-To: References: <160144.68114.qm@web82108.mail.mud.yahoo.com> Message-ID: <520717.89116.qm@web82106.mail.mud.yahoo.com> Well here is the official mono bug list, over 1900 issues, I am sure one of those issues points to our problem if its not just a new version needed. Anyway, hope this helps Official Mono Novell Bugs ________________________________ From: Stickman To: miss c Sent: Sun, October 17, 2010 2:54:31 PM Subject: Re: [opensource-dev] Again About Scripting Issues specifically KELLY LINDEN They attempted a fix a few server versions ago. But it did horrible things to some scripts, causing them to crash in totally new and horrible ways. The fix was pulled out and set to be put back in when everything else was updated so it could be included without causing horrors. I'm sure someone can give you better specifics. I'm not in an area to look up the information. I do know that the server with the actual fix is coming "soon." Which is good, because it felt impossibly far off when it got taken back out. Stickman On Oct 17, 2010 12:41 PM, "miss c" wrote: > > >Running more and more tests about the lag in regions it seems more and more to >point towards this issue more than anything else. > >https://jira.secondlife.com/browse/SVC-3895 with over 900 votes >"Rezzing Mono scripted object cripples sim FPS" > >Now Kelly mentioned on this post it had something to do with the mono >secuirty.dll. > >When I did a search for Security.dll and mono in google it pulled up mailing >lists and posts where this is actually a mono bug coming from their software. >The portion I gather is it was fixed or improved in newer versions. I looked >all over the wiki but I could not find what version of mono we are using. Does >anyone know? > >I know this is more of a server function, but we have discussed at length for >adding more tools to the viewer to monitor lag, but this would really make a >huge difference if we just needed to update the mono version on the servers. > >If there is a server mailing list, please point me in that direction. > >Thanks > >Miss >Fighting the lag every hour on the hour > > > >_______________________________________________ >Policies and (un)subscribe information available here: >http://wiki.secondlife.com/wiki/OpenSource-Dev >Please read the policies before posting to keep unmoderated posting privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101017/3f5bbb9d/attachment.htm From nexisentertainment at gmail.com Sun Oct 17 13:01:21 2010 From: nexisentertainment at gmail.com (Rob Nelson) Date: Sun, 17 Oct 2010 13:01:21 -0700 Subject: [opensource-dev] Again About Scripting Issues specifically KELLY LINDEN In-Reply-To: <160144.68114.qm@web82108.mail.mud.yahoo.com> References: <160144.68114.qm@web82108.mail.mud.yahoo.com> Message-ID: <4CBB5611.8010906@gmail.com> There is no "we". The servers are proprietary; LL does this on their own dime and time. From what I gather, there's a little bit of work going towards that direction, but the mesh changes have their attention for now, like car keys dangled in front of a toddler. Rob On 10/17/2010 12:40 PM, miss c wrote: > Running more and more tests about the lag in regions it seems more and > more to point towards this issue more than anything else. > > https://jira.secondlife.com/browse/SVC-3895 with over 900 votes > "Rezzing Mono scripted object cripples sim FPS" > > > Now Kelly mentioned on this post it had something to do with the mono > secuirty.dll. > > When I did a search for Security.dll and mono in google it pulled up > mailing lists and posts where this is actually a mono bug coming from > their software. The portion I gather is it was fixed or improved in > newer versions. I looked all over the wiki but I could not find what > version of mono we are using. Does anyone know? > > I know this is more of a server function, but we have discussed at > length for adding more tools to the viewer to monitor lag, but this > would really make a huge difference if we just needed to update the > mono version on the servers. > > If there is a server mailing list, please point me in that direction. > > Thanks > > Miss > Fighting the lag every hour on the hour > > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting privileges -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101017/da69a6de/attachment.htm From kelly at lindenlab.com Sun Oct 17 13:17:40 2010 From: kelly at lindenlab.com (Kelly Linden) Date: Sun, 17 Oct 2010 13:17:40 -0700 Subject: [opensource-dev] Again About Scripting Issues specifically KELLY LINDEN In-Reply-To: <4CBB5611.8010906@gmail.com> References: <160144.68114.qm@web82108.mail.mud.yahoo.com> <4CBB5611.8010906@gmail.com> Message-ID: Currently we use Mono 1.2.6. Moving to Mono 2.6.7 is in testing right now. It requires a two stage process to deploy so there will be a 'mono2 aware' version that has to be deployed before we get all the new version stuff. We are currently working on tracking down hopefully one of the last issues, a "System.InvalidCastException" that we sometimes get when loading scripts. Unfortunately it is a bit difficult to repro, and is a bit more subtle than the name would make it seem relating to loading scripts. I regularly give updates on this project and any other scripting work I am aware of at my office hours: http://wiki.secondlife.com/wiki/User:Kelly_Linden#Office_Hours . The only other relevant list is probably secondlifescripters at lists.secondlife.com. - Kelly On Sun, Oct 17, 2010 at 1:01 PM, Rob Nelson wrote: > There is no "we". The servers are proprietary; LL does this on their own > dime and time. From what I gather, there's a little bit of work going > towards that direction, but the mesh changes have their attention for now, > like car keys dangled in front of a toddler. > > Rob > > > On 10/17/2010 12:40 PM, miss c wrote: > > Running more and more tests about the lag in regions it seems more and > more to point towards this issue more than anything else. > > https://jira.secondlife.com/browse/SVC-3895 with over 900 votes > "Rezzing Mono scripted object cripples sim FPS" > > Now Kelly mentioned on this post it had something to do with the mono > secuirty.dll. > > When I did a search for Security.dll and mono in google it pulled up > mailing lists and posts where this is actually a mono bug coming from their > software. The portion I gather is it was fixed or improved in newer > versions. I looked all over the wiki but I could not find what version of > mono we are using. Does anyone know? > > I know this is more of a server function, but we have discussed at length > for adding more tools to the viewer to monitor lag, but this would really > make a huge difference if we just needed to update the mono version on the > servers. > > If there is a server mailing list, please point me in that direction. > > Thanks > > Miss > Fighting the lag every hour on the hour > > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting privileges > > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101017/2324265c/attachment-0001.htm From miss_c_27 at yahoo.com Sun Oct 17 14:00:46 2010 From: miss_c_27 at yahoo.com (miss c) Date: Sun, 17 Oct 2010 14:00:46 -0700 (PDT) Subject: [opensource-dev] Again About Scripting Issues specifically KELLY LINDEN In-Reply-To: References: <160144.68114.qm@web82108.mail.mud.yahoo.com> <4CBB5611.8010906@gmail.com> Message-ID: <324147.63773.qm@web82107.mail.mud.yahoo.com> That bug is listed here with 2.6.7 https://bugzilla.novell.com/show_bug.cgi?id=581679 Quote "I have tested this in Mono 2.6.7 and it is still occurring. it occurs when a second input field in added to a form (via the forms "+" button and happens at save." In version 2.8 it looks like they redid how mono works so it doesn't look like this is a bug that's going to be fixed. http://www.mono-project.com/Release_Notes_Mono_2.6.7 http://www.mono-project.com/Release_Notes_Mono_2.8 If this isn't fixable you may have to go to 2.8, but with as much as it looks like they changes, wow, a whole lot of work. But thank you for answering, can't wait to see it deployed. Miss ________________________________ From: Kelly Linden To: Rob Nelson Cc: opensource-dev at lists.secondlife.com Sent: Sun, October 17, 2010 3:17:40 PM Subject: Re: [opensource-dev] Again About Scripting Issues specifically KELLY LINDEN Currently we use Mono 1.2.6. Moving to Mono 2.6.7 is in testing right now. It requires a two stage process to deploy so there will be a 'mono2 aware' version that has to be deployed before we get all the new version stuff. We are currently working on tracking down hopefully one of the last issues, a "System.InvalidCastException" that we sometimes get when loading scripts. Unfortunately it is a bit difficult to repro, and is a bit more subtle than the name would make it seem relating to loading scripts. I regularly give updates on this project and any other scripting work I am aware of at my office hours: http://wiki.secondlife.com/wiki/User:Kelly_Linden#Office_Hours . The only other relevant list is probably secondlifescripters at lists.secondlife.com. - Kelly On Sun, Oct 17, 2010 at 1:01 PM, Rob Nelson wrote: There is no "we". The servers are proprietary; LL does this on their own dime and time. From what I gather, there's a little bit of work going towards that direction, but the mesh changes have their attention for now, like car keys dangled in front of a toddler. > >Rob > > >On 10/17/2010 12:40 PM, miss c wrote: >Running more and more tests about the lag in regions it seems more and >more to point towards this issue more than anything else. >> >>https://jira.secondlife.com/browse/SVC-3895 with over 900 votes >>"Rezzing Mono scripted object cripples sim FPS" >> >>Now Kelly mentioned on this post it had something to do with the >>mono secuirty.dll. >> >>When I did a search for Security.dll and mono in google it pulled up >>mailing lists and posts where this is actually a mono bug coming >>from their software. The portion I gather is it was fixed or >>improved in newer versions. I looked all over the wiki but I could >>not find what version of mono we are using. Does anyone know? >> >>I know this is more of a server function, but we have discussed at >>length for adding more tools to the viewer to monitor lag, but this >>would really make a huge difference if we just needed to update the >>mono version on the servers. >> >>If there is a server mailing list, please point me in that >>direction. >> >>Thanks >> >>Miss >>Fighting the lag every hour on the hour >> >> >> >> _______________________________________________ Policies and (un)subscribe >>information available here: >> >>http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before >>posting to keep unmoderated posting privileges >_______________________________________________ >Policies and (un)subscribe information available here: >http://wiki.secondlife.com/wiki/OpenSource-Dev >Please read the policies before posting to keep unmoderated posting privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101017/0901e1f8/attachment.htm From miss_c_27 at yahoo.com Sun Oct 17 14:00:46 2010 From: miss_c_27 at yahoo.com (miss c) Date: Sun, 17 Oct 2010 14:00:46 -0700 (PDT) Subject: [opensource-dev] Again About Scripting Issues specifically KELLY LINDEN In-Reply-To: References: <160144.68114.qm@web82108.mail.mud.yahoo.com> <4CBB5611.8010906@gmail.com> Message-ID: <324147.63773.qm@web82107.mail.mud.yahoo.com> That bug is listed here with 2.6.7 https://bugzilla.novell.com/show_bug.cgi?id=581679 Quote "I have tested this in Mono 2.6.7 and it is still occurring. it occurs when a second input field in added to a form (via the forms "+" button and happens at save." In version 2.8 it looks like they redid how mono works so it doesn't look like this is a bug that's going to be fixed. http://www.mono-project.com/Release_Notes_Mono_2.6.7 http://www.mono-project.com/Release_Notes_Mono_2.8 If this isn't fixable you may have to go to 2.8, but with as much as it looks like they changes, wow, a whole lot of work. But thank you for answering, can't wait to see it deployed. Miss ________________________________ From: Kelly Linden To: Rob Nelson Cc: opensource-dev at lists.secondlife.com Sent: Sun, October 17, 2010 3:17:40 PM Subject: Re: [opensource-dev] Again About Scripting Issues specifically KELLY LINDEN Currently we use Mono 1.2.6. Moving to Mono 2.6.7 is in testing right now. It requires a two stage process to deploy so there will be a 'mono2 aware' version that has to be deployed before we get all the new version stuff. We are currently working on tracking down hopefully one of the last issues, a "System.InvalidCastException" that we sometimes get when loading scripts. Unfortunately it is a bit difficult to repro, and is a bit more subtle than the name would make it seem relating to loading scripts. I regularly give updates on this project and any other scripting work I am aware of at my office hours: http://wiki.secondlife.com/wiki/User:Kelly_Linden#Office_Hours . The only other relevant list is probably secondlifescripters at lists.secondlife.com. - Kelly On Sun, Oct 17, 2010 at 1:01 PM, Rob Nelson wrote: There is no "we". The servers are proprietary; LL does this on their own dime and time. From what I gather, there's a little bit of work going towards that direction, but the mesh changes have their attention for now, like car keys dangled in front of a toddler. > >Rob > > >On 10/17/2010 12:40 PM, miss c wrote: >Running more and more tests about the lag in regions it seems more and >more to point towards this issue more than anything else. >> >>https://jira.secondlife.com/browse/SVC-3895 with over 900 votes >>"Rezzing Mono scripted object cripples sim FPS" >> >>Now Kelly mentioned on this post it had something to do with the >>mono secuirty.dll. >> >>When I did a search for Security.dll and mono in google it pulled up >>mailing lists and posts where this is actually a mono bug coming >>from their software. The portion I gather is it was fixed or >>improved in newer versions. I looked all over the wiki but I could >>not find what version of mono we are using. Does anyone know? >> >>I know this is more of a server function, but we have discussed at >>length for adding more tools to the viewer to monitor lag, but this >>would really make a huge difference if we just needed to update the >>mono version on the servers. >> >>If there is a server mailing list, please point me in that >>direction. >> >>Thanks >> >>Miss >>Fighting the lag every hour on the hour >> >> >> >> _______________________________________________ Policies and (un)subscribe >>information available here: >> >>http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before >>posting to keep unmoderated posting privileges >_______________________________________________ >Policies and (un)subscribe information available here: >http://wiki.secondlife.com/wiki/OpenSource-Dev >Please read the policies before posting to keep unmoderated posting privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101017/0901e1f8/attachment-0001.htm From miss_c_27 at yahoo.com Sun Oct 17 14:43:29 2010 From: miss_c_27 at yahoo.com (miss c) Date: Sun, 17 Oct 2010 14:43:29 -0700 (PDT) Subject: [opensource-dev] fix System.InvalidCastException (was again about scripting issues) In-Reply-To: <324147.63773.qm@web82107.mail.mud.yahoo.com> References: <160144.68114.qm@web82108.mail.mud.yahoo.com> <4CBB5611.8010906@gmail.com> <324147.63773.qm@web82107.mail.mud.yahoo.com> Message-ID: <886300.96935.qm@web82107.mail.mud.yahoo.com> https://bugzilla.novell.com/buglist.cgi?quicksearch=System.InvalidCastException .....The bug is listed 5 times... ....on one of these someone fixed the issue https://bugzilla.novell.com/show_bug.cgi?id=619929 ________________________________ From: miss c To: opensource-dev at lists.secondlife.com Cc: opensource-dev at lists.secondlife.com Sent: Sun, October 17, 2010 4:00:46 PM Subject: Re: [opensource-dev] Again About Scripting Issues specifically KELLY LINDEN That bug is listed here with 2.6.7 https://bugzilla.novell.com/show_bug.cgi?id=581679 Quote "I have tested this in Mono 2.6.7 and it is still occurring. it occurs when a second input field in added to a form (via the forms "+" button and happens at save." In version 2.8 it looks like they redid how mono works so it doesn't look like this is a bug that's going to be fixed. http://www.mono-project.com/Release_Notes_Mono_2.6.7 http://www.mono-project.com/Release_Notes_Mono_2.8 If this isn't fixable you may have to go to 2.8, but with as much as it looks like they changes, wow, a whole lot of work. But thank you for answering, can't wait to see it deployed. Miss ________________________________ From: Kelly Linden To: Rob Nelson Cc: opensource-dev at lists.secondlife.com Sent: Sun, October 17, 2010 3:17:40 PM Subject: Re: [opensource-dev] Again About Scripting Issues specifically KELLY LINDEN Currently we use Mono 1.2.6. Moving to Mono 2.6.7 is in testing right now. It requires a two stage process to deploy so there will be a 'mono2 aware' version that has to be deployed before we get all the new version stuff. We are currently working on tracking down hopefully one of the last issues, a "System.InvalidCastException" that we sometimes get when loading scripts. Unfortunately it is a bit difficult to repro, and is a bit more subtle than the name would make it seem relating to loading scripts. I regularly give updates on this project and any other scripting work I am aware of at my office hours: http://wiki.secondlife.com/wiki/User:Kelly_Linden#Office_Hours . The only other relevant list is probably secondlifescripters at lists.secondlife.com. - Kelly On Sun, Oct 17, 2010 at 1:01 PM, Rob Nelson wrote: There is no "we". The servers are proprietary; LL does this on their own dime and time. From what I gather, there's a little bit of work going towards that direction, but the mesh changes have their attention for now, like car keys dangled in front of a toddler. > >Rob > > >On 10/17/2010 12:40 PM, miss c wrote: >Running more and more tests about the lag in regions it seems more and >more to point towards this issue more than anything else. >> >>https://jira.secondlife.com/browse/SVC-3895 with over 900 votes >>"Rezzing Mono scripted object cripples sim FPS" >> >>Now Kelly mentioned on this post it had something to do with the >>mono secuirty.dll. >> >>When I did a search for Security.dll and mono in google it pulled up >>mailing lists and posts where this is actually a mono bug coming >>from their software. The portion I gather is it was fixed or >>improved in newer versions. I looked all over the wiki but I could >>not find what version of mono we are using. Does anyone know? >> >>I know this is more of a server function, but we have discussed at >>length for adding more tools to the viewer to monitor lag, but this >>would really make a huge difference if we just needed to update the >>mono version on the servers. >> >>If there is a server mailing list, please point me in that >>direction. >> >>Thanks >> >>Miss >>Fighting the lag every hour on the hour >> >> >> >> _______________________________________________ Policies and (un)subscribe >>information available here: >> >>http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before >>posting to keep unmoderated posting privileges >_______________________________________________ >Policies and (un)subscribe information available here: >http://wiki.secondlife.com/wiki/OpenSource-Dev >Please read the policies before posting to keep unmoderated posting privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101017/aaf3272a/attachment-0001.htm From arthur_fermi at fermisandbox.org Sun Oct 17 16:09:49 2010 From: arthur_fermi at fermisandbox.org (Arthur Fermi) Date: Sun, 17 Oct 2010 18:09:49 -0500 Subject: [opensource-dev] Fermi Viewer Message-ID: <000101cb6e50$6b4df020$41e9d060$@org> Fermi Sandbox is looking to put together a team to develop the Fermi Viewer. Please send inquires to Arthur_Fermi at fermisandbox.org or in world. Mission The Fermi Viewer projects goals are to create the best viewers for Second Life that works with all OS Grids. The Fermi Viewer will be open for all to review and look at, and all in house code will be generated and provided to the community. Project Overview The Fermi Viewer project will generate 2 separate viewers, one will be a full featured viewer along the lines of emerald, this will be a general viewer with a focus on building and sim management. The second view will be as light weight and fast as can be made, it will have building and sim management as its only focus with as many non-essential items moved out. Viewers will initial be based on the 1.x Snowglobe code from Linden Labs. A Version 2 viewer will come later in the project when time and resources are available to dedicate to a redesign of the interface. Open Source All work coming from the Fermi Viewer project will be returned to the community, this is a 100% open source project. Code Review All code other than the Linden Labs provide source code will be reviewed by a peer review committee to ensure that it complies with privacy standards. Once code is has been reviewed it will not need further review unless it has changed. Viewer Privacy Policy The Fermi Viewer will contain no code that will gather any information other than is required for interoperation with the grid it is connected to. No information will be stored off the client computer, no anonymous tracking data will be collected. Any violation of this policy will result in the instant removal from the project. Arthur Fermi -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101017/f08a5999/attachment.htm From carlo at alinoe.com Sun Oct 17 17:52:53 2010 From: carlo at alinoe.com (Carlo Wood) Date: Mon, 18 Oct 2010 02:52:53 +0200 Subject: [opensource-dev] fix System.InvalidCastException (was again about scripting issues) In-Reply-To: <886300.96935.qm@web82107.mail.mud.yahoo.com> References: <160144.68114.qm@web82108.mail.mud.yahoo.com> <4CBB5611.8010906@gmail.com> <324147.63773.qm@web82107.mail.mud.yahoo.com> <886300.96935.qm@web82107.mail.mud.yahoo.com> Message-ID: <20101018005253.GA32331@alinoe.com> Wow, very good miss! I think that last url is one that Linden Lab should study very closely. I too think that this will the solution for their problem. On Sun, Oct 17, 2010 at 02:43:29PM -0700, miss c wrote: > https://bugzilla.novell.com/buglist.cgi?quicksearch=System.InvalidCastException > > .....The bug is listed 5 times... > > > ....on one of these someone fixed the issue > https://bugzilla.novell.com/show_bug.cgi?id=619929 -- Carlo Wood From carlo at alinoe.com Sun Oct 17 17:58:33 2010 From: carlo at alinoe.com (Carlo Wood) Date: Mon, 18 Oct 2010 02:58:33 +0200 Subject: [opensource-dev] Fermi Viewer In-Reply-To: <000101cb6e50$6b4df020$41e9d060$@org> References: <000101cb6e50$6b4df020$41e9d060$@org> Message-ID: <20101018005833.GB32331@alinoe.com> Imho, it is not a good idea to start yet-another-viewer. The number of open source coders are limited, they should be working on one viewer - not twenty. We already have more than 10 different viewers based on LL's code. How is it possible we need another? On Sun, Oct 17, 2010 at 06:09:49PM -0500, Arthur Fermi wrote: > Fermi Sandbox is looking to put together a team to develop the Fermi Viewer. > Please send inquires to Arthur_Fermi at fermisandbox.org or in world. > > > > Mission > > The Fermi Viewer projects goals are to create the best viewers for Second Life > that works with all OS Grids. The Fermi Viewer will be open for all to review > and look at, and all in house code will be generated and provided to the > community. > > > > Project Overview > > The Fermi Viewer project will generate 2 separate viewers, one will be a full > featured viewer along the lines of emerald, this will be a general viewer with > a focus on building and sim management. The second view will be as light > weight and fast as can be made, it will have building and sim management as its > only focus with as many non-essential items moved out. > > Viewers will initial be based on the 1.x Snowglobe code from Linden Labs. A > Version 2 viewer will come later in the project when time and resources are > available to dedicate to a redesign of the interface. > > > > Open Source > > All work coming from the Fermi Viewer project will be returned to the > community, this is a 100% open source project. > > > > Code Review > > All code other than the Linden Labs provide source code will be reviewed by a > peer review committee to ensure that it complies with privacy standards. Once > code is has been reviewed it will not need further review unless it has > changed. > > > > Viewer Privacy Policy > > The Fermi Viewer will contain no code that will gather any information other > than is required for interoperation with the grid it is connected to. No > information will be stored off the client computer, no anonymous tracking data > will be collected. Any violation of this policy will result in the instant > removal from the project. > > > > Arthur Fermi > > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting privileges -- Carlo Wood From arthur_fermi at fermisandbox.org Sun Oct 17 18:02:01 2010 From: arthur_fermi at fermisandbox.org (Arthur Fermi) Date: Sun, 17 Oct 2010 20:02:01 -0500 Subject: [opensource-dev] Fermi Viewer In-Reply-To: <20101018005833.GB32331@alinoe.com> References: <000101cb6e50$6b4df020$41e9d060$@org> <20101018005833.GB32331@alinoe.com> Message-ID: <001e01cb6e60$1fe5f0f0$5fb1d2d0$@org> Well LLs base is a decent start point. We have looked at the other viewers and think we have some good ideas. I find that most of the other viewers are not focused on building or sim management. -----Original Message----- From: Carlo Wood [mailto:carlo at alinoe.com] Sent: Sunday, October 17, 2010 7:59 PM To: Arthur Fermi Cc: opensource-dev at lists.secondlife.com Subject: Re: [opensource-dev] Fermi Viewer Imho, it is not a good idea to start yet-another-viewer. The number of open source coders are limited, they should be working on one viewer - not twenty. We already have more than 10 different viewers based on LL's code. How is it possible we need another? On Sun, Oct 17, 2010 at 06:09:49PM -0500, Arthur Fermi wrote: > Fermi Sandbox is looking to put together a team to develop the Fermi Viewer. > Please send inquires to Arthur_Fermi at fermisandbox.org or in world. > > > > Mission > > The Fermi Viewer projects goals are to create the best viewers for Second Life > that works with all OS Grids. The Fermi Viewer will be open for all to review > and look at, and all in house code will be generated and provided to the > community. > > > > Project Overview > > The Fermi Viewer project will generate 2 separate viewers, one will be a full > featured viewer along the lines of emerald, this will be a general viewer with > a focus on building and sim management. The second view will be as light > weight and fast as can be made, it will have building and sim management as its > only focus with as many non-essential items moved out. > > Viewers will initial be based on the 1.x Snowglobe code from Linden Labs. A > Version 2 viewer will come later in the project when time and resources are > available to dedicate to a redesign of the interface. > > > > Open Source > > All work coming from the Fermi Viewer project will be returned to the > community, this is a 100% open source project. > > > > Code Review > > All code other than the Linden Labs provide source code will be reviewed by a > peer review committee to ensure that it complies with privacy standards. Once > code is has been reviewed it will not need further review unless it has > changed. > > > > Viewer Privacy Policy > > The Fermi Viewer will contain no code that will gather any information other > than is required for interoperation with the grid it is connected to. No > information will be stored off the client computer, no anonymous tracking data > will be collected. Any violation of this policy will result in the instant > removal from the project. > > > > Arthur Fermi > > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting privileges -- Carlo Wood From suezanne at gmail.com Sun Oct 17 19:05:26 2010 From: suezanne at gmail.com (SuezanneC Baskerville) Date: Sun, 17 Oct 2010 21:05:26 -0500 Subject: [opensource-dev] Fermi Viewer In-Reply-To: <001e01cb6e60$1fe5f0f0$5fb1d2d0$@org> References: <000101cb6e50$6b4df020$41e9d060$@org> <20101018005833.GB32331@alinoe.com> <001e01cb6e60$1fe5f0f0$5fb1d2d0$@org> Message-ID: Pehaps you could add the building and sim management features you think are useful to an existing project. On Sun, Oct 17, 2010 at 8:02 PM, Arthur Fermi wrote: > Well LLs base is a decent start point. We have looked at the other viewers > and think we have some good ideas. I find that most of the other viewers > are not focused on building or sim management. > > -----Original Message----- > From: Carlo Wood [mailto:carlo at alinoe.com] > Sent: Sunday, October 17, 2010 7:59 PM > To: Arthur Fermi > Cc: opensource-dev at lists.secondlife.com > Subject: Re: [opensource-dev] Fermi Viewer > > Imho, it is not a good idea to start yet-another-viewer. > The number of open source coders are limited, they should > be working on one viewer - not twenty. > > We already have more than 10 different viewers based > on LL's code. How is it possible we need another? > > On Sun, Oct 17, 2010 at 06:09:49PM -0500, Arthur Fermi wrote: > > Fermi Sandbox is looking to put together a team to develop the Fermi > Viewer. > > Please send inquires to Arthur_Fermi at fermisandbox.org or in world. > > > > > > > > Mission > > > > The Fermi Viewer projects goals are to create the best viewers for Second > Life > > that works with all OS Grids. The Fermi Viewer will be open for all to > review > > and look at, and all in house code will be generated and provided to the > > community. > > > > > > > > Project Overview > > > > The Fermi Viewer project will generate 2 separate viewers, one will be a > full > > featured viewer along the lines of emerald, this will be a general viewer > with > > a focus on building and sim management. The second view will be as light > > weight and fast as can be made, it will have building and sim management > as its > > only focus with as many non-essential items moved out. > > > > Viewers will initial be based on the 1.x Snowglobe code from Linden Labs. > A > > Version 2 viewer will come later in the project when time and resources > are > > available to dedicate to a redesign of the interface. > > > > > > > > Open Source > > > > All work coming from the Fermi Viewer project will be returned to the > > community, this is a 100% open source project. > > > > > > > > Code Review > > > > All code other than the Linden Labs provide source code will be reviewed > by a > > peer review committee to ensure that it complies with privacy standards. > Once > > code is has been reviewed it will not need further review unless it has > > changed. > > > > > > > > Viewer Privacy Policy > > > > The Fermi Viewer will contain no code that will gather any information > other > > than is required for interoperation with the grid it is connected to. No > > information will be stored off the client computer, no anonymous tracking > data > > will be collected. Any violation of this policy will result in the > instant > > removal from the project. > > > > > > > > Arthur Fermi > > > > > > > > > _______________________________________________ > > Policies and (un)subscribe information available here: > > http://wiki.secondlife.com/wiki/OpenSource-Dev > > Please read the policies before posting to keep unmoderated posting > privileges > > > -- > Carlo Wood > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting > privileges > -- v i r t u a l w o r l d e n t h u s i a s t -- http://www.google.com/profiles/s u e z a n n e -- -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101017/34f1ddfd/attachment-0001.htm From arthur_fermi at fermisandbox.org Sun Oct 17 19:09:28 2010 From: arthur_fermi at fermisandbox.org (Arthur Fermi) Date: Sun, 17 Oct 2010 21:09:28 -0500 Subject: [opensource-dev] Fermi Viewer In-Reply-To: References: <000101cb6e50$6b4df020$41e9d060$@org> <20101018005833.GB32331@alinoe.com> <001e01cb6e60$1fe5f0f0$5fb1d2d0$@org> Message-ID: <002201cb6e69$8038f930$80aaeb90$@org> That isn't something I had considered. In the end we would still need developers as we do not have the skills within the staff. From: SuezanneC Baskerville [mailto:suezanne at gmail.com] Sent: Sunday, October 17, 2010 9:05 PM To: Arthur Fermi Cc: Carlo Wood; opensource-dev at lists.secondlife.com Subject: Re: [opensource-dev] Fermi Viewer Pehaps you could add the building and sim management features you think are useful to an existing project. On Sun, Oct 17, 2010 at 8:02 PM, Arthur Fermi wrote: Well LLs base is a decent start point. We have looked at the other viewers and think we have some good ideas. I find that most of the other viewers are not focused on building or sim management. -----Original Message----- From: Carlo Wood [mailto:carlo at alinoe.com] Sent: Sunday, October 17, 2010 7:59 PM To: Arthur Fermi Cc: opensource-dev at lists.secondlife.com Subject: Re: [opensource-dev] Fermi Viewer Imho, it is not a good idea to start yet-another-viewer. The number of open source coders are limited, they should be working on one viewer - not twenty. We already have more than 10 different viewers based on LL's code. How is it possible we need another? On Sun, Oct 17, 2010 at 06:09:49PM -0500, Arthur Fermi wrote: > Fermi Sandbox is looking to put together a team to develop the Fermi Viewer. > Please send inquires to Arthur_Fermi at fermisandbox.org or in world. > > > > Mission > > The Fermi Viewer projects goals are to create the best viewers for Second Life > that works with all OS Grids. The Fermi Viewer will be open for all to review > and look at, and all in house code will be generated and provided to the > community. > > > > Project Overview > > The Fermi Viewer project will generate 2 separate viewers, one will be a full > featured viewer along the lines of emerald, this will be a general viewer with > a focus on building and sim management. The second view will be as light > weight and fast as can be made, it will have building and sim management as its > only focus with as many non-essential items moved out. > > Viewers will initial be based on the 1.x Snowglobe code from Linden Labs. A > Version 2 viewer will come later in the project when time and resources are > available to dedicate to a redesign of the interface. > > > > Open Source > > All work coming from the Fermi Viewer project will be returned to the > community, this is a 100% open source project. > > > > Code Review > > All code other than the Linden Labs provide source code will be reviewed by a > peer review committee to ensure that it complies with privacy standards. Once > code is has been reviewed it will not need further review unless it has > changed. > > > > Viewer Privacy Policy > > The Fermi Viewer will contain no code that will gather any information other > than is required for interoperation with the grid it is connected to. No > information will be stored off the client computer, no anonymous tracking data > will be collected. Any violation of this policy will result in the instant > removal from the project. > > > > Arthur Fermi > > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting privileges -- Carlo Wood _______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges -- v i r t u a l w o r l d e n t h u s i a s t -- http://www.google.com/profiles/s u e z a n n e -- -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101017/01ce4e33/attachment.htm From akanevsky at productengine.com Sun Oct 17 22:28:09 2010 From: akanevsky at productengine.com (Anya Kanevsky) Date: Sun, 17 Oct 2010 22:28:09 -0700 Subject: [opensource-dev] Daily Scrum Summary - Friday, October 15 Message-ID: https://wiki.secondlife.com/wiki/Snowstorm_Daily_Scrum_Archive Date: Fri Oct 15 == GENERAL NOTES == * Merge Monkey of the Day: Oz == DAILY SCRUM == === Merov === PAST * STORM-104: kdu upgrade: Fixed integration tests I broke, cleaned up build changes, build and test more, clean up unecessary code, more tests. FUTURE * STORM-104: kdu upgrade: Finish that. * STORM-105 : Perf decompression: put new data out, check the work done by opensource-dev community on similar tests. IMPEDIMENTS * Latest KDU bits ==Oz Linden== PAST * Merge Monkey ** Pulled outstanding beta fixes back to viewer-development ** Pushed everything to viewer-release ** re-testing changes for STORM-137 ** Pulled to viewer-developement: *** STORM-279 FUTURE * Merge Monkey ** Finish draining Snowstorm Integration queue * More changes to develop site * Figure out what to propose for WEB-1560 IMPEDIMENTS * none === Q Linden=== PAST * Release * STORM-381 * STORM-389 * STORM-390 * STORM-358 * OOO for 3 hrs yesterday and again today. * Log issue FUTURE * Release (all that stuff) IMPEDIMENTS * Release * Gotta slow down personally === Esbee Linden==== PAST * Viewer 2.2 Release prep * VWR triage * System requirements analysis * Learning a bit about Python * Drafting Viewer 2.2 release blog post FUTURE * Write Viewer 2.2 Release blog post * Systems requirements analysis * VWR Triage * Viewer 2.2 Release IMPEDIMENTS * None === Paul ProductEngine=== PAST: * STORM-263 (Cog button in lower-left of sidebar panel does not close popup menu on second click) ** Helped SL to fix this bug and created test plan for it * STORM-293 (Friend permissions icons overlap long names on 'My Friends' tab) ** WIP. ~5-6 hours. FUTURE: * STORM-293 Friend permissions icons overlap long names on 'My Friends' tab IMPEDIMENTS: * none === Seth Productengine === PAST: * BUG (STORM-263) Cog button in lower-left of sidebar panel does not close popup menu on second click * Fixed issues found in previous fix. ** Moved fix to viewer-development with slight refactoring and re-testing. * BUG (STORM-296) Cursor doesn't change when trying to drag and drop non-landmark items into Favorites folder ** Working on additional fix. FUTURE: * BUG (STORM-296) Cursor doesn't change when trying to drag and drop non-landmark items into Favorites folder * BUG (STORM-303) Favorites folder content isn't refreshed while re-ordering landmaks ** Estimated: 4-6 hours. IMPEDIMENTS: * none === Andrew Productengine === PAST: * Bug STORM-322 (Group Member Search: gives more entries then the search string suggests) ** WIP. Fixed the problem, but struggling with some strange problems in drawing the list- it flickers and only part of items are deleted. Will search for ways to solve it, maybe using timer will help. ** Estimate- 6 hours. FUTURE: * Bug STORM-322 (Group Member Search: gives more entries then the search string suggests). IMPEDIMENTS: * none === Vadim Productengine === PAST: * Bug STORM-381 (Impossible to join/create group from People tab > My Groups): ** Fixed by backing out the fix of STORM-263. * Bug STORM-211 (Fade timer is reset for all toasts displayed in the notifications channel): ** Fixed. * Bug STORM-376 (Toast close button sometimes doesn't disappear): ** Fixed. FUTURE: * Complete STORM-211. * Bug STORM-376 (Toast close button sometimes doesn't disappear). IMPEDIMENTS: * STORM-297 needs input === Andrey Productengine === PAST: * integrated tickets verification on the latest v-d build * exploratory regression testing in scope of changes FUTURE: * run formal regression testing against the latest build IMPEDIMENTS: * none From sythos at gmail.com Sun Oct 17 22:54:07 2010 From: sythos at gmail.com (Francesco Rabbi) Date: Mon, 18 Oct 2010 07:54:07 +0200 Subject: [opensource-dev] Fermi Viewer In-Reply-To: <001e01cb6e60$1fe5f0f0$5fb1d2d0$@org> References: <000101cb6e50$6b4df020$41e9d060$@org> <20101018005833.GB32331@alinoe.com> <001e01cb6e60$1fe5f0f0$5fb1d2d0$@org> Message-ID: <-574497265938522238@unknownmsgid> I think Carlo mean something else... In place to create another viewer join an existing team and contribute code for building and SIM managements -- Sent by iPhone Il giorno 18/ott/2010, alle ore 03:02, "Arthur Fermi" ha scritto: > Well LLs base is a decent start point. We have looked at the other viewers > and think we have some good ideas. I find that most of the other viewers > are not focused on building or sim management. > > -----Original Message----- > From: Carlo Wood [mailto:carlo at alinoe.com] > Sent: Sunday, October 17, 2010 7:59 PM > To: Arthur Fermi > Cc: opensource-dev at lists.secondlife.com > Subject: Re: [opensource-dev] Fermi Viewer > > Imho, it is not a good idea to start yet-another-viewer. > The number of open source coders are limited, they should > be working on one viewer - not twenty. > > We already have more than 10 different viewers based > on LL's code. How is it possible we need another? > > On Sun, Oct 17, 2010 at 06:09:49PM -0500, Arthur Fermi wrote: >> Fermi Sandbox is looking to put together a team to develop the Fermi > Viewer. >> Please send inquires to Arthur_Fermi at fermisandbox.org or in world. >> >> >> >> Mission >> >> The Fermi Viewer projects goals are to create the best viewers for Second > Life >> that works with all OS Grids. The Fermi Viewer will be open for all to > review >> and look at, and all in house code will be generated and provided to the >> community. >> >> >> >> Project Overview >> >> The Fermi Viewer project will generate 2 separate viewers, one will be a > full >> featured viewer along the lines of emerald, this will be a general viewer > with >> a focus on building and sim management. The second view will be as light >> weight and fast as can be made, it will have building and sim management > as its >> only focus with as many non-essential items moved out. >> >> Viewers will initial be based on the 1.x Snowglobe code from Linden Labs. > A >> Version 2 viewer will come later in the project when time and resources > are >> available to dedicate to a redesign of the interface. >> >> >> >> Open Source >> >> All work coming from the Fermi Viewer project will be returned to the >> community, this is a 100% open source project. >> >> >> >> Code Review >> >> All code other than the Linden Labs provide source code will be reviewed > by a >> peer review committee to ensure that it complies with privacy standards. > Once >> code is has been reviewed it will not need further review unless it has >> changed. >> >> >> >> Viewer Privacy Policy >> >> The Fermi Viewer will contain no code that will gather any information > other >> than is required for interoperation with the grid it is connected to. No >> information will be stored off the client computer, no anonymous tracking > data >> will be collected. Any violation of this policy will result in the > instant >> removal from the project. >> >> >> >> Arthur Fermi >> >> >> > >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/OpenSource-Dev >> Please read the policies before posting to keep unmoderated posting > privileges > > > -- > Carlo Wood > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting privileges From marc at inworlddesigns.com Mon Oct 18 00:01:09 2010 From: marc at inworlddesigns.com (Marc Adored) Date: Mon, 18 Oct 2010 03:01:09 -0400 Subject: [opensource-dev] Fermi Viewer In-Reply-To: <-574497265938522238@unknownmsgid> References: <000101cb6e50$6b4df020$41e9d060$@org> <20101018005833.GB32331@alinoe.com> <001e01cb6e60$1fe5f0f0$5fb1d2d0$@org> <-574497265938522238@unknownmsgid> Message-ID: Yes that could be awesome like The Fermi Builders Mod for Phoenix or better yet Kirstens :D On Mon, Oct 18, 2010 at 1:54 AM, Francesco Rabbi wrote: > I think Carlo mean something else... In place to create another viewer > join an existing team and contribute code for building and SIM > managements > > -- > Sent by iPhone > > Il giorno 18/ott/2010, alle ore 03:02, "Arthur Fermi" > ha scritto: > >> Well LLs base is a decent start point. ?We have looked at the other viewers >> and think we have some good ideas. ?I find that most of the other viewers >> are not focused on building or sim management. >> >> -----Original Message----- >> From: Carlo Wood [mailto:carlo at alinoe.com] >> Sent: Sunday, October 17, 2010 7:59 PM >> To: Arthur Fermi >> Cc: opensource-dev at lists.secondlife.com >> Subject: Re: [opensource-dev] Fermi Viewer >> >> Imho, it is not a good idea to start yet-another-viewer. >> The number of open source coders are limited, they should >> be working on one viewer - not twenty. >> >> We already have more than 10 different viewers based >> on LL's code. How is it possible we need another? >> >> On Sun, Oct 17, 2010 at 06:09:49PM -0500, Arthur Fermi wrote: >>> Fermi Sandbox is looking to put together a team to develop the Fermi >> Viewer. >>> Please send inquires to Arthur_Fermi at fermisandbox.org or in world. >>> >>> >>> >>> Mission >>> >>> The Fermi Viewer projects goals are to create the best viewers for Second >> Life >>> that works with all OS Grids. ?The Fermi Viewer will be open for all to >> review >>> and look at, and all in house code will be generated and provided to the >>> community. >>> >>> >>> >>> Project Overview >>> >>> The Fermi Viewer project will generate 2 separate viewers, one will be a >> full >>> featured viewer along the lines of emerald, this will be a general viewer >> with >>> a focus on building and sim management. ?The second view will be as light >>> weight and fast as can be made, it will have building and sim management >> as its >>> only focus with as many non-essential items moved out. >>> >>> Viewers will initial be based on the 1.x Snowglobe code from Linden Labs. >> A >>> Version 2 viewer will come later in the project when time and resources >> are >>> available to dedicate to a redesign of the interface. >>> >>> >>> >>> Open Source >>> >>> All work coming from the Fermi Viewer project will be returned to the >>> community, this is a 100% open source project. >>> >>> >>> >>> Code Review >>> >>> All code other than the Linden Labs provide source code will be reviewed >> by a >>> peer review committee to ensure that it complies with privacy standards. >> Once >>> code is has been reviewed it will not need further review unless it has >>> changed. >>> >>> >>> >>> Viewer Privacy Policy >>> >>> The Fermi Viewer will contain no code that will gather any information >> other >>> than is required for interoperation with the grid it is connected to. ?No >>> information will be stored off the client computer, no anonymous tracking >> data >>> will be collected. ? Any violation of this policy will result in the >> instant >>> removal from the project. >>> >>> >>> >>> Arthur Fermi >>> >>> >>> >> >>> _______________________________________________ >>> Policies and (un)subscribe information available here: >>> http://wiki.secondlife.com/wiki/OpenSource-Dev >>> Please read the policies before posting to keep unmoderated posting >> privileges >> >> >> -- >> Carlo Wood >> >> >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/OpenSource-Dev >> Please read the policies before posting to keep unmoderated posting privileges > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting privileges > From Lance.Corrimal at eregion.de Mon Oct 18 00:33:15 2010 From: Lance.Corrimal at eregion.de (Lance Corrimal) Date: Mon, 18 Oct 2010 09:33:15 +0200 Subject: [opensource-dev] Fermi Viewer In-Reply-To: <002201cb6e69$8038f930$80aaeb90$@org> References: <000101cb6e50$6b4df020$41e9d060$@org> <002201cb6e69$8038f930$80aaeb90$@org> Message-ID: <201010180933.15397.Lance.Corrimal@eregion.de> Am Montag, 18. Oktober 2010, 04:09:28 schrieb Arthur Fermi: > That isn't something I had considered. In the end we would still need > developers as we do not have the skills within the staff. so, let me see if I get this right. You have some ideas, and you need someone else to actually get those eimplemented, and you want to publish the resulting viewer under a name of your choice? ...why don't you simply float your ideas thru the list & see, they might even end up in an official viewer instead of in a TPV... bye, LC From arthur_fermi at fermisandbox.org Mon Oct 18 04:08:36 2010 From: arthur_fermi at fermisandbox.org (Arthur Fermi) Date: Mon, 18 Oct 2010 06:08:36 -0500 Subject: [opensource-dev] Fermi Viewer In-Reply-To: References: <000101cb6e50$6b4df020$41e9d060$@org> <20101018005833.GB32331@alinoe.com> <001e01cb6e60$1fe5f0f0$5fb1d2d0$@org> <-574497265938522238@unknownmsgid> Message-ID: <000101cb6eb4$d086e0a0$7194a1e0$@org> I am liking that idea :) the catch for us, is we have zero skills in house for a viewer. We can build datacenters, large database projects, program in Perl, PHP, VB, LSL and probably a few more, but no C programmers of any type. Go figure :) -----Original Message----- From: Marc Adored [mailto:marc at inworlddesigns.com] Sent: Monday, October 18, 2010 2:01 AM To: Francesco Rabbi Cc: Arthur Fermi; opensource-dev at lists.secondlife.com Subject: Re: [opensource-dev] Fermi Viewer Yes that could be awesome like The Fermi Builders Mod for Phoenix or better yet Kirstens :D On Mon, Oct 18, 2010 at 1:54 AM, Francesco Rabbi wrote: > I think Carlo mean something else... In place to create another viewer > join an existing team and contribute code for building and SIM > managements > > -- > Sent by iPhone > > Il giorno 18/ott/2010, alle ore 03:02, "Arthur Fermi" > ha scritto: > >> Well LLs base is a decent start point. ?We have looked at the other viewers >> and think we have some good ideas. ?I find that most of the other viewers >> are not focused on building or sim management. >> >> -----Original Message----- >> From: Carlo Wood [mailto:carlo at alinoe.com] >> Sent: Sunday, October 17, 2010 7:59 PM >> To: Arthur Fermi >> Cc: opensource-dev at lists.secondlife.com >> Subject: Re: [opensource-dev] Fermi Viewer >> >> Imho, it is not a good idea to start yet-another-viewer. >> The number of open source coders are limited, they should >> be working on one viewer - not twenty. >> >> We already have more than 10 different viewers based >> on LL's code. How is it possible we need another? >> >> On Sun, Oct 17, 2010 at 06:09:49PM -0500, Arthur Fermi wrote: >>> Fermi Sandbox is looking to put together a team to develop the Fermi >> Viewer. >>> Please send inquires to Arthur_Fermi at fermisandbox.org or in world. >>> >>> >>> >>> Mission >>> >>> The Fermi Viewer projects goals are to create the best viewers for Second >> Life >>> that works with all OS Grids. ?The Fermi Viewer will be open for all to >> review >>> and look at, and all in house code will be generated and provided to the >>> community. >>> >>> >>> >>> Project Overview >>> >>> The Fermi Viewer project will generate 2 separate viewers, one will be a >> full >>> featured viewer along the lines of emerald, this will be a general viewer >> with >>> a focus on building and sim management. ?The second view will be as light >>> weight and fast as can be made, it will have building and sim management >> as its >>> only focus with as many non-essential items moved out. >>> >>> Viewers will initial be based on the 1.x Snowglobe code from Linden Labs. >> A >>> Version 2 viewer will come later in the project when time and resources >> are >>> available to dedicate to a redesign of the interface. >>> >>> >>> >>> Open Source >>> >>> All work coming from the Fermi Viewer project will be returned to the >>> community, this is a 100% open source project. >>> >>> >>> >>> Code Review >>> >>> All code other than the Linden Labs provide source code will be reviewed >> by a >>> peer review committee to ensure that it complies with privacy standards. >> Once >>> code is has been reviewed it will not need further review unless it has >>> changed. >>> >>> >>> >>> Viewer Privacy Policy >>> >>> The Fermi Viewer will contain no code that will gather any information >> other >>> than is required for interoperation with the grid it is connected to. ?No >>> information will be stored off the client computer, no anonymous tracking >> data >>> will be collected. ? Any violation of this policy will result in the >> instant >>> removal from the project. >>> >>> >>> >>> Arthur Fermi >>> >>> >>> >> >>> _______________________________________________ >>> Policies and (un)subscribe information available here: >>> http://wiki.secondlife.com/wiki/OpenSource-Dev >>> Please read the policies before posting to keep unmoderated posting >> privileges >> >> >> -- >> Carlo Wood >> >> >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/OpenSource-Dev >> Please read the policies before posting to keep unmoderated posting privileges > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting privileges > From nexisentertainment at gmail.com Mon Oct 18 04:58:38 2010 From: nexisentertainment at gmail.com (Rob Nelson) Date: Mon, 18 Oct 2010 04:58:38 -0700 Subject: [opensource-dev] Fermi Viewer In-Reply-To: <000101cb6eb4$d086e0a0$7194a1e0$@org> References: <000101cb6e50$6b4df020$41e9d060$@org> <20101018005833.GB32331@alinoe.com> <001e01cb6e60$1fe5f0f0$5fb1d2d0$@org> <-574497265938522238@unknownmsgid> <000101cb6eb4$d086e0a0$7194a1e0$@org> Message-ID: <4CBC366E.50605@gmail.com> Just spit out what you want, some of us are bored enough to add it to our viewers. Rob On 10/18/2010 4:08 AM, Arthur Fermi wrote: > I am liking that idea :) the catch for us, is we have zero skills in house > for a viewer. We can build datacenters, large database projects, program in > Perl, PHP, VB, LSL and probably a few more, but no C programmers of any > type. Go figure :) > > -----Original Message----- > From: Marc Adored [mailto:marc at inworlddesigns.com] > Sent: Monday, October 18, 2010 2:01 AM > To: Francesco Rabbi > Cc: Arthur Fermi; opensource-dev at lists.secondlife.com > Subject: Re: [opensource-dev] Fermi Viewer > > Yes that could be awesome like The Fermi Builders Mod for Phoenix or > better yet Kirstens :D > > > On Mon, Oct 18, 2010 at 1:54 AM, Francesco Rabbi wrote: >> I think Carlo mean something else... In place to create another viewer >> join an existing team and contribute code for building and SIM >> managements >> >> -- >> Sent by iPhone >> >> Il giorno 18/ott/2010, alle ore 03:02, "Arthur Fermi" >> ha scritto: >> >>> Well LLs base is a decent start point. We have looked at the other > viewers >>> and think we have some good ideas. I find that most of the other viewers >>> are not focused on building or sim management. >>> >>> -----Original Message----- >>> From: Carlo Wood [mailto:carlo at alinoe.com] >>> Sent: Sunday, October 17, 2010 7:59 PM >>> To: Arthur Fermi >>> Cc: opensource-dev at lists.secondlife.com >>> Subject: Re: [opensource-dev] Fermi Viewer >>> >>> Imho, it is not a good idea to start yet-another-viewer. >>> The number of open source coders are limited, they should >>> be working on one viewer - not twenty. >>> >>> We already have more than 10 different viewers based >>> on LL's code. How is it possible we need another? >>> >>> On Sun, Oct 17, 2010 at 06:09:49PM -0500, Arthur Fermi wrote: >>>> Fermi Sandbox is looking to put together a team to develop the Fermi >>> Viewer. >>>> Please send inquires to Arthur_Fermi at fermisandbox.org or in world. >>>> >>>> >>>> >>>> Mission >>>> >>>> The Fermi Viewer projects goals are to create the best viewers for > Second >>> Life >>>> that works with all OS Grids. The Fermi Viewer will be open for all to >>> review >>>> and look at, and all in house code will be generated and provided to the >>>> community. >>>> >>>> >>>> >>>> Project Overview >>>> >>>> The Fermi Viewer project will generate 2 separate viewers, one will be a >>> full >>>> featured viewer along the lines of emerald, this will be a general > viewer >>> with >>>> a focus on building and sim management. The second view will be as > light >>>> weight and fast as can be made, it will have building and sim management >>> as its >>>> only focus with as many non-essential items moved out. >>>> >>>> Viewers will initial be based on the 1.x Snowglobe code from Linden > Labs. >>> A >>>> Version 2 viewer will come later in the project when time and resources >>> are >>>> available to dedicate to a redesign of the interface. >>>> >>>> >>>> >>>> Open Source >>>> >>>> All work coming from the Fermi Viewer project will be returned to the >>>> community, this is a 100% open source project. >>>> >>>> >>>> >>>> Code Review >>>> >>>> All code other than the Linden Labs provide source code will be reviewed >>> by a >>>> peer review committee to ensure that it complies with privacy standards. >>> Once >>>> code is has been reviewed it will not need further review unless it has >>>> changed. >>>> >>>> >>>> >>>> Viewer Privacy Policy >>>> >>>> The Fermi Viewer will contain no code that will gather any information >>> other >>>> than is required for interoperation with the grid it is connected to. > No >>>> information will be stored off the client computer, no anonymous > tracking >>> data >>>> will be collected. Any violation of this policy will result in the >>> instant >>>> removal from the project. >>>> >>>> >>>> >>>> Arthur Fermi >>>> >>>> >>>> >>>> _______________________________________________ >>>> Policies and (un)subscribe information available here: >>>> http://wiki.secondlife.com/wiki/OpenSource-Dev >>>> Please read the policies before posting to keep unmoderated posting >>> privileges >>> >>> >>> -- >>> Carlo Wood >>> >>> >>> _______________________________________________ >>> Policies and (un)subscribe information available here: >>> http://wiki.secondlife.com/wiki/OpenSource-Dev >>> Please read the policies before posting to keep unmoderated posting > privileges >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/OpenSource-Dev >> Please read the policies before posting to keep unmoderated posting > privileges > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting privileges > From jamey at beau.org Mon Oct 18 07:26:58 2010 From: jamey at beau.org (Jamey Fletcher) Date: Mon, 18 Oct 2010 09:26:58 -0500 Subject: [opensource-dev] Fermi Viewer In-Reply-To: References: <000101cb6e50$6b4df020$41e9d060$@org> <20101018005833.GB32331@alinoe.com> <001e01cb6e60$1fe5f0f0$5fb1d2d0$@org> <-574497265938522238@unknownmsgid> Message-ID: <4CBC5932.6080309@beau.org> Marc Adored wrote: > Yes that could be awesome like The Fermi Builders Mod for Phoenix or Imprudence? From tom at streamsense.net Mon Oct 18 07:29:52 2010 From: tom at streamsense.net (Thomas Grimshaw) Date: Mon, 18 Oct 2010 15:29:52 +0100 Subject: [opensource-dev] Fermi Viewer In-Reply-To: <4CBC5932.6080309@beau.org> References: <000101cb6e50$6b4df020$41e9d060$@org> <20101018005833.GB32331@alinoe.com> <001e01cb6e60$1fe5f0f0$5fb1d2d0$@org> <-574497265938522238@unknownmsgid> <4CBC5932.6080309@beau.org> Message-ID: <4CBC59E0.9050800@streamsense.net> Imprudence is certainly not stable enough for a viewer targeted at builders. ~Tom On 18/10/2010 15:26, Jamey Fletcher wrote: > Marc Adored wrote: > >> Yes that could be awesome like The Fermi Builders Mod for Phoenix or > Imprudence? > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting privileges From suezanne at gmail.com Mon Oct 18 07:51:51 2010 From: suezanne at gmail.com (SuezanneC Baskerville) Date: Mon, 18 Oct 2010 09:51:51 -0500 Subject: [opensource-dev] Fermi Viewer In-Reply-To: <4CBC59E0.9050800@streamsense.net> References: <000101cb6e50$6b4df020$41e9d060$@org> <20101018005833.GB32331@alinoe.com> <001e01cb6e60$1fe5f0f0$5fb1d2d0$@org> <-574497265938522238@unknownmsgid> <4CBC5932.6080309@beau.org> <4CBC59E0.9050800@streamsense.net> Message-ID: The "Visibuild" project, at http://visibuild3d.com/, might have some bearing on this, possibly. One might think a viewer and grid that are suposed to be useful for real world architecture would have some build tools other than the normal. It's C++, isn't it, not C? On Mon, Oct 18, 2010 at 9:29 AM, Thomas Grimshaw wrote: > Imprudence is certainly not stable enough for a viewer targeted at > builders. > > ~Tom > > On 18/10/2010 15:26, Jamey Fletcher wrote: > > Marc Adored wrote: > > > >> Yes that could be awesome like The Fermi Builders Mod for Phoenix or > > Imprudence? > > _______________________________________________ > > Policies and (un)subscribe information available here: > > http://wiki.secondlife.com/wiki/OpenSource-Dev > > Please read the policies before posting to keep unmoderated posting > privileges > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting > privileges > -- v i r t u a l w o r l d e n t h u s i a s t -- http://www.google.com/profiles/s u e z a n n e -- -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101018/d40dfa03/attachment.htm From kelly at lindenlab.com Mon Oct 18 08:08:39 2010 From: kelly at lindenlab.com (Kelly Linden) Date: Mon, 18 Oct 2010 08:08:39 -0700 Subject: [opensource-dev] fix System.InvalidCastException (was again about scripting issues) In-Reply-To: <20101018005253.GA32331@alinoe.com> References: <160144.68114.qm@web82108.mail.mud.yahoo.com> <4CBB5611.8010906@gmail.com> <324147.63773.qm@web82107.mail.mud.yahoo.com> <886300.96935.qm@web82107.mail.mud.yahoo.com> <20101018005253.GA32331@alinoe.com> Message-ID: Thank you for looking into it Miss C. We are indeed aware of mono's bugzilla, and even this specific bug report. Unfortunately, unlike the reporter, there is no clear enumeration of a dictionary happening where we see the crash. This is also a bug we saw well before the reporter saw it - while he reports a build on June 24th as introducing the bug for him, ours appears to be a re-occurrence of a bug we saw when we first attempted to address the mono stall bug back with SL Server 1.38 at the beginning of the year. Our error probably is at least tangentially related - a Dictionary or other container is the most likely source of the bug. Hopefully we can track it down this week. :) - kelly On Sun, Oct 17, 2010 at 5:52 PM, Carlo Wood wrote: > Wow, very good miss! > > I think that last url is one that Linden Lab should study > very closely. I too think that this will the solution > for their problem. > > On Sun, Oct 17, 2010 at 02:43:29PM -0700, miss c wrote: > > > https://bugzilla.novell.com/buglist.cgi?quicksearch=System.InvalidCastException > > > > .....The bug is listed 5 times... > > > > > > ....on one of these someone fixed the issue > > https://bugzilla.novell.com/show_bug.cgi?id=619929 > > -- > Carlo Wood > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101018/36e9891f/attachment.htm From kelly at lindenlab.com Mon Oct 18 08:33:47 2010 From: kelly at lindenlab.com (Kelly Linden) Date: Mon, 18 Oct 2010 08:33:47 -0700 Subject: [opensource-dev] Again About Scripting Issues specifically KELLY LINDEN In-Reply-To: <324147.63773.qm@web82107.mail.mud.yahoo.com> References: <160144.68114.qm@web82108.mail.mud.yahoo.com> <4CBB5611.8010906@gmail.com> <324147.63773.qm@web82107.mail.mud.yahoo.com> Message-ID: There are lots of ways to get an InvalidCastException, many of them quite valid. http://stackoverflow.com has a fair number of questions on the topic, and here is a good summary of what that error actually means: http://dotnetperls.com/invalidcastexception . Apparently there is also some more fun to be had if you are dealing with multiple domains - http://blogs.msdn.com/b/suzcook/archive/2004/06/02/debugging-an-invalidcastexception.aspx. We actually do move scripts across domains as a way to manage garbage collection on scripts, and that is something that has "been touched" during this project. I'm leaning towards this being closer to the issue, but I'm certainly open to other possibilities. - Kelly On Sun, Oct 17, 2010 at 2:00 PM, miss c wrote: > That bug is listed here with 2.6.7 > > https://bugzilla.novell.com/show_bug.cgi?id=581679 > > Quote "I have tested this in Mono 2.6.7 and it is still occurring. it > occurs when a second input field in added to a form (via the forms "+" > button and happens at save." > > In version 2.8 it looks like they redid how mono works so it doesn't look > like this is a bug that's going to be fixed. > > http://www.mono-project.com/Release_Notes_Mono_2.6.7 > http://www.mono-project.com/Release_Notes_Mono_2.8 > > If this isn't fixable you may have to go to 2.8, but with as much as it > looks like they changes, wow, a whole lot of work. But thank you for > answering, can't wait to see it deployed. > > Miss > > > > ------------------------------ > *From:* Kelly Linden > *To:* Rob Nelson > *Cc:* opensource-dev at lists.secondlife.com > *Sent:* Sun, October 17, 2010 3:17:40 PM > > *Subject:* Re: [opensource-dev] Again About Scripting Issues specifically > KELLY LINDEN > > Currently we use Mono 1.2.6. > > Moving to Mono 2.6.7 is in testing right now. It requires a two stage > process to deploy so there will be a 'mono2 aware' version that has to be > deployed before we get all the new version stuff. We are currently working > on tracking down hopefully one of the last issues, a > "System.InvalidCastException" that we sometimes get when loading scripts. > Unfortunately it is a bit difficult to repro, and is a bit more subtle than > the name would make it seem relating to loading scripts. > > I regularly give updates on this project and any other scripting work I am > aware of at my office hours: > http://wiki.secondlife.com/wiki/User:Kelly_Linden#Office_Hours . The only > other relevant list is probably secondlifescripters at lists.secondlife.com. > > - Kelly > > On Sun, Oct 17, 2010 at 1:01 PM, Rob Nelson wrote: > >> There is no "we". The servers are proprietary; LL does this on their own >> dime and time. From what I gather, there's a little bit of work going >> towards that direction, but the mesh changes have their attention for now, >> like car keys dangled in front of a toddler. >> >> Rob >> >> >> On 10/17/2010 12:40 PM, miss c wrote: >> >> Running more and more tests about the lag in regions it seems more and >> more to point towards this issue more than anything else. >> >> https://jira.secondlife.com/browse/SVC-3895 with over 900 votes >> "Rezzing Mono scripted object cripples sim FPS" >> >> Now Kelly mentioned on this post it had something to do with the mono >> secuirty.dll. >> >> When I did a search for Security.dll and mono in google it pulled up >> mailing lists and posts where this is actually a mono bug coming from their >> software. The portion I gather is it was fixed or improved in newer >> versions. I looked all over the wiki but I could not find what version of >> mono we are using. Does anyone know? >> >> I know this is more of a server function, but we have discussed at length >> for adding more tools to the viewer to monitor lag, but this would really >> make a huge difference if we just needed to update the mono version on the >> servers. >> >> If there is a server mailing list, please point me in that direction. >> >> Thanks >> >> Miss >> Fighting the lag every hour on the hour >> >> >> >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/OpenSource-Dev >> Please read the policies before posting to keep unmoderated posting privileges >> >> >> >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/OpenSource-Dev >> Please read the policies before posting to keep unmoderated posting >> privileges >> > > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101018/8d43630d/attachment-0001.htm From miss_c_27 at yahoo.com Mon Oct 18 09:05:18 2010 From: miss_c_27 at yahoo.com (miss c) Date: Mon, 18 Oct 2010 09:05:18 -0700 (PDT) Subject: [opensource-dev] user story - events and appointments Message-ID: <239448.98222.qm@web82103.mail.mud.yahoo.com> As a user I would like to be able to add a future event or office hours to an in game calender complete with email and in game reminder with a simple click. Toggling between windows to add an event to another calender or simply attempting to remember is not sufficient. I feel that events would get more attendance with such a feature and should be considered critical to assist residents in their efforts to create such events. This is already on the Jira in many places. Thank you Miss -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101018/d8dd81a0/attachment.htm From overdrive at dceo.rutgers.edu Mon Oct 18 09:46:18 2010 From: overdrive at dceo.rutgers.edu (Ron Festa) Date: Mon, 18 Oct 2010 12:46:18 -0400 Subject: [opensource-dev] Fermi Viewer In-Reply-To: References: <000101cb6e50$6b4df020$41e9d060$@org> <20101018005833.GB32331@alinoe.com> <001e01cb6e60$1fe5f0f0$5fb1d2d0$@org> <-574497265938522238@unknownmsgid> <4CBC5932.6080309@beau.org> <4CBC59E0.9050800@streamsense.net> Message-ID: Visibuild is RealXtend and Naali, not vanilla SL or OpenSIM. Nothing contributed to that would benefit SL or vanilla OpenSIM especially since both SL & OS are getting mesh support. Ron Festa Virtual Worlds Admin Division of Continuing Studies at Rutgers University PGP key: http://bit.ly/b1ZyhY Phone: 732-474-8583 On Mon, Oct 18, 2010 at 10:51 AM, SuezanneC Baskerville wrote: > The "Visibuild" project, at http://visibuild3d.com/, might have some > bearing on this, possibly. > > One might think a viewer and grid that are suposed to be useful for real > world architecture would have some build tools other than the normal. > > It's C++, isn't it, not C? > > > On Mon, Oct 18, 2010 at 9:29 AM, Thomas Grimshaw wrote: > >> Imprudence is certainly not stable enough for a viewer targeted at >> builders. >> >> ~Tom >> >> On 18/10/2010 15:26, Jamey Fletcher wrote: >> > Marc Adored wrote: >> > >> >> Yes that could be awesome like The Fermi Builders Mod for Phoenix or >> > Imprudence? >> > _______________________________________________ >> > Policies and (un)subscribe information available here: >> > http://wiki.secondlife.com/wiki/OpenSource-Dev >> > Please read the policies before posting to keep unmoderated posting >> privileges >> >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/OpenSource-Dev >> Please read the policies before posting to keep unmoderated posting >> privileges >> > > > > -- > v i r t u a l w o r l d e n t h u s i a s t > -- http://www.google.com/profiles/s u e z a n n e -- > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101018/aed0c769/attachment.htm From javajoint at gmail.com Mon Oct 18 10:08:51 2010 From: javajoint at gmail.com (Daniel Smith) Date: Mon, 18 Oct 2010 10:08:51 -0700 Subject: [opensource-dev] Fermi Viewer In-Reply-To: References: <000101cb6e50$6b4df020$41e9d060$@org> <20101018005833.GB32331@alinoe.com> <001e01cb6e60$1fe5f0f0$5fb1d2d0$@org> <-574497265938522238@unknownmsgid> <4CBC5932.6080309@beau.org> <4CBC59E0.9050800@streamsense.net> Message-ID: Time out! Whoa ;) There are only so many developers in the community. and there are two streams.. 1.x and 2.x ... and neither, as far as I know, is set up well for plugins... one cul de sac of development would be to go off and do plugins, for, say, imprudence, or phoenix, or kirstens.... or LL.... would be better all around.. for the community to say .. hold up.. how to merge the best of 1.x and 2.x, and have a uniform plugin model... Someone needs to say the C word: Coordination. ok.. back to it guys and gals ;) Daniel (and I didnt say "Unity" once.. although I really think that's worth exploring) On Mon, Oct 18, 2010 at 9:46 AM, Ron Festa wrote: > Visibuild is RealXtend and Naali, not vanilla SL or OpenSIM. Nothing > contributed to that would benefit SL or vanilla OpenSIM especially since > both SL & OS are getting mesh support. > > Ron Festa > Virtual Worlds Admin > Division of Continuing Studies at Rutgers University > PGP key: http://bit.ly/b1ZyhY > Phone: 732-474-8583 > > > > On Mon, Oct 18, 2010 at 10:51 AM, SuezanneC Baskerville < > suezanne at gmail.com> wrote: > >> The "Visibuild" project, at http://visibuild3d.com/, might have some >> bearing on this, possibly. >> >> One might think a viewer and grid that are suposed to be useful for real >> world architecture would have some build tools other than the normal. >> >> It's C++, isn't it, not C? >> >> >> On Mon, Oct 18, 2010 at 9:29 AM, Thomas Grimshaw wrote: >> >>> Imprudence is certainly not stable enough for a viewer targeted at >>> builders. >>> >>> ~Tom >>> >>> On 18/10/2010 15:26, Jamey Fletcher wrote: >>> > Marc Adored wrote: >>> > >>> >> Yes that could be awesome like The Fermi Builders Mod for Phoenix or >>> > Imprudence? >>> > _______________________________________________ >>> > Policies and (un)subscribe information available here: >>> > http://wiki.secondlife.com/wiki/OpenSource-Dev >>> > Please read the policies before posting to keep unmoderated posting >>> privileges >>> >>> _______________________________________________ >>> Policies and (un)subscribe information available here: >>> http://wiki.secondlife.com/wiki/OpenSource-Dev >>> Please read the policies before posting to keep unmoderated posting >>> privileges >>> >> >> >> >> -- >> v i r t u a l w o r l d e n t h u s i a s t >> -- http://www.google.com/profiles/s u e z a n n e -- >> >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/OpenSource-Dev >> Please read the policies before posting to keep unmoderated posting >> privileges >> > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting > privileges > -- Daniel Smith - Sonoma County, California http://daniel.org/resume -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101018/19ba5766/attachment.htm From daleinnisemail at gmail.com Mon Oct 18 10:13:16 2010 From: daleinnisemail at gmail.com (Dale Innis) Date: Mon, 18 Oct 2010 13:13:16 -0400 Subject: [opensource-dev] Fermi Viewer In-Reply-To: <4CBC59E0.9050800@streamsense.net> References: <000101cb6e50$6b4df020$41e9d060$@org> <20101018005833.GB32331@alinoe.com> <001e01cb6e60$1fe5f0f0$5fb1d2d0$@org> <-574497265938522238@unknownmsgid> <4CBC5932.6080309@beau.org> <4CBC59E0.9050800@streamsense.net> Message-ID: On Mon, Oct 18, 2010 at 10:29 AM, Thomas Grimshaw wrote: > ?Imprudence is certainly not stable enough for a viewer targeted at > builders. > > ~Tom Imprudence is no less stable than any other viewer (TP or LL). Every viewer has its fans and its detractors, based I think mostly on what happens to work best on the individual machine. (For instance I have had zero stability problems with Imprudence, including for building, but have never been able to get Kirsten's to work for me usably at all; I imagine there are others with just the opposite experience.) From tom at streamsense.net Mon Oct 18 10:17:33 2010 From: tom at streamsense.net (Thomas Grimshaw) Date: Mon, 18 Oct 2010 18:17:33 +0100 Subject: [opensource-dev] Fermi Viewer In-Reply-To: References: <000101cb6e50$6b4df020$41e9d060$@org> <20101018005833.GB32331@alinoe.com> <001e01cb6e60$1fe5f0f0$5fb1d2d0$@org> <-574497265938522238@unknownmsgid> <4CBC5932.6080309@beau.org> <4CBC59E0.9050800@streamsense.net> Message-ID: <4CBC812D.90100@streamsense.net> I'm certainly not a detractor of the Imprudence project, actually I'm a contributor, but at least on my platform, it's significantly less stable than any other viewer I have installed. Granted, I don't use Kirsten's simply due to a politican disagreement in the past. ~T On 18/10/2010 18:13, Dale Innis wrote: > On Mon, Oct 18, 2010 at 10:29 AM, Thomas Grimshaw wrote: >> Imprudence is certainly not stable enough for a viewer targeted at >> builders. >> >> ~Tom > Imprudence is no less stable than any other viewer (TP or LL). Every > viewer has its fans and its detractors, based I think mostly on what > happens to work best on the individual machine. (For instance I have > had zero stability problems with Imprudence, including for building, > but have never been able to get Kirsten's to work for me usably at > all; I imagine there are others with just the opposite experience.) > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting privileges From lee.ponzu at gmail.com Mon Oct 18 11:34:05 2010 From: lee.ponzu at gmail.com (Ponzu) Date: Mon, 18 Oct 2010 14:34:05 -0400 Subject: [opensource-dev] As a content creator, I would like... Message-ID: These are some vague and undeveloped ideas I am sure a lot of us have had. I wonder if we can make any progress on them? Some consensus on what could/should be done is a place to start. So.. I have some scripts in a folder in my inventory. I would like to save them to my local disk. If I change either my local version or my inventory version, they stay in sync. I can open my textures from in-world in my external editor of choice, modify them, and sync them back to the copies in inventory (or even the copy applied to an object). After I upload my Collada mesh, if I change my local copy, my inventory copy changes by magic. I can save my prim objects and coelesced objects locally, perhaps even directly in my local editing tool of choice. Then modify them, and re-upload them. Local and inventory versions are kept in sync by magic. Far off, I know. Now I need to think about "how?" regards ponz -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101018/9a0fd3e2/attachment-0001.htm From zabb65 at gmail.com Mon Oct 18 11:42:58 2010 From: zabb65 at gmail.com (Zabb65) Date: Mon, 18 Oct 2010 14:42:58 -0400 Subject: [opensource-dev] As a content creator, I would like... In-Reply-To: References: Message-ID: The local script editing and local texture editing has already been done before and were implemented in phoenix. Scripting was done by Katharine and textures were done by Vaalith. I believe Vaalith is waiting for mesh source code so they can begin working on the mesh portion of that. The caveats of this is that there is no way to sync them to existing inventory items or to update existing assets with the new one. So you get a local preview of the changes instantly, but you have to decide to upload a final copy at some point, and then it goes into your inventory. This also costs money. If there was some method of fast temporary uploads they could be previewed by all residents within a sim, but until that is done on the simulator side, there is no way to provide a cohesive element of live previews for other residents in the sim. (They see either of a broken prim/mesh/texture or the old copy that you uploaded.) Until there is a local disk based prim editor. I would not expect there to be the final item. On Mon, Oct 18, 2010 at 14:34, Ponzu wrote: > These are some vague and undeveloped ideas I am sure a lot of us have had. > I wonder if we can make any progress on them?? Some consensus on what > could/should be done is a place to start.? So.. > > > I have some scripts in a folder in my inventory.? I would like to save them > to my local disk.? If I change either my local version or my inventory > version, they stay in sync. > > I can open my textures from in-world in my external editor of choice, modify > them, and sync them back to the copies in inventory (or even the copy > applied to an object). > > After I upload my Collada mesh, if I change my local copy, my inventory copy > changes by magic. > > I?can save my prim objects and coelesced objects locally, perhaps even > directly in my local editing tool of choice.? Then?modify them, and > re-upload them.? Local and inventory versions are kept in sync by magic. > > Far off, I know.? Now I need to think about "how?" > > regards > ponz > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting > privileges > From lee.ponzu at gmail.com Mon Oct 18 11:48:56 2010 From: lee.ponzu at gmail.com (Ponzu) Date: Mon, 18 Oct 2010 14:48:56 -0400 Subject: [opensource-dev] O.O Display name code DROP! In-Reply-To: References: <000001cb6c04$2650ce50$72f26af0$@net> <3B7CD934-CFEF-49AC-A25E-AE9A15E32FA2@gmail.com> <201010171034.47758.Lance.Corrimal@eregion.de> <4CBAB9E3.9060108@gmail.com> Message-ID: Maybe a good step would be to make the logs easy to get to from the viewer itself. A button, or a menu item. Then open out in the default browser on they easy to read format. That might stop term thousand users from freaking out when they open the file using Notepad -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101018/1e92e4eb/attachment.htm From zabb65 at gmail.com Mon Oct 18 12:26:09 2010 From: zabb65 at gmail.com (Zabb65) Date: Mon, 18 Oct 2010 15:26:09 -0400 Subject: [opensource-dev] As a content creator, I would like... In-Reply-To: References: Message-ID: My mistake. Credits to Xotmid then for external script editor. On Mon, Oct 18, 2010 at 15:17, Brandon Husbands wrote: > Actualy I did the external script editor you can use the pre processor to > link in saved scripts from your hard drive > > On Oct 18, 2010 1:43 PM, "Zabb65" wrote: > > The local script editing and local texture editing has already been > done before and were implemented in phoenix. Scripting was done by > Katharine and textures were done by Vaalith. > > I believe Vaalith is waiting for mesh source code so they can begin > working on the mesh portion of that. > > The caveats of this is that there is no way to sync them to existing > inventory items or to update existing assets with the new one. So you > get a local preview of the changes instantly, but you have to decide > to upload a final copy at some point, and then it goes into your > inventory. This also costs money. If there was some method of fast > temporary uploads they could be previewed by all residents within a > sim, but until that is done on the simulator side, there is no way to > provide a cohesive element of live previews for other residents in the > sim. (They see either of a broken prim/mesh/texture or the old copy > that you uploaded.) > > Until there is a local disk based prim editor. I would not expect > there to be the final item. > > On Mon, Oct 18, 2010 at 14:34, Ponzu wrote: >> These are some vague and undeve... > >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/OpenSource-Dev >> Please read the policies before posting to keep unmoderated posting >> privileges >> > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting > privileges From lee.ponzu at gmail.com Mon Oct 18 12:46:54 2010 From: lee.ponzu at gmail.com (Ponzu) Date: Mon, 18 Oct 2010 15:46:54 -0400 Subject: [opensource-dev] As a content creator, I would like... In-Reply-To: References: Message-ID: On Mon, Oct 18, 2010 at 2:42 PM, Zabb65 wrote: > The local script editing and local texture editing has already been > done before and were implemented in phoenix. Scripting was done by > Katharine and textures were done by Vaalith. > > I believe Vaalith is waiting for mesh source code so they can begin > working on the mesh portion of that. > > The caveats of this is that there is no way to sync them to existing > inventory items or to update existing assets with the new one. I like the way you say it has been done already and then explain that it has not yet been done. Of course there are ways to sync them. You could completely rewrite SL to allow it, for example. I don't expect that, but it is still "a way". Anyway, I was more thinking of the user story and what the features would look like. A plan to implement it can wait awhile until "it" is defined. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101018/e2b801c8/attachment.htm From robertltux at gmail.com Mon Oct 18 13:13:30 2010 From: robertltux at gmail.com (Robert Martin) Date: Mon, 18 Oct 2010 16:13:30 -0400 Subject: [opensource-dev] As a content creator, I would like... In-Reply-To: References: Message-ID: I think the only way to do this would be for LL to have (maybe as a Premium benefit) some sort of webstorage to save assets then you would seen to run a sync program to link a local folder to the webstorage (and then to the asset farm) -- Robert L Martin From zabb65 at gmail.com Mon Oct 18 13:31:04 2010 From: zabb65 at gmail.com (Zabb65) Date: Mon, 18 Oct 2010 16:31:04 -0400 Subject: [opensource-dev] As a content creator, I would like... In-Reply-To: References: Message-ID: They have been completed to the point of technical limitations of the platform(AFAIK). I explained the caveats of the technical limitations currently imposed upon them. If all you want is to locally see it. Sure its been done. Otherwise, no, but there is progress that can be built on when the technical limitations are lifted. To do it as you explain it. It would require major updates to the way SL stores and uses assets. On Mon, Oct 18, 2010 at 15:46, Ponzu wrote: > On Mon, Oct 18, 2010 at 2:42 PM, Zabb65 wrote: >> >> The local script editing and local texture editing has already been >> done before and were implemented in phoenix. Scripting was done by >> Katharine and textures were done by Vaalith. >> >> I believe Vaalith is waiting for mesh source code so they can begin >> working on the mesh portion of that. >> >> The caveats of this is that there is no way to sync them to existing >> inventory items or to update existing assets with the new one. > > > I?like the way you say it has been done already?and then explain?that it has > not yet been done.??Of course there are ways to sync them.? You could > completely rewrite SL to allow it, for example.? I don't expect that, but it > is still "a way". > > Anyway, I was more thinking of the user story and?what the features would > look like.? A plan to implement it can wait awhile until "it" is defined. > > From akanevsky at productengine.com Mon Oct 18 15:56:56 2010 From: akanevsky at productengine.com (Anya Kanevsky) Date: Mon, 18 Oct 2010 15:56:56 -0700 Subject: [opensource-dev] Daily Scrum Summary - Monday, October 18 Message-ID: https://wiki.secondlife.com/wiki/Snowstorm_Daily_Scrum_Archive Date: Mon Oct 18 == GENERAL NOTES == * Merge Monkey of the Day: Oz == DAILY SCRUM == === Merov === PAST * STORM-104: kdu upgrade: More cleanup before pushing on dev repo. Emailed Oz on licensing issues on some files. * STORM-406: Follow up on STORM-137 (fmod changes): looked into this and will pull Boroondas change I think. Need to update build wiki. FUTURE * STORM-104: kdu upgrade: Finish that. * STORM-105 : Perf decompression: put new data out, check the work done by opensource-dev community on similar tests. IMPEDIMENTS * Latest KDU bits ==Oz Linden== PAST * Merge Monkey ** returned STORM-294 (failed to compile in TeamCity) FUTURE * Merge Monkey ** Draining Snowstorm Integration queue ** Would like to trade this off again after today * More changes to develop site * Submit proposal for WEB-1560 IMPEDIMENTS * none === Q Linden=== PAST * OOO for health * some viewer-beta work * risk analysis FUTURE * triage * beta * code if I can do it IMPEDIMENTS * none === Esbee Linden==== PAST * Viewer 2.2 Release prep * VWR triage * System requirements analysis * Learning Python * Drafting Viewer 2.2 release blog post FUTURE * Write Viewer 2.2 Release blog post * Systems requirements analysis * VWR Triage * Viewer 2.2 Release * Prep for Sprint 6 IMPEDIMENTS * None === Paul ProductEngine=== PAST: * STORM-293 (Friend permissions icons overlap long names on 'My Friends' tab) ** Fixed. FUTURE: * STORM-293 (Friend permissions icons overlap long names on 'My Friends' tab) ** Carefully test before pulling to bitbucket IMPEDIMENTS: * none === Seth Productengine === PAST: * BUG (STORM-263) Cog button in lower-left of sidebar panel does not close popup menu on second click ** Found more issues in the fix. ** Posted fix refactoring to the Review Board. FUTURE: * BUG (STORM-263) Cog button in lower-left of sidebar panel does not close popup menu on second click ** Some issues still remain unresolved. * BUG (STORM-296) Cursor doesn't change when trying to drag and drop non-landmark items into Favorites folder * BUG (STORM-303) Favorites folder content isn't refreshed while re-ordering landmaks ** Estimated: 4-6 hours. IMPEDIMENTS: * none === Andrew Productengine === PAST: * Bug STORM-322 (Group Member Search: gives more entries then the search string suggests) ** WIP. Almost fixed - works for uncached names well, but slower for cached, resolving it. Will finish on Monday and test on Vadim's system to estimate performance, estimate- 4 hours. * Major bug STORM-402 (People you interacted via IM chat floater are not shown in Recent tab) ** Moved to storm, investigated a little. Found the probable place where it occurs. FUTURE: * Bug STORM-322 (Group Member Search: gives more entries then the search string suggests). * Major bug STORM-402 (People you interacted via IM chat floater are not shown in Recent tab). IMPEDIMENTS: * none === Vadim Productengine === PAST: * Task STORM-386 (URL-name of object is shown as a hyperlink in the nearby chat console "new message" hint): ** Implemented. * Bug STORM-263 (Cog button in lower-left of sidebar panel does not close popup menu on second click): ** Reviewed fix. * Bug STORM-390 ("Place Profile" appears instead of "Resident Profile" after clicking on user name in NearBy Chat Toast): ** Investigated, found an unexpected reason (a trivial and safe fix of STORM-358 that triggered a nasty bug in textbox). FUTURE: * Fix STORM-390: ETA 4h. IMPEDIMENTS: * STORM-297 needs input From sllists at boroon.dasgupta.ch Tue Oct 19 07:05:41 2010 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Tue, 19 Oct 2010 16:05:41 +0200 Subject: [opensource-dev] Stuff I'd like to see in the coming sprint Message-ID: <4CBDA5B5.1070601@boroon.dasgupta.ch> Heya Sprint planning meeting is later today, so I thought it'd be good to list some issues that I think should be tackled soon: Low hanging fruits VWR-12984 Water flickers and disappears in patches * Very annoying and high-voted bug, especially apparent in skyboxes * Has been fixed in Snowglobe 1 half a year ago * Fix has been ported to Snowglobe 2 this summer (see SNOW-643 ) * Merov ported the fix to viewer-development recently, so the code 'only' needs some review. (The change is huge, though.) VWR-19643 / STORM-312 linux libndofdev version <= 0.2 incompatible to kernel >=2.6.33 * This has been fixed upstream (linux libndofdev version 0.3), so just using the newer library version will resolve this. * The upstream fix is o a small and easy to understand change (thus low-risk) o backwards compatible (will continue working with kernels <= 2.6.32) o well tested (I'm using it for months now) * Please note that ---while serving the same purpose--- linux libndofdev is a different project than the windows/mac library of the same name, and thus has different version numbers. VWR-23459 Viewer compiled against Boost-1.42 crashes when certain command line options are given * Fixed in Snowglobe 1 and 2 this summer (see SNOW-626 ) * Fix already ported to viewer-development (needs testing and review, but the change is small) * As far as I know, this is the only thing left for viewer-development to become fully compatible with Boost 1.42 * Fix is backwards compatible Features I'd personally would like to work on VWR-22044 Option to inline Navigation Bar into Menu Bar * Needs product manager approval VWR-23306 Detect UI skins at runtime * Needs some discussion: As skins can change functionality (to some extend) or change how/where certain functionality is accessible, we need ways to avoid this feature to become a major problem for customer support. * Some code by Robin Cornelius that's related to this has been annexed by some LL-internal project and she was asked not to publish it to avoid merge problems. In order to avoid duplication of efforts (and probably even worse merge problems), can this project please be opened up? If not, it'd be good to release at least sufficient information to make some collaboration on this topic possible. (no particular jira issue yet) Coding Standard application / code cleanup Our current code still violates our own coding standard a lot. Then there is unnecessary code (like derived classes re-implementing inherited methods in the exact same way the base class already implemented it) and maybe even still dead code (got rare, I think). I'll file jira issues for stuff like this as I get to do it. Could issues of this sort be allowed to be added to the current sprint list even during a sprint? It makes little sense to have such changes pile up until the respective next sprint is started. (no jira issue) Improve the Coding Standard What's the process for changing the coding standard? Sure, I could just edit the wiki page, but because all will have to follow it, making substantial changes needs consensus and warrants some discussion. Cheers, Boroondas -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101019/f80c2b96/attachment-0001.htm From angel_of_crimson at hotmail.com Tue Oct 19 07:24:26 2010 From: angel_of_crimson at hotmail.com (Erin Mallory) Date: Tue, 19 Oct 2010 10:24:26 -0400 Subject: [opensource-dev] Stuff I'd like to see in the coming sprint In-Reply-To: <4CBDA5B5.1070601@boroon.dasgupta.ch> References: <4CBDA5B5.1070601@boroon.dasgupta.ch> Message-ID: I'd also like to see some of the siezure causing issues addressed (like disabling toasts). I'd also like to see some of the ui needs for content creators addressed. (like at the very least the ability to edit/create clothing by right clicking the avatar, fixing edit clothing from the inventory window to automatically wear and edit clothing not worn, and adding upload back to file menu so its easier to find and faster to access). I don't think i can make the meeting, but I'm begging these issues PLEASE make it into this sprint. Date: Tue, 19 Oct 2010 16:05:41 +0200 From: sllists at boroon.dasgupta.ch To: oz at lindenlab.com; esbee at lindenlab.com CC: opensource-dev at lists.secondlife.com Subject: [opensource-dev] Stuff I'd like to see in the coming sprint Heya Sprint planning meeting is later today, so I thought it'd be good to list some issues that I think should be tackled soon: Low hanging fruits VWR-12984 Water flickers and disappears in patches Very annoying and high-voted bug, especially apparent in skyboxes Has been fixed in Snowglobe 1 half a year ago Fix has been ported to Snowglobe 2 this summer (see SNOW-643) Merov ported the fix to viewer-development recently, so the code 'only' needs some review. (The change is huge, though.) VWR-19643 / STORM-312 linux libndofdev version <= 0.2 incompatible to kernel >=2.6.33 This has been fixed upstream (linux libndofdev version 0.3), so just using the newer library version will resolve this. The upstream fix is a small and easy to understand change (thus low-risk) backwards compatible (will continue working with kernels <= 2.6.32) well tested (I'm using it for months now) Please note that ?while serving the same purpose? linux libndofdev is a different project than the windows/mac library of the same name, and thus has different version numbers. VWR-23459 Viewer compiled against Boost-1.42 crashes when certain command line options are given Fixed in Snowglobe 1 and 2 this summer (see SNOW-626) Fix already ported to viewer-development (needs testing and review, but the change is small) As far as I know, this is the only thing left for viewer-development to become fully compatible with Boost 1.42 Fix is backwards compatible Features I'd personally would like to work on VWR-22044 Option to inline Navigation Bar into Menu Bar Needs product manager approval VWR-23306 Detect UI skins at runtime Needs some discussion: As skins can change functionality (to some extend) or change how/where certain functionality is accessible, we need ways to avoid this feature to become a major problem for customer support. Some code by Robin Cornelius that's related to this has been annexed by some LL-internal project and she was asked not to publish it to avoid merge problems. In order to avoid duplication of efforts (and probably even worse merge problems), can this project please be opened up? If not, it'd be good to release at least sufficient information to make some collaboration on this topic possible. (no particular jira issue yet) Coding Standard application / code cleanup Our current code still violates our own coding standard a lot. Then there is unnecessary code (like derived classes re-implementing inherited methods in the exact same way the base class already implemented it) and maybe even still dead code (got rare, I think). I'll file jira issues for stuff like this as I get to do it. Could issues of this sort be allowed to be added to the current sprint list even during a sprint? It makes little sense to have such changes pile up until the respective next sprint is started. (no jira issue) Improve the Coding Standard What's the process for changing the coding standard? Sure, I could just edit the wiki page, but because all will have to follow it, making substantial changes needs consensus and warrants some discussion. Cheers, Boroondas _______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101019/564a3a72/attachment.htm From oz at lindenlab.com Tue Oct 19 07:41:36 2010 From: oz at lindenlab.com (Oz Linden (Scott Lawrence)) Date: Tue, 19 Oct 2010 10:41:36 -0400 Subject: [opensource-dev] Stuff I'd like to see in the coming sprint In-Reply-To: <4CBDA5B5.1070601@boroon.dasgupta.ch> References: <4CBDA5B5.1070601@boroon.dasgupta.ch> Message-ID: <4CBDAE20.1000008@lindenlab.com> > > > VWR-12984 Water > flickers and disappears in patches > > * Very annoying and high-voted bug, especially apparent in skyboxes > * Has been fixed in Snowglobe 1 half a year ago > * Fix has been ported to Snowglobe 2 this summer (see SNOW-643 > ) > * Merov ported the fix to viewer-development recently, so the code > 'only' needs some review. (The change is huge, though.) > > > > I'm not seeing this in Second Life 2.2.1 (212292) Second Life Development - are we sure it wasn't fixed by the other (and much simpler) water flicker fix? In any event, nothing with a patch that large (and which affects code shared with the simulator) counts as "low hanging fruit", however important the problem is. As I've mentioned before, there is an effort under way to split out the code that is shared between viewer and simulator into its own repository so that it can be better managed and evolved in a more coordinated way. That should be visible in the open source within a month or so, I think. My own opinion is that considering changes as large as this one that affects that code should be deferred until after that change. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101019/899588ec/attachment.htm From wolfpup67 at earthlink.net Tue Oct 19 08:34:31 2010 From: wolfpup67 at earthlink.net (WolfPup Lowenhar) Date: Tue, 19 Oct 2010 11:34:31 -0400 Subject: [opensource-dev] Stuff I'd like to see in the coming sprint In-Reply-To: References: <4CBDA5B5.1070601@boroon.dasgupta.ch> Message-ID: <001201cb6fa3$20540240$60fc06c0$@net> There is already a STORM issue relating to the toasts issue. The JIRA is here: https://jira.secondlife.com/browse/STORM-255 This should be in this sprint as it was ready for the last one till it was switched to a bug killing sprint to get the beta out to release. From: opensource-dev-bounces at lists.secondlife.com [mailto:opensource-dev-bounces at lists.secondlife.com] On Behalf Of Erin Mallory Sent: Tuesday, October 19, 2010 10:24 AM To: sllists at boroon.dasgupta.ch; oz at lindenlab.com; esbee at lindenlab.com Cc: opensource-dev at lists.secondlife.com Subject: Re: [opensource-dev] Stuff I'd like to see in the coming sprint I'd also like to see some of the siezure causing issues addressed (like disabling toasts). I'd also like to see some of the ui needs for content creators addressed. (like at the very least the ability to edit/create clothing by right clicking the avatar, fixing edit clothing from the inventory window to automatically wear and edit clothing not worn, and adding upload back to file menu so its easier to find and faster to access). I don't think i can make the meeting, but I'm begging these issues PLEASE make it into this sprint. _____ Date: Tue, 19 Oct 2010 16:05:41 +0200 From: sllists at boroon.dasgupta.ch To: oz at lindenlab.com; esbee at lindenlab.com CC: opensource-dev at lists.secondlife.com Subject: [opensource-dev] Stuff I'd like to see in the coming sprint Heya Sprint planning meeting is later today, so I thought it'd be good to list some issues that I think should be tackled soon: Low hanging fruits VWR-12984 Water flickers and disappears in patches * Very annoying and high-voted bug, especially apparent in skyboxes * Has been fixed in Snowglobe 1 half a year ago * Fix has been ported to Snowglobe 2 this summer (see SNOW-643 ) * Merov ported the fix to viewer-development recently, so the code 'only' needs some review. (The change is huge, though.) VWR-19643 / STORM-312 linux libndofdev version <= 0.2 incompatible to kernel >=2.6.33 * This has been fixed upstream (linux libndofdev version 0.3), so just using the newer library version will resolve this. * The upstream fix is * a small and easy to understand change (thus low-risk) * backwards compatible (will continue working with kernels <= 2.6.32) * well tested (I'm using it for months now) * Please note that -while serving the same purpose- linux libndofdev is a different project than the windows/mac library of the same name, and thus has different version numbers. VWR-23459 Viewer compiled against Boost-1.42 crashes when certain command line options are given * Fixed in Snowglobe 1 and 2 this summer (see SNOW-626 ) * Fix already ported to viewer-development (needs testing and review, but the change is small) * As far as I know, this is the only thing left for viewer-development to become fully compatible with Boost 1.42 * Fix is backwards compatible Features I'd personally would like to work on VWR-22044 Option to inline Navigation Bar into Menu Bar * Needs product manager approval VWR-23306 Detect UI skins at runtime * Needs some discussion: As skins can change functionality (to some extend) or change how/where certain functionality is accessible, we need ways to avoid this feature to become a major problem for customer support. * Some code by Robin Cornelius that's related to this has been annexed by some LL-internal project and she was asked not to publish it to avoid merge problems. In order to avoid duplication of efforts (and probably even worse merge problems), can this project please be opened up? If not, it'd be good to release at least sufficient information to make some collaboration on this topic possible. (no particular jira issue yet) Coding Standard application / code cleanup Our current code still violates our own coding standard a lot. Then there is unnecessary code (like derived classes re-implementing inherited methods in the exact same way the base class already implemented it) and maybe even still dead code (got rare, I think). I'll file jira issues for stuff like this as I get to do it. Could issues of this sort be allowed to be added to the current sprint list even during a sprint? It makes little sense to have such changes pile up until the respective next sprint is started. (no jira issue) Improve the Coding Standard What's the process for changing the coding standard? Sure, I could just edit the wiki page, but because all will have to follow it, making substantial changes needs consensus and warrants some discussion. Cheers, Boroondas _______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges _____ No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1136 / Virus Database: 422/3206 - Release Date: 10/19/10 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101019/0a247660/attachment-0001.htm From sllists at boroon.dasgupta.ch Tue Oct 19 09:29:08 2010 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Tue, 19 Oct 2010 18:29:08 +0200 Subject: [opensource-dev] VWR-12984 Water flickers and disappears in patches (was: Stuff I'd like to see in the coming sprint) In-Reply-To: <4CBDAE20.1000008@lindenlab.com> References: <4CBDA5B5.1070601@boroon.dasgupta.ch> <4CBDAE20.1000008@lindenlab.com> Message-ID: <4CBDC754.2030709@boroon.dasgupta.ch> On 10/19/2010 04:41 PM, Oz Linden (Scott Lawrence) wrote: >> >> >> VWR-12984 >> Water flickers and disappears in patches >> >> * Very annoying and high-voted bug, especially apparent in skyboxes >> * Has been fixed in Snowglobe 1 half a year ago >> * Fix has been ported to Snowglobe 2 this summer (see SNOW-643 >> ) >> * Merov ported the fix to viewer-development recently, so the >> code 'only' needs some review. (The change is huge, though.) >> > > I'm not seeing this in Second Life 2.2.1 (212292) Second Life Development Have you tried the repro? (I've put a platform back at http://slurl.com/secondlife/Hippotropolis/220/164/1001, so the repro can be performed again.) I can still reproduce this with current viewer-development. > are we sure it wasn't fixed by the other (and much simpler) water > flicker fix? I am sure. While the symptoms of VWR-12984 and STORM-306 were similar, the causes were very different and so are the fixes. > In any event, nothing with a patch that large (and which affects code > shared with the simulator) counts as "low hanging fruit", however > important the problem is. Fair enough, but it's certainly much lower hanging than before Merov ported it. > As I've mentioned before, there is an effort under way to split out > the code that is shared between viewer and simulator into its own > repository so that it can be better managed and evolved in a more > coordinated way. [...] My own opinion is that considering changes as > large as this one that affects that code should be deferred until > after that change. Is this the case for this fix? While the amount of changed code is huge, I'd assume it's mostly if not completely viewer-only parts that get altered. Though, not knowing the server source, I cannot be certain. I guess the indra/newview directory is viewer-only. I don't know about indra/llrender, but I don't see any apparent reason why the server code would rely on that. > That should be visible in the open source within a month or so, I think. Do we have any volunteers to forward-port the fix /again/ after that time? And no, as much as I'd like to see this bug fixed, I'm not volunteering for that task. Cheers, Boroondas -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101019/4efc2c93/attachment.htm From josh at lindenlab.com Tue Oct 19 09:42:38 2010 From: josh at lindenlab.com (Joshua Bell) Date: Tue, 19 Oct 2010 09:42:38 -0700 Subject: [opensource-dev] Stuff I'd like to see in the coming sprint In-Reply-To: <4CBDA5B5.1070601@boroon.dasgupta.ch> References: <4CBDA5B5.1070601@boroon.dasgupta.ch> Message-ID: On Tue, Oct 19, 2010 at 7:05 AM, Boroondas Gupte wrote: > > VWR-23306 Detect UI skins > at runtime > > - Needs some discussion: As skins can change functionality (to some > extend) or change how/where certain functionality is accessible, we need > ways to avoid this feature to become a major problem for customer support. > - Some code by Robin Cornelius that's related to this has been annexed > by some LL-internal project and she was asked not to publish it to avoid > merge problems. In order to avoid duplication of efforts (and probably even > worse merge problems), can this project please be opened up? If not, it'd be > good to release at least sufficient information to make some collaboration > on this topic possible. > > We hope to land the set of changes including this work in viewer-development within the next month or so. It's based off of viewer-development and we're tracking it closely, so we do not expect there to be significant merge problems. The changes are being wrangled part of one of those few projects that we are not doing completely in the open, and I can't comment further on the "why" of that. That said, I can state that the changes are pretty mundane and won't suddenly appear in a production viewer without going through viewer-development first - they'll land there just like any other patches and work their way through the normal release process. -- Josh -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101019/976c9a6b/attachment.htm From nexisentertainment at gmail.com Tue Oct 19 11:41:33 2010 From: nexisentertainment at gmail.com (Rob Nelson) Date: Tue, 19 Oct 2010 11:41:33 -0700 Subject: [opensource-dev] Stuff I'd like to see in the coming sprint In-Reply-To: References: <4CBDA5B5.1070601@boroon.dasgupta.ch> Message-ID: <4CBDE65D.3000206@gmail.com> As an epileptic, I agree. Thank God for Keppra (and the ability to still go back to Snowglobe 1.x). Rob On 10/19/2010 7:24 AM, Erin Mallory wrote: > I'd also like to see some of the siezure causing issues addressed > (like disabling toasts). -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101019/929b6bae/attachment.htm From malachi at tamzap.com Tue Oct 19 11:58:17 2010 From: malachi at tamzap.com (malachi) Date: Tue, 19 Oct 2010 14:58:17 -0400 Subject: [opensource-dev] Stuff I'd like to see in the coming sprint In-Reply-To: <4CBDAE20.1000008@lindenlab.com> References: <4CBDA5B5.1070601@boroon.dasgupta.ch> <4CBDAE20.1000008@lindenlab.com> Message-ID: I would also like to see (since there are so many new changes to the server.....) issues like VWR-11683 or any other new scripting functions that will reduce lag and speed up efficiency for developers. i dont think focusing only on functions and features that are going to ADD to lag should be going on here. i think as a community we should be working on ways to reduce the lag as well. any chance that someone will drop the few lines of code into the new server version and spit out the keys to scripts or do we all have to keep using tpv clients and 65535^3 prims to scan regions? -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ From dave at meadowlakearts.com Tue Oct 19 17:07:22 2010 From: dave at meadowlakearts.com (Dave Booth) Date: Tue, 19 Oct 2010 19:07:22 -0500 Subject: [opensource-dev] Stuff I'd like to see in the coming sprint In-Reply-To: References: <4CBDA5B5.1070601@boroon.dasgupta.ch> <4CBDAE20.1000008@lindenlab.com> Message-ID: <4CBE32BA.9050801@meadowlakearts.com> On 10/19/2010 13:58, malachi wrote: > I would also like to see (since there are so many new changes to the > server.....) > > issues like > > VWR-11683 > > > or any other new scripting functions that will reduce lag and speed up > efficiency for developers. i dont think focusing only on functions and > features that are going to ADD to lag should be going on here. i think as > a community we should be working on ways to reduce the lag as well. > > any chance that someone will drop the few lines of code into the new > server version and spit out the keys to scripts or do we all have to keep > using tpv clients and 65535^3 prims to scan regions? I love that idea but since its a scripting enhancement then apart from the script editor floaters syntax highlighting thats purely a server-side change. It's not something the snowstorm team or any of us can work on since its not in the opensource code. Sad to say that jira is likely going to end up closed as misfiled, because if its a scripting thing it aint a VWR project issue. You can count on my voice adding to you advocating for it as a server enhancement, but in its current jira location its likely gonna sink without trace. From kelly at lindenlab.com Tue Oct 19 19:53:22 2010 From: kelly at lindenlab.com (Kelly Linden) Date: Tue, 19 Oct 2010 19:53:22 -0700 Subject: [opensource-dev] Stuff I'd like to see in the coming sprint In-Reply-To: <4CBE32BA.9050801@meadowlakearts.com> References: <4CBDA5B5.1070601@boroon.dasgupta.ch> <4CBDAE20.1000008@lindenlab.com> <4CBE32BA.9050801@meadowlakearts.com> Message-ID: On Tue, Oct 19, 2010 at 5:07 PM, Dave Booth wrote: > On 10/19/2010 13:58, malachi wrote: > > I would also like to see (since there are so many new changes to the > > server.....) > > > > issues like > > > > VWR-11683 > > > > > > or any other new scripting functions that will reduce lag and speed up > > efficiency for developers. i dont think focusing only on functions and > > features that are going to ADD to lag should be going on here. i think as > > a community we should be working on ways to reduce the lag as well. > > > > any chance that someone will drop the few lines of code into the new > > server version and spit out the keys to scripts or do we all have to keep > > using tpv clients and 65535^3 prims to scan regions? > > I love that idea but since its a scripting enhancement then apart from > the script editor floaters syntax highlighting thats purely a > server-side change. It's not something the snowstorm team or any of us > can work on since its not in the opensource code. Sad to say that jira > is likely going to end up closed as misfiled, because if its a scripting > thing it aint a VWR project issue. You can count on my voice adding to > you advocating for it as a server enhancement, but in its current jira > location its likely gonna sink without trace. > > I've moved it to SVC, no need for it to be closed or to sink without a trace. But yes, it is a service and not a viewer issue. I have even commented on it already. - Kelly -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101019/86dbd3cf/attachment.htm From xotmid at gmail.com Tue Oct 19 21:21:07 2010 From: xotmid at gmail.com (Brandon Husbands) Date: Tue, 19 Oct 2010 23:21:07 -0500 Subject: [opensource-dev] Tools of the trade. Message-ID: I understand that Licensing costs money but I do have a question. It is almost 2011 That's 6 years after Visual Studio was released. I also know there are patches floating around for cmake and various other things that make VS2k8 compile properly. So I ask this, when is LL going to drop vs2k5 as the "Supported" MS compiler? With c++0x Standard actually being implimented with some methods in vs2k8 and mostly in 2k10. Is it not time to really update our default toolset? At least lets get the patches in to fix 2k8, and get it officially supported. I despise 2k5, 28k is pretty solid now. 2k10 seems to be the vista of IDE's maybe 2k11 will be the win 7 =) Mostly due to the project based settings instead of global IDE includes which is a PITA even with Cmake. Id like to get LL's response on how long are we going to be stuck with 2k5 as the "official" compiler/ide. -- ------------------------------------------------------------------------------------------------------------------------------- This email is a private and confidential communication. Any use of email may be subject to the laws and regulations of the United States. You may not Repost, Distribute nor reproduce any content of this message. ------------------------------------------------------------------------------------------------------------------------------- ------------------------------------------------------------------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101019/fe7e757c/attachment.htm From trilobyte550m at gmail.com Wed Oct 20 00:17:16 2010 From: trilobyte550m at gmail.com (Trilo Byte) Date: Wed, 20 Oct 2010 00:17:16 -0700 Subject: [opensource-dev] Project-MESH viewer In-Reply-To: <4CB9BE52.6070401@lindenlab.com> References: <4CB9BE52.6070401@lindenlab.com> Message-ID: <841CA309-B6A8-4A2B-B2F1-C8B7EEA90605@gmail.com> Big fail there, Oz. None of the machines I've tested on have working anti-aliasing (on the Mac client), either in the subsequent developer snapshots or the official release you guys let get out the door. TriloByte On Oct 16, 2010, at 8:01 AM, Oz Linden (Scott Lawrence) wrote: > On 2010-10-15 18:00, Trilo Byte wrote: >> But on the flipside, the Project MESH viewer has working shadows for nVidia GPU's on Mac (never happened before on any known config), and anti-aliasing's fixed. If we could get that bit out of the mesh viewer and into the 2.2 pipeline, we'd really be in great shape IMO. > > The AA fix is in the 2.2 pipeline (I did that merge) ... not sure about > the other (since I don't know which change that was). > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting privileges From secret.argent at gmail.com Wed Oct 20 02:29:19 2010 From: secret.argent at gmail.com (Argent Stonecutter) Date: Wed, 20 Oct 2010 04:29:19 -0500 Subject: [opensource-dev] Fermi Viewer In-Reply-To: References: <000101cb6e50$6b4df020$41e9d060$@org> <20101018005833.GB32331@alinoe.com> <001e01cb6e60$1fe5f0f0$5fb1d2d0$@org> <-574497265938522238@unknownmsgid> <4CBC5932.6080309@beau.org> <4CBC59E0.9050800@streamsense.net> Message-ID: <8F7C71E6-7CA1-4274-B2C4-F65EC3C06D61@gmail.com> On 2010-10-18, at 12:08, Daniel Smith wrote: > would be better all around.. for the community to say .. hold up.. how to merge the best of 1.x and 2.x We already have that. It's called 1.x. From secret.argent at gmail.com Wed Oct 20 02:39:17 2010 From: secret.argent at gmail.com (Argent Stonecutter) Date: Wed, 20 Oct 2010 04:39:17 -0500 Subject: [opensource-dev] Stuff I'd like to see in the coming sprint In-Reply-To: <4CBDA5B5.1070601@boroon.dasgupta.ch> References: <4CBDA5B5.1070601@boroon.dasgupta.ch> Message-ID: <0C91AC7E-C06A-42B2-9546-9FF1F79EF1F5@gmail.com> On 2010-10-19, at 09:05, Boroondas Gupte wrote: > Heya > > Sprint planning meeting is later today, so I thought it'd be good to list some issues that I think should be tackled soon: > Low hanging fruits https://jira.secondlife.com/browse/VWR-17011 From esbee at lindenlab.com Wed Oct 20 06:54:56 2010 From: esbee at lindenlab.com (Sarah (Esbee) Hutchinson) Date: Wed, 20 Oct 2010 09:54:56 -0400 Subject: [opensource-dev] Esbee's office hours canceled today. Message-ID: I'll be out of the office this morning, so my office hours will be canceled for this week. We'll resume next week! Best, Esbee -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101020/20034b3e/attachment.htm From wolfpup67 at earthlink.net Wed Oct 20 06:56:01 2010 From: wolfpup67 at earthlink.net (WolfPup Lowenhar) Date: Wed, 20 Oct 2010 09:56:01 -0400 Subject: [opensource-dev] FW: STORM-255 Project Build posted Message-ID: <006301cb705e$87e416a0$97ac43e0$@net> Thank you Oz for doing that. Fellow OS dev's please let me know of any changes that might be need. And also translations would be helpful as well. From: Oz Linden (Scott Lawrence) [mailto:oz at lindenlab.com] Sent: Tuesday, October 19, 2010 10:46 PM To: Esbee Linden (Sarah Hutchinson); WolfPup Lowenhar Subject: STORM-255 Project Build posted I've posted a set of Developer builds at https://wiki.secondlife.com/wiki/Downloading_test_builds#Developer_Builds that contain WolfPups changes for STORM-255 (disable group and im toasts). I've pushed the corresponding sources to ssh://hg at bitbucket.org/oz_linden/storm-255 (WolfPup - you have write access to that repo). Perhaps we can use these to begin a review and discussion of how to resolve this Story. _____ No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1136 / Virus Database: 422/3208 - Release Date: 10/20/10 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101020/8d715d3e/attachment-0001.htm From robertltux at gmail.com Wed Oct 20 07:42:31 2010 From: robertltux at gmail.com (Robert Martin) Date: Wed, 20 Oct 2010 10:42:31 -0400 Subject: [opensource-dev] FW: STORM-255 Project Build posted In-Reply-To: <006301cb705e$87e416a0$97ac43e0$@net> References: <006301cb705e$87e416a0$97ac43e0$@net> Message-ID: On Wed, Oct 20, 2010 at 9:56 AM, WolfPup Lowenhar wrote: > Thank you Oz for doing that. > > > > Fellow OS dev?s please let me know of any changes that might be need. And > also translations would be helpful as well. > > err a bit of a doc bug "Both Linden Lab and Thrid Party Viewers (TPV) may post links " I dunno what a thrid party viewer would be :) -- Robert L Martin From wolfpup67 at earthlink.net Wed Oct 20 08:40:07 2010 From: wolfpup67 at earthlink.net (WolfPup Lowenhar) Date: Wed, 20 Oct 2010 11:40:07 -0400 Subject: [opensource-dev] FW: STORM-255 Project Build posted In-Reply-To: References: <006301cb705e$87e416a0$97ac43e0$@net> Message-ID: <000601cb706d$129482e0$37bd88a0$@net> Third Party Viewer's would be: Pheniox Kristine's Imprudence Basically any viewer that do not say SecondLife. From: Robert Martin [mailto:robertltux at gmail.com] Sent: Wednesday, October 20, 2010 10:43 AM To: WolfPup Lowenhar Cc: OpenSource Mailing List Subject: Re: [opensource-dev] FW: STORM-255 Project Build posted On Wed, Oct 20, 2010 at 9:56 AM, WolfPup Lowenhar wrote: > Thank you Oz for doing that. > > > > Fellow OS dev's please let me know of any changes that might be need. And > also translations would be helpful as well. > > err a bit of a doc bug "Both Linden Lab and Thrid Party Viewers (TPV) may post links " I dunno what a thrid party viewer would be :) -- Robert L Martin _____ No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1136 / Virus Database: 422/3208 - Release Date: 10/20/10 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101020/86c05dbc/attachment.htm From kf6kjg at gmail.com Wed Oct 20 09:12:44 2010 From: kf6kjg at gmail.com (Ricky) Date: Wed, 20 Oct 2010 09:12:44 -0700 Subject: [opensource-dev] FW: STORM-255 Project Build posted In-Reply-To: <000601cb706d$129482e0$37bd88a0$@net> References: <006301cb705e$87e416a0$97ac43e0$@net> <000601cb706d$129482e0$37bd88a0$@net> Message-ID: I do believe WoldPup was pointing out a typo: thrid vs third... Ricky Cron Stardust On Wed, Oct 20, 2010 at 8:40 AM, WolfPup Lowenhar wrote: > Third Party Viewer?s would be: > > > > Pheniox > > Kristine?s > > Imprudence > > > > Basically any viewer that do not say SecondLife. > > > > From: Robert Martin [mailto:robertltux at gmail.com] > Sent: Wednesday, October 20, 2010 10:43 AM > To: WolfPup Lowenhar > Cc: OpenSource Mailing List > Subject: Re: [opensource-dev] FW: STORM-255 Project Build posted > > > > On Wed, Oct 20, 2010 at 9:56 AM, WolfPup Lowenhar > wrote: >> Thank you Oz for doing that. >> >> >> >> Fellow OS dev?s please let me know of any changes that might be need. And >> also translations would be helpful as well. >> >> > err a bit of a doc bug "Both Linden Lab and Thrid Party Viewers (TPV) > may post links " > > I dunno what a thrid party viewer would be :) > -- > Robert L Martin > > ________________________________ > > No virus found in this message. > > Checked by AVG - www.avg.com > Version: 10.0.1136 / Virus Database: 422/3208 - Release Date: 10/20/10 > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting > privileges > From javajoint at gmail.com Wed Oct 20 09:21:35 2010 From: javajoint at gmail.com (Daniel Smith) Date: Wed, 20 Oct 2010 09:21:35 -0700 Subject: [opensource-dev] Fermi Viewer In-Reply-To: <8F7C71E6-7CA1-4274-B2C4-F65EC3C06D61@gmail.com> References: <000101cb6e50$6b4df020$41e9d060$@org> <20101018005833.GB32331@alinoe.com> <001e01cb6e60$1fe5f0f0$5fb1d2d0$@org> <-574497265938522238@unknownmsgid> <4CBC5932.6080309@beau.org> <4CBC59E0.9050800@streamsense.net> <8F7C71E6-7CA1-4274-B2C4-F65EC3C06D61@gmail.com> Message-ID: On Wed, Oct 20, 2010 at 2:29 AM, Argent Stonecutter wrote: > On 2010-10-18, at 12:08, Daniel Smith wrote: > > would be better all around.. for the community to say .. hold up.. how to > merge the best of 1.x and 2.x > > We already have that. It's called 1.x. { "remarkAnswer" : "hee hee - but it doesnt have the two Ms", "theMs" : { "M1": "MOAP", "M2": "MESH" }, } -- Daniel Smith - Sonoma County, California http://daniel.org/resume -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101020/eac5c52f/attachment.htm From malachi at tamzap.com Wed Oct 20 11:20:20 2010 From: malachi at tamzap.com (malachi) Date: Wed, 20 Oct 2010 14:20:20 -0400 Subject: [opensource-dev] Enhanced Script Editor Request Message-ID: Of all the developers who are working on the client someone has to be smart enough to implement this. For you windows developers who are using Visual Studio, When you type a function name and get to the ( point of the function it pops a tip up telling you what is needed to complete this function. I believe it is called intellisense. I could be mistaken. Why can we not have the same type of script editor? An auto complete type of compiler for the editor. As we type in our scripts popups would help us complete what it is we are typing. this would increase speed of script writing, help beginners learn LSL programming faster, and simplify the process. this is just my thoughts. it is already implemented in LSLEditor just figured it could be done in the client as well. -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ From q at lindenlab.com Wed Oct 20 11:33:47 2010 From: q at lindenlab.com (Kent Quirk (Q Linden)) Date: Wed, 20 Oct 2010 14:33:47 -0400 Subject: [opensource-dev] Project-MESH viewer In-Reply-To: <841CA309-B6A8-4A2B-B2F1-C8B7EEA90605@gmail.com> References: <4CB9BE52.6070401@lindenlab.com> <841CA309-B6A8-4A2B-B2F1-C8B7EEA90605@gmail.com> Message-ID: <947BDC5D-EC8A-4A81-94C8-F3E0026221D9@lindenlab.com> So our old version of full-screen antialiasing (FSAA) was causing crashes. We have made changes to the supporting infrastructure for stability; these changes meant that some machines that used to do FSAA no longer could. We had a bug under windows that was causing the new mechanism to break. We fixed that for windows -- but we have another issue on macs. There is code in the mesh viewer that supports FSAA on macs; it's a bit big to pull over easily to viewer-development. It was my fault that I didn't realize that our fix to 2.2 didn't address macs properly until quite late in the release process. We chose to ship without the feature on Macs for this release. Macs are a small subset of our user base, and this feature only affects a subset of those users, and we felt that we should not hold up release for this issue. It's also my fault that I didn't call it out for release noting. I'm sorry about that. We do intend to restore full functioning FSAA on all capable platforms soon, hopefully with 2.3. If this affected you, I apologize. Q On Oct 20, 2010, at 3:17 AM, Trilo Byte wrote: > Big fail there, Oz. None of the machines I've tested on have working anti-aliasing (on the Mac client), either in the subsequent developer snapshots or the official release you guys let get out the door. > > TriloByte > > On Oct 16, 2010, at 8:01 AM, Oz Linden (Scott Lawrence) wrote: > >> On 2010-10-15 18:00, Trilo Byte wrote: >>> But on the flipside, the Project MESH viewer has working shadows for nVidia GPU's on Mac (never happened before on any known config), and anti-aliasing's fixed. If we could get that bit out of the mesh viewer and into the 2.2 pipeline, we'd really be in great shape IMO. >> >> The AA fix is in the 2.2 pipeline (I did that merge) ... not sure about >> the other (since I don't know which change that was). >> >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/OpenSource-Dev >> Please read the policies before posting to keep unmoderated posting privileges > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting privileges From q at lindenlab.com Wed Oct 20 11:43:11 2010 From: q at lindenlab.com (Kent Quirk (Q Linden)) Date: Wed, 20 Oct 2010 14:43:11 -0400 Subject: [opensource-dev] Tools of the trade. In-Reply-To: References: Message-ID: We've been having this discussion internally for some time. There's a lot of friction because a) we have to update lots of developers, and b) we have to rebuild all the libraries and distribute them internally. We've been working on a tool called autobuild which will automate this process; it's almost ready. It should make it lots easier for us as well as opensource developers to get a build up and running, and will centralize the tool decisions so that we can finally upgrade fairly easily. Q On Oct 20, 2010, at 12:21 AM, Brandon Husbands wrote: > I understand that Licensing costs money but I do have a question. It is almost 2011 That's 6 years after Visual Studio was released. > I also know there are patches floating around for cmake and various other things that make VS2k8 compile properly. So I ask this, when is LL going to drop vs2k5 as the "Supported" MS compiler? With c++0x Standard actually being implimented with some methods in vs2k8 and mostly in 2k10. Is it not time to really update our default toolset? > > At least lets get the patches in to fix 2k8, and get it officially supported. I despise 2k5, 28k is pretty solid now. 2k10 seems to be the vista of IDE's maybe 2k11 will be the win 7 =) Mostly due to the project based settings instead of global IDE includes which is a PITA even with Cmake. > > Id like to get LL's response on how long are we going to be stuck with 2k5 as the "official" compiler/ide. > > > > -- > ------------------------------------------------------------------------------------------------------------------------------- > This email is a private and confidential communication. Any use of email may be subject to the laws and regulations of the United States. You may not Repost, Distribute nor reproduce any content of this message. > ------------------------------------------------------------------------------------------------------------------------------- > ------------------------------------------------------------------------------------------------------------------------------- > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting privileges From dave at meadowlakearts.com Wed Oct 20 13:21:39 2010 From: dave at meadowlakearts.com (Dave Booth) Date: Wed, 20 Oct 2010 15:21:39 -0500 Subject: [opensource-dev] Enhanced Script Editor Request In-Reply-To: References: Message-ID: <4CBF4F53.6010202@meadowlakearts.com> On 10/20/2010 13:20, malachi wrote: > Of all the developers who are working on the client someone has to be > smart enough to implement this. > > For you windows developers who are using Visual Studio, When you type a > function name and get to the ( point of the function it pops a tip up > telling you what is needed to complete this function. I believe it is > called intellisense. I could be mistaken. Why can we not have the same > type of script editor? An auto complete type of compiler for the editor. > As we type in our scripts popups would help us complete what it is we are > typing. this would increase speed of script writing, help beginners learn > LSL programming faster, and simplify the process. this is just my > thoughts. it is already implemented in LSLEditor just figured it could be > done in the client as well. hover the mouse over the highlighted function name and you get a tip popup showing the functions prototype. Personally I prefer this to environments where the popup happens automatically - the popup would be a distraction for the functions I use really frequently and never need reminding about their parameters but I'll use the tip to remind myself of the correct parameter order for those I use infrequently. Perhaps this should be a selectable behaviour - Theres already a hook to spot when a function name is typed and highlight it, possibly leverage that and have function tip popups in the editor be on-hover, on-highlight or off? Dave. From kf6kjg at gmail.com Wed Oct 20 13:53:28 2010 From: kf6kjg at gmail.com (Ricky) Date: Wed, 20 Oct 2010 13:53:28 -0700 Subject: [opensource-dev] Enhanced Script Editor Request In-Reply-To: <4CBF4F53.6010202@meadowlakearts.com> References: <4CBF4F53.6010202@meadowlakearts.com> Message-ID: I think the idea here is to have the popup capable of doing auto-completion. This would save a load of time, as well as make it easier to script, IMHO. An alternative would be to expand the usefulness of the code insert dropdown by having it add the parens and properties for events and functions using default values/place holders such as is seen in the hover tips. Ricky Cron Stardust On Wed, Oct 20, 2010 at 1:21 PM, Dave Booth wrote: > On 10/20/2010 13:20, malachi wrote: >> Of all the developers who are working on the client someone has to be >> smart enough to implement this. >> >> For you windows developers who are using Visual Studio, When you type a >> function name and get to the ( point of the function it pops a tip up >> telling you what is needed to complete this function. I believe it is >> called intellisense. I could be mistaken. Why can we not have the same >> type of script editor? An auto complete type of compiler for the editor. >> As we type in our scripts popups would help us complete what it is we are >> typing. this would increase speed of script writing, help beginners learn >> LSL programming faster, and simplify the process. this is just my >> thoughts. it is already implemented in LSLEditor just figured it could be >> done in the client as well. > > hover the mouse over the highlighted function name and you get a tip > popup showing the functions prototype. Personally I prefer this to > environments where the popup happens automatically - the popup would be > a distraction for the functions I use really frequently and never need > reminding about their parameters but I'll use the tip to remind myself > of the correct parameter order for those I use infrequently. Perhaps > this should be a selectable behaviour - Theres already a hook to spot > when a function name is typed and highlight it, possibly leverage that > and have function tip popups in the editor be on-hover, on-highlight or off? > > Dave. > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting privileges > From suezanne at gmail.com Wed Oct 20 15:08:37 2010 From: suezanne at gmail.com (SuezanneC Baskerville) Date: Wed, 20 Oct 2010 17:08:37 -0500 Subject: [opensource-dev] Enhanced Script Editor Request In-Reply-To: References: <4CBF4F53.6010202@meadowlakearts.com> Message-ID: I'd be pleased if the popup tip remained visible somewhere. My short term memory is bad, if there are many parameters I have to make the popup appear more than once. On Wed, Oct 20, 2010 at 3:53 PM, Ricky wrote: > I think the idea here is to have the popup capable of doing > auto-completion. This would save a load of time, as well as make it > easier to script, IMHO. > > An alternative would be to expand the usefulness of the code insert > dropdown by having it add the parens and properties for events and > functions using default values/place holders such as is seen in the > hover tips. > > Ricky > Cron Stardust > > On Wed, Oct 20, 2010 at 1:21 PM, Dave Booth > wrote: > > On 10/20/2010 13:20, malachi wrote: > >> Of all the developers who are working on the client someone has to be > >> smart enough to implement this. > >> > >> For you windows developers who are using Visual Studio, When you type a > >> function name and get to the ( point of the function it pops a tip up > >> telling you what is needed to complete this function. I believe it is > >> called intellisense. I could be mistaken. Why can we not have the same > >> type of script editor? An auto complete type of compiler for the editor. > >> As we type in our scripts popups would help us complete what it is we > are > >> typing. this would increase speed of script writing, help beginners > learn > >> LSL programming faster, and simplify the process. this is just my > >> thoughts. it is already implemented in LSLEditor just figured it could > be > >> done in the client as well. > > > > hover the mouse over the highlighted function name and you get a tip > > popup showing the functions prototype. Personally I prefer this to > > environments where the popup happens automatically - the popup would be > > a distraction for the functions I use really frequently and never need > > reminding about their parameters but I'll use the tip to remind myself > > of the correct parameter order for those I use infrequently. Perhaps > > this should be a selectable behaviour - Theres already a hook to spot > > when a function name is typed and highlight it, possibly leverage that > > and have function tip popups in the editor be on-hover, on-highlight or > off? > > > > Dave. > > _______________________________________________ > > Policies and (un)subscribe information available here: > > http://wiki.secondlife.com/wiki/OpenSource-Dev > > Please read the policies before posting to keep unmoderated posting > privileges > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting > privileges > -- v i r t u a l w o r l d e n t h u s i a s t -- http://www.google.com/profiles/s u e z a n n e -- -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101020/df9c2fbf/attachment.htm From mrfrans at gmail.com Wed Oct 20 15:18:38 2010 From: mrfrans at gmail.com (Frans) Date: Thu, 21 Oct 2010 00:18:38 +0200 Subject: [opensource-dev] Enhanced Script Editor Request In-Reply-To: References: <4CBF4F53.6010202@meadowlakearts.com> Message-ID: I have the same problem as Suezanne. When I use the popup is usually for something longwinded and frequently have to make the popup appear several times. If the popup would appear automatically and I could hit tab,space or enter to have it auto complete that would be perfect. Frans On Thu, Oct 21, 2010 at 12:08 AM, SuezanneC Baskerville wrote: > I'd be pleased if the popup tip remained visible somewhere. My short term > memory is bad, if there are many parameters I have to make the popup appear > more than once. > > > -- > v i r t u a l w o r l d e n t h u s i a s t > -- http://www.google.com/profiles/s u e z a n n e -- > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting > privileges > -- Jeroen Frans Virtual World Technology Specialist @ http://VesuviusGroup.com Second Life: Frans Charming blog about SL @ http://secondslog.blogspot.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101021/00273081/attachment.htm From kf6kjg at gmail.com Wed Oct 20 15:19:02 2010 From: kf6kjg at gmail.com (Ricky) Date: Wed, 20 Oct 2010 15:19:02 -0700 Subject: [opensource-dev] Enhanced Script Editor Request In-Reply-To: References: <4CBF4F53.6010202@meadowlakearts.com> Message-ID: It used to stay up until clicked on or until certain characters were typed... Got in the the way at times, but was quite useful. On Wed, Oct 20, 2010 at 3:08 PM, SuezanneC Baskerville wrote: > I'd be pleased if the popup tip remained visible somewhere. My short term > memory is bad, if there are many parameters I have to make the popup appear > more than once. > > On Wed, Oct 20, 2010 at 3:53 PM, Ricky wrote: >> >> I think the idea here is to have the popup capable of doing >> auto-completion. ?This would save a load of time, as well as make it >> easier to script, IMHO. >> >> An alternative would be to expand the usefulness of the code insert >> dropdown by having it add the parens and properties for events and >> functions using default values/place holders such as is seen in the >> hover tips. >> >> Ricky >> Cron Stardust >> >> On Wed, Oct 20, 2010 at 1:21 PM, Dave Booth >> wrote: >> > On 10/20/2010 13:20, malachi wrote: >> >> Of all the developers who are working on the client someone has to be >> >> smart enough to implement this. >> >> >> >> For you windows developers who are using Visual Studio, When you type a >> >> function name and get to the ( point of the function it pops a tip up >> >> telling you what is needed to complete this function. I believe it is >> >> called intellisense. I could be mistaken. Why can we not have the same >> >> type of script editor? An auto complete type of compiler for the >> >> editor. >> >> As we type in our scripts popups would help us complete what it is we >> >> are >> >> typing. this would increase speed of script writing, help beginners >> >> learn >> >> LSL programming faster, and simplify the process. this is just my >> >> thoughts. it is already implemented in LSLEditor just figured it could >> >> be >> >> done in the client as well. >> > >> > hover the mouse over the highlighted function name and you get a tip >> > popup showing the functions prototype. Personally I prefer this to >> > environments where the popup happens automatically - the popup would be >> > a distraction for the functions I use really frequently and never need >> > reminding about their parameters but I'll use the tip to remind myself >> > of the correct parameter order for those I use infrequently. Perhaps >> > this should be a selectable behaviour - Theres already a hook to spot >> > when a function name is typed and highlight it, possibly leverage that >> > and have function tip popups in the editor be on-hover, on-highlight or >> > off? >> > >> > Dave. >> > _______________________________________________ >> > Policies and (un)subscribe information available here: >> > http://wiki.secondlife.com/wiki/OpenSource-Dev >> > Please read the policies before posting to keep unmoderated posting >> > privileges >> > >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/OpenSource-Dev >> Please read the policies before posting to keep unmoderated posting >> privileges > > > > -- > v i r t u a l?? w o r l d?? e n t h u s i a s t > -- http://www.google.com/profiles/s u e z a n n e -- > From lee.ponzu at gmail.com Wed Oct 20 15:39:00 2010 From: lee.ponzu at gmail.com (Ponzu) Date: Wed, 20 Oct 2010 18:39:00 -0400 Subject: [opensource-dev] Enhanced Script Editor Request In-Reply-To: References: <4CBF4F53.6010202@meadowlakearts.com> Message-ID: Make the script editor use vi. On Wed, Oct 20, 2010 at 6:19 PM, Ricky wrote: > It used to stay up until clicked on or until certain characters were > typed... Got in the the way at times, but was quite useful. > > > On Wed, Oct 20, 2010 at 3:08 PM, SuezanneC Baskerville > wrote: > > I'd be pleased if the popup tip remained visible somewhere. My short term > > memory is bad, if there are many parameters I have to make the popup > appear > > more than once. > > > > On Wed, Oct 20, 2010 at 3:53 PM, Ricky wrote: > >> > >> I think the idea here is to have the popup capable of doing > >> auto-completion. This would save a load of time, as well as make it > >> easier to script, IMHO. > >> > >> An alternative would be to expand the usefulness of the code insert > >> dropdown by having it add the parens and properties for events and > >> functions using default values/place holders such as is seen in the > >> hover tips. > >> > >> Ricky > >> Cron Stardust > >> > >> On Wed, Oct 20, 2010 at 1:21 PM, Dave Booth > >> wrote: > >> > On 10/20/2010 13:20, malachi wrote: > >> >> Of all the developers who are working on the client someone has to be > >> >> smart enough to implement this. > >> >> > >> >> For you windows developers who are using Visual Studio, When you type > a > >> >> function name and get to the ( point of the function it pops a tip up > >> >> telling you what is needed to complete this function. I believe it is > >> >> called intellisense. I could be mistaken. Why can we not have the > same > >> >> type of script editor? An auto complete type of compiler for the > >> >> editor. > >> >> As we type in our scripts popups would help us complete what it is we > >> >> are > >> >> typing. this would increase speed of script writing, help beginners > >> >> learn > >> >> LSL programming faster, and simplify the process. this is just my > >> >> thoughts. it is already implemented in LSLEditor just figured it > could > >> >> be > >> >> done in the client as well. > >> > > >> > hover the mouse over the highlighted function name and you get a tip > >> > popup showing the functions prototype. Personally I prefer this to > >> > environments where the popup happens automatically - the popup would > be > >> > a distraction for the functions I use really frequently and never need > >> > reminding about their parameters but I'll use the tip to remind myself > >> > of the correct parameter order for those I use infrequently. Perhaps > >> > this should be a selectable behaviour - Theres already a hook to spot > >> > when a function name is typed and highlight it, possibly leverage that > >> > and have function tip popups in the editor be on-hover, on-highlight > or > >> > off? > >> > > >> > Dave. > >> > _______________________________________________ > >> > Policies and (un)subscribe information available here: > >> > http://wiki.secondlife.com/wiki/OpenSource-Dev > >> > Please read the policies before posting to keep unmoderated posting > >> > privileges > >> > > >> _______________________________________________ > >> Policies and (un)subscribe information available here: > >> http://wiki.secondlife.com/wiki/OpenSource-Dev > >> Please read the policies before posting to keep unmoderated posting > >> privileges > > > > > > > > -- > > v i r t u a l w o r l d e n t h u s i a s t > > -- http://www.google.com/profiles/s u e z a n n e -- > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101020/4427c796/attachment-0001.htm From lee.ponzu at gmail.com Wed Oct 20 15:43:57 2010 From: lee.ponzu at gmail.com (Ponzu) Date: Wed, 20 Oct 2010 18:43:57 -0400 Subject: [opensource-dev] Latest build broken on Mac Message-ID: ...or maybe it is just me. I used hg bisect to find the " last good build", (see bottom of this email) Maybe I need to download new FMOD or something. ./develop.py dies like this... Running 'cmake -G \'Xcode\' -DCMAKE_BUILD_TYPE:STRING=RELWITHDEBINFO -DSTANDALONE:BOOL=OFF -DUNATTENDED:BOOL=OFF -DWORD_SIZE:STRING=32 -DROOT_PROJECT_NAME:STRING=SecondLife OFF "" \'/Users/elee/Documents/hg/ponzu-main/indra\'' in 'build-darwin-i386' ssh: connect to host install-packages.lindenlab.com port 22: Operation timed out Traceback (most recent call last): File "install.py", line 1150, in md5 mismatch: /private/var/tmp/elee/install.cache/fmod-3.75-darwin-20080818.tar.bz2 sys.exit(main()) File "install.py", line 1142, in main Downloading scp:install-packages.lindenlab.com:/local/www/install-packages/doc/fmod-3.75-darwin-20080818.tar.bz2 to local file /private/var/tmp/elee/install.cache/fmod-3.75-darwin-20080818.tar.bz2 options.scp) File "install.py", line 636, in do_install cache_dir) File "install.py", line 595, in install ifile.fetch_local() File "install.py", line 135, in fetch_local file(self.filename, 'wb').write(urllib2.urlopen(self.url).read()) File "/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/urllib2.py", line 124, in urlopen return _opener.open(url, data, timeout) File "/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/urllib2.py", line 383, in open response = self._open(req, data) File "/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/urllib2.py", line 401, in _open '_open', req) File "/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/urllib2.py", line 361, in _call_chain result = func(*args) File "install.py", line 670, in scp_open return self.do_scp(remote) File "install.py", line 701, in do_scp raise RuntimeError("Cannot fetch: %s" % remote) RuntimeError: Cannot fetch: install-packages.lindenlab.com: /local/www/install-packages/doc/fmod-3.75-darwin-20080818.tar.bz2 CMake Error at cmake/Prebuilt.cmake:39 (message): Failed to download or unpack prebuilt 'fmod'. Process returned 1. Call Stack (most recent call first): cmake/FMOD.cmake:10 (use_prebuilt_binary) llaudio/CMakeLists.txt:8 (include) Final output of hg bisect. -- Configuring incomplete, errors occurred! Error: the command 'cmake' exited with status 1 Changeset 13107:e37e63e56bb1: bad resolving manifests The first bad revision is: changeset: 13107:e37e63e56bb1 parent: 12562:a5f3c123758e user: Merov Linden date: Sat Oct 02 18:30:52 2010 -0700 files: indra/cmake/CMakeLists.txt indra/cmake/Copy3rdPartyLibs.cmake indra/cmake/FMOD.cmake indra/cmake/FindFMOD.cmake indra/newview/CMakeLists.txt indra/newview/viewer_manifest.py description: STORM-137 : Build script modif so that Windows build does not rely on fmod.dll being dropped in the source tree + addition to allow fmod to be found in standalone. Caution: wait an upcoming install.xml commit before pulling if building internaly. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101020/6054fe8b/attachment.htm From xotmid at gmail.com Wed Oct 20 15:46:35 2010 From: xotmid at gmail.com (Brandon Husbands) Date: Wed, 20 Oct 2010 17:46:35 -0500 Subject: [opensource-dev] Enhanced Script Editor Request In-Reply-To: References: <4CBF4F53.6010202@meadowlakearts.com> Message-ID: I will submit my external editor patch to snow storm On Oct 20, 2010 5:39 PM, "Ponzu" wrote: Make the script editor use vi. On Wed, Oct 20, 2010 at 6:19 PM, Ricky wrote: > > It used to stay up until cli... _______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101020/d2cfb54b/attachment.htm From sllists at boroon.dasgupta.ch Wed Oct 20 15:55:10 2010 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Thu, 21 Oct 2010 00:55:10 +0200 Subject: [opensource-dev] STORM-406: Conditional use of FMOD is not correct, breaks open source build (was: Latest build broken on Mac) In-Reply-To: References: Message-ID: <4CBF734E.90900@boroon.dasgupta.ch> On 10/21/2010 12:43 AM, Ponzu wrote: > ...or maybe it is just me. I used hg bisect to find the " last good > build", (see bottom of this email) Maybe I need to download new FMOD > or something. > > ./develop.py dies like this... > > [...] > RuntimeError: Cannot fetch: > install-packages.lindenlab.com:/local/www/install-packages/doc/fmod-3.75-darwin-20080818.tar.bz2 That'd be STORM-406 . Cheers, Boroondas -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101021/1da513c1/attachment.htm From kf6kjg at gmail.com Wed Oct 20 16:07:31 2010 From: kf6kjg at gmail.com (Ricky) Date: Wed, 20 Oct 2010 16:07:31 -0700 Subject: [opensource-dev] Enhanced Script Editor Request In-Reply-To: References: <4CBF4F53.6010202@meadowlakearts.com> Message-ID: lol... That comment reminds me of this (tongue-in-cheek,) graphic representing the learning curves for a variety of common editors: http://blogs.msdn.com/b/steverowe/archive/2004/11/17/code-editor-learning-curves.aspx vi indeed... I'm a pico guy myself, but I'll stoop to using Programmer's Notepad, TextWrangler, or even Eclipse depending on platform and language... All I ever learnt of vi was how to quit, and that took some hunting and help! :q! (while you're ahead) Ricky Cron Stadust On Wed, Oct 20, 2010 at 3:39 PM, Ponzu wrote: > Make the script editor use vi. > > On Wed, Oct 20, 2010 at 6:19 PM, Ricky wrote: >> >> It used to stay up until clicked on or until certain characters were >> typed... Got in the the way at times, but was quite useful. >> >> >> On Wed, Oct 20, 2010 at 3:08 PM, SuezanneC Baskerville >> wrote: >> > I'd be pleased if the popup tip remained visible somewhere. My short >> > term >> > memory is bad, if there are many parameters I have to make the popup >> > appear >> > more than once. >> > >> > On Wed, Oct 20, 2010 at 3:53 PM, Ricky wrote: >> >> >> >> I think the idea here is to have the popup capable of doing >> >> auto-completion. ?This would save a load of time, as well as make it >> >> easier to script, IMHO. >> >> >> >> An alternative would be to expand the usefulness of the code insert >> >> dropdown by having it add the parens and properties for events and >> >> functions using default values/place holders such as is seen in the >> >> hover tips. >> >> >> >> Ricky >> >> Cron Stardust >> >> >> >> On Wed, Oct 20, 2010 at 1:21 PM, Dave Booth >> >> wrote: >> >> > On 10/20/2010 13:20, malachi wrote: >> >> >> Of all the developers who are working on the client someone has to >> >> >> be >> >> >> smart enough to implement this. >> >> >> >> >> >> For you windows developers who are using Visual Studio, When you >> >> >> type a >> >> >> function name and get to the ( point of the function it pops a tip >> >> >> up >> >> >> telling you what is needed to complete this function. I believe it >> >> >> is >> >> >> called intellisense. I could be mistaken. Why can we not have the >> >> >> same >> >> >> type of script editor? An auto complete type of compiler for the >> >> >> editor. >> >> >> As we type in our scripts popups would help us complete what it is >> >> >> we >> >> >> are >> >> >> typing. this would increase speed of script writing, help beginners >> >> >> learn >> >> >> LSL programming faster, and simplify the process. this is just my >> >> >> thoughts. it is already implemented in LSLEditor just figured it >> >> >> could >> >> >> be >> >> >> done in the client as well. >> >> > >> >> > hover the mouse over the highlighted function name and you get a tip >> >> > popup showing the functions prototype. Personally I prefer this to >> >> > environments where the popup happens automatically - the popup would >> >> > be >> >> > a distraction for the functions I use really frequently and never >> >> > need >> >> > reminding about their parameters but I'll use the tip to remind >> >> > myself >> >> > of the correct parameter order for those I use infrequently. Perhaps >> >> > this should be a selectable behaviour - Theres already a hook to spot >> >> > when a function name is typed and highlight it, possibly leverage >> >> > that >> >> > and have function tip popups in the editor be on-hover, on-highlight >> >> > or >> >> > off? >> >> > >> >> > Dave. >> >> > _______________________________________________ >> >> > Policies and (un)subscribe information available here: >> >> > http://wiki.secondlife.com/wiki/OpenSource-Dev >> >> > Please read the policies before posting to keep unmoderated posting >> >> > privileges >> >> > >> >> _______________________________________________ >> >> Policies and (un)subscribe information available here: >> >> http://wiki.secondlife.com/wiki/OpenSource-Dev >> >> Please read the policies before posting to keep unmoderated posting >> >> privileges >> > >> > >> > >> > -- >> > v i r t u a l?? w o r l d?? e n t h u s i a s t >> > -- http://www.google.com/profiles/s u e z a n n e -- >> > >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/OpenSource-Dev >> Please read the policies before posting to keep unmoderated posting >> privileges > > From sythos at gmail.com Wed Oct 20 16:23:18 2010 From: sythos at gmail.com (Altair Sythos Memo) Date: Thu, 21 Oct 2010 01:23:18 +0200 Subject: [opensource-dev] Enhanced Script Editor Request In-Reply-To: References: <4CBF4F53.6010202@meadowlakearts.com> Message-ID: <20101021012318.a65b64d7.sythos@gmail.com> On Wed, 20 Oct 2010 16:07:31 -0700 Ricky wrote: > lol... That comment reminds me of this (tongue-in-cheek,) graphic > representing the learning curves for a variety of common editors: > http://blogs.msdn.com/b/steverowe/archive/2004/11/17/code-editor-learning-curves.aspx damn awaked my wife laughing... XD From malachi at tamzap.com Wed Oct 20 16:36:33 2010 From: malachi at tamzap.com (malachi) Date: Wed, 20 Oct 2010 19:36:33 -0400 Subject: [opensource-dev] Enhanced Script Editor Request In-Reply-To: References: <4CBF4F53.6010202@meadowlakearts.com> Message-ID: I didn't mean add something that would allow editing in an external program. It is bad enough on older machines to run SL alone. and opening multiple programs is not enough. Perhaps tool tips are a bit out of the way i agree with others that the tooltip can sometimes be annoying. but instead maybe a drop down list at the position of the cursor that allows you to pick a function and autocomplete it? and what about user functions? string foo(list in,integer index) or something. when you use it it should pop up in the drop down list as well. the drop down should not be limited to the LL preset functions. real editors do not restrain you to only the preset functions. On Wed, 20 Oct 2010 18:46:35 -0400, Brandon Husbands wrote: > I will submit my external editor patch to snow storm > > On Oct 20, 2010 5:39 PM, "Ponzu" wrote: > > Make the script editor use vi. > > > > > On Wed, Oct 20, 2010 at 6:19 PM, Ricky wrote: >> >> It used to stay up until cli... > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting > privileges -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ From lee.ponzu at gmail.com Wed Oct 20 16:37:43 2010 From: lee.ponzu at gmail.com (Ponzu) Date: Wed, 20 Oct 2010 19:37:43 -0400 Subject: [opensource-dev] STORM-406: Conditional use of FMOD is not correct, breaks open source build (was: Latest build broken on Mac) In-Reply-To: <4CBF734E.90900@boroon.dasgupta.ch> References: <4CBF734E.90900@boroon.dasgupta.ch> Message-ID: Boroondas, my guru! On Wed, Oct 20, 2010 at 6:55 PM, Boroondas Gupte wrote: > On 10/21/2010 12:43 AM, Ponzu wrote: > > ...or maybe it is just me. I used hg bisect to find the " last good > build", (see bottom of this email) Maybe I need to download new FMOD or > something. > > ./develop.py dies like this... > > [...] > RuntimeError: Cannot fetch: install-packages.lindenlab.com: > /local/www/install-packages/doc/fmod-3.75-darwin-20080818.tar.bz2 > > That'd be STORM-406 . > > Cheers, > Boroondas > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101020/c12fc9eb/attachment.htm From lee.ponzu at gmail.com Wed Oct 20 16:40:33 2010 From: lee.ponzu at gmail.com (Ponzu) Date: Wed, 20 Oct 2010 19:40:33 -0400 Subject: [opensource-dev] Enhanced Script Editor Request In-Reply-To: <20101021012318.a65b64d7.sythos@gmail.com> References: <4CBF4F53.6010202@meadowlakearts.com> <20101021012318.a65b64d7.sythos@gmail.com> Message-ID: Alas, so many generations of coder who learned vi from someone who already didn't know vi. You will note that Google's new keyboard commands are vi commands. There is a reason for this. On Wed, Oct 20, 2010 at 7:23 PM, Altair Sythos wrote: > On Wed, 20 Oct 2010 16:07:31 -0700 > Ricky wrote: > > > lol... That comment reminds me of this (tongue-in-cheek,) graphic > > representing the learning curves for a variety of common editors: > > > http://blogs.msdn.com/b/steverowe/archive/2004/11/17/code-editor-learning-curves.aspx > > damn awaked my wife laughing... XD > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101020/9ce5e240/attachment.htm From dave at meadowlakearts.com Wed Oct 20 17:45:14 2010 From: dave at meadowlakearts.com (Dave Booth) Date: Wed, 20 Oct 2010 19:45:14 -0500 Subject: [opensource-dev] Enhanced Script Editor Request In-Reply-To: References: <4CBF4F53.6010202@meadowlakearts.com> <20101021012318.a65b64d7.sythos@gmail.com> Message-ID: <4CBF8D1A.9000508@meadowlakearts.com> On 10/20/2010 18:40, Ponzu wrote: > Alas, so many generations of coder who learned vi from someone who > already didn't know vi. > > You will note that Google's new keyboard commands are vi commands. > There is a reason for this. > same reason that most chat apps commands are IRC commands :) /me does something in SL for example ... From gcanaday at gmail.com Wed Oct 20 17:45:51 2010 From: gcanaday at gmail.com (Glen Canaday) Date: Wed, 20 Oct 2010 20:45:51 -0400 Subject: [opensource-dev] Enhanced Script Editor Request In-Reply-To: References: <4CBF4F53.6010202@meadowlakearts.com> <20101021012318.a65b64d7.sythos@gmail.com> Message-ID: <1287621951.2178.1.camel@glen-desktop> On Wed, 2010-10-20 at 19:40 -0400, Ponzu wrote: > Alas, so many generations of coder who learned vi from someone who > already didn't know vi. > > > You will note that Google's new keyboard commands are vi commands. > There is a reason for this. > Google... has keyboard commands? :wq , :i, :q! <---? (loved the vi & emacs graphics! the other editors just didn't exist yet when I started with Linux...) --GC > On Wed, Oct 20, 2010 at 7:23 PM, Altair Sythos > wrote: > On Wed, 20 Oct 2010 16:07:31 -0700 > Ricky wrote: > > > > lol... That comment reminds me of this (tongue-in-cheek,) > graphic > > representing the learning curves for a variety of common > editors: > > > http://blogs.msdn.com/b/steverowe/archive/2004/11/17/code-editor-learning-curves.aspx > > > damn awaked my wife laughing... XD > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting privileges From gcanaday at gmail.com Wed Oct 20 17:47:33 2010 From: gcanaday at gmail.com (Glen Canaday) Date: Wed, 20 Oct 2010 20:47:33 -0400 Subject: [opensource-dev] Enhanced Script Editor Request In-Reply-To: <4CBF8D1A.9000508@meadowlakearts.com> References: <4CBF4F53.6010202@meadowlakearts.com> <20101021012318.a65b64d7.sythos@gmail.com> <4CBF8D1A.9000508@meadowlakearts.com> Message-ID: <1287622053.2178.3.camel@glen-desktop> I do sometimes wonder what happened to i, ii, iii, iv, and v, though. Must be like that "Leonard Part 6" movie Bill Cosby did in the early 80's. --GC On Wed, 2010-10-20 at 19:45 -0500, Dave Booth wrote: > On 10/20/2010 18:40, Ponzu wrote: > > Alas, so many generations of coder who learned vi from someone who > > already didn't know vi. > > > > You will note that Google's new keyboard commands are vi commands. > > There is a reason for this. > > > > same reason that most chat apps commands are IRC commands :) /me does > something in SL for example ... > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting privileges From latifer at streamgrid.net Wed Oct 20 17:58:44 2010 From: latifer at streamgrid.net (Latif Khalifa) Date: Thu, 21 Oct 2010 02:58:44 +0200 Subject: [opensource-dev] STORM-406: Conditional use of FMOD is not correct, breaks open source build (was: Latest build broken on Mac) In-Reply-To: References: <4CBF734E.90900@boroon.dasgupta.ch> Message-ID: Tested with https://bitbucket.org/merov_linden/viewer-development-storm-137 which produces working viewer, with FMOD support. Make sure to follow the updated instructions on the wiki that are mentioned in STORM-406, Latif On Thu, Oct 21, 2010 at 1:37 AM, Ponzu wrote: > Boroondas, my guru! > > On Wed, Oct 20, 2010 at 6:55 PM, Boroondas Gupte > wrote: >> >> On 10/21/2010 12:43 AM, Ponzu wrote: >> >> ...or maybe it is just me. ?I used hg bisect to find the " last good >> build", (see bottom of this email) ?Maybe I need to download new FMOD or >> something. >> ./develop.py dies like this... >> >> [...] >> RuntimeError: Cannot fetch: >> install-packages.lindenlab.com:/local/www/install-packages/doc/fmod-3.75-darwin-20080818.tar.bz2 >> >> That'd be STORM-406. >> >> Cheers, >> Boroondas >> >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/OpenSource-Dev >> Please read the policies before posting to keep unmoderated posting >> privileges > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting > privileges > From akanevsky at productengine.com Wed Oct 20 23:07:06 2010 From: akanevsky at productengine.com (Anya Kanevsky) Date: Wed, 20 Oct 2010 23:07:06 -0700 Subject: [opensource-dev] Daily Scrum Summary - Wednesday, October 20 Message-ID: Summary covers 2 days, since we had a sprint planning meeting instead of our daily standup on tuesday. https://wiki.secondlife.com/wiki/Snowstorm_Daily_Scrum_Archive Date: Wed Oct 20 == GENERAL NOTES == * Merge Monkey of the Day: Oz == DAILY SCRUM == === Merov === PAST * Sprint 6 planning meeting * OH: change the wiki giving my OH and subject while at it... * Sprint 4 and Sprint 5 cleanup : reviewed and marked QA some build only fixes * STORM-406: Pulled Boroondas changes. Added one changeset to [10:38] Merov Linden: * STORM-281: Posted a changeset and made it ready for review * STORM-416: Added data to the JIRA and made it Ready for review * STORM-104: kdu upgrade: More code cleanup. Discussed with Oz wrt licensing issues on some files. FUTURE * STORM-423: Prepare a changeset * STORM-104: kdu upgrade * STORM-105 : Perf decompression: put new data out, check the work done by opensource-dev community on similar tests. IMPEDIMENTS * Latest KDU bits: been told today's the day :) ==Oz Linden== PAST * Built and posted Project Viewer for STORM-255 ** Set up public repo for this change, and infrastructure to build it * Submitted proposal for WEB-1560 (open source SL map javascript) * Pulled initial viewer-beta changes back to viewer-development * Bumped viewer-development version number to 2.4.0 FUTURE * More changes to develop site * Looking into grittier details of ReviewBoard * Start on STORM-312 integration IMPEDIMENTS * none === Q Linden=== PAST * sprint planning * release * tagged next beta * triage / JIRA discussions * tool coding FUTURE * triage * meetings * beta * test code IMPEDIMENTS * none === Esbee Linden==== PAST * Viewer 2.2 Release * Viewer 2.2 Announcement Blog Post Up * Coordinating Viewer 2.3 Beta 1 release FUTURE * Write Viewer 2.3 Beta 1 blog post * Systems requirements analysis * Preferences review * VWR Triage * Viewer 2.3 Beta 1 Release Coordination IMPEDIMENTS * None === Paul ProductEngine=== PAST: * BUG STORM-254 The default offer friendship message is not shown when user offer friendship ** When i tried to resolve conflict while applying patch, noted that necessary strings are already in. It seems that patch was already applied. * BUG STORM-293 Friend permissions icons overlap long names on 'My Friends' tab ** Today during testing found second variant of fix. Tested and it's OK. ** Discussed with Vadim which variant of fix should be implemented. Applied fix and sent for a review * BUG STORM-311 "Share" button is enabled if select non worn wearable and wear it ** In progress. Estimate ~ 5 hour FUTURE: * BUG STORM-311 "Share" button is enabled if select non worn wearable and wear it IMPEDIMENTS: * none === Seth Productengine === PAST: * BUG (STORM-263) Cog button in lower-left of sidebar panel does not close popup menu on second click ** Found and fixed another few issues in the patch. Posted patch to review board at https://codereview.productengine.com/secondlife/r/888/. ** Could not find a proper way to resolve an issue with MenuButton incorrect pressed state. ** Fixed according to review feedback. * BUG (STORM-294) Selection goes out of Favorites overflow list if scroll it by keyboard ** Fixed compiler warning breaking the Windows build. *Fixing broken viewer-development build. FUTURE: * BUG (STORM-296) Cursor doesn't change when trying to drag and drop non-landmark items into Favorites folder * BUG (STORM-303) Favorites folder content isn't refreshed while re-ordering landmaks Estimated: 4-6 hours. * BUG (STORM-426) Menu button looks as being pressed while its menu is displayed by another control Estimated: 8 hours. IMPEDIMENTS: * none === Andrew Productengine === PAST: * Bug STORM-322 (Group Member Search: gives more entries then the search string suggests) ** Tried to find a better solution but all have their flaws. ** Discussed with Vadim, came to decision to fix it substantially other way. WIP. Estimate- 8 hours. ** While working on this issue, found suspicious place in code- seems there is another bug in group roles member list. There perhaps is a problem with "donations" column, but I couldn't check whether the bug there because couldn't donate land myself or find group where there are members who did it. To contribute land the way to appear there premium membership is needed. Deeding land is not what is needed. But though I couldn't reproduce it and file a bug, it will be fixed by my changes for STORM-322 anyway. * Major bug STORM-402 (People you interacted via IM chat floater are not shown in Recent tab) ** Fixed in viewer-beta code, had problems with building development, will test there tomorrow and put on review. ** Tested and sent for review. * Critical bug STORM-95 (Upload hangs client) ** Started investigating. FUTURE * Finish STORM-322 IMPEDIMENTS: * none === Vadim Productengine === PAST: * Bug STORM-390 ("Place Profile" appears instead of "Resident Profile" after clicking on user name in NearBy Chat Toast): ** Fixed. * Bug STORM-403 (Resident profile opens if click object SLURL in the nearby chat toast): ** Resolved as a dupe. * Code review. FUTURE: * will pick something from sprint 6 IMPEDIMENTS: * none === Andrey Productengine === PAST: * smoke and regression testing of Viewer 2.2.0 Release build 212097 ** smoke and integrity tests have been passed, build has been accepted * regression testing of Viewer 2.2.0 Release - done * updated regression suite: added Build Tools, SLApps, Gestures sections FUTURE: * complete regression testing of Viewer 2.2.0 Release * switch to v-d build: verify integrated tickets, do regression testing IMPEDIMENTS: * none From secret.argent at gmail.com Thu Oct 21 04:16:40 2010 From: secret.argent at gmail.com (Argent Stonecutter) Date: Thu, 21 Oct 2010 06:16:40 -0500 Subject: [opensource-dev] Fermi Viewer In-Reply-To: References: <000101cb6e50$6b4df020$41e9d060$@org> <20101018005833.GB32331@alinoe.com> <001e01cb6e60$1fe5f0f0$5fb1d2d0$@org> <-574497265938522238@unknownmsgid> <4CBC5932.6080309@beau.org> <4CBC59E0.9050800@streamsense.net> <8F7C71E6-7CA1-4274-B2C4-F65EC3C06D61@gmail.com> Message-ID: On 2010-10-20, at 11:21, Daniel Smith wrote: > On Wed, Oct 20, 2010 at 2:29 AM, Argent Stonecutter wrote: >> On 2010-10-18, at 12:08, Daniel Smith wrote: >>> would be better all around.. for the community to say .. hold up.. how to merge the best of 1.x and 2.x >> We already have that. It's called 1.x. > { "remarkAnswer" : "hee hee - but it doesnt have the two Ms", > "theMs" : { > "M1": "MOAP", > "M2": "MESH" > }, > } The open 2.x code base doesn't have mesh either. And media on a prim is the "Active Desktop" of SL. (and the way LL keeps nerfing mesh, I'm afraid that it's going to be the OS/2 Warp of SL) From secret.argent at gmail.com Thu Oct 21 04:17:46 2010 From: secret.argent at gmail.com (Argent Stonecutter) Date: Thu, 21 Oct 2010 06:17:46 -0500 Subject: [opensource-dev] Enhanced Script Editor Request In-Reply-To: References: Message-ID: On 2010-10-20, at 13:20, malachi wrote: > For you windows developers who are using Visual Studio, When you type a > function name and get to the ( point of the function it pops a tip up > telling you what is needed to complete this function. The SL editor already has this: you just hover the mouse over the function name. From secret.argent at gmail.com Thu Oct 21 04:22:20 2010 From: secret.argent at gmail.com (Argent Stonecutter) Date: Thu, 21 Oct 2010 06:22:20 -0500 Subject: [opensource-dev] Enhanced Script Editor Request In-Reply-To: References: <4CBF4F53.6010202@meadowlakearts.com> Message-ID: On 2010-10-20, at 18:07, Ricky wrote: > lol... That comment reminds me of this (tongue-in-cheek,) graphic > representing the learning curves for a variety of common editors: > http://blogs.msdn.com/b/steverowe/archive/2004/11/17/code-editor-learning-curves.aspx Pet peeve time: I understand the colloqualism, but if you think about what you're actually measuring a "steep learning curve" means something's easy to learn... you learn a lot, quickly. From lee.ponzu at gmail.com Thu Oct 21 06:51:26 2010 From: lee.ponzu at gmail.com (Ponzu) Date: Thu, 21 Oct 2010 09:51:26 -0400 Subject: [opensource-dev] USER STORY for not so far future Message-ID: As a user, I want to use a multi-touch device (iPad, Android, etc) to control Second Life. The simple technical issue is getting the tablet to talk to the viewer. Of course, the hard issue is creating the insanely great multi-touch interface. For example, touching tablet could re-aim camera. making little walking motions with your fingers could make you walk. two-finger movement could enter mouselook and move. I thought of this because I saw a Mac paint program (on the big screen) where the controls such as palette, color, brush, are on an iPad. Looked really cool. Ponzu -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101021/4fa51bd3/attachment.htm From sythos at gmail.com Thu Oct 21 07:10:00 2010 From: sythos at gmail.com (Francesco Rabbi) Date: Thu, 21 Oct 2010 16:10:00 +0200 Subject: [opensource-dev] USER STORY for not so far future In-Reply-To: References: Message-ID: <-7015223766409392128@unknownmsgid> Not understand sorry... This isn't a LL problem. You can already use iMouse to use your iPad, iPhone or iPod as a multi-touch trackpad and via control panel you can bind multi-touch gesture to keyboard shortcut... -- Sent by iPhone Il giorno 21/ott/2010, alle ore 15:52, Ponzu ha scritto: > As a user, I want to use a multi-touch device (iPad, Android, etc) to control Second Life. > > The simple technical issue is getting the tablet to talk to the viewer. Of course, the hard issue is creating the insanely great multi-touch interface. For example, touching tablet could re-aim camera. making little walking motions with your fingers could make you walk. two-finger movement could enter mouselook and move. > > I thought of this because I saw a Mac paint program (on the big screen) where the controls such as palette, color, brush, are on an iPad. Looked really cool. > > Ponzu > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting privileges From oz at lindenlab.com Thu Oct 21 08:57:28 2010 From: oz at lindenlab.com (Oz Linden (Scott Lawrence)) Date: Thu, 21 Oct 2010 11:57:28 -0400 Subject: [opensource-dev] USER STORY for not so far future In-Reply-To: <-7015223766409392128@unknownmsgid> References: <-7015223766409392128@unknownmsgid> Message-ID: <4CC062E8.9050504@lindenlab.com> On 2010-10-21 10:10, Francesco Rabbi wrote: > Not understand sorry... > > This isn't a LL problem. You can already use iMouse to use your iPad, > iPhone or iPod as a multi-touch trackpad and via control panel you can > bind multi-touch gesture to keyboard shortcut... Now that would be a great thing to document on the wiki - think you can write it up, Francesco? From lee.ponzu at gmail.com Thu Oct 21 12:55:13 2010 From: lee.ponzu at gmail.com (Ponzu) Date: Thu, 21 Oct 2010 15:55:13 -0400 Subject: [opensource-dev] USER STORY for not so far future In-Reply-To: <4CC062E8.9050504@lindenlab.com> References: <-7015223766409392128@unknownmsgid> <4CC062E8.9050504@lindenlab.com> Message-ID: Yes, it is a great thing, but the kind of control I imagine is not tied to keyboard short-cuts. At least, I don't think there is a keyboard shortcut for sit-on-that-chair, or look-to-the-left The background is that I think that the keyboard commands in SL were created by a combination of gamers (wasd) and 3D software users (ctl-cmd-shift X). I am trying to imagine what the fundamental operations are in SL, and then what multi-touch gesture each should map too. Think Tom Cruise in Minority Report... Ponzu waves hand to send email....woooosh damn, still there. Guess I'll have to pretend to click on the imaginary button. On Thu, Oct 21, 2010 at 11:57 AM, Oz Linden (Scott Lawrence) < oz at lindenlab.com> wrote: > On 2010-10-21 10:10, Francesco Rabbi wrote: > >> Not understand sorry... >> >> This isn't a LL problem. You can already use iMouse to use your iPad, >> iPhone or iPod as a multi-touch trackpad and via control panel you can >> bind multi-touch gesture to keyboard shortcut... >> > > > Now that would be a great thing to document on the wiki - think you can > write it up, Francesco? > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101021/a5e0e87a/attachment.htm From sythos at gmail.com Thu Oct 21 13:41:48 2010 From: sythos at gmail.com (Altair Sythos Memo) Date: Thu, 21 Oct 2010 22:41:48 +0200 Subject: [opensource-dev] USER STORY for not so far future In-Reply-To: <4CC062E8.9050504@lindenlab.com> References: <-7015223766409392128@unknownmsgid> <4CC062E8.9050504@lindenlab.com> Message-ID: <20101021224148.d18319ab.sythos@gmail.com> On Thu, 21 Oct 2010 11:57:28 -0400 "Oz Linden (Scott Lawrence)" wrote: > On 2010-10-21 10:10, Francesco Rabbi wrote: > > Not understand sorry... > > > > This isn't a LL problem. You can already use iMouse to use your > > iPad, iPhone or iPod as a multi-touch trackpad and via control > > panel you can bind multi-touch gesture to keyboard shortcut... > > > Now that would be a great thing to document on the wiki - think you > can write it up, Francesco? /me wistle whispering "next time i'll look my shoes" XD ok, asap i'll have a bit of spare time i'll begin, is more a list of links to howto... From zabb65 at gmail.com Thu Oct 21 15:05:32 2010 From: zabb65 at gmail.com (Zabb65) Date: Thu, 21 Oct 2010 18:05:32 -0400 Subject: [opensource-dev] Mesh Source Code ETA Message-ID: Last week when Mesh was announced into public beta, it was said the source code would be put up by the end of the week, checking the blog post mentions that it would be placed on the snowstorm wiki page, but I cannot find it there. After having corresponded with a few people it seems that the build was broken and that is what is keeping the source from being published. Later on I heard that pieces of mesh were being removed from the code because of license restrictions. So my questions are as follows: 1. Is there any ETA on a release for the source code to the mesh viewer? 2. As things are being removed, what exactly is being pulled, the entire uploading process? Mesh decomposition support only? Something else? 3. Is there the possibility of the code being released, even in its broken state so that the community can review the changes made and become more accustomed to them for merge purposes. Or so that the dedicated community could piece together a working build from what is there somehow? ~Zwagoth From malachi at tamzap.com Thu Oct 21 17:36:08 2010 From: malachi at tamzap.com (malachi) Date: Thu, 21 Oct 2010 20:36:08 -0400 Subject: [opensource-dev] Mesh Source Code ETA In-Reply-To: References: Message-ID: wow. see i missed this somewhere. but i comnpletely agree. if this client is OPEN SOURCE. where is the source? why is it being hidden behind walls? On Thu, 21 Oct 2010 18:05:32 -0400, Zabb65 wrote: > Last week when Mesh was announced into public beta, it was said the > source code would be put up by the end of the week, checking the blog > post mentions that it would be placed on the snowstorm wiki page, but > I cannot find it there. > > After having corresponded with a few people it seems that the build > was broken and that is what is keeping the source from being > published. Later on I heard that pieces of mesh were being removed > from the code because of license restrictions. So my questions are as > follows: > > 1. Is there any ETA on a release for the source code to the mesh viewer? > 2. As things are being removed, what exactly is being pulled, the > entire uploading process? Mesh decomposition support only? Something > else? > 3. Is there the possibility of the code being released, even in its > broken state so that the community can review the changes made and > become more accustomed to them for merge purposes. Or so that the > dedicated community could piece together a working build from what is > there somehow? > > ~Zwagoth > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting > privileges -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ From xotmid at gmail.com Thu Oct 21 17:54:52 2010 From: xotmid at gmail.com (Brandon Husbands) Date: Thu, 21 Oct 2010 19:54:52 -0500 Subject: [opensource-dev] Tools of the trade. In-Reply-To: References: Message-ID: You ditching Cmake? On Wed, Oct 20, 2010 at 1:43 PM, Kent Quirk (Q Linden) wrote: > We've been having this discussion internally for some time. There's a lot > of friction because a) we have to update lots of developers, and b) we have > to rebuild all the libraries and distribute them internally. > > We've been working on a tool called autobuild which will automate this > process; it's almost ready. It should make it lots easier for us as well as > opensource developers to get a build up and running, and will centralize the > tool decisions so that we can finally upgrade fairly easily. > > Q > > > On Oct 20, 2010, at 12:21 AM, Brandon Husbands wrote: > > > I understand that Licensing costs money but I do have a question. It is > almost 2011 That's 6 years after Visual Studio was released. > > I also know there are patches floating around for cmake and various other > things that make VS2k8 compile properly. So I ask this, when is LL going to > drop vs2k5 as the "Supported" MS compiler? With c++0x Standard actually > being implimented with some methods in vs2k8 and mostly in 2k10. Is it not > time to really update our default toolset? > > > > At least lets get the patches in to fix 2k8, and get it officially > supported. I despise 2k5, 28k is pretty solid now. 2k10 seems to be the > vista of IDE's maybe 2k11 will be the win 7 =) Mostly due to the project > based settings instead of global IDE includes which is a PITA even with > Cmake. > > > > Id like to get LL's response on how long are we going to be stuck with > 2k5 as the "official" compiler/ide. > > > > > > > > -- > > > ------------------------------------------------------------------------------------------------------------------------------- > > This email is a private and confidential communication. Any use of email > may be subject to the laws and regulations of the United States. You may not > Repost, Distribute nor reproduce any content of this message. > > > ------------------------------------------------------------------------------------------------------------------------------- > > > ------------------------------------------------------------------------------------------------------------------------------- > > _______________________________________________ > > Policies and (un)subscribe information available here: > > http://wiki.secondlife.com/wiki/OpenSource-Dev > > Please read the policies before posting to keep unmoderated posting > privileges > > -- ------------------------------------------------------------------------------------------------------------------------------- This email is a private and confidential communication. Any use of email may be subject to the laws and regulations of the United States. You may not Repost, Distribute nor reproduce any content of this message. ------------------------------------------------------------------------------------------------------------------------------- ------------------------------------------------------------------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101021/020f2804/attachment.htm From zabb65 at gmail.com Thu Oct 21 17:56:32 2010 From: zabb65 at gmail.com (Zabb65) Date: Thu, 21 Oct 2010 20:56:32 -0400 Subject: [opensource-dev] Mesh Source Code ETA In-Reply-To: References: Message-ID: They have only said they would release source, though they do not have to release it. They are doing so out of their own good will as a company, not by legal obligation, please remember this. I suspect they are not trying to hide anything at all in this. Just complications have likely occurred, so looking for updates or comments from the official source as to whats going on. ~Zwagoth On Thu, Oct 21, 2010 at 20:36, malachi wrote: > wow. see i missed this somewhere. but i comnpletely agree. if this client is > OPEN SOURCE. where is the source? why is it being hidden behind walls? > On Thu, 21 Oct 2010 18:05:32 -0400, Zabb65 wrote: > >> Last week when Mesh was announced into public beta, it was said the >> source code would be put up by the end of the week, checking the blog >> post mentions that it would be placed on the snowstorm wiki page, but >> I cannot find it there. >> >> After having corresponded with a few people it seems that the build >> was broken and that is what is keeping the source from being >> published. Later on I heard that pieces of mesh were being removed >> from the code because of license restrictions. So my questions are as >> follows: >> >> 1. Is there any ETA on a release for the source code to the mesh viewer? >> 2. As things are being removed, what exactly is being pulled, the >> entire uploading process? Mesh decomposition support only? Something >> else? >> 3. Is there the possibility of the code being released, even in its >> broken state so that the community can review the changes made and >> become more accustomed to them for merge purposes. Or so that the >> dedicated community could piece together a working build from what is >> there somehow? >> >> ~Zwagoth >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/OpenSource-Dev >> Please read the policies before posting to keep unmoderated posting >> privileges > > > -- > Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ > From brad at lindenlab.com Thu Oct 21 18:54:27 2010 From: brad at lindenlab.com (Brad Kittenbrink (Brad Linden)) Date: Thu, 21 Oct 2010 18:54:27 -0700 Subject: [opensource-dev] Tools of the trade. In-Reply-To: References: Message-ID: Funny, but no. It has been said that cmake is the worst IDE build system generator except all those others that have been tried. We are gonna try to ditch develop.py though. And we're gonna start publishing the way we build all third party libs for the viewer. We should be ready to show it off and talk about it in detail RealSoonNow. -Brad On Thu, Oct 21, 2010 at 5:54 PM, Brandon Husbands wrote: > You ditching Cmake? > > > > On Wed, Oct 20, 2010 at 1:43 PM, Kent Quirk (Q Linden) wrote: > >> We've been having this discussion internally for some time. There's a lot >> of friction because a) we have to update lots of developers, and b) we have >> to rebuild all the libraries and distribute them internally. >> >> We've been working on a tool called autobuild which will automate this >> process; it's almost ready. It should make it lots easier for us as well as >> opensource developers to get a build up and running, and will centralize the >> tool decisions so that we can finally upgrade fairly easily. >> >> Q >> >> >> On Oct 20, 2010, at 12:21 AM, Brandon Husbands wrote: >> >> > I understand that Licensing costs money but I do have a question. It is >> almost 2011 That's 6 years after Visual Studio was released. >> > I also know there are patches floating around for cmake and various >> other things that make VS2k8 compile properly. So I ask this, when is LL >> going to drop vs2k5 as the "Supported" MS compiler? With c++0x Standard >> actually being implimented with some methods in vs2k8 and mostly in 2k10. Is >> it not time to really update our default toolset? >> > >> > At least lets get the patches in to fix 2k8, and get it officially >> supported. I despise 2k5, 28k is pretty solid now. 2k10 seems to be the >> vista of IDE's maybe 2k11 will be the win 7 =) Mostly due to the project >> based settings instead of global IDE includes which is a PITA even with >> Cmake. >> > >> > Id like to get LL's response on how long are we going to be stuck with >> 2k5 as the "official" compiler/ide. >> > >> > >> > >> > -- >> > >> ------------------------------------------------------------------------------------------------------------------------------- >> > This email is a private and confidential communication. Any use of email >> may be subject to the laws and regulations of the United States. You may not >> Repost, Distribute nor reproduce any content of this message. >> > >> ------------------------------------------------------------------------------------------------------------------------------- >> > >> ------------------------------------------------------------------------------------------------------------------------------- >> > _______________________________________________ >> > Policies and (un)subscribe information available here: >> > http://wiki.secondlife.com/wiki/OpenSource-Dev >> > Please read the policies before posting to keep unmoderated posting >> privileges >> >> > > > -- > > ------------------------------------------------------------------------------------------------------------------------------- > This email is a private and confidential communication. Any use of email > may be subject to the laws and regulations of the United States. You may not > Repost, Distribute nor reproduce any content of this message. > > ------------------------------------------------------------------------------------------------------------------------------- > > ------------------------------------------------------------------------------------------------------------------------------- > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101021/841502b1/attachment-0001.htm From zabb65 at gmail.com Thu Oct 21 19:05:13 2010 From: zabb65 at gmail.com (Zabb65) Date: Thu, 21 Oct 2010 22:05:13 -0400 Subject: [opensource-dev] Mesh Source Code ETA In-Reply-To: References: Message-ID: Looks like this does not need an answer now. Code is up. http://hg.secondlife.com/mesh-development/ \o/ On Thu, Oct 21, 2010 at 20:56, Zabb65 wrote: > They have only said they would release source, though they do not have > to release it. They are doing so out of their own good will as a > company, not by legal obligation, please remember this. I suspect they > are not trying to hide anything at all in this. Just complications > have likely occurred, so looking for updates or comments from the > official source as to whats going on. > > ~Zwagoth > > On Thu, Oct 21, 2010 at 20:36, malachi wrote: >> wow. see i missed this somewhere. but i comnpletely agree. if this client is >> OPEN SOURCE. where is the source? why is it being hidden behind walls? >> On Thu, 21 Oct 2010 18:05:32 -0400, Zabb65 wrote: >> >>> Last week when Mesh was announced into public beta, it was said the >>> source code would be put up by the end of the week, checking the blog >>> post mentions that it would be placed on the snowstorm wiki page, but >>> I cannot find it there. >>> >>> After having corresponded with a few people it seems that the build >>> was broken and that is what is keeping the source from being >>> published. Later on I heard that pieces of mesh were being removed >>> from the code because of license restrictions. So my questions are as >>> follows: >>> >>> 1. Is there any ETA on a release for the source code to the mesh viewer? >>> 2. As things are being removed, what exactly is being pulled, the >>> entire uploading process? Mesh decomposition support only? Something >>> else? >>> 3. Is there the possibility of the code being released, even in its >>> broken state so that the community can review the changes made and >>> become more accustomed to them for merge purposes. Or so that the >>> dedicated community could piece together a working build from what is >>> there somehow? >>> >>> ~Zwagoth >>> _______________________________________________ >>> Policies and (un)subscribe information available here: >>> http://wiki.secondlife.com/wiki/OpenSource-Dev >>> Please read the policies before posting to keep unmoderated posting >>> privileges >> >> >> -- >> Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ >> > From xotmid at gmail.com Thu Oct 21 19:06:00 2010 From: xotmid at gmail.com (Brandon Husbands) Date: Thu, 21 Oct 2010 21:06:00 -0500 Subject: [opensource-dev] Tools of the trade. In-Reply-To: References: Message-ID: Soon TM! lol SO i dont have to worry about installing 2k5 yet then. On Thu, Oct 21, 2010 at 8:54 PM, Brad Kittenbrink (Brad Linden) < brad at lindenlab.com> wrote: > Funny, but no. It has been said that cmake is the worst IDE build system > generator except all those others that have been tried. > > We are gonna try to ditch develop.py though. And we're gonna start > publishing the way we build all third party libs for the viewer. We should > be ready to show it off and talk about it in detail RealSoonNow. > > -Brad > > > On Thu, Oct 21, 2010 at 5:54 PM, Brandon Husbands wrote: > >> You ditching Cmake? >> >> >> >> On Wed, Oct 20, 2010 at 1:43 PM, Kent Quirk (Q Linden) wrote: >> >>> We've been having this discussion internally for some time. There's a lot >>> of friction because a) we have to update lots of developers, and b) we have >>> to rebuild all the libraries and distribute them internally. >>> >>> We've been working on a tool called autobuild which will automate this >>> process; it's almost ready. It should make it lots easier for us as well as >>> opensource developers to get a build up and running, and will centralize the >>> tool decisions so that we can finally upgrade fairly easily. >>> >>> Q >>> >>> >>> On Oct 20, 2010, at 12:21 AM, Brandon Husbands wrote: >>> >>> > I understand that Licensing costs money but I do have a question. It is >>> almost 2011 That's 6 years after Visual Studio was released. >>> > I also know there are patches floating around for cmake and various >>> other things that make VS2k8 compile properly. So I ask this, when is LL >>> going to drop vs2k5 as the "Supported" MS compiler? With c++0x Standard >>> actually being implimented with some methods in vs2k8 and mostly in 2k10. Is >>> it not time to really update our default toolset? >>> > >>> > At least lets get the patches in to fix 2k8, and get it officially >>> supported. I despise 2k5, 28k is pretty solid now. 2k10 seems to be the >>> vista of IDE's maybe 2k11 will be the win 7 =) Mostly due to the project >>> based settings instead of global IDE includes which is a PITA even with >>> Cmake. >>> > >>> > Id like to get LL's response on how long are we going to be stuck with >>> 2k5 as the "official" compiler/ide. >>> > >>> > >>> > >>> > -- >>> > >>> ------------------------------------------------------------------------------------------------------------------------------- >>> > This email is a private and confidential communication. Any use of >>> email may be subject to the laws and regulations of the United States. You >>> may not Repost, Distribute nor reproduce any content of this message. >>> > >>> ------------------------------------------------------------------------------------------------------------------------------- >>> > >>> ------------------------------------------------------------------------------------------------------------------------------- >>> > _______________________________________________ >>> > Policies and (un)subscribe information available here: >>> > http://wiki.secondlife.com/wiki/OpenSource-Dev >>> > Please read the policies before posting to keep unmoderated posting >>> privileges >>> >>> >> >> >> -- >> >> ------------------------------------------------------------------------------------------------------------------------------- >> This email is a private and confidential communication. Any use of email >> may be subject to the laws and regulations of the United States. You may not >> Repost, Distribute nor reproduce any content of this message. >> >> ------------------------------------------------------------------------------------------------------------------------------- >> >> ------------------------------------------------------------------------------------------------------------------------------- >> >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/OpenSource-Dev >> Please read the policies before posting to keep unmoderated posting >> privileges >> > > -- ------------------------------------------------------------------------------------------------------------------------------- This email is a private and confidential communication. Any use of email may be subject to the laws and regulations of the United States. You may not Repost, Distribute nor reproduce any content of this message. ------------------------------------------------------------------------------------------------------------------------------- ------------------------------------------------------------------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101021/b1d1db89/attachment.htm From akanevsky at productengine.com Fri Oct 22 00:13:25 2010 From: akanevsky at productengine.com (Anya Kanevsky) Date: Fri, 22 Oct 2010 00:13:25 -0700 Subject: [opensource-dev] Daily Scrum Summary - Thursday, October 21 Message-ID: *Date: **Wed** **Oct **20* *== GENERAL NOTES ==* * Merge Monkey of the Day: Oz *== DAILY SCRUM ==* *=== Merov ===* *PAST* * STORM-423: Created a changeset, ready for review * STORM-406: Discussed with lkalif. Updated build wiki. Ready for review. * STORM-173: Found a repro case at last. * Merge Monkey-ing *FUTURE* * STORM-173: Study and fix or leave it that way. * STORM-104: kdu upgrade * STORM-105 : Perf decompression: put new data out, check the work done by opensource-dev community on similar tests. *IMPEDIMENTS* * Latest KDU bits: still waiting... *==**Oz** Linden**==* *PAST* * Lots of internal discussion re: develop site * Discuss opening map javascript * Office Hour ... not very productive day, somehow... *FUTURE* * Meetings regarding new TPV directory site * Review backlog for osdev candidate issues w/ Esbee * Learn how to do library change tests in TeamCity *IMPEDIMENTS* * None *=== Q **Linden**===* PAST * Move my desk * Work on an internal tool * Process documentation * Meetings * * *FUTURE* * Process negotiation * Meetings * Code tomorrow? *IMPEDIMENTS* * Too much time spent educating others on process *=== Esbee Linden ===* *PAST* * Draft of Viewer 2.3 Beta 1 Announcement Blog Post * Coordinating Viewer 2.3 Beta 1 release * Viewer Beta and Release Process work * VWR Triage * Started Prefs requirements work * Beat Q, Gez, and Nyx at Dominion *FUTURE* * Continue work on Viewer 2.3 Beta 1 blog post * Systems requirements analysis * Preferences review * VWR Triage * Viewer 2.3 Beta 1 Release Coordination * Mockup wiki page for Viewer downloads * Review STORM-255 * Finish chart reporting review on Jira *IMPEDIMENTS* * None (just time) *=== Paul ProductEngine===* *PAST:* * STORM-39 As a User, I want to control how long a chat toast appears before it fades. Please add fade time back to Chat preferences. ** Completed first part of the task. Tomorrow will continue the rest of the task. *FUTURE:* * STORM-39 As a User, I want to control how long a chat toast appears before it fades. Please add fade time back to Chat preferences. *IMPEDIMENTS:* * none to menu button's mouse down handler. *=== Seth Productengine ===* *PAST:* *BUG (STORM-426) Menu button looks as being pressed while its menu is displayed by another control ** WIP. **Added visibility change signal to LLMenuGL. Faced the problem with hideMenus() changing menu visibility prior *FUTURE:* * BUG (STORM-426) Menu button looks as being pressed while its menu is displayed by another control ** Estimated: 4 hours. * BUG (STORM-296) Cursor doesn't change when trying to drag and drop non-landmark items into Favorites folder I*MPEDIMENTS:* * none *=== Andrew Productengine ===* *PAST:* * Bug STORM-322 (Group Member Search: gives more entries then the search string suggests) ** Fixed the bug. Will add saving of member list order in setting, test and put on review. Estimate - 2 hours. *FUTURE* * Finish STORM-322. * Critical bug STORM-95 (Upload hangs client). *IMPEDIMENTS:* * none *=== Vadim Productengine ===* *PAST:* * Bug STORM-311 (*"Share" button is enabled if select non worn wearable and wear it*): ** Fixed. *Bug STORM-419 (*Port of SNOW-422 to SG 2.0: ' is used uninitialized in this function inlldarray.h*): ** Submitted a 3rd party patch. * Bug STORM-417 (*Port of SNOW-140 to SG 2.0 : Forced updates not working on Mac*): ** Submitted a 3rd party patch. * Found a workaround for the build problem described in STORM-406. * Consulted Seth about STORM-426. *FUTURE:* * will pick something from sprint 6 *IMPEDIMENTS:* * Need Q to answer in STORM-297. * Need more tickets targeted for sprint 6. * There is a showstopper bug STORM-182 which is still targeted to 2.2.0 beta. It seems to be wrong. *=== Andrey Productengine ===* *PAST:* * Viewer 2.3.0 Beta1 integrity tests are passed on Win; * Viewer 2.3.0 Beta1 smoke tests are passed on OSX and almost done on Windows and Linux * started regression testing of Viewer 2.3.0 Beta1 *FUTURE:* * finish smoke tests on Windows and Linux * proceed with regression tests *IMPEDIMENTS:* * none -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101022/8c03098b/attachment-0001.htm From makosoft at gmail.com Fri Oct 22 02:03:45 2010 From: makosoft at gmail.com (Aidan Thornton) Date: Fri, 22 Oct 2010 10:03:45 +0100 Subject: [opensource-dev] Mesh Source Code ETA In-Reply-To: References: Message-ID: On 10/22/10, Zabb65 wrote: > Looks like this does not need an answer now. Code is up. > http://hg.secondlife.com/mesh-development/ > \o/ Looks like convex decomposition support has been pulled. "LLConvexDecomposition is a proprietary library based on Havok (TM) physics libraries. In its place, Linden Lab shares the code for LLConvexDecompositionStub, a stub version of the same library with no proprietary components." I'd suggest porting the convex decomposition code from something like (for example) Bullet instead might be a good idea. From zabb65 at gmail.com Fri Oct 22 02:12:52 2010 From: zabb65 at gmail.com (Zabb65) Date: Fri, 22 Oct 2010 05:12:52 -0400 Subject: [opensource-dev] Mesh Source Code ETA In-Reply-To: References: Message-ID: I think this would be the most obvious way to add proper decomposition support back into the client, and allow for a full third party implementation. Bullet has a fairly basic decomposition engine, but it should work for what is being done, even if the results are not 100% idea, and possibly can be worked into snowstorm given sufficient time and testing. On Fri, Oct 22, 2010 at 05:03, Aidan Thornton wrote: > On 10/22/10, Zabb65 wrote: >> Looks like this does not need an answer now. Code is up. >> http://hg.secondlife.com/mesh-development/ >> \o/ > > Looks like convex decomposition support has been pulled. > "LLConvexDecomposition is a proprietary library based on Havok (TM) > physics libraries. In its place, Linden Lab shares the code for > LLConvexDecompositionStub, a stub version of the same library with no > proprietary components." > > I'd suggest porting the convex decomposition code from something like > (for example) Bullet instead might be a good idea. > From makosoft at gmail.com Fri Oct 22 04:30:27 2010 From: makosoft at gmail.com (Aidan Thornton) Date: Fri, 22 Oct 2010 12:30:27 +0100 Subject: [opensource-dev] Mesh Source Code ETA In-Reply-To: References: Message-ID: On 10/22/10, Zabb65 wrote: > Looks like this does not need an answer now. Code is up. > http://hg.secondlife.com/mesh-development/ > \o/ Oh, lovely: /** * @file llphysicsshapebuilder.cpp * @brief Generic system to convert LL(Physics)VolumeParams to physics shapes * @author falcon at lindenlab.com * * $LicenseInfo:firstyear=2010&license=internal$ * * Copyright (c) 2010, Linden Research, Inc. * * The following source code is PROPRIETARY AND CONFIDENTIAL. Use of * this source code is governed by the Linden Lab Source Code Disclosure * Agreement ("Agreement") previously entered between you and Linden * Lab. By accessing, using, copying, modifying or distributing this * software, you acknowledge that you have been informed of your * obligations under the Agreement and agree to abide by those obligations. * * ALL LINDEN LAB SOURCE CODE IS PROVIDED "AS IS." LINDEN LAB MAKES NO * WARRANTIES, EXPRESS, IMPLIED OR OTHERWISE, REGARDING ITS ACCURACY, * COMPLETENESS OR PERFORMANCE. * $/LicenseInfo$ */ I do wish organisations wouldn't do things like this... it's a real pain. From dave at meadowlakearts.com Fri Oct 22 07:09:39 2010 From: dave at meadowlakearts.com (Dave Booth) Date: Fri, 22 Oct 2010 09:09:39 -0500 Subject: [opensource-dev] Mesh Source Code ETA In-Reply-To: References: Message-ID: <4CC19B23.5070903@meadowlakearts.com> Theres even precedent for that kind of approach, where image decode is handled by kdu in the linden builds, but it falls back to jpeg2k if kdu isnt available. Indeed, the absence of a functionally equivalent fallback wherever code that is encumbered by proprietary licenses that restrict its opensource release is referenced is a severe blow to the entire snowstorm project, as it guarantees that any viewer built from source will never be feature-complete. Getting a working decomposer thats releasable ported in there should be a pretty high priority for the mesh project. I'd even go so far as to suggest that if proprietary code is to be used in a viewer feature, the availability of a functionally equivalent (doesnt have to perform as well, just has to work) source-releasable fallback should be a requirement for the introduction of the proprietary code to pass review. On 10/22/2010 04:12, Zabb65 wrote: > I think this would be the most obvious way to add proper decomposition > support back into the client, and allow for a full third party > implementation. Bullet has a fairly basic decomposition engine, but it > should work for what is being done, even if the results are not 100% > idea, and possibly can be worked into snowstorm given sufficient time > and testing. > > On Fri, Oct 22, 2010 at 05:03, Aidan Thornton wrote: >> On 10/22/10, Zabb65 wrote: >>> Looks like this does not need an answer now. Code is up. >>> http://hg.secondlife.com/mesh-development/ >>> \o/ >> Looks like convex decomposition support has been pulled. >> "LLConvexDecomposition is a proprietary library based on Havok (TM) >> physics libraries. In its place, Linden Lab shares the code for >> LLConvexDecompositionStub, a stub version of the same library with no >> proprietary components." >> >> I'd suggest porting the convex decomposition code from something like >> (for example) Bullet instead might be a good idea. >> > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting privileges > From nyx at lindenlab.com Fri Oct 22 08:43:39 2010 From: nyx at lindenlab.com (Nyx Linden) Date: Fri, 22 Oct 2010 11:43:39 -0400 Subject: [opensource-dev] Mesh viewer source code Message-ID: <4CC1B12B.6080603@lindenlab.com> Sorry for the delay, there's been a few build and licensing issues that have cropped up recently that have made it difficult to get the source code published for the mesh viewer. That being said, the source is now public, at the following repository: http://hg.secondlife.com/mesh-development/ Please note that there are still some build errors on some platforms, but there have been a few requests that we release the source even before these issues are fixed. I'll be focusing on getting these errors fixed tomorrow, so if you encounter specific build issues, please let me know. There are a few new libraries that are linked into the viewer - the source code for these will be released soon. The new libraries are: glod - level of detail library we use for auto-generating different levels of detail. Based on this library: http://www.cs.jhu.edu/~graphics/GLOD/ We have some tweaks that make it work with our system, and will be releasing the source shortly. collada - we're wrapping the standard collada libs with some code that makes it work with our viewer. We'll be releasing the source to our modifications shortly. Convex decomposition stub - We're using havok to decompose meshes into multiple convex hulls in our official release. However, to support the development of a fully open-source solution, we're releasing the source code to the "stub" (non-functional) version of the library we're providing to compile the mesh viewer. This stub should have all the relevant information necessary to start development of a new convex decomposition library. We hope to have the source up shortly. I'm very interested personally in seeing a fully open-source convex decomposition library created to work with our mesh source code, so if anyone would like to get started on this, please let me know and I'll do what I can to support such an effort! Please note that the current state of the code isn't fully stable - initial builds have reported a linking issue on linux, and a crash on windows. I'll be working to resolve these issues ASAP, but if you have any specific information on how the build is breaking, please let me know! This will be our primary repository, so check back for updates and build fixes :) Thanks everyone for your patience on waiting for the code! -Nyx From nalates.u at gmail.com Fri Oct 22 12:00:45 2010 From: nalates.u at gmail.com (Nalates Urriah) Date: Fri, 22 Oct 2010 12:00:45 -0700 Subject: [opensource-dev] Building Alignment Tool by Qarl Fizz Message-ID: This came out a couple of days ago. New World Notes covered it today, as I did. http://nalates.wordpress.com/2010/10/22/qarl-fizz-prim-alignment-tool/ In SL I use Prim Docker to do prim and texture alignment. I'm not sure Qarl's tool will replace prim docker for me, but it is a great start. I like Prim Docker but it is a bit awkward. Qarl's solution is much more elegant. Since the code is already written and working by a former Linden, will it be added to the SL Viewer? -- Nalates Urriah (SL AV) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101022/140b4540/attachment.htm From sllists at boroon.dasgupta.ch Fri Oct 22 12:19:07 2010 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Fri, 22 Oct 2010 21:19:07 +0200 Subject: [opensource-dev] Building Alignment Tool by Qarl Fizz In-Reply-To: References: Message-ID: <4CC1E3AB.10805@boroon.dasgupta.ch> Cool feature, indeed. On 10/22/2010 09:00 PM, Nalates Urriah wrote: > Since the code is already written and working by a former Linden, will > it be added to the SL Viewer? I'd hope so, but I guess that depends on what his reasonable rates are and whether LL is willing to pay those. Cheers, Boroondas -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101022/715066d5/attachment.htm From soft at lindenlab.com Fri Oct 22 12:25:15 2010 From: soft at lindenlab.com (Brian McGroarty) Date: Fri, 22 Oct 2010 12:25:15 -0700 Subject: [opensource-dev] Mesh Source Code ETA In-Reply-To: References: Message-ID: Falcon merely pasted the wrong license header there, and is already putting the right one in place. He mostly works in simulator code that's closely tied to Havok, and which can't be released. If you see it happen again in the future and there hasn't been some broad announcement about the license changing, assume it's a mistake. Go ahead and create a JIRA for them, or mail the author listed in the header. On Fri, Oct 22, 2010 at 4:30 AM, Aidan Thornton wrote: > On 10/22/10, Zabb65 wrote: > > Looks like this does not need an answer now. Code is up. > > http://hg.secondlife.com/mesh-development/ > > \o/ > > Oh, lovely: > > /** > * @file llphysicsshapebuilder.cpp > * @brief Generic system to convert LL(Physics)VolumeParams to > physics shapes > * @author falcon at lindenlab.com > * > * $LicenseInfo:firstyear=2010&license=internal$ > * > * Copyright (c) 2010, Linden Research, Inc. > * > * The following source code is PROPRIETARY AND CONFIDENTIAL. Use of > * this source code is governed by the Linden Lab Source Code Disclosure > * Agreement ("Agreement") previously entered between you and Linden > * Lab. By accessing, using, copying, modifying or distributing this > * software, you acknowledge that you have been informed of your > * obligations under the Agreement and agree to abide by those obligations. > * > * ALL LINDEN LAB SOURCE CODE IS PROVIDED "AS IS." LINDEN LAB MAKES NO > * WARRANTIES, EXPRESS, IMPLIED OR OTHERWISE, REGARDING ITS ACCURACY, > * COMPLETENESS OR PERFORMANCE. > * $/LicenseInfo$ > */ > > I do wish organisations wouldn't do things like this... it's a real pain. > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting > privileges > -- Brian McGroarty | Linden Lab Sent from my Newton MP2100 via acoustic coupler -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101022/cb9a1659/attachment.htm From tateru at taterunino.net Fri Oct 22 12:33:03 2010 From: tateru at taterunino.net (Tateru Nino) Date: Sat, 23 Oct 2010 06:33:03 +1100 Subject: [opensource-dev] Building Alignment Tool by Qarl Fizz In-Reply-To: References: Message-ID: <4CC1E6EF.4090604@taterunino.net> Not unless it's under a contribution agreement. On 23/10/2010 6:00 AM, Nalates Urriah wrote: > This came out a couple of days ago. New World Notes covered it today, > as I did. > http://nalates.wordpress.com/2010/10/22/qarl-fizz-prim-alignment-tool/ > > In SL I use Prim Docker to do prim and texture alignment. I'm not sure > Qarl's tool will replace prim docker for me, but it is a great start. > I like Prim Docker but it is a bit awkward. Qarl's solution is much > more elegant. > > Since the code is already written and working by a former Linden, will > it be added to the SL Viewer? > > -- > Nalates Urriah (SL AV) > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting privileges -- Tateru Nino http://dwellonit.taterunino.net/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101023/aee3b8f5/attachment.htm From sllists at boroon.dasgupta.ch Fri Oct 22 12:58:46 2010 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Fri, 22 Oct 2010 21:58:46 +0200 Subject: [opensource-dev] "Internal" license on early revisions (was: Mesh Source Code ETA) In-Reply-To: References: Message-ID: <4CC1ECF6.8070705@boroon.dasgupta.ch> On 10/22/2010 09:25 PM, Brian McGroarty wrote: > If you see it happen again in the future and there hasn't been some > broad announcement about the license changing, assume it's a mistake. > Go ahead and create a JIRA for them, or mail the author listed in the > header. I noticed that some files have the "internal" license header (complete with "PROPRIETARY AND CONFIDENTIAL" etc.) when you check out early revisions of them. Can we safely assume that these early versions have been relicensed under the same conditions as later versions of those same files? In lindenlab/viewer-development, these files are affected: indra/llui/tests/llurlentry_test.cpp indra/llui/tests/llurlmatch_test.cpp indra/llui/tests/llurlentry_stub.cpp indra/lib/python/indra/__init__.py indra/llmessage/tests/llcurl_stub.cpp indra/llmessage/tests/lltesthttpclientadapter.cpp indra/llmessage/tests/lltesthttpclientadapter.h indra/llmessage/tests/lltestmessagesender.cpp indra/llmessage/tests/lltestmessagesender.h indra/llmessage/llregionpresenceverifier.cpp indra/llmessage/tests/llmockhttpclient.h indra/llmessage/llregionpresenceverifier.h indra/llprimitive/tests/llmessagesystem_stub.cpp indra/lscript/llscriptresource.h indra/lscript/llscriptresourceconsumer.h indra/lscript/llscriptresourcepool.h indra/lscript/lscript_execute/llscriptresource.cpp indra/lscript/lscript_execute/llscriptresourceconsumer.cpp indra/lscript/lscript_execute/llscriptresourcepool.cpp indra/lib/python/indra/util/simperf_oprof_interface.py Cheers, Boroondas -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101022/d33ed943/attachment.htm From stickman at gmail.com Fri Oct 22 14:24:35 2010 From: stickman at gmail.com (Stickman) Date: Fri, 22 Oct 2010 14:24:35 -0700 Subject: [opensource-dev] As a content creator, I would like... In-Reply-To: References: Message-ID: On Mon, Oct 18, 2010 at 11:42 AM, Zabb65 wrote: > The local script editing and local texture editing has already been > done before and were implemented in phoenix. Scripting was done by > Katharine and textures were done by Vaalith. Is there a patch available for local script and textures syncing with SL somewhere? Stickman From nyx at lindenlab.com Fri Oct 22 15:06:52 2010 From: nyx at lindenlab.com (Nyx Linden) Date: Fri, 22 Oct 2010 18:06:52 -0400 Subject: [opensource-dev] Mesh viewer source code In-Reply-To: <4CC1B12B.6080603@lindenlab.com> References: <4CC1B12B.6080603@lindenlab.com> Message-ID: <4CC20AFC.1010206@lindenlab.com> Library source code is now up as well! the repositories are listed below: http://bitbucket.org/lindenlab/glod http://bitbucket.org/lindenlab/colladadom http://bitbucket.org/lindenlab/llconvexdecompositionstub Let me know if there are any questions! -Nyx On 10/22/2010 11:43 AM, Nyx Linden wrote: > Sorry for the delay, there's been a few build and licensing issues > that have cropped up recently that have made it difficult to get the > source code published for the mesh viewer. That being said, the source > is now public, at the following repository: > > http://hg.secondlife.com/mesh-development/ > > Please note that there are still some build errors on some platforms, > but there have been a few requests that we release the source even > before these issues are fixed. I'll be focusing on getting these > errors fixed tomorrow, so if you encounter specific build issues, > please let me know. > > There are a few new libraries that are linked into the viewer - the > source code for these will be released soon. The new libraries are: > > glod - level of detail library we use for auto-generating different > levels of detail. Based on this library: > http://www.cs.jhu.edu/~graphics/GLOD/ We have some tweaks that make > it work with our system, and will be releasing the source shortly. > > collada - we're wrapping the standard collada libs with some code that > makes it work with our viewer. We'll be releasing the source to our > modifications shortly. > > Convex decomposition stub - We're using havok to decompose meshes into > multiple convex hulls in our official release. However, to support the > development of a fully open-source solution, we're releasing the > source code to the "stub" (non-functional) version of the library > we're providing to compile the mesh viewer. This stub should have all > the relevant information necessary to start development of a new > convex decomposition library. We hope to have the source up shortly. > > I'm very interested personally in seeing a fully open-source convex > decomposition library created to work with our mesh source code, so if > anyone would like to get started on this, please let me know and I'll > do what I can to support such an effort! > > Please note that the current state of the code isn't fully stable - > initial builds have reported a linking issue on linux, and a crash on > windows. I'll be working to resolve these issues ASAP, but if you have > any specific information on how the build is breaking, please let me > know! This will be our primary repository, so check back for updates > and build fixes :) > > Thanks everyone for your patience on waiting for the code! > > -Nyx From sllists at boroon.dasgupta.ch Fri Oct 22 18:08:26 2010 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Sat, 23 Oct 2010 03:08:26 +0200 Subject: [opensource-dev] (CTS-315) march choice for 64bit builds Message-ID: <4CC2358A.5020803@boroon.dasgupta.ch> Because SSE2 is now required anyway, -march=pentium4 is now passed for building lindenlab/mesh-development. Of course, this doesn't work for 64bit builds. (See CTS-315 .) What should march be set to for 64bit buids, if anything? Cheers, Boroondas -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101023/a4eaa3e3/attachment.htm From carlo at alinoe.com Fri Oct 22 18:19:17 2010 From: carlo at alinoe.com (Carlo Wood) Date: Sat, 23 Oct 2010 03:19:17 +0200 Subject: [opensource-dev] Mesh Source Code ETA In-Reply-To: References: Message-ID: <20101023011917.GA16730@alinoe.com> On Thu, Oct 21, 2010 at 08:56:32PM -0400, Zabb65 wrote: > They have only said they would release source, though they do not have > to release it. They are doing so out of their own good will as a > company, not by legal obligation, please remember this. I suspect they That is not entirely true... You see, they link the webkit plugin statically with Qt code (LGPL), which demands that whatever the resulting code is, is GPL or LGPL. So, if they release a binary that includes a libmedia_plugin_gstreamer.so, which is linked statically with pure LGPL-ed code, then they are legally oblidged to provide the source code of libmedia_plugin_gstreamer.so. Now if LL decides to JUST provide the sources of that plugin lib, or just put the whole mesh repository that was used to compile it on the net, is entirely up to them, of course. -- Carlo Wood From carlo at alinoe.com Fri Oct 22 18:23:05 2010 From: carlo at alinoe.com (Carlo Wood) Date: Sat, 23 Oct 2010 03:23:05 +0200 Subject: [opensource-dev] (CTS-315) march choice for 64bit builds In-Reply-To: <4CC2358A.5020803@boroon.dasgupta.ch> References: <4CC2358A.5020803@boroon.dasgupta.ch> Message-ID: <20101023012305.GB16730@alinoe.com> Why is SSE2 required now? Sorry if I missed this. On Sat, Oct 23, 2010 at 03:08:26AM +0200, Boroondas Gupte wrote: > Because SSE2 is now required anyway, -march=pentium4 is now passed for building > lindenlab/mesh-development. Of course, this doesn't work for 64bit builds. (See > CTS-315.) What should march be set to for 64bit buids, if anything? -- Carlo Wood From marc at inworlddesigns.com Fri Oct 22 18:36:18 2010 From: marc at inworlddesigns.com (Marc Adored) Date: Fri, 22 Oct 2010 21:36:18 -0400 Subject: [opensource-dev] (CTS-315) march choice for 64bit builds In-Reply-To: <20101023012305.GB16730@alinoe.com> References: <4CC2358A.5020803@boroon.dasgupta.ch> <20101023012305.GB16730@alinoe.com> Message-ID: I assume that they probably used some SSE2 optimizations for the mesh code On Fri, Oct 22, 2010 at 9:23 PM, Carlo Wood wrote: > Why is SSE2 required now? Sorry if I missed this. > > On Sat, Oct 23, 2010 at 03:08:26AM +0200, Boroondas Gupte wrote: >> Because SSE2 is now required anyway, -march=pentium4 is now passed for building >> lindenlab/mesh-development. Of course, this doesn't work for 64bit builds. (See >> CTS-315.) What should march be set to for 64bit buids, if anything? > > -- > Carlo Wood > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting privileges > From leliel.mirihi at gmail.com Fri Oct 22 22:31:49 2010 From: leliel.mirihi at gmail.com (leliel) Date: Fri, 22 Oct 2010 22:31:49 -0700 Subject: [opensource-dev] (CTS-315) march choice for 64bit builds In-Reply-To: <4CC2358A.5020803@boroon.dasgupta.ch> References: <4CC2358A.5020803@boroon.dasgupta.ch> Message-ID: On Fri, Oct 22, 2010 at 6:08 PM, Boroondas Gupte wrote: > Because SSE2 is now required anyway, -march=pentium4 is now passed for > building lindenlab/mesh-development. Of course, this doesn't work for 64bit > builds. (See CTS-315.) What should march be set to for 64bit buids, if > anything? It should be using -mtune not -march. Unfortunately the original k8 cpus didn't support sse3 so pentium4 is still the best cpu type to use on a 64bit build. From sllists at boroon.dasgupta.ch Sat Oct 23 02:42:31 2010 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Sat, 23 Oct 2010 11:42:31 +0200 Subject: [opensource-dev] (CTS-315) march choice for 64bit builds In-Reply-To: <20101023012305.GB16730@alinoe.com> References: <4CC2358A.5020803@boroon.dasgupta.ch> <20101023012305.GB16730@alinoe.com> Message-ID: <4CC2AE07.50708@boroon.dasgupta.ch> On 10/23/2010 03:23 AM, Carlo Wood wrote: > Why is SSE2 required now? Sorry if I missed this. Ah, sorry, should have linked to Runitai's comment on CTS-284 . (Also read the comments before for context.) Cheers, Boroondas -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101023/e442d635/attachment.htm From sythos at gmail.com Sat Oct 23 03:08:32 2010 From: sythos at gmail.com (Altair Sythos Memo) Date: Sat, 23 Oct 2010 12:08:32 +0200 Subject: [opensource-dev] (CTS-315) march choice for 64bit builds In-Reply-To: <4CC2358A.5020803@boroon.dasgupta.ch> References: <4CC2358A.5020803@boroon.dasgupta.ch> Message-ID: <20101023120832.e1cb389e.sythos@gmail.com> On Sat, 23 Oct 2010 03:08:26 +0200 Boroondas Gupte wrote: > Because SSE2 is now required anyway, -march=pentium4 is now passed > for building lindenlab/mesh-development. Of course, this doesn't work > for 64bit builds. (See CTS-315 > .) What should march be > set to for 64bit buids, if anything? pentium4 don't support 64bit, but "nocona" yes the other (imho better) way to select right march/mtune is use "generic" and declare *all* parameters, sort of: for 32bit: gcc -march=generic -mtune=generic -m32 -mmmx -msse -msse2 -mfpmath=both for 64bit: gcc -march=generic -mtune=generic -m64 -mmmx -msse -msse2 -mfpmath=both From leliel.mirihi at gmail.com Sat Oct 23 03:19:24 2010 From: leliel.mirihi at gmail.com (leliel) Date: Sat, 23 Oct 2010 03:19:24 -0700 Subject: [opensource-dev] (CTS-315) march choice for 64bit builds In-Reply-To: <20101023120832.e1cb389e.sythos@gmail.com> References: <4CC2358A.5020803@boroon.dasgupta.ch> <20101023120832.e1cb389e.sythos@gmail.com> Message-ID: On Sat, Oct 23, 2010 at 3:08 AM, Altair Sythos wrote: > On Sat, 23 Oct 2010 03:08:26 +0200 > Boroondas Gupte wrote: > >> ?Because SSE2 is now required anyway, -march=pentium4 is now passed >> for building lindenlab/mesh-development. Of course, this doesn't work >> for 64bit builds. (See CTS-315 >> .) What should march be >> set to for 64bit buids, if anything? > > pentium4 don't support 64bit, but "nocona" yes nocona also enables sse3 which would cut out many k8 cpus. > the other (imho better) way to select right march/mtune is use > "generic" and declare *all* parameters, sort of: This is the proper fix imho. > for 32bit: > gcc -march=generic -mtune=generic -m32 -mmmx -msse -msse2 > -mfpmath=both > > for 64bit: > gcc -march=generic -mtune=generic -m64 -mmmx -msse -msse2 > -mfpmath=both Should use -mfpmath=sse, gcc isn't very good at doing both x87 and sse fp math at the same time. From sythos at gmail.com Sat Oct 23 03:44:17 2010 From: sythos at gmail.com (Altair Sythos Memo) Date: Sat, 23 Oct 2010 12:44:17 +0200 Subject: [opensource-dev] (CTS-315) march choice for 64bit builds In-Reply-To: References: <4CC2358A.5020803@boroon.dasgupta.ch> <20101023120832.e1cb389e.sythos@gmail.com> Message-ID: <20101023124417.441b3ad9.sythos@gmail.com> On Sat, 23 Oct 2010 03:19:24 -0700 leliel wrote: > > > the other (imho better) way to select right march/mtune is use > > "generic" and declare *all* parameters, sort of: > > This is the proper fix imho. > > > for 32bit: > > gcc -march=generic -mtune=generic -m32 -mmmx -msse -msse2 > > -mfpmath=both > > > > for 64bit: > > gcc -march=generic -mtune=generic -m64 -mmmx -msse -msse2 > > -mfpmath=both > > Should use -mfpmath=sse, gcc isn't very good at doing both x87 and sse > fp math at the same time. let GCC to choose the faster way to assembly machine code... (done under GCC4.5 a lot of test in KV enviroment, but on intel up) is time for a libs update too, especially on multimedia (opeonal, pulse, SSL0.9.7 is buged, etc.etc.), as change compilefarm upgrading GCC (mainly now, mesh need high performance compilated code) From leliel.mirihi at gmail.com Sat Oct 23 04:09:51 2010 From: leliel.mirihi at gmail.com (leliel) Date: Sat, 23 Oct 2010 04:09:51 -0700 Subject: [opensource-dev] (CTS-315) march choice for 64bit builds In-Reply-To: <20101023124417.441b3ad9.sythos@gmail.com> References: <4CC2358A.5020803@boroon.dasgupta.ch> <20101023120832.e1cb389e.sythos@gmail.com> <20101023124417.441b3ad9.sythos@gmail.com> Message-ID: On Sat, Oct 23, 2010 at 3:44 AM, Altair Sythos wrote: > On Sat, 23 Oct 2010 03:19:24 -0700 > leliel wrote: > > >> >> > the other (imho better) way to select right march/mtune is use >> > "generic" and declare *all* parameters, sort of: >> >> This is the proper fix imho. >> >> > for 32bit: >> > gcc -march=generic -mtune=generic -m32 -mmmx -msse -msse2 >> > -mfpmath=both >> > >> > for 64bit: >> > gcc -march=generic -mtune=generic -m64 -mmmx -msse -msse2 >> > -mfpmath=both >> >> Should use -mfpmath=sse, gcc isn't very good at doing both x87 and sse >> fp math at the same time. > > let GCC to choose the faster way to assembly machine code... (done > under GCC4.5 a lot of test in KV enviroment, but on intel up) SSE2 is faster, mfpmath=both tells gcc to use x87 & SSE at the same time which is not an easy task given how they work completely different. And it may not even give any speed up, many CPUs share execution hardware between x87 & SSE. > is time for a libs update too, especially on multimedia (opeonal, > pulse, SSL0.9.7 is buged, etc.etc.), as change compilefarm upgrading > GCC (mainly now, mesh need high performance compilated code) The first step towards that is to stop using the archaic and down right weird x87 ABI. From carlo at alinoe.com Sat Oct 23 04:27:54 2010 From: carlo at alinoe.com (Carlo Wood) Date: Sat, 23 Oct 2010 13:27:54 +0200 Subject: [opensource-dev] LGPL violation Message-ID: <20101023112754.GA394@alinoe.com> I am not a lawyer :p, but I think that it is allowed to link an LGPL-ed library statically against a proprietary executable provided you provide the object code or source code of the work that uses the library. In other words, it must be possible to make changes to Qt and *relink*. Translating that idea to linking statically with a shared library, it is clear that one still has to be able to make changes to Qt and relink, or they are non-compliant. This means they must provide all the object code that was used to create (link) libmedia_plugin_gstreamer.so, or they must provide the source code so that people can generate this object code themselves. Imho, the only practical solution is to make the source code availabe, and most likely just all the source code of the whole viewer. On Fri, Oct 22, 2010 at 07:02:18PM -0700, Erik Anderson wrote: > Not sure this is worth sending to the list, but could you clarify that .so > files are statically linked to the executable that they are loaded into? This > is a bit confusing to me. > > Or are they considered statically linked if you use the default dynamic loading > logic, rather than hand-coding GetProcAddr calls or equivalent? Nah - none of that. libmedia_plugin_gstreamer.so (the extension is different on OS other than linux I guess) is a shared library. However, it is constructed by linking statically with a modified version of Qt that was created by LL. Obviously, the users need to know what those mods are and they should be allowed to make changes of their own. For example, someone who already made changes to this version of Qt would not be able to use the mesh viewer until LL releases the full source code, so they are non-compliant if they release a 'beta' version of a viewer without providing the means to re-link libmedia_plugin_gstreamer.so with a different Qt. -- Carlo Wood From open at autistici.org Sat Oct 23 04:37:33 2010 From: open at autistici.org (Opensource Obscure) Date: Sat, 23 Oct 2010 12:37:33 +0100 Subject: [opensource-dev] [Linux] Viewer crash with no meaningful error message when cache dir. is missing Message-ID: <51a7301c24ac8956f9b905d358aed819@localhost> Short version: if the Linux viewer can't find the cache directory (even if empty), it will crash immediately, without providing any helpful error message. This happened to me after I moved the cache location to a secondary partition, and ran the viewer while the partition wasn't mounted. As a viewer user, I'd like to get a meaningful error message in such a situation. Opensource Obscure From marc at inworlddesigns.com Sat Oct 23 04:48:57 2010 From: marc at inworlddesigns.com (Marc Adored) Date: Sat, 23 Oct 2010 07:48:57 -0400 Subject: [opensource-dev] [Linux] Viewer crash with no meaningful error message when cache dir. is missing In-Reply-To: <51a7301c24ac8956f9b905d358aed819@localhost> References: <51a7301c24ac8956f9b905d358aed819@localhost> Message-ID: Maybe its crashing because it cant "create" the missing cache folder because that mount point doesn't even exist not really because it cant find it. It automatically creates it if it doesnt exist normally. Either way a error message stating what happened would be very helpful :P On Sat, Oct 23, 2010 at 7:37 AM, Opensource Obscure wrote: > Short version: if the Linux viewer can't find the cache > directory (even if empty), it will crash immediately, > without providing any helpful error message. > > This happened to me after I moved the cache location > to a secondary partition, and ran the viewer while the > partition wasn't mounted. > > As a viewer user, I'd like to get a meaningful error > message in such a situation. > > > Opensource Obscure > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting privileges > From lee.ponzu at gmail.com Sat Oct 23 08:20:04 2010 From: lee.ponzu at gmail.com (Ponzu) Date: Sat, 23 Oct 2010 11:20:04 -0400 Subject: [opensource-dev] Building Alignment Tool by Qarl Fizz In-Reply-To: References: Message-ID: Here's another link to a video. I hope LL can negotiate a price, or a truce, or whatever. http://www.qarl.com/qLab/?p=66 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101023/7b0076f2/attachment.htm From sllists at boroon.dasgupta.ch Sat Oct 23 09:00:50 2010 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Sat, 23 Oct 2010 18:00:50 +0200 Subject: [opensource-dev] [META] User stories and issue tracker readability Message-ID: <4CC306B2.60405@boroon.dasgupta.ch> As a user of the Second Life issue tracker (jira) who often sorts or searches through others' issues, I'd like people creating or editing issues to place the (sometimes lengthy) user stories into the *Description* field, /not/ the *Summary* field. /The summary should be as short as possible/ while still conveying what the issue is about. The role for whom the issue matters (i.e. "As a ..., I ...") and the specifics of the motivation / reason for the issue are important when examining a single issue, but aren't too helpful when looking for duplicates of other issues or when searching for already existing issues of a wish or problem you have. Even worse, because the space for displaying the summary is very limited in some of the greenhopper views, you often only see the "As a ..." part while the rest gets cut off, so you can't tell at one glance what an issue being discussed is about at all. Think of an issue as a little book. The story you want to tell belongs to the inside (the description). On the cover (summary), you want the story's title (catchy and ideally different from the title of other books), not the first chapter. What do you think? Cheers, Boroondas -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101023/3843d7f5/attachment.htm From joel.foner at gmail.com Sat Oct 23 09:22:24 2010 From: joel.foner at gmail.com (Joel Foner) Date: Sat, 23 Oct 2010 12:22:24 -0400 Subject: [opensource-dev] User story: Searchable contacts and inventory notes Message-ID: As a resident, I would like to be able to search contacts based on contents of contact notes, picks or content of 1st/2nd life tab text. In a related (maybe another story but connected) way, I would like to be able to record notes about inventory items, and search them in the same way. Joel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101023/4237324f/attachment.htm From suezanne at gmail.com Sat Oct 23 09:25:05 2010 From: suezanne at gmail.com (SuezanneC Baskerville) Date: Sat, 23 Oct 2010 11:25:05 -0500 Subject: [opensource-dev] [META] User stories and issue tracker readability In-Reply-To: <4CC306B2.60405@boroon.dasgupta.ch> References: <4CC306B2.60405@boroon.dasgupta.ch> Message-ID: Coincidentally right next to Boroondas's message in my gmail was a message about a change in a years old jira issue I created. Part of the change was to add the words "As a user," to the Summary field. https://jira.secondlife.com/browse/VWR-675 They also changed the importance from minor to major. I suspect these two actions are connected. I suspect that people are reading instructions that give them the impression that if they want issues to get proper consideration they need to put "As a user" at the beginning of the description field. Personally it seems kind of stupid to me to make people type the phrase "As a user" or similar in the beginning of a text field. If that information is important it should be be in a separate field with a dropdown list of cholces. Then you could sort and filter issues based on "Reporter-Type". On Sat, Oct 23, 2010 at 11:00 AM, Boroondas Gupte < sllists at boroon.dasgupta.ch> wrote: > As a user of the Second Life issue tracker (jira) who often sorts or > searches through others' issues, I'd like people creating or editing issues > to place the (sometimes lengthy) user stories into the *Description*field, > *not* the *Summary* field. *The summary should be as short as possible*while still conveying what the issue is about. The role for whom the issue > matters (i.e. "As a ..., I ...") and the specifics of the motivation / > reason for the issue are important when examining a single issue, but aren't > too helpful when looking for duplicates of other issues or when searching > for already existing issues of a wish or problem you have. > > Even worse, because the space for displaying the summary is very limited in > some of the greenhopper views, you often only see the "As a ..." part while > the rest gets cut off, so you can't tell at one glance what an issue being > discussed is about at all. > > Think of an issue as a little book. The story you want to tell belongs to > the inside (the description). On the cover (summary), you want the story's > title (catchy and ideally different from the title of other books), not the > first chapter. > > What do you think? > > Cheers, > Boroondas > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting > privileges > -- v i r t u a l w o r l d e n t h u s i a s t -- http://www.google.com/profiles/s u e z a n n e -- -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101023/3c448069/attachment.htm From erikba at odysseus.anderson.name Sat Oct 23 11:46:20 2010 From: erikba at odysseus.anderson.name (Erik Anderson) Date: Sat, 23 Oct 2010 11:46:20 -0700 Subject: [opensource-dev] LGPL violation In-Reply-To: <20101023112754.GA394@alinoe.com> References: <20101023112754.GA394@alinoe.com> Message-ID: I'm thinking that it may not require full source code if the ABI is published at least -- the only "static link" that seems involved here is whatever stub (.a?) is necessary to specify the ABI. That would permit someone to link to the library with alternate code (or replace the library with free source if necessary). It looks like they're going down a similar route with the mesh deconstruction code. On Sat, Oct 23, 2010 at 4:27 AM, Carlo Wood wrote: > I am not a lawyer :p, but I think that it is allowed to link an LGPL-ed > library statically against a proprietary executable provided you > provide the object code or source code of the work that uses the library. > > In other words, it must be possible to make changes to Qt and *relink*. > > Translating that idea to linking statically with a shared library, it > is clear that one still has to be able to make changes to Qt and relink, > or they are non-compliant. This means they must provide all the object > code that was used to create (link) libmedia_plugin_gstreamer.so, or > they must provide the source code so that people can generate this > object code themselves. > > Imho, the only practical solution is to make the source code availabe, > and most likely just all the source code of the whole viewer. > > On Fri, Oct 22, 2010 at 07:02:18PM -0700, Erik Anderson wrote: > > Not sure this is worth sending to the list, but could you clarify that > .so > > files are statically linked to the executable that they are loaded into? > This > > is a bit confusing to me. > > > > Or are they considered statically linked if you use the default dynamic > loading > > logic, rather than hand-coding GetProcAddr calls or equivalent? > > Nah - none of that. libmedia_plugin_gstreamer.so (the extension is > different > on OS other than linux I guess) is a shared library. However, it is > constructed > by linking statically with a modified version of Qt that was created by LL. > Obviously, the users need to know what those mods are and they should be > allowed to make changes of their own. > > For example, someone who already made changes to this version of Qt would > not be able to use the mesh viewer until LL releases the full source code, > so they are non-compliant if they release a 'beta' version of a viewer > without > providing the means to re-link libmedia_plugin_gstreamer.so with a > different Qt. > > -- > Carlo Wood > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101023/39b424c8/attachment.htm From lee.ponzu at gmail.com Sat Oct 23 11:49:34 2010 From: lee.ponzu at gmail.com (Ponzu) Date: Sat, 23 Oct 2010 14:49:34 -0400 Subject: [opensource-dev] Latest viewer-development crashing.... Message-ID: I made a clean download of viewer-development, the cloned it to ponzu-dev. (I was having trouble with fmod, so this cleaned that up for me.) Now I get crashes. Not complaining, just attaching my log files in case someone is interested. ponzu -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101023/f47d51b9/attachment-0001.htm -------------- next part -------------- A non-text attachment was scrubbed... Name: Second Life_2010-10-23-143856_iMac.crash Type: application/octet-stream Size: 36332 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101023/f47d51b9/attachment-0001.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: Archive.zip Type: application/zip Size: 70348 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101023/f47d51b9/attachment-0001.zip From secret.argent at gmail.com Sat Oct 23 13:27:14 2010 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sat, 23 Oct 2010 15:27:14 -0500 Subject: [opensource-dev] Building Alignment Tool by Qarl Fizz In-Reply-To: References: Message-ID: <943BFB55-5AE1-4E4A-A77F-2511FC3425FD@gmail.com> On 2010-10-22, at 14:00, Nalates Urriah wrote: > > Since the code is already written and working by a former Linden, will it be added to the SL Viewer? Qarl's comment that TPVs are free to use it and that his rates for Linden Lab are reasonable imply... not yet. :) From xotmid at gmail.com Sat Oct 23 13:37:34 2010 From: xotmid at gmail.com (Brandon Husbands) Date: Sat, 23 Oct 2010 15:37:34 -0500 Subject: [opensource-dev] Building Alignment Tool by Qarl Fizz In-Reply-To: <943BFB55-5AE1-4E4A-A77F-2511FC3425FD@gmail.com> References: <943BFB55-5AE1-4E4A-A77F-2511FC3425FD@gmail.com> Message-ID: Just write our implementation, not using any of his code. On Sat, Oct 23, 2010 at 3:27 PM, Argent Stonecutter wrote: > > On 2010-10-22, at 14:00, Nalates Urriah wrote: > > > > Since the code is already written and working by a former Linden, will it > be added to the SL Viewer? > > Qarl's comment that TPVs are free to use it and that his rates for Linden > Lab are reasonable imply... not yet. :) > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting > privileges > -- ------------------------------------------------------------------------------------------------------------------------------- This email is a private and confidential communication. Any use of email may be subject to the laws and regulations of the United States. You may not Repost, Distribute nor reproduce any content of this message. ------------------------------------------------------------------------------------------------------------------------------- ------------------------------------------------------------------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101023/5f59d3d7/attachment.htm From robertltux at gmail.com Sat Oct 23 14:10:43 2010 From: robertltux at gmail.com (Robert Martin) Date: Sat, 23 Oct 2010 17:10:43 -0400 Subject: [opensource-dev] Updating the Meshes and Morphs to export to DAE format possible?? Message-ID: Since the Jira got stomped during the last upgrade i was thinking at this point if we wanted to update the meshes and morphs dialog (which has been picked up by a few TPVs) we might as well have it export the avatar as a .dae package. This will allow folks to base a Mesh avatar on the "legacy" mesh. Comments?? -- Robert L Martin (doing this will also allow for needed perms locking) From lee.ponzu at gmail.com Sat Oct 23 17:41:57 2010 From: lee.ponzu at gmail.com (Ponzu) Date: Sat, 23 Oct 2010 20:41:57 -0400 Subject: [opensource-dev] Building Alignment Tool by Qarl Fizz In-Reply-To: References: <943BFB55-5AE1-4E4A-A77F-2511FC3425FD@gmail.com> Message-ID: On Sat, Oct 23, 2010 at 4:37 PM, Brandon Husbands wrote: > Just write our implementation, not using any of his code. It's that word "just" that makes it sound soooo easy 8-) > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101023/f4042c42/attachment.htm From sllists at boroon.dasgupta.ch Sun Oct 24 13:44:19 2010 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Sun, 24 Oct 2010 22:44:19 +0200 Subject: [opensource-dev] 64 bit pointers In-Reply-To: References: Message-ID: <4CC49AA3.8050002@boroon.dasgupta.ch> [CCing opensource-dev as this could be of general interest.] Hi Ponzu, On 10/24/2010 07:07 PM, Ponzu wrote: > Hi, > > I noticed your jira about casting a pointer to a U32, and of course > you are correct. Thanks! Are you referring to only the bug report (CTS-323 ) or also to my suggested fix ? > My question is why you would build a 64-bit viewer, anyway? I am not > a Linux guy, so let me ask, can a 64-bit kernel support a 32-bit > application? Yes, a 64-bit kernel can support 32-bit applications. In particular, all of the following combinations usually work: * 32-bit CPU, 32-bit kernel, 32-bit userland, 32-bit application (duh) * 64-bit CPU, 32-bit kernel, 32-bit userland, 32-bit application * 64-bit CPU, 64-bit kernel, 32-bit userland, 32-bit application * 64-bit CPU, 64-bit kernel, mulitlib userland, 32-bit application <--- this is the interesting case * 64-bit CPU, 64-bit kernel, mulitlib userland, 64-bit application * 64-bit CPU, 64-bit kernel, 64-bit userland, 64-bit application (well, of course) "Multilib" means that some important libraries are present on the system in both, 32-bit and 64-bit versions. 32-bit application that only need these libraries run fine on such systems. GStreamer's library however, that are used by SL for streaming media on Linux, is on most multilib distributions not one of these libraries, so 32-bit Second Life binaries will run on these systems, but lack support for video and audio stream playback. If you want streaming media support, you're thus left with the following options: 1. Only run a 32-bit operating system (either 32-bit kernel, or 64-bit kernel with 32-bit userland) * Though ... why did I buy 64-bit hardware, then? 2. Run an additional 32-bit operating system for using SL * With dual-boot and a common /home on a separate partition, this is not too difficult. * ... but I'd rather just maintain one system ;-) 3. Run SL in a 32-bit chroot or a 32-bit VM * SL is having performance problems as-is, adding a VM layer is probably not the best idea. (Yes, I know current VM technology can have very little overhead, but there's still some.) * Installing a fresh system is much less work than setting up a suitable chroot environment, so I'd rather go with option 2 above 4. Manually install a 32-bit GStreamer (probably in parallel to the 64-bit GStreamer that might be needed by other applications) * Never tried this, but could imagine this to be a PITA until it works 5. Build a 64-bit SLPlugin binary * Because 32-bit SL can talk to a 64-bit SLPlugin (and the 64-bit SLPlugin can use 64-bit GStreamer alright) this would suffice to provide streaming media support * If I do this ... why not go with option 6 below and build the whole viewer? It's not much harder. 6. Build SL myself (fixing any 64-bit specific problems, or get others to fix them if I can't do it myself) 7. Use a TPV that provides 64-bit binaries Because I like to change the viewer and am thus building myself anyway, option 6 is the most attractive to me. (Building a 32-bit binary would probably require to go with one of the options 1-3, i.e. do it in a 32-bit environment.) Ideally, fixing the issues that creep up when building 64bit makes the source more portable in a generic sense, so that we'd have less issues left once we want to build on yet another platform. (Solaris? iPod/Phone/Pad/Whateva? maemo or meeGo? *BSD? Your favorite game console platform? You're university's/company's HPC cluster (no dual boot there!)? The Windows version of 2072 that'll only be available in 128-bit and 256-bit variants? Ok ... most not very realistic, but you get the idea.) > If so the 32-bit app will usually run faster. They do in the HP-UX > and Solaris environments, anyway. I've never worked with these two UNIX systems, but I don't think this is generally true. On Linux and Windows, a properly optimized 64-bit binary should usually perform the same or better than a (also optimized) 32-bit binary build from the same source. In a lot of cases the difference will not be significant, but there are exceptions: Especially for number-crunching (e.g. in scientific simulations) at high precision 64-bit binaries often outperform their 32-bit counterparts. > The only good reason to build a 64-bit app is if the 4GB memory model > makes things difficult, for example, processing LARGE HD images. I only have 4GB of RAM (and another 4 swap), so that isn't my reason. While SL is known to be memory hungry, if it hits 4GB we've probably introduced another major memory leak. > If longs and pointers are 64-bit, they take up twice the memory bus > bandwidth, and they use twice as much register space in the CPU. This is true and the increased size of binaries as well as RAM usage due to bigger pointers are indeed sometimes noticeable (though almost never significant compared to the total filesize / memory requirement). For longs ... well, if the application doesn't benefit enough from the increased value range to make up for the increased memory usage, you should have used ints in the first place. :-P Cheers, Boroondas -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101024/8d176dad/attachment.htm From secret.argent at gmail.com Sun Oct 24 14:25:32 2010 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sun, 24 Oct 2010 16:25:32 -0500 Subject: [opensource-dev] 64 bit pointers In-Reply-To: <4CC49AA3.8050002@boroon.dasgupta.ch> References: <4CC49AA3.8050002@boroon.dasgupta.ch> Message-ID: <570C330E-FF7E-43AB-8C5B-B9B1BB784FC7@gmail.com> On 2010-10-24, at 15:44, Boroondas Gupte wrote: >> If so the 32-bit app will usually run faster. They do in the HP-UX and Solaris environments, anyway. > I've never worked with these two UNIX systems, but I don't think this is generally true. On Linux and Windows, a properly optimized 64-bit binary should usually perform the same or better than a (also optimized) 32-bit binary build from the same source. In a lot of cases the difference will not be significant, but there are exceptions: Especially for number-crunching (e.g. in scientific simulations) at high precision 64-bit binaries often outperform their 32-bit counterparts. This has nothing to do with the OS. In every environment I know, 32-bit is faster then 64 bit. Every environment but one. That exception is intel's x86 and amd64 architecture. That's because in the AMD extensions to the 64 bit architecture, AMD not only extended the instruction set to support 64 bit, but they quadrupled the size of the register file. The biggest problem that the intel architecture had was the tiny register file, so on x86 the 64-bit mode is MUCH MUCH easier to optimize for than the 32 bit mode. From akanevsky at productengine.com Sun Oct 24 17:29:23 2010 From: akanevsky at productengine.com (Anya Kanevsky) Date: Sun, 24 Oct 2010 17:29:23 -0700 Subject: [opensource-dev] Daily Scrum Summary - Friday, October 22 Message-ID: https://wiki.secondlife.com/wiki/Snowstorm_Daily_Scrum_Archive Date: Fri Oct 22 == GENERAL NOTES == * Merge Monkey of the Day: Oz == DAILY SCRUM == === Merov === PAST * STORM-330: Studied in details. Closed as "Cannot Reproduce" * STORM-406: Discussed with Vadim and Boroondas. Ready for review. * STORM-173: Found a fix. Ready for review. FUTURE * Merge Monkeying and code reviews * Pick some SG 2.0 port issues to move * STORM-104: kdu upgrade * STORM-105 : Perf decompression: put new data out, check the work done by opensource-dev community on similar tests. IMPEDIMENTS * Latest KDU bits: still waiting... ===Oz Linden=== PAST * Meetings and other work on new TPV directory site FUTURE * Learn how to do library change tests in TeamCity * Review backlog for osdev candidate issues w/ Esbee IMPEDIMENTS * none === Q Linden=== PAST * crashhunting antialiasing * release * STORM-297 FUTURE * triage * meetings * beta 2.3 * bisecing the 255 char issue IMPEDIMENTS * Antialiasing === Esbee Linden === PAST * Draft of Viewer 2.3 Beta 1 Announcement Blog Post * Coordinating Viewer 2.3 Beta 1 release * Viewer Beta and Release Process work * VWR Triage FUTURE * Discussions about crashers in 2.3 Beta 1 * Systems requirements analysis * Preferences review * VWR Triage * Viewer 2.3 Beta 1 Release Coordination * Mockup wiki page for Viewer downloads * Review STORM-255 * Finish chart reporting review on Jira IMPEDIMENTS * AA and Viewer 2.3 Beta 1 === Paul ProductEngine=== PAST: * STORM-39 As a User, I want to control how long a chat toast appears before it fades. Please add fade time back to Chat preferences. ** WIP. Estimate ~ 4-6 hours FUTURE: * STORM-39 As a User, I want to control how long a chat toast appears before it fades. Please add fade time back to Chat preferences. IMPEDIMENTS: * none === Seth Productengine === PAST: * BUG (STORM-426) Menu button looks as being pressed while its menu is displayed by another control ** Fixed. Published at review board: https://codereview.productengine.com/secondlife/r/889/ FUTURE: * BUG (STORM-426) Menu button looks as being pressed while its menu is displayed by another control ** Do some more fix testing and code clean up. * BUG (STORM-296) Cursor doesn't change when trying to drag and drop non-landmark items into Favorites folder ** Estimated: 6 hours. IMPEDIMENTS: * none === Andrew Productengine === PAST: * STORM-322 (Group Member Search: gives more entries then the search string suggests) ** Tested, fixed found problems and sent for review. * Bug STORM-184 (Save is enabled for outfits consisting of original items) ** Couldn't reproduce, will discuss with Plan tomorrow. FUTURE: - Critical bug STORM-95 (Upload hangs client). IMPEDIMENTS: * none === Vadim Productengine === PAST: * Bug STORM-184 (Save is enabled for outfits consisting of original items): ** Found out the bug is Windows-specific, reassigned to Andrew. * Bug STORM-224 (Change label "Fabric" to read "Texture"): ** Fixed. * Bug STORM-406 (build failure): ** Tested and rejected the fix as not working for non-standalone Linux/x86 build. * Extensive bugfixing-related discussions and code review. FUTURE: * I hope to take something new from sprint 6. IMPEDIMENTS: *none === Andrey Productengine === PAST: * completed regression testing of Beta1 2.3.0. No major issues were found in EN locale, but I found 1 severe issue in NL locale occasionally. * started Beta1 Jiras verification FUTURE: * pickup Beta2 build IMPEDIMENTS: * none -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101024/4bc85f9b/attachment-0001.htm From sllists at boroon.dasgupta.ch Mon Oct 25 07:01:47 2010 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Mon, 25 Oct 2010 16:01:47 +0200 Subject: [opensource-dev] (standalone/64-bit) build issues with Mesh viewer source code (and fixes for some of them. Yay!) In-Reply-To: <4CC1B12B.6080603@lindenlab.com> References: <4CC1B12B.6080603@lindenlab.com> Message-ID: <4CC58DCB.2040108@boroon.dasgupta.ch> So ... I've been busy during the weeking poking the mesh viewer source code with a stick g++ and can report some results. It seems quite some of the issues were (re)introduced by mistakes in merge conflict resolution. Some others are new. Here are the one's I've filed issues for already: CTS-314 : Fix of VWR-20810 / SNOW-503 (Quote EXE_STAGING_DIR to prevent it failing with some paths) lost in merge * VWR-20810 was fixed at b987077e9bbb , but it looks like the fix got lost in the merge at 538a49313042 . * Re-fixed * Ready for review CTS-315 : -march=pentium4 may not be used for 64bit builds * Started discussion on the mailing list about how to fix this correctly * Until that's decided, work around with sed '175 s/-march=pentium4 //' -i indra/cmake/00-Common.cmake when building 64-bit. CTS-318 : Fix of VWR-20809 / SNOW-504 (Do not depend on stage_thirds_party_libs for a standalone build.) lost in merge * VWR-20809 was fixed at c5ddd1e361ae , but it looks like the fix got lost in the merge at 538a49313042 . * Re-fixed * Ready for review CTS-319 : Fix of VWR-20670 / SNOW-506 (Protection on LLInstanceTracker base in LLEventTimer needs to be public for gcc >4.1) lost in merge * VWR-20670 was fixed at 20860bbd5cae , but it looks like the fix got lost in the merge at ad384ab52275 . * Re-fixed * Ready for review CTS-320 : use system zlib for standalone * Fixed, using the same pattern as already used elsewhere in the code o Noticed some mistakes in the fix and corrected those * Ready for review CTS-323 : Don't cast pointers to U32 * Fixed by using uintptr_t instead. o This type isn't part of the current C++ standard (might become part of the next), but it's already used elsewhere in the code, so I assume all of our build platforms support it. * Ready for review Now I'm stuck at where it won't find the new libraries , even when I build and install them. I guess some CMake glue for standalone is still missing. (Or maybe I should just wait for auto-build?) Also, when tests are enabled, one of them errors out. That's right, it's *not even failing*. :-P Running: /usr/bin/python ${SRC_DIR}/indra/llmessage/tests/test_llsdmessage_peer.py ${BUILD_DIR}/llmessage/INTEGRATION_TEST_llsdmessage Unit test group_started name=llsdmessage Failed to catch N11LLEventPump11DupPumpNameE Failure running: /usr/bin/python ${SRC_DIR}/indra/llmessage/tests/test_llsdmessage_peer.py ${BUILD_DIR}/llmessage/INTEGRATION_TEST_llsdmessage Error: 245 make[2]: *** [llmessage/INTEGRATION_TEST_llsdmessage] Error 245 make[1]: *** [llmessage/CMakeFiles/INTEGRATION_TEST_llsdmessage.dir/all] Error 2 make: *** [all] Error 2 Wolfpup observed that INTEGRATION_TEST_llcapabilitylistener also has runtime issues. Cheers, Boroondas -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101025/13143921/attachment.htm From wolfpup67 at earthlink.net Mon Oct 25 07:27:49 2010 From: wolfpup67 at earthlink.net (WolfPup Lowenhar) Date: Mon, 25 Oct 2010 10:27:49 -0400 Subject: [opensource-dev] (standalone/64-bit) build issues with Mesh viewer source code (and fixes for some of them. Yay!) In-Reply-To: <4CC58DCB.2040108@boroon.dasgupta.ch> References: <4CC1B12B.6080603@lindenlab.com> <4CC58DCB.2040108@boroon.dasgupta.ch> Message-ID: <001801cb7450$cd241210$676c3630$@net> Just so everyone knows I'm building on Windows 7 32-bit and both if the tests that Boroondas mentions are actually memory leaking BADLY(test ballons to nearly 1GB of mem usage) on my system just before crashing or I terminated the process. From: opensource-dev-bounces at lists.secondlife.com [mailto:opensource-dev-bounces at lists.secondlife.com] On Behalf Of Boroondas Gupte Sent: Monday, October 25, 2010 10:02 AM To: Nyx Linden Cc: opensource-dev Subject: [opensource-dev] (standalone/64-bit) build issues with Mesh viewer source code (and fixes for some of them. Yay!) So ... I've been busy during the weeking poking the mesh viewer source code with a stick g++ and can report some results. It seems quite some of the issues were (re)introduced by mistakes in merge conflict resolution. Some others are new. Here are the one's I've filed issues for already: CTS-314 : Fix of VWR-20810 / SNOW-503 (Quote EXE_STAGING_DIR to prevent it failing with some paths) lost in merge * VWR-20810 was fixed at b987077e9bbb , but it looks like the fix got lost in the merge at 538a49313042 . * Re-fixed * Ready for review CTS-315 : -march=pentium4 may not be used for 64bit builds * Started discussion on the mailing list about how to fix this correctly * Until that's decided, work around with . sed '175 s/-march=pentium4 //' -i indra/cmake/00-Common.cmake when building 64-bit. CTS-318 : Fix of VWR-20809 / SNOW-504 (Do not depend on stage_thirds_party_libs for a standalone build.) lost in merge * VWR-20809 was fixed at c5ddd1e361ae , but it looks like the fix got lost in the merge at 538a49313042 . * Re-fixed * Ready for review CTS-319 : Fix of VWR-20670 / SNOW-506 (Protection on LLInstanceTracker base in LLEventTimer needs to be public for gcc >4.1) lost in merge * VWR-20670 was fixed at 20860bbd5cae , but it looks like the fix got lost in the merge at ad384ab52275 . * Re-fixed * Ready for review CTS-320 : use system zlib for standalone * Fixed, using the same pattern as already used elsewhere in the code * Noticed some mistakes in the fix and corrected those * Ready for review CTS-323 : Don't cast pointers to U32 * Fixed by using uintptr_t instead. * This type isn't part of the current C++ standard (might become part of the next), but it's already used elsewhere in the code, so I assume all of our build platforms support it. * Ready for review Now I'm stuck at where it won't find the new libraries, even when I build and install them. I guess some CMake glue for standalone is still missing. (Or maybe I should just wait for auto-build?) Also, when tests are enabled, one of them errors out. That's right, it's not even failing. :-P Running: /usr/bin/python ${SRC_DIR}/indra/llmessage/tests/test_llsdmessage_peer.py ${BUILD_DIR}/llmessage/INTEGRATION_TEST_llsdmessage Unit test group_started name=llsdmessage Failed to catch N11LLEventPump11DupPumpNameE Failure running: /usr/bin/python ${SRC_DIR}/indra/llmessage/tests/test_llsdmessage_peer.py ${BUILD_DIR}/llmessage/INTEGRATION_TEST_llsdmessage Error: 245 make[2]: *** [llmessage/INTEGRATION_TEST_llsdmessage] Error 245 make[1]: *** [llmessage/CMakeFiles/INTEGRATION_TEST_llsdmessage.dir/all] Error 2 make: *** [all] Error 2 Wolfpup observed that INTEGRATION_TEST_llcapabilitylistener also has runtime issues. Cheers, Boroondas _____ No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1152 / Virus Database: 422/3218 - Release Date: 10/25/10 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101025/a2131c27/attachment-0001.htm From nyx at lindenlab.com Mon Oct 25 08:59:13 2010 From: nyx at lindenlab.com (Nyx Linden) Date: Mon, 25 Oct 2010 11:59:13 -0400 Subject: [opensource-dev] (standalone/64-bit) build issues with Mesh viewer source code (and fixes for some of them. Yay!) In-Reply-To: <001801cb7450$cd241210$676c3630$@net> References: <4CC1B12B.6080603@lindenlab.com> <4CC58DCB.2040108@boroon.dasgupta.ch> <001801cb7450$cd241210$676c3630$@net> Message-ID: I'm out of the office today and tomorrow, but will definitely be looking into these patches and remaining issues on Wednesday. Thanks a ton for helping us out! Nyx Sent from my iPhone On Oct 25, 2010, at 10:27 AM, "WolfPup Lowenhar" wrote: > Just so everyone knows I?m building on Windows 7 32-bit and both if > the tests that Boroondas mentions are actually memory leaking BADLY( > test ballons to nearly 1GB of mem usage) on my system just before cr > ashing or I terminated the process. > > > > From: opensource-dev-bounces at lists.secondlife.com [mailto:opensource- > dev-bounces at lists.secondlife.com] On Behalf Of Boroondas Gupte > Sent: Monday, October 25, 2010 10:02 AM > To: Nyx Linden > Cc: opensource-dev > Subject: [opensource-dev] (standalone/64-bit) build issues with Mesh > viewer source code (and fixes for some of them. Yay!) > > > > So ... I've been busy during the weeking poking the mesh viewer > source code with a stick g++ and can report some results. It seems > quite some of the issues were (re)introduced by mistakes in merge > conflict resolution. Some others are new. Here are the one's I've > filed issues for already: > > CTS-314: Fix of VWR-20810 / SNOW-503 (Quote EXE_STAGING_DIR to > prevent it failing with some paths) lost in merge > > VWR-20810 was fixed at b987077e9bbb, but it looks like the fix got > lost in the merge at 538a49313042. > Re-fixed > Ready for review > CTS-315: -march=pentium4 may not be used for 64bit builds > > Started discussion on the mailing list about how to fix this correctly > Until that's decided, work around with > ? sed '175 s/-march=pentium4 //' -i indra/cmake/00-Common.cm > ake > when building 64-bit. > > CTS-318: Fix of VWR-20809 / SNOW-504 (Do not depend on > stage_thirds_party_libs for a standalone build.) lost in merge > > VWR-20809 was fixed at c5ddd1e361ae , but it looks like the fix got > lost in the merge at 538a49313042. > Re-fixed > Ready for review > CTS-319: Fix of VWR-20670 / SNOW-506 (Protection on > LLInstanceTracker base in LLEventTimer needs to be public for gcc > >4.1) lost in merge > > VWR-20670 was fixed at 20860bbd5cae, but it looks like the fix got > lost in the merge at ad384ab52275. > Re-fixed > Ready for review > CTS-320: use system zlib for standalone > > Fixed, using the same pattern as already used elsewhere in the code > Noticed some mistakes in the fix and corrected those > Ready for review > CTS-323: Don't cast pointers to U32 > > Fixed by using uintptr_t instead. > This type isn't part of the current C++ standard (might become part > of the next), but it's already used elsewhere in the code, so I > assume all of our build platforms support it. > Ready for review > > > Now I'm stuck at where it won't find the new libraries, even when I > build and install them. I guess some CMake glue for standalone is > still missing. (Or maybe I should just wait for auto-build?) > > Also, when tests are enabled, one of them errors out. That's right, > it's not even failing. :-P > > Running: /usr/bin/python ${SRC_DIR}/indra/llmessage/tests/ > test_llsdmessage_peer.py ${BUILD_DIR}/llmessage/ > INTEGRATION_TEST_llsdmessage > Unit test group_started name=llsdmessage > Failed to catch N11LLEventPump11DupPumpNameE > Failure running: /usr/bin/python ${SRC_DIR}/indra/llmessage/tests/ > test_llsdmessage_peer.py ${BUILD_DIR}/llmessage/ > INTEGRATION_TEST_llsdmessage > Error: 245 > make[2]: *** [llmessage/INTEGRATION_TEST_llsdmessage] Error 245 > make[1]: *** [llmessage/CMakeFiles/INTEGRATION_TEST_llsdmessage.dir/ > all] Error 2 > make: *** [all] Error 2 > Wolfpup observed that INTEGRATION_TEST_llcapabilitylistener also has > runtime issues. > > Cheers, > Boroondas > > No virus found in this message. > Checked by AVG - www.avg.com > Version: 10.0.1152 / Virus Database: 422/3218 - Release Date: 10/25/10 > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting > privileges -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101025/7c4f76fa/attachment.htm From sllists at boroon.dasgupta.ch Mon Oct 25 12:56:29 2010 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Mon, 25 Oct 2010 21:56:29 +0200 Subject: [opensource-dev] Crashing integration tests (was: (standalone/64-bit) build issues with Mesh viewer source code (and fixes for some of them. Yay!)) In-Reply-To: <4CC58DCB.2040108@boroon.dasgupta.ch> References: <4CC1B12B.6080603@lindenlab.com> <4CC58DCB.2040108@boroon.dasgupta.ch> Message-ID: <4CC5E0ED.6070901@boroon.dasgupta.ch> On 10/25/2010 04:01 PM, Boroondas Gupte wrote: > Also, when tests are enabled, one of them errors out. That's right, > it's *not even failing*. :-P > > Running: /usr/bin/python ${SRC_DIR}/indra/llmessage/tests/test_llsdmessage_peer.py ${BUILD_DIR}/llmessage/INTEGRATION_TEST_llsdmessage > Unit test group_started name=llsdmessage > Failed to catch N11LLEventPump11DupPumpNameE > Failure running: /usr/bin/python ${SRC_DIR}/indra/llmessage/tests/test_llsdmessage_peer.py ${BUILD_DIR}/llmessage/INTEGRATION_TEST_llsdmessage > Error: 245 > make[2]: *** [llmessage/INTEGRATION_TEST_llsdmessage] Error 245 > make[1]: *** [llmessage/CMakeFiles/INTEGRATION_TEST_llsdmessage.dir/all] Error 2 > make: *** [all] Error 2 > > Wolfpup observed that INTEGRATION_TEST_llcapabilitylistener also has > runtime issues. What is interesting ---and honestly a bit frightening--- is that on Linux with GNU make you don't have to disable the integration tests with -DLL_TESTS=OFF or set them up to be skipped in the test's source with skip("...") to work around these build-stoppers. If you just re-issue make again (without cleaning first), it'll *continue the build without re-trying the test* that just before not-even-failed. While incremental builds are a great thing, and tests don't need to be re-run when they've /previously succeeded/ and none of their dependencies nor the test itself changed since, I guess this isn't how tests are supposed to work. If a test /fails/ or even /causes a runtime error/, it should not be skipped until explicitly disabled, either by LL_TESTS or in the test's source. How else would you know whether you've fixed the issue? User story As a developer, I want to be sure the build doesn't (seem to) succeed when I've broken a test I didn't disable. (At least as long as I haven't tampered with dependency declarations or the build system.) Boroondas -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101025/39061cd2/attachment.htm From sllists at boroon.dasgupta.ch Mon Oct 25 14:01:14 2010 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Mon, 25 Oct 2010 23:01:14 +0200 Subject: [opensource-dev] Crashing integration tests In-Reply-To: <649411.90154.qm@web43509.mail.sp1.yahoo.com> References: <4CC1B12B.6080603@lindenlab.com> <4CC58DCB.2040108@boroon.dasgupta.ch> <4CC5E0ED.6070901@boroon.dasgupta.ch> <649411.90154.qm@web43509.mail.sp1.yahoo.com> Message-ID: <4CC5F01A.4000709@boroon.dasgupta.ch> On 10/25/2010 10:56 PM, Nicky Perian wrote: > I found the same thing about failed tests on 2d and subsequent builds. > The build has an error the first time but passes the second. This was > on VC++Express 2005 build. And, didn't matter about redoing develop.py. So this isn't GNU make or even Makefile specific. Either it's a CMake bug, or we make some mistake at using CMake, probably not declaring all dependencies correctly. Boroondas -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101025/1fdb6c3c/attachment.htm From zabb65 at gmail.com Mon Oct 25 16:48:12 2010 From: zabb65 at gmail.com (Zabb65) Date: Mon, 25 Oct 2010 19:48:12 -0400 Subject: [opensource-dev] Crashing integration tests In-Reply-To: <4CC5F01A.4000709@boroon.dasgupta.ch> References: <4CC1B12B.6080603@lindenlab.com> <4CC58DCB.2040108@boroon.dasgupta.ch> <4CC5E0ED.6070901@boroon.dasgupta.ch> <649411.90154.qm@web43509.mail.sp1.yahoo.com> <4CC5F01A.4000709@boroon.dasgupta.ch> Message-ID: It looks to be a problem with multiple tests running at the same time. Looking at the error gives a hint that its a collision with a globally shared named pipe of some type. Running the tests individually works just fine for me, running more than one at a time doesn't. On Mon, Oct 25, 2010 at 17:01, Boroondas Gupte wrote: > On 10/25/2010 10:56 PM, Nicky Perian wrote: > > I found the same thing about failed tests on 2d and subsequent builds. The > build has an error the first time but passes the second. This was on > VC++Express 2005 build. And, didn't matter about redoing develop.py. > > So this isn't GNU make or even Makefile specific. Either it's a CMake bug, > or we make some mistake at using CMake, probably not declaring all > dependencies correctly. > > Boroondas > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting > privileges > From nickyperian at yahoo.com Mon Oct 25 17:11:18 2010 From: nickyperian at yahoo.com (Nicky Perian) Date: Mon, 25 Oct 2010 17:11:18 -0700 (PDT) Subject: [opensource-dev] Crashing integration tests In-Reply-To: References: <4CC1B12B.6080603@lindenlab.com> <4CC58DCB.2040108@boroon.dasgupta.ch> <4CC5E0ED.6070901@boroon.dasgupta.ch> <649411.90154.qm@web43509.mail.sp1.yahoo.com> <4CC5F01A.4000709@boroon.dasgupta.ch> Message-ID: <341520.79988.qm@web43508.mail.sp1.yahoo.com> With my builds, if I rebuild the failed project individually the failure repeats. If I build the full project a second time no failures are reported. It appears that a run-once setting (if possible) is used for integration tests. ________________________________ From: Zabb65 To: Boroondas Gupte Cc: Nicky Perian ; Second Life Open Source Developer Mailing List Sent: Mon, October 25, 2010 6:48:12 PM Subject: Re: [opensource-dev] Crashing integration tests It looks to be a problem with multiple tests running at the same time. Looking at the error gives a hint that its a collision with a globally shared named pipe of some type. Running the tests individually works just fine for me, running more than one at a time doesn't. On Mon, Oct 25, 2010 at 17:01, Boroondas Gupte wrote: > On 10/25/2010 10:56 PM, Nicky Perian wrote: > > I found the same thing about failed tests on 2d and subsequent builds. The > build has an error the first time but passes the second. This was on > VC++Express 2005 build. And, didn't matter about redoing develop.py. > > So this isn't GNU make or even Makefile specific. Either it's a CMake bug, > or we make some mistake at using CMake, probably not declaring all > dependencies correctly. > > Boroondas > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101025/57cf414a/attachment.htm From lee.ponzu at gmail.com Tue Oct 26 11:32:59 2010 From: lee.ponzu at gmail.com (Ponzu) Date: Tue, 26 Oct 2010 14:32:59 -0400 Subject: [opensource-dev] Viewer-development and viewer-beta Message-ID: Can someone briefly summarize how these two repositories are being used. It looks sort of like they are being kept very much in lock-step, with merges, pushes, and pulls. thanks, ponzu -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101026/2d318ae9/attachment.htm From akanevsky at productengine.com Tue Oct 26 11:48:23 2010 From: akanevsky at productengine.com (Anya Kanevsky) Date: Tue, 26 Oct 2010 11:48:23 -0700 Subject: [opensource-dev] Daily Scrum Summary - Tuesday, Oct 26 Message-ID: *Date: **Tue** **Oct **2**6* *== GENERAL NOTES ==* * Merge Monkey of the Day: Merov * IMPORTANT: Please remember - when merging your fixes into Beta, you must also pull them into viewer-development immediately after. * Esbee would also like to remind people to brush their teeth. Thank you. *== DAILY SCRUM ==* *=== Merov ===* *PAST* * STORM-105: Perf: cleaned up perf gathering. Considering adding new command line arguments for more flexible perf gathering. * Merge Monkeying and code reviews *FUTURE* * Merge Monkeying and code reviews * STORM-418: Propose a changeset. * STORM-105 : Perf decompression: put new data out, prepare for review. * STORM-104: kdu upgrade *IMPEDIMENTS* * Latest KDU bits: still waiting... =*==**Oz** Linden**==**=* *PAST* * Worked on new TPVD * Started moving content from develop.sl to wiki.sl * Reviewed (and approved) water flicker fix (STORM-416) *FUTURE* * Starting on lldir work related to STORM-102 (STORM-477 first) * Bug Esbee about STORM-255 review * Try to chase down KDU bits (grumble) *IMPEDIMENTS* * none *=== Q **Linden**===* *PAST* * integration of STORM-341 * triage * investigation into crashes * writing up extra subtasks for STORM-102 * 255-char limit (almost done, I think I might have it, will test) *FUTURE* * 255 char limit * antialiasing * crash rate * administrivia *IMPEDIMENTS* * duck *=== Esbee Linden ===* *PAST* * Coordinating Viewer 2.3 Beta 1 release * Viewer Beta and Release Process work * Finishing up systems requirements work * No progress on Prefs :( * Tried dev viewer w/STORM-255. Not sure of the full approach. Need to test more. * VWR Triage *FUTURE* * Systems requirements analysis * Preferences clean-up work * VWR Triage * Viewer 2.3 Beta 1 Release Coordination * More review of STORM-255 * Finish chart reporting review on Jira * Look at STORM-296 *IMPEDIMENTS* * Time keeps on slipping, slipping, slipping *=== Paul ProductEngine===* *PAST:* * STORM-36 As a User, I want to control how long a chat toast appears before it fades. Please add fade time back to Chat preferences. ** Fixed. Tomorrow will pull to bitbucket. *FUTURE:* * STORM-36 Pull to bitbucket * other tickets by priority *IMPEDIMENTS:* * none *=== Seth Productengine ===* *PAST:* * BUG (STORM-426) Menu button looks as being pressed while its menu is displayed by another control ** Updated fix according to review feedback. * BUG (STORM-296) Cursor doesn't change when trying to drag and drop non-landmark items into Favorites folder ** WIP. ** Investigated Erica's suggestion to move Favorites folder to Landmarks. Replied in jira that it might take long. *FUTURE:* * BUG (STORM-296) Cursor doesn't change when trying to drag and drop non-landmark items into Favorites folder ** Estimated: 4 hours. * BUG (STORM-303) Favorites folder content isn't refreshed while re-ordering landmaks I*MPEDIMENTS:* * none *=== Andrew Productengine ===* *PAST:* * Finished fixing critical bug STORM-95 (Upload hangs client) and sent it for review. * Bug STORM-184 (Save is enabled for outfits consisting of original items). ** Investigated. Bug doesn't reproduce under debug, but reproduces without it :) Will continue work on it tomorrow. *FUTURE:* * Bug STORM-184 (Save is enabled for outfits consisting of original items). Though I couldn't reproduce it today, Plan stably reproduces it on the same build and OS as mine. *IMPEDIMENTS:* * none *=== Vadim Productengine ===* *PAST:* * Bug STORM-341 (*Crash in LLFilteredWearableListManager::populateList()*): ** Fixed. * Bug STORM-452 (*Crash in LLAgentCamera::resetView()*): ** Investigated but could not reproduce; reassigned to Andrew to try reproducing on Windows. * Code review. *FUTURE:* * Will take something from the v-d bug queue. *IMPEDIMENTS:* *none -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101026/419a6eef/attachment-0001.htm From merov at lindenlab.com Tue Oct 26 11:50:33 2010 From: merov at lindenlab.com (Philippe (Merov) Bossut) Date: Tue, 26 Oct 2010 11:50:33 -0700 Subject: [opensource-dev] Viewer-development and viewer-beta In-Reply-To: References: Message-ID: Hi, On Tue, Oct 26, 2010 at 11:32 AM, Ponzu wrote: > Can someone briefly summarize how these two repositories are being used. > It looks sort of like they are being kept very much in lock-step, with > merges, pushes, and pulls. > It's all explained here: http://wiki.secondlife.com/wiki/Viewer_Integration_and_Release_Processes#Beta_Repository Right now, things that are committed in viewer-beta are systematically pulled shortly after in viewer-development so that the dev repo contains all fixes + all current (but not QA-ed yet) development. Cheers, - Merov -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101026/58ef4fed/attachment.htm From suezanne at gmail.com Tue Oct 26 11:51:40 2010 From: suezanne at gmail.com (SuezanneC Baskerville) Date: Tue, 26 Oct 2010 13:51:40 -0500 Subject: [opensource-dev] Files deleted by uninstaller don't appear in Recycle Bin Message-ID: Files deleted by the SL uninstaller don't appear in the Recycle Bin on my Windows XP system. It seems to me it would be better if they did. Some files deleted by some other programs do appear in the Recycle Bin. In the case that brought this to my attention, it was the uninstaller for the SL Development Viewer and what it deleted was all my chat history, which could have been 7 years of chat history. The uninstaller asks if you want to delete files left in the SL program files folder and then if you answer yes it proceeds to delete not only files in the SL program folder, it also deletes files in the Application Data and Local Settings folder, including files that were created by TPVs. Obviously the uninstaller shouldn't irreplacable user data without asking, as it does, or data in folders created by other programs, as it does, nor should the deletion process be without an easily activated STOP DELETING control, but despite those problems, the damage would be mitigated if one could restore the file from their Recycle Bin or appropriate equivalent. So, is there some reason why these deleted files don't go to the recycle bin? -- v i r t u a l w o r l d e n t h u s i a s t -- http://www.google.com/profiles/s u e z a n n e -- -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101026/66df6d11/attachment.htm From q at lindenlab.com Tue Oct 26 11:53:08 2010 From: q at lindenlab.com (Kent Quirk (Q Linden)) Date: Tue, 26 Oct 2010 14:53:08 -0400 Subject: [opensource-dev] Viewer-development and viewer-beta In-Reply-To: References: Message-ID: Briefly: viewer-development is the repository for daily work, the 'trunk'. Things checked in there go into the development viewer; the expectation is that those things are ready for release -- but it doesn't always work out that way. When we want to start the release process, we pull to viewer-beta. That goes through our integration QA process; every change in beta should be approved in advance, and also pulled over to viewer-development. Sometimes it goes the other way but we're trying to minimize that. We release betas approximately weekly. When we believe we have reached release stability, we pull beta to viewer-release and ship that as an "official" viewer. That will happen about monthly. The full explanation is here: http://wiki.secondlife.com/wiki/Linden_Lab_Repository_Strategy Q On Oct 26, 2010, at 2:32 PM, Ponzu wrote: > Can someone briefly summarize how these two repositories are being used. It looks sort of like they are being kept very much in lock-step, with merges, pushes, and pulls. > > thanks, > ponzu > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting privileges From robertltux at gmail.com Tue Oct 26 11:56:26 2010 From: robertltux at gmail.com (Robert Martin) Date: Tue, 26 Oct 2010 14:56:26 -0400 Subject: [opensource-dev] Files deleted by uninstaller don't appear in Recycle Bin In-Reply-To: References: Message-ID: On Tue, Oct 26, 2010 at 2:51 PM, SuezanneC Baskerville wrote: > The uninstaller asks if you want to delete files left in the SL program > files folder and then if you answer yes it proceeds to delete not only files > in the SL program folder, it also deletes files in the Application Data and > Local Settings folder, including files that were created by TPVs. the problem is in two parts 1 the uninstaller is being unclear and "helpful" 2 best practices for a TPV would be to use its own folder by default (with maybe doing a copy of the avatar log files and such) -- Robert L Martin From suezanne at gmail.com Tue Oct 26 12:04:38 2010 From: suezanne at gmail.com (SuezanneC Baskerville) Date: Tue, 26 Oct 2010 14:04:38 -0500 Subject: [opensource-dev] Files deleted by uninstaller don't appear in Recycle Bin In-Reply-To: References: Message-ID: Those two parts are not the sum of the problem. Deleted files can appear in the Recycle Bin, which would allow the user to restore them without the use of any special file undelete utitilities. The files SL deletes don't. Someone should check to make sure I'm wrong. TPVs aren't always going to follow best practices any more than LL is going to always follow best practice. Best practice would be that if you ask about deleting files in C:\Program Files\SecondLifeDevelopment, you confine your deletions to files in those folders. Regardless of the flaws in the uninstaller's logic, the question I'm asking here is "Can the deleted files be made to do to the Recycle Bin instead of bypassing the Recycle Bin and thus being, at least in the mind of most users, permanently and irreversably gone?" On Tue, Oct 26, 2010 at 1:56 PM, Robert Martin wrote: > On Tue, Oct 26, 2010 at 2:51 PM, SuezanneC Baskerville > wrote: > > The uninstaller asks if you want to delete files left in the SL program > > files folder and then if you answer yes it proceeds to delete not only > files > > in the SL program folder, it also deletes files in the Application Data > and > > Local Settings folder, including files that were created by TPVs. > > the problem is in two parts > 1 the uninstaller is being unclear and "helpful" > 2 best practices for a TPV would be to use its own folder by default > (with maybe doing a copy of the avatar log files and such) > > -- > Robert L Martin > -- v i r t u a l w o r l d e n t h u s i a s t -- http://www.google.com/profiles/s u e z a n n e -- -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101026/e131adda/attachment.htm From aklo at skyhighway.com Tue Oct 26 13:28:06 2010 From: aklo at skyhighway.com (aklo at skyhighway.com) Date: Tue, 26 Oct 2010 13:28:06 -0700 (PDT) Subject: [opensource-dev] Files deleted by uninstaller don't appear in Recycle Bin Message-ID: i've seen several products that have an uninstall option to "delete user data?" Like, the uninstall won't delete anything except its executables and program data that it installed unless you give it permission to do more at uninstall time. At least one program i've seen asked two uninstall questions like that, the one for user data and another for config files. That program asked about config files because the company had several different versions of its product and sometimes people would switch between them. i know, that's not the best way to do things. i'm just sayin what i've seen. - AK -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Those two parts are not the sum of the problem. Deleted files can appear in the Recycle Bin, which would allow the user to restore them without the use of any special file undelete utitilities. The files SL deletes don't. Someone should check to make sure I'm wrong. TPVs aren't always going to follow best practices any more than LL is going to always follow best practice. Best practice would be that if you ask about deleting files in C:\Program Files\SecondLifeDevelopment, you confine your deletions to files in those folders. Regardless of the flaws in the uninstaller's logic, the question I'm asking here is "Can the deleted files be made to do to the Recycle Bin instead of bypassing the Recycle Bin and thus being, at least in the mind of most users, permanently and irreversably gone?" On Tue, Oct 26, 2010 at 1:56 PM, Robert Martin wrote: On Tue, Oct 26, 2010 at 2:51 PM, SuezanneC Baskerville wrote: > The uninstaller asks if you want to delete files left in the SL program > files folder and then if you answer yes it proceeds to delete not only files > in the SL program folder, it also deletes files in the Application Data and > Local Settings folder, including files that were created by TPVs. the problem is in two parts 1 the uninstaller is being unclear and "helpful" 2 best practices for a TPV would be to use its own folder by default (with maybe doing a copy of the avatar log files and such) -- Robert L Martin -- v i r t u a l w o r l d e n t h u s i a s t -- http://www.google.com/profiles/s u e z a n n e -- _______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges From mrfrans at gmail.com Tue Oct 26 14:50:05 2010 From: mrfrans at gmail.com (Frans) Date: Tue, 26 Oct 2010 23:50:05 +0200 Subject: [opensource-dev] Files deleted by uninstaller don't appear in Recycle Bin In-Reply-To: References: Message-ID: In games unistallers it is pretty common for them to ask separately if you want to delete your save games as well. -Frans On Tue, Oct 26, 2010 at 10:28 PM, wrote: > i've seen several products that have an uninstall option to "delete user > data?" Like, the uninstall won't delete anything except its executables > and program data that it installed unless you give it permission to do > more at uninstall time. At least one program i've seen asked two > uninstall questions like that, the one for user data and another for > config files. That program asked about config files because the company > had several different versions of its product and sometimes people would > switch between them. i know, that's not the best way to do things. i'm > just sayin what i've seen. > > - AK > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > Those two parts are not the sum of the problem. > > Deleted files can appear in the Recycle Bin, which would allow the user > to restore them without the use of any special file undelete utitilities. > > The files SL deletes don't. Someone should check to make sure I'm wrong. > > TPVs aren't always going to follow best practices any more than LL is > going to always follow best practice. Best practice would be that if you > ask about deleting files in C:\Program Files\SecondLifeDevelopment, you > confine your deletions to files in those folders. > > Regardless of the flaws in the uninstaller's logic, the question I'm > asking here is "Can the deleted files be made to do to the Recycle Bin > instead of bypassing the Recycle Bin and thus being, at least in the mind > of most users, permanently and irreversably gone?" > > > On Tue, Oct 26, 2010 at 1:56 PM, Robert Martin > wrote: > > On Tue, Oct 26, 2010 at 2:51 PM, SuezanneC Baskerville > wrote: > > The uninstaller asks if you want to delete files left in the SL > program > > files folder and then if you answer yes it proceeds to delete not > only files > > in the SL program folder, it also deletes files in the Application > Data and > > Local Settings folder, including files that were created by TPVs. > > the problem is in two parts > 1 the uninstaller is being unclear and "helpful" > 2 best practices for a TPV would be to use its own folder by default > (with maybe doing a copy of the avatar log files and such) > > -- > Robert L Martin > > > > > -- > v i r t u a l w o r l d e n t h u s i a s t > -- http://www.google.com/profiles/s u e z a n n e -- > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101026/2022a9d2/attachment.htm From thomas.shikami at online.de Tue Oct 26 16:05:50 2010 From: thomas.shikami at online.de (Thomas Shikami) Date: Wed, 27 Oct 2010 01:05:50 +0200 Subject: [opensource-dev] Files deleted by uninstaller don't appear in Recycle Bin In-Reply-To: References: Message-ID: <4CC75ECE.2070705@online.de> SuezanneC Baskerville schrieb: > Files deleted by the SL uninstaller don't appear in the Recycle Bin > on my Windows XP system. > > It seems to me it would be better if they did. > > Some files deleted by some other programs do appear in the Recycle Bin. > > In the case that brought this to my attention, it was the uninstaller > for the SL Development Viewer and what it deleted was all my chat > history, which could have been 7 years of chat history. > That is a problem with SL installer. Installers should never touch any of the user specific folders anyways. Same for uninstallers. That is for the windows platform. The uninstaller deleting chatlogs is a bug. To get most of your logs back, try some undeletion software. Maybe system restore saved the logs as well, but I wouldn't just use system restore, as it's an intrusive task and may cause more problems than it's worth. From secret.argent at gmail.com Wed Oct 27 04:08:53 2010 From: secret.argent at gmail.com (Argent Stonecutter) Date: Wed, 27 Oct 2010 06:08:53 -0500 Subject: [opensource-dev] Files deleted by uninstaller don't appear in Recycle Bin In-Reply-To: References: Message-ID: The uninstaller shouldn't remove ANYTHING in the user's profile, period. It's not being "unclear" by removing files in the user's profile when it removes files in the Program Files directory, it's simply doing the wrong thing. This has been an ongoing problem for years, I suspect there's a Jira about it. From oz at lindenlab.com Wed Oct 27 07:05:45 2010 From: oz at lindenlab.com (Oz Linden (Scott Lawrence)) Date: Wed, 27 Oct 2010 10:05:45 -0400 Subject: [opensource-dev] [META] User stories and issue tracker readability In-Reply-To: References: <4CC306B2.60405@boroon.dasgupta.ch> Message-ID: <4CC831B9.9070401@lindenlab.com> On 2010-10-23 12:25, SuezanneC Baskerville wrote: > > Part of the change was to add the words "As a user," to the Summary > field. > > https://jira.secondlife.com/browse/VWR-675 > > They also changed the importance from minor to major. I suspect > these two actions are connected. > > I suspect that people are reading instructions that give them the > impression that if they want issues to get proper consideration they > need to put "As a user" at the beginning of the description field. It is very helpful to us when scanning lists of issues to be able to see whether they are motivated by a user-visible effect or are concerned with viewer developers or some other audience. From oz at lindenlab.com Wed Oct 27 07:17:01 2010 From: oz at lindenlab.com (Oz Linden (Scott Lawrence)) Date: Wed, 27 Oct 2010 10:17:01 -0400 Subject: [opensource-dev] LGPL violation In-Reply-To: <20101023112754.GA394@alinoe.com> References: <20101023112754.GA394@alinoe.com> Message-ID: <4CC8345D.2020100@lindenlab.com> On 2010-10-23 7:27, Carlo Wood wrote: > I am not a lawyer :p, but I think that it is allowed to link an LGPL-ed > library statically against a proprietary executable provided you > provide the object code or source code of the work that uses the library. Not correct. LGPL code may be linked to other source without having the viral effect of requiring that other source also be published as open source. LGPL _does_ require that if any changes are made to the source under that license, then those changes (and the original sources) must be open and available either as LGPL or as GPL. From I_really_needed_a_new_mailbox at gmx.de Wed Oct 27 07:21:15 2010 From: I_really_needed_a_new_mailbox at gmx.de (Zai Lynch) Date: Wed, 27 Oct 2010 16:21:15 +0200 Subject: [opensource-dev] [META] User stories and issue tracker readability In-Reply-To: <4CC831B9.9070401@lindenlab.com> References: <4CC306B2.60405@boroon.dasgupta.ch> <4CC831B9.9070401@lindenlab.com> Message-ID: > > It is very helpful to us when scanning lists of issues to be able to see > whether they are motivated by a user-visible effect or are concerned > with viewer developers or some other audience. > But isn't that what components could be used for? Affects: Users, UI Affects: Merchants, i18n etc. It would be pretty easy to filter them in that case. I'm indifferent with it, since I'm not active in the Jira anymore, though I remember having the exact same issue as Boroondas... -- @ZaiLynch -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101027/5712615c/attachment-0001.htm From malachi at tamzap.com Wed Oct 27 07:38:32 2010 From: malachi at tamzap.com (Malachi) Date: Wed, 27 Oct 2010 10:38:32 -0400 Subject: [opensource-dev] LGPL violation In-Reply-To: <4CC8345D.2020100@lindenlab.com> References: <20101023112754.GA394@alinoe.com> <4CC8345D.2020100@lindenlab.com> Message-ID: does this mean that if i move all of my own code over to a dll file that is loaded at runtime that i do not have to release the source for it? On Wed, 27 Oct 2010 10:17:01 -0400, Oz Linden (Scott Lawrence) wrote: > On 2010-10-23 7:27, Carlo Wood wrote: >> I am not a lawyer :p, but I think that it is allowed to link an LGPL-ed >> library statically against a proprietary executable provided you >> provide the object code or source code of the work that uses the >> library. > > Not correct. LGPL code may be linked to other source without having the > viral effect of requiring that other source also be published as open > source. LGPL _does_ require that if any changes are made to the source > under that license, then those changes (and the original sources) must > be open and available either as LGPL or as GPL. > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting > privileges -- Using Opera's revolutionary email client: http://www.opera.com/mail/ From q at lindenlab.com Wed Oct 27 07:45:55 2010 From: q at lindenlab.com (Kent Quirk (Q Linden)) Date: Wed, 27 Oct 2010 10:45:55 -0400 Subject: [opensource-dev] Files deleted by uninstaller don't appear in Recycle Bin In-Reply-To: References: Message-ID: <60C115E4-83AC-4C69-AABB-D5AC743B76FB@lindenlab.com> Au contraire. Some people get very upset when an installer leaves any files behind that were created by the program automatically, such as log files. It's simply not true that the uninstaller shouldn't remove anything in the profile -- I have worked at multiple companies where leaving behind any breadcrumbs (anything that wasn't created by File Save) after an uninstall was considered a major bug. Now I do think we can try do better; asking about deletion is on the Snowstorm backlog. Installers are always tricky and hard to test, and very often the uninstaller comes "for free" with writing the installer. It's also specialized, platform-specific code, sometimes in a strange language, so it's not easy to find devs who want to work on it. There's work going on right now that will probably affect this, and we'll make sure this is considered. Q On Oct 27, 2010, at 7:08 AM, Argent Stonecutter wrote: > The uninstaller shouldn't remove ANYTHING in the user's profile, period. It's not being "unclear" by removing files in the user's profile when it removes files in the Program Files directory, it's simply doing the wrong thing. This has been an ongoing problem for years, I suspect there's a Jira about it. From esbee at lindenlab.com Wed Oct 27 11:35:18 2010 From: esbee at lindenlab.com (Sarah (Esbee) Hutchinson) Date: Wed, 27 Oct 2010 14:35:18 -0400 Subject: [opensource-dev] Friday Sprint Review Meeting - Canceled Message-ID: Just a quick note to let you know I'm canceling the Sprint Review Meeting scheduled for this Friday at 8am PT. We didn't introduce a pile of new features this Sprint and have been mostly focused on stablization and crashers. I've also not made enough progress on Preferences design and requirements to review that either. (I apologize for that and will work to get this done as quickly as possible). We'll do a smaller review at our Sprint Retrospective on Monday. If you have any questions or comments. Please let me know! Best, Esbee -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101027/41fd38ec/attachment.htm From suezanne at gmail.com Wed Oct 27 12:09:39 2010 From: suezanne at gmail.com (SuezanneC Baskerville) Date: Wed, 27 Oct 2010 14:09:39 -0500 Subject: [opensource-dev] Files deleted by uninstaller don't appear in Recycle Bin In-Reply-To: <60C115E4-83AC-4C69-AABB-D5AC743B76FB@lindenlab.com> References: <60C115E4-83AC-4C69-AABB-D5AC743B76FB@lindenlab.com> Message-ID: Our chat logs are our baby pictures, our precious documents, our financial records. They are our love letters, our records of meeting our friends, our graduation diplomas, our birth certificates, our immunization records, our green cards. For an uninstall program to delete them is a good bit like your camera software's uninstall program deleting every one of your wedding and baby and family pictures. That some people might like exhaustively thorough uninstalls doesn't make that the right thing to do. People who are so concerned with a thorough uninstall that they want the stuff they, their friends, their business contacts and customers created deleted can delete it manually, apart from the uninstall program; people whose content is destroyed permanently by an inaccurately worded uninstall routine have no recourse. Regardless of whether the uninstall program does or doesn't delete these files, there is a separate matter that I am trying to bring to light, namely the question of whether the files the uninstall program deletes are deleted in such a fashion that they go into the operating system's "emergency backup system", which for Windows XP,. is called the recycle bin. I've made a jira issue about this: https://jira.secondlife.com/browse/VWR-23594 , "Files deleted by uninstallation should appear in the Recycle Bin or equivalent". Please vote for if you like. On Wed, Oct 27, 2010 at 9:45 AM, Kent Quirk (Q Linden) wrote: > Au contraire. Some people get very upset when an installer leaves any files > behind that were created by the program automatically, such as log files. > It's simply not true that the uninstaller shouldn't remove anything in the > profile -- I have worked at multiple companies where leaving behind any > breadcrumbs (anything that wasn't created by File Save) after an uninstall > was considered a major bug. > > Now I do think we can try do better; asking about deletion is on the > Snowstorm backlog. Installers are always tricky and hard to test, and very > often the uninstaller comes "for free" with writing the installer. It's also > specialized, platform-specific code, sometimes in a strange language, so > it's not easy to find devs who want to work on it. > > There's work going on right now that will probably affect this, and we'll > make sure this is considered. > > Q > > > On Oct 27, 2010, at 7:08 AM, Argent Stonecutter wrote: > > > The uninstaller shouldn't remove ANYTHING in the user's profile, period. > It's not being "unclear" by removing files in the user's profile when it > removes files in the Program Files directory, it's simply doing the wrong > thing. This has been an ongoing problem for years, I suspect there's a Jira > about it. > > -- v i r t u a l w o r l d e n t h u s i a s t -- http://www.google.com/profiles/s u e z a n n e -- -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101027/5481f91d/attachment.htm From danielravennest at gmail.com Wed Oct 27 12:35:52 2010 From: danielravennest at gmail.com (Daniel) Date: Wed, 27 Oct 2010 14:35:52 -0500 Subject: [opensource-dev] Files deleted by uninstaller In-Reply-To: References: Message-ID: <4CC87F18.2010406@gmail.com> Chat and IM logs are a user preference setting. If logging is turned on, the implication is the user wants the logs, and that preference should not be overridden without notice. Also, SL users are not working for a company in a business situation. It's a social virtual world, and chat logs represent their accumulated conversations with people. Also in some cases, users are running their *own* business, and chat logs record conversations with customers. Deleting personal or business data without warning is wrong in this environment, however much the practice may make sense in a corporate environment. > From: "Kent Quirk (Q Linden)" > > Au contraire. Some people get very upset when an installer leaves any files behind that were created by the program automatically, such as log files. It's simply not true that the uninstaller shouldn't remove anything in the profile -- I have worked at multiple companies where leaving behind any breadcrumbs (anything that wasn't created by File Save) after an uninstall was considered a major bug. > From akanevsky at productengine.com Wed Oct 27 13:07:17 2010 From: akanevsky at productengine.com (Anya Kanevsky) Date: Wed, 27 Oct 2010 13:07:17 -0700 Subject: [opensource-dev] Daily Scrum Summary - Wednesday, October 27 Message-ID: *Date: **Wed** **Oct **2**7* *== GENERAL NOTES ==* * Merge Monkey of the Day: Merov * IMPORTANT: Please remember - when merging your fixes into Beta, you must also pull them into viewer-development immediately after. * Esbee would also like to remind you that today's update is brought to you by the letter E and the number 3. *== DAILY SCRUM ==* *=== Merov ===* *PAST* * STORM-105: Perf: Changed code to allow metric choice on command line. Testing, testing... * STORM-418: Review alternative, posted fix, ready for review. * OH: Good insight on mesh code and upcoming likely merge gotcha's * Merge Monkeying and code reviews *FUTURE* * Merge Monkeying and code reviews * STORM-105 : Perf gathering: more changes coming. * STORM-104: kdu upgrade *IMPEDIMENTS* * Latest KDU bits: still waiting... =*==**Oz** Linden**==**=* *PAST* * New download wiki page for alternative viewers * More work on new TPVD * Started on lldir work related to STORM-102 (STORM-477 first) * Tried to chase down KDU bits (ball is with Kakadu) *FUTURE* * Finish STORM-477 * Continue pusuit of KDU bits *IMPEDIMENTS* * None *=== Q **Linden**===* PAST * crashhunting * beta 2.3 today * meetings * STORM-102 doc * STORM-341 * STORM-418 * STORM-482 *FUTURE* * triage * meetings *IMPEDIMENTS* * none *=== Esbee Linden ===* *PAST* * Coordination of Viewer 2.3 Beta 1 release * Finishing up systems requirements work * Office Hour RE: Preferences design * Finished review of STORM-255 and provided feedback. * VWR Triage *FUTURE* * Preferences design work * VWR Triage * Viewer 2.3 Beta 1 Release Coordination * Look at STORM-296 *IMPEDIMENTS* * I've got the song, "Human Nature" stuck in my head. (Now you do too) *=== Paul ProductEngine===* *PAST:* * STORM-36 As a User, I want to control how long a chat toast appears before it fades. Please add fade time back to Chat preferences. ** Completed and sent for review * BUG STORM-190 [TRUNCATION] many langs -- "Next Owner:" in floatear_bulk_perms.xml ** Fixed and sent for review * BUG STORM-354 [TRUNCATION] many langs - build tools "Click to:" combobox. ** Fixed and sent for review *FUTURE:* * STORM-400 Trash button not responding on People > My Friends tab * STORM-459 Delete outfit confirmation message doesn'r appear if use context or gear menu on 'My Outfits' tab *IMPEDIMENTS:* * none *=== Seth Productengine ===* *PAST:* * BUG (STORM-296) Cursor doesn't change when trying to drag and drop non-landmark items into Favorites folder ** Fixed. Patch for review at https://codereview.productengine.com/secondlife/r/887/ *FUTURE:* * BUG (STORM-303) Favorites folder content isn't refreshed while re-ordering landmaks ** Estimated: 8 hours. I*MPEDIMENTS:* * none *=== Andrew Productengine ===* *PAST:* * Bug STORM-184 (Save is enabled for outfits consisting of original items). ** WIP. Still couldn't find the source of bug. * Critical bug STORM-452 ([crashhunters] Crash in LLAgentCamera::resetView()) ** Investigated and tried to reproduce on different builds. Closed as cannot reproduce, perhaps it was fixed with fix for STORM-341. * While working on STORM-452 found and filed bug STORM-481 (Camera returns to edit appearance mode after entering and leaving mouselook while sidetray appearance tab is detached and minimized). *FUTURE:* * Bug STORM-184 (Save is enabled for outfits consisting of original items). *IMPEDIMENTS:* * none *=== Vadim Productengine ===* *PAST:* * Reviewed once more and finally approved Paul's implementation of story STORM-36 (*Configurable chat toast life time*). * Reviewed Merov's fix of STORM-454 (*Z coordinate still wrong*). * Major bug STORM-335 (*Group name SLURL isn't clickable in the About Land > General tab*): ** Fixed. * Major bug STORM-389 (*Object continue sending messages after user adding this object to block list*): ** Investigated, found out it was a server problem, unassigned. * * *FUTURE:* * Pick something major+ from the v-d bug queue. *IMPEDIMENTS:* *none *=== Andrey Productengine ===* *PAST:* * re-ran smoke and integrity on fresh Beta1 2.3.0 build r212976 * key bugfixes re-verified * started regression testing in scope of changes since Beta1 2.3.0 *FUTURE:* * complete regression testing of Beta1 2.3.0 * switch to v-d testing *IMPEDIMENTS:* * none -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101027/a4fb8374/attachment-0001.htm From da5idkronfeld at gmail.com Wed Oct 27 13:18:07 2010 From: da5idkronfeld at gmail.com (Da5id Kronfeld) Date: Wed, 27 Oct 2010 13:18:07 -0700 Subject: [opensource-dev] Files deleted by uninstaller don't appear in Recycle Bin In-Reply-To: <60C115E4-83AC-4C69-AABB-D5AC743B76FB@lindenlab.com> References: <60C115E4-83AC-4C69-AABB-D5AC743B76FB@lindenlab.com> Message-ID: <90B6C3ED-4CF3-4D6F-800A-3BB82F1B006B@gmail.com> On 2010-10-27, at 7:45 AM, Kent Quirk (Q Linden) wrote: > Au contraire. Some people get very upset when an installer leaves any files behind that were created by the program automatically, such as log files. It's simply not true that the uninstaller shouldn't remove anything in the profile -- I have worked at multiple companies where leaving behind any breadcrumbs (anything that wasn't created by File Save) after an uninstall was considered a major bug. I disagree with this statement. On unix like systems it's standard practice to store user specific settings in a file or directory like ~/.thePackage . Just because someone removes/replaces/updates the software does not mean that *anything* should happen to the contents of that file or directory. It's even worse on systems with more than one user. I think that it's better to decouple the per-user settings and preferences from the package installation entirely. Just my $L0.02. From zabb65 at gmail.com Wed Oct 27 14:33:22 2010 From: zabb65 at gmail.com (Zabb65) Date: Wed, 27 Oct 2010 17:33:22 -0400 Subject: [opensource-dev] Files deleted by uninstaller don't appear in Recycle Bin In-Reply-To: <90B6C3ED-4CF3-4D6F-800A-3BB82F1B006B@gmail.com> References: <60C115E4-83AC-4C69-AABB-D5AC743B76FB@lindenlab.com> <90B6C3ED-4CF3-4D6F-800A-3BB82F1B006B@gmail.com> Message-ID: My only concern with some of this, is that it eliminates the support teams easy one line answer to everything odd or unexplained. Uninstall and reinstall the client. The reason this works so well is that it deletes all of the users settings and preferences, which often become corrupted or contain invalid or bad values from previous versions, and cause trouble. Log files should not be placed inside a hidden/system folder to begin with in my opinion, its like treating user created content as program preferences. On Wed, Oct 27, 2010 at 16:18, Da5id Kronfeld wrote: > > On 2010-10-27, at 7:45 AM, Kent Quirk (Q Linden) wrote: > >> Au contraire. Some people get very upset when an installer leaves any files behind that were created by the program automatically, such as log files. It's simply not true that the uninstaller shouldn't remove anything in the profile -- I have worked at multiple companies where leaving behind any breadcrumbs (anything that wasn't created by File Save) after an uninstall was considered a major bug. > > I disagree with this statement. On unix like systems it's standard practice to store user specific settings in a file or directory like ~/.thePackage . Just because someone removes/replaces/updates the software does not mean that *anything* should happen to the contents of that file or directory. It's even worse on systems with more than one user. > > I think that it's better to decouple the per-user settings and preferences from the package installation entirely. Just my $L0.02. > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting privileges > From sythos at gmail.com Wed Oct 27 14:38:55 2010 From: sythos at gmail.com (Altair Sythos Memo) Date: Wed, 27 Oct 2010 23:38:55 +0200 Subject: [opensource-dev] LGPL violation In-Reply-To: References: <20101023112754.GA394@alinoe.com> <4CC8345D.2020100@lindenlab.com> Message-ID: <20101027233855.d7447cf6.sythos@gmail.com> On Wed, 27 Oct 2010 10:38:32 -0400 Malachi wrote: > does this mean that if i move all of my own code over to a dll file > that is loaded at runtime that i do not have to release the source > for it? uhm... both no and yes yu can put in a DLL all the code, LGPL allow you to do, bu you shoudl release the LGPL part of code (not the piece yours or under other license), you must release the LGPL code of DLL, not all From sythos at gmail.com Wed Oct 27 14:46:14 2010 From: sythos at gmail.com (Altair Sythos Memo) Date: Wed, 27 Oct 2010 23:46:14 +0200 Subject: [opensource-dev] LGPL violation In-Reply-To: <20101027233855.d7447cf6.sythos@gmail.com> References: <20101023112754.GA394@alinoe.com> <4CC8345D.2020100@lindenlab.com> <20101027233855.d7447cf6.sythos@gmail.com> Message-ID: <20101027234614.1187d593.sythos@gmail.com> On Wed, 27 Oct 2010 23:38:55 +0200 Altair "Sythos" Memo wrote: > yu can put in a DLL all the code, LGPL allow you to do, bu you shoudl > release the LGPL part of code (not the piece yours or under other > license), you must release the LGPL code of DLL, not all please... turn on your typonese translator before read my last email XD From stickman at gmail.com Wed Oct 27 19:53:59 2010 From: stickman at gmail.com (Stickman) Date: Wed, 27 Oct 2010 19:53:59 -0700 Subject: [opensource-dev] On Live, SL via Cloud Computing Message-ID: Had a thought, figured I'd share it in case someone with authority wanted to explore the topic. On Live (http://www.onlive.com/) is a cloud computing gaming service. You open up the client and their computers run the game and graphics and stream the video to you while accepting your controls. It means you can run games on systems that otherwise wouldn't run them. Pros: -Less powerful computers can run SL on high settings -Collaboration could result in cached or close asset data for super fast object and texture loading Cons: -$5/month subscription fee per user (Premium option?) -Requires high bandwidth (3mbit) connection -Probably consumes more bandwidth than SL itself would The big turn off for On Live to me is a monthly fee combined with full price video games combined with "don't pay for a year, we delete your account including your purchase record." But those cons wouldn't apply when dealing with Second Life through this medium. Just throwing that out there. Stickman From carlo at alinoe.com Thu Oct 28 04:29:11 2010 From: carlo at alinoe.com (Carlo Wood) Date: Thu, 28 Oct 2010 13:29:11 +0200 Subject: [opensource-dev] LGPL violation In-Reply-To: <4CC8345D.2020100@lindenlab.com> References: <20101023112754.GA394@alinoe.com> <4CC8345D.2020100@lindenlab.com> Message-ID: <20101028112911.GA20618@alinoe.com> On Wed, Oct 27, 2010 at 10:17:01AM -0400, Oz Linden (Scott Lawrence) wrote: > On 2010-10-23 7:27, Carlo Wood wrote: > > I am not a lawyer :p, but I think that it is allowed to link an LGPL-ed > > library statically against a proprietary executable provided you > > provide the object code or source code of the work that uses the library. > > Not correct. LGPL code may be linked to other source without having the > viral effect of requiring that other source also be published as open > source. LGPL _does_ require that if any changes are made to the source > under that license, then those changes (and the original sources) must > be open and available either as LGPL or as GPL. You state pretty firmly, while I believe you are in error. You are NOT allowed to link statically with an LGPL-ed library unless you provide the means for the user to relink the library, for example by providing the .o (object) files that it is linked with. From dave at meadowlakearts.com Thu Oct 28 06:27:52 2010 From: dave at meadowlakearts.com (Dave Booth) Date: Thu, 28 Oct 2010 08:27:52 -0500 Subject: [opensource-dev] LGPL violation In-Reply-To: <20101028112911.GA20618@alinoe.com> References: <20101023112754.GA394@alinoe.com> <4CC8345D.2020100@lindenlab.com> <20101028112911.GA20618@alinoe.com> Message-ID: <4CC97A58.3060801@meadowlakearts.com> On 10/28/2010 06:29, Carlo Wood wrote: libmedia_plugin_webkit.{sp,dll,dylib} Make sure you quote examples of static linking when you're talking about static linking :) Dynamically loaded libraries (that is, after all, what "dll" is an abbreviation for) are by definition not statically linked. if they were statically linked you wouldnt need the .dll, the .so or the .dylib file because the object code would have been incorporated into the binary at link time. Statically linked progs dont require external library files, dynamically linked ones do. Thats the reason that on Solaris systems roots default shell is /sbin/sh rather than /bin/sh - its statically linked so that even if the lib loader is hosed the sysadmin can still get to a working shell to fix it. (historically, statically linked progs went in /sbin not /bin - not always a convention honored these days since so few progs are ever completely statically linked any more but in this case it was) Now get off my lawn ;) Dave From wolfpup67 at earthlink.net Thu Oct 28 06:50:26 2010 From: wolfpup67 at earthlink.net (WolfPup Lowenhar) Date: Thu, 28 Oct 2010 09:50:26 -0400 Subject: [opensource-dev] [META] User stories and issue tracker readability In-Reply-To: <4CC306B2.60405@boroon.dasgupta.ch> References: <4CC306B2.60405@boroon.dasgupta.ch> Message-ID: <000001cb76a7$13b053d0$3b10fb70$@net> To my understanding here is the following: 1. The main jiras (VWR, WEB, SVC) are for general issues basically no user story. 2. When they get pulled to a particular teams jira ( STORM, DN, MESH ) they then get converted to a 'story' with sub tasks relating to that 'story' This is my twp cents worth on this. From: opensource-dev-bounces at lists.secondlife.com [mailto:opensource-dev-bounces at lists.secondlife.com] On Behalf Of Boroondas Gupte Sent: Saturday, October 23, 2010 12:01 PM To: Second Life Open Source Developer Mailing List Subject: [opensource-dev] [META] User stories and issue tracker readability As a user of the Second Life issue tracker (jira) who often sorts or searches through others' issues, I'd like people creating or editing issues to place the (sometimes lengthy) user stories into the Description field, not the Summary field. The summary should be as short as possible while still conveying what the issue is about. The role for whom the issue matters (i.e. "As a ..., I ...") and the specifics of the motivation / reason for the issue are important when examining a single issue, but aren't too helpful when looking for duplicates of other issues or when searching for already existing issues of a wish or problem you have. Even worse, because the space for displaying the summary is very limited in some of the greenhopper views, you often only see the "As a ..." part while the rest gets cut off, so you can't tell at one glance what an issue being discussed is about at all. Think of an issue as a little book. The story you want to tell belongs to the inside (the description). On the cover (summary), you want the story's title (catchy and ideally different from the title of other books), not the first chapter. What do you think? Cheers, Boroondas _____ No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1144 / Virus Database: 422/3214 - Release Date: 10/23/10 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101028/4325795f/attachment-0001.htm From carlo at alinoe.com Thu Oct 28 08:52:15 2010 From: carlo at alinoe.com (Carlo Wood) Date: Thu, 28 Oct 2010 17:52:15 +0200 Subject: [opensource-dev] LGPL violation In-Reply-To: <4CC97A58.3060801@meadowlakearts.com> References: <20101023112754.GA394@alinoe.com> <4CC8345D.2020100@lindenlab.com> <20101028112911.GA20618@alinoe.com> <4CC97A58.3060801@meadowlakearts.com> Message-ID: <20101028155215.GA26426@alinoe.com> On Thu, Oct 28, 2010 at 08:27:52AM -0500, Dave Booth wrote: > On 10/28/2010 06:29, Carlo Wood wrote: > libmedia_plugin_webkit.{sp,dll,dylib} > > Make sure you quote examples of static linking when you're talking about > static linking :) Make sure you read carefully what I say and understand it before talking about wrong examples :) libmedia_plugin_webkit.{sp,dll,dylib} are linked STATICALLY with the Qt libs (as in, linked with .a). Thus: Qt*.a (LGPL) + LL*.o (LGPL+FLOSS) = libmedia_plugin_webkit.so ==> LL*.o must be made public (or their source code), or libmedia_plugin_webkit.so cannot be shipped. -- Carlo Wood From wolfpup67 at earthlink.net Thu Oct 28 08:59:09 2010 From: wolfpup67 at earthlink.net (Brendan Wilson) Date: Thu, 28 Oct 2010 11:59:09 -0400 Subject: [opensource-dev] LGPL violation In-Reply-To: <20101028155215.GA26426@alinoe.com> References: <20101023112754.GA394@alinoe.com> <4CC8345D.2020100@lindenlab.com> <20101028112911.GA20618@alinoe.com> <4CC97A58.3060801@meadowlakearts.com> <20101028155215.GA26426@alinoe.com> Message-ID: <001401cb76b9$0ec2b5e0$2c4821a0$@net> Actually the Qt wbekit source that LL uses is available as I had to completely rebuild the set of libs on my system when I was working on snowglobe using visual studio 2008 as the lib provided by LL caused an issue when starting the viewer after being build due to an manifest incompatibility issue. From: opensource-dev-bounces at lists.secondlife.com [mailto:opensource-dev-bounces at lists.secondlife.com] On Behalf Of Carlo Wood Sent: Thursday, October 28, 2010 11:52 AM To: Dave Booth Cc: opensource-dev at lists.secondlife.com Subject: Re: [opensource-dev] LGPL violation On Thu, Oct 28, 2010 at 08:27:52AM -0500, Dave Booth wrote: > On 10/28/2010 06:29, Carlo Wood wrote: > libmedia_plugin_webkit.{sp,dll,dylib} > > Make sure you quote examples of static linking when you're talking about > static linking :) Make sure you read carefully what I say and understand it before talking about wrong examples :) libmedia_plugin_webkit.{sp,dll,dylib} are linked STATICALLY with the Qt libs (as in, linked with .a). Thus: Qt*.a (LGPL) + LL*.o (LGPL+FLOSS) = libmedia_plugin_webkit.so ==> LL*.o must be made public (or their source code), or libmedia_plugin_webkit.so cannot be shipped. -- Carlo Wood _______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges _____ No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1153 / Virus Database: 424/3224 - Release Date: 10/28/10 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101028/3b18f4e6/attachment.htm From erikba at odysseus.anderson.name Thu Oct 28 09:15:10 2010 From: erikba at odysseus.anderson.name (Erik Anderson) Date: Thu, 28 Oct 2010 09:15:10 -0700 Subject: [opensource-dev] LGPL violation In-Reply-To: <20101028155215.GA26426@alinoe.com> References: <20101023112754.GA394@alinoe.com> <4CC8345D.2020100@lindenlab.com> <20101028112911.GA20618@alinoe.com> <4CC97A58.3060801@meadowlakearts.com> <20101028155215.GA26426@alinoe.com> Message-ID: There is a static component that is linked when linking to dynamic libraries, however that is present mostly to inform the compiler on what the ABI is, or how your compiled code is expected to interact with the DLL. It is very possible to write a piece of code that explicitly loads the library by name and manually builds calls to it. In fact, it's likely possible to compile a program intended to run with a .dll without any related files being on the machine at the time. On Thu, Oct 28, 2010 at 8:52 AM, Carlo Wood wrote: > On Thu, Oct 28, 2010 at 08:27:52AM -0500, Dave Booth wrote: > > On 10/28/2010 06:29, Carlo Wood wrote: > > libmedia_plugin_webkit.{sp,dll,dylib} > > > > Make sure you quote examples of static linking when you're talking about > > static linking :) > > Make sure you read carefully what I say and understand it before > talking about wrong examples :) > > libmedia_plugin_webkit.{sp,dll,dylib} are linked STATICALLY with > the Qt libs (as in, linked with .a). > > Thus: > > Qt*.a (LGPL) + LL*.o (LGPL+FLOSS) = libmedia_plugin_webkit.so > > ==> LL*.o must be made public (or their source code), or > libmedia_plugin_webkit.so cannot be shipped. > > -- > Carlo Wood > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101028/021b2cc0/attachment.htm From makosoft at gmail.com Thu Oct 28 11:10:49 2010 From: makosoft at gmail.com (Aidan Thornton) Date: Thu, 28 Oct 2010 19:10:49 +0100 Subject: [opensource-dev] LGPL violation In-Reply-To: References: <20101023112754.GA394@alinoe.com> <4CC8345D.2020100@lindenlab.com> <20101028112911.GA20618@alinoe.com> <4CC97A58.3060801@meadowlakearts.com> <20101028155215.GA26426@alinoe.com> Message-ID: On 10/28/10, Erik Anderson wrote: > There is a static component that is linked when linking to dynamic > libraries, however that is present mostly to inform the compiler on what the > ABI is, or how your compiled code is expected to interact with the DLL. It > is very possible to write a piece of code that explicitly loads the library > by name and manually builds calls to it. In fact, it's likely possible to > compile a program intended to run with a .dll without any related files > being on the machine at the time. Yeah, but that's not what we're talking about. libmedia_plugin_webkit.so is in fact linked statically with various Qt libraries - the entirety of the code for those Qt libraries is incorporated into libmedia_plugin_webkit.so by the linker at compile time, not just a stub. The same happens with libmedia_plugin_webkit.a and libmedia_plugin_webkit.dylib. I'm not sure exactly why Linden Lab decided to do this - it's not a common thing to do and getting it to work right requires a certain amount of mucking with the build system, since static libraries normally aren't compiled with options that allow them to be included in a shared library - but do it they did. From lee.ponzu at gmail.com Thu Oct 28 11:12:40 2010 From: lee.ponzu at gmail.com (Ponzu) Date: Thu, 28 Oct 2010 14:12:40 -0400 Subject: [opensource-dev] On Live, SL via Cloud Computing In-Reply-To: References: Message-ID: Seems like an excellent thought to me. Someone should proto-type this and see how it feels. $60/yr is less than the cost of a new GPU. lee On Wed, Oct 27, 2010 at 10:53 PM, Stickman wrote: > Had a thought, figured I'd share it in case someone with authority > wanted to explore the topic. > > On Live (http://www.onlive.com/) is a cloud computing gaming service. > You open up the client and their computers run the game and graphics > and stream the video to you while accepting your controls. It means > you can run games on systems that otherwise wouldn't run them. > > Pros: > -Less powerful computers can run SL on high settings > -Collaboration could result in cached or close asset data for super > fast object and texture loading > > Cons: > -$5/month subscription fee per user (Premium option?) > -Requires high bandwidth (3mbit) connection > -Probably consumes more bandwidth than SL itself would > > The big turn off for On Live to me is a monthly fee combined with full > price video games combined with "don't pay for a year, we delete your > account including your purchase record." But those cons wouldn't apply > when dealing with Second Life through this medium. > > Just throwing that out there. > > Stickman > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101028/fec00b24/attachment.htm From angel_of_crimson at hotmail.com Thu Oct 28 11:19:12 2010 From: angel_of_crimson at hotmail.com (Erin Mallory) Date: Thu, 28 Oct 2010 14:19:12 -0400 Subject: [opensource-dev] problems with dev build 2.4.0 (213153) Message-ID: I installed the windows version, and it keeps tripping up on both 32 and 64 bit windows 7 versions as well as on XP pro. specifically it keeps triggering the "this program may not have installed correctly" windows alert. It seems to be a bit sluggish as well. I reinstalled to no avail. Any ideas if theres a bug in the build or? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101028/1d9c1eae/attachment.htm From akanevsky at productengine.com Thu Oct 28 11:52:11 2010 From: akanevsky at productengine.com (Anya Kanevsky) Date: Thu, 28 Oct 2010 11:52:11 -0700 Subject: [opensource-dev] Daily Scrum Summary - Thursday, October 28 Message-ID: *Date: **Thu, **Oct **2**8* *== GENERAL NOTES ==* * Merge Monkey of the Day: Merov * IMPORTANT: Please don't push to V-D until yesterday's issue with changes not making it into latest build is resolved * IMPORTANT: Please remember - when merging your fixes into Beta, you must also pull them into viewer-development immediately after. * Esbee would also like to remind you that today's update is brought to you by the letter E and the number 3. *== DAILY SCRUM ==* *=== Merov ===* *PAST* * STORM-105 : Perf gathering: now allowing test name to be passed on the command line, more interesting decompression perf data too. Ready for review. * Merge Monkeying and code reviews *FUTURE* * Merge Monkeying and code reviews * STORM-104: kdu upgrade *IMPEDIMENTS* * Latest KDU bits: still waiting... =*==**Oz** Linden**==**=* *PAST* * Worked on STORM-477 * Learn about running integration and unit tests * More work on new TPVD * Office Hour *FUTURE* * Finish STORM-477 ? * Continue pusuit of KDU bits *IMPEDIMENTS* * Pumpkin Waffles *=== Q **Linden**===* *PAST* * crashhunting * triage * meetings / planning * waffles *FUTURE* * triage * meetings / planning * OOO *IMPEDIMENTS* * too many waffles *=== Esbee Linden ===* *PAST* * Office Hour RE: Preferences design * Finished review of STORM-255 and provided feedback. * VWR Triage * Provided feedback on STORM-296 *FUTURE* * Preferences design work * VWR Triage * Team/Process/Goals Work * Review latest STORM-255 Viewer build *IMPEDIMENTS* * Pumpkin waffles (the ultimate impediment) *=== Paul ProductEngine===* *PAST:* * BUG STORM-459 (Delete outfit confirmation message doesn'r appear if use context or gear menu on 'My Outfits' tab) ** Fixed and sent for a review ( https://codereview.productengine.com/secondlife/r/892/ ) * BUG STORM-400 (Trash button not responding on People > My Friends tab) ** Fixed and sent for a review * BUG STORY-36 (As a User, I want to control how long a chat toast appears before it fades. Please add fade time back to Chat preferences) ** Created test plan as Merov asked. *FUTURE:* * other tickets by priority *IMPEDIMENTS:* * none *=== Seth Productengine ===* *PAST:* * BUG (STORM-303) Favorites folder content isn't refreshed while re-ordering landmarks ** WI. Investigating problem with Favorites arranging in My Inventory. The problem is not observed in My Landmarks. *FUTURE:* * BUG (STORM-303) Favorites folder content isn't refreshed while re-ordering landmarks ** Estimated: 4 hours. I*MPEDIMENTS:* * none *=== Andrew Productengine ===* *PAST:* * Bug STORM-184 (Save is enabled for outfits consisting of original items). ** WIP. There seem to be two problems, one with mOutfitLocked - fixed it, other seems to be with dirty and it reproduces unstably(maybe not unstably but couldn't figure out stable steps to reproduce). * Critical bug STORM-452 ([crashhunters] Crash in LLAgentCamera::resetView()) ** Occasionally reproduced, made protective fix and put on review. * While working on STORM-452 found and filed bug STORM-481 (Camera returns to edit appearance mode after entering and leaving mouselook while sidetray appearance tab is detached and minimized). *FUTURE:* * Bug STORM-184 (Save is enabled for outfits consisting of original items). or * Maybe will take a little break from STORM-184 and investigate STORM-404 (Viewer crashes if try to create new group while data about previous group is retrieved) that has higher priority. *IMPEDIMENTS:* * none *=== Vadim Productengine ===* *PAST:* * Task STORM-451 (*URL-like object name is displayed as HTTP url in the llGiveInventory discard notification*): ** Implemented. * Severe bug STORM-488 (*Place profile opens instead of Object profile if click on object SLURL in the nearby chat*): ** Closed as a dupe. * Severe bug STORM-487 (*Notifications tab in Preferences not working properly*): ** Investigated, found out it was caused by recent Richard's changes, moved it to LEAP project. * Major bug STORM-442 (*Busy mode not sending busy message or behaving properly*): ** Investigated and closed as expected behavior. * Code review. *FUTURE:* * Task STORM-489 (Context menu for HTTP url opens if right-click on URL-like named object). ETA: 3h. * Will take something major+ from the v-d bug queue. *IMPEDIMENTS:* *none *=== Andrey Productengine ===* *PAST:* * completed regression testing of Beta1 2.3.0 * started viewer-dev testing *FUTURE:* * viewer-dev testing *IMPEDIMENTS:* * none -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101028/504989a6/attachment-0001.htm From sls.dev.sl.1 at sylea.org Thu Oct 28 12:09:50 2010 From: sls.dev.sl.1 at sylea.org (Talarus Luan) Date: Thu, 28 Oct 2010 15:09:50 -0400 Subject: [opensource-dev] Files deleted by uninstaller don't appear in Recycle Bin In-Reply-To: <60C115E4-83AC-4C69-AABB-D5AC743B76FB@lindenlab.com> References: <60C115E4-83AC-4C69-AABB-D5AC743B76FB@lindenlab.com> Message-ID: <4CC9CA7E.1050003@sylea.org> On 10/27/2010 10:45 AM, Kent Quirk (Q Linden) wrote: > Au contraire. Some people get very upset when an installer leaves any files behind that were created by the program automatically, such as log files. Au contraire contraire. MANY people get VERY upset when an installer deletes files that belong to them that they directed the program to create, either explicitly, or automatically via an explicit setting. I have the original viewer 2 installed right now and am not going to uninstall it until I am DAMN SURE I have backed up my entire profile, specifically because of this asinine design flaw. If I didn't already know about it, I would be ROYALLY pissed off when it deleted years' worth of accumulated data; MY data. Despite having backups, there still will be incremental loss (data since last backup), and the hassle of having to restore said data. Other people aren't so lucky, not knowing to back up said profile data, or simply not doing backups (yeah, their risk, but there is NO call to intentionally manifest that failure in code). > It's simply not true that the uninstaller shouldn't remove anything in the profile -- I have worked at multiple companies where leaving behind any breadcrumbs (anything that wasn't created by File Save) after an uninstall was considered a major bug. Then that is multiple companies which promoted a SERIOUS installer design paradigm flaw. I can't say I envy you there. Of the hundreds of customers I have developed software for over the past 3 decades, if I had implemented such a design flaw in my uninstallers, I would have lost a lot of money, and potentially been sued by at least a couple of them. (btw, aren't anecdotal stories acting as appeal to authority logical fallacies fun?) Look, this isn't hard to grok; it really isn't. Any collection of data which is created by or at the behest of the user is considered "user data". Implementations of a proper installer paradigm should NEVER *EVER* touch user data, either automatically or by default WITHOUT the full knowledge and consent of the user. That includes things like chatlogs, user-created folders underneath the program directory, user preferences, etc. This does not apply to things like temporary files, cache files/folders, or program data (because none of that is "user data"). An uninstaller also should inform the user of any files that it left behind, where, and why. Give the user information and control, and you don't have "very upset" users. Maybe "mildly annoyed" users, but not "I want to throttle the idiot developer that did this to me" users. At MOST, an uninstaller, if it is hell-bent on trying to clean up *COMPLETELY* after itself, *must* inform the user that it wants to cleanup his/her user data, explain EXACTLY and IN DETAIL what is going to be cleaned, and leave the default for the option to NO (as in "don't delete my data!"). This is simply proper (un)installer design, and I am amazed that so many developers simply "don't get it", to the pain of their users (including myself). Deleting data is FAR more serious of an issue than leaving data behind. Once it is gone, it is gone; if it is left behind, the user can clean it up themselves. Anger from lost data >>> annoyance of having to break out the data dustbuster. > Now I do think we can try do better; asking about deletion is on the Snowstorm backlog. I sure hope so. <.< > Installers are always tricky and hard to test, and very often the uninstaller comes "for free" with writing the installer. It's also specialized, platform-specific code, sometimes in a strange language, so it's not easy to find devs who want to work on it. They are not nearly as tricky or hard to test as code itself. Yeah, the uninstaller is often auto-generated by the installer generator, but to not then go through it with a fine-toothed comb for verification and add application-specific changes to the uninstall script is just laziness, pure and simple. The "strange language" is often fairly simplistic and easy to manipulate with only a modicum of time and effort put into learning it. I would be extremely surprised to learn that there isn't at least one "installer expert" at LL, whose primary job function is building and testing installer packages (note I said "primary", not "sole"; let's not go there). > There's work going on right now that will probably affect this, and we'll make sure this is considered. It needs more than consideration; it needs to be done, period. It's improper and incorrect, it is a design flaw, and it needs to be fixed ASAP before it does any more damage to user data. --TL From robertltux at gmail.com Thu Oct 28 12:21:58 2010 From: robertltux at gmail.com (Robert Martin) Date: Thu, 28 Oct 2010 15:21:58 -0400 Subject: [opensource-dev] Files deleted by uninstaller don't appear in Recycle Bin In-Reply-To: <4CC9CA7E.1050003@sylea.org> References: <60C115E4-83AC-4C69-AABB-D5AC743B76FB@lindenlab.com> <4CC9CA7E.1050003@sylea.org> Message-ID: getting back to what i said 1 the uninstaller should state that it is removing the profile data (best thing to do would be to zip it and put it in a folder on the desktop) 2 TPVs should by default not use the default secondlife profile folder (i would bet that 40% of SL/TPV problems could be solved by this simple step) 3 the recycle bin is a gamble anyway and may not be safe to use (2 gigs of profile data and a 1 gig recycle bin size = chunks of missing data) -- Robert L Martin From wolfpup67 at earthlink.net Thu Oct 28 12:52:25 2010 From: wolfpup67 at earthlink.net (WolfPup Lowenhar) Date: Thu, 28 Oct 2010 15:52:25 -0400 Subject: [opensource-dev] problems with dev build 2.4.0 (213153) In-Reply-To: References: Message-ID: <000f01cb76d9$a5464de0$efd2e9a0$@net> Actually from what Merov said @ today's scrum meeting it seems that the TC system might not have built that version right so that could be causing your problems. From: opensource-dev-bounces at lists.secondlife.com [mailto:opensource-dev-bounces at lists.secondlife.com] On Behalf Of Erin Mallory Sent: Thursday, October 28, 2010 2:19 PM To: opensource-dev at lists.secondlife.com Subject: [opensource-dev] problems with dev build 2.4.0 (213153) I installed the windows version, and it keeps tripping up on both 32 and 64 bit windows 7 versions as well as on XP pro. specifically it keeps triggering the "this program may not have installed correctly" windows alert. It seems to be a bit sluggish as well. I reinstalled to no avail. Any ideas if theres a bug in the build or? _____ No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1153 / Virus Database: 424/3224 - Release Date: 10/28/10 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101028/bbad2852/attachment.htm From daleinnisemail at gmail.com Thu Oct 28 12:57:02 2010 From: daleinnisemail at gmail.com (Dale Innis) Date: Thu, 28 Oct 2010 15:57:02 -0400 Subject: [opensource-dev] On Live, SL via Cloud Computing In-Reply-To: References: Message-ID: Has anyone on this list actually tried OnLive? What's the ping time and the general responsiveness like? People are always hyping these server-side-rendering solutions as the Next Big Thing, but so far I don't see it... From sls.dev.sl.1 at sylea.org Thu Oct 28 13:08:30 2010 From: sls.dev.sl.1 at sylea.org (Talarus Luan) Date: Thu, 28 Oct 2010 16:08:30 -0400 Subject: [opensource-dev] On Live, SL via Cloud Computing In-Reply-To: References: Message-ID: <4CC9D83E.3080307@sylea.org> On 10/27/2010 10:53 PM, Stickman wrote: > Had a thought, figured I'd share it in case someone with authority > wanted to explore the topic. I'm not an authority, but I have explored it a bit. > On Live (http://www.onlive.com/) is a cloud computing gaming service. > You open up the client and their computers run the game and graphics > and stream the video to you while accepting your controls. It means > you can run games on systems that otherwise wouldn't run them. > It's an iteration on an old idea. Render the scene, stream it to the user, accept user input back to the server to render the next scene, etc. It's always been a huge boondoggle because of the amount of bandwidth it takes, loss of image fidelity, and the control lag. > Pros: > -Less powerful computers can run SL on high settings It still requires a fairly beefy computer to run the decoding in high image quality with high frame rates, which is pretty much a requirement to avoid image artifacting. > Cons: > -$5/month subscription fee per user (Premium option?) > -Requires high bandwidth (3mbit) connection > -Probably consumes more bandwidth than SL itself would -Control lag; even though they claim it is "good enough" for FPS games, many FPS players who have tried it out report serious latency in control response, turning them off of it. -Image quality issues: viewing a virtual world as a compressed movie will have significantly noticeable image quality issues (and has been noted in reviews of the service). My personal take on it (and has been since the mid-90s, when this concept was first proposed) is "no thanks". I prefer to use the horsepower of my system to generate the world, especially since that horsepower is still ever-increasing on a geometric scale, and getting cheaper all the time. It also isn't that hard to keep SL's platform requirements within the grasp of older hardware for a good long while. --TL From labrat.hb at gmail.com Thu Oct 28 13:09:09 2010 From: labrat.hb at gmail.com (Harold Brown) Date: Thu, 28 Oct 2010 13:09:09 -0700 Subject: [opensource-dev] On Live, SL via Cloud Computing In-Reply-To: References: Message-ID: I have an OnLive Founders account, and it is actually pretty good for response time. The downside of it right now is the small game library and the fact that you have to use an XBOX360 controller if you want to use a joystick. On Thu, Oct 28, 2010 at 12:57 PM, Dale Innis wrote: > Has anyone on this list actually tried OnLive? ?What's the ping time > and the general responsiveness like? > > People are always hyping these server-side-rendering solutions as the > Next Big Thing, but so far I don't see it... > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting privileges > From suezanne at gmail.com Thu Oct 28 14:12:39 2010 From: suezanne at gmail.com (SuezanneC Baskerville) Date: Thu, 28 Oct 2010 16:12:39 -0500 Subject: [opensource-dev] Files deleted by uninstaller don't appear in Recycle Bin In-Reply-To: References: <60C115E4-83AC-4C69-AABB-D5AC743B76FB@lindenlab.com> <4CC9CA7E.1050003@sylea.org> Message-ID: It might be more logical to store the chat logs - or perhaps a copy of the chat logs - in the "My Documents" folder, or operating system equivalent. The recycle bin might be a gamble, but it has better odds of allowing data restoration that not putting the deleted files in the recycle bin, doesn't it? Putting deleted chat log files in the recycle bin is not meant to exclude other needed improvements such as not deleted the files in the first place. There are several jira issues about not deleting our chat logs and other files such as settings fles that could use some more looking at and perhaps some votes. VWR-21970 - https://jira.secondlife.com/browse/VWR-21970 VWR-17901 - https://jira.secondlife.com/browse/VWR-17901 VWR-17040 - https://jira.secondlife.com/browse/VWR-17040 STORM-280 - https://jira.secondlife.com/browse/STORM-280 PLAT-45 - https://jira.secondlife.com/browse/PLAT-45 VWR-17187 - https://jira.secondlife.com/browse/VWR-17187 VWR-20216 - https://jira.secondlife.com/browse/VWR-20216 VWR-18315 - https://jira.secondlife.com/browse/VWR-18315 There are probably some other related issues in addition to the above. On Thu, Oct 28, 2010 at 2:21 PM, Robert Martin wrote: > getting back to what i said > > 1 the uninstaller should state that it is removing the profile data > (best thing to do would be to zip it and put it in a folder on the > desktop) > > 2 TPVs should by default not use the default secondlife profile folder > (i would bet that 40% of SL/TPV problems could be solved by this > simple step) > > 3 the recycle bin is a gamble anyway and may not be safe to use (2 > gigs of profile data and a 1 gig recycle bin size = chunks of missing > data) > -- > Robert L Martin > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting > privileges > -- v i r t u a l w o r l d e n t h u s i a s t -- http://www.google.com/profiles/s u e z a n n e -- -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101028/7a431a7c/attachment-0001.htm From lee.ponzu at gmail.com Thu Oct 28 15:08:59 2010 From: lee.ponzu at gmail.com (Ponzu) Date: Thu, 28 Oct 2010 18:08:59 -0400 Subject: [opensource-dev] Files deleted by uninstaller don't appear in Recycle Bin In-Reply-To: References: <60C115E4-83AC-4C69-AABB-D5AC743B76FB@lindenlab.com> <4CC9CA7E.1050003@sylea.org> Message-ID: I don't see this as a theoretical issue about whether the logs should be deleted, or not. (Note the word "should".) Many users don't like it. Don't do it. lee -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101028/e4a78d74/attachment.htm From marc at inworlddesigns.com Thu Oct 28 15:12:30 2010 From: marc at inworlddesigns.com (Marc Adored) Date: Thu, 28 Oct 2010 18:12:30 -0400 Subject: [opensource-dev] Files deleted by uninstaller don't appear in Recycle Bin In-Reply-To: References: <60C115E4-83AC-4C69-AABB-D5AC743B76FB@lindenlab.com> <4CC9CA7E.1050003@sylea.org> Message-ID: Wow such a big discussion. I think the best plan would be to have both ways as an option like lots of installers do. Check this box to delete all files program created after it was installed simple enough and solves really any problem that arrises from left over cache and stuff if one is trying to reinstall a viewer On Thu, Oct 28, 2010 at 6:08 PM, Ponzu wrote: > I don't see this as a theoretical issue about whether the logs should be > deleted, or not. ?(Note the word "should".) > Many users don't like it. ?Don't do it. > lee > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting > privileges > From merov at lindenlab.com Thu Oct 28 15:44:01 2010 From: merov at lindenlab.com (Philippe (Merov) Bossut) Date: Thu, 28 Oct 2010 15:44:01 -0700 Subject: [opensource-dev] Issue with Snowstorm build 213153 Message-ID: Hi, We had a strange issue today with that build which ended up being built from a merged node instead of the tip. The last 2 changeset in the tree are: changeset: 13218:f687381cc6bc tag: tip parent: 13216:f6305a7f525c parent: 13217:3795a42120f6 user: Merov Linden date: Wed Oct 27 11:44:33 2010 -0700 summary: STORM-452 : merge with viewer-development changeset: 13217:3795a42120f6 parent: 13205:f40486111006 user: Andrew Productengine date: Wed Oct 27 19:23:52 2010 +0300 summary: STORM-452 FIXED Made protective fix for crash in LLAgentCamera::resetView(). I pushed those (and other changes) at the same time on the tree. Clearly, "f687381cc6bc" is the tip but TC picked up "3795a42120f6" instead and that ended up building things that were missing a day of merges. A bunch of JIRA thus have been failing QA and were back in the "To Do" swim lane. We do not know why TC did this but it's possible this is a rare "back to the future" issue: the time stamp for Andrew changeset is actually more recent than the timestamp of my merge thanks to our respective time zones. We suspect that this confused TC when picking up the repo. After consulting with hg/TC experts, we think that this was a "one off" occurrence because of me merging aggressively Andrew's changes right after they were done. I'm going to resume merging now and, hopefully, everything will be back to normal in the next build. Thanks for your attention and sorry for the confusion. Cheers, - Merov -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101028/6755b4bf/attachment.htm From thomas.shikami at online.de Thu Oct 28 15:56:09 2010 From: thomas.shikami at online.de (Thomas Shikami) Date: Fri, 29 Oct 2010 00:56:09 +0200 Subject: [opensource-dev] Files deleted by uninstaller don't appear in Recycle Bin In-Reply-To: References: <60C115E4-83AC-4C69-AABB-D5AC743B76FB@lindenlab.com> <4CC9CA7E.1050003@sylea.org> Message-ID: <4CC9FF89.3010006@online.de> Just follow Microsoft requirements for Windows Logo for installation and uninstallation on the Windows platform. One of it is to never touch the user profile. This is a requirement for Terminal Services Aware applications. For removing "breadcrumbs", this is not working, an uninstaller cannot remove data from all user profiles, this is not possible. Instead an ISV can provide a profile cleanup utility. LL should follow the standards and restrictions. From suezanne at gmail.com Thu Oct 28 16:35:07 2010 From: suezanne at gmail.com (SuezanneC Baskerville) Date: Thu, 28 Oct 2010 18:35:07 -0500 Subject: [opensource-dev] Files deleted by uninstaller don't appear in Recycle Bin In-Reply-To: <4CC9FF89.3010006@online.de> References: <60C115E4-83AC-4C69-AABB-D5AC743B76FB@lindenlab.com> <4CC9CA7E.1050003@sylea.org> <4CC9FF89.3010006@online.de> Message-ID: 6 years and 9 months of chat logs is not "bread crumbs". v i r t u a l w o r l d e n t h u s i a s t -- http://www.google.com/profiles/s u e z a n n e -- -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101028/c9236047/attachment.htm From merov at lindenlab.com Thu Oct 28 17:16:24 2010 From: merov at lindenlab.com (Philippe (Merov) Bossut) Date: Thu, 28 Oct 2010 17:16:24 -0700 Subject: [opensource-dev] Issue with Snowstorm build 213153 In-Reply-To: References: Message-ID: Hi, As a follow up to this, it seems that build 213294 is all correct now: http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repo/snowstorm_viewer-development/rev/213294/index.html Cheers, - Merov On Thu, Oct 28, 2010 at 3:44 PM, Philippe (Merov) Bossut < merov at lindenlab.com> wrote: > Hi, > > We had a strange issue today with that build which ended up being built > from a merged node instead of the tip. The last 2 changeset in the tree are: > > changeset: 13218:f687381cc6bc > tag: tip > parent: 13216:f6305a7f525c > parent: 13217:3795a42120f6 > user: Merov Linden > date: Wed Oct 27 11:44:33 2010 -0700 > summary: STORM-452 : merge with viewer-development > > changeset: 13217:3795a42120f6 > parent: 13205:f40486111006 > user: Andrew Productengine > date: Wed Oct 27 19:23:52 2010 +0300 > summary: STORM-452 FIXED Made protective fix for crash in > LLAgentCamera::resetView(). > > I pushed those (and other changes) at the same time on the tree. Clearly, > "f687381cc6bc" is the tip but TC picked up "3795a42120f6" instead and that > ended up building things that were missing a day of merges. A bunch of JIRA > thus have been failing QA and were back in the "To Do" swim lane. > > We do not know why TC did this but it's possible this is a rare "back to > the future" issue: the time stamp for Andrew changeset is actually more > recent than the timestamp of my merge thanks to our respective time zones. > We suspect that this confused TC when picking up the repo. > > After consulting with hg/TC experts, we think that this was a "one off" > occurrence because of me merging aggressively Andrew's changes right after > they were done. I'm going to resume merging now and, hopefully, everything > will be back to normal in the next build. > > Thanks for your attention and sorry for the confusion. > > Cheers, > - Merov > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101028/d3a9c195/attachment.htm From angel_of_crimson at hotmail.com Thu Oct 28 23:36:18 2010 From: angel_of_crimson at hotmail.com (Erin Mallory) Date: Fri, 29 Oct 2010 02:36:18 -0400 Subject: [opensource-dev] Files deleted by uninstaller don't appear in Recycle Bin In-Reply-To: References: , , , , <60C115E4-83AC-4C69-AABB-D5AC743B76FB@lindenlab.com>, <4CC9CA7E.1050003@sylea.org>, , , , <4CC9FF89.3010006@online.de>, Message-ID: I lost 3 years on one computer and 4 on another because of uninstalling all v2 versions at the request of support (which i later learned was unneeded). I was assured i didn't need to back up my logs before hand. I tried to retrieve them using some of the data recovery programs we have at work, but the installer overwrote them when it erased them. WTF??? There are three failures here. The failure to provide at least the option to keep the logs, the failure of LL to have support people that know what the fuck they are doing, and using an installer that scrubs the deleted files so they can't be recoverable. All I can say is THANK GOD it was my personal computers and not my work ones. But even so, the loss of some of those logs really hurt and caused some real tears... especially the ones from users that are now deceased or missing irl. I can never recover those, and it angers me to no end that the inability of someone to actually think through a decision means that I cannot go back and reread the conversations we had anymore.... and yes now before i uninstall anything i back up the files. and i would have before uninstalling all the versions of v2 i had had at the time, except i was assured by live support that the installers would NOT touch those files. Just one more in a heap load of instances where someone at LL or their contractors decided that because they wanted something done a certain way all users would. so if some of the lindens wonder why i am so passionate and stubborn and why when you pull that "we're doing it this way and there's no discussion" crap, its cause that mentality leads to things like this happening.... Date: Thu, 28 Oct 2010 18:35:07 -0500 From: suezanne at gmail.com To: thomas.shikami at online.de CC: opensource-dev at lists.secondlife.com Subject: Re: [opensource-dev] Files deleted by uninstaller don't appear in Recycle Bin 6 years and 9 months of chat logs is not "bread crumbs". v i r t u a l w o r l d e n t h u s i a s t -- http://www.google.com/profiles/s u e z a n n e -- _______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101029/13338928/attachment-0001.htm From kow at sapinski.com Fri Oct 29 01:23:45 2010 From: kow at sapinski.com (k\o\w) Date: Fri, 29 Oct 2010 04:23:45 -0400 Subject: [opensource-dev] Files deleted by uninstaller don't appear in Recycle Bin In-Reply-To: References: , , , , <60C115E4-83AC-4C69-AABB-D5AC743B76FB@lindenlab.com>, <4CC9CA7E.1050003@sylea.org>, , , , <4CC9FF89.3010006@online.de>, Message-ID: <4CCA8491.2080603@sapinski.com> I'm having trouble reproducing this issue, when I uninstall Viewer 2 my logs and settings, even my local asset cache remain (using Win7 x64). What operating system are you folks experiencing the problem with? I suspect this might be related to using XP, which doesn't allocate separate folders for local and roaming application data like Vista/7 do. A quick peek at the installer template reveals that on XP the Application Data/Second Life folder is removed, while on Vista/7 only AppData/*local*/Second Life is removed, while the logs/settings in /AppData/*roaming*/Second Life should remain untouched. This pretty much defines best practice in terms of handling application data. If that is the case, then Linden should go ahead and ignore the bug as it's caused by the nature of a ~10 year old operating system. I'd rather see effort being put into supporting new Windows SDK features than working around old ones. Log file location is one of the few things you can change directly from preferences, and probably exactly for this reason. If you care so much backup your data more often or learn to use system/file restore. As for overwriting your old logs, you did that yourself when you installed over recently freed up HD space. Not a software bug. On 10/29/2010 2:36 AM, Erin Mallory wrote: > I lost 3 years on one computer and 4 on another because of > uninstalling all v2 versions at the request of support (which i later > learned was unneeded). I was assured i didn't need to back up my logs > before hand. I tried to retrieve them using some of the data recovery > programs we have at work, but the installer overwrote them when it > erased them. WTF??? > There are three failures here. The failure to provide at least the > option to keep the logs, the failure of LL to have support people that > know what the fuck they are doing, and using an installer that scrubs > the deleted files so they can't be recoverable. > All I can say is THANK GOD it was my personal computers and not my > work ones. > But even so, the loss of some of those logs really hurt and caused > some real tears... especially the ones from users that are now > deceased or missing irl. I can never recover those, and it angers me > to no end that the inability of someone to actually think through a > decision means that I cannot go back and reread the conversations we > had anymore.... and yes now before i uninstall anything i back up the > files. and i would have before uninstalling all the versions of v2 i > had had at the time, except i was assured by live support that the > installers would NOT touch those files. > > Just one more in a heap load of instances where someone at LL or their > contractors decided that because they wanted something done a certain > way all users would. so if some of the lindens wonder why i am so > passionate and stubborn and why when you pull that "we're doing it > this way and there's no discussion" crap, its cause that mentality > leads to things like this happening.... > > > ------------------------------------------------------------------------ > Date: Thu, 28 Oct 2010 18:35:07 -0500 > From: suezanne at gmail.com > To: thomas.shikami at online.de > CC: opensource-dev at lists.secondlife.com > Subject: Re: [opensource-dev] Files deleted by uninstaller don't > appear in Recycle Bin > > 6 years and 9 months of chat logs is not "bread crumbs". > > v i r t u a l w o r l d e n t h u s i a s t > -- http://www.google.com/profiles/s u e z a n n e -- > > _______________________________________________ Policies and > (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the > policies before posting to keep unmoderated posting privileges > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting privileges -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101029/c139b9e3/attachment.htm From secret.argent at gmail.com Fri Oct 29 04:48:05 2010 From: secret.argent at gmail.com (Argent Stonecutter) Date: Fri, 29 Oct 2010 06:48:05 -0500 Subject: [opensource-dev] Files deleted by uninstaller don't appear in Recycle Bin In-Reply-To: <60C115E4-83AC-4C69-AABB-D5AC743B76FB@lindenlab.com> References: <60C115E4-83AC-4C69-AABB-D5AC743B76FB@lindenlab.com> Message-ID: <73442E49-875F-48F2-B4C5-4B5907EEA2DB@gmail.com> On 2010-10-27, at 09:45, Kent Quirk (Q Linden) wrote: > Au contraire. Some people get very upset when an installer leaves any files behind that were created by the program automatically, such as log files. It's simply not true that the uninstaller shouldn't remove anything in the profile -- I have worked at multiple companies where leaving behind any breadcrumbs (anything that wasn't created by File Save) after an uninstall was considered a major bug. If the files are unambiguously owned by that specific instance of the program, and there is no likelihood that other instances of the program might be still installed, that might be true. Most programs are single-instance. Once uninstalled, it will never be installed again. That doesn't apply to files that are shared by multiple programs, and it doesn't apply to documents created by the program. Whether chat logs should be considered documents or log files is perhaps debatable, but that it's even debatable should be enough to exempt them from automatic deletion. And for Second Life, where it's routine to install and uninstall beta versions of the program, and where beta versions share files with the regular install, it shouldn't even be considered. From secret.argent at gmail.com Fri Oct 29 04:52:30 2010 From: secret.argent at gmail.com (Argent Stonecutter) Date: Fri, 29 Oct 2010 06:52:30 -0500 Subject: [opensource-dev] Files deleted by uninstaller don't appear in Recycle Bin In-Reply-To: References: <60C115E4-83AC-4C69-AABB-D5AC743B76FB@lindenlab.com> <90B6C3ED-4CF3-4D6F-800A-3BB82F1B006B@gmail.com> Message-ID: On 2010-10-27, at 16:33, Zabb65 wrote: > My only concern with some of this, is that it eliminates the support > teams easy one line answer to everything odd or unexplained. Uninstall > and reinstall the client. Good. Replace that with a "reset to default settings" option in Preferences. If you want to reset preferences, then make it explicit. Think of it like "Safe Mode", or like "Reset to Safe Defaults/Reset to Optimized Defaults" in your PC BIOS. From secret.argent at gmail.com Fri Oct 29 05:09:47 2010 From: secret.argent at gmail.com (Argent Stonecutter) Date: Fri, 29 Oct 2010 07:09:47 -0500 Subject: [opensource-dev] Files deleted by uninstaller don't appear in Recycle Bin In-Reply-To: <4CCA8491.2080603@sapinski.com> References: , , , , <60C115E4-83AC-4C69-AABB-D5AC743B76FB@lindenlab.com>, <4CC9CA7E.1050003@sylea.org>, , , , <4CC9FF89.3010006@online.de>, <4CCA8491.2080603@sapinski.com> Message-ID: <9E2FEABF-2DF8-45F5-BE8F-A8DCE3B42CD2@gmail.com> On 2010-10-29, at 03:23, kow wrote: > If that is the case, then Linden should go ahead and ignore the bug as it's caused by the nature of a ~10 year old operating system. A ten year old operating system that is still supported and widely used, more widely used than Vista for sure, and will no doubt continue to be widely used long after Microsoft gives up on it. The people who have a lot of log files, the ones worst impacted by this, installed Second Life long before Seven was shipped (we can ignore Vista, even Microsoft seems to prefer we forgot about it). From q at lindenlab.com Fri Oct 29 07:49:39 2010 From: q at lindenlab.com (Kent Quirk (Q Linden)) Date: Fri, 29 Oct 2010 10:49:39 -0400 Subject: [opensource-dev] Files deleted by uninstaller don't appear in Recycle Bin In-Reply-To: <73442E49-875F-48F2-B4C5-4B5907EEA2DB@gmail.com> References: <60C115E4-83AC-4C69-AABB-D5AC743B76FB@lindenlab.com> <73442E49-875F-48F2-B4C5-4B5907EEA2DB@gmail.com> Message-ID: <2670FDDF-58CA-48D6-A633-FD3DAB12B14A@lindenlab.com> Ok, people are quoting me without also quoting the context of the statement I was responding to, which was a categorical "never", and also not quoting what else I said, which was: > Now I do think we can try do better; asking about deletion is on the Snowstorm backlog. > > There's work going on right now that will probably affect this, and we'll make sure this is considered. I do agree that we shouldn't delete logs without asking, and we'll get to it, probably this quarter. I'm sorry if people misunderstood my comment. Q From lee.ponzu at gmail.com Fri Oct 29 17:12:09 2010 From: lee.ponzu at gmail.com (Ponzu) Date: Fri, 29 Oct 2010 20:12:09 -0400 Subject: [opensource-dev] Possible problem with beta download Message-ID: I just downloaded the new beta 2.3 from the link on the Blog. I got 212977. Then I started it. I got a message. See the attached picture. It offers me to download 212997. (Look close, Different number.) When I click to download, it downloads 212977. It looks to me like the number in the message on the login screen is incorrect. ponzu -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101029/9279bf4a/attachment-0001.htm -------------- next part -------------- A non-text attachment was scrubbed... Name: Screen shot 2010-10-29 at 8.08.55 PM.png Type: image/png Size: 87899 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101029/9279bf4a/attachment-0001.png From angel_of_crimson at hotmail.com Fri Oct 29 20:47:07 2010 From: angel_of_crimson at hotmail.com (Erin Mallory) Date: Fri, 29 Oct 2010 23:47:07 -0400 Subject: [opensource-dev] display name userstory Message-ID: as a user, if there are network issues in SL I would like display name enabled clients to NOT report avatars as ???-??? but rather default to user name or ??? - username -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101029/331da561/attachment.htm From nexisentertainment at gmail.com Sat Oct 30 04:58:25 2010 From: nexisentertainment at gmail.com (Rob Nelson) Date: Sat, 30 Oct 2010 04:58:25 -0700 Subject: [opensource-dev] display name userstory In-Reply-To: References: Message-ID: <4CCC0861.8000604@gmail.com> How about "username (Loading...)", in order to queue people in as to why their display names aren't showing up. Should relieve pressure on support staff. Rob On 10/29/2010 8:47 PM, Erin Mallory wrote: > as a user, if there are network issues in SL I would like display name > enabled clients to NOT report avatars as ???-??? but rather default to > user name or ??? - username > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting privileges -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101030/c7435829/attachment.htm From babytje_ab at live.com Sat Oct 30 05:04:35 2010 From: babytje_ab at live.com (Alexandrea Fride) Date: Sat, 30 Oct 2010 14:04:35 +0200 Subject: [opensource-dev] display name userstory In-Reply-To: <4CCC0861.8000604@gmail.com> References: <4CCC0861.8000604@gmail.com> Message-ID: Nice but on tiny problem IF the client when it hapens alredy cant get First and Last name how you suposte to get the username? username = first and last name and i would think that getting the Display Name is same way as getting username(first and last name), i would assume those info are together when fetching that data Greetings From: Rob Nelson Sent: Saturday, October 30, 2010 1:58 PM To: opensource-dev at lists.secondlife.com Subject: Re: [opensource-dev] display name userstory How about "username (Loading...)", in order to queue people in as to why their display names aren't showing up. Should relieve pressure on support staff. Rob On 10/29/2010 8:47 PM, Erin Mallory wrote: as a user, if there are network issues in SL I would like display name enabled clients to NOT report avatars as ???-??? but rather default to user name or ??? - username -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101030/6ac132f0/attachment.htm From angel_of_crimson at hotmail.com Sat Oct 30 08:58:28 2010 From: angel_of_crimson at hotmail.com (Erin Mallory) Date: Sat, 30 Oct 2010 11:58:28 -0400 Subject: [opensource-dev] display name userstory In-Reply-To: References: , <4CCC0861.8000604@gmail.com>, Message-ID: Aside from the friends list itself, I never had issues with avatars around me displaying their user names until the display name support was added. In fact last night, I tested three versions of v2. The official standard. what was the most recent dev build, and oz's test build of 255 which has support for display names. Oz's test build was showing all names as ??? -??? during the period when the grid seemed to be having major issues, where as the other two only showed "Loading" in the friends list. From: babytje_ab at live.com To: opensource-dev at lists.secondlife.com Date: Sat, 30 Oct 2010 14:04:35 +0200 Subject: Re: [opensource-dev] display name userstory Nice but on tiny problem IF the client when it hapens alredy cant get First and Last name how you suposte to get the username? username = first and last name and i would think that getting the Display Name is same way as getting username(first and last name), i would assume those info are together when fetching that data Greetings From: Rob Nelson Sent: Saturday, October 30, 2010 1:58 PM To: opensource-dev at lists.secondlife.com Subject: Re: [opensource-dev] display name userstory How about "username (Loading...)", in order to queue people in as to why their display names aren't showing up. Should relieve pressure on support staff. Rob On 10/29/2010 8:47 PM, Erin Mallory wrote: as a user, if there are network issues in SL I would like display name enabled clients to NOT report avatars as ???-??? but rather default to user name or ??? - username _______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101030/e4d429f2/attachment.htm From angel_of_crimson at hotmail.com Sat Oct 30 09:01:58 2010 From: angel_of_crimson at hotmail.com (Erin Mallory) Date: Sat, 30 Oct 2010 12:01:58 -0400 Subject: [opensource-dev] display name userstory In-Reply-To: References: , , <4CCC0861.8000604@gmail.com>, , , Message-ID: One more thing, the way it is now, it seems to break logging when the names were all displayed as ??? - ???. I would get chat histories of one person I chatted with showing up in the im window of someone else when I opened or received a new im... From: angel_of_crimson at hotmail.com To: babytje_ab at live.com; opensource-dev at lists.secondlife.com Date: Sat, 30 Oct 2010 11:58:28 -0400 Subject: Re: [opensource-dev] display name userstory Aside from the friends list itself, I never had issues with avatars around me displaying their user names until the display name support was added. In fact last night, I tested three versions of v2. The official standard. what was the most recent dev build, and oz's test build of 255 which has support for display names. Oz's test build was showing all names as ??? -??? during the period when the grid seemed to be having major issues, where as the other two only showed "Loading" in the friends list. From: babytje_ab at live.com To: opensource-dev at lists.secondlife.com Date: Sat, 30 Oct 2010 14:04:35 +0200 Subject: Re: [opensource-dev] display name userstory Nice but on tiny problem IF the client when it hapens alredy cant get First and Last name how you suposte to get the username? username = first and last name and i would think that getting the Display Name is same way as getting username(first and last name), i would assume those info are together when fetching that data Greetings From: Rob Nelson Sent: Saturday, October 30, 2010 1:58 PM To: opensource-dev at lists.secondlife.com Subject: Re: [opensource-dev] display name userstory How about "username (Loading...)", in order to queue people in as to why their display names aren't showing up. Should relieve pressure on support staff. Rob On 10/29/2010 8:47 PM, Erin Mallory wrote: as a user, if there are network issues in SL I would like display name enabled clients to NOT report avatars as ???-??? but rather default to user name or ??? - username _______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges _______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101030/4dc2a307/attachment.htm From tateru at taterunino.net Sat Oct 30 09:17:25 2010 From: tateru at taterunino.net (Tateru Nino) Date: Sun, 31 Oct 2010 03:17:25 +1100 Subject: [opensource-dev] display name userstory In-Reply-To: References: , , <4CCC0861.8000604@gmail.com>, , , Message-ID: <4CCC4515.8020603@taterunino.net> Sounds like a showstopper to me. On 31/10/2010 3:01 AM, Erin Mallory wrote: > One more thing, the way it is now, it seems to break logging when the > names were all displayed as ??? - ???. I would get chat histories of > one person I chatted with showing up in the im window of someone else > when I opened or received a new im... > > ------------------------------------------------------------------------ > From: angel_of_crimson at hotmail.com > To: babytje_ab at live.com; opensource-dev at lists.secondlife.com > Date: Sat, 30 Oct 2010 11:58:28 -0400 > Subject: Re: [opensource-dev] display name userstory > > Aside from the friends list itself, I never had issues with avatars > around me displaying their user names until the display name support > was added. In fact last night, I tested three versions of v2. The > official standard. what was the most recent dev build, and oz's test > build of 255 which has support for display names. Oz's test build was > showing all names as ??? -??? during the period when the grid seemed > to be having major issues, where as the other two only showed > "Loading" in the friends list. > > ------------------------------------------------------------------------ > From: babytje_ab at live.com > To: opensource-dev at lists.secondlife.com > Date: Sat, 30 Oct 2010 14:04:35 +0200 > Subject: Re: [opensource-dev] display name userstory > > Nice but on tiny problem > IF the client when it hapens alredy cant get First and Last name how > you suposte to get the username? > username = first and last name > and i would think that getting the Display Name is same way as getting > username(first and last name), i would assume those info are together > when fetching that data > Greetings > *From:* Rob Nelson > *Sent:* Saturday, October 30, 2010 1:58 PM > *To:* opensource-dev at lists.secondlife.com > > *Subject:* Re: [opensource-dev] display name userstory > How about "username (Loading...)", in order to queue people in as to > why their display names aren't showing up. Should relieve pressure on > support staff. > > Rob > > On 10/29/2010 8:47 PM, Erin Mallory wrote: > > as a user, if there are network issues in SL I would like display > name enabled clients to NOT report avatars as ???-??? but rather > default to user name or ??? - username > > > _______________________________________________ Policies and > (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the > policies before posting to keep unmoderated posting privileges > _______________________________________________ Policies and > (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the > policies before posting to keep unmoderated posting privileges > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting privileges -- Tateru Nino http://dwellonit.taterunino.net/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101031/8b661a42/attachment-0001.htm From twisted_laws at hotmail.com Sat Oct 30 12:59:59 2010 From: twisted_laws at hotmail.com (Twisted Laws) Date: Sat, 30 Oct 2010 15:59:59 -0400 Subject: [opensource-dev] possible display name crash In-Reply-To: <4CCC4515.8020603@taterunino.net> References: , ,,<4CCC0861.8000604@gmail.com>, , , , , , , <4CCC4515.8020603@taterunino.net> Message-ID: Not sure what the issue is, but today, i've had 3 crashes in LLHUDNameTag::setLabel at mLabelSegments.clear() running my own build of latest pull from viewer-development on Windows 7. It may have something to do with boost or just a timing issue between threads or maybe its just me or where i was. These all happened in sandbox goguen while my display name was set to something different. It appeared it happens when someone leaves the region. All the locals looked good further in the call stack but when it gets to the crash point, "this" equals 0xffffffff. Any other issues like this? This only started happening today and never with builds before last wednesday. Turning off display names allows me to run the same version with no problems. I don't see recent changes in this area and have tried rebuild all, etc.. Anyone have an idea? Twisted -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101030/642aa97c/attachment.htm From troy at troymcconaghy.com Sat Oct 30 16:01:35 2010 From: troy at troymcconaghy.com (Troy McConaghy) Date: Sat, 30 Oct 2010 16:01:35 -0700 Subject: [opensource-dev] Question about SL Search API Message-ID: Hi, This question is about the SL Search API: Does anyone on this list know how to build an URL to request a search for all Events with Category = Sports? The SL Search API documentation at http://wiki.secondlife.com/wiki/SearchAPIis somewhat useful. For example, I learned I can search for all events Events with "the" using: http://search.secondlife.com/client_search.php?q=the&s=Events but the documentation doesn't say how to search for *all* events (not just ones with "the" --- &q= doesn't work) and it doesn't say how to restrict the Events Category to Sports. I suspect it's something like &cat=sports tacked onto the URL but that isn't working. I know about http://search.secondlife.com/web/search/events/ but it's not what I need. I need the results it presents, but I need to get them using the SL Search API. Sincerely, Troy McConaghy -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101030/e4856d4f/attachment.htm From sldev at catznip.com Sun Oct 31 07:51:08 2010 From: sldev at catznip.com (Kitty) Date: Sun, 31 Oct 2010 15:51:08 +0100 Subject: [opensource-dev] possible display name crash In-Reply-To: References: , , , <4CCC0861.8000604@gmail.com>, , , , , , , <4CCC4515.8020603@taterunino.net> Message-ID: <000001cb790b$1ea879f0$5bf96dd0$@com> I'm not sure if this is actually your crash, but it seems to match rather closely with a lot of what you described: https://jira.secondlife.com/browse/VWR-23653 (patch attached). Kitty