Re: [opensource-dev] Review Request: Changes to fix CHOP-662.

[Oz Linden]

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



doc/contributions.txt


Lindens should not be added here (much as we're glad to have your help, 
Squire)


- Oz


On June 20, 2011, 8:21 p.m., Squire Linden wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/357/
> ---
> 
> (Updated June 20, 2011, 8:21 p.m.)
> 
> 
> Review request for Viewer, Oz Linden, Seth ProductEngine, and Alain Linden.
> 
> 
> Summary
> ---
> 
> Changes to fix CHOP-662. CHOP-662 was caused by the recent addition of 
> lldiriterator.cpp which is used to iterate over directories. It takes a mask 
> in the form of a glob string to use as a pattern for which files to iterate 
> over.
> 
> Unfortunately, as originally implemented, it converted the glob to a regex 
> pattern without escaping any legal glob characters which are illegal regex 
> characters. As a result if the passed in mask was an illegal regex it would 
> fail and llerrs would cause a crash.
> 
> In CHOP-662 this happens whenever a group name has, e.g. a '+' character at 
> the beginning. When logging in the viewer would attempt to load the group 
> chat log file which would result in a glob starting with a '+' character and 
> in turn to an illegal regex in lldiriterator.
> 
> Also, the chat code was doing nothing to ensure that illegal glob characters 
> were not being passed to the lldiriterator constructor.
> 
> 
> This addresses bug CHOP-662.
> http://jira.secondlife.com/browse/CHOP-662
> 
> 
> Diffs
> -
> 
>   doc/contributions.txt e8f2a53c3d6e 
>   indra/llvfs/CMakeLists.txt e8f2a53c3d6e 
>   indra/llvfs/lldiriterator.cpp e8f2a53c3d6e 
>   indra/llvfs/tests/lldiriterator_test.cpp PRE-CREATION 
>   indra/newview/lllogchat.cpp e8f2a53c3d6e 
> 
> Diff: http://codereview.secondlife.com/r/357/diff
> 
> 
> Testing
> ---
> 
> Added a unit test for lldiriterator which checks for construction failures on 
> examples of the most common group names which were causing the crashes.
> 
> 
> Thanks,
> 
> Squire
> 
>

___
Policies 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: Check for null ptr to hopefully prevent crash in LLToolPie

[Oz Linden]

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

Ship it!


Whether that's the crash or not, it's obviously a good idea

- Oz


On June 21, 2011, 8:53 a.m., Alain Linden wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/359/
> ---
> 
> (Updated June 21, 2011, 8:53 a.m.)
> 
> 
> Review request for Viewer, Oz Linden and Vadim ProductEngine.
> 
> 
> Summary
> ---
> 
> checking for null gAgentAvatarp should hopefully prevent the crash.  I can't 
> reproduce it so I don't know for sure.
> 
> 
> This addresses bug EXP-825.
> http://jira.secondlife.com/browse/EXP-825
> 
> 
> Diffs
> -
> 
>   indra/newview/lltoolpie.cpp e8f2a53c3d6e 
> 
> Diff: http://codereview.secondlife.com/r/359/diff
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Alain
> 
>

___
Policies 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: OPEN-99: use -march=pentium3 and -march=pentium4 only for 32 bit builds

[Boroondas Gupte]

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

(Updated June 22, 2011, 1:19 p.m.)


Review request for Viewer.


Changes
---

In 'Testing Done': Replaced output for standalone 64-bit build with reference 
to OPEN-100. Noted that failure of 64-bit build using 32-bit prebuilts is 
expected.


Summary
---

These flags prevent building for 64-bit (both standalone or non-standalone), so 
only use them for 32-bit builds.


This addresses bug OPEN-99.
http://jira.secondlife.com/browse/OPEN-99


Diffs
-

  doc/contributions.txt e8f2a53c3d6e 
  indra/cmake/00-Common.cmake e8f2a53c3d6e 

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


Testing (updated)
---

Tried a non-standalone 64-bit build (without using 64-bit prebuilts, though):
Fails with
[ 11%] Building CXX object 
llcommon/CMakeFiles/llcommon.dir/u64.o
Linking CXX shared library libllcommon.so

/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.5/../../../../x86_64-pc-linux-gnu/bin/ld: 
skipping incompatible 
${SRC_DIR}/build-linux-i686/packages/lib/release/libbreakpad_client.so when 
searching for -lbreakpad_client

