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

2011-02-02 Thread Anya Kanevsky 
 Tuesday, February 1 General Notes
--

   - Sprint planning today - no standup
   - MMOTD: Oz

Team Status
--
 Merov Linden
--

*PAST*

   - Triage JIRA for sprint planning meeting
   - Code reviews

*FUTURE*

   - Sprint planning
   - STORM-746 : KDU Improvements: Compress j2c with precincts

*IMPEDIMENTS*

   - none

Grumpity ProductEngine
--

*PAST*

   - Sprint 11 Theme - Customization
   - Sprint review
   - jira wrangling to prep for sprint planning
   - find victim for inventory issues (STORM-526)
   - Maestro commented on STORM-379 (Buy copy of floater)

*FUTURE*

   - Sprint planning
   - continue to prod others to resolve impediments
   - Product triage

*IMPEDIMENTS*

   - moving

Paul ProductEngine
--

*PAST*

   - BUG STORM-655 (mismatched filter extension in snapshot floater (jpeg vs
   jpg).)
  - Fixed and sent for review.
   - BUG STORM-680 (Avaline callers are added to the Recent list)
  - WIP. Estimate ~ 6-8 hours.

*FUTURE*

   - BUG STORM-680 (Avaline callers are added to the Recent list)

*IMPEDIMENTS*

   - none

Seth Productengine
--

*PAST*

   - BUG (STORM-219) "Folders Always By Name" and "System Folders To Top"
   options are missing from the Inventory menu. Can't sort folders!
  - Fixed with patch for STORM-316.
   - BUG (STORM-433) Friendship offer shifted up and placed over "Second
   Life" text
  - Investigating how friendship offers notifications are placed inside
  IM chat history.

*FUTURE*

   - BUG (STORM-433) Friendship offer shifted up and placed over "Second
   Life" text

*IMPEDIMENTS*

   - STORM-316

Vadim Productengine
--

*PAST*

   - STORM-2 (Customizable viewer layouts):
  - Implementing saving sidetray state. ETA: 2d.

*FUTURE*

   - Continue with STORM-2.

*IMPEDIMENTS*

   - Bug STORM-465 (Missing Strings from strings.xml):
  - 
Waiting for Q to provide code-related feedback.

Andrey ProductEngine
--

*PAST*

   - picked up 2.5.0 Beta3 r220094 build
   - smoke tests have been passed on Linux, OSX, and Windows, refer to the
   spreadsheet
   - integrity test has been failed by VWR-24681, but I think this is some
   kind of a server-side issue
   - 2.5.0 bug-fixes verification almost has been completed, refer to
   spreadsheet
  - 87 tickets marked as "Deferred" because TPE has no clue how to
  verify those
   - reported 4 tickets
   - picked up v-d 220024 build
  - verified 3 issues
  - proceeded with regression testing of v-d branch

*FUTURE*

   - proceed with regression testing of v-d build

*IMPEDIMENTS*

   - none


Wolfpup Lowenhar
--

*PAST*

   - Worked @ RL .
   - STORM-236 : waiting for Oz's suggestions.
   - Attended Sprint Planning Metting.
   - Attended Merov’s OH.

*FUTURE*

   - Work @ RL
   - STORM-941 : Dig into code and then email Oz and Leyla concerning
   possible fix as this is related to the DN code and there is some place that
   was missed in llimview that the logs still gets generated using legacy as a
   fallback instead of converting legacy to user name.

*IMPEDIMENTS*

   - STORM-236 : waiting for Oz's suggestions.
   - Not enough time to actually work on code.

Cummere Mayo
--

*PAST*

   - jira work
   - another blog post

*FUTURE*

   - more jira work
   - more blogs

*IMPEDIMENTS*

   - many
___
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] Need Clarification on interfacing with web-based UI elements

2011-02-02 Thread Tateru Nino 
Seems to me that as more of that goes Web-side it needs more 
comprehensive standardization, documentation and versioning.


On 2/02/2011 2:36 PM, Arrehn Oberlander wrote:
This is an open question I've tried to ask at a few different linden 
office hours, but haven't yet received a response one way or the other.


There's a couple different viewer UI elements now in the pipeline that 
are effectively full web pages- the search window, and now the profile 
window. It seems like there is more to come.


As a community developer interested in customizing that user interface 
for particular audiences, can LL clarify a best practice for working 
with these elements?


