| Age | Commit message (Collapse) | Author |
|---|
|
(cherry picked from commit 7d33e00d925614911a7602da1bd79916cc849ad7)
|
|
Add to apply_test.cpp a collect() function that incrementally accumulates an
arbitrary number of arguments into a std::vector<std::string>. Construct a
std::array<std::string> to pass it, using VAPPLY().
Clarify in header comments that LL::apply() can't call a variadic function
with arguments of dynamic size: std::vector or LLSD. The compiler can deduce
how many arguments to pass to a function with a fixed argument list; it can
deduce how many arguments to pass to a variadic function with a fixed number
of arguments. But it can't compile a call to a variadic function with an
arguments data structure whose size can vary at runtime.
(cherry picked from commit ceed33396266b123896f7cfb9b90abdf240e1eec)
|
|
Make apply(function, std::array) and apply(function, std::vector) available
even when we borrow the C++17 implementation of apply(function, std::tuple).
Add apply(function, LLSD) with interpretations:
* isUndefined() is treated as an empty array, for calling a nullary function
* scalar LLSD is treated as a single-entry array, for calling a unary function
* isArray() converts function parameters using LLSDParam
* isMap() is an error.
Add unit tests for all flavors of LL::apply().
(cherry picked from commit 3006c24251c6259d00df9e0f4f66b8a617e6026d)
|
|
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.
(cherry picked from commit 15d37713b9113a6f70dde48c764df02c76e18cbc)
(cherry picked from commit a1adcf1905d1fbc5fe07ff5a627295ccfe461ac4)
|
|
|
|
SL-19567: Mitigate glow banding
|
|
enabled by default
|
|
post-process buffers. Disabled by default.
|
|
|
|
(#273)
|
|
|
|
Bring over part of the LLEventDispatcher work inspired by DRTVWR-558.
|
|
SL-18837: Remove C++17 override, given build-variables change.
|
|
|
|
Ambiance (HDR) is 0
|
|
|
|
SL-19992: Fix LOD assert
|
|
LLMeshRepository::notifyMeshUnavailable is called on the highest LOD
|
|
|
|
Observed on bugsplat, no repro. Something destroys LLConversationItem without cleaning list (some sessions reuse the item, but they aren't supposed to remove it). Either item should inform floater to be properly removed or should be stored as an LLPointer.
|
|
|
|
Normalize the case of the name of the temp directory for string comparison.
|
|
|
|
Turns out that the pathname of the Python executable wasn't the issue.
This reverts commit 7dc6211ad5ea83685a35c6fff740278343aa8b9d.
|
|
to pick up new APR build that avoids toxic CreateProcessW() flag. It used to
be essential on Windows 7; now it's the cause of our integration test failures.
|
|
|
|
On GitHub Windows runners, trying to make build.yaml set PYTHON=python in the
environment doesn't work: integration tests still fail with "Access is denied"
because they're still trying to execute the interpreter's full pathname.
Instead, make llprocess_test and llleap_test detect the case of GitHub Windows
and override the environment variable PYTHON with a baked-in string constant
"python".
|
|
|
|
|
|
|
|
instead of a new value for each LLProcess::create() invocation.
Since the internal apr_log() function only looks at APR_LOG once per process,
the first test (which succeeded, hence no log file dump) left the log file
open with that same original pathname. Resetting the APR_LOG environment
variable for subsequent runs only made the new code in llprocess_test look for
files that were never created.
|
|
Remove llcommon circular dependency on llfilesystem, which doesn't work for
this case anyway.
|
|
|
|
|
|
|
|
|
|
|
|
Introducing indirection via test_python_script.py did NOT address the "Access
is denied" errors on GitHub Windows runners.
|
|
A New Material created in Inventory should be immediately usable.
|
|
|
|
|
|
|
|
improvements can lead to perceived inventory loss due to cache corruption"
This reverts commit cf692c40b0b9f8d0d04cd10a02a84e3f697a2e99.
|
|
The claim is that the Windows Python interpreter is integrated somehow with
the OS such that a command line that tries to run Python with a script that
"looks suspicious" (i.e. in a system temp directory) fails with "Access
denied" without even loading the interpreter. At least that theory would
explain the "Access denied" errors we've been getting trying to run Python
scripts generated into the system temp directory by our integration tests.
Our hope is that generating such scripts into the GitHub RUNNER_TEMP directory
will work better.
As this test is specific to Windows, don't even bother running Mac builds.
|
|
Having observed installer upload failures, I discovered the warning in
actions/upload-artifact/README.md about multiple concurrent jobs trying to
post the same pathname to the same artifact name. Try to disambiguate
artifacts not only for different platforms, but for different jobs running on
the same platform.
This change also reflects my understanding that an artifact is (effectively) a
distinct zip file that can contain multiple uploaded files. Because we'll want
to download metadata without having to download enormous installers, create a
separate metadata artifact per platform. Similarly, symbol files can get large:
use a third distinct artifact for symbol files.
But with those artifacts defined, leverage actions/upload-artifact's ability
to upload multiple paths to the same artifact. In build.sh, define bash arrays
installer, metadata, symbolfile and set up so that, on exit, each is written
to a GITHUB_OUTPUT variable with the corresponding name. This involves a
little magic to get macOS bash 3 to indirectly access an array.
These multi-line output variables are then used to drive the upload-artifact
step for each of the defined artifacts.
|
|
|
|
|
|
and use them instead of codeticket addoutput to pass GitHub xxx_name, xxx_path
outputs to build.yaml.
Add upload steps to build.yaml to try to upload build products identified in
build.sh.
|
|
|
|
|
