Re: [opensource-dev] before opena Jira, APR

[Tofu Linden]

Altair Sythos Memo wrote:
...
> 2010-08-31T21:02:02Z WARNING: ll_apr_warn_status: APR: Too many open
> files 
> 
> 2010-08-31T21:02:02Z WARNING: open:  Attempting to open
> filename: /home/user/.secondlife/cache/texturecache/texture.entries
...
> not so sure anyway is a viewer problem of something specific to my
> linuxbox... is why i'm asking here if somebody else match this kind of
> crash with latest build

This is a genuine problem.  Please file it in jira.  Any eyes on this
would be welcome.
It seems to have popped up recently - it may be related to the latest
HTTP textures changes, not sure (perhaps leaking file handles, though
lsof says we're still somewhat under the default limits).
___
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] Removal of the "MultipleAttachments" debug settings ?

[Argent Stonecutter]

On 2010-08-31, at 22:40, Glen Canaday wrote:
> Gamers like it broken like it is now, people who SOCIALIZE here (since
> SL is, in fact, *not* a game... ahem) like it broken the way it's
> historically been.

It wasn't broken historically: it was a prefs setting.

Also, gamers don't like it the way it is, seems like they want to completely 
lose the chat bar on hitting enter:

http://jira.secondlife.com/browse/VWR-18323

The current behavior doesn't work well for either camp.
___
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] before opena Jira, APR

[Tateru Nino]

  On 1/09/2010 8:28 PM, Tofu Linden wrote:
> Altair Sythos Memo wrote:
> ...
>> 2010-08-31T21:02:02Z WARNING: ll_apr_warn_status: APR: Too many open
>> files
>>
>> 2010-08-31T21:02:02Z WARNING: open:  Attempting to open
>> filename: /home/user/.secondlife/cache/texturecache/texture.entries
> ...
>> not so sure anyway is a viewer problem of something specific to my
>> linuxbox... is why i'm asking here if somebody else match this kind of
>> crash with latest build
> This is a genuine problem.  Please file it in jira.  Any eyes on this
> would be welcome.
> It seems to have popped up recently - it may be related to the latest
> HTTP textures changes, not sure (perhaps leaking file handles, though
> lsof says we're still somewhat under the default limits).
>
Hmm. It might not be an actual leak per-se... I've noticed in busy areas 
that the viewer will often hit a *lot* of parallel HTTP texture fetches. 
I'm not sure if there's a hard limit there, because my texture console 
can easily overflow with active texture-fetches. That's... what... 30+ 
and I'm guessing a minimum of two file-handles each right there (and gut 
feeling says there's probably closer to 3 involved).

If there's no cap on the number of parallel HTTP texture fetches (or the 
cap is too large), then you'll see more simultaneous fetches for 
higher-latency users (as an artifact of each HTTP session taking longer 
to complete), all other things being equal. If that is the case, then 
it's likely to have a far lower incidence if you're on the continental 
USA. Altair... you're in southern Europe, right?

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

[opensource-dev] Jira issues with fixes in boroondas/snowstorm-development (was: Product Backlog addition request: Build fixes for 64bit out-of-source)

[Boroondas Gupte]

 On 08/31/2010 08:55 PM, Boroondas Gupte wrote:
> On 08/28/2010 11:48 AM, Boroondas Gupte wrote:
>> I'll follow up with a new clone at the original location of my
>> repository soon and will hopefully get the merges right this time.
> http://bitbucket.org/boroondas/snowstorm-development/changeset/855c7fac6fc2
> (and ancestors)
Make that
http://bitbucket.org/boroondas/snowstorm-development/changeset/5bac0fd6a9aa

So here's the list of ported/implemented JIRA issues:

* everything from bitbucket.org/Techwolf/viewer-development up to
  the current tip (ed2130db2b59
  
)
  o For details, please refer to Techwolf's list post

.
* *VWR-20891  missing
  LL_TEST conditions in indra/viewer_components/login/CMakeLists.txt*
  o This wasn't an issue in Snowglobe (or I didn't notice it
there, because tests worked) so the fix isn't a port of any
existing patch or SVN changeset.
  o Fixed at 6ea6df364e22.


* *SNOW-737  Version
  agnostic libPNG linking*
  o If you ever had issues building SL against a libpng version
that wasn't 1.2, try this fix
  o Shouldn't break anything for libpng 1.2
  o Patch ported at bda128f41f35.


* *VWR-20911  CMake
  build arch detection is inaccurate and incomplete*
  o Get 32/64bit-ness from the compiler rather than from the kernel
  o I don't need this one to be able to build, but Robin said
the SNOW-512 
fix (pulled from Techwolf) would be incomplete without this,
so I included it.
  o Patch ported at a9132a63e473.


  o Fixed indentation at d02b22278d5b

.
* *SNOW-748  Building on
  OSX 10.6 fails with "warning: -mdynamic-no-pic overrides - fpic or
  -fPIC"*
  o Mac build warning (fatal due to |-Werror|) introduces by the
SNOW-512  fix
(pulled from Techwolf)
+ I don't have a Mac, so those who have please test this!
  o Functional changes from the SVN changesets ported at
483666cc9dee

.
  o Different whitespace cleanup needed than the original
changesets did. Implemented at d63b1eeffb77

.
* *SNOW-650  Tries to
  build pulseaudio when pulseaudio not found.*
  o Patch applied at 3568a637ad92

.
  o Manual merge at 0c18347b0769

.
  o Fuzz 3 lead to wrong contributions.txt entry (oops), fixed
at 11030238f334

.
* *SNOW-592  FIXED
  gstreamer 0.10.28 standalone build failure*
  o This fix is needed when building against newer GStreamer
versions
  o Ported at 16370ddd51a8

,
some source formatting changes at 5b850e440458

.
* *SNOW-764  (problem 1)
  Bugs showing when compiling with optimization*
  o I needed this patch to fix *SNOW-522
** crash due to
looking for skins/paths.xml at the wrong path*.
+ Not a build issue per-se, but I'd like to also use my
  build
  o Ported at 8afc8382dd9b

.

I also left notes at the jira issues themselves. I hope I didn't miss any.

Cheers,
Boroondas
___
Policies and (un)subscribe information available here:
http://wiki

[opensource-dev] Testing for VWR-20741 and sub task VWR-20933

[WolfPup Lowenhar]

I requesting of my fellow open source community members assistance in
testing the following:

http://jira.secondlife.com/browse/VWR-20741

and sub-task:

http://jira.secondlife.com/browse/VWR-20933



The change set for testing is here:

http://bitbucket.org/WolfpupL/viewer-development/changeset/36caec874c28




___
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] before opena Jira, APR

[Francesco Rabbi]

Il giorno 01/set/2010, alle ore 13:12, Tateru Nino
 ha scritto:

>  On 1/09/2010 8:28 PM, Tofu Linden wrote:
>> Altair Sythos Memo wrote:
>> ...
>>> 2010-08-31T21:02:02Z WARNING: ll_apr_warn_status: APR: Too many open
>>> files
>>>
>>> 2010-08-31T21:02:02Z WARNING: open:  Attempting to open
>>> filename: /home/user/.secondlife/cache/texturecache/texture.entries
>> ...
>>> not so sure anyway is a viewer problem of something specific to my
>>> linuxbox... is why i'm asking here if somebody else match this kind of
>>> crash with latest build
>> This is a genuine problem.  Please file it in jira.  Any eyes on this
>> would be welcome.
>> It seems to have popped up recently - it may be related to the latest
>> HTTP textures changes, not sure (perhaps leaking file handles, though
>> lsof says we're still somewhat under the default limits).
>>
> Hmm. It might not be an actual leak per-se... I've noticed in busy areas
> that the viewer will often hit a *lot* of parallel HTTP texture fetches.
> I'm not sure if there's a hard limit there, because my texture console
> can easily overflow with active texture-fetches. That's... what... 30+
> and I'm guessing a minimum of two file-handles each right there (and gut
> feeling says there's probably closer to 3 involved).
>
> If there's no cap on the number of parallel HTTP texture fetches (or the
> cap is too large), then you'll see more simultaneous fetches for
> higher-latency users (as an artifact of each HTTP session taking longer
> to complete), all other things being equal. If that is the case, then
> it's likely to have a far lower incidence if you're on the continental
> USA. Altair... you're in southern Europe, right?

Yes, and my box have default 1024 opened file limit, yesterday before
sleep i've setup for 4096 and for 2h nothing happened

Maybe HTTP should be throttled or childs must be reused more times, my
doubt is why i have 20Mbps DSL but i live South europe download time
is longer, and lock file start since download start to decode
complete.

This evening i open jira with full limits and enviroment specification
of my box and put in cron a check each minute using lsof to monitor
and stats opened file by viewer


-- 
Sent by iPhone
___
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] Testing for VWR-20741 and sub task VWR-20933

[Aleric Inglewood]

Hi,

I didn't actually test it, but looked at the changeset in a review-kind-of-way,
and have the following concerns:

1) It has been agreed in the past, imho, that this would be turned off
by default;
the current patch turns it on.
2) If there has communication with people with this turned off, and then
the option is turned on; then the last part of the communication with the
   option turned off is shown till eternity if there wasn't some chat history
   today or yesterday; which is basically the same concern as point 3:
3) If there was communication -say- three days ago (but not today or
yesterday), then that isn't found.

A solution to point 2 and 3 would be to create a symbolic link to the
last log file created and look for that instead of oldLogFileName
The name of this symbolic link may not contain a date of course, and
it may not be equal to ndsLogFileName. Ie, it could have -most_recent
appended.

On Wed, Sep 1, 2010 at 1:44 PM, WolfPup Lowenhar
 wrote:
> I requesting of my fellow open source community members assistance in
> testing the following:
>
> http://jira.secondlife.com/browse/VWR-20741
>
> and sub-task:
>
> http://jira.secondlife.com/browse/VWR-20933
>
>
>
> The change set for testing is here:
>
> http://bitbucket.org/WolfpupL/viewer-development/changeset/36caec874c28
>
>
>
>
> ___
> 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

[opensource-dev] Oz Office Hours canceled today

[Oz Linden (Scott Lawrence)]

I'm not going to be available for my regular office hour on Wednesday 
Sept 1.

Send mail if there was something you needed to discuss, and I'll set up 
a time we can meet.

___
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] before opena Jira, APR

[Oz Linden (Scott Lawrence)]

 On 2010-09-01 7:12, Tateru Nino wrote:

Hmm. It might not be an actual leak per-se... I've noticed in busy areas
that the viewer will often hit a*lot*  of parallel HTTP texture fetches.
That's not very good http behavior, but I doubt that we can get it 
changed until the servers are properly supporting persistent connections.


___
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] before opena Jira, APR

[Tateru Nino]

On 1/09/2010 11:24 PM, Oz Linden (Scott Lawrence) wrote:

On 2010-09-01 7:12, Tateru Nino wrote:

Hmm. It might not be an actual leak per-se... I've noticed in busy areas
that the viewer will often hit a*lot*  of parallel HTTP texture fetches.
That's not very good http behavior, but I doubt that we can get it 
changed until the servers are properly supporting persistent connections.
Indeed. It's not exactly best-practice. Creating a priority list of 
textures and a configurable concurrent requests cap (default: 16?) would 
probably be the way to go.


--
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] before opena Jira, APR

[Francesco Rabbi]

Il giorno 01/set/2010, alle ore 15:36, Tateru Nino 
ha scritto:



On 1/09/2010 11:24 PM, Oz Linden (Scott Lawrence) wrote:

On 2010-09-01 7:12, Tateru Nino wrote:

Hmm. It might not be an actual leak per-se... I've noticed in busy areas
that the viewer will often hit a **lot** of parallel HTTP texture fetches.

 That's not very good http behavior, but I doubt that we can get it changed
until the servers are properly supporting persistent connections.

Indeed. It's not exactly best-practice. Creating a priority list of textures
and a configurable concurrent requests cap (default: 16?) would probably be
the way to go.


No, this is a client side problem in file handling, not an HTTP problem...
You can parallelize billions of download, the fail (you can see in my logs)
is in local filesystem file handling. Maybe there are more locks than
suitable, the file/decoder handler must detect the limits and adapt the
pipes.

As seen in logs i suppose when a cached texture fail (timeout, bad crc for
packet loss) the automatic clean try a clear_while_run wasting all openable
files. If a http timeout or corrupted cached texture found the SINGLE
download or the single fileust be deleted or dropped, not whole cache.

If a running viewer have 600 opened tectures and got a timeout now re-open
all to clean them, exceding the default 1024 limit

I've noticed some grey textures too, i begin to think about the old
(patched) bug about decoding fail without retry, the pipe hold the channell
opened wasting resources




-- 
Sent by iPhone
___
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] before opena Jira, APR

[Oz Linden (Scott Lawrence)]

  On 2010-09-01 9:46, Francesco Rabbi wrote:
>
> No, this is a client side problem in file handling, not an HTTP 
> problem... You can parallelize billions of download,
Whether or not you _can_, you _shouldn't_.  The HTTP spec is quite clear 
on this point.

We'd get much better performance than we're getting now if we fixed the 
servers to support persistent connections; there's a lot of overhead in 
setting up a new connection - extra round trips plus TCP slow-start.

___
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] Second Pair of eyes needed!

[Mike Monkowski]

You're half right :-)
Change the other "LLFILE* fptr =" to "fptr =" as well.

Mike

Tiggs Linden wrote:
> You're shadowing fptr in the last if clause:
>   if (!fptr)
>{
>LLFILE* fptr = LLFile::fopen(oldLogFileName(filename),
> "r");/*Flawfinder: ignore*/
>LL_INFOS("") << "Old:" << file_name << LL_ENDL;
>if (!fptr)
>{
>LLFILE* fptr =
> LLFile::fopen(ndsLogFileName(file_name), "r");  /*Flawfinder:
> ignore*/
>LL_INFOS("") << "Orginal:" << file_name << LL_ENDL;
>if (!fptr) return;  //No previous conversation
> with this name.
>}
>}
> 
> Change that to:
> 
>   if (!fptr)
>{
>   fptr = LLFile::fopen(oldLogFileName(filename),
> "r");/*Flawfinder: ignore*/
>LL_INFOS("") << "Old:" << file_name << LL_ENDL;
>if (!fptr)
>{
>LLFILE* fptr =
> LLFile::fopen(ndsLogFileName(file_name), "r");  /*Flawfinder:
> ignore*/
>LL_INFOS("") << "Orginal:" << file_name << LL_ENDL;
>if (!fptr) return;  //No previous conversation
> with this name.
>}
>}
___
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] before opena Jira, APR

[Tateru Nino]

On 2/09/2010 12:20 AM, Oz Linden (Scott Lawrence) wrote:
>On 2010-09-01 9:46, Francesco Rabbi wrote:
>> No, this is a client side problem in file handling, not an HTTP
>> problem... You can parallelize billions of download,
> Whether or not you _can_, you _shouldn't_.  The HTTP spec is quite clear
> on this point.
RFC2616 makes for great reading, and the *majority* of it is superbly 
thought through. I spent years with a copy close-to-hand at all times.
> We'd get much better performance than we're getting now if we fixed the
> servers to support persistent connections; there's a lot of overhead in
> setting up a new connection - extra round trips plus TCP slow-start.
Concur. However, persistent connections (and possibly pipelining) will 
pretty much mean that you'll need to make sure you're maintaining a 
priority-queue of textures to fetch. Otherwise it will *feel* slower to 
the end-user even if it is actually faster in total fetch-and-render 
time. I've been down this road before.

