| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
|
|
|
We add a suffix to let us publish a Lua foo() function that wraps a C++ foo()
function. Of course the lua_CFunction must accept lua_State* and extract its
parameters from the Lua stack, so it must invoke different C++ code than the
C++ foo() function it's trying to reach. So the lua_CFunction is a method of
the LuaFunction subclass instance named foo_lua.
The suffix was _luadecl, but since the class name shows up in log messages,
make it the more streamlined _lua instead.
|
|
The chunk:
return 1, 2, {}
differs in two ways from:
print(1, 2, {})
First, print() engages the Lua tostring() builtin, so it displays values as
Lua sees them. (For a table, tostring() displays "table: hex", which isn't so
wonderful.) But LLFloaterLUADebug serializes the LLSD converted from the Lua
return values.
Second, we've overridden print() to engage a function that writes to the
viewer log as well as displaying to LLFloaterLUADebug. (As we go forward, most
Lua scripts won't be run manually by LLFloaterLUADebug.) The values returned
by a Lua chunk aren't implicitly logged. Each C++ caller wanting to evaluate a
Lua expression can choose whether to log the results.
|
|
|
|
|
|
Extend the LuaFunction::Registry map to store helptext as well as the function
pointer.
Add help text to every existing lua_function() invocation.
|
|
|
|
macOS clang produces fatal warnings when trying to pass a const char*
parameter to luaL_error() (-Wformat-security). Temporarily suppressing that
requires #pragma clang directives which, in turn, produce fatal warnings in
VS.
Moreover, VS recognizes that luaL_error() never returns, and so diagnoses the
following return statement as unreachable code. But that return statement is
the whole reason for lluau::error()'s existence...
|
|
|
|
|
|
|
|
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.
|
|
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.
|
|
We were calling lua_pcall() in such a way as to discard any values returned by
the Lua chunk.
Work around Luau's broken lua_tointegerx(), which unlike vanilla Lua's does
not report whether the value at the specified index is or is not an integer.
|
|
|
|
|
|
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
a preset...' option of the 'Preferences' floater
|
|
available to all users
|
|
|
|
|
|
|
|
|
