Re: [opensource-dev] Test build available

[Laurent Bechir]

Le 26 févr. 2011 à 05:33, Philippe (Merov) Bossut a écrit :

> Hi,
> 
> I created a "PO Build" to test a bunch of JIRAs in the Review state that just 
> need testing and PO Approval. The binaries are here:
> 
> http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repo/merov_viewer-development-import/rev/222147/index.html
> 
> The JIRAs pulled in for testing are:
> * STORM-357 : Gestures button is in the pressed state after drag-n-drop but 
> gestures list isn't visible

Fixed

> * STORM-665 : User is not able to view full name of Group's founder in the 
> Group Profile

I always see the display name, but not always the user name if the display name 
is too long.

> * STORM-842 : "Start at" list isn't populated with favorites if user name is 
> typed in fashion "firstname.lastname
> * STORM-889 : Put Link/Unlink in Edit Panel

Nice :)

> * STORM-949 : please remove actual usernames from XUI files <-- Trivial and 
> not really testable
> * STORM-954 : SL-viewer 2.0 No nearby people when over approximately 1000 
> meters <-- Long time dangling issue! Please test...

I guess you mean height of 1000 m ? sims are no more than 256 m ?

> * STORM-971 : 'Stop Tracking' menu item is still enabled in Mini-map floater 
> after you stopped tracking in Nearby mini-map
> * STORM-991 : Parser warning on Inventory floater construction
> * STORM-1004 : Unblocking/blocking name sometimes deletes identically named 
> entry, but of different TYPE
> 
> 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

[opensource-dev] autobuild+vs2010 memory trouble

[Jonathan Welch]

Yesterday I got to the point of being able to start a compile with
autobuild+vs2010 on my XP system with 3Gb of memory.  After about 90
minutes it died with the usual heap overflow message.  Today I edited
a file in the Cmake 2.8 directory and changed Zm1000 to Zm400 which
got me much further along.  About an hour in I saw I was about to run
out of memory and for the next hour was paging heavily.  I must have
run out of page file when it was working on llvlmanager.
I was left with 3 instances of cl.exe, 2 using a lot of memory and 1
using hardly any (I only have 2 cores so do not understand why I had 3
cl.exe running).  Once I killed those off it took about 4 minutes for
my page file to stop being accessed.

After yesterday's failure I tried again and all the files in the build
that had compiled successfully were being compiled again.

Some design changes need to be made here
1) Compile projects in much smaller chunks
2) Do not recompile files that have already been compile (I would like
someone to verify this)

My normal compile time has been a little over 1hr.
___
Policies 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+vs2010 memory trouble

[WolfPup Lowenhar]

You have just hit the issue I have been working on for the past week and a
half I found that if you totally remove the /Zm1000 setting you should not
have that issue. This is being cause by Cmake wanting to set the /Zm setting
I have filed a bug Report With Kitware concerning this. See :
https://jira.secondlife.com/browse/OPEN-37

My last comment there has a link to the issue and the issue has a work
around in it.

 

From: opensource-dev-boun...@lists.secondlife.com
[mailto:opensource-dev-boun...@lists.secondlife.com] On Behalf Of Jonathan
Welch
Sent: Tuesday, March 01, 2011 8:53 AM
To: OpenSource Mailing List
Subject: [opensource-dev] autobuild+vs2010 memory trouble

 

Yesterday I got to the point of being able to start a compile with
autobuild+vs2010 on my XP system with 3Gb of memory.  After about 90
minutes it died with the usual heap overflow message.  Today I edited
a file in the Cmake 2.8 directory and changed Zm1000 to Zm400 which
got me much further along.  About an hour in I saw I was about to run
out of memory and for the next hour was paging heavily.  I must have
run out of page file when it was working on llvlmanager.
I was left with 3 instances of cl.exe, 2 using a lot of memory and 1
using hardly any (I only have 2 cores so do not understand why I had 3
cl.exe running).  Once I killed those off it took about 4 minutes for
my page file to stop being accessed.

After yesterday's failure I tried again and all the files in the build
that had compiled successfully were being compiled again.

Some design changes need to be made here
1) Compile projects in much smaller chunks
2) Do not recompile files that have already been compile (I would like
someone to verify this)

My normal compile time has been a little over 1hr.
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting
privileges 

  _  

No virus found in this message.
Checked by AVG - www.avg.com
Version: 10.0.1204 / Virus Database: 1435/3475 - Release Date: 03/01/11

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