/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.5/../../../../x86_64-pc-linux-gnu/bin/ld: 
skipping incompatible 
${SRC_DIR}/build-linux-i686/packages/lib/release/libaprutil-1.so when searching 
for -laprutil-1

/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.5/../../../../x86_64-pc-linux-gnu/bin/ld: 
skipping incompatible 
${SRC_DIR}/build-linux-i686/packages/lib/release/libaprutil-1.a when searching 
for -laprutil-1

/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.5/../../../../x86_64-pc-linux-gnu/bin/ld: 
skipping incompatible 
${SRC_DIR}/build-linux-i686/packages/lib/release/libdb-5.1.so when searching 
for -ldb-5.1

/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.5/../../../../x86_64-pc-linux-gnu/bin/ld: 
cannot find -ldb-5.1
collect2: ld returned 1 exit status
make[2]: *** [llcommon/libllcommon.so] Error 1
make[1]: *** [llcommon/CMakeFiles/llcommon.dir/all] Error 2
make: *** [all] Error 2
ERROR: building default configuration returned 2
For more information: try re-running your command with 
--verbose or --debug
(This is, off course, expected. Will have to produce my own 64bit 
prebuilts for local use.)

Tried a standalone 64-bit build (after merging OPEN-38 changes):
Fails by hitting https://jira.secondlife.com/browse/OPEN-100

(Both errors occur much later in the build process than the one that'd occur 
without this change.)

Tried a non-standalone 32-bit build:
Fails on https://jira.secondlife.com/browse/OPEN-23 , just as without 
this change.


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: Local Bitmap Browser implementation.

[Oz Linden]

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



indra/llmath/llvolumemgr.cpp


Unnecessary early returns.

LLVolume* vol = NULL;
if ( lod <= NUM_LODS && ! mVolumeLODs[lod].isNull() )
{
vol = mVolumeLODs[lod];
}

return vol;




indra/newview/llfloaterlocalbitmap.cpp


(many instances of this throughout)

All these clauses should reverse the sense of the tests and only have a 
single break at the end of each case clause.

The use of early returns is unhelpful when debugging - set a variable and 
return at the bottom.



indra/newview/llfloaterlocalbitmap.cpp


What's wrong with combining these ifs and not needing the continues?

I know this is getting repetitious




indra/newview/llfloaterlocalbitmap.cpp


Nice logging !




indra/newview/llfloaterlocalbitmap.cpp


Really a global comment...

don't put braces all on one line, please.  See 
https://wiki.secondlife.com/wiki/Coding_Standard#Braces


- Oz


On June 18, 2011, 8:04 a.m., Vaalith Jinn wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/347/
> ---
> 
> (Updated June 18, 2011, 8:04 a.m.)
> 
> 
> Review request for Viewer.
> 
> 
> Summary
> ---
> 
> Local Bitmap Browser is a mechanism to locally load images into the viewer, 
> track them and optionally (per each image)
> have it check if the image has been overwritten locally and if so - update it 
> in the viewer and inworld.
> 
> This change affects build menu by adding a way to open the floater there.
> This change also affects the texture picker - adding tabs that lets the user 
> choose between the "Server" (regular inventory) and "Local" tabs (list of 
> locally added files).
> 
> 
> This addresses bug STORM-64.
> http://jira.secondlife.com/browse/STORM-64
> 
> 
> Diffs
> -
> 
>   doc/contributions.txt 6a3e7e403bd1 
>   indra/llmath/llvolumemgr.h 6a3e7e403bd1 
>   indra/llmath/llvolumemgr.cpp 6a3e7e403bd1 
>   indra/newview/CMakeLists.txt 6a3e7e403bd1 
>   indra/newview/llfloaterlocalbitmap.h PRE-CREATION 
>   indra/newview/llfloaterlocalbitmap.cpp PRE-CREATION 
>   indra/newview/lltexturectrl.h 6a3e7e403bd1 
>   indra/newview/lltexturectrl.cpp 6a3e7e403bd1 
>   indra/newview/llviewerfloaterreg.cpp 6a3e7e403bd1 
>   indra/newview/llviewerobjectlist.h 6a3e7e403bd1 
>   indra/newview/llviewertexturelist.h 6a3e7e403bd1 
>   indra/newview/llvovolume.h 6a3e7e403bd1 
>   indra/newview/skins/default/xui/en/floater_local_bitmap.xml PRE-CREATION 
>   indra/newview/skins/default/xui/en/floater_texture_ctrl.xml 6a3e7e403bd1 
>   indra/newview/skins/default/xui/en/menu_viewer.xml 6a3e7e403bd1 
> 
> Diff: http://codereview.secondlife.com/r/347/diff
> 
> 
> Testing
> ---
> 
> Texture/Sculptmap/Avatar Layer show.
> Texture/Sculptmap/Avatar Layer update.
> Multiple sculpties update.
> Opening multiple browser floaters works correctly. (two possible since one 
> can be opened from menu above, one from texture picker. all of them + texture 
> picker play nice.)
> Tested adding over 200 images at the same time.
> 
> 
> Thanks,
> 
> Vaalith
> 
>

