Translation of the UI is currently split into 3 preferences:
interface, tooltips, and new data. The distinction between interface
and tooltips is currently unclear as tooltips also include a lot of
messages not displayed in the actual tooltips on mouse hover.
These include reports to the Info Editor, information in editor
headers and footers, and statuses in panels.
In order to limit the use of `TIP_()` to actual tooltips, this commit
introduces a new preference for this extra information: "Reports".
New translation macros are introduced: `RPT_()` and `CTX_RPT_()`, as
well as their equivalent for the Python API, `pgettext_rpt_()`, to be
imported as `rpt_()`.
Pull Request: https://projects.blender.org/blender/blender/pulls/116804
These new ones (one new 'python' case, and some for external libraries
that were not affected so far) seem to be needed to get sanitizer builds
tests to work on current Linux buildbot.
Adds a `--weeks-ago` option to be able to control which week the report
should be made for. In practice people sometimes need to create reports
for a few weeks ago or for the current week.
Along with the 4.1 libraries upgrade, we are bumping the clang-format
version from 8-12 to 17. This affects quite a few files.
If not already the case, you may consider pointing your IDE to the
clang-format binary bundled with the Blender precompiled libraries.
The last good commit was 8474716abb0db3b06838a57f7217bc945638d8df.
After this commits from main were pushed to blender-v4.0-release. These are
being reverted.
Commits a4880576dc from to b26f176d1a that happend afterwards were meant for
4.0, and their contents is preserved.
Previously this was the double the CPU count because:
- Modern CPU's from AMD & Intel support SMT/hyper-threading which
present twice as many cores, doubling again has little to no benefit.
- Using 2x or 4x the number of physical cores number can use a lot of
memory on systems with many cores which are becoming more common.
Since hiding symbols on Linux, in many cases only addresses are printed.
This utility can run run on the back-trace to replace addresses
with line & function information.
See: ./tools/utils/addr2line_backtrace.py --help for usage information.
Note that some examples online run addr2line directly and use the output
in the stack-trace, while convenient and acceptable in some cases, in my
tests addr2line can take over 20 seconds to complete for a single
address. Implement this as a post-process instead. Multi-processing to
prevent this taking too long (around ~23 seconds on my system).
Ref !111416.