Re: [opensource-dev] STORM-1023 (was OPEN-4) : fmod

[WolfPup Lowenhar]

If your still having to copy the fmod.dll by hand then this is not a viable
solution as everything is supposed to be automatic hence the name autobuild.

 

From: Twisted Laws [mailto:twisted_l...@hotmail.com] 
Sent: Tuesday, March 01, 2011 8:00 AM
To: wolfpu...@earthlink.net
Subject: RE: [opensource-dev] STORM-1023 (was OPEN-4) : fmod

 

\dev\fmod   - contains the .h files
\dev\fmod\release - contains the .lib and .dll files  (fmodvc.lib renamed to
fmod.lib and fmod.dll)
\dev\fmod\debug - contains the .lib and .dll files (fmodvc.lib renamed to
fmod.lib and fmod.dll)
 
I couldn't get it to work using the zip extracted as it expects the release
and debug directorys under the directory specified in FMOD_LIBRARY and I had
to manually copy the dll file to 
build-vc100\sharedlibs\release (and debug and relwithdebinfo)
 

  _  

From: wolfpu...@earthlink.net
To: opensource-dev@lists.secondlife.com
Date: Mon, 28 Feb 2011 23:34:50 -0500
Subject: Re: [opensource-dev] STORM-1023 (was OPEN-4) : fmod

If you could explain how your fmod directory it set up it would be welcomed.
As you can see I am using the upacked zip file. My suggestion still stand
about making a packaging system in autobuild that would generate a package
like the one LL uses for fmod that could then be placed somewhere that the
autobuild system could find it and the extract it to the build tree.

 

From: opensource-dev-boun...@lists.secondlife.com
[mailto:opensource-dev-boun...@lists.secondlife.com] On Behalf Of Twisted
Laws
Sent: Saturday, February 26, 2011 11:54 AM
To: SLDEV
Subject: Re: [opensource-dev] STORM-1023 (was OPEN-4) : fmod

 

to get fmod working i used this changeset and used
autobuild --debug configure -c VC10msbuildRelWithDebInfo --
-DLL_TESTS:BOOL=OFF -DFMOD:BOOL=ON -DFMOD_INCLUDE_DIR=C:\Dev\fmod
-DFMOD_LIBRARY=C:\Dev\fmod
 
successfully compiles, runs and has sound  (not standalone)

 

  _  

No virus found in this message.
Checked by AVG - www.avg.com
Version: 10.0.1204 / Virus Database: 1435/3474 - Release Date: 02/28/11

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

Re: [opensource-dev] Review Request: VWR-24889: When a bake texture upload fails, retry instead of giving up.

[Thickbrick Sleaford]

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

(Updated March 1, 2011, 8:28 a.m.)


Review request for Viewer.


Changes
---

New diff, fixes the typo in the comment pointed out by Merov.


Summary
---

When a bake upload fails, the viewer doesn't retry it, and subsequently doesn't 
send a AgentSetAppearance message. This can happen without the user being 
aware, leaving the avatar looking good on their screen, but not updated to the 
same outfit on other people's screens. The avatar will remain in that state 
until the user does something that causes a rebake (manually rebake or change 
outfit.) The solution here is to retry the upload after a small delay.

What this diff changes: when a full-res upload fails, retry to upload it after 
a 5s delay, up to 5 times (in case the cap is available, last attempt is via 
the old asset store.) Also, some clearer log messages. This implements an old 
*FIX: comment:
// *FIX: retry upload after n seconds, asset server could be busy

This isn't needed for low res uploads, because they don't block subsequent 
full-res uploads (mNeedsUpload isn't set to FALSE in 
LLTexLayerSetBuffer::doUpload in low-res uploads.)


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


Diffs (updated)
-

  indra/newview/llassetuploadresponders.h 767feb16f05f 
  indra/newview/llassetuploadresponders.cpp 767feb16f05f 
  indra/newview/lltexlayer.h 767feb16f05f 
  indra/newview/lltexlayer.cpp 767feb16f05f 

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


Testing
---

Attempted outfit changes using a problematic connection (not recently used 
outfits to avoid using cached bakes). Looked for "Baked full res texture upload 
for  failed" log messages, observed the subsequent retries and 
successful upload for that region. Observed that eventually the fully-baked 
avatar is visible to other users.


Thanks,

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

Re: [opensource-dev] Review Request: VWR-24889: When a bake texture upload fails, retry instead of giving up.

[Boroondas Gupte]

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



indra/newview/lltexlayer.h


