| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
Use LLSDParam<uuid_vec_t> in LLAppearanceListener::wearItems() and
detachItems() to build the vector of LLUUIDs from the passed LLSD array.
|
|
|
|
|
|
into new private wearOutfit(LLInventoryCategory*) method.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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, make fiber.lua call LL.atexit(fiber.run) to schedule that final run()
call at ~LuaState() time using the generic mechanism.
Append an explicit fiber.run() call to a specific test in llluamanager_test.cpp
because the test code wants to interact with multiple Lua fibers *before* we
destroy the LuaState.
|
|
|
|
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().
|
