| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
It needs a rework
|
|
Honor FLAGS_SERVER_AUTOPILOT and don't locally override assigned agent rotation.
|
|
Communicate menu (#2707)
|
|
for testing purposes
|
|
|
|
Now the lerp() in global namespace is std::lerp(), but it remains true that
for some calls to std::lerp(), MSVC issues fatal argument conversion warnings.
In those places, call flerp() (our historic lerp()) instead.
|
|
|
|
|
|
For reasons that remain unclear, MSVC likes our lerp() function better than
its own std::lerp() function: publishing the latter into the global namespace,
instead of defining our own, produces fatal argument conversion warnings.
"math.h" publishes all of <cmath> into the global namespace, which causes a
GCC conflict between std::lerp() and our lerp() function. Including <cmath>
instead leaves std::lerp() in the std namespace, eliminating the conflict.
|
|
`LLKeyData::operator==(const LLKeyData&)` and `operator!=(const LLKeyData&)`
were not themselves `const` methods. In C++20, that can produce a fatal
warning that if the compare operands were reversed, you'd get different
results. Making them both `const` should fix it.
While touching the method definitions, make `operator==()` more intuitive, and
make `operator!=()` simply negate `operator==()` instead of restating it in
reverse.
|
|
|
|
Hoist `std::lerp()` into the global namespace instead.
|
|
GCC on Linux complains that "math.h", which hoists all the standard library
math functions into the global namespace for classic C compatibility, creates
a conflict between `std::lerp()` and the `lerp()` function in llmath.h.
(Perhaps we should just replace our `lerp()` definition with `using std::lerp;`)
Anyway, bringing in <cmath> rather than "math.h" leaves standard library math
functions in the `std` namespace, avoiding the conflict.
|
|
|
|
LLPreviewGesture adjusted to display more keys
|
|
|
|
|
|
Tweak found in most TPVs, likely originated from Firestorm
|
|
|
|
Fix various issues with snapshot upload fee calculation
|
|
In C++20, `std::filesystem::u8path()` (that accepts a UTF-8 encoded
`std::string` and returns a `std::filesystem::path`) is deprecated. Instead,
to engage UTF-8 coding conversions, we're supposed to pass the `path`
constructor a `std::u8string`, i.e. a `std::basic_string<char8_t>`. Since
`char8_t` is a type distinct from both `char` and `unsigned char`, we must Do
Something to pass a UTF-8 encoded `std::string` into `std::filesystem::path`.
To avoid copying characters from a `std::string` into a temporary
`std::u8string` and from there into the `std::filesystem::path`, make a
`boost::transform_iterator` that accepts a `std::string_view::iterator` and
adapts it to dereference `char8_t` characters. Make `fsyspath(std::string_view)`
engage the base-class constructor accepting (iterator, iterator), adapting
`string_view::begin()` and `end()` to deliver `char8_t` characters.
Use the same tactic for `fsyspath::operator=(std::string_view)`, explicitly
calling `std::filesystem::path::assign()` with the adapted iterators.
To resolve ambiguities, provide both constructors and assignment operators
accepting `(const std::string&)` and `(const char*)`, explicitly converting
each to `std::string_view`.
At the same time, `std::filesystem::path::u8string()` now returns
`std::u8string` rather than `std::string`. Since `std::filesystem::path`
delivers only that `std::u8string` rather than iterators into its internal
representation, we can't avoid capturing it and copying to the returned
`std::string`.
Remove explicit `.u8string()` calls from a few existing `fsyspath` instances,
now that `fsyspath` supports implicit conversion to `std::string`.
|
|
engaged. When flag is set allow sever to update local avatar rotation.
|
|
"Current Window" to determine correct image size and upload cost
|
|
on previously selected snapshot type and not necessarily snapshot to inventory
|
|
image size and display upload cost to user
|
|
|
|
asStringRef is only valid for strings
|
|
history with Ctrl-PgUp/PgDown (#2680)
|
|
|
|
|
|
|
|
|
|
Generalize LLPointer's comparison operators to allow comparable LLPointer types.
|
|
VoiceEffectsWillExpire can be triggered externally. Don't remove the
notification, only viewer's code that triggers it so that external
notification keeps working.
|
|
Given templated constructors and assignment operators, it's tempting to remove
specific constructors and assignment operators with the same LLPointer<Type>
parameters. That turns out to be a mistake. Add comments to warn future
maintainers.
|
|
This affords strong exception safety. Also, eliminating the conditional may
improve speed.
|
|
|
|
|
|
|
|
This reverts commit 5c16ae13758bdfe8fe1f13d5f67eabbb6eaa30a1.
Fix is correct, but should wait untill server sided fix gets deployed.
|
|
|
|
I thought /opt/local/include wasn't needed since we switched to boost181,
but PCRE headers are there. If you still have "boost" installed (maybe
depended on by some other package, just deactivate it first before cmake).
|
|
Add Lua scripts to viewer source tree
|
|
|
|
Instead of restating the whole class, requiring changes to be made in parallel
(which has already failed), just make a template alias.
|
|
That is, both `LLPointer::operator==()` and `operator!=()` and the free function
`operator==()` and `operator!=()` now accept pointer types other than the type
of the subject `LLPointer`, letting the compiler apply implicit pointer
conversions or diagnose an error.
|
