[opensource-dev] Review Request: STORM-1521 [previously VWR-25588]: Zi's proposed fix for FIRE-543 - Hovertext renders as overlay on top of everything else

2011-07-21 Thread Boroondas Gupte 

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

Review request for Viewer.


Summary
---

Set the z coordinate of hovertext such that it gets occluded by stuff in front 
of it.


This addresses bugs SH-489, VWR-24017 and VWR-25588.
http://jira.secondlife.com/browse/SH-489
http://jira.secondlife.com/browse/VWR-24017
http://jira.secondlife.com/browse/VWR-25588


Diffs
-

  doc/contributions.txt 46c7b36793c9 
  indra/llrender/llfontgl.cpp 46c7b36793c9 

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


Testing
---

Merged this change with e67da2c6e312 (as I still cannot build 
viewer-development tip) and rebuilt. Verified that my nametag and an objects 
llSetText hovertext were correctly occluded by another object in front of them.


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-1521 [previously VWR-25588]: Zi's proposed fix for FIRE-543 - Hovertext renders as overlay on top of everything else

2011-07-21 Thread Boroondas Gupte 

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

(Updated July 21, 2011, 2:44 a.m.)


Review request for Viewer.


Summary (updated)
---

Set the z (depth) coordinate of hovertext such that the hovertext gets occluded 
by stuff in front of it.


This addresses bugs SH-489, VWR-24017 and VWR-25588.
http://jira.secondlife.com/browse/SH-489
http://jira.secondlife.com/browse/VWR-24017
http://jira.secondlife.com/browse/VWR-25588


Diffs
-

  doc/contributions.txt 46c7b36793c9 
  indra/llrender/llfontgl.cpp 46c7b36793c9 

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


Testing
---

Merged this change with e67da2c6e312 (as I still cannot build 
viewer-development tip) and rebuilt. Verified that my nametag and an objects 
llSetText hovertext were correctly occluded by another object in front of them.


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-1521 [previously VWR-25588]: Zi's proposed fix for FIRE-543 - Hovertext renders as overlay on top of everything else

2011-07-21 Thread Boroondas Gupte 

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

(Updated July 21, 2011, 2:55 a.m.)


Review request for Viewer.


Changes
---

Made in-code comment a bit clearer.


Summary
---

Set the z (depth) coordinate of hovertext such that the hovertext gets occluded 
by stuff in front of it.


This addresses bugs SH-489, VWR-24017 and VWR-25588.
http://jira.secondlife.com/browse/SH-489
http://jira.secondlife.com/browse/VWR-24017
http://jira.secondlife.com/browse/VWR-25588


Diffs (updated)
-

  doc/contributions.txt 46c7b36793c9 
  indra/llrender/llfontgl.cpp 46c7b36793c9 

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


Testing
---

Merged this change with e67da2c6e312 (as I still cannot build 
viewer-development tip) and rebuilt. Verified that my nametag and an objects 
llSetText hovertext were correctly occluded by another object in front of them.


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-1458 ([crashhunters] crash at LLParticipantList::LLParticipantListMenu::isGroupModerator() [secondlife-bin llparticipantlist.cpp])

2011-07-21 Thread Paul ProductEngine 

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

(Updated July 21, 2011, 3:27 a.m.)


Review request for Viewer.


Changes
---

Updated diff according to Boroondas' commentaries


Summary
---

- Added null checking


This addresses bug storm-1458.
http://jira.secondlife.com/browse/storm-1458


Diffs (updated)
-

  indra/newview/llparticipantlist.cpp d8c37b383028 

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


Testing
---


Thanks,

Paul

___
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-1458 ([crashhunters] crash at LLParticipantList::LLParticipantListMenu::isGroupModerator() [secondlife-bin llparticipantlist.cpp])

2011-07-21 Thread Boroondas Gupte 

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



indra/newview/llparticipantlist.cpp


Hmm ... looking at the comment at 
https://bitbucket.org/lindenlab/viewer-development/src/d8c37b383028/indra/newview/llagent.h#cl-705
 and the implementation of isInGroup at 
https://bitbucket.org/lindenlab/viewer-development/src/d8c37b383028/indra/newview/llagent.cpp#cl-2414
 , this test actually checks whether the agent in question is a member of the 
group which has an UUID matching the conversation's session ID.

Because the session IDs of group chats will match the UUID of the 
respective groups (and all other chat session types should have session IDs not 
matching any group UUIDs), this also tells us whether the session is a group 
chat.