-- 
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] before opena Jira, APR

[Oz Linden (Scott Lawrence)]

  On 2010-09-01 10:36, Tateru Nino wrote:
>
> On 2/09/2010 12:20 AM, Oz Linden (Scott Lawrence) wrote:
>> On 2010-09-01 9:46, Francesco Rabbi wrote:
>>> No, this is a client side problem in file handling, not an HTTP
>>> problem... You can parallelize billions of download,
>> Whether or not you _can_, you _shouldn't_.  The HTTP spec is quite clear
>> on this point.
> RFC2616 makes for great reading, and the *majority* of it is superbly
> thought through. I spent years with a copy close-to-hand at all times.
>> We'd get much better performance than we're getting now if we fixed the
>> servers to support persistent connections; there's a lot of overhead in
>> setting up a new connection - extra round trips plus TCP slow-start.
> Concur. However, persistent connections (and possibly pipelining) will
> pretty much mean that you'll need to make sure you're maintaining a
> priority-queue of textures to fetch. Otherwise it will *feel* slower to
> the end-user even if it is actually faster in total fetch-and-render
> time. I've been down this road before.

Correct, but that's also something we should improve anyway - doing a 
better job of prioritizing which textures are loaded and in what order 
could make things _seem_ faster, even if the total time was the same.  
Doing both that and the connection handling together would be a big win 
(file under "Faster").



___
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] I was told this need to be dropped on the mailing list.

[Aimee Linden]

VWR-20751 should probably have been carried over as an incomplete task from the 
last sprint. Could you please add subtasks to VWR-20751 for each of these to 
track them?

According to my notes at 
https://spreadsheets.google.com/ccc?key=0AiLvQmencIAJdFF3N21iS3NRamlvRjdqSWxOdUNhdVE&hl=en&authkey=CO7ckKkK
 SNOW-512 shouldn't be imported without SNOW-748 (r3499 and r3501 in Snowglobe 
SVN) at least, as it breaks the Mac build.

Aimee.


On 31 Aug 2010, at 23:17, lists.secondlife@trap.wereanimal.net wrote:

> From http://jira.secondlife.com/browse/VWR-20751
> 
> I've added changesets for you to work with. These are the ones I used to get 
> viewer-devolment to build on linux 64-bit standalone.
> These patches/changeset have been updated to viewer-devolment as it was 
> different from snowglobe 2.x code.
> 
> https://bitbucket.org/Techwolf/viewer-development/changeset/5a7ee78d029e
> SNOW-746: Finished Google BreakPad cmake for standalone
> 
> https://bitbucket.org/Techwolf/viewer-development/changeset/ff09fdf21fde
> cmake patch from SNOW-543 updated for viewer-development
> 
> https://bitbucket.org/Techwolf/viewer-development/changeset/fd6fcea097f0
> viewer_manifest.py fixes from SNOW-334, SNOW-47, SNOW-517, and SNOW-543. They 
> all touch each other code, so combined into one changeset. Add doc/contrub 
> credit in the right places.
> 
> https://bitbucket.org/Techwolf/viewer-development/changeset/111a293c0e1c
> VWR-20893: "class Linux_x86_64Manifest" missing from viewer_manifest.py. 
> Breaking linux 64-bit build.
> 
> https://bitbucket.org/Techwolf/viewer-development/changeset/00bd21962052
> SNOW-512/SNOW-287: Build of LLPlugin fails on 64bit linux due to non PIC code 
> linking into the DSO.
> Formatting, cleanup, and one minor change by Techwolf Lupindo. Minor change 
> was a move of the hunk in indra/media_plugins/webkit/CmakeLists.txt to same 
> area as the other plugins CmakeLists.txt files.
> 
> https://bitbucket.org/Techwolf/viewer-development/changeset/15d19316812c
> SNOW-599/SNOW-747: Pulseaudio should be optional on Linux.
> 
> https://bitbucket.org/Techwolf/viewer-development/changeset/5697874b390b
> Add missing "if (LL_TESTS)" from SNOW-651/SNOW-654
> 
> -
> I've allready done the work. But the process to getting in the process is 
> still unclear. Red tape golore. I hope that can be changed.
> 
> --Techwolf Lupindo
> ___
> 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] I was told this need to be dropped on the mailing list.

