| Age | Commit message (Collapse) | Author |
|---|
|
When sending multiple LEAP packets in the same file (for testing convenience),
use a length prefix instead of delimiting with '\n'. Now that we allow a
serialization format that includes an LLSD format header (e.g.
"<?llsd/binary?>"), '\n' is part of the packet content. But in fact, testing
binary LLSD means we can't pick any delimiter guaranteed not to appear in the
packet content.
Using a length prefix also lets us pass a specific max_bytes to the subject
C++ LLSD parser.
Make llleap_test.cpp use new freestanding Python llsd package when available.
Update Python-side LEAP protocol code to work directly with encoded bytes
stream, avoiding bytes<->str encoding and decoding, which breaks binary LLSD.
Make LLSDSerialize::deserialize() recognize LLSD format header case-
insensitively. Python emits and checks for "llsd/binary", while LLSDSerialize
emits and checks for "LLSD/Binary". Once any of the headers is recognized,
pass corrected max_bytes to the specific parser.
Make deserialize() more careful about the no-header case: preserve '\n' in
content. Introduce debugging code (disabled) because it's a little tricky to
recreate.
Revert LLLeap child process stdout parser from LLSDSerialize::deserialize() to
the specific LLSDNotationParser(), as at present: the generic parser fails one
of LLLeap's integration tests for reasons that remain mysterious.
|
|
Since parsing binary LLSD is faster than parsing notation LLSD, send data from
the viewer to the LEAP plugin child process's stdin in binary instead of
notation.
Similarly, instead of parsing the child process's stdout using specifically a
notation parser, use the generic LLSDSerialize::deserialize() LLSD parser.
Add more LLSDSerialize Python compatibility tests.
|
|
Absent a header from LLSDSerialize::serialize(), make deserialize()
distinguish between XML or notation by recognizing an initial '<'.
|
|
LLSDSerialize::serialize() emits a header string, e.g. "<? llsd/notation ?>"
for notation format. Until now, LLSDSerialize::deserialize() has required that
header to properly decode the input stream.
But none of LLSDBinaryFormatter, LLSDXMLFormatter or LLSDNotationFormatter
emit that header themselves. Nor do any of the Python llsd.format_binary(),
format_xml() or format_notation() functions. Until now, you could not use
LLSD::deserialize() to parse an arbitrary-format LLSD stream serialized by
anything but LLSDSerialize::serialize().
Change LLSDSerialize::deserialize() so that if no header is recognized,
instead of failing, it attempts to parse as notation. Add tests to exercise
this case.
The tricky part about this processing is that deserialize() necessarily reads
some number of bytes from the input stream first, to try to recognize the
header. If it fails to do so, it must prepend the bytes it has already read to
the rest of the input stream since they're probably the beginning of the
serialized data.
To support this use case, introduce cat_streambuf, a std::streambuf subclass
that (virtually) concatenates other std::streambuf instances. When read by a
std::istream, the sequence of underlying std::streambufs appears to the
consumer as a single continuous stream.
|
|
|
|
|
|
|
|
Introduce LLSD template constructors and assignment operators to disambiguate
construction or assignment from any integer type to Integer, likewise any
floating point type to Real. Use new narrow() function to validate
conversions.
For LLSD method parameters converted from LLSD::Integer to size_t, where the
method previously checked for a negative argument, make it now check for
size_t converted from negative: in other words, more than S32_MAX. The risk of
having a parameter forced from negative to unsigned exceeds the risk of a
valid length or index over that max.
In lltracerecording.cpp's PeriodicRecording, now that mCurPeriod and
mNumRecordedPeriods are size_t instead of S32, defend against subtracting 1
from 0.
Use narrow() to validate newly-introduced narrowing conversions.
Make llclamp() return the type of the raw input value, even if the types of
the boundary values differ.
std::ostream::tellp() no longer returns a value we can directly report as a
number. Cast to U64.
|
|
|
|
size_t conversions
|
|
conversions
|
|
|
|
|
|
llssize is for a function parameter that should accept a size or index
(derived from size_t, which is 64 bits in a 64-bit viewer) but might need to
go negative for flag values. We've historically used S32 for that purpose, but
Xcode 14.1 complains about trying to pass size_t to S32.
narrow() is a template function that casts a wider type (e.g. size_t or
llssize) to a narrower type (e.g. S32 or U32), with validation in
RelWithDebInfo builds. It verifies (using assert()) that the value being
truncated can in fact fit into the target type.
|
|
|
|
It's a little distressing how often we have historically coded S32 or U32 to
pass a length or index.
There are more such assumptions in other viewer subdirectories, but this is a
start.
|
|
DRTVWR-570-maint-Q
|
|
creating an empty LLSDMap type.
|
|
|
|
|
|
|
|
In theory it is fine to do that, in practice it does break gatekeeper in subtle ways
due to https://developer.apple.com/library/archive/technotes/tn2206/_index.html#//apple_ref/doc/uid/DTS40007919-CH1-TNTAG207
Having bugsplat linked to all executables results in executables with an embedded rpath that is invalid for Gatekeeper. Luckily
it shows this is in the worst possible way. The viewer cannot be started with a non helpful message of teh viewer being unable to
verified. While at the same time spctl and codesign both show no errors at all.
|
|
# Conflicts:
# indra/newview/llfloaterpreference.cpp
# indra/newview/llviewercontrol.cpp
|
|
# Conflicts:
# indra/newview/llnetmap.cpp
# indra/newview/llnetmap.h
|
|
|
|
This partially reverts commit 935c1362a222f192bf913270d01f6c31c16e175b.
Reporting seems to have stoped working, trying the same way mac works.
|
|
|
|
|
|
|
|
|
|
DRTVWR-568_cmake
|
|
|
|
|
|
# Conflicts:
# indra/newview/llmodelpreview.h
|
|
|
|
|
|
|
|
|
|
Always search for python3[.exe] instead of plain 'python'. macOS Monterey no
longer bundles Python 2 at all.
Explicitly make PYTHON_EXECUTABLE a cached value so if the user edits it in
CMakeCache.txt, it won't be overwritten by indra/cmake/Python.cmake.
Do NOT set DYLD_LIBRARY_PATH for test executables! That has Bad Effects, as
discussed in https://stackoverflow.com/q/73418423/5533635. Instead, create
symlinks from build-mumble/sharedlibs/Resources -> Release/Resources and from
build-mumble/test/Resources -> ../sharedlibs/Release/Resources. For test
executables in sharedlibs/RelWithDebInfo and test/RelWithDebInfo, this
supports our dylibs' baked-in load path @executable_path/../Resources. That
load path assumes running in a standard app bundle (which the viewer in fact
does), but we've been avoiding creating an app bundle for every test program.
These symlinks allow us to continue doing that while avoiding
DYLD_LIBRARY_PATH.
Add indra/llcommon/apply.h. The LL::apply() function and its wrapper macro
VAPPLY were very useful in diagnosing the problem.
Tweak llleap_test.cpp. This source was modified extensively for diagnostic
purposes; these are the small improvements that remain.
|
|
This anticipates C++17's std::apply(), and in fact once we detect C++17, we'll
just use that. But in C++14 we must still provide our own implementation.
(cherry picked from commit dc2e2cd76f387ea6e80787fb94adcbc269cd1f25)
|
|
|
|
According to bugsplat get_thread_recorder was null
Replaced apr based LLThreadLocalPointer with thread_local
|
|
elision [-Werror=pessimizing-move]
|
|
|
|
# Conflicts:
# doc/contributions.txt
# indra/newview/llviewercontrol.cpp
|
|
|
|
|
|
The work queue callback binds "this". This is deemed safe due to current dependencies, but see the associated comment in the return callback. There was some trial and error to get a this-binded lambda to compile.
Due to LLVorbisDecodeState writing to disk off-thread, limit audio decodes proportional to general worker thread count. Guess the thread count for now.
|
|
(cherry picked from commit 41d6a0e222241606c317281e2f0b211e16813dd5)
|
|
DRTVWR-543-maint_cmake
|
