[opensource-dev] Review Request: STORM-1121: make llimage_libtest build on Linux

[Boroondas Gupte]

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

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] Group Notices not getting delivered

[Ardy Lay]

On 3/31/2011 5:19 AM, Jonathan Welch wrote:
> Just guessing here -- is there any chance you have something on your
> mute list that might be affecting these  notices?  Is it just for 1
> group or a number of them?
It's not in the block list, that we can see.  Many members, perhaps all, 
in a group are affected.  I can't say for sure all are because some 
members are unaccounted for.  Sad fact of Second Life.
___
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: Enable CURLOPT_ENCODING for Inventory caps, which uses the LLURLRequest code path

[Oz Linden]

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

(Updated March 31, 2011, 7:32 a.m.)


Review request for Viewer, Oz Linden, Joshua Linden, and Brad Kittenbrink.


Changes
---

adding the issue reference in the Bugs field


Summary
---

Enable Accept-Encoding: deflate, gzip in libcurl via setopt CURLOPT_ENCODING. 
I'm approaching this for Inventory, but it would apply to any HTTP request that 
goes through the LLURLRequest code path (vs. the LLCurl code path, which 
already does this).


This addresses bug vwr-25376.
http://jira.secondlife.com/browse/vwr-25376


Diffs
-

  indra/llmessage/llurlrequest.cpp 2ae060c0fa91 

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


Testing
---

Inventory loads, and I see the encoding options coming through on the backend 
apache logs.


Thanks,

Stone

___
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] Snowstorm PO review build

[Oz Linden (Scott Lawrence)]

http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repo/oz_viewer-poreview/rev/225458/index.html

Here are the issues addressed in that build:

STORM-399  Users that has 
chatted within chat range of the user in-world are not added to Recent tab
STORM-1072  [TRANSLATED 
BUT IN EN] in "Monde" > "Profil du lieu" > "À propos des terrains" > 
"Réglement" : "Estate / Full Region" is in english.
STORM-1094  Chat 
preferences > font size should increase size of input text in IM window
STORM-1095  Chat 
preferences > font size should increase size of input text in the chat box
STORM-1108  Enable Hints 
menu entry/preference is confusing
VWR-25269  [#STORM-1106] 
"Set scripts to running" on an object containing no scripts produces a 
"unknown notification" error


___
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-380) There is a little delay in sound when gesture first time played

[Seth ProductEngine]

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

(Updated March 31, 2011, 10:18 a.m.)


Review request for Viewer.


Changes
---

- Fixed checking the pending downloads for each playing gesture separately.
- Fixed calling assets callback to clean up the void pointer in getAssetData() 
and avoid potential memory leaks.


Summary (updated)
---

Added syncing animations and sounds before the gesture starts playing.
The actual playing of animations and sounds of a gesture starts only when all 
needed animations and sound files are loaded into viewer cache. This reduces 
the delay between animations and sounds meant to be played simultaneously but 
may increase the delay between the moment a gesture is triggered and the moment 
it starts playing.

Fixed calling assets callback to clean up the void pointer in getAssetData() 
and avoid potential memory leaks.


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


Diffs (updated)
-

  indra/llmessage/llassetstorage.cpp d30636c2a83a 
  indra/newview/llgesturemgr.h d30636c2a83a 
  indra/newview/llgesturemgr.cpp d30636c2a83a 

Diff: http://codereview.secondlife.com/r/231/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] Group Notices not getting delivered

[Stickman]

I've heard through the grapevine that only 400 random people in a group
larger than that get a group notice. But I have no information from an
authoritive source.

I've suffered and seen many sufferers of non-received group notices. So much
so that people who need their messages received don't even use group
notices.

Longstanding problem. No hope in sight. The bells. The bells!

Stickman

On Mar 31, 2011 4:02 AM, "Ardy Lay"  wrote:

On 3/31/2011 5:19 AM, Jonathan Welch wrote:
> Just guessing here -- is there any chance you have something on your
> mute list that might be affecting these  notices?  Is it just for 1
> group or a number of them?
It's not in the block list, that we can see.  Many members, perhaps all,
in a group are affected.  I can't say for sure all are because some
members are unaccounted for.  Sad fact of Second Life.

___
Policies and (un)subscribe information available her...
___
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] Group Notices not getting delivered

[Da5id Kronfeld]

On 2011-03-31, at 11:14 AM, Stickman wrote:

> I've heard through the grapevine that only 400 random people in a group 
> larger than that get a group notice. But I have no information from an 
> authoritive source.
> 
> I've suffered and seen many sufferers of non-received group notices. So much 
> so that people who need their messages received don't even use group notices.
> 
> Longstanding problem. No hope in sight. The bells. The bells!
> 
> Stickman
> 
> 

I have alts who are members of the same large groups and I see this all the 
time. Sometimes both, sometimes neither, and often just one account gets the 
notice.

___
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] Group Notices not getting delivered

[Tateru Nino]

On 1/04/2011 5:18 AM, Da5id Kronfeld wrote:
>
> On 2011-03-31, at 11:14 AM, Stickman wrote:
>
>> I've heard through the grapevine that only 400 random people in a
>> group larger than that get a group notice. But I have no information
>> from an authoritive source.
>>
>> I've suffered and seen many sufferers of non-received group notices.
>> So much so that people who need their messages received don't even
>> use group notices.
>>
>> Longstanding problem. No hope in sight. The bells. The bells!
>>
>> Stickman
>>
>>
>
> I have alts who are members of the same large groups and I see this
> all the time. Sometimes both, sometimes neither, and often just one
> account gets the notice.
>
Group notices become unreliable for large groups. I believe there are
ancient JIRAs about that. The issue dates back quite a ways. I'm not
aware of any *new* decline in group notice reliability at present, though.

-- 
Tateru Nino
http://dwellonit.taterunino.net/

___
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-954 corrected patch

[Merov Linden]

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


+1 on this patch modulo the code convention fix I mention here under.


indra/newview/llworld.cpp


Code convention: could you add "{}" around the statements following these 
"if"s?



indra/newview/llworld.cpp


Funny that you added them here :)


- Merov


On March 9, 2011, 3:33 p.m., Twisted Laws wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/194/
> ---
> 
> (Updated March 9, 2011, 3:33 p.m.)
> 
> 
> Review request for Viewer.
> 
> 
> Summary
> ---
> 
> STORM-954 review had 2 patches, the second of which was approved in review 
> process but the first patch is what went into viewer-development.  This is 
> that second patch again. This patch modifies getAvatars() in llworld.cpp.  
> Note this patch becomes more important if/when avatar distances may be 
> displayed to users in the viewer as it corrects for map data being incorrect 
> above 1024m by using the viewer characters list to get avatar position if 
> known and then falling back on the map data for the avatars that are beyond 
> view range.  This patch is in the repository 
> https://bitbucket.org/Twisted_Laws/viewer-development-storm-954
> 
> 
> This addresses bug storm-954.
> http://jira.secondlife.com/browse/storm-954
> 
> 
> Diffs
> -
> 
>   indra/newview/llworld.cpp aed94e854443 
> 
> Diff: http://codereview.secondlife.com/r/194/diff
> 
> 
> Testing
> ---
> 
> Proper testing with and without this patch is to have 2 or more avatars at 
> 1050 height with other avatars on the ground under you, and the NearmeRange 
> (debug setting) set to 4096 and the sort order in the Nearby avatars panel 
> set to sort by distance. (A busy region like a sandbox, is a good place to 
> test.) Without this patch, a nearby avatar will not necessarily be displayed 
> before avatars that are further away.  With this patch, the avatar standing 
> closest to you should show up as the first in the list.   
> 
> 
> Thanks,
> 
> Twisted
> 
>

___
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-954 corrected patch

[Twisted Laws]

