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

[Kitty Barnett]

> 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)?
> 
> Aleric Inglewood wrote:
> 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.
>

I know :|. 

That's why I asked if "update diff" wants an incremental diff (changes against 
the original diff), or a full diff (changes against viewer-development), or 
something else entirely?


- Kitty


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

[opensource-dev] Review Request: (STORM-550) LLDir::getNextFileInDir fails for some complex wildcard combinations

[Seth ProductEngine]

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

Review request for Viewer.


Summary
---

Fixed LLDir unit test which failed for some complex wildcard combinations.
Added a class implementing directory entries iteration with pattern matching 
which is used in unit tests instead of LLDir::getNextFileInDir.

This code has been run on Linux only. It should be tested under other platforms 
and more test cases should be provided. For example changing directory contents 
while iterating through it.


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


Diffs
-

  indra/cmake/Boost.cmake 794ad1fc71d1 
  indra/llvfs/CMakeLists.txt 794ad1fc71d1 
  indra/llvfs/lldiriterator.h PRE-CREATION 
  indra/llvfs/lldiriterator.cpp PRE-CREATION 
  indra/llvfs/tests/lldir_test.cpp 794ad1fc71d1 

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


Testing
---


Thanks,

Seth

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

Re: [opensource-dev] Review Request: (STORM-550) LLDir::getNextFileInDir fails for some complex wildcard combinations

[Oz Linden]

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



indra/llvfs/lldiriterator.h


This documentation is pretty good; it would be better if it were done in a 
way that was more doxygen compatible (putting the documentation of the methods 
on the methods).

The class should have a definition of the glob syntax and matching rules.




indra/llvfs/lldiriterator.cpp


The translation from glob to regex does not allow for escaped glob 
characters.

Suppose I wanted to find a set of file names that contained a '?' character 
- the glob would need to escape that character as in "*\?*".

I don't know if we actually care passionately about that case, but...



indra/llvfs/lldiriterator.cpp


This translation of the '*' glob character may be too general.  Most 
globbing will not match a leading '.' character in the file name (so the glob 
"*foo" will match the files "afoo" and "bfoo", but not ".foo").

This has the nice side effect of preventing any glob from matching the '.' 
and '..' directory links in unix-like file systems (which the iterator user 
should not have to deal with).




indra/llvfs/lldiriterator.cpp


What happens here if braces are not matched?

I believe what you'll get is an invalid regexp that will fail later.  
Probably better to catch it here where a reasonable diagnostic can be produced. 
 If braces != 0 at the bottom (or if it becomes < 0 the '}' case), then the 
input glob expression was invalid.



indra/llvfs/tests/lldir_test.cpp


If we're going to support the braces matching, test cases should be added 
for them.



- Oz


On 2010-12-17 12:46:52, Seth ProductEngine wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/32/
> ---
> 
> (Updated 2010-12-17 12:46:52)
> 
> 
> Review request for Viewer.
> 
> 
> Summary
> ---
> 
> Fixed LLDir unit test which failed for some complex wildcard combinations.
> Added a class implementing directory entries iteration with pattern matching 
> which is used in unit tests instead of LLDir::getNextFileInDir.
> 
> This code has been run on Linux only. It should be tested under other 
> platforms and more test cases should be provided. For example changing 
> directory contents while iterating through it.
> 
> 
> This addresses bug STORM-550.
> http://jira.secondlife.com/browse/STORM-550
> 
> 
> Diffs
> -
> 
>   indra/cmake/Boost.cmake 794ad1fc71d1 
>   indra/llvfs/CMakeLists.txt 794ad1fc71d1 
>   indra/llvfs/lldiriterator.h PRE-CREATION 
>   indra/llvfs/lldiriterator.cpp PRE-CREATION 
>   indra/llvfs/tests/lldir_test.cpp 794ad1fc71d1 
> 
> Diff: http://codereview.secondlife.com/r/32/diff
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Seth
> 
>

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