From a glance it appears that the presentation info and data model are 
commingled, complicating client-side customization of the presentation.


It may be possible to scrape out data, but unmanaged minor server-side 
adjustments to the presentation page may break scraping activity 
suddenly without warning. For an example of this, one can look at the 
number of times LSL scripts which display profile pictures by scraping 
UUID's from web lookups have been broken over the last few years.


I'm hoping that LL can clarify which interface a community developer 
can use to request and retreive this web-based data, particularly for 
avatar profile page information, that will not be prone to casual 
breakage after a third party viewer has been released.


Thanks, and my apologies if the answer for this is someplace obvious 
I've overlooked.




___
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


--
Tateru Nino
http://dwellonit.taterunino.net/

___
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 project VCExpress Command Line Build Need Testers

2011-02-02 Thread Nicky Perian 
I tested this on my machine and in viewer-autobuild after "autobuild configure 
-c OpenSourceRelWithDebInfo" but,
my machine has both Express and Pro present.

>From /viewer-autobuild
 

vcbuild.exe /logfile:Secondlife.log build-vc80\Secondlife.sln /platform=win32 
"RelWithDebInfo|Win32"


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

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

2011-02-02 Thread Kent Quirk 

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


So I have a couple of issues with this patch:

* I'm worried about the translation impact, how these strings are used and 
where. Should they be localized? Should they not be localized? I find it hard 
to believe that we ONLY need to translate Home and End. 
* The "1" key is duplicated. Are there others? 
* I think the single-letter keys should be placed in a more useful order so 
that we can easily find missing items. Keyboard order (especially since 
keyboards differ) is not good enough.
* I'm worried about the naming convention; single-letter names (ahem, yes, I 
know who's talking here) can be rather ambiguous. It's probably the easiest fix 
-- anything else may require much more extensive changes -- but I'm worried 
about this. Is this fix robust under localization?

I haven't had time to investigate these issues yet; does someone else have the 
knowledge to discuss?


- Kent


On Jan. 19, 2011, 8:30 a.m., Vadim ProductEngine wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/108/
> ---
> 
> (Updated Jan. 19, 2011, 8:30 a.m.)
> 
> 
> Review request for Viewer.
> 
> 
> Summary
> ---
> 
> Made all keys localizable.
> 
> 
> This addresses bug STORM-465.
> http://jira.secondlife.com/browse/STORM-465
> 
> 
> Diffs
> -
> 
>   indra/newview/skins/default/xui/en/strings.xml 38465c40c060 
> 
> Diff: http://codereview.secondlife.com/r/108/diff
> 
> 
> Testing
> ---
> 
> Tested on Linux. No keys produce the warning for me.
> 
> 
> Thanks,
> 
> Vadim
> 
>

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

[opensource-dev] llpaneloutfitedit.cpp failure to compile with vs2010 and boost 1.45.

2011-02-02 Thread Nicky Perian 

std::for_each(item_set.begin(), item_set.end(), boost::bind( 
&uuid_vec_t::push_back, &uuid_list, _1));



..\..\newview\llpaneloutfitedit.cpp(1332): error C2780: 
'boost::_bi::bind_t<_bi::dm_result::type,boost::_mfi::dm,_bi::list_av_1::type> boost::bind(M T::* 
,A1)' : expects 2 arguments - 3 provided
 
 C:\lindenhg\vcexpress2010build\libraries\include\boost/bind/bind.hpp(1728) : 
see declaration of 'boost::bind'


I have diffed and boost1-39 and i cant find differences.

Need pointers to help solve.



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

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

2011-02-02 Thread Vadim ProductEngine 


> On Feb. 2, 2011, 8:56 a.m., Kent Quirk wrote:
> > So I have a couple of issues with this patch:
> > 
> > * I'm worried about the translation impact, how these strings are used and 
> > where. Should they be localized? Should they not be localized? I find it 
> > hard to believe that we ONLY need to translate Home and End. 
> > * The "1" key is duplicated. Are there others? 
> > * I think the single-letter keys should be placed in a more useful order so 
> > that we can easily find missing items. Keyboard order (especially since 
> > keyboards differ) is not good enough.
> > * I'm worried about the naming convention; single-letter names (ahem, yes, 
> > I know who's talking here) can be rather ambiguous. It's probably the 
> > easiest fix -- anything else may require much more extensive changes -- but 
> > I'm worried about this. Is this fix robust under localization?
> > 
> > I haven't had time to investigate these issues yet; does someone else have 
> > the knowledge to discuss?
> >

