Re: [opensource-dev] Hacking up to Visual Studio 2010 ...

2011-02-17 Thread Oz Linden (Scott Lawrence) 

On 2011-02-16 16:01, Oz Linden (Scott Lawrence) wrote:


Tomorrow and Friday (Feb 17 & 18), Linden Lab is going to be holding 
an in-house Hackathon (stopping work on many other things, getting 
many developers together all at once, and focusing on getting a lot 
done in short time) to upgrade our builds of all our libraries and the 
viewer to a new toolchain, including our new package management tool 
(autobuild ) and Visual 
Studio 2010 for Windows (yes... about time... whatever... we're doing it).


I could use some help with a linux build problem... if you have a 
chance, please check out a copy of


   https://bitbucket.org/lindenlab/autobuild

and arrange for the bin/autobuild command from that repository to be in 
your $PATH


Then check out:

   https://bitbucket.org/oz_linden/viewer-autobuild2010

cd into the top level of that directory, and run:

   autobuild configure -c OpenSourceRelWithDebInfo

   autobuild configure -c OpenSourceRelWithDebInfo

and let me know if it works (and if not, see if you can figure out why 
not).  On our build farm, I'm getting an error:


_[19:13:30]:_ //LogScan//_(1s)_
_[19:13:30]:_ /[LogScan] / from /usr/include/c++/4.1.3/cmath:53,
_[19:13:30]:_ /[LogScan] / from 
/var/opt/teamcity/checkout/L-oz_viewer-autobuild2010/latest/indra/llcommon/linden_common.h:48,
_[19:13:30]:_ /[LogScan] / from 
/var/opt/teamcity/checkout/L-oz_viewer-autobuild2010/latest/indra/newview/tests/lldateutil_test.cpp:26:
_[19:13:30]:_ /[LogScan] //usr/include/bits/huge_val.h:28:18: error: 
missing binary operator before token "("
_[19:13:30]:_ /[LogScan] //usr/include/bits/huge_val.h:30:20: error: 
missing binary operator before token "("



___
Policies 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: When a bake texture upload fails, retry instead of giving up.

2011-02-17 Thread Boroondas Gupte 

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



indra/newview/lltexlayer.h


Is there any reason why you use BOOL instead of bool for this new data 
member? If not, prefer bool. (See 
https://wiki.secondlife.com/wiki/Coding_standard#Linden_Variable_Types )



indra/newview/lltexlayer.cpp


Is "res" for "resolution" or "result"?


- Boroondas


On Feb. 17, 2011, 9 a.m., Thickbrick Sleaford wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/152/
> ---
> 
> (Updated Feb. 17, 2011, 9 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 379da6bd50a5 
>   indra/newview/llassetuploadresponders.cpp 379da6bd50a5 
>   indra/newview/lltexlayer.h 379da6bd50a5 
>   indra/newview/lltexlayer.cpp 379da6bd50a5 
> 
> 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-22220 Chat preferences > font size should increase size of input text as well

2011-02-17 Thread Vadim ProductEngine 


> On Feb. 15, 2011, 6:40 a.m., Vadim ProductEngine wrote:
> > indra/newview/llchatbar.h, line 83
> > 
> >
> > Use tabs for indentation, not spaces.
> > 
> > This note seems to apply to all modified lines in this patch.
> 
> Jonathan Yap wrote:
> Using spaces is specified in the coding standard:
> http://wiki.secondlife.com/wiki/Coding_standard#Indentation
> This preference was made explicit on Feb 3.

Hmmm. This is news to me. Ok, please use tabs anyway to be consistent with 
surrounding code.


> On Feb. 15, 2011, 6:40 a.m., Vadim ProductEngine wrote:
> > indra/newview/llchatbar.cpp, lines 543-549
> > 
> >
> > Do you only update font size on focus changes?
> > Why?
> > That doesn't look right to me.
> 
> Jonathan Yap wrote:
> It might not look/feel right, but the only downside to doing it this way 
> is the message "Click here to chat" is not immediately updated.
> 
> If you are in the middle of typing in the chat input box and change the 
> size preference you will have to click back on the box to continue typing, at 
> which point the new font size is updated in the box.
> 
> The upside to doing it this way is a test for a font change is not being 
> performed every frame or every keystroke.  Oz is happy with it working this 
> way.

It's not the only (and not the best) way to avoid excessive updates. For 
example, you can subscribe to a setting change.
Anyway, this should be implemented with some kind of callback, so that updates 
happen in time.


- Vadim


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


On Feb. 15, 2011, 10:04 a.m., Jonathan Yap wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/139/
> ---
> 
> (Updated Feb. 15, 2011, 10:04 a.m.)
> 
> 
> Review request for Viewer.
> 
> 
> Summary
> ---
> 
> This is a request for help.  I am trying to learn more about c++ and how 
> variables in one class are accessed from another.  For someone who knows what 
> they are doing this is probably a pretty easy question.
> 
> I have been able to set the font size on the chat input box when it is 
> created in llbottomtray.cpp.  I would like to do the same thing when someone 
> clicks in that box to input text; it is possible they have changed the font 
> setting and I would like to apply the size there as well, but I am stuck on 
> how to do this.  I think the right place to do this is in 
> llchatbar.cpp/LLChatBar::onInputEditorGainFocus().
> 
> I have tried all kinds of wrong ways but at this point am stymied.
> 
> Exact steps on how to proceed would be appreciated.
> 
> 
> This addresses bug vwr-0.
> http://jira.secondlife.com/browse/vwr-0
> 
> 
> Diffs
> -
> 
>   indra/newview/llbottomtray.h 3d2e71443c58 
>   indra/newview/llbottomtray.cpp 3d2e71443c58 
> 
> Diff: http://codereview.secondlife.com/r/139/diff
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Jonathan
> 
>

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

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

2011-02-17 Thread Thickbrick Sleaford 

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

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 379da6bd50a5 
  indra/newview/llassetuploadresponders.cpp 379da6bd50a5 
  indra/newview/lltexlayer.h 379da6bd50a5 
  indra/newview/lltexlayer.cpp 379da6bd50a5 

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: (STORM-949) please remove actual usernames from XUI files

2011-02-17 Thread Vadim ProductEngine 

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

Ship it!


Looks fine. :-)

- Vadim


On Feb. 15, 2011, 2:48 p.m., Seth ProductEngine wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/151/
> ---
> 
> (Updated Feb. 15, 2011, 2:48 p.m.)
> 
> 
> Review request for Viewer.
> 
> 
> Summary
> ---
> 
> Actual usernames are replaced with "TestString PleaseIgnore" in EN locale 
> with setting translate="false" flag for affected widgets.
> Translated phrases with actual usernames are removed from XUI files in other 
> locales.
> 
> 
> This addresses bug STORM-949.
> http://jira.secondlife.com/browse/STORM-949
> 
> 
> Diffs
> -
> 
>   indra/newview/skins/default/xui/da/floater_about_land.xml 58fdb5218596 
>   indra/newview/skins/default/xui/da/floater_inventory_item_properties.xml 
> 58fdb5218596 
>   indra/newview/skins/default/xui/da/floater_tools.xml 58fdb5218596 
>   indra/newview/skins/default/xui/da/inspect_avatar.xml 58fdb5218596 
>   indra/newview/skins/default/xui/da/panel_edit_profile.xml 58fdb5218596 
>   indra/newview/skins/default/xui/da/panel_profile_view.xml 58fdb5218596 
>   indra/newview/skins/default/xui/da/sidepanel_task_info.xml 58fdb5218596 
>   indra/newview/skins/default/xui/de/floater_about_land.xml 58fdb5218596 
>   indra/newview/skins/default/xui/de/floater_inventory_item_properties.xml 
> 58fdb5218596 
>   indra/newview/skins/default/xui/de/floater_tools.xml 58fdb5218596 
>   indra/newview/skins/default/xui/de/inspect_avatar.xml 58fdb5218596 
>   indra/newview/skins/default/xui/de/inspect_group.xml 58fdb5218596 
>   indra/newview/skins/default/xui/de/panel_activeim_row.xml 58fdb5218596 
>   indra/newview/skins/default/xui/de/panel_chat_header.xml 58fdb5218596 
>   indra/newview/skins/default/xui/de/panel_edit_profile.xml 58fdb5218596 
>   indra/newview/skins/default/xui/de/panel_instant_message.xml 58fdb5218596 
>   indra/newview/skins/default/xui/de/panel_profile_view.xml 58fdb5218596 
>   indra/newview/skins/default/xui/de/sidepanel_task_info.xml 58fdb5218596 
>   indra/newview/skins/default/xui/en/floater_about_land.xml 58fdb5218596 
>   indra/newview/skins/default/xui/en/floater_inventory_item_properties.xml 
> 58fdb5218596 
>   indra/newview/skins/default/xui/en/floater_tools.xml 58fdb5218596 
>   indra/newview/skins/default/xui/en/inspect_avatar.xml 58fdb5218596 
>   indra/newview/skins/default/xui/en/inspect_group.xml 58fdb5218596 
>   indra/newview/skins/default/xui/en/panel_activeim_row.xml 58fdb5218596 
>   indra/newview/skins/default/xui/en/panel_chat_header.xml 58fdb5218596 
>   indra/newview/skins/default/xui/en/panel_edit_profile.xml 58fdb5218596 
>   indra/newview/skins/default/xui/en/panel_instant_message.xml 58fdb5218596 
>   indra/newview/skins/default/xui/en/panel_profile_view.xml 58fdb5218596 
>   indra/newview/skins/default/xui/en/sidepanel_task_info.xml 58fdb5218596 
>   indra/newview/skins/default/xui/es/floater_about_land.xml 58fdb5218596 
>   indra/newview/skins/default/xui/es/floater_inventory_item_properties.xml 
> 58fdb5218596 
>   indra/newview/skins/default/xui/es/floater_tools.xml 58fdb5218596 
>   indra/newview/skins/default/xui/es/inspect_avatar.xml 58fdb5218596 
>   indra/newview/skins/default/xui/es/panel_edit_profile.xml 58fdb5218596 
>   indra/newview/skins/default/xui/es/panel_profile_view.xml 58fdb5218596 
>   indra/newview/skins/default/xui/es/sidepanel_task_info.xml 58fdb5218596 
>   indra/newview/skins/default/xui/fr/floater_about_land.xml 58fdb5218596 
>   indra/newview/skins/default/xui/fr/floater_inventory_item_properties.xml 
> 58fdb5218596 
>   indra/newview/skins/default/xui/fr/floater_tools.xml 58fdb5218596 
>   indra/newview/skins/default/xui/fr/inspect_avatar.xml 58fdb5218596 
>   indra/newview/skins/default/xui/fr/inspect_group.xml 58fdb5218596 
>   indra/newview/skins/default/xui/fr/panel_activeim_row.xml 58fdb5218596 
>   indra/newview/skins/default/xui/fr/panel_chat_header.xml 58fdb5218596 
>   indra/newview/skins/default/xui/fr/panel_edit_profile.xml 58fdb5218596 
>   indra/newview/skins/default/xui/fr/panel_instant_message.xml 58fdb5218596 
>   indra/newview/skins/default/xui/fr/panel_profile_view.xml 58fdb5218596 
>   indra/newview/skins/default/xui/fr/sidepanel_task_info.xml 58fdb5218596 
>   indra/newview/skins/default/xui/it/floater_about_land.xml 58fdb5218596 
>   indra/newview/skins/default/xui/it/floater_inventory_item_properties.xml 
> 58fdb5218596 
>   indra/newview/skins/default/xui/it/floater_tools.xml 58fdb5218596 
>   indra/newview/skins/default/xui/it/panel_profile_view.xml 58fdb5218596 
>   indra/newview/skins/default/xui/it/sidepanel_task_info.xml 58fdb

Re: [opensource-dev] UI - Picks - no delete button

2011-02-17 Thread Anya Kanevsky 
Daniel, please file a jira for the Picks problem, preferably with
screenshots. Please file any jiras related to Web profiles as separate
issues.
Thanks!


2011/2/16 Daniel 

> What I see on 2.7.0(221148) was:
>
> * At first, trashcan not visible in MyProfile > MyPicks.
> * After using right arrow pick info button and then Edit button,
> trashcan appears and works
> * Right click on avatar, and MyProfile from list opens a window, but
> does not bring up my web profile the first time,
>   it does the second time, but does not show my Picks even though I am
> the owner of the profile.
>
> Having both kinds of profiles and neither of them working right is
> confusing to users.
>
> > From: Ann Otoole
> >
> > I don't see any trashcan. Expected. Looked. Not there. v2.5. No way to
> delete
> > picks.
> >
> >
> >
>
> ___
> Policies 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