Re: [opensource-dev] viewer-release vs The Penguins
On 2/6/2020 6:05, Nicky D. wrote: > The main reason why this happened is LL not wanting to have their own > Linux viewer depend on many 3Ps but rather use as much standalone > that you can find on a Linux system. That led to either snap, flatpak or > AppImage. I'm certainly interested in what you discover in containerizing the viewer. Distribution size, edge cases where things go wrong. Dropping it into a wsl2 instance on windows to see what happens... m ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Linux x64 - libmedia_plugin_cef.so error
On 3/20/2018 17:32, Alex wrote: > > Interesting that that symbol is defined 3 times in your library. > 'nm' that thing and see what is definition and what is reference. ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Mac viewer and Apple maintained opensource libraries
On 1/31/2017 3:24 PM, Cinder Roxley wrote: > ~ % otool -L /usr/lib/libssl.dylib > > /usr/lib/libssl.dylib: > > /usr/lib/libssl.0.9.8.dylib (compatibility version 0.9.8, current > version 0.9.8) > > /usr/lib/libcrypto.0.9.8.dylib (compatibility version 0.9.8, current > version 0.9.8) Ouch. I was ashamed of how long we stayed at 0.9.8. (Would kinda like to use LibreSSL...) -- Monty Brandenberg | Unit of Production Skype monty.linden | Second Life Monty Linden Linden Lab | Makers of Shared Creative Spaces Check out what we're working on! ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Linux
On 1/29/2017 8:39 PM, Nicky Perian wrote: > Will LL use a build system that can be updated as opposed to the current > out of date system? Hopefully, the build system will be a standard off > the shelf that everyone can install and without any mix and match specials. The "one, true Linux?" /me reaches for box of popcorn... ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Question about BUG-41029 and 64 bit usage
On 12/16/2016 4:16 AM, Henri Beauchamp wrote: > I'd say that the demonstration of how templates can actually > harm the maintainability of the code is done... Hahaha, that is a permanent on-going debate. m ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] 64 bit viewers build instructions
On 11/30/2016 4:11 PM, Nat Goodspeed wrote: > > I think we decided back when switching to VS 2013 that /GL and /LTCG > didn't add enough value for us to bother with them. I think the > expedient fix would be to remove /GL from jpeglib. I'll be the grumpy engineer and ask that 00-COMPILE-LINK-RUN.txt in the cmake directory get updated with current options and the thinking that led to them... m -- Monty Brandenberg | Unit of Production Skype monty.linden | Second Life Monty Linden Linden Lab | Makers of Shared Creative Spaces Check out what we're working on! ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Viewer Azumarill (coroutines) issue
On 12/1/2015 8:17 AM, Henri Beauchamp wrote: > but here is the comment > I wrote for it, which explains it all and could be used with benefit > by LL: And thanks for the analysis as well, Henri. Passed it along to folks and I can have another boost argument now. -- Monty Brandenberg | Unit of Production Skype monty.linden | Second Life Monty Linden Linden Lab | Makers of Shared Creative Spaces Check out what we're working on! ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Viewer Azumarill (coroutines) issue
On 12/1/2015 8:17 AM, Henri Beauchamp wrote: > ... It's becoming insane: > // obfuscating code complexity behind a gazillion of templates does not make > // the code cleaner (and certainly not faster), much to the contrary ! HB No disagreement on this point at all. :-) m ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Having Trouble Compiling on Windows - 2 Failed Builds
On 10/8/2014 10:10 PM, Sameer Anand wrote: Can someone maybe shed some light on something I am doing wrong? Thanks for the help! Try getting the white space out of your repo path. I.e. 'Viewer Source' - 'Viewer_Source' or something. A lot of build scripting isn't tolerant of that. ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Not actually OT: How do I get/update gcc to 4.6 on debian squeeze?
On 9/4/2014 11:00 AM, Lance Corrimal wrote: Hi, I guess noone else builds on linux AND tries to actually have a build environment that is exactly the same as the one Ll uses... Since it is NOT DOCUMENTED. Nobody would *want* the exact same build environment that we use. But Oz is, I believe, running down the info on the tool chain components. We're large enough that that info is stuck in a silo somewhere and we have to blast it out. m -- Monty Brandenberg | Unit of Production Skype monty.linden | Second Life Monty Linden Linden Lab | Makers of Shared Creative Spaces Check out what we're working on! ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] library refresh viewer
On 8/12/2014 7:26 PM, Nicky Perian wrote: 1. boost-- Is the openssl that is populated in 3p-boost-update the same version as the one used by the viewer? I'm thinking it comes from boost. No openssl distributed by Boost, just the asio library using it and SL shouldn't be using asio. Asio also doesn't build any binary artifacts, other than test cases, so no symbol dependencies. When used, it will pick up whatever version is found in the build environment. -- Monty Brandenberg | Unit of Production Skype monty.linden | Second Life Monty Linden Linden Lab | Makers of Shared Creative Spaces Check out what we're working on! ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Library Refresh viewer
Checking in to see if anyone is seeing problems with the new libraries. Crash reports have been mostly quiet and as expected. No lurking horrors yet? m ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Library Refresh viewer
On 7/15/2014 10:59 AM, Henri Beauchamp wrote: This raises the question whether or not using static libraries to compile the viewer, for the ones that might conflict with their dynamic counterparts that get loaded at runtime anyway (especially libpcre, libxml2 and libz)... Yes, it does raise the question. I talk about this in the new doc file indra/cmake/00-COMPILE-LINK-RUN.txt (lousy name but collates to the top in my locale). With Linux, I'm stuck with a flat symbol resolution process at startup. I am managing this a bit in ZLIB.cmake and PNG.cmake with --whole-archive options forcing the new libraries to be authoritative. That leaves open the question of backwards incompatibility for shared libraries built against an old version of an API getting symbols resolved with a new API . I don't have a magic solution for that. There is plenty of potential here for incompatibility even with C APIs. Both zlib and libpng have a history of structure non-opacity. But the approach is to test for compatibility and then try to deal with actual problems as they arise. None of the solutions here is particularly attractive but ensuring that run-time version is not less than compile-time version gives us a chance. m -- Monty Brandenberg | Unit of Production Skype monty.linden | Second Life Monty Linden Linden Lab | Makers of Shared Creative Spaces Check out what we're working on! ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Library Refresh viewer
On 7/15/2014 2:01 PM, Henri Beauchamp wrote: Agreed, but then we should make sure to compile the viewer against a version that is sufficiently old so that every currently used Linux distro got the same or a newer version installed... For example, in Linux Rosa 2012 case (a relatively recent distro, that will be kept mainted till 2017), libpcre.so.0 (PCRE v7.xx) is the system library. In this case, won't it be safer to use PCRE 7 instead of v8 for the static libarry linked to the viewer pre-built libraries (AFAIK, it's only libcolladadom) ?... When colladadom became a static library, the viewer actually lost a link-time dependency on pcre. It's still in the link, a dependency may come back should the colladadom compilation units that reference it be used in the future. But right now, this is a non-problem. If actual problems can be demonstrated on a supported platform, a library downgrade is one of the solutions available. Haven't needed to do that yet. -- Monty Brandenberg | Unit of Production Skype monty.linden | Second Life Monty Linden Linden Lab | Makers of Shared Creative Spaces Check out what we're working on! ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Library Refresh viewer
On 7/15/2014 6:01 PM, Henri Beauchamp wrote: But I just noticed this (apparently harmless) new warning, appearing in the stderr stream (i.e. only seen when the viewer is ran from a terminal): QObject::startTimer: QTimer can only be used with threads started with QThread It also appears with LL's Second_Life_Refresh viewer. Qt is generally unhappy running in SLplugin. :-) Soo many warnings flying out stderr whenever the viewer is run from command line. -- Monty Brandenberg | Unit of Production Skype monty.linden | Second Life Monty Linden Linden Lab | Makers of Shared Creative Spaces Check out what we're working on! ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] where do i get 3p-fmodex?
On 3/25/2014 6:58 AM, Ardy Lay wrote: Three files each got a little of this treatment, yes. And I don't expect this to be the right way to do it. It's just me steering around an obstacle that I suspect is caused by something in a make file. Problem is in FMODEX.cmake. A change I made didn't affect our builds, did affect OS builds. I'll revert that in the future when I get a chance but that would be the place to fix this (changeset 3d662c2f1aad). -- Monty Brandenberg | Unit of Production Skype monty.linden | Second Life Monty Linden Linden Lab | Makers of Shared Creative Spaces Check out what we're working on! ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
[opensource-dev] HTTP Project Viewer Source
Quick note to let everyone know that the next turn of the HTTP project code is now available in source and project viewer form. HTTP Project viewer can be found here: * http://wiki.secondlife.com/wiki/Release_Notes/Second_Life_Project_HTTP/3.6.13.284698 Viewer source repo is referenced here: * http://wiki.secondlife.com/wiki/Linden_Lab_Official:Viewer_Source_Repositories And there's a second repo for libcurl work here: * https://bitbucket.org/monty_linden/3p-curl This is still a project viewer and so additional changes may be expected before final release. Major changes from 3.4.3 include: * indra/llcorehttp - policy classes implemented, configuration API simplified, reduced idle time on wire between requests, documentation/how-to guide. * indra/newview/llmeshrepository - conversion to new HTTP using fewer connections, thread safety improvements, error handling improvements, request retry improvements. * 3p-curl - switched from c-ares to threaded DNS resolver and using version 7.24.0. m -- Monty Brandenberg | Unit of Production Skype monty.linden | Second Life Monty Linden Linden Lab | Makers of Shared Creative Spaces Check out what we're working on! ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Review Request: OPEN-172 Combined changesets for Linux gcc 4.7, 2 build of viewer development
--- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/618/#review1303 --- indra/newview/llviewertexture.cpp http://codereview.secondlife.com/r/618/#comment1198 Ugg, took me awhile to find this. The fix is to declare a virtual destructor on LLTextureManagerBridge in lltexturemanagerbridge.h. Looks like it can be pure virtual. - Monty Brandenberg On April 11, 2013, 8:26 p.m., Nicky Perian wrote: --- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/618/ --- (Updated April 11, 2013, 8:26 p.m.) Review request for Viewer. Description --- OPEN-172 Combined changesets for Linux gcc 4.7,2 build of viewer development This addresses bug OPEN-172. http://jira.secondlife.com/browse/OPEN-172 Diffs - indra/cmake/00-Common.cmake fc8c50bc74f5 indra/cmake/Copy3rdPartyLibs.cmake fc8c50bc74f5 indra/cmake/LLAddBuildTest.cmake fc8c50bc74f5 indra/linux_updater/linux_updater.cpp fc8c50bc74f5 indra/llappearance/llwearabletype.h fc8c50bc74f5 indra/llcommon/lldarray.h fc8c50bc74f5 indra/llcommon/lleventcoro.h fc8c50bc74f5 indra/llcommon/llinitparam.h fc8c50bc74f5 indra/llcommon/llrefcount.h fc8c50bc74f5 indra/llcorehttp/CMakeLists.txt fc8c50bc74f5 indra/llmath/lloctree.h fc8c50bc74f5 indra/llmessage/CMakeLists.txt fc8c50bc74f5 indra/llmessage/lliopipe.h fc8c50bc74f5 indra/llmessage/llregionpresenceverifier.cpp fc8c50bc74f5 indra/llui/llview.cpp fc8c50bc74f5 indra/media_plugins/gstreamer010/media_plugin_gstreamer010.cpp fc8c50bc74f5 indra/newview/llcommunicationchannel.cpp fc8c50bc74f5 indra/newview/llfloaterpathfindingobjects.cpp fc8c50bc74f5 indra/newview/llsurfacepatch.cpp fc8c50bc74f5 indra/newview/llviewertexture.cpp fc8c50bc74f5 indra/newview/llworld.cpp fc8c50bc74f5 indra/test/CMakeLists.txt fc8c50bc74f5 indra/test/test.cpp fc8c50bc74f5 Diff: http://codereview.secondlife.com/r/618/diff/ Testing --- Built on debia wheezy virtual box virtual machine. Logged on secondlife. Checked logs and found no spamming. Do not have a native machine to test with. The change to llviewertexture.cpp around line 419 needs a close look. Thanks, Nicky Perian ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] HTTP connection changes heading to Aditi in the near future
On 3/18/2013 12:06 PM, Monty Brandenberg wrote: On 3/15/2013 8:56 PM, Monty Brandenberg wrote: Three Mesh testing regions (MeshTest2, MeshTest2A, MeshTest2H) are now up as well on Aditi. As with textures, these regions share meshes so you may want to clear cache as appropriate when switching between channels. And now there are three sandbox regions on Aditi as well: Sandbox HTTP, Sandbox HTTP A, Sandbox HTTP H If there are any problems with these regions (and I can imagine I messed something up), let me know. It looks like Beta will be wrapped up shortly. If you've wanted to try these out but haven't yet, now would be a good time to jump in there. m ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] HTTP connection changes heading to Aditi in the near future
The three DRTSIM-203 channels on Aditi have been updated with a new build with a fix for SH-4026. This involves expired/revoked caps returning 502 on access rather than the traditional 404. 404 should be the norm once again. m ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] HTTP connection changes heading to Aditi in the near future
On 3/15/2013 8:56 PM, Monty Brandenberg wrote: Three Mesh testing regions (MeshTest2, MeshTest2A, MeshTest2H) are now up as well on Aditi. As with textures, these regions share meshes so you may want to clear cache as appropriate when switching between channels. And now there are three sandbox regions on Aditi as well: Sandbox HTTP, Sandbox HTTP A, Sandbox HTTP H If there are any problems with these regions (and I can imagine I messed something up), let me know. ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] HTTP connection changes heading to Aditi in the near future
On 3/15/2013 1:06 AM, Darien Caldwell wrote: Are these regions on the Main grid or Beta grid? I can find MeshTest2 on both grids, but the server version is 13.03.04.271238, so I'm not clear that this is the correct server version. Also TextureTest2 on beta seems to be closed off. All on Aditi (and now open). MeshTest2 regions aren't set up yet. Working on them now, there will be a followup post when they're ready. The Server announcement for this is here: http://wiki.secondlife.com/wiki/Server_Beta_User_Group#Upcoming_Stuff Earlier announcement with diagram here: http://wiki.secondlife.com/w/index.php?title=Server_Beta_User_Groupoldid=1177159 ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] HTTP connection changes heading to Aditi in the near future
On 3/14/2013 8:13 PM, Monty Brandenberg wrote: We now have three channels and a number of regions available for testing: * DRTSIM-203. Normal release intended to go to Agni supporting keepalive connections and other changes. Regions: o TextureTest2. High texture count, no meshes, low residency limit to prevent interference when doing benchmark testing. o (Coming soon) MeshTest2. High mesh count (many distinct mesh assets which all look the same), few textures. Low residency limit to prevent interference when doing benchmark testing. * DRTSIM-203H. Our 'Happy' channel with more generous limits and optimistic service controls. o TextureTest2H. Identical to TextureTest. o (Coming soon) MeshTest2H. Identical to MeshTest2 * DRTSIM-203A. Our 'Angry' channel with stricter and preemptive enforcement of limits (generates many 503 errors). o TextureTest2A. Identical to TextureTest. o (Coming soon) MeshTest2A. Identical to MeshTest2 Three Mesh testing regions (MeshTest2, MeshTest2A, MeshTest2H) are now up as well on Aditi. As with textures, these regions share meshes so you may want to clear cache as appropriate when switching between channels. ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] HTTP connection changes heading to Aditi in the near future
We now have three channels and a number of regions available for testing: * DRTSIM-203. Normal release intended to go to Agni supporting keepalive connections and other changes. Regions: o TextureTest2. High texture count, no meshes, low residency limit to prevent interference when doing benchmark testing. o (Coming soon) MeshTest2. High mesh count (many distinct mesh assets which all look the same), few textures. Low residency limit to prevent interference when doing benchmark testing. * DRTSIM-203H. Our 'Happy' channel with more generous limits and optimistic service controls. o TextureTest2H. Identical to TextureTest. o (Coming soon) MeshTest2H. Identical to MeshTest2 * DRTSIM-203A. Our 'Angry' channel with stricter and preemptive enforcement of limits (generates many 503 errors). o TextureTest2A. Identical to TextureTest. o (Coming soon) MeshTest2A. Identical to MeshTest2 Test regions share object and texture references so if you are trying to measure download rates or really exercise the network, you'll need to defeat caching. Typically with a restart and manual cache clear or your own preferred method. Aditi is also hosting some of the server-side baking work and you may not get a reliable avatar appearance unless you use a Sunshine project viewer. What we're looking for on these channels: DRTSIM-203. HTTP issues generally. HTTP texture download reliability and throughput. Script writers using *llRequestURL* and *llRequestSecureURL* should try to get an A/B comparison going between a normal 'Second Life Server' region on Aditi and DRTSIM-203. Particularly with competing traffic like large texture or mesh downloads. Scripts aren't getting a boost with this work but they shouldn't be adversely impacted. Mesh also isn't getting a boost this time but, again, negative impact should be avoided. Third-party viewer developers should test for overall compatibility with all HTTP services. We're interested in reports of regressions in any areas. We *are* expecting more 503 errors (0x01f70001) in log files as it will be possible to push requests faster than before and certain throttles will be hit. As long as these are recoverable, they're not a regression, they're an indicator of better utilization. DRTSIM-203H (Happy). Scripts and mesh do get a boost here and other limits are generally raised. This may increase the tendency to get 503 and 502 (0x01f60001) errors in some areas. Again, these aren't regressions as long as they're recoverable. Subjective and objective comments on Mesh and scripting behavior are sought here. DRTSIM-203A (Angry). This channel deliberately restricts resources and uses a punitive enforcement policy that should result in a storm of 503 errors. Viewers are expected to recover from these. Scripters can use this to test against a (reliably unreliable?) grid to see if they're handling recovery well. A higher error rate and lower throughput and availability are expected here. What is being tested is viewer and script robustness in the face of constraints. A more rigid enforcement policy, if tolerated by external software, might actually allow us to set higher limits if we can pull back when required. ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] HTTP connection changes heading to Aditi in the near future
On 3/14/2013 9:46 PM, Darien Caldwell wrote: As well I am not sure why scripts are being included in this at all. The HTTP issues as I understood were the number of http connections a viewer had to handle, with another factor in that mix being the particular router the resident uses and how well/badly it handled multiple HTTP connections. That only scratches the surface of the issues involved. Even for viewer-to-grid, there are a dozen or more independent variables. Service to service communcations such as a script to an external server or a script to another script shouldn't be a contributing factor in these viewer connection problems. The connections should never be hitting any viewer. It's a different communication path. llRequestURL and llRequestSecureURL are part of the service also called 'HTTP-In'. The HTTP server is in the script, the client is a non-viewer entity running out on the net. This path transits the gateways and so may be impacted indirectly (DRTSIM-203 channel) and directly (DRTSIM-203H channel) and is worth testing for those who've built services on them. ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Review Request: OPEN-159 / Faster, nicer Depth of Field
On 1/11/2013 5:03 PM, Tofu Buzzard wrote: llassert_always(false); Ah, yes. I added this assert to mark this function as broken because it ate some of my time just unobviously doing nothing. http://catb.org/jargon/html/magic-story.html ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Linux boost shared libraries
filed: https://jira.secondlife.com/browse/BUG-1056 ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Linux boost shared libraries
On 12/11/2012 5:36 PM, Henri Beauchamp wrote: The JIRA became useless to developers and users alike... Not useless, _streamlined_! *cough* ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Linux boost shared libraries
On 12/9/2012 9:32 PM, Nicky Perian wrote: What is the reason for the switch to boost shared libraries? The other platforms seem to perform without issue using boost static libraries. In 3.4.3? That change was picked up as part of some shared work in Boost packaging. Not certain what the technical motivation was. Are you seeing a problem as a result? (I expect it will likely revert on a future refresh of Boost, probably 1.52 but no promises there.) m ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Linux boost shared libraries
On 12/10/2012 7:25 PM, Nicky Perian wrote: At the sldev meeting earlier it was stated that unicode processing with boost regex was problematic unless a shared boost lib was included. Here: http://www.boost.org/doc/libs/1_52_0/libs/regex/doc/html/boost_regex/unicode.html it appears that the static lib compiled/linked with ICU is unicode aware. I think we need some unit/integration tests to probe what we're trying to achieve with ::regex. Grumble. ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] New HTTP Library Project Viewer
On 10/23/2012 6:10 AM, Henri Beauchamp wrote: And in fact, llappcorehttp.cpp only touches CP_CONNECTION_LIMIT, so CP_PER_HOST_CONNECTION_LIMIT is kept at its default (8) whatever the TextureFetchConcurrency debug setting value, meaning the viewer never opens more than 8 simultaneous connections per HTTP server. I therefore think that, as it is used right now TextureFetchConcurrency is not really useful (there's already a hard-coded limit of 40 in lltexturefetch.cpp for the max number of simultaenously queued texture fetching requests: perhaps this number should be affected by TextureFetchConcurrency instead ?), and in fact, the CP_CONNECTION_LIMIT will need to be much greater than 8 or 12, once the new HTTP core is used for connecting to other servers than just texture servers (mesh, capabilities, etc). On the other hand, I agree that CP_PER_HOST_CONNECTION_LIMIT should be kept below a reasonnable maximum value (8 sounds good for pipelining requests, but non-pipelining ones could probably allow up to 32 which is the default for per-host connections in most HTTP servers). Actually, GP_CONNECTION_LIMIT (global) and CP_PER_HOST_CONNECTION_LIMIT (per-class, per-host) aren't implemented yet so only CP_CONNECTION_LIMIT (and TextureFetchConcurrency) have effect. _httpinternal.h has the general to-do list for next phases. This is one area that should get some attention but a single control is all that's necessary for this release. As for the 40 request high water mark. That's part of a trade-off between several competing factors: 1. Deep pipelining to keep work available to low-level code (favors large numbers). 2. Responsiveness to changes in prioritization without having to serialize and pass new priority values down to lowest layers (favors small numbers). 3. Eventual balancing with other users of the same class to guarantee fairness and liveness. For textures, this will almost certainly include meshes and possibly other caps-based requests that don't use SSL. Unless the router is buggy, it shouldn't be impacted by the number of open sockets (at least not under 60K sockets)... Some protocols, such as torrent can use hundreds or even thousands of sockets at once. As Oz points out, routers are all affected by this and other factors. And I'd go so far to say that any router that implements NAT is guaranteed to be broken by design. But they're all broken in unique and interesting ways. Some are sensitive to connection concurrency. Others to connections created over a time interval. To counts of dest_addr:src_addr pairs, to counts of (dst_addr:dst_port:src_addr: src_port:ident) tuples. To DNS activity interspersed with handshakes. And then the failure modes are many. I once tried to build a simple control system to respond to failures but one family of routers takes five minutes to respond to a change in environment. Can't build a universally valid feedback system for this purpose with that kind of delay in the response. To quote Roy Batty: I've seen things you people wouldn't believe. Here's a chart I keep forwarding: http://www.smallnetbuilder.com/lanwan/router-charts/bar/77-max-simul-conn Not officially endorsed by Linden, etc., but a useful measure of one metric that is likely to predict problems. At the bottom of that chart you'll find members of router families that are both very common and very often a source of problems in SL. The true limit is server side. No, not really. It is *a* limit and one I'm deeply involved with. But there are people who are having difficulty getting to the servers and haven't even been able to enjoy its limits. ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] New HTTP Library Project Viewer
On 10/22/2012 6:28 PM, Henri Beauchamp wrote: In the current implementation, the new HTTP core can be configured to spawn from 12 to up to 256 (!) simultaneous connections... The texture fetcher code however never queues more than 40 requests at once, thus limiting the potential damages, but you might want to have a look at that and provide safer bounds before the new HTTP core gets used for more services in the viewer... No, the current HTTP code allows up to 12 concurrent connections with a shipping default of 8. A debug control is available to *reduce* not increase the concurrency. I'm interested in having available a control more refined than HTTP Textures on/off for people who have chronic connectivity problems. My hope is that knocking back concurrency will prevent certain routers from falling over. But other consumers, like mesh fetch, may completely swamp any improvement that control might offer. My backports allows from 8 to 32 simultaneous connections, with 12 as the default (i.e. same default as in viewer-http). You're running 50% hotter than I am. Stop eating all the sockets! :-) m ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] New HTTP Library Project Viewer
On 7/31/2012 10:03 PM, Kadah wrote: Its 8 again with the fallow comment. I tired to track down the rev, but apparently Mecurial 2.2 can't properly annotate that file for some reason, and the new UI for it in TortoiseHg2 is horrid. All of the referenced jiras around its changes are not public. One of the major reasons around that has to do with the behavior of low-end routers. It really is a problem for them. ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] New HTTP Library Project Viewer
On 7/30/2012 2:15 PM, Celierra Darling wrote: FYI, the Firefox folks had a conversation in 2008 and decided to bump up from 2 to 6 by default at that time (partly because everyone else was raising it).[1] (And for what it's worth, I found a mention from '06 that anything above 10 is excessive.[2]) That doesn't necessarily mean SL viewers should use the same values, but I think it probably demonstrates where people might try to push that setting, at least at first. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=423377#c4 [2] http://kb.mozillazine.org/index.php?title=Network.http.max-persistent-connections-per-serverdiff=28784oldid=28783 On the limiting side of things, we have to deal with this unfortunately: http://www.smallnetbuilder.com/wireless/wireless-reviews/26843-linksyswrt54gv5reallyisalousyrouter?showall=start=4 Finding a one-size-fits-all solution is a challenge when the consumer space performance range spans a 3000:1 ratio. I also did some tests on throughput-vs-concurrency and at 10 connections we're falling away from linear speedup. The example code in the new library happens to be a performance test framework should anyone want to play... m ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] New HTTP Library Project Viewer
On 7/30/2012 5:03 PM, Tateru Nino wrote: Heck, I know one person with two. A Belkin G *and* a Linksys WRT. There's someone who I would like to buy a drink. ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Build Error llviewermessage.cpp Linux 32
On 8/31/2011 12:53 AM, Mysty Saunders wrote: /home/mysty/slq/viewer-development/indra/newview/llviewermessage.cpp: In function ‘void process_improved_im(LLMessageSystem*, void**)’: /home/mysty/slq/viewer-development/indra/newview/llviewermessage.cpp:2858: error: ‘region_access’ may be used uninitialized in this function Can any help me get a clue to resolve this please? At 2858, change: U8 region_access; to: U8 region_access(0); or back the compiler down to 4.1 or disable some checks. The compiler is doing deep but not deep enough static analysis and declaring the code wonky. (Guilty!) ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] SOCKS viewer
On 7/14/2011 11:05 AM, Lee ponzu wrote: So, suppose you had two or more clients using the same cacheing SOCKS proxy. If they needed the same data (say the two users were in the same classroom or sex club), would they both get their data from the SOCKS cache? Not at this point. While two viewers will certainly fetch the same object, they'll do it with different URLs. Currently, our URLs are neither Resources nor Locators really and attempting to cache at the HTTP-level is problematic. That may change in the future but right now, that's what we have. So the immediate *proxy* work is to get HTTP SOCKS5 proxying working correctly and uniformly in the viewer. As far as asset caching goes the cache maximum has been bumped up recently. Give it a try people and please report back any problems. m ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Review Request: STORM-1112 Support SOCKS 5 proxy in the viewer (take 2)
--- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/374/#review863 --- indra/llmessage/llcurl.cpp http://codereview.secondlife.com/r/374/#comment880 Correct whitespace. indra/llmessage/llpacketring.h http://codereview.secondlife.com/r/374/#comment884 A few things mostly on coding style here: 1. You'll mostly see method declarations separate from member declarations. It's often due to access controls but it's also a good organizational thing. I'd move the method up here. 2. This is really a private/protected method. No external user should call this. Making it so is compatible with 1. 3. Terrible name. SendPacket and doSendPacket. This is some sort of sendPacketImpl or routePacket, I think. indra/llmessage/llpacketring.cpp http://codereview.secondlife.com/r/374/#comment890 With the proxy code, we could get data larger than NET_BUFFER_SIZE. We don't detect this condition in receive_packet. Might just log initially. So much wrong with it indra/llmessage/llpacketring.cpp http://codereview.secondlife.com/r/374/#comment886 Magic number from original code review. Need these definitions (10) in the socks protocol definition set. indra/llmessage/llpacketring.cpp http://codereview.secondlife.com/r/374/#comment888 Not necessary now but something for a follow-on jira. This would have been a good place for a scatter/gather i/o using recvmsg to avoid the data copying. indra/llmessage/llpacketring.cpp http://codereview.secondlife.com/r/374/#comment891 Isn't packet_size '10' too large at this point? indra/llmessage/llpacketring.cpp http://codereview.secondlife.com/r/374/#comment889 I just looked into get_sender() and get_receiving_interface(). *weep* They use statics. So no thread safety. If we do improve the receive_packet interface to ever to scatter/gather, *this* will go. indra/llmessage/llpacketring.cpp http://codereview.secondlife.com/r/374/#comment892 Another perfect opportunity for scatter/gather i/o. indra/llmessage/llpacketring.cpp http://codereview.secondlife.com/r/374/#comment893 Caller may still reasonably try to write a full NET_BUFFER_SIZE of data in which case this smashes memory. - Monty On July 12, 2011, 11:20 a.m., Log Linden wrote: --- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/374/ --- (Updated July 12, 2011, 11:20 a.m.) Review request for Viewer, Oz Linden, Monty Brandenberg, and Stone Linden. Summary --- This is a continuation of Robin Cornelius's SOCKS 5 contribution, shown in https://codereview.secondlife.com/r/232/ . I have tried to address all of the comments on that code review and do as much cleanup as possible. The diff includes everything that was submitted by Robin, as well as my work. Major changes since I started working: * Changed SOCKS 5 proxy control channel to use the existing LLSocket class, which is a thin wrapper around APR sockets. * Worked with the Linden Lab UX team to revamp the proxy controls. * Proxy credentials are now stored in the LLSecAPI password storage, which is the same that is used for users' Second Life Credentials instead of as being stored in the clear as a preference. This addresses bug STORM-1112. http://jira.secondlife.com/browse/STORM-1112 Diffs - indra/llmessage/CMakeLists.txt c7a4b7a24e05 indra/llmessage/llcurl.cpp c7a4b7a24e05 indra/llmessage/lliosocket.h c7a4b7a24e05 indra/llmessage/lliosocket.cpp c7a4b7a24e05 indra/llmessage/llpacketring.h c7a4b7a24e05 indra/llmessage/llpacketring.cpp c7a4b7a24e05 indra/llmessage/llproxy.h PRE-CREATION indra/llmessage/llproxy.cpp PRE-CREATION indra/llmessage/net.h c7a4b7a24e05 indra/llmessage/net.cpp c7a4b7a24e05 indra/llui/llfunctorregistry.h c7a4b7a24e05 indra/newview/app_settings/settings.xml c7a4b7a24e05 indra/newview/llappviewer.cpp c7a4b7a24e05 indra/newview/llfloaterpreference.h c7a4b7a24e05 indra/newview/llfloaterpreference.cpp c7a4b7a24e05 indra/newview/llloginhandler.cpp c7a4b7a24e05 indra/newview/llpanellogin.h c7a4b7a24e05 indra/newview/llsecapi.h c7a4b7a24e05 indra/newview/llstartup.h c7a4b7a24e05 indra/newview/llstartup.cpp c7a4b7a24e05 indra/newview/llviewerfloaterreg.cpp c7a4b7a24e05 indra/newview/llxmlrpctransaction.cpp c7a4b7a24e05 indra/newview/skins/default/xui/en/floater_preferences_proxy.xml PRE-CREATION indra/newview/skins/default/xui/en/notifications.xml c7a4b7a24e05 indra/newview/skins/default/xui/en/panel_cof_wearables.xml
Re: [opensource-dev] Review Request: STORM-1112 Support SOCKS 5 proxy in the viewer (take 2)
On 7/12/2011 5:35 PM, Monty Brandenberg wrote: This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/374/ I'm doing this review in pieces, btw. Too much code for one go... ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Is it just me? Avatar textures downloading last.
On 6/23/2011 1:06 AM, Lee ponzu wrote: * 1. Second Life Viewer - VWR https://jira.secondlife.com/browse/VWR * VWR-26093 https://jira.secondlife.com/browse/VWR-26093 Mass avatar texture rebake and load failures resulting in blury and grey textures which do not resolve on their own https://jira.secondlife.com/browse/VWR-26093 Already exists. I added a comment and my logs to it. Shoud this be a VWR Jira? Or could it be related to some other system. That's fine. We'll move it around as needed. And thanks for DEBUG level info. (Sim has the enable_simulator storm I hate. Not the problem, just sticks 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
Re: [opensource-dev] Is it just me? Avatar textures downloading last.
On 6/20/2011 5:20 PM, Lee ponzu wrote: If I can help gather any data let me know. Jira + description of events with timeline + logfile ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Review Request: Viewer cache size increase to 10GB.
On 6/6/2011 11:00 PM, Tateru Nino wrote: Not that I'm not glad to see the maximum cache size increased, but the cache cap was only very reluctantly increased to 1GB as the performance of the system increasingly suffered as the quantity of cached objects increased. How did we solve this? Different cache for the most part (we have many caches). This change mainly affects the *texture* cache. The general asset VFS cache is still capped for technical reasons. The scene caching is unchanged. We really want feedback on this on all platforms. Load up the texture cache, get your favorite regions in there, run around, clear the cache, do it again, etc. This work is being done under VWR-25182. Comments welcome and attach some jiras if you encounter problems. m ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Review Request: VWR-25610 LLControlGroup::loadFromFile makes unnecessary copies of large LLSD objects
On 4/27/2011 2:57 PM, Brad Kittenbrink wrote: On April 27th, 2011, 4:16 a.m., *Boroondas Gupte* wrote: 2) Remove space betweenconst and, so that it's easer to visually distinguish from binary operator 2) I think this is a bad idea, that would be far less readable imho. love brad for correct coding style. ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Windows compiling problem
On 4/12/2011 6:53 PM, Nicky Perian wrote: Dont' want to come across as self-promoting and am hesitant to advise LL devs Don't be shy how are we ever going to learn? ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Windows compiling problem
On 4/6/2011 11:46 AM, Monty Brandenberg wrote: Confirmed (I get it myself). Probably has to do with sensitivity to the SDKs installed on the system. The offending include order, in reverse order, is: C:\\Program Files (x86)\\Microsoft SDKs\\Windows\\v7.0A\\include\\objid l.h C:\\Program Files (x86)\\Microsoft SDKs\\Windows\\v7.0A\\include\\obj base.h C:\\Program Files (x86)\\Microsoft SDKs\\Windows\\v7.0A\\include\\ole2.h c:\\mcb\\hg\\viewer-development\\indra\\llwindow\\lldragdropwin32.h So I cleared this and the remainder of my problems by: - Updating autobuild from bitbucket. - Installing the 7.0A Windows SDK from MSDN on top of (or instead of, presumably) the 7.0A Windows SDK on the VS2010 DVD. - Updated DirectX to June '10 (was still using August '08 based on old internal setup). - Install UNSIS to clear error that looks like a path problem when we package. ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Windows compiling problem
On 4/5/2011 4:03 PM, Jonathan Welch wrote: I have not had much chance to compile since viewer-development took in the autobuild changes. This afternoon I gave it a try and fixed a few issues but am stumped at how to fix this, which occurs in a number of places: -- Build started: Project: llwindow, Configuration: Release Win32 -- llwindowwin32.cpp lldxhardware.cpp e:\Microsoft SDKs\Windows\v7.1\Include\objidl.h(11280): error C2061: syntax error : identifier '__RPC__out_xcount_part' e:\Microsoft SDKs\Windows\v7.1\Include\objidl.h(11281): error C2059: syntax error : ')' e:\Microsoft SDKs\Windows\v7.1\Include\objidl.h(11281): fatal error C1903: unable to recover from previous error(s); stopping compilation I fiddled a bit with the include path in the props file and this is what I currently have: IncludePathE:\Microsoft Visual Studio 10.0\VC\INCLUDE;e:\Microsoft SDKs\Windows\v7.1\Include;e:\Microsoft SDKs\Windows\v7.1\Include\gl;e:\Microsoft DirectX SDK (June 2010)\Include;e:\Microsoft SDKs\Windows\v7.1\Samples\winui\TSF\tsfapp;$(WindowsSdkDir)\include;$(IncludePath)/IncludePath That first entry is a result of my fiddling. This is happening in vs2010 but also via autobuild in a dos window. Googling on this error says it is an issue of having the include file list in a certain order, but as far as I can tell my list is correct...and worked when we were testing autobuild builds before the code got merged into viewer-development. Can you shed any light on this? I am stumped. Confirmed (I get it myself). Probably has to do with sensitivity to the SDKs installed on the system. The offending include order, in reverse order, is: C:\\Program Files (x86)\\Microsoft SDKs\\Windows\\v7.0A\\include\\objid l.h C:\\Program Files (x86)\\Microsoft SDKs\\Windows\\v7.0A\\include\\obj base.h C:\\Program Files (x86)\\Microsoft SDKs\\Windows\\v7.0A\\include\\ole2.h c:\\mcb\\hg\\viewer-development\\indra\\llwindow\\lldragdropwin32.h ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Review Request: VWR-20801 Implement SOCKS 5 Proxy for the viewer
--- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/232/#review537 --- Final pass through the code for review (I'll do this again after changes in the code). Two followups that must happen from SNOWSTORM: 1. Some panel/GUI changes that probably need review. 2. Password storage in the panel almost certainly needs to be moved to the LLSecAPI lump (or wherever 'Remember password' gets stuffed). indra/newview/llfloaterpreference.h http://codereview.secondlife.com/r/232/#comment458 Wonder if the new GUI layout should have a review indra/newview/llfloaterpreference.cpp http://codereview.secondlife.com/r/232/#comment459 General whitespace comment applies. I *think* we're still doing tabs, yes? indra/newview/llfloaterpreference.cpp http://codereview.secondlife.com/r/232/#comment460 We test mSocksSettingsDirty twice in this method unnecessarily (any differently). 'untill' - 'until' Re: comment. What are we telling the user here? It looks like we might not even save the settings. Explain. indra/newview/llfloaterpreference.cpp http://codereview.secondlife.com/r/232/#comment461 I have a suspicion here that we are saving the socks5 password to the generic settings mechanism. I don't think we can do that and we must use the LLSecAPI junk. indra/newview/llstartup.cpp http://codereview.secondlife.com/r/232/#comment462 It looks like this was disabled when it needed to be moved to some location after the proxy setup. Is that correct? I didn't see the new location in the code review tool... indra/newview/llstartup.cpp http://codereview.secondlife.com/r/232/#comment465 handleSocksProxy() seems to be setting up both standard HTTP proxies and Socks5 proxies. But this code is only allowing that for Socks5 proxies. Bad in itself but is caused by logic being replicated in several levels. This often indicates a design problem. indra/newview/llstartup.cpp http://codereview.secondlife.com/r/232/#comment463 There's a minor consistency problem in the settings checking here. If BrowserProxyEnabled and Socks5ProxyEnabled both are set true (accidentally, file corruption, logic error, whatever), one piece of code will treat this as having the BrowserProxyEnabled, another piece will treat it as Socks5ProxyEnabled. When I do these things, I like to sample the settings values once, normalize them to valid states and then code to those normalized values. indra/newview/llstartup.cpp http://codereview.secondlife.com/r/232/#comment464 Only variant in all these case statements is the first argument of the call. Might just set that in a stack variable and use it in one place after the switch. It is soo close to being stringizable. indra/newview/llxmlrpctransaction.cpp http://codereview.secondlife.com/r/232/#comment466 It's kind of clear that the 'LLSocks' class is really misnamed. It encompasses standard HTTP proxying as well as Socks5 proxying and if other styles come along, those as well. A class-and-file rename looks to be in order here. indra/newview/llxmlrpctransaction.cpp http://codereview.secondlife.com/r/232/#comment467 This piece of logic inside the isHttpProxyEnabled() test is beginning to look like a common idiom. Is it something that might be extracted into a free function in the LLSocks.cpp module to provide common glue between proxy configurations and libcurl option settings? - Monty On March 28, 2011, 4:46 a.m., Robin Cornelius wrote: --- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/232/ --- (Updated March 28, 2011, 4:46 a.m.) Review request for Viewer. Summary --- VWR-20801 - Add ability to use SOCKS 5 proxy to the viewer. This allows the UDP and/or the http requests to be sent via a SOCKS 5 proxy. This also allows http proxies to be used for other http operations such as caps etc as required. All the proxy settings have been unified on a single proxy floater accessable from preferences. This addresses bug VWR-20801. http://jira.secondlife.com/browse/VWR-20801 Diffs - indra/llmessage/CMakeLists.txt 65ff7415f171 indra/llmessage/llcurl.cpp 65ff7415f171 indra/llmessage/llpacketring.h 65ff7415f171 indra/llmessage/llpacketring.cpp 65ff7415f171 indra/llmessage/llsocks5.h PRE-CREATION indra/llmessage/llsocks5.cpp PRE-CREATION indra/llmessage/net.h 65ff7415f171 indra/llmessage/net.cpp 65ff7415f171 indra/newview/app_settings/settings.xml 65ff7415f171 indra/newview/llfloaterpreference.h 65ff7415f171 indra
Re: [opensource-dev] Review Request: VWR-20801 Implement SOCKS 5 Proxy for the viewer
On March 29, 2011, 4:19 p.m., Merov Linden wrote: Excellent! Except for a handful of minor typos, I've no problem with that code. One thing important though before we merge is to use the correct lgpl header for the new files. I hope others will also review and try it out before we merge as it's a fair amount of code. I definitely would like to review this but I can't for several days. But it's on my list. :-) - Monty --- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/232/#review519 --- On March 28, 2011, 4:46 a.m., Robin Cornelius wrote: --- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/232/ --- (Updated March 28, 2011, 4:46 a.m.) Review request for Viewer. Summary --- VWR-20801 - Add ability to use SOCKS 5 proxy to the viewer. This allows the UDP and/or the http requests to be sent via a SOCKS 5 proxy. This also allows http proxies to be used for other http operations such as caps etc as required. All the proxy settings have been unified on a single proxy floater accessable from preferences. This addresses bug VWR-20801. http://jira.secondlife.com/browse/VWR-20801 Diffs - indra/llmessage/CMakeLists.txt 65ff7415f171 indra/llmessage/llcurl.cpp 65ff7415f171 indra/llmessage/llpacketring.h 65ff7415f171 indra/llmessage/llpacketring.cpp 65ff7415f171 indra/llmessage/llsocks5.h PRE-CREATION indra/llmessage/llsocks5.cpp PRE-CREATION indra/llmessage/net.h 65ff7415f171 indra/llmessage/net.cpp 65ff7415f171 indra/newview/app_settings/settings.xml 65ff7415f171 indra/newview/llfloaterpreference.h 65ff7415f171 indra/newview/llfloaterpreference.cpp 65ff7415f171 indra/newview/llstartup.h 65ff7415f171 indra/newview/llstartup.cpp 65ff7415f171 indra/newview/llviewerfloaterreg.cpp 65ff7415f171 indra/newview/llxmlrpctransaction.cpp 65ff7415f171 indra/newview/skins/default/xui/en/floater_preferences_proxy.xml PRE-CREATION indra/newview/skins/default/xui/en/notifications.xml 65ff7415f171 indra/newview/skins/default/xui/en/panel_preferences_setup.xml 65ff7415f171 Diff: http://codereview.secondlife.com/r/232/diff Testing --- Verified login and in world interaction with proxy disabled, verified login and in world interactionvia socks 5 proxy. Code has been tested on Windows very recently and has also worked fine on linux, but i'm not currently in a position to retest that or Mac at all. Much more testing is needed to verify this does not break anything unexpectedly and also works as expected when enabled. To test requires a working socks 5 proxy. Thanks, Robin ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Review Request: Enable CURLOPT_ENCODING for Inventory caps, which uses the LLURLRequest code path
--- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/242/#review512 --- Before shipping, review the exploit history around CURLOPT_ENCODING. There is a known buffer overflow exploit, I believe in pre-7.20 releases but that should be checked first for applicability. - Monty On March 28, 2011, 6:22 p.m., Stone Linden wrote: --- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/242/ --- (Updated March 28, 2011, 6:22 p.m.) Review request for Viewer, Oz Linden, Joshua Linden, and Brad Kittenbrink. Summary --- Enable Accept-Encoding: deflate, gzip in libcurl via setopt CURLOPT_ENCODING. I'm approaching this for Inventory, but it would apply to any HTTP request that goes through the LLURLRequest code path (vs. the LLCurl code path, which already does this). Diffs - indra/llmessage/llurlrequest.cpp 2ae060c0fa91 Diff: http://codereview.secondlife.com/r/242/diff Testing --- Inventory loads, and I see the encoding options coming through on the backend apache logs. Thanks, Stone ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] A CALL FOR HHHEEELLLPPP
On 3/16/2011 6:04 AM, Thickbrick Sleaford wrote: /* rant, please ignore... */ Hahaha! Agreed. We have varying standards internally, as well. Honestly, I wouldn't mind something like a Weekly WTF? where non-Linden devs pick out a piece of bad code and grill us over it. It may not help but it will be entertaining. m ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] VS2010 Express fails basic test
On 2/28/2011 8:48 AM, Jonathan Welch wrote: I have been trying, with the help of NickyP and archer to get my VS2010 environment set up properly. snip CMake Error at e:/CMake 2.8/share/cmake-2.8/Modules/CMakeTestCCompiler.cmake:52 (MESSAGE): The C compiler E:/Microsoft Visual Studio 10.0/VC/bin/cl.exe is not able to compile a simple test program. It fails with the following output: Change Dir: E:/project/viewer-autobuild2010-wip/build-vc100/CMakeFiles/CMakeT mp I had a similar problem getting Win7-64bit setup with vs2010. The following may or may not solve your problem, however: 1. Reboot. After the VS SP1 upgrade and the special vista/w7 VS upgrade, it turned out a simple reboot fixed the problem. Which is fortunate because the error code I was getting was only documented on a site in Mandarin. 2. Finding the error code involved using the --debug-trycompile option to cmake. This leaves all temporaries in place including log/htm output with better diagnostics. Start with that if 1. doesn't do it. -- Monty Brandenberg 617.401.2384 mo...@lindenlab.com ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] VS2010 Express fails basic test
On 2/28/2011 3:58 PM, Monty Brandenberg wrote: I had a similar problem getting Win7-64bit setup with vs2010. The following may or may not solve your problem, however: Bleh I've been doing win7-64bit/vs2005 and xp/vs2010 and mixed up the two. My problem was the former, not the latter. Beware of Lindens offering free advice... -- Monty Brandenberg 617.401.2384 mo...@lindenlab.com ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] saving textures
On 12/30/2010 12:50 PM, Trilo Byte wrote: I'm experiencing the same failure, build 217920. I wrote up a JIRA: https://jira.secondlife.com/browse/VWR-24353 Please vote, add a comment with your machine/OS info/build info, or any other pertinent info I might have missed. There are several interesting things happening in the log file fragment you attached (including a functor lookup problem in UI Toast land). But the interesting one I expect is this: 2010-12-30T18:07:44Z INFO: parse: LLSDXMLParser::Impl::parse: XML_STATUS_ERROR parsing:cap invocation rate exceeded: 'xx----' Need more info (logs, additional confirmation) but I suspect we're getting error status back in a bad encoding and so we don't know to retry a save in the viewer. -- Monty Brandenberg mo...@lindenlab.com ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Debugging Snowstorm under Linux x64 with GDB locks the whole X session
On 12/29/2010 4:00 PM, Zabb65 wrote: Reading through the documentation on this. It may be easier to just add GDK_DEBUG=nograbs to the shell script launcher when it uses GDB, and have it work on all distros, up to date or not? Yep, except for the attach-after-start case. (Wish I could test it *sigh*). -- Monty Brandenberg 617.401.2384 mo...@lindenlab.com ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Question about the Too Many Open Files problem
On 9/19/2010 4:18 PM, Vex Streeter wrote:
HTTP textures seems to make an already bad situation worse. A very
large number of the open files I see on Linux are fonts: I've seen up
to 20 FDs pointing to the same font file - I typically run under linux
with a ulimit of 2048 to avoid the issue. I see similar things on
Windows (7) but it is neither quite as bad (fewer fonts maybe?) nor
happens to hit whatever fd limit windows has. One of the problems with
running out of FDs is that the viewer can fail in all sorts of bizarre
ways and will often not be able to dump a useful log.
This might be worth a Jira, at least to start feeding in tracking
information. On Linux, I'd expect this to at least generate a
strerror() message for ENFILE or EMFILE ('Too many open files in system'
and 'Too many open files') with similar messages on Mac. Full 'lsof'
output before or after a problem might be interesting, too. Something
in Ponzu's Problem has me looking in the direction of plugins as well.
But a rigorous test with HTTP Textures enabled and disabled would also
be useful...
m
--
Monty Brandenberg
mo...@lindenlab.com
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Question about the Too Many Open Files problem
On 9/20/2010 5:45 AM, Tofu Linden wrote: For anyone interested, https://jira.secondlife.com/browse/SH-173 Oh, and there's the strerror message. :-) -- Monty Brandenberg mo...@lindenlab.com ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] This cannot be right...
On 9/9/2010 3:47 PM, Ponzu wrote: Tried the later build, 209229. Same line in syslog.log A lot of completely unrelated programs are reporting the deliver_request: socketpair failed 24 (Too many open files) error (winbindd, hg, omd, Brother printers). Suggest you try two things: 1. Use 'lsof -p pid' while this occurs to see what is consuming all the file descriptors. Some additional options might be needed to get deeper information. 2. Bump the limit up in a process (ulimit -n 1024) and then use 'open' to start the viewer in that process and see if that works around the limit. I don't know what the real issue is but the internetz are full of *interesting* theories. Bonjour seems to be the likely candidate: http://discussions.apple.com/thread.jspa?threadID=2186838start=30tstart=0 http://discussions.apple.com/thread.jspa?messageID=10121652#10121652 http://discussions.apple.com/thread.jspa?threadID=2139587tstart=0 http://developer.apple.com/library/mac/#qa/qa2001/qa1297.html m -- Monty Brandenberg mo...@lindenlab.com ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Introduction
On 6/1/2010 9:30 PM, Oz Linden (Scott Lawrence) wrote: Conflict is fine - sometimes it's even productive, as long as it's done in a way that recognizes that everyone is ___ Sorry, people, Oz got into a fight. He'll pick this up again after the beating... -- Monty Brandenberg 617.401.2384 mo...@lindenlab.com ___ 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