"intermediary" is still misspelled


- Boroondas


On March 1, 2011, 8:28 a.m., Thickbrick Sleaford wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/152/
> ---
> 
> (Updated March 1, 2011, 8:28 a.m.)
> 
> 
> Review request for Viewer.
> 
> 
> Summary
> ---
> 
> When a bake upload fails, the viewer doesn't retry it, and subsequently 
> doesn't send a AgentSetAppearance message. This can happen without the user 
> being aware, leaving the avatar looking good on their screen, but not updated 
> to the same outfit on other people's screens. The avatar will remain in that 
> state until the user does something that causes a rebake (manually rebake or 
> change outfit.) The solution here is to retry the upload after a small delay.
> 
> What this diff changes: when a full-res upload fails, retry to upload it 
> after a 5s delay, up to 5 times (in case the cap is available, last attempt 
> is via the old asset store.) Also, some clearer log messages. This implements 
> an old *FIX: comment:
> // *FIX: retry upload after n seconds, asset server could be busy
> 
> This isn't needed for low res uploads, because they don't block subsequent 
> full-res uploads (mNeedsUpload isn't set to FALSE in 
> LLTexLayerSetBuffer::doUpload in low-res uploads.)
> 
> 
> This addresses bug VWR-24889.
> http://jira.secondlife.com/browse/VWR-24889
> 
> 
> Diffs
> -
> 
>   indra/newview/llassetuploadresponders.h 767feb16f05f 
>   indra/newview/llassetuploadresponders.cpp 767feb16f05f 
>   indra/newview/lltexlayer.h 767feb16f05f 
>   indra/newview/lltexlayer.cpp 767feb16f05f 
> 
> Diff: http://codereview.secondlife.com/r/152/diff
> 
> 
> Testing
> ---
> 
> Attempted outfit changes using a problematic connection (not recently used 
> outfits to avoid using cached bakes). Looked for "Baked full res texture 
> upload for  failed" log messages, observed the subsequent 
> retries and successful upload for that region. Observed that eventually the 
> fully-baked avatar is visible to other users.
> 
> 
> Thanks,
> 
> 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

Re: [opensource-dev] Review Request: VWR-24889: When a bake texture upload fails, retry instead of giving up.

[Thickbrick Sleaford]

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

(Updated March 1, 2011, 8:58 a.m.)


Review request for Viewer.


Changes
---

More comment spelling.


Summary
---

When a bake upload fails, the viewer doesn't retry it, and subsequently doesn't 
send a AgentSetAppearance message. This can happen without the user being 
aware, leaving the avatar looking good on their screen, but not updated to the 
same outfit on other people's screens. The avatar will remain in that state 
until the user does something that causes a rebake (manually rebake or change 
outfit.) The solution here is to retry the upload after a small delay.

What this diff changes: when a full-res upload fails, retry to upload it after 
a 5s delay, up to 5 times (in case the cap is available, last attempt is via 
the old asset store.) Also, some clearer log messages. This implements an old 
*FIX: comment:
// *FIX: retry upload after n seconds, asset server could be busy

This isn't needed for low res uploads, because they don't block subsequent 
full-res uploads (mNeedsUpload isn't set to FALSE in 
LLTexLayerSetBuffer::doUpload in low-res uploads.)


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


Diffs (updated)
-

  indra/newview/llassetuploadresponders.h 767feb16f05f 
  indra/newview/llassetuploadresponders.cpp 767feb16f05f 
  indra/newview/lltexlayer.h 767feb16f05f 
  indra/newview/lltexlayer.cpp 767feb16f05f 

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


Testing
---

Attempted outfit changes using a problematic connection (not recently used 
outfits to avoid using cached bakes). Looked for "Baked full res texture upload 
for  failed" log messages, observed the subsequent retries and 
successful upload for that region. Observed that eventually the fully-baked 
avatar is visible to other users.


Thanks,

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

[opensource-dev] Daily Scrum Summary - Monday, February 28

[Anya Kanevsky]

 Sprint 11, ends 02.28.11 Monday, February 28 General Notes
--

   - MMOTD: Merov

Team Status
--
 Merov Linden
--

*PAST*

   - MM: Merged what could be merged. Created a test PO build for things in
   review. Moved stuff from OPEN to STORM that were ready to be integrated.
   - STORM-1023 : fmod : Looked into the results reported by opensource
   devs. Need more work.

*FUTURE*

   - MM
   - Sprint 12 planning
   - STORM-987 : llimage_libtest: Add image stats output