1) AFAIU, only those keys need translation that are currrently used in menu 
shortcuts (see menu_*.xml).
   We don't know in advance what keys we're gonna use in future shortcuts, so 
it makes sense to make them all localizable.
2) Thanks, the "1" is indeed duplicated. Looks like a copy&paste issue.
3) Ok, the order doesn't matter to me. I can change it if you want.
4) I borrowed the naming style from existing code (see llkeyboard.cpp). 
Moreover, we tried adding "Key_" prefix to key names for the same reasons  as 
you say, but had to roll that change back because it had broken translation of 
older shortcuts (see comments in STORM-362).


- Vadim


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


On Jan. 19, 2011, 8:30 a.m., Vadim ProductEngine wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/108/
> ---
> 
> (Updated Jan. 19, 2011, 8:30 a.m.)
> 
> 
> Review request for Viewer.
> 
> 
> Summary
> ---
> 
> Made all keys localizable.
> 
> 
> This addresses bug STORM-465.
> http://jira.secondlife.com/browse/STORM-465
> 
> 
> Diffs
> -
> 
>   indra/newview/skins/default/xui/en/strings.xml 38465c40c060 
> 
> Diff: http://codereview.secondlife.com/r/108/diff
> 
> 
> Testing
> ---
> 
> Tested on Linux. No keys produce the warning for me.
> 
> 
> Thanks,
> 
> Vadim
> 
>

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

[opensource-dev] Daily Scrum Summary - Wednesday, February 2

2011-02-02 Thread Anya Kanevsky 
 Wednesday, February 2 General Notes
--

   - Sprint 11 Theme - Customization
   - Please do not pick up issues tagged with needs-design until the tag has
   been removed.
   - MMOTD: Merov
   - Please remember to move issues to current Sprint when a) starting work
   on them or b) accepting issues from the community
   - Groundhog day!

Team Status
--
 Merov Linden
--

*PAST*

   - Meetings, meetings: sprint 11 planning, VWR triaging and OH all in one
   day...
   - PO build: done
   - Merge Monkeying: cleaned up sprint 10 and previous
   - Triage SNOW JIRA
   - Dig into Coverity findings

*FUTURE*

   - MM
   - STORM-746 : KDU Improvements: Compress j2c with precincts

*IMPEDIMENTS*

   - none

Oz Linden
--

*PAST*

   - Meetings most of yesterday
   - Other non-Snowstorm activities

*FUTURE*

   - Try to fix using autobuild with VS Express

*IMPEDIMENTS*

   - snow, ice, snow, ice

Q Linden
--

*PAST*

   - STORM-465
   - Coverity stuff
   - triage
   - lots of ad hoc meetings
   - snow

*FUTURE*

   - more snow
   - ooo doctor / pt
   - triage bot

*IMPEDIMENTS*

   - none

Grumpity ProductEngine
--

*PAST*

   - Sprint planning
   - VWR triage
   - Jira wrangling
  - updated needs-design issues
  - closed dupes of issues in current sprint
  - moved issues accepted from community into current sprint

*FUTURE*

   - PEQA deferred issues triage with Bambers
   - continue to prod others to resolve impediments
  - STORM-379, STORM-465

*IMPEDIMENTS*

   - moving
   - sick

Paul ProductEngine
--

*PAST*

   - BUG STORM-655 (mismatched filter extension in snapshot floater (jpeg vs
   jpg).)
  - Fixed and sent for review.
   - BUG STORM-680 (Avaline callers are added to the Recent list)
  - WIP. Estimate ~ 6-8 hours.

*FUTURE*

   - BUG STORM-680 (Avaline callers are added to the Recent list)

*IMPEDIMENTS*

   - none

Seth Productengine
--

*PAST*

   - BUG (STORM-379) Content permissions aren't refreshed in the "Buy copy
   of" floater.
  - Investigating possible fix with updating "Buy copy of" floater each
  time it is shown.

*FUTURE*

   - BUG (STORM-433) Friendship offer shifted up and placed over "Second
   Life" text

*IMPEDIMENTS*

   - BUG (STORM-379) Content permissions aren't refreshed in the "Buy copy
   of" floater.
  - Asked in JIRA whether the bug should be fixed in a way that may
  increase server load.

Vadim Productengine
--

