| Age | Commit message (Collapse) | Author |
|---|
|
Add a new test<1>() that tests returning values from a Lua chunk using
LLLUAmanager::waitScriptLine(). This exercises lua_tollsd() without yet
involving LLEventPump machinery.
For that purpose, extract from test<2>() the sequence of (description,
expression, LLSD expected) triples into a static C array. The new test<1>()
returns each such expression as a result; test<2>() posts each such expression
to a test LLEventPump.
test<2>() now uses waitScriptLine() instead of pumping the coroutine scheduler
a few times and hoping. The pump-and-hope tactic worked before, but no longer
does. waitScriptLine() is more robust anyway.
Move the former test<1>() to test<3>() because it exercises still more
machinery, specifically listen_events() and await_event(). Because this test
involves a handshake with C++ code, use startScriptLine() to launch the Lua
coroutine while providing a definite way to wait for completion later. Again,
startScriptLine() followed by get() on the returned future is more robust
than the previous pump-and-hope code.
Similarly, the former test<3>(), now renamed test<4>(), uses startScriptLine()
and Future::get() instead of pump-and-hope.
|
|
|
|
If not, the resulting error message is so mysterious that it's worth adding an
error check to explain how to avoid it.
|
|
When lua_tollsd() makes a recursive call, it passes -1 as the index of the
newly-encountered nested table. To traverse the nested table, lua_tollsd()
starts by pushing nil as the initial key. But then calling lua_next(-1) finds
nil -- NOT the nested table!
Converting the index parameter to absolute before pushing nil solves.
|
|
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.
|
|
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>.
|
|
|
|
related SL-18684/SL-19206/SL-19173
|
|
|
|
and for LLViewerControlListener, to which it talks.
Fix glitches detected by the tests.
|
|
|
|
# Conflicts:
# indra/newview/llappviewer.h
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This changeset makes it possible to build the Second Life viewer using
Python 3. It is designed to be used with an equivalent Autobuild branch
so that a developer can compile without needing Python 2 on their
machine.
Breaking change: Python 2 support ending
Rather than supporting two versions of Python, including one that was
discontinued at the beginning of the year, this branch focuses on
pouring future effort into Python 3 only. As a result, scripts do not
need to be backwards compatible. This means that build environments,
be they on personal computers and on build agents, need to have a
compatible interpreter.
Notes
- SLVersionChecker will still use Python 2 on macOS
- Fixed the message template url used by template_verifier.py
|
|
|
|
# Conflicts:
# autobuild.xml
# build.sh
# indra/CMakeLists.txt
# indra/newview/CMakeLists.txt
# indra/newview/llappviewermacosx.cpp
# indra/newview/llappviewerwin32.h
# indra/newview/viewer_manifest.py
# indra/win_crash_logger/llcrashloggerwindows.cpp
|
|
# Conflicts:
# autobuild.xml
# indra/llcommon/llerror.cpp
# indra/llui/llnotifications.h
# indra/newview/llappviewer.cpp
# indra/newview/llappviewermacosx.cpp
|
|
|
|
Since we're going to run the git-hooks validation over the whole repository at
the start of every viewer build, it's important that we start with a clean
pass. Certain text files contained non-ASCII, non-UTF8 characters. We had
already been down the path of identifying and replacing those with ASCII. Pull
in those changes.
|
|
|
|
|
|
|
|
# Conflicts:
# autobuild.xml
# doc/contributions.txt
# indra/llcommon/llcoros.cpp
# indra/llmessage/llcoproceduremanager.cpp
# indra/newview/llfloaterfixedenvironment.cpp
# indra/newview/llfloaterimsessiontab.cpp
|
|
|
|
|
|
|
|
|
|
|
|
verification
|
|
|
|
|
|
|
|
|
|
|
|
This changeset is meant to exemplify how to convert a "namespace" class whose
methods are static -- and whose data are module-static -- to an LLSingleton.
LLVersionInfo has no initClass() or cleanupClass() methods, but the general
idea is the same.
* Derive the class from LLSingleton<T>:
class LLSomeSingleton: public LLSingleton<LLSomeSingleton> { ... };
* Add LLSINGLETON(LLSomeSingleton); in the private section of the class. This
usage implies a separate LLSomeSingleton::LLSomeSingleton() definition, as
described in indra/llcommon/llsingleton.h.
* Move module-scope data in the .cpp file to non-static class members. Change
any sVariableName to mVariableName to avoid being outright misleading.
* Make static class methods non-static. Remove '//static' comments from method
definitions as needed.
* For LLVersionInfo specifically, the 'const std::string&' return type was
replaced with 'std::string'. Returning a reference to a static or a member,
const or otherwise, is an anti-pattern: the interface constrains the
implementation, prohibiting possibly later returning a temporary (an
expression).
* For LLVersionInfo specifically, 'const S32' return type was replaced with
simple 'S32'. 'const' is just noise in that usage.
* Simple member initialization (e.g. the original initializer expressions for
static variables) can be done with member{ value } initializers (no examples
here though).
* Delete initClass() method.
* LLSingleton's forté is of course lazy initialization. It might work to
simply delete any calls to initClass(). But if there are side effects that
must happen at that moment, replace LLSomeSingleton::initClass() with
(void)LLSomeSingleton::instance();
* Most initClass() initialization can be done in the constructor, as would
normally be the case.
* Initialization that might cause a circular LLSingleton reference should be
moved to initSingleton(). Override 'void initSingleton();' should be private.
* For LLVersionInfo specifically, certain initialization that used to be
lazily performed was made unconditional, due to its low cost.
* For LLVersionInfo specifically, certain initialization involved calling
methods that have become non-static. This was moved to initSingleton()
because, in a constructor body, 'this' does not yet point to the enclosing
class.
* Delete cleanupClass() method.
* There is already a generic LLSingletonBase::deleteAll() call in
LLAppViewer::cleanup(). It might work to let this new LLSingleton be cleaned
up with all the rest. But if there are side effects that must happen at that
moment, replace LLSomeSingleton::cleanupClass() with
LLSomeSingleton::deleteSingleton(). That said, much of the benefit of
converting to LLSingleton is deleteAll()'s guarantee that cross-LLSingleton
dependencies will be properly honored: we're trying to migrate the code base
away from the present fragile manual cleanup sequence.
* Most cleanupClass() cleanup can be done in the destructor, as would normally
be the case.
* Cleanup that might throw an exception should be moved to cleanupSingleton().
Override 'void cleanupSingleton();' should be private.
* Within LLSomeSingleton methods, remove any existing
LLSomeSingleton::methodName() qualification: simple methodName() is better.
* In the rest of the code base, convert most LLSomeSingleton::methodName()
references to LLSomeSingleton::instance().methodName(). (Prefer instance() to
getInstance() because a reference does not admit the possibility of NULL.)
* Of course, LLSomeSingleton::ENUM_VALUE can remain unchanged.
In general, for many successive references to an LLSingleton instance, it
can be useful to capture the instance() as in:
auto& versionInfo{LLVersionInfo::instance()};
// ... versionInfo.getVersion() ...
We did not do that here only to simplify the code review.
The STRINGIZE(expression) macro encapsulates:
std::ostringstream out;
out << expression;
return out.str();
We used that in a couple places.
For LLVersionInfo specifically, lllogininstance_test.cpp used to dummy out a
couple specific static methods. It's harder to dummy out
LLSingleton::instance() references, so we add the real class to that test.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Use them in place of awkward try/catch test boilerplate.
|