*IMPEDIMENTS*

   - Need PO Approval or rejection on the 9 JIRAs I created a PO build for.
   Pretty please

Oz Linden
--

*PAST*

   - Debugging autobuild integration problems
   - Built a couple more autobuild packages
   - Assorted internal process meetings
   - Updated OPEN project workflow to include a triage state
   - Triaged about half of the open issues in my morning meeting today

*FUTURE*

   - Build some more autobuild packages
   - Continue autobuild integration and testing

*IMPEDIMENTS*

   - none

Q Linden
--

*PAST*

   - ooo for PT
   - process work
   - meetings
   - more writing

*FUTURE*

   - sprint planning
   - meetings
   - more writing

*IMPEDIMENTS*

   - none

Bao Linden
--

*PAST*

   - wrote the test plan for the memory project
   - finished my Q4 review
   - investigated SH-1064: crash in LLVertexBuffer::setupVertexBuffer when
   deferred rendering is enabled
   - investigated CTS-478: viewer freezes on first login on win7

*FUTURE*

   - continue on SH-1064
   - close CTS-478
   - meeting

*IMPEDIMENTS*

   - none

Grumpity ProductEngine
--

*PAST*

   - discussed STORM-236 with Wolf & Q
   - prep for Sprint planning
   -

*FUTURE*

   - sprint planning
   - test PO build
   - follow up with Nyx on windlight presets
   - meet with Geo

*IMPEDIMENTS*

   - none


Paul ProductEngine
--

*PAST*

   - BUG STORM-437 (Docked nearby chat panel is placed over Sidebar panel
   after Maximizing(or Restoring down) Viewer window)
  - Tried to reproduce on Linux and Windows but had no luck. Moved to
  unassigned as this bug is reproducible on Mac OS X 10.5.8 but i have not
  this OS
   - BUG STORM-494 (Message Well window is undocked while opening Side bar)
  - Fixed and sent for review

*FUTURE*

   - Setup WindowsXP and all necessary soft
   - Other tickets by priority

*IMPEDIMENTS*

   - none

Seth ProductEngine
--

*PAST*

   - BUG (STORM-1015) Unable to select right Login Landmark when it's name
   is not unique
  - Fixed. Submitted patch to the review board.
   - BUG (STORM-361) Teleport offer message is shown with scroll bar in the
   IM history
  - Could not reproduce.
   - BUG (STORM-721) Information about resident is displayed incorrectly in
   mini-inspector if there are any resident or group SLURLs
  - Looking for the cause of the bug in avatar inspector.
  - Investigating text editor with inline widgets behavior. In case with
  the avatar inspector the text editor reshape logic causes the editor
  contents to exceed the inspector boundaries. The possible
workarounds are to
  use an expandable textbox or to limit the length of the inspector text.

*FUTURE*

   - BUG (STORM-721) Information about resident is displayed incorrectly in
   mini-inspector if there are any resident or group SLURLs
  - Estimated: about an hour to apply a workaround, 10 - 12 hours to fix
  text editor.

*IMPEDIMENTS*

   - none

Vadim ProductEngine
--

*PAST*

   - STORM-236 (Allow the "Speak" button to be removed, like other buttons):
  - Finished hacking bottom tray to make the drag handle visible. I
  don't like the result though.
  - Finishing Wolfpup's work on making the Speak button optional.

*FUTURE*

   - Finish with STORM-236.

*IMPEDIMENTS*

   - Need a PO decision for STORM-326 (Persistent water/sky presets).

Andrey ProductEngine
--

*PAST*

   - continued regression testing of v-d branch
  - Alerts&Notifications
  - Navigation
  - Preferences - Sound & Media
  - Preferences - Notifications
  - Notifications
   - reported 1 issue

*FUTURE*

   - finish regression pass

*IMPEDIMENTS*

   - none

Jonathan Yap
--

*PAST*

   - STORM-980 (Appearance panel / Wear button is too wide)
  - QA found an additional issue with the Wear button so I will fix it
  as part of this jira.
   - STORM-990 (The arrow in the bottom right of the Landmark panel points
   down)
  - Sent back by MM for the 2nd time. Merged again and sent results back
  to bitbucket.
   - Got help from 2 people trying to figure out why autobuild+vs2010 does
   not work for

my configuration.

*FUTURE*

   - STORM - 980
   - More help 

[opensource-dev] VCmsbuildOpenSourceRelWithDebInfo Incremental Link Testers Needed.

[Nicky Perian]

