From wolfpup67 at earthlink.net Sat Jan 1 05:41:20 2011 From: wolfpup67 at earthlink.net (WolfPup Lowenhar) Date: Sat, 1 Jan 2011 08:41:20 -0500 Subject: [opensource-dev] HAPPY NEW YEAR !!!!!!!!!!!!! Message-ID: <000001cba9b9$93217b40$b96471c0$@net> Even though the new year has already started I just thought I would wish everyone here a HAPPY NEW YEAR !!!!! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110101/bf320e67/attachment.htm From aleric.inglewood at gmail.com Sat Jan 1 06:40:34 2011 From: aleric.inglewood at gmail.com (Aleric Inglewood) Date: Sat, 1 Jan 2011 15:40:34 +0100 Subject: [opensource-dev] A weird bug when moving the avatar In-Reply-To: <72A6811A-550E-4C41-A8EF-B0F0837A7940@gmail.com> References: <72A6811A-550E-4C41-A8EF-B0F0837A7940@gmail.com> Message-ID: Confirmed... When I first tried Viewer 2, my FPS would drop from 80 to 5 as soon as I pressed the 'walk forward' key. I didn't happen with the last compile (of the latest viewer-development) though. On Sat, Jan 1, 2011 at 3:33 AM, Trilo Byte wrote: > It's possible... I've been semi-crippled by lack of support for my nVidia GPU and the whole framerate stutter thing > https://jira.secondlife.com/browse/VWR-23318 > > When I get a chance, I'll see if I can isolate/reproduce. > > On Dec 31, 2010, at 5:59 PM, Marine Kelley wrote: > >> I have observed this behavior with the rev 14120 of viewer-development : >> >> https://jira.secondlife.com/browse/VWR-24361 (name checked this time) >> >> In short, when you press a movement key or use the move panel (going >> forward, backward etc, but not turning left or right), the FPS >> decrease dramatically (from 90 down to 15 FPS). It can be very >> annoying during races or fights. >> >> Has anybody observed this too ? I don't remember having seen this >> happen in older viewers, but I recently changed my video card so maybe >> the change in FPS was not noticeable to me before. >> >> And more importantly, has any work been done recently (less than two >> months ago) on the way the avatar movement is handled, that could >> trigger this bug ? I don't really know where to look so if anybody has >> pointers, please feel free to share ! >> >> Thanks, >> Marine >> _______________________________________________ >> Policies 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 Sat Jan 1 08:24:21 2011 From: lee.ponzu at gmail.com (Ponzu) Date: Sat, 1 Jan 2011 11:24:21 -0500 Subject: [opensource-dev] HAPPY NEW YEAR !!!!!!!!!!!!! In-Reply-To: <000001cba9b9$93217b40$b96471c0$@net> References: <000001cba9b9$93217b40$b96471c0$@net> Message-ID: New year, no hangover. What a waste 8-( On Sat, Jan 1, 2011 at 8:41 AM, WolfPup Lowenhar wrote: > Even though the new year has already started I just thought I would wish > everyone here a > > > > HAPPY > > NEW > > YEAR > > !!!!! > > > > _______________________________________________ > Policies 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/20110101/5bfb824e/attachment.htm From laurent.bechir at madonie.org Sun Jan 2 11:25:37 2011 From: laurent.bechir at madonie.org (Laurent Rathle) Date: Sun, 02 Jan 2011 20:25:37 +0100 Subject: [opensource-dev] Exclude Home from teleport history Message-ID: <4D20D131.9080001@madonie.org> Hello, Would it be easy to exclude home from Teleport history ? It would make it easier to see what' in From angel_of_crimson at hotmail.com Sun Jan 2 11:39:59 2011 From: angel_of_crimson at hotmail.com (Erin Mallory) Date: Sun, 2 Jan 2011 14:39:59 -0500 Subject: [opensource-dev] Exclude Home from teleport history In-Reply-To: <4D20D131.9080001@madonie.org> References: <4D20D131.9080001@madonie.org> Message-ID: I would really really rather not see home excluded because of the simple fact often home lotation can get reset if your preferences get changed or any of a half dozen minor bugs. so its nice to have it in the hisotry so you can go back and set it back. > Date: Sun, 2 Jan 2011 20:25:37 +0100 > From: laurent.bechir at madonie.org > To: opensource-dev at lists.secondlife.com > Subject: [opensource-dev] Exclude Home from teleport history > > > Hello, > > Would it be easy to exclude home from Teleport history ? It would make > it easier to see what' 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/20110102/a7cc911d/attachment.htm From kf6kjg at gmail.com Sun Jan 2 12:09:08 2011 From: kf6kjg at gmail.com (Ricky) Date: Sun, 2 Jan 2011 12:09:08 -0800 Subject: [opensource-dev] Exclude Home from teleport history In-Reply-To: References: <4D20D131.9080001@madonie.org> Message-ID: A method of filtering the history would give the wanted effect I presume. Ricky Cron Stardust On Sun, Jan 2, 2011 at 11:39 AM, Erin Mallory wrote: > I would really really rather not see home excluded because of the simple > fact often home lotation can get reset if your preferences get changed or > any of a half dozen minor bugs.? so its nice to have it in the hisotry so > you can go back and set it back. > >> Date: Sun, 2 Jan 2011 20:25:37 +0100 >> From: laurent.bechir at madonie.org >> To: opensource-dev at lists.secondlife.com >> Subject: [opensource-dev] Exclude Home from teleport history >> >> >> Hello, >> >> Would it be easy to exclude home from Teleport history ? It would make >> it easier to see what' 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 > > _______________________________________________ > Policies 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 Sun Jan 2 13:00:59 2011 From: kf6kjg at gmail.com (Ricky) Date: Sun, 2 Jan 2011 13:00:59 -0800 Subject: [opensource-dev] VWR-8208 Searchable "Debug Settings" Message-ID: I was just about to create a JIRA entry for the idea of making things easier to find in the Debug Settings menu, when I found an existant JIRA on the subject. VWR-8208 "find instead of auto-complete for Debug Settings" https://jira.secondlife.com/browse/VWR-8208 It would be great to have some attention paid to this concept, as it should be fairly trivial to implement, and would make working with those entries a lot easier. Just making some noise about one of my annoyances... Ricky Cron Stardust From marinekelley at gmail.com Sun Jan 2 13:52:58 2011 From: marinekelley at gmail.com (Marine Kelley) Date: Sun, 2 Jan 2011 22:52:58 +0100 Subject: [opensource-dev] VWR-8208 Searchable "Debug Settings" In-Reply-To: References: Message-ID: What I do is open my settings.xml file and search what I want with a text editor, it works. On 02/01/2011, Ricky wrote: > I was just about to create a JIRA entry for the idea of making things > easier to find in the Debug Settings menu, when I found an existant > JIRA on the subject. VWR-8208 "find instead of auto-complete for > Debug Settings" https://jira.secondlife.com/browse/VWR-8208 > It would be great to have some attention paid to this concept, as it > should be fairly trivial to implement, and would make working with > those entries a lot easier. > > Just making some noise about one of my annoyances... > 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 > From kf6kjg at gmail.com Sun Jan 2 14:47:24 2011 From: kf6kjg at gmail.com (Ricky) Date: Sun, 2 Jan 2011 14:47:24 -0800 Subject: [opensource-dev] VWR-8208 Searchable "Debug Settings" In-Reply-To: References: Message-ID: Thank you Jonathan and Marine. These workarounds are good, and I will tap into them. Hopefully an in-client solution isn't too far into the future! :) Ricky On Sun, Jan 2, 2011 at 1:52 PM, Marine Kelley wrote: > What I do is open my settings.xml file and search what I want with a > text editor, it works. > > On 02/01/2011, Ricky wrote: >> I was just about to create a JIRA entry for the idea of making things >> easier to find in the Debug Settings menu, when I found an existant >> JIRA on the subject. ?VWR-8208 "find instead of auto-complete for >> Debug Settings" https://jira.secondlife.com/browse/VWR-8208 >> It would be great to have some attention paid to this concept, as it >> should be fairly trivial to implement, and would make working with >> those entries a lot easier. >> >> Just making some noise about one of my annoyances... >> 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 >> > From marinekelley at gmail.com Sun Jan 2 14:57:48 2011 From: marinekelley at gmail.com (Marine Kelley) Date: Sun, 2 Jan 2011 23:57:48 +0100 Subject: [opensource-dev] VWR-8208 Searchable "Debug Settings" In-Reply-To: References: Message-ID: Yes that would be great, because the debug settings are not in any particular order in settings.xml, while they are in alphabetical order in the viewer. Sometimes it can be confusing (especially when you browse all the Render* debug settings, they are all over the place). On 02/01/2011, Ricky wrote: > Thank you Jonathan and Marine. These workarounds are good, and I will > tap into them. Hopefully an in-client solution isn't too far into the > future! :) > > Ricky > > On Sun, Jan 2, 2011 at 1:52 PM, Marine Kelley > wrote: >> What I do is open my settings.xml file and search what I want with a >> text editor, it works. >> >> On 02/01/2011, Ricky wrote: >>> I was just about to create a JIRA entry for the idea of making things >>> easier to find in the Debug Settings menu, when I found an existant >>> JIRA on the subject. ?VWR-8208 "find instead of auto-complete for >>> Debug Settings" https://jira.secondlife.com/browse/VWR-8208 >>> It would be great to have some attention paid to this concept, as it >>> should be fairly trivial to implement, and would make working with >>> those entries a lot easier. >>> >>> Just making some noise about one of my annoyances... >>> 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 >>> >> > From laurent.bechir at madonie.org Sun Jan 2 17:03:45 2011 From: laurent.bechir at madonie.org (laurent.bechir at madonie.org) Date: Mon, 03 Jan 2011 02:03:45 +0100 Subject: [opensource-dev] Exclude Home from teleport history In-Reply-To: References: <4D20D131.9080001@madonie.org> Message-ID: <4D212071.1050602@madonie.org> Erin Mallory a ?crit : > I would really really rather not see home excluded because of the > simple fact often home lotation can get reset if your preferences get > changed or any of a half dozen minor bugs. so its nice to have it in > the hisotry so you can go back and set it back. I've never seen that. Did it happened to you already ? From angel_of_crimson at hotmail.com Sun Jan 2 19:38:50 2011 From: angel_of_crimson at hotmail.com (Erin Mallory) Date: Sun, 2 Jan 2011 22:38:50 -0500 Subject: [opensource-dev] Exclude Home from teleport history In-Reply-To: <4D212071.1050602@madonie.org> References: <4D20D131.9080001@madonie.org>, , <4D212071.1050602@madonie.org> Message-ID: Yes, ive had the home point reset when my age verification glitched and i couldnt get into my own land, and when i installed a viewer that defaulted the preferences to g only. > Date: Mon, 3 Jan 2011 02:03:45 +0100 > From: laurent.bechir at madonie.org > To: opensource-dev at lists.secondlife.com > Subject: Re: [opensource-dev] Exclude Home from teleport history > > > > Erin Mallory a ?crit : > > I would really really rather not see home excluded because of the > > simple fact often home lotation can get reset if your preferences get > > changed or any of a half dozen minor bugs. so its nice to have it in > > the hisotry so you can go back and set it back. > > I've never seen that. Did it happened to you already ? > _______________________________________________ > Policies 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/20110102/6005fa5e/attachment.htm From Aleric.Inglewood at gmail.com Sun Jan 2 21:17:48 2011 From: Aleric.Inglewood at gmail.com (Aleric Inglewood) Date: Mon, 03 Jan 2011 05:17:48 -0000 Subject: [opensource-dev] Review Request: VWR-24100 Settings.xml: redundant entries and unnecessary tag In-Reply-To: <20101223201240.7867.22247@domU-12-31-38-00-90-68.compute-1.internal> References: <20101223201240.7867.22247@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110103051748.6679.61870@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/18/#review107 ----------------------------------------------------------- Ship it! - Aleric On Dec. 23, 2010, 12:12 p.m., Jonathan Yap wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/18/ > ----------------------------------------------------------- > > (Updated Dec. 23, 2010, 12:12 p.m.) > > > Review request for Viewer. > > > Summary > ------- > > I wrote two programs that use settings.xml to produce this massive table: > http://wiki.secondlife.com/wiki/Debug_Settings > > While doing this I found 4 places with duplicate entries and 1 entry that is repeated 4 times. There is also a pair of unnecessary tags. > > Having these cleaned out would make running my program, and thus updating the wiki table, easier. > > I've erased all but the last entry for these redundant debug settings. > > > This addresses bug vwr-24100. > http://jira.secondlife.com/browse/vwr-24100 > > > Diffs > ----- > > indra/newview/app_settings/settings.xml 46a990f8296f > > Diff: http://codereview.secondlife.com/r/18/diff > > > Testing > ------- > > > Thanks, > > Jonathan > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110103/487f227d/attachment.htm From tateru at taterunino.net Sun Jan 2 21:43:41 2011 From: tateru at taterunino.net (Tateru Nino) Date: Mon, 03 Jan 2011 16:43:41 +1100 Subject: [opensource-dev] Exclude Home from teleport history In-Reply-To: <4D212071.1050602@madonie.org> References: <4D20D131.9080001@madonie.org> <4D212071.1050602@madonie.org> Message-ID: <4D21620D.2050805@taterunino.net> On 3/01/2011 12:03 PM, laurent.bechir at madonie.org wrote: > > Erin Mallory a ?crit : >> I would really really rather not see home excluded because of the >> simple fact often home lotation can get reset if your preferences get >> changed or any of a half dozen minor bugs. so its nice to have it in >> the hisotry so you can go back and set it back. > I've never seen that. Did it happened to you already ? I've had it happen to me before also. There's a couple things that can silently reset your home location. For a while, some people were triggering it intentionally as a way of evading parcel ejection and so on - sure the owner can try to send you home, but if your home is where you are, nothing happens. At least one of the methods (which can happen unintentionally) was repeatedly reported as a security exploit back in 2006 - but AFAIK, it's still unfixed. -- Tateru Nino http://dwellonit.taterunino.net/ From opensourceobscure at gmail.com Mon Jan 3 03:06:31 2011 From: opensourceobscure at gmail.com (Opensource Obscure) Date: Mon, 3 Jan 2011 12:06:31 +0100 Subject: [opensource-dev] A weird bug when moving the avatar In-Reply-To: References: <72A6811A-550E-4C41-A8EF-B0F0837A7940@gmail.com> Message-ID: I saw something similar with recent development viewer builds on Linux. It makes the viewer unusable to me (it actually freezes for a few seconds here, not just slow down). I will add more details to VWR-24361 asap. Opensource Obscure On Sat, Jan 1, 2011 at 15:40, Aleric Inglewood wrote: > Confirmed... When I first tried Viewer 2, my FPS would drop from 80 to > 5 as soon as I pressed > the 'walk forward' key. I didn't happen with the last compile (of the > latest viewer-development) > though. > > On Sat, Jan 1, 2011 at 3:33 AM, Trilo Byte wrote: >> It's possible... I've been semi-crippled by lack of support for my nVidia GPU and the whole framerate stutter thing >> https://jira.secondlife.com/browse/VWR-23318 >> >> When I get a chance, I'll see if I can isolate/reproduce. >> >> On Dec 31, 2010, at 5:59 PM, Marine Kelley wrote: >> >>> I have observed this behavior with the rev 14120 of viewer-development : >>> >>> https://jira.secondlife.com/browse/VWR-24361 (name checked this time) >>> >>> In short, when you press a movement key or use the move panel (going >>> forward, backward etc, but not turning left or right), the FPS >>> decrease dramatically (from 90 down to 15 FPS). It can be very >>> annoying during races or fights. >>> >>> Has anybody observed this too ? I don't remember having seen this >>> happen in older viewers, but I recently changed my video card so maybe >>> the change in FPS was not noticeable to me before. >>> >>> And more importantly, has any work been done recently (less than two >>> months ago) on the way the avatar movement is handled, that could >>> trigger this bug ? I don't really know where to look so if anybody has >>> pointers, please feel free to share ! >>> >>> Thanks, >>> Marine >>> _______________________________________________ >>> Policies 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 > -- Opensource Obscure Twitter?[EN] -?Twitter?[IT] -?Blog?[IT] -?YouTube?-?Photos?-?Second Life From leliel.mirihi at gmail.com Mon Jan 3 04:02:19 2011 From: leliel.mirihi at gmail.com (leliel) Date: Mon, 3 Jan 2011 04:02:19 -0800 Subject: [opensource-dev] A weird bug when moving the avatar In-Reply-To: References: <72A6811A-550E-4C41-A8EF-B0F0837A7940@gmail.com> Message-ID: On Mon, Jan 3, 2011 at 3:06 AM, Opensource Obscure wrote: > I saw something similar with recent development viewer builds on Linux. > > It makes the viewer unusable to me (it actually freezes for a few seconds > here, not just slow down). That sounds more like STORM-809. From laurent.bechir at madonie.org Mon Jan 3 10:05:45 2011 From: laurent.bechir at madonie.org (Laurent Bechir) Date: Mon, 03 Jan 2011 19:05:45 +0100 Subject: [opensource-dev] Exclude Home from teleport history In-Reply-To: <4D21620D.2050805@taterunino.net> References: <4D20D131.9080001@madonie.org> <4D212071.1050602@madonie.org> <4D21620D.2050805@taterunino.net> Message-ID: <4D220FF9.4080708@madonie.org> Tateru Nino a ?crit : > I've had it happen to me before also. There's a couple things that can > silently reset your home location. For a while, some people were > triggering it intentionally as a way of evading parcel ejection and so > on - sure the owner can try to send you home, but if your home is where > you are, nothing happens. > > At least one of the methods (which can happen unintentionally) was > repeatedly reported as a security exploit back in 2006 - but AFAIK, it's > still unfixed. Perhaps what could be done is to put it as an optionnal setting (a check box to enable/disable for example) in the settings panel ? Like this everyine would have it the way he likes. I'm asking that because I often come and go from my home parcel so the history is quickly filled with a lot of landmark to it. From angel_of_crimson at hotmail.com Mon Jan 3 10:28:48 2011 From: angel_of_crimson at hotmail.com (Erin Mallory) Date: Mon, 3 Jan 2011 13:28:48 -0500 Subject: [opensource-dev] Exclude Home from teleport history In-Reply-To: <4D220FF9.4080708@madonie.org> References: <4D20D131.9080001@madonie.org> <4D212071.1050602@madonie.org>, <4D21620D.2050805@taterunino.net>, <4D220FF9.4080708@madonie.org> Message-ID: What if instead we made it so that each parcel could only show up in the history once unless an explicitly different landmark was used? I think that might have a more decluttering affect then just leaving the home point out. especially if like me you have multiple properties you own, and/or many places you might be called to sometimes multiple times a day... > Date: Mon, 3 Jan 2011 19:05:45 +0100 > From: laurent.bechir at madonie.org > To: opensource-dev at lists.secondlife.com > Subject: Re: [opensource-dev] Exclude Home from teleport history > > > > Tateru Nino a ?crit : > > I've had it happen to me before also. There's a couple things that can > > silently reset your home location. For a while, some people were > > triggering it intentionally as a way of evading parcel ejection and so > > on - sure the owner can try to send you home, but if your home is where > > you are, nothing happens. > > > > At least one of the methods (which can happen unintentionally) was > > repeatedly reported as a security exploit back in 2006 - but AFAIK, it's > > still unfixed. > > Perhaps what could be done is to put it as an optionnal setting (a check > box to enable/disable for example) in the settings panel ? Like this > everyine would have it the way he likes. I'm asking that because I often > come and go from my home parcel so the history is quickly filled with a > lot of landmark to 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/20110103/deb6ab0f/attachment.htm From merov at lindenlab.com Mon Jan 3 15:22:02 2011 From: merov at lindenlab.com (Philippe (Merov) Bossut) Date: Mon, 3 Jan 2011 15:22:02 -0800 Subject: [opensource-dev] saved logins In-Reply-To: <201012292346.17127.Lance.Corrimal@eregion.de> References: <4D1B9678.3050205@lindenlab.com> <201012292346.17127.Lance.Corrimal@eregion.de> Message-ID: Hi, On Wed, Dec 29, 2010 at 2:46 PM, Lance Corrimal wrote: > Am Mittwoch, 29. Dezember 2010 schrieb Aleric Inglewood: > > https://jira.secondlife.com/browse/SNOW-129 > > > > > that is one of the main things that are holding me back from going > live with dolphin viewer 2.x, the missing saved logins dropdown... > That was proposed as a port to Snowstorm: https://jira.secondlife.com/browse/SNOW-670 IIRC, OpenSim users didn't like some of the aspects of that implementation. An alternative proposal fixing those issues would be welcome. Cheers, - Merov -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110103/9bd104f4/attachment.htm From merov at lindenlab.com Mon Jan 3 15:24:53 2011 From: merov at lindenlab.com (Merov Linden) Date: Mon, 03 Jan 2011 23:24:53 -0000 Subject: [opensource-dev] Review Request: VWR-24347 Reversion in Copy3rdPartyLibs.cmake -- cannot find msvc* files using VS 2005 Express In-Reply-To: <20101229234218.20369.35141@domU-12-31-38-00-90-68.compute-1.internal> References: <20101229234218.20369.35141@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110103232453.9850.64015@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/68/#review108 ----------------------------------------------------------- Could you identify in the log history of the file when that "at some point" happened? There might be a reason for it though I can't imagine one off the top of my head. - Merov On Dec. 29, 2010, 3:42 p.m., Jonathan Yap wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/68/ > ----------------------------------------------------------- > > (Updated Dec. 29, 2010, 3:42 p.m.) > > > Review request for Viewer. > > > Summary > ------- > > Environment: Windows, VS 2005 Express > > Back in the days of v2.1 I was able to supply the following option to develop.py, which would allow me to specify the location of > msvcr80.dll > msvcp80.dll > Microsoft.VC80.CRT.manifest > > -DMSVC_REDIST_PATH:PATH=E:/some/path > > There was a similar code path for the debug files > -DMSVC_DEBUG_REDIST_PATH=E:/some/path > > This files cannot be found by the Express compiler so without a way of telling the compiler where to find them they have to be dropped into the build tree manually. > > At some point Copy3rdPartyLibs.cmake was rewritten and this option was dropped. > > > This addresses bug vwr-24347. > http://jira.secondlife.com/browse/vwr-24347 > > > Diffs > ----- > > indra/cmake/Copy3rdPartyLibs.cmake 27dae7b01a81 > > Diff: http://codereview.secondlife.com/r/68/diff > > > Testing > ------- > > I tried using -DMSVC_REDIST_PATH:PATH=E:/some/path with my VS 2005 Express compiler and obtained the desired result. > > I don't have the debug files to test -DMSVC_DEBUG_REDIST_PATH=E:/some/path > > > Thanks, > > Jonathan > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110103/096f6747/attachment.htm From merov at lindenlab.com Mon Jan 3 15:43:46 2011 From: merov at lindenlab.com (Philippe (Merov) Bossut) Date: Mon, 3 Jan 2011 15:43:46 -0800 Subject: [opensource-dev] saving textures In-Reply-To: <4D1CD64F.8060209@lindenlab.com> References: <4D1BCD60.6050906@meadowlakearts.com> <4D1C9718.8030906@lindenlab.com> <4D1CAE66.5010302@meadowlakearts.com> <2ABD9497-4B71-4ECA-B229-7FD02D810C06@gmail.com> <4D1CD64F.8060209@lindenlab.com> Message-ID: Hi, I can easily repro on Mac. As said before in the thread, it's likely a consequence of my KDU changes. I haven't checked that code path. My bad :( I moved the record to Snowstorm and it's now: STORM-828 Cheers, - Merov -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110103/bb3736db/attachment.htm From trilobyte550m at gmail.com Mon Jan 3 15:58:02 2011 From: trilobyte550m at gmail.com (Trilo Byte) Date: Mon, 3 Jan 2011 15:58:02 -0800 Subject: [opensource-dev] [HELP] Please update 'featuretable' files in code repository Message-ID: <024163D3-F2BD-4E07-80C6-D4575324B1CB@gmail.com> Could someone please update the featuretable.txt and featuretable_mac.txt (and presumably the featuretable_linux.txt. On the code repository, at: http://hg.secondlife.com/viewer-development/src/b0bd26c5638a/indra/newview/ As Q mentioned in a post some time ago, what the viewer is using and accessing is coming from LL's servers at login, and is apparently a much more recent version than what's on the code repository (repository shows version 25 for featuretable.txt, and version 22 for mac and linux versions). Looking through the secondlife.log file it appears to get the featuretable file from http://viewer-settings.secondlife.com/..., however it doesn't store an updated copy locally and I'm not able to access it myself. Thanks TriloByte Zanzibar From angel_of_crimson at hotmail.com Mon Jan 3 19:52:28 2011 From: angel_of_crimson at hotmail.com (Erin Mallory) Date: Mon, 3 Jan 2011 22:52:28 -0500 Subject: [opensource-dev] build 218026 silently failing Message-ID: build 218026 seems to just continuously silently fail. it doesn;t seem to trigger any particular error and i cannot figure out what is triggering it, other then possibly a memory leak. It just is there one moment and gone the next, leaving behind two instances of SLplugin. for a breif moment when this happens the secondlifedevelopement.exe file is still in the list usually taking up INSANE amounts of memory (more then 2 gig ram and 4 gig virtual), but only for a moment. it doesn't even trigger the crash logger. It does seem to happen most when i am in the middle of typing something into an im window but i can't consistently repo it enough to determine if that has something to do with it. I'm really frustrated and wondering if anyone else running this build or one from about the same timeframe is seeing this as well? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110103/0e86da86/attachment.htm From akanevsky at productengine.com Mon Jan 3 22:07:38 2011 From: akanevsky at productengine.com (Anya Kanevsky) Date: Tue, 4 Jan 2011 00:07:38 -0600 Subject: [opensource-dev] Very Strange occurrence... In-Reply-To: References: <78C5DABF-5934-49D0-9F9D-CB8C35F74178@gmail.com> <7E1308B5-D0EE-41D5-8CF2-A419D9A78462@gmail.com> Message-ID: Ponzu, I'm understandably very interested in finding out which xml files ... Thanks! Getting IMs from people telling me to lay off other people I don't know and have never talked to is getting kind of old. Thanks! a 2010/12/31 Ponzu > I just thought of looking in the xml files, and indeed "Grumpity > Productengine" shows up in a few of them, I assume as some sort of place > holder left by a programmer. > > Maybe such "magic words" should be replace by something like "Unkown > Resident" or some such. > > > On Fri, Dec 31, 2010 at 12:45 PM, Argent Stonecutter < > secret.argent at gmail.com> wrote: > >> > >> > There should be a few fallback strategies like: >> > a) Try to keep the old cache entry. >> > b) Use the normal user name. >> > c) Maybe even use the UUID. >> > >> > But just showing everyone (in the worst case) as ??? really screws >> > things up IMO. >> >> Agreed. The TPV I'm using seems to use the Legacy Name if the Display Name >> is not available. >> >> _______________________________________________ >> Policies 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/20110104/b0652af1/attachment.htm From vsavchuk at productengine.com Tue Jan 4 03:24:49 2011 From: vsavchuk at productengine.com (Vadim Savchuk) Date: Tue, 04 Jan 2011 13:24:49 +0200 Subject: [opensource-dev] Very Strange occurrence... In-Reply-To: References: <78C5DABF-5934-49D0-9F9D-CB8C35F74178@gmail.com> <7E1308B5-D0EE-41D5-8CF2-A419D9A78462@gmail.com> Message-ID: <4D230381.3090800@productengine.com> On 01/04/2011 08:07 AM, Anya Kanevsky wrote: > Ponzu, I'm understandably very interested in finding out which xml > files ... Thanks! inspect_avatar.xml: value="Grumpity ProductEngine with a long name" inspect_avatar.xml: value="Grumpity ProductEngine" inspect_group.xml: Grumpity's Grumpy Group of Moose panel_activeim_row.xml: Grumpity ProductEngine -- Vadim From sllists at boroon.dasgupta.ch Tue Jan 4 03:31:25 2011 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Tue, 04 Jan 2011 12:31:25 +0100 Subject: [opensource-dev] Very Strange occurrence... In-Reply-To: References: <78C5DABF-5934-49D0-9F9D-CB8C35F74178@gmail.com> <7E1308B5-D0EE-41D5-8CF2-A419D9A78462@gmail.com> Message-ID: <4D23050D.10206@boroon.dasgupta.ch> On 01/04/2011 07:07 AM, Anya Kanevsky wrote: > Ponzu, I'm understandably very interested in finding out which xml > files ... Thanks! > Getting IMs from people telling me to lay off other people I don't > know and have never talked to is getting kind of old. > [...] > > 2010/12/31 Ponzu > > > I just thought of looking in the xml files, and indeed "Grumpity > Productengine" shows up in a few of them, I assume as some sort of > place holder left by a programmer. > > Maybe such "magic words" should be replace by something like > "Unkown Resident" or some such. > *indra/newview/skins/default/xui/en/inspect_avatar.xml* 46: value="Grumpity ProductEngine with a long name" 57: value="Grumpity ProductEngine" *indra/newview/skins/default/xui/en/panel_activeim_row.xml* 79: Grumpity ProductEngine *indra/newview/skins/default/xui/en/inspect_group.xml* 34: Grumpity's Grumpy Group of Moose *indra/newview/skins/default/xui/fr/inspect_avatar.xml* 13: 14: *indra/newview/skins/default/xui/fr/panel_activeim_row.xml* 4: Grumpity ProductEngine *indra/newview/skins/default/xui/fr/inspect_group.xml* 20: Groupe grognon des Orignaux Grumpity *indra/newview/skins/default/xui/de/inspect_avatar.xml* 14: *indra/newview/skins/default/xui/de/panel_activeim_row.xml* 4: Grumpity ProductEngine *indra/newview/skins/default/xui/de/inspect_group.xml* 20: Grumpitys schlecht gelaunte Elche *indra/newview/skins/default/xui/es/inspect_avatar.xml* 13: *indra/newview/skins/default/xui/da/inspect_avatar.xml* 13: *indra/newview/skins/default/xui/pt/inspect_avatar.xml* 13: *indra/newview/skins/default/xui/ja/inspect_avatar.xml* 13: *indra/newview/skins/default/xui/ja/panel_activeim_row.xml* 4: Grumpity ProductEngine *indra/newview/skins/default/xui/ja/inspect_group.xml* 20: Grumpity's Grumpy Group of Moose *indra/newview/skins/default/xui/pl/inspect_avatar.xml* 13: Extracted from current viewer-development by ack --xml "Grumpity". Cheers, Boroondas -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110104/0b0ee8c9/attachment-0001.htm From wolfpup67 at earthlink.net Tue Jan 4 04:35:46 2011 From: wolfpup67 at earthlink.net (WolfPup Lowenhar) Date: Tue, 4 Jan 2011 07:35:46 -0500 Subject: [opensource-dev] Very Strange occurrence... In-Reply-To: <4D23050D.10206@boroon.dasgupta.ch> References: <78C5DABF-5934-49D0-9F9D-CB8C35F74178@gmail.com> <7E1308B5-D0EE-41D5-8CF2-A419D9A78462@gmail.com> <4D23050D.10206@boroon.dasgupta.ch> Message-ID: <000c01cbac0b$e97d1ea0$bc775be0$@net> I had seen those as well and just figured they were in there as a ?placed holder? so that when the translation team gets a hold of the viewer they have some large name there so that they know not to use that space. I have also seen different Lindens names there as well on other areas. From: opensource-dev-bounces at lists.secondlife.com [mailto:opensource-dev-bounces at lists.secondlife.com] On Behalf Of Boroondas Gupte Sent: Tuesday, January 04, 2011 6:31 AM To: Anya Kanevsky Cc: opensource-dev Subject: Re: [opensource-dev] Very Strange occurrence... On 01/04/2011 07:07 AM, Anya Kanevsky wrote: Ponzu, I'm understandably very interested in finding out which xml files ... Thanks! Getting IMs from people telling me to lay off other people I don't know and have never talked to is getting kind of old. [...] 2010/12/31 Ponzu I just thought of looking in the xml files, and indeed "Grumpity Productengine" shows up in a few of them, I assume as some sort of place holder left by a programmer. Maybe such "magic words" should be replace by something like "Unkown Resident" or some such. indra/newview/skins/default/xui/en/inspect_avatar.xml 46: value="Grumpity ProductEngine with a long name" 57: value="Grumpity ProductEngine" indra/newview/skins/default/xui/en/panel_activeim_row.xml 79: Grumpity ProductEngine indra/newview/skins/default/xui/en/inspect_group.xml 34: Grumpity's Grumpy Group of Moose indra/newview/skins/default/xui/fr/inspect_avatar.xml 13: 14: indra/newview/skins/default/xui/fr/panel_activeim_row.xml 4: Grumpity ProductEngine indra/newview/skins/default/xui/fr/inspect_group.xml 20: Groupe grognon des Orignaux Grumpity indra/newview/skins/default/xui/de/inspect_avatar.xml 14: indra/newview/skins/default/xui/de/panel_activeim_row.xml 4: Grumpity ProductEngine indra/newview/skins/default/xui/de/inspect_group.xml 20: Grumpitys schlecht gelaunte Elche indra/newview/skins/default/xui/es/inspect_avatar.xml 13: indra/newview/skins/default/xui/da/inspect_avatar.xml 13: indra/newview/skins/default/xui/pt/inspect_avatar.xml 13: indra/newview/skins/default/xui/ja/inspect_avatar.xml 13: indra/newview/skins/default/xui/ja/panel_activeim_row.xml 4: Grumpity ProductEngine indra/newview/skins/default/xui/ja/inspect_group.xml 20: Grumpity's Grumpy Group of Moose indra/newview/skins/default/xui/pl/inspect_avatar.xml 13: Extracted from current viewer-development by ack --xml "Grumpity". Cheers, Boroondas _____ No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1191 / Virus Database: 1435/3357 - Release Date: 01/03/11 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110104/caa74ed4/attachment.htm From satomi.ahn at gmail.com Tue Jan 4 06:32:45 2011 From: satomi.ahn at gmail.com (Satomi Ahn) Date: Tue, 4 Jan 2011 15:32:45 +0100 Subject: [opensource-dev] Inventory incremental search (VWR-23712) Message-ID: Hello and happy new year. I hate spamming this list, but there is an easy bug I'd like to see fixed in the viewer, and which seems to have been only taking dust in the JIRA for two entire months. This is about one of the bugs who contribute to the general feeling of sluggishness in Viewer 2, so I believe you should really consider inclusion in viewer-development ;-). Enough spoken, everything is there, patch included: https://jira.secondlife.com/browse/VWR-23712 -- Satomi Ahn From jhwelch at gmail.com Tue Jan 4 07:37:14 2011 From: jhwelch at gmail.com (Jonathan Welch) Date: Tue, 4 Jan 2011 10:37:14 -0500 Subject: [opensource-dev] Very Strange occurrence... In-Reply-To: <000c01cbac0b$e97d1ea0$bc775be0$@net> References: <78C5DABF-5934-49D0-9F9D-CB8C35F74178@gmail.com> <7E1308B5-D0EE-41D5-8CF2-A419D9A78462@gmail.com> <4D23050D.10206@boroon.dasgupta.ch> <000c01cbac0b$e97d1ea0$bc775be0$@net> Message-ID: This is actually a small symptom of a larger problem. The text in those xml files is supposed to be replaced by some valid string but that does not always happen. I've often hovered over some object which would show it was for sale for L$30,000 when it was not valued at that amount--a failure to substitute in the proper value. The real solution to this issue would be to fix the underlaying problem. > Ponzu, I'm understandably very interested in finding out which xml files ... > Thanks! From jhwelch at gmail.com Tue Jan 4 08:36:34 2011 From: jhwelch at gmail.com (Jonathan Yap) Date: Tue, 04 Jan 2011 16:36:34 -0000 Subject: [opensource-dev] Review Request: VWR-24100 Settings.xml: redundant entries and unnecessary tag In-Reply-To: <20101216160413.18774.96246@domU-12-31-38-00-90-68.compute-1.internal> References: <20101216160413.18774.96246@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110104163634.9850.94203@domU-12-31-38-00-90-68.compute-1.internal> > On Dec. 16, 2010, 8:04 a.m., Aleric Inglewood wrote: > > indra/newview/app_settings/settings.xml, line 1165 > > > > > > Considering the setting name (CacheLocationTopFolder), isn't the deleted Comment string better than the one you left in? Thus, Controls the top folder location of the the local disk cache, rather than Controls the location of the local disk cache. Diff is ok with me, I just wondered if you saw that it wasn't an exact duplicate. I adjusted the file per your observation. Apparently this setting was cloned from the one above it (CacheLocation) twice and the comment only updated in one of the copies. - Jonathan ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/18/#review32 ----------------------------------------------------------- On Dec. 23, 2010, 12:12 p.m., Jonathan Yap wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/18/ > ----------------------------------------------------------- > > (Updated Dec. 23, 2010, 12:12 p.m.) > > > Review request for Viewer. > > > Summary > ------- > > I wrote two programs that use settings.xml to produce this massive table: > http://wiki.secondlife.com/wiki/Debug_Settings > > While doing this I found 4 places with duplicate entries and 1 entry that is repeated 4 times. There is also a pair of unnecessary tags. > > Having these cleaned out would make running my program, and thus updating the wiki table, easier. > > I've erased all but the last entry for these redundant debug settings. > > > This addresses bug vwr-24100. > http://jira.secondlife.com/browse/vwr-24100 > > > Diffs > ----- > > indra/newview/app_settings/settings.xml 46a990f8296f > > Diff: http://codereview.secondlife.com/r/18/diff > > > Testing > ------- > > > Thanks, > > Jonathan > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110104/6bfc53a5/attachment.htm From esbee at lindenlab.com Tue Jan 4 08:47:37 2011 From: esbee at lindenlab.com (Sarah (Esbee) Kuehnle) Date: Tue, 4 Jan 2011 11:47:37 -0500 Subject: [opensource-dev] Snowstorm Sprint Planning Meeting Canceled Today Message-ID: Happy New Year! I've canceled the Snowstorm sprint planning meeting that was scheduled for this afternoon. I think it's best to push that to first thing next week which will give us all time to catch up on everything that's happened over the holidays. I'll get the team calendar updated with new times and dates shortly. --Esbee -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110104/f5ce781f/attachment-0001.htm From merov at lindenlab.com Tue Jan 4 10:01:04 2011 From: merov at lindenlab.com (Philippe (Merov) Bossut) Date: Tue, 4 Jan 2011 10:01:04 -0800 Subject: [opensource-dev] build 218026 silently failing In-Reply-To: References: Message-ID: Hi, On Mon, Jan 3, 2011 at 7:52 PM, Erin Mallory wrote: > build 218026 seems to just continuously silently fail. it doesn;t seem to > trigger any particular error and i cannot figure out what is triggering it, > other then possibly a memory leak. > It just is there one moment and gone the next, leaving behind two instances > of SLplugin. for a breif moment when this happens the > secondlifedevelopement.exe file is still in the list usually taking up > INSANE amounts of memory (more then 2 gig ram and 4 gig virtual), but only > for a moment. it doesn't even trigger the crash logger. > It does seem to happen most when i am in the middle of typing something > into an im window but i can't consistently repo it enough to determine if > that has something to do with it. I'm really frustrated and wondering if > anyone else running this build or one from about the same timeframe is > seeing this as well? > Hmmm... This is concerning. I suppose you're using the Windows build though, to avoid ambiguities, please mention the operating system you're using in your future reports. I certainly don't repro on Mac but I don't follow a very typical use pattern. Anyone else seeing this issue? On which platform? Thanks for the report Erin. Cheers, - Merov -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110104/fb0fe56d/attachment.htm From merov at lindenlab.com Tue Jan 4 10:09:47 2011 From: merov at lindenlab.com (Philippe (Merov) Bossut) Date: Tue, 4 Jan 2011 10:09:47 -0800 Subject: [opensource-dev] Inventory incremental search (VWR-23712) In-Reply-To: References: Message-ID: Hi, This seems spot on. Thanks Satomi. On Tue, Jan 4, 2011 at 6:32 AM, Satomi Ahn wrote: > > Enough spoken, everything is there, patch included: > https://jira.secondlife.com/browse/VWR-23712 Bug report + patch = much much love from Snowstorms maintainers :) Cheers, - Merov -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110104/a90768b0/attachment.htm From akanevsky at productengine.com Tue Jan 4 11:13:47 2011 From: akanevsky at productengine.com (Anya Kanevsky) Date: Tue, 4 Jan 2011 13:13:47 -0600 Subject: [opensource-dev] Scrum Cancelled Message-ID: Due to griefing in hippotropolis, we're canceling the meeting today. Please email me with your updates and I will send out a summary shortly. Apologies for the unpleasant experience, all. anya -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110104/31596eeb/attachment.htm From sldev at free.fr Tue Jan 4 11:35:33 2011 From: sldev at free.fr (Henri Beauchamp) Date: Tue, 4 Jan 2011 20:35:33 +0100 Subject: [opensource-dev] saved logins In-Reply-To: References: <4D1B9678.3050205@lindenlab.com> <201012292346.17127.Lance.Corrimal@eregion.de> Message-ID: <20110104203533.001f0b8e.sldev@free.fr> On Mon, 3 Jan 2011 15:22:02 -0800, Philippe (Merov) Bossut wrote: > Hi, > > On Wed, Dec 29, 2010 at 2:46 PM, Lance Corrimal > wrote: > > > Am Mittwoch, 29. Dezember 2010 schrieb Aleric Inglewood: > > > https://jira.secondlife.com/browse/SNOW-129 > > > > that is one of the main things that are holding me back from going > > live with dolphin viewer 2.x, the missing saved logins dropdown... > > That was proposed as a port to Snowstorm: > https://jira.secondlife.com/browse/SNOW-670 > > IIRC, OpenSim users didn't like some of the aspects of that implementation. > An alternative proposal fixing those issues would be welcome. The problem with Snowglobe's implementation is that it saves the login info using the grid index number in the grids list, number which changes for OpenSim grids as soon as you change the grids list, resulting in messed up saved login info. I fixed this issue in the Cool VL Viewer v1.25 (which is based off Snowglobe v1.5), simply by using the grid name instead of the grid index number... This fix is part of the patch (for SG 1.5) available here: http://sldev.free.fr/patches/12500/slviewer-0-v12500-MoreGridsDynamic_v7.patch.bz2 Henri. From slitovchuk at productengine.com Tue Jan 4 12:38:05 2011 From: slitovchuk at productengine.com (Seth ProductEngine) Date: Tue, 04 Jan 2011 20:38:05 -0000 Subject: [opensource-dev] Review Request: (STORM-550) LLDir::getNextFileInDir fails for some complex wildcard combinations In-Reply-To: <20101220214720.4669.56543@domU-12-31-38-00-90-68.compute-1.internal> References: <20101220214720.4669.56543@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110104203805.6675.57656@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/32/ ----------------------------------------------------------- (Updated Jan. 4, 2011, 12:38 p.m.) Review request for Viewer. Changes ------- - Added a boost::regex member variable not to translate the mask to a regex on every call to next(). - Moved iterator initialization and exceptions handling to the constructor. Summary ------- Fixed LLDir unit test which failed for some complex wildcard combinations. Added a class implementing directory entries iteration with pattern matching which is used in unit tests instead of LLDir::getNextFileInDir. This code has been run on Linux only. It should be tested under other platforms and more test cases should be provided. For example changing directory contents while iterating through it. This addresses bug STORM-550. http://jira.secondlife.com/browse/STORM-550 Diffs (updated) ----- indra/cmake/Boost.cmake 27dae7b01a81 indra/llvfs/CMakeLists.txt 27dae7b01a81 indra/llvfs/lldiriterator.h PRE-CREATION indra/llvfs/lldiriterator.cpp PRE-CREATION indra/llvfs/tests/lldir_test.cpp 27dae7b01a81 Diff: http://codereview.secondlife.com/r/32/diff Testing ------- Thanks, Seth -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110104/60a7d3d1/attachment.htm From slitovchuk at productengine.com Tue Jan 4 12:38:30 2011 From: slitovchuk at productengine.com (Seth ProductEngine) Date: Tue, 04 Jan 2011 20:38:30 -0000 Subject: [opensource-dev] Review Request: (STORM-550) LLDir::getNextFileInDir fails for some complex wildcard combinations In-Reply-To: <20101223152136.7885.63565@domU-12-31-38-00-90-68.compute-1.internal> References: <20101223152136.7885.63565@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110104203830.9850.51912@domU-12-31-38-00-90-68.compute-1.internal> > On Dec. 23, 2010, 7:21 a.m., Oz Linden wrote: > > indra/llvfs/lldiriterator.cpp, lines 152-155 > > > > > > This method of tracking escapes and brackets isn't quite correct, I think... consider translating a string input containing an escaped backslash or an escaped bracket. > > Escaping characters like backslash or a square bracket seems to work as expected. For example the pattern "file\\\\[0-9].abc" used as a mask argument for iterator constructor will match files: "file\1.abc", "file\2.abc", etc. The bracket can be escaped by a preceding double backslash "\\[". > On Dec. 23, 2010, 7:21 a.m., Oz Linden wrote: > > indra/llvfs/lldiriterator.cpp, line 99 > > > > > > There should be a unit test for this translation. All unit tests for directory iterator depend on the result of this translation. Looks like most common cases are covered. Does it need some additional test cases? what kind of cases should be added? > On Dec. 23, 2010, 7:21 a.m., Oz Linden wrote: > > indra/llvfs/lldiriterator.cpp, lines 67-80 > > > > > > It would be better to make the boost::regex a member variable - rather than translate the mask to a regex on every call to next, translate it once in the constructor. Updated in diff r3. > On Dec. 23, 2010, 7:21 a.m., Oz Linden wrote: > > indra/llvfs/lldiriterator.h, lines 55-56 > > > > > > Why not use '^' for the negation qualifier here? It's more familiar (at least to unix users) '!' is defined in pattern matching rules on glob(7) man page, but it could be easily replaced with '^' if it is needed. - Seth ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/32/#review80 ----------------------------------------------------------- On Jan. 4, 2011, 12:38 p.m., Seth ProductEngine wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/32/ > ----------------------------------------------------------- > > (Updated Jan. 4, 2011, 12:38 p.m.) > > > Review request for Viewer. > > > Summary > ------- > > Fixed LLDir unit test which failed for some complex wildcard combinations. > Added a class implementing directory entries iteration with pattern matching which is used in unit tests instead of LLDir::getNextFileInDir. > > This code has been run on Linux only. It should be tested under other platforms and more test cases should be provided. For example changing directory contents while iterating through it. > > > This addresses bug STORM-550. > http://jira.secondlife.com/browse/STORM-550 > > > Diffs > ----- > > indra/cmake/Boost.cmake 27dae7b01a81 > indra/llvfs/CMakeLists.txt 27dae7b01a81 > indra/llvfs/lldiriterator.h PRE-CREATION > indra/llvfs/lldiriterator.cpp PRE-CREATION > indra/llvfs/tests/lldir_test.cpp 27dae7b01a81 > > Diff: http://codereview.secondlife.com/r/32/diff > > > Testing > ------- > > > Thanks, > > Seth > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110104/aca4127c/attachment-0001.htm From akanevsky at productengine.com Tue Jan 4 13:05:41 2011 From: akanevsky at productengine.com (Anya Kanevsky) Date: Tue, 4 Jan 2011 15:05:41 -0600 Subject: [opensource-dev] Daily Scrum Summary - Tuesday, January 4, 2011 Message-ID: Tuesday, January 4, 2011 General Notes ------------------------------ - Happy New Year! - Standup was cancelled today - MMOTD: Oz Team Status ------------------------------ Merov Linden ------------------------------ *PAST* - STORM-825 : Reenable the LLMatrix3::orthogonalize test in llmath/tests/m3math_test.cpp : Tested on TC all platforms. Pass. Good to go IMO. - STORM-744 : Add unit tests to llkdu: Fixed code so that test passes in all circumstances (debug, release) on all platforms. Resubmitted to RB. Merged by Oz over the holidays. - STORM-828 : Texture Saving Does Not Work : Was able to repro that bug reported by Trilo. Likely my fault. Need to fix. - STORM-823 : Tab Key not working properly : Checked that fix (<3 @Vadim for it), moved it to Integration. *FUTURE* - STORM-828 : Texture Saving Does Not Work - STORM-745 : Produce comprehensive perf baseline: Complete that work. *IMPEDIMENTS* - None Oz Linden ------------------------------ *PAST* - Tracking down viewer dependencies with sources, etc - Wiki updates - Merge Monkeying - Office Hours *FUTURE* - Merge Monkey - Review autobuild documentation - More wiki updates... *IMPEDIMENTS* - none Q Linden ------------------------------ *PAST* - Vacation - Recover from vacation backlog - Long meeting this morning *FUTURE* - STORM-2 - More emails & Meetings *IMPEDIMENTS* - None Esbee Linden ------------------------------ *PAST* - Holiday - Review integration queue - Rejected STORM-797 and STORM-410 - does not pass stated acceptance criteria. - Rejected STORM-28 - It doesn't seem like the implementation has met the user story criteria at all. I can share calling cards, but how I do give my calling card to a Resident I meet? - Rejected STORM-702 - I'd like to see a test plan so I can properly review this fix and make sure we've really made it possible to wear a partial outfit. - Approved STORM-493, STORM-513, STORM-466, STORM-737, STORM-485, STORM-467, STORM-398, STORM-714, STORM-812 *FUTURE* - Get caught up - Reschedule upcoming Snowstorm team meetings - Review product owner and integration queues (STORM-34, -806, -438) *IMPEDIMENTS* - None Paul ProductEngine ------------------------------ - OOO - vacation Seth Productengine ------------------------------ *PAST* - TASK (STORM-797) Parcel SLURL rendering - Fixed - TASK (STORM-28) As a User, I want the ability to send my calling card to others - Fixed - BUG (STORM-550) LLDir::getNextFileInDir fails for some complex wildcard combinations - Changes according to feedback from Oz *FUTURE* - STORM-550 - STORM-447 (User is not able to share multi selected objects using drag&drop) *IMPEDIMENTS* - None. Andrew Productengine ------------------------------ *PAST* - Reviewed Sergey's fixes for a couple of issues, built and tested on Windows. - Major bug STORM-823 (Tab Key not working properly). - Fixed and put on review. - Normal task STORM-2 (Customizable viewer layouts). - Working on found problems. Continued Investigation of bug with loading undocked sidetray tabs. Discussed with Sergey and Vadim. There is some progress at last, but problem seems to be not in my fix, and is located quite deep. *FUTURE* - Normal task STORM-2 (Customizable viewer layouts). - Estimate for current version of feature - 2 days. *IMPEDIMENTS* - STORM-2. Waiting for Q's reply to letter about organization of layout saving. - STORM-2. Waiting for Esbee's answers to comments about layout design in STORM-753. - STORM-823. The issue is fixed, but in a way that may be not principally correct in future, so it would be good if Richard could say what he thinks about it. - Happy New Year! Vadim Productengine ------------------------------ *PAST* - Investigating bug STORM-226 (Viewer 2 Floating Text aligns improperly). - Not assigning the ticket to myself because I'm not yet sure I can fix it (to not disturb ~200 voters and ~50 watchers). *FUTURE* - Continue with STORM-226. *IMPEDIMENTS* - Need a decision in STORM-702 (Make it possible to wear partial outfits). - What to do with VWR tickets assigned to ProductEngine Team? https://jira.secondlife.com/secure/IssueNavigator.jspa?mode=hide&requestId=13071 Andrey Productengine ------------------------------ *PAST* - tiding my emails up after vacation - integrated tickets verification against the latest v-d build - test plans design: URLs, Sharing Inventory Items - started review of Sidebar TP *FUTURE* - finish with Sidebar TP *IMPEDIMENTS* - None. Jonathan Yap ------------------------------ *PAST* - VWR-18435 Up arrow icon on nearby chat/speak buttons - Researched. If this is taken in I will work on it. - VWR-24357 "Less" is not displayed after clicking on the "More" button in Nearby Media - Fixed. Can this be brought into STORM? *FUTURE* *IMPEDIMENTS* - None. Wolfpup Lowenhar ------------------------------ *PAST* - Worked @ RL and in world. - STORM-825 : Created online and local Repository for change set with the line in question deleted. - This just needs to be Integrated and QAed as this is a fix for during the build and testing process and not actually affecting the viewer code itself. - VWR-24256 : Watching this issue for comments.( i have an idea as to where the the fix would need to go but need to talk to Leyla to make sure, if it does get brought in.) *FUTURE* - Work @ RL and in world. - continue to monitor VWR-24256 . - Check Bug Queue : viewer-development some more. *IMPEDIMENTS* - Not enough time between working in-world and at real job to actually work on code. - Right Hand(it is slowly healing but will take time since it is the tip of middle finger.) - Trying to Figure out what to work on and still waiting on answer for STORM-236. Personal note: If I find those griefers they going to wish they had not done that as now I may have to end up re doing my computer. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110104/32a83687/attachment-0001.htm From angel_of_crimson at hotmail.com Tue Jan 4 15:40:30 2011 From: angel_of_crimson at hotmail.com (Erin Mallory) Date: Tue, 4 Jan 2011 18:40:30 -0500 Subject: [opensource-dev] about texture saving issues Message-ID: is the issue with saving textures only on macs? I'm not getting it on any windows build ive tried recently.. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110104/19ca16df/attachment.htm From merov at lindenlab.com Tue Jan 4 16:14:22 2011 From: merov at lindenlab.com (Merov Linden) Date: Wed, 05 Jan 2011 00:14:22 -0000 Subject: [opensource-dev] Review Request: VWR-24347 Reversion in Copy3rdPartyLibs.cmake -- cannot find msvc* files using VS 2005 Express In-Reply-To: <20101229234218.20369.35141@domU-12-31-38-00-90-68.compute-1.internal> References: <20101229234218.20369.35141@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110105001422.6679.8138@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/68/#review111 ----------------------------------------------------------- Those lines have been missing since a long time: the first version in hg is already missing them: https://bitbucket.org/lindenlab/viewer-development/changeset/07304583316d - Merov On Dec. 29, 2010, 3:42 p.m., Jonathan Yap wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/68/ > ----------------------------------------------------------- > > (Updated Dec. 29, 2010, 3:42 p.m.) > > > Review request for Viewer. > > > Summary > ------- > > Environment: Windows, VS 2005 Express > > Back in the days of v2.1 I was able to supply the following option to develop.py, which would allow me to specify the location of > msvcr80.dll > msvcp80.dll > Microsoft.VC80.CRT.manifest > > -DMSVC_REDIST_PATH:PATH=E:/some/path > > There was a similar code path for the debug files > -DMSVC_DEBUG_REDIST_PATH=E:/some/path > > This files cannot be found by the Express compiler so without a way of telling the compiler where to find them they have to be dropped into the build tree manually. > > At some point Copy3rdPartyLibs.cmake was rewritten and this option was dropped. > > > This addresses bug vwr-24347. > http://jira.secondlife.com/browse/vwr-24347 > > > Diffs > ----- > > indra/cmake/Copy3rdPartyLibs.cmake 27dae7b01a81 > > Diff: http://codereview.secondlife.com/r/68/diff > > > Testing > ------- > > I tried using -DMSVC_REDIST_PATH:PATH=E:/some/path with my VS 2005 Express compiler and obtained the desired result. > > I don't have the debug files to test -DMSVC_DEBUG_REDIST_PATH=E:/some/path > > > Thanks, > > Jonathan > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110105/cd7c331a/attachment.htm From carlo at alinoe.com Tue Jan 4 16:44:15 2011 From: carlo at alinoe.com (Carlo Wood) Date: Wed, 5 Jan 2011 01:44:15 +0100 Subject: [opensource-dev] Inventory incremental search (VWR-23712) In-Reply-To: References: Message-ID: <20110105004415.GA26491@alinoe.com> One reason that it's collecting dust might be that it isn't know if the author of the patch signed the Contribution Argeement. On Tue, Jan 04, 2011 at 03:32:45PM +0100, Satomi Ahn wrote: > Hello and happy new year. > > I hate spamming this list, but there is an easy bug I'd like to see > fixed in the viewer, and which seems to have been only taking dust in > the JIRA for two entire months. > > This is about one of the bugs who contribute to the general feeling of > sluggishness in Viewer 2, so I believe you should really consider > inclusion in viewer-development ;-). > > Enough spoken, everything is there, patch included: > https://jira.secondlife.com/browse/VWR-23712 > > -- > Satomi Ahn > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting privileges -- Carlo Wood From Lance.Corrimal at eregion.de Wed Jan 5 03:13:08 2011 From: Lance.Corrimal at eregion.de (Lance Corrimal) Date: Wed, 5 Jan 2011 12:13:08 +0100 Subject: [opensource-dev] Inventory incremental search (VWR-23712) In-Reply-To: <20110105004415.GA26491@alinoe.com> References: <20110105004415.GA26491@alinoe.com> Message-ID: <201101051213.09061.Lance.Corrimal@eregion.de> Am Mittwoch, 5. Januar 2011, 01:44:15 schrieb Carlo Wood: > One reason that it's collecting dust might be that it isn't know > if the author of the patch signed the Contribution Argeement. > > On Tue, Jan 04, 2011 at 03:32:45PM +0100, Satomi Ahn wrote: > > Hello and happy new year. > > > > I hate spamming this list, but there is an easy bug I'd like to see > > fixed in the viewer, and which seems to have been only taking dust in > > the JIRA for two entire months. > > > > This is about one of the bugs who contribute to the general feeling of > > sluggishness in Viewer 2, so I believe you should really consider > > inclusion in viewer-development ;-). > > > > Enough spoken, everything is there, patch included: > > https://jira.secondlife.com/browse/VWR-23712 Isn't the acceptance of the contribution agreement automatically implied when you upload a patch to a jira? anyways, applied the patch to viewer-release, works just fine, dolphinviewer2 has it now. bye, LC From oz at lindenlab.com Wed Jan 5 04:24:14 2011 From: oz at lindenlab.com (Oz Linden (Scott Lawrence)) Date: Wed, 05 Jan 2011 07:24:14 -0500 Subject: [opensource-dev] Inventory incremental search (VWR-23712) In-Reply-To: <201101051213.09061.Lance.Corrimal@eregion.de> References: <20110105004415.GA26491@alinoe.com> <201101051213.09061.Lance.Corrimal@eregion.de> Message-ID: <4D2462EE.9000403@lindenlab.com> On 2011-01-05 6:13, Lance Corrimal wrote: > Isn't the acceptance of the contribution agreement automatically implied when > you upload a patch to a jira? Alas, no. Putting a patch on jira, this list, or the codereview site means that it falls under any agreement that you have executed, but actually executing the agreement must be explicit. From Lance.Corrimal at eregion.de Wed Jan 5 04:38:10 2011 From: Lance.Corrimal at eregion.de (Lance Corrimal) Date: Wed, 5 Jan 2011 13:38:10 +0100 Subject: [opensource-dev] Inventory incremental search (VWR-23712) In-Reply-To: <4D2462EE.9000403@lindenlab.com> References: <201101051213.09061.Lance.Corrimal@eregion.de> <4D2462EE.9000403@lindenlab.com> Message-ID: <201101051338.10394.Lance.Corrimal@eregion.de> Am Mittwoch, 5. Januar 2011, 13:24:14 schrieb Oz Linden (Scott Lawrence): > On 2011-01-05 6:13, Lance Corrimal wrote: > > Isn't the acceptance of the contribution agreement automatically implied > > when you upload a patch to a jira? > > Alas, no. Putting a patch on jira, this list, or the codereview site > means that it falls under any agreement that you have executed, but > actually executing the agreement must be explicit. hmmm there is a patch of mine that actually got officially merged into snowglobe 1.5... point me to that agreement, ok? From Lance.Corrimal at eregion.de Wed Jan 5 04:39:56 2011 From: Lance.Corrimal at eregion.de (Lance Corrimal) Date: Wed, 5 Jan 2011 13:39:56 +0100 Subject: [opensource-dev] Inventory incremental search (VWR-23712) In-Reply-To: <4D2462EE.9000403@lindenlab.com> References: <201101051213.09061.Lance.Corrimal@eregion.de> <4D2462EE.9000403@lindenlab.com> Message-ID: <201101051339.56536.Lance.Corrimal@eregion.de> Am Mittwoch, 5. Januar 2011, 13:24:14 schrieb Oz Linden (Scott Lawrence): > On 2011-01-05 6:13, Lance Corrimal wrote: > > Isn't the acceptance of the contribution agreement automatically implied > > when you upload a patch to a jira? > > Alas, no. Putting a patch on jira, this list, or the codereview site > means that it falls under any agreement that you have executed, but > actually executing the agreement must be explicit. from the jira: "All submissions to this site are governed by Second Life Project Contribution Agreement. By submitting patches and other information using this site, you acknowledge that you have read, understood, and agreed to those terms." I understood that as "if you post anything here you automatically state that you agreed to the contrib agreement"... which is kind of a rat trap clause since throughout their SL almost anyone posts "other information" on jira at some point... bye, LC From tateru at taterunino.net Wed Jan 5 04:44:05 2011 From: tateru at taterunino.net (Tateru Nino) Date: Wed, 05 Jan 2011 23:44:05 +1100 Subject: [opensource-dev] Inventory incremental search (VWR-23712) In-Reply-To: <201101051339.56536.Lance.Corrimal@eregion.de> References: <201101051213.09061.Lance.Corrimal@eregion.de> <4D2462EE.9000403@lindenlab.com> <201101051339.56536.Lance.Corrimal@eregion.de> Message-ID: <4D246795.3020905@taterunino.net> On 5/01/2011 11:39 PM, Lance Corrimal wrote: > Am Mittwoch, 5. Januar 2011, 13:24:14 schrieb Oz Linden (Scott Lawrence): >> On 2011-01-05 6:13, Lance Corrimal wrote: >>> Isn't the acceptance of the contribution agreement automatically implied >>> when you upload a patch to a jira? >> Alas, no. Putting a patch on jira, this list, or the codereview site >> means that it falls under any agreement that you have executed, but >> actually executing the agreement must be explicit. > from the jira: > > "All submissions to this site are governed by Second Life Project Contribution > Agreement. By submitting patches and other information using this site, you > acknowledge that you have read, understood, and agreed to those terms." > > I understood that as "if you post anything here you automatically state that > you agreed to the contrib agreement"... which is kind of a rat trap clause > since throughout their SL almost anyone posts "other information" on jira at > some point... I think the implication of it is that you're acknowledging that you've already submitted a contribution agreement. However, things have been a bit lax and I understand there's more than one patch that has made it into the viewer - since the contribution agreements started - without any actual agreement on file. Ideally, someone should cross-check all of the contributed patches against the agreements. Sounds like a good job for someone on the legal team. -- Tateru Nino http://dwellonit.taterunino.net/ From Lance.Corrimal at eregion.de Wed Jan 5 04:56:03 2011 From: Lance.Corrimal at eregion.de (Lance Corrimal) Date: Wed, 5 Jan 2011 13:56:03 +0100 Subject: [opensource-dev] Inventory incremental search (VWR-23712) In-Reply-To: <4D246795.3020905@taterunino.net> References: <201101051339.56536.Lance.Corrimal@eregion.de> <4D246795.3020905@taterunino.net> Message-ID: <201101051356.03191.Lance.Corrimal@eregion.de> Am Mittwoch, 5. Januar 2011, 13:44:05 schrieb Tateru Nino: > Ideally, someone should cross-check all of the contributed patches > against the agreements. Sounds like a good job for someone on the legal > team. what about someone from marketing, about time they did someone useful... :P From stickman at gmail.com Wed Jan 5 04:57:12 2011 From: stickman at gmail.com (Stickman) Date: Wed, 5 Jan 2011 04:57:12 -0800 Subject: [opensource-dev] Inventory incremental search (VWR-23712) In-Reply-To: <201101051356.03191.Lance.Corrimal@eregion.de> References: <201101051339.56536.Lance.Corrimal@eregion.de> <4D246795.3020905@taterunino.net> <201101051356.03191.Lance.Corrimal@eregion.de> Message-ID: > what about someone from marketing, about time they did someone useful... :P Just throw the task to support. I'm sure they're not busy with anything else. :D Stickman From tateru at taterunino.net Wed Jan 5 05:03:18 2011 From: tateru at taterunino.net (Tateru Nino) Date: Thu, 06 Jan 2011 00:03:18 +1100 Subject: [opensource-dev] Inventory incremental search (VWR-23712) In-Reply-To: References: <201101051339.56536.Lance.Corrimal@eregion.de> <4D246795.3020905@taterunino.net> <201101051356.03191.Lance.Corrimal@eregion.de> Message-ID: <4D246C16.8000007@taterunino.net> On 5/01/2011 11:57 PM, Stickman wrote: >> what about someone from marketing, about time they did someone useful... :P > Just throw the task to support. I'm sure they're not busy with anything else. :D > Come on folks :) Let's not take the opportunity to have a dig (though, yes, I agree it is tempting, but perhaps not appropriate to this list). I think it's important for everyone that *someone* sit down with those agreements and make an effort to find where the legal rights and provenances of the viewer code have been tainted. Who better than the folks who wrote the agreements up and who know just how serious that is? -- Tateru Nino http://dwellonit.taterunino.net/ From stickman at gmail.com Wed Jan 5 05:08:52 2011 From: stickman at gmail.com (Stickman) Date: Wed, 5 Jan 2011 05:08:52 -0800 Subject: [opensource-dev] Inventory incremental search (VWR-23712) In-Reply-To: <4D246C16.8000007@taterunino.net> References: <201101051339.56536.Lance.Corrimal@eregion.de> <4D246795.3020905@taterunino.net> <201101051356.03191.Lance.Corrimal@eregion.de> <4D246C16.8000007@taterunino.net> Message-ID: >> Just throw the task to support. I'm sure they're not busy with anything else. :D > I think it's important for everyone that *someone* sit down with those > agreements and make an effort to find where the legal rights and > provenances of the viewer code have been tainted. Who better than the > folks who wrote the agreements up and who know just how serious that is? Because I don't want to come off as too much of a jerk, I believe support is understaffed, not lazy. My statement was sarcasm regarding the fact they likely have way too much to do already. I agree, definitely something that needs a watchful eye over it. It would hurt productivity if someone were to sue LL because a line of code they submitted was used without the contribution agreement. Stickman From Lance.Corrimal at eregion.de Wed Jan 5 05:19:25 2011 From: Lance.Corrimal at eregion.de (Lance Corrimal) Date: Wed, 5 Jan 2011 14:19:25 +0100 Subject: [opensource-dev] Inventory incremental search (VWR-23712) In-Reply-To: References: <4D246C16.8000007@taterunino.net> Message-ID: <201101051419.25185.Lance.Corrimal@eregion.de> Am Mittwoch, 5. Januar 2011, 14:08:52 schrieb Stickman: > >> Just throw the task to support. I'm sure they're not busy with anything > >> else. :D > > > > I think it's important for everyone that *someone* sit down with those > > agreements and make an effort to find where the legal rights and > > provenances of the viewer code have been tainted. Who better than the > > folks who wrote the agreements up and who know just how serious that is? > > Because I don't want to come off as too much of a jerk, I believe > support is understaffed, not lazy. My statement was sarcasm regarding > the fact they likely have way too much to do already. not only understaffed. they are also undertrained. In most of the tickets that I had lately, the fact that it takes about three months to get a resp?onse points at seriously understaffed, and the responses themself (if any) point at "I don't have the foggiest what this second life thing is, and I don't want to know." > I agree, definitely something that needs a watchful eye over it. It > would hurt productivity if someone were to sue LL because a line of > code they submitted was used without the contribution agreement. true. bye, LC From oz at lindenlab.com Wed Jan 5 07:19:32 2011 From: oz at lindenlab.com (Oz Linden) Date: Wed, 05 Jan 2011 15:19:32 -0000 Subject: [opensource-dev] Review Request: STORM-826 (partial): fix line endings in files that use a mix of CRLF and LF Message-ID: <20110105151932.6673.16877@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/70/ ----------------------------------------------------------- Review request for Viewer. Summary ------- This is a simple change to correct existing line endings - I scanned all of viewer-development to identify files that had a mixture of CRLF and LF endings and converted them to just LF. What to do about preventing future such will be dealt with separately... This addresses bug storm-826. http://jira.secondlife.com/browse/storm-826 Diffs ----- indra/newview/llfloaterwebcontent.h 845cab866155 indra/newview/llimview.h 845cab866155 indra/newview/llimview.cpp 845cab866155 indra/newview/lllogchat.cpp 845cab866155 Diff: http://codereview.secondlife.com/r/70/diff Testing ------- Thanks, Oz -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110105/d7f1b419/attachment.htm From oz at lindenlab.com Wed Jan 5 08:33:27 2011 From: oz at lindenlab.com (Oz Linden) Date: Wed, 05 Jan 2011 16:33:27 -0000 Subject: [opensource-dev] Review Request: (STORM-550) LLDir::getNextFileInDir fails for some complex wildcard combinations In-Reply-To: <20110104203805.6675.57656@domU-12-31-38-00-90-68.compute-1.internal> References: <20110104203805.6675.57656@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110105163327.6678.82332@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/32/ ----------------------------------------------------------- (Updated Jan. 5, 2011, 8:33 a.m.) Review request for Viewer. Changes ------- modified to correct the issue pointer Summary ------- Fixed LLDir unit test which failed for some complex wildcard combinations. Added a class implementing directory entries iteration with pattern matching which is used in unit tests instead of LLDir::getNextFileInDir. This code has been run on Linux only. It should be tested under other platforms and more test cases should be provided. For example changing directory contents while iterating through it. This addresses bug STORM-477. http://jira.secondlife.com/browse/STORM-477 Diffs ----- indra/cmake/Boost.cmake 27dae7b01a81 indra/llvfs/CMakeLists.txt 27dae7b01a81 indra/llvfs/lldiriterator.h PRE-CREATION indra/llvfs/lldiriterator.cpp PRE-CREATION indra/llvfs/tests/lldir_test.cpp 27dae7b01a81 Diff: http://codereview.secondlife.com/r/32/diff Testing ------- Thanks, Seth -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110105/f3cb8cbe/attachment.htm From twisted_laws at hotmail.com Wed Jan 5 10:42:36 2011 From: twisted_laws at hotmail.com (Twisted Laws) Date: Wed, 5 Jan 2011 13:42:36 -0500 Subject: [opensource-dev] build 218026 silently failing In-Reply-To: References: , Message-ID: I may have seen this on around 4 occasions while in the sandboxes over the last month. I've always assumed it was a bad object and immediately logged back in and ran in the debugger but it didn't re-occur. Its just a poof and its gone with nothing useful in the log files. My builds are a daily pull from viewer-development and compiled daily but I have some changes of my own in the viewer so I've not reported it but have tried to track it down. (Figured it was some error of mine since I'm still trying to get used to all the changes in folder and panel views.) My environment is Microsoft Windows 7 64-bit (Build 7600), compiled with vc2005 express. From: merov at lindenlab.com Date: Tue, 4 Jan 2011 10:01:04 -0800 To: opensource-dev at lists.secondlife.com Subject: Re: [opensource-dev] build 218026 silently failing Hi, On Mon, Jan 3, 2011 at 7:52 PM, Erin Mallory wrote: build 218026 seems to just continuously silently fail. it doesn;t seem to trigger any particular error and i cannot figure out what is triggering it, other then possibly a memory leak. It just is there one moment and gone the next, leaving behind two instances of SLplugin. for a breif moment when this happens the secondlifedevelopement.exe file is still in the list usually taking up INSANE amounts of memory (more then 2 gig ram and 4 gig virtual), but only for a moment. it doesn't even trigger the crash logger. It does seem to happen most when i am in the middle of typing something into an im window but i can't consistently repo it enough to determine if that has something to do with it. I'm really frustrated and wondering if anyone else running this build or one from about the same timeframe is seeing this as well? Hmmm... This is concerning. I suppose you're using the Windows build though, to avoid ambiguities, please mention the operating system you're using in your future reports. I certainly don't repro on Mac but I don't follow a very typical use pattern. Anyone else seeing this issue? On which platform? Thanks for the report Erin. Cheers, - Merov _______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110105/7f7322c1/attachment-0001.htm From oz at lindenlab.com Wed Jan 5 11:34:29 2011 From: oz at lindenlab.com (Oz Linden) Date: Wed, 05 Jan 2011 19:34:29 -0000 Subject: [opensource-dev] Review Request: (STORM-550) LLDir::getNextFileInDir fails for some complex wildcard combinations In-Reply-To: <20110105163327.6678.82332@domU-12-31-38-00-90-68.compute-1.internal> References: <20110105163327.6678.82332@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110105193429.6678.68706@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/32/#review112 ----------------------------------------------------------- Just one policy question with this... This implementation uses llwarns for various errors in the glob expression. Given that I expect that the glob expression will normally (always?) be hard coded (I hope no one will accept a pattern as input from the user and pass it on unverified), should these use llerrs so that the error cannot be missed (it crashes)? Other than that, this looks good now. - Oz On Jan. 5, 2011, 8:33 a.m., Seth ProductEngine wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/32/ > ----------------------------------------------------------- > > (Updated Jan. 5, 2011, 8:33 a.m.) > > > Review request for Viewer. > > > Summary > ------- > > Fixed LLDir unit test which failed for some complex wildcard combinations. > Added a class implementing directory entries iteration with pattern matching which is used in unit tests instead of LLDir::getNextFileInDir. > > This code has been run on Linux only. It should be tested under other platforms and more test cases should be provided. For example changing directory contents while iterating through it. > > > This addresses bug STORM-477. > http://jira.secondlife.com/browse/STORM-477 > > > Diffs > ----- > > indra/cmake/Boost.cmake 27dae7b01a81 > indra/llvfs/CMakeLists.txt 27dae7b01a81 > indra/llvfs/lldiriterator.h PRE-CREATION > indra/llvfs/lldiriterator.cpp PRE-CREATION > indra/llvfs/tests/lldir_test.cpp 27dae7b01a81 > > Diff: http://codereview.secondlife.com/r/32/diff > > > Testing > ------- > > > Thanks, > > Seth > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110105/573c13cc/attachment.htm From angel_of_crimson at hotmail.com Wed Jan 5 11:43:40 2011 From: angel_of_crimson at hotmail.com (Erin Mallory) Date: Wed, 5 Jan 2011 14:43:40 -0500 Subject: [opensource-dev] build 218026 silently failing In-Reply-To: References: , , , Message-ID: I don't think its just you twisted. Ive seen this on 3 differant windows computers with the build i mentioned. From: twisted_laws at hotmail.com To: merov at lindenlab.com; opensource-dev at lists.secondlife.com Date: Wed, 5 Jan 2011 13:42:36 -0500 Subject: Re: [opensource-dev] build 218026 silently failing I may have seen this on around 4 occasions while in the sandboxes over the last month. I've always assumed it was a bad object and immediately logged back in and ran in the debugger but it didn't re-occur. Its just a poof and its gone with nothing useful in the log files. My builds are a daily pull from viewer-development and compiled daily but I have some changes of my own in the viewer so I've not reported it but have tried to track it down. (Figured it was some error of mine since I'm still trying to get used to all the changes in folder and panel views.) My environment is Microsoft Windows 7 64-bit (Build 7600), compiled with vc2005 express. From: merov at lindenlab.com Date: Tue, 4 Jan 2011 10:01:04 -0800 To: opensource-dev at lists.secondlife.com Subject: Re: [opensource-dev] build 218026 silently failing Hi, On Mon, Jan 3, 2011 at 7:52 PM, Erin Mallory wrote: build 218026 seems to just continuously silently fail. it doesn;t seem to trigger any particular error and i cannot figure out what is triggering it, other then possibly a memory leak. It just is there one moment and gone the next, leaving behind two instances of SLplugin. for a breif moment when this happens the secondlifedevelopement.exe file is still in the list usually taking up INSANE amounts of memory (more then 2 gig ram and 4 gig virtual), but only for a moment. it doesn't even trigger the crash logger. It does seem to happen most when i am in the middle of typing something into an im window but i can't consistently repo it enough to determine if that has something to do with it. I'm really frustrated and wondering if anyone else running this build or one from about the same timeframe is seeing this as well? Hmmm... This is concerning. I suppose you're using the Windows build though, to avoid ambiguities, please mention the operating system you're using in your future reports. I certainly don't repro on Mac but I don't follow a very typical use pattern. Anyone else seeing this issue? On which platform? Thanks for the report Erin. Cheers, - Merov _______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges _______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110105/3a2aa123/attachment.htm From akanevsky at productengine.com Wed Jan 5 11:54:54 2011 From: akanevsky at productengine.com (Anya Kanevsky) Date: Wed, 5 Jan 2011 13:54:54 -0600 Subject: [opensource-dev] Daily Scrum Update - Wednesday, January 5, 2011 Message-ID: Wednesday, January 5, 2011 General Notes ------------------------------ - Reminder to devs. If a ticket doesn't pass Review and is rejected, it will move back to the To Do column in GH, if you do more work or clarify questions, it should be moved back through In Progress and then to In Review. - MMOTD: Oz, because he's automating the hell out of it. Team Status ------------------------------ Merov Linden ------------------------------ *PAST* - STORM-828 : Texture Saving Does Not Work: Tested quite a bit, can't repro reliably but it seems to be independent of KDU. Rather something to do with texture loading in general that fail to complete. Could be a deeper problem than just saving textures. *FUTURE* - STORM-828 : Texture Saving Does Not Work: Continue to investigate and, hopefully, fix. - STORM-745 : Produce comprehensive perf baseline: Complete that work. *IMPEDIMENTS* - None Oz Linden ------------------------------ *PAST* - Merge Monkey - Review autobuild documentation - More wiki updates... *FUTURE* - Merge Monkey - Office Hour - Reviewing third party lib builds to be moved to bitbucket *IMPEDIMENTS* - none Q Linden ------------------------------ *PAST* - storm-34 - comments on / discussion about a bunch of jiras - started on storm-2 discussion but got pulled away - meetings *FUTURE* - storm-2 maybe - meetings - ooo *IMPEDIMENTS* - dr appt - meetings Esbee Linden ------------------------------ *PAST* - Reviewed integration queue - Rejected STORM-797 and STORM-410 - does not pass stated acceptance criteria. - Rejected STORM-28 - It doesn't seem like the implementation has met the user story criteria at all. I can share calling cards, but how I do give my calling card to a Resident I meet? - Rejected STORM-702 - I'd like to see a test plan so I can properly review this fix and make sure we've really made it possible to wear a partial outfit. - Rejected STORM-34. I still don't like that if you enable this feature for one user, it's enabled for all users. Q, Oz, and I had a discussion afterwards and have come up with an alternate approach. Q will add a comment. - Approved STORM-493, STORM-513, STORM-466, STORM-737, STORM-485, STORM-467, STORM-398, STORM-714, STORM-812, STORM-806, STORM-438 - Checked on status of Viewer app icons (XD-29). Added clarification for application types. - Rescheduled Sprint 9 wrap-up and Sprint 10 meetings. *FUTURE* - Meetings - Triage - Review Snowstorm Team product backlog and bug log - Work with Rhett on next steps for Viewer icons - PO reviews for open tickets - Talk to Q about Andrew's feedback on STORM-753 (Design for Viewer Saved Layouts) - Going through the list of VWRs assigned to PE (finally) - Plan update for system requirements - Look at VWR-18435 and VWR-24357 for Jonathan. - Provide update to STORM-236 for Wolfpup. - Find time on my calendar for 2 weekly 1:1s w/Gez. *IMPEDIMENTS* - STORM-702 needs to be moved back through to the Review process so we can do PO and code reviews. Paul ProductEngine ------------------------------ - OOO - vacation Seth Productengine ------------------------------ *PAST* - TASK (STORM-797) Parcel SLURL rendering - Fixed - TASK (STORM-28) As a User, I want the ability to send my calling card to others - Fixed - BUG (STORM-550) LLDir::getNextFileInDir fails for some complex wildcard combinations - Changes according to feedback from Oz *FUTURE* - STORM-550 - STORM-447 (User is not able to share multi selected objects using drag&drop) *IMPEDIMENTS* - None. Andrew Productengine ------------------------------ *PAST* - Reviewed Sergey's fixes for a couple of issues, built and tested on Windows. - Major bug STORM-823 (Tab Key not working properly). - Fixed and put on review. - Normal task STORM-2 (Customizable viewer layouts). - Working on found problems. Continued Investigation of bug with loading undocked sidetray tabs. Discussed with Sergey and Vadim. There is some progress at last, but problem seems to be not in my fix, and is located quite deep. *FUTURE* - Normal task STORM-2 (Customizable viewer layouts). - Estimate for current version of feature - 2 days. *IMPEDIMENTS* - STORM-2. Waiting for Q's reply to letter about organization of layout saving. - STORM-2. Waiting for Esbee's answers to comments about layout design in STORM-753. Vadim Productengine ------------------------------ *PAST* - Investigating bug STORM-226 (Viewer 2 Floating Text aligns improperly). - Not assigning the ticket to myself because I'm not yet sure I can fix it (to not disturb ~200 voters and ~50 watchers). *FUTURE* - Continue with STORM-226. *IMPEDIMENTS* - Need a decision in STORM-702 (Make it possible to wear partial outfits). - What to do with VWR tickets assigned to ProductEngine Team? https://jira.secondlife.com/secure/IssueNavigator.jspa?mode=hide&requestId=13071 Andrey Productengine ------------------------------ *PAST* - tiding my emails up after vacation - integrated tickets verification against the latest v-d build - test plans design: URLs, Sharing Inventory Items - started review of Sidebar TP *FUTURE* - finish with Sidebar TP *IMPEDIMENTS* - None. Jonathan Yap ------------------------------ *PAST* - STORM-829 (Viewer 2 does not parse /me in object Instant Messages) *FUTURE* - STORM - 829 - STORM-830 (Volume slider isn't properly remembered if set to zero) *IMPEDIMENTS* - Need someone to bring VWR-24357 ( "Less" is not displayed after clicking on the "More" button in Nearby Media) into STORM if they think fixing this is a good idea. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110105/751cc2d8/attachment-0001.htm From q at lindenlab.com Wed Jan 5 13:44:31 2011 From: q at lindenlab.com (Kent Quirk (Q Linden)) Date: Wed, 5 Jan 2011 16:44:31 -0500 Subject: [opensource-dev] Very Strange occurrence... In-Reply-To: References: <78C5DABF-5934-49D0-9F9D-CB8C35F74178@gmail.com> <7E1308B5-D0EE-41D5-8CF2-A419D9A78462@gmail.com> <4D23050D.10206@boroon.dasgupta.ch> <000c01cbac0b$e97d1ea0$bc775be0$@net> Message-ID: So the reason that semi-plausible strings are used for these things is that they're the only strings available when we use the test floater feature from the login screen. But we should probably try not to use real names. And yes, Jonathan, these should mostly never be visible. But sometimes things happen. Q On Jan 4, 2011, at 10:37 AM, Jonathan Welch wrote: > This is actually a small symptom of a larger problem. > > The text in those xml files is supposed to be replaced by some valid > string but that does not always happen. > > I've often hovered over some object which would show it was for sale > for L$30,000 when it was not valued at that amount--a failure to > substitute in the proper value. > > The real solution to this issue would be to fix the underlaying problem. > >> Ponzu, I'm understandably very interested in finding out which xml files ... >> Thanks! > _______________________________________________ > Policies 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 slitovchuk at productengine.com Wed Jan 5 14:00:13 2011 From: slitovchuk at productengine.com (Seth ProductEngine) Date: Wed, 05 Jan 2011 22:00:13 -0000 Subject: [opensource-dev] Review Request: (STORM-550) LLDir::getNextFileInDir fails for some complex wildcard combinations In-Reply-To: <20110105193429.6678.68706@domU-12-31-38-00-90-68.compute-1.internal> References: <20110105193429.6678.68706@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110105220013.27615.56464@domU-12-31-38-00-90-68.compute-1.internal> > On Jan. 5, 2011, 11:34 a.m., Oz Linden wrote: > > Just one policy question with this... > > > > This implementation uses llwarns for various errors in the glob expression. > > > > Given that I expect that the glob expression will normally (always?) be hard coded (I hope no one will accept a pattern as input from the user and pass it on unverified), should these use llerrs so that the error cannot be missed (it crashes)? > > > > Other than that, this looks good now. Not sure about the policy on llerrs but as far as I remember we were trying not to overuse it, using only for fatal errors. If someone eventually will accept a pattern as the user input this might cause unexpected crashes, so I thought warnings would be enough to trace the error while hard coding the patterns, though if llerrs will work better in this case warnings could be replaced. - Seth ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/32/#review112 ----------------------------------------------------------- On Jan. 5, 2011, 8:33 a.m., Seth ProductEngine wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/32/ > ----------------------------------------------------------- > > (Updated Jan. 5, 2011, 8:33 a.m.) > > > Review request for Viewer. > > > Summary > ------- > > Fixed LLDir unit test which failed for some complex wildcard combinations. > Added a class implementing directory entries iteration with pattern matching which is used in unit tests instead of LLDir::getNextFileInDir. > > This code has been run on Linux only. It should be tested under other platforms and more test cases should be provided. For example changing directory contents while iterating through it. > > > This addresses bug STORM-477. > http://jira.secondlife.com/browse/STORM-477 > > > Diffs > ----- > > indra/cmake/Boost.cmake 27dae7b01a81 > indra/llvfs/CMakeLists.txt 27dae7b01a81 > indra/llvfs/lldiriterator.h PRE-CREATION > indra/llvfs/lldiriterator.cpp PRE-CREATION > indra/llvfs/tests/lldir_test.cpp 27dae7b01a81 > > Diff: http://codereview.secondlife.com/r/32/diff > > > Testing > ------- > > > Thanks, > > Seth > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110105/79eb1125/attachment.htm From simon.quinnell at gmail.com Wed Jan 5 15:56:51 2011 From: simon.quinnell at gmail.com (Simon Quinnell) Date: Thu, 6 Jan 2011 10:56:51 +1100 Subject: [opensource-dev] Very Strange occurrence... In-Reply-To: References: <78C5DABF-5934-49D0-9F9D-CB8C35F74178@gmail.com> <7E1308B5-D0EE-41D5-8CF2-A419D9A78462@gmail.com> <4D23050D.10206@boroon.dasgupta.ch> <000c01cbac0b$e97d1ea0$bc775be0$@net> Message-ID: I vote for Hippo Linden! On Thu, Jan 6, 2011 at 8:44 AM, Kent Quirk (Q Linden) wrote: > So the reason that semi-plausible strings are used for these things is that > they're the only strings available when we use the test floater feature from > the login screen. > > But we should probably try not to use real names. > > And yes, Jonathan, these should mostly never be visible. But sometimes > things happen. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110106/ea9f51f0/attachment.htm From jhwelch at gmail.com Wed Jan 5 18:14:04 2011 From: jhwelch at gmail.com (Jonathan Yap) Date: Thu, 06 Jan 2011 02:14:04 -0000 Subject: [opensource-dev] Review Request: STORM-829 Viewer 2 does not parse /me in object Instant Messages Message-ID: <20110106021404.27618.82093@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/71/ ----------------------------------------------------------- Review request for Viewer. Summary ------- The "/me" in the lsl code below would be displayed rather than being translated to a name: llInstantMessage(llGetOwner(),"/me Hello, Avatar!"); This addresses bug STORM-829. http://jira.secondlife.com/browse/STORM-829 Diffs ----- indra/newview/llviewermessage.cpp 845cab866155 Diff: http://codereview.secondlife.com/r/71/diff Testing ------- Thanks, Jonathan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110106/996640f2/attachment.htm From wolfpup67 at earthlink.net Wed Jan 5 19:33:37 2011 From: wolfpup67 at earthlink.net (Wolfpup Lowenhar) Date: Thu, 06 Jan 2011 03:33:37 -0000 Subject: [opensource-dev] Review Request: STORM-829 Viewer 2 does not parse /me in object Instant Messages In-Reply-To: <20110106021404.27618.82093@domU-12-31-38-00-90-68.compute-1.internal> References: <20110106021404.27618.82093@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110106033337.27917.9871@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/71/#review114 ----------------------------------------------------------- Ship it! indra/newview/llviewermessage.cpp Looks good to me, but just wondering why your checking for "/me " and "/me'" . - Wolfpup On Jan. 5, 2011, 6:14 p.m., Jonathan Yap wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/71/ > ----------------------------------------------------------- > > (Updated Jan. 5, 2011, 6:14 p.m.) > > > Review request for Viewer. > > > Summary > ------- > > The "/me" in the lsl code below would be displayed rather than being translated to a name: > llInstantMessage(llGetOwner(),"/me Hello, Avatar!"); > > > This addresses bug STORM-829. > http://jira.secondlife.com/browse/STORM-829 > > > Diffs > ----- > > indra/newview/llviewermessage.cpp 845cab866155 > > Diff: http://codereview.secondlife.com/r/71/diff > > > Testing > ------- > > > Thanks, > > Jonathan > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110106/cf0038b7/attachment.htm From liny.odell at phoenixviewer.com Thu Jan 6 00:52:39 2011 From: liny.odell at phoenixviewer.com (Liny Odell) Date: Fri, 7 Jan 2011 00:52:39 +1600 Subject: [opensource-dev] Review Request: STORM-829 Viewer 2 does not parse /me in object Instant Messages In-Reply-To: <20110106033337.27917.9871@domU-12-31-38-00-90-68.compute-1.internal> References: <20110106021404.27618.82093@domU-12-31-38-00-90-68.compute-1.internal> <20110106033337.27917.9871@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: Ever done "/me's happy"? It comes out (in my case) "Liny Odell's happy". On Thu, Jan 6, 2011 at 7:33 PM, Wolfpup Lowenhar wrote: > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/71/ > > Ship it! > indra/newview/llviewermessage.cpp (Diff > revision 1) > > void process_improved_im(LLMessageSystem *msg, void **user_data) > > 2752 > > if (prefix == "/me " || prefix == "/me'") > > Looks good to me, but just wondering why your checking for "/me " and "/me'" . > > > - Wolfpup > > On January 5th, 2011, 6:14 p.m., Jonathan Yap wrote: > Review request for Viewer. > By Jonathan Yap. > > *Updated Jan. 5, 2011, 6:14 p.m.* > Description > > The "/me" in the lsl code below would be displayed rather than being translated to a name: > llInstantMessage(llGetOwner(),"/me Hello, Avatar!"); > > *Bugs: * STORM-829 > Diffs > > - indra/newview/llviewermessage.cpp (845cab866155) > > View Diff > > _______________________________________________ > Policies 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/20110107/3407e4ad/attachment-0001.htm From sllists at boroon.dasgupta.ch Thu Jan 6 04:01:39 2011 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Thu, 06 Jan 2011 12:01:39 -0000 Subject: [opensource-dev] Review Request: STORM-826 (partial): fix line endings in files that use a mix of CRLF and LF In-Reply-To: <20110105151932.6673.16877@domU-12-31-38-00-90-68.compute-1.internal> References: <20110105151932.6673.16877@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110106120139.27617.15043@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/70/#review115 ----------------------------------------------------------- "View Diff" doesn't display anything and with "Download Diff", I get a patch file that doesn't change anything: It removes some lines and adds back the exact same lines, with the same line endings (just LF). The surrounding lines (in the diff context) seem also to be LF-ended, even though one of the actual original files (indra/newview/llfloaterwebcontent.h) has CRLF endings, except for the line touched by the patch. I don't know how much of these are review-board and/or diffing issues. Please point us to a hg changeset so we can review the actual change. - Boroondas On Jan. 5, 2011, 7:19 a.m., Oz Linden wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/70/ > ----------------------------------------------------------- > > (Updated Jan. 5, 2011, 7:19 a.m.) > > > Review request for Viewer. > > > Summary > ------- > > This is a simple change to correct existing line endings - I scanned all of viewer-development to identify files that had a mixture of CRLF and LF endings and converted them to just LF. > > What to do about preventing future such will be dealt with separately... > > > This addresses bug storm-826. > http://jira.secondlife.com/browse/storm-826 > > > Diffs > ----- > > indra/newview/llfloaterwebcontent.h 845cab866155 > indra/newview/llimview.h 845cab866155 > indra/newview/llimview.cpp 845cab866155 > indra/newview/lllogchat.cpp 845cab866155 > > Diff: http://codereview.secondlife.com/r/70/diff > > > Testing > ------- > > > Thanks, > > Oz > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110106/5fcabee5/attachment.htm From sllists at boroon.dasgupta.ch Thu Jan 6 04:08:26 2011 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Thu, 06 Jan 2011 12:08:26 -0000 Subject: [opensource-dev] Review Request: STORM-826 (partial): fix line endings in files that use a mix of CRLF and LF In-Reply-To: <20110106120139.27617.15043@domU-12-31-38-00-90-68.compute-1.internal> References: <20110106120139.27617.15043@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110106120826.27621.5092@domU-12-31-38-00-90-68.compute-1.internal> > On Jan. 6, 2011, 4:01 a.m., Boroondas Gupte wrote: > > "View Diff" doesn't display anything and with "Download Diff", I get a patch file that doesn't change anything: It removes some lines and adds back the exact same lines, with the same line endings (just LF). The surrounding lines (in the diff context) seem also to be LF-ended, even though one of the actual original files (indra/newview/llfloaterwebcontent.h) has CRLF endings, except for the line touched by the patch. > > > > I don't know how much of these are review-board and/or diffing issues. Please point us to a hg changeset so we can review the actual change. Hmm ... on the jira, I saw the link to https://bitbucket.org/oz_linden/storm-826/changeset/8037fad5dee4 but that changes many more files than the diff downloadable here even mentions. - Boroondas ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/70/#review115 ----------------------------------------------------------- On Jan. 5, 2011, 7:19 a.m., Oz Linden wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/70/ > ----------------------------------------------------------- > > (Updated Jan. 5, 2011, 7:19 a.m.) > > > Review request for Viewer. > > > Summary > ------- > > This is a simple change to correct existing line endings - I scanned all of viewer-development to identify files that had a mixture of CRLF and LF endings and converted them to just LF. > > What to do about preventing future such will be dealt with separately... > > > This addresses bug storm-826. > http://jira.secondlife.com/browse/storm-826 > > > Diffs > ----- > > indra/newview/llfloaterwebcontent.h 845cab866155 > indra/newview/llimview.h 845cab866155 > indra/newview/llimview.cpp 845cab866155 > indra/newview/lllogchat.cpp 845cab866155 > > Diff: http://codereview.secondlife.com/r/70/diff > > > Testing > ------- > > > Thanks, > > Oz > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110106/b7836fb1/attachment.htm From jhwelch at gmail.com Thu Jan 6 04:17:13 2011 From: jhwelch at gmail.com (Jonathan Yap) Date: Thu, 06 Jan 2011 12:17:13 -0000 Subject: [opensource-dev] Review Request: STORM-829 Viewer 2 does not parse /me in object Instant Messages In-Reply-To: <20110106033337.27917.9871@domU-12-31-38-00-90-68.compute-1.internal> References: <20110106033337.27917.9871@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110106121713.27618.17428@domU-12-31-38-00-90-68.compute-1.internal> > On Jan. 5, 2011, 7:33 p.m., Wolfpup Lowenhar wrote: > > indra/newview/llviewermessage.cpp, line 2752 > > > > > > Looks good to me, but just wondering why your checking for "/me " and "/me'" . That is the check used in other parts of the code and as was pointed out in the mailing list you can type /me's happy - Jonathan ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/71/#review114 ----------------------------------------------------------- On Jan. 5, 2011, 6:14 p.m., Jonathan Yap wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/71/ > ----------------------------------------------------------- > > (Updated Jan. 5, 2011, 6:14 p.m.) > > > Review request for Viewer. > > > Summary > ------- > > The "/me" in the lsl code below would be displayed rather than being translated to a name: > llInstantMessage(llGetOwner(),"/me Hello, Avatar!"); > > > This addresses bug STORM-829. > http://jira.secondlife.com/browse/STORM-829 > > > Diffs > ----- > > indra/newview/llviewermessage.cpp 845cab866155 > > Diff: http://codereview.secondlife.com/r/71/diff > > > Testing > ------- > > > Thanks, > > Jonathan > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110106/40f3ced1/attachment.htm From carlo at alinoe.com Thu Jan 6 06:36:25 2011 From: carlo at alinoe.com (Carlo Wood) Date: Thu, 6 Jan 2011 15:36:25 +0100 Subject: [opensource-dev] Very Strange occurrence... In-Reply-To: References: <78C5DABF-5934-49D0-9F9D-CB8C35F74178@gmail.com> <7E1308B5-D0EE-41D5-8CF2-A419D9A78462@gmail.com> <4D23050D.10206@boroon.dasgupta.ch> <000c01cbac0b$e97d1ea0$bc775be0$@net> Message-ID: <20110106143625.GA11714@alinoe.com> On Wed, Jan 05, 2011 at 04:44:31PM -0500, Kent Quirk (Q Linden) wrote: > So the reason that semi-plausible strings are used for these things is that they're the only strings available when we use the test floater feature from the login screen. > > But we should probably try not to use real names. > > And yes, Jonathan, these should mostly never be visible. But sometimes things happen. Nevertheless, it is a bug; if whatever failed is outside the influence of the viewer itself, then still it should not have shown this. The viewer should be fixed to show the account name, or at least the UUID, in this -hopefully- rare case. -- Carlo Wood From Aleric.Inglewood at gmail.com Thu Jan 6 06:48:38 2011 From: Aleric.Inglewood at gmail.com (Aleric Inglewood) Date: Thu, 06 Jan 2011 14:48:38 -0000 Subject: [opensource-dev] Review Request: STORM-826 (partial): fix line endings in files that use a mix of CRLF and LF In-Reply-To: <20110105151932.6673.16877@domU-12-31-38-00-90-68.compute-1.internal> References: <20110105151932.6673.16877@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110106144838.30687.8889@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/70/#review119 ----------------------------------------------------------- You missed indra/newview/llfloaterwebcontent.cpp Also, why not fix the only .xml with carriage returns in it: indra/newview/skins/default/xui/en/floater_web_content.xml Configuration files with carriage returns: indra/cmake/GetPrerequisites_2_8.cmake indra/cmake/LLAddBuildTest.cmake - Aleric On Jan. 5, 2011, 7:19 a.m., Oz Linden wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/70/ > ----------------------------------------------------------- > > (Updated Jan. 5, 2011, 7:19 a.m.) > > > Review request for Viewer. > > > Summary > ------- > > This is a simple change to correct existing line endings - I scanned all of viewer-development to identify files that had a mixture of CRLF and LF endings and converted them to just LF. > > What to do about preventing future such will be dealt with separately... > > > This addresses bug storm-826. > http://jira.secondlife.com/browse/storm-826 > > > Diffs > ----- > > indra/newview/llfloaterwebcontent.h 845cab866155 > indra/newview/llimview.h 845cab866155 > indra/newview/llimview.cpp 845cab866155 > indra/newview/lllogchat.cpp 845cab866155 > > Diff: http://codereview.secondlife.com/r/70/diff > > > Testing > ------- > > > Thanks, > > Oz > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110106/7c92abd9/attachment-0001.htm From Aleric.Inglewood at gmail.com Thu Jan 6 07:00:28 2011 From: Aleric.Inglewood at gmail.com (Aleric Inglewood) Date: Thu, 06 Jan 2011 15:00:28 -0000 Subject: [opensource-dev] Review Request: STORM-829 Viewer 2 does not parse /me in object Instant Messages In-Reply-To: <20110106021404.27618.82093@domU-12-31-38-00-90-68.compute-1.internal> References: <20110106021404.27618.82093@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110106150028.30687.25377@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/71/#review120 ----------------------------------------------------------- What about /Me, /ME or /me followed by another punctuation? Ie, "/me?", "/me!", etc... Just asking because these comparisions with just "/me " and "/me'" seem very limited, almost weird. More logical would be to not check anything at ALL - and either expand things, or not. What happens if you just set a flag saying "whatever is in this string, don't expand /me, /who, /whois, /kick etc" without at that point checking for one specific case (missing possibly many other variations). - Aleric On Jan. 5, 2011, 6:14 p.m., Jonathan Yap wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/71/ > ----------------------------------------------------------- > > (Updated Jan. 5, 2011, 6:14 p.m.) > > > Review request for Viewer. > > > Summary > ------- > > The "/me" in the lsl code below would be displayed rather than being translated to a name: > llInstantMessage(llGetOwner(),"/me Hello, Avatar!"); > > > This addresses bug STORM-829. > http://jira.secondlife.com/browse/STORM-829 > > > Diffs > ----- > > indra/newview/llviewermessage.cpp 845cab866155 > > Diff: http://codereview.secondlife.com/r/71/diff > > > Testing > ------- > > > Thanks, > > Jonathan > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110106/bc520272/attachment.htm From jhwelch at gmail.com Thu Jan 6 07:45:27 2011 From: jhwelch at gmail.com (Jonathan Yap) Date: Thu, 06 Jan 2011 15:45:27 -0000 Subject: [opensource-dev] Review Request: STORM-829 Viewer 2 does not parse /me in object Instant Messages In-Reply-To: <20110106150028.30687.25377@domU-12-31-38-00-90-68.compute-1.internal> References: <20110106150028.30687.25377@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110106154527.27619.68356@domU-12-31-38-00-90-68.compute-1.internal> > On Jan. 6, 2011, 7 a.m., Aleric Inglewood wrote: > > What about /Me, /ME or /me followed by another punctuation? Ie, "/me?", "/me!", etc... > > Just asking because these comparisions with just "/me " and "/me'" seem very limited, > > almost weird. More logical would be to not check anything at ALL - and either expand > > things, or not. What happens if you just set a flag saying "whatever is in this > > string, don't expand /me, /who, /whois, /kick etc" without at that point checking > > for one specific case (missing possibly many other variations). > > If it was me writing the original code I would not have made it case-sensitive, but as this is a bug fix and not a new feature I am following the current design of having just /me work. - Jonathan ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/71/#review120 ----------------------------------------------------------- On Jan. 5, 2011, 6:14 p.m., Jonathan Yap wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/71/ > ----------------------------------------------------------- > > (Updated Jan. 5, 2011, 6:14 p.m.) > > > Review request for Viewer. > > > Summary > ------- > > The "/me" in the lsl code below would be displayed rather than being translated to a name: > llInstantMessage(llGetOwner(),"/me Hello, Avatar!"); > > > This addresses bug STORM-829. > http://jira.secondlife.com/browse/STORM-829 > > > Diffs > ----- > > indra/newview/llviewermessage.cpp 845cab866155 > > Diff: http://codereview.secondlife.com/r/71/diff > > > Testing > ------- > > > Thanks, > > Jonathan > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110106/a9a2bbc3/attachment.htm From jhwelch at gmail.com Thu Jan 6 09:28:21 2011 From: jhwelch at gmail.com (Jonathan Yap) Date: Thu, 06 Jan 2011 17:28:21 -0000 Subject: [opensource-dev] Review Request: VWR-24347 Reversion in Copy3rdPartyLibs.cmake -- cannot find msvc* files using VS 2005 Express In-Reply-To: <20110105001422.6679.8138@domU-12-31-38-00-90-68.compute-1.internal> References: <20110105001422.6679.8138@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110106172821.27659.7756@domU-12-31-38-00-90-68.compute-1.internal> > On Jan. 4, 2011, 4:14 p.m., Merov Linden wrote: > > Those lines have been missing since a long time: the first version in hg is already missing them: > > https://bitbucket.org/lindenlab/viewer-development/changeset/07304583316d They are not in that early version, but they are (plus code for VS2008) in a V2.1 copy I have of that file, but at some point were taken out again. - Jonathan ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/68/#review111 ----------------------------------------------------------- On Dec. 29, 2010, 3:42 p.m., Jonathan Yap wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/68/ > ----------------------------------------------------------- > > (Updated Dec. 29, 2010, 3:42 p.m.) > > > Review request for Viewer. > > > Summary > ------- > > Environment: Windows, VS 2005 Express > > Back in the days of v2.1 I was able to supply the following option to develop.py, which would allow me to specify the location of > msvcr80.dll > msvcp80.dll > Microsoft.VC80.CRT.manifest > > -DMSVC_REDIST_PATH:PATH=E:/some/path > > There was a similar code path for the debug files > -DMSVC_DEBUG_REDIST_PATH=E:/some/path > > This files cannot be found by the Express compiler so without a way of telling the compiler where to find them they have to be dropped into the build tree manually. > > At some point Copy3rdPartyLibs.cmake was rewritten and this option was dropped. > > > This addresses bug vwr-24347. > http://jira.secondlife.com/browse/vwr-24347 > > > Diffs > ----- > > indra/cmake/Copy3rdPartyLibs.cmake 27dae7b01a81 > > Diff: http://codereview.secondlife.com/r/68/diff > > > Testing > ------- > > I tried using -DMSVC_REDIST_PATH:PATH=E:/some/path with my VS 2005 Express compiler and obtained the desired result. > > I don't have the debug files to test -DMSVC_DEBUG_REDIST_PATH=E:/some/path > > > Thanks, > > Jonathan > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110106/8de1e995/attachment.htm From oz at lindenlab.com Thu Jan 6 10:20:31 2011 From: oz at lindenlab.com (Oz Linden) Date: Thu, 06 Jan 2011 18:20:31 -0000 Subject: [opensource-dev] Review Request: STORM-826 (partial): fix line endings in files that use a mix of CRLF and LF In-Reply-To: <20110105151932.6673.16877@domU-12-31-38-00-90-68.compute-1.internal> References: <20110105151932.6673.16877@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110106182031.27622.50780@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/70/ ----------------------------------------------------------- (Updated Jan. 6, 2011, 10:20 a.m.) Review request for Viewer. Summary (updated) ------- This is a simple change to correct existing line endings - I scanned all of viewer-development to identify files that had a mixture of CRLF and LF endings and converted them to just LF. The diff apparently won't show the change in line ending characters.... see the repo (in the issue) for the real change. I expanded the scope of this to also convert some files that were all the same CRLF endings but did not obviously need to be. I left files that were clearly windows specific alone on the theory that non-windows users probably won't need to touch them, and the windows tools might care. This addresses bug storm-826. http://jira.secondlife.com/browse/storm-826 Diffs (updated) ----- indra/cmake/GetPrerequisites_2_8.cmake 6d44f0d85a80 indra/cmake/LLAddBuildTest.cmake 6d44f0d85a80 indra/newview/llfloaterwebcontent.h 6d44f0d85a80 indra/newview/llfloaterwebcontent.cpp 6d44f0d85a80 indra/newview/llimview.h 6d44f0d85a80 indra/newview/llimview.cpp 6d44f0d85a80 indra/newview/lllogchat.cpp 6d44f0d85a80 indra/newview/tests/llremoteparcelrequest_test.cpp 6d44f0d85a80 indra/viewer_components/updater/tests/llupdaterservice_test.cpp 6d44f0d85a80 Diff: http://codereview.secondlife.com/r/70/diff Testing ------- Thanks, Oz -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110106/327e4721/attachment.htm From esbee at lindenlab.com Thu Jan 6 11:14:20 2011 From: esbee at lindenlab.com (Sarah (Esbee) Kuehnle) Date: Thu, 6 Jan 2011 14:14:20 -0500 Subject: [opensource-dev] Snowstorm Sprint meeting cancellation info Message-ID: Hi everybody, Due to conflicting meetings, I've had to cancel the Snowstorm Sprint meeting we had planned for 12pm PT today. We will still be having a Sprint Review meeting, but it will be held at 1pm PT. -- Esbee -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110106/26645576/attachment-0001.htm From Aleric.Inglewood at gmail.com Thu Jan 6 13:54:16 2011 From: Aleric.Inglewood at gmail.com (Aleric Inglewood) Date: Thu, 06 Jan 2011 21:54:16 -0000 Subject: [opensource-dev] Review Request: STORM-826 (partial): fix line endings in files that use a mix of CRLF and LF In-Reply-To: <20110106182031.27622.50780@domU-12-31-38-00-90-68.compute-1.internal> References: <20110106182031.27622.50780@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110106215416.27615.7782@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/70/#review124 ----------------------------------------------------------- Ship it! Should be ok, I see no diff on the review board at all :p I didn't actually apply the diff and check if all carriage returns are gone now, but I don't think that's the idea of the review board, is it? - Aleric On Jan. 6, 2011, 10:20 a.m., Oz Linden wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/70/ > ----------------------------------------------------------- > > (Updated Jan. 6, 2011, 10:20 a.m.) > > > Review request for Viewer. > > > Summary > ------- > > This is a simple change to correct existing line endings - I scanned all of viewer-development to identify files that had a mixture of CRLF and LF endings and converted them to just LF. > > The diff apparently won't show the change in line ending characters.... see the repo (in the issue) for the real change. > I expanded the scope of this to also convert some files that were all the same CRLF endings but did not obviously need to be. I left files that were clearly windows specific alone on the theory that non-windows users probably won't need to touch them, and the windows tools might care. > > > This addresses bug storm-826. > http://jira.secondlife.com/browse/storm-826 > > > Diffs > ----- > > indra/cmake/GetPrerequisites_2_8.cmake 6d44f0d85a80 > indra/cmake/LLAddBuildTest.cmake 6d44f0d85a80 > indra/newview/llfloaterwebcontent.h 6d44f0d85a80 > indra/newview/llfloaterwebcontent.cpp 6d44f0d85a80 > indra/newview/llimview.h 6d44f0d85a80 > indra/newview/llimview.cpp 6d44f0d85a80 > indra/newview/lllogchat.cpp 6d44f0d85a80 > indra/newview/tests/llremoteparcelrequest_test.cpp 6d44f0d85a80 > indra/viewer_components/updater/tests/llupdaterservice_test.cpp 6d44f0d85a80 > > Diff: http://codereview.secondlife.com/r/70/diff > > > Testing > ------- > > > Thanks, > > Oz > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110106/71a15202/attachment.htm From Aleric.Inglewood at gmail.com Thu Jan 6 14:03:14 2011 From: Aleric.Inglewood at gmail.com (Aleric Inglewood) Date: Thu, 06 Jan 2011 22:03:14 -0000 Subject: [opensource-dev] Review Request: STORM-829 Viewer 2 does not parse /me in object Instant Messages In-Reply-To: <20110106150028.30687.25377@domU-12-31-38-00-90-68.compute-1.internal> References: <20110106150028.30687.25377@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110106220314.27618.89369@domU-12-31-38-00-90-68.compute-1.internal> > On Jan. 6, 2011, 7 a.m., Aleric Inglewood wrote: > > What about /Me, /ME or /me followed by another punctuation? Ie, "/me?", "/me!", etc... > > Just asking because these comparisions with just "/me " and "/me'" seem very limited, > > almost weird. More logical would be to not check anything at ALL - and either expand > > things, or not. What happens if you just set a flag saying "whatever is in this > > string, don't expand /me, /who, /whois, /kick etc" without at that point checking > > for one specific case (missing possibly many other variations). > > > > Jonathan Yap wrote: > If it was me writing the original code I would not have made it case-sensitive, but as this is a bug fix and not a new feature I am following the current design of having just /me work. I didn't suggest to make it case insensitive, I wondered what happens when you use /ME instead of /me with and without the patch. And I wonder why it is necessary at all to compare a string with "/me ". At the very least that indicates code duplication. Let me clarify, void do_it(std::string const& str) { if (!flag && str == "/me") ... else ... } Bad code: if (str == "/me") flag = 1; do_it(str); ------------------------------------------- Code that makes more sense: flag = 1; do_it(str); But keep in mind that I didn't look at the actual code ;). I just looked at your patch. - Aleric ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/71/#review120 ----------------------------------------------------------- On Jan. 5, 2011, 6:14 p.m., Jonathan Yap wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/71/ > ----------------------------------------------------------- > > (Updated Jan. 5, 2011, 6:14 p.m.) > > > Review request for Viewer. > > > Summary > ------- > > The "/me" in the lsl code below would be displayed rather than being translated to a name: > llInstantMessage(llGetOwner(),"/me Hello, Avatar!"); > > > This addresses bug STORM-829. > http://jira.secondlife.com/browse/STORM-829 > > > Diffs > ----- > > indra/newview/llviewermessage.cpp 845cab866155 > > Diff: http://codereview.secondlife.com/r/71/diff > > > Testing > ------- > > > Thanks, > > Jonathan > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110106/d6d7e8ed/attachment.htm From twisted_laws at hotmail.com Thu Jan 6 14:24:54 2011 From: twisted_laws at hotmail.com (Twisted Laws) Date: Thu, 6 Jan 2011 17:24:54 -0500 Subject: [opensource-dev] Review Request: STORM-829 Viewer 2 does not parse /me in object Instant Messages In-Reply-To: <20110106220314.27618.89369@domU-12-31-38-00-90-68.compute-1.internal> References: <20110106150028.30687.25377@domU-12-31-38-00-90-68.compute-1.internal>, <20110106220314.27618.89369@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: that would be bad to check for "/me", what about "/meow" ? From: Aleric.Inglewood at gmail.com To: opensource-dev at lists.secondlife.com; Aleric.Inglewood at gmail.com; jhwelch at gmail.com Date: Thu, 6 Jan 2011 22:03:14 +0000 Subject: Re: [opensource-dev] Review Request: STORM-829 Viewer 2 does not parse /me in object Instant Messages This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/71/ On January 6th, 2011, 7 a.m., Aleric Inglewood wrote: What about /Me, /ME or /me followed by another punctuation? Ie, "/me?", "/me!", etc... Just asking because these comparisions with just "/me " and "/me'" seem very limited, almost weird. More logical would be to not check anything at ALL - and either expand things, or not. What happens if you just set a flag saying "whatever is in this string, don't expand /me, /who, /whois, /kick etc" without at that point checking for one specific case (missing possibly many other variations). On January 6th, 2011, 7:45 a.m., Jonathan Yap wrote: If it was me writing the original code I would not have made it case-sensitive, but as this is a bug fix and not a new feature I am following the current design of having just /me work. I didn't suggest to make it case insensitive, I wondered what happens when you use /ME instead of /me with and without the patch. And I wonder why it is necessary at all to compare a string with "/me ". At the very least that indicates code duplication. Let me clarify, void do_it(std::string const& str) { if (!flag && str == "/me") ... else ... } Bad code: if (str == "/me") flag = 1; do_it(str); ------------------------------------------- Code that makes more sense: flag = 1; do_it(str); But keep in mind that I didn't look at the actual code ;). I just looked at your patch. - Aleric On January 5th, 2011, 6:14 p.m., Jonathan Yap wrote: Review request for Viewer. By Jonathan Yap. Updated Jan. 5, 2011, 6:14 p.m. Description The "/me" in the lsl code below would be displayed rather than being translated to a name: llInstantMessage(llGetOwner(),"/me Hello, Avatar!"); Bugs: STORM-829 Diffs indra/newview/llviewermessage.cpp (845cab866155) View Diff _______________________________________________ Policies 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/20110106/6b016a1e/attachment.htm From jhwelch at gmail.com Thu Jan 6 14:37:06 2011 From: jhwelch at gmail.com (Jonathan Yap) Date: Thu, 06 Jan 2011 22:37:06 -0000 Subject: [opensource-dev] Review Request: STORM-830 Volume slider isn't properly remembered if set to zero Message-ID: <20110106223706.27616.47963@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/72/ ----------------------------------------------------------- Review request for Viewer. Summary ------- There is an edge case in setMasterGain during startup which prevents setInternalGain from being called if the master volume setting and mInternalGain both equal 0. Setting mInternalGain to a very low but non-zero value fixes this issue. This addresses bug STORM-830. http://jira.secondlife.com/browse/STORM-830 Diffs ----- indra/llaudio/llaudioengine.cpp 6d44f0d85a80 Diff: http://codereview.secondlife.com/r/72/diff Testing ------- In Preferences / Sound & Media tested: Buttons Ambient Sound Effects Stream Music Media Voice Chat Thanks, Jonathan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110106/7ad11136/attachment-0001.htm From jhwelch at gmail.com Thu Jan 6 14:43:46 2011 From: jhwelch at gmail.com (Jonathan Yap) Date: Thu, 06 Jan 2011 22:43:46 -0000 Subject: [opensource-dev] Review Request: STORM-829 Viewer 2 does not parse /me in object Instant Messages In-Reply-To: <20110106150028.30687.25377@domU-12-31-38-00-90-68.compute-1.internal> References: <20110106150028.30687.25377@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110106224346.27615.33139@domU-12-31-38-00-90-68.compute-1.internal> > On Jan. 6, 2011, 7 a.m., Aleric Inglewood wrote: > > What about /Me, /ME or /me followed by another punctuation? Ie, "/me?", "/me!", etc... > > Just asking because these comparisions with just "/me " and "/me'" seem very limited, > > almost weird. More logical would be to not check anything at ALL - and either expand > > things, or not. What happens if you just set a flag saying "whatever is in this > > string, don't expand /me, /who, /whois, /kick etc" without at that point checking > > for one specific case (missing possibly many other variations). > > > > Jonathan Yap wrote: > If it was me writing the original code I would not have made it case-sensitive, but as this is a bug fix and not a new feature I am following the current design of having just /me work. > > Aleric Inglewood wrote: > I didn't suggest to make it case insensitive, I wondered what happens > when you use /ME instead of /me with and without the patch. > And I wonder why it is necessary at all to compare a string with "/me ". > At the very least that indicates code duplication. > > Let me clarify, > > void do_it(std::string const& str) > { > if (!flag && str == "/me") > ... > else > ... > } > > Bad code: > > if (str == "/me") > flag = 1; > do_it(str); > > ------------------------------------------- > > Code that makes more sense: > > flag = 1; > do_it(str); > > > But keep in mind that I didn't look at the actual code ;). I just looked at your patch. > You have to check for /me with a blank after it as anything else would be processed as a potential gesture. This "/me " and "/me'" testing is scattered throughout the chat handling code. - Jonathan ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/71/#review120 ----------------------------------------------------------- On Jan. 5, 2011, 6:14 p.m., Jonathan Yap wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/71/ > ----------------------------------------------------------- > > (Updated Jan. 5, 2011, 6:14 p.m.) > > > Review request for Viewer. > > > Summary > ------- > > The "/me" in the lsl code below would be displayed rather than being translated to a name: > llInstantMessage(llGetOwner(),"/me Hello, Avatar!"); > > > This addresses bug STORM-829. > http://jira.secondlife.com/browse/STORM-829 > > > Diffs > ----- > > indra/newview/llviewermessage.cpp 845cab866155 > > Diff: http://codereview.secondlife.com/r/71/diff > > > Testing > ------- > > > Thanks, > > Jonathan > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110106/ae223c54/attachment.htm From Aleric.Inglewood at gmail.com Thu Jan 6 17:37:17 2011 From: Aleric.Inglewood at gmail.com (Aleric Inglewood) Date: Fri, 07 Jan 2011 01:37:17 -0000 Subject: [opensource-dev] Review Request: STORM-830 Volume slider isn't properly remembered if set to zero In-Reply-To: <20110106223706.27616.47963@domU-12-31-38-00-90-68.compute-1.internal> References: <20110106223706.27616.47963@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110107013717.27619.98439@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/72/#review128 ----------------------------------------------------------- This is really not how you want to deal with this bug :/. It's a known fact that audio mixers are very bad with low volumes. Setting a volume to 0 (or something really small) can put a very high load on the CPU for the audio mixer, which causes severe problems. See https://jira.secondlife.com/browse/VWR-14914 So, on the contrary (as VWR-14914 fixed a horrible bug that made FPS drop drastically): when the volume is set to 0 (or even close to zero) the audio channel has to be muted and not mixed, ever. Assuming that VWR-14914 is in Viewer 2, and wasn't broken in the meantime, a volume of 0 would cause the channel to be muted, but setting it to 0.000001 will not cause it to be muted, but result in a high CPU load. - Aleric On Jan. 6, 2011, 2:37 p.m., Jonathan Yap wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/72/ > ----------------------------------------------------------- > > (Updated Jan. 6, 2011, 2:37 p.m.) > > > Review request for Viewer. > > > Summary > ------- > > There is an edge case in setMasterGain during startup which prevents setInternalGain from being called if the master volume setting and mInternalGain both equal 0. > > Setting mInternalGain to a very low but non-zero value fixes this issue. > > > This addresses bug STORM-830. > http://jira.secondlife.com/browse/STORM-830 > > > Diffs > ----- > > indra/llaudio/llaudioengine.cpp 6d44f0d85a80 > > Diff: http://codereview.secondlife.com/r/72/diff > > > Testing > ------- > > In Preferences / Sound & Media tested: > Buttons > Ambient > Sound Effects > Stream Music > Media > Voice Chat > > > Thanks, > > Jonathan > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110107/5066aa92/attachment.htm From Lance.Corrimal at eregion.de Fri Jan 7 00:43:20 2011 From: Lance.Corrimal at eregion.de (Lance Corrimal) Date: Fri, 7 Jan 2011 09:43:20 +0100 Subject: [opensource-dev] too bad that list posts can't be "sticky". Message-ID: <201101070943.20782.Lance.Corrimal@eregion.de> Could someone please link to this somewhere prominently on the snowstorm webpages? Just as a reminder of sorts? http://xkcd.com/844/ bye, LC From Aleric.Inglewood at gmail.com Fri Jan 7 05:25:43 2011 From: Aleric.Inglewood at gmail.com (Aleric Inglewood) Date: Fri, 07 Jan 2011 13:25:43 -0000 Subject: [opensource-dev] Review Request: STORM-830 Volume slider isn't properly remembered if set to zero In-Reply-To: <20110107013717.27619.98439@domU-12-31-38-00-90-68.compute-1.internal> References: <20110107013717.27619.98439@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110107132543.27917.99344@domU-12-31-38-00-90-68.compute-1.internal> > On Jan. 6, 2011, 5:37 p.m., Aleric Inglewood wrote: > > This is really not how you want to deal with this bug :/. It's a known fact that audio mixers are very bad with low volumes. Setting a volume to 0 (or something really small) can put a very high load on the CPU for the audio mixer, which causes severe problems. See https://jira.secondlife.com/browse/VWR-14914 > > > > So, on the contrary (as VWR-14914 fixed a horrible bug that made FPS drop drastically): when the volume is set to 0 (or even close to zero) the audio channel has to be muted and not mixed, ever. Assuming that VWR-14914 is in Viewer 2, and wasn't broken in the meantime, a volume of 0 would cause the channel to be muted, but setting it to 0.000001 will not cause it to be muted, but result in a high CPU load. > > After discussion on IRC Jonathan explained to me what this is all about. The patch is correct. Nevertheless, I was confused about the fact that this value of 0.000001 is never going to be USED. Perhaps a different value and comment can avoid that in the future when other coders look at it. mInternalGain is only ever compared with, and the whole point of this patch is to make sure that the first comparison fails (I now understand). A common value used to make sure that a first comparison fails is a value outside the valid range of that variable. The valid range being [0, 1], I'd suggest using -1 and adding a comment in the lines of: // Make sure that the first call to setMasterGain will cause setInternalGain to be called. mInternalGain = -1.f; - Aleric ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/72/#review128 ----------------------------------------------------------- On Jan. 6, 2011, 2:37 p.m., Jonathan Yap wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/72/ > ----------------------------------------------------------- > > (Updated Jan. 6, 2011, 2:37 p.m.) > > > Review request for Viewer. > > > Summary > ------- > > There is an edge case in setMasterGain during startup which prevents setInternalGain from being called if the master volume setting and mInternalGain both equal 0. > > Setting mInternalGain to a very low but non-zero value fixes this issue. > > > This addresses bug STORM-830. > http://jira.secondlife.com/browse/STORM-830 > > > Diffs > ----- > > indra/llaudio/llaudioengine.cpp 6d44f0d85a80 > > Diff: http://codereview.secondlife.com/r/72/diff > > > Testing > ------- > > In Preferences / Sound & Media tested: > Buttons > Ambient > Sound Effects > Stream Music > Media > Voice Chat > > > Thanks, > > Jonathan > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110107/fdc8850b/attachment-0001.htm From q at lindenlab.com Fri Jan 7 06:54:39 2011 From: q at lindenlab.com (Kent Quirk) Date: Fri, 07 Jan 2011 14:54:39 -0000 Subject: [opensource-dev] Review Request: (STORM-550) LLDir::getNextFileInDir fails for some complex wildcard combinations In-Reply-To: <20110105193429.6678.68706@domU-12-31-38-00-90-68.compute-1.internal> References: <20110105193429.6678.68706@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110107145439.27615.77304@domU-12-31-38-00-90-68.compute-1.internal> > On Jan. 5, 2011, 11:34 a.m., Oz Linden wrote: > > Just one policy question with this... > > > > This implementation uses llwarns for various errors in the glob expression. > > > > Given that I expect that the glob expression will normally (always?) be hard coded (I hope no one will accept a pattern as input from the user and pass it on unverified), should these use llerrs so that the error cannot be missed (it crashes)? > > > > Other than that, this looks good now. > > Seth ProductEngine wrote: > Not sure about the policy on llerrs but as far as I remember we were trying not to overuse it, using only for fatal errors. > If someone eventually will accept a pattern as the user input this might cause unexpected crashes, so I thought warnings would be enough to trace the error while hard coding the patterns, though if llerrs will work better in this case warnings could be replaced. I'd prefer to see llerrs here; there's no use case I can imagine to allow someone to manually enter globs. - Kent ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/32/#review112 ----------------------------------------------------------- On Jan. 5, 2011, 8:33 a.m., Seth ProductEngine wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/32/ > ----------------------------------------------------------- > > (Updated Jan. 5, 2011, 8:33 a.m.) > > > Review request for Viewer. > > > Summary > ------- > > Fixed LLDir unit test which failed for some complex wildcard combinations. > Added a class implementing directory entries iteration with pattern matching which is used in unit tests instead of LLDir::getNextFileInDir. > > This code has been run on Linux only. It should be tested under other platforms and more test cases should be provided. For example changing directory contents while iterating through it. > > > This addresses bug STORM-477. > http://jira.secondlife.com/browse/STORM-477 > > > Diffs > ----- > > indra/cmake/Boost.cmake 27dae7b01a81 > indra/llvfs/CMakeLists.txt 27dae7b01a81 > indra/llvfs/lldiriterator.h PRE-CREATION > indra/llvfs/lldiriterator.cpp PRE-CREATION > indra/llvfs/tests/lldir_test.cpp 27dae7b01a81 > > Diff: http://codereview.secondlife.com/r/32/diff > > > Testing > ------- > > > Thanks, > > Seth > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110107/7ccdb8e7/attachment.htm From sllists at boroon.dasgupta.ch Fri Jan 7 08:01:33 2011 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Fri, 07 Jan 2011 16:01:33 -0000 Subject: [opensource-dev] Review Request: STORM-826 (partial): fix line endings in files that use a mix of CRLF and LF In-Reply-To: <20110106182031.27622.50780@domU-12-31-38-00-90-68.compute-1.internal> References: <20110106182031.27622.50780@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110107160133.27917.41251@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/70/#review131 ----------------------------------------------------------- Still CRLFs in indra/newview/skins/default/xui/en/floater_web_content.xml , which isn't windows specific, I think. Otherwise https://bitbucket.org/oz_linden/storm-826/changeset/6e6d1de23cce looks good. I'm wondering whether we should also fix indentation on lines that are touched by this change anyway. (E.g. floater_web_content.xml mixes spaces and tabs.) - Boroondas On Jan. 6, 2011, 10:20 a.m., Oz Linden wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/70/ > ----------------------------------------------------------- > > (Updated Jan. 6, 2011, 10:20 a.m.) > > > Review request for Viewer. > > > Summary > ------- > > This is a simple change to correct existing line endings - I scanned all of viewer-development to identify files that had a mixture of CRLF and LF endings and converted them to just LF. > > The diff apparently won't show the change in line ending characters.... see the repo (in the issue) for the real change. > I expanded the scope of this to also convert some files that were all the same CRLF endings but did not obviously need to be. I left files that were clearly windows specific alone on the theory that non-windows users probably won't need to touch them, and the windows tools might care. > > > This addresses bug storm-826. > http://jira.secondlife.com/browse/storm-826 > > > Diffs > ----- > > indra/cmake/GetPrerequisites_2_8.cmake 6d44f0d85a80 > indra/cmake/LLAddBuildTest.cmake 6d44f0d85a80 > indra/newview/llfloaterwebcontent.h 6d44f0d85a80 > indra/newview/llfloaterwebcontent.cpp 6d44f0d85a80 > indra/newview/llimview.h 6d44f0d85a80 > indra/newview/llimview.cpp 6d44f0d85a80 > indra/newview/lllogchat.cpp 6d44f0d85a80 > indra/newview/tests/llremoteparcelrequest_test.cpp 6d44f0d85a80 > indra/viewer_components/updater/tests/llupdaterservice_test.cpp 6d44f0d85a80 > > Diff: http://codereview.secondlife.com/r/70/diff > > > Testing > ------- > > > Thanks, > > Oz > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110107/dffef04a/attachment.htm From josh at lindenlab.com Fri Jan 7 09:36:04 2011 From: josh at lindenlab.com (Joshua Linden) Date: Fri, 07 Jan 2011 17:36:04 -0000 Subject: [opensource-dev] Review Request: STORM-829 Viewer 2 does not parse /me in object Instant Messages In-Reply-To: <20110106021404.27618.82093@domU-12-31-38-00-90-68.compute-1.internal> References: <20110106021404.27618.82093@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110107173604.27620.95252@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/71/#review132 ----------------------------------------------------------- I believe Aleric's comment is accurate. Logic testing for a prefix should be removed from the patch, and the flag should simply always be specified in this case. It is notable that the flag does trigger exactly the same test that is present in the patch (i.e. it's not case sensitive, it replicates prefix testing in several other places in the code base, etc). A more general fix might be to refactor all of the places that do prefix testing, but that wouldn't affect this specific issue. Again, the patch should be reduced to one line that simply adds the desired flag. - Joshua On Jan. 5, 2011, 6:14 p.m., Jonathan Yap wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/71/ > ----------------------------------------------------------- > > (Updated Jan. 5, 2011, 6:14 p.m.) > > > Review request for Viewer. > > > Summary > ------- > > The "/me" in the lsl code below would be displayed rather than being translated to a name: > llInstantMessage(llGetOwner(),"/me Hello, Avatar!"); > > > This addresses bug STORM-829. > http://jira.secondlife.com/browse/STORM-829 > > > Diffs > ----- > > indra/newview/llviewermessage.cpp 845cab866155 > > Diff: http://codereview.secondlife.com/r/71/diff > > > Testing > ------- > > > Thanks, > > Jonathan > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110107/c5738336/attachment.htm From akanevsky at productengine.com Fri Jan 7 10:12:26 2011 From: akanevsky at productengine.com (Anya Kanevsky) Date: Fri, 7 Jan 2011 12:12:26 -0600 Subject: [opensource-dev] Daily Scrum Summary - Thursday, January 6, 2011 Message-ID: Thursday, January 6, 2011 General Notes ------------------------------ - Reminder to devs. If a ticket doesn't pass Review and is rejected, it will move back to the To Do column in GH, if you do more work or clarify questions, it should be moved back through In Progress and then to In Review. - MMOTD: Oz, because he's automating the hell out of it. Team Status ------------------------------ Merov Linden ------------------------------ *PAST* - STORM-828 : Texture Saving Does Not Work: More testing and looking into it. Problem is intermittent. Suspect server side issue (new cap routing) as we see cap errors when things go wrong. Checked with Monty, read docs. More instrumentation show that the problem may occur even without cap issues. Suspecting caching issues now. It's deep and multi faceted... Discussed and assigned to Bao. *FUTURE* - STORM-828 : Texture Saving Does Not Work: Continue to investigate a bit with Bao. - STORM-745 : Produce comprehensive perf baseline: Complete that work. *IMPEDIMENTS* - None Oz Linden ------------------------------ *PAST* - Merge Monkey - Office Hour - Reviewing third party lib builds to be moved to bitbucket - Helped XMPP Group Chat publish open source for project viewer - Reposted line endings fix based on review feedback *FUTURE* - Merge Monkey - Investigate Mercurial hooks for doing commit/pull checks - Look at VWR issues that have patches attached *IMPEDIMENTS* - none Q Linden ------------------------------ *PAST* - storm-34 - talk with oz about apr stuff - meetings - ooo *FUTURE* - storm-34 - storm-2 - meetings *IMPEDIMENTS* - meetings Esbee Linden ------------------------------ *PAST* - Meetings, Email - PO reviews - Prepared and sent out instruction and developer viewer build for product council to review - Scheduled 1:1s w/Gez - Reviewed half of the VWRs assigned to PE - Sent feedback to Jonathan on next steps for STORM-615 - Reviewed STORM-236 and decided on next steps *FUTURE* - Meetings - Review Snowstorm Team product backlog and bug log - Work with Rhett on next steps for Viewer icons - PO reviews for open tickets - Talk to Q about Andrew's feedback on STORM-753 (Design for Viewer Saved Layouts) - Finish going through the list of VWRs assigned to PE (finally) - Plan update for system requirements - Look at VWR-18435 and VWR-24357 for Jonathan - Add instructions for STORM-236 for Wolfpup - Write draft for Viewer 2.5 blog post *IMPEDIMENTS* - STORM-702 needs to be moved back through to the Review process so we can do PO and code reviews. Paul ProductEngine ------------------------------ - OOO - vacation Seth Productengine ------------------------------ *PAST* - BUG (STORM-447) User is not able to share multi selected objects using drag&drop - WIP. Investigated. Might require a few days long refactoring. Asked Esbee if we should start working at it. - BUG (STORM-514) LLSideTray::Params::Params() gets non-exsistant artwork. - Fixed. *FUTURE* - Pick some issues from bug queue. *IMPEDIMENTS* - None. Andrew Productengine ------------------------------ *PAST* - Answered Q's comments in STORM-823 (Tab Key not working properly) and STORM-34 (As a User, I want a list of my favorite locations available on the login screen so i can log in to SL right where I want to be). - Normal task STORM-2 (Customizable viewer layouts). - Excluded some floaters that caused crashes on load from saving to layout. Continued fixing the bug with loading undocked sidetray tabs - yesterday's idea of fix was in tight direction but can't be applied directly (it would break dock functionality of floater). Hope to finish it on Monday. *FUTURE* - Normal task STORM-2. Hope to finally finish first pass of feature on Monday. *IMPEDIMENTS* - STORM-2. Waiting for Q's reply to letter about organization of layout saving. - STORM-2. Waiting for Esbee's answers to comments about layout design in STORM-753. - STORM-34. No reply from Q to comment about current implementation of feature. Vadim Productengine ------------------------------ *PAST* - Bug STORM-226 (Viewer 2 Floating Text aligns improperly): - Requested an acceptance criteria. - Bug STORM-393 (Group SLURL has wrong color in the nearby chat): - Fixed. - Bug STORM-428 (Name of blocked person is not presented in Block list if person was added to list from 'Near me' or 'Friends' tabs of Choose resident): - Resolved as not reproducible. - Bug STORM-594 (Crash in LLView::handleVisibilityChange): - One more attempt to reproduce and find the reason. No luck so far. - Changed status of some tickets having both approvals from Reviewing to Approved, so that they can be integrated. *FUTURE* - Bug STORM-594 (Crash in LLView::handleVisibilityChange). - Bug STORM-243 (Suppress version change message in the viewer). *IMPEDIMENTS* - Need a decision in STORM-702 (Make it possible to wear partial outfits). Andrey Productengine ------------------------------ *PAST* - picked up v-d build r218264 - integrated tickets verification - continued regression testing of the build, see spreadsheet Sprint9-r217888-218264-Regression for details *FUTURE* - review and approve test plans for Chat, URLs, and Sidebar *IMPEDIMENTS* - there is a bunch of integrated tickets that I don't know how to verify from black-box perspective: STORM-810, STORM-799, STORM-800, STORM-780 Jonathan Yap ------------------------------ *PAST* - VWR-24347 (Reversion in Copy3rdPartyLibs.cmake -- cannot find msvc* files using VS 2005 Express) - This has been on Review Board for a while. Done. - STORM-829 (Viewer 2 does not parse /me in object Instant Messages) - Posted to Review Board. Done. - STORM-830 (Volume slider isn't properly remembered if set to zero) *FUTURE* - STORM-830 (Volume slider isn't properly remembered if set to zero) *IMPEDIMENTS* - Need someone to bring VWR-24357 ( "Less" is not displayed after clicking on the "More" button in Nearby Media) into STORM if they think fixing this is a good idea. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110107/0754a29f/attachment-0001.htm From jhwelch at gmail.com Fri Jan 7 10:25:26 2011 From: jhwelch at gmail.com (Jonathan Yap) Date: Fri, 07 Jan 2011 18:25:26 -0000 Subject: [opensource-dev] Review Request: STORM-829 Viewer 2 does not parse /me in object Instant Messages In-Reply-To: <20110107173604.27620.95252@domU-12-31-38-00-90-68.compute-1.internal> References: <20110107173604.27620.95252@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110107182526.27618.47295@domU-12-31-38-00-90-68.compute-1.internal> > On Jan. 7, 2011, 9:36 a.m., Joshua Linden wrote: > > I believe Aleric's comment is accurate. Logic testing for a prefix should be removed from the patch, and the flag should simply always be specified in this case. > > > > It is notable that the flag does trigger exactly the same test that is present in the patch (i.e. it's not case sensitive, it replicates prefix testing in several other places in the code base, etc). A more general fix might be to refactor all of the places that do prefix testing, but that wouldn't affect this specific issue. Again, the patch should be reduced to one line that simply adds the desired flag. Joshua, if the check for "/me " and "/me'" were not present and CHAT_STYLE_IRC was always passed in then all llInstantMessages from objects would be treated as if /me had been sent. I don't think this is what is desired. - Jonathan ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/71/#review132 ----------------------------------------------------------- On Jan. 5, 2011, 6:14 p.m., Jonathan Yap wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/71/ > ----------------------------------------------------------- > > (Updated Jan. 5, 2011, 6:14 p.m.) > > > Review request for Viewer. > > > Summary > ------- > > The "/me" in the lsl code below would be displayed rather than being translated to a name: > llInstantMessage(llGetOwner(),"/me Hello, Avatar!"); > > > This addresses bug STORM-829. > http://jira.secondlife.com/browse/STORM-829 > > > Diffs > ----- > > indra/newview/llviewermessage.cpp 845cab866155 > > Diff: http://codereview.secondlife.com/r/71/diff > > > Testing > ------- > > > Thanks, > > Jonathan > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110107/e324b7ac/attachment.htm From Aleric.Inglewood at gmail.com Fri Jan 7 11:46:32 2011 From: Aleric.Inglewood at gmail.com (Aleric Inglewood) Date: Fri, 07 Jan 2011 19:46:32 -0000 Subject: [opensource-dev] Review Request: STORM-829 Viewer 2 does not parse /me in object Instant Messages In-Reply-To: <20110107173604.27620.95252@domU-12-31-38-00-90-68.compute-1.internal> References: <20110107173604.27620.95252@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110107194632.30687.74936@domU-12-31-38-00-90-68.compute-1.internal> > On Jan. 7, 2011, 9:36 a.m., Joshua Linden wrote: > > I believe Aleric's comment is accurate. Logic testing for a prefix should be removed from the patch, and the flag should simply always be specified in this case. > > > > It is notable that the flag does trigger exactly the same test that is present in the patch (i.e. it's not case sensitive, it replicates prefix testing in several other places in the code base, etc). A more general fix might be to refactor all of the places that do prefix testing, but that wouldn't affect this specific issue. Again, the patch should be reduced to one line that simply adds the desired flag. > > Jonathan Yap wrote: > Joshua, if the check for "/me " and "/me'" were not present and CHAT_STYLE_IRC was always passed in then all llInstantMessages from objects would be treated as if /me had been sent. I don't think this is what is desired. @Joshua : Um yes - all of that seemed logical. But the existing code is far from logical, or clean. I just had a discussion with Jonathan on IRC and now understand that the meaning of the CHAT_STYLE_IRC is actually "we found this message to start with "/me", please BLINDLY replace the first 3 characters with the name of the object/avatar". The name of the flag is horribly wrong imho. Also, then I suggested to change the code in the what I had assumed it was: set the flag whenever replacement is necessary and just leave it to the replacement code to check for it. That would therefore require an additional change: make the code that now only tests if the flag is set ALSO test if the message indeed starts with "/me " or "/me'" (and having gotten rid of the code duplication, it then could easily be extended in the future). Unfortunately, not only the testing for "/me " is scattered all over the place, also the code that does the actual replacement of the first 3 characters exists in many places! ... So, without making this a much larger "project", I suppose adding one more duplication of code that checks for "/me " isn't the worst of things, and at least it is an immediate fix for the problem at hand :/. I have no objections anymore if the patch would be used as-is. - Aleric ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/71/#review132 ----------------------------------------------------------- On Jan. 5, 2011, 6:14 p.m., Jonathan Yap wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/71/ > ----------------------------------------------------------- > > (Updated Jan. 5, 2011, 6:14 p.m.) > > > Review request for Viewer. > > > Summary > ------- > > The "/me" in the lsl code below would be displayed rather than being translated to a name: > llInstantMessage(llGetOwner(),"/me Hello, Avatar!"); > > > This addresses bug STORM-829. > http://jira.secondlife.com/browse/STORM-829 > > > Diffs > ----- > > indra/newview/llviewermessage.cpp 845cab866155 > > Diff: http://codereview.secondlife.com/r/71/diff > > > Testing > ------- > > > Thanks, > > Jonathan > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110107/d4d182c7/attachment.htm From jamey at beau.org Fri Jan 7 13:14:48 2011 From: jamey at beau.org (Jamey Fletcher) Date: Fri, 07 Jan 2011 15:14:48 -0600 Subject: [opensource-dev] Review Request: STORM-829 Viewer 2 does not parse /me in object Instant Messages In-Reply-To: <20110107173604.27620.95252@domU-12-31-38-00-90-68.compute-1.internal> References: <20110106021404.27618.82093@domU-12-31-38-00-90-68.compute-1.internal> <20110107173604.27620.95252@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <4D278248.5070301@beau.org> Joshua Linden wrote: > I believe Aleric's comment is accurate. Logic testing for a prefix > should be removed from the patch, and the flag should simply always > be specified in this case. > It is notable that the flag does trigger exactly the same test that > is present in the patch (i.e. it's not case sensitive, it replicates > prefix testing in several other places in the code base, etc). A more > general fix might be to refactor all of the places that do prefix > testing, but that wouldn't affect this specific issue. Again, the > patch should be reduced to one line that simply adds the desired > flag. I'm... wondering why not test *ONCE* when the input is accepted, do the appropriate replacement and set the flag so it gets sent as an action instead of a statement, and be done with it? The IM input, chatbar inputs, and local history tab inputs all need pretty much the same validation, don't they? From angel_of_crimson at hotmail.com Fri Jan 7 17:35:21 2011 From: angel_of_crimson at hotmail.com (Erin Mallory) Date: Fri, 7 Jan 2011 20:35:21 -0500 Subject: [opensource-dev] storm-34 Message-ID: I've been testing the storm 34 viewer on windows 7 and on windows xp. Ive noticed its not properly keeping the preferences between when youre logged in and logged out and that the favorites therefor are not properly showing up for me. this started occuring after i changed the account from my cummere to erinyse then back. now no matter what i cant get it to show the favorites for either account at log in even though both accounts have that box checked.... before i jira this, can anyone else repo? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110107/7a55a24b/attachment-0001.htm -------------- next part -------------- A non-text attachment was scrubbed... Name: storm 34 pic two.JPG Type: image/jpeg Size: 76135 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110107/7a55a24b/attachment-0002.jpeg -------------- next part -------------- A non-text attachment was scrubbed... Name: storm 34 pic one.JPG Type: image/jpeg Size: 119719 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110107/7a55a24b/attachment-0003.jpeg From akanevsky at productengine.com Fri Jan 7 22:37:27 2011 From: akanevsky at productengine.com (Anya Kanevsky) Date: Sat, 8 Jan 2011 00:37:27 -0600 Subject: [opensource-dev] Daily Scrum Summary - Friday, January 7, 2011 Message-ID: Friday, January 7, 2011 General Notes ------------------------------ - Reminder to devs. If a ticket doesn't pass Review and is rejected, it will move back to the To Do column in GH, if you do more work or clarify questions, it should be moved back through In Progress and then to In Review. - MMOTD: Oz - PE is on holiday today - Orthodox Christmas Team Status ------------------------------ Merov Linden ------------------------------ *PAST* - STORM-828 : Texture Saving Does Not Work : investigated more with Bao. Issue moved to Bao's backlog. - STORM-150 : Evaluate kakadu new capabilities : Wrote doc, moved to review state, reviewed - STORM-104 : Update KDU to more recent version (v6.4) so we take advantage of decompression perf gain : All sub-tasks done so moved to review state. *FUTURE* - Clean-up all dangling sprint 9 issues assigned to me - STORM-745 : Produce comprehensive perf baseline: Complete that work. *IMPEDIMENTS* - None Oz Linden ------------------------------ *PAST* - Merge Monkey (tagged 2.5.0-start) - Set up some third party lib bitbucket repos - Code reviews - Looking at old VWR patches - Help triage a TPV issue with SLURLs *FUTURE* - Merge Monkey (handoff to Merov at EOD) - More looking at old VWR patches - Tracking down viewer dependencies, start updating wiki *IMPEDIMENTS* - none Q Linden ------------------------------ - OOO Esbee Linden ------------------------------ *PAST* - Meetings, Email - PO reviews - Discussed STORM-34, STORM-2, & STORM-753 w/Q - Reviewed STORM-34,STORM-2, and STORM-753 - Contacted Rhett about STORM-34 - Looped Q into the discussion about Viewer icons and the naming of Developer Viewers - Discussions about Viewer 2.5 beta 1 *FUTURE* - Meetings - Write draft for Viewer 2.5 blog post - Review Snowstorm Team product backlog and bug log - Work with Rhett on next steps for Viewer icons - PO reviews for open tickets - Finish going through the list of VWRs assigned to PE (finally) - Plan update for system requirements - Look at VWR-18435 and VWR-24357 for Jonathan - Add instructions for STORM-236 for Wolfpup *IMPEDIMENTS* - STORM-702 needs to be moved back through to the Review process so we can do PO and code reviews. Paul ProductEngine ------------------------------ - OOO - holiday Seth Productengine ------------------------------ *PAST* - BUG (STORM-396) Mouse cursor changes to "+" if try to drop a landmark from object inventory or notecard onto Favorites Bar - Could not reproduce. - BUG (STORM-385) Pressing ENTER key in the Favorites overflow list scrolls list - Fixed. *FUTURE* - BUG (STORM-383) Context menu cannot be open for Landmark that are located in the My inventory->Trash folder *IMPEDIMENTS* Waiting for Esbee's reply on the following issues: - TASK (STORM-797) Parcel SLURL rendering - TASK (STORM-28) As a User, I want the ability to send my calling card to others - BUG (STORM-447) User is not able to share multi selected objects using drag&drop Andrew Productengine ------------------------------ - OOO - holiday Vadim Productengine ------------------------------ - OOO - holiday Andrey Productengine ------------------------------ - OOO - holiday Jonathan Yap ------------------------------ *PAST* - STORM-830 (Volume slider isn't properly remembered if set to zero) - Fixed, but looking for comments on Review Board. - Long IRC discussion with Aleric this morning on this one. - Wrote VWR-24416 (Allow user to supply/define her own objects in the build floater) - STORM-435 (There is no space between name of object and value of object in Chat step while creating new gesture) - Fixed. - Commented on Review Board entry for STORM-829 (Viewer 2 does not parse /me in object Instant Messages) *FUTURE* - I have other commitments for the next two weeks and will not be around as much. *IMPEDIMENTS* - none - -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110108/a2c5030e/attachment-0001.htm From lee.ponzu at gmail.com Sat Jan 8 09:34:49 2011 From: lee.ponzu at gmail.com (Ponzu) Date: Sat, 8 Jan 2011 12:34:49 -0500 Subject: [opensource-dev] Pre-processing chat input (was Re: Review Request: STORM-829 Viewer 2 does not parse /me in object Instant Messages Message-ID: This reminds me a little of unix/sh/bash command line parsing, only much much simpler. We have almost nothing to pre-preprocess, though some of the TPVs do somewhat more. Could/should there be a llPreProcessChatLine() function. That way, You would reduce code duplication like =="/me " == "/me' " You would have a central place to put improvements. I always wanted things like /follow /goto /pointat etc etc etc. (Being an ancient old keyboard kinda guy...) just thinking... ponzu > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110108/4ba7a3b0/attachment.htm From Lance.Corrimal at eregion.de Sat Jan 8 09:58:14 2011 From: Lance.Corrimal at eregion.de (Lance Corrimal) Date: Sat, 8 Jan 2011 18:58:14 +0100 Subject: [opensource-dev] https://jira.secondlife.com/browse/SH-489 Message-ID: <201101081858.14793.Lance.Corrimal@eregion.de> Hi there, am I the only one who thinks that https://jira.secondlife.com/browse/SH-489 should be rated a bit higher than "minor, will be fixed in the distant future"? bye, LC From jhwelch at gmail.com Sat Jan 8 11:16:29 2011 From: jhwelch at gmail.com (Jonathan Welch) Date: Sat, 8 Jan 2011 14:16:29 -0500 Subject: [opensource-dev] Pre-processing chat input (was Re: Review Request: STORM-829 Viewer 2 does not parse /me in object Instant Messages In-Reply-To: References: Message-ID: Yesterday it was suggested to substitute /me at some early point. In this particular case it would not work for two reasons: 1) "/me" has to pass through the communications system so when it arrives at the viewer from the server the various components that display the line can see it is a "/me" line and insert the name in italics or otherwise "do the right thing". You have local chat toasts, chat history, the IM window, etc. 2) There are 3 ways messages can arrive from objects (llSay, llOwnerSay, and llInstantMessage) so there is no way they can be processed until the arrive at your viewer for display. -Jonathan From thickbrick.sleaford at gmail.com Sun Jan 9 06:59:17 2011 From: thickbrick.sleaford at gmail.com (Thickbrick Sleaford) Date: Sun, 09 Jan 2011 14:59:17 -0000 Subject: [opensource-dev] Review Request: VWR-24420: PNG images which specify "background color" lose alpha layer when imported. Message-ID: <20110109145917.7202.23064@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/74/ ----------------------------------------------------------- Review request for Viewer. Summary ------- Current code composites RGBA PNG images that contain a bKGD chunk down to RGB, discarding the alpha channel. This patch removes that code, since it contradicts purpose of the bKGD chunk as described in the PNG spec and as commonly used. This addresses bug VWR-24420. http://jira.secondlife.com/browse/VWR-24420 Diffs ----- doc/contributions.txt UNKNOWN indra/llimage/llpngwrapper.h UNKNOWN indra/llimage/llpngwrapper.cpp UNKNOWN Diff: http://codereview.secondlife.com/r/74/diff Testing ------- Tested uploading the 2 images attached to VWR-24420 with and without the patch. Before patch, "bad alpha.png" was uploaded as RGB, after patch, both images were uploaded as RGBA. Thanks, Thickbrick -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110109/1a3aba81/attachment.htm From lee.ponzu at gmail.com Sun Jan 9 07:09:45 2011 From: lee.ponzu at gmail.com (Ponzu) Date: Sun, 9 Jan 2011 10:09:45 -0500 Subject: [opensource-dev] https://jira.secondlife.com/browse/SH-489 In-Reply-To: <201101081858.14793.Lance.Corrimal@eregion.de> References: <201101081858.14793.Lance.Corrimal@eregion.de> Message-ID: Can someone give a cheap estimate of how hard this will be to fix? if it is easy to fix, I agree that it should be done soon. Is there a cost/benefit analysis done when Sprints are prioritized? ponzu On Sat, Jan 8, 2011 at 12:58 PM, Lance Corrimal wrote: > Hi there, > > am I the only one who thinks that > https://jira.secondlife.com/browse/SH-489 should be rated a bit higher > than "minor, will be fixed in the distant future"? > > > 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/20110109/130d2082/attachment.htm From robertltux at gmail.com Sun Jan 9 09:21:41 2011 From: robertltux at gmail.com (Robert Martin) Date: Sun, 9 Jan 2011 12:21:41 -0500 Subject: [opensource-dev] https://jira.secondlife.com/browse/SH-489 In-Reply-To: References: <201101081858.14793.Lance.Corrimal@eregion.de> Message-ID: On Sun, Jan 9, 2011 at 10:09 AM, Ponzu wrote: > Can someone give a cheap estimate of how hard this will be to fix? > if it is easy to fix, I agree that it should be done soon. i would say that a full audit of the hover text submodule would be in order (say 4 hours of junior grade programmer??) -- Robert L Martin From Lance.Corrimal at eregion.de Sun Jan 9 09:30:16 2011 From: Lance.Corrimal at eregion.de (Lance Corrimal) Date: Sun, 9 Jan 2011 18:30:16 +0100 Subject: [opensource-dev] https://jira.secondlife.com/browse/SH-489 In-Reply-To: References: <201101081858.14793.Lance.Corrimal@eregion.de> Message-ID: <201101091830.16245.Lance.Corrimal@eregion.de> Am Sonntag, 9. Januar 2011 schrieb Robert Martin: > On Sun, Jan 9, 2011 at 10:09 AM, Ponzu wrote: > > Can someone give a cheap estimate of how hard this will be to > > fix? if it is easy to fix, I agree that it should be done soon. > > i would say that a full audit of the hover text submodule would be > in order (say 4 hours of junior grade programmer??) I'd say a udo of the changes since 2.1 is in order, it seems to be a regression... bye, LC From robertltux at gmail.com Sun Jan 9 09:40:40 2011 From: robertltux at gmail.com (Robert Martin) Date: Sun, 9 Jan 2011 12:40:40 -0500 Subject: [opensource-dev] Why no single axis resize on linked prims?? Message-ID: Does anybody know of a good reason why when you are resizing a set of linked prims you do not have the single axis resize?? (also could we get a way to resize a linkset with 0.001 meters as a floor not as a locking measurement?) -- Robert L Martin From kf6kjg at gmail.com Sun Jan 9 09:37:37 2011 From: kf6kjg at gmail.com (Ricky) Date: Sun, 9 Jan 2011 09:37:37 -0800 Subject: [opensource-dev] https://jira.secondlife.com/browse/SH-489 In-Reply-To: <201101091830.16245.Lance.Corrimal@eregion.de> References: <201101081858.14793.Lance.Corrimal@eregion.de> <201101091830.16245.Lance.Corrimal@eregion.de> Message-ID: I'm not sure it is a separate problem, or related, but I've been able to see people's voice dots for extreme distances (whenever they are >1px,) through any number of intervening prims. Even if the nametag is obscured, the voice dot comes through. Has given me quite the advantage in "hide-and-seek" style gameplay. Not sure when I first noticed this, and I haven't started any digging... Ricky On Sun, Jan 9, 2011 at 9:30 AM, Lance Corrimal wrote: > Am Sonntag, 9. Januar 2011 schrieb Robert Martin: >> On Sun, Jan 9, 2011 at 10:09 AM, Ponzu wrote: >> > Can someone give a cheap estimate of how hard this will be to >> > fix? if it is easy to fix, I agree that it should be done soon. >> >> ?i would say that a full audit of the hover text submodule would be >> in order (say 4 hours of junior grade programmer??) > > I'd say a udo of the changes since 2.1 is in order, it seems to be a > regression... > > 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 trilobyte550m at gmail.com Sun Jan 9 10:26:13 2011 From: trilobyte550m at gmail.com (Trilo Byte) Date: Sun, 9 Jan 2011 10:26:13 -0800 Subject: [opensource-dev] Why no single axis resize on linked prims?? In-Reply-To: References: Message-ID: As I understand it, there's no way to do it without breaking a lot of content. Vehicle wheels that are no longer round (or that fit into a wheel well), skirt pieces that when stretched in certain directions are no longer facing the right directions, etc. On Jan 9, 2011, at 9:40 AM, Robert Martin wrote: > Does anybody know of a good reason why when you are resizing a set of > linked prims you do not have the single axis resize?? > (also could we get a way to resize a linkset with 0.001 meters as a > floor not as a locking measurement?) > > -- > 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 From angel_of_crimson at hotmail.com Sun Jan 9 10:28:04 2011 From: angel_of_crimson at hotmail.com (Erin Mallory) Date: Sun, 9 Jan 2011 13:28:04 -0500 Subject: [opensource-dev] Why no single axis resize on linked prims?? In-Reply-To: References: Message-ID: As for the why, probably because it would be both hard to resize in only one direction or two directions without majorly distorting the linkset, and the number of usecases where it would be useful to only resize a linkset in one or two directions after finishing a build is probably fairly low. as for the second question, the .001 is already a floor. once a prim reaches that dimension the set cannot go further because at this time we don't have prim sizes any smaller without scripts. to change that would, I would be considerable effort for very little gain. Furthermore it doesn't "lock" an item it simply limits how much further it resizes down. Personally, rather then worry about this and the hovertext both of which are legacy behaviors, i'd far rather see the major snowstorm developers work on issues that affect usability and accessibility for much larger parts of the sl population, as well as much more destructive bugs. For example, I'd much rather see things like storm-526 addressed, or snow-423, or cts-337, or better appearance editors, or any of a whole list of bigger issues. > Date: Sun, 9 Jan 2011 12:40:40 -0500 > From: robertltux at gmail.com > To: opensource-dev at lists.secondlife.com > Subject: [opensource-dev] Why no single axis resize on linked prims?? > > Does anybody know of a good reason why when you are resizing a set of > linked prims you do not have the single axis resize?? > (also could we get a way to resize a linkset with 0.001 meters as a > floor not as a locking measurement?) > > -- > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110109/348fda98/attachment.htm From q at lindenlab.com Sun Jan 9 10:59:36 2011 From: q at lindenlab.com (Kent Quirk (Q Linden)) Date: Sun, 9 Jan 2011 13:59:36 -0500 Subject: [opensource-dev] storm-34 In-Reply-To: References: Message-ID: <9043BBD2-9063-4CC8-B34B-BBE7037D92BE@lindenlab.com> You can't see the private favorites before login, so you shouldn't expect to see the "favorite landmarks" setting during login. You can only see it after login. This is because you don't have a private prefs available until after login. Q On Jan 7, 2011, at 8:35 PM, Erin Mallory wrote: > I've been testing the storm 34 viewer on windows 7 and on windows xp. Ive noticed its not properly keeping the preferences between when youre logged in and logged out and that the favorites therefor are not properly showing up for me. this started occuring after i changed the account from my cummere to erinyse then back. now no matter what i cant get it to show the favorites for either account at log in even though both accounts have that box checked.... > > before i jira this, can anyone else repo? > _______________________________________________ > Policies 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/20110109/7f3cbac0/attachment-0001.htm From aleric.inglewood at gmail.com Sun Jan 9 16:21:36 2011 From: aleric.inglewood at gmail.com (Aleric Inglewood) Date: Mon, 10 Jan 2011 01:21:36 +0100 Subject: [opensource-dev] Why no single axis resize on linked prims?? In-Reply-To: References: Message-ID: And now for the real answer... You can't resize a prim along an arbitrary axis, so if any linked prim is rotated, it's simply not possible (in 99.9% of the cases). You might be able to pull it of for many special cases by changing sheer values, and use rotation (and texture rotation to correct for that) etc, but even then it only works in so many cases, never along any arbitrary axis for any arbirary prim shape. On Sun, Jan 9, 2011 at 6:40 PM, Robert Martin wrote: > Does anybody know of a good reason why when you are resizing a set of > linked prims you do not have the single axis resize?? > (also could we get a way to resize a linkset with 0.001 meters as a > floor not as a locking measurement?) > > -- > 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 > From angel_of_crimson at hotmail.com Mon Jan 10 05:58:17 2011 From: angel_of_crimson at hotmail.com (Erin Mallory) Date: Mon, 10 Jan 2011 08:58:17 -0500 Subject: [opensource-dev] storm-34 In-Reply-To: <9043BBD2-9063-4CC8-B34B-BBE7037D92BE@lindenlab.com> References: , <9043BBD2-9063-4CC8-B34B-BBE7037D92BE@lindenlab.com> Message-ID: I thought the whole point of storm-34 was to give you your favorites during the login under the start at location so you could login to your favorite locations? Subject: Re: [opensource-dev] storm-34 From: q at lindenlab.com Date: Sun, 9 Jan 2011 13:59:36 -0500 CC: opensource-dev at lists.secondlife.com To: angel_of_crimson at hotmail.com You can't see the private favorites before login, so you shouldn't expect to see the "favorite landmarks" setting during login. You can only see it after login. This is because you don't have a private prefs available until after login. Q On Jan 7, 2011, at 8:35 PM, Erin Mallory wrote:I've been testing the storm 34 viewer on windows 7 and on windows xp. Ive noticed its not properly keeping the preferences between when youre logged in and logged out and that the favorites therefor are not properly showing up for me. this started occuring after i changed the account from my cummere to erinyse then back. now no matter what i cant get it to show the favorites for either account at log in even though both accounts have that box checked.... before i jira this, can anyone else repo? _______________________________________________ Policies 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/20110110/e0168f62/attachment.htm From opensourceobscure at gmail.com Mon Jan 10 06:32:27 2011 From: opensourceobscure at gmail.com (Opensource Obscure) Date: Mon, 10 Jan 2011 15:32:27 +0100 Subject: [opensource-dev] storm-34 In-Reply-To: <9043BBD2-9063-4CC8-B34B-BBE7037D92BE@lindenlab.com> References: <9043BBD2-9063-4CC8-B34B-BBE7037D92BE@lindenlab.com> Message-ID: What about a list of non-private, non-asset SLURLs that users can set while logged off? They would be shown *before* login, so that users can directly go there - avoiding additional in-world teleports. On shared computers, this could be disabled. Actually, in some cases people using the same shared computer could still enable it, and arrange a list of commons locations to show. It could work like this: 1a. while still logged off, go to Preferences and enable the feature. 1b. paste SLURLs in a dedicated field. 2. at next login, those SLURLs are parsed and shown in the current drop-down, in addition to the existing locations (home & last location) 3. choose a location and log in A completely different approach could be: embed SL map in the login screen and let people use it to choose a location where to log in. But I digress. Opensource Obscure On Sun, Jan 9, 2011 at 19:59, Kent Quirk (Q Linden) wrote: > You can't see the private favorites before login, so you shouldn't expect to > see the "favorite landmarks" setting during login. You can only see it after > login. This is because you don't have a private prefs available until after > login. > ?? ?Q > On Jan 7, 2011, at 8:35 PM, Erin Mallory wrote: > > I've been testing the storm 34 viewer on windows 7 and on windows xp.? Ive > noticed its not properly keeping the preferences between when youre logged > in and logged out and that the favorites therefor are not properly showing > up for me. this started occuring after i changed the account from my cummere > to erinyse then back.? now no matter what i cant get it to show the > favorites for either account at log in even though both accounts have that > box checked.... > > before i jira this, can anyone else repo? > one.JPG>_______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting > privileges > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting > privileges > -- Opensource Obscure Twitter?[EN] -?Twitter?[IT] -?Blog?[IT] -?YouTube?-?Photos?-?Second Life From adyukov at productengine.com Mon Jan 10 06:39:32 2011 From: adyukov at productengine.com (Andrew Dyukov) Date: Mon, 10 Jan 2011 16:39:32 +0200 Subject: [opensource-dev] storm-34 In-Reply-To: References: <9043BBD2-9063-4CC8-B34B-BBE7037D92BE@lindenlab.com> Message-ID: Yes, it was the point of the task and it works this way - you can see the list of your favorites in login screen if you allowed them to be shown beforehand (while being logged in). You can't change the preference before login because viewer wouldn't know whose preferences to change in this case, and even if it could it would be bad from privacy perspective. 2011/1/10 Erin Mallory : > I thought the whole point of storm-34 was to give you your favorites during > the login under the start at location so you could login to your favorite > locations? > > ________________________________ > Subject: Re: [opensource-dev] storm-34 > From: q at lindenlab.com > Date: Sun, 9 Jan 2011 13:59:36 -0500 > CC: opensource-dev at lists.secondlife.com > To: angel_of_crimson at hotmail.com > > You can't see the private favorites before login, so you shouldn't expect to > see the "favorite landmarks" setting during login. You can only see it after > login. This is because you don't have a private prefs available until after > login. > ?? ?Q > On Jan 7, 2011, at 8:35 PM, Erin Mallory wrote: > > I've been testing the storm 34 viewer on windows 7 and on windows xp.? Ive > noticed its not properly keeping the preferences between when youre logged > in and logged out and that the favorites therefor are not properly showing > up for me. this started occuring after i changed the account from my cummere > to erinyse then back.? now no matter what i cant get it to show the > favorites for either account at log in even though both accounts have that > box checked.... > > before i jira this, can anyone else repo? > one.JPG>_______________________________________________ > Policies 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 Jan 10 06:43:51 2011 From: Lance.Corrimal at eregion.de (Lance Corrimal) Date: Mon, 10 Jan 2011 15:43:51 +0100 Subject: [opensource-dev] storm-34 In-Reply-To: References: <9043BBD2-9063-4CC8-B34B-BBE7037D92BE@lindenlab.com> Message-ID: <201101101543.51330.Lance.Corrimal@eregion.de> > 1a. while still logged off, go to Preferences and enable the feature. > 1b. paste SLURLs in a dedicated field. > > 2. at next login, those SLURLs are parsed and shown in the current > drop-down, in addition to the existing locations (home & last location) > > 3. choose a location and log in voted. it could even be two lists, one in the global app_settings folder that could be populated (and read-only), and for example on the official LL client it would have slurls to infohubs or orientation islands, while a TPV dev could populate that with slurls to places that might be of special interest for users of that TPV... in case of my dolphin viewer i'd put slurls to vehicle rez areas in it, for example. bye, LC From angel_of_crimson at hotmail.com Mon Jan 10 07:25:14 2011 From: angel_of_crimson at hotmail.com (Erin Mallory) Date: Mon, 10 Jan 2011 10:25:14 -0500 Subject: [opensource-dev] storm-34 In-Reply-To: References: , <9043BBD2-9063-4CC8-B34B-BBE7037D92BE@lindenlab.com>, , Message-ID: The point is I did NOT change the preferences before hand. I logged in set the prefrences and logged out, and STILL do not see them showing up the way they should. > Date: Mon, 10 Jan 2011 16:39:32 +0200 > Subject: Re: [opensource-dev] storm-34 > From: adyukov at productengine.com > To: angel_of_crimson at hotmail.com > CC: q at lindenlab.com; opensource-dev at lists.secondlife.com > > Yes, it was the point of the task and it works this way - you can see > the list of your favorites in login screen if you allowed them to be > shown beforehand (while being logged in). You can't change the > preference before login because viewer wouldn't know whose preferences > to change in this case, and even if it could it would be bad from > privacy perspective. > > 2011/1/10 Erin Mallory : > > I thought the whole point of storm-34 was to give you your favorites during > > the login under the start at location so you could login to your favorite > > locations? > > > > ________________________________ > > Subject: Re: [opensource-dev] storm-34 > > From: q at lindenlab.com > > Date: Sun, 9 Jan 2011 13:59:36 -0500 > > CC: opensource-dev at lists.secondlife.com > > To: angel_of_crimson at hotmail.com > > > > You can't see the private favorites before login, so you shouldn't expect to > > see the "favorite landmarks" setting during login. You can only see it after > > login. This is because you don't have a private prefs available until after > > login. > > Q > > On Jan 7, 2011, at 8:35 PM, Erin Mallory wrote: > > > > I've been testing the storm 34 viewer on windows 7 and on windows xp. Ive > > noticed its not properly keeping the preferences between when youre logged > > in and logged out and that the favorites therefor are not properly showing > > up for me. this started occuring after i changed the account from my cummere > > to erinyse then back. now no matter what i cant get it to show the > > favorites for either account at log in even though both accounts have that > > box checked.... > > > > before i jira this, can anyone else repo? > > > one.JPG>_______________________________________________ > > Policies 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/20110110/7f9dbf58/attachment.htm From adyukov at productengine.com Mon Jan 10 07:31:36 2011 From: adyukov at productengine.com (Andrew Dyukov) Date: Mon, 10 Jan 2011 17:31:36 +0200 Subject: [opensource-dev] storm-34 In-Reply-To: References: <9043BBD2-9063-4CC8-B34B-BBE7037D92BE@lindenlab.com> Message-ID: If you enabled the preference for your account after login, and quit viewer correctly (i.e. it didn't crash), favorites should show up in "Start at" when your username is entered. Please write more detailed the steps to reproduce the problem. 2011/1/10 Erin Mallory : > The point is I did NOT change the preferences before hand.? I logged in set > the prefrences and logged out, and STILL do not see them showing up the way > they should. > >> Date: Mon, 10 Jan 2011 16:39:32 +0200 >> Subject: Re: [opensource-dev] storm-34 >> From: adyukov at productengine.com >> To: angel_of_crimson at hotmail.com >> CC: q at lindenlab.com; opensource-dev at lists.secondlife.com >> >> Yes, it was the point of the task and it works this way - you can see >> the list of your favorites in login screen if you allowed them to be >> shown beforehand (while being logged in). You can't change the >> preference before login because viewer wouldn't know whose preferences >> to change in this case, and even if it could it would be bad from >> privacy perspective. >> >> 2011/1/10 Erin Mallory : >> > I thought the whole point of storm-34 was to give you your favorites >> > during >> > the login under the start at location so you could login to your >> > favorite >> > locations? >> > >> > ________________________________ >> > Subject: Re: [opensource-dev] storm-34 >> > From: q at lindenlab.com >> > Date: Sun, 9 Jan 2011 13:59:36 -0500 >> > CC: opensource-dev at lists.secondlife.com >> > To: angel_of_crimson at hotmail.com >> > >> > You can't see the private favorites before login, so you shouldn't >> > expect to >> > see the "favorite landmarks" setting during login. You can only see it >> > after >> > login. This is because you don't have a private prefs available until >> > after >> > login. >> > ?? ?Q >> > On Jan 7, 2011, at 8:35 PM, Erin Mallory wrote: >> > >> > I've been testing the storm 34 viewer on windows 7 and on windows xp. >> > Ive >> > noticed its not properly keeping the preferences between when youre >> > logged >> > in and logged out and that the favorites therefor are not properly >> > showing >> > up for me. this started occuring after i changed the account from my >> > cummere >> > to erinyse then back.? now no matter what i cant get it to show the >> > favorites for either account at log in even though both accounts have >> > that >> > box checked.... >> > >> > before i jira this, can anyone else repo? >> > > > one.JPG>_______________________________________________ >> > Policies 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 Jan 10 08:34:08 2011 From: lee.ponzu at gmail.com (Ponzu) Date: Mon, 10 Jan 2011 11:34:08 -0500 Subject: [opensource-dev] Review Request: VWR-24420: PNG images which specify "background color" lose alpha layer when imported. In-Reply-To: <20110109145917.7202.23064@domU-12-31-38-00-90-68.compute-1.internal> References: <20110109145917.7202.23064@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: A common cause of z-buffer problems in SL is textures that do not *need* an alpha channel that contain one anyway. Lots of content in SL is created by rank amateurs (me for example). What if the upload dialog had a check box? [ ] This texture should have an alpha channel. If the box is not checked, the alpha channel is removed. If it is checked, it is retained, unless it is not there, in which case the user gets an error message. Just thinking out loud. ponzu On Sun, Jan 9, 2011 at 9:59 AM, Thickbrick Sleaford < thickbrick.sleaford at gmail.com> wrote: > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/74/ > Review request for Viewer. > By Thickbrick Sleaford. > Description > > Current code composites RGBA PNG images that contain a bKGD chunk down to RGB, discarding the alpha channel. This patch removes that code, since it contradicts purpose of the bKGD chunk as described in the PNG spec and as commonly used. > > Testing > > Tested uploading the 2 images attached to VWR-24420 with and without the patch. Before patch, "bad alpha.png" was uploaded as RGB, after patch, both images were uploaded as RGBA. > > *Bugs: * VWR-24420 > Diffs > > - doc/contributions.txt (UNKNOWN) > - indra/llimage/llpngwrapper.h (UNKNOWN) > - indra/llimage/llpngwrapper.cpp (UNKNOWN) > > View Diff > > _______________________________________________ > Policies 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/20110110/27c062c9/attachment.htm From angel_of_crimson at hotmail.com Mon Jan 10 08:38:23 2011 From: angel_of_crimson at hotmail.com (Erin Mallory) Date: Mon, 10 Jan 2011 11:38:23 -0500 Subject: [opensource-dev] storm-34 In-Reply-To: References: , <9043BBD2-9063-4CC8-B34B-BBE7037D92BE@lindenlab.com>, , , , Message-ID: what happened to get the issue to occur for me. I installed the storm-34 developer viewer. logged in with cummere mayo. set the option to show the favorites. logged out. started the viewer. it worked as expected. logged out. back in. still worked as expected. logged out. changed account to erinyse planer. logged in. logged back out. started viewer. favorites were not there (as expected) changed account back to cummere mayo. logged in. made sure preference was still on. (it was) logged out. restarted the viewer: favorites no longer show up. have tried reseeting the preference while logged in multiple times. didnt fix it. have tried reinstalling the viewer. worked great till i logged in an account and didnt set the preferences. NOTE: even enabling the preference on the erinyse account and logging out then switching logging in cummere mayo and logging off still doesnt allow it to work. Im not sure if soemthing is corrupting the prefences file or what... which is why im asking if others can repo this? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110110/5250ed1f/attachment.htm From adyukov at productengine.com Mon Jan 10 08:56:13 2011 From: adyukov at productengine.com (Andrew Dyukov) Date: Mon, 10 Jan 2011 18:56:13 +0200 Subject: [opensource-dev] storm-34 In-Reply-To: References: <9043BBD2-9063-4CC8-B34B-BBE7037D92BE@lindenlab.com> Message-ID: The preference is per-account, .i.e. you should turn it on separately for each user whose favorites you want to be shown in login screen. So to get favorites for both cummere and erinyse you should: 1. log in with cummere mayo. set the option to show the favorites. log out. 2. start the viewer. log in with erinyse planer. set the option to show the favorites. log out. On the next start of the viewer favorites will be available for both users. 2011/1/10 Erin Mallory : > what happened to get the issue to occur for me.? I installed the storm-34 > developer viewer.? logged in with cummere mayo.? set the option to show the > favorites.? logged out.?? started the viewer.? it worked as expected. logged > out.? back in. still worked as expected.? logged out. > changed account to erinyse planer.?? logged in.? logged back out.?? started > viewer.?? favorites were not there (as expected)? changed account back to > cummere mayo.? logged in.? made sure preference was still on.? (it was) > logged out. restarted the viewer: favorites no longer show up. > > have tried reseeting the preference while logged in multiple times.? didnt > fix it. have tried reinstalling the viewer.? worked great till i logged in > an account and didnt set the preferences.?? NOTE: even enabling the > preference on the erinyse account and logging out then switching logging in > cummere mayo and logging off still doesnt allow it to work.? Im not sure if > soemthing is corrupting the prefences file or what...? which is why im > asking if others can repo this? > From dave at meadowlakearts.com Mon Jan 10 09:28:20 2011 From: dave at meadowlakearts.com (Dave Booth) Date: Mon, 10 Jan 2011 11:28:20 -0600 Subject: [opensource-dev] Review Request: VWR-24420: PNG images which specify "background color" lose alpha layer when imported. In-Reply-To: References: <20110109145917.7202.23064@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <4D2B41B4.6040208@meadowlakearts.com> Thats a pretty good bit of thinking out loud there, Ponzu.... Personally I'd say thats a "clean" fix for this. However it all depends on how things are stored server-side - if the asset server code automatically assumes that every texture has an alpha channel and supplies a "solid" one for those where the upload doesnt provide one, any benefit of specifying at upload time is moot. On 1/10/2011 10:34, Ponzu wrote: > A common cause of z-buffer problems in SL is textures that do not > *need* an alpha channel that contain one anyway. Lots of content in > SL is created by rank amateurs (me for example). > > What if the upload dialog had a check box? > > [ ] This texture should have an alpha channel. > > If the box is not checked, the alpha channel is removed. If it is > checked, it is retained, unless it is not there, in which case the > user gets an error message. > > Just thinking out loud. > > ponzu > > On Sun, Jan 9, 2011 at 9:59 AM, Thickbrick Sleaford > > > wrote: > > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/74/ > > > Review request for Viewer. > By Thickbrick Sleaford. > > > Description > > Current code composites RGBA PNG images that contain a bKGD chunk down to RGB, discarding the alpha channel. This patch removes that code, since it contradicts purpose of the bKGD chunk as described in the PNG spec and as commonly used. > > > Testing > > Tested uploading the 2 images attached to VWR-24420 with and without the patch. Before patch, "bad alpha.png" was uploaded as RGB, after patch, both images were uploaded as RGBA. > > *Bugs: * VWR-24420 > > > Diffs > > * doc/contributions.txt (UNKNOWN) > * indra/llimage/llpngwrapper.h (UNKNOWN) > * indra/llimage/llpngwrapper.cpp (UNKNOWN) > > View Diff > > > _______________________________________________ > Policies 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 Mon Jan 10 10:05:11 2011 From: angel_of_crimson at hotmail.com (Erin Mallory) Date: Mon, 10 Jan 2011 13:05:11 -0500 Subject: [opensource-dev] storm-34 In-Reply-To: References: , <9043BBD2-9063-4CC8-B34B-BBE7037D92BE@lindenlab.com>, , , , , , Message-ID: I knwo it should be... but its not! > Date: Mon, 10 Jan 2011 18:56:13 +0200 > Subject: Re: [opensource-dev] storm-34 > From: adyukov at productengine.com > To: angel_of_crimson at hotmail.com > CC: q at lindenlab.com; opensource-dev at lists.secondlife.com > > The preference is per-account, .i.e. you should turn it on separately > for each user whose favorites you want to be shown in login screen. So > to get favorites for both cummere and erinyse you should: > > 1. log in with cummere mayo. set the option to show the favorites. log out. > 2. start the viewer. log in with erinyse planer. set the option to > show the favorites. log out. > > On the next start of the viewer favorites will be available for both users. > > 2011/1/10 Erin Mallory : > > what happened to get the issue to occur for me. I installed the storm-34 > > developer viewer. logged in with cummere mayo. set the option to show the > > favorites. logged out. started the viewer. it worked as expected. logged > > out. back in. still worked as expected. logged out. > > changed account to erinyse planer. logged in. logged back out. started > > viewer. favorites were not there (as expected) changed account back to > > cummere mayo. logged in. made sure preference was still on. (it was) > > logged out. restarted the viewer: favorites no longer show up. > > > > have tried reseeting the preference while logged in multiple times. didnt > > fix it. have tried reinstalling the viewer. worked great till i logged in > > an account and didnt set the preferences. NOTE: even enabling the > > preference on the erinyse account and logging out then switching logging in > > cummere mayo and logging off still doesnt allow it to work. Im not sure if > > soemthing is corrupting the prefences file or what... which is why im > > asking if others can repo this? > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110110/a26d1f9e/attachment.htm From josh at lindenlab.com Mon Jan 10 10:28:22 2011 From: josh at lindenlab.com (Joshua Linden) Date: Mon, 10 Jan 2011 18:28:22 -0000 Subject: [opensource-dev] Review Request: Show TOS (and other login dialogs) if --login is specified Message-ID: <20110110182822.7014.45882@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/76/ ----------------------------------------------------------- Review request for Viewer. Summary ------- This simply removes the mUserInteraction logic from LLLoginInstance, which is not used other than in this behavior. Internal discussion indicates that the current behavior is undesirable and is not being relied upon by test automation, and in fact interferes with test automation. Prior to this change, if the viewer is launched with: SecondLife.exe --login FIRST LAST PASSWORD ... and if the login response is that a TOS, Critical Message, or Update must be acknowledged, the viewer simply returns to the credentials screen (login panel) but does not indicate why. After this change, the viewer will display the appropriate follow-on UI even if --login is used. If necessary, an additional option could be specified to inhibit showing these UI elements for test automation scenarios (e.g. auto-accepting or exiting the viewer, as appropriate). (the bulk of the raw diff is whitespace changes due to re-indentation) This addresses bug VWR-24401. http://jira.secondlife.com/browse/VWR-24401 Diffs ----- indra/newview/lllogininstance.h 78fae8ca1b36 indra/newview/lllogininstance.cpp 78fae8ca1b36 indra/newview/llstartup.cpp 78fae8ca1b36 Diff: http://codereview.secondlife.com/r/76/diff Testing ------- Launched viewer normally (with "normal" account), entered credentials, logged in successfully. Launched viewer via --login (with "normal" account), logged in successfully. Launched viewer via --login with account needing to accept TOS update; viewer displayed TOS dialog; accepted and logged in successfully. Thanks, Joshua -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110110/84d7262a/attachment-0001.htm From josh at lindenlab.com Mon Jan 10 10:57:56 2011 From: josh at lindenlab.com (Joshua Bell) Date: Mon, 10 Jan 2011 10:57:56 -0800 Subject: [opensource-dev] Review Request: VWR-24420: PNG images which specify "background color" lose alpha layer when imported. In-Reply-To: References: <20110109145917.7202.23064@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: On Mon, Jan 10, 2011 at 8:34 AM, Ponzu wrote: > A common cause of z-buffer problems in SL is textures that do not *need* an > alpha channel that contain one anyway. Lots of content in SL is created by > rank amateurs (me for example). > > That seems like a good point, and might explain the existence of the code (although I'm just responding to the thread here, not as a domain expert). > What if the upload dialog had a check box? > > [ ] This texture should have an alpha channel. > > If the box is not checked, the alpha channel is removed. If it is checked, > it is retained, unless it is not there, in which case the user gets an error > message. > > Without digging more deeply into the issue, but putting on my UI design hat, if it's necessary to ask the user I'd suggest the wording: [x] Preserve transparency (alpha channel) The wording "This texture should have an alpha channel" seems like it could lead to users thinking "hey, sure, why not, sounds like a good idea" and checking it. If the image does not have an alpha channel, remove or disable the checkbox from the UI. Then there's the question of whether or not the box should be checked by default or not. Ponzu's point is compelling that the current behavior is implicitly desired by many content creators to avoid problems ("I uploaded a new texture and it's rendering differently than the textures I uploaded last week! SL sucks!"). Which would mean that this could default to unchecked (i.e. current behavior) but be exposed for users who know what's going on and would let them toggle it live with the preview. (Again, just speculating here as well, I haven't dug into the code.) -- Josh -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110110/b583a8bd/attachment.htm From tinacloud at gmx.de Mon Jan 10 11:03:30 2011 From: tinacloud at gmx.de (Zi Ree) Date: Mon, 10 Jan 2011 20:03:30 +0100 Subject: [opensource-dev] Review Request: VWR-24420: PNG images which specify "background color" lose alpha layer when imported. In-Reply-To: References: <20110109145917.7202.23064@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <201101102003.30338.tinacloud@gmx.de> Am Montag 10 Januar 2011 17:34:08 schrieb Ponzu: > What if the upload dialog had a check box? > > [ ] This texture should have an alpha channel. Would it be possible to do this on a per-face basis rather than on texture upload? So people could use the same texture as alpha texture and as non-alpha as well? Edit Texture [x] Use Alpha Thinking out loud ... Zi From josh at lindenlab.com Mon Jan 10 11:05:45 2011 From: josh at lindenlab.com (Joshua Bell) Date: Mon, 10 Jan 2011 11:05:45 -0800 Subject: [opensource-dev] Review Request: VWR-24420: PNG images which specify "background color" lose alpha layer when imported. In-Reply-To: <4D2B41B4.6040208@meadowlakearts.com> References: <20110109145917.7202.23064@domU-12-31-38-00-90-68.compute-1.internal> <4D2B41B4.6040208@meadowlakearts.com> Message-ID: On Mon, Jan 10, 2011 at 9:28 AM, Dave Booth wrote: > Thats a pretty good bit of thinking out loud there, Ponzu.... > > Personally I'd say thats a "clean" fix for this. However it all depends > on how things are stored server-side - if the asset server code > automatically assumes that every texture has an alpha channel and > supplies a "solid" one for those where the upload doesnt provide one, > any benefit of specifying at upload time is moot. The asset upload/storage system handles 3, 4 or 5 channel JPEG2000 textures and doesn't tinker with the channel data. The bulk of the textures in the asset system are 3-channel (RGB). (Excellent question, BTW.) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110110/d2a1e0c1/attachment.htm From q at lindenlab.com Mon Jan 10 11:26:02 2011 From: q at lindenlab.com (Kent Quirk) Date: Mon, 10 Jan 2011 19:26:02 -0000 Subject: [opensource-dev] Review Request: STORM-830 Volume slider isn't properly remembered if set to zero In-Reply-To: <20110107013717.27619.98439@domU-12-31-38-00-90-68.compute-1.internal> References: <20110107013717.27619.98439@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110110192602.6850.59459@domU-12-31-38-00-90-68.compute-1.internal> > On Jan. 6, 2011, 5:37 p.m., Aleric Inglewood wrote: > > This is really not how you want to deal with this bug :/. It's a known fact that audio mixers are very bad with low volumes. Setting a volume to 0 (or something really small) can put a very high load on the CPU for the audio mixer, which causes severe problems. See https://jira.secondlife.com/browse/VWR-14914 > > > > So, on the contrary (as VWR-14914 fixed a horrible bug that made FPS drop drastically): when the volume is set to 0 (or even close to zero) the audio channel has to be muted and not mixed, ever. Assuming that VWR-14914 is in Viewer 2, and wasn't broken in the meantime, a volume of 0 would cause the channel to be muted, but setting it to 0.000001 will not cause it to be muted, but result in a high CPU load. > > > > Aleric Inglewood wrote: > After discussion on IRC Jonathan explained to me what this is all about. The patch is correct. > Nevertheless, I was confused about the fact that this value of 0.000001 is never going to be USED. > Perhaps a different value and comment can avoid that in the future when other coders look at it. > mInternalGain is only ever compared with, and the whole point of this patch is to make sure > that the first comparison fails (I now understand). A common value used to make sure that > a first comparison fails is a value outside the valid range of that variable. The valid > range being [0, 1], I'd suggest using -1 and adding a comment in the lines of: > > // Make sure that the first call to setMasterGain will cause setInternalGain to be called. > mInternalGain = -1.f; > Aleric is correct, and if the approach is technically possible it would be preferred to use an out-of-range value. It appears to me that his suggested fix will work, but I haven't tried it myself. Jonathan, can you try it, please? - Kent ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/72/#review128 ----------------------------------------------------------- On Jan. 6, 2011, 2:37 p.m., Jonathan Yap wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/72/ > ----------------------------------------------------------- > > (Updated Jan. 6, 2011, 2:37 p.m.) > > > Review request for Viewer. > > > Summary > ------- > > There is an edge case in setMasterGain during startup which prevents setInternalGain from being called if the master volume setting and mInternalGain both equal 0. > > Setting mInternalGain to a very low but non-zero value fixes this issue. > > > This addresses bug STORM-830. > http://jira.secondlife.com/browse/STORM-830 > > > Diffs > ----- > > indra/llaudio/llaudioengine.cpp 6d44f0d85a80 > > Diff: http://codereview.secondlife.com/r/72/diff > > > Testing > ------- > > In Preferences / Sound & Media tested: > Buttons > Ambient > Sound Effects > Stream Music > Media > Voice Chat > > > Thanks, > > Jonathan > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110110/1fa302ac/attachment.htm From kf6kjg at gmail.com Mon Jan 10 11:47:53 2011 From: kf6kjg at gmail.com (Ricky) Date: Mon, 10 Jan 2011 11:47:53 -0800 Subject: [opensource-dev] 5 Channel JPEG2000 Message-ID: Question: what, if anything, is the 5th channel currently used for? Could it be used for normal maps if it is currently unused? If so, then we could do this entirely clientside, assuming 5 channel textures can be uploaded. Of course there would still need to be a way to disable the alpha channel during upload while preserving the normal map channel. Ricky Cron Stardust On Monday, January 10, 2011, Joshua Bell wrote: > On Mon, Jan 10, 2011 at 9:28 AM, Dave Booth wrote: > > Thats a pretty good bit of thinking out loud there, Ponzu.... > > Personally I'd say thats a "clean" fix for this. However it all depends > on how things are stored server-side - if the asset server code > automatically assumes that every texture has an alpha channel and > supplies a "solid" one for those where the upload doesnt provide one, > any benefit of specifying at upload time is moot. > The asset upload/storage system handles 3, 4 or 5 channel JPEG2000 textures and doesn't tinker with the channel data. The bulk of the textures in the asset system are 3-channel (RGB). > > (Excellent question, BTW.) > > From akanevsky at productengine.com Mon Jan 10 12:27:43 2011 From: akanevsky at productengine.com (Anya Kanevsky) Date: Mon, 10 Jan 2011 14:27:43 -0600 Subject: [opensource-dev] Daily Scrum Summary - Monday, January 10, 2011 Message-ID: Monday, January 10, 2011 General Notes ------------------------------ - Reminder to devs. If a ticket doesn't pass Review and is rejected, it will move back to the To Do column in GH, if you do more work or clarify questions, it should be moved back through In Progress and then to In Review. - MMOTD: Merov - PE was on holiday Friday. Team Status ------------------------------ Merov Linden ------------------------------ *PAST* - STORM-526 : Log out failure during Login causes loss of pending offers, including inventory : Look at that code, can't repro but pointed at potential issues, commented in JIRA - Cleaned-up sprint 9 stuff *FUTURE* - sprint planning - STORM-745 : Produce comprehensive perf baseline: Complete that work. *IMPEDIMENTS* - None Oz Linden ------------------------------ *PAST* - Merge Monkey (up to 2.5.0-start tag), handed off to Merov - More looking at old VWR patches - Tracking down viewer dependencies - OH *FUTURE* - Sprint planning - More VWR mining *IMPEDIMENTS* - none Q Linden ------------------------------ *PAST* - LL Planning meeting - STORM-34 - STORM-777 - SOCIAL-437 / VWR-24440 - STORM-830 - Blog post *FUTURE* - STORM-830 - Sprint planning - Triage *IMPEDIMENTS* - none Esbee Linden ------------------------------ *PAST* - HR stuff - Meetings, Email - Wrote Viewer 2.5 Beta 1 blog post - Played with Beta *FUTURE* - Meetings - Sprint Planning - Rev Viewer 2.5 Beta 1 Blog post - Review Snowstorm Team product backlog and bug log - PO reviews for open tickets - Finish going through the list of VWRs assigned to PE (finally) - Plan update for system requirements - Look at VWR-18435 and VWR-24357 for Jonathan - Add instructions for STORM-236 for Wolfpup - Look at STORM-383, -797, -28, -447 *IMPEDIMENTS* - none Paul ProductEngine ------------------------------ *PAST* - STORM-370 (Human-readable name of region disappears from Location Bar after pressing ESC) - Fixed and sent for review *FUTURE* - STORM-387 (Part of the table is hidden after increasing firsts column width in the floater and then dock it to the SP) - STORM-554 (NL - text overlapping in Build tools) - -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110110/14f73b04/attachment.htm From josh at lindenlab.com Mon Jan 10 13:18:42 2011 From: josh at lindenlab.com (Joshua Bell) Date: Mon, 10 Jan 2011 13:18:42 -0800 Subject: [opensource-dev] 5 Channel JPEG2000 In-Reply-To: References: Message-ID: On Mon, Jan 10, 2011 at 11:47 AM, Ricky wrote: > Question: what, if anything, is the 5th channel currently used for? > Bump maps in baked textures. IIRC, only the avatar pipeline produces/consumes that channel. Also, IIRC, the logic is entirely client-side at the moment. > Could it be used for normal maps if it is currently unused? > If so, then we could do this entirely clientside, assuming 5 channel > textures can be uploaded. Of course there would still need to be a > way to disable the alpha channel during upload while preserving the > normal map channel. > That would technically be possible. The asset system does do verification and modification of various asset types on upload (including textures), but - again, technically - this would probably work, possibly requiring some minor changes to the asset verifier. However... The biggest challenge is the lack of support for multiple channels in JPEG2000-producing/consuming tools. Many tools only work with 3-channel images, and complain about 4. Combined with the lack of tools for authoring JPEG2000 images in the first place, I'm not sure you'd want add another 3 channels to the image for the normal map. It would also mean you couldn't re-use a normal map with two textures, e.g. to allow color variants on a base mesh. Avoiding two separate texture asset fetches (colors and normals) per face might be a significant win, but I'd want to see the numbers to prove it first. (For comparison, the 13-channel RAW data used for uploading/downloading region terrain and parcel data is pretty pesky to work with. Sure, it works with PhotoShop, and is a technically simple single file backup format, but putting all of that data into a single image is fragile that you expect users to edit is not particularly user-friendly.) > Ricky > Cron Stardust > > On Monday, January 10, 2011, Joshua Bell wrote: > > On Mon, Jan 10, 2011 at 9:28 AM, Dave Booth > wrote: > > > > Thats a pretty good bit of thinking out loud there, Ponzu.... > > > > Personally I'd say thats a "clean" fix for this. However it all depends > > on how things are stored server-side - if the asset server code > > automatically assumes that every texture has an alpha channel and > > supplies a "solid" one for those where the upload doesnt provide one, > > any benefit of specifying at upload time is moot. > > The asset upload/storage system handles 3, 4 or 5 channel JPEG2000 > textures and doesn't tinker with the channel data. The bulk of the textures > in the asset system are 3-channel (RGB). > > > > (Excellent question, BTW.) > > > > > _______________________________________________ > Policies 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/20110110/41eb13e6/attachment-0001.htm From jhwelch at gmail.com Mon Jan 10 14:23:25 2011 From: jhwelch at gmail.com (Jonathan Yap) Date: Mon, 10 Jan 2011 22:23:25 -0000 Subject: [opensource-dev] Review Request: STORM-830 Volume slider isn't properly remembered if set to zero In-Reply-To: <20110107013717.27619.98439@domU-12-31-38-00-90-68.compute-1.internal> References: <20110107013717.27619.98439@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110110222325.6851.23708@domU-12-31-38-00-90-68.compute-1.internal> > On Jan. 6, 2011, 5:37 p.m., Aleric Inglewood wrote: > > This is really not how you want to deal with this bug :/. It's a known fact that audio mixers are very bad with low volumes. Setting a volume to 0 (or something really small) can put a very high load on the CPU for the audio mixer, which causes severe problems. See https://jira.secondlife.com/browse/VWR-14914 > > > > So, on the contrary (as VWR-14914 fixed a horrible bug that made FPS drop drastically): when the volume is set to 0 (or even close to zero) the audio channel has to be muted and not mixed, ever. Assuming that VWR-14914 is in Viewer 2, and wasn't broken in the meantime, a volume of 0 would cause the channel to be muted, but setting it to 0.000001 will not cause it to be muted, but result in a high CPU load. > > > > Aleric Inglewood wrote: > After discussion on IRC Jonathan explained to me what this is all about. The patch is correct. > Nevertheless, I was confused about the fact that this value of 0.000001 is never going to be USED. > Perhaps a different value and comment can avoid that in the future when other coders look at it. > mInternalGain is only ever compared with, and the whole point of this patch is to make sure > that the first comparison fails (I now understand). A common value used to make sure that > a first comparison fails is a value outside the valid range of that variable. The valid > range being [0, 1], I'd suggest using -1 and adding a comment in the lines of: > > // Make sure that the first call to setMasterGain will cause setInternalGain to be called. > mInternalGain = -1.f; > > > Kent Quirk wrote: > Aleric is correct, and if the approach is technically possible it would be preferred to use an out-of-range value. It appears to me that his suggested fix will work, but I haven't tried it myself. Jonathan, can you try it, please? > I changed the initial value of mInternalGain to -1, did a quick test with key clicks, and saw that that fixes the problem, too. - Jonathan ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/72/#review128 ----------------------------------------------------------- On Jan. 6, 2011, 2:37 p.m., Jonathan Yap wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/72/ > ----------------------------------------------------------- > > (Updated Jan. 6, 2011, 2:37 p.m.) > > > Review request for Viewer. > > > Summary > ------- > > There is an edge case in setMasterGain during startup which prevents setInternalGain from being called if the master volume setting and mInternalGain both equal 0. > > Setting mInternalGain to a very low but non-zero value fixes this issue. > > > This addresses bug STORM-830. > http://jira.secondlife.com/browse/STORM-830 > > > Diffs > ----- > > indra/llaudio/llaudioengine.cpp 6d44f0d85a80 > > Diff: http://codereview.secondlife.com/r/72/diff > > > Testing > ------- > > In Preferences / Sound & Media tested: > Buttons > Ambient > Sound Effects > Stream Music > Media > Voice Chat > > > Thanks, > > Jonathan > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110110/4e9d220c/attachment.htm From q at lindenlab.com Mon Jan 10 15:15:08 2011 From: q at lindenlab.com (Kent Quirk) Date: Mon, 10 Jan 2011 23:15:08 -0000 Subject: [opensource-dev] Review Request: STORM-830 Volume slider isn't properly remembered if set to zero In-Reply-To: <20110106223706.27616.47963@domU-12-31-38-00-90-68.compute-1.internal> References: <20110106223706.27616.47963@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110110231508.7014.59434@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/72/#review139 ----------------------------------------------------------- Ship it! Looks good now. - Kent On Jan. 6, 2011, 2:37 p.m., Jonathan Yap wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/72/ > ----------------------------------------------------------- > > (Updated Jan. 6, 2011, 2:37 p.m.) > > > Review request for Viewer. > > > Summary > ------- > > There is an edge case in setMasterGain during startup which prevents setInternalGain from being called if the master volume setting and mInternalGain both equal 0. > > Setting mInternalGain to a very low but non-zero value fixes this issue. > > > This addresses bug STORM-830. > http://jira.secondlife.com/browse/STORM-830 > > > Diffs > ----- > > indra/llaudio/llaudioengine.cpp 6d44f0d85a80 > > Diff: http://codereview.secondlife.com/r/72/diff > > > Testing > ------- > > In Preferences / Sound & Media tested: > Buttons > Ambient > Sound Effects > Stream Music > Media > Voice Chat > > > Thanks, > > Jonathan > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110110/b85c8eb5/attachment.htm From merov at lindenlab.com Mon Jan 10 15:36:35 2011 From: merov at lindenlab.com (Merov Linden) Date: Mon, 10 Jan 2011 23:36:35 -0000 Subject: [opensource-dev] Review Request: Update returnability of objects based on new encroachment rules In-Reply-To: <20101223075401.7867.83626@domU-12-31-38-00-90-68.compute-1.internal> References: <20101223075401.7867.83626@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110110233635.6852.32096@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/56/ ----------------------------------------------------------- (Updated Jan. 10, 2011, 3:36 p.m.) Review request for Viewer and Andrew Meadows. Changes ------- Latest diff from most recent andrew_linden repo Summary ------- The object-vs-parcel overlap test is done by building axis-aligned bounding boxes (AABB) about each prim of the selected objects and then checking for overlap between those boxes and self- and group-owned parcels. This addresses bug STORM-807. http://jira.secondlife.com/browse/STORM-807 Diffs (updated) ----- indra/llmath/llbbox.h bceb13778d1d indra/llmath/llbbox.cpp bceb13778d1d indra/llmessage/llregionflags.h bceb13778d1d indra/newview/llviewermenu.cpp bceb13778d1d indra/newview/llviewerobject.h bceb13778d1d indra/newview/llviewerobject.cpp bceb13778d1d indra/newview/llviewerparceloverlay.h bceb13778d1d indra/newview/llviewerparceloverlay.cpp bceb13778d1d indra/newview/llviewerregion.h bceb13778d1d indra/newview/llviewerregion.cpp bceb13778d1d indra/newview/llvoavatar.cpp bceb13778d1d indra/newview/skins/default/xui/en/menu_viewer.xml bceb13778d1d Diff: http://codereview.secondlife.com/r/56/diff Testing ------- Thanks, Merov -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110110/7ab19a77/attachment.htm From merov at lindenlab.com Mon Jan 10 15:55:04 2011 From: merov at lindenlab.com (Merov Linden) Date: Mon, 10 Jan 2011 23:55:04 -0000 Subject: [opensource-dev] Review Request: Update returnability of objects based on new encroachment rules In-Reply-To: <20110110233635.6852.32096@domU-12-31-38-00-90-68.compute-1.internal> References: <20110110233635.6852.32096@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110110235504.6850.51492@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/56/#review140 ----------------------------------------------------------- Ship it! Good! Only minor typos and code style issues (see review details). About lines commented out, please prefer deletion unless there's a good reason for it which then should be mentioned in comments. indra/llmath/llbbox.cpp Typo : change "rotiation" to "rotation" indra/llmessage/llregionflags.h Suppress legacy code, don't leave it commented out indra/llmessage/llregionflags.h Suppress old code, don't leave it commented out indra/llmessage/llregionflags.h Please suppress (though it was already commented out...) indra/llmessage/llregionflags.h Suppress etc... indra/llmessage/llregionflags.h Suppress etc... indra/newview/llviewerobject.h Typo: one "it" too many indra/newview/llviewerparceloverlay.cpp Code style: - use "{ }" for each for nested loop and each if statement - use "()" in "||" statement - Merov On Jan. 10, 2011, 3:36 p.m., Merov Linden wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/56/ > ----------------------------------------------------------- > > (Updated Jan. 10, 2011, 3:36 p.m.) > > > Review request for Viewer and Andrew Meadows. > > > Summary > ------- > > The object-vs-parcel overlap test is done by building axis-aligned bounding boxes (AABB) about each prim of the selected objects and then checking for overlap between those boxes and self- and group-owned parcels. > > > This addresses bug STORM-807. > http://jira.secondlife.com/browse/STORM-807 > > > Diffs > ----- > > indra/llmath/llbbox.h bceb13778d1d > indra/llmath/llbbox.cpp bceb13778d1d > indra/llmessage/llregionflags.h bceb13778d1d > indra/newview/llviewermenu.cpp bceb13778d1d > indra/newview/llviewerobject.h bceb13778d1d > indra/newview/llviewerobject.cpp bceb13778d1d > indra/newview/llviewerparceloverlay.h bceb13778d1d > indra/newview/llviewerparceloverlay.cpp bceb13778d1d > indra/newview/llviewerregion.h bceb13778d1d > indra/newview/llviewerregion.cpp bceb13778d1d > indra/newview/llvoavatar.cpp bceb13778d1d > indra/newview/skins/default/xui/en/menu_viewer.xml bceb13778d1d > > Diff: http://codereview.secondlife.com/r/56/diff > > > Testing > ------- > > > Thanks, > > Merov > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110110/891ad58a/attachment-0001.htm From nexiim at gmail.com Tue Jan 11 07:25:00 2011 From: nexiim at gmail.com (Nexii Malthus) Date: Tue, 11 Jan 2011 15:25:00 +0000 Subject: [opensource-dev] 5 Channel JPEG2000 In-Reply-To: References: Message-ID: I remember looking at the code for the baking process, it looked like it was made so that the description field could be used to designate what each channel means by using single char markers. Thinking this could be the best way to provide extra clues for the client to use for describing a multi-channel texture. As some of you may know, I had experimented with parallax shaders almost a year ago. The markers are what had spurred me on in hope that it would be possible eventually. It would be pretty cool if I could mark a channel as a heightmap. http://i56.tinypic.com/ao57uw.jpg Imagine this being possible for everyday use. [Oh and older computers wouldn't need to be left out either. I developed a weaker version of my original parallax shader on the Radeon X850. (That is one ol' graphics card)] - Nexii On Mon, Jan 10, 2011 at 9:18 PM, Joshua Bell wrote: > On Mon, Jan 10, 2011 at 11:47 AM, Ricky wrote: > >> Question: what, if anything, is the 5th channel currently used for? >> > > Bump maps in baked textures. IIRC, only the avatar pipeline > produces/consumes that channel. Also, IIRC, the logic is entirely > client-side at the moment. > > >> Could it be used for normal maps if it is currently unused? >> If so, then we could do this entirely clientside, assuming 5 channel >> textures can be uploaded. Of course there would still need to be a >> way to disable the alpha channel during upload while preserving the >> normal map channel. >> > > That would technically be possible. The asset system does do verification > and modification of various asset types on upload (including textures), but > - again, technically - this would probably work, possibly requiring some > minor changes to the asset verifier. > > However... > > The biggest challenge is the lack of support for multiple channels in > JPEG2000-producing/consuming tools. Many tools only work with 3-channel > images, and complain about 4. Combined with the lack of tools for authoring > JPEG2000 images in the first place, I'm not sure you'd want add another 3 > channels to the image for the normal map. It would also mean you couldn't > re-use a normal map with two textures, e.g. to allow color variants on a > base mesh. > > Avoiding two separate texture asset fetches (colors and normals) per face > might be a significant win, but I'd want to see the numbers to prove it > first. > > (For comparison, the 13-channel RAW data used for uploading/downloading > region terrain and parcel data is pretty pesky to work with. Sure, it works > with PhotoShop, and is a technically simple single file backup format, but > putting all of that data into a single image is fragile that you expect > users to edit is not particularly user-friendly.) > > >> Ricky >> Cron Stardust >> >> On Monday, January 10, 2011, Joshua Bell wrote: >> > On Mon, Jan 10, 2011 at 9:28 AM, Dave Booth >> wrote: >> > >> > Thats a pretty good bit of thinking out loud there, Ponzu.... >> > >> > Personally I'd say thats a "clean" fix for this. However it all depends >> > on how things are stored server-side - if the asset server code >> > automatically assumes that every texture has an alpha channel and >> > supplies a "solid" one for those where the upload doesnt provide one, >> > any benefit of specifying at upload time is moot. >> > The asset upload/storage system handles 3, 4 or 5 channel JPEG2000 >> textures and doesn't tinker with the channel data. The bulk of the textures >> in the asset system are 3-channel (RGB). >> > >> > (Excellent question, BTW.) >> > >> > >> _______________________________________________ >> Policies 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/20110111/1126c5e5/attachment.htm From nexiim at gmail.com Tue Jan 11 07:37:32 2011 From: nexiim at gmail.com (Nexii Malthus) Date: Tue, 11 Jan 2011 15:37:32 +0000 Subject: [opensource-dev] Review Request: VWR-24420: PNG images which specify "background color" lose alpha layer when imported. In-Reply-To: References: <20110109145917.7202.23064@domU-12-31-38-00-90-68.compute-1.internal> <4D2B41B4.6040208@meadowlakearts.com> Message-ID: I often take my own custom client for granted. I forget that people can't select compression levels (ratios are preserved, the textures work for me and others fine) and a checkbox whether alpha channel should be included. Additionally asset size statistics for memory usage when uncompressed and network bandwidth + asset server usage for when compressed. http://i56.tinypic.com/20iz592.jpg [If only I could have made it adjust upload fees based on size..] - Nexii On Mon, Jan 10, 2011 at 7:05 PM, Joshua Bell wrote: > On Mon, Jan 10, 2011 at 9:28 AM, Dave Booth wrote: > >> Thats a pretty good bit of thinking out loud there, Ponzu.... >> >> Personally I'd say thats a "clean" fix for this. However it all depends >> on how things are stored server-side - if the asset server code >> automatically assumes that every texture has an alpha channel and >> supplies a "solid" one for those where the upload doesnt provide one, >> any benefit of specifying at upload time is moot. > > > The asset upload/storage system handles 3, 4 or 5 channel JPEG2000 textures > and doesn't tinker with the channel data. The bulk of the textures in the > asset system are 3-channel (RGB). > > (Excellent question, BTW.) > > > _______________________________________________ > Policies 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/20110111/30cdfde6/attachment.htm From slitovchuk at productengine.com Tue Jan 11 08:27:20 2011 From: slitovchuk at productengine.com (Seth ProductEngine) Date: Tue, 11 Jan 2011 16:27:20 -0000 Subject: [opensource-dev] Review Request: (STORM-550) LLDir::getNextFileInDir fails for some complex wildcard combinations In-Reply-To: <20110105163327.6678.82332@domU-12-31-38-00-90-68.compute-1.internal> References: <20110105163327.6678.82332@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110111162720.6852.23169@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/32/ ----------------------------------------------------------- (Updated Jan. 11, 2011, 8:27 a.m.) Review request for Viewer. Changes ------- - Changed llwarns with llerrs in LLDirIterator and removed 2 unit tests that started to cause llerrs. - Replaced all existing usages of LLDir::getNextFileInDir() with the new directory iterator object. - Removed platform specific LLDir::getNextFileInDir() implementation. Summary (updated) ------- - Re-implemented LLDir::getNextFileInDir() as an iterator object. - Added a class implementing directory entries iteration with pattern matching which is used in unit tests instead of LLDir::getNextFileInDir. - Fixed LLDir unit test which failed for some complex wildcard combinations. - Replaced all existing usages of LLDir::getNextFileInDir() with the new directory iterator object. - Removed platform specific LLDir::getNextFileInDir() implementation. This addresses bug STORM-477. http://jira.secondlife.com/browse/STORM-477 Diffs (updated) ----- indra/cmake/Boost.cmake bceb13778d1d indra/integration_tests/llui_libtest/llui_libtest.cpp bceb13778d1d indra/linux_updater/linux_updater.cpp bceb13778d1d indra/llvfs/CMakeLists.txt bceb13778d1d indra/llvfs/lldir.h bceb13778d1d indra/llvfs/lldir.cpp bceb13778d1d indra/llvfs/lldir_linux.h bceb13778d1d indra/llvfs/lldir_linux.cpp bceb13778d1d indra/llvfs/lldir_mac.h bceb13778d1d indra/llvfs/lldir_mac.cpp bceb13778d1d indra/llvfs/lldir_solaris.h bceb13778d1d indra/llvfs/lldir_solaris.cpp bceb13778d1d indra/llvfs/lldir_win32.h bceb13778d1d indra/llvfs/lldir_win32.cpp bceb13778d1d indra/llvfs/lldiriterator.h PRE-CREATION indra/llvfs/lldiriterator.cpp PRE-CREATION indra/llvfs/tests/lldir_test.cpp bceb13778d1d indra/newview/llappviewer.cpp bceb13778d1d indra/newview/llappviewerlinux.cpp bceb13778d1d indra/newview/llfloateruipreview.cpp bceb13778d1d indra/newview/lllogchat.cpp bceb13778d1d indra/newview/llviewermedia.cpp bceb13778d1d indra/newview/llwaterparammanager.cpp bceb13778d1d indra/newview/llwlparammanager.cpp bceb13778d1d indra/viewer_components/updater/tests/llupdaterservice_test.cpp bceb13778d1d Diff: http://codereview.secondlife.com/r/32/diff Testing ------- Thanks, Seth -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110111/5ed23d25/attachment.htm From q at lindenlab.com Tue Jan 11 08:57:48 2011 From: q at lindenlab.com (Kent Quirk) Date: Tue, 11 Jan 2011 16:57:48 -0000 Subject: [opensource-dev] Review Request: (STORM-550) LLDir::getNextFileInDir fails for some complex wildcard combinations In-Reply-To: <20110111162720.6852.23169@domU-12-31-38-00-90-68.compute-1.internal> References: <20110111162720.6852.23169@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110111165748.7202.97332@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/32/#review141 ----------------------------------------------------------- Ship it! I haven't built it, but I'm presuming that since you wrote test code that it passes the tests. I love this; and it's even documented. The code looks good, and I'm really happy to have it. Thank you. - Kent On Jan. 11, 2011, 8:27 a.m., Seth ProductEngine wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/32/ > ----------------------------------------------------------- > > (Updated Jan. 11, 2011, 8:27 a.m.) > > > Review request for Viewer. > > > Summary > ------- > > - Re-implemented LLDir::getNextFileInDir() as an iterator object. > - Added a class implementing directory entries iteration with pattern matching which is used in unit tests instead of LLDir::getNextFileInDir. > - Fixed LLDir unit test which failed for some complex wildcard combinations. > - Replaced all existing usages of LLDir::getNextFileInDir() with the new directory iterator object. > - Removed platform specific LLDir::getNextFileInDir() implementation. > > > This addresses bug STORM-477. > http://jira.secondlife.com/browse/STORM-477 > > > Diffs > ----- > > indra/cmake/Boost.cmake bceb13778d1d > indra/integration_tests/llui_libtest/llui_libtest.cpp bceb13778d1d > indra/linux_updater/linux_updater.cpp bceb13778d1d > indra/llvfs/CMakeLists.txt bceb13778d1d > indra/llvfs/lldir.h bceb13778d1d > indra/llvfs/lldir.cpp bceb13778d1d > indra/llvfs/lldir_linux.h bceb13778d1d > indra/llvfs/lldir_linux.cpp bceb13778d1d > indra/llvfs/lldir_mac.h bceb13778d1d > indra/llvfs/lldir_mac.cpp bceb13778d1d > indra/llvfs/lldir_solaris.h bceb13778d1d > indra/llvfs/lldir_solaris.cpp bceb13778d1d > indra/llvfs/lldir_win32.h bceb13778d1d > indra/llvfs/lldir_win32.cpp bceb13778d1d > indra/llvfs/lldiriterator.h PRE-CREATION > indra/llvfs/lldiriterator.cpp PRE-CREATION > indra/llvfs/tests/lldir_test.cpp bceb13778d1d > indra/newview/llappviewer.cpp bceb13778d1d > indra/newview/llappviewerlinux.cpp bceb13778d1d > indra/newview/llfloateruipreview.cpp bceb13778d1d > indra/newview/lllogchat.cpp bceb13778d1d > indra/newview/llviewermedia.cpp bceb13778d1d > indra/newview/llwaterparammanager.cpp bceb13778d1d > indra/newview/llwlparammanager.cpp bceb13778d1d > indra/viewer_components/updater/tests/llupdaterservice_test.cpp bceb13778d1d > > Diff: http://codereview.secondlife.com/r/32/diff > > > Testing > ------- > > > Thanks, > > Seth > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110111/a2a882d7/attachment-0001.htm From angel_of_crimson at hotmail.com Tue Jan 11 18:05:26 2011 From: angel_of_crimson at hotmail.com (Erin Mallory) Date: Tue, 11 Jan 2011 21:05:26 -0500 Subject: [opensource-dev] web profiles. Message-ID: because of security and privacy issues with the new profiles can we please have option to keep the older ones until someone with the profile team gets their act together? seriously, these new profiles are creepy. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110111/f3d5ad49/attachment.htm From secret.argent at gmail.com Tue Jan 11 18:44:48 2011 From: secret.argent at gmail.com (Argent Stonecutter) Date: Tue, 11 Jan 2011 20:44:48 -0600 Subject: [opensource-dev] Review Request: VWR-24420: PNG images which specify "background color" lose alpha layer when imported. In-Reply-To: <201101102003.30338.tinacloud@gmx.de> References: <20110109145917.7202.23064@domU-12-31-38-00-90-68.compute-1.internal> <201101102003.30338.tinacloud@gmx.de> Message-ID: <91F21926-E9F4-4D5A-8A49-EC32D2D86233@gmail.com> On 2011-01-10, at 13:03, Zi Ree wrote: > Am Montag 10 Januar 2011 17:34:08 schrieb Ponzu: > >> What if the upload dialog had a check box? >> >> [ ] This texture should have an alpha channel. > > Would it be possible to do this on a per-face basis rather than on texture > upload? So people could use the same texture as alpha texture and as non-alpha > as well? > > Edit Texture > [x] Use Alpha How about: [_] Full Alpha, [x] 1-bit Alpha, [_] No Alpha. From simon.quinnell at gmail.com Tue Jan 11 19:47:03 2011 From: simon.quinnell at gmail.com (Simon Quinnell) Date: Wed, 12 Jan 2011 14:47:03 +1100 Subject: [opensource-dev] web profiles. In-Reply-To: References: Message-ID: How about you specify the security and privacy issues? No-one here is a mind reader. On Wed, Jan 12, 2011 at 1:05 PM, Erin Mallory wrote: > because of security and privacy issues with the new profiles can we please > have option to keep the older ones until someone with the profile team gets > their act together? > > seriously, these new profiles are creepy. > > _______________________________________________ > Policies 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/20110112/32790f23/attachment.htm From kadah.coba at gmail.com Tue Jan 11 19:54:00 2011 From: kadah.coba at gmail.com (Kadah) Date: Tue, 11 Jan 2011 19:54:00 -0800 Subject: [opensource-dev] web profiles. In-Reply-To: References: Message-ID: <4D2D25D8.90304@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 If its about the possible XSS and html injection, that was fixed today. All profile text info gets escaped now. On 1/11/2011 7:47 PM, Simon Quinnell wrote: > How about you specify the security and privacy issues? No-one here is a > mind reader. > > On Wed, Jan 12, 2011 at 1:05 PM, Erin Mallory > > wrote: > > because of security and privacy issues with the new profiles can we > please have option to keep the older ones until someone with the > profile team gets their act together? > > seriously, these new profiles are creepy. > > _______________________________________________ > Policies 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJNLSXYAAoJEIdLfPRu7qE2c1UIALye/0KE3XRvTxSS7ZhBW0i/ kE857hMOK8B9sbvbN08m8af8oas30cfIl/a/XvY8Fhf49tMrMlPC28X0OID1DtOs Dt50xkHTp56YqsmMHzcCRHgJN8lb6IonbX44U1VHah8/NEYQ7EejMuyBpnD9Wjvg KPUDsQOBl4vVhaJQ6GHbRQe54PpUzBnWpyecdZ8AvCldLk8L0KJAKVGMVXAKQSpe cFAZUo343UAA6Q15Ymoug4MTN4Z8s3snsL0llIF/XGD71H90KYL9cnxtbj7BmZus G8E3xpdUgPQGXkIwqKQUrZMQlOcINIUo4YuKyE+mK+Sdy6z9B9yOp1kecI70MFE= =djz5 -----END PGP SIGNATURE----- From angel_of_crimson at hotmail.com Tue Jan 11 20:48:13 2011 From: angel_of_crimson at hotmail.com (Erin Mallory) Date: Tue, 11 Jan 2011 23:48:13 -0500 Subject: [opensource-dev] web profiles. In-Reply-To: <4D2D25D8.90304@gmail.com> References: , , <4D2D25D8.90304@gmail.com> Message-ID: some of us were using html to cover up the darn twitter and facebook widgets.... security issues: the twitter widget and facebook like button you cant get rid of. security issue: if you want your profile visible in SL or at least searchable it HAS to be open to the entire world... (only gets protected by passord if you remove it from search security issue: RL tab is displayed ON THE WEB ... that alone is frightening security issue: people are already linking in other peoples profiles into webpages, facebook, even other applications now. Security issue: with html scrubbed from the text you cant hide profiles, even locked ones from bots, or cover up the facebook and twitter widgets. Seucrity issue: many groups that should be hidden in the profile by group preferences are still being show. preference issue: many users do NOT want their profiles shown ANYWHERE but in the game. preference issue: many users do not like the facebook feel preference issue: many users like having the partner, payment info, etc displayed. preference issue: most users would have preferred seeing web bugs fixed then resources wasted on facebook style profiles because a few web monkeys think that they will attract a few teenagers into SL. within moments of creation https://jira.secondlife.com/browse/WEB-3494 has already gotten votes as have many other issues related to getting rid of these new profiles. > Date: Tue, 11 Jan 2011 19:54:00 -0800 > From: kadah.coba at gmail.com > To: opensource-dev at lists.secondlife.com > Subject: Re: [opensource-dev] web profiles. > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > If its about the possible XSS and html injection, that was fixed today. > All profile text info gets escaped now. > > On 1/11/2011 7:47 PM, Simon Quinnell wrote: > > How about you specify the security and privacy issues? No-one here is a > > mind reader. > > > > On Wed, Jan 12, 2011 at 1:05 PM, Erin Mallory > > > wrote: > > > > because of security and privacy issues with the new profiles can we > > please have option to keep the older ones until someone with the > > profile team gets their act together? > > > > seriously, these new profiles are creepy. > > > > _______________________________________________ > > Policies 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 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.10 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iQEcBAEBAgAGBQJNLSXYAAoJEIdLfPRu7qE2c1UIALye/0KE3XRvTxSS7ZhBW0i/ > kE857hMOK8B9sbvbN08m8af8oas30cfIl/a/XvY8Fhf49tMrMlPC28X0OID1DtOs > Dt50xkHTp56YqsmMHzcCRHgJN8lb6IonbX44U1VHah8/NEYQ7EejMuyBpnD9Wjvg > KPUDsQOBl4vVhaJQ6GHbRQe54PpUzBnWpyecdZ8AvCldLk8L0KJAKVGMVXAKQSpe > cFAZUo343UAA6Q15Ymoug4MTN4Z8s3snsL0llIF/XGD71H90KYL9cnxtbj7BmZus > G8E3xpdUgPQGXkIwqKQUrZMQlOcINIUo4YuKyE+mK+Sdy6z9B9yOp1kecI70MFE= > =djz5 > -----END PGP SIGNATURE----- > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting privileges -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110111/ff9f9e02/attachment.htm From dmahalko at gmail.com Tue Jan 11 21:50:41 2011 From: dmahalko at gmail.com (Dale Mahalko) Date: Tue, 11 Jan 2011 23:50:41 -0600 Subject: [opensource-dev] What client for Havok 2k10 / mesh testing? Message-ID: Someone mentioned to me that there is a physics engine upgrade test over on the beta grid. I haven't used SL in a while (waiting for mesh to be done) so on startup I am notified of the 2.4 beta client at the login screen, yeah might as well install that. Hmm, odd, I don't think this beta client works with the mesh / physics beta grid. Everything just looks like paper-thin 2D rhombuses at odd angles all over the place. So what client am I supposed to be using? Probably should mention that detail on the wiki pages for the Havok 2k10 beta test grid. From stickman at gmail.com Tue Jan 11 21:53:08 2011 From: stickman at gmail.com (Stickman) Date: Tue, 11 Jan 2011 21:53:08 -0800 Subject: [opensource-dev] What client for Havok 2k10 / mesh testing? In-Reply-To: References: Message-ID: > Someone mentioned to me that there is a physics engine upgrade test > over on the beta grid. I haven't used SL in a while (waiting for mesh > to be done) so on startup I am notified of the 2.4 beta client at the > login screen, yeah might as well install that. Physics is serverside so you shouldn't need a special client for that. As for mesh, try out the "more viewers" option on the download page. http://wiki.secondlife.com/wiki/Linden_Lab_Official:Alternate_Viewers Stickman From yoz at lindenlab.com Tue Jan 11 21:54:08 2011 From: yoz at lindenlab.com (Yoz Grahame) Date: Tue, 11 Jan 2011 21:54:08 -0800 Subject: [opensource-dev] web profiles. In-Reply-To: References: <4D2D25D8.90304@gmail.com> Message-ID: Erin, you and I have discussed aspects of this several times in the past, and I'm sure we will again in the future. (I'll comment on the JIRA issue - thank you for filing it.) However, irrespective of my opinions on the matter, these issues are related to neither the viewer nor any other open source projects, so not suited to this mailing list. The Profiles team is keeping a close eye on the my.secondlife.com component of the WEB project and has been rapidly turning around fixes in response to filed issues. As such, JIRA is definitely the best place for these issues to be discussed (ideally as individual issues, rather than all lumped into one). -- Yoz On 11 January 2011 20:48, Erin Mallory wrote: > some of us were using html to cover up the darn twitter and facebook > widgets.... > > security issues: the twitter widget and facebook like button you cant get > rid of. > security issue: if you want your profile visible in SL or at least > searchable it HAS to be open to the entire world... (only gets protected by > passord if you remove it from search > security issue: RL tab is displayed ON THE WEB ... that alone is > frightening > security issue: people are already linking in other peoples profiles into > webpages, facebook, even other applications now. > Security issue: with html scrubbed from the text you cant hide profiles, > even locked ones from bots, or cover up the facebook and twitter widgets. > Seucrity issue: many groups that should be hidden in the profile by group > preferences are still being show. > > preference issue: many users do NOT want their profiles shown ANYWHERE but > in the game. > preference issue: many users do not like the facebook feel > preference issue: many users like having the partner, payment info, etc > displayed. > preference issue: most users would have preferred seeing web bugs fixed > then resources wasted on facebook style profiles because a few web monkeys > think that they will attract a few teenagers into SL. > > within moments of creation https://jira.secondlife.com/browse/WEB-3494 has > already gotten votes as have many other issues related to getting rid of > these new profiles. > > > > Date: Tue, 11 Jan 2011 19:54:00 -0800 > > From: kadah.coba at gmail.com > > To: opensource-dev at lists.secondlife.com > > Subject: Re: [opensource-dev] web profiles. > > > > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > If its about the possible XSS and html injection, that was fixed today. > > All profile text info gets escaped now. > > > > On 1/11/2011 7:47 PM, Simon Quinnell wrote: > > > How about you specify the security and privacy issues? No-one here is a > > > mind reader. > > > > > > On Wed, Jan 12, 2011 at 1:05 PM, Erin Mallory > > > > > wrote: > > > > > > because of security and privacy issues with the new profiles can we > > > please have option to keep the older ones until someone with the > > > profile team gets their act together? > > > > > > seriously, these new profiles are creepy. > > > > > > _______________________________________________ > > > Policies 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 > > -----BEGIN PGP SIGNATURE----- > > Version: GnuPG v1.4.10 (MingW32) > > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > > > iQEcBAEBAgAGBQJNLSXYAAoJEIdLfPRu7qE2c1UIALye/0KE3XRvTxSS7ZhBW0i/ > > kE857hMOK8B9sbvbN08m8af8oas30cfIl/a/XvY8Fhf49tMrMlPC28X0OID1DtOs > > Dt50xkHTp56YqsmMHzcCRHgJN8lb6IonbX44U1VHah8/NEYQ7EejMuyBpnD9Wjvg > > KPUDsQOBl4vVhaJQ6GHbRQe54PpUzBnWpyecdZ8AvCldLk8L0KJAKVGMVXAKQSpe > > cFAZUo343UAA6Q15Ymoug4MTN4Z8s3snsL0llIF/XGD71H90KYL9cnxtbj7BmZus > > G8E3xpdUgPQGXkIwqKQUrZMQlOcINIUo4YuKyE+mK+Sdy6z9B9yOp1kecI70MFE= > > =djz5 > > -----END PGP SIGNATURE----- > > _______________________________________________ > > Policies and (un)subscribe information available here: > > http://wiki.secondlife.com/wiki/OpenSource-Dev > > Please read the policies before posting to keep unmoderated posting > privileges > > _______________________________________________ > Policies 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/20110111/80c2c684/attachment-0001.htm From merov at lindenlab.com Tue Jan 11 22:16:37 2011 From: merov at lindenlab.com (Philippe (Merov) Bossut) Date: Tue, 11 Jan 2011 22:16:37 -0800 Subject: [opensource-dev] Test binaries Message-ID: Hi guys, I produced test binaries for a set of 14 issues so you can give them a spin and voice concerns before integration. Unfortunately, the TC Windows build timed out in succession and I didn't get one to build. Here however are the Linux and Mac ones: - http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repo/merov_viewer-development-import/rev/218825/arch/Linux/index.html - http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repo/merov_viewer-development-import/rev/218825/arch/Darwin/index.html Fixes included: - STORM-387 : Part of the table is hidden after increasing firsts column width in the floater and then dock it to the SP - STORM-797 : STORM-410 Parcel SLURL rendering - STORM-720 : STORM-304 URL-name of object is shown as hyperlink in Share confirmation window - STORM-830 : Volume slider isn't properly remembered if set to zero - STORM-370 : Human-readable name of region disappears from Location Bar after pressing ESC - STORM-385 : Pressing ENTER key in the Favorites overflow list scrolls list - STORM-702 : Make it possible to wear partial outfits - STORM-435 : There is no space between name of object and value of object in Chat step while creating new gesture - STORM-615 : Reorganize right click Build menu so Delete is at the top level - STORM-514 : LLSideTray::Params::Params() gets non-existent artwork. - STORM-393 : Group SLURL has wrong color in the nearby chat - STORM-829 : Viewer 2 does not parse /me in object Instant Messages - STORM-723 : Inspecting single prim objects doesn't work in Viewer 2 Thanks for your test effort. Cheers, - Merov -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110111/2535cef9/attachment.htm From trilobyte550m at gmail.com Wed Jan 12 01:24:57 2011 From: trilobyte550m at gmail.com (Trilo Byte) Date: Wed, 12 Jan 2011 01:24:57 -0800 Subject: [opensource-dev] What client for Havok 2k10 / mesh testing? In-Reply-To: References: Message-ID: <0098F56B-FCAF-4D11-AE96-5D53848D04D9@gmail.com> According to the Havok 2k10 Beta page on the wiki, the Mesh Project Viewer now contains the necessary bits for the physics engine upgrade (second sentence in the "What is Havok 2k10" section). https://wiki.secondlife.com/wiki/Havok_2k10_Beta_Home Further down on the page it details where you can test old version vs. new version on ADITI On Jan 11, 2011, at 9:50 PM, Dale Mahalko wrote: > Someone mentioned to me that there is a physics engine upgrade test > over on the beta grid. I haven't used SL in a while (waiting for mesh > to be done) so on startup I am notified of the 2.4 beta client at the > login screen, yeah might as well install that. > > Hmm, odd, I don't think this beta client works with the mesh / physics > beta grid. Everything just looks like paper-thin 2D rhombuses at odd > angles all over the place. > > So what client am I supposed to be using? Probably should mention that > detail on the wiki pages for the Havok 2k10 beta test grid. > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting privileges From oz at lindenlab.com Wed Jan 12 04:42:29 2011 From: oz at lindenlab.com (Oz Linden (Scott Lawrence)) Date: Wed, 12 Jan 2011 07:42:29 -0500 Subject: [opensource-dev] https://jira.secondlife.com/browse/SH-489 In-Reply-To: <201101081858.14793.Lance.Corrimal@eregion.de> References: <201101081858.14793.Lance.Corrimal@eregion.de> Message-ID: <4D2DA1B5.1010202@lindenlab.com> On 2011-01-08 12:58, Lance Corrimal wrote: > Hi there, > > am I the only one who thinks that > https://jira.secondlife.com/browse/SH-489 should be rated a bit higher > than "minor, will be fixed in the distant future"? If any open developer is interested in taking on this (and/or the similar-sounding voice dot issue mentioned later in the thread), don't let the fact that it's not in VWR or STORM dissuade you. From oz at lindenlab.com Wed Jan 12 04:56:45 2011 From: oz at lindenlab.com (Oz Linden (Scott Lawrence)) Date: Wed, 12 Jan 2011 07:56:45 -0500 Subject: [opensource-dev] storm-34 In-Reply-To: References: , <9043BBD2-9063-4CC8-B34B-BBE7037D92BE@lindenlab.com>, , , , Message-ID: <4D2DA50D.3060800@lindenlab.com> On 2011-01-10 11:38, Erin Mallory wrote: > what happened to get the issue to occur for me. I installed the > storm-34 developer viewer. logged in with cummere mayo. set the > option to show the favorites. logged out. started the viewer. it > worked as expected. logged out. back in. still worked as expected. > logged out. > changed account to erinyse planer. logged in. logged back out. > started viewer. favorites were not there (as expected) changed > account back to cummere mayo. logged in. made sure preference was > still on. (it was) logged out. restarted the viewer: favorites no > longer show up. There were a number of late-breaking changes to how this worked before it was integrated into viewer-development, so identifying a specific version is important (which you didn't do). What you're describing might have been fixed. Development Versions >= 2.5.0.218601 (and the upcoming 2.5.0 Beta) should behave the way Q described. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110112/498ae5c6/attachment.htm From oz at lindenlab.com Wed Jan 12 04:59:25 2011 From: oz at lindenlab.com (Oz Linden) Date: Wed, 12 Jan 2011 12:59:25 -0000 Subject: [opensource-dev] Review Request: Show TOS (and other login dialogs) if --login is specified In-Reply-To: <20110110182822.7014.45882@domU-12-31-38-00-90-68.compute-1.internal> References: <20110110182822.7014.45882@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110112125925.6853.5810@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/76/#review142 ----------------------------------------------------------- Ship it! Looks good to me. - Oz On Jan. 10, 2011, 10:28 a.m., Joshua Linden wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/76/ > ----------------------------------------------------------- > > (Updated Jan. 10, 2011, 10:28 a.m.) > > > Review request for Viewer. > > > Summary > ------- > > This simply removes the mUserInteraction logic from LLLoginInstance, which is not used other than in this behavior. Internal discussion indicates that the current behavior is undesirable and is not being relied upon by test automation, and in fact interferes with test automation. > > Prior to this change, if the viewer is launched with: > > SecondLife.exe --login FIRST LAST PASSWORD > > ... and if the login response is that a TOS, Critical Message, or Update must be acknowledged, the viewer simply returns to the credentials screen (login panel) but does not indicate why. > > After this change, the viewer will display the appropriate follow-on UI even if --login is used. If necessary, an additional option could be specified to inhibit showing these UI elements for test automation scenarios (e.g. auto-accepting or exiting the viewer, as appropriate). > > (the bulk of the raw diff is whitespace changes due to re-indentation) > > > This addresses bug VWR-24401. > http://jira.secondlife.com/browse/VWR-24401 > > > Diffs > ----- > > indra/newview/lllogininstance.h 78fae8ca1b36 > indra/newview/lllogininstance.cpp 78fae8ca1b36 > indra/newview/llstartup.cpp 78fae8ca1b36 > > Diff: http://codereview.secondlife.com/r/76/diff > > > Testing > ------- > > Launched viewer normally (with "normal" account), entered credentials, logged in successfully. > Launched viewer via --login (with "normal" account), logged in successfully. > Launched viewer via --login with account needing to accept TOS update; viewer displayed TOS dialog; accepted and logged in successfully. > > > Thanks, > > Joshua > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110112/d5e81a48/attachment.htm From nexiim at gmail.com Wed Jan 12 05:06:54 2011 From: nexiim at gmail.com (Nexii Malthus) Date: Wed, 12 Jan 2011 13:06:54 +0000 Subject: [opensource-dev] Pre-processing chat input (was Re: Review Request: STORM-829 Viewer 2 does not parse /me in object Instant Messages In-Reply-To: References: Message-ID: "/me " is a *post-process*. - Nexii On Sat, Jan 8, 2011 at 7:16 PM, Jonathan Welch wrote: > Yesterday it was suggested to substitute /me at some early point. > > In this particular case it would not work for two reasons: > > 1) "/me" has to pass through the communications system so when it > arrives at the viewer from the server the various components that > display the line can see it is a "/me" line and insert the name in > italics or otherwise "do the right thing". You have local chat > toasts, chat history, the IM window, etc. > > 2) There are 3 ways messages can arrive from objects (llSay, > llOwnerSay, and llInstantMessage) so there is no way they can be > processed until the arrive at your viewer for display. > > -Jonathan > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110112/071c1aa7/attachment.htm From secret.argent at gmail.com Wed Jan 12 05:26:07 2011 From: secret.argent at gmail.com (Argent Stonecutter) Date: Wed, 12 Jan 2011 07:26:07 -0600 Subject: [opensource-dev] web profiles. In-Reply-To: References: Message-ID: On 2011-01-11, at 21:47, Simon Quinnell wrote: > How about you specify the security and privacy issues? No-one here is a mind reader. Well, the obvious minor privacy issue is sharing information about your account with sites outside Linden Lab, if only because you're passing cookies and browser tags to Facebook and Twitter. I would be more comfortable if there was by default no data fetched from anywhere but LL by the viewer. Suggested options: [x] Hide third party badges on profiles I'm viewing. [x] Hide third party badges on my profile. I would also rather not have any RL information displayed in profiles I'm viewing unless I deliberately click through to a "RL tab", as in the 1.x profile. [x] Hide RL information on profiles I'm viewing. [x] Hide RL information on my profile on the web. From tateru.nino at gmail.com Wed Jan 12 05:30:57 2011 From: tateru.nino at gmail.com (Tateru Nino) Date: Thu, 13 Jan 2011 00:30:57 +1100 Subject: [opensource-dev] Pre-processing chat input (was Re: Review Request: STORM-829 Viewer 2 does not parse /me in object Instant Messages In-Reply-To: References: Message-ID: <4D2DAD11.8010302@gmail.com> Which is a shame. It's significantly less versatile that way. On 13/01/2011 12:06 AM, Nexii Malthus wrote: > "/me " is a *post-process*. > > - Nexii > > On Sat, Jan 8, 2011 at 7:16 PM, Jonathan Welch > wrote: > > Yesterday it was suggested to substitute /me at some early point. > > In this particular case it would not work for two reasons: > > 1) "/me" has to pass through the communications system so when it > arrives at the viewer from the server the various components that > display the line can see it is a "/me" line and insert the name in > italics or otherwise "do the right thing". You have local chat > toasts, chat history, the IM window, etc. > > 2) There are 3 ways messages can arrive from objects (llSay, > llOwnerSay, and llInstantMessage) so there is no way they can be > processed until the arrive at your viewer for display. > > -Jonathan > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated > posting privileges > > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting privileges -- Tateru Nino http://dwellonit.taterunino.net/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110113/91f6299b/attachment.htm From jhwelch at gmail.com Wed Jan 12 06:02:24 2011 From: jhwelch at gmail.com (Jonathan Yap) Date: Wed, 12 Jan 2011 14:02:24 -0000 Subject: [opensource-dev] Review Request: Storm-844 "More" should be "Less" when Media Control is open Message-ID: <20110112140224.6852.84692@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/78/ ----------------------------------------------------------- Review request for Viewer. Summary ------- "More" should be "Less" when Media Control is open This is a trivial text change in an xml file. The reason I am posting this here is due to some confusion using label_selected. In this case having it set to a different value than when label is set to seems to have no effect, so I have made them identical. I scanned all the xml files and there are only about 5 places where label_selected is different from the preceding label= value. Is there any reason to revert back to having them set to different values? i.e. label="More" and label_selected="Less" This addresses bug storm-844. http://jira.secondlife.com/browse/storm-844 Diffs ----- doc/contributions.txt 179e0754a27d indra/newview/skins/default/xui/en/panel_nearby_media.xml 179e0754a27d Diff: http://codereview.secondlife.com/r/78/diff Testing ------- Thanks, Jonathan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110112/330b9ce8/attachment.htm From sllists at boroon.dasgupta.ch Wed Jan 12 06:16:55 2011 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Wed, 12 Jan 2011 14:16:55 -0000 Subject: [opensource-dev] Review Request: Storm-844 "More" should be "Less" when Media Control is open In-Reply-To: <20110112140224.6852.84692@domU-12-31-38-00-90-68.compute-1.internal> References: <20110112140224.6852.84692@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110112141655.6851.33047@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/78/#review143 ----------------------------------------------------------- doc/contributions.txt Sorting issue numbers in doc/contributions.txt is a Good Thing(TM), but unrelated to the issue at hand, thus should happen in a separate commit. - Boroondas On Jan. 12, 2011, 6:02 a.m., Jonathan Yap wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/78/ > ----------------------------------------------------------- > > (Updated Jan. 12, 2011, 6:02 a.m.) > > > Review request for Viewer. > > > Summary > ------- > > "More" should be "Less" when Media Control is open > > This is a trivial text change in an xml file. The reason I am posting this here is due to some confusion using label_selected. In this case having it set to a different value than when label is set to seems to have no effect, so I have made them identical. > > I scanned all the xml files and there are only about 5 places where label_selected is different from the preceding label= value. > > Is there any reason to revert back to having them set to different values? > i.e. label="More" and label_selected="Less" > > > This addresses bug storm-844. > http://jira.secondlife.com/browse/storm-844 > > > Diffs > ----- > > doc/contributions.txt 179e0754a27d > indra/newview/skins/default/xui/en/panel_nearby_media.xml 179e0754a27d > > Diff: http://codereview.secondlife.com/r/78/diff > > > Testing > ------- > > > Thanks, > > Jonathan > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110112/37aaab60/attachment.htm From oz at lindenlab.com Wed Jan 12 06:45:35 2011 From: oz at lindenlab.com (Oz Linden) Date: Wed, 12 Jan 2011 14:45:35 -0000 Subject: [opensource-dev] Review Request: Storm-844 "More" should be "Less" when Media Control is open In-Reply-To: <20110112141655.6851.33047@domU-12-31-38-00-90-68.compute-1.internal> References: <20110112141655.6851.33047@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110112144535.6855.78808@domU-12-31-38-00-90-68.compute-1.internal> > On Jan. 12, 2011, 6:16 a.m., Boroondas Gupte wrote: > > doc/contributions.txt, lines 369-371 > > > > > > Sorting issue numbers in doc/contributions.txt is a Good Thing(TM), but unrelated to the issue at hand, thus should happen in a separate commit. Actually, because I use changes to this file to generate some of our metrics for open source contributions, I'd prefer that any existing order be preserved: that is, add lines as needed (and adding them in order is nice), but do not reorder existing lines please. - Oz ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/78/#review143 ----------------------------------------------------------- On Jan. 12, 2011, 6:02 a.m., Jonathan Yap wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/78/ > ----------------------------------------------------------- > > (Updated Jan. 12, 2011, 6:02 a.m.) > > > Review request for Viewer. > > > Summary > ------- > > "More" should be "Less" when Media Control is open > > This is a trivial text change in an xml file. The reason I am posting this here is due to some confusion using label_selected. In this case having it set to a different value than when label is set to seems to have no effect, so I have made them identical. > > I scanned all the xml files and there are only about 5 places where label_selected is different from the preceding label= value. > > Is there any reason to revert back to having them set to different values? > i.e. label="More" and label_selected="Less" > > > This addresses bug storm-844. > http://jira.secondlife.com/browse/storm-844 > > > Diffs > ----- > > doc/contributions.txt 179e0754a27d > indra/newview/skins/default/xui/en/panel_nearby_media.xml 179e0754a27d > > Diff: http://codereview.secondlife.com/r/78/diff > > > Testing > ------- > > > Thanks, > > Jonathan > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110112/4e0834aa/attachment-0001.htm From jamey at beau.org Wed Jan 12 07:17:59 2011 From: jamey at beau.org (Jamey Fletcher) Date: Wed, 12 Jan 2011 09:17:59 -0600 Subject: [opensource-dev] Pre-processing chat input (was Re: Review Request: STORM-829 Viewer 2 does not parse /me in object Instant Messages In-Reply-To: <4D2DAD11.8010302@gmail.com> References: <4D2DAD11.8010302@gmail.com> Message-ID: <4D2DC627.9030904@beau.org> Tateru Nino wrote: > Which is a shame. It's significantly less versatile that way. > On 13/01/2011 12:06 AM, Nexii Malthus wrote: >> "/me " is a *post-process*. I'm missing what versatility we're wanting in /me - I've always seen it as a rather straight-forward substitution. From tateru at taterunino.net Wed Jan 12 07:25:59 2011 From: tateru at taterunino.net (Tateru Nino) Date: Thu, 13 Jan 2011 02:25:59 +1100 Subject: [opensource-dev] Pre-processing chat input (was Re: Review Request: STORM-829 Viewer 2 does not parse /me in object Instant Messages In-Reply-To: <4D2DC627.9030904@beau.org> References: <4D2DAD11.8010302@gmail.com> <4D2DC627.9030904@beau.org> Message-ID: <4D2DC807.4080004@taterunino.net> On 13/01/2011 2:17 AM, Jamey Fletcher wrote: > Tateru Nino wrote: > >> Which is a shame. It's significantly less versatile that way. >> On 13/01/2011 12:06 AM, Nexii Malthus wrote: >>> "/me " is a *post-process*. > I'm missing what versatility we're wanting in /me - I've always seen it > as a rather straight-forward substitution. > Well, using myself for an example, I'm used to using a completely different set of tokens and substitutions for that sort of thing. I think SL is the only thing I use that supports the old IRC syntax. I find it awkward, and it would be nice to be able to use conventions that are more common to the software that I use. As a post-processed substitution token, though, I just don't have the luxury to use familiar textual communication modes. -- Tateru Nino http://dwellonit.taterunino.net/ From angel_of_crimson at hotmail.com Wed Jan 12 09:54:56 2011 From: angel_of_crimson at hotmail.com (Erin Mallory) Date: Wed, 12 Jan 2011 12:54:56 -0500 Subject: [opensource-dev] web profiles. In-Reply-To: <6FB55B7C-9AD6-4E07-A02B-C8DEACF42B78@lindenlab.com> References: , , <4D2D25D8.90304@gmail.com> , <6FB55B7C-9AD6-4E07-A02B-C8DEACF42B78@lindenlab.com> Message-ID: there are now separate child issues or linked issues to most of the relevant points raised, linked to http://jira.secondlife.com/browse/web-3494 so if people don't agree with parts, they can now vote for the parts they do agree with. I've also toned down some of the language. From: q at lindenlab.com Subject: Re: [opensource-dev] web profiles. Date: Wed, 12 Jan 2011 10:36:01 -0500 To: angel_of_crimson at hotmail.com Hey, Erin. Without commenting on the merits of this post (hint: it has many), you hurt your own cause when you can't resist throwing in insults at the end of it (web monkey comment with an imagined motivation). You'd probably get more traction on items like this if you can manage to separate things into categories -- for example, a security issues email (or as yoz suggests, separate JIRAs) and a separate prefs request. I don't have a dog in this hunt (profiles didn't come from my team) so I'm just trying to give you a suggestion that will make your requests more effective. Q On Jan 11, 2011, at 11:48 PM, Erin Mallory wrote:some of us were using html to cover up the darn twitter and facebook widgets.... security issues: the twitter widget and facebook like button you cant get rid of. security issue: if you want your profile visible in SL or at least searchable it HAS to be open to the entire world... (only gets protected by passord if you remove it from search security issue: RL tab is displayed ON THE WEB ... that alone is frightening security issue: people are already linking in other peoples profiles into webpages, facebook, even other applications now. Security issue: with html scrubbed from the text you cant hide profiles, even locked ones from bots, or cover up the facebook and twitter widgets. Seucrity issue: many groups that should be hidden in the profile by group preferences are still being show. preference issue: many users do NOT want their profiles shown ANYWHERE but in the game. preference issue: many users do not like the facebook feel preference issue: many users like having the partner, payment info, etc displayed. preference issue: most users would have preferred seeing web bugs fixed then resources wasted on facebook style profiles because a few web monkeys think that they will attract a few teenagers into SL. within moments of creation https://jira.secondlife.com/browse/WEB-3494 has already gotten votes as have many other issues related to getting rid of these new profiles. > Date: Tue, 11 Jan 2011 19:54:00 -0800 > From: kadah.coba at gmail.com > To: opensource-dev at lists.secondlife.com > Subject: Re: [opensource-dev] web profiles. > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > If its about the possible XSS and html injection, that was fixed today. > All profile text info gets escaped now. > > On 1/11/2011 7:47 PM, Simon Quinnell wrote: > > How about you specify the security and privacy issues? No-one here is a > > mind reader. > > > > On Wed, Jan 12, 2011 at 1:05 PM, Erin Mallory > > > wrote: > > > > because of security and privacy issues with the new profiles can we > > please have option to keep the older ones until someone with the > > profile team gets their act together? > > > > seriously, these new profiles are creepy. > > > > _______________________________________________ > > Policies 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 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.10 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iQEcBAEBAgAGBQJNLSXYAAoJEIdLfPRu7qE2c1UIALye/0KE3XRvTxSS7ZhBW0i/ > kE857hMOK8B9sbvbN08m8af8oas30cfIl/a/XvY8Fhf49tMrMlPC28X0OID1DtOs > Dt50xkHTp56YqsmMHzcCRHgJN8lb6IonbX44U1VHah8/NEYQ7EejMuyBpnD9Wjvg > KPUDsQOBl4vVhaJQ6GHbRQe54PpUzBnWpyecdZ8AvCldLk8L0KJAKVGMVXAKQSpe > cFAZUo343UAA6Q15Ymoug4MTN4Z8s3snsL0llIF/XGD71H90KYL9cnxtbj7BmZus > G8E3xpdUgPQGXkIwqKQUrZMQlOcINIUo4YuKyE+mK+Sdy6z9B9yOp1kecI70MFE= > =djz5 > -----END PGP SIGNATURE----- > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting privileges _______________________________________________ Policies 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/20110112/55a357b9/attachment.htm From nyx at lindenlab.com Wed Jan 12 09:57:07 2011 From: nyx at lindenlab.com (Nyx Linden) Date: Wed, 12 Jan 2011 17:57:07 -0000 Subject: [opensource-dev] Review Request: STORM-702 Make it possible to wear partial outfits In-Reply-To: <20101213150829.18768.63543@domU-12-31-38-00-90-68.compute-1.internal> References: <20101213150829.18768.63543@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110112175707.7014.12447@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/14/#review145 ----------------------------------------------------------- Ship it! Now has design approval. ship it. - Nyx On Dec. 13, 2010, 7:08 a.m., Vadim ProductEngine wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/14/ > ----------------------------------------------------------- > > (Updated Dec. 13, 2010, 7:08 a.m.) > > > Review request for Viewer. > > > Summary > ------- > > Enabled the "Replace Current Outfit" option for incomplete outfits (i.e. those that don't contain full set of body parts). > > > This addresses bug STORM-702. > http://jira.secondlife.com/browse/STORM-702 > > > Diffs > ----- > > indra/newview/llappearancemgr.cpp 3d2e71443c58 > indra/newview/llinventoryfunctions.cpp 3d2e71443c58 > > Diff: http://codereview.secondlife.com/r/14/diff > > > Testing > ------- > > > Thanks, > > Vadim > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110112/d3a95f5a/attachment.htm From akanevsky at productengine.com Wed Jan 12 12:44:25 2011 From: akanevsky at productengine.com (Anya Kanevsky) Date: Wed, 12 Jan 2011 14:44:25 -0600 Subject: [opensource-dev] Daily Scrum Summary - Wednesday, January 12 Message-ID: Wednesday, January 12, 2011 General Notes ------------------------------ - Standup cancelled today due to Vivox troubles. - MMOTD: Merov Team Status ------------------------------ Merov Linden ------------------------------ *PAST* - MM: created a test build for PO testing - OH : lots of triaging of old SNOW issues - Triaging of more SNOW issues and JIRA cleaning - LL meetings *FUTURE* - Merge Monkeying - STORM-745 : Produce comprehensive perf baseline *IMPEDIMENTS* - Windows builds on TC keep timing out. Working with CG on this. Oz Linden ------------------------------ *PAST* - Scrum Training - Collected data on avatar texture problems *FUTURE* - Upgrade reviewboard on codereview (STORM-862) - Finish (for now) wiki docs on reviews (STORM-691) - STORM-692 set up codereview service monitor - Office Hour - Internal meeting on TeamCity issues *IMPEDIMENTS* - none Q Linden ------------------------------ *PAST* - comments/discussion on STORM-823, VWR-24446 - Snowstorm meeting inworld -- SH-489, VWR-1317/VWR-24470, SNOW-423, VWR-24416, SVC-6300 - Internal meetings *FUTURE* - triage - pick a coding task off my sprint backlog *IMPEDIMENTS* - not snow, since I'm not leaving my house. :) Esbee Linden ------------------------------ *PAST* - Meetings, Email - Cleared out PO review queue: - Reviewed STORM-797, -387, -720, -830, -370, -385, -702, -435, -615, -514, -393, -829, -723 - All approved. - Finished wiki dashboard update for product council meeting (didn't get to present) :( *FUTURE* - Internal documentation - Wait on possible revisions Viewer 2.5 Beta 1 Blog post - Review Snowstorm Team product backlog and bug log - PO reviews for open tickets - Review Jira for tickets assigned to Aimee or Moss and make some decisions about where those tickets should go :( - Plan update for system requirements - Come up with design for STORM-28 (Might pass this to XD) - Look at STORM-812 - Take another look at Wolfpup's proposal for STORM-236. PE is not available to help with this ticket for now, we'll likely have to reconsider this ticket for Sprint 11. *IMPEDIMENTS* - none Paul ProductEngine ------------------------------ *PAST* - BUG STORM-832 (Two Roles are selected after made changes in one) - Fixed. Will test tomorrow one more time and send for review. *FUTURE* - BUG STORM-832 (Two Roles are selected after made changes in one.) - BUG STORM-433 (Friendship offer shifted up and placed over "Second Life" text) *IMPEDIMENTS* - Waiting for answer in STORM-429 before i begin to fix it. Seth Productengine ------------------------------ *PAST* - TASK (STORM-477) Re-implement LLDir::getNextFileInDir() as an iterator object - Fixed. *FUTURE* - BUG (STORM-383) Context menu cannot be open for Landmark that are located in the My inventory->Trash folder - BUG (STORM-843) Inventory incremental string search not working (search starts over) *IMPEDIMENTS* - TASK (STORM-797) Parcel SLURL rendering - BUG (STORM-447) User is not able to share multi selected objects using drag&drop Vadim Productengine ------------------------------ *PAST* - Bug STORM-715 (Clothing accordion is expanded after undocking My Appearance SP): - Fixed. - Bug STORM-243 (Suppress version change message in the viewer): - Investigated, asked Esbee a question. - Task STORM-174 (Checkbox needed to save inventory scripts as Mono): - Investigating. *FUTURE* - Continue with STORM-174. *IMPEDIMENTS* - Unclear what to do with STORM-702 (Make it possible to wear partial outfits). - Need Esbee's answer in STORM-243 (Suppress version change message in the viewer). - No clear acceptance criteria for STORM-226 (Floating Text aligns improperly). Andrey Productengine ------------------------------ *PAST* - picked up beta1 build 218716 - re-ran smoke & integrity tests - integrity test has been failed by major VWR-24443 (note: not Viewer issue, smokes not failed - according to Bambers) - performed Landmark Login test plan (1 minor issue reported) - 2.5.0 bug-fixes verification *FUTURE* - proceed with bug-fixes verification - re-run smoke and integrity on new one beta1 build(?) *IMPEDIMENTS* - none Jonathan Yap ------------------------------ *PAST* - STORM-844 ("More" should be "Less" when Media Control is open) - Done. Put to codereview with a logic question. - STORM-845 (Up arrow icon on nearby chat for "Shows/hides nearby chat log" always shows as an up arrow. Should, show change to down arrow to indicate close when log is open.) *FUTURE* - STORM - 845 *IMPEDIMENTS* - Was someone going to give an up/down decision on VWR-24100? Wolfpup Lowenhar ------------------------------ *PAST* - Worked @ RL and in world. - STORM-236 : Made changes similar to EXT-7104 to try and get this functional. Sent Grumpity an email to be forwarded to another person @ PE for obtaining information on exactly how they got that to function properly as i had an interesting sideaffect from the changes I made.(Note to Esbee: Since all the people wanting this have Voice disabled decided to have button follow Voice settings.) - Attended Esbee's OH. *FUTURE* - Work @ RL and in world. - Continue to monitor VWR-24256 . - Wait for reply from person @ PE concerning EXT-7104 *IMPEDIMENTS* - Not enough time between working in-world and at real job to actually work on code. - Loss of place inworld to do any major work for inworld building. Cummere Mayo ------------------------------ *PAST* - sorting and closing out or updating several snow project issues *FUTURE* - more of the same *IMPEDIMENTS* - many office hour meetins and rl meetings. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110112/cd6be5cb/attachment-0001.htm From stickman at gmail.com Wed Jan 12 13:23:36 2011 From: stickman at gmail.com (Stickman) Date: Wed, 12 Jan 2011 13:23:36 -0800 Subject: [opensource-dev] What client for Havok 2k10 / mesh testing? In-Reply-To: <0098F56B-FCAF-4D11-AE96-5D53848D04D9@gmail.com> References: <0098F56B-FCAF-4D11-AE96-5D53848D04D9@gmail.com> Message-ID: On Wed, Jan 12, 2011 at 1:24 AM, Trilo Byte wrote: > According to the Havok 2k10 Beta page on the wiki, the Mesh Project Viewer now contains the necessary bits for the physics engine upgrade (second sentence in the "What is Havok 2k10" section). > https://wiki.secondlife.com/wiki/Havok_2k10_Beta_Home "It has merged into the Mesh server branch and deployed to ADITI for your verification pleasure." Server, not viewer. I'll happily be wrong, truth is more important than being right, but the expensive, proprietary, and closed source havok code does not appear in the client except for the closed source mesh decomposition... thing... used for uploading meshes. However if the mesh servers are the only ones that have the new physics code, then it would be pretty silly to not have the mesh viewer, yes. I remembered there being other regions that had havok 10 that weren't tied to mesh, but if you're gonna test it, why not test it with mesh. Stickman From kf6kjg at gmail.com Wed Jan 12 14:20:36 2011 From: kf6kjg at gmail.com (Ricky) Date: Wed, 12 Jan 2011 14:20:36 -0800 Subject: [opensource-dev] Pre-processing chat input (was Re: Review Request: STORM-829 Viewer 2 does not parse /me in object Instant Messages In-Reply-To: <4D2DC807.4080004@taterunino.net> References: <4D2DAD11.8010302@gmail.com> <4D2DC627.9030904@beau.org> <4D2DC807.4080004@taterunino.net> Message-ID: Interesting. I haven't tested other IM clients in recent history, but Skype still supports the /me syntax. I suspect that the others do so as well. Just my L$2... Ricky Cron Stardust On Wed, Jan 12, 2011 at 7:25 AM, Tateru Nino wrote: > > > On 13/01/2011 2:17 AM, Jamey Fletcher wrote: >> Tateru Nino wrote: >> >>> ? ?Which is a shame. It's significantly less versatile that way. >>> On 13/01/2011 12:06 AM, Nexii Malthus wrote: >>>> "/me " is a *post-process*. >> I'm missing what versatility we're wanting in /me - I've always seen it >> as a rather straight-forward substitution. >> > Well, using myself for an example, I'm used to using a completely > different set of tokens and substitutions for that sort of thing. I > think SL is the only thing I use that supports the old IRC syntax. I > find it awkward, and it would be nice to be able to use conventions that > are more common to the software that I use. As a post-processed > substitution token, though, I just don't have the luxury to use familiar > textual communication modes. > > -- > Tateru Nino > http://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 > From joel.foner at gmail.com Wed Jan 12 14:32:40 2011 From: joel.foner at gmail.com (Joel Foner) Date: Wed, 12 Jan 2011 17:32:40 -0500 Subject: [opensource-dev] Pre-processing chat input (was Re: Review Request: STORM-829 Viewer 2 does not parse /me in object Instant Messages In-Reply-To: References: <4D2DAD11.8010302@gmail.com> <4D2DC627.9030904@beau.org> <4D2DC807.4080004@taterunino.net> Message-ID: Skype still supports /me... Many of the folks I know use /me regularly, for what it's worth. Skype displays the difference much more obviously, placing the text centered with different styling than normal chat with /me, so it has more emphasis than in sl visually. Joel On Jan 12, 2011 5:21 PM, "Ricky" wrote: > Interesting. I haven't tested other IM clients in recent history, but > Skype still supports the /me syntax. I suspect that the others do so > as well. > > Just my L$2... > > Ricky > Cron Stardust > > On Wed, Jan 12, 2011 at 7:25 AM, Tateru Nino wrote: >> >> >> On 13/01/2011 2:17 AM, Jamey Fletcher wrote: >>> Tateru Nino wrote: >>> >>>> Which is a shame. It's significantly less versatile that way. >>>> On 13/01/2011 12:06 AM, Nexii Malthus wrote: >>>>> "/me " is a *post-process*. >>> I'm missing what versatility we're wanting in /me - I've always seen it >>> as a rather straight-forward substitution. >>> >> Well, using myself for an example, I'm used to using a completely >> different set of tokens and substitutions for that sort of thing. I >> think SL is the only thing I use that supports the old IRC syntax. I >> find it awkward, and it would be nice to be able to use conventions that >> are more common to the software that I use. As a post-processed >> substitution token, though, I just don't have the luxury to use familiar >> textual communication modes. >> >> -- >> Tateru Nino >> http://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 >> > _______________________________________________ > Policies 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/20110112/63dde9cf/attachment.htm From yoz at lindenlab.com Wed Jan 12 15:04:59 2011 From: yoz at lindenlab.com (Yoz Grahame) Date: Wed, 12 Jan 2011 15:04:59 -0800 Subject: [opensource-dev] web profiles. In-Reply-To: References: <4D2D25D8.90304@gmail.com> <6FB55B7C-9AD6-4E07-A02B-C8DEACF42B78@lindenlab.com> Message-ID: On 12 January 2011 09:54, Erin Mallory wrote: > there are now separate child issues or linked issues to most of the > relevant points raised, linked to > http://jira.secondlife.com/browse/web-3494 so if people don't agree with > parts, they can now vote for the parts they do agree with. I've also toned > down some of the language. > Many thanks, Erin. Argent: If you could file a WEB + my.secondlife.com issue, we'll discuss it there. Thanks! -- Yoz -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110112/ab6a599f/attachment.htm From trilobyte550m at gmail.com Wed Jan 12 16:43:15 2011 From: trilobyte550m at gmail.com (Trilo Byte) Date: Wed, 12 Jan 2011 16:43:15 -0800 Subject: [opensource-dev] What client for Havok 2k10 / mesh testing? In-Reply-To: References: <0098F56B-FCAF-4D11-AE96-5D53848D04D9@gmail.com> Message-ID: Point taken, it does say merged on the server end. That should mean any viewer you're able to use to log into mesh city will work, with Mesh sandbox 2/15/22/32 using old physics, all other mesh regions running 2k10. On Jan 12, 2011, at 1:23 PM, Stickman wrote: > On Wed, Jan 12, 2011 at 1:24 AM, Trilo Byte wrote: >> According to the Havok 2k10 Beta page on the wiki, the Mesh Project Viewer now contains the necessary bits for the physics engine upgrade (second sentence in the "What is Havok 2k10" section). >> https://wiki.secondlife.com/wiki/Havok_2k10_Beta_Home > > "It has merged into the Mesh server branch and deployed to ADITI for > your verification pleasure." > > Server, not viewer. I'll happily be wrong, truth is more important > than being right, but the expensive, proprietary, and closed source > havok code does not appear in the client except for the closed source > mesh decomposition... thing... used for uploading meshes. > > However if the mesh servers are the only ones that have the new > physics code, then it would be pretty silly to not have the mesh > viewer, yes. I remembered there being other regions that had havok 10 > that weren't tied to mesh, but if you're gonna test it, why not test > it with mesh. > > Stickman From twisted_laws at hotmail.com Wed Jan 12 17:46:30 2011 From: twisted_laws at hotmail.com (Twisted Laws) Date: Wed, 12 Jan 2011 20:46:30 -0500 Subject: [opensource-dev] failed to find libboost_system-vc80-mt-1_39.lib in non-standalone Message-ID: A fresh clone of viewer-development up to r14487:5f4034c58817 1/12/2011 fails to buid non-standalone because of missing the libboost_system-vc80-mt-1_39.lib (or debug version). -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110112/95fcd055/attachment.htm From twisted_laws at hotmail.com Wed Jan 12 20:34:58 2011 From: twisted_laws at hotmail.com (Twisted Laws) Date: Wed, 12 Jan 2011 23:34:58 -0500 Subject: [opensource-dev] failed to find libboost_system-vc80-mt-1_39.lib in non-standalone In-Reply-To: References: Message-ID: of course i forgot to say on Windows 7 64 with vc 2005 express From: twisted_laws at hotmail.com To: opensource-dev at lists.secondlife.com Date: Wed, 12 Jan 2011 20:46:30 -0500 Subject: [opensource-dev] failed to find libboost_system-vc80-mt-1_39.lib in non-standalone A fresh clone of viewer-development up to r14487:5f4034c58817 1/12/2011 fails to buid non-standalone because of missing the libboost_system-vc80-mt-1_39.lib (or debug version). _______________________________________________ Policies 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/20110112/1b3c4039/attachment.htm From Lance.Corrimal at eregion.de Thu Jan 13 03:56:56 2011 From: Lance.Corrimal at eregion.de (Lance Corrimal) Date: Thu, 13 Jan 2011 12:56:56 +0100 Subject: [opensource-dev] build problem related to boost Message-ID: <201101131256.57291.Lance.Corrimal@eregion.de> hi there, I'm trying to add a new feature to my 2.4-based version of dolphinviewer, but I'm having serious pains with adding a callback for a new ui element. I added a combobox to the inventory panel, and two buttons. The buttons work ok, but as soon as I put a line in LLPanelMainInventory::postbuild() that is supposed to be adding a callback to the code that should be executed when the user uses that combobox, the build fails with a boost problem that is way past me. All i can say is that I've looked over all similar places in the code, and I do not see any noticeable difference between the way I'm trying to add a callback, and the way callbacks are added everywhere else... ok, the patch in question: http://dolphinviewer.eregion.de/files/patches/20400-13837/dolphinviewer2-0- v13837-InventoryQuickfilters_v0.patch.bz2 and here's the error that I keep getting: http://pastebin.com/Tb1Mkh6Z anybody around who could help me get that to work? thanks! bye, LC From Lance.Corrimal at eregion.de Thu Jan 13 04:15:01 2011 From: Lance.Corrimal at eregion.de (Lance Corrimal) Date: Thu, 13 Jan 2011 13:15:01 +0100 Subject: [opensource-dev] build problem related to boost In-Reply-To: <201101131256.57291.Lance.Corrimal@eregion.de> References: <201101131256.57291.Lance.Corrimal@eregion.de> Message-ID: <201101131315.01799.Lance.Corrimal@eregion.de> > ok, the patch in question: > http://dolphinviewer.eregion.de/files/patches/20400-13837/dolphinviewer2-0- > v13837-InventoryQuickfilters_v0.patch.bz2 https://bitbucket.org/LanceCorrimal/dolphinviewer2/changeset/d8b73e565bea From secret.argent at gmail.com Thu Jan 13 05:16:46 2011 From: secret.argent at gmail.com (Argent Stonecutter) Date: Thu, 13 Jan 2011 07:16:46 -0600 Subject: [opensource-dev] Pre-processing chat input (was Re: Review Request: STORM-829 Viewer 2 does not parse /me in object Instant Messages In-Reply-To: References: <4D2DAD11.8010302@gmail.com> <4D2DC627.9030904@beau.org> <4D2DC807.4080004@taterunino.net> Message-ID: <95B549E6-7E69-41AB-AD05-9E4F9679525E@gmail.com> On 2011-01-12, at 16:32, Joel Foner wrote: > Skype still supports /me... Many of the folks I know use /me regularly, for what it's worth. Skype displays the difference much more obviously, placing the text centered with different styling than normal chat with /me, so it has more emphasis than in sl visually. I don't understand why it needs to be highlighted at all. Just get rid of the ":" and if there's punctuation the following space. I find the italics in viewer two stupidly annoying. From wolfpup67 at earthlink.net Thu Jan 13 06:06:31 2011 From: wolfpup67 at earthlink.net (WolfPup Lowenhar) Date: Thu, 13 Jan 2011 09:06:31 -0500 Subject: [opensource-dev] failed to find libboost_system-vc80-mt-1_39.lib in non-standalone In-Reply-To: References: Message-ID: <000c01cbb32b$14984440$3dc8ccc0$@net> The same thing happened with the mesh viewer and was fixed in https://jira.secondlife.com/browse/CTS-317 by LL updating the windows boost libs to include the missing lib. Btw this is also happening on Windows 7 32-bit using VS2005 PRO. From: opensource-dev-bounces at lists.secondlife.com [mailto:opensource-dev-bounces at lists.secondlife.com] On Behalf Of Twisted Laws Sent: Wednesday, January 12, 2011 11:35 PM To: SLDEV Subject: Re: [opensource-dev] failed to find libboost_system-vc80-mt-1_39.lib in non-standalone of course i forgot to say on Windows 7 64 with vc 2005 express _____ From: twisted_laws at hotmail.com To: opensource-dev at lists.secondlife.com Date: Wed, 12 Jan 2011 20:46:30 -0500 Subject: [opensource-dev] failed to find libboost_system-vc80-mt-1_39.lib in non-standalone A fresh clone of viewer-development up to r14487:5f4034c58817 1/12/2011 fails to buid non-standalone because of missing the libboost_system-vc80-mt-1_39.lib (or debug version). _______________________________________________ Policies 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.1191 / Virus Database: 1435/3376 - Release Date: 01/12/11 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110113/6dc151ba/attachment.htm From babytje_ab at live.com Thu Jan 13 07:32:41 2011 From: babytje_ab at live.com (Alexandrea Fride) Date: Thu, 13 Jan 2011 15:32:41 -0000 Subject: [opensource-dev] Review Request: Storm-844 "More" should be "Less" when Media Control is open In-Reply-To: <20110112140224.6852.84692@domU-12-31-38-00-90-68.compute-1.internal> References: <20110112140224.6852.84692@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110113153241.17162.48537@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/78/#review147 ----------------------------------------------------------- Tested your patch and after testing it works however you do not need to have label_selected at all it works as expected without to - Alexandrea On Jan. 12, 2011, 6:02 a.m., Jonathan Yap wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/78/ > ----------------------------------------------------------- > > (Updated Jan. 12, 2011, 6:02 a.m.) > > > Review request for Viewer. > > > Summary > ------- > > "More" should be "Less" when Media Control is open > > This is a trivial text change in an xml file. The reason I am posting this here is due to some confusion using label_selected. In this case having it set to a different value than when label is set to seems to have no effect, so I have made them identical. > > I scanned all the xml files and there are only about 5 places where label_selected is different from the preceding label= value. > > Is there any reason to revert back to having them set to different values? > i.e. label="More" and label_selected="Less" > > > This addresses bug storm-844. > http://jira.secondlife.com/browse/storm-844 > > > Diffs > ----- > > doc/contributions.txt 179e0754a27d > indra/newview/skins/default/xui/en/panel_nearby_media.xml 179e0754a27d > > Diff: http://codereview.secondlife.com/r/78/diff > > > Testing > ------- > > > Thanks, > > Jonathan > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110113/9434954a/attachment.htm From twisted_laws at hotmail.com Thu Jan 13 08:05:22 2011 From: twisted_laws at hotmail.com (Twisted Laws) Date: Thu, 13 Jan 2011 16:05:22 -0000 Subject: [opensource-dev] Review Request: Storm-844 "More" should be "Less" when Media Control is open In-Reply-To: <20110112140224.6852.84692@domU-12-31-38-00-90-68.compute-1.internal> References: <20110112140224.6852.84692@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110113160522.17389.17138@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/78/#review148 ----------------------------------------------------------- To me, this is the wrong solution. label_selected used to work to allow a button to display different text when it was selected, so you could have a button that said More until it was pressed or selected and displayed more informaiton. At that time the text could change to Less indicating that pressing the button a second time would maybe reduce the information displayed. If the button in question here doesn't change when pressing, that means that something down in the control code is wrong. - Twisted On Jan. 12, 2011, 6:02 a.m., Jonathan Yap wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/78/ > ----------------------------------------------------------- > > (Updated Jan. 12, 2011, 6:02 a.m.) > > > Review request for Viewer. > > > Summary > ------- > > "More" should be "Less" when Media Control is open > > This is a trivial text change in an xml file. The reason I am posting this here is due to some confusion using label_selected. In this case having it set to a different value than when label is set to seems to have no effect, so I have made them identical. > > I scanned all the xml files and there are only about 5 places where label_selected is different from the preceding label= value. > > Is there any reason to revert back to having them set to different values? > i.e. label="More" and label_selected="Less" > > > This addresses bug storm-844. > http://jira.secondlife.com/browse/storm-844 > > > Diffs > ----- > > doc/contributions.txt 179e0754a27d > indra/newview/skins/default/xui/en/panel_nearby_media.xml 179e0754a27d > > Diff: http://codereview.secondlife.com/r/78/diff > > > Testing > ------- > > > Thanks, > > Jonathan > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110113/90cbe77a/attachment.htm From angel_of_crimson at hotmail.com Thu Jan 13 08:17:27 2011 From: angel_of_crimson at hotmail.com (Erin Mallory) Date: Thu, 13 Jan 2011 11:17:27 -0500 Subject: [opensource-dev] Slightly off topic but need ideas how to fix Message-ID: This is slightly off topic but as the ramifications of what will happen when the old profiles are taken down is starting to get out there, merchants and content creators are starting to panic about what these new profiles mean for them. There is a a ton of content that is going to be broken by this, much of it content that businesses rely on heavily. a more full list can be found in web-3509 but a number of rewards systems, venders, and security devices found within hundreds if not thousands of SL stores are built heavily around the old profile pages and cannot be easily updated or replaced before the old profiles will likely be taken down... Even if businesses begin to switch over, that involves changing out sometimes hundreds of venders, everything associated with the venders (like gift cards etc), and during all of that the ability to make new content is affected. Many SL businesses are teetering on the edge of bankrupcy already, including many where this is the SOLE or largest percentage of income to those that simply are incapable of getting an income any other way. So I'm pleading with the lindens and devs on this list to PLEASE start putting some thought to how to mitigate this... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110113/569c01db/attachment-0001.htm From jhwelch at gmail.com Thu Jan 13 08:37:43 2011 From: jhwelch at gmail.com (Jonathan Welch) Date: Thu, 13 Jan 2011 11:37:43 -0500 Subject: [opensource-dev] Clarification on contributions.txt Message-ID: Hi Oz, I updated two wiki entries dealing with adding to contributions.txt and would appreciate it if you could look over what I wrote and tell me and the mailing list if this is what you would like to have done. http://wiki.secondlife.com/w/index.php?title=Preparing_Code&diff=1131640&oldid=1028212 Thank you, -Jonathan From opensourceobscure at gmail.com Thu Jan 13 08:55:31 2011 From: opensourceobscure at gmail.com (Opensource Obscure) Date: Thu, 13 Jan 2011 17:55:31 +0100 Subject: [opensource-dev] storm-34 In-Reply-To: <4D2DA50D.3060800@lindenlab.com> References: <9043BBD2-9063-4CC8-B34B-BBE7037D92BE@lindenlab.com> <4D2DA50D.3060800@lindenlab.com> Message-ID: Not directly related to storm-34, but slightly related to the general discussion: Kirstens Viewer shows in the login screen random screenshots of cool SL locations (I think there's a user-contributed shared database of them) - pics also embed the address of the location, so one can manually input sim name and coordinates in the "Start at" text field. Locations can be also browsed in the login page itself. Opensource Obscure From jhwelch at gmail.com Thu Jan 13 08:56:10 2011 From: jhwelch at gmail.com (Jonathan Yap) Date: Thu, 13 Jan 2011 16:56:10 -0000 Subject: [opensource-dev] Review Request: Storm-844 "More" should be "Less" when Media Control is open In-Reply-To: <20110113160522.17389.17138@domU-12-31-38-00-90-68.compute-1.internal> References: <20110113160522.17389.17138@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110113165610.17356.54652@domU-12-31-38-00-90-68.compute-1.internal> > On Jan. 13, 2011, 8:05 a.m., Twisted Laws wrote: > > To me, this is the wrong solution. label_selected used to work to allow a button to display different text when it was selected, so you could have a button that said More until it was pressed or selected and displayed more informaiton. At that time the text could change to Less indicating that pressing the button a second time would maybe reduce the information displayed. If the button in question here doesn't change when pressing, that means that something down in the control code is wrong. I did a test with the floater preview UI (one of the few places that label is not the same as label_selected. There is a >> button there that does change to << when pressed. However, in this case, there is some code that does the button swapping. In llpanelnearbymedia.cpp / void LLPanelNearByMedia::onMoreLess() getChild("more_btn")->setVisible(!is_more); getChild("less_btn")->setVisible(is_more); If people think refactoring rather then just rewording is the way to go please say so. I always hesitate to "fix what ain't broke". The vast majority of button definitions in the xml files have identical entries for label and label_selected (is having label_selected present a requirement in a button definition or are all these entires superfluous?). - Jonathan ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/78/#review148 ----------------------------------------------------------- On Jan. 12, 2011, 6:02 a.m., Jonathan Yap wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/78/ > ----------------------------------------------------------- > > (Updated Jan. 12, 2011, 6:02 a.m.) > > > Review request for Viewer. > > > Summary > ------- > > "More" should be "Less" when Media Control is open > > This is a trivial text change in an xml file. The reason I am posting this here is due to some confusion using label_selected. In this case having it set to a different value than when label is set to seems to have no effect, so I have made them identical. > > I scanned all the xml files and there are only about 5 places where label_selected is different from the preceding label= value. > > Is there any reason to revert back to having them set to different values? > i.e. label="More" and label_selected="Less" > > > This addresses bug storm-844. > http://jira.secondlife.com/browse/storm-844 > > > Diffs > ----- > > doc/contributions.txt 179e0754a27d > indra/newview/skins/default/xui/en/panel_nearby_media.xml 179e0754a27d > > Diff: http://codereview.secondlife.com/r/78/diff > > > Testing > ------- > > > Thanks, > > Jonathan > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110113/d0394d96/attachment.htm From oz at lindenlab.com Thu Jan 13 09:05:21 2011 From: oz at lindenlab.com (Oz Linden (Scott Lawrence)) Date: Thu, 13 Jan 2011 12:05:21 -0500 Subject: [opensource-dev] Clarification on contributions.txt In-Reply-To: References: Message-ID: <4D2F30D1.5050708@lindenlab.com> On 2011-01-13 11:37, Jonathan Welch wrote: > Hi Oz, > > I updated two wiki entries dealing with adding to contributions.txt > and would appreciate it if you could look over what I wrote and tell > me and the mailing list if this is what you would like to have done. > > http://wiki.secondlife.com/w/index.php?title=Preparing_Code&diff=1131640&oldid=1028212 Thank you, Jonathan... you were essentially correct and that's a good addition. I tweaked what you wrote slightly. From merov at lindenlab.com Thu Jan 13 09:12:35 2011 From: merov at lindenlab.com (Philippe (Merov) Bossut) Date: Thu, 13 Jan 2011 09:12:35 -0800 Subject: [opensource-dev] failed to find libboost_system-vc80-mt-1_39.lib in non-standalone In-Reply-To: <000c01cbb32b$14984440$3dc8ccc0$@net> References: <000c01cbb32b$14984440$3dc8ccc0$@net> Message-ID: Hi, I noticed too and working on it to resolve it. Strange thing is that a build on the same code on my test viewer-development-importer repo did work fine... I'm a bit puzzled as to what is different between the 2. OTOH, it's just boost and it hasn't changed since June 2010 so it can't be that hard to fix. Certainly a case of a misplaced lib. Hmmm.... Any help appreciated of course (I'll make sure I'll be hanging out on #opensl today). Cheers, - Merov On Thu, Jan 13, 2011 at 6:06 AM, WolfPup Lowenhar wrote: > The same thing happened with the mesh viewer and was fixed in > https://jira.secondlife.com/browse/CTS-317 by LL updating the windows > boost libs to include the missing lib. Btw this is also happening on Windows > 7 32-bit using VS2005 PRO. > > > > *From:* opensource-dev-bounces at lists.secondlife.com [mailto: > opensource-dev-bounces at lists.secondlife.com] *On Behalf Of *Twisted Laws > *Sent:* Wednesday, January 12, 2011 11:35 PM > *To:* SLDEV > *Subject:* Re: [opensource-dev] failed to find > libboost_system-vc80-mt-1_39.lib in non-standalone > > > > of course i forgot to say on Windows 7 64 with vc 2005 express > > ------------------------------ > > From: twisted_laws at hotmail.com > To: opensource-dev at lists.secondlife.com > Date: Wed, 12 Jan 2011 20:46:30 -0500 > Subject: [opensource-dev] failed to find libboost_system-vc80-mt-1_39.lib > in non-standalone > > A fresh clone of viewer-development up to r14487:5f4034c58817 1/12/2011 > fails to buid non-standalone because of missing the > libboost_system-vc80-mt-1_39.lib (or debug version). > > > _______________________________________________ Policies and (un)subscribe > information available here: http://wiki.secondlife.com/wiki/OpenSource-DevPlease 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.1191 / Virus Database: 1435/3376 - Release Date: 01/12/11 > > _______________________________________________ > Policies 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/20110113/24c55432/attachment.htm From sllists at boroon.dasgupta.ch Thu Jan 13 09:25:39 2011 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Thu, 13 Jan 2011 18:25:39 +0100 Subject: [opensource-dev] Clarification on contributions.txt In-Reply-To: <4D2F30D1.5050708@lindenlab.com> References: <4D2F30D1.5050708@lindenlab.com> Message-ID: <4D2F3593.9060503@boroon.dasgupta.ch> [Sent from wrong address, so once again for the list. Sorry Oz for the duplicate message.] On 01/13/2011 06:05 PM, Oz Linden (Scott Lawrence) wrote: > On 2011-01-13 11:37, Jonathan Welch wrote: >> Hi Oz, >> >> I updated two wiki entries dealing with adding to contributions.txt >> and would appreciate it if you could look over what I wrote and tell >> me and the mailing list if this is what you would like to have done. >> >> http://wiki.secondlife.com/w/index.php?title=Preparing_Code&diff=1131640&oldid=1028212 > Thank you, Jonathan... you were essentially correct and that's a good > addition. I tweaked what you wrote slightly. Should new entries really always be added below existing ones of the same person, or could they be added at the 'right' position (if any), as long as existing entries aren't moved around nor removed? E.g., if we have Example Resident FOO-1000 FOO-3000 and Example Resident implements FOO-2000, should that become Example Resident FOO-1000 * FOO-2000* FOO-3000 (i.e. added at "right" position) or Example Resident FOO-1000 FOO-3000 * FOO-2000* (i.e. added below existing entries)? Also, could you make your metric-generating code public? Maybe someone can adapt it to not be mislead by re-sorting of issue entries. Cheers, Boroondas -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110113/e31c8adb/attachment-0001.htm From jhwelch at gmail.com Thu Jan 13 09:45:06 2011 From: jhwelch at gmail.com (Jonathan Welch) Date: Thu, 13 Jan 2011 12:45:06 -0500 Subject: [opensource-dev] Clarification on contributions.txt In-Reply-To: <4D2F30D1.5050708@lindenlab.com> References: <4D2F30D1.5050708@lindenlab.com> Message-ID: Oz, I updated the similar entry at https://wiki.secondlife.com/wiki/How_To_Submit_A_Viewer_Change#Readiness_Criteria with your tweak. From merov at lindenlab.com Thu Jan 13 10:22:05 2011 From: merov at lindenlab.com (Philippe (Merov) Bossut) Date: Thu, 13 Jan 2011 10:22:05 -0800 Subject: [opensource-dev] failed to find libboost_system-vc80-mt-1_39.lib in non-standalone In-Reply-To: References: <000c01cbb32b$14984440$3dc8ccc0$@net> Message-ID: Hi, The problem comes from changes in STORM-477 which is now requiring boost-system libs but we don't have that lib for windows in the prebuilt tarball. It turns out we are in the process of creating a boost-autobuild project so we'll get that fixed as part of this. In the meantime though, I'll backout the STORM-477 changes, create a new task for boost update and make STORM-477 depend on it. Things should be back to normal within a couple of hours. Sorry for the disruption. Cheers, - Merov On Thu, Jan 13, 2011 at 9:12 AM, Philippe (Merov) Bossut < merov at lindenlab.com> wrote: > Hi, > > I noticed too and working on it to resolve it. Strange thing is that a > build on the same code on my test viewer-development-importer repo did work > fine... I'm a bit puzzled as to what is different between the 2. OTOH, it's > just boost and it hasn't changed since June 2010 so it can't be that hard to > fix. Certainly a case of a misplaced lib. Hmmm.... Any help appreciated of > course (I'll make sure I'll be hanging out on #opensl today). > > Cheers, > - Merov > > On Thu, Jan 13, 2011 at 6:06 AM, WolfPup Lowenhar > wrote: > >> The same thing happened with the mesh viewer and was fixed in >> https://jira.secondlife.com/browse/CTS-317 by LL updating the windows >> boost libs to include the missing lib. Btw this is also happening on Windows >> 7 32-bit using VS2005 PRO. >> >> >> >> *From:* opensource-dev-bounces at lists.secondlife.com [mailto: >> opensource-dev-bounces at lists.secondlife.com] *On Behalf Of *Twisted Laws >> *Sent:* Wednesday, January 12, 2011 11:35 PM >> *To:* SLDEV >> *Subject:* Re: [opensource-dev] failed to find >> libboost_system-vc80-mt-1_39.lib in non-standalone >> >> >> >> of course i forgot to say on Windows 7 64 with vc 2005 express >> >> ------------------------------ >> >> From: twisted_laws at hotmail.com >> To: opensource-dev at lists.secondlife.com >> Date: Wed, 12 Jan 2011 20:46:30 -0500 >> Subject: [opensource-dev] failed to find libboost_system-vc80-mt-1_39.lib >> in non-standalone >> >> A fresh clone of viewer-development up to r14487:5f4034c58817 1/12/2011 >> fails to buid non-standalone because of missing the >> libboost_system-vc80-mt-1_39.lib (or debug version). >> >> >> _______________________________________________ Policies 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.1191 / Virus Database: 1435/3376 - Release Date: 01/12/11 >> >> _______________________________________________ >> >> Policies 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/20110113/a13fd248/attachment.htm From kf6kjg at gmail.com Thu Jan 13 10:29:31 2011 From: kf6kjg at gmail.com (Ricky) Date: Thu, 13 Jan 2011 10:29:31 -0800 Subject: [opensource-dev] Pre-processing chat input (was Re: Review Request: STORM-829 Viewer 2 does not parse /me in object Instant Messages In-Reply-To: <95B549E6-7E69-41AB-AD05-9E4F9679525E@gmail.com> References: <4D2DAD11.8010302@gmail.com> <4D2DC627.9030904@beau.org> <4D2DC807.4080004@taterunino.net> <95B549E6-7E69-41AB-AD05-9E4F9679525E@gmail.com> Message-ID: I tend to agree with you Argent. Just a simple replace is fine. While the tools I mentioned seem to all support the "/me" syntax, and may even specially highlight such messages, I'd rather that they didn't. In actual chat I don't find myself using "/me" a lot, whether in SL or out. However, I DO use it in LSL extensively. Ricky Cron Stardust On Thu, Jan 13, 2011 at 5:16 AM, Argent Stonecutter wrote: > On 2011-01-12, at 16:32, Joel Foner wrote: >> Skype still supports /me... Many of the folks I know use /me regularly, for what it's worth. Skype displays the ?difference much more obviously, placing the text centered with different styling than normal chat with /me, so it has more emphasis than in sl visually. > > I don't understand why it needs to be highlighted at all. Just get rid of the ":" and if there's punctuation the following space. I find the italics in viewer two stupidly annoying. From sythos at gmail.com Thu Jan 13 12:13:32 2011 From: sythos at gmail.com (Altair Sythos Memo) Date: Thu, 13 Jan 2011 21:13:32 +0100 Subject: [opensource-dev] Slightly off topic but need ideas how to fix In-Reply-To: References: Message-ID: <20110113211332.94a2ffb5.sythos@gmail.com> On Thu, 13 Jan 2011 11:17:27 -0500 Erin Mallory wrote: > > This is slightly off topic but as the ramifications of what will > happen when the old profiles are taken down is starting to get out > there, merchants and content creators are starting to panic about > what these new profiles mean for them. There is a a ton of content > that is going to be broken by this, much of it content that > businesses rely on heavily. a more full list can be found in web-3509 > but a number of rewards systems, venders, and security devices found > within hundreds if not thousands of SL stores are built heavily > around the old profile pages and cannot be easily updated or replaced > before the old profiles will likely be taken down... Even if > businesses begin to switch over, that involves changing out sometimes > hundreds of venders, everything associated with the venders (like > gift cards etc), and during all of that the ability to make new > content is affected. Many SL businesses are teetering on the edge of > bankrupcy already, including many where this is the SOLE or largest > percentage of income to those that simply are incapable of getting an > income any other way. So I'm pleading with the lindens and devs on > this list to PLEASE start putting some thought to how to mitigate > this... i'm sorry but don't understand how web interface to show profile data can involve business..... scripts still work in both directions (groups, key2name, the new istr about display names), and web interface is just a re-design of the "old" profile in sidebar (upper piece SL-photo +SL desc, just under RL photo +info, on a sie groups and picks), is just a interface design... you can stil ask for friendship, open an IM, offer a teleport, invite to a group (and bot can still invite to groups), so how shops, security systems and other can be involded by web profiles? From cinder at cinderblocks.biz Thu Jan 13 12:31:28 2011 From: cinder at cinderblocks.biz (Cinder Roxley) Date: Thu, 13 Jan 2011 13:31:28 -0700 Subject: [opensource-dev] Slightly off topic but need ideas how to fix In-Reply-To: <20110113211332.94a2ffb5.sythos@gmail.com> References: <20110113211332.94a2ffb5.sythos@gmail.com> Message-ID: On Thu, 13 Jan 2011 13:13:32 -0700, Altair Sythos Memo wrote: > On Thu, 13 Jan 2011 11:17:27 -0500 > Erin Mallory wrote: > >> >> This is slightly off topic but as the ramifications of what will >> happen when the old profiles are taken down is starting to get out >> there, merchants and content creators are starting to panic about >> what these new profiles mean for them. There is a a ton of content >> that is going to be broken by this, much of it content that >> businesses rely on heavily. a more full list can be found in web-3509 >> but a number of rewards systems, venders, and security devices found >> within hundreds if not thousands of SL stores are built heavily >> around the old profile pages and cannot be easily updated or replaced >> before the old profiles will likely be taken down... Even if >> businesses begin to switch over, that involves changing out sometimes >> hundreds of venders, everything associated with the venders (like >> gift cards etc), and during all of that the ability to make new >> content is affected. Many SL businesses are teetering on the edge of >> bankrupcy already, including many where this is the SOLE or largest >> percentage of income to those that simply are incapable of getting an >> income any other way. So I'm pleading with the lindens and devs on >> this list to PLEASE start putting some thought to how to mitigate >> this... > > i'm sorry but don't understand how web interface to show profile data > can involve business..... scripts still work in both directions > (groups, key2name, the new istr about display names), and web interface > is just a re-design of the "old" profile in sidebar (upper piece > SL-photo +SL desc, just under RL photo +info, on a sie groups and > picks), is just a interface design... you can stil ask for friendship, > open an IM, offer a teleport, invite to a group (and bot can still > invite to groups), so how shops, security systems and other can be > involded by web profiles? Poor design that involves grepping world.secondlife.com for information which is pushed to outworld databases. (something Erin seems vehemently against in her dozen other recent JIRA bug reports on webprofiles). I don't see how it's a "critical bug" that content creators wouldn't be able to mine world.secondlife.com anymore for userkeys, groups, profile pics, etc on their outworld servers. -- Sent from my Tracfone! From akanevsky at productengine.com Thu Jan 13 13:13:31 2011 From: akanevsky at productengine.com (Anya Kanevsky) Date: Thu, 13 Jan 2011 15:13:31 -0600 Subject: [opensource-dev] Daily Scrum Summary - Thursday, January 13, 2011 Message-ID: Thursday, January 13, 2011 General Notes ------------------------------ - MMOTD: Merov Team Status ------------------------------ Merov Linden ------------------------------ *PAST* - MM: lots of integration to 2.6, cleared up sprint 9 and sprint 8 lists - viewer-development build failure: STORM-477 changes to boost.cmake are the issue - STORM-748 and STORM-746: looked into those KDU improvements *FUTURE* - Merge Monkeying: need to back out STORM-477 - STORM-748 : rebuild kdu libs using KDU_X86_INTRINSICS - STORM-745 : Produce comprehensive perf baseline: *IMPEDIMENTS* - Windows builds on TC keep timing out. Working with CG on this. Oz Linden ------------------------------ *PAST* - Upgrade reviewboard on codereview (STORM-862) - Internal team meeting *FUTURE* - Finish (for now) wiki docs on reviews (STORM-691) - STORM-692 set up codereview service monitor *IMPEDIMENTS* - Blizzard & Snowblower breakdown (fixed) Q Linden ------------------------------ *PAST* - STORM-724, turned out to be obsolete; I eventually closed it but it took a couple of hours to figure that out. - Internal meetings - 2.5 beta 1 - WFH *FUTURE* - STORM-725 - triage *IMPEDIMENTS* that I don't want anyone to try to fix: - Boston Holiday Party tonight Esbee Linden ------------------------------ *PAST* - Meetings, Email - Review tickets assigned to Aimee and Moss - Play with Viewer 2.5 Beta 1 *FUTURE* - Boston office holiday party - Post and publish Viewer 2.5 Beta 1 blog post - Review Snowstorm Team product backlog and bug log - PO reviews for open tickets - Review Jira for tickets assigned to Aimee or Moss and make some decisions about where those tickets should go :( - Come up with design for STORM-28 (Might pass this to XD) - Look at STORM-812 - Take another look at Wolfpup's proposal for STORM-236. PE is not available to help with this ticket for now, we'll likely have to reconsider this ticket for Sprint 11. *IMPEDIMENTS* - none Paul ProductEngine ------------------------------ *PAST* - BUG STORM-832 (Two Roles are selected after made changes in one.) - Tested and sent for review - BUG STORM-433 (Friendship offer shifted up and placed over "Second Life" text) - Resolved as cannot reproduce - BUG STORM-392 (Truncated text between accordions in My Profile > My Picks tab) - Resolved as cannot reproduce - BUG STORM-834 (Color picker remains opened after 'Undo changes' button was pressed on 'Edit weareble' panel) - WIP. Estimate ~ 3-5 hours *FUTURE* - BUG STORM- (Color picker remains opened after 'Undo changes' button was pressed on 'Edit weareble' panel) - Other tickets by priority *IMPEDIMENTS* - Waiting for answer in STORM-429 before i begin to fix it. Seth Productengine ------------------------------ *PAST* - BUG (STORM-383) Context menu cannot be open for Landmark that are located in the My inventory->Trash folder - WIP. Added "Restore" context menu item for landmarks in Trash. Works only for gear menu so far, it needs to be added to right click menu also. *FUTURE* - BUG (STORM-383) Context menu cannot be open for Landmark that are located in the My inventory->Trash folder *IMPEDIMENTS* - TASK (STORM-797) Parcel SLURL rendering - BUG (STORM-447) User is not able to share multi selected objects using drag&drop Vadim Productengine ------------------------------ *PAST* - Task STORM-2 (Customizable viewer layouts): - Reviewed and tested. The feature is not quite ready for publishing. - Task STORM-174 (Checkbox needed to save inventory scripts as Mono): - Commented in ticket that the feature cannot be implemented without changes to simulator. *FUTURE* - Bug STORM-526 (Log out failure during Login causes loss of pending offers, including inventory). *IMPEDIMENTS* - Unclear what to do with STORM-174 (Checkbox needed to save inventory scripts as Mono): - the feature requires simulator work. - Need Esbee's answer in STORM-243 (Suppress version change message in the viewer). - No clear acceptance criteria for STORM-226 (Floating Text aligns improperly). Andrey Productengine ------------------------------ *PAST* - continued 2.5.0 Beta1 testing - started IQA-69 - web profiles and webkit testing - proceed with IQA-67 - 2.5.0 bug-fixes verification *FUTURE* - finish IQA-69 stuff testing - may be finish bug-fixes verification *IMPEDIMENTS* - none Jonathan Yap ------------------------------ *PAST* - STORM-844 ("More" should be "Less" when Media Control is open) - Responded to codereview comments. - Updated wiki in two places on adding to doc/contributions.txt and emailed Oz asking if this is what he wants. *FUTURE* - STORM - 845 *IMPEDIMENTS* - none Wolfpup Lowenhar ------------------------------ *PAST* - Worked @ RL and in world. - STORM-236 : did recive reply and putting on hold since was not brought into this sprint - Attended Esbee's OH. *FUTURE* - see if can find some thing for this sprint - Work @ RL and in world. - VWR-24256 : continue to monitor. *IMPEDIMENTS* - Not enough time between working in-world and at real job to actually work on code. - Loss of place inworld to do any major work. Cummere Mayo ------------------------------ *PAST* - sorting jira snow issues - organizing jira issues - 3/8 the way through *FUTURE* - same *IMPEDIMENTS* - none -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110113/69565f9d/attachment-0001.htm From oz at lindenlab.com Thu Jan 13 13:22:52 2011 From: oz at lindenlab.com (Oz Linden (Scott Lawrence)) Date: Thu, 13 Jan 2011 16:22:52 -0500 Subject: [opensource-dev] Clarification on contributions.txt In-Reply-To: <4D2F3593.9060503@boroon.dasgupta.ch> References: <4D2F30D1.5050708@lindenlab.com> <4D2F3593.9060503@boroon.dasgupta.ch> Message-ID: <4D2F6D2C.7090807@lindenlab.com> On 2011-01-13 12:25, Boroondas Gupte wrote: > [Sent from wrong address, so once again for the list. Sorry Oz for the > duplicate message.] > > On 01/13/2011 06:05 PM, Oz Linden (Scott Lawrence) wrote: >> On 2011-01-13 11:37, Jonathan Welch wrote: >>> Hi Oz, >>> >>> I updated two wiki entries dealing with adding to contributions.txt >>> and would appreciate it if you could look over what I wrote and tell >>> me and the mailing list if this is what you would like to have done. >>> >>> http://wiki.secondlife.com/w/index.php?title=Preparing_Code&diff=1131640&oldid=1028212 >> Thank you, Jonathan... you were essentially correct and that's a good >> addition. I tweaked what you wrote slightly. > Should new entries really always be added below existing ones of the > same person, or could they be added at the 'right' position (if any), > as long as existing entries aren't moved around nor removed? Insertion anywhere under the right person is fine, so insertion at the 'right' sorted location is ok. > Also, could you make your metric-generating code public? Maybe someone > can adapt it to not be mislead by re-sorting of issue entries. There's a threshold of code cleanliness below which I prefer not to publish. I'll have to think about whether or not this meets that test. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110113/b0849bb7/attachment.htm From opensourceobscure at gmail.com Fri Jan 14 04:40:12 2011 From: opensourceobscure at gmail.com (Opensource Obscure) Date: Fri, 14 Jan 2011 13:40:12 +0100 Subject: [opensource-dev] Slightly off topic but need ideas how to fix In-Reply-To: References: <20110113211332.94a2ffb5.sythos@gmail.com> Message-ID: [ Is this really on-topic? ] I agree with Cinder. I personally use some of these tools (even if not for business) and I find them useful. Still, it's well known that services built upon non-supported basis (like the specific HTML code used in the old profile pages) will break soon or later, and LL never supported officially scraping of its website as a feature itself. Some businesses may be negatively impacted by the change, sure, but I don't see this becoming a large-scale problem at all - especially if compared to other SL problems. Opensource Obscure From tateru at taterunino.net Fri Jan 14 04:59:40 2011 From: tateru at taterunino.net (Tateru Nino) Date: Fri, 14 Jan 2011 23:59:40 +1100 Subject: [opensource-dev] Slightly off topic but need ideas how to fix In-Reply-To: <20110113211332.94a2ffb5.sythos@gmail.com> References: <20110113211332.94a2ffb5.sythos@gmail.com> Message-ID: <4D3048BC.8030809@taterunino.net> On 14/01/2011 7:13 AM, Altair Sythos Memo wrote: > On Thu, 13 Jan 2011 11:17:27 -0500 > Erin Mallory wrote: > >> This is slightly off topic but as the ramifications of what will >> happen when the old profiles are taken down is starting to get out >> there, merchants and content creators are starting to panic about >> what these new profiles mean for them. There is a a ton of content >> that is going to be broken by this, much of it content that >> businesses rely on heavily. a more full list can be found in web-3509 >> but a number of rewards systems, venders, and security devices found >> within hundreds if not thousands of SL stores are built heavily >> around the old profile pages and cannot be easily updated or replaced >> before the old profiles will likely be taken down... Even if >> businesses begin to switch over, that involves changing out sometimes >> hundreds of venders, everything associated with the venders (like >> gift cards etc), and during all of that the ability to make new >> content is affected. Many SL businesses are teetering on the edge of >> bankrupcy already, including many where this is the SOLE or largest >> percentage of income to those that simply are incapable of getting an >> income any other way. So I'm pleading with the lindens and devs on >> this list to PLEASE start putting some thought to how to mitigate >> this... > i'm sorry but don't understand how web interface to show profile data > can involve business..... scripts still work in both directions > (groups, key2name, the new istr about display names), and web interface > is just a re-design of the "old" profile in sidebar (upper piece > SL-photo +SL desc, just under RL photo +info, on a sie groups and > picks), is just a interface design... you can stil ask for friendship, > open an IM, offer a teleport, invite to a group (and bot can still > invite to groups), so how shops, security systems and other can be > involded by web profiles? > Some businesses used the presence of picks to their locations in a user's profile as a method of gaming the search system, and set up scripts that would scrape the previous version web-profiles for data about whether a particular person had those picks on their profile and autopay them trivial amounts for it if they kept the picks for a long enough period. Since my understanding is that picks don't affect search-results any-longer, however, I don't see that as a huge problem. Some businesses still keep the practice up, however, believing that it still works. -- Tateru Nino http://dwellonit.taterunino.net/ From twisted_laws at hotmail.com Fri Jan 14 06:46:58 2011 From: twisted_laws at hotmail.com (Twisted Laws) Date: Fri, 14 Jan 2011 14:46:58 -0000 Subject: [opensource-dev] Review Request: Storm-844 "More" should be "Less" when Media Control is open In-Reply-To: <20110113160522.17389.17138@domU-12-31-38-00-90-68.compute-1.internal> References: <20110113160522.17389.17138@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110114144658.17158.19056@domU-12-31-38-00-90-68.compute-1.internal> > On Jan. 13, 2011, 8:05 a.m., Twisted Laws wrote: > > To me, this is the wrong solution. label_selected used to work to allow a button to display different text when it was selected, so you could have a button that said More until it was pressed or selected and displayed more informaiton. At that time the text could change to Less indicating that pressing the button a second time would maybe reduce the information displayed. If the button in question here doesn't change when pressing, that means that something down in the control code is wrong. > > Jonathan Yap wrote: > I did a test with the floater preview UI (one of the few places that label is not the same as label_selected. There is a >> button there that does change to << when pressed. > > However, in this case, there is some code that does the button swapping. In llpanelnearbymedia.cpp / void LLPanelNearByMedia::onMoreLess() > > getChild("more_btn")->setVisible(!is_more); > getChild("less_btn")->setVisible(is_more); > > If people think refactoring rather then just rewording is the way to go please say so. I always hesitate to "fix what ain't broke". > > The vast majority of button definitions in the xml files have identical entries for label and label_selected (is having label_selected present a requirement in a button definition or are all these entires superfluous?). I looked into this and have a patch that corrects it. What the patch does in llPanelNearByMedia::onMoreLess(), the first statement is changed to bool is_more = getChild("more_btn")->getToggleState(); the two statements Jonathan shows are changed to just one getChild("more_btn")->setVisible(true); (may just be removed and not be necessary) and in the xml file, the first more_btn gets is_toggle="true" added and the less_btn is removed. My patch file is attached to STORM-844. - Twisted ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/78/#review148 ----------------------------------------------------------- On Jan. 12, 2011, 6:02 a.m., Jonathan Yap wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/78/ > ----------------------------------------------------------- > > (Updated Jan. 12, 2011, 6:02 a.m.) > > > Review request for Viewer. > > > Summary > ------- > > "More" should be "Less" when Media Control is open > > This is a trivial text change in an xml file. The reason I am posting this here is due to some confusion using label_selected. In this case having it set to a different value than when label is set to seems to have no effect, so I have made them identical. > > I scanned all the xml files and there are only about 5 places where label_selected is different from the preceding label= value. > > Is there any reason to revert back to having them set to different values? > i.e. label="More" and label_selected="Less" > > > This addresses bug storm-844. > http://jira.secondlife.com/browse/storm-844 > > > Diffs > ----- > > doc/contributions.txt 179e0754a27d > indra/newview/skins/default/xui/en/panel_nearby_media.xml 179e0754a27d > > Diff: http://codereview.secondlife.com/r/78/diff > > > Testing > ------- > > > Thanks, > > Jonathan > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110114/b4cba853/attachment.htm From jhwelch at gmail.com Fri Jan 14 09:04:34 2011 From: jhwelch at gmail.com (Jonathan Welch) Date: Fri, 14 Jan 2011 12:04:34 -0500 Subject: [opensource-dev] Link times Message-ID: I just did a quick study on link times for various viewers on my 2Gb XP system Viewer 1st link 2nd link CV 1.22 0:53 0:24 SG 1.5 3:30 2:07 V2.5 6:18 6:01 I watched my memory usage during the V2.5 link and did not see it get to an extremely low value. The sizes of the .exe files are all pretty similar. Does anyone have a recommendation on how to improve my link times? 1) Add 1Gb of memory (not clear if this would help, but it would be a cheap experiment) 2) ? -Jonathan From angel_of_crimson at hotmail.com Fri Jan 14 09:32:36 2011 From: angel_of_crimson at hotmail.com (Erin Mallory) Date: Fri, 14 Jan 2011 12:32:36 -0500 Subject: [opensource-dev] Slightly off topic but need ideas how to fix In-Reply-To: References: , <20110113211332.94a2ffb5.sythos@gmail.com>, , Message-ID: Alot of businesses rely on gift venders that use the profiles to find people and rewards systems that use the profiles. It usually takes a week or more for a business to switch vender systems, and during that time they usually don't get anything new made. Many stores rely on minimum weekly incomes to be able to stay in business and/or support their rl selves and/or families. drastic changes like these made with so little thought/warning to the community hurt more then they help. especially when done with so little impact from the groups that they will actually impact. I really prey that these new topic-based office hours will have one for merchants needs on the web, and one for merchants needs in world. because for the past two years merchants needs have appeared (and i use that word deliberately) to not only be ignored by developers, but that developers have moved in the direct opposite direction. I know this isn't the case, but it really appears that way. I would really like it this year if snowstorm could focus part of the year (maybe February through may?) on sprints designed to really help merchants and content creators. specifically: 1) improvements to the clothing/skin/shape creation 2) making it easier to make and track classifies from in world (something that seems impossible to do now in 2.6) 3) building tool improvements. 4) coordinating and beginner the viewer work (or finding another team to do it) for the avatar 2.0 project. 5) drag and drop outfit editor and building tools. 6) better inventory search tools and inworld inventory recovery tools > Date: Fri, 14 Jan 2011 13:40:12 +0100 > From: opensourceobscure at gmail.com > To: cinder at cinderblocks.biz > CC: opensource-dev at lists.secondlife.com > Subject: Re: [opensource-dev] Slightly off topic but need ideas how to fix > > [ Is this really on-topic? ] > > > I agree with Cinder. > > I personally use some of these tools (even if not for business) > and I find them useful. > > Still, it's well known that services built upon non-supported basis > (like the specific HTML code used in the old profile pages) > will break soon or later, and LL never supported officially > scraping of its website as a feature itself. > > Some businesses may be negatively impacted by the change, > sure, but I don't see this becoming a large-scale problem > at all - especially if compared to other SL problems. > > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110114/099e83a4/attachment-0001.htm From Aleric.Inglewood at gmail.com Fri Jan 14 12:21:36 2011 From: Aleric.Inglewood at gmail.com (Aleric Inglewood) Date: Fri, 14 Jan 2011 20:21:36 -0000 Subject: [opensource-dev] Review Request: VWR-13040: LLObjectSelection::valid_root_begin() is really the same as LLObjectSelection::root_begin() Message-ID: <20110114202136.17389.23681@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/79/ ----------------------------------------------------------- Review request for Viewer. Summary ------- See https://jira.secondlife.com/browse/VWR-13040 This addresses bug VWR-13040. http://jira.secondlife.com/browse/VWR-13040 Diffs ----- doc/contributions.txt b0bd26c5638a indra/newview/llselectmgr.h b0bd26c5638a Diff: http://codereview.secondlife.com/r/79/diff Testing ------- Been using this ever since that jira/patch was created. Thanks, Aleric -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110114/0fe9ac04/attachment.htm From Aleric.Inglewood at gmail.com Fri Jan 14 12:26:27 2011 From: Aleric.Inglewood at gmail.com (Aleric Inglewood) Date: Fri, 14 Jan 2011 20:26:27 -0000 Subject: [opensource-dev] Review Request: VWR-24311: Uninstall packages that are renewed. Message-ID: <20110114202627.17162.52400@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/80/ ----------------------------------------------------------- Review request for Viewer. Summary ------- See https://jira.secondlife.com/browse/VWR-24311 Basically, this fixes the TODO comment in install.py but with the difference that we really want to uninstall any old package with the same name, different md5 or not. This addresses bug VWR-24311. http://jira.secondlife.com/browse/VWR-24311 Diffs ----- doc/contributions.txt b0bd26c5638a scripts/install.py b0bd26c5638a Diff: http://codereview.secondlife.com/r/80/diff Testing ------- Loads of testing on linux... Installing new packages now cleanly removes the old one first. Thanks, Aleric -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110114/92da6ca3/attachment.htm From Aleric.Inglewood at gmail.com Fri Jan 14 12:34:11 2011 From: Aleric.Inglewood at gmail.com (Aleric Inglewood) Date: Fri, 14 Jan 2011 20:34:11 -0000 Subject: [opensource-dev] Review Request: VWR-24312: Massively duplicated objects (part 2) Message-ID: <20110114203411.17162.12107@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/81/ ----------------------------------------------------------- Review request for Viewer. Summary ------- Turns out that most of my SNOW-800 patch was included in Viewer 2 (albeit without crediting me). However, not everything was used and some more cleaning up was possible. After this patch, and when compiling with optimization, there are no duplicates left anymore that shouldn't be there in the first place: apart from the debug stream iostream guard variable, there are several static variables with the same name (r, r1, r2, etc) but that indeed actually different symbol objects. Then there are a few constant POD arrays that are duplicated a hand full of times because they are accessed with a variable index (so optimizing them away is not possible). I left them like that (although defining those as extern as well would have been more consistent and not slower; in fact it would be faster theoretically because those arrays could share the same cache page then). This addresses bug VWR-24312. http://jira.secondlife.com/browse/VWR-24312 Diffs ----- doc/contributions.txt b0bd26c5638a indra/llcharacter/llanimationstates.cpp b0bd26c5638a indra/llcommon/llavatarconstants.h b0bd26c5638a indra/llcommon/lllslconstants.h b0bd26c5638a indra/llcommon/llmetricperformancetester.h b0bd26c5638a indra/llmath/llcamera.h b0bd26c5638a indra/llmath/llcamera.cpp b0bd26c5638a indra/newview/llviewerobject.cpp b0bd26c5638a indra/newview/llvoavatar.cpp b0bd26c5638a indra/newview/llvosky.h b0bd26c5638a indra/newview/llvosky.cpp b0bd26c5638a Diff: http://codereview.secondlife.com/r/81/diff Testing ------- Compiled with optimization and then running readelf on the executable to find duplicated symbols. Thanks, Aleric -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110114/13ba6a54/attachment.htm From akanevsky at productengine.com Fri Jan 14 12:35:27 2011 From: akanevsky at productengine.com (Anya Kanevsky) Date: Fri, 14 Jan 2011 14:35:27 -0600 Subject: [opensource-dev] Daily Scrum Summary - Friday, January 14 Message-ID: Friday, January 14, 2011 General Notes ------------------------------ - Still tickets needing QA verification in Sprint 8 & Sprint 9. UPD: all except dev have been verified - MMOTD: Merov - Monday is a holiday. Happy MLK day! Team Status ------------------------------ Merov Linden ------------------------------ *PAST* - MM - STORM-863 : Using --login on command line silently fails if new TOS needs accepting : worked on that with Josh, reviewed, built on all platforms, moved it to review - STORM-477 : back out that change that was making windows build fail. Issue with boost package. See here under. - STORM-865 : boost: make boost build under autobuild, add libboost_system to the tarball for windows : logged and linked to STORM-477 *FUTURE* - Merge Monkeying - STORM-748 : rebuild kdu libs using KDU_X86_INTRINSICS - STORM-745 : Produce comprehensive perf baseline *IMPEDIMENTS* - none Oz Linden ------------------------------ *PAST* - Finish (for now) wiki docs on reviews (STORM-691) - https://wiki.secondlife.com/wiki/Code_Review_Tool#Reviewing - Started configuration planning for open build system - STORM-692 set up codereview service monitor - Requested setup from Ops - Created new issue in current sprint for Aleric - STORM-862 *FUTURE* - Third Party Viewer developer meeting - Viewer dependency libs / autobuild *IMPEDIMENTS* - none Paul ProductEngine ------------------------------ *PAST* - BUG STORM-834 (Color picker remains opened after 'Undo changes' button was pressed on 'Edit weareble' panel) - Fixed and sent for review - BUG STORM-601 (My Effects colour swatch must be in focus after it was clicked.) - Investigated. Resolved as cannot reproduce. - BUG STORM-833 ("i" button is overlaid with Group Members name) - Investigated. Resolved as cannot reproduce. *FUTURE* - BUG STORM-680 (Avaline callers are added to the Recent list) *IMPEDIMENTS* - none Seth Productengine ------------------------------ *PAST* - BUG (STORM-383) Context menu cannot be open for Landmark that are located in the My inventory->Trash folder - WIP. Added "Restore" item to both context and "gear" menu for landmarks in Trash. Some issues with menu items visibility still unresolved. *FUTURE* - BUG (STORM-383) Context menu cannot be open for Landmark that are located in the My inventory->Trash folder - BUG (STORM-843) Inventory incremental string search not working (search starts over) *IMPEDIMENTS* - none Vadim Productengine ------------------------------ *PAST* - Task STORM-2 (Customizable viewer layouts): - Reviewed and tested. The feature is not quite ready for publishing. - Task STORM-174 (Checkbox needed to save inventory scripts as Mono): - Commented in ticket that the feature cannot be implemented without changes to simulator. *FUTURE* - Bug STORM-526 (Log out failure during Login causes loss of pending offers, including inventory). *IMPEDIMENTS* - Unclear what to do with STORM-174 (Checkbox needed to save inventory scripts as Mono): - the feature requires simulator work. - Need Esbee's answer in STORM-243 (Suppress version change message in the viewer). - No clear acceptance criteria for STORM-226 (Floating Text aligns improperly). Andrey Productengine ------------------------------ *PAST* - beta1 2.5.0 r218716 testing - finished with WebProfiles on Linux, OSX and Windows - WebKit testing is almost done except "Web Popups" and "4.7 basic functions", because of access issues - reported 4 tickets against Web Profiels - reopened 5 tickets against webkit *FUTURE* - switch to the latest v-d- build - verify integrated tickets *IMPEDIMENTS* - none Wolfpup Lowenhar ------------------------------ *PAST* - Worked @ RL and in world. - STORM-236 : did further investigation in Speak Button Logic then sent Esbee and Oz email after investigation.(will wait for response from Esbee as I have discussed it in IRC with Oz) *FUTURE* - May check to see if there is other things already planned for this sprint might be able to help on. - Work @ RL and in world. - VWR-24256 : continue to monitor. *IMPEDIMENTS* - Not enough time between working in-world and at real job to actually work on code. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110114/01a73120/attachment-0001.htm From Aleric.Inglewood at gmail.com Fri Jan 14 12:40:18 2011 From: Aleric.Inglewood at gmail.com (Aleric Inglewood) Date: Fri, 14 Jan 2011 20:40:18 -0000 Subject: [opensource-dev] Review Request: VWR-24315: SNOW-796: Clicking 'Reset to default' in the Debug Settings floater doesn't update cached control values. Message-ID: <20110114204018.17160.65071@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/82/ ----------------------------------------------------------- Review request for Viewer. Summary ------- See https://jira.secondlife.com/browse/VWR-24315 This addresses bug VWR-24315. http://jira.secondlife.com/browse/VWR-24315 Diffs ----- doc/contributions.txt b0bd26c5638a indra/newview/llfloatersettingsdebug.cpp b0bd26c5638a Diff: http://codereview.secondlife.com/r/82/diff Testing ------- I have some other patch that allows me to move my avatar up and down vertically (by faking it has a different height). When I open the Debug Settings floater and change the value with the up/down arrows, the avatar is immediately updated (changes height), but resetting the value (to zero) had no effect. With this patch, resetting caused the avatar to immediately change it's height to an Z-offset of zero again, as it should. Thanks, Aleric -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110114/a1c738d8/attachment.htm From Aleric.Inglewood at gmail.com Fri Jan 14 12:48:13 2011 From: Aleric.Inglewood at gmail.com (Aleric Inglewood) Date: Fri, 14 Jan 2011 20:48:13 -0000 Subject: [opensource-dev] Review Request: VWR-24317: Incorrect start up warnings: WARNING: ll_apr_warn_status: APR: No such file or directory Message-ID: <20110114204813.17158.23999@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/83/ ----------------------------------------------------------- Review request for Viewer. Summary ------- At start up one can get the following ?warnings?: 2010-10-23T12:22:44Z WARNING: ll_apr_warn_status: APR: No such file or directory 2010-10-23T12:22:44Z WARNING: remove: Attempting to remove filename: /home/aleric/.imprudence/logs/Imprudence.logout_marker 2010-10-23T12:22:44Z WARNING: ll_apr_warn_status: APR: No such file or directory 2010-10-23T12:22:44Z WARNING: remove: Attempting to remove filename: /home/aleric/.imprudence/logs/Imprudence.llerror_marker 2010-10-23T12:22:44Z WARNING: ll_apr_warn_status: APR: No such file or directory 2010-10-23T12:22:44Z WARNING: remove: Attempting to remove filename: /home/aleric/.imprudence/logs/Imprudence.error_marker This is nonsense since it is perfectly ok when those files don?t exist. This addresses bug VWR-24317. http://jira.secondlife.com/browse/VWR-24317 Diffs ----- indra/newview/llappviewer.cpp b0bd26c5638a Diff: http://codereview.secondlife.com/r/83/diff Testing ------- Thanks, Aleric -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110114/bc6c5bdf/attachment.htm From Aleric.Inglewood at gmail.com Fri Jan 14 12:50:57 2011 From: Aleric.Inglewood at gmail.com (Aleric Inglewood) Date: Fri, 14 Jan 2011 20:50:57 -0000 Subject: [opensource-dev] Review Request: VWR-24317: Incorrect start up warnings: WARNING: remove: Attempting to remove filename: /ramdisk/imprudence/cache/textures/*/*.texture Message-ID: <20110114205057.17158.38187@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/84/ ----------------------------------------------------------- Review request for Viewer. Summary ------- This turned out to be a simple matter of trying to remove non-existant files: A texture with a 'body size' of 0 doesn't have a texture body file. This addresses bug VWR-24317. http://jira.secondlife.com/browse/VWR-24317 Diffs ----- indra/newview/lltexturecache.cpp b0bd26c5638a Diff: http://codereview.secondlife.com/r/84/diff Testing ------- Thanks, Aleric -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110114/6d1bb00f/attachment.htm From Aleric.Inglewood at gmail.com Fri Jan 14 12:52:14 2011 From: Aleric.Inglewood at gmail.com (Aleric Inglewood) Date: Fri, 14 Jan 2011 20:52:14 -0000 Subject: [opensource-dev] Review Request: VWR-24317: Incorrect start up warnings: WARNING: addFeature: LLFeatureList::Attempting to add preexisting feature Disregard128DefaultDrawDistance Message-ID: <20110114205214.17156.14325@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/85/ ----------------------------------------------------------- Review request for Viewer. Summary ------- Fixes a bug that causes the last line of the feature table file to be read twice. This patch also removes the check for name.empty() because that will never be true, so might as well remove it. This addresses bug VWR-24317. http://jira.secondlife.com/browse/VWR-24317 Diffs ----- indra/newview/llfeaturemanager.cpp b0bd26c5638a Diff: http://codereview.secondlife.com/r/85/diff Testing ------- Thanks, Aleric -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110114/adfc0b73/attachment.htm From Aleric.Inglewood at gmail.com Fri Jan 14 12:53:52 2011 From: Aleric.Inglewood at gmail.com (Aleric Inglewood) Date: Fri, 14 Jan 2011 20:53:52 -0000 Subject: [opensource-dev] Review Request: VWR-24317: Incorrect start up warnings: WARNING: isFeatureAvailable: Feature RenderCubeMap not on feature list! Message-ID: <20110114205352.17160.83857@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/86/ ----------------------------------------------------------- Review request for Viewer. Summary ------- Fixes this warning. Note that LLCubeMap::sUseCubeMaps is set to true by default, so this patch only has effect when the feature is actually NOT available. I tested that LLCubeMap::sUseCubeMaps is NOT used before the point where it is initialized now. This addresses bug VWR-24317. http://jira.secondlife.com/browse/VWR-24317 Diffs ----- indra/newview/llappviewer.cpp b0bd26c5638a Diff: http://codereview.secondlife.com/r/86/diff Testing ------- Thanks, Aleric -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110114/d6079edc/attachment.htm From Aleric.Inglewood at gmail.com Fri Jan 14 12:56:12 2011 From: Aleric.Inglewood at gmail.com (Aleric Inglewood) Date: Fri, 14 Jan 2011 20:56:12 -0000 Subject: [opensource-dev] Review Request: VWR-24317: Fix of debug warning (printing of unassigned variable) Message-ID: <20110114205612.17159.77015@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/87/ ----------------------------------------------------------- Review request for Viewer. Summary ------- Fixed a typo that I stumbled upon and added quotes, and changed the warning to print something that makes more sense ('replacement' is always empty, since we didn't find it!) This addresses bug VWR-24317. http://jira.secondlife.com/browse/VWR-24317 Diffs ----- doc/contributions.txt b0bd26c5638a indra/llui/llnotifications.cpp b0bd26c5638a Diff: http://codereview.secondlife.com/r/87/diff Testing ------- Thanks, Aleric -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110114/8047d052/attachment-0001.htm From Aleric.Inglewood at gmail.com Fri Jan 14 12:58:44 2011 From: Aleric.Inglewood at gmail.com (Aleric Inglewood) Date: Fri, 14 Jan 2011 20:58:44 -0000 Subject: [opensource-dev] Review Request: VWR-24319: Fix the errors "QCursor: Cannot create bitmap cursor; invalid bitmap(s)" at start up of the webkit plugin, on linux. Message-ID: <20110114205844.20676.24901@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/88/ ----------------------------------------------------------- Review request for Viewer. Summary ------- These are caused because builtin resources of QtWebKit weren't initialized. This patch adds this initialization. This addresses bug VWR-24319. http://jira.secondlife.com/browse/VWR-24319 Diffs ----- doc/contributions.txt b0bd26c5638a indra/media_plugins/webkit/media_plugin_webkit.cpp b0bd26c5638a Diff: http://codereview.secondlife.com/r/88/diff Testing ------- Thanks, Aleric -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110114/7d58ec7e/attachment.htm From Aleric.Inglewood at gmail.com Fri Jan 14 13:00:35 2011 From: Aleric.Inglewood at gmail.com (Aleric Inglewood) Date: Fri, 14 Jan 2011 21:00:35 -0000 Subject: [opensource-dev] Review Request: VWR-24320: Don't dump callstacks at clean exit of viewer. Message-ID: <20110114210035.17162.62216@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/89/ ----------------------------------------------------------- Review request for Viewer. Summary ------- See http://jira.secondlife.com/browse/VWR-24320 This addresses bug VWR-24320. http://jira.secondlife.com/browse/VWR-24320 Diffs ----- doc/contributions.txt b0bd26c5638a indra/newview/llappviewer.cpp b0bd26c5638a Diff: http://codereview.secondlife.com/r/89/diff Testing ------- Thanks, Aleric -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110114/a4156ec1/attachment.htm From Aleric.Inglewood at gmail.com Fri Jan 14 13:02:32 2011 From: Aleric.Inglewood at gmail.com (Aleric Inglewood) Date: Fri, 14 Jan 2011 21:02:32 -0000 Subject: [opensource-dev] Review Request: VWR-24321: Validate textures starting with 00 too. Message-ID: <20110114210232.20676.90941@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/90/ ----------------------------------------------------------- Review request for Viewer. Summary ------- Trivial patch, just removes stupidity. This addresses bug VWR-24321. http://jira.secondlife.com/browse/VWR-24321 Diffs ----- doc/contributions.txt b0bd26c5638a indra/newview/lltexturecache.cpp b0bd26c5638a Diff: http://codereview.secondlife.com/r/90/diff Testing ------- Thanks, Aleric -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110114/c2d78fd8/attachment.htm From Aleric.Inglewood at gmail.com Fri Jan 14 13:05:04 2011 From: Aleric.Inglewood at gmail.com (Aleric Inglewood) Date: Fri, 14 Jan 2011 21:05:04 -0000 Subject: [opensource-dev] Review Request: VWR-24333: Hardening against use of getLindenUserDir() before logging in. Message-ID: <20110114210504.17156.62298@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/91/ ----------------------------------------------------------- Review request for Viewer. Summary ------- Without this patch, getLindenUserDir() is sometimes used without checking if it returns an empty value, resulting in trying to open an empty file and then gracefully recovering from that. So, this patch doesn't really fix a bug. However it might prevent one in the future. Note that this DID lead to a bug in Viewer 1 code, so it's possible. The main threat is that some singleton class that uses getLindenUserDir (indirectly) is instantiated before logging in: A singleton is only created once and when it is initialized with an empty getLindenUserDir() then that can remain. This patch aborts when the viewer is compiled in debug mode (not in release mode, when it will do what it did before this patch) and when getLindenUserDir() is called before it was initialized, unless the developer explicitely passes 'true' (empty_ok) to getLindenUserDir, signaling that they considered the possibility that the function is being called before the user logged in. This addresses bug VWR-24333. http://jira.secondlife.com/browse/VWR-24333 Diffs ----- indra/llvfs/lldir.h 422f636c3343 indra/llvfs/lldir.cpp 422f636c3343 indra/newview/llappviewer.cpp 422f636c3343 indra/newview/llbottomtray.cpp 422f636c3343 indra/newview/llfilepicker.cpp 422f636c3343 indra/newview/llnavigationbar.cpp 422f636c3343 indra/newview/llsearchhistory.h 422f636c3343 indra/newview/llurlhistory.cpp 422f636c3343 indra/newview/llviewerinventory.cpp 422f636c3343 indra/newview/llviewermedia.cpp 422f636c3343 indra/newview/llvoiceclient.cpp 422f636c3343 Diff: http://codereview.secondlife.com/r/91/diff Testing ------- Thanks, Aleric -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110114/8c828f9d/attachment.htm From Aleric.Inglewood at gmail.com Fri Jan 14 13:07:12 2011 From: Aleric.Inglewood at gmail.com (Aleric Inglewood) Date: Fri, 14 Jan 2011 21:07:12 -0000 Subject: [opensource-dev] Review Request: VWR-24334: Add support for PluginAttachDebuggerToPlugins to linux Message-ID: <20110114210712.17156.69318@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/92/ ----------------------------------------------------------- Review request for Viewer. Summary ------- Added: On linux, when PluginAttachDebuggerToPlugins is set to TRUE, execute the value of the environment variable LL_DEBUG_TERMINAL_COMMAND where a (obligatory) %s is replaced with the contents of the value of the environment variable LL_DEBUG_GDB_PATH followed by the string " -n /proc//exe ", where is the integer of the SLPlugin process we wish to attach to. The default value of LL_DEBUG_TERMINAL_COMMAND, if no environment variable is found, is "/usr/bin/xterm -geometry 160x24+0+0 -e %s" and the default value of LL_DEBUG_GDB_PATH is "/usr/bin/gdb". As such, it is possible to use a different terminal, for example setting the enviroment variable: LL_DEBUG_TERMINAL_COMMAND="/usr/bin/gnome-terminal --geometry=165x24-0+0 -e %s" And you can pass other parameters to gdb (and/or change it's path), for example by setting the enviroment variable: LL_DEBUG_GDB_PATH="/usr/local/bin/gdb -x /home/aleric/mygdbinit" which would open a different gdb and start with executing commands from /home/aleric/mygdbinit (no other .gdbinit is read). This addresses bug VWR-24334. http://jira.secondlife.com/browse/VWR-24334 Diffs ----- doc/contributions.txt b0bd26c5638a indra/llcommon/llprocesslauncher.h b0bd26c5638a indra/llplugin/llpluginprocessparent.cpp b0bd26c5638a Diff: http://codereview.secondlife.com/r/92/diff Testing ------- Thanks, Aleric -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110114/5e323384/attachment.htm From Aleric.Inglewood at gmail.com Fri Jan 14 13:09:34 2011 From: Aleric.Inglewood at gmail.com (Aleric Inglewood) Date: Fri, 14 Jan 2011 21:09:34 -0000 Subject: [opensource-dev] Review Request: VWR-24337: Possible crash on llassert_always(purge_list.size() >= entries_to_purge) Message-ID: <20110114210934.17161.21367@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/93/ ----------------------------------------------------------- Review request for Viewer. Summary ------- Just fixed the logic, so entries_to_purge won't become negative anymore, and the rest. This addresses bug VWR-24337. http://jira.secondlife.com/browse/VWR-24337 Diffs ----- doc/contributions.txt b0bd26c5638a indra/newview/lltexturecache.cpp b0bd26c5638a Diff: http://codereview.secondlife.com/r/93/diff Testing ------- Thanks, Aleric -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110114/568a7c6c/attachment-0001.htm From Aleric.Inglewood at gmail.com Fri Jan 14 13:13:27 2011 From: Aleric.Inglewood at gmail.com (Aleric Inglewood) Date: Fri, 14 Jan 2011 21:13:27 -0000 Subject: [opensource-dev] Review Request: VWR-24354: Fix manifest dependencies for linux Message-ID: <20110114211327.17160.77638@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/94/ ----------------------------------------------------------- Review request for Viewer. Summary ------- See http://jira.secondlife.com/browse/VWR-24354 This addresses bug VWR-24354. http://jira.secondlife.com/browse/VWR-24354 Diffs ----- doc/contributions.txt b0bd26c5638a indra/newview/CMakeLists.txt b0bd26c5638a Diff: http://codereview.secondlife.com/r/94/diff Testing ------- Thanks, Aleric -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110114/e8441000/attachment.htm From Aleric.Inglewood at gmail.com Fri Jan 14 13:15:31 2011 From: Aleric.Inglewood at gmail.com (Aleric Inglewood) Date: Fri, 14 Jan 2011 21:15:31 -0000 Subject: [opensource-dev] Review Request: VWR-24366: CMAKE_EXE_LINKER_FLAGS not honored when linking the viewer binary if -DLL_TESTS:BOOL=ON Message-ID: <20110114211531.17356.1377@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/95/ ----------------------------------------------------------- Review request for Viewer. Summary ------- Setting CMAKE_EXE_LINKER_FLAGS to "" because the tests "need" that is pretty hard measure. Not only is it not necessary to do so, it also changes how the viewer is linked depending on a whether or not the tests are compiled and that is not good. The reason that this was needed is that libgmock is underlinked (see http://wiki.mandriva.com/en/Underlinking), which is not compatible with -Wl,--as-needed that is being used on linux. libgmock.so.0 needs a symbol that is defined in libgtest.so.o, but -lgtest was not passed to the linker when creating libgmock.so.0: Underlinked (no libgtest.so.o): $ objdump -p /usr/lib/libgmock.so.0 | grep NEEDED NEEDED libstdc++.so.6 NEEDED libm.so.6 NEEDED libc.so.6 NEEDED libgcc_s.so.1 The solution is to wrap between -Wl,--no-as-needed -lgtest -Wl,--as-needed causing it to be added again. This is only needed on linux, since that the only platform that we use -Wl,--as-needed on. Moreover, we can just set GOOGLEMOCK_LIBRARIES to "gmock -Wl,--no-as-needed gtest -Wl,--as-needed" since that is only passed to TARGET_LINK_LIBRARIES which only adds -l in front of 'things' that don't start with '-', to allow you do pass special flags like this. This addresses bug VWR-24366. http://jira.secondlife.com/browse/VWR-24366 Diffs ----- doc/contributions.txt 422f636c3343 indra/cmake/GoogleMock.cmake 422f636c3343 indra/cmake/LLAddBuildTest.cmake 422f636c3343 Diff: http://codereview.secondlife.com/r/95/diff Testing ------- Thanks, Aleric -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110114/9cc1d535/attachment.htm From sllists at boroon.dasgupta.ch Fri Jan 14 13:16:46 2011 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Fri, 14 Jan 2011 21:16:46 -0000 Subject: [opensource-dev] Review Request: VWR-24311: Uninstall packages that are renewed. In-Reply-To: <20110114202627.17162.52400@domU-12-31-38-00-90-68.compute-1.internal> References: <20110114202627.17162.52400@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110114211646.17162.59510@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/80/#review152 ----------------------------------------------------------- scripts/install.py I think for multiple return values, packaging in tuples is preferred over packaging in lists.[citation needed] I.e., use return (to_install, to_uninstall) scripts/install.py This can be written more pythonesque as (to_install, to_uninstall) = self._build_ifiles(platform, cache_dir) scripts/install.py Does to_install need filtering at all? (Can it contain non-installables?) - Boroondas On Jan. 14, 2011, 12:26 p.m., Aleric Inglewood wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/80/ > ----------------------------------------------------------- > > (Updated Jan. 14, 2011, 12:26 p.m.) > > > Review request for Viewer. > > > Summary > ------- > > See https://jira.secondlife.com/browse/VWR-24311 > > Basically, this fixes the TODO comment in install.py but with the difference that we really want to uninstall any old package with the same name, different md5 or not. > > > This addresses bug VWR-24311. > http://jira.secondlife.com/browse/VWR-24311 > > > Diffs > ----- > > doc/contributions.txt b0bd26c5638a > scripts/install.py b0bd26c5638a > > Diff: http://codereview.secondlife.com/r/80/diff > > > Testing > ------- > > Loads of testing on linux... Installing new packages now cleanly removes the old one first. > > > Thanks, > > Aleric > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110114/54cddbbc/attachment.htm From sllists at boroon.dasgupta.ch Fri Jan 14 13:31:57 2011 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Fri, 14 Jan 2011 21:31:57 -0000 Subject: [opensource-dev] Review Request: VWR-24312: Massively duplicated objects (part 2) In-Reply-To: <20110114203411.17162.12107@domU-12-31-38-00-90-68.compute-1.internal> References: <20110114203411.17162.12107@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110114213157.17161.57957@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/81/#review153 ----------------------------------------------------------- indra/llcharacter/llanimationstates.cpp If all these lines are touched anyway, (didn't select all, to avoid an unnecessary long review), please either remove the alignment or use spaces instead of tabs for aligning, so they will look nice independent of tab display length. indra/llcommon/lllslconstants.h Yay for having type modifiers after the core type name. Makes them much easier to understand, especially when there are several cascaded ones. :-) - Boroondas On Jan. 14, 2011, 12:34 p.m., Aleric Inglewood wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/81/ > ----------------------------------------------------------- > > (Updated Jan. 14, 2011, 12:34 p.m.) > > > Review request for Viewer. > > > Summary > ------- > > Turns out that most of my SNOW-800 patch was included in Viewer 2 (albeit without crediting me). > However, not everything was used and some more cleaning up was possible. > > After this patch, and when compiling with optimization, there are no duplicates left > anymore that shouldn't be there in the first place: apart from the debug stream > iostream guard variable, there are several static variables with the same name (r, r1, > r2, etc) but that indeed actually different symbol objects. Then there are a few > constant POD arrays that are duplicated a hand full of times because they are > accessed with a variable index (so optimizing them away is not possible). I left them > like that (although defining those as extern as well would have been more consistent > and not slower; in fact it would be faster theoretically because those arrays could > share the same cache page then). > > > This addresses bug VWR-24312. > http://jira.secondlife.com/browse/VWR-24312 > > > Diffs > ----- > > doc/contributions.txt b0bd26c5638a > indra/llcharacter/llanimationstates.cpp b0bd26c5638a > indra/llcommon/llavatarconstants.h b0bd26c5638a > indra/llcommon/lllslconstants.h b0bd26c5638a > indra/llcommon/llmetricperformancetester.h b0bd26c5638a > indra/llmath/llcamera.h b0bd26c5638a > indra/llmath/llcamera.cpp b0bd26c5638a > indra/newview/llviewerobject.cpp b0bd26c5638a > indra/newview/llvoavatar.cpp b0bd26c5638a > indra/newview/llvosky.h b0bd26c5638a > indra/newview/llvosky.cpp b0bd26c5638a > > Diff: http://codereview.secondlife.com/r/81/diff > > > Testing > ------- > > Compiled with optimization and then running readelf on the executable to find duplicated symbols. > > > Thanks, > > Aleric > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110114/af4c7dec/attachment-0001.htm From sllists at boroon.dasgupta.ch Fri Jan 14 13:47:50 2011 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Fri, 14 Jan 2011 21:47:50 -0000 Subject: [opensource-dev] Review Request: VWR-24317: Incorrect start up warnings: WARNING: ll_apr_warn_status: APR: No such file or directory In-Reply-To: <20110114204813.17158.23999@domU-12-31-38-00-90-68.compute-1.internal> References: <20110114204813.17158.23999@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110114214750.17160.40207@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/83/#review154 ----------------------------------------------------------- Ship it! Looks good. Files should only be removed when they actually exists, which this change accomplishes. Just wondering: indra/newview/llappviewer.cpp indra/newview/llappviewer.cpp indra/newview/llappviewer.cpp what's the reason for moving the LL_INFOS around? - Boroondas On Jan. 14, 2011, 12:48 p.m., Aleric Inglewood wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/83/ > ----------------------------------------------------------- > > (Updated Jan. 14, 2011, 12:48 p.m.) > > > Review request for Viewer. > > > Summary > ------- > > At start up one can get the following ?warnings?: > > 2010-10-23T12:22:44Z WARNING: ll_apr_warn_status: APR: No such file or directory > 2010-10-23T12:22:44Z WARNING: remove: Attempting to remove filename: /home/aleric/.imprudence/logs/Imprudence.logout_marker > 2010-10-23T12:22:44Z WARNING: ll_apr_warn_status: APR: No such file or directory > 2010-10-23T12:22:44Z WARNING: remove: Attempting to remove filename: /home/aleric/.imprudence/logs/Imprudence.llerror_marker > 2010-10-23T12:22:44Z WARNING: ll_apr_warn_status: APR: No such file or directory > 2010-10-23T12:22:44Z WARNING: remove: Attempting to remove filename: /home/aleric/.imprudence/logs/Imprudence.error_marker > > This is nonsense since it is perfectly ok when those files don?t exist. > > > This addresses bug VWR-24317. > http://jira.secondlife.com/browse/VWR-24317 > > > Diffs > ----- > > indra/newview/llappviewer.cpp b0bd26c5638a > > Diff: http://codereview.secondlife.com/r/83/diff > > > Testing > ------- > > > Thanks, > > Aleric > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110114/f6b213a1/attachment.htm From merov at lindenlab.com Fri Jan 14 14:00:21 2011 From: merov at lindenlab.com (Merov Linden) Date: Fri, 14 Jan 2011 22:00:21 -0000 Subject: [opensource-dev] Review Request: VWR-13040: LLObjectSelection::valid_root_begin() is really the same as LLObjectSelection::root_begin() In-Reply-To: <20110114202136.17389.23681@domU-12-31-38-00-90-68.compute-1.internal> References: <20110114202136.17389.23681@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110114220021.17155.84423@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/79/#review156 ----------------------------------------------------------- The patch is correct but, grepping the code, I can't see one instance of is_valid_root being used so, that fix is moot. Better maybe to suppress that struct altogether or may be start to use it where adequate (haven't looked at that aspect I need to confess). - Merov On Jan. 14, 2011, 12:21 p.m., Aleric Inglewood wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/79/ > ----------------------------------------------------------- > > (Updated Jan. 14, 2011, 12:21 p.m.) > > > Review request for Viewer. > > > Summary > ------- > > See https://jira.secondlife.com/browse/VWR-13040 > > > This addresses bug VWR-13040. > http://jira.secondlife.com/browse/VWR-13040 > > > Diffs > ----- > > doc/contributions.txt b0bd26c5638a > indra/newview/llselectmgr.h b0bd26c5638a > > Diff: http://codereview.secondlife.com/r/79/diff > > > Testing > ------- > > Been using this ever since that jira/patch was created. > > > Thanks, > > Aleric > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110114/bba6a7ab/attachment.htm From merov at lindenlab.com Fri Jan 14 14:02:59 2011 From: merov at lindenlab.com (Merov Linden) Date: Fri, 14 Jan 2011 22:02:59 -0000 Subject: [opensource-dev] Review Request: VWR-13040: LLObjectSelection::valid_root_begin() is really the same as LLObjectSelection::root_begin() In-Reply-To: <20110114202136.17389.23681@domU-12-31-38-00-90-68.compute-1.internal> References: <20110114202136.17389.23681@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110114220259.17389.30873@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/79/#review157 ----------------------------------------------------------- Ship it! Ack... sorry: there are instances using the valid_root_iterator, silly me. Ship it! It's clearly a cut/paste that didn't get modified. - Merov On Jan. 14, 2011, 12:21 p.m., Aleric Inglewood wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/79/ > ----------------------------------------------------------- > > (Updated Jan. 14, 2011, 12:21 p.m.) > > > Review request for Viewer. > > > Summary > ------- > > See https://jira.secondlife.com/browse/VWR-13040 > > > This addresses bug VWR-13040. > http://jira.secondlife.com/browse/VWR-13040 > > > Diffs > ----- > > doc/contributions.txt b0bd26c5638a > indra/newview/llselectmgr.h b0bd26c5638a > > Diff: http://codereview.secondlife.com/r/79/diff > > > Testing > ------- > > Been using this ever since that jira/patch was created. > > > Thanks, > > Aleric > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110114/4252ba76/attachment-0001.htm From sllists at boroon.dasgupta.ch Fri Jan 14 14:03:53 2011 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Fri, 14 Jan 2011 22:03:53 -0000 Subject: [opensource-dev] Review Request: VWR-24317: Incorrect start up warnings: WARNING: remove: Attempting to remove filename: /ramdisk/imprudence/cache/textures/*/*.texture In-Reply-To: <20110114205057.17158.38187@domU-12-31-38-00-90-68.compute-1.internal> References: <20110114205057.17158.38187@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110114220353.17162.24336@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/84/#review155 ----------------------------------------------------------- indra/newview/lltexturecache.cpp As this will sometimes stay true, even when the file doesn't exist, file_must_be_removed or delete_the_file might be better names. (Maybe you can think off even better ones.) indra/newview/lltexturecache.cpp Make this LL_WARNS("TextureCache") << "Entry has a body size of zero but file " << filename << " exists. This file will be deleted, too." << LL_ENDL; or similar. - Boroondas On Jan. 14, 2011, 12:50 p.m., Aleric Inglewood wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/84/ > ----------------------------------------------------------- > > (Updated Jan. 14, 2011, 12:50 p.m.) > > > Review request for Viewer. > > > Summary > ------- > > This turned out to be a simple matter of trying to remove non-existant files: > A texture with a 'body size' of 0 doesn't have a texture body file. > > > This addresses bug VWR-24317. > http://jira.secondlife.com/browse/VWR-24317 > > > Diffs > ----- > > indra/newview/lltexturecache.cpp b0bd26c5638a > > Diff: http://codereview.secondlife.com/r/84/diff > > > Testing > ------- > > > Thanks, > > Aleric > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110114/e74aee25/attachment.htm From merov at lindenlab.com Fri Jan 14 14:07:08 2011 From: merov at lindenlab.com (Merov Linden) Date: Fri, 14 Jan 2011 22:07:08 -0000 Subject: [opensource-dev] Review Request: VWR-24315: SNOW-796: Clicking 'Reset to default' in the Debug Settings floater doesn't update cached control values. In-Reply-To: <20110114204018.17160.65071@domU-12-31-38-00-90-68.compute-1.internal> References: <20110114204018.17160.65071@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110114220708.17215.95903@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/82/#review158 ----------------------------------------------------------- Ship it! Yes, we should fire a signal so the change takes effect immediately. - Merov On Jan. 14, 2011, 12:40 p.m., Aleric Inglewood wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/82/ > ----------------------------------------------------------- > > (Updated Jan. 14, 2011, 12:40 p.m.) > > > Review request for Viewer. > > > Summary > ------- > > See https://jira.secondlife.com/browse/VWR-24315 > > > This addresses bug VWR-24315. > http://jira.secondlife.com/browse/VWR-24315 > > > Diffs > ----- > > doc/contributions.txt b0bd26c5638a > indra/newview/llfloatersettingsdebug.cpp b0bd26c5638a > > Diff: http://codereview.secondlife.com/r/82/diff > > > Testing > ------- > > I have some other patch that allows me to move my avatar up and down vertically (by faking it has a different height). > When I open the Debug Settings floater and change the value with the up/down arrows, the avatar is immediately updated (changes height), > but resetting the value (to zero) had no effect. With this patch, resetting caused the avatar to immediately change it's height to an Z-offset of zero again, as it should. > > > Thanks, > > Aleric > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110114/e5881dfd/attachment.htm From merov at lindenlab.com Fri Jan 14 14:16:58 2011 From: merov at lindenlab.com (Merov Linden) Date: Fri, 14 Jan 2011 22:16:58 -0000 Subject: [opensource-dev] Review Request: VWR-24317: Incorrect start up warnings: WARNING: addFeature: LLFeatureList::Attempting to add preexisting feature Disregard128DefaultDrawDistance In-Reply-To: <20110114205214.17156.14325@domU-12-31-38-00-90-68.compute-1.internal> References: <20110114205214.17156.14325@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110114221658.17162.2547@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/85/#review159 ----------------------------------------------------------- Ship it! Cleaner and better. No problem with this one. - Merov On Jan. 14, 2011, 12:52 p.m., Aleric Inglewood wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/85/ > ----------------------------------------------------------- > > (Updated Jan. 14, 2011, 12:52 p.m.) > > > Review request for Viewer. > > > Summary > ------- > > Fixes a bug that causes the last line of the feature table file to be read > twice. This patch also removes the check for name.empty() because that > will never be true, so might as well remove it. > > > This addresses bug VWR-24317. > http://jira.secondlife.com/browse/VWR-24317 > > > Diffs > ----- > > indra/newview/llfeaturemanager.cpp b0bd26c5638a > > Diff: http://codereview.secondlife.com/r/85/diff > > > Testing > ------- > > > Thanks, > > Aleric > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110114/2acf89d6/attachment.htm From merov at lindenlab.com Fri Jan 14 14:20:37 2011 From: merov at lindenlab.com (Merov Linden) Date: Fri, 14 Jan 2011 22:20:37 -0000 Subject: [opensource-dev] Review Request: VWR-24317: Incorrect start up warnings: WARNING: isFeatureAvailable: Feature RenderCubeMap not on feature list! In-Reply-To: <20110114205352.17160.83857@domU-12-31-38-00-90-68.compute-1.internal> References: <20110114205352.17160.83857@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110114222037.20676.95560@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/86/#review160 ----------------------------------------------------------- Ship it! I'm assuming that this global is indeed not used before the new initialization point. - Merov On Jan. 14, 2011, 12:53 p.m., Aleric Inglewood wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/86/ > ----------------------------------------------------------- > > (Updated Jan. 14, 2011, 12:53 p.m.) > > > Review request for Viewer. > > > Summary > ------- > > Fixes this warning. Note that LLCubeMap::sUseCubeMaps is set to true by > default, so this patch only has effect when the feature is actually NOT > available. > > I tested that LLCubeMap::sUseCubeMaps is NOT used before the point where > it is initialized now. > > > This addresses bug VWR-24317. > http://jira.secondlife.com/browse/VWR-24317 > > > Diffs > ----- > > indra/newview/llappviewer.cpp b0bd26c5638a > > Diff: http://codereview.secondlife.com/r/86/diff > > > Testing > ------- > > > Thanks, > > Aleric > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110114/a7369a48/attachment.htm From sllists at boroon.dasgupta.ch Fri Jan 14 14:23:09 2011 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Fri, 14 Jan 2011 22:23:09 -0000 Subject: [opensource-dev] Review Request: VWR-24321: Validate textures starting with 00 too. In-Reply-To: <20110114210232.20676.90941@domU-12-31-38-00-90-68.compute-1.internal> References: <20110114210232.20676.90941@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110114222309.17156.62495@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/90/#review161 ----------------------------------------------------------- Ship it! Correct. - Boroondas On Jan. 14, 2011, 1:02 p.m., Aleric Inglewood wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/90/ > ----------------------------------------------------------- > > (Updated Jan. 14, 2011, 1:02 p.m.) > > > Review request for Viewer. > > > Summary > ------- > > Trivial patch, just removes stupidity. > > > This addresses bug VWR-24321. > http://jira.secondlife.com/browse/VWR-24321 > > > Diffs > ----- > > doc/contributions.txt b0bd26c5638a > indra/newview/lltexturecache.cpp b0bd26c5638a > > Diff: http://codereview.secondlife.com/r/90/diff > > > Testing > ------- > > > Thanks, > > Aleric > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110114/c4ddf229/attachment-0001.htm From sllists at boroon.dasgupta.ch Fri Jan 14 14:46:26 2011 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Fri, 14 Jan 2011 22:46:26 -0000 Subject: [opensource-dev] Review Request: VWR-24366: CMAKE_EXE_LINKER_FLAGS not honored when linking the viewer binary if -DLL_TESTS:BOOL=ON In-Reply-To: <20110114211531.17356.1377@domU-12-31-38-00-90-68.compute-1.internal> References: <20110114211531.17356.1377@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110114224626.17389.54642@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/95/#review162 ----------------------------------------------------------- Ship it! Looks sane and your explanation makes sense. - Boroondas On Jan. 14, 2011, 1:15 p.m., Aleric Inglewood wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/95/ > ----------------------------------------------------------- > > (Updated Jan. 14, 2011, 1:15 p.m.) > > > Review request for Viewer. > > > Summary > ------- > > Setting CMAKE_EXE_LINKER_FLAGS to "" because the tests "need" that is pretty > hard measure. Not only is it not necessary to do so, it also changes how > the viewer is linked depending on a whether or not the tests are compiled > and that is not good. > > The reason that this was needed is that libgmock is underlinked > (see http://wiki.mandriva.com/en/Underlinking), which is not compatible > with -Wl,--as-needed that is being used on linux. libgmock.so.0 needs > a symbol that is defined in libgtest.so.o, but -lgtest was not passed > to the linker when creating libgmock.so.0: > > Underlinked (no libgtest.so.o): > $ objdump -p /usr/lib/libgmock.so.0 | grep NEEDED > NEEDED libstdc++.so.6 > NEEDED libm.so.6 > NEEDED libc.so.6 > NEEDED libgcc_s.so.1 > > The solution is to wrap between -Wl,--no-as-needed -lgtest -Wl,--as-needed > causing it to be added again. This is only needed on linux, since that > the only platform that we use -Wl,--as-needed on. Moreover, we can just > set GOOGLEMOCK_LIBRARIES to "gmock -Wl,--no-as-needed gtest -Wl,--as-needed" > since that is only passed to TARGET_LINK_LIBRARIES which only adds -l > in front of 'things' that don't start with '-', to allow you do pass > special flags like this. > > > This addresses bug VWR-24366. > http://jira.secondlife.com/browse/VWR-24366 > > > Diffs > ----- > > doc/contributions.txt 422f636c3343 > indra/cmake/GoogleMock.cmake 422f636c3343 > indra/cmake/LLAddBuildTest.cmake 422f636c3343 > > Diff: http://codereview.secondlife.com/r/95/diff > > > Testing > ------- > > > Thanks, > > Aleric > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110114/9f57e884/attachment.htm From sllists at boroon.dasgupta.ch Fri Jan 14 14:49:26 2011 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Fri, 14 Jan 2011 23:49:26 +0100 Subject: [opensource-dev] Link times In-Reply-To: References: Message-ID: <4D30D2F6.2010008@boroon.dasgupta.ch> On 01/14/2011 06:04 PM, Jonathan Welch wrote: > I just did a quick study on link times for various viewers on my 2Gb XP system > > Viewer 1st link 2nd link > CV 1.22 0:53 0:24 > SG 1.5 3:30 2:07 > V2.5 6:18 6:01 The long time for 2.5 be due to VWR-24366 . Dunno why linking Cool Viewer (that's what "CV" stands for, isn't it?) is so much quicker than SG 1.5, though. Good news: A fix is being reviewed at https://codereview.secondlife.com/r/95/ Cheers, Boroondas -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110114/59692233/attachment.htm From slitovchuk at productengine.com Fri Jan 14 16:13:40 2011 From: slitovchuk at productengine.com (Seth ProductEngine) Date: Sat, 15 Jan 2011 00:13:40 -0000 Subject: [opensource-dev] Review Request: (STORM-383) Context menu cannot be open for Landmark that are located in the My inventory->Trash folder Message-ID: <20110115001340.17162.5726@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/77/ ----------------------------------------------------------- Review request for Viewer. Summary ------- Added "Restore Item" context menu entry for landmarks and folders in Trash category in Places->My Landmarks->My Inventory accordion tab. This addresses bug STORM-383. http://jira.secondlife.com/browse/STORM-383 Diffs ----- indra/newview/llpanellandmarks.h 422f636c3343 indra/newview/llpanellandmarks.cpp 422f636c3343 indra/newview/skins/default/xui/en/menu_places_gear_folder.xml 422f636c3343 indra/newview/skins/default/xui/en/menu_places_gear_landmark.xml 422f636c3343 Diff: http://codereview.secondlife.com/r/77/diff Testing ------- Thanks, Seth -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110115/e992e606/attachment.htm From josh at lindenlab.com Fri Jan 14 16:20:56 2011 From: josh at lindenlab.com (Joshua Bell) Date: Fri, 14 Jan 2011 16:20:56 -0800 Subject: [opensource-dev] X network test dump (capacity failure) Message-ID: {"deviceId":"4d30a642a56f04.90158583","userAgent":"Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US) AppleWebKit/534.13 (KHTML, like Gecko) Chrome/9.0.597.47 Safari/534.13","href":" http://interest.secondlife-staging.com/landing/s/chat?rerun ","elapsedTime":25649,"kyokaStartTime":1295050793574,"kyokaEndTime":1295050819223,"launcherStartTime":1295050819835,"kyokaConfig":{"version":"2.4.8","toukai":" http://toukai.x.gaikai.com/toukai ","rerun":true,"forceLaunch":true,"forceBrowser":null,"dcFilter":null,"launcherWeb":" http://kyoka.x.gaikai.com/launcher ","cookieHash":"08a9e668e5fc5eadde3f31cead871b54","cookieTtl":873094,"koushidomoVersion":"0.1.9","testKoushidomo":null,"disableClientDisconnect":null,"dcMaxDistance":1600000,"traceToConsole":null,"uId":"4d30e8256e7930.61124624","sesId":"4d30e8256e79c2.79541129","spock":" http://toukai.x.gaikai.com/spock/ ","httpRtTimeoutFirstResponse":5000,"httpRtTimeoutCompleteTest":15000,"refererDomain":" secondlife-staging.com","koushiVersion":"2.0.23","koushiCodebase":" http://toukai.x.gaikai.com/assets/java/koushi","koushiForceNetwork":false,"koushiConnectUdpResendTimeoutMs":100,"koushiConnectUdpTimeoutS":3,"koushiConnectCommandTimeoutMs":2000,"koushiConnectSocketTimeoutMs":300,"koushiRttTimeoutS":3,"koushiRttIterations":10,"koushiStreamBwFps":30,"koushiStreamBwDurationS":3},"clientSettings":{"ipAddress":"38.99.63.41","browser":{"os":"Windows","osVersion":"6.1","browser":"Chrome","version":9},"plugins":{"flash":"10.1.103.0","silverlight":"4.0.51204.0","java":"1.6.0.23"},"videoFeatures":{"browserWidth":1151,"browserHeight":836,"screenWidth":1280,"screenHeight":1024,"colorDepth":32},"geoLocation":{"areaCode":"415","city":"San Francisco","continentCode":"NA","countryCode":"US","countryCode3":"USA","countryName":"United States","dmaCode":"807","isp":"PSINet","latitude":37.7644996643,"longitude":-122.429397583,"postalCode":"","region":"CA"},"cpu":13,"supportedResolutions":[1280,1024,32,1280,720,32,1152,864,32,640,480,32,1280,768,32,1280,800,32,720,480,32],"os":{"jvmVersion":"1.6.0_23","osArch":"x86","dataModel":32,"jvmVendor":"Sun Microsystems Inc."},"wifiOnly":false,"responseTime":10,"dataCenter":" x.snv1.llnw.ca.us.gaikai.com ","bandwidthKbps":26738,"mtu":1454,"rtt":{"rttSamples":10,"rttHighudp":14.9,"rttAvgtcp":5.4,"rttSamplesudp":6,"rttHightcp":10.66,"rttLowudp":5.73,"rttSamplestcp":6,"rttAvgudp":5.93,"rttLowtcp":5.31},"stream":{"bwOutOfOrderAF":0,"bwRttAvg":7.8,"bwLoss":1.39,"bwRttHigh":13.97,"bwDuration":3,"bwOutOfOrder":0,"bwRttLow":5.88,"bwKbps":9863.93},"udpTest":true,"udpPort":5995},"launchData":{"launch":false,"clientType":"java","results":{"wifiOnly":true,"bandwidth":true,"responseTime":true,"enabled":true,"plugins":{"flash":true,"java":true,"xbox":true,"ipad":true},"capacity":false},"gameData":{"code":"secondlife_custom_8_fps","name":"secondlife_custom_8_fps","demotime":"0","scriptVersion":"2.3.0","language":{"code":"EN","language":"English"},"inputProfile":{"mouseEnabled":"True","keyMappingConfigID":"fullKeyboard","feedbackProfile":"AUTO_UNBOUNDED","inputProfile":"PC-AUTO-UNBOUNDED"},"metadata":{"height":"576","site_overlay":" http://maps.secondlife.com/ ","type":"game","width":"1024"},"disabled":false,"resolution":{"width":1024,"height":576}},"launcherUrl":" http://interest.secondlife-staging.com/landing/s/chat?rerun ","forceLaunch":true},"eventDump":[{"seq":5,"eventType":"responseTime","eventData":{"host":" kd1.x.snv1.llnw.ca.us.gaikai.com ","rts":[8,9,9,10,11,13],"ots":[18,14,9,13,9,11,14,10,8,23],"total":60,"avg":10}},{"seq":6,"eventType":"responseTime","eventData":{"host":" kd1.x.lax6.llnw.ca.us.gaikai.com ","rts":[17,18,19,20,20,21],"ots":[27,21,21,24,33,17,19,20,18,20],"total":116,"avg":19}},{"seq":7,"eventType":"responseTime","eventData":{"host":" kd2.x.sea3.llnw.wa.us.gaikai.com ","rts":[26,26,26,26,26,27],"ots":[37,30,26,26,28,26,26,26,27,31],"total":157,"avg":26}}],"errorDump":[]} -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110114/117c2d36/attachment-0001.htm From merov at lindenlab.com Fri Jan 14 17:27:24 2011 From: merov at lindenlab.com (Merov Linden) Date: Sat, 15 Jan 2011 01:27:24 -0000 Subject: [opensource-dev] Review Request: VWR-24366: CMAKE_EXE_LINKER_FLAGS not honored when linking the viewer binary if -DLL_TESTS:BOOL=ON In-Reply-To: <20110114211531.17356.1377@domU-12-31-38-00-90-68.compute-1.internal> References: <20110114211531.17356.1377@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110115012724.17157.10313@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/95/#review163 ----------------------------------------------------------- Ship it! Makes sense. - Merov On Jan. 14, 2011, 1:15 p.m., Aleric Inglewood wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/95/ > ----------------------------------------------------------- > > (Updated Jan. 14, 2011, 1:15 p.m.) > > > Review request for Viewer. > > > Summary > ------- > > Setting CMAKE_EXE_LINKER_FLAGS to "" because the tests "need" that is pretty > hard measure. Not only is it not necessary to do so, it also changes how > the viewer is linked depending on a whether or not the tests are compiled > and that is not good. > > The reason that this was needed is that libgmock is underlinked > (see http://wiki.mandriva.com/en/Underlinking), which is not compatible > with -Wl,--as-needed that is being used on linux. libgmock.so.0 needs > a symbol that is defined in libgtest.so.o, but -lgtest was not passed > to the linker when creating libgmock.so.0: > > Underlinked (no libgtest.so.o): > $ objdump -p /usr/lib/libgmock.so.0 | grep NEEDED > NEEDED libstdc++.so.6 > NEEDED libm.so.6 > NEEDED libc.so.6 > NEEDED libgcc_s.so.1 > > The solution is to wrap between -Wl,--no-as-needed -lgtest -Wl,--as-needed > causing it to be added again. This is only needed on linux, since that > the only platform that we use -Wl,--as-needed on. Moreover, we can just > set GOOGLEMOCK_LIBRARIES to "gmock -Wl,--no-as-needed gtest -Wl,--as-needed" > since that is only passed to TARGET_LINK_LIBRARIES which only adds -l > in front of 'things' that don't start with '-', to allow you do pass > special flags like this. > > > This addresses bug VWR-24366. > http://jira.secondlife.com/browse/VWR-24366 > > > Diffs > ----- > > doc/contributions.txt 422f636c3343 > indra/cmake/GoogleMock.cmake 422f636c3343 > indra/cmake/LLAddBuildTest.cmake 422f636c3343 > > Diff: http://codereview.secondlife.com/r/95/diff > > > Testing > ------- > > > Thanks, > > Aleric > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110115/1d1c0716/attachment.htm From josh at lindenlab.com Fri Jan 14 17:57:38 2011 From: josh at lindenlab.com (Joshua Bell) Date: Fri, 14 Jan 2011 17:57:38 -0800 Subject: [opensource-dev] X network test dump (capacity failure) In-Reply-To: References: Message-ID: On Fri, Jan 14, 2011 at 4:20 PM, Joshua Bell wrote: > > {"deviceId":"4d30a642a56f04.90158583","userAgent":"Mozilla/5.0 (Windows; U; > Windows NT 6.1; en-US) AppleWebKit/534.13 (KHTML, like Gecko) > Chrome/9.0.597.47 Safari/534.13","href":" > http://interest.secondlife-staging.com/landing/s/chat? > Oops, sent that to the wrong mailing list. FYI, that's just a dump of script data from a browser trying to access the Second Life Web Viewer Beta, nothing secret. If you're trying out a session you can get at the same data by groveling around in the Web Inspector console or Firebug. Careful observers will now know what city I'm in and what OS/browser I'm running, though. Eeeek! :) -- Josh -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110114/e71ed869/attachment.htm From tateru at taterunino.net Fri Jan 14 18:29:32 2011 From: tateru at taterunino.net (Tateru Nino) Date: Sat, 15 Jan 2011 13:29:32 +1100 Subject: [opensource-dev] X network test dump (capacity failure) In-Reply-To: References: Message-ID: <4D31068C.4080503@taterunino.net> It's okay. We already go through your trash in the middle of the night, anyway. Incidentally, you're out of cheese. On 15/01/2011 12:57 PM, Joshua Bell wrote: > On Fri, Jan 14, 2011 at 4:20 PM, Joshua Bell > wrote: > > > > > {"deviceId":"4d30a642a56f04.90158583","userAgent":"Mozilla/5.0 > (Windows; U; Windows NT 6.1; en-US) AppleWebKit/534.13 (KHTML, > like Gecko) Chrome/9.0.597.47 > Safari/534.13","href":"http://interest.secondlife-staging.com/landing/s/chat? > > > > Oops, sent that to the wrong mailing list. > > FYI, that's just a dump of script data from a browser trying to access > the Second Life Web Viewer Beta, nothing secret. If you're trying out > a session you can get at the same data by groveling around in the Web > Inspector console or Firebug. > > Careful observers will now know what city I'm in and what OS/browser > I'm running, though. Eeeek! :) > > -- Josh > > > _______________________________________________ > Policies 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/20110115/71104d1b/attachment.htm From angel_of_crimson at hotmail.com Fri Jan 14 20:27:39 2011 From: angel_of_crimson at hotmail.com (Erin Mallory) Date: Fri, 14 Jan 2011 23:27:39 -0500 Subject: [opensource-dev] disappearing friends Message-ID: for some reason like 1/3 of my friends list randomly unfriended themselves including 3 of my own alts that I did not unfriend. Some people at the auction im at have said the same thing. anyone else noticing this? did LL impliment something new? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110114/0467a0ae/attachment.htm From missannotoole at yahoo.com Sat Jan 15 00:03:25 2011 From: missannotoole at yahoo.com (Ann Otoole) Date: Sat, 15 Jan 2011 00:03:25 -0800 (PST) Subject: [opensource-dev] disappearing friends In-Reply-To: References: Message-ID: <809385.61021.qm@web120519.mail.ne1.yahoo.com> I see no discrepancies in the viewer I use. What viewer(s) and versions are you using? ________________________________ From: Erin Mallory for some reason like 1/3 of my friends list randomly unfriended themselves including 3 of my own alts that I did not unfriend. Some people at the auction im at have said the same thing. anyone else noticing this? did LL impliment something new? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110115/6ce49dd3/attachment.htm From sllists at boroon.dasgupta.ch Sat Jan 15 10:03:23 2011 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Sat, 15 Jan 2011 18:03:23 -0000 Subject: [opensource-dev] Review Request: VWR-24311: Uninstall packages that are renewed. In-Reply-To: <20110114211646.17162.59510@domU-12-31-38-00-90-68.compute-1.internal> References: <20110114211646.17162.59510@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110115180323.17389.89216@domU-12-31-38-00-90-68.compute-1.internal> > On Jan. 14, 2011, 1:16 p.m., Boroondas Gupte wrote: > > scripts/install.py, line 598 > > > > > > Does to_install need filtering at all? (Can it contain non-installables?) Reading the docstring of install() , I realized this filtering *is* necessary, or all out-of-date installables would be uninstalled (and only the requested ones re-installed in new versions). I originally was mistaken on what "installables" is. To make the code less misleading, I suggest renaming that function argument to something like "requested_installables". - Boroondas ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/80/#review152 ----------------------------------------------------------- On Jan. 14, 2011, 12:26 p.m., Aleric Inglewood wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/80/ > ----------------------------------------------------------- > > (Updated Jan. 14, 2011, 12:26 p.m.) > > > Review request for Viewer. > > > Summary > ------- > > See https://jira.secondlife.com/browse/VWR-24311 > > Basically, this fixes the TODO comment in install.py but with the difference that we really want to uninstall any old package with the same name, different md5 or not. > > > This addresses bug VWR-24311. > http://jira.secondlife.com/browse/VWR-24311 > > > Diffs > ----- > > doc/contributions.txt b0bd26c5638a > scripts/install.py b0bd26c5638a > > Diff: http://codereview.secondlife.com/r/80/diff > > > Testing > ------- > > Loads of testing on linux... Installing new packages now cleanly removes the old one first. > > > Thanks, > > Aleric > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110115/55639d2b/attachment-0001.htm From sllists at boroon.dasgupta.ch Sat Jan 15 11:23:16 2011 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Sat, 15 Jan 2011 19:23:16 -0000 Subject: [opensource-dev] Review Request: VWR-24311: Uninstall packages that are renewed. In-Reply-To: <20110114211646.17162.59510@domU-12-31-38-00-90-68.compute-1.internal> References: <20110114211646.17162.59510@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110115192316.17215.61666@domU-12-31-38-00-90-68.compute-1.internal> > On Jan. 14, 2011, 1:16 p.m., Boroondas Gupte wrote: > > scripts/install.py, lines 592-594 > > > > > > This can be written more pythonesque as > > > > (to_install, to_uninstall) = self._build_ifiles(platform, cache_dir) Here, just to_install, to_uninstall = self._build_ifiles(platform, cache_dir) which again constructs a tuple (now on the left hand side to receive the values of the returned tuple). Again, omitting the parentheses stresses that the returned tuple just serves as a temporary vehicle for the two values. This is also the prevalent style for unpacking multiple return values in the existing python code from the viewer codebase. (The style in functions for returning multiple values is less homogeneous. But the use of tuples for that purpose, with or without parentheses, seems established.) > On Jan. 14, 2011, 1:16 p.m., Boroondas Gupte wrote: > > scripts/install.py, line 549 > > > > > > I think for multiple return values, packaging in tuples is preferred over packaging in lists.[citation needed] I.e., use > > > > return (to_install, to_uninstall) Actually, make that just return to_install, to_uninstall The comma is enough for constructing the tuple, the parentheses aren't needed (in this context), and leaving them away IMHO makes more clear that we aren't really interested in the tuple as container, but just use it to return multiple values at once. - Boroondas ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/80/#review152 ----------------------------------------------------------- On Jan. 14, 2011, 12:26 p.m., Aleric Inglewood wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/80/ > ----------------------------------------------------------- > > (Updated Jan. 14, 2011, 12:26 p.m.) > > > Review request for Viewer. > > > Summary > ------- > > See https://jira.secondlife.com/browse/VWR-24311 > > Basically, this fixes the TODO comment in install.py but with the difference that we really want to uninstall any old package with the same name, different md5 or not. > > > This addresses bug VWR-24311. > http://jira.secondlife.com/browse/VWR-24311 > > > Diffs > ----- > > doc/contributions.txt b0bd26c5638a > scripts/install.py b0bd26c5638a > > Diff: http://codereview.secondlife.com/r/80/diff > > > Testing > ------- > > Loads of testing on linux... Installing new packages now cleanly removes the old one first. > > > Thanks, > > Aleric > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110115/d6118a48/attachment.htm From lee.ponzu at gmail.com Sat Jan 15 11:29:29 2011 From: lee.ponzu at gmail.com (Ponzu) Date: Sat, 15 Jan 2011 14:29:29 -0500 Subject: [opensource-dev] disappearing friends In-Reply-To: <809385.61021.qm@web120519.mail.ne1.yahoo.com> References: <809385.61021.qm@web120519.mail.ne1.yahoo.com> Message-ID: Don't have any friends... ponzu On Sat, Jan 15, 2011 at 3:03 AM, Ann Otoole wrote: > I see no discrepancies in the viewer I use. What viewer(s) and versions are > you using? > > ------------------------------ > *From:* Erin Mallory > ** > for some reason like 1/3 of my friends list randomly unfriended themselves > including 3 of my own alts that I did not unfriend. Some people at the > auction im at have said the same thing. anyone else noticing this? did LL > impliment something new? > > > _______________________________________________ > Policies 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/20110115/5d2cd03e/attachment.htm From angel_of_crimson at hotmail.com Sat Jan 15 13:45:30 2011 From: angel_of_crimson at hotmail.com (Erin Mallory) Date: Sat, 15 Jan 2011 16:45:30 -0500 Subject: [opensource-dev] SNOW-370 Message-ID: is this still an issue with attempts to build 2.x builds or can i close this jira out? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110115/e2f980e7/attachment.htm From angel_of_crimson at hotmail.com Sat Jan 15 14:41:12 2011 From: angel_of_crimson at hotmail.com (Erin Mallory) Date: Sat, 15 Jan 2011 17:41:12 -0500 Subject: [opensource-dev] SNOW-178 Message-ID: I ran across this, and thought it would be a GREAT idea to bring this back into the light of day, especially since we've been discussing keyboard shortcuts and accessibility allot in snowstorm lately. I honestly think this is a great idea to try and implement but would like to hear thoughts and ideas by others. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110115/ccc372ba/attachment.htm From angel_of_crimson at hotmail.com Sat Jan 15 14:44:35 2011 From: angel_of_crimson at hotmail.com (Erin Mallory) Date: Sat, 15 Jan 2011 17:44:35 -0500 Subject: [opensource-dev] SNOW-178 In-Reply-To: References: Message-ID: and if we are discussing snow 178 we should likewise discuss 179 which is the other half of the equation. since i forgot to mention what these are about these two are for adding text commands or shortcuts for adding friends and accepting friends requests... From: angel_of_crimson at hotmail.com To: opensource-dev at lists.secondlife.com Date: Sat, 15 Jan 2011 17:41:12 -0500 Subject: [opensource-dev] SNOW-178 I ran across this, and thought it would be a GREAT idea to bring this back into the light of day, especially since we've been discussing keyboard shortcuts and accessibility allot in snowstorm lately. I honestly think this is a great idea to try and implement but would like to hear thoughts and ideas by others. _______________________________________________ Policies 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/20110115/85b64fb2/attachment.htm From Aleric.Inglewood at gmail.com Sun Jan 16 05:35:27 2011 From: Aleric.Inglewood at gmail.com (Aleric Inglewood) Date: Sun, 16 Jan 2011 13:35:27 -0000 Subject: [opensource-dev] Review Request: VWR-24311: Uninstall packages that are renewed. In-Reply-To: <20110114202627.17162.52400@domU-12-31-38-00-90-68.compute-1.internal> References: <20110114202627.17162.52400@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110116133527.25766.69981@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/80/ ----------------------------------------------------------- (Updated Jan. 16, 2011, 5:35 a.m.) Review request for Viewer. Changes ------- This new diff addresses Boroondas' list/tuple remark. I also added a fix to remove empty directories. Before this patch, install.py would only delete (empty) directories that were a part of the path of a deleted file. The problem with that is that if a tar ball contains an empty directory, it is never removed. I ran into this while running new tests. Fully tested (on linux). Thanks to Boroondas for assistance with the python syntax. Summary ------- See https://jira.secondlife.com/browse/VWR-24311 Basically, this fixes the TODO comment in install.py but with the difference that we really want to uninstall any old package with the same name, different md5 or not. This addresses bug VWR-24311. http://jira.secondlife.com/browse/VWR-24311 Diffs (updated) ----- doc/contributions.txt 422f636c3343 scripts/install.py 422f636c3343 Diff: http://codereview.secondlife.com/r/80/diff Testing ------- Loads of testing on linux... Installing new packages now cleanly removes the old one first. Thanks, Aleric -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110116/d1300588/attachment.htm From Aleric.Inglewood at gmail.com Sun Jan 16 05:53:19 2011 From: Aleric.Inglewood at gmail.com (Aleric Inglewood) Date: Sun, 16 Jan 2011 13:53:19 -0000 Subject: [opensource-dev] Review Request: VWR-24312: Massively duplicated objects (part 2) In-Reply-To: <20110114203411.17162.12107@domU-12-31-38-00-90-68.compute-1.internal> References: <20110114203411.17162.12107@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110116135319.26155.13876@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/81/ ----------------------------------------------------------- (Updated Jan. 16, 2011, 5:53 a.m.) Review request for Viewer. Changes ------- Changed tab's into spaces in the part that Boroondas pointed out (in indra/llcharacter/llanimationstates.cpp). Summary ------- Turns out that most of my SNOW-800 patch was included in Viewer 2 (albeit without crediting me). However, not everything was used and some more cleaning up was possible. After this patch, and when compiling with optimization, there are no duplicates left anymore that shouldn't be there in the first place: apart from the debug stream iostream guard variable, there are several static variables with the same name (r, r1, r2, etc) but that indeed actually different symbol objects. Then there are a few constant POD arrays that are duplicated a hand full of times because they are accessed with a variable index (so optimizing them away is not possible). I left them like that (although defining those as extern as well would have been more consistent and not slower; in fact it would be faster theoretically because those arrays could share the same cache page then). This addresses bug VWR-24312. http://jira.secondlife.com/browse/VWR-24312 Diffs (updated) ----- doc/contributions.txt 422f636c3343 indra/llcharacter/llanimationstates.cpp 422f636c3343 indra/llcommon/llavatarconstants.h 422f636c3343 indra/llcommon/lllslconstants.h 422f636c3343 indra/llcommon/llmetricperformancetester.h 422f636c3343 indra/llmath/llcamera.h 422f636c3343 indra/llmath/llcamera.cpp 422f636c3343 indra/newview/llviewerobject.cpp 422f636c3343 indra/newview/llvoavatar.cpp 422f636c3343 indra/newview/llvosky.h 422f636c3343 indra/newview/llvosky.cpp 422f636c3343 Diff: http://codereview.secondlife.com/r/81/diff Testing ------- Compiled with optimization and then running readelf on the executable to find duplicated symbols. Thanks, Aleric -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110116/49f50523/attachment.htm From Aleric.Inglewood at gmail.com Sun Jan 16 05:53:51 2011 From: Aleric.Inglewood at gmail.com (Aleric Inglewood) Date: Sun, 16 Jan 2011 13:53:51 -0000 Subject: [opensource-dev] Review Request: VWR-24312: Massively duplicated objects (part 2) In-Reply-To: <20110114213157.17161.57957@domU-12-31-38-00-90-68.compute-1.internal> References: <20110114213157.17161.57957@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110116135351.25761.94582@domU-12-31-38-00-90-68.compute-1.internal> > On Jan. 14, 2011, 1:31 p.m., Boroondas Gupte wrote: > > indra/llcommon/lllslconstants.h, line 184 > > > > > > Yay for having type modifiers after the core type name. Makes them much easier to understand, especially when there are several cascaded ones. :-) Yeah, I'm strongly convinced that TYPE const is superior in anyway over const TYPE. See http://www.xs4all.nl/~carlo17/cpp/const.qualifier.html for the reasoning. In one line: all type qualifiers work to the left, it's best to PUT them on the left so the whole type is logically uniform in it's construction. The fact that you can legally type 'const TYPE' is just a historically grown misfortune. - Aleric ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/81/#review153 ----------------------------------------------------------- On Jan. 16, 2011, 5:53 a.m., Aleric Inglewood wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/81/ > ----------------------------------------------------------- > > (Updated Jan. 16, 2011, 5:53 a.m.) > > > Review request for Viewer. > > > Summary > ------- > > Turns out that most of my SNOW-800 patch was included in Viewer 2 (albeit without crediting me). > However, not everything was used and some more cleaning up was possible. > > After this patch, and when compiling with optimization, there are no duplicates left > anymore that shouldn't be there in the first place: apart from the debug stream > iostream guard variable, there are several static variables with the same name (r, r1, > r2, etc) but that indeed actually different symbol objects. Then there are a few > constant POD arrays that are duplicated a hand full of times because they are > accessed with a variable index (so optimizing them away is not possible). I left them > like that (although defining those as extern as well would have been more consistent > and not slower; in fact it would be faster theoretically because those arrays could > share the same cache page then). > > > This addresses bug VWR-24312. > http://jira.secondlife.com/browse/VWR-24312 > > > Diffs > ----- > > doc/contributions.txt 422f636c3343 > indra/llcharacter/llanimationstates.cpp 422f636c3343 > indra/llcommon/llavatarconstants.h 422f636c3343 > indra/llcommon/lllslconstants.h 422f636c3343 > indra/llcommon/llmetricperformancetester.h 422f636c3343 > indra/llmath/llcamera.h 422f636c3343 > indra/llmath/llcamera.cpp 422f636c3343 > indra/newview/llviewerobject.cpp 422f636c3343 > indra/newview/llvoavatar.cpp 422f636c3343 > indra/newview/llvosky.h 422f636c3343 > indra/newview/llvosky.cpp 422f636c3343 > > Diff: http://codereview.secondlife.com/r/81/diff > > > Testing > ------- > > Compiled with optimization and then running readelf on the executable to find duplicated symbols. > > > Thanks, > > Aleric > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110116/f684a403/attachment-0001.htm From Aleric.Inglewood at gmail.com Sun Jan 16 06:12:37 2011 From: Aleric.Inglewood at gmail.com (Aleric Inglewood) Date: Sun, 16 Jan 2011 14:12:37 -0000 Subject: [opensource-dev] Review Request: VWR-24317: Incorrect start up warnings: WARNING: remove: Attempting to remove filename: /ramdisk/imprudence/cache/textures/*/*.texture In-Reply-To: <20110114205057.17158.38187@domU-12-31-38-00-90-68.compute-1.internal> References: <20110114205057.17158.38187@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110116141237.26155.39299@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/84/ ----------------------------------------------------------- (Updated Jan. 16, 2011, 6:12 a.m.) Review request for Viewer. Changes ------- Renamed the variable to 'file_maybe_exists', which should cover its meaning more accurately, thanks! Changed the warning into LL_WARNS("TextureCache") << "Entry has body size of zero but file " << filename << " exists. Deleting this file, too." << LL_ENDL; The second part is the 'resolution' of the problem. Your proposal sounded a bit too much as if the warning was about the fact that the file was being removed... Summary ------- This turned out to be a simple matter of trying to remove non-existant files: A texture with a 'body size' of 0 doesn't have a texture body file. This addresses bug VWR-24317. http://jira.secondlife.com/browse/VWR-24317 Diffs (updated) ----- indra/newview/lltexturecache.cpp b0bd26c5638a Diff: http://codereview.secondlife.com/r/84/diff Testing ------- Thanks, Aleric -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110116/559164a5/attachment.htm From sllists at boroon.dasgupta.ch Sun Jan 16 06:15:44 2011 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Sun, 16 Jan 2011 14:15:44 -0000 Subject: [opensource-dev] Review Request: VWR-24311: Uninstall packages that are renewed. In-Reply-To: <20110116133527.25766.69981@domU-12-31-38-00-90-68.compute-1.internal> References: <20110116133527.25766.69981@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110116141544.26155.14984@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/80/#review167 ----------------------------------------------------------- Ship it! scripts/install.py Please add a comment "regular directories (no symlinks)" ... scripts/install.py ... and here a comment "regular files and symlinks", so that the intention behind these conditionals is clear to people unfamiliar with the used os.path functions. Other than that, I'd say it's ready. Great work! - Boroondas On Jan. 16, 2011, 5:35 a.m., Aleric Inglewood wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/80/ > ----------------------------------------------------------- > > (Updated Jan. 16, 2011, 5:35 a.m.) > > > Review request for Viewer. > > > Summary > ------- > > See https://jira.secondlife.com/browse/VWR-24311 > > Basically, this fixes the TODO comment in install.py but with the difference that we really want to uninstall any old package with the same name, different md5 or not. > > > This addresses bug VWR-24311. > http://jira.secondlife.com/browse/VWR-24311 > > > Diffs > ----- > > doc/contributions.txt 422f636c3343 > scripts/install.py 422f636c3343 > > Diff: http://codereview.secondlife.com/r/80/diff > > > Testing > ------- > > Loads of testing on linux... Installing new packages now cleanly removes the old one first. > > > Thanks, > > Aleric > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110116/6a24a14e/attachment.htm From Aleric.Inglewood at gmail.com Sun Jan 16 06:20:11 2011 From: Aleric.Inglewood at gmail.com (Aleric Inglewood) Date: Sun, 16 Jan 2011 14:20:11 -0000 Subject: [opensource-dev] Review Request: VWR-24317: Incorrect start up warnings: WARNING: ll_apr_warn_status: APR: No such file or directory In-Reply-To: <20110114214750.17160.40207@domU-12-31-38-00-90-68.compute-1.internal> References: <20110114214750.17160.40207@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110116142011.25763.44653@domU-12-31-38-00-90-68.compute-1.internal> > On Jan. 14, 2011, 1:47 p.m., Boroondas Gupte wrote: > > indra/newview/llappviewer.cpp, lines 3091-3094 > > > > > > what's the reason for moving the LL_INFOS around? The last two, in order to print the correct value that gLastExecEvent is being set to: depending on the conditional, the value is set to what was printed, or to another value. The first hunk to have more symmetric code and treat that part the same as the others: first set the variable and then print it's contents. - Aleric ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/83/#review154 ----------------------------------------------------------- On Jan. 14, 2011, 12:48 p.m., Aleric Inglewood wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/83/ > ----------------------------------------------------------- > > (Updated Jan. 14, 2011, 12:48 p.m.) > > > Review request for Viewer. > > > Summary > ------- > > At start up one can get the following ?warnings?: > > 2010-10-23T12:22:44Z WARNING: ll_apr_warn_status: APR: No such file or directory > 2010-10-23T12:22:44Z WARNING: remove: Attempting to remove filename: /home/aleric/.imprudence/logs/Imprudence.logout_marker > 2010-10-23T12:22:44Z WARNING: ll_apr_warn_status: APR: No such file or directory > 2010-10-23T12:22:44Z WARNING: remove: Attempting to remove filename: /home/aleric/.imprudence/logs/Imprudence.llerror_marker > 2010-10-23T12:22:44Z WARNING: ll_apr_warn_status: APR: No such file or directory > 2010-10-23T12:22:44Z WARNING: remove: Attempting to remove filename: /home/aleric/.imprudence/logs/Imprudence.error_marker > > This is nonsense since it is perfectly ok when those files don?t exist. > > > This addresses bug VWR-24317. > http://jira.secondlife.com/browse/VWR-24317 > > > Diffs > ----- > > indra/newview/llappviewer.cpp b0bd26c5638a > > Diff: http://codereview.secondlife.com/r/83/diff > > > Testing > ------- > > > Thanks, > > Aleric > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110116/937eb6e9/attachment-0001.htm From sllists at boroon.dasgupta.ch Sun Jan 16 06:25:18 2011 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Sun, 16 Jan 2011 14:25:18 -0000 Subject: [opensource-dev] Review Request: VWR-24317: Incorrect start up warnings: WARNING: ll_apr_warn_status: APR: No such file or directory In-Reply-To: <20110114214750.17160.40207@domU-12-31-38-00-90-68.compute-1.internal> References: <20110114214750.17160.40207@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110116142518.25763.49683@domU-12-31-38-00-90-68.compute-1.internal> > On Jan. 14, 2011, 1:47 p.m., Boroondas Gupte wrote: > > indra/newview/llappviewer.cpp, lines 3091-3094 > > > > > > what's the reason for moving the LL_INFOS around? > > Aleric Inglewood wrote: > The last two, in order to print the correct value that gLastExecEvent is being set to: depending on the conditional, the value is set to what was printed, or to another value. The first hunk to have more symmetric code and treat that part the same as the others: first set the variable and then print it's contents. Makes sense. - Boroondas ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/83/#review154 ----------------------------------------------------------- On Jan. 14, 2011, 12:48 p.m., Aleric Inglewood wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/83/ > ----------------------------------------------------------- > > (Updated Jan. 14, 2011, 12:48 p.m.) > > > Review request for Viewer. > > > Summary > ------- > > At start up one can get the following ?warnings?: > > 2010-10-23T12:22:44Z WARNING: ll_apr_warn_status: APR: No such file or directory > 2010-10-23T12:22:44Z WARNING: remove: Attempting to remove filename: /home/aleric/.imprudence/logs/Imprudence.logout_marker > 2010-10-23T12:22:44Z WARNING: ll_apr_warn_status: APR: No such file or directory > 2010-10-23T12:22:44Z WARNING: remove: Attempting to remove filename: /home/aleric/.imprudence/logs/Imprudence.llerror_marker > 2010-10-23T12:22:44Z WARNING: ll_apr_warn_status: APR: No such file or directory > 2010-10-23T12:22:44Z WARNING: remove: Attempting to remove filename: /home/aleric/.imprudence/logs/Imprudence.error_marker > > This is nonsense since it is perfectly ok when those files don?t exist. > > > This addresses bug VWR-24317. > http://jira.secondlife.com/browse/VWR-24317 > > > Diffs > ----- > > indra/newview/llappviewer.cpp b0bd26c5638a > > Diff: http://codereview.secondlife.com/r/83/diff > > > Testing > ------- > > > Thanks, > > Aleric > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110116/84d1e3d4/attachment.htm From vsavchuk at productengine.com Sun Jan 16 07:37:41 2011 From: vsavchuk at productengine.com (Vadim ProductEngine) Date: Sun, 16 Jan 2011 15:37:41 -0000 Subject: [opensource-dev] Review Request: (STORM-383) Context menu cannot be open for Landmark that are located in the My inventory->Trash folder In-Reply-To: <20110115001340.17162.5726@domU-12-31-38-00-90-68.compute-1.internal> References: <20110115001340.17162.5726@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110116153741.26332.21783@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/77/#review170 ----------------------------------------------------------- indra/newview/llpanellandmarks.cpp Why are the checks for are_all_items_in_trash and are_any_items_in_trash different? I guess it should be something like: bool item_in_trash = listenerp->isItemInTrash() && *iter != trash_id; are_all_items_in_trash &= item_in_trash; are_any_items_in_trash |= item_in_trash; indra/newview/llpanellandmarks.cpp Although we use the same approach in the Appearance SP for enabling/displaying context menu items, it may be not what users expect. Please clearly state this behavior in the ticket comment for PO to notice. - Vadim On Jan. 14, 2011, 4:13 p.m., Seth ProductEngine wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/77/ > ----------------------------------------------------------- > > (Updated Jan. 14, 2011, 4:13 p.m.) > > > Review request for Viewer. > > > Summary > ------- > > Added "Restore Item" context menu entry for landmarks and folders in Trash category in Places->My Landmarks->My Inventory accordion tab. > > > This addresses bug STORM-383. > http://jira.secondlife.com/browse/STORM-383 > > > Diffs > ----- > > indra/newview/llpanellandmarks.h 422f636c3343 > indra/newview/llpanellandmarks.cpp 422f636c3343 > indra/newview/skins/default/xui/en/menu_places_gear_folder.xml 422f636c3343 > indra/newview/skins/default/xui/en/menu_places_gear_landmark.xml 422f636c3343 > > Diff: http://codereview.secondlife.com/r/77/diff > > > Testing > ------- > > > Thanks, > > Seth > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110116/245aed93/attachment.htm From aleric.inglewood at gmail.com Sun Jan 16 07:49:30 2011 From: aleric.inglewood at gmail.com (Aleric Inglewood) Date: Sun, 16 Jan 2011 16:49:30 +0100 Subject: [opensource-dev] Link times In-Reply-To: <4D30D2F6.2010008@boroon.dasgupta.ch> References: <4D30D2F6.2010008@boroon.dasgupta.ch> Message-ID: I'm afraid that VWR-24366 won't reduce link times significantly. On Fri, Jan 14, 2011 at 11:49 PM, Boroondas Gupte wrote: > On 01/14/2011 06:04 PM, Jonathan Welch wrote: > > I just did a quick study on link times for various viewers on my 2Gb XP > system > > Viewer 1st link 2nd link > CV 1.22 0:53 0:24 > SG 1.5 3:30 2:07 > V2.5 6:18 6:01 > > The long time for 2.5 be due to VWR-24366. Dunno why linking Cool Viewer > (that's what "CV" stands for, isn't it?) is so much quicker than SG 1.5, > though. > > Good news: A fix is being reviewed at > https://codereview.secondlife.com/r/95/ > > 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 jhwelch at gmail.com Sun Jan 16 10:03:05 2011 From: jhwelch at gmail.com (Jonathan Yap) Date: Sun, 16 Jan 2011 18:03:05 -0000 Subject: [opensource-dev] Review Request: Storm-844 "More" should be "Less" when Media Control is open In-Reply-To: <20110113160522.17389.17138@domU-12-31-38-00-90-68.compute-1.internal> References: <20110113160522.17389.17138@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110116180305.25764.60400@domU-12-31-38-00-90-68.compute-1.internal> > On Jan. 13, 2011, 8:05 a.m., Twisted Laws wrote: > > To me, this is the wrong solution. label_selected used to work to allow a button to display different text when it was selected, so you could have a button that said More until it was pressed or selected and displayed more informaiton. At that time the text could change to Less indicating that pressing the button a second time would maybe reduce the information displayed. If the button in question here doesn't change when pressing, that means that something down in the control code is wrong. > > Jonathan Yap wrote: > I did a test with the floater preview UI (one of the few places that label is not the same as label_selected. There is a >> button there that does change to << when pressed. > > However, in this case, there is some code that does the button swapping. In llpanelnearbymedia.cpp / void LLPanelNearByMedia::onMoreLess() > > getChild("more_btn")->setVisible(!is_more); > getChild("less_btn")->setVisible(is_more); > > If people think refactoring rather then just rewording is the way to go please say so. I always hesitate to "fix what ain't broke". > > The vast majority of button definitions in the xml files have identical entries for label and label_selected (is having label_selected present a requirement in a button definition or are all these entires superfluous?). > > Twisted Laws wrote: > I looked into this and have a patch that corrects it. What the patch does in llPanelNearByMedia::onMoreLess(), the first statement is changed to bool is_more = getChild("more_btn")->getToggleState(); the two statements Jonathan shows are changed to just one getChild("more_btn")->setVisible(true); (may just be removed and not be necessary) and in the xml file, the first more_btn gets is_toggle="true" added and the less_btn is removed. My patch file is attached to STORM-844. I applied this patch and you can view it via the link to the repository in the jira. - Jonathan ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/78/#review148 ----------------------------------------------------------- On Jan. 12, 2011, 6:02 a.m., Jonathan Yap wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/78/ > ----------------------------------------------------------- > > (Updated Jan. 12, 2011, 6:02 a.m.) > > > Review request for Viewer. > > > Summary > ------- > > "More" should be "Less" when Media Control is open > > This is a trivial text change in an xml file. The reason I am posting this here is due to some confusion using label_selected. In this case having it set to a different value than when label is set to seems to have no effect, so I have made them identical. > > I scanned all the xml files and there are only about 5 places where label_selected is different from the preceding label= value. > > Is there any reason to revert back to having them set to different values? > i.e. label="More" and label_selected="Less" > > > This addresses bug storm-844. > http://jira.secondlife.com/browse/storm-844 > > > Diffs > ----- > > doc/contributions.txt 179e0754a27d > indra/newview/skins/default/xui/en/panel_nearby_media.xml 179e0754a27d > > Diff: http://codereview.secondlife.com/r/78/diff > > > Testing > ------- > > > Thanks, > > Jonathan > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110116/991b75f5/attachment.htm From oz at lindenlab.com Mon Jan 17 04:17:34 2011 From: oz at lindenlab.com (Oz Linden (Scott Lawrence)) Date: Mon, 17 Jan 2011 07:17:34 -0500 Subject: [opensource-dev] Linden holiday - Oz office hour cancelled Message-ID: <4D34335E.7010806@lindenlab.com> Monday 17 January is a Linden Lab employee holiday. so I won't be holding my Office Hour. From oz at lindenlab.com Mon Jan 17 04:31:49 2011 From: oz at lindenlab.com (Oz Linden) Date: Mon, 17 Jan 2011 12:31:49 -0000 Subject: [opensource-dev] Review Request: VWR-24317: Fix of debug warning (printing of unassigned variable) In-Reply-To: <20110114205612.17159.77015@domU-12-31-38-00-90-68.compute-1.internal> References: <20110114205612.17159.77015@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110117123149.25766.50352@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/87/#review172 ----------------------------------------------------------- indra/llui/llnotifications.cpp I don't like leaving in commented-out code. I would prefer that this either be changed to a debug level message or deleted. - Oz On Jan. 14, 2011, 12:56 p.m., Aleric Inglewood wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/87/ > ----------------------------------------------------------- > > (Updated Jan. 14, 2011, 12:56 p.m.) > > > Review request for Viewer. > > > Summary > ------- > > Fixed a typo that I stumbled upon and added quotes, > and changed the warning to print something that makes > more sense ('replacement' is always empty, since we > didn't find it!) > > > This addresses bug VWR-24317. > http://jira.secondlife.com/browse/VWR-24317 > > > Diffs > ----- > > doc/contributions.txt b0bd26c5638a > indra/llui/llnotifications.cpp b0bd26c5638a > > Diff: http://codereview.secondlife.com/r/87/diff > > > Testing > ------- > > > Thanks, > > Aleric > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110117/5703b669/attachment.htm From Aleric.Inglewood at gmail.com Mon Jan 17 05:24:37 2011 From: Aleric.Inglewood at gmail.com (Aleric Inglewood) Date: Mon, 17 Jan 2011 13:24:37 -0000 Subject: [opensource-dev] Review Request: VWR-24311: Uninstall packages that are renewed. In-Reply-To: <20110116133527.25766.69981@domU-12-31-38-00-90-68.compute-1.internal> References: <20110116133527.25766.69981@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110117132437.25763.68327@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/80/ ----------------------------------------------------------- (Updated Jan. 17, 2011, 5:24 a.m.) Review request for Viewer. Changes ------- Added requested comments. Summary ------- See https://jira.secondlife.com/browse/VWR-24311 Basically, this fixes the TODO comment in install.py but with the difference that we really want to uninstall any old package with the same name, different md5 or not. This addresses bug VWR-24311. http://jira.secondlife.com/browse/VWR-24311 Diffs (updated) ----- doc/contributions.txt 422f636c3343 scripts/install.py 422f636c3343 Diff: http://codereview.secondlife.com/r/80/diff Testing ------- Loads of testing on linux... Installing new packages now cleanly removes the old one first. Thanks, Aleric -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110117/43cc8c50/attachment.htm From sllists at boroon.dasgupta.ch Mon Jan 17 05:30:36 2011 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Mon, 17 Jan 2011 13:30:36 -0000 Subject: [opensource-dev] Review Request: VWR-24311: Uninstall packages that are renewed. In-Reply-To: <20110117132437.25763.68327@domU-12-31-38-00-90-68.compute-1.internal> References: <20110117132437.25763.68327@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110117133036.25993.7887@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/80/#review173 ----------------------------------------------------------- Ship it! - Boroondas On Jan. 17, 2011, 5:24 a.m., Aleric Inglewood wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/80/ > ----------------------------------------------------------- > > (Updated Jan. 17, 2011, 5:24 a.m.) > > > Review request for Viewer. > > > Summary > ------- > > See https://jira.secondlife.com/browse/VWR-24311 > > Basically, this fixes the TODO comment in install.py but with the difference that we really want to uninstall any old package with the same name, different md5 or not. > > > This addresses bug VWR-24311. > http://jira.secondlife.com/browse/VWR-24311 > > > Diffs > ----- > > doc/contributions.txt 422f636c3343 > scripts/install.py 422f636c3343 > > Diff: http://codereview.secondlife.com/r/80/diff > > > Testing > ------- > > Loads of testing on linux... Installing new packages now cleanly removes the old one first. > > > Thanks, > > Aleric > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110117/ebf4b532/attachment.htm From Aleric.Inglewood at gmail.com Mon Jan 17 05:32:26 2011 From: Aleric.Inglewood at gmail.com (Aleric Inglewood) Date: Mon, 17 Jan 2011 13:32:26 -0000 Subject: [opensource-dev] Review Request: VWR-24317: Fix of debug warning (printing of unassigned variable) In-Reply-To: <20110114205612.17159.77015@domU-12-31-38-00-90-68.compute-1.internal> References: <20110114205612.17159.77015@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110117133226.25766.57123@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/87/ ----------------------------------------------------------- (Updated Jan. 17, 2011, 5:32 a.m.) Review request for Viewer. Changes ------- Got rid of commented out debug output in replaceSubstitutionStrings. Deleted the first llwarns and changed a second one into lldebugs. Summary ------- Fixed a typo that I stumbled upon and added quotes, and changed the warning to print something that makes more sense ('replacement' is always empty, since we didn't find it!) This addresses bug VWR-24317. http://jira.secondlife.com/browse/VWR-24317 Diffs (updated) ----- doc/contributions.txt b0bd26c5638a indra/llui/llnotifications.cpp b0bd26c5638a Diff: http://codereview.secondlife.com/r/87/diff Testing ------- Thanks, Aleric -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110117/f7ea619b/attachment.htm From tateru.nino at gmail.com Mon Jan 17 06:55:58 2011 From: tateru.nino at gmail.com (Tateru Nino) Date: Tue, 18 Jan 2011 01:55:58 +1100 Subject: [opensource-dev] Review Request: VWR-24317: Fix of debug warning (printing of unassigned variable) In-Reply-To: <20110117123149.25766.50352@domU-12-31-38-00-90-68.compute-1.internal> References: <20110114205612.17159.77015@domU-12-31-38-00-90-68.compute-1.internal> <20110117123149.25766.50352@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <4D34587E.8090600@gmail.com> I confess to not liking leaving in incorrectly spelled commented code. Just saying. On 17/01/2011 11:31 PM, Oz Linden wrote: > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/87/ > > > indra/llui/llnotifications.cpp > > (Diff revision 1) > void replaceSubstitutionStrings(LLXMLNodePtr node, StringMap& replacements) > 1384 > //llwarns<< "replaceSubstituionStrings: value: "<< value<< " repl: "<< replacement<< llendl; > 1384 > //llinfos<< "replaceSubstitutionStrings: value:\""<< value<< "\" repl:\""<< replacement<< "\"."<< llendl; > > I don't like leaving in commented-out code. > > I would prefer that this either be changed to a debug level message or deleted. > > - Oz > > > On January 14th, 2011, 12:56 p.m., Aleric Inglewood wrote: > > Review request for Viewer. > By Aleric Inglewood. > > /Updated Jan. 14, 2011, 12:56 p.m./ > > > Description > > Fixed a typo that I stumbled upon and added quotes, > and changed the warning to print something that makes > more sense ('replacement' is always empty, since we > didn't find it!) > > *Bugs: * VWR-24317 > > > Diffs > > * doc/contributions.txt (b0bd26c5638a) > * indra/llui/llnotifications.cpp (b0bd26c5638a) > > View Diff > > > _______________________________________________ > Policies 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/20110118/7ab573cb/attachment-0001.htm From oz at lindenlab.com Mon Jan 17 07:28:04 2011 From: oz at lindenlab.com (Oz Linden) Date: Mon, 17 Jan 2011 15:28:04 -0000 Subject: [opensource-dev] Review Request: VWR-24420: PNG images which specify "background color" lose alpha layer when imported. In-Reply-To: <20110109145917.7202.23064@domU-12-31-38-00-90-68.compute-1.internal> References: <20110109145917.7202.23064@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110117152804.26155.17661@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/74/#review174 ----------------------------------------------------------- Ship it! - Oz On Jan. 9, 2011, 6:59 a.m., Thickbrick Sleaford wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/74/ > ----------------------------------------------------------- > > (Updated Jan. 9, 2011, 6:59 a.m.) > > > Review request for Viewer. > > > Summary > ------- > > Current code composites RGBA PNG images that contain a bKGD chunk down to RGB, discarding the alpha channel. This patch removes that code, since it contradicts purpose of the bKGD chunk as described in the PNG spec and as commonly used. > > > This addresses bug VWR-24420. > http://jira.secondlife.com/browse/VWR-24420 > > > Diffs > ----- > > doc/contributions.txt UNKNOWN > indra/llimage/llpngwrapper.h UNKNOWN > indra/llimage/llpngwrapper.cpp UNKNOWN > > Diff: http://codereview.secondlife.com/r/74/diff > > > Testing > ------- > > Tested uploading the 2 images attached to VWR-24420 with and without the patch. Before patch, "bad alpha.png" was uploaded as RGB, after patch, both images were uploaded as RGBA. > > > Thanks, > > Thickbrick > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110117/667deead/attachment.htm From oz at lindenlab.com Mon Jan 17 07:33:24 2011 From: oz at lindenlab.com (Oz Linden) Date: Mon, 17 Jan 2011 15:33:24 -0000 Subject: [opensource-dev] Review Request: VWR-24347 Reversion in Copy3rdPartyLibs.cmake -- cannot find msvc* files using VS 2005 Express In-Reply-To: <20101229234218.20369.35141@domU-12-31-38-00-90-68.compute-1.internal> References: <20101229234218.20369.35141@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110117153324.25760.3666@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/68/#review175 ----------------------------------------------------------- Given that we are in the process of moving to VS2010, I suggest that this is not worth doing - Oz On Dec. 29, 2010, 3:42 p.m., Jonathan Yap wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/68/ > ----------------------------------------------------------- > > (Updated Dec. 29, 2010, 3:42 p.m.) > > > Review request for Viewer. > > > Summary > ------- > > Environment: Windows, VS 2005 Express > > Back in the days of v2.1 I was able to supply the following option to develop.py, which would allow me to specify the location of > msvcr80.dll > msvcp80.dll > Microsoft.VC80.CRT.manifest > > -DMSVC_REDIST_PATH:PATH=E:/some/path > > There was a similar code path for the debug files > -DMSVC_DEBUG_REDIST_PATH=E:/some/path > > This files cannot be found by the Express compiler so without a way of telling the compiler where to find them they have to be dropped into the build tree manually. > > At some point Copy3rdPartyLibs.cmake was rewritten and this option was dropped. > > > This addresses bug vwr-24347. > http://jira.secondlife.com/browse/vwr-24347 > > > Diffs > ----- > > indra/cmake/Copy3rdPartyLibs.cmake 27dae7b01a81 > > Diff: http://codereview.secondlife.com/r/68/diff > > > Testing > ------- > > I tried using -DMSVC_REDIST_PATH:PATH=E:/some/path with my VS 2005 Express compiler and obtained the desired result. > > I don't have the debug files to test -DMSVC_DEBUG_REDIST_PATH=E:/some/path > > > Thanks, > > Jonathan > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110117/cabad821/attachment.htm From slitovchuk at productengine.com Mon Jan 17 08:17:01 2011 From: slitovchuk at productengine.com (Seth ProductEngine) Date: Mon, 17 Jan 2011 16:17:01 -0000 Subject: [opensource-dev] Review Request: (STORM-383) Context menu cannot be open for Landmark that are located in the My inventory->Trash folder In-Reply-To: <20110115001340.17162.5726@domU-12-31-38-00-90-68.compute-1.internal> References: <20110115001340.17162.5726@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110117161701.25762.69346@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/77/ ----------------------------------------------------------- (Updated Jan. 17, 2011, 8:17 a.m.) Review request for Viewer. Changes ------- Minor style-related changes. Added comments. Summary ------- Added "Restore Item" context menu entry for landmarks and folders in Trash category in Places->My Landmarks->My Inventory accordion tab. This addresses bug STORM-383. http://jira.secondlife.com/browse/STORM-383 Diffs (updated) ----- indra/newview/llpanellandmarks.h 422f636c3343 indra/newview/llpanellandmarks.cpp 422f636c3343 indra/newview/skins/default/xui/en/menu_places_gear_folder.xml 422f636c3343 indra/newview/skins/default/xui/en/menu_places_gear_landmark.xml 422f636c3343 Diff: http://codereview.secondlife.com/r/77/diff Testing ------- Thanks, Seth -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110117/17c87340/attachment.htm From slitovchuk at productengine.com Mon Jan 17 08:18:36 2011 From: slitovchuk at productengine.com (Seth ProductEngine) Date: Mon, 17 Jan 2011 16:18:36 -0000 Subject: [opensource-dev] Review Request: (STORM-383) Context menu cannot be open for Landmark that are located in the My inventory->Trash folder In-Reply-To: <20110116153741.26332.21783@domU-12-31-38-00-90-68.compute-1.internal> References: <20110116153741.26332.21783@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110117161836.25764.78555@domU-12-31-38-00-90-68.compute-1.internal> > On Jan. 16, 2011, 7:37 a.m., Vadim ProductEngine wrote: > > indra/newview/llpanellandmarks.cpp, lines 1127-1132 > > > > > > Why are the checks for are_all_items_in_trash and are_any_items_in_trash different? > > > > I guess it should be something like: > > > > bool item_in_trash = listenerp->isItemInTrash() && *iter != trash_id; > > are_all_items_in_trash &= item_in_trash; > > are_any_items_in_trash |= item_in_trash; Probably it will look more pretty this way. But the checks should remain different in order not to enable "Restore Item" when Trash folder is selected and not to display an empty menu when some of the selected items are in Trash and some aren't. - Seth ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/77/#review170 ----------------------------------------------------------- On Jan. 17, 2011, 8:17 a.m., Seth ProductEngine wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/77/ > ----------------------------------------------------------- > > (Updated Jan. 17, 2011, 8:17 a.m.) > > > Review request for Viewer. > > > Summary > ------- > > Added "Restore Item" context menu entry for landmarks and folders in Trash category in Places->My Landmarks->My Inventory accordion tab. > > > This addresses bug STORM-383. > http://jira.secondlife.com/browse/STORM-383 > > > Diffs > ----- > > indra/newview/llpanellandmarks.h 422f636c3343 > indra/newview/llpanellandmarks.cpp 422f636c3343 > indra/newview/skins/default/xui/en/menu_places_gear_folder.xml 422f636c3343 > indra/newview/skins/default/xui/en/menu_places_gear_landmark.xml 422f636c3343 > > Diff: http://codereview.secondlife.com/r/77/diff > > > Testing > ------- > > > Thanks, > > Seth > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110117/4d5ec0c1/attachment-0001.htm From vsavchuk at productengine.com Mon Jan 17 08:54:30 2011 From: vsavchuk at productengine.com (Vadim ProductEngine) Date: Mon, 17 Jan 2011 16:54:30 -0000 Subject: [opensource-dev] Review Request: (STORM-383) Context menu cannot be open for Landmark that are located in the My inventory->Trash folder In-Reply-To: <20110117161701.25762.69346@domU-12-31-38-00-90-68.compute-1.internal> References: <20110117161701.25762.69346@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110117165430.25764.20178@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/77/#review177 ----------------------------------------------------------- Ship it! Alright then. - Vadim On Jan. 17, 2011, 8:17 a.m., Seth ProductEngine wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/77/ > ----------------------------------------------------------- > > (Updated Jan. 17, 2011, 8:17 a.m.) > > > Review request for Viewer. > > > Summary > ------- > > Added "Restore Item" context menu entry for landmarks and folders in Trash category in Places->My Landmarks->My Inventory accordion tab. > > > This addresses bug STORM-383. > http://jira.secondlife.com/browse/STORM-383 > > > Diffs > ----- > > indra/newview/llpanellandmarks.h 422f636c3343 > indra/newview/llpanellandmarks.cpp 422f636c3343 > indra/newview/skins/default/xui/en/menu_places_gear_folder.xml 422f636c3343 > indra/newview/skins/default/xui/en/menu_places_gear_landmark.xml 422f636c3343 > > Diff: http://codereview.secondlife.com/r/77/diff > > > Testing > ------- > > > Thanks, > > Seth > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110117/8a5a0ddd/attachment.htm From jhwelch at gmail.com Mon Jan 17 09:17:25 2011 From: jhwelch at gmail.com (Jonathan Yap) Date: Mon, 17 Jan 2011 17:17:25 -0000 Subject: [opensource-dev] Review Request: VWR-24347 Reversion in Copy3rdPartyLibs.cmake -- cannot find msvc* files using VS 2005 Express In-Reply-To: <20110117153324.25760.3666@domU-12-31-38-00-90-68.compute-1.internal> References: <20110117153324.25760.3666@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110117171725.25759.54334@domU-12-31-38-00-90-68.compute-1.internal> > On Jan. 17, 2011, 7:33 a.m., Oz Linden wrote: > > Given that we are in the process of moving to VS2010, I suggest that this is not worth doing Oz, I think it is worth doing, but doing it it a more general and forward-looking way, unless VS2010 Express will not have this issue. Please see the comment I just wrote in https://jira.secondlife.com/browse/vwr-24347 and let me know what you think. - Jonathan ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/68/#review175 ----------------------------------------------------------- On Dec. 29, 2010, 3:42 p.m., Jonathan Yap wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/68/ > ----------------------------------------------------------- > > (Updated Dec. 29, 2010, 3:42 p.m.) > > > Review request for Viewer. > > > Summary > ------- > > Environment: Windows, VS 2005 Express > > Back in the days of v2.1 I was able to supply the following option to develop.py, which would allow me to specify the location of > msvcr80.dll > msvcp80.dll > Microsoft.VC80.CRT.manifest > > -DMSVC_REDIST_PATH:PATH=E:/some/path > > There was a similar code path for the debug files > -DMSVC_DEBUG_REDIST_PATH=E:/some/path > > This files cannot be found by the Express compiler so without a way of telling the compiler where to find them they have to be dropped into the build tree manually. > > At some point Copy3rdPartyLibs.cmake was rewritten and this option was dropped. > > > This addresses bug vwr-24347. > http://jira.secondlife.com/browse/vwr-24347 > > > Diffs > ----- > > indra/cmake/Copy3rdPartyLibs.cmake 27dae7b01a81 > > Diff: http://codereview.secondlife.com/r/68/diff > > > Testing > ------- > > I tried using -DMSVC_REDIST_PATH:PATH=E:/some/path with my VS 2005 Express compiler and obtained the desired result. > > I don't have the debug files to test -DMSVC_DEBUG_REDIST_PATH=E:/some/path > > > Thanks, > > Jonathan > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110117/579ffed8/attachment.htm From sllists at boroon.dasgupta.ch Mon Jan 17 10:03:31 2011 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Mon, 17 Jan 2011 18:03:31 -0000 Subject: [opensource-dev] Review Request: VWR-24520: Don't use pkg_check_modules( ... QUIET ) on CMake < 2.8.2 Message-ID: <20110117180331.25764.31179@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/97/ ----------------------------------------------------------- Review request for Viewer. Summary ------- Only use QUIET in pkg_check_modules() on CMake >=2.8.2 (where it's supported) rather than already on CMake >=2.8. This addresses bug VWR-24520. http://jira.secondlife.com/browse/VWR-24520 Diffs ----- doc/contributions.txt 9e99b2c8fb28 indra/cmake/FindLLQtWebkit.cmake 9e99b2c8fb28 Diff: http://codereview.secondlife.com/r/97/diff Testing ------- Configured (standalone) without a .pgk file for libllqtwebkit on Linux with CMake 2.8.1 and CMake 2.8.3. Output as expected. Not tested: * CMake 2.8.2 * system with a .pgk file for libllqtwebkit * non-standalone * Mac, Win Thanks, Boroondas -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110117/9359afa3/attachment.htm From lenglish5 at cox.net Mon Jan 17 11:53:55 2011 From: lenglish5 at cox.net (Lawson English) Date: Mon, 17 Jan 2011 12:53:55 -0700 Subject: [opensource-dev] AW Groupies meeting tomorrow on mesh asset interop format Message-ID: <4D349E53.7040104@cox.net> The AW Groupies meeting tomorrow will be Aaron Walsh talking (in voice with questions taken in voice and text) about the iED OpenFile Format: http://mediagrid.org/news/2010-11_iED_Create_Once_Experience_Everywhere.html at http://maps.secondlife.com/secondlife/ThorneBridgeTown/156/130/22 at 9:30 AM Second Life Time IM Saijanai Kuhn for an invite to AW Groupies if you want to participate. Lawson (Saijanai Kuhn in Second Life) From Aleric.Inglewood at gmail.com Mon Jan 17 12:35:35 2011 From: Aleric.Inglewood at gmail.com (Aleric Inglewood) Date: Mon, 17 Jan 2011 20:35:35 -0000 Subject: [opensource-dev] Review Request: VWR-24520: Don't use pkg_check_modules( ... QUIET ) on CMake < 2.8.2 In-Reply-To: <20110117180331.25764.31179@domU-12-31-38-00-90-68.compute-1.internal> References: <20110117180331.25764.31179@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110117203535.26155.89717@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/97/#review179 ----------------------------------------------------------- Ship it! Perfect ;) - Aleric On Jan. 17, 2011, 10:03 a.m., Boroondas Gupte wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/97/ > ----------------------------------------------------------- > > (Updated Jan. 17, 2011, 10:03 a.m.) > > > Review request for Viewer. > > > Summary > ------- > > Only use QUIET in pkg_check_modules() on CMake >=2.8.2 (where it's supported) rather than already on CMake >=2.8. > > > This addresses bug VWR-24520. > http://jira.secondlife.com/browse/VWR-24520 > > > Diffs > ----- > > doc/contributions.txt 9e99b2c8fb28 > indra/cmake/FindLLQtWebkit.cmake 9e99b2c8fb28 > > Diff: http://codereview.secondlife.com/r/97/diff > > > Testing > ------- > > Configured (standalone) without a .pgk file for libllqtwebkit on Linux with CMake 2.8.1 and CMake 2.8.3. Output as expected. > > Not tested: > * CMake 2.8.2 > * system with a .pgk file for libllqtwebkit > * non-standalone > * Mac, Win > > > Thanks, > > Boroondas > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110117/66974c0d/attachment.htm From adyukov at productengine.com Mon Jan 17 13:24:08 2011 From: adyukov at productengine.com (Andrew ProductEngine) Date: Mon, 17 Jan 2011 21:24:08 -0000 Subject: [opensource-dev] Review Request: STORM-2 As a User, I want to set my own default views with specific UI layout so I can tailor my Viewer experience to the activities I'm most interested in. Message-ID: <20110117212408.25763.20611@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/98/ ----------------------------------------------------------- Review request for Viewer. Summary ------- First pass of saving of UI state into files. Implemeted saving of floaters and bottombar buttons state into a named layout. This layout is saved on disk into per-user folder. The folder with layout contains LLSD files. Currently the following features were implemeted: - Saving of bottomtray buttons order and visibility. - Saving floaters rect and visibility info (multiple instances of the same floater are supported) - Saving of sidetray tabs state (docked/undocked). - UI for the feature. TODO: - Add saving dock state for dockable floaters. - Add LL-created default layouts and support for them. - Refactor system of updating lists - get rid of ugly static dirty and it's check in draw. - Add saving of sidetray open/closed state, open tab, etc. This addresses bug STORM-2. http://jira.secondlife.com/browse/STORM-2 Diffs ----- indra/llui/llfloater.h 422f636c3343 indra/llui/llfloaterreg.h 422f636c3343 indra/newview/CMakeLists.txt 422f636c3343 indra/newview/llbottomtray.h 422f636c3343 indra/newview/llbottomtray.cpp 422f636c3343 indra/newview/llfloaterlayouts.h PRE-CREATION indra/newview/llfloaterlayouts.cpp PRE-CREATION indra/newview/llsidetray.h 422f636c3343 indra/newview/llsidetray.cpp 422f636c3343 indra/newview/llviewerfloaterreg.cpp 422f636c3343 indra/newview/llviewermenu.cpp 422f636c3343 indra/newview/skins/default/xui/en/floater_layouts.xml PRE-CREATION indra/newview/skins/default/xui/en/floater_save_layout.xml PRE-CREATION indra/newview/skins/default/xui/en/menu_viewer.xml 422f636c3343 indra/newview/skins/default/xui/en/notifications.xml 422f636c3343 Diff: http://codereview.secondlife.com/r/98/diff Testing ------- Thanks, Andrew -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110117/750a3d4d/attachment.htm From Aleric.Inglewood at gmail.com Mon Jan 17 19:03:48 2011 From: Aleric.Inglewood at gmail.com (Aleric Inglewood) Date: Tue, 18 Jan 2011 03:03:48 -0000 Subject: [opensource-dev] Review Request: STORM-864: As as developer, I would like an object oriented wrapper to make safe use of memory pools easier Message-ID: <20110118030348.26007.5470@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/99/ ----------------------------------------------------------- Review request for Viewer. Summary ------- Please see http://jira.secondlife.com/browse/STORM-864 I made a mercurial repository available for testing here: hg clone https://bitbucket.org/aleric/viewer-development-storm-864 >From the commit message: Introduces a LLThreadLocalData class that can be accessed through the static LLThread::tldata(). Currently this object contains two (public) thread-local objects: a LLAPRRootPool and a LLVolatileAPRPool. The first is the general memory pool used by this thread (and this thread alone), while the second is intended for short lived memory allocations (needed for APR). The advantages of not mixing those two is that the latter is used most frequently, and as a result of it's nature can be destroyed and reconstructed on a "regular" basis. This patch adds LLAPRPool (completely replacing the old one), which is a wrapper around apr_pool_t* and has complete thread-safity checking. Whenever an apr call requires memory for some resource, a memory pool in the form of an LLAPRPool object can be created with the same life-time as this resource; assuring clean up of the memory no sooner, but also not much later than the life-time of the resource that needs the memory. Many, many function calls and constructors had the pool parameter simply removed (it is no longer the concern of the developer, if you don't write code that actually does an libapr call then you are no longer bothered with memory pools at all). However, I kept the notion of short-lived and long-lived allocations alive (see my remark in the jira here: https://jira.secondlife.com/browse/STORM-864?focusedCommentId=235356&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-235356 which requires that the LLAPRFile API needs to allow the user to specify how long they think a file will stay open. By choosing 'short_lived' as default for the constructor that immediately opens a file, the number of instances where this needs to be specified is drastically reduced however (obviously, any automatic LLAPRFile is short lived). This addresses bug STORM-864. http://jira.secondlife.com/browse/STORM-864 Diffs ----- doc/contributions.txt 422f636c3343 indra/llaudio/llaudioengine_fmod.cpp 422f636c3343 indra/llaudio/llvorbisencode.cpp 422f636c3343 indra/llcharacter/llbvhloader.cpp 422f636c3343 indra/llcharacter/llkeyframemotionparam.cpp 422f636c3343 indra/llcharacter/llstatemachine.cpp 422f636c3343 indra/llcommon/CMakeLists.txt 422f636c3343 indra/llcommon/llapp.cpp 422f636c3343 indra/llcommon/llapr.h 422f636c3343 indra/llcommon/llapr.cpp 422f636c3343 indra/llcommon/llaprpool.h PRE-CREATION indra/llcommon/llaprpool.cpp PRE-CREATION indra/llcommon/llcommon.h 422f636c3343 indra/llcommon/llcommon.cpp 422f636c3343 indra/llcommon/llerror.h 422f636c3343 indra/llcommon/llerror.cpp 422f636c3343 indra/llcommon/llfixedbuffer.cpp 422f636c3343 indra/llcommon/llscopedvolatileaprpool.h PRE-CREATION indra/llcommon/llthread.h 422f636c3343 indra/llcommon/llthread.cpp 422f636c3343 indra/llcommon/llthreadsafequeue.h 422f636c3343 indra/llcommon/llthreadsafequeue.cpp 422f636c3343 indra/llcommon/llworkerthread.h 422f636c3343 indra/llcommon/llworkerthread.cpp 422f636c3343 indra/llcrashlogger/llcrashlogger.cpp 422f636c3343 indra/llimage/llimage.cpp 422f636c3343 indra/llimage/llimagedimensionsinfo.cpp 422f636c3343 indra/llimage/llimagej2c.cpp 422f636c3343 indra/llimage/llimageworker.h 422f636c3343 indra/llimage/llimageworker.cpp 422f636c3343 indra/llmath/llvolumemgr.cpp 422f636c3343 indra/llmessage/llares.cpp 422f636c3343 indra/llmessage/llcurl.cpp 422f636c3343 indra/llmessage/lliohttpserver.h 422f636c3343 indra/llmessage/lliohttpserver.cpp 422f636c3343 indra/llmessage/lliosocket.h 422f636c3343 indra/llmessage/lliosocket.cpp 422f636c3343 indra/llmessage/llmail.h 422f636c3343 indra/llmessage/llmail.cpp 422f636c3343 indra/llmessage/llpumpio.h 422f636c3343 indra/llmessage/llpumpio.cpp 422f636c3343 indra/llmessage/llurlrequest.cpp 422f636c3343 indra/llmessage/message.cpp 422f636c3343 indra/llmessage/tests/networkio.h 422f636c3343 indra/llplugin/llplugininstance.h 422f636c3343 indra/llplugin/llplugininstance.cpp 422f636c3343 indra/llplugin/llpluginmessagepipe.cpp 422f636c3343 indra/llplugin/llpluginprocesschild.cpp 422f636c3343 indra/llplugin/llpluginprocessparent.h 422f636c3343 indra/llplugin/llpluginprocessparent.cpp 422f636c3343 indra/llplugin/llpluginsharedmemory.h 422f636c3343 indra/llplugin/llpluginsharedmemory.cpp 422f636c3343 indra/llplugin/slplugin/slplugin.cpp 422f636c3343 indra/llvfs/lllfsthread.cpp 422f636c3343 indra/llvfs/llvfs.cpp 422f636c3343 indra/media_plugins/gstreamer010/llmediaimplgstreamer.h 422f636c3343 indra/media_plugins/gstreamer010/llmediaimplgstreamer_syms.cpp 422f636c3343 indra/media_plugins/webkit/linux_volume_catcher.cpp 422f636c3343 indra/newview/llappviewer.h 422f636c3343 indra/newview/llappviewer.cpp 422f636c3343 indra/newview/llappviewerlinux.cpp 422f636c3343 indra/newview/llappviewerlinux_api_dbus.cpp 422f636c3343 indra/newview/llappviewermacosx.cpp 422f636c3343 indra/newview/llfloateranimpreview.cpp 422f636c3343 indra/newview/llmainlooprepeater.cpp 422f636c3343 indra/newview/lltexturecache.h 422f636c3343 indra/newview/lltexturecache.cpp 422f636c3343 indra/newview/lltexturefetch.cpp 422f636c3343 indra/newview/llviewermenufile.cpp 422f636c3343 indra/newview/llvoavatar.cpp 422f636c3343 indra/newview/llvocache.h 422f636c3343 indra/newview/llvocache.cpp 422f636c3343 indra/newview/llvoicevivox.cpp 422f636c3343 indra/newview/llwatchdog.cpp 422f636c3343 indra/newview/tests/llworldmap_test.cpp 422f636c3343 indra/test/lltemplatemessagebuilder_tut.cpp 422f636c3343 indra/test/message_tut.cpp 422f636c3343 indra/test/test.cpp 422f636c3343 indra/test_apps/llplugintest/llmediaplugintest.cpp 422f636c3343 indra/viewer_components/updater/llupdateinstaller.cpp 422f636c3343 Diff: http://codereview.secondlife.com/r/99/diff Testing ------- Compiles and viewer functions normally. The new classes (LLAPRPool, LLThreadLocalData) and the LLAPRFile changes have been tested a lot more extensive, since they have been used as-is for months in imprudence and before that in my own viewer (since April). However, the patch contains changes to code elsewhere (to adapt it to the new API) that is rather new in this source tree. Note that changes with regard to LLAPRFile already have been in Snowglobe since version 1.1 (with some minor changes) including the method used to make thread-local data available. Thanks, Aleric -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110118/7467bc1a/attachment-0001.htm From Aleric.Inglewood at gmail.com Mon Jan 17 21:13:41 2011 From: Aleric.Inglewood at gmail.com (Aleric Inglewood) Date: Tue, 18 Jan 2011 05:13:41 -0000 Subject: [opensource-dev] Review Request: VWR-24519: Spawning of the 'spare' media plugin process makes debugging SLPlugin harder Message-ID: <20110118051341.25993.51445@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/96/ ----------------------------------------------------------- Review request for Viewer. Summary ------- This patch stops early spawns of "spare" media plugin processes when the debug setting PluginAttachDebuggerToPlugins is set. The result should be that the terminal with gdb session that pops up when you open a media is the correct one that you intend to debug (instead of an idle one that does nothing; while the process that you want to debug was already spawned an arbitrary amount of time before). This addresses bug VWR-24519. http://jira.secondlife.com/browse/VWR-24519 Diffs ----- indra/newview/llviewermedia.cpp 422f636c3343 Diff: http://codereview.secondlife.com/r/96/diff Testing ------- Thanks, Aleric -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110118/bfc2520e/attachment.htm From sllists at boroon.dasgupta.ch Tue Jan 18 04:30:59 2011 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Tue, 18 Jan 2011 12:30:59 -0000 Subject: [opensource-dev] Review Request: STORM-864: As as developer, I would like an object oriented wrapper to make safe use of memory pools easier In-Reply-To: <20110118030348.26007.5470@domU-12-31-38-00-90-68.compute-1.internal> References: <20110118030348.26007.5470@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110118123059.26332.65096@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/99/#review180 ----------------------------------------------------------- I don't feel really qualified to review this, thus just some minor remarks from me: doc/contributions.txt This sorting of contribution entries is not related the issue at hand and should thus happen in a separate commit, if at all. Current policy is to not re-sort existing entries at all, to not mislead Oz' metric gathering tools. See Oz' comment on https://codereview.secondlife.com/r/78/ and his clarification in this thread: https://lists.secondlife.com/pipermail/opensource-dev/2011-January/thread.html#5329 I guess this policy might change again once the tools have been made more robust. Please postpone re-sorting jira entries until then. indra/llcommon/llaprpool.h I think this comment line is noteworthy enough to show it on doxygen, too. Maybe even within an \attention or \warning . indra/llcommon/llaprpool.h Parameters and their behavior can be documented in doxygen with \param . See http://www.doxygen.nl/commands.html#cmdparam indra/llcommon/llaprpool.h This could be made a doxygen comment. indra/llcommon/llaprpool.h This should probably be a doxygen comment. indra/llcommon/llaprpool.h Why include only the first line in doxygen? indra/llcommon/llscopedvolatileaprpool.h The first "it's" should be "its". indra/llcommon/llscopedvolatileaprpool.h Consider exposing this comment via doxygen. indra/llcommon/llscopedvolatileaprpool.h Another candidate for a \warning or \attention ? indra/llcommon/llthread.h Another candidate for doxygen. \return could be used. indra/llcommon/llthread.h Consider using one line per statement, here. indra/llcommon/llthread.h It looks like the #if MUTEX_DEBUG is almost redundant here. I think it will only have an effect when RELEASE_SHOW_ASSERT is set or SHOW_ASSERT has been manually set. Are you sure you want to suppress this specific assertion in these cases? indra/llcommon/llthread.cpp Worth inlining? - Boroondas On Jan. 17, 2011, 7:03 p.m., Aleric Inglewood wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/99/ > ----------------------------------------------------------- > > (Updated Jan. 17, 2011, 7:03 p.m.) > > > Review request for Viewer. > > > Summary > ------- > > Please see http://jira.secondlife.com/browse/STORM-864 > > I made a mercurial repository available for testing here: > > hg clone https://bitbucket.org/aleric/viewer-development-storm-864 > > From the commit message: > > Introduces a LLThreadLocalData class that can be > accessed through the static LLThread::tldata(). > Currently this object contains two (public) thread-local > objects: a LLAPRRootPool and a LLVolatileAPRPool. > > The first is the general memory pool used by this thread > (and this thread alone), while the second is intended > for short lived memory allocations (needed for APR). > The advantages of not mixing those two is that the latter > is used most frequently, and as a result of it's nature > can be destroyed and reconstructed on a "regular" basis. > > This patch adds LLAPRPool (completely replacing the old one), > which is a wrapper around apr_pool_t* and has complete > thread-safity checking. > > Whenever an apr call requires memory for some resource, > a memory pool in the form of an LLAPRPool object can > be created with the same life-time as this resource; > assuring clean up of the memory no sooner, but also > not much later than the life-time of the resource > that needs the memory. > > Many, many function calls and constructors had the > pool parameter simply removed (it is no longer the > concern of the developer, if you don't write code > that actually does an libapr call then you are no > longer bothered with memory pools at all). > > However, I kept the notion of short-lived and > long-lived allocations alive (see my remark in > the jira here: https://jira.secondlife.com/browse/STORM-864?focusedCommentId=235356&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-235356 > which requires that the LLAPRFile API needs > to allow the user to specify how long they > think a file will stay open. By choosing > 'short_lived' as default for the constructor > that immediately opens a file, the number of > instances where this needs to be specified is > drastically reduced however (obviously, any > automatic LLAPRFile is short lived). > > > This addresses bug STORM-864. > http://jira.secondlife.com/browse/STORM-864 > > > Diffs > ----- > > doc/contributions.txt 422f636c3343 > indra/llaudio/llaudioengine_fmod.cpp 422f636c3343 > indra/llaudio/llvorbisencode.cpp 422f636c3343 > indra/llcharacter/llbvhloader.cpp 422f636c3343 > indra/llcharacter/llkeyframemotionparam.cpp 422f636c3343 > indra/llcharacter/llstatemachine.cpp 422f636c3343 > indra/llcommon/CMakeLists.txt 422f636c3343 > indra/llcommon/llapp.cpp 422f636c3343 > indra/llcommon/llapr.h 422f636c3343 > indra/llcommon/llapr.cpp 422f636c3343 > indra/llcommon/llaprpool.h PRE-CREATION > indra/llcommon/llaprpool.cpp PRE-CREATION > indra/llcommon/llcommon.h 422f636c3343 > indra/llcommon/llcommon.cpp 422f636c3343 > indra/llcommon/llerror.h 422f636c3343 > indra/llcommon/llerror.cpp 422f636c3343 > indra/llcommon/llfixedbuffer.cpp 422f636c3343 > indra/llcommon/llscopedvolatileaprpool.h PRE-CREATION > indra/llcommon/llthread.h 422f636c3343 > indra/llcommon/llthread.cpp 422f636c3343 > indra/llcommon/llthreadsafequeue.h 422f636c3343 > indra/llcommon/llthreadsafequeue.cpp 422f636c3343 > indra/llcommon/llworkerthread.h 422f636c3343 > indra/llcommon/llworkerthread.cpp 422f636c3343 > indra/llcrashlogger/llcrashlogger.cpp 422f636c3343 > indra/llimage/llimage.cpp 422f636c3343 > indra/llimage/llimagedimensionsinfo.cpp 422f636c3343 > indra/llimage/llimagej2c.cpp 422f636c3343 > indra/llimage/llimageworker.h 422f636c3343 > indra/llimage/llimageworker.cpp 422f636c3343 > indra/llmath/llvolumemgr.cpp 422f636c3343 > indra/llmessage/llares.cpp 422f636c3343 > indra/llmessage/llcurl.cpp 422f636c3343 > indra/llmessage/lliohttpserver.h 422f636c3343 > indra/llmessage/lliohttpserver.cpp 422f636c3343 > indra/llmessage/lliosocket.h 422f636c3343 > indra/llmessage/lliosocket.cpp 422f636c3343 > indra/llmessage/llmail.h 422f636c3343 > indra/llmessage/llmail.cpp 422f636c3343 > indra/llmessage/llpumpio.h 422f636c3343 > indra/llmessage/llpumpio.cpp 422f636c3343 > indra/llmessage/llurlrequest.cpp 422f636c3343 > indra/llmessage/message.cpp 422f636c3343 > indra/llmessage/tests/networkio.h 422f636c3343 > indra/llplugin/llplugininstance.h 422f636c3343 > indra/llplugin/llplugininstance.cpp 422f636c3343 > indra/llplugin/llpluginmessagepipe.cpp 422f636c3343 > indra/llplugin/llpluginprocesschild.cpp 422f636c3343 > indra/llplugin/llpluginprocessparent.h 422f636c3343 > indra/llplugin/llpluginprocessparent.cpp 422f636c3343 > indra/llplugin/llpluginsharedmemory.h 422f636c3343 > indra/llplugin/llpluginsharedmemory.cpp 422f636c3343 > indra/llplugin/slplugin/slplugin.cpp 422f636c3343 > indra/llvfs/lllfsthread.cpp 422f636c3343 > indra/llvfs/llvfs.cpp 422f636c3343 > indra/media_plugins/gstreamer010/llmediaimplgstreamer.h 422f636c3343 > indra/media_plugins/gstreamer010/llmediaimplgstreamer_syms.cpp 422f636c3343 > indra/media_plugins/webkit/linux_volume_catcher.cpp 422f636c3343 > indra/newview/llappviewer.h 422f636c3343 > indra/newview/llappviewer.cpp 422f636c3343 > indra/newview/llappviewerlinux.cpp 422f636c3343 > indra/newview/llappviewerlinux_api_dbus.cpp 422f636c3343 > indra/newview/llappviewermacosx.cpp 422f636c3343 > indra/newview/llfloateranimpreview.cpp 422f636c3343 > indra/newview/llmainlooprepeater.cpp 422f636c3343 > indra/newview/lltexturecache.h 422f636c3343 > indra/newview/lltexturecache.cpp 422f636c3343 > indra/newview/lltexturefetch.cpp 422f636c3343 > indra/newview/llviewermenufile.cpp 422f636c3343 > indra/newview/llvoavatar.cpp 422f636c3343 > indra/newview/llvocache.h 422f636c3343 > indra/newview/llvocache.cpp 422f636c3343 > indra/newview/llvoicevivox.cpp 422f636c3343 > indra/newview/llwatchdog.cpp 422f636c3343 > indra/newview/tests/llworldmap_test.cpp 422f636c3343 > indra/test/lltemplatemessagebuilder_tut.cpp 422f636c3343 > indra/test/message_tut.cpp 422f636c3343 > indra/test/test.cpp 422f636c3343 > indra/test_apps/llplugintest/llmediaplugintest.cpp 422f636c3343 > indra/viewer_components/updater/llupdateinstaller.cpp 422f636c3343 > > Diff: http://codereview.secondlife.com/r/99/diff > > > Testing > ------- > > Compiles and viewer functions normally. > > The new classes (LLAPRPool, LLThreadLocalData) and the LLAPRFile changes have been tested a lot more extensive, since they have been used as-is for months in imprudence and before that in my own viewer (since April). However, the patch contains changes to code elsewhere (to adapt it to the new API) that is rather new in this source tree. Note that changes with regard to LLAPRFile already have been in Snowglobe since version 1.1 (with some minor changes) including the method used to make thread-local data available. > > > Thanks, > > Aleric > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110118/54d9105b/attachment-0001.htm From vsavchuk at productengine.com Tue Jan 18 06:31:11 2011 From: vsavchuk at productengine.com (Vadim ProductEngine) Date: Tue, 18 Jan 2011 14:31:11 -0000 Subject: [opensource-dev] Review Request: STORM-2 As a User, I want to set my own default views with specific UI layout so I can tailor my Viewer experience to the activities I'm most interested in. In-Reply-To: <20110117212408.25763.20611@domU-12-31-38-00-90-68.compute-1.internal> References: <20110117212408.25763.20611@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110118143111.25993.91253@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/98/#review181 ----------------------------------------------------------- Ship it! Looks good, given that this is a first pass implementation. - Vadim On Jan. 17, 2011, 1:24 p.m., Andrew ProductEngine wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/98/ > ----------------------------------------------------------- > > (Updated Jan. 17, 2011, 1:24 p.m.) > > > Review request for Viewer. > > > Summary > ------- > > First pass of saving of UI state into files. > > Implemeted saving of floaters and bottombar buttons state into a named layout. This layout is saved on disk into per-user folder. The folder with layout contains LLSD files. > > Currently the following features were implemeted: > - Saving of bottomtray buttons order and visibility. > - Saving floaters rect and visibility info (multiple instances of the same floater are supported) > - Saving of sidetray tabs state (docked/undocked). > - UI for the feature. > > TODO: > - Add saving dock state for dockable floaters. > - Add LL-created default layouts and support for them. > - Refactor system of updating lists - get rid of ugly static dirty and it's check in draw. > - Add saving of sidetray open/closed state, open tab, etc. > > > This addresses bug STORM-2. > http://jira.secondlife.com/browse/STORM-2 > > > Diffs > ----- > > indra/llui/llfloater.h 422f636c3343 > indra/llui/llfloaterreg.h 422f636c3343 > indra/newview/CMakeLists.txt 422f636c3343 > indra/newview/llbottomtray.h 422f636c3343 > indra/newview/llbottomtray.cpp 422f636c3343 > indra/newview/llfloaterlayouts.h PRE-CREATION > indra/newview/llfloaterlayouts.cpp PRE-CREATION > indra/newview/llsidetray.h 422f636c3343 > indra/newview/llsidetray.cpp 422f636c3343 > indra/newview/llviewerfloaterreg.cpp 422f636c3343 > indra/newview/llviewermenu.cpp 422f636c3343 > indra/newview/skins/default/xui/en/floater_layouts.xml PRE-CREATION > indra/newview/skins/default/xui/en/floater_save_layout.xml PRE-CREATION > indra/newview/skins/default/xui/en/menu_viewer.xml 422f636c3343 > indra/newview/skins/default/xui/en/notifications.xml 422f636c3343 > > Diff: http://codereview.secondlife.com/r/98/diff > > > Testing > ------- > > > Thanks, > > Andrew > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110118/ea5e4514/attachment.htm From q at lindenlab.com Tue Jan 18 07:22:45 2011 From: q at lindenlab.com (Kent Quirk (Q Linden)) Date: Tue, 18 Jan 2011 10:22:45 -0500 Subject: [opensource-dev] STORM-243 - simulator version notifications Message-ID: <5941ED4A-7D5D-4008-9FC9-A68B33EF2A44@lindenlab.com> Hi, folks. I've just commented on STORM-243, which requests that we have Yet Another Option to allow suppression of the toast that tells you the simulator version changed when you changed to a new region. I think we should delete it entirely. Does anyone care to still get that notification, now that there are usually 3 different simulator versions live on the grid at any time? I don't mean "I can think of an obscure scenario when someone might care." I mean does anyone really need a notification about this, or can we just delete it? From Lance.Corrimal at eregion.de Tue Jan 18 07:28:21 2011 From: Lance.Corrimal at eregion.de (Lance Corrimal) Date: Tue, 18 Jan 2011 16:28:21 +0100 Subject: [opensource-dev] STORM-243 - simulator version notifications In-Reply-To: <5941ED4A-7D5D-4008-9FC9-A68B33EF2A44@lindenlab.com> References: <5941ED4A-7D5D-4008-9FC9-A68B33EF2A44@lindenlab.com> Message-ID: <201101181628.21597.Lance.Corrimal@eregion.de> Am Dienstag, 18. Januar 2011, 16:22:45 schrieb Kent Quirk (Q Linden): > Hi, folks. I've just commented on STORM-243, which requests that we have > Yet Another Option to allow suppression of the toast that tells you the > simulator version changed when you changed to a new region. > > I think we should delete it entirely. Does anyone care to still get that > notification, now that there are usually 3 different simulator versions > live on the grid at any time? I don't mean "I can think of an obscure > scenario when someone might care." I mean does anyone really need a > notification about this, or can we just delete it? on the contrary, i'm trying to port a patch from henri beauchamps cool viewer that makes that notification more detailed, as in it tells you the version of the sim you entered and the version of the sim you left. bye, LC From opensourceobscure at gmail.com Tue Jan 18 07:28:47 2011 From: opensourceobscure at gmail.com (Opensource Obscure) Date: Tue, 18 Jan 2011 16:28:47 +0100 Subject: [opensource-dev] Review Request: STORM-2 As a User, I want to set my own default views with specific UI layout so I can tailor my Viewer experience to the activities I'm most interested in. In-Reply-To: <20110118143111.25993.91253@domU-12-31-38-00-90-68.compute-1.internal> References: <20110117212408.25763.20611@domU-12-31-38-00-90-68.compute-1.internal> <20110118143111.25993.91253@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: Just to say this new feature looks very promising! A question. The 3rd note says "the files associated with saved layouts will be LLSD text files, so you can email or paste layouts into a notecard to share with other users". (the note also explains why this is not the ideal behaviour ever, and also why we have to deal with it for now) This sounds even cooler! ...but - how would that process of sharing LLSD files exactly work? I mean, where will users have to put those LLSD files? here is the scenario I'm thinking about: - a "teacher" (or mentor, friend, etc) is explaining to a new user how to build in SL - the teacher shares with the new user an LLSD file that contains an ideal layout for building, and says "put this in your SL folder" - the new user is now confused: many newbies don't know the difference between the software folder and the settings folder, and they don't know where those are; this gets even worst to solve for people trying to help them, because pathnames are different across different operating systems, across different releases of the same o.s. - or because of localization. possible solutions: - add another option in Preferences to choose the folder where we keep layouts - add a menu command to choose a specific layout file - then the viewer would copy that file into the actual settings folder. Opensource Obscure From sllists at boroon.dasgupta.ch Tue Jan 18 07:29:44 2011 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Tue, 18 Jan 2011 15:29:44 -0000 Subject: [opensource-dev] Review Request: make PREHASH variables char const* const Message-ID: <20110118152944.26007.14045@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/100/ ----------------------------------------------------------- Review request for Viewer. Summary ------- For the reason for this change, see https://jira.secondlife.com/browse/VWR-24487 and https://jira.secondlife.com/browse/VWR-24522 What I did: In indra/llmessage/message_prehash.(h|cpp), I turned everything into constant pointers to constants by search/replace. Then I tried to compile and added const qualifiers in dependent code as needed to stop the compiler complaining. Note that comments in indra/llmessage/message_prehash.(h|cpp) say these files have been generated from the message template. If this generation wasn't a one-off thing, the generating code must be changed, too, so it won't override this change here when the generation happens the next time. This addresses bug VWR-24487. http://jira.secondlife.com/browse/VWR-24487 Diffs ----- doc/contributions.txt fc7e5dcf3059 indra/llmessage/message_prehash.h fc7e5dcf3059 indra/llmessage/message_prehash.cpp fc7e5dcf3059 indra/llprimitive/llprimitive.h fc7e5dcf3059 indra/llprimitive/llprimitive.cpp fc7e5dcf3059 indra/llprimitive/llvolumemessage.h fc7e5dcf3059 indra/llprimitive/llvolumemessage.cpp fc7e5dcf3059 indra/llui/tests/llurlentry_stub.cpp fc7e5dcf3059 indra/newview/tests/llremoteparcelrequest_test.cpp fc7e5dcf3059 Diff: http://codereview.secondlife.com/r/100/diff Testing ------- Compiled (standalone, 64bit Linux) with and without LL_TESTS. Started the viewer, logged in, walked and flew around a bit. Everything seems to work. Thanks, Boroondas -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110118/f2a2a883/attachment.htm From wolfpup67 at earthlink.net Tue Jan 18 07:30:52 2011 From: wolfpup67 at earthlink.net (WolfPup Lowenhar) Date: Tue, 18 Jan 2011 10:30:52 -0500 Subject: [opensource-dev] STORM-243 - simulator version notifications In-Reply-To: <5941ED4A-7D5D-4008-9FC9-A68B33EF2A44@lindenlab.com> References: <5941ED4A-7D5D-4008-9FC9-A68B33EF2A44@lindenlab.com> Message-ID: <000f01cbb724$b13cd250$13b676f0$@net> Q, I believe the jira in question was wanting to suppress the popup but not the notification itself so that it would still show up in chat history if you were logging it or kept your chat history open all the time. From: opensource-dev-bounces at lists.secondlife.com [mailto:opensource-dev-bounces at lists.secondlife.com] On Behalf Of Kent Quirk (Q Linden) Sent: Tuesday, January 18, 2011 10:23 AM To: OpenSource Mailing List Subject: [opensource-dev] STORM-243 - simulator version notifications Hi, folks. I've just commented on STORM-243, which requests that we have Yet Another Option to allow suppression of the toast that tells you the simulator version changed when you changed to a new region. I think we should delete it entirely. Does anyone care to still get that notification, now that there are usually 3 different simulator versions live on the grid at any time? I don't mean "I can think of an obscure scenario when someone might care." I mean does anyone really need a notification about this, or can we just delete it? _______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges _____ No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1191 / Virus Database: 1435/3387 - Release Date: 01/17/11 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110118/3fc61156/attachment-0001.htm From opensourceobscure at gmail.com Tue Jan 18 07:40:42 2011 From: opensourceobscure at gmail.com (Opensource Obscure) Date: Tue, 18 Jan 2011 16:40:42 +0100 Subject: [opensource-dev] STORM-243 - simulator version notifications In-Reply-To: <5941ED4A-7D5D-4008-9FC9-A68B33EF2A44@lindenlab.com> References: <5941ED4A-7D5D-4008-9FC9-A68B33EF2A44@lindenlab.com> Message-ID: I guess most people on this list are personally interested in that notification. Still, I think we're a very non-representative sample of the whole SL userbase - especially with regards to tech details. Off by default, with freedom to choose would be the best; a Debug Setting would probably be good enough (since interested people are "techie" enough to know how to get there); should I choose between yes/no I would say "no" - remove them as most SL users aren't interested in that information and/or don't know what it means. IMO Opensource Obscure On Tue, Jan 18, 2011 at 16:22, Kent Quirk (Q Linden) wrote: > Hi, folks. I've just commented on STORM-243, which requests that we have Yet Another Option to allow suppression of the toast that tells you the simulator version changed when you changed to a new region. > > I think we should delete it entirely. Does anyone care to still get that notification, now that there are usually 3 different simulator versions live on the grid at any time? I don't mean "I can think of an obscure scenario when someone might care." I mean does anyone really need a notification about this, or can we just delete it? > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting privileges > From q at lindenlab.com Tue Jan 18 07:59:29 2011 From: q at lindenlab.com (Kent Quirk (Q Linden)) Date: Tue, 18 Jan 2011 10:59:29 -0500 Subject: [opensource-dev] STORM-243 - simulator version notifications In-Reply-To: <201101181628.21597.Lance.Corrimal@eregion.de> References: <5941ED4A-7D5D-4008-9FC9-A68B33EF2A44@lindenlab.com> <201101181628.21597.Lance.Corrimal@eregion.de> Message-ID: <9CA50354-52CF-4363-83B4-902846CFE1F3@lindenlab.com> Can you please explain why you care? Is there a reason why you want a notification? On Jan 18, 2011, at 10:28 AM, Lance Corrimal wrote: > Am Dienstag, 18. Januar 2011, 16:22:45 schrieb Kent Quirk (Q Linden): >> Hi, folks. I've just commented on STORM-243, which requests that we have >> Yet Another Option to allow suppression of the toast that tells you the >> simulator version changed when you changed to a new region. >> >> I think we should delete it entirely. Does anyone care to still get that >> notification, now that there are usually 3 different simulator versions >> live on the grid at any time? I don't mean "I can think of an obscure >> scenario when someone might care." I mean does anyone really need a >> notification about this, or can we just delete it? > > > on the contrary, i'm trying to port a patch from henri beauchamps cool viewer > that makes that notification more detailed, as in it tells you the version of > the sim you entered and the version of the sim you left. > > > 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 q at lindenlab.com Tue Jan 18 08:00:23 2011 From: q at lindenlab.com (Kent Quirk (Q Linden)) Date: Tue, 18 Jan 2011 11:00:23 -0500 Subject: [opensource-dev] STORM-243 - simulator version notifications In-Reply-To: References: <5941ED4A-7D5D-4008-9FC9-A68B33EF2A44@lindenlab.com> Message-ID: Everyone wants more options. Why should this be an option? Just because you're interested in knowing the version number, do you really need a notification of it? What does that give you that checking About Second Life doesn't give you? On Jan 18, 2011, at 10:40 AM, Opensource Obscure wrote: > I guess most people on this list are personally interested in that > notification. Still, I think we're a very non-representative sample > of the whole SL userbase - especially with regards to tech details. > > Off by default, with freedom to choose would be the best; > a Debug Setting would probably be good enough (since interested > people are "techie" enough to know how to get there); > should I choose between yes/no I would say "no" - remove them as > most SL users aren't interested in that information and/or don't know > what it means. > IMO > > Opensource Obscure > > On Tue, Jan 18, 2011 at 16:22, Kent Quirk (Q Linden) wrote: >> Hi, folks. I've just commented on STORM-243, which requests that we have Yet Another Option to allow suppression of the toast that tells you the simulator version changed when you changed to a new region. >> >> I think we should delete it entirely. Does anyone care to still get that notification, now that there are usually 3 different simulator versions live on the grid at any time? I don't mean "I can think of an obscure scenario when someone might care." I mean does anyone really need a notification about this, or can we just delete it? >> >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/OpenSource-Dev >> Please read the policies before posting to keep unmoderated posting privileges >> From stickman at gmail.com Tue Jan 18 08:01:35 2011 From: stickman at gmail.com (Stickman) Date: Tue, 18 Jan 2011 08:01:35 -0800 Subject: [opensource-dev] STORM-243 - simulator version notifications In-Reply-To: <201101181628.21597.Lance.Corrimal@eregion.de> References: <5941ED4A-7D5D-4008-9FC9-A68B33EF2A44@lindenlab.com> <201101181628.21597.Lance.Corrimal@eregion.de> Message-ID: > on the contrary, i'm trying to port a patch from henri beauchamps cool viewer > that makes that notification more detailed, as in it tells you the version of > the sim you entered and the version of the sim you left. As Lance said, the notice as it is right now isn't very useful. If it actually had more information, such as maybe the version you were at and the version you're going to and allows you to click it to get to the release notes, it would be significantly useful. In its current state, it's possibly confusing/annoying to the standard user, and not useful enough to the technical user. That wasn't your question, though. If it's not going to become more useful, I'd be up for deleting it. If I'm curious about versions, I'd go check it manually anyway. I have to already, since it doesn't tell me. Switching argument gears, I've often had the idea of SL having two clients, the standard user and the technical developer. Unfortunately, this is an extremely limited view, as there is a huge range of users. The "modular client" idea that went through the list a while back, where LL makes a core system with some default modules and everyone can make whatever addons they wanted, seemed like a really good idea that allows for these "two clients" and everything inbetween. It would also let people contribute by just making a quick little module rather than a full client. But that's a different topic. What's LL's direction for SL, anyway? Do they want to cater to the technical developer? The artistic developer? The window-shopping user? Socially inclined chatters? Sight seers? Besides bringing things up to current technology, it's hard to see where LL's trying to go, and that makes it hard to suggest things that would be more useful. Stickman From tateru at taterunino.net Tue Jan 18 08:02:19 2011 From: tateru at taterunino.net (Tateru Nino) Date: Wed, 19 Jan 2011 03:02:19 +1100 Subject: [opensource-dev] STORM-243 - simulator version notifications In-Reply-To: <5941ED4A-7D5D-4008-9FC9-A68B33EF2A44@lindenlab.com> References: <5941ED4A-7D5D-4008-9FC9-A68B33EF2A44@lindenlab.com> Message-ID: <4D35B98B.3070605@taterunino.net> Speaking as an unrepresentative sample of... err... one, I find the popup very useful - but *only* in certain defined periods where I am intending that it be an important part of what I'm doing (and it sometimes is). At that point, I *would* like more detail (exactly what version am I arriving in and what version have I arrived from). The rest of the time - being 99.5% of the time, I'd prefer it to default to off, and not see the popup at all. On 19/01/2011 2:22 AM, Kent Quirk (Q Linden) wrote: > Hi, folks. I've just commented on STORM-243, which requests that we have Yet Another Option to allow suppression of the toast that tells you the simulator version changed when you changed to a new region. > > I think we should delete it entirely. Does anyone care to still get that notification, now that there are usually 3 different simulator versions live on the grid at any time? I don't mean "I can think of an obscure scenario when someone might care." I mean does anyone really need a notification about this, or can we just delete it? > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting privileges > -- Tateru Nino http://dwellonit.taterunino.net/ From tateru.nino at gmail.com Tue Jan 18 08:13:29 2011 From: tateru.nino at gmail.com (Tateru Nino) Date: Wed, 19 Jan 2011 03:13:29 +1100 Subject: [opensource-dev] STORM-243 - simulator version notifications In-Reply-To: References: <5941ED4A-7D5D-4008-9FC9-A68B33EF2A44@lindenlab.com> Message-ID: <4D35BC29.80200@gmail.com> Well, connect up the network message system with a small plugin stub in python or something, expose the popup API to it, and I'm sure we can each decide for ourselves what events and messages should and shouldn't generate popups and under what circumstances. Then, perhaps, we could expose a few more APIs like chat/chat-history - as an example. On 19/01/2011 3:00 AM, Kent Quirk (Q Linden) wrote: > Everyone wants more options. Why should this be an option? > > Just because you're interested in knowing the version number, do you really need a notification of it? What does that give you that checking About Second Life doesn't give you? > > On Jan 18, 2011, at 10:40 AM, Opensource Obscure wrote: > >> I guess most people on this list are personally interested in that >> notification. Still, I think we're a very non-representative sample >> of the whole SL userbase - especially with regards to tech details. >> >> Off by default, with freedom to choose would be the best; >> a Debug Setting would probably be good enough (since interested >> people are "techie" enough to know how to get there); >> should I choose between yes/no I would say "no" - remove them as >> most SL users aren't interested in that information and/or don't know >> what it means. >> IMO >> >> Opensource Obscure >> >> On Tue, Jan 18, 2011 at 16:22, Kent Quirk (Q Linden) wrote: >>> Hi, folks. I've just commented on STORM-243, which requests that we have Yet Another Option to allow suppression of the toast that tells you the simulator version changed when you changed to a new region. >>> >>> I think we should delete it entirely. Does anyone care to still get that notification, now that there are usually 3 different simulator versions live on the grid at any time? I don't mean "I can think of an obscure scenario when someone might care." I mean does anyone really need a notification about this, or can we just delete it? >>> >>> _______________________________________________ >>> Policies and (un)subscribe information available here: >>> http://wiki.secondlife.com/wiki/OpenSource-Dev >>> Please read the policies before posting to keep unmoderated posting privileges >>> > _______________________________________________ > Policies 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/ From vsavchuk at productengine.com Tue Jan 18 08:20:36 2011 From: vsavchuk at productengine.com (Vadim ProductEngine) Date: Tue, 18 Jan 2011 16:20:36 -0000 Subject: [opensource-dev] Review Request: STORM-373 "Rename" context menu option disabled for incomplete inventory items Message-ID: <20110118162036.26007.12085@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/101/ ----------------------------------------------------------- Review request for Viewer. Summary ------- Refresh the inventory context menu (which enables the "Rename" option) after the selected item(s) gets fetched. I'm a bit worried by adding another inventory observer to each inventory panel, but I couldn't come up with a solution which is more elegant and affects performance less. This addresses bug STORM-373. http://jira.secondlife.com/browse/STORM-373 Diffs ----- indra/newview/llfolderview.h 422f636c3343 indra/newview/llfolderview.cpp 422f636c3343 indra/newview/llinventorypanel.h 422f636c3343 indra/newview/llinventorypanel.cpp 422f636c3343 Diff: http://codereview.secondlife.com/r/101/diff Testing ------- Thanks, Vadim -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110118/4bde50b6/attachment.htm From Lance.Corrimal at eregion.de Tue Jan 18 08:34:12 2011 From: Lance.Corrimal at eregion.de (Lance Corrimal) Date: Tue, 18 Jan 2011 17:34:12 +0100 Subject: [opensource-dev] STORM-243 - simulator version notifications In-Reply-To: References: <5941ED4A-7D5D-4008-9FC9-A68B33EF2A44@lindenlab.com> <201101181628.21597.Lance.Corrimal@eregion.de> Message-ID: <201101181734.12359.Lance.Corrimal@eregion.de> Am Dienstag, 18. Januar 2011 schrieb Stickman: > > on the contrary, i'm trying to port a patch from henri beauchamps > > cool viewer that makes that notification more detailed, as in it > > tells you the version of the sim you entered and the version of > > the sim you left. > > As Lance said, the notice as it is right now isn't very useful. > > If it actually had more information, such as maybe the version you > were at and the version you're going to and allows you to click it > to get to the release notes, it would be significantly useful. that is what henri's version does. bye, LC From missannotoole at yahoo.com Tue Jan 18 08:35:01 2011 From: missannotoole at yahoo.com (Ann Otoole) Date: Tue, 18 Jan 2011 08:35:01 -0800 (PST) Subject: [opensource-dev] STORM-243 - simulator version notifications In-Reply-To: <5941ED4A-7D5D-4008-9FC9-A68B33EF2A44@lindenlab.com> References: <5941ED4A-7D5D-4008-9FC9-A68B33EF2A44@lindenlab.com> Message-ID: <226473.53614.qm@web120517.mail.ne1.yahoo.com> Doesn't it add some minor overhead to region crossings? I don't care about it. The message does not say what server version you just entered so it is mostly an annoyance. If I need version info I know where it is. What I would like to see is region rating and a single letter server version code on the map without having to mouse float. ________________________________ From: Kent Quirk (Q Linden) Hi, folks. I've just commented on STORM-243, which requests that we have Yet Another Option to allow suppression of the toast that tells you the simulator version changed when you changed to a new region. I think we should delete it entirely. Does anyone care to still get that notification, now that there are usually 3 different simulator versions live on the grid at any time? I don't mean "I can think of an obscure scenario when someone might care." I mean does anyone really need a notification about this, or can we just delete it? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110118/f44f77a3/attachment.htm From q at lindenlab.com Tue Jan 18 08:42:25 2011 From: q at lindenlab.com (Kent Quirk) Date: Tue, 18 Jan 2011 16:42:25 -0000 Subject: [opensource-dev] Review Request: VWR-24100 Settings.xml: redundant entries and unnecessary tag In-Reply-To: <20101223201240.7867.22247@domU-12-31-38-00-90-68.compute-1.internal> References: <20101223201240.7867.22247@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110118164225.25993.62173@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/18/#review182 ----------------------------------------------------------- Ship it! These changes are all reasonable. Please go ahead. - Kent On Dec. 23, 2010, 12:12 p.m., Jonathan Yap wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/18/ > ----------------------------------------------------------- > > (Updated Dec. 23, 2010, 12:12 p.m.) > > > Review request for Viewer. > > > Summary > ------- > > I wrote two programs that use settings.xml to produce this massive table: > http://wiki.secondlife.com/wiki/Debug_Settings > > While doing this I found 4 places with duplicate entries and 1 entry that is repeated 4 times. There is also a pair of unnecessary tags. > > Having these cleaned out would make running my program, and thus updating the wiki table, easier. > > I've erased all but the last entry for these redundant debug settings. > > > This addresses bug vwr-24100. > http://jira.secondlife.com/browse/vwr-24100 > > > Diffs > ----- > > indra/newview/app_settings/settings.xml 46a990f8296f > > Diff: http://codereview.secondlife.com/r/18/diff > > > Testing > ------- > > > Thanks, > > Jonathan > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110118/b9383b80/attachment.htm From lenglish5 at cox.net Tue Jan 18 09:01:16 2011 From: lenglish5 at cox.net (Lawson English) Date: Tue, 18 Jan 2011 10:01:16 -0700 Subject: [opensource-dev] Mmeting today... was: Re: AW Groupies meeting tomorrow on mesh asset interop format In-Reply-To: <4D349E53.7040104@cox.net> References: <4D349E53.7040104@cox.net> Message-ID: <4D35C75C.5090201@cox.net> Today's AWG meeting at 9:30 AM pacific coast time will be streamed live to: http://www.metanomics.net/community_forum topic will be an open file format for mesh distribution between various virtual worlds From vsavchuk at productengine.com Tue Jan 18 09:02:33 2011 From: vsavchuk at productengine.com (Vadim ProductEngine) Date: Tue, 18 Jan 2011 17:02:33 -0000 Subject: [opensource-dev] Review Request: STORM-243 Suppress version change message in the viewer Message-ID: <20110118170233.25766.11850@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/109/ ----------------------------------------------------------- Review request for Viewer. Summary ------- Removed the "You just entered a region using a different server version..." pop-up notification. This addresses bug STORM-243. http://jira.secondlife.com/browse/STORM-243 Diffs ----- indra/newview/app_settings/settings.xml 422f636c3343 indra/newview/llviewermessage.cpp 422f636c3343 indra/newview/skins/default/xui/da/notifications.xml 422f636c3343 indra/newview/skins/default/xui/de/notifications.xml 422f636c3343 indra/newview/skins/default/xui/en/notifications.xml 422f636c3343 indra/newview/skins/default/xui/es/notifications.xml 422f636c3343 indra/newview/skins/default/xui/fr/notifications.xml 422f636c3343 indra/newview/skins/default/xui/it/notifications.xml 422f636c3343 indra/newview/skins/default/xui/ja/notifications.xml 422f636c3343 indra/newview/skins/default/xui/nl/notifications.xml 422f636c3343 indra/newview/skins/default/xui/pl/notifications.xml 422f636c3343 indra/newview/skins/default/xui/pt/notifications.xml 422f636c3343 Diff: http://codereview.secondlife.com/r/109/diff Testing ------- Thanks, Vadim -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110118/bc9644ed/attachment.htm From oz at lindenlab.com Tue Jan 18 09:02:38 2011 From: oz at lindenlab.com (Oz Linden) Date: Tue, 18 Jan 2011 17:02:38 -0000 Subject: [opensource-dev] Review Request: DN-202: More aggressive caching of display names Message-ID: <20110118170238.25765.26076@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/104/ ----------------------------------------------------------- Review request for Viewer. Summary ------- Changes the caching of avatar display names and other information from the People API to be more aggressive. The expiration time (which is derived from the cache controls of the HTTP responses), is now treated primarily as a maximum time before which the name information should be refreshed. When the ::get method is called on an entry older than its expiration time, an attempt is made to refresh the entry; if that attempt returns a failure, the cached entry is returned anyway. In the event of error returns from the People API when there is no cached entry, the legacy name system is queried to create temporary results; these are never cached in the LLAvatarNameCache. This applies both to HTTP request errors and to names that the PeopleAPI explicitly returns as error responses (the latter were the ones that previously created "???" temporary names - these are never created within the viewer now). The only time that entries are actually removed from the cache is a check made immediately after loading and every 20 minutes (MAX_UNREFRESHED_TIME) thereafter: entries whose expiration time is more than 20 minutes in the past are deleted. Also added extensive logging, mostly at DEBUG level, under the "AvNameCache" tag. This addresses bug dn-202. http://jira.secondlife.com/browse/dn-202 Diffs ----- indra/llcommon/llavatarname.h 422f636c3343 indra/llcommon/llavatarname.cpp 422f636c3343 indra/llmessage/llavatarnamecache.h 422f636c3343 indra/llmessage/llavatarnamecache.cpp 422f636c3343 indra/newview/llappviewer.cpp 422f636c3343 indra/newview/llimview.cpp 422f636c3343 Diff: http://codereview.secondlife.com/r/104/diff Testing ------- Hung out in busy welcome areas to get lots of name requests. Confirmed that refresh behavior was correct, and observed a number of HTTP error returns (both 499 Timeout, the most common, and 404 Not Found) from the People API. Saw that the fallback was correct (many examples of both falling back to a previously cached display name and to the legacy name when no cache was available). All of these were then correctly refreshed (the next attempt was almost always successful). Observed only a couple of cases of the People API returning unresolved names (the case that previously lead to "???" being used). The behavior was correct, but some more testing on a development grid where this error is forced may be a good idea. Moved to a nice quiet empty region, and observed that the cache cleaning occurred correctly after 20 minutes. Confirmed that cached values were saved and reloaded correctly. Thanks, Oz -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110118/9697caa5/attachment-0001.htm From angel_of_crimson at hotmail.com Tue Jan 18 09:04:09 2011 From: angel_of_crimson at hotmail.com (Erin Mallory) Date: Tue, 18 Jan 2011 12:04:09 -0500 Subject: [opensource-dev] STORM-243 - simulator version notifications In-Reply-To: <226473.53614.qm@web120517.mail.ne1.yahoo.com> References: <5941ED4A-7D5D-4008-9FC9-A68B33EF2A44@lindenlab.com>, <226473.53614.qm@web120517.mail.ne1.yahoo.com> Message-ID: I would also like to see the toast moved. it can be useful and would be more useful if it had the actual version. but i would like to see it on the chat history instead. in fact... it would be nice to have an option to have ALL remaining system notifications be optionally shown in chat history instead of as toasts. for one thing it would log better i think, for another... well toasts bother a rather significant portion of sl. those with some forms of epilepsy, migraines, some forms of add... to name a few... Erin/aka Cummere Date: Tue, 18 Jan 2011 08:35:01 -0800 From: missannotoole at yahoo.com To: q at lindenlab.com; opensource-dev at lists.secondlife.com Subject: Re: [opensource-dev] STORM-243 - simulator version notifications Doesn't it add some minor overhead to region crossings? I don't care about it. The message does not say what server version you just entered so it is mostly an annoyance. If I need version info I know where it is. What I would like to see is region rating and a single letter server version code on the map without having to mouse float. From: Kent Quirk (Q Linden) Hi, folks. I've just commented on STORM-243, which requests that we have Yet Another Option to allow suppression of the toast that tells you the simulator version changed when you changed to a new region. I think we should delete it entirely. Does anyone care to still get that notification, now that there are usually 3 different simulator versions live on the grid at any time? I don't mean "I can think of an obscure scenario when someone might care." I mean does anyone really need a notification about this, or can we just delete it? _______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110118/f21ce95f/attachment.htm From wolfpup67 at earthlink.net Tue Jan 18 09:28:05 2011 From: wolfpup67 at earthlink.net (Wolfpup Lowenhar) Date: Tue, 18 Jan 2011 17:28:05 -0000 Subject: [opensource-dev] Review Request: STORM-243 Suppress version change message in the viewer In-Reply-To: <20110118170233.25766.11850@domU-12-31-38-00-90-68.compute-1.internal> References: <20110118170233.25766.11850@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110118172805.25760.10816@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/109/#review183 ----------------------------------------------------------- Looks good to me since this is the removal of the Pop-up message and not total removal of the message that I can see, so message should be in chat history. - Wolfpup On Jan. 18, 2011, 9:02 a.m., Vadim ProductEngine wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/109/ > ----------------------------------------------------------- > > (Updated Jan. 18, 2011, 9:02 a.m.) > > > Review request for Viewer. > > > Summary > ------- > > Removed the "You just entered a region using a different server version..." pop-up notification. > > > This addresses bug STORM-243. > http://jira.secondlife.com/browse/STORM-243 > > > Diffs > ----- > > indra/newview/app_settings/settings.xml 422f636c3343 > indra/newview/llviewermessage.cpp 422f636c3343 > indra/newview/skins/default/xui/da/notifications.xml 422f636c3343 > indra/newview/skins/default/xui/de/notifications.xml 422f636c3343 > indra/newview/skins/default/xui/en/notifications.xml 422f636c3343 > indra/newview/skins/default/xui/es/notifications.xml 422f636c3343 > indra/newview/skins/default/xui/fr/notifications.xml 422f636c3343 > indra/newview/skins/default/xui/it/notifications.xml 422f636c3343 > indra/newview/skins/default/xui/ja/notifications.xml 422f636c3343 > indra/newview/skins/default/xui/nl/notifications.xml 422f636c3343 > indra/newview/skins/default/xui/pl/notifications.xml 422f636c3343 > indra/newview/skins/default/xui/pt/notifications.xml 422f636c3343 > > Diff: http://codereview.secondlife.com/r/109/diff > > > Testing > ------- > > > Thanks, > > Vadim > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110118/96017e1a/attachment.htm From vsavchuk at productengine.com Tue Jan 18 09:38:06 2011 From: vsavchuk at productengine.com (Vadim ProductEngine) Date: Tue, 18 Jan 2011 17:38:06 -0000 Subject: [opensource-dev] Review Request: STORM-243 Suppress version change message in the viewer In-Reply-To: <20110118172805.25760.10816@domU-12-31-38-00-90-68.compute-1.internal> References: <20110118172805.25760.10816@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110118173806.26332.18205@domU-12-31-38-00-90-68.compute-1.internal> > On Jan. 18, 2011, 9:28 a.m., Wolfpup Lowenhar wrote: > > Looks good to me since this is the removal of the Pop-up message and not total removal of the message that I can see, so message should be in chat history. This change drops adding the chat history entry as well. - Vadim ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/109/#review183 ----------------------------------------------------------- On Jan. 18, 2011, 9:02 a.m., Vadim ProductEngine wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/109/ > ----------------------------------------------------------- > > (Updated Jan. 18, 2011, 9:02 a.m.) > > > Review request for Viewer. > > > Summary > ------- > > Removed the "You just entered a region using a different server version..." pop-up notification. > > > This addresses bug STORM-243. > http://jira.secondlife.com/browse/STORM-243 > > > Diffs > ----- > > indra/newview/app_settings/settings.xml 422f636c3343 > indra/newview/llviewermessage.cpp 422f636c3343 > indra/newview/skins/default/xui/da/notifications.xml 422f636c3343 > indra/newview/skins/default/xui/de/notifications.xml 422f636c3343 > indra/newview/skins/default/xui/en/notifications.xml 422f636c3343 > indra/newview/skins/default/xui/es/notifications.xml 422f636c3343 > indra/newview/skins/default/xui/fr/notifications.xml 422f636c3343 > indra/newview/skins/default/xui/it/notifications.xml 422f636c3343 > indra/newview/skins/default/xui/ja/notifications.xml 422f636c3343 > indra/newview/skins/default/xui/nl/notifications.xml 422f636c3343 > indra/newview/skins/default/xui/pl/notifications.xml 422f636c3343 > indra/newview/skins/default/xui/pt/notifications.xml 422f636c3343 > > Diff: http://codereview.secondlife.com/r/109/diff > > > Testing > ------- > > > Thanks, > > Vadim > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110118/d9cf5e90/attachment.htm From merov at lindenlab.com Tue Jan 18 11:11:49 2011 From: merov at lindenlab.com (Merov Linden) Date: Tue, 18 Jan 2011 19:11:49 -0000 Subject: [opensource-dev] Review Request: VWR-24420: PNG images which specify "background color" lose alpha layer when imported. In-Reply-To: <20110109145917.7202.23064@domU-12-31-38-00-90-68.compute-1.internal> References: <20110109145917.7202.23064@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110118191149.26332.24863@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/74/#review185 ----------------------------------------------------------- indra/llimage/llpngwrapper.cpp Typo : change "gama" to "gamma" - Merov On Jan. 9, 2011, 6:59 a.m., Thickbrick Sleaford wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/74/ > ----------------------------------------------------------- > > (Updated Jan. 9, 2011, 6:59 a.m.) > > > Review request for Viewer. > > > Summary > ------- > > Current code composites RGBA PNG images that contain a bKGD chunk down to RGB, discarding the alpha channel. This patch removes that code, since it contradicts purpose of the bKGD chunk as described in the PNG spec and as commonly used. > > > This addresses bug VWR-24420. > http://jira.secondlife.com/browse/VWR-24420 > > > Diffs > ----- > > doc/contributions.txt UNKNOWN > indra/llimage/llpngwrapper.h UNKNOWN > indra/llimage/llpngwrapper.cpp UNKNOWN > > Diff: http://codereview.secondlife.com/r/74/diff > > > Testing > ------- > > Tested uploading the 2 images attached to VWR-24420 with and without the patch. Before patch, "bad alpha.png" was uploaded as RGB, after patch, both images were uploaded as RGBA. > > > Thanks, > > Thickbrick > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110118/f9104b00/attachment-0001.htm From merov at lindenlab.com Tue Jan 18 11:12:46 2011 From: merov at lindenlab.com (Merov Linden) Date: Tue, 18 Jan 2011 19:12:46 -0000 Subject: [opensource-dev] Review Request: VWR-24420: PNG images which specify "background color" lose alpha layer when imported. In-Reply-To: <20110109145917.7202.23064@domU-12-31-38-00-90-68.compute-1.internal> References: <20110109145917.7202.23064@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110118191246.25764.66243@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/74/#review186 ----------------------------------------------------------- Ship it! Other than the typo, no problem with that code. Good to fix all those alpha upload scenarios. - Merov On Jan. 9, 2011, 6:59 a.m., Thickbrick Sleaford wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/74/ > ----------------------------------------------------------- > > (Updated Jan. 9, 2011, 6:59 a.m.) > > > Review request for Viewer. > > > Summary > ------- > > Current code composites RGBA PNG images that contain a bKGD chunk down to RGB, discarding the alpha channel. This patch removes that code, since it contradicts purpose of the bKGD chunk as described in the PNG spec and as commonly used. > > > This addresses bug VWR-24420. > http://jira.secondlife.com/browse/VWR-24420 > > > Diffs > ----- > > doc/contributions.txt UNKNOWN > indra/llimage/llpngwrapper.h UNKNOWN > indra/llimage/llpngwrapper.cpp UNKNOWN > > Diff: http://codereview.secondlife.com/r/74/diff > > > Testing > ------- > > Tested uploading the 2 images attached to VWR-24420 with and without the patch. Before patch, "bad alpha.png" was uploaded as RGB, after patch, both images were uploaded as RGBA. > > > Thanks, > > Thickbrick > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110118/9a6f7d8c/attachment.htm From angel_of_crimson at hotmail.com Tue Jan 18 11:22:06 2011 From: angel_of_crimson at hotmail.com (Erin Mallory) Date: Tue, 18 Jan 2011 14:22:06 -0500 Subject: [opensource-dev] STORM-243 - simulator version notifications In-Reply-To: References: <5941ED4A-7D5D-4008-9FC9-A68B33EF2A44@lindenlab.com>, , <226473.53614.qm@web120517.mail.ne1.yahoo.com>, Message-ID: to rephrase, yes I like them, thought i'd rather see them on the chat history and have more detailed. but i can live without them if the majority really want to see them gone altogether. for me it helps me during certain testing and stuff to know when ive changed server versions but that's really about it. From: angel_of_crimson at hotmail.com To: missannotoole at yahoo.com; q at lindenlab.com; opensource-dev at lists.secondlife.com Date: Tue, 18 Jan 2011 12:04:09 -0500 Subject: Re: [opensource-dev] STORM-243 - simulator version notifications I would also like to see the toast moved. it can be useful and would be more useful if it had the actual version. but i would like to see it on the chat history instead. in fact... it would be nice to have an option to have ALL remaining system notifications be optionally shown in chat history instead of as toasts. for one thing it would log better i think, for another... well toasts bother a rather significant portion of sl. those with some forms of epilepsy, migraines, some forms of add... to name a few... Erin/aka Cummere Date: Tue, 18 Jan 2011 08:35:01 -0800 From: missannotoole at yahoo.com To: q at lindenlab.com; opensource-dev at lists.secondlife.com Subject: Re: [opensource-dev] STORM-243 - simulator version notifications Doesn't it add some minor overhead to region crossings? I don't care about it. The message does not say what server version you just entered so it is mostly an annoyance. If I need version info I know where it is. What I would like to see is region rating and a single letter server version code on the map without having to mouse float. From: Kent Quirk (Q Linden) Hi, folks. I've just commented on STORM-243, which requests that we have Yet Another Option to allow suppression of the toast that tells you the simulator version changed when you changed to a new region. I think we should delete it entirely. Does anyone care to still get that notification, now that there are usually 3 different simulator versions live on the grid at any time? I don't mean "I can think of an obscure scenario when someone might care." I mean does anyone really need a notification about this, or can we just delete it? _______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges _______________________________________________ Policies 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/20110118/f0466691/attachment.htm From slitovchuk at productengine.com Tue Jan 18 11:26:00 2011 From: slitovchuk at productengine.com (Seth ProductEngine) Date: Tue, 18 Jan 2011 19:26:00 -0000 Subject: [opensource-dev] Review Request: STORM-373 "Rename" context menu option disabled for incomplete inventory items In-Reply-To: <20110118162036.26007.12085@domU-12-31-38-00-90-68.compute-1.internal> References: <20110118162036.26007.12085@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110118192600.25993.52253@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/101/#review187 ----------------------------------------------------------- Ship it! Looks good to me. Seems like adding another observer is necessary to deal with this issue. - Seth On Jan. 18, 2011, 8:20 a.m., Vadim ProductEngine wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/101/ > ----------------------------------------------------------- > > (Updated Jan. 18, 2011, 8:20 a.m.) > > > Review request for Viewer. > > > Summary > ------- > > Refresh the inventory context menu (which enables the "Rename" option) after the selected item(s) gets fetched. > > I'm a bit worried by adding another inventory observer to each inventory panel, but I couldn't come up with a solution which is more elegant and affects performance less. > > > This addresses bug STORM-373. > http://jira.secondlife.com/browse/STORM-373 > > > Diffs > ----- > > indra/newview/llfolderview.h 422f636c3343 > indra/newview/llfolderview.cpp 422f636c3343 > indra/newview/llinventorypanel.h 422f636c3343 > indra/newview/llinventorypanel.cpp 422f636c3343 > > Diff: http://codereview.secondlife.com/r/101/diff > > > Testing > ------- > > > Thanks, > > Vadim > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110118/76f27bc7/attachment.htm From merov at lindenlab.com Tue Jan 18 11:31:43 2011 From: merov at lindenlab.com (Merov Linden) Date: Tue, 18 Jan 2011 19:31:43 -0000 Subject: [opensource-dev] Review Request: VWR-24320: Don't dump callstacks at clean exit of viewer. In-Reply-To: <20110114210035.17162.62216@domU-12-31-38-00-90-68.compute-1.internal> References: <20110114210035.17162.62216@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110118193143.32180.94320@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/89/#review188 ----------------------------------------------------------- Ship it! I do think this can be suppressed. It's not extremely useful in clean exit situations. - Merov On Jan. 14, 2011, 1 p.m., Aleric Inglewood wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/89/ > ----------------------------------------------------------- > > (Updated Jan. 14, 2011, 1 p.m.) > > > Review request for Viewer. > > > Summary > ------- > > See http://jira.secondlife.com/browse/VWR-24320 > > > This addresses bug VWR-24320. > http://jira.secondlife.com/browse/VWR-24320 > > > Diffs > ----- > > doc/contributions.txt b0bd26c5638a > indra/newview/llappviewer.cpp b0bd26c5638a > > Diff: http://codereview.secondlife.com/r/89/diff > > > Testing > ------- > > > Thanks, > > Aleric > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110118/3e863984/attachment.htm From leyla at lindenlab.com Tue Jan 18 11:34:37 2011 From: leyla at lindenlab.com (Leyla Farazha) Date: Tue, 18 Jan 2011 19:34:37 -0000 Subject: [opensource-dev] Review Request: DN-202: More aggressive caching of display names In-Reply-To: <20110118170238.25765.26076@domU-12-31-38-00-90-68.compute-1.internal> References: <20110118170238.25765.26076@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110118193437.25992.84438@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/104/#review189 ----------------------------------------------------------- Ship it! Looks great. Couldn't find any issues, except there was a "chached" instead of cached in a comment. We'd had issues in the past deleting expired entries from the cache, because the occasional synchronous call would come back without data the first time. But it looks like it only deletes them once it's been 20 minutes and there haven't been any fresh updates, which should be a pretty rare case, and it'll assure that we don't fall back to legacy names when we don't have to. Thanks for working on this code Oz :-) - Leyla On Jan. 18, 2011, 9:02 a.m., Oz Linden wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/104/ > ----------------------------------------------------------- > > (Updated Jan. 18, 2011, 9:02 a.m.) > > > Review request for Viewer. > > > Summary > ------- > > Changes the caching of avatar display names and other information from > the People API to be more aggressive. > > The expiration time (which is derived from the cache controls of the > HTTP responses), is now treated primarily as a maximum time before > which the name information should be refreshed. When the ::get method > is called on an entry older than its expiration time, an attempt is > made to refresh the entry; if that attempt returns a failure, the > cached entry is returned anyway. > > In the event of error returns from the People API when there is no > cached entry, the legacy name system is queried to create temporary > results; these are never cached in the LLAvatarNameCache. This > applies both to HTTP request errors and to names that the PeopleAPI > explicitly returns as error responses (the latter were the ones that > previously created "???" temporary names - these are never created > within the viewer now). > > The only time that entries are actually removed from the cache is a > check made immediately after loading and every 20 minutes > (MAX_UNREFRESHED_TIME) thereafter: entries whose expiration time is > more than 20 minutes in the past are deleted. > > Also added extensive logging, mostly at DEBUG level, under the "AvNameCache" tag. > > > This addresses bug dn-202. > http://jira.secondlife.com/browse/dn-202 > > > Diffs > ----- > > indra/llcommon/llavatarname.h 422f636c3343 > indra/llcommon/llavatarname.cpp 422f636c3343 > indra/llmessage/llavatarnamecache.h 422f636c3343 > indra/llmessage/llavatarnamecache.cpp 422f636c3343 > indra/newview/llappviewer.cpp 422f636c3343 > indra/newview/llimview.cpp 422f636c3343 > > Diff: http://codereview.secondlife.com/r/104/diff > > > Testing > ------- > > Hung out in busy welcome areas to get lots of name requests. > > Confirmed that refresh behavior was correct, and observed a number of > HTTP error returns (both 499 Timeout, the most common, and 404 Not > Found) from the People API. Saw that the fallback was correct (many > examples of both falling back to a previously cached display name and > to the legacy name when no cache was available). All of these were > then correctly refreshed (the next attempt was almost always > successful). > > Observed only a couple of cases of the People API returning unresolved > names (the case that previously lead to "???" being used). The > behavior was correct, but some more testing on a development grid > where this error is forced may be a good idea. > > Moved to a nice quiet empty region, and observed that the cache > cleaning occurred correctly after 20 minutes. > > Confirmed that cached values were saved and reloaded correctly. > > > Thanks, > > Oz > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110118/1502faaa/attachment-0001.htm From oskar at lindenlab.com Tue Jan 18 11:32:53 2011 From: oskar at lindenlab.com (Oskar Linden) Date: Tue, 18 Jan 2011 11:32:53 -0800 Subject: [opensource-dev] STORM-243 - simulator version notifications In-Reply-To: References: <5941ED4A-7D5D-4008-9FC9-A68B33EF2A44@lindenlab.com> <226473.53614.qm@web120517.mail.ne1.yahoo.com> Message-ID: It does have use for people testing server. I'd say make it optional, more informative, and disabled by default. __Oskar On Tue, Jan 18, 2011 at 11:22 AM, Erin Mallory wrote: > to rephrase, yes I like them, thought i'd rather see them on the chat > history and have more detailed. but i can live without them if the majority > really want to see them gone altogether. for me it helps me during certain > testing and stuff to know when ive changed server versions but that's really > about it. > > ------------------------------ > From: angel_of_crimson at hotmail.com > To: missannotoole at yahoo.com; q at lindenlab.com; > opensource-dev at lists.secondlife.com > Date: Tue, 18 Jan 2011 12:04:09 -0500 > > Subject: Re: [opensource-dev] STORM-243 - simulator version notifications > > I would also like to see the toast moved. it can be useful and would be > more useful if it had the actual version. but i would like to see it on the > chat history instead. in fact... it would be nice to have an option to have > ALL remaining system notifications be optionally shown in chat history > instead of as toasts. for one thing it would log better i think, for > another... well toasts bother a rather significant portion of sl. those > with some forms of epilepsy, migraines, some forms of add... to name a > few... > > Erin/aka Cummere > > ------------------------------ > Date: Tue, 18 Jan 2011 08:35:01 -0800 > From: missannotoole at yahoo.com > To: q at lindenlab.com; opensource-dev at lists.secondlife.com > Subject: Re: [opensource-dev] STORM-243 - simulator version notifications > > Doesn't it add some minor overhead to region crossings? I don't care about > it. The message does not say what server version you just entered so it is > mostly an annoyance. If I need version info I know where it is. > > What I would like to see is region rating and a single letter server > version code on the map without having to mouse float. > > ------------------------------ > *From:* Kent Quirk (Q Linden) > ** > Hi, folks. I've just commented on STORM-243, which requests that we have > Yet Another Option to allow suppression of the toast that tells you the > simulator version changed when you changed to a new region. > > I think we should delete it entirely. Does anyone care to still get that > notification, now that there are usually 3 different simulator versions live > on the grid at any time? I don't mean "I can think of an obscure scenario > when someone might care." I mean does anyone really need a notification > about this, or can we just delete it? > > > > _______________________________________________ Policies and (un)subscribe > information available here: http://wiki.secondlife.com/wiki/OpenSource-DevPlease read the policies before posting to keep unmoderated posting > privileges > _______________________________________________ Policies and (un)subscribe > information available here: http://wiki.secondlife.com/wiki/OpenSource-DevPlease 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/20110118/4e4ef1e5/attachment.htm From merov at lindenlab.com Tue Jan 18 11:39:05 2011 From: merov at lindenlab.com (Merov Linden) Date: Tue, 18 Jan 2011 19:39:05 -0000 Subject: [opensource-dev] Review Request: VWR-24333: Hardening against use of getLindenUserDir() before logging in. In-Reply-To: <20110114210504.17156.62298@domU-12-31-38-00-90-68.compute-1.internal> References: <20110114210504.17156.62298@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110118193905.26155.449@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/91/#review190 ----------------------------------------------------------- Ship it! I haven't search for all instances of getLindenUserDir() in the whole code but, reading the diff, this all looks good to me. - Merov On Jan. 14, 2011, 1:05 p.m., Aleric Inglewood wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/91/ > ----------------------------------------------------------- > > (Updated Jan. 14, 2011, 1:05 p.m.) > > > Review request for Viewer. > > > Summary > ------- > > Without this patch, getLindenUserDir() is sometimes used without > checking if it returns an empty value, resulting in trying to open > an empty file and then gracefully recovering from that. So, this > patch doesn't really fix a bug. However it might prevent one in the > future. Note that this DID lead to a bug in Viewer 1 code, so it's > possible. The main threat is that some singleton class that uses > getLindenUserDir (indirectly) is instantiated before logging in: > A singleton is only created once and when it is initialized with > an empty getLindenUserDir() then that can remain. > > This patch aborts when the viewer is compiled in debug mode (not > in release mode, when it will do what it did before this patch) > and when getLindenUserDir() is called before it was initialized, > unless the developer explicitely passes 'true' (empty_ok) to > getLindenUserDir, signaling that they considered the possibility > that the function is being called before the user logged in. > > > This addresses bug VWR-24333. > http://jira.secondlife.com/browse/VWR-24333 > > > Diffs > ----- > > indra/llvfs/lldir.h 422f636c3343 > indra/llvfs/lldir.cpp 422f636c3343 > indra/newview/llappviewer.cpp 422f636c3343 > indra/newview/llbottomtray.cpp 422f636c3343 > indra/newview/llfilepicker.cpp 422f636c3343 > indra/newview/llnavigationbar.cpp 422f636c3343 > indra/newview/llsearchhistory.h 422f636c3343 > indra/newview/llurlhistory.cpp 422f636c3343 > indra/newview/llviewerinventory.cpp 422f636c3343 > indra/newview/llviewermedia.cpp 422f636c3343 > indra/newview/llvoiceclient.cpp 422f636c3343 > > Diff: http://codereview.secondlife.com/r/91/diff > > > Testing > ------- > > > Thanks, > > Aleric > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110118/e7bf778a/attachment.htm From angel_of_crimson at hotmail.com Tue Jan 18 11:39:50 2011 From: angel_of_crimson at hotmail.com (Erin Mallory) Date: Tue, 18 Jan 2011 14:39:50 -0500 Subject: [opensource-dev] STORM-243 - simulator version notifications In-Reply-To: References: <5941ED4A-7D5D-4008-9FC9-A68B33EF2A44@lindenlab.com>, <226473.53614.qm@web120517.mail.ne1.yahoo.com>, , , Message-ID: could even bury the option in the debug console... most people that would need to turn it on would not likely keep flipping it I would think... Date: Tue, 18 Jan 2011 11:32:53 -0800 From: oskar at lindenlab.com To: opensource-dev at lists.secondlife.com Subject: Re: [opensource-dev] STORM-243 - simulator version notifications It does have use for people testing server. I'd say make it optional, more informative, and disabled by default. __Oskar On Tue, Jan 18, 2011 at 11:22 AM, Erin Mallory wrote: to rephrase, yes I like them, thought i'd rather see them on the chat history and have more detailed. but i can live without them if the majority really want to see them gone altogether. for me it helps me during certain testing and stuff to know when ive changed server versions but that's really about it. From: angel_of_crimson at hotmail.com To: missannotoole at yahoo.com; q at lindenlab.com; opensource-dev at lists.secondlife.com Date: Tue, 18 Jan 2011 12:04:09 -0500 Subject: Re: [opensource-dev] STORM-243 - simulator version notifications I would also like to see the toast moved. it can be useful and would be more useful if it had the actual version. but i would like to see it on the chat history instead. in fact... it would be nice to have an option to have ALL remaining system notifications be optionally shown in chat history instead of as toasts. for one thing it would log better i think, for another... well toasts bother a rather significant portion of sl. those with some forms of epilepsy, migraines, some forms of add... to name a few... Erin/aka Cummere Date: Tue, 18 Jan 2011 08:35:01 -0800 From: missannotoole at yahoo.com To: q at lindenlab.com; opensource-dev at lists.secondlife.com Subject: Re: [opensource-dev] STORM-243 - simulator version notifications Doesn't it add some minor overhead to region crossings? I don't care about it. The message does not say what server version you just entered so it is mostly an annoyance. If I need version info I know where it is. What I would like to see is region rating and a single letter server version code on the map without having to mouse float. From: Kent Quirk (Q Linden) Hi, folks. I've just commented on STORM-243, which requests that we have Yet Another Option to allow suppression of the toast that tells you the simulator version changed when you changed to a new region. I think we should delete it entirely. Does anyone care to still get that notification, now that there are usually 3 different simulator versions live on the grid at any time? I don't mean "I can think of an obscure scenario when someone might care." I mean does anyone really need a notification about this, or can we just delete it? _______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges _______________________________________________ Policies 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/20110118/f784df0c/attachment-0001.htm From kadah.coba at gmail.com Tue Jan 18 11:47:39 2011 From: kadah.coba at gmail.com (Kadah) Date: Tue, 18 Jan 2011 11:47:39 -0800 Subject: [opensource-dev] STORM-243 - simulator version notifications In-Reply-To: References: <5941ED4A-7D5D-4008-9FC9-A68B33EF2A44@lindenlab.com> <226473.53614.qm@web120517.mail.ne1.yahoo.com> Message-ID: <4D35EE5B.1070205@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 What Oskar said. Plus there are frequently (every RC roll?) bugs in one more more of the RCs that will effect a user till they relog on to a different RC server. - From November to mid-late December I was effected one or another bugs like that when ever I'd logg in to my home region that was Le Tigre and later on, Blue Steel. On 1/18/2011 11:32 AM, Oskar Linden wrote: > It does have use for people testing server. I'd say make it optional, > more informative, and disabled by default. > > __Oskar > > On Tue, Jan 18, 2011 at 11:22 AM, Erin Mallory > > wrote: > > to rephrase, yes I like them, thought i'd rather see them on the > chat history and have more detailed. but i can live without them if > the majority really want to see them gone altogether. for me it > helps me during certain testing and stuff to know when ive changed > server versions but that's really about it. > > ------------------------------------------------------------------------ > From: angel_of_crimson at hotmail.com > To: missannotoole at yahoo.com ; > q at lindenlab.com ; > opensource-dev at lists.secondlife.com > > Date: Tue, 18 Jan 2011 12:04:09 -0500 > > Subject: Re: [opensource-dev] STORM-243 - simulator version > notifications > > I would also like to see the toast moved. it can be useful and > would be more useful if it had the actual version. but i would like > to see it on the chat history instead. in fact... it would be nice > to have an option to have ALL remaining system notifications be > optionally shown in chat history instead of as toasts. for one > thing it would log better i think, for another... well toasts > bother a rather significant portion of sl. those with some forms > of epilepsy, migraines, some forms of add... to name a few... > > Erin/aka Cummere > > ------------------------------------------------------------------------ > Date: Tue, 18 Jan 2011 08:35:01 -0800 > From: missannotoole at yahoo.com > To: q at lindenlab.com ; > opensource-dev at lists.secondlife.com > > Subject: Re: [opensource-dev] STORM-243 - simulator version > notifications > > Doesn't it add some minor overhead to region crossings? I don't care > about it. The message does not say what server version you just > entered so it is mostly an annoyance. If I need version info I know > where it is. > > What I would like to see is region rating and a single letter server > version code on the map without having to mouse float. > > ------------------------------------------------------------------------ > *From:* Kent Quirk (Q Linden) > > ** > Hi, folks. I've just commented on STORM-243, which requests that we > have Yet Another Option to allow suppression of the toast that tells > you the simulator version changed when you changed to a new region. > > I think we should delete it entirely. Does anyone care to still get > that notification, now that there are usually 3 different simulator > versions live on the grid at any time? I don't mean "I can think of > an obscure scenario when someone might care." I mean does anyone > really need a notification about this, or can we just delete it? > > > > _______________________________________________ Policies and > (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the > policies before posting to keep unmoderated posting privileges > _______________________________________________ Policies 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJNNe5bAAoJEIdLfPRu7qE2R+AIAJJ+h5AuKJaZXFVUbkKNe3GY ziqBbj+rGtGYnY8gNwTFm15O6EQlQpCmO3LFTBEDWbXtkOk9NselM8/iw5sTKBHd 2KL8PdsSyi/WxBPrpkoniHRYLxamBVDu/htkPTheOIxg+tcBUQMHwbdzbZjkp2QW sWiw6gl8v8mPXeRi5bdLlK0oBAMqE4ledJmCYFSK0HyadKiTByPRyEMA/zw7mKq5 6uoqol4KsFMKdUwMVL4aXLq/oI8DfeWfVXCdxQS/ZI0UHPqow5ZEWXQ57OPK82VY 3laOCx3qS7MDOHhza015gwJyUMPLnwgDLByOjVke9rWYPYR37+TGpIDuSJpOAWM= =Cg1a -----END PGP SIGNATURE----- From merov at lindenlab.com Tue Jan 18 12:09:36 2011 From: merov at lindenlab.com (Merov Linden) Date: Tue, 18 Jan 2011 20:09:36 -0000 Subject: [opensource-dev] Review Request: VWR-24321: Validate textures starting with 00 too. In-Reply-To: <20110114210232.20676.90941@domU-12-31-38-00-90-68.compute-1.internal> References: <20110114210232.20676.90941@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110118200936.25759.54373@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/90/#review191 ----------------------------------------------------------- indra/newview/lltexturecache.cpp validate_idx being used in a test later, it's not just for (validate_idx == 0) that the behavior will be different. I need to understand better what that idx is all about or you need to give a bit more explanation before I approve this diff. - Merov On Jan. 14, 2011, 1:02 p.m., Aleric Inglewood wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/90/ > ----------------------------------------------------------- > > (Updated Jan. 14, 2011, 1:02 p.m.) > > > Review request for Viewer. > > > Summary > ------- > > Trivial patch, just removes stupidity. > > > This addresses bug VWR-24321. > http://jira.secondlife.com/browse/VWR-24321 > > > Diffs > ----- > > doc/contributions.txt b0bd26c5638a > indra/newview/lltexturecache.cpp b0bd26c5638a > > Diff: http://codereview.secondlife.com/r/90/diff > > > Testing > ------- > > > Thanks, > > Aleric > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110118/5e774485/attachment.htm From Lance.Corrimal at eregion.de Tue Jan 18 12:16:54 2011 From: Lance.Corrimal at eregion.de (Lance Corrimal) Date: Tue, 18 Jan 2011 21:16:54 +0100 Subject: [opensource-dev] STORM-243 - simulator version notifications In-Reply-To: References: <5941ED4A-7D5D-4008-9FC9-A68B33EF2A44@lindenlab.com> Message-ID: <201101182116.55282.Lance.Corrimal@eregion.de> Am Dienstag, 18. Januar 2011 schrieb Oskar Linden: > It does have use for people testing server. I'd say make it > optional, more informative, and disabled by default. seconded! wrap it in an if(gSavedSettings.getBOOL() ), and make it more detailed with links to the release notes to both server versions involved, and maybe the sim hostnames as well... bye, LC From twisted_laws at hotmail.com Tue Jan 18 12:30:37 2011 From: twisted_laws at hotmail.com (Twisted Laws) Date: Tue, 18 Jan 2011 15:30:37 -0500 Subject: [opensource-dev] STORM-243 - simulator version notifications In-Reply-To: References: <5941ED4A-7D5D-4008-9FC9-A68B33EF2A44@lindenlab.com>, Message-ID: Personally I see no reason for it and a user could have a simple script they are wearing that triggers on changed, CHANGE_REGION, that tells them the version of the server if they are interested. default { on_rez(integer start_param) { llOwnerSay(llGetRegionName + " " + llGetEnv("sim_channel") + " " + llGetEnv("sim_version")); } changed(integer change) { if(change & CHANGED_REGION) { llOwnerSay(llGetRegionName + " " + llGetEnv("sim_channel") + " " + llGetEnv("sim_version")); } } } -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110118/eea23f02/attachment.htm From q at lindenlab.com Tue Jan 18 12:41:26 2011 From: q at lindenlab.com (Kent Quirk) Date: Tue, 18 Jan 2011 20:41:26 -0000 Subject: [opensource-dev] Review Request: STORM-243 Suppress version change message in the viewer In-Reply-To: <20110118170233.25766.11850@domU-12-31-38-00-90-68.compute-1.internal> References: <20110118170233.25766.11850@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110118204126.25761.31192@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/109/#review192 ----------------------------------------------------------- Ship it! We've had the discussion and the change looks solid. - Kent On Jan. 18, 2011, 9:02 a.m., Vadim ProductEngine wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/109/ > ----------------------------------------------------------- > > (Updated Jan. 18, 2011, 9:02 a.m.) > > > Review request for Viewer. > > > Summary > ------- > > Removed the "You just entered a region using a different server version..." pop-up notification. > > > This addresses bug STORM-243. > http://jira.secondlife.com/browse/STORM-243 > > > Diffs > ----- > > indra/newview/app_settings/settings.xml 422f636c3343 > indra/newview/llviewermessage.cpp 422f636c3343 > indra/newview/skins/default/xui/da/notifications.xml 422f636c3343 > indra/newview/skins/default/xui/de/notifications.xml 422f636c3343 > indra/newview/skins/default/xui/en/notifications.xml 422f636c3343 > indra/newview/skins/default/xui/es/notifications.xml 422f636c3343 > indra/newview/skins/default/xui/fr/notifications.xml 422f636c3343 > indra/newview/skins/default/xui/it/notifications.xml 422f636c3343 > indra/newview/skins/default/xui/ja/notifications.xml 422f636c3343 > indra/newview/skins/default/xui/nl/notifications.xml 422f636c3343 > indra/newview/skins/default/xui/pl/notifications.xml 422f636c3343 > indra/newview/skins/default/xui/pt/notifications.xml 422f636c3343 > > Diff: http://codereview.secondlife.com/r/109/diff > > > Testing > ------- > > > Thanks, > > Vadim > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110118/5e5f78b0/attachment.htm From lee.ponzu at gmail.com Tue Jan 18 13:20:51 2011 From: lee.ponzu at gmail.com (Ponzu) Date: Tue, 18 Jan 2011 16:20:51 -0500 Subject: [opensource-dev] Link times In-Reply-To: References: <4D30D2F6.2010008@boroon.dasgupta.ch> Message-ID: Can you make the links verbose and compare the options? Also, why would first and second links differ? Could be that CV did a major revision of the make files, or CMake, or whatever is being used. On Sun, Jan 16, 2011 at 10:49 AM, Aleric Inglewood < aleric.inglewood at gmail.com> wrote: > I'm afraid that VWR-24366 won't reduce link times significantly. > > On Fri, Jan 14, 2011 at 11:49 PM, Boroondas Gupte > wrote: > > On 01/14/2011 06:04 PM, Jonathan Welch wrote: > > > > I just did a quick study on link times for various viewers on my 2Gb XP > > system > > > > Viewer 1st link 2nd link > > CV 1.22 0:53 0:24 > > SG 1.5 3:30 2:07 > > V2.5 6:18 6:01 > > > > The long time for 2.5 be due to VWR-24366. Dunno why linking Cool Viewer > > (that's what "CV" stands for, isn't it?) is so much quicker than SG 1.5, > > though. > > > > Good news: A fix is being reviewed at > > https://codereview.secondlife.com/r/95/ > > > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110118/e1bd5962/attachment.htm From trilobyte550m at gmail.com Tue Jan 18 13:27:54 2011 From: trilobyte550m at gmail.com (Trilo Byte) Date: Tue, 18 Jan 2011 13:27:54 -0800 Subject: [opensource-dev] STORM-243 - simulator version notifications In-Reply-To: References: <5941ED4A-7D5D-4008-9FC9-A68B33EF2A44@lindenlab.com>, <226473.53614.qm@web120517.mail.ne1.yahoo.com>, , , Message-ID: <6E2D0388-BD03-4BB7-ADD1-4D3DCEA01FDB@gmail.com> +1 for making it a debug setting (to choose whether you see notifications). The server version info would still be available in Help -> About as well as World -> Place Profile -> Region/Estate On Jan 18, 2011, at 11:39 AM, Erin Mallory wrote: > could even bury the option in the debug console... most people that would need to turn it on would not likely keep flipping it I would think... > > Date: Tue, 18 Jan 2011 11:32:53 -0800 > From: oskar at lindenlab.com > To: opensource-dev at lists.secondlife.com > Subject: Re: [opensource-dev] STORM-243 - simulator version notifications > > It does have use for people testing server. I'd say make it optional, more informative, and disabled by default. > > __Oskar > > On Tue, Jan 18, 2011 at 11:22 AM, Erin Mallory wrote: > to rephrase, yes I like them, thought i'd rather see them on the chat history and have more detailed. but i can live without them if the majority really want to see them gone altogether. for me it helps me during certain testing and stuff to know when ive changed server versions but that's really about it. > > From: angel_of_crimson at hotmail.com > To: missannotoole at yahoo.com; q at lindenlab.com; opensource-dev at lists.secondlife.com > Date: Tue, 18 Jan 2011 12:04:09 -0500 > > Subject: Re: [opensource-dev] STORM-243 - simulator version notifications > > I would also like to see the toast moved. it can be useful and would be more useful if it had the actual version. but i would like to see it on the chat history instead. in fact... it would be nice to have an option to have ALL remaining system notifications be optionally shown in chat history instead of as toasts. for one thing it would log better i think, for another... well toasts bother a rather significant portion of sl. those with some forms of epilepsy, migraines, some forms of add... to name a few... > > Erin/aka Cummere > > Date: Tue, 18 Jan 2011 08:35:01 -0800 > From: missannotoole at yahoo.com > To: q at lindenlab.com; opensource-dev at lists.secondlife.com > Subject: Re: [opensource-dev] STORM-243 - simulator version notifications > > Doesn't it add some minor overhead to region crossings? I don't care about it. The message does not say what server version you just entered so it is mostly an annoyance. If I need version info I know where it is. > > What I would like to see is region rating and a single letter server version code on the map without having to mouse float. > > From: Kent Quirk (Q Linden) > > Hi, folks. I've just commented on STORM-243, which requests that we have Yet Another Option to allow suppression of the toast that tells you the simulator version changed when you changed to a new region. > > I think we should delete it entirely. Does anyone care to still get that notification, now that there are usually 3 different simulator versions live on the grid at any time? I don't mean "I can think of an obscure scenario when someone might care." I mean does anyone really need a notification about this, or can we just delete it? > > > > _______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges > _______________________________________________ Policies 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/20110118/111e2552/attachment-0001.htm From liny.odell at phoenixviewer.com Tue Jan 18 13:35:34 2011 From: liny.odell at phoenixviewer.com (Liny Odell) Date: Tue, 18 Jan 2011 13:35:34 -0800 Subject: [opensource-dev] STORM-243 - simulator version notifications In-Reply-To: <6E2D0388-BD03-4BB7-ADD1-4D3DCEA01FDB@gmail.com> References: <5941ED4A-7D5D-4008-9FC9-A68B33EF2A44@lindenlab.com> <226473.53614.qm@web120517.mail.ne1.yahoo.com> <6E2D0388-BD03-4BB7-ADD1-4D3DCEA01FDB@gmail.com> Message-ID: Make that +2 for a debug setting On Tue, Jan 18, 2011 at 1:27 PM, Trilo Byte wrote: > +1 for making it a debug setting (to choose whether you see notifications). > > The server version info would still be available in Help -> About as well as > World -> Place Profile -> Region/Estate > On Jan 18, 2011, at 11:39 AM, Erin Mallory wrote: > > could even bury the option in the debug console... most people that would > need to turn it on would not likely keep flipping it I would think... > > ________________________________ > Date: Tue, 18 Jan 2011 11:32:53 -0800 > From:?oskar at lindenlab.com > To:?opensource-dev at lists.secondlife.com > Subject: Re: [opensource-dev] STORM-243 - simulator version notifications > > It does have use for people testing server. I'd say make it optional, more > informative, and disabled by default. > > __Oskar > > On Tue, Jan 18, 2011 at 11:22 AM, Erin > Mallory??wrote: > > to rephrase, yes I like them, thought i'd rather see them on the chat > history and have more detailed.? but i can live without them if the majority > really want to see them gone altogether.? for me it helps me during certain > testing and stuff to know when ive changed server versions but that's really > about it. > > ________________________________ > From:?angel_of_crimson at hotmail.com > To:?missannotoole at yahoo.com;?q at lindenlab.com;?opensource-dev at lists.secondlife.com > Date: Tue, 18 Jan 2011 12:04:09 -0500 > Subject: Re: [opensource-dev] STORM-243 - simulator version notifications > > I would also like to see the toast moved.? it can be useful and would be > more useful if it had the actual version.? but i would like to see it on the > chat history instead.? in fact... it would be nice to have an option to have > ALL remaining system notifications be optionally shown in chat history > instead of as toasts.? for one thing it would log better i think, for > another...? well toasts bother a rather significant portion of sl.?? those > with some forms of epilepsy, migraines, some forms of add... to name a > few... > > Erin/aka Cummere > > ________________________________ > Date: Tue, 18 Jan 2011 08:35:01 -0800 > From:?missannotoole at yahoo.com > To:?q at lindenlab.com;?opensource-dev at lists.secondlife.com > Subject: Re: [opensource-dev] STORM-243 - simulator version notifications > > Doesn't it add some minor overhead to region crossings? I don't care about > it. The message does not say what server version you just entered so it is > mostly an annoyance. If I need version info I know where it is. > > What I would like to see is region rating and a single letter server version > code on the map without having to mouse float. > > ________________________________ > From:?Kent Quirk (Q Linden) > > Hi, folks. I've just commented on STORM-243, which requests that we have Yet > Another Option to allow suppression of the toast that tells you the > simulator version changed when you changed to a new region. > > I think we should delete it entirely. Does anyone care to still get that > notification, now that there are usually 3 different simulator versions live > on the grid at any time? I don't mean "I can think of an obscure scenario > when someone might care." I mean does anyone really need a notification > about this, or can we just delete it? > > > > _______________________________________________ Policies and (un)subscribe > information available > here:?http://wiki.secondlife.com/wiki/OpenSource-Dev?Please read the > policies before posting to keep unmoderated posting privileges > _______________________________________________ Policies 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 q at lindenlab.com Tue Jan 18 13:37:34 2011 From: q at lindenlab.com (Kent Quirk (Q Linden)) Date: Tue, 18 Jan 2011 16:37:34 -0500 Subject: [opensource-dev] STORM-243 - simulator version notifications In-Reply-To: References: <5941ED4A-7D5D-4008-9FC9-A68B33EF2A44@lindenlab.com> <226473.53614.qm@web120517.mail.ne1.yahoo.com> <6E2D0388-BD03-4BB7-ADD1-4D3DCEA01FDB@gmail.com> Message-ID: It's not gonna be a debug setting. The information's available to put it on a HUD if you care. We're pulling the feature and simplifying the viewer. On Jan 18, 2011, at 4:35 PM, Liny Odell wrote: > Make that +2 for a debug setting > > On Tue, Jan 18, 2011 at 1:27 PM, Trilo Byte wrote: >> +1 for making it a debug setting (to choose whether you see notifications). >> >> The server version info would still be available in Help -> About as well as >> World -> Place Profile -> Region/Estate >> On Jan 18, 2011, at 11:39 AM, Erin Mallory wrote: >> >> could even bury the option in the debug console... most people that would >> need to turn it on would not likely keep flipping it I would think... >> >> ________________________________ >> Date: Tue, 18 Jan 2011 11:32:53 -0800 >> From: oskar at lindenlab.com >> To: opensource-dev at lists.secondlife.com >> Subject: Re: [opensource-dev] STORM-243 - simulator version notifications >> >> It does have use for people testing server. I'd say make it optional, more >> informative, and disabled by default. >> >> __Oskar >> >> On Tue, Jan 18, 2011 at 11:22 AM, Erin >> Mallory wrote: >> >> to rephrase, yes I like them, thought i'd rather see them on the chat >> history and have more detailed. but i can live without them if the majority >> really want to see them gone altogether. for me it helps me during certain >> testing and stuff to know when ive changed server versions but that's really >> about it. >> >> ________________________________ >> From: angel_of_crimson at hotmail.com >> To: missannotoole at yahoo.com; q at lindenlab.com; opensource-dev at lists.secondlife.com >> Date: Tue, 18 Jan 2011 12:04:09 -0500 >> Subject: Re: [opensource-dev] STORM-243 - simulator version notifications >> >> I would also like to see the toast moved. it can be useful and would be >> more useful if it had the actual version. but i would like to see it on the >> chat history instead. in fact... it would be nice to have an option to have >> ALL remaining system notifications be optionally shown in chat history >> instead of as toasts. for one thing it would log better i think, for >> another... well toasts bother a rather significant portion of sl. those >> with some forms of epilepsy, migraines, some forms of add... to name a >> few... >> >> Erin/aka Cummere >> >> ________________________________ >> Date: Tue, 18 Jan 2011 08:35:01 -0800 >> From: missannotoole at yahoo.com >> To: q at lindenlab.com; opensource-dev at lists.secondlife.com >> Subject: Re: [opensource-dev] STORM-243 - simulator version notifications >> >> Doesn't it add some minor overhead to region crossings? I don't care about >> it. The message does not say what server version you just entered so it is >> mostly an annoyance. If I need version info I know where it is. >> >> What I would like to see is region rating and a single letter server version >> code on the map without having to mouse float. >> >> ________________________________ >> From: Kent Quirk (Q Linden) >> >> Hi, folks. I've just commented on STORM-243, which requests that we have Yet >> Another Option to allow suppression of the toast that tells you the >> simulator version changed when you changed to a new region. >> >> I think we should delete it entirely. Does anyone care to still get that >> notification, now that there are usually 3 different simulator versions live >> on the grid at any time? I don't mean "I can think of an obscure scenario >> when someone might care." I mean does anyone really need a notification >> about this, or can we just delete it? >> >> >> >> _______________________________________________ Policies and (un)subscribe >> information available >> here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the >> policies before posting to keep unmoderated posting privileges >> _______________________________________________ Policies 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 stickman at gmail.com Tue Jan 18 13:46:08 2011 From: stickman at gmail.com (Stickman) Date: Tue, 18 Jan 2011 13:46:08 -0800 Subject: [opensource-dev] STORM-243 - simulator version notifications In-Reply-To: References: <5941ED4A-7D5D-4008-9FC9-A68B33EF2A44@lindenlab.com> <226473.53614.qm@web120517.mail.ne1.yahoo.com> <6E2D0388-BD03-4BB7-ADD1-4D3DCEA01FDB@gmail.com> Message-ID: > simplifying the viewer. Is this the answer to my question about the ultimate direction LL is taking for the official client? Stickman From angel_of_crimson at hotmail.com Tue Jan 18 13:49:51 2011 From: angel_of_crimson at hotmail.com (Erin Mallory) Date: Tue, 18 Jan 2011 16:49:51 -0500 Subject: [opensource-dev] STORM-243 - simulator version notifications In-Reply-To: References: <5941ED4A-7D5D-4008-9FC9-A68B33EF2A44@lindenlab.com>, <226473.53614.qm@web120517.mail.ne1.yahoo.com>, , , , , <6E2D0388-BD03-4BB7-ADD1-4D3DCEA01FDB@gmail.com>, , Message-ID: I can live with that. I got much more important features /design issues to fight over. :) > From: q at lindenlab.com > Date: Tue, 18 Jan 2011 16:37:34 -0500 > To: liny.odell at phoenixviewer.com > CC: opensource-dev at lists.secondlife.com > Subject: Re: [opensource-dev] STORM-243 - simulator version notifications > > It's not gonna be a debug setting. The information's available to put it on a HUD if you care. We're pulling the feature and simplifying the viewer. > > On Jan 18, 2011, at 4:35 PM, Liny Odell wrote: > > > Make that +2 for a debug setting > > > > On Tue, Jan 18, 2011 at 1:27 PM, Trilo Byte wrote: > >> +1 for making it a debug setting (to choose whether you see notifications). > >> > >> The server version info would still be available in Help -> About as well as > >> World -> Place Profile -> Region/Estate > >> On Jan 18, 2011, at 11:39 AM, Erin Mallory wrote: > >> > >> could even bury the option in the debug console... most people that would > >> need to turn it on would not likely keep flipping it I would think... > >> > >> ________________________________ > >> Date: Tue, 18 Jan 2011 11:32:53 -0800 > >> From: oskar at lindenlab.com > >> To: opensource-dev at lists.secondlife.com > >> Subject: Re: [opensource-dev] STORM-243 - simulator version notifications > >> > >> It does have use for people testing server. I'd say make it optional, more > >> informative, and disabled by default. > >> > >> __Oskar > >> > >> On Tue, Jan 18, 2011 at 11:22 AM, Erin > >> Mallory wrote: > >> > >> to rephrase, yes I like them, thought i'd rather see them on the chat > >> history and have more detailed. but i can live without them if the majority > >> really want to see them gone altogether. for me it helps me during certain > >> testing and stuff to know when ive changed server versions but that's really > >> about it. > >> > >> ________________________________ > >> From: angel_of_crimson at hotmail.com > >> To: missannotoole at yahoo.com; q at lindenlab.com; opensource-dev at lists.secondlife.com > >> Date: Tue, 18 Jan 2011 12:04:09 -0500 > >> Subject: Re: [opensource-dev] STORM-243 - simulator version notifications > >> > >> I would also like to see the toast moved. it can be useful and would be > >> more useful if it had the actual version. but i would like to see it on the > >> chat history instead. in fact... it would be nice to have an option to have > >> ALL remaining system notifications be optionally shown in chat history > >> instead of as toasts. for one thing it would log better i think, for > >> another... well toasts bother a rather significant portion of sl. those > >> with some forms of epilepsy, migraines, some forms of add... to name a > >> few... > >> > >> Erin/aka Cummere > >> > >> ________________________________ > >> Date: Tue, 18 Jan 2011 08:35:01 -0800 > >> From: missannotoole at yahoo.com > >> To: q at lindenlab.com; opensource-dev at lists.secondlife.com > >> Subject: Re: [opensource-dev] STORM-243 - simulator version notifications > >> > >> Doesn't it add some minor overhead to region crossings? I don't care about > >> it. The message does not say what server version you just entered so it is > >> mostly an annoyance. If I need version info I know where it is. > >> > >> What I would like to see is region rating and a single letter server version > >> code on the map without having to mouse float. > >> > >> ________________________________ > >> From: Kent Quirk (Q Linden) > >> > >> Hi, folks. I've just commented on STORM-243, which requests that we have Yet > >> Another Option to allow suppression of the toast that tells you the > >> simulator version changed when you changed to a new region. > >> > >> I think we should delete it entirely. Does anyone care to still get that > >> notification, now that there are usually 3 different simulator versions live > >> on the grid at any time? I don't mean "I can think of an obscure scenario > >> when someone might care." I mean does anyone really need a notification > >> about this, or can we just delete it? > >> > >> > >> > >> _______________________________________________ Policies and (un)subscribe > >> information available > >> here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the > >> policies before posting to keep unmoderated posting privileges > >> _______________________________________________ Policies 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 > > _______________________________________________ > Policies 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/20110118/949fba21/attachment-0001.htm From latifer at streamgrid.net Tue Jan 18 13:55:39 2011 From: latifer at streamgrid.net (Latif Khalifa) Date: Tue, 18 Jan 2011 22:55:39 +0100 Subject: [opensource-dev] STORM-243 - simulator version notifications In-Reply-To: References: <5941ED4A-7D5D-4008-9FC9-A68B33EF2A44@lindenlab.com> <226473.53614.qm@web120517.mail.ne1.yahoo.com> <6E2D0388-BD03-4BB7-ADD1-4D3DCEA01FDB@gmail.com> Message-ID: For the record: +1 for making it optional, with a debug setting default to off. The viewer has such wonderful instrumentation and debug facilities. Removing them in the name of "simplifying" is a big mistake in my opinion. On Tue, Jan 18, 2011 at 10:37 PM, Kent Quirk (Q Linden) wrote: > It's not gonna be a debug setting. The information's available to put it on a HUD if you care. ?We're pulling the feature and simplifying the viewer. > > On Jan 18, 2011, at 4:35 PM, Liny Odell wrote: > >> Make that +2 for a debug setting >> >> On Tue, Jan 18, 2011 at 1:27 PM, Trilo Byte wrote: >>> +1 for making it a debug setting (to choose whether you see notifications). >>> >>> The server version info would still be available in Help -> About as well as >>> World -> Place Profile -> Region/Estate >>> On Jan 18, 2011, at 11:39 AM, Erin Mallory wrote: >>> >>> could even bury the option in the debug console... most people that would >>> need to turn it on would not likely keep flipping it I would think... >>> >>> ________________________________ >>> Date: Tue, 18 Jan 2011 11:32:53 -0800 >>> From: oskar at lindenlab.com >>> To: opensource-dev at lists.secondlife.com >>> Subject: Re: [opensource-dev] STORM-243 - simulator version notifications >>> >>> It does have use for people testing server. I'd say make it optional, more >>> informative, and disabled by default. >>> >>> __Oskar >>> >>> On Tue, Jan 18, 2011 at 11:22 AM, Erin >>> Mallory wrote: >>> >>> to rephrase, yes I like them, thought i'd rather see them on the chat >>> history and have more detailed. ?but i can live without them if the majority >>> really want to see them gone altogether. ?for me it helps me during certain >>> testing and stuff to know when ive changed server versions but that's really >>> about it. >>> >>> ________________________________ >>> From: angel_of_crimson at hotmail.com >>> To: missannotoole at yahoo.com; q at lindenlab.com; opensource-dev at lists.secondlife.com >>> Date: Tue, 18 Jan 2011 12:04:09 -0500 >>> Subject: Re: [opensource-dev] STORM-243 - simulator version notifications >>> >>> I would also like to see the toast moved. ?it can be useful and would be >>> more useful if it had the actual version. ?but i would like to see it on the >>> chat history instead. ?in fact... it would be nice to have an option to have >>> ALL remaining system notifications be optionally shown in chat history >>> instead of as toasts. ?for one thing it would log better i think, for >>> another... ?well toasts bother a rather significant portion of sl. ? those >>> with some forms of epilepsy, migraines, some forms of add... to name a >>> few... >>> >>> Erin/aka Cummere >>> >>> ________________________________ >>> Date: Tue, 18 Jan 2011 08:35:01 -0800 >>> From: missannotoole at yahoo.com >>> To: q at lindenlab.com; opensource-dev at lists.secondlife.com >>> Subject: Re: [opensource-dev] STORM-243 - simulator version notifications >>> >>> Doesn't it add some minor overhead to region crossings? I don't care about >>> it. The message does not say what server version you just entered so it is >>> mostly an annoyance. If I need version info I know where it is. >>> >>> What I would like to see is region rating and a single letter server version >>> code on the map without having to mouse float. >>> >>> ________________________________ >>> From: Kent Quirk (Q Linden) >>> >>> Hi, folks. I've just commented on STORM-243, which requests that we have Yet >>> Another Option to allow suppression of the toast that tells you the >>> simulator version changed when you changed to a new region. >>> >>> I think we should delete it entirely. Does anyone care to still get that >>> notification, now that there are usually 3 different simulator versions live >>> on the grid at any time? I don't mean "I can think of an obscure scenario >>> when someone might care." I mean does anyone really need a notification >>> about this, or can we just delete it? >>> >>> >>> >>> _______________________________________________ Policies and (un)subscribe >>> information available >>> here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the >>> policies before posting to keep unmoderated posting privileges >>> _______________________________________________ Policies 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 > > _______________________________________________ > Policies 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 liny.odell at phoenixviewer.com Tue Jan 18 13:58:02 2011 From: liny.odell at phoenixviewer.com (Liny Odell) Date: Tue, 18 Jan 2011 13:58:02 -0800 Subject: [opensource-dev] STORM-243 - simulator version notifications In-Reply-To: References: <5941ED4A-7D5D-4008-9FC9-A68B33EF2A44@lindenlab.com> <226473.53614.qm@web120517.mail.ne1.yahoo.com> <6E2D0388-BD03-4BB7-ADD1-4D3DCEA01FDB@gmail.com> Message-ID: So LL is wanting those that want to know that they have enterd a region running a different sim version to wear an object with yet another script on their av? I have two words to say about that :"script limits", and I'm going to leave it at that (there is already enough discussion about it elsewhere). On Tue, Jan 18, 2011 at 1:49 PM, Erin Mallory wrote: > I can live with that. I got much more important features /design issues to > fight over.? :) > > >> From: q at lindenlab.com >> Date: Tue, 18 Jan 2011 16:37:34 -0500 >> To: liny.odell at phoenixviewer.com >> CC: opensource-dev at lists.secondlife.com >> Subject: Re: [opensource-dev] STORM-243 - simulator version notifications >> >> It's not gonna be a debug setting. The information's available to put it >> on a HUD if you care. We're pulling the feature and simplifying the viewer. >> >> On Jan 18, 2011, at 4:35 PM, Liny Odell wrote: >> >> > Make that +2 for a debug setting >> > >> > On Tue, Jan 18, 2011 at 1:27 PM, Trilo Byte >> > wrote: >> >> +1 for making it a debug setting (to choose whether you see >> >> notifications). >> >> >> >> The server version info would still be available in Help -> About as >> >> well as >> >> World -> Place Profile -> Region/Estate >> >> On Jan 18, 2011, at 11:39 AM, Erin Mallory wrote: >> >> >> >> could even bury the option in the debug console... most people that >> >> would >> >> need to turn it on would not likely keep flipping it I would think... >> >> >> >> ________________________________ >> >> Date: Tue, 18 Jan 2011 11:32:53 -0800 >> >> From: oskar at lindenlab.com >> >> To: opensource-dev at lists.secondlife.com >> >> Subject: Re: [opensource-dev] STORM-243 - simulator version >> >> notifications >> >> >> >> It does have use for people testing server. I'd say make it optional, >> >> more >> >> informative, and disabled by default. >> >> >> >> __Oskar >> >> >> >> On Tue, Jan 18, 2011 at 11:22 AM, Erin >> >> Mallory wrote: >> >> >> >> to rephrase, yes I like them, thought i'd rather see them on the chat >> >> history and have more detailed. but i can live without them if the >> >> majority >> >> really want to see them gone altogether. for me it helps me during >> >> certain >> >> testing and stuff to know when ive changed server versions but that's >> >> really >> >> about it. >> >> >> >> ________________________________ >> >> From: angel_of_crimson at hotmail.com >> >> To: missannotoole at yahoo.com; q at lindenlab.com; >> >> opensource-dev at lists.secondlife.com >> >> Date: Tue, 18 Jan 2011 12:04:09 -0500 >> >> Subject: Re: [opensource-dev] STORM-243 - simulator version >> >> notifications >> >> >> >> I would also like to see the toast moved. it can be useful and would be >> >> more useful if it had the actual version. but i would like to see it on >> >> the >> >> chat history instead. in fact... it would be nice to have an option to >> >> have >> >> ALL remaining system notifications be optionally shown in chat history >> >> instead of as toasts. for one thing it would log better i think, for >> >> another... well toasts bother a rather significant portion of sl. those >> >> with some forms of epilepsy, migraines, some forms of add... to name a >> >> few... >> >> >> >> Erin/aka Cummere >> >> >> >> ________________________________ >> >> Date: Tue, 18 Jan 2011 08:35:01 -0800 >> >> From: missannotoole at yahoo.com >> >> To: q at lindenlab.com; opensource-dev at lists.secondlife.com >> >> Subject: Re: [opensource-dev] STORM-243 - simulator version >> >> notifications >> >> >> >> Doesn't it add some minor overhead to region crossings? I don't care >> >> about >> >> it. The message does not say what server version you just entered so it >> >> is >> >> mostly an annoyance. If I need version info I know where it is. >> >> >> >> What I would like to see is region rating and a single letter server >> >> version >> >> code on the map without having to mouse float. >> >> >> >> ________________________________ >> >> From: Kent Quirk (Q Linden) >> >> >> >> Hi, folks. I've just commented on STORM-243, which requests that we >> >> have Yet >> >> Another Option to allow suppression of the toast that tells you the >> >> simulator version changed when you changed to a new region. >> >> >> >> I think we should delete it entirely. Does anyone care to still get >> >> that >> >> notification, now that there are usually 3 different simulator versions >> >> live >> >> on the grid at any time? I don't mean "I can think of an obscure >> >> scenario >> >> when someone might care." I mean does anyone really need a notification >> >> about this, or can we just delete it? >> >> >> >> >> >> >> >> _______________________________________________ Policies and >> >> (un)subscribe >> >> information available >> >> here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the >> >> policies before posting to keep unmoderated posting privileges >> >> _______________________________________________ Policies 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 >> >> _______________________________________________ >> Policies 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 esbee at lindenlab.com Tue Jan 18 13:58:41 2011 From: esbee at lindenlab.com (Sarah (Esbee) Kuehnle) Date: Tue, 18 Jan 2011 16:58:41 -0500 Subject: [opensource-dev] STORM-243 - simulator version notifications In-Reply-To: References: <5941ED4A-7D5D-4008-9FC9-A68B33EF2A44@lindenlab.com> <226473.53614.qm@web120517.mail.ne1.yahoo.com> <6E2D0388-BD03-4BB7-ADD1-4D3DCEA01FDB@gmail.com> Message-ID: The data is available via LSL - llGetEnv(). If you think about it, it makes much more sense for this to be a HUD for Residents who are interested in the information. For casual Second Life users, this information creates additional notification pop-ups and create confusion for people who don't know or care that the regions they enter are running different server versions. This is not a feature belongs in the Viewer. If there's more data you want out of llGetEnv(), I'd suggest filing an SVC feature request. --Esbee On Tue, Jan 18, 2011 at 4:49 PM, Erin Mallory wrote: > I can live with that. I got much more important features /design issues to > fight over. :) > > > > From: q at lindenlab.com > > Date: Tue, 18 Jan 2011 16:37:34 -0500 > > To: liny.odell at phoenixviewer.com > > CC: opensource-dev at lists.secondlife.com > > > Subject: Re: [opensource-dev] STORM-243 - simulator version notifications > > > > It's not gonna be a debug setting. The information's available to put it > on a HUD if you care. We're pulling the feature and simplifying the viewer. > > > > On Jan 18, 2011, at 4:35 PM, Liny Odell wrote: > > > > > Make that +2 for a debug setting > > > > > > On Tue, Jan 18, 2011 at 1:27 PM, Trilo Byte > wrote: > > >> +1 for making it a debug setting (to choose whether you see > notifications). > > >> > > >> The server version info would still be available in Help -> About as > well as > > >> World -> Place Profile -> Region/Estate > > >> On Jan 18, 2011, at 11:39 AM, Erin Mallory wrote: > > >> > > >> could even bury the option in the debug console... most people that > would > > >> need to turn it on would not likely keep flipping it I would think... > > >> > > >> ________________________________ > > >> Date: Tue, 18 Jan 2011 11:32:53 -0800 > > >> From: oskar at lindenlab.com > > >> To: opensource-dev at lists.secondlife.com > > >> Subject: Re: [opensource-dev] STORM-243 - simulator version > notifications > > >> > > >> It does have use for people testing server. I'd say make it optional, > more > > >> informative, and disabled by default. > > >> > > >> __Oskar > > >> > > >> On Tue, Jan 18, 2011 at 11:22 AM, Erin > > >> Mallory wrote: > > >> > > >> to rephrase, yes I like them, thought i'd rather see them on the chat > > >> history and have more detailed. but i can live without them if the > majority > > >> really want to see them gone altogether. for me it helps me during > certain > > >> testing and stuff to know when ive changed server versions but that's > really > > >> about it. > > >> > > >> ________________________________ > > >> From: angel_of_crimson at hotmail.com > > >> To: missannotoole at yahoo.com; q at lindenlab.com; > opensource-dev at lists.secondlife.com > > >> Date: Tue, 18 Jan 2011 12:04:09 -0500 > > >> Subject: Re: [opensource-dev] STORM-243 - simulator version > notifications > > >> > > >> I would also like to see the toast moved. it can be useful and would > be > > >> more useful if it had the actual version. but i would like to see it > on the > > >> chat history instead. in fact... it would be nice to have an option to > have > > >> ALL remaining system notifications be optionally shown in chat history > > >> instead of as toasts. for one thing it would log better i think, for > > >> another... well toasts bother a rather significant portion of sl. > those > > >> with some forms of epilepsy, migraines, some forms of add... to name a > > >> few... > > >> > > >> Erin/aka Cummere > > >> > > >> ________________________________ > > >> Date: Tue, 18 Jan 2011 08:35:01 -0800 > > >> From: missannotoole at yahoo.com > > >> To: q at lindenlab.com; opensource-dev at lists.secondlife.com > > >> Subject: Re: [opensource-dev] STORM-243 - simulator version > notifications > > >> > > >> Doesn't it add some minor overhead to region crossings? I don't care > about > > >> it. The message does not say what server version you just entered so > it is > > >> mostly an annoyance. If I need version info I know where it is. > > >> > > >> What I would like to see is region rating and a single letter server > version > > >> code on the map without having to mouse float. > > >> > > >> ________________________________ > > >> From: Kent Quirk (Q Linden) > > >> > > >> Hi, folks. I've just commented on STORM-243, which requests that we > have Yet > > >> Another Option to allow suppression of the toast that tells you the > > >> simulator version changed when you changed to a new region. > > >> > > >> I think we should delete it entirely. Does anyone care to still get > that > > >> notification, now that there are usually 3 different simulator > versions live > > >> on the grid at any time? I don't mean "I can think of an obscure > scenario > > >> when someone might care." I mean does anyone really need a > notification > > >> about this, or can we just delete it? > > >> > > >> > > >> > > >> _______________________________________________ Policies and > (un)subscribe > > >> information available > > >> here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the > > >> policies before posting to keep unmoderated posting privileges > > >> _______________________________________________ Policies 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 > > > > _______________________________________________ > > Policies 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/20110118/439c0faa/attachment-0001.htm From latifer at streamgrid.net Tue Jan 18 14:11:28 2011 From: latifer at streamgrid.net (Latif Khalifa) Date: Tue, 18 Jan 2011 23:11:28 +0100 Subject: [opensource-dev] STORM-243 - simulator version notifications In-Reply-To: References: <5941ED4A-7D5D-4008-9FC9-A68B33EF2A44@lindenlab.com> <226473.53614.qm@web120517.mail.ne1.yahoo.com> <6E2D0388-BD03-4BB7-ADD1-4D3DCEA01FDB@gmail.com> Message-ID: Making the server version notifications feature disabled by default, but keeping the option to enable it with more debug info in it accomplishes the both sides nicely. It doesn't confuse the casual user and it helps a pro make SL better. Removing stuff just for the sake of simplicity, without considering other criteria, is counter productive. You could remove "confusing" statistics panel (ctrl-shift-1) next? After all the "casual Second Life user" ?must be mystified with it (and LSL can tell you time dilation just fine). How about all the fast timers/texture console, etc etc. Again, instrumentation of the viewer for debugging is one of its strengths. On Tue, Jan 18, 2011 at 10:58 PM, Sarah (Esbee) Kuehnle wrote: > The data is available via LSL - llGetEnv(). If you think about it, it makes > much more sense for this to be a HUD for Residents who are interested in the > information. For casual Second Life users, this information creates > additional notification pop-ups and create confusion for people who don't > know or care that the regions they enter are running different server > versions. > > This is not a feature belongs in the Viewer. If there's more data you want > out of llGetEnv(), I'd suggest filing an SVC feature request. > > --Esbee > > > On Tue, Jan 18, 2011 at 4:49 PM, Erin Mallory > wrote: >> >> I can live with that. I got much more important features /design issues to >> fight over.? :) >> >> >> > From: q at lindenlab.com >> > Date: Tue, 18 Jan 2011 16:37:34 -0500 >> > To: liny.odell at phoenixviewer.com >> > CC: opensource-dev at lists.secondlife.com >> > Subject: Re: [opensource-dev] STORM-243 - simulator version >> > notifications >> > >> > It's not gonna be a debug setting. The information's available to put it >> > on a HUD if you care. We're pulling the feature and simplifying the viewer. >> > >> > On Jan 18, 2011, at 4:35 PM, Liny Odell wrote: >> > >> > > Make that +2 for a debug setting >> > > >> > > On Tue, Jan 18, 2011 at 1:27 PM, Trilo Byte >> > > wrote: >> > >> +1 for making it a debug setting (to choose whether you see >> > >> notifications). >> > >> >> > >> The server version info would still be available in Help -> About as >> > >> well as >> > >> World -> Place Profile -> Region/Estate >> > >> On Jan 18, 2011, at 11:39 AM, Erin Mallory wrote: >> > >> >> > >> could even bury the option in the debug console... most people that >> > >> would >> > >> need to turn it on would not likely keep flipping it I would think... >> > >> >> > >> ________________________________ >> > >> Date: Tue, 18 Jan 2011 11:32:53 -0800 >> > >> From: oskar at lindenlab.com >> > >> To: opensource-dev at lists.secondlife.com >> > >> Subject: Re: [opensource-dev] STORM-243 - simulator version >> > >> notifications >> > >> >> > >> It does have use for people testing server. I'd say make it optional, >> > >> more >> > >> informative, and disabled by default. >> > >> >> > >> __Oskar >> > >> >> > >> On Tue, Jan 18, 2011 at 11:22 AM, Erin >> > >> Mallory wrote: >> > >> >> > >> to rephrase, yes I like them, thought i'd rather see them on the chat >> > >> history and have more detailed. but i can live without them if the >> > >> majority >> > >> really want to see them gone altogether. for me it helps me during >> > >> certain >> > >> testing and stuff to know when ive changed server versions but that's >> > >> really >> > >> about it. >> > >> >> > >> ________________________________ >> > >> From: angel_of_crimson at hotmail.com >> > >> To: missannotoole at yahoo.com; q at lindenlab.com; >> > >> opensource-dev at lists.secondlife.com >> > >> Date: Tue, 18 Jan 2011 12:04:09 -0500 >> > >> Subject: Re: [opensource-dev] STORM-243 - simulator version >> > >> notifications >> > >> >> > >> I would also like to see the toast moved. it can be useful and would >> > >> be >> > >> more useful if it had the actual version. but i would like to see it >> > >> on the >> > >> chat history instead. in fact... it would be nice to have an option >> > >> to have >> > >> ALL remaining system notifications be optionally shown in chat >> > >> history >> > >> instead of as toasts. for one thing it would log better i think, for >> > >> another... well toasts bother a rather significant portion of sl. >> > >> those >> > >> with some forms of epilepsy, migraines, some forms of add... to name >> > >> a >> > >> few... >> > >> >> > >> Erin/aka Cummere >> > >> >> > >> ________________________________ >> > >> Date: Tue, 18 Jan 2011 08:35:01 -0800 >> > >> From: missannotoole at yahoo.com >> > >> To: q at lindenlab.com; opensource-dev at lists.secondlife.com >> > >> Subject: Re: [opensource-dev] STORM-243 - simulator version >> > >> notifications >> > >> >> > >> Doesn't it add some minor overhead to region crossings? I don't care >> > >> about >> > >> it. The message does not say what server version you just entered so >> > >> it is >> > >> mostly an annoyance. If I need version info I know where it is. >> > >> >> > >> What I would like to see is region rating and a single letter server >> > >> version >> > >> code on the map without having to mouse float. >> > >> >> > >> ________________________________ >> > >> From: Kent Quirk (Q Linden) >> > >> >> > >> Hi, folks. I've just commented on STORM-243, which requests that we >> > >> have Yet >> > >> Another Option to allow suppression of the toast that tells you the >> > >> simulator version changed when you changed to a new region. >> > >> >> > >> I think we should delete it entirely. Does anyone care to still get >> > >> that >> > >> notification, now that there are usually 3 different simulator >> > >> versions live >> > >> on the grid at any time? I don't mean "I can think of an obscure >> > >> scenario >> > >> when someone might care." I mean does anyone really need a >> > >> notification >> > >> about this, or can we just delete it? >> > >> >> > >> >> > >> >> > >> _______________________________________________ Policies and >> > >> (un)subscribe >> > >> information available >> > >> here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the >> > >> policies before posting to keep unmoderated posting privileges >> > >> _______________________________________________ Policies 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 >> > >> > _______________________________________________ >> > Policies 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 nickyperian at yahoo.com Tue Jan 18 14:22:48 2011 From: nickyperian at yahoo.com (Nicky Perian) Date: Tue, 18 Jan 2011 14:22:48 -0800 (PST) Subject: [opensource-dev] VS 2010 Express Build of Imprudence 1.4.0 Message-ID: <84046.39887.qm@web43502.mail.sp1.yahoo.com> Cross posting to IMPDEV and SLDEV lists. Visual Studio Express 2010 build of Imprudence 1.4.0 is branched as impvc100 at git at github.com:NickyPerian/imprudence.git . To complete the build cmake needs to be at version 2.8.1. Kitware corrected a bug related to VS2010 at 2.8.1 and it came back in the current versions but, is due to be fixed in version 2,8.4. The VS 2010 versions of libraries are in the downloads area of my public github account. Boost 1.45 libraries and the includes with ticket 4073 patch applied to function_template.hpp. File boost_1_45_VC100_libs_inc_patch4073.tar.bz2 json libraries and include with json_vc10.lib and json_vc10d.lib. File jsonlib_VC100_libs_inc.tar.bz2 QT web kit 4.7.1 with llqtwebkit.lib and llqtwebkitd.lib. File llqtwebkit-windows-qt4.7.1-20110117.tar.bz2 File llqtwebkit-windows-qt4.7.1-20110117.tar.bz2.md5sum On the VS2010 release configuration the Properties->Linker->Debugging->Map File Name has a ?:? in front of Release. This colon needs removed as it is carried though to a path that fails at link time. Directories are set in the Properties Manager in VS2010. That is activated by the third icon over from the bottom just below the Solutions Manager window. By default $(ExecutablePath) is placed after the custom directories entries. If there is an easy way to change it to before the entries I could not find it So, I resorted to an edit of the line and moved $(ExecutablePath) to the beginning. This was to work around \cygwin\bin\link from running ahead of VS2010 link. At this writing January 18, 2011 the llmediaplugintest project doesn't build. The viewer doesn't need it. Workaround is remove it from building in the configuration manager. To Do. Get test apps in llqtwebkit instructions to build under 2010. Take lessons from above and get llmediaplugintest to build. Common factor beings glui32.lib and freeglut_static.lib. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110118/865f0037/attachment.htm From hitomi.tiponi at yahoo.co.uk Tue Jan 18 15:20:19 2011 From: hitomi.tiponi at yahoo.co.uk (Hitomi Tiponi) Date: Tue, 18 Jan 2011 23:20:19 +0000 (GMT) Subject: [opensource-dev] SOCIAL-452 - new size of web profile floater In-Reply-To: References: Message-ID: <545761.5920.qm@web23904.mail.ird.yahoo.com> re: "SOCIAL-452 FIX Default size of Web content floater is wrong - needs to be optimized for Web profile display". I noticed this has been merged across to viewer-beta and am worried it is going to be deployed. If you do I think you will face a lot of annoyance over the now very large size of this floater. Really it should have been made smaller - not bigger with the width set to match the width of the outline profile. ________________________________ From: "opensource-dev-request at lists.secondlife.com" To: opensource-dev at lists.secondlife.com Sent: Wed, 19 January, 2011 2:30:57 Subject: opensource-dev Digest, Vol 12, Issue 59 Send opensource-dev mailing list submissions to opensource-dev at lists.secondlife.com To subscribe or unsubscribe via the World Wide Web, visit https://lists.secondlife.com/cgi-bin/mailman/listinfo/opensource-dev or, via email, send a message with subject or body 'help' to opensource-dev-request at lists.secondlife.com You can reach the person managing the list at opensource-dev-owner at lists.secondlife.com When replying, please edit your Subject line so it is more specific than "Re: Contents of opensource-dev digest..." Today's Topics: 1. Re: Review Request: STORM-2 As a User, I want to set my own default views with specific UI layout so I can tailor my Viewer experience to the activities I'm most interested in. (Vadim ProductEngine) 2. STORM-243 - simulator version notifications (Kent Quirk (Q Linden)) 3. Re: STORM-243 - simulator version notifications (Lance Corrimal) 4. Re: Review Request: STORM-2 As a User, I want to set my own default views with specific UI layout so I can tailor my Viewer experience to the activities I'm most interested in. (Opensource Obscure) 5. Review Request: make PREHASH variables char const* const (Boroondas Gupte) 6. Re: STORM-243 - simulator version notifications (WolfPup Lowenhar) ---------------------------------------------------------------------- Message: 1 Date: Tue, 18 Jan 2011 14:31:11 -0000 From: "Vadim ProductEngine" Subject: Re: [opensource-dev] Review Request: STORM-2 As a User, I want to set my own default views with specific UI layout so I can tailor my Viewer experience to the activities I'm most interested in. To: "Vadim ProductEngine" , "Andrew ProductEngine" , "Viewer" Message-ID: <20110118143111.25993.91253 at domU-12-31-38-00-90-68.compute-1.internal> Content-Type: text/plain; charset="utf-8" ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/98/#review181 ----------------------------------------------------------- Ship it! Looks good, given that this is a first pass implementation. - Vadim On Jan. 17, 2011, 1:24 p.m., Andrew ProductEngine wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/98/ > ----------------------------------------------------------- > > (Updated Jan. 17, 2011, 1:24 p.m.) > > > Review request for Viewer. > > > Summary > ------- > > First pass of saving of UI state into files. > > Implemeted saving of floaters and bottombar buttons state into a named layout. >This layout is saved on disk into per-user folder. The folder with layout >contains LLSD files. > > Currently the following features were implemeted: > - Saving of bottomtray buttons order and visibility. > - Saving floaters rect and visibility info (multiple instances of the same >floater are supported) > - Saving of sidetray tabs state (docked/undocked). > - UI for the feature. > > TODO: > - Add saving dock state for dockable floaters. > - Add LL-created default layouts and support for them. > - Refactor system of updating lists - get rid of ugly static dirty and it's >check in draw. > - Add saving of sidetray open/closed state, open tab, etc. > > > This addresses bug STORM-2. > http://jira.secondlife.com/browse/STORM-2 > > > Diffs > ----- > > indra/llui/llfloater.h 422f636c3343 > indra/llui/llfloaterreg.h 422f636c3343 > indra/newview/CMakeLists.txt 422f636c3343 > indra/newview/llbottomtray.h 422f636c3343 > indra/newview/llbottomtray.cpp 422f636c3343 > indra/newview/llfloaterlayouts.h PRE-CREATION > indra/newview/llfloaterlayouts.cpp PRE-CREATION > indra/newview/llsidetray.h 422f636c3343 > indra/newview/llsidetray.cpp 422f636c3343 > indra/newview/llviewerfloaterreg.cpp 422f636c3343 > indra/newview/llviewermenu.cpp 422f636c3343 > indra/newview/skins/default/xui/en/floater_layouts.xml PRE-CREATION > indra/newview/skins/default/xui/en/floater_save_layout.xml PRE-CREATION > indra/newview/skins/default/xui/en/menu_viewer.xml 422f636c3343 > indra/newview/skins/default/xui/en/notifications.xml 422f636c3343 > > Diff: http://codereview.secondlife.com/r/98/diff > > > Testing > ------- > > > Thanks, > > Andrew > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110118/ea5e4514/attachment-0001.htm ------------------------------ Message: 2 Date: Tue, 18 Jan 2011 10:22:45 -0500 From: "Kent Quirk (Q Linden)" Subject: [opensource-dev] STORM-243 - simulator version notifications To: OpenSource Mailing List Message-ID: <5941ED4A-7D5D-4008-9FC9-A68B33EF2A44 at lindenlab.com> Content-Type: text/plain; charset=us-ascii Hi, folks. I've just commented on STORM-243, which requests that we have Yet Another Option to allow suppression of the toast that tells you the simulator version changed when you changed to a new region. I think we should delete it entirely. Does anyone care to still get that notification, now that there are usually 3 different simulator versions live on the grid at any time? I don't mean "I can think of an obscure scenario when someone might care." I mean does anyone really need a notification about this, or can we just delete it? ------------------------------ Message: 3 Date: Tue, 18 Jan 2011 16:28:21 +0100 From: Lance Corrimal Subject: Re: [opensource-dev] STORM-243 - simulator version notifications To: opensource-dev at lists.secondlife.com Message-ID: <201101181628.21597.Lance.Corrimal at eregion.de> Content-Type: Text/Plain; charset="iso-8859-1" Am Dienstag, 18. Januar 2011, 16:22:45 schrieb Kent Quirk (Q Linden): > Hi, folks. I've just commented on STORM-243, which requests that we have > Yet Another Option to allow suppression of the toast that tells you the > simulator version changed when you changed to a new region. > > I think we should delete it entirely. Does anyone care to still get that > notification, now that there are usually 3 different simulator versions > live on the grid at any time? I don't mean "I can think of an obscure > scenario when someone might care." I mean does anyone really need a > notification about this, or can we just delete it? on the contrary, i'm trying to port a patch from henri beauchamps cool viewer that makes that notification more detailed, as in it tells you the version of the sim you entered and the version of the sim you left. bye, LC ------------------------------ Message: 4 Date: Tue, 18 Jan 2011 16:28:47 +0100 From: Opensource Obscure Subject: Re: [opensource-dev] Review Request: STORM-2 As a User, I want to set my own default views with specific UI layout so I can tailor my Viewer experience to the activities I'm most interested in. To: Vadim ProductEngine Cc: Viewer Message-ID: Content-Type: text/plain; charset=ISO-8859-1 Just to say this new feature looks very promising! A question. The 3rd note says "the files associated with saved layouts will be LLSD text files, so you can email or paste layouts into a notecard to share with other users". (the note also explains why this is not the ideal behaviour ever, and also why we have to deal with it for now) This sounds even cooler! ...but - how would that process of sharing LLSD files exactly work? I mean, where will users have to put those LLSD files? here is the scenario I'm thinking about: - a "teacher" (or mentor, friend, etc) is explaining to a new user how to build in SL - the teacher shares with the new user an LLSD file that contains an ideal layout for building, and says "put this in your SL folder" - the new user is now confused: many newbies don't know the difference between the software folder and the settings folder, and they don't know where those are; this gets even worst to solve for people trying to help them, because pathnames are different across different operating systems, across different releases of the same o.s. - or because of localization. possible solutions: - add another option in Preferences to choose the folder where we keep layouts - add a menu command to choose a specific layout file - then the viewer would copy that file into the actual settings folder. Opensource Obscure ------------------------------ Message: 5 Date: Tue, 18 Jan 2011 15:29:44 -0000 From: "Boroondas Gupte" Subject: [opensource-dev] Review Request: make PREHASH variables char const* const To: "Viewer" , "Boroondas Gupte" Message-ID: <20110118152944.26007.14045 at domU-12-31-38-00-90-68.compute-1.internal> Content-Type: text/plain; charset="utf-8" ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/100/ ----------------------------------------------------------- Review request for Viewer. Summary ------- For the reason for this change, see https://jira.secondlife.com/browse/VWR-24487 and https://jira.secondlife.com/browse/VWR-24522 What I did: In indra/llmessage/message_prehash.(h|cpp), I turned everything into constant pointers to constants by search/replace. Then I tried to compile and added const qualifiers in dependent code as needed to stop the compiler complaining. Note that comments in indra/llmessage/message_prehash.(h|cpp) say these files have been generated from the message template. If this generation wasn't a one-off thing, the generating code must be changed, too, so it won't override this change here when the generation happens the next time. This addresses bug VWR-24487. http://jira.secondlife.com/browse/VWR-24487 Diffs ----- doc/contributions.txt fc7e5dcf3059 indra/llmessage/message_prehash.h fc7e5dcf3059 indra/llmessage/message_prehash.cpp fc7e5dcf3059 indra/llprimitive/llprimitive.h fc7e5dcf3059 indra/llprimitive/llprimitive.cpp fc7e5dcf3059 indra/llprimitive/llvolumemessage.h fc7e5dcf3059 indra/llprimitive/llvolumemessage.cpp fc7e5dcf3059 indra/llui/tests/llurlentry_stub.cpp fc7e5dcf3059 indra/newview/tests/llremoteparcelrequest_test.cpp fc7e5dcf3059 Diff: http://codereview.secondlife.com/r/100/diff Testing ------- Compiled (standalone, 64bit Linux) with and without LL_TESTS. Started the viewer, logged in, walked and flew around a bit. Everything seems to work. Thanks, Boroondas -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110118/f2a2a883/attachment-0001.htm ------------------------------ Message: 6 Date: Tue, 18 Jan 2011 10:30:52 -0500 From: "WolfPup Lowenhar" Subject: Re: [opensource-dev] STORM-243 - simulator version notifications To: "OpenSource Mailing List" Message-ID: <000f01cbb724$b13cd250$13b676f0$@net> Content-Type: text/plain; charset="us-ascii" Q, I believe the jira in question was wanting to suppress the popup but not the notification itself so that it would still show up in chat history if you were logging it or kept your chat history open all the time. From: opensource-dev-bounces at lists.secondlife.com [mailto:opensource-dev-bounces at lists.secondlife.com] On Behalf Of Kent Quirk (Q Linden) Sent: Tuesday, January 18, 2011 10:23 AM To: OpenSource Mailing List Subject: [opensource-dev] STORM-243 - simulator version notifications Hi, folks. I've just commented on STORM-243, which requests that we have Yet Another Option to allow suppression of the toast that tells you the simulator version changed when you changed to a new region. I think we should delete it entirely. Does anyone care to still get that notification, now that there are usually 3 different simulator versions live on the grid at any time? I don't mean "I can think of an obscure scenario when someone might care." I mean does anyone really need a notification about this, or can we just delete it? _______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges _____ No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1191 / Virus Database: 1435/3387 - Release Date: 01/17/11 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110118/3fc61156/attachment.htm ------------------------------ _______________________________________________ opensource-dev mailing list opensource-dev at lists.secondlife.com https://lists.secondlife.com/cgi-bin/mailman/listinfo/opensource-dev End of opensource-dev Digest, Vol 12, Issue 59 ********************************************** -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110118/a704172b/attachment-0001.htm From hitomi.tiponi at yahoo.co.uk Tue Jan 18 15:23:40 2011 From: hitomi.tiponi at yahoo.co.uk (Hitomi Tiponi) Date: Tue, 18 Jan 2011 23:23:40 +0000 (GMT) Subject: [opensource-dev] SOCIAL-452 In-Reply-To: References: Message-ID: <179076.41972.qm@web23901.mail.ird.yahoo.com> oops - apologies for adding on the entire opensource-dev mail in my last message. Forgot to cut it out. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110118/86d178c9/attachment.htm From kadah.coba at gmail.com Tue Jan 18 16:07:35 2011 From: kadah.coba at gmail.com (Kadah) Date: Tue, 18 Jan 2011 16:07:35 -0800 Subject: [opensource-dev] Link times In-Reply-To: References: Message-ID: <4D362B47.4010905@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On windows I found that raiding 2 SSDs drops link times to negligible levels for full links on 2.4, <1 minute. Normally my links are well over 20 minutes on the same system running compile from disk based raid10. On 1/14/2011 9:04 AM, Jonathan Welch wrote: > I just did a quick study on link times for various viewers on my 2Gb XP system > > Viewer 1st link 2nd link > CV 1.22 0:53 0:24 > SG 1.5 3:30 2:07 > V2.5 6:18 6:01 > > I watched my memory usage during the V2.5 link and did not see it get > to an extremely low value. > > The sizes of the .exe files are all pretty similar. > > Does anyone have a recommendation on how to improve my link times? > 1) Add 1Gb of memory (not clear if this would help, but it would be a > cheap experiment) > 2) ? > > -Jonathan > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting privileges -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJNNitHAAoJEIdLfPRu7qE2AOQH/0gDJoE3nEwQwkLQij7gTQAd tahlsXfY/iBKPJNxNVqbfEmLQmhqh94CVHvMkIC5jyKTzHVHxRcGDrIGG6J8ngRr tRXhd06P+7xFk+Pw0EUonNPzX/pBctPMQlxaETSwdzyguqujtfyzCiMX69Ag27h1 X1vDoyZaz2IlaGIS9tdBruG7W6xLpSipDT1vEBkWMn0nXzGAtesfWlBKborgS7TS 65pgpGKYa4wQOuqYhwen78466Mevmd1WpMj/qc4oA3pcFRU1/7O6pFxid+uCnNgg s0yBR8zOwscJilBzy5/zlYhShv4IogBqTx4wHkkQGxVxwt2RF5oQCfx98nad0VE= =nHj3 -----END PGP SIGNATURE----- From tateru at taterunino.net Tue Jan 18 16:22:27 2011 From: tateru at taterunino.net (Tateru Nino) Date: Wed, 19 Jan 2011 11:22:27 +1100 Subject: [opensource-dev] STORM-243 - simulator version notifications In-Reply-To: References: <5941ED4A-7D5D-4008-9FC9-A68B33EF2A44@lindenlab.com> <226473.53614.qm@web120517.mail.ne1.yahoo.com> <6E2D0388-BD03-4BB7-ADD1-4D3DCEA01FDB@gmail.com> Message-ID: <4D362EC3.3040609@taterunino.net> Then can we have some sort of method by which we can turn arbitrary viewer events into popups? Or would I be wasting my time with that? On 19/01/2011 8:58 AM, Sarah (Esbee) Kuehnle wrote: > The data is available via LSL - llGetEnv() > . If you think about it, it > makes much more sense for this to be a HUD for Residents who are > interested in the information. For casual Second Life users, this > information creates additional notification pop-ups and create > confusion for people who don't know or care that the regions they > enter are running different server versions. > > This is not a feature belongs in the Viewer. If there's more data you > want out of llGetEnv(), I'd suggest filing an SVC feature request. > > --Esbee > > > On Tue, Jan 18, 2011 at 4:49 PM, Erin Mallory > > > wrote: > > I can live with that. I got much more important features /design > issues to fight over. :) > > > > From: q at lindenlab.com > > Date: Tue, 18 Jan 2011 16:37:34 -0500 > > To: liny.odell at phoenixviewer.com > > > CC: opensource-dev at lists.secondlife.com > > > > Subject: Re: [opensource-dev] STORM-243 - simulator version > notifications > > > > It's not gonna be a debug setting. The information's available > to put it on a HUD if you care. We're pulling the feature and > simplifying the viewer. > > > > On Jan 18, 2011, at 4:35 PM, Liny Odell wrote: > > > > > Make that +2 for a debug setting > > > > > > On Tue, Jan 18, 2011 at 1:27 PM, Trilo Byte > > wrote: > > >> +1 for making it a debug setting (to choose whether you see > notifications). > > >> > > >> The server version info would still be available in Help -> > About as well as > > >> World -> Place Profile -> Region/Estate > > >> On Jan 18, 2011, at 11:39 AM, Erin Mallory wrote: > > >> > > >> could even bury the option in the debug console... most > people that would > > >> need to turn it on would not likely keep flipping it I would > think... > > >> > > >> ________________________________ > > >> Date: Tue, 18 Jan 2011 11:32:53 -0800 > > >> From: oskar at lindenlab.com > > >> To: opensource-dev at lists.secondlife.com > > > >> Subject: Re: [opensource-dev] STORM-243 - simulator version > notifications > > >> > > >> It does have use for people testing server. I'd say make it > optional, more > > >> informative, and disabled by default. > > >> > > >> __Oskar > > >> > > >> On Tue, Jan 18, 2011 at 11:22 AM, Erin > > >> Mallory > wrote: > > >> > > >> to rephrase, yes I like them, thought i'd rather see them on > the chat > > >> history and have more detailed. but i can live without them > if the majority > > >> really want to see them gone altogether. for me it helps me > during certain > > >> testing and stuff to know when ive changed server versions > but that's really > > >> about it. > > >> > > >> ________________________________ > > >> From: angel_of_crimson at hotmail.com > > > >> To: missannotoole at yahoo.com ; > q at lindenlab.com ; > opensource-dev at lists.secondlife.com > > > >> Date: Tue, 18 Jan 2011 12:04:09 -0500 > > >> Subject: Re: [opensource-dev] STORM-243 - simulator version > notifications > > >> > > >> I would also like to see the toast moved. it can be useful > and would be > > >> more useful if it had the actual version. but i would like to > see it on the > > >> chat history instead. in fact... it would be nice to have an > option to have > > >> ALL remaining system notifications be optionally shown in > chat history > > >> instead of as toasts. for one thing it would log better i > think, for > > >> another... well toasts bother a rather significant portion of > sl. those > > >> with some forms of epilepsy, migraines, some forms of add... > to name a > > >> few... > > >> > > >> Erin/aka Cummere > > >> > > >> ________________________________ > > >> Date: Tue, 18 Jan 2011 08:35:01 -0800 > > >> From: missannotoole at yahoo.com > > >> To: q at lindenlab.com ; > opensource-dev at lists.secondlife.com > > > >> Subject: Re: [opensource-dev] STORM-243 - simulator version > notifications > > >> > > >> Doesn't it add some minor overhead to region crossings? I > don't care about > > >> it. The message does not say what server version you just > entered so it is > > >> mostly an annoyance. If I need version info I know where it is. > > >> > > >> What I would like to see is region rating and a single letter > server version > > >> code on the map without having to mouse float. > > >> > > >> ________________________________ > > >> From: Kent Quirk (Q Linden) > > > >> > > >> Hi, folks. I've just commented on STORM-243, which requests > that we have Yet > > >> Another Option to allow suppression of the toast that tells > you the > > >> simulator version changed when you changed to a new region. > > >> > > >> I think we should delete it entirely. Does anyone care to > still get that > > >> notification, now that there are usually 3 different > simulator versions live > > >> on the grid at any time? I don't mean "I can think of an > obscure scenario > > >> when someone might care." I mean does anyone really need a > notification > > >> about this, or can we just delete it? > > >> > > >> > > >> > > >> _______________________________________________ Policies and > (un)subscribe > > >> information available > > >> here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please > read the > > >> policies before posting to keep unmoderated posting privileges > > >> _______________________________________________ Policies 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 > > > > _______________________________________________ > > Policies 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/20110119/5a423f85/attachment-0001.htm From aleric.inglewood at gmail.com Tue Jan 18 17:37:21 2011 From: aleric.inglewood at gmail.com (Aleric Inglewood) Date: Wed, 19 Jan 2011 02:37:21 +0100 Subject: [opensource-dev] Link times In-Reply-To: <4D362B47.4010905@gmail.com> References: <4D362B47.4010905@gmail.com> Message-ID: I can confirm that. I'm using a RAM disk (0.08ms random access time) and that does indeed drop link time significantly (I measured 8 seconds for viewer 1, not sure how long it is for viewer 2). From carlo at alinoe.com Tue Jan 18 17:41:38 2011 From: carlo at alinoe.com (Carlo Wood) Date: Wed, 19 Jan 2011 02:41:38 +0100 Subject: [opensource-dev] STORM-243 - simulator version notifications In-Reply-To: <5941ED4A-7D5D-4008-9FC9-A68B33EF2A44@lindenlab.com> References: <5941ED4A-7D5D-4008-9FC9-A68B33EF2A44@lindenlab.com> Message-ID: <20110119014138.GA1580@alinoe.com> Delete! On Tue, Jan 18, 2011 at 10:22:45AM -0500, Kent Quirk (Q Linden) wrote: > Hi, folks. I've just commented on STORM-243, which requests that we have Yet Another Option to allow suppression of the toast that tells you the simulator version changed when you changed to a new region. > > I think we should delete it entirely. Does anyone care to still get that notification, now that there are usually 3 different simulator versions live on the grid at any time? I don't mean "I can think of an obscure scenario when someone might care." I mean does anyone really need a notification about this, or can we just delete it? > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting privileges -- Carlo Wood From Aleric.Inglewood at gmail.com Tue Jan 18 17:58:14 2011 From: Aleric.Inglewood at gmail.com (Aleric Inglewood) Date: Wed, 19 Jan 2011 01:58:14 -0000 Subject: [opensource-dev] Review Request: make PREHASH variables char const* const In-Reply-To: <20110118152944.26007.14045@domU-12-31-38-00-90-68.compute-1.internal> References: <20110118152944.26007.14045@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110119015814.25766.86058@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/100/#review196 ----------------------------------------------------------- Ship it! I love it! Thanks, this was stopped me from compiling the tests (since some commit not long ago I guess, because I could before). Just one remark. In one test _PREHASH_AgentID is set to "AgentID" (no doubt a place holder), while in the other you set it to 0 (now needed because it's a const). Perhaps a more symmetric approach is better? I'd opt for setting the other also to a random string, like "Grumpity Productengine", or "Aleric Inglewood" now I think about it. Other options are "All Your Base Are Belong To Us" and "Hi mom!". Got be SURE they aren't used though -- don't want any new 'Grumpity' embarrashments :p - Aleric On Jan. 18, 2011, 7:29 a.m., Boroondas Gupte wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/100/ > ----------------------------------------------------------- > > (Updated Jan. 18, 2011, 7:29 a.m.) > > > Review request for Viewer. > > > Summary > ------- > > For the reason for this change, see https://jira.secondlife.com/browse/VWR-24487 and https://jira.secondlife.com/browse/VWR-24522 > > What I did: > In indra/llmessage/message_prehash.(h|cpp), I turned everything into constant pointers to constants by search/replace. Then I tried to compile and added const qualifiers in dependent code as needed to stop the compiler complaining. > > Note that comments in indra/llmessage/message_prehash.(h|cpp) say these files have been generated from the message template. If this generation wasn't a one-off thing, the generating code must be changed, too, so it won't override this change here when the generation happens the next time. > > > This addresses bug VWR-24487. > http://jira.secondlife.com/browse/VWR-24487 > > > Diffs > ----- > > doc/contributions.txt fc7e5dcf3059 > indra/llmessage/message_prehash.h fc7e5dcf3059 > indra/llmessage/message_prehash.cpp fc7e5dcf3059 > indra/llprimitive/llprimitive.h fc7e5dcf3059 > indra/llprimitive/llprimitive.cpp fc7e5dcf3059 > indra/llprimitive/llvolumemessage.h fc7e5dcf3059 > indra/llprimitive/llvolumemessage.cpp fc7e5dcf3059 > indra/llui/tests/llurlentry_stub.cpp fc7e5dcf3059 > indra/newview/tests/llremoteparcelrequest_test.cpp fc7e5dcf3059 > > Diff: http://codereview.secondlife.com/r/100/diff > > > Testing > ------- > > Compiled (standalone, 64bit Linux) with and without LL_TESTS. > Started the viewer, logged in, walked and flew around a bit. Everything seems to work. > > > Thanks, > > Boroondas > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110119/2d012f21/attachment.htm From Aleric.Inglewood at gmail.com Tue Jan 18 18:08:15 2011 From: Aleric.Inglewood at gmail.com (Aleric Inglewood) Date: Wed, 19 Jan 2011 02:08:15 -0000 Subject: [opensource-dev] Review Request: VWR-24321: Validate textures starting with 00 too. In-Reply-To: <20110118200936.25759.54373@domU-12-31-38-00-90-68.compute-1.internal> References: <20110118200936.25759.54373@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110119020815.25761.14483@domU-12-31-38-00-90-68.compute-1.internal> > On Jan. 18, 2011, 12:09 p.m., Merov Linden wrote: > > indra/newview/lltexturecache.cpp, line 1595 > > > > > > validate_idx being used in a test later, it's not just for (validate_idx == 0) that the behavior will be different. I need to understand better what that idx is all about or you need to give a bit more explanation before I approve this diff. The debug setting CacheValidateCounter is set to 'next_id', which makes clear what it's meaning is: namely, the id that we will check next time. next_idx is a very local variable that is simply set to the value of CacheValidateCounter plus 1, and then that value is stored to CacheValidateCounter again for next time. validate_idx is the ID that is actually being tested this time. Hence, it should be the value of CacheValidateCounter before we increase that. Obviously, those ID's should be in the range 0...255, which is garanteed by doing a modulo 256 on next_id before writing it to CacheValidateCounter. The old code also increases validate_idx *before* it is used. That means that it will be in the range 1...256, and 0 is never tested (note that validate_idx is just increased, there is no modulo applied, so it's obvious that it shouldn't be increased). Even the wording ("next"_id) suggests that validate_idx should just be the value of CacheValidateCounter, which is the value of the previous next_id... So, after this patch, we get to the following code with validate_idx in the range 0...255, as it should be. - Aleric ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/90/#review191 ----------------------------------------------------------- On Jan. 14, 2011, 1:02 p.m., Aleric Inglewood wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/90/ > ----------------------------------------------------------- > > (Updated Jan. 14, 2011, 1:02 p.m.) > > > Review request for Viewer. > > > Summary > ------- > > Trivial patch, just removes stupidity. > > > This addresses bug VWR-24321. > http://jira.secondlife.com/browse/VWR-24321 > > > Diffs > ----- > > doc/contributions.txt b0bd26c5638a > indra/newview/lltexturecache.cpp b0bd26c5638a > > Diff: http://codereview.secondlife.com/r/90/diff > > > Testing > ------- > > > Thanks, > > Aleric > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110119/b021e179/attachment.htm From angel_of_crimson at hotmail.com Tue Jan 18 18:31:12 2011 From: angel_of_crimson at hotmail.com (Erin Mallory) Date: Tue, 18 Jan 2011 21:31:12 -0500 Subject: [opensource-dev] SOCIAL-452 In-Reply-To: <179076.41972.qm@web23901.mail.ird.yahoo.com> References: , <179076.41972.qm@web23901.mail.ird.yahoo.com> Message-ID: For what its worth i agree. the floater is too big. so is the layout on the profiles. both could be shrunk a bit to make it more usable. but what concerns me is the viewer hanging every time the web profiles are open... which i think is a viewer issue... Date: Tue, 18 Jan 2011 23:23:40 +0000 From: hitomi.tiponi at yahoo.co.uk To: opensource-dev at lists.secondlife.com Subject: Re: [opensource-dev] SOCIAL-452 oops - apologies for adding on the entire opensource-dev mail in my last message. Forgot to cut it out. _______________________________________________ Policies 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/20110118/d717a1b4/attachment-0001.htm From wolfpup67 at earthlink.net Tue Jan 18 19:22:44 2011 From: wolfpup67 at earthlink.net (WolfPup Lowenhar) Date: Tue, 18 Jan 2011 22:22:44 -0500 Subject: [opensource-dev] Storm-236 extra eyes needed.(please forgive for lenght) Message-ID: <001801cbb788$23cc2dd0$6b648970$@net> I'll apologize in advanced for length of this email but I need some extra eyes on the code for this Diff to show changes being made(also the reason for the length of email): diff --git a/indra/newview/llbottomtray.cpp b/indra/newview/llbottomtray.cpp --- a/indra/newview/llbottomtray.cpp +++ b/indra/newview/llbottomtray.cpp @@ -1528,6 +1528,7 @@ // because it resets chatbar's width according to resize logic. void LLBottomTray::initButtonsVisibility() { + setVisibleAndFitWidths(RS_BUTTON_SPEAK, gSavedSettings.getBOOL("EnableVoiceChat")); setVisibleAndFitWidths(RS_BUTTON_GESTURES, gSavedSettings.getBOOL("ShowGestureButton")); setVisibleAndFitWidths(RS_BUTTON_MOVEMENT, gSavedSettings.getBOOL("ShowMoveButton")); setVisibleAndFitWidths(RS_BUTTON_CAMERA, gSavedSettings.getBOOL("ShowCameraButton")); @@ -1540,6 +1541,7 @@ void LLBottomTray::setButtonsControlsAndListeners() { + gSavedSettings.getControl("EnableVoiceChat")->getSignal()->connect(boost::bi nd(&LLBottomTray::toggleShowButton, RS_BUTTON_SPEAK, _2)); gSavedSettings.getControl("ShowGestureButton")->getSignal()->connect(boost:: bind(&LLBottomTray::toggleShowButton, RS_BUTTON_GESTURES, _2)); gSavedSettings.getControl("ShowMoveButton")->getSignal()->connect(boost::bin d(&LLBottomTray::toggleShowButton, RS_BUTTON_MOVEMENT, _2)); gSavedSettings.getControl("ShowCameraButton")->getSignal()->connect(boost::b ind(&LLBottomTray::toggleShowButton, RS_BUTTON_CAMERA, _2)); diff --git a/indra/newview/llspeakbutton.cpp b/indra/newview/llspeakbutton.cpp --- a/indra/newview/llspeakbutton.cpp +++ b/indra/newview/llspeakbutton.cpp @@ -34,6 +34,7 @@ #include "llcallfloater.h" #include "lloutputmonitorctrl.h" #include "lltransientfloatermgr.h" +#include "llviewercontrol.h" #include "llspeakbutton.h" @@ -55,12 +56,15 @@ void LLSpeakButton::draw() { - // LLVoiceClient::getInstance() is the authoritative global source of info regarding our open-mic state, we merely reflect that state. - bool openmic = LLVoiceClient::getInstance()->getUserPTTState(); - bool voiceenabled = LLVoiceClient::getInstance()->voiceEnabled(); - mSpeakBtn->setToggleState(openmic && voiceenabled); - mOutputMonitor->setIsMuted(!voiceenabled); - LLUICtrl::draw(); + if ( gSavedSettings.getBOOL("EnableVoiceChat") ) + { + // LLVoiceClient::getInstance() is the authoritative global source of info regarding our open-mic state, we merely reflect that state. + bool openmic = LLVoiceClient::getInstance()->getUserPTTState(); + bool voiceenabled = LLVoiceClient::getInstance()->voiceEnabled(); + mSpeakBtn->setToggleState(openmic && voiceenabled); + mOutputMonitor->setIsMuted(!voiceenabled); + LLUICtrl::draw(); + } } void LLSpeakButton::setSpeakBtnEnabled(bool enabled) { diff --git a/indra/newview/skins/default/xui/en/menu_bottomtray.xml b/indra/newview/skins/default/xui/en/menu_bottomtray.xml --- a/indra/newview/skins/default/xui/en/menu_bottomtray.xml +++ b/indra/newview/skins/default/xui/en/menu_bottomtray.xml @@ -9,6 +9,17 @@ visible="false" width="128"> + + + + with the above code changed the speak button show/hide in accordance to the voice settings like it should. now for the problem: 1 when hiding the speak button(disabling voice) the space it took up is not freed(visible buttons sliding towards the text input field) this is a problem. 2 when showing the speak button(enabling voice) I get the following message in the log file: WARNING: LLToastAlertPanel::LLToastAlertPanel: Alert: Selected button cannot be shown right now. The button will be shown when there is enough space for it. Now somewhere in the related files there is a place that sets the space for the speak button and I feel that if I could locate it and make the needed changes it should solve both problems as I think the second one is tied to the fact that the space is not freed up. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110118/f42d7aa2/attachment.htm From kf6kjg at gmail.com Tue Jan 18 20:51:36 2011 From: kf6kjg at gmail.com (Cron Stardust) Date: Wed, 19 Jan 2011 04:51:36 -0000 Subject: [opensource-dev] Review Request: VWR-24321: Validate textures starting with 00 too. In-Reply-To: <20110118200936.25759.54373@domU-12-31-38-00-90-68.compute-1.internal> References: <20110118200936.25759.54373@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110119045136.25993.92953@domU-12-31-38-00-90-68.compute-1.internal> > On Jan. 18, 2011, 12:09 p.m., Merov Linden wrote: > > indra/newview/lltexturecache.cpp, line 1595 > > > > > > validate_idx being used in a test later, it's not just for (validate_idx == 0) that the behavior will be different. I need to understand better what that idx is all about or you need to give a bit more explanation before I approve this diff. > > Aleric Inglewood wrote: > The debug setting CacheValidateCounter is set to 'next_id', which makes clear what it's meaning is: namely, the id that we will check next time. next_idx is a very local variable that is simply set to the value of CacheValidateCounter plus 1, and then that value is stored to CacheValidateCounter again for next time. > > validate_idx is the ID that is actually being tested this time. Hence, it should be the value of CacheValidateCounter before we increase that. > > Obviously, those ID's should be in the range 0...255, which is garanteed by doing a modulo 256 on next_id before writing it to CacheValidateCounter. > > The old code also increases validate_idx *before* it is used. That means that it will be in the range 1...256, and 0 is never tested (note that validate_idx is just increased, there is no modulo applied, so it's obvious that it shouldn't be increased). Even the wording ("next"_id) suggests that validate_idx should just be the value of CacheValidateCounter, which is the value of the previous next_id... > > So, after this patch, we get to the following code with validate_idx in the range 0...255, as it should be. > Just double checking, as switching from pre-increment to addition can change behavior: In both cases next_idx will have the same value after this line is executed, however validate_idx will not. Prediff start state: validate_idx == 0; Prediff stop state: validate_idx == 1; next_idx == 1; Postdiff start state: validate_idx == 0; Postdiff stop state: validate_idx == 0; next_idx == 1; And another round over at the other end: Prediff start state: validate_idx == 255; Prediff stop state: validate_idx == 256; next_idx == 0; Postdiff start state: validate_idx == 255; Postdiff stop state: validate_idx == 255; next_idx == 0; So, yes, validate_idx will only have a 255 in it in this last case, however the over-all behavior has changed: validate_idx isn't being incremented at all in this line. WARNING: I have NOT looked at the rest of the diff, only at this one line. Nor do I know if validate_idx should or shouldn't be incremented by this line of code. - Cron ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/90/#review191 ----------------------------------------------------------- On Jan. 14, 2011, 1:02 p.m., Aleric Inglewood wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/90/ > ----------------------------------------------------------- > > (Updated Jan. 14, 2011, 1:02 p.m.) > > > Review request for Viewer. > > > Summary > ------- > > Trivial patch, just removes stupidity. > > > This addresses bug VWR-24321. > http://jira.secondlife.com/browse/VWR-24321 > > > Diffs > ----- > > doc/contributions.txt b0bd26c5638a > indra/newview/lltexturecache.cpp b0bd26c5638a > > Diff: http://codereview.secondlife.com/r/90/diff > > > Testing > ------- > > > Thanks, > > Aleric > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110119/c5ce404e/attachment-0001.htm From suezanne at gmail.com Tue Jan 18 21:16:44 2011 From: suezanne at gmail.com (SuezanneC Baskerville) Date: Tue, 18 Jan 2011 23:16:44 -0600 Subject: [opensource-dev] SOCIAL-452 - new size of web profile floater In-Reply-To: <545761.5920.qm@web23904.mail.ird.yahoo.com> References: <545761.5920.qm@web23904.mail.ird.yahoo.com> Message-ID: I get a permissions violation when I try to look at SOCIAL-452. On Tue, Jan 18, 2011 at 5:20 PM, Hitomi Tiponi wrote: > re: "SOCIAL-452 FIX Default size of Web content floater is wrong - needs to > be optimized for Web profile display". I noticed this has been merged > across to viewer-beta and am worried it is going to be deployed. If you do > I think you will face a lot of annoyance over the now very large size of > this floater. Really it should have been made smaller - not bigger with the > width set to match the width of the outline profile. > > ------------------------------ > *From:* "opensource-dev-request at lists.secondlife.com" < > opensource-dev-request at lists.secondlife.com> > *To:* opensource-dev at lists.secondlife.com > *Sent:* Wed, 19 January, 2011 2:30:57 > *Subject:* opensource-dev Digest, Vol 12, Issue 59 > > Send opensource-dev mailing list submissions to > opensource-dev at lists.secondlife.com > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.secondlife.com/cgi-bin/mailman/listinfo/opensource-dev > or, via email, send a message with subject or body 'help' to > opensource-dev-request at lists.secondlife.com > > You can reach the person managing the list at > opensource-dev-owner at lists.secondlife.com > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of opensource-dev digest..." > > > Today's Topics: > > 1. Re: Review Request: STORM-2 As a User, I want to set my own > default views with specific UI layout so I can tailor my Viewer > experience to the activities I'm most interested in. > (Vadim ProductEngine) > 2. STORM-243 - simulator version notifications > (Kent Quirk (Q Linden)) > 3. Re: STORM-243 - simulator version notifications (Lance Corrimal) > 4. Re: Review Request: STORM-2 As a User, I want to set my own > default views with specific UI layout so I can tailor my Viewer > experience to the activities I'm most interested in. > (Opensource Obscure) > 5. Review Request: make PREHASH variables char const* const > (Boroondas Gupte) > 6. Re: STORM-243 - simulator version notifications (WolfPup Lowenhar) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 18 Jan 2011 14:31:11 -0000 > From: "Vadim ProductEngine" > Subject: Re: [opensource-dev] Review Request: STORM-2 As a User, I > want to set my own default views with specific UI layout so I can > tailor my Viewer experience to the activities I'm most interested in. > To: "Vadim ProductEngine" , "Andrew > ProductEngine" , "Viewer" > > Message-ID: > <20110118143111.25993.91253 at domU-12-31-38-00-90-68.compute-1.internal> > Content-Type: text/plain; charset="utf-8" > > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/98/#review181 > ----------------------------------------------------------- > > Ship it! > > > Looks good, given that this is a first pass implementation. > > - Vadim > > > On Jan. 17, 2011, 1:24 p.m., Andrew ProductEngine wrote: > > > > ----------------------------------------------------------- > > This is an automatically generated e-mail. To reply, visit: > > http://codereview.secondlife.com/r/98/ > > ----------------------------------------------------------- > > > > (Updated Jan. 17, 2011, 1:24 p.m.) > > > > > > Review request for Viewer. > > > > > > Summary > > ------- > > > > First pass of saving of UI state into files. > > > > Implemeted saving of floaters and bottombar buttons state into a named > layout. This layout is saved on disk into per-user folder. The folder with > layout contains LLSD files. > > > > Currently the following features were implemeted: > > - Saving of bottomtray buttons order and visibility. > > - Saving floaters rect and visibility info (multiple instances of the > same floater are supported) > > - Saving of sidetray tabs state (docked/undocked). > > - UI for the feature. > > > > TODO: > > - Add saving dock state for dockable floaters. > > - Add LL-created default layouts and support for them. > > - Refactor system of updating lists - get rid of ugly static dirty and > it's check in draw. > > - Add saving of sidetray open/closed state, open tab, etc. > > > > > > This addresses bug STORM-2. > > http://jira.secondlife.com/browse/STORM-2 > > > > > > Diffs > > ----- > > > > indra/llui/llfloater.h 422f636c3343 > > indra/llui/llfloaterreg.h 422f636c3343 > > indra/newview/CMakeLists.txt 422f636c3343 > > indra/newview/llbottomtray.h 422f636c3343 > > indra/newview/llbottomtray.cpp 422f636c3343 > > indra/newview/llfloaterlayouts.h PRE-CREATION > > indra/newview/llfloaterlayouts.cpp PRE-CREATION > > indra/newview/llsidetray.h 422f636c3343 > > indra/newview/llsidetray.cpp 422f636c3343 > > indra/newview/llviewerfloaterreg.cpp 422f636c3343 > > indra/newview/llviewermenu.cpp 422f636c3343 > > indra/newview/skins/default/xui/en/floater_layouts.xml PRE-CREATION > > indra/newview/skins/default/xui/en/floater_save_layout.xml PRE-CREATION > > indra/newview/skins/default/xui/en/menu_viewer.xml 422f636c3343 > > indra/newview/skins/default/xui/en/notifications.xml 422f636c3343 > > > > Diff: http://codereview.secondlife.com/r/98/diff > > > > > > Testing > > ------- > > > > > > Thanks, > > > > Andrew > > > > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110118/ea5e4514/attachment-0001.htm > > ------------------------------ > > Message: 2 > Date: Tue, 18 Jan 2011 10:22:45 -0500 > From: "Kent Quirk (Q Linden)" > Subject: [opensource-dev] STORM-243 - simulator version notifications > To: OpenSource Mailing List > Message-ID: <5941ED4A-7D5D-4008-9FC9-A68B33EF2A44 at lindenlab.com> > Content-Type: text/plain; charset=us-ascii > > Hi, folks. I've just commented on STORM-243, which requests that we have > Yet Another Option to allow suppression of the toast that tells you the > simulator version changed when you changed to a new region. > > I think we should delete it entirely. Does anyone care to still get that > notification, now that there are usually 3 different simulator versions live > on the grid at any time? I don't mean "I can think of an obscure scenario > when someone might care." I mean does anyone really need a notification > about this, or can we just delete it? > > > > ------------------------------ > > Message: 3 > Date: Tue, 18 Jan 2011 16:28:21 +0100 > From: Lance Corrimal > Subject: Re: [opensource-dev] STORM-243 - simulator version > notifications > To: opensource-dev at lists.secondlife.com > Message-ID: <201101181628.21597.Lance.Corrimal at eregion.de> > Content-Type: Text/Plain; charset="iso-8859-1" > > Am Dienstag, 18. Januar 2011, 16:22:45 schrieb Kent Quirk (Q Linden): > > Hi, folks. I've just commented on STORM-243, which requests that we have > > Yet Another Option to allow suppression of the toast that tells you the > > simulator version changed when you changed to a new region. > > > > I think we should delete it entirely. Does anyone care to still get that > > notification, now that there are usually 3 different simulator versions > > live on the grid at any time? I don't mean "I can think of an obscure > > scenario when someone might care." I mean does anyone really need a > > notification about this, or can we just delete it? > > > on the contrary, i'm trying to port a patch from henri beauchamps cool > viewer > that makes that notification more detailed, as in it tells you the version > of > the sim you entered and the version of the sim you left. > > > bye, > LC > > > > ------------------------------ > > Message: 4 > Date: Tue, 18 Jan 2011 16:28:47 +0100 > From: Opensource Obscure > Subject: Re: [opensource-dev] Review Request: STORM-2 As a User, I > want to set my own default views with specific UI layout so I can > tailor my Viewer experience to the activities I'm most interested in. > To: Vadim ProductEngine > Cc: Viewer > Message-ID: > > Content-Type: text/plain; charset=ISO-8859-1 > > Just to say this new feature looks very promising! > > A question. The 3rd note says > "the files associated with saved layouts will be LLSD text files, so you > can > email or paste layouts into a notecard to share with other users". > (the note also explains why this is not the ideal behaviour ever, > and also why we have to deal with it for now) > > This sounds even cooler! ...but - how would that process of > sharing LLSD files exactly work? > I mean, where will users have to put those LLSD files? > > here is the scenario I'm thinking about: > > - a "teacher" (or mentor, friend, etc) is explaining to a new user > how to build in SL > - the teacher shares with the new user an LLSD file that contains > an ideal layout for building, and says "put this in your SL folder" > - the new user is now confused: many newbies don't know > the difference between the software folder and the settings folder, > and they don't know where those are; > this gets even worst to solve for people trying to help them, > because pathnames are different across different operating systems, > across different releases of the same o.s. - or because of localization. > > possible solutions: > - add another option in Preferences to choose the folder where we keep > layouts > - add a menu command to choose a specific layout file - then the viewer > would copy that file into the actual settings folder. > > Opensource Obscure > > > ------------------------------ > > Message: 5 > Date: Tue, 18 Jan 2011 15:29:44 -0000 > From: "Boroondas Gupte" > Subject: [opensource-dev] Review Request: make PREHASH variables char > const* const > To: "Viewer" , "Boroondas Gupte" > > Message-ID: > <20110118152944.26007.14045 at domU-12-31-38-00-90-68.compute-1.internal> > Content-Type: text/plain; charset="utf-8" > > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/100/ > ----------------------------------------------------------- > > Review request for Viewer. > > > Summary > ------- > > For the reason for this change, see > https://jira.secondlife.com/browse/VWR-24487 and > https://jira.secondlife.com/browse/VWR-24522 > > What I did: > In indra/llmessage/message_prehash.(h|cpp), I turned everything into > constant pointers to constants by search/replace. Then I tried to compile > and added const qualifiers in dependent code as needed to stop the compiler > complaining. > > Note that comments in indra/llmessage/message_prehash.(h|cpp) say these > files have been generated from the message template. If this generation > wasn't a one-off thing, the generating code must be changed, too, so it > won't override this change here when the generation happens the next time. > > > This addresses bug VWR-24487. > http://jira.secondlife.com/browse/VWR-24487 > > > Diffs > ----- > > doc/contributions.txt fc7e5dcf3059 > indra/llmessage/message_prehash.h fc7e5dcf3059 > indra/llmessage/message_prehash.cpp fc7e5dcf3059 > indra/llprimitive/llprimitive.h fc7e5dcf3059 > indra/llprimitive/llprimitive.cpp fc7e5dcf3059 > indra/llprimitive/llvolumemessage.h fc7e5dcf3059 > indra/llprimitive/llvolumemessage.cpp fc7e5dcf3059 > indra/llui/tests/llurlentry_stub.cpp fc7e5dcf3059 > indra/newview/tests/llremoteparcelrequest_test.cpp fc7e5dcf3059 > > Diff: http://codereview.secondlife.com/r/100/diff > > > Testing > ------- > > Compiled (standalone, 64bit Linux) with and without LL_TESTS. > Started the viewer, logged in, walked and flew around a bit. Everything > seems to work. > > > Thanks, > > Boroondas > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110118/f2a2a883/attachment-0001.htm > > ------------------------------ > > Message: 6 > Date: Tue, 18 Jan 2011 10:30:52 -0500 > From: "WolfPup Lowenhar" > Subject: Re: [opensource-dev] STORM-243 - simulator version > notifications > To: "OpenSource Mailing List" > Message-ID: <000f01cbb724$b13cd250$13b676f0$@net> > Content-Type: text/plain; charset="us-ascii" > > Q, > > I believe the jira in question was wanting to suppress the popup but not > the > notification itself so that it would still show up in chat history if you > were logging it or kept your chat history open all the time. > > > > From: opensource-dev-bounces at lists.secondlife.com > [mailto:opensource-dev-bounces at lists.secondlife.com] On Behalf Of Kent > Quirk > (Q Linden) > Sent: Tuesday, January 18, 2011 10:23 AM > To: OpenSource Mailing List > Subject: [opensource-dev] STORM-243 - simulator version notifications > > > > Hi, folks. I've just commented on STORM-243, which requests that we have > Yet > Another Option to allow suppression of the toast that tells you the > simulator version changed when you changed to a new region. > > I think we should delete it entirely. Does anyone care to still get that > notification, now that there are usually 3 different simulator versions > live > on the grid at any time? I don't mean "I can think of an obscure scenario > when someone might care." I mean does anyone really need a notification > about this, or can we just delete it? > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting > privileges > > _____ > > No virus found in this message. > Checked by AVG - www.avg.com > Version: 10.0.1191 / Virus Database: 1435/3387 - Release Date: 01/17/11 > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110118/3fc61156/attachment.htm > > ------------------------------ > > _______________________________________________ > opensource-dev mailing list > opensource-dev at lists.secondlife.com > https://lists.secondlife.com/cgi-bin/mailman/listinfo/opensource-dev > > > End of opensource-dev Digest, Vol 12, Issue 59 > ********************************************** > > > _______________________________________________ > Policies 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/20110118/07fde3e7/attachment-0001.htm From angel_of_crimson at hotmail.com Tue Jan 18 21:27:41 2011 From: angel_of_crimson at hotmail.com (Erin Mallory) Date: Wed, 19 Jan 2011 00:27:41 -0500 Subject: [opensource-dev] SOCIAL-452 - new size of web profile floater In-Reply-To: References: , <545761.5920.qm@web23904.mail.ird.yahoo.com>, Message-ID: thats cause social is a hidden project. Date: Tue, 18 Jan 2011 23:16:44 -0600 From: suezanne at gmail.com To: hitomi.tiponi at yahoo.co.uk CC: opensource-dev at lists.secondlife.com Subject: Re: [opensource-dev] SOCIAL-452 - new size of web profile floater I get a permissions violation when I try to look at SOCIAL-452. On Tue, Jan 18, 2011 at 5:20 PM, Hitomi Tiponi wrote: re: "SOCIAL-452 FIX Default size of Web content floater is wrong - needs to be optimized for Web profile display". I noticed this has been merged across to viewer-beta and am worried it is going to be deployed. If you do I think you will face a lot of annoyance over the now very large size of this floater. Really it should have been made smaller - not bigger with the width set to match the width of the outline profile. From: "opensource-dev-request at lists.secondlife.com" To: opensource-dev at lists.secondlife.com Sent: Wed, 19 January, 2011 2:30:57 Subject: opensource-dev Digest, Vol 12, Issue 59 Send opensource-dev mailing list submissions to opensource-dev at lists.secondlife.com To subscribe or unsubscribe via the World Wide Web, visit https://lists.secondlife.com/cgi-bin/mailman/listinfo/opensource-dev or, via email, send a message with subject or body 'help' to opensource-dev-request at lists.secondlife.com You can reach the person managing the list at opensource-dev-owner at lists.secondlife.com When replying, please edit your Subject line so it is more specific than "Re: Contents of opensource-dev digest..." Today's Topics: 1. Re: Review Request: STORM-2 As a User, I want to set my own default views with specific UI layout so I can tailor my Viewer experience to the activities I'm most interested in. (Vadim ProductEngine) 2. STORM-243 - simulator version notifications (Kent Quirk (Q Linden)) 3. Re: STORM-243 - simulator version notifications (Lance Corrimal) 4. Re: Review Request: STORM-2 As a User, I want to set my own default views with specific UI layout so I can tailor my Viewer experience to the activities I'm most interested in. (Opensource Obscure) 5. Review Request: make PREHASH variables char const* const (Boroondas Gupte) 6. Re: STORM-243 - simulator version notifications (WolfPup Lowenhar) ---------------------------------------------------------------------- Message: 1 Date: Tue, 18 Jan 2011 14:31:11 -0000 From: "Vadim ProductEngine" Subject: Re: [opensource-dev] Review Request: STORM-2 As a User, I want to set my own default views with specific UI layout so I can tailor my Viewer experience to the activities I'm most interested in. To: "Vadim ProductEngine" , "Andrew ProductEngine" , "Viewer" Message-ID: <20110118143111.25993.91253 at domU-12-31-38-00-90-68.compute-1.internal> Content-Type: text/plain; charset="utf-8" ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/98/#review181 ----------------------------------------------------------- Ship it! Looks good, given that this is a first pass implementation. - Vadim On Jan. 17, 2011, 1:24 p.m., Andrew ProductEngine wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/98/ > ----------------------------------------------------------- > > (Updated Jan. 17, 2011, 1:24 p.m.) > > > Review request for Viewer. > > > Summary > ------- > > First pass of saving of UI state into files. > > Implemeted saving of floaters and bottombar buttons state into a named layout. This layout is saved on disk into per-user folder. The folder with layout contains LLSD files. > > Currently the following features were implemeted: > - Saving of bottomtray buttons order and visibility. > - Saving floaters rect and visibility info (multiple instances of the same floater are supported) > - Saving of sidetray tabs state (docked/undocked). > - UI for the feature. > > TODO: > - Add saving dock state for dockable floaters. > - Add LL-created default layouts and support for them. > - Refactor system of updating lists - get rid of ugly static dirty and it's check in draw. > - Add saving of sidetray open/closed state, open tab, etc. > > > This addresses bug STORM-2. > http://jira.secondlife.com/browse/STORM-2 > > > Diffs > ----- > > indra/llui/llfloater.h 422f636c3343 > indra/llui/llfloaterreg.h 422f636c3343 > indra/newview/CMakeLists.txt 422f636c3343 > indra/newview/llbottomtray.h 422f636c3343 > indra/newview/llbottomtray.cpp 422f636c3343 > indra/newview/llfloaterlayouts.h PRE-CREATION > indra/newview/llfloaterlayouts.cpp PRE-CREATION > indra/newview/llsidetray.h 422f636c3343 > indra/newview/llsidetray.cpp 422f636c3343 > indra/newview/llviewerfloaterreg.cpp 422f636c3343 > indra/newview/llviewermenu.cpp 422f636c3343 > indra/newview/skins/default/xui/en/floater_layouts.xml PRE-CREATION > indra/newview/skins/default/xui/en/floater_save_layout.xml PRE-CREATION > indra/newview/skins/default/xui/en/menu_viewer.xml 422f636c3343 > indra/newview/skins/default/xui/en/notifications.xml 422f636c3343 > > Diff: http://codereview.secondlife.com/r/98/diff > > > Testing > ------- > > > Thanks, > > Andrew > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110118/ea5e4514/attachment-0001.htm ------------------------------ Message: 2 Date: Tue, 18 Jan 2011 10:22:45 -0500 From: "Kent Quirk (Q Linden)" Subject: [opensource-dev] STORM-243 - simulator version notifications To: OpenSource Mailing List Message-ID: <5941ED4A-7D5D-4008-9FC9-A68B33EF2A44 at lindenlab.com> Content-Type: text/plain; charset=us-ascii Hi, folks. I've just commented on STORM-243, which requests that we have Yet Another Option to allow suppression of the toast that tells you the simulator version changed when you changed to a new region. I think we should delete it entirely. Does anyone care to still get that notification, now that there are usually 3 different simulator versions live on the grid at any time? I don't mean "I can think of an obscure scenario when someone might care." I mean does anyone really need a notification about this, or can we just delete it? ------------------------------ Message: 3 Date: Tue, 18 Jan 2011 16:28:21 +0100 From: Lance Corrimal Subject: Re: [opensource-dev] STORM-243 - simulator version notifications To: opensource-dev at lists.secondlife.com Message-ID: <201101181628.21597.Lance.Corrimal at eregion.de> Content-Type: Text/Plain; charset="iso-8859-1" Am Dienstag, 18. Januar 2011, 16:22:45 schrieb Kent Quirk (Q Linden): > Hi, folks. I've just commented on STORM-243, which requests that we have > Yet Another Option to allow suppression of the toast that tells you the > simulator version changed when you changed to a new region. > > I think we should delete it entirely. Does anyone care to still get that > notification, now that there are usually 3 different simulator versions > live on the grid at any time? I don't mean "I can think of an obscure > scenario when someone might care." I mean does anyone really need a > notification about this, or can we just delete it? on the contrary, i'm trying to port a patch from henri beauchamps cool viewer that makes that notification more detailed, as in it tells you the version of the sim you entered and the version of the sim you left. bye, LC ------------------------------ Message: 4 Date: Tue, 18 Jan 2011 16:28:47 +0100 From: Opensource Obscure Subject: Re: [opensource-dev] Review Request: STORM-2 As a User, I want to set my own default views with specific UI layout so I can tailor my Viewer experience to the activities I'm most interested in. To: Vadim ProductEngine Cc: Viewer Message-ID: Content-Type: text/plain; charset=ISO-8859-1 Just to say this new feature looks very promising! A question. The 3rd note says "the files associated with saved layouts will be LLSD text files, so you can email or paste layouts into a notecard to share with other users". (the note also explains why this is not the ideal behaviour ever, and also why we have to deal with it for now) This sounds even cooler! ...but - how would that process of sharing LLSD files exactly work? I mean, where will users have to put those LLSD files? here is the scenario I'm thinking about: - a "teacher" (or mentor, friend, etc) is explaining to a new user how to build in SL - the teacher shares with the new user an LLSD file that contains an ideal layout for building, and says "put this in your SL folder" - the new user is now confused: many newbies don't know the difference between the software folder and the settings folder, and they don't know where those are; this gets even worst to solve for people trying to help them, because pathnames are different across different operating systems, across different releases of the same o.s. - or because of localization. possible solutions: - add another option in Preferences to choose the folder where we keep layouts - add a menu command to choose a specific layout file - then the viewer would copy that file into the actual settings folder. Opensource Obscure ------------------------------ Message: 5 Date: Tue, 18 Jan 2011 15:29:44 -0000 From: "Boroondas Gupte" Subject: [opensource-dev] Review Request: make PREHASH variables char const* const To: "Viewer" , "Boroondas Gupte" Message-ID: <20110118152944.26007.14045 at domU-12-31-38-00-90-68.compute-1.internal> Content-Type: text/plain; charset="utf-8" ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/100/ ----------------------------------------------------------- Review request for Viewer. Summary ------- For the reason for this change, see https://jira.secondlife.com/browse/VWR-24487 and https://jira.secondlife.com/browse/VWR-24522 What I did: In indra/llmessage/message_prehash.(h|cpp), I turned everything into constant pointers to constants by search/replace. Then I tried to compile and added const qualifiers in dependent code as needed to stop the compiler complaining. Note that comments in indra/llmessage/message_prehash.(h|cpp) say these files have been generated from the message template. If this generation wasn't a one-off thing, the generating code must be changed, too, so it won't override this change here when the generation happens the next time. This addresses bug VWR-24487. http://jira.secondlife.com/browse/VWR-24487 Diffs ----- doc/contributions.txt fc7e5dcf3059 indra/llmessage/message_prehash.h fc7e5dcf3059 indra/llmessage/message_prehash.cpp fc7e5dcf3059 indra/llprimitive/llprimitive.h fc7e5dcf3059 indra/llprimitive/llprimitive.cpp fc7e5dcf3059 indra/llprimitive/llvolumemessage.h fc7e5dcf3059 indra/llprimitive/llvolumemessage.cpp fc7e5dcf3059 indra/llui/tests/llurlentry_stub.cpp fc7e5dcf3059 indra/newview/tests/llremoteparcelrequest_test.cpp fc7e5dcf3059 Diff: http://codereview.secondlife.com/r/100/diff Testing ------- Compiled (standalone, 64bit Linux) with and without LL_TESTS. Started the viewer, logged in, walked and flew around a bit. Everything seems to work. Thanks, Boroondas -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110118/f2a2a883/attachment-0001.htm ------------------------------ Message: 6 Date: Tue, 18 Jan 2011 10:30:52 -0500 From: "WolfPup Lowenhar" Subject: Re: [opensource-dev] STORM-243 - simulator version notifications To: "OpenSource Mailing List" Message-ID: <000f01cbb724$b13cd250$13b676f0$@net> Content-Type: text/plain; charset="us-ascii" Q, I believe the jira in question was wanting to suppress the popup but not the notification itself so that it would still show up in chat history if you were logging it or kept your chat history open all the time. From: opensource-dev-bounces at lists.secondlife.com [mailto:opensource-dev-bounces at lists.secondlife.com] On Behalf Of Kent Quirk (Q Linden) Sent: Tuesday, January 18, 2011 10:23 AM To: OpenSource Mailing List Subject: [opensource-dev] STORM-243 - simulator version notifications Hi, folks. I've just commented on STORM-243, which requests that we have Yet Another Option to allow suppression of the toast that tells you the simulator version changed when you changed to a new region. I think we should delete it entirely. Does anyone care to still get that notification, now that there are usually 3 different simulator versions live on the grid at any time? I don't mean "I can think of an obscure scenario when someone might care." I mean does anyone really need a notification about this, or can we just delete it? _______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges _____ No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1191 / Virus Database: 1435/3387 - Release Date: 01/17/11 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110118/3fc61156/attachment.htm ------------------------------ _______________________________________________ opensource-dev mailing list opensource-dev at lists.secondlife.com https://lists.secondlife.com/cgi-bin/mailman/listinfo/opensource-dev End of opensource-dev Digest, Vol 12, Issue 59 ********************************************** _______________________________________________ Policies 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/20110119/a84e1d8f/attachment-0001.htm From Lance.Corrimal at eregion.de Tue Jan 18 23:42:28 2011 From: Lance.Corrimal at eregion.de (Lance Corrimal) Date: Wed, 19 Jan 2011 08:42:28 +0100 Subject: [opensource-dev] STORM-243 - simulator version notifications In-Reply-To: References: <5941ED4A-7D5D-4008-9FC9-A68B33EF2A44@lindenlab.com> Message-ID: <201101190842.28913.Lance.Corrimal@eregion.de> Am Dienstag, 18. Januar 2011 schrieb Kent Quirk (Q Linden): > It's not gonna be a debug setting. The information's available to > put it on a HUD if you care. We're pulling the feature and > simplifying the viewer. then how about getting rid of all the extra and superfluous information that the viewer presents that hast to be actively confirm by clicking on an OK button, without telling the user anything that he/she hasnt seen just a moment ago? like, for example, every time you get an inventory offer from a person, you first click "accept", then you get an additional popup that tells you "You have accepted ... from ..." which won't go away until you click ok. https://jira.secondlife.com/browse/STORM-323 bye, LC From stickman at gmail.com Wed Jan 19 00:20:01 2011 From: stickman at gmail.com (Stickman) Date: Wed, 19 Jan 2011 00:20:01 -0800 Subject: [opensource-dev] STORM-243 - simulator version notifications In-Reply-To: <201101190842.28913.Lance.Corrimal@eregion.de> References: <5941ED4A-7D5D-4008-9FC9-A68B33EF2A44@lindenlab.com> <201101190842.28913.Lance.Corrimal@eregion.de> Message-ID: On Tue, Jan 18, 2011 at 11:42 PM, Lance Corrimal wrote: > Am Dienstag, 18. Januar 2011 schrieb Kent Quirk (Q Linden): >> It's not gonna be a debug setting. The information's available to >> put it on a HUD if you care. ?We're pulling the feature and >> simplifying the viewer. > > then how about getting rid of all the extra and superfluous > information that the viewer presents > https://jira.secondlife.com/browse/STORM-323 This. If LL's goal is simplification, I will happily help them work towards that goal. I'll have to find another viewer that meets my needs, but at least I'll know to stop making suggestions LL would never be interested in because they don't have the goals I think they have. But right now, I don't know what LL's trying to do with the viewer. Besides bringing it up to modern tech (meshes, materials later, etc), and fixing bugs, what's LL trying to do? Is there a mission statement, a motto, a creed, or a list of goals somewhere? Stickman From opensourceobscure at gmail.com Wed Jan 19 01:46:31 2011 From: opensourceobscure at gmail.com (Opensource Obscure) Date: Wed, 19 Jan 2011 10:46:31 +0100 Subject: [opensource-dev] STORM-243 - simulator version notifications In-Reply-To: References: <5941ED4A-7D5D-4008-9FC9-A68B33EF2A44@lindenlab.com> Message-ID: On a second though, this solution (paired with the information from "About Second Life") seems good enough to me. Also, simplifying the viewer as a general approach is indeed necessary and reasonable. Opensource Obscure On Tue, Jan 18, 2011 at 21:30, Twisted Laws wrote: > > Personally I see no reason for it and a user could have a simple script they > are wearing that triggers on changed, CHANGE_REGION, that tells them the > version of the server if they are interested. > > default > { > ? on_rez(integer start_param) > ? { > ???????? llOwnerSay(llGetRegionName + " " + llGetEnv("sim_channel") + " " + > llGetEnv("sim_version")); > ? } > ?? changed(integer change) > ?? { > ????? if(change & CHANGED_REGION) > ???? { > ???????? llOwnerSay(llGetRegionName + " " + llGetEnv("sim_channel") + " " + > llGetEnv("sim_version")); > ???? } > ? } > } > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting > privileges > -- Opensource Obscure Twitter?[EN] -?Twitter?[IT] -?Blog?[IT] -?YouTube?-?Photos?-?Second Life From Lance.Corrimal at eregion.de Wed Jan 19 01:57:03 2011 From: Lance.Corrimal at eregion.de (Lance Corrimal) Date: Wed, 19 Jan 2011 10:57:03 +0100 Subject: [opensource-dev] STORM-243 - simulator version notifications In-Reply-To: References: <5941ED4A-7D5D-4008-9FC9-A68B33EF2A44@lindenlab.com> Message-ID: <201101191057.03623.Lance.Corrimal@eregion.de> I don't think that a "solution" that makes people wear more scripted attachments is a good one, especially since the viewer already HAS the information. make it a popup that is controlled by a debug option which is off by default, and make the content of the popup more useful for people that actually want to see it. bye, LC Am Mittwoch, 19. Januar 2011, 10:46:31 schrieb Opensource Obscure: > On a second though, this solution (paired with the information from > "About Second Life") seems good enough to me. > > Also, simplifying the viewer as a general approach is indeed necessary > and reasonable. > > Opensource Obscure > > On Tue, Jan 18, 2011 at 21:30, Twisted Laws wrote: > > Personally I see no reason for it and a user could have a simple script > > they are wearing that triggers on changed, CHANGE_REGION, that tells > > them the version of the server if they are interested. > > > > default > > { > > on_rez(integer start_param) > > { > > llOwnerSay(llGetRegionName + " " + llGetEnv("sim_channel") + " " > > + llGetEnv("sim_version")); > > } > > changed(integer change) > > { > > if(change & CHANGED_REGION) > > { > > llOwnerSay(llGetRegionName + " " + llGetEnv("sim_channel") + " " > > + llGetEnv("sim_version")); > > } > > } > > } > > > > > > _______________________________________________ > > Policies 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 Jan 19 02:41:16 2011 From: akanevsky at productengine.com (Anya Kanevsky) Date: Wed, 19 Jan 2011 02:41:16 -0800 Subject: [opensource-dev] Daily Scrum Summary - Tuesday, January 18 Message-ID: Past Updates Tuesday, January 18, 2011 General Notes ------------------------------ - MMOTD: Oz Team Status ------------------------------ Merov Linden ------------------------------ *PAST* - MM - STORM-863 : Using --login on command line silently fails if new TOS needs accepting : worked on that with Josh, reviewed, built on all platforms, moved it to review - STORM-477 : back out that change that was making windows build fail. Issue with boost package. See here under. - STORM-865 : boost: logged and linked to STORM-477 - STORM-866 : Default size of web content: integrated in viewer-beta (2.5) *FUTURE* - Merge Monkeying - OH - Triaging and code reviews - STORM-748 : rebuild kdu libs using KDU_X86_INTRINSICS - STORM-745 : Produce comprehensive perf baseline *IMPEDIMENTS* - none Oz Linden ------------------------------ *PAST* - Third Party Viewer developer meeting - Did some merges, reviewed several more - DN-202: improved display name caching *FUTURE* - Review many outstanding patches - Merge Monkey *IMPEDIMENTS* - none = Q Linden ------------------------------ *PAST* - VWR-24420 - VWR-24100 - VWR-24426 - STORM-243 - DN-202 - 2.5 beta 1 *FUTURE* - VWR-24426 - STORM-725 - DN-202 - STORM-864 - triage - keyword enhancement *IMPEDIMENTS* - None Esbee Linden ------------------------------ *PAST* - Meetings, Email - OOO Lunch with Q and Oz - Play with Viewer 2.5 Beta 1 - Prep Viewer 2.5 Beta 1 blog post - Jira ticket reviews *FUTURE* - Review Snowstorm Team product backlog and bug log - Tix which require feedback: STORM-28, -812, -226, -174 - Need a developer build for the tix in the PO review queue: STORM-2, -383, -484, -844, -834, -832, -715 https://jira.secondlife.com/secure/IssueNavigator.jspa?requestId=13662&mode=hide - Hopefully work on STORM-26 w/Q - Review tickets assigned to me - Plan tomorrow's Snowstorm Team office hour *IMPEDIMENTS* - None Paul ProductEngine ------------------------------ *PAST* - BUG STORM-634 ("Search" and "World map" SLURLs are not translated in Danish localisation) - Investigated. Assigned to Eli as it's just caused by missing translation in xml file. - BUG STORM-680 (Avaline callers are added to the Recent list) - WIP. Stuck while subscribing to the AVALINE voice service. Server doesn't return "Access Code", though my balance decreased. Discussed with Andrey and he has the same problem. Will try tomorrow. - BUG STORM-484 (The long name is not truncated in Build tools) - Fixed and sent for review - BUG STORM-533 (User is unable to save snapshot after pressing "More" and "Less" (without any changes)) - Resolved as cannot reproduce - BUG STORM-635 (Several strings in My Profile SP are not translated in Danish localization ) - Resolved as cannot reproduce. Since Web Profiles feature has been already implemented, this bug is not actual anymore. *FUTURE* - BUG STORM-680 (Avaline callers are added to the Recent list) *IMPEDIMENTS* - none Seth Productengine ------------------------------ *PAST* - BUG (STORM-383) Context menu cannot be open for Landmark that are located in the My inventory->Trash folder - Updated fix according to review feedback. - 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. - Investigating. Looking for the reason for not applying saved inventory sort order after re-login. *FUTURE* - 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. *IMPEDIMENTS* - none Vadim Productengine ------------------------------ *PAST* - Bug STORM-373 ('Rename' is sometimes disabled in inventory item context menu): - WIP, 80%. *FUTURE* - Bug STORM-373 ('Rename' is sometimes disabled in inventory item context menu): - Complete and submit. *IMPEDIMENTS* - Unclear what to do with STORM-174 (Checkbox needed to save inventory scripts as Mono): - the feature requires simulator work. - Need Esbee's answer in STORM-243 (Suppress version change message in the viewer). - No clear acceptance criteria for STORM-226 (Floating Text aligns improperly). Andrey Productengine ------------------------------ *PAST* - picked up v-d- build 219086 - proceeded with regression testing of v-d build - sidebar testplan review & revise *FUTURE* - continue with v-d stuff testing *IMPEDIMENTS* - none Wolfpup Lowenhar ------------------------------ *PAST* - Worked @ RL and in world. - STORM-236 : waiting on email reply from Esbee. - STORM-243 : gave feedback both in jira and on RB *FUTURE* - May check to see if there is other things already planed for this sprint might be able to help on. - Work @ RL and in world. - VWR-24256 : continue to monitor. *IMPEDIMENTS* - Not enough time between working in-world and at real job to actually work on code. Cummere Mayo ------------------------------ *PAST* - finished first pretriage of snowglobe - organized new metaissue for web profiles (needs moved from vwr to web) - created profile related feature requests - investigated VWR-23284 and some other jiras mentioning crashes on key west island. I think the viewer issue is a memory leak/runtime issue related to media, and that key west island is a "sick" region *FUTURE* - working on ideas for avatar 2.0 - collecting more feedback for appearance editor - get with merov about snowglobe and gear up for second pretriage - looking into options for mailing list for sl-ccnaf - get with oz about vwr issues oz mentioned last week *IMPEDIMENTS* - sick -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110119/5bb4d948/attachment-0001.htm From adyukov at productengine.com Wed Jan 19 03:05:53 2011 From: adyukov at productengine.com (Andrew Dyukov) Date: Wed, 19 Jan 2011 13:05:53 +0200 Subject: [opensource-dev] Review Request: STORM-2 As a User, I want to set my own default views with specific UI layout so I can tailor my Viewer experience to the activities I'm most interested in. In-Reply-To: References: <20110117212408.25763.20611@domU-12-31-38-00-90-68.compute-1.internal> <20110118143111.25993.91253@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: If everything will remain as it is in current implementation, layouts will be saved as several LLSD files in one folder, not in single LLSD file - it was done to allow adding of image files into layouts in future. So placing a folder into an archive and sending it by email (or other way) would be needed to share a layout. About proposed solutions- they both sound reasonable and probably may be added to the feature in future. 2011/1/18 Opensource Obscure : > Just to say this new feature looks very promising! > > A question. The 3rd note says > "the files associated with saved layouts will be LLSD text files, so you can > email or paste layouts into a notecard to share with other users". > (the note also explains why this is not the ideal behaviour ever, > and also why we have to deal with it for now) > > This sounds even cooler! ...but - how would that process of > sharing LLSD files exactly work? > I mean, where will users have to put those LLSD files? > > here is the scenario I'm thinking about: > > - a "teacher" (or mentor, friend, etc) is explaining to a new user > how to build in SL > - the teacher shares with the new user an LLSD file that contains > an ideal layout for building, and says "put this in your SL folder" > - the new user is now confused: many newbies don't know > the difference between the software folder and the settings folder, > and they don't know where those are; > this gets even worst to solve for people trying to help them, > because pathnames are different across different operating systems, > across different releases of the same o.s. - or because of localization. > > possible solutions: > - add another option in Preferences to choose the folder where we keep layouts > - add a menu command to choose a specific layout file ?- then the viewer > would copy that file into the actual settings folder. > > Opensource Obscure > From oz at lindenlab.com Wed Jan 19 04:06:27 2011 From: oz at lindenlab.com (Oz Linden (Scott Lawrence)) Date: Wed, 19 Jan 2011 07:06:27 -0500 Subject: [opensource-dev] Review Request: STORM-2 As a User, I want to set my own default views with specific UI layout so I can tailor my Viewer experience to the activities I'm most interested in. In-Reply-To: References: <20110117212408.25763.20611@domU-12-31-38-00-90-68.compute-1.internal> <20110118143111.25993.91253@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <4D36D3C3.5010509@lindenlab.com> On 2011-01-18 10:28, Opensource Obscure wrote: > Just to say this new feature looks very promising! > > A question. The 3rd note says > "the files associated with saved layouts will be LLSD text files, so you can > email or paste layouts into a notecard to share with other users". > (the note also explains why this is not the ideal behaviour ever, > and also why we have to deal with it for now) > > This sounds even cooler! ...but - how would that process of > sharing LLSD files exactly work? > I mean, where will users have to put those LLSD files? > > here is the scenario I'm thinking about: > > - a "teacher" (or mentor, friend, etc) is explaining to a new user > how to build in SL > - the teacher shares with the new user an LLSD file that contains > an ideal layout for building, and says "put this in your SL folder" > - the new user is now confused: many newbies don't know > the difference between the software folder and the settings folder, > and they don't know where those are; > this gets even worst to solve for people trying to help them, > because pathnames are different across different operating systems, > across different releases of the same o.s. - or because of localization. > > possible solutions: > - add another option in Preferences to choose the folder where we keep layouts > - add a menu command to choose a specific layout file - then the viewer > would copy that file into the actual settings folder. There are a variety of possible solutions to sharing between users, but sharing is explicitly not a part of this particular issue. The goal of this one is to make it possible to edit and save your layout choices. If/when we take up sharing those layouts, that will be a new issue. From oz at lindenlab.com Wed Jan 19 07:13:16 2011 From: oz at lindenlab.com (Oz Linden (Scott Lawrence)) Date: Wed, 19 Jan 2011 10:13:16 -0500 Subject: [opensource-dev] Using the codereview site for consults In-Reply-To: <001801cbb788$23cc2dd0$6b648970$@net> References: <001801cbb788$23cc2dd0$6b648970$@net> Message-ID: <4D36FF8C.20803@lindenlab.com> On 2011-01-18 22:22, WolfPup Lowenhar wrote: > > I'll apologize in advanced for length of this email but I need some > extra eyes on the code for this > > Diff to show changes being made(also the reason for the length of email): > This post suggests something to me.... I think it would be easier for everyone if the codereview site was used for posting this kind of query. It displays the code in a more readable way, and with more context. To be clear - it's perfectly ok, in fact encouraged, to post review requests for code that is not complete or ready for submission. Write up what kind of help you're looking for in the Description field, and the query will come to this list just like any other post (incidentally, I'm very happy with how people are responding to these review requests - thank you all for your help and attention). (this is not a criticism of what Wolfpup posted - it's a great query - I'm just clarifying that the codereview site may be used for this too) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110119/02d5827d/attachment.htm From vsavchuk at productengine.com Wed Jan 19 08:30:30 2011 From: vsavchuk at productengine.com (Vadim ProductEngine) Date: Wed, 19 Jan 2011 16:30:30 -0000 Subject: [opensource-dev] Review Request: STORM-465 Missing Strings from strings.xml Message-ID: <20110119163030.25762.55317@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/108/ ----------------------------------------------------------- Review request for Viewer. Summary ------- Made all keys localizable. This addresses bug STORM-465. http://jira.secondlife.com/browse/STORM-465 Diffs ----- indra/newview/skins/default/xui/en/strings.xml 38465c40c060 Diff: http://codereview.secondlife.com/r/108/diff Testing ------- Tested on Linux. No keys produce the warning for me. Thanks, Vadim -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110119/986eebb6/attachment.htm From opensourceobscure at gmail.com Wed Jan 19 09:34:09 2011 From: opensourceobscure at gmail.com (Opensource Obscure) Date: Wed, 19 Jan 2011 18:34:09 +0100 Subject: [opensource-dev] [JIRA] Indexing by search engines Message-ID: It seems to me that the Google indexing of jira.secondlife.com is a bit less efficient than in the past, where "in the past" may approx. mean "before the recent JIRA upgrade". I have mixed results - usually no problems - but sometimes it's a bit harder for me to get to the desired jira.secondlife.com/browse/xxxxxxx page than in the past. I don't have many evidences about this, but as an example http://www.google.com/search?q=storm-465&site:jira.secondlife.com doesn't show https://jira.secondlife.com/browse/STORM-465 in results, nor does www.google.com/search?q="The+missing+strings+are+shown+look+like+the+shortcut+part+of+the+menus" Is this expected? Anyone else experiencing this? If this issue exists, can be solved by fine-tuning JIRA website settings? Opensource Obscure -- http://twitter.com/oobscure - http://opensourceobscure.com From twisted_laws at hotmail.com Wed Jan 19 10:32:45 2011 From: twisted_laws at hotmail.com (Twisted Laws) Date: Wed, 19 Jan 2011 18:32:45 -0000 Subject: [opensource-dev] Review Request: VWR-24321: Validate textures starting with 00 too. In-Reply-To: <20110118200936.25759.54373@domU-12-31-38-00-90-68.compute-1.internal> References: <20110118200936.25759.54373@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110119183245.26332.57587@domU-12-31-38-00-90-68.compute-1.internal> > On Jan. 18, 2011, 12:09 p.m., Merov Linden wrote: > > indra/newview/lltexturecache.cpp, line 1595 > > > > > > validate_idx being used in a test later, it's not just for (validate_idx == 0) that the behavior will be different. I need to understand better what that idx is all about or you need to give a bit more explanation before I approve this diff. > > Aleric Inglewood wrote: > The debug setting CacheValidateCounter is set to 'next_id', which makes clear what it's meaning is: namely, the id that we will check next time. next_idx is a very local variable that is simply set to the value of CacheValidateCounter plus 1, and then that value is stored to CacheValidateCounter again for next time. > > validate_idx is the ID that is actually being tested this time. Hence, it should be the value of CacheValidateCounter before we increase that. > > Obviously, those ID's should be in the range 0...255, which is garanteed by doing a modulo 256 on next_id before writing it to CacheValidateCounter. > > The old code also increases validate_idx *before* it is used. That means that it will be in the range 1...256, and 0 is never tested (note that validate_idx is just increased, there is no modulo applied, so it's obvious that it shouldn't be increased). Even the wording ("next"_id) suggests that validate_idx should just be the value of CacheValidateCounter, which is the value of the previous next_id... > > So, after this patch, we get to the following code with validate_idx in the range 0...255, as it should be. > > > Cron Stardust wrote: > Just double checking, as switching from pre-increment to addition can change behavior: In both cases next_idx will have the same value after this line is executed, however validate_idx will not. > > Prediff start state: validate_idx == 0; > Prediff stop state: validate_idx == 1; next_idx == 1; > > Postdiff start state: validate_idx == 0; > Postdiff stop state: validate_idx == 0; next_idx == 1; > > And another round over at the other end: > > Prediff start state: validate_idx == 255; > Prediff stop state: validate_idx == 256; next_idx == 0; > > Postdiff start state: validate_idx == 255; > Postdiff stop state: validate_idx == 255; next_idx == 0; > > So, yes, validate_idx will only have a 255 in it in this last case, however the over-all behavior has changed: validate_idx isn't being incremented at all in this line. > > WARNING: I have NOT looked at the rest of the diff, only at this one line. Nor do I know if validate_idx should or shouldn't be incremented by this line of code. Given the way this seems to work to me without changing the sequence things are checked... I'd change line 1619 to if (uuididx == (validate_idx % 256)) Otherwise it was checking for 1 thru 256 and never 0... this does not change what appears to be incorrect coding where Aleric pointed out and thus won't change the current logic that it starts by checking 1 thru 255 before checking 0. To retain the current sequence that things are checked, you would have to compare uuididx to next_idx along with the change Aleric provided. However it seems to me that all is ok with using Aleric's correction and leaving the remaining code untouched. (I can't see where changing the sequence of checking makes a difference.) - Twisted ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/90/#review191 ----------------------------------------------------------- On Jan. 14, 2011, 1:02 p.m., Aleric Inglewood wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/90/ > ----------------------------------------------------------- > > (Updated Jan. 14, 2011, 1:02 p.m.) > > > Review request for Viewer. > > > Summary > ------- > > Trivial patch, just removes stupidity. > > > This addresses bug VWR-24321. > http://jira.secondlife.com/browse/VWR-24321 > > > Diffs > ----- > > doc/contributions.txt b0bd26c5638a > indra/newview/lltexturecache.cpp b0bd26c5638a > > Diff: http://codereview.secondlife.com/r/90/diff > > > Testing > ------- > > > Thanks, > > Aleric > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110119/c26c2890/attachment-0001.htm From sllists at boroon.dasgupta.ch Wed Jan 19 14:44:24 2011 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Wed, 19 Jan 2011 22:44:24 -0000 Subject: [opensource-dev] Review Request: VWR-24321: Validate textures starting with 00 too. In-Reply-To: <20110114210232.20676.90941@domU-12-31-38-00-90-68.compute-1.internal> References: <20110114210232.20676.90941@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110119224424.25759.40278@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/90/#review199 ----------------------------------------------------------- Ship it! > validate_idx being used in a test later, it's not just for (validate_idx == 0) > that the behavior will be different. I need to understand better what that idx > is all about or you need to give a bit more explanation before I approve this diff. The different intention is needed. Without the change Aleric suggests, files that have a specific byte of their UUID being 0 will never be validated. On the other hand, sometimes no files will be tested at all (when validate_idx is 256, as no byte can assume that value). indra/newview/lltexturecache.cpp This comment tells us the intention of everything in the if (validate) conditional code. Let's see what happens ... indra/newview/lltexturecache.cpp This value will be overwritten below. Has to be declared already here, so it will still be available in the second if (validate) scope. Here comes the first one: indra/newview/lltexturecache.cpp Overwrite validate_idx with value from settings. Will be something within [0,255], as we will see below. indra/newview/lltexturecache.cpp Old code: validate_idx will now be in [1,256]. (one higher than before) New code: validate_idx will stay in [0,256]. (untouched) Old and new code: next_idx will be in [0,256], but different than the new-code validate_idx (one higher modulo 256). indra/newview/lltexturecache.cpp next_idx (still in the range [0,256]) gets saved to setting. (Thus why the value we get from the setting above must be in that interval.) indra/newview/lltexturecache.cpp We iterate over a set of pairs. The pairs' second entries are our 'indices'. Current index is available in idx. indra/newview/lltexturecache.cpp If the entry has to be purged anyway, because of size constraints, we don't have to validate it. Otherwise, here's the second if (validate) scope. indra/newview/lltexturecache.cpp this actually happens in the following if scope (if the condition is met) indra/newview/lltexturecache.cpp Testing each entry each time probably takes too much time. Thus, as the comment in the beginning told us, only a fraction is tested. This is done by just skipping the following validation code for most entries during the for-loop we are currently in. Should the entry of the current iteration be tested? We decide that by comparing a specific byte of its UUID with validate_idx. Thus, during the loop, all cache entries that have this byte take on the same value as validate_idx will be validated. For this to actually be (on average) 1/256th of the files (as said comment claims), this byte must be uniformly distributed (i.e. all values in [0,255] must be equally likely for it). The server probably makes sure of that when assigning UUIDs. Because a byte takes values in [0,255], validate_idx must take on each of these values over time, so that all files will be validated sooner or later, if the stay around long enough. Thus the original code was wrong and the new one is correct. That mData[0] is indeed a byte can be seen where its declared. (See https://bitbucket.org/lindenlab/viewer-development/src/40d0806e9800/indra/llcommon/lluuid.h#cl-127 -- It's a U8.) indra/newview/lltexturecache.cpp The actual validation. Entries for files that fail it are marked down for purging. indra/newview/lltexturecache.cpp If we neither are short of space nor have validated any cache entries, no entries can possibly be marked down for purging, so we can leave early here. indra/newview/lltexturecache.cpp ... actually purge marked down entries ... indra/newview/lltexturecache.cpp ... end of the long for loop. I hope this makes things clear (and that I'm reading the code correctly and not telling any humbug ...) - Boroondas On Jan. 14, 2011, 1:02 p.m., Aleric Inglewood wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/90/ > ----------------------------------------------------------- > > (Updated Jan. 14, 2011, 1:02 p.m.) > > > Review request for Viewer. > > > Summary > ------- > > Trivial patch, just removes stupidity. > > > This addresses bug VWR-24321. > http://jira.secondlife.com/browse/VWR-24321 > > > Diffs > ----- > > doc/contributions.txt b0bd26c5638a > indra/newview/lltexturecache.cpp b0bd26c5638a > > Diff: http://codereview.secondlife.com/r/90/diff > > > Testing > ------- > > > Thanks, > > Aleric > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110119/5ebc7be1/attachment-0001.htm From sllists at boroon.dasgupta.ch Wed Jan 19 14:47:23 2011 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Wed, 19 Jan 2011 22:47:23 -0000 Subject: [opensource-dev] Review Request: VWR-24321: Validate textures starting with 00 too. In-Reply-To: <20110118200936.25759.54373@domU-12-31-38-00-90-68.compute-1.internal> References: <20110118200936.25759.54373@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110119224723.25992.89798@domU-12-31-38-00-90-68.compute-1.internal> > On Jan. 18, 2011, 12:09 p.m., Merov Linden wrote: > > indra/newview/lltexturecache.cpp, line 1595 > > > > > > validate_idx being used in a test later, it's not just for (validate_idx == 0) that the behavior will be different. I need to understand better what that idx is all about or you need to give a bit more explanation before I approve this diff. > > Aleric Inglewood wrote: > The debug setting CacheValidateCounter is set to 'next_id', which makes clear what it's meaning is: namely, the id that we will check next time. next_idx is a very local variable that is simply set to the value of CacheValidateCounter plus 1, and then that value is stored to CacheValidateCounter again for next time. > > validate_idx is the ID that is actually being tested this time. Hence, it should be the value of CacheValidateCounter before we increase that. > > Obviously, those ID's should be in the range 0...255, which is garanteed by doing a modulo 256 on next_id before writing it to CacheValidateCounter. > > The old code also increases validate_idx *before* it is used. That means that it will be in the range 1...256, and 0 is never tested (note that validate_idx is just increased, there is no modulo applied, so it's obvious that it shouldn't be increased). Even the wording ("next"_id) suggests that validate_idx should just be the value of CacheValidateCounter, which is the value of the previous next_id... > > So, after this patch, we get to the following code with validate_idx in the range 0...255, as it should be. > > > Cron Stardust wrote: > Just double checking, as switching from pre-increment to addition can change behavior: In both cases next_idx will have the same value after this line is executed, however validate_idx will not. > > Prediff start state: validate_idx == 0; > Prediff stop state: validate_idx == 1; next_idx == 1; > > Postdiff start state: validate_idx == 0; > Postdiff stop state: validate_idx == 0; next_idx == 1; > > And another round over at the other end: > > Prediff start state: validate_idx == 255; > Prediff stop state: validate_idx == 256; next_idx == 0; > > Postdiff start state: validate_idx == 255; > Postdiff stop state: validate_idx == 255; next_idx == 0; > > So, yes, validate_idx will only have a 255 in it in this last case, however the over-all behavior has changed: validate_idx isn't being incremented at all in this line. > > WARNING: I have NOT looked at the rest of the diff, only at this one line. Nor do I know if validate_idx should or shouldn't be incremented by this line of code. > > Twisted Laws wrote: > Given the way this seems to work to me without changing the sequence things are checked... > I'd change line 1619 to if (uuididx == (validate_idx % 256)) > Otherwise it was checking for 1 thru 256 and never 0... this does not change what appears > to be incorrect coding where Aleric pointed out and thus won't change the current > logic that it starts by checking 1 thru 255 before checking 0. To retain the current sequence > that things are checked, you would have to compare uuididx to next_idx along with the change > Aleric provided. > > However it seems to me that all is ok with using Aleric's correction and leaving the remaining > code untouched. (I can't see where changing the sequence of checking makes a difference.) > Just double checking, as switching from pre-increment to addition can change behavior: > In both cases next_idx will have the same value after this line is executed, however validate_idx will not. That's the intention. Without the change suggested here, validate_idx ends up in the wrong range. See my more detailed review below. - Boroondas ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/90/#review191 ----------------------------------------------------------- On Jan. 14, 2011, 1:02 p.m., Aleric Inglewood wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/90/ > ----------------------------------------------------------- > > (Updated Jan. 14, 2011, 1:02 p.m.) > > > Review request for Viewer. > > > Summary > ------- > > Trivial patch, just removes stupidity. > > > This addresses bug VWR-24321. > http://jira.secondlife.com/browse/VWR-24321 > > > Diffs > ----- > > doc/contributions.txt b0bd26c5638a > indra/newview/lltexturecache.cpp b0bd26c5638a > > Diff: http://codereview.secondlife.com/r/90/diff > > > Testing > ------- > > > Thanks, > > Aleric > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110119/9dd518a2/attachment.htm From sllists at boroon.dasgupta.ch Wed Jan 19 14:48:53 2011 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Wed, 19 Jan 2011 22:48:53 -0000 Subject: [opensource-dev] Review Request: VWR-24321: Validate textures starting with 00 too. In-Reply-To: <20110119224424.25759.40278@domU-12-31-38-00-90-68.compute-1.internal> References: <20110119224424.25759.40278@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110119224853.26007.69754@domU-12-31-38-00-90-68.compute-1.internal> > On Jan. 19, 2011, 2:44 p.m., Boroondas Gupte wrote: > > > validate_idx being used in a test later, it's not just for (validate_idx == 0) > > > that the behavior will be different. I need to understand better what that idx > > > is all about or you need to give a bit more explanation before I approve this diff. > > > > The different intention is needed. Without the change Aleric suggests, files that have a specific byte of their UUID being 0 will never be validated. On the other hand, sometimes no files will be tested at all (when validate_idx is 256, as no byte can assume that value). > The different intention is needed. Err ... I mean "The different behavior is intentional (and needed)." - Boroondas ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/90/#review199 ----------------------------------------------------------- On Jan. 14, 2011, 1:02 p.m., Aleric Inglewood wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/90/ > ----------------------------------------------------------- > > (Updated Jan. 14, 2011, 1:02 p.m.) > > > Review request for Viewer. > > > Summary > ------- > > Trivial patch, just removes stupidity. > > > This addresses bug VWR-24321. > http://jira.secondlife.com/browse/VWR-24321 > > > Diffs > ----- > > doc/contributions.txt b0bd26c5638a > indra/newview/lltexturecache.cpp b0bd26c5638a > > Diff: http://codereview.secondlife.com/r/90/diff > > > Testing > ------- > > > Thanks, > > Aleric > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110119/bf2740ea/attachment.htm From sllists at boroon.dasgupta.ch Wed Jan 19 14:52:52 2011 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Wed, 19 Jan 2011 22:52:52 -0000 Subject: [opensource-dev] Review Request: VWR-24321: Validate textures starting with 00 too. In-Reply-To: <20110119224424.25759.40278@domU-12-31-38-00-90-68.compute-1.internal> References: <20110119224424.25759.40278@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110119225252.25766.7524@domU-12-31-38-00-90-68.compute-1.internal> > On Jan. 19, 2011, 2:44 p.m., Boroondas Gupte wrote: > > indra/newview/lltexturecache.cpp, line 1595 > > > > > > Old code: > > validate_idx will now be in [1,256]. (one higher than before) > > > > New code: > > validate_idx will stay in [0,256]. (untouched) > > > > Old and new code: > > next_idx will be in [0,256], but different than the new-code validate_idx (one higher modulo 256). ok, tripple checked the ranges, but still typed them wrong ... this should be New code: validate_idx will stay in [0,255]. (untouched) Old and new code: next_idx will be in [0,255], but different than the new-code validate_idx (one higher modulo 256). > On Jan. 19, 2011, 2:44 p.m., Boroondas Gupte wrote: > > indra/newview/lltexturecache.cpp, lines 1596-1598 > > > > > > next_idx (still in the range [0,256]) gets saved to setting. (Thus why the value we get from the setting above must be in that interval.) make this [0,255], too ^_^ - Boroondas ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/90/#review199 ----------------------------------------------------------- On Jan. 14, 2011, 1:02 p.m., Aleric Inglewood wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/90/ > ----------------------------------------------------------- > > (Updated Jan. 14, 2011, 1:02 p.m.) > > > Review request for Viewer. > > > Summary > ------- > > Trivial patch, just removes stupidity. > > > This addresses bug VWR-24321. > http://jira.secondlife.com/browse/VWR-24321 > > > Diffs > ----- > > doc/contributions.txt b0bd26c5638a > indra/newview/lltexturecache.cpp b0bd26c5638a > > Diff: http://codereview.secondlife.com/r/90/diff > > > Testing > ------- > > > Thanks, > > Aleric > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110119/ea7a5f03/attachment-0001.htm From Aleric.Inglewood at gmail.com Wed Jan 19 15:05:04 2011 From: Aleric.Inglewood at gmail.com (Aleric Inglewood) Date: Wed, 19 Jan 2011 23:05:04 -0000 Subject: [opensource-dev] Review Request: VWR-24321: Validate textures starting with 00 too. In-Reply-To: <20110118200936.25759.54373@domU-12-31-38-00-90-68.compute-1.internal> References: <20110118200936.25759.54373@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110119230504.29886.50369@domU-12-31-38-00-90-68.compute-1.internal> > On Jan. 18, 2011, 12:09 p.m., Merov Linden wrote: > > indra/newview/lltexturecache.cpp, line 1595 > > > > > > validate_idx being used in a test later, it's not just for (validate_idx == 0) that the behavior will be different. I need to understand better what that idx is all about or you need to give a bit more explanation before I approve this diff. > > Aleric Inglewood wrote: > The debug setting CacheValidateCounter is set to 'next_id', which makes clear what it's meaning is: namely, the id that we will check next time. next_idx is a very local variable that is simply set to the value of CacheValidateCounter plus 1, and then that value is stored to CacheValidateCounter again for next time. > > validate_idx is the ID that is actually being tested this time. Hence, it should be the value of CacheValidateCounter before we increase that. > > Obviously, those ID's should be in the range 0...255, which is garanteed by doing a modulo 256 on next_id before writing it to CacheValidateCounter. > > The old code also increases validate_idx *before* it is used. That means that it will be in the range 1...256, and 0 is never tested (note that validate_idx is just increased, there is no modulo applied, so it's obvious that it shouldn't be increased). Even the wording ("next"_id) suggests that validate_idx should just be the value of CacheValidateCounter, which is the value of the previous next_id... > > So, after this patch, we get to the following code with validate_idx in the range 0...255, as it should be. > > > Cron Stardust wrote: > Just double checking, as switching from pre-increment to addition can change behavior: In both cases next_idx will have the same value after this line is executed, however validate_idx will not. > > Prediff start state: validate_idx == 0; > Prediff stop state: validate_idx == 1; next_idx == 1; > > Postdiff start state: validate_idx == 0; > Postdiff stop state: validate_idx == 0; next_idx == 1; > > And another round over at the other end: > > Prediff start state: validate_idx == 255; > Prediff stop state: validate_idx == 256; next_idx == 0; > > Postdiff start state: validate_idx == 255; > Postdiff stop state: validate_idx == 255; next_idx == 0; > > So, yes, validate_idx will only have a 255 in it in this last case, however the over-all behavior has changed: validate_idx isn't being incremented at all in this line. > > WARNING: I have NOT looked at the rest of the diff, only at this one line. Nor do I know if validate_idx should or shouldn't be incremented by this line of code. > > Twisted Laws wrote: > Given the way this seems to work to me without changing the sequence things are checked... > I'd change line 1619 to if (uuididx == (validate_idx % 256)) > Otherwise it was checking for 1 thru 256 and never 0... this does not change what appears > to be incorrect coding where Aleric pointed out and thus won't change the current > logic that it starts by checking 1 thru 255 before checking 0. To retain the current sequence > that things are checked, you would have to compare uuididx to next_idx along with the change > Aleric provided. > > However it seems to me that all is ok with using Aleric's correction and leaving the remaining > code untouched. (I can't see where changing the sequence of checking makes a difference.) > > Boroondas Gupte wrote: > > Just double checking, as switching from pre-increment to addition can change behavior: > > In both cases next_idx will have the same value after this line is executed, however validate_idx will not. > > That's the intention. Without the change suggested here, validate_idx ends up in the wrong range. See my more detailed review below. @Cron Stardust : That is correct. The bug was that validate_idx was 1 too large. Nor incrementing it is the correct thing. Re the 'WARNING': this line is the only line in the diff :p - Aleric ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/90/#review191 ----------------------------------------------------------- On Jan. 14, 2011, 1:02 p.m., Aleric Inglewood wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/90/ > ----------------------------------------------------------- > > (Updated Jan. 14, 2011, 1:02 p.m.) > > > Review request for Viewer. > > > Summary > ------- > > Trivial patch, just removes stupidity. > > > This addresses bug VWR-24321. > http://jira.secondlife.com/browse/VWR-24321 > > > Diffs > ----- > > doc/contributions.txt b0bd26c5638a > indra/newview/lltexturecache.cpp b0bd26c5638a > > Diff: http://codereview.secondlife.com/r/90/diff > > > Testing > ------- > > > Thanks, > > Aleric > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110119/42008055/attachment.htm From kf6kjg at gmail.com Wed Jan 19 15:43:43 2011 From: kf6kjg at gmail.com (Cron Stardust) Date: Wed, 19 Jan 2011 23:43:43 -0000 Subject: [opensource-dev] Review Request: VWR-24321: Validate textures starting with 00 too. In-Reply-To: <20110114210232.20676.90941@domU-12-31-38-00-90-68.compute-1.internal> References: <20110114210232.20676.90941@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110119234343.25759.11647@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/90/#review204 ----------------------------------------------------------- Ship it! Thanks for the clarification! Looks good to me. - Cron On Jan. 14, 2011, 1:02 p.m., Aleric Inglewood wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/90/ > ----------------------------------------------------------- > > (Updated Jan. 14, 2011, 1:02 p.m.) > > > Review request for Viewer. > > > Summary > ------- > > Trivial patch, just removes stupidity. > > > This addresses bug VWR-24321. > http://jira.secondlife.com/browse/VWR-24321 > > > Diffs > ----- > > doc/contributions.txt b0bd26c5638a > indra/newview/lltexturecache.cpp b0bd26c5638a > > Diff: http://codereview.secondlife.com/r/90/diff > > > Testing > ------- > > > Thanks, > > Aleric > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110119/7e59a90e/attachment.htm From secret.argent at gmail.com Wed Jan 19 20:08:44 2011 From: secret.argent at gmail.com (Argent Stonecutter) Date: Wed, 19 Jan 2011 22:08:44 -0600 Subject: [opensource-dev] STORM-243 - simulator version notifications In-Reply-To: References: <5941ED4A-7D5D-4008-9FC9-A68B33EF2A44@lindenlab.com> <226473.53614.qm@web120517.mail.ne1.yahoo.com> <6E2D0388-BD03-4BB7-ADD1-4D3DCEA01FDB@gmail.com> Message-ID: <29F41736-AB2A-4129-8618-9950575F6BE3@gmail.com> On 2011-01-18, at 15:58, Sarah (Esbee) Kuehnle wrote: > This is not a feature belongs in the Viewer. If there's more data you want out of llGetEnv(), I'd suggest filing an SVC feature request. "Just wait, next month we'll have someone needing help figuring out why llGetEnv is broken on the latest BlueSteel" :) :) :) :) (No, I'm not arguing, I'm being amused) (in case the smileys didn't get that across) From rusyasoft at gmail.com Thu Jan 20 00:34:00 2011 From: rusyasoft at gmail.com (Rustam Rakhimov) Date: Thu, 20 Jan 2011 17:34:00 +0900 Subject: [opensource-dev] Where is MXP implementation ? Message-ID: Where is MXP implementation ? hi everybody, RealXtend uses MXP but where exactly, i mean which part and where its used or implemented please let me know. if possible file name and function name thank you in advance !! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110120/c45cb063/attachment.htm From sllists at boroon.dasgupta.ch Thu Jan 20 02:49:06 2011 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Thu, 20 Jan 2011 11:49:06 +0100 Subject: [opensource-dev] Motto & Goals (was: STORM-243 - simulator version notifications) In-Reply-To: References: <5941ED4A-7D5D-4008-9FC9-A68B33EF2A44@lindenlab.com> <201101190842.28913.Lance.Corrimal@eregion.de> Message-ID: <4D381322.8080207@boroon.dasgupta.ch> On 01/19/2011 09:20 AM, Stickman wrote: > Is there a mission statement, a motto, a creed, or a list of goals > somewhere? "Fast, Easy and Fun", wasn't it? Or has that motto, too, already been antiquated? A list of long term goals (besides what is dictated by server side changes anyway) would interest me, too, though. Boroondas From akanevsky at productengine.com Thu Jan 20 03:48:26 2011 From: akanevsky at productengine.com (Anya Kanevsky) Date: Thu, 20 Jan 2011 03:48:26 -0800 Subject: [opensource-dev] Daily Scrum Summary - Wednesday, January 19 Message-ID: Wedensday, January 19, 2011 General Notes ------------------------------ - MMOTD: Oz Team Status ------------------------------ Merov Linden ------------------------------ *PAST* - OH: SNOW triaging, need to move a bunch of SNOW records as a result - SH-761: Texture Saving Does Not Work : worked with Bao on that. Need to evaluate his patch. - STORM-745 : KDU Perf : Got Windows data. Need to run that on Linux. - STORM-748 : KDU_X86_INTRINSICS : Patched vcproj to build with this. In progress. *FUTURE* - STORM-748 : Finish - STORM-745 : Finish *IMPEDIMENTS* - none Oz Linden ------------------------------ *PAST* - Merge Monkey - Caught up on what Team Chopper is doing (autobuild) *FUTURE* - Review patches in codereview - Merge Monkey *IMPEDIMENTS* - moving large amounts of slush around :-( Q Linden ------------------------------ *PAST* - STORM-725 - STORM-864 - VWR-24426 - SOCIAL-452 - STORM-243 - Internal meetings - Snowstorm weekly meeting - 2.5 beta 1 *FUTURE* - VWR-24426 - Dr's appt today - triage *IMPEDIMENTS* - Not enough rope to tie esbee to her chair. :( Esbee Linden ------------------------------ *PAST* - Meetings, Email - My last OH :( - Jira ticket reviews and cleanup *FUTURE* - Review Snowstorm Team product backlog and bug log - Tix which require feedback: STORM-28, -812, -226, -174 - Review developer build for the tix in the PO review queue: STORM-2, -383, -484, -844, -834, -832, -715 https://jira.secondlife.com/secure/IssueNavigator.jspa?requestId=13662&mode=hide - Hopefully work on STORM-26 w/Q - Review tickets assigned to me *IMPEDIMENTS* - None Paul ProductEngine ------------------------------ *PAST* - BUG STORM-547 (Name of blocked person is not presented in list if person was blocked from Inspector) - Fixed & sent for review - BUG STORM-613 ((i) button overlaps resident names in the Group chat participant list ) - Resolved as cannot reproduce - BUG STORM-665 (User is not able to view full name of Group's founder in the Group Profile) - Investigated and resolved as cannot reproduce - BUG STORM-629 (Place Rating text is quoted and is not translated in Polish localization) - Investigated and assigned to Eli. - BUG STORM-612 ('Didn't find..' text overlaps My inventory folder name in Pick Texture window) - Tried to reproduce. Tomorrow will try again. *FUTURE* - BUG STORM-612 ('Didn't find..' text overlaps My inventory folder name in Pick Texture window) *IMPEDIMENTS* - none Seth Productengine ------------------------------ *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. - WIP. Investigating. Seems that the issue affects only Inventory SP and does not reproduce on inventory floaters. *FUTURE* - 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. - BUG (STORM-843) Inventory incremental string search not working (search starts over) *IMPEDIMENTS* - none Vadim Productengine ------------------------------ *PAST* - Bug STORM-373 ('Rename' is sometimes disabled in inventory item context menu): - Completed the fix and put it on review. - Bug STORM-243 (Suppress version change message in the viewer): - Fixed; put the fix on review. - Bug STORM-547 (Name of blocked person is not presented in list if person was blocked from Inspector): - Helped Paul to fix it. - Bug STORM-599 (Name tags radio buttons are not in focus after they were clicked): - Resolved as expected behavior. - Bug STORM-465 (Missing Strings from strings.xml): - WIP. *FUTURE* - Complete fixing STORM-465. - Other bugs. *IMPEDIMENTS* - Unclear what to do with STORM-174: the feature requires simulator work. - No clear acceptance criteria for STORM-226 (Floating Text aligns improperly). - -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110120/573e5fb5/attachment-0001.htm From sllists at boroon.dasgupta.ch Thu Jan 20 03:53:49 2011 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Thu, 20 Jan 2011 11:53:49 -0000 Subject: [opensource-dev] Review Request: make PREHASH variables char const* const In-Reply-To: <20110119015814.25766.86058@domU-12-31-38-00-90-68.compute-1.internal> References: <20110119015814.25766.86058@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110120115349.26108.43130@domU-12-31-38-00-90-68.compute-1.internal> > On Jan. 18, 2011, 5:58 p.m., Aleric Inglewood wrote: > > I love it! Thanks, this was stopped me from compiling the tests (since some commit not long ago I guess, because I could before). > > Just one remark. In one test _PREHASH_AgentID is set to "AgentID" (no doubt a place holder), while in the other you set it to 0 (now needed because it's a const). Perhaps a more symmetric approach is better? I'd opt for setting the other also to a random string, like "Grumpity Productengine", or "Aleric Inglewood" now I think about it. Other options are "All Your Base Are Belong To Us" and "Hi mom!". Got be SURE they aren't used though -- don't want any new 'Grumpity' embarrashments :p > > Because I don't know how to quote code in a comment, I'll answer in a 'review'. See below. - Boroondas ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/100/#review196 ----------------------------------------------------------- On Jan. 18, 2011, 7:29 a.m., Boroondas Gupte wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/100/ > ----------------------------------------------------------- > > (Updated Jan. 18, 2011, 7:29 a.m.) > > > Review request for Viewer. > > > Summary > ------- > > For the reason for this change, see https://jira.secondlife.com/browse/VWR-24487 and https://jira.secondlife.com/browse/VWR-24522 > > What I did: > In indra/llmessage/message_prehash.(h|cpp), I turned everything into constant pointers to constants by search/replace. Then I tried to compile and added const qualifiers in dependent code as needed to stop the compiler complaining. > > Note that comments in indra/llmessage/message_prehash.(h|cpp) say these files have been generated from the message template. If this generation wasn't a one-off thing, the generating code must be changed, too, so it won't override this change here when the generation happens the next time. > > > This addresses bug VWR-24487. > http://jira.secondlife.com/browse/VWR-24487 > > > Diffs > ----- > > doc/contributions.txt fc7e5dcf3059 > indra/llmessage/message_prehash.h fc7e5dcf3059 > indra/llmessage/message_prehash.cpp fc7e5dcf3059 > indra/llprimitive/llprimitive.h fc7e5dcf3059 > indra/llprimitive/llprimitive.cpp fc7e5dcf3059 > indra/llprimitive/llvolumemessage.h fc7e5dcf3059 > indra/llprimitive/llvolumemessage.cpp fc7e5dcf3059 > indra/llui/tests/llurlentry_stub.cpp fc7e5dcf3059 > indra/newview/tests/llremoteparcelrequest_test.cpp fc7e5dcf3059 > > Diff: http://codereview.secondlife.com/r/100/diff > > > Testing > ------- > > Compiled (standalone, 64bit Linux) with and without LL_TESTS. > Started the viewer, logged in, walked and flew around a bit. Everything seems to work. > > > Thanks, > > Boroondas > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110120/b72a3ecd/attachment.htm From sllists at boroon.dasgupta.ch Thu Jan 20 03:54:38 2011 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Thu, 20 Jan 2011 11:54:38 -0000 Subject: [opensource-dev] Review Request: make PREHASH variables char const* const In-Reply-To: <20110118152944.26007.14045@domU-12-31-38-00-90-68.compute-1.internal> References: <20110118152944.26007.14045@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110120115438.25992.63770@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/100/#review207 ----------------------------------------------------------- > Just one remark. In one test _PREHASH_AgentID is set to "AgentID" > (no doubt a place holder), while in the other you set it to 0 > (now needed because it's a const). Perhaps a more symmetric approach > is better? indra/llui/tests/llurlentry_stub.cpp This test already contained these placeholder strings, so I just left it at that, only adapting the types. indra/newview/tests/llremoteparcelrequest_test.cpp In this test here, however, I think the pointers actually ended up undefined in the original code, so setting them to NULL was the closest I possibility could think off. As building succeeded with this, I concluded that these pointers are passed around but never dereferenced during the test.[*] I feel setting nullpointers nicely signals that fact, though it should probably be augmented by a // never used during this test or // never dereferenced in this test comment to make that intent clear. I agree though, that we should try to handle this similarly in both tests, if possible. So I tried setting the pointers in indra/llui/tests/llurlentry_stub.cpp to NULL, too, which works nicely. However, I then realized that the tested code might have nullpointer guards around dereferencing code, so that if we pass nullpointers we are actually testing another scenario than when passing pointers to actual data and that this might be the reason why no null-pointer exceptions occur during the tests. Of course, we could now examine the tested code to see whether this is the case. However, it would be a bad idea to adapt the test code based on that examination, as the tested code might be changed later without this question being re-evaluated and the test rewritten accordingly. Is there another pointer value besides NULL (thus not usually tested for) that still fails reliably when tried to dereference? ---- [*] Remember that tests are executed when building and are hopefully completely deterministic, so that any potential null-pointer-exception would have shown up. - Boroondas On Jan. 18, 2011, 7:29 a.m., Boroondas Gupte wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/100/ > ----------------------------------------------------------- > > (Updated Jan. 18, 2011, 7:29 a.m.) > > > Review request for Viewer. > > > Summary > ------- > > For the reason for this change, see https://jira.secondlife.com/browse/VWR-24487 and https://jira.secondlife.com/browse/VWR-24522 > > What I did: > In indra/llmessage/message_prehash.(h|cpp), I turned everything into constant pointers to constants by search/replace. Then I tried to compile and added const qualifiers in dependent code as needed to stop the compiler complaining. > > Note that comments in indra/llmessage/message_prehash.(h|cpp) say these files have been generated from the message template. If this generation wasn't a one-off thing, the generating code must be changed, too, so it won't override this change here when the generation happens the next time. > > > This addresses bug VWR-24487. > http://jira.secondlife.com/browse/VWR-24487 > > > Diffs > ----- > > doc/contributions.txt fc7e5dcf3059 > indra/llmessage/message_prehash.h fc7e5dcf3059 > indra/llmessage/message_prehash.cpp fc7e5dcf3059 > indra/llprimitive/llprimitive.h fc7e5dcf3059 > indra/llprimitive/llprimitive.cpp fc7e5dcf3059 > indra/llprimitive/llvolumemessage.h fc7e5dcf3059 > indra/llprimitive/llvolumemessage.cpp fc7e5dcf3059 > indra/llui/tests/llurlentry_stub.cpp fc7e5dcf3059 > indra/newview/tests/llremoteparcelrequest_test.cpp fc7e5dcf3059 > > Diff: http://codereview.secondlife.com/r/100/diff > > > Testing > ------- > > Compiled (standalone, 64bit Linux) with and without LL_TESTS. > Started the viewer, logged in, walked and flew around a bit. Everything seems to work. > > > Thanks, > > Boroondas > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110120/ce87c419/attachment-0001.htm From slitovchuk at productengine.com Thu Jan 20 06:46:47 2011 From: slitovchuk at productengine.com (Seth ProductEngine) Date: Thu, 20 Jan 2011 14:46:47 -0000 Subject: [opensource-dev] Review Request: STORM-465 Missing Strings from strings.xml In-Reply-To: <20110119163030.25762.55317@domU-12-31-38-00-90-68.compute-1.internal> References: <20110119163030.25762.55317@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110120144647.26155.39697@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/108/#review208 ----------------------------------------------------------- Ship it! No missing string warnings while looking through the menu with this patch. - Seth On Jan. 19, 2011, 8:30 a.m., Vadim ProductEngine wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/108/ > ----------------------------------------------------------- > > (Updated Jan. 19, 2011, 8:30 a.m.) > > > Review request for Viewer. > > > Summary > ------- > > Made all keys localizable. > > > This addresses bug STORM-465. > http://jira.secondlife.com/browse/STORM-465 > > > Diffs > ----- > > indra/newview/skins/default/xui/en/strings.xml 38465c40c060 > > Diff: http://codereview.secondlife.com/r/108/diff > > > Testing > ------- > > Tested on Linux. No keys produce the warning for me. > > > Thanks, > > Vadim > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110120/7fccdf2d/attachment.htm From Aleric.Inglewood at gmail.com Thu Jan 20 07:56:17 2011 From: Aleric.Inglewood at gmail.com (Aleric Inglewood) Date: Thu, 20 Jan 2011 15:56:17 -0000 Subject: [opensource-dev] Review Request: make PREHASH variables char const* const In-Reply-To: <20110120115438.25992.63770@domU-12-31-38-00-90-68.compute-1.internal> References: <20110120115438.25992.63770@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110120155617.26007.11230@domU-12-31-38-00-90-68.compute-1.internal> On Jan. 20, 2011, 3:54 a.m., Boroondas Gupte wrote: > > I agree though, that we should try to handle this similarly in both tests, if possible. So I tried setting the pointers in indra/llui/tests/llurlentry_stub.cpp to NULL, too, which works nicely. > > > > However, I then realized that the tested code might have nullpointer guards around dereferencing code, so that if we pass nullpointers we are actually testing another scenario than when passing pointers to actual data and that this might be the reason why no null-pointer exceptions occur during the tests. > > > > Of course, we could now examine the tested code to see whether this is the case. However, it would be a bad idea to adapt the test code based on that examination, as the tested code might be changed later without this question being re-evaluated and the test rewritten accordingly. > > > > Is there another pointer value besides NULL (thus not usually tested for) that still fails reliably when tried to dereference? > > > > ---- > > [*] Remember that tests are executed when building and are hopefully completely deterministic, so that any potential null-pointer-exception would have shown up. Sure set them to (char const*)0x1; That is not false, and surely will crash if you try to access it (it's odd). I'd only do this once for a local test though. If it still runs fine, you can set them to NULL and add a comment that they're not used. - Aleric ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/100/#review207 ----------------------------------------------------------- On Jan. 18, 2011, 7:29 a.m., Boroondas Gupte wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/100/ > ----------------------------------------------------------- > > (Updated Jan. 18, 2011, 7:29 a.m.) > > > Review request for Viewer. > > > Summary > ------- > > For the reason for this change, see https://jira.secondlife.com/browse/VWR-24487 and https://jira.secondlife.com/browse/VWR-24522 > > What I did: > In indra/llmessage/message_prehash.(h|cpp), I turned everything into constant pointers to constants by search/replace. Then I tried to compile and added const qualifiers in dependent code as needed to stop the compiler complaining. > > Note that comments in indra/llmessage/message_prehash.(h|cpp) say these files have been generated from the message template. If this generation wasn't a one-off thing, the generating code must be changed, too, so it won't override this change here when the generation happens the next time. > > > This addresses bug VWR-24487. > http://jira.secondlife.com/browse/VWR-24487 > > > Diffs > ----- > > doc/contributions.txt fc7e5dcf3059 > indra/llmessage/message_prehash.h fc7e5dcf3059 > indra/llmessage/message_prehash.cpp fc7e5dcf3059 > indra/llprimitive/llprimitive.h fc7e5dcf3059 > indra/llprimitive/llprimitive.cpp fc7e5dcf3059 > indra/llprimitive/llvolumemessage.h fc7e5dcf3059 > indra/llprimitive/llvolumemessage.cpp fc7e5dcf3059 > indra/llui/tests/llurlentry_stub.cpp fc7e5dcf3059 > indra/newview/tests/llremoteparcelrequest_test.cpp fc7e5dcf3059 > > Diff: http://codereview.secondlife.com/r/100/diff > > > Testing > ------- > > Compiled (standalone, 64bit Linux) with and without LL_TESTS. > Started the viewer, logged in, walked and flew around a bit. Everything seems to work. > > > Thanks, > > Boroondas > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110120/e7112838/attachment.htm From wolfpup67 at earthlink.net Thu Jan 20 09:29:06 2011 From: wolfpup67 at earthlink.net (Wolfpup Lowenhar) Date: Thu, 20 Jan 2011 17:29:06 -0000 Subject: [opensource-dev] Review Request: Help Needed to debug small problem with code for STORM-236. Message-ID: <20110120172906.25992.62891@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/112/ ----------------------------------------------------------- Review request for Viewer. Summary ------- This is actually a request for for help to debug what I have done so far to get this working. 1. In the current diff the button dose actualy hide and show according to if Voice is enabled or not. 2. i have two problems at this point. a. the space taken up by the speak button is not freed up b. when the speak button is shown after being hidden there is an error message saying no space avaiable (I think this is related to the fact that the space is not freed to begin with). This addresses bug STORM-236. http://jira.secondlife.com/browse/STORM-236 Diffs ----- doc/contributions.txt 40d0806e9800 indra/newview/llbottomtray.cpp 40d0806e9800 indra/newview/llspeakbutton.cpp 40d0806e9800 indra/newview/skins/default/xui/en/menu_bottomtray.xml 40d0806e9800 Diff: http://codereview.secondlife.com/r/112/diff Testing ------- Thanks, Wolfpup -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110120/65fc9c99/attachment.htm From kf6kjg at gmail.com Thu Jan 20 10:45:33 2011 From: kf6kjg at gmail.com (Cron Stardust) Date: Thu, 20 Jan 2011 18:45:33 -0000 Subject: [opensource-dev] Review Request: Help Needed to debug small problem with code for STORM-236. In-Reply-To: <20110120172906.25992.62891@domU-12-31-38-00-90-68.compute-1.internal> References: <20110120172906.25992.62891@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110120184533.26007.74955@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/112/#review210 ----------------------------------------------------------- Looks like you are only preventing the button from drawing and working, but not actually /removing/ it from the tray. Have you hunted down the code that is used to remove tray buttons when the tray is right-clicked on and an item is checked/unchecked? I would think that that is the functionality that needs to be copied onto the speak button. Maybe, as a different JIRA entry and review, you might consider what it would take to add the speak button to that tray context menu. Once the ability to remove and add the speak button via the context menu is working, it would then seem to me that this entry (STORM-236) would be trivial to implement, as all the core functionality will have been resolved already. Even if the new entry for the context menu wasn't accepted, the core functionality can still be done here. - Cron On Jan. 20, 2011, 9:29 a.m., Wolfpup Lowenhar wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/112/ > ----------------------------------------------------------- > > (Updated Jan. 20, 2011, 9:29 a.m.) > > > Review request for Viewer. > > > Summary > ------- > > This is actually a request for for help to debug what I have done so far to get this working. > 1. In the current diff the button dose actualy hide and show according to if Voice is enabled or not. > 2. i have two problems at this point. > a. the space taken up by the speak button is not freed up > b. when the speak button is shown after being hidden there is an error message saying no space avaiable > (I think this is related to the fact that the space is not freed to begin with). > > > This addresses bug STORM-236. > http://jira.secondlife.com/browse/STORM-236 > > > Diffs > ----- > > doc/contributions.txt 40d0806e9800 > indra/newview/llbottomtray.cpp 40d0806e9800 > indra/newview/llspeakbutton.cpp 40d0806e9800 > indra/newview/skins/default/xui/en/menu_bottomtray.xml 40d0806e9800 > > Diff: http://codereview.secondlife.com/r/112/diff > > > Testing > ------- > > > Thanks, > > Wolfpup > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110120/3be39558/attachment-0001.htm From wolfpup67 at earthlink.net Thu Jan 20 11:08:20 2011 From: wolfpup67 at earthlink.net (Wolfpup Lowenhar) Date: Thu, 20 Jan 2011 19:08:20 -0000 Subject: [opensource-dev] Review Request: Help Needed to debug small problem with code for STORM-236. In-Reply-To: <20110120184533.26007.74955@domU-12-31-38-00-90-68.compute-1.internal> References: <20110120184533.26007.74955@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110120190820.26155.30210@domU-12-31-38-00-90-68.compute-1.internal> > On Jan. 20, 2011, 10:45 a.m., Cron Stardust wrote: > > Looks like you are only preventing the button from drawing and working, but not actually /removing/ it from the tray. Have you hunted down the code that is used to remove tray buttons when the tray is right-clicked on and an item is checked/unchecked? I would think that that is the functionality that needs to be copied onto the speak button. > > > > Maybe, as a different JIRA entry and review, you might consider what it would take to add the speak button to that tray context menu. Once the ability to remove and add the speak button via the context menu is working, it would then seem to me that this entry (STORM-236) would be trivial to implement, as all the core functionality will have been resolved already. Even if the new entry for the context menu wasn't accepted, the core functionality can still be done here. This Issue is for having the button hide(not be drawn) and free up the space that it normally take in the bottom tray. The problem I'm having is with the second part getting the space freed up right. Also the context menu is functional so there are no problems there. - Wolfpup ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/112/#review210 ----------------------------------------------------------- On Jan. 20, 2011, 9:29 a.m., Wolfpup Lowenhar wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/112/ > ----------------------------------------------------------- > > (Updated Jan. 20, 2011, 9:29 a.m.) > > > Review request for Viewer. > > > Summary > ------- > > This is actually a request for for help to debug what I have done so far to get this working. > 1. In the current diff the button dose actualy hide and show according to if Voice is enabled or not. > 2. i have two problems at this point. > a. the space taken up by the speak button is not freed up > b. when the speak button is shown after being hidden there is an error message saying no space avaiable > (I think this is related to the fact that the space is not freed to begin with). > > > This addresses bug STORM-236. > http://jira.secondlife.com/browse/STORM-236 > > > Diffs > ----- > > doc/contributions.txt 40d0806e9800 > indra/newview/llbottomtray.cpp 40d0806e9800 > indra/newview/llspeakbutton.cpp 40d0806e9800 > indra/newview/skins/default/xui/en/menu_bottomtray.xml 40d0806e9800 > > Diff: http://codereview.secondlife.com/r/112/diff > > > Testing > ------- > > > Thanks, > > Wolfpup > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110120/2e4bc752/attachment.htm From oz at lindenlab.com Thu Jan 20 11:40:18 2011 From: oz at lindenlab.com (Oz Linden) Date: Thu, 20 Jan 2011 19:40:18 -0000 Subject: [opensource-dev] Review Request: VWR-24317: Incorrect start up warnings: WARNING: ll_apr_warn_status: APR: No such file or directory In-Reply-To: <20110114204813.17158.23999@domU-12-31-38-00-90-68.compute-1.internal> References: <20110114204813.17158.23999@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110120194018.26332.22619@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/83/#review212 ----------------------------------------------------------- Ship it! - Oz On Jan. 14, 2011, 12:48 p.m., Aleric Inglewood wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/83/ > ----------------------------------------------------------- > > (Updated Jan. 14, 2011, 12:48 p.m.) > > > Review request for Viewer. > > > Summary > ------- > > At start up one can get the following ?warnings?: > > 2010-10-23T12:22:44Z WARNING: ll_apr_warn_status: APR: No such file or directory > 2010-10-23T12:22:44Z WARNING: remove: Attempting to remove filename: /home/aleric/.imprudence/logs/Imprudence.logout_marker > 2010-10-23T12:22:44Z WARNING: ll_apr_warn_status: APR: No such file or directory > 2010-10-23T12:22:44Z WARNING: remove: Attempting to remove filename: /home/aleric/.imprudence/logs/Imprudence.llerror_marker > 2010-10-23T12:22:44Z WARNING: ll_apr_warn_status: APR: No such file or directory > 2010-10-23T12:22:44Z WARNING: remove: Attempting to remove filename: /home/aleric/.imprudence/logs/Imprudence.error_marker > > This is nonsense since it is perfectly ok when those files don?t exist. > > > This addresses bug VWR-24317. > http://jira.secondlife.com/browse/VWR-24317 > > > Diffs > ----- > > indra/newview/llappviewer.cpp b0bd26c5638a > > Diff: http://codereview.secondlife.com/r/83/diff > > > Testing > ------- > > > Thanks, > > Aleric > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110120/ba552ad0/attachment.htm From oz at lindenlab.com Thu Jan 20 11:47:04 2011 From: oz at lindenlab.com (Oz Linden) Date: Thu, 20 Jan 2011 19:47:04 -0000 Subject: [opensource-dev] Review Request: VWR-24317: Incorrect start up warnings: WARNING: remove: Attempting to remove filename: /ramdisk/imprudence/cache/textures/*/*.texture In-Reply-To: <20110116141237.26155.39299@domU-12-31-38-00-90-68.compute-1.internal> References: <20110116141237.26155.39299@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110120194704.26007.88481@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/84/#review213 ----------------------------------------------------------- Ship it! - Oz On Jan. 16, 2011, 6:12 a.m., Aleric Inglewood wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/84/ > ----------------------------------------------------------- > > (Updated Jan. 16, 2011, 6:12 a.m.) > > > Review request for Viewer. > > > Summary > ------- > > This turned out to be a simple matter of trying to remove non-existant files: > A texture with a 'body size' of 0 doesn't have a texture body file. > > > This addresses bug VWR-24317. > http://jira.secondlife.com/browse/VWR-24317 > > > Diffs > ----- > > indra/newview/lltexturecache.cpp b0bd26c5638a > > Diff: http://codereview.secondlife.com/r/84/diff > > > Testing > ------- > > > Thanks, > > Aleric > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110120/8a7ca5a4/attachment.htm From dahliatrimble at gmail.com Thu Jan 20 12:50:49 2011 From: dahliatrimble at gmail.com (Dahlia Trimble) Date: Thu, 20 Jan 2011 12:50:49 -0800 Subject: [opensource-dev] Where is MXP implementation ? In-Reply-To: References: Message-ID: I'm not sure about RealXtend, but there is a MXP implementation in IdealistViewer. You should be able to see the code here: http://forge.opensimulator.org/gf/project/idealistviewer/scmsvn/?action=browse&path=%2Ftrunk%2FIdealistViewer%2FNetwork%2F On Thu, Jan 20, 2011 at 12:34 AM, Rustam Rakhimov wrote: > Where is MXP implementation ? > > hi everybody, > > RealXtend uses MXP but where exactly, i mean which part and where its used > or implemented > > please let me know. if possible file name and function name > > thank you in advance !! > > _______________________________________________ > Policies 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/20110120/cea63f96/attachment.htm From oz at lindenlab.com Thu Jan 20 12:54:17 2011 From: oz at lindenlab.com (Oz Linden) Date: Thu, 20 Jan 2011 20:54:17 -0000 Subject: [opensource-dev] Review Request: VWR-24317: Fix of debug warning (printing of unassigned variable) In-Reply-To: <20110117133226.25766.57123@domU-12-31-38-00-90-68.compute-1.internal> References: <20110117133226.25766.57123@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110120205417.32180.36878@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/87/#review214 ----------------------------------------------------------- Ship it! - Oz On Jan. 17, 2011, 5:32 a.m., Aleric Inglewood wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/87/ > ----------------------------------------------------------- > > (Updated Jan. 17, 2011, 5:32 a.m.) > > > Review request for Viewer. > > > Summary > ------- > > Fixed a typo that I stumbled upon and added quotes, > and changed the warning to print something that makes > more sense ('replacement' is always empty, since we > didn't find it!) > > > This addresses bug VWR-24317. > http://jira.secondlife.com/browse/VWR-24317 > > > Diffs > ----- > > doc/contributions.txt b0bd26c5638a > indra/llui/llnotifications.cpp b0bd26c5638a > > Diff: http://codereview.secondlife.com/r/87/diff > > > Testing > ------- > > > Thanks, > > Aleric > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110120/aaf600ea/attachment.htm From kf6kjg at gmail.com Thu Jan 20 12:59:11 2011 From: kf6kjg at gmail.com (Cron Stardust) Date: Thu, 20 Jan 2011 20:59:11 -0000 Subject: [opensource-dev] Review Request: Help Needed to debug small problem with code for STORM-236. In-Reply-To: <20110120184533.26007.74955@domU-12-31-38-00-90-68.compute-1.internal> References: <20110120184533.26007.74955@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110120205911.32180.21283@domU-12-31-38-00-90-68.compute-1.internal> > On Jan. 20, 2011, 10:45 a.m., Cron Stardust wrote: > > Looks like you are only preventing the button from drawing and working, but not actually /removing/ it from the tray. Have you hunted down the code that is used to remove tray buttons when the tray is right-clicked on and an item is checked/unchecked? I would think that that is the functionality that needs to be copied onto the speak button. > > > > Maybe, as a different JIRA entry and review, you might consider what it would take to add the speak button to that tray context menu. Once the ability to remove and add the speak button via the context menu is working, it would then seem to me that this entry (STORM-236) would be trivial to implement, as all the core functionality will have been resolved already. Even if the new entry for the context menu wasn't accepted, the core functionality can still be done here. > > Wolfpup Lowenhar wrote: > This Issue is for having the button hide(not be drawn) and free up the space that it normally take in the bottom tray. The problem I'm having is with the second part getting the space freed up right. Also the context menu is functional so there are no problems there. As of 2.6.0.219259 the Speak button is not able to be removed from the tray using the context menu. However, the point I was trying to make was that the underlying functionality of what you are trying to accomplish here, that of removing a button and freeing up the space, is currently accomplished by the underlying functionality that the tray context menu taps into. Whether a simple (hah!) study of that code's functionality will give you what you need, or whether you do a complementary implementation of adding the (de)activation of the Speak button to the context menu, is up to you. I simply was pointing out that the underlying task is accomplished at another, potentially missed, location. If you have already studied and implemented the button (de)activation code that the tray context menu uses, then my suggestion is just noise. On the other hand, exploring what it would take to make the Speak button go away or come back via the context menu allows you to explore another code section that might result in two birds being killed with one stone: making the button removable for those who only use the keyboard or mouse toggle, and giving you the code to make the button go away when Voice isn't active. Hope that clears up the situation. To me the problem here isn't the tasks of "make the button hide" and then "free up the space" - it's about how to properly remove and re-add the button, similar to how the tray context menu works, just with a different trigger: the voice setting. - Cron ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/112/#review210 ----------------------------------------------------------- On Jan. 20, 2011, 9:29 a.m., Wolfpup Lowenhar wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/112/ > ----------------------------------------------------------- > > (Updated Jan. 20, 2011, 9:29 a.m.) > > > Review request for Viewer. > > > Summary > ------- > > This is actually a request for for help to debug what I have done so far to get this working. > 1. In the current diff the button dose actualy hide and show according to if Voice is enabled or not. > 2. i have two problems at this point. > a. the space taken up by the speak button is not freed up > b. when the speak button is shown after being hidden there is an error message saying no space avaiable > (I think this is related to the fact that the space is not freed to begin with). > > > This addresses bug STORM-236. > http://jira.secondlife.com/browse/STORM-236 > > > Diffs > ----- > > doc/contributions.txt 40d0806e9800 > indra/newview/llbottomtray.cpp 40d0806e9800 > indra/newview/llspeakbutton.cpp 40d0806e9800 > indra/newview/skins/default/xui/en/menu_bottomtray.xml 40d0806e9800 > > Diff: http://codereview.secondlife.com/r/112/diff > > > Testing > ------- > > > Thanks, > > Wolfpup > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110120/daf3e2d5/attachment.htm From wolfpup67 at earthlink.net Thu Jan 20 13:16:06 2011 From: wolfpup67 at earthlink.net (Wolfpup Lowenhar) Date: Thu, 20 Jan 2011 21:16:06 -0000 Subject: [opensource-dev] Review Request: Help Needed to debug small problem with code for STORM-236. In-Reply-To: <20110120184533.26007.74955@domU-12-31-38-00-90-68.compute-1.internal> References: <20110120184533.26007.74955@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110120211606.32180.46076@domU-12-31-38-00-90-68.compute-1.internal> > On Jan. 20, 2011, 10:45 a.m., Cron Stardust wrote: > > Looks like you are only preventing the button from drawing and working, but not actually /removing/ it from the tray. Have you hunted down the code that is used to remove tray buttons when the tray is right-clicked on and an item is checked/unchecked? I would think that that is the functionality that needs to be copied onto the speak button. > > > > Maybe, as a different JIRA entry and review, you might consider what it would take to add the speak button to that tray context menu. Once the ability to remove and add the speak button via the context menu is working, it would then seem to me that this entry (STORM-236) would be trivial to implement, as all the core functionality will have been resolved already. Even if the new entry for the context menu wasn't accepted, the core functionality can still be done here. > > Wolfpup Lowenhar wrote: > This Issue is for having the button hide(not be drawn) and free up the space that it normally take in the bottom tray. The problem I'm having is with the second part getting the space freed up right. Also the context menu is functional so there are no problems there. > > Cron Stardust wrote: > As of 2.6.0.219259 the Speak button is not able to be removed from the tray using the context menu. However, the point I was trying to make was that the underlying functionality of what you are trying to accomplish here, that of removing a button and freeing up the space, is currently accomplished by the underlying functionality that the tray context menu taps into. Whether a simple (hah!) study of that code's functionality will give you what you need, or whether you do a complementary implementation of adding the (de)activation of the Speak button to the context menu, is up to you. > > I simply was pointing out that the underlying task is accomplished at another, potentially missed, location. If you have already studied and implemented the button (de)activation code that the tray context menu uses, then my suggestion is just noise. On the other hand, exploring what it would take to make the Speak button go away or come back via the context menu allows you to explore another code section that might result in two birds being killed with one stone: making the button removable for those who only use the keyboard or mouse toggle, and giving you the code to make the button go away when Voice isn't active. > > Hope that clears up the situation. To me the problem here isn't the tasks of "make the button hide" and then "free up the space" - it's about how to properly remove and re-add the button, similar to how the tray context menu works, just with a different trigger: the voice setting. Cron, I wonder if you have even looked at the diff as im working on adding all the functionality that you say is not present. Yes there is some thing im missing other wise I would not be receiving an error in my local repository. this work is only in my local repository at present as it is not yet ready to be posted for review but as Oz suggested i placed this here with the subject "Help Needed" as i believe im missing some thing important in the code and there for getting a error. This is ACTUALLY a request for ASSISTANCE from the open source community and not a review request. - Wolfpup ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/112/#review210 ----------------------------------------------------------- On Jan. 20, 2011, 9:29 a.m., Wolfpup Lowenhar wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/112/ > ----------------------------------------------------------- > > (Updated Jan. 20, 2011, 9:29 a.m.) > > > Review request for Viewer. > > > Summary > ------- > > This is actually a request for for help to debug what I have done so far to get this working. > 1. In the current diff the button dose actualy hide and show according to if Voice is enabled or not. > 2. i have two problems at this point. > a. the space taken up by the speak button is not freed up > b. when the speak button is shown after being hidden there is an error message saying no space avaiable > (I think this is related to the fact that the space is not freed to begin with). > > > This addresses bug STORM-236. > http://jira.secondlife.com/browse/STORM-236 > > > Diffs > ----- > > doc/contributions.txt 40d0806e9800 > indra/newview/llbottomtray.cpp 40d0806e9800 > indra/newview/llspeakbutton.cpp 40d0806e9800 > indra/newview/skins/default/xui/en/menu_bottomtray.xml 40d0806e9800 > > Diff: http://codereview.secondlife.com/r/112/diff > > > Testing > ------- > > > Thanks, > > Wolfpup > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110120/96562c04/attachment-0001.htm From kf6kjg at gmail.com Thu Jan 20 14:14:08 2011 From: kf6kjg at gmail.com (Cron Stardust) Date: Thu, 20 Jan 2011 22:14:08 -0000 Subject: [opensource-dev] Review Request: Help Needed to debug small problem with code for STORM-236. In-Reply-To: <20110120184533.26007.74955@domU-12-31-38-00-90-68.compute-1.internal> References: <20110120184533.26007.74955@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110120221408.25760.47601@domU-12-31-38-00-90-68.compute-1.internal> > On Jan. 20, 2011, 10:45 a.m., Cron Stardust wrote: > > Looks like you are only preventing the button from drawing and working, but not actually /removing/ it from the tray. Have you hunted down the code that is used to remove tray buttons when the tray is right-clicked on and an item is checked/unchecked? I would think that that is the functionality that needs to be copied onto the speak button. > > > > Maybe, as a different JIRA entry and review, you might consider what it would take to add the speak button to that tray context menu. Once the ability to remove and add the speak button via the context menu is working, it would then seem to me that this entry (STORM-236) would be trivial to implement, as all the core functionality will have been resolved already. Even if the new entry for the context menu wasn't accepted, the core functionality can still be done here. > > Wolfpup Lowenhar wrote: > This Issue is for having the button hide(not be drawn) and free up the space that it normally take in the bottom tray. The problem I'm having is with the second part getting the space freed up right. Also the context menu is functional so there are no problems there. > > Cron Stardust wrote: > As of 2.6.0.219259 the Speak button is not able to be removed from the tray using the context menu. However, the point I was trying to make was that the underlying functionality of what you are trying to accomplish here, that of removing a button and freeing up the space, is currently accomplished by the underlying functionality that the tray context menu taps into. Whether a simple (hah!) study of that code's functionality will give you what you need, or whether you do a complementary implementation of adding the (de)activation of the Speak button to the context menu, is up to you. > > I simply was pointing out that the underlying task is accomplished at another, potentially missed, location. If you have already studied and implemented the button (de)activation code that the tray context menu uses, then my suggestion is just noise. On the other hand, exploring what it would take to make the Speak button go away or come back via the context menu allows you to explore another code section that might result in two birds being killed with one stone: making the button removable for those who only use the keyboard or mouse toggle, and giving you the code to make the button go away when Voice isn't active. > > Hope that clears up the situation. To me the problem here isn't the tasks of "make the button hide" and then "free up the space" - it's about how to properly remove and re-add the button, similar to how the tray context menu works, just with a different trigger: the voice setting. > > Wolfpup Lowenhar wrote: > Cron, > I wonder if you have even looked at the diff as im working on adding all the functionality that you say is not present. Yes there is some thing im missing other wise I would not be receiving an error in my local repository. this work is only in my local repository at present as it is not yet ready to be posted for review but as Oz suggested i placed this here with the subject "Help Needed" as i believe im missing some thing important in the code and there for getting a error. This is ACTUALLY a request for ASSISTANCE from the open source community and not a review request. Wolfpup, I am trying to give assistance. Just like I assist my fellow CS students in the programming labs when I'm not familiar with the details of what they are implementing. Yes, I have looked over the diff. Yet since I have never gotten a build environment that worked for more than a day, I didn't have the time (back when I did have the time) to learn the ins and outs of the viewer codebase. Since then I've not had the time to do more than glance over other people's code. Hopefully I will learn enough from that to start working changes myself when I have time again. Since I don't have a build env, I can't help with straight debugging. However, I believe that my points and information may be valid and useful in helping direct your mind to a solution, even though I cannot supply one. Often when I have a coding problem, I'll even go so far as to explain it to an artist: their eyes may glaze over, but in their ignorance of how things work in programming sometimes makes them able to point out areas to explore or solutions that I never would have thought of. Such is what I'm trying to do here: provide you with a way around the barrier. Not by going straight through the barrier, as I don't have that solution, but by pointing out a possible doorway further down the wall. However, to keep up the simile, if you've already tried that door and found it locked, then let me know, and I'll either try to point out another door, or shut up waiting for another person to find a way through. - Cron ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/112/#review210 ----------------------------------------------------------- On Jan. 20, 2011, 9:29 a.m., Wolfpup Lowenhar wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/112/ > ----------------------------------------------------------- > > (Updated Jan. 20, 2011, 9:29 a.m.) > > > Review request for Viewer. > > > Summary > ------- > > This is actually a request for for help to debug what I have done so far to get this working. > 1. In the current diff the button dose actualy hide and show according to if Voice is enabled or not. > 2. i have two problems at this point. > a. the space taken up by the speak button is not freed up > b. when the speak button is shown after being hidden there is an error message saying no space avaiable > (I think this is related to the fact that the space is not freed to begin with). > > > This addresses bug STORM-236. > http://jira.secondlife.com/browse/STORM-236 > > > Diffs > ----- > > doc/contributions.txt 40d0806e9800 > indra/newview/llbottomtray.cpp 40d0806e9800 > indra/newview/llspeakbutton.cpp 40d0806e9800 > indra/newview/skins/default/xui/en/menu_bottomtray.xml 40d0806e9800 > > Diff: http://codereview.secondlife.com/r/112/diff > > > Testing > ------- > > > Thanks, > > Wolfpup > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110120/6f813b40/attachment.htm From babytje_ab at live.com Thu Jan 20 14:28:32 2011 From: babytje_ab at live.com (Alexandrea Fride) Date: Thu, 20 Jan 2011 22:28:32 -0000 Subject: [opensource-dev] Review Request: Help Needed to debug small problem with code for STORM-236. In-Reply-To: <20110120184533.26007.74955@domU-12-31-38-00-90-68.compute-1.internal> References: <20110120184533.26007.74955@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110120222832.25763.90424@domU-12-31-38-00-90-68.compute-1.internal> > On Jan. 20, 2011, 10:45 a.m., Cron Stardust wrote: > > Looks like you are only preventing the button from drawing and working, but not actually /removing/ it from the tray. Have you hunted down the code that is used to remove tray buttons when the tray is right-clicked on and an item is checked/unchecked? I would think that that is the functionality that needs to be copied onto the speak button. > > > > Maybe, as a different JIRA entry and review, you might consider what it would take to add the speak button to that tray context menu. Once the ability to remove and add the speak button via the context menu is working, it would then seem to me that this entry (STORM-236) would be trivial to implement, as all the core functionality will have been resolved already. Even if the new entry for the context menu wasn't accepted, the core functionality can still be done here. > > Wolfpup Lowenhar wrote: > This Issue is for having the button hide(not be drawn) and free up the space that it normally take in the bottom tray. The problem I'm having is with the second part getting the space freed up right. Also the context menu is functional so there are no problems there. > > Cron Stardust wrote: > As of 2.6.0.219259 the Speak button is not able to be removed from the tray using the context menu. However, the point I was trying to make was that the underlying functionality of what you are trying to accomplish here, that of removing a button and freeing up the space, is currently accomplished by the underlying functionality that the tray context menu taps into. Whether a simple (hah!) study of that code's functionality will give you what you need, or whether you do a complementary implementation of adding the (de)activation of the Speak button to the context menu, is up to you. > > I simply was pointing out that the underlying task is accomplished at another, potentially missed, location. If you have already studied and implemented the button (de)activation code that the tray context menu uses, then my suggestion is just noise. On the other hand, exploring what it would take to make the Speak button go away or come back via the context menu allows you to explore another code section that might result in two birds being killed with one stone: making the button removable for those who only use the keyboard or mouse toggle, and giving you the code to make the button go away when Voice isn't active. > > Hope that clears up the situation. To me the problem here isn't the tasks of "make the button hide" and then "free up the space" - it's about how to properly remove and re-add the button, similar to how the tray context menu works, just with a different trigger: the voice setting. > > Wolfpup Lowenhar wrote: > Cron, > I wonder if you have even looked at the diff as im working on adding all the functionality that you say is not present. Yes there is some thing im missing other wise I would not be receiving an error in my local repository. this work is only in my local repository at present as it is not yet ready to be posted for review but as Oz suggested i placed this here with the subject "Help Needed" as i believe im missing some thing important in the code and there for getting a error. This is ACTUALLY a request for ASSISTANCE from the open source community and not a review request. > > Cron Stardust wrote: > Wolfpup, I am trying to give assistance. Just like I assist my fellow CS students in the programming labs when I'm not familiar with the details of what they are implementing. Yes, I have looked over the diff. Yet since I have never gotten a build environment that worked for more than a day, I didn't have the time (back when I did have the time) to learn the ins and outs of the viewer codebase. Since then I've not had the time to do more than glance over other people's code. Hopefully I will learn enough from that to start working changes myself when I have time again. Since I don't have a build env, I can't help with straight debugging. However, I believe that my points and information may be valid and useful in helping direct your mind to a solution, even though I cannot supply one. > > Often when I have a coding problem, I'll even go so far as to explain it to an artist: their eyes may glaze over, but in their ignorance of how things work in programming sometimes makes them able to point out areas to explore or solutions that I never would have thought of. Such is what I'm trying to do here: provide you with a way around the barrier. Not by going straight through the barrier, as I don't have that solution, but by pointing out a possible doorway further down the wall. > > However, to keep up the simile, if you've already tried that door and found it locked, then let me know, and I'll either try to point out another door, or shut up waiting for another person to find a way through. > Shouldend 'EnableVoiceChat' not also be defined in settings.xml? seeing it use gSavedSettings? other then that dident tested this yet but did see you miss that Greetings - Alexandrea ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/112/#review210 ----------------------------------------------------------- On Jan. 20, 2011, 9:29 a.m., Wolfpup Lowenhar wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/112/ > ----------------------------------------------------------- > > (Updated Jan. 20, 2011, 9:29 a.m.) > > > Review request for Viewer. > > > Summary > ------- > > This is actually a request for for help to debug what I have done so far to get this working. > 1. In the current diff the button dose actualy hide and show according to if Voice is enabled or not. > 2. i have two problems at this point. > a. the space taken up by the speak button is not freed up > b. when the speak button is shown after being hidden there is an error message saying no space avaiable > (I think this is related to the fact that the space is not freed to begin with). > > > This addresses bug STORM-236. > http://jira.secondlife.com/browse/STORM-236 > > > Diffs > ----- > > doc/contributions.txt 40d0806e9800 > indra/newview/llbottomtray.cpp 40d0806e9800 > indra/newview/llspeakbutton.cpp 40d0806e9800 > indra/newview/skins/default/xui/en/menu_bottomtray.xml 40d0806e9800 > > Diff: http://codereview.secondlife.com/r/112/diff > > > Testing > ------- > > > Thanks, > > Wolfpup > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110120/e9435e63/attachment-0001.htm From babytje_ab at live.com Thu Jan 20 14:29:49 2011 From: babytje_ab at live.com (Alexandrea Fride) Date: Thu, 20 Jan 2011 22:29:49 -0000 Subject: [opensource-dev] Review Request: Help Needed to debug small problem with code for STORM-236. In-Reply-To: <20110120184533.26007.74955@domU-12-31-38-00-90-68.compute-1.internal> References: <20110120184533.26007.74955@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110120222949.25764.73497@domU-12-31-38-00-90-68.compute-1.internal> > On Jan. 20, 2011, 10:45 a.m., Cron Stardust wrote: > > Looks like you are only preventing the button from drawing and working, but not actually /removing/ it from the tray. Have you hunted down the code that is used to remove tray buttons when the tray is right-clicked on and an item is checked/unchecked? I would think that that is the functionality that needs to be copied onto the speak button. > > > > Maybe, as a different JIRA entry and review, you might consider what it would take to add the speak button to that tray context menu. Once the ability to remove and add the speak button via the context menu is working, it would then seem to me that this entry (STORM-236) would be trivial to implement, as all the core functionality will have been resolved already. Even if the new entry for the context menu wasn't accepted, the core functionality can still be done here. > > Wolfpup Lowenhar wrote: > This Issue is for having the button hide(not be drawn) and free up the space that it normally take in the bottom tray. The problem I'm having is with the second part getting the space freed up right. Also the context menu is functional so there are no problems there. > > Cron Stardust wrote: > As of 2.6.0.219259 the Speak button is not able to be removed from the tray using the context menu. However, the point I was trying to make was that the underlying functionality of what you are trying to accomplish here, that of removing a button and freeing up the space, is currently accomplished by the underlying functionality that the tray context menu taps into. Whether a simple (hah!) study of that code's functionality will give you what you need, or whether you do a complementary implementation of adding the (de)activation of the Speak button to the context menu, is up to you. > > I simply was pointing out that the underlying task is accomplished at another, potentially missed, location. If you have already studied and implemented the button (de)activation code that the tray context menu uses, then my suggestion is just noise. On the other hand, exploring what it would take to make the Speak button go away or come back via the context menu allows you to explore another code section that might result in two birds being killed with one stone: making the button removable for those who only use the keyboard or mouse toggle, and giving you the code to make the button go away when Voice isn't active. > > Hope that clears up the situation. To me the problem here isn't the tasks of "make the button hide" and then "free up the space" - it's about how to properly remove and re-add the button, similar to how the tray context menu works, just with a different trigger: the voice setting. > > Wolfpup Lowenhar wrote: > Cron, > I wonder if you have even looked at the diff as im working on adding all the functionality that you say is not present. Yes there is some thing im missing other wise I would not be receiving an error in my local repository. this work is only in my local repository at present as it is not yet ready to be posted for review but as Oz suggested i placed this here with the subject "Help Needed" as i believe im missing some thing important in the code and there for getting a error. This is ACTUALLY a request for ASSISTANCE from the open source community and not a review request. > > Cron Stardust wrote: > Wolfpup, I am trying to give assistance. Just like I assist my fellow CS students in the programming labs when I'm not familiar with the details of what they are implementing. Yes, I have looked over the diff. Yet since I have never gotten a build environment that worked for more than a day, I didn't have the time (back when I did have the time) to learn the ins and outs of the viewer codebase. Since then I've not had the time to do more than glance over other people's code. Hopefully I will learn enough from that to start working changes myself when I have time again. Since I don't have a build env, I can't help with straight debugging. However, I believe that my points and information may be valid and useful in helping direct your mind to a solution, even though I cannot supply one. > > Often when I have a coding problem, I'll even go so far as to explain it to an artist: their eyes may glaze over, but in their ignorance of how things work in programming sometimes makes them able to point out areas to explore or solutions that I never would have thought of. Such is what I'm trying to do here: provide you with a way around the barrier. Not by going straight through the barrier, as I don't have that solution, but by pointing out a possible doorway further down the wall. > > However, to keep up the simile, if you've already tried that door and found it locked, then let me know, and I'll either try to point out another door, or shut up waiting for another person to find a way through. > > > Alexandrea Fride wrote: > Shouldend 'EnableVoiceChat' not also be defined in settings.xml? seeing it use gSavedSettings? other then that dident tested this yet but did see you miss that > > Greetings ignore that :) - Alexandrea ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/112/#review210 ----------------------------------------------------------- On Jan. 20, 2011, 9:29 a.m., Wolfpup Lowenhar wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/112/ > ----------------------------------------------------------- > > (Updated Jan. 20, 2011, 9:29 a.m.) > > > Review request for Viewer. > > > Summary > ------- > > This is actually a request for for help to debug what I have done so far to get this working. > 1. In the current diff the button dose actualy hide and show according to if Voice is enabled or not. > 2. i have two problems at this point. > a. the space taken up by the speak button is not freed up > b. when the speak button is shown after being hidden there is an error message saying no space avaiable > (I think this is related to the fact that the space is not freed to begin with). > > > This addresses bug STORM-236. > http://jira.secondlife.com/browse/STORM-236 > > > Diffs > ----- > > doc/contributions.txt 40d0806e9800 > indra/newview/llbottomtray.cpp 40d0806e9800 > indra/newview/llspeakbutton.cpp 40d0806e9800 > indra/newview/skins/default/xui/en/menu_bottomtray.xml 40d0806e9800 > > Diff: http://codereview.secondlife.com/r/112/diff > > > Testing > ------- > > > Thanks, > > Wolfpup > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110120/94fa343b/attachment.htm From sllists at boroon.dasgupta.ch Thu Jan 20 14:57:35 2011 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Thu, 20 Jan 2011 22:57:35 -0000 Subject: [opensource-dev] Review Request: make PREHASH variables char const* const In-Reply-To: <20110118152944.26007.14045@domU-12-31-38-00-90-68.compute-1.internal> References: <20110118152944.26007.14045@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110120225735.25766.11933@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/100/ ----------------------------------------------------------- (Updated Jan. 20, 2011, 2:57 p.m.) Review request for Viewer and Seth ProductEngine. Changes ------- Successfully tested with (char const*)0x1, so using NULL pointers, now. Adding Seth as reviewer, as he introduced the place holder data that would now get replaced by NULL. Summary ------- For the reason for this change, see https://jira.secondlife.com/browse/VWR-24487 and https://jira.secondlife.com/browse/VWR-24522 What I did: In indra/llmessage/message_prehash.(h|cpp), I turned everything into constant pointers to constants by search/replace. Then I tried to compile and added const qualifiers in dependent code as needed to stop the compiler complaining. Note that comments in indra/llmessage/message_prehash.(h|cpp) say these files have been generated from the message template. If this generation wasn't a one-off thing, the generating code must be changed, too, so it won't override this change here when the generation happens the next time. This addresses bug VWR-24487. http://jira.secondlife.com/browse/VWR-24487 Diffs (updated) ----- doc/contributions.txt fc7e5dcf3059 indra/llmessage/message_prehash.h fc7e5dcf3059 indra/llmessage/message_prehash.cpp fc7e5dcf3059 indra/llprimitive/llprimitive.h fc7e5dcf3059 indra/llprimitive/llprimitive.cpp fc7e5dcf3059 indra/llprimitive/llvolumemessage.h fc7e5dcf3059 indra/llprimitive/llvolumemessage.cpp fc7e5dcf3059 indra/llui/tests/llurlentry_stub.cpp fc7e5dcf3059 indra/newview/tests/llremoteparcelrequest_test.cpp fc7e5dcf3059 Diff: http://codereview.secondlife.com/r/100/diff Testing (updated) ------- Compiled (standalone, 64bit Linux) with and without LL_TESTS. Started the viewer, logged in, walked and flew around a bit. Everything seems to work. Locally set _PREHASH_AgentData and _PREHASH_AgentID to (char const*)0x1 in indra/llui/tests/llurlentry_stub.cpp and indra/newview/tests/llremoteparcelrequest_test.cpp to verify they actually are never dereferenced, even when not NULL, so that using NULL pointers instead of place holder data won't change what code paths gets tested. Both tests binaries executed without crashes and all the contained tests passed. Thanks, Boroondas -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110120/3bbd5972/attachment.htm From wolfpup67 at earthlink.net Thu Jan 20 18:37:18 2011 From: wolfpup67 at earthlink.net (Wolfpup Lowenhar) Date: Fri, 21 Jan 2011 02:37:18 -0000 Subject: [opensource-dev] Review Request: STORM-236 Actual Code Review Message-ID: <20110121023718.32180.15352@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/113/ ----------------------------------------------------------- Review request for Viewer. Summary ------- This allows the Speak Button to auto-hide for those that do not use Voice at all. This addresses bug STORM-236. http://jira.secondlife.com/browse/STORM-236 Diffs ----- doc/contributions.txt 9c7d543fd15d indra/newview/llbottomtray.h 9c7d543fd15d indra/newview/llbottomtray.cpp 9c7d543fd15d indra/newview/llspeakbutton.cpp 9c7d543fd15d indra/newview/skins/default/xui/en/menu_bottomtray.xml 9c7d543fd15d Diff: http://codereview.secondlife.com/r/113/diff Testing ------- Built locally and did the following: 1 Verified that when Voice is toggled via the preference panel the Speak Button auto hid/showed. 2 Verified that drag and drop functionality of the Speak Button was not affected. 3 Went to a non-Voice area with Voice active and verified that button was still there but grayed out. Thanks, Wolfpup -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110121/93ec6bd7/attachment-0001.htm From akanevsky at productengine.com Thu Jan 20 22:53:52 2011 From: akanevsky at productengine.com (Anya Kanevsky) Date: Thu, 20 Jan 2011 22:53:52 -0800 Subject: [opensource-dev] Daily Scrum Summary - Thursday, January 20, 2011 Message-ID: Thursday, January 20, 2011 General Notes ------------------------------ - MMOTD: Oz - Please remember to put descriptions next to the jira number in your report when possible. Team Status ------------------------------ Merov Linden ------------------------------ *PAST* - STORM-745 : KDU Perf : Got Linux data. The results are strange so I decided to run on Mac again before posting. - STORM-748 : KDU_X86_INTRINSICS : Discovered autobuild recent changes, need to update kdu-autobuild to take them into account (TC build broken right now). In progress. - Bunch of LL meetings *FUTURE* - SH-761 : test and move to integration - STORM-748 : Fix TC builds - STORM-745 : Re-run Mac stats *IMPEDIMENTS* - none Oz Linden ------------------------------ *PAST* - Merge Monkey - Office Hour - Wiki updates to Snowstorm calendar & meetings *FUTURE* - Merge Monkey - Patch triage from codereview *IMPEDIMENTS* - moving large amounts of slush around :-( Q Linden ------------------------------ *PAST* - STORM-725 - STORM-864 - VWR-24426 - SOCIAL-452 - STORM-243 - Internal meetings - Snowstorm weekly meeting - 2.5 beta 1 *FUTURE* - VWR-24426 - Dr's appt today - triage *IMPEDIMENTS* - Not enough rope to tie esbee to her chair. :( Esbee Linden ------------------------------ *PAST* - Meetings, Email - My last OH :( - Jira ticket reviews and cleanup *FUTURE* - Review Snowstorm Team product backlog and bug log - Tix which require feedback: STORM-28, -812, -226, -174 - Review developer build for the tix in the PO review queue: STORM-2, -383, -484, -844, -834, -832, -715 https://jira.secondlife.com/secure/IssueNavigator.jspa?requestId=13662&mode=hide - Hopefully work on STORM-26 w/Q - Review tickets assigned to me *IMPEDIMENTS* - None Paul ProductEngine ------------------------------ *PAST* - BUG STORM-665 (User is not able to view full name of Group's founder in the Group Profile) - Investigated and resolved as cannot reproduce - BUG STORM-629 (Place Rating text is quoted and is not translated in Polish localization) - Investigated and assigned to Eli. - BUG STORM-612 ('Didn't find..' text overlaps My inventory folder name in Pick Texture window) - Tried to reproduce. Tomorrow will try again. - BUG STORM-680 (Avaline callers are added to the Recent list) - Worked on this bug, but it'll take much more time to fix it without debugger. For some reason voice is unavailable in debug mode (in Linux). As tomorrow I'll install Windows on my machine, in which voice is working in debug mode, I'll fix it. - BUG STORM-513 ("Allow media to auto - play" check-box is enable after Media check-box was unchecked) - WIP. 90%. Estimate ~ 1 hour. *FUTURE* - Install Windows 7 on my machine as second OS. - BUG STORM-513 ("Allow media to auto - play" check-box is enable after Media check-box was unchecked) - BUG STORM-680 (Avaline callers are added to the Recent list) *IMPEDIMENTS* - none Seth Productengine ------------------------------ *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. - Resolved as "Cannot Reproduce". Inventory sorting seems to work as expected if inventory items could be sorted by date and folders are always sorted by name. - Story (STORM-526) Log out failure during Login causes loss of pending offers, including inventory - Investigating. *FUTURE* - Story (STORM-526) Log out failure during Login causes loss of pending offers, including inventory *IMPEDIMENTS* - none Vadim Productengine ------------------------------ *PAST* - Bug STORM-373 ('Rename' is sometimes disabled in inventory item context menu): - Submitted fix. - Bug STORM-465 (Missing Strings from strings.xml): - Completed the fix and posted it for review. - Bug STORM-348 ("Edit this shape button" button and "lock" icon are shown after each body part name after resizing the floater): - Fixed. *FUTURE* - Pick something from the bug queue. *IMPEDIMENTS* - Unclear what to do with STORM-174 (Checkbox needed to save inventory scripts as Mono): the feature requires simulator work. - Please write up an SVC issue and link to STORM-174 - No clear acceptance criteria for STORM-226 (Floating Text aligns improperly). - Q will close issue - Need an answer from PO in STORM-610 (Changes to Environment Editor: water color change is not saved). - it?s a bug Wolfpup Lowenhar ------------------------------ *PAST* - Worked @ RL and in world. - STORM-236 : Made Changes that were sugested @ the Snowstorm OH also followed Oz's sugestion to use the RB system to get help with code. *FUTURE* - Work @ RL and in world. - STORM-236 : Wait for replies to RB to see what others suggest as fixes and try them. - VWR-24256 : continue to monitor. *IMPEDIMENTS* - Not enough time between working in-world and at real job to actually work on code. Jonathan Yap ------------------------------ *PAST* - STORM-869 (Minor irregulaties in settings.xml) Done - Created VWR-24536 (Allow residents to change the color of scroll bars) - Updated three areas in https://wiki.secondlife.com/wiki/Viewer_2_Microsoft_Windows_Builds *FUTURE* - STORM-845 (Up arrow icon on nearby chat for "Shows/hides nearby chat log" always shows as an up arrow. Should change to down arrow to indicate close when log is open.) *IMPEDIMENTS* - None -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110120/b47ea564/attachment-0001.htm From merov at lindenlab.com Thu Jan 20 22:57:19 2011 From: merov at lindenlab.com (Merov Linden) Date: Fri, 21 Jan 2011 06:57:19 -0000 Subject: [opensource-dev] Review Request: VWR-24312: Massively duplicated objects (part 2) In-Reply-To: <20110116135319.26155.13876@domU-12-31-38-00-90-68.compute-1.internal> References: <20110116135319.26155.13876@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110121065719.26332.52149@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/81/#review221 ----------------------------------------------------------- I fail to see how any of those changes "massively prevents object duplication". I don't disagree with any of them but I don't see much value in any either. Sure, there are different ways to skin a cat and some are better. Still, these changes will likely make upcoming merges conflict annoyingly and make the life of the maintainers (i.e. mine and Oz) horrid. It reminded me of this post by another (more famous) Open Source maintainer: http://tirania.org/blog/archive/2010/Dec-31.html - Merov On Jan. 16, 2011, 5:53 a.m., Aleric Inglewood wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/81/ > ----------------------------------------------------------- > > (Updated Jan. 16, 2011, 5:53 a.m.) > > > Review request for Viewer. > > > Summary > ------- > > Turns out that most of my SNOW-800 patch was included in Viewer 2 (albeit without crediting me). > However, not everything was used and some more cleaning up was possible. > > After this patch, and when compiling with optimization, there are no duplicates left > anymore that shouldn't be there in the first place: apart from the debug stream > iostream guard variable, there are several static variables with the same name (r, r1, > r2, etc) but that indeed actually different symbol objects. Then there are a few > constant POD arrays that are duplicated a hand full of times because they are > accessed with a variable index (so optimizing them away is not possible). I left them > like that (although defining those as extern as well would have been more consistent > and not slower; in fact it would be faster theoretically because those arrays could > share the same cache page then). > > > This addresses bug VWR-24312. > http://jira.secondlife.com/browse/VWR-24312 > > > Diffs > ----- > > doc/contributions.txt 422f636c3343 > indra/llcharacter/llanimationstates.cpp 422f636c3343 > indra/llcommon/llavatarconstants.h 422f636c3343 > indra/llcommon/lllslconstants.h 422f636c3343 > indra/llcommon/llmetricperformancetester.h 422f636c3343 > indra/llmath/llcamera.h 422f636c3343 > indra/llmath/llcamera.cpp 422f636c3343 > indra/newview/llviewerobject.cpp 422f636c3343 > indra/newview/llvoavatar.cpp 422f636c3343 > indra/newview/llvosky.h 422f636c3343 > indra/newview/llvosky.cpp 422f636c3343 > > Diff: http://codereview.secondlife.com/r/81/diff > > > Testing > ------- > > Compiled with optimization and then running readelf on the executable to find duplicated symbols. > > > Thanks, > > Aleric > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110121/9ad8fd8f/attachment.htm From merov at lindenlab.com Thu Jan 20 23:02:41 2011 From: merov at lindenlab.com (Merov Linden) Date: Fri, 21 Jan 2011 07:02:41 -0000 Subject: [opensource-dev] Review Request: Storm-844 "More" should be "Less" when Media Control is open In-Reply-To: <20110112140224.6852.84692@domU-12-31-38-00-90-68.compute-1.internal> References: <20110112140224.6852.84692@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110121070241.29886.48775@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/78/#review222 ----------------------------------------------------------- Ship it! Seems correct. Ship it modulo the "don't shuffle the contributions" mentioned by Oz. - Merov On Jan. 12, 2011, 6:02 a.m., Jonathan Yap wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/78/ > ----------------------------------------------------------- > > (Updated Jan. 12, 2011, 6:02 a.m.) > > > Review request for Viewer. > > > Summary > ------- > > "More" should be "Less" when Media Control is open > > This is a trivial text change in an xml file. The reason I am posting this here is due to some confusion using label_selected. In this case having it set to a different value than when label is set to seems to have no effect, so I have made them identical. > > I scanned all the xml files and there are only about 5 places where label_selected is different from the preceding label= value. > > Is there any reason to revert back to having them set to different values? > i.e. label="More" and label_selected="Less" > > > This addresses bug storm-844. > http://jira.secondlife.com/browse/storm-844 > > > Diffs > ----- > > doc/contributions.txt 179e0754a27d > indra/newview/skins/default/xui/en/panel_nearby_media.xml 179e0754a27d > > Diff: http://codereview.secondlife.com/r/78/diff > > > Testing > ------- > > > Thanks, > > Jonathan > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110121/2b548c45/attachment.htm From merov at lindenlab.com Thu Jan 20 23:08:59 2011 From: merov at lindenlab.com (Merov Linden) Date: Fri, 21 Jan 2011 07:08:59 -0000 Subject: [opensource-dev] Review Request: VWR-24311: Uninstall packages that are renewed. In-Reply-To: <20110117132437.25763.68327@domU-12-31-38-00-90-68.compute-1.internal> References: <20110117132437.25763.68327@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110121070859.32180.79902@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/80/#review223 ----------------------------------------------------------- Ship it! Seems good. Glad to see a "TODO" being dealt with :) - Merov On Jan. 17, 2011, 5:24 a.m., Aleric Inglewood wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/80/ > ----------------------------------------------------------- > > (Updated Jan. 17, 2011, 5:24 a.m.) > > > Review request for Viewer. > > > Summary > ------- > > See https://jira.secondlife.com/browse/VWR-24311 > > Basically, this fixes the TODO comment in install.py but with the difference that we really want to uninstall any old package with the same name, different md5 or not. > > > This addresses bug VWR-24311. > http://jira.secondlife.com/browse/VWR-24311 > > > Diffs > ----- > > doc/contributions.txt 422f636c3343 > scripts/install.py 422f636c3343 > > Diff: http://codereview.secondlife.com/r/80/diff > > > Testing > ------- > > Loads of testing on linux... Installing new packages now cleanly removes the old one first. > > > Thanks, > > Aleric > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110121/8c6c3861/attachment.htm From merov at lindenlab.com Thu Jan 20 23:15:47 2011 From: merov at lindenlab.com (Merov Linden) Date: Fri, 21 Jan 2011 07:15:47 -0000 Subject: [opensource-dev] Review Request: VWR-24337: Possible crash on llassert_always(purge_list.size() >= entries_to_purge) In-Reply-To: <20110114210934.17161.21367@domU-12-31-38-00-90-68.compute-1.internal> References: <20110114210934.17161.21367@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110121071547.29886.46513@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/93/#review224 ----------------------------------------------------------- indra/newview/lltexturecache.cpp I get it but it's a bit unsettling to have the condition seemingly unrelated to the iterator. I'd rather have a while () construction here so it's more clear what the intent is. - Merov On Jan. 14, 2011, 1:09 p.m., Aleric Inglewood wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/93/ > ----------------------------------------------------------- > > (Updated Jan. 14, 2011, 1:09 p.m.) > > > Review request for Viewer. > > > Summary > ------- > > Just fixed the logic, so entries_to_purge won't become negative anymore, and the rest. > > > This addresses bug VWR-24337. > http://jira.secondlife.com/browse/VWR-24337 > > > Diffs > ----- > > doc/contributions.txt b0bd26c5638a > indra/newview/lltexturecache.cpp b0bd26c5638a > > Diff: http://codereview.secondlife.com/r/93/diff > > > Testing > ------- > > > Thanks, > > Aleric > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110121/0bd899b4/attachment-0001.htm From merov at lindenlab.com Thu Jan 20 23:21:19 2011 From: merov at lindenlab.com (Merov Linden) Date: Fri, 21 Jan 2011 07:21:19 -0000 Subject: [opensource-dev] Review Request: VWR-24354: Fix manifest dependencies for linux In-Reply-To: <20110114211327.17160.77638@domU-12-31-38-00-90-68.compute-1.internal> References: <20110114211327.17160.77638@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110121072119.25759.74284@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/94/#review225 ----------------------------------------------------------- Ship it! Seems good. - Merov On Jan. 14, 2011, 1:13 p.m., Aleric Inglewood wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/94/ > ----------------------------------------------------------- > > (Updated Jan. 14, 2011, 1:13 p.m.) > > > Review request for Viewer. > > > Summary > ------- > > See http://jira.secondlife.com/browse/VWR-24354 > > > This addresses bug VWR-24354. > http://jira.secondlife.com/browse/VWR-24354 > > > Diffs > ----- > > doc/contributions.txt b0bd26c5638a > indra/newview/CMakeLists.txt b0bd26c5638a > > Diff: http://codereview.secondlife.com/r/94/diff > > > Testing > ------- > > > Thanks, > > Aleric > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110121/5e0a6de0/attachment.htm From merov at lindenlab.com Thu Jan 20 23:30:41 2011 From: merov at lindenlab.com (Merov Linden) Date: Fri, 21 Jan 2011 07:30:41 -0000 Subject: [opensource-dev] Review Request: VWR-24347 Reversion in Copy3rdPartyLibs.cmake -- cannot find msvc* files using VS 2005 Express In-Reply-To: <20101229234218.20369.35141@domU-12-31-38-00-90-68.compute-1.internal> References: <20101229234218.20369.35141@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110121073041.26108.91722@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/68/#review226 ----------------------------------------------------------- Ship it! Though we'll be moving to VS 2010, this patch will help some folks in the community. - Merov On Dec. 29, 2010, 3:42 p.m., Jonathan Yap wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/68/ > ----------------------------------------------------------- > > (Updated Dec. 29, 2010, 3:42 p.m.) > > > Review request for Viewer. > > > Summary > ------- > > Environment: Windows, VS 2005 Express > > Back in the days of v2.1 I was able to supply the following option to develop.py, which would allow me to specify the location of > msvcr80.dll > msvcp80.dll > Microsoft.VC80.CRT.manifest > > -DMSVC_REDIST_PATH:PATH=E:/some/path > > There was a similar code path for the debug files > -DMSVC_DEBUG_REDIST_PATH=E:/some/path > > This files cannot be found by the Express compiler so without a way of telling the compiler where to find them they have to be dropped into the build tree manually. > > At some point Copy3rdPartyLibs.cmake was rewritten and this option was dropped. > > > This addresses bug vwr-24347. > http://jira.secondlife.com/browse/vwr-24347 > > > Diffs > ----- > > indra/cmake/Copy3rdPartyLibs.cmake 27dae7b01a81 > > Diff: http://codereview.secondlife.com/r/68/diff > > > Testing > ------- > > I tried using -DMSVC_REDIST_PATH:PATH=E:/some/path with my VS 2005 Express compiler and obtained the desired result. > > I don't have the debug files to test -DMSVC_DEBUG_REDIST_PATH=E:/some/path > > > Thanks, > > Jonathan > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110121/1fe72d26/attachment.htm From merov at lindenlab.com Thu Jan 20 23:33:48 2011 From: merov at lindenlab.com (Merov Linden) Date: Fri, 21 Jan 2011 07:33:48 -0000 Subject: [opensource-dev] Review Request: VWR-24520: Don't use pkg_check_modules( ... QUIET ) on CMake < 2.8.2 In-Reply-To: <20110117180331.25764.31179@domU-12-31-38-00-90-68.compute-1.internal> References: <20110117180331.25764.31179@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110121073348.26108.35604@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/97/#review227 ----------------------------------------------------------- Ship it! I'm advising the MM to merge in a test repo and do a full TC cycle on all platforms before merging though... - Merov On Jan. 17, 2011, 10:03 a.m., Boroondas Gupte wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/97/ > ----------------------------------------------------------- > > (Updated Jan. 17, 2011, 10:03 a.m.) > > > Review request for Viewer. > > > Summary > ------- > > Only use QUIET in pkg_check_modules() on CMake >=2.8.2 (where it's supported) rather than already on CMake >=2.8. > > > This addresses bug VWR-24520. > http://jira.secondlife.com/browse/VWR-24520 > > > Diffs > ----- > > doc/contributions.txt 9e99b2c8fb28 > indra/cmake/FindLLQtWebkit.cmake 9e99b2c8fb28 > > Diff: http://codereview.secondlife.com/r/97/diff > > > Testing > ------- > > Configured (standalone) without a .pgk file for libllqtwebkit on Linux with CMake 2.8.1 and CMake 2.8.3. Output as expected. > > Not tested: > * CMake 2.8.2 > * system with a .pgk file for libllqtwebkit > * non-standalone > * Mac, Win > > > Thanks, > > Boroondas > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110121/66336809/attachment.htm From merov at lindenlab.com Thu Jan 20 23:40:18 2011 From: merov at lindenlab.com (Merov Linden) Date: Fri, 21 Jan 2011 07:40:18 -0000 Subject: [opensource-dev] Review Request: VWR-24519: Spawning of the 'spare' media plugin process makes debugging SLPlugin harder In-Reply-To: <20110118051341.25993.51445@domU-12-31-38-00-90-68.compute-1.internal> References: <20110118051341.25993.51445@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110121074018.25761.59524@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/96/#review228 ----------------------------------------------------------- Ship it! Useful! Ship it. - Merov On Jan. 17, 2011, 9:13 p.m., Aleric Inglewood wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/96/ > ----------------------------------------------------------- > > (Updated Jan. 17, 2011, 9:13 p.m.) > > > Review request for Viewer. > > > Summary > ------- > > This patch stops early spawns of "spare" media plugin processes when the debug setting PluginAttachDebuggerToPlugins is set. > The result should be that the terminal with gdb session that pops up when you open a media is the correct one that you intend to debug (instead of an idle one that does nothing; while the process that you want to debug was already spawned an arbitrary amount of time before). > > > This addresses bug VWR-24519. > http://jira.secondlife.com/browse/VWR-24519 > > > Diffs > ----- > > indra/newview/llviewermedia.cpp 422f636c3343 > > Diff: http://codereview.secondlife.com/r/96/diff > > > Testing > ------- > > > Thanks, > > Aleric > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110121/bbff3994/attachment.htm From sllists at boroon.dasgupta.ch Fri Jan 21 03:44:26 2011 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Fri, 21 Jan 2011 11:44:26 -0000 Subject: [opensource-dev] Review Request: STORM-236 Actual Code Review In-Reply-To: <20110121023718.32180.15352@domU-12-31-38-00-90-68.compute-1.internal> References: <20110121023718.32180.15352@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110121114426.25761.82432@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/113/#review229 ----------------------------------------------------------- indra/newview/llbottomtray.h The comment here says "Specifies buttons which can be hidden when bottom tray is shrunk." Indeed, when you make the Viewer window narrower and narrower, after all buttons have reached their minimal size, the ones listed here (before your change, that's all bottom bar buttons except the speak button) will vanish one by one. (Making the window wider again will make them re-appear.) Does listing the speak button here make it disappear in that case, too? If so, is that intended? indra/newview/llbottomtray.cpp Comments should be written for those reading the final code, not for those reading the diff. I.e. comment on what is done, maybe on how it is done and most important (if not obvious) why it's done. Do not comment on how it's done differently from earlier code or why the change was made. That would later only confuse those who aren't reading the old and new code side-by-side. A better place for comments on changes than the code are the jira issues, the "Description" field here on RB and last but no least the commit messages. An exception is to be made when whole subsystems are changed in either very subtle or very fundamental ways (or both), so in-code comments pointing out the differences would help people already closely familiar with the old code to find their way around in the new one. This comment here can probably just be removed. indra/newview/llspeakbutton.cpp Simplify your comments! No need to point out the obvious. (Here, that the "if" is some sort of check, that you added this check here (where else?) and that you do something dependent on the result of the check.) // Only draw the speak button when voice is enabled would capture the intent of the code perfectly and be quicker to grasp than // Adding check here to see if ... if so then ... indra/newview/llspeakbutton.cpp Please don't remove the single empty line between the end of one method and the beginning of the next one. indra/newview/skins/default/xui/en/menu_bottomtray.xml Begin XML comments with just "", not "" and "<-->". indra/newview/skins/default/xui/en/menu_bottomtray.xml Indentation of name attribute is wrong. (Should be same as label and layout attributes.) indra/newview/skins/default/xui/en/menu_bottomtray.xml Make that label="Speak button (enables voice chat)" indra/newview/skins/default/xui/en/menu_bottomtray.xml More indentation strangeness. indra/newview/skins/default/xui/en/menu_bottomtray.xml Indentation of is wrong. (Should be same level as preceding and following ) - Boroondas On Jan. 20, 2011, 6:37 p.m., Wolfpup Lowenhar wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/113/ > ----------------------------------------------------------- > > (Updated Jan. 20, 2011, 6:37 p.m.) > > > Review request for Viewer. > > > Summary > ------- > > This allows the Speak Button to auto-hide for those that do not use Voice at all. > > > This addresses bug STORM-236. > http://jira.secondlife.com/browse/STORM-236 > > > Diffs > ----- > > doc/contributions.txt 9c7d543fd15d > indra/newview/llbottomtray.h 9c7d543fd15d > indra/newview/llbottomtray.cpp 9c7d543fd15d > indra/newview/llspeakbutton.cpp 9c7d543fd15d > indra/newview/skins/default/xui/en/menu_bottomtray.xml 9c7d543fd15d > > Diff: http://codereview.secondlife.com/r/113/diff > > > Testing > ------- > > Built locally and did the following: > 1 Verified that when Voice is toggled via the preference panel the Speak Button auto hid/showed. > 2 Verified that drag and drop functionality of the Speak Button was not affected. > 3 Went to a non-Voice area with Voice active and verified that button was still there but grayed out. > > > Thanks, > > Wolfpup > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110121/bbcc9662/attachment-0001.htm From sllists at boroon.dasgupta.ch Fri Jan 21 04:21:47 2011 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Fri, 21 Jan 2011 12:21:47 -0000 Subject: [opensource-dev] Review Request: STORM-236 Actual Code Review In-Reply-To: <20110121023718.32180.15352@domU-12-31-38-00-90-68.compute-1.internal> References: <20110121023718.32180.15352@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110121122147.25765.19752@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/113/#review230 ----------------------------------------------------------- Looks like RB ate some of my comments in the review above. (Maybe because the quoted code sections overlapped.) indra/newview/llspeakbutton.cpp The code here should be indented the same as the comment. indra/newview/skins/default/xui/en/menu_bottomtray.xml "section"? "selection"? Please check the spelling. Also, the comment here confused me. I think what you meant to say is: "The Speak Button is visible if and only if Voice Chat is enabled. Thus, to toggle the button's visibility, we enable or disable Voice Chat accordingly." indra/newview/skins/default/xui/en/menu_bottomtray.xml Trailing whitespace. (Didn't RB highlight those in red, before? Doesn't seem to do that anymore in the diff view, only in quoted code on the review.) - Boroondas On Jan. 20, 2011, 6:37 p.m., Wolfpup Lowenhar wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/113/ > ----------------------------------------------------------- > > (Updated Jan. 20, 2011, 6:37 p.m.) > > > Review request for Viewer. > > > Summary > ------- > > This allows the Speak Button to auto-hide for those that do not use Voice at all. > > > This addresses bug STORM-236. > http://jira.secondlife.com/browse/STORM-236 > > > Diffs > ----- > > doc/contributions.txt 9c7d543fd15d > indra/newview/llbottomtray.h 9c7d543fd15d > indra/newview/llbottomtray.cpp 9c7d543fd15d > indra/newview/llspeakbutton.cpp 9c7d543fd15d > indra/newview/skins/default/xui/en/menu_bottomtray.xml 9c7d543fd15d > > Diff: http://codereview.secondlife.com/r/113/diff > > > Testing > ------- > > Built locally and did the following: > 1 Verified that when Voice is toggled via the preference panel the Speak Button auto hid/showed. > 2 Verified that drag and drop functionality of the Speak Button was not affected. > 3 Went to a non-Voice area with Voice active and verified that button was still there but grayed out. > > > Thanks, > > Wolfpup > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110121/904b2ecc/attachment.htm From Aleric.Inglewood at gmail.com Fri Jan 21 04:25:58 2011 From: Aleric.Inglewood at gmail.com (Aleric Inglewood) Date: Fri, 21 Jan 2011 12:25:58 -0000 Subject: [opensource-dev] Review Request: VWR-24337: Possible crash on llassert_always(purge_list.size() >= entries_to_purge) In-Reply-To: <20110114210934.17161.21367@domU-12-31-38-00-90-68.compute-1.internal> References: <20110114210934.17161.21367@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110121122558.32180.48870@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/93/ ----------------------------------------------------------- (Updated Jan. 21, 2011, 4:25 a.m.) Review request for Viewer. Changes ------- The new diff uses while(purge_list.size() < entries_to_purge), instead of a for() loop. Summary ------- Just fixed the logic, so entries_to_purge won't become negative anymore, and the rest. This addresses bug VWR-24337. http://jira.secondlife.com/browse/VWR-24337 Diffs (updated) ----- doc/contributions.txt 422f636c3343 indra/newview/lltexturecache.cpp 422f636c3343 Diff: http://codereview.secondlife.com/r/93/diff Testing ------- Thanks, Aleric -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110121/d222a0ac/attachment.htm From sllists at boroon.dasgupta.ch Fri Jan 21 04:33:09 2011 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Fri, 21 Jan 2011 12:33:09 -0000 Subject: [opensource-dev] Review Request: VWR-24520: Don't use pkg_check_modules( ... QUIET ) on CMake < 2.8.2 In-Reply-To: <20110121073348.26108.35604@domU-12-31-38-00-90-68.compute-1.internal> References: <20110121073348.26108.35604@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110121123309.29886.19290@domU-12-31-38-00-90-68.compute-1.internal> > On Jan. 20, 2011, 11:33 p.m., Merov Linden wrote: > > I'm advising the MM to merge in a test repo and do a full TC cycle on all platforms before merging though... As far as I can see indra/cmake/FindLLQtWebkit.cmake only gets called by indra/cmake/WebKitLibPlugin.cmake (through find_package(LLQtWebkit REQUIRED QUIET)), and there the call only happens for STANDALONE. So I would be very surprised if this affects TC builds. - Boroondas ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/97/#review227 ----------------------------------------------------------- On Jan. 17, 2011, 10:03 a.m., Boroondas Gupte wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/97/ > ----------------------------------------------------------- > > (Updated Jan. 17, 2011, 10:03 a.m.) > > > Review request for Viewer. > > > Summary > ------- > > Only use QUIET in pkg_check_modules() on CMake >=2.8.2 (where it's supported) rather than already on CMake >=2.8. > > > This addresses bug VWR-24520. > http://jira.secondlife.com/browse/VWR-24520 > > > Diffs > ----- > > doc/contributions.txt 9e99b2c8fb28 > indra/cmake/FindLLQtWebkit.cmake 9e99b2c8fb28 > > Diff: http://codereview.secondlife.com/r/97/diff > > > Testing > ------- > > Configured (standalone) without a .pgk file for libllqtwebkit on Linux with CMake 2.8.1 and CMake 2.8.3. Output as expected. > > Not tested: > * CMake 2.8.2 > * system with a .pgk file for libllqtwebkit > * non-standalone > * Mac, Win > > > Thanks, > > Boroondas > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110121/4e40aaaa/attachment-0001.htm From Aleric.Inglewood at gmail.com Fri Jan 21 05:15:10 2011 From: Aleric.Inglewood at gmail.com (Aleric Inglewood) Date: Fri, 21 Jan 2011 13:15:10 -0000 Subject: [opensource-dev] Review Request: VWR-24312: Massively duplicated objects (part 2) In-Reply-To: <20110114213157.17161.57957@domU-12-31-38-00-90-68.compute-1.internal> References: <20110114213157.17161.57957@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110121131510.26007.64901@domU-12-31-38-00-90-68.compute-1.internal> > On Jan. 14, 2011, 1:31 p.m., Boroondas Gupte wrote: > > indra/llcommon/lllslconstants.h, line 184 > > > > > > Yay for having type modifiers after the core type name. Makes them much easier to understand, especially when there are several cascaded ones. :-) > > Aleric Inglewood wrote: > Yeah, I'm strongly convinced that TYPE const is superior in anyway over const TYPE. > See http://www.xs4all.nl/~carlo17/cpp/const.qualifier.html for the reasoning. > In one line: all type qualifiers work to the left, it's best to PUT them on the > left so the whole type is logically uniform in it's construction. The fact that > you can legally type 'const TYPE' is just a historically grown misfortune. > > Of course I meant.. "All type qualifiers work to the left, so it's best to PUT them on the _right_ ...", as in: TYPE QUALIFIER : The Qualifier changes the TYPE on it's left, so that what first was TYPE now becomes TYPE QUALIFIER. [Where "QUALIFIER" is not just const, volatile, restrict, but also * and &. The only exception where any qualifier works to the right is where 'const' (volatile and restrict, but NOT * an &) works on a base type. Surely it needs getting used when one changes style, but this one is so logical that already after a single week you don't understand anymore how you were ever able to use to previous format style. While on the topic of coding style and types. The above is a good reason to put * (and &) that are part of types *against* the TYPE they work on. That way one can easily recognize the difference between the unary operator, the binary operator and the type qualifier: A* b = *c * d + e; // The type qualifier has no space on it's left (and // changes the type A), the binary operator (multiplication) // has spaces on both sides, while the unary operator // (dereference) works to it's right side and has no // space on the right.] [[ Ie, #include struct A { int i; }; int main() { A const a[7] = { 0, 1, 2, 3, 4, 5, 6 }; int const two = 2; int const* c = &two; int const d = 3; A* const& e = &a[0]; A* b = *c * d + e; std::cout << b->i << std::endl; } ]] - Aleric ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/81/#review153 ----------------------------------------------------------- On Jan. 16, 2011, 5:53 a.m., Aleric Inglewood wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/81/ > ----------------------------------------------------------- > > (Updated Jan. 16, 2011, 5:53 a.m.) > > > Review request for Viewer. > > > Summary > ------- > > Turns out that most of my SNOW-800 patch was included in Viewer 2 (albeit without crediting me). > However, not everything was used and some more cleaning up was possible. > > After this patch, and when compiling with optimization, there are no duplicates left > anymore that shouldn't be there in the first place: apart from the debug stream > iostream guard variable, there are several static variables with the same name (r, r1, > r2, etc) but that indeed actually different symbol objects. Then there are a few > constant POD arrays that are duplicated a hand full of times because they are > accessed with a variable index (so optimizing them away is not possible). I left them > like that (although defining those as extern as well would have been more consistent > and not slower; in fact it would be faster theoretically because those arrays could > share the same cache page then). > > > This addresses bug VWR-24312. > http://jira.secondlife.com/browse/VWR-24312 > > > Diffs > ----- > > doc/contributions.txt 422f636c3343 > indra/llcharacter/llanimationstates.cpp 422f636c3343 > indra/llcommon/llavatarconstants.h 422f636c3343 > indra/llcommon/lllslconstants.h 422f636c3343 > indra/llcommon/llmetricperformancetester.h 422f636c3343 > indra/llmath/llcamera.h 422f636c3343 > indra/llmath/llcamera.cpp 422f636c3343 > indra/newview/llviewerobject.cpp 422f636c3343 > indra/newview/llvoavatar.cpp 422f636c3343 > indra/newview/llvosky.h 422f636c3343 > indra/newview/llvosky.cpp 422f636c3343 > > Diff: http://codereview.secondlife.com/r/81/diff > > > Testing > ------- > > Compiled with optimization and then running readelf on the executable to find duplicated symbols. > > > Thanks, > > Aleric > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110121/e32e1af1/attachment.htm From sllists at boroon.dasgupta.ch Fri Jan 21 06:34:35 2011 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Fri, 21 Jan 2011 14:34:35 -0000 Subject: [opensource-dev] Review Request: STORM-236 Actual Code Review In-Reply-To: <20110121114426.25761.82432@domU-12-31-38-00-90-68.compute-1.internal> References: <20110121114426.25761.82432@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110121143435.25992.88979@domU-12-31-38-00-90-68.compute-1.internal> > On Jan. 21, 2011, 3:44 a.m., Boroondas Gupte wrote: > > indra/newview/llspeakbutton.cpp, lines 67-70 > > > > > > Please don't remove the single empty line between the end of one method and the beginning of the next one. Oops, you didn't remove the line, it wasn't there before, just looks as if it was due to the diff view ... but can't hurt to add it. - Boroondas ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/113/#review229 ----------------------------------------------------------- On Jan. 20, 2011, 6:37 p.m., Wolfpup Lowenhar wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/113/ > ----------------------------------------------------------- > > (Updated Jan. 20, 2011, 6:37 p.m.) > > > Review request for Viewer. > > > Summary > ------- > > This allows the Speak Button to auto-hide for those that do not use Voice at all. > > > This addresses bug STORM-236. > http://jira.secondlife.com/browse/STORM-236 > > > Diffs > ----- > > doc/contributions.txt 9c7d543fd15d > indra/newview/llbottomtray.h 9c7d543fd15d > indra/newview/llbottomtray.cpp 9c7d543fd15d > indra/newview/llspeakbutton.cpp 9c7d543fd15d > indra/newview/skins/default/xui/en/menu_bottomtray.xml 9c7d543fd15d > > Diff: http://codereview.secondlife.com/r/113/diff > > > Testing > ------- > > Built locally and did the following: > 1 Verified that when Voice is toggled via the preference panel the Speak Button auto hid/showed. > 2 Verified that drag and drop functionality of the Speak Button was not affected. > 3 Went to a non-Voice area with Voice active and verified that button was still there but grayed out. > > > Thanks, > > Wolfpup > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110121/91773d2e/attachment.htm From Aleric.Inglewood at gmail.com Fri Jan 21 07:58:12 2011 From: Aleric.Inglewood at gmail.com (Aleric Inglewood) Date: Fri, 21 Jan 2011 15:58:12 -0000 Subject: [opensource-dev] Review Request: VWR-24312: Massively duplicated objects (part 2) In-Reply-To: <20110121065719.26332.52149@domU-12-31-38-00-90-68.compute-1.internal> References: <20110121065719.26332.52149@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110121155812.25993.13252@domU-12-31-38-00-90-68.compute-1.internal> > On Jan. 20, 2011, 10:57 p.m., Merov Linden wrote: > > I fail to see how any of those changes "massively prevents object duplication". I don't disagree with any of them but I don't see much value in any either. Sure, there are different ways to skin a cat and some are better. Still, these changes will likely make upcoming merges conflict annoyingly and make the life of the maintainers (i.e. mine and Oz) horrid. It reminded me of this post by another (more famous) Open Source maintainer: http://tirania.org/blog/archive/2010/Dec-31.html Hi Merov! Firstly, I completely agree with the Open Source maintainer article, and I understand why this patch made you think it. However, being aware of this fact I don't think I made such changes to code that didn't already need change anyway. In fact, although certain styles used in the code are a horror in my eyes, I still don't change it-- even when I change those lines to fix a bug-- when the context around it all use the same style. A lot of style in the viewer code changes from file to file and even from function to function, but I try to preserve the style used at that point in the code. But back to the subject at hand. Surely you know most of the following already: I'm not writing this just for you but more in general for anyone reading this review (to produce some of the output below, I had to recompile the viewer several times, so I have some time to write this ;). Perhaps the two of us can talk about it on IRC, as well, if you want. In the line of the article that you linked to ;) ... you might just want to skip this long post to where it say ******START HERE******. An important concept to understand this patch is what is called Plain Old Data (POD). All built-in types are POD, as well as struct's that that only have POD members (in particular, have no user-defined constructor or destructor, for the gory definition read http://en.wikipedia.org/wiki/Plain_old_data_structure) other then the ones generated by the compiler. Why does this matter? Well, consider we have two .cpp source files, source1.cpp and source2.cpp, both of which include the same header: source1.cpp: #include "header.h" //... int main() { } source2.cpp: #include "header.h" //... Further more, assume that the header defines a few constants: header.h: typedef int POD1; struct POD2 { POD1 i1; POD1 i2; }; POD1 const const1 = 1; POD2 const const2 = { 2, 2 }; struct nonPOD { POD1 i; nonPOD(int i_) : i(i_) { } }; nonPOD const const3(3); Here, the struct nonPOD is not a POD type because it has a user defined constructor. Note that 'nonPOD const const3 = { 3 }' would not compile, as such initialization is only allowed for POD types. First we'd compile both source files: g++ -o source1.o -c source1.cpp g++ -o source2.o -c source2.cpp And then link them: g++ -o test source1.o source2.o We can use the utility nm(1) to dump the symbols of each object file: $ nm -C ./source1.o | egrep '(const[0-9]|POD)' 0000000000000000 r const1 0000000000000004 r const2 0000000000000000 b const3 0000000000000000 W nonPOD::nonPOD(int) Here, just showing the interesting stuff (symbols containing 'const' or 'POD'), we see all three constants, and the constructor of nonPOD. Note that const1 and const2 have an 'r' in front of them while const3 has a 'b'. This means respectively 'read-only section' and 'uninitialized section'. The uninitialized section is not part of the final executable, it is space allocated in memory at the moment an executable is started and subsequently initialized, so it doesn't contribute the size of the executable but it does cause more memory to be used during run time. The other object file, source2.o has of course the exact same output: $ nm -C ./source2.o | egrep '(const[0-9]|POD)' 0000000000000000 r const1 0000000000000004 r const2 0000000000000000 b const3 0000000000000000 W nonPOD::nonPOD(int) Finally we can look at the end result, the linked executable: $ nm -C test | egrep '(const[0-9]|POD)' 000000000040071c r const1 0000000000400724 r const1 0000000000400720 r const2 0000000000400728 r const2 0000000000600b10 b const3 0000000000600b14 b const3 00000000004005d2 W nonPOD::nonPOD(int) And as you see all constants appear twice in the executable. Nothing we can do about that (until we compile with optimization, see below). Note that nm uses certain debug information. If we strip the executable, like so; $ strip test $ nm -C test | egrep '(const[0-9]|POD)' nm: test: no symbols So clearly this doesn't give the REAL picture, but good enough for this explanation. If now we compile with optimization, which should be the case that concerns us most, then the results becomes: $ g++ -O -o source1.o -c source1.cpp $ g++ -O -o source2.o -c source2.cpp $ g++ -o test source1.o source2.o 00000000006009f0 b const3 00000000006009f4 b const3 In other words, optimizing is able to get rid of POD constants, but not of non-POD constants: the compiler doesn't see or know that these will become identical (and in fact, if we'd take the pointer of them in yet other source files, then those _should_ be different). This is why it's at least good practise to put non-POD constants NOT in a header file: You don't gain anything with it, except creating duplicates. Now lets have a look at these results for do-not-directly-run-secondlife-bin (RELEASE mode, so with optimization). Here we need to use a more elaborate command line in order to get rid of not so interesting information: We dump all symbols, filter out only the ones in the read-only section and the uninitialized section, strip of all output except the mangled symbol name, then sort the symbol names alphabetically (not removing duplicates) and pipe that into 'uniq -c' which prints each symbol prepended with a count of how often it occurred. That result is piped into sort -n to sort the this result by how often each symbol (name) occurred (largest count last) and subsequencially through c++filt to demangle the symbols. Finally we filter out non interesting symbols: labels (starting with .LC), __FUNCTION__ symbols with the name of functions, the '_site' variable that occurs in the info and warning stream macro's, so although it's name is repeated a lot, it's really a different symbol every time. The result is of that is: $ nm do-not-directly-run-secondlife-bin | egrep ' (r|b) ' | sed -e 's/.* //' | sort | uniq -c | sort -n | c++filt | egrep -v '( \.LC|::__FUNCTION__|::_site)' ...lots of symbols only occuring once... 2 CSWTCH.1781 2 FTM_GEO_SKY 2 PANEL_PICKS 2 sTesterName 2 PREVIEW_HPAD 2 PANEL_PROFILE 2 FTM_REBUILD_VBO 2 LSCRIPTDataSize 2 MANIPULATOR_IDS 2 FTM_CULL_REBOUND 2 LSCRIPTTypeNames 2 COLLAPSED_BY_USER 2 FTM_CREATE_OBJECT 2 FTM_UPDATE_WLPARAM 2 FTM_PROCESS_OBJECTS 2 LSCRIPTStateBitField 2 t_panel_group_general 2 PREVIEW_TEXTURE_HEIGHT 2 WEARABLE_NAME_COMPARATOR 2 icon_m 2 icon_r 2 shader 2 icon_pg 2 NEW_LINE 2 t_places 2 (anonymous namespace)::gResponsePtr 3 t_inventory 3 empty_string 3 gDirOpposite 3 LLVORBIS_CLIP_MAX_SAMPLES 3 LLVORBIS_CLIP_REJECT_SIZE 3 LLVORBIS_CLIP_REJECT_SAMPLES 3 LLVORBIS_CLIP_MAX_SAMPLE_DATA 3 t2 4 r3 5 t1 8 OGL_TO_CFR_ROTATION 8 r2 12 r1 52 r 795 std::__ioinit The fact that std::__ioinit occurs 795 times is because it's used in the llinfos and llwarns etc macros as well, in many different places. The t2, r3, t1, r2, r1 and r, are static variables (in .cpp files) of that name used in several places in the code. Different symbols really. In other words, nothing wrong here. But, this is WITH this patch. ******START HERE****** Without the patch and leaving out the symbols from above, the output becomes: 8 VISIBILITY_HIDDEN 8 VISIBILITY_DEFAULT 8 VISIBILITY_VISIBLE 8 VISIBILITY_INVISIBLE 24 TEXTBOX_MAGIC_TOKEN 49 AIR_SCA_AVG 49 AIR_SCA_INTENS 49 gAirScaSeaLevel 351 DEFAULT_METRIC_NAME 518 NEG_X_AXIS 518 NEG_Y_AXIS 518 NEG_Z_AXIS 518 X_AXIS 518 Y_AXIS 518 Z_AXIS Thus, these are the duplicates (and how often) that are still in the code. Agreed, not many - but that is because you already applied SNOW-800 in the past. This should address your, | I fail to see how any of those changes "massively prevents object duplication". Next let me comment on, | I don't disagree with any of them but I don't see much value in any either. I completely agree with you, I don't see much value either. Not in terms of FPS improvements, not in link or compile times, and not even in making the code more robust. However, since I had to be SURE - and therefore had to redo SNOW-800... I ended up with this patch, and even though a "code clean up" and with the bonus of getting rid of several thousand duplicated constants here and there... I saw no reason not to commit it. | Sure, there are different ways to skin a cat and some are better. | Still, these changes will likely make upcoming merges conflict | annoyingly and make the life of the maintainers (i.e. mine and Oz) | horrid. Okaayyy.. now here is where we disagree ;). I think you're extremely exaggerating with the 'horrid', more over, I'm willing to make a bet that you will get no collision at all (ok, not really, because you have internal-knowledge of what other people are working on ;). The patch can be divided in three parts: 1) A single hunk of 139 lines in indra/llcharacter/llanimationstates.cpp that is merely a "style" fix (almost: it's 'bad coding' in that causes 139 times a call to a malloc, free and a copy constructor of LLUUID while utterly unnecessary. I ONLY added this to THIS patch, because this change was part of the *original* SNOW-800 patch (which is in snowglobe 1.x, where these lines were MOVED from a header to the .cpp file), but for some reason this change wasn't copied to viewer 2. I have no objections whatsoever if you decide not to apply this hunk, but seriously - how often is THAT part of the code changed by other people? It's a list of UUID's for crying out loud. It will NOT be changed for MONTHS to come. It will really not cause any collisions, or merge horror, because nobody else changes that code, ever. 2) Four lines in indra/llcommon/llavatarconstants.h that gets rid of the VISIBILITY_* duplications. Surely those four lines won't give you a merge problem either. It's extremely unlikely that, until everyone merged this, anyone will change code near those lines, and even if some person does - the fix of such collision would be extremely trivial. Likewise one line in indra/llcommon/lllslconstants.h for TEXTBOX_MAGIC_TOKEN. One line in indra/llcommon/llmetricperformancetester.h for DEFAULT_METRIC_NAME etc... minimal changes that in practise are very unlikely to even cause a collision before this is merged to everyone, and are faster to fix if it happens than it took you to read this post. 3) A serious code cleanup (and getting rid of the duplicates) regarding the AIR_SCA (AirSca) calculations. I say serious, because the old code is hardly "maintainable" and very unclear. If you have a hard time reviewing it then I'm sure that is because it nearly impossible to follow what the OLD code did... Again, yes, the old code worked... so why apply the patch when there is a risk for collisions? Well, in this case it's my opinion that the old code is SO bad-- that now the work of cleaning it up is done-- it's worth the risk... especially because in the end, it only changes things very locally (indra/newview/llvosky.cpp), again not likely at all that anyone else will be making changes to that code right now (especially since they'd need to understand the code first - heheh, highly unlikely!). Let me know what your decision is, so I can adapt my final test repository of the collection of the VWR* jiras that I currently have pending on the review board. Thanks for reading (sorry it was so long), Aleric - Aleric ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/81/#review221 ----------------------------------------------------------- On Jan. 16, 2011, 5:53 a.m., Aleric Inglewood wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/81/ > ----------------------------------------------------------- > > (Updated Jan. 16, 2011, 5:53 a.m.) > > > Review request for Viewer. > > > Summary > ------- > > Turns out that most of my SNOW-800 patch was included in Viewer 2 (albeit without crediting me). > However, not everything was used and some more cleaning up was possible. > > After this patch, and when compiling with optimization, there are no duplicates left > anymore that shouldn't be there in the first place: apart from the debug stream > iostream guard variable, there are several static variables with the same name (r, r1, > r2, etc) but that indeed actually different symbol objects. Then there are a few > constant POD arrays that are duplicated a hand full of times because they are > accessed with a variable index (so optimizing them away is not possible). I left them > like that (although defining those as extern as well would have been more consistent > and not slower; in fact it would be faster theoretically because those arrays could > share the same cache page then). > > > This addresses bug VWR-24312. > http://jira.secondlife.com/browse/VWR-24312 > > > Diffs > ----- > > doc/contributions.txt 422f636c3343 > indra/llcharacter/llanimationstates.cpp 422f636c3343 > indra/llcommon/llavatarconstants.h 422f636c3343 > indra/llcommon/lllslconstants.h 422f636c3343 > indra/llcommon/llmetricperformancetester.h 422f636c3343 > indra/llmath/llcamera.h 422f636c3343 > indra/llmath/llcamera.cpp 422f636c3343 > indra/newview/llviewerobject.cpp 422f636c3343 > indra/newview/llvoavatar.cpp 422f636c3343 > indra/newview/llvosky.h 422f636c3343 > indra/newview/llvosky.cpp 422f636c3343 > > Diff: http://codereview.secondlife.com/r/81/diff > > > Testing > ------- > > Compiled with optimization and then running readelf on the executable to find duplicated symbols. > > > Thanks, > > Aleric > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110121/f0ddeb3b/attachment-0001.htm From jhwelch at gmail.com Fri Jan 21 08:16:37 2011 From: jhwelch at gmail.com (Jonathan Welch) Date: Fri, 21 Jan 2011 11:16:37 -0500 Subject: [opensource-dev] Link times revisited Message-ID: This is a follow up to my earlier Link Times message. I just upgraded my system from 2Gb to 4Gb, though it only shows 3Gb as being available (the joys of 32-bit Windows XP). 1st 2nd pass CV 0:53 0:24 2Gb (CV = Cool Rainbow Viewer, based on v1.22) 0:58 0:26 3Gb SG 3:30 2:07 2Gb 3:33 2:11 3Gb V2 6:18 6:01 2Gb 5:28 3:33 3Gb When I was doing these timing tests, initially with 2Gb, I was also monitoring free memory and did not see it get to an extremely low value; perhaps data was being sent to the page file before that happened, as there is a significant speed gain just by having 1 more Gb. -jonathan From wolfpup67 at earthlink.net Fri Jan 21 08:41:30 2011 From: wolfpup67 at earthlink.net (WolfPup Lowenhar) Date: Fri, 21 Jan 2011 11:41:30 -0500 Subject: [opensource-dev] FW: [JIRA] Commented: (STORM-236) Allow the "Speak" button to be removed, like other buttons Message-ID: <006601cbb98a$0e62ea20$2b28be60$@net> Please Help test this. From: Oz Linden (JIRA) [mailto:no-reply at secondlife.com] Sent: Friday, January 21, 2011 10:57 AM To: wolfpup67 at earthlink.net Subject: [JIRA] Commented: (STORM-236) Allow the "Speak" button to be removed, like other buttons [ https://jira.secondlife.com/browse/STORM-236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel &focusedCommentId=236477#comment-236477 ] Oz Linden commented on STORM-236: --------------------------------- Test builds available at: http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repo/oz_project-2/rev/219418/index.html > Allow the "Speak" button to be removed, like other buttons > ---------------------------------------------------------- > > Key: STORM-236 > URL: https://jira.secondlife.com/browse/STORM-236 > Project: Snowstorm > Issue Type: Story > Environment: Irrelevant. > Reporter: Mimika Oh > Fix For: Product Backlog Proposals > > Attachments: cantspeakbutton.png, No Speak Button Voice Disabled.jpg, Screen shot 2010-03-31 at 19.24.55.png, Speak Button Voice Enabled.jpg > > Time Spent: 2 days, 1 hour > Remaining Estimate: 7 hours > > As a user who does not use Voice, I would like to reclaim the bottom-bar space occupied by the disabled "Speak" buttons. > The bottom bar of the viewer has buttons which can be enabled and disabled by right-clicking the bar. Except the Speak button, which remains even when Voice is totally disabled, and can't be removed. > Please allow it to be removed. When voice is disabled, it is just wasting space. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira _____ No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1191 / Virus Database: 1435/3393 - Release Date: 01/20/11 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110121/bcf6693d/attachment.htm From babytje_ab at live.com Fri Jan 21 09:06:38 2011 From: babytje_ab at live.com (Alexandrea Fride) Date: Fri, 21 Jan 2011 17:06:38 -0000 Subject: [opensource-dev] Review Request: STORM-236 Actual Code Review In-Reply-To: <20110121023718.32180.15352@domU-12-31-38-00-90-68.compute-1.internal> References: <20110121023718.32180.15352@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110121170638.25766.61483@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/113/#review235 ----------------------------------------------------------- Perfect just the naming in menu should be better "Speak button (enables voice chat)" like boroondas sayd :) (and mayby the styling fixed or so but patch works as exspected) tested patch and test build both worked as exspected nice job - Alexandrea On Jan. 20, 2011, 6:37 p.m., Wolfpup Lowenhar wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/113/ > ----------------------------------------------------------- > > (Updated Jan. 20, 2011, 6:37 p.m.) > > > Review request for Viewer. > > > Summary > ------- > > This allows the Speak Button to auto-hide for those that do not use Voice at all. > > > This addresses bug STORM-236. > http://jira.secondlife.com/browse/STORM-236 > > > Diffs > ----- > > doc/contributions.txt 9c7d543fd15d > indra/newview/llbottomtray.h 9c7d543fd15d > indra/newview/llbottomtray.cpp 9c7d543fd15d > indra/newview/llspeakbutton.cpp 9c7d543fd15d > indra/newview/skins/default/xui/en/menu_bottomtray.xml 9c7d543fd15d > > Diff: http://codereview.secondlife.com/r/113/diff > > > Testing > ------- > > Built locally and did the following: > 1 Verified that when Voice is toggled via the preference panel the Speak Button auto hid/showed. > 2 Verified that drag and drop functionality of the Speak Button was not affected. > 3 Went to a non-Voice area with Voice active and verified that button was still there but grayed out. > > > Thanks, > > Wolfpup > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110121/c8cd3597/attachment.htm From trilobyte550m at gmail.com Fri Jan 21 09:53:50 2011 From: trilobyte550m at gmail.com (Trilo Byte) Date: Fri, 21 Jan 2011 09:53:50 -0800 Subject: [opensource-dev] FW: [JIRA] Commented: (STORM-236) Allow the "Speak" button to be removed, like other buttons In-Reply-To: <006601cbb98a$0e62ea20$2b28be60$@net> References: <006601cbb98a$0e62ea20$2b28be60$@net> Message-ID: Works great in the Mac client. Sounds nitpicky, but I'd add a space after "Speak Button" and before "(Voice Enabled" in the menu On Jan 21, 2011, at 8:41 AM, WolfPup Lowenhar wrote: > Please Help test this. > > From: Oz Linden (JIRA) [mailto:no-reply at secondlife.com] > Sent: Friday, January 21, 2011 10:57 AM > To: wolfpup67 at earthlink.net > Subject: [JIRA] Commented: (STORM-236) Allow the "Speak" button to be removed, like other buttons > > > [ https://jira.secondlife.com/browse/STORM-236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=236477#comment-236477 ] > > Oz Linden commented on STORM-236: > --------------------------------- > > Test builds available at: > http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repo/oz_project-2/rev/219418/index.html > > > Allow the "Speak" button to be removed, like other buttons > > ---------------------------------------------------------- > > > > Key: STORM-236 > > URL: https://jira.secondlife.com/browse/STORM-236 > > Project: Snowstorm > > Issue Type: Story > > Environment: Irrelevant. > > Reporter: Mimika Oh > > Fix For: Product Backlog Proposals > > > > Attachments: cantspeakbutton.png, No Speak Button Voice Disabled.jpg, Screen shot 2010-03-31 at 19.24.55.png, Speak Button Voice Enabled.jpg > > > > Time Spent: 2 days, 1 hour > > Remaining Estimate: 7 hours > > > > As a user who does not use Voice, I would like to reclaim the bottom-bar space occupied by the disabled "Speak" buttons. > > The bottom bar of the viewer has buttons which can be enabled and disabled by right-clicking the bar. Except the Speak button, which remains even when Voice is totally disabled, and can't be removed. > > Please allow it to be removed. When voice is disabled, it is just wasting space. > > -- > This message is automatically generated by JIRA. > - > For more information on JIRA, see: http://www.atlassian.com/software/jira > > > > No virus found in this message. > Checked by AVG - www.avg.com > Version: 10.0.1191 / Virus Database: 1435/3393 - Release Date: 01/20/11 > > _______________________________________________ > Policies 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/20110121/f928e120/attachment-0001.htm From opensourceobscure at gmail.com Fri Jan 21 09:56:03 2011 From: opensourceobscure at gmail.com (Opensource Obscure) Date: Fri, 21 Jan 2011 18:56:03 +0100 Subject: [opensource-dev] Review Request: STORM-236 Actual Code Review In-Reply-To: <20110121170638.25766.61483@domU-12-31-38-00-90-68.compute-1.internal> References: <20110121023718.32180.15352@domU-12-31-38-00-90-68.compute-1.internal> <20110121170638.25766.61483@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: It seems it works as expected on Linux after some testing (2.6.0 (219418)). The UI works fine, but I didn't use voice during the tests. I don't know if this is by design, but I'll add that: - when you disable Voice, the Speak Button correctly disappears - this doesn't happen if you disable the whole SL audio system Thanks for this feature! Opensource Obscure On Fri, Jan 21, 2011 at 18:06, Alexandrea Fride wrote: > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/113/ > > Perfect just the naming in menu should be better "Speak button (enables voice chat)" like boroondas sayd :) (and mayby the styling fixed or so but patch works as exspected) > > tested patch and test build both worked as exspected > > nice job > > > - Alexandrea > > On January 20th, 2011, 6:37 p.m., Wolfpup Lowenhar wrote: > Review request for Viewer. > By Wolfpup Lowenhar. > > *Updated Jan. 20, 2011, 6:37 p.m.* > Description > > This allows the Speak Button to auto-hide for those that do not use Voice at all. > > Testing > > Built locally and did the following: > 1 Verified that when Voice is toggled via the preference panel the Speak Button auto hid/showed. > 2 Verified that drag and drop functionality of the Speak Button was not affected. > 3 Went to a non-Voice area with Voice active and verified that button was still there but grayed out. > > *Bugs: * STORM-236 > Diffs > > - doc/contributions.txt (9c7d543fd15d) > - indra/newview/llbottomtray.h (9c7d543fd15d) > - indra/newview/llbottomtray.cpp (9c7d543fd15d) > - indra/newview/llspeakbutton.cpp (9c7d543fd15d) > - indra/newview/skins/default/xui/en/menu_bottomtray.xml (9c7d543fd15d) > > View Diff > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting > privileges > -- *Opensource Obscure* Twitter [EN] - Twitter [IT] - Blog [IT] - YouTube - Photos - Second Life -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110121/5d64ba35/attachment.htm From merov at lindenlab.com Fri Jan 21 10:04:32 2011 From: merov at lindenlab.com (Merov Linden) Date: Fri, 21 Jan 2011 18:04:32 -0000 Subject: [opensource-dev] Review Request: STORM-236 Actual Code Review In-Reply-To: <20110121023718.32180.15352@domU-12-31-38-00-90-68.compute-1.internal> References: <20110121023718.32180.15352@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110121180432.25763.44810@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/113/#review236 ----------------------------------------------------------- indra/newview/llbottomtray.cpp Unnecessary comment. Please delete. indra/newview/llbottomtray.cpp Unnecessary comment. Please delete. indra/newview/llbottomtray.cpp What Boroondas said. Please delete that comment. indra/newview/llbottomtray.cpp Unnecessary comment. indra/newview/llbottomtray.cpp Unnecessary comment. indra/newview/skins/default/xui/en/menu_bottomtray.xml Typos: change "selction" to "selection", change "visable" to "visible" - Merov On Jan. 20, 2011, 6:37 p.m., Wolfpup Lowenhar wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/113/ > ----------------------------------------------------------- > > (Updated Jan. 20, 2011, 6:37 p.m.) > > > Review request for Viewer. > > > Summary > ------- > > This allows the Speak Button to auto-hide for those that do not use Voice at all. > > > This addresses bug STORM-236. > http://jira.secondlife.com/browse/STORM-236 > > > Diffs > ----- > > doc/contributions.txt 9c7d543fd15d > indra/newview/llbottomtray.h 9c7d543fd15d > indra/newview/llbottomtray.cpp 9c7d543fd15d > indra/newview/llspeakbutton.cpp 9c7d543fd15d > indra/newview/skins/default/xui/en/menu_bottomtray.xml 9c7d543fd15d > > Diff: http://codereview.secondlife.com/r/113/diff > > > Testing > ------- > > Built locally and did the following: > 1 Verified that when Voice is toggled via the preference panel the Speak Button auto hid/showed. > 2 Verified that drag and drop functionality of the Speak Button was not affected. > 3 Went to a non-Voice area with Voice active and verified that button was still there but grayed out. > > > Thanks, > > Wolfpup > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110121/b941d050/attachment-0001.htm From merov at lindenlab.com Fri Jan 21 10:14:32 2011 From: merov at lindenlab.com (Merov Linden) Date: Fri, 21 Jan 2011 18:14:32 -0000 Subject: [opensource-dev] Review Request: VWR-24337: Possible crash on llassert_always(purge_list.size() >= entries_to_purge) In-Reply-To: <20110121122558.32180.48870@domU-12-31-38-00-90-68.compute-1.internal> References: <20110121122558.32180.48870@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110121181432.25766.17233@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/93/#review237 ----------------------------------------------------------- Ship it! Better! You may want to reword a bit the comment above the "while()" statement though. - Merov On Jan. 21, 2011, 4:25 a.m., Aleric Inglewood wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/93/ > ----------------------------------------------------------- > > (Updated Jan. 21, 2011, 4:25 a.m.) > > > Review request for Viewer. > > > Summary > ------- > > Just fixed the logic, so entries_to_purge won't become negative anymore, and the rest. > > > This addresses bug VWR-24337. > http://jira.secondlife.com/browse/VWR-24337 > > > Diffs > ----- > > doc/contributions.txt 422f636c3343 > indra/newview/lltexturecache.cpp 422f636c3343 > > Diff: http://codereview.secondlife.com/r/93/diff > > > Testing > ------- > > > Thanks, > > Aleric > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110121/bc58ec6d/attachment.htm From oz at lindenlab.com Fri Jan 21 10:57:00 2011 From: oz at lindenlab.com (Oz Linden (Scott Lawrence)) Date: Fri, 21 Jan 2011 13:57:00 -0500 Subject: [opensource-dev] line ordering in contributions.txt Message-ID: <4D39D6FC.1090103@lindenlab.com> > Actually, because I use changes to this file to generate some of our metrics for open source contributions, I'd prefer that any existing order be preserved: that is, add lines as needed (and adding them in order is nice), but do not reorder existing lines please. I've fixed my script - it no longer cares what order those lines are in (and generates slightly more accurate stats even when they are not reordered, since if the same issue is listed under multiple contributors it is now counted only once). From oz at lindenlab.com Fri Jan 21 12:16:48 2011 From: oz at lindenlab.com (Oz Linden) Date: Fri, 21 Jan 2011 20:16:48 -0000 Subject: [opensource-dev] Review Request: STORM-2 As a User, I want to set my own default views with specific UI layout so I can tailor my Viewer experience to the activities I'm most interested in. In-Reply-To: <20110117212408.25763.20611@domU-12-31-38-00-90-68.compute-1.internal> References: <20110117212408.25763.20611@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110121201648.32180.90394@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/98/#review238 ----------------------------------------------------------- decided this morning that this change will not be integrated yet, so closing this review pending completing the work - Oz On Jan. 17, 2011, 1:24 p.m., Andrew ProductEngine wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/98/ > ----------------------------------------------------------- > > (Updated Jan. 17, 2011, 1:24 p.m.) > > > Review request for Viewer. > > > Summary > ------- > > First pass of saving of UI state into files. > > Implemeted saving of floaters and bottombar buttons state into a named layout. This layout is saved on disk into per-user folder. The folder with layout contains LLSD files. > > Currently the following features were implemeted: > - Saving of bottomtray buttons order and visibility. > - Saving floaters rect and visibility info (multiple instances of the same floater are supported) > - Saving of sidetray tabs state (docked/undocked). > - UI for the feature. > > TODO: > - Add saving dock state for dockable floaters. > - Add LL-created default layouts and support for them. > - Refactor system of updating lists - get rid of ugly static dirty and it's check in draw. > - Add saving of sidetray open/closed state, open tab, etc. > > > This addresses bug STORM-2. > http://jira.secondlife.com/browse/STORM-2 > > > Diffs > ----- > > indra/llui/llfloater.h 422f636c3343 > indra/llui/llfloaterreg.h 422f636c3343 > indra/newview/CMakeLists.txt 422f636c3343 > indra/newview/llbottomtray.h 422f636c3343 > indra/newview/llbottomtray.cpp 422f636c3343 > indra/newview/llfloaterlayouts.h PRE-CREATION > indra/newview/llfloaterlayouts.cpp PRE-CREATION > indra/newview/llsidetray.h 422f636c3343 > indra/newview/llsidetray.cpp 422f636c3343 > indra/newview/llviewerfloaterreg.cpp 422f636c3343 > indra/newview/llviewermenu.cpp 422f636c3343 > indra/newview/skins/default/xui/en/floater_layouts.xml PRE-CREATION > indra/newview/skins/default/xui/en/floater_save_layout.xml PRE-CREATION > indra/newview/skins/default/xui/en/menu_viewer.xml 422f636c3343 > indra/newview/skins/default/xui/en/notifications.xml 422f636c3343 > > Diff: http://codereview.secondlife.com/r/98/diff > > > Testing > ------- > > > Thanks, > > Andrew > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110121/842d3818/attachment.htm From kf6kjg at gmail.com Fri Jan 21 14:51:00 2011 From: kf6kjg at gmail.com (Cron Stardust) Date: Fri, 21 Jan 2011 22:51:00 -0000 Subject: [opensource-dev] Review Request: STORM-236 Actual Code Review In-Reply-To: <20110121114426.25761.82432@domU-12-31-38-00-90-68.compute-1.internal> References: <20110121114426.25761.82432@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110121225100.25761.81221@domU-12-31-38-00-90-68.compute-1.internal> > On Jan. 21, 2011, 3:44 a.m., Boroondas Gupte wrote: > > indra/newview/skins/default/xui/en/menu_bottomtray.xml, lines 11-13 > > > > > > Begin XML comments with just "", not "" and "<-->". Typically SGML/XML comments are supposed to start with "" (note the post/pre-fixed whitespace) - however, http://www.w3.org/TR/2008/REC-xml-20081126/#sec-comments does not require the space in the syntax, it only demonstrates it. - Cron ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/113/#review229 ----------------------------------------------------------- On Jan. 20, 2011, 6:37 p.m., Wolfpup Lowenhar wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/113/ > ----------------------------------------------------------- > > (Updated Jan. 20, 2011, 6:37 p.m.) > > > Review request for Viewer. > > > Summary > ------- > > This allows the Speak Button to auto-hide for those that do not use Voice at all. > > > This addresses bug STORM-236. > http://jira.secondlife.com/browse/STORM-236 > > > Diffs > ----- > > doc/contributions.txt 9c7d543fd15d > indra/newview/llbottomtray.h 9c7d543fd15d > indra/newview/llbottomtray.cpp 9c7d543fd15d > indra/newview/llspeakbutton.cpp 9c7d543fd15d > indra/newview/skins/default/xui/en/menu_bottomtray.xml 9c7d543fd15d > > Diff: http://codereview.secondlife.com/r/113/diff > > > Testing > ------- > > Built locally and did the following: > 1 Verified that when Voice is toggled via the preference panel the Speak Button auto hid/showed. > 2 Verified that drag and drop functionality of the Speak Button was not affected. > 3 Went to a non-Voice area with Voice active and verified that button was still there but grayed out. > > > Thanks, > > Wolfpup > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110121/91b06d4d/attachment.htm From merov at lindenlab.com Fri Jan 21 16:57:42 2011 From: merov at lindenlab.com (Merov Linden) Date: Sat, 22 Jan 2011 00:57:42 -0000 Subject: [opensource-dev] Review Request: STORM-2 As a User, I want to set my own default views with specific UI layout so I can tailor my Viewer experience to the activities I'm most interested in. In-Reply-To: <20110117212408.25763.20611@domU-12-31-38-00-90-68.compute-1.internal> References: <20110117212408.25763.20611@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110122005742.25766.41002@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/98/#review240 ----------------------------------------------------------- Ship it! Good. Adding my stamp of approval. - Merov On Jan. 17, 2011, 1:24 p.m., Andrew ProductEngine wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/98/ > ----------------------------------------------------------- > > (Updated Jan. 17, 2011, 1:24 p.m.) > > > Review request for Viewer. > > > Summary > ------- > > First pass of saving of UI state into files. > > Implemeted saving of floaters and bottombar buttons state into a named layout. This layout is saved on disk into per-user folder. The folder with layout contains LLSD files. > > Currently the following features were implemeted: > - Saving of bottomtray buttons order and visibility. > - Saving floaters rect and visibility info (multiple instances of the same floater are supported) > - Saving of sidetray tabs state (docked/undocked). > - UI for the feature. > > TODO: > - Add saving dock state for dockable floaters. > - Add LL-created default layouts and support for them. > - Refactor system of updating lists - get rid of ugly static dirty and it's check in draw. > - Add saving of sidetray open/closed state, open tab, etc. > > > This addresses bug STORM-2. > http://jira.secondlife.com/browse/STORM-2 > > > Diffs > ----- > > indra/llui/llfloater.h 422f636c3343 > indra/llui/llfloaterreg.h 422f636c3343 > indra/newview/CMakeLists.txt 422f636c3343 > indra/newview/llbottomtray.h 422f636c3343 > indra/newview/llbottomtray.cpp 422f636c3343 > indra/newview/llfloaterlayouts.h PRE-CREATION > indra/newview/llfloaterlayouts.cpp PRE-CREATION > indra/newview/llsidetray.h 422f636c3343 > indra/newview/llsidetray.cpp 422f636c3343 > indra/newview/llviewerfloaterreg.cpp 422f636c3343 > indra/newview/llviewermenu.cpp 422f636c3343 > indra/newview/skins/default/xui/en/floater_layouts.xml PRE-CREATION > indra/newview/skins/default/xui/en/floater_save_layout.xml PRE-CREATION > indra/newview/skins/default/xui/en/menu_viewer.xml 422f636c3343 > indra/newview/skins/default/xui/en/notifications.xml 422f636c3343 > > Diff: http://codereview.secondlife.com/r/98/diff > > > Testing > ------- > > > Thanks, > > Andrew > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110122/bb68ae57/attachment.htm From merov at lindenlab.com Fri Jan 21 17:29:04 2011 From: merov at lindenlab.com (Merov Linden) Date: Sat, 22 Jan 2011 01:29:04 -0000 Subject: [opensource-dev] Review Request: VWR-24321: Validate textures starting with 00 too. In-Reply-To: <20110114210232.20676.90941@domU-12-31-38-00-90-68.compute-1.internal> References: <20110114210232.20676.90941@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110122012904.25761.51409@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/90/#review241 ----------------------------------------------------------- Ship it! Ok, I read the code in more details and I'm indeed convinced now that this is correct. Ship it! - Merov On Jan. 14, 2011, 1:02 p.m., Aleric Inglewood wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/90/ > ----------------------------------------------------------- > > (Updated Jan. 14, 2011, 1:02 p.m.) > > > Review request for Viewer. > > > Summary > ------- > > Trivial patch, just removes stupidity. > > > This addresses bug VWR-24321. > http://jira.secondlife.com/browse/VWR-24321 > > > Diffs > ----- > > doc/contributions.txt b0bd26c5638a > indra/newview/lltexturecache.cpp b0bd26c5638a > > Diff: http://codereview.secondlife.com/r/90/diff > > > Testing > ------- > > > Thanks, > > Aleric > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110122/14c0b16a/attachment-0001.htm From merov at lindenlab.com Fri Jan 21 17:41:47 2011 From: merov at lindenlab.com (Merov Linden) Date: Sat, 22 Jan 2011 01:41:47 -0000 Subject: [opensource-dev] Review Request: Help Needed to debug small problem with code for STORM-236. In-Reply-To: <20110120172906.25992.62891@domU-12-31-38-00-90-68.compute-1.internal> References: <20110120172906.25992.62891@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110122014147.25764.45658@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/112/#review242 ----------------------------------------------------------- Ship it! Good code wise. Please keep comments short and clean. indra/newview/llspeakbutton.cpp Prefer: // Draw the voice button only if voice chat is enabled indra/newview/skins/default/xui/en/menu_bottomtray.xml Please clean up typos (selction, visable, and <-->) - Merov On Jan. 20, 2011, 9:29 a.m., Wolfpup Lowenhar wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/112/ > ----------------------------------------------------------- > > (Updated Jan. 20, 2011, 9:29 a.m.) > > > Review request for Viewer. > > > Summary > ------- > > This is actually a request for for help to debug what I have done so far to get this working. > 1. In the current diff the button dose actualy hide and show according to if Voice is enabled or not. > 2. i have two problems at this point. > a. the space taken up by the speak button is not freed up > b. when the speak button is shown after being hidden there is an error message saying no space avaiable > (I think this is related to the fact that the space is not freed to begin with). > > > This addresses bug STORM-236. > http://jira.secondlife.com/browse/STORM-236 > > > Diffs > ----- > > doc/contributions.txt 40d0806e9800 > indra/newview/llbottomtray.cpp 40d0806e9800 > indra/newview/llspeakbutton.cpp 40d0806e9800 > indra/newview/skins/default/xui/en/menu_bottomtray.xml 40d0806e9800 > > Diff: http://codereview.secondlife.com/r/112/diff > > > Testing > ------- > > > Thanks, > > Wolfpup > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110122/7fb7e16e/attachment.htm From nickyperian at yahoo.com Fri Jan 21 18:40:56 2011 From: nickyperian at yahoo.com (Nicky Perian) Date: Fri, 21 Jan 2011 18:40:56 -0800 (PST) Subject: [opensource-dev] google-breakpad VS2010 build project. Linden Dev Help Please. Message-ID: <981846.66599.qm@web43505.mail.sp1.yahoo.com> I am trying to prove a no harm done 2005 build first. Then on to 2010. the build-cmd.sh script references "build_sln" for several entries. Example: build_sln src/client/windows/breakpad_client.sln "release|win32" exception_handler These all fail when I try them. Is build_sln common to the LL build system and not included in 3p-google-breakpad source? The sln files build with cd src/client/windows ../../tools/gyp/gyp -G msvs_version=2005 Is this just and automation thingy? Can I just build with debug and release or do I need build_sln's magic? Nicky -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110121/0bad3edc/attachment.htm From merov at lindenlab.com Fri Jan 21 18:56:17 2011 From: merov at lindenlab.com (Merov Linden) Date: Sat, 22 Jan 2011 02:56:17 -0000 Subject: [opensource-dev] Review Request: make PREHASH variables char const* const In-Reply-To: <20110120225735.25766.11933@domU-12-31-38-00-90-68.compute-1.internal> References: <20110120225735.25766.11933@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110122025617.25764.41194@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/100/#review243 ----------------------------------------------------------- Ship it! Not a fan of widespread cleanup changes as I said in a previous review, but if this is getting rid of compilation errors on some machines, I'm all for it. - Merov On Jan. 20, 2011, 2:57 p.m., Boroondas Gupte wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/100/ > ----------------------------------------------------------- > > (Updated Jan. 20, 2011, 2:57 p.m.) > > > Review request for Viewer and Seth ProductEngine. > > > Summary > ------- > > For the reason for this change, see https://jira.secondlife.com/browse/VWR-24487 and https://jira.secondlife.com/browse/VWR-24522 > > What I did: > In indra/llmessage/message_prehash.(h|cpp), I turned everything into constant pointers to constants by search/replace. Then I tried to compile and added const qualifiers in dependent code as needed to stop the compiler complaining. > > Note that comments in indra/llmessage/message_prehash.(h|cpp) say these files have been generated from the message template. If this generation wasn't a one-off thing, the generating code must be changed, too, so it won't override this change here when the generation happens the next time. > > > This addresses bug VWR-24487. > http://jira.secondlife.com/browse/VWR-24487 > > > Diffs > ----- > > doc/contributions.txt fc7e5dcf3059 > indra/llmessage/message_prehash.h fc7e5dcf3059 > indra/llmessage/message_prehash.cpp fc7e5dcf3059 > indra/llprimitive/llprimitive.h fc7e5dcf3059 > indra/llprimitive/llprimitive.cpp fc7e5dcf3059 > indra/llprimitive/llvolumemessage.h fc7e5dcf3059 > indra/llprimitive/llvolumemessage.cpp fc7e5dcf3059 > indra/llui/tests/llurlentry_stub.cpp fc7e5dcf3059 > indra/newview/tests/llremoteparcelrequest_test.cpp fc7e5dcf3059 > > Diff: http://codereview.secondlife.com/r/100/diff > > > Testing > ------- > > Compiled (standalone, 64bit Linux) with and without LL_TESTS. > Started the viewer, logged in, walked and flew around a bit. Everything seems to work. > > > Locally set _PREHASH_AgentData and _PREHASH_AgentID to (char const*)0x1 in indra/llui/tests/llurlentry_stub.cpp and indra/newview/tests/llremoteparcelrequest_test.cpp to verify they actually are never dereferenced, even when not NULL, so that using NULL pointers instead of place holder data won't change what code paths gets tested. Both tests binaries executed without crashes and all the contained tests passed. > > > Thanks, > > Boroondas > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110122/b9a52504/attachment.htm From sllists at boroon.dasgupta.ch Sat Jan 22 03:20:07 2011 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Sat, 22 Jan 2011 11:20:07 -0000 Subject: [opensource-dev] Review Request: make PREHASH variables char const* const In-Reply-To: <20110120225735.25766.11933@domU-12-31-38-00-90-68.compute-1.internal> References: <20110120225735.25766.11933@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110122112007.25765.77006@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/100/#review244 ----------------------------------------------------------- As already mentioned in the review request description, comments in message_prehash.h and message_prehash.cpp claim that these files have been generated: indra/llmessage/message_prehash.h indra/llmessage/message_prehash.cpp Do we have to expect them to be re-generated again in the future? If so, the code for generating them should be changed alongside the change I propose here, so that future generations (pun intended) won't inadvertently override and revert the change. At first, I thought the code for generating them was not part of the source tree, but now I think I have located it in indra/llmessage/message.cpp. (I would have expected it to be a script, not a compiled program.) I will investigate this further and augment the review request with a change to the generating code, too, if applicable. - Boroondas On Jan. 20, 2011, 2:57 p.m., Boroondas Gupte wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/100/ > ----------------------------------------------------------- > > (Updated Jan. 20, 2011, 2:57 p.m.) > > > Review request for Viewer and Seth ProductEngine. > > > Summary > ------- > > For the reason for this change, see https://jira.secondlife.com/browse/VWR-24487 and https://jira.secondlife.com/browse/VWR-24522 > > What I did: > In indra/llmessage/message_prehash.(h|cpp), I turned everything into constant pointers to constants by search/replace. Then I tried to compile and added const qualifiers in dependent code as needed to stop the compiler complaining. > > Note that comments in indra/llmessage/message_prehash.(h|cpp) say these files have been generated from the message template. If this generation wasn't a one-off thing, the generating code must be changed, too, so it won't override this change here when the generation happens the next time. > > > This addresses bug VWR-24487. > http://jira.secondlife.com/browse/VWR-24487 > > > Diffs > ----- > > doc/contributions.txt fc7e5dcf3059 > indra/llmessage/message_prehash.h fc7e5dcf3059 > indra/llmessage/message_prehash.cpp fc7e5dcf3059 > indra/llprimitive/llprimitive.h fc7e5dcf3059 > indra/llprimitive/llprimitive.cpp fc7e5dcf3059 > indra/llprimitive/llvolumemessage.h fc7e5dcf3059 > indra/llprimitive/llvolumemessage.cpp fc7e5dcf3059 > indra/llui/tests/llurlentry_stub.cpp fc7e5dcf3059 > indra/newview/tests/llremoteparcelrequest_test.cpp fc7e5dcf3059 > > Diff: http://codereview.secondlife.com/r/100/diff > > > Testing > ------- > > Compiled (standalone, 64bit Linux) with and without LL_TESTS. > Started the viewer, logged in, walked and flew around a bit. Everything seems to work. > > > Locally set _PREHASH_AgentData and _PREHASH_AgentID to (char const*)0x1 in indra/llui/tests/llurlentry_stub.cpp and indra/newview/tests/llremoteparcelrequest_test.cpp to verify they actually are never dereferenced, even when not NULL, so that using NULL pointers instead of place holder data won't change what code paths gets tested. Both tests binaries executed without crashes and all the contained tests passed. > > > Thanks, > > Boroondas > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110122/e2ec0e80/attachment-0001.htm From sllists at boroon.dasgupta.ch Sat Jan 22 07:40:56 2011 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Sat, 22 Jan 2011 15:40:56 -0000 Subject: [opensource-dev] Review Request: make PREHASH variables char const* const In-Reply-To: <20110120225735.25766.11933@domU-12-31-38-00-90-68.compute-1.internal> References: <20110120225735.25766.11933@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110122154056.32180.11384@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/100/ ----------------------------------------------------------- (Updated Jan. 22, 2011, 7:40 a.m.) Review request for Viewer and Seth ProductEngine. Changes ------- Found and changed the generating code for message_prehash.(h|cpp), too. Summary (updated) ------- For the reason for this change, see https://jira.secondlife.com/browse/VWR-24487 and https://jira.secondlife.com/browse/VWR-24522 What I did: In indra/llmessage/message_prehash.(h|cpp), I turned everything into constant pointers to constants by search/replace. Then I tried to compile and added const qualifiers in dependent code as needed to stop the compiler complaining. Note that comments in indra/llmessage/message_prehash.(h|cpp) say these files have been generated from the message template. Because this generation might not have been a one-off thing, I changed the generating code, too, so it won't override this change here when the generation happens the next time. However, that part of the code is not called by Viewer, although the relevant function ? dump_prehash_files() ? ends up in the Viewer binary. That function probably gets called by the simulator, when one runs the latter with -prehash. (See https://bitbucket.org/lindenlab/viewer-development/src/fc7e5dcf3059/indra/llmessage/message.cpp#cl-2532 ) This addresses bug VWR-24487. http://jira.secondlife.com/browse/VWR-24487 Diffs (updated) ----- doc/contributions.txt fc7e5dcf3059 indra/llmessage/message.cpp fc7e5dcf3059 indra/llmessage/message_prehash.h fc7e5dcf3059 indra/llmessage/message_prehash.cpp fc7e5dcf3059 indra/llprimitive/llprimitive.h fc7e5dcf3059 indra/llprimitive/llprimitive.cpp fc7e5dcf3059 indra/llprimitive/llvolumemessage.h fc7e5dcf3059 indra/llprimitive/llvolumemessage.cpp fc7e5dcf3059 indra/llui/tests/llurlentry_stub.cpp fc7e5dcf3059 indra/newview/tests/llremoteparcelrequest_test.cpp fc7e5dcf3059 Diff: http://codereview.secondlife.com/r/100/diff Testing (updated) ------- Compiled (standalone, 64bit Linux) with and without LL_TESTS. Started the viewer, logged in, walked and flew around a bit. Everything seems to work. Locally set _PREHASH_AgentData and _PREHASH_AgentID to (char const*)0x1 in indra/llui/tests/llurlentry_stub.cpp and indra/newview/tests/llremoteparcelrequest_test.cpp to verify they actually are never dereferenced, even when not NULL, so that using NULL pointers instead of place holder data won't change what code paths gets tested. Both tests binaries executed without crashes and all the contained tests passed. Locally invoked start_messaging_system() with b_dump_prehash_file == true instead of FALSE, to see what would be generated after my change to dump_prehash_files(). The message_prehash.(h|cpp) generated by that had the correct type qualifiers and formatting, but some lines were removed or added compared to the modified files from the source tree. That probably means that the files aren't fully synchronized with the message template file in the source tree. Because the "added" constants are spread all over the file, while the "removed" ones were at the end, I'd wager that message_prehash.(h|cpp) in the viewer source tree are actually more up-to-date than the message template file in the source tree. Thanks, Boroondas -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110122/6848f0b5/attachment.htm From Aleric.Inglewood at gmail.com Sat Jan 22 19:41:13 2011 From: Aleric.Inglewood at gmail.com (Aleric Inglewood) Date: Sun, 23 Jan 2011 03:41:13 -0000 Subject: [opensource-dev] Review Request: make PREHASH variables char const* const In-Reply-To: <20110122154056.32180.11384@domU-12-31-38-00-90-68.compute-1.internal> References: <20110122154056.32180.11384@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110123034113.25760.75236@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/100/#review245 ----------------------------------------------------------- Ship it! Latest diff looks good. Great that you found the generator for this code! - Aleric On Jan. 22, 2011, 7:40 a.m., Boroondas Gupte wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/100/ > ----------------------------------------------------------- > > (Updated Jan. 22, 2011, 7:40 a.m.) > > > Review request for Viewer and Seth ProductEngine. > > > Summary > ------- > > For the reason for this change, see https://jira.secondlife.com/browse/VWR-24487 and https://jira.secondlife.com/browse/VWR-24522 > > What I did: > In indra/llmessage/message_prehash.(h|cpp), I turned everything into constant pointers to constants by search/replace. Then I tried to compile and added const qualifiers in dependent code as needed to stop the compiler complaining. > > Note that comments in indra/llmessage/message_prehash.(h|cpp) say these files have been generated from the message template. Because this generation might not have been a one-off thing, I changed the generating code, too, so it won't override this change here when the generation happens the next time. However, that part of the code is not called by Viewer, although the relevant function ? dump_prehash_files() ? ends up in the Viewer binary. That function probably gets called by the simulator, when one runs the latter with -prehash. (See https://bitbucket.org/lindenlab/viewer-development/src/fc7e5dcf3059/indra/llmessage/message.cpp#cl-2532 ) > > > This addresses bug VWR-24487. > http://jira.secondlife.com/browse/VWR-24487 > > > Diffs > ----- > > doc/contributions.txt fc7e5dcf3059 > indra/llmessage/message.cpp fc7e5dcf3059 > indra/llmessage/message_prehash.h fc7e5dcf3059 > indra/llmessage/message_prehash.cpp fc7e5dcf3059 > indra/llprimitive/llprimitive.h fc7e5dcf3059 > indra/llprimitive/llprimitive.cpp fc7e5dcf3059 > indra/llprimitive/llvolumemessage.h fc7e5dcf3059 > indra/llprimitive/llvolumemessage.cpp fc7e5dcf3059 > indra/llui/tests/llurlentry_stub.cpp fc7e5dcf3059 > indra/newview/tests/llremoteparcelrequest_test.cpp fc7e5dcf3059 > > Diff: http://codereview.secondlife.com/r/100/diff > > > Testing > ------- > > Compiled (standalone, 64bit Linux) with and without LL_TESTS. > Started the viewer, logged in, walked and flew around a bit. Everything seems to work. > > > Locally set _PREHASH_AgentData and _PREHASH_AgentID to (char const*)0x1 in indra/llui/tests/llurlentry_stub.cpp and indra/newview/tests/llremoteparcelrequest_test.cpp to verify they actually are never dereferenced, even when not NULL, so that using NULL pointers instead of place holder data won't change what code paths gets tested. Both tests binaries executed without crashes and all the contained tests passed. > > Locally invoked start_messaging_system() with b_dump_prehash_file == true instead of FALSE, to see what would be generated after my change to dump_prehash_files(). > The message_prehash.(h|cpp) generated by that had the correct type qualifiers and formatting, but some lines were removed or added compared to the modified files from the source tree. That probably means that the files aren't fully synchronized with the message template file in the source tree. Because the "added" constants are spread all over the file, while the "removed" ones were at the end, I'd wager that message_prehash.(h|cpp) in the viewer source tree are actually more up-to-date than the message template file in the source tree. > > > Thanks, > > Boroondas > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110123/d94b5aba/attachment.htm From Lance.Corrimal at eregion.de Mon Jan 24 01:29:27 2011 From: Lance.Corrimal at eregion.de (Lance Corrimal) Date: Mon, 24 Jan 2011 10:29:27 +0100 Subject: [opensource-dev] building on Mac OS X 10.6 is giving me multiple headaches... anyone able to help? Message-ID: <201101241029.27420.Lance.Corrimal@eregion.de> Hi there, I'm trying to build 2.4.x based on Mac OS X and I'm having several problems with that... - I'm pretty sure that I've located every place in the source that defines the name of the resulting .app and changed them to read "Dolphin Viewer 2.app" instead of "Second Life.app" and yet, the build process still tries to install some of the resulting stuff in Second Life.app and some in Dolphin Viewer 2.app, and at that point only Second Life.app exists so the build fails. -how do i configure the build on mac os to use GCC 4.0 instead of 4.2 If i want to build using unix makefiles instead of the xcode gui? - how do i configure the build process to builds against the 10.5 SDK instead of the 10.6 SDK when using unix makefiles instead of xcode gui? anyone got hints for me? bye, LC From oz at lindenlab.com Mon Jan 24 06:42:57 2011 From: oz at lindenlab.com (Oz Linden) Date: Mon, 24 Jan 2011 14:42:57 -0000 Subject: [opensource-dev] Review Request: make PREHASH variables char const* const In-Reply-To: <20110122154056.32180.11384@domU-12-31-38-00-90-68.compute-1.internal> References: <20110122154056.32180.11384@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110124144257.488.4038@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/100/#review246 ----------------------------------------------------------- If the file is generated, what is it doing checked into the source tree at all? This sounds to me like an invitation to future errors. Is there some reason why we should not just delete the checked in version and have it generated every time it's needed? - Oz On Jan. 22, 2011, 7:40 a.m., Boroondas Gupte wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/100/ > ----------------------------------------------------------- > > (Updated Jan. 22, 2011, 7:40 a.m.) > > > Review request for Viewer and Seth ProductEngine. > > > Summary > ------- > > For the reason for this change, see https://jira.secondlife.com/browse/VWR-24487 and https://jira.secondlife.com/browse/VWR-24522 > > What I did: > In indra/llmessage/message_prehash.(h|cpp), I turned everything into constant pointers to constants by search/replace. Then I tried to compile and added const qualifiers in dependent code as needed to stop the compiler complaining. > > Note that comments in indra/llmessage/message_prehash.(h|cpp) say these files have been generated from the message template. Because this generation might not have been a one-off thing, I changed the generating code, too, so it won't override this change here when the generation happens the next time. However, that part of the code is not called by Viewer, although the relevant function ? dump_prehash_files() ? ends up in the Viewer binary. That function probably gets called by the simulator, when one runs the latter with -prehash. (See https://bitbucket.org/lindenlab/viewer-development/src/fc7e5dcf3059/indra/llmessage/message.cpp#cl-2532 ) > > > This addresses bug VWR-24487. > http://jira.secondlife.com/browse/VWR-24487 > > > Diffs > ----- > > doc/contributions.txt fc7e5dcf3059 > indra/llmessage/message.cpp fc7e5dcf3059 > indra/llmessage/message_prehash.h fc7e5dcf3059 > indra/llmessage/message_prehash.cpp fc7e5dcf3059 > indra/llprimitive/llprimitive.h fc7e5dcf3059 > indra/llprimitive/llprimitive.cpp fc7e5dcf3059 > indra/llprimitive/llvolumemessage.h fc7e5dcf3059 > indra/llprimitive/llvolumemessage.cpp fc7e5dcf3059 > indra/llui/tests/llurlentry_stub.cpp fc7e5dcf3059 > indra/newview/tests/llremoteparcelrequest_test.cpp fc7e5dcf3059 > > Diff: http://codereview.secondlife.com/r/100/diff > > > Testing > ------- > > Compiled (standalone, 64bit Linux) with and without LL_TESTS. > Started the viewer, logged in, walked and flew around a bit. Everything seems to work. > > > Locally set _PREHASH_AgentData and _PREHASH_AgentID to (char const*)0x1 in indra/llui/tests/llurlentry_stub.cpp and indra/newview/tests/llremoteparcelrequest_test.cpp to verify they actually are never dereferenced, even when not NULL, so that using NULL pointers instead of place holder data won't change what code paths gets tested. Both tests binaries executed without crashes and all the contained tests passed. > > Locally invoked start_messaging_system() with b_dump_prehash_file == true instead of FALSE, to see what would be generated after my change to dump_prehash_files(). > The message_prehash.(h|cpp) generated by that had the correct type qualifiers and formatting, but some lines were removed or added compared to the modified files from the source tree. That probably means that the files aren't fully synchronized with the message template file in the source tree. Because the "added" constants are spread all over the file, while the "removed" ones were at the end, I'd wager that message_prehash.(h|cpp) in the viewer source tree are actually more up-to-date than the message template file in the source tree. > > > Thanks, > > Boroondas > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110124/187ae339/attachment.htm From q at lindenlab.com Mon Jan 24 08:17:38 2011 From: q at lindenlab.com (Kent Quirk) Date: Mon, 24 Jan 2011 16:17:38 -0000 Subject: [opensource-dev] Review Request: make PREHASH variables char const* const In-Reply-To: <20110124144257.488.4038@domU-12-31-38-00-90-68.compute-1.internal> References: <20110124144257.488.4038@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110124161738.30502.67844@domU-12-31-38-00-90-68.compute-1.internal> > On Jan. 24, 2011, 6:42 a.m., Oz Linden wrote: > > If the file is generated, what is it doing checked into the source tree at all? This sounds to me like an invitation to future errors. > > > > Is there some reason why we should not just delete the checked in version and have it generated every time it's needed? These files were generated, but the generation is a manual process and needs to take place on both the server and the viewer to ensure compatibility because this is part of a protocol definition. This is an area where we could end up breaking compatibility if we're not very careful, so please make only the changes needed to make it compile and make no semantic changes. - Kent ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/100/#review246 ----------------------------------------------------------- On Jan. 22, 2011, 7:40 a.m., Boroondas Gupte wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/100/ > ----------------------------------------------------------- > > (Updated Jan. 22, 2011, 7:40 a.m.) > > > Review request for Viewer and Seth ProductEngine. > > > Summary > ------- > > For the reason for this change, see https://jira.secondlife.com/browse/VWR-24487 and https://jira.secondlife.com/browse/VWR-24522 > > What I did: > In indra/llmessage/message_prehash.(h|cpp), I turned everything into constant pointers to constants by search/replace. Then I tried to compile and added const qualifiers in dependent code as needed to stop the compiler complaining. > > Note that comments in indra/llmessage/message_prehash.(h|cpp) say these files have been generated from the message template. Because this generation might not have been a one-off thing, I changed the generating code, too, so it won't override this change here when the generation happens the next time. However, that part of the code is not called by Viewer, although the relevant function ? dump_prehash_files() ? ends up in the Viewer binary. That function probably gets called by the simulator, when one runs the latter with -prehash. (See https://bitbucket.org/lindenlab/viewer-development/src/fc7e5dcf3059/indra/llmessage/message.cpp#cl-2532 ) > > > This addresses bug VWR-24487. > http://jira.secondlife.com/browse/VWR-24487 > > > Diffs > ----- > > doc/contributions.txt fc7e5dcf3059 > indra/llmessage/message.cpp fc7e5dcf3059 > indra/llmessage/message_prehash.h fc7e5dcf3059 > indra/llmessage/message_prehash.cpp fc7e5dcf3059 > indra/llprimitive/llprimitive.h fc7e5dcf3059 > indra/llprimitive/llprimitive.cpp fc7e5dcf3059 > indra/llprimitive/llvolumemessage.h fc7e5dcf3059 > indra/llprimitive/llvolumemessage.cpp fc7e5dcf3059 > indra/llui/tests/llurlentry_stub.cpp fc7e5dcf3059 > indra/newview/tests/llremoteparcelrequest_test.cpp fc7e5dcf3059 > > Diff: http://codereview.secondlife.com/r/100/diff > > > Testing > ------- > > Compiled (standalone, 64bit Linux) with and without LL_TESTS. > Started the viewer, logged in, walked and flew around a bit. Everything seems to work. > > > Locally set _PREHASH_AgentData and _PREHASH_AgentID to (char const*)0x1 in indra/llui/tests/llurlentry_stub.cpp and indra/newview/tests/llremoteparcelrequest_test.cpp to verify they actually are never dereferenced, even when not NULL, so that using NULL pointers instead of place holder data won't change what code paths gets tested. Both tests binaries executed without crashes and all the contained tests passed. > > Locally invoked start_messaging_system() with b_dump_prehash_file == true instead of FALSE, to see what would be generated after my change to dump_prehash_files(). > The message_prehash.(h|cpp) generated by that had the correct type qualifiers and formatting, but some lines were removed or added compared to the modified files from the source tree. That probably means that the files aren't fully synchronized with the message template file in the source tree. Because the "added" constants are spread all over the file, while the "removed" ones were at the end, I'd wager that message_prehash.(h|cpp) in the viewer source tree are actually more up-to-date than the message template file in the source tree. > > > Thanks, > > Boroondas > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110124/e2b90c5c/attachment.htm From arrehn at gmail.com Mon Jan 24 09:17:49 2011 From: arrehn at gmail.com (Arrehn Oberlander) Date: Mon, 24 Jan 2011 12:17:49 -0500 Subject: [opensource-dev] building on Mac OS X 10.6 is giving me multiple headaches... anyone able to help? In-Reply-To: <201101241029.27420.Lance.Corrimal@eregion.de> References: <201101241029.27420.Lance.Corrimal@eregion.de> Message-ID: Here's some example lines I use for building firestorm on macosx. You'll want to change the variables,strings,and optimizations to fit Dolphin. I hope this helps. A key takeaway is to use "xcodebuild" for command line builds and not make. ./develop.py -t $BTYPE configure -DPACKAGE:BOOL=ON -DVIEWER_CHANNEL:STRING=Firestorm-$CHANNEL -DVIEWER_LOGIN_CHANNEL:STRING=Firestorm-$CHANNEL # LL build wants this directory to exist, but doesn't make it itself. mkdir -p ./build-darwin-i386/newview/Release/Firestorm.app xcodebuild -project build-darwin-i386/SecondLife.xcodeproj \ -alltargets -configuration $BTYPE GCC_VERSION=4.2 \ -sdk macosx10.5 GCC_OPTIMIZATION_LEVEL=3 ARCHS=i386 \ GCC_ENABLE_SSE3_EXTENSIONS=YES On Mon, Jan 24, 2011 at 4:29 AM, Lance Corrimal wrote: > Hi there, > > I'm trying to build 2.4.x based on Mac OS X and I'm having several problems > with that... > > > - I'm pretty sure that I've located every place in the source that defines > the > name of the resulting .app and changed them to read "Dolphin Viewer 2.app" > instead of "Second Life.app" and yet, the build process still tries to > install > some of the resulting stuff in Second Life.app and some in Dolphin Viewer > 2.app, and at that point only Second Life.app exists so the build fails. > > -how do i configure the build on mac os to use GCC 4.0 instead of 4.2 If i > want to build using unix makefiles instead of the xcode gui? > > - how do i configure the build process to builds against the 10.5 SDK > instead > of the 10.6 SDK when using unix makefiles instead of xcode gui? > > > > anyone got hints for me? > > > > 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/20110124/10a454c5/attachment-0001.htm From angel_of_crimson at hotmail.com Mon Jan 24 09:25:47 2011 From: angel_of_crimson at hotmail.com (Erin Mallory) Date: Mon, 24 Jan 2011 12:25:47 -0500 Subject: [opensource-dev] from debug to prefences Message-ID: one of the things that oz and q have been grousing (to use oz's word) about lately is that there are LOTS of preferences in the debug menu that really don't have debug functions but are preferences. Both oz and q feel that the preferences bar is already kind of full though many users want to see more preferences. What I propose is kind of a compromise. Here's how it would work. We take the existing advanced preferences tab and turn it into a floater activated if you click on where the advanced tab is now. we then bump many of the preferences that are in the debug over. we can do it in kinda a category form as the sketch here shows or break it up into tabs. This would give the ui more of an mmo like presences control which would not necessarily be a bad thing and give faster, very easy and intuitive access to the more advanced features for those that want them and yet also allow us to keep both the preferences and debug consoles "clean." with some careful monitoring and feedback from the users we could then possibly narrow down what settings are not really needed and eliminate them off this panel and conversely have a space to add new preferences as well. I'm sure someone is going to argue that this would just make things more complicated both in the short term and long term. I'm going to attempt to answer those as follows. As far as the short term, yes it would. I'm sure it would involve quite a bit of code reworking and discussion and stuff. It would also take users a bit of time to adjust to the changes. In the long term, I think it would actually be simpler this way and add to the new user experience. by setting up things this way we could add ui hints and/or tool tips that explain what these preferences do, and if this one panel gets crowded, i don't think that most users will mind. in fact those used to mmo's will be kind of expecting it. in the mean time it gives us a place to part lesser used preferences from the prefences control, and clears up the debug menu while also making it easier to both move more used features back into the preferences menu and setting up for eventually allowing us to pick and choose what preferences we want where. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110124/f9638c28/attachment-0001.htm -------------- next part -------------- A non-text attachment was scrubbed... Name: new advanced copy.jpg Type: image/jpeg Size: 110155 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110124/f9638c28/attachment-0001.jpg From oz at lindenlab.com Mon Jan 24 09:43:18 2011 From: oz at lindenlab.com (Oz Linden) Date: Mon, 24 Jan 2011 17:43:18 -0000 Subject: [opensource-dev] Review Request: make PREHASH variables char const* const In-Reply-To: <20110122154056.32180.11384@domU-12-31-38-00-90-68.compute-1.internal> References: <20110122154056.32180.11384@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110124174318.30496.23930@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/100/#review248 ----------------------------------------------------------- Given that Boroondas reports that the message.cpp in the viewer source tree does not produce the same generated file as what we have checked in, and Q's comment that this shared code, should we remove the message.cpp from this tree and just use the generated file? Would that break tests? It seems axiomatic to me that there should only be one source for this - if the authoritative one is the one in the simulator sources, that's fine, but there should only be one. I don't like the idea of making changes (however good they are, and I agree that the new declarations are cleaner) that are not in sync with the server side. - Oz On Jan. 22, 2011, 7:40 a.m., Boroondas Gupte wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/100/ > ----------------------------------------------------------- > > (Updated Jan. 22, 2011, 7:40 a.m.) > > > Review request for Viewer and Seth ProductEngine. > > > Summary > ------- > > For the reason for this change, see https://jira.secondlife.com/browse/VWR-24487 and https://jira.secondlife.com/browse/VWR-24522 > > What I did: > In indra/llmessage/message_prehash.(h|cpp), I turned everything into constant pointers to constants by search/replace. Then I tried to compile and added const qualifiers in dependent code as needed to stop the compiler complaining. > > Note that comments in indra/llmessage/message_prehash.(h|cpp) say these files have been generated from the message template. Because this generation might not have been a one-off thing, I changed the generating code, too, so it won't override this change here when the generation happens the next time. However, that part of the code is not called by Viewer, although the relevant function ? dump_prehash_files() ? ends up in the Viewer binary. That function probably gets called by the simulator, when one runs the latter with -prehash. (See https://bitbucket.org/lindenlab/viewer-development/src/fc7e5dcf3059/indra/llmessage/message.cpp#cl-2532 ) > > > This addresses bug VWR-24487. > http://jira.secondlife.com/browse/VWR-24487 > > > Diffs > ----- > > doc/contributions.txt fc7e5dcf3059 > indra/llmessage/message.cpp fc7e5dcf3059 > indra/llmessage/message_prehash.h fc7e5dcf3059 > indra/llmessage/message_prehash.cpp fc7e5dcf3059 > indra/llprimitive/llprimitive.h fc7e5dcf3059 > indra/llprimitive/llprimitive.cpp fc7e5dcf3059 > indra/llprimitive/llvolumemessage.h fc7e5dcf3059 > indra/llprimitive/llvolumemessage.cpp fc7e5dcf3059 > indra/llui/tests/llurlentry_stub.cpp fc7e5dcf3059 > indra/newview/tests/llremoteparcelrequest_test.cpp fc7e5dcf3059 > > Diff: http://codereview.secondlife.com/r/100/diff > > > Testing > ------- > > Compiled (standalone, 64bit Linux) with and without LL_TESTS. > Started the viewer, logged in, walked and flew around a bit. Everything seems to work. > > > Locally set _PREHASH_AgentData and _PREHASH_AgentID to (char const*)0x1 in indra/llui/tests/llurlentry_stub.cpp and indra/newview/tests/llremoteparcelrequest_test.cpp to verify they actually are never dereferenced, even when not NULL, so that using NULL pointers instead of place holder data won't change what code paths gets tested. Both tests binaries executed without crashes and all the contained tests passed. > > Locally invoked start_messaging_system() with b_dump_prehash_file == true instead of FALSE, to see what would be generated after my change to dump_prehash_files(). > The message_prehash.(h|cpp) generated by that had the correct type qualifiers and formatting, but some lines were removed or added compared to the modified files from the source tree. That probably means that the files aren't fully synchronized with the message template file in the source tree. Because the "added" constants are spread all over the file, while the "removed" ones were at the end, I'd wager that message_prehash.(h|cpp) in the viewer source tree are actually more up-to-date than the message template file in the source tree. > > > Thanks, > > Boroondas > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110124/d19f1757/attachment.htm From jhwelch at gmail.com Mon Jan 24 10:05:12 2011 From: jhwelch at gmail.com (Jonathan Welch) Date: Mon, 24 Jan 2011 13:05:12 -0500 Subject: [opensource-dev] from debug to prefences In-Reply-To: References: Message-ID: There are approximately 1,100 entries in settings.xml, which is the list you see in the Debug Settings floater (perhaps it should be renamed to just Settings). I don't see any practical way of having all those available in any kind of sane preferences menu system. It would be good to generate a list of entries that are in there and never used by the code. Those could be eliminated without much discussion. You can find a pretty recent list here http://wiki.secondlife.com/wiki/Debug_Settings From cmvmh at ymail.com Mon Jan 24 10:21:57 2011 From: cmvmh at ymail.com (Cristy Husbands) Date: Mon, 24 Jan 2011 10:21:57 -0800 (PST) Subject: [opensource-dev] Feature Request - feet option Message-ID: <100139.33642.qm@web120316.mail.ne1.yahoo.com> As a user and builder I would like to be able to build without having to pull out measuring tapes or my calculater to get accurate "foot" measurement to keep things to a realistic size. I would love for their to be an option in the build tool to translate the meters to feet. Just have a little drop down that says use "feet" measurement. I noticed that the library contains examples of avatar height, doors, ceilings, all this would be unneeded if we could translate the measurement by feet. Thank you "Anything worth doing, is worth doing well" -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110124/3cf81578/attachment.htm From akanevsky at productengine.com Mon Jan 24 10:23:34 2011 From: akanevsky at productengine.com (Anya Kanevsky) Date: Mon, 24 Jan 2011 10:23:34 -0800 Subject: [opensource-dev] Daily Scrum Summary - Friday, January 21 Message-ID: Whoa, sorry. Better late than never. Friday, January 21, 2011 General Notes ------------------------------ - MMOTD: Oz - Please remember to put descriptions next to the jira number in your report when possible. Team Status ------------------------------ Merov Linden ------------------------------ *PAST* - STORM-745 : KDU Perf : Redone the plan so to gather consistent data (see JIRA). Ran it for Mac. Will run for Windows and Linux Monday. - SH-761 and others: merge test, fail, discussing with shining how best to get that in viewer-development - Code reviews: trying to reduce my backlog here and get JIRAs to move along sprint 10 *FUTURE* - SH-761, etc : get a clear merge list from shining - STORM-748 : Fix TC builds - STORM-745 : waiting pattern till Monday *IMPEDIMENTS* - none Oz Linden ------------------------------ *PAST* - Merge Monkey - Patch triage from codereview - Enhanced contribution stats script - tolerates reordered lines in contributions.txt - counts files & lines touched *FUTURE* - Merge Monkey - More code reviews - STORM-312 *IMPEDIMENTS* - none Q Linden ------------------------------ *PAST* - Passed off VWR-24426 to Oz - Internal meetings - Dr Appts - triage - 2.5 beta 1 blog post and monitoring - Planning trip to SF *FUTURE* - Meetings - 2.5 beta 2 review *IMPEDIMENTS* - none Esbee Linden ------------------------------ *PAST* - Jira ticket reviews and cleanup - Finished reviewing tickets assigned to Esbee Linden - Finished reviewing tickets assigned to Snowstorm Team - Completed last PO review (approved a bunch of tickets) - Wrote goodbye email to fellow Lindens FUTURE - Go back to being a Resi IMPEDIMENTS - Goodbye, friends. I love you, Snowstormers. *FUTURE* - Review Snowstorm Team product backlog and bug log - Tix which require feedback: STORM-28, -812, -226, -174 - Review developer build for the tix in the PO review queue: STORM-2, -383, -484, -844, -834, -832, -715 https://jira.secondlife.com/secure/IssueNavigator.jspa?requestId=13662&mode=hide - Hopefully work on STORM-26 w/Q - Review tickets assigned to me *IMPEDIMENTS* - None Paul ProductEngine ------------------------------ *PAST* - BUG STORM-680 (Avaline callers are added to the Recent list) - Worked on this bug, but it'll take much more time to fix it without debugger. For some reason voice is unavailable in debug mode (in Linux). As tomorrow I'll install Windows on my machine, in which voice is working in debug mode, I'll fix it. - BUG STORM-513 ("Allow media to auto - play" check-box is enable after Media check-box was unchecked) - WIP. 90%. Estimate ~ 1 hour. *FUTURE* - Install Windows 7 on my machine as second OS. - BUG STORM-513 ("Allow media to auto - play" check-box is enable after Media check-box was unchecked) - BUG STORM-680 (Avaline callers are added to the Recent list) *IMPEDIMENTS* - none Seth Productengine ------------------------------ *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. - Investigating problems and suggestions given in latest comments. Asked questions to product owner in jira. *FUTURE* - Story (STORM-526) Log out failure during Login causes loss of pending offers, including inventory *IMPEDIMENTS* - 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. - Waiting for product owner answers. Vadim Productengine ------------------------------ *PAST* - Resolved as not reproducible: - Bug STORM-371 (One instance of Viewer is crashed while restarting if language was changed in one of two running viewer's instance). - Bug STORM-345 (Landmark's overflow list appears aft