summaryrefslogtreecommitdiff
path: root/indra/llcommon
AgeCommit message (Collapse)Author
2024-04-02Use LLCoros::TempStatus when Lua is waiting on get_event_next().Nat Goodspeed
When enumerating C++ coroutines, it can be useful to know that a particular Lua coroutine is simply waiting for further events.
2024-04-02Add LL.source_path(), source_dir() Lua entry points.Nat Goodspeed
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.
2024-04-02Give LLLeapListener's "listen" operation a "tweak" argument.Nat Goodspeed
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.
2024-03-28viewer#1073 crash at loadSkeletonAndrey Kleshchev
looks like file that was being parced got corrupted 'in progress'
2024-03-28Ditch a couple LL_DEBUGS() messages.Nat Goodspeed
2024-03-28Eliminate unreferenced exception nameNat Goodspeed
2024-03-28Terminate Lua scripts hanging in LL.get_event_next().Nat Goodspeed
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.
2024-03-28Clean up unused llevents.h #includes.Nat Goodspeed
2024-03-28Move our lua_register(), lua_rawlen() from lua_function.h to .cpp.Nat Goodspeed
2024-03-27Merge branch 'main' into marchcat/yz-mergeAndrey Lihatskiy
2024-03-27Merge branch 'main' into DRTVWR-591-maint-XAndrey Lihatskiy
# Conflicts: # indra/llui/lltransutil.cpp # indra/newview/app_settings/settings.xml # indra/newview/llfloaterenvironmentadjust.cpp # indra/newview/llpaneleditwater.cpp # indra/newview/llpanelface.cpp # indra/newview/lltexturectrl.cpp # indra/newview/lltexturectrl.h
2024-03-27Merge remote-tracking branch 'origin/main' into DRTVWR-588-maint-WAndrey Lihatskiy
# Conflicts: # .github/workflows/build.yaml
2024-03-25Add LL.check_stop() entry point and call it in fiber scheduler().Nat Goodspeed
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.
2024-03-25Add LL. prefix to viewer entry points, fix existing references.Nat Goodspeed
2024-03-25Remove colliding LLListener.Nat Goodspeed
2024-03-24Introduce LLStreamListener: bundle LLEventStream+LLTempBoundListener.Nat Goodspeed
This is a very common pattern, especially in test code, but elsewhere in the viewer too. Use it in llluamanager_test.cpp.
2024-03-23Update sendReply(): accepting LLSD by value already copies it.Nat Goodspeed
2024-03-21WIP: Add fiber.lua module and use in leap.lua and WaitQueue.lua.Nat Goodspeed
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().
2024-03-18secondlife/viewer#1006: Move blank material constant to indra_constants.hCosmic Linden
2024-03-15SL-18721 Restore release behaviorAndrey Kleshchev
Closing window correctly caused a significant amount of logout freezes with no known reproes. Temporarily returning to old behavior were thread was killes without closing window and will reenable in later maints to hopefully get a scenario or at least more data of what is causing the freeze.
2024-03-14Proposal #2 to restore how UI/dialogs used to render by prioritizing ↵Henri Beauchamp
fallback fonts. With the emojis support, a new font was added, which not only provides emojis but also fancy colorful replacements for UTF-8 characters that used to be supported by our fallback (monochrome) fonts: this causes discrepancies and unwanted/undesired changes in scripted objects menus (e.g. an empty circle or square may render as a black, full one, a heart may render red instead of white), not to mention the larger font size used by the emoji characters... This patch restores the aspect of such menus/dialogs/UI elements with UTF-8 characters that *are* supported by the usual fallback fonts (fonts which may also vary from one viewer to another, and from one OS to another), so that everything keeps working/rendering as it always did so far, while not impairing the use of new colorful emojis. This second proposal ensures that: - "genuine" emojis (in the 0x1f000-0x1ffff range), will *always* be rendered using the new emojis font (this solves, for example, the monochrome "yellow faces" issue seen with some characters in my first proposal). - Special UTF-8 characters (in the 0x2000-0x32FF range) which have been used by scripters so far, will render as they used to, using the monochrome fallback fonts (this repairs scripted dialogs menus). - Remaining special characters, that do not have a corresponding glyph in the monochrome font, but do have one in the emojis font, will use the latter font to render. It also got the nice side-effect of removing the dependency on the ICU4C library. Note however that the recent commit: https://github.com/secondlife/viewer/commit/326055ba82c22fedde186c6a56bafd4fe87e613a will need to be reverted to allow this patch to actually fix scripted dialogs. Also, some cleanup might be needed in skins/default/xui/*/emoji_characters.xml to remove from it the special UTF-8 characters that will no longer be rendered with fanciful colors, but instead with the monochrome font glyphs.
2024-03-08Merge 'release/luau-scripting' into lua-leap for Emoji release.Nat Goodspeed
2024-03-08Merge branch 'main' into release/luau-scripting for Emoji release.Nat Goodspeed
2024-03-06Defend LuaState::expr() against lua_tollsd() errors.Nat Goodspeed
This is an unusual use case in which lua_tollsd() is called by C++ code without the Lua runtime farther up the call stack.
2024-03-05SL-17896 Don't crash silently if files are missing or out of memoryAndrey Kleshchev
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.
2024-03-04Merge branch 'main' into marchcat/x-mergeAndrey Lihatskiy
# Conflicts: # indra/llcommon/llstring.cpp # indra/llcommon/llstring.h
2024-03-01Merge remote-tracking branch 'origin/main' into release/gltf-maint2Brad Linden
2024-03-01Merge branch 'main' into marchcat/yz-mergeAndrey Lihatskiy
# Conflicts: # indra/newview/llinventorygallery.cpp
2024-03-01Merge branch 'main' into DRTVWR-588-maint-WAndrey Lihatskiy
2024-02-29Refactor require() to make it easier to reason about Lua stack usage.Nat Goodspeed
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.
2024-02-29Improve Debug class (indra/test/debug.h).Nat Goodspeed
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.
2024-02-27SL-18721 Shutdown fixes #5Andrey Kleshchev
2024-02-27Merge branch 'release/luau-scripting' into luau-require-impl.Nat Goodspeed
2024-02-23viewer#875 Crash at uri normalizationAndrey Kleshchev
Note that crash happened when setting LLProgressView::setMessage
2024-02-23Allow debug.h to be #included even in normal viewer code.Nat Goodspeed
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.
2024-02-23require() code clean-upMnikolenko Productengine
2024-02-23Ditch DebugExit: we already have Debug (in debug.h)Nat Goodspeed
2024-02-23Clean up #includes in lualistener.hNat Goodspeed
2024-02-22 #include <iomanip> where std::quoted() is referenced.Nat Goodspeed
Remove where it isn't.
2024-02-22Lua listen_events(), await_event() => get_event_{pumps,next}().Nat Goodspeed
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.
2024-02-22Add diagnostic logging to LLEventPumps::post().Nat Goodspeed
If post() can't find the requested pump, say so.
2024-02-22Viewer#863 Crash reading xmlAndrey Kleshchev
2024-02-21Add the option to use clean lua_State in "Lua debug" floaterMnikolenko Productengine
2024-02-20Initial require implementationMnikolenko Productengine
2024-02-13Add leaphelp() Lua builtin function for help on LEAP operations.Nat Goodspeed
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.
2024-02-13Add help() function to Lua "builtins."Nat Goodspeed
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.
2024-02-13Merge branch 'll_convert' into helpcmd.Nat Goodspeed
2024-02-13Change ll_convert<TOTYPE>(string) to just ll_convert(string).Nat Goodspeed
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.
2024-02-12WIP: Changes towards supporting Lua console help text.Nat Goodspeed
2024-02-09Change the LuaFunction subclass instance name suffix to _lua.Nat Goodspeed
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.