| Age | Commit message (Collapse) | Author |
|---|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
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.
|
|
Since the description shows up in the log output, it's better to see just the
script filename than to see "runScriptFile('filename')".
|
|
Extend the LuaFunction::Registry map to store helptext as well as the function
pointer.
Add help text to every existing lua_function() invocation.
|
|
Break out for LLLUAmanager consumers the promise/future semantics of
waitScriptFile() and waitScriptLine(). startScriptMumble() uses
runScriptMumble() to launch a coroutine to run the specified Lua script or
chunk, providing an internal adapter callback to set a promise on completion.
It then returns to its caller the future obtained from that promise. This
allows a caller to call startScriptMumble(), run in parallel with the Lua
coroutine for a while and then call get() on the returned future to wait for
results.
waitScriptMumble() is then trivially implemented using startScriptMumble().
Fix runScriptLine()'s logic to abbreviate the passed Lua chunk for use as the
description. We were erroneously assigning back through a string_view of the
parameter, which overwrote a temporary string in the argument list.
With Lua 5.4, listen_events() tried to discover the main "thread" (Lua
coroutine) associated with the current lua_State so we could call async
callbacks on that thread. Luau doesn't seem to provide that feature, so run
callbacks on whichever thread calls listen_events().
Reinstate original multi-argument lua_print_msg(), tweaked to avoid the Lua
5.4 lua_rotate() function, which is missing from Luau.
|
|
Add LuaState::expr() that evaluates a Lua snippet and reports back any result
(or error) left on the stack.
Add LLLUAmanager::runScriptFile() and runScriptLine() overloads that accept a
callback with an (int count, LLSD result) signature. The count disambiguates
(error, no result, one result, array of results). Also add overloads that accept
an existing LuaState instance. Also add waitScriptFile() and waitScriptLine()
methods that pause the calling coroutine until the Lua script completes, and
return its results.
Instead of giving LuaState a description to use for all subsequent checkLua()
calls, remove description from its constructor and data members. Move to
expr() and checkLua() parameters: we want a description specific to each
operation, rather than for the LuaState as a whole. This prepares for
persistent LuaState instances.
For now, the existing script_finished_fn semantics remain: the callback will
be called only when the LuaState is destroyed. This may need to change as we
migrate towards longer-lasting LuaState instances.
Make lua_function(name) macro append suffixes to the name for both the
LuaFunction subclass declaration and the instance declaration. This allows
publishing a lua_function() name such as sleep(), which already has a
different C++ declaration.
Move the Lua sleep() entry point to a standalone lua_function(sleep), instead
of a lambda in the body of runScriptFile().
|
|
The intention is to decentralize Luau entry points into our C++ code,
permitting a given entry point to be added to the .cpp file that already deals
with that class or functional area. Continuing to add every such entry point
to llluamanager.cpp doesn't scale well.
Extract LuaListener class from llluamanager.cpp to its own header and .cpp
file.
Extract from llluamanager into lua_function.h (and .cpp) declarations useful
for adding a lua_function Luau entry point, e.g.:
lua_register()
lua_rawlen()
lua_tostdstring()
lua_pushstdstring()
lua_tollsd()
lua_pushllsd()
LuaPopper
lua_function() and LuaFunction class
LuaState
lua_what
lua_stack
DebugExit
|
|
|
|
|
|
|
|
|
|
Also remove
#pragma comment(lib, "liblua54.a")
from relevant source files.
|
|
|
|
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.
|
|
DRTVWR-589
|
|
|
|
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>.
|
|
Break out a lua_print_msg() function common to print_debug(), print_info() and
print_warning(). Instead of accepting a single argument, lua_print_msg()
accepts arbitrary arguments, passing each to the Lua tostring() function and
concatenating the results. In addition to returning the combined string to its
caller for level-appropriate logging, it also posts the message to a "lua
output" LLEventPump for any interested party.
Make LLFloaterLUADebug listen on "lua output" when the floater is constructed,
storing the connection in an LLTempBoundListener to stop listening when the
floater is destroyed. Append each message to the floater's output panel with a
line break.
Make LLTextEditor::addLineBreakChar() public. insertText("\n") only appends a
little rectangle glyph.
Enlarge the text capacity of the floater's output panel to be able to report
whatever messages a Lua script wants to print.
Add diagnostic logging for posting events from Lua, and receiving events to
forward to Lua.
Since lua_pop() is a macro implemented on lua_settop(), replace the awkward
construct lua_pop(L, lua_gettop(L)) with lua_settop(L, 0).
Use lambdas instead of std::bind() to connect LuaListener and LLLeapListener.
|
|
|
|
|
|
|
|
Sprinkle lua_checkstack() calls into functions that push to the Lua stack --
particularly important when traversing nested data structures of unknown depth!
Tweak lua_pushllsd() handling of LLSD arrays.
|
|
This suspends the calling Lua coroutine (and C++ coroutine on which the Lua
state is running) until an event is received on the named LLEventPump.
Returns the event.
Pass optional timeout in seconds as a second argument. With no timeout, waits
indefinitely.
Pass optional timeout discriminator return value as a third argument
(default nil).
|
|
so Lua print() output will go to the viewer log, instead of getting discarded
and possibly causing failures when the buffer fills and there's no open stdout
file handle.
Also name each Lua C++ coroutine with the description we give the LuaState
instance.
|
|
|
|
|
|
|
|
|
|
Add LuaListener, based on LLLeap. LuaListener has an int key so the second and
subsequent calls to listen_events() can find a previously-created one.
LuaListener listens on its LLEventPump and arranges to call the specified Lua
callback with any incoming event. It also instantiates an LLLeapListener.
listen_events() locates the main thread for its state: we only want to call
callbacks on the Lua chunk's main thread, not on a (possibly suspended)
coroutine. It finds or creates a LuaListener and stashes it in the main
thread's registry, along with the passed Lua callback function. Finally it
returns the names of the LuaListener's reply pump and the LLLeapListener's
command pump.
Add LuaState RAII class to manage the lifespan of each lua_State we create.
This encapsulates much of the boilerplate common to runScriptFile() and
runScriptLine(). In addition, LuaState's destructor checks for a LuaListener
key and, if found, destroys the referenced LuaListener.
LuaState's constructor requires a description to clarify log messages.
Move the checkLua() free function to a member of LuaState. This allows
capturing an error message to pass to the C++ completion callback, if any.
Use LuaState in runScriptFile() and runScriptLine(), synthesizing a suitable
description in each case.
Add print_debug() and print_info() logging calls, analogous to
print_warning(). Add luaL_where() prefix to every such message.
Add lua_pushstdstring(), like lua_tostdstring(): convenience for working with
the pointer and length used by lua_pushlstring() and lua_tolstring().
Clean up return values of lua_functions. A lua_CFunction returns the number of
return values it has pushed, so any 'void' lua_CFunction should pop its
arguments and return 0.
|
|
The function formerly known as luaL_typerror() is now luaL_typeerror().
|
|
Given that we at least have a possibility of determining the length of a Lua
table in advance, we might be able to populate a vector of keys with a single
initial allocation. Even if Lua reports the length incorrectly,
vector::push_back() is one of the bread-and-butter operations of the library,
optimized to the extent possible. Inserting elements into a set seems more
likely to incur allocations.
Of course, we must then sort() the vector to determine its largest key value.
Also document the requirement that we use a Lua runtime compiled for C++, that
is, compiled to raise errors by C++ exceptions rather than by longjmp(). We
rely on temporary stack objects being properly destroyed even if errors are
raised.
Conventionally, with lua_tomumble(L, index), 'index' refers to the stack index
of the Lua object being converted to C++. For a Lua table, talk about table
keys rather than table indexes to avoid confusing the maintainer.
|
|
The previous implementation assumed that the Lua length function would
correctly report the number of entries in a table, and that traversing a table
with integer keys would produce them in numeric order. Neither assumption is
true. Instead, make a preliminary pass to validate and collect indexes, and to
discover the highest integer index. Armed with that, we can construct a
contiguous LLSD array of correct size, and populate it with a second pass.
Also add Lua-callable post_on_pump(pumpname, datablob) function.
|
|
|
|
|
|
|
|
|
|
It seems TC only builds specific v-p branches, e.g. DRTVWR-589 but not
DRTVWR-589-llsd.
|
|
|
|
|
|
|