___
Policies 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] Highlight Transparent Broken?

[Trilo Byte]

Is it just me, or is Advanced -> Highlighting and Visibility -> Highlight 
Transparent broken?

I convinced my girlfriend to try the development viewer on her machine, and she 
pointed it out (it's not a feature I use much).  Normally, when enabled, it 
should highlight any.all prims with transparency in red, and in build 233586 
(mac client) it doesn't appear to be doing anything.  Is this happening to 
anyone else?

TriloByte Zanzibar
___
Policies 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] Is it just me? Avatar textures downloading last.

[Lee ponzu]

   - 1. Second Life Viewer - VWR 
   - VWR-26093 

Mass avatar texture rebake and load failures resulting in blury and grey
textures which do not resolve on their
own

Already exists.  I added a comment and my logs to it.   Shoud this be a VWR
Jira?  Or could it be related to some other system.

ponzu

On Mon, Jun 20, 2011 at 8:03 PM, Thickbrick Sleaford <
thickbrick.sleaf...@gmail.com> wrote:

> On Saturday 18 June 2011 20:00:04 Lee ponzu wrote:
> > However, and unrelated to shadows, I began to notice last night that
> while
> > my scenes had all downloaded, the avatars around me were still all gray.
> >  Their objects were OK, it was just their skin and cloth final bake that
> is
> > missing.  They do show up after several minutes, but long after
> everything
> > else.
> >
>
> I've noticed avatar bakes taking very long to un-gray too, when trying the
> SL
> v2 viewer recently after not using it for a long-ish while. This is
> especially
> noticeable in crowded areas.
>
> Looking at the texture console, it looks like any fetch that is using udp
> (i.e. bakes, since they can not be fetched via http) is always at the
> bottom
> of the list, and usually gets bumped out quickly. I haven't tested this,
> but I
> get the feeling that the udp fetches are starved out of processing by the
> regular http fetches. If I stay a while in a gray people gathering, and
> then
> relog, the once-gray people have at least one discard level of their bakes
> quickly decoded, probably from cache. This makes me think that this is a
> prioritization issue, possibly caused by the quick turn-around of http
> textures.
>
> --
> Thickbrick
> ___
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/OpenSource-Dev
> Please read the policies before posting to keep unmoderated posting
> privileges
>
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

[opensource-dev] Stop Animating Me gone missing...

[Lee ponzu]

Using latest dev 2.7.5..  I needed to stop my animation but couldn't
find it in the menu.  Didn't it used to be there?  Should it be there?  Was
it removed on purpose?  Am I merely blind or drunk?

Someone had to remind me that we used to use a wearable object to do that,
and that worked fine.
___
Policies 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] Stop Animating Me gone missing...

[Lee ponzu]

Never mindfound it.  8-(


On Thu, Jun 23, 2011 at 1:08 AM, Lee ponzu  wrote:

> Using latest dev 2.7.5..  I needed to stop my animation but couldn't
> find it in the menu.  Didn't it used to be there?  Should it be there?  Was
> it removed on purpose?  Am I merely blind or drunk?
>
> Someone had to remind me that we used to use a wearable object to do that,
> and that worked fine.
>
>
>
___
Policies 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] Highlight Transparent Broken?

[holydoughnuts]

On 6/23/2011 12:10 AM, Trilo Byte wrote:
> Is it just me, or is Advanced ->  Highlighting and Visibility ->  Highlight 
> Transparent broken?
>
> I convinced my girlfriend to try the development viewer on her machine, and 
> she pointed it out (it's not a feature I use much).  Normally, when enabled, 
> it should highlight any.all prims with transparency in red, and in build 
> 233586 (mac client) it doesn't appear to be doing anything.  Is this 
> happening to anyone else?

Hmm, yes it repros here, Win7/ATI. Ctrl-Alt-T only works if I disable 
basic shaders. (I think it's expected that it won't fully work if 
automatic alpha is on, but it's definitely switched off here.)
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges