Re: [opensource-dev] Review Request: one-line fix for OPEN-39: (standalone) bitpack_test.o: No such file or directory

[Boroondas Gupte]

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

(Updated March 2, 2011, 5:32 a.m.)


Review request for Viewer and Aleric Inglewood.


Changes
---

(fixed typo in summary)


Summary (updated)
---

On standalone, -I"${TUT_INCLUDE_DIR}" was added to the compile flags for 
integration tests of llcommon when TUT_INCLUDE_DIR might not have been set yet. 
This lead to a flag -I"", which would confuse g++ and lead to the tests' object 
files not being found.

This change makes sure that TUT_INCLUDE_DIR is set by including Tut.cmake, 
which is responsible for setting it.


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


Diffs
-

  doc/contributions.txt 1013caf84c2e 
  indra/cmake/LLAddBuildTest.cmake 1013caf84c2e 

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


Testing
---

Clean rebuild with LL_TESTS ON (see also repro instructions on jira)


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-721) Information about resident is displayed incorrectly in mini-inspector if there are any resident or group SLURLs

[Seth ProductEngine]

> On March 1, 2011, 4:01 p.m., Boroondas Gupte wrote:
> > indra/llui/lltextbase.cpp, lines 1044-1052
> > 
> >
> > Only tangent to your code, but is the scoping (the "{" and "}") here 
> > doing anything useful? (It causes the "clip" object to be destructed one 
> > line earlier, but is that the intention?)
> > 
> > Also, it seems the "clip" object is never used. Does it do all its work 
> > in its constructor?

The clip object here does all its work in the constructor (see usage example in 
lllocalcliprect.h) - it clips the area inside which GL objects are rendered.

I tried to change the logic as little as possible so I moved the call to 
LLUICtrl::draw() to render the document view after drawText() is called to 
avoid possible blinking caused by hiding some of the embedded widgets. In case 
when LLUICtrl::draw() is called prior to drawText() some embedded widgets 
located outside visible document area will appear for a single frame before 
they are hidden in drawText().


- Seth


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


On March 1, 2011, 1:53 p.m., Seth ProductEngine wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/169/
> ---
> 
> (Updated March 1, 2011, 1:53 p.m.)
> 
> 
> Review request for Viewer.
> 
> 
> Summary
> ---
> 
> Fixed text editor to display the embedded widgets only if they are in the 
> currently visible area of a text document.
> 
> 
> This addresses bug STORM-721.
> http://jira.secondlife.com/browse/STORM-721
> 
> 
> Diffs
> -
> 
>   indra/llui/lltextbase.cpp 767feb16f05f 
> 
> Diff: http://codereview.secondlife.com/r/169/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

[opensource-dev] Open Development User Group cancelled today

[Oz Linden (Scott Lawrence)]

 I need to leave work early today to go pick up a new car.


___
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-28) As a User, I want the ability to send my calling card to others

[Seth ProductEngine]

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

(Updated March 2, 2011, 8:47 a.m.)


Review request for Viewer.


Changes
---

Corrected spelling.


Summary
---

- Added creating own calling card for the user to be able to share it with 
other residents.
- Moved calling cards synchronization with friends list to the viewer start up. 
Previously synchronized upon opening the Friends tab in People side panel.
- Calling cards for non-friends are not removed upon calling cards 
synchronization with friends list.
- Enabled "Share" menu item for calling cards in inventory.


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


Diffs (updated)
-

  indra/newview/llfriendcard.h 767feb16f05f 
  indra/newview/llfriendcard.cpp 767feb16f05f 
  indra/newview/llinventoryfunctions.cpp 767feb16f05f 
  indra/newview/llpanelpeople.cpp 767feb16f05f 

Diff: http://codereview.secondlife.com/r/159/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-28) As a User, I want the ability to send my calling card to others

[Seth ProductEngine]

> On March 1, 2011, 7:04 p.m., Merov Linden wrote:
> > I've nothing against lazy evaluation (I actually like that) but I don't 
> > like "static bool" showing up in the middle of the code to execute a piece 
> > of initialization once. Is that really something that should be done *once* 
> > per instance of the application or *once* per instantiation of the object? 
> > I'd prefer to have that synchronization done in the constructor or in an 
> > init method or at least have the bool a class or object member (as 
> > adequate) that's set to true on instantiation.

The code with "static bool" is not new, I've just moved it to sync the calling 
card with friends list on viewer start up.

LLInventoryFriendCardObserver::changed() is used to make sure the inventory 
became usable since the viewer had started, so this is not a part of 
LLInventoryFriendCardObserver initialization but rather an action that should 
be taken once per viewer session.

When working on the patch I didn't replace this static with a member because it 
was not meant to be used elsewhere.


- Seth


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


