Re: [opensource-dev] Review Request: scripts/install.py --uninstall does not always remove symbolic links.

[Brad Kittenbrink]

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

Ship it!


Looks like a safe and sensible change to me.

- Brad


On 2010-12-16 07:34:22, Aleric Inglewood wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/29/
> ---
> 
> (Updated 2010-12-16 07:34:22)
> 
> 
> Review request for Viewer.
> 
> 
> Summary
> ---
> 
> Packages (tar balls) installed with scripts/install.py do contain symbolic 
> links.
> Everything that they contain is written to the file installed.xml, and upon
> uninstall attempted to remove.
> 
> However, the python script first tests if a file exists before it removes it
> and uses os.path.exists for this, which only returns true when the target
> is a file, or a symbolic link *pointing* to an existing file.
> 
> Since the removal of the tar ball elements is arbitrary, it is possible (and
> often the case) that the file the symbolic link points to is removed before
> the symbolic link itself is removed, causing the test to fail and the symbolic
> link not to be removed.
> 
> This patch solves this bug by using os.path.lexists which returns true for
> normal files when they exist, and true for symbolic links if they exist,
> whether or not the file they point to exists, exactly what we want.
> 
> os.path.lexists was added to python 2.4, so that should not be problem.
> 
> 
> This addresses bug SNOW-744.
> http://jira.secondlife.com/browse/SNOW-744
> 
> 
> Diffs
> -
> 
>   scripts/install.py b0689af42a71 
> 
> Diff: http://codereview.secondlife.com/r/29/diff
> 
> 
> Testing
> ---
> 
> This patch was originally tested to work several months ago, and has been in
> use by the Imprudence TPV for a while now.
> 
> 
> 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] Review Request: VWR-24251: Fix -DLL_TESTS:BOOL=ON on standalone when Tut is installed in a non-standard directory.

[Brad Kittenbrink]

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

Ship it!


Looks good to me

- Brad


On 2010-12-19 07:18:51, Aleric Inglewood wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/44/
> ---
> 
> (Updated 2010-12-19 07:18:51)
> 
> 
> Review request for Viewer.
> 
> 
> Summary
> ---
> 
> If tut/tut.hpp isn't installed in a standard include directory all tests
> fail because the found include directory for tut isn't passed to the compiler.
> 
> This patch fixes this by passing it.
> Note that using include_directories() in a Find*.cmake file is bad practise.
> The correct way is to set an include dir variable and call
> include_directories() once. It certainly doesn't work for the tests anyway
> because the tests are all over the place and include_directories is on a
> per folder basis.  What is needed is to set it for each (test) target.
> 
> However, there is no TARGET_INCLUDE_DIRECTORIES. The closest thing that we
> have is to set the COMPILE_FLAGS property for a target.
> 
> Fortunately, standalone is only used for linux, so we can just use
> -I${TUT_INCLUDE_DIR} to get the effect we want.
> 
> 
> This addresses bug VWR-24251.
> http://jira.secondlife.com/browse/VWR-24251
> 
> 
> Diffs
> -
> 
>   indra/cmake/LLAddBuildTest.cmake b0689af42a71 
>   indra/cmake/Tut.cmake b0689af42a71 
>   indra/test/CMakeLists.txt b0689af42a71 
> 
> Diff: http://codereview.secondlife.com/r/44/diff
> 
> 
> Testing
> ---
> 
> Tested with standalone and tut.hpp installed in a non-standard place *after 
> applying VWR-24247* of course.
> All tests compile and pass (on linux 64bit).
> 
> 
> 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

[opensource-dev] Review Request: VWR-25608 error on shutdown due to buffer overrun in LLVFS::audit

[Brad Kittenbrink]

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

Review request for Viewer.


Summary
---

Fix for a minor buffer overrun on shutdown in LLVFS::audit.


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


Diffs
-

  indra/llvfs/llvfs.cpp UNKNOWN 

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


Testing
---

I tested using the Microsoft Debug Heap and confirmed that this allows the 
Debug Heap to shut down without errors.


Thanks,

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

[opensource-dev] Review Request: VWR-25609 crash on shutdown in LLGLNamePool::sInstances destructor

[Brad Kittenbrink]

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

Review request for Viewer.


Summary
---

The error is due to the fact that the instances of subclasses of LLGLNamePool 
(e.g. LLVertexBuffer::sStreamVBOPool) were having their destructors run after 
the destructor for LLGLNamePool::sInstances, yet accessing the members of the 
already destructed vector, causing a crash.


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


Diffs
-

  indra/llrender/llgl.h UNKNOWN 
  indra/llrender/llgl.cpp UNKNOWN 
  indra/llrender/llvertexbuffer.cpp UNKNOWN 
  indra/newview/llspatialpartition.cpp UNKNOWN 

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


Testing
---

Tested in debug builds with the Microsoft Debug heap and confirmed that this 
patch allows shutdown to complete without error.


Thanks,

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

[opensource-dev] Review Request: VWR-25610 LLControlGroup::loadFromFile makes unnecessary copies of large LLSD objects

[Brad Kittenbrink]

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

Review request for Viewer.


Summary
---

Unnecessary copying was slowing down debugging of STORM-1141.


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


Diffs
-

  indra/llxml/llcontrol.cpp UNKNOWN 

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


Testing
---


Thanks,

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] Review Request: VWR-25609 crash on shutdown in LLGLNamePool::sInstances destructor

[Brad Kittenbrink]

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

(Updated April 26, 2011, 5:40 p.m.)


Review request for Viewer.


Summary (updated)
---

The error is due to the fact that the instances of subclasses of LLGLNamePool 
(e.g. LLVertexBuffer::sStreamVBOPool) were having their destructors run after 
the destructor for LLGLNamePool::sInstances, yet accessing the members of the 
already destructed vector, causing a crash.

The fix is to use the LLInstanceTracker class which has already solved this 
problem in a general way, rather than hand-rolling our own custom solution in 
LLGLNamePool.


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


Diffs
-

  indra/llrender/llgl.h UNKNOWN 
  indra/llrender/llgl.cpp UNKNOWN 
  indra/llrender/llvertexbuffer.cpp UNKNOWN 
  indra/newview/llspatialpartition.cpp UNKNOWN 

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


Testing
---

Tested in debug builds with the Microsoft Debug heap and confirmed that this 
patch allows shutdown to complete without error.


Thanks,

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

[opensource-dev] Review Request: CHOP-629 symbol information for llcommon.dll is missing both in the debugger and in crash reports

[Brad Kittenbrink]

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

Review request for Viewer.


Summary
---

Somewhere in the VS2010 transition, the default conventions changed for how 
.pdb files get generated on shared library targets.  This fix explicitly sets 
the /DEBUG flag for the linker on the llcommon target.


This addresses bug CHOP-629.
http://jira.secondlife.com/browse/CHOP-629


Diffs
-

  indra/llcommon/CMakeLists.txt UNKNOWN 

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


Testing
---

I tested locally in the debugger, but I did not test crash reports.  We should 
find a way to test that once my TC build completes.


Thanks,

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] Review Request: CHOP-629 symbol information for llcommon.dll is missing both in the debugger and in crash reports

[Brad Kittenbrink]

> On April 27, 2011, 2:16 a.m., Boroondas Gupte wrote:
> > indra/llcommon/CMakeLists.txt, lines 262-278
> > <http://codereview.secondlife.com/r/281/diff/1/?file=1517#file1517line262>
> >
> > Naive question: Is there a reason not to add /DEBUG also when NOT 
> > LLCOMMON_LINK_SHARED?

The /DEBUG linker flag doesn't really apply for static libraries since the 
linker doesn't run for static libraries on windows.  The debug information is 
already embedded in our .lib static libraries on windows.


- Brad


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


On April 26, 2011, 5:48 p.m., Brad Kittenbrink wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/281/
> ---
> 
> (Updated April 26, 2011, 5:48 p.m.)
> 
> 
> Review request for Viewer.
> 
> 
> Summary
> ---
> 
> Somewhere in the VS2010 transition, the default conventions changed for how 
> .pdb files get generated on shared library targets.  This fix explicitly sets 
> the /DEBUG flag for the linker on the llcommon target.
> 
> 
> This addresses bug CHOP-629.
> http://jira.secondlife.com/browse/CHOP-629
> 
> 
> Diffs
> -
> 
>   indra/llcommon/CMakeLists.txt UNKNOWN 
> 
> Diff: http://codereview.secondlife.com/r/281/diff
> 
> 
> Testing
> ---
> 
> I tested locally in the debugger, but I did not test crash reports.  We 
> should find a way to test that once my TC build completes.
> 
> 
> Thanks,
> 
> 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] Review Request: VWR-25608 error on shutdown due to buffer overrun in LLVFS::audit

[Brad Kittenbrink]

> On April 27, 2011, 3:30 a.m., Boroondas Gupte wrote:
> > indra/llvfs/llvfs.cpp, lines 1716-1717
> > <http://codereview.secondlife.com/r/278/diff/1/?file=1511#file1511line1716>
> >
> > When index_size == 0, wouldn't it be more appropriate to skip the steps 
> > that require taking the address of element 0? They'd be nil operations in 
> > that case, anyway, wouldn't they?

In theory, you're right, but my intent was to make the minimally invasive 
change that would fix the error, and be sure to preserve all existing 
behaviors.  I was hesitant to engage in any more extensive refactoring without 
a good plan for how we want to test this subsystem.


> On April 27, 2011, 3:30 a.m., Boroondas Gupte wrote:
> > indra/llvfs/llvfs.cpp, lines 1719-1723
> > <http://codereview.secondlife.com/r/278/diff/1/?file=1511#file1511line1719>
> >
> > e.g. here we could extend the condition to
> > if (!buffer.empty() && (fread(&buffer[0], 1, index_size, 
> > mIndexFP) != index_size))

We certainly could, but I'm not convinced that that's better.


On April 27, 2011, 3:30 a.m., Brad Kittenbrink wrote:
> > Finally, if we are only ever accessing the underlying memory directly (as 
> > seems to be the case here), why use a std::vector as buffer instead of an 
> > array?

I can't speak to the intent of the original author of this code, but I always 
use vectors for dynamically sized arrays, as they automatically free the 
buffer.  Using new[] or malloc is far more error prone, even when using 
std::auto_ptr or boost::scoped_ptr for RAII.


- Brad


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


On April 26, 2011, 5:31 p.m., Brad Kittenbrink wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/278/
> ---
> 
> (Updated April 26, 2011, 5:31 p.m.)
> 
> 
> Review request for Viewer.
> 
> 
> Summary
> ---
> 
> Fix for a minor buffer overrun on shutdown in LLVFS::audit.
> 
> 
> This addresses bug VWR-25608.
> http://jira.secondlife.com/browse/VWR-25608
> 
> 
> Diffs
> -
> 
>   indra/llvfs/llvfs.cpp UNKNOWN 
> 
> Diff: http://codereview.secondlife.com/r/278/diff
> 
> 
> Testing
> ---
> 
> I tested using the Microsoft Debug Heap and confirmed that this allows the 
> Debug Heap to shut down without errors.
> 
> 
> Thanks,
> 
> 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] Review Request: VWR-25610 LLControlGroup::loadFromFile makes unnecessary copies of large LLSD objects

[Brad Kittenbrink]

> On April 27, 2011, 4:16 a.m., Boroondas Gupte wrote:
> > indra/llxml/llcontrol.cpp, lines 866-867
> > <http://codereview.secondlife.com/r/280/diff/1/?file=1516#file1516line866>
> >
> > 1) Any reason not to do the same for name?
> > 2) Remove space between "const" and "&", so that it's easer to visually 
> > distinguish from binary operator &
> > 3) LLSD::map_const_iterator seems to support operator ->, so we could 
> > write itr->second instead of (*itr).second .

1) Premature optimization is the root of all evil.  In all seriousness though, 
I found that the recursive LLSD copying was causing a significant number of 
memory allocations.  I didn't notice the name copying in the profiling, so I 
didn't look at it.  Making this consistent is probably a good idea.
2) I think this is a bad idea, that would be far less readable imho.
3) I'd be fine with this change at some point, but I don't think it really 
matters.


On April 27, 2011, 4:16 a.m., Brad Kittenbrink wrote:
> > [*] Assuming the data referenced by control_map isn't changed by other 
> > threads meanwhile. But I guess that'd also be necessary for copying it 
> > correctly, isn't it?

Correct, there are no other threads that can interfere with 
LLControlGroup::loadFromFile


- Brad


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


On April 26, 2011, 5:36 p.m., Brad Kittenbrink wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/280/
> ---
> 
> (Updated April 26, 2011, 5:36 p.m.)
> 
> 
> Review request for Viewer.
> 
> 
> Summary
> ---
> 
> Unnecessary copying was slowing down debugging of STORM-1141.
> 
> 
> This addresses bug VWR-25610.
> http://jira.secondlife.com/browse/VWR-25610
> 
> 
> Diffs
> -
> 
>   indra/llxml/llcontrol.cpp UNKNOWN 
> 
> Diff: http://codereview.secondlife.com/r/280/diff
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> 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] Review Request: VWR-25654: fix memory leak in LLTranslate::getTranslateUrl

