Re: [opensource-dev] "Nearby" people tab

[Oz Linden (Scott Lawrence)]

On 2011-01-30 7:47, Hitomi Tiponi wrote:
I have been having this trouble on some sims for the last few days 
(using 2.5.1 Beta 2 and later).  I have been trying to figure out the 
cause or something that may tie in the various sims it seems to happen 
on - but so far without luck.  On other sims this works as expected.

And yes - this happens on sims at ground level as well.

---

>Date: Sat, 29 Jan 2011 17:50:23 -0600
>From: Dave Booth >

>Subject: [opensource-dev] "Nearby" people tab
>To: OpenSource Mailing List >
>Message-ID: <4d44a7bf.9090...@meadowlakearts.com 
>

>Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
>Whats the expected behavior of this tab of the people sidebar? I'm
>currently sitting in a room with 14 other folks, half of whom are on my
>flist and all within chat range - but this tab tells me "no one nearby".
>Currently on Second Life 2.6.0 (21) Jan 29 2011 12:57:40 (Second
>Life Development) but to be honest I dont think I've EVER seen that tab
>populated, no matter what build or how crowded the venue.


It would be interesting to see what was in the log file for the period 
of time that the window was not properly filled 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

Re: [opensource-dev] Review Request: (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

[Vadim ProductEngine]

---
This is an automatically generated e-mail. To reply, visit:
http://codereview.secondlife.com/r/128/#review283
---

Ship it!


- Vadim


On Jan. 28, 2011, 11:37 a.m., Seth ProductEngine wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/128/
> ---
> 
> (Updated Jan. 28, 2011, 11:37 a.m.)
> 
> 
> Review request for Viewer and Vadim ProductEngine.
> 
> 
> Summary
> ---
> 
> - Added "Sort Folders Always by Name" setting.
> - Removed unused settings Inventory.Folders by Name/Sort by Date/Sort by 
> Name/System Folders to Top.
> 
> 
> This addresses bug STORM-316.
> http://jira.secondlife.com/browse/STORM-316
> 
> 
> Diffs
> -
> 
>   indra/newview/llpanelmaininventory.cpp b542f8134a2b 
>   indra/newview/skins/default/xui/en/menu_inventory_gear_default.xml 
> b542f8134a2b 
> 
> Diff: http://codereview.secondlife.com/r/128/diff
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Seth
> 
>

___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Review Request: Use consistent path for all *.py scripts

[Vadim ProductEngine]

---
This is an automatically generated e-mail. To reply, visit:
http://codereview.secondlife.com/r/129/#review284
---


Why didn't you choose "!/usr/bin/env python"? It seems more flexible.

- Vadim


On Jan. 28, 2011, 5:56 p.m., Merov Linden wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/129/
> ---
> 
> (Updated Jan. 28, 2011, 5:56 p.m.)
> 
> 
> Review request for Viewer.
> 
> 
> Summary
> ---
> 
> Simple consistency change, using "#!/usr/bin/python" in all python script.
> 
> 
> This addresses bug STORM-937.
> http://jira.secondlife.com/browse/STORM-937
> 
> 
> Diffs
> -
> 
>   indra/copy_win_scripts/start-client.py b542f8134a2b 
>   indra/develop.py b542f8134a2b 
>   indra/lib/python/indra/util/simperf_host_xml_parser.py b542f8134a2b 
>   indra/lib/python/indra/util/simperf_oprof_interface.py b542f8134a2b 
>   indra/lib/python/indra/util/test_win32_manifest.py b542f8134a2b 
>   indra/newview/generate_breakpad_symbols.py b542f8134a2b 
>   scripts/build_version.py b542f8134a2b 
>   scripts/install.py b542f8134a2b 
> 
> Diff: http://codereview.secondlife.com/r/129/diff
> 
> 
> Testing
> ---
> 
> Pulled into a test repo and build successfully on all platforms on TC so I 
> guess no bad surprise here.
> 
> 
> Thanks,
> 
> 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

Re: [opensource-dev] Review Request: VWR-24667; Copy3rdPartyLibs.cmake needs to account for Visual Studio 10 and Visual Studio 10 Express.

[Nicky Perian]

---
This is an automatically generated e-mail. To reply, visit:
http://codereview.secondlife.com/r/131/
---

(Updated Jan. 31, 2011, 7:34 a.m.)


Review request for Viewer.


Changes
---

Modified to include Jonathan Yap's review recommendation from 
https://jira.secondlife.com/browse/STORM-932. Added code from merov's wip at 
https://jira.secondlife.com/browse/STORM-860 variable declarations for MSVC_DIR 
and MSVC_SUFFIX and added values for Visual Studio 10.

Tested OK under windows 7 64 bit and Visual Studio 10 Express Edition.


Summary
---

Copy3rdPartyLibs.cmake need to respond correctly under Visual Studio 10 and 
Visual Studio 10 Express Edition.

 


This addresses bug VWR-24667.
http://jira.secondlife.com/browse/VWR-24667


Diffs (updated)
-

  indra/cmake/Copy3rdPartyLibs.cmake 691e3941d950 

Diff: http://codereview.secondlife.com/r/131/diff


Testing
---

Tested good under windows 7 64 bit and Visual Studio 10 Express Edition.


Thanks,

Nicky

___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Review Request: Added "sort folders by name" option to inventory menu.

[Seth ProductEngine]

---
This is an automatically generated e-mail. To reply, visit:
http://codereview.secondlife.com/r/130/#review285
---


The code looks good but I've uploaded nearly the same patch a day before: 
https://codereview.secondlife.com/r/128/. It is related to STORM-316 and 
includes some other code cleanup needed for that issue. It also adds "sort 
folders by name" option to inventory menu so perhaps we should go for my patch?

- Seth


On Jan. 29, 2011, 1:55 p.m., Kiptic Horsley wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/130/
> ---
> 
> (Updated Jan. 29, 2011, 1:55 p.m.)
> 
> 
> Review request for Viewer.
> 
> 
> Summary
> ---
> 
> The constants SO_FOLDERS_BY_NAME (llinventoryfilter.h line 71) and 
> sort_folders_by_name (llpanelmaininventory.cpp line 125) already existed, so 
> added an option to use them to the inventory menu 
> (menu_inventory_gear_default.xml) and updated llpanelmaininventory.cpp to 
> handle the new option.
> 
> 
> This addresses bug STORM-219.
> http://jira.secondlife.com/browse/STORM-219
> 
> 
> Diffs
> -
> 
>   indra/newview/llpanelmaininventory.cpp fe7fe04ccc9a 
>   indra/newview/skins/default/xui/en/menu_inventory_gear_default.xml 
> fe7fe04ccc9a 
> 
> Diff: http://codereview.secondlife.com/r/130/diff
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Kiptic
> 
>

___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

[opensource-dev] just for onsideration

[Erin Mallory]

Been asked if snowstorm could look at the viewer side of 
https://jira.secondlife.com/browse/VWR-21777 or at least bump it across 
whatever team should be looking at it since this one has been sitting there a 
while and quietly annoying people. 
  ___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

[opensource-dev] Review Request: No nearby people when over approxiamately 1000 meters

[Twisted Laws]

---
This is an automatically generated e-mail. To reply, visit:
http://codereview.secondlife.com/r/132/
---

Review request for Viewer.


Summary
---

This modifies the getAvatars function in llworld to also include any avatars 
that are found within the range from the LLCharactes list as well (the list of 
avatars that is in the viewer object list).  This should make sure that anyone 
that you visually see within range shows up in the list.  Note that changing it 
in this function also affects LLFloaterAvatarPicker::populateNearMe, 
LLLocalSpeakerMgr::updateSpeakerList, as well as the 
LLPanelPeople::updateNearbyList that was originally mentioned in the Jira.  The 
region avatars lists only contain valid position data when the avatars are 
below 1024m.  The comment that mentions about retrieving uuids is based on the 
function, not the current uses.  No current calls in the code are done with the 
avatar_ids argument NULL.  Duplicates in the returned list need to be 
suppressed.


This addresses bug VWR-17050.
http://jira.secondlife.com/browse/VWR-17050


Diffs
-

  indra/newview/llworld.cpp 691e3941d950 

Diff: http://codereview.secondlife.com/r/132/diff


Testing
---

Simple testing in sandboxes of this patch at 20m and 2000m heights with and 
without avatars nearby.  Tested with varying the NearMeRange to insure it does 
not show avatars beyond the range.  Testers need to understand that 
RenderFarClip has an impact on the avatars that are actually in the viewer 
object list, so setting NearMeRange to a great distance at high altitude won't 
necessarily add avatars to the list.  Basically if you can see the avatar and 
its within NearMeRange, the avatar should be in the nearby avatar list in the 
people panel.


Thanks,

Twisted

___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Review Request: Use consistent path for all *.py scripts

[Kent Quirk]

---
This is an automatically generated e-mail. To reply, visit:
http://codereview.secondlife.com/r/129/#review286
---


I would much prefer that we put the /usr/bin/env python form, since env can 
find whichever python is currently set up, including someone that has it in 
/usr/local/bin, or wherever they've chosen. Env is more likely to be found in 
/usr/bin than python is. So I'd like to see this change made the opposite way.

- Kent


On Jan. 28, 2011, 5:56 p.m., Merov Linden wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/129/
> ---
> 
> (Updated Jan. 28, 2011, 5:56 p.m.)
> 
> 
> Review request for Viewer.
> 
> 
> Summary
> ---
> 
> Simple consistency change, using "#!/usr/bin/python" in all python script.
> 
> 
> This addresses bug STORM-937.
> http://jira.secondlife.com/browse/STORM-937
> 
> 
> Diffs
> -
> 
>   indra/copy_win_scripts/start-client.py b542f8134a2b 
>   indra/develop.py b542f8134a2b 
>   indra/lib/python/indra/util/simperf_host_xml_parser.py b542f8134a2b 
>   indra/lib/python/indra/util/simperf_oprof_interface.py b542f8134a2b 
>   indra/lib/python/indra/util/test_win32_manifest.py b542f8134a2b 
>   indra/newview/generate_breakpad_symbols.py b542f8134a2b 
>   scripts/build_version.py b542f8134a2b 
>   scripts/install.py b542f8134a2b 
> 
> Diff: http://codereview.secondlife.com/r/129/diff
> 
> 
> Testing
> ---
> 
> Pulled into a test repo and build successfully on all platforms on TC so I 
> guess no bad surprise here.
> 
> 
> Thanks,
> 
> 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

Re: [opensource-dev] Review Request: Use consistent path for all *.py scripts

[Vadim ProductEngine]

> On Jan. 31, 2011, 11:47 a.m., Kent Quirk wrote:
> > I would much prefer that we put the /usr/bin/env python form, since env can 
> > find whichever python is currently set up, including someone that has it in 
> > /usr/local/bin, or wherever they've chosen. Env is more likely to be found 
> > in /usr/bin than python is. So I'd like to see this change made the 
> > opposite way.

+1


- Vadim


---
This is an automatically generated e-mail. To reply, visit:
http://codereview.secondlife.com/r/129/#review286
---


On Jan. 28, 2011, 5:56 p.m., Merov Linden wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/129/
> ---
> 
> (Updated Jan. 28, 2011, 5:56 p.m.)
> 
> 
> Review request for Viewer.
> 
> 
> Summary
> ---
> 
> Simple consistency change, using "#!/usr/bin/python" in all python script.
> 
> 
> This addresses bug STORM-937.
> http://jira.secondlife.com/browse/STORM-937
> 
> 
> Diffs
> -
> 
>   indra/copy_win_scripts/start-client.py b542f8134a2b 
>   indra/develop.py b542f8134a2b 
>   indra/lib/python/indra/util/simperf_host_xml_parser.py b542f8134a2b 
>   indra/lib/python/indra/util/simperf_oprof_interface.py b542f8134a2b 
>   indra/lib/python/indra/util/test_win32_manifest.py b542f8134a2b 
>   indra/newview/generate_breakpad_symbols.py b542f8134a2b 
>   scripts/build_version.py b542f8134a2b 
>   scripts/install.py b542f8134a2b 
> 
> Diff: http://codereview.secondlife.com/r/129/diff
> 
> 
> Testing
> ---
> 
> Pulled into a test repo and build successfully on all platforms on TC so I 
> guess no bad surprise here.
> 
> 
> Thanks,
> 
> 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

Re: [opensource-dev] C++ Need help to resolve stdint.h typedef conflicts between Quicktime and VS2010

[Kent Quirk (Q Linden)]

Looks like there are two versions of stdint.h accessible in your build -- one 
in GNUCompatibility, and one in VC.

I'm not sure why you're finding different ones in different order, but you want 
to make sure that you're using the same library search path everywhere. If your 
library search path includes . or .. you may need to put them late in the path 
so that some local version doesn't override the system version.

   Q

On Jan 30, 2011, at 8:38 AM, Nicky Perian wrote:

>  media_plugin_quicktime.cpp
> C:\Program Files (x86)\QuickTime SDK\CIncludes\GNUCompatibility/stdint.h(49): 
> error C2371: 'int_fast16_t' : redefinition; different basic types
>   C:\Program Files (x86)\Microsoft Visual Studio 
> 10.0\VC\include\stdint.h(34) : see declaration of 'int_fast16_t'
> 
> there are more errors like these but the same header just different int's
> 
> I have tried #include  and #undef and that doesn't help.
> 
> Need help as my C++ knowledge sucks.
> 
> But, I m trying to improve.
> 
> Nicky
> 
> 
> ___
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/OpenSource-Dev
> Please read the policies before posting to keep unmoderated posting privileges

___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Review Request: VWR-24610 Provide define LL_MSVC10 to customize Visual Studio 10 code submissions.

[Merov Linden]

---
This is an automatically generated e-mail. To reply, visit:
http://codereview.secondlife.com/r/121/#review288
---



indra/llcommon/llpreprocessor.h


If we want to pick up 1600, we should just say "== 1600". If we are wary of 
unknown intermediate VS builds and so want to use inequalities, we should not 
write the test in such a way that VS9 releases will be identified as VS10 (an 
hypothetical 15xx). So, I suggest to spell out the whole thing:
#if (_MSC_VER < 1400)
#define LL_MSVC7 // Visual C++ 2003 or earlier
#elif (_MSC_VER < 1500)
#define LL_MSVC8
#elif (_MSC_VER < 1600)
#define LL_MSVC9
#else
#define LL_MSVC10
#endif

Note that, that way, your MSVC10 code will not suddenly stop to compile in 
future versions of MSVC (which is likely to stay backward compatible woth 
MSVC10).


- Merov


On Jan. 25, 2011, 11:13 a.m., Nicky Perian wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/121/
> ---
> 
> (Updated Jan. 25, 2011, 11:13 a.m.)
> 
> 
> Review request for Viewer.
> 
> 
> Summary
> ---
> 
> Need additional eyes on this. My first RB.
> 
> 
> This addresses bug VWR-24610.
> http://jira.secondlife.com/browse/VWR-24610
> 
> 
> Diffs
> -
> 
>   indra/llcommon/llpreprocessor.h 26c09ad4293e 
> 
> Diff: http://codereview.secondlife.com/r/121/diff
> 
> 
> Testing
> ---
> 
> Compiled with VS2010. Used with another patch around a microsoft bug. Have 
> not used with VS 2005
> 
> 
> Thanks,
> 
> Nicky
> 
>

___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Review Request: Use consistent path for all *.py scripts

[Balp Allen]

> On Jan. 31, 2011, 6:27 a.m., Vadim ProductEngine wrote:
> > Why didn't you choose "!/usr/bin/env python"? It seems more flexible.

!/usr/bin/env python, is the standard python way, and i think is what should 
always be used on python scripts.


- Balp


---
This is an automatically generated e-mail. To reply, visit:
http://codereview.secondlife.com/r/129/#review284
---


On Jan. 28, 2011, 5:56 p.m., Merov Linden wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/129/
> ---
> 
> (Updated Jan. 28, 2011, 5:56 p.m.)
> 
> 
> Review request for Viewer.
> 
> 
> Summary
> ---
> 
> Simple consistency change, using "#!/usr/bin/python" in all python script.
> 
> 
> This addresses bug STORM-937.
> http://jira.secondlife.com/browse/STORM-937
> 
> 
> Diffs
> -
> 
>   indra/copy_win_scripts/start-client.py b542f8134a2b 
>   indra/develop.py b542f8134a2b 
>   indra/lib/python/indra/util/simperf_host_xml_parser.py b542f8134a2b 
>   indra/lib/python/indra/util/simperf_oprof_interface.py b542f8134a2b 
>   indra/lib/python/indra/util/test_win32_manifest.py b542f8134a2b 
>   indra/newview/generate_breakpad_symbols.py b542f8134a2b 
>   scripts/build_version.py b542f8134a2b 
>   scripts/install.py b542f8134a2b 
> 
> Diff: http://codereview.secondlife.com/r/129/diff
> 
> 
> Testing
> ---
> 
> Pulled into a test repo and build successfully on all platforms on TC so I 
> guess no bad surprise here.
> 
> 
> Thanks,
> 
> 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

Re: [opensource-dev] Using 'autobuild' to build the viewer

[Jonathan Welch]

In autobuild\autobuild_tool_source_environment.py there is one
reference to "devenv" and two references to "devenv.com".

This should be
1) Made consistent
2) Make sure there is not a devenv.exe -- just what is supposed to be
run?  I cannot check for myself, but one person told me there were
both .exe and .com present.
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Review Request: VWR-24612 lscript_compile warnings treated as errors -- workaround