> On March 31, 2011, 12:24 p.m., Merov Linden wrote:
> > +1 on this patch modulo the code convention fix I mention here under.

Corrected and updated in 
https://bitbucket.org/Twisted_Laws/viewer-development-storm-954/changeset/7bcb336642f4
 (the braces changes only)


- Twisted


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


On March 9, 2011, 3:33 p.m., Twisted Laws wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/194/
> ---
> 
> (Updated March 9, 2011, 3:33 p.m.)
> 
> 
> Review request for Viewer.
> 
> 
> Summary
> ---
> 
> STORM-954 review had 2 patches, the second of which was approved in review 
> process but the first patch is what went into viewer-development.  This is 
> that second patch again. This patch modifies getAvatars() in llworld.cpp.  
> Note this patch becomes more important if/when avatar distances may be 
> displayed to users in the viewer as it corrects for map data being incorrect 
> above 1024m by using the viewer characters list to get avatar position if 
> known and then falling back on the map data for the avatars that are beyond 
> view range.  This patch is in the repository 
> https://bitbucket.org/Twisted_Laws/viewer-development-storm-954
> 
> 
> This addresses bug storm-954.
> http://jira.secondlife.com/browse/storm-954
> 
> 
> Diffs
> -
> 
>   indra/newview/llworld.cpp aed94e854443 
> 
> Diff: http://codereview.secondlife.com/r/194/diff
> 
> 
> Testing
> ---
> 
> Proper testing with and without this patch is to have 2 or more avatars at 
> 1050 height with other avatars on the ground under you, and the NearmeRange 
> (debug setting) set to 4096 and the sort order in the Nearby avatars panel 
> set to sort by distance. (A busy region like a sandbox, is a good place to 
> test.) Without this patch, a nearby avatar will not necessarily be displayed 
> before avatars that are further away.  With this patch, the avatar standing 
> closest to you should show up as the first in the list.   
> 
> 
> Thanks,
> 
> Twisted
> 
>

___
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-954 corrected patch

[Merov Linden]

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

Ship it!


Thanks Twisted for taking my comment into account in 
https://bitbucket.org/Twisted_Laws/viewer-development-storm-954/changeset/7bcb336642f4

This is ready to be pull in as far as I'm concerned.

- Merov


On March 9, 2011, 3:33 p.m., Twisted Laws wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/194/
> ---
> 
> (Updated March 9, 2011, 3:33 p.m.)
> 
> 
> Review request for Viewer.
> 
> 
> Summary
> ---
> 
> STORM-954 review had 2 patches, the second of which was approved in review 
> process but the first patch is what went into viewer-development.  This is 
> that second patch again. This patch modifies getAvatars() in llworld.cpp.  
> Note this patch becomes more important if/when avatar distances may be 
> displayed to users in the viewer as it corrects for map data being incorrect 
> above 1024m by using the viewer characters list to get avatar position if 
> known and then falling back on the map data for the avatars that are beyond 
> view range.  This patch is in the repository 
> https://bitbucket.org/Twisted_Laws/viewer-development-storm-954
> 
> 
> This addresses bug storm-954.
> http://jira.secondlife.com/browse/storm-954
> 
> 
> Diffs
> -
> 
>   indra/newview/llworld.cpp aed94e854443 
> 
> Diff: http://codereview.secondlife.com/r/194/diff
> 
> 
> Testing
> ---
> 
> Proper testing with and without this patch is to have 2 or more avatars at 
> 1050 height with other avatars on the ground under you, and the NearmeRange 
> (debug setting) set to 4096 and the sort order in the Nearby avatars panel 
> set to sort by distance. (A busy region like a sandbox, is a good place to 
> test.) Without this patch, a nearby avatar will not necessarily be displayed 
> before avatars that are further away.  With this patch, the avatar standing 
> closest to you should show up as the first in the list.   
> 
> 
> Thanks,
> 
> Twisted
> 
>

___
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 setting UNATTENDED questions