[Brad Kittenbrink]

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

Ship it!


Looks good to me.

- Brad


On May 1, 2011, 2:54 p.m., Boroondas Gupte wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/282/
> ---
> 
> (Updated May 1, 2011, 2:54 p.m.)
> 
> 
> Review request for Viewer.
> 
> 
> Summary
> ---
> 
> curl_escape() returns a pointer to a C-string. When one is done with the 
> C-string, one must curl_free() the pointer. (See 
> http://curl.haxx.se/libcurl/c/curl_escape.html .) To be able to call 
> curl_free on the pointer, we must keep it in the first place.
> 
> Also, a cpp file in which curl functions are called should include 
>  directly, even if it already gets included indirectly, i.e. via 
> other includes. So adding that, too.
> 
> 
> Note that curl_escape() is deprecated and should be replaced by 
> curl_easy_escape(). This change does not do that, as this should probably be 
> done for all occurrences at once and be accompanied by some refactoring.
> 
> 
> This addresses bug VWR-25654.
> http://jira.secondlife.com/browse/VWR-25654
> 
> 
> Diffs
> -
> 
>   doc/contributions.txt 9ff8625cadec 
>   indra/newview/lltranslate.cpp 9ff8625cadec 
> 
> Diff: http://codereview.secondlife.com/r/282/diff
> 
> 
> Testing
> ---
> 
> * Built Viewer (Linux 64bit STANDALONE)
> * Verified that translation still works (logged in, enabled translation in 
> nearby chat floater, changed "translate to" language in preferences > chat 
> and went to Ahern)
> 
> 
> Thanks,
> 
> 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

Re: [opensource-dev] Review Request: VWR-25609 crash on shutdown in LLGLNamePool::sInstances destructor

[Brad Kittenbrink]

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

(Updated May 2, 2011, 4:30 p.m.)


Review request for Viewer and Richard Nelson.


Summary
---

The error is due to the fact that the instances of subclasses of LLGLNamePool 
(e.g. LLVertexBuffer::sStreamVBOPool) were having their destructors run after 
the destructor for LLGLNamePool::sInstances, yet accessing the members of the 
already destructed vector, causing a crash.

The fix is to use the LLInstanceTracker class which has already solved this 
problem in a general way, rather than hand-rolling our own custom solution in 
LLGLNamePool.


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


Diffs
-

  indra/llrender/llgl.h UNKNOWN 
  indra/llrender/llgl.cpp UNKNOWN 
  indra/llrender/llvertexbuffer.cpp UNKNOWN 
  indra/newview/llspatialpartition.cpp UNKNOWN 

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


Testing
---

Tested in debug builds with the Microsoft Debug heap and confirmed that this 
patch allows shutdown to complete without error.


Thanks,

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

[opensource-dev] Review Request: CHOP-619 fix for pre-compiled headers issue

[Brad Kittenbrink]

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

Review request for Viewer.


Summary
---

Fix for error using precompiled headers with vs2010 and incredibuild 3.60 beta2.

We'll use this opportunity to remove all the special cases we had for working 
around this problem.


This addresses bug CHOP-616.
http://jira.secondlife.com/browse/CHOP-616


Diffs
-

  indra/llcommon/llapp.cpp UNKNOWN 
  indra/llui/llbutton.h UNKNOWN 
  indra/llui/llfloaterreg.h UNKNOWN 
  indra/llui/llfocusmgr.h UNKNOWN 
  indra/llui/llfocusmgr.cpp UNKNOWN 
  indra/llui/lliconctrl.h UNKNOWN 
  indra/llui/lllineeditor.h UNKNOWN 
  indra/llui/llloadingindicator.h UNKNOWN 
  indra/llui/llmultislider.cpp UNKNOWN 
  indra/llui/llpanel.h UNKNOWN 
  indra/llui/llprogressbar.h UNKNOWN 
  indra/llui/llprogressbar.cpp UNKNOWN 
  indra/llui/llslider.h UNKNOWN 
  indra/llui/llstyle.h UNKNOWN 
  indra/llui/llstyle.cpp UNKNOWN 
  indra/llui/lltransutil.cpp UNKNOWN 
  indra/llui/llui.h UNKNOWN 
  indra/llui/llview.h UNKNOWN 
  indra/llui/llviewborder.cpp UNKNOWN 
  indra/llui/llwindowshade.h UNKNOWN 
  indra/llxuixml/lltrans.h UNKNOWN 
  indra/llxuixml/lltrans.cpp UNKNOWN 
  indra/llxuixml/llxuiparser.h UNKNOWN 
  indra/newview/llagent.h UNKNOWN 
  indra/newview/llagent.cpp UNKNOWN 
  indra/newview/llappviewer.cpp UNKNOWN 
  indra/newview/lleventnotifier.h UNKNOWN 
  indra/newview/llfloaterland.h UNKNOWN 
  indra/newview/llfloaterland.cpp UNKNOWN 
  indra/newview/llfloatersnapshot.cpp UNKNOWN 
  indra/newview/llfolderviewitem.h UNKNOWN 
  indra/newview/lllocationhistory.h UNKNOWN 
  indra/newview/lloutputmonitorctrl.h UNKNOWN 
  indra/newview/llpanelavatar.cpp UNKNOWN 
  indra/newview/llpanelgroupgeneral.cpp UNKNOWN 
  indra/newview/llpanelgrouproles.cpp UNKNOWN 
  indra/newview/llpreviewgesture.cpp UNKNOWN 
  indra/newview/llsidepaneliteminfo.cpp UNKNOWN 
  indra/newview/lltooldraganddrop.cpp UNKNOWN 
  indra/newview/llviewerchat.cpp UNKNOWN 
  indra/newview/llviewerkeyboard.h UNKNOWN 
  indra/newview/llviewermenu.cpp UNKNOWN 
  indra/newview/llviewerparcelmgr.cpp UNKNOWN 
  indra/newview/llviewerprecompiledheaders.h UNKNOWN 
  indra/newview/llviewerregion.h UNKNOWN 
  indra/newview/llviewerregion.cpp UNKNOWN 
  indra/newview/llviewertexturelist.h UNKNOWN 
  indra/newview/llviewerwindow.h UNKNOWN 
  indra/newview/llviewerwindow.cpp UNKNOWN 
  indra/newview/llvoavatar.cpp UNKNOWN 
  indra/newview/llvotree.cpp UNKNOWN 
  indra/newview/llvovolume.cpp UNKNOWN 
  indra/newview/llworld.cpp UNKNOWN 
  indra/newview/tests/llremoteparcelrequest_test.cpp UNKNOWN 
  indra/newview/tests/llviewerhelputil_test.cpp UNKNOWN 

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


Testing
---

I tested builds personally on windows and linux although the cmake changes can 
only affect windows.

The changes are such that testing the viewer itself is completely unnecessary.  
If it builds, it's good.


Thanks,

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

[opensource-dev] Review Request: Improvements in configuration time by eliminating redundant unpacking when reconfiguring

[Brad Kittenbrink]

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

Review request for Viewer.


Summary
---

Added checking in indra/cmake/Prebuilt.cmake to skip unnecessary unpacking of 
already installed packages.


This addresses bug CHOP-609.
http://jira.secondlife.com/browse/CHOP-609


Diffs
-

  indra/CMakeLists.txt UNKNOWN 
  indra/cmake/Prebuilt.cmake UNKNOWN 

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


Testing
---


Thanks,

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

[opensource-dev] Review Request: CHOP-624 header dependency improvements for build time speedup

[Brad Kittenbrink]

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

Review request for Viewer.


Summary
---

Sorry for the big diff here, but reworking a LOT of header dependencies to 
reduce complexity and help build time.  Started moving stuff out of public 
interfaces of classes to improve insulation (for example in llviewerregion.h 
and llviewerwindow.h).


This addresses bug CHOP-624.
http://jira.secondlife.com/browse/CHOP-624


Diffs
-

  indra/llcommon/llapp.cpp UNKNOWN 
  indra/llui/llbutton.h UNKNOWN 
  indra/llui/llfloaterreg.h UNKNOWN 
  indra/llui/llfocusmgr.h UNKNOWN 
  indra/llui/llfocusmgr.cpp UNKNOWN 
  indra/llui/lliconctrl.h UNKNOWN 
  indra/llui/lllineeditor.h UNKNOWN 
  indra/llui/llloadingindicator.h UNKNOWN 
  indra/llui/llmultislider.cpp UNKNOWN 
  indra/llui/llpanel.h UNKNOWN 
  indra/llui/llprogressbar.h UNKNOWN 
  indra/llui/llprogressbar.cpp UNKNOWN 
  indra/llui/llslider.h UNKNOWN 
  indra/llui/llstyle.h UNKNOWN 
  indra/llui/llstyle.cpp UNKNOWN 
  indra/llui/lltransutil.cpp UNKNOWN 
  indra/llui/llui.h UNKNOWN 
  indra/llui/llview.h UNKNOWN 
  indra/llui/llviewborder.cpp UNKNOWN 
  indra/llui/llwindowshade.h UNKNOWN 
  indra/llxuixml/lltrans.h UNKNOWN 
  indra/llxuixml/lltrans.cpp UNKNOWN 
  indra/llxuixml/llxuiparser.h UNKNOWN 
  indra/newview/llagent.h UNKNOWN 
  indra/newview/llagent.cpp UNKNOWN 
  indra/newview/llappviewer.cpp UNKNOWN 
  indra/newview/lleventnotifier.h UNKNOWN 
  indra/newview/llfloaterland.h UNKNOWN 
  indra/newview/llfloaterland.cpp UNKNOWN 
  indra/newview/llfloatersnapshot.cpp UNKNOWN 
  indra/newview/llfolderviewitem.h UNKNOWN 
  indra/newview/lllocationhistory.h UNKNOWN 
  indra/newview/lloutputmonitorctrl.h UNKNOWN 
  indra/newview/llpanelavatar.cpp UNKNOWN 
  indra/newview/llpanelgroupgeneral.cpp UNKNOWN 
  indra/newview/llpanelgrouproles.cpp UNKNOWN 
  indra/newview/llpreviewgesture.cpp UNKNOWN 
  indra/newview/llsidepaneliteminfo.cpp UNKNOWN 
  indra/newview/lltooldraganddrop.cpp UNKNOWN 
  indra/newview/llviewerchat.cpp UNKNOWN 
  indra/newview/llviewerkeyboard.h UNKNOWN 
  indra/newview/llviewermenu.cpp UNKNOWN 
  indra/newview/llviewerparcelmgr.cpp UNKNOWN 
  indra/newview/llviewerprecompiledheaders.h UNKNOWN 
  indra/newview/llviewerregion.h UNKNOWN 
  indra/newview/llviewerregion.cpp UNKNOWN 
  indra/newview/llviewertexturelist.h UNKNOWN 
  indra/newview/llviewerwindow.h UNKNOWN 
  indra/newview/llviewerwindow.cpp UNKNOWN 
  indra/newview/llvoavatar.cpp UNKNOWN 
  indra/newview/llvotree.cpp UNKNOWN 
  indra/newview/llvovolume.cpp UNKNOWN 
  indra/newview/llworld.cpp UNKNOWN 
  indra/newview/tests/llremoteparcelrequest_test.cpp UNKNOWN 
  indra/newview/tests/llviewerhelputil_test.cpp UNKNOWN 

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


Testing
---


Thanks,

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] Review Request: CHOP-624 header dependency improvements for build time speedup

[Brad Kittenbrink]

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

(Updated May 3, 2011, 6:40 p.m.)


Review request for Viewer.


Summary (updated)
---

Sorry for the big diff here, but reworking a LOT of header dependencies to 
reduce complexity and help build time.  Started moving stuff out of public 
interfaces of classes to improve insulation (for example in llviewerregion.h 
and llagent.h for the biggest examples).


This addresses bug CHOP-624.
http://jira.secondlife.com/browse/CHOP-624