[Merov Linden]

---
This is an automatically generated e-mail. To reply, visit:
http://codereview.secondlife.com/r/122/#review290
---

Ship it!


Sounds good to me now with Boroondas suggestion taken into account in the 
second diff.

- Merov


On Jan. 25, 2011, 3:09 p.m., Nicky Perian wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/122/
> ---
> 
> (Updated Jan. 25, 2011, 3:09 p.m.)
> 
> 
> Review request for Viewer.
> 
> 
> Summary
> ---
> 
> Correct marco redefinition warnings introduced in Visual Studio 10. Patch 
> applies workaround documented at:
> http://connect.microsoft.com/VisualStudio/feedback/details/621653/including-stdint-after-intsafe-generates-warnings
> 
> Depends on vwr-24610 which should be applied first.
> 
> 
> This addresses bug vwr-24612.
> http://jira.secondlife.com/browse/vwr-24612
> 
> 
> Diffs
> -
> 
>   indra/llcommon/llpreprocessor.h 26c09ad4293e 
> 
> Diff: http://codereview.secondlife.com/r/122/diff
> 
> 
> Testing
> ---
> 
> Before (snip)
> 1>C:\Program Files (x86)\Microsoft Visual Studio 
> 10.0\VC\include\stdint.h(81): warning C4005: 'UINT32_MAX' : macro redefinition
> 1>  indra.l.cpp(85) : see previous definition of 'UINT32_MAX'
> == Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==
> After patch applied:
> 1>-- Build started: Project: lscript_compile, Configuration: Release 
> Win32 --
> 1>  lscript_bytecode.cpp
> 1>  lscript_error.cpp
> 1>  lscript_resource.cpp
> 1>  lscript_scope.cpp
> 1>  lscript_tree.cpp
> 1>  lscript_typecheck.cpp
> 1>  indra.y.cpp
> 1>  indra.l.cpp
> 1>  lscript_compile.vcxproj -> 
> C:\lindenhg\vcexpress2010build\indra\build-vc100\lscript\lscript_compile\Release\lscript_compile.lib
> == Build: 1 succeeded, 0 failed, 0 up-to-date, 0 skipped ==
> 
> 
> Thanks,
> 
> Nicky
> 
>