On March 2, 2011, 8:47 a.m., Seth ProductEngine wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/159/
> ---
> 
> (Updated March 2, 2011, 8:47 a.m.)
> 
> 
> Review request for Viewer.
> 
> 
> Summary
> ---
> 
> - Added creating own calling card for the user to be able to share it with 
> other residents.
> - Moved calling cards synchronization with friends list to the viewer start 
> up. Previously synchronized upon opening the Friends tab in People side panel.
> - Calling cards for non-friends are not removed upon calling cards 
> synchronization with friends list.
> - Enabled "Share" menu item for calling cards in inventory.
> 
> 
> This addresses bug STORM-28.
> http://jira.secondlife.com/browse/STORM-28
> 
> 
> Diffs
> -
> 
>   indra/newview/llfriendcard.h 767feb16f05f 
>   indra/newview/llfriendcard.cpp 767feb16f05f 
>   indra/newview/llinventoryfunctions.cpp 767feb16f05f 
>   indra/newview/llpanelpeople.cpp 767feb16f05f 
> 
> Diff: http://codereview.secondlife.com/r/159/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-1001: Viewer needlessly hits the "ObjectMedia" cap with thousands of requests

[Kelly Washington]

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

Ship it!


This change looks good to me. It looks cleaner and more correct.

- Kelly


On Feb. 22, 2011, 11:12 a.m., Kitty Barnett wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/162/
> ---
> 
> (Updated Feb. 22, 2011, 11:12 a.m.)
> 
> 
> Review request for Viewer.
> 
> 
> Summary
> ---
> 
> S32 LLTextureEntry::setMediaTexGen(U8 media) would appear to be the root 
> cause of the bug:
> 
> The header file suggests that:
> 
> // The Media Tex Gen values are bits in a bit field:
> // +--+
> // | .TTM | M = Media Flags (web page), T = LLTextureEntry::eTexGen, . = 
> unused
> // | 76543210 |
> // +--+
> const S32 TEM_MEDIA_MASK  = 0x01;
> const S32 TEM_TEX_GEN_MASK= 0x06;
> 
> and while LLTextureEntry::setTexGen() and LLTextureEntry::setMediaFlags() 
> each properly mask off the supplied parameter with their respective bit mask, 
> setMediaTexGen() will always return TEM_CHANGE_MEDIA even if only texgen has 
> changed while the media flag hasn't (causing 
> LLVOVolume::processUpdateMessage() to queue a request to the cap when it 
> shouldn't).
> 
> Changing it to:
> 
> S32 LLTextureEntry::setMediaTexGen(U8 media)
> {
>   S32 result = setTexGen(media & TEM_TEX_GEN_MASK);
>   result |= setMediaFlags(media & TEM_MEDIA_MASK);
>   return result;
> }
> 
> appears to resolve the issue completely (the cap isn't hit unless an object 
> nearby has media on it, or changes its URL)
> 
> 
> This addresses bug STORM-1001.
> http://jira.secondlife.com/browse/STORM-1001
> 
> 
> Diffs
> -
> 
>   indra/llprimitive/lltextureentry.cpp UNKNOWN 
> 
> Diff: http://codereview.secondlife.com/r/162/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: STORM-1001: Viewer needlessly hits the "ObjectMedia" cap with thousands of requests

[Kelly Washington]

> On March 1, 2011, 10:22 p.m., Merov Linden wrote:
> > indra/llprimitive/lltextureentry.cpp, line 433
> > 
> >
> > Looks like you need to add creation/deletion of mMediaEntry if the 
> > TEM_MEDIA_MASK bit flipped.

That is covered in LLTextureEntry::setMediaFlags.


- Kelly


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


On Feb. 22, 2011, 11:12 a.m., Kitty Barnett wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/162/
> ---
> 
> (Updated Feb. 22, 2011, 11:12 a.m.)
> 
> 
> Review request for Viewer.
> 
> 
> Summary
> ---
> 
> S32 LLTextureEntry::setMediaTexGen(U8 media) would appear to be the root 
> cause of the bug:
> 
> The header file suggests that:
> 
> // The Media Tex Gen values are bits in a bit field:
> // +--+
> // | .TTM | M = Media Flags (web page), T = LLTextureEntry::eTexGen, . = 
> unused
> // | 76543210 |
> // +--+
> const S32 TEM_MEDIA_MASK  = 0x01;
> const S32 TEM_TEX_GEN_MASK= 0x06;
> 
> and while LLTextureEntry::setTexGen() and LLTextureEntry::setMediaFlags() 
> each properly mask off the supplied parameter with their respective bit mask, 
> setMediaTexGen() will always return TEM_CHANGE_MEDIA even if only texgen has 
> changed while the media flag hasn't (causing 
> LLVOVolume::processUpdateMessage() to queue a request to the cap when it 
> shouldn't).
> 
> Changing it to:
> 
> S32 LLTextureEntry::setMediaTexGen(U8 media)
> {
>   S32 result = setTexGen(media & TEM_TEX_GEN_MASK);
>   result |= setMediaFlags(media & TEM_MEDIA_MASK);
>   return result;
> }
> 
> appears to resolve the issue completely (the cap isn't hit unless an object 
> nearby has media on it, or changes its URL)
> 
> 
> This addresses bug STORM-1001.
> http://jira.secondlife.com/browse/STORM-1001
> 
> 
> Diffs
> -
> 
>   indra/llprimitive/lltextureentry.cpp UNKNOWN 
> 
> Diff: http://codereview.secondlife.com/r/162/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] VCmsbuildOpenSourceRelWithDebInfo Incremental Link Testers Needed.