Diffs
-

  indra/llcommon/llapp.cpp UNKNOWN 
  indra/llui/llbutton.h UNKNOWN 
  indra/llui/llfloaterreg.h UNKNOWN 
  indra/llui/llfocusmgr.h UNKNOWN 
  indra/llui/llfocusmgr.cpp UNKNOWN 
  indra/llui/lliconctrl.h UNKNOWN 
  indra/llui/lllineeditor.h UNKNOWN 
  indra/llui/llloadingindicator.h UNKNOWN 
  indra/llui/llmultislider.cpp UNKNOWN 
  indra/llui/llpanel.h UNKNOWN 
  indra/llui/llprogressbar.h UNKNOWN 
  indra/llui/llprogressbar.cpp UNKNOWN 
  indra/llui/llslider.h UNKNOWN 
  indra/llui/llstyle.h UNKNOWN 
  indra/llui/llstyle.cpp UNKNOWN 
  indra/llui/lltransutil.cpp UNKNOWN 
  indra/llui/llui.h UNKNOWN 
  indra/llui/llview.h UNKNOWN 
  indra/llui/llviewborder.cpp UNKNOWN 
  indra/llui/llwindowshade.h UNKNOWN 
  indra/llxuixml/lltrans.h UNKNOWN 
  indra/llxuixml/lltrans.cpp UNKNOWN 
  indra/llxuixml/llxuiparser.h UNKNOWN 
  indra/newview/llagent.h UNKNOWN 
  indra/newview/llagent.cpp UNKNOWN 
  indra/newview/llappviewer.cpp UNKNOWN 
  indra/newview/lleventnotifier.h UNKNOWN 
  indra/newview/llfloaterland.h UNKNOWN 
  indra/newview/llfloaterland.cpp UNKNOWN 
  indra/newview/llfloatersnapshot.cpp UNKNOWN 
  indra/newview/llfolderviewitem.h UNKNOWN 
  indra/newview/lllocationhistory.h UNKNOWN 
  indra/newview/lloutputmonitorctrl.h UNKNOWN 
  indra/newview/llpanelavatar.cpp UNKNOWN 
  indra/newview/llpanelgroupgeneral.cpp UNKNOWN 
  indra/newview/llpanelgrouproles.cpp UNKNOWN 
  indra/newview/llpreviewgesture.cpp UNKNOWN 
  indra/newview/llsidepaneliteminfo.cpp UNKNOWN 
  indra/newview/lltooldraganddrop.cpp UNKNOWN 
  indra/newview/llviewerchat.cpp UNKNOWN 
  indra/newview/llviewerkeyboard.h UNKNOWN 
  indra/newview/llviewermenu.cpp UNKNOWN 
  indra/newview/llviewerparcelmgr.cpp UNKNOWN 
  indra/newview/llviewerprecompiledheaders.h UNKNOWN 
  indra/newview/llviewerregion.h UNKNOWN 
  indra/newview/llviewerregion.cpp UNKNOWN 
  indra/newview/llviewertexturelist.h UNKNOWN 
  indra/newview/llviewerwindow.h UNKNOWN 
  indra/newview/llviewerwindow.cpp UNKNOWN 
  indra/newview/llvoavatar.cpp UNKNOWN 
  indra/newview/llvotree.cpp UNKNOWN 
  indra/newview/llvovolume.cpp UNKNOWN 
  indra/newview/llworld.cpp UNKNOWN 
  indra/newview/tests/llremoteparcelrequest_test.cpp UNKNOWN 
  indra/newview/tests/llviewerhelputil_test.cpp UNKNOWN 

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


Testing
---


Thanks,

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] Review Request: CHOP-624 header dependency improvements for build time speedup

[Brad Kittenbrink]

> On May 4, 2011, 11:58 a.m., Boroondas Gupte wrote:
> > This change is identical to the one under review at 
> > https://codereview.secondlife.com/r/289
> > 
> > Did you upload the wrong diff file to one of the review requests?

Oops, yes I did.  We can ignore this one and I'll rename the other one 
appropriately.

I'll upload the other patch as a new issue.


- Brad


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


On May 3, 2011, 6:40 p.m., Brad Kittenbrink wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/297/
> ---
> 
> (Updated May 3, 2011, 6:40 p.m.)
> 
> 
> Review request for Viewer.
> 
> 
> Summary
> ---
> 
> Sorry for the big diff here, but reworking a LOT of header dependencies to 
> reduce complexity and help build time.  Started moving stuff out of public 
> interfaces of classes to improve insulation (for example in llviewerregion.h 
> and llagent.h for the biggest examples).
> 
> 
> This addresses bug CHOP-624.
> http://jira.secondlife.com/browse/CHOP-624
> 
> 
> Diffs
> -
> 
>   indra/llcommon/llapp.cpp UNKNOWN 
>   indra/llui/llbutton.h UNKNOWN 
>   indra/llui/llfloaterreg.h UNKNOWN 
>   indra/llui/llfocusmgr.h UNKNOWN 
>   indra/llui/llfocusmgr.cpp UNKNOWN 
>   indra/llui/lliconctrl.h UNKNOWN 
>   indra/llui/lllineeditor.h UNKNOWN 
>   indra/llui/llloadingindicator.h UNKNOWN 
>   indra/llui/llmultislider.cpp UNKNOWN 
>   indra/llui/llpanel.h UNKNOWN 
>   indra/llui/llprogressbar.h UNKNOWN 
>   indra/llui/llprogressbar.cpp UNKNOWN 
>   indra/llui/llslider.h UNKNOWN 
>   indra/llui/llstyle.h UNKNOWN 
>   indra/llui/llstyle.cpp UNKNOWN 
>   indra/llui/lltransutil.cpp UNKNOWN 
>   indra/llui/llui.h UNKNOWN 
>   indra/llui/llview.h UNKNOWN 
>   indra/llui/llviewborder.cpp UNKNOWN 
>   indra/llui/llwindowshade.h UNKNOWN 
>   indra/llxuixml/lltrans.h UNKNOWN 
>   indra/llxuixml/lltrans.cpp UNKNOWN 
>   indra/llxuixml/llxuiparser.h UNKNOWN 
>   indra/newview/llagent.h UNKNOWN 
>   indra/newview/llagent.cpp UNKNOWN 
>   indra/newview/llappviewer.cpp UNKNOWN 
>   indra/newview/lleventnotifier.h UNKNOWN 
>   indra/newview/llfloaterland.h UNKNOWN 
>   indra/newview/llfloaterland.cpp UNKNOWN 
>   indra/newview/llfloatersnapshot.cpp UNKNOWN 
>   indra/newview/llfolderviewitem.h UNKNOWN 
>   indra/newview/lllocationhistory.h UNKNOWN 
>   indra/newview/lloutputmonitorctrl.h UNKNOWN 
>   indra/newview/llpanelavatar.cpp UNKNOWN 
>   indra/newview/llpanelgroupgeneral.cpp UNKNOWN 
>   indra/newview/llpanelgrouproles.cpp UNKNOWN 
>   indra/newview/llpreviewgesture.cpp UNKNOWN 
>   indra/newview/llsidepaneliteminfo.cpp UNKNOWN 
>   indra/newview/lltooldraganddrop.cpp UNKNOWN 
>   indra/newview/llviewerchat.cpp UNKNOWN 
>   indra/newview/llviewerkeyboard.h UNKNOWN 
>   indra/newview/llviewermenu.cpp UNKNOWN 
>   indra/newview/llviewerparcelmgr.cpp UNKNOWN 
>   indra/newview/llviewerprecompiledheaders.h UNKNOWN 
>   indra/newview/llviewerregion.h UNKNOWN 
>   indra/newview/llviewerregion.cpp UNKNOWN 
>   indra/newview/llviewertexturelist.h UNKNOWN 
>   indra/newview/llviewerwindow.h UNKNOWN 
>   indra/newview/llviewerwindow.cpp UNKNOWN 
>   indra/newview/llvoavatar.cpp UNKNOWN 
>   indra/newview/llvotree.cpp UNKNOWN 
>   indra/newview/llvovolume.cpp UNKNOWN 
>   indra/newview/llworld.cpp UNKNOWN 
>   indra/newview/tests/llremoteparcelrequest_test.cpp UNKNOWN 
>   indra/newview/tests/llviewerhelputil_test.cpp UNKNOWN 
> 
> Diff: http://codereview.secondlife.com/r/297/diff
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> 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] Review Request: CHOP-624 header dependency improvements for build time speedup

[Brad Kittenbrink]

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

(Updated May 4, 2011, 2:57 p.m.)


Review request for Viewer.


Changes
---

Oops, swiched the patches when uploading, updated this issue with the info from 
the patch that actually got posted.


Summary (updated)
---

Sorry for the big diff here, but reworking a LOT of header dependencies to 
reduce complexity and help build time.  Started moving stuff out of public 
interfaces of classes to improve insulation (for example in llviewerregion.h 
and llagent.h for the biggest examples).


This addresses bug CHOP-624.
http://jira.secondlife.com/browse/CHOP-624


Diffs
-

  indra/llcommon/llapp.cpp UNKNOWN 
  indra/llui/llbutton.h UNKNOWN 
  indra/llui/llfloaterreg.h UNKNOWN 
  indra/llui/llfocusmgr.h UNKNOWN 
  indra/llui/llfocusmgr.cpp UNKNOWN 
  indra/llui/lliconctrl.h UNKNOWN 
  indra/llui/lllineeditor.h UNKNOWN 
  indra/llui/llloadingindicator.h UNKNOWN 
  indra/llui/llmultislider.cpp UNKNOWN 
  indra/llui/llpanel.h UNKNOWN 
  indra/llui/llprogressbar.h UNKNOWN 
  indra/llui/llprogressbar.cpp UNKNOWN 
  indra/llui/llslider.h UNKNOWN 
  indra/llui/llstyle.h UNKNOWN 
  indra/llui/llstyle.cpp UNKNOWN 
  indra/llui/lltransutil.cpp UNKNOWN 
  indra/llui/llui.h UNKNOWN 
  indra/llui/llview.h UNKNOWN 
  indra/llui/llviewborder.cpp UNKNOWN 
  indra/llui/llwindowshade.h UNKNOWN 
  indra/llxuixml/lltrans.h UNKNOWN 
  indra/llxuixml/lltrans.cpp UNKNOWN 
  indra/llxuixml/llxuiparser.h UNKNOWN 
  indra/newview/llagent.h UNKNOWN 
  indra/newview/llagent.cpp UNKNOWN 
  indra/newview/llappviewer.cpp UNKNOWN 
  indra/newview/lleventnotifier.h UNKNOWN 
  indra/newview/llfloaterland.h UNKNOWN 
  indra/newview/llfloaterland.cpp UNKNOWN 
  indra/newview/llfloatersnapshot.cpp UNKNOWN 
  indra/newview/llfolderviewitem.h UNKNOWN 
  indra/newview/lllocationhistory.h UNKNOWN 
  indra/newview/lloutputmonitorctrl.h UNKNOWN 
  indra/newview/llpanelavatar.cpp UNKNOWN 
  indra/newview/llpanelgroupgeneral.cpp UNKNOWN 
  indra/newview/llpanelgrouproles.cpp UNKNOWN 
  indra/newview/llpreviewgesture.cpp UNKNOWN 
  indra/newview/llsidepaneliteminfo.cpp UNKNOWN 
  indra/newview/lltooldraganddrop.cpp UNKNOWN 
  indra/newview/llviewerchat.cpp UNKNOWN 
  indra/newview/llviewerkeyboard.h UNKNOWN 
  indra/newview/llviewermenu.cpp UNKNOWN 
  indra/newview/llviewerparcelmgr.cpp UNKNOWN 
  indra/newview/llviewerprecompiledheaders.h UNKNOWN 
  indra/newview/llviewerregion.h UNKNOWN 
  indra/newview/llviewerregion.cpp UNKNOWN 
  indra/newview/llviewertexturelist.h UNKNOWN 
  indra/newview/llviewerwindow.h UNKNOWN 
  indra/newview/llviewerwindow.cpp UNKNOWN 
  indra/newview/llvoavatar.cpp UNKNOWN 
  indra/newview/llvotree.cpp UNKNOWN 
  indra/newview/llvovolume.cpp UNKNOWN 
  indra/newview/llworld.cpp UNKNOWN 
  indra/newview/tests/llremoteparcelrequest_test.cpp UNKNOWN 
  indra/newview/tests/llviewerhelputil_test.cpp UNKNOWN 

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


Testing (updated)
---


Thanks,

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] Review Request: CHOP-624 header dependency improvements for build time speedup

[Brad Kittenbrink]

> On May 4, 2011, 11:58 a.m., Boroondas Gupte wrote:
> > This change is identical to the one under review at 
> > https://codereview.secondlife.com/r/289
> > 
> > Did you upload the wrong diff file to one of the review requests?
> 
> Brad Kittenbrink wrote:
> Oops, yes I did.  We can ignore this one and I'll rename the other one 
> appropriately.
> 
> I'll upload the other patch as a new issue.
> 
> Boroondas Gupte wrote:
> OK. As the creator of this review request, you should be able to close 
> it, so it's off list on the RB Dashboard.
> 
> Slightly OT: Neither CHOP-624 nor CHOP-616 are publicly accessible. It 
> would be nice if you could give use permission to view corresponding jira 
> issues before filing a review request, so we know the context/motivation of 
> the code changes we'd try to review.

done!


- Brad


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