___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

[opensource-dev] devenv.com (was Re: Using 'autobuild' to build the viewer)

[Brad Kittenbrink (Brad Linden)]

On Mon, Jan 31, 2011 at 1:31 PM, Jonathan Welch  wrote:

> In autobuild\autobuild_tool_source_environment.py there is one
> reference to "devenv" and two references to "devenv.com".
>
> This should be
> 1) Made consistent
> 2) Make sure there is not a devenv.exe -- just what is supposed to be
> run?  I cannot check for myself, but one person told me there were
> both .exe and .com present.
>
>
Both devenv.exe and devenv.com are supposed to be present in a standard
visual studio installation.  As I understand things, devenv.com is intended
to be the command line wrapper for devenv.exe.  On some systems, devenv.exe
behaves poorly if run directly from the command line (I've never repro'd
these problems myself, so unfortunately I don't have further details).
Originally we just used devenv by itself, but there were problems, and we
fixed the bug by switching to use devenv.com explicitly.  We seem to have
not caught all the occurrences however.

Anyways, that's the logic behind why things are the way they are.

We'll probably also need to add cases to handle whatever naming conventions
VCExpress has as well (if they're different).

-Brad
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] devenv.com (was Re: Using 'autobuild' to build the viewer)

[Jonathan Welch]

I am waiting for an updated version of autobuild, one that knows how
to handle Express.

The only compiler program that looks promising in that installation
directory is called VCExpress.exe

>probably also need to add cases to handle whatever >naming conventions
> VCExpress has as well (if they're different).
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] devenv.com (was Re: Using 'autobuild' to build the viewer)

[Nicky Perian]

I looked at this some and I think it needs to be MSbuild.exe the command line 
builder for VS 2010 Express. I think it is available to use for all versions 
but, I need to confirm.




From: Jonathan Welch 
To: Brad Kittenbrink (Brad Linden) 
Cc: OpenSource Mailing List 
Sent: Mon, January 31, 2011 4:03:02 PM
Subject: Re: [opensource-dev] devenv.com (was Re: Using 'autobuild' to build 
the 
viewer)

I am waiting for an updated version of autobuild, one that knows how
to handle Express.

The only compiler program that looks promising in that installation
directory is called VCExpress.exe

>probably also need to add cases to handle whatever >naming conventions
> VCExpress has as well (if they're different).
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges



  ___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] devenv.com (was Re: Using 'autobuild' to build the viewer)

[Jonathan Welch]

There is no msbuild.exe for VS 2005 Express (yes, a moot point soon).

On Mon, Jan 31, 2011 at 5:07 PM, Nicky Perian  wrote:
> I looked at this some and I think it needs to be MSbuild.exe the command
> line builder for VS 2010 Express. I think it is available to use for all
> versions but, I need to confirm.
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Review Request: Added "sort folders by name" option to inventory menu.

[Kiptic ‌]

Hmm mine added that menu option too :) But if yours fixes STORM-219 and another 
one too please use yours of course. Just make sure STORM-219 is closed :)
 