[Brad Kittenbrink (Brad Linden)]

Sorry I let this sit for a while without replying, here are my thoughts:

On Sat, Mar 26, 2011 at 7:18 AM, Ima Mechanique <
ima.mechani...@blueyonder.co.uk> wrote:

> Thanks for replying Brad
>
> > The working directory setting may no longer be necessary after this
> > change<
> https://bitbucket.org/merov_linden/viewer-autobuild2010/changeset/339c25d7046e
> >.
> > If so, that's good news.  However, I believe that we also use it for
> setting
> > the default configuration to RelWithDebInfo, which we still require.
>
> Could you expand on this? I'm assuming the "it" is vstool or UNATTENDED,
> but the only other references to either I can find in the source tree
> are part of the autobuild.xml configuration for Debug, RelWithDebInfo,
> and Release (which do seem to be setting configuration type for startup).
> If that is what you're referring to, then the CMakeLists.txt part could
> be safely removed and OS devs could remain happily oblivious to its use?
>

By 'it', I was referring to vstool.  The UNATTENDED variable is required to
support the enabling and disabling of that vstoool block of CMake code in
indra/newview/CMakeLists.txt.  We do not intend to delete that block of
code, as I said, that functionality is still required.  Frankly, VCExpress
devs need to support their own tools properly here, so they cannot be
oblivious to this until we get patches that solve these issues.  For now
this information has to be specified manually and the UNATTENDED variable is
as fine an interface as any for that now.  If someone discovered a builtin
CMake variable for automatically detecting whether the visual studio
installation is Express or Professional, then we should use that instead of
manually specifying this with UNATTENDED, but I'm not aware of one.


> > 2) If it really is necessary, could we change the program run (vstools)
> > > to something more compatible with all VC versions. Now the project
> files
> > > are XML based, it should be possible to do this as part of autobuild
> > > itself.
> > >
> > >
> > The source for vstool is
> > here<
> https://bitbucket.org/merov_linden/viewer-autobuild2010/src/tip/indra/tools/vstool/main.cs
> >.
> > (Yes, it's C#, don't ask me...)  If there's a way to make it compatible
> with
> > VCExpress I'd love to do so, but to my knowledge VCExpress doesn't expose
> > the macro apis that this relies upon, so it's likely impossible to
> directly
> > extend that script to this case.  I don't think it makes sense to build
> > support for tweaking these xml files into autobuild, as autobuild is
> > intended to be as fully decoupled from the details of individual build
> > systems as possible.
>
> Agreed about autobuild, I was thinking something like a python script
> that autobuild/cmake could use instead of vstool. However, it seems
> this is unnecessary now.
>

I strongly doubt that such a python script would be a better solution than
vstool.   We've got code that works for all VCPro developers that require
this functionality, and we have a good way to disable this functionality for
VCExpress developers who don't require it.  I don't think it's a good use of
our time to do anything more than that.


> > An alternative is getting this kind of feature built into cmake.  For
> > example, this issue  is
> a
> > feature request for making another kind of modification to the
> > *.vcproj.*.user configuration file where these settings are saved.
> >
> > In the mean time, I would definitely recommend updating the VCExpress
> > configurations to pass -DUNATTENDED:BOOL=ON on the command line until we
> > find a better solution for this.
>
> Already done and in my repo, although it's not a "VC Express"
> configuration it's for any OS VC 2010
>

Cool, sounds good.


>  > We used to do a lot more with the
> > --unattended argument to develop.py, but I think this is all that remains
> of
> > that cruft, so it's safe to use for this purpose.
>
> So if the autobuild.xml is what you were referring to above,  could we
> safely
> remove all references to UNATTENDED (TC and OS), and remove lines 1581 -
> 1594 from indra/newview/CMakeLists.txt?
>

No.
The UNATTENDED variable is the preffered way to configure whether vstool is
used or not.  Those lines are still required.  Again, I'd prefer cmake
included some automatic variable for detecting this, but what we have works.