On May 3, 2011, 6:40 p.m., Brad Kittenbrink wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/297/
> ---
> 
> (Updated May 3, 2011, 6:40 p.m.)
> 
> 
> Review request for Viewer.
> 
> 
> Summary
> ---
> 
> Sorry for the big diff here, but reworking a LOT of header dependencies to 
> reduce complexity and help build time.  Started moving stuff out of public 
> interfaces of classes to improve insulation (for example in llviewerregion.h 
> and llagent.h for the biggest examples).
> 
> 
> This addresses bug CHOP-624.
> http://jira.secondlife.com/browse/CHOP-624
> 
> 
> Diffs
> -
> 
>   indra/llcommon/llapp.cpp UNKNOWN 
>   indra/llui/llbutton.h UNKNOWN 
>   indra/llui/llfloaterreg.h UNKNOWN 
>   indra/llui/llfocusmgr.h UNKNOWN 
>   indra/llui/llfocusmgr.cpp UNKNOWN 
>   indra/llui/lliconctrl.h UNKNOWN 
>   indra/llui/lllineeditor.h UNKNOWN 
>   indra/llui/llloadingindicator.h UNKNOWN 
>   indra/llui/llmultislider.cpp UNKNOWN 
>   indra/llui/llpanel.h UNKNOWN 
>   indra/llui/llprogressbar.h UNKNOWN 
>   indra/llui/llprogressbar.cpp UNKNOWN 
>   indra/llui/llslider.h UNKNOWN 
>   indra/llui/llstyle.h UNKNOWN 
>   indra/llui/llstyle.cpp UNKNOWN 
>   indra/llui/lltransutil.cpp UNKNOWN 
>   indra/llui/llui.h UNKNOWN 
>   indra/llui/llview.h UNKNOWN 
>   indra/llui/llviewborder.cpp UNKNOWN 
>   indra/llui/llwindowshade.h UNKNOWN 
>   indra/llxuixml/lltrans.h UNKNOWN 
>   indra/llxuixml/lltrans.cpp UNKNOWN 
>   indra/llxuixml/llxuiparser.h UNKNOWN 
>   indra/newview/llagent.h UNKNOWN 
>   indra/newview/llagent.cpp UNKNOWN 
>   indra/newview/llappviewer.cpp UNKNOWN 
>   indra/newview/lleventnotifier.h UNKNOWN 
>   indra/newview/llfloaterland.h UNKNOWN 
>   indra/newview/llfloaterland.cpp UNKNOWN 
>   indra/newview/llfloatersnapshot.cpp UNKNOWN 
>   indra/newview/llfolderviewitem.h UNKNOWN 
>   indra/newview/lllocationhistory.h UNKNOWN 
>   indra/newview/lloutputmonitorctrl.h UNKNOWN 
>   indra/newview/llpanelavatar.cpp UNKNOWN 
>   indra/newview/llpanelgroupgeneral.cpp UNKNOWN 
>   indra/newview/llpanelgrouproles.cpp UNKNOWN 
>   indra/newview/llpreviewgesture.cpp UNKNOWN 
>   indra/newview/llsidepaneliteminfo.cpp UNKNOWN 
>   indra/newview/lltooldraganddrop.cpp UNKNOWN 
>   indra/newview/llviewerchat.cpp UNKNOWN 
>   indra/newview/llviewerkeyboard.h UNKNOWN 
>   indra/newview/llviewermenu.cpp UNKNOWN 
>   indra/newview/llviewerparcelmgr.cpp UNKNOWN 
>   indra/newview/llviewerprecompiledheaders.h UNKNOWN 
>   indra/newview/llviewerregion.h UNKNOWN 
>   indra/newview/llviewerregion.cpp UNKNOWN 
>   indra/newview/llviewertexturelist.h UNKNOWN 
>   indra/newview/llviewerwindow.h UNKNOWN 
>   indra/newview/llviewerwindow.cpp UNKNOWN 
>   indra/newview/llvoavatar.cpp UNKNOWN 
>   indra/newview/llvotree.cpp UNKNOWN 
>   indra/newview/llvovolume.cpp UNKNOWN 
>   indra/newview/llworld.cpp UNKNOWN 
>   indra/newview/tests/llremoteparcelrequest_test.cpp UNKNOWN 
>   indra/newview/tests/llviewerhelputil_test.cpp UNKNOWN 
> 
> Diff: http://codereview.secondlife.com/r/297/diff
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> 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

[opensource-dev] Review Request: CHOP-619 fix for pre-compiled headers issue

[Brad Kittenbrink]

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

Review request for Viewer.


Summary
---

Fix for error using precompiled headers with vs2010 and incredibuild 3.60 beta2.

We'll use this opportunity to remove all the special cases we had for working 
around this problem.

resubmitted with the correct patch now...


This addresses bug CHOP-619.
http://jira.secondlife.com/browse/CHOP-619


Diffs
-

  autobuild.xml UNKNOWN 
  build.sh UNKNOWN 
  indra/cmake/00-Common.cmake UNKNOWN 
  indra/cmake/Variables.cmake UNKNOWN 

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


Testing
---

I tested builds personally on windows and linux although the cmake changes can 
only affect windows.

The changes are such that testing the viewer itself is completely unnecessary.  
If it builds, it's good.


Thanks,

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

[opensource-dev] Review Request: Eliminate redundant 'autobuild install' executions when reconfiguring the build

[Brad Kittenbrink]

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

Review request for Viewer.


Summary
---

The use_prebuilt_binary macro handles automated installation of package 
dependencies using autobuild.  The goal is that 'autobuild install' should only 
be run when we know we need to install a new package.

Refactored things a bit to record the required state to achieve this goal.


This addresses bug CHOP-609.
http://jira.secondlife.com/browse/CHOP-609


Diffs
-

  indra/CMakeLists.txt UNKNOWN 
  indra/cmake/Prebuilt.cmake UNKNOWN 

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


Testing
---

Tested the build locally on windows and linux and testing in TC now.


Thanks,

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] Review Request: CHOP-624 header dependency improvements for build time speedup

[Brad Kittenbrink]

> On May 4, 2011, 11:36 a.m., Boroondas Gupte wrote:
> > indra/newview/llviewerregion.cpp, line 835
> > <http://codereview.secondlife.com/r/289/diff/1/?file=1566#file1566line835>
> >
> > Please place spaces around binary operator* .
> 
> Brad Kittenbrink wrote:
> sounds good

on further thought, is this a bug?
should it be 0.5 * (mImpl->mLandp->getMinZ() + mImpl->mLandp->getMaxZ()) 
instead?


- Brad


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


On May 4, 2011, 2:57 p.m., Brad Kittenbrink wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/289/
> ---
> 
> (Updated May 4, 2011, 2:57 p.m.)
> 
> 
> Review request for Viewer.
> 
> 
> Summary
> ---
> 
> Sorry for the big diff here, but reworking a LOT of header dependencies to 
> reduce complexity and help build time.  Started moving stuff out of public 
> interfaces of classes to improve insulation (for example in llviewerregion.h 
> and llagent.h for the biggest examples).
> 
> 
> This addresses bug CHOP-624.
> http://jira.secondlife.com/browse/CHOP-624
> 
> 
> Diffs
> -
> 
>   indra/llcommon/llapp.cpp UNKNOWN 
>   indra/llui/llbutton.h UNKNOWN 
>   indra/llui/llfloaterreg.h UNKNOWN 
>   indra/llui/llfocusmgr.h UNKNOWN 
>   indra/llui/llfocusmgr.cpp UNKNOWN 
>   indra/llui/lliconctrl.h UNKNOWN 
>   indra/llui/lllineeditor.h UNKNOWN 
>   indra/llui/llloadingindicator.h UNKNOWN 
>   indra/llui/llmultislider.cpp UNKNOWN 
>   indra/llui/llpanel.h UNKNOWN 
>   indra/llui/llprogressbar.h UNKNOWN 
>   indra/llui/llprogressbar.cpp UNKNOWN 
>   indra/llui/llslider.h UNKNOWN 
>   indra/llui/llstyle.h UNKNOWN 
>   indra/llui/llstyle.cpp UNKNOWN 
>   indra/llui/lltransutil.cpp UNKNOWN 
>   indra/llui/llui.h UNKNOWN 
>   indra/llui/llview.h UNKNOWN 
>   indra/llui/llviewborder.cpp UNKNOWN 
>   indra/llui/llwindowshade.h UNKNOWN 
>   indra/llxuixml/lltrans.h UNKNOWN 
>   indra/llxuixml/lltrans.cpp UNKNOWN 
>   indra/llxuixml/llxuiparser.h UNKNOWN 
>   indra/newview/llagent.h UNKNOWN 
>   indra/newview/llagent.cpp UNKNOWN 
>   indra/newview/llappviewer.cpp UNKNOWN 
>   indra/newview/lleventnotifier.h UNKNOWN 
>   indra/newview/llfloaterland.h UNKNOWN 
>   indra/newview/llfloaterland.cpp UNKNOWN 
>   indra/newview/llfloatersnapshot.cpp UNKNOWN 
>   indra/newview/llfolderviewitem.h UNKNOWN 
>   indra/newview/lllocationhistory.h UNKNOWN 
>   indra/newview/lloutputmonitorctrl.h UNKNOWN 
>   indra/newview/llpanelavatar.cpp UNKNOWN 
>   indra/newview/llpanelgroupgeneral.cpp UNKNOWN 
>   indra/newview/llpanelgrouproles.cpp UNKNOWN 
>   indra/newview/llpreviewgesture.cpp UNKNOWN 
>   indra/newview/llsidepaneliteminfo.cpp UNKNOWN 
>   indra/newview/lltooldraganddrop.cpp UNKNOWN 
>   indra/newview/llviewerchat.cpp UNKNOWN 
>   indra/newview/llviewerkeyboard.h UNKNOWN 
>   indra/newview/llviewermenu.cpp UNKNOWN 
>   indra/newview/llviewerparcelmgr.cpp UNKNOWN 
>   indra/newview/llviewerprecompiledheaders.h UNKNOWN 
>   indra/newview/llviewerregion.h UNKNOWN 
>   indra/newview/llviewerregion.cpp UNKNOWN 
>   indra/newview/llviewertexturelist.h UNKNOWN 
>   indra/newview/llviewerwindow.h UNKNOWN 
>   indra/newview/llviewerwindow.cpp UNKNOWN 
>   indra/newview/llvoavatar.cpp UNKNOWN 
>   indra/newview/llvotree.cpp UNKNOWN 
>   indra/newview/llvovolume.cpp UNKNOWN 
>   indra/newview/llworld.cpp UNKNOWN 
>   indra/newview/tests/llremoteparcelrequest_test.cpp UNKNOWN 
>   indra/newview/tests/llviewerhelputil_test.cpp UNKNOWN 
> 
> Diff: http://codereview.secondlife.com/r/289/diff
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> 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] Review Request: CHOP-624 header dependency improvements for build time speedup

[Brad Kittenbrink]

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

(Updated May 5, 2011, 5:21 p.m.)


Review request for Viewer.


Changes
---

Uploaded a new version of this patch incorporating some of the suggestions from 
Boroondas


Summary
---

Sorry for the big diff here, but reworking a LOT of header dependencies to 
reduce complexity and help build time.  Started moving stuff out of public 
interfaces of classes to improve insulation (for example in llviewerregion.h 
and llagent.h for the biggest examples).


This addresses bug CHOP-624.
http://jira.secondlife.com/browse/CHOP-624


