| Age | Commit message (Collapse) | Author |
|---|
|
must return less than 1.0 when rand() returns RAND_MAX
also, disable 32 bit build now that we have deprecated it.
https://community.secondlife.com/blogs/entry/13464-end-of-support-for-second-life-32-bit-windows-viewer-and-updated-minimum-system-requirements-for-macos-to-1013/
|
|
|
|
VERSION_BUILD is now too big to fit in 32 bits, and cpuid doesn't do what we expect under rosetta
|
|
|
|
|
|
This reverts commit 996ea03d874c714f312c1bfbafda3dddc2172a39.
|
|
branch
|
|
|
|
|
|
|
|
which should only affect Windows unit tests, but should hopefully improve our
chances that Windows unit tests will succeed.
|
|
|
|
Using concatenation appends the intended filename to the parent directory
name, instead of putting the filename in the parent directory.
|
|
|
|
It's cool to be able to write 'arg1 << "stuff" << var ...;' for a lambda
accepting a std::ostream reference, but cascading compile errors mean it's no
longer worth trying to make that work -- given actual C++ lambdas.
Also clean up a lingering BOOST_FOREACH() and a boost::bind() while at it.
|
|
The recommended template uses hyphens; change to underscores to be valid
Python temp module names.
|
|
It seems the problem addressed by aab769e wasn't some synergy between
Boost.Phoenix and Boost.Function, but rather the lack of a Phoenix header file
introducing operator<<().
|
|
|
|
from std::function, since some consumers still use (e.g.)
boost::phoenix::placeholders::arg1 to generate an inline callable.
|
|
On GitHub Windows Actions runners, we're getting permissions errors trying to
tell the Python interpreter to run a NamedTempFile script. Try using
NamedExtTempFile to give each such script a .py extension.
|
|
|
|
do not need 'using' directive, given BOOST_BIND_GLOBAL_PLACEHOLDERS.
|
|
The Python child processes used by llprocess_test.cpp and llleap_test.cpp need
the Python llsd module to communicate with the C++ parent process.
Also set LOGFAIL and BUGSPLAT_DB environment variables.
|
|
|
|
|
|
On a low-powered GitHub Mac runner, the system doesn't wake up as soon as it
should, and we get spurious "too late" errors. Try a bigger time increment.
|
|
|
|
It seems we're no longer implicitly inheriting <array> from some other [set
of] header file[s]. Where we use std::array, bring it in explicitly.
|
|
With VS 2022 on Windows GitHub Actions runners, we can't build apr_suite at
all with the upstream .sln / .vcxproj files, so we had to switch to
"experimental" CMake support. However there's no CMakeLists.txt file for
apr-iconv, so the Windows package omits that library.
|
|
Let the umbrella <regex.hpp> header make that decision.
|
|
This was a longstanding complaint: that Boost shouldn't dump the (somewhat
mysterious) _1, _2 et al. names into the global namespace. Recent Boost has
fixed that, requiring 'using namespace boost::placeholders;' if you want to
use them unqualified.
|
|
The package doesn't include that any more.
|
|
|
|
Update libxml2 to release v2.9.4.7476681.
Update minizip-ng to release v3.0.2.3e9876e.
Update colladadom to release v2.3.d1ef72a.
|
|
Update boost to release v1.81-90bb2df.
Update googlemock to release v1.7.0.77bba00.
|
|
|
|
|
|
Not colladadom: a GHA build of something upstream of it produced Mac link
errors seemingly related to zst.
Not xxhash: 3p-xxhash is a private repo, needing the 'public: false' switch in
its build.yaml.
|
|
following promotion of DRTVWR-577
|
|
Update llphysicsextensions_source to release v1.0.d3192c1.
Update fmodstudio to release v2.02.06.8f8fce1.
Update kdu to release v7.10.4.9e770ae.
Update slvoice to release v4.10.0000.32327.5fc3fe7c.399bd0e.
|
|
Update fmodstudio to release v2.02.06.c0dea14.
Update kdu to release v7.10.4.2dc3b89.
Update slvoice to release v4.10.0000.32327.5fc3fe7c.db0dc68.
|
|
|
|
|
|
|
|
|
|
BUG-233797/233798 - fix blackout when u/w fog_density < 0
|
|
|
|
Newer C++ compilers have different semantics around LLSDArray's special copy
constructor, which was essential to proper LLSD nesting. In short, we can no
longer trust LLSDArray to behave correctly. Now that we have variadic
functions, get rid of LLSDArray and replace every reference with llsd::array().
|
|
It seems newer compilers have a different interpretation of exactly when to
engage LLSDArray's copy constructor. In particular, this assignment:
some_LLSD_map[key] = LLSDArray(...)(...)...;
used to convert the LLSDArray object directly to LLSD; now it first calls the
custom copy constructor, which embeds the intended array within an outer array
before assigning it into the containing map.
The newer llsd::array() function avoids that problem because what it returns
is already an LLSD object.
Taking inventory of LLSDArray assignments of that form turned up a number of
workarounds like LLSD(LLSDArray(...)). Replacing those with llsd::array() is
both simpler and more readable.
Tip of the hat to Chorazinallen for surfacing this issue!
(cherry picked from commit bb718155bddfbe7007029a0c9e69a4a98615f14d)
|
|
|
