Re: [opensource-dev] autobuild & VS 2010 support merged to viewer-development

2011-04-05 Thread Mike Chase
On Mon, 2011-04-04 at 20:36 -0700, Trilo Byte wrote: 
> Last build with working multi-wearables (on Mac client, anyways) was
> 225589.  I've created a JIRA issue for the bug
> - https://jira.secondlife.com/browse/VWR-25421
> 
> 
> If any Windows/Linux users could please check this out and see if they
> can reproduce, I'd appreciate it.

I can't say I've actually done this before but I can confirm the
described behaviour on Linux.

Mike

> 
> TriloByte Zanzibar
> 
> On Apr 4, 2011, at 7:47 PM, Trilo Byte wrote:
> 
> > Found something that appears to have broken in 225670 -
> > multi-wearables.
> > 
> > Adding multiple attachments still works as expected, right click on
> > an attachment in your inventory or the My Appearance tab and choose
> > Add to add it to your currently worn outfit.  However, multiple
> > layers is broken - the Add button is ghosted when selecting
> > additional clothing layers in your SL inventory.  It does work as
> > expected if selecting an additional clothing layer item from one of
> > your established outfit folders in the My Appearance tab.
> > 
> > I'll start winding back through the builds to try and identify the
> > version this was broken in, this is a major regression to the
> > fashion set and hopefully this can be fixed before 2.6.3 goes to
> > beta.
> > 
> > On Apr 1, 2011, at 3:08 PM, Oz Linden (Scott Lawrence) wrote:
> > 
> > > The autobuild and Visual Studio 2010 branch has been merged to 
> > > viewer-development
> > > 
> > > develop.py is dead, long live autobuild
> > > 
> > > We did not get the OPEN-50 changes in before this merge, but it
> > > will be 
> > > very high priority for early next week.
> > > 
> > > ___
> > > 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] UI produces just grey boxes

2011-04-05 Thread Boroondas Gupte
On 04/05/2011 07:46 AM, Glimmering Sands wrote:
> Please see the attached screen shots to
> understand what I mean.
These look like your build is failing to load the images included in the
viewer's Artwork from disk. I guess images received from the network or
retrieved from the cache work (There's an IM session icon visible in the
second screenshot.), so it's probably not an issue with decoding images
in general.

As the artwork is now included in the source repository, it can't be
that you forgot to unpack it. (That was a common cause of this symptom
with 1.x Viewers.) So probably it's either a image file type specific
problem (I think most of the viewer artwork is PNG while textures
received from the asset system are JPEG2000) or your build is for some
reason looking for the artwork at the wrong place.

Things you can try to narrow down the cause:

* Try another build (e.g. official download) on your machine and see
  whether it suffers from the same problem.
* Create a new operating system user account on your system and try
  your build with that.
* Create a new SL user account and try your build with that.
* Try your build on another computer.

Lastly, see whether the build instructions have been updated since you
last read them. Maybe something needs to be done differently than before
to get a fully working build.

Cheers & good luck,
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: Squared all dist_vec() based comparisons and other dist_vec() operations where sensible.

2011-04-05 Thread Boroondas Gupte
On 04/05/2011 02:20 AM, Ricky wrote:
> Consider the following replacement for the section under consideration:
> ---
> }
> // factor the distance into the displacement vector. This will get us
> // equally visible movements for both close and far away selections.
> F32 min_dist = sqrt(fsqrtf(min_dist_squared)) / 2;
As fsqrtf(min_dist_squared) isn't used except for computing this
expression, it might make sense to write it in one line like this, thus
saving one variable. However, I do not think doing so solves the naming
problem. Note how min_dist now stores the exact value we were unsure how
to call. And because it's an order-four root of min_dist_squared,
min_dist is a misnomer for it. The only obvious way to avoid having to
name that value is to move the call to the outer sqrt into the arguments
of the following setVec. That however means it has to be called three
times, which makes it a bit silly considering the overall intention of
your change is optimization. Off course, two of the three calls might be
automatically optimized away by the compiler, as the sqrt function
should of course be referentially transparent
,
but I don't know how reliable that is.

If you cannot stand the ugliness of  half_sqrt_of_min_dist, just use
"tmp" (short for 'temporary') instead. That nicely implies nothing about
the variable's content (which is good, as, while we know how it's
calculated, we don't seem to be sure about its semantic) and at the same
time signifies that we use the variable to store a value /once/, so we
don't have to re-compute it /several times/ later on. (Which is true,
see paragraph above.)

> displ_global.setVec(displ.mV[0] * min_dist,
> displ.mV[1] * min_dist,
> displ.mV[2] * min_dist);
>
> // equates to: Displ_global = Displ * M_cam_axes_in_global_frame
> ---
> Yes, the double nested sqrt is rather strange to behold.  The inner
> fsqrtf came from the definition of vec_dist() and I wanted it to match
> that definition to make absolutely sure that this change is nothing
> more than a refactor.
>
> The inner sqrt is to make it the minimum distance.  The outer, and
> its subsequent division by two, are what are so confusing: what does
> this code do?  Why does it do it that way? The comment doesn't seem to
> shed much more light than can be gained from reading the code; it
> doesn't give the reasons behind the functionality.
My guess is that the formula was found by trail and error to make it
"feel right" when moving objects with a SpaceNavigator. Probably for
some arbitrary  value of "feel right" that is specific to the
developer(s) who did it. It'd have to try it again to know how it
actually feels. (While I use my SpaceNavigator for camera movement and
avatar navigation a lot, I rarely use it for moving objects.)

> Now, as to what fsqrtf is... According to math.h, it is part of a
> multiple-level #define chain that results in the following: fsqrtf(x)
> = sqrtf(x) = ((F32)sqrt((F64)(x)))
>
> So aside from the extra type conversions, fsqrtf is practically the
> same as sqrt.  Does that change anything?  Should I just make both
> sqrts one or the other?
As obj_pos and getOrigin() are both of type LLVector3, not of type
LLVector3d, sqrt(min_dist_squared) yield the same result as
((F32)sqrt((F64)(min_dist_squared))) even if we were to change the type
of min_dist_squared to F64, I think.