/Kip
 


Subject: Re: Review Request: Added "sort folders by name" option to inventory 
menu.
From: slitovc...@productengine.com
To: kip...@hotmail.com; slitovc...@productengine.com; 
opensource-dev@lists.secondlife.com
Date: Mon, 31 Jan 2011 15:43:16 +






This is an automatically generated e-mail. To reply, visit: 
http://codereview.secondlife.com/r/130/ 
The code looks good but I've uploaded nearly the same patch a day before: 
https://codereview.secondlife.com/r/128/. It is related to STORM-316 and 
includes some other code cleanup needed for that issue. It also adds "sort 
folders by name" option to inventory menu so perhaps we should go for my patch?

- Seth

On January 29th, 2011, 1:55 p.m., Kiptic Horsley wrote:




Review request for Viewer.
By Kiptic Horsley.
Updated Jan. 29, 2011, 1:55 p.m.
Description 



The constants SO_FOLDERS_BY_NAME (llinventoryfilter.h line 71) and 
sort_folders_by_name (llpanelmaininventory.cpp line 125) already existed, so 
added an option to use them to the inventory menu 
(menu_inventory_gear_default.xml) and updated llpanelmaininventory.cpp to 
handle the new option.

Bugs: STORM-219 
Diffs 

indra/newview/llpanelmaininventory.cpp (fe7fe04ccc9a)
indra/newview/skins/default/xui/en/menu_inventory_gear_default.xml 
(fe7fe04ccc9a)
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

Re: [opensource-dev] Review Request: STORM-465 Missing Strings from strings.xml

[Merov Linden]

---
This is an automatically generated e-mail. To reply, visit:
http://codereview.secondlife.com/r/108/#review291
---

Ship it!


Good I think. I'm assuming that localization hasn't left those outside 
strings.xml for a reason (like: make sure no one ever tries to translate them).

- Merov


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
> 
>

___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] devenv.com (was Re: Using 'autobuild' to build the viewer)

[Nicky Perian]

Your are right it isn't per se in VC Express 2005 but it is in .NET Framework 
on 
my machine but I have both Express and Pro.
Setting environment for using Microsoft Visual Studio 2005 x86 tools.

C:\VC80\VC>msbuild
Microsoft (R) Build Engine Version 2.0.50727.4927
[Microsoft .NET Framework, Version 2.0.50727.4952]
Copyright (C) Microsoft Corporation 2005. All rights reserved.

MSBUILD : error MSB1003: Specify a project or solution file. The current working
 directory does not contain a project or solution file.

C:\VC80\VC>msbuild /version
Microsoft (R) Build Engine Version 2.0.50727.4927
[Microsoft .NET Framework, Version 2.0.50727.4952]
Copyright (C) Microsoft Corporation 2005. All rights reserved.

2.0.50727.4927
C:\VC80\VC>c:\cygwin\bin\which msbuild.exe
/cygdrive/c/Windows/Microsoft.NET/Framework/v2.0.50727/msbuild.exe

C:\VC80\VC>
Setting environment for using Microsoft Visual Studio 2010 x86 tools.

c:\program files (x86)\microsoft visual studio 10.0\vc\bin>c:\cygwin\bin\which
sbuild.exe
/cygdrive/c/Windows/Microsoft.NET/Framework/v4.0.30319/msbuild.exe

c:\program files (x86)\microsoft visual studio 10.0\vc\bin>msbuild /version
Microsoft (R) Build Engine Version 4.0.30319.1
[Microsoft .NET Framework, Version 4.0.30319.1]
Copyright (C) Microsoft Corporation 2007. All rights reserved.

4.0.30319.1
c:\program files (x86)\microsoft visual studio 10.0\vc\bin>







From: Jonathan Welch 
To: Nicky Perian 
Cc: Brad Kittenbrink (Brad Linden) ; OpenSource Mailing 
List 

Sent: Mon, January 31, 2011 4:34:34 PM
Subject: Re: [opensource-dev] devenv.com (was Re: Using 'autobuild' to build 
the 
viewer)

There is no msbuild.exe for VS 2005 Express (yes, a moot point soon).

On Mon, Jan 31, 2011 at 5:07 PM, Nicky Perian  wrote:
> I looked at this some and I think it needs to be MSbuild.exe the command
> line builder for VS 2010 Express. I think it is available to use for all
> versions but, I need to confirm.



  ___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Review Request: Constraints in XUI files don't match the constraints imposed elsewhere in the viewer/server code.

[Merov Linden]

---
This is an automatically generated e-mail. To reply, visit:
http://codereview.secondlife.com/r/57/#review292
---

Ship it!


- Merov


On Jan. 27, 2011, 6:55 a.m., SignpostMarv Martin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/57/
> ---
> 
> (Updated Jan. 27, 2011, 6:55 a.m.)
> 
> 
> Review request for Viewer and Kent Quirk.
> 
> 
> Summary
> ---
> 
> Constraints in XUI files don't match the constraints imposed elsewhere in the 
> viewer/server code.
> 
> Don't know where the constraints are specified, but this XUI mod lets the 
> user play within the full range of the actual constraints.
> 
> JIRA page has screenshots of before & after.
> 
> 
> This addresses bug VWR-24197.
> http://jira.secondlife.com/browse/VWR-24197
> 
> 
> Diffs
> -
> 
>   indra/newview/skins/default/xui/en/floater_tools.xml UNKNOWN 
> 
> Diff: http://codereview.secondlife.com/r/57/diff
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> SignpostMarv
> 
>

___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Review Request: VWR-17050 No nearby people when over approxiamately 1000 meters

[Twisted Laws]

---
This is an automatically generated e-mail. To reply, visit:
http://codereview.secondlife.com/r/132/
---

(Updated Jan. 31, 2011, 3:34 p.m.)


Review request for Viewer.


Changes
---

fixed the title


Summary (updated)
---

This modifies the getAvatars function in llworld to also include any avatars 
that are found within the range from the LLCharactes list as well (the list of 
avatars that is in the viewer object list).  This should make sure that anyone 
that you visually see within range shows up in the list.  Note that changing it 
in this function also affects LLFloaterAvatarPicker::populateNearMe, 
LLLocalSpeakerMgr::updateSpeakerList, as well as the 
LLPanelPeople::updateNearbyList that was originally mentioned in the Jira.  The 
region avatars lists only contain valid position data when the avatars are 
below 1024m.  The comment that mentions about retrieving uuids is based on the 
function, not the current uses.  No current calls in the code are done with the 
avatar_ids argument NULL.  Duplicates in the returned list need to be 
suppressed.


This addresses bug VWR-17050.
http://jira.secondlife.com/browse/VWR-17050


Diffs
-

  indra/newview/llworld.cpp 691e3941d950 

Diff: http://codereview.secondlife.com/r/132/diff


Testing
---

Simple testing in sandboxes of this patch at 20m and 2000m heights with and 
without avatars nearby.  Tested with varying the NearMeRange to insure it does 
not show avatars beyond the range.  Testers need to understand that 
RenderFarClip has an impact on the avatars that are actually in the viewer 
object list, so setting NearMeRange to a great distance at high altitude won't 
necessarily add avatars to the list.  Basically if you can see the avatar and 
its within NearMeRange, the avatar should be in the nearby avatar list in the 
people panel.


Thanks,

Twisted

___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Review Request: (STORM-379) Content permissions aren't refreshed in the "Buy copy of" floater

[Merov Linden]