So maybe the comment should be yet different to reflect this. (Sorry, 
should have looked up this stuff for the first review already.) Maybe:
// Is session a group chat? (It is if the session ID is the UUID of a 
group of which the agent is a member.)

I wonder whether there is a better way (as in: making less assumptions / 
not using an agent as pivot) to test for this.


- Boroondas


On July 21, 2011, 3:27 a.m., Paul ProductEngine wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/404/
> ---
> 
> (Updated July 21, 2011, 3:27 a.m.)
> 
> 
> Review request for Viewer.
> 
> 
> Summary
> ---
> 
> - Added null checking
> 
> 
> This addresses bug storm-1458.
> http://jira.secondlife.com/browse/storm-1458
> 
> 
> Diffs
> -
> 
>   indra/newview/llparticipantlist.cpp d8c37b383028 
> 
> Diff: http://codereview.secondlife.com/r/404/diff
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Paul
> 
>

___
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-1458 ([crashhunters] crash at LLParticipantList::LLParticipantListMenu::isGroupModerator() [secondlife-bin llparticipantlist.cpp])

2011-07-21 Thread Paul ProductEngine 


> On July 21, 2011, 4:21 a.m., Boroondas Gupte wrote:
> > indra/newview/llparticipantlist.cpp, lines 807-808
> > 
> >
> > Hmm ... looking at the comment at 
> > https://bitbucket.org/lindenlab/viewer-development/src/d8c37b383028/indra/newview/llagent.h#cl-705
> >  and the implementation of isInGroup at 
> > https://bitbucket.org/lindenlab/viewer-development/src/d8c37b383028/indra/newview/llagent.cpp#cl-2414
> >  , this test actually checks whether the agent in question is a member of 
> > the group which has an UUID matching the conversation's session ID.
> > 
> > Because the session IDs of group chats will match the UUID of the 
> > respective groups (and all other chat session types should have session IDs 
> > not matching any group UUIDs), this also tells us whether the session is a 
> > group chat.
> > 
> > So maybe the comment should be yet different to reflect this. (Sorry, 
> > should have looked up this stuff for the first review already.) Maybe:
> > // Is session a group chat? (It is if the session ID is the 
> > UUID of a group of which the agent is a member.)
> > 
> > I wonder whether there is a better way (as in: making less assumptions 
> > / not using an agent as pivot) to test for this.

I think the comment may be: "Is agent in group call/chat ?"


- Paul


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


On July 21, 2011, 3:27 a.m., Paul ProductEngine wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/404/
> ---
> 
> (Updated July 21, 2011, 3:27 a.m.)
> 
> 
> Review request for Viewer.
> 
> 
> Summary
> ---
> 
> - Added null checking
> 
> 
> This addresses bug storm-1458.
> http://jira.secondlife.com/browse/storm-1458
> 
> 
> Diffs
> -
> 
>   indra/newview/llparticipantlist.cpp d8c37b383028 
> 
> Diff: http://codereview.secondlife.com/r/404/diff
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Paul
> 
>

___
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-1458 ([crashhunters] crash at LLParticipantList::LLParticipantListMenu::isGroupModerator() [secondlife-bin llparticipantlist.cpp])

2011-07-21 Thread Paul ProductEngine 

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

(Updated July 21, 2011, 7:01 a.m.)


Review request for Viewer.


Summary
---

- Added null checking


This addresses bug storm-1458.
http://jira.secondlife.com/browse/storm-1458


Diffs (updated)
-

  indra/newview/llparticipantlist.cpp d8c37b383028 

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


Testing
---


Thanks,

Paul

___
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-1458 ([crashhunters] crash at LLParticipantList::LLParticipantListMenu::isGroupModerator() [secondlife-bin llparticipantlist.cpp])

2011-07-21 Thread Boroondas Gupte 

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

Ship it!


- Boroondas


On July 21, 2011, 7:01 a.m., Paul ProductEngine wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/404/
> ---
> 
> (Updated July 21, 2011, 7:01 a.m.)
> 
> 
> Review request for Viewer.
> 
> 
> Summary
> ---
> 
> - Added null checking
> 
> 
> This addresses bug storm-1458.
> http://jira.secondlife.com/browse/storm-1458
> 
> 
> Diffs
> -
> 
>   indra/newview/llparticipantlist.cpp d8c37b383028 
> 
> Diff: http://codereview.secondlife.com/r/404/diff
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Paul
> 
>

___
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-1458 ([crashhunters] crash at LLParticipantList::LLParticipantListMenu::isGroupModerator() [secondlife-bin llparticipantlist.cpp])

2011-07-21 Thread Boroondas Gupte 


> On July 21, 2011, 4:21 a.m., Boroondas Gupte wrote:
> > indra/newview/llparticipantlist.cpp, lines 807-808
> > 
> >
> > Hmm ... looking at the comment at 
> > https://bitbucket.org/lindenlab/viewer-development/src/d8c37b383028/indra/newview/llagent.h#cl-705
> >  and the implementation of isInGroup at 
> > https://bitbucket.org/lindenlab/viewer-development/src/d8c37b383028/indra/newview/llagent.cpp#cl-2414
> >  , this test actually checks whether the agent in question is a member of 
> > the group which has an UUID matching the conversation's session ID.
> > 
> > Because the session IDs of group chats will match the UUID of the 
> > respective groups (and all other chat session types should have session IDs 
> > not matching any group UUIDs), this also tells us whether the session is a 
> > group chat.
> > 
> > So maybe the comment should be yet different to reflect this. (Sorry, 
> > should have looked up this stuff for the first review already.) Maybe:
> > // Is session a group chat? (It is if the session ID is the 
> > UUID of a group of which the agent is a member.)
> > 
> > I wonder whether there is a better way (as in: making less assumptions 
> > / not using an agent as pivot) to test for this.
> 
> Paul ProductEngine wrote:
> I think the comment may be: "Is agent in group call/chat ?"

We don't really care here whether the *agent* is in a group call/chat, but 
whether the *session* here is that of a *group* call/chat (as opposed to 
resident-to-resident chat and ad-hoc chat sessions). We just (ab)use the agent 
to get a list of candidate groups one of which might have the session ID as 
UUID. At least, that's what the code here seems to do. If the intention is 
something else, we might have a bug here.

Though it would make sense that this be in fact the intention, as the notion of 
"moderators" does not exist in ad-hoc and resi2resi chat sessions.


> I wonder whether there is a better way (as in: making less assumptions / not 
> using an agent as pivot) to test for this.

It looks like there isn't a better way, currently: LLIMModel::LLIMSession keeps 
track of the session type and offers this information through e.g. bool 
isGroupSessionType(), but LLParticipantList::LLParticipantListMenu seems 
neither directly nor indirectly (e.g. via mParent.mSpeakerMgr) aware of the 
LLIMSession it belongs to, so can't query that.

Off course, some refactoring could solve that, but that's not in-scope for this 
crash fix.


- Boroondas


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


On July 21, 2011, 3:27 a.m., Paul ProductEngine wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/404/
> ---
> 
> (Updated July 21, 2011, 3:27 a.m.)
> 
> 
> Review request for Viewer.
> 
> 
> Summary
> ---
> 
> - Added null checking
> 
> 
> This addresses bug storm-1458.
> http://jira.secondlife.com/browse/storm-1458
> 
> 
> Diffs
> -
> 
>   indra/newview/llparticipantlist.cpp d8c37b383028 
> 
> Diff: http://codereview.secondlife.com/r/404/diff
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Paul
> 
>

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

Re: [opensource-dev] Review Request: OPEN-67: make LLDirIterator implementation compatible to boost::filesystem v3 (as found in Boost 1.44 and newer)

2011-07-21 Thread Boroondas Gupte 

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

(Updated July 21, 2011, 8:43 a.m.)


Review request for Viewer.


Changes
---

Omit directory separator conversion, which is unnecessary for "paths" that are 
only filenames.


Summary
---

Context: We are currently using Boost 1.45, which already comes with the new 
Boost Filesystem Library API (Version 3) but still defaults to the old one 
(Version 2). From Boost 1.46 on, V3 will be the default and Boost 1.47 will be 
the last one to come with V2. The Boost Filesystem Library documentation 
recommends "Existing code should be moved to Version 3 as soon as convenient. 
New code should be written for Version 3. Version 2 is deprecated, and will not 
be included in Boost releases 1.48 and later."

This change overrides the default, so that the V3 API is used, and makes the 
necessary code changes. (So we can stick to Boost 1.45 and upgrade whenever we 
feel like it.)

Note: I only changed stuff that the compiler complained about. If the new API 
also changes semantic of still-compiling library usage, more changes might be 
necessary.


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


Diffs (updated)
-

  doc/contributions.txt 959f9340da92 
  indra/llvfs/lldiriterator.cpp 959f9340da92 

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


Testing
---

* Compiled Viewer (standalone) with Boost 1.45
* Started Viewer
* Logged in

* Compiled Viewer (standalone) with Boost 1.46
* Started Viewer
* Logged in

Not tested:
* non-standalone


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-1487 Gestures -> Get more leads to wrong URL

2011-07-21 Thread Oz Linden 

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

Ship it!


- Oz


On July 19, 2011, 11:20 a.m., Vadim ProductEngine wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/401/
> ---
> 
> (Updated July 19, 2011, 11:20 a.m.)
> 
> 
> Review request for Viewer.
> 
> 
> Summary
> ---
> 
> Changed the URL.
> 
> 
> This addresses bug STORM-1487.
> http://jira.secondlife.com/browse/STORM-1487
> 
> 
> Diffs
> -
> 
>   indra/newview/app_settings/settings.xml UNKNOWN 
> 
> Diff: http://codereview.secondlife.com/r/401/diff
> 
> 
> Testing
> ---
> 
> 
> 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: OPEN-67: make LLDirIterator implementation compatible to boost::filesystem v3 (as found in Boost 1.44 and newer)

2011-07-21 Thread Nicky Perian 

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


applied open-67_d.diff @r15984; windows fails link with unresolved externals as 
follows:
"windows-crash-logger.dir\RelWithDebInfo\/win_crash_logger.obj"  /machine:X86 
/debug 
llvfs.lib(lldiriterator.obj) : error LNK2019: unresolved external symbol 
"private: static class std::codecvt const * & __cdecl 
boost::filesystem3::path::wchar_t_codecvt_facet(void)" 
(?wchar_t_codecvt_facet@path@filesystem3@boost@@CAAAPBV?$codecvt@GDH@std@@XZ) 
referenced in function "public: __thiscall LLDirIterator::Impl::Impl(class 
std::basic_string,class std::allocator 
> const &,class std::basic_string,class 
std::allocator > const &)" 
(??0Impl@LLDirIterator@@QAE@ABV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@0@Z)
 
[c:\Users\Bill\lindenhg\viewer-development-mesh\build-vc100\win_crash_logger\windows-crash-logger.vcxproj]
llvfs.lib(lldiriterator.obj) : error LNK2019: unresolved external symbol "void 
__cdecl boost::filesystem3::path_traits::convert(unsigned short const 
*,unsigned short const *,class std::basic_string,class std::allocator > &,class 
std::codecvt const &)" 
(?convert@path_traits@filesystem3@boost@@YAXPBG0AAV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@ABV?$codecvt@GDH@5@@Z)
 referenced in function "public: class std::basic_string,class std::allocator > const __thiscall 
boost::filesystem3::path::string(class std::codecvt 
const &)const " 
(?string@path@filesystem3@boost@@QBE?BV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@ABV?$codecvt@GDH@5@@Z)
 
[c:\Users\Bill\lindenhg\viewer-development-mesh\build-vc100\win_crash_logger\windows-crash-logger.vcxproj]
llvfs.lib(lldiriterator.obj) : error LNK2019: unresolved external symbol 
"public: class std::basic_string,class 
std::allocator > const __thiscall 
boost::filesystem3::path::generic_string(class std::codecvt const &)const " 
(?generic_string@path@filesystem3@boost@@QBE?BV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@ABV?$codecvt@GDH@5@@Z)
 referenced in function "public: class std::basic_string,class std::allocator > const __thiscall 
boost::filesystem3::path::generic_string(void)const " 
(?generic_string@path@filesystem3@boost@@QBE?BV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@XZ)
 
[c:\Users\Bill\lindenhg\viewer-development-mesh\build-vc100\win_crash_logger\windows-crash-logger.vcxproj]
llvfs.lib(lldiriterator.obj) : error LNK2019: unresolved external symbol "void 
__cdecl boost::filesystem3::path_traits::convert(char const *,char const 
*,class std::basic_string,class std::allocator > &,class std::codecvt const &)" 
(?convert@path_traits@filesystem3@boost@@YAXPBD0AAV?$basic_string@GU?$char_traits@G@std@@V?$allocator@G@2@@std@@ABV?$codecvt@GDH@5@@Z)
 referenced in function "void __cdecl 
boost::filesystem3::path_traits::dispatch,class std::allocator > >(class std::basic_string,class 
std::allocator > const &,class std::basic_string,class std::allocator > &,class 
std::codecvt const &)" 
(??$dispatch@V?$basic_string@GU?$char_traits@G@std@@V?$allocator@G@2@@std@@@path_traits@filesystem3@boost@@YAXABV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@AAV?$basic_string@GU?$char_traits@G@std@@V?$allocator@G@2@@4@ABV?$codecvt@GDH@4@@Z)
 
[c:\Users\Bill\lindenhg\viewer-development-mesh\build-vc100\win_crash_logger\windows-crash-logger.vcxproj]

- Nicky


On July 21, 2011, 8:43 a.m., Boroondas Gupte wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/313/
> ---
> 
> (Updated July 21, 2011, 8:43 a.m.)
> 
> 
> Review request for Viewer.
> 
> 
> Summary
> ---
> 
> Context: We are currently using Boost 1.45, which already comes with the new 
> Boost Filesystem Library API (Version 3) but still defaults to the old one 
> (Version 2). From Boost 1.46 on, V3 will be the default and Boost 1.47 will 
> be the last one to come with V2. The Boost Filesystem Library documentation 
> recommends "Existing code should be moved to Version 3 as soon as convenient. 
> New code should be written for Version 3. Version 2 is deprecated, and will 
> not be included in Boost releases 1.48 and later."
> 
> This change overrides the default, so that the V3 API is used, and makes the 
> necessary code changes. (So we can stick to Boost 1.45 and upgrade whenever 
> we feel like it.)
> 
> Note: I only changed stuff that the compiler complained about. If the new API 
> also changes semantic of still-compiling library usage, more changes might be 
> necessary.
> 
> 
> This addresses bug OPEN-67.
> http://jira.secondlife.com/browse/OPEN-67
> 
> 
> Diffs
> -
> 
>   doc/contributions.txt 959f9340da9

Re: [opensource-dev] Review Request: OPEN-67: make LLDirIterator implementation compatible to boost::filesystem v3 (as found in Boost 1.44 and newer)

2011-07-21 Thread Boroondas Gupte 


> On July 21, 2011, 1:29 p.m., Nicky Perian wrote:
> > applied open-67_d.diff @r15984; windows fails link with unresolved 
> > externals as follows:
> > "windows-crash-logger.dir\RelWithDebInfo\/win_crash_logger.obj"  
> > /machine:X86 /debug 
> > llvfs.lib(lldiriterator.obj) : error LNK2019: unresolved external symbol 
> > "private: static class std::codecvt const * & 
> > __cdecl boost::filesystem3::path::wchar_t_codecvt_facet(void)" 
> > (?wchar_t_codecvt_facet@path@filesystem3@boost@@CAAAPBV?$codecvt@GDH@std@@XZ)
> >  referenced in function "public: __thiscall LLDirIterator::Impl::Impl(class 
> > std::basic_string,class 
> > std::allocator > const &,class std::basic_string > std::char_traits,class std::allocator > const &)" 
> > (??0Impl@LLDirIterator@@QAE@ABV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@0@Z)
> >  
> > [c:\Users\Bill\lindenhg\viewer-development-mesh\build-vc100\win_crash_logger\windows-crash-logger.vcxproj]
> > llvfs.lib(lldiriterator.obj) : error LNK2019: unresolved external symbol 
> > "void __cdecl boost::filesystem3::path_traits::convert(unsigned short const 
> > *,unsigned short const *,class std::basic_string > std::char_traits,class std::allocator > &,class 
> > std::codecvt const &)" 
> > (?convert@path_traits@filesystem3@boost@@YAXPBG0AAV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@ABV?$codecvt@GDH@5@@Z)
> >  referenced in function "public: class std::basic_string > std::char_traits,class std::allocator > const __thiscall 
> > boost::filesystem3::path::string(class std::codecvt > short,char,int> const &)const " 
> > (?string@path@filesystem3@boost@@QBE?BV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@ABV?$codecvt@GDH@5@@Z)
> >  
> > [c:\Users\Bill\lindenhg\viewer-development-mesh\build-vc100\win_crash_logger\windows-crash-logger.vcxproj]
> > llvfs.lib(lldiriterator.obj) : error LNK2019: unresolved external symbol 
> > "public: class std::basic_string,class 
> > std::allocator > const __thiscall 
> > boost::filesystem3::path::generic_string(class std::codecvt > short,char,int> const &)const " 
> > (?generic_string@path@filesystem3@boost@@QBE?BV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@ABV?$codecvt@GDH@5@@Z)
> >  referenced in function "public: class std::basic_string > std::char_traits,class std::allocator > const __thiscall 
> > boost::filesystem3::path::generic_string(void)const " 
> > (?generic_string@path@filesystem3@boost@@QBE?BV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@XZ)
> >  
> > [c:\Users\Bill\lindenhg\viewer-development-mesh\build-vc100\win_crash_logger\windows-crash-logger.vcxproj]
> > llvfs.lib(lldiriterator.obj) : error LNK2019: unresolved external symbol 
> > "void __cdecl boost::filesystem3::path_traits::convert(char const *,char 
> > const *,class std::basic_string > std::char_traits,class std::allocator > 
> > &,class std::codecvt const &)" 
> > (?convert@path_traits@filesystem3@boost@@YAXPBD0AAV?$basic_string@GU?$char_traits@G@std@@V?$allocator@G@2@@std@@ABV?$codecvt@GDH@5@@Z)
> >  referenced in function "void __cdecl 
> > boost::filesystem3::path_traits::dispatch > short,struct std::char_traits,class std::allocator > short> > >(class std::basic_string,class 
> > std::allocator > const &,class std::basic_string > short,struct std::char_traits,class std::allocator > short> > &,class std::codecvt const &)" 
> > (??$dispatch@V?$basic_string@GU?$char_traits@G@std@@V?$allocator@G@2@@std@@@path_traits@filesystem3@boost@@YAXABV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@AAV?$basic_string@GU?$char_traits@G@std@@V?$allocator@G@2@@4@ABV?$codecvt@GDH@4@@Z)
> >  
> > [c:\Users\Bill\lindenhg\viewer-development-mesh\build-vc100\win_crash_logger\windows-crash-logger.vcxproj]

Did the patch apply cleanly? To maintain readability, I didn't include the 
merge with tip, so you might want to pull 
https://bitbucket.org/boroondas/viewer-development-open-67 instead of manually 
applying patches.


- Boroondas


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


On July 21, 2011, 8:43 a.m., Boroondas Gupte wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/313/
> ---
> 
> (Updated July 21, 2011, 8:43 a.m.)
> 
> 
> Review request for Viewer.
> 
> 
> Summary
> ---
> 
> Context: We are currently using Boost 1.45, which already comes with the new 
> Boost Filesystem Library API (Version 3) but still defaults to the old one 
> (Version 2). From Boost 1.46 on, V3 will be the default and Boost 1.47 will 
> be the last one to come with V2. The Boost Filesystem Library documentation 
> recommends "Existing code should be moved to Versio

[opensource-dev] Review Request: VWR-26458: fixing a simple typo in German translation

2011-07-21 Thread Boroondas Gupte 

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

Review request for Viewer.


Summary
---

Found this coincidentally when looking through recent changesets. Thought I'd 
fix it right away.


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


Diffs
-

  doc/contributions.txt 06874d04d57e 
  indra/newview/skins/default/xui/de/floater_delete_env_preset.xml 06874d04d57e 

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


Testing
---

none


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: OPEN-67: make LLDirIterator implementation compatible to boost::filesystem v3 (as found in Boost 1.44 and newer)

2011-07-21 Thread Boroondas Gupte 


> On July 21, 2011, 1:29 p.m., Nicky Perian wrote:
> > applied open-67_d.diff @r15984; windows fails link with unresolved 
> > externals as follows:
> > "windows-crash-logger.dir\RelWithDebInfo\/win_crash_logger.obj"  
> > /machine:X86 /debug 
> > llvfs.lib(lldiriterator.obj) : error LNK2019: unresolved external symbol 
> > "private: static class std::codecvt const * & 
> > __cdecl boost::filesystem3::path::wchar_t_codecvt_facet(void)" 
> > (?wchar_t_codecvt_facet@path@filesystem3@boost@@CAAAPBV?$codecvt@GDH@std@@XZ)
> >  referenced in function "public: __thiscall LLDirIterator::Impl::Impl(class 
> > std::basic_string,class 
> > std::allocator > const &,class std::basic_string > std::char_traits,class std::allocator > const &)" 
> > (??0Impl@LLDirIterator@@QAE@ABV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@0@Z)
> >  
> > [c:\Users\Bill\lindenhg\viewer-development-mesh\build-vc100\win_crash_logger\windows-crash-logger.vcxproj]
> > llvfs.lib(lldiriterator.obj) : error LNK2019: unresolved external symbol 
> > "void __cdecl boost::filesystem3::path_traits::convert(unsigned short const 
> > *,unsigned short const *,class std::basic_string > std::char_traits,class std::allocator > &,class 
> > std::codecvt const &)" 
> > (?convert@path_traits@filesystem3@boost@@YAXPBG0AAV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@ABV?$codecvt@GDH@5@@Z)
> >  referenced in function "public: class std::basic_string > std::char_traits,class std::allocator > const __thiscall 
> > boost::filesystem3::path::string(class std::codecvt > short,char,int> const &)const " 
> > (?string@path@filesystem3@boost@@QBE?BV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@ABV?$codecvt@GDH@5@@Z)
> >  
> > [c:\Users\Bill\lindenhg\viewer-development-mesh\build-vc100\win_crash_logger\windows-crash-logger.vcxproj]
> > llvfs.lib(lldiriterator.obj) : error LNK2019: unresolved external symbol 
> > "public: class std::basic_string,class 
> > std::allocator > const __thiscall 
> > boost::filesystem3::path::generic_string(class std::codecvt > short,char,int> const &)const " 
> > (?generic_string@path@filesystem3@boost@@QBE?BV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@ABV?$codecvt@GDH@5@@Z)
> >  referenced in function "public: class std::basic_string > std::char_traits,class std::allocator > const __thiscall 
> > boost::filesystem3::path::generic_string(void)const " 
> > (?generic_string@path@filesystem3@boost@@QBE?BV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@XZ)
> >  
> > [c:\Users\Bill\lindenhg\viewer-development-mesh\build-vc100\win_crash_logger\windows-crash-logger.vcxproj]
> > llvfs.lib(lldiriterator.obj) : error LNK2019: unresolved external symbol 
> > "void __cdecl boost::filesystem3::path_traits::convert(char const *,char 
> > const *,class std::basic_string > std::char_traits,class std::allocator > 
> > &,class std::codecvt const &)" 
> > (?convert@path_traits@filesystem3@boost@@YAXPBD0AAV?$basic_string@GU?$char_traits@G@std@@V?$allocator@G@2@@std@@ABV?$codecvt@GDH@5@@Z)
> >  referenced in function "void __cdecl 
> > boost::filesystem3::path_traits::dispatch > short,struct std::char_traits,class std::allocator > short> > >(class std::basic_string,class 
> > std::allocator > const &,class std::basic_string > short,struct std::char_traits,class std::allocator > short> > &,class std::codecvt const &)" 
> > (??$dispatch@V?$basic_string@GU?$char_traits@G@std@@V?$allocator@G@2@@std@@@path_traits@filesystem3@boost@@YAXABV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@AAV?$basic_string@GU?$char_traits@G@std@@V?$allocator@G@2@@4@ABV?$codecvt@GDH@4@@Z)
> >  
> > [c:\Users\Bill\lindenhg\viewer-development-mesh\build-vc100\win_crash_logger\windows-crash-logger.vcxproj]
> 
> Boroondas Gupte wrote:
> Did the patch apply cleanly? To maintain readability, I didn't include 
> the merge with tip, so you might want to pull 
> https://bitbucket.org/boroondas/viewer-development-open-67 instead of 
> manually applying patches.

Just saw that you mentioned a revision: 15984

Though, this is a revision number, thus valid for the local repository only. 
What is the corresponding revision ID?


- Boroondas


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


On July 21, 2011, 8:43 a.m., Boroondas Gupte wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/313/
> ---
> 
> (Updated July 21, 2011, 8:43 a.m.)
> 
> 
> Review request for Viewer.
> 
> 
> Summary
> ---
> 
> Context: We are currently using Boost 1.45, which already comes with the new 
> Boost Filesystem Library API (Version 3) but still defaults to the old one 
> (Vers

Re: [opensource-dev] Review Request: STORM-1453: Prevent unintended 10L sale

2011-07-21 Thread Kadah Coba 

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

(Updated July 21, 2011, 5:34 p.m.)


Review request for Viewer.


Summary (updated)
---

This change makes it so setting an object for sale or modifying the price or 
sale type requires explicitly applying the changes. Default behavior before 
this patch is all sale info is committed to sim on change. After this patch the 
sale info will only get set or modified after hitting a "mark for sale" button. 
There is no change to removing an object from sale, unchecking "For sale" will 
be committed to sim without further user interation.

https://bitbucket.org/Kadah_Coba/storm-1453


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


Diffs (updated)
-

  indra/newview/llpanelpermissions.cpp UNKNOWN 

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


Testing
---

(I had stuff here but Review Board kept deleting it every time I tried to save.)


Thanks,

Kadah

___
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-1453: Prevent unintended 10L sale

2011-07-21 Thread Kadah Coba 

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


Made the requested changes. Allow setting object price without needing to 
commit the object for sale at the default 10L first.

- Kadah


On July 21, 2011, 5:34 p.m., Kadah Coba wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/365/
> ---
> 
> (Updated July 21, 2011, 5:34 p.m.)
> 
> 
> Review request for Viewer.
> 
> 
> Summary
> ---
> 
> This change makes it so setting an object for sale or modifying the price or 
> sale type requires explicitly applying the changes. Default behavior before 
> this patch is all sale info is committed to sim on change. After this patch 
> the sale info will only get set or modified after hitting a "mark for sale" 
> button. There is no change to removing an object from sale, unchecking "For 
> sale" will be committed to sim without further user interation.
> 
> https://bitbucket.org/Kadah_Coba/storm-1453
> 
> 
> This addresses bug STORM-1453.
> http://jira.secondlife.com/browse/STORM-1453
> 
> 
> Diffs
> -
> 
>   indra/newview/llpanelpermissions.cpp UNKNOWN 
> 
> Diff: http://codereview.secondlife.com/r/365/diff
> 
> 
> Testing
> ---
> 
> (I had stuff here but Review Board kept deleting it every time I tried to 
> save.)
> 
> 
> Thanks,
> 
> Kadah
> 
>

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

Re: [opensource-dev] Review Request: OPEN-67: make LLDirIterator implementation compatible to boost::filesystem v3 (as found in Boost 1.44 and newer)

2011-07-21 Thread Nicky Perian 

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


Hash was 216ebc0442d29a8ba4a66ae8c7211b7aaa225892. However, the result is the 
same when building a clone of 
https://bitbucket.org/boroondas/viewer-development-open-67. I'll try to sort 
out a solution as time allows. Maybe another windows developer can pitch in.

- Nicky


On July 21, 2011, 8:43 a.m., Boroondas Gupte wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/313/
> ---
> 
> (Updated July 21, 2011, 8:43 a.m.)
> 
> 
> Review request for Viewer.
> 
> 
> Summary
> ---
> 
> Context: We are currently using Boost 1.45, which already comes with the new 
> Boost Filesystem Library API (Version 3) but still defaults to the old one 
> (Version 2). From Boost 1.46 on, V3 will be the default and Boost 1.47 will 
> be the last one to come with V2. The Boost Filesystem Library documentation 
> recommends "Existing code should be moved to Version 3 as soon as convenient. 
> New code should be written for Version 3. Version 2 is deprecated, and will 
> not be included in Boost releases 1.48 and later."
> 
> This change overrides the default, so that the V3 API is used, and makes the 
> necessary code changes. (So we can stick to Boost 1.45 and upgrade whenever 
> we feel like it.)
> 
> Note: I only changed stuff that the compiler complained about. If the new API 
> also changes semantic of still-compiling library usage, more changes might be 
> necessary.
> 
> 
> This addresses bug OPEN-67.
> http://jira.secondlife.com/browse/OPEN-67
> 
> 
> Diffs
> -
> 
>   doc/contributions.txt 959f9340da92 
>   indra/llvfs/lldiriterator.cpp 959f9340da92 
> 
> Diff: http://codereview.secondlife.com/r/313/diff
> 
> 
> Testing
> ---
> 
> * Compiled Viewer (standalone) with Boost 1.45
> * Started Viewer
> * Logged in
> 
> * Compiled Viewer (standalone) with Boost 1.46
> * Started Viewer
> * Logged in
> 
> Not tested:
> * non-standalone
> 
> 
> 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-1453: Prevent unintended 10L sale

2011-07-21 Thread Wolfpup Lowenhar 


> On July 21, 2011, 5:35 p.m., Kadah Coba wrote:
> > Made the requested changes. Allow setting object price without needing to 
> > commit the object for sale at the default 10L first.

1. Can the price be set to 0$L.
2. Dose this also fix it in the side tray?


- Wolfpup


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


On July 21, 2011, 5:34 p.m., Kadah Coba wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/365/
> ---
> 
> (Updated July 21, 2011, 5:34 p.m.)
> 
> 
> Review request for Viewer.
> 
> 
> Summary
> ---
> 
> This change makes it so setting an object for sale or modifying the price or 
> sale type requires explicitly applying the changes. Default behavior before 
> this patch is all sale info is committed to sim on change. After this patch 
> the sale info will only get set or modified after hitting a "mark for sale" 
> button. There is no change to removing an object from sale, unchecking "For 
> sale" will be committed to sim without further user interation.
> 
> https://bitbucket.org/Kadah_Coba/storm-1453
> 
> 
> This addresses bug STORM-1453.
> http://jira.secondlife.com/browse/STORM-1453
> 
> 
> Diffs
> -
> 
>   indra/newview/llpanelpermissions.cpp UNKNOWN 
> 
> Diff: http://codereview.secondlife.com/r/365/diff
> 
> 
> Testing
> ---
> 
> (I had stuff here but Review Board kept deleting it every time I tried to 
> save.)
> 
> 
> Thanks,
> 
> Kadah
> 
>

___
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