> Or should I just leave this mess and move on to making sure the rest
> of the patch is done?
Yes, I'd say so.

> (Which it practically is, we are just quibbling over the last
> stragglers as far as I can tell.)
Indeed. :-)

Cheers,
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-941) IM log naming should go by SL name, not DN.

2011-04-05 Thread Vadim ProductEngine

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


Looks fine, except for two issues.


indra/llui/llurlaction.h


I don't agree that LLURLAction as an appropriate place for this method: the 
method does no user-visible action ant thus should be moved to an auxiliary 
class (not sure which one, needs investigation).



indra/newview/llimview.cpp


What happens to messages logged in between the call to buildUserName() and 
the moment when the name gets asynchronously refreshed by onAvatarNameCache()?

It looks like the messages may be logged to a different file than 
subsequent ones.
If that's the case, maybe the old file should be renamed once you've got 
the updated name?


- Vadim


On April 4, 2011, 4:30 p.m., Seth ProductEngine wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/249/
> ---
> 
> (Updated April 4, 2011, 4:30 p.m.)
> 
> 
> Review request for Viewer.
> 
> 
> Summary
> ---
> 
> Fixed IM history to use the resident's user name for the log file name.
> Added conversions from legacy names or SLURLs with avatar id to the user 
> names in cases of logging P2P sessions and inventory offers.
> 
> 
> This addresses bug STORM-941.
> http://jira.secondlife.com/browse/STORM-941
> 
> 
> Diffs
> -
> 
>   indra/llui/llurlaction.h d30636c2a83a 
>   indra/llui/llurlaction.cpp d30636c2a83a 
>   indra/newview/llgiveinventory.cpp d30636c2a83a 
>   indra/newview/llimview.cpp d30636c2a83a 
>   indra/newview/llnotificationhandler.h d30636c2a83a 
>   indra/newview/llnotificationhandlerutil.cpp d30636c2a83a 
> 
> Diff: http://codereview.secondlife.com/r/249/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] Review Request: (STORM-721) Information about resident is displayed incorrectly in mini-inspector if there are any resident or group SLURLs

2011-04-05 Thread Seth ProductEngine

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

Review request for Viewer.


Summary
---

Fix for text box clipping in a textbox without a scroller.

Published on behalf of Richard Linden:
This patch makes clipping work consistently with text and embedded widgets. The 
widgets will only be displayed if the corresponding text they are embedded in 
is displayed.  There is also a new param "clip" for text widgets that can be 
used to disable clipping entirely.  I introduced this as a potential work 
around due to the fact that we *used* to assume that text was never clipped in 
the vertical direction unless we had scrolling turned on.  This hasn't been the 
case for over a year, but now we can selectively turn off vertical text 
clipping with (clip="false") if we have to.


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


Diffs
-

  indra/llui/lltextbase.h d30636c2a83a 
  indra/llui/lltextbase.cpp d30636c2a83a 

Diff: http://codereview.secondlife.com/r/250/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-941) IM log naming should go by SL name, not DN.

2011-04-05 Thread Wolfpup Lowenhar

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



indra/llui/llurlaction.h


Having this here looks to be the best way to prevent generating a Legacy 
named P2P system message during said conversation that has been started by a 
person that DOSE NOT have Display Names turned on as there is one SYSTEM 
message that would seem to be coming from no where and this looks like it is 
its source.


- Wolfpup


On April 4, 2011, 4:30 p.m., Seth ProductEngine wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/249/
> ---
> 
> (Updated April 4, 2011, 4:30 p.m.)
> 
> 
> Review request for Viewer.
> 
> 
> Summary
> ---
> 
> Fixed IM history to use the resident's user name for the log file name.
> Added conversions from legacy names or SLURLs with avatar id to the user 
> names in cases of logging P2P sessions and inventory offers.
> 
> 
> This addresses bug STORM-941.
> http://jira.secondlife.com/browse/STORM-941
> 
> 
> Diffs
> -
> 
>   indra/llui/llurlaction.h d30636c2a83a 
>   indra/llui/llurlaction.cpp d30636c2a83a 
>   indra/newview/llgiveinventory.cpp d30636c2a83a 
>   indra/newview/llimview.cpp d30636c2a83a 
>   indra/newview/llnotificationhandler.h d30636c2a83a 
>   indra/newview/llnotificationhandlerutil.cpp d30636c2a83a 
> 
> Diff: http://codereview.secondlife.com/r/249/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-721) Information about resident is displayed incorrectly in mini-inspector if there are any resident or group SLURLs

2011-04-05 Thread Seth ProductEngine


> On March 16, 2011, 12:39 a.m., Richard Nelson wrote:
> > So I've found some underlying problems with text extents measurement and 
> > clipping and I'm working on a fix now...hopefully I'll have something 
> > tomorrow

Published the patch by Richard Nelson at 
https://codereview.secondlife.com/r/250/


- Seth


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


On March 4, 2011, 10:30 a.m., Seth ProductEngine wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/169/
> ---
> 
> (Updated March 4, 2011, 10:30 a.m.)
> 
> 
> Review request for Viewer and Richard Nelson.
> 
> 
> 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] Review Request: Change to description for ShowNetStatus in debbug settings.

2011-04-05 Thread Wolfpup Lowenhar

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

Review request for Viewer.


Summary
---

This is a change in the description for the ShowNetStatus debug setting.


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


Diffs
-

  indra/newview/app_settings/settings.xml 3fc9a496265c 

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


Testing
---

None needed as this is only a textual change.


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: (STORM-941) IM log naming should go by SL name, not DN.

2011-04-05 Thread Seth ProductEngine


> On April 5, 2011, 9:02 a.m., Wolfpup Lowenhar wrote:
> > indra/llui/llurlaction.h, line 81
> > 
> >
> > Having this here looks to be the best way to prevent generating a 
> > Legacy named P2P system message during said conversation that has been 
> > started by a person that DOSE NOT have Display Names turned on as there is 
> > one SYSTEM message that would seem to be coming from no where and this 
> > looks like it is its source.