[Boroondas Gupte]

 Hi Aimee

On 09/01/2010 05:02 PM, Aimee Linden wrote:
> VWR-20751 should probably have been carried over as an incomplete task from 
> the last sprint. Could you please add subtasks to VWR-20751 for each of these 
> to track them?
Should I do the same with the issues fixed in my repository
?

> According to my notes at 
> https://spreadsheets.google.com/ccc?key=0AiLvQmencIAJdFF3N21iS3NRamlvRjdqSWxOdUNhdVE&hl=en&authkey=CO7ckKkK
>  SNOW-512 shouldn't be imported without SNOW-748 (r3499 and r3501 in 
> Snowglobe SVN) at least, as it breaks the Mac build.
I've already applied those to my repository, after pulling in Techwolf's
changes. See my comment on jira
.
Can you test it, please?

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] before opena Jira, APR

[Francesco Rabbi]

Il giorno 01/set/2010, alle ore 16:47, "Oz Linden (Scott Lawrence)"
 ha scritto:

>
>
> Correct, but that's also something we should improve anyway - doing a
> better job of prioritizing which textures are loaded and in what order
> could make things _seem_ faster, even if the total time was the same.
> Doing both that and the connection handling together would be a big win
> (file under "Faster").

May be usefull do something like old windlight... The area visible by
avatar (cam or mouselook) should be splitted in slices and textures
should be downloaded starting from closest slice 16 textures each
512Kbps of inbound network speed (client setup). A system for fallback
on single texture if corrupted or timed out will be great...



-- 
Sent by iPhone
___
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] Code review request: VWR-22454 (Teleporting multiple friends)

[Aimee Linden]

Hi,

Could I get some eyes on a fix for VWR-22454 (Teleporting multiple friends) 
please?

 
http://bitbucket.org/aimee_linden/viewer-development-import/changeset/18f8e079a1de

Aimee.
___
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] Code review request: VWR-22454 (Teleporting multiple friends)

[Tofu Linden]

Looks shippable.  I assume it works.  Ideally the (nice) video-repro
would be text-ized so it doesn't have to be decoded by QA in real time. :)
+1

Aimee Linden wrote:
> Hi,
> 
> Could I get some eyes on a fix for VWR-22454 (Teleporting multiple friends) 
> please?
> 
>  
> http://bitbucket.org/aimee_linden/viewer-development-import/changeset/18f8e079a1de
> 
> Aimee.
> ___
> 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] before opena Jira, APR

[Sythos]

On Wed, 01 Sep 2010 11:28:42 +0100
Tofu Linden  wrote:

> Altair Sythos Memo wrote:
> ...
> > 2010-08-31T21:02:02Z WARNING: ll_apr_warn_status: APR: Too many open
> > files 
> > 
> > 2010-08-31T21:02:02Z WARNING: open:  Attempting to open
> > filename: /home/user/.secondlife/cache/texturecache/texture.entries
> ...
> > not so sure anyway is a viewer problem of something specific to my
> > linuxbox... is why i'm asking here if somebody else match this kind
> > of crash with latest build
> 
> This is a genuine problem.  Please file it in jira.  Any eyes on this
> would be welcome.
> It seems to have popped up recently - it may be related to the latest
> HTTP textures changes, not sure (perhaps leaking file handles, though
> lsof says we're still somewhat under the default limits).

http://jira.secondlife.com/browse/VWR-22757

added info, but i thyink "lsof" isn't right tools, if on an empty sim
(1 texture: the gorund) of if i'm in a city fullfit of textures lsof
report about same numbers.

is there a debug info to activate to read files opened by HTTP handler?
___
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] System Folders to Top

