| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
|
|
being used as an operand to typeid'
|
|
query part as well.
fix by Ansariel
|
|
|
|
|
|
|
|
|
|
|
|
|
|
RenderVolumeLODFactor
- fix for review
- fix in buffer overrun detector
|
|
|
|
Request max 5 attachments per idle loop to reduce sim-side failures seen when requesting large numbers.
|
|
Changeset ffd264ca493c removed the whole llstdio_filebuf construct, which is
what depended on the __gnu_cxx::stdio_filebuf<> extension. Now, even on
Windows, ll[io]fstream very closely resembles std::[io]fstream.
Since we no longer depend on that extension, we can remove its #include.
This should (!) remove the last obstacle to building with libc++ on the Mac.
|
|
and open() methods. The only remaining value added by ll[io]fstream over
std::[io]stream is proper handling of non-ASCII pathnames, which can be done
by deriving from std::[io]stream, converting pathname strings and passing them
to the corresponding base-class methods.
This is only necessary on Windows. On Posix, ll[io]fstream are already
typedefs for std::[io]fstream.
This change removes a significant volume of cruft from llfile.{h,cpp}.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
wide char paths; on other platforms they are now just typedefs to the std classes
|
|
|
|
respectively
|
|
respectively
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
|
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.
|
|
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.
|
|
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.
|
|
LLMarketplaceFolderBridge class in the bridge model. Only the panels with the use_marketplace_folders param flag will use that one.
|
|
|
|
|
|
ms_sleep() calls and adjust expectations accordingly
|
|
|
|
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.
|
|
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!
|
|
|
|
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...
|
