| Age | Commit message (Collapse) | Author |
|---|
|
The header file documents that no llrand function should ever return a value
equal to the passed extent, so the one test in llrand_test.cpp that checked
less than or equal to the high end of the range was anomalous.
But changing that to an exclusive range means that we no longer need separate
exclusive range and inclusive range functions. Replace
ensure_in_range_using(), ensure_in_exc_range() and ensure_in_inc_range() with
a grand unified (simplified) ensure_in_range() function.
|
|
|
|
It's frustrating and unactionable to have a failing test report merely that
the random value was greater than the specified high end. Okay, so what was
the value? If it's supposed to be less than the high end, did it happen to be
equal? Or was it garbage? We can't reproduce the failure by rerunning!
The new ensure_in_exc_range(), ensure_in_inc_range() mechanism is somewhat
complex because exactly one test allows equality with the high end of the
expected range, where the rest mandate that the function return less than the
high end. If that's a bug in the test -- if every llrand function is supposed
to return less than the high end -- then we could simplify the test logic.
|
|
Add from_lua() function to run a small Lua script that constructs a specified
Lua object and posts it back to the test program via a temporary LLEventPump.
Call this with a variety of Lua objects, comparing to the expected LLSD.
Add round_trip() function to run another small Lua script that listens for
incoming LLEventPump events and, for each, posts the received Lua data back to
the test program as LLSD. Call this with a variety of LLSD objects, comparing
to the expected LLSD. Also collect these objects into an LLSD array and send
that for a round trip; also collect into an LLSD map and send that.
Sadly, tests currently drive an access violation when trying to convert a
nested Lua table to LLSD.
Add verbose debug logging to lua_tollsd() to identify the context at which we
hit the access violation.
Add comments describing further exceptions to LLSD-to-Lua round trip identity.
Add lua_what() iostream manipulator to stream whatever we can readily
discover about a value at a specified Lua stack index.
Add lua_stack() to report the contents of the Lua stack. Since the stack is
created anew for every call to a C function, this shouldn't usually be
enormous.
Add hexdump.h with iostream manipulators to dump a byte range as hex digits,
or to produce readable text from a mix of printing and nonprinting ASCII
characters.
|
|
|
|
looks like pool regularly gets corrupted, try using separate pool
|
|
|
|
# Conflicts:
# indra/newview/llinventorymodel.cpp
# indra/newview/llvovolume.cpp
|
|
# Conflicts:
# indra/newview/CMakeLists.txt
# indra/newview/VIEWER_VERSION.txt
# indra/newview/llagent.cpp
# indra/newview/llfloaternewfeaturenotification.cpp
# indra/newview/llinventorybridge.cpp
# indra/newview/llinventorymodel.cpp
# indra/newview/lloutfitgallery.cpp
# indra/newview/llpanelmaininventory.cpp
# indra/newview/llpanelmaininventory.h
# indra/newview/llsidepaneltaskinfo.cpp
# indra/newview/llsidepaneltaskinfo.h
# indra/newview/lltexturectrl.cpp
# indra/newview/lltexturectrl.h
# indra/newview/llviewerinventory.cpp
# indra/newview/llviewerobject.cpp
# indra/newview/llviewertexturelist.cpp
# indra/newview/llviewertexturelist.h
# indra/newview/skins/default/xui/en/floater_new_feature_notification.xml
# indra/newview/skins/default/xui/en/menu_inventory.xml
|
|
The first test runs a Lua script that calls post_on(), listen_events() and
await_event() to engage in LLEventPump handshakes with the test program.
Make llluamanager.cpp testable by putting LL_TEST conditionals around lots of
viewer-internals headers and the lua_function definitions that engage them.
Since LuaListener::connect() is called by its constructor, make it a static
method that explicitly accepts the lua_State* (instead of finding it as
mState). Add that parameter to its two existing calls.
Add a debug log message when LuaListener is destroyed. This surfaced the need
to pass a no-op deleter when listen_events() constructs a LuaListener::ptr_t.
When compiled for LL_TEST, make LuaListener::mReplyPump an
LLEventLogProxyFor<LLEventStream> instead of a plain LLEventStream.
For debugging purposes, add a type string "LLEventLogProxy" for
LLEventPumps::make(). A make() call with this type will return an
LLEventLogProxyFor<LLEventStream>.
|
|
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.
(cherry picked from commit 045342ba29aae186e13c711bd4dd84377d4a7e43)
|
|
Use whole seconds rather than tenths of seconds, since apparently the TeamCity
agent machine is having trouble waking up within tenths of seconds.
|
|
Move hexdump() and hexmix() stream formatters to new hexdump.h for potential
use by other tests.
In toPythonUsing() helper function, add a temp file to receive Python script
debug output, and direct debug output to that file. On test failure, dump the
contents of that file to the log.
Give NamedTempFile::peep() an optional target std::ostream; refactor
implementation as peep_via() that accepts a callable to process each text
line. Add operator<<() to stream the contents of a NamedTempFile object to
ostream -- but don't use that with LL_DEBUGS(), as it flattens the file
contents into a single log line. Instead add peep_log(), which streams each
individual text line to LL_DEBUGS().
|
|
|
|
|
|
|
|
|
|
A test executable on a GitHub Windows runner failed with C00000FD, which
reports stack overflow.
(cherry picked from commit aab7b4ba3812e5876b1205285bcfd8cff96bcac9)
|
|
Add DEBUG log output to try to diagnose.
|
|
# Conflicts:
# indra/llcommon/llsdserialize.cpp
# indra/llcommon/llsdserialize.h
# indra/llmath/llvolume.cpp
# indra/llrender/llgl.cpp
# indra/llxml/llcontrol.cpp
# indra/newview/llpanelnearbymedia.cpp
# indra/newview/llsceneview.cpp
# indra/newview/llselectmgr.cpp
# indra/newview/llstartup.cpp
# indra/newview/lltextureview.cpp
# indra/newview/llvovolume.cpp
# indra/newview/skins/default/xui/en/menu_viewer.xml
|
|
# Conflicts:
# indra/newview/app_settings/settings.xml
# indra/newview/llinventoryfunctions.cpp
# indra/newview/llinventoryfunctions.h
# indra/newview/llinventorymodel.cpp
# indra/newview/llinventoryobserver.cpp
# indra/newview/llinventoryobserver.h
# indra/newview/skins/default/xui/ja/floater_inventory_item_properties.xml
|
|
# Conflicts:
# autobuild.xml
|
|
|
|
For unknown reason allocations of these coroutines often crash on client machines.
1. Limit quantity of coros running in parallel by reducing retries and wait time
2. Print out more diagnostic info
|
|
that unconditionally return. This eliminates the problem of pacifying a
compiler that expects a return statement vs. a compiler that detects that
callFail() unconditionally throws.
Thanks, Ansariel.
|
|
|
|
LLSDParam<LLSD> is the generic case, when we need to pass LLSDParam adapters
to some set of function parameters whose types we don't specifically know. Its
templated conversion operator notices the actual parameter type T and
delegates conversion to the specific LLSDParam<T> specialization.
But when T has picked up references, e.g. somewhere along the way in the
LL::apply() machinery, the compiler might not choose the desired conversion
because we don't have a sufficiently specific LLSDParam specialization.
LLSDParam<LLSD> can address that by using std::decay_t<T> when delegating to
the specific LLSDParam specialization. This removes references, const and
volatile.
|
|
There's a limit to how much time it's worth trying to work around a compiler
bug that's already been fixed in newer Xcode.
|
|
|
|
|
|
That wasn't the issue. This is a compiler bug:
https://github.com/llvm/llvm-project/issues/41999
https://stackoverflow.com/q/57080425
https://bugs.llvm.org/show_bug.cgi?id=42654
This reverts commit c406fa7ae97441d1d6e0ea6727c42c8f978fabed.
|
|
|
|
Both the previous version and this compile and run successfully with Xcode
14.3.1, but our older TeamCity compiler chokes -- so we must iterate remotely,
sigh.
|
|
VC doesn't recognize that a constexpr name doesn't need to be bound into a
lambda. However, since it's knowable at compile time, it can be deduced within
the innermost lambda.
(cherry picked from commit 37c3daff1a565eaafee691dfb57702b6b8f024d6)
|
|
|
|
|
|
|
|
|
|
Major improvements to LLLeap functionality
|
|
LL_USE_SYSTEM_RAND has been disabled since June 2008; that code only clutters
the implementation we actually use.
|
|
|
|
|
|
# Conflicts:
# indra/llui/llfolderviewitem.cpp
# indra/newview/llinventorymodel.cpp
# indra/newview/llinventorymodelbackgroundfetch.cpp
|
|
|
|
# Conflicts:
# doc/contributions.txt
# indra/llcommon/llerrorthread.cpp
|
|
|
|
Once std::apply() becomes available, 'using std::apply;' isn't correct because
the more general template tries to handle the apply(function, vector) case
that we explicitly implement below. Have to provide apply(function, tuple) and
apply(function, array) signatures that can forward to std::apply().
|
|
|
|
(cherry picked from commit 2c1253c8ed2a1648317e6edd768b3fda00c56ce2)
|
|
addMethod() was using dynamic_cast<target class*>(this) and testing for
nullptr to decide whether the class owning the passed method is, or is not, a
subclass of LLEventDispatcher. The trouble is that it doesn't work for the
deferred add() calls queued by LazyEventAPI: the dynamic_cast was always
returning nullptr. static_cast works better, but that leaves us with the
problem we were trying to solve with dynamic_cast: what if the target class
really isn't a subclass? Use std::is_base_of to pick which of two addMethod()
overloads to invoke, one of which calls addFail().
(cherry picked from commit a4d520aa5d023d80cfeec4f40c3464b54cbcfc5b)
|
