| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
Introduce LLCoros::CoroData::mHistogram, a map of cutoff times (bucket
breakpoints) with counts of occurrences. The idea is that mHistogram counts
how many times the real time taken by a particular coroutine resumption falls
into one of those buckets. Initialize the map with guessed buckets; these are
set in llcoros.cpp so they can be changed without requiring extensive rebuilds.
scheduler::pick_next() now records the timestamp and fiber context just before
the fiber manager resumes the next coroutine. If the next pick_next() call
reveals that the previous resumption took longer than the minimum bucket
breakpoint, it increments the appropriate bucket counter and logs the instance.
LLCoros::toplevel() reports nonzero mHistogram entries on coroutine
termination.
|
|
Instead, introduce bool CoroData::isMain and test that. Use "main" for the
name of the main coroutine. That eliminates the logname() method, also the
llcoro::logname() free function. It also obviates the alternate CoroData
constructor.
Use boost::fibers::fiber::id as the LLInstanceTracker key for CoroData,
instead of the coroutine name. Introduce get_CoroData(id), also getName(id).
Extract static CoroData for the main coroutine to main_CoroData() so both
get_CoroData() overloads can use it.
Ditch unused get_CoroData(string) parameter: now get_CoroData().
Introduce LLCoros::mNameMap for lookup by name (e.g. killreq()). CoroData's
constructor puts an entry into mNameMap; the destructor removes it. Since
mNameMap is thread_local (unlike an LLInstanceTracker key), that theoretically
permits duplicate coroutine names on different threads.
Introduce mPrefixMap to help generate distinct coroutine names, instead of a
single scalar.
Introduce CoroData::getName(), and use it in both LLCoros::getName()
overloads. CoroData::getName() appends mStatus if it's not empty. This is
useful for disambiguating generic pool coroutines based on the current task.
|
|
indicate if the world map should be opened and focused.
|
|
# Conflicts:
# .github/workflows/build.yaml
# indra/llmath/raytrace.cpp
|
|
|
|
|
|
|
|
|
|
|
|
|
|
vector math classes (#2766)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
owning_ptr<T> adapts std::unique_ptr<T> to be a better drop-in replacement for
a legacy class that formerly stored plain T* data members, and explicitly
destroyed them using domain-specific destructor functions.
Directly substituting std::unique_ptr into JPEG2KEncode and JPEG2KDecode was
cumbersome because every such pointer declaration required a redundant
template parameter describing the deleter function passed into its
constructor. Moreover, it required lots of little syntax tweaks: changing
every assignment to a reset() call, changing every reference to a get() call.
Using owning_ptr<T> allows us to leave the code more or less as it was before,
save that assignment and destruction automatically handle the previous
referenced T instance.
|
|
This allows removing #include "llerror.h" from llpointer.h.
Also remove #include "llmutex.h" as a heavy way to get
<boost/functional/hash.hpp>.
That requires adding #include "llmutex.h" to llimage.h, llnotifications.h,
llwatchdog.cpp and llvolumemgr.cpp, which were inheriting it from llpointer.h.
|
|
|
|
|
|
`LLKeyData::operator==(const LLKeyData&)` and `operator!=(const LLKeyData&)`
were not themselves `const` methods. In C++20, that can produce a fatal
warning that if the compare operands were reversed, you'd get different
results. Making them both `const` should fix it.
While touching the method definitions, make `operator==()` more intuitive, and
make `operator!=()` simply negate `operator==()` instead of restating it in
reverse.
|
|
|
|
In C++20, `std::filesystem::u8path()` (that accepts a UTF-8 encoded
`std::string` and returns a `std::filesystem::path`) is deprecated. Instead,
to engage UTF-8 coding conversions, we're supposed to pass the `path`
constructor a `std::u8string`, i.e. a `std::basic_string<char8_t>`. Since
`char8_t` is a type distinct from both `char` and `unsigned char`, we must Do
Something to pass a UTF-8 encoded `std::string` into `std::filesystem::path`.
To avoid copying characters from a `std::string` into a temporary
`std::u8string` and from there into the `std::filesystem::path`, make a
`boost::transform_iterator` that accepts a `std::string_view::iterator` and
adapts it to dereference `char8_t` characters. Make `fsyspath(std::string_view)`
engage the base-class constructor accepting (iterator, iterator), adapting
`string_view::begin()` and `end()` to deliver `char8_t` characters.
Use the same tactic for `fsyspath::operator=(std::string_view)`, explicitly
calling `std::filesystem::path::assign()` with the adapted iterators.
To resolve ambiguities, provide both constructors and assignment operators
accepting `(const std::string&)` and `(const char*)`, explicitly converting
each to `std::string_view`.
At the same time, `std::filesystem::path::u8string()` now returns
`std::u8string` rather than `std::string`. Since `std::filesystem::path`
delivers only that `std::u8string` rather than iterators into its internal
representation, we can't avoid capturing it and copying to the returned
`std::string`.
Remove explicit `.u8string()` calls from a few existing `fsyspath` instances,
now that `fsyspath` supports implicit conversion to `std::string`.
|
|
|
|
Given templated constructors and assignment operators, it's tempting to remove
specific constructors and assignment operators with the same LLPointer<Type>
parameters. That turns out to be a mistake. Add comments to warn future
maintainers.
|
|
This affords strong exception safety. Also, eliminating the conditional may
improve speed.
|
|
Instead of restating the whole class, requiring changes to be made in parallel
(which has already failed), just make a template alias.
|
|
That is, both `LLPointer::operator==()` and `operator!=()` and the free function
`operator==()` and `operator!=()` now accept pointer types other than the type
of the subject `LLPointer`, letting the compiler apply implicit pointer
conversions or diagnose an error.
|
|
Add Lua scripting to develop, behind feature flag
|
|
|
|
|
|
|
|
|
|
# Conflicts:
# indra/newview/llfeaturemanager.cpp
# indra/newview/llviewertexturelist.cpp
# indra/newview/llvoicewebrtc.cpp
|
|
|
|
|
|
|
|
Introduce `ScriptCommand` class that parses a command line into a script name
and optional args, using bash-like quoting and escaping. `ScriptCommand`
searches for a file with that script name on a passed list of directories; the
directories may be specified relative to a particular base directory.
`ScriptCommand` supports the special case of a script name containing unescaped
spaces. It guarantees that either the returned script file exists, or its
`error()` string is non-empty.
Replace `LLLeap::create()` logic, from which `ScriptCommand` was partly
derived, with a `ScriptCommand` instance.
Make `LLLUAmanager::runScriptFile()` use a `ScriptCommand` instance to parse
the passed command line.
Subsume `LLAppViewer::init()` script-path-searching logic for `--luafile`
into `ScriptCommand`. In fact that lambda now simply calls
`LLLUAmanager::runScriptFile()`.
Make `lluau::dostring()` accept an optional vector of script argument strings.
Following PUC-Rio Lua convention, pass these arguments into a Lua script as
the predefined global `arg`, and also as the script's `...` argument.
`LuaState::expr()` also accepts and passes through script argument strings.
Change the log tag for the Lua script interruption message: if we want it, we
can still enable it, but we don't necessarily want it along with all other
"Lua" DEBUG messages.
Remove `LuaState::script_finished_fn`, which isn't used any more. Also remove
the corresponding `LLLUAmanager::script_finished_fn`. This allows us to
simplify `~LuaState()` slightly, as well as the parameter signatures for
`LLLUAmanager::runScriptFile()` and `runScriptLine()`.
|
|
Make Develop->Render Tests->Frame Profile dump JSON to a file too.
|
|
|
|
|
|
|
|
fixes secondlife/viewer#2566
|
|
or to produce readable text from a mix of printing and nonprinting ASCII
characters.
(cherry picked from commit 01a59bab1a4b7c4645271a21cfaadc3735b6029c)
|
|
|
|
This is redundant (but harmless) on a Posix system, but it fills a missing
puzzle piece on Windows. The point of fsyspath is to be able to interchange
freely between fsyspath and std::string. Existing fsyspath could be
constructed and assigned from std::string, and we could explicitly call its
string() method to get a std::string, but an implicit fsyspath-to-string
conversion that worked on Posix would trip us up on Windows. Fix that.
(cherry picked from commit fbeff6d8052d4b614a0a2c8ebaf35b45379ab578)
|