I guess Vadim is right about moving the method. Seems that just stripping a 
UUID part of a given SLURL doesn't really belong here, but moving it won't 
affect the patch functionality.

Wolfpup, do you have some objections against moving the method or some 
suggestions about the functionality changes?


- Seth


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


On April 4, 2011, 4:30 p.m., Seth ProductEngine wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/249/
> ---
> 
> (Updated April 4, 2011, 4:30 p.m.)
> 
> 
> Review request for Viewer.
> 
> 
> Summary
> ---
> 
> Fixed IM history to use the resident's user name for the log file name.
> Added conversions from legacy names or SLURLs with avatar id to the user 
> names in cases of logging P2P sessions and inventory offers.
> 
> 
> This addresses bug STORM-941.
> http://jira.secondlife.com/browse/STORM-941
> 
> 
> Diffs
> -
> 
>   indra/llui/llurlaction.h d30636c2a83a 
>   indra/llui/llurlaction.cpp d30636c2a83a 
>   indra/newview/llgiveinventory.cpp d30636c2a83a 
>   indra/newview/llimview.cpp d30636c2a83a 
>   indra/newview/llnotificationhandler.h d30636c2a83a 
>   indra/newview/llnotificationhandlerutil.cpp d30636c2a83a 
> 
> Diff: http://codereview.secondlife.com/r/249/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-941) IM log naming should go by SL name, not DN.

2011-04-05 Thread Wolfpup Lowenhar


> On April 5, 2011, 9:02 a.m., Wolfpup Lowenhar wrote:
> > indra/llui/llurlaction.h, line 81
> > 
> >
> > Having this here looks to be the best way to prevent generating a 
> > Legacy named P2P system message during said conversation that has been 
> > started by a person that DOSE NOT have Display Names turned on as there is 
> > one SYSTEM message that would seem to be coming from no where and this 
> > looks like it is its source.
> 
> Seth ProductEngine wrote:
> I guess Vadim is right about moving the method. Seems that just stripping 
> a UUID part of a given SLURL doesn't really belong here, but moving it won't 
> affect the patch functionality.
> 
> Wolfpup, do you have some objections against moving the method or some 
> suggestions about the functionality changes?

Not at all.


- Wolfpup


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


On April 4, 2011, 4:30 p.m., Seth ProductEngine wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/249/
> ---
> 
> (Updated April 4, 2011, 4:30 p.m.)
> 
> 
> Review request for Viewer.
> 
> 
> Summary
> ---
> 
> Fixed IM history to use the resident's user name for the log file name.
> Added conversions from legacy names or SLURLs with avatar id to the user 
> names in cases of logging P2P sessions and inventory offers.
> 
> 
> This addresses bug STORM-941.
> http://jira.secondlife.com/browse/STORM-941
> 
> 
> Diffs
> -
> 
>   indra/llui/llurlaction.h d30636c2a83a 
>   indra/llui/llurlaction.cpp d30636c2a83a 
>   indra/newview/llgiveinventory.cpp d30636c2a83a 
>   indra/newview/llimview.cpp d30636c2a83a 
>   indra/newview/llnotificationhandler.h d30636c2a83a 
>   indra/newview/llnotificationhandlerutil.cpp d30636c2a83a 
> 
> Diff: http://codereview.secondlife.com/r/249/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] [server-beta] BlueSteel - Inventory loading time

2011-04-05 Thread Latif Khalifa
I was implementing new inventory capabilities for
libopenmetaverse/radegast and noticed the same slowdown compared with
the old UDP method. I need to run about 8-10 concurrent http fetches
in Radegast to be on par with the previous system. I don't know how
taxing this is for the sim though.

Latif

On Mon, Apr 4, 2011 at 2:41 AM, Opensource Obscure
 wrote:
> After reading a kind remark on the forums, I did some testing
> about Inventory loading time on BlueSteel regions. I started
> from BlueSteel Sandbox 1. Actually, on this region, Inventory
> loads consistently very slowly. I did 4 tests in total there
> over 1 hour. Region is completely empty and runs smoothly.
> I tried other BlueSteel regions, and there Inventory loads
> as fast as on the other releases - included the other three
> sandboxes. So, in general, no apparent direct relation yet.
>
>
> tl;dr usually 2', at least 5' on BlueSteel Sandbox 1
>
>
> Inventory = 18k items
>
>
> Second Life RC BlueSteel 11.03.29.225233
>
> http://maps.secondlife.com/secondlife/BlueSteel%20Sandbox%201/128/128/23
> 5' - 7' - 5'15" - 5'
>
> http://maps.secondlife.com/secondlife/Ambleside/161/95/30
> 2'
>
> http://maps.secondlife.com/secondlife/Hanley/153/167/95
> 2'
>
> http://maps.secondlife.com/secondlife/Oak%20Grove/182/163/13
> 1'50"
>
> http://maps.secondlife.com/secondlife/BlueSteel%20Sandbox%202/128/120/23
> 1'50"
>
> http://maps.secondlife.com/secondlife/BlueSteel%20Sandbox%203/131/123/23
> 2'
>
> http://maps.secondlife.com/secondlife/BlueSteel%20Sandbox%204/128/128/23
> 1'50"
>
>
> Second Life Server 11.03.22.224783
>
> http://maps.secondlife.com/secondlife/Frisch/160/70/38
> 2'40" - 2'15"
>
> http://maps.secondlife.com/secondlife/LOL/14/34/55
> 1'50"
>
>
> Second Life RC Magnum 11.03.29.225234
>
> http://maps.secondlife.com/secondlife/Deshima/118/130/2975
> 2'20"
>
>
>
> --
> Opensource Obscure
> http://twitter.com/oobscure - http://opensourceobscure.com/lol
> ___
> Click here to unsubscribe or manage your list subscription:
> https://lists.secondlife.com/cgi-bin/mailman/listinfo/server-beta
>
___
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: Change to description for ShowNetStatus in debbug settings.

