summaryrefslogtreecommitdiff
path: root/indra/llcommon
AgeCommit message (Collapse)Author
2015-03-23Reogranized some headers for GCC added <memory> to the linden_common.h for ↵Rider Linden
shared_ptr
2015-02-24merge changes for 3.7.25-releaseOz Linden
2015-01-28MAINT-4744: Eliminate viewer dependency on (old) GNU libstdc++.Nat Goodspeed
To be more accurate, this changeset doesn't actually eliminate the dependency: it eliminates the use cases for the llifstream / llofstream feature that requires it. Currently you can construct an llifstream or llofstream from an open LLFILE* file handle (or, except on Windows, an int file descriptor). But rather than containing a streambuf implementation based on FILE*, llfile.h relies on the fact that the Windows std::filebuf happens to support that as a nonstandard extension; also on a nonstandard GNU extension __gnu_cxx::stdio_filebuf<char>. To move from GNU libstdc++ to clang's libc++ (the direction on Mac), we could code a streambuf that supports FILE*. But before doing that, it's worth asking whether anyone actually uses this questionable feature. In fact there were only two methods: LLWearable::exportFile() and importFile() -- and only one call to either, in LLViewerWearable::saveNewAsset(). The code in saveNewAsset() opened the LLFILE* immediately before calling exportFile(), meaning we could reasonably push the open operation down into exportFile(). That logic was complex anyway due to the need for the caller to close the LLFILE* regardless of the success of the exportFile(). Change LLWearable::exportFile() and importFile() to accept a std::string filename rather than an open LLFILE*. Change LLViewerWearable::saveNewAsset() to simply call exportFile(filename) rather than horsing around with an LLFILE* handle. (This improves the code in another way too: it encapsulates the need to open the relevant file in binary mode. Previously, each caller had to remember to do that.) To prevent inadvertent reintroduction of ll[io]fstream(LLFILE*) code, add llstream_LLFILE preprocessor macro (default 0) to control access to the relevant constructors. Also suppress rdbuf() override, the only method whose signature references llstdio_filebuf.
2015-01-22Disambiguate constructor's initialization call to its base class.Nat Goodspeed
A particular LLInitParam::TypeValuesHelper specialization is derived from a different TypeValuesHelper specialization. The subclass constructor TypeValuesHelper(...) has previously forwarded the call to its base-class constructor with: TypeValuesHelper(val): TypeValuesHelper(val) {} This is the first time I've looked at that; I'm a bit surprised that previous compilers blithely accept it, and apparently understand the intent. gcc 4.7 complains that we would need to turn on -std=c++11 to support delegating constructors; obviously the second TypeValuesHelper is now assumed to be the class being defined, rather than its base class. Fortunately the class already has typedefs for both specializations, fully qualified with all template parameters, so I simply replaced the second TypeValuesHelper reference with base_t.
2015-01-16Continue gradually replacing Boost.Lambda with Boost.Phoenix.Nat Goodspeed
For some reason, after the upgrade to Boost 1.57, gcc 4.6.3 has trouble with the boost::lambda::_1 usage in stringize.h. This is consistent with other cases we've encountered in which Boost.Lambda appears to be unmaintained and losing its compatibility with other libraries. Fortunately Phoenix provides a functional equivalent, albeit spelled differently.
2015-01-12Experimentally try full-size LLLeap stream test on Windows.Nat Goodspeed
The new toolchain may (!) have fixed a longstanding bug in LLLeap / APR when we try to pump large volumes of data through a Windows named pipe using APR nonblocking I/O. This used to fail pretty consistently because the APR nonblocking write call would sometimes spuriously return "would block" when in fact the data buffer was completely written; the caller would later retry, which of course would duplicate some of the data in the pipe. Preliminary experiments with VS 2013 suggest this may have been resolved. This changeset is to propagate the experiment to a wider range of Windows systems; we may need to revert it if in fact the bug persists.
2014-12-23merge some linux fixes and OPEN-287Oz Linden
2014-12-23fix dos line endingsOz Linden
2014-12-22Investigative check-in to see if system clock() function can be used to time ↵callum_linden
ms_sleep() calls and adjust expectations accordingly
2014-12-22work arounds to compile on linuxOz Linden
2014-12-16For one use case, boost::bind() better than boost::phoenix::bind().Nat Goodspeed
We use boost::phoenix::placeholders::arg1 to imply a whole lambda expression, replacing boost::lambda. But to bind a plain function in a more straightforward way, seems classic boost::bind() works while boost::phoenix::bind() does not.
2014-12-16Isolate #pragma clang to __clang__ compilations.Nat Goodspeed
It's very irritating that Visual Studio produces a warning for unrecognized #pragmas, which we then merrily turn into an error -- #pragma is inherently compiler-specific!
2014-12-12fix dos line endingsOz Linden
2014-12-12Eliminate use of boost::lambda with boost::function (Trac #10864).Nat Goodspeed
https://svn.boost.org/trac/boost/ticket/10864 I've used boost::lambda with boost::function in a number of creative ways over the years. But the clang 6 shipped with Xcode 6 seems to have somehow broken lambda + function in Boost 1.57. boost::phoenix is a partial workaround. Sadly, lambda's comma-operator overload doesn't seem to be supported, necessitating a couple ugly workarounds. With real lambdas now supported by current compilers, I'm sure the Boost community has little incentive to repair the lambda + function problem. Presumably we'll be able to use such features ourselves Real Soon Now...
2014-12-11Disambiguate a few ensure() calls.Nat Goodspeed
These were of the form ensure(std::string, something convertible to bool). Not sure what the ambiguity was, but ensure(std::string, bool(something)) works better.
2014-12-10Clarify for VS 2013 that an operator bool() method returns bool.Nat Goodspeed
For some reason VS 2013 (unlike its predecessors and other current compilers) needs us to explicitly convert an operator bool() method's return expression to bool. :-P
2014-12-10Fix for build problems with LLTrace::AccumulatorBuffer copy ctor in VS2013 ↵callum_linden
(only)
2014-12-09no implicit conversion from ofsteam to bool in VS2013!!!!callum_linden
2014-11-19OPEN-282 - Define LL_THREAD_LOCAL for our platforms in order to unify TLS ↵Cinder
support
2014-11-19OPEN-282 Use pthreads for TLS on macCinder
2014-11-14remove skip from llframetimer_test now that it is fixedOz Linden
2014-11-14merge up to tip of viewer-tools-updateOz Linden
2014-11-14rewrite an llframetimer test to be less sensitive to extended ms_sleep callsOz Linden
2014-11-14Convert llhash() to use boost::hash, per Cinder's suggestion.Nat Goodspeed
2014-11-14Skip LLFrameTimer test<3>, which fails with Xcode 6.x builds.Nat Goodspeed
Hopefully this is temporary until we figure out the real problem!
2014-10-23Bring in new TUT library build. Clean up ensure_equals() overloads.Nat Goodspeed
The new TUT library build eliminates the ambiguity about ensure_equals(const char*, ...) versus ensure_equals(const std::string&, ...). Now it's all based on const std::string&. Remove pointless const char* overloads and ambiguous forwarding templates. With clang in Xcode 6, any new datatypes we intend to use with ensure_equals() must have operator<<(std::ostream&, datatype) declared BEFORE lltut.h #includes tut.hpp. Reorder code in certain test source files to guarantee that visibility.
2014-10-22Update to build on Xcode 6.0 (fix unit tests): minor fix for debug only unit ↵callum_linden
test
2014-10-22Remove unit test case that relied on undefined order of evaluationOz Linden
in: 'cout << a() << b()' the order of evaluation of a() and b() is undefined.
2014-10-22merge with more fixes from callumOz Linden
2014-10-22correct merge error in llerror_test.cppOz Linden
2014-10-22Update to build on Xcode 6.0 (fix unit tests): remove unused statement warningcallum_linden
2014-10-22Update to build on Xcode 6.0 (fix unit tests): skip llerror_test test for ↵callum_linden
now - operator << issues on clang
2014-10-22Update to build on Xcode 6.0 (fix unit tests): remove unused functions that ↵callum_linden
trigger clang warnings
2014-10-22Update to build on Xcode 6.0 (fix unit tests): fix up Boost linker errorscallum_linden
2014-10-22added skip to llerror_test of nested logging, noted in todo fileOz Linden
2014-10-21Update to build on Xcode 6.0: remove release build unused functioncallum_linden
2014-10-20Update to build on Xcode 6.0: fix typo in functions paramscallum_linden
2014-10-17Update to build on Xcode 6.0: fix Boost intrusive_ptr scoping issue (part 2 ↵callum_linden
- tidy up)
2014-10-17Update to build on Xcode 6.0: fix Boost intrusive_ptr scoping issuecallum_linden
2014-10-17Update to build on Xcode 6.0: collection of similar const var not used ↵callum_linden
warnings/errors [-Wunused-const-variable]
2014-10-17Update to build on Xcode 6.0: clang warned about comparison of unsigned int ↵callum_linden
to >=0 - correct ifx here is to retype the variable as signed
2014-10-17Update to build on Xcode 6.0: remove unused function that makes clang sadcallum_linden
2014-10-17Update to build on Xcode 6.0: remove unused member variable that makes clang sadcallum_linden
2014-10-17Update to build on Xcode 6.0: additional scoping required for clangcallum_linden
2014-10-17Update to build on Xcode 6.0: remove unused variable [-Wunused-const-variable]callum_linden
2014-10-17Update to build on Xcode 6.0: TEMP fix to remove broken code (clang) until ↵callum_linden
it's true purpose becomes clear
2014-10-17Update to build on Xcode 6.0: turn BACK ON warnings as errors for overloaded ↵callum_linden
virtuals [-Woverloaded-virtual] and fix up first (of many) files
2014-10-17Update to build on Xcode 6.0: reorder code and additional scoing in template ↵callum_linden
classes to make clang happy
2014-10-14Reorder LLEventDetail::listenerNameForCoro[Impl]() decls for Xcode 6.Nat Goodspeed
2014-10-07MAINT-4548 & MAINT-4557 FIXED build issuesmaksymsproductengine