Age | Commit message (Collapse) | Author |
|
|
|
The new Xcode 14.1 brings the new Apple Clang compiler which
considers sprintf unsafe and geenrates deprecation warnings
suggesting to sue snprintf instead. This only happens for C++
code by default, and C code can still use sprintf without any
warning.
This changes does the following:
- Whenever is trivial replace sprintf() with BLI_snprintf.
- For all other cases use the newly introduced BLI_sprintf
which is a wrapper around sprintf() but without warning.
There is a discouragement note in the BLI_sprintf comment to
suggest use of BLI_snprintf when the size is known.
Differential Revision: https://developer.blender.org/D16410
|
|
|
|
|
|
Function casts hid casting between potentially incompatible type
signatures (using int instead of Py_ssize_t). As it happens this seems
not to have caused any bugs on supported platforms so this change is
mainly for correctness and to avoid problems in the future.
|
|
Some BPy_StructRNA methods used BPy_PropertyRNA in their function
signatures, while this didn't case any bugs, it could lead to issues
in the future.
|
|
Missed these changes in [0].
Also replace designated initializers in some C code, as it's not used
often and would need to be removed when converting to C++.
[0] e555ede626dade2c9b6449ec7dcdda22b2585fd4
|
|
Use struct identifiers in comments before the value.
This has some advantages:
- The struct identifiers didn't mix well with other code-comments,
where other comments were wrapped onto the next line.
- Minor changes could re-align all other comments in the struct.
- PyVarObject_HEAD_INIT & tp_name are no longer placed on the same line.
Remove overly verbose comments copied from PyTypeObject (Python v2.x),
these aren't especially helpful and get outdated.
Also corrected some outdated names:
- PyTypeObject.tp_print -> tp_vectorcall_offset
- PyTypeObject.tp_reserved -> tp_as_async
|
|
|
|
|
|
Show the windowing environment on non MS-Windows/Apple systems,
since X11/WAYLAND are selected startup there was no convenient way
for users to know which back-end was being used.
Include the windowing environment in the About splash & system-info.txt
since it will be useful for handling bug reports.
This commit adds a private API call not intended for general use
as I would like to be able to remove this later and it's only needed
in the specific case of testing if Blender is using WAYLAND or X11
(which maybe be used via XWayland).
Python scripts can already inspect the system to check which windowing
environment used, the API call is mainly useful for troubleshooting.
|
|
|
|
Missed flipping arguments for caller.
|
|
Rename BKE_appdir_folder_id_version to
BKE_appdir_resource_path_id_with_version because BKE_appdir_folder_id
and BKE_appdir_folder_id_version didn't accept compatible arguments.
Also add notes to GHOST_getSystemDir & GHOST_getUserDir that
BKE_appdir_resource_path_id(..) should be used instead (in most cases).
|
|
Contributed by luzpaz.
Differential Revision: https://developer.blender.org/D16071
|
|
Mathutils types were always GC tracked even when it wasn't intended.
Not having to track objects speeds up Python execution.
In an isolated benchmark created to stress test the GC
creating 4-million vectors (re-assigning them 100 times), this gives
an overall ~2.5x speedup, see: P3221.
Details:
Since [0] (which added support for sub-classed mathutils types)
tp_alloc was called which defaults to PyType_GenericAlloc which always
GC tracked the resulting object when Py_TPFLAGS_HAVE_GC was set.
Avoid using PyType_GenericAlloc unless the type is sub-classed,
in that case the object is un-tracked.
Add asserts that the tracked state is as expected before tracking &
un-tracking, to ensure changes to object creation don't cause objects
to be tracked unintentionally.
Also assign the PyTypeObject.tp_is_gc callback so types optionally GC
track objects only do so when an object is referenced.
[0]: fbd936494495d0de54eef24a97957e000306785f
|
|
|
|
|
|
|
|
|
|
While both are supported, 'arg' is in more common use so prefer it.
|
|
|
|
Calling operators in background-mode always printed with the
assumption that output should never be hidden.
However operators called from `bpy.ops` were also printing reports to
the `stdout` (needed for the Python console and generally useful).
Resolve by adding a flag to signal that the owner of the ReportList
is responsible for printing to the `stdout`.
|
|
The following changes have been made to this attribute with
WITH_PYTHON_MODULE is defined:
- Defaults to an empty string (instead of pointing to __init__.so).
- It's writable, so script authors can point to a valid Blender binary.
`where_am_i(..)` is no longer used by BKE_appdir_program_path_init,
there is now a separate code-path for setting the initial program
directory, calls after this can be used to set the binary path.
|
|
Changed in Python 3.5, match Python's internal name.
|
|
When Blender is built as a Python module, exit early if the major
and minor versions don't match. Without this, the error message can
be cryptic/unhelpful.
|
|
|
|
|
|
Was not using the absolute index for comparison,
breaking the id_management test.
|
|
|
|
Invalidate depsgraph.object_instances when freed, this resolves a crash
when accessing the object instances after iteration has finished.
Unlike most other collections, object_instances is only valid while the
iterator is in-memory.
The Python/RNA API needs to inline int/string collection lookups so the
Python instance can be created before the iterator ends.
Reviewed By: mont29, sergey
Ref D15755
|
|
|
|
Check the thread-state before accessing PyEval_GetFrame, since this is
a crash handler, the state of the Python interpreter isn't known.
|
|
Currently, the compositor can be disabled using the WITH_COMPOSITOR
build option. Since, we intent to always build the realtime compositor,
we need to make the distinction between both compositors clear.
So this patch renames the option to WITH_COMPOSITOR_CPU. Additionally,
the check for the option was moved inside the compositor modules' own
CMake file in preparation for the realtime compositor code.
Differential Revision: https://developer.blender.org/D15622
Reviewed By: Jeroen Bakker, Ray Molenkamp
|
|
|
|
NOTE: This is committed to the 3.3 branch as part of D15606, which we
decided should go to this release still (by Bastien, Dalai and me). That
is because these are important usability fixes/improvements to have for
the LTS release.
Adds `rna_path.cc` and `RNA_path.h`.
`rna_access.c` is a quite big file, which makes it rather hard and
inconvenient to navigate. RNA path functions form a nicely coherent unit
that can stand well on it's own, so it makes sense to split them off to
mitigate the problem. Moreover, I was looking into refactoring the quite
convoluted/overloaded `rna_path_parse()`, and found that some C++
features may help greatly with that. So having that code compile in C++
would be helpful to attempt that.
Differential Revision: https://developer.blender.org/D15540
Reviewed by: Brecht Van Lommel, Campbell Barton, Bastien Montagne
|
|
Adds `rna_path.cc` and `RNA_path.h`.
`rna_access.c` is a quite big file, which makes it rather hard and
inconvenient to navigate. RNA path functions form a nicely coherent unit
that can stand well on it's own, so it makes sense to split them off to
mitigate the problem. Moreover, I was looking into refactoring the quite
convoluted/overloaded `rna_path_parse()`, and found that some C++
features may help greatly with that. So having that code compile in C++
would be helpful to attempt that.
Differential Revision: https://developer.blender.org/D15540
Reviewed by: Brecht Van Lommel, Campbell Barton, Bastien Montagne
|
|
Instead of removing the `bgl` module, set all it's functions to stubs
so importing `bgl` or any of it's members doesn't raise an error.
This avoids problems for scripts that import bgl but don't call it's
functions when running in background mode.
|
|
When rendering with headless builds, show an error instead of crashing.
Previously GPU_backend_init was called indirectly from
DRW_opengl_context_create, a new function is now called from the window
manager (GPU_backend_init_once), so it's possible to check if the GPU
has a back-end.
This also disables the `bgl` Python module when building WITH_HEADLESS.
Reviewed By: fclem
Ref D15463
|
|
Rename and refactor several F-curve key manipulation functions, and move
them from `editors` to `blenkernel`.
The functions formerly known as `delete_fcurve_key`,
`delete_fcurve_keys`, and `clear_fcurve_keys` have been moved from
`ED_keyframes_edit.h` to `BKE_fcurve.h` and have been renamed according
to hierarchical naming rules.
Below is a table of the naming changes.
| From | To |
| -- | -- |
| `delete_fcurve_key(fcu, index, do_recalc)` | `BKE_fcurve_delete_key(fcu, index)` |
| `delete_fcurve_keys(fcu)` | `BKE_fcurve_delete_keys_selected(fcu)` |
| `clear_fcurve_keys(fcu)` | `BKE_fcurve_delete_keys_all(fcu)` |
| `calchandles_fcurve()` | `BKE_fcurve_handles_recalc()` |
| `calchandles_fcurve_ex()`| `BKE_fcurve_handles_recalc_ex()` |
The function formerly known as `delete_fcurve_key` no longer takes a
`do_fast` parameter, which determined whether or not to call
`calchandles_fcurve`. Now, the responsibility is on the caller to run
the new `BKE_fcurve_handles_recalc` function if they have want to
recalculate the handles.
In addition, there is now a new static private function called
`fcurve_bezt_free` which sets the key count to zero and frees the key
array. This function is now used in couple of instances of functionally
equivalent code. Note that `BKE_fcurve_delete_keys_all` is just a
wrapper around `fcurve_bezt_free`.
This change was initially spurred by the fact that `delete_fcurve_keys`
was improperly named; this was a good opportunity to fix the location
and naming of a few of these functions.
Reviewed By: sybren
Differential Revision: https://developer.blender.org/D15282
|
|
This patch updates the documentation for arguments regarding the `Gizmo`
type.
- Corrected `select_id` doc for draw_preset_ functions. `-1` indicates
that no selection ID is to be written, but previous docs incorrectly
specified `0` instead.
- Added missing doc for `target` argument for `target_set_handler`
function.
Reviewed by: Aaron Carlisle (Blendify)
Differential Revision: https://developer.blender.org/D14834
|
|
|
|
Add internal function (only used for testing at the moment)
`_bpy._driver_secure_code_test`.
Add test `script_pyapi_bpy_driver_secure_eval` to serves two purposes:
- Ensure expressions that should be insecure remain so when upgrading
Python or making any changes in this area.
- Ensure new versions of Python don't introduce new byte-codes that
prevent existing expressions from being executed
(happened when upgrading from 3.7, see [0]).
[0]: dfa52017638abdf59791e5588c439d3a558a191d
|
|
The following opcodes have been added, see [0] for details:
- LIST_TO_TUPLE: convert a list to a tuple,
use for constructing lists/tuples in some cases.
- LIST_EXTEND: use for constructing lists with unpacking.
- SET_UPDATE: use for constructing sets with unpacking.
- CONTAINS_OP: check if `a in b` generally useful.
When writing tests these op-codes where needed for basic operations
and can be safely supported.
Add note why dictionary manipulation op-codes have been left out.
Also restrict namsepace access to anything with an underscore prefix
since these may be undocumented.
[0]: https://docs.python.org/3.10/library/dis.html
|
|
Also move mis-placed doc-string.
|
|
Showing the expression alone may not be enough to track down an error
evaluating a py-driver. Show information about the target ID & property
in the error message as well.
|
|
These kinds of leaks are relatively harmless, it reduces the number of
un-freed data reported by valgrind on exit.
|
|
Also use __func__ for printing the funciton name.
|
|
Error in [0] which assumed the struct member was renamed however
byte-code access from PyCodeObject now requires an API call.
Thanks to @music for pointing this out.
[0]: 780c0ea097444c3be60314dffd203c099720badb
|
|
- Use API calls to access frame-data as PyFrameObject is now opaque.
- Update opcodes allowed for safe driver evaluation.
**Details**
Some opcodes have been added for safe-driver evaluation.
Python 3.11 removes many opcodes - the number of accepted opcodes in
Blender's listing dropped from 65 to 43) however some new opcodes
also needed to be added. As this relates to security details about newly
added opcodes have been noted below (see [0] for full documentation).
Newly added opcodes:
- CACHE:
Used to control caching instructions.
- RESUME:
A no-op. Performs internal checks.
- BINARY_OP:
Implements the binary and in-place operators,
replacing specific binary operations.
- CALL, PRECALL, KW_NAMES:
Used for calling functions, replacing some existing opcodes.
- POP_JUMP_{FORWARD/BACKWARD}_IF_{TRUE/FALSE/NONE/NOT_NONE}.
Manipulate the byte-code counter.
- SWAP, PUSH_NULL.
Stack manipulation.
Resolves T99277.
[0]: https://docs.python.org/3.11/library/dis.html
|