Diffs (updated)
-

  indra/llcommon/llapp.cpp UNKNOWN 
  indra/llui/llbutton.h UNKNOWN 
  indra/llui/llfloaterreg.h UNKNOWN 
  indra/llui/llfocusmgr.h UNKNOWN 
  indra/llui/llfocusmgr.cpp UNKNOWN 
  indra/llui/lliconctrl.h UNKNOWN 
  indra/llui/lllineeditor.h UNKNOWN 
  indra/llui/llloadingindicator.h UNKNOWN 
  indra/llui/llmultislider.cpp UNKNOWN 
  indra/llui/llpanel.h UNKNOWN 
  indra/llui/llprogressbar.h UNKNOWN 
  indra/llui/llprogressbar.cpp UNKNOWN 
  indra/llui/llslider.h UNKNOWN 
  indra/llui/llstyle.h UNKNOWN 
  indra/llui/llstyle.cpp UNKNOWN 
  indra/llui/lltransutil.cpp UNKNOWN 
  indra/llui/llui.h UNKNOWN 
  indra/llui/llview.h UNKNOWN 
  indra/llui/llviewborder.cpp UNKNOWN 
  indra/llui/llwindowshade.h UNKNOWN 
  indra/llxuixml/lltrans.h UNKNOWN 
  indra/llxuixml/lltrans.cpp UNKNOWN 
  indra/llxuixml/llxuiparser.h UNKNOWN 
  indra/newview/llagent.h UNKNOWN 
  indra/newview/llagent.cpp UNKNOWN 
  indra/newview/llappviewer.cpp UNKNOWN 
  indra/newview/lleventnotifier.h UNKNOWN 
  indra/newview/llfloaterland.h UNKNOWN 
  indra/newview/llfloaterland.cpp UNKNOWN 
  indra/newview/llfloatersnapshot.cpp UNKNOWN 
  indra/newview/llfolderviewitem.h UNKNOWN 
  indra/newview/lllocationhistory.h UNKNOWN 
  indra/newview/lloutputmonitorctrl.h UNKNOWN 
  indra/newview/llpanelavatar.cpp UNKNOWN 
  indra/newview/llpanelgroupgeneral.cpp UNKNOWN 
  indra/newview/llpanelgrouproles.cpp UNKNOWN 
  indra/newview/llpreviewgesture.cpp UNKNOWN 
  indra/newview/llsidepaneliteminfo.cpp UNKNOWN 
  indra/newview/lltooldraganddrop.cpp UNKNOWN 
  indra/newview/llviewerchat.cpp UNKNOWN 
  indra/newview/llviewerkeyboard.h UNKNOWN 
  indra/newview/llviewermenu.cpp UNKNOWN 
  indra/newview/llviewerparcelmgr.cpp UNKNOWN 
  indra/newview/llviewerprecompiledheaders.h UNKNOWN 
  indra/newview/llviewerregion.h UNKNOWN 
  indra/newview/llviewerregion.cpp UNKNOWN 
  indra/newview/llviewertexturelist.h UNKNOWN 
  indra/newview/llviewerwindow.h UNKNOWN 
  indra/newview/llviewerwindow.cpp UNKNOWN 
  indra/newview/llvoavatar.cpp UNKNOWN 
  indra/newview/llvotree.cpp UNKNOWN 
  indra/newview/llvovolume.cpp UNKNOWN 
  indra/newview/llworld.cpp UNKNOWN 
  indra/newview/tests/llremoteparcelrequest_test.cpp UNKNOWN 
  indra/newview/tests/llviewerhelputil_test.cpp UNKNOWN 

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


Testing
---


Thanks,

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] Review Request: CHOP-624 header dependency improvements for build time speedup

[Brad Kittenbrink]

> On May 6, 2011, 3:19 a.m., Boroondas Gupte wrote:
> > No further objections, thus giving my "Ship it". Though, as I know near 
> > nothing about the precompiled header technique and just trust you on the 
> > assertion that these changes are ok if everything still compiles, it'd 
> > probably be good to get a review from at least one more person.
> 
> Boroondas Gupte wrote:
> Oh, wait, due to the diff file mix-up that assertion was probably for the 
> CHOP-619 changes, now under review at 
> https://codereview.secondlife.com/r/299/ , wasn't it? But most changes on 
> review here /do/ look like they should be ok if it still compiles.

Right.


> On May 6, 2011, 3:19 a.m., Boroondas Gupte wrote:
> > indra/newview/llviewerregion.cpp, lines 833-839
> > <http://codereview.secondlife.com/r/289/diff/2/?file=1684#file1684line833>
> >
> > > on further thought, is this a bug?
> > > should it be 0.5 * (mImpl->mLandp->getMinZ() + 
> > mImpl->mLandp->getMaxZ()) instead?
> > 
> > Oh, didn't notice that. Then again, I was merely verifying that you 
> > don't alter functionality, not whether the present functionality makes any 
> > sense.
> > 
> > Looking at the lines above the one in question and the method name, it 
> > might indeed well be that this is a bug and that mdV[VZ] should be set to 
> > the mean of the mLandp's minZ and maxZ. However,
> > 1) without explanatory code comments and/or a specification of this 
> > method, we cannot tell for sure.
> > 2) Even if this is a bug, relying code might to some hackary to 
> > compensate for it, which would lead to overcompensation if this is fixed 
> > only here. So this would need careful further examination, first. (If this 
> > is a bug and isn't compensated for elsewhere, would its effect be 
> > observable somehow? If so, how?)
> > 3) Even if this is a bug, fixing it is out of scope for CHOP-624 and 
> > should not delay/block it.
> > 
> > Conclusion: Good catch, but file a separate jira issue for tracking 
> > investigation and (if needed) fixing of that potential problem.

Totally agreed.


> On May 6, 2011, 3:19 a.m., Boroondas Gupte wrote:
> > indra/newview/llviewerwindow.cpp, line 248
> > <http://codereview.secondlife.com/r/289/diff/2/?file=1687#file1687line248>
> >
> > Just to make sure, as 'static' is that silly C++ keyword with 3 
> > different meanings depending on context: Here you're limiting visibility of 
> > the constant to file scope, aren't you? Is that the right thing to do with 
> > it, rather than placing it in a namespace or class? Should the same be done 
> > for some of the other constants around here? (I saw you did it for one 
> > more.)

Correct, I want to limit them to file scope.  In particular after I had removed 
the corresponding declarations from the header for a lot of these constants, I 
knew they weren't being used anywhere else, so making them part of the class's 
public interface seemed counterproductive.  Ideally I'd like to delete a lot of 
this kind of code.

Anyways, in my experience, certain optimizations get made to static const 
values that often do not get made for constants in unnamed namespaces, and the 
like (although this likely no longer applies with "modern" compilers).  Part of 
my ongoing build time optimization work in CHOP-609 is to reduce the number of 
extern symbols that the linker has to deal with, and this is the easiest way to 
do that in cases where it can be used.


- Brad


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


On May 5, 2011, 5:21 p.m., Brad Kittenbrink wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/289/
> ---
> 
> (Updated May 5, 2011, 5:21 p.m.)
> 
> 
> Review request for Viewer.
> 
> 
> Summary
> ---
> 
> Sorry for the big diff here, but reworking a LOT of header dependencies to 
> reduce complexity and help build time.  Started moving stuff out of public 
> interfaces of classes to improve insulation (for example in llviewerregion.h 
> and llagent.h for the biggest examples).
> 
> 
> This addresses bug CHOP-624.
> http://jira.secondlife.com/browse/CHOP-624
> 
> 
> Diffs
> -
> 
>   indra/llcommon/llapp.cpp 

Re: [opensource-dev] Review Request: CHOP-624 header dependency improvements for build time speedup

[Brad Kittenbrink]

> On May 6, 2011, 3:19 a.m., Boroondas Gupte wrote:
> > indra/newview/llviewerregion.cpp, lines 833-839
> > <http://codereview.secondlife.com/r/289/diff/2/?file=1684#file1684line833>
> >
> > > on further thought, is this a bug?
> > > should it be 0.5 * (mImpl->mLandp->getMinZ() + 
> > mImpl->mLandp->getMaxZ()) instead?
> > 
> > Oh, didn't notice that. Then again, I was merely verifying that you 
> > don't alter functionality, not whether the present functionality makes any 
> > sense.
> > 
> > Looking at the lines above the one in question and the method name, it 
> > might indeed well be that this is a bug and that mdV[VZ] should be set to 
> > the mean of the mLandp's minZ and maxZ. However,
> > 1) without explanatory code comments and/or a specification of this 
> > method, we cannot tell for sure.
> > 2) Even if this is a bug, relying code might to some hackary to 
> > compensate for it, which would lead to overcompensation if this is fixed 
> > only here. So this would need careful further examination, first. (If this 
> > is a bug and isn't compensated for elsewhere, would its effect be 
> > observable somehow? If so, how?)
> > 3) Even if this is a bug, fixing it is out of scope for CHOP-624 and 
> > should not delay/block it.
> > 
> > Conclusion: Good catch, but file a separate jira issue for tracking 
> > investigation and (if needed) fixing of that potential problem.
> 
> Brad Kittenbrink wrote:
> Totally agreed.
> 
> Boroondas Gupte wrote:
> Please link to that new jira once it's filed. I'm curious what'll become 
> of that topic.

finally got around to writing this up: 
https://jira.secondlife.com/browse/VWR-25719


- Brad


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


On May 5, 2011, 5:21 p.m., Brad Kittenbrink wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/289/
> ---
> 
> (Updated May 5, 2011, 5:21 p.m.)
> 
> 
> Review request for Viewer.
> 
> 
> Summary
> ---
> 
> Sorry for the big diff here, but reworking a LOT of header dependencies to 
> reduce complexity and help build time.  Started moving stuff out of public 
> interfaces of classes to improve insulation (for example in llviewerregion.h 
> and llagent.h for the biggest examples).
> 
> 
> This addresses bug CHOP-624.
> http://jira.secondlife.com/browse/CHOP-624
> 
> 
> Diffs
> -
> 
>   indra/llcommon/llapp.cpp UNKNOWN 
>   indra/llui/llbutton.h UNKNOWN 
>   indra/llui/llfloaterreg.h UNKNOWN 
>   indra/llui/llfocusmgr.h UNKNOWN 
>   indra/llui/llfocusmgr.cpp UNKNOWN 
>   indra/llui/lliconctrl.h UNKNOWN 
>   indra/llui/lllineeditor.h UNKNOWN 
>   indra/llui/llloadingindicator.h UNKNOWN 
>   indra/llui/llmultislider.cpp UNKNOWN 
>   indra/llui/llpanel.h UNKNOWN 
>   indra/llui/llprogressbar.h UNKNOWN 
>   indra/llui/llprogressbar.cpp UNKNOWN 
>   indra/llui/llslider.h UNKNOWN 
>   indra/llui/llstyle.h UNKNOWN 
>   indra/llui/llstyle.cpp UNKNOWN 
>   indra/llui/lltransutil.cpp UNKNOWN 
>   indra/llui/llui.h UNKNOWN 
>   indra/llui/llview.h UNKNOWN 
>   indra/llui/llviewborder.cpp UNKNOWN 
>   indra/llui/llwindowshade.h UNKNOWN 
>   indra/llxuixml/lltrans.h UNKNOWN 
>   indra/llxuixml/lltrans.cpp UNKNOWN 
>   indra/llxuixml/llxuiparser.h UNKNOWN 
>   indra/newview/llagent.h UNKNOWN 
>   indra/newview/llagent.cpp UNKNOWN 
>   indra/newview/llappviewer.cpp UNKNOWN 
>   indra/newview/lleventnotifier.h UNKNOWN 
>   indra/newview/llfloaterland.h UNKNOWN 
>   indra/newview/llfloaterland.cpp UNKNOWN 
>   indra/newview/llfloatersnapshot.cpp UNKNOWN 
>   indra/newview/llfolderviewitem.h UNKNOWN 
>   indra/newview/lllocationhistory.h UNKNOWN 
>   indra/newview/lloutputmonitorctrl.h UNKNOWN 
>   indra/newview/llpanelavatar.cpp UNKNOWN 
>   indra/newview/llpanelgroupgeneral.cpp UNKNOWN 
>   indra/newview/llpanelgrouproles.cpp UNKNOWN 
>   indra/newview/llpreviewgesture.cpp UNKNOWN 
>   indra/newview/llsidepaneliteminfo.cpp UNKNOWN 
>   indra/newview/lltooldraganddrop.cpp UNKNOWN 
>   indra/newview/llviewerchat.cpp UNKNOWN 
>   indra/newview/llviewerkeyboard.h UNKNOWN 
>   indra/newview/llviewermenu.cpp UNKNOWN 
>   indra/newview/llviewerparcelmgr.cpp UNKNOWN 
>   indra/newvie

[opensource-dev] Review Request: Cleaning up testing cmake macros to prepare for refactoring them to improve build time.

[Brad Kittenbrink]

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

Review request for Viewer.


Summary
---

Consolidating all references to the LL_TESTS config var in one file to make the 
logic surrounding it more cohesive.


This addresses bug CHOP-609.
http://jira.secondlife.com/browse/CHOP-609


Diffs
-

  indra/cmake/LLAddBuildTest.cmake UNKNOWN 
  indra/cmake/LLTestCommand.cmake UNKNOWN 
  indra/llcharacter/CMakeLists.txt UNKNOWN 
  indra/llcommon/CMakeLists.txt UNKNOWN 
  indra/llimage/CMakeLists.txt UNKNOWN 
  indra/llinventory/CMakeLists.txt UNKNOWN 
  indra/llkdu/CMakeLists.txt UNKNOWN 
  indra/llmath/CMakeLists.txt UNKNOWN 
  indra/llmessage/CMakeLists.txt UNKNOWN 
  indra/llplugin/CMakeLists.txt UNKNOWN 
  indra/llprimitive/CMakeLists.txt UNKNOWN 
  indra/llui/CMakeLists.txt UNKNOWN 
  indra/llvfs/CMakeLists.txt UNKNOWN 
  indra/llxml/CMakeLists.txt UNKNOWN 
  indra/newview/CMakeLists.txt UNKNOWN 
  indra/viewer_components/login/CMakeLists.txt UNKNOWN 
  indra/viewer_components/updater/CMakeLists.txt UNKNOWN 

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


Testing
---

I've tested with LL_TESTS=ON, but I'd like some help from people who use this 
feature testing with LL_TESTS=OFF to make sure I haven't missed anything.


Thanks,

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

[opensource-dev] Review Request: CHOP-658 moving panels and floaters into a new static library project viewer_components/viewerui

