| Age | Commit message (Collapse) | Author |
|---|
|
|
|
secondlife/brad/materials_featurette_build_workaround
Attempted workaround for actions/runner-images#10004 build failures.
|
|
Add trusted flag to UI callbacks, so not everything is accessible from the script
|
|
|
|
|
|
following promotion of secondlife/viewer #648: Release/materials featurette
|
|
#648: Release/materials featurette
|
|
|
|
|
|
|
|
|
|
ScopedRegistrarHelper
|
|
There are two conventions for Lua function calls. You can call a function with
positional arguments as usual:
f(1, 2, 3)
Lua makes it easy to handle omitted positional arguments: their values are nil.
But as in C++, positional arguments get harder to read when there are many, or
when you want to omit arguments other than the last ones.
Alternatively, using Lua syntactic sugar, you can pass a single argument which
is a table containing the desired function arguments. For this you can use
table constructor syntax to effect keyword arguments:
f{a=1, b=2, c=3}
A call passing keyword arguments is more readable because you explicitly
associate the parameter name with each argument value. Moreover, it gracefully
handles the case of multiple optional arguments. The reader need not be
concerned about parameters *not* being passed.
Now you're coding a Lua module with a number of functions. Some have numerous
or complicated arguments; some do not. For simplicity, you code the simple
functions to accept positional arguments, the more complicated functions to
accept the single-table argument style.
But how the bleep is a consumer of your module supposed to remember which
calling style to use for a given function?
mapargs() blurs the distinction, accepting either style. Coding a function
like this (where '...' is literal code, not documentation ellipsis):
function f(...)
local args = mapargs({'a', 'b', 'c'}, ...)
-- now use args.a, args.b, args.c
end
supports calls like:
f(1, 2, 3)
f{1, 2, 3}
f{c=3, a=1, b=2}
f{1, 2, c=3}
f{c=3, 1, 2} -- unlike Python!
In every call above, args.a == 1, args.b == 2, args.c == 3.
Moreover, omitting arguments (or explicitly passing nil, positionally or by
keyword) works correctly.
test_mapargs.lua exercises these cases.
|
|
|
|
|
|
|
|
Make LLLeap iterate over child stdout while read data is pending
|
|
instead of using mutual recursion to exhaust the read buffer.
|
|
Co-authored-by: Dave Parks <davep@lindenlab.com>
|
|
|
|
Update tinyexr package to package based on secondlife/3p-tinyexr.
|
|
|
|
Add timer support to the Lua viewer
|
|
secondlife/1614-pbr-materials-exhibit-striationmoiré-patterns-in-specular-highlights
1614 pbr materials exhibit striationmoiré patterns in specular highlights
|
|
|
|
so the user need not reverse-engineer the code to figure out the output.
|
|
|
|
|
|
The reqid is only distinct within a particular calling script.
|
|
|
|
Since timers presents a timers.Timer Lua class supporting queries and
cancellation, make TimersListener::scheduleAfter() and scheduleEvery() respond
immediately so the newly constructed Timer object has the reqid necessary to
perform those subsequent operations.
This requires that Lua invocations of these operations avoid calling the
caller's callback with that initial response.
Reinvent leap.generate() to return a Lua object supporting next() and done()
methods. A plain Lua coroutine that (indirectly) calls fiber.wait() confuses
the fiber scheduler, so avoid implementing generate() as a Lua coroutine.
Add a bit more leap.lua diagnostic output.
|
|
|
|
|
|
leap.eventstream() is used when we expect the viewer's LLEventAPI to send an
immediate first response with the reqid from the request, followed by some
number of subsequent responses bearing the same reqid. The difference between
eventstream() and generate() is that generate() expects the caller to request
each such response, whereas eventstream calls the caller's callback with each
response.
cancelreq() is for canceling the background fiber launched by eventstream()
before the callback tells it to quit.
Make WaitFor:close() remove the object from the waitfors list; similarly, make
WaitForReqid:close() remove the object from the pending list. For this reason,
cleanup() must iterate over a copy of each of the pending and waitfors lists.
Instead of unregisterWaitFor() manually searching the waitfors list, use
table.find().
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Otherwise we fall into the trap of destroying a joinable std::thread, which
calls std::terminate() and hence our crash-on-terminate() handler.
The previous ~ThreadPool() logic only joined threads if the queue wasn't
already closed, but evidently we can reach the destructor with the queue
closed but the threads not yet joined.
Fixes #1534.
|
|
This reverts commit f5a7c22cea16b51db12360436ce64c2433a5aa5f to fix
viewer#1568.
|
|
|
|
#1494 Fix for mirror updates getting "stuck" on some faces.
|
|
secondlife/viewer#1531: Attempt to fix PBR terrain fragment shader
|
|
|
|
|
|
Nat's ideas from PR #1547
|
|
|