*PAST*

   - STORM-2 (Customizable viewer layouts):
  - Implementing saving sidetray state. ETA: 1d.
   - Sprint planning meeting.

*FUTURE*

   - Continue with STORM-2.

*IMPEDIMENTS*

   - STORM-465 (Missing Strings from strings.xml):
  - 
Waiting for Q to provide code-related feedback.

Andrey ProductEngine
--

*PAST*

   - picked up 2.5.0 Beta3 r220094 build
   - smoke tests have been passed on Linux, OSX, and Windows, refer to the
   spreadsheet
   - integrity test has been failed by VWR-24681, but I think this is some
   kind of a server-side issue
   - 2.5.0 bug-fixes verification almost has been completed, refer to
   spreadsheet
  - 87 tickets marked as "Deferred" because TPE has no clue how to
  verify those
   - reported 4 tickets
   - picked up v-d 220024 build
  - verified 3 issues
  - proceeded with regression testing of v-d branch

*FUTURE*

   - proceed with regression testing of v-d build

*IMPEDIMENTS*

   - none


Wolfpup Lowenhar
--

*PAST*

   - Worked @ RL .
   - STORM-236 : read Oz's comments on JIRA
  - emailed Oz with comments concerning suggestions and what it could
  entail to get suggested capability in the context menu for the
bottom tray
  and the other issues in the rest of the comment.
   - STORM-941 : Began looking in code for possible places where the issue
   could be happening.
   - Attended SnowStorm OH which ended up being canceled due to weather in
   Boston

*FUTURE*

   - Work @ RL
   - STORM-941 : email Oz and Leyla concerning possible areas that could be
   causing the problem.

*IMPEDIMENTS*

   - STORM-236 : waiting for new graphics and name to call the panel.
   - Not enough time to actually work on code.

Jonathan Yap
--

*PAST*

   - VWR-24628 (Descriptive text missing next to first checkbox in About
   Land/Access)
  - This had to be fixed first in order to work on Storm - 953. 4 other
  people helped with this! This was my proudest moment as a
developer. Great
  team effort. Easy fix but caused by low-level routine change.
   - STORM-953 (Clarify what happens when you uncheck Allow Public Access)
  - Needs a very quick design review. See image attached to jira
  https://jira.secondlife.com/se

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

2011-02-02 Thread Oz Linden 

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



indra/newview/llworld.cpp


I would strongly prefer to see this rearranged as properly nested 
if/then/else rather than using continue.

Similarly, I'd like to have the break replaced by just adding another exit 
condition to the 'for' loop.



- Oz


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

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

Re: [opensource-dev] Help prevent DOS line endings...

2011-02-02 Thread Oz Linden (Scott Lawrence) 
On 2011-02-01 15:33, Discrete Dreamscape wrote:
> Possible cover-all solution: use Mercurial's "eol" extension. It's 
> worked pretty well for me so far, and handily autofixed all the DOS 
> endings in a particular fork I looked at in one go. It works much like 
> the autoprops configuration does in Subversion; hopefully with less pain.
>
> Enable it (should be included by default in all recent versions, dunno 
> about Tortoise) by adding the following section and options to your 
> system-wide or repo-local .hgrc file:
>
> [extensions]
> eol =
>
> Then add a ".hgeol" file to the root of the repository (it can be 
> versioned and thus easily distributed!), and fill it with whatever 
> standard Mercurial pattern entries are needed, like so:
>
> [patterns]
> **.py = native
> **.txt = native
> **.h = native
> **.cpp = native
> **Makefile = LF
>
> As soon as this file exists and the extension is active for you, 
> further hg commands will immediately treat any non-conforming 
> line-endings as modifications to your current working copy. Hope this 
> is helpful; if so, it could be added to that page as well.

I considered adding that, but didn't know whether some of the 
windows-specific files might be broken by it (if so, they too could be 
configured).   Does anyone know?

Could always put this into a test repo and run a TeamCity build
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

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

2011-02-02 Thread Kent Quirk 