2011-04-05 Thread Vadim ProductEngine

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

Ship it!


I have no objections code-wise, but shouldn't the new string have been approved 
by PO/XD prior to making the change?

- Vadim


On April 5, 2011, 9:31 a.m., Wolfpup Lowenhar wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/251/
> ---
> 
> (Updated April 5, 2011, 9:31 a.m.)
> 
> 
> Review request for Viewer.
> 
> 
> Summary
> ---
> 
> This is a change in the description for the ShowNetStatus debug setting.
> 
> 
> This addresses bug STORM-1098.
> http://jira.secondlife.com/browse/STORM-1098
> 
> 
> Diffs
> -
> 
>   indra/newview/app_settings/settings.xml 3fc9a496265c 
> 
> Diff: http://codereview.secondlife.com/r/251/diff
> 
> 
> Testing
> ---
> 
> None needed as this is only a textual change.
> 
> 
> 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: (STORM-721) Information about resident is displayed incorrectly in mini-inspector if there are any resident or group SLURLs

2011-04-05 Thread Seth ProductEngine

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

Ship it!


- Seth


On April 5, 2011, 9 a.m., Seth ProductEngine wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/250/
> ---
> 
> (Updated April 5, 2011, 9 a.m.)
> 
> 
> Review request for Viewer.
> 
> 
> Summary
> ---
> 
> Fix for text box clipping in a textbox without a scroller.
> 
> Published on behalf of Richard Linden:
> This patch makes clipping work consistently with text and embedded widgets. 
> The widgets will only be displayed if the corresponding text they are 
> embedded in is displayed.  There is also a new param "clip" for text widgets 
> that can be used to disable clipping entirely.  I introduced this as a 
> potential work around due to the fact that we *used* to assume that text was 
> never clipped in the vertical direction unless we had scrolling turned on.  
> This hasn't been the case for over a year, but now we can selectively turn 
> off vertical text clipping with (clip="false") if we have to.
> 
> 
> This addresses bug STORM-721.
> http://jira.secondlife.com/browse/STORM-721
> 
> 
> Diffs
> -
> 
>   indra/llui/lltextbase.h d30636c2a83a 
>   indra/llui/lltextbase.cpp d30636c2a83a 
> 
> Diff: http://codereview.secondlife.com/r/250/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-1095 Chat preferences > font size should increase size of input text in the chat box

2011-04-05 Thread Vadim ProductEngine

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



indra/newview/llnearbychatbar.h


Avoid redundant changes.



indra/newview/llnearbychatbar.h


Remove the class prefix: it may cause compilation problems on Linux.



indra/newview/llnearbychatbar.cpp


CS: "if ("



indra/newview/llviewerchat.h


* Readability: please separate type definitions from methods.
* CS: Inconsistent naming. Should be something like font_change_signal_t.



indra/newview/llviewerchat.h


* Memory leak? Seems to be never deleted.
* Why pointer?
* Move to private section.
* CS: rename to sFontChangedSignal.


- Vadim


On March 30, 2011, 5:43 a.m., Jonathan Yap wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/244/
> ---
> 
> (Updated March 30, 2011, 5:43 a.m.)
> 
> 
> Review request for Viewer.
> 
> 
> Summary
> ---
> 
>  Chat preferences > font size should increase size of input text in the chat 
> box
> 
> 
> This addresses bug STORM-1095.
> http://jira.secondlife.com/browse/STORM-1095
> 
> 
> Diffs
> -
> 
>   doc/contributions.txt 65ff7415f171 
>   indra/llui/lllineeditor.h 65ff7415f171 
>   indra/llui/lllineeditor.cpp 65ff7415f171 
>   indra/newview/llbottomtray.cpp 65ff7415f171 
>   indra/newview/llfloaterpreference.cpp 65ff7415f171 
>   indra/newview/llnearbychatbar.h 65ff7415f171 
>   indra/newview/llnearbychatbar.cpp 65ff7415f171 
>   indra/newview/llviewerchat.h 65ff7415f171 
>   indra/newview/llviewerchat.cpp 65ff7415f171 
> 
> Diff: http://codereview.secondlife.com/r/244/diff
> 
> 
> Testing
> ---
> 
> Change font size in preferences and see
> 1) Font size in chat input box changes to new size immediately
> 2) Font size is set to selected size when viewer is restarted
> 
> 
> 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: STORM-236 Actual Code Review

2011-04-05 Thread Vadim ProductEngine

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


This review request is obsolete. Wolfpup, please close it.

- Vadim


On Jan. 20, 2011, 6:37 p.m., Wolfpup Lowenhar wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/113/
> ---
> 
> (Updated Jan. 20, 2011, 6:37 p.m.)
> 
> 
> Review request for Viewer.
> 
> 
> Summary
> ---
> 
> This allows the Speak Button to auto-hide for those that do not use Voice at 
> all.
> 
> 
> This addresses bug STORM-236.
> http://jira.secondlife.com/browse/STORM-236
> 
> 
> Diffs
> -
> 
>   doc/contributions.txt 9c7d543fd15d 
>   indra/newview/llbottomtray.h 9c7d543fd15d 
>   indra/newview/llbottomtray.cpp 9c7d543fd15d 
>   indra/newview/llspeakbutton.cpp 9c7d543fd15d 
>   indra/newview/skins/default/xui/en/menu_bottomtray.xml 9c7d543fd15d 
> 
> Diff: http://codereview.secondlife.com/r/113/diff
> 
> 
> Testing
> ---
> 
> Built locally and did the following:
> 1 Verified that when Voice is toggled via the preference panel the Speak 
> Button auto hid/showed.
> 2 Verified that drag and drop functionality of the Speak Button was not 
> affected.
> 3 Went to a non-Voice area with Voice active and verified that button was 
> still there but grayed out.
> 
> 
> 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: Use consistent path for all *.py scripts

2011-04-05 Thread Vadim ProductEngine

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


The code has been integrated. Merov, please close the review request.

- Vadim


