| Age | Commit message (Collapse) | Author |
|---|
|
This is an unusual use case in which lua_tollsd() is called by C++ code
without the Lua runtime farther up the call stack.
|
|
|
|
Under debug LL_ERRS will show a message as well, but release won't show
anything and will quit silently so show a notification when applicable.
|
|
correct erms..."
This reverts commit 60debe828b87c33fdbd33e3a5fcef423e544fe55.
|
|
|
|
|
|
|
|
# Conflicts:
# indra/newview/llinventorygallery.cpp
|
|
|
|
following promotion of secondlife/viewer #673
|
|
|
|
|
|
|
|
The code to save the loaded module was using the wrong key.
|
|
|
|
Push throwing Lua errors down into LLRequireResolver::findModule() and
findModuleImpl() so their callers don't have to handle the error case. That
eliminates finishrequire().
require() itself now only retrieves (and pops) the passed module name and
calls LLRequireResolver::resolveRequire() to do the actual work.
resolveRequire() is now void. It only instantiates LLRequireResolver and calls
its findModule().
findModule() is now also void. It's guaranteed to either push the loaded Lua
module or throw a Lua error. In particular, when findPathImpl() cannot find
the specified module, findModule() throws an error. That replaces
ModuleStatus::NotFound.
Since std::filesystem::path::append() aka operator/() detects when its right
operand is absolute and, in that case, discards the left operand, we no longer
need resolveAndStoreDefaultPaths(): we can just invoke that operation inline.
When findModule() pushes _MODULES on the Lua stack, it uses LuaRemover (below)
to ensure that _MODULES is removed again no matter how findModules() exits.
findModuleImpl() now accepts the candidate pathname as its argument. That
eliminates mAbsolutePath.
findModuleImpl() now returns only bool: true means the module was found and
loaded and pushed on the Lua stack, false means not found and nothing was
pushed; no return means an error was reported.
Push running a newly found module's source file down into findModuleImpl().
That eliminates the distinction between Cached and FileRead, which obviates
ModuleStatus: a bool return means either "previously cached" or "we read it,
compiled it, loaded it and ran it." That also eliminates the need to store the
module's textual content in mSourceCode.
Similarly, once loading the module succeeds, findModuleImpl() caches it in
_MODULES right away. That eliminates ResolvedRequire since we need not pass
the full pathname of the found module (or its contents) back up through the
call chain.
Move require() code that runs the new module into private runModule() method,
called by findModuleImpl() in the not-cached case. runModule() is the only
remaining method that can push either a string error message or the desired
module, because of its funny stack manipulations. That means the check for a
string error message on the stack top can move down to findModuleImpl().
Add LuaRemover class to ensure that on exit from some particular C++ block,
the specified Lua stack entry will definitely be removed. This is different
from LuaPopper in that it engages lua_remove() rather than lua_pop().
Also ditch obsolete await_event() Lua entry point.
|
|
Disable copy assignment operator as well as copy constructor.
Use std::uncaught_exceptions() in destructor to report whether there's an
in-flight exception at block exit. Since that was the whole point of the
DEBUGIN / DEBUGEND macros, those become obsolete. Ditch them and their
existing invocations.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Note that crash happened when setting LLProgressView::setMessage
|
|
debug.h #defines a couple of macros intended to enclose the entire body of a
function to track its entry and (possibly exceptional) exit. The trouble is
that these macros used to be called BEGIN and END, which is far too generic --
especially considering that END is used as an enum value in some parts of the
viewer.
Rename them DEBUGIN and DEBUGEND, which is ugly but unlikely to collide with
anything else.
|
|
Since print() writes to cerr, we used to be able to use it only in test
programs. Making the cerr writes conditional on LL_TEST allows us to use it
for debugging the code under test as well, since in the normal viewer the
cerr statements vanish.
|
|
All Debug constructor args are concatenated using stringize().
|
|
|
|
|
|
|
|
Remove where it isn't.
|
|
Don't set up a Lua callback to receive incoming events, a la listen_events().
Don't listen on an arbitrary event pump, a la await_event().
Instead, the new get_event_pumps() entry point simply delivers the reply pump
and command pump names (as listen_events() did) without storing a Lua
callback.
Make LuaListener capture incoming events on the reply pump in a queue. This
avoids the problem of multiple events arriving too quickly for the Lua script
to retrieve. If the queue gets too big, discard the excess instead of blocking
the caller of post().
Then the new get_event_next() entry point retrieves the next (pump, data) pair
from the queue, blocking the Lua script until a suitable event arrives. This
is closer to the use of stdin for a LEAP plugin. It also addresses the
question: what should the Lua script's C++ coroutine do while waiting for an
incoming reply pump event?
Recast llluamanager_test.cpp for this new, more straightforward API.
Move LLLeap's and LuaListener's reply LLEventPump into LLLeapListener, which
they both use. This simplifies LLLeapListener's API, which was a little
convoluted: the caller supplied a connect callback to allow LLLeapListener to
connect some listener to the caller's reply pump. Now, instead, the caller
simply passes a bool(pumpname, data) callback to receive events incoming on
LLLeapListener's own reply pump.
Fix a latent bug in LLLeapListener: if a plugin called listen() more than once
with the same listener name, the new connection would not have been saved.
While at it, replace some older Boost features in LLLeapListener and LLLeap.
|
|
If post() can't find the requested pump, say so.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
leaphelp() (no argument) shows a list of all LEAP APIs.
leaphelp(API) shows further help for a specific API.
Both forms query LuaListener's LeapListener and report its responses. In
future we might reimplement leaphelp() as a Lua function.
Add LuaState::getListener() method, which checks whether there's a LuaListener
associated with this LuaState and returns a pointer if so.
Add LuaState::obtainListener() method, which finds or creates a LuaListener
for this LuaState and returns its pointer.
Both the above use logic migrated from the Lua listen_events() entry point,
which now calls obtainListener() instead.
|
|
|
|
help() with no argument lists all our viewer builtins.
help(function, function, ...) shows help text for each named function. Each
argument can be either a string or the function in question (e.g. help(help)).
To support Lua-related text containing line breaks, make LLTextEditor::
pasteTextWithLinebreaks() a public template method. Change the existing
implementation, which specifically accepts (const LLWString&), into its
LLWString specialization. The generic template passes llconvert(arg) to that
specialization, the one real implementation.
Make LLFloaterLUADebug methods call pasteTextWithLinebreaks() instead of
insertText(), which ignores newline characters.
To allow help() to accept an actual function as well as a string name, add a
lookup-by-function-pointer map to LuaFunction. (A Lua function does not store
a name.) Make the constructor store an entry in the new lookup map as well as
in the original registry map.
Change LuaFunction::getRegistry() and getRegistered() to getState() and
getRState(), respectively. Each returns a std::pair, but the first binds
non-const references while the second binds const references.
|
|
|
|
As a function parameter, an assignment expression or a `return` expression,
`ll_convert()` can infer its target type.
When it's important to specify the TOTYPE explicitly, rename the old
`ll_convert()` function template to `ll_convert_to()`. Fix existing usage.
|
|
|
|
|
|
|
|
--lua "chunk" runs the specified Lua chunk at startup time.
--luafile pathname runs the specified Lua script file at startup time.
You may specify more than one --lua or --luafile switch on the command line.
|
|
Since the description shows up in the log output, it's better to see just the
script filename than to see "runScriptFile('filename')".
|
|
That means that as you use the floater, variables that you assign and
functions that you define are available to subsequent Lua chunks.
|