> On Feb. 2, 2011, 8:56 a.m., Kent Quirk wrote:
> > So I have a couple of issues with this patch:
> > 
> > * I'm worried about the translation impact, how these strings are used and 
> > where. Should they be localized? Should they not be localized? I find it 
> > hard to believe that we ONLY need to translate Home and End. 
> > * The "1" key is duplicated. Are there others? 
> > * I think the single-letter keys should be placed in a more useful order so 
> > that we can easily find missing items. Keyboard order (especially since 
> > keyboards differ) is not good enough.
> > * I'm worried about the naming convention; single-letter names (ahem, yes, 
> > I know who's talking here) can be rather ambiguous. It's probably the 
> > easiest fix -- anything else may require much more extensive changes -- but 
> > I'm worried about this. Is this fix robust under localization?
> > 
> > I haven't had time to investigate these issues yet; does someone else have 
> > the knowledge to discuss?
> >
> 
> Vadim ProductEngine wrote:
> 1) AFAIU, only those keys need translation that are currrently used in 
> menu shortcuts (see menu_*.xml).
>We don't know in advance what keys we're gonna use in future 
> shortcuts, so it makes sense to make them all localizable.
> 2) Thanks, the "1" is indeed duplicated. Looks like a copy&paste issue.
> 3) Ok, the order doesn't matter to me. I can change it if you want.
> 4) I borrowed the naming style from existing code (see llkeyboard.cpp). 
> Moreover, we tried adding "Key_" prefix to key names for the same reasons  as 
> you say, but had to roll that change back because it had broken translation 
> of older shortcuts (see comments in STORM-362).

I would like to see a revised changeset please, reflecting 2 and 3. I'm happy 
with your responses to 1 and 4.


- Kent


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


On Jan. 19, 2011, 8:30 a.m., Vadim ProductEngine wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/108/
> ---
> 
> (Updated Jan. 19, 2011, 8:30 a.m.)
> 
> 
> Review request for Viewer.
> 
> 
> Summary
> ---
> 
> Made all keys localizable.
> 
> 
> This addresses bug STORM-465.
> http://jira.secondlife.com/browse/STORM-465
> 
> 
> Diffs
> -
> 
>   indra/newview/skins/default/xui/en/strings.xml 38465c40c060 
> 
> Diff: http://codereview.secondlife.com/r/108/diff
> 
> 
> Testing
> ---
> 
> Tested on Linux. No keys produce the warning for me.
> 
> 
> Thanks,
> 
> Vadim
> 
>

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

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

2011-02-02 Thread Torben Trautman 


> On Feb. 2, 2011, 8:56 a.m., Kent Quirk wrote:
> > So I have a couple of issues with this patch:
> > 
> > * I'm worried about the translation impact, how these strings are used and 
> > where. Should they be localized? Should they not be localized? I find it 
> > hard to believe that we ONLY need to translate Home and End. 
> > * The "1" key is duplicated. Are there others? 
> > * I think the single-letter keys should be placed in a more useful order so 
> > that we can easily find missing items. Keyboard order (especially since 
> > keyboards differ) is not good enough.
> > * I'm worried about the naming convention; single-letter names (ahem, yes, 
> > I know who's talking here) can be rather ambiguous. It's probably the 
> > easiest fix -- anything else may require much more extensive changes -- but 
> > I'm worried about this. Is this fix robust under localization?
> > 
> > I haven't had time to investigate these issues yet; does someone else have 
> > the knowledge to discuss?
> >
> 
> Vadim ProductEngine wrote:
> 1) AFAIU, only those keys need translation that are currrently used in 
> menu shortcuts (see menu_*.xml).
>We don't know in advance what keys we're gonna use in future 
> shortcuts, so it makes sense to make them all localizable.
> 2) Thanks, the "1" is indeed duplicated. Looks like a copy&paste issue.
> 3) Ok, the order doesn't matter to me. I can change it if you want.
> 4) I borrowed the naming style from existing code (see llkeyboard.cpp). 
> Moreover, we tried adding "Key_" prefix to key names for the same reasons  as 
> you say, but had to roll that change back because it had broken translation 
> of older shortcuts (see comments in STORM-362).
> 
> Kent Quirk wrote:
> I would like to see a revised changeset please, reflecting 2 and 3. I'm 
> happy with your responses to 1 and 4.