On Feb. 11, 2011, 6:23 p.m., Merov Linden wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/129/
> ---
> 
> (Updated Feb. 11, 2011, 6:23 p.m.)
> 
> 
> Review request for Viewer.
> 
> 
> Summary
> ---
> 
> Simple consistency change, using "#!/usr/bin/python" in all python script.
> 
> 
> This addresses bug STORM-937.
> http://jira.secondlife.com/browse/STORM-937
> 
> 
> Diffs
> -
> 
>   indra/cmake/run_build_test.py 92e58e51776a 
>   indra/copy_win_scripts/start-client.py 92e58e51776a 
>   indra/develop.py 92e58e51776a 
>   indra/lib/python/indra/util/llperformance.py 92e58e51776a 
>   indra/lib/python/indra/util/llversion.py 92e58e51776a 
>   indra/lib/python/indra/util/simperf_proc_interface.py 92e58e51776a 
>   indra/lib/python/indra/util/test_win32_manifest.py 92e58e51776a 
>   indra/llmessage/tests/test_llsdmessage_peer.py 92e58e51776a 
>   indra/llmessage/tests/testrunner.py 92e58e51776a 
>   indra/newview/generate_breakpad_symbols.py 92e58e51776a 
>   indra/newview/tests/test_llxmlrpc_peer.py 92e58e51776a 
>   indra/newview/viewer_manifest.py 92e58e51776a 
>   indra/test/test_llmanifest.py 92e58e51776a 
>   scripts/build_version.py 92e58e51776a 
>   scripts/md5check.py 92e58e51776a 
>   scripts/setup-path.py 92e58e51776a 
>   scripts/template_verifier.py 92e58e51776a 
>   scripts/update_version_files.py 92e58e51776a 
> 
> Diff: http://codereview.secondlife.com/r/129/diff
> 
> 
> Testing
> ---
> 
> Pulled into a test repo and build successfully on all platforms on TC so I 
> guess no bad surprise here.
> 
> 
> 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: STORM-987 : llimage_libtest : create an independent executable to exercise llimage outside the viewer

2011-04-05 Thread Vadim ProductEngine

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


Sorry, I haven't had time to investigate the build issue further.
Anyway, the code has been integrated. Please close the review request.

- Vadim


On March 10, 2011, 10:15 p.m., Merov Linden wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/195/
> ---
> 
> (Updated March 10, 2011, 10:15 p.m.)
> 
> 
> Review request for Viewer.
> 
> 
> Summary
> ---
> 
> This creates a new independent executable that exercise the entire llimage 
> libray, loading and saving all supported image file formats, gathering perf 
> data and outputting basic image info.
> 
> The use of the application itself is documented in the wiki: 
> https://wiki.secondlife.com/wiki/Llimage_libtest
> 
> From a code standpoint, the main things done are:
> - Add a new test application in indra/integration_tests/llimage_libtest/
> - Move some perf amalyzing code from indra/newview/llfasttimerview.cpp to 
> indra/llcommon/llmetricperformancetester so that it can be used outside the 
> newview context (as it should...)
> - Small cleanup in llimage.h
> 
> 
> This addresses bug STORM-987.
> http://jira.secondlife.com/browse/STORM-987
> 
> 
> Diffs
> -
> 
>   indra/integration_tests/CMakeLists.txt 344d4c6d7d7e 
>   indra/integration_tests/llimage_libtest/CMakeLists.txt PRE-CREATION 
>   indra/integration_tests/llimage_libtest/llimage_libtest.h PRE-CREATION 
>   indra/integration_tests/llimage_libtest/llimage_libtest.cpp PRE-CREATION 
>   indra/llcommon/llmetricperformancetester.h 344d4c6d7d7e 
>   indra/llcommon/llmetricperformancetester.cpp 344d4c6d7d7e 
>   indra/llimage/llimage.h 344d4c6d7d7e 
>   indra/llimage/llimagej2c.cpp 344d4c6d7d7e 
>   indra/newview/llfasttimerview.h 344d4c6d7d7e 
>   indra/newview/llfasttimerview.cpp 344d4c6d7d7e 
> 
> Diff: http://codereview.secondlife.com/r/195/diff
> 
> 
> Testing
> ---
> 
> So far, testing has been done on Mac only. Tests on Windows and Linux are 
> planned and will likely result in cmake tweaks here and there. We're not 
> planning however to alter dramatically this code further at this point.
> 
> 
> 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: STORM-1121: make llimage_libtest build on Linux

2011-04-05 Thread Vadim ProductEngine

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


Hasn't this code been integrated already?

- Vadim


On March 31, 2011, 1:07 a.m., Boroondas Gupte wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/247/
> ---
> 
> (Updated March 31, 2011, 1:07 a.m.)
> 
> 
> Review request for Viewer.
> 
> 
> Summary
> ---
> 
> Posting Merov's fix to demonstrate the might of parent-diff. :-P
> 
> See jira for details. This review includes changesets c4d0796548e2 and 
> 5bd988b91f20.
> 
> 
> This addresses bug STORM-1121.
> http://jira.secondlife.com/browse/STORM-1121
> 
> 
> Diffs
> -
> 
>   indra/integration_tests/CMakeLists.txt 3f0988f415e7 
>   indra/integration_tests/llimage_libtest/CMakeLists.txt PRE-CREATION 
> 
> Diff: http://codereview.secondlife.com/r/247/diff
> 
> 
> Testing
> ---
> 
> Merov said ( 
> https://jira.secondlife.com/browse/STORM-1121?focusedCommentId=252239&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-252239
>  ):
> > I was able to get the Linux build to go through though I did not check the 
> > resulting llimage_libtest executable.
> 
> I (Boroondas) didn't to any testing at all.
> 
> 
> 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: fix for STORM-1049: [crashhunters] crash at LLViewerFetchedTexture::forceToSaveRawImage(int, bool)

2011-04-05 Thread Vadim ProductEngine

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


Somebody please close this empty request.

- Vadim