One line addition to autobuild.xml VCmsbuildRelWithDebInfo Section for 
incremental linking.


   VC10msbuildRelWithDebInfo

  build
  
command
msbuild.exe
options

  SecondLife.sln
  /t:build
  /p:Configuration=RelWithDebInfo
  /p:Platform=Win32
  /p:"VCBuildAdditionalOptions= /useenv"
  /p:"VCBuildAdditionalOptions= /incremental"
  
  
  configure
  
options

  -G
  "Visual Studio 10"
  -DSTANDALONE:BOOL=FALSE
  -DINSTALL_PROPRIETARY=FALSE
  -DFMOD=TRUE

  
  name
  VC10msbuildRelWithDebInfo

   



  ___
Policies 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: (STORM-721) Information about resident is displayed incorrectly in mini-inspector if there are any resident or group SLURLs

[Seth ProductEngine]

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

Review request for Viewer.


Summary
---

Fixed text editor to display the embedded widgets only if they are in the 
currently visible area of a text document.


This addresses bug STORM-721.
http://jira.secondlife.com/browse/STORM-721


Diffs
-

  indra/llui/lltextbase.cpp 767feb16f05f 

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


Testing
---


Thanks,

Seth

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

[opensource-dev] Daily Scrum Summary - Tuesday, March 1

[Anya Kanevsky]

 Sprint 12, ends 03.21.11 Tuesday, March 1 General Notes
--

   - MMOTD: Merov

Team Status
--
 Merov Linden
--

*PAST*

   - Sprint 12 planning
   - Worked on mapserver fixes (internal experiments)

*FUTURE*

   - MM
   - STORM-1023 : fmod : look into Wolfpup comments and try to rationalize
   all that
   - STORM-987 : llimage_libtest: Add image stats output

*IMPEDIMENTS*

   - none

Oz Linden
--

*PAST*

   - Assorted internal meetings

*FUTURE*

   - Autobuild integration and testing

*IMPEDIMENTS*

   - none

Q Linden
--

*PAST*

   - process work
   - sprint planning
   - meetings
   - work on storm-26 and its children (keyboard shortcut system)

*FUTURE*

   - sprint planning
   - 2.5.1 release
   - storm-26

*IMPEDIMENTS*

   - none
   - ooo this afternoon, but will be working from home later

Bao Linden
--

*PAST*

   - closed CTS-478 after further investigation
   - deferred SH-1064 until the crash report is normal after trying all
   possibilities to repro.
   - meetings

*FUTURE*

   - OOO for the morning
   - review STORM-864

*IMPEDIMENTS*

   - none

Wolf Linden
--

*PAST*

   - Organization initiatives

*FUTURE*

   - All Snowstorm, All Day

*IMPEDIMENTS*

   - none

Grumpity ProductEngine
--

*PAST*

   - Sprint planning
   - jira wrangling
   - tested PO build

*FUTURE*

   - follow up with Nyx on windlight presets
   - meet with Geo

*IMPEDIMENTS*

   - none


Paul ProductEngine
--

*PAST*

   - Finished setup and configuring SL project on WindowsXP
   - BUG STORM-952 (No upload from filepath including national characters
   like æ, ø and å)
  - Closed as cannot reproduce.