[Twisted Laws]

This works well for me and is much  nicer than it starting over every build.

 


Date: Tue, 1 Mar 2011 12:26:45 -0800
From: nickyper...@yahoo.com
To: opensource-dev@lists.secondlife.com
Subject: [opensource-dev] VCmsbuildOpenSourceRelWithDebInfo Incremental Link 
Testers Needed.





One line addition to autobuild.xml VCmsbuildRelWithDebInfo Section for 
incremental linking.




   VC10msbuildRelWithDebInfo

  build
  
command
msbuild.exe
options

  SecondLife.sln
  /t:build
  /p:Configuration=RelWithDebInfo
  /p:Platform=Win32
  /p:"VCBuildAdditionalOptions= /useenv"
  /p:"VCBuildAdditionalOptions= /incremental"
  
  
  configure
  
options

  -G
  "Visual Studio 10"
  -DSTANDALONE:BOOL=FALSE
  -DINSTALL_PROPRIETARY=FALSE
  -DFMOD=TRUE

  
  name
  VC10msbuildRelWithDebInfo

   



___ 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] VCmsbuildOpenSourceRelWithDebInfo Incremental Link Testers Needed.

[Nicky Perian]

Thanks for testing and feed back.
I committed this to viewer-autobuild2010-wip earlier today.

Nicky




From: Twisted Laws 
To: nickyper...@yahoo.com; SLDEV 
Sent: Wed, March 2, 2011 3:10:21 PM
Subject: RE: [opensource-dev] VCmsbuildOpenSourceRelWithDebInfo Incremental 
Link 
Testers Needed.

 This works well for me and is much  nicer than it starting over every build.

 

 Date: Tue, 1 Mar 2011 12:26:45 -0800
From: nickyper...@yahoo.com
To: opensource-dev@lists.secondlife.com
Subject: [opensource-dev] VCmsbuildOpenSourceRelWithDebInfo Incremental Link 
Testers Needed.

 
One line addition to autobuild.xml VCmsbuildRelWithDebInfo Section for 
incremental linking. 



   VC10msbuildRelWithDebInfo

  build
  
command
msbuild.exe
options

  SecondLife.sln
  /t:build
  /p:Configuration=RelWithDebInfo
  /p:Platform=Win32
  /p:"VCBuildAdditionalOptions= /useenv"
  /p:"VCBuildAdditionalOptions= /incremental"
  
  
  configure
  
options

  -G
  "Visual Studio 10"
  -DSTANDALONE:BOOL=FALSE
  -DINSTALL_PROPRIETARY=FALSE
  -DFMOD=TRUE

  
  name
  VC10msbuildRelWithDebInfo




___ 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] Is 'STANDALONE' confusing?

[Philippe (Merov) Bossut]

Hi,

We passed the time limit set by Oz on OPEN-11, but, as I'm working on
STORM-1023 (née OPEN-4) which is a case of NOT STANDALONE that actually
requires some "do it yourself libs", I put some thoughts in this.

The build basically covers 2 very general case wrt 3rd party libs:
- use LL prebuilt binaries: this is the "normal" case, the one that was
initially coded and used by everyone in LL. In that case, 3rd party libs and
headers  packaged by LL (possibly using some patches or some special compile
options) are fetched and now installed in
build-/packages/{include,lib}.
- do not use LL prebuilt binaries: this is the case where a dev wants to use
its own set of built libs or system available libs. In that case (named
"STANDALONE" which I always interpreted as "I'm on my own"), some special
logic in Find.cmake will try to locate the libs and includes in
some well known probable folders.

In case where you cannot (or don't want to) use the LL prebuilt binary (e.g.
fmod) and/or do not have them in some system folder (Find.cmake
won't find them), you can (or should) specify a path using:
-D_INCLUDE_DIR= -D_LIBRARY=

I really think this covers all reasonable cases.

Dropping privately built 3rd party libs though was always a bit of a black
art. Now that most 3rd party libs have a public repo available at
lindenlab/3p- though, you have another possibility which is to
build the package yourself and point autobuild.xml to it using a
"file:///" url (don't forget to also change the md5 hash...). That
will extract libs and includes and drop them in build-/packages. I
experimented with that in OPEN-6 and it works fine.

That last trick though will not work if STANDALONE is specified which makes
me think now that STANDALONE really means "USE_SYSTEM_LIBS".

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