-Brad
___
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: Enable CURLOPT_ENCODING for Inventory caps, which uses the LLURLRequest code path

[Joshua Linden]

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

Ship it!


Looks good. 

Empty-string ("") is a signal to curl to send an Accept-Encoding header with 
any type it understands and can transparently decode on receipt. On the one 
hand, it might be nice to define a constant empty string so that this behavior 
is more obvious, but on the other using literal empty strings will match what 
people might search for.

- Joshua


On March 31, 2011, 7:32 a.m., Stone Linden wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/242/
> ---
> 
> (Updated March 31, 2011, 7:32 a.m.)
> 
> 
> Review request for Viewer, Oz Linden, Joshua Linden, and Brad Kittenbrink.
> 
> 
> Summary
> ---
> 
> Enable Accept-Encoding: deflate, gzip in libcurl via setopt CURLOPT_ENCODING. 
> I'm approaching this for Inventory, but it would apply to any HTTP request 
> that goes through the LLURLRequest code path (vs. the LLCurl code path, which 
> already does this).
> 
> 
> This addresses bug vwr-25376.
> http://jira.secondlife.com/browse/vwr-25376
> 
> 
> Diffs
> -
> 
>   indra/llmessage/llurlrequest.cpp 2ae060c0fa91 
> 
> Diff: http://codereview.secondlife.com/r/242/diff
> 
> 
> Testing
> ---
> 
> Inventory loads, and I see the encoding options coming through on the backend 
> apache logs.
> 
> 
> Thanks,
> 
> Stone
> 
>

___
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] Press release that affects us all!

[Brandon Husbands]

DCS has just finished Acquiring Linden labs.
The Linden Lab staff will be laid off and replaced with my own Staff from
Xotmid Solutions.

We will also be making some major changes to Second Life to improve the
MMORPG aspects of it.

For more information please visit http://dcsengine.com

-- 
---
This email is a private and confidential communication. Any use of email may
be subject to the laws and regulations of the United States. You may not
Repost, Distribute nor reproduce any content of this message.
---
---
___
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] Press release that affects us all!

[aklo]

Like, i thought we'd know if LL was being bought or for sale or anything,
but still - Not Funny.  i mean, maybe i just don't have a sense of humor
or something.  But y'know, Not Funny.

- AK
-
DCS has just finished Acquiring Linden labs.
The Linden Lab staff will be laid off and replaced with my own Staff from
Xotmid Solutions.

We will also be making some major changes to Second Life to improve the
MMORPG aspects of it.

For more information please visit http://dcsengine.com

-- 
---
This email is a private and confidential communication. Any use of email
may be subject to the laws and regulations of the United States. You may
not Repost, Distribute nor reproduce any content of this message.
---
---



___
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] Press release that affects us all!

[Brandon Husbands]

Its my april fools joke... =)
as it says in a nice big h1 tag on the site april fools.

On Fri, Apr 1, 2011 at 1:13 AM,  wrote:

> Like, i thought we'd know if LL was being bought or for sale or anything,
> but still - Not Funny.  i mean, maybe i just don't have a sense of humor
> or something.  But y'know, Not Funny.
>
> - AK
>
> -
> DCS has just finished Acquiring Linden labs.
> The Linden Lab staff will be laid off and replaced with my own Staff from
> Xotmid Solutions.
>
> We will also be making some major changes to Second Life to improve the
> MMORPG aspects of it.
>
> For more information please visit http://dcsengine.com
>
> --
>
> ---
> This email is a private and confidential communication. Any use of email
> may be subject to the laws and regulations of the United States. You may
> not Repost, Distribute nor reproduce any content of this message.
>
> ---
>
> ---
>
>
>
> ___
> 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
>
>


-- 
---
This email is a private and confidential communication. Any use of email may
be subject to the laws and regulations of the United States. You may not
Repost, Distribute nor reproduce any content of this message.
---
---
___
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