On None, Xiaohong Bao wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/193/
> ---
> 
> Review request for Viewer and Merov Linden.
> 
> 
> Summary
> ---
> 
> changeset: efc74a20699e
> Merov: I need to bug you again for a few more reviews for some crashes.
> 
> 
> This addresses bug storm-1049.
> http://jira.secondlife.com/browse/storm-1049
> 
> 
> Diffs
> -
> 
> 
> Diff: http://codereview.secondlife.com/r/193/diff
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Xiaohong
> 
>

___
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] Windows compiling problem

2011-04-05 Thread Jonathan Welch
I have not had much chance to compile since viewer-development took in
the autobuild changes.  This afternoon I gave it a try and fixed a few
issues but am stumped at how to fix this, which occurs in a number of
places:

-- Build started: Project: llwindow, Configuration: Release Win32 --
 llwindowwin32.cpp
 lldxhardware.cpp
e:\Microsoft SDKs\Windows\v7.1\Include\objidl.h(11280): error C2061:
syntax error : identifier '__RPC__out_xcount_part'
e:\Microsoft SDKs\Windows\v7.1\Include\objidl.h(11281): error C2059:
syntax error : ')'
e:\Microsoft SDKs\Windows\v7.1\Include\objidl.h(11281): fatal error
C1903: unable to recover from previous error(s); stopping compilation

I fiddled a bit with the include path in the props file and this is
what I currently have:
E:\Microsoft Visual Studio 10.0\VC\INCLUDE;e:\Microsoft
SDKs\Windows\v7.1\Include;e:\Microsoft
SDKs\Windows\v7.1\Include\gl;e:\Microsoft DirectX SDK (June
2010)\Include;e:\Microsoft
SDKs\Windows\v7.1\Samples\winui\TSF\tsfapp;$(WindowsSdkDir)\include;$(IncludePath)

That first entry is a result of my fiddling.  This is happening in
vs2010 but also via autobuild in a dos window.

Googling on this error says it is an issue of having the include file
list in a certain order, but as far as I can tell my list is
correct...and worked when we were testing autobuild builds before the
code got merged into viewer-development.

Can you shed any light on this?  I am stumped.
___
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-1095 Chat preferences > font size should increase size of input text in the chat box

2011-04-05 Thread Oz Linden


> On April 5, 2011, 12:35 p.m., Vadim ProductEngine wrote:
> > indra/newview/llnearbychatbar.h, line 118
> > 
> >
> > Remove the class prefix: it may cause compilation problems on Linux.

Does cause failure on Linux... I fixed it to do the PO Review build and forgot 
to mention it.  Good catch, Vadim.


- Oz


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


On March 30, 2011, 5:43 a.m., Jonathan Yap wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/244/
> ---
> 
> (Updated March 30, 2011, 5:43 a.m.)
> 
> 
> Review request for Viewer.
> 
> 
> Summary
> ---
> 
>  Chat preferences > font size should increase size of input text in the chat 
> box
> 
> 
> This addresses bug STORM-1095.
> http://jira.secondlife.com/browse/STORM-1095
> 
> 
> Diffs
> -
> 
>   doc/contributions.txt 65ff7415f171 
>   indra/llui/lllineeditor.h 65ff7415f171 
>   indra/llui/lllineeditor.cpp 65ff7415f171 
>   indra/newview/llbottomtray.cpp 65ff7415f171 
>   indra/newview/llfloaterpreference.cpp 65ff7415f171 
>   indra/newview/llnearbychatbar.h 65ff7415f171 
>   indra/newview/llnearbychatbar.cpp 65ff7415f171 
>   indra/newview/llviewerchat.h 65ff7415f171 
>   indra/newview/llviewerchat.cpp 65ff7415f171 
> 
> Diff: http://codereview.secondlife.com/r/244/diff
> 
> 
> Testing
> ---
> 
> Change font size in preferences and see
> 1) Font size in chat input box changes to new size immediately
> 2) Font size is set to selected size when viewer is restarted
> 
> 
> 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: Change to description for ShowNetStatus in debbug settings.

2011-04-05 Thread Wolfpup Lowenhar


> On April 5, 2011, noon, Vadim ProductEngine wrote:
> > I have no objections code-wise, but shouldn't the new string have been 
> > approved by PO/XD prior to making the change?

I discussed it with Oz in IRC just before posting it to here and to the online 
repository for this issue


- Wolfpup


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


On April 5, 2011, 9:31 a.m., Wolfpup Lowenhar wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/251/
> ---
> 
> (Updated April 5, 2011, 9:31 a.m.)
> 
> 
> Review request for Viewer.
> 
> 
> Summary
> ---
> 
> This is a change in the description for the ShowNetStatus debug setting.
> 
> 
> This addresses bug STORM-1098.
> http://jira.secondlife.com/browse/STORM-1098
> 
> 
> Diffs
> -
> 
>   indra/newview/app_settings/settings.xml 3fc9a496265c 
> 
> Diff: http://codereview.secondlife.com/r/251/diff
> 
> 
> Testing
> ---
> 
> None needed as this is only a textual change.
> 
> 
> 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] C++ Need help to resolve stdint.h typedef conflicts between Quicktime and VS2010

2011-04-05 Thread Kiptic ‌

>  media_plugin_quicktime.cpp
> C:\Program Files (x86)\QuickTime SDK\CIncludes\GNUCompatibility/stdint.h(49): 
> error C2371: 'int_fast16_t' : redefinition; different basic types
>   C:\Program Files (x86)\Microsoft Visual Studio 
> 10.0\VC\include\stdint.h(34) : see declaration of 'int_fast16_t'

> there are more errors like these but the same header just different int's

> I have tried #include  and #undef and that doesn't help.

Oh, interesting, I just had the same problem after switching to VS2010. Thought 
I'd share my solution :)

It turns out the geniuses at Microsoft had decided not to include stdint.h in 
their include directory (which is required by the C99 standard, that Microsoft 
apparently ignores).

This got the Apple people worried, so they added their own stdint.h to the 
QuickTime SDK. Nice, except that now for some unknown reason Microsoft decided 
it was time to add stdint.h to VS2010! Obviously with completely different 
definitions :)