[Brad Kittenbrink]

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

Review request for Viewer and Richard Nelson.


Summary
---

Started moving panel and floater classes into a new static library project in 
an effort to start promoting better insulation between model and view sections 
of the viewer codebase.  This is in preparation for further work breaking 
header dependencies along the lines of CHOP-624


This addresses bug CHOP-658.
http://jira.secondlife.com/browse/CHOP-658


Diffs
-

  indra/cmake/LLViewerUI.cmake PRE-CREATION 
  indra/newview/CMakeLists.txt UNKNOWN 
  indra/newview/llfloaterabout.h UNKNOWN 
  indra/newview/llfloaterabout.cpp UNKNOWN 
  indra/newview/llfloateranimpreview.h UNKNOWN 
  indra/newview/llfloateranimpreview.cpp UNKNOWN 
  indra/newview/llfloaterauction.h UNKNOWN 
  indra/newview/llfloaterauction.cpp UNKNOWN 
  indra/newview/llfloateravatarpicker.h UNKNOWN 
  indra/newview/llfloateravatarpicker.cpp UNKNOWN 
  indra/newview/llfloateravatartextures.h UNKNOWN 
  indra/newview/llfloateravatartextures.cpp UNKNOWN 
  indra/newview/llfloaterbeacons.h UNKNOWN 
  indra/newview/llfloaterbeacons.cpp UNKNOWN 
  indra/newview/llfloaterbuildoptions.h UNKNOWN 
  indra/newview/llfloaterbuildoptions.cpp UNKNOWN 
  indra/newview/llfloaterbulkpermission.h UNKNOWN 
  indra/newview/llfloaterbulkpermission.cpp UNKNOWN 
  indra/newview/llfloaterbump.h UNKNOWN 
  indra/newview/llfloaterbump.cpp UNKNOWN 
  indra/newview/llfloaterbuy.h UNKNOWN 
  indra/newview/llfloaterbuy.cpp UNKNOWN 
  indra/newview/llfloaterbuycontents.h UNKNOWN 
  indra/newview/llfloaterbuycontents.cpp UNKNOWN 
  indra/newview/llfloaterbuycurrency.h UNKNOWN 
  indra/newview/llfloaterbuycurrency.cpp UNKNOWN 
  indra/newview/llfloaterbuycurrencyhtml.h UNKNOWN 
  indra/newview/llfloaterbuycurrencyhtml.cpp UNKNOWN 
  indra/newview/llfloaterbuyland.h UNKNOWN 
  indra/newview/llfloaterbuyland.cpp UNKNOWN 
  indra/newview/llfloatercamera.h UNKNOWN 
  indra/newview/llfloatercamera.cpp UNKNOWN 
  indra/newview/llfloaterchat.h UNKNOWN 
  indra/newview/llfloaterchat.cpp UNKNOWN 
  indra/newview/llfloaterchatterbox.h UNKNOWN 
  indra/newview/llfloaterchatterbox.cpp UNKNOWN 
  indra/newview/llfloatercolorpicker.h UNKNOWN 
  indra/newview/llfloatercolorpicker.cpp UNKNOWN 
  indra/newview/llfloaterdaycycle.h UNKNOWN 
  indra/newview/llfloaterdaycycle.cpp UNKNOWN 
  indra/newview/llfloaterdisplayname.h UNKNOWN 
  indra/newview/llfloaterdisplayname.cpp UNKNOWN 
  indra/newview/llfloaterenvsettings.h UNKNOWN 
  indra/newview/llfloaterenvsettings.cpp UNKNOWN 
  indra/newview/llfloaterevent.h UNKNOWN 
  indra/newview/llfloaterevent.cpp UNKNOWN 
  indra/newview/llfloaterfonttest.h UNKNOWN 
  indra/newview/llfloaterfonttest.cpp UNKNOWN 
  indra/newview/llfloaterfriends.h UNKNOWN 
  indra/newview/llfloaterfriends.cpp UNKNOWN 
  indra/newview/llfloatergesture.h UNKNOWN 
  indra/newview/llfloatergesture.cpp UNKNOWN 
  indra/newview/llfloatergodtools.h UNKNOWN 
  indra/newview/llfloatergodtools.cpp UNKNOWN 
  indra/newview/llfloatergroupinvite.h UNKNOWN 
  indra/newview/llfloatergroupinvite.cpp UNKNOWN 
  indra/newview/llfloatergroups.h UNKNOWN 
  indra/newview/llfloatergroups.cpp UNKNOWN 
  indra/newview/llfloaterhandler.h UNKNOWN 
  indra/newview/llfloaterhandler.cpp UNKNOWN 
  indra/newview/llfloaterhardwaresettings.h UNKNOWN 
  indra/newview/llfloaterhardwaresettings.cpp UNKNOWN 
  indra/newview/llfloaterhelpbrowser.h UNKNOWN 
  indra/newview/llfloaterhelpbrowser.cpp UNKNOWN 
  indra/newview/llfloaterhud.h UNKNOWN 
  indra/newview/llfloaterhud.cpp UNKNOWN 
  indra/newview/llfloaterimagepreview.h UNKNOWN 
  indra/newview/llfloaterimagepreview.cpp UNKNOWN 
  indra/newview/llfloaterinspect.h UNKNOWN 
  indra/newview/llfloaterinspect.cpp UNKNOWN 
  indra/newview/llfloaterinventory.h UNKNOWN 
  indra/newview/llfloaterinventory.cpp UNKNOWN 
  indra/newview/llfloaterjoystick.h UNKNOWN 
  indra/newview/llfloaterjoystick.cpp UNKNOWN 
  indra/newview/llfloaterlagmeter.h UNKNOWN 
  indra/newview/llfloaterlagmeter.cpp UNKNOWN 
  indra/newview/llfloaterland.h UNKNOWN 
  indra/newview/llfloaterland.cpp UNKNOWN 
  indra/newview/llfloaterlandholdings.h UNKNOWN 
  indra/newview/llfloaterlandholdings.cpp UNKNOWN 
  indra/newview/llfloatermap.h UNKNOWN 
  indra/newview/llfloatermap.cpp UNKNOWN 
  indra/newview/llfloatermediabrowser.h UNKNOWN 
  indra/newview/llfloatermediabrowser.cpp UNKNOWN 
  indra/newview/llfloatermediasettings.h UNKNOWN 
  indra/newview/llfloatermediasettings.cpp UNKNOWN 
  indra/newview/llfloatermemleak.h UNKNOWN 
  indra/newview/llfloatermemleak.cpp UNKNOWN 
  indra/newview/llfloaternamedesc.h UNKNOWN 
  indra/newview/llfloaternamedesc.cpp UNKNOWN 
  indra/newview/llfloaternotificationsconsole.h UNKNOWN 
  indra/newview/llfloaternotificationsconsole.cpp UNKNOWN 
  indra/newview/llfl

Re: [opensource-dev] Review Request: Correctly identify Server 2008, Server 2008 R2, Server 2012, and Windows 8

[Brad Kittenbrink]

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

Ship it!


Looks good to me

- Brad


On May 17, 2011, 9:31 a.m., tankmaster.finesmith wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/311/
> ---
> 
> (Updated May 17, 2011, 9:31 a.m.)
> 
> 
> Review request for Viewer.
> 
> 
> Summary
> ---
> 
> The stated OS in help -> about for server 2008 and server 2008 R2 is 
> inaccurate.  It shows up as "Microsoft Windows Vista Server" or "Microsoft 
> Windows 7 Server" instead of "Microsoft Server 2008" or "Microsoft Server 
> 2008 R2" respectively.  This patch corrects the text display error and also 
> adds support for "Microsoft Server 2012" and "Microsoft Windows 8" which I 
> have confirmed works on those OSs.  I came to this work by mimicking the code 
> logic for how server 2003 was handled.
> 
> This patch does not correct the error of XP always showing up as running in 
> compatibility mode.  This also doesn’t affect the redundant display of x64 
> for Server 2008 R2 and Server 2012, which are only available in 64bit 
> versions.
> 
> I have applied my patch to my clone of viewer-dev at 
> https://bitbucket.org/Tank_Master/storm-1258/changeset/f4b293bbdedf and my 
> initial firestorm commit can be found at 
> http://hg.phoenixviewer.com/phoenix-firestorm-lgpl/rev/6bf2de50ea83 
> 
> 
> This addresses bug STORM-1258.
> http://jira.secondlife.com/browse/STORM-1258
> 
> 
> Diffs
> -
> 
>   indra/llcommon/llsys.cpp ddfc2ed6aee1 
> 
> Diff: http://codereview.secondlife.com/r/311/diff
> 
> 
> Testing
> ---
> 
> I made this patch for Firestorm, where it was applied and tested initially 
> and no errors have been found.
> 
> 
> Thanks,
> 
> tankmaster.finesmith
> 
>

___
Policies 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: CHOP-658 moving panels and floaters into a new static library project viewer_components/viewerui

[Brad Kittenbrink]

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

(Updated May 20, 2011, 4:04 p.m.)


Review request for Viewer and Richard Nelson.


Changes
---

Ok, I tried to redo the file moves correctly as Thomas suggested.  Maybe the 
diff will look a little better this time?

anyways the results are here 
https://bitbucket.org/brad_linden/viewer-mustbuildfaster-2

mustbuildfaster-1 is now a dead end.  I haven't looked into any of the side 
panel failures yet.


Summary
---

Started moving panel and floater classes into a new static library project in 
an effort to start promoting better insulation between model and view sections 
of the viewer codebase.  This is in preparation for further work breaking 
header dependencies along the lines of CHOP-624


This addresses bug CHOP-658.
http://jira.secondlife.com/browse/CHOP-658


Diffs (updated)
-

  indra/cmake/LLViewerUI.cmake PRE-CREATION 
  indra/newview/CMakeLists.txt UNKNOWN 
  indra/newview/llfloaterabout.h UNKNOWN 
  indra/newview/llfloaterabout.cpp UNKNOWN 
  indra/newview/llfloateranimpreview.h UNKNOWN 
  indra/newview/llfloateranimpreview.cpp UNKNOWN 
  indra/newview/llfloaterauction.h UNKNOWN 
  indra/newview/llfloaterauction.cpp UNKNOWN 
  indra/newview/llfloateravatarpicker.h UNKNOWN 
  indra/newview/llfloateravatarpicker.cpp UNKNOWN 
  indra/newview/llfloateravatartextures.h UNKNOWN 
  indra/newview/llfloateravatartextures.cpp UNKNOWN 
  indra/newview/llfloaterbeacons.h UNKNOWN 
  indra/newview/llfloaterbeacons.cpp UNKNOWN 
  indra/newview/llfloaterbuildoptions.h UNKNOWN 
  indra/newview/llfloaterbuildoptions.cpp UNKNOWN 
  indra/newview/llfloaterbulkpermission.h UNKNOWN 
  indra/newview/llfloaterbulkpermission.cpp UNKNOWN 
  indra/newview/llfloaterbump.h UNKNOWN 
  indra/newview/llfloaterbump.cpp UNKNOWN 
  indra/newview/llfloaterbuy.h UNKNOWN 
  indra/newview/llfloaterbuy.cpp UNKNOWN 
  indra/newview/llfloaterbuycontents.h UNKNOWN 
  indra/newview/llfloaterbuycontents.cpp UNKNOWN 
  indra/newview/llfloaterbuycurrency.h UNKNOWN 
  indra/newview/llfloaterbuycurrency.cpp UNKNOWN 
  indra/newview/llfloaterbuycurrencyhtml.h UNKNOWN 
  indra/newview/llfloaterbuycurrencyhtml.cpp UNKNOWN 
  indra/newview/llfloaterbuyland.h UNKNOWN 
  indra/newview/llfloaterbuyland.cpp UNKNOWN 
  indra/newview/llfloatercamera.h UNKNOWN 
  indra/newview/llfloatercamera.cpp UNKNOWN 
  indra/newview/llfloaterchat.h UNKNOWN 
  indra/newview/llfloaterchat.cpp UNKNOWN 
  indra/newview/llfloaterchatterbox.h UNKNOWN 
  indra/newview/llfloaterchatterbox.cpp UNKNOWN 
  indra/newview/llfloatercolorpicker.h UNKNOWN 
  indra/newview/llfloatercolorpicker.cpp UNKNOWN 
  indra/newview/llfloaterdaycycle.h UNKNOWN 
  indra/newview/llfloaterdaycycle.cpp UNKNOWN 
  indra/newview/llfloaterdisplayname.h UNKNOWN 
  indra/newview/llfloaterdisplayname.cpp UNKNOWN 
  indra/newview/llfloaterenvsettings.h UNKNOWN 
  indra/newview/llfloaterenvsettings.cpp UNKNOWN 
  indra/newview/llfloaterevent.h UNKNOWN 
  indra/newview/llfloaterevent.cpp UNKNOWN 
  indra/newview/llfloaterfonttest.h UNKNOWN 
  indra/newview/llfloaterfonttest.cpp UNKNOWN 
  indra/newview/llfloaterfriends.h UNKNOWN 
  indra/newview/llfloaterfriends.cpp UNKNOWN 
  indra/newview/llfloatergesture.h UNKNOWN 
  indra/newview/llfloatergesture.cpp UNKNOWN 
  indra/newview/llfloatergodtools.h UNKNOWN 
  indra/newview/llfloatergodtools.cpp UNKNOWN 
  indra/newview/llfloatergroupinvite.h UNKNOWN 
  indra/newview/llfloatergroupinvite.cpp UNKNOWN 
  indra/newview/llfloatergroups.h UNKNOWN 
  indra/newview/llfloatergroups.cpp UNKNOWN 
  indra/newview/llfloaterhandler.h UNKNOWN 
  indra/newview/llfloaterhandler.cpp UNKNOWN 
  indra/newview/llfloaterhardwaresettings.h UNKNOWN 
  indra/newview/llfloaterhardwaresettings.cpp UNKNOWN 
  indra/newview/llfloaterhelpbrowser.h UNKNOWN 
  indra/newview/llfloaterhelpbrowser.cpp UNKNOWN 
  indra/newview/llfloaterhud.h UNKNOWN 
  indra/newview/llfloaterhud.cpp UNKNOWN 
  indra/newview/llfloaterimagepreview.h UNKNOWN 
  indra/newview/llfloaterimagepreview.cpp UNKNOWN 
  indra/newview/llfloaterinspect.h UNKNOWN 
  indra/newview/llfloaterinspect.cpp UNKNOWN 
  indra/newview/llfloaterinventory.h UNKNOWN 
  indra/newview/llfloaterinventory.cpp UNKNOWN 
  indra/newview/llfloaterjoystick.h UNKNOWN 
  indra/newview/llfloaterjoystick.cpp UNKNOWN 
  indra/newview/llfloaterlagmeter.h UNKNOWN 
  indra/newview/llfloaterlagmeter.cpp UNKNOWN 
  indra/newview/llfloaterland.h UNKNOWN 
  indra/newview/llfloaterland.cpp UNKNOWN 
  indra/newview/llfloaterlandholdings.h UNKNOWN 
  indra/newview/llfloaterlandholdings.cpp UNKNOWN 
  indra/newview/llfloatermap.h UNKNOWN 
  indra/newview/llfloatermap.cpp UNKNOWN 
  indra/newview/llfloatermediabrowser.h UNKNOWN 
  indra/newview/llfloatermediabrowser.cpp UNKNOWN 
  indra/newview/llfloatermediasettings.h UNKNOW