[Suz Dollar]

As a user, I would like to be able to turn off the forced system folders 
to top. This used to be an obvious and easy thing to change back and 
forth on the fly and now seems to have been removed and relegated to the 
debug menu. As an advanced user, I can work with the debug setting for 
this, but it seems anti-intuitive to remove this when many who go into 
biz may simply need their own folders at the top and most easily accessible.
___
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] multiwearable userstories

[Erin Mallory]

As a user, the new mutliwearables are incrdibly nice, but now make some things 
a little tricky.  I have collected three related userstories addressing them.

1) As a user, I would like a way to keep my huds (and hair) from being stripped 
off if I replace my outfit. 
2) As a user I would like an option to replace just the clothing portions of an 
outfit, as well as the ability to replace a single layer of clothing in an 
outfit.
3) As a user I would like the ability to remove a given clothing item on a 
layer from the remove clothing menu without having to click remove (layername) 
until that item is gone. 
4) As a user I would like to have an ao integrated into the UI so I don't have 
to worry about accidentally removing it if i change outfits. 

Cummere Mayo... 
  ___
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] Removal of the "MultipleAttachments" debug settings ?

[Kadah]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 9/1/2010 4:09 AM, Argent Stonecutter wrote:
> It wasn't broken historically: it was a prefs setting.
> 
> Also, gamers don't like it the way it is, seems like they want to completely 
> lose the chat bar on hitting enter:
> 
> http://jira.secondlife.com/browse/VWR-18323
> 
> The current behavior doesn't work well for either camp.

I prefer WASD movement, but the current method has a lot of focus
control issues where enter doesn't always bring focus to the chat bar.
I'm having to use the mouse all the time to do this.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJMfruSAAoJEIdLfPRu7qE2zVUH/ijuHRiyltlTkb1pL0dSIxIN
Zo8jbka4mtM2AL/b3GkfVAiIwuVGDeLaaBrGRgne2PlIF9M4D3Jw5EkNJciUGGZN
FovcffozVHNYUjc7EboNDXNzZlVxMZEvWeEoaMldIsDsZYcwjdMGm4wtfjwyRos1
y9fbeMXM31vXRP0uRmWSkcyih7TvYByv++CaoAfASwzyU6F6erXRS4ZOvp1CKudW
d6IpDG/RjDhhhjqq2NXboSv8/YtcDZGaeLO3uhgx+iime7uDVqI6y8eNe/uATyuE
tCS19v9PArpZsiGQ8r9OkmrS0gf2n1kTsZ7eN3C7PKo8hJdljwzbKVsimDhu8nU=
=jkKK
-END PGP SIGNATURE-
___
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] System Folders to Top

[Lance Corrimal]

Am Wednesday 01 September 2010 schrieb Suz Dollar:
> As a user, I would like to be able to turn off the forced system
> folders to top. This used to be an obvious and easy thing to
> change back and forth on the fly and now seems to have been
> removed and relegated to the debug menu.

there's a debug menu item for that??? where which what how



bye,
LC
___
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] Removal of the "MultipleAttachments" debug settings ?

[Sythos]

On Wed, 01 Sep 2010 13:46:10 -0700
Kadah  wrote:


> I prefer WASD movement, but the current method has a lot of focus
> control issues where enter doesn't always bring focus to the chat bar.
> I'm having to use the mouse all the time to do this.

I htink is better give as option to residents, a lot of ppl got crazy
without a fixed focus on chatbar...
___
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] System Folders to Top

[Suz Dollar]

Inventory.SystemFoldersToTop

Set to false will put the folders in full alpha numeric order with 
special characters like ! at the top. Set to True will leave it with 
system folders always at the top. I've had it with the system folders 
mixed in for so long that it held the preference somewhere long after 
the option dropped in 2.x. I had to go back to 1.23 to figure out where 
the menu option was missing. This should be somewhere on our options 
gadget, a loss imo from 1.23.