There is a few more keys that have been localized or need to be localized. In 
german we also translated Shift (Umschalt) and Home (Zuhause)[which is a wrong 
translation by the way]. We still need to localize ` (snapshot to disk and 
region debug console shortcuts don´t work in german) and \ (Look at last 
speaker shortcut doesn´t work). I´m pretty sure this is also true at least for 
french.

Hope this helps :)


- Torben


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


On Jan. 19, 2011, 8:30 a.m., Vadim ProductEngine wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/108/
> ---
> 
> (Updated Jan. 19, 2011, 8:30 a.m.)
> 
> 
> Review request for Viewer.
> 
> 
> Summary
> ---
> 
> Made all keys localizable.
> 
> 
> This addresses bug STORM-465.
> http://jira.secondlife.com/browse/STORM-465
> 
> 
> Diffs
> -
> 
>   indra/newview/skins/default/xui/en/strings.xml 38465c40c060 
> 
> Diff: http://codereview.secondlife.com/r/108/diff
> 
> 
> Testing
> ---
> 
> Tested on Linux. No keys produce the warning for me.
> 
> 
> Thanks,
> 
> Vadim
> 
>

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

Re: [opensource-dev] Help prevent DOS line endings...

2011-02-02 Thread Discrete Dreamscape 
This is from the help page on the extension:


The optional "[repository]" section specifies the line endings to use for
files stored
in the repository. It has a single setting, "native", which determines the
storage line
endings for files declared as "native" in the "[patterns]" section. It can
be set to
"LF" or "CRLF". The default is "LF". For example, this means that on
Windows, files
configured as "native" ("CRLF" by default) will be converted to "LF" when
stored in the
repository. Files declared as "LF", "CRLF", or "BIN" in the "[patterns]"
section are
always stored as-is in the repository.

Example versioned ".hgeol" file:

  [patterns]
  **.py = native
  **.vcproj = CRLF
  **.txt = native
  Makefile = LF
  **.jpg = BIN

  [repository]
  native = LF


So if a file pattern is specifically declared to have Windows line-endings,
it should remain that way for everyone and in the repository.. probably
worth some quick testing.


Discrete


On Wed, Feb 2, 2011 at 3:06 PM, Oz Linden (Scott Lawrence)  wrote:

> On 2011-02-01 15:33, Discrete Dreamscape wrote:
>
>> Possible cover-all solution: use Mercurial's "eol" extension. It's worked
>> pretty well for me so far, and handily autofixed all the DOS endings in a
>> particular fork I looked at in one go. It works much like the autoprops
>> configuration does in Subversion; hopefully with less pain.
>>
>> Enable it (should be included by default in all recent versions, dunno
>> about Tortoise) by adding the following section and options to your
>> system-wide or repo-local .hgrc file:
>>
>> [extensions]
>> eol =
>>
>> Then add a ".hgeol" file to the root of the repository (it can be
>> versioned and thus easily distributed!), and fill it with whatever standard
>> Mercurial pattern entries are needed, like so:
>>
>> [patterns]
>> **.py = native
>> **.txt = native
>> **.h = native
>> **.cpp = native
>> **Makefile = LF
>>
>> As soon as this file exists and the extension is active for you, further
>> hg commands will immediately treat any non-conforming line-endings as
>> modifications to your current working copy. Hope this is helpful; if so, it
>> could be added to that page as well.
>>
>
> I considered adding that, but didn't know whether some of the
> windows-specific files might be broken by it (if so, they too could be
> configured).   Does anyone know?
>
> Could always put this into a test repo and run a TeamCity build
>
___
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

2011-02-02 Thread Twisted Laws 

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


Changes
---

I redid the patch, hopefully making the comments more acceptable and took out 
the use of continue.   I moved retrieval of the character positions before the 
world positions as I found cases where the information would be incorrect right 
near 1024 testing with a couple people below 1024, and a couple people above.  
Note this is a replacement patch.


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 (updated)
-

  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: STORM-864: As as developer, I would like an object oriented wrapper to make safe use of memory pools easier

2011-02-02 Thread Merov Linden 

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



indra/llcommon/llaprpool.h


I think it's be more clear to use an explicit name like "getAPRPool()" 
rather than the function operator here. It produces hard to read code in a 
couple of places and it's just plain unclear what "myPool()" really does.



indra/llmessage/llpumpio.cpp


An example where the use of operator() is particularly unsightly...


- Merov


On Jan. 29, 2011, 9:10 a.m., Aleric Inglewood wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/99/
> ---
> 
> (Updated Jan. 29, 2011, 9:10 a.m.)
> 
> 
> Review request for Viewer.
> 
> 
> Summary
> ---
> 
> Please see http://jira.secondlife.com/browse/STORM-864
> 
> I made a mercurial repository available for testing here:
> 
> hg clone https://bitbucket.org/aleric/viewer-development-storm-864
> 
> From the commit message:
> 
> Introduces a LLThreadLocalData class that can be
> accessed through the static LLThread::tldata().
> Currently this object contains two (public) thread-local
> objects: a LLAPRRootPool and a LLVolatileAPRPool.
> 
> The first is the general memory pool used by this thread
> (and this thread alone), while the second is intended
> for short lived memory allocations (needed for APR).
> The advantages of not mixing those two is that the latter
> is used most frequently, and as a result of it's nature
> can be destroyed and reconstructed on a "regular" basis.
> 
> This patch adds LLAPRPool (completely replacing the old one),
> which is a wrapper around apr_pool_t* and has complete
> thread-safity checking.
> 
> Whenever an apr call requires memory for some resource,
> a memory pool in the form of an LLAPRPool object can
> be created with the same life-time as this resource;
> assuring clean up of the memory no sooner, but also
> not much later than the life-time of the resource
> that needs the memory.
> 
> Many, many function calls and constructors had the
> pool parameter simply removed (it is no longer the
> concern of the developer, if you don't write code
> that actually does an libapr call then you are no
> longer bothered with memory pools at all).
> 
> However, I kept the notion of short-lived and
> long-lived allocations alive (see my remark in
> the jira here: 
> https://jira.secondlife.com/browse/STORM-864?focusedCommentId=235356&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-235356
> which requires that the LLAPRFile API needs
> to allow the user to specify how long they
> think a file will stay open. By choosing
> 'short_lived' as default for the constructor
> that immediately opens a file, the number of
> instances where this needs to be specified is
> drastically reduced however (obviously, any
> automatic LLAPRFile is short lived).
> 
> 
> This addresses bug STORM-864.
> http://jira.secondlife.com/browse/STORM-864
> 
> 
> Diffs
> -
> 
>   doc/contributions.txt fe7fe04ccc9a 
>   indra/llaudio/llaudioengine_fmod.cpp fe7fe04ccc9a 
>   indra/llaudio/llvorbisencode.cpp fe7fe04ccc9a 
>   indra/llcharacter/llbvhloader.cpp fe7fe04ccc9a 
>   indra/llcharacter/llkeyframemotionparam.cpp fe7fe04ccc9a 
>   indra/llcharacter/llstatemachine.cpp fe7fe04ccc9a 
>   indra/llcommon/CMakeLists.txt fe7fe04ccc9a 
>   indra/llcommon/llapp.cpp fe7fe04ccc9a 
>   indra/llcommon/llapr.h fe7fe04ccc9a 
>   indra/llcommon/llapr.cpp fe7fe04ccc9a 
>   indra/llcommon/llaprpool.h PRE-CREATION 
>   indra/llcommon/llaprpool.cpp PRE-CREATION 
>   indra/llcommon/llcommon.h fe7fe04ccc9a 
>   indra/llcommon/llcommon.cpp fe7fe04ccc9a 
>   indra/llcommon/llerror.h fe7fe04ccc9a 
>   indra/llcommon/llerror.cpp fe7fe04ccc9a 
>   indra/llcommon/llfixedbuffer.cpp fe7fe04ccc9a 
>   indra/llcommon/llscopedvolatileaprpool.h PRE-CREATION 
>   indra/llcommon/llthread.h fe7fe04ccc9a 
>   indra/llcommon/llthread.cpp fe7fe04ccc9a 
>   indra/llcommon/llthreadsafequeue.h fe7fe04ccc9a 
>   indra/llcommon/llthreadsafequeue.cpp fe7fe04ccc9a 
>   indra/llcommon/llworkerthread.h fe7fe04ccc9a 
>   indra/llcommon/llworkerthread.cpp fe7fe04ccc9a 
>   indra/llcrashlogger/llcrashlogger.cpp fe7fe04ccc9a 
>   indra/llimage/llimage.cpp fe7fe04ccc9a 
>   indra/llimage/llimagedimensionsinfo.cpp fe7fe04ccc9a 
>   indra/llimage/llimagej2c.cpp fe7fe04ccc9a 
>   indra/llimage/llimageworker.h fe7fe04ccc9a 
>   indra/llimage/llimageworker.cpp fe7fe04ccc9a 
>   indra/llmath/llvolumemgr.cpp fe7fe04ccc9a 
>   indra/llmessage/llares.cpp fe7fe04ccc9a 
>   indra/llmessage/llcurl.cpp fe7fe04ccc9a 
>   indra/llmessage/lliohttpserver.h fe7fe04ccc9a