Also, they failed defining the standard _STDINT_H that would tell other headers 
it exists, instead they define _STDINT only. Brilliant.

So, I had to do this:

1. In C:\Program Files (x86)\QuickTime SDK\CIncludes\CoreFoundation, comment 
out this on line 36:
#include 

2. In C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\stdint.h 
(keep a copy of the original if you like!), change line 4 from this:
#define _STDINT

...to this:
#define _STDINT
#define _STDINT_H

Voilà it now compiles properly, and so should everything else that uses 
stdint.h!

/Kip

  ___
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-1121: make llimage_libtest build on Linux

2011-04-05 Thread Boroondas Gupte


> On April 5, 2011, 12:43 p.m., Vadim ProductEngine wrote:
> > Hasn't this code been integrated already?

yes, you are right


- Boroondas


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


On March 31, 2011, 1:07 a.m., Boroondas Gupte wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/247/
> ---
> 
> (Updated March 31, 2011, 1:07 a.m.)
> 
> 
> Review request for Viewer.
> 
> 
> Summary
> ---
> 
> Posting Merov's fix to demonstrate the might of parent-diff. :-P
> 
> See jira for details. This review includes changesets c4d0796548e2 and 
> 5bd988b91f20.
> 
> 
> This addresses bug STORM-1121.
> http://jira.secondlife.com/browse/STORM-1121
> 
> 
> Diffs
> -
> 
>   indra/integration_tests/CMakeLists.txt 3f0988f415e7 
>   indra/integration_tests/llimage_libtest/CMakeLists.txt PRE-CREATION 
> 
> Diff: http://codereview.secondlife.com/r/247/diff
> 
> 
> Testing
> ---
> 
> Merov said ( 
> https://jira.secondlife.com/browse/STORM-1121?focusedCommentId=252239&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-252239
>  ):
> > I was able to get the Linux build to go through though I did not check the 
> > resulting llimage_libtest executable.
> 
> I (Boroondas) didn't to any testing at all.
> 
> 
> 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] C++ Need help to resolve stdint.h typedef conflicts between Quicktime and VS2010

2011-04-05 Thread Nicky Perian
If you are going to stick with vs2010 and not look back the easy solution is 
uninstall the Quicktime SDK and let autobuild deliver the the required items to 
build in package. If you still need to build 1.x or 2.x with develop.py there a 
some include guards that can be used for autobuild and then rename to original 
headers to for develop.py builds.






From: Kiptic ‌ 
To: opensource-dev@lists.secondlife.com
Sent: Tue, April 5, 2011 4:12:00 PM
Subject: Re: [opensource-dev] C++ Need help to resolve stdint.h typedef 
conflicts between Quicktime and VS2010

 >  media_plugin_quicktime.cpp
> C:\Program Files (x86)\QuickTime SDK\CIncludes\GNUCompatibility/stdint.h(49): 
> error C2371: 'int_fast16_t' : redefinition; different basic types
>   C:\Program Files (x86)\Microsoft Visual Studio 
> 10.0\VC\include\stdint.h(34) : see declaration of 'int_fast16_t'

> there are more errors like these but the same header just different int's

> I have tried #include  and #undef and that doesn't help.

Oh, interesting, I just had the same problem after switching to VS2010. Thought 
I'd share my solution :)

It turns out the geniuses at Microsoft had decided not to include stdint.h in 
their include directory (which is required by the C99 standard, that Microsoft 
apparently ignores).

This got the Apple people worried, so they added their own stdint.h to the 
QuickTime SDK. Nice, except that now for some unknown reason Microsoft decided 
it was time to add stdint.h to VS2010! Obviously with completely different 
definitions :)

Also, they failed defining the standard _STDINT_H that would tell other headers 
it exists, instead they define _STDINT only. Brilliant.

So, I had to do this:

1. In C:\Program Files (x86)\QuickTime SDK\CIncludes\CoreFoundation, comment 
out 
this on line 36:
#include 

2. In C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\stdint.h 
(keep a copy of the original if you like!), change line 4 from this:
#define _STDINT

...to this:
#define _STDINT
#define _STDINT_H

Voilà it now compiles properly, and so should everything else that uses 
stdint.h!

/Kip___
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] C++ Need help to resolve stdint.h typedef conflicts between Quicktime and VS2010

2011-04-05 Thread Kiptic ‌

Uninstall the SDK, well that's clever, didn't even think of that :) Thanks.

/Kip
  
  ___
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: fix for STORM-973: [crashhunters] crash at LLViewerTextureList::removeImageFromList(LLViewerFetchedTexture *)7

2011-04-05 Thread Xiaohong Bao

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

Review request for Viewer.


Summary
---

this is to resubmit the patch for storm-973.


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


Diffs
-

  indra/newview/lldrawpoolbump.cpp 13670741a0a8 
  indra/newview/llviewertexturelist.h 13670741a0a8 
  indra/newview/llviewertexturelist.cpp 13670741a0a8 

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


Testing
---


Thanks,

Xiaohong

___
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: Change to description for ShowNetStatus in debbug settings.

2011-04-05 Thread Boroondas Gupte

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



indra/newview/app_settings/settings.xml


"Viewer Usage"?

I think the indicators show packet loss and used network bandwidth.


- Boroondas


On April 5, 2011, 9:31 a.m., Wolfpup Lowenhar wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/251/
> ---
> 
> (Updated April 5, 2011, 9:31 a.m.)
> 
> 
> Review request for Viewer.
> 
> 
> Summary
> ---
> 
> This is a change in the description for the ShowNetStatus debug setting.
> 
> 
> This addresses bug STORM-1098.
> http://jira.secondlife.com/browse/STORM-1098
> 
> 
> Diffs
> -
> 
>   indra/newview/app_settings/settings.xml 3fc9a496265c 
> 
> Diff: http://codereview.secondlife.com/r/251/diff
> 
> 
> Testing
> ---
> 
> None needed as this is only a textual change.
> 
> 
> 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: Change to description for ShowNetStatus in debbug settings.