*FUTURE*

   - STORM-357 (Gestures button is in the pressed state after drag-n-drop
   but gestures list isn't visible)

*IMPEDIMENTS*

   - none

Seth ProductEngine
--

*PAST*

   - BUG (STORM-721) Information about resident is displayed incorrectly in
   mini-inspector if there are any resident or group SLURLs
  - Workaround with limiting the length of the inspector text does not
  solve the problem.
  - Working on hiding the widgets embedded into the text editor if they
  are beyond the visible text area.

*FUTURE*

   - BUG (STORM-721) Information about resident is displayed incorrectly in
   mini-inspector if there are any resident or group SLURLs
  - Estimated: 4-6 hours.
   - BUG (STORM-989) Texture Picker freezes - does not indicate texture on
   prim

*IMPEDIMENTS*

   - none

Vadim ProductEngine
--

*PAST*

   - STORM-236 (Allow the "Speak" button to be removed, like other buttons):
  - Finished hacking bottom tray to make the drag handle visible. I
  don't like the result though.
  - Finishing Wolfpup's work on making the Speak button optional.

*FUTURE*

   - Finish with STORM-236.

*IMPEDIMENTS*

   - Need a PO decision for STORM-326 (Persistent water/sky presets).

Andrey ProductEngine
--

*PAST*

   - verified integrated tickets STORM-979, STORM-680, STORM-974, STORM-980
   - almost done regression pass against v-d branch (Appearance and
   Region/Estate are left)
  - Preferences - Graphics / Hardware Settings
  - Preferences - Graphics / Advanced (40%)
  - Sidebar-HUD interaction
  - My Profile Panel
  - Avatar Appearance - Inventory Sidepanel
  - Avatar Appearance - Outfit Selector
  - Avatar Appearance - Avatar Clouding Rez
  - Avatar Appearance - Wearable Editor (52%)

*FUTURE*

   - verify integrated tickets?

*IMPEDIMENTS*

   - none

Jonathan Yap
--

*PAST*

   - STORM-980 (Appearance panel / Wear button is too wide)
  - Fixed additional issue QA found.
   - STORM-1025 (Chat preferences > font size should increase size of input
   text as well)
  - Ready for PO build testing. Note: RB suggestion that font change
  take effect immediately via

a callback has not been implemented. Oz thought the current method was
adequate.

   - Got more help with autobuild+vs2010.

*FUTURE*

*IMPEDIMENTS*

   - STORM - 956

File message_template.msg needs to be pushed into viewer code tree from
server code tree. Long term solution expected late March.

   - STORM - 1019 Needs design feedback from Wolf.

Wolfpup Lowenhar
--

*PAST*

   - RL work.
   - Trying to earn $L's inworld.
   - OPEN-37: rewrote per Oz's directions so others can butter understand
   also didmore testing on my system to see if i can get it working .
   - STORM-1023 : Testing of Merov's proposed fix. this looks like it might
   not be the best way to go as the dll file still has to be manualy copied
   into the build tree whic is not what is wanted.

*FUTURE*

   - RL work.
   - T

Re: [opensource-dev] Review Request: (STORM-721) Information about resident is displayed incorrectly in mini-inspector if there are any resident or group SLURLs

[Boroondas Gupte]

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



indra/llui/lltextbase.cpp


Only tangent to your code, but is the scoping (the "{" and "}") here doing 
anything useful? (It causes the "clip" object to be destructed one line 
earlier, but is that the intention?)

Also, it seems the "clip" object is never used. Does it do all its work in 
its constructor?


- Boroondas


On March 1, 2011, 1:53 p.m., Seth ProductEngine wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/169/
> ---
> 
> (Updated March 1, 2011, 1:53 p.m.)
> 
> 
> Review request for Viewer.
> 
> 
> Summary
> ---
> 
> Fixed text editor to display the embedded widgets only if they are in the 
> currently visible area of a text document.
> 
> 
> This addresses bug STORM-721.
> http://jira.secondlife.com/browse/STORM-721
> 
> 
> Diffs
> -
> 
>   indra/llui/lltextbase.cpp 767feb16f05f 
> 
> Diff: http://codereview.secondlife.com/r/169/diff
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Seth
> 
>

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

Re: [opensource-dev] Review Request: Nearby chat history is displaying both Display Names and user.names when the Display Name is not changed from default.

[Twisted Laws]

> On Feb. 27, 2011, 5:57 a.m., Boroondas Gupte wrote:
> >

Works as advertised for me in use in world and I've not found any adverse 
effects.   Aleric's rewriting (with comment) makes the most sense.


- Twisted


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


On Feb. 19, 2011, 9:32 a.m., ardy.lay wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/153/
> ---
> 
> (Updated Feb. 19, 2011, 9:32 a.m.)
> 
> 
> Review request for Viewer.
> 
> 
> Summary
> ---
> 
> https://jira.secondlife.com/browse/VWR-24917
> I have been finding the redundent display of functionally equivalent names in 
> nearby chat history and IM history quite tiresome.
> Simple proposal: If the resident's Display Name is at the default then do not 
> display their user.name.
> https://bitbucket.org/ArdyLay/viewer-development-vwr-24917
> 
> Change is to: LLAvatarName::getCompleteName
> 
> I find the following Callers:
> LLAvatarActions::requestFriendshipDialog
> LLAvatarActions::startIM
> LLAvatarActions::startCall
> LLIMModel::LLIMSession
> LLIMModel::logToFile
> LLPostponedNotification::onAvatarNameCache
> LLUrlEntryAgent::onAvatarNameCache
> LLUrlEntryAgent::getLabel
> LLUrlEntryAgentCompleteName::getName
> 
> // Callback for name resolution of a god/estate message
> llviewermessage.cpp(2149): args["NAME"] = av_name.getCompleteName();
> llviewermessage.cpp(2154): chat.mText = av_name.getCompleteName() + ": " + 
> message;
> 
> static void on_avatar_name_cache_toast ...
> llimview.cpp(108): args["FROM"] = av_name.getCompleteName();
> 
> Some of these make me wonder if this change will cause some defects and 
> should be implimented as a seperate function.
> 
> 
> This addresses bug VWR-24917.
> http://jira.secondlife.com/browse/VWR-24917
> 
> 
> Diffs
> -
> 
>   doc/contributions.txt c10d5e37db1e 
>   indra/llcommon/llavatarname.cpp c10d5e37db1e 
> 
> Diff: http://codereview.secondlife.com/r/153/diff
> 
> 
> Testing
> ---
> 
> I have been using this trivial change and have shared it with a friend, via 
> bitbucket.  We have both built the viewer on Windows 7 and find the resulting 
> reduction in redundent text in chat and IM history on screen to be very 
> helpful.
> 
> 
> Thanks,
> 
> ardy.lay
> 
>

___
Policies 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-24957: Attachments may loose their associated inventory item UUID

[Merov Linden]

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

Ship it!


Seems correct to me.

- Merov


On Feb. 22, 2011, 4:49 a.m., Kitty Barnett wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/161/
> ---
> 
> (Updated Feb. 22, 2011, 4:49 a.m.)
> 
> 
> Review request for Viewer.
> 
> 
> Summary
> ---
> 
> Current flow:
> 1) object->extractAttachmentItemID()
> 2) "same object reattached" condition evaluates true => removeObject calls 
> object->setAttachmentItemID(LLUUID::null)
> 3) the remainder of addObject() executes but the object's mAttachmentItemID 
> is now "LLUUID::null"
> 
> Reversing the order of (1) and (2) should prevent mAttachmentItemID from 
> being - in this specific case accidentally - cleared
> 
> 
> This addresses bug VWR-24957.
> http://jira.secondlife.com/browse/VWR-24957
> 
> 
> Diffs
> -
> 
>   indra/newview/llviewerjointattachment.cpp UNKNOWN 
> 
> Diff: http://codereview.secondlife.com/r/161/diff
> 
> 
> Testing
> ---
> 
> I can't trigger that block for my avie's attachments "on demand" but I 
> actually made this change a while back (before SVC-6766) in response to 
> reports from users and this was the only possibility I could find in the 
> viewer where an attachment may suddenly "forget" its associated inventory 
> item.
> 
> 
> Thanks,
> 
> Kitty
> 
>

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