Lance Corrimal wrote:
> Am Wednesday 01 September 2010 schrieb Suz Dollar:
>   
>> As a user, I would like to be able to turn off the forced system
>> folders to top. This used to be an obvious and easy thing to
>> change back and forth on the fly and now seems to have been
>> removed and relegated to the debug menu.
>> 
>
> there's a debug menu item for that??? where which what how
>
>
>
> bye,
> LC
> ___
> 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] Removal of the "MultipleAttachments" debug settings ?

[Glen Canaday]

People on this list got pretty vitriolic about it only a few months ago
- I was under the impression the gamers wanted it the way it is.

Where was this ever a pref setting? I don't recall ever seeing it.

--GC

On Wed, 2010-09-01 at 06:09 -0500, Argent Stonecutter wrote:
> On 2010-08-31, at 22:40, Glen Canaday wrote:
> > Gamers like it broken like it is now, people who SOCIALIZE here (since
> > SL is, in fact, *not* a game... ahem) like it broken the way it's
> > historically been.
> 
> It wasn't broken historically: it was a prefs setting.
> 
> Also, gamers don't like it the way it is, seems like they want to completely 
> lose the chat bar on hitting enter:
> 
> http://jira.secondlife.com/browse/VWR-18323
> 
> The current behavior doesn't work well for either camp.


___
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] jira? avatar_lad.xml

[Sythos]

in last 2.1.2 build in mouselook all items are rezzed, i've hair worn
on Skull, in avatar_lad.xml i see:



but in mouselook i see my hair

how/where can i check if file correctly readed and parsed or the
trouble is elsewhere?
___
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] jira? avatar_lad.xml

[Sythos]

On Thu, 2 Sep 2010 00:06:25 +0200
Altair "Sythos" Memo  wrote:

> in last 2.1.2 build in mouselook all items are rezzed, i've hair worn
> on Skull, in avatar_lad.xml i see:
> 
>   id="2"
>  group="2"
>  pie_slice="2"
>  name="Skull"
>  joint="mHead"
>  position="0 0 0.15"
>  rotation="0 0 90"
>  visible_in_first_person="false" />
> 
> but in mouselook i see my hair
> 
> how/where can i check if file correctly readed and parsed or the
> trouble is elsewhere?


just checked... ALL attachments are visible in mouselook, shoes rings
and belt too
___
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] Own attachments visible in mouselook (was: jira? avatar_lad.xml)

[Boroondas Gupte]

 On 09/02/2010 12:14 AM, Altair Sythos Memo wrote:
> just checked... ALL attachments are visible in mouselook, shoes rings
> and belt too
Sounds like VWR-22022 .

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] Own attachments visible in mouselook (was: jira? avatar_lad.xml)

[Sythos]

On Thu, 02 Sep 2010 00:36:04 +0200
Boroondas Gupte  wrote:

>  On 09/02/2010 12:14 AM, Altair Sythos Memo wrote:
> > just checked... ALL attachments are visible in mouselook, shoes
> > rings and belt too
> Sounds like VWR-22022 .

yes sound like... but why i've received 5 copies of your email? O_o
___
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] jira? avatar_lad.xml

[Stickman]

> just checked... ALL attachments are visible in mouselook, shoes rings
> and belt too

There's an option in preferences: "show avatar in mouselook." It moved
in 2.x, but it's still there. Unless they took it out in 2.1. Turning
it off should make your attachments not visible in mouselook.

Or are you saying they're visible regardless of the option? I think
I'd get more complaints about it from customers if you were. I haven't
gotten any in a while.

Stickman
___
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 Sprint 2 Retrospective Notes Posted

[Esbee Linden (Sarah Hutchinson)]

Notes from our Sprint Retrospective meeting on Tuesday are now posted (finally!)

https://wiki.secondlife.com/wiki/Snowstorm_Sprint_Retrospective_Archive

Cheers!
Esbee___
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