From sldev at free.fr Sat Oct 1 13:24:56 2011 From: sldev at free.fr (Henri Beauchamp) Date: Sat, 1 Oct 2011 22:24:56 +0200 Subject: [opensource-dev] Mesh viewers and tcmalloc issues Message-ID: <20111001222456.498de5e3.sldev@free.fr> Greetings, I noticed that all the viewers using tcmalloc (mesh viewers under Linux and Windows, since those use SSE2 and must gain memory-aligned malloc() and new() calls that their standard library does not provide) suffer from a serious problem: they never release memory back to the system, meaning that after visiting a crowded place and caming around a lot, the viewer can occupy 2.5Gb of memory, and even after you TP out to a skybox with almost no objects/textures and no avatar around, the viewer retains the full amount of alloctaed memory for itself. Worst, should you manage to keep the viewer from crashing during a full hour or so, its allocated memory will get so badly fragmented that it starts crawling down and finally crashes, even in quiet sims. Bao Linden recently worked on private memory pools to work around these issues, but so far and despite his hard work, the result is less than satisfactory: the memory is still never released to the system, and the viewers using private memory pools crash every few minutes after issuing a warning: "LLPluginProcessParent::poll: apr_pollset_poll failed with status 4 Well, be happy since I found an easy work around for these problems while working on the Cool VL Viewer v1.26.1 (the mesh branch). tcmalloc is actually supposed to release back to the system the memory freed by the application using it, but it does so only after a certain number of memory blocks have been freed. There is an environment variable that you can set (TCMALLOC_RELEASE_RATE) to adjust the "rate" at which tcmalloc will release the freed blocks back to the system. In fact, this is not really a rate, but a divisor (the number of freed blocks is divided by the rate number (when != 0: a 0 rate means "never release memory"), and compared to a threshold. If the number is below the threshold, the freed blocks are released. The documentation for tcmalloc says that "Reasonable rates are in the range [0,10]", but even with a rate of 10, you never get the viewer to release more than a couple hundreds megabytes for 2+Gb of allocated memory. It occurred to me that the algorithm tcmalloc uses is simply crippled ! The good news, is that if you pass an "unreasonnable" rate, tcmalloc will finally release memory (the more "unreasonnable" and the more memory is released). With a rate of 10000 (yes, ten thousands), you get the viewer to release everything when it doesn't need it any more, which matches the behaviour of tcmalloc-less viewers. Since the Windows builds don't use a wrapper script to launch the viewer, it is however best to hardcode this new rate as the default one in tcmalloc istelf. This is what I did for the Cool VL Viewer and it works like a charm. There is only one line to change in tcmalloc source, in src/page_heap.cc: DEFINE_double(tcmalloc_release_rate, EnvToDouble("TCMALLOC_RELEASE_RATE", 10000.0), <--- HERE "Rate at which we release unused memory to the system. " "Zero means we never release memory back to the system. " "Increase this flag to return memory faster; decrease it " "to return memory slower. Reasonable rates are in the " "range [0,10]"); Now, the viewer runs rock stable (just like the non-mesh, tcmalloc-less version) and uses very reasonnable amounts of memory. It also doesn't suffer from memory fragmentation any more since it is transparently taken care of by the OS (via the page table and the PMMU of the CPU, something neither tcmalloc nor Bao's private memory pool can do since these are userspace code). For what it is worth... Henri. From moriz.gupte at gmail.com Sat Oct 1 13:46:39 2011 From: moriz.gupte at gmail.com (Moriz Gupte) Date: Sat, 1 Oct 2011 14:46:39 -0600 Subject: [opensource-dev] Mesh viewers and tcmalloc issues In-Reply-To: <20111001222456.498de5e3.sldev@free.fr> References: <20111001222456.498de5e3.sldev@free.fr> Message-ID: Thank you Henri. On Sat, Oct 1, 2011 at 2:24 PM, Henri Beauchamp wrote: > Greetings, > > I noticed that all the viewers using tcmalloc (mesh viewers under Linux > and Windows, since those use SSE2 and must gain memory-aligned malloc() > and new() calls that their standard library does not provide) suffer > from a serious problem: they never release memory back to the system, > meaning that after visiting a crowded place and caming around a lot, > the viewer can occupy 2.5Gb of memory, and even after you TP out to a > skybox with almost no objects/textures and no avatar around, the viewer > retains the full amount of alloctaed memory for itself. > > Worst, should you manage to keep the viewer from crashing during a full > hour or so, its allocated memory will get so badly fragmented that it > starts crawling down and finally crashes, even in quiet sims. > > Bao Linden recently worked on private memory pools to work around these > issues, but so far and despite his hard work, the result is less than > satisfactory: the memory is still never released to the system, and the > viewers using private memory pools crash every few minutes after issuing > a warning: > "LLPluginProcessParent::poll: apr_pollset_poll failed with status 4 > > Well, be happy since I found an easy work around for these problems > while working on the Cool VL Viewer v1.26.1 (the mesh branch). > > tcmalloc is actually supposed to release back to the system the memory > freed by the application using it, but it does so only after a certain > number of memory blocks have been freed. There is an environment > variable that you can set (TCMALLOC_RELEASE_RATE) to adjust the "rate" > at which tcmalloc will release the freed blocks back to the system. > In fact, this is not really a rate, but a divisor (the number of freed > blocks is divided by the rate number (when != 0: a 0 rate means "never > release memory"), and compared to a threshold. If the number is below > the threshold, the freed blocks are released. > The documentation for tcmalloc says that "Reasonable rates are in the > range [0,10]", but even with a rate of 10, you never get the viewer to > release more than a couple hundreds megabytes for 2+Gb of allocated > memory. It occurred to me that the algorithm tcmalloc uses is simply > crippled ! > > The good news, is that if you pass an "unreasonnable" rate, tcmalloc > will finally release memory (the more "unreasonnable" and the more > memory is released). With a rate of 10000 (yes, ten thousands), you > get the viewer to release everything when it doesn't need it any more, > which matches the behaviour of tcmalloc-less viewers. > > Since the Windows builds don't use a wrapper script to launch the > viewer, it is however best to hardcode this new rate as the default > one in tcmalloc istelf. This is what I did for the Cool VL Viewer > and it works like a charm. There is only one line to change in > tcmalloc source, in src/page_heap.cc: > DEFINE_double(tcmalloc_release_rate, > EnvToDouble("TCMALLOC_RELEASE_RATE", 10000.0), <--- HERE > "Rate at which we release unused memory to the system. " > "Zero means we never release memory back to the system. " > "Increase this flag to return memory faster; decrease it " > "to return memory slower. Reasonable rates are in the " > "range [0,10]"); > > Now, the viewer runs rock stable (just like the non-mesh, tcmalloc-less > version) and uses very reasonnable amounts of memory. It also doesn't > suffer from memory fragmentation any more since it is transparently > taken care of by the OS (via the page table and the PMMU of the CPU, > something neither tcmalloc nor Bao's private memory pool can do since > these are userspace code). > > For what it is worth... > > Henri. > _______________________________________________ > 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 > -- 'Consider how the lilies grow. They do not labor or spin.' *Rameshsharma Ramloll* PhD, *Research Associate Professor*, Idaho State University, Pocatello, ID 83209 Tel: 208-282-5333 Blog , LinkedIn , Play2Train -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20111001/00571899/attachment.htm From mike.chase at alternatemetaverse.com Sat Oct 1 21:23:36 2011 From: mike.chase at alternatemetaverse.com (Mike Chase) Date: Sun, 02 Oct 2011 00:23:36 -0400 Subject: [opensource-dev] Mesh viewers and tcmalloc issues In-Reply-To: <20111001222456.498de5e3.sldev@free.fr> References: <20111001222456.498de5e3.sldev@free.fr> Message-ID: <4E87E748.90605@alternatemetaverse.com> On 10/01/2011 04:24 PM, Henri Beauchamp wrote: > Greetings, > > I noticed that all the viewers using tcmalloc (mesh viewers under Linux > and Windows, since those use SSE2 and must gain memory-aligned malloc() > and new() calls that their standard library does not provide) suffer > from a serious problem: they never release memory back to the system, > meaning that after visiting a crowded place and caming around a lot, > the viewer can occupy 2.5Gb of memory, and even after you TP out to a > skybox with almost no objects/textures and no avatar around, the viewer > retains the full amount of alloctaed memory for itself. > > Worst, should you manage to keep the viewer from crashing during a full > hour or so, its allocated memory will get so badly fragmented that it > starts crawling down and finally crashes, even in quiet sims. > > Bao Linden recently worked on private memory pools to work around these > issues, but so far and despite his hard work, the result is less than satisfactory: the memory is still never released to the system, and the > viewers using private memory pools crash every few minutes after issuing > a warning: > "LLPluginProcessParent::poll: apr_pollset_poll failed with status 4 > > Well, be happy since I found an easy work around for these problems > while working on the Cool VL Viewer v1.26.1 (the mesh branch). > > tcmalloc is actually supposed to release back to the system the memory > freed by the application using it, but it does so only after a certain > number of memory blocks have been freed. There is an environment > variable that you can set (TCMALLOC_RELEASE_RATE) to adjust the "rate" > at which tcmalloc will release the freed blocks back to the system. > In fact, this is not really a rate, but a divisor (the number of freed > blocks is divided by the rate number (when != 0: a 0 rate means "never > release memory"), and compared to a threshold. If the number is below > the threshold, the freed blocks are released. > The documentation for tcmalloc says that "Reasonable rates are in the > range [0,10]", but even with a rate of 10, you never get the viewer to > release more than a couple hundreds megabytes for 2+Gb of allocated > memory. It occurred to me that the algorithm tcmalloc uses is simply > crippled ! > > The good news, is that if you pass an "unreasonnable" rate, tcmalloc > will finally release memory (the more "unreasonnable" and the more > memory is released). With a rate of 10000 (yes, ten thousands), you > get the viewer to release everything when it doesn't need it any more, > which matches the behaviour of tcmalloc-less viewers. > > Since the Windows builds don't use a wrapper script to launch the > viewer, it is however best to hardcode this new rate as the default > one in tcmalloc istelf. This is what I did for the Cool VL Viewer > and it works like a charm. There is only one line to change in > tcmalloc source, in src/page_heap.cc: > DEFINE_double(tcmalloc_release_rate, > EnvToDouble("TCMALLOC_RELEASE_RATE", 10000.0),<--- HERE > "Rate at which we release unused memory to the system. " > "Zero means we never release memory back to the system. " > "Increase this flag to return memory faster; decrease it " > "to return memory slower. Reasonable rates are in the " > "range [0,10]"); > > Now, the viewer runs rock stable (just like the non-mesh, tcmalloc-less > version) and uses very reasonnable amounts of memory. It also doesn't > suffer from memory fragmentation any more since it is transparently > taken care of by the OS (via the page table and the PMMU of the CPU, > something neither tcmalloc nor Bao's private memory pool can do since > these are userspace code). > > For what it is worth... Setting this as described for me made the client (on Linux) so slow as to be unuseable. I am seeing occasional crashesas well and tried this as a workaround. Mike > Henri. > _______________________________________________ > 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 From zabb65 at gmail.com Sat Oct 1 22:12:40 2011 From: zabb65 at gmail.com (Zabb65) Date: Sun, 2 Oct 2011 01:12:40 -0400 Subject: [opensource-dev] Mesh viewers and tcmalloc issues In-Reply-To: <4E87E748.90605@alternatemetaverse.com> References: <20111001222456.498de5e3.sldev@free.fr> <4E87E748.90605@alternatemetaverse.com> Message-ID: It is not desirable to let the default allocation engine run under Linux, and possibly Mac. glibc has an incredibly slow allocator for small objects, and tcmalloc was implemented to remedy these situations(This is what I heard, but have not confirmed.) Inventory and a few other items create massive numbers of very small heap objects. Setting a much lower value(1000) that only returns memory occasionally is much more desirable on this platform. You can do this without recompiling tcmalloc as well by passing an environment variable, which is the desired method. Please note that it is listed as a caveat on the tcmalloc page that it very clearly does not return memory to the system(I assume this is outdated, or reflects the default value) Windows doesn't really have a need for tcmalloc from what I can see. If LL compiles using visual studio 2010, the C runtime uses the low fragmentation heap allocator. The low fragmentation allocator is fast enough to satisfy even large numbers of small objects, and keep heap fragmentation to very small percentages. Working "against" the heap manager on windows by rolling your own is generally not advised unless there are extraordinary needs or requirements, and even then, it is far easier to cause more problems then you fix. Is tcmalloc really providing aligned allocations? I only found documentation that it would enforced specific amounts of space between items, not that they were guaranteed to be aligned to an X byte boundary. (Maybe this is what the spacing guarantees, but I am unsure.) On Sun, Oct 2, 2011 at 00:23, Mike Chase wrote: > On 10/01/2011 04:24 PM, Henri Beauchamp wrote: >> Greetings, >> >> I noticed that all the viewers using tcmalloc (mesh viewers under Linux >> and Windows, since those use SSE2 and must gain memory-aligned malloc() >> and new() calls that their standard library does not provide) suffer >> from a serious problem: they never release memory back to the system, >> meaning that after visiting a crowded place and caming around a lot, >> the viewer can occupy 2.5Gb of memory, and even after you TP out to a >> skybox with almost no objects/textures and no avatar around, the viewer >> retains the full amount of alloctaed memory for itself. >> >> Worst, should you manage to keep the viewer from crashing during a full >> hour or so, its allocated memory will get so badly fragmented that it >> starts crawling down and finally crashes, even in quiet sims. >> >> Bao Linden recently worked on private memory pools to work around these >> issues, but so far and despite his hard work, the result is less than satisfactory: the memory is still never released to the system, and the >> viewers using private memory pools crash every few minutes after issuing >> a warning: >> "LLPluginProcessParent::poll: apr_pollset_poll failed with status 4 >> >> Well, be happy since I found an easy work around for these problems >> while working on the Cool VL Viewer v1.26.1 (the mesh branch). >> >> tcmalloc is actually supposed to release back to the system the memory >> freed by the application using it, but it does so only after a certain >> number of memory blocks have been freed. There is an environment >> variable that you can set (TCMALLOC_RELEASE_RATE) to adjust the "rate" >> at which tcmalloc will release the freed blocks back to the system. >> In fact, this is not really a rate, but a divisor (the number of freed >> blocks is divided by the rate number (when != 0: a 0 rate means "never >> release memory"), and compared to a threshold. If the number is below >> the threshold, the freed blocks are released. >> The documentation for tcmalloc says that "Reasonable rates are in the >> range [0,10]", but even with a rate of 10, you never get the viewer to >> release more than a couple hundreds megabytes for 2+Gb of allocated >> memory. It occurred to me that the algorithm tcmalloc uses is simply >> crippled ! >> >> The good news, is that if you pass an "unreasonnable" rate, tcmalloc >> will finally release memory (the more "unreasonnable" and the more >> memory is released). With a rate of 10000 (yes, ten thousands), you >> get the viewer to release everything when it doesn't need it any more, >> which matches the behaviour of tcmalloc-less viewers. >> >> Since the Windows builds don't use a wrapper script to launch the >> viewer, it is however best to hardcode this new rate as the default >> one in tcmalloc istelf. This is what I did for the Cool VL Viewer >> and it works like a charm. There is only one line to change in >> tcmalloc source, in src/page_heap.cc: >> DEFINE_double(tcmalloc_release_rate, >> ? ? ?EnvToDouble("TCMALLOC_RELEASE_RATE", 10000.0),<--- HERE >> ? ? ?"Rate at which we release unused memory to the system. ?" >> ? ? ?"Zero means we never release memory back to the system. ?" >> ? ? ?"Increase this flag to return memory faster; decrease it " >> ? ? ?"to return memory slower. ?Reasonable rates are in the " >> ? ? ?"range [0,10]"); >> >> Now, the viewer runs rock stable (just like the non-mesh, tcmalloc-less >> version) and uses very reasonnable amounts of memory. It also doesn't >> suffer from memory fragmentation any more since it is transparently >> taken care of by the OS (via the page table and the PMMU of the CPU, >> something neither tcmalloc nor Bao's private memory pool can do since >> these are userspace code). >> >> For what it is worth... > > Setting this as described for me made the client (on Linux) so slow as > to be unuseable. ?I am seeing occasional crashesas well and tried this > as a workaround. > > Mike > >> Henri. >> _______________________________________________ >> 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 > From Lance.Corrimal at eregion.de Sat Oct 1 23:39:06 2011 From: Lance.Corrimal at eregion.de (Lance Corrimal) Date: Sun, 2 Oct 2011 08:39:06 +0200 Subject: [opensource-dev] Mesh viewers and tcmalloc issues In-Reply-To: <20111001222456.498de5e3.sldev@free.fr> References: <20111001222456.498de5e3.sldev@free.fr> Message-ID: <201110020839.06870.Lance.Corrimal@eregion.de> Am Samstag, 1. Oktober 2011 schrieb Henri Beauchamp: first, if this works as advertized... henri, you rock. majorly. I've seen a scorpions live concert on their last world tour rock more but not much. second, two issues: 1. viever_manifest.py needs to be edited to reflect the fact that libtcmalloc.so now has the version 0.2.2 and not 0.1.0 :) 2. 3p-google-perftools does not build under VS2010 EXPRESS since the build script relies on devenv.com :/ 1. is simple enough but what do i do about 2? bye, LC From sldev at free.fr Sun Oct 2 00:48:18 2011 From: sldev at free.fr (Henri Beauchamp) Date: Sun, 2 Oct 2011 09:48:18 +0200 Subject: [opensource-dev] Mesh viewers and tcmalloc issues In-Reply-To: <4E87E748.90605@alternatemetaverse.com> References: <20111001222456.498de5e3.sldev@free.fr> <4E87E748.90605@alternatemetaverse.com> Message-ID: <20111002094818.0c82e9da.sldev@free.fr> On Sun, 02 Oct 2011 00:23:36 -0400, Mike Chase wrote: > Setting this as described for me made the client (on Linux) so slow as > to be unuseable. I am seeing occasional crashesas well and tried this > as a workaround. I can tell you the slow down is *certainly* not coming from this fix: I conducted many tests here (have been using this fix for over a week now), and can tell there is absolutely no speed difference with the fix and without the fix... Henri. From Lance.Corrimal at eregion.de Sun Oct 2 01:01:00 2011 From: Lance.Corrimal at eregion.de (Lance Corrimal) Date: Sun, 2 Oct 2011 10:01:00 +0200 Subject: [opensource-dev] Mesh viewers and tcmalloc issues In-Reply-To: <20111002094818.0c82e9da.sldev@free.fr> References: <20111001222456.498de5e3.sldev@free.fr> <4E87E748.90605@alternatemetaverse.com> <20111002094818.0c82e9da.sldev@free.fr> Message-ID: <201110021001.00807.Lance.Corrimal@eregion.de> Am Sonntag, 2. Oktober 2011 schrieb Henri Beauchamp: > On Sun, 02 Oct 2011 00:23:36 -0400, Mike Chase wrote: > > Setting this as described for me made the client (on Linux) so > > slow as to be unuseable. I am seeing occasional crashesas well > > and tried this as a workaround. > > I can tell you the slow down is *certainly* not coming from this > fix: I conducted many tests here (have been using this fix for > over a week now), and can tell there is absolutely no speed > difference with the fix and without the fix... I've been using "export TCMALLOC_RELEASE_RATE=10000" here for a bit, and didn't notice any negative impacts either, but the memory usage of the client dropped by roughly one gig... bye, LC From sldev at free.fr Sun Oct 2 01:20:47 2011 From: sldev at free.fr (Henri Beauchamp) Date: Sun, 2 Oct 2011 10:20:47 +0200 Subject: [opensource-dev] Mesh viewers and tcmalloc issues In-Reply-To: References: <20111001222456.498de5e3.sldev@free.fr> <4E87E748.90605@alternatemetaverse.com> Message-ID: <20111002102047.68fc545f.sldev@free.fr> On Sun, 2 Oct 2011 01:12:40 -0400, Zabb65 wrote: > It is not desirable to let the default allocation engine run under > Linux, and possibly Mac. glibc has an incredibly slow allocator for > small objects, and tcmalloc was implemented to remedy these > situations(This is what I heard, but have not confirmed.) Inventory > and a few other items create massive numbers of very small heap > objects. This would be true only if the viewer was to perform dozens of thousands of allocations *every* second, which is *not* the case, plus the speed difference is not that large (we are speaking of microseconds per allocation here), especially when tcmalloc finds itself with a fragmented allocated virtual memory pool and must perform garbage collection as a result: the overhead is then huge, when the system malloc() simply *transparently* benefits from the OS ability of allocating continuous blocks of virtual memory out of fragmented physical memory via the page table and doesn't need any garbage collection. It becomes even worst with private memory pools of v3 that add yet another layer of code around memory allocations, slowing things down more. Finally, when tcmalloc doesn't release enough memory you find youself with a huge process in memory that may result in your system starting to swap... And instead of microseconds penalties, we are now speaking of seconds ! > Setting a much lower value(1000) that only returns memory > occasionally is much more desirable on this platform. The problem is then that not *all* memory get released (the tcmalloc algorithm is crippled), and tcmalloc will still get its non-released pool fragmented over time. > You can do this > without recompiling tcmalloc as well by passing an environment > variable, which is the desired method. I know and told it: please re-read my message ! However, it doesn't work for Windows (unless you create a complicated shortcut with cmd.exe and accept having a command window staying open together with the viewer after launching the latter with that shortcut), thus why hardcoding the value is best (it's a private library for use by the viewer only anyway: it's not like it it was to be installed system-wide). > Please note that it is listed > as a caveat on the tcmalloc page that it very clearly does not return > memory to the system(I assume this is outdated, or reflects the > default value) No, you probably saw an outdated doc. See: http://google-perftools.googlecode.com/svn/trunk/doc/tcmalloc.html and scroll down to the "Releasing Memory Back to the System" section. > Windows doesn't really have a need for tcmalloc from what I can see. I so think it does for mesh viewers, for aligned allocations. MacOS-X doesn't need it. > If LL compiles using visual studio 2010, the C runtime uses the low > fragmentation heap allocator. The low fragmentation allocator is fast > enough to satisfy even large numbers of small objects, and keep heap > fragmentation to very small percentages. Working "against" the heap > manager on windows by rolling your own is generally not advised unless > there are extraordinary needs or requirements, and even then, it is > far easier to cause more problems then you fix. Really, the only true motivation behind the use of tcmalloc in mesh viewers (it was not use for non-mesh viewers) is to provide aligned allocations. Without it, and the way the mesh viewer code is written, the viewer simply crashes as soon as it tries to perform an SSE2 operation on an unaligned structure. I tried with and without tcmalloc in the non-mesh branch of the Cool VL Viewer (v1.26.0): there is no speed difference at all, but the viewer does use more memory with tcmalloc (even with the force- release trick). I got rid of it in newest v1.26.0 versions since it's not worth bothering with it for non-SSE2 llmath viewers. > Is tcmalloc really providing aligned allocations? I only found > documentation that it would enforced specific amounts of space between > items, not that they were guaranteed to be aligned to an X byte > boundary. (Maybe this is what the spacing guarantees, but I am > unsure.) Yes, it does (see above). Henri. From sldev at free.fr Sun Oct 2 01:23:57 2011 From: sldev at free.fr (Henri Beauchamp) Date: Sun, 2 Oct 2011 10:23:57 +0200 Subject: [opensource-dev] Mesh viewers and tcmalloc issues In-Reply-To: <201110020839.06870.Lance.Corrimal@eregion.de> References: <20111001222456.498de5e3.sldev@free.fr> <201110020839.06870.Lance.Corrimal@eregion.de> Message-ID: <20111002102357.87da208c.sldev@free.fr> On Sun, 2 Oct 2011 08:39:06 +0200, Lance Corrimal wrote: > second, two issues: > > 1. viever_manifest.py needs to be edited to reflect the fact that > libtcmalloc.so now has the version 0.2.2 and not 0.1.0 :) Yes, unless you recompile v1.7. > 2. 3p-google-perftools does not build under VS2010 EXPRESS since the > build script relies on devenv.com :/ Yep, it tries to include *NIX headers.. > 1. is simple enough but what do i do about 2? Simply recover the v1.7 version of 3p-google-perftools: it compiles fine here (under VS2005). Henri From Lance.Corrimal at eregion.de Sun Oct 2 01:58:44 2011 From: Lance.Corrimal at eregion.de (Lance Corrimal) Date: Sun, 2 Oct 2011 10:58:44 +0200 Subject: [opensource-dev] Mesh viewers and tcmalloc issues In-Reply-To: <20111002102357.87da208c.sldev@free.fr> References: <20111001222456.498de5e3.sldev@free.fr> <201110020839.06870.Lance.Corrimal@eregion.de> <20111002102357.87da208c.sldev@free.fr> Message-ID: <201110021058.44523.Lance.Corrimal@eregion.de> Am Sonntag, 2. Oktober 2011 schrieb Henri Beauchamp: > > 1. is simple enough but what do i do about 2? > > Simply recover the v1.7 version of 3p-google-perftools: it compiles > fine here (under VS2005). Doesn't under VS2010 EXPRESS... what now? bye, LC From wolfpup67 at earthlink.net Sun Oct 2 05:00:53 2011 From: wolfpup67 at earthlink.net (WolfPup Lowenhar) Date: Sun, 2 Oct 2011 08:00:53 -0400 Subject: [opensource-dev] Mesh viewers and tcmalloc issues In-Reply-To: <201110020839.06870.Lance.Corrimal@eregion.de> References: <20111001222456.498de5e3.sldev@free.fr> <201110020839.06870.Lance.Corrimal@eregion.de> Message-ID: <000001cc80fa$ef7e4170$ce7ac450$@net> Lance, Nicky P has a new fix for https://jira.secondlife.com/browse/OPEN-69 this will allow Open Source Developers using the Express version of Visual Studios properly build all 3p-libs as well as the viewer. > -----Original Message----- > From: opensource-dev-bounces at lists.secondlife.com [mailto:opensource-dev- > bounces at lists.secondlife.com] On Behalf Of Lance Corrimal > Sent: Sunday, October 02, 2011 2:39 AM > To: opensource-dev at lists.secondlife.com > Subject: Re: [opensource-dev] Mesh viewers and tcmalloc issues > > Am Samstag, 1. Oktober 2011 schrieb Henri Beauchamp: > > > first, if this works as advertized... henri, you rock. majorly. I've > seen a scorpions live concert on their last world tour rock more but > not much. > > second, two issues: > > 1. viever_manifest.py needs to be edited to reflect the fact that > libtcmalloc.so now has the version 0.2.2 and not 0.1.0 :) > > 2. 3p-google-perftools does not build under VS2010 EXPRESS since the > build script relies on devenv.com :/ > > 1. is simple enough but what do i do about 2? > > > 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 > ----- > No virus found in this message. > Checked by AVG - www.avg.com > Version: 2012.0.1809 / Virus Database: 2085/4533 - Release Date: 10/02/11 From Lance.Corrimal at eregion.de Sun Oct 2 05:12:41 2011 From: Lance.Corrimal at eregion.de (Lance Corrimal) Date: Sun, 2 Oct 2011 14:12:41 +0200 Subject: [opensource-dev] Mesh viewers and tcmalloc issues In-Reply-To: <000001cc80fa$ef7e4170$ce7ac450$@net> References: <20111001222456.498de5e3.sldev@free.fr> <201110020839.06870.Lance.Corrimal@eregion.de> <000001cc80fa$ef7e4170$ce7ac450$@net> Message-ID: <201110021412.41676.Lance.Corrimal@eregion.de> Am Sonntag, 2. Oktober 2011 schrieb WolfPup Lowenhar: > Lance, > Nicky P has a new fix for > https://jira.secondlife.com/browse/OPEN-69 this will allow Open > Source Developers using the Express version of Visual Studios > properly build all 3p-libs as well as the viewer. awesome! i guess I'll use that autobuild instead of the original one? bye, LC From nickyperian at yahoo.com Sun Oct 2 06:18:58 2011 From: nickyperian at yahoo.com (Nicky Perian) Date: Sun, 2 Oct 2011 06:18:58 -0700 (PDT) Subject: [opensource-dev] Mesh viewers and tcmalloc issues In-Reply-To: <201110021412.41676.Lance.Corrimal@eregion.de> References: <20111001222456.498de5e3.sldev@free.fr> <201110020839.06870.Lance.Corrimal@eregion.de> <000001cc80fa$ef7e4170$ce7ac450$@net> <201110021412.41676.Lance.Corrimal@eregion.de> Message-ID: <1317561538.17852.YahooMailNeo@web43509.mail.sp1.yahoo.com> I was trying to get all libraries to build w/o modifying the library source. google-perftools is/was on the needs work list. Vcexpress doesn't have a command line switch /Upgrade as devenv does. However, you can open an older solution file in the VS2010 Express IDE and it will upgrade to the latest. That is what I did and the library built. Using open-69 autobuild. I haven't built the viewer with it yet. PS. Individual project files can be upgraded with vcupgrade ? using Express just on command line. For solution files you must use the IDE. ________________________________ From: Lance Corrimal To: opensource-dev at lists.secondlife.com Sent: Sunday, October 2, 2011 7:12 AM Subject: Re: [opensource-dev] Mesh viewers and tcmalloc issues Am Sonntag, 2. Oktober 2011 schrieb WolfPup Lowenhar: > Lance, > Nicky P has a new fix for > https://jira.secondlife.com/browse/OPEN-69 this will allow Open > Source Developers using the Express version of Visual Studios > properly build all 3p-libs as well as the viewer. awesome! i guess I'll use that autobuild instead of the original one? 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20111002/38c070e7/attachment-0001.htm From mike.chase at alternatemetaverse.com Sun Oct 2 07:12:57 2011 From: mike.chase at alternatemetaverse.com (Mike Chase) Date: Sun, 02 Oct 2011 10:12:57 -0400 Subject: [opensource-dev] Mesh viewers and tcmalloc issues In-Reply-To: <20111002094818.0c82e9da.sldev@free.fr> References: <20111001222456.498de5e3.sldev@free.fr> <4E87E748.90605@alternatemetaverse.com> <20111002094818.0c82e9da.sldev@free.fr> Message-ID: <4E887169.9080906@alternatemetaverse.com> On 10/02/2011 03:48 AM, Henri Beauchamp wrote: > On Sun, 02 Oct 2011 00:23:36 -0400, Mike Chase wrote: > >> Setting this as described for me made the client (on Linux) so slow as >> to be unuseable. I am seeing occasional crashesas well and tried this >> as a workaround. > I can tell you the slow down is *certainly* not coming from this fix: > I conducted many tests here (have been using this fix for over a week > now), and can tell there is absolutely no speed difference with the > fix and without the fix... I'm pretty sure it is. No code changes, I simply set the environment variable and restarted. removing the environment variable again returned things to previous behaviour. This is running a 3.0.6 dev viewer on Fedora Linux (F15) x86-64. Mike > Henri. > _______________________________________________ > 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 From mike.chase at alternatemetaverse.com Sun Oct 2 07:20:58 2011 From: mike.chase at alternatemetaverse.com (Mike Chase) Date: Sun, 02 Oct 2011 10:20:58 -0400 Subject: [opensource-dev] Mesh viewers and tcmalloc issues In-Reply-To: <4E887169.9080906@alternatemetaverse.com> References: <20111001222456.498de5e3.sldev@free.fr> <4E87E748.90605@alternatemetaverse.com> <20111002094818.0c82e9da.sldev@free.fr> <4E887169.9080906@alternatemetaverse.com> Message-ID: <4E88734A.7030709@alternatemetaverse.com> On 10/02/2011 10:12 AM, Mike Chase wrote: > On 10/02/2011 03:48 AM, Henri Beauchamp wrote: >> On Sun, 02 Oct 2011 00:23:36 -0400, Mike Chase wrote: >> >>> Setting this as described for me made the client (on Linux) so slow as >>> to be unuseable. I am seeing occasional crashesas well and tried this >>> as a workaround. >> I can tell you the slow down is *certainly* not coming from this fix: >> I conducted many tests here (have been using this fix for over a week >> now), and can tell there is absolutely no speed difference with the >> fix and without the fix... > I'm pretty sure it is. No code changes, I simply set the environment > variable and restarted. removing the environment variable again returned > things to previous behaviour. This is running a 3.0.6 dev viewer on > Fedora Linux (F15) x86-64. One more note. I have 16gb of memory on this system so the large heap really isnt a problem per-se. I still see occasional exits (with no crashdump so I can't easily say what exactly is happening). RSS on my system is 10000 so I'm not coming even close to that. Henri, I'm not saying your wrong (though setting a param outside the specified operational range for the library doesn't feel like a *fix* to me). I do believe more testing is needed. Mike > > Mike >> Henri. >> _______________________________________________ >> 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 From carlo at alinoe.com Sun Oct 2 07:39:49 2011 From: carlo at alinoe.com (Carlo Wood) Date: Sun, 2 Oct 2011 16:39:49 +0200 Subject: [opensource-dev] Mesh viewers and tcmalloc issues In-Reply-To: <20111002102047.68fc545f.sldev@free.fr> References: <20111001222456.498de5e3.sldev@free.fr> <4E87E748.90605@alternatemetaverse.com> <20111002102047.68fc545f.sldev@free.fr> Message-ID: <20111002163949.7e3f86b5@hikaru.localdomain> On Sun, 2 Oct 2011 10:20:47 +0200 Henri Beauchamp wrote: > Really, the only true motivation behind the use of tcmalloc in mesh > viewers (it was not use for non-mesh viewers) is to provide aligned > allocations. Without it, and the way the mesh viewer code is written, > the viewer simply crashes as soon as it tries to perform an SSE2 > operation on an unaligned structure. Use _mm_malloc, if that doesn't exist use posix_memalign and if that also doesn't exist, just use malloc. That will work (for sse2 alignment). tcmalloc is to get speed from not having to lock threads when they allocate memory: they each have their own pool. I never saw any evidence that the main thread is waiting considerable long times (ie > 10 usec) on a lock in malloc because other threads are trying to alloc/free memory, so I don't see the need for tcmalloc in the viewer. I think LL fell in love with it for their server, but the decision to use it for the viewer is wrong. -- Carlo Wood From sldev at free.fr Sun Oct 2 09:25:09 2011 From: sldev at free.fr (Henri Beauchamp) Date: Sun, 2 Oct 2011 18:25:09 +0200 Subject: [opensource-dev] Mesh viewers and tcmalloc issues In-Reply-To: <20111002163949.7e3f86b5@hikaru.localdomain> References: <20111001222456.498de5e3.sldev@free.fr> <4E87E748.90605@alternatemetaverse.com> <20111002102047.68fc545f.sldev@free.fr> <20111002163949.7e3f86b5@hikaru.localdomain> Message-ID: <20111002182509.821c17d0.sldev@free.fr> On Sun, 2 Oct 2011 16:39:49 +0200, Carlo Wood wrote: > On Sun, 2 Oct 2011 10:20:47 +0200 > Henri Beauchamp wrote: > > > Really, the only true motivation behind the use of tcmalloc in mesh > > viewers (it was not use for non-mesh viewers) is to provide aligned > > allocations. Without it, and the way the mesh viewer code is written, > > the viewer simply crashes as soon as it tries to perform an SSE2 > > operation on an unaligned structure. > > Use _mm_malloc, if that doesn't exist use posix_memalign > and if that also doesn't exist, just use malloc. > That will work (for sse2 alignment). Insufficient for the current way the mesh viewers code is written: you also need all classes (and their members) used with SSE2 operations to be aligned, else you get crashes. This means that the C++ "new" call is also impacted. If you're not convinced, try by yourself by compiling the mesh viewer without tcmalloc under Linux or Windows, and admire the segfaults as soon as it starts rezzing anything. Also, this is why LL didn't use tcmalloc for MacOS-X builds, since that OS got natively aligned memory allocations. > tcmalloc is to get speed from not having to lock > threads when they allocate memory: they each have > their own pool. I never saw any evidence that the > main thread is waiting considerable long times > (ie > 10 usec) on a lock in malloc because other > threads are trying to alloc/free memory, so I don't > see the need for tcmalloc in the viewer. I think > LL fell in love with it for their server, but the > decision to use it for the viewer is wrong. They introduced tcmalloc use *only* because of the mesh code (tcmalloc was not in use before the mesh branch appeared), but I agree that its use in the viewer, beside the memory alignment issue is an overkill and certainly not necessary. I'd rather see a simpler memory allocator used than tcmalloc... Henri. From sldev at free.fr Sun Oct 2 09:30:49 2011 From: sldev at free.fr (Henri Beauchamp) Date: Sun, 2 Oct 2011 18:30:49 +0200 Subject: [opensource-dev] Mesh viewers and tcmalloc issues In-Reply-To: <4E887169.9080906@alternatemetaverse.com> References: <20111001222456.498de5e3.sldev@free.fr> <4E87E748.90605@alternatemetaverse.com> <20111002094818.0c82e9da.sldev@free.fr> <4E887169.9080906@alternatemetaverse.com> Message-ID: <20111002183049.0c6d3cca.sldev@free.fr> On Sun, 02 Oct 2011 10:12:57 -0400, Mike Chase wrote: > On 10/02/2011 03:48 AM, Henri Beauchamp wrote: > > On Sun, 02 Oct 2011 00:23:36 -0400, Mike Chase wrote: > > > >> Setting this as described for me made the client (on Linux) so slow as > >> to be unuseable. I am seeing occasional crashesas well and tried this > >> as a workaround. > > I can tell you the slow down is *certainly* not coming from this fix: > > I conducted many tests here (have been using this fix for over a week > > now), and can tell there is absolutely no speed difference with the > > fix and without the fix... > I'm pretty sure it is. No code changes, I simply set the environment > variable and restarted. removing the environment variable again returned > things to previous behaviour. This is running a 3.0.6 dev viewer on > Fedora Linux (F15) x86-64. Try harder... with multiple sessions (sometimes, you can log in a skybox and get 150fps, then relog with the same viewer, in the same skybox and with the same environment and get only 140fps...). Also, use the FPS reports issued each minute in the debug console (waiting for it to stabilize, which can take 3 minutes or so) and make sure the viewer window stays active (with focus) during the whole measurement period. I can asssure you I saw 0% difference (and I *did* test *hard* to make sure during now over 10 days). BTW, the Cool VL Viewer v1.26.1 (mesh branch) is now 5-7% faster than Snowglobe v1.5 it is (well, *was*) based on. Henri. From sldev at hotmail.com Sun Oct 2 09:45:01 2011 From: sldev at hotmail.com (Henri Beauchamp) Date: Sun, 2 Oct 2011 18:45:01 +0200 Subject: [opensource-dev] Mesh viewers and tcmalloc issues In-Reply-To: <4E88734A.7030709@alternatemetaverse.com> References: <20111001222456.498de5e3.sldev@free.fr> <4E87E748.90605@alternatemetaverse.com> <20111002094818.0c82e9da.sldev@free.fr> <4E887169.9080906@alternatemetaverse.com> <4E88734A.7030709@alternatemetaverse.com> Message-ID: <20111002184501.51be06f1.sldev@hotmail.com> On Sun, 02 Oct 2011 10:20:58 -0400, Mike Chase wrote: > One more note. I have 16gb of memory on this system so the large heap > really isnt a problem per-se. It is, because you will not be able to get more than 3Gb of virtual memory per process, and when this virtual space gets fragmented (which *does* happen during "long" sessions with tcmalloc and its default release rate), your viewer will crash trying to allocate the next unfragmented space that won't fit its currently allocated but fragmented pool. > I still see occasional exits (with no crashdump so I can't > easily say what exactly is happening). That's exactly what happens when your process tries to use over 3G of memory... Run the viewer under gdb, wait for it to crash and do a backtrace to get the stack trace and see how it crashes during a tcmalloc call for allocating memory... > RSS on my system is 10000 so I'm not coming even close to that. You'll still be stuck with the 3Gb limit per process, thanks to Intel's insane addressing modes and poor intsruction set design... If only IBM had chosen Motorola's 680x0 line of CPUs back in the days when they opted for the 8086, the PCs would have had 32bits OSes with flat memory models from the very start, without weird stuff such as paging, PAE and whatnot !... Today, we are still paying the price of the poor design of the x86 CPUs... > Henri, I'm not saying your wrong (though setting a param outside > the specified operational range for the library doesn't feel like > a *fix* to me). The tcmalloc algorithm for releasing memory is crippled, period. And as I wrote, this is a *workaround* (I never wrote is was a *fix* !). The true fix would be to fix tcmalloc itself, or better, to do without tcmalloc ! > I do believe more testing is needed. Feel free to test harder, but I made my mind on it, and the Cool VL Viewer is already benefitting from my findings. You are of course free to ignore them (I also wrote in my first message: "For what it is worth...", so it's up to you, really). Henri. From mike.chase at alternatemetaverse.com Sun Oct 2 20:13:03 2011 From: mike.chase at alternatemetaverse.com (Mike Chase) Date: Sun, 02 Oct 2011 23:13:03 -0400 Subject: [opensource-dev] Mesh viewers and tcmalloc issues In-Reply-To: <20111002184501.51be06f1.sldev@hotmail.com> References: <20111001222456.498de5e3.sldev@free.fr> <4E87E748.90605@alternatemetaverse.com> <20111002094818.0c82e9da.sldev@free.fr> <4E887169.9080906@alternatemetaverse.com> <4E88734A.7030709@alternatemetaverse.com> <20111002184501.51be06f1.sldev@hotmail.com> Message-ID: <4E89283F.80403@alternatemetaverse.com> On 10/02/2011 12:45 PM, Henri Beauchamp wrote: > On Sun, 02 Oct 2011 10:20:58 -0400, Mike Chase wrote: > >> One more note. I have 16gb of memory on this system so the large heap >> really isnt a problem per-se. > It is, because you will not be able to get more than 3Gb of virtual > memory per process, and when this virtual space gets fragmented (which > *does* happen during "long" sessions with tcmalloc and its default > release rate), your viewer will crash trying to allocate the next > unfragmented space that won't fit its currently allocated but > fragmented pool. Ok, point taken. Even though I'm on a 64bit system the executable is 32 bit so yes, 3gb will be the max memory. And I do see it creep in that direction. It would be nice to have a 64bit native executable. But that path has been tread before. I don't expect to see that any time soon. So what allocator is Firestorm using? It sits around 1.6gb for me where the dev viewer keeps growing. Mike From twisted_laws at hotmail.com Mon Oct 3 07:38:26 2011 From: twisted_laws at hotmail.com (Twisted Laws) Date: Mon, 3 Oct 2011 10:38:26 -0400 Subject: [opensource-dev] Mesh viewers and tcmalloc issues In-Reply-To: <20111001222456.498de5e3.sldev@free.fr> References: <20111001222456.498de5e3.sldev@free.fr> Message-ID: Only thing I don't understand about all this, is if you clone and build viewer-development and 3p-google-perftools, then LL_USE_TCMALLOC is undefined in both. in GooglePerfTools.cmake: set(TCMALLOC_FLAG -ULL_USE_TCMALLOC=1) and in llcommon property pagesUndefine Preprocessor Definitions: LL_USE_TCMALLOC=1So it would appear, at least by default, that tcmalloc is not enabled. Am I understanding this wrong? Or does LL build their viewer with it defined and sending the viewer out the opensource world with it disabled? I did follow Henri's msg and built a viewer with EnvToDouble("TCMALLOC_RELEASE_RATE", 10000.0) (in 3p-google-perftools) and it seems to do exactly the same as without it. Twisted > Date: Sat, 1 Oct 2011 22:24:56 +0200 > From: sldev at free.fr > To: opensource-dev at lists.secondlife.com > Subject: [opensource-dev] Mesh viewers and tcmalloc issues > > Greetings, > > I noticed that all the viewers using tcmalloc (mesh viewers under Linux > and Windows, since those use SSE2 and must gain memory-aligned malloc() > and new() calls that their standard library does not provide) suffer > from a serious problem: they never release memory back to the system, > meaning that after visiting a crowded place and caming around a lot, > the viewer can occupy 2.5Gb of memory, and even after you TP out to a > skybox with almost no objects/textures and no avatar around, the viewer > retains the full amount of alloctaed memory for itself. > > Worst, should you manage to keep the viewer from crashing during a full > hour or so, its allocated memory will get so badly fragmented that it > starts crawling down and finally crashes, even in quiet sims. > > Bao Linden recently worked on private memory pools to work around these > issues, but so far and despite his hard work, the result is less than satisfactory: the memory is still never released to the system, and the > viewers using private memory pools crash every few minutes after issuing > a warning: > "LLPluginProcessParent::poll: apr_pollset_poll failed with status 4 > > Well, be happy since I found an easy work around for these problems > while working on the Cool VL Viewer v1.26.1 (the mesh branch). > > tcmalloc is actually supposed to release back to the system the memory > freed by the application using it, but it does so only after a certain > number of memory blocks have been freed. There is an environment > variable that you can set (TCMALLOC_RELEASE_RATE) to adjust the "rate" > at which tcmalloc will release the freed blocks back to the system. > In fact, this is not really a rate, but a divisor (the number of freed > blocks is divided by the rate number (when != 0: a 0 rate means "never > release memory"), and compared to a threshold. If the number is below > the threshold, the freed blocks are released. > The documentation for tcmalloc says that "Reasonable rates are in the > range [0,10]", but even with a rate of 10, you never get the viewer to > release more than a couple hundreds megabytes for 2+Gb of allocated > memory. It occurred to me that the algorithm tcmalloc uses is simply > crippled ! > > The good news, is that if you pass an "unreasonnable" rate, tcmalloc > will finally release memory (the more "unreasonnable" and the more > memory is released). With a rate of 10000 (yes, ten thousands), you > get the viewer to release everything when it doesn't need it any more, > which matches the behaviour of tcmalloc-less viewers. > > Since the Windows builds don't use a wrapper script to launch the > viewer, it is however best to hardcode this new rate as the default > one in tcmalloc istelf. This is what I did for the Cool VL Viewer > and it works like a charm. There is only one line to change in > tcmalloc source, in src/page_heap.cc: > DEFINE_double(tcmalloc_release_rate, > EnvToDouble("TCMALLOC_RELEASE_RATE", 10000.0), <--- HERE > "Rate at which we release unused memory to the system. " > "Zero means we never release memory back to the system. " > "Increase this flag to return memory faster; decrease it " > "to return memory slower. Reasonable rates are in the " > "range [0,10]"); > > Now, the viewer runs rock stable (just like the non-mesh, tcmalloc-less > version) and uses very reasonnable amounts of memory. It also doesn't > suffer from memory fragmentation any more since it is transparently > taken care of by the OS (via the page table and the PMMU of the CPU, > something neither tcmalloc nor Bao's private memory pool can do since > these are userspace code). > > For what it is worth... > > Henri. > _______________________________________________ > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20111003/3dff96b4/attachment.htm From serpentu at gmail.com Mon Oct 3 09:19:46 2011 From: serpentu at gmail.com (Vaalith Jinn) Date: Mon, 03 Oct 2011 16:19:46 -0000 Subject: [opensource-dev] Review Request: Texture Picker: Making the preview "widget" a little more flexible. In-Reply-To: <20110916091716.23150.54005@domU-12-31-38-00-90-68.compute-1.internal> References: <20110916091716.23150.54005@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20111003161946.26507.50766@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/474/ ----------------------------------------------------------- (Updated Oct. 3, 2011, 9:19 a.m.) Review request for Viewer. Summary (updated) ------- Update: would appreciate a LL yes or no to this, as it's one of the issues that's holding back STORM-64. Texture picker's preview box was never a real widget. It had no XUI presence so the XUI designers had no control over it. Also, it's height depended on the it's parent floater's min size which meant that increasing the min size distorted the preview box, which must be at a 1:1 ratio. I have modified the code in a way that a) makes the preview box no longer reliant on any of the floater's own parameters. b) gives the XUI designers three parameters that affect the preview box specifically: left, top, and size. (size is both the size from left to right, and from top to bottom, keeping it locked to 1:1) The changes are only noticeable to coders and xui designers, not the users. note: It is still not a real widget and it still lacks a follow, layout, delta and any other widget specific abilities. Diffs ----- indra/newview/lltexturectrl.cpp d36e49ee2651 indra/newview/skins/default/xui/en/floater_texture_ctrl.xml d36e49ee2651 Diff: http://codereview.secondlife.com/r/474/diff Testing ------- The box seems to behave exactly as it did before. Changing the indicated left, top, and size values in the appropriate xml file does affect the relevant properties. Thanks, Vaalith -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20111003/d724422a/attachment.htm From kf6kjg at gmail.com Mon Oct 3 10:18:50 2011 From: kf6kjg at gmail.com (Ricky) Date: Mon, 3 Oct 2011 10:18:50 -0700 Subject: [opensource-dev] Web Inspector In-Reply-To: References: Message-ID: Responding to myself... JIRA filed as https://jira.secondlife.com/browse/VWR-27074 "Web Inspector not operable on Mac or Linux" Ricky Cron Stardust On Thu, Sep 22, 2011 at 11:32 PM, Ricky wrote: > I've been aiming to debug a page I wrote for MOAP, and I was hoping to > use the Web Inspector introduced in > http://hg.secondlife.com/viewer-development/changeset/042aa5b6afd9 > where I learnt that I needed to set the MediaPluginDebugging debug > setting to TRUE. ?So I did. ?But on my Mac Mini, it only pops up a > separate window (not a in-the-viewer dialog, but a separate OS-level > dialog window) that has no content, only flat white. > > Are any other platforms able to use it? ?JIRA might be forthcoming, > but I'm going to sleep on it first. ?Tested with 3.0.5.240927. > > My ultimate goal is to find out why the Javascript I wrote, that works > fine under Chrome, Safari, and Firefox, doesn't run correctly in > MOAP... :P > > Thanks for your info, > Ricky > Cron Stardust > > PS. If you don't know how, here's how to both enable and test the Web Inspector: > 1: Enable the MediaPluginDebugging debug setting (Advanced > Show > Debug Settings) > 2: Open the Web Content Browser (Develop > UI > Web Content Browser) > 3: Right-click on the page to open the context menu and select Open > Web Inspector. > > I expected to see http://www.webkit.org/blog/41/introducing-the-web-inspector/ > From moriz.gupte at gmail.com Mon Oct 3 13:17:26 2011 From: moriz.gupte at gmail.com (Moriz Gupte) Date: Mon, 3 Oct 2011 14:17:26 -0600 Subject: [opensource-dev] Mesh viewers and tcmalloc issues In-Reply-To: References: <20111001222456.498de5e3.sldev@free.fr> Message-ID: Am wondering if anyone from Linden Lab can comment on this thread. This is such an important issue regarding mesh viewers and mesh based economy. Many mesh builders are reverting products back to sculpty versions because the majority of clients refuse to use the latest viewers that support mesh because of the significant fps drops. On Mon, Oct 3, 2011 at 8:38 AM, Twisted Laws wrote: > Only thing I don't understand about all this, is if you clone and build > viewer-development and 3p-google-perftools, then LL_USE_TCMALLOC is > undefined in both. > > in GooglePerfTools.cmake: > set(TCMALLOC_FLAG -ULL_USE_TCMALLOC=1) > and in llcommon property pages > Undefine Preprocessor Definitions: LL_USE_TCMALLOC=1 > So it would appear, at least by default, that tcmalloc is not enabled. Am > I understanding this wrong? Or does LL build their viewer with it defined > and sending the viewer out the opensource world with it disabled? > > I did follow Henri's msg and built a viewer with > EnvToDouble("TCMALLOC_RELEASE_RATE", 10000.0) (in 3p-google-perftools) and > it seems to do exactly the same as without it. > > Twisted > > > Date: Sat, 1 Oct 2011 22:24:56 +0200 > > From: sldev at free.fr > > To: opensource-dev at lists.secondlife.com > > Subject: [opensource-dev] Mesh viewers and tcmalloc issues > > > > > Greetings, > > > > I noticed that all the viewers using tcmalloc (mesh viewers under Linux > > and Windows, since those use SSE2 and must gain memory-aligned malloc() > > and new() calls that their standard library does not provide) suffer > > from a serious problem: they never release memory back to the system, > > meaning that after visiting a crowded place and caming around a lot, > > the viewer can occupy 2.5Gb of memory, and even after you TP out to a > > skybox with almost no objects/textures and no avatar around, the viewer > > retains the full amount of alloctaed memory for itself. > > > > Worst, should you manage to keep the viewer from crashing during a full > > hour or so, its allocated memory will get so badly fragmented that it > > starts crawling down and finally crashes, even in quiet sims. > > > > Bao Linden recently worked on private memory pools to work around these > > issues, but so far and despite his hard work, the result is less than > satisfactory: the memory is still never released to the system, and the > > viewers using private memory pools crash every few minutes after issuing > > a warning: > > "LLPluginProcessParent::poll: apr_pollset_poll failed with status 4 > > > > Well, be happy since I found an easy work around for these problems > > while working on the Cool VL Viewer v1.26.1 (the mesh branch). > > > > tcmalloc is actually supposed to release back to the system the memory > > freed by the application using it, but it does so only after a certain > > number of memory blocks have been freed. There is an environment > > variable that you can set (TCMALLOC_RELEASE_RATE) to adjust the "rate" > > at which tcmalloc will release the freed blocks back to the system. > > In fact, this is not really a rate, but a divisor (the number of freed > > blocks is divided by the rate number (when != 0: a 0 rate means "never > > release memory"), and compared to a threshold. If the number is below > > the threshold, the freed blocks are released. > > The documentation for tcmalloc says that "Reasonable rates are in the > > range [0,10]", but even with a rate of 10, you never get the viewer to > > release more than a couple hundreds megabytes for 2+Gb of allocated > > memory. It occurred to me that the algorithm tcmalloc uses is simply > > crippled ! > > > > The good news, is that if you pass an "unreasonnable" rate, tcmalloc > > will finally release memory (the more "unreasonnable" and the more > > memory is released). With a rate of 10000 (yes, ten thousands), you > > get the viewer to release everything when it doesn't need it any more, > > which matches the behaviour of tcmalloc-less viewers. > > > > Since the Windows builds don't use a wrapper script to launch the > > viewer, it is however best to hardcode this new rate as the default > > one in tcmalloc istelf. This is what I did for the Cool VL Viewer > > and it works like a charm. There is only one line to change in > > tcmalloc source, in src/page_heap.cc: > > DEFINE_double(tcmalloc_release_rate, > > EnvToDouble("TCMALLOC_RELEASE_RATE", 10000.0), <--- HERE > > "Rate at which we release unused memory to the system. " > > "Zero means we never release memory back to the system. " > > "Increase this flag to return memory faster; decrease it " > > "to return memory slower. Reasonable rates are in the " > > "range [0,10]"); > > > > Now, the viewer runs rock stable (just like the non-mesh, tcmalloc-less > > version) and uses very reasonnable amounts of memory. It also doesn't > > suffer from memory fragmentation any more since it is transparently > > taken care of by the OS (via the page table and the PMMU of the CPU, > > something neither tcmalloc nor Bao's private memory pool can do since > > these are userspace code). > > > > For what it is worth... > > > > Henri. > > _______________________________________________ > > 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 > -- 'Consider how the lilies grow. They do not labor or spin.' *Rameshsharma Ramloll* PhD, *Research Associate Professor*, Idaho State University, Pocatello, ID 83209 Tel: 208-282-5333 Blog , LinkedIn , Play2Train -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20111003/2e9e8314/attachment.htm From nickyperian at yahoo.com Mon Oct 3 14:32:06 2011 From: nickyperian at yahoo.com (Nicky Perian) Date: Mon, 3 Oct 2011 14:32:06 -0700 (PDT) Subject: [opensource-dev] Mesh viewers and tcmalloc issues In-Reply-To: References: <20111001222456.498de5e3.sldev@free.fr> Message-ID: <1317677526.87825.YahooMailNeo@web43513.mail.sp1.yahoo.com> http://dl.dropbox.com/u/7833186/libtcmalloc_minimal.dll.JPG (build directory image) Is it possible that tcmalloc is used through this dll and the -U and un-define prevent? linking it statically? ________________________________ From: Moriz Gupte To: SLDEV Sent: Monday, October 3, 2011 3:17 PM Subject: Re: [opensource-dev] Mesh viewers and tcmalloc issues Am wondering if anyone from Linden Lab can comment on this thread. This is such an important issue regarding mesh viewers and mesh based economy. Many mesh builders are reverting products back to sculpty versions because the majority of clients refuse to use the latest viewers that support mesh because of the significant fps drops.? On Mon, Oct 3, 2011 at 8:38 AM, Twisted Laws wrote: Only thing I don't understand about all this, is if you clone and build viewer-development and 3p-google-perftools, then LL_USE_TCMALLOC is undefined in both. >? >in GooglePerfTools.cmake: > >set(TCMALLOC_FLAG -ULL_USE_TCMALLOC=1) > >and in llcommon property pages >Undefine Preprocessor Definitions:?LL_USE_TCMALLOC=1So it would appear, at least by default, that tcmalloc is not enabled.?? Am I understanding this wrong?? Or does LL build their viewer with it defined and sending the viewer out the opensource world with it disabled? >? >I did follow Henri's msg and built a viewer with EnvToDouble("TCMALLOC_RELEASE_RATE", 10000.0) (in 3p-google-perftools) and it seems to do exactly the same as without it. >? >Twisted >?> Date: Sat, 1 Oct 2011 22:24:56 +0200 >> From: sldev at free.fr >> To: opensource-dev at lists.secondlife.com >> Subject: [opensource-dev] Mesh viewers and tcmalloc issues > >> >> Greetings, >> >> I noticed that all the viewers using tcmalloc (mesh viewers under Linux >> and Windows, since those use SSE2 and must gain memory-aligned malloc() >> and new() calls that their standard library does not provide) suffer >> from a serious problem: they never release memory back to the system, >> meaning that after visiting a crowded place and caming around a lot, >> the viewer can occupy 2.5Gb of memory, and even after you TP out to a >> skybox with almost no objects/textures and no avatar around, the viewer >> retains the full amount of alloctaed memory for itself. >> >> Worst, should you manage to keep the viewer from crashing during a full >> hour or so, its allocated memory will get so badly fragmented that it >> starts crawling down and finally crashes, even in quiet sims. >> >> Bao Linden recently worked on private memory pools to work around these >> issues, but so far and despite his hard work, the result is less than satisfactory: the memory is still never released to the system, and the >> viewers using private memory pools crash every few minutes after issuing >> a warning: >> "LLPluginProcessParent::poll: apr_pollset_poll failed with status 4 >> >> Well, be happy since I found an easy work around for these problems >> while working on the Cool VL Viewer v1.26.1 (the mesh branch). >> >> tcmalloc is actually supposed to release back to the system the memory >> freed by the application using it, but it does so only after a certain >> number of memory blocks have been freed. There is an environment >> variable that you can set (TCMALLOC_RELEASE_RATE) to adjust the "rate" >> at which tcmalloc will release the freed blocks back to the system. >> In fact, this is not really a rate, but a divisor (the number of freed >> blocks is divided by the rate number (when != 0: a 0 rate means "never >> release memory"), and compared to a threshold. If the number is below >> the threshold, the freed blocks are released. >> The documentation for tcmalloc says that "Reasonable rates are in the >> range [0,10]", but even with a rate of 10, you never get the viewer to >> release more than a couple hundreds megabytes for 2+Gb of allocated >> memory. It occurred to me that the algorithm tcmalloc uses is simply >> crippled ! >> >> The good news, is that if you pass an "unreasonnable" rate, tcmalloc >> will finally release memory (the more "unreasonnable" and the more >> memory is released). With a rate of 10000 (yes, ten thousands), you >> get the viewer to release everything when it doesn't need it any more, >> which matches the behaviour of tcmalloc-less viewers. >> >> Since the Windows builds don't use a wrapper script to launch the >> viewer, it is however best to hardcode this new rate as the default >> one in tcmalloc istelf. This is what I did for the Cool VL Viewer >> and it works like a charm. There is only one line to change in >> tcmalloc source, in src/page_heap.cc: >> DEFINE_double(tcmalloc_release_rate, >> EnvToDouble("TCMALLOC_RELEASE_RATE", 10000.0), <--- HERE >> "Rate at which we release unused memory to the system. " >> "Zero means we never release memory back to the system. " >> "Increase this flag to return memory faster; decrease it " >> "to return memory slower. Reasonable rates are in the " >> "range [0,10]"); >> >> Now, the viewer runs rock stable (just like the non-mesh, tcmalloc-less >> version) and uses very reasonnable amounts of memory. It also doesn't >> suffer from memory fragmentation any more since it is transparently >> taken care of by the OS (via the page table and the PMMU of the CPU, >> something neither tcmalloc nor Bao's private memory pool can do since >> these are userspace code). >> >> For what it is worth... >> >> Henri. >> _______________________________________________ >> 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 > -- 'Consider how the lilies grow. They do not labor or spin.' Rameshsharma Ramloll?PhD,?Research Associate Professor, Idaho State University, Pocatello, ID 83209 Tel: 208-282-5333 Blog,?LinkedIn,?Play2Train _______________________________________________ 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20111003/c35f7cdd/attachment-0001.htm From sl.nicky.ml at googlemail.com Mon Oct 3 14:35:32 2011 From: sl.nicky.ml at googlemail.com (Nicky D.) Date: Mon, 3 Oct 2011 23:35:32 +0200 Subject: [opensource-dev] Mesh viewers and tcmalloc issues In-Reply-To: References: <20111001222456.498de5e3.sldev@free.fr> Message-ID: > in GooglePerfTools.cmake: > set(TCMALLOC_FLAG -ULL_USE_TCMALLOC=1) > and in llcommon property pages > Undefine Preprocessor Definitions:?LL_USE_TCMALLOC=1 > So it would appear, at least by default, that tcmalloc is not enabled.?? Am > I understanding this wrong?? Or does LL build their viewer with it defined > and sending the viewer out the opensource world with it disabled? > That define is really only used for some statics code in llallocator.cpp. It does not influence if tcmalloc is used or not. From armin.weatherwax at googlemail.com Mon Oct 3 15:50:46 2011 From: armin.weatherwax at googlemail.com (Armin Weatherwax) Date: Tue, 4 Oct 2011 00:50:46 +0200 Subject: [opensource-dev] Mesh viewers and tcmalloc issues In-Reply-To: References: <20111001222456.498de5e3.sldev@free.fr> Message-ID: <201110040050.47007.Armin.Weatherwax@googlemail.com> > That define is really only used for some statics code in > llallocator.cpp. It does > not influence if tcmalloc is used or not. its not clear where/why/when it is used - any code path includuing tcmalloc on linux 32bit isn't compiled, though the viewer crashes if it isn't linked, which in my opinion at least needs a comment *that* just linking it makes a difference. Even better would be a comment with e.g. a link to furher information about *why* just linking it makes a difference. For Linux 64bit not linking tcmalloc makes no difference (anything is aligned anyway, and I didn't see any difference in speed). Armin From Lance.Corrimal at eregion.de Tue Oct 4 00:31:00 2011 From: Lance.Corrimal at eregion.de (Lance Corrimal) Date: Tue, 4 Oct 2011 09:31:00 +0200 Subject: [opensource-dev] how to read minidumps Message-ID: <201110040931.00928.Lance.Corrimal@eregion.de> hi, I'm pretty sure noone at LL is interested in the minidumps from my TPV, so I'll have to read them myself... how do i do that? bye, LC From thickbrick.sleaford at gmail.com Tue Oct 4 03:23:51 2011 From: thickbrick.sleaford at gmail.com (Thickbrick Sleaford) Date: Tue, 4 Oct 2011 12:23:51 +0200 Subject: [opensource-dev] how to read minidumps In-Reply-To: <201110040931.00928.Lance.Corrimal@eregion.de> References: <201110040931.00928.Lance.Corrimal@eregion.de> Message-ID: <201110041223.52309.thickbrick.sleaford@gmail.com> On Tuesday 04 October 2011 09:31:00 Lance Corrimal wrote: > hi, > > I'm pretty sure noone at LL is interested in the minidumps from my > TPV, so I'll have to read them myself... how do i do that? > At least on the Linux side, breakpad provides minidump_stackwalk, which takes a minidump file and a symbols file and produces a stack trace. That executable is not provided with the linden-packaged breakpad though. You will also need to make sure the symbols file you are using is from the same build that produced the minidump. See http://code.google.com/p/google- breakpad/wiki/LinuxStarterGuide#Processing_the_minidump_to_produce_a_stack_trace -- Thickbrick From oz at lindenlab.com Tue Oct 4 07:26:22 2011 From: oz at lindenlab.com (Oz Linden) Date: Tue, 04 Oct 2011 14:26:22 -0000 Subject: [opensource-dev] Review Request: Texture Picker: Making the preview "widget" a little more flexible. In-Reply-To: <20111003161946.26507.50766@domU-12-31-38-00-90-68.compute-1.internal> References: <20111003161946.26507.50766@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20111004142622.26507.32623@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/474/ ----------------------------------------------------------- (Updated Oct. 4, 2011, 7:26 a.m.) Review request for Viewer and Richard Nelson. Summary ------- Update: would appreciate a LL yes or no to this, as it's one of the issues that's holding back STORM-64. Texture picker's preview box was never a real widget. It had no XUI presence so the XUI designers had no control over it. Also, it's height depended on the it's parent floater's min size which meant that increasing the min size distorted the preview box, which must be at a 1:1 ratio. I have modified the code in a way that a) makes the preview box no longer reliant on any of the floater's own parameters. b) gives the XUI designers three parameters that affect the preview box specifically: left, top, and size. (size is both the size from left to right, and from top to bottom, keeping it locked to 1:1) The changes are only noticeable to coders and xui designers, not the users. note: It is still not a real widget and it still lacks a follow, layout, delta and any other widget specific abilities. Diffs ----- indra/newview/lltexturectrl.cpp d36e49ee2651 indra/newview/skins/default/xui/en/floater_texture_ctrl.xml d36e49ee2651 Diff: http://codereview.secondlife.com/r/474/diff Testing ------- The box seems to behave exactly as it did before. Changing the indicated left, top, and size values in the appropriate xml file does affect the relevant properties. Thanks, Vaalith -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20111004/2521a889/attachment.htm From sldev at free.fr Tue Oct 4 08:08:54 2011 From: sldev at free.fr (Henri Beauchamp) Date: Tue, 4 Oct 2011 17:08:54 +0200 Subject: [opensource-dev] how to read minidumps In-Reply-To: <201110041223.52309.thickbrick.sleaford@gmail.com> References: <201110040931.00928.Lance.Corrimal@eregion.de> <201110041223.52309.thickbrick.sleaford@gmail.com> Message-ID: <20111004170854.b90ad622.sldev@free.fr> On Tue, 4 Oct 2011 12:23:51 +0200, Thickbrick Sleaford wrote: > On Tuesday 04 October 2011 09:31:00 Lance Corrimal wrote: > > hi, > > > > I'm pretty sure noone at LL is interested in the minidumps from my > > TPV, so I'll have to read them myself... how do i do that? > > At least on the Linux side, breakpad provides minidump_stackwalk, > which takes a minidump file and a symbols file and produces a stack > trace. That executable is not provided with the linden-packaged > breakpad though. You will also need to make sure the symbols file > you are using is from the same build that produced the minidump. We've got a saying for this kind of silliness, in France: "Pourquoi faire simple quand on peut faire compliqu? ?" ("Why doing it the simple way when you can find a complex way to do it ?") I guess the stack_trace.log file what just too simple in LL's view... * rolls eyes and shakes head, sighing deeply * Henri. From mike.chase at alternatemetaverse.com Tue Oct 4 08:32:55 2011 From: mike.chase at alternatemetaverse.com (Mike Chase) Date: Tue, 04 Oct 2011 11:32:55 -0400 Subject: [opensource-dev] Mesh viewers and tcmalloc issues In-Reply-To: <20111002184501.51be06f1.sldev@hotmail.com> References: <20111001222456.498de5e3.sldev@free.fr> <4E87E748.90605@alternatemetaverse.com> <20111002094818.0c82e9da.sldev@free.fr> <4E887169.9080906@alternatemetaverse.com> <4E88734A.7030709@alternatemetaverse.com> <20111002184501.51be06f1.sldev@hotmail.com> Message-ID: <4E8B2727.7080704@alternatemetaverse.com> On 10/02/2011 12:45 PM, Henri Beauchamp wrote: > On Sun, 02 Oct 2011 10:20:58 -0400, Mike Chase wrote: > >> One more note. I have 16gb of memory on this system so the large heap >> really isnt a problem per-se. > It is, because you will not be able to get more than 3Gb of virtual > memory per process, and when this virtual space gets fragmented (which > *does* happen during "long" sessions with tcmalloc and its default > release rate), your viewer will crash trying to allocate the next > unfragmented space that won't fit its currently allocated but > fragmented pool. Is there a JIRA filed for this somewhere I can follow? In the meantime I may try running the heap profiler. I beginning to suspect not so much the allocator and more so a memory leak somewhere. Mike From marinekelley at gmail.com Tue Oct 4 08:55:17 2011 From: marinekelley at gmail.com (Marine Kelley) Date: Tue, 4 Oct 2011 17:55:17 +0200 Subject: [opensource-dev] how to read minidumps In-Reply-To: <20111004170854.b90ad622.sldev@free.fr> References: <201110040931.00928.Lance.Corrimal@eregion.de> <201110041223.52309.thickbrick.sleaford@gmail.com> <20111004170854.b90ad622.sldev@free.fr> Message-ID: The Shadok is strong in this one... On 04/10/2011, Henri Beauchamp wrote: > On Tue, 4 Oct 2011 12:23:51 +0200, Thickbrick Sleaford wrote: > >> On Tuesday 04 October 2011 09:31:00 Lance Corrimal wrote: >> > hi, >> > >> > I'm pretty sure noone at LL is interested in the minidumps from my >> > TPV, so I'll have to read them myself... how do i do that? >> >> At least on the Linux side, breakpad provides minidump_stackwalk, >> which takes a minidump file and a symbols file and produces a stack >> trace. That executable is not provided with the linden-packaged >> breakpad though. You will also need to make sure the symbols file >> you are using is from the same build that produced the minidump. > > We've got a saying for this kind of silliness, in France: > "Pourquoi faire simple quand on peut faire compliqu? ?" > ("Why doing it the simple way when you can find a complex way to > do it ?") > > I guess the stack_trace.log file what just too simple in LL's view... > * rolls eyes and shakes head, sighing deeply * > > Henri. > _______________________________________________ > 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 > From oz at lindenlab.com Tue Oct 4 08:55:45 2011 From: oz at lindenlab.com (Oz Linden (Scott Lawrence)) Date: Tue, 04 Oct 2011 11:55:45 -0400 Subject: [opensource-dev] Mesh viewers and tcmalloc issues In-Reply-To: References: <20111001222456.498de5e3.sldev@free.fr> Message-ID: <4E8B2C81.8030907@lindenlab.com> On 2011-10-03 16:17, Moriz Gupte wrote: > Am wondering if anyone from Linden Lab can comment on this thread. > This is such an important issue regarding mesh viewers and mesh based > economy. Many mesh builders are reverting products back to sculpty > versions because the majority of clients refuse to use the latest > viewers that support mesh because of the significant fps drops. I'm just getting caught up on the list after a few days spent firefighting.... will bring it to the attention of the mesh team. From oz at lindenlab.com Tue Oct 4 09:16:28 2011 From: oz at lindenlab.com (Oz Linden (Scott Lawrence)) Date: Tue, 04 Oct 2011 12:16:28 -0400 Subject: [opensource-dev] Open Development User Group schedule change Message-ID: <4E8B315C.3080606@lindenlab.com> I've moved my Wednesday afternoon UG meeting to Tuesday, and a half hour later.... See https://wiki.secondlife.com/wiki/Project_Snowstorm/Calendar From log at lindenlab.com Tue Oct 4 10:23:53 2011 From: log at lindenlab.com (Log Linden) Date: Tue, 04 Oct 2011 17:23:53 -0000 Subject: [opensource-dev] Review Request: Enable legacy viewer C++ tests in indra/test. In-Reply-To: <20110919192314.965.39027@domU-12-31-38-00-90-68.compute-1.internal> References: <20110919192314.965.39027@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20111004172353.26378.34725@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/479/ ----------------------------------------------------------- (Updated Oct. 4, 2011, 10:23 a.m.) Review request for Viewer and Nat Goodspeed. Changes ------- Added JIRA and repo containing the changes. Summary ------- As part of the Linden Lab automation hackathon, I finally had time to re-enable the tests located in the indra/test directory. These tests are currently not being built or run as part of a standard viewer build and haven't at least since we switched over from subversion. I copied over a few tests from the corresponding server test repository and also fixed some tests that had been rendered unbuildable by various code changes to the viewer. These tests can be disabled from running (but not building) by disabling the standard LL_TESTS cmake configuration variable. llevents_tut.cpp proved to be an interesting challenge to get to pass on our Linux build servers. With the Debian Lenny version of the gcc build toolchain, if an exception is located in a different dynamic library (.so) file as the code that is causing the exception, the exception will not be caught. My workaround was borrowed from the llmessage unit tests and expanded upon to allow the monitoring of the string from the caught exception. This addresses bug STORM-1634. http://jira.secondlife.com/browse/STORM-1634 Diffs ----- indra/test/llevents_tut.cpp 656d988266e8 indra/test/llapp_tut.cpp PRE-CREATION indra/CMakeLists.txt 656d988266e8 indra/test/CMakeLists.txt 656d988266e8 indra/test/io.cpp 656d988266e8 indra/test/llhttpclient_tut.cpp 656d988266e8 indra/test/lliohttpserver_tut.cpp 656d988266e8 indra/test/llsd_new_tut.cpp 656d988266e8 indra/test/llsdmessagebuilder_tut.cpp 656d988266e8 indra/test/lltemplatemessagebuilder_tut.cpp 656d988266e8 Diff: http://codereview.secondlife.com/r/479/diff Testing ------- I built and ran this code on recent versions of all three platforms with no error. When it failed to build in teamcity, I also built it on a lenny system by hand until I had fixed the exception handling issue, then ran all of the tests 100 times in a row on the same lenny machine with no test failures. The tests have run successfully in Teamcity for each revision since the fix for the exception handling code. Thanks, Log -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20111004/e12197a2/attachment.htm From richard at lindenlab.com Tue Oct 4 12:08:44 2011 From: richard at lindenlab.com (Richard Nelson) Date: Tue, 04 Oct 2011 19:08:44 -0000 Subject: [opensource-dev] Review Request: Texture Picker: Making the preview "widget" a little more flexible. In-Reply-To: <20111004142622.26507.32623@domU-12-31-38-00-90-68.compute-1.internal> References: <20111004142622.26507.32623@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20111004190844.26382.9675@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/474/#review1041 ----------------------------------------------------------- Please do not use localization strings to parameterize a widget. Better to use a place holder and then call getChildView on it and use the rect of that view for displaying the texture preview. - Richard On Oct. 4, 2011, 7:26 a.m., Vaalith Jinn wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/474/ > ----------------------------------------------------------- > > (Updated Oct. 4, 2011, 7:26 a.m.) > > > Review request for Viewer and Richard Nelson. > > > Summary > ------- > > Update: would appreciate a LL yes or no to this, as it's one of the issues that's holding back STORM-64. > > > Texture picker's preview box was never a real widget. It had no XUI presence so the XUI designers had no control over it. > Also, it's height depended on the it's parent floater's min size which meant that increasing the min size distorted the preview box, > which must be at a 1:1 ratio. > > I have modified the code in a way that > a) makes the preview box no longer reliant on any of the floater's own parameters. > b) gives the XUI designers three parameters that affect the preview box specifically: left, top, and size. > (size is both the size from left to right, and from top to bottom, keeping it locked to 1:1) > > The changes are only noticeable to coders and xui designers, not the users. > note: It is still not a real widget and it still lacks a follow, layout, delta and any other widget specific abilities. > > > Diffs > ----- > > indra/newview/lltexturectrl.cpp d36e49ee2651 > indra/newview/skins/default/xui/en/floater_texture_ctrl.xml d36e49ee2651 > > Diff: http://codereview.secondlife.com/r/474/diff > > > Testing > ------- > > The box seems to behave exactly as it did before. > Changing the indicated left, top, and size values in the appropriate xml file does affect the relevant properties. > > > Thanks, > > Vaalith > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20111004/591a3194/attachment.htm From nexiim at gmail.com Tue Oct 4 13:40:49 2011 From: nexiim at gmail.com (Nexii Malthus) Date: Tue, 4 Oct 2011 21:40:49 +0100 Subject: [opensource-dev] how to read minidumps In-Reply-To: References: <201110040931.00928.Lance.Corrimal@eregion.de> <201110041223.52309.thickbrick.sleaford@gmail.com> <20111004170854.b90ad622.sldev@free.fr> Message-ID: You can read the google breakpad generated dumps straight into visual studio. I wasted so much time trying to get minidump_stackwalk and all that on windows and they don't tell you that you can just use visual studio. I got crash logging working on my own TPV, I send the reports to my own crash logging server which accumulates them and provides me an interface to check out minidumps and logs. - Nexii Malthus On Tue, Oct 4, 2011 at 4:55 PM, Marine Kelley wrote: > The Shadok is strong in this one... > > On 04/10/2011, Henri Beauchamp wrote: > > On Tue, 4 Oct 2011 12:23:51 +0200, Thickbrick Sleaford wrote: > > > >> On Tuesday 04 October 2011 09:31:00 Lance Corrimal wrote: > >> > hi, > >> > > >> > I'm pretty sure noone at LL is interested in the minidumps from my > >> > TPV, so I'll have to read them myself... how do i do that? > >> > >> At least on the Linux side, breakpad provides minidump_stackwalk, > >> which takes a minidump file and a symbols file and produces a stack > >> trace. That executable is not provided with the linden-packaged > >> breakpad though. You will also need to make sure the symbols file > >> you are using is from the same build that produced the minidump. > > > > We've got a saying for this kind of silliness, in France: > > "Pourquoi faire simple quand on peut faire compliqu? ?" > > ("Why doing it the simple way when you can find a complex way to > > do it ?") > > > > I guess the stack_trace.log file what just too simple in LL's view... > > * rolls eyes and shakes head, sighing deeply * > > > > Henri. > > _______________________________________________ > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20111004/d291cf81/attachment.htm From Lance.Corrimal at eregion.de Tue Oct 4 13:51:59 2011 From: Lance.Corrimal at eregion.de (Lance Corrimal) Date: Tue, 4 Oct 2011 22:51:59 +0200 Subject: [opensource-dev] how to read minidumps In-Reply-To: References: <201110040931.00928.Lance.Corrimal@eregion.de> Message-ID: <201110042252.00117.Lance.Corrimal@eregion.de> omgwtf i want. we gotta talk and soon. bye, LC Am Dienstag, 4. Oktober 2011 schrieb Nexii Malthus: > You can read the google breakpad generated dumps straight into > visual studio. I wasted so much time trying to get > minidump_stackwalk and all that on windows and they don't tell you > that you can just use visual studio. > > I got crash logging working on my own TPV, I send the reports to my > own crash logging server which accumulates them and provides me an > interface to check out minidumps and logs. > > - Nexii Malthus > > On Tue, Oct 4, 2011 at 4:55 PM, Marine Kelley wrote: > > The Shadok is strong in this one... > > > > On 04/10/2011, Henri Beauchamp wrote: > > > On Tue, 4 Oct 2011 12:23:51 +0200, Thickbrick Sleaford wrote: > > >> On Tuesday 04 October 2011 09:31:00 Lance Corrimal wrote: > > >> > hi, > > >> > > > >> > I'm pretty sure noone at LL is interested in the minidumps > > >> > from my TPV, so I'll have to read them myself... how do i > > >> > do that? > > >> > > >> At least on the Linux side, breakpad provides > > >> minidump_stackwalk, which takes a minidump file and a symbols > > >> file and produces a stack trace. That executable is not > > >> provided with the linden-packaged breakpad though. You will > > >> also need to make sure the symbols file you are using is from > > >> the same build that produced the minidump. > > > > > > We've got a saying for this kind of silliness, in France: > > > "Pourquoi faire simple quand on peut faire compliqu? ?" > > > ("Why doing it the simple way when you can find a complex way > > > to do it ?") > > > > > > I guess the stack_trace.log file what just too simple in LL's > > > view... * rolls eyes and shakes head, sighing deeply * > > > > > > Henri. > > > _______________________________________________ > > > 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 From stone at lindenlab.com Tue Oct 4 15:08:10 2011 From: stone at lindenlab.com (Stone Linden) Date: Tue, 04 Oct 2011 22:08:10 -0000 Subject: [opensource-dev] Review Request: VWR-27090 Allow Calling Cards to carry the "(link)" suffix in the Inventory pane Message-ID: <20111004220810.26381.82104@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/487/ ----------------------------------------------------------- Review request for Viewer. Summary ------- Move the test for whether an item is a link outside of the test for whether an item is a calling card. This allows calling card links to carry the "(link)" suffix, but continues to deny them the "(nomod) (nocopy)" suffixes. This addresses bug VWR-27090. http://jira.secondlife.com/browse/VWR-27090 Diffs ----- indra/newview/llinventorybridge.cpp 88cf7d9a9d31 Diff: http://codereview.secondlife.com/r/487/diff Testing ------- Compiles cleanly. Shows Calling Card links with "(link)" suffix. Thanks, Stone -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20111004/ecf7b217/attachment.htm From sldev at free.fr Tue Oct 4 15:55:25 2011 From: sldev at free.fr (Henri Beauchamp) Date: Wed, 5 Oct 2011 00:55:25 +0200 Subject: [opensource-dev] how to read minidumps In-Reply-To: References: <201110040931.00928.Lance.Corrimal@eregion.de> <201110041223.52309.thickbrick.sleaford@gmail.com> <20111004170854.b90ad622.sldev@free.fr> Message-ID: <20111005005525.eea9a027.sldev@free.fr> On Tue, 4 Oct 2011 21:40:49 +0100, Nexii Malthus wrote: > You can read the google breakpad generated dumps straight into visual > studio. Excepted that I develop under Linux and that the stack_trace.log file doesn't need any thrid party program neither any symbols table to tell you excatly what went wrong at the first glance... From serpentu at gmail.com Tue Oct 4 20:11:32 2011 From: serpentu at gmail.com (Vaalith Jinn) Date: Wed, 05 Oct 2011 03:11:32 -0000 Subject: [opensource-dev] Review Request: Texture Picker: Making the preview "widget" a little more flexible. In-Reply-To: <20111004142622.26507.32623@domU-12-31-38-00-90-68.compute-1.internal> References: <20111004142622.26507.32623@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20111005031132.26382.13386@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/474/ ----------------------------------------------------------- (Updated Oct. 4, 2011, 8:11 p.m.) Review request for Viewer and Richard Nelson. Changes ------- I've also considered hijacking an actual widget's rect but was not aware i could just use "view", that simplifies things! Just tested this new diff, seems to work and even seems to follow. Summary ------- Update: would appreciate a LL yes or no to this, as it's one of the issues that's holding back STORM-64. Texture picker's preview box was never a real widget. It had no XUI presence so the XUI designers had no control over it. Also, it's height depended on the it's parent floater's min size which meant that increasing the min size distorted the preview box, which must be at a 1:1 ratio. I have modified the code in a way that a) makes the preview box no longer reliant on any of the floater's own parameters. b) gives the XUI designers three parameters that affect the preview box specifically: left, top, and size. (size is both the size from left to right, and from top to bottom, keeping it locked to 1:1) The changes are only noticeable to coders and xui designers, not the users. note: It is still not a real widget and it still lacks a follow, layout, delta and any other widget specific abilities. Diffs (updated) ----- indra/newview/lltexturectrl.cpp d36e49ee2651 indra/newview/skins/default/xui/en/floater_texture_ctrl.xml d36e49ee2651 Diff: http://codereview.secondlife.com/r/474/diff Testing ------- The box seems to behave exactly as it did before. Changing the indicated left, top, and size values in the appropriate xml file does affect the relevant properties. Thanks, Vaalith -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20111005/13114d7d/attachment-0001.htm From richard at lindenlab.com Wed Oct 5 00:03:12 2011 From: richard at lindenlab.com (Richard Nelson) Date: Wed, 05 Oct 2011 07:03:12 -0000 Subject: [opensource-dev] Review Request: Texture Picker: Making the preview "widget" a little more flexible. In-Reply-To: <20111005031132.26382.13386@domU-12-31-38-00-90-68.compute-1.internal> References: <20111005031132.26382.13386@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20111005070312.26380.18343@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/474/#review1042 ----------------------------------------------------------- Ship it! thanks, looks good! - Richard On Oct. 4, 2011, 8:11 p.m., Vaalith Jinn wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/474/ > ----------------------------------------------------------- > > (Updated Oct. 4, 2011, 8:11 p.m.) > > > Review request for Viewer and Richard Nelson. > > > Summary > ------- > > Update: would appreciate a LL yes or no to this, as it's one of the issues that's holding back STORM-64. > > > Texture picker's preview box was never a real widget. It had no XUI presence so the XUI designers had no control over it. > Also, it's height depended on the it's parent floater's min size which meant that increasing the min size distorted the preview box, > which must be at a 1:1 ratio. > > I have modified the code in a way that > a) makes the preview box no longer reliant on any of the floater's own parameters. > b) gives the XUI designers three parameters that affect the preview box specifically: left, top, and size. > (size is both the size from left to right, and from top to bottom, keeping it locked to 1:1) > > The changes are only noticeable to coders and xui designers, not the users. > note: It is still not a real widget and it still lacks a follow, layout, delta and any other widget specific abilities. > > > Diffs > ----- > > indra/newview/lltexturectrl.cpp d36e49ee2651 > indra/newview/skins/default/xui/en/floater_texture_ctrl.xml d36e49ee2651 > > Diff: http://codereview.secondlife.com/r/474/diff > > > Testing > ------- > > The box seems to behave exactly as it did before. > Changing the indicated left, top, and size values in the appropriate xml file does affect the relevant properties. > > > Thanks, > > Vaalith > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20111005/98ea7bfe/attachment.htm From nat at lindenlab.com Wed Oct 5 10:42:00 2011 From: nat at lindenlab.com (Nat Goodspeed) Date: Wed, 05 Oct 2011 17:42:00 -0000 Subject: [opensource-dev] Review Request: Enable legacy viewer C++ tests in indra/test. In-Reply-To: <20111004172353.26378.34725@domU-12-31-38-00-90-68.compute-1.internal> References: <20111004172353.26378.34725@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20111005174200.26508.39747@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/479/#review1043 ----------------------------------------------------------- indra/test/llsd_new_tut.cpp Thumbs up for solving this up at the top rather than cluttering code inline. But I think I'd rather see 'using std::fpclassify;' on non-Windows, then put this local fpclassify() in the local namespace, and skip the std:: prefix when calling fpclassify() below. indra/test/llsd_new_tut.cpp Hmm, where did this code come from? Server side? indra/test/llsdmessagebuilder_tut.cpp Srsly?? I'd much rather see the definition of _PREHASH_Test0 et al. change to make this work. Are those local? - Nat On Oct. 4, 2011, 10:23 a.m., Log Linden wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/479/ > ----------------------------------------------------------- > > (Updated Oct. 4, 2011, 10:23 a.m.) > > > Review request for Viewer and Nat Goodspeed. > > > Summary > ------- > > As part of the Linden Lab automation hackathon, I finally had time to re-enable the tests located in the indra/test directory. These tests are currently not being built or run as part of a standard viewer build and haven't at least since we switched over from subversion. I copied over a few tests from the corresponding server test repository and also fixed some tests that had been rendered unbuildable by various code changes to the viewer. These tests can be disabled from running (but not building) by disabling the standard LL_TESTS cmake configuration variable. > > llevents_tut.cpp proved to be an interesting challenge to get to pass on our Linux build servers. With the Debian Lenny version of the gcc build toolchain, if an exception is located in a different dynamic library (.so) file as the code that is causing the exception, the exception will not be caught. My workaround was borrowed from the llmessage unit tests and expanded upon to allow the monitoring of the string from the caught exception. > > > This addresses bug STORM-1634. > http://jira.secondlife.com/browse/STORM-1634 > > > Diffs > ----- > > indra/test/llevents_tut.cpp 656d988266e8 > indra/test/llapp_tut.cpp PRE-CREATION > indra/CMakeLists.txt 656d988266e8 > indra/test/CMakeLists.txt 656d988266e8 > indra/test/io.cpp 656d988266e8 > indra/test/llhttpclient_tut.cpp 656d988266e8 > indra/test/lliohttpserver_tut.cpp 656d988266e8 > indra/test/llsd_new_tut.cpp 656d988266e8 > indra/test/llsdmessagebuilder_tut.cpp 656d988266e8 > indra/test/lltemplatemessagebuilder_tut.cpp 656d988266e8 > > Diff: http://codereview.secondlife.com/r/479/diff > > > Testing > ------- > > I built and ran this code on recent versions of all three platforms with no error. When it failed to build in teamcity, I also built it on a lenny system by hand until I had fixed the exception handling issue, then ran all of the tests 100 times in a row on the same lenny machine with no test failures. The tests have run successfully in Teamcity for each revision since the fix for the exception handling code. > > > Thanks, > > Log > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20111005/ceb8936b/attachment.htm From log at lindenlab.com Wed Oct 5 13:17:36 2011 From: log at lindenlab.com (Log Linden) Date: Wed, 05 Oct 2011 20:17:36 -0000 Subject: [opensource-dev] Review Request: Enable legacy viewer C++ tests in indra/test. In-Reply-To: <20111005174200.26508.39747@domU-12-31-38-00-90-68.compute-1.internal> References: <20111005174200.26508.39747@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20111005201736.26376.40527@domU-12-31-38-00-90-68.compute-1.internal> > On Oct. 5, 2011, 10:42 a.m., Nat Goodspeed wrote: > > indra/test/llsd_new_tut.cpp, line 762 > > > > > > Hmm, where did this code come from? Server side? Yep, that version of this test seemed to be newer and fixed some of the disabled or failing tests (can't remember exactly, it's been almost a month!). > On Oct. 5, 2011, 10:42 a.m., Nat Goodspeed wrote: > > indra/test/llsdmessagebuilder_tut.cpp, line 87 > > > > > > Srsly?? I'd much rather see the definition of _PREHASH_Test0 et al. change to make this work. Are those local? Nope, they're in indra/llmessage/message_prehash.h. I could change the parameter const-ness in LLMessageBlock* createBlock, but I think I would also have to change LLMessageBlock::addVariable which is in llmessagetemplate.h. > On Oct. 5, 2011, 10:42 a.m., Nat Goodspeed wrote: > > indra/test/llsd_new_tut.cpp, line 37 > > > > > > Thumbs up for solving this up at the top rather than cluttering code inline. But I think I'd rather see 'using std::fpclassify;' on non-Windows, then put this local fpclassify() in the local namespace, and skip the std:: prefix when calling fpclassify() below. Thumbs up goes to whomever fixed this on the server. Fixed it on the viewer according to your recommendation, I agree that it's cleaner. - Log ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/479/#review1043 ----------------------------------------------------------- On Oct. 4, 2011, 10:23 a.m., Log Linden wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/479/ > ----------------------------------------------------------- > > (Updated Oct. 4, 2011, 10:23 a.m.) > > > Review request for Viewer and Nat Goodspeed. > > > Summary > ------- > > As part of the Linden Lab automation hackathon, I finally had time to re-enable the tests located in the indra/test directory. These tests are currently not being built or run as part of a standard viewer build and haven't at least since we switched over from subversion. I copied over a few tests from the corresponding server test repository and also fixed some tests that had been rendered unbuildable by various code changes to the viewer. These tests can be disabled from running (but not building) by disabling the standard LL_TESTS cmake configuration variable. > > llevents_tut.cpp proved to be an interesting challenge to get to pass on our Linux build servers. With the Debian Lenny version of the gcc build toolchain, if an exception is located in a different dynamic library (.so) file as the code that is causing the exception, the exception will not be caught. My workaround was borrowed from the llmessage unit tests and expanded upon to allow the monitoring of the string from the caught exception. > > > This addresses bug STORM-1634. > http://jira.secondlife.com/browse/STORM-1634 > > > Diffs > ----- > > indra/test/llevents_tut.cpp 656d988266e8 > indra/test/llapp_tut.cpp PRE-CREATION > indra/CMakeLists.txt 656d988266e8 > indra/test/CMakeLists.txt 656d988266e8 > indra/test/io.cpp 656d988266e8 > indra/test/llhttpclient_tut.cpp 656d988266e8 > indra/test/lliohttpserver_tut.cpp 656d988266e8 > indra/test/llsd_new_tut.cpp 656d988266e8 > indra/test/llsdmessagebuilder_tut.cpp 656d988266e8 > indra/test/lltemplatemessagebuilder_tut.cpp 656d988266e8 > > Diff: http://codereview.secondlife.com/r/479/diff > > > Testing > ------- > > I built and ran this code on recent versions of all three platforms with no error. When it failed to build in teamcity, I also built it on a lenny system by hand until I had fixed the exception handling issue, then ran all of the tests 100 times in a row on the same lenny machine with no test failures. The tests have run successfully in Teamcity for each revision since the fix for the exception handling code. > > > Thanks, > > Log > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20111005/6b46f871/attachment.htm From nat at lindenlab.com Wed Oct 5 13:46:31 2011 From: nat at lindenlab.com (Nat Goodspeed) Date: Wed, 05 Oct 2011 20:46:31 -0000 Subject: [opensource-dev] Review Request: Enable legacy viewer C++ tests in indra/test. In-Reply-To: <20111005174200.26508.39747@domU-12-31-38-00-90-68.compute-1.internal> References: <20111005174200.26508.39747@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20111005204631.26590.56047@domU-12-31-38-00-90-68.compute-1.internal> > On Oct. 5, 2011, 10:42 a.m., Nat Goodspeed wrote: > > indra/test/llsdmessagebuilder_tut.cpp, line 87 > > > > > > Srsly?? I'd much rather see the definition of _PREHASH_Test0 et al. change to make this work. Are those local? > > Log Linden wrote: > Nope, they're in indra/llmessage/message_prehash.h. I could change the parameter const-ness in LLMessageBlock* createBlock, but I think I would also have to change LLMessageBlock::addVariable which is in llmessagetemplate.h. Sigh, no, I would not advocate changing stuff in llmessage. I think that could open the door to a world of hurt... But if _PREHASH_Test[01] are defined the same as the rest of the _PREHASH_Nonsense, how is it that the viewer build in general gets away with passing _PREHASH_Nonsense items to these methods without requiring similar ugly const_cast() casts? - Nat ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/479/#review1043 ----------------------------------------------------------- On Oct. 4, 2011, 10:23 a.m., Log Linden wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/479/ > ----------------------------------------------------------- > > (Updated Oct. 4, 2011, 10:23 a.m.) > > > Review request for Viewer and Nat Goodspeed. > > > Summary > ------- > > As part of the Linden Lab automation hackathon, I finally had time to re-enable the tests located in the indra/test directory. These tests are currently not being built or run as part of a standard viewer build and haven't at least since we switched over from subversion. I copied over a few tests from the corresponding server test repository and also fixed some tests that had been rendered unbuildable by various code changes to the viewer. These tests can be disabled from running (but not building) by disabling the standard LL_TESTS cmake configuration variable. > > llevents_tut.cpp proved to be an interesting challenge to get to pass on our Linux build servers. With the Debian Lenny version of the gcc build toolchain, if an exception is located in a different dynamic library (.so) file as the code that is causing the exception, the exception will not be caught. My workaround was borrowed from the llmessage unit tests and expanded upon to allow the monitoring of the string from the caught exception. > > > This addresses bug STORM-1634. > http://jira.secondlife.com/browse/STORM-1634 > > > Diffs > ----- > > indra/test/llevents_tut.cpp 656d988266e8 > indra/test/llapp_tut.cpp PRE-CREATION > indra/CMakeLists.txt 656d988266e8 > indra/test/CMakeLists.txt 656d988266e8 > indra/test/io.cpp 656d988266e8 > indra/test/llhttpclient_tut.cpp 656d988266e8 > indra/test/lliohttpserver_tut.cpp 656d988266e8 > indra/test/llsd_new_tut.cpp 656d988266e8 > indra/test/llsdmessagebuilder_tut.cpp 656d988266e8 > indra/test/lltemplatemessagebuilder_tut.cpp 656d988266e8 > > Diff: http://codereview.secondlife.com/r/479/diff > > > Testing > ------- > > I built and ran this code on recent versions of all three platforms with no error. When it failed to build in teamcity, I also built it on a lenny system by hand until I had fixed the exception handling issue, then ran all of the tests 100 times in a row on the same lenny machine with no test failures. The tests have run successfully in Teamcity for each revision since the fix for the exception handling code. > > > Thanks, > > Log > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20111005/177095d3/attachment-0001.htm From Lance.Corrimal at eregion.de Thu Oct 6 06:32:17 2011 From: Lance.Corrimal at eregion.de (Lance Corrimal) Date: Thu, 6 Oct 2011 15:32:17 +0200 Subject: [opensource-dev] debian lenny build environment? Message-ID: <201110061532.17445.Lance.Corrimal@eregion.de> Hi, does anyone have a list of packages that I need to install on a debian lenny to be able to build a 3.x viewer and the 3p libs? thanks, LC From sythos at gmail.com Thu Oct 6 07:17:57 2011 From: sythos at gmail.com (Francesco "Sythos" Rabbi) Date: Thu, 6 Oct 2011 16:17:57 +0200 Subject: [opensource-dev] debian lenny build environment? In-Reply-To: <201110061532.17445.Lance.Corrimal@eregion.de> References: <201110061532.17445.Lance.Corrimal@eregion.de> Message-ID: <-5726721438487726518@unknownmsgid> If you install metapackages you hit all: Build-essential Bison Flex Libgtk2.0-dev Libglib2.0-dev I think is all -- Sent by iPhone Il giorno 06/ott/2011, alle ore 15:33, Lance Corrimal ha scritto: > Hi, > > does anyone have a list of packages that I need to install on a debian > lenny to be able to build a 3.x viewer and the 3p libs? > > > thanks, > 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 From oz at lindenlab.com Thu Oct 6 17:06:46 2011 From: oz at lindenlab.com (Oz Linden) Date: Fri, 07 Oct 2011 00:06:46 -0000 Subject: [opensource-dev] Review Request: VWR-27090 Allow Calling Cards to carry the "(link)" suffix in the Inventory pane In-Reply-To: <20111004220810.26381.82104@domU-12-31-38-00-90-68.compute-1.internal> References: <20111004220810.26381.82104@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20111007000646.26381.31426@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/487/#review1047 ----------------------------------------------------------- Ship it! - Oz On Oct. 4, 2011, 3:08 p.m., Stone Linden wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/487/ > ----------------------------------------------------------- > > (Updated Oct. 4, 2011, 3:08 p.m.) > > > Review request for Viewer. > > > Summary > ------- > > Move the test for whether an item is a link outside of the test for whether an item is a calling card. This allows calling card links to carry the "(link)" suffix, but continues to deny them the "(nomod) (nocopy)" suffixes. > > > This addresses bug VWR-27090. > http://jira.secondlife.com/browse/VWR-27090 > > > Diffs > ----- > > indra/newview/llinventorybridge.cpp 88cf7d9a9d31 > > Diff: http://codereview.secondlife.com/r/487/diff > > > Testing > ------- > > Compiles cleanly. > Shows Calling Card links with "(link)" suffix. > > > Thanks, > > Stone > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20111007/dc022c95/attachment.htm From oz at lindenlab.com Thu Oct 6 18:26:34 2011 From: oz at lindenlab.com (Oz Linden (Scott Lawrence)) Date: Thu, 06 Oct 2011 21:26:34 -0400 Subject: [opensource-dev] Snowstorm Team Review Build Message-ID: <4E8E554A.5010109@lindenlab.com> *Snowstorm Team Issues: Functional Review build* STORM-1602 2011 Q3 GPU Table Update VWR-25897 Cannot start Viewer 2.6.8 or later using the (open source) radeon driver on Linux VWR-26081 Radeon HD 6XXX cards not properly recognized VWR-26622 Intel Mobile 4 Series GPU not detected VWR-26913 [#STORM-1604] check_mark.png not loading at startup VWR-27026 [#STORM-1633] As a user, I would like for more detaled and useful information on the status floater VWR-27090 [#STORM-1640] simbolic links to calling cards missing the tailing "(link)" text in name Windows | Macintosh | Linux ------------------------------------------------------------------------ Details for these builds (build logs, included changesets) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20111006/75163754/attachment.htm From oz at lindenlab.com Fri Oct 7 11:54:41 2011 From: oz at lindenlab.com (Oz Linden) Date: Fri, 07 Oct 2011 18:54:41 -0000 Subject: [opensource-dev] Review Request: STORM-1581: Reduce frequency of graphics preferences being reset to recommended defaults Message-ID: <20111007185441.26378.45748@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/488/ ----------------------------------------------------------- Review request for Viewer. Summary ------- Modified the tests that compare previous gpu & feature tables as follows: Previously, the viewer stored the GPU class, and if that changed then preferences were reset. This submission changes the test to be based on the GPU id string rather than the GPU class, so that reclassification will not cause preferences to be reset. If the actual GPU has changed, such as a new computer, a new video card, or even a new driver, it is ok to reset the preferences. I have made a new dialog that shows the previous and new GPU identifiers, so the user can see exactly why the preferences have been changed. This should be infrequent and unsurprising. The other, and most frequent, cause for graphics preferences being reset is that something in the featuretable has changed, and the version number of the table has been incremented. Since we want to retain the ability to force values back to the recommended settings, this has been retained, but the rule has now been made explicit that the version number should be incremented ONLY if resetting all preferences is the intended effect, and not for just any change to the table. The notification dialog for this case has also been made more explicit. This addresses bug storm-1581. http://jira.secondlife.com/browse/storm-1581 Diffs ----- indra/newview/app_settings/settings.xml 6fc2f1ac8acb indra/newview/featuretable.txt 6fc2f1ac8acb indra/newview/featuretable_linux.txt 6fc2f1ac8acb indra/newview/featuretable_mac.txt 6fc2f1ac8acb indra/newview/featuretable_solaris.txt 6fc2f1ac8acb indra/newview/featuretable_xp.txt 6fc2f1ac8acb indra/newview/llstartup.cpp 6fc2f1ac8acb indra/newview/llviewerwindow.cpp 6fc2f1ac8acb indra/newview/skins/default/xui/en/notifications.xml 6fc2f1ac8acb Diff: http://codereview.secondlife.com/r/488/diff Testing ------- Manually simulated changes of both conditions, and the new dialogs were displayed correctly and preferences were reset. Also ran without changing anything, and preferences were preserved. Thanks, Oz -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20111007/b6326bb0/attachment.htm From lee.ponzu at gmail.com Sun Oct 9 11:03:23 2011 From: lee.ponzu at gmail.com (Lee ponzu) Date: Sun, 9 Oct 2011 11:03:23 -0700 Subject: [opensource-dev] Attached Objects not appearing to be attached. Message-ID: With the latest dev viewer, I am getting this glitch where a shoe or my hair does not move when I move. I TP into a location, walk away, and a shoe (left?) or my hair stays where I started. It looks attached in Inventory. A detach/attach fixes it. A TP might fix it, or not, not sure. By the way, this is not on my usual satellite internet. This is on actual high speed.... ponzu Second Life 3.1.1 (242386) Oct 5 2011 08:52:29 (Second Life Development) [ReleaseNotes] You are at 262117.0, 262145.0, 24.4 in Burning Man- Black Rock located at sim7425.agni.lindenlab.com (216.82.34.172:12035) Second Life RC Magnum 11.09.23.241511 Release Notes CPU: Intel(R) Core(TM) i5-2415M CPU @ 2.30GHz (2300 MHz) Memory: 4096 MB OS Version: Mac OS X 10.6.8 Darwin 10.8.0 Darwin Kernel Version 10.8.0: Tue Jun 7 16:32:41 PDT 2011; root:xnu-1504.15.3~1/RELEASE_X86_64 x86_64 Graphics Card Vendor: Intel Inc. Graphics Card: Intel HD Graphics 3000 OpenGL Engine OpenGL Version: 2.1 APPLE-1.6.38 libcurl Version: libcurl/7.21.1 OpenSSL/0.9.8q zlib/1.2.5 c-ares/1.7.1 J2C Decoder Version: KDU v6.4.1 Audio Driver Version: FMOD version 3.750000 Qt Webkit Version: 4.7.1 (version number hard-coded) Voice Server Version: Vivox 3.2.0002.10426 Built with GCC version 40001 Packets Lost: 0/41153 (0.0%) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20111009/28ea6f88/attachment.htm From Lance.Corrimal at eregion.de Sun Oct 9 11:30:43 2011 From: Lance.Corrimal at eregion.de (Lance Corrimal) Date: Sun, 9 Oct 2011 20:30:43 +0200 Subject: [opensource-dev] Attached Objects not appearing to be attached. In-Reply-To: References: Message-ID: <201110092030.43981.Lance.Corrimal@eregion.de> Am Sonntag, 9. Oktober 2011 schrieb Lee ponzu: > With the latest dev viewer, I am getting this glitch where a shoe > or my hair does not move when I move. I TP into a location, walk > away, and a shoe (left?) or my hair stays where I started. It > looks attached in Inventory. A detach/attach fixes it. A TP might > fix it, or not, not sure. By the way, this is not on my usual > satellite internet. This is on actual high speed.... that sounds a lot like what someone with an original viewer sees when someone usong the extra attach points in phoenix walks by with a visible attachment on one of the extra points. bye, LC From Lance.Corrimal at eregion.de Sun Oct 9 11:53:47 2011 From: Lance.Corrimal at eregion.de (Lance Corrimal) Date: Sun, 9 Oct 2011 20:53:47 +0200 Subject: [opensource-dev] avameet.com Message-ID: <201110092053.47193.Lance.Corrimal@eregion.de> every mail to the list triggers a response from avameet.com. could whoever set that up please make it stop. thanks. From stone at lindenlab.com Mon Oct 10 17:05:44 2011 From: stone at lindenlab.com (Stone Linden) Date: Tue, 11 Oct 2011 00:05:44 -0000 Subject: [opensource-dev] Review Request: EXP-625 New user remains a cloud for an extended period on first login in Advanced mode Message-ID: <20111011000544.6964.96889@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/489/ ----------------------------------------------------------- Review request for Viewer, Oz Linden, Nyx Linden, Jenn, Richard Nelson, Aura Linden, and Brad Payne. Summary ------- A new user logging in for the first time will remain a cloud for an unfortunate period of time. Turns out this is because we were failing to request the Library items corresponding to the user's desired initial outfit. The bug could be worked around by taking some other Inventory action, which would trigger a background fetch. This fix directly addresses the problem and allows the fetch of items to take place immediately. This addresses bug EXP-625. http://jira.secondlife.com/browse/EXP-625 Diffs ----- indra/newview/llinventoryobserver.cpp 88cf7d9a9d31 Diff: http://codereview.secondlife.com/r/489/diff Testing ------- Compiles and reproduceably alleviates the bug. Tested with several newly-created accounts. Thanks, Stone -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20111011/c04c1fcc/attachment.htm From richard at lindenlab.com Tue Oct 11 08:58:04 2011 From: richard at lindenlab.com (Richard Nelson) Date: Tue, 11 Oct 2011 15:58:04 -0000 Subject: [opensource-dev] Review Request: EXP-625 New user remains a cloud for an extended period on first login in Advanced mode In-Reply-To: <20111011000544.6964.96889@domU-12-31-38-00-90-68.compute-1.internal> References: <20111011000544.6964.96889@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20111011155804.6966.79982@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/489/#review1048 ----------------------------------------------------------- Ship it! good catch! - Richard On Oct. 10, 2011, 5:05 p.m., Stone Linden wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/489/ > ----------------------------------------------------------- > > (Updated Oct. 10, 2011, 5:05 p.m.) > > > Review request for Viewer, Oz Linden, Nyx Linden, Jenn, Richard Nelson, Aura Linden, and Brad Payne. > > > Summary > ------- > > A new user logging in for the first time will remain a cloud for an unfortunate period of time. Turns out this is because we were failing to request the Library items corresponding to the user's desired initial outfit. The bug could be worked around by taking some other Inventory action, which would trigger a background fetch. This fix directly addresses the problem and allows the fetch of items to take place immediately. > > > This addresses bug EXP-625. > http://jira.secondlife.com/browse/EXP-625 > > > Diffs > ----- > > indra/newview/llinventoryobserver.cpp 88cf7d9a9d31 > > Diff: http://codereview.secondlife.com/r/489/diff > > > Testing > ------- > > Compiles and reproduceably alleviates the bug. Tested with several newly-created accounts. > > > Thanks, > > Stone > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20111011/ce60be3b/attachment.htm From vsavchuk at productengine.com Tue Oct 11 10:48:52 2011 From: vsavchuk at productengine.com (Vadim ProductEngine) Date: Tue, 11 Oct 2011 17:48:52 -0000 Subject: [opensource-dev] Review Request: STORM-1615 Please update language support for Viewer Message-ID: <20111011174852.9424.96895@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/490/ ----------------------------------------------------------- Review request for Viewer and Richard Nelson. Summary ------- - Added Traditional Chinese to the Language dropdown menu in Preferences / General. The language is already supported, it just wasn't in the menu. - Added support for Russian, Simplified Chinese and Turkish. * Added the new languages to the list in Preferences / General. * Added a couple of "translated" XUI files for each language to create the necessary folders. - Removed Dutch from the available languages list. Dutch translations are still there, so you can still use Dutch by running viewer with "--set Language nl". Language codes: ru (Russian), tr (Turkish), zh_CN (Simplified Chinese), zh (Traditional Chinese). This addresses bug STORM-1615. http://jira.secondlife.com/browse/STORM-1615 Diffs ----- indra/newview/skins/default/xui/de/panel_preferences_general.xml 3af8218d32f1 indra/newview/skins/default/xui/en/panel_preferences_general.xml 3af8218d32f1 indra/newview/skins/default/xui/es/panel_preferences_general.xml 3af8218d32f1 indra/newview/skins/default/xui/fr/panel_preferences_general.xml 3af8218d32f1 indra/newview/skins/default/xui/it/panel_preferences_general.xml 3af8218d32f1 indra/newview/skins/default/xui/ja/panel_preferences_general.xml 3af8218d32f1 indra/newview/skins/default/xui/nl/panel_preferences_general.xml 3af8218d32f1 indra/newview/skins/default/xui/pl/panel_preferences_general.xml 3af8218d32f1 indra/newview/skins/default/xui/pt/panel_preferences_general.xml 3af8218d32f1 indra/newview/skins/default/xui/ru/floater_buy_currency_html.xml PRE-CREATION indra/newview/skins/default/xui/tr/floater_buy_currency_html.xml PRE-CREATION indra/newview/skins/default/xui/zh/panel_preferences_general.xml 3af8218d32f1 indra/newview/skins/default/xui/zh_CN/floater_buy_currency_html.xml PRE-CREATION indra/newview/skins/minimal/xui/ru/menu_script_chiclet.xml PRE-CREATION indra/newview/skins/minimal/xui/tr/menu_script_chiclet.xml PRE-CREATION indra/newview/skins/minimal/xui/zh/menu_script_chiclet.xml PRE-CREATION indra/newview/skins/minimal/xui/zh_CN/menu_script_chiclet.xml PRE-CREATION Diff: http://codereview.secondlife.com/r/490/diff Testing ------- Thanks, Vadim -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20111011/3a4a4259/attachment.htm From frost0610 at hotmail.de Tue Oct 11 11:55:08 2011 From: frost0610 at hotmail.de (Torben Trautman) Date: Tue, 11 Oct 2011 20:55:08 +0200 Subject: [opensource-dev] Review Request: STORM-1615 Please update language support for Viewer In-Reply-To: <20111011174852.9424.96895@domU-12-31-38-00-90-68.compute-1.internal> References: <20111011174852.9424.96895@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: I?m asking this mainly just out of curiosity but wouldn?t it make sense to add localizable strings to the locale panel_preferences_general files right away? If you added to the different language versions it would be easier to localize afterwards or even better - the language names could be localized right away. Greetings, Torben From: vsavchuk at productengine.com To: richard at lindenlab.com Date: Tue, 11 Oct 2011 17:48:52 +0000 CC: opensource-dev at lists.secondlife.com Subject: [opensource-dev] Review Request: STORM-1615 Please update language support for Viewer This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/490/ Review request for Viewer and Richard Nelson. By Vadim ProductEngine. Description - Added Traditional Chinese to the Language dropdown menu in Preferences / General. The language is already supported, it just wasn't in the menu. - Added support for Russian, Simplified Chinese and Turkish. * Added the new languages to the list in Preferences / General. * Added a couple of "translated" XUI files for each language to create the necessary folders. - Removed Dutch from the available languages list. Dutch translations are still there, so you can still use Dutch by running viewer with "--set Language nl". Language codes: ru (Russian), tr (Turkish), zh_CN (Simplified Chinese), zh (Traditional Chinese). Bugs: STORM-1615 Diffs indra/newview/skins/default/xui/de/panel_preferences_general.xml (3af8218d32f1) indra/newview/skins/default/xui/en/panel_preferences_general.xml (3af8218d32f1) indra/newview/skins/default/xui/es/panel_preferences_general.xml (3af8218d32f1) indra/newview/skins/default/xui/fr/panel_preferences_general.xml (3af8218d32f1) indra/newview/skins/default/xui/it/panel_preferences_general.xml (3af8218d32f1) indra/newview/skins/default/xui/ja/panel_preferences_general.xml (3af8218d32f1) indra/newview/skins/default/xui/nl/panel_preferences_general.xml (3af8218d32f1) indra/newview/skins/default/xui/pl/panel_preferences_general.xml (3af8218d32f1) indra/newview/skins/default/xui/pt/panel_preferences_general.xml (3af8218d32f1) indra/newview/skins/default/xui/ru/floater_buy_currency_html.xml (PRE-CREATION) indra/newview/skins/default/xui/tr/floater_buy_currency_html.xml (PRE-CREATION) indra/newview/skins/default/xui/zh/panel_preferences_general.xml (3af8218d32f1) indra/newview/skins/default/xui/zh_CN/floater_buy_currency_html.xml (PRE-CREATION) indra/newview/skins/minimal/xui/ru/menu_script_chiclet.xml (PRE-CREATION) indra/newview/skins/minimal/xui/tr/menu_script_chiclet.xml (PRE-CREATION) indra/newview/skins/minimal/xui/zh/menu_script_chiclet.xml (PRE-CREATION) indra/newview/skins/minimal/xui/zh_CN/menu_script_chiclet.xml (PRE-CREATION) View Diff _______________________________________________ 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20111011/d666bed5/attachment-0001.htm From vsavchuk at productengine.com Tue Oct 11 12:30:30 2011 From: vsavchuk at productengine.com (Vadim Savchuk) Date: Tue, 11 Oct 2011 22:30:30 +0300 Subject: [opensource-dev] Review Request: STORM-1615 Please update language support for Viewer In-Reply-To: References: <20111011174852.9424.96895@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: Torben, I'm not sure what you mean. The new strings will be automatically picked up by the viewer localization tool, i.e. there is no point for me to "update" translations. On Tue, Oct 11, 2011 at 9:55 PM, Torben Trautman wrote: > I?m asking this mainly just out of curiosity but wouldn?t it make sense to > add localizable strings to the locale panel_preferences_general files right > away? > If you added > > * > > * > > to the different language versions it would be easier to localize > afterwards or even better - the language names could be localized right > away. > > Greetings, > Torben > > ------------------------------ > From: vsavchuk at productengine.com > To: richard at lindenlab.com > Date: Tue, 11 Oct 2011 17:48:52 +0000 > CC: opensource-dev at lists.secondlife.com > Subject: [opensource-dev] Review Request: STORM-1615 Please update language > support for Viewer > > > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/490/ > Review request for Viewer and Richard Nelson. > By Vadim ProductEngine. > Description > > - Added Traditional Chinese to the Language dropdown menu in Preferences / General. > The language is already supported, it just wasn't in the menu. > - Added support for Russian, Simplified Chinese and Turkish. > * Added the new languages to the list in Preferences / General. > * Added a couple of "translated" XUI files for each language to create the necessary folders. > - Removed Dutch from the available languages list. > Dutch translations are still there, so you can still use Dutch by running viewer with "--set Language nl". > > Language codes: ru (Russian), tr (Turkish), zh_CN (Simplified Chinese), zh (Traditional Chinese). > > *Bugs: * STORM-1615 > Diffs > > - indra/newview/skins/default/xui/de/panel_preferences_general.xml > (3af8218d32f1) > - indra/newview/skins/default/xui/en/panel_preferences_general.xml > (3af8218d32f1) > - indra/newview/skins/default/xui/es/panel_preferences_general.xml > (3af8218d32f1) > - indra/newview/skins/default/xui/fr/panel_preferences_general.xml > (3af8218d32f1) > - indra/newview/skins/default/xui/it/panel_preferences_general.xml > (3af8218d32f1) > - indra/newview/skins/default/xui/ja/panel_preferences_general.xml > (3af8218d32f1) > - indra/newview/skins/default/xui/nl/panel_preferences_general.xml > (3af8218d32f1) > - indra/newview/skins/default/xui/pl/panel_preferences_general.xml > (3af8218d32f1) > - indra/newview/skins/default/xui/pt/panel_preferences_general.xml > (3af8218d32f1) > - indra/newview/skins/default/xui/ru/floater_buy_currency_html.xml > (PRE-CREATION) > - indra/newview/skins/default/xui/tr/floater_buy_currency_html.xml > (PRE-CREATION) > - indra/newview/skins/default/xui/zh/panel_preferences_general.xml > (3af8218d32f1) > - indra/newview/skins/default/xui/zh_CN/floater_buy_currency_html.xml > (PRE-CREATION) > - indra/newview/skins/minimal/xui/ru/menu_script_chiclet.xml > (PRE-CREATION) > - indra/newview/skins/minimal/xui/tr/menu_script_chiclet.xml > (PRE-CREATION) > - indra/newview/skins/minimal/xui/zh/menu_script_chiclet.xml > (PRE-CREATION) > - indra/newview/skins/minimal/xui/zh_CN/menu_script_chiclet.xml > (PRE-CREATION) > > View Diff > > _______________________________________________ Policies and (un)subscribe > information available here: http://wiki.secondlife.com/wiki/OpenSource-DevPlease 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 > -- Vadim -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20111011/58dd4d1f/attachment.htm From jhwelch at gmail.com Tue Oct 11 15:27:46 2011 From: jhwelch at gmail.com (Jonathan Yap) Date: Tue, 11 Oct 2011 22:27:46 -0000 Subject: [opensource-dev] Review Request: STORM-976 Object muted by name still displays notification message when clicked Message-ID: <20111011222746.11352.60663@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/491/ ----------------------------------------------------------- Review request for Viewer. Summary ------- An object muted by name still displays a notification message when clicked. The recent fix from Storm-1297 seems to have addressed this problem for objects that you do not own. The changes here take care of objects you do own. This addresses bug STORM-976. http://jira.secondlife.com/browse/STORM-976 Diffs ----- doc/contributions.txt 60058126a6d3 indra/newview/llviewermessage.cpp 60058126a6d3 Diff: http://codereview.secondlife.com/r/491/diff Testing ------- Tested using the plan in the JIRA Description field. Muted test object by name. Clicked on it, activating inventory offer. Noted that no offer notification was presented. Thanks, Jonathan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20111011/350cc145/attachment.htm From richard at lindenlab.com Tue Oct 11 15:50:15 2011 From: richard at lindenlab.com (Richard Nelson) Date: Tue, 11 Oct 2011 22:50:15 -0000 Subject: [opensource-dev] Review Request: STORM-1615 Please update language support for Viewer In-Reply-To: <20111011174852.9424.96895@domU-12-31-38-00-90-68.compute-1.internal> References: <20111011174852.9424.96895@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20111011225015.6960.99239@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/490/#review1049 ----------------------------------------------------------- indra/newview/skins/minimal/xui/ru/menu_script_chiclet.xml why are you manually setting these values? - Richard On Oct. 11, 2011, 10:48 a.m., Vadim ProductEngine wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/490/ > ----------------------------------------------------------- > > (Updated Oct. 11, 2011, 10:48 a.m.) > > > Review request for Viewer and Richard Nelson. > > > Summary > ------- > > - Added Traditional Chinese to the Language dropdown menu in Preferences / General. > The language is already supported, it just wasn't in the menu. > - Added support for Russian, Simplified Chinese and Turkish. > * Added the new languages to the list in Preferences / General. > * Added a couple of "translated" XUI files for each language to create the necessary folders. > - Removed Dutch from the available languages list. > Dutch translations are still there, so you can still use Dutch by running viewer with "--set Language nl". > > Language codes: ru (Russian), tr (Turkish), zh_CN (Simplified Chinese), zh (Traditional Chinese). > > > This addresses bug STORM-1615. > http://jira.secondlife.com/browse/STORM-1615 > > > Diffs > ----- > > indra/newview/skins/default/xui/de/panel_preferences_general.xml 3af8218d32f1 > indra/newview/skins/default/xui/en/panel_preferences_general.xml 3af8218d32f1 > indra/newview/skins/default/xui/es/panel_preferences_general.xml 3af8218d32f1 > indra/newview/skins/default/xui/fr/panel_preferences_general.xml 3af8218d32f1 > indra/newview/skins/default/xui/it/panel_preferences_general.xml 3af8218d32f1 > indra/newview/skins/default/xui/ja/panel_preferences_general.xml 3af8218d32f1 > indra/newview/skins/default/xui/nl/panel_preferences_general.xml 3af8218d32f1 > indra/newview/skins/default/xui/pl/panel_preferences_general.xml 3af8218d32f1 > indra/newview/skins/default/xui/pt/panel_preferences_general.xml 3af8218d32f1 > indra/newview/skins/default/xui/ru/floater_buy_currency_html.xml PRE-CREATION > indra/newview/skins/default/xui/tr/floater_buy_currency_html.xml PRE-CREATION > indra/newview/skins/default/xui/zh/panel_preferences_general.xml 3af8218d32f1 > indra/newview/skins/default/xui/zh_CN/floater_buy_currency_html.xml PRE-CREATION > indra/newview/skins/minimal/xui/ru/menu_script_chiclet.xml PRE-CREATION > indra/newview/skins/minimal/xui/tr/menu_script_chiclet.xml PRE-CREATION > indra/newview/skins/minimal/xui/zh/menu_script_chiclet.xml PRE-CREATION > indra/newview/skins/minimal/xui/zh_CN/menu_script_chiclet.xml PRE-CREATION > > Diff: http://codereview.secondlife.com/r/490/diff > > > Testing > ------- > > > Thanks, > > Vadim > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20111011/82f58f85/attachment-0001.htm From vsavchuk at productengine.com Tue Oct 11 17:24:55 2011 From: vsavchuk at productengine.com (Vadim ProductEngine) Date: Wed, 12 Oct 2011 00:24:55 -0000 Subject: [opensource-dev] Review Request: STORM-1615 Please update language support for Viewer In-Reply-To: <20111011225015.6960.99239@domU-12-31-38-00-90-68.compute-1.internal> References: <20111011225015.6960.99239@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20111012002455.9426.50619@domU-12-31-38-00-90-68.compute-1.internal> > On Oct. 11, 2011, 3:50 p.m., Richard Nelson wrote: > > indra/newview/skins/minimal/xui/ru/menu_script_chiclet.xml, line 3 > > > > > > why are you manually setting these values? Do you mean the label value? I just needed something to make sure translation to the language works. Can be removed if there's something wrong with it. The purpose was just to ensure creation of the language folder by placing a file into it. I thought a trivial soon-to-be-replaced translation would be a good fit. - Vadim ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/490/#review1049 ----------------------------------------------------------- On Oct. 11, 2011, 10:48 a.m., Vadim ProductEngine wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/490/ > ----------------------------------------------------------- > > (Updated Oct. 11, 2011, 10:48 a.m.) > > > Review request for Viewer and Richard Nelson. > > > Summary > ------- > > - Added Traditional Chinese to the Language dropdown menu in Preferences / General. > The language is already supported, it just wasn't in the menu. > - Added support for Russian, Simplified Chinese and Turkish. > * Added the new languages to the list in Preferences / General. > * Added a couple of "translated" XUI files for each language to create the necessary folders. > - Removed Dutch from the available languages list. > Dutch translations are still there, so you can still use Dutch by running viewer with "--set Language nl". > > Language codes: ru (Russian), tr (Turkish), zh_CN (Simplified Chinese), zh (Traditional Chinese). > > > This addresses bug STORM-1615. > http://jira.secondlife.com/browse/STORM-1615 > > > Diffs > ----- > > indra/newview/skins/default/xui/de/panel_preferences_general.xml 3af8218d32f1 > indra/newview/skins/default/xui/en/panel_preferences_general.xml 3af8218d32f1 > indra/newview/skins/default/xui/es/panel_preferences_general.xml 3af8218d32f1 > indra/newview/skins/default/xui/fr/panel_preferences_general.xml 3af8218d32f1 > indra/newview/skins/default/xui/it/panel_preferences_general.xml 3af8218d32f1 > indra/newview/skins/default/xui/ja/panel_preferences_general.xml 3af8218d32f1 > indra/newview/skins/default/xui/nl/panel_preferences_general.xml 3af8218d32f1 > indra/newview/skins/default/xui/pl/panel_preferences_general.xml 3af8218d32f1 > indra/newview/skins/default/xui/pt/panel_preferences_general.xml 3af8218d32f1 > indra/newview/skins/default/xui/ru/floater_buy_currency_html.xml PRE-CREATION > indra/newview/skins/default/xui/tr/floater_buy_currency_html.xml PRE-CREATION > indra/newview/skins/default/xui/zh/panel_preferences_general.xml 3af8218d32f1 > indra/newview/skins/default/xui/zh_CN/floater_buy_currency_html.xml PRE-CREATION > indra/newview/skins/minimal/xui/ru/menu_script_chiclet.xml PRE-CREATION > indra/newview/skins/minimal/xui/tr/menu_script_chiclet.xml PRE-CREATION > indra/newview/skins/minimal/xui/zh/menu_script_chiclet.xml PRE-CREATION > indra/newview/skins/minimal/xui/zh_CN/menu_script_chiclet.xml PRE-CREATION > > Diff: http://codereview.secondlife.com/r/490/diff > > > Testing > ------- > > > Thanks, > > Vadim > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20111012/9ad5f10c/attachment.htm From oz at lindenlab.com Tue Oct 11 18:38:19 2011 From: oz at lindenlab.com (Oz Linden (Scott Lawrence)) Date: Tue, 11 Oct 2011 21:38:19 -0400 Subject: [opensource-dev] Snowstorm Project Review Viewer Message-ID: <4E94EF8B.8070004@lindenlab.com> *Snowstorm Team Issues: Functional Review build* EXP-625 New user loads as cloud when logging in with second new account STORM-1579 xml formatting issues in Region/Estate floater STORM-1639 Duplicated XUI ID: floater_build_options.xml Windows | Macintosh | Linux ------------------------------------------------------------------------ Details for these builds (build logs, included changesets) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20111011/847b680d/attachment.htm From slitovchuk at productengine.com Wed Oct 12 07:41:04 2011 From: slitovchuk at productengine.com (Seth ProductEngine) Date: Wed, 12 Oct 2011 14:41:04 -0000 Subject: [opensource-dev] Review Request: STORM-1615 Please update language support for Viewer In-Reply-To: <20111011174852.9424.96895@domU-12-31-38-00-90-68.compute-1.internal> References: <20111011174852.9424.96895@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20111012144104.9610.71178@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/490/#review1051 ----------------------------------------------------------- Ship it! - Seth On Oct. 11, 2011, 10:48 a.m., Vadim ProductEngine wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/490/ > ----------------------------------------------------------- > > (Updated Oct. 11, 2011, 10:48 a.m.) > > > Review request for Viewer and Richard Nelson. > > > Summary > ------- > > - Added Traditional Chinese to the Language dropdown menu in Preferences / General. > The language is already supported, it just wasn't in the menu. > - Added support for Russian, Simplified Chinese and Turkish. > * Added the new languages to the list in Preferences / General. > * Added a couple of "translated" XUI files for each language to create the necessary folders. > - Removed Dutch from the available languages list. > Dutch translations are still there, so you can still use Dutch by running viewer with "--set Language nl". > > Language codes: ru (Russian), tr (Turkish), zh_CN (Simplified Chinese), zh (Traditional Chinese). > > > This addresses bug STORM-1615. > http://jira.secondlife.com/browse/STORM-1615 > > > Diffs > ----- > > indra/newview/skins/default/xui/de/panel_preferences_general.xml 3af8218d32f1 > indra/newview/skins/default/xui/en/panel_preferences_general.xml 3af8218d32f1 > indra/newview/skins/default/xui/es/panel_preferences_general.xml 3af8218d32f1 > indra/newview/skins/default/xui/fr/panel_preferences_general.xml 3af8218d32f1 > indra/newview/skins/default/xui/it/panel_preferences_general.xml 3af8218d32f1 > indra/newview/skins/default/xui/ja/panel_preferences_general.xml 3af8218d32f1 > indra/newview/skins/default/xui/nl/panel_preferences_general.xml 3af8218d32f1 > indra/newview/skins/default/xui/pl/panel_preferences_general.xml 3af8218d32f1 > indra/newview/skins/default/xui/pt/panel_preferences_general.xml 3af8218d32f1 > indra/newview/skins/default/xui/ru/floater_buy_currency_html.xml PRE-CREATION > indra/newview/skins/default/xui/tr/floater_buy_currency_html.xml PRE-CREATION > indra/newview/skins/default/xui/zh/panel_preferences_general.xml 3af8218d32f1 > indra/newview/skins/default/xui/zh_CN/floater_buy_currency_html.xml PRE-CREATION > indra/newview/skins/minimal/xui/ru/menu_script_chiclet.xml PRE-CREATION > indra/newview/skins/minimal/xui/tr/menu_script_chiclet.xml PRE-CREATION > indra/newview/skins/minimal/xui/zh/menu_script_chiclet.xml PRE-CREATION > indra/newview/skins/minimal/xui/zh_CN/menu_script_chiclet.xml PRE-CREATION > > Diff: http://codereview.secondlife.com/r/490/diff > > > Testing > ------- > > > Thanks, > > Vadim > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20111012/9036b3a8/attachment.htm From Lance.Corrimal at eregion.de Wed Oct 12 08:55:15 2011 From: Lance.Corrimal at eregion.de (Lance Corrimal) Date: Wed, 12 Oct 2011 17:55:15 +0200 Subject: [opensource-dev] viewer-beta and viewer-release repositories... Message-ID: <201110121755.15534.Lance.Corrimal@eregion.de> Is there any chance to get those two repos updated to what's current? thanks. From Lance.Corrimal at eregion.de Wed Oct 12 10:20:04 2011 From: Lance.Corrimal at eregion.de (Lance Corrimal) Date: Wed, 12 Oct 2011 19:20:04 +0200 Subject: [opensource-dev] viewer-beta and viewer-release repositories... In-Reply-To: References: <201110121755.15534.Lance.Corrimal@eregion.de> Message-ID: <201110121920.04998.Lance.Corrimal@eregion.de> According to the download page, 3.0.3 is current. according to llversionviewer.h, viewer-release is 3.0.0 and according to "hg fetch", viewer-beta has two unmerged heads... right after a hg clone. bye, LC Am Mittwoch, 12. Oktober 2011 schrieb Jonathan Welch: > I was looking at viewer-release today and the tags had V3.0 -- is > that current or not? > > On Wed, Oct 12, 2011 at 11:55 AM, Lance Corrimal > > wrote: > > Is there any chance to get those two repos updated to what's > > current? > > > > thanks. > > _______________________________________________ > > 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 From richard at lindenlab.com Wed Oct 12 14:28:28 2011 From: richard at lindenlab.com (Richard Nelson) Date: Wed, 12 Oct 2011 21:28:28 -0000 Subject: [opensource-dev] Review Request: STORM-1615 Please update language support for Viewer In-Reply-To: <20111011174852.9424.96895@domU-12-31-38-00-90-68.compute-1.internal> References: <20111011174852.9424.96895@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20111012212828.6960.13583@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/490/#review1052 ----------------------------------------------------------- Ship it! - Richard On Oct. 11, 2011, 10:48 a.m., Vadim ProductEngine wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/490/ > ----------------------------------------------------------- > > (Updated Oct. 11, 2011, 10:48 a.m.) > > > Review request for Viewer and Richard Nelson. > > > Summary > ------- > > - Added Traditional Chinese to the Language dropdown menu in Preferences / General. > The language is already supported, it just wasn't in the menu. > - Added support for Russian, Simplified Chinese and Turkish. > * Added the new languages to the list in Preferences / General. > * Added a couple of "translated" XUI files for each language to create the necessary folders. > - Removed Dutch from the available languages list. > Dutch translations are still there, so you can still use Dutch by running viewer with "--set Language nl". > > Language codes: ru (Russian), tr (Turkish), zh_CN (Simplified Chinese), zh (Traditional Chinese). > > > This addresses bug STORM-1615. > http://jira.secondlife.com/browse/STORM-1615 > > > Diffs > ----- > > indra/newview/skins/default/xui/de/panel_preferences_general.xml 3af8218d32f1 > indra/newview/skins/default/xui/en/panel_preferences_general.xml 3af8218d32f1 > indra/newview/skins/default/xui/es/panel_preferences_general.xml 3af8218d32f1 > indra/newview/skins/default/xui/fr/panel_preferences_general.xml 3af8218d32f1 > indra/newview/skins/default/xui/it/panel_preferences_general.xml 3af8218d32f1 > indra/newview/skins/default/xui/ja/panel_preferences_general.xml 3af8218d32f1 > indra/newview/skins/default/xui/nl/panel_preferences_general.xml 3af8218d32f1 > indra/newview/skins/default/xui/pl/panel_preferences_general.xml 3af8218d32f1 > indra/newview/skins/default/xui/pt/panel_preferences_general.xml 3af8218d32f1 > indra/newview/skins/default/xui/ru/floater_buy_currency_html.xml PRE-CREATION > indra/newview/skins/default/xui/tr/floater_buy_currency_html.xml PRE-CREATION > indra/newview/skins/default/xui/zh/panel_preferences_general.xml 3af8218d32f1 > indra/newview/skins/default/xui/zh_CN/floater_buy_currency_html.xml PRE-CREATION > indra/newview/skins/minimal/xui/ru/menu_script_chiclet.xml PRE-CREATION > indra/newview/skins/minimal/xui/tr/menu_script_chiclet.xml PRE-CREATION > indra/newview/skins/minimal/xui/zh/menu_script_chiclet.xml PRE-CREATION > indra/newview/skins/minimal/xui/zh_CN/menu_script_chiclet.xml PRE-CREATION > > Diff: http://codereview.secondlife.com/r/490/diff > > > Testing > ------- > > > Thanks, > > Vadim > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20111012/30be7980/attachment.htm From stone at lindenlab.com Wed Oct 12 17:11:59 2011 From: stone at lindenlab.com (Stone Linden) Date: Thu, 13 Oct 2011 00:11:59 -0000 Subject: [opensource-dev] Review Request: EXP-625 Speed up initial avatar copy and bake by moving the initial gestures copy into LLApperanceMgr::onFirstFullyVisible() Message-ID: <20111013001159.6960.89419@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/492/ ----------------------------------------------------------- Review request for Viewer, Oz Linden, Nyx Linden, Jenn, Richard Nelson, and Brad Payne. Summary ------- Move copyLibraryGestures from llstartup.cpp to llappearancemgr.cpp, and call it from the onFirstFullyVisible() method. This gives the avatar initial outfit load and bake time to finish before going into the somewhat expensive gesture copy process. This addresses bug EXP-625. http://jira.secondlife.com/browse/EXP-625 Diffs ----- indra/newview/llagentwearables.h 88cf7d9a9d31 indra/newview/llagentwearables.cpp 88cf7d9a9d31 indra/newview/llappearancemgr.h 88cf7d9a9d31 indra/newview/llappearancemgr.cpp 88cf7d9a9d31 indra/newview/llstartup.h 88cf7d9a9d31 indra/newview/llstartup.cpp 88cf7d9a9d31 Diff: http://codereview.secondlife.com/r/492/diff Testing ------- Fully loads and bakes my initial avatar in 20s from accepting ToS until visible in-world vs. 50s without this change. Time until Gestures are fully copies is about 45s, so slightly faster than trying to do it all at once, and a better experience to get the avatar first, then the gestures second. Thanks, Stone -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20111013/4a459b08/attachment.htm From stone at lindenlab.com Wed Oct 12 17:19:01 2011 From: stone at lindenlab.com (Stone Linden) Date: Thu, 13 Oct 2011 00:19:01 -0000 Subject: [opensource-dev] Review Request: EXP-625 Speed up initial avatar copy and bake by moving the initial gestures copy into LLApperanceMgr::onFirstFullyVisible() In-Reply-To: <20111013001159.6960.89419@domU-12-31-38-00-90-68.compute-1.internal> References: <20111013001159.6960.89419@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20111013001901.9610.84651@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/492/ ----------------------------------------------------------- (Updated Oct. 12, 2011, 5:19 p.m.) Review request for Viewer, Oz Linden, Nyx Linden, Jenn, Richard Nelson, and Brad Payne. Changes ------- Fixing parent diff. Summary ------- Move copyLibraryGestures from llstartup.cpp to llappearancemgr.cpp, and call it from the onFirstFullyVisible() method. This gives the avatar initial outfit load and bake time to finish before going into the somewhat expensive gesture copy process. This addresses bug EXP-625. http://jira.secondlife.com/browse/EXP-625 Diffs (updated) ----- indra/newview/llagentwearables.h be1660e54fa8 indra/newview/llagentwearables.cpp be1660e54fa8 indra/newview/llappearancemgr.h be1660e54fa8 indra/newview/llappearancemgr.cpp be1660e54fa8 indra/newview/llstartup.h be1660e54fa8 indra/newview/llstartup.cpp be1660e54fa8 Diff: http://codereview.secondlife.com/r/492/diff Testing ------- Fully loads and bakes my initial avatar in 20s from accepting ToS until visible in-world vs. 50s without this change. Time until Gestures are fully copies is about 45s, so slightly faster than trying to do it all at once, and a better experience to get the avatar first, then the gestures second. Thanks, Stone -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20111013/30b5f09d/attachment.htm From stone at lindenlab.com Wed Oct 12 17:23:07 2011 From: stone at lindenlab.com (Stone Linden) Date: Thu, 13 Oct 2011 00:23:07 -0000 Subject: [opensource-dev] Review Request: EXP-625 Speed up initial avatar copy and bake by moving the initial gestures copy into LLApperanceMgr::onFirstFullyVisible() In-Reply-To: <20111013001901.9610.84651@domU-12-31-38-00-90-68.compute-1.internal> References: <20111013001901.9610.84651@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20111013002307.6964.61346@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/492/ ----------------------------------------------------------- (Updated Oct. 12, 2011, 5:23 p.m.) Review request for Viewer, Oz Linden, Nyx Linden, Jenn, Richard Nelson, and Brad Payne. Changes ------- Fixed llstartup.cpp parent diff: $ hg diff -r be1660e54fa8:tip > exp-625-parent.diff Summary ------- Move copyLibraryGestures from llstartup.cpp to llappearancemgr.cpp, and call it from the onFirstFullyVisible() method. This gives the avatar initial outfit load and bake time to finish before going into the somewhat expensive gesture copy process. This addresses bug EXP-625. http://jira.secondlife.com/browse/EXP-625 Diffs (updated) ----- indra/newview/llagentwearables.h be1660e54fa8 indra/newview/llagentwearables.cpp be1660e54fa8 indra/newview/llappearancemgr.h be1660e54fa8 indra/newview/llappearancemgr.cpp be1660e54fa8 indra/newview/llstartup.h be1660e54fa8 indra/newview/llstartup.cpp be1660e54fa8 Diff: http://codereview.secondlife.com/r/492/diff Testing ------- Fully loads and bakes my initial avatar in 20s from accepting ToS until visible in-world vs. 50s without this change. Time until Gestures are fully copies is about 45s, so slightly faster than trying to do it all at once, and a better experience to get the avatar first, then the gestures second. Thanks, Stone -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20111013/13b0ed5e/attachment-0001.htm From stone at lindenlab.com Wed Oct 12 17:24:33 2011 From: stone at lindenlab.com (Stone Linden) Date: Thu, 13 Oct 2011 00:24:33 -0000 Subject: [opensource-dev] Review Request: EXP-625 Speed up initial avatar copy and bake by moving the initial gestures copy into LLApperanceMgr::onFirstFullyVisible() In-Reply-To: <20111013002307.6964.61346@domU-12-31-38-00-90-68.compute-1.internal> References: <20111013002307.6964.61346@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20111013002433.6963.69812@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/492/ ----------------------------------------------------------- (Updated Oct. 12, 2011, 5:24 p.m.) Review request for Viewer, Oz Linden, Nyx Linden, Jenn, Richard Nelson, and Brad Payne. Summary ------- Move copyLibraryGestures from llstartup.cpp to llappearancemgr.cpp, and call it from the onFirstFullyVisible() method. This gives the avatar initial outfit load and bake time to finish before going into the somewhat expensive gesture copy process. This addresses bug EXP-625. http://jira.secondlife.com/browse/EXP-625 Diffs ----- indra/newview/llagentwearables.h be1660e54fa8 indra/newview/llagentwearables.cpp be1660e54fa8 indra/newview/llappearancemgr.h be1660e54fa8 indra/newview/llappearancemgr.cpp be1660e54fa8 indra/newview/llstartup.h be1660e54fa8 indra/newview/llstartup.cpp be1660e54fa8 Diff: http://codereview.secondlife.com/r/492/diff Testing (updated) ------- Fully loads and bakes my initial avatar in 20s from accepting ToS until visible in-world vs. 50s without this change. Time until Gestures are fully copied is about 45s. Slightly faster than trying to do it all at once, and a better experience to get the avatar first, then the gestures second. Thanks, Stone -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20111013/306dd39a/attachment.htm From alain at lindenlab.com Thu Oct 13 11:10:27 2011 From: alain at lindenlab.com (Alain Linden) Date: Thu, 13 Oct 2011 18:10:27 -0000 Subject: [opensource-dev] Review Request: Adds support for packaging and extracting zip formatted archives Message-ID: <20111013181027.9610.12609@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/494/ ----------------------------------------------------------- Review request for Viewer, Oz Linden, Jenn, and Nat Goodspeed. Summary ------- These changes are to support packaging archives as zip files. This is useful when you are using autobuild to construct an archive that isn't really intended to be used as an autobuild installable. Internally autobuild can handle tarballs on any platform, but if you are making a package for windows and not installing with autobuild, it is better to use zip which is natively supported. Changes here do the following: 1. enable the --archive-format option for autobuild package to choose the format of the package. 2. add support for reading an 'archive' entry per platform with the new 'format' element to select the archive format with the configuration file. 3. add new edit command 'autobuild edit archive' to add archive configurations. 4. add support for installing zip formatted archives. Diffs ----- autobuild/autobuild_tool_edit.py ac90b03614ea autobuild/autobuild_tool_package.py ac90b03614ea autobuild/common.py ac90b03614ea autobuild/configfile.py ac90b03614ea autobuild/tests/test_common.py ac90b03614ea autobuild/tests/test_package.py ac90b03614ea Diff: http://codereview.secondlife.com/r/494/diff Testing ------- Thanks, Alain -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20111013/cf3a8531/attachment.htm From nat at lindenlab.com Fri Oct 14 08:56:36 2011 From: nat at lindenlab.com (Nat Goodspeed) Date: Fri, 14 Oct 2011 15:56:36 -0000 Subject: [opensource-dev] Review Request: Adds support for packaging and extracting zip formatted archives In-Reply-To: <20111013181027.9610.12609@domU-12-31-38-00-90-68.compute-1.internal> References: <20111013181027.9610.12609@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20111014155636.6963.47810@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/494/#review1053 ----------------------------------------------------------- Since I know this snapshot of the functionality isn't yet complete -- it doesn't have the bugfix from yesterday -- I'd like to see the composite diffs. Which resurfaces a question about which I've scratched my head before. How do you coax this tool to display all the differences between two repo clones, even if the changesets are discontiguous? - Nat On Oct. 13, 2011, 11:10 a.m., Alain Linden wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/494/ > ----------------------------------------------------------- > > (Updated Oct. 13, 2011, 11:10 a.m.) > > > Review request for Viewer, Oz Linden, Jenn, and Nat Goodspeed. > > > Summary > ------- > > These changes are to support packaging archives as zip files. This is useful when you are using autobuild to construct an archive that isn't really intended to be used as an autobuild installable. Internally autobuild can handle tarballs on any platform, but if you are making a package for windows and not installing with autobuild, it is better to use zip which is natively supported. Changes here do the following: > > 1. enable the --archive-format option for autobuild package to choose the format of the package. > 2. add support for reading an 'archive' entry per platform with the new 'format' element to select the archive format with the configuration file. > 3. add new edit command 'autobuild edit archive' to add archive configurations. > 4. add support for installing zip formatted archives. > > > Diffs > ----- > > autobuild/autobuild_tool_edit.py ac90b03614ea > autobuild/autobuild_tool_package.py ac90b03614ea > autobuild/common.py ac90b03614ea > autobuild/configfile.py ac90b03614ea > autobuild/tests/test_common.py ac90b03614ea > autobuild/tests/test_package.py ac90b03614ea > > Diff: http://codereview.secondlife.com/r/494/diff > > > Testing > ------- > > > Thanks, > > Alain > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20111014/75fc9650/attachment.htm From alain at lindenlab.com Fri Oct 14 09:32:02 2011 From: alain at lindenlab.com (Alain Linden) Date: Fri, 14 Oct 2011 16:32:02 -0000 Subject: [opensource-dev] Review Request: Adds support for packaging and extracting zip formatted archives In-Reply-To: <20111013181027.9610.12609@domU-12-31-38-00-90-68.compute-1.internal> References: <20111013181027.9610.12609@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20111014163202.6963.14968@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/494/ ----------------------------------------------------------- (Updated Oct. 14, 2011, 9:32 a.m.) Review request for Viewer, Oz Linden, Jenn, and Nat Goodspeed. Changes ------- Included a few bug fixes. Summary ------- These changes are to support packaging archives as zip files. This is useful when you are using autobuild to construct an archive that isn't really intended to be used as an autobuild installable. Internally autobuild can handle tarballs on any platform, but if you are making a package for windows and not installing with autobuild, it is better to use zip which is natively supported. Changes here do the following: 1. enable the --archive-format option for autobuild package to choose the format of the package. 2. add support for reading an 'archive' entry per platform with the new 'format' element to select the archive format with the configuration file. 3. add new edit command 'autobuild edit archive' to add archive configurations. 4. add support for installing zip formatted archives. Diffs (updated) ----- autobuild/autobuild_tool_edit.py ac90b03614ea autobuild/autobuild_tool_package.py ac90b03614ea autobuild/common.py ac90b03614ea autobuild/configfile.py ac90b03614ea autobuild/tests/test_common.py ac90b03614ea autobuild/tests/test_package.py ac90b03614ea Diff: http://codereview.secondlife.com/r/494/diff Testing ------- Thanks, Alain -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20111014/9154902a/attachment.htm From nat at lindenlab.com Fri Oct 14 10:18:40 2011 From: nat at lindenlab.com (Nat Goodspeed) Date: Fri, 14 Oct 2011 17:18:40 -0000 Subject: [opensource-dev] Review Request: Adds support for packaging and extracting zip formatted archives In-Reply-To: <20111014163202.6963.14968@domU-12-31-38-00-90-68.compute-1.internal> References: <20111014163202.6963.14968@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20111014171840.9424.50206@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/494/#review1054 ----------------------------------------------------------- Ship it! Looks good -- and thank you! - Nat On Oct. 14, 2011, 9:32 a.m., Alain Linden wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/494/ > ----------------------------------------------------------- > > (Updated Oct. 14, 2011, 9:32 a.m.) > > > Review request for Viewer, Oz Linden, Jenn, and Nat Goodspeed. > > > Summary > ------- > > These changes are to support packaging archives as zip files. This is useful when you are using autobuild to construct an archive that isn't really intended to be used as an autobuild installable. Internally autobuild can handle tarballs on any platform, but if you are making a package for windows and not installing with autobuild, it is better to use zip which is natively supported. Changes here do the following: > > 1. enable the --archive-format option for autobuild package to choose the format of the package. > 2. add support for reading an 'archive' entry per platform with the new 'format' element to select the archive format with the configuration file. > 3. add new edit command 'autobuild edit archive' to add archive configurations. > 4. add support for installing zip formatted archives. > > > Diffs > ----- > > autobuild/autobuild_tool_edit.py ac90b03614ea > autobuild/autobuild_tool_package.py ac90b03614ea > autobuild/common.py ac90b03614ea > autobuild/configfile.py ac90b03614ea > autobuild/tests/test_common.py ac90b03614ea > autobuild/tests/test_package.py ac90b03614ea > > Diff: http://codereview.secondlife.com/r/494/diff > > > Testing > ------- > > > Thanks, > > Alain > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20111014/4fc8b497/attachment.htm From nickyperian at yahoo.com Fri Oct 14 17:35:38 2011 From: nickyperian at yahoo.com (Nicky Perian) Date: Fri, 14 Oct 2011 17:35:38 -0700 (PDT) Subject: [opensource-dev] linux32 build startup failures. Message-ID: <1318638938.57154.YahooMailNeo@web43503.mail.sp1.yahoo.com> 2011-10-14T23:42:09Z llrender/llgl.cpp(1799) : error 2011-10-14T23:42:09Z ERROR: LLGLState: ASSERT (mWasEnabled == glIsEnabled(state)) A good build but, errors at start-up on both viewer development and kokua builds. SL downloaded binary runs w/o error. The build system is Debian Squeeze i686 inside a Virtual Box VM with 3 cores and 3GB dedicated to the VM. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20111014/db7c3888/attachment.htm From sllists at boroon.dasgupta.ch Sat Oct 15 03:55:41 2011 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Sat, 15 Oct 2011 12:55:41 +0200 Subject: [opensource-dev] linux32 build startup failures. In-Reply-To: <1318638938.57154.YahooMailNeo@web43503.mail.sp1.yahoo.com> References: <1318638938.57154.YahooMailNeo@web43503.mail.sp1.yahoo.com> Message-ID: <4E9966AD.2050108@boroon.dasgupta.ch> On 10/15/2011 02:35 AM, Nicky Perian wrote: > 2011-10-14T23:42:09Z llrender/llgl.cpp(1799) : error > 2011-10-14T23:42:09Z ERROR: LLGLState: ASSERT (mWasEnabled == > glIsEnabled(state)) > A good build but, errors at start-up on both viewer development and > kokua builds. SL downloaded binary runs w/o error. > The build system is Debian Squeeze i686 inside a Virtual Box VM with 3 > cores and 3GB dedicated to the VM. That is an llassert(), not an llassert_always(), so it won't normally trigger on Release or ReleaseOS builds. As fas as I know, LL's downloads are Release builds. Cheers Boroondas -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20111015/790fdbdd/attachment.htm From Ima.Mechanique at blueyonder.co.uk Sat Oct 15 21:55:45 2011 From: Ima.Mechanique at blueyonder.co.uk (Ima Mechanique) Date: Sun, 16 Oct 2011 04:55:45 -0000 Subject: [opensource-dev] Review Request: STORM-959 Syntax highlighting for LSL multi-line comments. Message-ID: <20111016045545.17041.8740@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/498/ ----------------------------------------------------------- Review request for Viewer. Summary ------- Adding syntax highlighting for LSL multi-line comments. This has been sitting on my hard drive for months. I've redone the diff against current tip. This addresses bug STORM-959. http://jira.secondlife.com/browse/STORM-959 Diffs ----- doc/contributions.txt 871963a3c7b9 indra/llui/llkeywords.h 871963a3c7b9 indra/llui/llkeywords.cpp 871963a3c7b9 indra/newview/app_settings/keywords.ini 871963a3c7b9 Diff: http://codereview.secondlife.com/r/498/diff Testing ------- Thanks, Ima -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20111016/1fe78768/attachment.htm From sllists at boroon.dasgupta.ch Sun Oct 16 06:32:03 2011 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Sun, 16 Oct 2011 13:32:03 -0000 Subject: [opensource-dev] Review Request: STORM-959 Syntax highlighting for LSL multi-line comments. In-Reply-To: <20111016045545.17041.8740@domU-12-31-38-00-90-68.compute-1.internal> References: <20111016045545.17041.8740@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20111016133203.17038.34224@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/498/#review1055 ----------------------------------------------------------- Looks good as far as I can tell. Can we unit-test this somehow, though? indra/llui/llkeywords.cpp Code duplication. Could be worth factoring out an (inlined) compare function to be called with mToken in isHead and with mDelimiter in isTail. indra/llui/llkeywords.cpp Any reason to keep this line commented out instead of removing it entirely? indra/llui/llkeywords.cpp While we're here, this comment should start with 'If', not 'Is' - Boroondas On Oct. 15, 2011, 9:55 p.m., Ima Mechanique wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/498/ > ----------------------------------------------------------- > > (Updated Oct. 15, 2011, 9:55 p.m.) > > > Review request for Viewer. > > > Summary > ------- > > Adding syntax highlighting for LSL multi-line comments. > This has been sitting on my hard drive for months. I've redone the diff against current tip. > > > This addresses bug STORM-959. > http://jira.secondlife.com/browse/STORM-959 > > > Diffs > ----- > > doc/contributions.txt 871963a3c7b9 > indra/llui/llkeywords.h 871963a3c7b9 > indra/llui/llkeywords.cpp 871963a3c7b9 > indra/newview/app_settings/keywords.ini 871963a3c7b9 > > Diff: http://codereview.secondlife.com/r/498/diff > > > Testing > ------- > > > Thanks, > > Ima > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20111016/1ea95308/attachment-0001.htm From Ima.Mechanique at blueyonder.co.uk Sun Oct 16 12:32:08 2011 From: Ima.Mechanique at blueyonder.co.uk (Ima Mechanique) Date: Sun, 16 Oct 2011 19:32:08 -0000 Subject: [opensource-dev] Review Request: STORM-959 Syntax highlighting for LSL multi-line comments. In-Reply-To: <20111016045545.17041.8740@domU-12-31-38-00-90-68.compute-1.internal> References: <20111016045545.17041.8740@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20111016193208.17098.80571@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/498/ ----------------------------------------------------------- (Updated Oct. 16, 2011, 12:32 p.m.) Review request for Viewer. Changes ------- Updated diff to incorporate two of Boroondas' comments. Still looking at the main comment. Summary ------- Adding syntax highlighting for LSL multi-line comments. This has been sitting on my hard drive for months. I've redone the diff against current tip. This addresses bug STORM-959. http://jira.secondlife.com/browse/STORM-959 Diffs (updated) ----- doc/contributions.txt 871963a3c7b9 indra/llui/llkeywords.h 871963a3c7b9 indra/llui/llkeywords.cpp 871963a3c7b9 indra/newview/app_settings/keywords.ini 871963a3c7b9 Diff: http://codereview.secondlife.com/r/498/diff Testing ------- Thanks, Ima -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20111016/daf57a57/attachment.htm From Ima.Mechanique at blueyonder.co.uk Sun Oct 16 12:45:46 2011 From: Ima.Mechanique at blueyonder.co.uk (Ima Mechanique) Date: Sun, 16 Oct 2011 19:45:46 -0000 Subject: [opensource-dev] Review Request: STORM-959 Syntax highlighting for LSL multi-line comments. In-Reply-To: <20111016193208.17098.80571@domU-12-31-38-00-90-68.compute-1.internal> References: <20111016193208.17098.80571@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20111016194546.17038.49821@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/498/ ----------------------------------------------------------- (Updated Oct. 16, 2011, 12:45 p.m.) Review request for Viewer. Changes ------- diff2 seemed to break something on RB. Summary ------- Adding syntax highlighting for LSL multi-line comments. This has been sitting on my hard drive for months. I've redone the diff against current tip. This addresses bug STORM-959. http://jira.secondlife.com/browse/STORM-959 Diffs (updated) ----- doc/contributions.txt 871963a3c7b9 indra/llui/llkeywords.h 871963a3c7b9 indra/llui/llkeywords.cpp 871963a3c7b9 indra/newview/app_settings/keywords.ini 871963a3c7b9 Diff: http://codereview.secondlife.com/r/498/diff Testing ------- Thanks, Ima -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20111016/acf18802/attachment.htm From Lance.Corrimal at eregion.de Mon Oct 17 03:23:45 2011 From: Lance.Corrimal at eregion.de (Lance Corrimal) Date: Mon, 17 Oct 2011 10:23:45 -0000 Subject: [opensource-dev] Review Request: VWR-27184: Hide "Library" landmark accordion when NoInventoryLibrary is set to TRUE Message-ID: <20111017102345.17039.39999@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/499/ ----------------------------------------------------------- Review request for Viewer. Summary ------- When the user hides the library by setting the debug setting "NoInventoryLibrary" to TRUE, the Library accordion in the landmark panel stays and duplicates the "My Inventory" accordion. This patch fixes that. This addresses bug VWR-27184. http://jira.secondlife.com/browse/VWR-27184 Diffs ----- indra/newview/llpanellandmarks.cpp 871963a3c7b9 indra/newview/skins/default/xui/en/panel_landmarks.xml 871963a3c7b9 Diff: http://codereview.secondlife.com/r/499/diff Testing ------- using this patch in Dolphin Viewer 3 since 3.0.11 without problems. Thanks, Lance -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20111017/9804a6cc/attachment.htm From jhwelch at gmail.com Mon Oct 17 03:38:04 2011 From: jhwelch at gmail.com (Jonathan Yap) Date: Mon, 17 Oct 2011 10:38:04 -0000 Subject: [opensource-dev] Review Request: VWR-27184: Hide "Library" landmark accordion when NoInventoryLibrary is set to TRUE In-Reply-To: <20111017102345.17039.39999@domU-12-31-38-00-90-68.compute-1.internal> References: <20111017102345.17039.39999@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20111017103804.17037.38799@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/499/#review1056 ----------------------------------------------------------- indra/newview/skins/default/xui/en/panel_landmarks.xml Am I missing the place in the code where there is a corresponding setVisible call since the default now seems to be not visible? - Jonathan On Oct. 17, 2011, 3:23 a.m., Lance Corrimal wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/499/ > ----------------------------------------------------------- > > (Updated Oct. 17, 2011, 3:23 a.m.) > > > Review request for Viewer. > > > Summary > ------- > > When the user hides the library by setting the debug setting "NoInventoryLibrary" to TRUE, the Library accordion in the landmark panel stays and duplicates the "My Inventory" accordion. This patch fixes that. > > > This addresses bug VWR-27184. > http://jira.secondlife.com/browse/VWR-27184 > > > Diffs > ----- > > indra/newview/llpanellandmarks.cpp 871963a3c7b9 > indra/newview/skins/default/xui/en/panel_landmarks.xml 871963a3c7b9 > > Diff: http://codereview.secondlife.com/r/499/diff > > > Testing > ------- > > using this patch in Dolphin Viewer 3 since 3.0.11 without problems. > > > Thanks, > > Lance > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20111017/af894aad/attachment.htm From Lance.Corrimal at eregion.de Mon Oct 17 04:04:35 2011 From: Lance.Corrimal at eregion.de (Lance Corrimal) Date: Mon, 17 Oct 2011 11:04:35 -0000 Subject: [opensource-dev] Review Request: VWR-27184: Hide "Library" landmark accordion when NoInventoryLibrary is set to TRUE In-Reply-To: <20111017103804.17037.38799@domU-12-31-38-00-90-68.compute-1.internal> References: <20111017103804.17037.38799@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20111017110435.17041.1648@domU-12-31-38-00-90-68.compute-1.internal> > On Oct. 17, 2011, 3:38 a.m., Jonathan Yap wrote: > > indra/newview/skins/default/xui/en/panel_landmarks.xml, line 77 > > > > > > Am I missing the place in the code where there is a corresponding setVisible call since the default now seems to be not visible? setVisible is done somewhere down the inheritcance tree. It works without an explicit call, so I did not want to stick one in. - Lance ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/499/#review1056 ----------------------------------------------------------- On Oct. 17, 2011, 3:23 a.m., Lance Corrimal wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/499/ > ----------------------------------------------------------- > > (Updated Oct. 17, 2011, 3:23 a.m.) > > > Review request for Viewer. > > > Summary > ------- > > When the user hides the library by setting the debug setting "NoInventoryLibrary" to TRUE, the Library accordion in the landmark panel stays and duplicates the "My Inventory" accordion. This patch fixes that. > > > This addresses bug VWR-27184. > http://jira.secondlife.com/browse/VWR-27184 > > > Diffs > ----- > > indra/newview/llpanellandmarks.cpp 871963a3c7b9 > indra/newview/skins/default/xui/en/panel_landmarks.xml 871963a3c7b9 > > Diff: http://codereview.secondlife.com/r/499/diff > > > Testing > ------- > > using this patch in Dolphin Viewer 3 since 3.0.11 without problems. > > > Thanks, > > Lance > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20111017/d6d1a24f/attachment-0001.htm From hitomi.tiponi at yahoo.co.uk Mon Oct 17 07:55:35 2011 From: hitomi.tiponi at yahoo.co.uk (Hitomi Tiponi) Date: Mon, 17 Oct 2011 15:55:35 +0100 (BST) Subject: [opensource-dev] Missing details in Snowstorm development builds In-Reply-To: References: Message-ID: <1318863335.33502.YahooMailNeo@web23907.mail.ird.yahoo.com> I have noticed that the fields 'Changes since last good build' and 'Jiras' on the Snowtorm Viewer development build are repeatedly showing as 'None' for more than a weeknow - despite the fact that there are clearly changes and responses to JIRAs being implemented. It is quite useful to see what a build addresses so I wondered if this was deliberate or a bug you can fix? Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20111017/973a022e/attachment.htm From jhwelch at gmail.com Mon Oct 17 17:41:06 2011 From: jhwelch at gmail.com (Jonathan Welch) Date: Mon, 17 Oct 2011 20:41:06 -0400 Subject: [opensource-dev] Eliminate VS2010 LNK4099 errors Message-ID: I've got tired of seeing blasts of LNK4099 errors fly up the screen when I compile so I looked into how to eliminate them. It seems the only way to do this is to hack link.exe and change the 4 bytes that equal 4099 to something else. See http://www.bottledlight.com/docs/lnk4099.html In my case this was at location 15a0. Of course it would be nice if the files in question did not cause this to happen in the first place. -Jonathan From wolfpup67 at earthlink.net Mon Oct 17 18:12:01 2011 From: wolfpup67 at earthlink.net (WolfPup Lowenhar) Date: Mon, 17 Oct 2011 21:12:01 -0400 Subject: [opensource-dev] STORM-1647 Message-ID: <003301cc8d32$f1617900$d4246b00$@net> For reference please see https://jira.secondlife.com/browse/STORM-1647 The first build this is seen in is build 240927 and I'm needing help locating the most recent build before that one that it is not happening in ad this would help reduce the number of change sets I have to search through to find what is causing this any help from the Os community would be greatly welcomed. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20111017/7abcb21e/attachment.htm From stone at lindenlab.com Tue Oct 18 00:19:19 2011 From: stone at lindenlab.com (Stone Linden) Date: Tue, 18 Oct 2011 07:19:19 -0000 Subject: [opensource-dev] Review Request: Add experimental support for building with Xcode 4.2 on Mac OS X Lion Message-ID: <20111018071919.17041.45357@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/502/ ----------------------------------------------------------- Review request for Viewer. Summary ------- Check the version of Xcode installed, and use that to set appropriate Mac OS X SDK and compiler versions. Supports Xcode 3.2.x with Mac OS X SDK 10.5 with identical parameters as the code it replaces. Adds parameters for Xcode 4.2 with Mac OS X 10.6 SDK. Explicitly rejects with a message Xcode less than 3.2, and both 4.0 and 4.1. Removes options for PPC builds, which we don't use, don't support, and don't work anyhow. Diffs ----- indra/cmake/Variables.cmake c42575f2cde8 Diff: http://codereview.secondlife.com/r/502/diff Testing ------- Builds On My Machine (TM). Thanks, Stone -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20111018/e26545cb/attachment.htm From oz at lindenlab.com Tue Oct 18 08:47:23 2011 From: oz at lindenlab.com (Oz Linden) Date: Tue, 18 Oct 2011 15:47:23 -0000 Subject: [opensource-dev] Review Request: STORM-959 Syntax highlighting for LSL multi-line comments. In-Reply-To: <20111016194546.17038.49821@domU-12-31-38-00-90-68.compute-1.internal> References: <20111016194546.17038.49821@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20111018154723.17043.98384@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/498/#review1058 ----------------------------------------------------------- indra/llui/llkeywords.h Doxygen comments for the usage of these would be good. Per the coding standard, it should be a typedef: https://wiki.secondlife.com/wiki/Coding_Standard#Enums indra/llui/llkeywords.h getLength2 is not descriptive.... name it in a way that reflects the difference in what it does (and if making that clear requires renaming getLength, that's fine) - Oz On Oct. 16, 2011, 12:45 p.m., Ima Mechanique wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/498/ > ----------------------------------------------------------- > > (Updated Oct. 16, 2011, 12:45 p.m.) > > > Review request for Viewer. > > > Summary > ------- > > Adding syntax highlighting for LSL multi-line comments. > This has been sitting on my hard drive for months. I've redone the diff against current tip. > > > This addresses bug STORM-959. > http://jira.secondlife.com/browse/STORM-959 > > > Diffs > ----- > > doc/contributions.txt 871963a3c7b9 > indra/llui/llkeywords.h 871963a3c7b9 > indra/llui/llkeywords.cpp 871963a3c7b9 > indra/newview/app_settings/keywords.ini 871963a3c7b9 > > Diff: http://codereview.secondlife.com/r/498/diff > > > Testing > ------- > > > Thanks, > > Ima > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20111018/0139616c/attachment.htm From oz at lindenlab.com Tue Oct 18 08:54:21 2011 From: oz at lindenlab.com (Oz Linden (Scott Lawrence)) Date: Tue, 18 Oct 2011 11:54:21 -0400 Subject: [opensource-dev] Eliminate VS2010 LNK4099 errors In-Reply-To: References: Message-ID: <4E9DA12D.7@lindenlab.com> On 2011-10-17 20:41, Jonathan Welch wrote: > I've got tired of seeing blasts of LNK4099 errors fly up the screen > when I compile so I looked into how to eliminate them. It seems the > only way to do this is to hack link.exe and change the 4 bytes that > equal 4099 to something else. See > http://www.bottledlight.com/docs/lnk4099.html > > In my case this was at location 15a0. I don't think we're going to officially suggest doing that.... :-) > Of course it would be nice if the files in question did not cause this > to happen in the first place. Anyone know how to make that happen? From nickyperian at yahoo.com Tue Oct 18 11:10:29 2011 From: nickyperian at yahoo.com (Nicky Perian) Date: Tue, 18 Oct 2011 11:10:29 -0700 (PDT) Subject: [opensource-dev] Eliminate VS2010 LNK4099 errors In-Reply-To: <4E9DA12D.7@lindenlab.com> References: <4E9DA12D.7@lindenlab.com> Message-ID: <1318961429.61659.YahooMailNeo@web43511.mail.sp1.yahoo.com> Deliver the *pdb files with each library as is done with vorbis_static within 3p-ogvorbis' build-cmd.sh. ________________________________ From: Oz Linden (Scott Lawrence) To: opensource-dev at lists.secondlife.com Sent: Tuesday, October 18, 2011 10:54 AM Subject: Re: [opensource-dev] Eliminate VS2010 LNK4099 errors On 2011-10-17 20:41, Jonathan Welch wrote: > I've got tired of seeing blasts of LNK4099 errors fly up the screen > when I compile so I looked into how to eliminate them.? It seems the > only way to do this is to hack link.exe and change the 4 bytes that > equal 4099 to something else.? See > http://www.bottledlight.com/docs/lnk4099.html > > In my case this was at location 15a0. I don't think we're going to officially suggest doing that.... :-) > Of course it would be nice if the files in question did not cause this > to happen in the first place. Anyone know how to make that happen? _______________________________________________ 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20111018/df012104/attachment-0001.htm From oz at lindenlab.com Tue Oct 18 12:14:11 2011 From: oz at lindenlab.com (Oz Linden) Date: Tue, 18 Oct 2011 19:14:11 -0000 Subject: [opensource-dev] Review Request: STORM-1615 Please update language support for Viewer In-Reply-To: <20111011174852.9424.96895@domU-12-31-38-00-90-68.compute-1.internal> References: <20111011174852.9424.96895@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20111018191411.17043.57581@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/490/#review1059 ----------------------------------------------------------- Ship it! - Oz On Oct. 11, 2011, 10:48 a.m., Vadim ProductEngine wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/490/ > ----------------------------------------------------------- > > (Updated Oct. 11, 2011, 10:48 a.m.) > > > Review request for Viewer and Richard Nelson. > > > Summary > ------- > > - Added Traditional Chinese to the Language dropdown menu in Preferences / General. > The language is already supported, it just wasn't in the menu. > - Added support for Russian, Simplified Chinese and Turkish. > * Added the new languages to the list in Preferences / General. > * Added a couple of "translated" XUI files for each language to create the necessary folders. > - Removed Dutch from the available languages list. > Dutch translations are still there, so you can still use Dutch by running viewer with "--set Language nl". > > Language codes: ru (Russian), tr (Turkish), zh_CN (Simplified Chinese), zh (Traditional Chinese). > > > This addresses bug STORM-1615. > http://jira.secondlife.com/browse/STORM-1615 > > > Diffs > ----- > > indra/newview/skins/default/xui/de/panel_preferences_general.xml 3af8218d32f1 > indra/newview/skins/default/xui/en/panel_preferences_general.xml 3af8218d32f1 > indra/newview/skins/default/xui/es/panel_preferences_general.xml 3af8218d32f1 > indra/newview/skins/default/xui/fr/panel_preferences_general.xml 3af8218d32f1 > indra/newview/skins/default/xui/it/panel_preferences_general.xml 3af8218d32f1 > indra/newview/skins/default/xui/ja/panel_preferences_general.xml 3af8218d32f1 > indra/newview/skins/default/xui/nl/panel_preferences_general.xml 3af8218d32f1 > indra/newview/skins/default/xui/pl/panel_preferences_general.xml 3af8218d32f1 > indra/newview/skins/default/xui/pt/panel_preferences_general.xml 3af8218d32f1 > indra/newview/skins/default/xui/ru/floater_buy_currency_html.xml PRE-CREATION > indra/newview/skins/default/xui/tr/floater_buy_currency_html.xml PRE-CREATION > indra/newview/skins/default/xui/zh/panel_preferences_general.xml 3af8218d32f1 > indra/newview/skins/default/xui/zh_CN/floater_buy_currency_html.xml PRE-CREATION > indra/newview/skins/minimal/xui/ru/menu_script_chiclet.xml PRE-CREATION > indra/newview/skins/minimal/xui/tr/menu_script_chiclet.xml PRE-CREATION > indra/newview/skins/minimal/xui/zh/menu_script_chiclet.xml PRE-CREATION > indra/newview/skins/minimal/xui/zh_CN/menu_script_chiclet.xml PRE-CREATION > > Diff: http://codereview.secondlife.com/r/490/diff > > > Testing > ------- > > > Thanks, > > Vadim > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20111018/1e478a63/attachment.htm From oz at lindenlab.com Tue Oct 18 15:04:19 2011 From: oz at lindenlab.com (Oz Linden (Scott Lawrence)) Date: Tue, 18 Oct 2011 18:04:19 -0400 Subject: [opensource-dev] Viewer UI mode merge Message-ID: <4E9DF7E3.20509@lindenlab.com> Today the Viewer UI mode merge project is coming to viewer-development. This project combines basic and advanced modes and brings an updated, more flexible workspace to the Viewer. At the time of integration with viewer-development today, there are still a number of outstanding issues the team is working on to prepare for beta and release. So if you're running the development Viewer, please be aware that some things may not yet work correctly. Here's a quick rundown of some of the known issues: o The Viewer floater camera views and presets do not work. o The Nearby Voice panel does not update to a new call or from nearby voice info once opened. o Viewer crashes when updating UI size in preferences. o The Speak button is activated when dragging and dropping between toolbars and/or moving back to the Tool Box. o Viewer crash when moving the speak button from one toolbar to another when there is an active call request. o Teleport history doesn't display visited locations. o Viewer crash when double-clicking the mini-map in People > Nearby. o Notification and conversation chiclets overlap. o WASD controls don't move avatar while the Move floater is in focus. o Closing voice controls while a group or p2p call also closes the group call/IM window o Viewer crash after teleport o Hitting back in the 'Create Group' panel or 'Blocked' panel requires multiple clicks for action to occur. The team is busily addressing these issues and will be updating as we plan the next couple of beta releases. If you see other issues, please report them in Jira as always and we'll make sure they are routed appropriately. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20111018/8d7ee3cc/attachment.htm From jhwelch at gmail.com Tue Oct 18 19:03:17 2011 From: jhwelch at gmail.com (Jonathan Welch) Date: Tue, 18 Oct 2011 22:03:17 -0400 Subject: [opensource-dev] FUI project just out - no more sidebar Message-ID: The new FUI project just got merged in to viewer-development. No more sidebar! Attached you can see there are buttons on the bottom and left. There's also a column you can move them to on the right which starts out unpopulated. For each of the 3 zones you can have icons or icons+labels and move buttons around or eliminate ones you don't want. -------------- next part -------------- A non-text attachment was scrubbed... Name: FUI.png Type: image/png Size: 335909 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/opensource-dev/attachments/20111018/323a9a0d/attachment-0001.png From geenz at geenzo.com Tue Oct 18 19:09:29 2011 From: geenz at geenzo.com (Geenz) Date: Tue, 18 Oct 2011 22:09:29 -0400 Subject: [opensource-dev] FUI project just out - no more sidebar In-Reply-To: References: Message-ID: <0012F31F-87FA-4559-84D3-D1D77F849593@geenzo.com> I can't be the only one who thinks that window management needs to be re-thought for FUI. As it stands, it seems as if that actually took a step backwards. On Oct 18, 2011, at 10:03 PM, Jonathan Welch wrote: > The new FUI project just got merged in to viewer-development. No more > sidebar! Attached you can see there are buttons on the bottom and > left. There's also a column you can move them to on the right which > starts out unpopulated. For each of the 3 zones you can have icons or > icons+labels and move buttons around or eliminate ones you don't want. > _______________________________________________ > 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 From arrehn at gmail.com Tue Oct 18 19:20:08 2011 From: arrehn at gmail.com (Arrehn Oberlander) Date: Tue, 18 Oct 2011 22:20:08 -0400 Subject: [opensource-dev] Viewer UI mode merge In-Reply-To: <4E9DF7E3.20509@lindenlab.com> References: <4E9DF7E3.20509@lindenlab.com> Message-ID: Thanks for sharing Oz, Although I like the general direction of the improvements and believe they have good potential, I feel the obligation to point out to your own presentation with Esbee and Qarl two years ago coming off of the difficult Viewer 2 rollout, where the three of you stood up before everyone at SLCC and told us that LL wasn't going drop these large UI rewrites on the community as surprises. I'm glad it's there, I think it has potential, but the communication and coordination with the greater development community was poor at best, and at worst, contrary to what LL directly communicated. It would perhaps have been better to have these as project viewers well in advance of a sweeping merge. On Tue, Oct 18, 2011 at 6:04 PM, Oz Linden (Scott Lawrence) < oz at lindenlab.com> wrote: > Today the Viewer UI mode merge project is coming to viewer-development. > This project combines basic and advanced modes and brings an updated, more > flexible workspace to the Viewer. > > At the time of integration with viewer-development today, there are still a > number of outstanding issues the team is working on to prepare for beta and > release. So if you're running the development Viewer, please be aware that > some things may not yet work correctly. Here's a quick rundown of some of > the known issues: > > > - The Viewer floater camera views and presets do not work. > - The Nearby Voice panel does not update to a new call or from > nearby voice info once opened. > - Viewer crashes when updating UI size in preferences. > - The Speak button is activated when dragging and dropping between > toolbars and/or moving back to the Tool Box. > - Viewer crash when moving the speak button from one toolbar to > another when there is an active call request. > - Teleport history doesn't display visited locations. > - Viewer crash when double-clicking the mini-map in People > Nearby. > - Notification and conversation chiclets overlap. > - WASD controls don't move avatar while the Move floater is in > focus. > - Closing voice controls while a group or p2p call also closes the > group call/IM window > - Viewer crash after teleport > - Hitting back in the 'Create Group' panel or 'Blocked' panel > requires multiple clicks for action to occur. > > The team is busily addressing these issues and will be updating as we > plan the next couple of beta releases. If you see other issues, please > report them in Jira as always and we'll make sure they are routed > appropriately. > > > > _______________________________________________ > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20111018/3519430c/attachment.htm From kadah.coba at gmail.com Tue Oct 18 19:21:33 2011 From: kadah.coba at gmail.com (Kadah) Date: Tue, 18 Oct 2011 19:21:33 -0700 Subject: [opensource-dev] Viewer UI mode merge In-Reply-To: <4E9DF7E3.20509@lindenlab.com> References: <4E9DF7E3.20509@lindenlab.com> Message-ID: <4E9E342D.7080607@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 My top annoyances on first impressions: No Map button by default, and no ctrl+M shortcut at all. Can't relocate the chiclets syswell, or at least reduce the standoff from the corner. I use that corner exclusively for the minimap, which has always made using the v2 UI difficult. Nearby voice should be a flyout panel of nearby (outstanding from 2.0) Nearby chat should be dockable in Conversations (outstanding from 2.0) Otherwise its rather nice. You won't see my crying over the sidebar being removed and the abality to see and type in to local is long overdue. I really like the customizable buttons, though I wish they were not per-user. A quick vid I made of the new button customization: http://www.youtube.com/watch?v=T9dvwEr_JuY -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJOnjQtAAoJEIdLfPRu7qE2JH4H/iKdVDOTjHWFYjS7Xj9GYE64 as/W22pgJh7PIeHBrFXi7MWHe2phxQr0m5TSa3F7+frJ91MXD/DvHqpnonIrL5pA 5FFCTkau9LCXM9iJ/xOYGyr61/e8o7AwS2axBRx6FIHNXh3/836fLLUXYHjEksvv 0ZKS/9YNp1der/d2BKoF8utbp5kaD9awPzFFTXmzYGyJ+faTZXbOKtD2VHLrdfnK nC2/k2iGCZGGxyqu7P7t6YfZbSoMm6xA4WR+vQ5B/qegk1E9kTcUXQo4sHHCtbyJ I73sG0YQg42WcxX00nWFVM+XF1IBtOn4NmabgSb2xoJw+bk3GBvg6vd6vFuYI9Y= =HIaj -----END PGP SIGNATURE----- From kadah.coba at gmail.com Tue Oct 18 19:21:41 2011 From: kadah.coba at gmail.com (Kadah) Date: Tue, 18 Oct 2011 19:21:41 -0700 Subject: [opensource-dev] Viewer UI mode merge In-Reply-To: References: <4E9DF7E3.20509@lindenlab.com> Message-ID: <4E9E3435.2070407@gmail.com> On 10/18/2011 7:20 PM, Arrehn Oberlander wrote: > Thanks for sharing Oz, > > Although I like the general direction of the improvements and believe > they have good potential, I feel the obligation to point out to your own > presentation with Esbee and Qarl two years ago coming off of the > difficult Viewer 2 rollout, where the three of you stood up before > everyone at SLCC and told us that LL wasn't going drop these large UI > rewrites on the community as surprises. > > I'm glad it's there, I think it has potential, but the communication and > coordination with the greater development community was poor at best, > and at worst, contrary to what LL directly communicated. > > It would perhaps have been better to have these as project viewers well > in advance of a sweeping merge. +1 From aklo at skyhighway.com Tue Oct 18 19:24:20 2011 From: aklo at skyhighway.com (aklo at skyhighway.com) Date: Tue, 18 Oct 2011 19:24:20 -0700 Subject: [opensource-dev] FUI project just out - no more sidebar Message-ID: Dude! For serious? That's just the kind of thing that could inspire me to fix my computer so i can try the v3 viewer and start spending some quality time in SL doing something other than just meditating at the Buddha Center! i mean, the meditating is good & all that, & it's not like it doesn't make me a better person, avi, etc. But it would be super terrific to actually have some different fun doing other things, too! Thx!! - AK -------------------------------------------------------------------------------- The new FUI project just got merged in to viewer-development. No more sidebar! Attached you can see there are buttons on the bottom and left. There's also a column you can move them to on the right which starts out unpopulated. For each of the 3 zones you can have icons or icons+labels and move buttons around or eliminate ones you don't want. From jessica at trinityenterprises.ca Tue Oct 18 19:26:30 2011 From: jessica at trinityenterprises.ca (Jessica Trinity) Date: Tue, 18 Oct 2011 22:26:30 -0400 Subject: [opensource-dev] Viewer UI mode merge In-Reply-To: References: <4E9DF7E3.20509@lindenlab.com> Message-ID: <3A09D7FD17A5450CAD8E2E1D10D7D30B@JessicaLyonPC> Agreed on all points made by Arrehn. _____ From: opensource-dev-bounces at lists.secondlife.com [mailto:opensource-dev-bounces at lists.secondlife.com] On Behalf Of Arrehn Oberlander Sent: Tuesday, October 18, 2011 10:20 PM To: Oz Linden (Scott Lawrence) Cc: Viewer Subject: Re: [opensource-dev] Viewer UI mode merge Thanks for sharing Oz, Although I like the general direction of the improvements and believe they have good potential, I feel the obligation to point out to your own presentation with Esbee and Qarl two years ago coming off of the difficult Viewer 2 rollout, where the three of you stood up before everyone at SLCC and told us that LL wasn't going drop these large UI rewrites on the community as surprises. I'm glad it's there, I think it has potential, but the communication and coordination with the greater development community was poor at best, and at worst, contrary to what LL directly communicated. It would perhaps have been better to have these as project viewers well in advance of a sweeping merge. On Tue, Oct 18, 2011 at 6:04 PM, Oz Linden (Scott Lawrence) wrote: Today the Viewer UI mode merge project is coming to viewer-development. This project combines basic and advanced modes and brings an updated, more flexible workspace to the Viewer. At the time of integration with viewer-development today, there are still a number of outstanding issues the team is working on to prepare for beta and release. So if you're running the development Viewer, please be aware that some things may not yet work correctly. Here's a quick rundown of some of the known issues: * The Viewer floater camera views and presets do not work. * The Nearby Voice panel does not update to a new call or from nearby voice info once opened. * Viewer crashes when updating UI size in preferences. * The Speak button is activated when dragging and dropping between toolbars and/or moving back to the Tool Box. * Viewer crash when moving the speak button from one toolbar to another when there is an active call request. * Teleport history doesn't display visited locations. * Viewer crash when double-clicking the mini-map in People > Nearby. * Notification and conversation chiclets overlap. * WASD controls don't move avatar while the Move floater is in focus. * Closing voice controls while a group or p2p call also closes the group call/IM window * Viewer crash after teleport * Hitting back in the 'Create Group' panel or 'Blocked' panel requires multiple clicks for action to occur. The team is busily addressing these issues and will be updating as we plan the next couple of beta releases. If you see other issues, please report them in Jira as always and we'll make sure they are routed appropriately. _______________________________________________ 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20111018/a30f737e/attachment-0001.htm From geenz at geenzo.com Tue Oct 18 19:32:55 2011 From: geenz at geenzo.com (Geenz) Date: Tue, 18 Oct 2011 22:32:55 -0400 Subject: [opensource-dev] Viewer UI mode merge In-Reply-To: References: <4E9DF7E3.20509@lindenlab.com> Message-ID: <049F7CEA-C402-45F4-B8A5-A058DCC18035@geenzo.com> I agree completely with Arrehn myself, communication with the community is awesome when trying to achieve a UI intended to work for *most* people. That said, my two cents on the new UI: Why are IMs docked at the top? It seems like it'd make more sense for them to be docked at the bottom. Window management is in severe need of some love. The one saving grace of the sidebar was, everything was docked in one location, instead of spread out across the whole screen, while still having the ability to undock certain elements. Dockable windows that could be grouped together would be nice. On Oct 18, 2011, at 10:20 PM, Arrehn Oberlander wrote: > Thanks for sharing Oz, > > Although I like the general direction of the improvements and believe they have good potential, I feel the obligation to point out to your own presentation with Esbee and Qarl two years ago coming off of the difficult Viewer 2 rollout, where the three of you stood up before everyone at SLCC and told us that LL wasn't going drop these large UI rewrites on the community as surprises. > > I'm glad it's there, I think it has potential, but the communication and coordination with the greater development community was poor at best, and at worst, contrary to what LL directly communicated. > > It would perhaps have been better to have these as project viewers well in advance of a sweeping merge. > > > On Tue, Oct 18, 2011 at 6:04 PM, Oz Linden (Scott Lawrence) wrote: > Today the Viewer UI mode merge project is coming to viewer-development. This project combines basic and advanced modes and brings an updated, more flexible workspace to the Viewer. > > At the time of integration with viewer-development today, there are still a number of outstanding issues the team is working on to prepare for beta and release. So if you're running the development Viewer, please be aware that some things may not yet work correctly. Here's a quick rundown of some of the known issues: > > The Viewer floater camera views and presets do not work. > The Nearby Voice panel does not update to a new call or from nearby voice info once opened. > Viewer crashes when updating UI size in preferences. > The Speak button is activated when dragging and dropping between toolbars and/or moving back to the Tool Box. > Viewer crash when moving the speak button from one toolbar to another when there is an active call request. > Teleport history doesn't display visited locations. > Viewer crash when double-clicking the mini-map in People > Nearby. > Notification and conversation chiclets overlap. > WASD controls don't move avatar while the Move floater is in focus. > Closing voice controls while a group or p2p call also closes the group call/IM window > Viewer crash after teleport > Hitting back in the 'Create Group' panel or 'Blocked' panel requires multiple clicks for action to occur. > The team is busily addressing these issues and will be updating as we plan the next couple of beta releases. If you see other issues, please report them in Jira as always and we'll make sure they are routed appropriately. > > > > _______________________________________________ > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20111018/e539aee5/attachment.htm From oz at lindenlab.com Tue Oct 18 19:48:47 2011 From: oz at lindenlab.com (Oz Linden (Scott Lawrence)) Date: Tue, 18 Oct 2011 22:48:47 -0400 Subject: [opensource-dev] Viewer UI mode merge In-Reply-To: <4E9DF7E3.20509@lindenlab.com> References: <4E9DF7E3.20509@lindenlab.com> Message-ID: <4E9E3A8F.1090004@lindenlab.com> On 2011-10-18 18:04, Oz Linden (Scott Lawrence) wrote: > > Today the Viewer UI mode merge project is coming to > viewer-development. This project combines basic and advanced modes > and brings an updated, more flexible workspace to the Viewer. > > At the time of integration with viewer-development today, there > are still a number of outstanding issues the team is working on to > prepare for beta and release. So if you're running the development > Viewer, please be aware that some things may not yet work > correctly. Here's a quick rundown of some of the known issues: > > o The Viewer floater camera views and presets do not work. > o The Nearby Voice panel does not update to a new call or from > nearby voice info once opened. > o Viewer crashes when updating UI size in preferences. > o The Speak button is activated when dragging and dropping > between toolbars and/or moving back to the Tool Box. > o Viewer crash when moving the speak button from one toolbar to > another when there is an active call request. > o Teleport history doesn't display visited locations. > o Viewer crash when double-clicking the mini-map in People > Nearby. > o Notification and conversation chiclets overlap. > o WASD controls don't move avatar while the Move floater is in > focus. > o Closing voice controls while a group or p2p call also closes > the group call/IM window > o Viewer crash after teleport > o Hitting back in the 'Create Group' panel or 'Blocked' panel > requires multiple clicks for action to occur. > > The team is busily addressing these issues and will be updating as > we plan the next couple of beta releases. If you see other issues, > please report them in Jira as always and we'll make sure they are > routed appropriately. > > Beta candidate builds are at http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repo/viewer-pre-beta/rev/243350/index.html -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20111018/d23ccbcf/attachment.htm From Lance.Corrimal at eregion.de Tue Oct 18 23:41:48 2011 From: Lance.Corrimal at eregion.de (Lance Corrimal) Date: Wed, 19 Oct 2011 08:41:48 +0200 Subject: [opensource-dev] FUI project just out - no more sidebar In-Reply-To: References: Message-ID: <201110190841.48832.Lance.Corrimal@eregion.de> Am Mittwoch, 19. Oktober 2011 schrieb Jonathan Welch: > The new FUI project just got merged in to viewer-development. No > more sidebar! Attached you can see there are buttons on the > bottom and left. There's also a column you can move them to on > the right which starts out unpopulated. For each of the 3 zones > you can have icons or icons+labels and move buttons around or > eliminate ones you don't want. why the eff are those buttons on the left instead of the right where we all would expect them to be after around 2 years of sidebar? do "they" want to screw with users minds? other than that it looks fine. I'll give it a more in-deep once my local v-d has built. bye, LC From ardylay at gmail.com Tue Oct 18 23:44:17 2011 From: ardylay at gmail.com (Ardy Lay) Date: Wed, 19 Oct 2011 00:44:17 -0600 Subject: [opensource-dev] FUI project just out - no more sidebar In-Reply-To: <201110190841.48832.Lance.Corrimal@eregion.de> References: <201110190841.48832.Lance.Corrimal@eregion.de> Message-ID: <4E9E71C1.3020807@gmail.com> On 10/19/2011 12:41 AM, Lance Corrimal wrote: > Am Mittwoch, 19. Oktober 2011 schrieb Jonathan Welch: >> The new FUI project just got merged in to viewer-development. No >> more sidebar! Attached you can see there are buttons on the >> bottom and left. There's also a column you can move them to on >> the right which starts out unpopulated. For each of the 3 zones >> you can have icons or icons+labels and move buttons around or >> eliminate ones you don't want. > why the eff are those buttons on the left instead of the right where > we all would expect them to be after around 2 years of sidebar? > > do "they" want to screw with users minds? > > other than that it looks fine. > > I'll give it a more in-deep once my local v-d has built. > > > 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 MOVE the effing buttons yourself! It's easy, really. Try it. And seriously, this is a "First Look" kinda thing. People are flipping out and I think I am kinda burned out on people flipping out. From Lance.Corrimal at eregion.de Tue Oct 18 23:52:39 2011 From: Lance.Corrimal at eregion.de (Lance Corrimal) Date: Wed, 19 Oct 2011 08:52:39 +0200 Subject: [opensource-dev] FUI project just out - no more sidebar In-Reply-To: <4E9E71C1.3020807@gmail.com> References: <201110190841.48832.Lance.Corrimal@eregion.de> <4E9E71C1.3020807@gmail.com> Message-ID: <201110190852.39976.Lance.Corrimal@eregion.de> Am Mittwoch, 19. Oktober 2011 schrieb Ardy Lay: > > why the eff are those buttons on the left instead of the right > > where we all would expect them to be after around 2 years of > > sidebar? > > MOVE the effing buttons yourself! It's easy, really. doesn't change the fact that they should not have been moved from the right in the first place. first rule in UI design: do not move essential stuff with no extremely good reasons. bye, LC From ardylay at gmail.com Wed Oct 19 00:34:44 2011 From: ardylay at gmail.com (Ardy Lay) Date: Wed, 19 Oct 2011 01:34:44 -0600 Subject: [opensource-dev] FUI project just out - no more sidebar In-Reply-To: <201110190852.39976.Lance.Corrimal@eregion.de> References: <201110190841.48832.Lance.Corrimal@eregion.de> <4E9E71C1.3020807@gmail.com> <201110190852.39976.Lance.Corrimal@eregion.de> Message-ID: <4E9E7D94.4020303@gmail.com> On 10/19/2011 12:52 AM, Lance Corrimal wrote: > Am Mittwoch, 19. Oktober 2011 schrieb Ardy Lay: > >>> why the eff are those buttons on the left instead of the right >>> where we all would expect them to be after around 2 years of >>> sidebar? >> MOVE the effing buttons yourself! It's easy, really. > doesn't change the fact that they should not have been moved from the > right in the first place. > > first rule in UI design: do not move essential stuff with no extremely > good reasons. > > > 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 Did you like the sidebar when it was introduced? From fire at b3dmultitech.com Wed Oct 19 00:43:27 2011 From: fire at b3dmultitech.com (Paul Preibisch) Date: Wed, 19 Oct 2011 16:43:27 +0900 Subject: [opensource-dev] FUI project just out - no more sidebar In-Reply-To: <201110190852.39976.Lance.Corrimal@eregion.de> References: <201110190841.48832.Lance.Corrimal@eregion.de> <4E9E71C1.3020807@gmail.com> <201110190852.39976.Lance.Corrimal@eregion.de> Message-ID: I agree - my first thought was, wow - its gonna be hard getting stuff from the left now, when I am used to accessing it from the right. Best option: leave it on the right, but make it movable to the left via drag and drop. On Wed, Oct 19, 2011 at 3:52 PM, Lance Corrimal wrote: > Am Mittwoch, 19. Oktober 2011 schrieb Ardy Lay: > > > > why the eff are those buttons on the left instead of the right > > > where we all would expect them to be after around 2 years of > > > sidebar? > > > > MOVE the effing buttons yourself! It's easy, really. > > doesn't change the fact that they should not have been moved from the > right in the first place. > > first rule in UI design: do not move essential stuff with no extremely > good reasons. > > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20111019/0ad83030/attachment.htm From opensourceobscure at gmail.com Wed Oct 19 00:45:30 2011 From: opensourceobscure at gmail.com (opensourceobscure) Date: Wed, 19 Oct 2011 09:45:30 +0200 Subject: [opensource-dev] FUI project just out - no more sidebar In-Reply-To: References: <201110190841.48832.Lance.Corrimal@eregion.de> <4E9E71C1.3020807@gmail.com> <201110190852.39976.Lance.Corrimal@eregion.de> Message-ID: Is this thread going anywhere? On Wed, Oct 19, 2011 at 09:43, Paul Preibisch wrote: > I agree - my first thought was, wow - its gonna be hard getting stuff from > the left now, when I am used to accessing it from the right. ?Best option: > leave it on the right, but make it movable to the left via drag and drop. > > On Wed, Oct 19, 2011 at 3:52 PM, Lance Corrimal > wrote: >> >> Am Mittwoch, 19. Oktober 2011 schrieb Ardy Lay: >> >> > > why the eff are those buttons on the left instead of the right >> > > where we all would expect them to be after around 2 years of >> > > sidebar? >> > >> > MOVE the effing buttons yourself! ?It's easy, really. >> >> doesn't change the fact that they should not have been moved from the >> right in the first place. >> >> first rule in UI design: do not move essential stuff with no extremely >> good reasons. >> >> >> 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 > -- Opensource Obscure https://twitter.com/oobscure https://my.secondlife.com/opensource.obscure Join this group to discuss Second Life Viewer: https://j.mp/slv2group From kuraiko at gmx.net Wed Oct 19 00:47:11 2011 From: kuraiko at gmx.net (Kuraiko Yoshikawa) Date: Wed, 19 Oct 2011 09:47:11 +0200 Subject: [opensource-dev] Fwd: Re: FUI project just out - no more sidebar In-Reply-To: <4E9E7FFA.5060501@gmx.net> References: <4E9E7FFA.5060501@gmx.net> Message-ID: <4E9E807F.8010807@gmx.net> On 19.10.2011 04:03, Jonathan Welch wrote: > The new FUI project just got merged in to viewer-development. Yay! Looks good. It is a good beginning much better as the Viewer 2 UI... @devs: It would be nice when the align of the colums were adjustable too. Right/Left: Top, Center, Bottom and the Bottom column left, center, right -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20111019/270b2be5/attachment.htm From hitomi.tiponi at yahoo.co.uk Wed Oct 19 01:14:22 2011 From: hitomi.tiponi at yahoo.co.uk (Hitomi Tiponi) Date: Wed, 19 Oct 2011 09:14:22 +0100 (BST) Subject: [opensource-dev] FUI project just out Message-ID: <1319012062.39768.YahooMailNeo@web23904.mail.ird.yahoo.com> I also agree with Arrehn's assessment - and welcome the changes made by FUI. It is a shame that these ideas were not run past some ordinary (i.e. non-techie) users at a group such as the Viewer Evolution User Group to gauge user opinion and priorities on various issues before deciding on design directions.? Hopefully now these changes have been released that the team will work with the user community to further improve it; we all want these changes to improve the user experience - so let us all work together to make sure that they do. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20111019/b3f02aba/attachment.htm From jhwelch at gmail.com Wed Oct 19 01:57:33 2011 From: jhwelch at gmail.com (Jonathan Welch) Date: Wed, 19 Oct 2011 04:57:33 -0400 Subject: [opensource-dev] FUI project just out In-Reply-To: <1319012062.39768.YahooMailNeo@web23904.mail.ird.yahoo.com> References: <1319012062.39768.YahooMailNeo@web23904.mail.ird.yahoo.com> Message-ID: I have good first impressions of this change, but there also need to be some tweaks made to it: Notification well at top right is always on top of floaters, so I cannot have any floater flush right any more Allow notification well to be moved to bottom right Change default of left docked buttons to right docked. I think this will cause less of a shock to users when this viewer goes into release Allow buttons to be located other than centered, at least let us have the option for flush left/right/top/bottom I have lost a lot of space at the bottom of the screen due to buttons being centered there so I have to have the chat input box above them or else shrunk to a useless size (apparently no one tests designs on a 1028x768 screen) If you are going to have button layout per-user add a drop-down to the layout floater so we can pick an existing layout from another account Add text-only option for icons Remove title bar from mini-map floater (this is probably a bug/regression) On Wed, Oct 19, 2011 at 4:14 AM, Hitomi Tiponi wrote: > I also agree with Arrehn's assessment - and welcome the changes made by FUI. > It is a shame that these ideas were not run past some ordinary (i.e. > non-techie) users at a group such as the Viewer Evolution User Group to > gauge user opinion and priorities on various issues before deciding on > design directions. Hopefully now these changes have been released that the > team will work with the user community to further improve it; we all want > these changes to improve the user experience - so let us all work together > to make sure that they do. > > _______________________________________________ > 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 > From secret.argent at gmail.com Wed Oct 19 04:20:10 2011 From: secret.argent at gmail.com (Argent Stonecutter) Date: Wed, 19 Oct 2011 06:20:10 -0500 Subject: [opensource-dev] FUI project just out - no more sidebar In-Reply-To: <0012F31F-87FA-4559-84D3-D1D77F849593@geenzo.com> References: <0012F31F-87FA-4559-84D3-D1D77F849593@geenzo.com> Message-ID: On 2011-10-18, at 21:09, Geenz wrote: > I can't be the only one who thinks that window management needs to be re-thought for FUI. As it stands, it seems as if that actually took a step backwards. One thing that's an immediate show-stopper for me: chat as a separate floater. After all the debate over chat in 2.x, how could they even further marginalize it? From oz at lindenlab.com Wed Oct 19 05:25:03 2011 From: oz at lindenlab.com (Oz Linden (Scott Lawrence)) Date: Wed, 19 Oct 2011 08:25:03 -0400 Subject: [opensource-dev] FUI project just out - no more sidebar In-Reply-To: <201110190852.39976.Lance.Corrimal@eregion.de> References: <201110190841.48832.Lance.Corrimal@eregion.de> <4E9E71C1.3020807@gmail.com> <201110190852.39976.Lance.Corrimal@eregion.de> Message-ID: <4E9EC19F.6080102@lindenlab.com> On 2011-10-19 2:52, Lance Corrimal wrote: > first rule in UI design: do not move essential stuff with no extremely > good reasons. Maybe they wanted you to discover that you could move them? Sounds like an ok reason to me... From wolfpup67 at earthlink.net Wed Oct 19 05:51:03 2011 From: wolfpup67 at earthlink.net (WolfPup Lowenhar) Date: Wed, 19 Oct 2011 08:51:03 -0400 Subject: [opensource-dev] Viewer UI mode merge In-Reply-To: <4E9E3435.2070407@gmail.com> References: <4E9DF7E3.20509@lindenlab.com> <4E9E3435.2070407@gmail.com> Message-ID: <001201cc8e5d$c317ee90$4947cbb0$@net> For those of us that attend the in world meetings concerning the viewer it had been know that this was coming for a couple of months and I has even had a discussion with some of the UI team personally concerning some aspects of the UI both in world and via email some of which even included sending a snapshot of Firestorms UI with it in the Starlight Silver/Blue theme. So to me this is no surprise. Now for my personal taste it look like ill have to go in and edit some of the background png files again so that they are semi-transparent again at least locally for me. > -----Original Message----- > From: opensource-dev-bounces at lists.secondlife.com [mailto:opensource-dev- > bounces at lists.secondlife.com] On Behalf Of Kadah > Sent: Tuesday, October 18, 2011 10:22 PM > To: Arrehn Oberlander > Cc: Viewer > Subject: Re: [opensource-dev] Viewer UI mode merge > > On 10/18/2011 7:20 PM, Arrehn Oberlander wrote: > > Thanks for sharing Oz, > > > > Although I like the general direction of the improvements and believe > > they have good potential, I feel the obligation to point out to your own > > presentation with Esbee and Qarl two years ago coming off of the > > difficult Viewer 2 rollout, where the three of you stood up before > > everyone at SLCC and told us that LL wasn't going drop these large UI > > rewrites on the community as surprises. > > > > I'm glad it's there, I think it has potential, but the communication and > > coordination with the greater development community was poor at best, > > and at worst, contrary to what LL directly communicated. > > > > It would perhaps have been better to have these as project viewers well > > in advance of a sweeping merge. > > +1 > _______________________________________________ > 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 > ----- > No virus found in this message. > Checked by AVG - www.avg.com > Version: 2012.0.1831 / Virus Database: 2092/4559 - Release Date: 10/18/11 From mike.chase at alternatemetaverse.com Wed Oct 19 07:34:38 2011 From: mike.chase at alternatemetaverse.com (Mike Chase) Date: Wed, 19 Oct 2011 10:34:38 -0400 Subject: [opensource-dev] Viewer UI mode merge In-Reply-To: <4E9DF7E3.20509@lindenlab.com> References: <4E9DF7E3.20509@lindenlab.com> Message-ID: <4E9EDFFE.80603@alternatemetaverse.com> On 10/18/2011 06:04 PM, Oz Linden (Scott Lawrence) wrote: > > Today the Viewer UI mode merge project is coming to > viewer-development. This project combines basic and advanced modes > and brings an updated, more flexible workspace to the Viewer. > > One thing I've notice in this viewer and a few recent dev builds... Using the mouse wheel to scroll a window only works when I'm hovering over the scroll bar on the right. Doing it over the window (inventory list, notecard, etc) doesn't work. This is on Linux FWIW. Is that intentional? It's a major departure from the standard desktop UI behaviour for all the other scrollable windows on my system. Mike -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20111019/940d7e88/attachment-0001.htm From garmin.kawaguichi at magalaxie.com Wed Oct 19 08:00:21 2011 From: garmin.kawaguichi at magalaxie.com (Garmin Kawaguichi) Date: Wed, 19 Oct 2011 17:00:21 +0200 Subject: [opensource-dev] Viewer UI mode merge References: <4E9DF7E3.20509@lindenlab.com> <4E9EDFFE.80603@alternatemetaverse.com> Message-ID: Under Windows Vista and with Viewer SL 3.2.0 (243350) I have the same issue. Note that for "ABOUT SECOND LIFE" window the scroll works as usual GCI ----- Original Message ----- From: Mike Chase Sent: Wednesday, October 19, 2011 4:34 PM Subject: Re: [opensource-dev] Viewer UI mode merge ...Using the mouse wheel to scroll a window only works when I'm hovering over the scroll bar on the right. Doing it over the window (inventory list, notecard, etc) doesn't work. This is on Linux FWIW. Is that intentional? It's a major departure from the standard desktop UI behaviour for all the other scrollable windows on my system. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20111019/a5afbd9c/attachment.htm From hitomi.tiponi at yahoo.co.uk Wed Oct 19 08:38:59 2011 From: hitomi.tiponi at yahoo.co.uk (Hitomi Tiponi) Date: Wed, 19 Oct 2011 16:38:59 +0100 (BST) Subject: [opensource-dev] Viewer UI mode merge Message-ID: <1319038739.9988.YahooMailNeo@web23905.mail.ird.yahoo.com> There is a lot of really good stuff in this release including some icons that look similar to those used in Firestorm and StarLight - so especially like them :).? Some are a bit odd, like the mini-map which I would use for a radar instead, but generally they are of a high quality. Were any non-techie users involved in these discussions I wonder - after all a lot of users who use SL just for socialising have very different requirements, especially with regards to chat/IMs? >For those of us that attend the in world meetings concerning the viewer it >had been know that this was coming for a couple of months and I has even had >a discussion with some of the UI team personally concerning some aspects of >the UI both in world and via email some of which even included sending a >snapshot of Firestorms UI with it in the Starlight Silver/Blue theme. So to >me this is no surprise. Now for my personal taste it look like ill have to >go in and edit some of the background png files again so that they are >semi-transparent again at least locally for me. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20111019/9f5f8201/attachment.htm From kf6kjg at gmail.com Wed Oct 19 08:51:52 2011 From: kf6kjg at gmail.com (Ricky) Date: Wed, 19 Oct 2011 08:51:52 -0700 Subject: [opensource-dev] Missing details in Snowstorm development builds In-Reply-To: <1318863335.33502.YahooMailNeo@web23907.mail.ird.yahoo.com> References: <1318863335.33502.YahooMailNeo@web23907.mail.ird.yahoo.com> Message-ID: Yes, the last one to note any "Changes since last good build" or "Jiras" was revision 242386 completed on Wed Oct 05 2011 16:43:20 GMT-0700 (PDT). Beyond that, void. No knowing what the changes were unless you subscribe to another list somewheres... Why is it broken? Dunno, my intuition says that it looks like some API broke. Ricky Cron Stardust On Mon, Oct 17, 2011 at 7:55 AM, Hitomi Tiponi wrote: > > I have noticed that the fields 'Changes since last good build' and 'Jiras' > on the Snowtorm Viewer development build are repeatedly showing as 'None' > for more than a weeknow - despite the fact that there are clearly changes > and responses to JIRAs being implemented. > > It is quite useful to see what a build addresses so I wondered if this was > deliberate or a bug you can fix? > > Thanks. > > _______________________________________________ > 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 > From oz at lindenlab.com Wed Oct 19 08:56:30 2011 From: oz at lindenlab.com (Oz Linden (Scott Lawrence)) Date: Wed, 19 Oct 2011 11:56:30 -0400 Subject: [opensource-dev] Missing details in Snowstorm development builds In-Reply-To: <1318863335.33502.YahooMailNeo@web23907.mail.ird.yahoo.com> References: <1318863335.33502.YahooMailNeo@web23907.mail.ird.yahoo.com> Message-ID: <4E9EF32E.1080902@lindenlab.com> On 2011-10-17 10:55, Hitomi Tiponi wrote: > > I have noticed that the fields 'Changes since last good build' and > 'Jiras' on the Snowtorm Viewer development build are repeatedly > showing as 'None' for more than a weeknow - despite the fact that > there are clearly changes and responses to JIRAs being implemented. > > It is quite useful to see what a build addresses so I wondered if this > was deliberate or a bug you can fix? I've asked our tools team to look at this... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20111019/fa0ab026/attachment.htm From Lance.Corrimal at eregion.de Wed Oct 19 09:14:42 2011 From: Lance.Corrimal at eregion.de (Lance Corrimal) Date: Wed, 19 Oct 2011 18:14:42 +0200 Subject: [opensource-dev] FUI project just out - no more sidebar In-Reply-To: <4E9EC19F.6080102@lindenlab.com> References: <201110190852.39976.Lance.Corrimal@eregion.de> <4E9EC19F.6080102@lindenlab.com> Message-ID: <201110191814.42908.Lance.Corrimal@eregion.de> Am Mittwoch 19 Oktober 2011 schrieb Oz Linden (Scott Lawrence): > On 2011-10-19 2:52, Lance Corrimal wrote: > > first rule in UI design: do not move essential stuff with no > > extremely good reasons. > > Maybe they wanted you to discover that you could move them? Sounds > like an ok reason to me... there are many reasons to change things, "change for the sake of change" being the least of them. From missannotoole at yahoo.com Wed Oct 19 09:39:52 2011 From: missannotoole at yahoo.com (Ann Otoole) Date: Wed, 19 Oct 2011 09:39:52 -0700 (PDT) Subject: [opensource-dev] Viewer UI mode merge In-Reply-To: <1319038739.9988.YahooMailNeo@web23905.mail.ird.yahoo.com> References: <1319038739.9988.YahooMailNeo@web23905.mail.ird.yahoo.com> Message-ID: <1319042392.28248.YahooMailNeo@web120526.mail.ne1.yahoo.com> From vexstreeter at gmail.com Wed Oct 19 09:48:02 2011 From: vexstreeter at gmail.com (Vex Streeter) Date: Wed, 19 Oct 2011 12:48:02 -0400 Subject: [opensource-dev] Viewer UI mode merge In-Reply-To: <4E9DF7E3.20509@lindenlab.com> References: <4E9DF7E3.20509@lindenlab.com> Message-ID: <4E9EFF42.20502@gmail.com> Dare I ask if there's been any thought during the FUI project about "tear off to separate rooted window" support? e.g. VWR-467 -Vex From trilobyte550m at gmail.com Wed Oct 19 09:48:17 2011 From: trilobyte550m at gmail.com (Trilo Byte) Date: Wed, 19 Oct 2011 09:48:17 -0700 Subject: [opensource-dev] FUI project just out - no more sidebar In-Reply-To: <201110191814.42908.Lance.Corrimal@eregion.de> References: <201110190852.39976.Lance.Corrimal@eregion.de> <4E9EC19F.6080102@lindenlab.com> <201110191814.42908.Lance.Corrimal@eregion.de> Message-ID: <3E5C9B6F-D4AE-4800-8A8D-5A02ADEAE8E9@gmail.com> I definitely like the direction it's heading, but a few things jump out... 1) How do I change/edit my picks? 2) User-definable shortcut keys would be the perfect compliment to this (currently no shortcut for appearance, opening additional inventory windows, etc) 3) How about that awesome draw distance slider we tested last June as an optional UI component? 4) Can the position of the group/IM chiclets and notification popups be changed (via user preferences)? 5) Is there a preferences setting for disabling the Favorites portion of the "LM & Favorites" toolbar? I also notice a 2 second delay when opening an inventory window. Opening other windows or closing the inventory window happens instantaneously, but opening a window has a pronounced delay. You can no longer use cmd-shift-I (on the Mac client) to open additional inventory windows, but opening additional windows through the gear menu also results in a delayed opening. Rendering performance also seems to take a hit with build 243327. Since changelogs/JIRA lists aren't included on the build/download pages, I don't know if this is because of some other change to the viewer, or if it's the direct result of the user interface project. TriloByte Zanzibar From trilobyte550m at gmail.com Wed Oct 19 10:02:52 2011 From: trilobyte550m at gmail.com (Trilo Byte) Date: Wed, 19 Oct 2011 10:02:52 -0700 Subject: [opensource-dev] Broken scrolling In-Reply-To: References: <4E9DF7E3.20509@lindenlab.com> <4E9EDFFE.80603@alternatemetaverse.com> Message-ID: <566B485A-45EC-4338-B069-47834C6C4763@gmail.com> Scrolling has not been working properly on the Mac client in recent builds either. VWR-27175 On Oct 19, 2011, at 8:00 AM, Garmin Kawaguichi wrote: > Under Windows Vista and with Viewer SL 3.2.0 (243350) I have the same issue. > > Note that for "ABOUT SECOND LIFE" window the scroll works as usual > > GCI > ----- Original Message ----- > From: Mike Chase > Sent: Wednesday, October 19, 2011 4:34 PM > Subject: Re: [opensource-dev] Viewer UI mode merge > ...Using the mouse wheel to scroll a window only works when I'm hovering over the scroll bar on the right. Doing it over the window (inventory list, notecard, etc) doesn't work. This is on Linux FWIW. Is that intentional? It's a major departure from the standard desktop UI behaviour for all the other scrollable windows on my system. > > _______________________________________________ > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20111019/45abd0fb/attachment.htm From oz at lindenlab.com Wed Oct 19 12:35:36 2011 From: oz at lindenlab.com (Oz Linden) Date: Wed, 19 Oct 2011 19:35:36 -0000 Subject: [opensource-dev] Review Request: storm-1622: fix wind eddies Message-ID: <20111019193536.17042.45241@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/503/ ----------------------------------------------------------- Review request for Viewer. Summary ------- The implementation in the viewer of the local wind eddies was too closely coupled to that of the Classic Clouds, so that when the clouds were removed in v2.8 the local wind eddies were broken. This change removes that coupling (along with a few vestigial bits of the classic clouds) and restores the wind eddies. It turned out that there was also some debug code for visualizing the wind, so I attached that to the Develop>Render Metadata menu (Wind Vectors), adjusting it so that it displays the vectors 25 meters above the avatar (attaching screenshots to the jira issue). Thanks are due to Runitai Linden for help with this part. This addresses bug storm-1622. http://jira.secondlife.com/browse/storm-1622 Diffs ----- indra/newview/llglsandbox.cpp 913d90c3225b indra/newview/llviewermenu.cpp 913d90c3225b indra/newview/llwind.h 913d90c3225b indra/newview/llwind.cpp 913d90c3225b indra/newview/pipeline.h 913d90c3225b indra/newview/pipeline.cpp 913d90c3225b indra/newview/skins/default/xui/en/menu_viewer.xml 913d90c3225b Diff: http://codereview.secondlife.com/r/503/diff Testing ------- Tested with particles that are sensitive to wind, and the excellent demonstration site linked in the jira issue. Thanks, Oz -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20111019/d1d86672/attachment.htm From kf6kjg at gmail.com Wed Oct 19 13:40:46 2011 From: kf6kjg at gmail.com (Ricky) Date: Wed, 19 Oct 2011 13:40:46 -0700 Subject: [opensource-dev] FUI project just out - no more sidebar In-Reply-To: <3E5C9B6F-D4AE-4800-8A8D-5A02ADEAE8E9@gmail.com> References: <201110190852.39976.Lance.Corrimal@eregion.de> <4E9EC19F.6080102@lindenlab.com> <201110191814.42908.Lance.Corrimal@eregion.de> <3E5C9B6F-D4AE-4800-8A8D-5A02ADEAE8E9@gmail.com> Message-ID: Erm... build 243327 says that it's still in progress... Are you sure that's the version you tested against? http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repo/snowstorm_viewer-development/rev/243327/index.html Ricky Cron Stardust On Wed, Oct 19, 2011 at 9:48 AM, Trilo Byte wrote: > I definitely like the direction it's heading, but a few things jump out... > > 1) How do I change/edit my picks? > 2) User-definable shortcut keys would be the perfect compliment to this (currently no shortcut for appearance, opening additional inventory windows, etc) > 3) How about that awesome draw distance slider we tested last June as an optional UI component? > 4) Can the position of the group/IM chiclets and notification popups be changed (via user preferences)? > 5) Is there a preferences setting for disabling the Favorites portion of the "LM & Favorites" toolbar? > > I also notice a 2 second delay when opening an inventory window. ?Opening other windows or closing the inventory window happens instantaneously, but opening a window has a pronounced delay. ?You can no longer use cmd-shift-I (on the Mac client) to open additional inventory windows, but opening additional windows through the gear menu also results in a delayed opening. > > Rendering performance also seems to take a hit with build 243327. ?Since changelogs/JIRA lists aren't included on the build/download pages, I don't know if this is because of some other change to the viewer, or if it's the direct result of the user interface project. > > TriloByte Zanzibar > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting privileges > From jhwelch at gmail.com Wed Oct 19 14:32:42 2011 From: jhwelch at gmail.com (Jonathan Welch) Date: Wed, 19 Oct 2011 17:32:42 -0400 Subject: [opensource-dev] Eliminate VS2010 LNK4099 errors In-Reply-To: <1318961429.61659.YahooMailNeo@web43511.mail.sp1.yahoo.com> References: <4E9DA12D.7@lindenlab.com> <1318961429.61659.YahooMailNeo@web43511.mail.sp1.yahoo.com> Message-ID: I've done a little more testing. There are two steps I had to perform to eliminate those pesky messages. 1: Hack link.exe and patch out the 4099 code 2: Add /ignore:4099 to the link command line On Tue, Oct 18, 2011 at 2:10 PM, Nicky Perian wrote: > Deliver the *pdb files with each library as is done with vorbis_static > within 3p-ogvorbis' build-cmd.sh. > > ________________________________ > From: Oz Linden (Scott Lawrence) > To: opensource-dev at lists.secondlife.com > Sent: Tuesday, October 18, 2011 10:54 AM > Subject: Re: [opensource-dev] Eliminate VS2010 LNK4099 errors > > On 2011-10-17 20:41, Jonathan Welch wrote: >> I've got tired of seeing blasts of LNK4099 errors fly up the screen >> when I compile so I looked into how to eliminate them. It seems the >> only way to do this is to hack link.exe and change the 4 bytes that >> equal 4099 to something else. See >> http://www.bottledlight.com/docs/lnk4099.html >> >> In my case this was at location 15a0. > > I don't think we're going to officially suggest doing that.... :-) >> Of course it would be nice if the files in question did not cause this >> to happen in the first place. > > Anyone know how to make that happen? > > _______________________________________________ > 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 > From bryon at slearth.com Wed Oct 19 18:13:59 2011 From: bryon at slearth.com (Bryon) Date: Wed, 19 Oct 2011 18:13:59 -0700 Subject: [opensource-dev] FUI project just out - no more sidebar In-Reply-To: <201110190841.48832.Lance.Corrimal@eregion.de> Message-ID: I would assume it's the first step to have them on either side in user prefs down the road... What I'd like to see with those left/right buttons is a full Dock Behavior much like the Mac OS Dock or A-dock app that: 1. Automatically hide and show when moving to the edge of the screen or corner (optional) 2. Automatically expand the dock (optional) 3. Have those buttons optionally show as image or text or both, using a similar approach as that of Adobe apps and the way panels open to the left along right side buttons. (The big mistake in V2 being that the buttons moved alongs with the panel which was very disorienting) 4. Give the same flexibility to that left/right dock as the new customizable approach for the bottom buttons. That way, on top of the Windows like approach on the bottom (reminiscent of the old v1 buttons that people are familiar with) you'd give more Mac/Dock like approach on the sides with the ability to place every item with either method at the user's preferences. The other thing we need get away from, are left and right sliding navigation within a panel/window which is not very good for this environment, as much is it for touch devices... On desktop computers the expectation is tabs over inner-window left and right sliders. And talking of Tabs I am not sure the "My" word prefixes all over (like 'My Textures', 'My Inventory' etc) are needed. It makes tabs longer that needed, and by definition "My" is already implied. i.e. What you are looking at is YOUR stuff not the neighbors... The UI is far from being Glorious but in a fairly good re-direction so far. Bryon On 10/18/11 11:41 PM, "Lance Corrimal" wrote: >Am Mittwoch, 19. Oktober 2011 schrieb Jonathan Welch: >> The new FUI project just got merged in to viewer-development. No >> more sidebar! Attached you can see there are buttons on the >> bottom and left. There's also a column you can move them to on >> the right which starts out unpopulated. For each of the 3 zones >> you can have icons or icons+labels and move buttons around or >> eliminate ones you don't want. > >why the eff are those buttons on the left instead of the right where >we all would expect them to be after around 2 years of sidebar? > >do "they" want to screw with users minds? > >other than that it looks fine. > >I'll give it a more in-deep once my local v-d has built. > > >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 From dave at meadowlakearts.com Wed Oct 19 19:11:48 2011 From: dave at meadowlakearts.com (Dave Booth) Date: Wed, 19 Oct 2011 21:11:48 -0500 Subject: [opensource-dev] Weird issue with mouselook flight in newer viewers Message-ID: <4E9F8364.7040300@meadowlakearts.com> Where did the limits on mouselook angle come from in the newer builds? In current development a mouselook-steered aircraft cant pitch up beyond 80 degrees and cant pitch down beyond 40. It's got to be in the viewer code somewhere because using TPVs like the current Firestorm beta I can pitch freely between +90 and -90 in the same vehicle. This is breaking a LOT of existing content, every aircraft that uses ML steering. Any ideas, folks? It's hard to notice without fully functional flight instruments but its a real problem - when a flight envelope can change just based on the version of viewer code aircraft combat is blown into a cocked hat... From CronoCloud at mchsi.com Thu Oct 20 07:23:38 2011 From: CronoCloud at mchsi.com (Ron Rogers Jr.) Date: Thu, 20 Oct 2011 09:23:38 -0500 Subject: [opensource-dev] Viewer UI mode merge In-Reply-To: <4E9EDFFE.80603@alternatemetaverse.com> References: <4E9DF7E3.20509@lindenlab.com> <4E9EDFFE.80603@alternatemetaverse.com> Message-ID: <20111020092338.43efa8b7.CronoCloud_mchsi.com@mchsi.com> On Wed, 19 Oct 2011 10:34:38 -0400 Mike Chase wrote: > > One thing I've notice in this viewer and a few recent dev > builds... Using the mouse wheel to scroll a window only works when > I'm hovering over the scroll bar on the right. Doing it over the > window (inventory list, notecard, etc) doesn't work. This is on > Linux FWIW. Is that intentional? It's a major departure from the > standard desktop UI behaviour for all the other scrollable windows > on my system. > > Mike > I can confirm....I think it's because of the highlight rectangle it puts over itemss that the mouse hovers over. Very annoying. I'm running Linux as well. CronoCloud -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/opensource-dev/attachments/20111020/7e8347f3/attachment.pgp From CronoCloud at mchsi.com Thu Oct 20 07:48:50 2011 From: CronoCloud at mchsi.com (Ron Rogers Jr.) Date: Thu, 20 Oct 2011 09:48:50 -0500 Subject: [opensource-dev] FUI project just out - no more sidebar In-Reply-To: References: Message-ID: <20111020094850.1a726114.CronoCloud_mchsi.com@mchsi.com> On Tue, 18 Oct 2011 22:03:17 -0400 Jonathan Welch wrote: > The new FUI project just got merged in to viewer-development. No > more sidebar! I kind of liked the sidebar, everything in one place, and it didn't block my "view" but I can "sort of" mimic the behavior with the new buttons. Also notifications in upper right, as the Grid intended. A few things I noticed. 1. I have no choice in vertical positioning of buttons. I want the UI buttons at the right to be "top right, not middle right" That way I can have my inventory/friends/groups windows in "middle right" Sidebar style So it would be nice to be able to move the buttons anywhere on the docks and have them stay put. The dock buttons also need auto-hide, so I can put windows on the right and left and have the docks "pop-over" 2. I miss the firefox style search bar in the navigation toolbar. To me it made total sense to have it there. I miss it a LOT. I'm not for certain combining navigation and favorites toolbars was a good idea though I do like the behavior of the "more" button on the favorites. 3. The "UI viewer" will immediately crash on launch....unless you delete your preferences and start over from scratch. 4. Notifications still aren't big enough to show enough text. I think they use the "medium" size which is too big. Have notifications respect chat-font size choices, that will help. 5. Certain windows don't seem remember location. Inventory does, but friends list doesn't. 6. I've noticed that delay opening inventory windows, and it's only with the inventory window. That's all I've noticed...so far. CronoCloud -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/opensource-dev/attachments/20111020/20c2b565/attachment-0001.pgp From kf6kjg at gmail.com Thu Oct 20 09:06:08 2011 From: kf6kjg at gmail.com (Ricky) Date: Thu, 20 Oct 2011 09:06:08 -0700 Subject: [opensource-dev] Weird issue with mouselook flight in newer viewers In-Reply-To: <4E9F8364.7040300@meadowlakearts.com> References: <4E9F8364.7040300@meadowlakearts.com> Message-ID: Those angle limits have been in place for many, many years. Though I agree that having them has little purpose, they have, nevertheless been there the whole time. Ricky Cron Stardust On Wed, Oct 19, 2011 at 7:11 PM, Dave Booth wrote: > Where did the limits on mouselook angle come from in the newer builds? > In current development a mouselook-steered aircraft cant pitch up beyond > 80 degrees and cant pitch down beyond 40. It's got to be in the viewer > code somewhere because using TPVs like the current Firestorm beta I can > pitch freely between +90 and -90 in the same vehicle. This is breaking a > LOT of existing content, every aircraft that uses ML steering. Any > ideas, folks? It's hard to notice without fully functional flight > instruments but its a real problem - when a flight envelope can change > just based on the version of viewer code aircraft combat is blown into a > cocked hat... > _______________________________________________ > 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 > From kadah.coba at gmail.com Thu Oct 20 10:23:45 2011 From: kadah.coba at gmail.com (Kadah) Date: Thu, 20 Oct 2011 10:23:45 -0700 Subject: [opensource-dev] FUI project just out - no more sidebar In-Reply-To: References: <0012F31F-87FA-4559-84D3-D1D77F849593@geenzo.com> Message-ID: <4EA05921.7090300@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/19/2011 4:20 AM, Argent Stonecutter wrote: > On 2011-10-18, at 21:09, Geenz wrote: >> I can't be the only one who thinks that window management needs >> to be re-thought for FUI. As it stands, it seems as if that >> actually took a step backwards. > > One thing that's an immediate show-stopper for me: chat as a > separate floater. > > After all the debate over chat in 2.x, how could they even further > marginalize it? To me local chat is the same since 2.0, except now the local chat log and chat bar panels are in the same floater. I agree that it should be a stopper, but I have thought since 2.0 beta. Sadly it only a small effort to add docking support to local chat in to conversations. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJOoFkhAAoJEIdLfPRu7qE2qykIAKQUtD+qTWFMd1f6bffvy16J 3O02NvUdJNq143Dn8kCTjnN4jW3nLAO9PfmvFTHVycPonr0tcMYnDyQtS3/flGLH NH3NRV4F6prLzYDSlzojNXanpbQ83ADH5zlKIBWIBd9q5Be47wGFiwn8dcacS1iN AlXG06B+PZ7hJW5qpjN1xQfo51y9iYDAxNAkuQijqi+uFJ0mXnWTAM3X1IAB/1Sk 4fMi3WtqXi+U0ln//RbK/aYv5C0dn62Cy04toVFC+GqbE5GYcTnjEOgzjfVeS3dw MDk7aNH25H927QSwneBuZFMNVB0dcjFm2MNRh4ddJA57MEa6wiPpP2jT0/b0b6M= =8c3H -----END PGP SIGNATURE----- From kadah.coba at gmail.com Thu Oct 20 10:30:48 2011 From: kadah.coba at gmail.com (Kadah) Date: Thu, 20 Oct 2011 10:30:48 -0700 Subject: [opensource-dev] FUI project just out - no more sidebar In-Reply-To: <4E9EC19F.6080102@lindenlab.com> References: <201110190841.48832.Lance.Corrimal@eregion.de> <4E9E71C1.3020807@gmail.com> <201110190852.39976.Lance.Corrimal@eregion.de> <4E9EC19F.6080102@lindenlab.com> Message-ID: <4EA05AC8.1090107@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/19/2011 5:25 AM, Oz Linden (Scott Lawrence) wrote: > On 2011-10-19 2:52, Lance Corrimal wrote: >> first rule in UI design: do not move essential stuff with no >> extremely good reasons. > > Maybe they wanted you to discover that you could move them? Sounds > like an ok reason to me... I'm gonna guess that was the reason for removing Map as well, make me figure out how to add it back before I can use it. I noticed that the ctrl+M shortcut wouldn't actually work till I added the button back at least once per profile. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJOoFrIAAoJEIdLfPRu7qE2fY4H/RLoSavbGXQ8Jndk+EaQs9M/ 6jMiFBB769PqzB4G2N/O7TKgundeKCHew0XgnOghX1jtveC9YHtkqnTHq4ZV3ea0 wKtvsMHucKD0RN/KjfidDzqKO3flPUYr2gdRclxoj1G6+sNKptDVOizUu59wcvIt fM/DYKNcjqTsvRuIn77BSOLJEzHHR1X3Y9epW88Ow2UEgFDn7yuZLq1qaNV8IZUM X8c6O5oDAvHSWQb2Fk+b7Iwwbtk+a127p8i+GY3OD3vqbhcq6g2+hW+jCP9LnvfB n7jcMY69BjARpI4ttPcDzO6sTQv2DU/GRUGXBrECTCWmnZegT3YtdowM56xC9j0= =5UxU -----END PGP SIGNATURE----- From oz at lindenlab.com Thu Oct 20 11:22:14 2011 From: oz at lindenlab.com (Oz Linden) Date: Thu, 20 Oct 2011 18:22:14 -0000 Subject: [opensource-dev] Review Request: storm-1622: fix wind eddies In-Reply-To: <20111019193536.17042.45241@domU-12-31-38-00-90-68.compute-1.internal> References: <20111019193536.17042.45241@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20111020182214.17120.43314@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/503/ ----------------------------------------------------------- (Updated Oct. 20, 2011, 11:22 a.m.) Review request for Viewer and David Parks. Summary ------- The implementation in the viewer of the local wind eddies was too closely coupled to that of the Classic Clouds, so that when the clouds were removed in v2.8 the local wind eddies were broken. This change removes that coupling (along with a few vestigial bits of the classic clouds) and restores the wind eddies. It turned out that there was also some debug code for visualizing the wind, so I attached that to the Develop>Render Metadata menu (Wind Vectors), adjusting it so that it displays the vectors 25 meters above the avatar (attaching screenshots to the jira issue). Thanks are due to Runitai Linden for help with this part. This addresses bug storm-1622. http://jira.secondlife.com/browse/storm-1622 Diffs ----- indra/newview/llglsandbox.cpp 913d90c3225b indra/newview/llviewermenu.cpp 913d90c3225b indra/newview/llwind.h 913d90c3225b indra/newview/llwind.cpp 913d90c3225b indra/newview/pipeline.h 913d90c3225b indra/newview/pipeline.cpp 913d90c3225b indra/newview/skins/default/xui/en/menu_viewer.xml 913d90c3225b Diff: http://codereview.secondlife.com/r/503/diff Testing ------- Tested with particles that are sensitive to wind, and the excellent demonstration site linked in the jira issue. Thanks, Oz -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20111020/c1dddbdc/attachment.htm From dave at meadowlakearts.com Thu Oct 20 11:51:11 2011 From: dave at meadowlakearts.com (Dave Booth) Date: Thu, 20 Oct 2011 13:51:11 -0500 Subject: [opensource-dev] Weird issue with mouselook flight in newer viewers In-Reply-To: References: <4E9F8364.7040300@meadowlakearts.com> Message-ID: <4EA06D9F.7010705@meadowlakearts.com> On 10/20/2011 11:06 AM, Ricky wrote: > Those angle limits have been in place for many, many years. Though I > agree that having them has little purpose, they have, nevertheless > been there the whole time. > So in other words I've been living with it without really noticing until I actually started building my own aircraft and made myself an instrument panel with a fully functional artificial horizon. I guess it's JIRA time, although its hardly going to be a high priority as it will be considered an enhancement rather than a fix. In the meantime I guess I'm switching over to Firestorm whenever I'm going to be flying through any area I might get shot at, since having a wider flight envelope than anyone using a LL viewer could well be useful :) From secret.argent at gmail.com Thu Oct 20 17:27:59 2011 From: secret.argent at gmail.com (Argent Stonecutter) Date: Thu, 20 Oct 2011 19:27:59 -0500 Subject: [opensource-dev] FUI project just out - no more sidebar In-Reply-To: <4EA05921.7090300@gmail.com> References: <0012F31F-87FA-4559-84D3-D1D77F849593@geenzo.com> <4EA05921.7090300@gmail.com> Message-ID: On 2011-10-20, at 12:23, Kadah wrote: > To me local chat is the same since 2.0, except now the local chat log > and chat bar panels are in the same floater. I agree that it should be > a stopper, but I have thought since 2.0 beta. I don't use the local chat log, I use the chat overlay. From dave at meadowlakearts.com Thu Oct 20 19:13:25 2011 From: dave at meadowlakearts.com (Dave Booth) Date: Thu, 20 Oct 2011 21:13:25 -0500 Subject: [opensource-dev] Weird issue with mouselook flight in newer viewers In-Reply-To: <4EA06D9F.7010705@meadowlakearts.com> References: <4E9F8364.7040300@meadowlakearts.com> <4EA06D9F.7010705@meadowlakearts.com> Message-ID: <4EA0D545.2090105@meadowlakearts.com> On 10/20/2011 1:51 PM, Dave Booth wrote: > > I guess it's JIRA time VWR-27241 filed, requesting removal of the mouselook limits imposed by code in /indra/newview/llagent.cpp - There is no reason to limit this so tightly and nearly all TPVs out there allow pitch between -90 and +90 without restriction. From dawn.owens at bellevue.edu Fri Oct 21 14:07:12 2011 From: dawn.owens at bellevue.edu (Dawn Owens) Date: Fri, 21 Oct 2011 16:07:12 -0500 Subject: [opensource-dev] Participate in a Second Life Research Project Message-ID: <6C76F3CE7CE30F43A79FA970B6F52EED010FA4DD48FC@BELLMAIL.bellevue.edu> I am a Doctoral candidate at the University of Nebraska at Omaha. I am doing research in Second Life as part of my dissertation research. The research study is designed to study how virtual world technology capabilities affect the development of trust in virtual teams. Participants will be paid $4,850 Linden Dollars. The attached document provides details about the research study and participant requirements. Feel free to contact me with questions. I look forward to hearing from you. Dawn Owens -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20111021/d8da9884/attachment-0001.htm -------------- next part -------------- A non-text attachment was scrubbed... Name: Letter to participants_Pilot2.pdf Type: application/pdf Size: 132200 bytes Desc: Letter to participants_Pilot2.pdf Url : http://lists.secondlife.com/pipermail/opensource-dev/attachments/20111021/d8da9884/attachment-0001.pdf From tonya.souther at gmail.com Fri Oct 21 14:28:40 2011 From: tonya.souther at gmail.com (Tonya Souther) Date: Fri, 21 Oct 2011 16:28:40 -0500 Subject: [opensource-dev] VBO on OS X: Anyone looking at this? Message-ID: I just managed to really, really piss myself off badly. I was running Firestorm on my nice fast system: dual-quad Mac Pro (first generation), 12 GB RAM, ATI 5770 graphics. I got 14.7 FPS in a 1408x939 window. Then I logged out, fired up my shiny new Windows 7/Parallels Desktop 6 virtual machine, and logged in on Firestorm there. I got 28 FPS in a 1595x848 window rendering the exact same scene. The graphics settings are identical, except that the Windows executable is using VBO and the Mac isn't. I know VBOs are broken on OS X. What's it going to take to fix them? This is just plain criminal. From aklo at skyhighway.com Sat Oct 22 16:51:10 2011 From: aklo at skyhighway.com (aklo at skyhighway.com) Date: Sat, 22 Oct 2011 16:51:10 -0700 Subject: [opensource-dev] An Idea Message-ID: <003199885872404e95c4c00ce1347fb6.squirrel@cruziomail.cruzio.com> Hey Everybody, i had an idea. My dad used to tell me that when i had one of those i should treat it kindly, 'cause it was in a strange place. "Ha-ha," huh? Anyways, what if there was a "Random TP" button or keypress or whatever? i mean, just to make things interesting?* i don't know what kind of controls or whatever might make it more (or less) practical, but i think it would be a pretty cool thing. i know i'd try it lots. Well, as soon as i get my computer fixed, anyway. Y'all rock! - AK * Some things i can think of might be: 1) to a place with more (less) than X avis there, 2) from the list of Linden Prize winners, 3) with maturity rating (not) Y, 4) dance clubs or concerts, 5) language(s) being spoken Z, ...and like that. Maybe people could sign up to be on a list of destinations, or maybe some of it could just be parsed out of info we could otherwise collect ourselves if we wanted to spend a lot of time doing it. Or maybe it could just be made out of all the places that aren't trying to keep people out? From Lance.Corrimal at eregion.de Sat Oct 22 23:38:21 2011 From: Lance.Corrimal at eregion.de (Lance Corrimal) Date: Sun, 23 Oct 2011 08:38:21 +0200 Subject: [opensource-dev] An Idea In-Reply-To: <003199885872404e95c4c00ce1347fb6.squirrel@cruziomail.cruzio.com> References: <003199885872404e95c4c00ce1347fb6.squirrel@cruziomail.cruzio.com> Message-ID: <201110230838.22226.Lance.Corrimal@eregion.de> Am Sonntag 23 Oktober 2011 schrieb aklo at skyhighway.com: > Hey Everybody, > > i had an idea. My dad used to tell me that when i had one of those > i should treat it kindly, 'cause it was in a strange place. > "Ha-ha," huh? > > Anyways, what if there was a "Random TP" button or keypress or > whatever? i mean, just to make things interesting?* i don't know > what kind of controls or whatever might make it more (or less) > practical, but i think it would be a pretty cool thing. i know > i'd try it lots. Well, as soon as i get my computer fixed, > anyway. Hum... Kinda like the "I'm feeling lucky!" button on google? Not a good idea in SL in my opinion. A random Tp to some random grid coords will take you: - underwater - to someone's private parcel - on top of someone's banline - in range of someone's security orb - on some abandoned land - on some unused mainland most of the time. not to mention the chance to get a "You have no access to that teleport destionation" without even knowing what destinaion it was would be pretty frustrating. And then there's zindra. do you really want to randomly land in zindra? now, "take me to a random showcase destination with the same maturity rating as the parcel i'm on" would be kinda cool. "take me to a random showcase destination with the same rating, that is not yet in my tp history" would be cooler. bye, LC From nexiim at gmail.com Sun Oct 23 00:16:41 2011 From: nexiim at gmail.com (Nexii Malthus) Date: Sun, 23 Oct 2011 08:16:41 +0100 Subject: [opensource-dev] An Idea In-Reply-To: <201110230838.22226.Lance.Corrimal@eregion.de> References: <003199885872404e95c4c00ce1347fb6.squirrel@cruziomail.cruzio.com> <201110230838.22226.Lance.Corrimal@eregion.de> Message-ID: Yeah, I had the same thoughts on the TP history, that property would make it a pretty good proposal. Aren't TPs already tracked via local chat log? If so, then the puzzle pieces are available to put a prototype. - Nexii Malthus On Sun, Oct 23, 2011 at 7:38 AM, Lance Corrimal wrote: > Am Sonntag 23 Oktober 2011 schrieb aklo at skyhighway.com: > > Hey Everybody, > > > > i had an idea. My dad used to tell me that when i had one of those > > i should treat it kindly, 'cause it was in a strange place. > > "Ha-ha," huh? > > > > Anyways, what if there was a "Random TP" button or keypress or > > whatever? i mean, just to make things interesting?* i don't know > > what kind of controls or whatever might make it more (or less) > > practical, but i think it would be a pretty cool thing. i know > > i'd try it lots. Well, as soon as i get my computer fixed, > > anyway. > > > Hum... Kinda like the "I'm feeling lucky!" button on google? > > Not a good idea in SL in my opinion. > > A random Tp to some random grid coords will take you: > - underwater > - to someone's private parcel > - on top of someone's banline > - in range of someone's security orb > - on some abandoned land > - on some unused mainland > > most of the time. > not to mention the chance to get a "You have no access to that > teleport destionation" without even knowing what destinaion it was > would be pretty frustrating. > And then there's zindra. do you really want to randomly land in > zindra? > > > now, "take me to a random showcase destination with the same maturity > rating as the parcel i'm on" would be kinda cool. > "take me to a random showcase destination with the same rating, that > is not yet in my tp history" would be cooler. > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20111023/7f162e6c/attachment.htm From oz at lindenlab.com Sun Oct 23 05:06:19 2011 From: oz at lindenlab.com (Oz Linden) Date: Sun, 23 Oct 2011 12:06:19 -0000 Subject: [opensource-dev] Review Request: storm-1663: widen pitch clamping on camera, make it the same for sitting Message-ID: <20111023120619.28700.61559@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/504/ ----------------------------------------------------------- Review request for Viewer. Summary ------- See linked jira issue. It's not yet clear why the existing limits were chosen, or why the limits were narrowed when sitting. This addresses bug storm-1663. http://jira.secondlife.com/browse/storm-1663 Diffs ----- indra/newview/llagent.cpp 02cd1e33128c Diff: http://codereview.secondlife.com/r/504/diff Testing ------- The changes here are essentially the same as the method used in Phoenix, so I don't expect anything catastrophic, but I'm building a test viewer to find out. Thanks, Oz -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20111023/ca799252/attachment.htm From oz at lindenlab.com Sun Oct 23 06:44:57 2011 From: oz at lindenlab.com (Oz Linden) Date: Sun, 23 Oct 2011 13:44:57 -0000 Subject: [opensource-dev] Review Request: storm-1663: widen pitch clamping on camera, make it the same for sitting In-Reply-To: <20111023120619.28700.61559@domU-12-31-38-00-90-68.compute-1.internal> References: <20111023120619.28700.61559@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20111023134457.28708.43822@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/504/ ----------------------------------------------------------- (Updated Oct. 23, 2011, 6:44 a.m.) Review request for Viewer. Summary ------- See linked jira issue. It's not yet clear why the existing limits were chosen, or why the limits were narrowed when sitting. This addresses bug storm-1663. http://jira.secondlife.com/browse/storm-1663 Diffs ----- indra/newview/llagent.cpp 02cd1e33128c Diff: http://codereview.secondlife.com/r/504/diff Testing (updated) ------- The changes here are essentially the same as the method used in Phoenix, so I don't expect anything catastrophic. test viewer at http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repo/oz_project-2/rev/243714/index.html Thanks, Oz -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20111023/99cd2565/attachment.htm From kf6kjg at gmail.com Sun Oct 23 13:45:59 2011 From: kf6kjg at gmail.com (Cron Stardust) Date: Sun, 23 Oct 2011 20:45:59 -0000 Subject: [opensource-dev] Review Request: storm-1663: widen pitch clamping on camera, make it the same for sitting In-Reply-To: <20111023134457.28708.43822@domU-12-31-38-00-90-68.compute-1.internal> References: <20111023134457.28708.43822@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20111023204559.28700.79278@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/504/#review1060 ----------------------------------------------------------- Ship it! Looks good to me. The only issue I can see is commenting to why it's limited to 1 degree off the pure limit, so as to prevent this kind of confusion again. My guess is to prevent gimbal lock - which could then be rectified a different way later in the future, for instance by eliminating the limits and using non-Euler angles to control the rotation allowing the user to rotate continuously in vertical direction like is done in the horizontal. - Cron On Oct. 23, 2011, 6:44 a.m., Oz Linden wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/504/ > ----------------------------------------------------------- > > (Updated Oct. 23, 2011, 6:44 a.m.) > > > Review request for Viewer. > > > Summary > ------- > > See linked jira issue. It's not yet clear why the existing limits were chosen, or why the limits were narrowed when sitting. > > > This addresses bug storm-1663. > http://jira.secondlife.com/browse/storm-1663 > > > Diffs > ----- > > indra/newview/llagent.cpp 02cd1e33128c > > Diff: http://codereview.secondlife.com/r/504/diff > > > Testing > ------- > > The changes here are essentially the same as the method used in Phoenix, so I don't expect anything catastrophic. > > test viewer at http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repo/oz_project-2/rev/243714/index.html > > > Thanks, > > Oz > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20111023/235213f1/attachment.htm From aklo at skyhighway.com Sun Oct 23 17:49:20 2011 From: aklo at skyhighway.com (aklo at skyhighway.com) Date: Sun, 23 Oct 2011 17:49:20 -0700 Subject: [opensource-dev] An Idea Message-ID: <211bd56767f2e3001473006227fbd64b.squirrel@cruziomail.cruzio.com> Y'all, i hadn't thought about how much of SL is someplace that would be pretty boring to tp to. i don't know what tp'ing within range of a security orb would be like, but i'll trust you if you say it it wouldn't be fun. It doesn't sound like fun, anyway. i think the things that made me think the most were the way i've looked for things to do sometimes by zooming around on the map & picking someplace with lots of avis for a place to go. About half the time that's not very exciting, but the other half has made SL worth the time! i just found out about Zindra a couple of days ago. Someone on the NCI chat told me about it. You're right. i *definitely* wouldn't want to tp there. In fact, if there was some setting i could adjust in my viewer to make sure i never went there by trick or by accident, i would use the setting *for sure*! i think i can deal with random kinda "adult content" places sort of like, "generally," but if Zindra is what i was told it was, i'd even be happier if it showed up on my map as a black hole with that red circle bar on it. The other thing about random tp'ing is the lists of places that the search gives up. It seems like there should be some easy way to keep all that stuff indexed and sorted so that a random tp could access it in several different ways. The point is, tp'ing to a place i've been before or that got randomly selected from the 3 or 4 thousand LMs i have would be a little interesting, but it would be primo if the random loc was picked from places i've never been, or at least officially "really cool" sites. i've never done the Google, "I'm feeling lucky" thing, but i think i get the idea. It's like, yeah, like that, only like, *interesting*, you know? Not just some webpage. There's billions of those and if the random coords in SL are boring and maybe dangerous, picking a random page off the Internet sounds like some wierd kind of Russian Roulette with 1 real bullet in the gun, 1 that squirts lemonade, and 4 filled with sleeping gas. i dunno. If somebody came up with a "Random TP" button, i'm sure i'd press it several times every time i went in-world, even if most of the tps were boring, gave me some hazard i had to avoid immediately, or had me tp'ing out like it couldn't happen fast enough and wishing i'd thought of wearing a biohazard space suit before i pushed the button. My curiosity has got me in trouble way more times than i like to think about! Maybe it's crazy to want to amp it out in SL, but i'll bet i'm way not the only one who'd be thumpin' that button almost by reflex. Thx, ppl!! - AK Yeah, I had the same thoughts on the TP history, that property would make it a pretty good proposal. Aren't TPs already tracked via local chat log? If so, then the puzzle pieces are available to put a prototype. - Nexii Malthus On Sun, Oct 23, 2011 at 7:38 AM, Lance Corrimal wrote: Am Sonntag 23 Oktober 2011 schrieb aklo at skyhighway.com: > Hey Everybody, > > i had an idea. My dad used to tell me that when i had one of those > i should treat it kindly, 'cause it was in a strange place. > "Ha-ha," huh? > > Anyways, what if there was a "Random TP" button or keypress or > whatever? i mean, just to make things interesting?* i don't know > what kind of controls or whatever might make it more (or less) > practical, but i think it would be a pretty cool thing. i know > i'd try it lots. Well, as soon as i get my computer fixed, > anyway. Hum... Kinda like the "I'm feeling lucky!" button on google? Not a good idea in SL in my opinion. A random Tp to some random grid coords will take you: - underwater - to someone's private parcel - on top of someone's banline - in range of someone's security orb - on some abandoned land - on some unused mainland most of the time. not to mention the chance to get a "You have no access to that teleport destionation" without even knowing what destinaion it was would be pretty frustrating. And then there's zindra. do you really want to randomly land in zindra? now, "take me to a random showcase destination with the same maturity rating as the parcel i'm on" would be kinda cool. "take me to a random showcase destination with the same rating, that is not yet in my tp history" would be cooler. 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 From dahliatrimble at gmail.com Sun Oct 23 19:08:32 2011 From: dahliatrimble at gmail.com (Dahlia Trimble) Date: Sun, 23 Oct 2011 19:08:32 -0700 Subject: [opensource-dev] An Idea In-Reply-To: <003199885872404e95c4c00ce1347fb6.squirrel@cruziomail.cruzio.com> References: <003199885872404e95c4c00ce1347fb6.squirrel@cruziomail.cruzio.com> Message-ID: 1) open map 2) zoom out all the way 3) double click somewhere works for me :) On Sat, Oct 22, 2011 at 4:51 PM, wrote: > Hey Everybody, > > i had an idea. My dad used to tell me that when i had one of those i > should treat it kindly, 'cause it was in a strange place. "Ha-ha," huh? > > Anyways, what if there was a "Random TP" button or keypress or whatever? > i mean, just to make things interesting?* i don't know what kind of > controls or whatever might make it more (or less) practical, but i think > it would be a pretty cool thing. i know i'd try it lots. Well, as soon > as i get my computer fixed, anyway. > > Y'all rock! > > - AK > > * Some things i can think of might be: 1) to a place with more (less) > than X avis there, 2) from the list of Linden Prize winners, 3) with > maturity rating (not) Y, 4) dance clubs or concerts, 5) language(s) > being spoken Z, ...and like that. Maybe people could sign up to be on a > list of destinations, or maybe some of it could just be parsed out of info > we could otherwise collect ourselves if we wanted to spend a lot of time > doing it. Or maybe it could just be made out of all the places that > aren't trying to keep people out? > > _______________________________________________ > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20111023/6bffe3a0/attachment.htm From garmin.kawaguichi at magalaxie.com Mon Oct 24 06:54:36 2011 From: garmin.kawaguichi at magalaxie.com (Garmin Kawaguichi) Date: Mon, 24 Oct 2011 15:54:36 +0200 Subject: [opensource-dev] An Idea References: <003199885872404e95c4c00ce1347fb6.squirrel@cruziomail.cruzio.com> Message-ID: <13D635D105C24934831153604F7F4C88@Deimos> >----- Original Message ----- >From: Dahlia Trimble >Sent: Monday, October 24, 2011 4:08 AM >Subject: Re: [opensource-dev] An Idea >1) open map >2) zoom out all the way >3) double click somewhere >works for me :) :))) For me too!!! GCI From tateru.nino at gmail.com Mon Oct 24 07:06:21 2011 From: tateru.nino at gmail.com (Tateru Nino) Date: Tue, 25 Oct 2011 01:06:21 +1100 Subject: [opensource-dev] An Idea In-Reply-To: <13D635D105C24934831153604F7F4C88@Deimos> References: <003199885872404e95c4c00ce1347fb6.squirrel@cruziomail.cruzio.com> <13D635D105C24934831153604F7F4C88@Deimos> Message-ID: <4EA570DD.6030105@gmail.com> On 25/10/2011 12:54 AM, Garmin Kawaguichi wrote: >> ----- Original Message ----- >> From: Dahlia Trimble >> Sent: Monday, October 24, 2011 4:08 AM >> Subject: Re: [opensource-dev] An Idea >> 1) open map >> 2) zoom out all the way >> 3) double click somewhere >> works for me :) > :))) For me too!!! That's how I do it. Semi-random 'drunkard-walk' teleports are a favourite pastime of mine. From aklo at skyhighway.com Mon Oct 24 19:20:25 2011 From: aklo at skyhighway.com (aklo at skyhighway.com) Date: Mon, 24 Oct 2011 19:20:25 -0700 Subject: [opensource-dev] An Idea Message-ID: <353d1e16a03c3131796c13b63bab99fd.squirrel@cruziomail.cruzio.com> Hey Y'all, thx for the suggestion, but that's what i already do, except i try to make it a little better chances of finding someplace interesting by picking places i see lots of avis or whatever. Like Lance & Nexii pointed out, most coords are kinda boring to tp to. They can be interesting if you tp there & then look around lots of times, but some of that's 'cause we're already not tp'ing into water or stuff like that. Tho, y'know, i've found some nice places underwater, too, so there's that. After thinking about it, my idea is more like having a random tp button that "thinks" a little bit for you so the chances you'll find an interesting place way lots better, and maybe filtered on your mood or whatever. Like, having all that info in the search sorted out so you can choose "rides" or, "shopping", or "concert" or something like that and get a random selection better than you would do yourself. Or maybe use the map knowledge the system has that would take us forever to collect so if we wanna go to a random place with more than 12 avis, or a history of lots of visits, it's way easier and lots more likely to be fun instead of boring. i mean, it would be easy, i think, to hook up a random selection of say, Linden Prize winners, but maybe there'd even be a point to it for somebody who's all into money (ick) to make it so ppl who want random visitors can pay to be on a list for ppl who are into that kind of thing. Have fun!! - AK ----------------------------------------------------------------------------- On 25/10/2011 12:54 AM, Garmin Kawaguichi wrote: >> ----- Original Message ----- >> From: Dahlia Trimble >> Sent: Monday, October 24, 2011 4:08 AM >> Subject: Re: [opensource-dev] An Idea >> 1) open map >> 2) zoom out all the way >> 3) double click somewhere >> works for me > :))) For me too!!! That's how I do it. Semi-random 'drunkard-walk' teleports are a favourite pastime of mine. _______________________________________________ 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 From jhwelch at gmail.com Tue Oct 25 06:23:42 2011 From: jhwelch at gmail.com (Jonathan Welch) Date: Tue, 25 Oct 2011 09:23:42 -0400 Subject: [opensource-dev] Question about speed of name cache query Message-ID: For my solution to Storm-1653 (Group notices sent by muted residents are still displayed) I have to call gCacheName->buildLegacyName to get the AgentID associated with a legacy name. It looks like this code may operate asynchronously if there is a cache miss. In my testing I was always able to get an AgentID back, even with a cache miss, but my tests were not being done in a lagged out region. Would someone with knowledge of the name cache tell me if it is possible for this routine to not return an AgentID; I'd like to comment my code change properly. Thank you, -Jonathan From Lance.Corrimal at eregion.de Tue Oct 25 07:00:49 2011 From: Lance.Corrimal at eregion.de (Lance Corrimal) Date: Tue, 25 Oct 2011 16:00:49 +0200 Subject: [opensource-dev] Question about speed of name cache query In-Reply-To: References: Message-ID: <201110251600.49365.Lance.Corrimal@eregion.de> All I know about name caching is this: clear your cache the hard way, by removing everything in the cache folder, then open the info tab of a group with a really high number of members, and your framerate will go to hell until all display names have been fetched. Am Dienstag 25 Oktober 2011 schrieb Jonathan Welch: > For my solution to Storm-1653 (Group notices sent by muted > residents are still displayed) I have to call > gCacheName->buildLegacyName to get the AgentID associated with a > legacy name. > > It looks like this code may operate asynchronously if there is a > cache miss. In my testing I was always able to get an AgentID > back, even with a cache miss, but my tests were not being done in > a lagged out region. > > Would someone with knowledge of the name cache tell me if it is > possible for this routine to not return an AgentID; I'd like to > comment my code change properly. > > Thank you, > > -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 From sythos at gmail.com Tue Oct 25 07:56:43 2011 From: sythos at gmail.com (Francesco "Sythos" Rabbi) Date: Tue, 25 Oct 2011 16:56:43 +0200 Subject: [opensource-dev] Question about speed of name cache query In-Reply-To: <201110251600.49365.Lance.Corrimal@eregion.de> References: <201110251600.49365.Lance.Corrimal@eregion.de> Message-ID: <-5225066862672901355@unknownmsgid> Il giorno 25/ott/2011, alle ore 16:00, Lance Corrimal < Lance.Corrimal at eregion.de> ha scritto: All I know about name caching is this: clear your cache the hard way, by removing everything in the cache folder, then open the info tab of a group with a really high number of members, and your framerate will go to hell until all display names have been fetched. Am Dienstag 25 Oktober 2011 schrieb Jonathan Welch: For my solution to Storm-1653 (Group notices sent by muted residents are still displayed) I have to call gCacheName->buildLegacyName to get the AgentID associated with a legacy name. It looks like this code may operate asynchronously if there is a cache miss. In my testing I was always able to get an AgentID back, even with a cache miss, but my tests were not being done in a lagged out region. Would someone with knowledge of the name cache tell me if it is possible for this routine to not return an AgentID; I'd like to comment my code change properly. During my experience in KV team i've tried lots of way to increase performances, pthread (actually used) have the "bad side" to hold the parent thread till the job is executed if the next token of parent thread, APR solve a bit deploying some loads on separate threads, but for intrinsic nature of pthread (APR is just a wrapper like boost::thread) the child have a lot of constraints from parent thread. This mean some code token can slow down (till hand for short time) the main thread. I've stepped in my test in 2 directions: OpenCL and OpenMP (not for "release" of KV, just few test with very few tester). OpenCL require a lot of code rewrite, i've tried just to spread main threads (cloning the main thread incipit like in macosx code, on Mac OCL is native), the performance are higher, but not so much as the pain of rewrite the code (and is a lot driver dependent, nVidia implementation and AMD/ATI one don't match fully at 100%). OCL load GPU too if main CPUs are full, this mean after a TP a overrall hang for 1-2 seconds while GPU move back to main memory their threads and begin to work as graphic unit (at least... on my system... not so high-end one) OpenMP isn't so widely appliable, is pretty nice on thread startup code (i've seen *ALL* my 4 cores loaded at 100%, just moving principal threads like whole decoding and fetching thread on other cores via OMP), but is lot interesting in "for" code, like inventory or name fecthing, OMP is very low as invasive level and need few include and few pragma around the code. OMP is native too on MacOSX, is a default installed lib on quite all linux distros, is just a DLL on windows (another 3p libs and all should work). In a child process hang or overload the core others PU can continue to work without too many slows. hoping this comment can be usefull, if more detail needed i can write more (during european evenings, now "theorically" i'm working in RL ;) ) -- Sent by iPhone -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20111025/f09e0d41/attachment.htm From vsavchuk at productengine.com Tue Oct 25 10:06:22 2011 From: vsavchuk at productengine.com (Vadim ProductEngine) Date: Tue, 25 Oct 2011 17:06:22 -0000 Subject: [opensource-dev] Review Request: STORM-1666 Redundant "Release Notes" text in the About window for non-English locales Message-ID: <20111025170622.28703.35318@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/505/ ----------------------------------------------------------- Review request for Viewer. Summary ------- Ported the XML changes made for STORM-1611 to other locales. This addresses bug STORM-1666. http://jira.secondlife.com/browse/STORM-1666 Diffs ----- indra/newview/skins/default/xui/da/floater_about.xml 08e65f3ead3d indra/newview/skins/default/xui/es/floater_about.xml 08e65f3ead3d indra/newview/skins/default/xui/ja/floater_about.xml 08e65f3ead3d indra/newview/skins/default/xui/pl/floater_about.xml 08e65f3ead3d indra/newview/skins/default/xui/ru/floater_about.xml 08e65f3ead3d indra/newview/skins/default/xui/tr/floater_about.xml 08e65f3ead3d indra/newview/skins/default/xui/zh/floater_about.xml 08e65f3ead3d Diff: http://codereview.secondlife.com/r/505/diff Testing ------- Thanks, Vadim -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20111025/db3eb352/attachment.htm From vsavchuk at productengine.com Tue Oct 25 10:28:09 2011 From: vsavchuk at productengine.com (Vadim ProductEngine) Date: Tue, 25 Oct 2011 17:28:09 -0000 Subject: [opensource-dev] Review Request: STORM-1667 Square brackets around of Release Notes link in the About window Message-ID: <20111025172809.3104.18912@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/506/ ----------------------------------------------------------- Review request for Viewer. Summary ------- Adding back code that was accidentally removed in changeset ff333a95d1aa (the fix of STORM-1611). This addresses bug STORM-1667. http://jira.secondlife.com/browse/STORM-1667 Diffs ----- indra/newview/llfloaterabout.cpp 08e65f3ead3d Diff: http://codereview.secondlife.com/r/506/diff Testing ------- Thanks, Vadim -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20111025/059a4706/attachment.htm From vsavchuk at productengine.com Tue Oct 25 10:37:59 2011 From: vsavchuk at productengine.com (Vadim ProductEngine) Date: Tue, 25 Oct 2011 17:37:59 -0000 Subject: [opensource-dev] Review Request: STORM-1668 Localized strings.xml contains reference to non-existing gesture "bow1" Message-ID: <20111025173759.28706.74125@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/507/ ----------------------------------------------------------- Review request for Viewer. Summary ------- Fixed references to nonexistent gesture /bow1 in translations. This addresses bug STORM-1668. http://jira.secondlife.com/browse/STORM-1668 Diffs ----- indra/newview/skins/default/xui/es/strings.xml 08e65f3ead3d indra/newview/skins/default/xui/ja/strings.xml 08e65f3ead3d indra/newview/skins/default/xui/ru/strings.xml 08e65f3ead3d indra/newview/skins/default/xui/tr/strings.xml 08e65f3ead3d Diff: http://codereview.secondlife.com/r/507/diff Testing ------- Thanks, Vadim -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20111025/d3943a4d/attachment-0001.htm From Ima.Mechanique at blueyonder.co.uk Tue Oct 25 18:03:28 2011 From: Ima.Mechanique at blueyonder.co.uk (Ima Mechanique) Date: Wed, 26 Oct 2011 01:03:28 -0000 Subject: [opensource-dev] Review Request: STORM-959 Syntax highlighting for LSL multi-line comments. In-Reply-To: <20111016194546.17038.49821@domU-12-31-38-00-90-68.compute-1.internal> References: <20111016194546.17038.49821@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20111026010328.28711.73465@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/498/ ----------------------------------------------------------- (Updated Oct. 25, 2011, 6:03 p.m.) Review request for Viewer. Changes ------- * Fixed the */ delimiter being ignored. FINALLY! * Changed enum to a typedef and added a doc-block. * Changed names of enum constants to be a little less confusing. * Renamed getLength()/getLength2() to be more informative [getLengthHead()/getLengthTail()]. Summary ------- Adding syntax highlighting for LSL multi-line comments. This has been sitting on my hard drive for months. I've redone the diff against current tip. This addresses bug STORM-959. http://jira.secondlife.com/browse/STORM-959 Diffs (updated) ----- .hgignore 08e65f3ead3d doc/contributions.txt 08e65f3ead3d indra/llui/llkeywords.h 08e65f3ead3d indra/llui/llkeywords.cpp 08e65f3ead3d indra/newview/app_settings/keywords.ini 08e65f3ead3d Diff: http://codereview.secondlife.com/r/498/diff Testing ------- Thanks, Ima -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20111026/bfdd86ed/attachment.htm From oz at lindenlab.com Wed Oct 26 06:25:46 2011 From: oz at lindenlab.com (Oz Linden (Scott Lawrence)) Date: Wed, 26 Oct 2011 09:25:46 -0400 Subject: [opensource-dev] Bay area contributors... Message-ID: <4EA80A5A.3000709@lindenlab.com> I'm going to be in San Francisco Monday through Friday next week... if there are local open source contributors that are interested in getting together some evening, I'd love to do that. From jhwelch at gmail.com Wed Oct 26 08:27:08 2011 From: jhwelch at gmail.com (Jonathan Yap) Date: Wed, 26 Oct 2011 15:27:08 -0000 Subject: [opensource-dev] Review Request: STORM-1653 Group notices sent by muted residents are still displayed Message-ID: <20111026152708.28710.45136@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/508/ ----------------------------------------------------------- Review request for Viewer. Summary ------- When I mute a resident, group notices from that resident are still being displayed to me. This addresses bug STORM-1653. http://jira.secondlife.com/browse/STORM-1653 Diffs ----- doc/contributions.txt c42575f2cde8 indra/newview/llviewermessage.cpp c42575f2cde8 Diff: http://codereview.secondlife.com/r/508/diff Testing ------- See test plan in jira. Even with an empty name cache I still get an AgentID back. It is not clear to me if I might not when there is a cache miss and the backend systems servicing the name to ID request are heavily loaded. Thanks, Jonathan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20111026/3ff1d372/attachment.htm From oz at lindenlab.com Wed Oct 26 10:20:13 2011 From: oz at lindenlab.com (Oz Linden (Scott Lawrence)) Date: Wed, 26 Oct 2011 13:20:13 -0400 Subject: [opensource-dev] Question about speed of name cache query In-Reply-To: References: Message-ID: <4EA8414D.4090106@lindenlab.com> On 2011-10-25 9:23, Jonathan Welch wrote: > For my solution to Storm-1653 (Group notices sent by muted residents > are still displayed) I have to call gCacheName->buildLegacyName to get > the AgentID associated with a legacy name. > > It looks like this code may operate asynchronously if there is a cache > miss. In my testing I was always able to get an AgentID back, even > with a cache miss, but my tests were not being done in a lagged out > region. > > Would someone with knowledge of the name cache tell me if it is > possible for this routine to not return an AgentID; I'd like to > comment my code change properly. > I'm pretty sure that buildLegacyName will always return a useful name; the asynchronous path is only for fetching a Display Name. From oz at lindenlab.com Wed Oct 26 10:22:52 2011 From: oz at lindenlab.com (Oz Linden) Date: Wed, 26 Oct 2011 17:22:52 -0000 Subject: [opensource-dev] Review Request: STORM-1653 Group notices sent by muted residents are still displayed In-Reply-To: <20111026152708.28710.45136@domU-12-31-38-00-90-68.compute-1.internal> References: <20111026152708.28710.45136@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20111026172252.28709.70575@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/508/#review1061 ----------------------------------------------------------- Ship it! indra/newview/llviewermessage.cpp I don't think you can get a cache miss on a legacy name fetch, but in any case something should be logged here (I'd say at warning level). - Oz On Oct. 26, 2011, 8:27 a.m., Jonathan Yap wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/508/ > ----------------------------------------------------------- > > (Updated Oct. 26, 2011, 8:27 a.m.) > > > Review request for Viewer. > > > Summary > ------- > > When I mute a resident, group notices from that resident are still being displayed to me. > > > This addresses bug STORM-1653. > http://jira.secondlife.com/browse/STORM-1653 > > > Diffs > ----- > > doc/contributions.txt c42575f2cde8 > indra/newview/llviewermessage.cpp c42575f2cde8 > > Diff: http://codereview.secondlife.com/r/508/diff > > > Testing > ------- > > See test plan in jira. > > Even with an empty name cache I still get an AgentID back. It is not clear to me if I might not when there is a cache miss and the backend systems servicing the name to ID request are heavily loaded. > > > Thanks, > > Jonathan > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20111026/70c061ee/attachment.htm From jhwelch at gmail.com Wed Oct 26 11:09:58 2011 From: jhwelch at gmail.com (Jonathan Yap) Date: Wed, 26 Oct 2011 18:09:58 -0000 Subject: [opensource-dev] Review Request: STORM-1653 Group notices sent by muted residents are still displayed In-Reply-To: <20111026152708.28710.45136@domU-12-31-38-00-90-68.compute-1.internal> References: <20111026152708.28710.45136@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20111026180958.28710.13743@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/508/ ----------------------------------------------------------- (Updated Oct. 26, 2011, 11:09 a.m.) Review request for Viewer. Changes ------- Added a line to display a warning if the name to id routine returns a null. Summary ------- When I mute a resident, group notices from that resident are still being displayed to me. This addresses bug STORM-1653. http://jira.secondlife.com/browse/STORM-1653 Diffs (updated) ----- doc/contributions.txt c42575f2cde8 indra/newview/llviewermessage.cpp c42575f2cde8 Diff: http://codereview.secondlife.com/r/508/diff Testing ------- See test plan in jira. Even with an empty name cache I still get an AgentID back. It is not clear to me if I might not when there is a cache miss and the backend systems servicing the name to ID request are heavily loaded. Thanks, Jonathan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20111026/d4dd62ad/attachment-0001.htm From jhwelch at gmail.com Wed Oct 26 11:10:23 2011 From: jhwelch at gmail.com (Jonathan Yap) Date: Wed, 26 Oct 2011 18:10:23 -0000 Subject: [opensource-dev] Review Request: STORM-1653 Group notices sent by muted residents are still displayed In-Reply-To: <20111026172252.28709.70575@domU-12-31-38-00-90-68.compute-1.internal> References: <20111026172252.28709.70575@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20111026181023.1830.55775@domU-12-31-38-00-90-68.compute-1.internal> > On Oct. 26, 2011, 10:22 a.m., Oz Linden wrote: > > indra/newview/llviewermessage.cpp, line 2462 > > > > > > I don't think you can get a cache miss on a legacy name fetch, but in any case something should be logged here (I'd say at warning level). > > Done. - Jonathan ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/508/#review1061 ----------------------------------------------------------- On Oct. 26, 2011, 11:09 a.m., Jonathan Yap wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/508/ > ----------------------------------------------------------- > > (Updated Oct. 26, 2011, 11:09 a.m.) > > > Review request for Viewer. > > > Summary > ------- > > When I mute a resident, group notices from that resident are still being displayed to me. > > > This addresses bug STORM-1653. > http://jira.secondlife.com/browse/STORM-1653 > > > Diffs > ----- > > doc/contributions.txt c42575f2cde8 > indra/newview/llviewermessage.cpp c42575f2cde8 > > Diff: http://codereview.secondlife.com/r/508/diff > > > Testing > ------- > > See test plan in jira. > > Even with an empty name cache I still get an AgentID back. It is not clear to me if I might not when there is a cache miss and the backend systems servicing the name to ID request are heavily loaded. > > > Thanks, > > Jonathan > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20111026/b074057b/attachment.htm From opensourceobscure at gmail.com Thu Oct 27 02:43:36 2011 From: opensourceobscure at gmail.com (opensourceobscure) Date: Thu, 27 Oct 2011 11:43:36 +0200 Subject: [opensource-dev] spam on JIRA Message-ID: "Classic" link spam is being published on JIRA via this account (and possibly others): https://jira.secondlife.com/secure/ViewProfile.jspa?name=carry10086 Opensource Obscure -- https://twitter.com/oobscure https://my.secondlife.com/opensource.obscure Join this group to discuss Second Life Viewer: https://j.mp/slv2group From jhwelch at gmail.com Thu Oct 27 14:17:51 2011 From: jhwelch at gmail.com (Jonathan Welch) Date: Thu, 27 Oct 2011 17:17:51 -0400 Subject: [opensource-dev] Public Land example Message-ID: For a viewer change I am working on I need to find a parcel that is public land. This will show up in the About Land Owner field as (public) Can anyone point me to such a spot? I have tried visiting Infohubs, Help Island, Blake Sea, abandoned mainland, etc. but so far no luck. Thanks, -Jonathan From jhwelch at gmail.com Thu Oct 27 14:55:44 2011 From: jhwelch at gmail.com (Jonathan Welch) Date: Thu, 27 Oct 2011 17:55:44 -0400 Subject: [opensource-dev] Public Land example In-Reply-To: References: Message-ID: The value in the owner field will not be a normal looking name -- it will be (public) On Thu, Oct 27, 2011 at 5:17 PM, Jonathan Welch wrote: > For a viewer change I am working on I need to find a parcel that is > public land. This will show up in the About Land Owner field as > (public) > > Can anyone point me to such a spot? I have tried visiting Infohubs, > Help Island, Blake Sea, abandoned mainland, etc. but so far no luck. > > Thanks, > > -Jonathan > From holydoughnuts at gmail.com Thu Oct 27 15:42:19 2011 From: holydoughnuts at gmail.com (holydoughnuts) Date: Thu, 27 Oct 2011 18:42:19 -0400 Subject: [opensource-dev] Public Land example In-Reply-To: References: Message-ID: <4EA9DE4B.30102@gmail.com> Does that stuff even exist any more? All the abandoned land has reverted to Gov. Linden since 1.9 On 10/27/2011 05:17 PM, Jonathan Welch wrote: > For a viewer change I am working on I need to find a parcel that is > public land. This will show up in the About Land Owner field as > (public) > > Can anyone point me to such a spot? I have tried visiting Infohubs, > Help Island, Blake Sea, abandoned mainland, etc. but so far no luck. > > Thanks, > > -Jonathan From andrew at lindenlab.com Thu Oct 27 15:49:36 2011 From: andrew at lindenlab.com (Andrew Meadows) Date: Thu, 27 Oct 2011 15:49:36 -0700 Subject: [opensource-dev] Public Land example In-Reply-To: <4EA9DE4B.30102@gmail.com> References: <4EA9DE4B.30102@gmail.com> Message-ID: <4EA9E000.3080709@lindenlab.com> Public land is no longer used in SL proper, but still sometimes shows up in internal LL test simulators (due to loading a legacy simstate). I had some simulator code that completely removed all public land during simstate load, but it was in a project that was scrapped and I haven't yet gone back and salvaged that work. Hopefully I'll get around to it someday... Meanwhile, support of Public Land in the viewer could be removed. When LL simulator developers get impacted by the change it will provoke us to fix things simulator side, and it shouldn't be very hard to do. - Andrew On 10/27/2011 03:42 PM, holydoughnuts wrote: > Does that stuff even exist any more? All the abandoned land has reverted > to Gov. Linden since 1.9 > > On 10/27/2011 05:17 PM, Jonathan Welch wrote: >> For a viewer change I am working on I need to find a parcel that is >> public land. This will show up in the About Land Owner field as >> (public) >> >> Can anyone point me to such a spot? I have tried visiting Infohubs, >> Help Island, Blake Sea, abandoned mainland, etc. but so far no luck. >> >> Thanks, >> >> -Jonathan From jhwelch at gmail.com Thu Oct 27 17:28:47 2011 From: jhwelch at gmail.com (Jonathan Welch) Date: Thu, 27 Oct 2011 20:28:47 -0400 Subject: [opensource-dev] Public Land example In-Reply-To: <4EA9E000.3080709@lindenlab.com> References: <4EA9DE4B.30102@gmail.com> <4EA9E000.3080709@lindenlab.com> Message-ID: Andrew, Thank you for a very informative reply. It makes testing my change for Storm-1105 very easy. On Thu, Oct 27, 2011 at 6:49 PM, Andrew Meadows wrote: > Public land is no longer used in SL proper, but still sometimes shows up > in internal LL test simulators (due to loading a legacy simstate). I had > some simulator code that completely removed all public land during simstate > load, but it was in a project that was scrapped and I haven't yet gone back > and salvaged that work. Hopefully I'll get around to it someday... > > Meanwhile, support of Public Land in the viewer could be removed. > When LL simulator developers get impacted by the change it will provoke us > to fix things simulator side, and it shouldn't be very hard to do. > > - Andrew > > On 10/27/2011 03:42 PM, holydoughnuts wrote: >> Does that stuff even exist any more? All the abandoned land has reverted >> to Gov. Linden since 1.9 >> >> On 10/27/2011 05:17 PM, Jonathan Welch wrote: >>> For a viewer change I am working on I need to find a parcel that is >>> public land. This will show up in the About Land Owner field as >>> (public) >>> >>> Can anyone point me to such a spot? I have tried visiting Infohubs, >>> Help Island, Blake Sea, abandoned mainland, etc. but so far no luck. >>> >>> 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 > From dave at meadowlakearts.com Thu Oct 27 20:56:46 2011 From: dave at meadowlakearts.com (Dave Booth) Date: Thu, 27 Oct 2011 22:56:46 -0500 Subject: [opensource-dev] Missing details in Snowstorm development builds In-Reply-To: <4E9EF32E.1080902@lindenlab.com> References: <1318863335.33502.YahooMailNeo@web23907.mail.ird.yahoo.com> <4E9EF32E.1080902@lindenlab.com> Message-ID: <4EAA27FE.2020205@meadowlakearts.com> On 10/19/2011 10:56 AM, Oz Linden (Scott Lawrence) wrote: > I've asked our tools team to look at this... Have they made any progress? From jhwelch at gmail.com Fri Oct 28 04:34:47 2011 From: jhwelch at gmail.com (Jonathan Yap) Date: Fri, 28 Oct 2011 11:34:47 -0000 Subject: [opensource-dev] Review Request: STORM-1105 "Traffic: 0" shown for two cases (traffic actually 0, and waiting for data) Message-ID: <20111028113447.1830.64585@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/509/ ----------------------------------------------------------- Review request for Viewer. Summary ------- In the past, the daily computation for "traffic" has failed to compute - see SVC-6142 - which results in showing "Traffic: 0" for parcels that have actually had visitors. However, even if that has been addressed (and we believe it has), the viewer logic shows "Traffic: 0" for two cases: * Waiting for data from the server * Traffic actually is 0 Ideally, the viewer would distinguish these, e.g. showing "(waiting for data)" or some such, so that it is clear that the 0 is not an actual result in those cases. This should be relatively easy to plumb into indra/newview/llviewerparcelmgr.cpp and indra/newview/llfloaterland.cpp This addresses bug STORM-1105. http://jira.secondlife.com/browse/STORM-1105 Diffs ----- doc/contributions.txt 8b455c1b7a5e indra/newview/llfloaterland.cpp 8b455c1b7a5e indra/newview/llviewerparcelmgr.h 8b455c1b7a5e indra/newview/llviewerparcelmgr.cpp 8b455c1b7a5e indra/newview/skins/default/xui/en/floater_about_land.xml 8b455c1b7a5e Diff: http://codereview.secondlife.com/r/509/diff Testing ------- Opened About Land repeatedly, saw Loading... briefly before a numerical value for Traffic appeared. Thanks, Jonathan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20111028/fe20296b/attachment.htm From oz at lindenlab.com Fri Oct 28 10:25:41 2011 From: oz at lindenlab.com (Oz Linden (Scott Lawrence)) Date: Fri, 28 Oct 2011 13:25:41 -0400 Subject: [opensource-dev] Monday Open Development User Group cancelled.... Message-ID: <4EAAE595.20803@lindenlab.com> I'll be trying to adjust my clock to California time, so the meeting on Monday 10-31 is cancelled. I will do the Tuesday meeting as usual. From oz at lindenlab.com Fri Oct 28 13:37:00 2011 From: oz at lindenlab.com (Oz Linden) Date: Fri, 28 Oct 2011 20:37:00 -0000 Subject: [opensource-dev] Review Request: STORM-959 Syntax highlighting for LSL multi-line comments. In-Reply-To: <20111026010328.28711.73465@domU-12-31-38-00-90-68.compute-1.internal> References: <20111026010328.28711.73465@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20111028203700.28700.80351@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/498/#review1063 ----------------------------------------------------------- Ship it! - Oz On Oct. 25, 2011, 6:03 p.m., Ima Mechanique wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/498/ > ----------------------------------------------------------- > > (Updated Oct. 25, 2011, 6:03 p.m.) > > > Review request for Viewer. > > > Summary > ------- > > Adding syntax highlighting for LSL multi-line comments. > This has been sitting on my hard drive for months. I've redone the diff against current tip. > > > This addresses bug STORM-959. > http://jira.secondlife.com/browse/STORM-959 > > > Diffs > ----- > > .hgignore 08e65f3ead3d > doc/contributions.txt 08e65f3ead3d > indra/llui/llkeywords.h 08e65f3ead3d > indra/llui/llkeywords.cpp 08e65f3ead3d > indra/newview/app_settings/keywords.ini 08e65f3ead3d > > Diff: http://codereview.secondlife.com/r/498/diff > > > Testing > ------- > > > Thanks, > > Ima > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20111028/e6989bc4/attachment.htm From Lance.Corrimal at eregion.de Sat Oct 29 03:43:06 2011 From: Lance.Corrimal at eregion.de (Lance Corrimal) Date: Sat, 29 Oct 2011 10:43:06 -0000 Subject: [opensource-dev] Review Request: VWR-27382: Drag&Drop in Recent disabled Message-ID: <20111029104306.3104.83184@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/510/ ----------------------------------------------------------- Review request for Viewer. Summary ------- the "recent" tab does not accept drag&drop anymore, this fixes it. This addresses bug VWR-27382. http://jira.secondlife.com/browse/VWR-27382 Diffs ----- indra/newview/skins/default/xui/en/panel_main_inventory.xml ed476e07185c Diff: http://codereview.secondlife.com/r/510/diff Testing ------- could not test influence on the new selling-from-inv infrastructure, other than that it works ok. Thanks, Lance -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20111029/54354379/attachment.htm From jaeger_Reg at hotmail.com Sat Oct 29 21:43:29 2011 From: jaeger_Reg at hotmail.com (Tankmaster Finesmith) Date: Sun, 30 Oct 2011 04:43:29 -0000 Subject: [opensource-dev] Review Request: STORM-959 Syntax highlighting for LSL multi-line comments. In-Reply-To: <20111026010328.28711.73465@domU-12-31-38-00-90-68.compute-1.internal> References: <20111026010328.28711.73465@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20111030044329.15278.16534@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/498/#review1064 ----------------------------------------------------------- .hgignore why is this here? shouldn't this be a separate commit to exclude showing .diff files in hg working directory? - Tankmaster On Oct. 25, 2011, 6:03 p.m., Ima Mechanique wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/498/ > ----------------------------------------------------------- > > (Updated Oct. 25, 2011, 6:03 p.m.) > > > Review request for Viewer. > > > Summary > ------- > > Adding syntax highlighting for LSL multi-line comments. > This has been sitting on my hard drive for months. I've redone the diff against current tip. > > > This addresses bug STORM-959. > http://jira.secondlife.com/browse/STORM-959 > > > Diffs > ----- > > .hgignore 08e65f3ead3d > doc/contributions.txt 08e65f3ead3d > indra/llui/llkeywords.h 08e65f3ead3d > indra/llui/llkeywords.cpp 08e65f3ead3d > indra/newview/app_settings/keywords.ini 08e65f3ead3d > > Diff: http://codereview.secondlife.com/r/498/diff > > > Testing > ------- > > > Thanks, > > Ima > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20111030/35bb2c3b/attachment.htm From Ima.Mechanique at blueyonder.co.uk Sun Oct 30 02:10:07 2011 From: Ima.Mechanique at blueyonder.co.uk (Ima Mechanique) Date: Sun, 30 Oct 2011 09:10:07 -0000 Subject: [opensource-dev] Review Request: STORM-959 Syntax highlighting for LSL multi-line comments. In-Reply-To: <20111030044329.15278.16534@domU-12-31-38-00-90-68.compute-1.internal> References: <20111030044329.15278.16534@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20111030091007.15690.17046@domU-12-31-38-00-90-68.compute-1.internal> > On Oct. 29, 2011, 9:43 p.m., Tankmaster Finesmith wrote: > > .hgignore, line 69 > > > > > > why is this here? shouldn't this be a separate commit to exclude showing .diff files in hg working directory? Yes it should. I checked my repo and it went in as a separate commit, so I've no idea how it got into the diff :-( - Ima ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/498/#review1064 ----------------------------------------------------------- On Oct. 25, 2011, 6:03 p.m., Ima Mechanique wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/498/ > ----------------------------------------------------------- > > (Updated Oct. 25, 2011, 6:03 p.m.) > > > Review request for Viewer. > > > Summary > ------- > > Adding syntax highlighting for LSL multi-line comments. > This has been sitting on my hard drive for months. I've redone the diff against current tip. > > > This addresses bug STORM-959. > http://jira.secondlife.com/browse/STORM-959 > > > Diffs > ----- > > .hgignore 08e65f3ead3d > doc/contributions.txt 08e65f3ead3d > indra/llui/llkeywords.h 08e65f3ead3d > indra/llui/llkeywords.cpp 08e65f3ead3d > indra/newview/app_settings/keywords.ini 08e65f3ead3d > > Diff: http://codereview.secondlife.com/r/498/diff > > > Testing > ------- > > > Thanks, > > Ima > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20111030/2ec0b080/attachment.htm From pguslisty at productengine.com Mon Oct 31 02:10:06 2011 From: pguslisty at productengine.com (Paul ProductEngine) Date: Mon, 31 Oct 2011 09:10:06 -0000 Subject: [opensource-dev] Review Request: STORM-1666 Redundant "Release Notes" text in the About window for non-English locales In-Reply-To: <20111025170622.28703.35318@domU-12-31-38-00-90-68.compute-1.internal> References: <20111025170622.28703.35318@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20111031091006.16584.46461@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/505/#review1067 ----------------------------------------------------------- Ship it! - Paul On Oct. 25, 2011, 10:06 a.m., Vadim ProductEngine wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/505/ > ----------------------------------------------------------- > > (Updated Oct. 25, 2011, 10:06 a.m.) > > > Review request for Viewer. > > > Summary > ------- > > Ported the XML changes made for STORM-1611 to other locales. > > > This addresses bug STORM-1666. > http://jira.secondlife.com/browse/STORM-1666 > > > Diffs > ----- > > indra/newview/skins/default/xui/da/floater_about.xml 08e65f3ead3d > indra/newview/skins/default/xui/es/floater_about.xml 08e65f3ead3d > indra/newview/skins/default/xui/ja/floater_about.xml 08e65f3ead3d > indra/newview/skins/default/xui/pl/floater_about.xml 08e65f3ead3d > indra/newview/skins/default/xui/ru/floater_about.xml 08e65f3ead3d > indra/newview/skins/default/xui/tr/floater_about.xml 08e65f3ead3d > indra/newview/skins/default/xui/zh/floater_about.xml 08e65f3ead3d > > Diff: http://codereview.secondlife.com/r/505/diff > > > Testing > ------- > > > Thanks, > > Vadim > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20111031/5f08bbd7/attachment.htm From pguslisty at productengine.com Mon Oct 31 02:10:57 2011 From: pguslisty at productengine.com (Paul ProductEngine) Date: Mon, 31 Oct 2011 09:10:57 -0000 Subject: [opensource-dev] Review Request: STORM-1667 Square brackets around of Release Notes link in the About window In-Reply-To: <20111025172809.3104.18912@domU-12-31-38-00-90-68.compute-1.internal> References: <20111025172809.3104.18912@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20111031091057.15274.33200@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/506/#review1068 ----------------------------------------------------------- Ship it! - Paul On Oct. 25, 2011, 10:28 a.m., Vadim ProductEngine wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/506/ > ----------------------------------------------------------- > > (Updated Oct. 25, 2011, 10:28 a.m.) > > > Review request for Viewer. > > > Summary > ------- > > Adding back code that was accidentally removed in changeset ff333a95d1aa (the fix of STORM-1611). > > > This addresses bug STORM-1667. > http://jira.secondlife.com/browse/STORM-1667 > > > Diffs > ----- > > indra/newview/llfloaterabout.cpp 08e65f3ead3d > > Diff: http://codereview.secondlife.com/r/506/diff > > > Testing > ------- > > > Thanks, > > Vadim > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20111031/6a707f10/attachment.htm From pguslisty at productengine.com Mon Oct 31 02:12:29 2011 From: pguslisty at productengine.com (Paul ProductEngine) Date: Mon, 31 Oct 2011 09:12:29 -0000 Subject: [opensource-dev] Review Request: STORM-1668 Localized strings.xml contains reference to non-existing gesture "bow1" In-Reply-To: <20111025173759.28706.74125@domU-12-31-38-00-90-68.compute-1.internal> References: <20111025173759.28706.74125@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20111031091229.16585.16166@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/507/#review1069 ----------------------------------------------------------- Ship it! - Paul On Oct. 25, 2011, 10:37 a.m., Vadim ProductEngine wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/507/ > ----------------------------------------------------------- > > (Updated Oct. 25, 2011, 10:37 a.m.) > > > Review request for Viewer. > > > Summary > ------- > > Fixed references to nonexistent gesture /bow1 in translations. > > > This addresses bug STORM-1668. > http://jira.secondlife.com/browse/STORM-1668 > > > Diffs > ----- > > indra/newview/skins/default/xui/es/strings.xml 08e65f3ead3d > indra/newview/skins/default/xui/ja/strings.xml 08e65f3ead3d > indra/newview/skins/default/xui/ru/strings.xml 08e65f3ead3d > indra/newview/skins/default/xui/tr/strings.xml 08e65f3ead3d > > Diff: http://codereview.secondlife.com/r/507/diff > > > Testing > ------- > > > Thanks, > > Vadim > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20111031/0d183350/attachment.htm From vsavchuk at productengine.com Mon Oct 31 02:32:24 2011 From: vsavchuk at productengine.com (Vadim ProductEngine) Date: Mon, 31 Oct 2011 09:32:24 -0000 Subject: [opensource-dev] Review Request: STORM-1105 "Traffic: 0" shown for two cases (traffic actually 0, and waiting for data) In-Reply-To: <20111028113447.1830.64585@domU-12-31-38-00-90-68.compute-1.internal> References: <20111028113447.1830.64585@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20111031093224.15272.75959@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/509/#review1070 ----------------------------------------------------------- Ship it! - Vadim On Oct. 28, 2011, 4:34 a.m., Jonathan Yap wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/509/ > ----------------------------------------------------------- > > (Updated Oct. 28, 2011, 4:34 a.m.) > > > Review request for Viewer. > > > Summary > ------- > > > In the past, the daily computation for "traffic" has failed to compute - see SVC-6142 - which results in showing "Traffic: 0" for parcels that have actually had visitors. > > However, even if that has been addressed (and we believe it has), the viewer logic shows "Traffic: 0" for two cases: > > * Waiting for data from the server > * Traffic actually is 0 > > Ideally, the viewer would distinguish these, e.g. showing "(waiting for data)" or some such, so that it is clear that the 0 is not an actual result in those cases. > > This should be relatively easy to plumb into indra/newview/llviewerparcelmgr.cpp and indra/newview/llfloaterland.cpp > > > This addresses bug STORM-1105. > http://jira.secondlife.com/browse/STORM-1105 > > > Diffs > ----- > > doc/contributions.txt 8b455c1b7a5e > indra/newview/llfloaterland.cpp 8b455c1b7a5e > indra/newview/llviewerparcelmgr.h 8b455c1b7a5e > indra/newview/llviewerparcelmgr.cpp 8b455c1b7a5e > indra/newview/skins/default/xui/en/floater_about_land.xml 8b455c1b7a5e > > Diff: http://codereview.secondlife.com/r/509/diff > > > Testing > ------- > > Opened About Land repeatedly, saw Loading... briefly before a numerical value for Traffic appeared. > > > Thanks, > > Jonathan > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20111031/036109dd/attachment.htm From iseki at solar-system.tuis.ac.jp Mon Oct 31 03:23:40 2011 From: iseki at solar-system.tuis.ac.jp (Fumi.Iseki) Date: Mon, 31 Oct 2011 19:23:40 +0900 Subject: [opensource-dev] Real Time Animation with Kinect In-Reply-To: References: Message-ID: <4EAE772C.3020406@solar-system.tuis.ac.jp> Hello everyone. We are developing the system of real time animation on SL with Kinect. Please see http://www.nsl.tuis.ac.jp/xoops/modules/x_movie/x_movie_view.php?cid=2&lid=33 Is this interesting? From leonelm at utad.pt Mon Oct 31 03:30:44 2011 From: leonelm at utad.pt (Leonel Morgado) Date: Mon, 31 Oct 2011 10:30:44 -0000 Subject: [opensource-dev] Real Time Animation with Kinect In-Reply-To: <4EAE772C.3020406@solar-system.tuis.ac.jp> References: <4EAE772C.3020406@solar-system.tuis.ac.jp> Message-ID: <007901cc97b8$270de360$7529aa20$@pt> Of course it is! Do you plan to make this available as an open source library on top of libOpenMetaverse? Int?, Leonel UTAD, Vila Real Portugal -----Original Message----- From: opensource-dev-bounces at lists.secondlife.com [mailto:opensource-dev-bounces at lists.secondlife.com] On Behalf Of Fumi.Iseki Sent: segunda-feira, 31 de Outubro de 2011 10:24 To: opensource-dev at lists.secondlife.com Subject: [opensource-dev] Real Time Animation with Kinect Hello everyone. We are developing the system of real time animation on SL with Kinect. Please see http://www.nsl.tuis.ac.jp/xoops/modules/x_movie/x_movie_view.php?cid=2&lid=3 3 Is this interesting? _______________________________________________ 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 From gaberman at gmail.com Mon Oct 31 04:24:38 2011 From: gaberman at gmail.com (Gabriel Berman) Date: Mon, 31 Oct 2011 09:24:38 -0200 Subject: [opensource-dev] Real Time Animation with Kinect In-Reply-To: <007901cc97b8$270de360$7529aa20$@pt> References: <4EAE772C.3020406@solar-system.tuis.ac.jp> <007901cc97b8$270de360$7529aa20$@pt> Message-ID: Awnsome presentation ! How did you make the gestures be applied on the secondlife ? and what type of software and hardware do we need to begin create things like that ? Amazing ! congratulations ;) Eng. Gabriel Berman. LGB Consultores Associados Ltda Brasil - Porto Alegre -RS -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20111031/557ba18d/attachment.htm From marinekelley at gmail.com Mon Oct 31 08:54:22 2011 From: marinekelley at gmail.com (Marine Kelley) Date: Mon, 31 Oct 2011 16:54:22 +0100 Subject: [opensource-dev] Need help about EXT-1285 Message-ID: Hi all ! I need help ! I'm working on adapting my RLV to version 3.2.0 of the viewer, and hitting a wall here. Let me explain the problem : In V1.x, script dialog boxes (the blue menus) were located on the upper right corner of the screen, with a fixed size text area in which the script could write what it wanted (up to 512 chars), with a scrollbar when needed. Then there were the buttons below that area. This had a nice side effect though, the buttons were always at the same place on the screen, so for repetitive tasks with dialogs you knew well, you didn't have to actually read before clicking. The scrollbar wasn't very practical, so LL decided to move the dialogs down to the lower right corner of the screen in v2.x, in exchange of making the dialogs variable in size. Best of both worlds, the dialogs were showing all the info at first glance without the need for a scrollbar, and the buttons were always at the same spot (although the sidebar was complicating things a little, but it was still workable). Now in v3 the dialogs are back to the upper right corner of the screen as part of EXT-1285 (coded and released by Seth Productengine). Ok, but no scrollbar means the buttons are NOT always at the same place anymore and that... is unacceptable to me. I absolutely need to change this, this is not practicable as it is. So I have two options. Either leave the dialogs where they are now and move the buttons of the dialog window BEFORE the text, or move the dialogs back to the lower right corner of the screen. Option 1 is good for v1 users, but a little confusing since the dialogs would not look like they always did. However I have spent some time looking for a way to do this, and never found HOW to move these buttons up before the text. I know the dialog is roughly defined in notifications.xml under the name "ScriptDialog", but I don't see where the list of buttons is constructed. The point of this email is partly to ask how to do this. Option 2 is good for v2 users, however it has a nasty side-effect : notification boxes ("are you sure you want to quit" and such) are linked to the tool bar or something. I haven't found where to change that and this is also the point of this email. I prefer option 1 personally, but I fear moving the buttons would look like a lame hack. Can anybody give me pointers about how to implement either option please ? Or better, both options ! Thank you in advance, Marine From wolfpup67 at earthlink.net Mon Oct 31 09:12:44 2011 From: wolfpup67 at earthlink.net (WolfPup Lowenhar) Date: Mon, 31 Oct 2011 12:12:44 -0400 Subject: [opensource-dev] Need help about EXT-1285 In-Reply-To: References: Message-ID: <002401cc97e7$ecade280$c609a780$@net> The position of the buttons can be easily move by changing line 87 of panel_notification.xml. Orginal : follows="left|right|bottom" Top placement : follows="left|right|top" <- this should move the buttons to the top of the layout but also might have to move lines 85-99 to the top of the xml file as well plus modify the other sections accordingly. > -----Original Message----- > From: opensource-dev-bounces at lists.secondlife.com [mailto:opensource-dev- > bounces at lists.secondlife.com] On Behalf Of Marine Kelley > Sent: Monday, October 31, 2011 11:54 AM > To: opensource-dev at lists.secondlife.com > Subject: [opensource-dev] Need help about EXT-1285 > > Hi all ! I need help ! > > I'm working on adapting my RLV to version 3.2.0 of the viewer, and > hitting a wall here. Let me explain the problem : > > In V1.x, script dialog boxes (the blue menus) were located on the > upper right corner of the screen, with a fixed size text area in which > the script could write what it wanted (up to 512 chars), with a > scrollbar when needed. Then there were the buttons below that area. > This had a nice side effect though, the buttons were always at the > same place on the screen, so for repetitive tasks with dialogs you > knew well, you didn't have to actually read before clicking. > > The scrollbar wasn't very practical, so LL decided to move the dialogs > down to the lower right corner of the screen in v2.x, in exchange of > making the dialogs variable in size. Best of both worlds, the dialogs > were showing all the info at first glance without the need for a > scrollbar, and the buttons were always at the same spot (although the > sidebar was complicating things a little, but it was still workable). > > Now in v3 the dialogs are back to the upper right corner of the screen > as part of EXT-1285 (coded and released by Seth Productengine). Ok, > but no scrollbar means the buttons are NOT always at the same place > anymore and that... is unacceptable to me. I absolutely need to change > this, this is not practicable as it is. > > So I have two options. Either leave the dialogs where they are now and > move the buttons of the dialog window BEFORE the text, or move the > dialogs back to the lower right corner of the screen. > > Option 1 is good for v1 users, but a little confusing since the > dialogs would not look like they always did. However I have spent some > time looking for a way to do this, and never found HOW to move these > buttons up before the text. I know the dialog is roughly defined in > notifications.xml under the name "ScriptDialog", but I don't see where > the list of buttons is constructed. The point of this email is partly > to ask how to do this. > > Option 2 is good for v2 users, however it has a nasty side-effect : > notification boxes ("are you sure you want to quit" and such) are > linked to the tool bar or something. I haven't found where to change > that and this is also the point of this email. > > I prefer option 1 personally, but I fear moving the buttons would look > like a lame hack. Can anybody give me pointers about how to implement > either option please ? Or better, both options ! > > Thank you in advance, > Marine > _______________________________________________ > 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 > ----- > No virus found in this message. > Checked by AVG - www.avg.com > Version: 2012.0.1834 / Virus Database: 2092/4586 - Release Date: 10/31/11 From marinekelley at gmail.com Mon Oct 31 09:55:03 2011 From: marinekelley at gmail.com (Marine Kelley) Date: Mon, 31 Oct 2011 17:55:03 +0100 Subject: [opensource-dev] Need help about EXT-1285 In-Reply-To: <002401cc97e7$ecade280$c609a780$@net> References: <002401cc97e7$ecade280$c609a780$@net> Message-ID: Thanks WolfPup. With this change and a couple other tweaks, I could finally get an inverted dialog box, which achieves exactly what I wanted with my option 1. Kudos ! Marine On 31/10/2011, WolfPup Lowenhar wrote: > The position of the buttons can be easily move by changing line 87 of > panel_notification.xml. > Orginal : follows="left|right|bottom" > Top placement : follows="left|right|top" <- this should move the buttons to > the top of the layout but also might have to move lines 85-99 to the top of > the xml file as well plus modify the other sections accordingly. > >> -----Original Message----- >> From: opensource-dev-bounces at lists.secondlife.com [mailto:opensource-dev- >> bounces at lists.secondlife.com] On Behalf Of Marine Kelley >> Sent: Monday, October 31, 2011 11:54 AM >> To: opensource-dev at lists.secondlife.com >> Subject: [opensource-dev] Need help about EXT-1285 >> >> Hi all ! I need help ! >> >> I'm working on adapting my RLV to version 3.2.0 of the viewer, and >> hitting a wall here. Let me explain the problem : >> >> In V1.x, script dialog boxes (the blue menus) were located on the >> upper right corner of the screen, with a fixed size text area in which >> the script could write what it wanted (up to 512 chars), with a >> scrollbar when needed. Then there were the buttons below that area. >> This had a nice side effect though, the buttons were always at the >> same place on the screen, so for repetitive tasks with dialogs you >> knew well, you didn't have to actually read before clicking. >> >> The scrollbar wasn't very practical, so LL decided to move the dialogs >> down to the lower right corner of the screen in v2.x, in exchange of >> making the dialogs variable in size. Best of both worlds, the dialogs >> were showing all the info at first glance without the need for a >> scrollbar, and the buttons were always at the same spot (although the >> sidebar was complicating things a little, but it was still workable). >> >> Now in v3 the dialogs are back to the upper right corner of the screen >> as part of EXT-1285 (coded and released by Seth Productengine). Ok, >> but no scrollbar means the buttons are NOT always at the same place >> anymore and that... is unacceptable to me. I absolutely need to change >> this, this is not practicable as it is. >> >> So I have two options. Either leave the dialogs where they are now and >> move the buttons of the dialog window BEFORE the text, or move the >> dialogs back to the lower right corner of the screen. >> >> Option 1 is good for v1 users, but a little confusing since the >> dialogs would not look like they always did. However I have spent some >> time looking for a way to do this, and never found HOW to move these >> buttons up before the text. I know the dialog is roughly defined in >> notifications.xml under the name "ScriptDialog", but I don't see where >> the list of buttons is constructed. The point of this email is partly >> to ask how to do this. >> >> Option 2 is good for v2 users, however it has a nasty side-effect : >> notification boxes ("are you sure you want to quit" and such) are >> linked to the tool bar or something. I haven't found where to change >> that and this is also the point of this email. >> >> I prefer option 1 personally, but I fear moving the buttons would look >> like a lame hack. Can anybody give me pointers about how to implement >> either option please ? Or better, both options ! >> >> Thank you in advance, >> Marine >> _______________________________________________ >> 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 >> ----- >> No virus found in this message. >> Checked by AVG - www.avg.com >> Version: 2012.0.1834 / Virus Database: 2092/4586 - Release Date: 10/31/11 > > _______________________________________________ > 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 > From iseki at solar-system.tuis.ac.jp Mon Oct 31 17:14:45 2011 From: iseki at solar-system.tuis.ac.jp (Fumi.Iseki) Date: Tue, 01 Nov 2011 09:14:45 +0900 Subject: [opensource-dev] Real Time Animation with Kinect In-Reply-To: <4EAE772C.3020406@solar-system.tuis.ac.jp> References: <4EAE772C.3020406@solar-system.tuis.ac.jp> Message-ID: <4EAF39F5.1060701@solar-system.tuis.ac.jp> Thank you for your response. >> Do you plan to make this available as an open source library on top of >> libOpenMetaverse? We want to release this system as Open Source within Nov. 2011 I don't think relevance of libOpenMetaverse now. >> That looks great - are those movements being streamed in real time to the other connected clients? This is local Viewer only. For synchronize on network, modified of a server is required. >> How did you make the gestures be applied on the secondlife ? and what type of software and hardware do we need to begin create things like that ? A mechanism is very simple. Probably, anyone can create software. We are writing wiki about this system. But it is under construction now. Please wait. wiki: http://www.nsl.tuis.ac.jp/xoops/modules/xpwiki/?SLKinect Thanks. From jaymes_keller at lavabit.com Mon Oct 31 17:18:07 2011 From: jaymes_keller at lavabit.com (Jamie Quinlan) Date: Tue, 01 Nov 2011 00:18:07 +0000 Subject: [opensource-dev] Redundant 'typedef' causing compiliation to fail on GCC 4.4/4.5 Message-ID: <1320106694.30400.7.camel@CHANDRA> Hi all, It's rare I post on here, but I think I need to bring something to light. With the latest viewer-development branch, I noticed that a warning, treated like an error, causes compilation of the viewer to fail under GCC 4.4 and 4.5 versions. (Note, I haven't mentioned GCC 4.6, as it fails to compile anyway, but that's a moot point, as I have 4.4 and 4.5 built and installed from source. :) ) As far as my knowledge of C++ goes, typedef functions are only used in C to declare structs, in C++, it's not used that way. Fortunatly the fix is simple. All you have to do is to delete the 'typedef' from line 54 of indra/llui/llkeywords.h, and off you go. Just don't delete anything else from that line, that would be Very Bad(TM). Sorry if it does seem a little harsh, but if it breaks a Linden-used version of GCC, it might end up being a major PITA, and we don't want that. :)