Re: [opensource-dev] Review Request: (STORM-28) As a User, I want the ability to send my calling card to others

[Merov Linden]

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


I've nothing against lazy evaluation (I actually like that) but I don't like 
"static bool" showing up in the middle of the code to execute a piece of 
initialization once. Is that really something that should be done *once* per 
instance of the application or *once* per instantiation of the object? I'd 
prefer to have that synchronization done in the constructor or in an init 
method or at least have the bool a class or object member (as adequate) that's 
set to true on instantiation.


indra/newview/llpanelpeople.cpp


Please, spell "synchronize" correctly: synchronize_friends_folders


- Merov


On Feb. 21, 2011, 4:57 p.m., Seth ProductEngine wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/159/
> ---
> 
> (Updated Feb. 21, 2011, 4:57 p.m.)
> 
> 
> Review request for Viewer.
> 
> 
> Summary
> ---
> 
> - Added creating own calling card for the user to be able to share it with 
> other residents.
> - Moved calling cards synchronization with friends list to the viewer start 
> up. Previously synchronized upon opening the Friends tab in People side panel.
> - Calling cards for non-friends are not removed upon calling cards 
> synchronization with friends list.
> - Enabled "Share" menu item for calling cards in inventory.
> 
> 
> This addresses bug STORM-28.
> http://jira.secondlife.com/browse/STORM-28
> 
> 
> Diffs
> -
> 
>   indra/newview/llfriendcard.h c10d5e37db1e 
>   indra/newview/llfriendcard.cpp c10d5e37db1e 
>   indra/newview/llinventoryfunctions.cpp c10d5e37db1e 
>   indra/newview/llpanelpeople.cpp c10d5e37db1e 
> 
> Diff: http://codereview.secondlife.com/r/159/diff
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Seth
> 
>

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

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

[Twisted Laws]