Re: [opensource-dev] Autoupdater Flashback

[Brad Kittenbrink (Brad Linden)]

I have posted this info here:
https://wiki.secondlife.com/wiki/Viewer_Update_Service/Protocol

-Brad

On Wed, Dec 1, 2010 at 6:46 AM, Kitty  wrote:

> Would it be possible to get the protocol specification for the updater
> service on the server-side?
>
>
>
> It’s always possible to work backwards from the code in the viewer, but it
> would be handy to just have an overview of the viewer<->web service
> exchanges :).
>
>
>
> Kitty
>
>
>
> *From:* opensource-dev-boun...@lists.secondlife.com [mailto:
> opensource-dev-boun...@lists.secondlife.com] *On Behalf Of *Brad
> Kittenbrink (Brad Linden)
> *Sent:* dinsdag 30 november 2010 22:34
> *To:* Bunny Halberd
> *Cc:* opensource-dev@lists.secondlife.com
> *Subject:* Re: [opensource-dev] Autoupdater Flashback
>
>
>
> Oops, thanks for the heads-up.
>
> The background updater is new in viewer 2.4 (as it's not released in beta
> yet, it doesn't have release notes yet, so sorry for the surprise).
> Yesterday we deployed the server side work in preparation for the beginning
> of the 2.4 beta releases, and it turned on.  Unfortunately we hadn't been
> paying attention to the Second Life Development channel, and there was some
> obsolete data in the database.
>
> Anyways, thanks again for testing this for us.  We should be getting it
> fixed shortly.
>
> -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] google-breakpad VS2010 build project. Linden Dev Help Please.

[Brad Kittenbrink (Brad Linden)]

On Fri, Jan 21, 2011 at 6:40 PM, Nicky Perian  wrote:

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

Yes, it's for automation.   The shell function build_sln is part of our new
third party lib build system which we're starting to document here:
http://wiki.secondlife.com/wiki/Autobuild and here:
http://wiki.secondlife.com/wiki/Autobuild_How_To

You're a bit ahead of the curve, and we haven't quite kicked all of this off
with great fanfare just yet.  But thanks for diving in fearlessly :)

If you want to run the build, in theory you should just need to check out
our autobuild repository , put its
bin directory in your PATH, and run 'autobuild install && autobuild build &&
autobuild package'

Anyways, in addition to that, a simple substitute definition for the
function is as follows:
build_sln() {
local solution=$1
local config=$2
local proj=$3

if [ -z "$proj" ] ; then
devenv.com "$(cygpath -m "$solution")" /build "$config"
else
devenv.com "$(cygpath -m "$solution")" /build "$config" /project
"$proj"
fi
}

-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

[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] autobuild setting UNATTENDED questions

[Brad Kittenbrink (Brad Linden)]

On Fri, Mar 25, 2011 at 11:04 AM, Ima Mechanique <
ima.mechani...@blueyonder.co.uk> wrote:

> I'm trying to find out more information about this setting and the piece
> of code it controls. Non Windows devs can switch off now as it only
> affects them by causing a warning about it not being used.
>
> 1) Is it still needed. All configurations, even the TC ones, have it
> defaulting to off. This causes problems for VCE devs as the vstools
> program controlled by it causes an error for them.
> It's purpose appears to be to set the working directory for running the
> .exe. However, the .exe runs just fine without it being set.
>


The working directory setting may no longer be necessary after this
change.
If so, that's good news.  However, I believe that we also use it for setting
the default configuration to RelWithDebInfo, which we still require.


2) If it really is necessary, could we change the program run (vstools)
> to something more compatible with all VC versions. Now the project files
> are XML based, it should be possible to do this as part of autobuild
> itself.
>
>
The source for vstool is
here.
(Yes, it's C#, don't ask me...)  If there's a way to make it compatible with
VCExpress I'd love to do so, but to my knowledge VCExpress doesn't expose
the macro apis that this relies upon, so it's likely impossible to directly
extend that script to this case.  I don't think it makes sense to build
support for tweaking these xml files into autobuild, as autobuild is
intended to be as fully decoupled from the details of individual build
systems as possible.

An alternative is getting this kind of feature built into cmake.  For
example, this issue  is a
feature request for making another kind of modification to the
*.vcproj.*.user configuration file where these settings are saved.

In the mean time, I would definitely recommend updating the VCExpress
configurations to pass -DUNATTENDED:BOOL=ON on the command line until we
find a better solution for this.  We used to do a lot more with the
--unattended argument to develop.py, but I think this is all that remains of
that cruft, so it's safe to use for this purpose.

-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] autobuild setting UNATTENDED questions

[Brad Kittenbrink (Brad Linden)]

Sorry I let this sit for a while without replying, here are my thoughts:

On Sat, Mar 26, 2011 at 7:18 AM, Ima Mechanique <
ima.mechani...@blueyonder.co.uk> wrote:

> Thanks for replying Brad
>
> > The working directory setting may no longer be necessary after this
> > change<
> https://bitbucket.org/merov_linden/viewer-autobuild2010/changeset/339c25d7046e
> >.
> > If so, that's good news.  However, I believe that we also use it for
> setting
> > the default configuration to RelWithDebInfo, which we still require.
>
> Could you expand on this? I'm assuming the "it" is vstool or UNATTENDED,
> but the only other references to either I can find in the source tree
> are part of the autobuild.xml configuration for Debug, RelWithDebInfo,
> and Release (which do seem to be setting configuration type for startup).
> If that is what you're referring to, then the CMakeLists.txt part could
> be safely removed and OS devs could remain happily oblivious to its use?
>

By 'it', I was referring to vstool.  The UNATTENDED variable is required to
support the enabling and disabling of that vstoool block of CMake code in
indra/newview/CMakeLists.txt.  We do not intend to delete that block of
code, as I said, that functionality is still required.  Frankly, VCExpress
devs need to support their own tools properly here, so they cannot be
oblivious to this until we get patches that solve these issues.  For now
this information has to be specified manually and the UNATTENDED variable is
as fine an interface as any for that now.  If someone discovered a builtin
CMake variable for automatically detecting whether the visual studio
installation is Express or Professional, then we should use that instead of
manually specifying this with UNATTENDED, but I'm not aware of one.


> > 2) If it really is necessary, could we change the program run (vstools)
> > > to something more compatible with all VC versions. Now the project
> files
> > > are XML based, it should be possible to do this as part of autobuild
> > > itself.
> > >
> > >
> > The source for vstool is
> > here<
> https://bitbucket.org/merov_linden/viewer-autobuild2010/src/tip/indra/tools/vstool/main.cs
> >.
> > (Yes, it's C#, don't ask me...)  If there's a way to make it compatible
> with
> > VCExpress I'd love to do so, but to my knowledge VCExpress doesn't expose
> > the macro apis that this relies upon, so it's likely impossible to
> directly
> > extend that script to this case.  I don't think it makes sense to build
> > support for tweaking these xml files into autobuild, as autobuild is
> > intended to be as fully decoupled from the details of individual build
> > systems as possible.
>
> Agreed about autobuild, I was thinking something like a python script
> that autobuild/cmake could use instead of vstool. However, it seems
> this is unnecessary now.
>

I strongly doubt that such a python script would be a better solution than
vstool.   We've got code that works for all VCPro developers that require
this functionality, and we have a good way to disable this functionality for
VCExpress developers who don't require it.  I don't think it's a good use of
our time to do anything more than that.


> > An alternative is getting this kind of feature built into cmake.  For
> > example, this issue  is
> a
> > feature request for making another kind of modification to the
> > *.vcproj.*.user configuration file where these settings are saved.
> >
> > In the mean time, I would definitely recommend updating the VCExpress
> > configurations to pass -DUNATTENDED:BOOL=ON on the command line until we
> > find a better solution for this.
>
> Already done and in my repo, although it's not a "VC Express"
> configuration it's for any OS VC 2010
>

Cool, sounds good.


>  > We used to do a lot more with the
> > --unattended argument to develop.py, but I think this is all that remains
> of
> > that cruft, so it's safe to use for this purpose.
>
> So if the autobuild.xml is what you were referring to above,  could we
> safely
> remove all references to UNATTENDED (TC and OS), and remove lines 1581 -
> 1594 from indra/newview/CMakeLists.txt?
>

No.
The UNATTENDED variable is the preffered way to configure whether vstool is
used or not.  Those lines are still required.  Again, I'd prefer cmake
included some automatic variable for detecting this, but what we have works.

-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] Review Request: CHOP-658 moving panels and floaters into a new static library project viewer_components/viewerui

[Brad Kittenbrink (Brad Linden)]

On Tue, May 17, 2011 at 8:17 AM, Ardy Lay  wrote:

>  On 5/16/2011 9:04 PM, Brad Kittenbrink wrote:
>
> It's also availible on 
> bitbucket(https://bitbucket.org/brad_linden/viewer-mustbuildfaster-1/changeset/25c39e3d8a88)
>  for testing in TeamCity.
>
>  Brad, is the TeamCity build result listed anywhere yet?
>
> I pulled from your viewer-mustbuildfaster-1 at commit 16171 - 6f777a541bf6
> and built it in 19 minutes without tests.  BUT... when I logged in I find
> an empty "MY FRIENDS" list.  "No matches found".  Heh, that might scare
> somebody.  ;-)
>
>
http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repo/brad_viewer-mustbuildfaster-1/rev/230029/index.html

 I'll take a look at the friends list and other side panel issues that
wolfpup mentions.  Thanks for testing!

-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] Review Request: CHOP-658 moving panels and floaters into a new static library project viewer_components/viewerui

[Brad Kittenbrink (Brad Linden)]

On Tue, May 17, 2011 at 12:42 PM, WolfPup Lowenhar
wrote:

> I also built this repository locally but from the tip and my build time
> which was a full standard build including all test took 2hrs and 22min this
> is actually 8 minutes longer that a viewer development build currently. Also
> only one of the side panels works and that is the inventory side panel.
>

Well, there are definitely further optimizations to be made here as well.
Rightt now the new viewerui project isn't using precompiled headers yet, so
that could explain why the build is taking longer.  Hopefully reenabling pch
with a new header file specifically tuned for the viewerui project will give
even bigger gains.

-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] Snowglobe Mecurial Repository

[Brad Kittenbrink (Brad Linden)]

On Fri, Mar 19, 2010 at 4:47 PM, Jacek Antonelli
wrote:

> On Fri, Mar 19, 2010 at 1:13 PM, Carlo Wood  wrote:
> > Actually, I think I understand why.
> >
> > LL is using hg internally, and has been for a while.
> > They just pushed things out as svn for public access, but that process
> > caused all the meta data to be lost and had to be done manually, and
> > therefore only sometimes in big large chunks.
> >
> > It is for the benefit of snowglobe that commits to the internal
> > repository are available with meta data and as the original change sets,
> > once they are merged with the public repository.
> >
> > With hg this is possible: just push the changeset to the "public
> > hg repository", but only if that public repository run hg itself.
> >
> > On top of that, merging branches is much easier (according to
> > http://hginit.com/00.html), that holds for merging changes from internal
> > into snowglobe but also for TPV's assuming they switch to hg as well.
> > It should become much easier for us and for others using hg to merge
> > 'upstream' changes with the ever growning set of local patches and
> > extensions.
>
> Yep, I would guess those are all some of LL's reasons for switching
> away from SVN.
>
> Also, speaking from my experience using SVN for several years before
> switching to Git (which is close enough to Hg), using a distributed
> version control system just changes the way you work, and the way you
> think about version control and software development. Personally, I
> think that mental shift is even more important than the new features
> and tools and easy merges (which are also very nice, of course).
>
> Think of the old lock-based systems, where one team member would
> "check out" a file, and no one else could edit it until they were
> done. Once people switched to systems like CVS or SVN that let all the
> developers keep working without blocking each other (as much), it
> really altered and improved how software was developed and how teams
> worked together. Distributed systems take this to the next step, and
> again it alters and improves the way developers work and collaborate.
>
> Plus everything's just way faster. :-D I never realized how much time
> I spent waiting for a SVN commit to finish -- or even checking the log
> -- until I used Git. Now I'm completely spoiled, and waiting 10
> seconds to contact the server just to look at the log, or 30 seconds
> (or even minutes (!) for big changes) to commit feels like an eternity
> to me. It may seem like a little thing, but it feels so much nicer
> when nearly every operation is near-instantaneous.
>
> - Jacek
>

also, some of us use hg-git internally, http://hg-git.github.com/

I won't comment on which direction we're converting things. ;)

-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] SG2 Build with VC++ Express VC90.

[Brad Kittenbrink (Brad Linden)]

On Tue, Mar 30, 2010 at 9:44 PM, Philippe (Merov) Bossut <
me...@lindenlab.com> wrote:

> Hi NickyP,
>
> On Tue, Mar 30, 2010 at 7:28 PM, William Nickels wrote:
>
>> I have been building SG2 with VC++ Express 2008 (VC90) using boost
>> libraries version 1-36. I have completed the build of secondlife-bin.exe and
>> it runs error free. However, when I attampt ALL_BUILD and try to build
>> setup.exe I encounter dependency issues with the build trying to use VC80
>> microsoft DLL's. Being new,  I can't seem to find the cmake file or python
>> script or other files that generate these incorrect dependencies. I need
>> help.
>>
>
> SG2 is no different from SG1.x with respect to building.
>
> The dependencies for each sub projects are written in CMakeLists.txt files
> available for each sub project. e.g. indra/win_crash_logger/CMakeLists.txt
> for the win_crash_logger sub project.
>
> All of the cmake rules are stored in .cmake files written in cmake script
> found in indra/cmake. Those files are referenced as include at the beginning
> of each CMakeLists.txt.
>
> We're not building with VC90 internally so I'm not surprised some
> unpleasant surprise happen in that case. We should work to fix them though.
>
> - Merov
>
> PS: Note to self: get VS 2008 (VC90) and try solving all those build
> issues... it's about time...
>
> I am working on this currently (finally) as well...

-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] viewer-external update

[Brad Kittenbrink (Brad Linden)]

This was due to us upgrading to a new version of the c-ares library,
and we dropped the pieces that handle the new initialization
requirements.  If we export again it should be fixed.

Sorry,
-Brad

On Wednesday, June 16, 2010, Latif Khalifa  wrote:
> Hi,
>
> It builds fine on windows but it does not run. I get ""Could not start
> address resolution system" dialog on startup. After clicking OK, the
> viewer exits. Thank to Kirsten Lee the workaround of switching back to
> ares 1.6 makes it work again on windows.
>
> Latif
>
> On Wed, Jun 16, 2010 at 7:19 AM, Philippe (Merov) Bossut
>  wrote:
>> Hi,
>>
>> I'm glad to report that export to viewer-external is fixed. Svn rev 3417
>> contains all the 2.1 code and newest viewer-public development. The Mac
>> build at least works without crashing so it seems safe again to svn update
>> and check.
>>
>> Sorry for the disruption and thanks for your patience.
>>
>> Cheers,
>> - Merov
>>
>>
>> On Mon, Jun 14, 2010 at 10:01 PM, Philippe (Merov) Bossut
>>  wrote:
>>>
>>> Hi,
>>>
>>> Update on viewer-external: the last 2 "hg pull" from viewer-public keep
>>> failing when building on all platforms and, therefore, do not get to the
>>> export stage (we export only if builds pass).
>>>
>>> I think I identified the culprit: a bunch of new files and dependencies
>>> added for crash tracking.
>>>
>>> I'll be working with Lindens to determine what to do with those files and
>>> dependencies with respect to FLOSS.
>>>
>>> Thanks for your patience.
>>>
>>> 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
>
___
Policies 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] Where oh where has my rendering gone?

[Brad Kittenbrink (Brad Linden)]

On Wed, Oct 6, 2010 at 8:57 AM, Joshua Bell  wrote:

> On Tue, Oct 5, 2010 at 7:29 PM, Kent Quirk (Q Linden) 
> wrote:
>
>> Well, it's not quite like that. To pull this off, you'd have to take
>> everywhere we set a color, and set it instead to its equivalent black and
>> white value (there's a formula that's traditionally used, although there's
>> no "correct" way to do it:  Y = 0.3*R + 0.59*G + 0.11*B). You *might* be
>> able to get away with modifying the LLColor4 constructor to do this, but
>> it's probably going to have some surprising results when you assign a value
>> and don't get the same value back.
>>
>
> How about post-processing every frame before the final swapBuffers call?
> That seems like it could be done with a shader and only touching a small
> amount of code. This would affect the UI as well as the world viewport,
> however, without some significant refactoring, but given that we already
> have some post-processing effects (glow, etc) perhaps there's already a good
> spot to slot this in?
>
> (Don't trust me too much, though, as I've never written a non-trivial
> shader and have never touched the viewer's render pipeline!)
>
> Of course, once you have monochrome output, you could tweak the shader and
> get sepia-toned rendering. Old-timey SL, anyone?
>
> -- Josh
>
>

This is definitely the approach I'd recommend.

To do this you'll want to reenable the old postprocessing filters which were
part of a pre-release version of windlight but got disabled.

llrender/llpostprocess.{h,cpp}
newview/llfloaterpostprocess.{h,cpp}
newview/app_settings/shader/class{1,2}/effects/*.glsl

Most of this legacy code is probably horribly incompatible with the current
renderer (particularly since deferred rendering has redesigned the way the
renderer is organized), but at least it's a place to start looking...

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

Re: [opensource-dev] Tools of the trade.

[Brad Kittenbrink (Brad Linden)]

Funny, but no. It has been said that cmake is the worst IDE build system
generator except all those others that have been tried.

We are gonna try to ditch develop.py though.  And we're gonna start
publishing the way we build all third party libs for the viewer.  We should
be ready to show it off and talk about it in detail RealSoonNow.

-Brad

On Thu, Oct 21, 2010 at 5:54 PM, Brandon Husbands  wrote:

> You ditching Cmake?
>
>
>
> On Wed, Oct 20, 2010 at 1:43 PM, Kent Quirk (Q Linden) 
> wrote:
>
>> We've been having this discussion internally for some time. There's a lot
>> of friction because a) we have to update lots of developers, and b) we have
>> to rebuild all the libraries and distribute them internally.
>>
>> We've been working on a tool called autobuild which will automate this
>> process; it's almost ready. It should make it lots easier for us as well as
>> opensource developers to get a build up and running, and will centralize the
>> tool decisions so that we can finally upgrade fairly easily.
>>
>>Q
>>
>>
>> On Oct 20, 2010, at 12:21 AM, Brandon Husbands wrote:
>>
>> > I understand that Licensing costs money but I do have a question. It is
>> almost 2011 That's 6 years after Visual Studio was released.
>> > I also know there are patches floating around for cmake and various
>> other things that make VS2k8 compile properly. So I ask this, when is LL
>> going to drop vs2k5 as the "Supported" MS compiler? With c++0x Standard
>> actually being implimented with some methods in vs2k8 and mostly in 2k10. Is
>> it not time to really update our default toolset?
>> >
>> > At least lets get the patches in to fix 2k8, and get it officially
>> supported. I despise 2k5, 28k is pretty solid now. 2k10 seems to be the
>> vista of IDE's maybe 2k11 will be the win 7 =) Mostly due to the project
>> based settings instead of global IDE includes which is a PITA even with
>> Cmake.
>> >
>> > Id like to get LL's response on how long are we going to be stuck with
>> 2k5 as the "official" compiler/ide.
>> >
>> >
>> >
>> > --
>> >
>> ---
>> > This email is a private and confidential communication. Any use of email
>> may be subject to the laws and regulations of the United States. You may not
>> Repost, Distribute nor reproduce any content of this message.
>> >
>> ---
>> >
>> ---
>> > ___
>> > Policies and (un)subscribe information available here:
>> > http://wiki.secondlife.com/wiki/OpenSource-Dev
>> > Please read the policies before posting to keep unmoderated posting
>> privileges
>>
>>
>
>
> --
>
> ---
> This email is a private and confidential communication. Any use of email
> may be subject to the laws and regulations of the United States. You may not
> Repost, Distribute nor reproduce any content of this message.
>
> ---
>
> ---
>
> ___
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/OpenSource-Dev
> Please read the policies before posting to keep unmoderated posting
> privileges
>
___
Policies 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] Directory named "$(CONFIGURATION)" (was: No rule to make target)

[Brad Kittenbrink (Brad Linden)]

On Tue, Nov 9, 2010 at 1:04 AM, Boroondas Gupte
wrote:

>  On 11/09/2010 08:12 AM, Ricky wrote:
>
> Trying to compile viewer_development a60d3b118c76 (tip as of the time
> of this message) I get the following error:
>
> make[2]: *** No rule to make target
> `sharedlibs//PROJECT_llmath_TEST_llbboxlocal', needed by
> `llmath/PROJECT_llmath_TEST_llbboxlocal_ok.txt'.  Stop.
>
> The folder linden/indra/sharedlibs/ contains the following:
> $(CONFIGURATION)  Debug   RelWithDebInfo  Release 
> Resources
>
> Looks like a misconfig in the build system; I don't think that there
> should be a folder named "$(CONFIGURATION)" in that directory.  Maybe
> someone typed single quotes when they intended to use double quotes?
>
>  Maybe caused by changesets 
> 2626
> /2627?
> Though those are one year old, now. So if it's them, Mac builders should be
> having this problem ever since 2.0 ...
>
> Cheers,
> Boroondas
>

Speaking as the author of the offending changesets (sorry!).  I'd strongly
recommend buiding using the xcode generator instead of makefiles on Mac.
This is not the only place we make this assumption in our cmake scripts.

Anyways, for now our builds pretty much assume Mac == Xcode.  In theory,
that'd be good to fix, but I don't really have time to look into it now.  If
there are enough people interested in this we should get a story written for
adding support for the makefile generator on mac, and then I can fill in the
details there for how it should be done.

-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] Autoupdater Flashback

[Brad Kittenbrink (Brad Linden)]

Oops, thanks for the heads-up.

The background updater is new in viewer 2.4 (as it's not released in beta
yet, it doesn't have release notes yet, so sorry for the surprise).
Yesterday we deployed the server side work in preparation for the beginning
of the 2.4 beta releases, and it turned on.  Unfortunately we hadn't been
paying attention to the Second Life Development channel, and there was some
obsolete data in the database.

Anyways, thanks again for testing this for us.  We should be getting it
fixed shortly.

-Brad

On Mon, Nov 29, 2010 at 7:42 PM, Bunny Halberd  wrote:

> Hey Guys -
>
> So, when I got home from work I grabbed whatever the current Snowstorm
> build at the time is to use for the evening. (Build 215642 today.)
> Shortly after logging in I see that a new version of SL has been
> downloaded and will be installed on the next restart... thought that
> was weird since I'd never seen that message before.
>
> When I restarted the SL Viewer a console window opened up and a new
> version of the viewer was installed. Version:
>
> - Second Life 2.1.2 (209456) Sep 13 2010 16:05:27 (Second Life Development)
>
> Which is much older than 215642. :)
>
> So yay! The autoupdater works! Except, uh, it's handing out a really
> old version! :)
>
> - Bunny
> ___
> Policies 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