| Age | Commit message (Collapse) | Author |
|---|
|
merge main into contribute
|
|
|
|
# Conflicts:
# indra/cmake/CMakeLists.txt
# indra/llcommon/llsdserialize.cpp
# indra/llcommon/llsdserialize.h
# indra/llcommon/tests/llleap_test.cpp
# indra/newview/llfilepicker.h
# indra/newview/llfilepicker_mac.h
# indra/newview/llfilepicker_mac.mm
# indra/newview/skins/default/xui/en/strings.xml
|
|
SL-19541: Add basic coding standards check
|
|
Run Linden coding standard git-hooks in a basic Github actions workflow.
|
|
following promotion of DRTVWR-573
|
|
|
|
|
|
to make it accessible after updating the viewer
|
|
|
|
|
|
# Conflicts:
# indra/cmake/Copy3rdPartyLibs.cmake
# indra/cmake/FindOpenJPEG.cmake
# indra/cmake/OpenJPEG.cmake
# indra/integration_tests/llui_libtest/CMakeLists.txt
# indra/newview/CMakeLists.txt
|
|
The viewer currently presents a startling "Grid emergency" warning if an
unrecognized error is returned from login. Let's tone this down a bit
and present the error as it is: an unrecognized login failure rather
than SLearth exploding.
|
|
|
|
SL-18330: Address further code review comments
|
|
per Leviathan code review.
|
|
added missing app setting
|
|
|
|
|
|
instead of having specific binary, ternary and quaternary overloads.
|
|
The num_periods arguments have all been changed to size_t, but the default
argument values were still coded as S32_MAX. Change to
std::numeric_limits<size_t>::max().
|
|
Not only do the local typedefs make the code less readable, they also rely on
assumptions about the implementation. The standard types are guaranteed by the
C++ library implementation.
|
|
SL-18330: Send binary LLSD to LEAP plugins; extend LLSD compatibility.
|
|
Reduce stale time for PRs
|
|
|
|
|
|
|
|
|
|
|
|
translations (#80)
|
|
Feature described at https://community.secondlife.com/blogs/entry/12652-coming-soon-to-a-viewer-near-you-group-chat-history/
|
|
|
|
changes in /en/ (#78)
|
|
As it happens, the change in the LLUUID::combine() algorithm introduced by one
of my previous commits is causing invalid assets creation (seen with
some clothing items, such as Shape and Universal types); obviously, the server
is using the old algorithm for UUID validation purpose of these assets.
This commit reverts LLUUID::combine() code to use LLMD5.
|
|
Let's reduce the stale time from 60 days to 30. We already have at least two multi-month PRs.
|
|
|
|
|
|
Faster and simpler inventory category hashing.
|
|
As suggested in comments for previous commit.
|
|
keys (#70)
LLUUID and LLMaterialID already have an excellent entropy and value dispersion; there is therefore strictly no need to further (slowly) hash their value for use with std and boost libraries containers.
This commit adds a trivial getDigest64() method to both LLUUID and LLMaterialID (which simply returns the XOR of the two 64 bits long words their value is made of), and uses it in std::hash and hash_value() specializations for use with containers.
|
|
These classes are not trivially copyable because of the mState pointer on an internal
XXH3 state that would have to be explicitely copied.
While it would be possible to add custom copy constructor and operator for them, it
does not really make sense to allow copying an instance of these classes, since all we
care about storing and copying is the digest (which is either an U64 or an LLUUID).
|
|
This commit changes inventory category hashing from slow LLMD5 to fast HBXX128 hashing, and allows to use a simple LLUUID for the hash, instead of an LLMD5 instance.
It also removes some old cruft dealing with unused baked texture hashing.
|
|
The viewer currently presents a startling "Grid emergency" warning if an
unrecognized error is returned from login. Let's tone this down a bit
and present the error as it is: an unrecognized login failure rather
than SLearth exploding.
|
|
|
|
following promotion of DRTVWR-570
|
|
|
|
|
|
speed matters. (#64)
This commit adds the HBXX64 and HBXX128 classes for use as a drop-in
replacement for the slow LLMD5 hashing class, where speed matters and
backward compatibility (with standard hashing algorithms) and/or
cryptographic hashing qualities are not required.
It also replaces LLMD5 with HBXX* in a few existing hot (well, ok, just
"warm" for some) paths meeting the above requirements, while paving the way for
future use cases, such as in the DRTVWR-559 and sibling branches where the slow
LLMD5 is used (e.g. to hash materials and vertex buffer cache entries), and
could be use such a (way) faster algorithm with very significant benefits and
no negative impact.
Here is the comment I added in indra/llcommon/hbxx.h:
// HBXXH* classes are to be used where speed matters and cryptographic quality
// is not required (no "one-way" guarantee, though they are likely not worst in
// this respect than MD5 which got busted and is now considered too weak). The
// xxHash code they are built upon is vectorized and about 50 times faster than
// MD5. A 64 bits hash class is also provided for when 128 bits of entropy are
// not needed. The hashes collision rate is similar to MD5's.
// See https://github.com/Cyan4973/xxHash#readme for details.
|
|
Should be fixed by SL-18996, but just in case user decides to select a model while viewer closes
|
|
This reverts commit 4d429b7ea31f51f653e0e2ad6b5799a515e28334.
|