---
This is an automatically generated e-mail. To reply, visit:
http://codereview.secondlife.com/r/126/#review293
---

Ship it!


Seems good.

- Merov


On Jan. 27, 2011, 4:05 p.m., Seth ProductEngine wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/126/
> ---
> 
> (Updated Jan. 27, 2011, 4:05 p.m.)
> 
> 
> Review request for Viewer.
> 
> 
> Summary
> ---
> 
> Changed displaying the permissions of inventory items inside an object to 
> show the permissions which will be granted to the next owner of the item.
> 
> The permissions affected by this issue can be seen in Content tab of Tools 
> floater which is open by selecting Edit in object's context menu. If agent 
> can't perform certain actions on the item a respective suffix will be added 
> to the item's name e.g. (no copy), (no modify) or(no transfer).
> 
> This issue affects viewer 1.23 too. Could it be expected behavior?
> 
> 
> This addresses bug STORM-379.
> http://jira.secondlife.com/browse/STORM-379
> 
> 
> Diffs
> -
> 
>   indra/newview/llpanelobjectinventory.cpp b542f8134a2b 
> 
> Diff: http://codereview.secondlife.com/r/126/diff
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Seth
> 
>

___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Review Request: STORM-610 Changes to Environment Editor: water color change is not saved

[Merov Linden]

---
This is an automatically generated e-mail. To reply, visit:
http://codereview.secondlife.com/r/125/#review294
---

Ship it!


Looks good.

- Merov


On Jan. 27, 2011, 1:20 p.m., Vadim ProductEngine wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/125/
> ---
> 
> (Updated Jan. 27, 2011, 1:20 p.m.)
> 
> 
> Review request for Viewer and Seth ProductEngine.
> 
> 
> Summary
> ---
> 
> Now when you change water color or density, the changes are saved until you 
> switch to another water preset.
> 
> 
> This addresses bug STORM-610.
> http://jira.secondlife.com/browse/STORM-610
> 
> 
> Diffs
> -
> 
>   indra/newview/app_settings/settings.xml b542f8134a2b 
>   indra/newview/llwaterparammanager.h b542f8134a2b 
>   indra/newview/llwaterparammanager.cpp b542f8134a2b 
> 
> Diff: http://codereview.secondlife.com/r/125/diff
> 
> 
> Testing
> ---
> 
> Played with presets and sliders. The new behavior seems fine to me, although 
> it may be confusing that basic water settings are persistent, while sky 
> settings aren't.
> 
> While working on this bug I've almost (~80%) implemented STORM-326 
> (Persistent water/sky settings), so if anyone is interested I'd be happy to 
> complete that work.
> 
> 
> Thanks,
> 
> Vadim
> 
>

___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Very Strange occurrence...

[Philippe (Merov) Bossut]

We should really take STORM-949 in the next sprint.
There are only 4 strings to change in 3 xml files to get that straighten
out.

Cheers,
- Merov

On Sat, Jan 29, 2011 at 9:50 AM, Opensource Obscure <
opensourceobsc...@gmail.com> wrote:

> Happened again a few hours ago with the same username (Grumpity),
> unfortunately I couldn't take note of which viewer build I was using.
>
> Photo: http://www.plurk.com/p/afagjx
>
> In a comment to that photo, another user reports noobs sending
> Abuse Report against Grumpity, and again this happened yesterday.
>
> On Thu, Jan 6, 2011 at 15:36, Carlo Wood  wrote:
> > On Wed, Jan 05, 2011 at 04:44:31PM -0500, Kent Quirk (Q Linden) wrote:
> >> So the reason that semi-plausible strings are used for these things is
> that they're the only strings available when we use the test floater feature
> from the login screen.
> >>
> >> But we should probably try not to use real names.
> >>
> >> And yes, Jonathan, these should mostly never be visible. But sometimes
> things happen.
> >
> > Nevertheless, it is a bug; if whatever failed is outside the influence of
> > the viewer itself, then still it should not have shown this. The viewer
> > should be fixed to show the account name, or at least the UUID, in
> > this -hopefully- rare case.
> >
> > --
> > Carlo Wood 
> > ___
> > Policies and (un)subscribe information available here:
> > http://wiki.secondlife.com/wiki/OpenSource-Dev
> > Please read the policies before posting to keep unmoderated posting
> privileges
> >
>
>
>
> --
> Opensource Obscure
> http://twitter.com/oobscure - http://opensourceobscure.com/lol
> ___
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/OpenSource-Dev
> Please read the policies before posting to keep unmoderated posting
> privileges
>
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] "Nearby" people tab

[Dave Booth]

On 1/31/2011 07:52, Oz Linden (Scott Lawrence) wrote:
> On 2011-01-30 7:47, Hitomi Tiponi wrote:
>> I have been having this trouble on some sims for the last few days 
>> (using 2.5.1 Beta 2 and later).  I have been trying to figure out the 
>> cause or something that may tie in the various sims it seems to 
>> happen on - but so far without luck.  On other sims this works as 
>> expected.
>> And yes - this happens on sims at ground level as well.
>>
>> ---
>>
>> >Date: Sat, 29 Jan 2011 17:50:23 -0600
>> >From: Dave Booth > >
>> >Subject: [opensource-dev] "Nearby" people tab
>> >To: OpenSource Mailing List > >
>> >Message-ID: <4d44a7bf.9090...@meadowlakearts.com 
>> >
>> >Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>> >
>> >Whats the expected behavior of this tab of the people sidebar? I'm
>> >currently sitting in a room with 14 other folks, half of whom are on my
>> >flist and all within chat range - but this tab tells me "no one 
>> nearby".
>> >Currently on Second Life 2.6.0 (21) Jan 29 2011 12:57:40 (Second
>> >Life Development) but to be honest I dont think I've EVER seen that tab
>> >populated, no matter what build or how crowded the venue.
>
> It would be interesting to see what was in the log file for the period 
> of time that the window was not properly filled in.

I intend to capture some more specific data in the next few days - will 
involve laying out precisely positioned prims in 3 dimensions for an av 
to sit on and probing what "NearMeRange" distances they appear and 
disappear from the nearby tab to an alt sat on the zero-ref prim. If 
properly designed, that study will establish any issues with height AGL, 
"flat" (2d) vector magnitude and "true" (3d) vector magnitude. Will 
include logfile capture and will advise.

Dave.
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Review Request: (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

[Merov Linden]

---
This is an automatically generated e-mail. To reply, visit:
http://codereview.secondlife.com/r/128/#review295
---

Ship it!


Seems good.

- Merov


On Jan. 28, 2011, 11:37 a.m., Seth ProductEngine wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/128/
> ---
> 
> (Updated Jan. 28, 2011, 11:37 a.m.)
> 
> 
> Review request for Viewer and Vadim ProductEngine.
> 
> 
> Summary
> ---
> 
> - Added "Sort Folders Always by Name" setting.
> - Removed unused settings Inventory.Folders by Name/Sort by Date/Sort by 
> Name/System Folders to Top.
> 
> 
> This addresses bug STORM-316.
> http://jira.secondlife.com/browse/STORM-316
> 
> 
> Diffs
> -
> 
>   indra/newview/llpanelmaininventory.cpp b542f8134a2b 
>   indra/newview/skins/default/xui/en/menu_inventory_gear_default.xml 
> b542f8134a2b 
> 
> Diff: http://codereview.secondlife.com/r/128/diff
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Seth
> 
>

___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Review Request: VWR-24667; Copy3rdPartyLibs.cmake needs to account for Visual Studio 10 and Visual Studio 10 Express.

[Merov Linden]

---
This is an automatically generated e-mail. To reply, visit:
http://codereview.secondlife.com/r/131/#review296
---

Ship it!


Good factorization job. Thanks for doing this. I have not tried the patch 
though and recommend MM to do a full TC cycle before merging in 
viewer-development.

- Merov


On Jan. 31, 2011, 7:34 a.m., Nicky Perian wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/131/
> ---
> 
> (Updated Jan. 31, 2011, 7:34 a.m.)
> 
> 
> Review request for Viewer.
> 
> 
> Summary
> ---
> 
> Copy3rdPartyLibs.cmake need to respond correctly under Visual Studio 10 and 
> Visual Studio 10 Express Edition.
> 
>  
> 
> 
> This addresses bug VWR-24667.
> http://jira.secondlife.com/browse/VWR-24667
> 
> 
> Diffs
> -
> 
>   indra/cmake/Copy3rdPartyLibs.cmake 691e3941d950 
> 
> Diff: http://codereview.secondlife.com/r/131/diff
> 
> 
> Testing
> ---
> 
> Tested good under windows 7 64 bit and Visual Studio 10 Express Edition.
> 
> 
> Thanks,
> 
> Nicky
> 
>

___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Very Strange occurrence...

[Anya Kanevsky]

I made the executive decision to do that along with creating the issue :)