2011-04-05 Thread Wolfpup Lowenhar


> On April 5, 2011, 2:55 p.m., Boroondas Gupte wrote:
> > indra/newview/app_settings/settings.xml, line 9560
> > 
> >
> > "Viewer Usage"?
> > 
> > I think the indicators show packet loss and used network bandwidth.

The way the indicators are hard coded there one that indicated the Viewer as a 
percent of the time dilation between it and the region your in and the second 
one is the Network Usage(AKA bandwidth being used more usage being bad) thus 
they even change color to yellow and even red meaning worsening conditions.


- Wolfpup


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


On April 5, 2011, 9:31 a.m., Wolfpup Lowenhar wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/251/
> ---
> 
> (Updated April 5, 2011, 9:31 a.m.)
> 
> 
> Review request for Viewer.
> 
> 
> Summary
> ---
> 
> This is a change in the description for the ShowNetStatus debug setting.
> 
> 
> This addresses bug STORM-1098.
> http://jira.secondlife.com/browse/STORM-1098
> 
> 
> Diffs
> -
> 
>   indra/newview/app_settings/settings.xml 3fc9a496265c 
> 
> Diff: http://codereview.secondlife.com/r/251/diff
> 
> 
> Testing
> ---
> 
> None needed as this is only a textual change.
> 
> 
> 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] autobuild & VS 2010 support merged to viewer-development

2011-04-05 Thread Mike Chase
Ok, so One thing I'm seeing frequently with this new build is I'm either
partialy ruth'd or the wrong sex. Mostlyu loos liek shape issues but in
coms cases others will see me with 2 skins, A noob skin and my own. Like
they're both being worn. Its occured fairly frequently. A teleport
sometimes clears it up.


IDK if thats related to the wearables stuff at all...

Mike


On Mon, 2011-04-04 at 20:36 -0700, Trilo Byte wrote: 
> Last build with working multi-wearables (on Mac client, anyways) was
> 225589.  I've created a JIRA issue for the bug
> - https://jira.secondlife.com/browse/VWR-25421
> 
> 
> If any Windows/Linux users could please check this out and see if they
> can reproduce, I'd appreciate it.
> 
> 
> TriloByte Zanzibar
> 
> On Apr 4, 2011, at 7:47 PM, Trilo Byte wrote:
> 
> > Found something that appears to have broken in 225670 -
> > multi-wearables.
> > 
> > Adding multiple attachments still works as expected, right click on
> > an attachment in your inventory or the My Appearance tab and choose
> > Add to add it to your currently worn outfit.  However, multiple
> > layers is broken - the Add button is ghosted when selecting
> > additional clothing layers in your SL inventory.  It does work as
> > expected if selecting an additional clothing layer item from one of
> > your established outfit folders in the My Appearance tab.
> > 
> > I'll start winding back through the builds to try and identify the
> > version this was broken in, this is a major regression to the
> > fashion set and hopefully this can be fixed before 2.6.3 goes to
> > beta.
> > 
> > On Apr 1, 2011, at 3:08 PM, Oz Linden (Scott Lawrence) wrote:
> > 
> > > The autobuild and Visual Studio 2010 branch has been merged to 
> > > viewer-development
> > > 
> > > develop.py is dead, long live autobuild
> > > 
> > > We did not get the OPEN-50 changes in before this merge, but it
> > > will be 
> > > very high priority for early next week.
> > > 
> > > ___
> > > 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] UI produces just grey boxes

2011-04-05 Thread Glimmering Sands
Thank you, I will try from a freshly made account.  The hint that it
is possibly the artwork bundle will hopefully help much.

Hugs,

Glimmering

On Tue, Apr 5, 2011 at 6:34 AM, Boroondas Gupte
 wrote:
> On 04/05/2011 07:46 AM, Glimmering Sands wrote:
>
> Please see the attached screen shots to
> understand what I mean.
>
> These look like your build is failing to load the images included in the
> viewer's Artwork from disk. I guess images received from the network or
> retrieved from the cache work (There's an IM session icon visible in the
> second screenshot.), so it's probably not an issue with decoding images in
> general.
>
> As the artwork is now included in the source repository, it can't be that
> you forgot to unpack it. (That was a common cause of this symptom with 1.x
> Viewers.) So probably it's either a image file type specific problem (I
> think most of the viewer artwork is PNG while textures received from the
> asset system are JPEG2000) or your build is for some reason looking for the
> artwork at the wrong place.
>
> Things you can try to narrow down the cause:
>
> Try another build (e.g. official download) on your machine and see whether
> it suffers from the same problem.
> Create a new operating system user account on your system and try your build
> with that.
> Create a new SL user account and try your build with that.
> Try your build on another computer.
>
> Lastly, see whether the build instructions have been updated since you last
> read them. Maybe something needs to be done differently than before to get a
> fully working build.
>
> Cheers & good luck,
> 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


[opensource-dev] s3-proxy.lindenlab.com points to a private IP address?

2011-04-05 Thread Glimmering Sands
Sorry to bother you kind folks again.  I am attempting to follow the
suggestion of building from scratch from a new account.  Given that
the instructions for how to install fmod are now missing from the wiki
I decided I should just follow the autobuild instructions.  Maybe they
will work better?  But alas, fate would have it that this has a
failure for me as well:


downloading fmod archive from
http://s3-proxy.lindenlab.com/private-builds-secondlife-com/hg/repo/3p-fmod-private/rev/221852/arch/Darwin/installer/fmod-3.75-darwin-20110222.tar.bz2
unable to download file: 

So why does this download timeout?

$ nslookup s3-proxy.lindenlab.com
Non-authoritative answer:
s3-proxy.lindenlab.com  canonical name = int.excod.lindenlab.com.
Name:   int.excod.lindenlab.com
Address: 10.6.3.104

No, even in the fantastical world I might live in, I am quite certain
I am not able to reach linden lab's private servers, nor do I think
setting up my own 10.6/16 network would be of any assistance.  Perhaps
this is an error by the DNS administrators at Linden Labs?

Kind Regards,

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