[opensource-dev] Review Request: Dragging the "Contents" folder from object inventory to agent inventory shows the "prohibited" cursor

[Kitty Barnett]

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

Review request for Viewer.


Summary
---

The "Contents" folder is an LLInventoryObject instance, and failed the dynamic 
cast to LLInventoryItem.

The permission logic didn't apply since it's a category (which has no 
permissions) and was changed to use the same function that will do the actual 
copying so that drop behaviour should always match the "can drop" result.


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


Diffs
-

  indra/newview/llpanelobjectinventory.cpp UNKNOWN 

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


Testing
---


Thanks,

Kitty

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

[opensource-dev] Review Request: STORM-316 Add missing "sort by name" and "sort by recent" options for folders

[Kitty Barnett]

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

Review request for Viewer.


Summary
---

Changes the UI (and needs additional translation), but it's a viewer 1 option 
that was missed by STORM-316.

Existing "Sort by (Name|Most Recent)" => "Sort Items by (Name|Most Recent)"

Split "Folders always by name" in two options to match what was done for 
inventory items and added "Sort Folders by (Name|Most Recent)" menu options.


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


Diffs
-

  indra/newview/llpanelmaininventory.cpp UNKNOWN 
  indra/newview/skins/default/xui/en/menu_inventory_gear_default.xml UNKNOWN 

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


Testing
---


Thanks,

Kitty

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

Re: [opensource-dev] Review Request: Bug Fix for STORM-776 and STORM-288

[Vadim ProductEngine]

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

Ship it!


Looks plausible and works for me.

- Vadim


On 2010-12-15 19:59:24, Wolfpup Lowenhar wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/21/
> ---
> 
> (Updated 2010-12-15 19:59:24)
> 
> 
> Review request for Viewer.
> 
> 
> Summary
> ---
> 
> This is actually Kitty's patch for STORM-288 but it also corrects the issue 
> listed in STORM-776 as well.
> 
> 
> This addresses bug STORM-776.
> http://jira.secondlife.com/browse/STORM-776
> 
> 
> Diffs
> -
> 
>   doc/contributions.txt b0689af42a71 
>   indra/newview/llsidepaneliteminfo.h b0689af42a71 
>   indra/newview/llsidepaneliteminfo.cpp b0689af42a71 
> 
> Diff: http://codereview.secondlife.com/r/21/diff
> 
> 
> Testing
> ---
> 
> I have built and tested this locally and was able to fully modify the next 
> person permissions on object that i had full permissions also tested to see 
> if I could set item in inventory for sale and I could.
> 
> Test Viewers for this issue are available here:
> http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repo/oz_project-2/rev/216992/index.html
> 
> please test this on mac and linux to verify fix works on all platforms.
> 
> 
> Thanks,
> 
> Wolfpup
> 
>

___
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: Settings.xml: redundant entries and unnecessary tag

[Boroondas Gupte]

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

Ship it!


looks good

- Boroondas


On 2010-12-14 12:39:34, Jonathan Yap wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/18/
> ---
> 
> (Updated 2010-12-14 12:39:34)
> 
> 
> Review request for Viewer.
> 
> 
> Summary
> ---
> 
> I wrote two programs that use settings.xml to produce this massive table:
> http://wiki.secondlife.com/wiki/Debug_Settings
> 
> While doing this I found 4 places with duplicate entries and 1 entry that is 
> repeated 4 times.  There is also a pair of unnecessary tags.
> 
> Having these cleaned out would make running my program, and thus updating the 
> wiki table, easier.
> 
> I've erased all but the last entry for these redundant debug settings.
> 
> 
> This addresses bug vwr-24100.
> http://jira.secondlife.com/browse/vwr-24100
> 
> 
> Diffs
> -
> 
>   indra/newview/app_settings/settings.xml 46a990f8296f 
> 
> Diff: http://codereview.secondlife.com/r/18/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

Re: [opensource-dev] Review Request: Crash in LLRemoteParcelInfoProcessor::processParcelInfoReply()

[Boroondas Gupte]

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



indra/newview/llremoteparcelrequest.cpp


post-increments are subtle ... please include some comment in the code that 
points out what's going on. (Can be short)



indra/newview/llremoteparcelrequest.cpp


Please also comment in the code why cur_oi may not be oi when calling this, 
so we don't risk someone reverting your fix by accident.


- Boroondas


On 2010-12-15 11:27:50, Kitty Barnett wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/24/
> ---
> 
> (Updated 2010-12-15 11:27:50)
> 
> 
> Review request for Viewer.
> 
> 
> Summary
> ---
> 
> erase() on a multimap will only invalidate iterators that point to the 
> element being erased so pre-incrementing the loop iterator should prevent it 
> from getting invalidated when an observer calls removeObserver() as part of 
> its processParcelInfo() implementation.
> 
> 
> This addresses bug VWR-24207.
> http://jira.secondlife.com/browse/VWR-24207
> 
> 
> Diffs
> -
> 
>   indra/newview/llremoteparcelrequest.cpp UNKNOWN 
> 
> Diff: http://codereview.secondlife.com/r/24/diff
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Kitty
> 
>

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

Re: [opensource-dev] Review Request: Settings.xml: redundant entries and unnecessary tag

[Wolfpup Lowenhar]

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

Ship it!


any code or xml clean up is a good thing i think.

- Wolfpup


On 2010-12-14 12:39:34, Jonathan Yap wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/18/
> ---
> 
> (Updated 2010-12-14 12:39:34)
> 
> 
> Review request for Viewer.
> 
> 
> Summary
> ---
> 
> I wrote two programs that use settings.xml to produce this massive table:
> http://wiki.secondlife.com/wiki/Debug_Settings
> 
> While doing this I found 4 places with duplicate entries and 1 entry that is 
> repeated 4 times.  There is also a pair of unnecessary tags.
> 
> Having these cleaned out would make running my program, and thus updating the 
> wiki table, easier.
> 
> I've erased all but the last entry for these redundant debug settings.
> 
> 
> This addresses bug vwr-24100.
> http://jira.secondlife.com/browse/vwr-24100
> 
> 
> Diffs
> -
> 
>   indra/newview/app_settings/settings.xml 46a990f8296f 
> 
> Diff: http://codereview.secondlife.com/r/18/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: scripts/install.py --uninstall does not always remove symbolic links.

[Aleric Inglewood]

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

Review request for Viewer.


Summary
---

Packages (tar balls) installed with scripts/install.py do contain symbolic 
links.
Everything that they contain is written to the file installed.xml, and upon
uninstall attempted to remove.

However, the python script first tests if a file exists before it removes it
and uses os.path.exists for this, which only returns true when the target
is a file, or a symbolic link *pointing* to an existing file.

Since the removal of the tar ball elements is arbitrary, it is possible (and
often the case) that the file the symbolic link points to is removed before
the symbolic link itself is removed, causing the test to fail and the symbolic
link not to be removed.

This patch solves this bug by using os.path.lexists which returns true for
normal files when they exist, and true for symbolic links if they exist,
whether or not the file they point to exists, exactly what we want.

os.path.lexists was added to python 2.4, so that should not be problem.


This addresses bug SNOW-744.
http://jira.secondlife.com/browse/SNOW-744


Diffs
-

  scripts/install.py b0689af42a71 

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


Testing
---

This patch was originally tested to work several months ago, and has been in
use by the Imprudence TPV for a while now.


Thanks,

Aleric

___
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: scripts/install.py --uninstall does not always remove symbolic links.

[Boroondas Gupte]

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

Ship it!


Your explanation is consistent with python's documentation and the change looks 
simple and sane. The change won't have any effect on platforms that don't have 
os.lstat(), but those seem to be the ones that don't have symlinks in the first 
place.

- Boroondas


On 2010-12-16 07:34:22, Aleric Inglewood wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/29/
> ---
> 
> (Updated 2010-12-16 07:34:22)
> 
> 
> Review request for Viewer.
> 
> 
> Summary
> ---
> 
> Packages (tar balls) installed with scripts/install.py do contain symbolic 
> links.
> Everything that they contain is written to the file installed.xml, and upon
> uninstall attempted to remove.
> 
> However, the python script first tests if a file exists before it removes it
> and uses os.path.exists for this, which only returns true when the target
> is a file, or a symbolic link *pointing* to an existing file.
> 
> Since the removal of the tar ball elements is arbitrary, it is possible (and
> often the case) that the file the symbolic link points to is removed before
> the symbolic link itself is removed, causing the test to fail and the symbolic
> link not to be removed.
> 
> This patch solves this bug by using os.path.lexists which returns true for
> normal files when they exist, and true for symbolic links if they exist,
> whether or not the file they point to exists, exactly what we want.
> 
> os.path.lexists was added to python 2.4, so that should not be problem.
> 
> 
> This addresses bug SNOW-744.
> http://jira.secondlife.com/browse/SNOW-744
> 
> 
> Diffs
> -
> 
>   scripts/install.py b0689af42a71 
> 
> Diff: http://codereview.secondlife.com/r/29/diff
> 
> 
> Testing
> ---
> 
> This patch was originally tested to work several months ago, and has been in
> use by the Imprudence TPV for a while now.
> 
> 
> Thanks,
> 
> Aleric
> 
>

___
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: Settings.xml: redundant entries and unnecessary tag

[Aleric Inglewood]

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


..testing the review system (hi mom!)..


indra/newview/app_settings/settings.xml


Considering the setting name (CacheLocationTopFolder), isn't the deleted 
Comment string better than the one you left in? Thus, Controls the top folder 
location of the the local disk cache, rather than Controls the location of the 
local disk cache. Diff is ok with me, I just wondered if you saw that it wasn't 
an exact duplicate.



indra/newview/app_settings/settings.xml


This deletes the entry with 60 seconds between printing the FPS and leaves 
the one that has 10 seconds between printing. Which is the correct one?



indra/newview/app_settings/settings.xml


This really looks wrong. The first OutBandwidth has Comment that has 
nothing to do with OutBandwidth and a Type Boolean.
The one that was left in seem to be the real OutBandwidth looking at the 
Comment, and has Type F32.

My guess is that the deleted entry should not have been deleted, but that 
the key of this entry is wrong, and that the correct way to fix this is to 
change the key into whatever it was intended to be.


- Aleric


On 2010-12-14 12:39:34, Jonathan Yap wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/18/
> ---
> 
> (Updated 2010-12-14 12:39:34)
> 
> 
> Review request for Viewer.
> 
> 
> Summary
> ---
> 
> I wrote two programs that use settings.xml to produce this massive table:
> http://wiki.secondlife.com/wiki/Debug_Settings
> 
> While doing this I found 4 places with duplicate entries and 1 entry that is 
> repeated 4 times.  There is also a pair of unnecessary tags.
> 
> Having these cleaned out would make running my program, and thus updating the 
> wiki table, easier.
> 
> I've erased all but the last entry for these redundant debug settings.
> 
> 
> This addresses bug vwr-24100.
> http://jira.secondlife.com/browse/vwr-24100
> 
> 
> Diffs
> -
> 
>   indra/newview/app_settings/settings.xml 46a990f8296f 
> 
> Diff: http://codereview.secondlife.com/r/18/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

Re: [opensource-dev] Review Request: Crash in LLRemoteParcelInfoProcessor::processParcelInfoReply()

[Merov Linden]

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


Putting the "oi++" in the same line as the affectation is unclear. Please put 
that on the next line and write a comment as to why this increment must happen 
as soon as the affectation to cur_oi is done (the whole point of the patch). 
I'm afraid that someone reviewing casually the code would "simplify" this by 
putting the increment back in the "for" statement.

- Merov


On 2010-12-15 11:27:50, Kitty Barnett wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/24/
> ---
> 
> (Updated 2010-12-15 11:27:50)
> 
> 
> Review request for Viewer.
> 
> 
> Summary
> ---
> 
> erase() on a multimap will only invalidate iterators that point to the 
> element being erased so pre-incrementing the loop iterator should prevent it 
> from getting invalidated when an observer calls removeObserver() as part of 
> its processParcelInfo() implementation.
> 
> 
> This addresses bug VWR-24207.
> http://jira.secondlife.com/browse/VWR-24207
> 
> 
> Diffs
> -
> 
>   indra/newview/llremoteparcelrequest.cpp UNKNOWN 
> 
> Diff: http://codereview.secondlife.com/r/24/diff
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Kitty
> 
>

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

Re: [opensource-dev] Review Request: Crash in LLRemoteParcelInfoProcessor::processParcelInfoReply()

[Kent Quirk]

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

Ship it!


Wow, nice catch. I was looking for this bug earlier and didn't dream that a 
function like processParcelInfo would attempt to erase an entity. 

- Kent


On 2010-12-15 11:27:50, Kitty Barnett wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/24/
> ---
> 
> (Updated 2010-12-15 11:27:50)
> 
> 
> Review request for Viewer.
> 
> 
> Summary
> ---
> 
> erase() on a multimap will only invalidate iterators that point to the 
> element being erased so pre-incrementing the loop iterator should prevent it 
> from getting invalidated when an observer calls removeObserver() as part of 
> its processParcelInfo() implementation.
> 
> 
> This addresses bug VWR-24207.
> http://jira.secondlife.com/browse/VWR-24207
> 
> 
> Diffs
> -
> 
>   indra/newview/llremoteparcelrequest.cpp UNKNOWN 
> 
> Diff: http://codereview.secondlife.com/r/24/diff
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Kitty
> 
>

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

[opensource-dev] [TOS]Question about TOS

[Malachi Prophit]

We all had to accept a new TOS stating that the teen grid and the main  
grid were now one grid. However after having my son log into his teen grid  
account we found that he is not on the main grid, instead he is trapped on  
the teen grid. He has no access to the main grid and we have no access to  
him. Not even the ability to see his profile or he see ours.

My question is this, If we had to accept a new TOS that integrated the  
merger of the two grids and the two grids WERE NOT merged, what hidden  
take our souls clause has LL added to the TOS, and shoved down our throats  
this time?


-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/
___
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] [TOS]Question about TOS

[David Simmons]

The actual merger is not until January 2011.

On Thu, Dec 16, 2010 at 8:43 AM, Malachi Prophit  wrote:
> We all had to accept a new TOS stating that the teen grid and the main
> grid were now one grid. However after having my son log into his teen grid
> account we found that he is not on the main grid, instead he is trapped on
> the teen grid. He has no access to the main grid and we have no access to
> him. Not even the ability to see his profile or he see ours.
>
> My question is this, If we had to accept a new TOS that integrated the
> merger of the two grids and the two grids WERE NOT merged, what hidden
> take our souls clause has LL added to the TOS, and shoved down our throats
> this time?
>
>
> --
> Using Opera's revolutionary email client: http://www.opera.com/mail/
> ___
> 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
>



-- 
“The greatest danger in modern technology isn't that machines will
begin to think like people, but that people will begin to think like
machines” Unknown

http://www.google.com/profiles/techiedavid
___
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-524 : Refresh L$ balance

[Aleric Inglewood]

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

Ship it!


> 99% chance that this is correct (not counting the added line with trailing 
> white space ;).

Something that can impossibly be harmful, but what made me wonder, is that 
before
getChild("balance") never has setVisible called in the old code, but
in the new code apparently needs it (definitely looking logical from the context
where it is added). But I suppose that it's irrelevant.


- Aleric


On 2010-12-10 16:21:57, Merov Linden wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/6/
> ---
> 
> (Updated 2010-12-10 16:21:57)
> 
> 
> Review request for Viewer.
> 
> 
> Summary
> ---
> 
> Since the L$ balance can be updated by events outside the viewer entirely 
> (purchase of L$ on web) and since we do not pool or receive notifications for 
> this, I implemented a simple "click to refresh" event on the LLTextBox 
> holding the L$ balance value (proposed by Q in JIRA).
> I modified the tooltip to reflect this new functionality.
> 
> 
> This addresses bug STORM-524.
> http://jira.secondlife.com/browse/STORM-524
> 
> 
> Diffs
> -
> 
>   indra/newview/llbuycurrencyhtml.cpp 8668b574c1f3 
>   indra/newview/llfloaterbuycurrency.cpp 8668b574c1f3 
>   indra/newview/llfloaterbuycurrencyhtml.cpp 8668b574c1f3 
>   indra/newview/llstatusbar.h 8668b574c1f3 
>   indra/newview/llstatusbar.cpp 8668b574c1f3 
>   indra/newview/skins/default/xui/en/panel_status_bar.xml 8668b574c1f3 
> 
> Diff: http://codereview.secondlife.com/r/6/diff
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Merov
> 
>

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

Re: [opensource-dev] Review Request: Crash in LLVivoxVoiceClient::notifyStatusObservers()

[Merov Linden]

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

Ship it!


This looks correct to me and should fix the observed crasher.

- Merov


On 2010-12-15 11:48:39, Kitty Barnett wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/25/
> ---
> 
> (Updated 2010-12-15 11:48:39)
> 
> 
> Review request for Viewer.
> 
> 
> Summary
> ---
> 
> Moved removeObserver() out of the "if(getAvatarId().notNull()) { }" block 
> since "getAvatarId()" can return the NULL UUID (i.e. if the panel hasn't been 
> opened), matching the addObserver() without condition in postBuild.
> 
> 
> This addresses bug VWR-24209.
> http://jira.secondlife.com/browse/VWR-24209
> 
> 
> Diffs
> -
> 
>   indra/newview/llpanelavatar.cpp UNKNOWN 
> 
> Diff: http://codereview.secondlife.com/r/25/diff
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Kitty
> 
>

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

Re: [opensource-dev] Review Request: VWR-20962 CTRL-\ Last chatter

[Aleric Inglewood]

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


I suppose that there is a problem with the API, as that seems to dictate that 
the correct way to fix this is to first call setFocusOnAvatar(FALSE, FALSE) to 
unlock(?) or at least to stop the second call from calling setFocusGlobal, then 
to call setFocusGlobal and finally calling startCameraAnimation() to start the 
animation. Or maybe the last call isn't even needed since 
LLAgentCamera::setFocusGlobal also calls it.

I'm not sure, but it would be my guess that calling setFocusOnAvatar(FALSE, 
FALSE) (in the same place as you do now, before calling setFocusGlobal) is the 
more correct solution: you don't want to start an animation at this point, you 
just want to stop focussing on the avatar.

Can you try if that works too (Change the last TRUE into a FALSE)?

- Aleric


On 2010-12-14 07:03:25, Jonathan Yap wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/16/
> ---
> 
> (Updated 2010-12-14 07:03:25)
> 
> 
> Review request for Viewer.
> 
> 
> Summary
> ---
> 
> You have to push CTRL-\(there is a menu item for this too) twice to get the 
> last chatter function to work.  My fix unlocks the camera before moving it.
> 
> 
> This addresses bug vwr-20962.
> http://jira.secondlife.com/browse/vwr-20962
> 
> 
> Diffs
> -
> 
>   indra/newview/llagentcamera.cpp 3d2e71443c58 
> 
> Diff: http://codereview.secondlife.com/r/16/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

Re: [opensource-dev] Review Request: Dragging the "Contents" folder from object inventory to agent inventory shows the "prohibited" cursor

[Merov Linden]

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

Ship it!


I think this is correct though I haven't tried the code. Good use of 
move_inv_category_world_to_agent() that does all the right perm checking.

- Merov


On 2010-12-16 03:04:28, Kitty Barnett wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/26/
> ---
> 
> (Updated 2010-12-16 03:04:28)
> 
> 
> Review request for Viewer.
> 
> 
> Summary
> ---
> 
> The "Contents" folder is an LLInventoryObject instance, and failed the 
> dynamic cast to LLInventoryItem.
> 
> The permission logic didn't apply since it's a category (which has no 
> permissions) and was changed to use the same function that will do the actual 
> copying so that drop behaviour should always match the "can drop" result.
> 
> 
> This addresses bug VWR-24217.
> http://jira.secondlife.com/browse/VWR-24217
> 
> 
> Diffs
> -
> 
>   indra/newview/llpanelobjectinventory.cpp UNKNOWN 
> 
> Diff: http://codereview.secondlife.com/r/26/diff
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Kitty
> 
>

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

Re: [opensource-dev] Review Request: Settings.xml: redundant entries and unnecessary tag

[Jonathan Yap]

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



indra/newview/app_settings/settings.xml


I agree with your observation that the first (and deleted) record has a 
better Comment string.  But without looking at the code I do not want to go 
making changes to the wording--my goal was just to eliminate obvious duplicates.



indra/newview/app_settings/settings.xml


The viewer uses the last record of a repeated group, so it in this case it 
is using 10.0 (just to be sure I started the viewer and looked).



indra/newview/app_settings/settings.xml


If I had to make a guess I would say that the 2nd entry for Outbandwidth 
was the original and that someone copied it up 1 level and put in a comment 
"Expand render stats display" but forgot to change the associated key.  One 
could argue that having a F32 is wrong and that it should be an unsigned 
integer, depending on what units are being used (i.e. a limit of 3.25 makes 
sense if you are using kb/sec).


- Jonathan


On 2010-12-14 12:39:34, Jonathan Yap wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/18/
> ---
> 
> (Updated 2010-12-14 12:39:34)
> 
> 
> Review request for Viewer.
> 
> 
> Summary
> ---
> 
> I wrote two programs that use settings.xml to produce this massive table:
> http://wiki.secondlife.com/wiki/Debug_Settings
> 
> While doing this I found 4 places with duplicate entries and 1 entry that is 
> repeated 4 times.  There is also a pair of unnecessary tags.
> 
> Having these cleaned out would make running my program, and thus updating the 
> wiki table, easier.
> 
> I've erased all but the last entry for these redundant debug settings.
> 
> 
> This addresses bug vwr-24100.
> http://jira.secondlife.com/browse/vwr-24100
> 
> 
> Diffs
> -
> 
>   indra/newview/app_settings/settings.xml 46a990f8296f 
> 
> Diff: http://codereview.secondlife.com/r/18/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

Re: [opensource-dev] [TOS]Question about TOS

[Trilo Byte]

As the header of the TOS indicated, the changes were in preparation for the 
coming changes.  As per the published info (which was linked in the terms), 
that isn't due to happen until January.

If you're concerned about a company or organization sneaking in clauses
or rules that you wouldn't agree with, you should probably read the
document more carefully before checking the box to indicate that you 
accept the terms.

On Dec 16, 2010, at 8:43 AM, Malachi Prophit wrote:

> We all had to accept a new TOS stating that the teen grid and the main  
> grid were now one grid. However after having my son log into his teen grid  
> account we found that he is not on the main grid, instead he is trapped on  
> the teen grid. He has no access to the main grid and we have no access to  
> him. Not even the ability to see his profile or he see ours.
> 
> My question is this, If we had to accept a new TOS that integrated the  
> merger of the two grids and the two grids WERE NOT merged, what hidden  
> take our souls clause has LL added to the TOS, and shoved down our throats  
> this time?
> 
> 
> -- 
> Using Opera's revolutionary email client: http://www.opera.com/mail/
> ___
> 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

Re: [opensource-dev] Review Request: Crash in LLRemoteParcelInfoProcessor::processParcelInfoReply()

[Kitty Barnett]

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

(Updated 2010-12-16 11:06:44.936367)


Review request for Viewer.


Changes
---

Added comments.

I'm wondering if there is still a reason for the deadlist_t related code now?

If that was "inlined" into the loop it would become:

while (oi != end)
{
// increment the loop iterator now since it may become invalid 
below
observer_multimap_t::iterator cur_oi = oi++;

LLRemoteParcelInfoObserver * observer = cur_oi->second.get();
if(observer)
{
// may invalidate cur_oi if the observer removes itself 
observer->processParcelInfo(parcel_data);
}
else
{
// the handle points to an expired observer, so don't 
keep it
// around anymore (invalidates cur_oi)
observers.erase(cur_oi);
}
}

That might decrease the chance of the fix being reverted since even if the 
comment on "processParcelInfo" is missed, then "observers.erase()" would still 
make the need for two iterators ("oi" and "cur_oi") clear?


Summary
---

erase() on a multimap will only invalidate iterators that point to the element 
being erased so pre-incrementing the loop iterator should prevent it from 
getting invalidated when an observer calls removeObserver() as part of its 
processParcelInfo() implementation.


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


Diffs (updated)
-

  indra/newview/llremoteparcelrequest.cpp UNKNOWN 

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


Testing
---


Thanks,

Kitty

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

Re: [opensource-dev] Review Request: Crash in LLRemoteParcelInfoProcessor::processParcelInfoReply()

[Kitty Barnett]

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


*confuzzled*

Does it want an incremental change starting at the previous diff? Or a diff 
that includes the original diff (starting from viewer-dev)?

- Kitty


On 2010-12-16 11:06:44, Kitty Barnett wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/24/
> ---
> 
> (Updated 2010-12-16 11:06:44)
> 
> 
> Review request for Viewer.
> 
> 
> Summary
> ---
> 
> erase() on a multimap will only invalidate iterators that point to the 
> element being erased so pre-incrementing the loop iterator should prevent it 
> from getting invalidated when an observer calls removeObserver() as part of 
> its processParcelInfo() implementation.
> 
> 
> This addresses bug VWR-24207.
> http://jira.secondlife.com/browse/VWR-24207
> 
> 
> Diffs
> -
> 
>   indra/newview/llremoteparcelrequest.cpp UNKNOWN 
> 
> Diff: http://codereview.secondlife.com/r/24/diff
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Kitty
> 
>

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

Re: [opensource-dev] Review Request: scripts/install.py --uninstall does not always remove symbolic links.

[Brad Kittenbrink]

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

Ship it!


Looks like a safe and sensible change to me.

- Brad


On 2010-12-16 07:34:22, Aleric Inglewood wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/29/
> ---
> 
> (Updated 2010-12-16 07:34:22)
> 
> 
> Review request for Viewer.
> 
> 
> Summary
> ---
> 
> Packages (tar balls) installed with scripts/install.py do contain symbolic 
> links.
> Everything that they contain is written to the file installed.xml, and upon
> uninstall attempted to remove.
> 
> However, the python script first tests if a file exists before it removes it
> and uses os.path.exists for this, which only returns true when the target
> is a file, or a symbolic link *pointing* to an existing file.
> 
> Since the removal of the tar ball elements is arbitrary, it is possible (and
> often the case) that the file the symbolic link points to is removed before
> the symbolic link itself is removed, causing the test to fail and the symbolic
> link not to be removed.
> 
> This patch solves this bug by using os.path.lexists which returns true for
> normal files when they exist, and true for symbolic links if they exist,
> whether or not the file they point to exists, exactly what we want.
> 
> os.path.lexists was added to python 2.4, so that should not be problem.
> 
> 
> This addresses bug SNOW-744.
> http://jira.secondlife.com/browse/SNOW-744
> 
> 
> Diffs
> -
> 
>   scripts/install.py b0689af42a71 
> 
> Diff: http://codereview.secondlife.com/r/29/diff
> 
> 
> Testing
> ---
> 
> This patch was originally tested to work several months ago, and has been in
> use by the Imprudence TPV for a while now.
> 
> 
> Thanks,
> 
> Aleric
> 
>

___
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-316 Add missing "sort by name" and "sort by recent" options for folders

[Seth ProductEngine]

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


For me 'Sort Folders by Most Recent' works only when 'Sort Items by Most 
Recent' is checked. Though I can't figure out what's wrong with this patch.

- Seth


On 2010-12-16 03:33:51, Kitty Barnett wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/27/
> ---
> 
> (Updated 2010-12-16 03:33:51)
> 
> 
> Review request for Viewer.
> 
> 
> Summary
> ---
> 
> Changes the UI (and needs additional translation), but it's a viewer 1 option 
> that was missed by STORM-316.
> 
> Existing "Sort by (Name|Most Recent)" => "Sort Items by (Name|Most Recent)"
> 
> Split "Folders always by name" in two options to match what was done for 
> inventory items and added "Sort Folders by (Name|Most Recent)" menu options.
> 
> 
> This addresses bug STORM-316.
> http://jira.secondlife.com/browse/STORM-316
> 
> 
> Diffs
> -
> 
>   indra/newview/llpanelmaininventory.cpp UNKNOWN 
>   indra/newview/skins/default/xui/en/menu_inventory_gear_default.xml UNKNOWN 
> 
> Diff: http://codereview.secondlife.com/r/27/diff
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Kitty
> 
>

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

[opensource-dev] Fwd: [sldev] Anyone here with OpenCV experience?

[David Simmons]

With all the work done on the MS Kinect it seems like a good time to
revisit this issue.

On Thu, May 21, 2009 at 12:42 PM, Philip Rosedale  wrote:
> Has anyone here worked with camera-based gesture recognition before?
> How about OpenCV?  Is OpenCV the best package for extracting basic head
> position/gesture information from a camera image stream?  Merov and I
> are pondering a Snowglobe project to detect head motion from simple
> cameras and connect it to the SL Viewer.
> ___
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/SLDev
> Please read the policies before posting to keep unmoderated posting privileges
>



--
“The greatest danger in modern technology isn't that machines will
begin to think like people, but that people will begin to think like
machines” Unknown

http://www.google.com/profiles/techiedavid



-- 
“The greatest danger in modern technology isn't that machines will
begin to think like people, but that people will begin to think like
machines” Unknown

http://www.google.com/profiles/techiedavid
___
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] Can anyone tell me how to get rid of these lol...

[Ponzu]

I am not a windows guy...but I would look for an option for the linker that
suppresses errors. Then maybe set that in your environment, or figure out
how to add it to the CMake files.

ponzu

On Tue, Dec 14, 2010 at 10:23 PM, Malachi Prophit wrote:

> i get hundreds of these stupid errors. And i have since i compiled the
> first client back on 1.18. They are harmless but very annoying.
>
> they always look like this.
> Warning 3   warning LNK4099: PDB 'apr-1_ib_1.pdb' was not found with
> '..\..\..\..\libraries\i686-win32\lib\release\apr-1.lib' or at
> 'C:\Documents and
>
> Settings\Owner\Desktop\linden\indra\build-VC90\media_plugins\quicktime\Release\apr-1_ib_1.pdb';
> linking object as if no debug info  apr-1.lib
>
> I have no clue what they are or where to start ... thanks in advance.
>
>
> --
> Using Opera's revolutionary email client: http://www.opera.com/mail/
> ___
> 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

Re: [opensource-dev] Review Request: STORM-316 Add missing "sort by name" and "sort by recent" options for folders

[Kitty Barnett]

> On 2010-12-16 14:06:33, Seth ProductEngine wrote:
> > For me 'Sort Folders by Most Recent' works only when 'Sort Items by Most 
> > Recent' is checked. Though I can't figure out what's wrong with this patch.

I'm seeing it too...

I *think* (part of) the cause may be in LLFolderViewFolder::sortBy(U32 order):

if (order & LLInventoryFilter::SO_DATE)
{
time_t latest = 0;

if (!mItems.empty())
{
LLFolderViewItem* item = *(mItems.begin());
latest = item->getCreationDate();
}

if (!mFolders.empty())
{
LLFolderViewFolder* folder = *(mFolders.begin());
if (folder->getCreationDate() > latest)
{
latest = folder->getCreationDate();
}
}
mSubtreeCreationDate = latest;
}

It looks like in the case of a folder the creation date is always 
mSubtreeCreationDate and if the items aren't sorted by date, then 
mSubtreeCreationDate will never set for the folder.

I'll peek at it some more over the weekend, thankies for the feedback, Seth :).


- Kitty


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


On 2010-12-16 03:33:51, Kitty Barnett wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/27/
> ---
> 
> (Updated 2010-12-16 03:33:51)
> 
> 
> Review request for Viewer.
> 
> 
> Summary
> ---
> 
> Changes the UI (and needs additional translation), but it's a viewer 1 option 
> that was missed by STORM-316.
> 
> Existing "Sort by (Name|Most Recent)" => "Sort Items by (Name|Most Recent)"
> 
> Split "Folders always by name" in two options to match what was done for 
> inventory items and added "Sort Folders by (Name|Most Recent)" menu options.
> 
> 
> This addresses bug STORM-316.
> http://jira.secondlife.com/browse/STORM-316
> 
> 
> Diffs
> -
> 
>   indra/newview/llpanelmaininventory.cpp UNKNOWN 
>   indra/newview/skins/default/xui/en/menu_inventory_gear_default.xml UNKNOWN 
> 
> Diff: http://codereview.secondlife.com/r/27/diff
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Kitty
> 
>

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

[opensource-dev] Daily Scrum Summary - Thursday, December 16

[Anya Kanevsky]

 Thursday, December 16, 2010 General Notes
--

   - Merge Monkey of the Day: Oz


Team Status
--
 Merov Linden
--

*PAST*

   - STORM-453 : libcurl 7.21: Finished cleaning up the Mac and Linux
   builds. Built on TC for all platforms. W00t! Requested tests on
   opensource-dev before moving this to review.
   - STORM-151: kdu compression: Clean up code. Posted new diff to RB.
   Waiting for reviews (pretty please...).

*FUTURE*

   - STORM-745 : Produce comprehensive perf baseline
   - STORM-744 : Add unit tests to llkdu

*IMPEDIMENTS*

   - none

Oz Linden
--

*PAST*

   - Office Hour
   - Responded to code review posts
   - Merge Monkey
  - merged some fixes
   - Fixed some internal wiki documentation

*FUTURE*

   - libcurl test
   - Merge Monkey
   - Autobbuild audits so we can publish it as open source
   - Pull crash fixes from Kitty

*IMPEDIMENTS*

   - none


Q Linden
--

   - OOO - medical


Esbee Linden
--

*PAST*

   - Meetings
   - Catch up on emails
   - Snowstorm team meeting
   - Review integration queue
   - Prep for Viewer 2.4 release

*FUTURE*

   - Lots of meetings
   - Release Viewer 2.4
   - Post Viewer 2.4 release blog post
   - Review integration queue list and made sure "target viewer version" is
   updated for merge monkey
   - Upload sketches of saved layouts
   - VWRs to check on
  - VWR-21493
  - STORM-525
  - STORM-529. It was re-resolved as no repro.
  - STORM-702. Caused issues based on fix. Let's chat more with PE about
  this.
  - Review VWR-16569 - Will review. Jonathan wants this one.
   - Review Jonathan's work list
   - Send STORM-398 to Taka for Communications tools input
   - See comments on STORM-713

*IMPEDIMENTS*

   - Time


Paul ProductEngine
--

   - OOO - sick

Seth Productengine
--

*PAST*

   - Story (STORM-771) As someone working with outfits, copy/paste in
   Current Outfit Folder should paste links (which are supported) rather than
   objects (which are not)
  - Pushed fix after review.
   - BUG (STORM-550) LLDir::getNextFileInDir fails for some complex wildcard
   combinations
   - WIP. Found a problem with converting wildcard patterns into regexps.

*FUTURE*

   - BUG (STORM-550) LLDir::getNextFileInDir fails for some complex wildcard
   combinations

*IMPEDIMENTS*

   - Story (STORM-28) As a User, I want the ability to send my calling card
   to others.
  - Waiting for more details.

Andrew Productengine
--

*PAST*

   - Normal task STORM-2 (UI layout saving)
  - WIP. Implemented plain version of saving and started implementing
  loading. While implementing loading found problems in saving. In
process of
  changing it.
   - Critical bug STORM-525 (Runtime Error message from the Microsoft

Visual C++ Runtime Library eventually leads to Crash)

   -
  - Tried to reproduce on different locations where Mairead Fitzgerald
  but had no luck- teleported, waited and moved for some time, but didn't
  experience any cracks or even memory leaks. Maybe testers could
try to find
  some stable steps to reproduce this issue and than it would be
assigned back
  to me?
   - Critical bug STORM-786 (Back button, Username and Display Name are
   missing in Resident profile tab)
  - Helped Vadim at pre-review stage of the ticket.

*FUTURE*

   - STORM-2. Hope to finish implementation of save and load tomorrow.
  - Estimate - 2-2,5 days.

*IMPEDIMENTS*

   - STORM-777 (Design the file format for layout information and discuss
   it).
  - No reply from Q to letter regarding this issue.

Vadim Productengine
--

*PAST*

   - Showstopper bug STORM-786 (Back button, Username and Display Name are
   missing in Resident profile tab):
  - Fixed.
   - Bug STORM-410 (Region and parcel SLApps are displayed in non-human
   readable format):
  - 
WIP 70%.

*FUTURE*

   - Complete the fix for STORM-410.
   - Bug STORM-446 (CLicking on /app/classified SLapp does not open the
   classified details).
   - Bug STORM-511 (User is not able to view full name of group in title of
   group notification).

*IMPEDIMENTS*

   - Need Esbee's answer in STORM-529 (Undo feature missing from BUILD
   menu).
   - Need feedback from Nyx/Esbee in STORM-702 (Make it possible to wear
   partial outfits).

Questions:

   - What to do with VWR tickets assigned to ProductEngine Team?

https://jira.secondlife.com/secure/IssueNavigator.jspa?mode=hide&requestId=13071
 Andrey Productengine
--

*PAST*

   - exploratory testing of 2.4.0 interim release build r216842
   - ToS testing (failed by the minor issue STORM-789)
   - tested fix for STORM-786 on a private build

*FUTURE*

   - pickup final 2.4.0 release build and re-run smo

[opensource-dev] [HELP] How can I find/copy GPU settings?

[Trilo Byte]

I'm having some difficulty with the Second Life Viewer and my shiny 
new GPU (nVidia Quadro 4000).  The Mac client doesn't recognize it,
and gives me an error when I launch the Viewer app.

What's worse, dynamic shadows and deferred rendering are completely
broken (I get the same complete system crash that ATI users get).

However, the Windows client does not appear to have a problem 
recognizing the card.  I get no error, and I have no problem with the
deferred renderer or with any of the shadow settings.

I've checked against release Viewers, Snowstorm snapshots, and the
Mesh Project snapshots all with the same result.  Mac clients can't ID
or support the card, Windows clients can.

Is there someplace I can go looking around within the Windows
client (and support files) to try and find what's needed to detect my
GPU so I can rig up Mac support?

I'd appreciate any help/ideas

Cheers

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

Re: [opensource-dev] Review Request: Crash in LLRemoteParcelInfoProcessor::processParcelInfoReply()

[Aleric Inglewood]

> On 2010-12-16 11:11:33, Kitty Barnett wrote:
> > *confuzzled*

Does it want an incremental change starting at the previous diff? Or a diff 
that includes the original diff (starting from viewer-dev)?

When I click on the link 'Diff r2', I don't get a diff - I get an error message 
that 2 our of 5 hunks failed to apply.


- Aleric


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


On 2010-12-16 11:06:44, Kitty Barnett wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/24/
> ---
> 
> (Updated 2010-12-16 11:06:44)
> 
> 
> Review request for Viewer.
> 
> 
> Summary
> ---
> 
> erase() on a multimap will only invalidate iterators that point to the 
> element being erased so pre-incrementing the loop iterator should prevent it 
> from getting invalidated when an observer calls removeObserver() as part of 
> its processParcelInfo() implementation.
> 
> 
> This addresses bug VWR-24207.
> http://jira.secondlife.com/browse/VWR-24207
> 
> 
> Diffs
> -
> 
>   indra/newview/llremoteparcelrequest.cpp UNKNOWN 
> 
> Diff: http://codereview.secondlife.com/r/24/diff
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Kitty
> 
>

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

Re: [opensource-dev] [HELP] How can I find/copy GPU settings?

[Aleric Inglewood]

In indra/newview/llfeaturemanager.cpp  LLFeatureManager::loadGPUClass
reads the file GPU_TABLE_FILENAME
and LLFeatureManager::parseGPUTable matches
the string 'renderer' with it.
You could start with printing 'renderer'
and see if it's the same on windows
and Mac and if not find out why not.
If on Mac it makes sense nevertheless,
you'd have to find out why gGLManager.getRawGLString()
isn't returning the right thing. As a work around
you could hardcode the correct string into your viewer.

On Fri, Dec 17, 2010 at 1:09 AM, Trilo Byte  wrote:
> I'm having some difficulty with the Second Life Viewer and my shiny
> new GPU (nVidia Quadro 4000).  The Mac client doesn't recognize it,
> and gives me an error when I launch the Viewer app.
>
> What's worse, dynamic shadows and deferred rendering are completely
> broken (I get the same complete system crash that ATI users get).
>
> However, the Windows client does not appear to have a problem
> recognizing the card.  I get no error, and I have no problem with the
> deferred renderer or with any of the shadow settings.
>
> I've checked against release Viewers, Snowstorm snapshots, and the
> Mesh Project snapshots all with the same result.  Mac clients can't ID
> or support the card, Windows clients can.
>
> Is there someplace I can go looking around within the Windows
> client (and support files) to try and find what's needed to detect my
> GPU so I can rig up Mac support?
>
> I'd appreciate any help/ideas
>
> Cheers
>
> TriloByte Zanzibar
> ___
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/OpenSource-Dev
> Please read the policies before posting to keep unmoderated posting privileges
>
___
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] How can I find/copy GPU settings?

[Aleric Inglewood]

On Fri, Dec 17, 2010 at 2:48 AM, Aleric Inglewood
 wrote:
> In indra/newview/llfeaturemanager.cpp  LLFeatureManager::loadGPUClass
> reads the file GPU_TABLE_FILENAME
> and LLFeatureManager::parseGPUTable matches
> the string 'renderer' with it.
> You could start with printing 'renderer'
> and see if it's the same on windows
> and Mac and if not find out why not.
> If on Mac it makes sense nevertheless,
> you'd have to find out why gGLManager.getRawGLString()
> isn't returning the right thing. As a work around

I meant.. if it makes sense, you could add a line
to gpu_table.txt

Also, if this fails you should get a warning in the
debug output that prints renderer:

LL_WARNS("RenderInit") << "Couldn't match GPU to a class: " <<
gGLManager.getRawGLString() << LL_ENDL;

> you could hardcode the correct string into your viewer.
>
> On Fri, Dec 17, 2010 at 1:09 AM, Trilo Byte  wrote:
>> I'm having some difficulty with the Second Life Viewer and my shiny
>> new GPU (nVidia Quadro 4000).  The Mac client doesn't recognize it,
>> and gives me an error when I launch the Viewer app.
>>
>> What's worse, dynamic shadows and deferred rendering are completely
>> broken (I get the same complete system crash that ATI users get).
>>
>> However, the Windows client does not appear to have a problem
>> recognizing the card.  I get no error, and I have no problem with the
>> deferred renderer or with any of the shadow settings.
>>
>> I've checked against release Viewers, Snowstorm snapshots, and the
>> Mesh Project snapshots all with the same result.  Mac clients can't ID
>> or support the card, Windows clients can.
>>
>> Is there someplace I can go looking around within the Windows
>> client (and support files) to try and find what's needed to detect my
>> GPU so I can rig up Mac support?
>>
>> I'd appreciate any help/ideas
>>
>> Cheers
>>
>> TriloByte Zanzibar
>> ___
>> Policies and (un)subscribe information available here:
>> http://wiki.secondlife.com/wiki/OpenSource-Dev
>> Please read the policies before posting to keep unmoderated posting 
>> privileges
>>
>
___
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