2011/1/31 Philippe (Merov) Bossut 

> We should really take STORM-949 in the next sprint.
> There are only 4 strings to change in 3 xml files to get that straighten
> out.
>
> Cheers,
> - Merov
>
>
> On Sat, Jan 29, 2011 at 9:50 AM, Opensource Obscure <
> opensourceobsc...@gmail.com> wrote:
>
>> Happened again a few hours ago with the same username (Grumpity),
>> unfortunately I couldn't take note of which viewer build I was using.
>>
>> Photo: http://www.plurk.com/p/afagjx
>>
>> In a comment to that photo, another user reports noobs sending
>> Abuse Report against Grumpity, and again this happened yesterday.
>>
>> On Thu, Jan 6, 2011 at 15:36, Carlo Wood  wrote:
>> > On Wed, Jan 05, 2011 at 04:44:31PM -0500, Kent Quirk (Q Linden) wrote:
>> >> So the reason that semi-plausible strings are used for these things is
>> that they're the only strings available when we use the test floater feature
>> from the login screen.
>> >>
>> >> But we should probably try not to use real names.
>> >>
>> >> And yes, Jonathan, these should mostly never be visible. But sometimes
>> things happen.
>> >
>> > Nevertheless, it is a bug; if whatever failed is outside the influence
>> of
>> > the viewer itself, then still it should not have shown this. The viewer
>> > should be fixed to show the account name, or at least the UUID, in
>> > this -hopefully- rare case.
>> >
>> > --
>> > Carlo Wood 
>> > ___
>> > Policies and (un)subscribe information available here:
>> > http://wiki.secondlife.com/wiki/OpenSource-Dev
>> > Please read the policies before posting to keep unmoderated posting
>> privileges
>> >
>>
>>
>>
>> --
>> Opensource Obscure
>> http://twitter.com/oobscure - http://opensourceobscure.com/lol
>> ___
>> Policies and (un)subscribe information available here:
>> http://wiki.secondlife.com/wiki/OpenSource-Dev
>> Please read the policies before posting to keep unmoderated posting
>> privileges
>>
>
>
> ___
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/OpenSource-Dev
> Please read the policies before posting to keep unmoderated posting
> privileges
>
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Review Request: VWR-24610 Provide define LL_MSVC10 to customize Visual Studio 10 code submissions.

[Nicky Perian]

---
This is an automatically generated e-mail. To reply, visit:
http://codereview.secondlife.com/r/121/
---

(Updated Jan. 31, 2011, 5:35 p.m.)


Review request for Viewer.


Changes
---

Adds LL_MSVC9 for code related to Visual Studio 2008. Provides for 
identification of all known Visual Studio versions.


Summary
---

Need additional eyes on this. My first RB.


This addresses bug VWR-24610.
http://jira.secondlife.com/browse/VWR-24610


Diffs (updated)
-

  indra/llcommon/llpreprocessor.h 26c09ad4293e 

Diff: http://codereview.secondlife.com/r/121/diff


Testing
---

Compiled with VS2010. Used with another patch around a microsoft bug. Have not 
used with VS 2005


Thanks,

Nicky

___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Review Request: VWR-17050 No nearby people when over approxiamately 1000 meters

[Merov Linden]

---
This is an automatically generated e-mail. To reply, visit:
http://codereview.secondlife.com/r/132/#review297
---


It seems to me that the new code can completely replace the old one, i.e. the 
search based on the map is not adding anything different or is it?


indra/newview/llworld.cpp


I fail to see how the "1000m" condition is tested in this code. Same for 
the "only do this when we are retrieving uuid's". 


- Merov


On Jan. 31, 2011, 3:34 p.m., Twisted Laws wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/132/
> ---
> 
> (Updated Jan. 31, 2011, 3:34 p.m.)
> 
> 
> Review request for Viewer.
> 
> 
> Summary
> ---
> 
> This modifies the getAvatars function in llworld to also include any avatars 
> that are found within the range from the LLCharactes list as well (the list 
> of avatars that is in the viewer object list).  This should make sure that 
> anyone that you visually see within range shows up in the list.  Note that 
> changing it in this function also affects 
> LLFloaterAvatarPicker::populateNearMe, LLLocalSpeakerMgr::updateSpeakerList, 
> as well as the LLPanelPeople::updateNearbyList that was originally mentioned 
> in the Jira.  The region avatars lists only contain valid position data when 
> the avatars are below 1024m.  The comment that mentions about retrieving 
> uuids is based on the function, not the current uses.  No current calls in 
> the code are done with the avatar_ids argument NULL.  Duplicates in the 
> returned list need to be suppressed.
> 
> 
> This addresses bug VWR-17050.
> http://jira.secondlife.com/browse/VWR-17050
> 
> 
> Diffs
> -
> 
>   indra/newview/llworld.cpp 691e3941d950 
> 
> Diff: http://codereview.secondlife.com/r/132/diff
> 
> 
> Testing
> ---
> 
> Simple testing in sandboxes of this patch at 20m and 2000m heights with and 
> without avatars nearby.  Tested with varying the NearMeRange to insure it 
> does not show avatars beyond the range.  Testers need to understand that 
> RenderFarClip has an impact on the avatars that are actually in the viewer 
> object list, so setting NearMeRange to a great distance at high altitude 
> won't necessarily add avatars to the list.  Basically if you can see the 
> avatar and its within NearMeRange, the avatar should be in the nearby avatar 
> list in the people panel.
> 
> 
> Thanks,
> 
> Twisted
> 
>

___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Review Request: VWR-24610 Provide define LL_MSVC10 to customize Visual Studio 10 code submissions.

[Merov Linden]

---
This is an automatically generated e-mail. To reply, visit:
http://codereview.secondlife.com/r/121/#review298
---

Ship it!


Good to go I think. Need to cycle on TC before merge though :)

- Merov


On Jan. 31, 2011, 5:35 p.m., Nicky Perian wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/121/
> ---
> 
> (Updated Jan. 31, 2011, 5:35 p.m.)
> 
> 
> Review request for Viewer.
> 
> 
> Summary
> ---
> 
> Need additional eyes on this. My first RB.
> 
> 
> This addresses bug VWR-24610.
> http://jira.secondlife.com/browse/VWR-24610
> 
> 
> Diffs
> -
> 
>   indra/llcommon/llpreprocessor.h 26c09ad4293e 
> 
> Diff: http://codereview.secondlife.com/r/121/diff
> 
> 
> Testing
> ---
> 
> Compiled with VS2010. Used with another patch around a microsoft bug. Have 
> not used with VS 2005
> 
> 
> Thanks,
> 
> Nicky
> 
>

