| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
Passing std::string::c_str() to a (const std::string&) function parameter is
worse than clutter, it's pointless overhead: it forces the compiler to
construct a new std::string instance, instead of passing a const reference to
the one you already have in hand.
|
|
Remove LL_TEST special case from require() code (to search in the viewer's
source tree). Instead, make llluamanager_test.cpp append to LuaRequirePath to
get the same effect.
|
|
|
|
|
|
outfit items
|
|
Remove AutorunLuaScriptFile and the LLLUAmanager::runScriptOnLogin() method
that checked it.
Instead, iterate over LuaAutorunPath directories at viewer startup, iterate
over *.lua files in each and implicitly run those.
LuaCommandPath and LuaRequirePath are not yet implemented.
|
|
This replaces type_tag<T>(), which searched and possibly extended the type_tags
unordered_map at runtime. If we called lua_emplace<T>() from different threads,
that would require locking type_tags.
In contrast, the compiler must instantiate a distinct TypeTag<T> for every
distinct T passed to lua_emplace<T>(), so each gets a distinct value at static
initialization time. No locking is required; no lookup; no allocations.
Add a test to llluamanager_test.cpp to verify that each distinct T passed to
lua_emplace<T>() gets its own TypeTag<T>::value, and that each gets its own
destructor -- but that different lua_emplace<T>() calls with the same T share
the same TypeTag<T>::value and the same destructor.
|
|
|
|
|
|
|
|
|
|
|
|
Add "userQuit" operation to LLAppViewerListener to engage
LLAppViewer::userQuit(), which pops up "Are you sure?" prompt unless
suppressed.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Use ClassName(ctor args) for classes using util.classctor().
|
|
|
|
|
|
|
|
popup:tip() engages 'SystemMessageTip'.
|
|
|
|
|
|
|
|
|
|
Instead of deriving LuaListener from LLInstanceTracker with an int key,
generating a unique int key and storing that key in the Registry, use new
lua_emplace<LuaState>() to store the LuaListener directly in a Lua userdata
object in the Lua Registry.
Because lua_emplace<T>() uses LL.atexit() to guarantee that ~LuaState will
destroy the T object, we no longer need ~LuaState() to make a special call
specifically to destroy the LuaListener, if any. So we no longer need
LuaState::getListener() separate from obtainListener().
Since LuaListener is no longer an LLInstanceTracker subclass, make
LuaState::obtainListener() return LuaListener& rather than LuaListener::ptr_t.
|
|
Make viewer_manifest.py copy them into the viewer install image.
Make the require() function look for them there.
|
|
|
|
|
|
When the user explicitly types 'return expression[, expression]...' we convert
the result of the expressions to LLSD and format them into the LUA Debug
Console, which serves as a useful acknowledgment.
But until now, if the user neither invoked print() nor ran a 'return'
statement, the LUA Debug Console output remained empty. This could be a little
disconcerting: you click Execute, or press Enter, and apparently nothing
happens. You must either monitor viewer log output, or simply trust that the
Lua snippet ran.
When there are no 'return' results, at least emit 'ok'. But when the user is
entering a series of no-output commands, vary the 'ok' output by appending a
counter: 'ok 1', 'ok 2' etc.
|
|
The special case of a Lua snippet that indirectly invokes the
"LLNotifications" listener can result in a recursive call to
LLFloaterLUADebug's handler methods. Defend against that case.
|
|
stringize() constructs, populates and destroys a std::ostringstream, which is
actually less efficient than directly allocating a std::string big enough for
the result of operator+().
Maybe someday we'll specialize stringize(p0, p1) for the case in which they're
both string-like, and invoke operator+() for that situation...
|
|
The expression (payload or {}) is unnecessary, since that value will be
converted to LLSD -- and both Lua nil and empty table convert to
LLSD::isUndefined().
|
|
|
|
WIP: This is known not to work yet.
|
|
The nullary login() call (login with saved credentials) has been tested, but
the binary login(username, password) call is known not to work yet.
|
|
Add listviews(), viewinfo(), click(), doubleclick(), drag(), keypress() and
type().
WIP: These are ported from Python LEAP equivalents, but the Lua implementation
has only been partially tested.
|
|
The 'startup' table, the module's namespace, must be defined near the top
because its local waitfor:process() override references startup.
The byname table's metatable's __index() function wants to raise an error if
you try to access an undefined entry, but it referenced t[k] to check that,
producing infinite recursion. Use rawget(t, k) instead.
Also use new leap.WaitFor(args) syntax instead of leap.WaitFor:new(args).
|
|
The discussions we've read about Lua classes conventionally use
ClassName:new() as the constructor, and so far we've followed that convention.
But setting metaclass(ClassName).__call = ClassName.new permits Lua to respond
to calls of the form ClassName(ctor args) by implicitly calling
ClassName:new(ctor args).
Introduce util.classctor(). Calling util.classctor(ClassName) sets ClassName's
metaclass's __call to ClassName's constructor method. If the constructor method
is named something other than new(), pass ClassName.method as the second arg.
Use util.classctor() on each of our classes that defines a new() method.
Replace ClassName:new(args) calls with ClassName(args) calls throughout.
|
|
in addition to a list {'name1', 'name2', ...}.
|
|
|
|
|
|
|
|
to pick up Featurettes promotion + Brad's GitHub Windows build workaround.
|
|
|
