Age | Commit message (Collapse) | Author |
|
Our std::strings are UTF-8 encoded, so conversion from std::string to
std::filesystem::path must use UTF-8 decoding. The native Windows
std::filesystem::path constructor and assignment operator accepting
std::string use "native narrow encoding," which mangles path strings
containing UTF-8 encoded non-ASCII characters.
fsyspath's std::string constructor and assignment operator explicitly engage
std::filesystem::u8path() to handle encoding. u8path() is deprecated in C++20,
but once we adapt fsyspath's conversion to C++20 conventions, consuming code
need not be modified.
|
|
Among other things, this empowers ll_convert() and ll_convert_to() to accept a
string literal (which might contain non-ASCII characters, e.g. __FILE__).
Without this, even though we have ll_convert_impl specializations accepting
const char*, passing a string literal fails because the compiler can't find a
specialization specifically accepting const char[length].
|
|
On Windows, std::filesystem::path::value_type is wchar_t, not char -- so
path::string_type is std::wstring, not std::string. So while Posix path
instances implicitly convert to string, Windows path instances do not. Add
explicit u8string() calls.
Also add LL.abspath() Lua entry point to further facilitate finding a resource
file relative to the calling Lua script. Use abspath() for both
test_luafloater_demo.lua and test_luafloater_gesture_list.lua.
|
|
When enumerating C++ coroutines, it can be useful to know that a particular
Lua coroutine is simply waiting for further events.
|
|
This helps a Lua script log its own identity, or find associated files
relative to its location in the filesystem.
Add more comprehensive logging around the start and end of a given Lua script,
or its "p.s." fiber.run() call.
|
|
If specified as true, "tweak" means to tweak the specified "listener" name for
uniqueness. This avoids LLEventPump::listen()'s DupListenerName exception,
which causes the "listen" operation to return "status" as false.
|
|
|
|
|
|
Make LuaListener listen for "LLApp" viewer shutdown events. On receiving such,
it closes its queue. Then the C++ coroutine calling getNext() wakes up with an
LLThreadSafeQueue exception, and calls LLCoros::checkStop() to throw one of
the exceptions recognized by LLCoros::toplevel().
Add an llluamanager_test.cpp test to verify this behavior.
|
|
|
|
|
|
fiber.lua's scheduler() is greedy, in the sense that it wants to run every
ready Lua fiber before retrieving the next incoming event from the viewer (and
possibly blocking for some real time before it becomes available). But check
for viewer shutdown before resuming any suspended-but-ready Lua fiber.
|
|
|
|
|
|
This is a very common pattern, especially in test code, but elsewhere in the
viewer too.
Use it in llluamanager_test.cpp.
|
|
|
|
fiber.lua goes beyond coro.lua in that it distinguishes ready suspended
coroutines from waiting suspended coroutines, and presents a rudimentary
scheduler in fiber.yield(). yield() can determine that when all coroutines are
waiting, it's time to retrieve the next incoming event from the viewer.
Moreover, it can detect when all coroutines have completed and exit without
being explicitly told.
fiber.launch() associates a name with each fiber for debugging purposes.
fiber.get_name() retrieves the name of the specified fiber, or the running fiber.
fiber.status() is like coroutine.status(), but can return 'ready' or 'waiting'
instead of 'suspended'.
fiber.yield() leaves the calling fiber ready, but lets other ready fibers run.
fiber.wait() suspends the calling fiber and lets other ready fibers run.
fiber.wake(), called from some other coroutine, returns the passed fiber to
ready status for a future call to fiber.yield().
fiber.run() drives the scheduler to run all fibers to completion.
If, on completion of the subject Lua script, LuaState::expr() detects that the
script loaded fiber.lua, it calls fiber.run() to finish running any dangling
fibers. This lets a script make calls to fiber.launch() and then just fall off
the end, leaving the implicit fiber.run() call to run them all.
fiber.lua is designed to allow the main thread, as well as explicitly launched
coroutines, to make leap.request() calls. This part still needs debugging.
The leap.lua module now configures a fiber.set_idle() function that honors
leap.done(), but calls get_event_next() and dispatches the next incoming event.
leap.request() and generate() now leave the reqid stamp in the response. This
lets a caller handle subsequent events with the same reqid, e.g. for
LLLuaFloater.
Remove leap.process(): it has been superseded by fiber.run().
Remove leap.WaitFor:iterate(): unfortunately that would run afoul of the Luau
bug that prevents suspending the calling coroutine within a generic 'for'
iterator function.
Make leap.lua use weak tables to track WaitFor objects.
Make WaitQueue:Dequeue() call fiber.wait() to suspend its caller when the queue
is empty, and Enqueue() call fiber.wake() to set it ready again when a new
item is pushed.
Make llluamanager_test.cpp's leap test script use the fiber module to launch
coroutines, instead of the coro module. Fix a bug in which its drain()
function was inadvertently setting and testing the global 'item' variable
instead of one local to the function. Since some other modules had the same
bug, it was getting confused.
Also add printf.lua, providing a printf() function. printf() is short for
print(string.format()), but it can also print tables: anything not a number or
string is formatted using the inspect() function.
Clean up some LL_DEBUGS() output left over from debugging lua_tollsd().
|
|
|
|
|
|
This is an unusual use case in which lua_tollsd() is called by C++ code
without the Lua runtime farther up the call stack.
|
|
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.
|
|
|
|
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.
|
|
|
|
|
|
|
|
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.
|
|
|
|
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.
|
|
|
|
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...
|
|
|
|
|
|
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
|
|
LLDispatchListener::getPumpName() went away when LLEventStream became one of
its base classes. The assumption was that LLEventStream::getName() would
suffice. Re-add getPumpName(), forwarding to getName(), for backwards
compatibility.
|