___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Review Request: Use consistent path for all *.py scripts

[Merov Linden]

> On Jan. 31, 2011, 11:47 a.m., Kent Quirk wrote:
> > I would much prefer that we put the /usr/bin/env python form, since env can 
> > find whichever python is currently set up, including someone that has it in 
> > /usr/local/bin, or wherever they've chosen. Env is more likely to be found 
> > in /usr/bin than python is. So I'd like to see this change made the 
> > opposite way.
> 
> Vadim ProductEngine wrote:
> +1

I'm all for it since everybody seems to agree on this syntax (which is less 
error prone for 3rd party devs, I agree). Still, as mentioned by Brad in the 
JIRA, we should revise and dust off the wiki: 
http://wiki.secondlife.com/wiki/Coding_standard#Python_File_Names. In 
particular, I don't think we want .pyo or .pyc files around anymore (all the 
.py files in lindenlab/viewer-development are open source).


- Merov


---
This is an automatically generated e-mail. To reply, visit:
http://codereview.secondlife.com/r/129/#review286
---


On Jan. 28, 2011, 5:56 p.m., Merov Linden wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/129/
> ---
> 
> (Updated Jan. 28, 2011, 5:56 p.m.)
> 
> 
> Review request for Viewer.
> 
> 
> Summary
> ---
> 
> Simple consistency change, using "#!/usr/bin/python" in all python script.
> 
> 
> This addresses bug STORM-937.
> http://jira.secondlife.com/browse/STORM-937
> 
> 
> Diffs
> -
> 
>   indra/copy_win_scripts/start-client.py b542f8134a2b 
>   indra/develop.py b542f8134a2b 
>   indra/lib/python/indra/util/simperf_host_xml_parser.py b542f8134a2b 
>   indra/lib/python/indra/util/simperf_oprof_interface.py b542f8134a2b 
>   indra/lib/python/indra/util/test_win32_manifest.py b542f8134a2b 
>   indra/newview/generate_breakpad_symbols.py b542f8134a2b 
>   scripts/build_version.py b542f8134a2b 
>   scripts/install.py b542f8134a2b 
> 
> Diff: http://codereview.secondlife.com/r/129/diff
> 
> 
> Testing
> ---
> 
> Pulled into a test repo and build successfully on all platforms on TC so I 
> guess no bad surprise here.
> 
> 
> Thanks,
> 
> 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

[opensource-dev] problems working with autobuild

[Twisted Laws]

So I figured I'd give the autobuild method of building a try.   I've not made 
it far yet 
and wondering if someone might give me a pointer on what I've done wrong...
 
I read: http://wiki.secondlife.com/wiki/Autobuild_Quick_Start
and read: 
https://lists.secondlife.com/pipermail/opensource-dev/2011-January/005633.html
v-autobuild is from: https://bitbucket.org/mani_linden/viewer-autobuild
 
I must be missing something here but I'm not sure what.  The autobuild/bin 
directory is 
in the path.   Python 2.6 installed.
 
Thanks for any hints,  session log follows  (note that the ./setup.py install 
fails, and i have
to use python setup.py install)
 
dir: /cygdrive/c/dev/hgbuilds
$ cd autobuild
dir: /cygdrive/c/dev/hgbuilds/autobuild
$ ls
autobuild  bin  build  setup.py
dir: /cygdrive/c/dev/hgbuilds/autobuild
$ ./setup.py install
./setup.py: line 23: from: command not found
./setup.py: line 27: PACKAGE_NAME: command not found
./setup.py: line 28: LLAUTOBUILD_VERSION: command not found
./setup.py: line 29: LLAUTOBUILD_SOURCE: command not found
./setup.py: line 30: CLASSIFIERS: command not found
./setup.py: line 41: ext_modules: command not found
./setup.py: line 43: syntax error near unexpected token `newline'
./setup.py: line 43: `setup('
dir: /cygdrive/c/dev/hgbuilds/autobuild
$ python setup.py install
running install
running build
running build_py
running build_scripts
running install_lib
running install_scripts
running install_egg_info
Removing C:\Python26\Lib\site-packages\autobuild-0.0.0-py2.6.egg-info
Writing C:\Python26\Lib\site-packages\autobuild-0.0.0-py2.6.egg-info
dir: /cygdrive/c/dev/hgbuilds/autobuild
$ cd ../v-autobuild
dir: /cygdrive/c/dev/hgbuilds/v-autobuild
$ autobuild configure -c OpenSourceRelWithDebInfo
C:\cygwin\bin\python: can't open file 
'/cygdrive/c/dev/hgbuilds/autobuild/bin/autobuild': [Errno 2] No such file or 
directory
dir: /cygdrive/c/dev/hgbuilds/v-autobuild
$ ls -l /cygdrive/c/dev/hgbuilds/autobuild/bin/autobuild
-rwxr-xr-x 1 John None 2213 Jan 31 20:37 
/cygdrive/c/dev/hgbuilds/autobuild/bin/autobuild
dir: /cygdrive/c/dev/hgbuilds/v-autobuild
$ ___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Review Request: VWR-24312: Massively duplicated objects (part 2)

[Merov Linden]

---
This is an automatically generated e-mail. To reply, visit:
http://codereview.secondlife.com/r/81/#review300
---


@Aleric: OK, you convinced me on all accounts *except* for the ease of merge 
which I want to test myself before giving my blessing to this patch. You 
wouldn't be the first one be to claim that "it merges" and create some issues 
unwittingly. If you could post the URL of an hg repo with your patch, I'll be 
happy to give it a spin building on all platforms.

BTW, thanks for the super detailed comment: very interesting stuff.

- 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
> 
>

___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] problems working with autobuild

[Nicky Perian]

I can't tell but it looks like windows and you using cygwin, Is that correct?
I was able to us the Visual Studio Command Prompt and all went as planned in 
documentation save one patch from Oz.
Realize that isn't help. But, i didn't use cygwin and my Python was a seperate 
install in windows. Did not use the cygwin version of Python.





From: Twisted Laws 
To: SLDEV 
Sent: Mon, January 31, 2011 8:43:01 PM
Subject: [opensource-dev] problems working with autobuild

 So I figured I'd give the autobuild method of building a try.   I've not made 
it far yet 

and wondering if someone might give me a pointer on what I've done wrong...
 
I read: http://wiki.secondlife.com/wiki/Autobuild_Quick_Start
and read: 
https://lists.secondlife.com/pipermail/opensource-dev/2011-January/005633.html
v-autobuild is from: https://bitbucket.org/mani_linden/viewer-autobuild
 
I must be missing something here but I'm not sure what.  The autobuild/bin 
directory is 

in the path.   Python 2.6 installed.
 
Thanks for any hints,  session log follows  (note that the ./setup.py install 
fails, and i have
to use python setup.py install)
 