> On Feb. 3, 2011, 5:06 a.m., Oz Linden wrote:
> >
> 
> Kitty Barnett wrote:
> Is there any reason to "fix" this in getAvatars() rather than just 
> "fixing" it when processing the CoarseLocationUpdate legacy region message 
> (and when processing the still unused cap)?
> 
> The minimap for instance won't call getAvatars() but will rather access 
> the position directly so it would still be broken for nearby avatars when 
> >1000m.
> 
> Additionally, if the plan is to still enable the http cap at some point 
> in the future then fixing the viewer's handling of that now would ideally 
> mean that the problem is fixed for everyone as soon as it's enabled rather 
> than having to wait another quarter for the next viewer release that contains 
> the fix.

Note that the final version of this patch that was tagged "ship it" was not 
what was in the merge in viewer-development, instead the first version was 
included.


- Twisted


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


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

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

Re: [opensource-dev] Review Request: on-line fix for OPEN-39: (standalone) bitpack_test.o: No such file or directory

[Merov Linden]

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

Ship it!


Seems good to me.

- Merov


On Feb. 26, 2011, 1:38 p.m., Boroondas Gupte wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/168/
> ---
> 
> (Updated Feb. 26, 2011, 1:38 p.m.)
> 
> 
> Review request for Viewer and Aleric Inglewood.
> 
> 
> Summary
> ---
> 
> On standalone, -I"${TUT_INCLUDE_DIR}" was added to the compile flags for 
> integration tests of llcommon when TUT_INCLUDE_DIR might not have been set 
> yet. This lead to a flag -I"", which would confuse g++ and lead to the tests' 
> object files not being found.
> 
> This change makes sure that TUT_INCLUDE_DIR is set by including Tut.cmake, 
> which is responsible for setting it.
> 
> 
> This addresses bug OPEN-39.
> http://jira.secondlife.com/browse/OPEN-39
> 
> 
> Diffs
> -
> 
>   doc/contributions.txt 1013caf84c2e 
>   indra/cmake/LLAddBuildTest.cmake 1013caf84c2e 
> 
> Diff: http://codereview.secondlife.com/r/168/diff
> 
> 
> Testing
> ---
> 
> Clean rebuild with LL_TESTS ON (see also repro instructions on jira)
> 
> 
> 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: STORM-1001: Viewer needlessly hits the "ObjectMedia" cap with thousands of requests

[Merov Linden]

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



indra/llprimitive/lltextureentry.cpp


Looks like you need to add creation/deletion of mMediaEntry if the 
TEM_MEDIA_MASK bit flipped.


- Merov


On Feb. 22, 2011, 11:12 a.m., Kitty Barnett wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/162/
> ---
> 
> (Updated Feb. 22, 2011, 11:12 a.m.)
> 
> 
> Review request for Viewer.
> 
> 
> Summary
> ---
> 
> S32 LLTextureEntry::setMediaTexGen(U8 media) would appear to be the root 
> cause of the bug:
> 
> The header file suggests that:
> 
> // The Media Tex Gen values are bits in a bit field:
> // +--+
> // | .TTM | M = Media Flags (web page), T = LLTextureEntry::eTexGen, . = 
> unused
> // | 76543210 |
> // +--+
> const S32 TEM_MEDIA_MASK  = 0x01;
> const S32 TEM_TEX_GEN_MASK= 0x06;
> 
> and while LLTextureEntry::setTexGen() and LLTextureEntry::setMediaFlags() 
> each properly mask off the supplied parameter with their respective bit mask, 
> setMediaTexGen() will always return TEM_CHANGE_MEDIA even if only texgen has 
> changed while the media flag hasn't (causing 
> LLVOVolume::processUpdateMessage() to queue a request to the cap when it 
> shouldn't).
> 
> Changing it to:
> 
> S32 LLTextureEntry::setMediaTexGen(U8 media)
> {
>   S32 result = setTexGen(media & TEM_TEX_GEN_MASK);
>   result |= setMediaFlags(media & TEM_MEDIA_MASK);
>   return result;
> }
> 
> appears to resolve the issue completely (the cap isn't hit unless an object 
> nearby has media on it, or changes its URL)
> 
> 
> This addresses bug STORM-1001.
> http://jira.secondlife.com/browse/STORM-1001
> 
> 
> Diffs
> -
> 
>   indra/llprimitive/lltextureentry.cpp UNKNOWN 
> 
> Diff: http://codereview.secondlife.com/r/162/diff
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Kitty
> 
>

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