Re: [opensource-dev] [HELP] LLFeaturemanager.cpp question

[Trilo Byte]

In the indra/newview/llfeaturemanager.cpp file, it references a featuretable 
text file.

Is this still in use?  As I peruse the featuretable_mac.txt file, it appears 
that no 
machine/gpu-specific information exists not only for the current lineup, but 
for any 
Mac made in 2 1/2 years.  If it is still used, I can try to work on getting the 
list updated
to include settings for recent gpu's.

(the featuretable.txt file for PC's looks similarly outdated, but I'm not 
familiar enough 
with that platform to be of much help in updating that list).

Also, I'm unclear on what the renderer listings (in lines 720-755 and other 
places)
refers to.  Are those external driver file names, or are there renderer files
someplace within the viewer codebase repository that I'm not seeing?


TriloByte Zanzibar


On Dec 16, 2010, at 5:48 PM, 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
> 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] LLFeaturemanager.cpp question

[Kent Quirk (Q Linden)]

I haven't delved into this code recently, but the featuretable is now 
downloaded from our servers each time (so we can adjust without having to 
re-release the software). It does lag by one iteration, though (we've already 
set up the video by the time it's downloaded, so it affects the NEXT run). The 
online version of the table is kept pretty current. 

Q

On Dec 17, 2010, at 9:07 PM, Trilo Byte wrote:

> In the indra/newview/llfeaturemanager.cpp file, it references a featuretable 
> text file.
> 
> Is this still in use?  As I peruse the featuretable_mac.txt file, it appears 
> that no 
> machine/gpu-specific information exists not only for the current lineup, but 
> for any 
> Mac made in 2 1/2 years.  If it is still used, I can try to work on getting 
> the list updated
> to include settings for recent gpu's.
> 
> (the featuretable.txt file for PC's looks similarly outdated, but I'm not 
> familiar enough 
> with that platform to be of much help in updating that list).
> 
> Also, I'm unclear on what the renderer listings (in lines 720-755 and other 
> places)
> refers to.  Are those external driver file names, or are there renderer files
> someplace within the viewer codebase repository that I'm not seeing?
> 
> 
> TriloByte Zanzibar
> 
> 
> On Dec 16, 2010, at 5:48 PM, 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
>> 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

___
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] LLFeaturemanager.cpp question

[Trilo Byte]

Is there a way, then, to add support for a newly released GPU (Quadro 4000) for 
the Mac client?  If there is some specific info that's need, I'd be happy to 
track it down.

On Dec 17, 2010, at 8:38 PM, Kent Quirk (Q Linden) wrote:

> I haven't delved into this code recently, but the featuretable is now 
> downloaded from our servers each time (so we can adjust without having to 
> re-release the software). It does lag by one iteration, though (we've already 
> set up the video by the time it's downloaded, so it affects the NEXT run). 
> The online version of the table is kept pretty current. 
> 
>Q
> 
> On Dec 17, 2010, at 9:07 PM, Trilo Byte wrote:
> 
>> In the indra/newview/llfeaturemanager.cpp file, it references a featuretable 
>> text file.
>> 
>> Is this still in use?  As I peruse the featuretable_mac.txt file, it appears 
>> that no 
>> machine/gpu-specific information exists not only for the current lineup, but 
>> for any 
>> Mac made in 2 1/2 years.  If it is still used, I can try to work on getting 
>> the list updated
>> to include settings for recent gpu's.
>> 
>> (the featuretable.txt file for PC's looks similarly outdated, but I'm not 
>> familiar enough 
>> with that platform to be of much help in updating that list).
>> 
>> Also, I'm unclear on what the renderer listings (in lines 720-755 and other 
>> places)
>> refers to.  Are those external driver file names, or are there renderer files
>> someplace within the viewer codebase repository that I'm not seeing?
>> 
>> 
>> TriloByte Zanzibar
>> 
>> 
>> On Dec 16, 2010, at 5:48 PM, 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
>>> 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
> 

___
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