dir: /cygdrive/c/dev/hgbuilds
$ cd autobuild
dir: /cygdrive/c/dev/hgbuilds/autobuild
$ ls
autobuild  bin  build  setup.py
dir: /cygdrive/c/dev/hgbuilds/autobuild
$ ./setup.py install
./setup.py: line 23: from: command not found
./setup.py: line 27: PACKAGE_NAME: command not found
./setup.py: line 28: LLAUTOBUILD_VERSION: command not found
./setup.py: line 29: LLAUTOBUILD_SOURCE: command not found
./setup.py: line 30: CLASSIFIERS: command not found
./setup.py: line 41: ext_modules: command not found
./setup.py: line 43: syntax error near unexpected token `newline'
./setup.py: line 43: `setup('
dir: /cygdrive/c/dev/hgbuilds/autobuild
$ python setup.py install
running install
running build
running build_py
running build_scripts
running install_lib
running install_scripts
running install_egg_info
Removing C:\Python26\Lib\site-packages\autobuild-0.0.0-py2.6.egg-info
Writing C:\Python26\Lib\site-packages\autobuild-0.0.0-py2.6.egg-info
dir: /cygdrive/c/dev/hgbuilds/autobuild
$ cd ../v-autobuild
dir: /cygdrive/c/dev/hgbuilds/v-autobuild
$ autobuild configure -c OpenSourceRelWithDebInfo
C:\cygwin\bin\python: can't open file 
'/cygdrive/c/dev/hgbuilds/autobuild/bin/autobuild': [Errno 2] No such file or 
directory
dir: /cygdrive/c/dev/hgbuilds/v-autobuild
$ ls -l /cygdrive/c/dev/hgbuilds/autobuild/bin/autobuild
-rwxr-xr-x 1 John None 2213 Jan 31 20:37 
/cygdrive/c/dev/hgbuilds/autobuild/bin/autobuild
dir: /cygdrive/c/dev/hgbuilds/v-autobuild
$



  ___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Review Request: VWR-17050 No nearby people when over approxiamately 1000 meters

[Twisted Laws]

---
This is an automatically generated e-mail. To reply, visit:
http://codereview.secondlife.com/r/132/#review302
---



indra/newview/llworld.cpp


This area where I search for the existance of an uuid in the list is 
something that works but it would seem that theres some better method.  Open to 
suggestions.


- Twisted


On Jan. 31, 2011, 3:34 p.m., Twisted Laws wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/132/
> ---
> 
> (Updated Jan. 31, 2011, 3:34 p.m.)
> 
> 
> Review request for Viewer.
> 
> 
> Summary
> ---
> 
> This modifies the getAvatars function in llworld to also include any avatars 
> that are found within the range from the LLCharactes list as well (the list 
> of avatars that is in the viewer object list).  This should make sure that 
> anyone that you visually see within range shows up in the list.  Note that 
> changing it in this function also affects 
> LLFloaterAvatarPicker::populateNearMe, LLLocalSpeakerMgr::updateSpeakerList, 
> as well as the LLPanelPeople::updateNearbyList that was originally mentioned 
> in the Jira.  The region avatars lists only contain valid position data when 
> the avatars are below 1024m.  The comment that mentions about retrieving 
> uuids is based on the function, not the current uses.  No current calls in 
> the code are done with the avatar_ids argument NULL.  Duplicates in the 
> returned list need to be suppressed.
> 
> 
> This addresses bug VWR-17050.
> http://jira.secondlife.com/browse/VWR-17050
> 
> 
> Diffs
> -
> 
>   indra/newview/llworld.cpp 691e3941d950 
> 
> Diff: http://codereview.secondlife.com/r/132/diff
> 
> 
> Testing
> ---
> 
> Simple testing in sandboxes of this patch at 20m and 2000m heights with and 
> without avatars nearby.  Tested with varying the NearMeRange to insure it 
> does not show avatars beyond the range.  Testers need to understand that 
> RenderFarClip has an impact on the avatars that are actually in the viewer 
> object list, so setting NearMeRange to a great distance at high altitude 
> won't necessarily add avatars to the list.  Basically if you can see the 
> avatar and its within NearMeRange, the avatar should be in the nearby avatar 
> list in the people panel.
> 
> 
> Thanks,
> 
> Twisted
> 
>

___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Review Request: VWR-17050 No nearby people when over approxiamately 1000 meters

[Twisted Laws]

> On Jan. 31, 2011, 5:48 p.m., Merov Linden wrote:
> > It seems to me that the new code can completely replace the old one, i.e. 
> > the search based on the map is not adding anything different or is it?

There are several reasons that replacing the code may provide a different 
result.  The list of avatars returned by the function is based on NearMeRange 
which could be a greater value than RenderFarClip.  In that case, replacing the 
code would only return the list of avatars in RenderFarClip range and would 
ignore a greater NearMeRange.  In the case of a person owning an island, they 
may have NearMeList set to 1200 so they could see the presence of any avatar in 
their region at any altitude and yet have RenderFarClip set to 128.  I realize 
that at this point its not really "NearMe".  Also I've noticed in the sandboxes 
that quite often a person shows up in the region avatar list before showing up 
in the viewer object list and in my personal implementation of a radar floater 
I mark the avatar names that are not visible.  In the released versions of the 
Nearby list, the Zoom-in option is not available for avatars that are not 
visible so designers must have considered this situation.

I guess my other reason would be changing it in llworld wouldn't be the right 
place to have the function getAvatars if it ignored map data and only used 
character data.  Maybe creating a new getAvatars in LLCharacters would be the 
right way to do it then.


> On Jan. 31, 2011, 5:48 p.m., Merov Linden wrote:
> > indra/newview/llworld.cpp, lines 1475-1477
> > 
> >
> > I fail to see how the "1000m" condition is tested in this code. Same 
> > for the "only do this when we are retrieving uuid's".

It can only provide the function if it has been storing uuid's (avatar_ids not 
null) or it would provide duplicates.  The reason its for over 1000m is the 
viewer object list position is ignored if it had already added the uuid from 
the region data.  I.e, the region avatar position is incorrect if the user is 
over 1024m and will not be added to the list as its not in NearMeRange.


- Twisted


---
This is an automatically generated e-mail. To reply, visit:
http://codereview.secondlife.com/r/132/#review297
---


On Jan. 31, 2011, 3:34 p.m., Twisted Laws wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/132/
> ---
> 
> (Updated Jan. 31, 2011, 3:34 p.m.)
> 
> 
> Review request for Viewer.
> 
> 
> Summary
> ---
> 
> This modifies the getAvatars function in llworld to also include any avatars 
> that are found within the range from the LLCharactes list as well (the list 
> of avatars that is in the viewer object list).  This should make sure that 
> anyone that you visually see within range shows up in the list.  Note that 
> changing it in this function also affects 
> LLFloaterAvatarPicker::populateNearMe, LLLocalSpeakerMgr::updateSpeakerList, 
> as well as the LLPanelPeople::updateNearbyList that was originally mentioned 
> in the Jira.  The region avatars lists only contain valid position data when 
> the avatars are below 1024m.  The comment that mentions about retrieving 
> uuids is based on the function, not the current uses.  No current calls in 
> the code are done with the avatar_ids argument NULL.  Duplicates in the 
> returned list need to be suppressed.
> 
> 
> This addresses bug VWR-17050.
> http://jira.secondlife.com/browse/VWR-17050
> 
> 
> Diffs
> -
> 
>   indra/newview/llworld.cpp 691e3941d950 
> 
> Diff: http://codereview.secondlife.com/r/132/diff
> 
> 
> Testing
> ---
> 
> Simple testing in sandboxes of this patch at 20m and 2000m heights with and 
> without avatars nearby.  Tested with varying the NearMeRange to insure it 
> does not show avatars beyond the range.  Testers need to understand that 
> RenderFarClip has an impact on the avatars that are actually in the viewer 
> object list, so setting NearMeRange to a great distance at high altitude 
> won't necessarily add avatars to the list.  Basically if you can see the 
> avatar and its within NearMeRange, the avatar should be in the nearby avatar 
> list in the people panel.
> 
> 
> Thanks,
> 
> Twisted
> 
>

___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges